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 .
DETAILED ACTION
Currently pending claims are 1 – 31.
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.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the exclaimed 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 – 21, 23 – 27 & 31 are rejected under 35 U.S.C.103 as being unpatentable over Yitbarek et al. (U.S. Patent 2020/0145419), in view of Pittelko et al. (U.S. Patent 9,076,021).
As per claim 1, 9 & 15, Yitbarek teaches an apparatus to be configured at a compute server, the apparatus comprising:
a processor (Yitbarek: FIG. 1 / E-120);
a memory (Yitbarek: FIG. 1 / E-128); and
circuitry of a trusted execution environment (TEE), the TEE to include a trusted computing base that includes at least one core of the processor and at least a portion of the memory, wherein the circuitry is configured to (Yitbarek: see above, FIG. 1, 2 & Para [0028] / [0003] / [0145] / [0150] and Para [0049] Line 6 – 8: each of a computing device can include, at least one, processor(s)/memory, trusted computing base (TCB) of a TEE as well as accelerator(s) for offloading computing-intensive workload (Para [0003] / [0145] & FIG. 1 / FIG. 2), wherein a trusted IO device (TIO device) can function as an accelerator (Para [0049] Line 6 – 8)), and
authenticate an accelerator at a service server that is to be coupled with the compute server via a communication link routed through a fabric (Yitbarek: see above, FIG. 3 & Para [0065] Line 1 – 2 / Line 5 – 12, Para [0028] / [0003] / [0145] / [0150] and Para [0049] Line 6 – 8
(a) each of the computing device can be either a computer server or a service server w.r.t. a relative location coupled with a network (i.e. fabric) routed via a communication link – (e.g.) located at the local side can be referred as a local computer server and at the remote side is thus referred as a service server respectively (Para [0150]), wherein both of the local computer server and the remote service server can include an accelerator for offloading computing-intensive workload (Para [0003] / [0145]) such as a trusted IO device (i.e. TIO device: Para [0049] Line 6 – 8), and
(b) authenticating an accelerator (e.g. a TIO device), at a remote service server, based upon performing an attestation protocol by receiving an attestation report from the TIO device (i.e. accelerator) so that a provision agent (PA) of a trusted agent (TA) at the local computer server can thus remotely verify that the attestation report is authentic by verifying one or more attributes of the TIO device (Para [0065] Line 1 – 2 / Line 5 – 12).
cause a key table to be programmed and maintained at the accelerator, the key table for use by the accelerator to identify at least one session key to use to decrypt encrypted data sent from or destined to the TEE.
(a) Yitbarek teaches executing an authenticated key agreement protocol between both of the trust agent (at a TEE of a computer server) and the TIO device (i.e. an accelerator of a service server) so as to possess a shared session key to decrypt the encrypted data between the communication link (Yitbarek: Para [0120] Line 1 – 7) and Yitbarek further teaches providing (forwards) a peer-to-peer communication key (e.g. a session key (see above)) to the TIO device (i.e. accelerator) so as to encrypt / decrypt communications over peer-to-peer communication link (Yitbarek: Para [0150] Line 1 – 10).
(b) Yitbarek further teaches maintaining a key table with multiple encryption / decryption (symmetric) keys which are used to encrypt / decrypt data as it is stored and the security keys can be selected base on key identifiers associated with (e.g.) a portion of bits of the accessed memory page address (Yitbarek: Para [0031] Line 14 – 23). However, Yitbarek does not disclose expressly causing a key table to be programmed and maintained at the accelerator to use to decrypt encrypted data sent from or destined to the TEE.
(c) In view of that, Pittelko (as a 2nd reference) teaches providing a security mechanism for managing a request from a requestor for accessing encrypted data of a remote data storage system, wherein the destined data storage system (e.g. as an accelerator of a service server) can receive a service request from a requestor (e.g. as a TEE of a computer server) to decrypt the encrypted data using one of the decryption key(s) by configuring (programming) a decryption module, at the remote side (e.g. the accelerator), to provide one or more decryption keys as required to access the encrypted data (Pittelko: Col. 3 Line 45 – 47 / Line 26 – 30), and accordingly, Pittelko further teaches providing a key table which can be used (configured / programmed) to associate one or more decryption key identifiers (indexes) with corresponding decryption keys for accessing encrypted data, wherein each encryption / decryption key is changed at each of snapshots corresponding to different decryption key identifiers and the decryption keys as well as the encryption keys can be symmetric at each of snapshots (e.g. as a session key) (Pittelko: Col. 3 Line 18 – 23 / Line 36 – 40) – this is consistent with the disclosure of the instant specification (SPEC-PG.PUB: Para [0034] Line 6 – 10 & Para [0053] Line 11 – 13: (a) a TEE of a computer server can send a request to an accelerator (at the service server) and the requested service can be a storage service that provides access to a storage array by TEE using security keys, and (b) the indicated key index value refers to a row of a key table of the corresponding security keys).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to propose the modification of causing a key table to be programmed and maintained at the accelerator because Pittelko teaches to alternatively, effectively and securely provide a security mechanism for managing a request from a requestor for accessing encrypted data of a remote data storage system, wherein the destined data storage system (e.g. as an accelerator of a service server) can receive a service request from a requestor (e.g. as a TEE of a computer server) to decrypt the encrypted data using one of the decryption key(s) by configuring (programming) a decryption module, at the remote side (e.g. the accelerator), to provide one or more decryption keys as required to access the encrypted data, and accordingly, Pittelko further teaches providing a key table which can be used (configured / programmed) to associate one or more decryption key identifiers (indexes) with corresponding decryption keys for accessing encrypted data, wherein each encryption / decryption key is changed at each of snapshots corresponding to different decryption key identifiers and the decryption keys as well as the encryption keys can be symmetric at each of snapshots (e.g. as a session key) (see above) within the Yitbarek’s system of (a) executing an authenticated key agreement protocol between both of the trust agent (at a TEE of a computer server) and the TIO device (i.e. an accelerator of a service server) so as to possess a shared session key to decrypt the encrypted data between the communication link and further providing (forwards) a peer-to-peer communication key (e.g. a session key) to the TIO device (i.e. accelerator) so as to encrypt / decrypt communications over peer-to-peer communication link and (b) maintaining a key table with multiple encryption / decryption (symmetric) keys which are used to encrypt / decrypt data as it is stored and the security keys can be selected base on key identifiers associated with (e.g.) a portion of bits of the accessed memory page address (see above).
As per claim 19, the claim limitations are met as the same reasons as that set forth in the paragraph above regarding to claim 1 with the exception of the feature(s) to:
receive a programming request from the TEE to program a key table for use to identify at least one session key to use to decrypt encrypted data sent from or destined to the TEE (Pittelko: see above & Col. 3 Line 45 – 47 / Line 26 – 30 / Line 18 – 23 / Line 36 – 40:
(a) First of all, Yitbarek teaches maintaining a key table with multiple encryption / decryption (symmetric) keys which are used to encrypt / decrypt data as it is stored and the security keys can be selected base on key identifiers associated with (e.g.) a portion of bits of the accessed memory page address (Yitbarek: Para [0031] Line 14 – 23); and
(b) Pittelko (as a 2nd reference) teaches providing a security mechanism for managing a request from a requestor for accessing encrypted data of a remote data storage system, wherein the destined data storage system (e.g. as an accelerator of a service server) can receive a service request from a requestor (e.g. as a TEE of a computer server) to decrypt the encrypted data using one of the decryption key(s) by configuring (programming) a decryption module, at the remote side (e.g. the accelerator), to provide one or more decryption keys as required to access the encrypted data (Pittelko: Col. 3 Line 45 – 47 / Line 26 – 30), and accordingly,
(c) Pittelko further teaches providing a key table which can be used (configured / programmed) to associate one or more decryption key identifiers (indexes) with corresponding decryption keys for accessing encrypted data, wherein each encryption / decryption key is changed at each of snapshots corresponding to different decryption key identifiers and the decryption keys as well as the encryption keys can be symmetric at each of snapshots (e.g. as a session key) (Pittelko: Col. 3 Line 18 – 23 / Line 36 – 40) – this is consistent with the disclosure of the instant specification (SPEC-PG.PUB: Para [0034] Line 6 – 10 & Para [0053] Line 11 – 13: (a) a TEE of a computer server can send a request to an accelerator (at the service server) and the requested service can be a storage service that provides access to a storage array by TEE using security keys, and (b) the indicated key index value refers to a row of a key table of the corresponding security keys).
As per claim 27, the claim limitations are met as the same reasons as that set forth in the paragraph above regarding to claim 1 & claim 19, wherein:
an accelerator device to include circuitry configured to: exchange information with trusted execution environment (TEE) at a compute server to be coupled with the service server via a communication link routed through a fabric, the exchanged information to authenticate the accelerator device to the TEE at the compute server; and securely share one or more session keys with the TEE at the compute server to use to decrypt encrypted data sent from or destined to the TEE at the compute server or to encrypt transformed data generated using decrypted encrypted data (NOTE: please refer to: CLAIM 19 and any other associated claims with similar rationales (see above)).
a service TEE, the service TEE to include a trusted computing base that includes at least one core of a processor hosted by the service server and at least a portion of a memory hosted by the service server, wherein the service TEE includes circuitry, the circuitry of the service TEE is configured to: exchange information with a TEE at the compute server via the communication link routed through the fabric, the exchanged information to authenticate the service TEE to the TEE at the compute server; and securely share the one or more session keys with the TEE at the compute server to use to decrypt encrypted data sent from or destined to the TEE at the compute server or to encrypt transformed data generated by the accelerator device using decrypted encrypted data (NOTE: please refer to CLAIM 1: each of a computing device can include, at least one, processor(s)/memory, trusted computing base (TCB) of a TEE as well as accelerator(s), such as a trusted IO device (TIO device), for offloading computing-intensive workload (Yitbarek: see above & Para [0003] / [0145], Para [0049] Line 6 – 8 & FIG. 1 / FIG. 2)).
As per claim 2, 10 & 16, Yitbarek as modified teaches to generate a work request for the accelerator to perform a transformation operation on data included in encrypted data, the work request to include information for the accelerator to identify a session key to use to decrypt the encrypted data based on the programmed key table, the work request to indicate that transformed data is to be encrypted using the session key and sent towards a destination indicated in the work request; and cause the work request to be sent to the accelerator (Yitbarek: see above & FIG. 13 / E-1308, FIG. 14 / E-1420, Para [0125] Last sentence and Para [0120]: deriving / verifying an integrity with MAC of a device configuration report by performing a transformation operation on the target data along with a (symmetric) session key) on each data-block of (e.g.) firmware version, register/memory configuration block, and link encryption status data-block) || (Pittelko: see above: using a key table along with a plurality of key identifiers (indexes) for encryption / decryption associated with the target data).
As per claim 3, 11, 17 & 21, Yitbarek as modified teaches the destination indicated in the work request comprises a storage device coupled with the service server, wherein the transformation operation includes compressing data included in the decrypted data, de-duplicating data included in the decrypted data or re-compressing data included in the decrypted data (Yitbarek: see above & Para [0102] Line 1 – 4, FIG. 13 / E-1308, FIG. 14 / E-1420, Para [0125] Last sentence and Para [0120]: (a) the destination of an accelerator (i.e. TIO device) includes a storage device, (b) performing a transformation operation on the target data w.r.t. an integrity with MAC of a device configuration report along with a (symmetric) session key) on each data-block of (e.g.) firmware version, register/memory configuration block, and link encryption status data-block) || (Pittelko: see above: using a key table along with a plurality of key identifiers (indexes) for encryption / decryption associated with the target data (e.g. the decrypted data)).
As per claim 4 & 12, Yitbarek as modified teaches the transformation operation includes compressing data included in the decrypted data, wherein the decrypted data includes one or more data-blocks, each data-block having a hash value generated by the circuitry, respective generated hash values to be used to verify an integrity of each data-block (Pittelko: see above: using a key table along with a plurality of key identifiers (indexes) for encryption / decryption associated with the target data (e.g. the decrypted data)) || (Yitbarek: see above & Para [0102] Line 1 – 4, FIG. 13 / E-1308, FIG. 14 / E-1420 (E-1422 / E-1424 / E-1426), Para [0125] Last sentence and Para [0120]: performing a transformation operation on the target data w.r.t. an integrity with MAC of a device configuration report along with a (symmetric) session key) on each data-block of (e.g.) firmware version, register/memory configuration block, and link encryption status data-block).
As per claim 5 – 6, 13 – 14, 18, 20 & 23, the instant claim is directed to a claimed content having functionality corresponding to the Claims 1 – 4, and are rejected by a similar rationale.
As per claim 7 & 31, Yitbarek as modified teaches the circuitry is configured to authenticate the accelerator via establishment of a secure communication session with the accelerator according to a Secure Protocol and Data Model (SPDM) specification (Yitbarek: see above and FIG. 14 / E-1414 & E-1404: establishing a secure channel by using authenticated key agreement protocol with secure arbitration mode (SEAM), which constitutes as one type of Secure Protocol and Data Model) || (Pittelko: see above).
As per claim 8, Yitbarek as modified teaches wherein the circuitry of the TEE comprises a core of the processor, a field programmable gate array, or an application specific integrated circuit (Yitbarek: see above & FIG. 1 /2 and Para [0003]).
As per claim 24, Yitbarek as modified teaches wherein to identify the session key to use to decrypt the encrypted data based on information included in the work request comprises the work request indicating a key table index value that is assigned to an entry in the programmed key table that includes the session key (Yitbarek: see above & Para [0031] Line 14 – 23: maintaining a key table with multiple encryption / decryption (symmetric) keys which are used to encrypt / decrypt data as it is stored and the security keys can be selected base on key identifiers associated with (e.g.) information such as a portion of bits of the accessed memory page address) || (Pittelko: see above).
As per claim 25, Yitbarek as modified teaches the work request indicating a key table index value that is assigned to an entry in the programmed key table that includes a wrapping key, the work request to also include information for the circuitry to use the wrapping key to decrypt the session key that was encrypted using the wrapping key (Yitbarek: see above & Para [0067] Line 7 – 13: providing an authenticated key exchange protocol with provision key (e.g. a session key) wrapped with a wrapping key).
As per claim 26, the instant claim is directed to a claimed content having functionality corresponding to the Claims 1 – 4 & 19, and are rejected by a similar rationale.
Claims 22 & 28 – 30 are rejected under 35 U.S.C.103 as being unpatentable over Yitbarek et al. (U.S. Patent 2020/0145419), in view of Pittelko et al. (U.S. Patent 9,076,021), and in view of Xia et al. (CN 10-794-7981 A).
As per claim 22, Xi (& Yitbarek as modified) teaches compressing data included in the decrypted data, and wherein the circuitry is further configured to: generate a first cyclic redundancy check (CRC) value using the clear text data; compress the clear text data to generate the transformed data; encrypt the transformed data with the first CRC value; and perform a reverse transform operation following encryption of the transformed data, the reverse transform operation to include the circuitry to decrypt the encrypted transformed data with the first CRC value, decompress the decrypted transformed data to regenerate the clear text data, calculate a second CRC value using the regenerated clear text data, and compare the second CRC value with the first CRC value to determine if the regenerated clear text data is different than the clear text data that was compressed (Yitbarek & Pittelko: see above) || (Xi: Page 9 / 3rd Para: Xi teaches providing a network device management method and securely processing clear data along with a typical CRC value for data integrity to ensure the original clear data has not been tampered or destroyed, wherein the process started with a comparison (validation) mechanism by first transcoding a software entity (e.g. a file) into clear data, and then compressing the clear data, encrypting the compressed data along with a corresponding CRC check value for verification and, at the opposite side, the entire process can be proceeded reversely for data integrity check started from decryption, followed with decompression for a secure CRC validation (again) to ensure the original clear data has not been tampered or destroyed).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to propose the modification of providing a securely process including data compression, encryption and CRC validation because Xi teaches to alternatively, effectively and securely provide a network device management method and securely processing clear data along with a typical CRC value for data integrity, wherein the process started with a comparison (validation) mechanism by first transcoding a software entity (e.g. a file) into clear data, and then compressing the clear data, encrypting the compressed data along with a corresponding CRC check value for verification and, at the opposite side, the entire process can be proceeded reversely for data integrity check started from decryption, followed with decompression for a secure CRC validation to ensure the original clear data has not been tampered or destroyed (see above) within the Yitbarek’s system of executing an authenticated key agreement protocol between both of the trust agent (at a TEE of a computer server) and the TIO device (i.e. an accelerator of a service server) so as to possess a shared session key to decrypt the encrypted data between the communication link and further providing (forwards) a peer-to-peer communication key (e.g. a session key) to the TIO device (i.e. accelerator) so as to encrypt / decrypt communications over peer-to-peer communication link (see above).
As per claim 28 – 30, the instant claim is directed to a claimed content having functionality corresponding to the Claims 1 – 4, 22 & 27, and are rejected by a similar rationale along with a repetitive (repeated) concept of subject matters that renders
insignificance of patentability.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LONGBIT CHAI whose telephone number is (571)272-3788. The examiner can normally be reached Monday - Friday 9:00am-5:00pm.
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, Lynn D. Feild can be reached at 571-272-2092. 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.
---------------------------------------------------
/Longbit Chai/
Primary Examiner, Art Unit 2431
No. #2580 – 2025 ---------------------------------------------------