DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is response to communication filed on March 02, 2026.
Status of claims within the present application:
Claims 1 – 20 are pending.
Claim 1, 14, and 17 are amended.
Response to Amendment
Applicant’s amendments, see page [6] of applicant’s remarks, filed March 02, 2026, with respect to claims 1 – 20 that were rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, regards as the invention have been fully considered and are persuasive. Therefore, the 35 U.S.C. 112(b) rejection is withdrawn.
Applicant’s arguments, see page [6 – 7] of applicant’s remarks, filed March 02, 2026, with respect to claims 1 – 8, 10 – 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 11438155 B2 to Costa in view of US 20240089239 A1 to Kakaiya, have been fully considered, but are not persuasive. Therefore, the applicant is directed to the response below:
With respect to 1, 14, and 17, applicant argued that the prior art does not teach the transformed values, the requester values, and the report are not in the plain text. Examiner noted that prior art does teach having all of the transformed values, the requester values, and the report are not in the plain text. With Costa, the requester values are “parameters included or implied in the received request may be converted in optional step 1204 if it is determined, for example, the data format of a parameter in the original request is not the same as the data format for that parameter in the native platform” and the report are “the results from executing the enclave instructions or calling the enclave hypercalls are cleaned up in box 1312. Clean up may include, for example, converting the output parameters or the exception handling of the enclave processor instructions or the enclave hypercalls into the format or protocol of the abstraction layer interface” which is understood that the values are not in the original plain text. Also, Kakaiya does teach that the transformed values are “Circuitry 1537 at accelerator 1536 provides the transformed data to circuitry 1533 of service TEE 1532. circuitry 1537 encrypts the transformed data. For these examples, similar operations are implemented as described above for read flow 1200 shown in FIG. 12 for circuitry 1533 to encrypt the transformed data and provide the encrypted data” which provided the transformed value into an encrypted data. Therefore, the rejection still stands.
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.
Claims 1 – 8, 10 – 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 11438155 B2 to Costa in view of US 20240089239 A1 to Kakaiya.
Regarding claim 1, Costa teaches a method comprising: establishing a key for a transformation of values from a partner data vault; [Costa, col. 9 lines 66 – 67 lines to col. 10 lines 1 – 9 discloses a key exchange process that produces a shared key SK; an attestation process for attestation to enclave client 510 of the enclave on trusted platform 530; and a secure computation are done. The shared key SK from the first process is used for communicating inputs and outputs of the secure computation. In the key exchange, the enclave client computes g.sup.A, stored in box 512, from the enclave client's private key A and a generator function g, for example as described below for the Diffe-Hellman key exchange (DKE) protocol] receiving requester values from a requester data vault that are not in a plain text; [Costa, col. 25 lines 18 – 27 discloses parameters included or implied in the received request may be converted in optional step 1204 if it is determined, for example, the data format of a parameter in the original request is not the same as the data format for that parameter in the native platform. For example, if a request from an enclave or client includes a parameter derived from an abstraction format attestation report, such as an enclave abstraction identity, will be converted into a parameter used in a native format attestation report, such as a native enclave identity.] performing an operation that compares the transformed values and the requester values; [Costa, col. 13 lines 25 – 32 discloses The verifier 702 can verify integrity of secure container 708 by comparing measurement 712 against an expected result (the expected result determined, for example, by locally performing the same hash of the measurement 712), and verify that the attestation signature was created for this particular verifier 702 communication path instance by inspecting data 714 (for example because the hash of data 714 is tied to the key exchange message 2 706).] compiling results of the operation as a report; [Costa, col. 10 lines 21 – 25 discloses computation results 516 can then be securely communicated back to the enclave client 510 by encrypting the results with the shared key SK (Enc.sub.SK(results)) before sending them to the enclave client in message 526.] configuring the report, not in plain text, using the requester values; [Costa, col. 29 lines discloses 20 -25 discloses the results from executing the enclave instructions or calling the enclave hypercalls are cleaned up in box 1312. Clean up may include, for example, converting the output parameters or the exception handling of the enclave processor instructions or the enclave hypercalls into the format or protocol of the abstraction layer interface.] and sending the report to the requester. [Costa, col. 29 lines 26 – 28 discloses the converted output parameters are then returned to the original requestor (enclave or client) in box 1314.], but Costa does not teach receiving transformed values from the partner data vault, the values being transformed using the key and not in plain text;
However, Kakaiya does teach receiving transformed values from the partner data vault, the values being transformed using the key and not in plain text; [Kakaiya, para. 155 discloses circuitry 1517 sends a work request to service TEE 1532. For these examples, the work request can be for accelerator 1536 to perform a transformation on encrypted data read from a storage device (e.g., included in storage array 1540). The work request, for example, can include a work descriptor and/or information included in the work request that is used by service TEE 1532 to generate a work descriptor for accelerator 1536 to use to determine what session key to use to decrypt the encrypted data read from the storage device. Para. 157 – 159 discloses circuitry 1537 at accelerator 1536 decrypts and transforms data. For these examples, similar operations are implemented as described above for read flow 1200 shown in FIG. 12 for circuitry 1537 to decrypt and then transform the data. Circuitry 1537 at accelerator 1536 provides the transformed data to circuitry 1533 of service TEE 1532. circuitry 1537 encrypts the transformed data. For these examples, similar operations are implemented as described above for read flow 1200 shown in FIG. 12 for circuitry 1533 to encrypt the transformed data and provide the encrypted data.]
Therefore, it would have obvious to one of ordinary skill within the art before the effective filling date to combine Kakaiya’s system with Costa’s system, with a motivation for integrity logic 228 generates a CRC value based on the transformed (e.g., decompressed) data and compare the generated CRC value to the CRC value that was provided by decryption logic 226 to verify that the clear text data has not been altered or corrupted from its original state. [Kakaiya, para. 122]
As per claim 2, modified Costa teaches the method of Claim 1, further comprising receiving an operation request from the requester, the operation request identifying the operation and fields of the requester data vault with which to perform the identified operation. [Costa, col. 25 lines 17 – 26 discloses an abstraction platform request may be translated into a native platform request in operations 1204-1208. Parameters included or implied in the received request may be converted in optional step 1204 if it is determined, for example, the data format of a parameter in the original request is not the same as the data format for that parameter in the native platform. For example, if a request from an enclave or client includes a parameter derived from an abstraction format attestation report, such as an enclave abstraction identity, will be converted into a parameter used in a native format attestation report, such as a native enclave identity.]
Regarding claim 3, modified Costa teaches the method of Claim 1, further comprising: generating a requester key for the transformation of values from the requester data vault; [Costa, col. 40 lines 19 – 29 discloses key vault systems with vault-locked keys and derived keys, particularly where encryption keys are derived from a vault-locked key, may be used to build a security system that is flexible and vary secure. A key derivation function, which may or may not be public, can be used to generate multiple keys from a first key. The first key (a root secret) may be vault-locked for the highest level of security, and keys derived from the first key can be used for encryption purposes. If a derived key is compromised, a new derived key can be generated in an existing system without having to access or change the key vault holding the first key.] wherein performing an operation comprises performing the operation on the transformed values and the requester transformed values; [Costa, col. 10 lines 18 – 21 discloses A secure computation may be performed inside the secure enclave container 536 using the secret code and/or data 542 to produce a computation result 544.], but Costa does not teach receiving transformed requester values from the requester data vault, the transformed requester values being transformed using the requester key.
However, Kakaiya does teach receiving transformed requester values from the requester data vault, the transformed requester values being transformed using the requester key, [Kakaiya, para. 155 discloses circuitry 1517 sends a work request to service TEE 1532. For these examples, the work request can be for accelerator 1536 to perform a transformation on encrypted data read from a storage device (e.g., included in storage array 1540). The work request, for example, can include a work descriptor and/or information included in the work request that is used by service TEE 1532 to generate a work descriptor for accelerator 1536 to use to determine what session key to use to decrypt the encrypted data read from the storage device. Para. 157 – 159 discloses circuitry 1537 at accelerator 1536 decrypts and transforms data. For these examples, similar operations are implemented as described above for read flow 1200 shown in FIG. 12 for circuitry 1537 to decrypt and then transform the data. Circuitry 1537 at accelerator 1536 provides the transformed data to circuitry 1533 of service TEE 1532. circuitry 1537 encrypts the transformed data. For these examples, similar operations are implemented as described above for read flow 1200 shown in FIG. 12 for circuitry 1533 to encrypt the transformed data and provide the encrypted data.]
Therefore, it would have obvious to one of ordinary skill within the art before the effective filling date to combine Kakaiya’s system with Costa’s system, with a motivation for integrity logic 228 generates a CRC value based on the transformed (e.g., decompressed) data and compare the generated CRC value to the CRC value that was provided by decryption logic 226 to verify that the clear text data has not been altered or corrupted from its original state. [Kakaiya, para. 122]
As per claim 4, modified Costa teaches the method of Claim 1, wherein establishing a key comprises generating a key to transform encrypted values of the partner data vault to a form suitable for performing the operation. [Costa, col. 40 lines 19 – 29 discloses key vault systems with vault-locked keys and derived keys, particularly where encryption keys are derived from a vault-locked key, may be used to build a security system that is flexible and vary secure. A key derivation function, which may or may not be public, can be used to generate multiple keys from a first key. The first key (a root secret) may be vault-locked for the highest level of security, and keys derived from the first key can be used for encryption purposes. If a derived key is compromised, a new derived key can be generated in an existing system without having to access or change the key vault holding the first key.]
Regarding claim 5, modified Costa teaches the method of Claim 4, but Costa does not teach further comprising forming a session with the partner data vault, and wherein sending the key and receiving transformed values is performed within the escrow session.
However, Kakaiya does teach further comprising forming a session with the partner data vault, and wherein sending the key and receiving transformed values is performed within the escrow session. [Kakaiya, para. 42 discloses scheme 300 is a way to establish a secure session between TEE 116 at compute server 110 with accelerator 136 at service server 130 via programming of session keys to a key table maintained at accelerator 136. For these examples, as shown in FIG. 3, logic and/or features of circuitry 117 of TEE 116 to include, but not limited to, authentication logic 210, key programming logic 212, and encryption logic 214 and logic and/or features of circuitry 137 of accelerator 136 to include, but not limited to, authentication logic 220, key logic 222, and decryption logic 226 are utilized to establish a secure session between TEE 116 and accelerator 136. The established secure session can facilitate maintaining a trusted enclave between TEE 116 and accelerator 136. Service 132 at service server 130 can also be involved in at least receiving requests from TEE 116 and forwarding information to accelerator 136 to facilitate establishing the secure session.]
Therefore, it would have obvious to one of ordinary skill within the art before the effective filling date to combine Kakaiya’s system with Costa’s system, with a motivation for integrity logic 228 generates a CRC value based on the transformed (e.g., decompressed) data and compare the generated CRC value to the CRC value that was provided by decryption logic 226 to verify that the clear text data has not been altered or corrupted from its original state. [Kakaiya, para. 122]
Regarding claim 6, modified Costa teaches the method of Claim1, but Costa does not teach wherein the transformed values are transformed by a keyed one-way transformation.
However, Kakaiya does teach further wherein the transformed values are transformed by a keyed one-way transformation. [Kakaiya, para. 103 discloses Accelerator write integrity scheme 1100 shown in FIG. 11 provides a high-level example of how logic and/or features of circuitry (e.g., circuitry 137) at an accelerator (e.g., accelerator 136) verify integrity of encrypted data upon receiving or obtaining the encrypted data and take additional steps to protect re-encrypted data following any transformation of the data and to ensure that transformation of the data is lossless via a reverse transform process.]
Therefore, it would have obvious to one of ordinary skill within the art before the effective filling date to combine Kakaiya’s system with Costa’s system, with a motivation for integrity logic 228 generates a CRC value based on the transformed (e.g., decompressed) data and compare the generated CRC value to the CRC value that was provided by decryption logic 226 to verify that the clear text data has not been altered or corrupted from its original state. [Kakaiya, para. 122]
As per claim 7, modified Costa teaches the method of Claim 1, further comprising canonicalizing the transformed values and the requester values, and wherein performing an operation comprises matching. [Costa, col. 9 lines 57 – 65 discloses the enclave identity can be verified by comparing the identity information in the attestation message with an independently known identity value. For example, if the identity information in the attestation message is a hash of the initial state of the enclave, enclave client 510 may know the hash of the initial state, or may be able to compute such hash from a known initial state, and this value can then be compared to the identity value provided in the attestation message.]
As per claim 8, modified Costa teaches the method of Claim 1, wherein performing an operation comprises performing a join operation and wherein configuring the report comprises indicating requester values that match a corresponding transformed value. [Costa, col. 33 lines 14 - 27 discloses an enclave client may securely determine that enclaves are equivalent by comparing identity values derived from attestation reports. Enclave client 1602 may securely identify each of the enclaves by receiving separate attestation reports from the first enclave 1612 and the second enclave 1622. An identity value may be included (or derived from) each of these attestation reports. If the identity values are the same, enclave client 1602 may have confidence that first enclave 1612 and second enclave 1622 are equivalent in some sense. The identity values from the attestation reports may be abstract identity values corresponding to a particular abstract identity type (such ExactHash, InstanceHash, ImageID, FamilyID, or AuthorID), or hashes of such abstract identity values.]
As per claim 10, modified Costa teaches the method of Claim 1, wherein configuring the report comprises attaching flags to identified requested values that meet the identified operation. [Costa, col. 10 lines 48 – 59 discloses the artifact, or result, of local attestation is called an attestation report, and is Sign.sub.AK(Hash(g.sup.A), M) in the example of FIG. 5. Remote attestation may occur when the enclave client 510 and the trusted platform 530 are hosted on different computers. The artifact, or result, of remote attestation is called an attestation quote, which in some cases may be very similar or identical to a local attestation report. In other cases an attestation quote may include an additional artifact of trust related to the computer or native platform providing the quote. Such an additional artifact of trust may include a host health certificate such as a TCG log associated with a TPM.]
As per claim 11, modified Costa teaches the method of Claim 10, wherein the identified requester values include values for multiple records in a single field of the requester data vault. [Costa, col. 25 lines 60 – 65 discloses the operation of sending the request to the native platform 1208 may involve multiple operations with the native platform, and may vary depending on the operation (or primitive) requested, such as creating an enclave, attestation, data sealing, control transfer, or use of monotonic counters and trusted time.]
As per claim 12, modified Costa teaches the method of Claim 10, wherein the identified values include values for a field of the requester data vault that are within an identified numerical range. [Costa, col. 11 lines 12 – 22 discloses Attestation at the InstanceHash identity level may include a subset of the initial state 538. The subset may be specified at the time the enclave binary files (the binary files) that are loaded into the secure container 536 were originally signed by the author of those enclave binary files. For example, a first (or primary) enclave binary file may include a list of identities of other enclave binary files upon which the first enclave binary file depends. For each identity listed, a flag may be included in the first binary file to indicate if each binary file listed is measured or not by the hash function to produce an InstanceHash attestation report.]
As per claim 13, modified Costa teaches the method of Claim 10, wherein the identified values include values for multiple records of the requester data vault in multiple fields [Costa, col. 25 lines 60 – 65 discloses the operation of sending the request to the native platform 1208 may involve multiple operations with the native platform, and may vary depending on the operation (or primitive) requested, such as creating an enclave, attestation, data sealing, control transfer, or use of monotonic counters and trusted time.] and wherein performing an operation includes performing combinations of values in different fields. [Costa, col. 10 lines 18 – 21 discloses A secure computation may be performed inside the secure enclave container 536 using the secret code and/or data 542 to produce a computation result 544.]
Regarding claim 14, it recites features similar to features within claim 1, therefore it is rejected in a similar manner.
Regarding claim 15, it recites features similar to features within claim 10, therefore it is rejected in a similar manner.
Regarding claim 16, it recites features similar to features within claim 11, therefore it is rejected in a similar manner.
Regarding claim 17, it recites features similar to features within claim 1, therefore it is rejected in a similar manner.
Regarding claim 18, it recites features similar to features within claim 4, therefore it is rejected in a similar manner.
Regarding claim 20, it recites features similar to features within claim 7, therefore it is rejected in a similar manner.
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over US 11438155 B2 to Costa in view of US 20240089239 A1 to Kakaiya in further view of US 20240187381 A1 to Golikov et al., (hereinafter, “Golikov”).
Regarding claim 9, modified Costa teaches the method of Claim 1, but modified Costa does not teach wherein the transformed values are encrypted and wherein performing the operation comprises performing the operation without decrypting the transformed values.
However, Golikov does teach wherein the transformed values are encrypted and wherein performing the operation comprises performing the operation without decrypting the transformed values. [Golikov, para. 82 discloses Because the segments are encrypted, the compression is performed using the public evaluation key, which allows the encrypted segments to be compressed without the need for any decryption.]
Therefore, it would have obvious to one of ordinary skill within the art before the effective filling date to combine Golikov’s system with Costa’s system, with a motivation for the set of WAN optimization operations, in some embodiments, include at least a TRE first operation for identifying redundant segments in the encrypted data stream and replacing the redundant segments with segment identifiers corresponding to the redundant segments, and a compression second operation for compressing the encrypted data stream and producing the WAN-optimized encrypted data stream. The method then forwards the WAN-optimized encrypted data stream to the receiver. [Golikov, para. 87]
Regarding claim 19, it recites features similar to features within claim 9, therefore it is rejected in a similar manner.
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 Phuc Pham whose telephone number is (571)272-8893. The examiner can normally be reached Monday - Thursday 7:30 AM - 4:30 PM; Friday 8:00 AM - 12: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, Linglan Edwards can be reached at (571) 270-5440. 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.
/P.P./Patent Examiner, Art Unit 2408
/CHAU LE/Primary Examiner, Art Unit 2408
Prosecution Insights