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 .
Status of Claims
• This action is in reply to the amendments filed on October 20, 2025.
• Claim 1 has been amended and are hereby entered.
• Claims 2-8 have been canceled.
• Claim 1 is currently pending and have been examined.
• This action is made FINAL.
Response to Arguments
Applicant’s arguments filed October 20, 2025 have been fully considered but they are not persuasive.
The Examiner is withdrawing the 35 USC § 101 rejections due to Applicant’s amendments. In particular, the claimed invention recites limitations including: receiving, by a computing device of the computing system comprising a blockchain node with a peer-to-peer networking interface, a consensus module implementing an append-only blockchain with a Merkle-tree state, and a cryptographic engine of a processing module, from a digital record of baseline content of an evaluation request from a user device of the computing system… identifying, by the computing device, an accreditation authority computing device of the computing system by consulting a registry that maps the obligation recipient ID to an accreditation authority identifier and corresponding public key material; obtaining, by the computing device, baseline validation information from the accreditation authority computing device, the baseline validation information comprising a digital signature over a canonicalized digest of the baseline content and a validation timestamp; validating, by the cryptographic engine, the baseline content by: (i) recomputing the canonicalized digest of the baseline content, (ii) verifying the digital signature using a public key bound to the accreditation authority, and (iii) confirming that the accreditation authority is not revoked according to a revocation status indicator, and indicating the baseline content is valid when the validation succeeds; establishing, by the computing device, non-fungible token (NFT) content including… an accreditation authority signature reference to produce an NFT; synchronizing, by the computing device, with the object distributed ledger to a finalized block height having at least a threshold number of confirmations; computing, by the cryptographic engine, a transaction digest over a canonical representation of the NFT content together with a nonce, chain identifier, and a previous block hash, encrypting at least a portion of the NFT content using a receiving public key associated with the object distributed and generating a transaction signature by signing the transaction digest with a private key of the computing device; causing, by the consensus module, generation of a next block of a blockchain of the object distribution ledger including the NFT content, the encrypted portion, a Merkle root committing the NFT content, and the transaction signature; and causing, by the computing device, inclusion of the next block as a new block in the object distributed ledger and recording a Merkle proof of inclusion for the NFT content, wherein inclusion of the chain identifier, the previous block hash, and the nonce in the transaction digest prevents replay across ledgers or epochs, the recorded Merkle proof provides tamper-evident provenance, and the threshold number of confirmations provides finalized custody within a bounded time window.
These are meaningful limitations that are more than applying the use of the abstract idea to a computer and more than generally linking the use of the judicial exception to a particular technological environment or field of use such as a computer network. These limitations, in combination, are indicative of a practical application. Furthermore, as an ordered combination, the claim limitations are also not well-understood, routine, or conventional.
For the reasons stated above, claim 1 has been deemed to be patent eligible under 35 U.S.C. §101.
New 35 USC § 112 rejections have been entered due to applicant’s amendments.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 1 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 recites the limitations of a consensus module implementing an “append-only blockchain with a Merkle-tree state.” The Specification is devoid of support for the feature of an append-only blockchain; nor does the Specification describe any type of Merkle-tree state. Therefore, this limitation is new matter.
Furthermore regarding claim 1, claim 1 recites the limitation identifying “by consulting a registry that maps the obligation recipient ID to an accreditation authority identifier and corresponding public key material.” There is no support in the Specification for the step of consulting a registry. Nor is there any support in the Specification for any type of mapping or mapped data structure, let alone a mapping of an obligation recipient ID to an accreditation authority identifier and corresponding public key material. Therefore, this limitation is new matter.
Furthermore regarding claim 1, claim 1 recites baseline validation information comprising “a digital signature over a canonical digest of the baseline content and a validation timestamp.” There is no support in the Specification for baseline validation information comprising this information. In fact, the Specification does not describe at all the features of a digital signature, a canonical digest, or a timestamp. Therefore this limitation is new matter.
Furthermore regarding claim 1, claim 1 recites validating the baseline content by: “(i) recomputing the canonicalized digest of the baseline content, (ii) verifying the digital signature using a public key bound to the accreditation authority, and (iii) confirming that the accreditation authority is not revoked according to a revocation status indicator.” Again, there is no support for “the canonicalized digest of the baseline content,” so therefore there is no support for recomputing “the canonicalized digest of the baseline content.” And again, there is no support for a “digital signature,” so therefore there is no support for verifying a digital signature. And, there is no support for determining whether an accreditation authority is revoked; nor is there is there any support in the Specification for a revocation status indicator. Therefore this limitation is new matter.
Furthermore regarding claim 1, claim 1 recites establishing “an accreditation authority signature reference” to produce the NFT. The Specification is devoid of any disclosure pertaining to an accreditation authority signature reference. Therefore this limitation is new matter.
Furthermore regarding claim 1, claim 1 recites the limitation synchronizing “to a finalized block height having at least a threshold number of confirmations.” There is no support in the Specification for the feature of a “finalized block height.” Nor is there support in the Specification for a threshold number of confirmations. Therefore this limitation is new matter.
Furthermore regarding claim 1, the claim recites computing “a transaction digest over a canonical representation of the NFT content.” There is no support in the Specification for the feature of a transaction digest over a canonical representation of the NFT content. Nor is there support in the Specification for the feature of any type of canonical representation, let alone a canonical representation of the NFT. Therefore this limitation is new matter.
Furthermore regarding claim 1, claim 1 recites generating a transaction signature by “signing the transaction digest with a private key.” There is no support in the Specification for signing the transaction digest with a private key; in fact there is no support in the Specification for any transaction digest. Therefore this limitation is new matter.
Furthermore regarding claim 1, claim 1 recites causing generation of a block including “a Merkle root committing the NFT content.” Again, there is no support in the Specification for any type of Merkle tree data structure, and therefore there is no support in the Specification for a Merkle root.
Furthermore regarding claim 1, claim 1 recites recording “a Merkle proof of inclusion for the NFT content.” There is no support in the Specification for the feature of a Merkle proof of inclusion. Therefore this limitation is new matter.
Furthermore regarding claim 1, claim 1 recites “wherein inclusion of… the nonce in the transaction digest prevents replay across ledgers or epochs, the recorded Merkle proof provides tamper-evident provenance, and the threshold number of confirmations provides finalized custody within a bounded time window.” As an initial matter, there is no support in the Specification for the feature of “the transaction digest.” Furthermore, there is no support in the Specification for the feature of “preventing replay across ledgers or epochs.” Furthermore, the Specification is devoid of any disclosure pertaining to a recorded Merkle proof, let alone any disclosure pertaining to providing tamper-evident provenance. And again, the Specification is devoid of any disclosure pertaining to a threshold number of confirmations, let alone any disclosure pertaining to providing a finalized custody with a bounded time window. Therefore this limitation is new matter.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20240037593 (“Navon”) discloses managing loyalty programs using a decentralized blockchain are provided. Transactions between users and a merchant are monitored via an application programming interface (API) of a service provider. Based on the monitoring, it may be determined that at least one of the users has satisfied reward criteria for a loyalty program associated with the merchant. The loyalty program includes a plurality of tokens to be distributed to users who satisfy the reward criteria configured by the merchant via a merchant interface. At least one token from among the plurality of tokens may be selected for the user, based on at least one smart contract associated with the merchant. The smart contract is stored on the blockchain in association with a unique identifier for the merchant. A transaction is broadcasted to the decentralized blockchain for transferring the at least one token to a digital wallet of the user.
US 20230298435 (“Dalmia”) discloses gaming solutions across different gaming channels, different entities, and different environments using blockchain and/or non-fungible token (NFT) components and/or functionality. In an embodiment, multi-level NFTs may be awarded as part of game play in one or more game channels, with each subsequently awarded NFT having a level and associated value higher than its predecessor. The multi-level NFT's may be controlled by a smart contract designed to allow the use of the multi-level NFT's in ways that minimize changes to existing gaming regulations.
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 RAVEN E YONO whose telephone number is (313)446-6606. The examiner can normally be reached Monday - Friday 8-5PM EST.
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, Bennett M Sigmond can be reached on (303) 297-4411. 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.
/RAVEN E YONO/Primary Examiner, Art Unit 3694