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 .
Status of Claims
Claims 1, 5, 7, 22-27 are pending. Claims 2-4, 6, 8-21 are cancelled.
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 Farhan et al (PGPUB 2020/0150886).
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, wherein the configuration is locked in the 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); and
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).
Shanbhogue does not explicitly teach, in response to detecting a change to the configuration, while one or more configuration bits are set, invalidate a link encryption key.
However, Farhan teaches the concept of, in response to detecting a change to a configuration, while one or more configuration bits are set, invalidating a link encryption key ([abstract] secure sanitization of a storage device; [0015] a storage device is configured to detect a hardware configuration change in the host computer to which it is connected and to perform a cryptographic erase operation in response to the detection of the change; during an initialization of the storage device, the storage device can compare a description of hardware components of a host computer that is initializing the storage device to the record stored in the storage device; if the hardware component descriptions do not match, then the storage device can delete its cryptographic key; [0018] the storage device 110 comprises a mode field 142 that indicates a current mode of the storage device 110; the value of the mode field 142 can comprise one or more numbers and/or characters; for example, the mode field 142 can be an enumeration field, such as a bitmask; [0027] the storage device controller 120 can be configured to receive a secure erase request 182 and to inspect the value of the mode field 142 to determine whether the storage device 110 is in the sanitization mode; upon a determination that the storage device 110 is in the sanitization mode, the storage device controller 120 can perform an erase operation to render data stored in the storage locations (e.g., 132) of the storage medium 130 inaccessible; performing the erase operation can comprise deleting the cryptographic key 144).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine invalidating an encryption key in response to a configuration change teachings of Farhan with the locked, trusted configuration table teachings of Shanbhogue, with the benefit of responding to any potential security threats against a system, which may be indicated by attempts to change a system software/hardware configuration to bypass essential security features, by invalidating (in this case by deletion) an encryption key, thereby preventing access to encrypted data, and improving the security environment.
Regarding Claims 7, 24, and 27:
Shanbhogue in view of Farhan 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 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 Farhan, and further in view of Moreau-Arnott et al (PGPUB 2023/0267017).
Regarding Claims 5, 23, and 26:
Shanbhogue in view of Farhan teaches the apparatus of claim 1, the method of claim 22, and the computer-readable medium of claim 15.
Neither Shanbhogue nor Farhan 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 locked, trusted configuration table teachings of Shanbhogue in view of Farhan, in order to incorporate secure endpoint authentication and security protocols into a wide variety of virtualized/cloud environments, such as orchestration environments including microservice architectures, thereby allowing use of such environments with improved validation and security.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 22, and 25 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Regarding the claim objections:
Applicant’s amendments have overcome the previous claim objections, which are therefore withdrawn.
Regarding the rejection of claims under 35 USC 112:
Applicant’s amendments have overcome the previous claim rejections under 35 USC 112(a), which are therefore withdrawn.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 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