DETAILED ACTION
Priority: 10/01/2022
Assignee: Intel
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 .
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
Claims 21-22 in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations belonging to claims 21-22 in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim(s) 1-3, 18 and 22 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim(s) 1, 7, 18 of Gayen et al.(U.S. Patent No. 12,326,816) in view of Vakharwala et al.(2021/0406195).
Claim(s) 4 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim(s) 1, 7, 18 of Gayen et al.(U.S. Patent No. 12,326,816) in view of Vakharwala et al.(2021/0406195), and further in view of Narayanan et al.(20220334991).
The analysis is shown below:
17/958,333(Present)
Patent No. 12,326,816
(claim 1) An offload device comprising: an address translation cache (ATC);
and a processing engine implemented at least partially in hardware, wherein the processing engine is to:
receive a start ATC reservation descriptor, wherein the start ATC reservation descriptor comprises an identifier associated with a virtual machine;
receive an address translation, wherein the address translation comprises a physical address corresponding to a translation of a virtual address; determine that the address translation is associated with the identifier included in the start ATC reservation descriptor;
and store the physical address in the ATC at least partially based on the determination that the address translation is associated with the identifier included in the start ATC reservation descriptor. (18 and 22)
(Claim 1) An offload device comprising: an address translation cache (ATC); and a processing engine implemented at least partially in hardware, wherein the processing engine is to: receive a translation fetch descriptor from a processor of a compute device to be processed by the processing engine, the translation fetch descriptor comprising an indication of a plurality of virtual memory addresses; send, in response to receipt of the translation fetch descriptor, a request for a physical memory address corresponding to individual virtual memory addresses of the plurality of virtual memory addresses; receive, for individual virtual memory addresses of the plurality of virtual memory addresses, a physical memory address; cache, for individual virtual memory addresses of the plurality of virtual memory addresses, the corresponding physical memory address in the ATC; send, without reading from or writing to any of the physical addresses corresponding to the plurality of virtual memory addresses, an indication to the processor that the translation fetch descriptor has been processed; receive a work descriptor from the processor after the indication is sent to the processor that the translation fetch descriptor has been processed, wherein the plurality of virtual memory addresses indicated by the translation fetch descriptor correlates to the work descriptor; and perform a task identified in the work descriptor by performing direct memory access (DMA) operations to individual physical memory addresses corresponding to individual virtual memory addresses of the plurality of virtual memory addresses by accessing physical memory addresses stored in the ATC and without requesting address translation by an IOMMU during performance of the task.
(Vakharwala)
0070 -- As mentioned earlier, in embodiments the use of DevPIC is not limited to storing address-mask for LAM. It is generic infrastructure that can be used to store any process specific information. Another example is to store a Domain-ID (VM-ID) that identifies a VM in the DevPIC
(claim 2) The offload device of claim 1, wherein the identifier associated with the virtual machine comprises a domain identifier, wherein the domain identifier identifies the virtual machine.
(Vakharwala)
0131 -- In an example, the method further comprises, when the process specific information comprises a domain identifier, in response to a single invalidation request, invalidating a plurality of entries of a device translation lookaside buffer associated with the domain identifier, the plurality of entries associated with a plurality of process address space identifiers of a virtual machine having the domain identifier.
(claim 3) wherein the identifier associated with the virtual machine comprises a process address space identifier (PASID), wherein the PASID identifies an application of the virtual machine.
(Vakharwala)
[0131] -- the plurality of entries associated with a plurality of process address space identifiers of a virtual machine having the domain identifier.
(claim 4) wherein the start ATC reservation descriptor comprises one or more flags that indicate whether the identifier associated with the virtual machine is a domain identifier that identifies the virtual machine or a process address space identifier (PASID) that identifies an application of the virtual machine.
(Narayanan)
[0103] -- As discussed below, the priority descriptor may specify the domain (e.g., VM 304) and/or the process address space identifier (PASID) that should receive priority access to the input/output memory management unit (IOMMU) 310 resources
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the features of Vakharwala into the claimed embodiments of Gayen et al. for the benefit of providing a set of transactions for peripheral component interconnect express (PCIe) components to exchange and determine translated addresses in support of native input/output (VO) virtualization in an efficient manner. The apparatus allows reduction of latency in devices, thus improving performance of the device(Vakharwala, Col. 16 lines 31-34).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the features of Narayanan into the claimed embodiments of Gayen et al. in view of Vakharwala for the benefit of virtualization allows the creation of multiple simulated environments, operating systems (OS), or dedicated resources from a single, physical hardware system. The virtual machine running the critical workload experiences undesirable levels of latency and throughput(Narayanen, Col. 16 lines 31-34).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim(s) 1-4, 18, 22 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.Claims 1,18,22 are rejected for reciting limitations that are unclear, vague and indefinite.
Claim 1 recites, ‘an identifier associated with a virtual machine’. Though claim 2 recites, ‘a domain identifier’ and claim 3 recites, ‘a process address space identifier’, and both are associated with the claimed virtual machine, it is unclear which identifier claim 1 refers to.
It is unclear how a ‘domain’ is defined and determined. Therefore it is unclear how the ‘domain identifier’ is represented so that it identifies the VM. Similarly, it is unclear how the PASID is represented. Therefore it is unclear how the PASID identifies an application of the VM.
All parameters are received from the processor or IOMMU. So it is unclear how the offload device can determine/verify the received physical address’s ‘association’ with the ‘identifier’. Furthermore, due to the ‘identifier’ ambiguity the recitation, ‘determine that the address translation is associated with the identifier….’, is obscure and the ‘determination’ is indefinite.
Hence claim 1 is rejected for reciting limitations that are unclear, vague and indefinite. Claims 18,22 also have the same issues.
2.Claims 1,18,22 are rejected for reciting limitations that are unclear, vague and indefinite.
Claim 1 recites, ‘….an identifier associated with a virtual machine’, and ‘….a translation of a virtual address’.
Since it is not explicitly recited, it is unclear if ‘a virtual address’ is associated with the claimed ‘a virtual machine’ or a different, external client device.
It is well known in the art that a virtual machine possesses its own independent, contiguous virtual address space/addresses which is created and managed by the hypervisor. Accordingly, it is unclear how the recited virtual machine is associated with only one ‘virtual address’.
More importantly, claim 1 recites, ‘receive an address translation, ….corresponding to a translation of a virtual address’. But as recited, it is unclear how ‘a virtual address’ was received by the IOMMU, so that the address translation comprising a physical address for the virtual address, was received from the IOMMU, by the offload device.
Though the spec recites 2-way communication between the IOMMU and the offload device, claim 1 recites an offload device based one-sided communication which is an incomplete exchange. Hence claim 1 is rejected for reciting limitations that are unclear, vague and indefinite. Claims 18,22 also have the same issues.
3.Claims 1,18,22 are rejected for reciting a limitation that is unclear, inconsistent and indefinite.
Claim 1 recites, ‘receive a start ATC reservation descriptor’ and then recites, ‘receive an address translation….comprising a physical address’.
As recited, these steps are inconsistent with Fig. 15 of the spec.
Claim 1 starts with spec, Fig. 13, determination step 1308: ‘Receive start ATC descriptor?’ Yes. Then claim 1 proceeds to Fig. 15, step 1354.
As per the spec, in order for Fig. 15, step 1354: ‘Receive address translation from IOMMU’ to be true, the previous step, Fig. 15, step 1352, ‘send address translation request to IOMMU’, must be recited.
The spec recites that the offload device receives the address translation from the IOMMU because the offload device sends the translation request to the IOMMU. But claim 1 omits the step. Therefore, as recited, it is unclear how the offload device ‘receives an address translation ….comprising a physical address’, immediately after it receives the ATC descriptor.
Accordingly claim 1 recites a limitation that is inconsistent with the spec. Hence claim 1 is rejected for reciting a limitation that is unclear, inconsistent, incorrect and indefinite. Claims 18,22 also 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, 18, 22 are rejected under AIA 35 U.S.C. 103(a) as being unpatentable over Gayen et al (20210149815) in view of DSA-Arch (‘Intel Data Streaming Accelerator Preliminary Architecture Specification’, Rev 1.2, September 2021, Pgs. 1-197).
As per Claim 1, Gayen discloses an offload device (Gayen, [Fig. 1: offload device 112A]; [0003 - Fig. 1 shows a compute device with an offload device for fetching of address translations]) comprising:
an address translation cache (ATC) (Gayen, [Fig. 1: an address translation cache/ATC 128A]);
a processing engine implemented at least partially in hardware (Gayen, [0022 – Fig. 1: offload device 112A includes a processing engine 126A]; [0074 - The processing engine is implemented at least partially in hardware]),
wherein the processing engine (Gayen, [0022 - The processing engine 126A may be embodied as, e.g., a processor, a memory, a GPU, an accelerator, an ASIC, a FPGA etc.]) is to:
receive a start ATC reservation descriptor (Gayen, [0050 - In Fig. 7, step 702, the offload device 112 receives a translation fetch descriptor from processor 102]),
wherein the start ATC reservation descriptor comprises an identifier associated with a virtual machine (Gayen, [0046 – A translation fetch descriptor formatted as shown in Fig. 4. The translation fetch descriptor indicates that the descriptor is for an address translation fetch operation. The descriptor indicates the beginning of the range of virtual memory addresses/VM to be translated, the size of the virtual memory addresses to be translated, and the stride to use in translating addresses and PASID/identifier]);
receive ([See 112(b)]) an address translation (Gayen, [0056 - In Fig. 8, step 724, in which the offload device 112 sets the current virtual address to translate as the starting virtual address identified in the descriptor]; [0057 - After step 724, in step 726, the offload device 112 prepares an ATS request. The ATS request is prepared based on the parameters determined in step 712 based on the flags and other parameters of the translation fetch descriptor. In step 728, offload device 112 sends the ATS request to IOMMU 118]; [0063 - In Fig. 8, step 730, the IOMMU determines the physical address/PA for the virtual address sent in the descriptor by the offload device. In step 742, the IOMMU 118 sends an ATS response/address translation to offload device 112, thereby implying that the received address translation is because the device sent a translation request to the IOMMU; This is similar to Fig. 15 of the spec]),
wherein the address translation comprises a physical address corresponding to a translation of a virtual address (Gayen, [0058 - In Fig. 8, block 730, the IOMMU 118 determines a physical address corresponding to the virtual address]; [0063 - In Fig. 8, step 742, the IOMMU 118 sends an ATS response to the offload device 112 which comprises the physical address determined by the IOMMU]);
determine that the address translation is associated ([See 112(b)]) with the identifier included in the start ATC reservation descriptor (Gayen, [0063 – Since in Fig. 8, step 742, the IOMMU 118 sends an ATS response to the offload device 112, it implies that the IOMMU validated the translation request previously sent by the device and responded accordingly; This further implies that the received address translation is associated with the identifier in the descriptor]);
store the physical address in the ATC (Gayen, [Fig. 9: step 746, Save Physical Address to ATC]) at least partially based on the determination that the address translation is associated with the identifier ([See 112(b)]) included in the start ATC reservation descriptor (Gayen, [0064 – In Fig. 9, if a page fault was not detected, the offload device 112 saves the physical address to ATC 128, and then method 700 proceeds to step 756 to proceed to the next virtual address, thereby implying that since the address translation is valid, the PA is stored in the ATC at least partially based on the address translation being associated with the identifier included in the ATC descriptor, and processing can move to next step]).
DSA-Arch clarifies the association of the PA with the identifier as follows,
determine that the address translation (DSA-Arch, [Pg. 29, Para-Last, Sec. 3.11:Address Translation - The use of virtual addresses that are shared with processes running on the CPU is called shared virtual memory/SVM. To support SVM the device provides a PASID when performing address translations; Here the PASID sent to the IOMMU in the translation request is the one received earlier in the descriptor]) is associated with the identifier (DSA-Arch, [Pg. 22, Para-2 - The PASID is used by the device to look up addresses in the ATC and to send address translation or page requests to the IOMMU. In Shared mode, the PASID to be used with each descriptor is contained in the PASID field of every descriptor]) included in the start ATC reservation descriptor (DSA-Arch, [Pg. 30, Para-2 - The IOMMU finds the translation by walking the appropriate page tables and returns an address translation response that contains the translated address/physical address and the effective permissions, thereby implying determining that the received address translation is associated with the identifier in the ATC descriptor; Since the claim does not recite how ‘determination’ is done, the citation is a valid interpretation]);
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the PASID of DSA-Arch into the address virtualization of Gayen for the benefit of Intel DSA supporting the PCI Express Address Translation Service/ATS capabilities. ATS describes the device behavior during address translation. When a descriptor enters a descriptor processing unit, the device requests translations for the addresses in the descriptor. If there is a hit in the Address Translation Cache, the device uses the corresponding HPA. If there is a miss or permission fault, the device sends an address translation request to IOMMU for the translation (DSA-Arch, Pg. 30, Para-2).
As per Claim 3, the rejection of claim 1 is incorporated, and Gayen discloses,
wherein the identifier associated with the virtual machine (Gayen, [0051 - In Fig. 7, after step 702, in step 704, the offload device 112 determines one or more virtual addresses/VM identified in the translation fetch descriptor]) comprises a process address space identifier (PASID) (Gayen, [0038 – In Fig. 4, the process address space identifier/PASID field indicates which process address space should be used]),
wherein the PASID identifies an application of the virtual machine (Gayen, [0013 – In Fig. 1, the application can send a translation fetch descriptor to the offload device 112 instructing it to fetch address translations for a certain range of virtual memory addresses/VM]; [0038 - The PASID used corresponds to the process/application executing on the processor 102 that sends the descriptor]);
DSA-Arch further clarifies,
wherein the PASID (DSA-Arch, [Pg. 29, Sec. 3.11:Address Translation - The use of virtual addresses that are shared with processes running on the CPU is called shared virtual memory/SVM. To support SVM the device provides a PASID when performing address translations]; [Pg. 11 – PASID: A value used in memory transactions to convey the address space on the host of an address used by the device]) identifies an application of the virtual machine (DSA-Arch, [Pg. 60, Sec.7.3.3:SVM and PASID Virtualization, Para-7 - Create a mapping for a Guest PASID]; [Pg. 58, Fig. 7.1 – Guest OS 2/VM, Application]; [Pg. 33, Para-1 - When an application or VM that is using Intel DSA is suspended, it may have outstanding descriptors submitted to the device. This work must be completed so the client is in a coherent state that can be resumed later]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the PASID of DSA-Arch into the address virtualization of Gayen, for the benefit of the Intel DSA support an Address Translation Cache/ATC and interacts with DMA Remapping hardware using the PCI-SIG-defined Address Translation Services/ATS, Process Address Space ID/PASID, and Page Request Services/PRS capabilities. The PASID TLP prefix is added to upstream requests to support both Shared Virtual Memory/SVM and Intel Scalable IOV (DSA-Arch, Pg. 19).
As per Claim 18, it is similar to claim 1 and therefore the same mappings are incorporated.
As per Claim 22, it is similar to claim 1 and therefore the same mappings are incorporated.
Claim 2 is rejected under AIA 35 U.S.C. 103(a) as being unpatentable over Gayen et al (20210149815) in view of DSA-Arch (‘Intel Data Streaming Accelerator Preliminary Architecture Specification’, Rev 1.2, September 2021, Pgs. 197), Intel-VT (‘Intel Virtualization Technology for Directed I/O’, 2018, Pgs. 275), and Stockwell et al (20200142839).
As per Claim 2, the rejection of claim 1 is incorporated, and Gayen, DSA-Arch disclose shared virtual memory.
Intel-VT further clarifies,
wherein the identifier associated with the virtual machine (Intel-VT, [Pg. 2-1 - Guest Software: Each virtual machine/VM is a guest software environment that supports a stack consisting of an OS and application software]; [Pg. 3-1 - A domain is defined as an isolated environment in the platform, to which a subset of the host physical memory is allocated. I/O devices that are allowed to access physical memory directly are allocated to a domain and referred as the domain’s assigned devices. For virtualization, software treats each VM as a domain]) comprises a domain identifier (Intel-VT, [Pg. 9-14 - DID: Domain Identifier - Identifier for the domain to which the Scalable-Mode PASID Table Entry maps]; [Pg. 6-5, Sec. 6.2.3.1 - Software must program a valid value in the DID field of all scalable-mode PASID-table entries, including entries where the PASID Granular translation type field is set to pass-through or first-level only; Since the domain ID is received from the processor, the citation is a valid interpretation]),
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the domain and domain identifier/DID of Intel-VT into the address virtualization of Gayen, DSA-Arch for the benefit of utilizing the isolation property of a domain by blocking access to its physical memory from resources not assigned to it. Multiple isolated domains are supported in a system by ensuring that all devices are assigned to some domain, and that they can only access the physical resources allocated to their domain (Intel-VT, Pg. 3-1).
Intel-VT discloses that each VM is a domain.
Stockwell clarifies the domain identifier which identifies the VM as follows,
wherein the domain identifier identifies the virtual machine (Stockwell, [Fig. 25: VMID 250; The VMID acts as the identifier that binds a specific address space/domain to a particular VM]; [0158 - The hypervisor defines multiple sets of stage 2 page tables for different VMs, and a VMID 250 provided with the memory access request identifies which particular stage 2 page tables to use for which VM]; [0158 - The VMID and ASID/PASID 250,252 are collectively referred as a translation context identifier 254 which identifies a current translation context; Since both identifiers serve the same purpose: isolating and distinguishing memory address spaces, a PASID can be considered functionally equivalent to an ASID/Address Space ID]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the VMID of Stockwell into the address virtualization of Gayen, DSA-Arch, Intel-VT for the benefit of the MMU supporting two stages of address translation. The attributes in the stage-1 page tables could limit access to processes operating at a given exception level or higher. If the transaction attributes are valid and the access is permitted by the stage-1 page tables, then the MMU returns the corresponding intermediate physical address/IPA. The IPA together with the VMID then indexes into stage-2 page tables which again validate the attributes of the transaction and, if valid, returns a physical address (Stockwell, 0159).
Claim 4 is rejected under AIA 35 U.S.C. 103(a) as being unpatentable over Gayen et al (20210149815) in view of DSA-Arch (‘Intel Data Streaming Accelerator Preliminary Architecture Specification’, Rev 1.2, September 2021, Pgs. 197), and Intel-VT (‘Intel Virtualization Technology for Directed I/O’, 2018, Pgs. 275).
As per Claim 4, the rejection of claim 1 is incorporated, and Gayen discloses,
wherein the start ATC reservation descriptor comprises one or more flags that indicate whether the identifier associated with the virtual machine (Gayen, [0038 - Fig. 4 shows a translation fetch descriptor]) is a domain identifier that identifies the virtual machine or a process address space identifier (PASID) that identifies an application of the virtual machine (Gayen, [0034 - The translation fetch descriptor indicates a range of virtual memory addresses/VM that should be translated as well as certain flags]).
The claim does not recite what the flags are. Intel-VT clarifies the flags as follow,
wherein the start ATC reservation descriptor comprises one or more flags (Intel-VT, [Pg. 4-2 - Translation-requests-with-PASID specify attributes such as Address Type, Address, Length, No-write flag and additional attributes such as PASID value, Execute-Requested flag, and Privileged-mode-Requested flag in the PASID prefix/PASID TLP Prefix; Since the claim does not recite what the flags are and what they indicate, the citation is a valid interpretation]) that indicate whether the identifier (Intel-VT, [Pg. 6-2 – Sec. 6.2.1: Tagging of Cached Translations - Remapping architecture supports tagging of various translation caches such as the ATC which includes First-level paging structure cache and Second-level paging structure cache, both of which use either ‘identifier’ as needed; Since the claim does not define the format and contents of the ATC descriptor, the citation is a valid interpretation]) associated with the virtual machine is a domain identifier that identifies the virtual machine (Intel-VT, [Pg. 3-1, Sec. 3.2:Domains and Address Translation - For virtualization, software treat each virtual machine as a domain, thereby implying that the VMID is the domain identifier that identifies the VM]) or a process address space identifier (PASID) (Intel-VT, [Pg. 1-2 - PASID that identifies the address space targeted by DMA requests. For requests with PASID, the PASID value is provided in the PASID TLP prefix of the request, which includes flag mentioned above; This suggests that when an application within a VM requests a DMA operation, every data transfer is tagged with identifier(s) that tells the hardware which application initiated it and the VM]) that identifies an application of the virtual machine (Intel-VT, [Pg. 1-2 - Guest Virtual Address: Processor virtual address used by software running in a partition/VM]; [Pg. 3-1 - Virtual Address/VA space of host application on whose behalf it is performing DMA requests, Guest Virtual Address/GVA space of a client application executing within a VM]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the PASID TLP Prefix into the address virtualization of Gayen, DSA-Arch for the benefit of using DMA address translation as shown in Fig. 3.5 where I/O devices 1 and 2 are assigned to domains 1 and 2, respectively. The software responsible for creating and managing the domains allocates system physical memory for both domains and sets up the DMA address translation function. DMA address in requests initiated by devices 1 & 2 are translated to appropriate HPAs by the remapping hardware (Intel-VT, Pg. 3-2).
Response to Arguments
Applicant's election with traverse of S1(claims 1-4, 18, 22) in the reply filed on January 20, 2026 is acknowledged. The applicant’s arguments for traversal have been fully considered but have not been found persuasive.
Applicant argues: ‘Applicant respectfully traverses the election-of-species requirement because the Office has not set forth, with the requisite specificity, how examining the pending claims together would create a serious search and/or examination burden. See MPEP..……’. (Rem, Pg. 1)
Response: The restriction recites three distinct species : S1, S2, S3. The serious search and examination burden for each species is explained in detail below. At least Figs. 5, 7, 13, pertain to S1. At least Figs. 8, 10, pertain to S2. And at least Figs. 1, 4, 9, 11-12, pertain to S3.
[[A]] With regards to Species-1/S1 : This species deals with the communication between the offload device and the processor/IOMMU based on a received start descriptor comprising an identifier to further acquire an address translation from the IOMMU.
(1) Claim 1 starts the communication with the offload device receiving a VM associated start descriptor from the processor which includes an ‘identifier’ and then proceeds to receive an address translation for a virtual address from the IOMMU and finally stores the translated physical address in the ATC. Claims 18, 22 are similar to claim 1. The 2-way communication required a new search - ***S1:Search 1***
(2) Claim 2 recites that the identifier is a domain identifier that identifies the VM. The claim does not recite the role the domain identifier plays in the offload device-processor/IOMMU communication. This missing information required a new search - ***S1:Search 2***
(3) Claim 3 recites that the identifier is a PASID that identifies an application of the VM. Though both identifiers are associated with the VM, the claim does not recite how the domain identifier is mapped to the PASID. Neither does it recite the role of the PASID in the offload device-IOMMU communication. A new search was required – ***S1:Search 3***
(4) Claim 4 recites that the start descriptor includes one or more flags that indicate whether the VM identifier is a domain identifier or a PASID. The claim does not recite what the flags are and which flag(s) identifies which identifier. A new search was required - ***S1:Search 4***
[[B]] With regards to Species-2/S2 : This species deals with the storage and management of start descriptor attributes and data in the Address Translation Cache/ATC of the offload device and a register of the offload device, by establishing two zones, evicting pre-existing and existing cache entries based on conditions, merging zones, cache occupancy calculation, cache error detection, error processing and one-way message passing. It is well known in the art that eviction is associated with error processing.
(1) Claim 5 stores the identifier in a register of the offload device, establishes in the ATC a first zone to store cache entries associated with identifier, and a second zone.
Claim 7 stores the physical address in the first zone – ***S2:Search 1***
Claim 6 recites evicting from the first zone, pre-stored cache entries not associated with the identifier. Eviction is a non-trivial cache function, and evicting from the first zone cache entries which were already present but not associated with the identifier, requires a new search because a traversal of the all stored cache entries in the first zone is needed to distinguish and determine the unwanted entries and evict them – ***S2:Search 2***
Claims 19-20, 23-24 are similar to claims 5-7.
Claim 13 recites storing the physical address in the first zone by ‘preferentially’ evicting a stored cache entry not associated with the identifier. The preferential eviction suggests a priority-based eviction, requiring an additional search - ***S2:Search 3***
(2) Claim 8 recites a new algorithm for storing a second physical address related to receiving a second address translation for a second virtual address. After determining that the second address translation is not associated with the identifier, the second physical address is stored in the second zone. This new algorithm must operate in a loop to process translations of a first virtual address, a second virtual address etc., and store the second physical address in the second zone because of identifier mismatch – ***S2:Search 4***
(3) Claims 9, 10, 11 recite determining fractional cache occupancy wherein the presence of ‘one or more level bits’ in the start descriptor indicates what fraction of the ATC should be reserved for cache entries associated with the identifier. The claims do not recite how the ‘level bits’ must be interpreted for each fractional occupancy requirement. This feature requires a new search. Claim 9 recites establishing the first zone based on the level bits – ***S2:Search 5***
Claim 10 recites that the level bits indicate that the first zone should be 25% of the ATC. Claim 11 recites that the level bits indicate that the first zone should be 50% of the ATC – ***S2:Search 6***
(4) Claim 12 recites a zone merge feature, which requires a new zone merge algorithm. After receiving a stop descriptor, delete the identifier from the offload device register and merge the first zone and the second zone, without reciting how to achieve the ‘merge’.
Merge is non-trivial because the two zones must be combined without data loss and the combined zone size must not exceed available ATC space. This suggests ATC memory management and requires a new search – ***S2:Search 7***
(5) Claims 14-15 recite detecting an error in the ATC, processing the cache error and one-way message passing.
Claim 14 recites receiving a second descriptor, and determining whether the second descriptor triggers an error (claim does not recite the error condition). If the error is detected, send a message to the MMU.
Claim 15 also recites receiving a second descriptor, determining whether it triggers an error. If the error is detected send a completion record to the MMU, wherein the completion record includes a status code indicative of the error. The recitations require a new search. As mentioned above, cache eviction is closely related to cache error detection and management. Hence claims 14-15 are included in the second species – ***S2:Search 8***
[[C]] With regards to Species-3/S3 : This species deals with communication between system software of the compute device and the compute device (2-way) and also communication between the compute device and offload device (2-way). This 3-component, 2-part communication occurs while determining the Quality-Of-Service/QoS required by a VM for storing address translations in the ATC of the offload device, based on the workload of the VM.
(1) Claims 16,21,25 recite that system software of the compute device determines that a VM requires a high QoS for storing address translations in the ATC of the offload device. The system software then sends a request to the compute device to implement a VM-specific ATC reservation policy in the offload device. This 2-way communication between the system software and the compute device, based on high QoS detection per-VM and its workload reservation policy requires a new search – ***S3:Search 1***
The compute device then sends a start descriptor to the offload device to implement the reservation policy in the offload device. This requires creating and maintaining ‘memory areas’ in the ATC on a per-VM basis to store the information of the implemented reservation policy. This 2-way communication between the compute device and the offload device, based on per-VM reservation policy, requires a new search – ***S3:Search 2***
(2) Claim 17 recites that the system software of the compute device determines a high QoS for the VM if it determines that the VM or a container in the VM is running a high-priority, critical, or real-time workload.
It is well-known in the prior art that VM workloads are dynamic, based on time or demand. Therefore running high-priority, critical, or real-time workloads requires guaranteeing resources to prevent contention during data access, reducing latency, and ensuring consistent performance. A new search is required and some search factors include dedicated memory reservations, high-performance and storage I/O limits - ***S3:Search 3***
The above claim-by-claim analysis clearly shows that the application recites a wide range of technologies that do not share a single general inventive concept. This clearly indicates that the three species S1, S2, S3, are distinct and are not obvious variations of each other. The wide range of technologies makes it extremely challenging to search all claims. In essence, searching all claims imposes an unreasonable, undue burden.
Applicant further argues:‘With respect to S1 versus S2,…….’(Rem, Pg. 1)
Response: Please see above.
As shown above, two-way communication between the offload device and processor/IOMMU to cache an address translation in the offload device based on an identifier, as recited in S1 is distinct from storage and management of attributes and data in the ATC/cache of the offload device by establishing zones, merging zones, searching and evicting pre-existing and existing cache entries based on conditions and attributes, cache occupancy calculation, cache error detection, error processing and one-way message passing, as recited in S2.
In short, communication between 2 components to cache a physical address is different from cache management of pre-existing and new cache entries. S1 and S2 require substantially different fields of search.
Applicant further argues:‘With respect to S1 versus S3,….’(Rem, Pg. 2)
Response: Please see above.
As explained above, two-way communication between 2-components, the offload device and processor/IOMMU to cache an address translation in the offload device based on an identifier, as recited in S1 is distinct from the communication between 3-components, the system software and the compute device (2-way) and also communication between the compute device and the offload device (2-way), as recited in S3. This two-part 3-component communication occurs while determining the Quality-Of-Service/QoS required by a VM for storing address translations in the ATC of the offload device, based on the workload of the VM.
In short, communication between 2 components to cache a physical address is different from VM related Quality-Of-Service measurements involving communication between 3 components. S1 and S3 require substantially different fields of search.
Applicant further argues:‘With respect to S2 versus S3,…..’. (Rem, Pg. 2)
Response: Please see above.
As explained above, storage and management of attributes and data in the ATC of the offload device by establishing zones, merging zones, searching and evicting pre-existing and existing cache entries based on conditions and attributes, cache occupancy calculation, cache error detection, error processing and one-way message passing, as recited in S2, is distinct from the communication between 3-components, as recited in S3. This two-part 3-component communication occurs while determining the Quality-Of-Service/QoS required by a VM for storing address translations in the ATC of the offload device, based on the workload of the VM.
In short, cache management is different from VM related Quality-Of-Service measurements. S2 and S3 require substantially different fields of search.
Applicant further argues:‘Claim 18 (method) recites ………In addition, dependent limitations overlap between apparatus and method claims as shown above (e.g., claim 5 vs. claim 19; claim 6 vs. claim 20; claim 7 vs.claim 24).…..different claim formats. (Rem, Pg. 3)
Response:
For the purposes of consistency, claims 19-20, 23-24 are included in S2, and are withdrawn from consideration in the present action.
For clarity, S1 comprises 1-4,18,22; S2 comprises 1,5-15,18-20,22-24; S3 comprises 1,16-17,18,21,22,25.
Response:
Claims 5-7 are narrowing by reciting the operation of the ‘processing engine’.
Based on the Applicant’s argument and for the purposes of consistency, claims 19-20, 23-24 are included in S2, and are withdrawn from consideration in the present action.
For clarity, S1 comprises 1-4,18,22; S2 comprises 1,5-15,18-20,22-24; S3 comprises 1,16-17,18,21,22,25.
Claim(s) 5-17,19-21 and 23-25 withdrawn from further consideration pursuant to 37 CFR 1.142(b), as being drawn to a nonelected species/invention, there being no allowable generic or linking claim. Applicant timely traversed the restriction (election) requirement in the reply filed on January 20, 2026 .
The requirement is still deemed proper and is therefore made FINAL.
Examiner Notes:
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
1. PCI Express Base Specification Revision 6.0.1, 29 August 2022
2. PCI Express Address Translation Services Specification, Version 1.1, 2009
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