DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 21-40 are pending in this office action.
Double Patenting
The non-statutory 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 non-statutory double patenting rejection is appropriate where the conflicting claims 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); 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 non-statutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a non-statutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based e-Terminal Disclaimer may be filled out completely online using web-screens. An e-Terminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about e-Terminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 21-40 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1-23 of U.S. Patent No. 12,026,244. Although the claims at issue are not identical, they are not patentably distinct from each other . the mapping of corresponding claims of independents claims is as follow, where limitations and its corresponding limitations have a same cue.
Application:18/676,979
Patent:12,026,244
21. (New) A system comprising: an operating system; a processor; and memory comprising computer executable instructions that, when executed, perform operations comprising:
receiving a request to register a client package with the operating system, wherein the client package is unsigned and identifies a dependency of the client package on a host package;
determining the host package includes a host capability that indicates the host package has permission from the operating system to serve as a host to the client package;
and based on determining the client package does not include executable files and the host package includes the host capability, registering the client package with the operating system.
determining the client package does not include executable files;
1. (Currently Amended) A non-transitory computer-readable medium comprising instructions that are executable by one or more processors to cause a computing system to:
receive a request to register a client package, wherein the client package is unsigned and specifies a dependency identifying a host package,
wherein the host package is signed and includes an executable, wherein the host package is registered with an operating system, wherein the host package has access to a function of the operating system, and wherein the dependency identifying the host package includes at least one of a name, a version, a publisher, or an author of the host package;
register, by the operating system, the client package based on at least a determination that the dependency identifying the host package is satisfied; receive a request to activate an application included in the client package;
12. (Original) The computer-readable medium of claim 1, wherein the client package does not contain executable files or references to binaries or classes other than the host package.
Independent claim 34
Independent claim 21
Independent claim 39
Independent claim 13
Claims 21-40 are provisionally rejected on the ground of non-statutory double patenting as being unpatentable over claim 21-40 of co-pending Application No. 18/676,931. Although the claims at issue are not identical, they are not patentably distinct from each other . the mapping of corresponding claims of independents claims is as follow, where limitations and its corresponding limitations have a same cue.
This is a provisional non-statutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Application:18/676,979
Application:18/676,931
21. (New) A system comprising: an operating system; a processor; and memory comprising computer executable instructions that, when executed, perform operations comprising:
receiving a request to register a client package with the operating system, wherein the client package is unsigned and identifies a dependency of the client package on a host package; determining the client package does not include executable files;
determining the host package includes a host capability that indicates the host package has permission from the operating system to serve as a host to the client package;
and based on determining the client package does not include executable files and the host package includes the host capability, registering the client package with the operating system.
21. (Currently Amended) A system comprising: a processor; and memory comprising computer executable instructions that, when executed, perform operations comprising:
generating, during execution of a host runtime of a host package, a client package not comprising executable files; declaring, in the client package, a dependency on the host package, wherein the dependency includes at least one of a name of the host package or a version of the host package;defining, in the client package, an application with an application identity and a reference to the host runtime,
wherein the reference to the host runtime is usable by the client package for execution of the application;specifying, in a client manifest of the client package, an unsigned marker attribute, the unsigned marker attribute having a value comprising a string of characters indicating that the client package is unsigned;
and providing, upon activation of the application, access to the host runtime under the application identity.
Independent claim 34
Independent claim 34
Independent claim 34
Independent claim 40
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claims 21, 29-40 are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al US20090282477A1 in view of Khalid et al US11210390B1.
As per claim 21, Chen discloses a system comprising:
an operating system; a processor; and memory comprising computer executable instructions that, when executed, perform operations comprising: [0047] and [0029].
receiving a request to register a client package with the operating system:
[0051] “Operating System Portability: The system allows untrusted modules to be executed on any operating system that supports the secure runtime environment (e.g., for the x86 architecture, untrusted modules could be supported in the Windows.TM., MacOS.TM., and Linux.TM. operating systems “;
wherein the client package is unsigned and identifies a dependency of the client package on a host package;
[0049]“The untrusted module relies entirely on the secure runtime environment for access to system services, with the secure runtime environment taking full responsibility for the safety of the services provided”;
determining the client package does not include executable files:
[0082]“For instance, a native code module cannot read or change file system state, initiate network (or inter-module and/or inter-process) communications, or launch computations outside of an isolated "sandbox," and instead must rely on the secure runtime environment to perform such interactions (if allowed) on its behalf.”;
determining the host package includes a host capability that indicates the host package has permission from the operating system to serve as a host to the client package:
[0096] In some embodiments of the present invention, the service runtime provides functionality similar to that of an operating system, e.g., loading and launching modules on behalf of the host computation, providing access to a set of basic system services, and ensuring isolation between the separate security domains of client applications and untrusted native code modules. Because native code modules are restricted from directly accessing the native operating system kernel, all communications and system service requests made by native code modules are submitted to the service runtime. This intermediary role enables the service runtime to mediate all communication and access to system resources and enforce an access control policy that is stricter than that of the underlying native operating system.
and based on determining the client package does not include executable files and the host package includes the host capability, linking the client package with the operating system:
[0082] and [0045] “If validator 212 determines that untrusted native code module 208 is not compliant with a set of validation rules, the module is rejected (and hence not executed). Otherwise, if untrusted native code module 208 passes validation, it can be safely executed in secure runtime environment 214”:
[0074] “ Because native code modules are restricted from directly accessing the native operating system kernel, all communications and system service requests made by native code modules are submitted to the service runtime. This intermediary role enables the service runtime to mediate all communication and access to system resources and enforce an access control policy that is stricter than that of the underlying native operating system.” See also [0082]
But not explicitly:
registering the client package with the operating system:
Kalid discloses:
Col 6 lines 51-55 “ In addition, in the Windows' registry, different versions of the SW application may be registered under different identifiers or names. As a result, the operating system may treat different versions of the same SW application as different programs installed therein. “;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of khalid into teachings of Chen to track and detect behaviors of the potentially malicious content suspect during processing by the one or more software application. Thereafter, information associated with the detected behaviors pertaining to a malicious attack is stored, and an alert with respect to the malicious attack is issued. (Khalid abstract].
As per claim 29 the rejection of claim 21 is incorporated and furthermore Chen discloses:
wherein the host package is signed or includes an authenticating object enabling the operating system to authenticate the host package:
[0088] “ In some embodiments of the present invention, the secure runtime environment includes multiple aspects of runtime functionality. For instance, the secure runtime environment may include: [0089] 1. Client runtime functionality that provides an interface that allows client applications to create services based on untrusted native code modules and communicate with such services; [0090] 2. Service runtime functionality that serves as an application execution environment that loads and launches native code modules on behalf of clients and provides access to a set of basic system services while ensuring the isolation of intended security domains; [0091] 3. IMC (inter-module communication) runtime functionality that provides mechanisms for communications between trusted modules and the service runtime”;
As per claim 30 the rejection of claim 21 is incorporated and furthermore Chen discloses:
wherein the dependency includes criteria to be satisfied to register the client package with the operating system:
[0129]“While restricting the use of such instructions may simplify aspects of the validator, this could also potentially limit the performance of native code modules. Therefore, to provide maximum performance, the system may support such extensions by checking (e.g., in the validator) whether any extensions used in a native code module are supported by the hardware of the computing device (e.g., by checking detailed product model and version information, such as a model, model number, and stepping for current Intel processors, to determine the set of supported instructions). For instance, the validator may enforce safety for a native code module by preventing the execution of instructions that are unsupported by and/or undefined for the available hardware of a specific computing device.”;
As per claim 31 the rejection of claim 30 is incorporated and furthermore Chen discloses:
wherein the criteria specifies at least one of: a name of the host package; a minimum version of the host package; or a publisher or author of the host package:
[0129]“In some embodiments of the present invention, the validator checks whether native code modules attempt to use processor-model-specific instruction set extensions (such as different versions of the SSE (Streaming SIMD Extensions) available on some generations of x86 processors)”;
As per claim 32 the rejection of claim 30 is incorporated and furthermore Chen discloses:
wherein the criteria specifies at least one of: the host package is encrypted; the host package is compressed; or the host package is physically present on a particular volume or device:
[0121]“The system loads the native code module into a secure runtime environment that enforces code integrity, control flow integrity, and data integrity for the native code module (operation 710). Then, the system proceeds to execute instructions from the native code module in the secure runtime environment (operation 720). During execution, the secure runtime environment moderates which resources can be accessed by the native code module as well as how these resources are accessed. Executing the native code module in the secure runtime environment facilitates achieving native code performance for untrusted program code without significant risk of unwanted side effects.”;
As per claim 33 the rejection of claim 31 is incorporated and furthermore Chen discloses:
wherein determining the client package does not include the executable files comprises determining the client package does not include extensions referencing binaries or classes outside of the host package.
[0082]“For instance, a native code module cannot read or change file system state, initiate network (or inter-module and/or inter-process) communications, or launch computations outside of an isolated "sandbox," and instead must rely on the secure runtime environment to perform such interactions (if allowed) on its behalf.”;
As per claim 34, Chen discloses a method comprising:
receiving a request to register a client package with an operating system of a device:
[0051] “Operating System Portability: The system allows untrusted modules to be executed on any operating system that supports the secure runtime environment (e.g., for the x86 architecture, untrusted modules could be supported in the Windows.TM., MacOS.TM., and Linux.TM. operating systems “;
wherein the client package is unsigned and identifies a dependency of the client package on a host package comprising an executable file and a host runtime:
[0049]“The untrusted module relies entirely on the secure runtime environment for access to system services, with the secure runtime environment taking full responsibility for the safety of the services provided”;
determining the client package does not include executable files or extensions referencing binaries or classes that are not in the host package:
[0082]“For instance, a native code module cannot read or change file system state, initiate network (or inter-module and/or inter-process) communications, or launch computations outside of an isolated "sandbox," and instead must rely on the secure runtime environment to perform such interactions (if allowed) on its behalf.”;
based on determining the client package does not include the executable files or the extensions, linking the client package with the operating system:
[0082] and [0045] “If validator 212 determines that untrusted native code module 208 is not compliant with a set of validation rules, the module is rejected (and hence not executed). Otherwise, if untrusted native code module 208 passes validation, it can be safely executed in secure runtime environment 214”:
[0074] “ Because native code modules are restricted from directly accessing the native operating system kernel, all communications and system service requests made by native code modules are submitted to the service runtime. This intermediary role enables the service runtime to mediate all communication and access to system resources and enforce an access control policy that is stricter than that of the underlying native operating system.” See also [0082]
and upon activating an application included in the client package, invoking the host runtime:
[0125]“In summary, embodiments of the present invention include a secure runtime environment that facilitates achieving native code performance for untrusted program code without significant risk of unwanted side effects. This secure runtime environment facilitates native code modules that are otherwise securely isolated from the other software and hardware components of a computing device to communicate with other system components in a secure, controlled manner. The secure runtime environment moderates both which resources can be accessed (and communicated with) by the native code module, as well as how such resources are accessed, thereby ensuring that the native code module relies entirely on the secure runtime environment to access system services and cannot perform sensitive operations without explicit mediation.
But not explicitly:
registering the client package with the operating system:
Kalid discloses:
Col 6 lines 51-55 “ In addition, in the Windows' registry, different versions of the SW application may be registered under different identifiers or names. As a result, the operating system may treat different versions of the same SW application as different programs installed therein. “;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of khalid into teachings of Chen to track and detect behaviors of the potentially malicious content suspect during processing by the one or more software application. Thereafter, information associated with the detected behaviors pertaining to a malicious attack is stored, and an alert with respect to the malicious attack is issued. (Khalid abstract].
As per claim 35 the rejection of claim 34 is incorporated and furthermore Chen discloses:
prior to receiving the request to register the client package, receiving a request to register the host package with the operating system; verifying a signature of the host package; and registering the host package with the operating system:
[0088]” In some embodiments of the present invention, the secure runtime environment includes multiple aspects of runtime functionality. For instance, the secure runtime environment may include: [0089] 1. Client runtime functionality that provides an interface that allows client applications to create services based on untrusted native code modules and communicate with such services; [0090] 2. Service runtime functionality that serves as an application execution environment that loads and launches native code modules on behalf of clients and provides access to a set of basic system services while ensuring the isolation of intended security domains; [0091] 3. IMC (inter-module communication) runtime functionality that provides mechanisms for communications between trusted modules and the service runtime; and [0092] 4. Developer runtime functionality that is linked into the untrusted native code modules during development to facilitate communication with other aspects of the secure runtime environment.
As per claim 36 the rejection of claim 34 is incorporated and furthermore Chen discloses:
the host runtime comprises activation information that references the executable file; and the operating system uses the activation information when the host runtime is invoked:
[0088]” In some embodiments of the present invention, the secure runtime environment includes multiple aspects of runtime functionality. For instance, the secure runtime environment may include: [0089] 1. Client runtime functionality that provides an interface that allows client applications to create services based on untrusted native code modules and communicate with such services; [0090] 2. Service runtime functionality that serves as an application execution environment that loads and launches native code modules on behalf of clients and provides access to a set of basic system services while ensuring the isolation of intended security domains; [0091] 3. IMC (inter-module communication) runtime functionality that provides mechanisms for communications between trusted modules and the service runtime; and [0092] 4. Developer runtime functionality that is linked into the untrusted native code modules during development to facilitate communication with other aspects of the secure runtime environment.
As per claim 37 the rejection of claim 34 is incorporated and furthermore Chen discloses:
wherein the host package further comprises metadata files indicating at least one of: an identity of the host package; contents of the host package; or functionality of the host package:
[0045] “During execution, secure runtime environment 214 provides a very limited interface 216 between the untrusted native code module 208 and other software entities and hardware resources, moderating all external requests made by untrusted native code module 208 (as well as the way in which these requests are made).”;
As per claim 38 the rejection of claim 34 is incorporated and furthermore Chen discloses:
receiving, from the application, a request to access a function of the operating system, wherein the application is not authorized to access the function and the host package is authorized to access the function; and determining the host package is authorized to access the function; and granting the request to access the function:
[0082] “The secure runtime environment moderates both which resources can be accessed (and communicated with) by the native code module, as well as how such resources are accessed, thereby ensuring that the native code module relies entirely on the secure runtime environment to access system services and cannot perform sensitive operations without explicit mediation. For instance, a native code module cannot read or change file system state, initiate network (or inter-module and/or inter-process) communications, or launch computations outside of an isolated "sandbox," and instead must rely on the secure runtime environment to perform such interactions (if allowed) on its behalf”;
As per claim 39, Chen discloses a device comprising:
an operating system; a processor; and memory comprising computer executable instructions that, when executed, perform operations comprising:
[0051] “Operating System Portability: The system allows untrusted modules to be executed on any operating system that supports the secure runtime environment (e.g., for the x86 architecture, untrusted modules could be supported in the Windows.TM., MacOS.TM., and Linux.TM. operating systems “;
registering a host package with the operating system based on an authentication object included in the host package:
[0088] “Service runtime functionality that serves as an application execution environment that loads and launches native code modules on behalf of clients and provides access to a set of basic system services while ensuring the isolation of intended security domains; [0091] 3. IMC (inter-module communication) runtime functionality that provides mechanisms for communications between trusted modules and the service runtime; and [0092] 4. Developer runtime functionality that is linked into the untrusted native code modules during development to facilitate communication with other aspects of the secure runtime environment”;
receiving a request to register a client package with the operating system, wherein the client package include an application and identifies a dependency of the client package on the host package;
[0051] “Operating System Portability: The system allows untrusted modules to be executed on any operating system that supports the secure runtime environment (e.g., for the x86 architecture, untrusted modules could be supported in the Windows.TM., MacOS.TM., and Linux.TM. operating systems “;
[0049]“The untrusted module relies entirely on the secure runtime environment for access to system services, with the secure runtime environment taking full responsibility for the safety of the services provided”;
[0082]“For instance, a native code module cannot read or change file system state, initiate network (or inter-module and/or inter-process) communications, or launch computations outside of an isolated "sandbox," and instead must rely on the secure runtime environment to perform such interactions (if allowed) on its behalf.”;
determining the host package satisfies criteria for registering the client package with the operating system, wherein the criteria is indicated by the dependency;
[0074]“In one embodiment of the present invention, the system provides a constrained system call interface that can only be accessed via a set of "trampoline instructions" (or "trampolines") 420 found in text region 412. These trampoline instructions 420 include a limited set of safe (and aligned) entry points into the runtime system that are initialized by the loader/validator with trusted code that can transfer control to trusted runtime code and/or services 422. These trampoline instructions 420 are the only mechanism that can be used to transfer control flow in and out of the untrusted native code module.”;
and based on determining the client package satisfies the criteria, linking the client package with the operating system:
[0085] moderates access to system resources using a simple access policy that ensures that native code modules do not violate system protection and privacy constraints; [0086] supports multiple native code modules isolated from each other; and [0087] can be implemented in a small amount of code that can be both easily audited as well as ported to multiple operating systems that run on the same hardware architecture. The secure runtime environment moderates both which resources can be accessed (and communicated with) by the native code module, as well as how such resources are accessed, thereby ensuring that the native code module relies entirely on the secure runtime environment to access system services and cannot perform sensitive operations without explicit mediation. For instance, a native code module cannot read or change file system state, initiate network (or inter-module and/or inter-process) communications, or launch computations outside of an isolated "sandbox," and instead must rely on the secure runtime environment to perform such interactions (if allowed) on its behalf.
But not explicitly:
registering the client package with the operating system:
Kalid discloses:
Col 6 lines 51-55 “ In addition, in the Windows' registry, different versions of the SW application may be registered under different identifiers or names. As a result, the operating system may treat different versions of the same SW application as different programs installed therein. “;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of khalid into teachings of Chen to track and detect behaviors of the potentially malicious content suspect during processing by the one or more software application. Thereafter, information associated with the detected behaviors pertaining to a malicious attack is stored, and an alert with respect to the malicious attack is issued. (Khalid abstract].
As per claim 40 the rejection of claim 39 is incorporated and furthermore Chen discloses:
the host package includes a host runtime; and upon activation of the application, the application uses the host runtime to access functions of the operating system.
[0096]”In some embodiments of the present invention, the service runtime provides functionality similar to that of an operating system, e.g., loading and launching modules on behalf of the host computation, providing access to a set of basic system services, and ensuring isolation between the separate security domains of client applications and untrusted native code modules. Because native code modules are restricted from directly accessing the native operating system kernel, all communications and system service requests made by native code modules are submitted to the service runtime. This intermediary role enables the service runtime to mediate all communication and access to system resources and enforce an access control policy that is stricter than that of the underlying native operating system”;
Claims 22-27 are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al US20090282477A1 in view of Khalid et al US11210390B1 and Shah et al US20200202006A1
As per claim 22, the rejection of claim 21 is incorporated and furthermore Chen discloses:
receiving an activation request to activate an application included in the client package; and invoking a host runtime of the host package with an application identity of the application:
[0107] “In some embodiments of the present invention, the system provides debugging support for native code modules. For instance, the compilation process may provide mechanisms for building and linking a native code module to a different runtime implementation that includes the same interfaces as the secure runtime environment but where the different implementation of the service runtime provides additional debugging support and/or output. Alternatively, the service runtime and/or the developer runtime may include additional functions and/or capabilities that facilitate debugging native code modules”;
But not explicitly:
wherein the application identity is included in the client package.
Shah discloses:
wherein the application identity is included in the client package.
[0030] “As described above, the list 114 and versions 116 of the dependencies may be obtained from the install commands or other commands used to build the application, where the commands specify the dependencies to be used in building the application, which may additionally include arguments to specify particular versions 116 of the dependencies to be used as well.
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Shah into teachings of Chen and khalid for analyzing software image for vulnerabilities based on dependencies use in building image for running software application environments in containers. The continuous integration or continuous delivery (CI-CD) pipeline is leveraged to automatically build and update images, ensures that only dependencies that have been verified as safe are used. Accurately obtain the list and versions of dependencies use in building the first version of the image without consulting a lock file or manifest file. [Shah 0038].
As per claim 23, the rejection of claim 22 is incorporated and furthermore Chen does not explicitly disclose:
tracking activity of the application using the application identity by tracking activity of an executable file included in the host package.
Kalid discloses:
tracking activity of the application using the application identity by tracking activity of an executable file included in the host package.
Col 8 lines 1-5 " At block 206, the processing logic stores information describing any detected anomalous behaviors, and, associated therewith, the version identifier (e.g., version number and, where applicable, service pack number) corresponding to each of the versions of the software application and the operating system whose execution resulted in the anomalous behavior. At block 208, processing logic declares any identified attack incident and may issue an alert, which in some embodiments, contains or references threat data, including, for example, the version number or numbers of the SW application having a potential security vulnerability SO that remedial action may be taken”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of khalid into teachings of Chen and Shah, to track and detect behaviors of the potentially malicious content suspect during processing by the one or more software application. Thereafter, information associated with the detected behaviors pertaining to a malicious attack is stored, and an alert with respect to the malicious attack is issued. (Khalid abstract].
As per claim 24, the rejection of claim 22 is incorporated and furthermore Chen discloses:
the host runtime includes activation information referencing an executable file included in the host package; and the operating system, using the activation information, invokes the executable file to use content files of the application.
[0121] “The system loads the native code module into a secure runtime environment that enforces code integrity, control flow integrity, and data integrity for the native code module (operation 710). Then, the system proceeds to execute instructions from the native code module in the secure runtime environment (operation 720). During execution, the secure runtime environment moderates which resources can be accessed by the native code module as well as how these resources are accessed. Executing the native code module in the secure runtime environment facilitates achieving native code performance for untrusted program code without significant risk of unwanted side effects.”;
As per claim 25, the rejection of claim 22 is incorporated and furthermore Chen discloses:
wherein functionality of the operating system is made available to the application via the host runtime:
[0082] “Because native code modules are restricted from directly accessing the native operating system kernel, all communications and system service requests made by native code modules are submitted to the service runtime. This intermediary role enables the service runtime to mediate all communication and access to system resources and enforce an access control policy that is stricter than that of the underlying native operating system.
As per claim 26, the rejection of claim 25 is incorporated and furthermore Chen discloses:
receiving, from the application, a request to access the functionality of the operating system; determining the host package is able to access the functionality of the operating system; and granting the application access to the functionality of the operating system.
[0082] “The secure runtime environment moderates both which resources can be accessed (and communicated with) by the native code module, as well as how such resources are accessed, thereby ensuring that the native code module relies entirely on the secure runtime environment to access system services and cannot perform sensitive operations without explicit mediation. For instance, a native code module cannot read or change file system state, initiate network (or inter-module and/or inter-process) communications, or launch computations outside of an isolated "sandbox," and instead must rely on the secure runtime environment to perform such interactions (if allowed) on its behalf”;
As per claim 27, the rejection of claim 25 is incorporated and furthermore Chen discloses:
receiving, from the application, a request to access the functionality of the operating system; determining the host package is unable to access the functionality of the operating system; and denying the application access to the functionality of the operating system.
[0082] “The secure runtime environment moderates both which resources can be accessed (and communicated with) by the native code module, as well as how such resources are accessed, thereby ensuring that the native code module relies entirely on the secure runtime environment to access system services and cannot perform sensitive operations without explicit mediation. For instance, a native code module cannot read or change file system state, initiate network (or inter-module and/or inter-process) communications, or launch computations outside of an isolated "sandbox," and instead must rely on the secure runtime environment to perform such interactions (if allowed) on its behalf”;
Claim 28 is rejected under 35 U.S.C. 103 as being unpatentable over Chen et al US20090282477A1 in view of Khalid et al US11210390B1 and further in view of Shah et al US20200202006A1 and Boodman et al US8200962B1.
As per claim 28, the rejection of claim 27 is incorporated and furthermore Chen discloses:
in response to denying the application access to the functionality of the operating system, rejects the host package from the operating system;:
[0075]“The validator scans through the code section of each native code module that is loaded, decoding all executable instructions using a sequential traversal of the instruction stream that starts at the load (base) address. As described above, the validator rejects a native code module if it finds any defects, such as: illegal/disallowed instructions; alignment defects; direct branches with an invalid branch target; and/or unsafe indirect calls or jumps (that do not follow the target range and alignment restrictions described above)”;
But not explicitly:
upon uninstalling the host package from the operating system, deregistering the client package from the operating system.
Boodman discloses:
in response to denying the application access to the functionality of the operating system, uninstalling the host package from the operating system:
Col 14 lines 56-65 “ In various embodiments, the blacklisting message may indicate that one or more versions (e.g., all versions, versions 2.0-2.5, etc.) of a browser extension 132 are to be disabled. In some embodiments, the blacklisting message may indicate that the browser extension 132 should be uninstalled. For example, the browser extension 132 may have been determined to be malicious or violate a term of service, etc. In such an embodiment, the blacklisting message may identify or indicate the browser extension 132 to be either disabled or uninstalled based upon the browser extension's UID 138”;
and upon uninstalling the host package from the operating system deregistering the client package from the operating system:
Col 47-55 “In various embodiments, in which the browser extension 132 is uninstalled, as opposed to merely disabled or unloaded, the extension manager 126 or web browser 124 may delete or remove any files (e.g., web page 140, manifest 136, etc.) stored within the computing device 102 or storage medium 116. In various embodiments, the extension manager 126 or web browser 124 may transmit a message to the web store (e.g., web store 160) indicating that the browser extension 132 has been uninstalled”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Boodman into teachings of Chen, khalid and Shah to allow dynamically re-loading or unloading the web browser extension via the web browser without restarting the web browser so as to change the functionality of the web browser user's interest, thus enabling the user to effectively create a custom browser that includes functionality of the customized extensions.[ Boodman col 2 line 1-7].
Pertinent arts:
US20130031642A1:
Techniques involving detection of misuse of digital licenses pertaining to application use. An identification of unsigned applications or other use-protected applications enabled for use at a user device is obtained. The identification of such applications is directed to a licensing authority to seek digital license renewal for using the applications.
US20170076075A1:
Registration of an application in a per-user registration model includes the creation and storage of duplicate registration data for multiple user accounts present on a system.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRAHIM BOURZIK whose telephone number is (571)270-7155. The examiner can normally be reached Monday-Friday (8-4:30).
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, Wei Y Mui can be reached at 571-270-2738. 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.
/BRAHIM BOURZIK/ Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights