Cryptographic digital asset architecture with selectively lockable dynamic evolution

Abstract

A method for selectively locking a cryptographic digital asset includes directing or requesting the creation or minting of a plurality of cryptographic tokens via a first common digital contract registered on a distributed ledger. Each cryptographic token is a digital asset that includes at least one attribute that is operative to evolve or change through a plurality of evolutionary stages. The plurality of cryptographic tokens are then directed to be transferred to a plurality of token holders. The method further includes receiving a request from a token holder to selectively lock the digital asset in one of the plurality of evolutionary stages, and directing or requesting the token holder to transfer a second cryptographic token having at least one attribute derived at least in part from the evolutionary stage of the digital asset at the time of the request.

Description

Technical Field

[0001] [Cross - Reference to Related Applications] This application claims priority to U.S. Provisional Patent Application No. 63 / 334,082, filed on April 22, 2022, the entire content of which is incorporated herein by reference.

[0002] [Technical Field] The present disclosure generally relates to architectures and methods that enable a user to interact with dynamically evolving crypto - assets / digital collectibles and selectively freeze them.

Background Art

[0003] A non - fungible token (NFT) is an irreplaceable (i.e., non - fungible) record stored in digital form and tradable among various market participants. Often, an NFT serves as proof of authenticity or ownership of a corresponding digital or physical item. The record constituting the NFT is often stored in an immutable digital ledger such as a blockchain - style ledger and can be divided among participants who maintain many different nodes or ledgers. Such a blockchain ledger uses some means to encrypt at least part of the record content and also references previous blocks (within the blockchain) to ensure continuity.

[0004] NFTs typically include resident data (metadata) stored directly on the blockchain, which defines the core aspects of the digital asset. While the metadata itself may be limited due to the complexity of the costs associated with pushing large amounts of data through the blockchain's transaction verification process, it often includes one or more pointers or references to additional, separate on-chain stored assets or off-chain data / digital files such as photos, graphics, videos, and audio, which would be too costly to store on-chain. When an NFT appears in a user's social media account or digital wallet, the associated software program verifies the metadata and digitally retrieves and displays the associated photos from the referenced on-chain or off-chain file repository.

[0005] In the current NFT sector, two blockchain / smart contract standards are dominant. Both rely on the Ethereum network and are developed according to improvement suggestions adopted by the community: ERC721 (also known as EIP-721) and ERC1155 (also known as EIP-1155). In a very general sense, ERC721 provides a standard for creating unique (i.e., one-of-a-kind) digital assets and is most commonly associated with traditional NFTs. Each ERC721 token contains a token-specific smart contract and must be created and transferred independently of other ERC721 tokens. Conversely, ERC1155 provides a standard for creating multiple batches of substantially identical tokens through a single recorded smart contract. These batched tokens are serialized (e.g., 1 token out of 100) and can be transferred individually or in batches between wallets.

[0006] Examples of assets that can be represented via ERC721 tokens include unique assets such as land, artwork, and unique digital collectibles. Examples of assets that can be represented with ERC1155 tokens include limited edition trading cards, art prints, coupons, and general admission event tickets. Once created, each tokenized asset under an ERC1155 contract is substantially interchangeable with other assets publicly issued under that contract. For example, using an ERC1155 contract, it is possible to issue a batch of 100 trading cards that are outwardly identical and fully interchangeable with one another (except that they have unique token identification (ID) numbers). From the owner's perspective, multiple such cards may be traded together through a single marketplace list, and the value of individual cards is determined by the market trends of the lot, not by the characteristics of individual cards / tokens.

[0007] In some embodiments, the ERC1155 contract can further provide a toggle mechanism for transitioning tokens from an initial fungible / semi-fungible state to a subsequent non-fungible state. Such tokens may be used in conjunction with tickets or coupons for general admission events, in which case the tokens lose compatibility with other tokens in the initial lot and become more unique and non-fungible.

[0008] For the purposes of this disclosure, ERC721 tokens are more commonly referred to as unique cryptographic tokens ("UCTs"), and ERC1155 tokens are sometimes referred to as batch-minted cryptographic tokens ("BMCTs"). Each UCT may be individually registered on the blockchain's distributed ledger and be the product of an individual smart contract, or multiple UCTs may be generated from the same smart contract. Multiple BMCTs may be collectively derived from a single smart contract, all registered on the blockchain's distributed ledger. Broadly speaking, both UCTs and BMCTs are considered a type of NFT for the purposes of this disclosure.

[0009] In the current market, most digital collectibles backed by UCT or BMCT are inherently static, with value derived not only from the desirability of the collection to which the collectible belongs, but also from the rarity of one or more asset-specific characteristics represented by the token or reference graphic file. In the current NFT landscape, there are few opportunities to interact with digital collectibles other than loading graphic files as social media profile pictures or importing collectibles / assets into third-party software applications to be "used" by characters or used to influence gameplay features. [Brief explanation of the drawing]

[0010] [Figure 1] This is a schematic diagram illustrating the timeline progression of evolution-dependent locking for cryptographic digital assets.

[0011] [Figure 2] This is a schematic diagram illustrating the evolutionary process of cryptographic digital assets as they evolve through one or more external trigger events.

[0012] [Figure 3] This outlines the evolutionary progression of cryptographic digital assets incorporating one or more external factors that facilitate the outcome of evolutionary locking.

[0013] [Figure 4] This is a schematic diagram showing how to merge a base item with a skin vial sub-asset, which has uncertain results, to generate one of six different outcomes.

[0014] [Figure 5] This is a schematic diagram illustrating the evolutionary progression of skin vial sub-assets, whose outcomes are uncertain, to produce different results after use / integration with the base asset, and the results depend at least partially on the evolutionary state of the evolving sub-assets.

[0015] [Figure 6] A schematic flowchart showing the merging of a second skin vial sub-asset with an uncertain result with a previously skinned base asset to generate a newly skinned base asset and a newly created skin vial.

[0016] [Figure 7A] A schematic graphic display image providing a perspective view of a digital skin vial sub-asset integrated into a basic level version of a digital collectible.

[0017] [Figure 7B] A schematic graphic display image showing a magnified view of the vial of FIG. 7A inserted into the digital collectible of FIG. 7A.

[0018] [Figure 7C] A schematic graphic display image showing a side view of a digital skin extending across the entire base level version of a digital collectible.

[0019] [Figure 7D] A schematic graphic display of the digital collectible of FIG. 7C with the digital skin fully applied. **DETAILED DESCRIPTION OF THE INVENTION**

[0020] Broadly speaking, the concepts described herein relate to digital collectibles and NFTs and achieve an enhanced level of interactivity and user engagement. In this architecture / method, limited executions of dynamic digital collectibles may be minted in batches, and then their owners / holders may be given the option and / or functionality to selectively lock copies of the collectibles at any stage of their dynamic evolution. In some embodiments, different downstream opportunities / benefits / capabilities may follow in response to when the asset is locked.

[0021] By enabling direct user participation and control over evolving digital assets, this technology can provide a more actively engaged ownership community, resulting in a more enjoyable user experience and increased desirability of asset ownership and brand engagement.

[0022] The method begins by creating and / or minting multiple encrypted tokens (BMCTs) in batches via a single or common digital contract registered on a blockchain-based distributed ledger (i.e., a "smart contract," such as an ERC1155 contract). At the time of minting, each encrypted token / associated digital asset may be substantially identical to all others except for having a different token-specific ID number. The smart contract and / or BMCT may include metadata that references an on-chain or off-chain file repository storing one or more data files and / or graphic files. The file repository may be an internet-connected server, a cloud-based computing platform, or a peer-to-peer / distributed file system such as the InterPlanetary File System (IPFS) developed by Protocol Labs. The identified graphic files stored in the file repository may provide a graphic representation of the digital asset 32 (shown in FIG. 1) that may be common to each BMCT issued via the registered smart contract. The created BMCTs may be distributed to multiple different token holders, such as by requesting or instructing a transfer via an established blockchain protocol.

[0023] As schematically shown in Figures 1 and 2, the digital asset 32 ​​may include at least one characteristic / attribute configured to dynamically evolve through multiple evolutionary stages over a period of time and / or in response to one or more events. These dynamically evolving characteristics can take various forms and be implemented in various ways. For example, in some configurations, the characteristic is a visual element 38 of the digital asset, while in other configurations, the evolving characteristic may include non-visual parameters 40, such as performance attributes, that define how the digital object behaves or how it affects other objects when the asset is imported into a video game type software application.

[0024] In embodiments where the evolving attribute is a visual element 38 of the digital asset, the visual element may include a complete graphic representation of the digital asset ("image"), a portion of the image, a layer of the image, or one or more elements that are added to the image only after a conditional event has occurred. Examples of potentially evolving graphic attributes include color, graphic stickers, decorations, attribute size, visual continuity, background, text identifiers, state identifiers, and the like.

[0025] When dynamically evolving traits are elements of the graphical representation of assets or graphic files, modifying this integrated visual element may require changing the pointer to the graphic file (i.e., the token is redirected to a different file or file location) or simply replacing the original source file in the file repository. In some embodiments, to more easily identify the evolutionary state of the dynamic trait, a digital record of the evolution and / or properties of the evolving trait may be stored alongside the graphic file. This digital record may be provided, for example, in an accompanying data file, metadata associated with the graphic file, or as a digital code provided on the image itself (e.g., a QR code® displayed on the graphic).

[0026] In embodiments where the evolutionary attribute is a non-visual parameter 40, the attribute may include a distinct alphanumeric identifier (e.g., Level 1 (L1), Level 2 (L2), Level 3 (L3), Level 4 (L4)) that can function as a qualitative or quantitative identifier of the magnitude of some characteristic, such as level, experience, power, evolutionary stage, or event ID. This dynamically evolving characteristic or attribute may be stored in a data file in a file repository, or in combination with a graphic file describing the digital asset. Such a data file may define one or more performance attributes that define how the digital object behaves or how it affects other objects when the asset is imported into a video game type software application, for example. Examples of such parameters include strength, agility, health, level, power boost, etc. The dynamic evolution of the asset may simply be responsible for randomly changing one or more of these parameters, or increasing / leveling up one or more of these parameters.

[0027] In many embodiments, the dynamic attribute may be an integrated aspect of the BMCT (i.e., inseparable from or directly identifiable from the data or graphics associated with the BMCT), while in other embodiments, the dynamic attribute may be its own separate sub-asset simply referenced by the primary digital asset / BMCT. More specifically, in some configurations, the evolving attribute may have its own tokenized existence, identified within or referenced by the BMCT. In such a nested architecture, evolutionary changes to the evolving attribute may occur only within the code or control of this second-tier attribute token. A detailed disclosure of this nested attribute concept is found in U.S. Patent Application No. 17 / 701,237, filed on 22 March 2022 and issued as U.S. Patent No. 11,475,449, which is incorporated herein by reference in its entirety.

[0028] Figure 1 schematically illustrates an example of a digital asset 32 ​​represented as a cuboid container with an outer surface 42 configured to dynamically evolve from a substantially intact initial state 44A through the progression of successive evolutionary states 44B, 44C, and 44D that gradually decompose and / or decompose. In this embodiment, the evolving visual attribute 38 is the visual continuity / integrity of the outer container structure. Furthermore, this example also provides non-visual parameters 40 (i.e., evolutionary level) that accompany the asset 32 ​​and evolve concurrently with the progressing degradation of the visual outer surface 42.

[0029] Figure 2 schematically illustrates a second example of a digital asset 32, represented as an image of a shoe (visual attribute 38) configured to dynamically evolve through the progression of evolutionary stages 50A, 50B, and 50C. Further illustrated, the digital asset includes several non-visual parameters 40 configured to evolve in each stage. As shown in the illustration, these non-visual parameters 40 may include attributes that qualitatively define how each asset behaves when imported into a digital video game-style environment and worn by a user's avatar.

[0030] Attribute evolution Once a BMCT is defined and created, one or more dynamic attributes may evolve discretely or continuously over time. In discrete or partial evolution, the attribute progresses through multiple perceptually distinguishable evolutionary stages, the transitions are recognizable, and each stage is maintained for a certain period (e.g., several days / weeks). In continuous evolution, the attribute progresses through a number of sufficiently small changes, and two temporally adjacent states become almost indistinguishable on their own (i.e., the overall transition is closer to a stepwise change). In practice, due to the limitations of modern computing, the difference between discrete and continuous may be merely a matter of degree. Discrete evolution may have fewer than 1,000, fewer than 100, fewer than 50, or fewer than 10 discrete evolutionary stages, while continuous evolution may have more than 1,000, more than 5,000, more than 10,000, or more than 100,000 discrete stages. Examples of discrete evolution are shown in Figures 1 and 2. Other examples include increasing an asset's experience level by an integer value from 0 to 50, or cycling through the seven main colors of the rainbow for a visual attribute. Conversely, examples of continuous evolution include the experience level increasing every second or minute for as long as the token exists (since Mint), or the visual attribute's color cycling through the colors of the rainbow in increments of 5000 or more (compared to just 7 times in discrete examples).

[0031] Generally, the evolution of dynamic attributes may occur in response to some predefined event, occurrence, condition, or action. In some configurations, the condition may simply be the passage of time (for example, if the transition occurs in response to a clock increment, the addition of a new block to the blockchain, etc.). In other configurations, the condition may be a random number generator that outputs a number within a predefined range, or a specific function that outputs a predefined result or sequence. In yet another configuration, the evolution may occur at the discretion of the asset manager (for example, by an administrator replacing a file on a file server).

[0032] In some configurations, dynamic attributes may evolve in direct response to one or more external trigger events (e.g., trigger event #1 60 and trigger event #2 62, as shown in Figure 2). Such trigger events may be outside the direct control or prediction of the smart contract and may rely on appropriate import filters, APIs, blockchain oracles 64, or other similar mechanisms to detect and utilize them. In some embodiments, these trigger events have a probabilistic probability of occurring (e.g., the outcome of a sporting event or playoff / postseason performance, an athlete's in-game statistics or career highlights, election results, etc.) and may occur within the real / physical world or a digital / virtual environment or a game environment. In some embodiments, an appropriate blockchain oracle 64, such as one provided via the CHAINLINK blockchain protocol, may function as a distributed knowledge source from which these trigger events can be derived.

[0033] External trigger events that cause attribute evolution may further include the result of one or more activities that require (or encourage / incentive) group / community participation. For example, in one example, a dynamic attribute may evolve in response to a community (e.g., a group of BMCT asset owners) completing one or more predefined group challenges. Such evolutionary models help to increase awareness of engagement and interconnectivity within the owner base and strengthen ownership and brand loyalty. Examples of group challenges include achieving a predefined total number of social media "likes" for each asset, achieving a predefined number of asset uses / imports within social media digital platforms or one or more video game-type software applications, achieving various collective milestones (e.g., asset valuation or ranking within a predefined asset pool), and / or solving one or more problems.

[0034] Selective evolutionary lock As mentioned above, after the creation of these BMCTs with evolving attributes, token holders may be provided with a mechanism to selectively freeze their assets in their current state so as to prevent further evolution of the dynamic attributes / characteristics (typically shown in 70 in Figure 1). This act of freezing or locking the evolution allows holders to maintain their assets (or identical substitutes) indefinitely in their locked state (e.g., locked / replica-locked tokens 72B, 72C, 72D corresponding to the evolved states 44B, 44C, 44D in Figure 1). Alternatively, in some embodiments, holders may be provided with one or more derivative assets / tokens 74A, 74B, 74C, 74D based at least partially on the evolved state of the BMCT at the time the lock request was made.

[0035] In some configurations, such lock events may occur and may be provided within the standards used to create the tokens. For example, if one BMCT holder (among several BMCT holders under a common agreement) wants to freeze the state of their tokens, a redemption feature may be toggled to move the tokens from group-level attributes (i.e., attributes commonly shared with multiple other batch mint tokens) to token-specific attributes that uniquely identify each token (i.e., individual attributes, a pointer to a graphic file, etc.).

[0036] In another embodiment, to selectively lock or freeze the state of an evolving BMCT, a user may selectively exchange one or more unique cryptographic tokens (UCTs) and / or BMCTs corresponding to the exchanged BMCT (i.e., the UCTs and / or BMCTs have one or more attributes or properties that are at least partially derived from the state of the evolving BMCT at the time of exchange). To facilitate the exchange, a server or computing node may receive a request from the owner or holder of the BMCT to facilitate the lock / exchange. At that point, the server may examine the current parameter space of the evolving BMCT to determine which attributes have evolved since creation and to what extent. Such an examination may include accessing a file repository to examine the current state of the graphic files, the metadata associated with the graphic files, and / or other data files associated with or potentially referenced by the evolving BMCT.

[0037] Once the parameter space of the evolving BMCT is understood, the server may generate a UCT, such as an ERC721 token, and / or a BMCT, such as an ERC1155 token, which include at least one parameter or attribute partially derived from the state of the evolving attributes in the BMCT at the time of the request. In some embodiments, the UCT may be an exact replica of the BMCT at the time the lock request was made. In other embodiments, the UCT may be visually different from the graphical representation of the evolving BMCT, but may have one or more aspects independently derived from the state of the dynamically evolving characteristics. For example, in the embodiment shown in Figure 1, the evolving BMCT may be represented as a cuboid object, but at exchange, a corresponding UCT digital shoe or BMCT digital skin vial may be created by the server at the time of exchange. This digital skin vial may be an attribute-modifying sub-asset that can be used to change predefined attributes of higher-level assets such as silhouettes or atypical versions of shoes (e.g., colorway, silhouette, decoration, shoelaces, background, dynamic motion / animation, degree of cartoon rendering). This digital skin vial may have various states or design themes derived or created as a result of the state of the cube at the time of request. Similarly, in some embodiments, instead of creating derivative attribute-modifying sub-asset UCTs / BMCTs such as vials, the server may create UCTs of higher-level / primary assets, such as an entire shoe of its own design.

[0038] In some embodiments, multiple UCTs may be created in response to an exchange / lock request. More specifically, the server does not need to adhere to a 1:1 create / exchange model and can generate multiple UCTs in response to a request to lock a single evolving BMCT. In one embodiment, the server may create a first UCT (e.g., derived assets 74A-D) derived from the evolving state of the BMCT at the time of the request, and also create a second UCT (e.g., replica assets 72B-D) which is a replica of the BMCT at the time of the request. The first UCT may be a primary asset (e.g., shoes, clothing, game tools, accessories, weapons) or a secondary asset (e.g., color, function, overlay, special ability), but may derive at least one property / attribute from the evolving state of the BMCT at the time of the request.

[0039] In some embodiments, the server may consider various additional auxiliary data when generating UCTs. For example, the server may rely on data from external sources such as date / time, oracles (or other repositories of real-world data / events / knowledge), geospatial data (such as identifying the location where the request was made), or the presence of other registered assets (such as booster assets) in the owner's wallet or account. An example of using such auxiliary data would be if a lock request was made while physically attending a basketball or football championship game, the server could generate a sports-themed or commemorative UCT. Conversely, if a lock request was made elsewhere (even though both requests were made simultaneously and the evolutionary states of the BMCT assets were different), the server could generate UCTs with different properties.

[0040] In another example, as shown in Figure 3, the BMCT digital asset 80 may be provided to all season ticket holders in a particular sports league at the start or end of the season. The server may recognize a request to lock the evolution state of the token only if the request occurs while participating in a game (recognized by geolocation input 82). One or more elements of the generated UCT 84 (i.e., generated by the server in response to a request to lock 70) may correspond to the evolution state of the BMCT (i.e., dynamically evolving attributes may be counters used to identify which games of the season or playoffs are currently "live" games). Furthermore, other properties / attributes of the generated UCT may correspond to significant events in that game (e.g., scoring leaders, player milestones, division / conference / league champions, etc.) which may be obtained from sports knowledge, statistical databases, or external repositories of the blockchain oracle 64. Such a “game” of choosing when to exchange BMCT may involve an element of chance regarding whether to wait for a better or more noteworthy game to lock in, or whether the current game presents a compelling reason to request / exchange.

[0041] Upon receiving a lock request and generating one or more corresponding UCTs, the server may instruct, request, or otherwise execute to transfer the generated UCTs to the wallet or account of the original requesting party. Thus, from the user's perspective, the user may request a lock and, in response, receive one or more corresponding digital collections. In some embodiments, the original BMCT on which the lock was requested may transition to an inactive state (e.g., switched to an empty graphic file or designated as "written" or "redeemed") or be transferred to an account or wallet associated with the server or content creator (i.e., that wallet may exist solely for the purpose of collecting redeemed BMCTs). In this way, the user may effectively exchange a BMCT for one or more UCTs based on the BMCT. As yet another example, in the sports example above, if the organizer's intention was to use BMCTs to offer prizes to a specific class of ticket holders (such as season ticket holders or ticket holders who purchase directly from the team / league rather than a third-party marketplace), the original BMCT may not be burned at all. In that case, multiple lock requests may be made without affecting the underlying BMCT.

[0042] Downstream opportunities While UCTs themselves may possess some extrinsic value based on their collectibility, appearance, etc., in some embodiments, UCTs may also provide some intrinsic value to the owner / holder by unlocking new opportunities or increasing the likelihood of certain opportunities becoming available. For example, in some embodiments, a UCT may be exchanged for one or more physical products, including but not limited to physical items having an appearance, look, or similarity that matches or is derived from the graphic file / image associated with the UCT, or having more general characteristics (e.g., limited production (approximately 100-5000 units)). In some embodiments, a UCT may influence the possibility of the owner receiving secondary benefits, such as the availability of various physical retail products, access to specific events or the opportunity to purchase advance tickets, digital access to unique experiences in virtual or mixed reality environments, or the ability to receive or purchase various tertiary digital assets. For example, owning a particular UCT or a UCT with certain characteristics may increase the likelihood of winning a virtual lottery for a limited release product, such as by increasing the number of entries in the lottery, increasing the probability of winning, or improving one's position in the virtual line. Further disclosures of such lottery-based product sales and virtual lines are contained in U.S. Patent No. 11,295,318, issued on April 5, 2022, which is incorporated in its entirety by reference.

[0043] In some embodiments, all UCTs generated from a common BMCT agreement may belong to a common UCT collection or a common UCT genus. Therefore, there is an opportunity to “airdrop” or gift subsequent UCTs to any UCT holder within that collection.

[0044] In one embodiment, the method may further include transferring a subsequent dynamically evolving BMCT90 (the second-generation cube shown in Figure 1) to the holder of the first BMCT when a request is made to freeze, lock, or burn (i.e., destroy) the first BMCT. Thus, the game may not end even if the first BMCT is replaced / locked, and user engagement may continue (revenue may decrease with each subsequent replacement / lock). The digital image associated with the subsequent BMCT90 may be identical to the original / pre-evolution version of the first BMCT. Alternatively, the second BMCT may have one or more characteristics (such as color, text, or style) that help to visually distinguish it from the first BMCT.

[0045] Silhouette and skin In some configurations, when the originally distributed BMCT is exchanged or locked, the token owner may receive a new BMCT or UCT containing a digital image similar to a silhouette or other base-level article version, as shown in Figure 4, 100. In some embodiments, this article may be footwear, clothing, a vehicle, a tool, or other similar article. Furthermore, or instead, the token owner may receive one or more UCTs representing sub-assets, skins, or skin vials 102 that can be applied to the silhouette. Such sub-assets may include, for example, unique colors, textures, patterns, digital features (e.g., if imported into a video game), decorations, backgrounds, animations, features, visual overlays, etc. In some embodiments, a skin vial may represent a combination of multiple potential skins or attributes. For example, as shown in Figure 4, combining the base-level article 100 with a skin vial 102 may yield any of the six illustrated results 104A, 104B, 104C, 104D, 104E, or 104F.

[0046] Token holders, upon acquiring one or more sub-assets (through the initial exchange or subsequent independent purchases), may submit requests to combine them with the silhouette / base version to create a custom or upgraded version of the base item. In some embodiments, combining a skin vial (or a similar item that does not visually define the final result) with the base-level version of the item may generate a final skin version of the item that is only ultimately revealed to the user after the combination.

[0047] As schematically shown in Figure 5, in some configurations, a secondary asset (e.g., skin vial 102) may be adapted to evolve dynamically in a manner similar to the BMCT described with respect to Figures 1 and 2. In this embodiment, the evolution of skin vial 102 may occur primarily in a non-visual manner, although small visual attributes may also be modified to indicate that evolution is taking place. As shown in Figure 5, as skin vial evolves through multiple evolutionary states 110A, 110B, 110C, and 110D, merging with base article 100 may result in the generation of corresponding different visual representations 112A, 112B, 112C, and 112D (i.e., skin may have different characteristics or visual appearances that are at least partially drawn or derived from the evolutionary state at the time fusion / use occurred).

[0048] Such combinations of base assets and skins may be performed within a predefined digital / computing environment in which these assets can be linked and combined without altering the underlying tokens. In this configuration, the linking of assets may rely, for example, on a database registration or cross-referencing mechanism. In another embodiment, the linking / combining may involve annotating the metadata of the primary asset to reference UCTs representing secondary assets, as described in U.S. Patent Application No. 17 / 701,237.

[0049] In some configurations, multiple UCT sub-assets can be applied to a single base silhouette to create unique combinations or hybrids between skin styles. In this configuration, an associated server, digital engine, or virtual environment may generate generative combinations of sub-assets, each representing complementary elements on the silhouette. Such combinations may be created in a manner that adheres to one or more predefined style guidelines or rules that may govern potential mergers. Alternatively, the combinations may rely on a machine learning model, which may create designs for the provided skins according to patterns extracted from a predefined product portfolio. For example, in the shoe example, the machine learning model may be trained on a specific manufacturer's past product releases / designs to understand how to best combine skins while adhering to the manufacturer's established design language for that silhouette.

[0050] As shown in Figure 6, in some embodiments, instead of creating a generative merge of skins, a second or subsequently applied skin vial 120 may operationally reskin the base article 100 previously skinned by the first skin vial 122. In some configurations, this reskinning may result in a third skin vial 124 being minted and returned to the user, as if the initially applied skin had been removed from the article. This third skin vial 124 may be equivalent to or substantially identical to the first skin vial 122, and if the skin vials are embodied as BMCTs, the third skin vial 124 may be minted from the same contract used to create the first skin vial 122.

[0051] Figures 7A–7D schematically illustrate embodiments of graphical merging of a primary asset (e.g., a base version of shoe 140) and a secondary asset (e.g., a digital skin vial 142). As described above, during merging, the tokens embodying vial 142 (e.g., via nested references to the secondary asset token) may be burned, transferred to a burn wallet, or nested in the primary asset's code. Regardless of what happens at the token level, in one configuration, the graphical representation of the vial may be merged into the graphical representation of a higher-level asset (i.e., shoe). Furthermore, as illustrated, the skin 144 obtained from the vial may also be applied to the shoe (and may spread across the entire shoe, as schematically shown in Figure 7C). Such merging may be displayed to the user via a server that operationally combines the assets. Also, in some embodiments, the server may further modify the graphic files of the primary asset to include the secondary asset. In some embodiments, to facilitate skin removal, the secondary asset may be applied as a masking layer on top of the existing shoe graphic (which may be maintained in an unaltered form on the base layer of the image). In embodiments where secondary assets are burned or sent to a burn wallet, the graphical representation of the skin and / or vial may be stored by the server in a file repository, and the merged graphics combination may be integrated into (or instructed to be written to) the metadata of the primary asset, overwrite existing graphics files, or be kept private as a merged asset by the server.

[0052] As described above, in some embodiments, a user may submit a request to make the upgraded / skinned silhouette available for retail sale in physical form. Similarly, the upgraded / skinned item can be imported into a digital software application / video game, as generally described in U.S. Patent No. 11,308,184. This patent incorporates all of its contents and disclosures by reference.

[0053] Furthermore, the above technologies can be implemented in various forms. While NFT technology is consistently referenced, this technology may be implemented through one or more public blockchains, private blockchains, or by incorporating one or more sidechains, smart contracts, databases, etc.

[0054] Furthermore, it is important to understand that this concept of locking evolving assets or creating derived assets from evolving assets can be used in various ways. In one particular embodiment, an evolving ERC1155 collectible may be locked / burned / exchanged for one or more ERC1155 skin vials that act to modify an ERC721 base article and / or an existing ERC721 base article. The ERC1155 skin vials can be configured to evolve dynamically so that when the skin vial is applied to or merged with a base article, different results are produced in response to the evolution state of the vial. In addition, the vial may have a suite of potential skins to choose from (for example, when the vial is applied to a base article, one of eight applicable skins may be probabilistically selected). If the vial evolves, each skin and skin option may also evolve, although the rate and extent of evolution may differ. Once a base article is skinned using the vial, the vial may be burned or transferred to a burn wallet managed by the content creator for that purpose. As described above, if a subsequent vial is then applied to a base article to which a skin has been applied, the server may create a generative merge or a descendant digital asset (such as those described in U.S. Patent No. 10,505,726, which is incorporated in its entirety by reference) based on the combination of characteristics, or extract the first vial / skin (remove the skin and recreate the vial) before applying the subsequent vial.

[0055] In other configurations, locking an evolving ERC1155 collectible may create a replica ERC721 collectible based on, or an exact copy of, the evolving ERC1155 collectible at the time of locking. Furthermore, other derived ERC721 collectibles may be created / exchanged at locking, each deriving at least one property from the evolving state of the ERC1155 collectible, but they may not be identical. Finally, locking an ERC1155 collectible may result in the owner receiving one or more other evolving ERC1155 collectibles in return, which may then be selectively locked in much the same way as the original ERC1155 collectible.

[0056] While previous disclosures have primarily focused on footwear, similar concepts may also apply to clothing, accessory items that may be useful in video games, commemorative trading cards, sports tickets, concert tickets, event tickets, and the like.

[0057] This technology creates a new paradigm and applications for NFT collectibles, where owners no longer need to own photos created by others. Instead, this architecture and method of exchanging and locking NFT assets provides a gamified, interactive experience, allowing owners to participate in the design, collect, and modify NFTs at their own discretion. This brings end-user control, brand integration, and a more dynamic experience to areas that were previously simple and static.

[0058] In some embodiments, aspects of this disclosure may be implemented through computer executable instruction programs, such as program modules commonly referred to as software applications or application programs, which are executed by one of the controllers or variations of controllers described herein. The software may include, in some, routines, programs, objects, components, and data structures that perform specific tasks or implement specific data types. The software may form interfaces that allow the computer to respond to input sources. The software may work in conjunction with other code segments to initiate various tasks in response to received data, in conjunction with sources of received data. The software may be stored in various memory media, such as CD-ROMs, magnetic disks, bubble memory, and semiconductor memory (such as various types of RAM or ROM).

[0059] Furthermore, aspects of this disclosure may be implemented in a variety of computer systems and computer network configurations, including multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, and mainframe computers. In addition, aspects of this disclosure may be implemented in a distributed computing environment in which tasks are performed by resident and remote processing devices linked over a communication network. In a distributed computing environment, program modules may reside on both local and remote computer storage media, including memory storage devices. Thus, aspects of this disclosure may be implemented in relation to various hardware, software, or combinations thereof within a computer system or other processing system.

[0060] Any method described herein may include machine-readable instructions executed by (a) a processor, (b) a controller, and / or (c) other suitable processing unit. The algorithms, software, control logic, protocols, or methods disclosed herein may be embodied as software stored on tangible media such as flash memory, CD-ROM, floppy disk, hard drive, digital versatile disk (DVD), or other memory devices. The algorithms, control logic, protocols, or methods as a whole, and / or parts thereof, may also be executed by devices other than controllers and may be incorporated into firmware or dedicated hardware in any available manner (e.g., implemented by application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable logic devices (FPLDs), discrete logic, etc.). Furthermore, while certain algorithms are described with reference to the flowcharts provided herein, many other methods for implementing the exemplary machine-readable instructions may be used instead.

[0061] While aspects of this disclosure are described in detail with reference to illustrated embodiments, those skilled in the art will recognize that many modifications can be made without departing from the scope of this disclosure. This disclosure is not limited to the exact configurations and structures disclosed herein, and any modifications, changes, and variations evident from the foregoing description are within the scope of this disclosure as defined by the appended claims. Furthermore, the concepts of the present invention expressly include any and all combinations and subcombinations of the elements and features described herein.

[0062] The following sections provide various embodiments and / or additional embodiments of the Technology. These sections should be read and interpreted in light of the preceding disclosures and are intended to supplement the disclosures, not to limit them.

[0063] Item 1. A method for selectively locking cryptographic digital assets, A step of instructing or requesting the creation or minting of multiple first crypto tokens via a first common digital contract registered on a distributed ledger, wherein each of the multiple crypto tokens is defined as a digital asset that includes attributes that operate to evolve or change through multiple evolutionary stages, The steps include instructing the transfer of multiple cryptocurrency tokens to multiple token holders, The steps include receiving a request from one token holder among multiple token holders to selectively lock a digital asset defined by one of multiple cryptocurrency tokens at one of multiple evolutionary stages, A method comprising the steps of: instructing or requesting a token holder to transfer a second cryptocurrency token, wherein the second cryptocurrency token has at least one attribute that is at least partially derived from the evolutionary stage of the digital asset at the time of the request.

[0064] Section 2. The method described in Section 1, wherein the attribute operates to evolve or change in response to an external trigger event.

[0065] 3. The method described in Section 2, wherein the external trigger event is an event that occurs in the real / physical world, or in a digital / virtual environment or game environment.

[0066] Item 4. The method described in Item 2, The steps include receiving an indication via a blockchain oracle that an external trigger event has occurred, The further step includes modifying an attribute in response to an indication that an external trigger event has occurred.

[0067] Item 5. A method described in any of Items 1 to 4, wherein the attribute is an element of the graphical representation of the digital asset or a distinct alphanumeric identifier.

[0068] Item 6. A method by any of Items 1 to 5, which includes a request to selectively lock digital assets from a token holder, and which includes a request to exchange a first cryptocurrency token for a second cryptocurrency token.

[0069] Item 7. A method according to any of Items 1 to 6, further comprising the step of receiving an indication of the location of a token holder, and instructing or requesting that a second cryptographic token be transferred to the token holder, unless the location of the token holder is within a predetermined distance from the predetermined location.

[0070] Article 8. The method described in Article 7, The process involves receiving a request from a second token holder among multiple token holders to selectively lock a digital asset defined by one of multiple cryptocurrency tokens at one of multiple evolutionary stages, A step of receiving an indication of the location of a token holder, wherein the location of the token holder is within a defined distance from a defined location, and the location of a second token holder is not within a defined distance from a defined location. A step of instructing or requesting that a third cryptographic token be transferred to a second token holder, wherein the third cryptographic token has at least one attribute that is at least partially derived from the evolutionary stage of the digital asset at the time of the request, and the second and third cryptographic tokens have at least one distinct attribute.

[0071] Item 9. A method of any of Items 1 to 8, further comprising the step of instructing or requesting, after instructing or requesting, to transfer the second cryptocurrency token to the token holder, to burn or transfer the first cryptocurrency token to a burn wallet.

[0072] Item 10. A method according to any of Items 1-9, wherein the second cryptographic token represents a secondary asset or skin, and the secondary asset or skin can be combined with a primary digital asset to modify the attributes of the primary digital asset.

[0073] Item 11. A method according to any of Items 1 to 10, wherein the multiple first cryptographic tokens are ERC1155 tokens created in accordance with the Ethereum Improvement Proposal (EIP)-1155, and the second cryptographic tokens are ERC721 tokens created in accordance with the Ethereum Improvement Proposal (EIP)-721.

[0074] Item 12. A method for managing digital assets represented by cryptographic tokens, A step of instructing or requesting the creation or minting of multiple initial cryptographic tokens via a first common digital contract registered on a distributed ledger, wherein each token represents a digital asset having at least one attribute that can evolve through multiple evolutionary stages, The steps include distributing multiple initial cryptocurrency tokens to multiple token holders, A step of monitoring one or more external trigger events that may affect the evolution of at least one attribute, A step of updating at least one attribute of a digital asset in response to an external trigger event, The process involves receiving a lock request from a token holder to selectively lock a digital asset defined by one of the initial cryptographic tokens at a specific stage of evolution, and Steps include instructing or requesting the creation or minting of subsequent cryptographic tokens that capture the state of a digital asset at a specific stage of evolution, This includes the step of instructing or requesting that the subsequent cryptocurrency token be transferred to the token holder's digital wallet or account.

[0075] Section 13. The method described in Section 12, wherein the external trigger event is an event that occurs in the physical world, a digital or virtual environment, or a video game environment.

[0076] Item 14. A method according to any of items 12-13, wherein the step of monitoring one or more external trigger events includes receiving input from a blockchain oracle and verifying and processing the occurrence of the external trigger events.

[0077] Section 15. A method described in any of Sections 12-14, wherein at least one attribute of the digital asset includes a visual or graphical representation, an alphanumeric identifier, or a combination thereof.

[0078] Item 16. A method according to any of items 12-15, wherein a lock request from a token holder includes a request to exchange an initial cryptographic token for a subsequent cryptographic token.

[0079] Article 17. A method described in any of Articles 12 to 16, The steps include receiving a lock request and simultaneously receiving an indication of the token holder's location, The further step includes applying geographical restrictions to subsequent transfers of cryptographic tokens based on the token holder's location relative to a predefined location.

[0080] Section 18. A method of any of Sections 12-17, further comprising the step of discarding the initial cryptocurrency after transferring the subsequent cryptocurrency to the token holder by transferring the initial cryptocurrency to a burn wallet or marking it as inactive.

[0081] Item 19. A method according to any of Items 12-18, wherein the subsequent cryptographic token represents a digital sub-asset or digital asset modifier that can be used in combination with the primary digital asset to modify one or more attributes of the primary digital asset.

[0082] Section 20. A method according to any of Sections 12-19, wherein the multiple initial cryptographic tokens are ERC1155 tokens created in accordance with Ethereum Improvement Proposal EIP-1155, and the subsequent cryptographic tokens are ERC721 tokens created in accordance with Ethereum Improvement Proposal EIP-721.

[0083] Item 21. An electronic computing system configured to perform any of the methods described in items 1 to 20.

Claims

1. A method for selectively locking encrypted digital assets, performed by a computer system, A step of instructing or requesting the creation or minting of a plurality of first cryptocurrency tokens via a first common digital contract registered on a distributed ledger, wherein each of the plurality of first cryptocurrency tokens defines a digital asset that includes attributes that operate to evolve or change through a plurality of evolutionary stages, The steps include instructing the transfer of the plurality of first cryptographic tokens to a plurality of token holders, The steps include receiving a request from one of the multiple token holders to selectively lock the digital asset defined by one of the multiple first cryptographic tokens in one of the multiple evolutionary stages, A method comprising the steps of: instructing or requesting the transfer of a second cryptographic token to the token holder, wherein the second cryptographic token has at least one attribute that is at least partially derived from the evolutionary stage of the digital asset at the time of the request.

2. The method according to claim 1, wherein the attribute operates to evolve or change in response to an external trigger event.

3. The method according to claim 2, wherein the external trigger event is an event that occurs in the real / physical world, or in a digital / virtual environment or a game environment.

4. The steps include receiving an indication via a blockchain oracle that the aforementioned external trigger event has occurred, The method of claim 2, further comprising the step of changing the attribute in response to an indication that the external trigger event has occurred.

5. The method according to claim 1, wherein the attribute is an element of the graphical representation of the digital asset or a separate alphanumeric identifier.

6. The method according to claim 1, wherein a request from the token holder to selectively lock the digital assets includes a request to exchange the first cryptographic token for a second cryptographic token.

7. The further step includes receiving an indication of the location of the token holder, The method according to claim 1, wherein the step of instructing or requesting the transfer of the second cryptographic token to the token holder is performed only if the location of the token holder is within a predetermined distance from a predetermined location.

8. The steps include receiving a request from a second token holder among the plurality of token holders to selectively lock the digital asset defined by one of the plurality of first crypto tokens at one of a plurality of evolutionary stages, A step of receiving an indication of the location of the token holder, wherein the location of the token holder is within a predetermined distance from the predetermined location, and the location of the second token holder is not within a predetermined distance from the predetermined location. The method according to claim 7, further comprising the steps of instructing or requesting the transfer of a third cryptographic token to the holder of the second token, wherein the third cryptographic token has at least one attribute that is at least partially derived from the evolutionary stage of the digital asset at the time of the request, and the second cryptographic token and the third cryptographic token have at least one different attribute.

9. The method according to claim 1, further comprising the step of instructing or requesting, after instructing or requesting, to transfer the second cryptographic token to the token holder, to burn or transfer the first cryptographic token to a burn wallet.

10. The aforementioned second cryptographic token represents a secondary asset or skin, and also, The method according to claim 1, wherein the sub-asset or skin can be combined with the primary digital asset to modify the attributes of the primary digital asset.

11. The method according to claim 1, wherein the plurality of first cryptographic tokens are ERC1155 tokens created in accordance with Ethereum Improvement Proposal EIP-1155, and the second cryptographic token is an ERC721 token created in accordance with Ethereum Improvement Proposal EIP-721.

12. A method for managing digital assets represented by cryptographic tokens, which is performed by a computer system, The steps of instructing or requesting the creation or minting of a plurality of initial cryptographic tokens via a first common digital contract registered on a distributed ledger, wherein each token represents a digital asset having at least one attribute that can evolve through a plurality of evolutionary stages, The steps include distributing the aforementioned multiple initial encrypted tokens to multiple token holders, The steps include monitoring one or more external trigger events that may influence the evolution of at least one attribute, A step of updating at least one attribute of the digital asset in response to the external trigger event, The steps include receiving a lock request from a token holder to selectively lock a digital asset defined by one of the aforementioned multiple initial cryptographic tokens in a specific evolutionary stage, The steps include instructing or requesting the creation or minting of a subsequent cryptographic token that captures the state of the digital asset at the aforementioned specific evolutionary stage, A method comprising the step of instructing or requesting that the subsequent cryptographic token be transferred to the digital wallet or account of the token holder.

13. The method according to claim 12, wherein the external trigger event is an event occurring in the physical world, a digital or virtual environment, or a video game environment.

14. The method according to claim 12, wherein the step of monitoring one or more external trigger events includes receiving input from a blockchain oracle and verifying and processing the occurrence of the external trigger events.

15. The method according to claim 12, wherein at least one attribute of the digital asset includes a visual or graphical representation, an alphanumeric identifier, or a combination thereof.

16. The method according to claim 12, wherein the lock request from the token holder includes a request to exchange the initial encrypted token for the subsequent encrypted token.

17. The steps include receiving the lock request and simultaneously receiving an indication of the token holder's location, The method according to claim 12, further comprising the step of applying geographical restrictions to subsequent transfers of cryptographic tokens based on the location of the token holder relative to a predefined location.

18. The method according to claim 12, further comprising the step of transferring the initial cryptocurrency to a burn wallet or marking it as inactive, after transferring the subsequent cryptocurrency to the token holder.

19. The method according to claim 12, wherein the subsequent cryptographic token represents a digital sub-asset or digital asset modifier that can be used in combination with the primary digital asset to modify one or more attributes of the primary digital asset.

20. The method according to claim 12, wherein the plurality of initial cryptographic tokens are ERC1155 tokens created in accordance with Ethereum Improvement Proposal EIP-1155, and the subsequent cryptographic tokens are ERC721 tokens created in accordance with Ethereum Improvement Proposal EIP-721.

Images