DETAILED ACTION
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
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103(a) are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1 – 3, 7, 8, 16, and 17 are rejected under 35 U.S.C. 102(a)(2) as being unpatentable over Naamneh et al. (hereinafter Naamneh, US 11,204,992) in view of Tse et al. (hereinafter Tse, US 2016/0092685).
Regarding claim 1, Naamneh discloses:
a computing device (see at least Fig. 1 and col. 4 ln. 11 – col. 5 ln. 43), comprising:
a processor resource (see at least Fig. 1 and col. 4 ln. 11 – col. 5 ln. 43); and
a non-transitory memory resource storing machine-readable instructions to cause the processor resource (see at least Fig. 1 and col. 4 ln. 11 – col. 5 ln. 43) to:
receive, at an application programming interface (API) of an operating system (OS) of the computing device, a call from an application (see at least Fig. 5 and col. 8 ln. 55 – col. 9 ln. 45 for API OS kernel calls that are received through a compatibility layer that originate from the malware process (an application));
modify the call to the API service based on a policy (see at least Fig. 5 and col. 8 ln. 55 – col. 9 ln. 45 for API OS kernel calls that are received through a compatibility layer and modifying the calls for successful execution); and
return a modified output to the application according to the modified call based on the policy being active (see at least Fig. 5 and col. 8 ln. 55 – col. 9 ln. 45 for API OS kernel calls that are received through a compatibility layer and modifying the calls for successful execution, which includes, then, providing the modified call(s) to the system for said execution (this providing the modified call then shows that the modified call is returned* to the system for the calls execution), thereby to augment or modify a behavior of at least one of the application or the OS (see at least Fig. 5 and col. 8 ln. 55 – col. 9 ln. 45 where the performing of the return of the modified kernel calls change the behavior of operating system (OS) / kernel as the OS would have performed another task or been idle but for the processing of the call), wherein the policy is determined to have been affirmatively made when a condition associated with the policy is satisfied and wherein the policy is determined to not been invoked when the condition is not satisfied (see at least Fig. 5 and col. 8 ln. 55 – col. 9 ln. 45 where denial or allowance of an access request for an API call is made and the API call is modified when the condition is determined to merit that action and when not merited/satisfied the API is not modified).
Naamneh does not expressly disclose the policies being active, however Tse discloses
a policy being active or inactive depending on a condition being satisfied or not (see at least ph. [0035] for the thresholds are continued to be violated while the conditions of those violation thresholds are not in compliance of the compliance rule).
It would have been obvious for a person of ordinary skill in the art at the time of filing to modify the teachings of Naamneh, as modified by Tse in order to implement passive compliance system notifications.
Regarding claim 2, the rejection of claim 1 is incorporated and Naamneh discloses:
the processor resource is to modify the call to the API service by filtering the call (at least Fig. 3 and col. 6 ln. 7 – col. 8 ln. 38 discloses that the API calls are determined for their compatibility and incompatibility with the system, this acts as a filter for one set of calls being handled in one fashion (i.e. if incompatible, they are modified to be made compatible), this is done on the system executed by the processor as per at least Fig. 1 and col. 4 ln. 11 – col. 5 ln. 43).
Regarding claim 3, the rejection of claim 2 is incorporated and Naamneh discloses:
the processor resource is to modify the call to the API service by altering the filtered call (at least Fig. 3 and col. 6 ln. 7 – col. 8 ln. 38 discloses that the API calls are determined for their compatibility and incompatibility with the system, this acts as a filter for one set of calls being handled in one fashion (i.e. if incompatible, they are modified to be made compatible), this is done on the system executed by the processor as per at least Fig. 1 and col. 4 ln. 11 – col. 5 ln. 43).
Regarding claim 7, the rejection of claim 1 is incorporated and Naamneh discloses:
the call is a system call, and wherein the system call is at least one of:
a process control call;
a file management call (see at least col. 6 ln. 17 – 27 for the API calls to operating system including calls to open files (a common file management call));
or an information maintenance call.
Regarding claim 8, Naamneh discloses:
a non-transitory machine-readable medium including instructions that when executed cause a processor resource (see at least Fig. 1 and col. 4 ln. 11 – col. 5 ln. 43) to:
transmit a system call from an application to an application programming interface (API) service of an operating system (OS) of the computing device (see at least Fig. 4 – 6 and their respective brief descriptions in col. 3 ln. 17 – 27 that describe the API calls as system calls, Fig. 1 and col. 4 ln. 11 – col. 5 ln. 43 and at least Fig. 3 and col. 6 ln. 7 – col. 8 ln. 38 for the API OS system calls being received and modified);
before the system call is received by the API service of the OS of the computing device hook the received system call to the API service by a function provider included in the API service of the OS (see at least Fig. 1 and col. 4 ln. 11 – col. 5 ln. 43 and at least Fig. 3 and col. 6 ln. 7 – col. 8 ln. 38 for the API OS system calls being received, intercepted/ hooked and modified whereas mentioned in Fig. 3 block 302 a call “to and API” indicates that the call is directed to the API and that call *to* the API is what is intercepted, which then indicates that the interception is before the call is made to the API);
modify the hooked system call to the API service based on an active policy (see at least Fig. 1 and col. 4 ln. 11 – col. 5 ln. 43 and at least Fig. 3 and col. 6 ln. 7 – col. 8 ln. 38 for the API OS system calls being received, intercepted/ hooked and modified), wherein the policy is determined to have been affirmatively made when a condition associated with the policy is satisfied (see at least Fig. 5 and col. 8 ln. 55 – col. 9 ln. 45 where denial or allowance of an access request for an API call is made and the API call is modified when the condition is determined to merit that action and when not merited/satisfied the API is not modified).
Naamneh does not expressly disclose the policies being active, however Tse discloses
a policy being active or inactive depending on a condition being satisfied or not (see at least ph. [0035] for the thresholds are continued to be violated while the conditions of those violation thresholds are not in compliance of the compliance rule); and
return a modified output to the application according to the modified call based on the policy being active (see at least Fig. 5 and col. 8 ln. 55 – col. 9 ln. 45 for API OS kernel calls that are received through a compatibility layer and modifying the calls for successful execution, which includes, then, providing the modified call(s) to the system for said execution (this providing the modified call then shows that the modified call is returned* to the system for the calls execution), thereby to augment or modify a behavior of at least one of the application or the OS (see at least Fig. 5 and col. 8 ln. 55 – col. 9 ln. 45 where the performing of the return of the modified kernel calls change the behavior of operating system (OS) / kernel as the OS would have performed another task or been idle but for the processing of the call).
It would have been obvious for a person of ordinary skill in the art at the time of filing to modify the teachings of Naamneh, as modified by Tse, in order to implement passive compliance system notifications.
Regarding claim 16, the rejection of claim 12 is incorporated and Naamneh discloses:
the condition is determined to be satisfied based on at least one of geospatial location of the computing device, a time of day, an environmental condition, a usage pattern of a user of the computing device, a network type of computing device, or a network security type of the computing device (see at least Fig. 5 and col. 8 ln. 55 – col. 9 ln. 45 where denial or allowance of an access request for an API call is made and the API call is modified when the condition is determined to merit that action and when not merited/satisfied the API is not modified and at least Fig. 3 and col. 8 ln. 13 – 30 discloses that the security system for determining if calls to the API are to be allowed access as per at least col. 5 ln. 55 – col. 9 ln. 8).
Regarding claim 17 the rejection of claim 1 is incorporated and Naamneh discloses:
the call, when received by the API, returns a first output to the application, the first output causing a behavior of the application (see at least col. 7 ln. 65 – col. 8 ln. 5 for the call being utilized by the malware (an application) and therefore the behavior performed by the application is that it is actually utilizing the result of the call).
Claim 4 is rejected under 35 U.S.C. 103(a) as being unpatentable over Naamneh in view of Tse and further in view of Willson et al. (hereinafter Willson, US 11,403,136).
Regarding claim 4, the rejection of claim 2 is incorporated and Naamneh discloses:
the processor resource is to transform the filtered call to the API service (at least Fig. 3 and col. 6 ln. 7 – col. 8 ln. 38 discloses that the API calls are determined for their compatibility and incompatibility with the system, this acts as a filter for one set of calls being handled in one fashion (i.e. if incompatible, they are modified to be made compatible)).
Naamneh and Tse do not disclose, however, Willson discloses:
prioritizing a first content type over a second content type (see at least Fig. 2 and col. 9 ln. 25 – col. 11 ln. 58).
It would have been obvious for a person of ordinary skill in the art at the time of filing to modify the teachings of Naamneh, as modified by the teachings of Tse, by the teachings of Willson in order to implement options to execute higher importance tasks for execution.
Claims 5 and 6 are rejected under 35 U.S.C. 103(a) as being unpatentable over Naamneh in view of Aspro et al. (hereinafter Aspro, US 11,403,136).
Regarding claim 5, the rejection of claim 1 is incorporated and Naamneh does not expressly disclose, however, Aspro discloses:
the computing device further includes a sensor to capture sensor data (see ph. [0021] that discloses sensor as a data source for the computing system and said system’s device(s)).
It would have been obvious for a person of ordinary skill in the art at the time of filing to modify the teachings of Naamneh, as modified by the teachings of Aspro in order to allow for real world real-time data to be collected and added to the computing system for processing.
Regarding claim 6, the rejection of claim 5 is incorporated and Naamneh discloses:
the processor resource is to cause, based on the captured sensor data, the policy to be activated (at least ph. [0021] - [0025] discloses that data sources of backend systems can result in an API system call and then trigger rules/instructions/policies of the system to modify the API calls of clients).
It would have been obvious for a person of ordinary skill in the art at the time of filing to modify the teachings of Naamneh, by the teachings of Aspro in order to allow for real world real-time data to be collected and added to the computing system for processing.
Claims 12 – 15 and 19 are rejected under 35 U.S.C. 103(a) as being unpatentable over Naamneh in view of Aspro.
Regarding claim 12, Naamneh discloses:
a method (see at least Fig. 3 and col. 6 ln. 7 – col. 8 ln. 38), comprising:
causing, by a computing device see at least Fig. 1 and col. 4 ln. 11 – col. 5 ln. 43), a policy to be activated based on data (see at least Fig. 3 and col. 6 ln. 7 – col. 8 ln. 38 indicates that upon a determination from data/information in the system that there is an incompatible call, that further steps (e.g. modifying the call) should be taken, as such the policy of modifying for enforcing compatibility is activated);
transmitting, by the computing device, a system call from an application to an application programming interface (API) service of an operating system (OS) of the computing device (see at least Fig. 3 where the call to be intercepted is to the API (and then is generated from somewhere else and then sent/transmitted to the API and see at least Fig. 4 – 6 and their respective brief descriptions in col. 3 ln. 17 – 27 that describe the API calls as system calls, Fig. 1 and col. 4 ln. 11 – col. 5 ln. 43 and at least Fig. 3 and col. 6 ln. 7 – col. 8 ln. 38 for the API OS system calls being received and modified);
before the system call is received by the API service of the OS of the computing device hooking, by the computing device, the system call (see at least Fig. 1 and col. 4 ln. 11 – col. 5 ln. 43 and at least Fig. 3 and col. 6 ln. 7 – col. 8 ln. 38 for the API OS system calls being received, intercepted/ hooked and modified whereas mentioned in Fig. 3 block 302 a call “to and API” indicates that the call is directed to the API and that call *to* the API is what is intercepted, which then indicates that the interception is before the call is made to the API);
modifying, by the computing device, the hooked system call based on the policy (see at least Fig. 1 and col. 4 ln. 11 – col. 5 ln. 43 and at least Fig. 3 and col. 6 ln. 7 – col. 8 ln. 38 for the API OS system calls being received, intercepted/ hooked and modified); and
return a modified output to the application according to the modified call based on the policy being active (see at least Fig. 5 and col. 8 ln. 55 – col. 9 ln. 45 for API OS kernel calls that are received through a compatibility layer and modifying the calls for successful execution, which includes, then, providing the modified call(s) to the system for said execution (this providing the modified call then shows that the modified call is returned* to the system for the calls execution), thereby to augment or modify a behavior of at least one of the application or the OS (see at least Fig. 5 and col. 8 ln. 55 – col. 9 ln. 45 where the performing of the return of the modified kernel calls change the behavior of operating system (OS) / kernel as the OS would have performed another task or been idle but for the processing of the call).
Naamneh does not expressly disclose, however, Aspro discloses:
sensor data from a sensor (at least ph. [0021] - [0025] discloses that data sources of backend systems can result in an API system call and then trigger rules/instructions/policies of the system to modify the API calls of clients).
It would have been obvious for a person of ordinary skill in the art at the time of filing to modify the teachings of Naamneh, as modified by Tse, by the teachings of Aspro in order to allow for real world real-time data to be collected and added to the computing system for processing.
Regarding claim 13, the rejection of claim 12 is incorporated and Naamneh discloses:
modifying the hooked system call includes adding a parameter to the hooked system call (at least Fig. 3 and col. 6 ln. 7 – col. 8 ln. 38 discloses that parameters/flags may be adjusted as part of the modifying of the API calls to allow for the calls’ compatibility).
Regarding claim 14, the rejection of claim 12 is incorporated and Naamneh discloses:
modifying the hooked system call includes adding a flag to the hooked system call for a different API (at least Fig. 3 and col. 6 ln. 7 – col. 8 ln. 38 discloses that parameters/flags may be adjusted as part of the modifying of the API calls to allow for the calls’ compatibility, including the adding / injection of such parameters / flags).
Regarding claim 15, the rejection of claim 12 is incorporated and Naamneh discloses:
causing the application to execute according to the modified output (at least Fig. 3 and col. 6 ln. 7 – col. 8 ln. 38 discloses that the execution continues after the modification with the modified version of the API call).
Regarding claim 19, the rejection of claim 12 is incorporated and Naamneh discloses:
is determining whether the condition is satisfied the policy is based on at least one of geospatial location of the computing device, a time of day, an environmental condition, a usage pattern of a user of the computing device, a network type of computing, or a network security type of the computing device (see at least Fig. 5 and col. 8 ln. 55 – col. 9 ln. 45 where denial or allowance of an access request for an API call is made and the API call is modified when the condition is determined to merit that action and when not merited/satisfied the API is not modified and at least Fig. 3 and col. 8 ln. 13 – 30 discloses that the security system for determining if calls to the API are to be allowed access as per at least col. 5 ln. 55 – col. 9 ln. 8).
Claims 9 – 11 and 18 are rejected under 35 U.S.C. 103(a) as being unpatentable over Naamneh in view of Tse and further in view of Thompson (US 12,073,263).
Regarding claim 9, the rejection of claim 8 is incorporated and Naamneh and Tse does not expressly disclose, however, Thompson discloses:
the policy is one of a plurality of policies (col. 14 ln. 61 – col. 15 ln. 7 discloses various rules/policies for carrying out proper processing of the system by properly carrying out the instructions for those rules/polices).
It would have been obvious for a person of ordinary skill in the art at the time of filing to modify the teachings of Naamneh, as modified by the teachings of Tse, by the teachings of Thompson in order to have code that follows logic for actually practical processing.
Regarding claim 10, the rejection of claim 9 is incorporated and Naamneh does not expressly disclose, however, Thompson discloses:
the processor resource is to receive an updated plurality of policies from a remote computing device (col. 14 ln. 61 – col. 15 ln. 53 for being able to modify the execution plan (therefore modification of the rules/policies of its execution) are necessary/proper).
It would have been obvious for a person of ordinary skill in the art at the time of filing to modify the teachings of Naamneh, as modified by the teachings of Tse, by the teachings of Thompson in order to have code that follows logic for actually practical processing.
Regarding claim 11, the rejection of claim 9 is incorporated and Naamneh does not expressly disclose, however, Thompson discloses:
the computing device includes a user account associated with the plurality of policies (col. ln. – discloses that multiple APIs may be associated with a particular customer, this then indicates that the execution environment system discloses associates the customer (user) with information related to the associated APIs with that customer/user, this then discloses that an account that associates the customer/user with the data that indicates which APIs is associated with the user is a present and disclosed feature); and
the processor resource is to receive the plurality of policies in response to the user account accessing the computing device (col. ln. discloses that the customer/user may modify the APIs functioning / code, as such its rules/policies that indicate the functioning of the APIs when the customer accesses the system through the information that links the customer to the customer’s respective information (i.e. when the user accesses the user’s account).
It would have been obvious for a person of ordinary skill in the art at the time of filing to modify the teachings of Naamneh, as modified by the teachings of Tse, by the teachings of Thompson in order to have code that follows logic for actually practical processing.
Regarding claim 18, the rejection of claim 9 is incorporated and Naamneh discloses:
determine condition information, wherein the condition information includes at least one of geospatial location of the computing device, a time of day, an environmental condition, a usage pattern of a user of the computing device, a network type of computing device, or a network security type of the computing device (see at least Fig. 5 and col. 8 ln. 55 – col. 9 ln. 45 where denial or allowance of an access request for an API call is made and the API call is modified when the condition is determined to merit that action and when not merited/satisfied the API is not modified and at least Fig. 3 and col. 8 ln. 13 – 30 discloses that the security system for determining if calls to the API are to be allowed access as per at least col. 5 ln. 55 – col. 9 ln. 8);
evaluate the condition information to determine whether the condition is satisfied (see at least Fig. 5 and col. 8 ln. 55 – col. 9 ln. 45 where denial or allowance of an access request for an API call is made and the API call is modified when the condition is determined to merit that action and when not merited/satisfied the API is not modified).
Claim 20 is rejected under 35 U.S.C. 103(a) as being unpatentable over Naamneh in view of Tse and further in view of Schulz et al. (hereinafter Schulz, US 10,580,073).
Regarding claim 20, the rejection of claim 12 is incorporated and Naamneh does not expressly, however, Schulz discloses:
receive an updated version of the policy from a remote computing device (see at least Fig. 1 and col. 4 ln. 49 – col. 6 ln. 24 that discloses receiving information to dynamically change the computer control logic (a policy under which the computer is to perform its tasks), thereby there is a continuously updating of versions of the policy that determines the executing obligation computer control logic) ).
It would have been obvious for a person of ordinary skill in the art at the time of filing to modify the teachings of Naamneh, as modified by the teachings of Tse, by the teachings of Schulz in order to rapidly adapt to changing situations in order to increase the performance of final results.
Response to Arguments
Applicant Applicant’s arguments have been fully considered but are moot in light of new grounds of rejection.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CRAIG C DORAIS whose telephone number is (571)270-3371. The examiner can normally be reached M-F 9:00 am - 6: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, Pierre Vital can be reached at 5712724215. 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.
/CRAIG C DORAIS/Primary Examiner, Art Unit 2198
Prosecution Insights