Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Claims 1-20 are presented for examination.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type 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); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claim 1 are compared to claim 1 in US Patent 12099864 in the following table:
Instant Application
Patent number 12099864
Claim 1. A computing device, comprising: a plurality of hardware resources including a set of one or more hardware processors, memory, and storage devices, wherein the storage devices include instructions that when executed by the set of hardware processors, cause the computing device to operate a virtualized system, the virtualized system including:
a set of one or more virtual machines (VMs) that execute one or more guest operating systems;
a formally verified microkernel running in a most privileged level to abstract hardware resources of the computing device; a plurality of formally verified hyper-processes including:
a set of one or more virtual machine monitors (VMMs) corresponding to the set of one or more VMs respectively, wherein a particular VMM manages interactions between the corresponding VM and physical resources of the computing device;
a set of one or more active security policy enforcers corresponding to the set of one or more VMMs respectively, wherein each active security policy enforcer uses virtual machine introspection (VMI) for introspection of at least some of the hardware resources including one or more hardware processors, wherein each active security policy enforcer enforces a plurality of policies based at least in part on the introspection;
a virtual switch coupled with each of the VMMs, wherein the virtual switch is not directly coupled with any of the set of VMs, wherein a virtual network policy enforcer enforces a set of one or more network policies at the virtual switch that affect communication of the one or more guest operating systems.
Claim 1. A computing device, comprising: a plurality of hardware resources including a set of one or more hardware processors, memory, and storage devices, wherein the storage devices include instructions that when executed by the set of hardware processors, cause the computing device to operate a virtualized system, the virtualized system including:
a set of one or more virtual machines (VMs) that execute one or more guest operating systems;
a formally verified microkernel running in a most privileged level to abstract and grants authorized access to hardware resources of the computing device; and a plurality of formally verified hyper-processes including:
a set of one or more virtual machine monitors (VMMs) corresponding to the set of one or more VMs respectively, wherein a particular VMM manages interactions between the corresponding VM and physical resources of the computing device;
a set of one or more active security policy enforcers corresponding to the set of one or more VMMs respectively, wherein each active security policy enforcer uses virtual machine introspection (VMI) for introspection of at least some of the hardware resources including one or more hardware processors, wherein each active security policy enforcer enforces a plurality of policies based at least in part on the introspection; and
a virtual switch coupled with each of the VMMs, wherein the virtual switch is not directly coupled with any of the set of VMs, wherein a virtual network policy enforcer enforces a set of one or more network policies at the virtual switch that affect communication of the one or more guest operating systems.
Claim 9. 9. A method in a computing device, comprising:
executing a formally verified microkernel in a most privileged level to abstract hardware resources of the computing device;
executing a set of one or more virtual machine monitors (VMMs) as a user-level application in an address space on top of the formally verified microkernel that each support execution of a guest operating system running in a virtual machine (VM), wherein a particular VMM manages interactions between the corresponding VM and hardware resources of the computing device;
continuously monitoring at least a portion of the hardware resources of the computing device, wherein the continuously monitoring includes performing virtual machine introspection (VMI) on at least the portion of the hardware resources of the computing device outside of the guest operating system;
determining, from the continuously monitoring, a violation of a policy; and responsive to the determination of the violation of policy, taking one or more remedial steps.
Claim 9. A method in a computing device, comprising:
executing a formally verified microkernel in a most privileged level to abstract hardware resources of the computing device;
executing a plurality of virtual machine monitors (VMMs), wherein each of the plurality of VMMs runs as a user-level application in a different address space on top of the formally verified microkernel, wherein each of the plurality of VMMs support execution of a different guest operating system running in a different virtual machine (VM), and wherein a particular VMM manages interactions between a corresponding VM and hardware resources of the computing device; for each of the plurality of VMMS,
continuously monitoring at least a portion of the hardware resources of the computing device including performing virtual machine introspection (VMI) on at least the portion of the hardware resources of the computing device outside of the guest operating system running in the virtual machine corresponding to that VMM;
determining, from the continuously monitoring, that a driver is attempted to be loaded and is a violation of a policy regarding drivers that are permitted to be loaded; and responsive to the determination of the violation of policy regarding drivers that are permitted to be loaded, taking one or more remedial steps including logging the violation and blocking the driver from being loaded.
Claim 15 is identical to claim 9 and is rejected for the same reasons.
Claims 1-20 are provisionally rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-16 of US Patent 12099864.
Although the conflicting claims are not identical, they are not patentably distinct from each other because the limitations of claims 1-16 of the patent, anticipates or otherwise renders obvious the limitations of 1-20, respectively of this instant application.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 16-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
As to claim 16, it recites “transitory machine-readable storage medium of claim 15” . Since it does not exclude transitory “signal” storing computer-readable code within relatively short amount of time, the broadest reasonable interpretation in light of specification encompasses that the computer-readable medium is signal per se. Thus, the claim is not eligible subject matter.
Claim 17-20 have the same problem and are rejected for the same reason.
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 1-20 are rejected under 35 U.S.C. 112, second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which applicant regards as the invention.
In claims 1, 9 and 15 the term “formally verified” is used. Examples include “formally verified microkernel” and “formally verified hyper-processes”
Paragraph 24 of the specification mentions “[0024] In an embodiment, the formally verified microkernel implements a capability-based system that ensures that resources can be accessed only when explicitly enabled. In such an embodiment, each piece of executing code and resource requires explicit authorization in the form of a granted capability to access a hardware resource or code resource..”
Paragraph 129 goes into more detail describing Fig 11 “[0129] FIG. 11 is a flow chart that illustrates an exemplary method of formal verification that may be used in some embodiments. A model 1105 of the code 1115 is created. The model 1105 is the functional implementation corresponding to the code 1115. The specification 1110 is a formal specification of the properties of the code 1115 expressed in a mathematical language. The code 1115 itself may be coded in a way that is architecture to be formally verified. The tools 1120 may include tools for converting the code 1115 into file(s) suitable for an interactive theorem prover 1135. The properties 1130 include any security properties or any theorems used for proving the code 1115. If the proof 1125 fails at block 1140, then the code 1115 is not formally verified. If the proof is verified, then the code 1115 is deemed to be formally verified 1145”.
The part about microkernel (paragraph 24) is clear enough and establishes security standards for resource access.
Fig 11 establishes standards for verification that makes sure a component is “formally verified”. Given the fact that claims use “virtual machine introspection” and “policy enforcement” at the switch level, it seems that having “formally verified” components means these components are “secure” and can be trusted not to be hacked into and therefore the rest of the components can be checked through mechanisms such as introspection using them.
Examiner would like to emphasize merely stating some generic verification standard (Fig 11) (that can be applied to any code or any device) does not give much weight to the term “formally verified” to any of these components (except perhaps to the microkernel because of paragraph 24).
More important than the verification process and standards, is the consequence of the verification. If a “formally verified” hypervisor makes it secure, then this needs to be explicitly stated.
“Formally verified” does not have a unique and identifiable definition that can be applied to all these disparate (ex microkernel, hypervisor, etc) entities uniformly. Merely stating some generic verification standards will not suffice.
Reading the claim language, one gets the impression that these components (example hyperprocesses) are formally verified (free of any security problems based on the context of the invention eventhough this is not mentioned in the claim itself) prior to any use. For purposes of examination, it is assumed they are “secure” and working correctly prior to usage.
The remaining claims, not specifically mentioned, are rejected for being dependent upon one of the claims above.
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 of this title, 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 1 and 3 are rejected under 35 U.S.C. 103 as being unpatentable over Babakian (US 2021/0021634 A1) in view of Ismael (US 2016/0006756 A1)
and in further view of Dahlin et al (Dahlin.pdf “Toward the Verification of a Simple
Hypervisor” in Proceedings 10th International Workshop on the ACL2 Theorem
Prover and its Applications, Austin, Texas, USA, November 3-4, 2011 (D. Hardin
and J. Schmaltz, eds.), vol. 70 of Electronic Proceedings in Theoretical Computer
Science, pp. 28–45, Open Publishing Association, 2011. (hereinafter
Dahlin)
As per claim 1, Babakian teaches A computing device, comprising:
a plurality of hardware resources including a set of one or more hardware processors, memory, and storage devices, wherein the storage devices include instructions that when executed by the set of hardware processors, cause the computing device to operate a virtualized system, the virtualized system including: (Babakian Fig 2 Hardware 212A and 212B)
a set of one or more virtual machines (VMs) that execute one or more guest operating systems; (Babakian Fig 2 VM 131 and VM 132)
a plurality of formally verified hyper-processes including:
a set of one or more virtual machine monitors (VMMs) corresponding to the set of one or more VMs respectively, wherein a particular VMM manages interactions between the corresponding VM and physical resources of the computing device; (Babakian Fig 2 Hypervisor 210A and 210B)
a set of one or more active security policy enforcers corresponding to the set of one or more VMMs respectively, wherein each active security policy enforcer uses virtual machine introspection (VMI) for introspection of at least some of the hardware resources including one or more hardware processors, wherein each active security policy enforcer enforces a plurality of policies based at least in part on the introspection; (Babakian [0038] At 405 in FIG. 4, network introspection entity 150 may monitor VMs 131-134 to identify or establish their normal operational behavior (i.e., intended state) [virtual machine introspection]. Any suitable approach may be used for network monitoring, such as using VMware's AppDefense™, etc. For example, network introspection entity 150 may interact with hypervisor 214A/214B (see network introspection module 219A/219B in FIG. 2) and/or guest OS 235-238 (e.g., via an agent executed by each guest OS). To establish their intended state, network introspection entity 150 may monitor VMs 131-134 and respective applications 231-234 for a period of time. [0044] At 430 in FIG. 4, authoritative controller 110 (e.g., using policy engine 114) may generate context-aware DNS record information (see 530 in FIG. 5) by mapping DNS record information associated with VM 131/133 to their context information. The context-aware DNS record information (see 112) provides a one-to-one mapping between DNS information record(s) associated with VM 131/133[ [a form of intersection, looking at VM from outside of it], and context information associated with VM 131/133. In practice, context-aware DNS record information may be updated dynamically at block 430 based on any updated context information. [0070] Potential security threats may be detected in various scenarios. For example, the number of cache misses at DNS resolver 110 may be greater than a predetermined threshold based on DNS queries from user device 801. In another example, user device 801 may behave abnormally at runtime, such as by querying for domain names supported by external platforms (i.e., does not satisfy its intended state).)
a virtual switch coupled with each of the VMMs, wherein the virtual switch is not directly coupled with any of the set of VMs, wherein a virtual network policy enforcer enforces a set of one or more network policies at the virtual switch that affect communication of the one or more guest operating systems. (Babakian [0019] Hypervisor 214A/214B implements virtual switch 215A/215B and logical distributed router (DR) instance 217A/217B to handle egress packets from, and ingress packets to, corresponding VMs. In SDN environment 100, logical switches and logical DRs may be implemented in a distributed manner and can span multiple hosts. For example, logical switches that provide logical layer-2 connectivity, i.e., an overlay network, may be implemented collectively by virtual switches 215A-B and represented internally using forwarding tables (not shown) at respective virtual switches 215A-B. The forwarding tables may each include entries that collectively implement the respective logical switches. Further, logical DRs that provide logical layer-3 connectivity may be implemented collectively by DR instances 217A-B and represented internally using routing tables (not shown) at respective DR instances 217A-B. The routing tables may each include entries that collectively implement the respective logical DRs. See also Fig 1 and Fig 1 Policy Engine 114 and 110 (Authoritative controller) and [0044] At 430 in FIG. 4, authoritative controller 110 (e.g., using policy engine 114) may generate context-aware DNS record information (see 530 in FIG. 5) by mapping DNS record information associated with VM 131/133 to their context information. The context-aware DNS record information (see 112) provides a one-to-one mapping between DNS information record(s) associated with VM 131/133, and context information associated with VM 131/133. In practice, context-aware DNS record information may be updated dynamically at block 430 based on any updated context information).
Obviously the policy will affect the virtual switch each switch has its own network introspection module according to Fig 2 of Babakian)
Babakian does not teach a formally verified microkernel running in a most privileged level to abstract hardware resources of the computing device;
However, Ismael teaches a formally verified microkernel running in a most privileged level to abstract hardware resources of the computing device (Ismael [0028] The trusted threat-aware microvisor (hereinafter "microvisor") may be embodied as a light-weight module disposed or layered beneath (underlying, i.e., directly on native hardware) the operating system kernel 230 executing on the node to virtualize the hardware and control privileges (i.e., access control permissions or capabilities) to kernel (e.g., hardware) resources of the node 200 that are typically controlled by the operating system kernel. That is, the microvisor may be implemented in an operationally efficient (i.e., light-weight) manner that maintains user experience (i.e., little performance degradation) at the node. Illustratively, the kernel resources may include (physical) CPU(s) 212, memory 220, network interface(s) 214 and devices 216. The microvisor may be configured to control access to one or more of the resources in response to a request by an operating system process to access the resource).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Ismael with the system of Babakian to use kernel at the privileged level. One having ordinary skill in the art would have been motivated to use Ismael into the system of Babakian for the purpose of providing a trusted threat-aware microvisor for a virtualization system. (Ismael paragraph 03)
Babakian and Ismael do not teach formally verified VMM.
However, Dahlin teaches formally verified VMM (Dahlin [page 29] This paper reports on the development of MinVisor and progress in its modeling and verification. Though early, the project has had some significant success in moving toward using formal verification to develop a simple hypervisor with very high assurance.)
In the combination, with Babakian, given that the switch in Babakian is coupled with the VMM and part of it, it is assumed that the two are verified together according to the standards established in Dahlin.
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Dahlin with the system of Babakian and Ismael to implement a formally verified VMM. One having ordinary skill in the art would have been motivated to use Dahlin into the system of Babakian and Ismael for the purpose of modeling and verification of hypervisors at the implementation level (Dahlin page 28).
As per claim 3, Babakian teaches the plurality of formally verified hyperprocesses further includes a policy manager that manages policies for the virtualized system. (Babakian Fig 1 Policy Engine 114 and 110 (Authoritative controller) and [0044] At 430 in FIG. 4, authoritative controller 110 (e.g., using policy engine 114) may generate context-aware DNS record information (see 530 in FIG. 5) by mapping DNS record information associated with VM 131/133 to their context information. The context-aware DNS record information (see 112) provides a one-to-one mapping between DNS information record(s) associated with VM 131/133, and context information associated with VM 131/133. In practice, context-aware DNS record information may be updated dynamically at block 430 based on any updated context information.)
The examiner believes this is consistent with what is disclosed in the specification ([0041] Some of these hyper-processes communicate with the microkernel 160 such as the master controller 150. The master controller 150 controls the operation of the virtualization such as memory allocation, execution time allotment,
virtual machine creation, and/or inter-process communication.). The authoritative controller in Babakian acts like the master controller in the current invention.
Claims 2 and 4 are rejected under 35 U.S.C. 103 as being unpatentable over Babakian (US 2021/0021634 A1) in view of Ismael (US 2016/0006756 A1)
and in further view of Dahlin et al (Dahlin.pdf “Toward the Verification of a Simple
Hypervisor” in Proceedings 10th International Workshop on the ACL2 Theorem
Prover and its Applications, Austin, Texas, USA, November 3-4, 2011 (D. Hardin
and J. Schmaltz, eds.), vol. 70 of Electronic Proceedings in Theoretical Computer
Science, pp. 28–45, Open Publishing Association, 2011. (hereinafter
Dahlin) and Lukacs (US 2014/0137180 A1)
As per claim 2, Babakian, Ismael and Dahlin do not teach policies are dynamically received remotely and installed to the set of one or more active security policy enforcers.
However, Luckas teaches policies are dynamically received remotely and installed to the set of one or more active security policy enforcers. (Lukacs [0006] he security VM is configurable by a centralized security manager executing on a remote server connected to the client system by a network, wherein the remote server is programmed to configure a plurality of client systems including the client system, and wherein the security VM is configured to control a network adapter of the client system according to a security policy received from the remote server)
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Lukacs with the system of Babakian, Ismael and Dahlin to receive a policy remotely. One having ordinary skill in the art would have been motivated to use Lukacs into the system of Babakian, Ismael and Dahlin for the purpose of providing anti-malware systems employing hardware virtualization technology. (Lukacs paragraph 01)
As per claim 4, Babakian, Ismael and Dahlin do not teach wherein the policy manager is configured to receive events from the set of active security policy enforcers, and wherein the policy manager is configured to disconnect network access from one of the guest operating systems upon a particular policy violation.
However, Luckas teaches the policy manager is configured to receive events from the set of active security policy enforcers, and wherein the policy manager is configured to disconnect network access from one of the guest operating systems upon a particular policy violation. (Luckas [0070] In some embodiments, the security VM is configured to detect malware and/or malicious activity in network traffic to/from the respective client system, and when such malware or activity is detected, to restrict access of the client system to the network. Such action on the part of individual security VMs distributed within the network may effectively prevent the spread of malicious activity over the network and/or may prevent leakage of valuable business data by selectively disconnecting malicious endpoints from the network).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Lukacs with the system of Babakian, Ismael and Dahlin to disconnect network access. One having ordinary skill in the art would have been motivated to use Lukacs into the system of Babakian, Ismael and Dahlin for the purpose of providing anti-malware systems employing hardware virtualization technology. (Lukacs paragraph 01)
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Babakian (US 2021/0021634 A1) in view of Ismael (US 2016/0006756 A1)
and in further view of Dahlin et al (Dahlin.pdf “Toward the Verification of a Simple
Hypervisor” in Proceedings 10th International Workshop on the ACL2 Theorem
Prover and its Applications, Austin, Texas, USA, November 3-4, 2011 (D. Hardin
and J. Schmaltz, eds.), vol. 70 of Electronic Proceedings in Theoretical Computer
Science, pp. 28–45, Open Publishing Association, 2011. (hereinafter
Dahlin) and Garfinkel et al. (vmi-garfinkel.pdf “Garfinkel T, Rosenblum M (2003) A virtual machine introspection based architecture for intrusion detection. In: Proceedings of the network and distributed systems security symposium, February 2003” (hereinafter Garfinkel)
As per claim 5, Babakian, Ismael and Dahlin do not teach the plurality of formally verified hyperprocesses further includes a hardware and firmware policy enforcer.
However, Garfinkel teaches the plurality of formally verified hyperprocesses further includes a hardware and firmware policy enforcer. (Garfinkel section 6.2 specifically section 6.2.1 (Memeory Access Enforcer)
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Garfinkel with the system of Babakian, Ismael and Dahlin to implement a hardware enforcer. One having ordinary skill in the art would have been motivated to use Garfinkel into the system of Babakian, Ismael and Dahlin for the purpose of monitoring of both hardware and software level events (Garfinkel page 1).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Babakian (US 2021/0021634 A1) in view of Ismael (US 2016/0006756 A1)
and in further view of Dahlin et al (Dahlin.pdf “Toward the Verification of a Simple
Hypervisor” in Proceedings 10th International Workshop on the ACL2 Theorem
Prover and its Applications, Austin, Texas, USA, November 3-4, 2011 (D. Hardin
and J. Schmaltz, eds.), vol. 70 of Electronic Proceedings in Theoretical Computer
Science, pp. 28–45, Open Publishing Association, 2011. (hereinafter
Dahlin) and Ghosh (US 9,846,588 B2)
As per claim 6, Babakian, Ismael and Dahlin do not teach one of the plurality of policies is a process allow policy that indicates a set of one or more processes that are allowed to be executed by a particular one of the one or more guest operating systems.
However, Ghosh teaches wherein one of the plurality of policies is a process allow policy that indicates a set of one or more processes that are allowed to be executed by a particular one of the one or more guest operating systems. (Ghosh [claim 1] the virtual machine manager operatively coupled to the request handler, the virtual machine manager configured to select a guest virtual machine based on a program type associated with the program, the request handler configured to send the request to the guest virtual machine such that the guest virtual machine executes the program in response to the indication of the program being included on a list indicating which programs are allowed to operate within the guest virtual machine).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Ghosh with the system of Babakian, Ismael and Dahlin to have a process allow policy. One having ordinary skill in the art would have been motivated to use Ghosh into the system of Babakian, Ismael and Dahlin for the purpose of providing safe environment for running Internet-connected software (Ghosh [col 1 lines 66-68]).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Babakian (US 2021/0021634 A1) in view of Ismael (US 2016/0006756 A1)
and in further view of Dahlin et al (Dahlin.pdf “Toward the Verification of a Simple
Hypervisor” in Proceedings 10th International Workshop on the ACL2 Theorem
Prover and its Applications, Austin, Texas, USA, November 3-4, 2011 (D. Hardin
and J. Schmaltz, eds.), vol. 70 of Electronic Proceedings in Theoretical Computer
Science, pp. 28–45, Open Publishing Association, 2011. (hereinafter
Dahlin) and Durham (US 2019/0095350 A1)
As per claim 7, Babakian, Ismael and Dahlin do not teach at least one of the one or more VMs that executes a guest operating system includes a local active security policy enforcer that can interact with encrypted memory used by the guest operating system.
However, Durham teaches at least one of the one or more VMs that executes a guest operating system includes a local active security policy enforcer that can interact with encrypted memory used by the guest operating system. (Durham [0092] In Example 1, an apparatus for encrypting a memory comprises: a cryptographic circuit to encrypt and decrypt data, the cryptographic circuit to receive a data line including at least an encrypted portion from a memory in response to a read request having a memory address from a first agent, obtain a key identifier for a key of the first agent from the data line, obtain the key using the key identifier, decrypt the at least encrypted portion of the data line using the key and send decrypted data of the at least encrypted portion of the data line to a cache hierarchy of a processor for access by the first agent, where the memory is encrypted with a plurality of keys, the key one of the plurality of keys).
The examiner is giving the term “local active security policy enforcer” its broadest reasonable interpretation to mean residing locally and not remotely.
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Durham with the system of Babakian, Ismael and Dahlin to implement a local security enforcer. One having ordinary skill in the art would have been motivated to use Durham into the system of Babakian, Ismael and Dahlin for the purpose of providing memory encryption in a multiple tenant computing environment. (Durham paragraph 01)
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Babakian (US 2021/0021634 A1) in view of Ismael (US 2016/0006756 A1)
and in further view of Dahlin et al (Dahlin.pdf “Toward the Verification of a Simple
Hypervisor” in Proceedings 10th International Workshop on the ACL2 Theorem
Prover and its Applications, Austin, Texas, USA, November 3-4, 2011 (D. Hardin
and J. Schmaltz, eds.), vol. 70 of Electronic Proceedings in Theoretical Computer
Science, pp. 28–45, Open Publishing Association, 2011. (hereinafter
Dahlin) and Sultan (US 2016/0373481 A1).
As per claim 8, Babakian, Ismael and Dahlin do not teach wherein at least one of the one or more VMs includes a notification agent running in guest user mode space, wherein the notification agent is configured to notify a user of a detected event including a violation of policy.
However, Sultan teaches wherein at least one of the one or more VMs includes a notification agent running in guest user mode space, wherein the notification agent is configured to notify a user of a detected event including a violation of policy. (Sultan [0031] In response to the request, in this example, the computing resource service provider 102 may configure the set of introspection agents to perform the security action of notifying the customer owner of any execution of a process not on the approved list in the set of virtual machines 106. And [0039] Within the computing resource service provider 102 environment, there may also be a data store containing a set of reference values representing expected values or expected ranges of values for the measurements being taken at designated introspection points. In response to variance from the expected value or range, the introspection agent may execute a security action, such as notifying a customer owner of a virtual machine instance that may be affected by the variance that the variance was observed.)
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Sultan with the system of Babakian, Ismael and Dahlin to notify a user of a violation of a policy. One having ordinary skill in the art would have been motivated to use Sultan into the system of Babakian, Ismael and Dahlin for the purpose of providing a new and useful system for detecting threats to a wide variety of resource types in large scale distributed computing systems.(Sultan paragraph 16)
Claims 9 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Garfinkel et al. (vmi-garfinkel.pdf “Garfinkel T, Rosenblum M (2003) A virtual machine introspection based architecture for intrusion detection. In: Proceedings of the network and distributed systems security symposium, February 2003” (hereinafter Garfinkel) in view of Ismael (US 2016/0006756 A1)
As per claim 9, Garfinkel teaches A method in a computing device, comprising:
executing a set of one or more virtual machine monitors (VMMs) as a user-level application in an address space on top of the formally verified microkernel that each support execution of a guest operating system running in a virtual machine (VM), wherein a particular VMM manages interactions between the corresponding VM and hardware resources of the computing device; (Garfinkel Fig 1 (Virtual Machine Monitor) see also section 3.1-3.3)
continuously monitoring at least a portion of the hardware resources of the computing device, wherein the continuously monitoring includes performing virtual machine introspection (VMI) on at least the portion of the hardware resources of the computing device outside of the guest operating system; (Garfinkel [section 1] We call this approach of inspecting a virtual machine from the outside for the purpose of analyzing the software running inside it virtual machine introspection (VMI). In this paper we will provide a detailed examination of a VMI-based architecture for intrusion detection. A key part of our discussion is the presentation of Livewire, a prototype VMI-based intrusion detection system that we have built and evaluated against a variety of real world attacks. Using Livewire, we demonstrate that this architecture is a practical and effective means of implementing intrusion detection policies).
determining, from the continuously monitoring, a violation of a policy; (Garfinkel [section 4.3.2] (At the heart of any intrusion detection system is the policy engine. This component interprets system state and events from the VMM interface and OS interface library, and decides whether or not the system has been compromised. If the system has been compromised, the policy engine is responsible for responding in an appropriate manner. For example, in case of a break-in, the policy engine can suspend or reboot the virtual machine, and report the breakin. Since the focus of our work has been studying VMI as a platform for IDS, we have focused on implementing variations on mainstream HIDS style policies [37] such as burglar alarms, misuse detectors and integrity checkers. A policy engine implementing complex anomaly detection and other, more exotic techniques can also be supported in this architecture) also see section 5.4.2 (Policy Module) and 6.2 (Event Driven Policy Modules))
responsive to the determination of the violation of policy, taking one or more remedial steps. (Garfinkel section 6 (6.1 -6.2) and section 7 (7.1-7.2))
Garfinkel does not teach executing a formally verified microkernel in a most privileged level to abstract hardware resources of the computing device.
However, Ismael teaches executing a formally verified microkernel in a most privileged level to abstract hardware resources of the computing device; (Ismael [0028] The trusted threat-aware microvisor (hereinafter "microvisor") may be embodied as a light-weight module disposed or layered beneath (underlying, i.e., directly on native hardware) the operating system kernel 230 executing on the node to virtualize the hardware and control privileges (i.e., access control permissions or capabilities) to kernel (e.g., hardware) resources of the node 200 that are typically controlled by the operating system kernel. That is, the microvisor may be implemented in an operationally efficient (i.e., light-weight) manner that maintains user experience (i.e., little performance degradation) at the node. Illustratively, the kernel resources may include (physical) CPU(s) 212, memory 220, network interface(s) 214 and devices 216. The microvisor may be configured to control access to one or more of the resources in response to a request by an operating system process to access the resource).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Ismael with the system of Garfinkel and Ryland to use a kernel at the privileged level. One having ordinary skill in the art would have been motivated to use Ismael into the system of Garfinkel and Ryland for the purpose of providing a trusted threat-aware microvisor for a virtualization system. (Ismael paragraph 03).
As to claim 9, it is rejected based on the same reason as claim 15.
Claims 10, 11, 16 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Garfinkel et al. (vmi-garfinkel.pdf “Garfinkel T, Rosenblum M (2003) A virtual machine introspection based architecture for intrusion detection. In: Proceedings of the network and distributed systems security symposium, February 2003” (hereinafter Garfinkel) in view of Ismael (US 2016/0006756 A1) and in further view of Babakian (US 2021/0021634 A1).
As per claim 10, Garfinkel and Ismael do not teach enforcing one or more virtual network policies at a virtual switch for granular control of network communication of the computing device.
However, Babakian teaches enforcing one or more virtual network policies at a virtual switch for granular control of network communication of the computing device. (Babakian [0038] At 405 in FIG. 4, network introspection entity 150 may monitor VMs 131-134 to identify or establish their normal operational behavior (i.e., intended state) [virtual machine introspection]. Any suitable approach may be used for network monitoring, such as using VMware's AppDefense™, etc. For example, network introspection entity 150 may interact with hypervisor 214A/214B (see network introspection module 219A/219B in FIG. 2) and/or guest OS 235-238 (e.g., via an agent executed by each guest OS). To establish their intended state, network introspection entity 150 may monitor VMs 131-134 and respective applications 231-234 for a period of time. [0044] At 430 in FIG. 4, authoritative controller 110 (e.g., using policy engine 114) may generate context-aware DNS record information (see 530 in FIG. 5) by mapping DNS record information associated with VM 131/133 to their context information. The context-aware DNS record information (see 112) provides a one-to-one mapping between DNS information record(s) associated with VM 131/133, and context information associated with VM 131/133. In practice, context-aware DNS record information may be updated dynamically at block 430 based on any updated context information. [0070] Potential security threats may be detected in various scenarios. For example, the number of cache misses at DNS resolver 110 may be greater than a predetermined threshold based on DNS queries from user device 801. In another example, user device 801 may behave abnormally at runtime, such as by querying for domain names supported by external platforms (i.e., does not satisfy its intended state).)
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Babakian with the system of Garfinkel and Ismael to implement network policies. One having ordinary skill in the art would have been motivated to use Babakian into the system of Garfinkel and Ismael for the purpose of improving performance and fault tolerance for a network (Babakian paragraph 13)
As per claim 11, Babakian teaches the virtual switch is coupled with the set of one or more virtual machine monitors and is not directly coupled with any VM. (Babakian [0019] Hypervisor 214A/214B implements virtual switch 215A/215B and logical distributed router (DR) instance 217A/217B to handle egress packets from, and ingress packets to, corresponding VMs. In SDN environment 100, logical switches and logical DRs may be implemented in a distributed manner and can span multiple hosts. For example, logical switches that provide logical layer-2 connectivity, i.e., an overlay network, may be implemented collectively by virtual switches 215A-B and represented internally using forwarding tables (not shown) at respective virtual switches 215A-B. The forwarding tables may each include entries that collectively implement the respective logical switches. Further, logical DRs that provide logical layer-3 connectivity may be implemented collectively by DR instances 217A-B and represented internally using routing tables (not shown) at respective DR instances 217A-B. The routing tables may each include entries that collectively implement the respective logical DRs.)
As to claim 16, it is rejected based on the same reason as claim 10.
As to claim 17, it is rejected based on the same reason as claim 11.
Claims 12 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Garfinkel et al. (vmi-garfinkel.pdf “Garfinkel T, Rosenblum M (2003) A virtual machine introspection based architecture for intrusion detection. In: Proceedings of the network and distributed systems security symposium, February 2003” (hereinafter Garfinkel) in view of Ismael (US 2016/0006756 A1) and in further view of Dahlin et al (Dahlin.pdf “Toward the Verification of a Simple Hypervisor” in Proceedings 10th International Workshop on the ACL2 Theorem Prover and its Applications, Austin, Texas, USA, November 3-4, 2011 (D. Hardin
and J. Schmaltz, eds.), vol. 70 of Electronic Proceedings in Theoretical Computer
Science, pp. 28–45, Open Publishing Association, 2011. (hereinafter
Dahlin)
As per claim 12, Garfinkel and Ismael do not teach teaches the one or more VMMs are formally verified.
However, Dahlin teaches the one or more VMMs are formally verified (Dahlin [page 29] This paper reports on the development of MinVisor and progress in its modeling and verification. Though early, the project has had some significant success in moving toward using formal verification to develop a simple hypervisor with very high assurance.)
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Dahlin with the system of Garfinkel and Ismael to implement a formally verified VMM. One having ordinary skill in the art would have been motivated to use Dahlin into the system of Garfinkel and Ismael for the purpose of modeling and verification of hypervisors at the implementation level (Dahlin page 28).
As to claim 18, it is rejected based on the same reason as claim 12.
Claims 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Garfinkel et al. (vmi-garfinkel.pdf “Garfinkel T, Rosenblum M (2003) A virtual machine introspection based architecture for intrusion detection. In: Proceedings of the network and distributed systems security symposium, February 2003” (hereinafter Garfinkel) in view of Ismael (US 2016/0006756 A1) and in further view of Xu (US 2018/0227317 A1)
As per claim 13, Garfinkel and Ismael do not teach wherein the policy is configured by an administrator of the computing device.
However, Xu teaches wherein the policy is configured by an administrator of the computing device. (Xu [0023] As shown in FIG. 1, hypervisor 140 may include a local controller 145. A user of the system 100, such as a network administrator, may specify user-defined security parameters input, such as security policies or rules, which may be received and processed at the system 100 by local controller 145).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Xu with the system of Garfinkel and Ismael to have an administrator configure a policy. One having ordinary skill in the art would have been motivated to use Xu into the system of Garfinkel and Ismael for the purpose of exchanging packet based on monitoring traffic information and/or user-defined security parameters (Xu paragraph 04)
As to claim 19, it is rejected based on the same reason as claim 13.
Claims 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Garfinkel et al. (vmi-garfinkel.pdf “Garfinkel T, Rosenblum M (2003) A virtual machine introspection based architecture for intrusion detection. In: Proceedings of the network and distributed systems security symposium, February 2003” (hereinafter Garfinkel) in view of Ismael (US 2016/0006756 A1) and in further view of Lukacs (US 2014/0137180 A1)
As per claim 14, Garfinkel and Ismael do not teach wherein the policy is received dynamically from a remote server.
However, Lukacs teaches wherein the policy is received dynamically from a remote server. (Lukacs [0006] he security VM is configurable by a centralized security manager executing on a remote server connected to the client system by a network, wherein the remote server is programmed to configure a plurality of client systems including the client system, and wherein the security VM is configured to control a network adapter of the client system according to a security policy received from the remote server)
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Lukacs with the system of Garfinkel and Ismael to receive a policy remotely. One having ordinary skill in the art would have been motivated to use Lukacs into the system of Garfinkel and Ismael for the purpose of providing anti-malware systems employing hardware virtualization technology. (Lukacs paragraph 01)
As to claim 20, it is rejected based on the same reason as claim 14.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20190012465 A1 – discloses an apparatus and method for collecting an audit trail in a virtual machine boot process, the audit-trail-collecting apparatus including an event detection unit for detecting a software interrupt event, a register state information extraction unit for extracting state information of a CPU register corresponding to a detection time of the software interrupt event, a monitoring unit for monitoring a change in a vector value corresponding to the software interrupt event in an interrupt vector table, a threat occurrence detection unit for detecting a threat occurrence in a virtual machine boot process based on at least one of the CPU register state information and a monitored result, and an audit trail collection unit for storing an audit trail corresponding to at least one of the CPU register state information and the monitored result when the threat occurrence is detected in the virtual machine boot process.
US 20150186643 A1 – discloses a method, an apparatus, and a system for triggering virtual machine introspection, so as to provide a timely and effective security check triggering mechanism. In the present invention, data that needs to be protected is determined; the data that needs to be protected is monitored; and when it is determined that the data that needs to be protected is modified, virtual machine introspection is triggered. The present invention avoids a performance loss and a security problem that are brought about by regularly starting a virtual machine introspection system to perform a security check, and therefore, the present invention is more applicable.
US 20170180325 A1 – discloses Technologies for enforcing virtual machine network access control include a network computing device that includes a plurality of virtual machines. The network computing device is configured to receive an access request from a virtual function assigned to a requesting virtual machine of the network computing device. The network computing device is additionally configured to determine a first privilege level assigned to the requesting machine and a second privilege level assigned to the destination virtual machine, and determine whether the requesting virtual machine is authorized to access the destination virtual machine based on a comparison of the first and second privilege levels. Upon determining the requesting virtual machine is authorized to access the destination virtual machine, the network computing device is additionally configured to allow the requesting virtual machine access to the destination virtual machine. Other embodiments are described herein.
US 20160285830 A1 – discloses a network interface controller that includes one virtual function owned by a virtual machine present in the computer system. The controller includes a simple filtering agent that is associated with the first virtual function. The agent enforces simple filter rules for received network packets. The simple filter rules are capable of blocking the network packets from reaching the virtual machine. The apparatus also includes another virtual function that is owned by a virtual machine monitor present in the computer system. The controller also includes a side bounce filtering agent to forward the first network packet to the second virtual function if the first packet is blocked by the at least one of the one or more simple filter rules.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MEHRAN KAMRAN whose telephone number is (571)272-3401. The examiner can normally be reached on 9-5.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Emerson Puente can be reached on (571)272-3652. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MEHRAN KAMRAN/ Primary Examiner, Art Unit 2196
Prosecution Insights