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 .
Status of Claims
2. This Office Action is issued in response to the claims filed on 09/30/2024.
Claims 1-12 are pending in this Office Action.
Priority
3. Acknowledgement is made of applicant’s continuation claim of application of U.S. Patent Application 18/211,537, filed June 19, 2023. U.S. Patent Application 18/211,537 is a continuation of U.S. Patent Application 16/834,200, filed March 30, 2020. U.S. Patent Application 16/834,200 claims the benefit of U.S. Provisional Patent Application 62/827,155, filed March 31, 2019. U.S. Patent Application 16/834,200 is a continuation-in-part application of U.S. Patent Application 16/050,123, filed July 31, 2018, now issued as U.S. Patent 11,496,517. U.S. Patent Application 16/050,123 claims the benefit of U.S. Provisional Patent Application 62/545,458, filed August 14, 2017 and U.S. Provisional Patent Application 62/540,547, filed August 2, 2017. U.S. Patent Application 18/211,537 and 16/834,200.
Information Disclosure Statement
4. The information disclosure statement (IDS) submitted on 09/30/2025 has been considered by the Examiner.
Double Patenting
5. The nonstatutory 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 nonstatutory 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 nonstatutory 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 USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The 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 eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
6. Claims 1-12 of the instant application are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-6 and 13-18 of U.S. Patent No. 11,681,568 respectively. Although the claims at issue are not identical, they are not patentably distinct from each other because claims 1-12 of the instant application are anticipated by claims 1-6 and 13-18 of U.S. Patent No. 11,681,568 respectively (Please see table below).
Instant Application 18/902,870
US Patent 11,681,568
1. A method of authorizing application programming interface (API) calls on a host computer in a local cluster of computers, the method comprising:
at an API-authorizing agent executing on the host computer in the local computer cluster,
receiving, from a remote cluster of computers, (i) a set of API-authorizing policies to evaluate in order to determine whether API calls to an application executing on the host computer are authorized, and (ii) a set of parameters needed for evaluating the policies;
registering, with the remote cluster of computers, for notifications regarding updates to the set of parameters;
receiving notifications, from the remote cluster, regarding an update to the set of parameters;
updating the set of parameters based on the update.
1. A method of authorizing application programming interface (API) calls on a host computer in a local cluster of computers, the method comprising:
at an API-authorizing agent executing on the host computer in the local computer cluster:
receiving, from a remote cluster of computers, (i) a set of API-authorizing policies to evaluate in order to determine whether API calls to an application executing on the host computer are authorized and (ii) a first set of parameters needed for evaluating the policies;
registering, with the remote cluster of computers, for notifications regarding updates to the first set of parameters;
receiving notifications, from the remote cluster of computers, regarding an update to the first set of parameters;
updating the first set of parameters based on the update;
receiving a second set of parameters from a set of one or more computers in the local cluster of computers, the second parameter set needed for evaluating one or more policies in the received policy set; and receiving updates to the second set of parameters from the set of computers in the local cluster of computers.
2. The method of claim 1, wherein the notification includes the update.
2. The method of claim 1, wherein the notification includes the update.
3. The method of claim 1 further comprising directing the remote cluster to provide the update after receiving the notification regarding the update.
3. The method of claim 1 further comprising directing the remote cluster of computers to provide the update after receiving the notification regarding the update.
4. The method of claim 1, wherein the remote cluster comprises two or more computers that serve as a logically centralized set of servers for distributing policies and parameters needed for evaluating the policies.
4. The method of claim 1, wherein the remote cluster of computers comprises two or more computers that serve as a logically centralized set of servers for distributing policies and parameters needed for evaluating the policies.
5. The method of claim 4, wherein the policies are policy opcodes for execution and the parameters are policy operands needed for the execution of the policy opcodes.
5. The method of claim 4, wherein the policies are policy opcodes for execution and the parameters are policy operands needed for the execution of the policy opcodes.
6. The method of claim 1 further comprising periodically polling the remote cluster to retrieve the set of parameters needed for the received set of policies, said periodic polling supplementing the registered notifications to account for discrepancy between state of parameter set at the host computer and the state of parameter set at the remote cluster due to a loss of one or more notifications from the remote cluster.
6. The method of claim 1 further comprising periodically polling the remote cluster of computers to retrieve the set of parameters needed for the received set of policies, said periodic polling supplementing the registered notifications to account for discrepancy between state of parameter set at the host computer and the state of parameter set at the remote cluster of computers due to a loss of one or more notifications from the remote cluster of computers.
7. A non-transitory machine readable medium storing an API (application programming interface) authorizing agent for a host computer in a local cluster of computers, the agent for execution by at least one processing unit and comprising sets of instructions for:
receiving, from a remote cluster of computers, (i) a set of API-authorizing policies to evaluate in order to determine whether API calls to an application executing on the host computer are authorized, and (ii) a set of parameters needed for evaluating the policies;
registering, with the remote cluster of computers, for notifications regarding updates to the set of parameters;
receiving notifications, from the remote cluster, regarding an update to the set of parameters;
updating the set of parameters based on the update.
13. A non-transitory machine readable medium storing an API (application programming interface) authorizing agent for a host computer in a local cluster of computers, the agent for execution by at least one processing unit and comprising sets of instructions for:
receiving, from a remote cluster of computers, (i) a set of API-authorizing policies to evaluate in order to determine whether API calls to an application executing on the host computer are authorized and (ii) a first set of parameters needed for evaluating the policies;
registering, with the remote cluster of computers, for notifications regarding updates to the first set of parameters;
receiving notifications, from the remote cluster of computers, regarding an update to the first set of parameters;
updating the first set of parameters based on the update;
receiving a second set of parameters from a set of one or more computers in the local cluster of computers, the second parameter set needed for evaluating one or more policies in the received policy set; and
receiving updates to the second set of parameters from the set of computers in the local cluster of computers.
8. The non-transitory machine readable medium of claim 7, wherein the notification includes the update.
14. The non-transitory machine readable medium of claim 13, wherein the notification includes the update.
9. The non-transitory machine readable medium of claim 7, wherein the agent further comprises a set of instructions for directing the remote cluster to provide the update after receiving the notification regarding the update.
15. The non-transitory machine readable medium of claim 13, wherein the agent further comprises a set of instructions for directing the remote cluster of computers to provide the update after receiving the notification regarding the update.
10. The non-transitory machine readable medium of claim 7, wherein the remote cluster comprises two or more computers that serve as a logically centralized set of servers for distributing policies and parameters needed for evaluating the policies.
16. The non-transitory machine readable medium of claim 13, wherein the remote cluster of computers comprises two or more computers that serve as a logically centralized set of servers for distributing policies and parameters needed for evaluating the policies.
11. The non-transitory machine readable medium of claim 10, wherein the policies are policy opcodes for execution and the parameters are policy operands needed for the execution of the policy opcodes.
17. The non-transitory machine readable medium of claim 16, wherein the policies are policy opcodes for execution and the parameters are policy operands needed for the execution of the policy opcodes.
12. The non-transitory machine readable medium of claim 7, wherein the agent further comprises a set of instructions for periodically polling the remote cluster to retrieve the set of parameters needed for the received set of policies, said periodic polling supplementing the registered notifications to account for discrepancy between state of parameter set at the host computer and the state of parameter set at the remote cluster due to a loss of one or more notifications from the remote cluster.
18. The non-transitory machine readable medium of claim 13, wherein the agent further comprises a set of instructions for periodically polling the remote cluster of computers to retrieve the set of parameters needed for the received set of policies, said periodic polling supplementing the registered notifications to account for discrepancy between state of parameter set at the host computer and the state of parameter set at the remote cluster of computers due to a loss of one or more notifications from the remote cluster of computers.
Claim Objections
7. Claim 1 and 7 recite: “receiving, from a remote cluster of computers…; registering, with the remote cluster of computers…; receiving notifications, from the remote cluster…”
Claims 3-4, 6, 9-10, and 12 recite: “…the remote cluster…”
For purpose of consistency and clarity, Examiner suggests changing the term ‘remote cluster’ to ‘remote cluster of computers’.
Claim Rejections - 35 USC § 103
8. 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.
9. Claims 1-4 and 7-10 are rejected under 35 U.S.C. 103 as being unpatentable over Surcouf et al. (US 2019/0020665), hereinafter “Surcouf”, in view of Beckman et al. (US 2019/0230130), hereinafter “Beckman”.
Regarding claim 1, Surcouf discloses a method of authorizing application programming interface (API) calls on a host computer in a local cluster of computers, the method comprising:
at an API-authorizing agent executing on the host computer in the local computer cluster (Fig. 1 with associated text and paragraphs [0027]-[0029]: Enforcement agent 140), receiving, from a remote cluster of computers (Fig. 1 with associated text: Container Orchestration Engine) , (i) a set of API-authorizing policies to evaluate in order to determine whether API calls to an application executing on the host computer are authorized, and (ii) a set of parameters needed for evaluating the policies (paragraphs [0024], [0028], [0042]-[0043]: policies authorizing API calls associated to pairs of containers are corresponding to (i) and lists of allowed/permitted API calls/requests are corresponding to (ii));
Surcouf discloses registering to receive policies (paragraph [0042]). Surcouf does not explicitly disclose registering, with the remote cluster of computers, for notifications regarding updates to the set of parameters; receiving notifications, from the remote cluster, regarding an update to the set of parameters; updating the set of parameters based on the update. However, registering with a remote system for policy updates and receiving notifications regarding policy updates from the remote system are known in the art and Beckman’s teaching is an example (paragraphs [0069]-[0070]: registering/enrolling for notification services; paragraphs [0028]-[0029] and [0068]: receiving update notification from backend system. Fig. 1 with associated text: backend system including plurality of computers is remote from client device).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Surcouf’s teaching API-authorizing agent utilizing policies with Beckman’s teaching of registering for policy updates and receiving notifications regarding policy updates from remote system because the result would be predictable and resulted in registering, with the remote cluster of computers, for notifications regarding updates to the set of parameters; receiving notifications, from the remote cluster, regarding an update to the set of parameters.
Regarding claim 2, Surcouf and Beckman disclose the method of claim 1, wherein the notification includes the update (Surcouf, paragraph [0028]: broadcasting update).
Regarding claim 3, Surcouf and Beckman disclose the method of claim 1 further comprising directing the remote cluster to provide the update after receiving the notification regarding the update (Beckman, paragraphs [0029] and [0033]-[0036]: receiving update after notification).
Regarding claim 4, Surcouf and Beckman disclose the method of claim 1, wherein the remote cluster comprises two or more computers that serve as a logically centralized set of servers for distributing policies and parameters needed for evaluating the policies (Surcouf, paragraphs [0024] and [0047]: Container Orchestration Engine operates as a central management system to manage policies. Beckman, Fig.1 with associated text and paragraph [0008]: backend systems manage rules. The combination of Surcouf and Beckman’s teachings would have an obvious and predictable result of the remote cluster comprises two or more computers that serve as a logically centralized set of servers for distributing policies and parameters needed for evaluating the policies).
Claims 7-10 claim similar subject matters to claims 1-4 respectively; therefore, claims 7-10 are rejected at least for the same reasons as claims 1-4 respectively.
10. Claims 5 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Surcouf et al. (US 2019/0020665), hereinafter “Surcouf”, in view of Beckman et al. (US 2019/0230130), hereinafter “Beckman” and in view of Jiang (US 10,719,448), hereinafter “Jiang”.
Regarding claim 5, Surcouf and Beckman disclose the method of claim 4. Surcouf and Beckman do not explicitly disclose wherein the policies are policy opcodes for execution and the parameters are policy operands needed for the execution of the policy opcodes. However, using opcodes and operands in policy execution is known in the art and Jiang’s teaching is an example (Col. 7, line 62- Col. 8, line 20).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Surcouf and Beckman’s teachings of API-authorizing agent registering for policy updates and receiving notifications regarding policy updates from remote system with Jiang’s teaching of using opcodes and operands in policy execution because the result would be predictable and resulted in the policies are policy opcodes for execution and the parameters are policy operands needed for the execution of the policy opcodes.
Claim 11 claims similar subject matters to claim 5; therefore, claim 11 is rejected at least for the same reasons as claim 5.
11. Claims 6 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Surcouf et al. (US 2019/0020665), hereinafter “Surcouf”, in view of Beckman et al. (US 2019/0230130), hereinafter “Beckman” and in view of Paruchuri et al. (US 2019/0109891), hereinafter “Paruchuri”.
Regarding claim 6, Surcouf and Beckman disclose the method of claim 1. Surcouf and Beckman do not explicitly disclose periodically polling the remote cluster to retrieve the set of parameters needed for the received set of policies, said periodic polling supplementing the registered notifications to account for discrepancy between state of parameter set at the host computer and the state of parameter set at the remote cluster due to a loss of one or more notifications from the remote cluster. However, periodically polling remote servers to retrieve updating data is known in the art and Paruchuri’s teaching is an example (paragraph [0073]: “New or updated versions of load balancing criteria 325 and policies 326 may be provisioned or loaded to the EMS 300 synchronously (e.g., where the main system controller 302 periodically polls the remote server(s) 340 for updates)”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Surcouf and Beckman’s teachings of API-authorizing agent registering for policy updates and receiving notifications regarding policy updates from remote system with Paruchuri’s teaching of periodically polling remote servers to retrieve updating data because the result would be predictable and resulted in periodically polling the remote cluster to retrieve the set of parameters needed for the received set of policies, said periodic polling supplementing the registered notifications to account for discrepancy between state of parameter set at the host computer and the state of parameter set at the remote cluster due to a loss of one or more notifications from the remote cluster (note: the limitation “said periodic polling supplementing the registered notifications to account for discrepancy between state of parameter set at the host computer and the state of parameter set at the remote cluster due to a loss of one or more notifications from the remote cluster” is intended use which is an obvious application for periodic polling for policy update).
Claim 12 claims similar subject matters to claim 6; therefore, claim 12 is rejected at least for the same reasons as claim 6.
Prior Art of Record
12. The prior arts made of record and not relied upon are considered pertinent to applicant’s disclosure: See Notice of References Cited.
Conclusion
13. Any inquiry concerning this communication or earlier communications from the examiner should be directed to THANH T LE whose telephone number is (571)270-0279. The examiner can normally be reached on Monday-Thursday 8:00 am - 4:00 pm EST.
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, Farid Homayounmehr can be reached on 571-272-3739. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/THANH T LE/Primary Examiner, Art Unit 2495