DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to the Amendment filed on 04/07/2026.
In the instant Amendment: Claims 1, 16-20 have been amended, claim 8 has been cancelled. Claims 1-7, 9-20 have been examined and are pending. This Action is made FINAL.
Response to Arguments
Rejection under 35 U.S.C. 101 is withdrawn in response to amendment.
Interpretation under 35 U.S.C. 112(f) is withdrawn as claim 8 has been cancelled.
Applicants’ arguments with respect to amended claims 1 has been considered but are moot in view of the new ground(s) of rejection. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action.
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 discloses as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 9-12, 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Sprague et al. (“Sprague,” US 20160275461, published Sep. 22, 2016) in view of Sarangdhar et al. (“Sarangdhar,” US 20160142212, published May 19, 2016) and Pogorelik et al. (“Pogorelik,” US 20170187783, published June 29, 2017).
Regarding claim 1, Sprague discloses
A TEE-based method to establish trusted and secure channel between the user and public cloud environment, configured to establish a secure communication channel between the user and a TEE (Trusted Execution Environment) in a cloud server (Sprague [0038], [0043], [0061], [0080]. Example embodiments may be founded on the principles of the Trusted Network Connect (TNC) standards under which the integrity of a device may be verified prior to actual enablement of the connection to a network switch. The Trusted Execution Environment (TEE) is also capable of self-measurement processes and remote attestation of the health of the device. Server computers 160 may be configured to provide a user device authentication system 100 which communicates with authenticators to confirm a requestor's identity prior to allowing the requestor to access resources protected by the authentication system. The server computers may not be separate server computers but part of cloud network 170. The TEE offers an execution space that provides a higher level of security than a Rich OS. In another example embodiment, the TEE may be implemented as a virtual machine. The TEE Adapter 216 may be configured as the interface between the Device Rivet/TEE applet 208 bolted into the TEE and the outside world of partner apps and online services.), comprising:
after the TEE is started, calling a trusted measurement mechanism of the TEE to perform security measurement on an operation environment and an operation content of a computing node operated in the TEE, and sending a measurement result to a trusted verification module, wherein the trusted verification module is operated in a [second] TEE (Sprague [0038], [0061], [0114]. Example embodiments may be founded on the principles of the Trusted Network Connect (TNC) standards under which the integrity of a device may be verified prior to actual enablement of the connection to a network switch. According to TNC, a device performs a series of measurements that are securely stored on the device. The measurements typically would include validation of the BIOS image, the operating system (OS) and any applications that need to be verified that they have not been altered. Upon connection to the network, the switch would perform a validation process verifying that the measurement data matches a reference value that was computed when the device was either previously connected or in a current known good condition or state. The Trusted Execution Environment (TEE) is also capable of self-measurement processes and remote attestation of the health of the device. The TEE offers an execution space that provides a higher level of security than a Rich OS. In another example embodiment, the TEE may be implemented as a virtual machine. Verification can be done locally or remotely and may include additional user verification, confirmation or signature from logging systems, other critical process steps, location or time.);
acquiring relevant verification information from a remote verification server of the TEE, and controlling the trusted verification module to verify [the NONCE field and the MAC in the] measurement result according to the relevant verification information, so as to determine whether the operation environment of the computing node is credible and whether the operation content of the computing node is secure (Sprague [0038], [0061], [0075]. Example embodiments may be founded on the principles of the Trusted Network Connect (TNC) standards under which the integrity of a device may be verified prior to actual enablement of the connection to a network switch. According to TNC, a device performs a series of measurements that are securely stored on the device. The measurements typically would include validation of the BIOS image, the operating system (OS) and any applications that need to be verified that they have not been altered. Upon connection to the network, the switch would perform a validation process verifying that the measurement data matches a reference value that was computed when the device was either previously connected or in a current known good condition or state. The Trusted Execution Environment (TEE) is also capable of self-measurement processes and remote attestation of the health of the device. The TEE offers an execution space that provides a higher level of security than a Rich OS. In another example embodiment, the TEE may be implemented as a virtual machine. This measurement may be requested directly of the Device Adaptor or fetched by the server through a persistent sockets connection with the device. The current measurement is compared against the gold measurement or Reference Value in the block chain. If the measurements match the transaction is signed. If the measurements do not match, the request is rejected. If the measurements do not match, the device may be put through a registration renewal where a new measurement is gathered. Every time a measurement matches, the device registration record can be updated with a success count.); and
when it is confirmed that the operation environment of the computing node is credible and the operation content of the computing node is secure, establishing a communication channel between the user and the computing node (Sprague [0038], [0043], [0075]. Example embodiments may be founded on the principles of the Trusted Network Connect (TNC) standards under which the integrity of a device may be verified prior to actual enablement of the connection to a network switch. According to TNC, a device performs a series of measurements that are securely stored on the device. The measurements typically would include validation of the BIOS image, the operating system (OS) and any applications that need to be verified that they have not been altered. Upon connection to the network, the switch would perform a validation process verifying that the measurement data matches a reference value that was computed when the device was either previously connected or in a current known good condition or state. The Trusted Execution Environment (TEE) is also capable of self-measurement processes and remote attestation of the health of the device. Server computers 160 may be configured to provide a user device authentication system 100 which communicates with authenticators to confirm a requestor's identity prior to allowing the requestor to access resources protected by the authentication system. The server computers may not be separate server computers but part of cloud network 170. The current measurement is compared against the gold measurement or Reference Value in the block chain. If the measurements match the transaction is signed. If the measurements do not match, the request is rejected. If the measurements do not match, the device may be put through a registration renewal where a new measurement is gathered. Every time a measurement matches, the device registration record can be updated with a success count.).
Sprague does not explicitly disclose: wherein the trusted verification module is operated in a second TEE.
However, in an analogous art, Sarangdhar discloses a method, comprising: wherein the trusted verification module is operated in a second TEE (Sarangdhar [0019], [0022]. FIG. 1 illustrates an example system for TPM certification and attestation utilizing an anonymous key system in accordance with at least one embodiment of the present disclosure. System 100 may comprise, for example, at least device 102 and remote resource 104. A cloud computing architecture may comprise, for example, a plurality of data servers operating individually or in unison to provide various data processing-related services to user device 102. For example, TPM FW module 200 may be loaded into trusted execution environment (TEE) 202 and AKS FW module 204 may be loaded into TEE 206. TEEs 204 and 206 may comprise protected areas of memory in which known-good programs may execute, confidential information may be stored in a secure manner, etc.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Sarangdhar and Sprague to include the step of: wherein the trusted verification module is operated in a second TEE. One would have been motivated to provide user with a means of gaining authenticated access to a program or service that is operated in a plurality of TEE environments. (See Saranghar [0022].)
Sprague and Sarangdhar do not explicitly disclose: the measurement result includes a NONCE field and an integrity protection field denoted as MAC in the security of the trusted verification module; the NONCE field and the MAC field in the measurement result.
However, in an analogous art, Pogorelik discloses a method, comprising the steps of:
the measurement result includes a NONCE field and an integrity protection field denoted as MAC in the security of the trusted verification module; the NONCE field and the MAC field in the measurement result (Pogorelik [0062]-[0063]. Sensor device 104-1 may be configured to perform one or more functions in a trusted execution environment (TEE), such as within an access-protected region of a memory device, with a dynamic application loader, and/or with software guard extensions. A TEE may provide and/or improve integrity and/or security. Sensor device 104-1 may be configured to broadcast measurements to include a device ID (e.g., a MAC address) and/or a running frame counter, and/or to sign broadcasts with a hardware-based key for device authentication/attestation. This may to provide and/or enhance integrity and/or security.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Pogorelik, Sarangdhar and Sprague to include the step of: the measurement result includes a NONCE field and an integrity protection field denoted as MAC in the security of the trusted verification module; the NONCE field and the MAC field in the measurement result. One would have been motivated to provide user with a means for generating a set of verifiable measurements or states of a TEE environment. (See Pogorelik [0063].)
Regarding claim 2, Sprague, Sarangdhar and Pogorelik disclose the method of claim 1. Sprague further discloses
wherein when it is confirmed that the operation environment of the computing node is credible and the operation content of the computing node is secure, establishing the communication channel between the user and the computing node further comprises (Sprague [0038], [0043], [0075]. Example embodiments may be founded on the principles of the Trusted Network Connect (TNC) standards under which the integrity of a device may be verified prior to actual enablement of the connection to a network switch. According to TNC, a device performs a series of measurements that are securely stored on the device. The measurements typically would include validation of the BIOS image, the operating system (OS) and any applications that need to be verified that they have not been altered. Upon connection to the network, the switch would perform a validation process verifying that the measurement data matches a reference value that was computed when the device was either previously connected or in a current known good condition or state. The Trusted Execution Environment (TEE) is also capable of self-measurement processes and remote attestation of the health of the device. Server computers 160 may be configured to provide a user device authentication system 100 which communicates with authenticators to confirm a requestor's identity prior to allowing the requestor to access resources protected by the authentication system. The server computers may not be separate server computers but part of cloud network 170. The current measurement is compared against the gold measurement or Reference Value in the block chain. If the measurements match the transaction is signed. If the measurements do not match, the request is rejected. If the measurements do not match, the device may be put through a registration renewal where a new measurement is gathered. Every time a measurement matches, the device registration record can be updated with a success count.):
when it is confirmed that the operation environment of the computing node is credible and the operation content of the computing node is secure, controlling the trusted verification module to sign a public key of the computing node to generate a digital certificate, and sending the digital certificate to the computing node (Sprague [0094]. An embodiment may be a method for creating a birth certificate for a user device in a block chain communication network comprising: establishing a device identity for the user device by generating a public/private key pair that is locked to the user device; signing of the public key of the device by an endorsement key established during manufacturing or creation of the device, manufacturing or creation of the execution environment of the device and/or manufacturing or creation of an application on the device; and enrolling the device with a trusted third party including: requesting and obtaining the generated public key from the device; requesting and obtaining a device measurement record of the device containing attributes related to the device Platform Configuration Registers (PCR), BIOS, OS and/or GPS; endorsing of the device measurement record by the third party and the device; and registering the device into the block chain including posting the endorsed device measurement record into a public cryptographic ledger.); and
establishing the communication channel between the user and the computing node by the digital certificate (Sprague [0038], [0094]. Example embodiments may be founded on the principles of the Trusted Network Connect (TNC) standards under which the integrity of a device may be verified prior to actual enablement of the connection to a network switch. According to TNC, a device performs a series of measurements that are securely stored on the device. The measurements typically would include validation of the BIOS image, the operating system (OS) and any applications that need to be verified that they have not been altered. Upon connection to the network, the switch would perform a validation process verifying that the measurement data matches a reference value that was computed when the device was either previously connected or in a current known good condition or state. The Trusted Execution Environment (TEE) is also capable of self-measurement processes and remote attestation of the health of the device. An embodiment may be a method for creating a birth certificate for a user device in a block chain communication network comprising: establishing a device identity for the user device by generating a public/private key pair that is locked to the user device; signing of the public key of the device by an endorsement key established during manufacturing or creation of the device, manufacturing or creation of the execution environment of the device and/or manufacturing or creation of an application on the device; and enrolling the device with a trusted third party including: requesting and obtaining the generated public key from the device; requesting and obtaining a device measurement record of the device containing attributes related to the device Platform Configuration Registers (PCR), BIOS, OS and/or GPS; endorsing of the device measurement record by the third party and the device; and registering the device into the block chain including posting the endorsed device measurement record into a public cryptographic ledger.).
Regarding claim 3, Sprague, Sarangdhar and Pogorelik disclose the method of claim 1. Sprague further discloses wherein calling the trusted measurement mechanism of the TEE to perform security measurement on the operation environment and the operation content of the computing node operated in the TEE, and sending the measurement result to the trusted verification module further comprises: calling the trusted measurement mechanism of the TEE to perform security measurement on the operation environment and the operation content of the computing node operated in the TEE (Sprague [0061], [0075]. The TEE offers an execution space that provides a higher level of security than a Rich OS. In another example embodiment, the TEE may be implemented as a virtual machine. This measurement may be requested directly of the Device Adaptor or fetched by the server through a persistent sockets connection with the device. The current measurement is compared against the gold measurement or Reference Value in the block chain. If the measurements match the transaction is signed. If the measurements do not match, the request is rejected. If the measurements do not match, the device may be put through a registration renewal where a new measurement is gathered. Every time a measurement matches, the device registration record can be updated with a success count.),
generating a measurement report based on the measurement result, and sending the measurement report to the trusted verification module (Sprague [0038], [0061], [0075]. The measurements typically would include validation of the BIOS image, the operating system (OS) and any applications that need to be verified that they have not been altered. Upon connection to the network, the switch would perform a validation process verifying that the measurement data matches a reference value that was computed when the device was either previously connected or in a current known good condition or state. The Trusted Execution Environment (TEE) is also capable of self-measurement processes and remote attestation of the health of the device. The TEE offers an execution space that provides a higher level of security than a Rich OS. In another example embodiment, the TEE may be implemented as a virtual machine. This measurement may be requested directly of the Device Adaptor or fetched by the server through a persistent sockets connection with the device. The current measurement is compared against the gold measurement or Reference Value in the block chain. If the measurements match the transaction is signed. If the measurements do not match, the request is rejected. If the measurements do not match, the device may be put through a registration renewal where a new measurement is gathered. Every time a measurement matches, the device registration record can be updated with a success count.).
Regarding claim 4, Sprague, Sarangdhar and Pogorelik disclose the method of claim 3. Sprague further discloses wherein controlling the trusted verification module to verify the measurement result according to the relevant verification information further comprises: controlling the trusted verification module to verify the measurement report according to the relevant verification information (Sprague [0038], [0075]. Example embodiments may be founded on the principles of the Trusted Network Connect (TNC) standards under which the integrity of a device may be verified prior to actual enablement of the connection to a network switch. According to TNC, a device performs a series of measurements that are securely stored on the device. The measurements typically would include validation of the BIOS image, the operating system (OS) and any applications that need to be verified that they have not been altered. Upon connection to the network, the switch would perform a validation process verifying that the measurement data matches a reference value that was computed when the device was either previously connected or in a current known good condition or state. The Trusted Execution Environment (TEE) is also capable of self-measurement processes and remote attestation of the health of the device. The current measurement is compared against the gold measurement or Reference Value in the block chain. If the measurements match the transaction is signed. If the measurements do not match, the request is rejected. If the measurements do not match, the device may be put through a registration renewal where a new measurement is gathered. Every time a measurement matches, the device registration record can be updated with a success count.)
Regarding claim 9, claim 9 is directed to a computer device corresponding to the method of claim 1. Claim 9 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding claim 10, claim 10 is directed to a computer device corresponding to the method of claim 2. Claim 10 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Regarding claim 11, claim 11 is directed to a computer device corresponding to the method of claim 3. Claim 11 is similar in scope to claim 3 and is therefore rejected under similar rationale.
Regarding claim 12, claim 12 is directed to a computer device corresponding to the method of claim 4. Claim 12 is similar in scope to claim 4 and is therefore rejected under similar rationale.
Regarding claim 16, claim 16 is directed to a non-transitory computer-readable storage medium corresponding to the method of claim 1. Claim 16 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding claim 17, claim 17 is directed to a non-transitory computer-readable storage medium corresponding to the method of claim 2. Claim 17 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Regarding claim 18, claim 18 is directed to a non-transitory computer-readable storage medium corresponding to the method of claim 3. Claim 18 is similar in scope to claim 3 and is therefore rejected under similar rationale.
Regarding claim 19, claim 19 is directed to a non-transitory computer-readable storage medium corresponding to the method of claim 4. Claim 19 is similar in scope to claim 4 and is therefore rejected under similar rationale.
Claims 5-7, 13-15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Sprague et al. (“Sprague,” US 20160275461, published Sep. 22, 2016) in view of Sarangdhar et al. (“Sarangdhar,” US 20160142212, published May 19, 2016), Pogorelik et al. (“Pogorelik,” US 20170187783, published June 29, 2017) and Li et al. (“Li,” US 20220188146, filed Dec. 16, 2020).
Regarding claim 5, Sprague, Sarangdhar and Pogorelik disclose the method of claim 1.
Sprague, Sarangdhar and Pogorelik do not explicitly disclose: receiving a connection request for the TEE from the user, and creating or starting the TEE.
However, in an analogous art, Li discloses a method, comprising the step of: wherein before calling the trusted measurement mechanism of the TEE to perform security measurement on the operation environment and the operation content of the computing node operated in the TEE, the method further comprises: receiving a connection request for the TEE from the user, and creating or starting the TEE (Li [0031], [0044]. In an embodiment, these services requests may be made using system calls to the TEE backend module 234 inside the VMkernel 224. In response to these service requests, the hardware TEE mechanism 214 is engaged by the TEE backend module 234 to fulfill the requested services or operations. In an embodiment, this engagement or interaction may involve issuing appropriate TEE commands for the requested services to the hardware TEE mechanism 214, which would cause the hardware TEE mechanism to execute the requested services or operations, such as TEE creation, TEE configuration, TEE execution and TEE removal operations. The TEE migration process begins at step 502, where a request to migrate the source TEE 402A in the source host computer 404A to another host computer in the cluster 102 is received at the migration runtime 438A in the source TEE. In an embodiment, the request may be sent from the hypervisor 416A to the migration runtime 438A in the source TEE 402A in response to user request or in response to instructions from the cluster management server 106.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Sprague, Sarangdhar, Pogorelik and Li to include: receiving a connection request for the TEE from the user, and creating or starting the TEE. One would have been motivated to provide users with a means for creating a TEE service instance for providing services according to user requests. (See Li [0031].)
Regarding claim 6, Sprague, Sarangdhar, Pogorelik and Li disclose the method of claim 5.
Sprague further discloses wherein the connection request comprises at least one of private data uploading, private calculation algorithm uploading, private machine-learning model uploading, protected operation request of private calculation task, or private data downloading (Sprague [0051], [0078]. In another embodiment, at least a portion of the system software instructions 115 may be downloaded over a cable, communication and/or wireless connection via, for example, a browser SSL session1 or through an app (whether executed from a mobile or other computing device). In an example embodiment, Authentication Web Site 206 may be a JSON API written in Python, which uses the Third Party Agent/Process private key to enroll the identity keys of Devices 205 and Service Providers 204. During enrollment, the public key of the User Device 205 or Service Provider 204 is recorded by the TEE applet 208.).
Regarding claim 7, Sprague, Sarangdhar, Pogorelik and Li disclose the method of claim 5. Sprague further discloses further comprising: when it is confirmed that the operation environment of the computing node is not credible or the operation content of the computing node is not secure, returning a result of connection insecurity to the user (Sprague [0038], [0075]. Example embodiments may be founded on the principles of the Trusted Network Connect (TNC) standards under which the integrity of a device may be verified prior to actual enablement of the connection to a network switch. According to TNC, a device performs a series of measurements that are securely stored on the device. The measurements typically would include validation of the BIOS image, the operating system (OS) and any applications that need to be verified that they have not been altered. Upon connection to the network, the switch would perform a validation process verifying that the measurement data matches a reference value that was computed when the device was either previously connected or in a current known good condition or state. The Trusted Execution Environment (TEE) is also capable of self-measurement processes and remote attestation of the health of the device. The current measurement is compared against the gold measurement or Reference Value in the block chain. If the measurements match the transaction is signed. If the measurements do not match, the request is rejected. If the measurements do not match, the device may be put through a registration renewal where a new measurement is gathered.).
Regarding claim 13, claim 13 is directed to a computer device corresponding to the method of claim 5. Claim 13 is similar in scope to claim 5 and is therefore rejected under similar rationale.
Regarding claim 14, claim 14 is directed to a computer device corresponding to the method of claim 6. Claim 14 is similar in scope to claim 6 and is therefore rejected under similar rationale.
Regarding claim 15, claim 15 is directed to a computer device corresponding to the method of claim 7. Claim 15 is similar in scope to claim 7 and is therefore rejected under similar rationale.
Regarding claim 20, claim 20 is directed to a non-transitory computer-readable storage medium corresponding to the method of claim 5. Claim 20 is similar in scope to claim 5 and is therefore rejected under similar rationale.
Conclusion
Applicant’s amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a)..
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDWARD LONG whose telephone number is (571)272-8961. The examiner can normally be reached on Monday to Friday, 9 AM - 6 PM EST (Alternate Fridays).
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham can be reached on (571) 270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system.
Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only.
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/EDWARD LONG/
Examiner, Art Unit 2439
/LUU T PHAM/ Supervisory Patent Examiner, Art Unit 2439
1 An SSL session may incorporate encryption protocols (e.g., certificate, symmetric encryption, digital signature) to protect the privacy and authenticity of data communication.
Prosecution Insights