DETAILED ACTION
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 3/16/2026 has been entered.
Status of Claims
Claims 1, 5, 7, 22-27 are pending. Claims 2-4, 6, 8-21 are cancelled.
Claim Objections
Claims 1, 22, 25 are objected to because of the following informalities:
Claims 1, 22, and 25 each recite the following: “…such that one or more configuration bits corresponding to the one or more hardware devices to lock the configuration…”. This should be “are to lock…” or similar.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 5, 7, 22-27 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claim 1 recites “lock the configuration in the trusted table such that one or more configuration bits corresponding to the one or more hardware devices to lock the configuration based on detecting one or more changes to the configuration.” Examiner can find no support for this subject matter in the specification and claims as originally filed. The only apparent reference to a “configuration bit” is as follows:
[0064] At operation 525 the XPU coordinator 412 verifies the configuration using the session key. The XPU Coordinator is a privileged and trusted component that may read the trusted table to verify the configuration. At operation 530 the XPU coordinator 412 locks the configuration. As a part of TDXIO protocol, the security engine on the accelerator has a configuration bit that when set locks the device. In the event of any configuration change when this bit is set, the PCIe Rootport key is invalidated. We ensure that the trusted coordinator sets this bit before verifying the configuration and allowing access. Only the TD which sets the configuration can unset it.
From the above, it is clear that the configuration bit is set first, and then in the event of any configuration change, the PCIe Rootport key is invalidated. However, it is also clear that locking the device using the configuration bit is not based on detecting one or more changes to the configuration; the configuration bit is already set to lock the device. Therefore, the amendment introduces new matter. Claims 22 and 25 contain similar subject matter and are therefore rejected for similar reasons. None of the dependent claims correct the deficiencies of their respective independent claim, and are therefore rejected for the same reasons. For the purposes of art rejection, “lock the configuration in the trusted table such that one or more configuration bits corresponding to the one or more hardware devices to lock the configuration based on detecting one or more changes to the configuration” will be construed as written, i.e. the configuration is locked with a configuration bit based on detecting changes to the configuration.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 7, 22, 24-25, 27 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shanbhogue et al (PGPUB 2019/0228145), and further in view of Nelurouth et al (PGPUB 2021/0021990).
Regarding Claims 1, 22, 25:
Shanbhogue teaches an apparatus, a method, and at least one non-transitory computer-readable medium having stored thereon instructions (abstract, systems, methods, and apparatuses relating to performing an attachment of an input-output memory management unit (IOMMU) to a device, and a verification of the attachment; [0109] non-transitory machine readable medium that stores code), comprising:
processing circuitry to ([0033] processor coupled to various components):
initiate an authentication request relating to one or more hardware devices ([0042] VMM obtains attestation reports from trusted devices and hands them to the trusted domain (TD); the TD verifies these attestation reports and if it accepts the device as trust worthy, the TD requests the SEAM module to configure the trusted device contexts in the IOMMU such that this device can now perform DMA to the TDs private memory; [0045] a trusted input/output (I/O) protocol where the device when requested to provide its attestations generates a report that includes the unique ID it received in the trusted ping);
establish, in response to the authentication request, a session key with the one or more hardware devices ([0045] a mechanism to assign a unique ID (e.g., separate from the RID) to each IOMMU being used (e.g., in a platform) where this unique ID (i.e. “session key”) is configured (e.g., assigned) only by a trusted intermediary (e.g., the SEAM module and/or SEAM circuitry); [0047] the device saves the unique IOMMU ID in its internal protected registers, for example, where the unique IOMMU ID cannot be tampered with by a VMM using the software interface or using hardware attacks (e.g., through debug interfaces of the device));
negotiate a virtual function to be implemented by the one or more hardware devices to define a configuration in a trusted table ([0058] TDX (e.g., as discussed above) aware VMM 310, e.g., that creates, manages, and governs the VM instances; [0060] configured by the VMM into the device that is in the processes of being assigned to the TD; [0068] in addition, to limiting to only SEAM accesses, the Trusted VTD register address space of all IOMMUs on a platform are mapped to SEAM's page tables (e.g., IA) and the corresponding MMIO Page Attribute Metadata Table (PAMT) entry/ies are marked off as “allocated” in certain embodiments; in the corresponding MMIO PAMT entries, the VTDBAR (e.g., host physical address (HPA)) of the corresponding IOMMU (or unique identifier) and owner (e.g., SEAM module) can be inserted as part of the process; hence these MMIO pages are locked/reserved and cannot be allocated any further as part of adding a secure EPT (e.g., via execution of an ADDSEPT instruction) for MMIO mapping to TDs in certain embodiments);
verify the configuration with the one or more hardware devices using the session key ([0078] in response to a “Lock and Trusted Interface Report” command, the device locks the configuration of the corresponding interface (e.g., physical function (PF)/virtual function (VF)/Assignable Device Interface (ADI)) and generates the posture report along with the message authentication code (MAC) with a key pre-negotiated with the trusted agent in certain embodiments; the report structure (e.g., in addition to information about vendor ID, class ID, requestor ID, default PASID, link security status, MMIO BARs etc.) includes the nonce sent as part of request as well as the unique IOMMU identifier received by device from corresponding IOMMU in certain embodiments; the device report is sent to a trusted agent (TA) (e.g., SEAM module) in certain embodiments; in certain embodiments (e.g., after verification of nonce and MAC), the TA modifies the report to avoid any virtualization holes (e.g. calculating BAR HPA hashes) and sends to TD (e.g., with a new MAC calculated with key exchanged with TD) along with device certificate; in one embodiment, the IOMMU identifier flows with this report to TD; the TD guest validates the certificate and associated report to make the decision of bringing the corresponding device (or an interface of device to be assigned to TD) into its TCB); and
lock the configuration in the trusted table ([0068]-[0069] in addition, to limiting to only SEAM accesses, the Trusted VTD register address space of all IOMMUs on a platform are mapped to SEAM's page tables (e.g., IA) and the corresponding MMIO Page Attribute Metadata Table (PAMT) entry/ies are marked off as “allocated” in certain embodiments; in the corresponding MMIO PAMT entries, the VTDBAR (e.g., host physical address (HPA)) of the corresponding IOMMU (or unique identifier) and owner (e.g., SEAM module) can be inserted as part of the process; hence these MMIO pages are locked/reserved and cannot be allocated any further as part of adding a secure EPT (e.g., via execution of an ADDSEPT instruction) for MMIO mapping to TDs in certain embodiments; finally, to prevent attacks by BIOS/VMM in certain scenarios (e.g., falsifying VTDBAR information to SEAM; as discussed below), MCHECK, after the abovementioned VTDBAR verification, configures a trusted table of VTDBARs of all IOMMUs in platform at fixed address in a SEAM range register (SEAMRR), e.g., in registers depicted herein; in one embodiment, a SEAM module executes from within a reserved region of memory which is protected using a range register (e.g., SEAMRR) such that this memory cannot be read or written by any software outside the SEAM module or any devices).
Shanbhogue does not explicitly teach locking, such that one or more configuration bits corresponding to the one or more hardware devices to lock the configuration based on detecting one or more changes to the configuration.
However, Nelurouth teaches the concept of locking, such that one or more configuration bits corresponding to one or more hardware devices to lock a configuration based on detecting one or more changes to the configuration ([0044] the device locking unit 265 may comprise means for determining whether the modem 200/the mobile device 120 is locked by checking for a lock indicator 255 in memory of the modem 200; the lock indicator 255 may comprise one or more bits of the OTPM 230; the device locking unit 265 may be configured, for example, to look for the locking configuration information 290 in a specific memory location, or look for a specific file, or look for a specific directory maintained by the SFS 280 for the locking configuration information; the device locking unit 265 may attempt to recover the locking configuration information 290 in response to determining that the locking configuration information 290 is missing or corrupted; the locking configuration information 290 may be recovered from a backup copy of the locking configuration information 290 stored on the modem 200, if available, or from the wireless network operator by sending a notification to the wireless network operator that the locking configuration information 290 is missing or corrupted; [0039] the locking configuration information 290 may be stored in a persistent memory of the modem 200, including but not limited to the memory 275; the SFS 280 may provide means for detecting modification of the locking configuration information; the locking configuration information 290 may be maintained by the SFS 280, and the SFS 280 may detect attempts to modify (e.g., alter or delete or replace) the locking configuration information 290).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the locking configuration bits to lock a configuration based on detecting one or more changes to the configuration teachings of Nelurouth with the locking a configuration teachings of Shanbhogue, in order to respond to attempts to alter a configuration maliciously or without permission by using a locking bit to confirm the configuration was protected, and restore the locked configuration from a backup, thereby maintaining the appropriate configuration (i.e. configuration is locked) when changes are attempted, improving the security environment.
Regarding Claims 7, 24, and 27:
Shanbhogue in view of Nelurouth teaches the apparatus of claim 1, the method of claim 22, and the non-transitory computer-readable medium of claim 25. In addition, Shanbhogue teaches wherein the processing circuitry is coupled to a memory, the processing circuitry comprises one or more of application processing circuitry or graphics processing circuitry ([0033] memory controller coupled to memory; [0031] when installed over a host machine (e.g., processor) in certain embodiments, a VMM facilitates the creation of VMs, e.g., each with separate operating systems (OS) and applications; the VMM may manage the backend operation of these VMs by allocating the necessary computing, memory, storage and other input/output (I/O) resources, such as, but not limited to, an input-output memory management unit (IOMMU); [0034] graphics controller).
Claim(s) 5, 23, 26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shanbhogue in view of Nelurouth, and further in view of Moreau-Arnott et al (PGPUB 2023/0267017).
Regarding Claims 5, 23, and 26:
Shanbhogue in view of Nelurouth teaches the apparatus of claim 1, the method of claim 22, and the computer-readable medium of claim 15.
Neither Shanbhogue nor Nelurouth explicitly teaches the hardware processor to:
receive, from an application, a payload associated with a first microservice operation to be performed by a virtual function relating to the one or more hardware devices; and
route the payload from the first microservice operation to a second microservice operation.
However, Moreau-Arnott teaches the concept of receiving, from an application, a payload associated with a first microservice operation to be performed by a virtual function relating to the one or more hardware devices ([0003] a series of microservices may be chained together and deployed together when called for a specific purpose, such as data record processing; for example, when a record is received, a corresponding series of microservices may be loaded, and the record may be sent to the first microservice to perform or solve a common task (e.g., find an email address associated with an account for the record); the record may then be passed on or output to other microservices on the chain (e.g. perform other tasks such as sending an email to the email address associated with the account or found by the first microservice)); and
route the payload from the first microservice operation to a second microservice operation ([0003] when a record is received, a corresponding series of microservices may be loaded, and the record may be sent to the first microservice to perform or solve a common task (e.g., find an email address associated with an account for the record); the record may then be passed on or output to other microservices on the chain (e.g. perform other tasks such as sending an email to the email address associated with the account or found by the first microservice)).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the microservice architecture teachings of Moreau-Arnott with the authentication and negotiation between a compute complex and an adjunct device teachings of Shanbhogue in view of Nelurouth, in order to incorporate secure endpoint authentication and security protocols into a wide variety of virtualized/cloud environments, such as orchestration environments such as microservice architectures, thereby allowing use of such environments with improved validation and security.
Response to Arguments
Applicant's arguments filed 3/16/2026 have been fully considered but they are not persuasive.
Regarding the rejection of claims under 35 USC 112:
Applicant’s amendments have overcome the previous claim rejections under 35 USC 112(d), which are therefore withdrawn. However, the amendment has introduced new 35 USC 112(a) issues, presented above.
Regarding the rejection of claims under 35 USC 101:
Applicant’s amendments have overcome the previous claim rejections under 35 USC 101, which are therefore withdrawn.
Regarding the rejection of claims under 35 USC 102/103:
Applicant’s arguments consist of the mere assertion that the amendments to claim 1 overcome the previous rejection(s). However, a new ground(s) for rejection is provided above which does teach the amended subject matter.
Applicant makes no further substantive arguments.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FORREST L CAREY whose telephone number is (571)270-7814. The examiner can normally be reached 9:00AM-5:30PM M-F.
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, William Korzuch can be reached at (571) 272-7589. 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.
/FORREST L CAREY/Examiner, Art Unit 2491
/WILLIAM R KORZUCH/Supervisory Patent Examiner, Art Unit 2491
Prosecution Insights