DETAILED ACTION
This non-final office action is in response to claims 5-8, 12-14, 16-23, and 29-33 filed on 04/03/2026 for examination. Claims 5-8, 12-14, 16-23, and 29-33 are being examined and are pending.
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 .
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 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.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 04/03/2026 has been entered.
Response to Amendment
The amendment filed April 3, 2026 has been entered. Claims 5-8, 12-14, and 16-23 remain pending in the application. Claims 29-33 are new. The claims have been amended. Applicant’s arguments and amendments to the claims are directed to the 35 U.S.C. 102 and 103 rejections previously set forth in the Final Office Action mailed January 22, 2026. Claims 5, 12, 18, and 22 have been amended and have necessitated a new ground(s) of rejection in this Office Action. Further, applicant’s arguments regarding claims 5-8, 12-14, 16-23, and 29-33 have been fully considered but are not persuasive to differentiate over the prior art as presently cited. Particularly:
Applicant opines that Hu et al. (CN113743921A; hereinafter “Hu”) appears to fail to disclose “wherein the verifiable presentation is verified without reliance on third-party verifiable credentials by checking an authenticity of the NFT on the spot”. Remarks, pgs. 6-7. Applicant further cites their specification at [0042] and contrasts it to the disclosure of Hu at [0013-0019] regarding the verification mechanism and the NFT as its own authority. Id. However, the claims as written do no recite that the NFT must be its “own authority”, nor do they exclude use of an issuer contract, NFT contract, registry, or general blockchain infrastructure. Regarding the written claim language: Hu teaches wherein a verification is based on querying the current NFT holder information in the NFT contract and comparing the blockchain address corresponding to the self-signing user’s DID information with the blockchain address of the current NFT holder. See, e.g., Hu at [0162-164], [0137], and [0141-142]. If the addresses match, the verification is successful. Id. If the addresses do not match, the VP verification fails. Id. I.e., authenticity of the asserted NFT holder possession/current-holder status is checked at verification time and without relying on a separate third-party verifiable credential. Id. Accordingly, Hu teaches “wherein the verifiable presentation is verified without reliance on third-party verifiable credentials by checking an authenticity of the NFT on the spot”. Applicant’s associated remarks are unpersuasive.
In view of the foregoing, as well as hereinbelow with regards to 35 U.S.C. 103, applicant’s arguments regarding claims 5-8, 12-14, 16-23, and 29-33 have been fully considered but are not persuasive to differentiate over the prior art.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim(s) 5-8, 12-14, 16-23, and 29-33 is/are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Particularly:
The term “on the spot” in claim 5 is an idiomatic/relative term which renders the claim indefinite. The term “on the spot” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree of timeliness/locality/location, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. E.g., is it limited to milliseconds, seconds, a single processor, a single portion of memory, etc. Claims 12 and 33 recite a similar deficiency, and are rejected under like rationale. Claims 6-8, 13-14, 16-23, and 29-32 incorporate the deficiency of their respective parent claim, and are rejected under like rationale.
Claim 30 recites “the verifiable credential presentation” in line in line 2. There is insufficient antecedent basis for this limitation in the claim. Claim 32 recites a similar deficiency, and is rejected under like rationale.
Claim Rejections - 35 USC § 102
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 5-6, 8, 12-13, 16-18, 20-22, 29, and 31 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Hu et al. (CN113743921A; Hereinafter “Hu”).
Regarding claim 5, Hu teaches a method for verifying user credentials (abstract, [0163-265]), comprising:
receiving a verifiable presentation that is signed using a private key of a public key infrastructure ([0034], [0111-112], and [0150-156] – a verifiable presentation/statement is signed using a private key of the holder. The verifiable statement is received by the verification party. The private key has a corresponding public key <i.e., part of a public key infrastructure>), wherein the private key is associated with a cryptocurrency address holding a non- fungible token (NFT) ([0162-165], [0122], and [0133] – the holder’s private key is associated with the holder’s DID/blockchain address holding an asset/non-fungible token “NFT”);
obtaining a public key corresponding to the private key ([0037-038], [0047], [0157-160] – the DID document is queried and the holder’s public key is acquired and used to perform signature verification on the verifiable representation/presentation); and
verifying the verifiable presentation using the obtained public key, wherein the verifiable presentation is to prove possession of one or more verifiable credentials with predetermined characteristics ([0162-165], [0111-112], and [0142] – the verifiable presentation is verified using the public key of the holder obtained via the DID document. The verifiable presentation is verified to confirm the holder’s possession of both the verifiable credential and the entitlement/status to use it <i.e., predetermined characteristics>. E.g., the verifiable credential is combined with the digital signature of the holder to create the verifiable presentation), wherein the verifiable presentation is verified without reliance on third-party verifiable credentials by checking an authenticity of the NFT on the spot ([0162-164], [0137], and [0141-142] – the verification is based on querying the current NFT holder information in the NFT contract and comparing the blockchain address corresponding to the self-signing user’s DID information with the blockchain address of the current NFT holder. If the addresses match, verification successful. If the addresses do not match, VP verification fails. <i.e., authenticity of the asserted NFT holder possession/current-holder status is checked at verification time and without relying on a separate third-party verifiable credential>).
Regarding claim 6, Hu teaches the method of claim 5, wherein an owner of the NFT assigns a public decentralized identifier (DID) to the NFT and registers the public DID on a public ledger ([0128-131] and [0110] – the DID document is deployed <i.e., registered> on a public blockchain ledger. The DID is associated with <i.e., assigned to> the NFT via a holder), the method further comprising: resolving the public DID of the NFT to a DID document ([0110], [0047], and [0158-159] – the DID is resolved into a DID document. The DID is associated with the NFT via the holder); and obtaining the public key from the DID document ([0110], [0047], [0158-159], and [0173-175] – the DID documents include the public key, and the public key is obtained by querying the identifier/identification document <i.e., DID document> for the holder).
Regarding claim 8, Hu teaches the method of claim 5, wherein: the cryptocurrency address is an Ethereum address ([0113] and [0164] – the blockchain used is an Ethereum blockchain <i.e., the address is an Ethereum address>).
Regarding claim 12, Hu teaches an apparatus for verifying user credentials (abstract, [0163-265]), comprising:
a processor configured to receive a verifiable presentation that is signed using a private key of a public key infrastructure ([0034], [0111-112], and [0150-156] – a verifiable presentation/statement is signed using a private key of the holder. The verifiable statement is received by the verification party. The private key has a corresponding public key <i.e., part of a public key infrastructure>), obtain a public key corresponding to the private key ([0037-038], [0047], [0157-160] – the DID document is queried and the holder’s public key is acquired and used to perform signature verification on the verifiable representation/presentation), and verify the verifiable presentation using the obtained public key ([0162-165], [0111-112], and [0142] – the verifiable presentation is verified using the public key of the holder obtained via the DID document), wherein the private key is associated with a cryptocurrency address holding a non-fungible token (NFT) ([0162-165], [0122], and [0133] – the holder’s private key is associated with the holder’s DID/blockchain address holding an asset/non-fungible token “NFT”), the verifiable presentation is to prove possession of one or more verifiable credentials with predetermined characteristics ([0162-165], [0111-112], and [0142] – the verifiable presentation is verified using the public key of the holder obtained via the DID document. The verifiable presentation is verified to confirm the holder’s possession of both the verifiable credential and the entitlement/status to use it <i.e., predetermined characteristics>. E.g., the verifiable credential is combined with the digital signature of the holder to create the verifiable presentation) and the processor is further configured to verify the verifiable presentation without reliance on third-party verifiable credentials by checking an authenticity of the NFT on the spot ([0162-165], [0111-112], and [0142] – the verifiable presentation is verified using the public key of the holder obtained via the DID document. The verifiable presentation is verified to confirm the holder’s possession of both the verifiable credential and the entitlement/status to use it <i.e., predetermined characteristics>. E.g., the verifiable credential is combined with the digital signature of the holder to create the verifiable presentation).
Regarding claim 13, Hu teaches the apparatus of claim 12, wherein: an owner of the NFT assigns a public decentralized identifier (DID) to the NFT and registers the public DID on a public ledger ([0128-131] and [0110] – the DID document is deployed <i.e., registered> on a public blockchain ledger. The DID is associated with <i.e., assigned to> the NFT via a holder), and the processor is configured to determine a DID document based on the public DID of the NFT and obtain the public key from the DID document ([0110], [0047], [0158-159], and [0173-175] – the DID documents include the public key, and the public key is obtained by querying the identifier/identification document <i.e., DID document> for the holder; [0037-038], [0047], [0157-160] – the DID document is queried and the holder’s public key is acquired and used to perform signature verification on the verifiable representation/presentation).
Regarding claim 16, Hu teaches the method of claim 5, wherein: the verifiable presentation is comprised of data synthesized from, but not containing, the one or more verifiable credentials such that the data is synthesized using zero-knowledge proofs ([0111-0112] – the verifiable presentation may be generated based on zero-knowledge proofs pertaining to the verifiable credential).
Regarding claim 17, Hu teaches the method of claim 5, further comprising: processing of the verifiable presentation to prove possession of the one or more verifiable credentials by cryptographically verifying a digital signature of the one or more verifiable credentials with the public key ([0162-165], [0142], and [0171-176] – the verifier performs signature verification using the public key obtained from the identifier/DID documents to verify the verifiable presentation. The verifiable presentation is verified to confirm the holder’s possession of both the verifiable credential and the entitlement/status to use it).
Regarding claim 18, Hu teaches the method of claim 5, wherein: the verifiable presentation is issued by the NFT or an owner of the NFT ([0111-112], [0034], and [0150-160] – the verifiable presentation is created/signed by the holder <i.e., NFT/owner of the NFT>).
Regarding claim 20, Hu teaches the apparatus of claim 12, wherein: the verifiable presentation is comprised of data synthesized from, but not containing, the one or more verifiable credentials such that the data is synthesized using zero-knowledge proofs ([0111-0112] – the verifiable presentation may be generated based on zero-knowledge proofs pertaining to the verifiable credential).
Regarding claim 21, Hu teaches the apparatus of claim 12, the processor further configured to: process the verifiable presentation to prove possession of the one or more verifiable credentials by cryptographically verifying a digital signature of the one or more verifiable credentials with the public key ([0162-165], [0142], and [0171-176] – the verifier performs signature verification using the public key obtained from the identifier/DID documents to verify the verifiable presentation. The verifiable presentation is verified to confirm the holder’s possession of both the verifiable credential and the entitlement/status to use it).
Regarding claim 22, Hu teaches the apparatus of claim 12, wherein: the verifiable presentation is issued by the NFT or an owner of the NFT ([0111-112], [0034], and [0150-160] – the verifiable presentation is created/signed by the holder <i.e., NFT/owner of the NFT>).
Regarding claim 29, Hu teaches the method of claim 5, wherein: the checking of the authenticity of the NFT on the spot is based on the public key and a derived cryptocurrency address holding the NFT ([0037-040], [0047], and [0157-164] – the holder’s public key is obtained and used to verify the verifiable representation, and the blockchain address corresponding to the self-signing user’s DID information is compared with the address information of the current NFT holder queried from the NFT contract).
Regarding claim 31, Hu teaches the apparatus of claim 12, wherein: the processor is further configured to check the authenticity of the NFT on the spot based on the public key and a derived cryptocurrency address holding the NFT ([0037-040], [0047], and [0157-164] – the holder’s public key is obtained and used to verify the verifiable representation, and the blockchain address corresponding to the self-signing user’s DID information is compared with the address information of the current NFT holder queried from the NFT contract).
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) 7, 14, 19, 23, and 33 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hu in view of Eby et al. (US20230104103A1; Hereinafter “Eby”).
Regarding claim 7, Hu teaches the method of claim 6, wherein: the verifiable presentation is verified when the cryptocurrency address holding the NFT can be derived |from the DID information| ([0164] and [0141]when the NFT holder address matches the signer’s DID information the verifiable presentation may be verified). Yet, Hu fails to specifically disclose the verifiable presentation is verified when the cryptocurrency address holding the NFT can be derived from the public key.
However, Eby teaches a similar system wherein verifiable credentials are verified by recipients (see, e.g., Eby at [0022-024]), wherein the verifiable presentation is verified when the cryptocurrency address holding the NFT can be derived from the public key ([0034], [0016], and [0007] – cryptocurrency address is holding the NFT. The cryptocurrency address can be the public key of the NFT owner <i.e., can be derived from the public key>; [0045-048], and [0022-024] – a verifier obtains the public key/address from the custody account’s public DID. The verifier may verify a signature associated with the verifiable credential using the public key/address <i.e., if the public key/address are wrong, verification fails>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hu with the teachings of Eby, wherein the verifiable presentation is verified when the cryptocurrency address holding the NFT can be derived from the public key, to securely ensure the holder is entitled to utilize the NFT/verifiable credential via the blockchain (see, e.g., Hu at [0164] and [0141]; with Eby at [0034], [0016], [0045-048], and [0022-024]).
Regarding claim 14, Hu teaches the apparatus of claim 13, wherein the verifiable presentation is verified when the cryptocurrency address holding the NFT can be derived |from the DID information| ([0164] and [0141]when the NFT holder address matches the signer’s DID information the verifiable presentation may be verified). Yet, Hu fails to specifically disclose the verifiable presentation is verified when the cryptocurrency address holding the NFT can be derived from the public key.
However, Eby teaches a similar system wherein verifiable credentials are verified by recipients (see, e.g., Eby at [0022-024]), wherein the verifiable presentation is verified when the cryptocurrency address holding the NFT can be derived from the public key ([0034], [0016], and [0007] – cryptocurrency address is holding the NFT. The cryptocurrency address can be the public key of the NFT owner <i.e., can be derived from the public key>; [0045-048], and [0022-024] – a verifier obtains the public key/address from the custody account’s public DID. The verifier may verify a signature associated with the verifiable credential using the public key/address <i.e., if the public key/address are wrong, verification fails>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hu with the teachings of Eby, wherein the verifiable presentation is verified when the cryptocurrency address holding the NFT can be derived from the public key, to securely ensure the holder is entitled to utilize the NFT/verifiable credential via the blockchain (see, e.g., Hu at [0164] and [0141]; with Eby at [0034], [0016], [0045-048], and [0022-024]).
Regarding claim 19, Hu teaches the method of claim 5. Yet, Hu appears to fail to specifically disclose further comprising: determining that a public decentralized identifier (DID) of the NFT is deprecated due to a transfer of the NFT to a new owner having a different public and private key pair.
However, Eby teaches a similar system wherein verifiable credentials are verified by recipients (see, e.g., Eby at [0022-024]), further comprising: determining that a public decentralized identifier (DID) of the NFT is deprecated due to a transfer of the NFT to a new owner having a different public and private key pair ([0050-053], [0018], and [0022] – when the NFT is transferred to a new owner any/all previous ownership claims are updated in the blockchain to show they are revoked. The new owner and the old owner are represented as owners in the blockchain using their DID documents, which are each associated with respective public and private key pairs <i.e., the old owner/key pair is deprecated for the NFT, and the new owner has a different key pair>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hu with the teachings of Eby, further comprising: determining that a public decentralized identifier (DID) of the NFT is deprecated due to a transfer of the NFT to a new owner having a different public and private key pair, to ensure former owners cannot continue to exert control over the NFT/VCs (see, e.g., Eby at [0050-053], [0018], and [0022]).
Regarding claim 23, Hu teaches the apparatus of claim 12. Yet, Hu appears to fail to specifically disclose further comprising: determining that a public decentralized identifier (DID) of the NFT is deprecated due to a transfer of the NFT to a new owner having a different public and private key pair.
However, Eby teaches a similar system wherein verifiable credentials are verified by recipients (see, e.g., Eby at [0022-024]), further comprising: determining that a public decentralized identifier (DID) of the NFT is deprecated due to a transfer of the NFT to a new owner having a different public and private key pair ([0050-053], [0018], and [0022] – when the NFT is transferred to a new owner any/all previous ownership claims are updated in the blockchain to show they are revoked. The new owner and the old owner are represented as owners in the blockchain using their DID documents, which are each associated with respective public and private key pairs <i.e., the old owner/key pair is deprecated for the NFT, and the new owner has a different key pair>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hu with the teachings of Eby, further comprising: determining that a public decentralized identifier (DID) of the NFT is deprecated due to a transfer of the NFT to a new owner having a different public and private key pair, to ensure former owners cannot continue to exert control over the NFT/VCs (see, e.g., Eby at [0050-053], [0018], and [0022]).
Regarding claim 33, Hu teaches a method for verifying user credentials (abstract, [0163-265]), comprising:
receiving a verifiable presentation that is signed using a private key of a public key infrastructure ([0034], [0111-112], and [0150-156] – a verifiable presentation/statement is signed using a private key of the holder. The verifiable statement is received by the verification party. The private key has a corresponding public key <i.e., part of a public key infrastructure>), wherein the private key is associated with a cryptocurrency address holding a non- fungible token (NFT) ([0162-165], [0122], and [0133] – the holder’s private key is associated with the holder’s DID/blockchain address holding an asset/non-fungible token “NFT”);
obtaining a public key corresponding to the private key ([0037-038], [0047], [0157-160] – the DID document is queried and the holder’s public key is acquired and used to perform signature verification on the verifiable representation/presentation);
verifying the verifiable presentation using the obtained public key, wherein the verifiable presentation is to prove possession of one or more verifiable credentials with predetermined characteristics ([0162-165], [0111-112], and [0142] – the verifiable presentation is verified using the public key of the holder obtained via the DID document. The verifiable presentation is verified to confirm the holder’s possession of both the verifiable credential and the entitlement/status to use it <i.e., predetermined characteristics>. E.g., the verifiable credential is combined with the digital signature of the holder to create the verifiable presentation), wherein the verifiable presentation is verified without reliance on third-party verifiable credentials by checking an authenticity of the NFT on the spot ([0162-164], [0137], and [0141-142] – the verification is based on querying the current NFT holder information in the NFT contract and comparing the blockchain address corresponding to the self-signing user’s DID information with the blockchain address of the current NFT holder. If the addresses match, verification successful. If the addresses do not match, VP verification fails. <i.e., authenticity of the asserted NFT holder possession/current-holder status is checked at verification time and without relying on a separate third-party verifiable credential>). Yet, Hu appears to fail to specifically disclose further comprising: determining that a public decentralized identifier (DID) of the NFT is deprecated due to a transfer of the NFT to a new owner having a different public and private key pair.
However, Eby teaches a similar system wherein verifiable credentials are verified by recipients (see, e.g., Eby at [0022-024]), further comprising: determining that a public decentralized identifier (DID) of the NFT is deprecated due to a transfer of the NFT to a new owner having a different public and private key pair ([0050-053], [0018], and [0022] – when the NFT is transferred to a new owner any/all previous ownership claims are updated in the blockchain to show they are revoked. The new owner and the old owner are represented as owners in the blockchain using their DID documents, which are each associated with respective public and private key pairs <i.e., the old owner/key pair is deprecated for the NFT, and the new owner has a different key pair>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hu with the teachings of Eby, further comprising: determining that a public decentralized identifier (DID) of the NFT is deprecated due to a transfer of the NFT to a new owner having a different public and private key pair, to ensure former owners cannot continue to exert control over the NFT/VCs (see, e.g., Eby at [0050-053], [0018], and [0022]).
Claim(s) 30 and 32 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hu in view of Pajek et al. (US20250279889; Hereinafter “Pajek”).
Regarding claim 30, Hu teaches the method of claim 5, as well as wherein the verifiable credential is verified based on the cryptocurrency address holding the NFT (see, e.g., Hu at [0162-164] – the verification is performed by querying the current NFT holder information in the NFT contract and comparing the blockchain address corresponding to the self-signing user’s DID information with the blockchain address corresponding to the asset holder/current NFT holder). Yet, Hu appears to fail to specifically disclose wherein: the verifiable credential presentation is verified when the cryptocurrency address holding the NFT is derived from the public key by applying a specific hash function to the public key to generate a string and selecting a predetermined number of bytes from the string.
However, Pajek teaches a similar system comprising generating using a public address for verification (see, e.g., [0116-118], [0120], and [0080-082], wherein: the credential is verified when the cryptocurrency address is derived from the public key by applying a specific hash function to the public key to generate a string and selecting a predetermined number of bytes from the string ([0116-118], [0120], and [0080-082] – a public key is hashed using Keccak-256 <i.e., a specific hash function> to generate a 256-bit/32 byte hash value, and the latter 20 bytes are extracted from the 32 byte hash value as a public key address. The public key address is subsequently used in verification. The generated public key address is searched for in the identification code, and the request with a signature is validated using the public key).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hu with the teachings of Pajek, wherein: the verifiable credential presentation is verified when the cryptocurrency address holding the NFT is derived from the public key by applying a specific hash function to the public key to generate a string and selecting a predetermined number of bytes from the string, to ensure accurate verification without storing/sharing the full public key on the network/reducing storage burden (see, e.g., Hu at [0162-164]; with Pajek at [0116-118], [0120], and [0080-082]).
Regarding claim 32, Hu teaches the apparatus of claim 12, wherein: the processor is configured to verify the verifiable credential presentation based on the cryptocurrency address holding the NFT (see, e.g., Hu at [0162-164] – the verification is performed by querying the current NFT holder information in the NFT contract and comparing the blockchain address corresponding to the self-signing user’s DID information with the blockchain address corresponding to the asset holder/current NFT holder). Yet, Hu appears to fail to specifically disclose wherein: the processor is configured to verify the verifiable credential presentation when the cryptocurrency address holding the NFT is derived from the public key by applying a specific hash function to the public key to generate a string and selecting a predetermined number of bytes from the string.
However, Pajek teaches a similar system comprising generating using a public address for verification (see, e.g., [0116-118], [0120], and [0080-082], wherein: the credential is verified when the cryptocurrency address is derived from the public key by applying a specific hash function to the public key to generate a string and selecting a predetermined number of bytes from the string ([0116-118], [0120], and [0080-082] – a public key is hashed using Keccak-256 <i.e., a specific hash function> to generate a 256-bit/32 byte hash value, and the latter 20 bytes are extracted from the 32 byte hash value as a public key address. The public key address is subsequently used in verification. The generated public key address is searched for in the identification code, and the request with a signature is validated using the public key).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hu with the teachings of Pajek, wherein: the processor is configured to verify the verifiable credential presentation when the cryptocurrency address holding the NFT is derived from the public key by applying a specific hash function to the public key to generate a string and selecting a predetermined number of bytes from the string, to ensure accurate verification without storing/sharing the full public key on the network/reducing storage burden (see, e.g., Hu at [0162-164]; with Pajek at [0116-118], [0120], and [0080-082]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Suk (US20230145439) teaches a system for providing real asset authentication via DIDs and NFTs, wherein verifiable credentials are used for authentication (see, e.g., Suk at abstract, ([0070-071]). Hernandez et al. (NPL: “SSI Essentials: What are Decentralized Identifiers (DIDs) & Verifiable Credentials (VSs)?”, November 14, 2021) teaches using verifiable credentials, decentralized identifiers, and verifiable presentations to verify claims (see, e.g., Hernandez at pgs. 5-8). Brunner et al. (NPL: “DID and VC: Untangling Decentralized Identifiers and Verifiable Credentials for the Web of Trust”; March 2021) teaches a standard for the generation and verification of verifiable credentials, as well as verifiable credential usage with decentralized identifiers (see, e.g., Brunner at abstract, pgs. 62-63).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSHUA RAYMOND WHITE whose telephone number is (571)272-4365. The examiner can normally be reached Monday-Thursday, & Alternate Fridays.
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, Taghi Arani can be reached at 5712723787. 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.
/J.R.W./Examiner, Art Unit 2438 /TAGHI T ARANI/Supervisory Patent Examiner, Art Unit 2438
Prosecution Insights