DETAILED ACTION
Claims 1-25 were restricted. Claims 1-4, 18, 22 are elected. Claims 5-17, 19-21, 23-25 are withdrawn. Claims 1-4, 18, 22 are pending.
Priority: 10/1/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.
Claim 22 in this application is/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 claim(s) 22 in this application that use the word “means” (or “step”) is/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
Reference application/patent Instant/Present Application# 17958333
Application# 17129496
Patent# US12326816B2
Reference application/ US patent US12326816B2: claim 1
Instant application
US20230021888A1: claims 1-4
Preamble:
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:
Preamble:
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;
receive a start ATC reservation descriptor, wherein the start ATC reservation descriptor comprises an identifier associated with a virtual machine;
receive, for individual virtual memory addresses of the plurality of virtual memory addresses, a physical memory address;
receive an address translation, wherein the address translation comprises a physical address corresponding to a translation of a virtual address;
cache, …., the corresponding physical memory address in the ATC;
Obvious because: Portion is reserved
wherein, in response to receipt of the start ATC reservation descriptor, the processing engine is to reserve a portion of the ATC for address translations associated with the virtual machine.
store the physical address in the ATC….
‘….correlates to the work descriptor….’ and ‘….without requesting address translation by an IOMMU….’
Obvious because: An IOMMU natively utilizes a Domain ID to segment VM boundaries. To bypass the IOMMU via the ATC safely, applying a Domain ID to the VM correlation is a standard, obvious implementation choice.
Claim 2:
wherein the identifier associated with the virtual machine comprises a domain identifier, wherein the domain identifier identifies the virtual machine.
‘….plurality of virtual memory addresses…. correlates to the work descriptor….’
Obvious because: When a work descriptor targets a specific application inside a VM, a PASID is the standard industry field used to correlate those specific virtual memory subsets to that task.
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.
Broadly maps to a ‘command structure’, ‘configuration packet’, or ‘work entry’.
Obvious because: a host sends an instruction block to set up translation resources. The ‘ATC reservation descriptor’ is just a specific hardware packet variation.
Maps to ‘control bits’, ‘attribute fields’, or an ‘opcode header’.
Obvious because: Header spaces or status flags within its commands. Designating 1 or 2 bits in a command block to act as a toggle or ‘flag is a standard data packet design choice.
Maps broadly to a ‘virtual context tag’, ‘VM identity string’, or ‘domain marker’.
Obvious because : Assigning a unique tracking ID to a VM context inside the MMU. The ‘Domain ID’ is as a standard label for a VM context.
Maps broadly to an ‘inner process tracking label’ or a ‘sub-context field’.
Obvious because of finer address routing. Adding a finer layer like a PASID to track an application within a VM is an extension of virtualization.
Claim 4:
‘start ATC reservation descriptor’
‘comprises one or more flags’
‘domain identifier that identifies the virtual machine’
‘or a PASID that identifies an application….’
Note: Based on the amendment and arguments, OTDP rejection has been updated.
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.Amended Claims 1-3 are rejected for reciting limitations that are unclear, ambiguous and indefinite.
Amended Claim 1 recites, ‘….the start ATC reservation descriptor comprises an identifier associated with a virtual machine’. Here the limitation introduces a single identifier element.
Parallel dependent Claim 2 further limits this identifier by reciting ‘wherein the identifier….comprises a domain identifier, wherein the domain identifier identifies the virtual machine’.
And parallel dependent claim 3 limits the same identifier by reciting ‘wherein the identifier…. comprises a process address space identifier or PASID, wherein the PASID identifies an application of the virtual machine’.
Because claims 2 and 3 are parallel dependent claims, they create a conflict regarding the scope of the ‘identifier’ established in claim 1.
Furthermore, according to spec Para-0056, which recites ‘Bits 147-144 818 is four-bit flag field’, the domain ID and the PASID are distinct flags to identify different scopes of the address space, the VM domain itself versus a specific application within that VM.
By having separate dependent claims that redefine the single ‘identifier’ of claim 1 as two entirely different structures, it is unclear
whether the ‘identifier’ of claim 1 is intended to be a single generic category that can be either a domain identifier or a PASID, or if the identifier requires both structural features.
By defining the same baseline element of claim 1 (‘identifier’) in two distinct ways in parallel, the boundaries of claim 1 and consequently the boundaries of claims 2 and 3 are rendered ambiguous and indefinite. Therefore the boundary of what the ‘identifier’ in claim 1 is actually limited to when considering the claim dependency tree as a whole, is unclear. It is unclear as to what independent claim 1 actually covers.
Note: Based on the arguments, the rejection has been clarified and maintained.
2.Claim 4 rejected for reciting a limitation that is unclear, inconsistent and indefinite.
Claim 4 recites ‘wherein the start ATC descriptor comprises one or more flags that indicate whether the identifier associated with the VM is a domain identifier that identifies the VM or a PASID that identifies an application of the VM’. Here the claim states that the flag(s) identify the type of the identifier associated with the VM, i.e., whether the identifier is a domain ID or a PASID. As shown below, the claim contradicts the spec.
In Para-0056, the spec states, ‘One of the defined bits, when set, indicates that the PASID should be used to identify the address space for which cache reservation should be made, and the other of the defined bits in the flag 818, when set, indicates that the domain ID should be used to identify the address space for which cache reservation should be made’. Here the flags indicate a functional rule, which identifier to use for identifying a target address space for cache reservation.
Because the claim recites that the flags indicate the type of identifier associated with the VM, while the spec discloses that the flags indicate which address space should receive a cache reservation, there is a clear discrepancy regarding the meaning and scope of the claimed ‘one or more flags’.
The claim is inconsistent with the spec. Since it is unclear as to what ‘one or more flags’ actually indicate, claim 4 is indefinite.
Furthermore claim 4 uses the term ‘or’ (‘a domain ID or a PASID) which is interpreted as ‘either or both’ (inclusive) rather than exclusive. Because the spec describes two distinct bits within the four-bit flag field and fails to disclose a prevention mechanism, a hardware or software register could logically hold a value where both bits are set to 1. In other words the lack of a prevention mechanism in the spec means the claim scope permits both bits to be ‘1’ at the same time. Hence claim 4 is rejected.
Note: This rejection is necessitated by the arguments.
3.Claims 1, 18, 22 are rejected for reciting a limitation that is unclear, inconsistent and indefinite.
Claim 1 recites 'an offload device comprises a processing engine, wherein the processing engine is to receive a descriptor….' and independent claim 18 recites 'a method comprising: receiving by an offload device a descriptor….' and the spec recites 'an offload device may execute a method to receive a descriptor'.
The main issue here is indefinite claim scope due to inconsistent terminology between the claims and the spec regarding who or what performs the actions.
Claim 1, an apparatus claim, states that the processing engine (a component inside the offload device) is the entity that receives the descriptor….etc..
Claim 18, a method claim, states that the offload device itself receives the descriptor…. etc.
The spec in Fig. 13, Para-0085 states that the offload device executes a method to receive the descriptor….etc.
While method claims can be broader than apparatus claims, the explicit shift in which entity performs the steps creates a discrepancy. The spec fails to clearly teach whether the offload device as a whole or the processing engine specifically is required to perform the steps. Hence claims 1, 18, 22 are rejected.
Note: Based on the arguments, the rejection has been clarified and maintained.
4.Amended Claim 1 and claims 18, 22 are rejected for reciting a limitation that is unclear, inconsistent and indefinite.
Claim 1 recites, ‘….the processing engine: to receive a start ATC reservation descriptor’ and then recites, ‘receive an address translation….comprising a physical address….’.
These steps are inconsistent with the spec.
Claim 1 starts with Fig. 13, a method performed by the offload device. step 1308 recites: ‘Receive start ATC descriptor?’ Yes. Then claim 1 jumps to Fig. 15, step 1354.
According to the spec, in order for Fig. 15, step 1354: ‘Receive address translation from IOMMU’ to be true, the previous steps of Fig. 15, namely steps 1342, 1344, 1348, 1352 have to be executed.
While the spec clarifies that the offload device sends a request to the IOMMU to get the translation, the claim itself jumps straight from receiving a descriptor to suddenly receiving the translation out of nowhere.
Consequently, the claim is indefinite because it lacks proper antecedent basis for the operational logic and fails to define the boundaries of the processing engine's required capabilities. Specifically, the claim states that the processing engine is configured to ‘receive an address translation’, but it fails to recite any preceding step or functional capability of generating, triggering, or sending an address translation request.
Without reciting the cooperative step of requesting the translation (which is explicitly required in the spec description of the offload device logic, Fig. 15, step 1352), it is unclear whether the claimed processing engine must possess the functional capability to communicate with the external IOMMU to initiate the translation, or passively read value(s) in a table populated by the offload device or an unrecited external source. Because the claim omits the necessary logical step that bridges the start ATC descriptor to the received translation, the precise scope and operational boundaries of the ‘processing engine’ are unclear.
Since the spec does not support the skipped path, the scope of claim 1 is indefinite. Hence claim 1 is rejected.
Claims 18, 22 are also rejected because the steps performed by the offload device are inconsistent with the spec.
Note: Based on the arguments, the rejection has been clarified and maintained.
5.Amended Claim 1 is rejected is rejected for reciting a limitation that is unclear, vague and indefinite.
Claim 1 recites, ‘receive a start ATC reservation descriptor…..wherein, in response to receipt of the start ATC reservation descriptor, the processing engine is to reserve a portion of the ATC for address translations associated with the virtual machine’.
The limitation links the receipt of the ‘start ATC reservation descriptor’ to the act of reserving a ‘portion’ (e.g., a specific allocation, size, or bounded region) of the ATC.
However, in Fig. 11, Para-0078, step 1104, the spec merely states ‘the compute device may receive a request from system software, such as an orchestrator, to implement a virtual machine specific offload device cache reservation policy’, before sending the start ATC descriptor in next step 1106.
While the spec implements a general ‘policy’ prior to sending the descriptor, it is unclear how the ‘portion’ of the ATC is actually defined, bounded, or sized. More importantly, the claim makes the descriptor the triggering event/vehicle for reserving a portion but the spec does not disclose that the received start ATC descriptor provides a size value, parameter, or instruction necessary to ‘reserve a portion of the ATC…’ for the specific VM.
It is unclear how merely stating a preceding ‘policy’ request results in the hardware processing engine to execute a specific ATC portion reservation for the specific VM.
Therefore it is unclear how the processing engine executes the reservation of a discrete ‘portion’ of the ATC for the VM based on the receipt of the descriptor, when the descriptor itself is not described as containing or dictating the size or allocation parameters.
Hence claim 1 is rejected as being indefinite.
6.Claims 18, 22 are rejected for reciting a limitation that is unclear, inconsistent and indefinite.
Method Claim 18 recites, ‘wherein storing, by the offload device, the physical address in an ATC of the offload device, at least partially based on the determination that the address translation is associated with the identifier included in the start ATC reservation descriptor’.
Claim 18 does not recite any allocation of space, size constraints, or reservation mechanism within the ATC. Because the step to perform the ‘reservation’ function is entirely missing, it implies that the translation could be stored anywhere in the ATC. The limitation creates a disconnect between claim 18, claim 1 and spec because it fails to capture the essential step of using the reserved portion.
Though a method claim is broader, the spec must support it. The spec must show that the inventor was in possession of both the apparatus that allocates memory before storing the translation and a method that stores the translation without requiring the specific prior allocation step. But the spec does not support the second path.
Hence claim 18 is rejected as being indefinite. Claim 22 has the same issue and is also rejected.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3, 18, 22 are rejected under AIA 35 U.S.C. 103 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).
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]),
wherein, in response to receipt of the start ATC reservation descriptor, the processing engine is to reserve a portion of the ATC for address translations associated with the virtual machine (Gayen, [0021 – In Fig. 1, ATC 128A can be considered a memory element that has one or more memory element locations or entries, and each memory element location can be indexed. An index value can point to a memory element location that is allocated/reserved for or contains a virtual memory address and physical memory address translation, thereby implying that a portion of the ATC has been reserved for storing address translations associated with the VM]);
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
The Applicant's arguments filed on August 10, 2026 have been fully considered, but they are not persuasive.
Applicant argues:‘ Applicant notes that Gayen has a corresponding patent application publication US 2021/0149815, dated May 20, 2021, which is more than a year before the filing date of the present application…. ……..Applicant submits that the pending…. requests withdrawal of the non-statutory double patenting rejection’. (Rem, Pg. 1)
Response: This argument is incorrect.
The applicant argues that because Gayen’s Intel publication is available under 35 U.S.C.102(a)(1), overcoming a 103 rejection automatically defeats an OTDP rejection. This is legally incorrect. OTDP evaluates whether the claims of the instant application are patentably indistinct from the issued claims of the reference patent, regardless of statutory prior art timelines.
OTDP is designed to prevent the unjustified timewise extension of the right to exclude. It is based on a claim-to-claim comparison between the pending application (US20230021888A1) and the reference patent (US Patent# 12326816), not on a prior art disclosure comparison per se. Surviving a prior art rejection under 35 U.S.C. 103 does not automatically establish that the pending claims are patentably distinct from the issued claims.
The law prohibits an inventor from getting two separate patents on the same invention. Since the parent application has officially crossed the finish line and issued as a patent (US12326816B2), it is now the formal legal benchmark. So the new 2023 claims are compared against the already-issued claims to ensure that the inventor is not improperly extending their monopoly.
Hence the OTDP rejection is maintained. To fully obviate this rejection, Applicant is invited to file a TD under 37 CFR 1.321.
Applicant further argues: ‘The fact that the identifier of Claim 1 maybe a domain identifier, a PASID, or another identifier satisfying the recited relationship may make Claim 1 broader than Claims 2 and 3, but breadth is not indefiniteness’. (Rem, Pg. 2)
Response: This argument is incorrect.
By defining the same baseline element of claim 1 (‘identifier’) in two distinct parallel ways, the boundaries of claim 1 and consequently the boundaries of claims 2 and 3, are rendered ambiguous and indefinite. Please see the clarified 112(b).
Applicant further argues:‘With respect to Claim 4,……Moreover, the Specification provides an exemplary four-bit flag field and explains that one defined bit indicates use of the PASID and another defined bit indicates use of the domain ID’. (Rem, Pg. 4)
Response: Based on the arguments, please see the 112(b).
Applicant further argues: ‘Claim 1 is an apparatus claim and does not purport to recite a closed sequence of method steps. It requires a processing engine having the recited capabilities, including the capability to receive the address translation’. (Rem, Pg. 5)
Response: Claim 1 is improper because the spec does not disclose that the processing engine (which is included in the offload device) performs the recited functions, namely, ‘receive a start ATC descriptor….’, ‘receive an address translation’, ‘determine that the address translation is associated with the identifier’, ‘….reserve a portion of the ATC….’.
Para-0028 of the spec states, ‘In some embodiments, the processing engine may include circuitry to manage storing and retrieving cache entries in the ATC 128.’ Based on this statement, ‘store the physical address in the ATC’ is the only limitation performed by the processing engine.
The spec does not disclose that the processing engine ‘has the capability to receive the address translation’. The address translation is provided by the IOMMU. The spec does not disclose any mechanism to prove the reception capability of the processing engine from any component.
In Figs. 13-16, the spec discloses that the offload device performs the claim 1 functions. Therefore the claim 1 limitations are unsupported extrapolation.
Though claim 1 is an apparatus claim, the spec must show possession of the full scope of the claim, including any functional steps recited in the apparatus claim. But as explained above, the spec does not show possession for the processing engine performing the above steps (except storing the translation in the ATC).
Applicant further argues:‘The Office Action's reliance on the sequence illustrated in FIG. 15….. The Office Action reasons that because block 1352 of FIG. 15 precedes block 1354, the "send address translation request to IOMMU" operation "must be recited"’. (Rem, Pg. 6)
Response: The claim states that the processing engine is configured to ‘receive an address translation’, but it fails to recite any preceding step or functional capability of generating, triggering, or sending an address translation request. ‘Receive… translation’ does not happen in vacuum.
Because the claim omits the necessary logical step(s) that bridges the start descriptor to the received translation, the operational boundaries of the ‘processing engine’ are unclear. Please see the 112(b).
Figs. 13-15 disclose flow charts describing a set of rules performed by the offload device to reserve and manage entries in the ATC. A flowchart is not a suggestion. It is the definitive algorithm that gives structure to the functions recited in the claim(s). To recite the claim by skipping steps (unless allowed by the spec based on the flowchart) improperly expands the claim scope to recite an undisclosed and non-functional ‘new’ concept. It is a potential 112(a).
Applicant further argues:‘With respect to the allegedly omitted transmission of an address translation request, Claim 18 recites a method "comprising" the stated operations’. (Rem, Pg. 6)
Response: Though a method claim is broader, the spec must support it. Under MPEP 2163, the spec must demonstrate that the inventor had possession of the full scope of a method claim, including any recited functional steps.
Please see the 112(b).
Applicant argues:‘…in the interest of expediting the prosecution ….Applicant has amended claim 1 to recite, "wherein, in response to receipt of the start ATC reservation descriptor, the processing engine is to reserve a portion of the ATC for address’. (Rem, Pg. 9)
Response: The spec describes receiving a ‘start ATC reservation descriptor’ containing an identifier associated with a VM. However, the spec fails to disclose how the processing engine determines the size, amount, or bounds of the ‘portion’ of the ATC to reserve upon receiving this descriptor.
Please see the 112(b).
Conclusion
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 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
Prosecution Insights