Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
2. Applicant’s arguments filed on 12/11/2025, with respect to the 35 U.S.C. 103 rejection(s) of claim(s) Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over NPL "Evaluating the Flexibility of the Java Sandbox" hereinafter Coker in view of U.S. Publication No. 20160147992 hereinafter Zhao have been fully considered. However, upon further consideration, a new ground(s) of rejection is made in view of amended claims.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
3. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over NPL
"Evaluating the Flexibility of the Java Sandbox" hereinafter Coker in view of U.S.
Publication No. 20160147992 hereinafter Zhao, and further in view of U.S. Publication No. 20150161381 hereinafter Sun.
As per claim 1, Coker discloses:
A method (Abstract, pg. 1 "We validate these results by deriving two
restrictions on application behavior that restrict (1) security manager
modifications and (2) privilege escalation. We demonstrate that enforcing these
rules at runtime stop a representative proportion of modern Java 7 exploits
without breaking backwards compatibility with benign applications. These
practical rules should be enforced in the JRE to fortify the Java sandbox."
") comprising:
loading, by a device, a Java Security Manager into a runtime of an
application, wherein the Java Security Manager, when called, is configured to
perform permission checks within the application (Section 2.1, pg. 2, first
column, "The Java sandbox is designed to safely execute code from untrusted
sources using components summarized in Figure 1. When a class loader loads a
class (e.g., from the network, filesystem, etc.), it assigns the class a code source
that indicates the code origin, and associates it with a protection domain.
Protection domains segment the classes into groups by permission set. These
sets contain permissions that explicitly allow actions with security implications,
such as writing to the filesystem, accessing the network," Also see Table 1, pg.
3 "Table 1: List of sandbox-defeating permissions. A security manager that
enforces a policy containing any of these permission results in a defenseless
sandbox. A subset of these permissions were first identified in [7].");
a call directed to the Java Security Manager to perform a particular
permission check (Section 5, FORTIFIYING THE SANDBOX, first paragraph "
Based on our study of how open-source Java programs interact with the security
manager, we propose two changes to the current Java security model to stop
exploits from disabling self-protecting managers. These rules can be applied to
all Java applications. These rules reduce the flexibility and thus complexity of the
Java security model without breaking backwards compatibility in practice:
Privilege escalation rule. If a self-protecting security manager is set for the
application, a class may not directly load a more privileged class. This rule is
violated when the protection domain of a loaded class implies a permission that
is not implied in the protection domain that loaded it. Security manager rule. The
manager cannot be changed if a self-protecting security manager has been set
by the application. This is violated when code causes a change.");
determining, by the agent and based on a runtime application self-
protection (RASP) policy, whether the call represents a RASP policy violation
(Section 5.1, Implementation using JVMTI, first paragraph "JVMTI is a native
interface that enables the creation of dynamic analysis tools, called agents, such
as profilers, debuggers, or thread analyzers. JVMTI agents can intercept and
respond to events such as class or thread creation, field access or modification,
breakpoints, etc. JVMTI requires turning off the just-in-time compiler (JIT) to
enforced the security manager rule, which slows down program execution
enough that our monitors are not suitable for adoption with current JVMTI
implementations. A more correct and general approach is to embed our rules
directly in the JRE. We are currently in communication with the OpenJDK
developers on their security-dev mailing list about doing so." Section 5.1.2,
Enforcing the security manager rule, first paragraph "We enforce the
Security Manager rule by monitoring every read from and write to the field in the
System class that stores the security manager (the security field). The agent
stores a shadow copy of the most recently-set security manager. Whenever the
field is written, the agent checks its shadow copy of the manager. If the shadow
copy is null, the manager is being set for the first time. If the new manager is self
protecting, the agent updates the shadow copy. If not, the agent stops performing
stringent checks because the rule does not apply in the presence of a
defenseless manager. The agent checks modifications to the security manager
and validates it when it is referenced. The latter is necessary to catch type
confusion attacks, which change the manager without triggering a JVMTI
modification event. The tool detects unauthorized changes every time the
manager is used by comparing the current manager with the shadow copy for
changes. Type confusion attacks that masquerade as a privileged class loader
will not be detected by our agent, and may still be dangerous when exploited in
collaboration with other JRE vulnerabilities." );
and raising, by the agent and when the agent determines that the call represents a RASP policy violation, a RASP security exception (pg. 6, second
column, first paragraph "Figure 4 shows how Freemind sets the proxy security
manager field. Once a manager is set, if setFinalSecurityManager is called again
with a different security manager, a SecurityException is thrown, but calling the
method with a reference to the set manager disables the sandbox. The comment
implies that this sequence of operations was implemented to prevent malicious
applications from changing the settings of the sandbox." Pg. 8, first column,
Section 5.3, third paragraph "In each case, we confirmed that the tests, sample
workloads, or fuzzed executions worked without a security manager. To sandbox
the applications, we developed security policies using a custom security manager
that does not throw exceptions and that prints out checked permissions as each
program executes. Finally, we ran each case a third time using our policy and the
standard Java security manager with our monitors attached and enforcing the
rules. The rules did not break any unit tests, sample workloads, or fuzzed
executions.")
a Java Security Manager performing the particular permission check (pg.
2, second column, second paragraph "The sandbox is activated by setting a
security manager, which acts as the gateway between the sandbox and the rest
of the application. Whenever a sandboxed class attempts to execute a method
with security implications, that method queries the security manager to determine
if the operation should be permitted. To perform a permission check, the security
manager walks the call stack to ensure each class in the current stack frame has
the specific permission needed to perform the action.")
Coker does not disclose:
intercepting, by an agent executed by the device and via instrumentation inserted into the permission checks of the application, a call directed to the Java Security Manager prior to the Java Security Manager performing a particular permission check;
determining, prior to the Java Security Manager performing the particular permission check on the call and by the agent, whether the call represents a violation
and raising, by the agent and when the agent determines that the call
represents a policy violation, a security exception prior to a Security Manager
Zhao discloses:
intercepting, by an agent executed by the device and via instrumentation
code inserted into the permission checks of the application, a call (para 0080 " In
an embodiment, a "supervisor" function may be used to protect another function,
referred to herein as a "protected" function, from bots and/or malicious
instructions. A supervisor function may be a function that determines, at run-time,
whether the function(s) that call a protected function are pre-authorized to call the
protected function. If so, the supervisor function may call the protected function,
and/or cause the protected function to be executed." para 0089 "A supervisor
function may be used to protect a function defined in a web page and/or browser.
9 FIG. 2 illustrates a modified web page that defines a supervisor function, which
may intercept calls to the protected function and prevent unauthorized callers
from calling the protected function, in an example embodiment.")
and raising, by the agent and when the agent determines that the call
represents a policy violation, a security exception prior to a Security Manager
(para 0080 " If so, the supervisor function may call the protected function, and/or
cause the protected function to be executed. Otherwise, the supervisor function
may terminate, return an invalid response or error flag, raise an exception and/or
other error, display an error, and/or perform any other negative response that
interrupts and/or prevents execution of the protected function." Para 0091 " In
line 6, supervisor function 220 determines whether the identifier for the current
direct caller matches, and/or is equivalent to, the authorized caller function
identifier. If so, control passes to line 7, which calls the protected function is
called using the new alias ("ProtectedFunction1 20"); otherwise, control passes
to line 10. In line 10, the supervisor function raises or throws an exception error,
which terminates supervisor function 220 without calling function 120 and
indicates an unauthorized caller function attempted to call function 120.")
Therefore, it would have been obvious to one of ordinary skill in the art
before the effective filing date of the claimed invention to modify the method of
fortify the Java sandbox of Coker to include intercepting, by an agent executed
by the device and via instrumentation code inserted into the permission checks of
the application, a call and raising, by the agent and when the agent determines
that the call represents a policy violation, a security exception prior to a Security
Manager, as taught by Zhao.
The motivation would have been to enhanced the security of a security
validated permission request before the permission request check is executed.
Coker in view of Zhao does not disclose:
intercepting, a call prior to the Java Security Manager performing a particular permission check; determining, prior to the Java Security Manager performing the particular permission check on the call and by an agent
determining, prior to the Java Security Manager performing the particular permission check on the call and by the agent, whether the call represents a violation
Sun discloses:
intercepting, a call prior to the Java Security Manager performing a particular permission check; determining, prior to the Java Security Manager performing the particular permission check on the call and by an agent
determining, prior to the Java Security Manager performing the particular permission check on the call and by the agent, whether the call represents a violation (Fig. 3, para 0028 “ In block 320, exploit detection code is injected into the JVM, instrumenting the JVM that provides the sandbox.” Par 0030 “ In order to successfully run code out of the JAVA Sandbox, the exploit must disable the SecurityManager object before the exploit can run the privileged JAVA code necessary to escape the JAVA sandbox. In one embodiment, the System.getSecurityManager and System.setSecurityManager methods are hooked in the java.lang.System class with detection logic. The detection logic, illustrated in blocks 340 and 360, checks if the original SecurityManager object has been changed or disabled, hooking the setSecurityManager method to store the original SecurityManager object in block 340 at initialization of the sandbox, and then checking in block 360 with the getSecurityManager method whether the SecurityManager object is null or disabled. If the SecurityManager object has been disabled or is null, that indicates an escape attempt has occurred, and the application attempting to escape from the sandbox may be terminated.” Para 0032 and Table under paragraph 0032 “The detection logic for a JRE 1.6.x embodiment is a little bit different as an attacker does not have to disable a SecurityManager object to run code out of sandbox. Instead, an attacker can just change the permissions. If the JAVA application tries to call a privileged method such as ClassLoader, the application will get the following error of "permission denied":
TABLE-US-00001 java.security.AccessControlException: access denied (''java.lang.RuntimePermission'' ''createClassLoader'') at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkCreateClassLoader(Unknown Source) at java.lang.ClassLoader.checkCreateClassLoader(Unknown Source) at java.lang.ClassLoader.<init>(Unknown Source) ...”
Para 0034 “Therefore, in one embodiment, the detection logic for JRE 1.6.x environments may hook some methods that will be always used in a JAVA exploits that attempt to run code outside of the sandbox, for example, Runtime.getRuntime( ).Exec( ). Applications running in a sandbox that do not contain an exploit attempting to escape the sandbox generally do not call the EXEC method. By injecting code into the JVM 140 to hook the EXEC method, we can check the permission status whenever the EXEC method is called in block 350. Normally, a JAVA application is not supposed to have full permissions inside the JAVA sandbox. If the permissions are at an appropriate level for the sandbox in block 370, the execution of code to be performed by the EXEC method may be allowed; otherwise, the application that appears to be trying to escape the sandbox may be terminated. Although the EXEC method is identified as hooked in FIG. 3, other methods can be hooked instead of or in addition to EXEC as desired.” A check is made by the hook/code before the security manager can be retrieved or execute the permission check.)
Therefore, it would have been obvious to one of ordinary skill in the art
before the effective filing date of the claimed invention to modify the method of
fortify the Java sandbox of Coker in view of Zhao to include intercepting, a call prior to the Java Security Manager performing a particular permission check; determining, prior to the Java Security Manager performing the particular permission check on the call and by an agent and determining, prior to the Java Security Manager performing the particular permission check on the call and by the agent, whether the call represents a violation, as taught by Sun.
The motivation would have been to detect an attempt to escape the sandbox environment and allowing the sandbox environment to prevent those actions from being performed (Sun paragraph 0017).
As per claim 2, Coker in view of Zhao and Sun discloses:
The method as in claim 1, wherein the RASP policy violation comprises
one of: injection, broken authentication, sensitive data exposure. Extensible
Markup Language (XML) external entities (XX E), broken access control, security
misconfiguration, cross-site scripting, insecure deserialization, using components
with known vulnerabilities, or insufficient logging and monitoring (Coker pg. 3,
section 2.3 and pg. 7, section 5, second paragraph).
As per claim 3, Coker in view of Zhao and Sun discloses:
The method as in claim 1, further comprising: preventing, by the agent, the
Java Security Manager from crashing the application as a result of a permission
check performed by the Java Security Manager (Coker pg. 7, sections 5.1, 5.1.1,
5.1.2 and section 5.2, second paragraph).
As per claim 4, Coker in view of Zhao and Sun discloses:
The method as in claim 3, wherein preventing the Java Security Manager
from crashing the application as the result of a permission check performed by
the Java Security Manager comprises: causing permission checks performed by
the Java Security Manager to always grant permission (Zhao para 0080 and
0091, Though Coker discloses Java Security Manager from crashing the
application as the result of a permission check, Zhao discloses causing
permission checks performed by the Java Security Manager to always grant
permission. The motivation would have been to enhanced the security of a
security validated permission request before the permission request check is
executed).
As per claim 5, Coker in view of Zhao and Sun discloses:
The method as in claim 1, wherein the application is a Java application
(Coker Abstract, pg. 3, section 2.3, and pg. 7, section 5, first paragraph).
As per claim 6, Coker in view of Zhao and Sun discloses:
The method as in claim 1, wherein the particular permission check is a
runtime command execution permission check (Coker pg. 6, second column,
third paragraph, We demonstrated that the custom security manager is easily
removed using reflection to show that the problem is more complex than simply
fixing permission checks related to setting the security manager. Figure 5 shows
a Groovy exploit to turn off the manager. The script gets a reference to the
system's manager and its class. The class has the same type as the custom
security manager, thus the exploit gets a reference to the proxy manager field.
The field is made public to allow the exploit to reflectively null it, disabling the
sandbox to allow "forbidden" operations. We notified Freemind developers of this
vulnerability in August of 2014 and offered our advice in achieving their desired
outcome.")
As per claim 7, Coker in view of Zhao and Sun discloses:
The method as in claim 1, wherein loading the Java Security Manager into
the runtime of the application (Coker pg. 2, section 2.1, first paragraph and pg. 7,
section 5, second paragraph) comprises:
making a determination as to whether the application includes a call to the
Java Security Manager and inserting the call to the Java Security Manager into
the application, based on the determination (Coker pg. 7, sections 5.1, 5.1.1,
5.1.2 and section 5.2, second paragraph) and (Zhao para 0080, 0081, 0089-
0093, The motivation would have been to enhanced the security of a security
validated permission request before the permission request check is executed).
As per claim 8, Coker in view of Zhao and Sun discloses:
The method as in claim 1, further comprising: preventing the Java Security
Manager from calling a method that generates context information regarding a
call stack of the application (Coker pg. 2, second column, second paragraph and
pg. 9, first column, first paragraph).
As per claim 9, Coker in view of Zhao and Sun discloses:
The method as in claim 1, wherein raising the RASP security exception
comprises: preventing, by the agent, the application from performing the RASP
policy violation (Coker pg. 7, sections 5.1, 5.1.1, 5.1.2 and section 5.2, second
paragraph).
As per claim 10, Coker in view of Zhao and Sun discloses:
The method as in claim wherein the agent is a RASP agent (Coker pg. 7,
sections 5.1, 5.1.1, 5.1.2 and section 5.2, second paragraph).
As per 11, the implementation of the method of claim 1 will execute the
apparatus of claim 11. The claim is analyzed with respect to claim 1.
As per claim 12, The claim is analyzed with respect to claim 2.
As per claim 13, The claim is analyzed with respect to claim 3.
As per claim 14, The claim is analyzed with respect to claim 4.
As per claim 15, The claim is analyzed with respect to claim 5.
As per claim 16, The claim is analyzed with respect to claim 6.
As per claim 17, The claim is analyzed with respect to claim 7.
As per claim 18, The claim is analyzed with respect to claim 8.
As per claim 19, The claim is analyzed with respect to claim 9.
As per 20, the implementation of the method of claim 1 will execute the
non-transitory (Zhao paragraph 0176) of claim 20. The claim is analyzed
with respect to claim 1.
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 GARY S GRACIA whose telephone number is (571)270-5192. The examiner can normally be reached Monday-Friday 9am-6pm.
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, Philip Chea can be reached at 5712723951. 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.
/GARY S GRACIA/Primary Examiner, Art Unit 2499