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
2. The information disclosure statement(s) (IDS) submitted on 05/22/2026 and 08/06/2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) are being considered by the examiner.
Response to Amendment
3. This communication is in response to the amendment filed on 04/09/2026. The Examiner has acknowledged the amended Claims 1, 3, 4, 6, 8, 11, 13, 14, 16 and 20. Claims 2 and 12 have been cancelled. Claims 1, 3-11 and 13-20 are pending and Claims 1, 3-11 and 13-20 are rejected.
Response to Arguments
4. Applicant's arguments (Remarks: Pages: 8-10) filed on 04/09/2026 have been fully considered and they are persuasive in part. However, applicant’s other arguments are now moot in view of a new reference applied (Ponsini et al. US 2016/0134660 Al), and the applicant’s amendment necessitated a new ground of rejection.
5. The objection to the Claims 1, 2, 4, 6, 11-12, 14, 16, and 20 has been withdrawn in view of the amended corrections and the cancellation of Claims 2 and 12.
6. Applicant’s arguments (Remarks: Pages: 8-10) with respect to 35 U.S.C. 103 have been fully considered and they are persuasive in part.
Applicant further argues (Remarks: Pages: 8-9):
“Sood and Duffy fail to teach or suggest one or more computing devices to establish a first confidential computing system of the kind recited in claim 1.”; and
“However, Applicant respectfully submits that the relied upon portions of Sood fail to disclose that a TEE is launched within a first confidential computing system and that an interface configured to provide, to a plurality of participating parties, access to the cooperative computing environment is executed using a controller software module hosted by the TEE within the first confidential computing system.” And
“However, Duffy fails to make up for the deficiencies of Sood with respect to the first confidential computing system and TEE.”
To the extent that Applicant argues Sood does not disclose a computing device establishing a first confidential computing system, examiner respectfully disagrees. Sood discloses that a TEE is launched within a confidential computing system with one or more computing devices. For example, Sood discloses that the secure execution environment comprises the first set of secure execution enclaves and the first set of secure data paths (Sood: [Abstract]), where those enclaves collectively form a composable trustworthy execution environment (CTEE) for that workload (Sood: ¶ [0030]), and a computing device used for workload orchestration and/or deployment may include a communication interface to communication with a plurality of heterogeneous computing resources associated with the computing environment, and may further include one or more processors to create secure execution environments (e.g., composable trustworthy execution environments or CTEEs) for securely executing workloads of different tenants across those heterogeneous computing resources) (Sood: ¶ [0091]).
While the combination of Sood and Duffy does not explicitly disclose “an interface configured to provide, to a plurality of participating parties, access to the cooperative computing environment is executed using a controller software module hosted by the TEE within the first confidential computing system” as recited in the amended claims, Applicant’s arguments are now moot in view of the new reference applied (Ponsini et al. US 2016/0134660 Al). Please see the 35 USC 103 rejection below.
Further, applicant’s arguments with respect to the remaining independent Claims 11 and 20 and the dependent Claims 3-10 and 13-19 are based on applicant’s arguments with respect to Claim 1 and their dependency, and therefore, are now moot in view of the new reference applied (Ponsini et al. US 2016/0134660 Al). Applicant's amendment necessitated a new ground of rejection.
Claim Rejections - 35 USC § 103
7. 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.
8. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
9. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
10. Claims 1, 3-9, 11, 13-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Sood et al. (US 2019/0220601 A1, hereinafter Sood) in view of Duffy et al. (US 2019/0205555 A1, hereinafter Duffy), and further in view of Ponsini et al. (US 2016/0134660 Al, hereinafter Ponsini).
Regarding Claim 1,
Sood discloses a method for implementing a cooperative computing environment, the method comprising, using one or more computing devices (Sood: ¶ [0090] embodiment of workload orchestration using CTEEs…, flowchart 700 may be implemented using the embodiments and functionality described throughout, ¶ [0113] embodiments of methods, hardware, software, firmware or code set forth above may be implemented via instructions, ¶ [0025] an example computing system 100 with composable trustworthy execution environments (CTEEs) for heterogenous workloads, Figs. 1, 7);
establishing a first confidential computing system (Sood: ¶ [0091] a computing device used for workload orchestration and/or deployment may include a communication
interface to communication with a plurality of heterogeneous computing resources associated with the computing environment, and may further include one or more
processors to create secure execution environments (e.g., composable trustworthy execution environments or CTEEs) for securely executing workloads of different tenants across
those heterogeneous computing resources, ¶ [0002] disclosure relates in general to the field of secure execution environments, and more particularly, though not exclusively, to composable trustworthy execution environments (CTEEs) for heterogeneous and/or multitenant workloads, ¶¶ [0015-0016, 0058-0059]), wherein the first confidential computing system includes a trusted execution environment (TEE) launched within the first confidential computing system (Sood: [Abstract]the secure execution environment comprises the
first set of secure execution enclaves and the first set of secure data paths, ¶ [0030] those enclaves collectively form a composable trustworthy execution environment (CTEE) for that workload, ¶ [0091] a computing device used for workload orchestration and/or deployment may include a communication interface to communication with a plurality of heterogeneous computing resources associated with the computing environment, and may further include one or more processors to create secure execution environments (e.g., composable trustworthy execution environments or CTEEs) for securely executing workloads of different tenants across those heterogeneous computing resources, ¶ [0069]);
executing, on the first confidential computing system, a controller software module hosted by the TEE (Sood: ¶ [0091] a computing device used for workload orchestration and/or deployment may include a communication interface to communication with a plurality of heterogeneous computing resources associated with the computing environment, and may further include one or more processors to create secure execution environments (e.g., composable trustworthy execution environments or CTEEs) for securely executing workloads of different tenants across those heterogeneous computing resources, ¶ [0110] Embodiments of the disclosure may be implemented as computer programs or program code executing on programmable systems comprising at least one processor, a storage system, ¶ [0060]);
executing, using the controller software module hosted by the TEE within the first confidential computing system, an interface configured to provide, to a plurality of participating parties, access to the computing environment (Sood: ¶ [0088] a network component such as a bridge, router, or switch may be used to route data from one or more input streams to multiple output streams, and vice versa. When a bridge, router, or switch is included in the trust boundary of the tenants, ¶ [0033] interconnects and/or links connecting secured enclaves can support a variety of configurations, including point-to-point, point-to-multipoint, endpoint devices directly connected to each other, connected /tunneled over a switch, bridge, and/or router, and so forth, ¶ [0034] when a switch is within the trust boundary of a tenant, then the switch may include the ability to create a secure enclave and/or data path that is included in the CTEE for that tenant, ¶ [0110] Embodiments of the disclosure may be implemented as computer programs or program code executing on programmable systems comprising at least one processor, a storage system, ¶¶ [0060, 0122]);
receiving, via the interface from a requesting participating party of the plurality of participating parties (Sood: ¶ [0022] this disclosure presents various embodiments of dynamic, scalable, and composable trustworthy execution environments (CTEEs) for workloads
executed on heterogeneous computing platforms with multiple tenants, ¶ [0088] a network component such as a bridge, router, or switch may be used to route data from one or more input streams to multiple output streams, and vice versa. When a bridge, router, or switch is included in the trust boundary of the tenants, ¶ [0030] when a particular processing component ll2a-d is used to execute multiple workloads of different tenants l02a-b, a separate enclave ll4a-h is created on that processing component for each workload, ¶¶ [0033-0034]), a request to initiate a setup process for the cooperative computing environment on a second confidential computing system (Sood: ¶ [0059] multiple secure execution enclaves 303 are configured on each processing resource 302a-e for the workloads of the different tenants, ¶ [0092] where a request to deploy a workload in a heterogeneous computing environment is received… Moreover, the workload may be a heterogeneous workload that is designed to execute across various heterogeneous computing resources, ¶ [0100] the tenant may request and/or negotiate certain changes to the secure execution environment, ¶ [0093] the request may indicate that the workload is to be deployed in a secure execution environment across those heterogeneous computing resources, ¶ [0065] in order to execute certain workloads of the tenants 410, 420 on the infrastructure of the 3rd party service provider 430, ¶ [0081]); and
in response to a determination that non-requesting participating parties of the plurality of participating parties approved the request, completing the setup process for the cooperating computing environment in accordance with one or more criteria defined by the request (Sood: ¶ [0099] the CTEE configuration may be provided to the tenant for approval, which may include root-of-trust (RoT) signatures and attestations for the trustworthiness of each component in the CTEE, ¶ [0101] If the tenant approves the secure execution environment (e.g., CTEE), the flowchart then proceeds to block 716 to deploy the workload for execution in the secure execution environment. In this manner, the workload is then securely executed across the various heterogeneous components in the secure execution environment (e.g., CTEE), ¶[0100]).
It is noted Sood does not explicitly disclose:
in response to a determination that non-requesting participating parties of the plurality of participating parties approved the request, completing the setup process for the cooperating computing environment in accordance with one or more criteria defined by the request.
Duffy from the same field of endeavor as the claimed invention discloses method of multiple-person controls, using digital signatures of resource requests to provide a separate layer of protection. A script running with sufficient privilege executes resource requests requiring privilege elevation, but only after validating a first digital signature signed by a requester and validating one or more additional digital signatures signed by reviewers (Duffy: [Abstract]), a resource request 110, can be any task or action initiated by a computer user, such as a system administrator, to cause secure-computing system 100 to perform an action (Duffy: ¶ [0161]), Requester 106 digitally
signs 202 action-request file 114 to create a request-signature file 116. Action-request file 114 together with signature file 116 comprise an action-request package 118, which is distributed 206 to other authorized participants 104 (Duffy: ¶ [0162], ¶ [0163]), and requester 106 submits approval package 120 to an action-processing tool 122 for processing and if compliant, tool 122 grants 210 resource request. Tool 122 is software that runs on secure computing system 100 (Duffy: ¶ [0164]).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Duffy in the teachings of Sood. A person having ordinary skill in the art would have been motivated to do so to protect against the
insider threat, yet have minimal impact to system-administration work flow and to provide an easy-to-implement method of multiple-person-control, that is simple to analyze and verify, offering a separate, independent layer of security that is scalable and reconfigurable (Duffy: ¶ [0021], also see [Abstract]).
It is noted Sood and Duffy do not explicitly disclose:
executing, on the first confidential computing system, a controller software module hosted by the TEE; and
executing, using the controller software module hosted by the TEE within the first confidential computing system, an interface configured to provide, to a plurality of participating parties, access to the computing environment.
However, Ponsini from the same field of endeavor as the claimed invention discloses that specifically, one or more embodiments relate to associating a user to the trusted execution environment (TEE) of his/her device in order to remotely manage sensitive applications
related to the user within his/her device (Ponsini: ¶ [0012]), the TEE executes a trusted OS, which is designed to enable the TEE using security based design techniques (Ponsini: ¶ [0015]), and on the TEE (204) side, the TEE exposes sets of application programming interfaces(APIs) to enable communication from the REE and others to use trusted software functionality within the TEE…, the trusted OS is the hosting code that provides an internal API to trusted applications which run on
top of the trusted OS, and a proprietary method to enable the client device API software to interface with the TEE from other execution environments. The TEE internal API (214) is one of these APIs exposed by the Trusted OS (206) to trusted applications (208) (Ponsini: ¶ [0028], Also see ¶¶ [0030, 0052, Fig. 2 – 204, 206, 214]).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Ponsini in the teachings of Sood. A person having ordinary skill in the art would have been motivated to do so as the API and the controlling software would execute within the trusted boundary rather than in an untrusted environment, therefore increasing the confidentiality and the integrity of the requests received from the participants and allowing authentication and cryptographic operations within the trusted environment.
Regarding Claim 3,
Claim 3 is dependent on Claim 1, and the combination of Sood, Duffy and Ponsini discloses all the limitations of Claim 1. Sood further discloses further comprising performing a remote attestation process between each of the plurality of participating parties and the controller software module hosted by the TEE within the first confidential computing system (Sood: ¶ [0088] In order for the bridge, router, or switch to assist in protecting the CTEE, the bridge, router, or switch is required to attest its trustworthiness to the platform and any remote party. Attestation of the trustworthiness of the bridge, router, or switch includes attestation of its hardware identity and software/firmware identities through cryptographically secure evidence, ¶ [0110] Embodiments of the disclosure may be implemented as computer programs or program code executing on programmable systems comprising at least one processor, a storage system, ¶ [0069] service provider (SP) security controller 433 provides access control and attestation services to the particular tenant 410, 420 and ensures that the interconnects and network links on the provisioned computing platforms 440a-b are securely configured per the tenant's security policy, ¶¶ [0076, 0083]).
The combination of Sood and Duffy does not explicitly disclose:
performing a remote attestation process between each of the plurality of participating parties and the controller software module hosted by the TEE within the first confidential computing system.
Ponsini further discloses that the TEE executes a trusted OS, which is designed to enable the TEE using security based design techniques (Ponsini: ¶ [0015]), the TEE executes a trusted OS, which is designed to enable the TEE using security based design techniques (Ponsini: ¶ [0015]), on the TEE (204) side, the TEE exposes sets of application programming interfaces(APIs) to enable communication from the REE and others to use trusted software functionality within the TEE…, the trusted OS is the hosting code that provides an internal API to trusted applications which run on top of the trusted OS, and a proprietary method to enable the client device API software to interface with the TEE from other execution environments. The TEE internal API (214) is one of these APIs exposed by the Trusted OS (206) to trusted applications (208) (Ponsini: ¶ [0028]), and the TEE that is configured to store a data structure such as a table, a list, etc., mapping each client device (116, 118, 120) to the TEE identifier that uniquely identifies the TEE on the client device, as well as a cryptographic key unique to each device, which may be used to verify the (208) authenticity of user-binding requests (Ponsini: ¶ [0020], Also see ¶¶ [0045, 0046]).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Ponsini in the teachings of Sood. A person having ordinary skill in the art would have been motivated to do so as the API and the controlling software would execute within the trusted boundary rather than in an untrusted environment, therefore increasing the confidentiality and the integrity of the requests received from the participants and allowing authentication and cryptographic operations within the trusted environment.
Regarding Claim 4,
Claim 4 is dependent on Claim 3, and the combination of Sood, Duffy and Ponsini discloses all the limitations of Claim 3. Sood further discloses wherein executing the controller software module includes at least one of, (i) providing source code of the controller software module to the plurality of participating parties; and (ii) providing a cryptographic measurement of the controller software module to the plurality of participating parties (Sood: ¶ [0088] In order for the bridge, router, or switch to assist in protecting the CTEE, the bridge, router, or switch is required to attest its trustworthiness to the platform and any remote party. Attestation of the trustworthiness of the bridge, router, or switch includes attestation of its hardware identity and software /firmware identities through cryptographically secure evidence, ¶ [0083] security controller, and/or virtualized infrastructure manager (VIM) may then collectively provision the various components and interconnects on the underlying infrastructure to build a CTEE for the workload, as well as procure root-of-trust (RoT) signatures and attestation from those components in order to build a complete CTEE, ¶ [0034] when a switch is within the trust boundary of a tenant, then the switch may include the ability to create a secure enclave and/or data path that is included in the CTEE for that tenant, ¶ [0110] Embodiments of the disclosure may be implemented as computer programs or program code executing on programmable systems comprising at least one processor, a storage system, ¶¶ [0030, 0060, 0087, 0097, 0099]).
The combination of Sood and Duffy does not explicitly disclose wherein executing the controller software module includes at least one of (i) providing source code of the controller software module to the plurality of participating parties and (ii) providing a cryptographic measurement of the controller software module to the plurality of participating parties.
Ponsini further discloses that the TEE executes a trusted OS, which is designed to enable the TEE using security based design techniques (Ponsini: ¶ [0015]), and the TEE that is configured to store a data structure such as a table, a list, etc., mapping each client device (116,
118, 120) to the TEE identifier that uniquely identifies the TEE on the client device, as well as a cryptographic key unique to each device, which may be used to verify the (208) authenticity of user-binding requests (Ponsini: ¶ [0020]), Trusted OS (206) components dedicated to exposing an inbuilt TEE capability, such as cryptography. The trusted kernel/trusted functions (212) also allow for communication with trusted peripherals (232) in the device hardware (230)…, the TEE is configured to provide trusted storage of data and keys such that no unauthorized internal or external attacker may access, copy, or modify the data contained in trusted storage (Ponsini: ¶ [0030], ¶ [0045]).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Ponsini in the teachings of Sood. A person having ordinary skill in the art would have been motivated to do so as the API and the controlling software would execute within the trusted boundary rather than in an untrusted environment, therefore increasing the confidentiality and the integrity of the requests received from the participants and allowing authentication and cryptographic operations within the trusted environment.
Regarding Claim 5,
Claim 5 is dependent on Claim 1, and the combination of Sood, Duffy and Ponsini discloses all the limitations of Claim 1. Sood does not explicitly disclose further comprising at least one of:
determining whether the non-requesting participating parties of the plurality of participating parties approve the request;
determining whether a predetermined subset of the non-requesting participating parties of the plurality of participating parties approve the request; and
assigning respective weights to each of the participating parties, defining a threshold for acceptance of requests, obtaining a weighted sum of responses from the non-requesting participating parties, and performing at least one operation of the setup process in response to the weighted sum exceeding the defined threshold.
Duffy further discloses method of multiple-person controls, using digital signatures of resource requests to provide a separate layer of protection. A script running with sufficient privilege executes resource requests requiring privilege elevation, but only after validating a first digital signature signed by a requester and validating one or more additional digital signatures signed by reviewers (Duffy: [Abstract]), requester 106 submits approval package 120 to an action-processing tool 122 for processing and if compliant, tool 122 grants 210 resource request. Tool 122 is software that runs on secure computing system 100 (Duffy: ¶ [0164]), and count the number of valid signatures that were signed by different authorized participants and check whether two or more such signatures are present. Stated this way, the rule provide cryptographic evidence that two different
authorized participants have indicated approval for the submitted resource request (Duffy: ¶ [0205], ¶¶ [0293-0294]).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Duffy in the teachings of Sood. A person having ordinary skill in the art would have been motivated to do so to protect against the
insider threat, yet have minimal impact to system-administration work flow and to provide an easy-to-implement method of multiple-person-control, that is simple to analyze and verify, offering a separate, independent layer of security that is scalable and reconfigurable (Duffy: ¶ [0021], also see [Abstract]).
Regarding Claim 6,
Claim 6 is dependent on Claim 1, and the combination of Sood, Duffy and Ponsini discloses all the limitations of Claim 1. Sood further discloses subsequent to completing the setup process, changing a configuration of the cooperative computing environment by: (i) receiving a request from a first participating party to execute a change to the configuration of the cooperative computing environment (Sood: ¶ [0100] the tenant may request and/or negotiate certain changes to the secure execution environment, ¶ [0102] a subsequent request may be received to deploy another workload of a different second tenant. Accordingly, another secure execution environment (e.g., CTEE) may be configured for that workload by creating secure execution enclaves (e.g., TEEs, HMEEs) and secure data paths on the appropriate processing and interconnect resources from the collection of heterogeneous computing resources, ¶ [0103]).
Sood does not explicitly disclose:
(ii) executing the change to the configuration of the cooperative computing environment by at least one of:
determining that the non-requesting participating parties of the plurality of participating parties approve the request;
determining that a predetermined subset of the non-requesting participating parties of the plurality of participating parties approve the request; and
assigning respective weights to each of the participating parties, defining a threshold for acceptance of requests, obtaining a weighted sum of responses from the non-requesting participating parties, and executing the change in response to the weighted sum exceeding the defined threshold.
Duffy further discloses method of multiple-person controls, using digital signatures of resource requests to provide a separate layer of protection. A script running with sufficient privilege executes resource requests requiring privilege elevation, but only after validating a first digital signature signed by a requester and validating one or more additional digital signatures signed by reviewers (Duffy: [Abstract]), requester 106 submits approval package 120 to an action-processing tool 122 for processing and if compliant, tool 122 grants 210 resource request. Tool 122 is software that runs on secure computing system 100 (Duffy: ¶ [0164]), and count the number of valid signatures that were signed by different authorized participants and check whether two or more such signatures are present. Stated this way, the rule provide cryptographic evidence that two different
authorized participants have indicated approval for the submitted resource request (Duffy: ¶ [0205], ¶¶ [0293-0294]).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Duffy in the teachings of Sood. A person having ordinary skill in the art would have been motivated to do so to protect against the
insider threat, yet have minimal impact to system-administration work flow and to provide an easy-to-implement method of multiple-person-control, that is simple to analyze and verify, offering a separate, independent layer of security that is scalable and reconfigurable (Duffy: ¶ [0021], also see [Abstract]).
Regarding Claim 7,
Claim 7 is dependent on Claim 6, and the combination of Sood, Duffy and Ponsini discloses all the limitations of Claim 6. Sood does not explicitly disclose wherein the change corresponds to a request to at least one of add a new party from the plurality of participating parties and remove a party from the plurality of participating parties.
Duffy further discloses requester 106 submits approval package 120 to an action-processing tool 122 for processing and if compliant, tool 122 grants 210 resource request. Tool 122 is software that runs on secure computing system 100 (Duffy: ¶ [0164]), and the present method of two-person
controls can be used to add participant entries to table 152. This is initiated by an authorized participant creating an action-request file specifying adding an entry to table 152, getting a second participant to approve the request, and submitting the resulting approval package to action-processing tool 122. Similarly, the present method of two-person controls can be used to disenroll a participant, meaning removing the participant's entry in table 152 to prevent future participation (Duffy: ¶ [0258], ¶[0209]).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Duffy in the teachings of Sood. A person having ordinary skill in the art would have been motivated to do so to protect against the
insider threat, yet have minimal impact to system-administration work flow and to provide an easy-to-implement method of multiple-person-control, that is simple to analyze and verify, offering a separate, independent layer of security that is scalable and reconfigurable (Duffy: ¶ [0021], also see [Abstract]).
Regarding Claim 8,
Claim 8 is dependent on Claim 1, and the combination of Sood, Duffy and Ponsini discloses all the limitations of Claim 1. Sood further discloses wherein the one or more computing devices include at least one processor configured to operate the TEE (Sood: ¶ [0060] computing platform 300 supports islands of secure execution enclaves 303a-j (e.g., TEEs and/or HMEEs) on each processing resource 302a-e, which are interconnected over cryptographically secured interconnects or links 306a-h, thus forming CTEEs for the respective tenant workloads, ¶ [0091] a computing device used for workload orchestration and/or deployment may include a communication interface to communication with a plurality of heterogeneous computing resources associated with the computing environment, and may further include one or more processors to create secure execution environments (e.g., composable trustworthy execution environments or CTEEs) for securely executing workloads of different tenants across those heterogeneous computing resources, ¶ [0096] the secure execution enclaves may be implemented as trusted execution environments (TEES) and/or hardware-mediated execution enclaves (HMEEs), ¶¶ [0029, 0043-0044, 0058-0059, 0065]).
Regarding Claim 9,
Claim 9 is dependent on Claim 1, and the combination of Sood, Duffy and Ponsini discloses all the limitations of Claim 1. Sood further discloses wherein the first confidential computing system requests validation of the second confidential computing system by remote attestation (Sood: ¶ [0088] In order for the bridge, router, or switch to assist in protecting the CTEE, the bridge, router, or switch is required to attest its trustworthiness to the platform and any remote party. Attestation of the trustworthiness of the bridge, router, or switch includes attestation of its hardware identity and software/firmware identities through cryptographically secure evidence, ¶¶ [0083, 0099]).
Regarding Claim 11,
Sood discloses a system configured to implement a cooperative computing environment, the system comprising, one or more computing devices configured to (Sood: ¶ [0025] an example computing system 100 with composable trustworthy execution environments (CTEEs) for heterogenous workloads, ¶ [0113] embodiments of methods, hardware, software, firmware or code set forth above may be implemented via instructions, Figs. 1, 7, ¶¶ [0090, 0110]), a management gateway configured to execute one or more functions of the interface, the management gateway configured to (Sood: ¶ [0088] a network component such as a bridge, router, or switch may be used to route data from one or more input streams to multiple output streams, and vice versa. When a bridge, router, or switch is included in the trust boundary of the tenants, ¶ [0033] interconnects and/or links connecting secured enclaves can support a variety of configurations, including point-to-point, point-to-multipoint, endpoint devices directly connected to each other, connected /tunneled over a switch, bridge, and/or router, and so forth, ¶ [0034] when a switch is within the trust boundary of a tenant, then the switch may include the ability to create a secure enclave and/or data path that is included in the CTEE for that tenant, ¶ [0110] Embodiments of the disclosure may be implemented as computer programs or program code executing on programmable systems comprising at least one processor, a storage system, ¶ [0122]), and discloses all the limitations of Claim 11, in combination with Duffy and Ponsini, as discussed in Claim 1. Therefore, Claim 11 is rejected using the same rationales as discussed in Claim 1.
Regarding Claim 13,
Claim 13 is dependent on Claim 11, and the combination of Sood, Duffy and Ponsini discloses all the limitations of Claim 11. The combination of Sood, Duffy and Ponsini discloses all the limitations of Claim 13 as discussed in Claim 3. Therefore, Claim 13 is rejected using the same rationales as discussed in Claim 3.
Regarding Claim 14,
Claim 14 is dependent on Claim 13, and the combination of Sood, Duffy and Ponsini discloses all the limitations of Claim 13. The combination of Sood, Duffy and Ponsini discloses all the limitations of Claim 14 as discussed in Claim 4. Therefore, Claim 14 is rejected using the same rationales as discussed in Claim 4.
Regarding Claim 15,
Claim 15 is dependent on Claim 11, and the combination of Sood, Duffy and Ponsini discloses all the limitations of Claim 11. The combination of Sood, Duffy and Ponsini discloses all the limitations of Claim 15 as discussed in Claim 5. Therefore, Claim 15 is rejected using the same rationales as discussed in Claim 5.
Regarding Claim 16,
Claim 16 is dependent on Claim 11, and the combination of Sood, Duffy and Ponsini discloses all the limitations of Claim 11. The combination of Sood, Duffy and Ponsini discloses all the limitations of Claim 16 as discussed in Claim 6. Therefore, Claim 16 is rejected using the same rationales as discussed in Claim 6.
Regarding Claim 17,
Claim 17 is dependent on Claim 16, and the combination of Sood, Duffy and Ponsini discloses all the limitations of Claim 16. The combination of Sood, Duffy and Ponsini discloses all the limitations of Claim 17 as discussed in Claim 7. Therefore, Claim 17 is rejected using the same rationales as discussed in Claim 7.
Regarding Claim 18,
Claim 18 is dependent on Claim 11, and the combination of Sood, Duffy and Ponsini discloses all the limitations of Claim 11. The combination of Sood, Duffy and Ponsini discloses all the limitations of Claim 18 as discussed in Claim 9. Therefore, Claim 18 is rejected using the same rationales as discussed in Claim 9.
Regarding Claim 20,
Sood discloses a system configured to implement a cooperative computing environment, the system including a processing device configured to execute instructions stored in memory to (Sood: ¶ [0025] an example computing system 100 with composable trustworthy execution environments (CTEEs) for heterogenous workloads…, (e.g., a computing device to assign workloads to the compute devices ll0a-b for execution), ¶ [0088] a network component such as a bridge, router, or switch may be used to route data from one or more input streams to multiple output streams, and vice versa. When a bridge, router, or switch is included in the trust boundary of the tenants, ¶ [0033] interconnects and/or links connecting secured enclaves can support a variety of configurations, including point-to-point, point-to-multipoint, endpoint devices directly connected to each other, connected /tunneled over a switch, bridge, and/or router, and so forth, ¶ [0034] when a switch is within the trust boundary of a tenant, then the switch may include the ability to create a secure enclave and/or data path that is included in the CTEE for that tenant, ¶ [0113] embodiments of methods, hardware, software, firmware or code set forth above may be implemented via instructions, Figs. 1, 7, ¶¶ [0045, 0090, 0110, 0122]), and discloses all the limitations of Claim 20, in combination with Duffy and Ponsini, as discussed in Claim 1. Therefore, Claim 20 is rejected using the same rationales as discussed in Claim 1.
11. Claims 10 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Sood et al. (US 2019/0220601 A1, hereinafter Sood), in view of Duffy et al. (US 2019/0205555 A1, hereinafter Duffy), in view of Ponsini et al. (US 2016/0134660 Al, hereinafter Ponsini), and further in view of Li et al. (US 2020/0004973 A1, hereinafter Li).
Regarding Claim 10,
Claim 10 is dependent on Claim 1, and the combination of Sood, Duffy and Ponsini discloses all the limitations of Claim 1. Sood does not explicitly disclose wherein (i) the first confidential computing system is comprised of a plurality of computing devices executing a secure multiparty computation protocol or (ii) the second confidential computing system is comprised of a plurality of computing devices executing a secure multiparty computation protocol.
Duffy further discloses method of multiple-person controls, using digital signatures of resource requests to provide a separate layer of protection. A script running with sufficient privilege executes resource requests requiring privilege elevation, but only after validating a first digital signature signed by a requester and validating one or more additional digital signatures signed by reviewers (Duffy: [Abstract]), and requester 106 submits approval package 120 to an action-processing tool 122 for processing and if compliant, tool 122 grants 210 resource request. Tool 122 is software that runs on secure computing system 100 (Duffy: ¶ [0164]).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Duffy in the teachings of Sood. A person having ordinary skill in the art would have been motivated to do so to protect against the
insider threat, yet have minimal impact to system-administration work flow and to provide an easy-to-implement method of multiple-person-control, that is simple to analyze and verify, offering a separate, independent layer of security that is scalable and reconfigurable (Duffy: ¶ [0021], also see [Abstract]).
However, the combination Sood, Duffy and Ponsini does not explicitly disclose wherein (i) the first confidential computing system is comprised of a plurality of computing devices executing a secure multiparty computation protocol or (ii) the second confidential computing system is comprised of a plurality of computing devices executing a secure multiparty computation protocol.
However, Li from the same field of endeavor as the claimed invention discloses obtaining verification data based on the first ciphertext for verifying whether a ciphertext to be verified corresponds to the object data; and sending the verification data to the first computing device for the first computing device to execute a cryptography protocol with a third computing device based on the verification data (Li: [Abstract]), a scenario diagram of the secure multiparty computation according to the embodiments of the present specification. As shown in FIG. 1, the participants of a secure multiparty computation include a first computing device, for example, a first server 11 and a third computing device, for example, a third server 13, wherein the first server 11 is the server of a demonstrator which is an individual, an enterprise, an organization, etc., and the third server 13 is the server of a validator which may be an individual, an enterprise, an organization, etc. providing service to the demonstrator. The scenario also includes a second computing device, for example, a second server 12, which is, for example, the server of a bank, a tax bureau, and another authorized organization. The second server stores the data of the demonstrator (Li: ¶ [0080]), and obtaining an input of a secure multiparty computation protocol, the verification data is the authorized organization's digital signature for the first ciphertext, wherein the verification unit further comprises: a third determination sub-unit 1725 configured for determining whether the second ciphertext matches the digital signature (Li: ¶ [0161], also see ¶ [0031]).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Li in the teachings of Sood and Duffy. A person having ordinary skill in the art would have been motivated to do so as through endorsing homomorphically encrypted ciphertext and using a secure multiparty computation protocol, the dilemma between data privacy and data credibility is resolved, obviating the use of zero-knowledge proof technology and expensive computation and storage consumption required by the zero-knowledge proof technology and solve the problem of data falsification in evaluations involving multiple demonstrators' data (Li: ¶ [0057]).
Regarding Claim 19,
Claim 19 is dependent on Claim 11, and the combination of Sood, Duffy and Ponsini discloses all the limitations of Claim 11. The combination of Sood, Duffy, Ponsini and Li discloses all the limitations of Claim 19 as discussed in Claim 10. Therefore, Claim 19 is rejected using the same rationales as discussed in Claim 10.
Conclusion
12. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US-20150220745-A1
US-10678675-B2
US-20210297262-A1
US-20220284100-A1
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMEERA WICKRAMASURIYA whose telephone number is (571)272-1507. The examiner can normally be reached on M-F 9:45am - 6:15pm.
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, Jung W. Kim can be reached on 571-272-3804. 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.
/SAMEERA WICKRAMASURIYA/
Examiner, Art Unit 2494
/JUNG W KIM/Supervisory Patent Examiner, Art Unit 2494
Prosecution Insights