Verified Presentation of Non-Fungible Tokens
Non-fungible tokens (NFTs) authenticate and verify the authenticity of digital media by using unique identifiers and cryptographic keys, ensuring only authorized devices can present the original content, addressing the challenge of distinguishing between original and copied digital media.
Patent Information
- Application Number
- JP2024536432
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2021-12-22
- Filing Date
- 2022-12-21
- Publication Date
- 2025-02-04
- Estimated Expiration
- 2042-12-21
AI Technical Summary
Digital media, such as images, videos, and audio files, are easily copied and duplicated, making it difficult to distinguish between the original work and copies, which complicates the verification of authenticity.
The use of non-fungible tokens (NFTs) to authenticate and verify the authenticity of digital media by associating them with unique identifiers and cryptographic keys, ensuring that only authorized devices can present the original media.
Enables the accurate verification of digital media authenticity by ensuring that only genuine copies are presented, with indicators confirming the originality of the media content.
Smart Images

Figure 2025503462000001_ABST
Abstract
Description
[Technical field]
[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to and the benefit of co-pending U.S. patent application Ser. No. 17 / 559,302, entitled "VERIFIED PRESENTATION OF NON-FUNGIBLE TOKENS," filed Dec. 22, 2021, which is incorporated by reference as if fully set forth herein. [Background technology]
[0002] Digital media can often be copied and pasted. For example, image files can be easily copied or duplicated, as can other files representing other types of media (e.g., video, audio, etc.). Thus, when a work is recorded on a digital medium, it can be difficult to distinguish between an artist's original work and a copy of the work. For example, when a digital photograph is displayed in a digital picture frame, it is difficult for a viewer to tell whether he or she is looking at an original photograph or a copy. Summary of the Invention [Means for solving the problem]
[0003] Various approaches are disclosed for verifying the presentation of digital media represented by a non-fungible token (NFT). In various embodiments of the present disclosure, a user can submit an NFT representing the digital media to a presentation device. The presentation device can then evaluate the NFT and determine whether it is authorized to present the digital media associated with the NFT. In other embodiments of the present disclosure, a user can obtain information about the presentation device and the NFT associated with the digital media to be presented along with her or her client device. The client device can then verify that the presentation device is authorized to present the digital media associated with the NFT. As a result, the user can determine whether he or she is using an original copy of the digital media file or a (potentially unauthentic) duplicate. [Brief description of the drawings]
[0004] Many aspects of the present disclosure can be better understood with reference to the following drawings, in which the components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure, and in which like reference numbers indicate corresponding parts throughout the several views. [Figure 1] FIG. 1 is a diagram of a network environment in accordance with various embodiments of the present disclosure. [Diagram 2] FIG. 2 is a sequence diagram illustrating an example of interactions between components of the network environment of FIG. 2 in accordance with various embodiments of the present disclosure. [Diagram 3] FIG. 3 is a sequence diagram illustrating an example of interactions between components of the network environment of FIG. 2 in accordance with various embodiments of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0005] In the following discussion, a general description of the system and its components is provided, followed by a discussion of its operation. The following discussion provides illustrative examples of the operation of various components of the present disclosure, however, use of the following illustrative examples is not intended to exclude other implementations consistent with the principles disclosed by the following illustrative examples.
[0006] 1 illustrates a network environment 100 in accordance with various embodiments. The network environment 100 can include a presentation device 103, a client device 106, and a distributed data store 109, which can be in data communication with each other over a network 113.
[0007] Networks 113 may include wide area networks (WANs), local area networks (LANs), personal area networks (PANs), or combinations thereof. These networks may include wired or wireless components, or combinations thereof. Wired networks include Ethernet networks, cable networks, fiber optic networks, and telephone networks such as dial-up, digital subscriber line (DSL), and digital integrated services digital network (ISDN) networks. Wireless networks include cellular networks, satellite networks, Institute of Electrical and Electronics Engineers (IEEE) 802.11 wireless networks (i.e., Wi-Fi), BLUETOOTH networks, microwave transmission networks, and other networks that rely on radio broadcasting. Networks 113 may also include a combination of two or more networks 113. Examples of networks 113 include the Internet, intranets, extranets, virtual private networks (VPNs), and similar networks.
[0008] The presentation device 103 may represent any computing device capable of presenting digital media. Thus, the presentation device 103 may include a memory that stores machine-readable instructions that, when executed by a processor, cause the presentation device 103 to perform various operations. Examples of the presentation device 103 may include personal computers (e.g., desktop computers, laptop computers, or similar devices), mobile computing devices (e.g., personal digital assistants, mobile phones, smartphones, web pads, tablet computer systems, music players, handheld game consoles, e-readers, and similar devices), media playback devices (e.g., media streaming devices, Blu-ray players, digital video disc (DVD) players, set-top boxes, and similar devices), video game consoles, digital picture frames, smart speakers, or other devices with similar functionality. In some examples, the presentation device 103 may include one or more displays 116, such as liquid crystal displays (LCDs), gas plasma-based flat panel displays, organic light-emitting diode (OLED) displays, electrophoretic ink ("E-ink") displays, projectors, or other types of display devices. In some examples, the display 116 may be a component of the presentation device 103 or may be connected to the presentation device 103 via a wired or wireless connection.
[0009] Presentation device 103 may also include Hardware Security Module (HSM) 119, which is a dedicated microcontroller that secures the hardware with integrated cryptographic keys and provides support for various cryptographic operations or primitives. This may include performing various cryptographic functions on behalf of presentation device 103 or applications executed by presentation device 103. To perform these cryptographic operations, HSM 119 includes HSM public key 123 and a respective HSM private key 126. HSM public key 123 may be made freely available by HSM 119 to any application executing on presentation device 103, while HSM private key 126 may be securely kept within HSM 119 such that it is inaccessible and unreadable by other processes executing on presentation device 103 or other components of presentation device 103. For example, HSM 119 may sign any piece of data using HSM private key 126 and provide that signature to another application without disclosing HSM private key 126. As another example, HSM 119 can decrypt data that was previously encrypted using HSM public key 123 without disclosing HSM private key 126 .
[0010] Various applications or other functions may be executed by presentation device 103. These components may include a wallet application 129, a presentation application 133, and other applications, services, processes, systems, engines, or functionality not discussed in detail herein.
[0011] The wallet application 129 may be executed to facilitate interaction with the distributed data store 109 by the presentation device 103. This may include authenticating transactions on behalf of the presentation device 103. Thus, the wallet application 129 may be associated with a wallet public key 136 and a respective wallet private key 139, which allows the wallet application 129 to authenticate or verify transactions that occur on the distributed data store 109. The wallet application 129 may also be associated with a wallet address 143, which acts as an identifier of the presentation device 103 for transactions recorded by or involving the distributed data store 109. In some implementations, the wallet address 143 may be derived from the wallet public key 136 (e.g., by applying a cryptographic hash function to the wallet public key 136).
[0012] Presentation application 133 may be executed to present media using presentation device 103. For example, presentation application 133 may cause images or videos to be displayed on display 116 of presentation device 103. As another example, presentation application 133 may cause audio files (e.g., music, speech, etc.) to be played through speakers of presentation device 103.
[0013] Client device 106 is representative of multiple client devices that may be coupled to network 113. Client device 106 may include a processor, memory, a network interface, and other components. Examples of client device 106 include mobile devices (e.g., smart phones, mobile phones, tablet computers, etc.), personal computers (e.g., desktops, laptops, etc.), and similar devices.
[0014] The client device 106 may be configured to run a variety of applications, such as a client application 146 or other applications. The client application 146 may execute on the client device 106 and communicate with the presentation device 103. To this end, the client application 146 may include a browser, a dedicated application, or other executable. The client device 106 may be configured to run applications beyond the client application 146, such as an email application, a social networking application, a word processor, a spreadsheet, or other application.
[0015] Various data are also stored in the distributed data store 109. The distributed data store 109 represents a data storage network formed from multiple computing devices operating as nodes in the data storage network. In some implementations, any computing device can participate as a node in the distributed data store 109, including one or more client devices 106 or one or more presentation devices 103. In general, each node can store a copy of the data stored in the distributed data store 109. When data is written to the distributed data store 109, each node can communicate with other nodes of the distributed data store 109 to verify and / or coordinate the storage of the new record or data in the distributed data store 109. An example of the distributed data store 109 can be a blockchain that uses a proof-of-work, proof-of-stake, or proof-of-authority protocol to verify new blocks of data stored on the blockchain. Various types of data can be stored by the distributed data store 109. This may include one or more non-fungible tokens (NFTs) 149, non-fungible token (NFT) smart contracts 153, and / or one or more assertions 156.
[0016] An NFT 149 may represent a non-fungible data structure stored in a distributed data store 109, such as a blockchain, distributed ledger, or similar data store. Because an NFT 149 is non-fungible, it may be used for a variety of purposes where fungibility is not desirable. For example, an NFT 149 may be used to represent ownership or control of an asset, such as a non-fungible digital or physical item (e.g., a video, image, audio file, etc.). An NFT 149 may be structured or formatted to conform to various standards or protocols for non-fungible tokens. Examples of such standards include the ETHEREUM ERC-721 standard, the ETHEREUM ERC-1155 standard, the FLOW blockchain NFT standard, the SOLANA blockchain NFT standard, etc. Because an NFT 149 is unique and non-fungible, each NFT 149 may also have an NFT identifier 159, which may represent a unique identifier for each NFT 149 that uniquely identifies the NFT 149 with respect to other NFTs 149. The NFT identifier 159 may be formatted in a variety of ways, depending on which standard the NFT 149 conforms to. The NFT 149 may also be associated with an owner address 163, which identifies the address of the owner of the NFT 149, and an authenticated address 169, which identifies the address of an individual or entity authorized to perform various actions (e.g., sell, transfer, display, etc.) with the NFT 149. The NFT 149 may also include metadata 173, such as a URL that specifies the location of the digital file represented by the NFT 149, a hash of the digital file represented by the NFT 149, etc.
[0017] A non-fungible token (NFT) smart contract 153 may be stored or hosted in the distributed data store 109. A smart contract is an executable program stored in the distributed data store 109 and executable by a node of the distributed data store 109. A smart contract may be automatically executed when one or more predefined conditions are met. The functionality provided by a smart contract may also be called or invoked by a node of the distributed data store 109 or a client interacting with the distributed data store 109. In various embodiments of the present disclosure, the NFT smart contract 153 may be executed to create one or more NFTs 149 according to one or more predefined parameters and / or one or more arguments passed as input values to the NFT smart contract 153. The NFT smart contract 153 may also be executed to provide information about a specified NFT 149 (e.g., an owner address 166, an authenticated address, and / or metadata 173, etc.) in response to a query. The NFT smart contract 153 may also be executed or invoked to transfer ownership of the NFT 149 (e.g., by updating the owner address 166), to update the authenticated address 169 of the NFT 149, to update the metadata 173 of the NFT 149, or to perform other operations on the NFT 149.
[0018] The NFT smart contract 153 may also have a smart contract address 176. The smart contract address 176 may be used to uniquely identify the smart contract from other smart contracts hosted by the distributed data store 109. The smart contract address 176 may be used to reference the NFT smart contract 153 (e.g., to invoke functionality provided by the NFT smart contract 153).
[0019] One or more assertions 156 may be stored in the distributed data store 109. Each assertion 156 may represent an authentication by an individual associated with an owner address 166 or authenticated address 169 of an NFT 149 to a presentation device 103 associated with an HSM public key 123 for presenting media represented by the NFT 149. Thus, each assertion 156 may include an HSM public key 123, an owner address 166, and / or an authenticated address 169.
[0020] Next, a general description is provided of the operation of the various components of network environment 100. The following description provides one example of the interactions between the various components of network environment 100, although other interactions are possible. Additional details regarding the operation of and interactions between individual components are provided in the discussion accompanying the sequence diagrams of FIGS.
[0021] Initially, a user may set up his or her presentation device 103. As part of the setup process, the user may set up or register a wallet application 129 executed by the presentation device 103 to interact with his or her wallet address, thereby enabling the wallet application 129 to sign, authenticate, or verify transactions associated with the user's wallet address 143.
[0022] A user of the client device 106 can then connect his or her client device 106 to the presentation device 103. For example, the user can pair his or her mobile phone with the presentation device 103 via BLUETOOTH. Once connected, the user of the client device 106 can use the client application 146 to provide the smart contract address 176 and the NFT identifier 159 to a presentation application 133 running on the presentation device 103.
[0023] The presentation device 103 can then query the NFT smart contract 153 identified by the smart contract address 176 to obtain the owner address 166, authenticated address 169, and / or metadata 173 for the NFT 149 identified by the NFT identifier 159. The NFT smart contract 153 can then provide the owner address 166, authenticated address 169, and / or metadata in response.
[0024] To verify ownership of the NFT 149, the presentation application 133 can send a request to the wallet application 129 to sign a transaction, challenge, or other nonce value. The wallet application 129 can use the wallet private key 139 to sign the transaction, challenge, or other nonce value and provide the signature of the transaction, challenge, or other nonce value to the presentation application 133. In some examples, the wallet application 129 can also return the transaction, challenge, or other nonce value to the presentation application 133.
[0025] The presentation application 133 then recovers the wallet public key 136 from the signature and derives a wallet address 143 for the wallet application 129 from the wallet public key 136. If the wallet address 143 matches either the owner address 166 or the authenticated address 169 of the NFT 149, then the presentation application 133 can determine that the owner of the presentation device 103 is also the owner or authenticated user of the NFT 149 and therefore the presentation device 103 is authenticated to present the media represented by the NFT 149.
[0026] For example, if the NFT 149 is stored on the Ethereum blockchain and the wallet application 129 is an Ethereum wallet, then upon receiving the transaction signature from the wallet application 129, the presentation application 133 can use the ECRECOVER function provided by Ethereum's SOLIDITY language to recover the wallet public key 136. The presentation application 133 can then derive the wallet address 143 of the wallet application 129 from the recovered wallet public key 136 by generating a Keccak-256 hash of the wallet public key 136 and selecting the last 20 bytes of the Keccak-256 hash as the wallet address 143. The presentation application 133 can then compare this wallet address 143 to the owner address 166 or authenticated address 169 of the NFT 149.
[0027] If the wallet address 143 matches the owner address 166 or the authenticated address 169, the presentation application 133 can determine that the NFT 149 is authentic (e.g., owned by the user or that the user is authenticated or authorized to present the media represented by the NFT 149 using the presentation device 103). In response, the presentation application 133 can cause the presentation device 103 to present the media represented by the NFT 149. In some examples, the presentation application 133 can also cause the presentation device 103 to activate an indicator that provides an indication that the NFT 149 is authenticated, authentic, or owned by the user.
[0028] If the wallet address 143 does not match the owner address 166 or the authenticated address 169, the presentation application 133 may still be configured to cause the presentation device 103 to present the media represented by the NFT 149. However, in these circumstances, the presentation application 133 may fail to cause the presentation device 103 to activate an indicator that provides an indication that the NFT 149 is authenticated, authentic, or owned by the user. Alternatively, the presentation application 133 may be configured to ignore or otherwise fail the presentation device 103 to present the media represented by the NFT 149. In these circumstances, only NFTs 149 that are authenticated, authentic, or owned by the user will be presented using the presentation device 103.
[0029] In isolation, a viewer of the presentation device 103 may wish to verify the identity of the presentation device 103. For example, an unauthorized presentation device 103 may be configured to present a digital copy of the media represented by the NFT 149. Such a counterfeit presentation device 103 may also provide an indicator of authenticity to disguise the fact that the media is an unauthorized copy or duplicate for presentation.
[0030] Thus, a user can obtain the HSM public key 123 embedded in the HSM 119 of the presentation device 103. This can be done in a number of ways. For example, the user can use the client device 106 to scan a Quick Response (QR) code that encodes the HSM public key 123. As another example, the user can pair his or her client device 106 with the presentation device 103 using BLUETOOTH, Near Field Communication (NFC), or a similar wireless protocol to obtain the HSM public key 123.
[0031] The client application 146 can then encrypt the challenge using HSM public key 123 and send the encrypted challenge to the presentation device 103. The presentation device 103 can present the encrypted challenge to the HSM 119, which can decrypt the challenge and create a signature of the challenge using the HSM private key 126. The presentation device 103 can then send the signature of the challenge back to the client application 146.
[0032] The client application 146 can use the HSM public key 123 to verify the signature of the challenge. If the signature is valid, the client application can retrieve from the distributed data store 109 one or more assertions 156 that are associated with the HSM public key 123. The client application 146 can then evaluate the assertions 156 and determine whether the presentation device 103 is an authentic or certified device.
[0033] 2, a sequence diagram is shown providing one example of interactions between components of network environment 100. The sequence diagram of FIG. 2 provides only one example of many different types of functional arrangements that may be employed or performed within network environment 100. Alternatively, the sequence diagram of FIG. 2 may be considered to depict one example of elements of a method implemented within network environment 100.
[0034] Beginning at block 203, the client application 146 sends the NFT identifier 159 to the presentation application 133. The client application 146 may also send the smart contract address 176 responsible for the NFT 149 identified by the NFT identifier 159.
[0035] Next, in block 206, the presentation application 133 sends a request to the NFT smart contract 153 identified by the smart contract address 176. The request can invoke one or more functions provided by the NFT smart contract 153 and provide the NFT identifier 159 as an argument. For example, the presentation application 133 can invoke a first function exposed by the NFT smart contract 153 that returns the owner address 166 of the NFT 149 in response to the NFT identifier 159 provided as an argument or input to the function. Similarly, the presentation application 133 can invoke a second function exposed by the NFT smart contract 153 that returns the authenticated address 169 of the NFT 149 in response to the NFT identifier 159 provided as an argument or input to the function. Additionally, the presentation application 133 can invoke a third function exposed by the NFT smart contract 153 that returns the metadata 173 of the NFT 149 in response to the NFT identifier 159 provided as an argument or input to the function. In some implementations, one or more of these functions may be implemented as a single function of the NFT smart contract 153. The presentation application 133 can then receive the owner address 166, the authenticated address 169, and / or the metadata 173 from the NFT smart contract 153 in response.
[0036] Next, in block 209, the presentation application 133 can verify ownership of the NFT 149 identified by the NFT identifier 159 provided by the client application 146 in block 203. Thus, the presentation application 133 can send a request to the wallet application 129 to sign the transaction, challenge, or other nonce value. The wallet application 129 can sign the transaction, challenge, or other nonce value using the wallet private key 139 and provide the signature of the transaction, challenge, or other nonce value to the presentation application 133. In some examples, the wallet application 129 can also return the transaction, challenge, or other nonce value to the presentation application 133.
[0037] The presentation application 133 can then recover the wallet public key 136 from the signature and derive the wallet address 143 of the wallet application 129 from the wallet public key 136. If the wallet address 143 matches either the owner address 166 or the authenticated address 169 of the NFT 149, the presentation application 133 can determine that the owner of the presentation device 103 is also the owner or authenticated user of the NFT 149 and therefore the presentation device 103 is authenticated to present the media represented by the NFT 149.
[0038] For example, if the NFT 149 is stored on the Ethereum blockchain and the wallet application 129 is an Ethereum wallet, then upon receiving the transaction signature from the wallet application 129, the presentation application 133 can use the ECRECOVER function provided by Ethereum's SOLIDITY language to recover the wallet public key 136. The presentation application 133 can then derive the wallet address 143 of the wallet application 129 from the recovered wallet public key 136 by generating a Keccak-256 hash of the wallet public key 136 and selecting the last 20 bytes of the Keccak-256 hash as the wallet address 143. The presentation application 133 can then compare this wallet address 143 to the owner address 166 or authenticated address 169 of the NFT 149.
[0039] If the presentation application 133 determines that the NFT 149 is owned by or authorized for presentation by the presentation device 103, the presentation application 133 may cause the presentation device 103 to activate an indicator of authenticity in block 213. For example, the presentation application 133 may cause the presentation device 103 to turn on a small light or change the color of the light (e.g., from red to green) to indicate that the NFT 149 is owned by or authorized for provision by the presentation device 103. Similarly, if the NFT 149 is not owned by or authorized for provision by the presentation device 103, the presentation application 133 may cause the presentation device 103 to deactivate the indicator of authenticity by turning off the small light or changing the color of the light (e.g., from green to red).
[0040] Next, in block 216, the presentation application 133 may cause the media represented by the NFT 149 to be presented using the presentation device 103. For example, the presentation application 133 may request the media file located at a uniform resource locator (URL) specified in the metadata of the NFT 149. Once the media file is received, it may be presented using the presentation device 103. For example, if the media file is an image or video, the media file may be displayed on the display 116 of the presentation device 103. As another example, if the media file is an audio file, the audio file may be played using speakers built into the presentation device 103.
[0041] In some implementations, the presentation application 133 may compare the hash of the media file located at the URL to the hash included in the metadata 173 of the NFT 149 in block 216. If the hashes match, this indicates that the media file located at the URL is the media file represented by the NFT 149. In this situation, the presentation application 133 may then present the media file. However, if the hashes do not match, this indicates that the media file located at the URL is not the media file represented by the NFT 149. In such a situation, the presentation application 133 may fail to present the media file.
[0042] As discussed above, if the NFT 149 is not validated at block 209, the media represented by the NFT 149 may still be presented at block 216 in some implementations. However, as discussed at block 213, the indicator of authenticity may indicate that the NFT 149 is not owned by the owner of the presentation device 103 or has not been authenticated or displayed using the presentation device 103. Alternatively, the functionality of block 216 may be skipped or omitted for NFTs 149 that are not owned or authenticated for presentation.
[0043] 3, a sequence diagram is shown providing one example of interactions between components of network environment 100. The sequence diagram of FIG. 3 provides only one example of many different types of functional arrangements that may be employed or performed within network environment 100. Alternatively, the sequence diagram of FIG. 3 may be considered to depict one example of elements of a method implemented within network environment 100.
[0044] Beginning at block 301, the client application 146 can obtain the HSM public key 123 from the HSM 119 of the presentation device 103 that is presenting the media represented by the NFT 149. This can be done using a variety of approaches. For example, the client application 146 can have the client device 106 scan a matrix barcode (e.g., a QR code) or other encoding of the HSM public key 123, or receive a scan captured by another application running on the client device 106. As another example, a user can pair his or her client device 106 with the presentation device 103 using BLUETOOTH, Near Field Communication (NFC), or a similar wireless protocol to obtain the HSM public key 123. The client application 146 can then wirelessly communicate with the presentation device 103 to receive the HSM public key 123.
[0045] Moving to block 303, the client application 146 can send a challenge to the presentation application 133. For example, the client application 146 can generate a token, nonce value, or other piece of random data. The client application 146 can then encrypt the token, nonce value, or other piece of random data with the HSM public key 123 to generate an encrypted token, nonce value, or other piece of random data that the client application 146 can send to the presentation application 133 as an encrypted challenge.
[0046] Next, in block 306, presentation application 133 may cause the encrypted challenge sent by client application 146 to be decrypted and signed with HSM private key 126 of HSM 119. For example, presentation application 133 may use HSM private key 126 to decrypt the encrypted challenge and then invoke one or more functions provided by HSM 119 to sign the resulting token, nonce value, or other random piece of data with HSM private key 126.
[0047] Next, in block 309 , the presentation application 133 may return the signature generated in block 306 to the client application 146 .
[0048] Thus, in block 311, the client application 146 can verify the signature provided by the presentation application 133. For example, the client application 146 can use the HSM public key 123 obtained in block 301 to verify the signature of the token received in block 309, a nonce value, or a random piece of data generated by the respective HSM private key 126. If the signature is verified, the client application 146 can determine that it is communicating with a presentation device 103 associated with the HSM public key 123.
[0049] Moving to block 313, the client application 146 may retrieve one or more assertions 156 associated with the HSM public key 123 from the distributed data store 109. Thus, the HSM public key 123 may be used as a search parameter to retrieve all assertions 156 created for the presentation device 103.
[0050] Next, in block 316, the client application 146 can evaluate the assertion 156 to determine whether the media rendered by the presentation device 103 is associated with a valid or authenticated NFT 149. For example, the client application 146 can obtain the owner address 166 or authenticated address 169 and the NFT identifier 159 of the NFT 149 that represents the currently presented media.
[0051] Client application 146 can obtain NFT identifier 159, owner address 166, and / or authenticated address 169 through several approaches. In one example, presentation device 103 can display these values (e.g., through a matrix barcode, such as a QR code, that can be scanned by client device 106), which can be scanned by client device 106 and provided to client application 146. As another example, these values can be sent by presentation application 133 to client application 146 (e.g., via a BLUETOOTH or NFC connection between client device 106 and presentation device 103).
[0052] The client application 146 can then compare the NFT identifier 159 and the owner address 166 or authenticated address 169 to the NFT identifier 159 and the owner address 166 or authenticated address 169 listed in the assertion 156 associated with the HSM public key 123 of the presentation device 103. If the NFT identifier 159 and the owner address 166 or authenticated address 169 match the values listed in the assertion 156, the client application 146 can conclude that the presentation device 103 is authenticated or authorized to display the media represented by the NFT 149 and that the presentation is valid or authentic.
[0053] Some of the software components discussed above are stored in the memory of the respective computing device and are executable by the processor of the respective computing device. In this respect, the term "executable" refers to a program file in a form that can ultimately be executed by the processor. Examples of executable programs include compiled programs that can be loaded into a random access portion of memory and converted into machine code in a format that can be executed by the processor, source code that can be expressed in a suitable format, such as object code, that can be loaded into a random access portion of memory and executed by the processor, or source code that can be interpreted by another executable program to generate instructions in the random access portion of memory to be executed by the processor. Executable programs can be stored in any portion or component of memory, such as random access memory (RAM), read-only memory (ROM), hard drive, solid-state drive, universal serial bus (USB) flash drive, memory card, optical disk such as compact disk (CD) or digital versatile disk (DVD), floppy disk, magnetic tape, or other memory components.
[0054] Memory includes both volatile and non-volatile memory and data storage components. Volatile components are components that do not retain a data value when power is lost. Non-volatile components are components that retain a data value when power is lost. Thus, memory can include random access memory (RAM), read-only memory (ROM), hard disk drives, solid state drives, USB flash drives, memory cards accessed through a memory card reader, floppy disks accessed through an associated floppy disk drive, optical disks accessed through an optical disk drive, magnetic tapes accessed through a suitable tape drive, or other memory components, or a combination of any two or more of these memory components. In addition, RAM can include static random access memory (SRAM), dynamic random access memory (DRAM), or magnetic random access memory (MRAM) and other such devices. The ROM may include a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or other similar memory devices.
[0055] The applications and systems described herein may be embodied as software or code executed by general purpose hardware as discussed above, but alternatively, the applications and systems described herein may also be embodied as dedicated hardware, or a combination of software / general purpose hardware and dedicated hardware. When embodied as dedicated hardware, each may be implemented as a circuit or state machine employing any one or combination of several technologies. Such technologies may include, but are not limited to, discrete logic circuits having logic gates that implement various logic functions upon application of one or more data signals, application specific integrated circuits (ASICs) having appropriate logic gates, field programmable gate arrays (FPGAs), or other components, and the like. Such technologies are generally known to those skilled in the art and consequently will not be described in detail herein.
[0056] The sequence diagrams represent the functionality and operation of the implementation of the portions of the various embodiments of the present disclosure. When embodied as software, each block may represent a module, segment, or portion of code that includes program instructions for implementing the specified logical function. The program instructions may be embodied in the form of source code that includes human-readable statements written in a programming language or machine code that includes numerical instructions recognizable by a suitable execution system, such as a processor in a computer system. The machine code may be transformed from the source code through various processes. For example, the machine code may be generated from the source code using a compiler prior to execution of the corresponding application. As another example, the machine code may be generated from the source code simultaneously with execution by an interpreter. Other techniques may also be used. When embodied as hardware, each block may represent a circuit or several interconnected circuits for implementing one or more specified logical functions.
[0057] Although the sequence diagrams follow a specific order of execution, it should be understood that the order of execution may differ from that depicted. For example, the order of execution of two or more blocks may be scrambled relative to the order shown. Also, two or more blocks shown in succession may be executed concurrently or with partial concurrence. Furthermore, in some embodiments, one or more of the blocks shown in the sequence diagrams may be skipped or omitted. Additionally, any number of counters, state variables, alert semaphores, or messages may be added to the logic flows described herein for purposes such as improving usability, billing, measuring performance, or providing troubleshooting assistance. It should be understood that all such variations are within the scope of the present disclosure.
[0058] Also, any logic or application described herein, including software or code, may be embodied as any non-transitory computer-readable medium for use by or in combination with an instruction execution system, such as a processor in a computer system or other system. In this sense, logic may include statements, including instructions and declarations, that may be fetched from a computer-readable medium and executed by an instruction execution system. In the context of this disclosure, a "computer-readable medium" may be any medium capable of containing, storing, or maintaining the logic or application described herein for use by or in combination with an instruction execution system. Moreover, a collection of distributed computer-readable media (e.g., a storage area network, or a distributed or clustered file system or database) located across multiple computing devices may also be collectively considered a single non-transitory computer-readable medium.
[0059] The computer-readable medium may include any of many physical media, such as magnetic, optical, or semiconductor media. More specific examples of suitable computer-readable media may include, but are not limited to, magnetic tape, magnetic floppy diskette, magnetic hard drive, memory card, solid-state drive, USB flash drive, or optical disk. The computer-readable medium may also be random access memory (RAM), including static random access memory (SRAM) and dynamic random access memory (DRAM) or magnetic random access memory (MRAM). In addition, the computer-readable medium may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or other types of memory devices.
[0060] Furthermore, any logic or application described herein may be implemented and structured in a variety of ways. For example, one or more applications described herein may be implemented as modules or components of a single application. Furthermore, one or more applications described herein may execute on a shared computing device or separate computing devices, or a combination thereof. For example, multiple applications described herein may execute on the same computing device or on multiple computing devices within the same computing environment.
[0061] Disjunctive phrases, such as the phrase "at least one of X, Y, or Z," are understood in the context in which they are generally used to indicate that an item, term, etc. can be either X, Y, or Z, or any combination thereof (e.g., X; Y; Z; X, or Y; X, or Z; Y, or Z; X, Y, or Z; etc.), unless expressly stated otherwise. Thus, such disjunctive phrases are generally not intended to, and should not, imply that a particular embodiment requires that at least one of X, at least one of Y, and / or at least one of Z, respectively, be present.
[0062] It should be emphasized that the above-described embodiments of the present disclosure are merely possible examples of implementations set forth to provide a clear understanding of the principles of the present disclosure. Many variations and modifications may be made to the above-described embodiments without substantially departing from the spirit and principles of the present disclosure. All such variations and modifications are intended to be included herein within the scope of the present disclosure and protected by the following claims.
[0063] Various embodiments of the present disclosure are described in the following clauses. In the following clauses, some embodiments of the present disclosure are described, while other embodiments of the present disclosure are also described above.
[0064] Clause 1 A system comprising: a computing device including a processor, a memory, and a display; and machine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to at least receive a smart contract address and a non-fungible token (NFT) identifier from a client device; execute a function of a smart contract placed at the smart contract address to obtain an owner address for the NFT, where the NFT identifier is provided as an argument to the function of the smart contract; verify the owner address for the NFT; and present a media file represented by the NFT in response to verifying the owner address for the NFT.
[0065] Clause 2 The system described in clause 1, wherein the machine-readable instructions, when executed, cause a computing device to present a media file represented by an NFT, at least identify a uniform resource locator (URL) included in the metadata of the NFT, the URL specifying where the media file is located, and further retrieve the media file from the location specified by the URL.
[0066] Clause 3 The system of any one of clauses 1 to 2, wherein the computing device further comprises an indicator light that, when active, indicates that the image is authentic, and the machine-readable instructions, when executed by the computing device, cause the computing device to further activate the indicator light in response to at least verifying the owner address for the NFT.
[0067] Clause 4 The system of any one of clauses 1 to 3, wherein the client device communicates with the computing device via a BLUETOOTH or near field communication (NFC) connection, and the smart contract address and the NFT identifier are received via the BLUETOOTH or NFC connection.
[0068] Clause 5 The system of clauses 1-4, wherein the machine-readable instructions that, when executed, cause the computing device to verify the owner address for the NFT further cause the computing device to at least send a request to sign a transaction to a wallet application hosted by the computing device, receive a transaction signature from the wallet application, determine a wallet public key based on at least a portion of the transaction signature, derive a wallet address from the wallet public key, and determine that the wallet address matches the owner address.
[0069] Clause 6 The system of clauses 1 to 5, wherein the NFT includes a hash and the machine-readable instructions, when executed, further cause the computing device to at least determine that the hash included in the NFT matches a hash of the media file, and wherein the media file is retrieved from the location specified by the URL in response to a determination that the hash included in the NFT matches the hash of the media file.
[0070] Clause 7 The system of any one of clauses 1 to 6, wherein the NFT is stored on the Ethereum blockchain.
[0071] Clause 8 A method comprising: receiving, from a client device, a smart contract address and a non-fungible token (NFT) identifier; executing a function of a smart contract located at the smart contract address to obtain an owner address for the NFT, the NFT identifier being provided as an argument to the function of the smart contract; verifying the owner address for the NFT; and presenting a media file represented by the NFT in response to verifying the owner address for the NFT.
[0072] Clause 9 The method of claim 8, wherein presenting the media file further includes identifying a uniform resource locator (URL) included in metadata of the NFT, the URL specifying a location where the media file is located, and retrieving the media file from the location specified by the URL.
[0073] Clause 10 10. The method of any one of clauses 8-9, further comprising activating an indicator light on the presentation device in response to verifying the owner address for the NFT.
[0074] Clause 11 11. The method of any one of clauses 8 to 10, wherein the smart contract address and the NFT identifier are received via a BLUETOOTH or NFC connection with the client device.
[0075] Clause 12 12. The method of any one of clauses 8 to 11, wherein verifying the owner address for the NFT further includes sending a request to a wallet application hosted by the computing device to sign the transaction, receiving the transaction signature from the wallet application, determining a wallet public key based on at least a portion of the transaction signature, deriving a wallet address from the wallet public key, and determining that the wallet address matches the owner address.
[0076] Clause 13 The method of any one of clauses 8 to 12, wherein the NFT includes a hash, and the method further includes determining that the hash included in the NFT matches a hash of a media file, and in response to determining that the hash included in the NFT matches the hash of the media file, retrieving the media file from the location specified by the URL occurs.
[0077] Clause 14 14. The method of any one of clauses 8 to 13, wherein the NFT is stored on the Ethereum blockchain.
[0078] Clause 15 A non-transitory, computer-readable medium comprising machine-readable instructions that, when executed by a processor of a computing device, cause the computing device to at least receive from a client device a smart contract address and a non-fungible token (NFT) identifier, execute a function of a smart contract placed at the smart contract address to obtain an owner address for the NFT, where the NFT identifier is provided as an argument to the function of the smart contract, verify the owner address for the NFT, and present a media file represented by the NFT in response to verifying the owner address for the NFT.
[0079] Clause 16 The non-transitory, computer-readable medium of claim 15, further comprising machine-readable instructions that, when executed, cause a computing device to present a media file represented by an NFT, at least identify a uniform resource locator (URL) included in metadata of the NFT, where the URL specifies where the media file is located, and retrieve the media file from the location specified by the URL.
[0080] Clause 17 The non-transitory, computer-readable medium of any one of clauses 15 to 16, wherein the computing device further comprises an indicator light that, when active, indicates that the image is authentic, and the machine-readable instructions, when executed by the computing device, cause the computing device to further activate at least the indicator light in response to verifying the owner address for the NFT.
[0081] Clause 18 The non-transitory, computer-readable medium of clauses 15-17, wherein the client device communicates with the computing device via a BLUETOOTH or near field communication (NFC) connection, and the smart contract address and the NFT identifier are received via the BLUETOOTH or NFC connection.
[0082] Clause 19 The non-transitory, computer-readable medium of clauses 15-18, wherein the machine-readable instructions that, when executed, cause a computing device to verify an owner address for an NFT further cause the computing device to at least send a request to a wallet application hosted by the computing device to sign a transaction, receive a transaction signature from the wallet application, determine a wallet public key based on at least a portion of the transaction signature, derive a wallet address from the wallet public key, and determine that the wallet address matches the owner address.
[0083] Clause 20 The non-transitory, computer-readable medium of clauses 15 to 19, wherein the NFT is stored on the Ethereum blockchain.
Claims
1. a computing device including a processor, a memory, and a display; The machine-readable instructions stored in the memory, which when executed by the processor, cause the computing device to at least: receiving a smart contract address and a non-fungible token (NFT) identifier from a client device; executing a function of a smart contract located at the smart contract address to obtain the owner address for the NFT, where the NFT identifier is provided as an argument to the function of the smart contract; verifying the owner address for the NFT; presenting a media file represented by the NFT in response to validating the owner address for the NFT; and A system comprising:
2. The machine-readable instructions, which when executed, cause the computing device to present the media file represented by the NFT, include at least: identifying a Uniform Resource Locator (URL) included in metadata of the NFT, the URL specifying where the media file is located; retrieving the media file from the location specified by the URL; The system of claim 1 further comprising:
3. 3. The system of claim 1 or 2, wherein the computing device further comprises an indicator light that, when active, indicates that the image is authentic, and the machine-readable instructions, when executed by the computing device, further cause the computing device to at least activate the indicator light in response to verifying the owner address for the NFT.
4. 4. The system of claim 1, wherein the client device communicates with the computing device via a BLUETOOTH or near field communication (NFC) connection, and the smart contract address and the NFT identifier are received via the BLUETOOTH or NFC connection.
5. The machine-readable instructions, which when executed cause the computing device to verify the owner address for the NFT, cause the computing device to at least: Sending a request to sign a transaction to a wallet application hosted by the computing device; receiving the signature of the transaction from the wallet application; determining a wallet public key based at least in part on the signature of the transaction; deriving a wallet address from the wallet public key; determining that the wallet address matches the owner address; The system according to claim 1 to 4, further comprising:
6. The NFT includes a hash, and the machine-readable instructions, when executed, cause the computing device to at least: determining that the hash included in the NFT matches a hash of the media file; The system of claim 1 , wherein the media file is retrieved from the location specified by the URL in response to a determination that the hash included in the NFT matches the hash of the media file.
7. The system of claims 1 to 6, wherein the NFT is stored on the Ethereum blockchain.
8. receiving a smart contract address and a non-fungible token (NFT) identifier from a client device; executing a function of a smart contract located at the smart contract address to obtain the owner address for the NFT, where the NFT identifier is provided as an argument to the function of the smart contract; verifying the owner address for the NFT; presenting the media file represented by the NFT in response to validating the owner address for the NFT; A method comprising:
9. Presenting the media file includes: Identifying a Uniform Resource Locator (URL) included in metadata of the NFT, the URL specifying where the media file is located; Retrieving the media file from the location specified by the URL; The method of claim 8 further comprising:
10. 10. The method of claim 8 or 9, further comprising activating an indicator light of a presentation device in response to verifying the owner address for the NFT.
11. 11. The method of claim 8, wherein the smart contract address and the NFT identifier are received via the BLUETOOTH or NFC connection with the client device.
12. Validating the owner address for the NFT includes: Sending a request to a wallet application hosted by the computing device to sign a transaction; receiving the signature of the transaction from the wallet application; determining a wallet public key based at least in part on the signature of the transaction; deriving a wallet address from the wallet public key; determining that the wallet address matches the owner address; The method of claim 8 to 11, further comprising:
13. the NFT comprises a hash, and the method further comprises: determining that the hash included in the NFT matches a hash of the media file; In response to determining that the hash included in the NFT matches the hash of the media file, retrieving the media file from the location specified by the URL occurs. The method of claims 8 to 12, further comprising:
14. 14. The method of claim 8 to 13, wherein the NFT is stored on the Ethereum blockchain.
15. When executed by a processor of a computing device, the computing device is provided with at least receiving a smart contract address and a non-fungible token (NFT) identifier from a client device; executing a function of a smart contract located at the smart contract address to obtain the owner address for the NFT, where the NFT identifier is provided as an argument to the function of the smart contract; verifying the owner address for the NFT; presenting a media file represented by the NFT in response to validating the owner address for the NFT; A non-transitory, computer-readable medium containing machine-readable instructions for causing
16. The machine-readable instructions, which when executed, cause the computing device to present the media file represented by the NFT, include at least: identifying a Uniform Resource Locator (URL) included in metadata of the NFT, the URL specifying where the media file is located; Retrieving the media file from the location specified by the URL; 20. The non-transitory, computer-readable medium of claim 15, further comprising:
17. 17. The non-transitory, computer-readable medium of claim 15 or 16, wherein the computing device further comprises an indicator light that, when active, indicates that the image is authentic, and the machine-readable instructions, when executed by the computing device, cause the computing device to further activate at least the indicator light in response to verifying the owner address for the NFT.
18. 18. The non-transitory, computer-readable medium of claims 15-17, wherein the client device communicates with the computing device via a BLUETOOTH or near field communication (NFC) connection, and the smart contract address and the NFT identifier are received via the BLUETOOTH or NFC connection.
19. The machine-readable instructions, which when executed cause the computing device to verify the owner address for the NFT, cause the computing device to at least: Sending a request to a wallet application hosted by the computing device to sign a transaction; receiving a signature of the transaction from the wallet application; determining a wallet public key based at least in part on the signature of the transaction; deriving a wallet address from the wallet public key; determining that the wallet address matches the owner address; 20. The non-transitory, computer-readable medium of claim 15 to 18, further comprising:
20. 20. The non-transitory, computer-readable medium of claims 15-19, wherein the NFT is stored on the Ethereum blockchain.
Citation Information
Patent Citations
Decentralized marketplaces and ecosystems enabled by blockchain-based document delivery, collaboration, and distribution
JP2021518028A
Computer system and method for more efficiently storing, issuing, and transacting tokenized blockchain game assets managed by a smart contract
US10946283B1
Non-fungible token (NFT) based digital rights management in a decentralized data delivery network
US11075891B1
Property right confirmation and transfer methods and systems, electronic device, and storage medium
WO2021121090A1