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 .
DETAILED CORRESPONDENCE
Acknowledgements
The Amendment of claims 1, 8 and 15, filed on 12/05/2025 is acknowledged.
Claims 1-6 and 8-21 are pending, no new claim(s) added and, therefore,
Claims 1-6 and 8-21 are hereby examined.
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 12/05/2025 has been entered.
Examiner’s Response to Amendment/Remarks
35 USC § 103
Applicant’s amendment to claims 1, 8 and 15, filed on 12/05/2025 is hereby acknowledged and the Applicant’s argument and remarks are considered and found not persuasive by the Examiner. Applicant is of the opinion on page 12 of the response filed on 05/27/2025, that […For example, claim 1 as amended now recites in part:
the custodian service maintains an asset record that records ownership of the asset and facilitates the custodian service transferring recorded ownership of the asset from a first party to a second party without paying network transaction fees, (emphasis added). Applicant respectfully submits that this language is not present in Guar nor Toth. Applicant notes that this amendment specifically recites "without paying network transaction fees" and that if the US Patent Office wishes to reject this disclosure under 35 U.S.C. § 103, it must affirmatively provide evidence of "without paying network transmission fees." See MPEP § 2144.03 (A). The MPEP states that it is "never appropriate to rely solely on "common knowledge" in the art without evidentiary support in the record." Id. Applicant further submits it would be improper for any future rejection of this language to cite a reference that does not mention "network transaction fees" and allege that the reference in fact teaches "without paying network transaction fees." A reference could mention a chair without explicitly referring to the chair's legs, but this is not evidence that the chair lacks legs. In the same way, a reference to the blockchain that does not explicitly describe "network transaction fees" is not evidence that the reference teaches "without paying network transaction fees." Accordingly, Applicant respectfully requests that the rejection of claim 1 be withdrawn].
Examiner respectfully disagrees with this assertion of the need for prior art to teach verbatim the language "without network transaction fees". However, to further buttress Gaur’s teachings as disclosed already and in addition below, ¶¶ 0053, 0078 of Gaur disclose that […Unlike the proof-of-work, where the algorithm rewards miners who solve mathematical problems, with the proof of stake, a creator of a new block is chosen in a deterministic way, depending on its wealth, also defined as "stake." Then, a similar proof is performed by the selected/chosen node], clearly this stipulation shows that Gaur’s transactions are without network transaction fees. And in combination of ¶ 0082, teaches this newly added limitation of “the custodian service maintains an asset record that records ownership of the asset and facilitates the custodian service transferring recorded ownership of the asset from a first party to a second party without paying network transaction fees”.
Furthermore, on page 13 of the response, Applicant asserts [Applicant respectfully submits that neither Guar nor Toth discloses "provide a proof of authenticity of the verifiable credential to the custodian service or the verifier service in response to the request for proof of ownership of the digital asset," as recited in claim 1. Applicant has previously raised this concern, and the previous Non- final Office Action responded as follows… that even if the "permission key" of Guar did indicate "the custodian ... is rightfully in possession of the digital asset," Applicant notes that this is entirely separate from "a proof of authenticity... in response to the request for proof of ownership].
Examiner asserts that this statement has been addressed correctly in the previous Office Action as Gaur teaches these elements as previously disclosed.
Therefore, the 103 rejection is hereby maintained.
Claim Objections
Claim 1 is objected to because the adjective “digital” appears to be missing from the phrase “ownership of the asset” in lines 15–16 and 16–17. It appears this phrase should be “ownership of the --digital-- asset” to be consistent with the rest of the claim.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 3
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.
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.
Claims 1-6, 8-10 and 14-17 are rejected under 35 U.S.C. 103 as being unpatentable over Gaur et al., (US 20230085691 A1) in view Toth et al., (US 20190097812 A1).
With respect to claim 1, Gaur teaches a method and a system, comprising a computing device comprising a processor and a memory; and machine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to at least:
receive from a custodian service a verifiable credential, wherein: the verifiable credential represents proof of ownership of a digital asset {see at least ¶¶ 0003-0004, 0040 “The ownership key asserts the right of the owner of the digital asset. The ownership key may be a private key that is kept in possession of the asset owner with a trifocal wrapper, and not exposed…”, and also ¶ 0040 “The ownership key asserts the right of the owner of the digital asset. The ownership key may be a private key that is kept in possession of the asset owner with a trifocal wrapper, and not exposed…”, and also ¶¶ 0041, 0050-0053, 0056“…the wrapper may be part of the process performed by the key generation module 170. The wrapping may be undone by the ownership key 111. In other words, the ownership key 111 may be used to verify that a signature created with the permission key 112 (even when the permission key 112 is wrapped) is a valid signature (i.e., created by a key that is derived from the master seed). Likewise, the ownership key 111 may be used to verify that a signature created with the consent key 113 (even when the consent key 113 is wrapped) is a valid signature”}.
the custodian service maintains an asset record that records ownership of the asset and facilitates the custodian service transferring recorded ownership of the asset from a first party to a second party without paying network transaction fees {see at least ¶¶ 0053, 0078 “Before blocks can be added to the blockchain, the blocks must be validated. Validation for the permissionless blockchain 352 may include a proof-of-work (PoW) which is a solution to a puzzle derived from the block's header. Although not shown in the example of FIG. 3C, another process for validating a block is proof-of-stake. Unlike the proof-of-work, where the algorithm rewards miners who solve mathematical problems, with the proof of stake, a creator of a new block is chosen in a deterministic way, depending on its wealth, also defined as "stake." Then, a similar proof is performed by the selected/chosen node”, ¶ 0082 “ When the custodian 420 desires to transfer the digital asset to the actor 430 in accordance with goals set forth by the asset owner 410, the custodian 420 may generate a blockchain transaction 442 which identifies the digital asset, the custodian 420, the asset owner 410, the actor 430, a timestamp, a chaincode, etc. and sign the blockchain transaction 442 with the permission key 412. The blockchain transaction 442 can be stored within a data block on a blockchain ledger 440. The blockchain transaction 442 may also be performed concurrently or simultaneously with a process of transferring the custody of the digital asset from the custodian 420 to the actor 430, for example, transferring from custodial wallet to actor wallet, etc.,”}.
store the verifiable credential in the memory of the computing device {see at least ¶ 0041 “…the permission key and the consent key may be “wrapped” or otherwise encrypted based on the ownership key. The asset owner may keep the ownership key without divulging it to others. The ownership key may then be used to unwrap or open transactions involving the digital asset that are stored on a blockchain ledger. In particular, the asset owner can verify that the permission key and the consent key used in the transaction are valid, based on the ownership key since all three keys are created from the same master seed”, and also ¶¶ 0042, 0072 “…To include credentials from a traditional data source 312 in chaincode, the developer 310 could use an out-of-band connection to access the data. In this example, the blockchain user 302 connects to the permissioned blockchain 304 through a peer node 314…”, and ¶ 0110}.
publish an ownership claim of the digital asset to an identity ledger, the ownership claim being based at least in part on the verifiable credential { see at least ¶¶ 0052-0053, 0145 “The collected data may be stored in the blockchain 810 based on a consensus mechanism. The consensus mechanism pulls in (permissioned nodes) to ensure that the data being recorded is verified and accurate. The data recorded is time-stamped, cryptographically signed, and immutable. It is therefore auditable, transparent, and secure. Adding IoT devices which write directly to the blockchain can, in certain cases (i.e., supply chain, healthcare, logistics, etc.), increase both the frequency and accuracy of the data being recorded”}.
receive a request for proof of ownership of the digital asset from the custodian service or a verifier service { see at least ¶¶ 0003-0004, 0050-0051 “…Here, the asset owner 102 may retain possession of the ownership key 111, while providing the permission key 112 to the custodian 120. The permission key 112 is proof that the custodian 120 is rightfully in possession of the digital asset 104 on behalf of the asset owner 102…” with this disclosure it is clear that the permission key which is derived from the private key gets to the custodian as a proof of ownership of the digital asset, {and also ¶¶ 0042-0049, 0081, 0089-0091}, and
provide a proof of authenticity of the verifiable credential to the custodian service or the verifier service in response to the request for proof of ownership of the digital asset {see at least ¶ 0004 “…blockchain transaction comprising an identifier of the digital asset on a blockchain ledger, an identifier of the custodial service, and an identifier of a recipient of the digital asset, signing the blockchain transaction with a key from a trifocal key which proves that the custodial service is authorized to transact with the digital asset on behalf of the user, and storing the signed blockchain transaction on a blockchain ledger”, and also ¶ 0040 “The ownership key asserts the right of the owner of the digital asset. The ownership key may be a private key that is kept in possession of the asset owner with a trifocal wrapper, and not exposed…”, and also ¶¶ 0050-0051 “…Here, the asset owner 102 may retain possession of the ownership key 111, while providing the permission key 112 to the custodian 120. The permission key 112 is proof that the custodian 120 is rightfully in possession of the digital asset 104 on behalf of the asset owner 102…” with this disclosure it is clear that the permission key which is derived from the private key gets to the custodian as a proof of ownership of the digital asset, also ¶¶ 0052-0053, 0056 “…the wrapper may be part of the process performed by the key generation module 170. The wrapping may be undone by the ownership key 111. In other words, the ownership key 111 may be used to verify that a signature created with the permission key 112 (even when the permission key 112 is wrapped) is a valid signature (i.e., created by a key that is derived from the master seed). Likewise, the ownership key 111 may be used to verify that a signature created with the consent key 113 (even when the consent key 113 is wrapped) is a valid signature…”, ¶ 0089 “392 collaborating users can establish persistent secure sessions by exchanging e-credentials and using the encryption key pairs associated with their e-credentials”, ¶ 0090 “392 an issuer 302 attests to the identity of a requester 301 wherein the issuer cannot repudiate having proofed the requester's identity”, ¶ 0091 “394 users can use e-credentials proofed and attested to by other parties to establish secure sessions user 301”}.
Gaur does not explicitly disclose
the proof of ownership includes at least one cryptographic signature generated using a private key of a public-private key pair associated with at least one third-party individual or at least one third-party entity who has certified or verified an identity associated with the verifiable credential; and
However, Toth discloses “the proof of ownership including at least one cryptographic signature generated using a private key of a public-private key pair associated with at least one third-party individual or at least one third-party entity who has certified or verified an identity associated with the verifiable credential” in {see at least ¶ 0412 “FIG . 8 is a usage scenario diagram illustrating the issuing of an original electronic credential, for example , an electronic driver's license or banking card embedded in the user's personal identity device”, ¶¶ 0470-0471 “Every e-credential 401 issued also specifies a digital seal image 423 and is associated with three (3) public-private key pairs 416 where public keys 417 are embedded into e-credential 401, and where the paired private keys 418 are in protected memory store 213 of the owner's personal identity engine 202, said public-private key pairs including a signing-verification key pair used to create and verify digital signatures applied to documents and messages 442…”, and also ¶¶ 0473-0485, 0443 “Cryptographic operations, associated with the encryption keys of a selected e-credential 220 of an owner provided to other parties, are bound to device owner 201 as follows (see legend 275):”, ¶ 0444 (a) Digital signing key s, a private key in 213 associated with e-credential 220 of the owner, can be used by identity engine 204 of owner 201 to calculate, by means of a prior art encryption algorithm, a digital signature over a message, document or e-credential…”, ¶ 0445 “(b) Cryptographic operations, associated with the encryption keys of a selected e-credential 220 of an owner provided to other parties, are bound to device owner 201 as follows (see legend 275):”}.
Therefore, it would have been obvious for a person of ordinary skill in the art at the time the application is filed, to apply the digital asset ownership identity verification as disclosed in Troth within the verification of Gaur in order to have an option of protecting actual owner’s private/public key information with expiry hold time. This will provide a protected and secured owner’s data in an NFT transaction with Gaur’s ownership authentication process.
With respect to claims 8 and 15, Gaur teaches, receiving a request to claim ownership of a digital asset in an asset ledger, the request including an identifier of the digital asset and an identifier of an owner of the digital asset { see at least ¶ 0003 “…via a custodial service, a request to transact with a digital asset owned by a user and temporarily in custody of the custodial service, generating a blockchain transaction comprising an identifier of the digital asset on a blockchain ledger, an identifier of the custodial service, and an identifier of a recipient of the digital asset”, and also ¶¶ 0004, 0040-0042}.
updating an owner identifier for the digital asset in the asset ledger, without paying network transaction fees, to include a public key of an asset custodian, the updating occurring at least in part due to the digital asset being at least provided at least the public key of the asset custodian and the public key of the asset custodian indicating that the asset custodian is the owner of the digital asset {see at least ¶¶ 0050-0053, 0055-0056 “…In the example embodiments, the decision to custody a digital asset with a third party can trigger a process that creates the trifocal key 110. In this example, the individual keys, for example, the permission key 112 and the consent key 113 may be “wrapped” prior to be delivered to the custodian 120 and the actor 130, thereby preventing these keys from being exposed…”}.
providing a verifiable credential to an identity wallet, the verifiable credential being linked to the digital asset in the asset ledger and the verifiable credential including […] {see at least ¶¶ 0004, 0050-0053, 0070 “…As the transaction moves through the different steps of FIG. 2B, each of the client node 260 and the blockchain peers 281-284 may attach their respective VC to a step that they have performed. In this example, each of the blockchain peers 281-284 may include a set of VCs (e.g., one or more VCs) that provide identity and membership information associated with the blockchain peers 281-284. For example, the client node 260 may include a verifiable certificate with a claim issued by an MSP of the blockchain network that identifies the client as a member for transacting on the blockchain. As another example, the blockchain peers 281-283 may include VCs that identify the blockchain peers 281-283 as endorsing peers of the blockchain. Meanwhile, the blockchain peer 284 may include a VC that identifies the blockchain peer 284 as an ordering node of the blockchain…”},
publishing an ownership claim associated with a user in an identity ledger, wherein the ownership claim is based at least in part on the verifiable credential provided to the identity wallet { see at least ¶¶ 0052-0053, 0145 “The collected data may be stored in the blockchain 810 based on a consensus mechanism. The consensus mechanism pulls in (permissioned nodes) to ensure that the data being recorded is verified and accurate. The data recorded is time-stamped, cryptographically signed, and immutable. It is therefore auditable, transparent, and secure. Adding IoT devices which write directly to the blockchain can, in certain cases (i.e., supply chain, healthcare, logistics, etc.), increase both the frequency and accuracy of the data being recorded”};
creating an asset record that stores the owner identifier in association with an asset identifier for the digital asset, the owner identifier representing the user of the identity wallet, and {see at least ¶¶ 0050-0052 “…when the asset owner 102 transfers the permission key 112 to the custodian 120, the transfer may be performed via the blockchain ledger 140. Here, a blockchain transaction 142 may be recorded on the blockchain ledger 140 that reflects this transfer. The blockchain transaction 142 may identify the digital asset 104 (e.g., by serial number, name, etc.), the custodian 120, the asset owner 102…”, and also ¶ 0053}.
storing the asset record on an off-chain data store accessible by the asset custodian {see at least Fig 3A “Data source 312”, claim 6 “…wherein the processor is further configured to store the digital asset of the user via a crypto storage of the custodial service”, and also ¶ 0072 “…The blockchain developer 310 can deploy chaincode directly to the network through an interface. To include credentials from a traditional data source 312 in chaincode, the developer 310 could use an out-of-band connection to access the data… a user attempting to utilize chaincode may be required to verify their credentials on the traditional data source 312. To confirm the user's authorization, chaincode can use an out-of-band connection to this data through a traditional processing platform 318”}.
Gaur does not explicitly disclose “…the verifiable credential comprising a timestamp of when the verifiable credential will expire …”
“…the proof of ownership including at least one cryptographic signature generated using a private key of a public-private key pair associated with at least one third-party individual or at least one third-party entity who has certified or verified an identity associated with the verifiable credential”
However, Toth discloses “…the proof of ownership including at least one cryptographic signature generated using a private key of a public-private key pair associated with at least one third-party individual or at least one third-party entity who has certified or verified an identity associated with the verifiable credential” in {see at least ¶¶ 00470-0471 “Every e-credential 401 issued also specifies a digital seal image 423 and is associated with three (3) public-private key pairs 416 where public keys 417 are embedded into e-credential 401, and where the paired private keys 418 are in protected memory store 213 of the owner's personal identity engine 202, said public-private key pairs including a signing-verification key pair used to create and verify digital signatures applied to documents and messages 442…”, and also ¶¶ 0473-0485, 0443 “Cryptographic operations, associated with the encryption keys of a selected e-credential 220 of an owner provided to other parties, are bound to device owner 201 as follows (see legend 275):”, ¶ 0444 (a) Digital signing key s, a private key in 213 associated with e-credential 220 of the owner, can be used by identity engine 204 of owner 201 to calculate, by means of a prior art encryption algorithm, a digital signature over a message, document or e-credential…”, ¶ 0445 “(b) Cryptographic operations, associated with the encryption keys of a selected e-credential 220 of an owner provided to other parties, are bound to device owner 201 as follows (see legend 275):”}.
Therefore, it would have been obvious for a person of ordinary skill in the art at the time the application is filed, to apply the digital asset ownership identity verification as disclosed in Troth within the verification of Gaur in order to have an option of protecting actual owner’s private/public key information with expiry hold time. This will provide a protected and secured owner’s data in an NFT transaction with Gaur’s ownership authentication process.
With respect to claim 2, the combination of Gaur in view of Troth teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Gaur discloses wherein the machine-readable instructions further cause the computing device to at least send an instruction to the custodian service to transfer ownership of the digital asset to another owner, the instruction specifying an owner identifier of the other owner {see at least ¶¶ 0004, 0052-0053}.
With respect to claim 3, the combination of Gaur in view of Troth teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Troth discloses wherein the proof of the verifiable credential comprises a cryptographic signature of the verifiable credential generated by the custodian service see for Example Fig. 2 and “the legend 275 for public-private encryption keys” and ¶¶ 0471, 0473-0485, 0443 “Cryptographic operations, associated with the encryption keys of a selected e-credential 220 of an owner provided to other parties, are bound to device owner 201 as follows (see legend 275):”, ¶ 0444 (a) Digital signing key s, a private key in 213 associated with e-credential 220 of the owner, can be used by identity engine 204 of owner 201 to calculate, by means of a prior art encryption algorithm, a digital signature over a message, document or e-credential…”, ¶ 0445 “(b) Cryptographic operations, associated with the encryption keys of a selected e-credential 220 of an owner provided to other parties, are bound to device owner 201 as follows (see legend 275):”}.
With respect to claim 4, the combination of Gaur in view of Troth teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Gaur discloses wherein the proof of the verifiable credential
comprises a token issued by the custodian service and a cryptographic signature of the token, the cryptographic signature having been generated by the custodian service {see at least ¶¶ 0054-0056, 0145}.
With respect to claim 5, the combination of Gaur in view of Troth teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Gaur discloses wherein the machine-readable instructions further cause the computing device to at least:
create the ownership claim in response to receipt of the verifiable credential, the ownership claim including a unique identifier for the digital asset and an identifier of a true owner of the digital asset {see at least ¶¶ 0042-0049}, and
With respect to claim 6, the combination of Gaur in view of Troth teaches all the subject matter as disclosed in claim 5 above.
Furthermore, Gaur discloses wherein the identifier of the true owner of the digital asset is a decentralized identifier associated with the true owner, the decentralized identifier containing a public key associated with the true owner {see at least ¶¶ 0054-0056}.
With respect to claim 14, the combination of Gaur in view of Troth teaches all the subject matter as disclosed in claim 8 above.
Furthermore, Gaur discloses wherein the digital asset is a non-fungible token (NFT) {see at least ¶ 0050}.
With respect to claims 9 and 16, the combination of Gaur in view of Troth teaches all the subject matter as disclosed in claim 8 and 15 above, respectfully.
Furthermore, Gaur discloses, further comprising: signing the verifiable credential with a private key of the asset custodian to generate a cryptographic signature {see at least ¶ 0002 “…generate a blockchain transaction comprising an identifier of the digital asset on a blockchain ledger, an identifier of the custodial service, and an identifier of a recipient of the digital asset, sign the blockchain transaction with a key from a trifocal key which proves that the custodial service is authorized to transact with the digital asset on behalf of the user…” and also ¶¶ 0082, 0140}, and
including the cryptographic signature in the verifiable credential { see at least ¶¶ 0082-0083 “…When the actor 430 desires to invest the digital asset in accordance with the goals set forth by the asset owner 410, the actor 430 may generate a blockchain transaction 444 which identifies the digital asset, the asset owner… and sign the blockchain transaction 4424 with the consent key 413… simultaneously with a process of transferring the custody of the digital asset from the actor 430 to the liquidity pool”}.
With respect to claims 10 and 17, the combination of Gaur in view of Troth teaches all the subject matter as disclosed in claim 8 and 15 above, respectfully.
Furthermore, Gaur discloses, further comprising: generating a token {see at least ¶ 0050 “…As a non-limiting example, the digital asset 104 may be a digital token that
represents a digitized asset…”}.
signing the token with a private key of the asset custodian to generate a
cryptographic signature {see at least ¶¶ 0002, 0050, 0082, 0140}, and including the token and the cryptographic signature in the verifiable credential {see at least ¶¶ 0050, 0082-0083}.
With respect to claim 21, the combination of Gaur in view of Troth teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Gaur discloses, wherein the verifiable credential complies with a version of the W3C's standard for verifiable credentials {see at least ¶¶ 0004, 0070 “In the example of FIG. 2B, the client node 260 and each of the blockchain peers 281-284 may use a verifiable credential as a signature. As the transaction moves through the different steps of FIG. 2B, each of the client node 260 and the blockchain peers 281-284 may attach their respective VC to a step that they have performed. In this example, each of the blockchain peers 281-284 may include a set of VCs (e.g., one or more VCs) that provide identity and membership information associated with the blockchain peers 281-284…”}. Examiner’s Note: A verifiable credential (also referred to herein as “VC”) is a set of tamper-proof claims and metadata that cryptographically prove who issued the verifiable credential. One example standard for a verifiable credential is the Global Verifiable Credential Standard (W3C) that includes credential metadata, claims, and proof(s).
Claims 11-13 and 18-20 are rejected under 35 U.S.C. 103 as being
unpatentable over Gaur et al., (US 20230085691 A1) in view Toth et al., (US 20190097812 A1) and further in view of Cox et al., (US 20220383295 A1).
With respect to claims 11 and 18, the combination of Gaur in view of Troth teaches all the subject matter as disclosed in claim 8 and 15 above respectively.
Furthermore, Gaur discloses wherein the owner identifier is a first owner identifier, the verifiable credential is a first verifiable credential, the identity wallet is a first identity wallet, and the method further comprises:
receiving a request to transfer ownership of the digital asset, the request to transfer the digital asset comprising a second owner identifier associated with a new owner of the digital asset {see at least ¶¶ 0004, 0087-0088 “…generating a blockchain transaction comprising an identifier of the digital asset on a blockchain ledger, an identifier of the custodial service, and an identifier of a recipient of the digital asset…”}.
updating the asset record to replace the first owner identifier with the second owner identifier {see at least ¶ 0081 “…Likewise, the asset owner 410 has provided the consent key 413 to an actor 430. In this example, the permission key 412 gives the custodian 420 consent to possess the digital asset, and transfer the digital asset to the actor…”, and also ¶ 0082}.
providing a second verifiable credential to a second identity wallet, the second verifiable credential being linked to the digital asset in the asset ledger {see at least ¶¶ 0004, 0070}.
The combination of Gaur in view of Troth, does not explicitly disclose revoking an ownership claim associated with the first owner identifier.
However, Cox discloses revoking an ownership claim associated with the first
owner identifier {see at least ¶ 0040-0041 “…to transfer the NFT associated with NFT asset 226 to collector container 210d using wired connection device 119. Collector container 210c can then record the ownership transfer on secure public ledger 206, resulting in collector container 210c relinquishing NFT asset 226 and ownership of its associated NFT to whoever possesses collector container 210d (e.g., user 208d) …”, and also ¶ 0042}.
Therefore, it would have been obvious for a person of ordinary skill in the art at the time the application is filed, to modify the digital asset transfer transaction of Gaur in view of the asset ownership identity verification as disclosed in Troth, with the revoking of ownership claim of asset of Cox in order to have an asset transfer ownership securely protected.
With respect to claims 12 and 19, the combination of Gaur and Troth, in view of Cox teaches all the subject matter as disclosed in claim 11 and 18 above, respectfully.
Furthermore, Cox discloses wherein revoking the ownership claim further comprises updating the ownership claim to reflect that it is revoked {see at least ¶¶ 0040-0042}.
Therefore, it would have been obvious for a person of ordinary skill in the art at the time the application is filed, to modify the digital asset transfer transaction of Gaur in view of the asset ownership identity verification as disclosed in Troth, with the revoking of ownership claim of asset of Cox in order to have an asset transfer ownership securely protected.
With respect to claims 13 and 20, the combination of Gaur and Troth, in view of Cox teaches all the subject matter as disclosed in claim 11 and 18 above, respectfully.
Furthermore, Cox discloses wherein revoking the ownership claim further comprises adding the ownership claim to a revocation list { see at least ¶¶ 0040-0042}.
Therefore, it would have been obvious for a person of ordinary skill in the art at the time the application is filed, to modify the digital asset transfer transaction of Gaur in view of the asset ownership identity verification as disclosed in Troth, with the revoking of ownership claim of asset of Cox in order to have an asset transfer ownership securely protected.
Conclusion
The prior art made of record and not relied upon:
1) (US 20230045546 A1) – KIM et al., Method and Apparatus for Managing Non-Fungible Token for Digital Content - relates to a method and apparatus for managing a non-fungible tokens (NFTs), and, more particularly, to enabling centralized generation and transacting of NFTs without the use of blockchains.
2) (US 20230120534 A1) – Jakobsson et al., Methods for Conditional Transaction Tokens, Secure Sharing of Token Assets, Wallet Spam Protection, and User Interfaces for Acceptance of Terms - relates to cryptography. More particularly it relates to immutable ledgers and verification mechanisms associated with cryptographic systems.
3) (US 20030056094 A1) - Huitema et al., Peer-to-peer Name Resolution Protocol (PNRP) Security Infrastructure And Method - relates generally to peer-to-peer protocols, and more particularly to security framework infrastructures for to peer-to-peer protocols. Also teaches expiry checking an expiration date of the ID certificate to determine if the ID certificate is still valid in paragraph 0009 and 0041.
4) (WO 2022001225 A1) - Pan et al., Identity Credential Application Method, Identity Authentication Method, Device, and Apparatus – relates to providing an identity credential application method, and an identity authentication method, a device and an apparatus. Said method comprises: a first device sending a first message to a second device, the first message comprising identity credential application information of the first device.
5) (US 20170330174 A1) - Demarinis et al., Application Framework using Blockchain-Based Asset Ownership - relates to distributed ledger technology (such as blockchain technology), proof of work systems, cryptosystems, and electronic transaction systems.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINCENT IDIAKE whose telephone number is (571)272-1284. The examiner can normally be reached on Mon-Fri from 10:30AM to 7:30PM ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PATRICK MCATEE, can be reached at telephone number (571)272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated-interview-request-air-form
/V.I./Examiner, Art Unit 3698 /PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698