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, 4, 8, 10, 15, 17 and 21, filed on 05/13/2026 is acknowledged.
Claims 1-6 and 8-21 are pending, no claim(s) canceled and, therefore,
Claims 1-6 and 8-21 are hereby examined.
Examiner’s Response to Amendment/Remarks
Claim Objections
The amendment to claim 1 has overcome the objection raised in the previous office action mailed out on 02/13/2026, therefore, the objection is withdrawn.
35 USC § 103
Applicant’s amendment to claims 1, 4, 8, 10, 15, 17 and 21, filed on 05/13/2026 is hereby acknowledged and the Applicant’s argument and remarks as regards that Guar in view of Toth does not teach the limitation “the custodian service maintains an asset record that records ownership of the digital asset and facilitates the custodian service transferring recorded ownership of the digital asset from a first party to a second party without paying network transaction fees;” are considered and found persuasive by the Examiner. Upon further search consideration, Examiner is introducing a new prior, Pratz et al., (US 20200058176 A1) to teach this limitation, in ¶ 0096 “Further, in some example embodiments, the blockchain ledger is a permissioned private blockchain (e.g., Hyperledger Fabric) in which blocks can be generated for each transaction, small batches of transactions, or larger batches of transactions without miner's fees to create said blocks”. Emphasis added by the Examiner.
As this is a new grounds of rejection, therefore, this Office Action is a Non-Final Office Action on the merits, claims 1-6 and 8-21 are currently pending and have been addressed below.
However, as regards the newly added limitations of “the verifiable credential is generated by the custodian service, wherein the custodian service is in possession of the digital asset;
the verifiable credential contains a token signed using a private key associated with an owner of the digital asset, wherein the token corresponds to a proof of authenticity;” Examiner disclose that Gaur still teaches these limitations, as disclosed below.
Therefore, the 103 rejection is hereby maintained
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), and further in view of Pratz et al., (US 20200058176 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 verifiable credential is generated by the custodian service, wherein the
custodian service is in possession of the digital asset (¶ 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. ”, and also ¶ 0050}.
the verifiable credential contains a token signed using a private key associated with an owner of the digital asset, wherein the token corresponds to a proof of authenticity {see at least ¶ 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 {“… 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” ¶¶ 0050-0053, 0056}.
“the custodian service maintains an asset record that records ownership of the digital asset and facilitates the custodian service transferring” […] {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 “…recorded ownership of the digital asset from a first party to a second party without paying network transaction fees”;
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.
The combination of Gaur in view of Toth does not exclusively disclose “…recorded ownership of the digital asset from a first party to a second party without paying network transaction fees”.
However, Pratz discloses “…recorded ownership of the digital asset from a first party to a second party without paying network transaction fees” {see at least ¶ 0096 “…in some example embodiments, the blockchain ledger is a permissioned private blockchain (e.g., Hyperledger Fabric) in which blocks can be generated for each transaction, small batches of transactions, or larger batches of transactions without miner's fees to create said blocks”}.
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 no fees charged for block creation in a blockchain transaction of Pratz, within the verification of Gaur in view of the digital asset ownership identity verification as disclosed in Troth in order to have an option of no transaction fee charged. This will provide a transaction fee free transaction 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, […] 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…”}.
while being in possession of the digital asset, 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 at least a token signed using a private key associated with an owner of the digital asset, wherein the token corresponds to a proof of authenticity {see at least ¶¶ 0003-0004 “receiving, 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, 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 ¶¶ 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”}.
Although Gaur teaches the step of “while being in possession of the digital asset, providing a verifiable credential…” as disclosed above
Additionally, Toth also discloses while being in possession of the digital asset, 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 at least a token signed using a private key associated with an owner of the digital asset, wherein the token corresponds to a proof of authenticity 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.
The combination of Gaur and Toth does not explicitly disclose “…without paying network transaction fees…”
However, Pratz discloses “…without paying network transaction fees…” {see at
least ¶¶ 0096}
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 no fees charged for block creation in a blockchain transaction of Pratz, within the verification of Gaur in view of the digital asset ownership identity verification as disclosed in Troth in order to have an option of no transaction fee charged. This will provide a transaction fee free transaction in an NFT transaction with Gaur’s ownership authentication process.
With respect to claim 2, the combination of Gaur in view of Troth, in view of Pratz, 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, in view of Pratz, 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, in view of Pratz, teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Gaur discloses wherein the proof of the verifiable credential
comprises the 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, in view of Pratz, 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, in view of Pratz, 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, in view of Pratz, 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, in view of Pratz, 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, in view of Pratz, teaches all the subject matter as disclosed in claim 8 and 15 above, respectfully.
Furthermore, Gaur discloses, further comprising:
signing the token with a private key of the asset custodian to generate a
cryptographic signature {see at least ¶¶ 0002, 0050, 0082, 0140} including the cryptographic signature in the verifiable credential {see at least ¶¶ 0050, 0082-0083, 0145}.
With respect to claim 21, the combination of Gaur in view of Troth, in view of Pratz, 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 in view of Pratz et al., (US 20200058176 A1), 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, in view of Pratz, 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, in view of Pratz, 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, and in view of without paying transaction fees of Pratz, 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 in view Troth, in view of Pratz, and 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, and in view of without paying transaction fees of Pratz, 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, and in view of without paying transaction fees of Pratz, 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.
6) (US 20190287100 A1) – Song et al., Method for Managing Token Based on Heterogeneous Blockchain Networks, and Token Management Server Using the Same - relates to a method for managing tokens based on heterogeneous blockchain networks; and more particularly, to the method for managing the tokens of an exchange between cryptocurrencies based on the heterogeneous blockchain networks, and the token management server using the same.
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
Prosecution Insights