DETAILED ACTION
Claims 1, 3, 5, 7, 9, 11, 14, 16, 18 are amended. Claims 1-19 are pending.
Priority: December 06, 2022
Assignee: N.C. State Univ
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 11/24/2025 has been entered.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim(s) 1-19 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
1.Amended Claims 1,7,14 are rejected for reciting a limitation that is unsupported by the spec.
Amended Claim 1 recites, ‘an accelerator comprising address translations cached in a private TLB, the private TLB hit indicating presence of a cached address translation associated with the request….and the private TLB miss indicating absence of the privately cached address translation….’.
The spec does not recite this limitation.
Though the claim recites, ‘an accelerator comprising address translations cached in a private TLB’, the spec does not define the contents of cached ‘address translations’. The spec does not disclose the steps of how the accelerator communicates with the IOMMU/cryptoMMU to acquire the address translations to cache them in the private TLB. In other words, how ‘a cached address translation’ is associated with ‘the request’ is undisclosed.
The spec does not disclose matching parameters in ‘a cached address translation’ and request, and use presence or absence of parameters to determine a private TLB hit or miss.
Though the spec recites PASIDs, and MAC generation requires a PASID, there is no disclosure of how the accelerator manages its virtual address space and use the PASID(s) to communicate with the IOMMU, resulting in cached address translation(s) in the private TLB. There is no disclosure of how the private TLB maps virtual addresses/VAs to physical addresses/PAs for fast lookups.
The amendment makes a sweeping statement that effectively seeks to cover the entire breadth of host dependent accelerator architectures, without support from the original disclosure. Therefore the recitation constitutes new matter.
The spec fails to support the scope of the amendment, making the amendment overly broad and encompassing subject matter not described. Hence claim 1 is rejected for reciting a limitation that is unsupported by the spec. Claims 7,14 have the same issue. Claims 2-6,8-13,15-19 are rejected for failing to cure the deficiency from their respective parent claim by dependency.
Claim(s) 4, 10, 17 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention.
1.Claims 4,10,17 are rejected for reciting a limitation where the spec fails to disclose how to use the disclosure without undue experimentation.
Claim 4 recites, ‘determining a key from an authentication key table (AKT) based at least in part upon a device identifier (DevID) associated with the accelerator and a process address space identifier (PASID)’.
The claim recites ‘determining a key from an AKT…..’.
The spec recites storing entries into the AKT housed in the CryptoMMU, where each stored entry of the table comprises a {DevID,PASID} pair and an authentication key. Each stored PASID, of the plurality of PASIDs, is a 20-bit identifier, and the DevID, for each accelerator is represented as ‘device/bus/functionID’. But the spec does not disclose how-to lookup or search the AKT for a particular auth key and retrieve it, based on a {PASID,DevID} pair. Whether it is one accelerator or accelerators, the lookup in the table requires extensive processing, none of which is recited in the spec.
Though the spec recites that each auth key is defined as a per-{DevID, PASID} pair, there is no written description of how the plurality of PASIDs are allocated, bound and tagged with each request from the accelerator. There is no disclosure of how the claimed ‘a PASID’ is identified, for a given DevID, in the AKT, so that the associated auth key can be determined.
It is well-known that efficient searches rely on indexes for fast retrieval of values, but no such search ‘criteria’ is recited in the spec. The spec fails to disclose how to search the AKT and use it to determine the auth key for the claimed or any {DevID,PASID} pair, without undue experimentation. The spec relies on undisclosed steps, making it intensely challenging to search the AKT.
Though accelerators are recited, there is no disclosure of a per accelerator-PASID memory map, AKT lookup steps or specific examples of searches. Given the lack of written description support, the spec makes a functional and structural leap when claim 4 recites ‘determining a key from AKT based….upon a DevID associated with the accelerator and a PASID’.
More importantly, searching the auth key directly from the table is an insecure practice as it may require the original key to be stored in plaintext, making it vulnerable to exposure if the CryptoMMU is compromised.
Since the steps for searching the claimed auth key for the {DevID-PASID} pair is undisclosed, generating the MAC, as recited in claim 1 becomes unreliable. The spec fails to support the scope of the limitation, making the amendment encompass subject matter not described and use the AKT without undue experimentation.
Hence claim 4 is rejected because the spec does not provide enablement for searching the auth key based at least on a {DevID-PASID} pair in the AKT comprising a plurality of {DevID,PASID} pairs, and keys, commensurate in scope with the claims. Claims 10,17 have the same issue.
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.
Claim(s) 1-19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
1.Amended Claims 1,7,14 are rejected for reciting a limitation that is unclear, incorrect and indefinite.
Amended Claim 1 recites, ‘the private TLB hit indicating presence of a cached address translation associated with the request in the private TLB and the private TLB miss indicating absence of the privately cached address translation in the private TLB’.
The spec does not recite this limitation. Paras:0044,0045 recite, ‘upon a private TLB miss’, ‘upon a TLB hit’. That’s all! So it is unclear what the amendment means.
There is no recitation of why ‘a cached address translation’ is in the private TLB in the first instance. Ignoring the virtual address(es) is technically incorrect.
As previously mentioned, the spec does not recite the parameters of ‘a cached address translation’ stored in the private TLB. In addition, it is unclear how the accelerator manages its virtual address space and what additional parameters may be included (virtual address, PASID, DevID, control flags, etc.) in ‘a cached address translation’.
Though claim 4 suggests that the parameters of the ‘cached address translation’ can be more (VA,PASID,DevID,control flags,PA,perm,MAC) than the request (PA,perm,MAC), it is unclear what constitutes ‘a cached address translation’. This indicates that the applicant's possession of the claimed subject matter at the time of filing was incomplete.
Spec, Para-0017 recites, ‘As CryptoMMU enables accelerators to cache their own translations privately’. This suggests that the parameters of an ‘own’ (cached) translation can be custom.
Since it is unclear how ‘a cached address translation’ is associated with ‘the request’, reciting that the hit or miss is based on the presence or absence of the ‘cached address translation’, is incorrectly speculative and unsubstantiated by the spec.
It is well-known that a TLB stores recently used virtual-to-physical memory address translations. Since the claim ignores the virtual address space, it is questionable what parameters actually determine a private TLB hit or miss. Hence amended claim 1 is rejected for reciting a limitation that is unclear, incorrect and indefinite. Claims 7, 14 have the same issue.
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.
Claims 1-3, 7-9, 13, 14-16 are rejected under AIA 35 U.S.C. 103(a) as being unpatentable over Kounavis et al (20200026661, hereinafter Kounavis-1) in view of Jayasena et al (20190018800) and Cong et al (‘Supporting Address Translation for Accelerator-Centric Architectures’, 2017, IEEE, Pgs. 1-12).
As per Claim 1, Kounavis-1 discloses a method for cryptographic memory management (Kounavis-1, [0001 - An IOMMU providing a secure address translation service based on a context of a requesting device/accelerator]; [0007 - Fig. 2 shows components of a system to provide secure address translation services using message authentication codes/MACs and invalidation tracking]; [0034 – In Fig. 2, system 200 comprises a host system-on-a-chip/SOC 210 communicatively coupled to device SOC 240 via a host-to-device link 260]), comprising:
receiving, by a cryptographic memory management unit (CryptoMMU) (Kounavis-1, [0035 – In Figs. 1-2, host SOC 210 comprises root port 220, which comprises IOMMU 226, an Advanced Encryption Standard/AES Cipher-based Message Authentication Code/CMAC module 224, and an invalidation tracking table 222]), a request (Kounavis-1, [0037 - In Fig. 3, step 310, the IOMMU receives a memory access request from a remote device/accelerator via a host-to-device link, wherein the memory access request comprises a host physical address/HPA that identifies a physical address within the memory pertaining to the memory access request and a MAC]) identified as a private translation-lookaside buffer (TLB) miss or private TLB hit from an accelerator (Kounavis-1, [0003 - ATS allows a PCIe device/accelerator to request address translations, from VA/virtual address to HPA, from a translation agent/IOMMU/cryptoMMU. This capability allows the device to store the resulting translations in a Dev-TLB 244/private TLB, and directly use the resulting HPA to subsequently access main memory, via a host-to-device link, such as Cache Coherent Interconnect for Accelerators/CCIX; Here the use of the received HPA in the request implies that it is the result of a prior VA to HPA translation request and caching the translation, thereby identifying a private TLB hit later]) comprising address translations cached in a private TLB (Kounavis-1, [Fig. 2: Dev-TLB 244/private TLB]; [0003 - ATS allows the device to store the translations internally in a Dev-TLB, also called an address translation cache/ATC/private TLB),
the private TLB hit indicating presence of a cached address translation ([See 112(b)]) associated with the request (Kounavis-1, [0041 – Since hit occurred, send translated request to IOMMU, implying presence of cached address translation in private TLB]) in the private TLB (Kounavis-1, [0041 – In Fig. 4, step 450, host 210 receives the HPA and MAC from the remote device 240 in a subsequent memory request, thereby implying a private TLB hit occurred]) and the private TLB miss (Kounavis-1, [0040 - Since miss occurred, send translation request to IOMMU with VA to get PA]) indicating absence of the privately cached address translation in the private TLB (Kounavis-1, [0040 – In Fig. 4, step 435, IOMMU returns the HPA and MAC to the remote device, thereby implying that cached address translation was not there so translation request was sent from device to get the HPA/PA,MAC,etc.]);
in response to the request identified as the private TLB hit (Kounavis-1, [Fig. 3: step 310, send request with physical address and MAC]; [0003 - ATS allows a PCIe device to request address translations, from VA/virtual address to HPA/host physical address/PA, from a translation agent/IOMMU/cryptoMMU. This capability allows the device to store the resulting translations internally in a Dev-TLB, and directly use the resulting HPA to subsequently access/request main memory]), generating a message authentication code (MAC) based upon attributes of a page table entry (PTE) corresponding to the request (Kounavis-1, [0037 – In Fig. 3, step 315, the IOMMU generates a second MAC using the host physical address/PA received with the memory access request and a private key associated with the remote device/acc]; [0041 – In Fig. 4, step 455 the IOMMU 226 re-generates the MAC and at step 450, compares it with the one that was sent by the device; Since the MAC is regenerated, it implies that the IOMMU uses the parameters received in the request to calculate the new MAC]), the attributes comprising a physical address and access permissions (Kounavis-1, [0027 - HPT 135 is a flat or hierarchical table in memory 140 in which for every device associated with the host to use secure ATS, for each page in main memory a corresponding permission entry specifying appropriate R/W permissions is created]; [0053 – In Fig. 6, step 645, the IOMMU 222 calculates the MAC for the requested permissions; As per ATS, PCIe, the PA and permissions are returned to the device, which in a subsequent hit are included in the request. This implies that in addition to the MAC, the request comprises the PA and access permissions]);
comparing the generated MAC to a MAC provided with the request (Kounavis-1, [Fig. 4: step 460 - MAC’s match ?]);
in response to the comparison (Kounavis-1, [Fig. 4: step 460 - MAC’s match ? Yes]), allowing system memory access if the generated MAC matches the MAC provided with the request (Kounavis-1, [0041 – In Fig. 4, if at step 460 the MACs match, then control passes to step 465 and the IOMMU 226 looks up the HPA in the invalidation tracking table 222. If, at step 465 the HPA is not in the invalidation tracking table 222, then access is allowed]).
It is well known that during a miss, PCIe,ATS returns an address translation response that contains the PTE attributes, namely translated address/PA and the permissions.
Jayasena further clarifies the permissions or metadata as follows,
the attributes comprising a physical address and access permissions (Jayasena, [0035 – In Fig. 4, the encrypted physical address includes other information generated by encrypting metadata that is appended to the physical address prior to encryption]; [0012 - The host appends metadata including information indicating permissions associated with the accelerator to the physical address/PA prior to encryption so that the encrypted physical address includes encrypted values of the metadata/permission]; [0039 – In Fig. 5, step 505, the accelerator provides a memory access request including an encrypted physical address to the host processor; Since the encrypted PA includes the permissions, it implies that the attributes/PA,perms are included in the request]);
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the translated request of Jayasena into the memory address translation and memory protection of Kounavis-1, for the benefit of the host processor/IOMMU being configured to verify that the accelerator is authorized to access physical addresses indicated in memory access requests on the basis of the information included in an encrypted physical address transmitted by the accelerator in the memory access request (Jayasena, 0021).
Kounavis-1,Jayasena disclose a CryptoIOMMU communicating with an accelerator that caches address translations in a private TLB or Dev TLB.
Cong clarifies the ‘private TLB’ as follows,
an accelerator comprising address translations cached in a private TLB (Cong, [Pg. 1, Abstract, Para-2 - A relatively small private TLB design to provide low-latency caching of translations to each accelerator]),
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the relatively small private TLB of Cong into the memory address translation and memory protection of Kounavis-1,Jayasena for the benefit of using the relatively small, 16-32 entries, low-latency private TLB to allow accelerators save trips to the IOMMU, and also capture the page access locality (Cong, Pg. 2, Col. 1, Sec. 1:Private TLBs, Para-last).
As per Claim 2, the rejection of claim 1 is incorporated, and Kounavis-1 discloses,
wherein system memory access is denied if the generated MAC does not match the MAC (Kounavis-1, [Fig. 4: step 460, MACs match? No]) provided with the request (Kounavis-1, [0061 – In Fig. 4, step 455, the IOMMU 226/cryptoMMU re-generates the MAC and at step 550 compares it with the one that was sent by the device/accelerator. If at step 460, the MACs do not match, then control passes to step 475 and the device access is denied]).
As per Claim 3, the rejection of claim 1 is incorporated, and Kounavis-1 discloses,
wherein the request identified as the private TLB hit comprises the attributes of the PTE (Kounavis-1, [0037 – In Fig. 3, step 310, the IOMMU receives a memory access request from a remote device/accelerator via a host-to-device link, wherein the memory access request comprises a host physical address/HPA that identifies a physical address within the memory pertaining to the memory access request]; [0025 - The translation agent 130/CryptoMMU provides an access control mechanism that ensures a context of a device can only access HPAs to which it has explicitly been assigned appropriate permissions, thereby implying that the request comprises the HPA/physical address and permissions; Since the claim does not define ‘attributes of the PTE’ and its composition, the citation is a valid interpretation]).
As per Claim 7, Kounavis-1 discloses a system for cryptographic memory management (Kounavis-1, [0007 - Fig. 2 shows components of a system to provide secure address translation services using message authentication codes/MACs and invalidation tracking]; [0034 – In Fig. 2, system 200 comprises a host system-on-a-chip/SOC 210 communicatively coupled to device SOC 240 via a host-to-device link 260]; [0001 - An IOMMU providing a secure address translation service based on a context of a requesting device/accelerator]), comprising:
at least one processing or computing device comprising processing circuitry (Kounavis-1, [0035 – In Figs. 1-2, host SOC 210 comprises root port 220, which comprises IOMMU 226, an Advanced Encryption Standard/AES Cipher-based Message Authentication Code/CMAC module 224, and an invalidation tracking table 222]), the at least one processing or computing device configured to at least:
The remaining limitations are similar to claim 1 and therefore the same rejections are incorporated.
As per Claim 8, it is similar to claim 2 and therefore the same rejections are incorporated.
As per Claim 9, it is similar to claim 3 and therefore the same rejections are incorporated.
As per Claim 13, the rejection of claim 7 is incorporated, and Kounavis-1 discloses,
wherein a trusted computing base comprises the at least one processing or computing device (Kounavis-1, [0021 - Fig. 2: trusted system, such as the IOMMU]).
As per Claim 14, it is similar to claims 1,7 and therefore the same rejections are incorporated.
As per Claim 15, it is similar to claim 2 and therefore the same rejections are incorporated.
As per Claim 16, it is similar to claim 3 and therefore the same rejections are incorporated.
Claims 4, 10, 17 are rejected under AIA 35 U.S.C. 103(a) as being unpatentable over Kounavis et al (20200026661, hereinafter Kounavis-1) in view of Jayasena et al (20190018800), Cong et al, Shanbhogue et al (20190042463) and Huang et al (‘Protect Data of Virtual Machines with MKTME on KVM’, 2018, Pgs. 1-20).
As per Claim 4, the rejection of claim 1 is incorporated, and Kounavis-1, Jayasena,Cong disclose generating a MAC.
Shanbhogue further discloses,
wherein generating the MAC comprises determining a key ([See 112(a)]) from an authentication key table (AKT) (Shanbhogue, [0052 – In Fig. 1, MK-TME engine 145 is utilized in the TD architecture to support one or more encryption keys per each TD 190A-190C to help achieve the cryptographic isolation, thereby implying the presence of a table comprising of keys for each TD/VM/accelerator]) based at least in part upon a device identifier (DevID) associated with the accelerator and a process address space identifier (PASID) (Shanbhogue, [0193 – TDDEVICEBIND - This instruction is used by the TD to indicate it wants to take ownership of a device and/or PASID]; [0195 – Input Parameters: Requester ID/DevID — bus/device/function number of the device/accelerator to own; Device-Exclusive—flag to indicate if the TD wants to take ownership of the entire device function or just a PASID context in that device function]; [Fig. 14]; The citations suggest that each key is based on DevID and PASID]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the trust domain of Shanbhogue into the memory address translation and memory protection of Kounavis-1,Jayasena,Cong for the benefit of providing isolation in virtualized systems using trust domains/TDs. The TD architecture allows the processor to deploy TDs that leverage the MK-TME engine, the MOT, and the access-controlled TD control structures for secure operation of TD workloads (Shanbhogue, 0039).
Huang further clarifies the keys in the MKTME and its processes with their PASIDs/accelerators as follows,
determining a key from an authentication key table (AKT) (Huang, [at least Pgs. 6, 8, 11-13,16; W.r.t. Pg. 11, in Intel's MKTME, a KeyID is a number that indexes an internal CPU table to select a specific AES encryption key and memory mode. Different keys are assigned to different memory regions associated with regions in the accelerator. As shown in Pg. 8, KeyIDs are embedded in the upper bits of physical memory addresses. Therefore based on K1,Jayasena,Cong,Shanbhogue,Huang, when a device/acc presents its credentials, DevID,PASID,key, the IOMMU retrieves the stored hash associated with them. The IOMMU then computes a new hash using the same hashing algorithm and compares the new hash to the stored hash. If the hashes match, the key is verified without exposing the original key in the search, thereby ‘determining the key’]),
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the AES encryption keys of Huang into the memory address translation and memory protection of Kounavis-1, Jayasena, Cong, Shanbhogue, for the benefit of managing accelerators with runtime protection with CPU generated keys (Huang, Pg. 11).
As per Claim 10, it is similar to claim 4 and therefore the same rejections are incorporated.
As per Claim 17, it is similar to claim 4 and therefore the same rejections are incorporated.
Claims 5, 11, 18 are rejected under AIA 35 U.S.C. 103(a) as being unpatentable over Kounavis et al (20200026661, hereinafter Kounavis-1) in view of Jayasena et al (20190018800), Cong et al (2017), and Shanbhogue et al (20190042463).
As per Claim 5, the rejection of claim 1 is incorporated, and Kounavis-1, Jayasena, Cong disclose page table, PTE, physical address, permissions and MAC.
Shanbhogue further discloses,
in response to the response identified as the private TLB miss, obtaining a page table entry (PTE) based upon a page table (Shanbhogue, [Fig. 16]) in host memory corresponding to the private TLB miss (Shanbhogue, [0301 - If there is a miss, then the IOMMU starts the table walk. This walk is done using the platform reserved key ID-PKID through the Trusted Device Context structures]; [0134 - trusted IO translation lookaside buffer/IOTLB]; [0136 - Use trusted IOMMU translation tables for trusted transactions originating from devices]);
determining message authentication code (MAC) based upon attributes of the PTE (Shanbhogue, [0301 - Once the PASID table entry has been walked to, the IOMMU has the pointer to the first level page table, second level page table and the TD Key ID. The first and second level page tables are walked using the TD Key ID. Once the final translation is determined the IOTLB is filled with the translated physical address along with the TD KID/MAC with trusted bit set/permission]);
providing the accelerator with translation information comprising the PTE and the determined MAC, the translation information enabling access by the accelerator (Shanbhogue, [0301 - The physical address and the TD KID are then sent to the mesh to complete the DMA transaction, thereby implying providing the accelerator with translation information comprising the PTE and the determined MAC for access]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the trust domain of Shanbhogue into the memory address translation and memory protection of Kounavis-1,Jayasena,Cong for the benefit of providing isolation in virtualized systems using trust domains/TDs. The TD architecture allows the processor to deploy TDs that leverage the MK-TME engine, the MOT, and the access-controlled TD control structures for secure operation of TD workloads (Shanbhogue, 0039).
As per Claim 11, it is similar to claim 5 and therefore the same rejections are incorporated.
As per Claim 18, it is similar to claim 5 and therefore the same rejections are incorporated.
Claims 6, 12, 19 are rejected under AIA 35 U.S.C. 103(a) as being unpatentable over Kounavis et al (20200026661, hereinafter Kounavis-1) in view of Jayasena et al (20190018800), Cong et al (2017), Shanbhogue et al (20190042463) and Kounavis et al (20210406199, hereinafter Kounavis-2).
As per Claim 6, the rejection of claim 5 is incorporated, and Kounavis-1, Jayasena, Cong, Shanbhogue disclose walking the page table via the HPT.
Kounavis-2 further clarifies,
wherein the PTE is obtained by walking through the page table (Kounavis-2, [0043 – In Fig. 4, at step 420, IOMMU 226 initiates a page walk through the invalidation tracking table 222, and at step 425 the IOMMU 226 generates an encrypted physical address/EPA using a secret key assigned to remote device 240, thereby implying obtaining the PTE]; [0059 – In Fig. 5, at step 520, IOMMU 226 initiates a page walk through the invalidation tracking table 222, and at step 525 the IOMMU 226 generates a MAC using a secret key assigned to the remote device 240 and appends the MAC to the HPA to generate a MAC-PA]; [0097 - page tables are walked]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the translated request of Kounavis-2 into the memory address translation and memory protection of Kounavis-1, Jayasena,Cong,Shanbhogue for the benefit of providing a secure address translation service by a translation agent/CryptoMMU based on message authentication codes/MACs and invalidation tracking (Kounavis-2, 0024).
Shanbhogue clarifies,
wherein the PTE is obtained by walking through the page table (Shanbhogue, [0032 - An extended page table/EPT structure called a Secure Extended Page Table/SEPT is used by a processor/cryptoMMU for TD private/trusted page walks]; [0083 - After system initialization, the SEPT structure is the same as the EPT, except memory for SEPT pages are protected using TD/Trusted Domain ephemeral keys, i.e., pages are encrypted and integrity protected]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the trust domain of Shanbhogue into the memory address translation and memory protection of Kounavis-1, Jayasena, Cong, Kounavis-2 for the benefit of providing isolation in virtualized systems using trust domains/TDs. The TD architecture allows the processor to deploy TDs that leverage the MK-TME engine, the MOT, and the access-controlled TD control structures for secure operation of TD workloads (Shanbhogue, 0039).
As per Claim 12, it is similar to claim 6 and therefore the same rejections are incorporated.
As per Claim 19, it is similar to claim 6 and therefore the same rejections are incorporated.
Response to Arguments
The Applicant's arguments filed on December 22, 2025 have been fully considered, but they are not persuasive.
Applicant argues, ‘Thus, Kounavis-1 in view of Kounavis-2 does not disclose, ….."in response to ….hit….based upon attributes of a PTE corresponding to the request….the attributes comprising a physical address and access permissions," as recited in….amended claim 1’. (Rem, Pg. 13)
Response: This argument is incorrect.
It is well-known in the prior art that in ATS-based architectures and PCIe, during a miss, the IOMMU returns the physical address and the permissions. So during a subsequent hit, it is obvious that the accelerator includes the physical address, permissions and MAC in the request. For example, ‘Intel Data Streaming Accelerator Architecture Specification’, Revision 2.1, 2021, Pg. 30 recites, ‘If there is a miss or permission fault, the device sends an address translation request to IOMMU for the translation. The IOMMU finds the translation by walking the appropriate page tables and returns an address translation response that contains the translated address and the effective permissions’.
Therefore the cited prior art which relies on ATS, PCIe discloses receiving the attributes (PA,permissions),MAC from the IOMMU and including the PA, permissions and MAC in the request.
Please note that in para-0044, the spec does not clearly recite that the permissions are provided to the accelerator. But in para-0045, the {unreceived} permissions are included in the request.
Applicant further argues, ‘Kounavis-1 in view of Kounavis-2 does not disclose, teach or suggest "a request identified….miss or hit from an accelerator comprising address translations cached in a private TLB, the private TLB hit ….presence of a cache address translation….and miss indicating absence ….in the private TLB’. (Rem, Pg. 13)
Response: Simply claiming ‘an accelerator comprising address translations cached in a private TLB’ is invalid because it covers all possible ways to achieve the result (caching address translations between CryptoMMUs and third-party accelerators) and exceeding the disclosure's contribution. The scope of the claim must be limited to the specific structures or methods disclosed, not all possible implementations. Hence the recitation is a 112(a). Regarding the undefined ‘cached address translations’, please see the 112(b) and the O/A.
Applicant further argues: ‘Kounavis-1 in view of Kounavis-2 does not disclose….all the features recited in base claims 4, 10 and 17. The addition of Shanbhogue does not cure the deficiencies….’. (Rem, Pg. 14)
Response: The spec makes a high-level, vague recitation of storing {DevID,PASID} pairs and their corresponding authentication keys in the authentication key table/AKT. But the spec does not disclose searching for a particular auth key and retrieving the auth key from the AKT based on a {DevID,PASID} pair. Claim 4 makes a sweeping statement without written description support. In fact how the accelerator integrates and manages its virtual address space and the PASIDs in co-operation with the cryptoMMU, to search the AKT is undisclosed. Please see the 112(a).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARVIND TALUKDAR whose telephone number is (303)297-4475. The examiner can normally be reached M-F, 10 am-6pm EST.
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, Hosain Alam can be reached at 571-272-3978. 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.
Arvind Talukdar
Primary Examiner
Art Unit 2132
/ARVIND TALUKDAR/Primary Examiner, Art Unit 2132