WO2022261147A1

WO2022261147A1 - Token-based asset administration

Info

Publication number: WO2022261147A1
Application number: PCT/US2022/032574
Authority: WO
Inventors: Timothy Nielsen; Stanisalv SYNKO
Original assignee: Ubp Llc
Priority date: 2021-06-07
Filing date: 2022-06-07
Publication date: 2022-12-15

Abstract

In a non-fungible token (NFT) based CloutCard system, a purchaser of a CloutCard (cCard) also receives a "secret" based on user-identifying information. The owner of the cCard may transfer the cCard, on demand, simply by presenting user-identifying information and the secret. Thus, a prospective token purchaser has immediate exclusive and secure control over tokens without the need for a hardware or software wallet. A smart contract may be utilized to maintain custody of cCards.

Description

TOKEN-BASED ASSET ADMINISTRATION CROSS-REFERENCE TO RELATED APPLICATION [0001] The present application claims the benefit of priority to U.S. Provisional Patent

Application No. 63/197.804, filed June 7, 2021, which is hereby incorporated by reference in its entirety.

FIELD OF THE INVENTION

[0002] The present disclosure generally relates to fungible and non-fungible tokens, and more specifically to token-based systems and methods for generating, administering, and maintaining fungible and non-fungible tokens.

BACKGROUND

[0003] Traditional non-fungible token (NFT) platforms require purchasers to establish hardware or software wallets in order to receive custody of purchased tokens, which may be cumbersome to establish. Moreover, this requirement typically limits prospective purchasers to only those willing to hold and maintain custody of their tokens in this manner.

[0004] Additionally, current NFT platforms lack an effective way to inventory, sell, transfer, track, and otherwise make tangible, intangible social benefits. In other words, aside from selling traditional event or concert tickets, influencers, musicians, artists, athletes, and other individuals and entities have no effective way to reduce physical interaction (i.e., either via real world and virtual interactions) with fans, customers, or clients to an alienable, redeemable, trackable form. While traditional event tickets may work for large events, these tickets are ineffective when it comes to monetizing, transferring, and tracking smaller engagement events (e.g., micro-engagements). For example, a micro-engagement may include a musician agreeing to meet and have lunch with a small select group of fans while in town for a concert. Typically, the artist’s concert may be associated with tickets that provide access to the concert; however, the micro-engagement that the artist wants to sell may not have associated tickets. The artist may want to directly monetize the micro-engagements rather than connect them to the existing ticket for the larger event.

[0005] Additionally, in connection with the sale of an artist’s digital tokens, the artist may wish to offer to sell or give away some tangible piece of property, such as a T-shirt or sticker which is exclusive to the purchasers or holders of that artist’s digital tokens. Unfortunately, artists currently have no integrated way to track and administer the inventory of that right to redeem the tangible property or sendee (e.g., a fan meet and greet) associated with the digital token, which entitles its holder to such benefit and may be traded between subsequent purchasers. Moreover, the party offering a certain benefit associated with a digital token (or fraction of a digital token) may not know how many times that specific benefit has been “redeemed” and may have to repeatedly (or even perpetually) honor that benefit.

SUMMARY

[0006] In one or more cases, a computer-implemented method of generating and assigning a cryptographic digital asset is provided. In one or more cases, the computer- implemented method includes generating a token identifier of the cryptographic digital asset. In one or more cases, the computer- implemented method includes receiving a request to purchase the cryptographic digital asset, in which the request includes an identifier of a purchaser. In one or more cases, the computer-implemented method includes performing a first hashing function on the purchaser identifier to generate a hash of the purchaser identifier. In one or more cases, the computer-implemented method includes generating a seed value of a randomly generated secret. In one or more cases, the computer-implemented method includes performing a second hashing function on the seed value to generate a hash of the randomly generated secret. In one or more cases, the computer-implemented method includes generating a transfer hash comprising the hash of the purchaser identifier and the hash of the randomly generated secret. In one or more cases, the computer-implemented method includes transmitting the transfer hash and the token identifier of the cryptographic digital asset to a blockchain, in which the transfer hash and the token identifier are associated such that the purchaser is established as the owner of the cryptographic digital asset.

[0007] In one or more cases, a decentralized computing system for generating and assigning a cryptographic digital asset is provided. In one or more cases, the decentralized computing system includes a network having a memory and a processor. In one or more cases, the decentralized computing system is configured to generate a token identifier of the cryptographic digital asset. In one or more cases, the decentralized computing system is configured to receive a request to purchase the cryptographic digital asset, in which the request includes an identifier of a purchaser. In one or more cases, the decentralized computing system is configured to perform a first hashing function on the purchaser identifier to generate a hash of the purchaser identifier. In one or more cases, the decentralized computing system is configured to generate a seed value of a randomly generated secret. In one or more cases, the decentralized computing system is configured to perform a second hashing function on the seed value to generate a hash of the randomly generated secret. In one or more cases, the decentralized computing system is configured to generate a transfer hash comprising the hash of the purchaser identifier and the hash of the randomly generated secret. In one or more cases, the decentralized computing system is configured to transmit the transfer hash and the token identifier of the cryptographic digital asset to a blockchain, in which the transfer hash and the token identifier are associated such that the purchaser is established as the owner of the cryptographic digital asset. [0008] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure, as claimed. Further, the accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate aspects of the present disclosure and together with the description, serve to explain principles of the disclosed embodiments as set forth in the accompanying claims.

BRIEF DESCRIPTION OF THE DRAWINGS [0009] FIGs. 1A-1B illustrate a front side and a back side of an example cCard.

[0010] FIGs. 2A-2C illustrate various views of another example cCard.

[0011] FIG. 3 illustrates example cCard tier-based benefits associated with a musician.

[0012] FIG. 4 illustrates example cCard benefits associated with a gym owner or fighter.

[0013] FIG. 5 is a block diagram of an example cCard system.

[0014] FIG. 6 is a flow diagram depicting an example method for generating a cCard.

[0015] FIG. 7 is block diagram of a system for generating a cCard.

[0016] FIG. 8 is a flow diagram depicting an example method for transferring a cCard.

[0017] FIG. 9 is a block diagram of a system for transferring a cCard.

[0018] FIG. 10 is a block diagram depicting generation of hashes.

[0019] FIG. 11 is a flow diagram depicting an example method for generating a cCard token. DETAILED DESCRIPTION

[0020] Reference will now be made in detail to the disclosed embodiments, examples of which are illustrated in the accompanying drawings. The same reference numbers in the drawings and this disclosure are intended to refer to the same or like elements, components, and/or parts.

[0021] In this application, the use of the singular includes the plural unless specifically stated otherwise. In this application, the use of “or” means “and/or” unless stated otherwise. Furthermore, the use of the term “including,” as well as other forms such as “includes” and “included,” is not limiting. In addition, terms such as “element” or “component” encompass both elements and components comprising one unit, and elements and components that comprise more than one subunit, unless specifically stated otherwise.

[0022] Embodiments of the present disclosure generally relate to fungible and non- fungible tokens, and more specifically, to token-based systems and methods for generating, administering, and maintaining fungible and non-fungible tokens. It is noted that a fungible token and non-fungible token may be represented by, for example but not limited to, a Cloutchain card, a cCard, a Clout card, or like derivatives (referred to hereinafter as a “cCard”). In one or more examples, a cCard includes one or more of a token component, an item component, a visual component, and an indication of rights or benefits associated with ownership of the cCard. It should be understood that the token component of the cCard may be represented by a whole token or a portion of the whole token. In one or more cases, an item component may represent, for example, but not limited to, a trading card, ticket, or the like. [0023] In one or more cases, cCards are token-based assets that may be utilized to represent non-fungible token (NFT) based items (or items based upon fractional NFTs), such as, but not limited to, trading cards, tickets to events, promotional items, downloads, or the like. In one or more cases, cCards may include one or more attributes corresponding to, for example but not limited to, intrinsic value, extrinsic value, tier-based value, stock value, rarity or scarcity, card series, and multiple real-world and virtual benefits. In some cases, one or more attributes may be static, which do not change over time. In some cases, one or more attributes may be dynamic, which change over time. In some cases, one or more attributes may be permanent, such that the attribute remains in effect for the life of the cCard. In other cases, one or more attributes may be temporary. For example, a temporary attribute may expire during a certain time period.

In another example, a temporary attribute may diminish over time. In yet another example, a temporary attribute may be available for a limited number of uses. It is noted that a cCard may include a combination of attributes that have a variety of features. For instance, a cCard may include an attribute that is permanent, another attribute that is temporary, and another attribute that is dynamic.

[0024] In one or more cases, cCards may be based on a smart contract-based custody solution that allows purchasers to buy tokens and take receipt of a “secret.” The “secret” may enable transfer of the token on demand in conjunction with the appropriate user data that compliments a user generated hash. Thus, any prospective token purchaser can buy and have immediate exclusive and secure control over tokens without the need for a hardware or software wallet. For instance, a CloutChain network may manage custody of digital tokens on a blockchain via a one or more smart contracts. To interact with a digital token (e.g., purchasing, selling, or transferring the token), a user may authenticate oneself by logging into a cCard marketplace of the CloutChain network, and subsequently providing directions to the CloutChain network (e.g., purchase a token from a specific collection of tokens). The CloutChain network may receive the direction from the user and make calls to the respective smart contract. That is, a user may interact with a smart contract via a web2 solution without utilizing a digital wallet or needing to have a digital wallet that is associated with one or more rules on a smart contract. [0025] In one or more cases, cCards allow issuers to tie events (e.g., large events, microengagements, and the like) and other benefits, as described in more detail herein, to the collection and ownership of a cCard. In one or more cases, an event and related benefits may be tied to certain quantities of cCards, combinations of cCards, or unique cCards. cCards grant the issuer a way to tokenize (i.e., make tangible) future interactions, services, and tangible goods; sell those interactions, services, and tangible goods; and track the outstanding quantity of offered interactions, sendees, or tangible goods. In one or more cases, cCards may act as tickets themselves by allowing the issuer to verify the real-time ownership and identity of the owner of any particular cCard or quantity thereof.

[0026] FIGs. 1 A-2C illustrated example cCards and various views thereof. For example,

FIG. 1 A illustrates a front side of the example cCard 100A, and FIG. IB illustrates a back side of the example cCard 100B. In another example, FIGs. 2A-2C illustrate a cCard having a scrolling view feature, such that a user may scroll to various areas of the cCard, which are not in view on the user interface of the user’s device 101.

[0027] In one or more cases, a cCard may display the name 102 of an issuer of the cCard.

For example, the name 102 of an issuer may be an artist, performer, athlete, or the like. In one or more cases, a cCard may include a scannable or readable component 104 displayed on a user interface of the user’s device 101. In the scannable or readable component 104 may include for example, an RFID tag, a bar code, a label, a QR code, or the like, which may be scanned and provide further action. For example, if the CloutChain netw ork determines that the scanned component 104 is valid, the cCard may provide an indication of the validity on the user interface of the user device 101. The validity indication may, for example, grant a user access to an event or allow a user to redeem an item or sendee associated with the cCard. In another example, if the CloutChain network determines that the scanned component 104 is valid, the cCard may provide a link. The link may be displayed on the user interface, in which a user may provide an input that selects the link, hi one or more cases, the link may reference a user to any appropriate site, such as a site to manage, buy, sell, or transfer cCards, an issuer’s site, or the like.

[0028] As illustrated in FIGs. IB, 2A, and 2B, cCards may comprise an artistic component 106. For example, the artistic component 106 may display an artist name, artist logo, or the like. In some cases, the artistic component 106 may include visual aspects (e.g., an image of a logo), auditory aspects (e.g., background music, voice recordings highlighting features of the corresponding event), multimedia aspects (e.g., video, sound, images, and the like), or any appropriate combination thereof. In one or more cases, the artistic components 106 may be generated by issuers, such as, for example, artists, influencers, athletes, businesses, or the like.

In one or more cases, the artistic component 106 may provide value to issuers in the form of advertisement, public relations, fan appreciation, or the like.

[0029] In one or more cases, the artistic component 106 of the cCard may constitute a visual representation of the underlying blockchain token, such as, but not limited to, an Ethereum Request for Comment (ERC) non-fungible token. In one or more cases, the cCard displays a visual art component designed by or for the issuer. In one or more cases, the cCard displays one or more attributes of the cCard including the card series 108, a scarcity or rarity of the card, prizes 112 associated with the cCard, stock 114 associated with the cCard, a tier level 116 associated with the cCard, a current value 118 of the cCard, additional details 120 of the cCard, and benefits 110 which the cCard will grant the holder. For example, a cCard may render an indication of the value, e.g., a current value 118, of tire cCard. In one or more cases, a cCard may render an indication of the location of the event associated with the cCard. For example, if the cCard is to be used as a ticket to an event, the cCard may display the location of the event, or the area in which a cCard grants access. In one or more cases, a cCard may render attributes of the cCard, such as the series 108 of the cCard (e.g., where the cCard fits in or is positioned in a series of issued cCards or collection), benefits 110, prizes 112, stock value 114, tier value 116, or the like, or any appropriate combination thereof.

[0030] In one or more cases, cCards may convey rights and benefits to their holders. For example, cCards may convey tier-based benefits based on the total quantity of cCards, which relate to any given issuer, in the holder’s possession. In some cases, quantity-based tier requirements may be established by the issuer. For example, one tier-based benefit may establish that anyone who owns 1-9 total cCards (e.g., of any variation and from any collection /series issued by that issuer) may access Tier 1 benefits (e.g., tier value 116). In another example, another tier-based benefit may establish that anyone who owns 10-49 total cCards may access Tier 2 benefits. In one or more cases, tier level benefits may comprise any appropriate benefit. For example, tier level benefits may be associated with gifts, downloads, back-stage passes, memberships, or the like, or any appropriate combination thereof, hr one or more cases, different tier levels may represent an increase or decrease in desire or value. For example, a tier 1 level benefit may have the greater value be more desirous than a tier 2 level benefit. In another example, the tier 1 level benefit may be less valuable than the tier 2 level benefit. In one or more cases, the CloutChain network may establish rules within one or more smart contracts that establish the value of tiered benefits as the tiered benefits relate to one another.

[0031] In one or more cases, as issuers offer subsequent cCards of a collection, the value of older cCards with respect to Tier qualification may be reduced. For example, once collection 2 is released, all cCards from collection 1 may count as 0.5 cards for purposes of reaching a given tier. In another example, on the issuance of collection 3, the first run cards could drop to 0.25 and second run cards could drop to 0.5 of previous values. In one or more cases, the percentage of decline may be customized and occur at the discretion of the issuer. For example, the value of a run of cards (e.g., the first run of cards) may decline each and every time a new collection is issued. In other examples, the value of a run of cards (e.g., the first run of cards) may not decline when a new collection is issued. In yet another example, the value of a run of cards may decline when a certain number of collections are issued. By reducing the value of older cCards (thereby disincentivizing customers from purchasing the cCard), the issuer may retire or remove cCards from circulation. It is noted, however, that this method of “retiring” older cards from the tier structure may prevent cCard tier inflation and encourage ongoing purchases to maintain status. In one or more cases, specific benefits may be offered for specific combinations of cCards, which are collected from one or multiple collections from one or more issuers. For example, an artist may issue multiple collections of cCards, and may implement a rule in the smart contract that provides a benefit to the holder of, for example, cCards from two of the collections. In another example, if Artist 1 and Artist 2 go on a music tour together, Artist 1 and Artist 2 may choose to collaborate on a cCard promotion and offer back-stage access to any holders of a certain combination of rare cCards, which have been issued by Artist 1 and Artist 2, whether issued separately or together.

[0032] In one or more cases, specific benefits and rights may be associated with a particular variant of a cCard. Specific benefits may be decided by an issuer of the cCard. For example, an issuer may set one of the cCard design variants to constitute a total of only 1% of all cCards issued in that collection and can specify that any holder of that specific variant can access a specific exclusive benefit or right. In another example, the issuer may set another of the cCard design variants to constitute a total of, for example, 5% of all cCards issued in that collection to be grant the holder access to another specific benefit or right. Benefits and rights may comprise any appropriate benefit or right, such as, for example, gifts, downloads, back-stage passes, memberships, or the like.

[0033] For any card-specific benefit that can be repeated, a stock system may be implemented for each such card. As each cCard may be backed by a NFT, each cCard can have its own level of stock, such as stock 114. The stock level of the cCard may indicate, for example, an inventory, such as the number or inventory of issued cards, the number of uses of one or more benefits associated with a cCard. In one or more cases, the available stock 114 of the cCard or benefits associated with a cCard will limit the total number of times that a tangible benefit can be used in connection with any individual cCard. Moreover, the available stock 114 may lead to the secondary market value of ultra-rare cCards diminishing over time. For example, if the holder of an ultra-rare cCard presents the cCard to claim an exclusive t-shirt, or the like, from the issuer, the issuer verifies the token holder, and the holder redeems the benefit from the cCard. This redemption may reduce the stock of that cCard by, for example, one. In one or more cases, the issuer may provide a direction to the CloutChain network, via the CloutChain marketplace, to reduce the stock level associated with the respective cCard. As the cCard is sold to a subsequent purchaser, the new purchaser can redeem the benefit so long as the cCard purchased still has remaining stock. The remaining stock/quantity (e.g., stock 114) may be displayed on each applicable cCard, thereby providing a holder of the cCard or prospective purchaser or transferee of the cCard with notice as to a remaining number of times a benefit associated with the cCard may be redeemed. That is, this will allow prospective purchasers to know the current stock value of a cCard. In one or more cases, the stock/quantity may be tracked through a private, public ledger, or any appropriate combination thereof.

[0034] In one or more cases, benefits associated with a cCard may be physical (e.g., real- world), virtual (e.g., digital ), or any appropriate combination thereof. For digital/virtual benefits, the cCard system may provide a unique content feed that displays token-gated-content only to qualified token-based cCard holders. This may be accomplished by querying an internal database of the cCard system, such as database 30 depicted in FIG. 5, FIG. 7, and FIG. 9. In one or more cases, a public database, public ledger, or the like, may be utilized to verify token ownership. Ownership, security, and traceability of the public ledger may be relied upon to verify authenticity of the public-record owner. The results of which may then be communicated to the cCard system private database and used to populate the content feed with the appropriate content.

[0035] In one or more cases, cCard specific benefits may include, for example, but not limited to, one or more of the following, a download of previously unreleased media, backstage access, sound check access, access to a designated seating area, meet and greet access with a person or group designated in the cCard, voucher to redeem training or coaching sessions, voucher to redeem exclusive merchandise or items, and other like benefits. In one or more cases, cCard Tier-Based benefits may include, for example, but not limited to, one or more of the following, discounts on merchandise, early access to concert tickets, access to AMA/Q&A/Exclusive Live Streams, access to exclusive giveaways, access to a social feed (e.g., the CloutChain social feed) that may be tailored based on token inventory, exclusive hours of access to business (e.g., exclusive hours for customers of the business such as gyms and boutique shops), backstage access, sound check access, and access to a designated seating area.

[0036] FIGs. 3 and 4 illustrate example tier benefits associated with certain tiers of cCards. For example, as illustrated in FIG. 3, cCards associated with Tier 1 may provide access to exclusive content feed and a monthly playlist recommendation; cCards associated with Tier 2 may include the benefits of Tier 1 as well as a voucher for a discount on merchandise and access to exclusive giveaways; and cCards associated with Tier 3 may include the benefits of Tiers 1 and 2 as well as backstage access during a tour and a monthly livestream invitation for the fall benefits seasons. In some examples, out of a certain number of issued tokens (e.g., 5000 total tokens or 5000 total cCards) a certain number (e.g., 50) of tokens (i.e., cCards) may be an exclusive ultra-rare design providing a holder of the token additional benefits, such as access to an intimate virtual acoustic concert in July and an exclusive t-shirt commemorating the virtual acoustic concert. In other examples, another number of tokens (e.g., 2000 tokens) of the total number of tokens may be another exclusive ultra-rare design providing a holder of the token additional benefits, such as a download to a previously unreleased demo. In another example, as illustrated in FIG. 4, cCards associated with Tier 1 may provide access to exclusive content feed; cCards associated with Tier 2 may include the benefits of Tier 1 as well as a voucher for a discount on merchandise; and cCards associated with Tier 3 may include the benefits of Tiers 1 and 2 as well as a voucher to access exclusive workout hours (e.g., 5p.m. to 7p.m. on Fridays) and access to a monthly livestream invitation for the fall benefits seasons. In some examples, out of a certain number (e.g., 1000) of issued tokens (i.e., cCards), a certain number of tokens (e.g., 10 tokens) may be an exclusive ultra-rare design providing a holder of the token additional benefits, such as a voucher to access, for example, but not limited to, a single one-on-one training session

[0037] In one or more cases, the content feed provided by the CloutChain network may be used to share private links to external virtual content or events (e.g., links or passwords to private zoom or twitch lobby) or host an exclusive token-based file download like an unreleased mp3 or video. In one or more cases, the content feed may comprise a token-dependent media player or live media streaming platform with direct connectivity to streaming platforms.

[0038] Referring back to FIGs. 1 A-2C, in order to verify the authenticity and identity of a person claiming one or more benefits associated with a cCard, the cCard may display the scannable or readable component 104, which may include for example, a QR code, verify button, NFC (RFID) interface, Bluetooth interface, or the like, or any appropriate combination thereof that may be used to verify an authenticity of the cCard or holder. When, for example, the QR code is scanned (or another verification protocol is triggered, such as the user verifying the authenticity of the cCard via the NFC interface of the user’s device), the CloutChain network may query a public ledger and retrieve the publicly available data of the true owner. For example, the CloutChain network may retrieve an email from the public ledger, and may cross check the public information (e.g. the retrieved email address) against the CloutChain network private database (e.g., database 30) and the party attempting the verification. For example, during the verification process, the CloutChain network may present, for example, the profile picture, name, email address, tier status, and unique card inventory' for the person associated as being the holder of the cCard on the device of the user. The identity of the user attempting to utilize the benefit associated with the cCard may be crossed-checked with the associated holder of the cCard in order to verify the identity of the user. Further, during the verification process, the CloutChain network may utilize the identification information provided on the cCard and validate the authenticity of the cCard. This method constitutes a ticket that is secure, cannot be duplicated, cannot be scalped, and can be tracked on a public distributed ledger all without having to share too much personal identifying information on the part of the holder. This blend of distributed ledger technology with internal database access creates a uniquely secure ticketing application.

[0039] In one or more cases, the CloutChain network provides collections of cCards that are managed using one or more smart contracts. In some cases, a collection of cCards may be associated with a specific smart contract or several smart contracts. In one or more cases, the CloutChain network may utilize several smart contracts that manage various features of the CloutChain ecosystem. For instance, one smart contract may be created to manage changes to cCards or collections of cCards (e.g., change benefits associated with a cCard or a collection; adjusting tier values; adjusting stock values; or other like changes). Another smart contract may be a smart contract (e.g., KYC smart contract) configured to create, read, update, and delete operations for approved users. Another smart contract may be configured to perform hashing or other cryptographic functions on identification information. Yet another smart contract may be configured to manage the data of the cCards and collections that are tied to a blockchain. Moreover, another smart contract (e.g., an ownership smart contract) may manages rules that are established in the CloutChain network. For example, such smart contract may blacklist a user who has not been labeled as an issuer or holder within the CloutChain ecosystem. In some examples, when a user is approved via, for example, the KYC smart contract, the CloutChain network may make a call to the ownership smart contract and whitelist the user for the associated cCard or collection of cCards.

[0040] In one or more cases, the CloutChain network provides cCard issuers access to a

CRM-style dashboard, via a user interface of the user’s device (e.g., the issuer’s device), allowing an issuer to view and manage issued cCards. In one or more cases, the CRM-style dashboard presents basic demographic information for all of holders of the issuer’s cCard. In one or more cases, the dashboard may be populated based on present holders of the issuer’s tokens. [0041] In one or more cases, purchasers of NFT-token-based cCards may not need hardware or software (digital) wallets to purchase and utilize cCards. In one or more cases, a user also does not need to utilize a digital wallet to redeem benefits or transfer a cCard or its underlying token components. That is, a user may utilize one or more features of a cCard (e.g., purchasing a cCard, redeeming a benefit, or transferring a cCard) by using a user-derived code and a secret. The user-derived code may be derived from any appropriate attribute that identifies a user, for example but not limited to, an email address, a telephone number, a physical address, or other like identifiers of the user. For example, the CloutChain network may provide a cCard or collection of cCards that are available for an issuer to purchase and customize to provide tailored cCards. The CloutChain network may authenticate the user-derived code (e.g., an email address) input by issuer and a secret. The secret may be generated by the cCard system, by an entity other than the cCard system, or any appropriate combination thereof. The secret may be generated by an appropriate means. For example, as explained in more detail herein, the secret may be the result of performing a hash function on a random seed. Having authenticated the user-derived code and secret, the CloutChain network may recognize the issuer as being authenticated and allow the issuer to purchase cCard or collection of cCards and to tailor the cCard (e.g., by providing directions to the CloutChain network, which provides calls to the respective smart contract). As such, the CloutChain network creates tokens (i.e., the cCards) and subsequently assigns ownership (i.e., assigns meta data of the issuers to the tokens) of the tokens to issuers once the issuers purchase the tokens.

[0042] In one or more cases, the CloutChain network may maintain custody of purchased

NFT-based cCards in one or more smart contracts. Metadata associated with a cCard may be added to the smart contract. The metadata may represent, for example, a hash value associated with the cCard, a token ID associated with the cCard, and any other appropriate metadata. Alternatively, custody of purchased NFT-based cCards may be maintained within the CloutChain network without need for a smart contract. By maintaining custody of purchased NFT-based cCards, a user (e.g., an issuer or fan) may interact with a cCard (e.g., an issuer purchasing a cCard; a fan redeeming a benefit of a cCard) via a CloutChain network-maintained application without requiring a user to leave the CloutChain network platform or set up third- party digital wallets (or create a digital wallet within the CloutChain ecosystem). In one or more cases, to purchase cCards, transfer cCards, or redeem benefits, a user may present the secret and one or more attributes of the user-derived code (e.g., email address, web2 login credentials, or the like) to the CloutChain network, hr one or more other cases, if a user successfully logs onto the cCard system platform and provides a corresponding hash, a user may purchase cCards, transfer cCards, or redeem benefits without presenting a secret of user-derived code. That is, the user need not provide the user-derived code (e.g., email address) as the user is authenticated by successfully logging onto the cCard platform.

[0043] In one or more cases, the CloutChain network platform provides a cCard marketplace that allows users of the CloutChain network platform to buy and sell cCards between users. In one or more cases, issuers may receive a royalty on all transactions and the cCard marketplace may allow users to complete collections, acquire sought-after benefits, and purchase access (e.g., tickets) to events associated with specific cCards. As such, in some cases, an issuer of a cCard may receive a royalty every time a cCard is sold or resold. Furthennore, by transacting with cCards in the cCard marketplace, the possibilities of fake tickets being sold, authentic tickets being duplicated, or authentic tickets not being delivered to the purchaser is eliminated.

[0044] In one or more cases, a cCard system, such as the cCard system 600 illustrated in

FIG. 5, may utilize blockchains, cryptographic hashes, and smart contracts. A blockchain, e.g., blockchain network 4 includes a list of records or transactions, referred to as blocks. Each block of a blockchain contains, among other things, a cryptographic hash of at least a portion of the previously generated block. Thus, the entirety of the transaction history is preserved in the blockchain. A hash is a value resulting from a cryptographic hash function. A cryptographic hash function operates on data of any size, and provides a fixed size result. It is a one-way function. Thus, the input data to a cryptographic hash function cannot be determined from the resultant hash value. Also, a hash value for a unique set of input data is unique. That is, the same hash value will not result from different inputs. Thus, if one bit of input data is changed, the resultant hash value is changed. A smart contract represents executable code stored in a blockchain. The executable code may represent an agreement between parties.

[0045] FIG. 5 is a block diagram of a cCard system 600. System 600 includes

CloutChain network 2, blockchain network 4, blockchain 8, and one or more smart contracts, such as smart contract 6. CloutChain network 2 may include CloutChain backend 32 (i.e., a server-side portion of the CloutChain network 2) and database 30. As described herein, CloutChain network 2 may generate hashes, generate token IDs, maintain hashes, maintain token IDs, maintain a portal for users and issuers, maintain a cCard user interface, maintain a private database of user/token related information, connect buyers and sellers of cCards, facilitate trades, advertise the availability of cCards, maintain a cCard user and issuer dashboard, facilitate the establishment of cCard token-related smart contracts, verify or assist in the verification of ownership of the holder of any given cCard or combination thereof, or the like, or any appropriate combination thereof.

[0046] FIG. 6 is a flow diagram depicting an example method for generating a cCard, and FIG. 7 is a block diagram of a system (e.g., cCard system 600) for generating a cCard.

[0047] In one or more cases, the CloutChain network 2 may develop a cCard or a collection of cCards that may be purchased by an issuer 26 and tailored to needs of the issuer 26. The CloutChain network 2 may have custody of one or more wallets, which have overarching ownership of the smart contracts.

[0048] In one or more cases, a request to issue a cCard may be received at step 10. The request may come from any appropriate source, such as, but not limited to an issuer 26 of the cCard. The issuer 26 may be a sports promoter, an artist (e.g., rock band, painter, etc.), or the like, for example. In one or more cases, the request may be provided to the CloutChain network 2. For example, the issuer 26 may access the digital marketplace of the CloutChain network 2 and submit a request to issue a cCard.

[0049] The availability of cCards may be advertised at step 12. In one or more cases, the system 600 may maintain an inventory of available cCards, and advertise the number of available cCards on the digital marketplace of the CloutChain network 2. hi one or more cases, qualifiers associated with the availably cCards may be advertised at step 12. For example, the system 600 may append one or more qualifiers to a cCard or a set of cCards, in which the qualifier describes a condition of the respective cCard. Qualifiers may include, for example, but not limited to, a statement that the cCard will be available for sale for a limited amount of time, that the cCards are part of a particular collection, or the like. The availability of the cCards may be advertised by CloutChain network 2 via any appropriate means, such as, for example, the internet. A user, such as issuer 26, of the CloutChain network 2 may view the availability and any conditions by accessing the digital marketplace of the CloutChain network 2.

[0050] In one or more cases, CloutChain network 2 may receive a request to purchase a cCard at step 14. To purchase a cCard (or a collection of cCards), a purchaser, e.g., issuer 26, may input identifying information. In one or more cases, the identifying information may be used to link the purchaser to the cCard. In some cases, the identifying information may include a form of identification, such as an email address, telephone number, home address, or the like. In one or more other cases, a purchaser may log onto the digital marketplace of the cCard platform (e.g., CloutChain network 2), in which the purchaser either creates an account w ith the CloutChain network 2 or logs onto a previously established account. By successfiilly logging onto the CloutChain network 2, the system 600 recognizes that the purchaser has an established relationship (e.g., an account) with the cCard platform (e.g., CloutChain network 2), and thus previously provided a form of identification. [0051] In one or more cases, a final transfer hash for each purchased cCard may be generated by CloutChain network 2 at step 16. In one or more cases, the CloutChain network 2 may generate the final transfer hash using a hash of the purchaser’s identification (e.g., email address, telephone number, home address, etc.) and another hash of a secret value, or secret. In one or more cases, the secret may be generated by CloutChain network 2, or by any appropriate entity. In some cases, the secret value or secret may be a randomly generated secret. In one or more cases, the CloutChain network 2 may generate the secret by any appropriate means, such as, for example, performing a hash function on a random seed. For example, the random seed may be a 256 key.

[0052] In one or more cases, the CloutChain network 2 may generate a cCard at step 18.

That is, the CloutChain network 2 may tailor the purchased cCard at the direction of the issuer 26. For instance, the CloutChain network 2 may receive directions from the issuer 26 as to the various components and benefits associated with the cCard. The CloutChain network 2 may make calls to the respective smart contracts and established rules associated with the cCard. As described herein, a cCard may include an indication of an artistic component 106, attributes associated with the cCard, benefits associated with the cCard, the value of the cCard (stock value, tier value, intrinsic value, extrinsic value, etc.), or the like.

[0053] At step 19, a token ID may be generated by the CloutChain network 2. In one or more cases, a token ID is a value associated with an NFT-or token-based cCard. In one or more cases, each token ID is unique for each cCard. That is, no two cCards have the same token ID. Thus, a token ID provides a means for uniquely identifying a cCard. In one or more cases, CloutChain network 2 may randomize one, more, or all purchased cCards at step 20. By randomizing the cCards, the purchasers (e.g., such as a user who purchases the cCard from the issuer 26) of the c Cards may not know which cards the purchasers purchased until the purchasers receive the cCards. For example, a purchaser may not know the value of the cCard, the benefits associated with the cCard, the stock or tier value of the cCard, until it is received. In one or more cases, cCard tokens may be placed in one or more smart contracts 6 at step 22. In one or more cases, the smart contracts may be blockchain 8 based. cCard tokens may be non-fungible tokens (NFTs). Purchased cCards may be purchased and distributed to one or more users, such as 28 at step 24. [0054] FIG. 8 is a flow diagram depicting an example method for transferring a cCard.

FIG. 9 is a block diagram of the system 600 for transferring a cCard. In one or more cases, at step 44, a request to transfer a cCard may be sent by a first user 36 to CloutChain network 2.

The first user 36 may successfully log onto the cCard platform, thereby authenticating the identity of the first user 36, and the first user 36 may initiate the transfer of a cCard to another user, such as second user 38. In one or more cases, the first user 36 may provide the secret associated with the cCard to be transferred and provide some form of agreed upon identifying information of second user 38 (e.g., email address). For example, the first user 36 may submit the secret associated with the cCard to the CloudChain network 2 and an email address of the second user 38. It is noted that the first user 36 may be the issuer 26 of the cCard or another holder (a purchaser who purchased the cCard from the issuer 26) of the cCard.

[0055] In one or more cases, the CloutChain network 2 transfers the cCard (i.e., the token) to second user 38. To transfer ownership of the cCard, the CloutChain network 2 generates a hash of the provided identifying information at step 46. For example, the CloutChain network 2 generates a hash of the provided identifying information by hashing the email address of second user 38. In an example, the CloutChain network 2 may designate this hash value as SUHashl (i.e., Second User Hash! ). In one or more cases, the CloutChain network 2 may generate a seed for a second user secret for the second user 38 at step 48. The second user secret may be generated by any appropriate means, such as, for example, a random seed, such as a 256 bit key, or the like, hi one or more cases, the CloutChain network 2 may hash the second user seed at step 50. For example, the CloutChain network 2 hashes the second user seed and designates this hash value as for example, SUHash2 (i.e., Second User Hash2).

[0056] In one or more cases, the CloutChain network 2 may generate a final transfer hash for the second user 38 at step 52. For example, the CloutChain network 2 generates a final transfer hash for the second user 38 by hashing SUHashl and SUHash2. It is noted that the CloutChain network 2 may not generate a new token ID. For instance, as the token ID uniquely identifies a cCard and the CloutChain network 2 is only transferring ownership of the already generated cCard, the CloutChain network 2 does not need to generate a new cCard.

[0057] In one or more cases, the CloutChain network 2 may generate a final transfer token for the second user 38 at step 54. For example, the CloutChain network 2 generates a final transfer token for the second user 38 by combining SUHashl, SUHash2, SU Token ID, and the final transfer hash for second user 38. This final transfer token may be generated by any appropriate means. In one or more cases, the CloutChain network 2 provides metadata associated with the second user cCard to the respective smart contract, e.g., smart contract 6, at step 56. In one or more cases, the CloutChain network 2 provides the final transfer token to the second user 38, thereby transferring ownership of the cCard to the second user 38. In one or more cases, steps 46 through 54 may be accomplished by CloutChain network 2, by a user seeking to transfer the token through the execution of existing code in place which will facilitate the hash generation, or any appropriate combination thereof

[0058] FIG. 10 is a block diagram depicting generation of hashes for cCards. In one or more cases, block 920 represents identifying information (e.g., an email address) of a user or purchaser of a cCard. In an example, the CloutChain network 2 uses the email address to identify the user. As discussed herein, the CloutChain network 2 hashes the identifying information and generates a hash of the identifying information. For example, block 940 represents the function of a hashed email address of the user or the purchaser of the cCard, in which the resultant value is designated Hashl. In one or more cases, block 960 represents a secret. For example, and as discussed herein, the secret may be any appropriate secret, such as a random seed, 256 bit key, or the like. As discussed herein, the CloutChain network 2 hashes the secret and the resultant value is designated Hash2, as illustrated in block 980. In one or more cases, have generated the hashed functions (e.g., Hashl and Hash2) in blocks 940 and 980, the CloutChain network 2 generates a final transfer hash, which is illustrated in block 1000 as the function of hashing Hashl and Hash2. hi one or more cases, the resultant value is designated as the final transfer hash. Hashl and Hash2 may be combined in any appropriate manner prior to being hashed. For example, Hashl and Hash 2 may be concatenated in any order.

[0059] FIG. 11 is a flow diagram depicting an example method for generating a cCard token. In one or more cases, an email address is received at step 1102. For example, CloutChain network 2 may receive an email address from a user or purchaser of a cCard. As discussed herein, an email address is an example form of identification of a user or purchaser of a cCard. CloutChain network 2 may receive other agreed upon forms of identification information to identify a user or purchaser of the cCard. In one or more cases, a first hash value is generated at step 1104 by hashing the email address received at step 1102. For example, CloutChain network 2 performs a hashing function on the received email address and generates the first hash value. In one or more cases, a secret is generated at step 1106. For example, CloutChain network 2 generates a secret as discussed herein. Further, in one or more cases, a second hash value is generated at step 1108 by hashing the secret generated at step 1106. For example, CloutChain network 2 performs a hashing function on the generated secret to generate a second hash value.

In one or more cases, a final transfer hash is generated at step 1110 by hashing the first hash and second hash. For example, the CloutChain network 2 generates a final transfer hash by performing a hashing fimction on the first hash and the second hash. In one or more cases, a token ID is generated at step 1112. It is noted that the token ID does need not be generated in the sequence depicted in FIG. 11 (e.g., subsequent to step 1110). Rather, it should be understood that the token ID may be generated at any step in the depicted process. In one or more cases, the token ID is a random string that is not necessarily related to a holder. A token ID may persist across subsequent holders. In one or more cases, a final transfer token is generated at step 1114. For example, the CloutChain network 2 may generate a final transfer token by combining the first hash, the second hash, the token ID, and the final transfer hash.

[0060] In one or more cases, a method of generating a cCard includes: receiving a request to generate a cCard; advertising the availability for purchase of the cCard; receiving a number of requests to purchase the cCard, in which each request to purchase the cCard includes an identifier of a respective purchaser; for each of the number of requests, generating a respective first hash, in which each generated first hash is a result of performing a hash function on a respective identifier; for each of the number of requests, generating a respective seed value, in which each generated seed value differs from all other seed values; for each of the number of requests, generating a respective second hash, in which each generated second hash is a result of performing a hash function on a respective seed value; for each of the number of requests, generating a respective token identifier, in which each generated token identifier differs from all other token identifiers; for each of the number of requests, generating a transfer hash, in which each generated transfer hash is a result of performing a hash function on a respective combination of each first hash and each second hash; for each of the number of requests, generating a respective cCard including a respective transfer hash and a respective token ID; and transmitting each of the generated transfer hashes and each of the generated token identifiers to a cryptographic block chain. In one or more cases, the method further includes providing each generated cCard to each respective purchaser. In one or more cases, the method further includes randomizing all generated cCards; and providing the randomized cCards to each respective purchaser. In one or more cases, the method further includes maintaining custody of generated cCards in a smart contract associated with the cryptographic blockchain. In one or more cases, the cryptographic blockchain is a non- fungible token-based blockchain. In one or more cases, advertising the availability for purchase of the cCards includes an indication that only a limited number of cCards are available. In one or more cases, advertising the availability for purchase of the cCards includes an indication that the cCard is part of a particular collection of cCards. In one or more cases, the identifier of a purchaser is an email address of the purchaser. In one or more cases, each of the generated cCards has associated therewith, a specific benefit. In one or more cases, each generated cCard includes an indication of at least one of an event for which the cCard may be used, a location of an event, a collection to which the cCard belongs, an artist name, a logo associated with an artist, a benefit associated with the cCard, or a scannable link. [0061] In one or more cases, a method includes: receiving a request from a first user to transfer a cCard to a second user; authenticating the first user; generating a first second-user hash, in which the first second-user hash is a result of performing a hash function on an identifier of the second user; generating a seed value; generating a second second-user hash, in which the second second-user hash is a result of performing a hash function on the seed value; generating a transfer hash, in which the transfer hash is a result of performing a hash function on a combination of the first second-user hash and the second second-user hash; transferring ownership of the cCard to the second user by associating the first second-user hash, the second second-user hash, the transfer hash, and a token identifier of the cCard; and updating a cryptographic block chain to record the transaction of transferring the cCard from the first user to the second user. In one or more cases, the method further includes providing the cCard to the second user. In one or more cases, the method further includes maintaining custody of the transferred cCard in a smart contract associated with the cryptographic blockchain. In one or more cases, the cryptographic blockchain is a non-fungible token-based blockchain.

[0062] Aspects of the present disclosure have been described in detail with reference to illustrated embodiments. Those skilled in the art, however, will appreciate that modifications may be made thereto without departing from the scope of the disclosure. Moreover, the present disclosure is not limited to the precise construction and compositions disclosed herein. Any and all modifications, changes, and variations apparent from this disclosure are within tire scope of the invention as defined by the appended claims. Additionally, the present disclosure expressly includes any and all combinations of the preceding elements, features, and embodiments.

Claims

CLAIMS What is claimed is:

1. A computer-implemented method of generating and assigning a cryptographic digital asset, the computer-implemented method comprising: generating a token identifier of the cryptographic digital asset; receiving a request to purchase the cryptographic digital asset, the request comprising an identifier of a purchaser; performing a first hashing function on the purchaser identifier to generate a hash of the purchaser identifier; generating a seed value of a randomly generated secret; performing a second hashing function on the seed value to generate a hash of the randomly generated secret; generating a transfer hash comprising the hash of the purchaser identifier and the hash of the randomly generated secret; and transmitting the transfer hash and tire token identifier of the cryptographic digital asset to a blockchain, wherein the transfer hash and the token identifier are associated such that the purchaser is established as the owner of the cryptographic digital asset.

2. The computer-implemented method of claim 1, further comprises issuing the cryptographic digital asset to the blockchain prior to associating the purchaser as the owner of the cryptographic digital asset.

3. The computer-implemented method of claim 1, further comprises: randomizing the cryptographic digital asset within a plurality of other generated cryptographic digital assets, wherein each of the other generated cryptographic digital assets are associated with a respective token identifier; selecting one of the randomized cryptographic digital assets; and transmitting the transfer hash and the selected randomized cryptographic digital asset to the blockchain, wherein the transfer hash and the token identifier of the selected randomized cryptographic digital asset are associated such that the purchaser is established as the owner of the selected randomized cryptographic digital asset.

4. The computer-implemented method of claim 1, further comprises: generating a collection of cryptographic digital assets associated with one or more smart contracts; advertising an availability of the collection of cryptographic digital assets; and receiving the request to purchase the cryptographic digital asset from the generated collection of cryptographic digital assets.

5. The computer-implemented method of claim 1, wherein the identifier of the purchaser is a web2 based login credential.

6. The computer-implemented method of claim 1, wherein the identifier of the purchaser is an email address of the purchaser.

7. The computer-implemented method of claim 1, wherein the cryptographic digital asset is associated with a redeemable benefit associated with the purchaser.

8. The computer- implemented method of claim 1, further comprises maintaining custody of the cryptographic digital asset in one or more smart contracts associated with the blockchain.

9. The computer-implemented method of claim 1, further comprises: receiving a request from the purchaser to transfer ownership of the cryptographic digital asset to a subsequent purchaser; and authenticating the purchaser based on the received purchaser identifier.

10. The computer-implemented method of claim 9, further comprises: performing a third hashing function on an identifier of the subsequent purchaser to generate a hash of the subsequent purchaser identifier; generating a second seed value of the randomly generated secret; perfonning a fourth hashing function on the second seed value to generate a hash of the randomly generated secret; generating a second transfer hash comprising the hash of the subsequent purchaser identifier and the hash of the randomly generated secret; and transferring ownership of the cryptographic digital asset to the subsequent purchaser by updating metadata associated with the ciyptographic digital asset in a smart contract and providing a transfer token associated with the cryptographic digital asset to the subsequent purchaser.

11. A decentralized computing system for generating and assigning a cryptographic digital asset, the decentralized computing system comprising a network having a memory and a processor configured to: generate a token identifier of the cryptographic digital asset; receive a request to purchase the cryptographic digital asset, the request comprising an identifier of a purchaser; perform a first hashing function on the purchaser identifier to generate a hash of the purchaser identifier; generate a seed value of a randomly generated secret; perfonn a second hashing function on the seed value to generate a hash of the randomly generated secret; generate a transfer hash comprising the hash of the purchaser identifier and the hash of the randomly generated secret; and transmit the transfer hash and the token identifier of the cryptographic digital asset to a blockchain, wherein the transfer hash and the token identifier are associated such that the purchaser is established as the owner of the cryptographic digital asset.

12. The decentralized computing system of claim 11, wherein the processor is further configured to issue the cryptographic digital asset to the blockchain prior to associating the purchaser as the owner of the cryptographic digital asset.

13. The decentralized computing system of claim 11, wherein the processor is further configured to: randomize the cryptographic digital asset within a plurality of other generated cryptographic digital assets, wherein each of the other generated cryptographic digital assets are associated with a respective token identifier; select one of the randomized cryptographic digital assets; and transmit the transfer hash and the selected randomized cryptographic digital asset to the blockchain, wherein the transfer hash and the token identifier of the selected randomized cryptographic digital asset are associated such that the purchaser is established as the owner of the selected randomized cryptographic digital asset.

14. The decentralized computing system of claim 11 , wherein the processor is further configured to: generate a collection of cryptographic digital assets associated with one or more smart contracts; advertise an availability of the collection of cryptographic digital assets; and receive the request to purchase the cryptographic digital asset from the generated collection of cryptographic digital assets.

15. The decentralized computing system of claim 11, wherein the identifier of the purchaser is a web2 based login credential.

16. The decentralized computing system of claim 11, wherein the identifier of the purchaser is an email address of the purchaser.

17. The decentralized computing system of claim 11, wherein the cryptographic digital asset is associated with a redeemable benefit associated with the purchaser.

18. The decentralized computing system of claim 11, wherein the processor is further configured to maintain custody of the cryptographic digital asset in one or more smart contracts associated with the blockchain.

19. The decentralized computing system of claim 11, wherein the processor is further configured to: receive a request from the purchaser to transfer ownership of the cryptographic digital asset to a subsequent purchaser; and authenticate the purchaser based on the received purchaser identifier.

20. The decentralized computing system of claim 19, wherein the processor is further configured to: perform a third hashing function on an identifier of the subsequent purchaser to generate a hash of the subsequent purchaser identifier; generate a second seed value of the randomly generated secret; perform a fourth hashing function on the second seed value to generate a hash of the randomly generated secret; generate a second transfer hash comprising the hash of the subsequent purchaser identifier and the hash of the randomly generated secret; and transfer ownership of the cryptographic digital asset to the subsequent purchaser by updating metadata associated with the cryptographic digital asset in a smart contract and providing a transfer token associated with the cryptographic digital asset to the subsequent purchaser.