WO2024003778A1

WO2024003778A1 - Improving online community and privacy for non fungible token (nft) token holders

Info

Publication number: WO2024003778A1
Application number: PCT/IB2023/056704
Authority: WO
Inventors: Gregory James SPILLANE; Jordan Allen WASHBURN
Original assignee: Rfyn, Inc.
Priority date: 2022-06-28
Filing date: 2023-06-28
Publication date: 2024-01-04

Abstract

The present disclosure seeks to improve on NFT token holders' user experience. A secure wallet authorization protocol (SWAP) enhances the privacy of the token holder. Third-party applications are only granted access to the metadata of the desired token, thereby protecting the privacy of the token holder and their wallet. Role based access control (RBAC) assigns all roles and responsibilities to the token zero holder. The token zero holder can then delegate tasks to oversee the community in whatever way they see fit. Additionally, a generalizable communication protocol can send messages to different groups based on subscription level and interest.

Description

IMPROVING ONLINE COMMUNITY AND PRIVACY FOR NON FUNGIBLE TOKEN (NFT) TOKEN HOLDERS

TECHNICAL FIELD

[0001] The present disclosure relates to adding functionality to enable non-fungible token (NFT) token holders to interact in a community or social network.

BACKGROUND

[0002] NFTs (or non-fungible tokens) are unique identification tokens that exist in the memory of the blockchain under the scope of compiled and executable code that is deployed as a smart contract. This smart contract enables enhancing the identifier to more value, and that value can represent digital assets like art, music, in-game items, and videos. Alternatively or additionally, the value can represent a relationship between token holders, or a relationship to the contract, or any other virtual function. NFTs are generally one of a kind, or at least one of a very limited run, and have unique identifying codes. Because of this, NFTs contain built-in authentication, which serves as proof of ownership. The authentication is made by the owner having a combination of an address and a keypair on a blockchain.

[0003] Physical money and cryptocurrencies are “fungible,” meaning they can be traded or exchanged for one another. They’re also equal in value — one dollar is always worth another dollar; one Bitcoin is always equal to another Bitcoin. Crypto’s fungibility makes it a trusted means of conducting transactions on the blockchain.

[0004] NFTs are different. Each has a digital signature that makes it impossible for NFTs to be exchanged for or equal to one another (hence, non-fungible). One NBA video clip NFT, for example, is not equal to a digital art NFT simply because they’re both NFTs. One NBA video clip NFT is not even necessarily equal in value to another NBA video clip NFT, for that matter.

[0005] NFTs exist on a blockchain, which is a distributed public ledger that records transactions. The “blockchain” is named according to the “block,” formed by packing multiple transactions and the hash value of the previous block, and the “link” generated with respect to the dependencies of the hash values within the previous block and the following block.

[0006] NFTs are pointers and can point to a myriad of different things. For example, the address can point to a digital asset, it can point to a position in office, it can point to a vote, it can point to a generative concept, it can point to a representation of Al, or it can point to the rights over music. In short, NFT pointers can point to almost anything.

[0007] In the example of a digital asset, NFTs are like physical collector’s items, only digital. So instead of getting an actual oil painting to hang on the wall, the owner gets a digital file instead. Owners also get exclusive ownership rights. NFTs can have only one owner at a time, and their use of blockchain technology makes it easy to verify ownership and transfer tokens between owners. NFTs may be stored in an owner’s digital wallet.

[0008] Further, NFTs are often stored under solidity contracts that define what is commonly referred to as a collection. These contracts are deployed on blockchains such as Ethereum or Polygon. [0009] The collections store and define the rules, parameters, tradability, transactions, and other details about each individual token under it. When a token is created, it is minted and assigned to an owner. That owner then owns a unique non fungible identifier held within that contract’s address. This identifier points to a set of well-known and defined metadata about that token, things that represent imagery, attributes, traits, and other details about that token.

[0010] At minimum, all token holders have been minted by the same contract and share this common characteristic. As a result, it can be said that these token holders belong to the community of the collection by virtue of owning the token. Often, they share very similar interests because of the nature of the token. An example of this would be Steve Aoki’s passport tokens for his “Aokiverse” which define a set of images and benefits that the token holders own because they possess a token. [0011] While many inroads have been made in the field of NFTs, further improvements will bolster the token holder’s user experience.

SUMMARY

[0012] The present disclosure seeks to add new functionality such that NFT token holders can behave like a community or social network. Role based access control (RBAC) assigns all roles and responsibilities to the token zero holder. The token zero holder can then delegate tasks to oversee the community in whatever way they see fit. For example, the token zero holder can create a role structure (e.g., create and designate moderators and/or other roles), create a permission structure (e.g., permit the ability to chat and/or other permissions), create role and permission structures (e.g., allow the moderators to be able to chat, etc.), grant roles (e.g., designate a specific person as a moderator, etc.), revoke roles, and/or perform other operations. Further, a secure wallet authorization protocol (SWAP) enhances the privacy of the token holder. Third-party applications are only granted access to the metadata of the desired token, thereby protecting the privacy of the token holder and their wallet. Additionally, a generalizable communication protocol can send messages to different groups based on subscription level and interest.

[0013] According to an embodiment, a tangible, non-transitory, machine-readable medium storing instructions on a server that when executed by one or more processors effectuate operations, the operations include creating an online community comprised of token holders and granting configuration rights to the token holder of token zero. The configuration rights include rights for creating a hierarchy and structure of the online community, rights for creating rules of the online community, rights for managing roles, permissions, and responsibilities of the token holders in the online community, rights for promoting certain token holders to moderator roles to monitor the token holders to ensure they are adhering to the rules of the online community, and rights for posting messages to a content feed viewable by the token holders. Further, an individual token held by a token holder is verifiable via the blockchain.

[0014] In an embodiment, the server is a blockchain server.

[0015] In an embodiment, when ownership of token zero is transferred, the configuration rights will remain with the new owner of token zero.

[0016] In an embodiment, when ownership of a token assigned to the moderator role is transferred, the moderator role will be revoked from that token.

[0017] In an embodiment, the rights for managing roles, permissions, and responsibilities of the token holders in the online community comprise assigning roles and revoking roles of the token holders.

[0018] According to an embodiment, a tangible, non-transitory, machine-readable medium storing instructions of an application that when executed by one or more processors effectuate operations for a digital wallet for storing a plurality of tokens of a wallet owner on a server, the operations include requesting approval from the wallet owner for a specific token’s metadata within the digital wallet. Upon receiving approval from the wallet owner, the operations include receiving an authorization grant code. The operations then present the authorization grant code to a wallet access server. The operations then receive an access token and the specific token metadata from the wallet access server, wherein only the specific token metadata and no other token metadata is received from the digital wallet of the wallet owner. The operations then present the access token to the wallet access server to request permitted resources. Thereafter, the operations receive the permitted resources from the wallet access server. Further, the token is verifiable via the blockchain.

[0019] In an embodiment, the server is a blockchain server.

[0020] In an embodiment, the application does not have access to the token ID.

[0021] In an embodiment, the application does not have access to the wallet address.

[0022] In an embodiment, the access token can be used by the application to interact with the specific token metadata until the access token is revoked by the wallet owner.

[0023] According to an embodiment, a tangible, non-transitory, machine-readable medium storing instructions on a server that when executed by one or more processors effectuate operations for a digital wallet for storing a plurality of tokens of a wallet owner on a server, the operations include creating an online community comprised of token holders, communicating general messages and announcements with all the token holders, communicating VIP messages with only VIP token holders and not non- VIP token holders, and communicating directly with individual token holders. Further, the communication of messages and announcements is provided over a content feed. Additionally, an individual token held by a token holder is verifiable via the blockchain. Also, a subset of all the token holders is the VIP token holders.

[0024] In an embodiment, the server is a blockchain server.

[0025] In an embodiment, messages can be sent to groups of token holders based on attributes or other qualities of tokens.

[0026] In an embodiment, the messages and the announcements can be permanent or temporary. [0027] In an embodiment, each message contains an author, a timestamp, and rich body content that can include text, images, video, and links.

[0028] Further features and advantages of the invention, as well as the stmcture and operation of various embodiments of the invention, are described in detail below with reference to the accompanying drawings. It is noted that the invention is not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Additional embodiments will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.

BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate the present invention and, together with the description, further serve to explain the principles of the invention and to enable a person skilled in the relevant art(s) to make and use the invention.

[0030] FIG. 1 is a schematic drawing of a system having an NFT engine, according to an embodiment of the present disclosure.

[0031] FIG. 2 is a schematic drawing of an exemplary computing system, according to an embodiment of the present disclosure.

[0032] FIG. 3 is a schematic drawing of operations performed by the role based access control (RBAC) system, according to an embodiment of the present disclosure.

[0033] FIG. 4 is a schematic drawing of a digital wallet that stores tokens, according to an embodiment of the present disclosure.

[0034] FIG. 5 is a schematic drawing of the secure wallet authorization protocol (SWAP), according to an embodiment of the present disclosure.

[0035] FIG. 6A is a schematic drawing of the token zero content feed, according to an embodiment of the present disclosure.

[0036] FIG. 6B is a schematic drawing of a VIP token holder’s content feed, according to an embodiment of the present disclosure.

[0037] FIG. 6C is a schematic drawing of a regular token holder’s content feed, according to an embodiment of the present disclosure.

[0038] FIG. 7 is a schematic drawing of a method associated with the generalizable communication protocol, according to an embodiment of the present disclosure.

DETAILED DESCRIPTION

[0039] This specification discloses one or more embodiments that incorporate the features of this invention. The disclosed embodiment(s) merely exemplify the invention. The scope of the invention is not limited to the disclosed embodiment(s). The invention is defined by the claims appended hereto. [0040] The embodiment(s) described, and references in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment(s) described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is understood that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether explicitly described.

[0041] FIG. 1 illustrates a system 10 comprising a utility NFT interface 12 and other components as described herein. In some embodiments, the utility NFT interface 12 is executed by one or more of the computers described below with reference to FIG. 2 (and/or other computers) and includes an application program interface (API) server 26, a web server 28, a data store 30, a cache server 32, and a blockchain server 33. These components, in some embodiments, communicate with one another in order to provide the functionality of the utility NFT interface 12 described herein. As described in greater detail below, in some embodiments, the data store 30 may store data about users and transactions associated with users. The cache server 32 may expedite access to this data by storing likely relevant data in relatively high-speed memory, for example, in random-access memory or a solid-state drive. The web server 28 may serve webpages having graphical user interfaces that display login views, one or more views that facilitate transactions by users, or other displays. The API server 26 may serve data to various applications that process data related to user logins, transactions, or other data. The blockchain server 33 stores the contents of the NFTs at a location on the blockchain. The blockchain server 33 also stores compiled and executable code that is deployed as a smart contract. [0042] The operation of components 26, 28, and 30 may be coordinated by a controller 14, which may bidirectionally communicate with each of these components or direct the components to communicate with one another. Communication may occur by transmitting data between separate computing devices (e.g., via transmission control protocol/intemet protocol (TCP/IP) communication over a network), by transmitting data between separate applications or processes on one computing device or by passing values to and from functions, modules, or objects within an application or process, e.g., by reference or by value.

[0043] Among other operations, in some embodiments, the utility NFT interface 12 links login information to previously stored user profile information for a user and facilitates entry (e.g., which includes entry or selection) of information indicating a request of the user to buy or sell NFTs. This interaction with users may occur via a website or a native application viewed on a desktop computer, tablet, or a laptop of the user. And in some cases, such interaction occurs via a mobile website viewed on a smart phone, tablet, or other mobile user device, or via a special-purpose native application executing on a smart phone, tablet, or other mobile user device. Facilitating transactions across a variety of devices is expected to make it easier for the user to complete transactions when and where convenient for the user.

[0044] To illustrate an example of the environment in which the utility NFT interface 12 operates, the illustrated embodiment of FIG. 1 includes several components with which the utility NFT interface 12 communicates: mobile user devices 34 and 36; a desk-top user device 38; and external resources 46. Each of these devices communicates with the utility NFT interface 12 via a network 50, such as the Internet or the Internet in combination with various other networks, like local area networks, cellular networks, or personal area networks.

[0045] The mobile user devices 34 and 36 may be smart phones, tablets, gaming devices, or other hand-held networked computing devices having a display, a user input device (e.g., buttons, keys, voice recognition, or a single or multi-touch touchscreen), memory (such as a tangible, machine- readable, non-transitory memory), a network interface, a portable energy source (e.g., a battery), and a processor (a term which, as used herein, includes one or more processors) coupled to each of these components. The memory of the mobile user devices 34 and 36 may store instructions that when executed by the associated processor provide an operating system and various applications, including a web browser 42 and/or a native mobile application 40. The desk-top user device 32 may also include a web browser 44, native applications, and/or other components. In addition, the desktop user device 38 may include a monitor; a keyboard; a mouse; memory; a processor; and a tangible, non- transitory, machine-readable memory storing instructions that when executed by the processor provide an operating system and the web browser (and/or the native applications, etc.). The native application 40 and the web browsers 42 and 44, in some embodiments, are operative to provide a graphical user interface associated with system 10 that communicates with the utility NFT interface 12 and facilitates user interaction with data from the utility NFT interface 12. The web browsers 42 and 44 may be configured to receive a website from the utility NFT interface 12 having data related to instructions (for example, instructions expressed in JavaScript) that when executed by the browser (which is executed by the processor) cause the mobile user device 36 and/or the desktop user device 38 to communicate with the utility NFT interface 12 and facilitate user interaction with data from the utility NFT interface 12. The native application 40 and the web browsers 42 and 44, upon rendering a webpage and/or a graphical user interface from the utility NFT interface 12, may generally be referred to as client applications of the utility NFT interface 12, which in some embodiments may be referred to as a server. Embodiments, however, are not limited to client/server architectures, and the utility NFT interface 12, as illustrated, may include a variety of components other than those functioning primarily as a server. Three user devices are shown, but embodiments are expected to interface with substantially more, with more than 100 concurrent sessions and serving more than 1 million users distributed over a relatively large geographic area, such as a state, the entire United States, or the world.

[0046] External resources 46, in some embodiments, include sources of information such as databases, websites, etc.; external entities participating with the system 10 (e.g., systems or networks associated with system 10), one or more servers outside of the system 10, a network (e.g., the internet), electronic storage, equipment related to Wi-Fi ™ technology, equipment related to Bluetooth® technology, data entry devices, or other resources. In some embodiments, some or all of the functionality attributed herein to external resources 46 may be provided by resources included in the system 10. External resources 46 may be configured to communicate with the utility NFT interface 12, mobile user devices 34 and 36, desktop user device 38, and/or other components of the system 10 via wired and/or wireless connections, via a network (e.g., a local area network and/or the internet), via cellular technology, via Wi-Fi technology, and/or via other resources.

[0047] Thus, the utility NFT interface 12, in some embodiments, operates in the illustrated environment by communicating with several different devices and transmitting instructions to various devices to communicate with one another. The number of illustrated external resources 46, desktop user devices 38, and mobile user devices 36 and 34 is selected for explanatory purposes only, and embodiments are not limited to the specific number of any such devices illustrated by FIG 1, which is not to imply that other descriptions are limiting. [0048] The utility NFT interface 12 includes several components introduced above that facilitate transactions by users. For example, the illustrated API server 26 may be configured to communicate data about users, transactions, permissions, token issuances, and/or other information via a protocol, such as a representational-state-transfer (REST)-based API protocol over hypertext transfer protocol (HTTP) or other protocols. Examples of operations that may be facilitated by the API server 26 include requests to display, link, modify, add, or retrieve portions or all of user profiles, transactions, issue tokens, grant permissions, or other information. API requests may identify which data is to be displayed, linked, modified, added, or retrieved by specifying criteria for identifying records, such as queries for retrieving or processing information about a particular user (e.g., a user’s advertisement preferences as described herein), for example. In some embodiments, the API server 26 communicates with the native application 40 of the mobile user device 34 or other components of the system 10.

[0049] The illustrated web server 28 may be configured to display, link, modify, add, or retrieve portions or all of user profiles, transactions, information about tokens and/token issuances, permissions, or other information encoded in a webpage (e.g. a collection of resources to be rendered by the browser and associated plug-ins, including execution of scripts, such as JavaScript, invoked by the webpage). In some embodiments, the graphical user interface presented by the webpage may include inputs by which the user may enter or select data, such as clickable or touchable display regions or display regions for text input. Such inputs may prompt the browser to request additional data from the web server 28 or transmit data to the web server 28, and the web server 28 may respond to such requests by obtaining the requested data and returning it to the user device or acting upon the transmitted data (e.g., storing posted data or executing posted commands). In some embodiments, the requests are for a new webpage or for data upon which client-side scripts will base changes in the webpage, such as XMLHttpRequest requests for data in a serialized format, e.g. JavaScript object notation (JSON) or extensible markup language (XML). The web server 28 may communicate with web browsers, such as the web browser 42 or 44 executed by user devices 36 or 38. In some embodiments, the webpage is modified by the web server 28 based on the type of user device, e.g., with a mobile webpage having fewer and smaller images and a narrower width being presented to the mobile user device 36, and a larger, more content rich webpage being presented to the desk-top user device 38. An identifier of the type of user device, either mobile or non-mobile, for example, may be encoded in the request for the webpage by the web browser (e.g., as a user agent type in an HTTP header associated with a GET request), and the web server 28 may select the appropriate interface based on this embedded identifier, thereby providing an interface appropriately configured for the specific user device in use. [0050] The illustrated data store 30, in some embodiments, stores data about users, data about transactions associated with users, data about tokens associated with users, data about permissions associated with users, and/or other information. The data store 30 may include various types of data stores, including relational or non-relational databases, document collections, hierarchical key -value pairs, or memory images, for example. Such components may be formed in a single database, document, or the like, or may be stored in separate data structures. In some embodiments, the data store 30 comprises electronic storage media that electronically stores information. The electronic storage media of data store 30 may include one or both of system storage that is provided integrally (i.e., substantially non-removable) with the system 10 and/or removable storage that is removably connectable to the system 10 via, for example, a port (e.g., a USB port, a firewire port, etc.) or a drive (e.g., a disk drive, etc.). The data store 30 may be (in whole or in part) a separate component within the system 10, or the data store 30 may be provided (in whole or in part) integrally with one or more other components of the system 10 (e.g., controller 14, etc.). In some embodiments, the data store 30 may be located in a data center, in a server that is part of external resources 46, in a computing device 34, 36, or 38, or in other locations. The data store 30 may include one or more of optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drive, floppy drive, etc.), electrical charge-based storage media (e.g., EPROM, RAM, etc.), solid-state storage media (e.g., flash drive, etc.), or other electronically readable storage media. The data store 30 may store software algorithms, information determined by the controller 14, information received via the graphical user interface displayed on computing devices 34, 36, and/or 38, information received from external resources 46, or other information accessed by the system 10 to function as described herein.

[0051] FIG. 2 is a diagram that illustrates an exemplary computing system 200 in accordance with embodiments of the present system. Various portions of systems and methods described herein, may include or be executed on one or more computer systems the same as or similar to computing system 200. For example, utility NFT interface 12, mobile user device 34, mobile user device 36, desktop user device 38, external resources 46 and/or other components of the system 10 (FIG. 1) may be and/or include one more computer systems the same as or similar to computing system 200. Further, processes, modules, processor components, and/or other components of the system 10 described herein may be executed by one or more processing systems similar to and/or the same as that of computing system 200.

[0052] Computing system 200 may include one or more processors (e.g., processors 210a-210n) coupled to system memory 220, an input/output I/O device interface 230, and a network interface 240 via an input/output (I/O) interface 250. A processor may include a single processor or a plurality of processors (e.g., distributed processors). A processor may be any suitable processor capable of executing or otherwise performing instructions. A processor may include a central processing unit (CPU) that carries out program instructions to perform the arithmetical, logical, and input/output operations of computing system 200. A processor may execute code (e.g., processor firmware, a protocol stack, a database management system, an operating system, or a combination thereof) that creates an execution environment for program instructions. A processor may include a programmable processor. A processor may include general or special purpose microprocessors. A processor may receive instructions and data from a memory (e.g., system memory 220). Computing system 200 may be a uni-processor system including one processor (e.g., processor 210a), or a multi-processor system including any number of suitable processors (e.g., 210a-210n). Multiple processors may be employed to provide for parallel or sequential execution of one or more portions of the techniques described herein. Processes, such as logic flows, described herein may be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating corresponding output. Processes described herein may be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit). Computing system 200 may include a plurality of computing devices (e.g., distributed computer systems) to implement various processing functions.

[0053] I/O device interface 230 may provide an interface for connection of one or more I/O devices 260 to computer system 200. I/O devices may include devices that receive input (e.g., from a user) or output information (e.g., to a user). I/O devices 260 may include, for example, graphical user interface presented on displays (e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor), pointing devices (e.g., a computer mouse or trackball), keyboards, keypads, touchpads, scanning devices, voice recognition devices, gesture recognition devices, printers, audio speakers, microphones, cameras, or the like. I/O devices 260 may be connected to computer system 200 through a wired or wireless connection. I/O devices 260 may be connected to computer system 200 from a remote location. I/O devices 260 located on remote computer system, for example, may be connected to computer system 200 via a network and network interface 240.

[0054] Network interface 240 may include a network adapter that provides for connection of computer system 200 to a network. Network interface 240 may facilitate data exchange between computer system 200 and other devices connected to the network. Network interface 240 may support wired or wireless communication. The network may include an electronic communication network, such as the Internet, a local area network (LAN), a wide area network (WAN), a cellular communications network, or the like. [0055] System memory 220 may be configured to store program instructions 270 or data 280. Program instructions 270 may be executable by a processor (e.g., one or more of processors 210a- 210n) to implement one or more embodiments of the present techniques. Instructions 270 may include modules and/or components of computer program instructions for implementing one or more techniques described herein with regard to various processing modules and/or components. Program instructions may include a computer program (which in certain forms is known as a program, software, software application, script, or code). A computer program may be written in a programming language, including compiled or interpreted languages, or declarative or procedural languages. A computer program may include a unit suitable for use in a computing environment, including as a stand-alone program, a module, a component, or a subroutine. A computer program may or may not correspond to a fde in a file system. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program may be deployed to be executed on one or more computer processors located locally at one site or distributed across multiple remote sites and interconnected by a communication network.

[0056] System memory 220 may include a tangible program carrier having program instructions stored thereon. A tangible program carrier may include a non-transitory computer readable storage medium. A non-transitory computer readable storage medium may include a machine readable storage device, a machine readable storage substrate, a memory device, or any combination thereof. Non- transitory computer readable storage medium may include non-volatile memory (e.g., flash memory, ROM, PROM, EPROM, EEPROM memory), volatile memory (e.g., random access memory (RAM), static random access memory (SRAM), synchronous dynamic RAM (SDRAM)), bulk storage memory (e.g., CD-ROM and/or DVD-ROM, hard-drives), or the like. System memory 220 may include a non-transitory computer readable storage medium that may have program instructions stored thereon that are executable by a computer processor (e.g., one or more of processors 210a-210n) to cause the subject matter and the functional operations described herein. A memory (e.g., system memory 220) may include a single memory device and/or a plurality of memory devices (e.g., distributed memory devices). Instructions or other program code to provide the functionality described herein may be stored on a tangible, non-transitory computer readable media. In some cases, the entire set of instructions may be stored concurrently on the media, or in some cases, different parts of the instmctions may be stored on the same media at different times, e.g., a copy may be created by writing program code to a first-in-first-out buffer in a network interface, where some of the instructions are pushed out of the buffer before other portions of the instructions are written to the buffer, with all of the instructions residing in memory on the buffer, just not all at the same time. [0057] I/O interface 250 may be configured to coordinate I/O traffic between processors 210a- 210n, system memory 220, network interface 240, I/O devices 260, and/or other peripheral devices. I/O interface 250 may perform protocol, timing, or other data transformations to convert data signals from one component (e.g., system memory 220) into a format suitable for use by another component (e.g., processors 210a-210n). I/O interface 250 may include support for devices attached through various types of peripheral buses, such as a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard.

[0058] Embodiments of the techniques described herein may be implemented using a single instance of computer system 200 or multiple computer systems 200 configured to host different portions or instances of embodiments. Multiple computer systems 200 may provide for parallel or sequential processing/execution of one or more portions of the techniques described herein.

[0059] Those skilled in the art will appreciate that computer system 200 is merely illustrative and is not intended to limit the scope of the techniques described herein. Computer system 200 may include any combination of devices or software that may perform or otherwise provide for the performance of the techniques described herein. For example, computer system 200 may include or be a combination of a cloud-computing system, a data center, a server rack, a server, a virtual server, a desktop computer, a laptop computer, a tablet computer, a server device, a client device, a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a vehicle-mounted computer, a television or device connected to a television (e.g., Apple TV ™), or a Global Positioning System (GPS), or the like. Computer system 200 may also be connected to other devices that are not illustrated or may operate as a stand-alone system. In addition, the functionality provided by the illustrated components may in some embodiments be combined in fewer components or distributed in additional components. Similarly, in some embodiments, the functionality of some of the illustrated components may not be provided or other additional functionality may be available.

[0060] Those skilled in the art will also appreciate that while various items are illustrated as being stored in memory or on storage while being used, these items or portions of them may be transferred between memory and other storage devices for purposes of memory management and data integrity. Alternatively, in other embodiments some or all of the software components may execute in memory on another device and communicate with the illustrated computer system via inter-computer communication. Some or all the system components or data structures may also be stored (e.g., as instructions or structured data) on a computer-accessible medium or a portable article to be read by an appropriate drive, various examples of which are described above. In some embodiments, instructions stored on a computer-accessible medium separate from computer system 200 may be transmitted to computer system 200 via transmission media or signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as a network or a wireless link. Various embodiments may further include receiving, sending, or storing instructions or data implemented in accordance with the foregoing description upon a computer-accessible medium. Accordingly, the present invention may be practiced with other computer system configurations.

Role Based Access Control (RBAC) for NFTs

[0061] Utility NFT interface 12 is configured to provide a role-based access control (RBAC) system for NFTs. RBAC is a generalizable system that grants configurable rights to a single specific token holder who can then create, assign, revoke and otherwise manage permission sets and roles to other token holders.

[0062] Utility NFT interface 12 is configured for creating an online community comprised of token holders and granting the owner role to the token holder of token zero. Every contract is created with an owner role that has permissions to create roles, create permissions, grant roles, grant permissions, delete roles, delete permissions. For example, the token zero holder can create roles such as moderators, create permissions such as a chat feature, create role and permission structure such as enabling moderators to chat, granting roles such as letting Larry be a moderator, and revoking roles such as rescinding Larry from the moderator role. The token zero holder also holds configuration rights including rights for creating a hierarchy and structure of the online community, rights for creating rules of the online community, and rights for posting messages to a content feed viewable by the token holders. The configuration rights of the token zero holder are not limited to these. For example, other possible configuration rights include choosing the aesthetic of the online community, such as the background design and the font. Another example could be setting up chat rooms for the token holders to converse. In essence, the token zero holder is free to change the online community’s user interface and rules in any way they see fit. Further, the role set and permission set are completely configurable so that the roles can be used as a system in any application. Furthermore, an individual token held by a token holder is verifiable via the blockchain. Utility NFT interface 12 is configured such that the contents of the tokens reside on the blockchain (e.g., a blockchain server or servers, or other distributed public ledger).

[0063] Utility NFT interface 12 is configured such that when ownership of token zero is transferred, the configuration rights will remain with the new owner of token zero. Similarly, when ownership of a token assigned to the moderator role is transferred, the moderator role will be revoked from that token. Token holders may be evaluated before receiving a moderator role, so when a new token holder acquires a token with a moderator role, that role should be revoked. Moderator roles can be created and destroyed as needed.

[0064] In an embodiment, the rights for managing roles, permissions, and responsibilities of the token holders in the online community comprise assigning roles and revoking roles of the token holders. Assigning and revoking roles include roles for moderators, permissions to post messages, and other roles for the online community, for example.

[0065] By way of further explanation, NFT collections represent decentralized communities of token holders that often share a core ethos. Within this community, there is no formalized way to create a hierarchy or structure, enable different permissions, moderate, create and distribute content, or any other formalized system to enable community management. An example community might be something like a musician and their fans. In this community, the artist can distribute exclusive music to their fans. They should also be able to promote moderators to be able to monitor their fans to ensure that they are behaving within the parameters of the artist’s community. Within an artist’s community of token holders, there needs to be a way for the artist to create roles and permission structures for the token holders to manage their rights, permissions, and responsibilities.

[0066] Utility NFT interface 12 is configured such that each solidity contract created that contains this RBAC system contains a single configurable contract owner token — referred to as “token zero,” although the actual number of the token can be configurable to any number. Utility NFT interface 12 is configured such that the owner of token zero maintains the rights to create, manage, assign, and revoke roles that grant other token holders arbitrary permissions. A permission can be anything, like “can moderate chat,” which would grant the token holder the ability to moderate a chat room. Once assigned a role, the token holder then will have that role and all the appropriate permissions appear in their token metadata for applications to read, interpret, and use.

[0067] Utility NFT interface 12 is configured such that each RBAC solidity contract contains a ownerTokenNumber variable in it that defines the token number that grants owner permissions over the community. By default, this is set to 0. Each RBAC solidity contract also contains a rbacManagementUri variable in it that defines an endpoint to manage roles and permissions, and a rbacTokenManagementUri function in it that returns an endpoint to manage users’ roles.

[0068] Utility NFT interface 12 is configured such that, by default, when the contract is deployed the first token that is minted has ownership over all the roles and permissions. This token also gets all permissions assigned to them.

[0069] In some embodiments, the contract owner or a designee of the contract owner is minted the first token by utility NFT interface 12 as soon as the contract is deployed granting them ownership role over the token. The ownership role also grants them rights to the following permissions (among other possible permissions) “can manage roles,” “can_manage_permissions,” and “can manage token holders.” With these permissions, the contract owner can interact with the rbacManagementUri and the rbacTokenManagementUri to manage permissions, manage roles, assign permissions to roles, and assign roles to users.

[0070] Utility NFT interface 12 is configured such that token zero can be traded or transferred like any other token. Transferring this token also transfers the RBAC rights and responsibilities.

[0071] FIG. 3 shows a flowchart 300 for using the RBAC protocol. At 310, the system 10 creates an online community comprised of token holders. At 320, the system 10 grants configuration rights to the token holder of token zero, which can include the right to grant permissions to other users, and/or other rights as described herein.

[0072] A permission consists of a code and a description. The code is a logical key that can be used to look the description up. It is no more than 50 characters, lowercase, and underscore delimited, like “can moderate chat.” The description is a variable length text-based description that describes the rights and responsibilities that the permission grants. For example, the description could state, “Enables the user to moderate chat including deleting messages, timing users out, banning users, etc.” Permissions should be structured with “can ” verbiage as opposed to “cannot ” verbiage.

[0073] Permissions do not need to be assigned to roles and can be created and destroyed on their own. Permissions are the building blocks of functionality. Permissions can be stored on-chain in contract or off-chain depending on contract requirements. Managing permissions is done through a REST API that can be accessed by the token zero holder.

[0074] Utility NFT interface 12 is configured such that a role comprises a name and a revocation policy. The name is a logical key and a description. The name is unique and case sensitive to avoid confusion. An example role is something like “Moderator.” Roles can be assigned any number of permissions. For example, a “Moderator” role might include the “can moderate chat” permission. The revocation policy determines whether a role should be revoked when the token is transferred. For instance, a “Moderator” role revocation policy would be “on-all-transfers” so that when moderators transfer tokens the role is revoked from that token. The other revocation policies are “never” for Token Zero and “on-management” for a role that is transferrable.

[0075] Roles can be stored on-chain in contract or off-chain depending on contract requirements. In some embodiments, managing roles is performed by utility NFT interface 12 (Fig. 1) through a REST API that can be accessed by the token zero holder. Roles can be assigned to any existing token and can be revoked from any existing token. Role assignment comprises the coupling between a token ID and a role key. For example, a role such as “community postef’ can be created. Then a permission set is created to have the following capabilities: “can post videos” and “can post images.” Thereafter, the permission can be tied to the role such that community posters can now post videos and images. After this is set up, the role can be granted to Mikayla and Abby ; Mikayla and Abby are now community posters. As a result, the token ID of Mikayla and Abby are coupled to the community poster role key. Later on, the community poster role can be revoked from Mikayla; the role key will no longer be connected to her token ID. Role assignment is stored in a list that resembles the following:

Token ?: [Moderator]

[0076] Roles can be revoked based on the Transfer event if they are marked to be revoked on transfer, or they can be revoked by the token zero holder otherwise.

[0077] Applications can interact with the roles through the token metadata or through the rbacTokenManagementUri.

[0078] Both uri’s are open for public access and return the following data stmcture that defines the token holders’ roles and permissions.

[0079] {

“permissions”: [{ “code”: “can moderate chat”, “description”: “Enables the user to moderate chat including deleting messages, timing users out, banning users, etc.”. }]

“roles”: [{ “name”: “Moderator”, “revocation-policy”: “on-all-transfers” }] }

[0080] Applications can use this information as needed.

[0081] Utility NFT interface 12 may be configured such that there are two types of management interfaces, depending on the type of RBAC implementation. For on-chain solutions utility NFT interface 12 may be configured such that the token zero holder can interact with the following functions written into the solidity contract (these are examples, other functions may be possible): createPermission deletePermission updatePermission createRole deleteRole updateRole addRolePermissions removeRolePermissions assignRole revokeRole

[0082] For off-chain solutions utility NFT interface 12 may be configured such that the token zero owner can authorize with a REST API using a signed transaction to prove ownership over the wallet. After proving ownership, an access token is granted to the user and they have access to a REST API that models the above functions and manages the same data in a database. Example routes are as follows:

POST /contract/) contract address }/rbac/permission

PATCH /contract/{contract_address}/rbac/permission/{permission_name} DELETE /contract/{contract_address}/rbac/permission/{permission_name}

POST /contract/{contract_address}/rbac/role

PATCH /contract/) contract address }/rbac/role/{ role name } DELETE /contract/) contract address }/rbac/role/{ role name } PATCH /contract/)contract_address}/rbac/role/)role_name}/permissions/add PATCH /contract/) contract_address}/rbac/role/)role_name}/permissions/remove

POST /contract/)contract_address}/rbac/token/)tokenld}/assign/)role_name} REVOKE /contract/) contract address }/rbac/token/{ tokenld }/assign/{ role name }

Secure Wallet Authorization Protocol (SWAP) for NFTs

[0083] Utility NFT interface 12 (Fig. 1) is configured to effectuate operations for a digital wallet for storing a plurality of tokens of a wallet owner on a server, a secure wallet authorization protocol (SWAP), for example. SWAP may provide various privacy, security, portability, and/or other advantages compared to prior systems. For example, SWAP may provide a zero knowledge (ZK) method that enables a user to send a fact to a third party (e.g., website) without other parts of their identity being compromised, including but not limited to other identifiers like wallet identifiers or user identifications, biometrics, and/or other facts or attributes about themselves. The ZK method may be fully traceable or trackable such that applicable data (e.g., connections between transactions) may be provided to an auditor, for example.

[0084] SWAP is configured to hide permanent record information behind a federated service so that a user never has the permanent record information on a device or computer (e.g., a smartphone, a laptop, etc.) to lose. SWAP can be run as a federated module anywhere. It can be user owned so the user has control over their own data, or SWAP can be run by a third party service provider. Because the source data is blockchain, SWAP instances are interoperable and share the same source data as well, allowing users to use any instance.

[0085] In some embodiments, SWAP may be configured to use single use wallets that store tagged tokens that represent generalizable and documented facts. In these instances, wallets can be audited to verify the facts source data without , but will not compromise other user information. SWAP can also be run using ZK proofs and other best practices configured to prevent compromising a single use wallet address. However, this may disable some of the benefits which provide auditability and traceability with some facts. For example, if a user has a valid driver's license, SWAP may be used with a ZK proof to prove the existence of the driver’s license. But to provide auditability, SWAP can be configured to provide a single use wallet that can trace the history of that particular driver’s license.

[0086] SWAP may be configured to tie the single use wallets together with a changeable private pseudonym to continue to protect and obscure use data. In addition, SWAP is configured to enable levels of encryption around individualized user data that have different levels of usability and security. For example, a highest level of security may require passphrases from an end user along with two factor authentication and server side keys to decrypt factual data (but making recovery more challenging). A lowest level of security may require only server side keys (but making recovery easier.)

[0087] To implement SWAP (and provide the various advantages described above) utility NFT interface 12 (Fig. 1) is configured to effectuate operations including requesting approval from the wallet owner for a specific token or that token’s metadata. Upon receiving approval from the wallet owner, utility NFT interface 12 facilitates receiving an authorization grant code. The authorization grant code is presented to a wallet access server. An access token is received along with the specific token or token metadata from the wallet access server. Utility NFT interface 12 and the SWAP is configured such that only the specific token or token metadata and nothing else is shared. The access token is presented to the wallet access server to request permitted resources. Thereafter, the permitted resources are received from the wallet access server. Utility NFT interface 12 is configured such that the token is verifiable via the blockchain.

[0088] Note that utility NFT interface 12 may be configured such that the application does not have access to the token ID. In other words, the application does not have permission to see the token data. In an embodiment, the application does not have access to the wallet address. In other words, the application does not have permission to see the contents of the digital wallet. In an embodiment, the access token can be used by the application to interact with the specific token metadata until the access token is revoked by the wallet owner. Utility NFT interface 12 is configured such that the application has continued access to the specific token metadata until that access is denied by the wallet owner.

[0089] By way of further explanation, utility NFT interface 12 is configured such that the SWAP protocol enables a third-party application to obtain limited access to an HTTP service on behalf of a wallet owner to facilitate reading and interacting with scoped token metadata and actions without compromising the wallet address.

[0090] Wallets contain the tokens that a user owns. By identifying the person that owns a wallet one can learn a lot of information about the user without their consent, including but not limited to places they have visited, brands they are interested in, social status, general wealth, and much more. As wallets are filled with more and more assets, they will be used to construct more elaborate profiles of people and infringe more on privacy rights. Ownership of tokens informs third parties about a user’s otherwise private preferences. As a result, third parties should only have access to selective tokens in the digital wallet under the user’s consent.

[0091] SWAP, as facilitated by utility NFT interface 12, is a protocol that allows an application to request that a user authorizes access to view individualized metadata about tokens from their wallet without ever gaining access to the token ID, the contract address, or the wallet address. These pieces of information can be used to uniquely identify the user and extract the rest of the information from their wallet, thereby invading their privacy.

[0092] An example use case for SWAP could be an application requiring checking if the end user holds a token in their wallet that grants them access to a virtual concert. Normally, this problem is solved by the application being provided a signed transaction that proves a user owns a wallet address. Once the user proves ownership over the wallet, they can look in the wallet, find an appropriate token, and verify they are allowed in. Instead, SWAP enables the application to ask the user, “Will you attend this event?” The user can then consent to answering the question without sending contract addresses, wallet addresses, or token IDs to the application. Using SWAP, a user can send a fact (e.g., token metadata in this example) to a third party (e.g., a website associated with the virtual concert) without other parts of their identity being compromised, including but not limited to other identifiers like wallet identifiers or user identifications, biometrics, and/or other facts or attributes about themselves that might be stored in the digital wallet.

[0093] FIG. 4 shows an example of a digital wallet 400. Tokens X, Y, and Z are owned by the wallet owner and stored in their digital wallet 400. Now, for example, a third-party application wants access to Token Y, which is for the virtual concert. Upon authorization by the wallet owner, utility NFT interface 12 (Fig. 1) and the SWAP protocol are configured such that, instead of showing everything in one’s digital wallet, including Tokens X, Y, and Z, only the metadata of Token Y will be accessible to the third-party application. As a result, the third-party application will know that the wallet owner is attending the virtual concert but will not be privy to the contents of Tokens X or Z, or even the contents of Token Y. Only Token Y metadata is passed on to the third-party application. [0094] FIG. 5 shows an example of how a SWAP protocol 500 is implemented (e.g., by utility NFT interface 12). At (A), a requesting third-party application 501 makes a request to a wallet owner 502 asking for a specific set of information scoped to their application needs and benefits. Then at (B), the wallet owner 502 is presented a screen that notifies them of the information held within the scoped request. On approval, a short-lived authorization grant code is created and passed back to the application 501. Continuing to (C), the application 501 then uses the grant code to request scoped information and an access token from a wallet access server 503. At (D), the wallet access server 503 responds with metadata about the tokens of the wallet owner 502 as well as sends a scoped access token that can be used for future requests about those resources. Next at (E), the application 501 can use the scoped access token to request permitted resources. At (F), the wallet access server 503 accepts requests with scoped access tokens and creates, updates, or modifies appropriate data. [0095] Scopes are filterable identifiers that are identified by the third-party application and issued to the wallet owner when requesting information. Scopes include higher level projects that map to an array of contract addresses, individual contract addresses, as well as specific benefits or permissions. An example scope would be translated to: “The application server is requesting permission to read information and send chat messages about tickets to a Steve Aoki concert on December 12, 2022.” [0096] An authorization grant is the credentialed access submitted by a wallet owner to the wallet access server to prove that they own the wallet in question. The proof is accomplished by signing a transaction with the wallet owner’s private key and verified with the wallet owner’s public key. Once the proof is obtained, an access token is established between the wallet access server and the wallet owner that persists the authorization for that user to the wallet.

[0097] An authorization code is created by a wallet access server and distributed to third-party applications on directive of the wallet owner. An application first requests a scoped authorization code. After authorizing with the wallet access server, the wallet owner approves the authorization code, and the access server sends it to the third-party application. This access code is then used to establish a scoped access token between the application and the wallet access server.

[0098] An example of the aforementioned permitted resources follows. A musician can work with a third-party ticketing platform to offer free tickets to owners of a certain NFT. The token holder would then go to the third-party ticketing platform and connects their wallet to verify ownership of that NFT. Thereafter, SWAP validates ownership and passes authentication back to the ticketing platform without disclosing the wallet address. Finally, the ticket is granted. In this case, the permitted resources would be validating ownership of the NFT.

[0099] Access tokens are used by third-party applications to issue requests to wallet access servers on the wallet owner’s behalf. Access tokens can be revoked from the wallet access servers by the wallet owner to remove access from the third-party application. [00100] As described above, SWAP is configured to hide permanent record information behind a federated service so that a user never has the permanent record information on a device or computer (e.g., a smartphone, a laptop, etc.) to lose. The “blockchain dream” is about trusted interoperable decentralized data that can be accessed by anyone. A federated architecture is a loosely coupled cooperating set of services. So in this case, SWAP is a federated service that fosters the transfer of a decentralized fact from one service to another without compromising the user’s information. A real world example of this could be like a vaccination card. There may be an asserter of the fact (the administrator of the vaccine), there may be people that care about the fact (e.g., a school or other organization) and there is a federated service that sits in between to facilitate the transfer (e.g., a...piece of paper). SWAP is in the place of that paper, except it controls the information more tightly so a date of birth or any other vital information is not leaked. SWAP can be run as a federated module anywhere (e.g., on a server and/or some other computing device). It can be user controlled so the user has control over their own data, or SWAP can be run by a service. It can also be moved. Being able to be moved means that any instance of SWAP can facilitate the transfer of these facts. It is an interoperable layer that leverages decentralized data on the blockchain, so anyone can run it - e.g., Google could run a server that facilitates SWAP, or Amazon, or a user, etc. Doing some things on one federated provider does not mean SWAP is beholden to that federated provider. If a user decides they no longer trust that provider to facilitate this exchange of information, the provider may be changed.

[00101] In some embodiments, SWAP may be configured to use single use wallets to store facts so that the wallets can be audited, but will not compromise other user information. A single use wallet is the same as every other wallet. However, most wallets hold lots of things from currency to tokens and have long histories of transactions. These single use wallets are created, a token is added, and then they are never used again or tied to anything else. This is so that the history of that token can be tracked in isolation. With the example of a driver’s license the wallet contains the entire history of that one particular event and nothing else (thus providing traceability and privacy). In these examples, the token also points to an array of encrypted documents and holds a list of users that are allowed to access those documents, so people and companies (like a driver’s license owner or the DMV) can grant temporary access to others so that they can access, decrypt, and audit the supporting documentation. This enables government agencies to further inspect things that have been asserted as facts to verify their accuracy.

[00102] SWAP can also be run using ZK proofs and other best practices configured to prevent compromising a single use wallet address. ZK proofs concern proving a fact without conveying any information about that fact. So in the example of vaccinations, the general idea is that a challenger, say a first entity in this example, can ask a user effectively something only a holder of that information would be able to answer. Then, the user uses their vaccination/medical record to create a response to that challenge. And the first entity, trusting all of the advanced complicated cryptographic algorithms utilized here, trust the response is valid without seeing the proof. However, this may disable some of the benefits which provide auditability and traceability with some facts. For example, if a user has a valid driver's license, SWAP may be used with a ZK proof to prove the existence of the driver’s license. But to provide auditability, SWAP can be configured to provide a single use wallet that can trace the history of that particular driver’s license.

[00103] SWAP may be configured to tie the single use wallets together with a changeable private pseudonym to continue to protect and obscure use data. In this case, a single use wallet encompasses all of the information about one thing, like a driver’s license and all of the related facts. On the blockchain, that wallet is never tied in any way to any other transaction, so it is not publicly discoverable who the owner of that wallet is. The federated module then stores a pseudonym for the real user that only they know and that can be changed at any point in time. This means that in order for a snooper/attacker to create an entire history for a person, they would have to hack the federated module in three different ways (and possibly steal the persons phone and their password) - purposely not committed to writing here - to gather all of the wallet addresses to compose a complete history of publicly viewable statements about that person. In addition, SWAP is configured to enable levels of encryption around individualized user data that have different levels of usability and security. For example, a highest level of security may require passphrases from an end user along with two factor authentication and server side keys to decrypt factual data (but making recovery more challenging). A lowest level of security may require only server side keys (but making recovery easier.)

Generalizable Communication Protocol for NFTs

[00104] Returning to Fig. 1, in some embodiments, utility NFT interface 12 is configured effectuate operations for a generalizable communication protocol for NFTs. For example, a digital wallet for storing a plurality of tokens of a wallet owner on a server may exist (and/or be provided by utility NFT interface 12). Utility NFT interface 12 may be configured to facilitate creating an online community comprised of token holders, communicating general messages and announcements with the token holders, communicating VIP messages with only VIP token holders and not non- VIP token holders, communicating directly with individual token holders, and/or other operations. Utility NFT interface 12 may be configured such that the communication of messages and announcements is provided over a content feed. Communicating directly with individual token holders can be done on the content feed or through private messaging. Additionally, an individual token held by a token holder is verifiable via the blockchain. Also, a subset of all the token holders is the VIP token holders. Utility NFT interface 12 may be configured such that VIP token holders are any token holders that have subscribed to exclusive VIP content. Utility NFT interface 12 may be configured such that a general token holder can become a VIP token holder at any time by enrolling in a VIP subscription. [00105] In an embodiment, utility NFT interface 12 may be configured such that messages can be sent to groups of token holders based on attributes or other qualities of tokens. Any attributes can be chosen, such as interest in a certain member of the band or interest in band apparel. For example, utility NFT interface 12 may be configured such that token holders on Team Garrett will receive messages from Garrett, while those who are on Team Felix will receive messages from or about Felix. Further, those who are interested in band apparel will receive messages to purchase the newest merchandise from the band.

[00106] In an embodiment, the messages and the announcements can be permanent or temporary. In general, the messages are permanent, and the announcements are temporary, but this is not limiting. Either can be permanent or temporary. In an embodiment, each message contains an author, a timestamp, and rich body content that can include text, images, video, and links.

[00107] By way of further explanation, utility NFT interface 12 is configured such that the generalizable communication protocol is a mechanism to include any NFT in a communication protocol that allows the contract owner to disseminate information to the token holders that can either be direct messages to different groups of token holders or messages to all users. As stated above, NFT collections represent decentralized communities of token holders that often share a core ethos. Within this community, there is no formalized way to communicate or distribute information. Much of the infrastructure being built up around NFTs relies on loose integration with Discord channels and gated access to other sites.

[00108] Examples of the token-based communication needs might include brands connecting with opt-in followers to receive marketing notifications, events pushing live notifications to attendees to inform them of changes, and musicians releasing new content to an exclusive group of fans.

[00109] Each solidity contract created that contains this communication protocol enables the owner of the contract owner token to distribute transient and permanent information. The messages that go through the communication protocol can be broadcast to the entire community or it can be broadcast to a group filtered by specific tokens, specific attributes, or specific roles.

[00110] Each token holder has authorized gated access to a searchable list of messages that have been sent to them by the token zero holder or other permission enabled users. The content feed contains all permanent information messages and relevant temporary information announcements. Each message contains an author, a timestamp, and rich body content that can include text, images, video, and links.

[00111] Announcements are time expiring messages that can be distributed over a push style notification to token holders. Announcements will also show up in the feed but for a configurable amount of time decided by the author before they will expire. Announcements are restricted to just text.

[00112] Messages are added to the content feed and short push notifications of the messages are sent to users based on preferences. Messages can be sent to all token holders, token holders filtered by attributes, or directly to individual tokens.

[00113] For example, FIGS. 6A-6C show the content feed of different types of token holders. FIG. 6A shows the content feed 600A of the token zero holder. FIG. 6B shows the content feed 600B of a VIP token holder content feed. FIG. 6C shows the content feed 600C of a regular token holder. As shown in FIG. 6A, the token zero holder receives all messages and announcements, including VIP messages 601, general messages 602, announcements 603, and marketing notifications 604. Announcements can come with a note indicating when they will expire. In this case, announcement 603 will expire in 10 hours. All token holders will receive general messages 602 as well as announcements 603. However, only VIP token holders will receive VIP messages 601, as seen in FIG. 6B. A regular token holder only receives general messages 602 and announcements 603. In this example, neither the VIP token holder nor the regular token holder receives the marketing notifications 604, because neither has subscribed to the marketing notifications 604. The messages and announcements can appear chronologically in the content feeds, with the oldest at the top and the newest at the bottom. When the messages fill up the entire screen, then older messages will not be seen, but a scrollbar can be used to view the older messages.

[00114] The content feed for token holders can be displayed on a phone but can also be displayed on a computer, tablet, watch, or any other device that can be connected to the blockchain server.

[00115] FIG. 7 shows a flowchart 700 for using the generalizable communication protocol. At 710, the system 10 creates an online community comprised of token holders. At 720, the system 10 communicates general messages and announcements with all the token holders. At 730, the system 10 communicates VIP messages with only VIP token holders and not non- VIP token holders. At 740, the system 10 communicates directly with individual token holders.

[00116] Utility NFT interface 12 (Fig. 1) may be configured such that the ability to send messages to token holders is restricted to those that hold the permissions “can send announcements” and “can send messages.” These permissions are owned by the contract owner and can also be assigned to various roles and granted to different token holders. All of this can be done using the token’s RBAC permission system. [00117] Messages can be sent and managed through a REST API using the following endpoint: POST /contract/{contract_address}/message { type: text: context: [{ }, {}, {}], attachments: [], filter: { tokens: [], attributes: [] }}

DELETE /contract/{contract_address}/message/{id}

[00118] Applications may use the communication protocol by first allowing a user to authenticate using the Secure Wallet Authorization Protocol (SWAP). Once authenticated, the application will have an access token that they can use to send or receive messages for contracts and tokens within the authorized scopes.

[00119] While specific embodiments of the invention have been described above, it will be appreciated that the invention may be practiced otherwise than as described. The description is not intended to limit the invention.

[00120] It is to be appreciated that the Detailed Description section, and not the Summary and Abstract sections, is intended to be used to interpret the claims. The Summary and Abstract sections may set forth one or more but not all exemplary embodiments of the present invention as contemplated by the inventor(s), and thus, are not intended to limit the present invention and the appended claims in any way.

[00121] The present invention has been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed.

[00122] The foregoing description of the specific embodiments will so fully reveal the general nature of the invention that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present invention. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein.

[00123] The breadth and scope of the present invention should not be limited by any of the abovedescribed exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

WHAT IS CLAIMED IS:

1. A tangible, non-transitory, machine-readable medium storing instructions of an application that when executed by one or more processors effectuate operations for a digital wallet for storing a plurality of tokens of a wallet owner on a server, the operations comprising: requesting approval from the wallet owner for a specific token’s metadata within the digital wallet, wherein a token is verifiable via the blockchain; upon receiving approval from the wallet owner, receiving an authorization grant code; presenting the authorization grant code to a wallet access server; receiving an access token and the specific token metadata from the wallet access server, wherein only the specific token metadata and no other token metadata is received from the digital wallet of the wallet owner; presenting the access token to the wallet access server to request permitted resources; and receiving the permitted resources from the wallet access server.

2. The machine-readable medium of claim 1, wherein the server is a blockchain server.

3. The machine-readable medium of claim 1, wherein the application does not have access to the token ID.

4. The machine-readable medium of claim 1, wherein the application does not have access to the wallet address.

5. The machine-readable medium of claim 1, wherein the access token can be used by the application to interact with the specific token metadata until the access token is revoked by the wallet owner.

6. The machine-readable medium of claim 1, wherein the user can grant access to the specific token and/or the specific token’s metadata without granting access to any other data associated with the digital wallet, the other data comprising identity data, biometrics, a wallet identifier, and/or wallet owner attributes.

7. The machine-readable medium of claim 6, wherein the other data is hidden behind a federated service.

8. The machine-readable medium of claim 6, wherein encryption around the other data is adjustable, comprising different levels of individualized user data that have different levels of usability and security.

9. The machine-readable medium of claim 1, wherein the digital wallet comprises a single use wallet, and wherein the single use wallet is associated with a changeable private pseudonym.

10. The machine-readable medium of claim 1, the operations comprising a zero knowledge (ZK) method.

11. A tangible, non-transitory, machine-readable medium storing instructions on a server that when executed by one or more processors effectuate operations, the operations comprising: creating an online community comprised of token holders, wherein an individual token held by a token holder is verifiable via the blockchain; communicating general messages and announcements with all the token holders; communicating VIP messages with only VIP token holders and not non- VIP token holders, wherein a subset of all the token holders is the VIP token holders; communicating directly with individual token holders; wherein the communication of messages and announcements is provided over a content feed.

12. The machine-readable medium of claim 11, wherein the server is a blockchain server.

13. The machine-readable medium of claim 11, wherein messages can be sent to groups of token holders based on attributes or other qualities of tokens.

14. The machine-readable medium of claim 11, wherein the messages and the announcements can be permanent or temporary.

15. The machine-readable medium of claim 11, wherein each message contains an author, a timestamp, and rich body content that can include text, images, video, and links.

16. A tangible, non-transitory, machine-readable medium storing instructions on a server that when executed by one or more processors effectuate operations, the operations comprising: creating an online community comprised of token holders, wherein an individual token held by a token holder is verifiable via the blockchain; and granting configuration rights to the token holder of token zero, wherein the configuration rights comprise: rights for creating a hierarchy and structure of the online community; rights for creating rules of the online community; rights for managing roles, permissions, and responsibilities of the token holders in the online community; rights for promoting certain token holders to moderator roles to monitor the token holders to ensure they are adhering to the rules of the online community; and rights for posting messages to a content feed viewable by the token holders.

17. The machine-readable medium of claim 16, wherein the server is a blockchain server.

18. The machine-readable medium of claim 16, wherein when ownership of token zero is transferred, the configuration rights will remain with the new owner of token zero.

19. The machine-readable medium of claim 16, wherein when ownership of a token assigned to the moderator role is transferred, the moderator role will be revoked from that token.

20. The machine-readable medium of claim 16, wherein the rights for managing roles, permissions, and responsibilities of the token holders in the online community comprise assigning roles and revoking roles of the token holders.