DETAILED ACTION
Claims 1, 4, 5, 8, 9, 11, 14-16, 18, 19, 21, and 23 are amended. Claims 2, 3, 10, 12, 13, 17, and 20 are cancelled. Claim 27 is new. Claims 1, 4-9, 11, 14-16, 18, 19, and 21-27 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.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 09/22/2025 has been entered.
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 claims 1 and 11 are fully considered and are satisfactory to overcome the rejections under 35 U.S.C. §101 directed to claims 1, 4-9, 11, 14-16, 18, 19, and 21-26 in the previous Office Action.
Double Patenting
The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on non-statutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a non-statutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based e-Terminal Disclaimer may be filled out completely online using web-screens. An e-Terminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about e-Terminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 4-9, 11, 14-16, 18-19, and 27 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1, 3-5, 7, and 9-11 of U.S. Patent No. 10,990,702 B1.
Instant Application
U.S. Patent No. 10,990,702 B1
Claim
Limitation
Claim
Limitation
1
A method comprising: at a first computer: receiving, from a second computer, a request to determine whether an intercepted application programming interface (API) call intended for an application on the second computer is authorized; identifying, based at least in part on the request, at least one API-authorization policy applicable to the intercepted API call and a first set of parameters for evaluating the API-authorization policy; determining, based at least in part on the identified first set of parameters and the identified at least one API-authorization policy, that the intercepted API call is authorized; and in response to determining that the intercepted API call is authorized, transmitting, to the second computer, a response that authorizes the intercepted API call.
1
A method for enforcing API (Application Programming Interface) authorization policies for an application that executes on a machine executing on a first computer, the method comprising: at a second computer, receiving, from a local API-authorization agent executing separately from the application on the machine executing on the first host computer, a request to determine whether an API call received by the application executing on the first host computer is authorized and should be processed by the application, wherein the application receives the API call, and in response, sends the request to authorize the API call to the local API-authorization agent through a network stack of the machine, and the local API-authorization agent forwards the request to the second computer; based on the received request, identifying at least one API-authorization policy and a first set of parameters for evaluating the API-authorization policy by using a second set of parameters associated with the API call to retrieve the API-authorization policy and the first set of parameters from a single storage structure that stores both API-authorization policies and parameters for evaluating policies; 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 local API-authorization agent that executes on the machine executing on the first computer to authorize the API call after determining that the API call should be approved, wherein the application processes the API call in response to the authorization.
4
The method of claim 1, wherein the request is received from, and the response is sent to, a local API-authorizing agent executing on the second computer.
1
at a second computer, receiving, from a local API-authorization agent executing separately from the application on the machine executing on the first host computer, a request to determine whether an API call received by the application executing on the first host computer is authorized and should be processed by the application, wherein the application receives the API call, and in response, sends the request to authorize the API call to the local API-authorization agent through a network stack of the machine, and the local API-authorization agent forwards the request to the second computer
5
The method of claim 4, wherein the application and the local API-authorizing agent execute on a machine that executes on the second computer.
1
at a second computer, receiving, from a local API-authorization agent executing separately from the application on the machine executing on the first host computer, a request to determine whether an API call received by the application executing on the first host computer is authorized and should be processed by the application, wherein the application receives the API call, and in response, sends the request to authorize the API call to the local API-authorization agent through a network stack of the machine, and the local API-authorization agent forwards the request to the second computer
6
The method of claim 5, wherein the machine is a virtual machine.
3
The method of claim 1, wherein the machine is a virtual machine.
7
The method of claim 5, wherein the machine is a container.
4
The method of claim 1, wherein the machine is a container.
8
The method of claim 5, wherein: another application executing on the machine on the second computer intercepts API call and in response sends a request to authorize the intercepted API call to the local API-authorizing agent through a network stack of the machine; and the local API-authorizing agent executing on the machine on the second computer forwards the request to the first computer.
1
at a second computer, receiving, from a local API-authorization agent executing separately from the application on the machine executing on the first host computer, a request to determine whether an API call received by the application executing on the first host computer is authorized and should be processed by the application, wherein the application receives the API call, and in response, sends the request to authorize the API call to the local API-authorization agent through a network stack of the machine, and the local API-authorization agent forwards the request to the second computer
9
The method of claim 1. further comprising, at the first computer: receiving definitions for a plurality of authorization policies for a plurality of API calls to applications executing on the second computer; collecting a second set of parameters for evaluating the authorization policies to assess whether API calls should be authorized or rejected; and storing the definitions for the plurality of authorization policies and the collected second set of parameters in a single hierarchical storage document from which policies and associated sets of parameters are retrieved to evaluate whether intercepted API calls intended for applications on the second computer are authorized.
5
The method of claim 1 further comprising: at the second computer, receiving definitions for a plurality of authorization policies for a plurality of API calls to the applications; collecting parameters for evaluating the authorization policies to assess whether API calls should be authorized or rejected; and storing the defined authorization policies and collected parameters in a single hierarchical storage structure from which the policies and associated set of parameters are retrieved to evaluate whether API calls should be authorized.
11
A non-transitory machine readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising: receiving, by a first computer, a request to determine whether an intercepted application programming interface (API) call intended for an application on a second computer is authorized; identifying, based at least in part on the request, at least one API-authorization policy applicable to the intercepted API call and a first set of parameters for evaluating the API-authorization policy; determining, based at least in part on the identified first set of parameters and the identified at least one API-authorization policy, that the intercepted API call is authorized; and in response to determining that the intercepted API call is authorized, transmitting, to the second computer, a response that authorizes the intercepted API call.
7
A non-transitory machine readable medium storing a program enforcing API (Application Programming Interface) authorization policies for an application that executes on a machine executing on a first computer, the program for execution by at least one processing unit of a second computer, the program comprising sets of instructions for: receiving, from a local API-authorization agent executing separately from the application on the machine executing on the first host computer, a request to determine whether an API call received by the application executing on the first host computer is authorized and should be processed by the application, wherein the application receives the API call, and in response, sends the request to authorize the API call to the local API-authorization agent through a network stack of the machine, and the local API-authorization agent forwards the request to the second computer; based on the received request, identifying at least one API-authorization policy and a first set of parameters for evaluating the API-authorization policy by using a second set of parameters associated with the API call to retrieve the API-authorization policy and the first set of parameters from a single storage structure that stores both API-authorization policies and parameters for evaluating policies; 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 local API-authorizing agent that executes on the first machine executing on the first computer to authorize the API call after determining that the API call should be approved, wherein the application processes the API call in response to the authorization.
14
The non-transitory machine readable medium of claim 11, wherein the request is received from, and the response is sent to, a local API-authorizing agent executing on the second computer.
7
receiving, from a local API-authorization agent executing separately from the application on the machine executing on the first host computer, a request to determine whether an API call received by the application executing on the first host computer is authorized and should be processed by the application, wherein the application receives the API call, and in response, sends the request to authorize the API call to the local API-authorization agent through a network stack of the machine, and the local API-authorization agent forwards the request to the second computer
15
The non-transitory machine readable medium of claim 14, wherein the application and the local API-authorizing agent execute on a machine that executes on the second computer.
7
receiving, from a local API-authorization agent executing separately from the application on the machine executing on the first host computer, a request to determine whether an API call received by the application executing on the first host computer is authorized and should be processed by the application, wherein the application receives the API call, and in response, sends the request to authorize the API call to the local API-authorization agent through a network stack of the machine, and the local API-authorization agent forwards the request to the second computer
16
The non-transitory machine readable medium of claim 15, wherein the machine comprises at least one of a virtual machine or a container.
9, 10
The non-transitory machine readable medium of claim 7, wherein the machine is a virtual machine.
The non-transitory machine readable medium of claim 7, wherein the machine is a container.
18
The non-transitory machine readable medium of claim 15, wherein: another application executing on the machine on the second computer intercepts the API call and in response sends a request to authorize the intercepted API call to the local API-authorizing agent through a network stack of the machine; and the local API-authorizing agent executing on the machine on the second computer forwards the request to the first computer.
7
receiving, from a local API-authorization agent executing separately from the application on the machine executing on the first host computer, a request to determine whether an API call received by the application executing on the first host computer is authorized and should be processed by the application, wherein the application receives the API call, and in response, sends the request to authorize the API call to the local API-authorization agent through a network stack of the machine, and the local API-authorization agent forwards the request to the second computer
19
The non-transitory machine readable medium of claim 11, wherein the operations further comprise: receiving definitions for a plurality of authorization policies for a plurality of API calls to applications executing on the second computer; collecting a second set of parameters for evaluating the authorization policies to assess whether API calls should be authorized or rejected; and storing the definitions for the plurality of authorization policies and the collected second set of parameters in a single hierarchical storage document from which policies and associated sets of parameters are retrieved to evaluate whether intercepted API calls intended for applications on the second computer are authorized.
11
receiving definitions for a plurality of authorization policies for a plurality of API calls to the applications; collecting parameters for evaluating the authorization policies to assess whether API calls should be authorized or rejected; and storing the defined authorization policies and collected parameters in a single hierarchical storage structure from which the policies and associated set of parameters are retrieved to evaluate whether API calls should be authorized.
With respect to claims 1, 4-9, 11, 14-16, and 18-19: Although the claims at issue are not identical, they are not patentably distinct from each other because claims 1, 3-5, 7, and 9-11 of U.S. Patent No. 10,990,702 B1 anticipates claims 1, 4-9, 11, 14-16, and 18-19 of the instant application.
With respect to claim 27: Claim 27 is directed to a device to perform the method disclosed in claim 1. As such, in view of claims 1 and 7 of U.S. Patent No. 10,990,702 B1, it would have been obvious to one of ordinary skill in the art to realize the device recited in claim 27.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 9, 11, 19, 21, and 27 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Moriconi (US 2003/0115484 A1; from IDS filed on 09/21/2021; hereinafter “Moriconi”).
With respect to claim 1, Moriconi teaches: A method comprising:
at a first computer (see e.g. Fig. 1: “Client Server 116”; Fig. 3A: “Client Server”; and paragraph 24: “server associated with one or more clients (otherwise known as client servers)”):
receiving, from a second computer (see e.g. Fig. 1: “User Terminal 118”; paragraph 46: “a client”), a request to determine whether an intercepted application programming interface (API) call intended for an application (see e.g. paragraph 169: “an application”) on the second computer (see e.g. paragraph 170: “the application by a user at a user terminal 118”; and Fig. 5) is authorized (see e.g. paragraph 169: “performing a back-end policy analysis at a client server 116 for a query issued at an application”; and paragraph 170: “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)”);
identifying, based at least in part on the request, at least one API-authorization policy applicable to the intercepted API call and a first set of parameters for evaluating the API-authorization policy (see e.g. paragraph 171: “upon receiving the query and the parameters, 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”);
determining, based at least in part on the identified first set of parameters and the identified at least one API-authorization policy, that the intercepted API call is authorized (see e.g. paragraph 171: “executes the query against the local client security policy”; 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: “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
in response to determining that the intercepted API call is authorized, transmitting, to the second computer, a response that authorizes the intercepted API call (see e.g. paragraph 57: “Users are authorized to access information in order to perform their job functions. Such access may be controlled so that a user gets access only to the information needed to perform his job function”; paragraph 92: “If the evaluated authorization request does not deny access for the user, then at step 722 access is allowed”; and 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”).
Moriconi discloses a back-end policy analysis at a server, namely “client server” (i.e. a first computer), for authorizing or denying access to a query coming from an application executing on a user terminal (i.e. a client). The client server receives the query from the application on the user terminal via a Business Logic Engine (BLE) API , evaluates parameters included in the query against security rules to determine access privileges of the user as part of the policy analysis, and authorizes the query accordingly. The results of the authorized query are then provided to the user at the user terminal.
With respect to claim 9, Moriconi teaches: The method of claim 1 further comprising, at the first computer:
receiving definitions for a plurality of authorization policies for a plurality of API calls to applications (see e.g. 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 second computer (see e.g. 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. 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 a second set of the parameters for evaluating the authorization policies to assess whether API calls should be authorized or rejected (see e.g. 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 definitions for the plurality of authorization policies and the collected second set of parameters in a single hierarchical storage document from which policies and associated set of parameters are retrieved to evaluate whether intercepted API calls intended for applications on the second computer are authorized (see e.g. 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).
With respect to claims 11 and 19: Claims 11 and 19 are directed to a non-transitory machine readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform operations corresponding to the method disclosed in claims 1 and 9, respectively; please see the rejections directed to clams 1 and 9 above which also cover the limitations recited in claims 11 and 19. Note that Moriconi also discloses machine readable storage media storing instructions to perform operations corresponding to the method disclosed in claims 1 and 9 (see e.g. paragraphs 48-51).
With respect to claim 21, Moriconi as modified teaches: The method of claim 9, further comprising:
receiving the at least one API-authorization policy via a user interface (see e.g. paragraph 78: “management station 212 preferably includes a graphical user interface (GUI) 410 for users to create or customize policy rules”); and
wherein the second set of parameters are collected from a set of data sources executing in a datacenter (see e.g. 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 and the second computer (see e.g. 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 27: Claim 27 is directed to a device comprising memory and at least one processor configured to perform active steps corresponding to the method disclosed in claim 1; please see the rejection directed to claim 1 above which also covers the limitations recited in claim 27. Note that Moriconi also discloses a device comprising memory 134, 136, 138 and a CPU 132 configured to implement the method disclosed in claim 1 (see e.g. Fig. 1A).
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 4-8, 14-16, 18, and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Moriconi in view of Krishnamurthy et al. (US 2018/0295036 A1; from IDS filed on 09/21/2021; hereinafter “Krishnamurthy”).
With respect to claim 4, Moriconi teaches: The method of claim 1, wherein the request is received from, and the response is sent to, …executing on the second 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 second 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 API-authorizing 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:
another application executing on the machine on the second computer intercepts the API call and in response sends a request to authorize the intercepted API call …of the machine (see e.g. Moriconi, Fig. 5: “Application Guard Interface 512”; paragraph 87: “application guard interface 512 (referred to as interface 332 in FIG. 3A), coupled to an application 312, for requesting access to securable components. 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 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 first 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 second 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 claims 14-16 and 18: Claims 14-16 and 18 are directed to a non-transitory machine readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform operations corresponding to the method disclosed in claims 4-8, respectively; please see the rejections directed to clams 4-8 above which also cover the limitations recited in claims 14-16 and 18.
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.
Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Moriconi in view of Garg et al. (US 2004/0083367 A1; hereinafter “Garg”).
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.
Response to Arguments
Applicant's arguments filed 09/22/2025 have been fully considered but they are not persuasive. In detail:
(i) Regarding Applicant’s arguments with respect to the limitation “an API call” (Remarks, pages 12-13), note that Moriconi utilizes a Business Logic Engine (BLE) API 332 that provides an interface for the application to submit queries to the client server (see paragraph 170: “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)”; and paragraph 89: “Engine 602 is the active component of a BLE, which maintains and evaluates entitlement information for application(s). API 604 provides a link between the application(s) and BLE 316”).
As such, Moriconi discloses an API 332 receiving calls (e.g. a query) coming from the application which are then evaluated for authorization.
Therefore, Moriconi teaches the limitation “an API call” as recited in claim 1. For more details, please see the corresponding rejection above.
(ii) Regarding Applicant’s arguments with respect to the limitation “an intercepted” API call (Remarks, page 12), note that in view of the above discussion, Moriconi discloses API calls (e.g. a query) coming from an application. Moriconi further discloses performing a policy analysis for authorizing such calls before they can be executed, such as evaluating parameters of a query before allowing access (see e.g. paragraph 169: “performing a back-end policy analysis at a client server 116 for a query issued at an application”; and paragraph 170: “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)”).
That is, the API calls coming from the application are first evaluated (i.e. intercepted for evaluation) before they can access the necessary resources.
As such, Moriconi teaches the limitation “an intercepted API call” as recited in claim 1. For more details, please see the corresponding rejection above.
Allowable Subject Matter
Claims 23-25 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter:
The limitations recited in claim 23 “distributing a second hierarchical storage document to a first local API-authorizing agent executing on a third computer 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” and “distributing a third hierarchical storage document to a second local API-authorizing agent executing on a fourth computer 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”, in combination with the other limitations recited therewith, introduce subject matter that is novel and non-obvious over the prior art.
CONCLUSION
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Reierson et al. (US 2012/0159570 A1) discloses intercepting an API call and determining if the intercepted API calls is authorized to access corresponding resources (see paragraphs 35-38; and Fig. 5).
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 at (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