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 05/08/2025 and 12/10/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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, 4, 16 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over HEINLEIN, US-20250260557-A1 (hereinafter “HEINLEIN ‘557”) in view of Costa, US-20180211054-A1 (hereinafter “Costa ‘054”) and ZHANG et al., US-20240380611-A1 (hereinafter “ZHANG ‘611”).
Per claim 1 (independent):
HEINLEIN ‘557 discloses: A method, comprising:
providing, by a server system, a resource accessible to a plurality of client devices using end-to-end encryption;
receiving, by the server system, a request from one of the client devices to access the resource
(FIG. 1, [0040], a user 10 is using a client device 20 (one of the client devices) that communicates with a server 30 (a server system); [0042], The above aspect of the present invention allows a user to use E2EE on multiple client devices (a plurality of client devices using end-to-end encryption) while ensuring that the server (or any other potential eavesdropper) is unable to access the stored encrypted data, that is, one of the client devices can access the resource of the server system; [0005], The present invention provides systems and methods relating to end to end encryption (using end-to-end encryption). Encrypted data (a resource) stored on a server or transmitted by way of a server (providing, by the server system, the resource; receiving, by the server system, a request to access the resource) can be accessed (accessible to a plurality of client devices) from any number of authenticated client devices (i.e., the plurality of client devices) by storing an encrypted private key on the server).
HEINLEIN ‘557 does not disclose but Costa ‘054 discloses: providing, by the server system, a signed attestation that includes a public key of the server system, wherein the attestation attests to the public key and to a set of system properties of the server system that are immutable while the resource is accessible (FIG. 5, [0049], an enclave client 510 (the attestation verifier) may wish to use the secure computation services of enclave on the trusted platform 530 (the server system); [0051], To attest the identity of the enclave (to provide assurance about what code running inside the secure enclave container 536) – providing, by the server system, a signed attestation, an attestation message 522 (the signed attestation) is sent to the enclave client 510 ... the secure enclave container's 536 initial state 538 (a set of system properties of the server system that are immutable – the previously referenced “provide assurance” may be understood as assurance that the initial state remains immutable) of public code and public data are used as an enclave identity, though other identities are possible. Instead of sending the entire initial state 538 in an attestation message, a hash of the initial state, M=Hash (Initial State) – the set of system properties, is sent instead. The attestation message 522 includes the message contents (M and
g
B
), and a signature of the message contents (
S
i
g
n
A
K
(Hash (
g
B
), M)) – the (signed) attestation including a digital signature over both
g
B
and M. Furthermore, it is well known in the art that, in the Diffie-Hellman Key Exchange (DKE) protocol,
g
B
corresponds to the public key exchanged with the remote party; [0052], Computation results 516 (while the resource is accessible) can then be securely communicated back to the enclave client 510 by encrypting the results).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified HEINLEIN ‘557 with the communication of computation results to the enclave client after software attestation of the enclave on the trusted platform through the DKE protocol through verification of an attestation message as taught by Costa ‘054 because the enclave client is assured that the results (i.e., resources) originate from the attested enclave rather than from untrusted software running not based on the initial state of the enclave. Additionally, Costa ‘054 is analogous to the claimed invention because it teaches software attestation of an enclave [0049].
HEINLEIN ‘557 in view of Costa ‘054 does not disclose but ZHANG ‘611 discloses: wherein the request is encrypted using the attested-to public key of the server system (FIG. 3, [0049], 130. The second device (the server system) receives a data access request transmitted by the first device if both the first terminal identity and a second terminal identity are registered identities, the data access request being encrypted (the request is encrypted) by the first device by using a second public key (using the attested-to public key) ... the second public key (generated by the second device – see [0047]) being obtained by the first device based on the second certificate, which has been transmitted by the second device – see [0043] – [0044], that is, the attested-to public key of the server system).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified HEINLEIN ‘557 in view of Costa ‘054 with the data transmission by verifying certificates to authenticate communication devices and encrypting data access request and using public-key cryptography as taught by ZHANG ‘611 because confidential data is protected from unauthorized access while improving the privacy and reliability of communications [0047]-[0055]. Additionally, ZHANG ‘611 is analogous to the claimed invention because it teaches the second device receives a data access request transmitted by the first device [0049].
Per claim 4 (dependent on claim 1):
HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
HEINLEIN ‘557 in view of ZHANG ‘611 does not disclose but Costa ‘054 discloses: The method of claim 1, wherein the set of immutable system properties identify an enforced set of applications authorized to execute while the resource is accessible (FIG. 5, [0051], To attest the identity of the enclave (to provide assurance about what code running inside the secure enclave container 536 – identify an enforced set of applications authorized to execute while the resource is accessible), an attestation message 522 is sent to the enclave client 510 ... the secure enclave container's 536 initial state 538 of public code and public data (the set of immutable system properties) are used as an enclave identity, though other identities are possible. Instead of sending the entire initial state 538 in an attestation message, a hash of the initial state, M=Hash (Initial State), is sent instead. The attestation message 522 includes the message contents (M and
g
B
), and a signature of the message contents (
S
i
g
n
A
K
(Hash (
g
B
), M)); [0052], Computation results 516 (while the resource is accessible) can then be securely communicated back to the enclave client 510 by encrypting the results).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified HEINLEIN ‘557 in view of ZHANG ‘611 with the communication of computation results to the enclave client after software attestation of the enclave on the trusted platform through the DKE protocol through verification of an attestation message as taught by Costa ‘054 because the enclave client is assured that the results (i.e., resources) originate from the attested enclave rather than from untrusted software running not based on the initial state of the enclave.
Per claim 16 (independent):
The limitations of the claim(s) correspond(s) to features of claim 1 and the claim(s) is/are rejected for the reasons detailed with respect to claim 1.
Per claim 20 (independent):
The limitations of the claim(s) correspond(s) to features of claim 1 and the claim(s) is/are rejected for the reasons detailed with respect to claim 1.
Claim(s) 2 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 as applied to claims 1 and 16 above, and further in view of Wang et al., US-20260089002-A1 (hereinafter “Wang ‘002”).
Per claim 2 (dependent on claim 1):
HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
HEINLEIN ‘557 in view of ZHANG ‘611 does not disclose but Costa ‘054 discloses: The method of claim 1, further comprising:
publishing, by the server system, information about the immutable system properties
(FIG. 5, [0049], an enclave client 510 (the attestation verifier) may wish to use the secure computation services of enclave on the trusted platform 530 (the server system); [0051], To attest the identity of the enclave (to provide assurance about what code running inside the secure enclave container 536), an attestation message 522 is sent to the enclave client 510 ... the secure enclave container's 536 initial state 538 of public code and public data (information about the immutable system properties) are used as an enclave identity, though other identities are possible. Instead of sending the entire initial state 538 in an attestation message, a hash of the initial state, M=Hash (Initial State), is sent instead – publishing, by the server system, the information. The attestation message 522 includes the message contents (M and
g
B
), and a signature of the message contents (
S
i
g
n
A
K
(Hash (
g
B
), M))).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified HEINLEIN ‘557 with the communication of computation results to the enclave client after software attestation of the enclave on the trusted platform through the DKE protocol through verification of an attestation message as taught by Costa ‘054 because the enclave client is assured that the results (i.e., resources) originate from the attested enclave rather than from untrusted software running not based on the initial state of the enclave.
HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 does not disclose but Wang ‘002 discloses: publishing information about the immutable system properties to a transparency log stored in a transparency server accessible to the client device when verifying the signed attestation (FIG. 3, [0191], a typical TPM-based remote attestation process; [0196], Step 4: The TPM in the computing platform sends the remote attestation report (which may carry the remote attestation evidence, the AIK, and a signature) to the client on the computing platform (publishing information about the immutable system properties to a transparency log – see [0166] - [0167]); [0197], It should be understood that the remote attestation evidence is information (for example, a measurement log and/or a PCR value – the transparency log) measured by the TPM on the computing platform, the signature is used to verify the remote attestation evidence; [0201], Step 7: The verifier (a transparency server storing the transparency log) verifies the remote attestation report, the AIK, and the signature (when verifying the signed attestation), and obtains a remote attestation verification result; [0202], Step 8: The verifier sends the remote attestation verification result to the relying party – accessible to the client device).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 with the verifier validating remotely the attestation evidence for determining whether the computing platform is in a trusted state before it is relied upon or granted access as taught by Wang ‘002 because the system can detect compromised software components and allow only verified platforms to access protected services or resources. Additionally, Wang ‘002 is analogous to the claimed invention because it teaches a typical TPM-based remote attestation process [0191].
Per claim 17 (dependent on claim 16):
HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 discloses the elements detailed in the rejection of claim 16 above, incorporated herein by reference.
The limitations of the claim(s) correspond(s) to features of claim 2 and the claim(s) is/are rejected for the reasons detailed with respect to claim 2.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 and DEWAN, US-20250342255-A1 (hereinafter “DEWAN ‘255”).
Per claim 6 (dependent on claim 1):
HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
HEINLEIN ‘557 in view of ZHANG ‘611 does not disclose but Costa ‘054 discloses: The method of claim 1, wherein the set of immutable system properties includes an enforced set of applications included in the server system and used to provide the resource (FIG. 5, [0051], To attest the identity of the enclave (to provide assurance about what code running inside the secure enclave container 536 – an enforced set of applications included in the server system), an attestation message 522 is sent to the enclave client 510 ... the secure enclave container's 536 initial state 538 of public code and public data (the set of immutable system properties) are used as an enclave identity, though other identities are possible. Instead of sending the entire initial state 538 in an attestation message, a hash of the initial state, M=Hash (Initial State), is sent instead. The attestation message 522 includes the message contents (M and
g
B
), and a signature of the message contents (
S
i
g
n
A
K
(Hash (
g
B
), M)); [0052], Computation results 516 (the resource to be provided) can then be securely communicated back to the enclave client 510 by encrypting the results).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified HEINLEIN ‘557 in view of ZHANG ‘611 with the communication of computation results to the enclave client after software attestation of the enclave on the trusted platform through the DKE protocol through verification of an attestation message as taught by Costa ‘054 because the enclave client is assured that the results (i.e., resources) originate from the attested enclave rather than from untrusted software running not based on the initial state of the enclave.
HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 does not disclose but DEWAN ‘255 discloses: The method of claim 1, wherein the set of immutable system properties includes an indication of particular hardware included in the computing system and used to provide the resource ( FIG. 3, [0056], Upon confirmation of the firmware validity (based on the attestation report 311), attestation service 350 may transmit access request 353 to resource 370 for a hardware component (particular hardware included in the computing device, i.e., the platform 210 of FIG. 2) to access resource 370 (used to provide the resource); FIG. 6, [0068], for connecting with an endpoint to validate device firmware. At operation 602, the attestation service (e.g., attestation service 350 of FIG. 3) may validate the attestation report (e.g., attestation report 311 of FIG. 3; the set of immutable system properties including an indication of particular hardware) received from a hardware component (e.g., hardware components 212 of FIG. 2) directly or via a root of trust (e.g., ROT 214 of FIG. 4) of a computing device (e.g., platform 210 of FIG. 2; the computing device) hosting the hardware component).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 with the attestation service validating a hardware component’s firmware attestation and automatically identifying the appropriate vendor endpoint as taught by DEWAN ‘255 because this reduces manual configuration while ensuring that firmware information is retrieved only from the appropriate trusted service. Additionally, DEWAN ‘255is analogous to the claimed invention because it teaches the interaction between components of an example attestation system [0043].
Claim(s) 13-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 and Karame et al., US-20210112038-A1 (hereinafter “Karame ‘038”).
Per claim 13 (dependent on claim 1):
HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 does not disclose but Karame ‘038 discloses: The method of claim 1, wherein the resource includes a machine learning model hosted by the server system (FIGS. 1 and 2, [0041], depict a Machine Learning as a Service (MLaaS) system 100 (also called a "system") (a machine learning model) where a host 110 (also called a "service provider" or a "host processing system") (the server system hosting the ML model) includes a computing infrastructure for clients 120 ( also called "data providers" or "client processing systems") to perform machine learning operations ... Therefore, clients 120 (accessing the resource, that is, the ML model) rely on host 110 to perform processor-intensive machine-learning model training and/or applying a trained machine-learning model to obtain predictions (e.g., classifications); [0046], the present invention improves over existing MLaaS techniques by offering a host configured to take advantage of both a trusted hardware component (e.g., TEE 114) for attestation (e.g., attestation, via TEE 114 of the machine learning model that host 110 applies) and computational acceleration through GPU (e.g., intermediate processing system 112)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 with the MLaaS system allowing clients to apply a trained ML model to obtain prediction in a host by taking advantage of both a TEE for attestation and computational acceleration through GPU as taught by Karame ‘038 because the system overcomes hardware limitations by boosting processing efficiency while strictly safeguarding client data privacy and proprietary model parameters. Additionally, Karame ‘038 is analogous to the claimed invention because it teaches a Machine Learning as a Service (MLaaS) system 100 [0041].
Per claim 14 (dependent on claim 1):
HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 does not disclose but Karame ‘038 discloses: The method of claim 1, wherein the resource includes accelerator hardware configured to perform one or more tasks identified in the request (FIGS. 1 and 2, [0041], depict a Machine Learning as a Service (MLaaS) system 100 (also called a "system") where a host 110 (also called a "service provider" or a "host processing system") includes a computing infrastructure for clients 120 ( also called "data providers" or "client processing systems") to perform machine learning operations ... Therefore, clients 120 (accessing the resource, that is, the ML model) rely on host 110 to perform processor-intensive machine-learning model training and/or applying a trained machine-learning model to obtain predictions (e.g., classifications) – tasks identified in the request; [0046], the present invention improves over existing MLaaS techniques by offering a host configured to take advantage of both a trusted hardware component (e.g., TEE 114) for attestation (e.g., attestation, via TEE 114 of the machine learning model that host 110 applies) and computational acceleration through GPU (e.g., intermediate processing system 112; accelerator hardware configured to perform one or more tasks identified in the request)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 with the MLaaS system allowing clients to apply a trained ML model to obtain prediction in a host by taking advantage of both a TEE for attestation and computational acceleration through GPU as taught by Karame ‘038 because the system overcomes hardware limitations by boosting processing efficiency while strictly safeguarding client data privacy and proprietary model parameters.
Per claim 15 (dependent on claim 1):
HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 does not disclose but Karame ‘038 discloses: The method of claim 1, wherein the resource includes an application hosted by the server system (FIGS. 1 and 2, [0041], depict a Machine Learning as a Service (MLaaS) system 100 (also called a "system") where a host 110 (also called a "service provider" or a "host processing system"; the server system) includes a computing infrastructure for clients 120 ( also called "data providers" or "client processing systems") to perform machine learning operations ... Therefore, clients 120 (accessing the resource, that is, the ML model) rely on host 110 to perform processor-intensive machine-learning model training and/or applying a trained machine-learning model to obtain predictions (e.g., classifications); [0060], client 120 can verify that (i) host 110 performs the modeling (e.g., classification) on trusted hardware and (ii) the corresponding trusted application (e.g., compiler 310 instantiated through enclave 320) (an application hosted by the server system) realizes any advertised classification functionality without leaking any source-identifying data from TEE 114 to intermediate processing system 112).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 with the MLaaS system allowing clients to apply a trained ML model to obtain prediction in a host through trusted applications by taking advantage of both a TEE for attestation and computational acceleration through GPU as taught by Karame ‘038 because the system overcomes hardware limitations by boosting processing efficiency while strictly safeguarding client data privacy and proprietary model parameters.
Allowable Subject Matter
Claim(s) 3, 5, 7-12 and 18-19 is/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.
The following is a statement of reasons for the indication of allowable subject matter:
Regarding claims 3, 5, 7, 9-10 and 18-19, the prior art of record (HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611) does not disclose:
Claim 3: Although Costa ‘054 may be considered to teach the claimed publish information, it merely recites public code and public data, without specifically disclosing that the publish information includes “identifiers of components and an operating system” on the server system.
Claim 5 (and 18): Costa ‘054 discloses that the enclave of the trusted platform sends an attestation message containing signed information. However, Costa ‘054 does not disclose that the signed information includes “digests generated from hashing program instructions of the authorized applications.”
Claim 7: The combination of HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 may identify authorized application of the server system; however, the combination fails to teach or suggest the claimed concept of a “restricted execution mode.”
Claim 9: The combination of HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 is silent as to “accessing one or more manifests identifying a set of signatures generated from signing applications and a set of criteria in which the applications are authorized to execute;
confirm verification of the signatures; and
enforcing the criteria for the applications.”
Claim 10 (and 19): The combination of HEINLEIN ‘557 in view of Costa ‘054 and ZHANG ‘611 is silent as to “receiving, by a secure circuit of the server system, information from an enforcement agent enforcing the set of immutable system properties; and
signing, by the secure circuit, an attestation based on the information indicating that set of immutable system properties are being enforced by the enforcement agent.”
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
LAM et al., US-20240267364-A1 – a communication device selectively encrypts only sensitive portion of a payload while leaving other portions in plaintext, and generates integrity protection over the encrypted and unencrypted portions. This improves protocol interoperability and enables intermediate network processing without sacrificing end-to-end integrity.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANGSEOK PARK whose telephone number is (571)272-4332. The examiner can normally be reached Monday-Friday 7:30-5:30 and Alternate Fridays 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, PHILIP CHEA can be reached at (571)272-3951. 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.
/SANGSEOK PARK/Primary Examiner, Art Unit 2499
Prosecution Insights