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 .
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
This Action is in response to communications filed 08/06/2025.
Claims 1 and 6-11 have been amended.
Claims 12-20 have been newly added.
Claims 1-20 are pending.
Claims 1-20 are rejected.
Response to Amendment
In the Remarks filed 08/06/2025, Applicant has amended:
The language of claims 7 and 11 to address the antecedent basis issues previously identified. The Examiner therefore withdraws the corresponding 112(b) rejections made in the Office action dated 02/06/2025.
Response to Arguments
In Remarks filed on 08/06/2025, Applicant substantially argues:
Claim 4 limitation as originally presented contains proper antecedent basis for the term “base address”. Applicant’s argument filed has been fully considered and found to be persuasive. The corresponding 112(b) rejection has been withdrawn.
On Pages 2-3, the applied references including Campbell, Liljeberg, and Sell fail to disclose the amended limitation of claim 1, and similarly presented in newly added claims 12 and 20, regarding “accessing a first physical memory address … from a virtual machine control structure that is to be used to store a plurality of virtual machine controls for the first virtual machine”. In particular, Applicant points to Liljeberg as being cited for teaching one or more access protected structures corresponding to the first virtual machine but that it is not disclosed or rendered obvious the above identified amended limitation. Applicant’s arguments filed have been fully considered but they are moot in view of the current rejections made in response to Applicant’s amendments.
Claims 12-20 are addressed for the first time in the current action.
All arguments by the applicant are believed to be covered in the body of the office action; thus, this action constitutes a complete response to the issues raised in the remarks dated August 6, 2025.
Claim Interpretation
The Examiner notes newly presented Claim 12 contains language indicated as “amendments” despite being a new claim added. For clarity purposes, the Examiner makes of record that the currently filed Claim 12 is considered as “New” and any following amendments made should follow corresponding appropriate filing procedure as required. For the current action, the claim is interpreted as including the indicated underlined portions and excluding any portions indicated by strikethrough.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103(a) are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Campbell et al. (US 2005/0223225) in view of Neiger et al. (US 2015/0121366) and further in view of Liljeberg (US 2011/0010483) and still further in view of Sell (US 2016/0371496).
Regarding claim 1, Campbell discloses, in the italicized portions, a processor, comprising: decode circuitry to decode an instruction associated with a virtualization architectural extension ([0016] Each processor 110 may include various elements, including any or all of: 1) cache memory 112, 2) non-protected microcode (uCode) 114, and 3) protected microcode 116. Microcode includes circuitry to generate operations and micro-operations in the execution of instructions, where instructions may include both program (software-implementable) operations and operations triggered by hardware events that may not be directly programmable. Protected microcode 116 includes microcode that may be executed only by protected instructions and/or as part of a protected operation. [0040] The host execution mode may utilize virtual machine functionality and may create a secure execution environment, which operates utilizing protected microcode and protected memory, alone, or in conjunction with non-protected microcode instructions and non-protected memory, as previously discussed.); and execution circuitry coupled with the decode circuitry, the execution circuitry to execute the instruction to perform operations, including to ([0017] Configuration space may be reserved in this manner. Configuration "space" is a conceptual term that refers to the range(s) of addresses that are reserved for implementation in logic circuit 120 for various activities, with accesses that are targeted to any address within the configuration space being redirected to various portions of logic circuit 120 rather than to memory 140 or to input-output devices. [0018] FIG. 1 shows protected configurations space 141 and non-protected configuration space 142, which represent the ranges of addressable locations that are reserved for control and monitoring activities (protected and non-protected activities, respectively) that are implemented in logic circuit 120. Configuration space may be implemented with addresses that would otherwise be part of memory address space or input-output (I/O) address space. Read or write commands to at least a portion of the addresses in the configurations space are redirected to configurations registers in logic circuit 120.): access one or more access protected structures corresponding to a first virtual machine to determine a plurality of physical memory addresses associated with a corresponding plurality of apertures, including to access a first physical memory address of the plurality of physical memory addresses from a virtual machine control structure that is to be used to store a plurality of virtual machine controls for the first virtual machine, the first physical memory address associated with a first aperture of the plurality of apertures, the first virtual machine to use the first aperture to share information with a first authorized entity, wherein an opcode of the instruction allows the execution circuitry to access the one or more access protected structures to determine the first physical memory address, and wherein the first virtual machine and the first authorized entity are to access the first aperture using the first physical memory address. Herein Campbell discloses a processor structure including decode and execution circuitry to process commands which access protected memory ranges from non-protected access commands, wherein these protected memory ranges are interpreted as being analogous to the plurality of apertures. Campbell does not explicitly recite the details pertaining to accessing the protected structures to determine a plurality of physical memory addresses corresponding to the plurality of apertures including a first physical memory address, from a virtual machine control structure (VMCS), which is enabled to be accessed by an opcode of the instruction and using the first physical address of the first aperture to share information between the first virtual machine and first authorized entity. Regarding accessing the protected structures to determine a physical memory address including to access a first physical memory address from a VMCS, Neiger discloses in Paragraphs [0027-28] “[0027] Processor 120 may control the operation of VMs 150 and 160 according to data stored in one or more virtual machine control structures (each, a "VMCS"). A VMCS is a data structure that may contain state of one or more guests, state of a host, execution control information indicating how VMM 140 is to control operation of a guest or guests, execution control information indicating how VM exits and VM entries are to operate, information regarding VM exits and VM entries, any other such information. [0028] The addresses that a guest application uses to access its linear or virtual memory may be translated, using page tables configured by a guest OS, to addresses in the memory space that appears (through the virtualization supported by the processor and the VMM) as system memory to the guest OS (each, a "guest physical address" or "GPA"). The GPAs may be translated to addresses (each, a "host physical address" or "HPA") in actual system memory (e.g., memory 130), through the EPTs (which have been configured by the VMM prior to a VM entry) without causing a VM exit.” Herein Neiger discloses and identifies use of a VMCS to control access to particular allocated memory spaces on a per virtual machine basis. Each respective VMCS enables the corresponding virtual machine to access a host physical address allocated to it in the system. As Campbell recites use of VMCS to store information dictating how to control execution of virtual machines, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention that the VMCS in Campbell stores information including physical address mapping as taught by Neiger to enable access by virtual machines to the corresponding allocated memory spaces for operation execution. Neiger does not explicitly disclose using the first physical memory address associated with the first aperture to share information. Regarding this limitation, Liljeberg discloses in Paragraphs [0073] and [0088-90] “[0073] According to an exemplary embodiment of the present invention, a separate memory protection unit (MPU) is additionally provided, which is under the control of the virtual machine monitor (VMM). The memory protection unit (MPU) is configured to handle memory protection and memory sharing between different virtual machines (VMs). [0088] The permission table 320 may be implemented in different ways. One possible implementation is based on an associative array, which is indexed with the virtual machine (VM) identifier (ID) and the virtual machine (VM) physical address to be translated and contains at least one physical base address and size, which define a physical memory region of the physical system memory accessible to the virtual machine (VM). [0089] The example permission table of FIG. 6 illustratively presents memory mappings for three virtual machines VM ID 1, VM ID 2, and VM ID 3. The first virtual machines VM ID 1 maps three different physical system memory regions to its address space, which are (0x00000000 to 0x00ffffff), (0x07000000 to 0x070fffff) and (0xf0000000 to 0xf0ffffff). [0090] Second of the memory regions (0x07000000 to 0x070fffff) is shared with virtual machine VM ID 2. The virtual machine VM ID 3 only maps one physical system memory region (0x20000000 to 0x20ffffff) and does not share any physical system memory region with one of the other virtual machines VM ID 1 and VM ID 2.” Herein Liljeberg discloses the system maintains a protected table containing memory address ranges represented by a base address and offset wherein the allocated ranges are shared between different virtual machines for access. In view of Campbell wherein disclosed using special commands to access specified ranges of addresses associated with virtual machines (VMs) and Neiger wherein each VMCS details allocated physical memory addresses, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide access to protected memory addresses through specific commands issued by virtual machines in order to protected the associated address from unauthorized access and share data between virtual machines which have been allocated access to the same memory range (Liljeberg [0005]). Campbell, Neiger, and Liljeberg do not explicitly disclose that the protected structure is accessed via the opcode of the instruction allowing access to the structure. Regarding this aspect of the limitation, Sell discloses in Paragraphs [0034] and [0085-86] “[0034] After virtual addresses (VA's) are generated by the Hypervisor 76 for the protected regions (PR's) (and one-stage VA/PA translation tables are generated for them), the initially included PR definitions 71b are copied (although not necessarily copied in bit-for-bit sameness, it is the underlying information that is transferred as, or optionally transformed into PR enforcer executable format) into a ‘buried’ memory space or zone 75d of system memory by the PR enforcer. As used herein the term “system memory” refers to physical memory and includes a physical main memory as well as other data storage that for the most part can be addressed and read from and/or written to at least by a system master processor (and optionally by supplemental other processors). [0085] In one embodiment, the protected regions enforcing mechanism 218e is at least partly implemented as part of the microcode used to define the assembly code level behaviors (operations) of the master one or more of the physical data processing units 218p. Special opcodes are provided for operating the micro-code implemented enforcing mechanism 218e (including for causing it to perform certain operations that only it is allowed to perform). [0086] One of these special opcodes creates the meta-data protecting memory space region (PRM) 218ee and stores therein various protected region attributes (as well as VA/PA direct translation tables—see for example 72c of FIG. 1B) where the latter can only be intelligibly accessed by the PR enforcing mechanism 218e. The protected region attributes may include a read/write (R/W) permission bit, an executable/non-executable (N/NX) control bit for each respective protected region (or for each subsection of the PR, for example for each 4 Kbyte memory page of the PR) as well as additional other operational constraining controls or requirements for each respective protected region or subsection thereof.” Herein Sell discloses controlling access to protected regions via identifying commands by included special opcodes which authorize access to respectively protected regions. In this manner, the data stored therein is protected from unauthorized access and it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize opcodes to verify commands as Campbell also controls access to memory via microcode implementation which may be modified to include the opcodes as presented in Sell to secure code execution (Sell [0002]). Campbell, Neiger, Liljeberg and Sell are analogous art because they are from the same field of endeavor of managing memory accesses in a virtual machine environment.
Regarding claim 2, Campbell, Neiger, Liljeberg and Sell in combination further disclose the processor of claim 1, wherein the plurality of physical memory addresses further include a second physical memory address associated with a second aperture, the first virtual machine to use the second aperture to share information with a second authorized entity, wherein the opcode of the instruction allows the execution circuitry to access the one or more access protected structures to determine the second physical memory address, and wherein the first virtual machine and the second authorized entity are to access the second aperture using the second physical memory address (Neiger [0027-28], Liljeberg [0089-90] and Sell [0086]). Herein Neiger discloses each virtual machine is controlled by a corresponding VMCS which indicate allocated memory. Liljeberg discloses the plurality of memory regions which may be allocated amongst the plurality of virtual machines. In particular, Liljeberg demonstrates sharing between a first and second virtual machine, but one of ordinary skill would recognize the duplication of the feature as obvious for sharing another memory region between two different virtual machines. This is further supported under rationale as presented in MPEP 2144.04 under duplication of parts achieving a predictable result. This is further extended to the disclose of Sell wherein opcodes control access to protected regions and therefore a respective opcode may be included in the instruction to access the second physical memory address.
Regarding claim 3, Liljeberg further discloses the processor of claim 2, wherein at least one of the first authorized entity and the second authorized entity comprise a second virtual machine ([0073]). Herein Liljeberg identifies that the protected memory regions are shared between different virtual machines.
Regarding claim 4, Liljeberg further discloses the processor of claim 2, wherein the execution circuitry is to determine a base address by reading the one or more access protected structures and is to use the base address to read the second physical memory address ([0087] The virtual machine monitor (VMM) also maintains the permission table containing the translation mappings between real addresses (i.e. real (real) page number 420 and page offset 410) and real physical addresses (i.e. physical page number 440 and page offset 410). During address translation, the permission table is indexed with the virtual machine (VM) identifier (ID) and selected bits of the virtual machine (VM) physical address. The table provides the means to map the virtual machine (VM) physical address to the corresponding physical address of the hardware layer of the host system. The address translation may be fully hardware-implemented. However, the present invention should not be understood as being limited thereto. [0088] The permission table 320 may be implemented in different ways. One possible implementation is based on an associative array, which is indexed with the virtual machine (VM) identifier (ID) and the virtual machine (VM) physical address to be translated and contains at least one physical base address and size, which define a physical memory region of the physical system memory accessible to the virtual machine (VM). The table illustrated in FIG. 6 presents such an example 4-way associative array.). Herein Liljeberg discloses access protected structure contains a physical base address and size which defines the protected memory region.
Regarding claim 5, Campbell and Neiger further disclose the processor of claim 1, wherein at least one of the one or more access protected structures comprises a virtual machine control structure used to store virtual machine and/or virtualization associated information (Campbell [0038] As will be discussed, according to embodiments of the invention, a virtual machine monitor (VMM) operable in conjunction with a host execution mode of the processor may create at least one protected mode environment to operate guest software in a virtual machine. Responsive to a command to switch between protected modes, the VMM causes the processor to atomically switch between an original protected mode environment and a target protected mode environment. A virtual machine execution (VMX) mode may be utilized to enable virtual machine functionality for use in switching between protected modes. Further, a virtual machine control structure (VMCS) may be utilized to store state information related to the original and target protected modes for use in atomically switching between the two.). Herein Campbell explicitly recites employing a VMCS to store virtual machine associated information. Neiger additionally discloses use of VMCS in Paragraphs [0027-28].
Regarding claim 6, Campbell further discloses the processor of claim 1, wherein the processor is to prevent access to the one or more access protected structures by one or more general-purpose memory access instructions ([0016]). Herein Campbell discloses non-protected microcode may not be executed to access protected regions.
Regarding claim 7, Neiger and Liljeberg further disclose the processor of claim 1, wherein the first authorized entity includes a second virtual machine ([0073]). Herein Liljeberg identifies allocating memory for share between two different virtual machines. Neiger also discloses corresponding VMCS to each virtual machine present to control execution of the respective VM.
Regarding claim 8, Campbell further discloses the processor of claim 1, wherein the first virtual machine is to execute an instruction to store information in the first aperture ([0016-18]). Herein Campbell discloses each configuration space may be targeted by respective protected instructions for access.
Regarding claim 9, Liljeberg further discloses the processor of claim 2, wherein the first physical memory address is to indicate a first base address of the first aperture and the second physical memory address is to indicate a second base address of the second aperture ([0087-90]). Each respective allocated region comprises a physical base address and size.
Regarding claim 10, Campbell and Neiger further disclose the processor of claim 1, wherein a virtual machine monitor (VMM) is to allocate a plurality of system memory pages to the first virtual machine, at least a portion of the system memory pages to be allocated to the first aperture (Campbell [0038] As will be discussed, according to embodiments of the invention, a virtual machine monitor (VMM) operable in conjunction with a host execution mode of the processor may create at least one protected mode environment to operate guest software in a virtual machine. Responsive to a command to switch between protected modes, the VMM causes the processor to atomically switch between an original protected mode environment and a target protected mode environment. [0041] The processor and/or chipset 201 further implements a virtual machine monitor (VMM) 204 to aid in implementing the host execution mode. In one embodiment, the host execution mode enables a plurality of separate protected mode environments to be created. These protected mode environments may run guest software. In one embodiment, these protected mode environments may operate as virtual machines. Additionally, memory management functionality 203 is utilized to allocate memory to implement the protected mode environments, for example, as virtual machines.). Herein Campbell discloses a VMM is utilized to allocate memory to the protected regions. Neiger additionally discloses in Paragraphs [0027-28] a VMM controlling each VM via the corresponding VMCS.
Regarding claim 11, Neiger and Liljeberg further disclose the processor of claim 1, wherein the first physical memory address is a host physical memory addresses (Neiger [0027-28] and Liljeberg [0075] and [0085] and [0087]). Herein the protected memory addresses targeted by instructions are indicated as physical addresses of host memory.
Regarding claim 12, Campbell discloses, in the italicized portions, a method comprising: decoding an instruction associated with a virtualization architectural extension ([0016] and [0040]); and executing the instruction ([0017-18]), including: accessing one or more access protected structures corresponding to a first virtual machine to determine a plurality of physical memory addresses associated with a corresponding plurality of apertures, including accessing a first physical memory address of the plurality of physical memory addresses from a virtual machine control structure storing a plurality of virtual machine controls for the first virtual machine, the first physical memory address associated with a first aperture of the plurality of apertures; and the first virtual machine using the first aperture to share information with a first authorized entity, wherein an opcode of the instruction allows access to the one or more access protected structures to determine the first physical memory address, and wherein the first virtual machine and the first authorized entity access the first aperture using the first physical memory address. Herein Campbell discloses a processor structure including decode and execution circuitry to process commands which access protected memory ranges from non-protected access commands, wherein these protected memory ranges are interpreted as being analogous to the plurality of apertures. Campbell does not explicitly recite the details pertaining to accessing the protected structures to determine a plurality of physical memory addresses corresponding to the plurality of apertures including a first physical memory address, from a virtual machine control structure (VMCS), which is enabled to be accessed by an opcode of the instruction and using the first physical address of the first aperture to share information between the first virtual machine and first authorized entity. Regarding accessing the protected structures to determine a physical memory address including to access a first physical memory address from a VMCS, Neiger discloses in Paragraphs [0027-28] use of a VMCS to control access to particular allocated memory spaces on a per virtual machine basis. Each respective VMCS enables the corresponding virtual machine to access a host physical address allocated to it in the system. Neiger does not explicitly disclose using the first physical memory address associated with the first aperture to share information. Regarding this limitation, Liljeberg discloses in Paragraphs [0073] and [0088-90] the system maintains a protected table containing memory address ranges represented by a base address and offset wherein the allocated ranges are shared between different virtual machines for access. Campbell, Neiger, and Liljeberg do not explicitly disclose that the protected structure is accessed via the opcode of the instruction allowing access to the structure. Regarding this aspect of the limitation, Sell discloses in Paragraphs [0034] and [0085-86] controlling access to protected regions via identifying commands by included special opcodes which authorize access to respectively protected regions. Claim 12 is rejected on a similar basis as claim 1.
Regarding claim 13, Campbell, Neiger, and Liljeberg in combination further disclose the method of claim 12, further comprising preventing access to the one or more access protected structures by one or more general-purpose memory access instructions (Campbell [0016]), wherein the first physical memory address is a host physical memory address (Neiger [0027-28] and Liljeberg [0075] and [0085] and [0087]). Claim 13 is rejected on a similar basis as reasons provided in the rejections of claims 6 and 11.
Regarding claim 14, Campbell and Neiger further disclose the method of claim 12, further comprising the first virtual machine executing an instruction to store information in the first aperture (Campbell [0087-90]), wherein a virtual machine monitor (VMM) is to allocate a plurality of system memory pages to the first virtual machine, at least a portion of the system memory pages to be allocated to the first aperture (Campbell [0038] and [0041] and Neiger [0027-28]). Claim 14 is rejected on a similar basis as reasons provided in the rejections of claims 8 and 10.
Regarding claim 15, Liljeberg further discloses the method of claim 12, wherein the first physical memory address indicates a first base address of the first aperture ([0087-90]). Claim 15 is rejected on a similar basis as reasons provided in the rejection of claim 9.
Regarding claim 16, Campbell, Neiger, Liljeberg and Sell in combination further disclose the method of claim 12, wherein the plurality of physical memory addresses further include a second physical memory address associated with a second aperture, the method further comprising the first virtual machine using the second aperture to share information with a second authorized entity, wherein the opcode of the instruction allows access to the one or more access protected structures to determine the second physical memory address, and wherein the first virtual machine and the second authorized entity access the second aperture using the second physical memory address (Neiger [0027-28], Liljeberg [0089-90] and Sell [0086]). Claim 16 is rejected on a similar basis as reasons provided in the rejection of claim 2.
Regarding claim 17, Liljeberg further discloses the method of claim 16, further comprising: determining a base address by reading the one or more access protected structures; and using the base address to read the second physical memory address ([0087-88]). Claim 17 is rejected on a similar basis as reasons provided in the rejection of claim 4.
Regarding claim 18, Campbell discloses, in the italicized portions, a system comprising: a dynamic random access memory (DRAM); and a processor coupled with the DRAM, the processor comprising: decode circuitry to decode an instruction associated with a virtualization architectural extension ([0016] and [0040]); and execution circuitry coupled with the decode circuitry, the execution circuitry to execute the instruction to perform operations ([0017-18]), including to: access one or more access protected structures corresponding to a first virtual machine to determine a plurality of physical memory addresses associated with a corresponding plurality of apertures, including to access a first physical memory address of the plurality of physical memory addresses from a virtual machine control structure that is to be used to store a plurality of virtual machine controls for the first virtual machine, the first physical memory address associated with a first aperture of the plurality of apertures, the first virtual machine to use the first aperture to share information with a first authorized entity, wherein an opcode of the instruction allows the execution circuitry to access the one or more access protected structures to determine the first physical memory address, and wherein the first virtual machine and the first authorized entity are to access the first aperture using the first physical memory address. Herein Campbell discloses a processor structure including decode and execution circuitry to process commands which access protected memory ranges from non-protected access commands, wherein these protected memory ranges are interpreted as being analogous to the plurality of apertures. Campbell does not explicitly recite the details pertaining to the DRAM and accessing the protected structures to determine a plurality of physical memory addresses corresponding to the plurality of apertures including a first physical memory address, from a virtual machine control structure (VMCS), which is enabled to be accessed by an opcode of the instruction and using the first physical address of the first aperture to share information between the first virtual machine and first authorized entity. Regarding accessing the protected structures to determine a physical memory address including to access a first physical memory address from a VMCS, Neiger discloses in Paragraphs [0027-28] use of a VMCS to control access to particular allocated memory spaces on a per virtual machine basis. Each respective VMCS enables the corresponding virtual machine to access a host physical address allocated to it in the system. Neiger does not explicitly disclose using the first physical memory address associated with the first aperture to share information or the DRAM. Regarding these limitations, Liljeberg discloses in Paragraphs [0073] and [0088-90] and [0102-103] the system maintains a protected table containing memory address ranges represented by a base address and offset wherein the allocated ranges are shared between different virtual machines for access. Additionally a DRAM is connected to the MPU. Campbell, Neiger, and Liljeberg do not explicitly disclose that the protected structure is accessed via the opcode of the instruction allowing access to the structure. Regarding this aspect of the limitation, Sell discloses in Paragraphs [0034] and [0085-86] controlling access to protected regions via identifying commands by included special opcodes which authorize access to respectively protected regions. Additionally, Sell also discloses use of a DRAM in Paragraph [0030]. Claim 18 is rejected on a similar basis as claim 1.
Regarding claim 19, Campbell further discloses the system of claim 18, wherein the processor is to prevent access to the one or more access protected structures by one or more general-purpose memory access instructions, and wherein the first virtual machine is to execute an instruction to store information in the first aperture (Campbell [0016-18]). Claim 19 is rejected on a similar basis as reasons provided in the rejections of claims 6 and 8.
Regarding claim 20, Campbell, Neiger, and Liljeberg further discloses the system of claim 18, wherein the first physical memory address is to indicate a first base address of the first aperture (Liljeberg [0087-90]), and wherein a virtual machine monitor (VMM) is to allocate a plurality of system memory pages to the first virtual machine, at least a portion of the system memory pages to be allocated to the first aperture, and wherein the first physical memory address is a host physical memory address (Campbell [0038] and [0041] and Neiger [0027-28] and Liljeberg [0075] and [0085] and [0087]). Claim 20 is rejected on a similar basis as reasons provided in the rejections of claims 9, 10, and 11.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Goldsmith et al. (US 2016/0188354) – Paragraphs [0015-35] wherein controlling VMs via VMCS is discussed.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALEXANDER J YOON whose telephone number is (408)918-7629. The examiner can normally be reached on Monday-Friday 8am-3pm ET. The examiner’s email is alexander.yoon2@uspto.gov.
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, Jared Rutz can be reached on 571-272-5535. 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.
/ALEXANDER YOON/
Examiner, Art Unit 2135
/JARED I RUTZ/Supervisory Patent Examiner, Art Unit 2135