DETAILED ACTION
Claims 2, 3, 10, 12, 13, and 20 are cancelled. Claims 9 and 22 are amended. Claims 1, 4-9, 11, 14-19, and 21-26 are pending in the application.
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 .
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.
Examiner’s Notes
The Examiner cites particular sections in the references as applied to the claims below for the convenience of the applicant(s). Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant(s) fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Response to Amendment
Amendments to claim 22 are fully considered and are satisfactory to overcome the objections directed to the claims in the previous Office Action.
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, 4-9, 11, 14-19, and 21-26 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
With respect to claim 1: Claim 1 recites a method for enforcing API (Application Programming Interface) authorization policies for an application executing on a first computer, the method comprising: at a second computer that receives requests to authorize API calls from the first computer and a first plurality of additional computers; receiving, from the first computer, a request to determine whether an API call received by the application is authorized, after an authentication operation is performed on the API call at the first computer to determine that the API call is from a source that is allowed to make such a call to the application; from a single hierarchical storage document stored on the second computer, extracting at least one API-authorization policy applicable to the API call received by the application and a first set of parameters for evaluating the API-authorization policy, wherein the single hierarchical storage document stores (i) definitions, from a first set of sources, for a plurality of authorization policies for a plurality of API calls to applications executing on the first computer and the first plurality of additional computers and (ii) parameters, collected from a second set of sources different than the first set of sources, to evaluate the authorization policies to assess whether API calls made to the applications should be authorized or rejected; using the identified first set of parameters to evaluate the identified API- authorization policy in order to determine that the API call should be approved; and sending a response to the first computer to authorize the API call after determining that the API call should be approved, wherein the second computer further distributes hierarchical storage documents storing defined policies and parameters to a second plurality of additional computers for local agents executing on the second plurality of additional computers to use the hierarchical storage documents to authorize or reject API calls made to applications executing on the second plurality of additional computers.
Based upon consideration of all of the relevant factors with respect to claim 1 as a whole, the claim is determined to be directed to a judicial exception (i.e. an abstract idea).
Under the broadest reasonable interpretation (BRI), the terms of the claim are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. See MPEP §2111. As such, the broadest reasonable interpretation of claim 1 is a method of authorizing API calls based on API-authorization policies stored in hierarchical storage documents that are distributed to a plurality of computers.
Step 1: This part of the eligibility analysis evaluates whether the claim falls within any statutory category. MPEP §2106.03. The claim recites at least one step or act, including receiving, from the first computer, a request to determine whether an API call received by the application is authorized. Thus, the claim is directed to a process, which is one of the statutory categories of invention.
Step 2A Prong One: This part of the eligibility analysis evaluates whether the claim recites a judicial exception. As explained in MPEP 2106.04(II) and the October 2019 Update, a claim “recites” a judicial exception when the judicial exception is “set forth” or “described” in the claim.
In this case, the limitations “to determine whether an API call received by the application is authorized”, “extracting at least one API-authorization policy applicable to the API call received by the application and a first set of parameters for evaluating the API-authorization policy”, “(i) definitions, from a first set of sources, for a plurality of authorization policies for a plurality of API calls to applications executing on the first computer and the first plurality of additional computers and (ii) parameters, collected from a second set of sources different than the first set of sources, to evaluate the authorization policies to assess whether API calls made to the applications should be authorized or rejected”, “using the identified first set of parameters to evaluate the identified API- authorization policy in order to determine that the API call should be approved”, “determining that the API call should be approved” recited in claim 1 can be performed mentally by observing policy information, observing parameter values and definition information included in the policies, and making a determination that an API call should be authorized or denied based on these observations. Such observations, evaluations, and judgements are classified under “mental processes” abstract grouping. See MPEP §2106.04(a)(2).
Accordingly, claim 1 does recite a judicial exception (i.e. an abstract idea).
Step 2A Prong Two: This part of the eligibility analysis evaluates whether the claim as a whole integrates the recited judicial exception into a practical application of the exception. This evaluation is performed by (a) identifying whether there are any additional elements recited in the claim beyond the judicial exception, and (b) evaluating those additional elements individually and in combination to determine whether the claim as a whole integrates the exception into a practical application. 2019 PEG Section III(A)(2), 84 Fed. Reg. at 54-55.
In this case, the additional elements are: (i) “an application executing on a first computer”, (ii) “at a second computer that receives requests to authorize API calls from the first computer and a first plurality of additional computers”, (iii) “receiving, from the first computer, a request”, (iv) “after an authentication operation is performed on the API call at the first computer to determine that the API call is from a source that is allowed to make such a call to the application”, (v) “from a single hierarchical storage document stored on the second computer… the single hierarchical storage document stores”, (vi) “sending a response to the first computer to authorize the API call after”, and (vii) “the second computer further distributes hierarchical storage documents storing defined policies and parameters to a second plurality of additional computers for local agents executing on the second plurality of additional computers to use the hierarchical storage documents to authorize or reject API calls made to applications executing on the second plurality of additional computers”.
Regarding the additional element (i), the limitations recited therewith are directed to a conventional computing device executing an application as known in the art. As such, the additional element (i) is no more than an attempt to generally link the use of the claimed method to a particular technological environment or a field of use which fails to integrate the judicial exception into a practical application in a meaningful manner. See MPEP §2106.05(h).
Regarding the additional elements (ii), (iii), (v), (vi), and (vii) the limitations recited therewith are directed to data gathering and data storage operations in general which are tangential or nominal additions to the claim. Specifically, these additional elements are directed to mere data gathering operations (e.g. receiving requests, storing documents, distributing documents) which are tangential to the abovementioned judicial exception. As such, the additional elements (ii), (iii), (v), and (vi) are insignificant extra-solution activities that fail to integrate the judicial exception into a practical application in a meaningful manner. See MPEP §2106.05(g).
Regarding the additional element (iv), the limitations recited therewith are directed to an authentication operation performed at a computing device that is not a part of the claimed method; that is, the authentication process is tangential to the method of authorizing API calls performed at the second computer as recited in the claims. As such, the additional element (iv) is a pre-solution insignificant activity that fails to integrate the judicial exception into a practical application in a meaningful manner. See MPEP §2106.05(g).
These additional elements, in combination, also fail to integrate the judicial exception into a practical application the combination of these elements results in a computing environment that performs operations (e.g. data storage, API authentication, data transmission) recited in a high-level of generality that are tangential and nominal to the judicial exception.
Consequently, the additional elements (i)-(vii), both individually and in combination, fail to integrate the judicial exception as a whole into a practical application in a meaningful manner.
Step 2B: This part of the eligibility analysis evaluates whether the claim as a whole amounts to significantly more than the recited exception, i.e., whether any additional element, or combination of additional elements, adds an inventive concept to the claim. MPEP 2106.05.
As discussed above with respect to Step 2A Prong Two, the additional element (i) is directed to a generic computer performing a conventional operation (i.e. executing an application) as known in the art, and the additional elements (ii)-(vii)and (iii) are directed to data transmission and storage operations for API authorization purposes which are, as also identified in the background section of the instant application and the various documents submitted with the Information Disclosure Statements (see e.g. IDS submitted on 04/19/2024, US Patent Cite No. 1-2, US Patent Application Publication Cite No. 1), known data processing functions in the art. As such, these additional elements, both individually and in combination, fail to introduce an inventive concept to claim 1.
Consequently, claim 1 as a whole does not amount to significantly more than the judicial exception, and claim 1 is not eligible.
With respect to claims 4-9 and 21-26: Claims 4-9 and 21-26 also fail to integrate the judicial exception into a practical application because:
Claims 4, 8, 9, and 23-27 are directed to data gathering operations merely tangential to the judicial exception. As such, claims 4, 8, 9, and 23-27 present insignificant extra solution activities that fail to integrate the judicial exception into a practical application in a meaningful manner.
Claims 5-7, 21, and 22 present additional elements at a high-level of generality which is no more than an attempt to generally link the judicial exception into a technological field. As such, claims 5-7, 21, and 22 fail to integrate the judicial exception into a practical application in a meaningful manner.
With respect to claims 11 and 14-19: Claims 11 and 14-19 are directed to a non-transitory machine readable medium storing a program comprising instructions for implementing active steps corresponding to the method disclosed in claims 1 and 4-9, respectively. As such, in view of the reasons with respect to claims 1 and 4-9 presented above, claims 11 and 14-19 are also directed to an abstract idea without significantly more and are ineligible.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 11 and 14-19 are rejected under 35 U.S.C. 103 as being unpatentable over Moriconi et al. (US 2003/0115484 A1; from IDS filed on 09/21/2021; hereinafter Moriconi) in view of Garg et al. (US 2004/0083367 A1; hereinafter Garg) and Krishnamurthy et al. (US 2018/0295036 A1; from IDS filed on 09/21/2021; hereinafter Krishnamurthy).
With respect to claim 11, Moriconi teaches: A non-transitory machine readable medium storing a program (see e.g. Moriconi, paragraphs 48-51) enforcing API (Application Programming Interface) authorization policies for an application executing on a first computer (see e.g. Moriconi, paragraph 46: “an application guard located on …a client”; paragraph 75: “application guard 310 preferably includes at least one application 312, an authorization library program 314”; and paragraph 87: “application guard interface 512 can be located on a client computer”; and Fig. 5), the program for execution by at least one processing unit of a second computer (see e.g. Moriconi, paragraph 87: “authorization engine 316 and local client policy 318 can be located on client server 116”) that receives requests to authorize API calls from the first computer (see e.g. Moriconi, paragraph 76: “Authorization engine 316 grants or denies access to securable components of client server 116”; and paragraph 169: “performing a back-end policy analysis at a client server 116 for a query issued at an application”) and a first plurality of additional computers (see e.g. Moriconi, paragraph 47: “Each user terminal 118 can access the components or resources hosted on one of the n client servers upon being granted access privileges based on the local client security policy stored in the client server”; and Fig. 1: “User Terminal 118.1-118.m”), the program comprising sets of instructions for:
receiving, from the first computer, a request to determine whether an API call received by the application executing on the first computer is authorized (see e.g. Moriconi, paragraph 76: “Authorization engine 316 grants or denies access to securable components of client server 116, as specified by the set of rules in the local client security policy, which is stored in local client policy (database) 318… securable components of client server 116 can include applications, data, and/or objects”; paragraph 169: “performing a back-end policy analysis at a client server 116 for a query issued at an application”; and paragraph 170: “the application issues a query containing one or more parameters and sends the query, together with the parameters, to local policy analysis (engine) 319 via BLE API 332 (FIG. 3A). The query is programmed into the application by a user at a user terminal 118 (FIG. 1) or at a console (not shown) coupled to client server 116”);
extracting, from a single hierarchical storage document (see e.g. Moriconi, paragraph 75: “a local client security policy (data file”; paragraph 139: “policy data designed according to the policy model, which includes rule inheritance, object hierarchy, role hierarchy, and other interrelationships between policy components”; paragraph 150: “role hierarchy and rule inheritance”; paragraph 152: “objects hierarchy”; and Fig. 14-15) stored on the second computer (see e.g. Moriconi, paragraph 75: “FIG. 3 is a block diagram of one embodiment for non-volatile memory 138, located within client server 116… application guard 310 preferably includes… a local client security policy (data file”), at least one API-authorization policy applicable to the API call received by the application (see e.g. Moriconi, paragraph 76: “Authorization engine 316 grants or denies access to securable components of client server 116, as specified by the set of rules in the local client security policy, which is stored in local client policy (database) 318”; paragraph 87: “Application guard 310 also includes at least one authorization engine 316 for evaluating requests from application guard interface 512 as specified by local client security policy 318”; and paragraph 169: “performing a back-end policy analysis at a client server 116 for a query issued at an application”) and a first sets of parameters (see e.g. Moriconi, paragraph 171: “object and role”) for evaluating the API-authorization policy (see e.g. Moriconi, paragraph 153: “When processing a policy inquiry, the system considers the rule inheritance, object hierarchy and role hierarchy as shown in FIGS. 14 and 15”; and paragraph 171: “local policy analysis 319 in a BLE (FIG. 3A) executes the query against the local client security policy based on the object and role hierarchy, and rule inheritances shown in FIGS. 14 and 15”), wherein the single hierarchical storage document stores… (ii) parameters, collected from a second set of sources (see e.g. Moriconi, paragraphs 11-12)… to evaluate the authorization policies to assess whether API calls made to the applications should be authorized or rejected (see e.g. Moriconi, paragraph 153: “When processing a policy inquiry, the system considers the rule inheritance, object hierarchy and role hierarchy as shown in FIGS. 14 and 15. The results present rules that match the given privilege, object, and subject in a query request”);
using the identified first set of parameters to evaluate the identified API-authorization policy in order to determine that the API call should be approved (see e.g. Moriconi, paragraph 51: “"security rules" that describe several constraints, including what applications a particular user can access, what objects (resources) within an application a user can access, and how those privileges are constrained by time, geography, attributes, application data or external events”; paragraph 166: “BLC 212 receives a query containing one or more parameters from a user and forwards the query, together with the parameters, to policy manager 210”; and paragraph 167: “upon receiving the query and the parameters, policy analysis 234 in policy manager 210 interprets the query and parameters, and executes the query against the global security policy 224 based on the object and role hierarchy, and rule inheritances shown in FIGS. 14 and 15”); and
sending a response to the first computer to authorize the API call after determining that the API call should be approved (see e.g. Moriconi, paragraph 172: “the application receives the query results and further processes the results according to the application's operational flow, which may display the results to the user”),
wherein the second computer further distributes (see e.g. Moriconi, paragraph 73: “a distributor program 214 to distribute local client security policies”; and paragraph 175: “bundles a management system, zero or more engines, and a policy database on a single server and then synchronizes with local policy stores over the network following local authorization requests to the central server”) hierarchical storage documents storing defined policies and parameters to a second plurality of additional computers (see e.g. Moriconi, Fig. 1: “Client Server 1 Applications 116.1… Client Server n Applications 116.n”)… to use the hierarchical storage documents to authorize or reject API calls made to applications executing on the second plurality of additional computers (see e.g. Moriconi, paragraph 47: “Each client server 116 hosts various components or resources, stores a set of rules of the policy received through the network from policy manager server 112, and enforces the set of rules for components or resources. The set of rules received through the network is otherwise known as a local client security policy”).
Since Moriconi already discloses a policy distributor 214 that distributes policies to additional computers (see e.g. Moriconi, paragraph 73), it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement such a distributor 214 on a client server 116 as Moriconi further discloses such modifications to servers to implement policy distribution as one of the embodiments (see e.g. Moriconi, paragraph 175). The motivation/suggestion for such a modification would be to reduce the workload on the policy manager server 112; thus improving the overall processing efficiency.
Moriconi does not but Garg teaches:
(i) definitions, form a first set of sources, for a plurality of authorization policies for a plurality of API calls to applications (see e.g. Garg, paragraph 29: “Authorization policy store 104 stores data that represents authorization objects and relationships between those objects. The objects and relationships define which users are authorized to perform which operations in association with one or more applications”) executing on the first computer and the first plurality of additional computers (see e.g. Garg, paragraph 29: “one or more applications”; and paragraph 256: “In a distributed computing environment, application modules may be located in both local and remote computer storage media”) and… different than the first set of sources (see e.g. Garg, paragraph 26: “application administrator defines role-based user permissions through authorization manager 108, which are stored in authorization policy store 104”; and paragraph 317: “delegation of administration at the authorization store… Support for delegation allows higher level administrators to give limited access to others to manage some subset of the data stored in authorization policy store 104… each authorization store object, application object, and scope object can have an associated list of administrators and an associated list of readers. Administrators are able to perform all operations on objects in the authorization policy while readers only have read access to the objects in the authorization policy store”),
Moriconi and Garg are analogous art because they are in the same field of endeavor: enforcing authorization policies for applications executing on a computer. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Moriconi with the teachings of Garg. The motivation/suggestion would be to provide an improved administration for the authorization policies; thus improving the overall authorization process management.
Moriconi does not but Krishnamurthy teaches:
for local agents (see e.g. Krishnamurthy, paragraph 117: “GI agent 2150”) executing on the second plurality of additional computers (see e.g. Krishnamurthy, paragraph 117: “Upon occurrence of a new network connection event, the GI agent 2150 receives a callback from an operating system (OS) of the corresponding VM 114 and, based on this callback, provides a network event identifier to the context engine 2110”; paragraph 119: “the OS of the VM 114 delays transmission of a new network event (e.g., does not start sending data messages for the network event) until the GI agent 2150 directs the OS to proceed with processing of the network event”; paragraph 146: “direct the GI agent 2150 of the VM 114 to perform a process-control operation on a process. Examples of such process-control operations include (1) terminating a video conference application that has a particular version number, (2) terminating a browser that is displaying YouTube traffic, (3) terminating applications that have a high threat level score, etc.”; and paragraph 89)
Moriconi and Krishnamurthy are analogous art because they are in the same field of endeavor: policy-based communication security management. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Moriconi with the teachings of Krishnamurthy. The motivation/suggestion would be to improve load balancing traffic by collecting user and/or process context (see e.g. Krishnamurthy, paragraph 84).
With respect to claim 14, Moriconi as modified teaches: The non-transitory machine readable medium of claim 11, wherein the request is received from, and the response is sent to, …executing on the first computer (see e.g. Moriconi, paragraph 46: “an application guard located on …a client”; paragraph 91: “application guard 310 is preferably integrated with application 312 through a high-level application programming interface (API) or authorization library 314 that allows application 312 to make authorization requests as needed through an application guard interface 512”; paragraph 170: “the application issues a query containing one or more parameters and sends the query, together with the parameters, to local policy analysis (engine) 319 via BLE API 332”; paragraph 172: “the application receives the query results and further processes the results according to the application's operational flow”; and Fig. 5).
Moriconi does not but Krishnamurthy teaches:
a local API-authorizing agent (see e.g. Krishnamurthy, paragraph 117: “Upon occurrence of a new network connection event, the GI agent 2150 receives a callback from an operating system (OS) of the corresponding VM 114 and, based on this callback, provides a network event identifier to the context engine 2110”; paragraph 119: “the OS of the VM 114 delays transmission of a new network event (e.g., does not start sending data messages for the network event) until the GI agent 2150 directs the OS to proceed with processing of the network event”; paragraph 146: “direct the GI agent 2150 of the VM 114 to perform a process-control operation on a process. Examples of such process-control operations include (1) terminating a video conference application that has a particular version number, (2) terminating a browser that is displaying YouTube traffic, (3) terminating applications that have a high threat level score, etc.”; and paragraph 89)
Moriconi and Krishnamurthy are analogous art because they are in the same field of endeavor: policy-based communication security management. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Moriconi with the teachings of Krishnamurthy. The motivation/suggestion would be to improve load balancing traffic by collecting user and/or process context (see e.g. Krishnamurthy, paragraph 84).
With respect to claim 15, Moriconi as modified teaches: The non-transitory machine readable medium of claim 14, wherein the application …execute on a machine that executes on the first computer (see e.g. Moriconi, paragraph 46: “an application guard located on …a client”; paragraph 50: “various components or resources of client 116 can include applications, functions or procedures within an application, data structures within an application, and database or file system objects referenced by an application”; and paragraph 75: “application guard 310 preferably includes at least one application 312, an authorization library program 314””).
Moriconi does not but Krishnamurthy teaches:
and the local agent (see e.g. Krishnamurthy, paragraph 63: “execute a guest-introspection (GI) agent on each machine”)
Moriconi and Krishnamurthy are analogous art because they are in the same field of endeavor: policy-based communication security management. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Moriconi with the teachings of Krishnamurthy. The motivation/suggestion would be to improve load balancing traffic by collecting user and/or process context (see e.g. Krishnamurthy, paragraph 84).
With respect to claim 16, Moriconi as modified teaches: The non-transitory machine readable medium of claim 15,
Moriconi does not but Krishnamurthy teaches:
wherein the machine is a virtual machine (see e.g. Krishnamurthy, paragraph 63: “the GI agents of the VMs on a host”).
Moriconi and Krishnamurthy are analogous art because they are in the same field of endeavor: policy-based communication security management. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Moriconi with the teachings of Krishnamurthy. The motivation/suggestion would be to improve computing resource management (see e.g. Krishnamurthy, paragraph 2).
With respect to claim 17, Moriconi as modified teaches: The non-transitory machine readable medium of claim 15,
Moriconi does not but Krishnamurthy teaches:
wherein the machine is a container (see e.g. Krishnamurthy, paragraph 63: “the GI agents of the VMs on a host”; and paragraph 36: “Operating system virtualization is also referred to herein as container virtualization. As used herein, operating system virtualization refers to a system in which processes are isolated in an operating system. In a typical operating system virtualization system, a host operating system is installed on the server hardware. Alternatively, the host operating system may be installed in a virtual machine of a full virtualization environment”).
Moriconi and Krishnamurthy are analogous art because they are in the same field of endeavor: policy-based communication security management. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Moriconi with the teachings of Krishnamurthy. The motivation/suggestion would be to improve computing resource management (see e.g. Krishnamurthy, paragraph 2).
With respect to claim 18, Moriconi as modified teaches: The non-transitory machine readable medium of claim 15, wherein the application executing on the machine on the first computer receives the API call and in response sends a request to authorize the API call… of the machine (see e.g. Moriconi, paragraph 170: “the application issues a query containing one or more parameters and sends the query, together with the parameters, to local policy analysis (engine) 319 via BLE API 332”); and
forwards the request to the second computer (see e.g. Moriconi, paragraph 169: “performing a back-end policy analysis at a client server 116 for a query issued at an application”; and paragraph 170: “the application issues a query containing one or more parameters and sends the query, together with the parameters, to local policy analysis (engine) 319 via BLE API 332 (FIG. 3A). The query is programmed into the application by a user at a user terminal 118 (FIG. 1) or at a console (not shown) coupled to client server 116”).
Moriconi does not but Krishnamurthy teaches:
to the local API-authorizing agent through a network stack (see e.g. Krishnamurthy, paragraph 202: “the GI agent 2150 interacts with the network stack and/or process subsystem in the VM's OS kernel space to collect contextual attributes regarding a process or network event”)
the local API-authorizing agent executing on the machine on the first computer (see e.g. Krishnamurthy, paragraph 117: “Upon occurrence of a new network connection event, the GI agent 2150 receives a callback from an operating system (OS) of the corresponding VM 114 and, based on this callback, provides a network event identifier to the context engine 2110”; and paragraph 119: “the OS of the VM 114 delays transmission of a new network event (e.g., does not start sending data messages for the network event) until the GI agent 2150 directs the OS to proceed with processing of the network event”)
Moriconi and Krishnamurthy are analogous art because they are in the same field of endeavor: policy-based communication security management. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Moriconi with the teachings of Krishnamurthy. The motivation/suggestion would be to improve load balancing traffic by collecting user and/or process context (see e.g. Krishnamurthy, paragraph 84).
With respect to claim 19, Moriconi as modified teaches: The non-transitory machine readable medium of claim 11, wherein the program further comprises sets of instructions for:
receiving the definitions for the plurality of authorization policies for a plurality of API calls to the application (see e.g. Moriconi, paragraph 47: “Each client server 116 hosts various components or resources, stores a set of rules of the policy received through the network from policy manager server 112, and enforces the set of rules for components or resources. The set of rules received through the network is otherwise known as a local client security policy”; and paragraph 54: “An authorization policy preferably comprises four components, including objects, subjects, privileges, and conditions. Objects may be applications, or the operations within an application. Examples of objects include applications or methods, web pages, database tables or files, and menu items in a graphical user interface”) executing on the first computer (see e.g. Moriconi, paragraph 17: “a policy may contain thousands of rules, applications and users. In a distributed system, these applications and users may be scattered through many geographically separated locations, which are connected to each other through a network”; and Fig. 1), the first plurality of additional computers (see e.g. Moriconi, paragraph 17: “a policy may contain thousands of rules, applications and users. In a distributed system, these applications and users may be scattered through many geographically separated locations, which are connected to each other through a network”; and Fig. 1), and the second plurality of additional computers (see e.g. Moriconi, paragraph 17: “a policy may contain thousands of rules, applications and users. In a distributed system, these applications and users may be scattered through many geographically separated locations, which are connected to each other through a network”; and Fig. 1);
collecting, …the parameters for evaluating the authorization policies to assess whether API calls should be authorized or rejected (see e.g. Moriconi, paragraph 76: “Authorization engine 316 grants or denies access to securable components of client server 116, as specified by the set of rules in the local client security policy, which is stored in local client policy (database) 318. For example, securable components of client server 116 can include applications, data, and/or objects”); and
storing the defined authorization policies and the collected parameters in a single hierarchical storage document from which the policies and associated set of parameters are retrieved to evaluate whether API calls made to applications on the first computer and the first plurality of additional computers should be authorized (see e.g. Moriconi, paragraph 139: “policy data designed according to the policy model, which includes rule inheritance, object hierarchy, role hierarchy, and other interrelationships between policy components”; paragraph 152: “objects hierarchy in reference to an organizational chart in a fictitious stocking trading company. In FIG. 15, four organization nodes are arranged in two layers, namely, "global," "trading," "human resources," and "payroll." Each organization node at the second layer is associated with one or more applications (i.e. t1, t2, and t3; h1 and h2; or p1). Each application is associated with one or more resources nodes. For example, if an application node is an intranet management application, the associated resources can be web pages; or if an application node is a database, the associated resources can be database table views”; paragraph 167; paragraph 17: “a policy may contain thousands of rules, applications and users. In a distributed system, these applications and users may be scattered through many geographically separated locations, which are connected to each other through a network”; and Fig. 1).
Claims 1, 4-9, and 21-26 are rejected under 35 U.S.C. 103 as being unpatentable over Moriconi in view of Blasi (US 2017/0346807 A1), Garg, and Krishnamurthy.
With respect to claim 1, Moriconi teaches: A method for enforcing API (Application Programming Interface) authorization policies for an application executing on a first computer (see e.g. Moriconi, paragraph 46: “an application guard located on …a client”; paragraph 75: “application guard 310 preferably includes at least one application 312, an authorization library program 314”; and paragraph 87: “application guard interface 512 can be located on a client computer”; and Fig. 5), the method comprising:
at a second computer (see e.g. Moriconi, paragraph 87: “authorization engine 316 and local client policy 318 can be located on client server 116”) that receives requests to authorize API calls from the first computer (see e.g. Moriconi, paragraph 76: “Authorization engine 316 grants or denies access to securable components of client server 116”; and paragraph 169: “performing a back-end policy analysis at a client server 116 for a query issued at an application”) and a first plurality of additional computers (see e.g. Moriconi, paragraph 47: “Each user terminal 118 can access the components or resources hosted on one of the n client servers upon being granted access privileges based on the local client security policy stored in the client server”; and Fig. 1: “User Terminal 118.1-118.m”):
receiving, from the first computer, a request to determine whether an API call received by the application is authorized (see e.g. Moriconi, paragraph 76: “Authorization engine 316 grants or denies access to securable components of client server 116, as specified by the set of rules in the local client security policy, which is stored in local client policy (database) 318… securable components of client server 116 can include applications, data, and/or objects”; paragraph 169: “performing a back-end policy analysis at a client server 116 for a query issued at an application”; and paragraph 170: “the application issues a query containing one or more parameters and sends the query, together with the parameters, to local policy analysis (engine) 319 via BLE API 332 (FIG. 3A). The query is programmed into the application by a user at a user terminal 118 (FIG. 1) or at a console (not shown) coupled to client server 116”),
from a single hierarchical storage document (see e.g. Moriconi, paragraph 75: “a local client security policy (data file”; paragraph 139: “policy data designed according to the policy model, which includes rule inheritance, object hierarchy, role hierarchy, and other interrelationships between policy components”; paragraph 150: “role hierarchy and rule inheritance”; paragraph 152: “objects hierarchy”; and Fig. 14-15) stored on the second computer (see e.g. Moriconi, paragraph 75: “FIG. 3 is a block diagram of one embodiment for non-volatile memory 138, located within client server 116… application guard 310 preferably includes… a local client security policy (data file”), extracting at least one API-authorization policy applicable to the API call received by the application (see e.g. Moriconi, paragraph 76: “Authorization engine 316 grants or denies access to securable components of client server 116, as specified by the set of rules in the local client security policy, which is stored in local client policy (database) 318”; paragraph 87: “Application guard 310 also includes at least one authorization engine 316 for evaluating requests from application guard interface 512 as specified by local client security policy 318”; and paragraph 169: “performing a back-end policy analysis at a client server 116 for a query issued at an application”) and a first sets of parameters (see e.g. Moriconi, paragraph 171: “object and role”) for evaluating the API-authorization policy (see e.g. Moriconi, paragraph 153: “When processing a policy inquiry, the system considers the rule inheritance, object hierarchy and role hierarchy as shown in FIGS. 14 and 15”; and paragraph 171: “local policy analysis 319 in a BLE (FIG. 3A) executes the query against the local client security policy based on the object and role hierarchy, and rule inheritances shown in FIGS. 14 and 15”), wherein the single hierarchical storage document stores… (ii) parameters, collected from a second set of sources (see e.g. Moriconi, paragraphs 11-12)… to evaluate the authorization policies to assess whether API calls made to the applications should be authorized or rejected (see e.g. Moriconi, paragraph 153: “When processing a policy inquiry, the system considers the rule inheritance, object hierarchy and role hierarchy as shown in FIGS. 14 and 15. The results present rules that match the given privilege, object, and subject in a query request”);
using the identified first set of parameters to evaluate the identified API-authorization policy in order to determine that the API call should be approved (see e.g. Moriconi, paragraph 51: “"security rules" that describe several constraints, including what applications a particular user can access, what objects (resources) within an application a user can access, and how those privileges are constrained by time, geography, attributes, application data or external events”; paragraph 166: “BLC 212 receives a query containing one or more parameters from a user and forwards the query, together with the parameters, to policy manager 210”; and paragraph 167: “upon receiving the query and the parameters, policy analysis 234 in policy manager 210 interprets the query and parameters, and executes the query against the global security policy 224 based on the object and role hierarchy, and rule inheritances shown in FIGS. 14 and 15”); and
sending a response to the first computer to authorize the API call after determining that the API call should be approved (see e.g. Moriconi, paragraph 172: “the application receives the query results and further processes the results according to the application's operational flow, which may display the results to the user”),
wherein the second computer further distributes (see e.g. Moriconi, paragraph 73: “a distributor program 214 to distribute local client security policies”; and paragraph 175: “bundles a management system, zero or more engines, and a policy database on a single server and then synchronizes with local policy stores over the network following local authorization requests to the central server”) hierarchical storage documents storing defined policies and parameters to a second plurality of additional computers (see e.g. Moriconi, Fig. 1: “Client Server 1 Applications 116.1… Client Server n Applications 116.n”)… to use the hierarchical storage documents to authorize or reject API calls made to applications executing on the second plurality of additional computers (see e.g. Moriconi, paragraph 47: “Each client server 116 hosts various components or resources, stores a set of rules of the policy received through the network from policy manager server 112, and enforces the set of rules for components or resources. The set of rules received through the network is otherwise known as a local client security policy”).
Since Moriconi already discloses a policy distributor 214 that distributes policies to additional computers (see e.g. Moriconi, paragraph 73), it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement such a distributor 214 on a client server 116 as Moriconi further discloses such modifications to servers to implement policy distribution as one of the embodiments (see e.g. Moriconi, paragraph 175). The motivation/suggestion for such a modification would be to reduce the workload on the policy manager server 112; thus improving the overall processing efficiency.
Moriconi does not but Blasi teaches:
after (see e.g. Blasi, Fig. 5-6) an authentication operation (see e.g. Blasi, paragraph 55: “authenticating”; and paragraph 68: “authenticating the ISV application 132 by the access management server 110 and authorizing the ISV application 132 to access requested services and data provided by the resource server 140”) is performed on the API call (see e.g. Blasi, paragraph 55: “a request to access data or services provided by the resource server 140 via one or more exposed APIs”) at the first computer (see e.g. Blasi, Fig. 1: “Access Management Server 110”) to determine that the API call is from a source (see e.g. Blasi, paragraph 55: “a distributed computing resource (e.g., the ISV application 132) of a requesting entity (e.g., an ISV or another entity)”) that is allowed to make such a call to the application (see e.g. Blasi, paragraph 55: “authenticating a distributed computing resource (e.g., the ISV application 132) of a requesting entity (e.g., an ISV or another entity)… the service request message includes a digitally signed license token 300 for authentication and access authorization of the ISV application 132 (or some other distributed computing resource of the requesting entity)”; and paragraph 58: “In block 508, the access management server 110 compares the previously-generated hash value obtained by decrypting the digital signature 340 with the new hash value generated from hashing the unencrypted payload portion 320 of the received license token 300. In decision block 510, the access management server 110 determines whether the previously-generated hash value matches the newly generated hash value”);
Moriconi and Blasi are analogous art because they are in the same field of endeavor: authorizing API calls within a network environment. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Moriconi with the teachings of Blasi. The motivation/suggestion would be to increase security (see e.g. Blasi, paragraph 21).
Moriconi does not but Garg teaches:
(i) definitions, form a first set of sources, for a plurality of authorization policies for a plurality of API calls to the applications (see e.g. Garg, paragraph 29: “Authorization policy store 104 stores data that represents authorization objects and relationships between those objects. The objects and relationships define which users are authorized to perform which operations in association with one or more applications”) executing on the first computer and the first plurality of additional computers (see e.g. Garg, paragraph 29: “one or more applications”; and paragraph 256: “In a distributed computing environment, application modules may be located in both local and remote computer storage media”) and… different than the first set of sources (see e.g. Garg, paragraph 26: “application administrator defines role-based user permissions through authorization manager 108, which are stored in authorization policy store 104”; and paragraph 317: “delegation of administration at the authorization store… Support for delegation allows higher level administrators to give limited access to others to manage some subset of the data stored in authorization policy store 104… each authorization store object, application object, and scope object can have an associated list of administrators and an associated list of readers. Administrators are able to perform all operations on objects in the authorization policy while readers only have read access to the objects in the authorization policy store”),
Moriconi and Garg are analogous art because they are in the same field of endeavor: enforcing authorization policies for applications executing on a computer. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Moriconi with the teachings of Garg. The motivation/suggestion would be to provide an improved administration for the authorization policies; thus improving the overall authorization process management.
Moriconi does not but Krishnamurthy teaches:
for local agents (see e.g. Krishnamurthy, paragraph 117: “GI agent 2150”) executing on the second plurality of additional computers (see e.g. Krishnamurthy, paragraph 117: “Upon occurrence of a new network connection event, the GI agent 2150 receives a callback from an operating system (OS) of the corresponding VM 114 and, based on this callback, provides a network event identifier to the context engine 2110”; paragraph 119: “the OS of the VM 114 delays transmission of a new network event (e.g., does not start sending data messages for the network event) until the GI agent 2150 directs the OS to proceed with processing of the network event”; paragraph 146: “direct the GI agent 2150 of the VM 114 to perform a process-control operation on a process. Examples of such process-control operations include (1) terminating a video conference application that has a particular version number, (2) terminating a browser that is displaying YouTube traffic, (3) terminating applications that have a high threat level score, etc.”; and paragraph 89)
Moriconi and Krishnamurthy are analogous art because they are in the same field of endeavor: policy-based communication security management. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Moriconi with the teachings of Krishnamurthy. The motivation/suggestion would be to improve load balancing traffic by collecting user and/or process context (see e.g. Krishnamurthy, paragraph 84).
With respect to claim 4, Moriconi as modified teaches: The method of claim 1, wherein the request is received from, and the response is sent to, …executing on the first computer (see e.g. Moriconi, paragraph 46: “an application guard located on …a client”; paragraph 91: “application guard 310 is preferably integrated with application 312 through a high-level application programming interface (API) or authorization library 314 that allows application 312 to make authorization requests as needed through an application guard interface 512”; paragraph 170: “the application issues a query containing one or more parameters and sends the query, together with the parameters, to local policy analysis (engine) 319 via BLE API 332”; paragraph 172: “the application receives the query results and further processes the results according to the application's operational flow”; and Fig. 5).
Moriconi does not but Krishnamurthy teaches:
a local API-authorizing agent (see e.g. Krishnamurthy, paragraph 117: “Upon occurrence of a new network connection event, the GI agent 2150 receives a callback from an operating system (OS) of the corresponding VM 114 and, based on this callback, provides a network event identifier to the context engine 2110”; paragraph 119: “the OS of the VM 114 delays transmission of a new network event (e.g., does not start sending data messages for the network event) until the GI agent 2150 directs the OS to proceed with processing of the network event”; paragraph 146: “direct the GI agent 2150 of the VM 114 to perform a process-control operation on a process. Examples of such process-control operations include (1) terminating a video conference application that has a particular version number, (2) terminating a browser that is displaying YouTube traffic, (3) terminating applications that have a high threat level score, etc.”; and paragraph 89)
Moriconi and Krishnamurthy are analogous art because they are in the same field of endeavor: policy-based communication security management. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Moriconi with the teachings of Krishnamurthy. The motivation/suggestion would be to improve load balancing traffic by collecting user and/or process context (see e.g. Krishnamurthy, paragraph 84).
With respect to claim 5, Moriconi as modified teaches: The method of claim 4, wherein the application …execute on a machine that executes on the first computer (see e.g. Moriconi, paragraph 46: “an application guard located on …a client”; paragraph 50: “various components or resources of client 116 can include applications, functions or procedures within an application, data structures within an application, and database or file system objects referenced by an application”; paragraph 75: “application guard 310 preferably includes at least one application 312, an authorization library program 314””).
Moriconi does not but Krishnamurthy teaches:
and the local agent (see e.g. Krishnamurthy, paragraph 63: “execute a guest-introspection (GI) agent on each machine”)
Moriconi and Krishnamurthy are analogous art because they are in the same field of endeavor: policy-based communication security management. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Moriconi with the teachings of Krishnamurthy. The motivation/suggestion would be to improve load balancing traffic by collecting user and/or process context (see e.g. Krishnamurthy, paragraph 84).
With respect to claim 6, Moriconi as modified teaches: The method of claim 5,
Moriconi does not but Krishnamurthy teaches:
wherein the machine is a virtual machine (see e.g. Krishnamurthy, paragraph 63: “the GI agents of the VMs on a host”).
Moriconi and Krishnamurthy are analogous art because they are in the same field of endeavor: policy-based communication security management. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Moriconi with the teachings of Krishnamurthy. The motivation/suggestion would be to improve computing resource management (see e.g. Krishnamurthy, paragraph 2).
With respect to claim 7, Moriconi as modified teaches: The method of claim 5,
Moriconi does not but Krishnamurthy teaches:
wherein the machine is a container (see e.g. Krishnamurthy, paragraph 63: “the GI agents of the VMs on a host”; and paragraph 36: “Operating system virtualization is also referred to herein as container virtualization. As used herein, operating system virtualization refers to a system in which processes are isolated in an operating system. In a typical operating system virtualization system, a host operating system is installed on the server hardware. Alternatively, the host operating system may be installed in a virtual machine of a full virtualization environment”).
Moriconi and Krishnamurthy are analogous art because they are in the same field of endeavor: policy-based communication security management. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Moriconi with the teachings of Krishnamurthy. The motivation/suggestion would be to improve computing resource management (see e.g. Krishnamurthy, paragraph 2).
With respect to claim 8, Moriconi as modified teaches: The method of claim 5, wherein:
the application executing on the machine on the first computer receives the API call and in response sends a request to authorize the API call …of the machine (see e.g. Moriconi, paragraph 170: “the application issues a query containing one or more parameters and sends the query, together with the parameters, to local policy analysis (engine) 319 via BLE API 332”), and
forwards the request to the second computer (see e.g. Moriconi, paragraph 169: “performing a back-end policy analysis at a client server 116 for a query issued at an application”; and paragraph 170: “the application issues a query containing one or more parameters and sends the query, together with the parameters, to local policy analysis (engine) 319 via BLE API 332 (FIG. 3A). The query is programmed into the application by a user at a user terminal 118 (FIG. 1) or at a console (not shown) coupled to client server 116”).
Moriconi does not but Krishnamurthy teaches:
to the local API-authorizing agent through a network stack (see e.g. Krishnamurthy, paragraph 202: “the GI agent 2150 interacts with the network stack and/or process subsystem in the VM's OS kernel space to collect contextual attributes regarding a process or network event”)
the local API-authorizing agent executing on the machine on the first computer (see e.g. Krishnamurthy, paragraph 63: “the GI agents of the VMs on a host”; paragraph 117: “Upon occurrence of a new network connection event, the GI agent 2150 receives a callback from an operating system (OS) of the corresponding VM 114 and, based on this callback, provides a network event identifier to the context engine 2110”; and paragraph 119: “the OS of the VM 114 delays transmission of a new network event (e.g., does not start sending data messages for the network event) until the GI agent 2150 directs the OS to proceed with processing of the network event”)
Moriconi and Krishnamurthy are analogous art because they are in the same field of endeavor: policy-based communication security management. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Moriconi with the teachings of Krishnamurthy. The motivation/suggestion would be to improve load balancing traffic by collecting user and/or process context (see e.g. Krishnamurthy, paragraph 84).
With respect to claim 9, Moriconi as modified teaches: The method of claim 1 further comprising, at the second computer:
receiving the definitions for the plurality of authorization policies for a plurality of API calls to the applications (see e.g. Moriconi, paragraph 47: “Each client server 116 hosts various components or resources, stores a set of rules of the policy received through the network from policy manager server 112, and enforces the set of rules for components or resources. The set of rules received through the network is otherwise known as a local client security policy”; and paragraph 54: “An authorization policy preferably comprises four components, including objects, subjects, privileges, and conditions. Objects may be applications, or the operations within an application. Examples of objects include applications or methods, web pages, database tables or files, and menu items in a graphical user interface”) executing on the first computer (see e.g. Moriconi, paragraph 17: “a policy may contain thousands of rules, applications and users. In a distributed system, these applications and users may be scattered through many geographically separated locations, which are connected to each other through a network”; and Fig. 1), the first plurality of additional computers (see e.g. Moriconi, paragraph 17: “a policy may contain thousands of rules, applications and users. In a distributed system, these applications and users may be scattered through many geographically separated locations, which are connected to each other through a network”; and Fig. 1), and the second plurality of additional computers (see e.g. Moriconi, paragraph 17: “a policy may contain thousands of rules, applications and users. In a distributed system, these applications and users may be scattered through many geographically separated locations, which are connected to each other through a network”; and Fig. 1);
collecting, …the parameters for evaluating the authorization policies to assess whether API calls should be authorized or rejected (see e.g. Moriconi, paragraph 76: “Authorization engine 316 grants or denies access to securable components of client server 116, as specified by the set of rules in the local client security policy, which is stored in local client policy (database) 318. For example, securable components of client server 116 can include applications, data, and/or objects”); and
storing the defined authorization policies and the collected parameters in the single hierarchical storage document from which the policies and associated set of parameters are retrieved to evaluate whether API calls made to applications on the first computer and the first plurality of additional computers should be authorized (see e.g. Moriconi, paragraph 139: “policy data designed according to the policy model, which includes rule inheritance, object hierarchy, role hierarchy, and other interrelationships between policy components”; paragraph 152: “objects hierarchy in reference to an organizational chart in a fictitious stocking trading company. In FIG. 15, four organization nodes are arranged in two layers, namely, "global," "trading," "human resources," and "payroll." Each organization node at the second layer is associated with one or more applications (i.e. t1, t2, and t3; h1 and h2; or p1). Each application is associated with one or more resources nodes. For example, if an application node is an intranet management application, the associated resources can be web pages; or if an application node is a database, the associated resources can be database table views”; paragraph 167; paragraph 17: “a policy may contain thousands of rules, applications and users. In a distributed system, these applications and users may be scattered through many geographically separated locations, which are connected to each other through a network”; and Fig. 1).
Moriconi does not but Garg teaches:
from the second set of sources (see e.g. Garg, paragraph 26: “application administrator defines role-based user permissions through authorization manager 108, which are stored in authorization policy store 104”;),
Moriconi and Garg are analogous art because they are in the same field of endeavor: enforcing authorization policies for applications executing on a computer. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Moriconi with the teachings of Garg. The motivation/suggestion would be to provide an improved administration for the authorization policies; thus improving the overall authorization process management.
With respect to claim 21, Moriconi as modified teaches: The method of claim 1, wherein:
the first set of sources from which the authorization policy definitions are received comprises a user interface (see e.g. Moriconi, paragraph 78: “management station 212 preferably includes a graphical user interface (GUI) 410 for users to create or customize policy rules”); and
the second set of sources from which the parameters for evaluating the authorization policies are collected comprises a set of data sources executing in a datacenter (see e.g. Moriconi, paragraph 47: “System 100 comprises a policy manager server 112, n client servers 116.1, 116.2, . . . , through 116.n, m user terminals 118.1, 118.2, . . . , through 118.m, and a location service 120. The policy manager server 112, n client servers 118.1, 118.2, . . . , 118.n, m user terminals 118.1, 118.2, . . . , 118.m, and location service 120 are coupled to each other through a network 114. Policy manager server 112 contains a global security policy that includes a plurality of policy rules and can distribute the various policy rules to the n client servers. Each client server 116 hosts various components or resources, stores a set of rules of the policy received through the network from policy manager server 112, and enforces the set of rules for components or resources”) along with the first computer, second computer, and first and second pluralities of additional computers (see e.g. Moriconi, paragraph 47: “System 100 comprises a policy manager server 112, n client servers 116.1, 116.2, . . . , through 116.n, m user terminals 118.1, 118.2, . . . , through 118.m, and a location service 120. The policy manager server 112, n client servers 118.1, 118.2, . . . , 118.n, m user terminals 118.1, 118.2, . . . , 118.m, and location service 120 are coupled to each other through a network 114”; and Fig. 1).
With respect to claim 22, Moriconi as modified teaches: The method of claim 21,
Moriconi does not but Garg teaches:
wherein the set of data sources comprises a plurality of LDAP directories in the datacenter (see e.g. Garg, paragraph 41: “access a domain controller to execute an LDAP query that may be associated with an application group object”).
Moriconi and Garg are analogous art because they are in the same field of endeavor: enforcing authorization policies for applications executing on a computer. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Moriconi with the teachings of Garg. The motivation/suggestion would be to provide an improved administration for the authorization policies; thus improving the overall authorization process management.
With respect to claim 23, Moriconi as modified teaches: The method of claim 21, wherein the hierarchical storage document is a first hierarchical storage document (see e.g. Moriconi, paragraph 75: “a local client security policy (data file”), the method further comprising:
distributing a second hierarchical storage document to [a first local API-authorizing agent executing on] a third computer (see e.g. Moriconi, Fig. 1: “Client Server 1 Applications 116.1… Client Server n Applications 116.n”) [for the first local API-authorizing agent] to use API-authorization policies and associated parameters stored in the second hierarchical storage document to authorize and reject API calls made to a first set of one or more applications executing on the third computer (see e.g. Moriconi, paragraph 82: “An optimizer program 462 within distributor 214 then determines which application guard 310 needs to receive which policy rules (based on the local client security policy stored in each application guard). A differ program 464 determines what types of changes were made to optimized policy 222, and then distributes only changes to the relevant policy rules (or local client security policy 318) through a database connectivity layer such as ODBC 440 and a communication interface 442 to the appropriate application guard 310 (FIG. 3), which enforces access control to local applications 312 and data”; paragraph 83: “the application guards 310 can be distributed among various clients or client servers 116, and each application guard 310 has its own specific local client security policy 318”; and Fig. 1); and
distributing a third hierarchical storage document to [a second local API-authorizing agent executing on] a fourth computer (see e.g. Moriconi, Fig. 1: “Client Server 1 Applications 116.1… Client Server n Applications 116.n”) [for the second local API-authorizing agent] to use API- authorization policies and associated parameters stored in the third hierarchical storage document to authorize and reject API calls made to a second set of one or more applications executing on the fourth computer (see e.g. Moriconi, paragraph 82: “An optimizer program 462 within distributor 214 then determines which application guard 310 needs to receive which policy rules (based on the local client security policy stored in each application guard). A differ program 464 determines what types of changes were made to optimized policy 222, and then distributes only changes to the relevant policy rules (or local client security policy 318) through a database connectivity layer such as ODBC 440 and a communication interface 442 to the appropriate application guard 310 (FIG. 3)”; paragraph 83: “the application guards 310 can be distributed among various clients or client servers 116, and each application guard 310 has its own specific local client security policy 318”; and Fig. 1).
Moriconi does not but Krishnamurthy teaches:
a first local API-authorizing agent executing on (see e.g. Krishnamurthy, paragraph 63: “GI agents of the VMs”; paragraph 117: “Upon occurrence of a new network connection event, the GI agent 2150 receives a callback from an operating system (OS) of the corresponding VM 114 and, based on this callback, provides a network event identifier to the context engine 2110”)… for the first local API-authorizing agent (see e.g. Krishnamurthy, paragraph 146: “direct the GI agent 2150 of the VM 114 to perform a process-control operation on a process. Examples of such process-control operations include (1) terminating a video conference application that has a particular version number, (2) terminating a browser that is displaying YouTube traffic, (3) terminating applications that have a high threat level score, etc.”; and paragraph 89)
a second local API-authorizing agent executing on (see e.g. Krishnamurthy, paragraph 63: “GI agents of the VMs”; paragraph 117: “Upon occurrence of a new network connection event, the GI agent 2150 receives a callback from an operating system (OS) of the corresponding VM 114 and, based on this callback, provides a network event identifier to the context engine 2110”)… for the second local API-authorizing agent (see e.g. Krishnamurthy, paragraph 146: “direct the GI agent 2150 of the VM 114 to perform a process-control operation on a process. Examples of such process-control operations include (1) terminating a video conference application that has a particular version number, (2) terminating a browser that is displaying YouTube traffic, (3) terminating applications that have a high threat level score, etc.”; and paragraph 89)
Moriconi and Krishnamurthy are analogous art because they are in the same field of endeavor: policy-based communication security management. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Moriconi with the teachings of Krishnamurthy. The motivation/suggestion would be to improve load balancing traffic by collecting user and/or process context (see e.g. Krishnamurthy, paragraph 84).
With respect to claim 24, Moriconi as modified teaches: The method of claim 23, wherein the second and third hierarchical storage documents store different sets of API-authorization policies based on different applications executing on the third and fourth computers (see e.g. Moriconi, paragraph 82: “A differ program 464 determines what types of changes were made to optimized policy 222, and then distributes only changes to the relevant policy rules (or local client security policy 318)”; paragraph 83: “the application guards 310 can be distributed among various clients or client servers 116, and each application guard 310 has its own specific local client security policy 318”; and paragraph 88: “policy rules developed at policy manager 210 are compiled into an optimized form before changes to the sets of policy rules forming the various local client security policies are distributed to the target application guards 310. The optimized form enables the distribution of only the modified portions of the various local client security policies to the target application guards 310. This distribution methodology, among other things, facilitates updating the versions of the local client security policies enforced by the application guards 310”).
With respect to claim 25, Moriconi as modified teaches: The method of claim 23, wherein the second and third hierarchical storage documents comprise different subsets of the first hierarchical storage document stored at the second computer (see e.g. Moriconi, paragraph 82: “A differ program 464 determines what types of changes were made to optimized policy 222, and then distributes only changes to the relevant policy rules (or local client security policy 318)”).
With respect to claim 26, Moriconi as modified teaches: The method of claim 4,
Moriconi does not but Krishnamurthy teaches:
wherein the request is received from the local API- authorizing agent as a remote procedure call (RPC) message (see e.g. Krishnamurthy, paragraph 85: “The communication bus between the services 508-518 in the management plane 230 can leverage… remote procedure call (RPC)”).
Moriconi and Krishnamurthy are analogous art because they are in the same field of endeavor: policy-based communication security management. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Moriconi with the teachings of Krishnamurthy. The motivation/suggestion would be to improve communication efficiency.
Response to Arguments
Applicant's arguments filed 12/05/2024 have been fully considered but they are not persuasive. In detail:
(i) Regarding Applicant’s arguments with respect to “Step 2A Prong One” section of the rejections under 35 U.S.C. §101 (Remarks, pages 8-10), consider the following example that shows how a human can perform the identified limitations mentally:
For an API call get(XYZ) from IP address 111, consider the following authorization policy definitions:
Policy 1: For IP address 111, allow API get() calls
Policy 2: For IP address 222, allow API get() calls
Policy 3: For IP address 111, deny API set() calls.
Based on these authorization policy definitions, Policy 1 and Policy 3 are applicable to this particular IP address. Furthermore, Policy 1 indicates, the particular API call should be authorized since it is a “get()” call.
Note that, by considering the above example, a person of ordinary skill in the art mentally performs extracting at least one API policy applicable to the API call, analyze corresponding policy definitions and parameters (e.g. IP address, type of API call, etc.), and determines whether to allow or deny the API call.
That is, determining whether to authorize or deny an API call by evaluating policies and parameters, and making a corresponding decision can be performed mentally; such as reading through a corresponding algorithm, or analyzing a corresponding pseudo-code, etc.
The Examiner notes that, these limitations are directed to merely analyzing information regarding the API calls and authorization policies and making a decision accordingly; these limitations identify no details regarding actual API calls and/or require an actual execution of a particular API call. They are merely directed to making an authorization decision.
As such, the limitations “to determine whether an API call received by the application is authorized”, “extracting at least one API-authorization policy applicable to the API call received by the application and a first set of parameters for evaluating the API-authorization policy”, “(i) definitions, from a first set of sources, for a plurality of authorization policies for a plurality of API calls to applications executing on the first computer and the first plurality of additional computers and (ii) parameters, collected from a second set of sources different than the first set of sources, to evaluate the authorization policies to assess whether API calls made to the applications should be authorized or rejected”, “using the identified first set of parameters to evaluate the identified API- authorization policy in order to determine that the API call should be approved”, “determining that the API call should be approved” identified in Step 2A Prong One section can be performed mentally by a human and are directed to an abstract idea.
(ii) Regarding Applicant’s arguments with respect to “Step 2A Prong Two” section of the rejections under 35 U.S.C. §101 (Remarks, pages 10-12),
However, note that the Example 38 highlighted by the Applicant specifically utilizes the state of the hardware components (i.e. memory allocation) whereas the instant application makes no such consideration; the API call authorization process is not tied to any specific type of hardware component and/or state of hardware components.
That is, the limitation “an application executing on a first computer” is no more than an attempt to generally link the use of the judicial exception into a computing technological environment or field of use since this limitation provides no details regarding the application, execution process of the application, the computer, and/or any other hardware specific details (e.g. specific memory allocations, processing speed, etc.). Such attempts are identified by the courts as failing to incorporate judicial exceptions into a practical application in a meaningful manner. See MPEP §2106.05(h).
Further note that, the “extracting” process and the authorization process (i.e. the limitations “to determine whether an API call received by the application is authorized”, “using the identified first set of parameters to evaluate the identified API-authorization policy in order to determine that the API call should be approved”, “determining that the API call should be approved”) are not considered as one of the additional elements, but as a part of the judicial exception in the form of a mental process; extracting/observing information and making a corresponding authorization decision can be performed mentally as explained above under item (i).
Even further, the other additional elements (i.e. the limitations “at a second computer that receives requests to authorize API calls from the first computer and a first plurality of additional computers”, “receiving, from the first computer, a request”, “after an authentication operation is performed on the API call at the first computer to determine that the API call is from a source that is allowed to make such a call to the application”, “from a single hierarchical storage document stored on the second computer… the single hierarchical storage document stores”, “sending a response to the first computer to authorize the API call after”, and “the second computer further distributes hierarchical storage documents storing defined policies and parameters to a second plurality of additional computers for local agents executing on the second plurality of additional computers to use the hierarchical storage documents to authorize or reject API calls made to applications executing on the second plurality of additional computers”) are directed to data transmission and data retrieval operations in general without any details regarding how these communications are implemented, how the data retrieval operations are implemented, and/or how these elements are specifically utilized for the authorization process.
Accordingly, these additional elements don’t go any further than tangential additions to the judicial exception.
Consequently, the Examiner maintains the rejections under 35 U.S.C. §101 directed to claim 1. For more details, please see the corresponding rejection above.
(iii) Regarding the rejections under 35 U.S.C. §103, Applicants argue that Moriconi in view of Garg fails to teach the limitation “the single hierarchical storage document stores (i) definitions, from a first set of sources, for a plurality of authorization policies for a plurality of API calls to applications executing on the first computer and the first plurality of additional computers and (ii) parameters, collected from a second set of sources different than the first set of sources, to evaluate the authorization policies to assess whether API calls made to the applications should be authorized or rejected” as recited (Remarks, pages 12-14).
However, Moriconi discloses a security policy file stored locally on the client server that defines hierarchies (see e.g. Moriconi, paragraph 75: “a local client security policy (data file”; paragraph 139: “policy data designed according to the policy model, which includes rule inheritance, object hierarchy, role hierarchy, and other interrelationships between policy components”; paragraph 150: “role hierarchy and rule inheritance”; paragraph 152: “objects hierarchy”; and Fig. 14-15).
That is, Moriconi teaches a “single hierarchical storage document”.
Moriconi also discloses the security policy file comprising parameters regarding rule inheritance, object hierarchy and role hierarchy; for example a “junior trader” parameter, a “senior trader” parameter, etc. as shown in Fig. 14; which are then used for authorizing or denying API calls (see e.g. Moriconi, paragraph 153: “When processing a policy inquiry, the system considers the rule inheritance, object hierarchy and role hierarchy as shown in FIGS. 14 and 15. The results present rules that match the given privilege, object, and subject in a query request”).
That is, Moriconi teaches the security policy file (i.e. the single hierarchical storage document) storing “parameters… to evaluate the authorization policies to assess whether API calls made to the applications should be authorized or rejected”.
Moriconi further discloses these security policy files, which includes the corresponding parameters, being defined by various enterprises (i.e. a set of sources) (see e.g. Moriconi, paragraph 11: “A real-world security policy that spans a large enterprise, otherwise known as an enterprise or global security policy, uses a detailed and dynamic knowledge base specific to that enterprise. The authorization privileges are specific to the constantly evolving sets of users, applications, partners, and global policies that the enterprise puts in place to protect its key information resources. A security policy that spans a large enterprise can consist of tens or hundreds of thousands of individual rules that cover which users are authorized to access particular applications, perform various operations, or manage the delegation and transfer of tasks. Many of these policy rules that implement the business practice of an organization have to be hard-coded within custom-built applications or stored in a database”; and paragraph 12: “the policy rules that make up an enterprise… policy implementation at the department level”).
On the other hand, Moriconi does not explicitly disclose the security policy file having “definitions”.
However, Garg discloses an authorization policy store storing authorization objects and relationships between these objects (i.e. authorization definitions) (see e.g. Garg, paragraph 29: “Authorization policy store 104 stores data that represents authorization objects and relationships between those objects. The objects and relationships define which users are authorized to perform which operations in association with one or more applications”).
That is, Garg discloses storing authorization policy definitions.
Garg further discloses different levels of administrators (i.e. different sources) that manage definitions and parameters, such as an application administrator defining user permission parameters whereas higher level administrators defining the entire authorization objects and policies (see e.g. Garg, paragraph 26: “application administrator defines role-based user permissions through authorization manager 108, which are stored in authorization policy store 104”; and paragraph 317: “delegation of administration at the authorization store… Support for delegation allows higher level administrators to give limited access to others to manage some subset of the data stored in authorization policy store 104… each authorization store object, application object, and scope object can have an associated list of administrators and an associated list of readers. Administrators are able to perform all operations on objects in the authorization policy while readers only have read access to the objects in the authorization policy store”).
That is, Garg discloses different sources for defining authorization parameters and authorization policy definitions.
Consequently, Moriconi in view of Garg teaches the limitation “the single hierarchical storage document stores (i) definitions, from a first set of sources, for a plurality of authorization policies for a plurality of API calls to applications executing on the first computer and the first plurality of additional computers and (ii) parameters, collected from a second set of sources different than the first set of sources, to evaluate the authorization policies to assess whether API calls made to the applications should be authorized or rejected” as recited in claim 1, and the Examiner maintains the corresponding rejection. For more details, please see the rejection directed to claim 1 above.
(iv) Regarding the rejections under 35 U.S.C. §103, Applicants argue that Moriconi fails to teach the limitations “a second computer that receives requests to authorize API calls from the first computer” and “from a single hierarchical storage document stored on the second computer, extracting at least one API-authorization policy” as recited (Remarks, pages 14-15).
However, Moriconi discloses an authorization engine 316 executing on a client server 116 (i.e. a second computer) that receives requests to authorize API calls from an application guard 512 for an application 312 executing on a client computer (i.e. a first computer) (see e.g. Moriconi, paragraph 87: “authorization engine 316 and local client policy 318 can be located on client server 116”; paragraph 76: “Authorization engine 316 grants or denies access to securable components of client server 116”; and paragraph 169: “performing a back-end policy analysis at a client server 116 for a query issued at an application”; and Fig. 3).
That is, Moriconi discloses a client server 116 that receives requests to authorize API calls from the client.
As such, Moriconi teaches the limitation “a second computer that receives requests to authorize API calls from the first computer”.
Moriconi further discloses a security policy file stored locally on the client server that defines hierarchies (see e.g. Moriconi, paragraph 75: “a local client security policy (data file”; paragraph 139: “policy data designed according to the policy model, which includes rule inheritance, object hierarchy, role hierarchy, and other interrelationships between policy components”; paragraph 150: “role hierarchy and rule inheritance”; paragraph 152: “objects hierarchy”; and Fig. 14-15).
That is, Moriconi teaches “a single hierarchical storage document stored on the second computer”
This security policy file is used by the authorization engine 316 on the client server to extract information in order to determine whether to authorize or deny an API call (see e.g. Moriconi, paragraph 76: “Authorization engine 316 grants or denies access to securable components of client server 116, as specified by the set of rules in the local client security policy, which is stored in local client policy (database) 318”; paragraph 87: “Application guard 310 also includes at least one authorization engine 316 for evaluating requests from application guard interface 512 as specified by local client security policy 318”; and paragraph 169: “performing a back-end policy analysis at a client server 116 for a query issued at an application”).
That is, Moriconi discloses from the security policy file stored on the client server, extracting an API authorization policy.
As such, Moriconi teaches “from a single hierarchical storage document stored on the second computer, extracting at least one API-authorization policy”.
Consequently, Moriconi teaches the limitations “a second computer that receives requests to authorize API calls from the first computer” and “from a single hierarchical storage document stored on the second computer, extracting at least one API-authorization policy” as recited in claim 1, and the Examiner maintains the corresponding rejection. For more details, please see the rejection directed to claim 1 above.
(v) Regarding the rejections under 35 U.S.C. §103, Applicants argue that Moriconi in view of Krishnamurthy fails to teach the limitations “the second computer further distributes hierarchical storage documents storing defined policies and parameters to a second plurality of additional computers for local agents executing on the second plurality of additional computers” as recited (Remarks, pages 14-15).
However, note that Moriconi discloses a policy manager server 112 that distributes security policies to client server applications 116.1-n (see e.g. Moriconi, paragraph 73: “a distributor program 214 to distribute local client security policies”; and paragraph 47: “Each client server 116 hosts various components or resources, stores a set of rules of the policy received through the network from policy manager server 112, and enforces the set of rules for components or resources. The set of rules received through the network is otherwise known as a local client security policy”).
That is, Moriconi discloses a computer (i.e. policy manager server 112) that “distributes hierarchical storage documents storing defined policies and parameters to a second plurality of additional computers for local agents executing on the second plurality of additional computers”.
Moriconi further discloses bundling these policy distribution and policy management operations on a single computer as an embodiment (see e.g. Moriconi, paragraph 175: “Another alternative embodiment bundles a management system, zero or more engines, and a policy database on a single server and then synchronizes with local policy stores over the network following local authorization requests to the central server”)
As such, it would have been obvious to one of ordinary skill in the art to utilize a single computer that implements both the functions of the policy manager server 112 and a client server 116. The motivation/suggestion for such a modification would be to reduce the workload on the policy manager server 112, such as delegating some of the policy distribution work to a client server while the policy manager server handles the remaining policy distribution; thus improving the overall processing efficiency.
On the other hand, Moriconi does not explicitly disclose “local agents” executing on the client servers for handling security policies.
However, Krishnamurthy discloses local GI agents 2150 that implement process control operations such either allowing processes to proceed with their execution or terminating processes based on threat levels (see e.g. Krishnamurthy, paragraph 117: “Upon occurrence of a new network connection event, the GI agent 2150 receives a callback from an operating system (OS) of the corresponding VM 114 and, based on this callback, provides a network event identifier to the context engine 2110”; paragraph 119: “the OS of the VM 114 delays transmission of a new network event (e.g., does not start sending data messages for the network event) until the GI agent 2150 directs the OS to proceed with processing of the network event”; paragraph 146: “direct the GI agent 2150 of the VM 114 to perform a process-control operation on a process. Examples of such process-control operations include (1) terminating a video conference application that has a particular version number, (2) terminating a browser that is displaying YouTube traffic, (3) terminating applications that have a high threat level score, etc.”; and paragraph 89).
That is, the GI agent 2150 implements an authorization process.
Consequently, Moriconi in view of Krishnamurthy teaches the limitation “the second computer further distributes hierarchical storage documents storing defined policies and parameters to a second plurality of additional computers for local agents executing on the second plurality of additional computers” as recited in claim 1, and the Examiner maintains the corresponding rejection. For more details, please see the rejection directed to claim 1 above.
(vi) Applicant’s arguments with respect to claims 4-9, 11, 14-19, and 21-26 are fully considered; however, in view of the above discussions, they are not found to be persuasive. Consequently, the Examiner maintains the rejections directed to claims 4-9, 11, 14-19, and 21-26 are. For details, please see the corresponding rejections above.
CONCLUSION
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Stahlberg et al. (US 2018/0367311 A1) discloses a plurality of delegated authorizers each including a security policy to evaluate and authorize API calls (see paragraph 61).
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Umut Onat whose telephone number is (571)270-1735. The examiner can normally be reached M-Th 9:00-7:30.
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, Kevin L Young can be reached on (571) 270-3180. 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.
/UMUT ONAT/Primary Examiner, Art Unit 2194
Prosecution Insights