Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
1. This action is responsive to: an original application filed on 3 July 2025.
2. Claims 1-20 are currently pending and rejected.
Information Disclosure Statement
3. No IDS filed.
Priority
4. Priority date claimed has been considered.
Drawings
5. The drawings filed on 3 July 2025 are accepted by the examiner.
Double Patenting
6. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents /process/ file/efs/guidance /eTD-info-I.jsp.
Claims 1-20 are rejected under the grounds of non-statutory obviousness-type double patenting, as they are deemed unpatentable over claims 1-20 of US Patent application No. 18483724.
Although the conflicting claims are not identical, they are considered not patentably distinct from one another, as they convey the same inventive concept. Specifically, both sets of claims disclose a method for PROCESS SECURITY CAPABILITY REQUIREMENTS IDENTIFICATION
by using system call analysis. Furthermore, it would have been obvious to one of ordinary skill in the art, at the time of the invention’s filing, to employ this approach to prevent and protect software that attempt to run by the kernel, thereby rendering the claims unpatentable.
Claim Rejections - 35 USC § 102
7. 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 –
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
(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-20 are rejected 35 U.S.C §102 (a)(1) as being anticipated by Cohen et al. (US Patent No. 9804952), hereinafter Cohen.
Regarding claim 1:
One or more non-transitory computer-readable media having instructions stored thereon, wherein the instructions, when executed by one or more processors, cause an analysis system to perform processing comprising (Cohen, col 5, lines 48-53):
identifying a system call to be made by a process, the system call to be executed by a kernel of an operating system of a computer system (Cohen, col 10, lines 18-36), wherein when a system call returns, monitor 122 may determine whether the system call was successful or failed, along with a set of capabilities used by the particular system call. Accordingly, debug information 232 may provide additional information that allows a user to work the issue further by providing valuable feedback. For example, a user reviewing debug information 232 may identify system calls and/or capabilities that application 118.
determining a set of one or more capabilities assigned to the process (Cohen, col 18, lines 37-47, col 11, lines 15-29), wherein determines whether a system call uses a capability. If so, 20
container manager 124 performs action 220 and thus performs capability check 222. If the system call does not use a capability, container manager 124 may skip actions 220 and 224 for the particular system call. In another example, container manager 124 implements the capability check 222 25 by determining whether the system call uses a capability. It should be understood that a set of capabilities may refer to zero or more capabilities or one or more capabilities.
determining one or more capabilities prerequisite for execution of the system call (Cohen, col 7, lines 50-61), wherein Process 204A is assigned a process identifier (ID) 208A that uniquely identifies the process, and process 204B is assigned a process ID 208B that uniquely identifies
the process. Restricted container 126 may restrict one or more system calls and/or one or more capabilities from being invoked within the container. If an application attempts to invoke a restricted system call from within restricted container 126, the system call is unavailable and fails. Additionally, if an application attempts to invoke a restricted capability from within restricted container 126, the capability is unavailable and the system call that uses the restricted capability fails.
identifying a capability included in the set of one or more capabilities assigned to the process that is not included in the one or more capabilities (Cohen, col 9, lines 10-24), wherein System call 206 uses set of capabilities 224 in order to 10 complete the system call. Application 118 has attempted to invoke set of capabilities 224 in accordance with invocation of system call 206. In some examples, dynamically instrumenting capability check 222 and system call returns in kernel 120 with container manager 124 allows very clear 15 determination of the capabilities used by the application's system calls. A system call that has failed may be referred to as a failed system call. A system call may fail for various reasons. For example, a system call may fail because
restricted container 126 restricts the system call from being 20 invoked within the restricted container, restricts a capability used by the system call from being invoked within the restricted container, the application running in restricted container 126 is corrupt, or other reasons.
and applying a change to the process to remove the capability from the set of one or more capabilities assigned to the process (Cohen, col 11, lines 1-13), wherein modify application 118 and remove this system call or capability from being invoked by application 118. In this example, the system call or capability may be unnecessary, and the user may accordingly modify application 118 to not invoke one or more of the restricted capabilities. 10 These approaches may allow for application 118 to successfully run in restricted container 126, or would provide for fewer system call failures.
Regarding claim 2:
wherein determining the set of one or more capabilities assigned to the process includes determining a privilege level assigned to the process, wherein the privilege level indicates the set of one or more capabilities (Cohen, col 6, lines 23-42).
Regarding claim 3:
wherein the instructions, when executed by the one or more processors, cause the analysis system to perform further processing comprising: determining an updated privilege level that omits the capability, wherein applying the change to the process includes assigning the updated privilege level to the process (Cohen, col 10, lines 50-67).
Regarding claim 4:
wherein identifying the system call includes: intercepting, by an interceptor of the analysis system, the system call, the interceptor located between a program that executes the process and an execution engine of an operating system kernel of the computer system (Cohen, Fig.6).
Regarding claim 5:
wherein the interceptor comprises an in-line process that intercepts the system call at runtime (Cohen, col 12, LINES 41-54).
Regarding claim 6:
wherein the interceptor intercepts the system call prior to execution of the system call by the operating system kernel (Cohen, col 3, lines 1-22).
Regarding claim 7:
wherein the instructions, when executed by the one or more processors, cause the analysis system to perform further processing comprising: preventing, by the interceptor, the system call from arriving at the execution engine; or delaying, by the interceptor, the system call from arriving at the execution engine (Cohen, col 3, lines 32-57).
Regarding claim 8:
wherein determining the one or more capabilities comprises: determining a type of the system call; and performing analysis of the system call based at least in part on the type of the system call, the one or more capabilities prerequisite for execution of the system call determined based at least in part on results of the analysis (Cohen, col 10, lines 19-45).
Regarding claim 9:
wherein: determining the type of the system call comprises determining that the system call is an argument-specific system call type; and performing the analysis comprises: determining one or more arguments of the system call; and determining the one or more capabilities based on the one or more arguments (Cohen, col 9, lines 37-61).
Regarding claim 10:
wherein: determining the type of the system call comprises determining that the system call is an environment-specific system call type; and performing the analysis comprises: determining one or more parameters corresponding to the system call; determining a state of an environment in which the system call is to be executed; and determining the one or more capabilities based on the one or more parameters and the state of the environment (Cohen, col 10, lines 47-65).
Regarding claim 11:
identifying a system call to be made by a process, the system call to be executed by a kernel of an operating system of a computer system (Cohen, col 10, lines 18-36), wherein when a system call returns, monitor 122 may determine whether the system call was successful or failed, along with a set of capabilities used by the particular system call. Accordingly, debug information 232 may provide additional information that allows a user to work the issue further by providing valuable feedback. For example, a user reviewing debug information 232 may identify system calls and/or capabilities that application 118.
determining a set of one or more capabilities assigned to the process (Cohen, col 18, lines 37-47, col 11, lines 15-29), wherein determines whether a system call uses a capability. If so, 20
container manager 124 performs action 220 and thus performs capability check 222. If the system call does not use a capability, container manager 124 may skip actions 220 and 224 for the particular system call. In another example, container manager 124 implements the capability check 222 25 by determining whether the system call uses a capability. It should be understood that a set of capabilities may refer to zero or more capabilities or one or more capabilities.
determining one or more capabilities prerequisite for execution of the system call (Cohen, col 7, lines 50-61), wherein Process 204A is assigned a process identifier (ID) 208A that uniquely identifies the process, and process 204B is assigned a process ID 208B that uniquely identifies
the process. Restricted container 126 may restrict one or more system calls and/or one or more capabilities from being invoked within the container. If an application attempts to invoke a restricted system call from within restricted container 126, the system call is unavailable and fails. Additionally, if an application attempts to invoke a restricted capability from within restricted container 126, the capability is unavailable and the system call that uses the restricted capability fails.
identifying a capability included in the set of one or more capabilities assigned to the process that is not included in the one or more capabilities (Cohen, col 9, lines 10-24), wherein System call 206 uses set of capabilities 224 in order to 10 complete the system call. Application 118 has attempted to invoke set of capabilities 224 in accordance with invocation of system call 206. In some examples, dynamically instrumenting capability check 222 and system call returns in kernel 120 with container manager 124 allows very clear 15 determination of the capabilities used by the application's system calls. A system call that has failed may be referred to as a failed system call. A system call may fail for various reasons. For example, a system call may fail because
restricted container 126 restricts the system call from being 20 invoked within the restricted container, restricts a capability used by the system call from being invoked within the restricted container, the application running in restricted container 126 is corrupt, or other reasons. and applying a change to the process to remove the capability from the set of one or more capabilities assigned to the process (Cohen, col 11, lines 1-13), wherein modify application 118 and remove this system call or capability from being invoked by application 118. In this example, the system call or capability may be unnecessary, and the user may accordingly modify application 118 to not invoke one or more of the restricted capabilities. 10 These approaches may allow for application 118 to successfully run in restricted container 126, or would provide for fewer system call failures.
Regarding claim 12:
wherein determining the set of one or more capabilities assigned to the process includes determining a privilege level assigned to the process, wherein the privilege level indicates the set of one or more capabilities (Cohen, col 6, lines 23-42).
Regarding claim 13:
further comprising: determining an updated privilege level that omits the capability, wherein applying the change to the process includes assigning the updated privilege level to the process (Cohen, col 10, lines 50-67).
Regarding claim 14:
wherein identifying the system call includes: intercepting, by an interceptor of an analysis system, the system call, the interceptor located between a program that executes the process and an execution engine of an operating system kernel of the computer system (Cohen, Fig.6).
Regarding claim 15:
wherein the interceptor comprises an in-line process that intercepts the system call at runtime (Cohen, col 12, lines 41-54).
Regarding claim 16:
further comprising: preventing, by the interceptor, the system call from arriving at the execution engine; or delaying, by the interceptor, the system call from arriving at the execution engine (Cohen, col 3, lines 32-57).
Regarding claim 17:
a memory to store a system call to be made by a process during execution of the process (Cohen, col 16, lines 4-9).
and a processor to: identify a system call to be made by a process, the system call to be executed by a kernel of an operating system of a computer system (Cohen, col 10, lines 18-36), wherein when a system call returns, monitor 122 may determine whether the system call was successful or failed, along with a set of capabilities used by the particular system call. Accordingly, debug information 232 may provide additional information that allows a user to work the issue further by providing valuable feedback. For example, a user reviewing debug information 232 may identify system calls and/or capabilities that application 118.
determine a set of one or more capabilities assigned to the process (Cohen, col 18, lines 37-47, col 11, lines 15-29), wherein determines whether a system call uses a capability. If so, 20
container manager 124 performs action 220 and thus performs capability check 222. If the system call does not use a capability, container manager 124 may skip actions 220 and 224 for the particular system call. In another example, container manager 124 implements the capability check 222 25 by determining whether the system call uses a capability. It should be understood that a set of capabilities may refer to zero or more capabilities or one or more capabilities.
determine one or more capabilities prerequisite for execution of the system call (Cohen, col 7, lines 50-61), wherein Process 204A is assigned a process identifier (ID) 208A that uniquely identifies the process, and process 204B is assigned a process ID 208B that uniquely identifies the process. Restricted container 126 may restrict one or more system calls and/or one or more capabilities from being invoked within the container. If an application attempts to invoke a restricted system call from within restricted container 126, the system call is unavailable and fails. Additionally, if an application attempts to invoke a restricted capability from within restricted container 126, the capability is unavailable and the system call that uses the restricted capability fails.
identify a capability included in the set of one or more capabilities assigned to the process that is not included in the one or more capabilities (Cohen, col 9, lines 10-24), wherein System call 206 uses set of capabilities 224 in order to 10 complete the system call. Application 118 has attempted to invoke set of capabilities 224 in accordance with invocation of system call 206. In some examples, dynamically instrumenting capability check 222 and system call returns in kernel 120 with container manager 124 allows very clear 15 determination of the capabilities used by the application's system calls. A system call that has failed may be referred to as a failed system call. A system call may fail for various reasons. For example, a system call may fail because
restricted container 126 restricts the system call from being 20 invoked within the restricted container, restricts a capability used by the system call from being invoked within the restricted container, the application running in restricted container 126 is corrupt, or other reasons.
and apply a change to the process to remove the capability from the set of one or more capabilities assigned to the process (Cohen, col 11, lines 1-13), wherein modify application 118 and remove this system call or capability from being invoked by application 118. In this example, the system call or capability may be unnecessary, and the user may accordingly modify application 118 to not invoke one or more of the restricted capabilities. 10 These approaches may allow for application 118 to successfully run in restricted container 126, or would provide for fewer system call failures.
Regarding claim 18:
wherein to determine the one or more capabilities comprises to: determine a type of the system call; and perform analysis of the system call based at least in part on the type of the system call, the one or more capabilities prerequisite for execution of the system call determined based at least in part on results of the analysis (Cohen, col 10, lines 19-45).
Regarding claim 19:
wherein to: determine the type of the system call comprises to determine that the system call is an argument-specific system call type; and perform the analysis comprises to: determine one or more arguments of the system call; and determine the one or more capabilities based on the one or more arguments (Cohen, col 9, lines 37-61).
Regarding claim 20:
wherein to: determine the type of the system call comprises to determine that the system call is an environment-specific system call type; and perform the analysis comprises to: determine one or more parameters corresponding to the system call; determine a state of an environment in which the system call is to be executed; and determine the one or more capabilities based on the one or more parameters and the state of the environment (Cohen, col 10, lines 47-65).
Conclusion
8. The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Monjour Rahim whose telephone number is (571)270-3890.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Shewaye Gelagay can be reached on 571-272-4219. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (in USA or CANANDA) or 571-272-1000.
/Monjur Rahim/
Patent Examiner
United States Patent and Trademark Office
Art Unit: 2436; Phone: 571.270.3890
E-mail: monjur.rahim@uspto.gov
Fax: 571.270.4890
Prosecution Insights