DETAILED ACTION
This communication is in response to Application No. 18/933,171 filed on October 31st, 2024, in which claims 1-25 are presented for examination.
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 submitted on 02/11/2025 and 04/02/2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements were considered by the examiner.
Specification
The contents of the specification are sufficient for examination purposes.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 9-11, 15-18, and 21-25 are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (hereinafter Zhu) (“Enabling Privacy-Preserving, Compute- and Data-Intensive Computing using Heterogeneous Trusted Execution Environment”) in view of Beutel et al. (hereinafter Beutel) (“Flower: A Friendly Federated Learning Framework”).
Regarding Claim 1, Zhu teaches a method comprising (Pg. 1, Col. 1, Para. 1, “We have implemented the HETEE design on a hardware prototype system, and evaluated it with large-scale Neural Net- works inference and training tasks”, where “implement[ation of] the HETEE design on a hardware prototype system” is a method; see also Pg. 6, Col. 2, Fig. 3, “Example pseudo code to use HETEE”, where methods “to use HETEE” are depicted in “pseudo code” and Pg. 6, Fig. 5, where the method is further depicted):
providing a shared asset in a hardware accelerator (Pg. 10, Col. 1, Para. 2, “In the design of HETEE the states of accelerators are cleared upon mode switches and task switches. This reduces shared resources between the insecure world and secure world, as well as among tasks” and Pg. 10, Col. 2, Para, 2, “In the HETEE design, software stack of accelerator needs to be run in the trusted OS on security controller . . . In our prototype system, the ARM Cortex A9 processor of the ZC706 runs a Linux kernel . . . After the ZC706 de- crypts and verifies the task sent from the host CPU, the data is transmitted back, and the GPU software stack including Tensorflow, CUDA library and GPU driver running on the host CPU are responsible for using the GPU”, where shared assets, “shared resources” as well as the underlying “software stack of the accelerator” and hardware components, are provided in the “the states of accelerators”, which are hardware accelerators, see Pg. 2, Col. 2, Para. 1, “All the computing units, like GPUs, AI accelerators, etc., are shared between the OS and the security controller”; Pg. 1, Col. 2, Para. 3, “high-throughput accelerators such as graph-processing unit (GPU), tensor-processing unit (TPU), field-programmable gate array (FPGA, for building custom accelerators) etc.”; and Pg. 10, Col. 1, Para. 1, “It only needs to support limited hardware accelerators”; see also Pg. 7, Col. 1, Para. 1, “the remote user encrypts the command (i.e., AI model), packs the ciphertext into a command task, and put it into the task queue. The task manager fetches ciphertexts from the task queue, verifies the integrity of the messages, then decrypts and parses them. If the parsed task is a command, task manager will initiate a corresponding process (i.e.,Tensorflow program) to execute the command. At the same time, input and output buffers are created for the process. When the task manager detects a new data task, it dispatches the task to the corresponding process input buffers. After its data is processed by accelerator”, where an asset, “the command (i.e., AI model) . . . [and] the computing result”, is provided in an “accelerator”, “When the task manager detects a new data task, it dispatches the task to the corresponding process input buffers. After its data is processed by accelerator, the process places the computing result in the output buffer”);
coupling the hardware accelerator to a first data holder; uploading first confidential data from the first data holder into the hardware accelerator (Pg. 7, Col. 2, Para. 3, “When a user needs to utilize the accelerator resource, a request is sent to the security controller, which dynamically allocates a certain amount of accelerator resources to the user”; Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data. These data may be encrypted inside the CPU TEE, or placed directly on the host hard disk in the encrypted form, or come from a remote user”; and Pg. 7, Col. 1, Para. 2, “First, the process initializes accelerators and allocates device buffers for data. Then, the process loads new data from the input buffer, and moving them into the memory space of the accelerator. Then, the computing kernel is launched. After the execution, the result is copied from the accelerators to the output buffer”, where the hardware accelerator is coupled to a data holder, “dynamically allocates a certain amount of accelerator resources to the user”, and confidential data is uploaded, “transmit sensitive data”, from the data holder, “from a remote user”, into the hardware accelerator, “the process loads new data from the input buffer, and moving them into the memory space of the accelerator”, and where the plurality of “different users” requires a first data holder, such that its associated confidential data is first confidential data, see Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”);
updating . . . [an] asset using the first confidential data (Pg. 7, Col. 1, Para. 1, “After its data is processed by accelerator, the process places the computing result in the output buffer”, where the “the computing result” is generated using the “data”, which is first confidential data when “transmit[ted] sensitive data” from a first “remote user”, see Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data . . . from a remote user” and Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Pg. 1, Col. 2, Para. 1, “there is an urgent demand for privacy-preserving techniques capable of supporting compute- and data-intensive (CDI) computing, such as training deep neural networks (DNNs) over an enormous amount of data” and Pg. 11, Col. 2, Para. 1, “It can be observed that the HETEE throughput overhead is 12.34% for network inference and 9.87% for network training on average”, where the using can be updating an asset, “network training”);
deleting the first confidential data from the hardware accelerator (Pg. 2, Col. 2, Para. 2, “Our solution leverages the unique features of today’s GPU and accelerator designs . . . they can be “reset” to a trusted status by simply cleaning up all their internal storage . . . HETEE either utilizes its “hot reset” function to restore it to the clean status or runs a program to wipe out all its storage content”; Pg. 4, Col. 2, Para. 2, “we consider that the under the fundamental reset or cold reboot, the firmware on an accelerator (such as GPU) can ensure that all micro-architecture statuses, including those of caches and memory, are cleared”; and Pg. 10, Col. 1, Para. 2, “In the design of HETEE the states of accelerators are cleared upon mode switches and task switches. This reduces shared resources between the insecure world and secure world, as well as among tasks”, where data is deleted from the hardware accelerator, “wipe out all its storage content” such that “the states of accelerators are cleared” to “ensure that all micro-architecture statuses, including those of caches and memory, are cleared”, which is first confidential data when “transmit[ted] sensitive data” from a first “remote user”, see Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data . . . from a remote user” and Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Pg. 7, Col. 1, Para. 1, “Finally, the task manager destroys the task queues and terminates the process”);
coupling the hardware accelerator to a second data holder, wherein the first data holder is no longer able to communicate with the hardware accelerator; uploading second confidential data from the second data holder into the hardware accelerator (Pg. 7, Col. 2, Para. 3, “When a user needs to utilize the accelerator resource, a request is sent to the security controller, which dynamically allocates a certain amount of accelerator resources to the user”; Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data. These data may be encrypted inside the CPU TEE, or placed directly on the host hard disk in the encrypted form, or come from a remote user”; and Pg. 7, Col. 1, Para. 2, “First, the process initializes accelerators and allocates device buffers for data. Then, the process loads new data from the input buffer, and moving them into the memory space of the accelerator. Then, the computing kernel is launched. After the execution, the result is copied from the accelerators to the output buffer”, where the hardware accelerator is coupled to a data holder, “dynamically allocates a certain amount of accelerator resources to the user”, and confidential data is uploaded, “transmit sensitive data”, from the data holder, “from a remote user”, into the hardware accelerator, “the process loads new data from the input buffer, and moving them into the memory space of the accelerator”, and where the plurality of “different users” requires a second data holder, such that its associated confidential data is second confidential data, see Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Pg. 7, Col. 2, Para. 3, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them. Coupled with our context cleaning mechanism, such a design can minimize side-channel leakages across tasks” and Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds. By dynamically configuring the Express Fabric chip, an accelerator can be physically assigned to the host or the security controller on-demand, thus enabling the switching of the accelerator security mode. With this feature, HETEE dynamically defines the boundary of the secure world. To avoid the security risks from the data and code on the accelerator switched between different worlds, HETEE utilizes context clearance to restore the device to a trusted state”, where the coupling can be to the same hardware accelerator, “it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds . . . an accelerator can be physically assigned to the host or the security controller on-demand, thus enabling the switching of the accelerator security mode”, which occurs when the first data holder is no longer able to communicate with the hardware accelerator, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them”); and
updating . . . [an] asset using the second confidential data (Pg. 7, Col. 1, Para. 1, “After its data is processed by accelerator, the process places the computing result in the output buffer”, where the “the computing result” is generated using the “data”, which is second confidential data when “transmit[ted] sensitive data” from a second “remote user” of the plurality of “different users”, see Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data . . . from a remote user” and Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Pg. 1, Col. 2, Para. 1, “there is an urgent demand for privacy-preserving techniques capable of supporting compute- and data-intensive (CDI) computing, such as training deep neural networks (DNNs) over an enormous amount of data” and Pg. 11, Col. 2, Para. 1, “It can be observed that the HETEE throughput overhead is 12.34% for network inference and 9.87% for network training on average”, where the using can be updating an asset, “network training”).
Zhu does not explicitly disclose . . . the shared . . . the shared . . . (Pg. 4, Col. 2, Para. 5, “We expect that HETEE provides strong isolation both between secure/insecure worlds and be- tween the enclaves that run different computing tasks”, where there is “strong isolation” between “different computing tasks” and, as a result, the updating is not specifically described as of the shared asset).
However, Beutel teaches . . . [updating] the shared [asset using the first data] . . . [and updating] the shared [asset using the second data] (Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates” and Pg. 2, Col. 2, Para. 1, “Using Flower as the underlying framework, we present experiments that explore both algorithmic and system level aspects of FL on five machine learning workloads with up to 1000 clients”, where the shared asset, “the aggregated model”, is updated “local parameters update to a shared prediction model . . . sending the local parameter updates to a central server for aggregation”, using data “the local parameter updates” from “up to 1000 clients”, which includes first and second data; see also Pg. 1, Abstract, “Federated Learning (FL) has emerged as a promising technique for edge devices to collaboratively learn a shared prediction model while keeping training data on device”).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine the updating an asset using first confidential data and updating another asset using second confidential data of Zhu with the updating the shared asset using the first data and updating the shared asset using the second data of Beutel in order to utilize Zhu’s method for training machine learning models (Zhu, Pg. 1, Col. 2, Para. 1, “there is an urgent demand for privacy-preserving techniques capable of supporting compute- and data-intensive (CDI) computing, such as training deep neural networks (DNNs) over an enormous amount of data” and Zhu, Pg. 11, Col. 2, Para. 1, “It can be observed that the HETEE throughput overhead is 12.34% for network inference and 9.87% for network training on average”) to perform scalable and collaborative model training in a manner that preserves data privacy (Beutel, Pg. 1, Abstract, “Federated Learning (FL) has emerged as a promising technique for edge devices to collaboratively learn a shared prediction model while keeping training data on device”; Beutel, Pg. 2, Col. 1, Para. 3, “We present Flower, a novel FL framework that supports scalable algorithmic research and implementation of FL methods on edge devices and servers”; and Beutel, Pg. 1, Col. 1-2, Para. 1-1, “Federated Learning (FL) (McMahan et al., 2017) is an emerging area of research in the machine learning community which aims to enable distributed edge devices (or users) to collaboratively train a shared prediction model while keeping their personal data private. At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates”; see also Beutel, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”, where the privacy preserving aspect of federated will allow for secure model training using “different users . . . across secure/insecure worlds”), which uses a system that is capable of simulating the effects of scale, data differences, and device heterogeneity (Beutel, Pg. 7, Col. 2, Para. 3, “To properly scale our experiment to these conditions and to simulate the fact that different clients will have different data, we have augmented the original CIFAR-10 training set from 50k to 500k samples using standard image augmentation techniques . . . The FL server and all the clients are hosted on virtual machines in a cloud platform”, where use of virtual machines hosted in a cloud platform allows for efficient and adjustable allocation of resources for the servers and clients, without the need for expensive hardware; see also Beutel, Pg. 1, Abstract, “We describe the design goals and architecture of Flower and use it to evaluate the impacts of scale and heterogeneity on common FL methods in experiments with up to 1000 clients”) so as to be compatible across the heterogeneous computing environments disclosed by Zhu (compare Zhu, Pg. 1, Col. 1, Abstract, “This paper present HETEE (Heterogeneous TEE), the first design of TEE capable of strongly protecting heterogeneous computing with unsecure accelerators. HETEE is uniquely constructed to work with today’s servers, and does not require any changes for existing commercial CPUs or accelerators” with Beutel, Pg. 1, Abstract, “Flower is open source, supports heterogeneous environments including mobile and edge devices, and scales to a large number of distributed client”).
Regarding Claim 2, Zhu in view of Beutel teaches the method of claim 1, wherein the shared asset is a machine learning (ML) model (Zhu, Pg. 10, Col. 1, Para. 2, “In the design of HETEE the states of accelerators are cleared upon mode switches and task switches. This reduces shared resources between the insecure world and secure world, as well as among tasks” and Zhu, Pg. 10, Col. 2, Para, 2, “In the HETEE design, software stack of accelerator needs to be run in the trusted OS on security controller . . . In our prototype system, the ARM Cortex A9 processor of the ZC706 runs a Linux kernel . . . After the ZC706 de- crypts and verifies the task sent from the host CPU, the data is transmitted back, and the GPU software stack including Tensorflow, CUDA library and GPU driver running on the host CPU are responsible for using the GPU”, where shared assets, “shared resources” as well as the underlying “software stack of the accelerator” and hardware components, are provided in the “the states of accelerators”, which, in view of Beutel, comprise a shared machine learning model, see Beutel, Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates”; see also Zhu, Pg. 7, Col. 1, Para. 1, “the remote user encrypts the command (i.e., AI model), packs the ciphertext into a command task . . . When the task manager detects a new data task, it dispatches the task to the corresponding process input buffers. After its data is processed by accelerator”),
wherein updating the shared asset using the first and second confidential data comprises training the ML model using the first and second confidential data (Zhu, Pg. 7, Col. 1, Para. 1, “After its data is processed by accelerator, the process places the computing result in the output buffer”, where the “the computing result” is generated using the “data”, which is first confidential data when “transmit[ted] sensitive data” from a first “remote user” of the plurality of “different users” and which is second confidential data when “transmit[ted] sensitive data” from a second “remote user” of the plurality of “different users”, see Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data . . . from a remote user” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Zhu, Pg. 1, Col. 2, Para. 1, “there is an urgent demand for privacy-preserving techniques capable of supporting compute- and data-intensive (CDI) computing, such as training deep neural networks (DNNs) over an enormous amount of data” and Zhu, Pg. 11, Col. 2, Para. 1, “It can be observed that the HETEE throughput overhead is 12.34% for network inference and 9.87% for network training on average”, where the using can be updating an asset, “network training”, and where, in view of Beutel, the updating of assets is updating a shared ML model asset by training the it using the first and second confidential data, see Beutel, Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates” and Beutel, Pg. 2, Col. 2, Para. 1, “Using Flower as the underlying framework, we present experiments that explore both algorithmic and system level aspects of FL on five machine learning workloads with up to 1000 clients”),
wherein the hardware accelerator includes one or more graphics processing units (GPUs) (Zhu, Pg. 1-2, Col. 2-2, Para. 3-4, “none of those TEEs can truly support CDI computing tasks, due to their exclusion of high-throughput accelerators such as graph-processing unit (GPU) . . . We present the first de- sign of TEE capable of protecting heterogeneous comput- ing, which enables different computing units (CPU, GPU, accelerators, etc.) to efficiently work together, without exposing a large attack surface to untrusted OS” and Zhu, Pg. 10, Col. 2, Table 2, “Heterogeneous units 4 GPUs (NVIDIA Tesla M40)”; see also Zhu, Pg. 1, Col. 1, Abstract, “accelerators like GPU”, where the hardware accelerator, “accelerators”, is discussed as including one or more graphics processing units (GPUs), “GPU”).
The reasons for obviousness were discussed in regard to the rejection of claim 1 above and remain applicable here.
Regarding Claim 3, Zhu in view of Beutel teaches the method of claim 1, wherein the shared asset is a statistical parameter (Zhu, Pg. 10, Col. 1, Para. 2, “In the design of HETEE the states of accelerators are cleared upon mode switches and task switches. This reduces shared resources between the insecure world and secure world, as well as among tasks” and Zhu, Pg. 10, Col. 2, Para, 2, “In the HETEE design, software stack of accelerator needs to be run in the trusted OS on security controller . . . In our prototype system, the ARM Cortex A9 processor of the ZC706 runs a Linux kernel . . . After the ZC706 de- crypts and verifies the task sent from the host CPU, the data is transmitted back, and the GPU software stack including Tensorflow, CUDA library and GPU driver running on the host CPU are responsible for using the GPU”, where shared assets, “shared resources” as well as the underlying “software stack of the accelerator” and hardware components, are provided in the “the states of accelerators”, which, in view of Beutel, comprise a statistical parameter, “local parameter updates . . . for aggregation” as a statistical “average”, see Beutel, Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates” and Beutel, Pg. 14, Col. 2, Para. 1, “The server then averages all successful θ k∈{0,..,K} updates, weighted by mk, the number of training examples on client k”; see also Zhu, Pg. 7, Col. 1, Para. 1, “the remote user encrypts the command (i.e., AI model), packs the ciphertext into a command task . . . When the task manager detects a new data task, it dispatches the task to the corresponding process input buffers. After its data is processed by accelerator”),
wherein updating the shared asset using the first and second confidential data comprises updating a value of the statistical parameter using the first and second confidential data (Zhu, Pg. 7, Col. 1, Para. 1, “After its data is processed by accelerator, the process places the computing result in the output buffer”, where the “the computing result” is generated using the “data”, which is first confidential data when “transmit[ted] sensitive data” from a first “remote user” of the plurality of “different users” and which is second confidential data when “transmit[ted] sensitive data” from a second “remote user” of the plurality of “different users”, see Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data . . . from a remote user” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Zhu, Pg. 1, Col. 2, Para. 1, “there is an urgent demand for privacy-preserving techniques capable of supporting compute- and data-intensive (CDI) computing, such as training deep neural networks (DNNs) over an enormous amount of data” and Zhu, Pg. 11, Col. 2, Para. 1, “It can be observed that the HETEE throughput overhead is 12.34% for network inference and 9.87% for network training on average”, where the using can be updating an asset, “network training”, and where, in view of Beutel, the updating of assets is updating a value, one of the “average[d] all successful θ k∈{0,..,K} updates, weighted by mk”, of the statistical parameter, “the aggregated model”, using the first and second confidential data, see Beutel, Pg. 14, Col. 2, Para. 1, “The server then averages all successful θ k∈{0,..,K} updates, weighted by mk, the number of training examples on client k” and Beutel, Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates”).
The reasons for obviousness were discussed in regard to the rejection of claim 1 above and remain applicable here.
Regarding Claim 4, Zhu in view of Beutel teaches the method of claim 1, wherein the first and second data holders comprise respective confidential virtual machines (VMs) (Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”, where, as discussed above, the plurality of “different users” requires at least a first and second data holder, which, in view of Beutel comprise respective confidential, see Beutel, Pg. 1, Col. 1, Para. 1, “Federated Learning (FL) (McMahan et al., 2017) is an emerging area of research in the machine learning community which aims to enable distributed edge devices (or users) to collaboratively train a shared prediction model while keeping their personal data private”, virtual machines, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”).
The reasons for obviousness were discussed in regard to the rejection of claim 1 above and remain applicable here.
Regarding Claim 9, Zhu in view of Beutel teaches a collaborative learning system, comprising (Zhu, Pg. 1, Col. 1, Abstract, “We have implemented the HETEE design on a hardware prototype system, and evaluated it with large-scale Neural Net- works inference and training tasks”, where a learning system, “system” for “training”, is disclosed, which, in view of Beutel is collaborative, see Beutel, Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates”):
a hardware accelerator comprising a shared asset (Zhu, Pg. 10, Col. 1, Para. 2, “In the design of HETEE the states of accelerators are cleared upon mode switches and task switches. This reduces shared resources between the insecure world and secure world, as well as among tasks” and Zhu, Pg. 10, Col. 2, Para, 2, “In the HETEE design, software stack of accelerator needs to be run in the trusted OS on security controller . . . In our prototype system, the ARM Cortex A9 processor of the ZC706 runs a Linux kernel . . . After the ZC706 de- crypts and verifies the task sent from the host CPU, the data is transmitted back, and the GPU software stack including Tensorflow, CUDA library and GPU driver running on the host CPU are responsible for using the GPU”, where shared assets, “shared resources” as well as the underlying “software stack of the accelerator” and hardware components, are comprised in the “the states of accelerators”, which are hardware accelerators, see Zhu, Pg. 2, Col. 2, Para. 1, “All the computing units, like GPUs, AI accelerators, etc., are shared between the OS and the security controller”; Zhu, Pg. 1, Col. 2, Para. 3, “high-throughput accelerators such as graph-processing unit (GPU), tensor-processing unit (TPU), field-programmable gate array (FPGA, for building custom accelerators) etc.”; and Zhu, Pg. 10, Col. 1, Para. 1, “It only needs to support limited hardware accelerators”; see also Zhu, Pg. 7, Col. 1, Para. 1, “the remote user encrypts the command (i.e., AI model), packs the ciphertext into a command task, and put it into the task queue. The task manager fetches ciphertexts from the task queue, verifies the integrity of the messages, then decrypts and parses them. If the parsed task is a command, task manager will initiate a corresponding process (i.e.,Tensorflow program) to execute the command. At the same time, input and output buffers are created for the process. When the task manager detects a new data task, it dispatches the task to the corresponding process input buffers. After its data is processed by accelerator”, where an asset, “the command (i.e., AI model) . . . [and] the computing result”, is provided in an “accelerator”, “When the task manager detects a new data task, it dispatches the task to the corresponding process input buffers. After its data is processed by accelerator, the process places the computing result in the output buffer”, which, in view of which, in view of Beutel is shared, see Beutel, Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates”);
a first VM for a first data holder (Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”, where the plurality of “different users” requires a first data holder, which, in view of Beutel has a first WM for it, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”);
a second VM for a second data holder (Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”, where the plurality of “different users” requires a second data holder, which, in view of Beutel has a second WM for it, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”);
and a third orchestrator VM configured to (Zhu, Pg. 5, Col. 1, Para. 2, “At the center of the design is a trusted security controller unit that manages a set of PCIe switches attached to a host server” and Zhu, Pg. 6, Fig. 2, where the “security controller” and “host server” are collectively within the broadest reasonable interpretation of an orchestrator because they perform and effect “manage[ment]”, which, in view of Beutel is a server WM, which is the third VM, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”; see also Zhu, Pg. 1, Col. 1, Abstract, “HETEE is uniquely constructed to work with today’s servers, and does not require any changes for existing commercial CPUs or accelerators. The key idea of our design runs security controller as a stand-alone computing system to dynamically adjust the boundary of between secure and insecure worlds through the PCIe switches, rendering the control of an accelerator to the host OS when it is not needed for secure computing, and shifting it back when it is. The controller is the only trust unit in the system and it runs the custom OS and accelerator runtimes, together with the encryption, authentication and remote attestation components”):
couple the hardware accelerator to the first VM, wherein the first VM is configured to upload first confidential data into the hardware accelerator (Zhu, Pg. 7, Col. 2, Para. 3, “When a user needs to utilize the accelerator resource, a request is sent to the security controller, which dynamically allocates a certain amount of accelerator resources to the user”; Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data. These data may be encrypted inside the CPU TEE, or placed directly on the host hard disk in the encrypted form, or come from a remote user”; and Zhu, Pg. 7, Col. 1, Para. 2, “First, the process initializes accelerators and allocates device buffers for data. Then, the process loads new data from the input buffer, and moving them into the memory space of the accelerator. Then, the computing kernel is launched. After the execution, the result is copied from the accelerators to the output buffer”, where the hardware accelerator is coupled to a data holder, “dynamically allocates a certain amount of accelerator resources to the user”, and confidential data is uploaded, “transmit sensitive data”, from the configured data holder, “from a remote user”, into the hardware accelerator, “the process loads new data from the input buffer, and moving them into the memory space of the accelerator”, and where the plurality of “different users” requires a first data holder, such that its associated confidential data is first confidential data, see Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”, and where, in view of Beutel the first data holder has a first VM for it, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”);
update the shared asset using the first confidential data (Zhu, Pg. 7, Col. 1, Para. 1, “After its data is processed by accelerator, the process places the computing result in the output buffer”, where the “the computing result” is generated using the “data”, which is first confidential data when “transmit[ted] sensitive data” from a first “remote user” of the plurality of “different users”, see Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data . . . from a remote user” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Zhu, Pg. 1, Col. 2, Para. 1, “there is an urgent demand for privacy-preserving techniques capable of supporting compute- and data-intensive (CDI) computing, such as training deep neural networks (DNNs) over an enormous amount of data” and Zhu, Pg. 11, Col. 2, Para. 1, “It can be observed that the HETEE throughput overhead is 12.34% for network inference and 9.87% for network training on average”, where the using can be updating an asset, “network training”, and where, in view of Beutel, the updating of assets is updating a shared asset using the first confidential data, see Beutel, Pg. 14, Col. 2, Para. 1, “The server then averages all successful θ k∈{0,..,K} updates, weighted by mk, the number of training examples on client k” and Beutel, Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates”);
delete the first confidential data from the hardware accelerator (Zhu, Pg. 2, Col. 2, Para. 2, “Our solution leverages the unique features of today’s GPU and accelerator designs . . . they can be “reset” to a trusted status by simply cleaning up all their internal storage . . . HETEE either utilizes its “hot reset” function to restore it to the clean status or runs a program to wipe out all its storage content”; Zhu, Pg. 4, Col. 2, Para. 2, “we consider that the under the fundamental reset or cold reboot, the firmware on an accelerator (such as GPU) can ensure that all micro-architecture statuses, including those of caches and memory, are cleared”; and Zhu, Pg. 10, Col. 1, Para. 2, “In the design of HETEE the states of accelerators are cleared upon mode switches and task switches. This reduces shared resources between the insecure world and secure world, as well as among tasks”, where data is deleted from the hardware accelerator, “wipe out all its storage content” such that “the states of accelerators are cleared” to “ensure that all micro-architecture statuses, including those of caches and memory, are cleared”, which is first confidential data when “transmit[ted] sensitive data” from a first “remote user”, see Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data . . . from a remote user” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Zhu, Pg. 7, Col. 1, Para. 1, “Finally, the task manager destroys the task queues and terminates the process”);
couple the hardware accelerator to the second VM, wherein the first VM is no longer able to communicate with the hardware accelerator, and wherein the second VM is configured to upload second confidential data into the hardware accelerator (Zhu, Pg. 7, Col. 2, Para. 3, “When a user needs to utilize the accelerator resource, a request is sent to the security controller, which dynamically allocates a certain amount of accelerator resources to the user”; Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data. These data may be encrypted inside the CPU TEE, or placed directly on the host hard disk in the encrypted form, or come from a remote user”; and Zhu, Pg. 7, Col. 1, Para. 2, “First, the process initializes accelerators and allocates device buffers for data. Then, the process loads new data from the input buffer, and moving them into the memory space of the accelerator. Then, the computing kernel is launched. After the execution, the result is copied from the accelerators to the output buffer”, where the hardware accelerator is coupled to a data holder, “dynamically allocates a certain amount of accelerator resources to the user”, and confidential data is uploaded, “transmit sensitive data”, from the configured data holder, “from a remote user”, into the hardware accelerator, “the process loads new data from the input buffer, and moving them into the memory space of the accelerator”, and where the plurality of “different users” requires a second data holder, such that its associated confidential data is second confidential data, see Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Zhu, Pg. 7, Col. 2, Para. 3, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them. Coupled with our context cleaning mechanism, such a design can minimize side-channel leakages across tasks” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds. By dynamically configuring the Express Fabric chip, an accelerator can be physically assigned to the host or the security controller on-demand, thus enabling the switching of the accelerator security mode. With this feature, HETEE dynamically defines the boundary of the secure world. To avoid the security risks from the data and code on the accelerator switched between different worlds, HETEE utilizes context clearance to restore the device to a trusted state”, where the coupling can be to the same hardware accelerator, “it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds . . . an accelerator can be physically assigned to the host or the security controller on-demand, thus enabling the switching of the accelerator security mode”, which occurs when the first data holder is no longer able to communicate with the hardware accelerator, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them”, and where, in view of Beutel the first data holder has a first VM for it and the second data holder has a second VM for it, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”); and
update the shared asset using the second confidential data (Zhu, Pg. 7, Col. 1, Para. 1, “After its data is processed by accelerator, the process places the computing result in the output buffer”, where the “the computing result” is generated using the “data”, which is second confidential data when “transmit[ted] sensitive data” from a second “remote user” of the plurality of “different users”, see Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data . . . from a remote user” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Zhu, Pg. 1, Col. 2, Para. 1, “there is an urgent demand for privacy-preserving techniques capable of supporting compute- and data-intensive (CDI) computing, such as training deep neural networks (DNNs) over an enormous amount of data” and Zhu, Pg. 11, Col. 2, Para. 1, “It can be observed that the HETEE throughput overhead is 12.34% for network inference and 9.87% for network training on average”, where the using can be updating an asset, “network training”, and where, in view of Beutel, the updating of assets is updating a shared asset using the second confidential data, see Beutel, Pg. 14, Col. 2, Para. 1, “The server then averages all successful θ k∈{0,..,K} updates, weighted by mk, the number of training examples on client k” and Beutel, Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates”).
The reasons for obviousness were discussed in regard to the rejection of claim 1 above and remain applicable here.
Regarding Claim 10, the additional elements of the dependent claim are substantially the same as the limitations of claim 2, therefore it is rejected under the same rationale.
Regarding Claim 11, the additional elements of the dependent claim are substantially the same as the limitations of claim 3, therefore it is rejected under the same rationale.
Regarding Claim 15, Zhu in view of Beutel teaches the collaborative learning system of claim 9, wherein the orchestrator VM is configured to establish a collaborative learning environment to update respective shared assets on one or more respective hardware accelerators for multiple groups of data holders (Zhu, Pg. 5, Col. 1, Para. 2, “At the center of the design is a trusted security controller unit that manages a set of PCIe switches attached to a host server”; Zhu, Pg. 6, Fig. 2; Zhu, Pg. 7, Col. 2, Para. 3, “When a user needs to utilize the accelerator resource, a request is sent to the security controller, which dynamically allocates a certain amount of accelerator resources to the user”; Zhu, Pg. 11, Col. 2, Para. 1, “It can be observed that the HETEE throughput overhead is 12.34% for network inference and 9.87% for network training on average”; and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”, where the “security controller” and “host server” are collectively within the broadest reasonable interpretation of an orchestrator because they perform and effect “manage[ment]”, which is configured to establish a learning environment to update respective assets on one or more respective hardware accelerators, “the security controller, which dynamically allocates a certain amount of accelerator resources to the user” for “network training”, for multiple groups of data holders, “different users . . . across secure/insecure worlds”, which, in view of Beutel, the orchestrator is a VM, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”, and the learning environment is a collaborative learning environment to update shared assets, see Beutel, Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates” and Beutel, Pg. 2, Col. 2, Para. 1, “Using Flower as the underlying framework, we present experiments that explore both algorithmic and system level aspects of FL on five machine learning workloads with up to 1000 clients”),
wherein the orchestrator VM enables each of the respective hardware accelerators to travel to each data holder in a corresponding one of the multiple groups (Zhu, Pg. 6, Fig. 2; Zhu, Pg. 7, Col. 2, Para. 3, “When a user needs to utilize the accelerator resource, a request is sent to the security controller, which dynamically allocates a certain amount of accelerator resources to the user”; and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”, wherein the orchestrator enables each of the respective hardware accelerators to travel to each data holder, “the security controller, which dynamically allocates a certain amount of accelerator resources to the user”, in a corresponding one of the multiple groups, “different users . . . across secure/insecure worlds”, which, in view of Beutel, the orchestrator is a VM, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”).
The reasons for obviousness were discussed in regard to the rejection of claim 1 above and remain applicable here.
Regarding Claim 16, Zhu teaches a computer program product comprising: one or more computer readable storage media; and program instructions stored on the one or more storage media to perform operations comprising: . . . (Pg. 14, Col. 1, Para. 1, “We partially implemented HETEE on the prototype system which is a X86 host system connected with Xilinx Zynq FPGA (acting as the security controller) and NVIDIA GPUs over PCIe fabric, and evaluated it with large-scale Neural Networks inference tasks”, where a person of ordinary skill in the art would understand that “implement[ing] HETEE on the prototype system which is a X86 host system connected with Xilinx Zynq FPGA . . . and NVIDIA GPUs over PCIe fabric, and evaluated it with large-scale Neural Networks inference tasks” requires a computer program product, “implement[ing] HETEE on the prototype system which is a X86 host system connected with Xilinx Zynq FPGA . . . and NVIDIA GPUs”, comprising: one or more computer readable storage media; and program instructions stored on the one or more storage media, see Pg. 1, Col. 1, Abstract, “The host server and other computing systems communicate with controller through an in-memory task queue that accommodates the computing tasks offloaded to HETEE, in the form of encrypted and signed code and data”, to perform operations, “large-scale Neural Networks inference tasks”; see also Pg. 3, Col. 2, Para. 3, “Code, data and runtime states should not have been observable by unauthorized applications. This is achieved, e.g. by encrypting the code or data that reside in the memory”; Pg. 6, Col. 2, Fig. 3, “Example pseudo code to use HETEE”; and Pg. 6, Fig. 5).
The remaining limitations are substantially the same as limitations of claim 1, therefore it is rejected under the same rationale.
Regarding Claim 17, the additional elements of the dependent claim are substantially the same as the limitations of claim 2, therefore it is rejected under the same rationale.
Regarding Claim 18, the additional elements of the dependent claim are substantially the same as the limitations of claim 3, therefore it is rejected under the same rationale.
Regarding Claim 21, Zhu in view of Beutel teaches a hardware accelerator comprising: circuitry (Zhu, Pg. 2, Col. 2, Para. 1, “All the computing units, like GPUs, AI accelerators, etc., are shared between the OS and the security controller”; Zhu, Pg. 1, Col. 2, Para. 3, “high-throughput accelerators such as graph-processing unit (GPU), tensor-processing unit (TPU), field-programmable gate array (FPGA, for building custom accelerators) etc.”; and Zhu, Pg. 10, Col. 1, Para. 1, “It only needs to support limited hardware accelerators”, where a “hardware accelerator” comprises circuitry, “high-throughput accelerators such as graph-processing unit (GPU), tensor-processing unit (TPU), field-programmable gate array (FPGA, for building custom accelerators) etc.”)
configured to: receive first confidential data from a first virtual machine (VM) (Zhu, Pg. 7, Col. 2, Para. 3, “When a user needs to utilize the accelerator resource, a request is sent to the security controller, which dynamically allocates a certain amount of accelerator resources to the user”; Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data. These data may be encrypted inside the CPU TEE, or placed directly on the host hard disk in the encrypted form, or come from a remote user”; and Zhu, Pg. 7, Col. 1, Para. 2, “First, the process initializes accelerators and allocates device buffers for data. Then, the process loads new data from the input buffer, and moving them into the memory space of the accelerator. Then, the computing kernel is launched. After the execution, the result is copied from the accelerators to the output buffer”, where the hardware accelerator is coupled to a data holder, “dynamically allocates a certain amount of accelerator resources to the user”, and configured to receive confidential data, “transmit sensitive data”, from the data holder, “from a remote user”, into the hardware accelerator, “the process loads new data from the input buffer, and moving them into the memory space of the accelerator”, and where the plurality of “different users” requires a first data holder, such that its associated confidential data is first confidential data, see Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”, which, in view of Beutel, the first data holder is a first virtual machine, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”);
update a shared asset using the first confidential data (Zhu, Pg. 7, Col. 1, Para. 1, “After its data is processed by accelerator, the process places the computing result in the output buffer”, where the “the computing result” is generated using the “data”, which is first confidential data when “transmit[ted] sensitive data” from a first “remote user” of the plurality of “different users”, see Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data . . . from a remote user” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Zhu, Pg. 1, Col. 2, Para. 1, “there is an urgent demand for privacy-preserving techniques capable of supporting compute- and data-intensive (CDI) computing, such as training deep neural networks (DNNs) over an enormous amount of data” and Zhu, Pg. 11, Col. 2, Para. 1, “It can be observed that the HETEE throughput overhead is 12.34% for network inference and 9.87% for network training on average”, where the using can be updating an asset, “network training”, and where, in view of Beutel, the updating of assets is updating a shared asset using the first confidential data, see Beutel, Pg. 14, Col. 2, Para. 1, “The server then averages all successful θ k∈{0,..,K} updates, weighted by mk, the number of training examples on client k” and Beutel, Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates”);
delete the first confidential data from the hardware accelerator (Zhu, Pg. 2, Col. 2, Para. 2, “Our solution leverages the unique features of today’s GPU and accelerator designs . . . they can be “reset” to a trusted status by simply cleaning up all their internal storage . . . HETEE either utilizes its “hot reset” function to restore it to the clean status or runs a program to wipe out all its storage content”; Zhu, Pg. 4, Col. 2, Para. 2, “we consider that the under the fundamental reset or cold reboot, the firmware on an accelerator (such as GPU) can ensure that all micro-architecture statuses, including those of caches and memory, are cleared”; and Zhu, Pg. 10, Col. 1, Para. 2, “In the design of HETEE the states of accelerators are cleared upon mode switches and task switches. This reduces shared resources between the insecure world and secure world, as well as among tasks”, where data is deleted from the hardware accelerator, “wipe out all its storage content” such that “the states of accelerators are cleared” to “ensure that all micro-architecture statuses, including those of caches and memory, are cleared”, which is first confidential data when “transmit[ted] sensitive data” from a first “remote user”, see Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data . . . from a remote user” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Zhu, Pg. 7, Col. 1, Para. 1, “Finally, the task manager destroys the task queues and terminates the process”);
receive, after deleting the first confidential data, second confidential data from a second VM, wherein the first VM is no longer able to communicate with the hardware accelerator (Zhu, Pg. 7, Col. 2, Para. 3, “When a user needs to utilize the accelerator resource, a request is sent to the security controller, which dynamically allocates a certain amount of accelerator resources to the user”; Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data. These data may be encrypted inside the CPU TEE, or placed directly on the host hard disk in the encrypted form, or come from a remote user”; and Zhu, Pg. 7, Col. 1, Para. 2, “First, the process initializes accelerators and allocates device buffers for data. Then, the process loads new data from the input buffer, and moving them into the memory space of the accelerator. Then, the computing kernel is launched. After the execution, the result is copied from the accelerators to the output buffer”, where the hardware accelerator is coupled to a data holder, “dynamically allocates a certain amount of accelerator resources to the user”, and confidential data is received, “transmit sensitive data”, from the data holder, “from a remote user”, into the hardware accelerator, “the process loads new data from the input buffer, and moving them into the memory space of the accelerator”, and where the plurality of “different users” requires a second data holder, such that its associated confidential data is second confidential data, see Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”, and, which, in view of Beutel, the second data holder is a second virtual machine, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”; see also Zhu, Pg. 7, Col. 2, Para. 3, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them. Coupled with our context cleaning mechanism, such a design can minimize side-channel leakages across tasks” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds. By dynamically configuring the Express Fabric chip, an accelerator can be physically assigned to the host or the security controller on-demand, thus enabling the switching of the accelerator security mode. With this feature, HETEE dynamically defines the boundary of the secure world. To avoid the security risks from the data and code on the accelerator switched between different worlds, HETEE utilizes context clearance to restore the device to a trusted state”, where the coupling can be to the same hardware accelerator, “it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds . . . an accelerator can be physically assigned to the host or the security controller on-demand, thus enabling the switching of the accelerator security mode”, which occurs when the first VM is no longer able to communicate with the hardware accelerator, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them”, and the receiving occurs after the deleting the first confidential data to “minimize side-channel leakages across tasks”, see Zhu, Pg. 7, Col. 2, Para. 3, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them. Coupled with our context cleaning mechanism, such a design can minimize side-channel leakages across tasks”; see also Zhu, Pg. 2, Col. 2, Para. 2, “Our solution leverages the unique features of today’s GPU and accelerator designs . . . they can be “reset” to a trusted status by simply cleaning up all their internal storage . . . HETEE either utilizes its “hot reset” function to restore it to the clean status or runs a program to wipe out all its storage content”; Zhu, Pg. 4, Col. 2, Para. 2, “we consider that the under the fundamental reset or cold reboot, the firmware on an accelerator (such as GPU) can ensure that all micro-architecture statuses, including those of caches and memory, are cleared”; and Zhu, Pg. 10, Col. 1, Para. 2, “In the design of HETEE the states of accelerators are cleared upon mode switches and task switches. This reduces shared resources between the insecure world and secure world, as well as among tasks”, where data is deleted from the hardware accelerator, “wipe out all its storage content” such that “the states of accelerators are cleared” to “ensure that all micro-architecture statuses, including those of caches and memory, are cleared”, which is first confidential data when “transmit[ted] sensitive data” from a first “remote user”, see Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data . . . from a remote user” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Zhu, Pg. 7, Col. 1, Para. 1, “Finally, the task manager destroys the task queues and terminates the process”); and
update the shared asset using the second confidential data (Zhu, Pg. 7, Col. 1, Para. 1, “After its data is processed by accelerator, the process places the computing result in the output buffer”, where the “the computing result” is generated using the “data”, which is second confidential data when “transmit[ted] sensitive data” from a second “remote user” of the plurality of “different users”, see Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data . . . from a remote user” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Zhu, Pg. 1, Col. 2, Para. 1, “there is an urgent demand for privacy-preserving techniques capable of supporting compute- and data-intensive (CDI) computing, such as training deep neural networks (DNNs) over an enormous amount of data” and Zhu, Pg. 11, Col. 2, Para. 1, “It can be observed that the HETEE throughput overhead is 12.34% for network inference and 9.87% for network training on average”, where the using can be updating an asset, “network training”, and where, in view of Beutel, the updating of assets is updating a shared asset using the second confidential data, see Beutel, Pg. 14, Col. 2, Para. 1, “The server then averages all successful θ k∈{0,..,K} updates, weighted by mk, the number of training examples on client k” and Beutel, Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates”).
The reasons for obviousness were discussed in regard to the rejection of claim 1 above and remain applicable here.
Regarding Claim 22, the additional elements of the dependent claim are substantially the same as the limitations of claim 2, therefore it is rejected under the same rationale.
Regarding Claim 23, Zhu in view of Beutel teaches the hardware accelerator of claim 21, wherein the hardware accelerator is confidential computing (CC) enabled such that keys are used to encrypt data transmitted to the hardware accelerator from the first and second VMs (Zhu, Pg. 5, Col. 1-2, Para. 5-1, “A remote user uses the remote attestation to verify the security of an accelerator. The main part of an offloading application runs on the CPU. It accepts the protection of a CPU TEE (e.g. Intel SGX), or its sensitive code and data exists in encrypted form. When the application needs to use an accelerator, it writes the code and data according to the agreed programming model, and sends these key data and task instructions to the security controller in ciphertext”; Zhu, Pg. 6, Col. 1, Para. 1, “Hardware acceleration engine for encryption and decryption and hash algorithms are expected”; Zhu, Pg. 7, Col. 1, Para. 2, “First, the process initializes accelerators and allocates device buffers for data. Then, the process loads new data from the input buffer, and moving them into the memory space of the accelerator. Then, the computing kernel is launched. After the execution, the result is copied from the accelerators to the output buffer”; and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”, where the hardware accelerator, “accelerator”, is confidential computing (CC) enabled such that keys are used to encrypt data transmitted, “its sensitive code and data exists in encrypted form . . . and sends these key data and task instructions to the security controller in ciphertext”, to the hardware accelerator, “the process loads new data from the input buffer, and moving them into the memory space of the accelerator”, from the first and second data holders of the plurality of “different users”, which, in view of Beutel, are the first and second VMs, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”).
The reasons for obviousness were discussed in regard to the rejection of claim 1 above and remain applicable here.
Regarding Claim 24, Zhu in view of Beutel teaches a computer program product comprising: one or more computer readable storage media; and program instructions stored on the one or more storage media to perform operations comprising (Zhu, Pg. 14, Col. 1, Para. 1, “We partially implemented HETEE on the prototype system which is a X86 host system connected with Xilinx Zynq FPGA (acting as the security controller) and NVIDIA GPUs over PCIe fabric, and evaluated it with large-scale Neural Networks inference tasks”, where a person of ordinary skill in the art would understand that “implement[ing] HETEE on the prototype system which is a X86 host system connected with Xilinx Zynq FPGA . . . and NVIDIA GPUs over PCIe fabric, and evaluated it with large-scale Neural Networks inference tasks” requires a computer program product, “implement[ing] HETEE on the prototype system which is a X86 host system connected with Xilinx Zynq FPGA . . . and NVIDIA GPUs”, comprising: one or more computer readable storage media; and program instructions stored on the one or more storage media, see Zhu, Pg. 1, Col. 1, Abstract, “The host server and other computing systems communicate with controller through an in-memory task queue that accommodates the computing tasks offloaded to HETEE, in the form of encrypted and signed code and data”, to perform operations, “large-scale Neural Networks inference tasks”; see also Zhu, Pg. 3, Col. 2, Para. 3, “Code, data and runtime states should not have been observable by unauthorized applications. This is achieved, e.g. by encrypting the code or data that reside in the memory”; Zhu, Pg. 6, Col. 2, Fig. 3, “Example pseudo code to use HETEE”; and Zhu, Pg. 6, Fig. 5):
providing a shared asset in a hardware accelerator (Zhu, Pg. 10, Col. 1, Para. 2, “In the design of HETEE the states of accelerators are cleared upon mode switches and task switches. This reduces shared resources between the insecure world and secure world, as well as among tasks” and Zhu, Pg. 10, Col. 2, Para, 2, “In the HETEE design, software stack of accelerator needs to be run in the trusted OS on security controller . . . In our prototype system, the ARM Cortex A9 processor of the ZC706 runs a Linux kernel . . . After the ZC706 de- crypts and verifies the task sent from the host CPU, the data is transmitted back, and the GPU software stack including Tensorflow, CUDA library and GPU driver running on the host CPU are responsible for using the GPU”, where shared assets, “shared resources” as well as the underlying “software stack of the accelerator” and hardware components, are provided in the “the states of accelerators”, which are hardware accelerators, see Zhu, Pg. 2, Col. 2, Para. 1, “All the computing units, like GPUs, AI accelerators, etc., are shared between the OS and the security controller”; Zhu, Pg. 1, Col. 2, Para. 3, “high-throughput accelerators such as graph-processing unit (GPU), tensor-processing unit (TPU), field-programmable gate array (FPGA, for building custom accelerators) etc.”; and Zhu, Pg. 10, Col. 1, Para. 1, “It only needs to support limited hardware accelerators”; see also Zhu, Pg. 7, Col. 1, Para. 1, “the remote user encrypts the command (i.e., AI model), packs the ciphertext into a command task, and put it into the task queue. The task manager fetches ciphertexts from the task queue, verifies the integrity of the messages, then decrypts and parses them. If the parsed task is a command, task manager will initiate a corresponding process (i.e.,Tensorflow program) to execute the command. At the same time, input and output buffers are created for the process. When the task manager detects a new data task, it dispatches the task to the corresponding process input buffers. After its data is processed by accelerator”, where an asset, “the command (i.e., AI model) . . . [and] the computing result”, is provided in an “accelerator”, “When the task manager detects a new data task, it dispatches the task to the corresponding process input buffers. After its data is processed by accelerator, the process places the computing result in the output buffer”; see also Beutel, Pg. 14, Col. 2, Para. 1, “The server then averages all successful θ k∈{0,..,K} updates, weighted by mk, the number of training examples on client k” and Beutel, Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates”);
coupling the hardware accelerator to a first data holder such that the first data holder uploads first confidential data into the hardware accelerator (Zhu, Pg. 7, Col. 2, Para. 3, “When a user needs to utilize the accelerator resource, a request is sent to the security controller, which dynamically allocates a certain amount of accelerator resources to the user”; Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data. These data may be encrypted inside the CPU TEE, or placed directly on the host hard disk in the encrypted form, or come from a remote user”; and Zhu, Pg. 7, Col. 1, Para. 2, “First, the process initializes accelerators and allocates device buffers for data. Then, the process loads new data from the input buffer, and moving them into the memory space of the accelerator. Then, the computing kernel is launched. After the execution, the result is copied from the accelerators to the output buffer”, where the hardware accelerator is coupled to a data holder, “dynamically allocates a certain amount of accelerator resources to the user”, and confidential data is uploaded, “transmit sensitive data”, from the data holder, “from a remote user”, into the hardware accelerator, “the process loads new data from the input buffer, and moving them into the memory space of the accelerator”, and where the plurality of “different users” requires a first data holder, such that its associated confidential data is first confidential data, see Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”),
wherein the hardware accelerator deletes the first confidential data after updating the shared asset using the first confidential data (Zhu, Pg. 2, Col. 2, Para. 2, “Our solution leverages the unique features of today’s GPU and accelerator designs . . . they can be “reset” to a trusted status by simply cleaning up all their internal storage . . . HETEE either utilizes its “hot reset” function to restore it to the clean status or runs a program to wipe out all its storage content”; Zhu, Pg. 4, Col. 2, Para. 2, “we consider that the under the fundamental reset or cold reboot, the firmware on an accelerator (such as GPU) can ensure that all micro-architecture statuses, including those of caches and memory, are cleared”; and Zhu, Pg. 10, Col. 1, Para. 2, “In the design of HETEE the states of accelerators are cleared upon mode switches and task switches. This reduces shared resources between the insecure world and secure world, as well as among tasks”, wherein the hardware accelerator deletes data, “wipe out all its storage content” such that “the states of accelerators are cleared” to “ensure that all micro-architecture statuses, including those of caches and memory, are cleared”, which is first confidential data when “transmit[ted] sensitive data” from a first “remote user”, see Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data . . . from a remote user” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Zhu, Pg. 7, Col. 1, Para. 1, “Finally, the task manager destroys the task queues and terminates the process”; Zhu, Pg. 7, Col. 1, Para. 1, “After its data is processed by accelerator, the process places the computing result in the output buffer”, where the deleting occurs after, “Finally” “After”, the “the computing result” is generated using the “data”, which is first confidential data when “transmit[ted] sensitive data” from a first “remote user”, see Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data . . . from a remote user” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Zhu, Pg. 1, Col. 2, Para. 1, “there is an urgent demand for privacy-preserving techniques capable of supporting compute- and data-intensive (CDI) computing, such as training deep neural networks (DNNs) over an enormous amount of data” and Zhu, Pg. 11, Col. 2, Para. 1, “It can be observed that the HETEE throughput overhead is 12.34% for network inference and 9.87% for network training on average”, where the using can be updating an asset, “network training”, and where, in view of Beutel, the updating of assets is updating a shared ML model asset by training the it using the first and second confidential data, see Beutel, Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates” and Beutel, Pg. 2, Col. 2, Para. 1, “Using Flower as the underlying framework, we present experiments that explore both algorithmic and system level aspects of FL on five machine learning workloads with up to 1000 clients”);
ensuring the first data holder can no longer communicate with the hardware accelerator; and coupling the hardware accelerator to a second data holder such that the second data holder uploads second confidential data into the hardware accelerator (Zhu, Pg. 7, Col. 2, Para. 3, “When a user needs to utilize the accelerator resource, a request is sent to the security controller, which dynamically allocates a certain amount of accelerator resources to the user”; Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data. These data may be encrypted inside the CPU TEE, or placed directly on the host hard disk in the encrypted form, or come from a remote user”; and Zhu, Pg. 7, Col. 1, Para. 2, “First, the process initializes accelerators and allocates device buffers for data. Then, the process loads new data from the input buffer, and moving them into the memory space of the accelerator. Then, the computing kernel is launched. After the execution, the result is copied from the accelerators to the output buffer”, where the hardware accelerator is coupled to a data holder, “dynamically allocates a certain amount of accelerator resources to the user”, and confidential data is uploaded, “transmit sensitive data”, from the data holder, “from a remote user”, into the hardware accelerator, “the process loads new data from the input buffer, and moving them into the memory space of the accelerator”, and where the plurality of “different users” requires a second data holder, such that its associated confidential data is second confidential data, see Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Zhu, Pg. 7, Col. 2, Para. 3, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them. Coupled with our context cleaning mechanism, such a design can minimize side-channel leakages across tasks” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds. By dynamically configuring the Express Fabric chip, an accelerator can be physically assigned to the host or the security controller on-demand, thus enabling the switching of the accelerator security mode. With this feature, HETEE dynamically defines the boundary of the secure world. To avoid the security risks from the data and code on the accelerator switched between different worlds, HETEE utilizes context clearance to restore the device to a trusted state”, where the coupling can be to the same hardware accelerator, “it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds . . . an accelerator can be physically assigned to the host or the security controller on-demand, thus enabling the switching of the accelerator security mode”, which occurs when the first data holder is no longer able to communicate with the hardware accelerator, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them”),
wherein the hardware accelerator deletes the second confidential data after updating the shared asset using the second confidential data (Zhu, Pg. 2, Col. 2, Para. 2, “Our solution leverages the unique features of today’s GPU and accelerator designs . . . they can be “reset” to a trusted status by simply cleaning up all their internal storage . . . HETEE either utilizes its “hot reset” function to restore it to the clean status or runs a program to wipe out all its storage content”; Zhu, Pg. 4, Col. 2, Para. 2, “we consider that the under the fundamental reset or cold reboot, the firmware on an accelerator (such as GPU) can ensure that all micro-architecture statuses, including those of caches and memory, are cleared”; and Zhu, Pg. 10, Col. 1, Para. 2, “In the design of HETEE the states of accelerators are cleared upon mode switches and task switches. This reduces shared resources between the insecure world and secure world, as well as among tasks”, wherein the hardware accelerator deletes data, “wipe out all its storage content” such that “the states of accelerators are cleared” to “ensure that all micro-architecture statuses, including those of caches and memory, are cleared”, which is second confidential data when “transmit[ted] sensitive data” from a second “remote user”, see Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data . . . from a remote user” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Zhu, Pg. 7, Col. 1, Para. 1, “Finally, the task manager destroys the task queues and terminates the process”; Zhu, Pg. 7, Col. 1, Para. 1, “After its data is processed by accelerator, the process places the computing result in the output buffer”, where the deleting occurs after, “Finally” “After”, the “the computing result” is generated using the “data”, which is second confidential data when “transmit[ted] sensitive data” from a second “remote user”, see Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data . . . from a remote user” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Zhu, Pg. 1, Col. 2, Para. 1, “there is an urgent demand for privacy-preserving techniques capable of supporting compute- and data-intensive (CDI) computing, such as training deep neural networks (DNNs) over an enormous amount of data” and Zhu, Pg. 11, Col. 2, Para. 1, “It can be observed that the HETEE throughput overhead is 12.34% for network inference and 9.87% for network training on average”, where the using can be updating an asset, “network training”, and where, in view of Beutel, the updating of assets is updating a shared ML model asset by training it using the first and second confidential data, see Beutel, Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates” and Beutel, Pg. 2, Col. 2, Para. 1, “Using Flower as the underlying framework, we present experiments that explore both algorithmic and system level aspects of FL on five machine learning workloads with up to 1000 clients”).
The remaining limitations are substantially the same as limitations of claim 1, therefore it is rejected under the same rationale.
Regarding Claim 25, the additional elements of the dependent claim are substantially the same as the limitations of claim 2, therefore it is rejected under the same rationale.
Claims 5-8, 12-14, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Zhu in view of Beutel and López-Alt et al. (hereinafter López-Alt) (“On-the-Fly Multiparty Computation on the Cloud via Multikey Fully Homomorphic Encryption”).
Regarding Claim 5, Zhu in view of Beutel teaches the method of claim 1, further comprising, . . . updating the shared asset using the first confidential data (Zhu, Pg. 7, Col. 1, Para. 1, “After its data is processed by accelerator, the process places the computing result in the output buffer”, where the “the computing result” is generated using the “data”, which is first confidential data when “transmit[ted] sensitive data” from a first “remote user” of the plurality of “different users”, see Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data . . . from a remote user” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Zhu, Pg. 1, Col. 2, Para. 1, “there is an urgent demand for privacy-preserving techniques capable of supporting compute- and data-intensive (CDI) computing, such as training deep neural networks (DNNs) over an enormous amount of data” and Zhu, Pg. 11, Col. 2, Para. 1, “It can be observed that the HETEE throughput overhead is 12.34% for network inference and 9.87% for network training on average”, where the using can be updating an asset, “network training”, and where, in view of Beutel, the updating of assets is updating a shared asset using the first confidential data, see Beutel, Pg. 14, Col. 2, Para. 1, “The server then averages all successful θ k∈{0,..,K} updates, weighted by mk, the number of training examples on client k” and Beutel, Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates”):
disconnecting, by an orchestrator VM, the first data holder from the hardware accelerator (Zhu, Pg. 5, Col. 1, Para. 2, “At the center of the design is a trusted security controller unit that manages a set of PCIe switches attached to a host server”; Zhu, Pg. 7, Col. 1, Para. 1, “Finally, the task manager destroys the task queues and terminates the process”; and Zhu, Pg. 6, Fig. 2, where the “security controller” and “host server” are collectively within the broadest reasonable interpretation of an orchestrator because they perform and effect “manage[ment]”, which, in view of Beutel is a orchestration server WM, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”, and where “the task manager”, which as shown in figure 2 is part of the “Security Controller”, disconnects data holders from the hardware accelerator, “destroys the task queues and terminates the process”; see also Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”, where the plurality of “different users” includes the first data holder)
so that the first data holder is no longer able to communicate with the hardware accelerator (Zhu, Pg. 7, Col. 2, Para. 3, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them. Coupled with our context cleaning mechanism, such a design can minimize side-channel leakages across tasks” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds. By dynamically configuring the Express Fabric chip, an accelerator can be physically assigned to the host or the security controller on-demand, thus enabling the switching of the accelerator security mode. With this feature, HETEE dynamically defines the boundary of the secure world. To avoid the security risks from the data and code on the accelerator switched between different worlds, HETEE utilizes context clearance to restore the device to a trusted state”, where the coupling can be to the same hardware accelerator, “it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds . . . an accelerator can be physically assigned to the host or the security controller on-demand, thus enabling the switching of the accelerator security mode”, which occurs after the first data holder is no longer able to communicate with the hardware accelerator, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them”).
The reasons for obviousness were discussed in regard to the rejection of claim 1 above and remain applicable here.
Zhu in view of Beutel do not explicitly disclose . . . before . . . (where the disconnecting is not specifically described as occurring before the updating).
However, López-Alt teaches . . . [a method for multiparty computation] (Pg. 1219, Col. 1, Abstract, Para. 1, “We propose a new notion of secure multiparty computation aided by a computationally-powerful but untrusted “cloud” serve”)
[where] before [performing the computation, the data holders are disconnected from the server] . . . (Pg. 1220, Col. 1, Para. 4, “the users need not be online at all during the bulk of the computation; they need to “wake up” only when it is time to decrypt the output”).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine the updating the shared asset using the first confidential data and disconnecting, by an orchestrator VM, the first data holder from the hardware accelerator so that the first data holder is no longer able to communicate with the hardware accelerator of Zhu in view of Beutel with the method for multiparty computation where before performing the computation, the data holders are disconnected from the server of López-Alt in order to securely perform the collaborative updating of the shared asset (compare Beutel, Pg. 14, Col. 2, Para. 1, “The server then averages all successful θ k∈{0,..,K} updates, weighted by mk, the number of training examples on client k” and Beutel, Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates”, where the computations require access to data from multiple data holders at once, with López-Alt, Pg. 1219, Col. 1, Abstract, Para. 1-2, “We propose a new notion of secure multiparty computation aided by a computationally-powerful but untrusted “cloud” server . . . All user’s input data and intermediate results are protected from snooping by the cloud as well as other users. This extends the standard notion of fully homomorphic encryption (FHE), where users can only enlist the cloud’s help in evaluating functions on their own encrypted data”, where computations can be securely performed on aggregate user data without compromising privacy), while minimizing interactions with the data holders (López-Alt, Pg. 1219, Col. 1, Abstract, Para. 2-3, “In on-the-fly MPC, each user is involved only when initially uploading his (encrypted) data to the cloud, and in a final output decryption phase when outputs are revealed . . . When users upload their data, they need not decide in advance which function will be computed, nor who they will compute with; they need only retroactively approve the eventually-chosen functions and on whose data the functions were evaluated. This notion is qualitatively the best possible in minimizing interaction”) and allowing for undetected uploads without the need for mutual trust (López-Alt, Pg. 1920, Col. 2, Para. 3, “In our setting, since the parties do not trust each other, they will most certainly not want to encrypt their inputs using each other’s keys” and López-Alt, Pg. 1920, Col. 1, Para. 3, “An on-the-fly multiparty computation protocol proceeds thus: 1. The numerous users each encrypt their data and up load them to the cloud, unaware of the identity or even the number of other users in the system”).
Regarding Claim 6, Zhu in view of Beutel and López-Alt teaches the method of claim 5, further comprising, before (Zhu, Pg. 1, Col. 1, Abstract, “The host server and other computing systems communicate with controller through an in-memory task queue that accommodates the computing tasks offloaded to HETEE, in the form of encrypted and signed code and data” and Zhu, Pg. 7, Col. 1, Para. 1, “Once the establishment of the task queue is completed, the remote user encrypts the command (i.e., AI model), packs the ciphertext into a command task, and put it into the task queue. The task manager fetches ciphertexts from the task queue, verifies the integrity of the messages, then decrypts and parses them”, where the updating of the “AI model” requires both the “code” and “data”, and, as a result, the below discussed code must be uploaded before the updating; see also López-Alt, Pg. 1220, Col. 1, Para. 4, “the users need not be online at all during the bulk of the computation; they need to “wake up” only when it is time to decrypt the output”; see also López-Alt, Pg. 1219, Col. 1, Abstract, Para. 1, “We propose a new notion of secure multiparty computation aided by a computationally-powerful but untrusted “cloud” serve”)
updating the shared asset using the first confidential data (Zhu, Pg. 7, Col. 1, Para. 1, “After its data is processed by accelerator, the process places the computing result in the output buffer”, where the “the computing result” is generated using the “data”, which is first confidential data when “transmit[ted] sensitive data” from a first “remote user” of the plurality of “different users”, see Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data . . . from a remote user” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Zhu, Pg. 1, Col. 2, Para. 1, “there is an urgent demand for privacy-preserving techniques capable of supporting compute- and data-intensive (CDI) computing, such as training deep neural networks (DNNs) over an enormous amount of data” and Zhu, Pg. 11, Col. 2, Para. 1, “It can be observed that the HETEE throughput overhead is 12.34% for network inference and 9.87% for network training on average”, where the using can be updating an asset, “network training”, and where, in view of Beutel, the updating of assets is updating a shared asset using the first confidential data, see Beutel, Pg. 14, Col. 2, Para. 1, “The server then averages all successful θ k∈{0,..,K} updates, weighted by mk, the number of training examples on client k” and Beutel, Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates”)
but after (Zhu, Pg. 7, Col. 2, Para. 3, “When a user needs to utilize the accelerator resource, a request is sent to the security controller, which dynamically allocates a certain amount of accelerator resources to the user” and Zhu, Pg. 7, Col. 2, Para. 3, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them. Coupled with our context cleaning mechanism, such a design can minimize side-channel leakages across tasks”, where “the security controller . . . dynamically allocates a certain amount of accelerator resources to the user[s]” in a sequential manner, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them”, such that, in view of Beutel’s “1000 clients”, the below discussed uploading of code from a client must occur after the disconnecting of a first data holder, see Beutel, Pg. 2, Col. 2, Para. 1, “Using Flower as the underlying framework, we present experiments that explore both algorithmic and system level aspects of FL on five machine learning workloads with up to 1000 clients”; see also López-Alt, Pg. 1220, Col. 1, Para. 4, “the users need not be online at all during the bulk of the computation; they need to “wake up” only when it is time to decrypt the output”; see also López-Alt, Pg. 1219, Col. 1, Abstract, Para. 1, “We propose a new notion of secure multiparty computation aided by a computationally-powerful but untrusted “cloud” serve”)
disconnecting the first data holder from the hardware accelerator (Zhu, Pg. 5, Col. 1, Para. 2, “At the center of the design is a trusted security controller unit that manages a set of PCIe switches attached to a host server”; Zhu, Pg. 7, Col. 1, Para. 1, “Finally, the task manager destroys the task queues and terminates the process”; and Zhu, Pg. 6, Fig. 2, where “the task manager”, which as shown in figure 2 is part of the “Security Controller”, disconnects data holders from the hardware accelerator, “destroys the task queues and terminates the process”; see also Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”, where the plurality of “different users” includes the first data holder):
uploading, by the orchestrator VM, code into the hardware accelerator wherein the code updates the shared asset using the first confidential data (Zhu, Pg. 5, Col. 1, Para. 2, “At the center of the design is a trusted security controller unit that manages a set of PCIe switches attached to a host server”; Zhu, Pg. 7, Col. 1, Para. 1, “Finally, the task manager destroys the task queues and terminates the process”; and Zhu, Pg. 6, Fig. 2, where the “security controller” and “host server” are collectively within the broadest reasonable interpretation of an orchestrator because they perform and effect “manage[ment]”, which, in view of Beutel is a orchestration server WM, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”, which uploads code, see Zhu, Pg. 1, Col. 1, Abstract, “The host server and other computing systems communicate with controller through an in-memory task queue that accommodates the computing tasks offloaded to HETEE, in the form of encrypted and signed code and data”, into the hardware accelerator, Zhu, Pg. 8, Col. 1, Para. 1, “To avoid the security risks from the data and code on the accelerator switched be- tween different worlds, HETEE utilizes context clearance to restore the device to a trusted state”, wherein the code updates assets using data, see Zhu, Pg. 7, Col. 1, Para. 1, “Once the establishment of the task queue is completed, the remote user encrypts the command (i.e., AI model), packs the ciphertext into a command task, and put it into the task queue. The task manager fetches ciphertexts from the task queue, verifies the integrity of the messages, then decrypts and parses them”, which in view of in view of Beutel, the updating of assets is updating a shared asset using data from the “all successful θ k∈{0,..,K} updates”, including the first confidential data, see Beutel, Pg. 14, Col. 2, Para. 1, “The server then averages all successful θ k∈{0,..,K} updates, weighted by mk, the number of training examples on client k” and Beutel, Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates”).
The reasons for obviousness were discussed in regard to the rejection of claim 1 and the rejection of claim 5 above and remain applicable here.
Regarding Claim 7, Zhu in view of Beutel and López-Alt teaches the method of claim 5, wherein the hardware accelerator is confidential computing (CC) enabled such that keys are used to encrypt data transmitted to the hardware accelerator (Zhu, Pg. 5, Col. 1-2, Para. 5-1, “A remote user uses the remote attestation to verify the security of an accelerator. The main part of an offloading application runs on the CPU. It accepts the protection of a CPU TEE (e.g. Intel SGX), or its sensitive code and data exists in encrypted form. When the application needs to use an accelerator, it writes the code and data according to the agreed programming model, and sends these key data and task instructions to the security controller in ciphertext”; Zhu, Pg. 6, Col. 1, Para. 1, “Hardware acceleration engine for encryption and decryption and hash algorithms are expected”; Zhu, Pg. 7, Col. 1, Para. 2, “First, the process initializes accelerators and allocates device buffers for data. Then, the process loads new data from the input buffer, and moving them into the memory space of the accelerator. Then, the computing kernel is launched. After the execution, the result is copied from the accelerators to the output buffer”; and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”, where the hardware accelerator, “accelerator”, is confidential computing (CC) enabled such that keys are used to encrypt data transmitted, “its sensitive code and data exists in encrypted form . . . and sends these key data and task instructions to the security controller in ciphertext”, to the hardware accelerator, “the process loads new data from the input buffer, and moving them into the memory space of the accelerator”, from the first and second data holders of the plurality of “different users”, which, in view of Beutel, are the first and second VMs, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”),
the method further comprising, before the second data holder communicates with the hardware accelerator: resetting (Zhu, Pg. 2, Col. 2, Para. 2, “Our solution leverages the unique features of today’s GPU and accelerator designs . . . they can be “reset” to a trusted status by simply cleaning up all their internal storage . . . HETEE either utilizes its “hot reset” function to restore it to the clean status or runs a program to wipe out all its storage content”; Zhu, Pg. 4, Col. 2, Para. 2, “we consider that the under the fundamental reset or cold reboot, the firmware on an accelerator (such as GPU) can ensure that all micro-architecture statuses, including those of caches and memory, are cleared”; Zhu, Pg. 10, Col. 1, Para. 2, “In the design of HETEE the states of accelerators are cleared upon mode switches and task switches. This reduces shared resources between the insecure world and secure world, as well as among tasks”; and Zhu, Pg. 7, Col. 1, Para. 1, “Finally, the task manager destroys the task queues and terminates the process”, where resetting is performed, “HETEE either utilizes its “hot reset” function to restore it to the clean status or runs a program to wipe out all its storage content” “the task manager destroys the task queues and terminates the process”, which occurs before the second data holder communicates with the hardware accelerator, see Zhu, Pg. 7, Col. 2, Para. 3, “When a user needs to utilize the accelerator resource, a request is sent to the security controller, which dynamically allocates a certain amount of accelerator resources to the user” and Zhu, Pg. 7, Col. 2, Para. 3, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them. Coupled with our context cleaning mechanism, such a design can minimize side-channel leakages across tasks”),
by the orchestrator VM (Zhu, Pg. 5, Col. 1, Para. 2, “At the center of the design is a trusted security controller unit that manages a set of PCIe switches attached to a host server”; Zhu, Pg. 7, Col. 1, Para. 1, “Finally, the task manager destroys the task queues and terminates the process”; and Zhu, Pg. 6, Fig. 2, where the “security controller” and “host server” are collectively within the broadest reasonable interpretation of an orchestrator because they perform and effect “manage[ment]”, which, in view of Beutel is a orchestration server WM, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”),
the keys used to communicate with the hardware accelerator (López-Alt, Pg. 1219, Col. 1, Para. 3, “We show how on-the-fly MPC can be achieved using a new type of encryption scheme that we call multi key FHE, which is capable of operating on inputs encrypted under multiple, unrelated keys. A ciphertext resulting from a multikey evaluation can be jointly de crypted using the secret keys of all the users involved in the computation” and López-Alt, Pg. 1220, Col. 1, Para. 3, “The numerous users each encrypt their data and upload them to the cloud, unaware of the identity or even the number of other users in the system. Additional data may arrive directly to the cloud, encrypted under users’ public keys (e.g., as encrypted emails arriving to a cloud-based mailbox)”, where, in view of López-Alt, “all of the users” are “unrelated keys”, which is within the broadest reasonable interpretation of resetting the keys, and where the keys are used for communication, “users each encrypt their data and upload them to the cloud”, with the hardware accelerator, see Zhu, Pg. 2, Col. 2, Para. 1, “All the computing units, like GPUs, AI accelerators, etc., are shared between the OS and the security controller”; Zhu, Pg. 1, Col. 2, Para. 3, “high-throughput accelerators such as graph-processing unit (GPU), tensor-processing unit (TPU), field-programmable gate array (FPGA, for building custom accelerators) etc.”; and Zhu, Pg. 10, Col. 1, Para. 1, “It only needs to support limited hardware accelerators”);
and providing the reset keys to the second data holder but not the first data holder so that the first data holder can no longer communicate with the hardware accelerator (Zhu, Pg. 7, Col. 2, Para. 3, “When a user needs to utilize the accelerator resource, a request is sent to the security controller, which dynamically allocates a certain amount of accelerator resources to the user” and Zhu, Pg. 7, Col. 2, Para. 3, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them. Coupled with our context cleaning mechanism, such a design can minimize side-channel leakages across tasks”, where resources for communication with the hardware accelerator, “When a user needs to utilize the accelerator resource, a request is sent to the security controller, which dynamically allocates a certain amount of accelerator resources to the user”, are provided to the second data holder but not the first data holder so that the first data holder can no longer communicate with the hardware accelerator, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them. Coupled with our context cleaning mechanism, such a design can minimize side-channel leakages across tasks”; see also Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”, where the plurality of “different users” requires a first and a second data holder; see also López-Alt, Pg. 1219, Col. 1, Para. 3, “We show how on-the-fly MPC can be achieved using a new type of encryption scheme that we call multi key FHE, which is capable of operating on inputs encrypted under multiple, unrelated keys. A ciphertext resulting from a multikey evaluation can be jointly de crypted using the secret keys of all the users involved in the computation” and López-Alt, Pg. 1220, Col. 1, Para. 3, “The numerous users each encrypt their data and upload them to the cloud, unaware of the identity or even the number of other users in the system. Additional data may arrive directly to the cloud, encrypted under users’ public keys (e.g., as encrypted emails arriving to a cloud-based mailbox)”, where, in view of López-Alt, the reset keys, “the secret keys of all the users involved in the computation”, are part of the provided resources).
The reasons for obviousness were discussed in regard to the rejection of claim 1 and the rejection of claim 5 above and remain applicable here.
Regarding Claim 8, the additional elements of the dependent claim are substantially the same as the limitations of claim 15, therefore it is rejected under the same rationale.
Regarding Claim 12, Zhu in view of Beutel and López-Alt teaches the collaborative learning system of claim 9, wherein the third orchestrator VM is configured to (Zhu, Pg. 5, Col. 1, Para. 2, “At the center of the design is a trusted security controller unit that manages a set of PCIe switches attached to a host server”; Zhu, Pg. 7, Col. 1, Para. 1, “Finally, the task manager destroys the task queues and terminates the process”; and Zhu, Pg. 6, Fig. 2, where the “security controller” and “host server” are collectively within the broadest reasonable interpretation of an orchestrator because they perform and effect “manage[ment]”, which, in view of Beutel is a orchestration server WM, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”),
before (López-Alt, Pg. 1220, Col. 1, Para. 4, “the users need not be online at all during the bulk of the computation; they need to “wake up” only when it is time to decrypt the output”; see also López-Alt, Pg. 1219, Col. 1, Abstract, Para. 1, “We propose a new notion of secure multiparty computation aided by a computationally-powerful but untrusted “cloud” serve”)
updating the shared asset using the first confidential data (Zhu, Pg. 7, Col. 1, Para. 1, “After its data is processed by accelerator, the process places the computing result in the output buffer”, where the “the computing result” is generated using the “data”, which is first confidential data when “transmit[ted] sensitive data” from a first “remote user” of the plurality of “different users”, see Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data . . . from a remote user” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Zhu, Pg. 1, Col. 2, Para. 1, “there is an urgent demand for privacy-preserving techniques capable of supporting compute- and data-intensive (CDI) computing, such as training deep neural networks (DNNs) over an enormous amount of data” and Zhu, Pg. 11, Col. 2, Para. 1, “It can be observed that the HETEE throughput overhead is 12.34% for network inference and 9.87% for network training on average”, where the using can be updating an asset, “network training”, and where, in view of Beutel, the updating of assets is updating a shared asset using the first confidential data, see Beutel, Pg. 14, Col. 2, Para. 1, “The server then averages all successful θ k∈{0,..,K} updates, weighted by mk, the number of training examples on client k” and Beutel, Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates”):
disconnect the first data holder from the hardware accelerator (Zhu, Pg. 5, Col. 1, Para. 2, “At the center of the design is a trusted security controller unit that manages a set of PCIe switches attached to a host server”; Zhu, Pg. 7, Col. 1, Para. 1, “Finally, the task manager destroys the task queues and terminates the process”; and Zhu, Pg. 6, Fig. 2, where “the task manager”, which as shown in figure 2 is part of the “Security Controller”, disconnects data holders from the hardware accelerator, “destroys the task queues and terminates the process”; see also Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”, where the plurality of “different users” includes the first data holder)
so that the first VM is no longer able to communicate with the hardware accelerator (Zhu, Pg. 7, Col. 2, Para. 3, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them. Coupled with our context cleaning mechanism, such a design can minimize side-channel leakages across tasks” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds. By dynamically configuring the Express Fabric chip, an accelerator can be physically assigned to the host or the security controller on-demand, thus enabling the switching of the accelerator security mode. With this feature, HETEE dynamically defines the boundary of the secure world. To avoid the security risks from the data and code on the accelerator switched between different worlds, HETEE utilizes context clearance to restore the device to a trusted state”, where the coupling can be to the same hardware accelerator, “it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds . . . an accelerator can be physically assigned to the host or the security controller on-demand, thus enabling the switching of the accelerator security mode”, which occurs after the first data holder is no longer able to communicate with the hardware accelerator, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them”, and where, in view of Beutel the first data holder has a first WM for it, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”).
The reasons for obviousness were discussed in regard to the rejection of claim 1 and the rejection of claim 5 above and remain applicable here.
Regarding Claim 13, Zhu in view of Beutel and López-Alt teaches the collaborative learning system of claim 12, wherein the third orchestrator VM is configured to (Zhu, Pg. 5, Col. 1, Para. 2, “At the center of the design is a trusted security controller unit that manages a set of PCIe switches attached to a host server”; Zhu, Pg. 7, Col. 1, Para. 1, “Finally, the task manager destroys the task queues and terminates the process”; and Zhu, Pg. 6, Fig. 2, where the “security controller” and “host server” are collectively within the broadest reasonable interpretation of an orchestrator because they perform and effect “manage[ment]”, which, in view of Beutel is a orchestration server WM, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”),
before (Zhu, Pg. 1, Col. 1, Abstract, “The host server and other computing systems communicate with controller through an in-memory task queue that accommodates the computing tasks offloaded to HETEE, in the form of encrypted and signed code and data” and Zhu, Pg. 7, Col. 1, Para. 1, “Once the establishment of the task queue is completed, the remote user encrypts the command (i.e., AI model), packs the ciphertext into a command task, and put it into the task queue. The task manager fetches ciphertexts from the task queue, verifies the integrity of the messages, then decrypts and parses them”, where the updating of the “AI model” requires both the “code” and “data”, and, as a result, the below discussed code must be uploaded before the updating; see also López-Alt, Pg. 1220, Col. 1, Para. 4, “the users need not be online at all during the bulk of the computation; they need to “wake up” only when it is time to decrypt the output”; see also López-Alt, Pg. 1219, Col. 1, Abstract, Para. 1, “We propose a new notion of secure multiparty computation aided by a computationally-powerful but untrusted “cloud” serve”)
updating the shared asset using the first confidential data (Zhu, Pg. 7, Col. 1, Para. 1, “After its data is processed by accelerator, the process places the computing result in the output buffer”, where the “the computing result” is generated using the “data”, which is first confidential data when “transmit[ted] sensitive data” from a first “remote user” of the plurality of “different users”, see Zhu, Pg. 6-7, Para. 4-1, “Data task: This type of task is used to transmit sensitive data . . . from a remote user” and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”; see also Zhu, Pg. 1, Col. 2, Para. 1, “there is an urgent demand for privacy-preserving techniques capable of supporting compute- and data-intensive (CDI) computing, such as training deep neural networks (DNNs) over an enormous amount of data” and Zhu, Pg. 11, Col. 2, Para. 1, “It can be observed that the HETEE throughput overhead is 12.34% for network inference and 9.87% for network training on average”, where the using can be updating an asset, “network training”, and where, in view of Beutel, the updating of assets is updating a shared asset using the first confidential data, see Beutel, Pg. 14, Col. 2, Para. 1, “The server then averages all successful θ k∈{0,..,K} updates, weighted by mk, the number of training examples on client k” and Beutel, Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates”)
but after (Zhu, Pg. 7, Col. 2, Para. 3, “When a user needs to utilize the accelerator resource, a request is sent to the security controller, which dynamically allocates a certain amount of accelerator resources to the user” and Zhu, Pg. 7, Col. 2, Para. 3, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them. Coupled with our context cleaning mechanism, such a design can minimize side-channel leakages across tasks”, where “the security controller . . . dynamically allocates a certain amount of accelerator resources to the user[s]” in a sequential manner, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them”, such that, in view of Beutel’s “1000 clients”, the below discussed uploading of code from a client must occur after the disconnecting of a first data holder, see Beutel, Pg. 2, Col. 2, Para. 1, “Using Flower as the underlying framework, we present experiments that explore both algorithmic and system level aspects of FL on five machine learning workloads with up to 1000 clients”; see also López-Alt, Pg. 1220, Col. 1, Para. 4, “the users need not be online at all during the bulk of the computation; they need to “wake up” only when it is time to decrypt the output”; see also López-Alt, Pg. 1219, Col. 1, Abstract, Para. 1, “We propose a new notion of secure multiparty computation aided by a computationally-powerful but untrusted “cloud” serve”)
disconnecting the first data holder from the hardware accelerator (Zhu, Pg. 5, Col. 1, Para. 2, “At the center of the design is a trusted security controller unit that manages a set of PCIe switches attached to a host server”; Zhu, Pg. 7, Col. 1, Para. 1, “Finally, the task manager destroys the task queues and terminates the process”; and Zhu, Pg. 6, Fig. 2, where “the task manager”, which as shown in figure 2 is part of the “Security Controller”, disconnects data holders from the hardware accelerator, “destroys the task queues and terminates the process”; see also Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”, where the plurality of “different users” includes the first data holder):
upload code into the hardware accelerator, wherein the code updates the shared asset using the first confidential data (Zhu, Pg. 5, Col. 1, Para. 2, “At the center of the design is a trusted security controller unit that manages a set of PCIe switches attached to a host server”; Zhu, Pg. 7, Col. 1, Para. 1, “Finally, the task manager destroys the task queues and terminates the process”; and Zhu, Pg. 6, Fig. 2, where the “security controller” and “host server” are collectively within the broadest reasonable interpretation of an orchestrator because they perform and effect “manage[ment]”, which, in view of Beutel is a orchestration server WM, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”, which uploads code, see Zhu, Pg. 1, Col. 1, Abstract, “The host server and other computing systems communicate with controller through an in-memory task queue that accommodates the computing tasks offloaded to HETEE, in the form of encrypted and signed code and data”, into the hardware accelerator, Zhu, Pg. 8, Col. 1, Para. 1, “To avoid the security risks from the data and code on the accelerator switched be- tween different worlds, HETEE utilizes context clearance to restore the device to a trusted state”, wherein the code updates assets using data, see Zhu, Pg. 7, Col. 1, Para. 1, “Once the establishment of the task queue is completed, the remote user encrypts the command (i.e., AI model), packs the ciphertext into a command task, and put it into the task queue. The task manager fetches ciphertexts from the task queue, verifies the integrity of the messages, then decrypts and parses them”, which in view of in view of Beutel, the updating of assets is updating a shared asset using data from the “all successful θ k∈{0,..,K} updates”, including the first confidential data, see Beutel, Pg. 14, Col. 2, Para. 1, “The server then averages all successful θ k∈{0,..,K} updates, weighted by mk, the number of training examples on client k” and Beutel, Pg. 1, Col. 1-2, Para. 1-1, “At a high level, this is achieved by repeating three basic steps: i) local parameters update to a shared prediction model on each edge device, ii) sending the local parameter updates to a central server for aggregation, and iii) receiving the aggregated model back for the next round of local updates”).
The reasons for obviousness were discussed in regard to the rejection of claim 1 and the rejection of claim 5 above and remain applicable here.
Regarding Claim 14, Zhu in view of Beutel and López-Alt teaches the collaborative learning system of claim 9, wherein the hardware accelerator is confidential computing (CC) enabled such that keys are used to encrypt data transmitted to the hardware accelerator (Zhu, Pg. 5, Col. 1-2, Para. 5-1, “A remote user uses the remote attestation to verify the security of an accelerator. The main part of an offloading application runs on the CPU. It accepts the protection of a CPU TEE (e.g. Intel SGX), or its sensitive code and data exists in encrypted form. When the application needs to use an accelerator, it writes the code and data according to the agreed programming model, and sends these key data and task instructions to the security controller in ciphertext”; Zhu, Pg. 6, Col. 1, Para. 1, “Hardware acceleration engine for encryption and decryption and hash algorithms are expected”; Zhu, Pg. 7, Col. 1, Para. 2, “First, the process initializes accelerators and allocates device buffers for data. Then, the process loads new data from the input buffer, and moving them into the memory space of the accelerator. Then, the computing kernel is launched. After the execution, the result is copied from the accelerators to the output buffer”; and Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”, where the hardware accelerator, “accelerator”, is confidential computing (CC) enabled such that keys are used to encrypt data transmitted, “its sensitive code and data exists in encrypted form . . . and sends these key data and task instructions to the security controller in ciphertext”, to the hardware accelerator, “the process loads new data from the input buffer, and moving them into the memory space of the accelerator”, from the first and second data holders of the plurality of “different users”, which, in view of Beutel, are the first and second VMs, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”),
the orchestrator VM is configured to (Zhu, Pg. 5, Col. 1, Para. 2, “At the center of the design is a trusted security controller unit that manages a set of PCIe switches attached to a host server”; Zhu, Pg. 7, Col. 1, Para. 1, “Finally, the task manager destroys the task queues and terminates the process”; and Zhu, Pg. 6, Fig. 2, where the “security controller” and “host server” are collectively within the broadest reasonable interpretation of an orchestrator because they perform and effect “manage[ment]”, which, in view of Beutel is a orchestration server WM, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”),
before the second data holder communicates with the hardware accelerator: reset (Zhu, Pg. 2, Col. 2, Para. 2, “Our solution leverages the unique features of today’s GPU and accelerator designs . . . they can be “reset” to a trusted status by simply cleaning up all their internal storage . . . HETEE either utilizes its “hot reset” function to restore it to the clean status or runs a program to wipe out all its storage content”; Zhu, Pg. 4, Col. 2, Para. 2, “we consider that the under the fundamental reset or cold reboot, the firmware on an accelerator (such as GPU) can ensure that all micro-architecture statuses, including those of caches and memory, are cleared”; Zhu, Pg. 10, Col. 1, Para. 2, “In the design of HETEE the states of accelerators are cleared upon mode switches and task switches. This reduces shared resources between the insecure world and secure world, as well as among tasks”; and Zhu, Pg. 7, Col. 1, Para. 1, “Finally, the task manager destroys the task queues and terminates the process”, where resetting is performed, “HETEE either utilizes its “hot reset” function to restore it to the clean status or runs a program to wipe out all its storage content” “the task manager destroys the task queues and terminates the process”, which occurs before the second data holder communicates with the hardware accelerator, see Zhu, Pg. 7, Col. 2, Para. 3, “When a user needs to utilize the accelerator resource, a request is sent to the security controller, which dynamically allocates a certain amount of accelerator resources to the user” and Zhu, Pg. 7, Col. 2, Para. 3, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them. Coupled with our context cleaning mechanism, such a design can minimize side-channel leakages across tasks”),
by the orchestrator VM (Zhu, Pg. 5, Col. 1, Para. 2, “At the center of the design is a trusted security controller unit that manages a set of PCIe switches attached to a host server”; Zhu, Pg. 7, Col. 1, Para. 1, “Finally, the task manager destroys the task queues and terminates the process”; and Zhu, Pg. 6, Fig. 2, where the “security controller” and “host server” are collectively within the broadest reasonable interpretation of an orchestrator because they perform and effect “manage[ment]”, which, in view of Beutel is a orchestration server WM, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”),
the keys used to communicate with the hardware accelerator (López-Alt, Pg. 1219, Col. 1, Para. 3, “We show how on-the-fly MPC can be achieved using a new type of encryption scheme that we call multi key FHE, which is capable of operating on inputs encrypted under multiple, unrelated keys. A ciphertext resulting from a multikey evaluation can be jointly de crypted using the secret keys of all the users involved in the computation” and López-Alt, Pg. 1220, Col. 1, Para. 3, “The numerous users each encrypt their data and upload them to the cloud, unaware of the identity or even the number of other users in the system. Additional data may arrive directly to the cloud, encrypted under users’ public keys (e.g., as encrypted emails arriving to a cloud-based mailbox)”, where, in view of López-Alt, “all of the users” are “unrelated keys”, which is within the broadest reasonable interpretation of resetting the keys, and where the keys are used for communication, “users each encrypt their data and upload them to the cloud”, with the hardware accelerator, see Zhu, Pg. 2, Col. 2, Para. 1, “All the computing units, like GPUs, AI accelerators, etc., are shared between the OS and the security controller”; Zhu, Pg. 1, Col. 2, Para. 3, “high-throughput accelerators such as graph-processing unit (GPU), tensor-processing unit (TPU), field-programmable gate array (FPGA, for building custom accelerators) etc.”; and Zhu, Pg. 10, Col. 1, Para. 1, “It only needs to support limited hardware accelerators”); and
provide the reset keys to the second VM but not the first VM so that the first data holder can no longer communicate with the hardware accelerator (Zhu, Pg. 7, Col. 2, Para. 3, “When a user needs to utilize the accelerator resource, a request is sent to the security controller, which dynamically allocates a certain amount of accelerator resources to the user” and Zhu, Pg. 7, Col. 2, Para. 3, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them. Coupled with our context cleaning mechanism, such a design can minimize side-channel leakages across tasks”, where resources for communication with the hardware accelerator, “When a user needs to utilize the accelerator resource, a request is sent to the security controller, which dynamically allocates a certain amount of accelerator resources to the user”, are provided to the second data holder but not the first data holder so that the first data holder can no longer communicate with the hardware accelerator, “HETEE only allows multiple tasks to timing-share accelerators, rather than multiple tasks concurrently running on them. Coupled with our context cleaning mechanism, such a design can minimize side-channel leakages across tasks”; see also Zhu, Pg. 8, Col. 1, Para. 1, “In order to utilize the data center accelerator resources more efficiently, it is necessary to dynamically allocate the accelerators to different users, which might involve switching the accelerator across secure/insecure worlds”, where the plurality of “different users” requires a first and a second data holder; see also López-Alt, Pg. 1219, Col. 1, Para. 3, “We show how on-the-fly MPC can be achieved using a new type of encryption scheme that we call multi key FHE, which is capable of operating on inputs encrypted under multiple, unrelated keys. A ciphertext resulting from a multikey evaluation can be jointly de crypted using the secret keys of all the users involved in the computation” and López-Alt, Pg. 1220, Col. 1, Para. 3, “The numerous users each encrypt their data and upload them to the cloud, unaware of the identity or even the number of other users in the system. Additional data may arrive directly to the cloud, encrypted under users’ public keys (e.g., as encrypted emails arriving to a cloud-based mailbox)”, where, in view of López-Alt, the reset keys, “the secret keys of all the users involved in the computation”, are part of the provided resources, and where, in view of Beutel, the first and second data holders are the first and second VMs, see Beutel, Pg. 7, Col. 2, Para. 3, “The FL server and all the clients are hosted on virtual machines in a cloud platform”).
The reasons for obviousness were discussed in regard to the rejection of claim 1 and the rejection of claim 5 above and remain applicable here.
Regarding Claim 19, the additional elements of the dependent claim are substantially the same as the limitations of claim 5, therefore it is rejected under the same rationale.
Regarding Claim 20, the additional elements of the dependent claim are substantially the same as the limitations of claim 6, therefore it is rejected under the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Chu et al. (Pat. App. Pub. No. US 2021/0374617 A1) discloses additional systems and methods for updating a shared asset that is a statistical parameter (see Para. [0066] – [0077]; Fig. 5).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW BRYCE GOLAN whose telephone number is (571)272-5159. The examiner can normally be reached Monday through Friday, 8:00 AM to 5:00 PM ET.
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, Alexey Shmatov can be reached at (571) 270-3428. 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.
/MATTHEW BRYCE GOLAN/Examiner, Art Unit 2123
/ALEXEY SHMATOV/Supervisory Patent Examiner, Art Unit 2123
