DETAILED ACTION
A Request for Continued Examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous office action has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission filed on January 28, 2026 has been entered.
Claims 1-9 and 11-21 are currently pending and directed toward a FUNCTION-BASED SERVICE FRAMEWORK BASED ON TRUSTED EXECUTION ENVIRONMENT.
Any claim objection/rejection not repeated below is withdrawn due to Applicant's amendment.
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 . 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 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.
Response to Arguments
Applicant’s arguments with regards to claims 1-9 and 11-21 have been fully considered, but they are not persuasive. Additionally, Examiner responds to Applicant’s remarks:
“how can” argument – Applicant argues that how Alder can disclose "receiving, via the first secure communication channel, the function from the at least one function providing party such that the at least one function is private relative to the one or more data providing parties" when page 7 of Alder clearly states that the client ensures that the intended function is the function that process its input data by including a hash of the intended function as part of its encrypted input (REMARKS, pages 9-10).
Response: a hash of the intended function as part of its encrypted input, as not the same as the function itself. Compare “To achieve this, the client includes a hash of the intended function h(F) as part of her encrypted input. Upon receiving this, the worker enclave checks that this matches the hash of the function it has loaded, and if not, aborts the invocation before passing the decrypted inputs to the function.” and “It then decrypts the inputs and checks if the function hash h(F) supplied by the client matches the hash of the loaded function. If the hashes match, the function is invoked on the decrypted inputs.” (Alder, page 7). It should be also noted that Applicant did not respond to teachings of Felsen, page 166, as was provided by Examiner.
“nowhere” argument – Applicant argues that the Office Action at page 11 cites Alder at page 2 for allegedly disclosing these limitations, however, other than mentioning the terms "web developer" and "authorized users' web browsers," nowhere does Alder or Felsen that the configuration information identifies respective locations from where the at least one function providing party and the one or more data providing parties will attest the enclave, as now recited in independent claim 1. (REMARKS, pages 9-10).
Response: Alder explicitly teaches a location from which the enclave could be attested and a function can be directly invoked, which are the authorized users' web browsers.
Conclusion: Examiner maintains rejections.
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 of this title, 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-9 and 11-21 are rejected under 35 U.S.C. 103 as being unpatentable over Alder et al. (S-FaaS: Trustworthy and Accountable Function-as-a-Service using Intel SGX, arXiv:1810.06080v1 14 Oct 2018, 16 pages) in view of Felsen et al (Secure and Private Function Evaluation with Intel SGX, CCSW ’19, November 11, 2019, 17 pages), hereinafter referred to as Alder and Felsen respectively.
As per claim 1, Alder teaches a method, comprising: reading configuration information identifying one or more data providing party and at least one function providing parties (We distinguish between the entity that provisions the function, i.e. the function provider, and the entity that invokes the function, i.e. the client. The client supplies the inputs on which the function is run, and receives the corresponding output. Alder, page 2);
generating, based at least in part on the configuration information, an enclave comprising one or more attestation components corresponding to each of the one or more data providing parties, one or more input data components corresponding to each the one or more data providing parties, at least one function attestation component corresponding to the at least one function providing party, at least one function input component corresponding to the at least one function providing party, and a secure component comprising at least a circuit configured to execute a function (we present S-FaaS, an approach for providing security and accountability in FaaS using Intel Software Guard Extensions (SGX). SGX is a modern Trusted Execution Environment (TEE) providing hardware-based isolation and protection for code and data inside an enclave. Our S-FaaS architecture encapsulates individual functions inside SGX enclaves, and uses remote attestation to provide various guarantees to relying parties. Specifically, SFaaS enhances security by protecting the integrity and authenticity of the function inputs and outputs, and provides strong assurance to the client that the outputs are the result of a correct execution of the function with the given inputs. Alder, pages 1-2);
establishing a first secure communication channel between the at least one function providing party and the at least one function input component in response to an affirmative attestation at the at least one function attestation component of the enclave (The function provider is assumed to have a business relationship with the service provider, including a means to authenticate itself (e.g. username and password, or public key). The service provider uses this mechanism to control who may provision functions. These intermediate steps are not shown in Figure 3, but the overall result is that a function F, provided by the function provider, is eventually provisioned to a worker enclave. Alder, page 6);
establishing one or more second secure communication channels between each of the one or more data input components and the corresponding data providing parties in response to an affirmative attestation at the respective one or more data attestation components of the enclave (Once a client has obtained the published set of public keys from the KDE (Section V-A), and verified the KDE’s attestation (Section V-B), she runs the key agreement protocol to generate a symmetric session key K under which to encrypt her inputs using an authenticated encryption algorithm (e.g. AES-GCM). Note that this key exchange only achieves unilateral authentication of the enclave towards the client, since the enclave’s public key is authenticated via the transitive attestation. We assume that any client authentication, if required, is included in the inputs supplied by the client (e.g. an API key or authentication token). In addition to encrypting the inputs for the worker enclave, the client also wants to ensure that only the intended function may process her inputs. Alder, page 7);
receiving, via the first secure communication channel the function from the at least one function providing party (Unlike typical systems using remote attestation, this check is necessary in our case because the function is dynamically provisioned to the worker enclave after the worker enclave has been attested by the KDE. To achieve this, the client includes a hash of the intended function h(F) as part of her encrypted input. Upon receiving this, the worker enclave checks that this matches the hash of the function it has loaded, and if not, aborts the invocation before passing the decrypted inputs to the function. Alder, page 7).
Alder in view of Felsen further teaches such that the at least one function is private relative to the one or more data providing parties (Sometimes not only the inputs of a function but also the function itself should be kept secret, e.g., when executing proprietary software on private data. For these cases, private function evaluation (PFE) allows two mutually distrusting parties to jointly evaluate a private function provided by one of the parties on private data provided by the other party while ensuring that neither of them learns anything about the other party’s input…In the PFE setting, one party provides the private input and the other party provides the private function in form of programming bits to the universal circuit, while the UC itself is the publicly known function in the SFE setting. Felsen, page 166);
Alder in view of Felsen are analogous art to the claimed invention, because they are from a similar field of endeavor of systems, components and methodologies for providing secure communication between computer systems. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Alder in view of Felsen. This would have been desirable because we are the first to also address efficient private function evaluation (PFE) via TEEs, where one of the parties provides a function that represents intellectual property and is computed obliviously on the other party’s input. For realizing PFE, we securely evaluate universal circuits (UCs) that can be programmed via input bits to emulate any function up to a given size (Felsen, page 165).
receiving, via the one or more second secure communication channels data from the one or more data providing parties (Once a client has obtained the published set of public keys from the KDE (Section V-A), and verified the KDE’s attestation (Section V-B), she runs the key agreement protocol to generate a symmetric session key K under which to encrypt her inputs using an authenticated encryption algorithm (e.g. AES-GCM). Alder, page 7);
sending the function and the data to the circuit of the secure component of the enclave via the first secure communication channel and the second secure communication channels, respectively, wherein the circuit executes the function to compute at least one output based at least in part on the data (run: When a function invocation is requested, this ECALL is called with the encrypted inputs as parameters. The enclave first calculates the shared session key K using its own key agreement key kka, and the client’s public key kc+. It then decrypts the inputs and checks if the function hash h(F) supplied by the client matches the hash of the loaded function. If the hashes match, the function is invoked on the decrypted inputs. If the function produces an output, this ECALL returns the size of the output, allowing the host application to allocate the correct size buffers outside the enclave. Alder, page 7); and
sending the at least one output to the one or more data providing parties via at least one output component of the enclave (finish: Finally, this ECALL copies the encrypted output and signed resource measurements out of the enclave. These will be sent to the client and function provider respectively. Alder, page 7);
wherein the configuration information identifies respective locations from where the at least one function providing party and the one or more data providing parties will attest the enclave (For example, to deal with highly variable demand, a web developer could provision a function that can be directly invoked from authorized users’ web browsers (possibly via an API gateway like that provided by AWS), Alder, page 2);
and
wherein the method is performed by at least one processor coupled to at least one memory (SGX resource measurement: We present a set of mechanisms for accurately measuring the compute time, memory, and network usage of a function executing inside an SGX enclave, in a manner that can be trusted by both the service provider and function provider. Alder, page 2).
As per claim 2, Alder in view of Felsen further teaches the method of claim 1, wherein the circuit comprises a universal circuit (Even without our architecture, a FaaS service provider would always run functions in some type of sandbox in order to isolate different functions from one another and protect the underlying infrastructure from potentially malicious functions. Alder, page 4).
As per claim 3, Alder in view of Felsen further teaches the method of claim 1, further comprising:
receiving one or more keys from the at least one function providing party (To solve this, our architecture includes a new key distribution enclave (KDE) to securely generate and distribute the necessary keys to the dynamically created worker enclaves. Alder, page 4); and
using the one or more keys in connection with establishing at least the first secure communication channel between the at least one function providing party and the one or more data input component of the enclave (The KDE also distributes the corresponding public keys to the function provider and clients. A client can thus use the public key agreement key kka+ in conjunction with her own key agreement key kc to generate a symmetric session key K. Alder, page 5);
wherein the one or more keys are invisible to the one or more data providing parties (The function provider is assumed to have a business relationship with the service provider, including a means to authenticate itself (e.g. username and password, or public key). The service provider uses this mechanism to control who may provision functions. Alder, page 6).
As per claim 4, Alder in view of Felsen further teaches the method of claim 1, further comprising: receiving one or more keys from the one or more data providing parties (The worker enclave interacts with the relying parties using the key set it received, thus establishing a transitive trust relationship between the relying parties and worker enclave. Alder, page 6); and
using the one or more keys in connection with establishing at least one or more the second secure communication channels between the one or more data providing parties and the at least one output component of the enclave (To achieve this, the client includes a hash of the intended function h(F) as part of her encrypted input. Upon receiving this, the worker enclave checks that this matches the hash of the function it has loaded, and if not, aborts the invocation before passing the decrypted inputs to the function. Alder, page 7);
wherein the one or more keys are invisible to the at least one function providing party (A key agreement key kka, which is used to authenticate the worker enclave to clients and establish a shared session key K with each client. Alder, page 5).
As per claim 5, Alder in view of Felsen further teaches the method of claim 1, further comprising sending the one or more output over the one or more second secure communication channels to the one or more data providing parties (Once the function completes, the worker enclave returns the outputs and the nonce to the client via the encrypted channel, and includes the signed resource measurement and receipt, if requested. Alder, page 7).
As per claim 6, Alder in view of Felsen further teaches the method of claim 5, further comprising encrypting the at least one output prior to sending the at least one output to the one or more data providing parties (finish: Finally, this ECALL copies the encrypted output and signed resource measurements out of the enclave. These will be sent to the client and function provider respectively. Alder, page 7).
As per claim 7, Alder in view of Felsen further teaches the method of claim 1, further comprising decrypting the data from the one or more data providing parties prior to sending the data to the circuit (Upon receiving this, the worker enclave checks that this matches the hash of the function it has loaded, and if not, aborts the invocation before passing the decrypted inputs to the function. Alder, page 7).
As per claim 8, Alder in view of Felsen further teaches the method of claim 1, further comprising decrypting the function from the at least one function providing party prior to sending the function to the circuit (SGX provides sealed storage by allowing each enclave to encrypt (i.e. seal) persistent data so that it can be stored outside the enclave. Data can be sealed either against MRENCLAVE, such that it can only be unsealed by precisely the same enclave running on the same physical platform. Alternatively, data can be sealed against MRSIGNER, such that it can be unsealed on the same platform by any enclave signed by the same developer key. Alder, page 3).
As per claim 9, Alder in view of Felsen further teaches the method of claim 1, wherein the first secure communication channel and the one or more second secure communication channels are established in response to the at least one function providing party and the one or more data providing parties remotely attesting the enclave (Our S-FaaS architecture encapsulates individual functions inside SGX enclaves, and uses remote attestation to provide various guarantees to relying parties. Specifically, SFaaS enhances security by protecting the integrity and authenticity of the function inputs and outputs, and provides strong assurance to the client that the outputs are the result of a correct execution of the function with the given inputs. S-FaaS provides accountability by producing a verifiable measurement of the fine-grained resource usage of each function invocation. Crucially, this measurement can be verified by both the service provider and the function provider, even though the latter does not control the software stack. Alder, page 2).
As per claim 11, Alder in view of Felsen further teaches the method of claim 1, wherein the configuration information identifies a computing environment in which the circuit will operate (SGX is a modern Trusted Execution Environment (TEE) providing hardware-based isolation and protection for code and data inside an enclave. Our S-FaaS architecture encapsulates individual functions inside SGX enclaves, and uses remote attestation to provide various guarantees to relying parties. Alder, page 2).
As per claim 12, Alder in view of Felsen further teaches the method of claim 1, further comprising: generating the one or more data input components in the enclave to receive the data from the one or more data providing parties based on the configuration information identifying the one or more data providing parties (2. Invoke, Fig. 1. Main entities and interactions in FaaS, Alder, page 2); and
generating the at least one output component in the enclave to send the at least one output over the one or more second secure communication channels to the one or more data providing parties based on the configuration information identifying the one or more data providing parties as a recipient of the at least one output (3. Results, Fig. 1. Main entities and interactions in FaaS, Alder, page 2).
As per claim 13, Alder in view of Felsen further teaches the method of claim 12, further comprising generating the at least one function input component in the enclave to receive the function from the at least one function providing party based on the configuration information identifying the at least one function providing party (1. Deploy, Fig. 1. Main entities and interactions in FaaS, Alder, page 2).
As per claim 14, Alder in view of Felsen further teaches the method of claim 13, further comprising restricting the circuit from performing input-output operations, wherein the one or more data input components, the at least one function input component and the at least one output component perform the input-output operations (To achieve this, the client includes a hash of the intended function h(F) as part of her encrypted input. Upon receiving this, the worker enclave checks that this matches the hash of the function it has loaded, and if not, aborts the invocation before passing the decrypted inputs to the function. See also Once the function completes, the worker enclave returns the outputs and the nonce to the client via the encrypted channel, and includes the signed resource measurement and receipt, if requested. If the function terminates abnormally, the worker enclave sends an error message to the client in lieu of the output. Alder, page 7).
As per claim 15, Alder in view of Felsen further teaches the method of claim 1, at least one attestation component corresponding to the one or more data providing parties and the at least one function attestation component corresponding to the at least one function providing party process remote attestations of the enclave from the one or more data providing parties and the at least one function providing party (We solve this by developing a new type of transitive attestation scheme (Section V-B). Alder, page 4).
Apparatus and product claims 16-21 are drawn to the apparatus and product corresponding to the method of using same as claimed in claims 1-9 and 11-15. Therefore apparatus claims 16-18 and product claims 19-21 correspond to method claims 1-9 and 11-15, have limitations similar to those treated in the above rejection, and are met by the references as discussed above, and are rejected for the same reasons of anticipation as used above.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-9 and 11-21 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 respectively of copending Application No. 17/829,485 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claims 1-9 and 11-21 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-20 of US patent No. 12,056,232 by Liu et al. in view of Felsen et al (Secure and Private Function Evaluation with Intel SGX, CCSW ’19, November 11, 2019, 17 pages). Although the conflicting claims are not identical, they are not patentably distinct from each other because all elements of claims 1-9 and 11-21 of the instant application correspond to elements of claims 1-20 of US patent No. 12,056,232. The above claims of the present application would have been obvious over claims 1-20 of US patent No. 12,056,232 because each element of the claims of the present application is anticipated by the claims of the US patent No. 12,056,232 and as such are unpatentable for obviousness-type double patenting (In re Goodman (CAFC) 29 USPQ2D 2010 (12/3/1993)). Please consider the following mapping:
claim 1, A method, comprising:
reading configuration information identifying one or more data providing party and at least one function providing partis (wherein the attested delegator provisions a body and an input of the function to the given container via the secure connection. Liu, claim 5);
generating, based at least in part on the configuration information, an enclave comprising one or more attestation components corresponding to each of the one or more data providing parties, one or more input data components corresponding to each the one or more data providing parties (second set of one or more functions for execution within a non-secure execution area of the function based service framework, Liu, claim 1), at least one function attestation component corresponding to the at least one function providing party, at least one function input component corresponding to the at least one function providing party (a first set of one or more functions for execution within a secure execution area of the function-based service framework, Liu, claim 1), and a secure component comprising at least a circuit configured to execute a function (the secure execution area comprises a hardware-based trusted execution platform. Liu, claim 9);
establishing a first secure communication channel between the at least one function providing party and the at least one function input component in response to an affirmative attestation at the at least one function attestation component of the enclave (submit a function execution request and a flag to an attested delegator to execute a function from the first set of one or more function in the secure execution area, wherein the attested delegator is a secure enclave dedicated to a client and the flag indicates that the function is a secure function, Liu, claim 10, and The system of claim 12, wherein a secure connection is established between the attested delegator and the given secure container. Liu, claim 13);
establishing one or more second secure communication channels between each of the one or more data input components and the corresponding data providing parties in response to an affirmative attestation at the respective one or more data attestation components of the enclave (14. The system of claim 13, wherein the attested delegator provisions a body and an input of the function to the given container via the secure connection. 15. The system of claim 14, wherein the given container executes the function. Liu, claims 14-15);
receiving, via the first secure communication channel the function from the at least one function providing party (submitting a function execution request and a flag to an attested delegator to execute a function from the first set of one or more functions in the secure execution area, wherein the attested delegator is a secure enclave dedicated to a client and the flag indicates that the function is a secure function; Liu, claim 1);
receiving, via the one or more second secure communication channels data from the one or more data providing parties (wherein the attested delegator provisions a body and an input of the function to the given container via the secure connection. Liu, claim 5);
sending the function and the data to the circuit of the secure component of the enclave via the first secure communication channel and the second secure communication channels, respectively, wherein the circuit executes the function to compute at least one output based at least in part on the data (instantiates one or more secure containers in the secure execution area; schedules secure execution of the function by the one or more secure containers, Liu, claim 1); and
sending the at least one output to the one or more data providing parties via at least one output component of the enclave (receiving, from the attested delegator, a result of an execution of the function. Liu, claim 1);
wherein the method is performed by at least one processor coupled to at least one memory (the function-based service framework comprising at least one processor and at least one memory, Liu, Claim 1).
Further Liu in view of Felsen teaches such that the at least one function is private relative to the one or more data providing parties (Sometimes not only the inputs of a function but also the function itself should be kept secret, e.g., when executing proprietary software on private data. For these cases, private function evaluation (PFE) allows two mutually distrusting parties to jointly evaluate a private function provided by one of the parties on private data provided by the other party while ensuring that neither of them learns anything about the other party’s input…In the PFE setting, one party provides the private input and the other party provides the private function in form of programming bits to the universal circuit, while the UC itself is the publicly known function in the SFE setting. Felsen, page 166);
MOTIVATION: we are the first to also address efficient private function evaluation (PFE) via TEEs, where one of the parties provides a function that represents intellectual property and is computed obliviously on the other party’s input. For realizing PFE, we securely evaluate universal circuits (UCs) that can be programmed via input bits to emulate any function up to a given size (Felsen, page 165).
Conclusion -Therefore, in view of the above reasons, Examiner maintains rejections.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OLEG KORSAK whose telephone number is (571)270-1938. The examiner can normally be reached on Monday-Friday 7:30am - 5:00pm EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Rupal Dharia can be reached on (571) 272-3880. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/OLEG KORSAK/
Primary Examiner, Art Unit 2492