DETAILED ACTION
This final office action is in response to claims 1-20 filed on 08/22/2025 for examination. Claims 1-20 are being examined and are pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Response to Amendment
The amendment filed August 22, 2025 has been entered. Claims 1-20 remain pending in the application. The claims have been amended. Applicant’s arguments and amendments to the claims are directed to the 35 U.S.C. 103 rejection(s) previously set forth in the Non-Final Office Action mailed May 22, 2025. Claims 1, 3-10, and 12-20 have been amended and have necessitated a new ground(s) of rejection in this Office Action. Further, applicant’s arguments regarding claims 1-20 have been fully considered but are not persuasive to differentiate over the prior art. Particularly:
Applicant opines that Bronk (US20170244565) in view of Chauhan et al. (US20180103018) fails to disclose calculating a first threshold of diminution returns for a sign operation based on a first time to perform the sign operation that is determined based on a first equation to determine whether to offload the sign operation onto a hardware acceleration coprocessor and calculating a second threshold of diminishing returns for a verify operation based on a second time to perform the verify operation that is determined based on a second equation to determine whether to offload the verify operation onto the hardware acceleration coprocessor, with generally similar rationale for the language of claim 10. Remarks, pgs. 12-13. Examiner disagrees. Bronk teaches a system for determining whether to offload cryptographic sign operations and/or cryptographic verify operations to a cryptographic accelerator. See, e.g., Bronk at [0036-041]. Similarly, Chauhan teaches a system for determining whether to offload different types of cryptographic operations to a cryptographic accelerator (though Chauhan does not appear to explicitly state “sign” operations or “verify” operations). See, e.g., Chauhan at [0329-0331] and [0343-344]. Particularly: Chauhan teaches a system for choosing whether an x86 processor or a hardware accelerator should perform a first type of cryptographic operation, whether the x86 processor or a hardware accelerator should perform a second type of cryptographic operation, whether the x86 processor or a hardware accelerator should perform a third type of cryptographic operation, etc. Id. A threshold for offloading a first type of cryptographic operations may be based upon a first time duration for processing the first type of cryptographic operations using the x86 processor vs. a second time duration for processing the first type cryptographic operations using the hardware accelerator <i.e., a first equation>. Id. When it is more optimal/faster to offload the operation to an accelerator, the operation is offloaded. Id. Similarly, a threshold for offloading a second type of cryptographic operations may be based upon a first <i.e., “third”> total time duration for processing the second type of cryptographic operations using the x86 processor vs. a second <i.e., “fourth”> time duration for processing the second type cryptographic operations using the hardware accelerator <i.e., a second equation>. Id. Accordingly, Chauhan teaches calculating a first threshold of diminution returns for a first operation based on a first time to perform the first operation that is determined based on a first equation to determine whether to offload the first operation onto a hardware acceleration coprocessor and calculating a second threshold of diminishing returns for a second operation based on a second time to perform the second operation that is determined based on a second equation to determine whether to offload the second operation onto the hardware acceleration coprocessor.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the sign and verify offloading of Bronk with the teachings of Chauhan, comprising calculating a first threshold of diminution returns for a sign operation based on a first time to perform the sign operation that is determined based on a first equation to determine whether to offload the sign operation onto a hardware acceleration coprocessor and calculating a second threshold of diminishing returns for a verify operation based on a second time to perform the verify operation that is determined based on a second equation to determine whether to offload the verify operation onto the hardware acceleration coprocessor, to more optimally execute cryptographic operations using the host processor and/or the hardware acceleration coprocessor (see, e.g., Bronk at [0039-041] and [0036-037]; with Chauhan at [0342-0347] and [0329-331]).
In view of the foregoing, as well as hereinbelow with regards to 35 U.S.C. 103, applicant’s arguments regarding claims 1-20 have been fully considered but are not persuasive to differentiate over the prior art.
Claim Objections
Claim 19 is objected to because of the following informality:
Claim 19 recites “The method of claim 16 further comprising […]” in lines 1-2. Examiner suggests amending to “The method of claim 16, further comprising […]” or similar, if intended.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-5, 7-11, 13-14, 16-17, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bronk (US20170244565) in view of Chauhan et al. (US20180103018).
Regarding claim 1, Bronk teaches a system, comprising:
a host processor operable to communicate with a remote requestor to perform sign and verify operations for attesting a trusted system ([0016-017], [0019], and [0040] – a coordination server <host processor> and a computing system <remote requestor> communicate to attest that the computing system <i.e., remote requestor> is utilizing a trusted execution environment <i.e., trusted system attested>. An attestation quote/trusted execution environment key signature are received and verified by the coordination server to confirm the attestation; [0036-037] – the operations performed may be, e.g., sign and verify operations); and
a hardware acceleration coprocessor coupled to the host processor ([0039-041] and [0036-037] – the coordination server <i.e., host processor> is coupled to <i.e., in communication with> a cryptographic module. The cryptographic module 310 performs verification and signature operations on behalf of the coordination server. The cryptographic module 310 may be an independent security co-processor/cryptographic accelerator <i.e., hardware acceleration coprocessor coupled to the coordination server>), wherein the host processor is further operable to offload the sign and the verify operations onto the hardware acceleration coprocessor to free up processing power on the host processor ([0039-041] and [0036-037] – the coordination server <i.e., host processor> is coupled to a cryptographic module. The cryptographic module 310 performs verification and signature operations <i.e., a subset of operations> on behalf of the coordination server <i.e., host module offloads a subset of operations, freeing up processing power>. The cryptographic module 310 may be an independent security co-processor/cryptographic accelerator <i.e., hardware acceleration coprocessor coupled to the coordination server>).
While Bronk teaches determining whether to offload sign operations and/or verify operations to a hardware acceleration processor (see, e.g., Bronk at [0039-041] and [0036-037]), Bronk appears to fail to specifically disclose wherein the host processor is operable to calculate a first threshold of diminishing returns for one of the sign operations based on a first time to perform the one of the sign operations to determine whether to offload the one of the sign operations onto the hardware acceleration coprocessor, wherein the first time is determined based on a first equation, wherein the host processor is operable to calculate a second threshold of diminishing returns for one of the verify operations based on a second time to perform the one of the verify operations to determine whether to offload the one of the verify operations onto the hardware acceleration coprocessor, and wherein the second time is determined based on a second equation that is different than the first equation.
However, Chauhan teaches a similar system for offloading cryptographic operations to a hardware acceleration coprocessor ([0342-0347] – cryptographic operations are offloaded to a cryptographic accelerator when the demand on the processor exceeds a threshold), wherein the host processor is operable to calculate a first threshold of diminishing returns for one of the |first operations| based on a first time to perform the one of the |first operations| to determine whether to offload the one of the |first operations| onto the hardware acceleration coprocessor, wherein the first time is determined based on a first equation ([0329-331] and [0343-344] – an x86 processor or a hardware accelerator are selected to perform a first type of cryptographic operation. When a determined <i.e., calculated> execution threshold is crossed, the system determines it is more optimal to offload the first type of cryptographic operation to the hardware accelerator <i.e., based on a threshold of diminishing returns>. The threshold for offloading the first type of operation to the hardware accelerator is determined based upon, e.g., a comparison of a first time duration <i.e., first time> for processing the first type of operations with the x86 processor vs. a second time duration for processing the first type of operations with the hardware accelerator <i.e., threshold is based upon a first equation using a “first” time>), wherein the host processor is operable to calculate a second threshold of diminishing returns for one of the |second operations| based on a second time to perform the one of the |second operations| to determine whether to offload the one of the |second operations| onto the hardware acceleration coprocessor, and wherein the second time is determined based on a second equation that is different than the first equation ([0329-331] and [0343-344] – an x86 processor or a hardware accelerator are selected to perform a second type of cryptographic operation. When a determined <i.e., calculated> execution threshold is crossed, the system determines it is more optimal to offload the second type of cryptographic operation to the hardware accelerator <i.e., based on a threshold of diminishing returns>. The threshold for offloading the second type of operation to the hardware accelerator is determined based upon, e.g., a comparison of a first <i.e., second> time duration for processing the second type of operations with the x86 processor vs. a second time duration for processing the second type of operations with the hardware accelerator <i.e., threshold is based upon a second equation using a “second” time>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the sign and verify offloading of Bronk with the teachings of Chauhan, wherein the host processor is operable to calculate a first threshold of diminishing returns for one of the sign operations based on a first time to perform the one of the sign operations to determine whether to offload the one of the sign operations onto the hardware acceleration coprocessor, wherein the first time is determined based on a first equation, wherein the host processor is operable to calculate a second threshold of diminishing returns for one of the verify operations based on a second time to perform the one of the verify operations to determine whether to offload the one of the verify operations onto the hardware acceleration coprocessor, and wherein the second time is determined based on a second equation that is different than the first equation, to more optimally execute cryptographic operations using the host processor and/or the hardware acceleration coprocessor (see, e.g., Bronk at [0039-041] and [0036-037]; with Chauhan at [0342-0347] and [0329-331]).
Regarding claim 2, the combination of Bronk and Chauhan teach the system of claim 1, wherein the hardware acceleration coprocessor comprises a processing circuit selected from the group consisting of: an application-specific integrated circuit (ASIC), a programmable logic device (PLD), a graphics processing unit (GPU), and a central processing unit (CPU) (Bronk at [0036] and [0011] – the cryptographic module <i.e., accelerator> uses a processor <i.e., CPU> to perform the cryptographic functions).
Regarding claim 3, the combination of Bronk and Chauhan teach the system of wherein the hardware acceleration coprocessor comprises a field- programmable gate array (FPGA) device (Chauhan at [0355] – the processors/accelerators may be implemented via an FPGA), and wherein the host processor is operable to calculate the first threshold of diminishing returns to determine whether to offload the one of the sign operations onto the FPGA device (Chauhan at [0342-347] – a processor or a cryptographic accelerator are selected to perform a cryptographic operation. A number of factors are used to calculate whether to offload to the cryptographic accelerator. When a predetermined <i.e., calculated> threshold for the processor is crossed, the system determines it is more optimal to offload cryptographic operations to the hardware accelerator <i.e., based on a threshold of diminishing returns>; [0003], [0331-337] – the threshold may be calculated based on a capacity or utilization limit for the respective processor, an expected rate of cryptographic requests, operation size, and/or on an optimal rate of usage for the respective processor/accelerator <i.e., based on a threshold of diminishing returns>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the host processor and hardware acceleration processor of Bronk with the teachings of Chauhan, wherein the hardware acceleration coprocessor comprises a field-programmable gate array (FPGA) device, and wherein the host processor is operable to calculate a threshold of diminishing returns to determine whether or not to offload the one of the sign operations onto the FPGA device, to more optimally execute cryptographic operations using both the host processor and the hardware acceleration coprocessor (see, e.g., Bronk at [0039-041] and [0036-037]; with Chauhan at [0342-0347]).
Regarding claim 4, the combination of Bronk and Chauhan teach the system of claim 1, wherein the host processor is operable to calculate the first threshold of diminishing returns based on a third time to perform the one of the sign operations on the host processor ([0329-331] and [0343-344] – an x86 processor or a hardware accelerator are selected to perform a first type of cryptographic operation. When a determined <i.e., calculated> execution threshold is crossed, the system determines it is more optimal to offload the first type of cryptographic operation to the hardware accelerator <i.e., based on a threshold of diminishing returns>. The threshold for offloading the first type of operation to the hardware accelerator is determined based upon, e.g., a comparison of a first time duration <i.e., first time> for processing the first type of operations with the x86 processor vs. a second time duration <i.e., third time> for processing the first type of operations with the hardware accelerator <i.e., threshold is based upon a first equation using a “first” and “third” time>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the host processor and hardware acceleration processor of Bronk with the teachings of Chauhan to make threshold computations for both signature operations and verify operations. Particularly: wherein the host processor is operable to calculate the first threshold of diminishing returns based on a third time to perform the one of the sign operations on the host processor, to more optimally execute the cryptographic operations using both the host processor and the hardware acceleration coprocessor (see, e.g., Bronk at [0039-041] and [0036-037]; with Chauhan at [0342-0347]).
Regarding claim 5, the combination of Bronk and Chauhan teach the system of claim 1, wherein the host processor is operable to determine whether a number of signatures for the one of the sign operations to be processed is greater than the first threshold of diminishing returns (Chauhan at [0342-347] – a processor or a cryptographic accelerator are selected to perform a cryptographic operation. A number of factors are used to calculate whether to offload to the cryptographic accelerator. When a predetermined threshold for the processor is crossed, the system determines it is more optimal to offload cryptographic operations to the hardware accelerator <i.e., based on a threshold of diminishing returns>; [0005], [0003], and [0331-337] – the threshold may be tested based on an expected rate of cryptographic requests vs. an actually received number of cryptographic requests. The cryptographic requests may be, e.g., signature operations <i.e., number of signature requests exceeds threshold>; Bronk at [0036-041] – cryptographic operations may be, e.g., sign operations). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the host processor and hardware acceleration processor of Bronk with the teachings of Chauhan, wherein the host processor is operable to determine whether a number of signatures for the operations to be processed is greater than the threshold of diminishing returns, to more optimally execute cryptographic operations using both the host processor and the hardware acceleration coprocessor (see, e.g., Bronk at [0039-041] and [0036-037]; with Chauhan at [0342-0347]).
Regarding claim 7, the combination of Bronk and Chauhan teach the system of claim 1, wherein the hardware acceleration coprocessor schedules the one of the sign operations when a number of signatures for the one of the sign operations to be processed is greater than the first threshold of diminishing returns (Bronk at [0036-041] – cryptographic signature operations offloaded may be, e.g., sign operations; Chauhan at [0342-347] – a processor or a cryptographic accelerator are selected to perform a cryptographic operation. A number of factors are used to calculate whether to offload to the cryptographic accelerator. When a predetermined threshold for the processor is crossed, the system determines it is more optimal to offload <i.e., schedule> cryptographic operations on the hardware accelerator <i.e., based on a threshold of diminishing returns>; [0005], [0003], and [0332-337] – the threshold may be tested based on an expected rate of cryptographic requests vs. an actually received number of cryptographic requests. The cryptographic requests may be, e.g., signature operations <i.e., number of signature requests exceeds threshold>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the host processor and hardware acceleration processor of Bronk with the teachings of Chauhan, wherein the hardware acceleration coprocessor schedules the one of the sign operations when a number of signatures for the one of the sign operations to be processed is greater than the first threshold of diminishing returns, to more optimally execute cryptographic operations using both the host processor and the hardware acceleration coprocessor (see, e.g., Bronk at [0039-041] and [0036-037]; with Chauhan at [0342-0347]).
Regarding claim 8, the combination of Bronk and Chauhan teach the system of claim 7, wherein the hardware acceleration coprocessor is operable to write data that is used for prove functions to a memory (Bronk at [0039-041] and [0036-037] – the cryptographic module <i.e., hardware acceleration coprocessor> receives offloaded signature requests which proves a requesting system’s valid membership in an EPID group; [0031] and [0086] – the cryptographic requests stored in memory <i.e., data written to a first memory>) and to invoke a separate prove functional instance for each signature in a signature revocation list (Bronk at [0039-041] and [0036-037] – the cryptographic module <i.e., hardware acceleration coprocessor> receives offloaded signature which proves a requesting system’s valid membership in an EPID group; [0025], [0032], and [0055] – a revocation list is checked to ensure the signature has not been revoked, and attestation is provided; [0031] and [0086] – the cryptographic requests stored in memory <i.e., data written to a first memory>).
Regarding claim 9, the combination of Bronk and Chauhan teach the system of claim 1, wherein the hardware acceleration coprocessor is operable to perform the verify operations that verify membership in a group while maintaining anonymity (Bronk at [0016], [0024-25], and [0043] – EPID group membership is anonymously verified using an EPID public key; [0039-041] and [0036-037] – the cryptographic module <i.e., acceleration coprocessor> performs verification and signature operations on behalf of the coordination server. The cryptographic module may be an independent security co-processor/cryptographic accelerator <i.e., hardware acceleration coprocessor> coupled to the computing system).
Regarding claim 10, Bronk teaches a system, comprising:
a host processor that communicates with a remote requestor to perform sign and verify operations for attesting a trusted system ([0016-017], [0019], and [0040] – a coordination server <host processor> and a computing system <remote requestor> communicate to attest that the computing system <i.e., remote requestor> is utilizing a trusted execution environment <i.e., trusted system attested>. An attestation quote/trusted execution environment key signature are received and verified by the coordination server to confirm the attestation; [0036-037] – the operations performed may be, e.g., sign and verify operations); and
a hardware acceleration coprocessor in communication with the host processor ([0039-041] and [0036-037] – the coordination server <i.e., host processor> is coupled to <i.e., in communication with> a cryptographic module. The cryptographic module 310 performs verification and signature operations on behalf of the coordination server. The cryptographic module 310 may be an independent security co-processor/cryptographic accelerator <i.e., hardware acceleration coprocessor coupled to the coordination server>), wherein the host processor offloads at least a subset of the sign and the verify operations to the hardware acceleration coprocessor ([0039-041] and [0036-037] – the coordination server <i.e., host processor> is coupled to a cryptographic module. The cryptographic module 310 performs verification and signature operations <i.e., a subset of operations> on behalf of the coordination server <i.e., host module offloads a subset of operations, freeing up processing power>. The cryptographic module 310 may be an independent security co-processor/cryptographic accelerator <i.e., hardware acceleration coprocessor coupled to the coordination server>).
While Bronk teaches determining whether to offload sign operations and/or verify operations to a hardware acceleration processor (see, e.g., Bronk at [0039-041] and [0036-037]), Bronk appears to fail to specifically disclose wherein the host processor calculates a first threshold of diminishing returns based on a first time to perform one of the sign operations on the host processor and based on a second time to perform the one of the sign operations on the hardware acceleration coprocessor to determine whether to offload the one of the sign operations to the hardware acceleration coprocessor, and wherein the host processor calculates a second threshold of diminishing returns based on a third time to perform one of the verify operations on the host processor and based on a fourth time to perform the one of the verify operations on the hardware acceleration coprocessor to determine whether to offload the one of the verify operations to the hardware acceleration coprocessor.
However, Chauhan teaches a similar system for offloading cryptographic operations to a hardware acceleration coprocessor ([0342-0347] – cryptographic operations are offloaded to a cryptographic accelerator when the demand on the processor exceeds a threshold), wherein the host processor calculates a first threshold of diminishing returns based on a first time to perform one of the [|first operations|] on the host processor and based on a second time to perform the one of the [|first operations|] on the hardware acceleration coprocessor to determine whether to offload the one of the [|first operations|] to the hardware acceleration coprocessor ([0329-331] and [0343-344] – an x86 processor or a hardware accelerator are selected to perform a first type of cryptographic operation. When a determined <i.e., calculated> execution threshold is crossed, the system determines it is more optimal to offload the first type of cryptographic operation to the hardware accelerator <i.e., based on a threshold of diminishing returns>. The threshold for offloading the first type of operation to the hardware accelerator is determined based upon, e.g., a comparison of a first time duration for processing the first type of operations with the x86 processor vs. a second time duration for processing the first type of operations with the hardware accelerator <i.e., threshold is based upon a “first” time and “second” time determined to perform the first type of operation>), and
wherein the host processor calculates a second threshold of diminishing returns based on a third time to perform one of the [|second operations|] on the host processor and based on a fourth time to perform the one of the [|second operations|] on the hardware acceleration coprocessor to determine whether to offload the one of the [|second operations|] to the hardware acceleration coprocessor ([0329-331] and [0343-344] – an x86 processor or a hardware accelerator are selected to perform a second type of cryptographic operation. When a determined <i.e., calculated> execution threshold is crossed, the system determines it is more optimal to offload the second type of cryptographic operation to the hardware accelerator <i.e., based on a threshold of diminishing returns>. The threshold for offloading the second type of operation to the hardware accelerator is determined based upon, e.g., a comparison of a first <i.e., third> time duration for processing the second type of operations with the x86 processor vs. a second <i.e., fourth> time duration for processing the operations with the hardware accelerator <i.e., threshold is based upon a “third” time and “fourth” time determined to perform the first type of operation>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the sign and verify offloading of Bronk with the teachings of Chauhan, wherein the host processor calculates a first threshold of diminishing returns based on a first time to perform one of the sign operations on the host processor and based on a second time to perform the one of the sign operations on the hardware acceleration coprocessor to determine whether to offload the one of the sign operations to the hardware acceleration coprocessor, and wherein the host processor calculates a second threshold of diminishing returns based on a third time to perform one of the verify operations on the host processor and based on a fourth time to perform the one of the verify operations on the hardware acceleration coprocessor to determine whether to offload the one of the verify operations to the hardware acceleration coprocessor, to more optimally execute cryptographic operations using the host processor and/or the hardware acceleration coprocessor (see, e.g., Bronk at [0039-041] and [0036-037]; with Chauhan at [0342-0347] and [0329-331]).
Regarding claim 11, the combination of Bronk and Chauhan teach the system of claim 10, wherein the hardware acceleration coprocessor comprises a processing circuit selected from the group consisting of: an application-specific integrated circuit (ASIC), a programmable logic device (PLD), a graphics processing unit (GPU), and a central processing unit (CPU) (Bronk at [0036] and [0011] – the cryptographic module <i.e., accelerator> uses a processor <i.e., a CPU> to perform the cryptographic functions).
Regarding claim 13, the combination of Bronk and Chauhan teach the system of claim 10, wherein the hardware acceleration coprocessor executes the subset of the sign and the verify operations comprising implementing a group identity (Bronk at [0039-041] and [0036-037] – the cryptographic module 310 performs verification and signature operations on behalf of the coordination server. E.g., the cryptographic module 310 verifies EPID key signatures/certificates using an EPID public key; [0025] and [0043] – in EPID, each member of the group has a unique private EPID key, and a single public EPID key is used by the cryptographic module 310 to verify each member of a group’s identity <i.e., group identity implemented and verified>), wherein each member of the group identity possesses a unique private key, and verifying each member of the group identity using a public key to verify each of the unique private keys (Bronk at [0039-041] and [0036-037] – the cryptographic module 310 performs verification and signature operations on behalf of the coordination server. E.g., the cryptographic module 310 verifies EPID key signatures/certificates using an EPID public key; [0025] – in EPID, each member of the group has a unique private EPID key, and a single public EPID key is used by the cryptographic module 310 to verify each member of a group’s identity).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the host processor and hardware acceleration coprocessor of Bronk with the teachings of Chauhan, wherein the hardware acceleration coprocessor executes the sign and verify operations comprising implementing a group identity, wherein each member of the group identity possesses a unique private key, and verifying each member of the group identity using a public key to verify each of the unique private keys, to more optimally execute cryptographic operations using both the host processor and the hardware acceleration coprocessor (see, e.g., Bronk at [0039-041] and [0036-037]; with Chauhan at [0342-0347] and [0331]).
Regarding claim 14, the combination of Bronk and Chauhan teach the system of claim 10, wherein the host processor determines whether a number of signatures for the one of the sign operations to be processed is greater than the first threshold of diminishing returns (Chauhan at [0342-347] – a processor or a cryptographic accelerator are selected to perform a cryptographic operation. A number of factors are used to calculate whether to offload to the cryptographic accelerator. When a predetermined threshold for the processor is crossed, the system determines it is more optimal to offload cryptographic operations to the hardware accelerator <i.e., based on a threshold of diminishing returns>; [0005], [0003], and [0331-337] – the threshold may be tested based on an expected rate of cryptographic requests vs. an actually received number of cryptographic requests. The cryptographic requests may be, e.g., signature operations <i.e., number of signature requests exceeds threshold>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the host processor and hardware acceleration coprocessor of Bronk with the teachings of Chauhan, wherein the host processor determines whether a number of signatures for one of the sign operations to be processed is greater than the first threshold of diminishing returns, to more optimally execute cryptographic operations using both the host processor and the hardware acceleration coprocessor (see, e.g., Bronk at [0039-041] and [0036-037]; with Chauhan at [0342-0347] and [0331]).
Regarding claim 16, Bronk teaches a method for offloading a workload to a hardware acceleration coprocessor ([0016-017], [0019], and [0040] – a coordination server <host processor> and a computing system <remote requestor> communicate to attest that the computing system <i.e., remote requestor> is utilizing a trusted execution environment <i.e., trusted system attested>. An attestation quote/trusted execution environment key signature are received and verified by the coordination server to confirm the attestation; [0036-037] – the operations performed may be, e.g., sign and verify operations), the method comprising:
performing sign and verify operations for attesting a trusted system using a host processor that communicates with a remote requestor ([0039-041] and [0036-037] – the coordination server <i.e., host processor> is coupled to a cryptographic module. The cryptographic module 310 performs verification and signature operations <i.e., a subset of operations> on behalf of the coordination server <i.e., host module offloads a subset of operations, freeing up processing power>. The cryptographic module 310 may be an independent security co-processor/cryptographic accelerator <i.e., hardware acceleration coprocessor coupled to the coordination server>).
While Bronk teaches determining whether to offload sign operations and/or verify operations to a hardware acceleration processor (see, e.g., Bronk at [0039-041] and [0036-037]), Bronk appears to fail to specifically disclose determining whether to offload one of the sign operations from the host processor to the hardware acceleration coprocessor by calculating a first threshold of diminishing returns based on a first time to perform the one of the sign operations on the host processor and based on a second time to perform the one of the sign operations on the hardware acceleration coprocessor, wherein the hardware acceleration coprocessor is coupled to the host processor; and determining whether to offload one of the verify operations from the host processor to the hardware acceleration coprocessor by calculating a second threshold of diminishing returns based on a third time to perform the one of the verify operations on the host processor and based on a fourth time to perform the one of the verify operations on the hardware acceleration coprocessor.
However, Chauhan teaches a similar system for offloading cryptographic operations to a hardware acceleration coprocessor ([0342-0347] – cryptographic operations are offloaded to a cryptographic accelerator when the demand on the processor exceeds a threshold), comprising determining whether to offload one of the [|first operations|] from the host processor to the hardware acceleration coprocessor by calculating a first threshold of diminishing returns based on a first time to perform the one of the [|first operations|] on the host processor and based on a second time to perform the one of the [|first operations|] on the hardware acceleration coprocessor, wherein the hardware acceleration coprocessor is coupled to the host processor ([0329-331] and [0343-344] – an x86 processor or a hardware accelerator are selected to perform a first type of cryptographic operation. When a determined <i.e., calculated> execution threshold is crossed, the system determines it is more optimal to offload the first type of cryptographic operation to the hardware accelerator <i.e., based on a threshold of diminishing returns>. The threshold for offloading the first type of operation to the hardware accelerator is determined based upon, e.g., a comparison of a first time duration for processing the first type of operations with the x86 processor vs. a second time duration for processing the first type of operations with the hardware accelerator <i.e., threshold is based upon a “first” time and “second” time determined to perform the first type of operation>); and
determining whether to offload one of the [|second operations|] from the host processor to the hardware acceleration coprocessor by calculating a second threshold of diminishing returns based on a third time to perform the one of the [|second operations|] on the host processor and based on a fourth time to perform the one of the [|second operations|] on the hardware acceleration coprocessor ([0329-331] and [0343-344] – an x86 processor or a hardware accelerator are selected to perform a second type of cryptographic operation. When a determined <i.e., calculated> execution threshold is crossed, the system determines it is more optimal to offload the second type of cryptographic operation to the hardware accelerator <i.e., based on a threshold of diminishing returns>. The threshold for offloading the second type of operation to the hardware accelerator is determined based upon, e.g., a comparison of a first <i.e., third> time duration for processing the second type of operations with the x86 processor vs. a second <i.e., fourth> time duration for processing the operations with the hardware accelerator <i.e., threshold is based upon a “third” time and “fourth” time determined to perform the first type of operation>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the sign and verify offloading of Bronk with the teachings of Chauhan, comprising determining whether to offload one of the sign operations from the host processor to the hardware acceleration coprocessor by calculating a first threshold of diminishing returns based on a first time to perform the one of the sign operations on the host processor and based on a second time to perform the one of the sign operations on the hardware acceleration coprocessor, wherein the hardware acceleration coprocessor is coupled to the host processor; and determining whether to offload one of the verify operations from the host processor to the hardware acceleration coprocessor by calculating a second threshold of diminishing returns based on a third time to perform the one of the verify operations on the host processor and based on a fourth time to perform the one of the verify operations on the hardware acceleration coprocessor, to more optimally execute cryptographic operations using the host processor and/or the hardware acceleration coprocessor (see, e.g., Bronk at [0039-041] and [0036-037]; with Chauhan at [0342-0347] and [0329-331]).
Regarding claim 17, the combination of Bronk and Chauhan teach the method of claim 16, further comprising implementing a group identity (Bronk at [0016], [0024-25], and [0043] – the signature may be an EPID key signature generated with a private EPID key <i.e., unique private key> uniquely corresponding to the trusted execution environment. EPID public keys are keys associated with a group public EPIP key and a particular group identification. The group public EPIP key is used to verify the signature is generated with a private EPID key <i.e., unique private key> of the group to verify group membership), wherein each member of the group identity possesses a unique private key, and verifying each member of the group identity using a public key to verify each of the unique private keys (Bronk at [0016], [0024-25], and [0043] – received signatures may be EPID key signatures generated with private EPID keys <i.e., unique private key> uniquely corresponding to trusted execution environments. EPID public keys are keys associated with a group public EPIP key and a particular group identification. The group public EPIP key is used to verify a signature is generated with a private EPID key <i.e., unique private key> of the group to verify group membership. Multiple signatures of group members generated with respective EPID private keys may be verified at the coordination server by a single EPID public key).
Regarding claim 19, the combination of Bronk and Chauhan teach the method of claim 16 further comprising scheduling the one of the sign operations when a number of signatures for the one of the sign operations to be processed is greater than the first threshold of diminishing returns (Chauhan at [0342-347] – a processor or a cryptographic accelerator are selected to perform a cryptographic operation. A number of factors are used to calculate whether to offload to the cryptographic accelerator. When a predetermined threshold for the processor is crossed, the system determines it is more optimal to offload <i.e., schedule> cryptographic operations on the hardware accelerator <i.e., based on a threshold of diminishing returns>; [0005], [0003], and [0331-337] – the threshold may be tested based on an expected rate of cryptographic requests vs. an actually received number of cryptographic requests. The cryptographic requests may be, e.g., signature operations <i.e., number of signature requests exceeds threshold>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the combination of Bronk and Chauhan with the teachings of Chauhan, further comprising scheduling the one of the sign operations when a number of signatures for the one of the sign operations to be processed is greater than the first threshold of diminishing returns, to more optimally execute cryptographic operations using both the host processor and the hardware acceleration coprocessor (see, e.g., Bronk at [0039-041] and [0036-037]; with Chauhan at [0342-0347]).
Claim(s) 6, 15, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bronk in view of Chauhan, further in view of Liu et al. (US20190213029, hereinafter “Liu”).
Regarding claim 6, the combination of Bronk and Chauhan teach the system of claim 1, as well as accelerating sign bitstreams and verify bitstreams using a cryptographic accelerator ([0039-041] and [0036-037] – The cryptographic module receives and performs verification and signature operations on behalf of the coordination server). Yet, the combination of Bronk and Chauhan appears to fail to specifically disclose wherein the hardware acceleration coprocessor comprises a dynamic configurator that is operable to reallocate programmable resources on the hardware acceleration coprocessor by reconfiguring the programmable resources with more instances of sign bitstreams or more instances of verify bitstreams to perform the at least some of the operations.
However, Liu teaches a similar system for allocating resources between a processor and an accelerator (see, e.g., abstract, [0005], and [0012]), wherein the hardware acceleration coprocessor comprises a dynamic configurator that is operable to reallocate programmable resources on the hardware acceleration coprocessor by reconfiguring the programmable resources with more instances of |first utilization| or more instances of |second utilization| to perform the |first and second utilizations| ([0007], [0012], and [0038-039] – a reconfigurable FPGA is used to accelerate operations for a processor. The FPGA can be reconfigured to perform more operations of a specific type based on thresholds. E.g., a first utilization can be increased and a second utilization can be decreased; [0003] – FPGA operations may be cryptographic operations, e.g., encryption).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Bronk and Chauhan with the teachings of Liu, wherein the hardware acceleration coprocessor comprises a dynamic configurator that is operable to reallocate programmable resources on the hardware acceleration coprocessor by reconfiguring the programmable resources with more instances of sign bitstreams or more instances of verify bitstreams to perform the sign and verify operations, to more optimally execute cryptographic operations using the hardware acceleration coprocessor by adapting to more desired acceleration operations (see, e.g., Bronk at [0039-041] and [0036-037]; with Liu at [0007], [0012], and [0038-039]).
Regarding claim 15, the combination of Bronk and Chauhan teach the system of claim 10, as well as accelerating sign bitstreams and verify bitstreams using a cryptographic accelerator ([0039-041] and [0036-037] – The cryptographic module receives and performs verification and signature operations on behalf of the coordination server). Yet, the combination of Bronk and Chauhan appears to fail to specifically disclose wherein the hardware acceleration coprocessor comprises a dynamic configurator that is operable to reallocate programmable resources on the hardware acceleration coprocessor by reconfiguring the programmable resources with more instances of sign bitstreams or more instances of verify bitstreams to perform the at least some of the operations.
However, Liu teaches a similar system for allocating resources between a processor and an accelerator (see, e.g., abstract, [0005], and [0012]), wherein the hardware acceleration coprocessor comprises a dynamic configurator that is operable to reallocate programmable resources on the hardware acceleration coprocessor by reconfiguring the programmable resources with more instances of |first utilization| or more instances of |second utilization| to perform the at least some of the |first and second utilizations| ([0007], [0012], and [0038-039] – a reconfigurable FPGA is used to accelerate operations for a processor. The FPGA can be reconfigured to perform more operations of a specific type based on thresholds. E.g., a first utilization can be increased and a second utilization can be decreased; [0003] – FPGA operations may be cryptographic operations, e.g., encryption).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Bronk and Chauhan with the teachings of Liu, wherein the hardware acceleration coprocessor comprises a dynamic configurator that is operable to reallocate programmable resources on the hardware acceleration coprocessor by reconfiguring the programmable resources with more instances of sign bitstreams or more instances of verify bitstreams to perform the sign and verify operations, to more optimally execute cryptographic operations using the hardware acceleration coprocessor by adapting to more desired acceleration operations (see, e.g., Bronk at [0039-041] and [0036-037]; with Liu at [0007], [0012], and [0038-039]).
Regarding claim 20, the combination of Bronk and Chauhan teach the method of claim 16, as well as accelerating sign bitstreams and verify bitstreams using a cryptographic accelerator ([0039-041] and [0036-037] – The cryptographic module receives and performs verification and signature operations on behalf of the coordination server). Yet, the combination of Bronk and Chauhan appears to fail to specifically disclose further comprising: reallocating programmable resources on the hardware acceleration coprocessor using a dynamic configurator by reconfiguring the programmable resources with more instances of sign bitstreams or more instances of verify bitstreams to perform the subset of the operations.
However, Liu teaches a similar system for allocating resources between a processor and an accelerator (see, e.g., abstract, [0005], and [0012]), further comprising: reallocating programmable resources on the hardware acceleration coprocessor using a dynamic configurator by reconfiguring the programmable resources with more instances of |first utilization| or more instances of |second utilization| to perform the |first and second utilizations| ([0007], [0012], and [0038-039] – a reconfigurable FPGA is used to accelerate operations for a processor. The FPGA can be reconfigured to perform more operations of a specific type based on thresholds. E.g., a first utilization can be increased and a second utilization can be decreased; [0003] – FPGA operations may be cryptographic operations, e.g., encryption).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Bronk and Chauhan with the teaching