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 .
This office action is in response to the amendment filed on 09/09/2026.
Claims 1, 3, 11 and 13 have been amended. Claims 2 and 12 are cancelled. Claims 1, 3-11 and 13-20 have been examined.
Response to Arguments
Applicant’s arguments see Remarks filed on 09/09/2026 with respect to 35 U.S.C. 103 rejection have been considered but are moot because the new ground of rejection set forth below.
Information Disclosure Statement
The information disclosure statement filed 06/09/2026 has been considered.
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, 4, 7-9, 11, 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 in view of Novotny et al. (US 20220391541), hereinafter Novotny.
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 evidence being accompanied by a provenance recipe; 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).
Raghuram in view of Smith does not explicitly teach a provenance recipe that defines a type of information to establish provenance of at least one source code or binary underlying the computing task; and analyze the evidence, based on the provenance recipe. However, Novotny discloses a provenance recipe that defines a type of information to establish provenance of at least one source code or binary underlying the computing task; (see para. [0038], [0046]-[0049], 0038] produce a provenance manifest 218 which contains information about the parts and the context that were used during the release build operation. For instance, the provenance manifest includes part information 304 such as source code file names 308 and content checksums 310, library file names 314 and content checksums 316, and the names 320 and content checksums 322 of resources 318 such as image files that were embedded into the release binary during the release build operation. Similarly, the provenance manifest 218 includes context information 212 such as compiler parameters 330, compiler version 328, names 334 and versions 336 of any other tools 332 used, the runtime name 348 and version 350, and the operating system name 356 and version 358); and analyze the evidence, based on the provenance recipe (see para. [0017]-[0019], [0050], [0082]-[0099], provenance manifests in a tree of provenance manifests. This allows provenance validation without rebuilding everything from scratch, to the extent that the referenced provenance manifests are trusted… provenance validation is an independent process for each binary).
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 provenance verification result by Novotny. One would have been motivated to do so in order to provide software security by validating a provenance of a binary's source code for vulnerabilities (para. [0210], Smith).
Regarding claim 4 and 14,
Raghuram in view of Smith in view of Novotny further discloses the method of claim 1. Raghuram in view Smith in view of Novotny 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 in view of Novotny further discloses the method of claim 1. Raghuram in view Smith in view of Novotny 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 in view of Novotny further discloses the method of claim 1. Raghuram in view Smith in view of Novotny 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 in view of Novotny further discloses the method of claim 1. Raghuram in view Smith in view of Novotny 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 and in view of Novotny et al. (US 20220391541), hereinafter Novotny further in view of Silveira et al (US 2022/0179959).
Regarding claims 3 and 13,
Raghuram in view of Smith in view of Novotny further discloses the method of claim 1. Raghuram in view Smith in view of Novotny 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 and Novotny 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 claims 5 and 15,
Raghuram in view of Smith in view of Novotny further discloses the method of claim 1. Raghuram in view Smith in view of Novotny 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 and Novotny 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 Novotny 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 and in view of Novotny et al. (US 20220391541), hereinafter Novotny further in view of Touitou et al (US 2022/0129544).
Regarding claims 10 and 20,
Raghuram in view of Smith in view of Novotny discloses the method of claim 1. Raghuram in view Smith in view of Novotny 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 in view of Novotny 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 and Novotny 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.
Kuhtz et al. (US 10210170) directed to hierarchical and incremental nature of the software build systems to reduce the number of storage operations needed. Specifically, by a deduplicating process which shadows the causal dependency graph of the build workflow, some embodiments reduce or even minimize the number of churned nodes in a hash tree representation of the build's transformations.
Shaikh et al. (US 20200097845) directed to source codes 234 represent a plurality of different sets of software code for training different types of machine learning models on how to classify different datasets and for determining how to utilize the different classified datasets (e.g., what type of task is a particular dataset capable of performing).
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 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
