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 .
This action is in response to the claims filed 3/07/2026. Claims 1-4, 9-20, and 25 are pending. Claims 1 (a machine) and 19 (a method) are independent.
Claim interpretation: “global context”
The term global context and global context isolated are not explicitly defined in the present specification and do not have accepted meanings within the memory encryption art. Therefore, the term does not require any particular structure, format, or use of data beyond that explicitly recited in the claims.
Response to Arguments
Applicant’s remarks on p. 11 with respect to the § 101 rejections are persuasive and the rejections are withdrawn.
Applicant's arguments filed 3/07/2026 have been fully considered but they are not persuasive.
On page 11 of the remarks Applicant discusses the claim interpretation of the term “global context”. Examiner responds that the term is not defined within the claim or the prior art and does not require any structure or particular data elements.
On page 12-13 Applicant asserts that “Independent claims 1 and 19 have been amended to specify, inter alia, that the processor records a "reduced global context identification code (RGCID)" in each entry of the TLB and in- core cache structure, records a "complete global context identification code (CGCID)" in each entry of the shared cache, and manages a "global context identification code conversion table" on each in-core cache structure for conversion between the RGCID and the CGCID.
These features solve a specific hardware limitation: saving precious storage space within the in-core caches (TLB, L1, L2) by using a shorter code (RGCID), while utilizing a longer, complete code (CGCID) in the external shared cache, bridged by a dedicated code conversion table. Chhabra fails to disclose these features.”
This argument is not persuasive.
The claims do not define the reduced global context or complete global context. Nor do the claims detail how the conversion is performed. Significantly, nowhere in the claims is it articulated how the reduced/complete contexts are different.
In absence of any indication that the terms are distinct, they are reasonably interpreted to be both shown by the key remapping tables and data of Chhabra.
(“the KeyID may be derived from a combination of bits in the linear address and the TLB memory mapping. As one example, there may be a top half and a bottom half of the KeyID, where the top half is from the upper linear address non-canonical bits and the bottom half is from the unused upper address bits of the physical address mapping from the TLB, as specified in the page tables. The actual physical address used by a caching fabric may have KeyID bits from both the original linear address and physical address mapping.” Chhabra ¶ 37. See also Chhabra ¶ 39)
A portion of the KMT being a reduced global context, and the entirety being a complete global context.
Applicant responds to this mapping, on page 13 of the remarks, by stating: “Chhabra teaches bit concatenation-combining two different pieces of address information to form a single KeyID. In stark contrast, the present invention's RGCID and CGCID are not two halves of an address.”
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “RGCID and CGCID are not two halves of an address”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
As noted above RGCID and CGCID are not defined in the claims and; therefore, are not excluded from being interpreted as two halves of an address.
On page 13 of the remarks, Applicant states: “The claimed GCID conversion table (206) is a pure code-translation mechanism used solely to expand a short RGCID into a long CGCID before looking up any cryptographic key”.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
The claimed “conversion table” is not defined and cannot exclude prior art conversions, such as those detailed in Chhabra. Critically, nowhere in the claims is it articulated how the conversion is performed, what data is added, removed, or converted. The act of conversion is required only in the most abstract manner and reasonably interpreted to be the data conversions/lookups of Chhabra.
Applicant’s further remarks are not persuasive for the reasons noted above.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-4 and 19-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Chhabra et al., US 2019/0042402 (published 2019).
As to claims 1 and 19, Chhabra discloses a machine/method comprising:
a processor, (see Chhabra Fig. 9) configured to use keys, which are global context isolated, (see Chhabra Fig. 7B) to encrypt and decrypt data of a system memory (see Chhabra ¶¶ 72 and 85 discussing memory 960) that is coupled to the processor, (“KeyID portion of the physical address to lookup the key and use it for encryption/decryption” Chhabra ¶ 45)
wherein the processor identifies the keys using key identification codes, (Chhabra ¶ 45) and each key identification code includes a global context identification code. (see Chhabra Fig. 7B)
wherein the processor includes a plurality of cores, (“Representative details of core 920 are illustrated. Understand that core 930 and/or other present cores may include similar circuitry.” Chhabra ¶ 75) each core includes a translation lookaside buffer (“core 920 includes a TLB 924. In various embodiments, TLB 924 includes entries each having a translation from a linear address to a physical address” Chhabra ¶ 76) and an in-core cache structure, (“a KMT re-mapping can be cached at each processor for optimal performance.” Chhabra ¶ 39. “core 920 includes a key remapping table 926 and a key table 928. Such tables may be implemented within a cache included in core 920.” Chhabra ¶ 76. “access to a given entry 352 within KMT 350 is performed using the KeyID of a full address, which is used to index into KMT 350. KMT 350 implemented as a translation table enables the VMM to directly choose what KeyID to use for a KeyID selected by the guest VM.” Chhabra ¶ 42) and the processor further includes a shared cache shared by the cores; (“a shared cache… the cache 935 may include a mid-level cache, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, a last level cache (LLC), and so on, or combinations thereof. Cores 920, 930 may check whether data is located in cache 935 to execute one or more instructions and/or other data (e.g., program data, etc.), wherein a cache miss may cause a transfer of the data from memory 960 to cache 913 in a block of fixed size (e.g., cache line).” Chhabra ¶ 77. A cache miss of the per core cache causing a multi-level lookup, which is the purpose of multi-level caches.)
wherein the processor records a corresponding reduced global context identification code as the key identification code in each entry of each translation lookaside buffer (“KeyIDs (or at least a portion thereof) may be stored along with physical addresses within TLB 113.” Chhabra ¶ 27) and each entry of each in-core cache structure; (“the KeyID may be derived from a combination of bits in the linear address and the TLB memory mapping. As one example, there may be a top half and a bottom half of the KeyID, where the top half is from the upper linear address non-canonical bits and the bottom half is from the unused upper address bits of the physical address mapping from the TLB, as specified in the page tables. The actual physical address used by a caching fabric may have KeyID bits from both the original linear address and physical address mapping. Likewise, the KeyID may be metadata that is stored in the caching fabric to communicate which key to use for a particular memory transaction/cache line to a memory execution engine.” Chhabra ¶ 37)
wherein the processor records a corresponding complete global context identification code (“the KeyID may be derived from a combination of bits in the linear address and the TLB memory mapping. As one example, there may be a top half and a bottom half of the KeyID, where the top half is from the upper linear address non-canonical bits and the bottom half is from the unused upper address bits of the physical address mapping from the TLB, as specified in the page tables. The actual physical address used by a caching fabric may have KeyID bits from both the original linear address and physical address mapping.” Chhabra ¶ 37) as the key identification code in each entry of the shared cache; and (“a shared cache… the cache 935 may include a mid-level cache, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, a last level cache (LLC), and so on, or combinations thereof. Cores 920, 930 may check whether data is located in cache 935 to execute one or more instructions and/or other data (e.g., program data, etc.), wherein a cache miss may cause a transfer of the data from memory 960 to cache 913 in a block of fixed size (e.g., cache line).” Chhabra ¶ 77. A cache miss of the per core cache causing a multi-level lookup, which is the purpose of multi-level caches.)
wherein the processor further manages a global context identification code conversion table on each in-core cache structure of each core for conversion between the reduced global context identification codes and the complete global context identification codes. (“Referring now to FIG. 3A, shown is a block diagram of a KeyID remapping table (KMT) in accordance with an embodiment of the present invention. Such KMTs may be stored in various locations within a system, including processor-internal cache memories, system memories, among other possible locations. In an embodiment, a KMT re-mapping can be cached at each processor for optimal performance. For example, a full KMT may be stored in addressable memory (similar to page tables or extended page tables), with an additional per-processor local cache similar to a TLB that maintains a low latency translation table for the KMT mappings.” Chhabra ¶ 39. See also Chhabra Fig. 7B showing KMT.)
As to claims 2, and 20, Chhabra discloses the machine/method of claims 1 and 19 and further discloses:
wherein: each key identification code further includes a page granular identification code that manages the keys in granularity of pages. (“VMM-assigned KeyID portion 710 may be obtained from the page tables/extended page tables and thereby be stored in TLB 750 (illustrated with dashed line).” Chhabra ¶ 62)
As to claim 3, Chhabra discloses the machine/method of claims 1 and 19 and further discloses:
a system memory controller, configured to control access to the system memory; and (see Chhabra Fig. 9, item 950. “memory controller 950 may be shared among cores 920, 930, may be coupled with cache 935 (e.g., shared multilevel cache), and may couple cores 920, 930 with memory 960 (e.g., shared DRAM).” Chhabra ¶ 78)
an encryption and decryption engine, running a cryptographic algorithm to encrypt write data in response to a write operation that the system memory controller performs on the system memory, and to decrypt read data in response to a read operation that the system memory controller performs on the system memory, (“Memory encryption engine 940 also includes a decryptor 942, which may decrypt ciphertext data to generate unencrypted data. Decryptor 942 may include an inverse of encryptor 941…. Thus, unencrypted data (e.g., plaintext data) may be implemented as input to encryptor 941 to generate an unreadable copy of the unencrypted data (e.g., ciphertext data) when the unencrypted data is to be stored in memory 960 (e.g., write instruction), wherein decryptor 942 may be implemented to decrypt the ciphertext data and generate the unencrypted data when the ciphertext data is to be fetched from memory 960 (e.g., read instruction).” Chhabra ¶ 82)
wherein the encryption and decryption engine includes a key provider, which provides the keys according to the requested key identification codes, to run the cryptographic algorithm. (“Memory encryption engine 940 may further include a key/tweak value selector 948 to select a key from a plurality of keys (e.g., a key domain) and/or a tweak from a plurality of tweaks (e.g., a tweak domain) for a physical location in memory 960…. select a key and/or a tweak for the physical location in the memory when the function (and/or part thereof) is given access.” Chhabra ¶ 84. See also Chhabra ¶ 82).
As to claim 4, Chhabra discloses the machine/method of claims 3 and 19 and further discloses:
wherein: the cryptographic algorithm is a block message cipher algorithm in an XTS mode. (“block cipher to bind unencrypted data with the physical memory address. A tweak function 945 may include, for example, XTS (XOR-encrypt-XOR)/XEX-based tweaked codebook” Chhabra ¶ 73).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 9, 11-17, and 25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chhabra et al., US 2019/0042402 (published 2019), in view of Lu et al., US 2021/0303469 (published 2021).
As to claim 9, Chhabra discloses the machine/method of claims 1 and further discloses: wherein:
(“a VMM application that instantiates virtual machines to provide services in response to a consumer's request.” Chhabra ¶ 66)
global context identification code… a target reduced global context identification code that is mapped to a target complete global context identification code of the target virtual machine. (“the KeyID may be derived from a combination of bits in the linear address and the TLB memory mapping. As one example, there may be a top half and a bottom half of the KeyID, where the top half is from the upper linear address non-canonical bits and the bottom half is from the unused upper address bits of the physical address mapping from the TLB, as specified in the page tables. The actual physical address used by a caching fabric may have KeyID bits from both the original linear address and physical address mapping.” Chhabra ¶ 37.)
Chhabra does not explicitly disclose:
in response to the processor starting up a target virtual machine that is not being managed in the global context identification code conversion table,
the processor updates the … conversion table to record ….
Lu discloses:
in response to the processor starting up a target virtual machine that is not being managed in the global context identification code conversion table, (“launching a new virtual machine with a reset OS image.” Lu ¶ 30)
the processor updates the … conversion table to record ….
(“The host computer can attempt to reach blocks of data from a copy of the OS image from storage cached locally by the hypervisor (e.g., the host cache). If the required blocks are not stored in the host cache (e.g., there is a cache miss), the blocks are retrieved from a network storage location containing a copy of the OS image represented by, for example, a virtual disk.” Lu ¶ 30)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Chhabra with Lu by providing for VM instantiation and cache updating as detailed in Lu in the KeyID address mapping cache system of Chhabra; i.e. updating the caches of Chhabra when VMs are instantiated. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Chhabra with Lu in order to provide for virtual machine instantiation as required by Chhabra ¶ 66.
As to claim 11, Chhabra in view of Lu discloses the machine/method of claim 9 and further discloses: wherein:
the processor further includes a reduced global context identification code register configured to store the reduced target global context identification code; and (“in addition to or instead of using non-canonical linear address bits to include a KeyID, a processor register that may be written by VM/application software can store a KeyID, or part of a KeyID, to indicate which key (or tweak) to be used at the physical address (or cached metadata) level.” Chhabra ¶ 91)
a page table in the system memory stores a page granular identification code. (“VMM-assigned KeyID portion 710 may be obtained from the page tables/extended page tables and thereby be stored in TLB 750 (illustrated with dashed line).” Chhabra ¶ 62)
As to claim 12, Chhabra in view of Lu discloses the machine/method of claim 11 and further discloses: wherein:
the processor searches the translation lookaside buffer according to a target address; (“Stated another way, the latency of performing a page walk via page miss handler 210 may be avoided when an entry is present within a translation lookaside buffer.” Chhabra ¶ 35. “On a TLB miss, the page tables and extended page tables are walked by the PMH hardware to determine the physical address to use for accessing memory.” Chhabra ¶ 43)
in response to determining that the translation lookaside buffer does not yet contain information about the target address, the processor reads the reduced global context identification code register to get the target reduced global context identification code, and operates a page table lookup unit to search the page table in the system memory; (“On a TLB miss, the page tables and extended page tables are walked by the PMH hardware to determine the physical address to use for accessing memory.” Chhabra ¶ 43. The physical address comprising the key ids, as seen in Chhabra Fig. 7B, and are used for walking the page tables.)
by searching the page table, the processor obtains a target page table entry corresponding to the target address, and gets a target page granular identification code from the target page table entry; and (See Figure 2 and associated decryptions. The physical address comprising the key ids, as seen in Chhabra Fig. 7B, and are used for walking the page tables.)
the processor combines the target reduced global context identification code and the target page granular identification code into a simplified key identification code, and stores the simplified key identification code and the target page table entry in the translation lookaside buffer. (“Page miss handler 210 sends physical address 255 to a translation lookaside buffer 260 for insertion into an entry. As such, more ready access to the LA-to-PA translation may occur by reference to the TLB.” Chhabra ¶ 35)
As to claim 13, Chhabra in view of Lu discloses the machine/method of claim 11 and further discloses: wherein:
in response to determining that the translation lookaside buffer contains the information about the target address, the processor obtains the reduced target global context identification code and the target page granular identification code from the translation lookaside buffer. (“based upon indexing into the TLB with this linear address it can be determined whether a valid translation is present in the TLB for the linear address.” Chhabra ¶ 55, key IDs handled in Fig. 7B and related disclosure.)
As to claim 14, Chhabra in view of Lu discloses the machine/method of claim 11 and further discloses: wherein:
in response to determining that target read data of the target address is not in-core cached, (“a full address 205 is received in a page miss handler 210 from a requester such as a VM or other software entity. By way of a page walk operation performed by page miss handler 210, a physical address 255 is obtained.” Chhabra ¶ 30) the processor converts the reduced target global context identification code into the target complete global context identification code according to the global context identification code conversion table, and combines the target complete global context identification code with the target page granular identification code to form a complete key identification code; (“The physical address comprising the key ids, as seen in Chhabra Fig. 7B, and are used for walking the page tables.)
in response to determining that the target read data of the target address is not in-core cached nor cached in the shared cache, (“the cache 935 may include a mid-level cache, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, a last level cache (LLC), and so on, or combinations thereof. Cores 920, 930 may check whether data is located in cache 935 to execute one or more instructions and/or other data (e.g., program data, etc.), wherein a cache miss may cause a transfer of the data from memory 960 to cache 913 in a block of fixed size (e.g., cache line).” Chhabra ¶ 77. “Page miss handler 210 walks the page tables/extended page tables of page table hierarchy 220 to translate a linear address to a machine/host physical address, which is used to reference memory. PMH 210 may, in embodiments, perform a KMT lookup, and insert the KeyID in the final/host physical address.” Chhabra ¶ 32) the complete key identification code is used to search for a key table in the key provider; and (“a key table (also referred to herein as a “KeyID table”) stored in memory and access controlled by the MKTME execution circuit may store keys” Chhabra ¶ 20. “The physical address comprising the key ids, as seen in Chhabra Fig. 7B, and are used for walking the page tables.)
based on a key obtained from the key provider, the encryption and decryption engine decrypts the target read data obtained from the system memory, to be cached in the shared cache with the complete global context identification code, and cached in the in-core cache structure with the simplified key identification code.
(See Chhabra Fig. 6, discussing loading data from memory and obtaining keys therefore. “at block 660 a decryption operation may be performed using the cryptographic key. Understand that in some cases as where hierarchical key identifiers are used, a single key, associated with a VM or other entity is provided, and additional keying material may be used as a tweak for purposes of the decryption.” Chhabra ¶ 57)
As to claim 15, Chhabra in view of Lu discloses the machine/method of claim 11 and further discloses: wherein:
target write data of the target address is in-core cached with the target reduced global context identification code; (“this full address may be received within processor hardware for a given memory request (e.g., a read or write request).” Chhabra ¶ 48)
to send out the target write data from a target core, (“The memory request further includes associated information, including an indication of the access type and an identifier of the source of the memory request, e.g., a given VM, as indicated by a VM identifier.” Chhabra ¶ 48) the processor converts the target reduced global context identification code into the target complete global context identification code according to the global context identification code conversion table, (“Next, control passes to block 420 where the KeyID portion may be obtained from the full address (e.g., the MSBs of the linear address).” Chhabra ¶ 48) combines the target complete global context identification code with the target page granular identification code to form a complete key identification code, (see Chhabra Fig. 7B)
… a key table in the key provider is searched according to the complete key identification code to obtain a key and, according to the key, (“a key table (also referred to herein as a “KeyID table”) stored in memory and access controlled by the MKTME execution circuit may store keys” Chhabra ¶ 20) the encryption and decryption engine encrypts and programs the target write data (“memory encryption engine 940 includes an encryptor 941, which may encrypt unencrypted data.” Chhabra ¶ 79) to the system memory. (“Memory 960 may be protected using encryption and integrity checking.” Chhabra ¶ 73)
Chhabra does not explicitly disclose the steps of a data write:
and caches the target write data and the complete key identification code in the shared cache; and
to send the target write data out from the shared cache,
Lu discloses the act of writing data outside of the processor cache:
and caches the target write data and the complete key identification code in the shared cache; and
to send the target write data out from the shared cache,
(“The filter driver can be configured to intercept all read and write requests and redirect the requests. For example, for a write request, the filter driver can direct the write request to a memory cache or a write back cache defined separately from the system disk storing a copy of the OS image and to access information from the memory cache or write back cache as appropriate.” Lu ¶ 32)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Chhabra with Lu by providing for VM instantiation and cache/memory reading and writing as detailed in Lu with the KeyID address mapping cache system of Chhabra; i.e. updating the caches of Chhabra when VMs are instantiated and allowing reads and writes from said VM. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Chhabra with Lu in order to provide for virtual machine instantiation for service providing, as required by Chhabra ¶ 66.
As to claims 16, and 25, Chhabra discloses the machine/method of claims 8 and 24 and but does not disclose: wherein:
in response to releasing a target entry from the global context identification code conversion table, the processor executes a flush instruction to flush cached contents, associated with target key identification codes related to the target entry, to the system memory.
Lu further discloses:
in response to releasing a target entry from the global context identification code conversion table, the processor executes a flush instruction to flush cached contents, associated with target key identification codes related to the target entry, to the system memory. (“During a reboot of the virtual machine 400, the memory cache 410, the flush drive 412, and the write back cache 414 can be reset, thereby removing any data from a previous user session.” Lu ¶ 74 “During the rebooting process, the hypervisor can also clear 740 the write back cache as well as any local memory (e.g., memory cache 410), thereby deleting any session-specific information that may have been created by a user or a user session application during the computing session.” Lu ¶ 91)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Chhabra with Lu by providing for VM instantiation and cache updating as detailed in Lu in the KeyID address mapping cache system of Chhabra; i.e. updating the caches of Chhabra when VMs are instantiated and rebooted. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Chhabra with Lu in order to provide for virtual machine instantiation as required by Chhabra ¶ 66, and rebooting, thereby saving processing time Lu ¶ 31.
As to claims 17, Chhabra in view of Lu discloses the machine/method of claim 16 and further discloses: wherein:
the flush instruction performs cache flushing based on a target global context identification code of the target key identification codes. (“the virtual machine 400 can include a flush drive 412. In some implementations, the flush drive can be mapped to a write back cache 414. In some examples, the filter driver 408 can be configured to push data from the local memory cache 410 to the flush drive 412.” Lu ¶ 72, flushing the caches of Chhabra that include context codes and key id codes.)
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chhabra et al., US 2019/0042402 (published 2019), in view of Lu et al., US 2021/0303469 (published 2021), and Shanbhogue et al., US 2018/0067866 (published 2018).
As to claim 10, Chhabra discloses the machine/method of claim 9 and further discloses: wherein:
in response to starting up the target virtual machine, the processor downloads a … of the target virtual machine from the system memory, (“The host computer can attempt to reach blocks of data from a copy of the OS image from storage cached locally by the hypervisor (e.g., the host cache). If the required blocks are not stored in the host cache (e.g., there is a cache miss), the blocks are retrieved from a network storage location containing a copy of the OS image represented by, for example, a virtual disk.” Lu ¶ 30)
obtains the target complete global context identification code therefrom, and maps the target reduced global context identification code to the target complete global context identification code. (“the KeyID may be derived from a combination of bits in the linear address and the TLB memory mapping. As one example, there may be a top half and a bottom half of the KeyID, where the top half is from the upper linear address non-canonical bits and the bottom half is from the unused upper address bits of the physical address mapping from the TLB, as specified in the page tables. The actual physical address used by a caching fabric may have KeyID bits from both the original linear address and physical address mapping.” Chhabra ¶ 37)
Chhabra in view of Lu does not explicitly disclose:
virtual machine control structure
Shanbhogue discloses:
virtual machine control structure
(“the VMM may set a bit flag of a translate-on-entry control field of the VMCS associated with the virtual machine to perform a TOE VM entry. The VMM may also store a logical address in the VMCS, where the logical address corresponds to an instruction to be emulated for the VM machine.” Shanbhogue ¶ 28)
Shanbhogue further discloses: “The virtualization support circuitry may also retrieve data from and store data to a data structure known as a virtual machine control structure (VMCS) as a way to exchange translation-related data with the VMM, as will be explained in detail. The virtualization support circuitry may ultimately perform an exit to the VMM after either successful translation of an address or upon detecting a fault, and storing an identified reason for the exit in the VMCS.” Shanbhogue ¶ 27
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Chhabra in view of Lu with Chanbhogue by utilizing a VMCS control structure as detailed in Chanbhogue. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Chhabra in view of Lu with Chanbhogue in order to provide a control structure (VMCS) to exchange address translation data with the VMM, as discussed in Chanbhogue, thereby providing virtualization functionality that is required, but not detailed, in Chhabra and Lu.
Claim(s) 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chhabra et al., US 2019/0042402 (published 2019), in view of LeMay et al., US 2022/0206958 (published 2022).
As to claim 18, Chhabra discloses the machine/method of claim 12 but does not disclose:
wherein: the processor further includes a free-zone model-specific register and a base address model-specific register, which are configured to respectively set a range and a base address and an encryption-free and decryption-free zone.
LeMay dicloses:
wherein: the processor further includes a free-zone (“In at least some other embodiments, other metadata (or context information) can be encoded in the unused bits of encoded pointer 114 such as a size of plaintext address slices (e.g., number of bits in a plaintext slice of a memory address embedded in the encoded pointer),” LeMay ¶ 70)
model-specific register and a base address model-specific register, which are configured to respectively set a range and a base address and an encryption-free and decryption-free zone. (“certain formats of memory operands specify both a base register and a separate scaled index and/or displacement from the address in the base register. The processor unit may interpret the base register as referencing the beginning of the allocation and the sum of the scaled index and/or displacement as an offset within the allocation. The processor unit may then check that the entire requested access is within the bounds of the allocation.” LeMay ¶ 244. See also LeMay ¶ 419, registers used in accessing data and calculations; therefore, offset is included in or computed within a register.)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Chhabra with LeMay by utilizing the register pointers of LeMay to indicate plaintext slices and encrypted locations, as done in LeMay. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Chhabra with Lemay in order to allow a processor to selectively operate on both encrypted and unencrypted data, thereby saving computational load when encryption is not required.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892, particularly:
Chhabra et al., US 12,518,026, disclosing storage encryption using a converged cryptographic engine.
THIS ACTION IS MADE FINAL. 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 MICHAEL W CHAO whose telephone number is (571)272-5165. The examiner can normally be reached M, W-F 8-5.
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, Rupal Dharia can be reached at (571) 272-3880. 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.
/MICHAEL W CHAO/ Primary Examiner, Art Unit 2492
Prosecution Insights