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 .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-2, 4, 7-9, 11-12, 14, 17-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Raghuram et al (WO 2022/272064), hereinafter Raghuram in view of Smith et al. (US 2020/0084202), hereinafter Smith.
Regarding claim 1:
Raghuram teaches a computing node configured to perform attestation and provenance verification, comprising:
processing circuitry; (para. [0050] IPUs) and
a memory device including instructions embodied thereon, wherein the instructions, which when executed by the processing circuitry, configure the processing circuitry to cause operations that:
receive evidence from a client relating to a computing task; (para. [0096], [0103]-[0105], a request is received (at an attestation service operated by a trust service provider) from the requesting party, to obtain attestation evidence. This requested attestation evidence includes trust claims (or, “attestation claims”) to serve as proof of trust of a compute configuration of the requesting party, to be evaluated by a relying party … the request for attestation evidence is provided from the requesting party to the trust service provider, in response to an (earlier) request for some proof of trust that was provided from the relying party to the requesting party)
analyze the evidence to determine [[a provenance]] verification result for trustworthiness of the computing task; (para. [0096], [0104-[0105], An application/service owner, before deploying an application in a CSP, creates (or establishes, activates, etc.) an attestation policy for the application. This may be accomplished with the TEE policy creation operations 1111 depicted in FIG. 11. The attestation policy defines the criteria used by the attestation service on how to validate/attest the application… the trust service provider obtains and evaluates an attestation policy associated with the requesting party (and optionally, the relying party). In an example, the attestation policy specifies one or more requirements for generating, evaluating, or providing the proof of attestation)
evaluate compliance of the computing task with a policy; (para. [0107] the trust service provider creates an attestation token based on the attestation policy. This attestation token provides a proof of trust for the trust claims, to establish the trustworthiness of some asset (e.g., a trusted computing component, configuration, or environment). For example, proof of trust for the trust claims may be generated on behalf of a compute configuration of the requesting party, which relates to relates to use of a trusted execution environment at the requesting party) and
return an attestation token that includes [[the provenance verification result]] for the computing task, in response to determining the computing task is compliant with the policy (para. [0108]-[0109], the attestation token is provided (e.g., communicated) to the requesting party, and at operation 1305, the requesting party provides (e.g., forwards) the attestation token to the relying party as a proof of trust. In an example, the relying party controls access to a resource based on verifying the trust claims from the token (serving as the proof of trust). In another example, the relying party controls access to a resource based on verifying the trust claims from the token (again, serving as the proof of trust)… additional operations may be optionally performed to repeat the attestation evaluation and token generation operations, on behalf of a relying party (with the roles of the relying and requesting parties being reversed). This can allow additional attestation evidence providing additional trust claims for the originally relying party to be evaluated by the originally requesting party).
While Raghuram discloses verification result for the trustworthiness, Raghuram does not explicitly disclose Smith discloses determine a provenance verification result for trustworthiness of the computing task; return an attestation token that includes the provenance verification result for the computing task (para. [0097] [0140], [0174], at operation 1204: The attestation service 1121 successfully performs attestation, and issues an attestation token 1141 that includes claims of the verified application…Hierarchical Token Management (HTM) … record keeping may help in efficient auditing to meet regulatory requirements and in tracking provenance, … device construction, composition and mutability properties are trust relevant properties called Attestation Assertions (AA) device provenance is a trust assertion that the SCE 1010 can facilitate)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify attestation verification disclosed by Raghuram by incorporating provenance verification result by Smith. One would have been motivated to do so in order to provide an assertion that includes chain-of-custody during manufacturing, supply chain and possibly even post deployment (para. [0210], Smith).
Regarding claim 2 and 12,
Raghuram in view of Smith further discloses the method of claim 1. Raghuram in view Smith further discloses wherein the evidence is accompanied by a provenance recipe (Smith, para. [0210] Note that instant application is described as “recipe” as instructions, specifications, formats used with provenance data, provenance-related definitions or instructions associated with provenance).
Regarding claim 4 and 14,
Raghuram in view of Smith further discloses the method of claim 1. Raghuram in view Smith further discloses wherein to analyze the evidence, includes to generate provenance data according to instructions and parameters contained in a provenance manifest (Smith para. [0174] attestation assertions, trust properties, and provenance as a trust assertion. structured assertions parameters to generate or validate provenance-related data).
Regarding claim 7 and 17,
Raghuram in view of Smith further discloses the method of claim 1. Raghuram in view Smith further discloses wherein the computing node is configured to receive the evidence via an application programming interface, and return the attestation token via the application programming interface (Raghuram, para. [0054], [0081], API layers, API client libraries).
Regarding claim 8 and 18,
Raghuram in view of Smith further discloses the method of claim 1. Raghuram in view Smith further discloses wherein the instructions further configure the processing circuitry to cause operations that: receive a request via the application programming interface for provenance collateral information; and return the provenance collateral information. (Raghuram, para. [0054], [0081], API layers 330, API client libraries 320 allow different parties to interface and consume the services (including with user interfaces 312, API clients 314, eco-system services 316, and the like).
Regarding claim 9 and 19,
Raghuram in view of Smith further discloses wherein the attestation token returned to the client includes a list of ingredients with hash codes, to enable the client to verify the computing task (Smith, para, [0163], [0207], chained hashes of images to an attestation authority or blockchain-based signature identity infrastructure … class identification may include assertions that in some way identify a class of device; for example, the triple Svendor, model, version) or a hash of firmware.
Claim 11 is recites substantially similar limitation as claim 1 above, therefore, is also rejected under the same rationale set forth for claim 1 above.
Claim(s) 3, 5-6, 13, 15-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Raghuram et al (WO 2022/272064), hereinafter Raghuram in view of Smith et al. (US 2020/0084202), hereinafter Smith further in view of Silveira et al (US 2022/0179959).
Regarding claim 3 and 13,
Raghuram in view of Smith further discloses the method of claim 1. Raghuram in view Smith further discloses wherein the evidence includes a digest code [[corresponding to a workload]], and wherein to analyze the evidence includes to [[verify an integrity of the workload based on the digest code]] and the provenance recipe (Smith, para. [0174], attestation evidence and trust assertions, [0174] supports provenance “The AtS 1030 receives Attestation Evidence (AE) … and may evaluate some or all of it). Raghuram in view Smith does not explicitly discloses, however, Silveira discloses a digest code corresponding to a workload and verifying an integrity of the workload based on the digest code (para. [0029], [0036], … the attestation, when challenged by a remote verifier … may submit the workload integrity log 137 along with an authenticated digest of hashes 153 as proof of the authenticity of the integrity measurements in the workload integrity log 137). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify attestation verification disclosed by Raghuram and Smith by incorporating digest code associated with the workload as taught by Silveir. One would have been motivated to do so in order to provide attestation to the computer platform to the verifier along with proof (para. [0014], Silveir)
Regarding claim 5 and 15,
Raghuram in view of Smith further discloses the method of claim 4. Raghuram in view Smith does not explicitly disclose, however, Silveira discloses wherein to analyze the evidence, includes verification of at least one container image and source code associated with the computing task (Silveria, para. [0028]-[0029], agent may read container image metadata to form corresponding measurements, read instantiated container file system metadata to form corresponding measurements, measure files when accessed during the run-time of the container… the agent may take the integrity measurements in response to certain container-related events… integrity measurements to create one or multiple worklog integrity logs… verifier may use an authenticated digest of the hashes to verify that the workload integrity). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify attestation verification disclosed by Raghuram and Smith by incorporating digest code associated with the workload as taught by Silveir. One would have been motivated to do so in order to provide attestation to the computer platform to the verifier along with proof (para. [0014], Silveir)
Regarding claim 6 and 16,
Raghuram in view of Smith in view of Silveir further discloses wherein the verification of at least one container image and source code associated with the computing task is performed based on the provenance manifest (Silveria, para. [0028]-[0029], agent may read container image metadata to form corresponding measurements, read instantiated container file system metadata to form corresponding measurements, measure files when accessed during the run-time of the container) The same motivation as claim 5 above applies.
Claim(s) 10 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Raghuram et al (WO 2022/272064), hereinafter Raghuram in view of Smith et al. (US 2020/0084202), hereinafter Smith further in view of Touitou et al (US 2022/0129544).
Regarding claims 10 and 20,
Raghuram in view of Smith further discloses the method of claim 1. Raghuram in view Smith further discloses wherein the attestation token is used by the client or at least one external entity to verify integrity of [[a binary or source code]] associated with the computing task. Raghuram in view Smith does not explicitly teach, however, Cohen discloses wherein the attestation token is used by the client or at least one external entity to verify integrity of a binary or source code associated with the computing task (para. [0077], the client 100 and the secure enclave 330, the cryptographic hash of the corresponding binary code may be used by the client to verify that the public key was generated by an SGX protected application whose identity is given by the hash. the cryptographic hash of the corresponding binary code may be used by the client to verify that the public key was generated by an SGX protected application whose identity is given by the hash). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify attestation verification disclosed by Raghuram and Smith by incorporating verifying integrity of binary code or source code as taught by Touitou. One would have been motivated to do so in order to provide software attestation in a trusted execution environment (Abstract, Touitou).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Cohen et al. (US 2020/0084045) directed to generating a hash of the digital asset. The method further includes updating a distributed ledger of a blockchain system with the hash of the digital asset to establish the provenance of the digital asset.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Shewaye Gelagay whose telephone number is (571)272-4219. The examiner can normally be reached Monday to Friday 8 A.M. - 4 P.M..
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, Amy C. Johnson can be reached at (571) 272-2238. 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.
/SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436
Prosecution Insights