Prosecution Insights
Last updated: July 17, 2026
Application No. 19/203,148

NON-FUNGIBLE TOKEN OWNERSHIP REGISTRATION AND VERIFICATION SYSTEM

Non-Final OA §101§102§103§112
Filed
May 08, 2025
Priority
Mar 11, 2022 — provisional 63/318,818 +3 more
Examiner
SHAIFER HARRIMAN, DANT B
Art Unit
Tech Center
Assignee
Counterten Inc.
OA Round
1 (Non-Final)
81%
Grant Probability
Favorable
1-2
OA Rounds
1y 9m
Est. Remaining
98%
With Interview

Examiner Intelligence

Grants 81% — above average
81%
Career Allowance Rate
635 granted / 785 resolved
+20.9% vs TC avg
Strong +17% interview lift
Without
With
+17.4%
Interview Lift
resolved cases with interview
Typical timeline
2y 11m
Avg Prosecution
11 currently pending
Career history
806
Total Applications
across all art units

Statute-Specific Performance

§101
6.2%
-33.8% vs TC avg
§103
79.7%
+39.7% vs TC avg
§102
6.5%
-33.5% vs TC avg
§112
2.6%
-37.4% vs TC avg
Black line = Tech Center average estimate • Based on career data from 785 resolved cases

Office Action

§101 §102 §103 §112
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 . Election/Restrictions NO restrictions warranted at applicant’s time of filing for CONtinuation – in – part. Priority This application is a CIP of 18/215,157 06/27/2023, now ABN; which further claims domestic priority under 35 USC 119e to provisional application 63/356,473, filed on 06/28/2022. This application is a CIP of 18/118,722, filed on 03/07/2023, now US PAT # 12341916; which further claims domestic priority under 35 USC 119e to provisional application 63/318,818, filed on 03/11/2022. Information Disclosure Statement The information disclosure statement (IDS) submitted on 08/20/2025, the submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Drawings Applicant’s drawings filed on 05/08/2025 have been inspected and is in compliance with MPEP 608.02. Specification Applicant’s specification filed on 05/08/2025 has been inspected and is in compliance with MPEP 608.01. Claim Objections NO objections warranted at applicant’s time of filing for CONtinuation – in – part. Claim Interpretation – 35 USC 112th 6th or f The following is a quotation of 35 U.S.C. 112(f): (f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph: An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked. As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph: (A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function; (B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and (C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function. Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function. Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function. Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. This application includes one or more claim limitations that use the word “means” or “step” but are nonetheless not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph because the claim limitation(s) recite(s) sufficient structure, materials, or acts to entirely perform the recited function. Such claim limitation(s) is/are: As per claim 20. A system for verifying a nonfungible token (NFT) comprising: one or more servers configured “to receive an NFT owner identifier from a verifier device, wherein the NFT owner identifier was transferred from an owner device to the verifier device, at a locale, using a physical representation of the NFT owner identifier;” wherein the one or more servers are further configured “to verify ownership of an NFT using the NFT owner identifier;” and wherein the one or more servers are further configured “to return ownership verification data of the NFT to the verifier device.” Because this/these claim limitation(s) is/are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are not being interpreted to cover only the corresponding structure, material, or acts described in the specification as performing the claimed function, and equivalents thereof. If applicant intends to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to remove the structure, materials, or acts that performs the claimed function; or (2) present a sufficient showing that the claim limitation(s) does/do not recite sufficient structure, materials, or acts to perform the claimed function. Appropriate action required. Claim Rejections - 35 USC § 112 NO rejections warranted at applicant’s filing for CONtinuation – in – part. Claim Rejections - 35 USC § 101 NO rejections warranted at applicant’s filing for CONtinuation – in – part. Double Patenting The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969). A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on non-statutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). The filing of a terminal disclaimer by itself is not a complete reply to a non-statutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13. The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based e-Terminal Disclaimer may be filled out completely online using web-screens. An e-Terminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about e-Terminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer. Claim[s] 1 – 20 are rejected on the ground of non-statutory double patenting as being unpatentable over claim[s] 1 - 20 of U.S. Patent No. 12341916 [reference patent]. Although the claims at issue are not identical, they are not patentably distinct from each other because the subject matter of the pending application and the reference patent are the same or similar in content scope and are not distinct in any manner: Methods and systems allow verifiers to conduct an ownership verification process in a frictionless and efficient manner without the need to understand and implement complex cryptographic algorithms and blockchain technologies. A disclosed system for verifying an NFT is a blockchain shell which accepts an NFT owner identifier from a verifier, verifies an NFT, and returns ownership verification data to a verifier device. Numerous approaches for registering NFT ownership with the blockchain shell, generating, transferring, and accepting the NFT owner identifier, and verifying NFT ownership using the NFT owner identifier are disclosed herein. Also see the table below for a claim-by-claim comparison. Pending US Application # 19/203148 US PAT # 1231916 [reference patent] 1. A method for verifying a nonfungible token (NFT) comprising: receiving an NFT owner identifier from a verifier device, wherein the NFT owner identifier was transferred from an owner device to the verifier device, at a locale, using a physical representation of the NFT owner identifier; verifying ownership of an NFT using the NFT owner identifier; and returning ownership verification data of the NFT to the verifier device. 1. (Currently Amended) A method for verifying a nonfungible token (NFT) comprising: receiving an NFT owner identifier from a verifier device, wherein the NFT owner identifier was transferred from an owner device to the verifier device, at a locale, using a physical representation of the NFT owner identifier; verifying ownership of an NFT using the NFT owner identifier; [[and]] returning ownership verification data of the NFT to the verifier device; sending a personal information disclosure incentive for a personal information disclosure authorization to the owner device; receiving the personal information disclosure authorization from the owner device; and releasing personal information after: (i) receiving the personal information disclosure authorization; and (ii) verifying ownership of the NFT using the NFT owner identifier. 2. The method of claim 1, further comprising: registering the NFT with a blockchain shell system; and wherein registering the NFT with the blockchain shell system includes generating the NFT owner identifier. 2. (Original) The method of claim 1, further comprising: registering the NFT with a blockchain shell system; and wherein registering the NFT with the blockchain shell system includes generating the NFT owner identifier. 3. The method of claim 2, wherein registering the NFT comprises: transferring the NFT via an entry on a blockchain. 3. (Original) The method of claim 2, wherein registering the NFT comprises: transferring the NFT via an entry on a blockchain. 4. The method of claim 2, wherein registering the NFT comprises: accessing a blockchain to find a public key associated with the NFT; and requesting a message encrypted with a private key associated with the NFT. 4. (Original) The method of claim 2, wherein registering the NFT comprises: accessing a blockchain to find a public key associated with the NFT; and requesting a message encrypted with a private key associated with the NFT. 5. The method of claim 1, further comprising: registering the NFT with a blockchain shell system; and wherein registering the NFT with the blockchain shell system includes generating the NFT owner identifier for storage on an owner device, wherein the NFT owner device. 5. (Original) The method of claim 1, further comprising: registering the NFT with a blockchain shell system; and wherein registering the NFT with the blockchain shell system includes generating the NFT owner identifier for storage on an owner device, wherein the NFT owner identifier internally identifies an owner of the owner device in a blockchain shell system. 6. The method of claim 1, further comprising: registering the NFT with a blockchain shell system, wherein registering the NFT with the blockchain shell system includes storing a full legal name for an owner in the blockchain shell system; wherein the ownership verification data of the NFT includes the full legal name for the owner. 6. (Original) The method of claim 1, further comprising: registering the NFT with a blockchain shell system, wherein registering the NFT with the blockchain shell system includes storing a full legal name for an owner in the blockchain shell system; wherein the ownership verification data of the NFT includes the full legal name for the owner. 7. The method of claim 1, further comprising: the physical representation of the NFT owner identifier is a visual encoding presented on a display of an owner device; and the NFT owner identifier is transferred from the owner device to the verifier device using an optical sensor on the verifier device. 7. (Original) The method of claim 1, further comprising: the physical representation of the NFT owner identifier is a visual encoding presented on a display of an owner device; and the NFT owner identifier is transferred from the owner device to the verifier device using an optical sensor on the verifier device. 8. The method of claim 1, wherein: the NFT owner identifier is a public wallet identifier associated with the NFT on a blockchain; and verifying ownership of the NFT includes accessing the blockchain and requesting a message encrypted with a private key associated with the public wallet identifier. 8. (Original) The method of claim 1, wherein: the NFT owner identifier is a public wallet identifier associated with the NFT on a blockchain; and verifying ownership of the NFT includes accessing the blockchain and requesting a message encrypted with a private key associated with the public wallet identifier. 9. The method of claim 1, wherein verifying ownership of the NFT using the NFT owner identifier comprises: searching a database of a blockchain shell system for the NFT owner identifier using the NFT owner identifier. 9. (Original) The method of claim 1, wherein verifying ownership of the NFT using the NFT owner identifier comprises: searching a database of a blockchain shell system for the NFT owner identifier using the NFT owner identifier. 10. The method of claim 1, wherein verifying ownership of the NFT using the NFT owner identifier comprises: searching a database of a blockchain shell system for a public wallet identifier using the NFT owner identifier; and accessing a blockchain to verify that the public wallet identifier is associated with the NFT on the blockchain. 10. (Original) The method of claim 1, wherein verifying ownership of the NFT using the NFT owner identifier comprises: searching a database of a blockchain shell system for a public wallet identifier using the NFT owner identifier; and accessing a blockchain to verify that the public wallet identifier is associated with the NFT on the blockchain. 11. The method of claim 1, wherein verifying ownership of the NFT using the NFT owner identifier comprises: delivering a link to the NFT on a blockchain with the ownership verification data. 11. (Original) The method of claim 1, wherein verifying ownership of the NFT using the NFT owner identifier comprises: delivering a link to the NFT on a blockchain with the ownership verification data. 12. The method of claim 1, further comprising: issuing an electronic identification card for the NFT owner identifier; wherein the electronic identification card is stored in a wallet application on the owner device; and wherein the physical representation is part of the electronic identification card. 12. (Original) The method of claim 1, further comprising: issuing an electronic identification card for the NFT owner identifier; wherein the electronic identification card is stored in a wallet application on the owner device; and wherein the physical representation is part of the electronic identification card. 13. The method of claim 1, further comprising: sending a personal information disclosure incentive for a personal information disclosure authorization to the owner device; receiving the personal information disclosure authorization from the owner device; and releasing personal information after: (i) receiving the personal information disclosure authorization; and (ii) verifying ownership of the NFT using the NFT owner identifier. 1. (Currently Amended) A method for verifying a nonfungible token (NFT) comprising: receiving an NFT owner identifier from a verifier device, wherein the NFT owner identifier was transferred from an owner device to the verifier device, at a locale, using a physical representation of the NFT owner identifier; verifying ownership of an NFT using the NFT owner identifier; [[and]] returning ownership verification data of the NFT to the verifier device; sending a personal information disclosure incentive for a personal information disclosure authorization to the owner device; receiving the personal information disclosure authorization from the owner device; and releasing personal information after: (i) receiving the personal information disclosure authorization; and (ii) verifying ownership of the NFT using the NFT owner identifier. 14. The method of claim 13, further comprising: registering the NFT with a blockchain shell system, wherein registering the NFT with the blockchain shell system includes storing the personal information for an owner in the blockchain shell system; and wherein registering the NFT with the blockchain shell system includes generating the NFT owner identifier. 14. (Currently Amended) The method of claim [[13]] 1, further comprising: registering the NFT with a blockchain shell system, wherein registering the NFT with the blockchain shell system includes storing the personal information for an owner in the blockchain shell system; and wherein registering the NFT with the blockchain shell system includes generating the NFT owner identifier. 15. One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause a system to execute a method for verifying a nonfungible token (NFT) comprising: receiving an NFT owner identifier from a verifier device, wherein the NFT owner identifier was transferred from an owner device to the verifier device, at a locale, using a physical representation of the NFT owner identifier; verifying ownership of an NFT using the NFT owner identifier; and returning ownership verification data of the NFT to the verifier device. 15. (Currently Amended) One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause a system to execute a method for verifying a nonfungible token (NFT) comprising: receiving an NFT owner identifier from a verifier device, wherein the NFT owner identifier was transferred from an owner device to the verifier device, at a locale, using a physical representation of the NFT owner identifier; verifying ownership of an NFT using the NFT owner identifier; [[and]] returning ownership verification data of the NFT to the verifier device; sending a personal information disclosure incentive for a personal information disclosure authorization to the owner device; receiving the personal information disclosure authorization from the owner device; and releasing personal information after: (i) receiving the personal information disclosure authorization; and (ii) verifying ownership of the NFT using the NFT owner identifier. 16. The one or more non-transitory computer-readable media of claim 15, wherein the method further comprises: registering the NFT with a blockchain shell system; and wherein registering the NFT with the blockchain shell system includes generating the NFT owner identifier. 16. (Original) The one or more non-transitory computer-readable media of claim 15, wherein the method further comprises: registering the NFT with a blockchain shell system; and wherein registering the NFT with the blockchain shell system includes generating the NFT owner identifier. 17. The one or more non-transitory computer-readable media of claim 15, wherein the method further comprises: registering the NFT with a blockchain shell system; and generating the NFT owner identifier for storage on an owner device, wherein the NFT owner identifier internally identifies an owner of the owner device in a blockchain shell system. 17. (Original) The one or more non-transitory computer-readable media of claim 15, wherein the method further comprises: registering the NFT with a blockchain shell system; and generating the NFT owner identifier for storage on an owner device, wherein the NFT owner identifier internally identifies an owner of the owner device in a blockchain shell system. 18. The one or more non-transitory computer-readable media of claim 15, wherein the method further comprises: sending a personal information disclosure incentive for a personal information disclosure authorization to the owner device; receiving the personal information disclosure authorization from the owner device; and releasing personal information after: (i) receiving the personal information disclosure authorization; and (ii) verifying ownership of the NFT using the NFT owner identifier. 15. (Currently Amended) One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause a system to execute a method for verifying a nonfungible token (NFT) comprising: receiving an NFT owner identifier from a verifier device, wherein the NFT owner identifier was transferred from an owner device to the verifier device, at a locale, using a physical representation of the NFT owner identifier; verifying ownership of an NFT using the NFT owner identifier; [[and]] returning ownership verification data of the NFT to the verifier device; sending a personal information disclosure incentive for a personal information disclosure authorization to the owner device; receiving the personal information disclosure authorization from the owner device; and releasing personal information after: (i) receiving the personal information disclosure authorization; and (ii) verifying ownership of the NFT using the NFT owner identifier. 19. The one or more non-transitory computer-readable media of claim 18, wherein the method further comprises: registering the NFT with a blockchain shell system, wherein registering the NFT with the blockchain shell system includes storing personal identifying information for an owner in the blockchain shell system; and wherein registering the NFT with the blockchain shell system includes generating the NFT owner identifier. 19. (Currently Amended) The one or more non-transitory computer-readable media of claim [[18]] 15, wherein the method further comprises: registering the NFT with a blockchain shell system, wherein registering the NFT with the blockchain shell system includes storing personal identifying information for an owner in the blockchain shell system; and wherein registering the NFT with the blockchain shell system includes generating the NFT owner identifier. 20. A system for verifying a nonfungible token (NFT) comprising: one or more servers configured to receive an NFT owner identifier from a verifier device, wherein the NFT owner identifier was transferred from an owner device to the verifier device, at a locale, using a physical representation of the NFT owner identifier; wherein the one or more servers are further configured to verify ownership of an NFT using the NFT owner identifier; and wherein the one or more servers are further configured to return ownership verification data of the NFT to the verifier device. 20. (Currently Amended) A system for verifying a nonfungible token (NFT) comprising: one or more servers configured to receive an NFT owner identifier from a verifier device, wherein the NFT owner identifier was transferred from an owner device to the verifier device, at a locale, using a physical representation of the NFT owner identifier; wherein the one or more servers are further configured to verify ownership of an NFT using the NFT owner identifier; [[and]] wherein the one or more servers are further configured to return ownership verification data of the NFT to the verifier device; wherein the one or more servers are further configured to send a personal information disclosure incentive for a personal information disclosure authorization to the owner device; wherein the one or more servers are further configured to receive the personal information disclosure authorization from the owner device; and wherein the one or more servers are further configured to release personal information after: (i) receiving the personal information disclosure authorization; and (ii) verifying ownership of the NFT using the NFT owner identifier. Claim Rejections - 35 USC § 102 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. Claim(s) 1, 8 – 10, 15, 20 is/are rejected under 35 U.S.C. 102[a][2] as being taught by Eby et al. [US PGPUB # 2023/0104103]. As per claim 1. Eby does teach a method for verifying a nonfungible token (NFT) [Eby, paragraph: 0006, lines 1 – 6, Disclosed are various approaches for managing ownership of digital assets, such as non-fungible tokens (NFTs) stored on a distributed ledger, using third-parties as custodians. When ownership of a digital asset, such as an NFT, is transferred between user, the NFT is often updated to reflect the wallet address of the new owner.] comprising: receiving an NFT owner identifier from a verifier device, wherein the NFT owner identifier was transferred from an owner device to the verifier device, at a locale, using a physical representation of the NFT owner identifier [Eby, Figure # 2, and paragraph: 0035, lines 13 – 17, In general, the request to take ownership of the NFT 123 will include at least the NFT identifier 129 of the NFT 123 and the owner identifier 139 [NFT owner identifier] of the individual requesting [i.e. applicant’s owner device] that the custody service 143 [i.e. applicant’s verifier device] take possession of the NFT 123.]; verifying ownership of an NFT using the NFT owner identifier [Eby, Figure # 2, and paragraph: 0038, lines 1 – 9, Proceeding to block 216, the custody service 143 can create a verifiable credential 159 that can be used by the customer who sent the request at block 206 to take ownership of the NFT 123 to prove that the customer is the owner of the NFT 123 held by the custody service 143. For example, the custody service 143 could generate the verifiable credential 159 and sign the verifiable credential 159 with the NFT owner private key 136.]; and returning ownership verification data of the NFT to the verifier device [Eby, Figure # 2, and paragraph: 0038, lines 13 – 23, In some examples, where custody service 143 [i.e. applicant’s verifier device] could instead provide a copy of the verifiable credential 159 to the verifier service 153. In these examples, the verifier service 153 could verify the authenticity of the verifiable credential 159 provided by the custody service 143 and then either sign the verifiable credential 159 with the verifier private key 163 or generate a signed token with the verifier private key 163, which could then be included in the verifiable credential 159. In these examples, the verifiable credential 159 could then be returned by the verifier service 153 to the custody service 143.]. As per claim 8. Eby does teach the method of claim 1, wherein: the NFT owner identifier is a public wallet identifier associated with the NFT on a blockchain [Eby, Figure # 1, and paragraph: 0016, lines 6 – 8, In some implementations, the NFT owner public key 133 can be referred to as the wallet address or owner address for the NFT 123.]; and verifying ownership of the NFT includes accessing the blockchain and requesting a message encrypted with a private key associated with the public wallet identifier [Eby, Figure # 1, and paragraph: 0016, lines 8 – 15, For each NFT owner public key 133, there can also be a respective NFT owner private key 136. The NFT owner private key 136 allows for the owner of an NFT 123 to verify his or her ownership by generating cryptographically secure signatures that can be verified using the NFT owner public key 133. Accordingly, the NFT owner private key 136 may be stored in a non-public location separate from the asset ledger 113.]. As per claim 9. Eby does teach the method of claim 1, wherein verifying ownership of the NFT using the NFT owner identifier comprises: searching a database of a blockchain shell system for the NFT owner identifier using the NFT owner identifier [Eby, paragraph: 0022, lines 8 – 14, The custody service 143 can also create, revoke, or update ownership claims 126 stored in the identity ledger 116 for individual NFTs 123. As part of these processes, the custody service 143 can also create or issue verifiable credentials 159 to client devices 109 so that owners of NFTs 123 can verify their ownership to third-parties.]. As per claim 10. Eby does teach the method of claim 1, wherein verifying ownership of the NFT using the NFT owner identifier comprises: searching a database of a blockchain shell system for a public wallet identifier using the NFT owner identifier [Eby, Figure # 3, paragraph: 0045, Proceeding to block 306, the verifier service 153 can send a proof request to the identity wallet 169 in response to receiving the verification request at block 303. The proof request can specify the verifiable credential 159 to be authenticated or verified, so that the identity wallet 169 can return the proof for the desired verifiable credential 159. For example, the proof request could specify the NFT 123 associated with the verifiable credential 159 (e.g., by including the NFT identifier 129 of the NFT 123).]; and accessing a blockchain to verify that the public wallet identifier is associated with the NFT on the blockchain [Eby, Figure # 3, paragraph: 0046, Then, at block 309, the identity wallet 169 can search for the verifiable credential 159 and return a proof of authenticity or integrity to the verifiable credential 159 to the verifier service 153. For example, if the verifiable credential 159 had been signed by the custody service 143 or the verifier service 153, then the identity wallet 169 could return the signature of the verifiable credential 159. As another example, if the verifiable credential 159 includes a token that had been signed by the custody service 143 or the verifier service 153, the token and the cryptographic signature for the token could be returned to the verifier service 153 as proof of authenticity or integrity.]. As per non – transitory computer-readable media claim 15 that includes the same or similar claim limitations as method claim 1, and is similarly rejected. ***The examiner notes that applicant’s recited: “non – transitory computer-readable media,” “instructions,” and “one or more processors” is taught by the prior art of Eby at paragraphs: 0067 – 0070, 0072. As per system claim 20 that includes the same or similar claim limitations as method claim 1, and is similarly rejected. ***The examiner notes that applicant’s recited: “one or more servers” is taught by the prior art of Eby at paragraph: 0012, lines 1 – 4. 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. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or non-obviousness. Claim(s) 2 - 4, 16, 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Eby et al. [US PGPUB # 2023/0104103] in view of Cardo Sanchez et al. [US PGPUB # 2022/0269754] As per claim 2. Eby does teach what is taught in the rejection of claim # 1 above. While Eby does teach the claim limitation of: “...and wherein registering the NFT with the blockchain shell system includes generating the NFT owner identifier.” [paragraph: 0029, To begin, a user registers his owner identifier 139 as a decentralized identifier (DID) 127 in the identity ledger 116. The DID 127 can include information identifying the user (e.g., name, contact information, etc.) and a public key that can be used to identify the user]. Eby does not clearly teach the method of claim 1, further comprising: registering the NFT with a blockchain shell system. However, Cardo Sanchez does teach the method of claim 1, further comprising: registering the NFT with a blockchain shell system [paragraph: 0005, lines 2 – 6, relating to particular Assets on a blockchain, each represented by a Non-Fungible Token (NFT) which upon creation is recorded in a block of a public blockchain architecture alongside all of the information relating to the represented Asset.]. It would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Eby as modified and Cardo Sanchez in order for the exchange or transfer thru a custodian computing environment of a nonfungible token between an owner and requesting party of Eby as modified to include digital right asset ledger of Cardo Sanchez. This would allow for the requesting party and owner to assert and prove any action or access to the NFT before access or action is allowed to the NFT. See paragraph: 0017 of Cardo Sanchez. As per claim 3. Eby as modified does teach the method of claim 2, wherein registering the NFT comprises: transferring the NFT via an entry on a blockchain [Eby, paragraph: 0029, To begin, a user registers his owner identifier 139 as a decentralized identifier (DID) 127 in the identity ledger 116. The DID 127 can include information identifying the user (e.g., name, contact information, etc.) and a public key that can be used to identify the user.]. As per claim 4. Eby does teach the method of claim 2, wherein registering the NFT comprises: accessing a blockchain to find a public key associated with the NFT [Eby, Figure # 1, and paragraph: 0016, lines 8 – 15, For each NFT owner public key 133, there can also be a respective NFT owner private key 136. The NFT owner private key 136 allows for the owner of an NFT 123 to verify his or her ownership by generating cryptographically secure signatures that can be verified using the NFT owner public key 133. Accordingly, the NFT owner private key 136 may be stored in a non-public location separate from the asset ledger 113.]; and requesting a message encrypted with a private key associated with the NFT [Eby, Figure # 2, and paragraph: 0038, lines 1 – 9, Proceeding to block 216, the custody service 143 can create a verifiable credential 159 that can be used by the customer who sent the request at block 206 to take ownership of the NFT 123 to prove that the customer is the owner of the NFT 123 held by the custody service 143. For example, the custody service 143 could generate the verifiable credential 159 and sign the verifiable credential 159 with the NFT owner private key 136.]. As per non – transitory computer-readable media claim 16 that includes the same or similar claim limitations as method claim 2, and is similarly rejected. As per non – transitory computer-readable media claim 17 that includes the same or similar claim limitations as method claim 3, and is similarly rejected. Claim(s) 5 – 7, 11, 14, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Eby et al. [US PGPUB # 2023/0104103] in view of Barhudarian et al. [US PGPUB # 2023/0135947] As per claim 5. Eby does teach what is taught in the rejection of claim # 1 above. Eby does not clearly teach the method of claim 1, further comprising: registering the NFT with a blockchain shell system; and wherein registering the NFT with the blockchain shell system includes generating the NFT owner identifier for storage on an owner device, wherein the NFT owner identifier internally identifies an owner of the owner device in a blockchain shell system. However, Barhudarian does teach the method of claim 1, further comprising: registering the NFT with a blockchain shell system [Figure # 9, and paragraph: 0076, lines 1 – 8, FIG. 9A illustrates an example communication pattern 900A for registering a new physical item and associating the new physical item with a new NFT. As illustrated in FIG. 9A, the data system 906 is configured to generate a new record associated with a new physical item (represented by arrow 912A). In response to generating a new record, the data system 906 is configured to send a request to the decentralized system 908 (represented by arrow 914A), causing the new NFT to be registered in the decentralized system 908 (represented by arrow 916A).]; and wherein registering the NFT with the blockchain shell system includes generating the NFT owner identifier for storage on an owner device, wherein the NFT owner identifier internally identifies an owner of the owner device in a blockchain shell system [Barhudarian, Figure # 9, and paragraph: 0077, lines 1 – 2, Once the first dataset and the second dataset are stored in the smart fabric 902, a computing device 910 (e.g., a computing device associated with the current owner or a potential buyer) can be used to verify authenticity and/or ownership of the physical item]. It would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Eby as modified and Barhudarian in order for the exchange or transfer thru a custodian computing environment of a nonfungible token between an owner and requesting party of Eby as modified to include smart fabric of Barhudarian. This would allow for the requesting party and owner to consult a smart contract and prove that any action or access to the NFT is sanctioned by the smart contract before access or action is allowed with the NFT. See paragraph: 0004 of Barhudarian. As per claim 6. Eby as modified does teach the method of claim 1, further comprising: registering the NFT with a blockchain shell system, wherein registering the NFT with the blockchain shell system includes storing a full legal name for an owner in the blockchain shell system [Barhudarian, paragraph: 0049, In some embodiments, the NFPFT system further includes a data system configured to store a data record associated with the physical item 110 and/or NFT 122…..The computer system of manufacture 130 is further configured to record a data record associated with the physical item 110 in the data system 170. For example, the data record associated with the physical item 110 may contain (but are not limited to) (1) attribute(s) of the physical item (e.g., a design, a color, a photo, and/or a sales price of the physical item), (2) personal information associated with owner(s) of the physical item 110 (e.g., a name, an email address, a phone number, a physical address of each owner), and/or (3) service performed on the physical item 110 (e.g., repair, maintenance, appraisal, etc.).]; wherein the ownership verification data of the NFT includes the full legal name for the owner [Barhudarian, paragraph: 0072, lines 1 – 12, In some embodiments, the computing device 500 is also configured to extract the service end point from the smart fabric 112 and/or the NFT 122 and access the data system 170 via the service end point 854 to retrieve the data record associated with the physical item 110, such as (but not limited to) (1) attribute(s) of the physical item 110 (e.g., a design, a color, a photo, and/or a sales price of the physical item 110), (2) personal information associated with owner(s) of the physical item 110 (e.g., a name, an email address, a phone number, a physical address of each owner), and/or (3) service performed on the physical item 110 (e.g., repair, maintenance, appraisal).]. As per claim 7. Eby as modified does teach the method of claim 1, further comprising: the physical representation of the NFT owner identifier is a visual encoding presented on a display of an owner device [Barhudarian, Figure # 8, and paragraph: 0072, lines 12 – 17, In some embodiments, in response to retrieving the data record associated with the physical item 110, the computing device 500 is configured to generate a visualization, visualizing the data record associated with the physical item, e.g., displaying a photo of the physical item.]; and the NFT owner identifier is transferred from the owner device to the verifier device using an optical sensor on the verifier device [Eby, Figure # 2, and paragraph: 0035, lines 13 – 17, In general, the request to take ownership of the NFT 123 will include at least the NFT identifier 129 of the NFT 123 and the owner identifier 139 [NFT owner identifier] of the individual requesting [i.e. applicant’s owner device] that the custody service 143 [i.e. applicant’s verifier device] take possession of the NFT 123. Then further of Barhudarian, Figure # 8, and paragraph: 0072, lines 12 – 17, In some embodiments, in response to retrieving the data record associated with the physical item 110, the computing device 500 is configured to generate a visualization, visualizing the data record associated with the physical item, e.g., displaying a photo of the physical item.]. As per claim 11. Eby as modified does teach the method of claim 1, wherein verifying ownership of the NFT using the NFT owner identifier comprises: delivering a link to the NFT on a blockchain with the ownership verification data [Barhudarian, paragraph: 0071, lines 8 – 20, As such, when a set of multiple physical items are physically linked together, their corresponding NFTs are digitally linked together. As another example, an artist may create a first physical item and associate the first physical item with a first NFT. Later, the artist may create a second physical item, and associate the second physical item with a second NFT. If the first item and the second item form a set, the second NFT may include an NFT identifier of the first NFT in its metadata, and the first NFT may be added an NFT identifier of the second NFT in its metadata.]. As per claim 14. Eby as modified does teach the method of claim 13, further comprising: registering the NFT with a blockchain shell system, wherein registering the NFT with the blockchain shell system [Barhudarian, Figure # 9, and paragraph: 0076, lines 1 – 8, FIG. 9A illustrates an example communication pattern 900A for registering a new physical item and associating the new physical item with a new NFT. As illustrated in FIG. 9A, the data system 906 is configured to generate a new record associated with a new physical item (represented by arrow 912A). In response to generating a new record, the data system 906 is configured to send a request to the decentralized system 908 (represented by arrow 914A), causing the new NFT to be registered in the decentralized system 908 (represented by arrow 916A).] includes storing the personal information for an owner in the blockchain shell system [Barhudarian, paragraph: 0072, lines 1 – 12, In some embodiments, the computing device 500 is also configured to extract the service end point from the smart fabric 112 and/or the NFT 122 and access the data system 170 via the service end point 854 to retrieve the data record associated with the physical item 110, such as (but not limited to) (1) attribute(s) of the physical item 110 (e.g., a design, a color, a photo, and/or a sales price of the physical item 110), (2) personal information associated with owner(s) of the physical item 110 (e.g., a name,]; and wherein registering the NFT with the blockchain shell system includes generating the NFT owner identifier [Barhudarian, paragraph: 0006, lines 1 – 4, In some embodiments, the NFT also includes an owner identifier associated with an owner of the NFT. The owner of the NFT corresponds to an owner of the physical item]. As per non – transitory computer-readable media claim 19 that includes the same or similar claim limitations as method claim 14, and is similarly rejected. Claim(s) 12, is/are rejected under 35 U.S.C. 103 as being unpatentable over in Eby et al. [US PGPUB # 2023/0104103] view of Spivak et al. [US PGPUB # 2022/0366061] As per claim 12. Eby does teach what is taught in the rejection of claim 1 above. Eby does not clearly teach the method of claim 1, further comprising: issuing an electronic identification card for the NFT owner identifier; wherein the electronic identification card is stored in a wallet application on the owner device; and wherein the physical representation is part of the electronic identification card. However, Spivak does teach the method of claim 1, further comprising: issuing an electronic identification card for the NFT owner identifier [paragraph: 0108, In another example, the security device on a physical object can be used to trigger operations or processes, such as calling the API to a system that opens the lock on a door that the security device is on. The door can only be unlocked by someone who is close enough to scan the security device on the door, for example. In the case of NFTs, a scan of the security device on the door and/or of the security device on the user's printed ID card or badge or pass or ticket, can initiate services related to the door, such as unlocking the door for that particular badge holder. Where this can connect to NFTs is that the badge or ID card may be represented by an NFT, and the physical instance of that badge/ID card is an authorized copy or instance of that NFT. A user of the NFT for the badge is verified as having permission to enter that door, when they authenticate the security device on their physical badge/ID as well as the security device on the door with the metadata connected to the NFT for their physical badge/ID and the permissions it grants.]; wherein the electronic identification card is stored in a wallet application on the owner device [paragraph: 0108, In another example, the security device on a physical object can be used to trigger operations or processes, such as calling the API to a system that opens the lock on a door that the security device is on.]; and wherein the physical representation is part of the electronic identification card [paragraph: 0108, In another example, the security device on a physical object can be used to trigger operations or processes, such as calling the API to a system that opens the lock on a door that the security device is on. The door can only be unlocked by someone who is close enough to scan the security device on the door, for example. In the case of NFTs, a scan of the security device on the door and/or of the security device on the user's printed ID card or badge or pass or ticket, can initiate services related to the door, such as unlocking the door for that particular badge holder. Where this can connect to NFTs is that the badge or ID card may be represented by an NFT, and the physical instance of that badge/ID card is an authorized copy or instance of that NFT. A user of the NFT for the badge is verified as having permission to enter that door, when they authenticate the security device on their physical badge/ID as well as the security device on the door with the metadata connected to the NFT for their physical badge/ID and the permissions it grants.]. It would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Eby and Spivak in order for the exchange or transfer thru a custodian computing environment of a nonfungible token between an owner and requesting party of Eby to include authenticating the owner - NFT by a physical means to the requesting party of Spivak. This would allow for the custodian computing environment to implement a simplistic way of authenticating the owner - physical NFT by use of physically authenticating operations. See paragraph: 0110 of Spivak. Allowable Subject Matter Claim[s] 13 and 18 contain allowable subject matter, but as allowable subject matter has been indicated, applicant's reply must either comply with all formal requirements or specifically traverse each requirement not complied with. See 37 CFR 1.111(b) and MPEP § 707.07(a). Claim[s] 13, 18 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. ***The examiner notes that a reasons for allowance can be written the next subsequent office action once all formal requirements have been overcome. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Haddad et al., who does teach utilizing non-fungible tokens (“NFTs”) as universal digital identification are provided. A user may be assigned an NFT on a distributed ledger attesting to the user's identity. The user may request to be authenticated. The user may be prompted to transfer the NFT to a smart contract on the distributed ledger. An authentication program may check the NFT and the NFT's history on the ledger to determine that the NFT belongs to the user. When the NFT belongs to the user, the authentication program may authenticate the user. The smart contract may transfer the NFT back to the user, so that the user may use the NFT again to be authenticated. Hale et al., who does teach authenticated encryption with associated data (AEAD) process, encrypting and authenticating a non-fungible token (NFT) and authenticating a NFT descriptor without encryption to generate a limited access non fungible tokens (LANFT), the LANFT including an authenticated and encrypted NFT portion and an authenticated and nonencrypted NFT descriptor portion which is viewable by a user prior to obtaining ownership of the NFT; and in response to receiving a confirmation that the user has obtained ownership of the NFT, providing a private key to the user, wherein the private key is used to decrypt the NFT. Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANT SHAIFER - HARRIMAN whose telephone number is (571)272-7910. The examiner can normally be reached M - F: 9am to 5pm. 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, Ali Shayanfar can be reached at 571 – 270 - 1050. 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. /DANT B SHAIFER HARRIMAN/ Primary Examiner, Art Unit 2434
Read full office action

Prosecution Timeline

May 08, 2025
Application Filed
Jun 29, 2026
Non-Final Rejection mailed — §101, §102, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12665930
SYSTEMS AND METHODS FOR DYNAMIC POLICY ASSIGNMENT OF SECURE COMMUNICATION SESSIONS USING SPDM
3y 3m to grant Granted Jun 23, 2026
Patent 12657270
Digital Biometric User Authentication Processes
3y 1m to grant Granted Jun 16, 2026
Patent 12627707
MITIGATING RISK FROM MULTI-FACTOR AUTHENTICATION FATIGUE ATTACKS
2y 8m to grant Granted May 12, 2026
Patent 12621275
SYSTEM AND METHOD TO CONTROL ACCESS OF ULTRA-WIDEBAND (UWB) DEVICES
2y 2m to grant Granted May 05, 2026
Patent 12615160
SYSTEMS AND METHODS FOR ENFORCING CRYPTOGRAPHICALLY SECURE ACTIONS IN PUBLIC, NON-PERMISSIONED BLOCKCHAINS USING BIFURCATED SELF-EXECUTING PROGRAMS COMPRISING SHARED DIGITAL SIGNATURE REQUIREMENTS
1y 8m to grant Granted Apr 28, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
81%
Grant Probability
98%
With Interview (+17.4%)
2y 11m (~1y 9m remaining)
Median Time to Grant
Low
PTA Risk
Based on 785 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month