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 .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 2/01/23, 3/04/24, and 9/24/25 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-3, 5, 7, 11-16, 18, 20, and 25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Buendgen et al. (US 20200285746), Allen (US 20200076607), Ramachandran et al. (US 20230036145), and Beda, III (US 8677449).
Regarding claims 1, 14, and 25, Buendgen teaches: A method / system / computer program product for personalizing a secure guest instance from a generic boot image (boot image of secure guest par. 0043), using a trusted firmware that maintains metadata of said secure guest instance (secure interface control using guest metadata par. 0043) retrieving, by said secure guest instance, a secret object derived from said at least one retrievable secret from said trusted firmware (secure interface control receiving secret as part of the guest metadata which is cryptographically linked to a guest par. 0043);
Buendgen does not explicitly teach passing a request structure including metadata to establish a secret and modifying metadata.
However, Allen teaches: passing a request structure from said secure guest instance (a number of requests may be issued by applications associated with the secrets data par. 0018) to said trusted firmware (an application may request the creation of a new secret that may be stored in the hypervisor-managed secrets compartment par. 0018, and the application server may include firmware par. 0055) for modifying said metadata of said secure guest instance (the secrets management VM image may contain secret metadata 828 with secrets metadata 830 which may correspond to secret 822 and a secrets data store 836 par. 0052) and to establish at least one retrievable secret in said metadata of said secure guest instance that is specific to said secure guest instance (the hypervisor-managed secrets compartment and/or the secrets managed VM instances may provide the mapping between requests and the secrets that correspond to the requests using lookup tables, metadata, identification tables, and/or other methods to ensure that the proper secret goes to the proper requester par. 0040);
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Buendgen with the teachings of Allen since the teachings of Allen provide a better security solution for protecting secrets in complex systems with a large number of guest virtual machines.
Allen does not explicitly teach modifying metadata or personalizing guest instances.
However, Ramachandran teaches: verifying, by said trusted firmware, said request structure and upon success modifying said metadata as specified by said request structure (using firmware to verify account request approval and in response to approval, updating account metadata par. 0007 – 0010 wherein the user interfaces/accounts can involve vault secrets par. 0052);
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Buendgen and Allen with the teachings of Ramachandran since the creation of vault secrets and updating metadata as outlined by Ramachandran would enhance the methods/systems of the prior combination by creating trust relationships between accounts and storing key value pairs through metadata associated with the relationship, and further implementing a secret engine to enable permissions/trust relationships.
Ramachandran does not explicitly teach personalizing guest instances.
However, Beda teaches: using, by said secure guest instance, said retrieved secret object to personalize said secure guest instance (using external metadata, which can be sensitive, to customize virtual machines Col. 5 Lines 44 – 52).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Buendgen, Allen, and Ramachandran with the teachings of Beda since the customization aspects of Beda would enhance the prior combination through allowing virtual machines to be booted in a customized manner using external metadata that would allow for trusted agents to authenticate/provide tokens to the virtual machines.
Regarding claims 2 and 15, Buendgen teaches: wherein each request structure is integrity protected such that said integrity of said request structure is verified by said trusted firmware (secret bound to metadata being transferred to a trusted component is integrity protected par. 0043).
Regarding claims 3 and 16, Buendgen teaches: wherein said request structure comprises an image measurement value of said secure guest instance passing said request structure (private key of secure interface control comprises a cryptographic measure of a boot image par. 0008), and wherein said trusted firmware rejects said request structure if said measurement value of a boot image of said secure guest instance does not match said image measurement value (the portion of metadata that contains the secret is encrypted by a key that only a secure interface control can compute where verification is used to match guest and secret par. 0043 - 0044, the key including a cryptographic measure of the boot image par. 0008).
Regarding claims 5 and 18, Buendgen teaches: wherein said request structure comprises encrypted data that is only decryptable by said trusted firmware (secure interface control decrypting secret using an exclusively computed key par. 0018 – 0019).
Regarding claims 7 and 20, Buendgen teaches: wherein data of said request structure are encrypted (hardware security module can encrypt data par. 0035), and wherein a modification of said metadata of said secure guest instance comprises adding some of said encrypted data as a secret to said metadata (secrets are transported to a secure interface control as encrypted through a secure channel as part of the guest metadata which is cryptographically linked to the guest, therefore the secret is added as part of the metadata and is encrypted/must be decrypted using a private key par. 0043 – 0044).
Regarding claim 11, Ramachandran teaches: wherein said request structure comprises an indication on how to modify said metadata of said secure guest instance (approval of account provisioning includes updating account metadata, which is specified by instructions included by the program par. 0007).
For motivation to combine see claim 1 above.
Regarding claims 12 and 24, Beda teaches: wherein said metadata comprises controls that determine operations that are executable by said secure guest instance (trusted agent requests a token from the metadata server that is used for authentication as well as determining whether or not requests will be approved/executed Col. 5 Line 44 – Col. 6 Line 26).
For motivation to combine see claim 1 above.
Regarding claim 13, Beda teaches: creating said request structure to modify said metadata of said secure guest instance that has been created but not yet started (modification of external metadata for virtual machine which has not yet been booted but for which information has been created for Col. 5 Line 44 – Col. 6 Line 26).
Claim(s) 4 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Buendgen, Allen, Ramachandran, and Beda, and further in view of Sethi et al. (US 20210406345).
Regarding claims 4 and 17, Sethi teaches: wherein said request structure comprises a universal unique identifier (UUID) of said secure guest instance (the client object may contain information pertaining to the OS and/or other attributes of the VM, the application seeking the license, and the encrypted UUID par. 0032), and wherein said trusted firmware rejects said request structure if said UUID of said secure guest instance passing said request structure does not match said UUID in said request structure (if the encrypted UUIDs do not match, the cloud computing site may abort the request par. 0040).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Buendgen, Allen, Ramachandran, and Beda with the teachings of Sethi since the usage of the UUID would enhance the prior combination by allowing validation of client objects with license keys and appending client object with the license key as a result of successful validation, serving as a way to bind keys to virtual machines.
Claim(s) 6 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Buendgen, Allen, Ramachandran, and Beda, and further in view of Jochheim et al. (US 20160112195).
Regarding claims 6 and 19, Jochheim teaches: wherein said encrypted data of said request structure comprises an extension secret (central instance using master key and additional decryption structure to generate a key extension for the secret key that includes definition of additional component group that should in the future be decryptable using the extension par. 0041 - 0047), and wherein said trusted firmware rejects any request structure received after a first request structure with said extension secret does not match said extension secret of said first request structure received (additional component group is not decrypted if identifiers of the extended secret key do not match par. 0051 - 0052).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Buendgen, Allen, Ramachandran, and Beda with the teachings of Jochheim since the key extension of Jochheim would provide an additional decryption structure that can include definitions of future additional component groups that should be decryptable with the corresponding extended secret key, thereby allowing for software models to not be encrypted newly for every instance.
Claim(s) 8 and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Buendgen, Allen, Ramachandran, and Beda, and further in view of Weise et al. (US 20080181399).
Regarding claims 8 and 21, Weise teaches: wherein said trusted firmware (firmware resident on crypto accelerator/HSM par. 0029) provides cryptographic functions operating on protected keys (HSM securely generates long term secrets for use in cryptographic functions where the secrets can be a private/public/protected key par. 0009), wherein said secret object is a protected key which is only valid for use by said secure guest instance as arguments to one of said cryptographic functions (protected keys are only truly protected if generated and maintained inside the HSM, such that if it is not considered valid then it may not be protected cryptographically par. 0009).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Buendgen, Allen, Ramachandran, and Beda with the teachings of Weise since the protected keys of Weise provide protected keys for long term secrets and to physically protect access to, and use of, said secrets, further enhancing the keys security while providing scalability in using the keys.
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Buendgen, Allen, Ramachandran, Beda, and Jochheim, and further in view of Bringer (US 20180019874).
Regarding claim 10, Bringer teaches: wherein in said request structure, each retrievable secret is associated with a secret reference (secure communication request involves reference secret data which is associated with a secret between two devices par. 0006, 0028 – 0031, 0060 – 0075), and wherein said retrieving said secret object associated with said secret reference from said trusted firmware is enabled by a retrieval interface of said trusted firmware that takes said secret reference as input (inputs are sent by a communication interface and acquired by a data entry interface which determines if reference secret data matches other input data, such as keys or other secret data, to determine if the secure communication should occur when conditions are met par. 0069 – 0075).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Buendgen, Allen, Ramachandran, Beda, and Jochheim with the teachings of Bringer since the use of secret references as inputs provides datums that depend on images of input data which then use a verifier of reference secret data which allows for another avenue of verification between various devices using private keys from said devices.
Allowable Subject Matter
Claims 9, 22, and 23 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim 23 is considered allowable subject matter based upon being dependent to claim 22.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Ritchie (US 20170270318) which outlines a cryptographic unit having a protected memory for storing keys as well as trusted transaction risk processing.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORDAN SCOTT MOTTER whose telephone number is (703)756-1550. The examiner can normally be reached Monday - Friday 7:30 a.m. - 4:30 p.m..
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, Pierre Vital can be reached at 571-272-4215. 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.
/J.S.M./ Examiner, Art Unit 2198
/PIERRE VITAL/ Supervisory Patent Examiner, Art Unit 2198