DETAILED ACTION
This non-final Office Action is in response to applicants’ filing on 05/13/2024. Claims 1-30 are presented for examination and have been considered as follows.
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 .
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.
Drawings
The drawings filed on 05/13/2024 are accepted.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 11/18/2024 have been placed in the application file, and the information referred therein has been considered as to the merits.
Examiner’s Note: Applicants’ express definition of “computer-storage medium” in the Specification on page 43 para. [00127] has been noted. “As used herein, the terms "machine-storage medium," "device-storage medium," and "computer-storage medium" mean the same thing and may be used interchangeably in this disclosure. The terms refer to single or multiple storage devices and/or media (e.g., a centralized or distributed database, and/or associated caches and servers) that store executable instructions and/or data. The terms shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media, including memory internal or external to processors. Specific examples of machine-storage media, computer-storage media, and/or device-storage media include non-volatile memory, including by way of example semiconductor memory devices, e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read- only memory (EEPROM), field-programmable gate arrays (FPGAs), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The terms "machine-storage media," "computer-storage media," and "device-storage media" specifically exclude carrier waves, modulated data signals, and other such media, at least some of which are covered under the term "signal medium" discussed below.”
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 7, 11, 12, 17, and 27 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.
Claim 7 recites the limitation “the allowed list of system calls” in line 8, but it is unclear if this is referring to the “conditionally allowed list of system calls” recited in Claim 6 or an entirely separate list not previously recited.
Claim 11 recites the limitation "the compute node" in line 6. There is insufficient antecedent basis for this limitation in the claim.
Claim 12 recites the limitation "the compute node" in line 3. There is insufficient antecedent basis for this limitation in the claim.
Claim 17 recites the limitation “the allowed list of system calls” in line 8, but it is unclear if this is referring to the “conditionally allowed list of system calls” recited in Claim 16 or an entirely separate list not previously recited.
Claim 27 recites the limitation “the allowed list of system calls” in line 9, but it is unclear if this is referring to the “conditionally allowed list of system calls” recited in Claim 26 or an entirely separate list not previously recited.
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)(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-5, 8-15, 18-25, and 28-30 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Russello (US 20150332043 A1, IDS submitted 11/18/2024).
As to Claim 1:
Russello discloses a method (e.g. Russello “a method of analysing applications executing on a target device via an analysis graphical user interface (GUI) displayed on an analysis device” [0032]) comprising:
instantiating, by at least one hardware processor of a compute node (e.g. Russello system or device having processor or processors configured to carry out the methods [0047]), a first process and a second process, the second process executing at the compute node as a child process of the first process (e.g. Russello “parent of the target process and will be able to monitor and control all the child processes” [0195]; initialization and starting of main monitor and child Zygote process [0199]; [0257]);
detecting a notification associated with a system call initiated by the child process (e.g. Russello “the main monitor should receive a notification every time the target Zygote process enters or exits to and from a system call” [0199]; “When the security system starts, only the main monitor process is running, along with the security system service. The main monitor is attached to and monitoring the Zygote process. New process monitors are created as children of the main monitor as a result of the fork system call invocations made by the Zygote process” [0203]; “this ensures that the process monitors will receive notifications of any system calls executed by every single thread and process that descends from the root application process” [0258]; [0260]);
pausing the child process based on the notification (e.g. Russello “Every time Zygote 62 invokes a fork system call 64, it will be suspended 65 by the kernel 66 and the main monitor 70 will be notified by the kernel via a signal 68 (e.g. SIGCHILD) and woken up” [0205]; “When a system call is made by the target process, the kernel will suspend the target process execution and will unblock the process monitor (e.g. using SIGCHILD signal). The waitpid( ) function will return the ID of the thread (TID) that generated the system call as well as some additional process state information that is used for other purposes” [0261]);
retrieving via the first process, at least one permission associated with the system call (e.g. Russello “The security system is configured to retrieve and load a specific security policy or set of policies to the new process monitor 72 based on application identification data” [0219]; “the process monitor policies can be initialized and policies can be enforced specific to that process. The package name is forwarded to the process monitor's policy decision point, which will load the specific policies for the monitored process” [0223]; [0230]); and
performing a determination of whether to resume the child process based on the at least one permission (e.g. Russello “Each process monitor is configured to enforce the retrieved security policy for its attached new process by implementing a security action at the Linux layer in regard to the detected system call based on the retrieved security policy. The security action may comprise any one or more of the following: allowing the system call to proceed, blocking the system call from proceeding, or modifying parameters of the system call prior to execution or return values generated by the system call after execution” [0226]; “In case the process is allowed to continue and after the decision is enforced, the process monitor will notify the kernel to continue the process execution (eg. ptrace(PTRACE_SYSCALL))” [0261]).
As to Claim 2:
Russello discloses the method of claim 1, further comprising: initiating a trace on the paused child process based on a tracing configuration associated with the compute node (e.g. Russello “The term “monitoring” as used in this specification and claims is intended to mean, in the context of a master-target process relationship, where the master intercepts, controls, modifies and/or traces system calls made by the target process” [0131]; “When a process monitor invokes ptrace to attach to a target process, each time the target process invokes a system call the gateway will suspend the target process and send a signal to its process monitor” [0185]; “using a tracing system call that is configured to enable a master process to control a target process by inspecting its memory and registers and intercepting its system call invocations. In this embodiment, the tracing system call is the process trace system call (ptrace)” [0195]; [0259]).
As to Claim 3:
Russello discloses the method of claim 2, further comprising: retrieving a set of system call categories (e.g. Russello receiving configuration code for monitoring blocked system calls, logging system call, suspending system calls [0109]; illegal system calls, normal processes [0170]; [0192]) and a corresponding set of filtering policies of the tracing configuration (e.g. Russello “set of security policies for one or more processes” [0189] retrieved by security system [0194]; “security system is configured to retrieve and load a specific security policy or set of policies to the new process monitor” [0219]; [0223]; [0226]).
As to Claim 4:
Russello discloses the method of claim 3, further comprising: detecting the system call is associated with a system call category of the set of system call categories (e.g. Russello process monitor determines if the system call is allowed, blocked, or modifiable [0192]) and a corresponding filtering policy of the set of filtering policies, the corresponding filtering policy specifying the at least one permission (e.g. Russello “process monitor 52 then decides based on the security policy configured for the associated application 10 in the application layer and other parameters extracted from the process execution state whether to block the system call or otherwise allow the system call to proceed in its original or a modified state” [0193]).
As to Claim 5:
Russello discloses the method of claim 3, further comprising: configuring the set of system call categories to include a blocked system call category (e.g. Russello blocked system call [0058]; [0170]; [0192]; denied system call [0283]), a fatally blocked system call category (e.g. Russello “kill the monitored process 304 making the function call altogether… depending on the nature of the associated system call that was to be invoked and/or security policy associated with the process, such as kill the entire process or return a value or error code to the process to prevent crashing” [0283]), and a conditionally allowed system call category (e.g. Russello modified system call [0192]; modifying parameters of the system call [0226]; system/function call is modifiable to allow execution [0283]).
As to Claim 8:
Russello discloses the method of claim 1, further comprising: determining to block the child process based on the system call violating the at least one permission (e.g. Russello “killing the process” [0109]; “Based on the security policy or policies configured in the monitoring entity 310 for the process 304, the monitoring entity 310 implements a security action or decision on the detected function call… kill the monitored process 304 making the function call altogether” [0283]; “if the security policy dictates that the application 331 should not be allowed to invoke the function… the enter method of the PEP 339 can return a decision to ‘kill’ 346 the application. In this case, the wrapper function 345 will perform an exit terminating the process and its application” [0294]).
As to Claim 9:
Russello discloses the method of claim 2, further comprising: determining to resume the child process based on the system call not violating the at least one permission (e.g. Russello “The child process 375 also raises a SIGSTOP 380 to be stopped until the parent process 370 allows it to resume its execution. When the child process 375 resumes its execution, it will continue with the dlopen 384 operation” [0319]; “they should be notified every time their target process executes a system call (using e.g. ptrace(PTRACE_SYSCALL)” [0260]; “After the decision point returns, the enforcement will continue the monitored process if the decision indicates to do so” [0261]; [0365]); and initiating an exit handling to suspend the trace (e.g. Russello “Once this setup has been performed, the process monitors go to sleep (e.g. invokes waitpid( )) after attaching to the monitored target process. This blocks the process monitor… In case the process is allowed to continue and after the decision is enforced, the process monitor will notify the kernel to continue the process execution (eg. ptrace(PTRACE_SYSCALL)) and goes back to sleep” [0261]).
As to Claim 10:
Russello discloses the method of claim 9, further comprising: configuring a teardown of the child process based on completion of the system call (e.g. Russello “A process is terminated when its operations are completed. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc., in a computer program. When a process corresponds to a function, its termination corresponds to a return of the function to the calling function or a main function” [0143]; “When the fork system call returns in Zygote (the system call is exiting), the process will be still stopped 66 and the kernel will notify the main monitor 70 via signal 82 (e.g. SIGCHILD)” [0214]).
As to Claim 11:
Russello discloses a system (e.g. Russello “analysis system for analysing applications executing on a target device. The system comprises an analysis agent operating on the target device that is configured to receive or retrieve information indicative of system call invocations initiated by applications during execution. The system also comprises an analysis device in data communication with the target device over a data communication link that is configured to receive the information from the analysis agent of the target device over the data communication link. The analysis device comprises an analysis graphical user interface (GUI) that is configured to display the received information for viewing and/or interaction by a user” [Abstract]) comprising:
at least one hardware processor of a computing node (e.g. Russello system or device having processor or processors configured to carry out the methods [0047]); and
at least one memory storing instructions that cause the at least one hardware processor to perform operations (e.g. Russello “a computer-readable medium having stored thereon computer readable instructions that, when executed on a processing device, cause the processing device to perform any one or more of the methods” [0046]) comprising:
instantiating a first process and a second process, the second process executing at the compute node as a child process of the first process (e.g. Russello “parent of the target process and will be able to monitor and control all the child processes” [0195]; initialization and starting of main monitor and child Zygote process [0199]; [0257]);
detecting a notification associated with a system call initiated by the child process (e.g. Russello “the main monitor should receive a notification every time the target Zygote process enters or exits to and from a system call” [0199]; “When the security system starts, only the main monitor process is running, along with the security system service. The main monitor is attached to and monitoring the Zygote process. New process monitors are created as children of the main monitor as a result of the fork system call invocations made by the Zygote process” [0203]; “this ensures that the process monitors will receive notifications of any system calls executed by every single thread and process that descends from the root application process” [0258]; [0260]);
pausing the child process based on the notification (e.g. Russello “Every time Zygote 62 invokes a fork system call 64, it will be suspended 65 by the kernel 66 and the main monitor 70 will be notified by the kernel via a signal 68 (e.g. SIGCHILD) and woken up” [0205]; “When a system call is made by the target process, the kernel will suspend the target process execution and will unblock the process monitor (e.g. using SIGCHILD signal). The waitpid( ) function will return the ID of the thread (TID) that generated the system call as well as some additional process state information that is used for other purposes” [0261]);
retrieving via the first process, at least one permission associated with the system call (e.g. Russello “The security system is configured to retrieve and load a specific security policy or set of policies to the new process monitor 72 based on application identification data” [0219]; “the process monitor policies can be initialized and policies can be enforced specific to that process. The package name is forwarded to the process monitor's policy decision point, which will load the specific policies for the monitored process” [0223]; [0230]); and
performing a determination of whether to resume the child process based on the at least one permission (e.g. Russello “Each process monitor is configured to enforce the retrieved security policy for its attached new process by implementing a security action at the Linux layer in regard to the detected system call based on the retrieved security policy. The security action may comprise any one or more of the following: allowing the system call to proceed, blocking the system call from proceeding, or modifying parameters of the system call prior to execution or return values generated by the system call after execution” [0226]; “In case the process is allowed to continue and after the decision is enforced, the process monitor will notify the kernel to continue the process execution (eg. ptrace(PTRACE_SYSCALL))” [0261]).
As to Claim 12:
Russello discloses the system of claim 11, the operations further comprising: initiating a trace on the paused child process based on a tracing configuration associated with the compute node (e.g. Russello “The term “monitoring” as used in this specification and claims is intended to mean, in the context of a master-target process relationship, where the master intercepts, controls, modifies and/or traces system calls made by the target process” [0131]; “When a process monitor invokes ptrace to attach to a target process, each time the target process invokes a system call the gateway will suspend the target process and send a signal to its process monitor” [0185]; “using a tracing system call that is configured to enable a master process to control a target process by inspecting its memory and registers and intercepting its system call invocations. In this embodiment, the tracing system call is the process trace system call (ptrace)” [0195]; [0259]).
As to Claim 13:
Russello discloses the system of claim 12, the operations further comprising: retrieving a set of system call categories (e.g. Russello receiving configuration code for monitoring blocked system calls, logging system call, suspending system calls [0109]; illegal system calls, normal processes [0170]; [0192]) and a corresponding set of filtering policies of the tracing configuration (e.g. Russello “set of security policies for one or more processes” [0189] retrieved by security system [0194]; “security system is configured to retrieve and load a specific security policy or set of policies to the new process monitor” [0219]; [0223]; [0226]).
As to Claim 14:
Russello discloses the system of claim 13, the operations further comprising: detecting the system call is associated with a system call category of the set of system call categories (e.g. Russello process monitor determines if the system call is allowed, blocked, or modifiable [0192]) and a corresponding filtering policy of the set of filtering policies, the corresponding filtering policy specifying the at least one permission (e.g. Russello “process monitor 52 then decides based on the security policy configured for the associated application 10 in the application layer and other parameters extracted from the process execution state whether to block the system call or otherwise allow the system call to proceed in its original or a modified state” [0193]).
As to Claim 15:
Russello discloses the system of claim 13, the operations further comprising: configuring the set of system call categories to include a blocked system call category (e.g. Russello blocked system call [0058]; [0170]; [0192]; denied system call [0283]), a fatally blocked system call category (e.g. Russello “kill the monitored process 304 making the function call altogether… depending on the nature of the associated system call that was to be invoked and/or security policy associated with the process, such as kill the entire process or return a value or error code to the process to prevent crashing” [0283]), and a conditionally allowed system call category (e.g. Russello modified system call [0192]; modifying parameters of the system call [0226]; system/function call is modifiable to allow execution [0283]).
As to Claim 18:
Russello discloses the system of claim 11, the operations further comprising: determining to block the child process based on the system call violating the at least one permission (e.g. Russello “killing the process” [0109]; “Based on the security policy or policies configured in the monitoring entity 310 for the process 304, the monitoring entity 310 implements a security action or decision on the detected function call… kill the monitored process 304 making the function call altogether” [0283]; “if the security policy dictates that the application 331 should not be allowed to invoke the function… the enter method of the PEP 339 can return a decision to ‘kill’ 346 the application. In this case, the wrapper function 345 will perform an exit terminating the process and its application” [0294]).
As to Claim 19:
Russello discloses the system of claim 12, the operations further comprising: determining to resume the child process based on the system call not violating the at least one permission (e.g. Russello “The child process 375 also raises a SIGSTOP 380 to be stopped until the parent process 370 allows it to resume its execution. When the child process 375 resumes its execution, it will continue with the dlopen 384 operation” [0319]; “they should be notified every time their target process executes a system call (using e.g. ptrace(PTRACE_SYSCALL)” [0260]; “After the decision point returns, the enforcement will continue the monitored process if the decision indicates to do so” [0261]; [0365]); and initiating an exit handling to suspend the trace (e.g. Russello “Once this setup has been performed, the process monitors go to sleep (e.g. invokes waitpid( )) after attaching to the monitored target process. This blocks the process monitor… In case the process is allowed to continue and after the decision is enforced, the process monitor will notify the kernel to continue the process execution (eg. ptrace(PTRACE_SYSCALL)) and goes back to sleep” [0261]).
As to Claim 20:
Russello discloses the system of claim 19, the operations further comprising: configuring a teardown of the child process based on completion of the system call (e.g. Russello “A process is terminated when its operations are completed. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc., in a computer program. When a process corresponds to a function, its termination corresponds to a return of the function to the calling function or a main function” [0143]; “When the fork system call returns in Zygote (the system call is exiting), the process will be still stopped 66 and the kernel will notify the main monitor 70 via signal 82 (e.g. SIGCHILD)” [0214]).
As to Claim 21:
Russello discloses a computer-storage medium comprising instructions that, when executed by one or more processors of a machine, configure the machine to perform operations (e.g. Russello “a computer-readable medium having stored thereon computer readable instructions that, when executed on a processing device, cause the processing device to perform any one or more of the methods” [0046]; system or device having processor or processors configured to carry out the methods [0047]) comprising:
instantiating a first process and a second process, the second process executing at a compute node as a child process of the first process (e.g. Russello “parent of the target process and will be able to monitor and control all the child processes” [0195]; initialization and starting of main monitor and child Zygote process [0199]; [0257]);
detecting a notification associated with a system call initiated by the child process (e.g. Russello “the main monitor should receive a notification every time the target Zygote process enters or exits to and from a system call” [0199]; “When the security system starts, only the main monitor process is running, along with the security system service. The main monitor is attached to and monitoring the Zygote process. New process monitors are created as children of the main monitor as a result of the fork system call invocations made by the Zygote process” [0203]; “this ensures that the process monitors will receive notifications of any system calls executed by every single thread and process that descends from the root application process” [0258]; [0260]);
pausing the child process based on the notification (e.g. Russello “Every time Zygote 62 invokes a fork system call 64, it will be suspended 65 by the kernel 66 and the main monitor 70 will be notified by the kernel via a signal 68 (e.g. SIGCHILD) and woken up” [0205]; “When a system call is made by the target process, the kernel will suspend the target process execution and will unblock the process monitor (e.g. using SIGCHILD signal). The waitpid( ) function will return the ID of the thread (TID) that generated the system call as well as some additional process state information that is used for other purposes” [0261]);
retrieving via the first process, at least one permission associated with the system call (e.g. Russello “The security system is configured to retrieve and load a specific security policy or set of policies to the new process monitor 72 based on application identification data” [0219]; “the process monitor policies can be initialized and policies can be enforced specific to that process. The package name is forwarded to the process monitor's policy decision point, which will load the specific policies for the monitored process” [0223]; [0230]); and
performing a determination of whether to resume the child process based on the at least one permission (e.g. Russello “Each process monitor is configured to enforce the retrieved security policy for its attached new process by implementing a security action at the Linux layer in regard to the detected system call based on the retrieved security policy. The security action may comprise any one or more of the following: allowing the system call to proceed, blocking the system call from proceeding, or modifying parameters of the system call prior to execution or return values generated by the system call after execution” [0226]; “In case the process is allowed to continue and after the decision is enforced, the process monitor will notify the kernel to continue the process execution (eg. ptrace(PTRACE_SYSCALL))” [0261]).
As to Claim 22:
Russello discloses the computer-storage medium comprising of claim 21, the operations further comprising: initiating a trace on the paused child process based on a tracing configuration associated with the compute node (e.g. Russello “The term “monitoring” as used in this specification and claims is intended to mean, in the context of a master-target process relationship, where the master intercepts, controls, modifies and/or traces system calls made by the target process” [0131]; “When a process monitor invokes ptrace to attach to a target process, each time the target process invokes a system call the gateway will suspend the target process and send a signal to its process monitor” [0185]; “using a tracing system call that is configured to enable a master process to control a target process by inspecting its memory and registers and intercepting its system call invocations. In this embodiment, the tracing system call is the process trace system call (ptrace)” [0195]; [0259]).
As to Claim 23:
Russello discloses the computer-storage medium comprising of claim 22, the operations further comprising: retrieving a set of system call categories (e.g. Russello receiving configuration code for monitoring blocked system calls, logging system call, suspending system calls [0109]; illegal system calls, normal processes [0170]; [0192]) and a corresponding set of filtering policies of the tracing configuration (e.g. Russello “set of security policies for one or more processes” [0189] retrieved by security system [0194]; “security system is configured to retrieve and load a specific security policy or set of policies to the new process monitor” [0219]; [0223]; [0226]).
As to Claim 24:
Russello discloses the computer-storage medium comprising of claim 23, the operations further comprising: detecting the system call is associated with a system call category of the set of system call categories (e.g. Russello process monitor determines if the system call is allowed, blocked, or modifiable [0192]) and a corresponding filtering policy of the set of filtering policies, the corresponding filtering policy specifying the at least one permission (e.g. Russello “process monitor 52 then decides based on the security policy configured for the associated application 10 in the application layer and other parameters extracted from the process execution state whether to block the system call or otherwise allow the system call to proceed in its original or a modified state” [0193]).
As to Claim 25:
Russello discloses the computer-storage medium comprising of claim 23, the operations further comprising: configuring the set of system call categories to include a blocked system call category (e.g. Russello blocked system call [0058]; [0170]; [0192]; denied system call [0283]), a fatally blocked system call category (e.g. Russello “kill the monitored process 304 making the function call altogether… depending on the nature of the associated system call that was to be invoked and/or security policy associated with the process, such as kill the entire process or return a value or error code to the process to prevent crashing” [0283]), and a conditionally allowed system call category (e.g. Russello modified system call [0192]; modifying parameters of the system call [0226]; system/function call is modifiable to allow execution [0283]).
As to Claim 28:
Russello discloses the computer-storage medium comprising of claim 21, the operations further comprising: determining to block the child process based on the system call violating the at least one permission (e.g. Russello “killing the process” [0109]; “Based on the security policy or policies configured in the monitoring entity 310 for the process 304, the monitoring entity 310 implements a security action or decision on the detected function call… kill the monitored process 304 making the function call altogether” [0283]; “if the security policy dictates that the application 331 should not be allowed to invoke the function… the enter method of the PEP 339 can return a decision to ‘kill’ 346 the application. In this case, the wrapper function 345 will perform an exit terminating the process and its application” [0294]).
As to Claim 29:
Russello discloses the computer-storage medium comprising of claim 22, the operations further comprising: determining to resume the child process based on the system call not violating the at least one permission (e.g. Russello “The child process 375 also raises a SIGSTOP 380 to be stopped until the parent process 370 allows it to resume its execution. When the child process 375 resumes its execution, it will continue with the dlopen 384 operation” [0319]; “they should be notified every time their target process executes a system call (using e.g. ptrace(PTRACE_SYSCALL)” [0260]; “After the decision point returns, the enforcement will continue the monitored process if the decision indicates to do so” [0261]; [0365]); and initiating an exit handling to suspend the trace (e.g. Russello “Once this setup has been performed, the process monitors go to sleep (e.g. invokes waitpid( )) after attaching to the monitored target process. This blocks the process monitor… In case the process is allowed to continue and after the decision is enforced, the process monitor will notify the kernel to continue the process execution (eg. ptrace(PTRACE_SYSCALL)) and goes back to sleep” [0261]).
As to Claim 30:
Russello discloses the computer-storage medium comprising of claim 29, the operations further comprising: configuring a teardown of the child process based on completion of the system call (e.g. Russello “A process is terminated when its operations are completed. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc., in a computer program. When a process corresponds to a function, its termination corresponds to a return of the function to the calling function or a main function” [0143]; “When the fork system call returns in Zygote (the system call is exiting), the process will be still stopped 66 and the kernel will notify the main monitor 70 via signal 82 (e.g. SIGCHILD)” [0214]).
Allowable Subject Matter
Claims 6, 7, 16, 17, 26, and 27 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicants’ disclosure.
O'Riordan et al. (US 8683400 B1)
Uner et al. (US 20120216242 A1)
Gerraty (US 11157609 B1)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Kenneth Chang whose telephone number is (571)270-7530. The examiner can normally be reached Monday - Friday 9:30am-5:30pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Taghi Arani can be reached at 571-272-3787. 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.
/KENNETH W CHANG/Primary Examiner, Art Unit 2438
PNG
media_image1.png
35
280
media_image1.png
Greyscale
10.17.2025