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 .
Response to Amendment
The Amendment filed 4/10/2026 has been entered. Claims 1-20 remain pending in the present Office Action.
The Amendments to the Specification have been have been fully considered and are sufficient to overcome the Objections set forth in the previous Office Action.
Claim Objections
Claims 1, 3, 6, 12, 16-18 and 20 are objected to because of the following informalities:
In claim 1, line 19, it is unclear whether “the one or more VMs” are referring to the “one or more secure VMs” previously recited in claim 1, lines 9 and 12, or the “one or more VMs” previously recited in claim 1, line 14.
In claim 1, line 23, it is unclear whether “the one or more VMs” are referring to the “one or more secure VMs” previously recited in claim 1, lines 9 and 12, or the “one or more VMs” previously recited in claim 1, line 14.
In claim 3, line 2, it is unclear whether “a self-signed certificate” is the same as or distinct from the self-signed certificate recited in claim 1. Accordingly, claim 3, line 2, should be amended to recite either “[[a]]the self-signed certificate” or to recite “a second self-signed certificate”.
In claim 6, line 2, “a self-signed certificate” seems to be referring to the same self-signed certificate recited in claim 1. Accordingly, claim 6, line 2, should be amended to recite “[[a]]the self-signed certificate”..
In claim 12, line 6, it is unclear whether “the one or more VMs” are referring to the “one or more secure VMs” previously recited in claim 1, lines 9 and 12, or the “one or more VMs” previously recited in claim 1, line 14.
In claim 16, line 22, it is unclear whether “the one or more VMs” are referring to the “one or more secure VMs” previously recited in claim 16, lines 12 and 15, or the “one or more VMs” previously recited in claim 16, line 17.
In claim 16, line 26, it is unclear whether “the one or more VMs” are referring to the “one or more secure VMs” previously recited in claim 16, lines 12 and 15, or the “one or more VMs” previously recited in claim 16, line 17.
In claim 17, line 4, it is unclear whether “a self-signed certificate” is the same as or distinct from the self-signed certificate recited in claim 16. Accordingly, claim 17, line 4, should be amended to recite either “[[a]]the self-signed certificate” or to recite “a second self-signed certificate”.
In claim 18, lines 5-6, it is unclear whether “a self-signed certificate” is the same as or distinct from the self-signed certificate recited in claim 16. Accordingly, claim 18, lines 5-6, should be amended to recite either “[[a]]the self-signed certificate” or to recite “a second self-signed certificate”.
In claim 20, line 20, it is unclear whether “the one or more VMs” are referring to the “one or more secure VMs” previously recited in claim 20, lines 10 and 13, or the “one or more VMs” previously recited in claim 20, line 15.
In claim 20, line 24, it is unclear whether “the one or more VMs” are referring to the “one or more secure VMs” previously recited in claim 20, lines 10 and 13, or the “one or more VMs” previously recited in claim 20, line 15.
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-20 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, lines 21-22, recite “wherein the attestation report cryptographically binds the host public key to the host machine via a has value of the self-signed certificate”.
However, the Specification fails to teach a “has value” of the self-signed certificate. Thus, it is unclear what the claimed “has value” is, and how the attestation report cryptographically binds the host public key to the host machine via the “has value”.
Claim 16, lines 24-25, recite the same limitation identified above with respect to claim 1. Accordingly, claim 16 is rejected under 35 U.S.C. 112(a) for the same reasons presented with respect to claim 1.
Claim 20, lines 22-23, recite the same limitation identified above with respect to claim 1. Accordingly, claim 20 is rejected under 35 U.S.C. 112(a) for the same reasons presented with respect to claim 1.
Claims 2-15 and 17-19 depend from claims 1 and 16, respectively, and therefore inherit the same deficiencies of claims 1 and 16.
For clarity of the record, the Examiner assumes the limitation should be reciting a “hash value” as described in paragraph [0068] of the amended Specification filed 4/10/2026.
Accordingly, to overcome the rejections under 35 U.S.C. 112(a), the Examiner suggests amending claims 1, 16 and 20 to recite, respectively, “wherein the attestation report cryptographically binds the host public key to the host machine via a [[has]] hash value of the self-signed certificate” in order to overcome the rejections.
Further, if the suggested amendments to claims 1 and 16 are made, additional amendments should be made in claim 3, line 3, and in claim 17, line 5, to clarify if “a hash value” as currently recited is either the same as or distinct from the hash value recited in claims 1 and 16 (e.g., to recite either “[[a]] the hash value” or “ a second hash value”).
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.
Claims 1-20 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.
Claim 1 recites the limitation "the one or more VMs" in line 14. There is insufficient antecedent basis for this limitation in the claim.
For clarity of the record, the Examiner assumes the recited one or more VMs are referring to the “one or more secure VMs” previously recited in the claim. Accordingly, claim 1, line 14, should be amended to recite “the one or more secure VMs” in order to overcome the rejection.
Claims 2-15 depend from claim 1, and therefore inherit the same deficiencies.
Claim 16 recites the limitation "the one or more VMs" in line 17. There is insufficient antecedent basis for this limitation in the claim.
For clarity of the record, the Examiner assumes the recited one or more VMs are referring to the “one or more secure VMs” previously recited in the claim. Accordingly, claim 16, line 17, should be amended to recite “the one or more secure VMs” in order to overcome the rejection.
Claims 17-19 depend from claim 16, and therefore inherit the same deficiencies.
Claim 20 recites the limitation "the one or more VMs" in line 15. There is insufficient antecedent basis for this limitation in the claim.
For clarity of the record, the Examiner assumes the recited one or more VMs are referring to the “one or more secure VMs” previously recited in the claim. Accordingly, claim 20, line 15, should be amended to recite “the one or more secure VMs” in order to overcome the rejection.
Allowable Subject Matter
Claims 1-20 would be allowable if rewritten or amended to overcome the rejections under 35 U.S.C. 112(a) and 112(b) set forth in this Office action.
The following is a statement of reasons for the indication of allowable subject matter:
Claims 1, 16, and 20 would be allowable for reciting the limitation “receiving, by a data clean room orchestration system, an indication of mutually attested code for a data clean room between two or more partners, wherein the mutually attested code is co-authored by the data clean room orchestration system and at least one of the two or more partners, and wherein an image digest of the mutually attested code has been mutually approved by the two or more partners” in the context of the claims as whole as there was no prior art nor combination of prior art found which taught mutually code co-authored by a data clean room orchestration system and one or more partners of the data clean room, nor was there any prior art found which taught an image digest of the mutually attested code approved by the partners of a data clean room.
The closest prior art found with respect to the above limitation is cited below:
ORTIZ et al. (U.S. Pub. No. 2019/0362083) teaches a data clean room orchestration system receiving an indication of mutually attested code for a data clean room between two or more partners ([0067]-[0068] – “the platform may interface with participating partners (e.g., banks and merchants) to receive, from a respective system of each partner, consumer data including transaction data [...] The received consumer data from the partners cannot be accessed, decrypted or read by any other user, system or process except by the Clean Room for the stipulated purpose, i.e., for the purpose of running the analytics and generating the offers. This platform enables the execution of analytics on encrypted data"; [0087] – “A secure enclave 133 may be configured to store an encrypted dataset in a single secure enclave and execute one or more analytics algorithms"; [0149]-[0150] – “resource manager 1100 can verify that the client system is an authorized party to Clean Room 300. Once the client system has been verified as an authorized party, resource manager 1100 may transmit, and display at the client system, one or more data analytics to which the client system has access. The client system may elect one or more options from the displayed data analytics options.[...] The client system may then send the complete data query to resource manager 1100. Resource manager 1100 may receive the data query from the client system, and proceed to send the query to application manager 1124 in order to launch the data analytics based on the data query from the client system."; [0151 ] – “one or more data analytic operations may be open for inspection and/or signed by all authorized parties participating in Clean Room 300 to assure the authorized parties that the Clean Room is secure and intact."; [0155] – “Similar to a data query 118 from the system illustrated in FIG. 14, a query request 118 from a client system 119 may be sent to the Resource Manager 1100. The query request 118 may include a query for data analytics." The received query indicates data analytics to be performed in Clean Room 300, where the data analytics operations are inspected and signed (i.e., attested) by all parties of the Clean Room.). However, ORTIZ fails to teach or suggest that the data analytics to be performed (i.e., the “mutually attested code”) is “co-authored by the data clean room orchestration system and” one or more of the partners, and fails to teach or suggest “an image digest of the mutually attested code” is mutually approved by the partners.
Kostakis et al. (U.S. Patent No. 11,651,287) teaches an “approved statements table”, i.e., SQL statements which have been mutually approved by two or more partners of a data clean room (Col. 11, line 62-Col. 12, line 23 – “the contents of the approved statements table is agreed upon or otherwise generated by the first database account 405 and second database account 450. For example, the users managing the first database account 405 and second database account 450 agree upon query language that is acceptable to both and include the query language in the approved statements table, and the agreed upon language is stored in the approved statements table 410 on the first database account 405 and also stored in the approved statements table 455 in the second database account 450.”; Col. 18, lines 33-38 – “At operation 1005, the data clean room system 230 stores query data (e.g., agreed-upon SQL statements and query templates). For example, the data consumer and the data provider agree on one or more SQL statements that will enable their use-case for the shared data (e.g., overlap analysis).”). However, Kostakis fails to teach or suggest that the approved SQL statements (i.e., the “mutually attested code”) are “co-authored by the data clean room orchestration system and” one or more of the partners, and fails to teach or suggest “an image digest of” the SQL statements is mutually approved by the partners.
Moyer et al. (U.S. Pub. No. 2024/0380595 A1) teaches a system for performing multi-party computations, in which trusted execution environment retrieves a launcher image corresponding to a container containing a workload to be executed, generates verifiable attestations based on the launcher image, sends the verifiable attestations to an attestation service, receives an identity token from the attestation service in response to the verifiable attestations being validated, sending the identity token to an access policy verifier which determines if the identity token satisfies attribute conditions specified by a user, wherein the attribute conditions may include a launcher image digest configured based on approved workload images ([0003] – “a trusted execution environment (TEE) causes the data processing hardware to perform operations including obtaining a container associated with a first entity, the container executing a workload, the workload requiring access to private resources associated with a second entity. […] receiving, from an access policy verifier, a federated identity token indicating that the verifiable attestation satisfies an attribute condition provided by the second entity.”; [0031] – “The trusted execution environment 145 may generate or retrieve a launcher image 422 corresponding to the container 122 and generate the verifiable attestations 310 based on the launcher image 422. The launcher image 422 indicates the execution environment within the TEE 145. In some implementations, the launcher image 422 is a hardened launcher image 422 that indicates that the container 122 and workload 124 are immutable as the execution environment of the TEE 145 is secure. By generating the hardened launcher image 422, the trusted execution environment 145 assures that the operator (e.g., the requesting entity 20) launching the workload 124 cannot influence execution of the workload 124 beyond availability (e.g., how many instances are created and when they are allowed to run), which image of the container 122 is chosen, and the initial runtime configuration of the container 122. Accordingly, the launcher image 422 provides the operator-isolation required to make claims (i.e., attestations 310) about the workload 124 being executed and/or the container 122. The verifiable attestations 310 may thus be used to prove that the workload 124 is running approved code in an acceptable/approved environment.”; [0032] – “The trusted execution environment 145 may transmit the verifiable attestation 310 to an attestation service 305. The attestation service 305 acts as a workload identity provider in order to translate the verifiable attestations 310 into a form that the trusted execution environment 145 may present to an access policy verifier 350 for evaluation. In some implementations, the attestation service 305 will accept verifiable attestations 310 and, after validating them, produce an identity token 330.”; [0033] – “After receiving the identity token 330, the trusted execution environment 145 may transmit the identity token 330 to the access policy verifier 350. The access policy verifier 350 may include attribute conditions 365 that can be used to evaluate the claims of the identity token 330. […] The attribute conditions 365 may be configured by a user (e.g., the secure entity 10) or configured based on approved workload images 432 (see FIG. 4). The attribute conditions 365 may include one or more properties that can be used to evaluate the claims of the identity token 330 such as a launcher image digest, virtual machine (VM) confidentiality, and/or any information on the launcher image 422 used to generate the verifiable attestations 310. When the access policy verifier 350 determines that the claims of the identity token 330 satisfy the attribute conditions 365, the access policy verifier 350 transmits a federated identity 360 token to the trusted execution environment 145.”). However, Moyer fails to teach fails to teach or suggest that workload/container implementing the workload (i.e., the “mutually attested code”) is “co-authored by the data clean room orchestration system and” one or more of the partners, and fails to teach or suggest the image digest, e.g., the launcher image digest, has been “mutually” approved by the multiple partners.
As such, claims 1, 16, and 20 would be allowable if rewritten to overcome the rejections under 35 U.S.C. 112(a) and 112(b) for the reasons presented above. Claims 2-15 and 17-19 depend from claims 1 and 16, respectively, and would therefore be allowable for the same reasons.
Response to Arguments
Applicant’s arguments, see pages 10-18 of the Remarks, filed 4/10/2026, with respect to the rejections of under 35 U.S.C. 103 of claims 1, 16, and 20 have been fully considered and are persuasive. The rejections of claims 1-20 under 35 U.S.C. 103 have been withdrawn.
Specifically, Applicant’s arguments that ORTIZ does not teach co-authored, image-digest-approved code presented on pages 12-13 are persuasive. The Examiner agrees with the Applicant’s assertion that neither ORTIZ, nor any of the other cited references, teach the limitation “receiving, by a data clean room orchestration system, an indication of mutually attested code for a data clean room between two or more partners, wherein the mutually attested code is co-authored by the data clean room orchestration system and at least one of the two or more partners. and wherein an image digest of the mutually attested code has been mutually approved by the two or more partners” as recited in claims 1, 16, and 20. Accordingly, the rejections of claims 1-20 under 35 U.S.C. 103 have been withdrawn.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
CLEBSCH et al. (U.S. Pub. No. 2022/0413883) teaches an attestation platform provides a token to a secure key store, where the secure key store determines if the claims of the token satisfy requirements of a secure key release policy provided by a user, and the secure key store releases a symmetric key for decrypting the user’s file systems if the claims of the token satisfy the requirements of the secure key release policy (see [0073], [0078]-[0079], and [0107]-[0114]).
Atamli et al. (U.S. Pub. No. 2024/0202315) teaches an entire virtual machine may be executed within a trusted execution environment (TEE), e.g., a secure enclave, such that it is isolated from and inaccessible to the hypervisor and host operating system which manage the virtual machine (see [0010] and [0027]).
Maletsky (U.S. Pub. No. 2017/0235957) teaches a digest of an entire image of authorized code can be used to verify the authenticity of integrity of the entire image of the authorized code (see [0057]).
Brown et al. (U.S. Pub. No. 2013/0145165) teaches a public key/private key pair associated with a specified identity of an electronic device which can be used for encryption/decryption, where a public key certificate, such as a self-signed certificate used in attestation, includes the public key as well as the identity information of the devices, and a hash of the self-signed certificate may be used to verify the self-signed certificate by a recipient (see [0003], [0053]-[0054], [0059], and [0073]).
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 JENNIFER MARIE GUTMAN whose telephone number is (703)756-1572. The examiner can normally be reached M-F: 9:00 am - 5:00 pm.
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, Kevin Young can be reached at 571-270-3180. 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.
/JENNIFER MARIE GUTMAN/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights