Creating and maintaining digital tokens on the blockchain using physical device identifiers.

Abstract

Some aspects of the disclosure provide techniques for generating a digital token associated with an asset on a blockchain. An exemplary method generally includes receiving a request to create a digital token corresponding to an asset. A first private key is received. The first private key may be associated with a wallet in which the digital token is to be stored. A second private key is received from a physical device associated with an owner of the asset. An address of the asset is encrypted with a public key associated with the second private key. Metadata associated with the digital token is encrypted with a public key associated with the first private key. The digital token is minted on the blockchain based on the encrypted address of the asset and the encrypted metadata.

Description

Technical Field

[0001] Introduction Aspects of the present disclosure relate to digital tokens corresponding to other assets, and more particularly, to the generation and maintenance of digital tokens on a blockchain.

Background Art

[0002] Distributed ledgers, such as blockchains, hash chains, and other ledger systems, generally provide a mechanism for tracking the transaction history associated with physical or digital objects. The distributed ledger may structure the transaction history for an object as a plurality of nodes that are continuously ordered. The original transaction in the distributed ledger that represents the creation of an object may be a node that does not point to other nodes in the distributed ledger as predecessor nodes. Subsequent transactions may be reached by moving a pointer from the node representing the original transaction to the node representing any particular transaction. Using the distributed ledger, transactions may be processed by ensuring that the objects identified in the transaction exist in the distributed ledger (e.g., to verify that the object exists and / or is a valid object for which the transaction can be made), and by ensuring that the participants in the transaction are qualified to carry out the transaction.

[0003] In some cases, these distributed ledgers may be used to maintain a transaction history for digital tokens that may be associated with other (physical or virtual) assets. Generally, transferring ownership of these assets may involve transferring both the underlying asset and the digital tokens associated with that asset. The transfer of digital tokens can generally be achieved by moving the tokens from the current owner's wallet to the new owner's wallet based on the encryption keys associated with the current owner and the new owner. However, when information about the underlying asset associated with the digital tokens is stored in an unencrypted format or encrypted using compromised encryption keys, it may be possible for a malicious or unauthorized user to access and duplicate the underlying asset.

[0004] Therefore, techniques are needed to securely generate and maintain digital tokens on the blockchain. [Overview of the Initiative]

[0005] Several embodiments provide computer implementations for generating digital tokens associated with assets on a blockchain. An exemplary method generally involves receiving a request to create a digital token corresponding to an asset. A first private key is received. This first private key may be associated with a wallet in which the digital token is to be stored. A second private key is received from a physical device associated with the asset owner. The asset address is encrypted with the public key associated with the second private key. Metadata associated with the digital token is encrypted with the public key associated with the first private key. The digital token is minted on the blockchain based on the encrypted asset address and the encrypted metadata.

[0006] Other embodiments provide a processing system configured to carry out the methods described above and the methods described herein; a non-temporary computer-readable medium comprising instructions that, when executed by one or more processors of the processing system, cause the processing system to carry out the methods described above and the methods described herein; a computer program product embodied on a computer-readable storage medium comprising code for carrying out the methods described above and the methods described herein; and a processing system comprising means for carrying out the methods described above and the methods described herein.

[0007] The following description and related drawings detail some exemplary features of one or more embodiments.

[0008] The attached figures illustrate some aspects of one or more embodiments and should therefore not be considered to limit the scope of this disclosure. [Brief explanation of the drawing]

[0009] [Figure 1] This diagram illustrates an exemplary system in which digital tokens corresponding to other assets are generated and maintained based on physical device identifiers. [Figure 2] This figure shows an exemplary pipeline for generating digital tokens based on a physical device identifier. [Figure 3] This diagram illustrates an exemplary operation for generating digital tokens corresponding to other assets based on a physical device identifier. [Figure 4] This diagram illustrates an exemplary pipeline for securely accessing digital tokens corresponding to other assets based on a physical device identifier. [Figure 5] This diagram illustrates an exemplary operation for securely accessing digital tokens corresponding to other assets on a blockchain. [Figure 6] This figure shows an exemplary system in which embodiments of the present disclosure may be implemented. [Modes for carrying out the invention]

[0010] For ease of understanding, the same reference numerals are used to designate identical elements common to the drawings where possible. It is intended that elements and features of one embodiment may be usefully incorporated into other embodiments without further description.

[0011] Digital tokens stored on a blockchain generally enable the maintenance and transfer of ownership of various assets in a traceable manner. These tokens can be non-fungible tokens (NFTs) or unique tokens representing ownership of a specific asset, such as a specific piece of artwork, an event ticket, or specific data, and these tokens may not be divisible into smaller parts or exchanged for other tokens. Because these tokens may not be exchangeable for other tokens, various steps may be taken to prevent the duplication of these tokens. For example, the information within a token may be encrypted using a cryptographic system so that only the token owner can access that token. For example, a public-private-key cryptography system generally allows a digital token to be encrypted using the owner's public key so that only a party with the owner's private key can decrypt the digital token and view its contents.

[0012] However, compromising the owner's private key could allow a malicious or unauthorized user to access the digital token, carry out an unauthorized transfer of the digital token to another user, or generate unauthorized copies of the digital token. For example, if a digital token corresponding to a digital artwork contains information identifying the location of that digital artwork (e.g., a uniform resource locator (URL) or uniform resource identifier (URI)), and that digital token is encrypted using a compromised key, a malicious user could access that underlying digital artwork and effectively forge it. By carrying out an unauthorized transfer of the digital token or forging the underlying asset, the link linking ownership of the digital token to ownership of the underlying asset, whether physical or digital, could be broken. In another example, if a digital token encrypted using a compromised key contains sensitive information, a malicious user could access this sensitive information and use it for unauthorized or malicious purposes.

[0013] Aspects of this disclosure provide techniques for securely generating and maintaining digital tokens. As described in further detail herein, digital tokens may be generated based on data encrypted using multiple encryption keys. One of these encryption keys may be a public key corresponding to a private key associated with the owner of the asset associated with the digital token, and another of these encryption keys may be a public key corresponding to a private key from a physical device associated with the owner of the asset. Different information in a digital token may be encrypted using different keys, and therefore, if one key is compromised, only a portion of the data in the digital token may be compromised, while other data in the token may be protected. For example, if the key used to encrypt metadata in a digital token is compromised, but the key used to encrypt the address where the asset is located is not compromised, it may not be possible for a malicious party to access the underlying asset associated with the digital token, copy that underlying asset, or create a token with a valid reference to the address where that asset is located. By generating digital tokens using multiple keys, aspects of this disclosure can improve the security of digital tokens stored on a blockchain, since multiple keys may be required to compromise a digital token. Criticizing multiple keys can be a computationally inefficient process (for example, a brute-force attack on a 128-bit key can be 2 128 Using multiple keys (which would require 3.4E38 decryption attempts) can increase the computational cost of breaking the encryption used on the data stored in the digital token, and therefore, doing so would, at best, be impossible.

[0014] Exemplary generation and maintenance of digital tokens based on physical device identifiers Figure 1 shows an exemplary computing environment 100 in which digital tokens corresponding to other assets are generated and maintained using a physical device identifier as one of the keys in a set of keys used to encrypt the data within the digital tokens. As shown in the figure, the computing environment 100 includes a token processing system and a network 120.

[0015] The token processing system 110 generally enables the generation, extraction, and transfer of digital tokens, using multiple encryption keys to protect the security of the data stored in the digital tokens. Generally, the token processing system 110 can be any computing device that can generate digital tokens and generate corresponding blocks in a blockchain to prove the creation and / or transfer of digital tokens and the assets associated with the digital tokens, such as servers, compute clusters, desktop computers, laptop computers, mobile computing devices, and edge computing devices. For example, the token processing system 110 may be configured to process transactions on a cryptocurrency network, such as network 120. For example, network 120 could be the Ethereum® network, or another cryptocurrency network where smart contracts can be defined and executed for the generation of unique digital tokens corresponding to ownership or control over associated assets. As shown in the figure, the token processing system 110 includes a token generator 112, a token extractor 114, and a token transferor 116.

[0016] The token generator 112 generally uses keys associated with the asset owner's digital wallet and keys associated with a physical device owned by the asset owner to generate (or "mint") digital tokens corresponding to the underlying asset. The generated (or "minted") tokens may be committed to the asset owner's digital wallet, and a corresponding record may be recorded on the blockchain to prove the creation and initial ownership of the digital tokens and the underlying asset.

[0017] Users can request the generation of digital tokens associated with an asset, whether physical or digital, by providing information about the underlying asset, a first private key, and a second private key. As will be explained in more detail below, the first private key may be associated with a wallet owned by the asset owner, and the second private key may be associated with a physical device owned by the asset owner.

[0018] In some aspects, the assets on which digital tokens should be generated may be digital assets such as digital artwork, digital event tickets, digital audio and / or video files, or sensitive data used to generate public reports (e.g., environmental, social, and governance (ESG) reports). Digital assets may be stored separately from the digital tokens stored on the blockchain (e.g., "off-chain"), and information about the underlying assets may include information identifying the location where the digital assets are stored. For example, these digital assets may be identified by a uniform resource locator (URL), uniform resource identifier (URI), or content identifier in a distributed file system (e.g., an interplanetary file system (IPFS)) where the digital assets are stored.

[0019] In other aspects, the assets for which digital tokens are to be generated can be physical assets. The information used to generate digital tokens that prove ownership of such assets with respect to physical assets can include various digital counterparts to the physical assets, such as pictures of the physical assets, digital files containing identification information of the physical assets, etc. When a digital counterpart exists for a physical asset, the information about the original asset can identify the location where the digital asset is stored, similar to a digital asset. In some aspects, when no digital counterpart exists for a physical asset, the information about the original asset can include information that can be used to access the physical asset, such as a security code, a lock combination, etc.

[0020] Token generator 112 can prompt the user to provide a first secret key for use in encrypting metadata associated with the digital token in response to a request to generate a digital token corresponding to an asset. The first secret key can be a secret key associated with the wallet in which the digital token is to be stored. Token generator 112 can then generate a corresponding first public key using various key generation algorithms, such that data encrypted using the first public key can be decrypted using the first secret key (e.g., the secret key associated with the wallet in which the digital token is to be stored). In some aspects, token generator 112 can generate a unique public key for each digital token generated by token generator 112.

[0021] Token generator 112 can also prompt the user to provide a second secret key for use in encrypting information about the location where the asset corresponding to the digital token is located in response to a request to generate a digital token. Similar to the case of the first secret key, the second secret key can be used with various key generation algorithms to generate a second public key that can be used to encrypt information about the location where the asset corresponding to the digital token is located.

[0022] In some embodiments, the second secret key can be retrieved from a physical device associated with the owner of the asset. To obtain the second secret key, the token generator 112 can provide a prompt for the user to scan or otherwise digitally read or enter a physical identifier from the physical device. The physical identifier can be scanned or read via various data connections between the physical device and a device (e.g., a mobile phone, laptop computer, desktop computer, etc.) used to invoke the token generation process in the token generator 112. For example, the physical identifier can be read via a near field communication (NFC) data connection with the physical device associated with the owner of the asset, read from a radio frequency identification (RFID) module (e.g., an RFID tag) embedded in the physical device, read via a Bluetooth® low energy (BLE) connection with the physical device, or read via some other wired or wireless (e.g., contactless) data connection between the physical device and the device used to invoke the token generation process.

[0023] In some embodiments, the token generator 112 can enable the user to manually enter and / or select a physical identifier associated with the physical device. For example, the token generator 112 can enable the user to input data such as the serial number of the physical device, the identifier of a subscriber identity module (SIM) associated with the physical device (e.g., an integrated circuit card identifier (ICCID) number), the international mobile equipment identity (IMEI) associated with the physical device, the identifier of an RFID module associated with the physical device, etc. However, these are merely examples of various identifiers that can be provided as the physical identifier, and it should be recognized that other unique device identifiers can also or alternatively be provided as the second secret key.

[0024] After the token generator 112 generates a first public key (corresponding to the first private key) and a second public key (corresponding to the second private key), the data to be embedded in the digital token may be encrypted. Metadata describing the digital token may be encrypted using the first public key, and the location of the asset associated with the digital token may be encrypted using the second public key. The metadata describing the digital token may include information defining various attributes that describe the unique character of the digital token and the underlying asset. For example, in a scenario where the digital token corresponds to a playable character in a video game, the metadata describing the digital token may include information about the playable character's appearance, gameplay attributes about the playable character, and an inventory of items the playable character can carry. In another example, in a scenario where the digital token corresponds to a report generated from confidential (e.g., market confidential) information, the metadata describing the digital token may include various data points derived from the confidential information, such as ESG score data derived from the confidential information, or internal equity or debt rating derived from market confidential data. On the other hand, the location where the assets corresponding to the digital tokens reside can be encrypted using a second public key so that, even if the first public key is compromised, a malicious user will effectively be unable to acquire, modify, and / or transfer the underlying assets associated with the digital tokens.

[0025] After encrypting the metadata and the location (or address) of the underlying asset associated with the digital token, the token generator 112 can mint the digital token on the blockchain. A digital token generally includes encrypted metadata and an encrypted address. When minting a digital token, the token generator 112 can create the digital token and, at the same time, invoke a smart contract on the blockchain to generate a record that proves the creation of the digital token on blockchain 122 and the initial ownership of the digital token by the wallet owner, whose private key can be used to decrypt the digital token. When minting a digital token on blockchain 122, the digital token may be stored on blockchain 122, and the underlying asset associated with the digital token may be maintained in a location separate from blockchain 122.

[0026] The token extractor 114 generally allows users to view previously minted digital tokens. To provide the user with a digital token for viewing, the token extractor 114 may request the identifier of the digital token and extract the digital token from the blockchain 124. The extracted digital token may contain an encrypted location where the underlying asset is located and encrypted metadata, which may be encrypted using different keys to provide security between the metadata in the digital token and the location where the underlying asset is stored, as described above.

[0027] To enable a user to view the underlying asset associated with a digital token, the token extractor 114 may request a second private key from the user. (This key may be read via a wired or wireless connection to a physical device associated with the asset owner, as described above, or may be entered manually.) Upon receiving the second private key, the token extractor 114 may decrypt the location of the underlying asset and provide it to the user viewing the digital token. Metadata may also be provided to the viewer in an encrypted form, and the user may decrypt the metadata using the first private key. In general, data contained in or associated with a digital token is transmitted in an encrypted format from the token processing system 110 to a client device (not shown) and can be decrypted locally (on the client device), so that the decrypted data is not at risk of exposure during transit. In some embodiments, the keys required to decrypt the location data and metadata within the digital token may be provided from the client device to the token extractor 114 via various key exchange mechanisms, and the digital token may be decrypted. The decrypted digital token may then be re-encrypted using a different (mutually agreed-upon) set of keys, which may enable the information within the digital token to be kept secure during transit.

[0028] The token transferr 116 generally facilitates the on-chain transfer of digital tokens and underlying assets from the initial owner to the subsequent owner. To transfer digital tokens (and underlying assets), the transferor can access and unlock the digital tokens via the token extractor 114 and initiate the transfer process. The token transferr 116 can then request a set of keys associated with the transferee (e.g., the user to whom ownership of the digital tokens and underlying assets should be transferred) for use in encrypting metadata and location information in the digital tokens. In some embodiments, the requested set of keys may include a public key associated with the wallet to which the digital tokens should be transferred and a public key associated with a physical device owned by the transferee. After receiving the requested set of keys, the token transferr 116 can use the public key associated with the wallet to which the digital tokens should be transferred to encrypt the metadata and use the public key associated with the physical device owned by the transferee to encrypt the location of the underlying assets. Subsequently, the updated token, now readable by someone with the private key of the recipient but unreadable by the previous owner, can persist on blockchain 122 to prove the transfer of ownership.

[0029] In some embodiments, the token transferor 116 may function as an intermediary to coordinate the transfer of digital tokens and underlying assets from the current owner (transferor) to a new owner (destination). In such cases, the token transferor 116 may receive information identifying the transferor and destination and initiate a process to separately obtain appropriate encryption and decryption keys. For example, the token transferor 116 may request a private key from the current owner of the digital token, separately from requesting a public key from the new owner of the digital token. By requesting these keys separately, the token transferor 116 may prevent the new owner of the digital asset from obtaining the current owner's private key, and thus prevent the current owner's other digital tokens from being compromised by the new owner. Furthermore, the current owner of the digital token may not have access to the new owner's public key, which may prevent the current owner of the digital token from creating new tokens using the new owner's public key.

[0030] An exemplary pipeline for generating digital tokens on the blockchain based on physical device identifiers. Figure 2 shows an exemplary pipeline 200 for generating digital tokens on a blockchain according to the embodiments of this disclosure.

[0031] As shown in the diagram, pipeline 200 begins with wallet key entry stage 210. In wallet key entry stage 210, a user creating a digital token corresponding to an asset provides a private key associated with the wallet to which the digital token should be deposited. A token generator (for example, token generator 112 shown in Figure 1) can prompt the user for the private key they may provide, such as by typing the private key or scanning a physical device where the private key is stored. After the token generator receives the private key associated with the wallet to which the digital token should be deposited, the token generator can generate a public key (for example, an encryption key) using various key generation mechanisms that can generate a public key from the private key.

[0032] Pipeline 200 may proceed to Physical Identifier Entry Stage 220. In Physical Identifier Entry Stage 220, the token generator may request a physical identifier of a physical device owned by the owner of the digital token and underlying asset for use in generating the digital token. A public key associated with the physical device may be derived from the physical identifier using various key generation mechanisms, which treat the physical identifier as a private key that can be used to decrypt data encrypted using the public key derived from the physical identifier. The physical identifier may be provided, for example, by reading the identifier from the physical device using a wired or wireless data connection, or by manual entry of the identifier. As described, the identifier may be read from various short-range data connections, such as NFC connections, by reading RFID tags, by BLE connections, etc. In some embodiments, the identifier may be an identifier associated with a SIM (e.g., an ICCID number), a serial number associated with a physical device, etc. Note that the physical identifier may be any kind of globally unique identifier that uniquely identifies the physical device owned by the owner of the asset and digital token.

[0033] In metadata encryption stage 230, the token generator encrypts the metadata carried in the digital token. As described, the metadata may be derived from the private key of the digital wallet, or otherwise encrypted using the public key associated with that private key.

[0034] In asset address encryption stage 240, the location (or address) of the asset corresponding to the digital key is encrypted. As described, the location (or address) may be encrypted using a public key derived from the physical identifier.

[0035] In token ownership allocation stage 250, a record indicating token ownership may be generated.

[0036] Finally, in token minting stage 260, the digital token is minted and persists on the blockchain. The digital token may be minted using encrypted metadata and encrypted address information such that multiple keys are required to decipher the content of the digital token and access the underlying asset corresponding to the digital token. In token minting stage 260, the digital token may be minted by invoking one or more smart contracts that cause a record to be generated on the blockchain (e.g., blockchain 122 shown in Figure 1) that proves the creation of the digital token and the initial allocation of ownership of the digital token to the owner who provided that wallet private key in wallet key entry stage 210. The digital token minted on blockchain 122 and stored on blockchain 122 may then be retrieved and transferred using the private key associated with the owner's wallet and the physical identifier of the owner's physical device, as described above.

[0037] Figure 3 shows an exemplary operation 300 for generating a digital token corresponding to another physical or digital asset based on a physical device identifier, according to an aspect of this disclosure. The operation described herein may be performed, for example, by the token generator 112 shown in Figure 1.

[0038] As illustrated, operation 300 may begin in block 310, when a request to create a digital token corresponding to an asset is received (for example, in a token generator, such as the token generator 112 shown in Figure 1). Generally, a request to create a digital asset may include information identifying the location where the corresponding asset is stored, such as a URL or URI for the digital asset, or physical location and access information for a physical asset. The corresponding asset may be a digital asset, such as a document or repository of confidential information, or digital artwork; a digital counterpart to a physical asset, such as a digital certificate associated with a physical asset; or the physical asset itself.

[0039] In block 320, a first private key is received (for example, in a token generator such as token generator 112 shown in Figure 1). Block 320 may correspond to a wallet key entry stage 210 shown in Figure 2. The first private key may be associated with a wallet in which digital tokens are to be stored. The token generator may use various key generation mechanisms to generate a first public key, which may be used to encrypt data, and which can then be decrypted using the first private key.

[0040] In block 330, a second private key is received (for example, in a token generator such as the token generator 112 shown in Figure 1). Block 330 may correspond to the physical identifier entry stage 220 shown in Figure 2. The second private key may be received from a physical device associated with the asset owner.

[0041] In some embodiments, the second secret key may be received by scanning, or otherwise reading, data from a physical device associated with the asset owner via a wired or wireless connection. The wireless connection through which the second secret key may be received may include, for example, an NFC connection, a connection generated by an RFID tag, or a BLE connection. Alternatively, the second secret key may be manually entered into a data entry form and provided to the token generator.

[0042] A secret key may contain various physical identifiers associated with a physical device. For example, physical identifiers may include identifiers for an NFC chip on a physical device, identifiers for an RFID tag on a physical device, etc. In another example, physical identifiers may be various identifiers associated with a mobile device (e.g., a cellular phone) through which a digital token is created. These identifiers may include the serial number of the physical device, the ICCID number, or other identifiers of a SIM card attached to the physical device, the IMEI associated with the physical device, or other globally unique identifiers.

[0043] In block 340, the asset address is encrypted with a public key associated with a second private key (for example, in a token generator such as the token generator 112 shown in Figure 1). Block 340 may correspond to the asset address encryption stage 240 shown in Figure 2.

[0044] In block 350, metadata associated with the digital token is encrypted with the public key associated with the first private key (for example, in a token generator such as the token generator 112 shown in Figure 1). Block 350 may correspond to the metadata encryption stage 230 shown in Figure 2.

[0045] In block 360, the digital token is minted on the blockchain. The digital token may be minted based on the encrypted address of the asset and encrypted metadata. In some examples, if the digital token conforms to the Ethereum Comment Request 1155 (ERC-1155) standard, the encrypted address of the asset may be stored in the tokenURI field, and the encrypted metadata may be stored in various metadata fields within the digital token.

[0046] In some forms, digital tokens can be NFTs that have ownership records maintained on a blockchain. In such cases, a digital token may represent a specific asset and may not be interchangeable with other digital tokens representing other assets.

[0047] In some cases, after a digital token is minted on the blockchain, it may be committed to a wallet. When a digital token is committed to a wallet, a reference to the digital token may be written to the wallet. A reference to a digital token may identify a location on the blockchain (or in some other storage network) where the digital token may reside, and the wallet owner may use this information to access the digital token, view metadata stored in the digital token, access the location of assets associated with the digital token, and so on.

[0048] As explained, the encrypted address of an asset and the encrypted metadata are encrypted using different keys, so compromising one key may not allow a malicious user to obtain a usable version of the digital token and the underlying asset associated with it. Furthermore, because different keys are used to separately encrypt the data stored in the digital token, an additional computational complexity may be introduced to any attempt to decrypt the digital token.

[0049] For example, suppose different 128-bit keys are used to encrypt the metadata and the asset address. In such a case, the digital token is 2 128 Decrypting metadata using individual keys, and separately, 2 128 It can be broken by using multiple keys to decrypt the address of the underlying asset. Even if one key is compromised, decrypting the encrypted data using other keys is possible in a brute-force attack. 128 This may require multiple decryption operations, which could make it computationally impossible to solve in a reasonable amount of time.

[0050] In some embodiments, metadata associated with a digital token may include a URI that identifies the location where the digital asset is stored.

[0051] In some embodiments, metadata associated with a digital token may include private data used to generate public data stored in the digital asset.

[0052] In some embodiments, metadata associated with a digital token may include public data generated from private data stored in the digital asset.

[0053] In some embodiments, a request to view a digital asset may be received along with a second private key. The digital token may be retrieved (for example, from the blockchain), and the encrypted address within the digital token may be decrypted using the second private key. The decrypted address of the asset corresponding to the digital token and the encrypted metadata within the digital token may be returned. The encrypted metadata within the digital token may be decryptable using the first private key.

[0054] In some embodiments, a request may be received to transfer a digital token from one wallet to a second wallet. The request may include the public key associated with the second wallet and the public key of a second physical device to be associated with the digital token. Based on the first private key, the second private key, the public key associated with the second wallet, and the public key of the second physical device, ownership of the digital token is transferred to the user associated with the second wallet. To transfer ownership, the digital token may be decrypted using the first and second private keys, and then re-encrypted using the public key associated with the second wallet and the public key of the second physical device. A new record proving the transfer of the digital token to the owner of the second wallet may then be written to the blockchain. Furthermore, since the digital token has been re-encrypted using a new set of keys, the previous owner of the digital token may no longer be able to decrypt and view the metadata in the digital token and the address where the asset associated with that token is located.

[0055] Exemplary secure key exchange for generating and maintaining digital tokens based on physical device identifiers As described above, the creation and transfer of digital tokens associated with other assets may involve the use of multiple cryptographic keys to commit these digital tokens to the blockchain, access these digital tokens, and transfer ownership of these digital tokens. Various key exchange mechanisms may be used to encrypt the digital tokens and protect the keys used to verify that users have permission to access these digital tokens, in order to enforce security over the digital tokens and prevent, or at least mitigate, the unauthorized creation or duplication of the digital tokens.

[0056] Cryptographic keys generally differ in structure depending on whether they are used in symmetric or asymmetric encryption. In symmetric encryption, the same key is used to encrypt and decrypt data. In contrast, in asymmetric encryption, there are two keys: a private key and a public key. Encryption can generally be performed using the public key, and decryption can be performed using the private key. Since the public key is generally known, any party can encrypt data, but only the holder of the corresponding private key can decrypt data encrypted using the public key. Because cryptographic keys enable access to encrypted data, these keys are generally exchanged in a way that prevents a third party from performing a "man-in-the-middle" attack to capture them.

[0057] Aspects of this disclosure provide techniques for securely exchanging keys used in generating, encrypting, and decrypting digital tokens associated with other assets. Multiple keys may be used to protect digital tokens committed on the blockchain, such as proof of ownership (or at least possession) of two or more keys, in order to decrypt an encrypted version of a digital token (or any other digital counterpart to any other asset) and access that version. Furthermore, one or more keys may be stored on tamper-resistant or tamper-proof physical tags (e.g., tamper-proof RFID tags) to further guarantee the authenticity and security of both the digital tokens and the other assets associated with these physical tokens.

[0058] In one example where a pair of cryptographic key sets is used to secure a digital token, the first key set in the pair may be the key used in an asymmetric encryption scheme, and the second key set in the pair may be the key used in a symmetric encryption scheme (and vice versa). To secure a digital token associated with some other asset, a first encrypted payload may be stored in memory on a physical tag attached to or integrated with the other asset. This first encrypted payload may contain, for example, a unique identifier of the other asset (e.g., an RFID tag identifier or another physical device or asset identifier) ​​and may be secured using the first encryption key and information relating to the current owner of the other asset (e.g., a private key associated with the wallet in which the digital token corresponding to the other asset is stored). A second related payload may be stored on-chain to prove ownership of the digital token and the asset associated with the digital token. To protect the digital token, the second payload may be encrypted using a second set of cryptographic keys. In some embodiments, the second payload may be encrypted using the public key component of the second cryptographic key set such that only the holder of the private key component of the second cryptographic key set can decrypt and access the digital token.

[0059] Figure 4 shows an exemplary pipeline 400 for securely generating digital tokens corresponding to other assets based on physical device identifiers, and for securely accessing those digital tokens.

[0060] As shown in the figure, the pipeline 400 includes physical objects 410, client devices 420, and a blockchain 122, all of which are connected to each other in a communicative manner. The physical object 410 may be an object having associated digital tokens, and records of those digital tokens are stored on the blockchain 122. The physical object 410 may be, for example, a collectible object, a physical document, an electronic data storage device, or another object that exists and is maintained on the blockchain, in which confidential data is stored.

[0061] To create a digital token, the use of a specific encryption key may be verified between the physical object 410 and the client device 420 via the tag reader 422. To do so, the physical object 410 may transmit an encrypted payload via the object tag 412 containing known or otherwise verifiable data, such as information identifying the physical object 410 (e.g., a serial number or other unique identifier for the physical object 410 or the object tag 412). The tag reader 422 may receive (or read) this encrypted payload and attempt to decrypt it using one or more keys. If the encrypted payload is successfully decrypted using the encryption key (e.g., the payload matches some known or otherwise verifiable data), the client device 420 may encrypt the payload using that encryption key for storage on the physical object 410. In some embodiments, the encrypted payload stored on the physical object 410 may include a private key associated with the owner or user of the client device 420 (which may be the private key component of a public-private key pair used in an asymmetric encryption scheme) and an identifier associated with the physical object 410.

[0062] The client device 420 further generates an encrypted payload to be committed to blockchain 122. The encrypted payload may include, for example, a digital token (or a locator that enables access to the digital token) and an identifier associated with the physical object 410. To protect the digital token, the encrypted payload and other data committed to blockchain 122 may be encrypted using the public key associated with the wallet in which the digital token should be stored. As described, the corresponding private key should generally be kept secret and accessible only to the wallet owner, so the encrypted payload may generally not be recoverable by any party other than the wallet owner.

[0063] Similar to creating a digital token, the use of a specific encryption key to access a digital token (for example, for a transfer from one owner to a new owner) can be verified between the physical object 410 and the client device 420 via the tag reader 422. The key checker 424 uses the specific encryption key to derive the value of the wallet private key and the identifier of the physical object 410. If the key checker 424 determines that the wallet private key derived from the encryption key provided by the physical object 410 matches a known wallet private key (for example, a private key owned by the user of the client device 420), the key checker 424 can determine that the user of the client device 420 possesses both the key required to verify ownership of the digital token and other assets associated with the digital token, and the key required to decrypt the digital token (for example, by being able to decrypt an encrypted payload from the physical object 410, or by being able to derive the wallet private key from the symmetric key used by the physical object 410 to encrypt the payload).

[0064] The key checker 424 can provide information confirming ownership (or at least possession) of both keys, which is necessary to verify ownership of the digital token and decrypt the digital token to the physical device 410. Based on receiving this verification information, the physical device 410 can provide the client device 410 with its identifier. Generally, as described, the identifier of the physical device may be the serial number of the physical device 410, the identifier of the subscriber identification module (SIM) associated with the physical device 410 (e.g., the integrated circuit card identification (ICCID) number), the International Mobile Equipment Identity (IMEI) associated with the physical device, or the identifier of the RFID module (e.g., the object tag 412) associated with the physical device 410. In some embodiments, the verification information provided to the physical device 410 may be a binary instruction that the client device 420 has ownership (or at least possession) of the appropriate key, an encrypted payload decryptable by the physical device 410, a signed payload verifiable by the physical device 410, or other data that proves ownership (or possession) of the appropriate key involved in securing the digital token on the blockchain 122.

[0065] The token cryptographer / decrypter 426 can retrieve an encrypted payload containing a digital token from blockchain 122. In some embodiments, the encrypted payload may include an encrypted uniform resource indicator (URI) and an encrypted version of the identifier of physical device 410. Using a wallet private key, the token cryptographer / decrypter 426 can attempt to decrypt the encrypted payload. If the data resulting from the attempt to decrypt the encrypted payload resolves to incomprehensible data, the user of client device 420 may not be able to access the digital token stored on blockchain 122. However, if decrypting the encrypted payload resolves to valid data and the decrypted identifier of physical device 410 matches the actual identifier of physical device 410, ownership of physical device 410 and its associated digital token can be verified.

[0066] Subsequently, the user of client device 420 can access the digital token and provide information about the physical device and the digital token to the receiving party. The receiving party can negotiate the keys to be used to verify future ownership of the physical object 410 and the digital token associated with the physical object 410, to generate an encrypted payload, and to commit that payload to the physical object 410 (for example, on object tag 412) and to blockchain 122.

[0067] Although the tag reader 422, the key checker 424, and the token cryptographer / decrypter 426 are shown as separate components, it should be recognized by those skilled in the art that these components may be separate or combined with one or more other components. In some embodiments, the tag reader 422, the key checker 424, and the token cryptographer / decrypter 426 may be deployed as components in one or more of the token generator 112, token extractor 114, and / or token transferr 116 of the token processing system 110 shown in Figure 1.

[0068] Figure 5 shows an exemplary operation 500 for securely accessing digital tokens corresponding to other assets on a blockchain. The operation 500 described herein may be performed, for example, by the token generator 112 shown in Figure 1, the client device 420 shown in Figure 4, and so on.

[0069] As illustrated, operation 500 begins in block 510, which involves retrieving a payload associated with a first set of encryption keys from a tag associated with a physical object having a digital token counterpart. In some embodiments, the payload may contain information about a decryption key for an encrypted payload, which is encrypted using the first set of encryption keys and includes information about the digital token and information identifying the physical object. The tag may be, for example, an RFID tag on which the payload is stored and which may be updated when ownership of the physical object and the digital token counterpart is transferred. In some embodiments, the payload may be a first set of encryption keys based on other data of its that is available when accessing the digital token counterpart to the physical object.

[0070] In block 520, operation 500 proceeds to retrieve a second set of encryption keys and an identifier for a physical object based on the retrieved payload. In some embodiments, the payload can be decrypted using the encryption key and corresponding appropriate decryption key used to encrypt the payload. If the payload is encrypted using a symmetric encryption scheme, the encryption key and decryption key may be the same key. If the payload is encrypted using an asymmetric encryption scheme, the encryption key may be a public key and the decryption key may be a corresponding private key.

[0071] In some embodiments, the payload may include keys or other data that can be provided as input to a key derivation function. The key derivation function may be a function designed to generate one or more keys based on the input (and other data, such as cryptographic salts).

[0072] In block 530, operation 500 proceeds to verify possession of a first set of encryption keys and a second set of encryption keys. In some embodiments, possession of the first set of encryption keys and the second set of encryption keys may be verified by a physical device.

[0073] In block 540, operation 500 proceeds to receive an identifier for a physical object based on the possession of a first set of encryption keys and a second set of encryption keys.

[0074] In block 550, operation 500 proceeds to decrypt a payload from the blockchain, which includes the digital token counterpart of a physical object and the identifier of the physical token, based on a second set of cryptographic keys. In some embodiments, decrypting a payload from the blockchain may include decrypting an encrypted payload using the second set of cryptographic keys. The decrypted payload may include a URI that identifies the location where the digital token counterpart of the physical token is located, and the identifier of the physical object associated with the digital token counterpart.

[0075] In block 560, action 500 proceeds to access the digital token counterpart of a physical object based on a decrypted payload from the blockchain. In some embodiments, in order to access the digital token counterpart of a physical object, the decrypted identifier of the physical object may be compared with the received identifier of the physical object. If the decrypted identifier of the physical object and the received identifier of the physical object match, it can be confirmed that the holder of the second set of cryptographic keys is the legitimate owner of the physical object and its digital token counterpart. Based on this confirmation, access to the digital token counterpart may be granted. However, if the decrypted identifier of the physical object and the received identifier of the physical object do not match, it can be confirmed that there is a mismatch between the holder of the second set of cryptographic keys and the legitimate owner of the physical object, and therefore, access to the digital token counterpart of the physical object may be blocked.

[0076] Exemplary system for generating and maintaining digital tokens based on physical device identifiers Figure 6 shows an exemplary system 600 configured to perform the methods described herein, including, for example, operation 300 in Figure 3 and / or operation 500 in Figure 5. In some embodiments, system 600 may function as a token processing system, such as the token processing system 110 shown in Figure 1.

[0077] As shown, System 600 includes a central processing unit (CPU) 602, one or more I / O device interfaces 604 that can enable the connection of various I / O devices 614 (e.g., keyboard, display, mouse device, pen input, etc.) to System 600, a network interface 606 through which System 600 is connected to a network (which may be a local network, intranet, internet, or any other group of computing devices connected to communicate with each other), memory 608, and interconnects 612. The I / O device interfaces 614 and / or network interface 606 may be used to receive requests to generate, withdraw, and transfer digital tokens on a blockchain.

[0078] The CPU 602 can retrieve and execute programming instructions stored in memory 608. Similarly, the CPU 602 can retrieve and store application data in memory 608. The interconnect 612 transmits programming instructions and application data between the CPU 602, the I / O device interface 604, the network interface 606, and memory 608.

[0079] CPU602 is included to represent a single CPU, multiple CPUs, a single CPU with multiple processing cores, and so on.

[0080] Memory 608 represents volatile memory such as random access memory, or non-volatile memory such as non-volatile random access memory or phase-change random access memory. As shown, memory 608 includes a token generator 620, a token extractor 630, a token transferr 640, and a key data store 650.

[0081] The token generator 620 corresponds to the token generator 112 shown in Figure 1 and may enable the generation of digital tokens corresponding to other assets using a first private key and a second private key. The token generator 620 may receive a first private key, which may be the private key associated with the wallet to which the digital token should be deposited, and a second private key, which may be the physical identifier of a physical device owned by the owner of the digital token and the underlying asset to which the digital token should be generated.

[0082] In some embodiments, the second secret key may be obtained by reading the physical identifier of a physical device via the physical device identifier reader 610 and the antenna 616 associated with the physical device identifier reader 610, which may enable the system 600 to wirelessly read and / or write data via an NFC connection with a physical device, wirelessly read and / or write data stored on an RFID tag, wirelessly read and / or write data via a BLE connection with a physical device, and so on. In some embodiments, the second secret key may be obtained via manual entry of the physical identifier of a physical device via an I / O device interface 604 through an I / O device 614.

[0083] A public key may be derived from a first key and a second key, and the token generator 620 may use these public keys to separately encrypt metadata about the digital token and the location where the underlying asset may be accessed. The digital token, including the separately encrypted metadata and location information, may be minted, and a record proving the creation of the digital token and the initial ownership of the digital token and the underlying asset by the wallet owner may be committed to a blockchain on an external network via the network interface 606.

[0084] The token extractor 630 may correspond to the token extractor 114 shown in Figure 1. Generally, the token extractor 630 may allow the owner of the digital token, or a person who is intended to possess both the first and second private keys, to extract the digital token and decrypt the location information and metadata stored in the digital token. The encrypted information may remain encrypted during transit from the token extractor 630 to a remote client device (for example, via the network interface 606) so that the security of the data stored in the digital token can be maintained.

[0085] The token transferor 640 may correspond to the token transferor 116 shown in Figure 1 and may enable the owner of a digital token and underlying asset to transfer ownership of the digital token and underlying asset to a destination or new owner. To do so, the token transferor 640 may require the private key of the transferor and the public key of the destination. The private key of the transferor (for example, the private key for the transferor wallet and the physical identifier of the transferor's physical device) may be used to decrypt metadata and address information for the underlying asset, and the public key of the destination may be used to re-encrypt the metadata and address information for the underlying asset. The token transferor 640 may then generate a record for commitment to a blockchain on an external network via the network interface 606, which proves the transfer of ownership of the digital token from the transferor to the destination.

[0086] In some embodiments, the first private key may be stored in a key data store 650 in memory 608. The key data store 650 may enable various encryption and / or decryption keys (e.g., public and / or private keys) to be securely maintained on the system 600 for use by the token generator 620 for encrypting metadata in digital tokens, and for use by the token extractor 630 and token transferor 640 for decrypting metadata in digital tokens. To provide additional security, the second private key and second public key may not be stored in the key data store 650 because their presentation is required for the generation, viewing, and transfer of digital tokens. Compromising system 600 by not storing the second private key and the second public key in the key data store 650 still means that malicious users may still not have access to the keys necessary to decipher the address where the underlying asset associated with the digital tokens resides, and therefore may still not be able to take action with respect to the digital tokens owned by the owner of system 600.

[0087] Exemplary clause Implementation examples are described in the following numbered sections.

[0088] A method comprising: receiving a request to create a digital token corresponding to an asset; receiving a first private key associated with a wallet in which the digital token should be stored; receiving a second private key from a physical device associated with the asset owner; encrypting the asset address with the public key associated with the second private key; encrypting metadata associated with the digital token with the public key associated with the first private key; and minting the digital token on the blockchain based on the encrypted address of the asset and the encrypted metadata.

[0089] Clause 2 The method of Clause 1, wherein receiving a second secret key includes reading the identifier of a physical device via a near-field communication (NFC) data connection.

[0090] Clause 3 The method of Clause 2, wherein the identifier of the physical device includes the identifier of the NFC chip on the physical device.

[0091] Clause 4 The method described in any one of Clauses 1 to 3, wherein receiving a second secret key includes receiving an entry for an identifier associated with a physical device.

[0092] Clause 5 The method described in Clause 4, wherein the identifier includes an associated serial number of a physical device associated with the owner of the asset.

[0093] Clause 6 The method of Clause 4 or 5, wherein the identifier includes the identifier of a subscriber identification module (SIM).

[0094] Clause 7 The method described in any one of Clauses 4 to 6, wherein the identifier includes the International Mobile Device Identification Information (IMEI) associated with a physical device.

[0095] Clause 8 The method described in any one of Clauses 4 to 7, wherein the identifier includes the identifier of the radio frequency identifier (RFID) module of the physical device.

[0096] Clause 9 The metadata associated with a digital token includes a Uniform Resource Indicator (URI) that identifies the location where the asset is stored, as described in any one of Clauses 1 through 8.

[0097] Clause 10 The method described in any one of Clauses 1 to 9, wherein the metadata associated with the digital token includes confidential data used to generate public data stored in the asset.

[0098] The method described in any one of the clauses 1 through 10, further comprising receiving a request to view an asset, receiving a second private key, retrieving a digital token, using the second private key to decrypt the encrypted address of the asset from the digital token, and returning the decrypted address of the asset and the encrypted metadata in the digital token as a set of public key hashes that can be decrypted using the first private key.

[0099] Clause 12 The method of Clause 11, wherein receiving a second secret key includes reading the identifier of a physical device via a near-field communication (NFC) data connection.

[0100] The method described in any one of the clauses 1 to 12, further comprising receiving a request to transfer a digital token from one wallet to a second wallet, requesting the public key associated with the second wallet and the public key of a second physical device to be associated with the digital token, and transferring ownership of the digital token to the user associated with the second wallet based on the first private key, the second private key, the public key associated with the second wallet and the public key of the second physical device.

[0101] Clause 14 The method described in any one of Clauses 1 to 13, wherein the digital token includes a non-fungible token (NFT) having an ownership record maintained on the blockchain.

[0102] Clause 15 The method described in any one of Clauses 1 through 14, further including committing digital tokens to a wallet.

[0103] Clause 16 A processor implementation method comprising: retrieving a payload associated with a first set of encryption keys from a tag associated with a physical object having a digital token counterpart; retrieving a second set of encryption keys and an identifier for the physical object based on the retrieved payload; verifying possession of the first set of encryption keys and the second set of encryption keys; receiving the identifier for the physical object based on the verification of possession of the first set of encryption keys and the second set of encryption keys; decrypting a payload from the blockchain, including the digital token counterpart for the physical object and the identifier for the physical token, based on the second set of encryption keys; and accessing the digital token counterpart for the physical object based on the decrypted payload from the blockchain.

[0104] Clause 17 The method of Clause 16, wherein the payload associated with a first set of encryption keys includes a second set of encryption keys and an identifier of a physical object encrypted using the first set of encryption keys.

[0105] Clause 18 The method of Clause 16 or 17, wherein the first set of encryption keys includes keys used in a symmetric encryption scheme.

[0106] Clause 19 The method of any one of Clauses 16 to 18, wherein retrieving a second set of encryption keys and an identifier of a physical object includes decrypting the retrieved payload based on the first set of encryption keys.

[0107] Clause 20 The method according to any one of Clauses 16 to 19, wherein the second set of encryption keys includes a private key counterpart to a public key used to encrypt a payload from the blockchain, which includes a digital token counterpart to a physical object and an identifier to a physical object.

[0108] The method of any one of the clauses 16 to 20, wherein the possession of a first set of encryption keys and a second set of encryption keys is determined to include comparing an extracted second set of encryption keys with a known second set of encryption keys, comparing an extracted identifier of a physical object with a known identifier of a physical object, and determining that the extracted second set of encryption keys matches the known second set of encryption keys and the extracted identifier of a physical object matches a known identifier of a physical object.

[0109] Clause 22 The method of any one of Clauses 16 to 21, which includes verifying possession of a first set of encryption keys and a second set of encryption keys by sending an instruction to a tag associated with a physical object that the first set of encryption keys and the second set of encryption keys have been verified.

[0110] The method described in any one of the clauses 16 to 22, wherein accessing the digital token counterpart of a physical object based on a decrypted payload from the blockchain includes determining that the decrypted version of the digital token has been reduced to understandable data, determining that the identifier of the decrypted physical token based on a second set of cryptographic keys matches the received identifier of the physical object, and retrieving the digital token counterpart based on the determination that the decrypted version of the digital token has been reduced to understandable data and that the identifier of the physical token reduced based on a second set of cryptographic keys matches the received identifier of the physical object.

[0111] A system comprising memory storing executable instructions and a processor configured to execute those executable instructions in order to perform any one of the operations described in Clauses 1 through 23.

[0112] Clause 25 A system comprising means for performing any one of the operations described in Clauses 1 to 23.

[0113] Clause 26 A non-temporary computer-readable medium storing instructions that, when executed by a processor, cause the processor to perform any of the operations described in any one of Clauses 1 through 23.

[0114] Additional considerations The preceding descriptions are provided to enable those skilled in the art to practice the various embodiments described herein. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applicable to other embodiments. For example, changes may be made to the function and configuration of the elements described herein without departing from the scope of this disclosure. Various examples may, as appropriate, omit, replace, or add various procedures or components. Also, features described in some examples may be combined in some other examples. For example, an apparatus may be implemented and a method may be practiced using any number of embodiments described herein. Furthermore, the scope of this disclosure shall cover such apparatus or method practiced using other structures, functions, or structures and functions in addition to, or other than, the various embodiments of this disclosure described herein. It should be understood that the embodiments of this disclosure disclosed herein may be embodied by one or more elements of the claims.

[0115] As used herein, the phrase “at least one of” the list of items refers to any combination of those items, including a single member. For example, “at least one of a, b, or c” shall cover a, b, c, ab, ac, bc, and abc, as well as any combination with multiple identical elements (for example, aa, aaa, aab, aac, abb, acc, bb, bbb, bbc, cc, and ccc, or any other order of a, b, and c).

[0116] As used herein, the term “deciding” encompasses a wide variety of actions. For example, “deciding” may include calculating, calculating, processing, deriving, investigating, looking up (e.g., looking up in a table, database, or other data structure), verifying, etc. It may also include receiving (e.g., receiving information), accessing (e.g., accessing data in memory), etc. It may also include resolving, selecting, choosing, establishing, etc.

[0117] The methods disclosed herein include one or more steps or actions for achieving the method. The steps and / or actions of the method may be interchangeable with one another without departing from the claims. In other words, unless a particular order of steps or actions is specified, the order and / or use of any particular steps and / or actions may be modified without departing from the claims. Furthermore, various operations of the methods described above may be carried out by any preferred means capable of performing the corresponding function. These means may include, but are not limited to, various hardware and / or software components and / or modules, including circuits, application-specific integrated circuits (ASICs), or processors. Generally, where there are operations shown in the figures, those operations may have corresponding counterpart means plus function components with similar numbering.

[0118] The various exemplary logic blocks, modules, and circuits described in this disclosure may be implemented or carried out by general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices (PLDs), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but alternatively, the processor may be any commercially available processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors working with a DSP core, or any other such configuration.

[0119] A processing system may be implemented using a bus architecture. The bus may include any number of interconnection buses and bridges, depending on the specific application of the processing system and the overall design constraints. The bus may link various circuits to one another, particularly the processor, machine-readable media, and input / output devices. User interfaces (e.g., keypads, displays, mice, joysticks, etc.) may also be connected to the bus. The bus may also link various other circuits, such as timing sources, peripherals, voltage regulators, and power management circuits, which are well known in the art and therefore not described further. The processor may be implemented using one or more general-purpose and / or dedicated processors. Examples include microprocessors, microcontrollers, DSP processors, and other circuits capable of running software. Those skilled in the art will recognize how best to implement the functions described for the processing system, depending on the specific application and the overall design constraints imposed on the overall system.

[0120] When implemented in software, functionality may be stored or transmitted as one or more instructions or code on a computer-readable medium. Software, regardless of its name (software, firmware, middleware, microcode, hardware description language, etc.), is broadly interpreted to mean instructions, data, or any combination thereof. Computer-readable medium includes both computer storage and communication media, such as any medium that facilitates the transfer of computer programs from one location to another. A processor may be responsible for managing the bus and general processing, including the execution of software modules stored on a computer-readable storage medium. The computer-readable storage medium may be coupled to the processor so that the processor can read information from and write information to the storage medium. Alternatively, the storage medium may be integrated with the processor. For example, the computer-readable medium may include a computer-readable storage medium with instructions stored on it, separate from transmission lines, data-modulated carriers, and / or wireless nodes, all of which may be accessed by the processor through a bus interface. Alternatively, or as an addition, computer-readable media, or any part thereof, may be incorporated into the processor, as may be the case with caches and / or general-purpose register files. Examples of machine-readable storage media may include, as an example, RAM (random access memory), flash memory, ROM (read-only memory), PROM (programmable read-only memory), EPROM (erasable programmable read-only memory), EEPROM (electrically erasable programmable read-only memory), registers, magnetic disks, optical disks, hard drives, or any other suitable storage media, or any combination thereof. Machine-readable media may be embodied in computer program products.

[0121] A software module may consist of a single instruction or many instructions, and may be distributed across several different code segments, between different programs, and across multiple storage media. A computer-readable medium may contain several software modules. A software module contains instructions that, when executed by a device such as a processor, cause a processing system to perform various functions. A software module may include a send module and a receive module. Each software module may reside in a single storage device or be distributed across multiple storage devices. For example, a software module may be loaded from a hard drive into RAM when a triggering event occurs. While a software module is executing, the processor may load some of the instructions into a cache to increase access speed. One or more cache lines may then be loaded into a general-purpose register file for execution by the processor. When referring to the functionality of a software module, it should be understood that such functionality is implemented by the processor when executing instructions from that software module.

[0122] The following claims are not limited to the embodiments shown herein, but should be given the full scope consistent with the language of the claims. In the claims, a singular reference to an element means "one or more" rather than "only" unless explicitly stated otherwise. Unless otherwise stated, the term "several" means one or more. No claim element should be construed under Section 112(f) of the U.S. Patent Act unless it is expressly expressed using the phrase "means for" or, in the case of a method claim, the phrase "steps for". All structural and functional equivalents to the elements of various aspects described throughout this disclosure, known to or to those skilled in the art, are expressly incorporated by reference herein and are encompassed by the claims. Furthermore, nothing disclosed herein, whether such disclosure is expressly expressed in the claims or not, is not made public.

Claims

1. A method performed by a processor, Receiving requests to create digital tokens corresponding to assets, Receiving a first private key associated with a wallet in which the aforementioned digital token is to be stored, Receiving a second private key from a physical device associated with the owner of the aforementioned asset, The address of the asset is encrypted with the public key associated with the second private key, The metadata associated with the digital token is encrypted using the public key associated with the first private key, On the blockchain, minting the digital token based on the encrypted address of the asset and the encrypted metadata. Methods that include...

2. The method according to claim 1, wherein receiving the second secret key includes reading the identifier of the physical device via a near-field communication (NFC) data connection.

3. The method according to claim 2, wherein the identifier of the physical device includes the identifier of the NFC chip on the physical device.

4. The method according to claim 1, wherein receiving the second secret key includes receiving an entry for an identifier associated with the physical device.

5. The method according to claim 4, wherein the identifier includes an associated serial number for the physical device associated with the owner of the asset.

6. The method according to claim 4, wherein the identifier includes an identifier for a subscriber identification module (SIM).

7. The method according to claim 4, wherein the identifier includes International Mobile Device Identification Information (IMEI) associated with the physical device.

8. The method according to claim 4, wherein the identifier includes the identifier of the radio frequency identifier (RFID) module of the physical device.

9. The method according to claim 1, wherein the metadata associated with the digital token includes a uniform resource indicator (URI) that identifies the location where the asset is stored.

10. The method according to claim 1, wherein the metadata associated with the digital token includes private data used to generate public data stored in the asset.

11. Receiving a request to view the aforementioned assets, Receiving the second secret key, Extracting the aforementioned digital token, Using the second private key, decrypt the encrypted address of the asset from the digital token, The decrypted address of the asset and the encrypted metadata in the digital token are returned as a set of public key hashes that can be decrypted using the first private key. The method according to claim 1, further comprising:

12. The method according to claim 11, wherein receiving the second secret key includes reading the identifier of the physical device via a near-field communication (NFC) data connection.

13. Receiving a request to transfer the aforementioned digital token from the wallet to a second wallet, Requesting the public key associated with the second wallet and the public key of the second physical device to be associated with the digital token, Transferring ownership of the digital token to the user associated with the second wallet based on the first private key, the second private key, the public key associated with the second wallet, and the public key of the second physical device. The method according to claim 1, further comprising:

14. The method according to claim 1, wherein the digital token includes a non-fungible token (NFT) having an ownership record maintained on a blockchain.

15. The method according to claim 1, further comprising committing the digital token to the wallet.

Images