DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
This action is responsive to an amendment filed on 06/09/2025. Claims 1-15 have been amended. Claims 1-15 are pending for examination.
Response to Arguments
Applicant’s arguments, see Applicant Arguments/Remarks, filed on 06/09/2025, with respect to the rejection under 35 U.S.C. §101 have been fully considered and are persuasive. Therefore, the 35 U.S.C. §101 rejection has been withdrawn.
Applicant's arguments with respect to the rejection of the pending claims under 35 U.S.C. §102 have been fully considered. However, in the current rejection, Examiner relies on Rognlie to teach the amended limitations, therefore, applicant’s arguments are moot because the arguments do not apply to the reference being used in the current rejection. See the newly crafted rejection, infra.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-7, 10, 13 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over US 11424939 (Allen et al.) in view of US 2022/0050907 (Rognlie et al.).
Regarding Claim 1, Allen teaches a non-transitory computer- readable storage medium comprising instructions which, when executed by a processor [C.21:L.18-32], cause the processor to: retrieve an attestation public key from storage of a secure component of a platform ([C.9:L. 38-42] trusted platform module (TPM) obtains the attestation identity key from a key storage. The attestation identity key can be a certified private key. The certified private key can be used to sign data and other information. The key storage can be integrated with the TPM), wherein the attestation public key is bound to an identity associated with a root of trust of the platform [C.2:L.55 – C.3:L.17] a trusted platform module (TPM) is able to validate the hardware of the host as well as the software installed on the host. The TPM examines the host and/or configuration data provided by the host and generates attestation data. The attestation data may include one or more attestation parameters including identity information associated with a key belonging to the TPM. The attestation identity key is a signing key (comprising a private/public key pair) that is used to provide host authentication based on the attestation capability of the TPM. Thus, the attestation identity key allows the TPM to produce cryptographically signed attestation evidence (e.g., attestation data) about the configuration and operational state of the host. [C.3:L.33-37], the attestation identity key certificate identifies the TPM, the host associated with the TPM, includes a public portion of the attestation identity key (e.g., a public attestation identity key), such as a certified public key, owned by the TPM. [C.4:L.17-22], proof confirms that the TPM provided a valid attestation identity key certificate comprising a valid certificate chain establishing a chain of trust, and a valid public portion of the attestation identity key used to produce the signed attestation data);
obtain a trusted time stamp associated with …data collection by the…platform ([C.2:L.46-54] forward a message, to the host, that contains some or all of the information contained in the attestation request and instructions that may aid in generating attestation data. For example, the message may include a request to obtain configuration information of the host, where the configuration information can be used to obtain or generate attestation data that includes attestation parameters that may include timestamp data, at least some of the configuration information. [C.2:L.63 – C.3:L.4], The TPM examines the host and/or configuration data provided by the host and generates attestation data…the attestation data may include at least a portion of the configuration data obtained from the host. For example, the attestation data may include one or more attestation parameters including a timestamp. [C.8:L.52-59] forward a message, to the TPM, that contains some or all of the information contained in the attestation request and instructions that may aid in generating attestation data. For example, the message may include a request to obtain configuration information of the host, where the configuration information can be used to obtain or generate attestation data that includes attestation parameters that may include timestamp data); and
generate, using an attestation private key linked to the attestation public key, a signed measurement based on a trusted input as a nonce, wherein the signed measurement confirms authenticity of the…data collection based on the root of trust. ([C.3:L.7-14] The TPM signs the attestation document using a secret portion of an attestation identity key, such as certified private key, owned by the TPM. … the attestation identity key is a signing key (comprising a private/public key pair) that is used to provide host authentication based on the attestation capability of the TPM. [C.4:L.4-6], The signed attestation data can be communicated to the prover service with the client nonce and the attestation identity key certificate. [C.9:L.38-41] the TPM obtains the attestation identity key from a key storage. The attestation identity key can be a certified private key. The certified private key can be used to sign data and other information. [C.9:L.52-55] the TPM also obtains an attestation identity key certificate. The certificate provides proof that the attestation identity key is a signing key belonging to the TPM and usable to verify the integrity of the host. [C.11:L.8-14], The prover service can generate a host nonce using a random nonce generator. The random nonce generator can communicate the host nonce to the prover service . The prover service combines the client nonce and the host nonce to generate the proof challenge. [C.11:L.26-27] the prover service can communicate the proof and the proof challenge to the TPM . [C.11:L.49-53], The proof and the associated proof data can be used by the TPM and/or attestation endpoint to confirm to the customer that the attestation identity key used to sign attestation data satisfies a certain set of relationships confirmed by the circuit [C.15:L.6-10], The attestation identity key allows the TPM to produce signed attestation data about the configuration and operational state of the host. …the attestation identity key is simply a certified private key that can be used to sign data and information. [C.22:L.26-38] The zero-knowledge proof can verify the validity of the attestation data, that the signed attestation data was signed with the certified private key, and/or that the certificate comprising the certified public key includes a valid chain of trust. …verify the zero-knowledge proof to establish an authenticity of the attestation data).
While, Allen teaches obtain configuration information, where the configuration information can be used to generate attestation data that includes timestamp data and establish an authenticity of the attestation data, however, Allen does not explicitly teach, but Rognlie teaches obtain a trusted time stamp associated with batched data collection by a staging server of the platform, wherein the batched data collection is to save diagnostic data from multiple computing devices in a batch for bulk upload to the staging server; …wherein the measurement confirms authenticity of the batched data ([¶¶ 0070-0071], server receives one or more data points or values. The data points may correspond to data collected from testing or sampling a batch of a particular product …the sampling or testing of a batch is parameter-specific, i.e., sampling is based on one or more parameter values for a batch …The collected data includes the parameter value or values and may include metadata associated with the circumstances of the sampling. For example, the batch data may also include a batch ID number or name, time stamp information (e.g., time and/or date corresponding to the time and/or date that the batch was sampled or created)… The batch data may be automatically uploaded to the system as it is collected. For example, the values may be detected via one or more of the instruments in the system. The data values may be received directly from the instrument or from a computing device or storage in communication with the instrument or that has received information from the instrument (e.g., via bulk data upload). The time stamp information may also be recorded directly by the instrument when the values are recorded and may be uploaded to the server directly. …the time stamp information may be automatically entered into the system when the batch data is uploaded (e.g., indicating the time the batch was entered into the system. [¶ 0082], after stores the collected data the system receives an analytics request, which may be a request for validation of collected data. For example, a user may want to know whether a particular batch is in compliance with regulations and/or goals at the time of sampling).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Rognlie’s teachings of collection of batched data including time stamps from plurality of instruments and validate the collected data to the teachings of Allen, because such incorporation would have ensured significant time savings and increased efficiency by bulk data upload
Regarding Claim 2, Allen teaches the non-transitory computer- readable storage medium of claim 1, wherein the instructions further cause the processor to generate the trusted time stamp using the attestation private key and an input time associated with the batched data collection ([C.8:L.64-67] TPM may be a secure enclave or computing region including secure storage and processors protected from external modification or tampering without proper credentials. [Fig. 1, C.9:L.4-6], The TPM 112 examines the system configuration of the host 108 and generates attestation data based on configuration data obtained from the host. [C.9:L.29-32] the attestation data may include one or more attestation parameters including a timestamp when the attestation data was generated or obtained. [C.3:L.2-10], the attestation data may include one or more attestation parameters including a timestamp, information associated with the attestation request, the client nonce, configuration data of the host, and/or identity information associated with a key belonging to the TPM. The TPM signs the attestation document using a secret portion of an attestation identity key, such as certified private key, owned by the TPM).
Regarding Claim 3, Allen teaches the non-transitory computer- readable storage medium of claim 1, wherein the instructions further cause the processor to receive the trusted time stamp from a trusted entity connected to the platform in response to the platform performing batched data collection ([Fig. 1, C.8:L.35-59], client computing device 102 communicates the attestation request and the client nonce to an attestation endpoint 106. …The attestation endpoint 106 determines, based on the evaluation, that the customer is requesting attestation data related to the host 108. …the attestation endpoint 106 forward the obtained client nonce to a trusted platform module (TPM) 112 that is linked to the host 108. The attestation endpoint 106 may also forward a message, to the TPM 112, that contains some or all of the information contained in the attestation request and instructions that may aid in generating attestation data. For example, the message may include a request to obtain configuration information of the host 108, where the configuration information can be used to obtain or generate attestation data that includes attestation parameters that may include timestamp data, …The TPM 112 examines the system configuration of the host 108 and generates attestation data based on configuration data obtained from the host 108).
Regarding Claim 4, Allen teaches the non-transitory computer- readable storage medium of claim 1, comprising instructions to cause the processor to receive, from a trusted entity, the trusted input, where the trusted input comprises an input time associated with the batched data collection ([C.21:L.56 – C.22:L.10], a host computing system of the service provider, such as the TPM 112, generates the attestation data based on configuration data obtained from a host computing device of the service provider. For example, the host can provide the configuration data to the TPM. The TPM 112 can generate the attestation data based on the configuration data provided by the host computing device. The attestation data may include additional data, such as one or more attestation parameters generated by the TPM 112 or derived from the configuration data. For example, one or more of the attestation parameters may include data describing the hardware, software, application(s), platform(s), and so forth, implemented by the host computing device. The attestation parameters of the attestation data may also include other parameters, such as a timestamp indicating when the attestation data was generated, and/or identifying information pertaining to the TPM, the host computing device, the service provider, one or more keys of the TPM, and so forth.).
Regarding Claim 5, Allen teaches the non-transitory computer- readable storage medium of claim 1, comprising instructions to cause the processor to aggregate information indicative of the diagnostic data collected by the platform at a trusted component of the platform ([C.9:L.52-58], The TPM obtains an attestation identity key certificate. The certificate provides proof that the attestation identity key is a signing key belonging to the TPM and usable to verify the integrity of the host. The attestation identity key certificate is issued by a trusted certification authority (CA) and includes a certificate chain to establish a chain of trust. [C.10:L.3-10], The TPM signs the attestation data using the attestation identity key. The TPM can also couple the attestation identity key certificate to the signed attestation data. The signature on the attestation data and/or the certificate to the attestation data can include information related to the TPM, service provider and the host. …the TPM communicates the signed attestation data and the certificate to a prover service. …The prover service can generate a proof that comprises proof data. The proof, and associated proof data, confirms that the attestation data received from the TPM was signed with a valid attestation identity key held by the TPM. Furthermore, the proof confirms that the TPM 112 provided a valid attestation identity key certificate comprising a valid certificate chain establishing a chain of trust).
Regarding Claim 6, Allen teaches the non-transitory computer- readable storage medium of claim 1, comprising instructions to cause the processor to send the attestation public key, the trusted time stamp and the signed measurement to a storage ([C.2:L.55 – C.3:L.41], The TPM, specifically, is able to validate the hardware of the host as well as the software installed on the host. The TPM examines the host and/or configuration data provided by the host and generates attestation data, which can be associated with an attestation document, summarizing the hardware and software configuration of the host. As descried, in some implementations, the attestation data may include at least a portion of the configuration data obtained from the host. For example, the attestation data may include one or more attestation parameters including a timestamp, information associated with the attestation request, the client nonce, configuration data of the host, and/or identity information associated with a key belonging to the TPM. The TPM signs the attestation document using a secret portion of an attestation identity key, such as certified private key, owned by the TPM. In some implementations, the attestation identity key is a signing key (comprising a private/public key pair) that is used to provide host authentication based on the attestation capability of the TPM. Thus, the attestation identity key allows the TPM to produce cryptographically signed attestation evidence (e.g., attestation data) about the configuration and operational state of the host. … the TPM also includes an attestation identity key certificate. Alternatively, another computing device, such as the attestation endpoint, may hold the attestation identity key certificate on behalf of the TPM. The certificate provides proof that the attestation identity key is a signing key restricted to the TPM and usable to verify the integrity of the host. In some implementations, the attestation identity key certificate is issued by a trusted certification authority (CA) and includes a certificate chain to establish a chain of trust. In general, CAs may represent entities, processes, and tools that create digital certificates that securely bind the names of entities to public keys. A CA's signature on a certificate allows any tampering with the contents of the certificate to be easily detected. As long as the CA's signature on a certificate can be verified, the certificate has integrity. In some implementations, the attestation identity key certificate identifies the TPM, the host associated with the TPM, includes a public portion of the attestation identity key (e.g., a public attestation identity key), such as a certified public key, owned by the TPM,. [C.8:L.64-67] the TPM may be a secure enclave or computing region including secure storage and processors protected from external modification or tampering without proper credentials).
Regarding Claim 7, Allen teaches the non-transitory computer-readable storage medium of claim 6, further comprising instructions to cause the processor to send, to the storage: a certificate indicative of the identity associated with the root of trust of the platform ([C.3:L.18-24], the TPM also includes an attestation identity key certificate. The certificate provides proof that the attestation identity key is a signing key restricted to the TPM and usable to verify the integrity of the host); a log indicative of information obtained by the platform when collecting the diagnostic data; a measurement indicative of the identity of the platform; and/or a platform identity indicator of the platform ([C.2:L.63 – C.3:L.23], The TPM examines the host and/or configuration data provided by the host and generates attestation data… the attestation data may include one or more attestation parameters including… identity information associated with a key belonging to the TPM. …the TPM also includes the attestation identity key certificate. The certificate provides proof that the attestation identity key is a signing key restricted to the TPM and usable to verify the integrity of the host).
Regarding Claim 10, Allen teaches a method, comprising: receiving an attestation public key from storage of a secure component of a platform, wherein the attestation public key is bound to an identity associated with a root of trust of a platform ([C.2:L.64 – C.3:L.17], trusted platform module (TPM) generates attestation data. The attestation data may include one or more attestation parameters including …identity information associated with a key belonging to the TPM. [C.9:L. 38-42] trusted platform module (TPM) obtains the attestation identity key from a key storage. The attestation identity key can be a certified private key. The certified private key can be used to sign data and other information. The key storage can be integrated with the TPM); receiving a signed time stamp indicative of a time of…data collection by … the platform ([C.2:L.64 – C.3:L.17], trusted platform module (TPM) generates attestation data. The attestation data may include one or more attestation parameters including a timestamp. [C.9:L.29-32], the attestation data may include one or more attestation parameters including a timestamp when the attestation data was generated or obtained); and receiving a signed measurement generated by the platform based on a trusted input, wherein the signed measurement confirms authenticity of the batched data collection based on the root of trust ([C.2:L.64 – C.3:L.17], trusted platform module (TPM) generates attestation data, which can be associated with an attestation document, summarizing the hardware and software configuration of the host. …the attestation data may include at least a portion of the configuration data obtained from the host. …The TPM signs the attestation document using a secret portion of an attestation identity key, such as certified private key, owned by the TPM. …the attestation identity key is a signing key (comprising a private/public key pair) that is used to provide host authentication based on the attestation capability of the TPM. Thus, the attestation identity key allows the TPM to produce cryptographically signed attestation evidence (e.g., attestation data) about the configuration and operational state of the host);
performing, using processing circuitry, a check wherein failing the check indicates that the platform is in an unexpected state ([C.6:L63 - C.7:L.10] Validation of the proof fails and the attestation data and/or proof are disregarded when the challenges do not match. When the challenges match, the proof validator service validates the proof and associated proof data using the circuit. Specifically, the circuit can output one or more true/false statements or values (e.g., 1 or 0). A true statement or value indicates that the TPM provided valid attestation data, the attestation data that was signed with a valid attestation identity key, and/or included a valid attestation identity key certificate. A false statement or value indicates that the prover service was not able to verify valid attestation data, the signature on the attestation data, and/or the attestation identity key certificate), and wherein passing the check indicates at least that: the identity of the platform corresponds to an expected identity by using a previously-received identity for the platform; the signed time stamp corresponds to an expected time stamp by using the attestation public key; and/or the signed measurement corresponds to an expected measurement by using the attestation public key ([C.5:L.21-50] The prover service can communicate a circuit that was used by the prover service to generate the proof and associated proof data. The proof and the associated proof data can be used by the TPM and/or attestation endpoint to confirm to the customer that the attestation identity key used to sign attestation data satisfies a certain set of relationships confirmed by the circuit, without revealing to the customer private or secret information associated with the signature. Furthermore, the proof and the associated proof data can be used by the TPM and/or attestation endpoint to confirm to the customer that a valid attestation identity key certificate comprising a valid certificate chain establishing a chain of trust, and a valid public portion of the attestation identity key, satisfy a certain set of relationships confirmed by the circuit. In addition, the proof and the associated proof data can be used by the TPM and/or attestation endpoint to confirm to the customer that the attestation data included valid configuration data of the host and/or valid attestation parameters generated by the TPM. The data provided by the circuit can be one or more output values indicating whether or not the TPM provided attestation data that was signed with a valid attestation identity key and included a valid attestation identity key certificate. The one or more output values can also indicate whether or not the attestation data included valid configuration data of the host and/or valid attestation parameters generated by the TPM); and in response to failing the check, providing an indication that the platform is in the unexpected state ([C.5:L.51-62] the circuit can output one or more true/false statements or values (e.g., 1 or 0). A true statement or value indicates that the TPM provided attestation data that was signed with a valid attestation identity key and included a valid attestation identity key certificate. A false statement or value indicates that the prover service was not able to verify the signature on the attestation data and/or the attestation identity key certificate).
While, Allen teaches obtain configuration information, where the configuration information can be used to generate attestation data that includes timestamp data and establish an authenticity of the attestation data, however, Allen does not explicitly teach, but Rognlie teaches receiving a signed time stamp indicative of a time of batched data collection by a staging server of the platform, wherein the batched data collection is to save diagnostic data from multiple computing devices in a batch for bulk upload to the staging server; wherein the signed measurement confirms authenticity of the batched data collection (emphasis added) ([¶¶ 0070-0071], server receives one or more data points or values. The data points may correspond to data collected from testing or sampling a batch of a particular product …the sampling or testing of a batch is parameter-specific, i.e., sampling is based on one or more parameter values for a batch …The collected data includes the parameter value or values and may include metadata associated with the circumstances of the sampling. For example, the batch data may also include a batch ID number or name, time stamp information (e.g., time and/or date corresponding to the time and/or date that the batch was sampled or created)… The batch data may be automatically uploaded to the system as it is collected. For example, the values may be detected via one or more of the instruments in the system. The data values may be received directly from the instrument or from a computing device or storage in communication with the instrument or that has received information from the instrument (e.g., via bulk data upload). The time stamp information may also be recorded directly by the instrument when the values are recorded and may be uploaded to the server directly. …the time stamp information may be automatically entered into the system when the batch data is uploaded (e.g., indicating the time the batch was entered into the system. [¶ 0082], after stores the collected data the system receives an analytics request, which may be a request for validation of collected data. For example, a user may want to know whether a particular batch is in compliance with regulations and/or goals at the time of sampling).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Rognlie’s teachings of collection of batched data including time stamps from plurality of instruments to the teachings of Allen, because such incorporation would have ensured significant time savings and increased efficiency by bulk data upload.
Regarding Claim 13, Allen teaches a computing device comprising a processor to: determine a trusted time associated with …data collection by a staging server of a platform ([C.2:L.63 – C.3:L.4], The TPM examines the host and/or configuration data provided by the host and generates attestation data…the attestation data may include at least a portion of the configuration data obtained from the host. For example, the attestation data may include one or more attestation parameters including a timestamp. Note: applicant’s specification discloses trusted time is the time provided by a trusted entity (See, specification para. 0088). Since, the timestamp is generated by a trusted platform module (TPM), therefore, the timestamp of Allen can be considered as a trusted time); generate an attestation key pair bound to an identity associated with a root of trust; obtain a signed time stamp based on the trusted time and a private key of the attestation key pair ([C.2:L.55 – C.3:L.17] The attestation data may include one or more attestation parameters including identity information associated with a key belonging to the TPM. The attestation identity key is a signing key (comprising a private/public key pair) that is used to provide host authentication based on the attestation capability of the TPM. The TPM examines the host and/or configuration data provided by the host and generates attestation data…the attestation data may include at least a portion of the configuration data obtained from the host. For example, the attestation data may include one or more attestation parameters including a timestamp.); generate a signed measurement based on a trusted input and the private key, wherein the signed measurement confirms authenticity of the…data collection based on the root of trust ([C.3:L.7-14] The TPM signs the attestation document using a secret portion of an attestation identity key, such as certified private key, owned by the TPM. … an attestation identity key is a signing key (comprising a private/public key pair) that is used to provide host authentication based on the attestation capability of the TPM. [C.9:L.38-41] the TPM obtains the attestation identity key from a key storage. The attestation identity key can be a certified private key. The certified private key can be used to sign data and other information. [C.9:L.52-55] the TPM also obtains an attestation identity key certificate. The certificate provides proof that the attestation identity key is a signing key belonging to the TPM and usable to verify the integrity of the host. [C.11:L.8-14], The prover service can generate a host nonce using a random nonce generator. The random nonce generator can communicate the host nonce to the prover service . The prover service combines the client nonce and the host nonce to generate the proof challenge. [C.11:L.26-27] the prover service can communicate the proof and the proof challenge to the TPM. [C.11:L.49-53], The proof and the associated proof data can be used by the TPM and/or attestation endpoint to confirm to the customer that the attestation identity key used to sign attestation data satisfies a certain set of relationships confirmed by the circuit [C.15:L.6-10], The attestation identity key allows the TPM to produce signed attestation data about the configuration and operational state of the host. …the attestation identity key is simply a certified private key that can be used to sign data and information); and send an attestation public key of the attestation key pair, the signed time stamp and the signed measurement to a verifying entity ([C.4:L.4-6], The signed attestation data can be communicated to the prover service with the client nonce and the attestation identity key certificate. [C.11:L.26-27] the prover service can communicate the proof and the proof challenge to the TPM . [C.11:L.49-53], The proof and the associated proof data can be used by the TPM and/or attestation endpoint to confirm to the customer that the attestation identity key used to sign attestation data satisfies a certain set of relationships confirmed by the circuit).
While, Allen teaches obtain configuration information, where the configuration information can be used to generate attestation data that includes timestamp data and establish an authenticity of the attestation data, however, Allen does not explicitly teach, but Rognlie teaches determine a trusted time associated with batched data collection by a staging server of a platform, wherein the batched data collection is to save diagnostic data from multiple computing devices in a batch for bulk upload to the staging server; …wherein the measurement confirms authenticity of the batched data collection ([¶¶ 0070-0071], server receives one or more data points or values. The data points may correspond to data collected from testing or sampling a batch of a particular product …the sampling or testing of a batch is parameter-specific, i.e., sampling is based on one or more parameter values for a batch …The collected data includes the parameter value or values and may include metadata associated with the circumstances of the sampling. For example, the batch data may also include a batch ID number or name, time stamp information (e.g., time and/or date corresponding to the time and/or date that the batch was sampled or created)… The batch data may be automatically uploaded to the system as it is collected. For example, the values may be detected via one or more of the instruments in the system. The data values may be received directly from the instrument or from a computing device or storage in communication with the instrument or that has received information from the instrument (e.g., via bulk data upload). The time stamp information may also be recorded directly by the instrument when the values are recorded and may be uploaded to the server directly. …the time stamp information may be automatically entered into the system when the batch data is uploaded (e.g., indicating the time the batch was entered into the system. [¶ 0082], after stores the collected data the system receives an analytics request, which may be a request for validation of collected data. For example, a user may want to know whether a particular batch is in compliance with regulations and/or goals at the time of sampling).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Rognlie’s teachings of collection of batched data including time stamps from plurality of instruments and validate the collected data to the teachings of Allen, because such incorporation would have ensured significant time savings and increased efficiency by bulk data upload
Regarding Claim 14, Allen teaches the computing device of claim 13, wherein the processor further to: obtain identifying information responsive to a change of state of the computing device ([C.2:L.55 – C.3:L.25], a trusted platform module (TPM) examines the host and/or configuration data provided by the host and generates attestation data. The attestation data may include one or more attestation parameters including identity information associated with a key belonging to the TPM. …TPM also includes an attestation identity key certificate. The certificate provides proof that the attestation identity key is a signing key restricted to the TPM and usable to verify the integrity of the host), and send the identifying information to the verifying entity ([C.4:L.3-17], The TPM can communicate the signed attestation data to the prover service. The signed attestation data can be communicated to the prover service with the client nonce and the attestation identity key certificate. The prover service can generate a proof. The proof, and associated proof data, confirms that the attestation data comprises host configuration data validated by the TPM and/or valid attestation parameter(s) provided or generated by the TPM. The proof can also confirm that the attestation data was signed with a valid attestation identity key held by the TPM).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Allen in view of Rognlie, and further in view of WO 2017027026 (Feather et al.).
Regarding Claim 8, Allen teaches the non-transitory computer-readable storage medium of claim 6, further comprising instructions to cause the processor to: send a request to a certification authority and receive a certificate from the certification authority proving that the attestation public key is associated with the platform ([C.3:L.18-29], the TPM also includes an attestation identity key certificate. The attestation identity key certificate is issued by a trusted certification authority (CA) and includes a certificate chain to establish a chain of trust. In general, CAs may represent entities, processes, and tools that create digital certificates that securely bind the names of entities to public keys);
Allen in view of Rognlie do not explicitly teach, however, Feather teaches cause the certificate to be sent, by the certification authority, to the storage ([¶ 0021] certificate authority (CA) certificate may be obtained by the user of the host from a certificate authority, and passed on to the storage system. …the certificate authority may transmit the CA certificate directly to the storage system on behalf of the host, or the storage system may retrieve the CA certificate from the certificate authority based on instructions from the host. The CA certificate may include a public key, and the certificate authority may securely retain a private key that corresponds to the CA certificate).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Feather with the combined teachings of Allen and Rognlie in order to store the certificate in a storage system because such incorporation would have allowed the system to retrieve the certificate when needed.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Allen in view of Rognlie, and further in view of WO 2012149717 (Shi et al.) and US 2004/0151308 (Kacker et al.).
Regarding Claim 9, Allen teaches the non-transitory computer-readable storage medium of claim 1, further comprising instructions to: send, to a certification authority, the attestation public key and a public key of a secure component of the platform ([C.9:L.52-57] the TPM also obtains an attestation identity key certificate. The certificate provides proof that the attestation identity key is a signing key belonging to the TPM and usable to verify the integrity of the host. The attestation identity key certificate is issued by a trusted certification authority (CA) …The attestation identity key certificate identifies the TPM and the host associated with the TPM, includes a public portion of the attestation identity key (e.g., a public attestation identity key), such as a certified public key, owned by the TPM);
Allen in view of Rognlie do not explicitly teach, however, Shi teaches receive, from the certification authority, an encrypted nonce that is encrypted…; decrypt the encrypted nonce using the attestation private key; and send the decrypted nonce to a verifying entity ([Page 5, Para. 2-5], Generate a key pair according to the local identification information, where the key pair includes: a private key KS2 and a public key KP2 ; the local identification information includes: information that can identify the local device; Generate a first data packet according to the public key KP2 and the function to be changed, and encrypt the first data packet with the public key KP2 to obtain the encrypted first data packet. Send the encrypted first data packet and the local unique identifier to the server, so that the server can obtain the private key KS1 according to the local unique identifier; and decrypt the first data packet according to the private key KS1).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Shi with the combined teachings of Allen and Rognlie in order to encrypt data using a public key, send the encrypted data to an entity and decrypt the data using private key of the entity, because such incorporation would have ensured the security of data transfer.
Allen in view of Rognlie and Shi do not explicitly teach, however, Kacker teaches encrypted according to a policy that specifies presence of the attestation private key on the secure component to enable decryption of the encrypted nonce by the platform ([¶¶ 0014-0016], A policy enforcement service may use various types of policy information in determining whether or not to grant access to a given user. … A user desiring to obtain a private key to decrypt particular encrypted data may provide suitable authentication information. The policy enforcement service may use this information on the characteristics of the user in enforcing the policy rules set forth by the policy information to determine whether the user is authorized to access the content of the encrypted data. If the user is authorized, the user may be provided with the necessary private key. … Once the user has obtained the private key, the user may use an identity-based decryption engine to decrypt the encrypted data and thereby access and use the data in its unencrypted form).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Kacker with the combined teachings of Allen, Rognlie and Shi in order to enforce policy to determine whether the user have the private key to decrypt the encrypted data, because such incorporation would have ensured the data is distributed in a secure fashion (see, Kacker, para. 0017).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Allen in view of Rognlie and further in view of JP 2005269466 (Nihei et al.).
Regarding Claim 11, Allen in view of Rognlie do not explicitly teach, however, Nihei teaches the method of claim 10, where performing the check further comprises re-computing diagnostic data collected by the platform using a log of measurements used to produce aggregate information indicative of the diagnostic data collected by the platform ([Page 2, Para. 7] reproduce the movement data related to the movement of the past mobile terminal from the communication log output by the data communication apparatus).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Nihei with the teachings of Allen in order to reproduce data from a log because such incorporation would have allowed the system to retrieve and generate lost data form log.
Claims 12 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Allen in view of Rognlie and further in view of Kacker.
Regarding Claim 12, Allen in view of Rognlie do not explicitly teach, however, Kacker teaches the method of claim 10, comprising performing an additional check, where the additional check comprises causing data encrypted under the attestation public key of the platform to be sent to the platform along with a policy that specifies that a private key linked to the attestation public key is present on the platform in order to decrypt the data, the method further comprising determining whether or not the private key is present on the platform depending on whether the data is returned by the platform ([¶ 0037], The data packaging service may encrypt the data before providing the data to users. [¶¶ 0042-0045], the encryption scheme generally will use at least two inputs in addition to the data being encrypted. … The first input is public parameter information… The second input used by the data encryption engine is the public key that contains policy information… The first and second inputs to the encryption engine are used by the data packaging service to encrypt the data [¶¶ 0047-0048], If the access request for access to a particular encrypted data item is granted, the policy enforcement service may provide the user with an appropriate private key to decrypt that encrypted data item. the user may use policy information that has been received from the data packaging service as the basis for the access request. …which includes sufficient information to inform the policy enforcement service which public key (and corresponding policy) and which private key correspond to the access request. [¶ 0050] If the policy enforcement service determines that the user satisfies the policy constraints imposed by the policy and that the user is therefore authorized to access the contents of the encrypted data, the policy enforcement service may provide the user with the private key that corresponds to the public key (Q) that was used to encrypt the data. The user may use the private key and decrypt the encrypted data and thereby access the desired content).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Kacker with the combined teachings of Allen and Rognlie in order to enforce policy to provide access to encrypted content only to the entity which have the private key corresponds to the public key and use the private key to decrypt the encrypted data, because such incorporation would have ensured the data is distributed in a secure fashion (see, Kacker, para. 0017).
Regarding Claim 15, Allen in view of Rognlie do not explicitly teach, however, Kacker teaches the computing device of claim 13, wherein the processor further to: receive, from the verifying entity, a request comprising data encrypted under the attestation public key and a policy specifying that the data is to be decrypted if the private key is held; decrypt the data using the private key, and send the decrypted data to the verifying entity ([¶ 0037], The data packaging service may encrypt the data before providing the data to users. [¶¶ 0042-0045], the encryption scheme generally will use at least two inputs in addition to the data being encrypted. … The first input is public parameter information… The second input used by the data encryption engine is the public key that contains policy information… The first and second inputs to the encryption engine are used by the data packaging service to encrypt the data [¶¶ 0047-0048], If the access request for access to a particular encrypted data item is granted, the policy enforcement service may provide the user with an appropriate private key to decrypt that encrypted data item. the user may use policy information that has been received from the data packaging service as the basis for the access request. …which includes sufficient information to inform the policy enforcement service which public key (and corresponding policy) and which private key correspond to the access request. [¶ 0050] If the policy enforcement service determines that the user satisfies the policy constraints imposed by the policy and that the user is therefore authorized to access the contents of the encrypted data, the policy enforcement service may provide the user with the private key that corresponds to the public key (Q) that was used to encrypt the data. The user may use the private key and decrypt the encrypted data and thereby access the desired content).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Kacker with the combined teachings of Allen and Rognlie in order to enforce policy to provide access to encrypted content only to the entity which have the private key corresponds to the public key and use the private key to decrypt the encrypted data, because such incorporation would have ensured the data is distributed in a secure fashion (see, Kacker, para. 0017).
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMAD YOUSUF A MIAN whose telephone number is (571)272-9206. The examiner can normally be reached Monday-Friday 9am-5:30pm.
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, ARIO ETIENNE can be reached at 571-272-4001. The fax phone number for the organization