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 .
Detailed Action
This is the initial office action that has been issued in response to patent application, 18/613,984, filed on 03/22/2024. Claims 1-20, as originally filed, are currently pending and have been considered below. Claims 1, 11, and 18 are independent claims.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06/06/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Drawings
The drawings filed on 3/22/2024 are accepted by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-5, 11-16, and 18-20 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 11, and 18 recite the limitation "the DLL." There is insufficient antecedent basis for this limitation in the claims since only “a security dynamic link library (DLL)” was defined.
Claims 1, 11, and 18 recite the limitation “… that the API call requires postprocessing; wherein postprocessing comprises synchronous postprocessing …”. The claim language “wherein postprocessing” renders the claims indefinite.
Claims 1 and 11 recite the limitation “… preprocessing, by the security kernel driver, the API call, wherein preprocessing comprises synchronous preprocessing …”. The claim language “wherein preprocessing” renders the claims indefinite.
Claim 2 recites the limitation “… wherein synchronous preprocessing comprises: …”. The claim language “wherein synchronous preprocessing” renders the claim indefinite.
Claim 2 recites the limitation "the protection service." There is insufficient antecedent basis for this limitation in the claim.
Claims 3-5, 13-15, and 19-20 recite the limitation "the security service." There is insufficient antecedent basis for this limitation in the claims.
Claim 12 recites the limitation "the system of claim 11." Claim 11 recites method not system.
Claim 12 recites the limitation “… wherein asynchronous preprocessing comprises: …”. The claim language “wherein asynchronous preprocessing” renders the claim indefinite.
Claim 16 recites the limitation "the first synchronous verdict." There is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Sandoval et al. (US Patent No. US 8,255,931 B2, hereinafter, Sandoval) in view of Fuller et al. (US Patent No. US 8,782,744 B1, hereinafter, Fuller) and further in view of Lukacs (US Patent Application Publication No. US 2018/0004943 A1).
Regarding Claim 1, Sandoval discloses: A method for managing Application Program Interface (API) calls from a client to an API server in a computer system comprising a security kernel driver, the method comprising:
injecting a security dynamic link library (DLL) into the API server, wherein the DLL is configured to monitor API calls related to specific system functions (Sandoval, col 2, line 1-2, “API hooks can be introduced in a variety of ways, either at the source of the call (i.e., the application program) or the target thereof (e.g., the operating system process being called). A particularly powerful method of API hooking involves injecting a dynamic link library (DLL) into the address space of the target program and patching the API with a branch (i.e., JMP) instruction. A DLL is a file containing executable instructions (in the form of subroutines and functions) that can be loaded and executed by a computer program while that program is running.”);
hooking an API call of a client to the API server by the security DLL (Sandoval, col 2, line 1-12, “API hooks can be introduced in a variety of ways, either at the source of the call (i.e., the application program) or the target thereof (e.g., the operating system process being called). A particularly powerful method of API hooking involves injecting a dynamic link library (DLL) into the address space of the target program and patching the API with a branch (i.e., JMP) instruction. A DLL is a file containing executable instructions (in the form of subroutines and functions) that can be loaded and executed by a computer program while that program is running.”);
Sandoval does not explicitly teach the following limitation that Fuller teaches:
analyzing the API call information by the security DLL to determine an identity of the client (Fuller, col 3, line 10-44, “The pre-processor may then use the information contained in request instance and/or the context of the API call variant to determine if the request instance should be processed. In other embodiments, the context may include time of day, IP address, account type, origin of request, destination of request, hostname or other identifiers that may be extrinsically given or intrinsic to the request.”);
impersonating the client by the security DLL to get security rights of the client (Fuller, col 3, line 10-44, “In the embodiment shown, the pre-processor consults 2 an authorization engine 114 to determine if the client 102 has permission to use the API call variant. In some embodiments, the pre-processor 112 may calculate or determine the authorization without consulting an authorization engine 114.”);
prefiltering the API call by the security DLL by evaluating parameters of the API call against a predefined security DLL policy to determine an API call status, wherein the API call is passed to the security kernel driver (Fuller, col 3, line 10-44, “The pre-processor may then use the information contained in request instance and/or the context of the API call variant to determine if the request instance should be processed. … In the embodiment shown, the pre-processor consults 2 an authorization engine 114 to determine if the client 102 has permission to use the API call variant.”);
preprocessing, by the security kernel driver, the API call,
wherein preprocessing comprises synchronous preprocessing (Fuller, col 3, line 10-44, “The pre-processor may then use the information contained in request instance and/or the context of the API call variant to determine if the request instance should be processed. … In the embodiment shown, the pre-processor consults 2 an authorization engine 114 to determine if the client 102 has permission to use the API call variant.”);
executing the API call (Fuller, col 3, line 10-44, “However, if the client has permission to make the request using the API call variant, the request may be communicated 5 to the request service 13 for processing”); and
determining, by the security kernel driver, that the API call requires postprocessing (Fuller, col 4, line 63 - col 5, line 19, “The request processor 108 may invoke the post-processor 118.”);
postprocessing the API call (Fuller, col 4, line 63 - col 5, line 19, “The post-processor 118 may use the response object and client information to query an Authorization Engine 114 as to permissions and information related to response data. Using the permissions and information obtained, the post-processor 118 may verify, modify and/or delete fields and/or data from the response instance 116 as part of the inspection performed by the post-processor 118.”).
Sandoval in view of Fuller is analogous art because the references are from the “same field of endeavor” and are from the same “problem solving area.” Namely, they pertain to the field of “security methods in software development.” It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Sandoval with Fuller to
“analyzing the API call information by the security DLL to determine an identity of the client;
impersonating the client by the security DLL to get security rights of the client;
prefiltering the API call by the security DLL by evaluating parameters of the API call against a predefined security DLL policy to determine an API call status, wherein the API call is passed to the security kernel driver;
preprocessing, by the security kernel driver, the API call,
wherein preprocessing comprises synchronous preprocessing;
executing the API call; and
determining, by the security kernel driver, that the API call requires postprocessing;
postprocessing the API call”;
because, the API may be dynamically managed at the point of request and also at the point of return (Fuller, Abstract).
Sandoval in view of Fuller does not explicitly teach the following limitation that Lukacs teaches:
wherein postprocessing comprises synchronous postprocessing when the parameters of the API call are an immediate risk to the computer system (The limitation “API call” is taught by Sandoval in view of Fuller. Lukacs is not relied upon to teach the limitation of “API call.” Lukacs ¶[0044], “a part of the analysis is performed in a synchronous manner, while another part of the analysis may be performed asynchronously. The term synchronous is used herein to denote a manner of analyzing an event wherein execution of the entity generating the event (herein deemed triggering entity, for simplicity) is suspended while the respective analysis is performed. In contrast to synchronous analysis, asynchronous analysis refers to a manner of analyzing an event, wherein the triggering entity is allowed to continue execution, while the respective event is inserted into an event queue, to be analyzed later on.” ¶[0046], “Synchronous analysis may comprise, for instance, a subset of operations that are critical for assessing the security risk posed by a monitored entity.”);
wherein the postprocessing comprises asynchronous postprocessing when the parameters of the API call do not pose an immediate risk to the computer system (The limitation “API call” is taught by Sandoval in view of Fuller. Lukacs is not relied upon to teach the limitation of “API call.” Lukacs ¶[0044], “a part of the analysis is performed in a synchronous manner, while another part of the analysis may be performed asynchronously. The term synchronous is used herein to denote a manner of analyzing an event wherein execution of the entity generating the event (herein deemed triggering entity, for simplicity) is suspended while the respective analysis is performed. In contrast to synchronous analysis, asynchronous analysis refers to a manner of analyzing an event, wherein the triggering entity is allowed to continue execution, while the respective event is inserted into an event queue, to be analyzed later on.” ¶[0047], “In contrast to synchronous analysis, the operation of asynchronous analysis module 46 is not tied to the execution of the entity triggering the notified event, in the sense that the triggering entity is allowed to continue execution, while the notified event is added to an event queue, for processing at a later time.”); and
Sandoval in view of Fuller and further in view of Lukacs is analogous art because the references are from the “same field of endeavor” and are from the same “problem solving area.” Namely, they pertain to the field of “security methods in software development.” It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Sandoval in view of Fuller with Lukacs to implement synchronous or asynchronous post-processing,
“wherein postprocessing comprises synchronous postprocessing when the parameters of the API call are an immediate risk to the computer system;
wherein the postprocessing comprises asynchronous postprocessing when the parameters of the API call do not pose an immediate risk to the computer system”;
because, synchronous analysis may comprise, for instance, a subset of operations that are critical for assessing the security risk, and in contrast to synchronous analysis, the operation of asynchronous analysis is not tied to the execution of the entity triggering the notified event, in the sense that the triggering entity is allowed to continue execution (Lukacs, ¶[0046-0047]).
Regarding Claim 2, Sandoval in view of Fuller and further in view of Lukacs teaches: The method of claim 1, wherein synchronous preprocessing comprises:
communicating API call modified input parameters to the protection service to get a first synchronous verdict and either (Fuller, col 3, line 10-44, “The pre-processor may then use the information contained in request instance and/or the context of the API call variant to determine if the request instance should be processed. … In the embodiment shown, the pre-processor consults 2 an authorization engine 114 to determine if the client 102 has permission to use the API call variant.” Col 6, line 3-14, “This environment can allow introduction of new input and output parameters to existing API calls as well as creating new API calls.”):
rejecting the API call with modified or unmodified input parameters based on the first synchronous verdict (Fuller, col 3, line 10-44, “Once the authorization has been determined, the pre-processor 112 may report 4 the authorization back to the request processor 108. If the request is not authorized, the request processor may send a response 14 that the API call variant does not exist, even if the API call was syntactically correct. Similarly, malformed API call variants may also be denied as non-existent if permission is denied. This provides protection from discovery of API calls to which a client 102 does not have permission to request.”); or
allowing the API call with modified input parameters to be executed based on the first synchronous verdict to get API call output parameters (Fuller, col 3, line 10-44, “if the client has permission to make the request using the API call variant, the request may be communicated 5 to the request service 13 for processing.” Col 3, line 45-63, “The request service 13 may return 6 information about the processing, such as fields that may be placed in a return instance. The return instance may be constructed based on the context of the API call variant and/or request received.”).
Regarding Claim 3, Sandoval in view of Fuller and further in view of Lukacs teaches: The method of claim 1, wherein the synchronous postprocessing comprises:
communicating API call output parameters to the security service to get a second synchronous verdict (Fuller, col 3, line 45-63, “The request processor may allow the post-processor 118 to inspect and alter the return instance to conform to the expectations of the API call variant. In some embodiments, this may include stripping new fields from the return instance that are not expected to be returned to the client. In other embodiments, this may be altering the return instance to conform to the expected return syntax. In one embodiment, the post-processor 118 may consult 8 an authorization engine 114 to determine 9 which fields the client 102 has permission to receive.”); and
blocking the API call based on the second synchronous verdict (Fuller, col 3, line 45-63, “In some embodiments, this may include stripping new fields from the return instance that are not expected to be returned to the client. In other embodiments, this may be altering the return instance to conform to the expected return syntax. In one embodiment, the post-processor 118 may consult 8 an authorization engine 114 to determine 9 which fields the client 102 has permission to receive. After the post-processor 118 has completed the inspection, the request processor may receive 10 the return information and provide a response 14 to the client 102 using the return information.”).
Regarding Claim 4, Sandoval in view of Fuller and further in view of Lukacs teaches: The method of claim 1, wherein the synchronous postprocessing comprises:
communicating API call output parameters to the security service to get a second synchronous verdict (Fuller, col 3, line 45-63, “In one embodiment, the post-processor 118 may consult 8 an authorization engine 114 to determine 9 which fields the client 102 has permission to receive.”);
adjusting the API call output parameters (Fuller, col 3, line 45-63, “The request processor may allow the post-processor 118 to inspect and alter the return instance to conform to the expectations of the API call variant. In some embodiments, this may include stripping new fields from the return instance that are not expected to be returned to the client. … In one embodiment, the post-processor 118 may consult 8 an authorization engine 114 to determine 9 which fields the client 102 has permission to receive.”); and
allowing the API call with the adjusted output parameters based on the second synchronous verdict (Fuller, col 3, line 45-63, “After the post-processor 118 has completed the inspection, the request processor may receive 10 the return information and provide a response 14 to the client 102 using the return information.”).
Regarding Claim 5, Sandoval in view of Fuller and further in view of Lukacs teaches: The method of claim 1, wherein the asynchronous postprocessing comprises:
communicating API call output parameters to the security service to get a second asynchronous verdict (Fuller, col 3, line 45-63, “In one embodiment, the post-processor 118 may consult 8 an authorization engine 114 to determine 9 which fields the client 102 has permission to receive.”);
monitoring the API call based on the second asynchronous verdict (Lukacs, ¶[0035], “CSA 40 is configured to monitor the behavior of a plurality of executable entities (e.g., processes, threads, applications), and to determine whether any such monitored entity is malicious according to its behavior. Monitored entities may include components of an operating system and user applications, among others.”).
Regarding Claim 6, Sandoval in view of Fuller and further in view of Lukacs teaches: The method of claim 2, wherein the security kernel driver further processes the API call by:
collecting for audit purposes the API call information (Fuller, col 4, line 63 - col 5, line 19, “The API call 106 and/or successful API return 120 may be reported to an auditing system 122.”); and
initiating, by the security kernel driver, a security action based on the first synchronous verdict, wherein the security action initiates a protection mechanism (Lukacs, ¶[0054], “When the synchronous analysis indicates that the currently notified event is indicative of a computer security threat (e.g., is malware-indicative), synchronous analysis module 44 may transmit a security alert 56b to CSA 40.” ¶[0055], “When the event indicates a computer security threat according to a result of the asynchronous analysis, module 46 may transmit a security alert 56a to CSA 40.” ¶[0057] “In response to receiving security alert(s) 56a and/or 56b, computer security application 40 may take protective action against monitored entity 38.”).
Regarding Claim 7, Sandoval in view of Fuller and further in view of Lukacs teaches: The method of claim 1, further comprising initiating, by the security kernel driver, a security action based on the synchronous or the asynchronous postprocessing, wherein the security action is one of:
initiating a protection mechanism (Lukacs, ¶[0057], “In response to receiving security alert(s) 56a and/or 56b, computer security application 40 may take protective action against monitored entity 38. Such protective action may include, among others, suspending execution of, or otherwise incapacitating entity 38, and rolling back a set of changes made to host system 10 as a result of execution of monitored entity 38.”);
executing remediation procedures;
backup of a state requested to be overwritten by the API call; or
triggering a rollback of system changes associated with the API call.
Regarding Claim 8, Sandoval in view of Fuller and further in view of Lukacs teaches: The method of claim 7, wherein the protection mechanism isolates affected system components, alerts system administrators, or updates system security configurations (Lukacs, ¶[0057], “Such protective action may include, among others, suspending execution of, or otherwise incapacitating entity 38, and rolling back a set of changes made to host system 10 as a result of execution of monitored entity 38.”).
Regarding Claim 9, Sandoval in view of Fuller and further in view of Lukacs teaches: The method of claim 7, wherein remediation procedures comprise a rollback comprising reversing the effects of the API call and restoring affected system settings or files to a previous state (Lukacs, ¶[0057], “Such protective action may include, among others, suspending execution of, or otherwise incapacitating entity 38, and rolling back a set of changes made to host system 10 as a result of execution of monitored entity 38.”).
Regarding Claim 10, Sandoval in view of Fuller and further in view of Lukacs teaches: The method of claim 9, wherein rollback comprises reverting system changes made as a result of the API call to a predefined safe state (Lukacs, ¶[0057], “Such protective action may include, among others, suspending execution of, or otherwise incapacitating entity 38, and rolling back a set of changes made to host system 10 as a result of execution of monitored entity 38.”).
Regarding Claim 11, Sandoval discloses: A method for managing Application Program Interface (API) calls from a client to an API server in a computer system comprising a security kernel driver and a protection service, the method comprising:
injecting a security dynamic link library (DLL) into the API server, wherein the DLL is configured to monitor API calls related to specific system functions (Sandoval, col 2, line 1-2, “API hooks can be introduced in a variety of ways, either at the source of the call (i.e., the application program) or the target thereof (e.g., the operating system process being called). A particularly powerful method of API hooking involves injecting a dynamic link library (DLL) into the address space of the target program and patching the API with a branch (i.e., JMP) instruction. A DLL is a file containing executable instructions (in the form of subroutines and functions) that can be loaded and executed by a computer program while that program is running.”);
hooking an API call of a client to the API server by the security DLL (Sandoval, col 2, line 1-12, “API hooks can be introduced in a variety of ways, either at the source of the call (i.e., the application program) or the target thereof (e.g., the operating system process being called). A particularly powerful method of API hooking involves injecting a dynamic link library (DLL) into the address space of the target program and patching the API with a branch (i.e., JMP) instruction. A DLL is a file containing executable instructions (in the form of subroutines and functions) that can be loaded and executed by a computer program while that program is running.”);
Sandoval does not explicitly teach the following limitation that Fuller teaches:
analyzing the API call information by the security DLL to determine an identity of the client (Fuller, col 3, line 10-44, “The pre-processor may then use the information contained in request instance and/or the context of the API call variant to determine if the request instance should be processed. In other embodiments, the context may include time of day, IP address, account type, origin of request, destination of request, hostname or other identifiers that may be extrinsically given or intrinsic to the request.”); and
impersonating the client by the security DLL to get security rights of the client (Fuller, col 3, line 10-44, “In the embodiment shown, the pre-processor consults 2 an authorization engine 114 to determine if the client 102 has permission to use the API call variant. In some embodiments, the pre-processor 112 may calculate or determine the authorization without consulting an authorization engine 114.”);
prefiltering the API call by the security DLL by evaluating parameters of the API call against a predefined security DLL policy to determine an API call status, wherein the API call is passed to the security kernel driver (Fuller, col 3, line 10-44, “The pre-processor may then use the information contained in request instance and/or the context of the API call variant to determine if the request instance should be processed. … In the embodiment shown, the pre-processor consults 2 an authorization engine 114 to determine if the client 102 has permission to use the API call variant.”);
preprocessing, by the security kernel driver, the API call,
wherein preprocessing comprises asynchronous preprocessing (Fuller, col 3, line 10-44, “The pre-processor may then use the information contained in request instance and/or the context of the API call variant to determine if the request instance should be processed. … In the embodiment shown, the pre-processor consults 2 an authorization engine 114 to determine if the client 102 has permission to use the API call variant.”);
executing the API call (Fuller, col 3, line 10-44, “However, if the client has permission to make the request using the API call variant, the request may be communicated 5 to the request service 13 for processing”); and
determining, by the security kernel driver, that the API call requires postprocessing (Fuller, col 4, line 63 - col 5, line 19, “The request processor 108 may invoke the post-processor 118.”);
postprocessing the API call (Fuller, col 4, line 63 - col 5, line 19, “The post-processor 118 may use the response object and client information to query an Authorization Engine 114 as to permissions and information related to response data. Using the permissions and information obtained, the post-processor 118 may verify, modify and/or delete fields and/or data from the response instance 116 as part of the inspection performed by the post-processor 118.”).
Sandoval in view of Fuller is analogous art because the references are from the “same field of endeavor” and are from the same “problem solving area.” Namely, they pertain to the field of “security methods in software development.” It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Sandoval with Fuller to
“analyzing the API call information by the security DLL to determine an identity of the client;
impersonating the client by the security DLL to get security rights of the client;
prefiltering the API call by the security DLL by evaluating parameters of the API call against a predefined security DLL policy to determine an API call status, wherein the API call is passed to the security kernel driver;
preprocessing, by the security kernel driver, the API call,
wherein preprocessing comprises asynchronous preprocessing;
executing the API call; and
determining, by the security kernel driver, that the API call requires postprocessing;
postprocessing the API call”;
because, the API may be dynamically managed at the point of request and also at the point of return (Fuller, Abstract).
Sandoval in view of Fuller does not explicitly teach the following limitation that Lukacs teaches:
wherein postprocessing comprises synchronous postprocessing when the parameters of the API call are an immediate risk to the computer system (The limitation “API call” is taught by Sandoval in view of Fuller. Lukacs is not relied upon to teach the limitation of “API call.” Lukacs ¶[0044], “a part of the analysis is performed in a synchronous manner, while another part of the analysis may be performed asynchronously. The term synchronous is used herein to denote a manner of analyzing an event wherein execution of the entity generating the event (herein deemed triggering entity, for simplicity) is suspended while the respective analysis is performed. In contrast to synchronous analysis, asynchronous analysis refers to a manner of analyzing an event, wherein the triggering entity is allowed to continue execution, while the respective event is inserted into an event queue, to be analyzed later on.” ¶[0046], “Synchronous analysis may comprise, for instance, a subset of operations that are critical for assessing the security risk posed by a monitored entity.”);
wherein the postprocessing comprises asynchronous postprocessing when the parameters of the API call do not pose an immediate risk to the computer system (The limitation “API call” is taught by Sandoval in view of Fuller. Lukacs is not relied upon to teach the limitation of “API call.” Lukacs ¶[0044], “a part of the analysis is performed in a synchronous manner, while another part of the analysis may be performed asynchronously. The term synchronous is used herein to denote a manner of analyzing an event wherein execution of the entity generating the event (herein deemed triggering entity, for simplicity) is suspended while the respective analysis is performed. In contrast to synchronous analysis, asynchronous analysis refers to a manner of analyzing an event, wherein the triggering entity is allowed to continue execution, while the respective event is inserted into an event queue, to be analyzed later on.” ¶[0047], “In contrast to synchronous analysis, the operation of asynchronous analysis module 46 is not tied to the execution of the entity triggering the notified event, in the sense that the triggering entity is allowed to continue execution, while the notified event is added to an event queue, for processing at a later time.”); and
Sandoval in view of Fuller and further in view of Lukacs is analogous art because the references are from the “same field of endeavor” and are from the same “problem solving area.” Namely, they pertain to the field of “security methods in software development.” It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Sandoval in view of Fuller with Lukacs to implement synchronous or asynchronous post-processing,
“wherein postprocessing comprises synchronous postprocessing when the parameters of the API call are an immediate risk to the computer system;
wherein the postprocessing comprises asynchronous postprocessing when the parameters of the API call do not pose an immediate risk to the computer system”;
because, synchronous analysis may comprise, for instance, a subset of operations that are critical for assessing the security risk, and in contrast to synchronous analysis, the operation of asynchronous analysis is not tied to the execution of the entity triggering the notified event, in the sense that the triggering entity is allowed to continue execution (Lukacs, ¶[0046-0047]).
Regarding Claim 12, Sandoval in view of Fuller and further in view of Lukacs teaches: The system of claim 11, wherein asynchronous preprocessing comprises:
execution of the API call with modified or unmodified input parameters to get API call output parameters (Fuller, col 6, line 3-14, “This environment can allow introduction of new input and output parameters to existing API calls as well as creating new API calls.”);
passing of the modified or unmodified input parameters to the protection service to get a first asynchronous verdict (Fuller, col 6, line 15-27, “These annotations are then associated with a pre-processor and post-processor, which are used by the API management environment to validate input parameters and filter output parameters.”); and
postprocessing of the API call based on the API call output parameters (Fuller, col 4, line 63 - col 5, line 19, “The post-processor 118 may use the response object and client information to query an Authorization Engine 114 as to permissions and information related to response data. Using the permissions and information obtained, the post-processor 118 may verify, modify and/or delete fields and/or data from the response instance 116 as part of the inspection performed by the post-processor 118.”).
Regarding Claim 13, Sandoval in view of Fuller and further in view of Lukacs teaches: The method of claim 11, wherein the asynchronous postprocessing comprises:
communicating API call output parameters to the security service to get a second asynchronous verdict (Fuller, col 3, line 45-63, “In one embodiment, the post-processor 118 may consult 8 an authorization engine 114 to determine 9 which fields the client 102 has permission to receive.”); and
monitoring the API call based on the second asynchronous verdict (Lukacs, ¶[0035], “CSA 40 is configured to monitor the behavior of a plurality of executable entities (e.g., processes, threads, applications), and to determine whether any such monitored entity is malicious according to its behavior. Monitored entities may include components of an operating system and user applications, among others.”).
Regarding Claim 14, Sandoval in view of Fuller and further in view of Lukacs teaches: The method of claim 11, wherein the synchronous postprocessing comprises:
communicating API call output parameters to the security service to get a second synchronous verdict (Fuller, col 3, line 45-63, “The request processor may allow the post-processor 118 to inspect and alter the return instance to conform to the expectations of the API call variant. In some embodiments, this may include stripping new fields from the return instance that are not expected to be returned to the client. In other embodiments, this may be altering the return instance to conform to the expected return syntax. In one embodiment, the post-processor 118 may consult 8 an authorization engine 114 to determine 9 which fields the client 102 has permission to receive.”); and
blocking the API call based on the second synchronous verdict (Fuller, col 3, line 45-63, “In some embodiments, this may include stripping new fields from the return instance that are not expected to be returned to the client. In other embodiments, this may be altering the return instance to conform to the expected return syntax. In one embodiment, the post-processor 118 may consult 8 an authorization engine 114 to determine 9 which fields the client 102 has permission to receive. After the post-processor 118 has completed the inspection, the request processor may receive 10 the return information and provide a response 14 to the client 102 using the return information.”).
Regarding Claim 15, Sandoval in view of Fuller and further in view of Lukacs teaches: The method of claim 11, wherein the synchronous postprocessing comprises:
communicating API call output parameters to the security service to get a second synchronous verdict (Fuller, col 3, line 45-63, “In one embodiment, the post-processor 118 may consult 8 an authorization engine 114 to determine 9 which fields the client 102 has permission to receive.”);
adjusting the API call output parameters (Fuller, col 3, line 45-63, “The request processor may allow the post-processor 118 to inspect and alter the return instance to conform to the expectations of the API call variant. In some embodiments, this may include stripping new fields from the return instance that are not expected to be returned to the client. … In one embodiment, the post-processor 118 may consult 8 an authorization engine 114 to determine 9 which fields the client 102 has permission to receive.”); and
allowing the API call with the adjusted output parameters based on the second synchronous verdict (Fuller, col 3, line 45-63, “After the post-processor 118 has completed the inspection, the request processor may receive 10 the return information and provide a response 14 to the client 102 using the return information.”).
Regarding Claim 16, Sandoval in view of Fuller and further in view of Lukacs teaches: The method of claim 12, wherein the security kernel driver further processes the API call by:
collecting for audit purposes the API call information (Fuller, col 4, line 63 - col 5, line 19, “The API call 106 and/or successful API return 120 may be reported to an auditing system 122.”);
initiating, by the security kernel driver, a security action based on the first synchronous verdict, wherein the security action initiates a protection mechanism (Lukacs, ¶[0054], “When the synchronous analysis indicates that the currently notified event is indicative of a computer security threat (e.g., is malware-indicative), synchronous analysis module 44 may transmit a security alert 56b to CSA 40.” ¶[0055], “When the event indicates a computer security threat according to a result of the asynchronous analysis, module 46 may transmit a security alert 56a to CSA 40.” ¶[0057] “In response to receiving security alert(s) 56a and/or 56b, computer security application 40 may take protective action against monitored entity 38.”).
Regarding Claim 17, Sandoval in view of Fuller and further in view of Lukacs teaches: The method of claim 11, further comprising initiating, by the security kernel driver, a security action based on the synchronous postprocessing or the asynchronous postprocessing, wherein the security action is one of:
initiating a protection mechanism (Lukacs, ¶[0057], “In response to receiving security alert(s) 56a and/or 56b, computer security application 40 may take protective action against monitored entity 38. Such protective action may include, among others, suspending execution of, or otherwise incapacitating entity 38, and rolling back a set of changes made to host system 10 as a result of execution of monitored entity 38.”);
executing remediation procedures;
backup of a state requested to be overwritten by the API call; or
triggering a rollback of system changes associated with the call.
Regarding Claim 18, Sandoval discloses: A method for managing Application Program Interface (API) calls from a client to an API server in a computer system comprising a security kernel driver and a protection service, the method comprising:
injecting a security dynamic link library (DLL) into the API server, wherein the DLL is configured to monitor API calls related to specific system functions (Sandoval, col 2, line 1-2, “API hooks can be introduced in a variety of ways, either at the source of the call (i.e., the application program) or the target thereof (e.g., the operating system process being called). A particularly powerful method of API hooking involves injecting a dynamic link library (DLL) into the address space of the target program and patching the API with a branch (i.e., JMP) instruction. A DLL is a file containing executable instructions (in the form of subroutines and functions) that can be loaded and executed by a computer program while that program is running.”);
hooking an API call of a client to the API server by the security DLL (Sandoval, col 2, line 1-12, “API hooks can be introduced in a variety of ways, either at the source of the call (i.e., the application program) or the target thereof (e.g., the operating system process being called). A particularly powerful method of API hooking involves injecting a dynamic link library (DLL) into the address space of the target program and patching the API with a branch (i.e., JMP) instruction. A DLL is a file containing executable instructions (in the form of subroutines and functions) that can be loaded and executed by a computer program while that program is running.”);
analyzing the API call information by the security DLL to determine an identity of the client (Fuller, col 3, line 10-44, “The pre-processor may then use the information contained in request instance and/or the context of the API call variant to determine if the request instance should be processed. In other embodiments, the context may include time of day, IP address, account type, origin of request, destination of request, hostname or other identifiers that may be extrinsically given or intrinsic to the request.”); and
impersonating the client by the security DLL to get security rights of the client (Fuller, col 3, line 10-44, “In the embodiment shown, the pre-processor consults 2 an authorization engine 114 to determine if the client 102 has permission to use the API call variant. In some embodiments, the pre-processor 112 may calculate or determine the authorization without consulting an authorization engine 114.”);
prefiltering the API call by the security DLL by evaluating parameters of the API call against a predefined security DLL policy to determine an API call status, wherein the API call is passed to the security kernel driver (Fuller, col 3, line 10-44, “The pre-processor may then use the information contained in request instance and/or the context of the API call variant to determine if the request instance should be processed. … In the embodiment shown, the pre-processor consults 2 an authorization engine 114 to determine if the client 102 has permission to use the API call variant.”);
allowing, by the security kernel driver, execution of the API call without preprocessing (Fuller, col 3, line 10-44, “However, if the client has permission to make the request using the API call variant, the request may be communicated 5 to the request service 13 for processing”); and
determining, by the security kernel driver, that the executed API call requires postprocessing (Fuller, col 4, line 63 - col 5, line 19, “The request processor 108 may invoke the post-processor 118.”);
wherein postprocessing comprises synchronous postprocessing when the parameters of the API call are an immediate risk to the computer system (The limitation “API call” is taught by Sandoval in view of Fuller. Lukacs is not relied upon to teach the limitation of “API call.” Lukacs ¶[0044], “a part of the analysis is performed in a synchronous manner, while another part of the analysis may be performed asynchronously. The term synchronous is used herein to denote a manner of analyzing an event wherein execution of the entity generating the event (herein deemed triggering entity, for simplicity) is suspended while the respective analysis is performed. In contrast to synchronous analysis, asynchronous analysis refers to a manner of analyzing an event, wherein the triggering entity is allowed to continue execution, while the respective event is inserted into an event queue, to be analyzed later on.”);
wherein the postprocessing comprises asynchronous postprocessing when the parameters of the API call do not pose an immediate risk to the computer system (The limitation “API call” is taught by Sandoval in view of Fuller. Lukacs is not relied upon to teach the limitation of “API call.” Lukacs ¶[0044], “a part of the analysis is performed in a synchronous manner, while another part of the analysis may be performed asynchronously. The term synchronous is used herein to denote a manner of analyzing an event wherein execution of the entity generating the event (herein deemed triggering entity, for simplicity) is suspended while the respective analysis is performed. In contrast to synchronous analysis, asynchronous analysis refers to a manner of analyzing an event, wherein the triggering entity is allowed to continue execution, while the respective event is inserted into an event queue, to be analyzed later on.”); and
postprocessing the API call (Fuller, col 4, line 63 - col 5, line 19, “The post-processor 118 may use the response object and client information to query an Authorization Engine 114 as to permissions and information related to response data. Using the permissions and information obtained, the post-processor 118 may verify, modify and/or delete fields and/or data from the response instance 116 as part of the inspection performed by the post-processor 118.”).
Regarding Claim 19, Sandoval in view of Fuller and further in view of Lukacs teaches: The method of claim 18, wherein the asynchronous postprocessing comprises:
communicating API call output parameters to the security service to get a second asynchronous verdict (Fuller, col 3, line 45-63, “In one embodiment, the post-processor 118 may consult 8 an authorization engine 114 to determine 9 which fields the client 102 has permission to receive.”); and
monitoring the API call based on the second asynchronous verdict (Lukacs, ¶[0035], “CSA 40 is configured to monitor the behavior of a plurality of executable entities (e.g., processes, threads, applications), and to determine whether any such monitored entity is malicious according to its behavior. Monitored entities may include components of an operating system and user applications, among others.”).
Regarding Claim 20, Sandoval in view of Fuller and further in view of Lukacs teaches: The method of claim 18, wherein the synchronous postprocessing comprises:
communicating API call output parameters to the security service to get a synchronous postprocessing verdict (Fuller, col 3, line 45-63, “The request processor may allow the post-processor 118 to inspect and alter the return instance to conform to the expectations of the API call variant. In some embodiments, this may include stripping new fields from the return instance that are not expected to be returned to the client. In other embodiments, this may be altering the return instance to conform to the expected return syntax. In one embodiment, the post-processor 118 may consult 8 an authorization engine 114 to determine 9 which fields the client 102 has permission to receive.”); and
either adjusting the API call output parameters (Fuller, col 3, line 45-63, “The request processor may allow the post-processor 118 to inspect and alter the return instance to conform to the expectations of the API call variant. In some embodiments, this may include stripping new fields from the return instance that are not expected to be returned to the client. … In one embodiment, the post-processor 118 may consult 8 an authorization engine 114 to determine 9 which fields the client 102 has permission to receive.”),
allowing the API call with the adjusted output parameters based on the synchronous postprocessing verdict (Fuller, col 3, line 45-63, “After the post-processor 118 has completed the inspection, the request processor may receive 10 the return information and provide a response 14 to the client 102 using the return information.”), or
blocking the API call based on the synchronous postprocessing verdict (Fuller, col 3, line 45-63, “In some embodiments, this may include stripping new fields from the return instance that are not expected to be returned to the client. In other embodiments, this may be altering the return instance to conform to the expected return syntax. In one embodiment, the post-processor 118 may consult 8 an authorization engine 114 to determine 9 which fields the client 102 has permission to receive. After the post-processor 118 has completed the inspection, the request processor may receive 10 the return information and provide a response 14 to the client 102 using the return information.”).
CONCLUSION
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDGAR W XIE whose telephone number is (703)756-4777. The examiner can normally be reached Monday - Friday, 8:00am - 5:00pm.
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, JEFFREY PWU can be reached at (571)272-6798. 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.
/EDGAR W XIE/Examiner, Art Unit 2433
/WASIKA NIPA/Primary Examiner, Art Unit 2433