API CALL METHOD, API CALL APPARATUS, ELECTRONIC DEVICE AND NON-TRANSITORY COMPUTER READABLE STORAGE MEDIUM

§101 §102 §103 §112

CTNF 18/407,956 CTNF 101616 DETAILED ACTION 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. This Office Action is in response to claims filed 01/09/2024. Claims 1-16 and 18 are pending. Claim Rejections - 35 USC § 112 07-30-02 AIA 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. 07-34-01 Claims 1-16 and 18 are 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, 9 and 18 all recite “the determining”. It is unclear whether this refers to determining “one or more rules corresponding to an API” or “whether to allow the API call request”. Therefore Claims 1, 9 and 18 are rejected under 35 U.S.C. 112(b). For the purposes of compact prosecution, examiner will interpret “the determining” as either for “one or more rules corresponding to an API” or “whether to allow the API call request”. Claims 4, 5, 8, 12, 13, and 16 all recite “the API call”. It is unclear whether this refers to “An Application Programming Interface (API) call method/apparatus” or “an API call request”. Therefore Claims 4, 5, 8, 12, 13, and 16 are rejected under 35 U.S.C. 112(b). For the purposes of compact prosecution, the Examiner will interpret “the API call” to mean either the “An Application Programming Interface (API) call method/apparatus” or “an API call request”. Claim 8 recites “a second position” twice. It is unclear if these are two different second positions. Therefore Claim 8 is rejected under 35 U.S.C. 112(b). For the purposes of compact prosecution, the Examiner will interpret that both “a second positions” refer to the same second position. Claims 2-8 and 10-16 are rejected based on their dependency to the aforementioned Claims 1 and 9 and their failure to resolve the deficiencies thereof. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1-18 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below. Step 1: Claims 1-8 are directed to methods and fall within the statutory category of processes. Claims 9-16 are directed to an apparatus and falls within the statutory category of machines. Claim 18 is directed to A non-transitory computer-readable storage medium and falls under the category of a manufacture. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes. In order to evaluate the Step 2A inquiry “Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?” we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application. Step 2A Prong 1: Claims 1, 9 and 18: the limitations of “determining/determine” … “one or more rules corresponding to an API from a rule set in response to an API call request…” and “determining/determine” … “whether to allow the API call request based on the one or more rules”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally determine a set of rules for performing a method of communication and whether or not to allow that communication based on those rules. Therefore, yes, Claims 1, 9 and 18 recite judicial exceptions. The claims have been identified to recite judicial exceptions, Step 2A Prong 2 will evaluate whether the claims are directed to the judicial exception. Step 2A Prong 2: Claims 1, 9 and 18: The judicial exceptions are not integrated into practical applications. In particular, the claims recite the following additional elements – “using processing circuitry of an electronic device”, “and executing/execute” … “a call of the API corresponding to the API call request based on results of the determining” is a recitation of generic computing components and functions merely being used as a tool to apply the abstract idea (see MPEP § 2106.05(f)). Therefore, “Do the claims recite additional elements that integrate the judicial exception into a practical application? No, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. After having evaluating the inquires set forth in Steps 2A Prong 1 and 2, it has been concluded that the Claims 1, 9 and 18 not only recite a judicial exception but that the claims are directed to a judicial exception as a judicial exception has not been integrated into a practical application. Step 2B: Claims 1, 9 and 18: The claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than generic computing components which do not amount to significantly more than the abstract idea. Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception? No , these additional elements, alone or in combination, do not amount to significantly more than the judicial exception. Having concluded analysis within the provided framework, Claims 1, 9 and 18 do not recite patent eligible subject matter under 35 U.S.C. § 101. Regarding Claims 2 and 10: “determining the one or more rules corresponding to the API from the rule set based on a command number of the API”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can think about one or more rules from a plurality corresponding to a method of communication. With regard to integration into practical application and whether additional elements amount to significantly more, Claims 2 and 10 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 2 and 10 do not recite patent eligible subject matter under 35 U.S.C. § 101. Regarding Claims 3 and 11: “wherein the rule set is included in a hash table; the hash table includes a key corresponding to the command number of the API, and one or more values corresponding to the key represent the one or more rules corresponding to the API;” … “traversing a linked list included in the hash table corresponding to the command number of the API based on the key to determine the one or more rules corresponding to the API, the one or more rules included in one or more nodes of the linked list”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally evaluate rules and traverse a linked list via pen and paper. With regard to integration into practical application and whether additional elements amount to significantly more, Claims 3 and 11 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 3 and 11 do not recite patent eligible subject matter under 35 U.S.C. § 101. Regarding Claims 4-5 and 12-13: “determining whether the API is being abused by comparing a status bitmap corresponding to the API with the one or more rules”, and “comparing values included in the status bitmap corresponding to the API with call sequence values included in each of the one or more rules; allowing the API call in response to the one or more rules including call sequence values which are same as the values of the status bitmap corresponding to the API; and prohibiting the API call in response to none of the one or more rules including call sequence values which are the same as the values of the status bitmap corresponding to the API”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can think about one or more rules from a plurality corresponding to a method of communication and compare them to a current status to determine if rules are being followed and allowing communication to take place accordingly. With regard to integration into practical application and whether additional elements amount to significantly more, Claims 4-5 and 12-13 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 4-5 and 12-13 do not recite patent eligible subject matter under 35 U.S.C. § 101. Regarding Claims 6 and 14: “determining/determine” … “the rule set corresponding to a target device from a plurality of preset rule sets in response to an open function of the API being executed to turn on the target device”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can select a recipient from a plurality based on a set of rules of the associated recipient and the message being sent. With regard to integration into practical application and whether additional elements amount to significantly more, Claims 6 and 14 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 6 and 14 do not recite patent eligible subject matter under 35 U.S.C. § 101. Regarding Claims 7 and 15: “creating/create,”… “a status bitmap corresponding to the API in response to an open function of the API being executed to turn on a target device, the status bitmap including API call records and API call results corresponding to the API; and updating/update” … “ the status bitmap corresponding to the API in response to executing calls of the API”, reciting insignificant extra-solution data gathering/storing/transmission activity, MPEP § 2106.05(g). With regard to integration into practical application and whether additional elements amount to significantly more, Claims 7 and 15 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more, performing a well understood, routine, and conventional task of data gathering. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network … iii. Electronic recordkeeping … iv. Storing and retrieving information in memory”. See MPEP § 2106.05(d)(II). Therefore, Claims 7 and 15 do not recite patent eligible subject matter under 35 U.S.C. § 101. Regarding Claims 8 and 16: “the updating the status bitmap comprises, in response to a second position in the status bitmap corresponding to the API being 0, the second position being used to record the API call results corresponding to the API: updating a first position in the status bitmap corresponding to the API to 1 in response to a successful calling of the API, the first position being used to record the API call record associated with the API; and updating a second position to 1 in the status bitmap corresponding to the API and updating the first position to 0 in response to a failed calling of the API” , reciting insignificant extra-solution data gathering/storing/transmission activity, MPEP § 2106.05(g). With regard to integration into practical application and whether additional elements amount to significantly more, Claims 8 and 16 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more, performing a well understood, routine, and conventional task of data gathering. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network … iii. Electronic recordkeeping … iv. Storing and retrieving information in memory”. See MPEP § 2106.05(d)(II). Therefore, Claims 8 and 16 do not recite patent eligible subject matter under 35 U.S.C. § 101. Claim Rejections - 35 USC § 102 07-06 AIA 15-10-15 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 (i.e., changing from AIA to pre-AIA) 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. 07-07-aia AIA 07-07 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 – 07-08-aia AIA (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 and 18 are rejected under 35 U.S.C. 102(a)(1) as being unpatentable over Joshi et al. (US 20180217996 A1) (hereinafter Joshi). Regarding Claim 1, Joshi teaches: An Application Programming Interface (API) call method, “A policy-based filter can be configured to monitor and filter calls to APIs that access functionality of the file-based write filter”, (Joshi: Abstract), “In step 1 in FIG. 4A, it is assumed that application 400 invokes a call to FbwfAddExclusion”, (Joshi: ¶027), “filter 200 can hook a call to a function of write filter APIs 150”, (Joshi: ¶042). comprising: determining, using processing circuitry of an electronic device, one or more rules corresponding to an API from a rule set in response to an API call request from an operating system (OS) of the electronic device associated with the API, “computer hardware, such as, for example, one or more processors and system memory”, (Joshi: ¶045), “policies 202 are shown as including an entry/rule” … “policies 202 can define the criteria by which filtering component 201 will determine whether a particular call to a function of write filter APIs 150 should be allowed”, (Joshi: ¶023), “In current Windows implementations, a call to the FbwfAddExclusion function (or calls to other functions for accessing file-based write filter 110) will be handled by the FBWFlib component of the operating system”, (Joshi: ¶026 ; Figs 4A-4E), “policy-based filter 200 is configured to perform API hooking, the operating system may notify policy-based filter 200 that the FbwfAddExclusion function was called prior to allowing the FBWFlib component to handle the call as is represented in step 2a”, (Joshi: ¶028), “In response to intercepting the attempt to access the functionality of file-based write filter 110, policy-based filter 200 can evaluate the access attempt against policies 202”, (Joshi: ¶029), “policy-based filter 200 can access policies 202 to determine whether the particular application and/or the particular user are authorized to access the particular functionality of file-based write filter 110” … “policies 202 include any rules that would allow application 400 and/or the current user to invoke the FbwfAddExclusion function”, (Joshi: ¶031). the API including an Input/Output Control (ioctl) interface; “I/O requests targeting file-based write filter 110 (e.g., IOCTLs that are created when an application calls functions of write filter APIs 150)”, (Joshi: ¶021), “policy-based filter 200 is attached to file-based write filter 110 as a filter driver, policy-based filter 200 can receive an IOCTL that is generated by the FBWFlib component in response to the call to the FbwfAddExclusion”, (Joshi: ¶028). determining, using the processing circuitry, whether to allow the API call request based on the one or more rules; “in the context of API hooking, filtering component 201 can be configured to allow a call to a function of write filter APIs 150 to proceed only if policies 202 allow the application and/or user that invoked the call to do so”, (Joshi: ¶022), “configured to determine whether a particular attempt to access the functionality of file-based filter driver 110 should be allowed as well as the functionality for either allowing or blocking the attempt”, (Joshi: ¶022), “computer hardware, such as, for example, one or more processors and system memory”, (Joshi: ¶045). and executing, using the processing circuitry, a call of the API corresponding to the API call request based on results of the determining. “In the case of API hooking, this may entail allowing the call to the FbwfAddExclusion function to proceed in a normal fashion to the FBWFlib component which would then create the appropriate IOCTL (e.g., via the DeviceIoControl function) to be passed on to file-based write filter 110 as represented in step 4a”, (Joshi: ¶032), “should allow a call to FbwfAddExclusion if the call is made by Application A when executed by User A”, (Joshi: ¶023), “filtering component 201 can include functionality for performing API hooking and/or for attaching itself as a filter to file-based write filter 110”, (Joshi: ¶022; Fig 3). Regarding Claim 9, Joshi teaches: An Application Programming Interface (API) call apparatus, comprising: processing circuitry configured to, “A policy-based filter can be configured to monitor and filter calls to APIs that access functionality of the file-based write filter”, (Joshi: Abstract), “In step 1 in FIG. 4A, it is assumed that application 400 invokes a call to FbwfAddExclusion”, (Joshi: ¶027), “filter 200 can hook a call to a function of write filter APIs 150”, (Joshi: ¶042), “computer hardware, such as, for example, one or more processors and system memory”, (Joshi: ¶045). determine one or more rules corresponding to an API from a rule set in response to an API call request from an operation system of the apparatus for the API, “policies 202 can define the criteria by which filtering component 201 will determine whether a particular call to a function of write filter APIs 150 should be allowed”, (Joshi: ¶023), “In current Windows implementations, a call to the FbwfAddExclusion function (or calls to other functions for accessing file-based write filter 110) will be handled by the FBWFlib component of the operating system”, (Joshi: ¶026 ; Figs 4A-4E), “policy-based filter 200 is configured to perform API hooking, the operating system may notify policy-based filter 200 that the FbwfAddExclusion function was called prior to allowing the FBWFlib component to handle the call as is represented in step 2a”, (Joshi: ¶028), “In response to intercepting the attempt to access the functionality of file-based write filter 110, policy-based filter 200 can evaluate the access attempt against policies 202”, (Joshi: ¶029), “policy-based filter 200 can access policies 202 to determine whether the particular application and/or the particular user are authorized to access the particular functionality of file-based write filter 110” … “policies 202 include any rules that would allow application 400 and/or the current user to invoke the FbwfAddExclusion function”, (Joshi: ¶031). the API comprises an Input/Output Control (ioctl) interface; “I/O requests targeting file-based write filter 110 (e.g., IOCTLs that are created when an application calls functions of write filter APIs 150)”, (Joshi: ¶021), “policy-based filter 200 is attached to file-based write filter 110 as a filter driver, policy-based filter 200 can receive an IOCTL that is generated by the FBWFlib component in response to the call to the FbwfAddExclusion”, (Joshi: ¶028). determine whether to allow the API call request based on the one or more rules; “in the context of API hooking, filtering component 201 can be configured to allow a call to a function of write filter APIs 150 to proceed only if policies 202 allow the application and/or user that invoked the call to do so”, (Joshi: ¶022), “configured to determine whether a particular attempt to access the functionality of file-based filter driver 110 should be allowed as well as the functionality for either allowing or blocking the attempt”, (Joshi: ¶022), “computer hardware, such as, for example, one or more processors and system memory”, (Joshi: ¶045). and execute a call of the API corresponding to the API call request based on results of the determining. “In the case of API hooking, this may entail allowing the call to the FbwfAddExclusion function to proceed in a normal fashion to the FBWFlib component which would then create the appropriate IOCTL (e.g., via the DeviceIoControl function) to be passed on to file-based write filter 110 as represented in step 4a”, (Joshi: ¶032), “should allow a call to FbwfAddExclusion if the call is made by Application A when executed by User A”, (Joshi: ¶023), “filtering component 201 can include functionality for performing API hooking and/or for attaching itself as a filter to file-based write filter 110”, (Joshi: ¶022; Fig 3). Regarding Claim 18, Joshi teaches: A non-transitory computer-readable storage medium having computer readable instructions stored thereon, which when being executed by at least one processor, cause the at least one processor to: “computer hardware, such as, for example, one or more processors and system memory” … “carrying or storing computer-executable instructions and/or data structures”, (Joshi: ¶045). determine one or more rules corresponding to an API from a rule set in response to an API call request from an operation system of an apparatus for the API, “policies 202 can define the criteria by which filtering component 201 will determine whether a particular call to a function of write filter APIs 150 should be allowed”, (Joshi: ¶023), “In current Windows implementations, a call to the FbwfAddExclusion function (or calls to other functions for accessing file-based write filter 110) will be handled by the FBWFlib component of the operating system”, (Joshi: ¶026 ; Figs 4A-4E), “policy-based filter 200 is configured to perform API hooking, the operating system may notify policy-based filter 200 that the FbwfAddExclusion function was called prior to allowing the FBWFlib component to handle the call as is represented in step 2a”, (Joshi: ¶028), “In response to intercepting the attempt to access the functionality of file-based write filter 110, policy-based filter 200 can evaluate the access attempt against policies 202”, (Joshi: ¶029), “policy-based filter 200 can access policies 202 to determine whether the particular application and/or the particular user are authorized to access the particular functionality of file-based write filter 110” … “policies 202 include any rules that would allow application 400 and/or the current user to invoke the FbwfAddExclusion function”, (Joshi: ¶031). the API comprises an Input/Output Control (ioctl) interface; “I/O requests targeting file-based write filter 110 (e.g., IOCTLs that are created when an application calls functions of write filter APIs 150)”, (Joshi: ¶021), “policy-based filter 200 is attached to file-based write filter 110 as a filter driver, policy-based filter 200 can receive an IOCTL that is generated by the FBWFlib component in response to the call to the FbwfAddExclusion”, (Joshi: ¶028). determine whether to allow the API call request based on the one or more rules; “in the context of API hooking, filtering component 201 can be configured to allow a call to a function of write filter APIs 150 to proceed only if policies 202 allow the application and/or user that invoked the call to do so”, (Joshi: ¶022), “configured to determine whether a particular attempt to access the functionality of file-based filter driver 110 should be allowed as well as the functionality for either allowing or blocking the attempt”, (Joshi: ¶022), “computer hardware, such as, for example, one or more processors and system memory”, (Joshi: ¶045). and execute a call of the API corresponding to the API call request based on results of the determining. “In the case of API hooking, this may entail allowing the call to the FbwfAddExclusion function to proceed in a normal fashion to the FBWFlib component which would then create the appropriate IOCTL (e.g., via the DeviceIoControl function) to be passed on to file-based write filter 110 as represented in step 4a”, (Joshi: ¶032), “should allow a call to FbwfAddExclusion if the call is made by Application A when executed by User A”, (Joshi: ¶023), “filtering component 201 can include functionality for performing API hooking and/or for attaching itself as a filter to file-based write filter 110”, (Joshi: ¶022; Fig 3). Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21 AIA Claim s 2 and 10 are rejected under 35 U.S.C. 103(a) as being unpatentable over Joshi et al. (US 20180217996 A1) (hereinafter Joshi) . Regarding Claim 2, Joshi teaches: determining the one or more rules corresponding to the API from the rule set based on a command number of the API . “A policy-based filter can be configured to monitor and filter calls to APIs that access functionality of the file-based write filter”, (Joshi: Abstract), “In step 1 in FIG. 4A, it is assumed that application 400 invokes a call to FbwfAddExclusion”, (Joshi: ¶027), “filter 200 can hook a call to a function of write filter APIs 150”, (Joshi: ¶042) “policies 202 can define the criteria by which filtering component 201 will determine whether a particular call to a function of write filter APIs 150 should be allowed”, (Joshi: ¶023), “policy-based filter 200 is configured to perform API hooking, the operating system may notify policy-based filter 200 that the FbwfAddExclusion function was called prior to allowing the FBWFlib component to handle the call as is represented in step 2a”, (Joshi: ¶028), “For clarity, it is noted that the IOCTL would be in the form of an IRP with a particular IOCTL control code that is passed to policy-based filter 200 by I/O manager”, (Joshi: ¶028). Examiner notes: interpreting the IOCTL control code as a command number. While Joshi does not explicitly teach a command number, it does teach a IOCTL control code in “For clarity, it is noted that the IOCTL would be in the form of an IRP with a particular IOCTL control code that is passed to policy-based filter 200 by I/O manager”, (Joshi: ¶028). A IOCTL control code is similar to a command number because it identifies which specific driver/API operation is being requested. It would have been obvious to use a command number as the numeric operation identifier corresponding to the IOCTL/API command. Regarding Claim 10, Joshi teaches: determining the one or more rules corresponding to the API from the rule set based on a command number of the API. “A policy-based filter can be configured to monitor and filter calls to APIs that access functionality of the file-based write filter”, (Joshi: Abstract), “In step 1 in FIG. 4A, it is assumed that application 400 invokes a call to FbwfAddExclusion”, (Joshi: ¶027), “filter 200 can hook a call to a function of write filter APIs 150”, (Joshi: ¶042) “policies 202 can define the criteria by which filtering component 201 will determine whether a particular call to a function of write filter APIs 150 should be allowed”, (Joshi: ¶023), “policy-based filter 200 is configured to perform API hooking, the operating system may notify policy-based filter 200 that the FbwfAddExclusion function was called prior to allowing the FBWFlib component to handle the call as is represented in step 2a”, (Joshi: ¶028), “For clarity, it is noted that the IOCTL would be in the form of an IRP with a particular IOCTL control code that is passed to policy-based filter 200 by I/O manager”, (Joshi: ¶028). Examiner notes: interpreting the IOCTL control code as a command number. While Joshi does not explicitly teach a command number, it does teach a IOCTL control code in “For clarity, it is noted that the IOCTL would be in the form of an IRP with a particular IOCTL control code that is passed to policy-based filter 200 by I/O manager”, (Joshi: ¶028). A IOCTL control code is similar to a command number because it identifies which specific driver/API operation is being requested. It would have been obvious to use a command number as the numeric operation identifier corresponding to the IOCTL/API command . 07-21 AIA Claim s 3 and 11 are rejected under 35 U.S.C. 103(a) as being unpatentable over Joshi in view of Law et al (US 20070005546 A1) (hereinafter Law) . Regarding Claim 3, Joshi teaches: the hash table includes a key corresponding to the command number of the API, and one or more values corresponding to the key represent the one or more rules corresponding to the API ; and the determining the one or more rules corresponding to the API from the rule set based on the command number of the API comprises, traversing a linked list included in the hash table corresponding to the command number of the API based on the key to determine the one or more rules corresponding to the API, “A policy-based filter can be configured to monitor and filter calls to APIs that access functionality of the file-based write filter”, (Joshi: Abstract), “In step 1 in FIG. 4A, it is assumed that application 400 invokes a call to FbwfAddExclusion”, (Joshi: ¶027), “filter 200 can hook a call to a function of write filter APIs 150”, (Joshi: ¶042) “policies 202 can define the criteria by which filtering component 201 will determine whether a particular call to a function of write filter APIs 150 should be allowed”, (Joshi: ¶023), “policy-based filter 200 is configured to perform API hooking, the operating system may notify policy-based filter 200 that the FbwfAddExclusion function was called prior to allowing the FBWFlib component to handle the call as is represented in step 2a”, (Joshi: ¶028), “For clarity, it is noted that the IOCTL would be in the form of an IRP with a particular IOCTL control code that is passed to policy-based filter 200 by I/O manager”, (Joshi: ¶028). Examiner notes: interpreting the IOCTL control code as a command number. Further regarding Claim 3, Joshi fails to teach: the rule set is included in a hash table; the hash table includes a key corresponding to the command number of the API , However, Law teaches: “The composite key is used to retrieve a list of rules from a common hash table” … “maps from a composite hash key to an array of rule objects” … “. The hash table is preferably shared among all target attributes to eliminate, inter alia, duplicate matching criteria”, (Law: ¶040). and one or more values corresponding to the key represent the one or more rules corresponding to the API; “In step 240, a composite key for the current template is created by concatenating each attribute name in the current template's literal match set and the corresponding value from the input data”, (Law: ¶039), “client identification is performed by matching one or more of the incoming key/value pairs to identify the client and set a client ID attribute”, (Law: ¶045), “Each row in Table 1 represents a rule and each cell in Table 1 represents a value”, (Law: ¶024). traversing a linked list included in the hash table corresponding to the command number of the API based on the key to determine the one or more rules corresponding to the API, However, Law teaches: “In step 250, each rule in the returned linked list is examined for any additional pattern criteria associated with the rule and if the input data satisfies every pattern criteria associated with the rule” … “after examining each rule in the returned linked list, no rule has been added to the final result set”, (Law: ¶041), “includes a pointer to the first template object in the next match set that may be used to quickly skip to the first template of the next match set as soon as all the templates within the current match set have been visited or suppressed”, (Law: ¶034). the one or more rules included in one or more nodes of the linked list. However, Law teaches: “The composite key is used to retrieve a list of rules from a common hash table” … “maps from a composite hash key to an array of rule objects” … “. The hash table is preferably shared among all target attributes to eliminate, inter alia, duplicate matching criteria”, (Law: ¶040), “the hash table returns a linked list of rule objects whose literal matching criteria match the input data and are associated with the current template”, (Law: ¶041). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the rule set is included in a hash table; the hash table includes a key corresponding to the command number of the API , and one or more values corresponding to the key represent the one or more rules corresponding to the API; traversing a linked list included in the hash table corresponding to the command number of the API based on the key to determine the one or more rules corresponding to the API, the one or more rules included in one or more nodes of the linked list of Law with the methods and systems of Joshi resulting in an API interception system that retrieves policies/rules by a key from a common hash table. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “The hash table is preferably shared among all target attributes to eliminate, inter alia, duplicate matching criteria”, (Law: ¶040), and “The processing time of the rules table may be significantly decreased through the use of a rule shape”, (Law: ¶029) . Regarding Claim 11, Joshi teaches: the hash table includes a key corresponding to the command number of the API , and one or more values corresponding to the key represents the one or more rules corresponding to the API ; and the processing circuitry is further configured to determine the one or more rules corresponding to the API by, traversing a linked list included in the hash table corresponding to the command number of the API based on the key to determine the one or more rules corresponding to the API, “A policy-based filter can be configured to monitor and filter calls to APIs that access functionality of the file-based write filter”, (Joshi: Abstract), “In step 1 in FIG. 4A, it is assumed that application 400 invokes a call to FbwfAddExclusion”, (Joshi: ¶027), “filter 200 can hook a call to a function of write filter APIs 150”, (Joshi: ¶042) “policies 202 can define the criteria by which filtering component 201 will determine whether a particular call to a function of write filter APIs 150 should be allowed”, (Joshi: ¶023), “policy-based filter 200 is configured to perform API hooking, the operating system may notify policy-based filter 200 that the FbwfAddExclusion function was called prior to allowing the FBWFlib component to handle the call as is represented in step 2a”, (Joshi: ¶028), “For clarity, it is noted that the IOCTL would be in the form of an IRP with a particular IOCTL control code that is passed to policy-based filter 200 by I/O manager”, (Joshi: ¶028). Examiner notes: interpreting the IOCTL control code as a command number. Further regarding Claim 11, Joshi fails to teach: wherein the rule set is included in a hash table; the hash table includes a key corresponding to the command number of the API, However, Law teaches: “The composite key is used to retrieve a list of rules from a common hash table” … “maps from a composite hash key to an array of rule objects” … “. The hash table is preferably shared among all target attributes to eliminate, inter alia, duplicate matching criteria”, (Law: ¶040). and one or more values corresponding to the key represents the one or more rules corresponding to the API; “In step 240, a composite key for the current template is created by concatenating each attribute name in the current template's literal match set and the corresponding value from the input data”, (Law: ¶039), “client identification is performed by matching one or more of the incoming key/value pairs to identify the client and set a client ID attribute”, (Law: ¶045), “Each row in Table 1 represents a rule and each cell in Table 1 represents a value”, (Law: ¶024). and the processing circuitry is further configured to determine the one or more rules corresponding to the API by , traversing a linked list included in the hash table corresponding to t he command number of the API based on the key to determine the one or more rules corresponding to the API , However, Law teaches: “In step 250, each rule in the returned linked list is examined for any additional pattern criteria associated with the rule and if the input data satisfies every pattern criteria associated with the rule” … “after examining each rule in the returned linked list, no rule has been added to the final result set”, (Law: ¶041), “includes a pointer to the first template object in the next match set that may be used to quickly skip to the first template of the next match set as soon as all the templates within the current match set have been visited or suppressed”, (Law: ¶034). the one or more rules included in one or more nodes of the linked list. However, Law teaches: “The composite key is used to retrieve a list of rules from a common hash table” … “maps from a composite hash key to an array of rule objects” … “. The hash table is preferably shared among all target attributes to eliminate, inter alia, duplicate matching criteria”, (Law: ¶040), “the hash table returns a linked list of rule objects whose literal matching criteria match the input data and are associated with the current template”, (Law: ¶041). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine wherein the rule set is included in a hash table; the hash table includes a key corresponding to the command number of the API, and one or more values corresponding to the key represents the one or more rules corresponding to the API; and the processing circuitry is further configured to determine the one or more rules corresponding to the API by , traversing a linked list included in the hash table corresponding to t he command number of the API based on the key to determine the one or more rules corresponding to the API , the one or more rules included in one or more nodes of the linked lis t of Law with the methods and systems of Joshi resulting in an API interception system that retrieves policies/rules by a key from a common hash table. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “The hash table is preferably shared among all target attributes to eliminate, inter alia, duplicate matching criteria”, (Law: ¶040), and “The processing time of the rules table may be significantly decreased through the use of a rule shape”, (Law: ¶029) . 07-21 AIA Claim s 4-5 and 12-13 are rejected under 35 U.S.C. 103(a) as being unpatentable over Joshi in view of Mankins et al (US 20110179488 A1) (hereinafter Mankins) . Regarding Claim 4, Joshi teaches: determining whether the API is being abused by comparing a status bitmap corresponding to the API with the one or more rules. “in the context of API hooking, filtering component 201 can be configured to allow a call to a function of write filter APIs 150 to proceed only if policies 202 allow the application and/or user that invoked the call to do so”, (Joshi: ¶022), “configured to determine whether a particular attempt to access the functionality of file-based filter driver 110 should be allowed as well as the functionality for either allowing or blocking the attempt”, (Joshi: ¶022), “computer hardware, such as, for example, one or more processors and system memory”, (Joshi: ¶045). Further regarding Claim 4, Joshi fails to teach: determining whether the API is being abused by comparing a status bitmap corresponding to the API with the one or more rules. However, Mankins teaches: “The comparisons facilitate real-time detection of actual system-call behavior that deviates from the expected system-call behavior and that may be indicative of intrusion attacks”, (Mankins: ¶009), “Anomalous behavior is identified when the actual system-call behavior does not have a match in the Bloom filter data object”, (Mankins: ¶018), “monitored system-call sequences have a match in the profile database, operation is considered to be normal” … “sequence is not found in the profile database, operation is considered to be anomalous”, (Mankins: ¶006), “The Bloom filter data object contains data representative of expected system-call behavior associated with a computer program”, (Mankins: Abstract), “The Bloom filter data object 180 may be in the form of a bit vector or bitmap data object”, (Mankins: ¶051), “Any suitable number h of independent and uniform hash functions may be employed to encode predetermined unique system-call sequences into the bit vector”, (Mankins: ¶050). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine determining whether the API is being abused by comparing a status bitmap corresponding to the API with the one or more rules of Mankins with the methods and systems of Joshi resulting in an API interception system that uses a bitmap to track API abuse . A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “the compact Bloom filter data object 180 in the OS kernel, where system-call behavior can be tracked and compared with the data in the Bloom filter data object 180 without having to communicate outside of the operating system level of the computer 110”, (Mankins: ¶045). Regarding Claim 5, Joshi teaches: comparing values included in the status bitmap corresponding to the API with call sequence values included in each of the one or more rules; allowing the API call in response to the one or more rules including call sequence values which are same as the values of the status bitmap corresponding to the API; and prohibiting the API call in response to none of the one or more rules including call sequence values which are the same as the values of the status bitmap corresponding to the API. “in the context of API hooking, filtering component 201 can be configured to allow a call to a function of write filter APIs 150 to proceed only if policies 202 allow the application and/or user that invoked the call to do so”, (Joshi: ¶022), “configured to determine whether a particular attempt to access the functionality of file-based filter driver 110 should be allowed as well as the functionality for either allowing or blocking the attempt”, (Joshi: ¶022), “computer hardware, such as, for example, one or more processors and system memory”, (Joshi: ¶045). Further regarding Claim 5, Joshi fails to teach: comparing values included in the status bitmap corresponding to the API with call sequence values included in each of the one or more rules; allowing the API call in response to the one or more rules including call sequence values which are same as the values of the status bitmap corresponding to the API; and prohibiting the API call in response to none of the one or more rules including call sequence values which are the same as the values of the status bitmap corresponding to the API. However, Mankins teaches: “The Bloom filter data object 180 may be in the form of a bit vector or bitmap data object”, (Mankins: ¶051), “Using the hash functions, the build subsystem 160 computes a predetermined number of distinct values for each system-call sequence, and uses these values to index the bit vector”, (Mankins: ¶050), “The indexed bits of the bit vector are set to a value of one to represent the encoded system-call sequence”, (Mankins: ¶050), “The hash functions are also used to index the bit vector to search for a match to a particular piece of input data, such as a monitored system-call sequence”, (Mankins: ¶050), “Actual system-call behavior is compared with the data in the Bloom filter data object”, (Mankins: Abstract), “As long as the monitored system-call sequences have a match in the profile database, operation is considered to be normal”, (Mankins: ¶006). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine comparing values included in the status bitmap corresponding to the API with call sequence values included in each of the one or more rules; allowing the API call in response to the one or more rules including call sequence values which are same as the values of the status bitmap corresponding to the API; and prohibiting the API call in response to none of the one or more rules including call sequence values which are the same as the values of the status bitmap corresponding to the API of Mankins with the methods and systems of Joshi resulting in an API interception system that compares call sequence values to a bitmap to track API abuse . A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “The comparisons facilitate real-time detection of actual system-call behavior that deviates from the expected system-call behavior and that may be indicative of intrusion attacks”, (Mankins: ¶009) and “the intrusion detection system 100 reduces delays associated with monitoring system calls in the OS kernel 120 because processing can be performed within the operating system”, (Mankins: ¶032). Regarding Claim 12, Joshi teaches: determining whether the API is being abused by comparing a status bitmap corresponding to the API with the one or more rules. “in the context of API hooking, filtering component 201 can be configured to allow a call to a function of write filter APIs 150 to proceed only if policies 202 allow the application and/or user that invoked the call to do so”, (Joshi: ¶022), “configured to determine whether a particular attempt to access the functionality of file-based filter driver 110 should be allowed as well as the functionality for either allowing or blocking the attempt”, (Joshi: ¶022), “computer hardware, such as, for example, one or more processors and system memory”, (Joshi: ¶045). Further regarding Claim 12, Joshi fails to teach: determining whether the API is being abused by comparing a status bitmap corresponding to the API with the one or more rules. However, Mankins teaches: “The comparisons facilitate real-time detection of actual system-call behavior that deviates from the expected system-call behavior and that may be indicative of intrusion attacks”, (Mankins: ¶009), “Anomalous behavior is identified when the actual system-call behavior does not have a match in the Bloom filter data object”, (Mankins: ¶018), “monitored system-call sequences have a match in the profile database, operation is considered to be normal” … “sequence is not found in the profile database, operation is considered to be anomalous”, (Mankins: ¶006), “The Bloom filter data object contains data representative of expected system-call behavior associated with a computer program”, (Mankins: Abstract), “The Bloom filter data object 180 may be in the form of a bit vector or bitmap data object”, (Mankins: ¶051), “Any suitable number h of independent and uniform hash functions may be employed to encode predetermined unique system-call sequences into the bit vector”, (Mankins: ¶050). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine determining whether the API is being abused by comparing a status bitmap corresponding to the API with the one or more rules of Mankins with the methods and systems of Joshi resulting in an API interception system that uses a bitmap to track API abuse . A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “the compact Bloom filter data object 180 in the OS kernel, where system-call behavior can be tracked and compared with the data in the Bloom filter data object 180 without having to communicate outside of the operating system level of the computer 110”, (Mankins: ¶045). Regarding Claim 13, Joshi teaches: comparing values included in the status bitmap corresponding to the API with call sequence values included in each of the one or more rules; allowing the API call in response to the one or more rules including call sequence values which are same as the values of the status bitmap corresponding to the API; and prohibiting the API call in response to none of the one or more rules including call sequence values which are the same as the values of the status bitmap corresponding to the API. “in the context of API hooking, filtering component 201 can be configured to allow a call to a function of write filter APIs 150 to proceed only if policies 202 allow the application and/or user that invoked the call to do so”, (Joshi: ¶022), “configured to determine whether a particular attempt to access the functionality of file-based filter driver 110 should be allowed as well as the functionality for either allowing or blocking the attempt”, (Joshi: ¶022), “computer hardware, such as, for example, one or more processors and system memory”, (Joshi: ¶045). Further regarding Claim 13, Joshi fails to teach: comparing values included in the status bitmap corresponding to the API with call sequence values included in each of the one or more rules; allowing the API call in response to the one or more rules including call sequence values which are same as the values of the status bitmap corresponding to the API; and prohibiting the API call in response to none of the one or more rules including call sequence values which are the same as the values of the status bitmap corresponding to the API. However, Mankins teaches: “The Bloom filter data object 180 may be in the form of a bit vector or bitmap data object”, (Mankins: ¶051), “Using the hash functions, the build subsystem 160 computes a predetermined number of distinct values for each system-call sequence, and uses these values to index the bit vector”, (Mankins: ¶050), “The indexed bits of the bit vector are set to a value of one to represent the encoded system-call sequence”, (Mankins: ¶050), “The hash functions are also used to index the bit vector to search for a match to a particular piece of input data, such as a monitored system-call sequence”, (Mankins: ¶050), “Actual system-call behavior is compared with the data in the Bloom filter data object”, (Mankins: Abstract), “As long as the monitored system-call sequences have a match in the profile database, operation is considered to be normal”, (Mankins: ¶006). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine comparing values included in the status bitmap corresponding to the API with call sequence values included in each of the one or more rules; allowing the API call in response to the one or more rules including call sequence values which are same as the values of the status bitmap corresponding to the API; and prohibiting the API call in response to none of the one or more rules including call sequence values which are the same as the values of the status bitmap corresponding to the API of Mankins with the methods and systems of Joshi resulting in an API interception system that compares call sequence values to a bitmap to track API abuse . A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “The comparisons facilitate real-time detection of actual system-call behavior that deviates from the expected system-call behavior and that may be indicative of intrusion attacks”, (Mankins: ¶009) and “the intrusion detection system 100 reduces delays associated with monitoring system calls in the OS kernel 120 because processing can be performed within the operating system”, (Mankins: ¶032) . 07-21 AIA Claim s 6 and 14 are rejected under 35 U.S.C. 103(a) as being unpatentable over Joshi in view of Oshins et al (US 20050246559 A1) (hereinafter Oshins) . Regarding Claim 6, Joshi teaches: determining, using the processing circuitry, the rule set corresponding to a target device from a plurality of preset rule sets in response to an open function of the API being executed to turn on the target device. “computer hardware, such as, for example, one or more processors and system memory”, (Joshi: ¶045), “policies 202 can define the criteria by which filtering component 201 will determine whether a particular call to a function of write filter APIs 150 should be allowed”, (Joshi: ¶023), “In current Windows implementations, a call to the FbwfAddExclusion function (or calls to other functions for accessing file-based write filter 110) will be handled by the FBWFlib component of the operating system”, (Joshi: ¶026 ; Figs 4A-4E), “policy-based filter 200 is configured to perform API hooking, the operating system may notify policy-based filter 200 that the FbwfAddExclusion function was called prior to allowing the FBWFlib component to handle the call as is represented in step 2a”, (Joshi: ¶028), “In response to intercepting the attempt to access the functionality of file-based write filter 110, policy-based filter 200 can evaluate the access attempt against policies 202”, (Joshi: ¶029), “policy- based filter 200 can access policies 202 to determine whether the particular application and/or the particular user are authorized to access the particular functionality of file-based write filter 110” … “policies 202 include any rules that would allow application 400 and/or the current user to invoke the FbwfAddExclusion function”, (Joshi: ¶031). Further regarding Claim 6, Joshi fails to teach: determining, using the processing circuitry , the rule set corresponding to a target device from a plurality of preset rule sets in response to an open function of the API being executed to turn on the target device. However, Oshins teaches: “a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer”, (Oshins: ¶024), “it controls the device by sending I/O Request Packets (IRPs) to the stack of drivers at 300”, (Oshins: ¶063), “each driver handles PnP and Power events. However, one driver in the stack should track system power events and status, deciding when the device should be powered on or off”, (Oshins: ¶064), “If a handle is opened when the device is in D3, then it will be moved to D0”, (Oshins: ¶350), “The Power Policy state machine is primarily responsible for deciding when the device should be in D0, D1, D2 or D3”, (Oshins: ¶093), “The Framework calls EvtDeviceCreate, which calls WdfPowerPolicyPowerReference”, (Oshins: ¶375), “This device can be moved between "off" and "on."”, (Oshins: ¶350). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine determining, using the processing circuitry , the rule set corresponding to a target device from a plurality of preset rule sets in response to an open function of the API being executed to turn on the target device of Oshins with the methods and systems of Joshi resulting in an API interception system capable of calls involving powering devices. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “Significantly improve opportunities for battery life savings including system tuning and power optimization algorithms”, (Oshins: ¶011). Regarding Claim 14, Joshi teaches: determine the rule set corresponding to a target device from a plurality of preset rule sets in response to an open function of the API being executed to turn on the target device. “computer hardware, such as, for example, one or more processors and system memory”, (Joshi: ¶045), “policies 202 can define the criteria by which filtering component 201 will determine whether a particular call to a function of write filter APIs 150 should be allowed”, (Joshi: ¶023), “In current Windows implementations, a call to the FbwfAddExclusion function (or calls to other functions for accessing file-based write filter 110) will be handled by the FBWFlib component of the operating system”, (Joshi: ¶026 ; Figs 4A-4E), “policy-based filter 200 is configured to perform API hooking, the operating system may notify policy-based filter 200 that the FbwfAddExclusion function was called prior to allowing the FBWFlib component to handle the call as is represented in step 2a”, (Joshi: ¶028), “In response to intercepting the attempt to access the functionality of file-based write filter 110, policy-based filter 200 can evaluate the access attempt against policies 202”, (Joshi: ¶029), “policy-based filter 200 can access policies 202 to determine whether the particular application and/or the particular user are authorized to access the particular functionality of file-based write filter 110” … “policies 202 include any rules that would allow application 400 and/or the current user to invoke the FbwfAddExclusion function”, (Joshi: ¶031). Further regarding Claim 6, Joshi fails to teach: determine the rule set corresponding to a target device from a plurality of preset rule sets in response to an open function of the API being executed to turn on the target device. However, Oshins teaches: “a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer”, (Oshins: ¶024), “it controls the device by sending I/O Request Packets (IRPs) to the stack of drivers at 300”, (Oshins: ¶063), “each driver handles PnP and Power events. However, one driver in the stack should track system power events and status, deciding when the device should be powered on or off”, (Oshins: ¶064), “If a handle is opened when the device is in D3, then it will be moved to D0”, (Oshins: ¶350), “The Power Policy state machine is primarily responsible for deciding when the device should be in D0, D1, D2 or D3”, (Oshins: ¶093), “The Framework calls EvtDeviceCreate, which calls WdfPowerPolicyPowerReference”, (Oshins: ¶375), “This device can be moved between "off" and "on."”, (Oshins: ¶350). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine determine the rule set corresponding to a target device from a plurality of preset rule sets in response to an open function of the API being executed to turn on the target device of Oshins with the methods and systems of Joshi resulting in an API interception system capable of calls involving powering devices. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “Significantly improve opportunities for battery life savings including system tuning and power optimization algorithms”, (Oshins: ¶011) . 07-21 AIA Claim s 7 and 15 are rejected under 35 U.S.C. 103(a) as being unpatentable over Joshi in view of Mankins, further in view of Oshins . Regarding Claim 7, Joshi fails to teach: creating, using the processing circuitry, a status bitmap corresponding to the API in response to an open function of the API being executed to turn on a target device, However, Mankins teaches: “The Bloom filter data object 180 may be in the form of a bit vector or bitmap data object”, (Mankins: ¶051), “Using the hash functions, the build subsystem 160 computes a predetermined number of distinct values for each system-call sequence, and uses these values to index the bit vector”, (Mankins: ¶050), “The indexed bits of the bit vector are set to a value of one to represent the encoded system-call sequence”, (Mankins: ¶050), “The hash functions are also used to index the bit vector to search for a match to a particular piece of input data, such as a monitored system-call sequence”, (Mankins: ¶050), “Actual system-call behavior is compared with the data in the Bloom filter data object”, (Mankins: Abstract), “As long as the monitored system-call sequences have a match in the profile database, operation is considered to be normal”, (Mankins: ¶006). the status bitmap including API call records and API call results corresponding to the API; However, Mankins teaches: “A rolling log of system calls may be maintained”, (Mankins: ¶035), “the monitoring subsystem 150 may monitor system-call behavior at the OS kernel 120”, (Mankins: ¶066), “If the trace includes the system calls "open, read, mmap, mmap, open”, (Mankins: ¶037). and updating, using the processing circuitry, the status bitmap corresponding to the API in response to executing calls of the API. However, Mankins teaches: “System calls refer to mechanisms used by computer programs to request service from the operating system ("OS") of a computer”, (Mankins: ¶005), “The indexed bits of the bit vector are set to a value of one to represent the encoded system-call sequence”, (Mankins: ¶050). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine creating, using the processing circuitry, a status bitmap corresponding to the API in response to an open function of the API being executed to turn on a target device, the status bitmap including API call records and API call results corresponding to the API; and updating, using the processing circuitry, the status bitmap corresponding to the API in response to executing calls of the API of Mankins with the methods and systems of Joshi resulting in an API interception system that compares call sequence values to a bitmap to track API abuse . A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “The comparisons facilitate real-time detection of actual system-call behavior that deviates from the expected system-call behavior and that may be indicative of intrusion attacks”, (Mankins: ¶009) and “the intrusion detection system 100 reduces delays associated with monitoring system calls in the OS kernel 120 because processing can be performed within the operating system”, (Mankins: ¶032). Further regarding Claim 7, Joshi in view Mankins of fails to teach: creating, using the processing circuitry, a status bitmap corresponding to the API in response to an open function of the API being executed to turn on a target device, However, Oshins teaches: “a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer”, (Oshins: ¶024), “it controls the device by sending I/O Request Packets (IRPs) to the stack of drivers at 300”, (Oshins: ¶063), “each driver handles PnP and Power events. However, one driver in the stack should track system power events and status, deciding when the device should be powered on or off”, (Oshins: ¶064), “If a handle is opened when the device is in D3, then it will be moved to D0”, (Oshins: ¶350), “The Power Policy state machine is primarily responsible for deciding when the device should be in D0, D1, D2 or D3”, (Oshins: ¶093), “The Framework calls EvtDeviceCreate, which calls WdfPowerPolicyPowerReference”, (Oshins: ¶375), “This device can be moved between "off" and "on."”, (Oshins: ¶350). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine creating, using the processing circuitry, a status bitmap corresponding to the API in response to an open function of the API being executed to turn on a target device, of Oshins with the methods and systems of Joshi in view of Mankins resulting in an API interception system capable of calls involving powering devices. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “Significantly improve opportunities for battery life savings including system tuning and power optimization algorithms”, (Oshins: ¶011). Regarding Claim 15, Joshi fails to teach: create a status bitmap corresponding to the API in response to an open function of the API being executed to turn on a target device, However, Mankins teaches: “The Bloom filter data object 180 may be in the form of a bit vector or bitmap data object”, (Mankins: ¶051), “Using the hash functions, the build subsystem 160 computes a predetermined number of distinct values for each system-call sequence, and uses these values to index the bit vector”, (Mankins: ¶050), “The indexed bits of the bit vector are set to a value of one to represent the encoded system-call sequence”, (Mankins: ¶050), “The hash functions are also used to index the bit vector to search for a match to a particular piece of input data, such as a monitored system-call sequence”, (Mankins: ¶050), “Actual system-call behavior is compared with the data in the Bloom filter data object”, (Mankins: Abstract), “As long as the monitored system-call sequences have a match in the profile database, operation is considered to be normal”, (Mankins: ¶006). the status bitmap including API call records and API call results corresponding to the API; However, Mankins teaches: “A rolling log of system calls may be maintained”, (Mankins: ¶035), “the monitoring subsystem 150 may monitor system-call behavior at the OS kernel 120”, (Mankins: ¶066), “If the trace includes the system calls "open, read, mmap, mmap, open”, (Mankins: ¶037). and update the status bitmap corresponding to the API in response to executing calls of the API. However, Mankins teaches: “System calls refer to mechanisms used by computer programs to request service from the operating system ("OS") of a computer”, (Mankins: ¶005), “The indexed bits of the bit vector are set to a value of one to represent the encoded system-call sequence”, (Mankins: ¶050). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine create a status bitmap corresponding to the API in response to an open function of the API being executed to turn on a target device, the status bitmap including API call records and API call results corresponding to the API; and update the status bitmap corresponding to the API in response to executing calls of the API of Mankins with the methods and systems of Joshi resulting in an API interception system that compares call sequence values to a bitmap to track API abuse . A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “The comparisons facilitate real-time detection of actual system-call behavior that deviates from the expected system-call behavior and that may be indicative of intrusion attacks”, (Mankins: ¶009) and “the intrusion detection system 100 reduces delays associated with monitoring system calls in the OS kernel 120 because processing can be performed within the operating system”, (Mankins: ¶032). Further regarding Claim 15, Joshi in view of Mankins fails to teach: create a status bitmap corresponding to the API in response to an open function of th e API being executed to turn on a target device, However, Oshins teaches: “a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer”, (Oshins: ¶024), “it controls the device by sending I/O Request Packets (IRPs) to the stack of drivers at 300”, (Oshins: ¶063), “each driver handles PnP and Power events. However, one driver in the stack should track system power events and status, deciding when the device should be powered on or off”, (Oshins: ¶064), “If a handle is opened when the device is in D3, then it will be moved to D0”, (Oshins: ¶350), “The Power Policy state machine is primarily responsible for deciding when the device should be in D0, D1, D2 or D3”, (Oshins: ¶093), “The Framework calls EvtDeviceCreate, which calls WdfPowerPolicyPowerReference”, (Oshins: ¶375), “This device can be moved between "off" and "on."”, (Oshins: ¶350). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine create a status bitmap corresponding to the API in response to an open function of th e API being executed to turn on a target device of Oshins with the methods and systems of Joshi in view of Mankins resulting in an API interception system capable of calls involving powering devices. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “Significantly improve opportunities for battery life savings including system tuning and power optimization algorithms”, (Oshins: ¶011) . 07-21 AIA Claim s 8 and 16 are rejected under 35 U.S.C. 103(a) as being unpatentable over Joshi in view of Mankins and Oshins, further in view of Burton et al. (US 20030149808 A1) (hereinafter Burton) . Further regarding Claim 8, Joshi in view of Mankins and Oshins fails to teach: in response to a second position in the status bitmap corresponding to the API being 0, the second position being used to record the API call results corresponding to the API: updating a first position in the status bitmap corresponding to the API to 1 in response to a successful calling of the API, the first position being used to record the API call record associated with the API; and updating a second position to 1 in the status bitmap corresponding to the API and updating the first position to 0 in response to a failed calling of the API. However, Burton teaches: “The status register 200 includes a channel identifier field 201, an abort indicator field 202, a transaction complete (TC) indicator field 203, a timeout indicator field 204”, (Burton: ¶016), “If the transaction completes successfully, the TC field 203 may be updated to indicate successful” … “if an abort or timeout event occurs, the abort field 203 or timeout field 204 may be respectively updated”, (Burton: ¶018), “status register may be appropriately updated to record the successful completion of the transaction”, (Burton: ¶024), “status register may be appropriately updated to record the timeout”, (Burton: ¶025), “if the TC field 203 is not written to after a predetermined period of time to indicate successful completion of the transaction, it may be determined that a timeout event has occurred”, (Burton: ¶017), “if a transaction complete is not recorded in the corresponding status register after a predetermined period of time, it may be determined that a timeout event has occurred. If so, an interrupt may be generated and the timeout indicator field 204 of the corresponding status register may be appropriately updated to record the timeout, as shown in block 308”, (Burton: ¶025). Examiner notes: First and second positions are interpreted as TC field 203 and abort timeout field 204 respectively, if success then fields are set to 1 and 0 since transaction completes and no timeout occurred however in response to a non-changing completion field then the fields may be set to 01 as transaction was incomplete and there was a timeout. It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine in response to a second position in the status bitmap corresponding to the API being 0, the second position being used to record the API call results corresponding to the API: updating a first position in the status bitmap corresponding to the API to 1 in response to a successful calling of the API, the first position being used to record the API call record associated with the API; and updating a second position to 1 in the status bitmap corresponding to the API and updating the first position to 0 in response to a failed calling of the API of Burton with the methods and systems of Joshi in view of Mankins and Oshins resulting in an API interception system than can dynamically record the completion of calls. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “Information obtained by monitoring and recording events as described may assist in diagnosing system problems and thereby increasing system reliability and availability”, (Burton: ¶028). Regarding Claim 16, Joshi in view of Mankins and Oshins fails to teach: updating a first position in the status bitmap corresponding to the API to 1 in response to a successful calling of the API, the first position being used to record the API call record associated with the API; and updating a second position in the status bitmap corresponding to the API to 1 and updating the first position to 0 in response to a failed calling of the API. However, Burton teaches: “The status register 200 includes a channel identifier field 201, an abort indicator field 202, a transaction complete (TC) indicator field 203, a timeout indicator field 204”, (Burton: ¶016), “If the transaction completes successfully, the TC field 203 may be updated to indicate successful” … “if an abort or timeout event occurs, the abort field 203 or timeout field 204 may be respectively updated”, (Burton: ¶018), “status register may be appropriately updated to record the successful completion of the transaction”, (Burton: ¶024), “status register may be appropriately updated to record the timeout”, (Burton: ¶025), “if the TC field 203 is not written to after a predetermined period of time to indicate successful completion of the transaction, it may be determined that a timeout event has occurred”, (Burton: ¶017), “if a transaction complete is not recorded in the corresponding status register after a predetermined period of time, it may be determined that a timeout event has occurred. If so, an interrupt may be generated and the timeout indicator field 204 of the corresponding status register may be appropriately updated to record the timeout, as shown in block 308”, (Burton: ¶025). Examiner notes: First and second positions are interpreted as TC field 203 and abort timeout field 204 respectively, if success then fields are set to 1 and 0 since transaction completes and no timeout occurred however in response to a non-changing completion field then the fields may be set to 01 as transaction was incomplete and there was a timeout. It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine updating a first position in the status bitmap corresponding to the API to 1 in response to a successful calling of the API, the first position being used to record the API call record associated with the API; and updating a second position in the status bitmap corresponding to the API to 1 and updating the first position to 0 in response to a failed calling of the API of Burton with the methods and systems of Joshi in view of Mankins and Oshins resulting in an API interception system than can dynamically record the completion of calls. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “Information obtained by monitoring and recording events as described may assist in diagnosing system problems and thereby increasing system reliability and availability”, (Burton: ¶028). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHIHAB ALAM whose telephone number is (571)272-8705. The examiner can normally be reached Mon - Fri 7:30am-5pm. 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, Bradley Teets can be reached at (571) 272-3338. 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. /SHIHAB ALAM/Examiner, Art Unit 2197 /BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197 Application/Control Number: 18/407,956 Page 2 Art Unit: 2197 Application/Control Number: 18/407,956 Page 3 Art Unit: 2197 Application/Control Number: 18/407,956 Page 4 Art Unit: 2197 Application/Control Number: 18/407,956 Page 5 Art Unit: 2197 Application/Control Number: 18/407,956 Page 6 Art Unit: 2197 Application/Control Number: 18/407,956 Page 7 Art Unit: 2197 Application/Control Number: 18/407,956 Page 8 Art Unit: 2197 Application/Control Number: 18/407,956 Page 9 Art Unit: 2197 Application/Control Number: 18/407,956 Page 10 Art Unit: 2197 Application/Control Number: 18/407,956 Page 11 Art Unit: 2197 Application/Control Number: 18/407,956 Page 12 Art Unit: 2197 Application/Control Number: 18/407,956 Page 13 Art Unit: 2197 Application/Control Number: 18/407,956 Page 14 Art Unit: 2197 Application/Control Number: 18/407,956 Page 15 Art Unit: 2197 Application/Control Number: 18/407,956 Page 16 Art Unit: 2197 Application/Control Number: 18/407,956 Page 17 Art Unit: 2197 Application/Control Number: 18/407,956 Page 18 Art Unit: 2197 Application/Control Number: 18/407,956 Page 19 Art Unit: 2197 Application/Control Number: 18/407,956 Page 20 Art Unit: 2197 Application/Control Number: 18/407,956 Page 21 Art Unit: 2197 Application/Control Number: 18/407,956 Page 22 Art Unit: 2197 Application/Control Number: 18/407,956 Page 23 Art Unit: 2197 Application/Control Number: 18/407,956 Page 24 Art Unit: 2197 Application/Control Number: 18/407,956 Page 25 Art Unit: 2197 Application/Control Number: 18/407,956 Page 26 Art Unit: 2197 Application/Control Number: 18/407,956 Page 27 Art Unit: 2197 Application/Control Number: 18/407,956 Page 28 Art Unit: 2197 Application/Control Number: 18/407,956 Page 29 Art Unit: 2197 Application/Control Number: 18/407,956 Page 30 Art Unit: 2197 Application/Control Number: 18/407,956 Page 31 Art Unit: 2197 Application/Control Number: 18/407,956 Page 32 Art Unit: 2197 Application/Control Number: 18/407,956 Page 33 Art Unit: 2197 Application/Control Number: 18/407,956 Page 34 Art Unit: 2197 Application/Control Number: 18/407,956 Page 35 Art Unit: 2197 Application/Control Number: 18/407,956 Page 36 Art Unit: 2197 Application/Control Number: 18/407,956 Page 37 Art Unit: 2197 Application/Control Number: 18/407,956 Page 38 Art Unit: 2197 Application/Control Number: 18/407,956 Page 39 Art Unit: 2197 Application/Control Number: 18/407,956 Page 40 Art Unit: 2197 Application/Control Number: 18/407,956 Page 41 Art Unit: 2197 Application/Control Number: 18/407,956 Page 42 Art Unit: 2197 Application/Control Number: 18/407,956 Page 43 Art Unit: 2197 Application/Control Number: 18/407,956 Page 44 Art Unit: 2197 Application/Control Number: 18/407,956 Page 45 Art Unit: 2197 Application/Control Number: 18/407,956 Page 46 Art Unit: 2197 Application/Control Number: 18/407,956 Page 47 Art Unit: 2197 Application/Control Number: 18/407,956 Page 48 Art Unit: 2197 Application/Control Number: 18/407,956 Page 49 Art Unit: 2197 Application/Control Number: 18/407,956 Page 50 Art Unit: 2197 Application/Control Number: 18/407,956 Page 51 Art Unit: 2197