Multi-tier tokenization platform

Abstract

To provide a platform implementing a two-tier tokenization process to build a digital asset pool at a server.SOLUTION: An application adds user accounts to a two-tier tokenization platform, initializes general asset tokens for application users, creates a digital version of a financial or physical asset to add the asset to a general asset pool. Users register ownership and beneficial interest in some portion of the general asset pool. Specific asset tokens are created. Token transfers between users are processed. Payments for the users are generated. Asset information and application records are stored to a distributed ledger. A value of active general asset tokens and active specific asset tokens is updated. Frozen general asset tokens are reactivated and added to the general asset pool. Compliance verification is performed.SELECTED DRAWING: Figure 4

Description

[Technical field]

[0001] Cross-references to related applications This application claims priority to U.S. Provisional Application No. 62 / 743,859, filed October 10, 2018, and entitled “MULTI-TIER TOKENIZATION PLATFORM.” [Background technology]

[0002] Investment in large assets has been limited by both circumstances and technology to large entities with large financial resources existing in the same jurisdiction. For example, large illiquid asset types such as financing loans for infrastructure projects have historically been limited by several investment issues.

[0003] For example, participation in the financing of large infrastructure projects in the United States is limited primarily to large specialized financial institutions with a U.S. presence. Foreign institutional investors' access to large infrastructure financing transactions in the United States is limited by visibility, distance, language, and lack of local market knowledge. Furthermore, direct investor participation in large infrastructure projects or through specialized infrastructure funds is constrained by minimum investment requirements that typically exceed fundraising capacity.

[0004] Funding commitments for infrastructure funds or projects are strict and tend to be specific transactions where concentration risk is high. Limited liquidity is available to investors in the infrastructure sector, whether investing directly in projects or through specialized private equity funds. There are no technological systems that address the nuances of financing large assets such as infrastructure projects. Technical solutions to the problems associated with financing large projects and other types of illiquid assets are needed. Summary of the Invention

[0005] Broadly described, the technology provides a technical solution to the technical problem of providing a platform to address large assets and other types of illiquid assets. The technology's platform provides an automated, two-tier tokenization process that is machine-implemented, uses a distributed ledger system, and provides artificial intelligence-driven user support services. The technology provides a flexible technical solution to address any large assets in any geographical jurisdiction.

[0006] The platform of the technology implements a two-layer tokenization process to build a digital asset pool on one or more servers or machines. The application builds a digital asset pool, called a general asset pool, by creating digital representations of large-scale financial and physical assets. In some cases, the two-layer tokenization process uses computer protocols called smart contracts to digitally facilitate, verify, and manage the interaction and performance of one or more contracts associated with each token. These smart contracts can operate on one or more blockchains, which may be public or permissioned networks that restrict the users and transactions that are allowed to participate in the network. The use of smart contracts on blockchains allows transactions to be efficiently executed, often without a third party, and allows information about the token and its transactions to be traceable and immutable. A general asset token (GAT), with contractual functionality defined by the smart contract, represents pro-rata ownership interests in the general asset pool. Specific Asset Tokens (SATs), with contractual functionality defined by smart contracts, represent ownership interests in specific assets that are selected and removed from the general asset pool by users of the platform from remote devices communicating with one or more servers or machines. The general asset tokens, offered to qualified retail and / or institutional investors, generate funds to build the general asset pool. Holders of the general asset tokens are periodically offered by the servers the option to create specific asset tokens representing a portion of the overall assets from the general asset pool through a two-tier tokenization process, subject to the technology protocol, ownership concentration limits, and bidding and allocation schemes established by the platform.

[0007] By developing a custom portfolio of asset-specific tokens using general asset tokens, all created from assets available in the general asset pool and stored in memory by the platform, users of the platform can establish a desired level of exposure and diversification that reflects their risk / return preferences and any other investment criteria. Tokenization into general and specific assets using smart contracts makes asset tokens more easily tradable and achieves liquidity through smaller increments, even for traditionally illiquid asset types. Additionally, the system significantly increases liquidity through information by using various machine learning and artificial intelligence ("AI") tools to recommend trading ideas and continually drive transaction activity among users (e.g., investors).

[0008] In some cases, a method for providing a multi-tier tokenization platform is disclosed. The method includes initiating one or more generic asset tokens by an application on a first machine, the one or more generic asset tokens being associated with a plurality of users of the platform, each of the generic asset tokens having a first value, the one or more generic asset tokens being mapped by the application to values ​​of one or more assets in a generic asset pool. A request is received by the application to create one or more specific asset tokens using one of the one or more generic asset tokens that map to a portion of a specific asset from the generic asset pool, where the one or more assets include the specific asset. The request can be initiated from a remote machine associated with one of a plurality of users associated with one of the one or more generic asset tokens used to create the specific asset token. A first specific asset token is created that maps to a portion of the entire specific asset. The first specific asset token is based at least in part on the request data. A record of the generated specific asset tokens and an updated state of the generic asset tokens is stored.

[0009] In some cases, a system for providing a multi-tier tokenization platform includes a server having a memory and a plurality of processors. One or more modules are stored in the memory and executed by the plurality of processors. The modules are executable to activate one or more generic asset tokens by an application on a first machine, the one or more generic asset tokens associated with a plurality of users of the platform, the application to map one or more generic asset tokens created by the application to a generic asset pool stored in the memory, each of the generic asset tokens having a first value, and receive request data by the application to create one or more specific asset tokens using one of the one or more generic asset tokens that map to a portion of the entire specific asset. The request is initiated from a remote machine associated with one of the plurality of users associated with one of the one or more generic asset tokens used to create the one or more specific asset tokens. The one or more assets include the specific asset, creating a first specific asset token that maps to a portion of the entire specific asset token. The first specific asset token stores a record of the deletion of the generic asset token used to create the specific asset token that deletes some associated value from the generic asset pool based at least in part on the request data. [Brief description of the drawings]

[0010] [Figure 1A] FIG. 1 illustrates a block diagram of a system for providing protocols stored in a remote data store to a two-tier tokenization platform. [Figure 1B] 1 illustrates a block diagram of a system for providing a two-tier tokenization platform using a protocol stored on a local server. [Diagram 2] 1 illustrates a block diagram of an application for providing a two-tier tokenization platform. [Diagram 3]1 illustrates a block diagram of a protocol module. [Figure 4] 1 illustrates a method for providing a two-tier tokenization platform. [Diagram 5] 1 illustrates a method for creating an asset-specific token. [Figure 6] 1 illustrates a method for generating an allocation of a particular asset token. [Figure 7] 1 illustrates a method for processing a token transfer between a first user and a second user. [Figure 8] 1 illustrates a method for reactivating a frozen general asset token. [Figure 9] 1 illustrates a method for automatically providing asset recommendations to a user. [Figure 10] 1 illustrates a block diagram of a two-tier tokenization platform user case schematic. [Figure 11] 1 illustrates a block diagram of a flow chart of activities of a two-tier tokenization platform. [Figure 12] FIG. 1 illustrates a block diagram of a computing environment for implementing a two-tier tokenization platform. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Broadly described, the technology provides a technical solution to the technical problem of providing a platform to address large assets and other types of illiquid assets. The technology's platform provides an automated, two-tier tokenization process that is machine-implemented, uses a distributed ledger system, and provides artificial intelligence-driven user support services. The technology provides a flexible technical solution to address any large assets in any geographical jurisdiction.

[0012] The platform of the technology implements a two-layer tokenization process to build a digital asset pool across one or more servers or machines. The application builds a digital asset pool, called a general asset pool, by creating digital representations of large-scale financial and physical assets. The two-layer tokenization process uses computer protocols called smart contracts to digitally facilitate, verify, and manage the interaction and performance of one or more contracts associated with each token. These smart contracts can operate on one or more blockchains, which may be public or permissioned networks that restrict the users and transactions that are allowed to participate in the network. The use of smart contracts on blockchains allows transactions to be efficiently executed, often without a third party, and allows information about the token and its transactions to be traceable and immutable. A general asset token (GAT), with contractual functionality defined by the smart contract, represents a pro rata ownership interest in the general asset pool. Specific Asset Tokens (SATs), with contractual functionality defined by smart contracts, represent interests in specific assets that users of the platform select and remove from the general asset pool by providing input, for example, via remote devices that communicate with one or more servers or machines (collectively referred to herein as servers). The general asset tokens offered to qualified retail and / or institutional investors generate funds to build the general asset pool. Holders of general asset tokens are periodically offered the option to create specific asset tokens representing a portion of the overall assets from the general asset pool by the servers through a two-tier tokenization process, subject to the technology protocol, ownership concentration limits, and bidding and allocation schemes established by the platform.

[0013] By developing a custom portfolio of asset-specific tokens using general asset tokens, all created from assets available in the general asset pool and stored in memory by the platform, users of the platform can establish a desired level of exposure and diversification that reflects their risk / return preferences and any other investment criteria. Tokenization into general and specific assets using smart contracts makes asset tokens more easily tradable and achieves liquidity through smaller increments, even for traditionally illiquid asset types. Additionally, the system significantly increases liquidity through information by using various machine learning and artificial intelligence ("AI") tools to recommend trading ideas and continually drive transaction activity among users (e.g., investors).

[0014] The machine-based platform of the present technology has several advantages and provides technical solutions to several technical problems.

[0015] One of the technical problems is the lack of a technology platform to enable entities with more modest financial resources to directly participate in the financing of large financial or physical assets. There is no platform or technology solution that allows for small-scale participation in the financing of large assets.

[0016] The present technology solves this technical problem by providing a platform that allows for the digitization of assets using a two-tier cascading tokenization system. By digitizing the tokens in two tiers by an application on a server, the second tier provides a portion of the asset's equity as a digital token that can be stored and accessed, allowing users who do not have access to large financial assets or physical assets to participate in the platform in a streamlined and easy way to invest in the financing of large assets.

[0017] Another technical issue with large financial or physical asset fundraising is that the assets are not tied to technology that allows for decentralization through traditional platforms. Rather, investors who want to invest in large asset fundraising are limited to a single large investment through traditional banking technology.

[0018] The Platform solves this technical problem by providing computerized protocols and logic that allow, via a server implementing the Platform, to selectively create digital asset-specific tokens using digital general asset tokens. This selection allows users of the Platform to customize the portfolios that are created and maintained through the Platform. By utilizing the Platform's functionality, users can achieve desired levels of return and diversification profiles across assets at scale, functionality that was not possible with previous technologies. Thus, the Platform provides technical functionality that was not previously available.

[0019] Additional features and benefits of the Platform include, but are not limited to, the adoption of a bidding and allocation scheme that democratizes bidding for asset exposure. This allows for price discovery at intermediate intervals over the lifecycle of the stake, and allows for partial asset interests in the form of tokens that can be easily converted into cash or other assets and provide liquidity as needed. The System provides a Platform that is a scalable, autonomous, multi-party collaboration system that uses smart contracts to improve speed and establishes trust with immutable transaction records. All domestic and international parties can participate in the fundraising of financial or physical assets in local or remote jurisdictions by using digital tokens on the Platform. Technology-enabled compliance and enforcement features built into the Platform and embedded in the tokens ensure that all participants and activities continually meet the regulatory requirements of the jurisdictions they are active in. Furthermore, machine learning and artificial intelligence mechanisms (collectively referred to as "AI") allow participants to economically create portfolios that match their strategy, risk, return and other preferences, and promote asset token liquidity through ongoing portfolio recommendations, thereby encouraging trading of tokens among users.

[0020] In some cases, general asset tokens are mapped by the application to a general asset pool. Specific asset tokens are mapped to a specific asset portion of an asset in the general asset pool. The entire specific asset is associated with a real / financial asset. A reference to an "entire specific asset" may refer to a portion of the total obligation of a real / financial asset, but the entire specific asset is 100% (e.g., "entire") of the system's inventory of obligations.

[0021] FIG. 1A illustrates a block diagram of a system for providing protocols stored in a remote data store to a two-tier tokenization platform. The system 100 of FIG. 1A includes user machines 110, 120, and 130, a network 140, a server 150, an administrator machine 170, a data store 180, and a distributed ledger machine 190. Each of the user machines 110-130 may be associated with a user of the two-tier tokenization platform provided by the server 150. In some cases, the users may be investors in assets whose tokens are provided by the server 150. The users may interact with content pages, such as web pages provided via a network browser, web pages provided by the server 150, mobile applications, and other mechanisms implemented on the user machine, the server 150, or distributed across the user machine and the server 150.

[0022] Network 140 may route traffic between user machines 110-130 and server 150. Network 140 may also route some of the traffic, in some cases, between server 150, machine 170, data store 180, and distributed ledger machine 190. Network 140 may be implemented as one or more private networks, public networks, the Internet, an intranet, a local area network, a wide area network, a cellular network, a traditional telephone service network, a wireless network, a Wi-Fi network, a wired network, a peer-to-peer network, or other network suitable for communicating data between machines.

[0023] Administration server 150 may include one or more servers that provide the functionality discussed herein. In some cases, administration server may include multiple servers across which administration application 160 is distributed. Administration server 150 may include one or more network servers that act as an interface to network 140, handle network requests and responses, and can communicate with one or more administration servers 150.

[0024] Administration application 160 may include one or more modules, objects, and / or programs stored in memory of server 150 (which may be implemented by one or more physical or logical machines or servers) and executed by a processor of the server to perform the functions described herein. Administration application 160 is described in more detail with respect to FIG.

[0025] The administrator machine 170 may be associated with an administration account that can manage aspects of the two-tier tokenization platform implemented by the administration server 150.

[0026] Data store 180 may include one or more protocols 185. Protocols 185 may include logic, rules, modules, objects, and / or programs that may implement some of the functionality described herein. For payments of FIG. 1A, protocols 185 may be implemented in whole or in part remotely from administration server 150.

[0027] The distributed ledger machine 190 may be used to store and / or log data, information, updates, changes, and other information regarding the provision of the two-tier tokenization platform by the administration server 150. In some cases, the distributed ledger machine may implement a ledger implemented across a network of peers in the network, with each peer holding a copy of the complete ledger (e.g., a distributed ledger implemented with a blockchain).

[0028] Figure 1B shows a block diagram of a system for providing a two-tier tokenization platform using a protocol stored on a local server. The system 100 of Figure 1A includes user machines 110, 120, and 130, a network 140, a server 150, an administrator machine 170, a data store 180, and a distributed ledger machine 190. The system of Figure 1B is similar to the system of Figure 1A, except that the protocol 185 may be implemented entirely local to the server 150.

[0029] Figure 2 shows a block diagram of applications for providing a two-tier tokenization platform. Applications 200 of Figure 2 provide details of administration applications 160 of the systems of Figures 1A and 1B. Applications 200 include token management 210, asset pool manager 220, trading engine 230, portfolio manager 240, payment manager 250, compliance logic 260, and protocols 270.

[0030] Token management 210, as part of the two-tier tokenization system of the present technology, manages the general asset tokens and specific asset tokens. In particular, token management 210 may assign value and equity to general asset tokens and specific asset tokens, manage the general asset tokens used to create specific asset tokens, the movement of general asset tokens to repositories after they have been used to create specific asset tokens, and other aspects of token management.

[0031] The asset pool manager 220 may manage a general asset pool that contains digital representations of financial and real assets. In some cases, the asset pool manager 220 may update the pool state, register and manage the attribution of ownership and beneficial interests by users of general asset tokens and users of specific asset tokens in subscription events, move general asset tokens to a repository, and add general asset tokens from the repository back to the asset pool upon triggering events.

[0032] The trading engine 230 may handle the transfer of specific asset tokens between users of the system. In some cases, the trading engine 230 may manage the sale of specific asset tokens, offers to buy specific asset tokens, and trading of specific asset tokens between users of the system.

[0033] The portfolio manager 240 may track portfolios for users of the system. In some cases, the portfolio manager 240 can track general asset tokens and specific asset tokens in a user's profile, values ​​associated with the user's tokens, and can help the user select specific asset tokens that meet the user's objectives and criteria.

[0034] The payment manager 250 may process payments between users and between users and the platform. In some cases, the payment manager 250 may process fees paid by users to the platform for performing tasks and operations, insurance premiums paid by users to other users, and other payments processed by the system. In the case of assets that pay principal and interest, the payment manager may periodically calculate, process, and record the transmission of principal and interest to users of the general asset token or users of the specific asset token that hold interest vested in such payments.

[0035] Compliance logic 260 may include logic to ensure that the system operates in compliance with regulatory, legal, and tax constraints within the required jurisdiction. Protocols 270 include logic, rules, modules, objects, and / or programs that may implement some of the functionality described herein. Protocols 270 are discussed in more detail with respect to FIG.

[0036] Figure 3 illustrates a block diagram of a protocol module. Protocol module 300 of Figure 3 provides details of protocols 185 and 195 of Figures 1A and 1B, and protocol 270 of Figure 2. Protocols 300 include asset discovery and portfolio creation 310, securitization in place 320, two-tier asset digitization 330, cascading tokens 340, portfolio manager 350, exchange 360, custody 370, compliance and data conduit 380, and analytics 390.

[0037] Asset Discovery and Portfolio Creation (AD / PC) 310 functions to create general asset tokens, ultimately raise funds for onboarding asset purchases, and onboard new assets. The AD / PC protocol defines asset attributes to create digital representations of assets (e.g., generating asset tokens), embeds rules, drains tasks for general asset tokens from the general asset pool, sets completion rules, sets participation window timetables, sets the state of general asset tokens, and otherwise manages general asset tokens.

[0038] Securitization in Place (SIP) 320 includes a securitization token creation protocol. The SIP protocol creates asset-specific tokens on demand, which represent a percentage of a specific asset from a general pool. The SIP protocol can also provide for the deletion of asset-specific tokens from the platform ecosystem when the tokens reach a terminal value or otherwise meet a deletion condition.

[0039] Two-Layer Asset Digitization 330 provides a two-layer blockchain framework for users to interact with digital assets. Cascade Token 340 contains the rules for users and asset generators to interact with each other, both at regular intervals and on a rolling basis. Portfolio Management 350 is a set of protocols for users to manage their self-directed investments. Exchange 360 ​​contains the rules for users to interact with each other and the platform, both on a regular and rolling basis.

[0040] Custody 370 includes a set of protocols for holding, authorizing, registering, recording ownership interests and transactions, and managing the processing of client cash and tokenized securities, including hot and cold storage of newly created tokens for safekeeping, deposit of existing cash and tokens, and transfers related to purchases, sales, and settlements.

[0041] Compliance and Data Conduit 380 contains logic to actively ensure compliance with regulatory matters and internal controls by recording events and event data on the network, extracting data for governance, and enforcing governance and execution schemes (e.g., bidding and allocation schemes). Importantly, 380 is a data conduit for requesting and exchanging data from on-chain (e.g., distributed ledger systems) and off-chain (e.g., servers or local data stores) sources.

[0042] Analytics 390 is a suite of portfolio tools including portfolio monitoring, risk assessment, scenario analysis, and uses AI and machine learning concepts to utilize external data and data extraction to generate recommendations according to user-defined investment objectives.

[0043] In some cases, at least a portion of protocol 300 may be used to implement modules 210-260 of application 200. In some cases, the protocol may be implemented by modules 210-260 of application 200 of Figure 2. The protocols of protocol module 300 are discussed in more detail below.

[0044] 4 illustrates a method for providing a two-tier tokenization platform. At step 410, a user account may be added to the two-tier tokenization platform. In some cases, a user may ultimately be associated with both a general asset token and an asset-specific token. The user account may include user credentials, user investment objective data, contact data, and other data of the user.

[0045] At step 415, a general asset token may be activated for an application user. In some cases, a user may pay a fee to acquire an interest in a general asset token. Thus, each general asset token is associated with a value. After activation, at step 420, the application adds assets to a general asset pool by creating a digital version of the financial or physical asset. The holdings and value of the general asset pool so created are updated at step 425, and users of the general asset token register their ownership and beneficial interests in a portion of the general asset pool. The holdings in the general asset pool may include assets acquired by the system administrator using proceeds from the initial issuance of the general asset token and subsequent sales of the general asset token. Each general asset token holder has a pro rata interest in the value of the general asset pool, which is based on the value of the acquired assets, which are then represented in digital form.

[0046] The generation of general asset tokens can proceed according to the Asset Discovery / Portfolio Creation (AD / PC) protocol. The AD / PC protocol creates general asset tokens by implementing asset purchases, implementing new assets, creating homogenous digital assets to represent each asset, embedding rules and executing general asset token tasks, setting completion rules, setting a timetable for cast events, setting the state of general asset tokens, and otherwise managing general asset tokens. The AD / PC protocol is the interaction of tasks and data between the asset generator and the investor. The AD / PC protocol runs together with the Cascading Token Protocol, which is another set of rules between the asset generator and the user. It is activated by a switching mechanism from the AD / PC protocol and returns results to the AD / PC, which controls the state of the general asset token.

[0047] The AD / PC protocol is the basis for implementing each specific asset into the Framework ecosystem. Before each specific asset is electronically defined as a homogenous digital asset type, the AD / PC protocol converts legal rights and obligations into elements that can be incorporated into smart contracts. In summary, a pool of homogenous digital assets belongs to a general pool, whose economic value supports the creation of an inventory of general asset tokens in proportion to the underlying asset. A homogenous asset type can be a financial asset, a physical asset, or a pool of assets. Each equivalent unit will have identical rights and obligations. The definition of the AD / PC protocol contract begins with the allocation of the full initial value of the asset's contractual rights and obligations to the holders of the general pool. The AD / PC protocol also registers the offering of general asset tokens to comply with the regulations of the specific asset type and authority. Registration allows the Framework to offer general asset tokens to raise pooled funds in fiat currency from a large group of investors for asset purchases. Thereafter, at regular intervals called Cast Events, investors holding general asset tokens may initiate subscription requests using general asset tokens to create asset-specific tokens and build custom portfolios of asset-specific tokens. The customized combinations are self-driven, using available AI-guided recommendation tools created by the present Framework of AI Protocols described below.

[0048] General asset tokens are evergreen, or exist forever. However, general asset tokens can be active or "frozen" in a repository. The repository stores general asset tokens whenever a holder relinquishes all or an increment of general asset tokens to perform a task in the system. The repository acts as a wallet to store frozen general asset tokens. General asset tokens that enter the wallet are marked as frozen. General asset tokens in the repository can then be reactivated via an offer to raise additional funds for the next round of asset purchases.

[0049] Once sold to a user, a general asset token becomes active and receives a pro rata share of rewards (mainly, but not exclusively, principal and interest). The framework collects general asset tokens as payment for establishing a portfolio of specific asset tokens and stores the collected general asset tokens in a repository. The general asset tokens may be used partially or completely. Once a holder of a general asset token creates a custom portfolio using the general asset token, the holder will own the newly created specific asset tokens and the underlying contract would not allow the holder to return the specific asset tokens to the original general asset tokens that were previously owned. The general asset tokens in the repository may be auctioned at a later date to raise additional funds for additional asset purchases. Once auctioned at a later date, the general asset tokens are reactivated from the repository.

[0050] In effect, the AD / PC Protocol allows eligible users (such as investors) to engage in a wide variety of assets, significantly improving the quality of purchasing power through the pooling of funds. In doing so, the AD / PC Protocol reduces manpower requirements, provides investors with more control and choice, and allows multiple tasks to be performed simultaneously more efficiently.

[0051] While investors in the analog world can also pool resources for purchasing power, the AD / PC Protocol democratizes access to investable assets, especially to obscure classes of assets that are not publicly available or easy to find and often require privileged access. Additionally, traditional investment funds do not offer pooled investors the ability to customize asset mixes due to control, investor relations activity considerations, and cost / operational complexity. The AD / PC Protocol uses blockchain technology, including a distributed ledger across multiple machines, to allow each investor to create a customized investment portfolio from available assets, as opposed to the one-size-fits-all approach of traditional asset managers.

[0052] Additionally, general asset token information management is more dynamic, efficient and rich. Each general asset token's "smart contract" contains information regarding authorizations to spend tokens, including pro rata allocations, pools of assets to choose from if they can be used to establish custom portfolios, transfers of general asset tokens back to the repository instead of minting specific asset tokens, and freeze / reactivation switches controlled by the framework.

[0053] In particular, the rights and obligations of the general asset token include rights to the platform rewards program. The value of the general asset token is based on the value of the user network, including unclaimed assets. The network receives revenue from activity and unclaimed assets. General asset token holders can also receive rewards for performing activities and becoming members of the user network, subject to the rules of the platform network.

[0054] The AD / PC protocol performs several functions, is persistent, and is guided by the state of the general asset token. Functions include a permissioned blockchain interaction and validation protocol, creation of smart contracts containing the rights and obligations of the original general asset token, issuance and sale of the general asset token, and a fiat to general asset token funding mechanism. The AD / PC protocol can determine when a fundraising amount is met, can determine when an asset purchase is met, and can set a timetable for casting events. The AD / PC protocol includes a rewards protocol (e.g., principal and interest) for payments managed by blockchain smart contracts, registration and storage of general asset token interests on a permissioned blockchain, blockchain-enabled dynamic recording of the state of the general asset token, blockchain-enabled management of the addition and removal of general asset tokens from repositories on a permissioned blockchain, and a protocol for interacting with the cascading token protocol. The AD / PC Protocol may further manage user (i.e., investor) KYC / AML, identity, and external accounts, sell new general asset tokens or auction existing general asset tokens in future rounds, raise funds in fiat currency, use general asset tokens to create specific asset tokens on a conditional basis, and actively record the interests of general asset token holders.

[0055] Returning to the method of Figure 4, at step 430, a specific asset token may be created. A general asset token may be used to create a specific asset token that represents a portion of an entire specific asset. Creation of a specific asset token from a general asset token includes receiving subscription requests from one or more users who own the general asset token during a cast event, receiving a premium from the user receiving the specific asset token, generating an allocation, and "freezing" the general asset token by removing the general asset token from the general asset pool and placing the general asset token in a repository.

[0056] Holders of general asset tokens are periodically provided with options by the system to establish or adjust their exposure in a custom portfolio during a timetable called a cast event. At each casting event, holders of general asset tokens can choose to use their general asset tokens to establish a portfolio of specific asset tokens by submitting a subscription request that defines an ownership stake of available assets in the general pool that have not yet been claimed by others. The specific asset tokens represent a percentage of the ownership stake of each specific asset that they wish to participate in (similar to a bond CUSIP). A subscription request can cover all or a portion of a user's general asset token ownership interest. With each casting event, the assets available in the general pool will vary over time as they are updated to consist of newly added assets and general pool assets remaining after the previous casting event.

[0057] As subscription requests reallocate stakes across the investor pool, participants wanting to increase their stake in a particular asset can potentially offer a premium to other general asset token holders by contributing a portion of their general asset token value to the general pool value. Allocation is then made based on a democratic bidding and allocation scheme and applied to bids received within the announced participation window opening and closing dates / times. The bidding and allocation scheme provides allocation rules based on a Dutch auction process that prioritizes allocation by highest bid and settlement by lowest liquidation price. The bidding and allocation scheme can change over time according to the system's governance rules.

[0058] The value of the newly created specific asset token (as defined in the subscription request) plus the bid premium can be equal to the initial stake of the holder of the general asset token. For example, the underlying asset X can be valued at $200. At issuance, 10 users of the system can have a stake of $20 per asset X through the general pool on which the general asset token is based. If a 25% stake limit applies, 4 users may bid to create $50 per specific asset token of asset X. Asset X is then fully subscribed and no more specific asset tokens X can be created for asset X. In the future, another user looking to purchase specific asset tokens X can do so by using fiat currency or by negotiating an exchange of specific asset tokens X for other system specific asset tokens, but only if one current holder of specific asset tokens X wants to sell their stake in specific asset tokens X.

[0059] In order for the four users to increase their concentration in Asset X, they must reduce their stakes in other assets from their pro-rata exposure at the time of the issuance of the general asset token. The four users can only induce other users in the pool to reduce their exposure to Asset X (or exit altogether in this example) and accept a higher concentration in the exposure of the other remaining assets by offering a bid premium. Although the bid premium increases, it does not guarantee that the user's (i.e., investor's) subscription request will be accepted. Allocation is done based on a bidding and allocation schema.

[0060] As described above, the system platform allows for full or partial securitization of Asset X. Even if only one user subscribes to Asset X, they can create one Asset Token X worth $50 (or less) for Asset X and leave $150 (or 75%) of Asset X unclaimed. The value remains in the general asset pool and the equity contributions are reallocated to the remaining general asset tokens. The unclaimed 75% of Asset X will be available for users (i.e., investors) to claim in future cast events until it is fully subscribed. In other words, unlike traditional securitization, a user does not need to subscribe to the entire value of Asset X to start creating a particular Asset Token X.

[0061] A holder of a single general asset token can only create and own specific asset tokens up to the limits defined by the governance rules of the system and applied to the bidding and allocation scheme. Users (i.e., investors) collectively cannot create asset tokens that are more specific than the value of the underlying asset. If the total requests received from holders of various general asset tokens to create specific asset tokens exceed the value of the underlying asset, the specific asset token will be "oversubscribed." When this occurs, creations of specific asset tokens will be allocated according to the bidding and allocation scheme until the full stake in the underlying asset has been allocated. Contributions of any unfulfilled subscriptions in that asset will be left in an amount equal to the unused general asset tokens.

[0062] Once a holder of a general asset token creates a customized portfolio using the general asset token, the holder owns the newly created specific asset token and cannot convert the specific asset token back to the original general asset token previously owned. The system freezes the amount of general asset tokens used as payment to create the specific asset token (and associated premium bid) and stores the retired general asset token in a repository. The system repository stores the general asset tokens whenever a user (i.e., an investor) relinquishes all or an increment of the general asset token to perform a task in the system. The repository acts as a wallet to store the frozen general asset tokens. The general asset tokens that enter the wallet are marked as frozen. The general asset tokens in the repository can then be reactivated to execute additional offers to raise additional funds for another round of asset purchases.

[0063] The platform will track the total general asset tokens held (active), the total general asset tokens used to create specific asset tokens (frozen), and the value of active general asset tokens and active specific asset tokens. Active general asset tokens and active specific asset tokens have a fundamental value based on the remaining value of the underlying asset and a market value established by trading activity that may be at a premium or discount to the fundamental value. The fundamental value of an actively held general asset token is backed by the value of unclaimed assets in the general pool, net of amortization at a particular time. The fundamental value of an active specific asset token is backed by the value of claimed assets removed from the general asset pool and created according to the bidding and allocation scheme established for the casting event, net of amortization at a particular time. For a specific asset, the total fundamental value is equal to the total value of the active specific asset tokens for that specific asset plus the equivalent value of the specific assets remaining in the general pool unclaimed, represented by the general asset token. The platform tracks this combined value so that each asset is not over- or under-represented when active asset-specific tokens and the equivalent amount of active general asset tokens for a single asset are counted.

[0064] For example, but not exclusively, in a commercial use case for a U.S. infrastructure project, such as the initial market focus of the system, the underlying value of the general asset token and the specific asset token will change over time due to the amortization of the underlying asset. In this example, the general asset token and the specific asset token are tied to a financial loan for the infrastructure project, whether in a general pool or specific asset, at or prior to the maturity of the loan, the loan may be refinanced or come to terms. When the underlying asset loan is repaid in full, the specific asset token will be burned. Similarly, any remaining attribution to the asset will be reduced to zero in the general asset token.

[0065] The creation of asset-specific tokens is discussed in detail with respect to the method of FIG.

[0066] At step 435, token transfers between users may be processed by the application. Transfers of asset-specific tokens may include member-initiated token sales, member-initiated token purchases, or member-initiated token trades. Details of processing token transfers are discussed with respect to the method of FIG.

[0067] In step 440, user payments are generated. In some cases, when the platform administrator acquires the loan assets, holders of general asset tokens and specific asset tokens receive cash flows from the assets, referred to as rewards. The holders of specific asset tokens receive cash flows (loan principal and interest payments, minus network fees) from the specific underlying assets represented by the specific asset tokens they hold. Similarly, holders of general asset tokens receive cash flows (e.g., loan principal and interest payments, minus fees that may be charged to users) from their pro rata shares of the assets in the general pool of unclaimed assets. Additionally, following a casting event, holders of general asset tokens and holders of specific asset tokens may receive rewards in the form of additional equity contributions reflecting the premiums for bids paid by successful subscription requests. Payments may be distributed periodically by the system, such as monthly, quarterly, annually, on an ad hoc basis, or other time periods.

[0068] In some cases, to provide financial services and send and receive payments to users and counterparties for providing such services, the system will be established with a system and relevant regulations to conduct KYC / AML (Know Your Customer / Anti Money Laundering) reviews on all potential participants to ensure that users meet the eligibility requirements. The system platform will utilize third parties with blockchain applications (and possibly other types of applications) that allow the platform to access and update information regarding the identities of participants.

[0069] By meeting KYC / AML requirements and satisfying the highest regulatory standards, the system will be able to interact with banks and other financial institutions for its remittance needs, including, among other things, receiving payments in fiat currency (such as USD) from platform participants and loan borrowers, and making payments to designated bank accounts of loan sellers and platform participants (e.g., principal and interest to users, and exchange fees from users to clear transactions).

[0070] The asset information and application records are stored by the application on the distributed ledger at step 445. The system may use a distributed ledger architecture to store records of asset purchases and dispositions, token transactions, and payments.

[0071] Users can interact with assets through a two-layer blockchain framework outlined by two-layer Digital Asset 1 (DA1) and Digital Asset 2 (DA2) protocols. The system utilizes a two-layer blockchain framework for users to interact with investable assets in new ways. DA is the task and data interaction between digital assets and users (i.e., investors). DA1 includes a first set of protocols that allow interaction with homogenous types of assets ("assets"). DA2 builds on this and includes a second set of protocols that allow interaction with a subset of specific assets ("portfolios") derived from the entire specific asset.

[0072] By resequencing interacting nodes and defining dynamic, rich data processing protocols, the Digital Asset Protocol streamlines processes and resource requirements, bringing long-needed efficiency to the notoriously asset-rich, resource-poor investment fund model.

[0073] DA1 and DA2 greatly improve users' visibility to identify desired investments and their ability to acquire and manage those investments. A real-time map of assets against counterparties and other assets on a permissioned blockchain helps many stakeholders more effectively perform their functions as asset generators, users (i.e., investors), portfolio managers, regulators, tax authorities, and accountants. Investors of all types can have democratized access to these investable assets that were historically out of reach due to minimum investment requirements, privileged access, and recognition. Now, all permissioned stakeholders (users, administrators, etc.) will have improved transparency with mapping tools and ecosystem-wide participation regarding assets at all times, providing a positive change in the balance of power.

[0074] Among many improvements and innovations, blockchain-enabled digital assets facilitate discoverability, improve transaction quality, reduce counterparty risk, provide transparency, enable customization, facilitate exchange, embed compliance, enrich asset data and history, streamline validation, facilitate customization, unlock liquidity information, facilitate accurate and dynamic record-keeping, and facilitate AI-driven investment. DA1 and DA2 for assets each consist of several functional elements that manage the logic required for compliance protocols. Some of these functional elements may include public and permissioned blockchain interaction and validation protocols, blockchain-enabled permissioning and user (e.g., investor) eligibility rules for various types of assets, dynamic description of various types of assets on the permissioned blockchain, compliance of assets to the permissioned blockchain, a real-time map of assets against counterparties and other assets on the permissioned blockchain, a self-discovery protocol for discovering assets with a specific set of parameters, an assisted discovery protocol (in some cases driven by artificial intelligence) for identifying assets, validation of token transactions on the permissioned blockchain, digital registration and storage of tokens on the public blockchain, dynamic record-keeping of the transaction history of assets on the public blockchain, a distributed ledger architecture that records purchases and dispositions of assets by the platform system manager, token supply, transactions by the system of general asset token and asset-specific token holders, and payment of principal and interest to token holders.

[0075] In some cases, the control, storage, and protection of cash and tokenized assets on permissioned and public blockchains is governed by the logic, rules, and functions of a custody protocol.

[0076] The custody protocol uses blockchain technology to protect cash and tokenized assets over their lifecycle from the creation of the asset to the end of its lifecycle. The functionality of protecting cash and tokenized assets over the asset and transaction lifecycle encapsulates the creation, registration, and ownership rights of digital assets to perform activities described in one of the other platform protocols. The custody protocol includes rules for the handling and transfer of assets between all operators, including the asset generator, digital assets, users (e.g., investors), networks of other users, and regulators to ensure compliance with relevant rules (e.g., custody rules) in the domicile of operation.

[0077] The Protocol covers mechanisms for holding, authorizing, verifying, registering, recording ownership interests and transactions, and managing the handling of client cash and tokenized securities, including transfers related to newly created tokens, deposits, purchases, sales and settlements of existing cash and tokens, including the verification and authorization of holders of cash and tokenized securities, and the verification and authorization of participants initiating and settling transactions between holders of such assets.

[0078] The custody protocol includes the corresponding rules of all technical modules for the exchange, as well as additional custody-specific elements. The rules and elements include public and permissioned blockchain interaction and validation protocols, user KYC / AML, identity, external account management, coordination with distributed ledger architecture to record events, history of asset purchases and dispositions by the system manager, token supply, transactions by holders of general and specific asset tokens, payment of principal and interest to holders of tokens, coordination with rules governing the exchange, residency and updates in the permissioned blockchain, and receipt of pricing and aging data from the permissioned blockchain for publication on the public blockchain. The rules can relate to transaction validation, transaction reversal, counterparty obligations, and management and use of private and public keys. The keys are used in cryptographic methods to protect access to user addresses of transactions on the blockchain. The rules and elements may include delivery and settlement mechanisms, digital storage on the side blockchain and physical storage, digital registration on the public blockchain of completed transactions, registration of tokenized assets, registration of interests in tokenized assets, authorization and validation of writes to the side blockchain, balance sheet validation, and initiating various transactions on behalf of asset owners, authorization and validation of transactions, transfer of all assets, initiating various transactions on behalf of asset holders, and determining the transaction and settlement parameters required for initiating, validating, and settling transactions.

[0079] Returning to the method of FIG. 4, in step 450, the values ​​of the active general asset tokens and the active specific asset tokens are updated. The fundamental value of the actively held general asset tokens is backed by the value of the unclaimed assets in the general pool, minus amortization and network fees, at a particular point in time. This value changes over time and is updated periodically by the system. The fundamental value of the specific asset tokens is backed by the value of the claimed assets that were created according to the bidding and allocation scheme established for the cast event and removed from the general asset pool, minus amortization and network fees, at a particular point in time. This value changes over time and is updated periodically by the system. The total fundamental value of the assets on the platform is the value of all active specific asset tokens plus the equivalent value of the unclaimed general pool assets.

[0080] In step 455, the frozen general asset tokens are reactivated and added to the general asset pool. In some cases, a second round of general asset token generation is performed and general asset tokens are added to the general asset pool. In some cases, if general asset tokens from a previous offering are still in the general asset pool, these general asset tokens can be used to create specific asset tokens or assigned new values ​​based on the value of the new general asset. This is discussed in more detail with respect to the method of FIG. 8.

[0081] At step 460, a compliance validation is performed. In some cases, the compliance validation is performed at least in part according to a compliance protocol. The compliance protocol establishes all the logic to actively ensure compliance with regulatory matters and internal controls by recording events and event data on the network, extracting data for governance, and applying governance and execution schemas (such as bidding and allocation schemas). The compliance protocol actively adjusts the logic to match general operating specifications set by accounting boards, securities regulations, technical standards, and other requirements. After executing the compliance protocol, the process loops back to step 420, whereby new assets can be deposited to increase the cumulative general asset pool over time. Thus, updating the general asset pool at step 425 may include adding subsequent cycles of new assets to the pool, taking in proceeds received from the sale of reactivated frozen general asset tokens from the repository, and subtracting previous general asset pool assets that were mapped to specific asset tokens created in previous cycles. This may be done periodically or in response to one or more events, such as reactivation of a general asset or conversion of a general asset token to a specific asset token.

[0082] In this capacity of governance, compliance, and internal control, the Compliance Protocol will require permissioning and validation regimes to include a range of relevant participants such as auditors, regulators, committee members, and administrators. The Compliance Protocol will act as an exchange mechanism between on-chain and off-chain data, curating external and internal data requests between parties.

[0083] The compliance protocols help establish a compliance platform with the operational authority of the system and may manage, implement, and / or access public and permissioned blockchain interaction and validation protocols, legal module, auditor module, KYC / AML module, fraud monitoring module, bidding and allocation schema module, default and restructuring module, corporate finance module, custody and trading module, trustee module, and special purpose vehicle SPV module.

[0084] Figure 5 illustrates a method for creating a specific asset token. The method of Figure 5 details step 430 of the method of Figure 4. First, a casting event is triggered by an application in step 510. The casting event indicates the start of a subscription process for a holder of a general asset token who is attempting to create a specific asset token using the general asset token.

[0085] Next, in step 515, the application may receive one or more subscription requests from users who hold general asset tokens. The subscription requests define an equity contribution of an asset available in the general pool that has not been claimed by other general asset token holders. The subscription requests may be made from all or a portion of the general asset token equity contribution. A general asset token holder may use the general asset token to initiate a protocol to create specific asset tokens. A general asset token holder may adjust exposure in a custom portfolio during a cast event by sending a subscription request to the specific asset token that adjusts its exposure. In some cases, the specific asset tokens represent an equity share of each specific asset in which the user wishes to participate.

[0086] A premium may be received from the user associated with the subscription request at step 520. In some cases, participants may provide premiums to other general asset token holders by contributing a portion of the value of their general asset token to the value of the other user's general asset token.

[0087] The asset-specific token allocation may be generated by the application in response to the subscription request in step 525. The asset-specific token allocation may be implemented using financially well-accepted and well-tested procedures. Details for allocating the asset-specific tokens are discussed with respect to the method of FIG.

[0088] At step 530, the general asset token may be removed from the active state of tokens and moved to the repository in response to the generated allocation of specific asset tokens. Changing the state or "freezing" of the general asset token includes reducing the value to zero, removing the general asset token from the active population, and moving the frozen general asset token to the repository. By moving the general asset token from the general asset pool to the repository, the general asset token is "frozen" after being used to create specific asset tokens. At step 535, the premium is distributed from the holder of the newly created specific asset token to other users in the general pool in the settlement of the newly created specific asset token. This step completes the settlement method for creating specific asset tokens.

[0089] In some cases, the Securitization in Place (SIP) protocol is used to create and manage specific asset tokens. The SIP protocol creates specific asset tokens on demand and sweeps or clears the ecosystem of asset tokens that reach a terminal value or otherwise meet a deletion condition. The SIP protocol covers the task and data interaction between the asset generator and the digital asset. The SIP protocol is activated when it receives instructions from the Cascade Token Protocol (see below) to create specific asset tokens until the asset's value is fully assigned to the specific asset token created by the user and until the asset reaches the end of its lifecycle.

[0090] Once subscription requests have been allocated and priced (in accordance with governance, equity restrictions, and bidding and allocation schema), the SIP protocol initiates the creation of asset-specific tokens that represent partial interests in a particular asset. Specific asset tokens can only be created under certain circumstances and in increments established by the SIP protocol rules for that asset. Fractional interests so created assign value to particular users with pro rata rights and obligations in a ratio that reflects their equity investment in the underlying asset.

[0091] Holders of general asset tokens initiate subscription requests during a cast event via the Cascading Token Protocol (see below) to determine the amount of specific asset tokens that need to be minted. The SIP Protocol incrementally securitizes the value of homogeneous assets until the required percentage of assets from the AD / PC's general pool onboarding registry is allocated to specific users (e.g. investors). When securitizing homogeneous assets, the SIP Protocol deposits the incremental value into the securitization vehicle and alerts the AD / PC to remove the corresponding amount from the general asset tokens.

[0092] Subscription requests are collected from all general asset token holders during a cast event and hold the value of the specific asset set by the AD / PC and aged to that point. Each specific asset token utilizes a "smart contract" that incorporates investment rights and obligations, including subscription rights that define the percentage of economic interest and liability interests, transfer and exchange rights, the value of the asset over the asset's lifespan, and a sunset mechanism in case the specific asset is exhausted. Specific asset tokens backed by assets can reach a terminal value / scrap value or zero value and are burned after exhausting their economic lifespan.

[0093] The creation of digital securitization tokens significantly compresses the process, structure, and resources as opposed to traditional securitization of assets. In traditional securitization, a special purpose vehicle ("SPV") is created. Assets meeting certain characteristics are acquired and transferred to the SPV. The assets are pooled to a target size. New securities are created, backed by the pool of assets and managed by a trustee. All securities are created simultaneously. This process can take three months or more. With starting costs of $2 million or more, this can consume the economics of a transaction and inhibit the creation of new investment products.

[0094] The SIP Protocol compresses the issuance process using blockchain-enabled smart contracts to allow the creation of digital securitized asset tokens for any asset type. Securitized asset tokens are created on the platform where the asset is implemented, thus constituting a "securitization in place." Without asset transfers and a web of SPVs, depending on the complexity of the underlying asset and the governing securities regulations, the SIP Protocol is ready to create compliant digital security tokens for any asset in 1-4 weeks. After an asset is implemented and prepared, asset-specific tokens can be created "on demand."

[0095] This rolling basis securitization is not currently feasible with previous systems. Due to administrative complexity, a full securitization is done for the entire pool and pricing for the entire pool is set at once, which may be at a premium or discount. With rolling basis securitization, all securities so created can be easily carved out and time-stamped upon creation. Fractional ownership shares are priced at the current asset value, avoiding discounted pricing due to over-issuance, since issuance is triggered by users seeking asset specific tokens. The task of creating incremental asset specific tokens is streamlined with electronic instructions and inventory is calculated and tracked by the distributed ledger.

[0096] In addition to rolling-based securitization, another SIP protocol innovation is the sweep mechanism, which "burns" asset-specific tokens that reach an end-of-life condition. The sweep mechanism is an innovation not offered in traditional securitization procedures. Securitization of assets using SPVs involves the use of trustees and is a document- and resource-intensive process. This protocol creates a self-cleaning securitization process. Thus, partial shares of a specific asset are created on a rolling basis, but all asset-specific tokens of the same asset are simultaneously retired.

[0097] The SIP protocol performs several key functions for each new asset implemented in the ecosystem and is completed when the asset is fully allocated or retired. These functions include the public blockchain and permissioned blockchain interaction and validation protocols, the blockchain-enabled description of the original asset that the asset generator implements on the platform (including value and cost / payment waterfall and shadow rating, done on the permissioned blockchain) and reflecting the value of the asset as it ages (done on the permissioned blockchain and periodically published on the public blockchain), the dynamic valuation protocol that establishes the increment of the asset's portion in coordination with the participation window set by the AD / PC, receives instructions from the cascading token protocol to create partial shares of the specific asset with unique identifiers from the original asset on the permissioned blockchain, and the creation of identification badges including allocation to registered users (e.g. investors) of the permissioned blockchain and the rights and obligations underlying each partial share of the digital specific asset. the creation of a smart contract to include a set of assets that have been allocated to the permissioned blockchain and a set of assets that have been allocated to the permissioned blockchain; digital registration and storage of the specific asset tokens on the public blockchain when triggered by selection of the general asset token in the cascade token protocol; periodic validation and recording of the value of the specific asset tokens on the public blockchain; a reward protocol for payouts (e.g., principal and interest) on the permissioned blockchain for the general asset tokens and the specific asset tokens managed by the smart contract; recording of performance states on the public blockchain; a settlement protocol for sweeping and managing an active inventory of asset tokens on the permissioned blockchain and public blockchain reflecting assets that have reached a terminal value or zero value ("burned"); periodic validation and "burning" of the specific asset tokens upon settlement on the public blockchain; and an active record of the ownership interests of holders of the specific asset tokens.

[0098] The Cascade Token Protocol (CT Protocol) contains the rules by which users (e.g., investors) and asset generators interact with each other on both a periodic and rolling basis. The CT Protocol runs and / or operates together with the AD / PC Protocol, which is another set of rules between users and asset generators, and is activated by a switch mechanism from the AD / PC. The CT Protocol controls the state of the general asset token and returns the results to the AD / PC, which calculates the corresponding creation of specific asset tokens.

[0099] Users (e.g., investors) and asset generators interact with each other using a combination of general asset tokens and specific asset tokens. General asset tokens are sold to users to raise funds to purchase assets for implementation on the blockchain. General asset tokens are evergreen or perpetual in that they can be removed from the asset pool, placed in a repository, and reintroduced into the asset pool for subsequent offerings. For each homogenous asset type, the SIP protocol creates a conforming digital investment product or specific asset token on the blockchain that represents a partial share of the homogenous asset type. The specific asset tokens can reach a terminal value or zero value and are burned after they have exhausted their economic life. The CT protocol performs a calculation to convert the premium paid by investors to create specific asset tokens into additional equity investments in the remaining unclaimed assets.

[0100] First, the entire value of the specific asset tokens belongs to the general pool of the ecosystem and is not assigned to any specific user. The value assets and any economic benefits implemented in DA1, while not assigned to any specific user, belong to the ecosystem. It supports a reward system for users who purchase general asset tokens that fund the underlying assets.

[0101] At regular intervals, called Cast Events, users holding general asset tokens can use those tokens to create custom DA2 portfolios from combinations of partial shares of the DA1 asset. In this way, general asset tokens can be used to create "cascading" portfolios of many specific asset tokens equal to the value of the general asset token.

[0102] The CT Protocol is a key protocol for defining how asset generators and investors interact. This innovation allows investors to create custom portfolios for the first time on a pooled platform. This protocol is important because it provides unique flexibility for investors to invest in entire trades or self-directed combinations of investments, while allowing platform administrators to keep searching for assets to reload the pipeline.

[0103] The CT protocol democratizes the bidding and pricing mechanism for asset-specific tokens. Since subscription requests reallocate ownership across the investor pool, participants who want to increase their stake in an asset-specific token must offer a premium to other holders by contributing a portion of the value of the general asset token to the value of the general pool. Allocation is then made based on a democratic bidding and allocation scheme and is applied to bids received within the announced participation window opening date and time. The bidding and allocation scheme provides the rules of allocation, for example based on the Dutch auction process. Users bid the amount and price they want to buy. Once bids are made, allocation is made from highest bid to lowest bid. The price paid is the minimum bid price to receive allocation. The bidding and allocation scheme can change over time according to the governance rules of the platform.

[0104] The CT Protocol includes several technical modules and functions, including public and permissioned blockchain interaction and validation protocols, a mechanism for hosting permissioned blockchain participation windows and recording public blockchain results, creation of smart contracts containing the rights and obligations underlying the cascading token mechanism (including the use of general asset tokens to participate in a pro rata share of specific asset tokens), a protocol for updating the activation state of general asset tokens before and after their consumption in participation events, blockchain-enabled dynamic recording of the inventory of general asset tokens via the AD / PC protocol, a protocol for updating the allocation of "shares" of specific asset tokens on identification badges, removal from the general pool inventory, and establishment of a compliance program (initial sale and subsequent auctions) to inform existing general asset and specific asset token holders on the platform of the availability of new implemented / unclaimed assets or general asset tokens available for purchase, which may include the underlying asset specific details in the case of specific asset tokens, or general asset token specific details.

[0105] FIG. 6 illustrates a method for generating asset-specific token allocations. The method of FIG. 6 illustrates details of step 525 of the method of FIG. 5. In step 605, bids for specific asset tokens received by the application from users who own general asset tokens are analyzed. Then, in step 610, a determination is made as to whether the total of the claims for the specific asset tokens is greater than the value of the underlying asset. If the total of the claims is not greater than the value of the underlying asset, then in step 620, a determination is made as to whether shares of all the specific asset tokens have been claimed. If shares of all the specific asset tokens have not been claimed, the application redistributes unclaimed shares of the SAT to other users in the general pool.

[0106] Returning to step 610, if the total demand for asset-specific tokens is greater than the value of the underlying asset, then in step 615, asset-specific tokens are created and allocated per a bidding and allocation scheme.

[0107] Whether all the specific tokens are oversubscribed, fully claimed, or partially claimed, the method of FIG. 6 is completed at step 630 by adjusting the share price of the specific asset token. At step 635, the allocation of the specific asset token is completed. In some cases, the assets can be allocated using a Dutch auction, similar to that used in the Treasury bill auction. An example of a Dutch auction is as follows: A specific asset may have 100 units available. First, five users or owners each allocate 20 specific asset tokens, which is equivalent to 20 units of the general token. All five owners want to create 25 units of each specific token. In other words, the specific asset is oversubscribed by 25 units. Owner 1 makes a premium bid of 1.2 general tokens to create each of 25 specific units, Owner 2 makes a premium bid of 1.15 for each of 25 units, Owner 3 makes a premium bid of 1.15 for each of 25 units, Owner 4 makes a premium bid of 1.1 for each of 25 units, and Owner 5 makes a premium bid of 1.1 for each of 25 units. Bids are ranked from highest premium bid to lowest, and quantities are allocated from highest premium bid until all 100 units are allocated to the asset. In this case, Owner 1 gets the right to create 25 specific token units, Owners 2 and 3 each get the right to create 25 units because they have equal second-highest bids, and Owners 4 and 5 get the right to create 25 units each because they have equal third-highest bids, but there are not enough units left to fill a full 50 units. Instead, they get the right to create the remaining half, or 12.5 units. In this Dutch auction example, the liquidation price will be 1.1 general tokens, which is the minimum bid allocated. Thus, a premium of 10 general tokens will be paid by the winning bidder to bidders who finish with less than 20 specific tokens.Owners 4 and 5 each receive a premium of 5 general tokens to compensate for their reduction in their holdings of specific tokens of 12.5 (vs. the original 20).

[0108] FIG. 7 illustrates a method for processing a token transfer between a first user and a second user. The method of FIG. 7 illustrates details of step 435 of the method of FIG. 4. At step 710, a determination is made as to whether a request to transfer an interest in a particular asset token via a sale is received. If a request to sell an interest in a particular asset token is received at step 710, a token sale notification is generated by the application at step 715. At step 720, the token sale notification may be sent to the user and the distributed ledger. At step 725, a determination is made as to whether a request to transfer an interest in a particular asset token via a purchase is received. If a request to transfer tokens via a purchase is received, a token purchase notification is generated at step 730, and a token purchase notification is sent by the application at step 735. The purchase notification may be sent to the relevant user and the distributed ledger system, and may be reported to other systems or machines, in some cases.

[0109] At step 740, a request may be received to transfer an interest in a specific asset token via a transaction between multiple users. At step 745, a token transaction notification may be generated by the application. At step 750, the notification may be sent by the application. The notification may be sent to the users involved in the transaction, to other users having general asset tokens and / or specific asset tokens, and to the distributed ledger system, and may possibly be reported to other systems or machines.

[0110] In some cases, users holding general asset tokens and holders of specific asset tokens may exchange tokens within the system's platform for an exchange fee paid in fiat currency to a platform administrator, which may be a percentage of the amount of the exchange transaction.

[0111] These exchanges allow for the full or partial exchange of tokens associated with each user. The mechanism for calculating and transferring equivalent values ​​between holders of various tokens will be based on the underlying assets supporting the general or specific asset tokens' values. Also, current or new users can "bid" for another token holder's tokens by transferring value using other specific or general asset tokens or fiat currency. Conversely, investors holding general or specific asset tokens can "offer" to sell their tokens to current or new users. The current platform provides a marketplace for the announcement and curation of transactions across a network of current token holders and other eligible new investors for the above "bids and offers."

[0112] The current platform facilitates the listing of asset specific tokens (but not general asset tokens) on external exchanges. The system may utilize existing licensed exchanges. In some cases, the system may provide general and asset specific token exchange capabilities over time. The goal is to provide users of the platform with maximum flexibility to swap between a wide combination of tokens and provide AI-driven recommendations and portfolio construction tools specific to the system tokens.

[0113] The system will assist users of general asset tokens to aid in their selection of which underlying specific asset tokens to select for creation using machine learning / AI. This will involve an AI-driven guided decision process. Based on the specific investment profile, objectives, and criteria of the user (e.g., investor), the AI ​​will find the best match between that particular user (e.g., investor) and the asset that best suits their needs. Conversely, the AI ​​will identify current assets that violate the investment objectives of a particular investor or specific conditions they specify, and will recommend removing the asset. In effect, the current platform will generate liquidity in the underlying assets through data, rather than just using capital.

[0114] In some cases, the system may implement an exchange protocol having rules for users to interact with one another over their networks, both on a periodic and rolling basis.

[0115] The goal is to provide platform users with maximum flexibility to swap between a wide variety of token combinations and provide recommendation and portfolio construction tools. While the system will have an external list of asset specific tokens (not general asset tokens) on alternative exchanges, the rules of exchanges and users' eligibility to participate / own tokens will be set by the system exchange rules.

[0116] The module collects associated transaction fees to facilitate the exchange. The ability to exchange digital assets will greatly increase liquidity for all types of investable assets, providing liquidity for the first time for certain asset types such as project finance assets.

[0117] The exchange protocol includes several technical modules and functions, including public and permissioned blockchain interaction and validation protocols, management of investor KYC / AML, identity, and external accounts that orchestrate the distributed ledger architecture to record events and history of asset purchases and dispositions by the platform manager, token supply, transactions by holders of the platform's general and asset specific tokens, principal and interest payments to token holders, residing and updated on the permissioned blockchain and receiving pricing and aging data from the permissioned blockchain for publication on the public blockchain, orchestration with rules governing the exchange, rules for validating transactions, transaction reversals, counterparty obligations, and distribution and settlement mechanisms.

[0118] In some cases, the system may offer subsequent offers for general asset tokens to users. The system uses a repository to freeze general asset tokens after their owners use them to create specific asset tokens. The frozen general asset tokens will be pooled and offered to new owners to facilitate additional rounds of asset purchases. Future offers will reset the new price of the general asset tokens.

[0119] There may be Round 1 general asset token holders who have not submitted subscription requests to mint specific assets (elected instead of owning a general pool contribution) at the time of the future offering of general asset tokens from the repository to raise new cash in Round 2. Prior to the Round 2 offering, Round 1 general asset token holders will be given two options: 1) they will be given the option to submit their general asset tokens and mint specific asset tokens reflecting their contributions in the remaining pool of unclaimed Round 1 assets prior to the Round 2 offering. Unlike the bidding process used for casting events, this will be a pro rata mix of assets from all general token holders; or 2) instead, if Round 1 general asset token holders choose not to mint Round 1 specific asset tokens prior to the Round 2 offering, they will be forced to “reset” their general asset tokens to the Round 1 to Round 2 valuation levels.

[0120] In a "reset", the new value level will be based on the price of the round 2 offer relative to the actual remaining round 1 value of the general asset token, which is the original cost of the round 1 general asset token less the amount of cash (excluding loan interest) paid to the holder of that general asset token before round 2 took place. The "reset" ratio is a very specific number calculated based on the remaining round 1 value and the price of the new round 2 offer, so the conversion of round 1 general asset tokens to round 2 general asset tokens will be exact.

[0121] The purpose of this “reset” is to allow holders of Round 1 and Round 2 general asset tokens to come to the same parity in terms of value for minting specific asset tokens, with the same rights and cash flows from the combined pool of unclaimed assets from Round 1 and unclaimed assets purchased after Round 2 of the general asset tokens being auctioned.

[0122] For example, assume 100 general asset tokens were created at the initial issuance at $10 / token. Of this supply, 98 general asset tokens were used to create asset-specific tokens and were therefore submitted to the system repository. Due to amortization, the value of each of the 2 unused Round 1 general asset tokens will be $7.50 at the end of 12 months.

[0123] At the end of the 12 months, the system announces an auction of 98 general asset tokens at $10 per token. Prior to the auction, one of the round 1 general asset token holders submits his tokens to create specific asset tokens for half of the remaining unclaimed asset pool from round 1. The other round 1 general asset token holder does not submit his general asset tokens and the round 2 offering is completed. The remaining value of the round 1 general asset tokens was $7.50. The round 2 auction is at $10 / token. The round 1 general asset token holder's holdings are adjusted to 0.75 general asset tokens, which are then forced to "reset" to parity in the round 2 general asset token auction. Thus, the total number of general asset tokens offered in round 2 is updated to 99 (98 plus the 1 general asset token submitted just before the auction). The total number of general asset tokens in round 2 is now 99.75 (99 plus 0.75 due to the forced reset of the round 1 general asset tokens).

[0124] Round 1 and Round 2 General Asset Tokens will parity and have the right to create Specific Assets from a pool of any combination of unclaimed Round 1 assets and assets purchased using the proceeds from the Round 2 General Asset Token offering.

[0125] In the example above, because the Round 2 offer was 1.0, the Round 1 offer of General Asset Tokens was adjusted to 0.75 General Asset Tokens. That 0.75 General Asset Tokens, when multiplied by the new total proforma outstanding General Asset Token value, reflects the adjusted purchasing power (% stake) of a 0.75 General Asset Token holder to participate in future casting events.

[0126] A=B / C.

[0127] Where: A is the value of the outstanding general asset tokens in the new total quote.

[0128] B is the sum of the new total estimated unclaimed assets, i.e. the sum of the remaining unclaimed round 1 asset pool and the new round 2 asset pool.

[0129] C is the total quotation number of outstanding general asset tokens.

[0130] The system will notify existing general asset and specific asset token holders on the platform when a casting event will take place. Through a transaction protocol, the system will allow members and the public to see which specific asset tokens are being offered for sale by current holders. Specific asset tokens can be purchased by eligible users with fiat currency or by exchanging other system assets.

[0131] FIG. 8 illustrates a method for reactivating a frozen generic asset token. The method of FIG. 8 illustrates details of step 455 of the method of FIG. 4. A notification regarding the use of the generic asset token to create a specific asset token is sent to a user associated with the generic asset token in step 810. The notification may present the user with an option to use the generic asset token to create a specific asset token. The generic asset token and the generic asset pool are discovered upon addition of reactivating the generic asset token from the repository in step 815.

[0132] The previous general asset token is then removed from the general asset pool in step 835. In step 820, the new general asset token is added to the general asset pool in respect of an available general asset token spot.

[0133] In step 825, the methodology maps all reactivated general asset tokens and general asset token values ​​remaining from the previous round into a new general asset pool that includes the addition of new general pool assets acquired in each new cycle and general pool assets that were not used to create specific assets in the previous pool cycle.

[0134] 9 illustrates a method for automatically providing asset recommendations to a user. At step 910, the application can receive user-specific investment profile, goals, and user criteria data. The investment profile data can include the types of investments and preferences the user has, such as domestic versus international assets, various industries or technologies, and other preferences. The goals can indicate whether the user wants to increase value, receive cash, or other objectives.

[0135] In step 915, the application maps the received data to the inputs of the model to automatically generate recommended asset information. In some cases, the model may be a neural network or other machine language model that uses artificial intelligence to determine the assets that best fit the user's investment profile, goals, and other criteria.

[0136] The application persistently builds a data warehouse and, through machine learning techniques, purchases additional information from the user knowledge base and the platform knowledge base to enhance user queries.

[0137] At step 925, the received input is converted into an enriched query and processed by the model to generate an output. Many users with limited analytical resources may submit simple queries, especially for unfamiliar asset types or permission queries. To address this limitation that constrains the quality of the user's analysis, the methodology of 925 uses data analytics and machine learning techniques to relate the received input to broader data sets and trends accumulated by the platform from on-chain and off-chain sources and models. This expands the dimension of the original search query into an "enhanced" query. At step 930, the output of the model is converted into asset recommendations for the particular user.

[0138] At step 935, current assets that do not meet the investor's goals are identified. In some cases, the system analyzes the user's current asset holdings to determine whether assets in the user's portfolio do not meet the user's investment profile, goals, or other criteria. At step 940, the application provides asset recommendations to the user based on the transformed output of the model and the identified current assets.

[0139] At step 945, user feedback is recorded in the user knowledge base and outcomes are deposited in the platform knowledge base. At step 950, the user knowledge base and platform knowledge base persistently search and suggest transactions to complement user queries. Complementing the methodology of 925, step 950 uses data analytics and machine learning techniques to relate the received input to broader data sets and trends accumulated by the platform from on-chain and off-chain sources and models to identify patterns, relationships, and actively inform users. The use of technology and information to drive activity is essential to solving large-scale asset financing, especially when illiquidity impedes traditional markets.

[0140] In some cases, portfolio management may be handled by a Portfolio Management (PM) Protocol implemented by the system. The PM Protocol is a set of protocols for users as investors to manage their self-directed investments, with the added intelligence of AI-driven recommendation tools. The PM Protocol allows users to utilize digital assets to submit investment objectives and exercise underlying rights and obligations.

[0141] When the administrator of the system acquires an asset, holders of general asset tokens and specific asset tokens receive cash flows from the asset and the value of the tokens decreases as follows: holders of specific asset tokens receive cash flows (loan principal and interest payments minus platform management fees) from the specific underlying asset represented by the specific asset token they hold. Similarly, holders of general asset tokens receive activity cash flows (loan principal and interest payments minus platform management fees) from the underlying asset of the general pool.

[0142] Users as investors pay fees for the operation of the platform, including technology and inventory creation and replenishment. Network fees are based in part on the outstanding amount of loaned assets (not tokens) at the start of a payment period (pro rata every fiscal quarter or first payment period). General and asset-specific token holders receive investment returns in fiat currency, net of fees.

[0143] The PM Protocol includes several technical modules and functions, some of which include public and permissioned blockchain interaction and validation protocols, a protocol for dynamically updating the value of any general asset tokens actively held in the permissioned blockchain, a protocol for dynamically updating the value of a pro rata share of unclaimed assets in the general pool in the permissioned blockchain, a protocol for dynamically updating the value of active asset tokens in the permissioned blockchain and the public blockchain, a protocol for registering users of the platform, a protocol for associating users with general asset tokens and asset specific tokens, a protocol for managing premium rewards in the permissioned blockchain, a protocol for managing network fees due in the permissioned blockchain, a payment protocol for transmitting rewards and value in the permissioned blockchain and the public blockchain, and a protocol for "settling" asset tokens at loan maturity (value), whether by refinancing or termination, in the permissioned blockchain and the public blockchain.

[0144] In some cases, portfolio monitoring may be performed by Analytical Protocol, a suite of portfolio tools including portfolio monitoring, risk assessment and scenario analysis that uses AI and machine learning concepts to utilize external data and data extractions and generate recommendations according to user-defined investment objectives.

[0145] The platform helps token investors select assets to exchange for underlying asset tokens to convert through an AI-driven guided decision process (described in a separate protocol). It is the first truly intelligent token that can dynamically assemble, cull, and regroup components.

[0146] The AI ​​component seeks the best match between a particular user (e.g., an investor) and assets based on the particular investment profile, goals, and criteria of the user. Conversely, the AI ​​identifies current assets that violate a particular user's investment goals or user-specified conditions and recommends removing the assets.

[0147] The AI ​​protocol is trained by proprietary data analysis of industry data as well as the system's data flows and transactions. The AI ​​protocol includes functions such as public and permissioned blockchain interaction and verification protocols, a scenario construction module, a stress testing module, a goal construction unit, recommendation tools, and a performance evaluation module.

[0148] Figure 10 shows a block diagram of a user case schematic of a two-layer tokenization platform. In the schematic of Figure 10, a user 1001 can buy and sell generic tokens at 1004 and trade digital assets at 1008. Rates for digital assets can be made through exchanges 1009. Users can also establish portfolios and convert generic tokens at 1005. Users can further exchange tokens at 1007 and buy and sell specific tokens at 1006 and record them in the blockchain 1010.

[0149] The user 1001 can manage the account at 1015, including depositing and withdrawing funds at 1016, and can make and receive payments at 1018. Wallet administration can be performed at 1017.

[0150] Users may be implemented at 1014 and verified as accredited investors at 1013. Administrators may perform research on users of the system at 1019 and create operations on general and other tokens, including freezing used general tokens in a repository and reusing frozen general tokens for auctions at 1028. Auctions of general tokens may be implemented at 1025.

[0151] An administrator of the system can also create and write specific tokens at 1020, manage portfolio fees at 1021, and publish at 1027. The administrator may perform bank management at 1026. Management of connections to payment intermediaries is essential to manage the transfer of value across applications and protocols. Here, "banks" may refer to traditional institutions as well as digital providers of payment intermediaries, including hot and cold storage providers of crypto assets. Over time, revenue and expense management occurs at 1024, and conversion of general tokens occurs at 1023. Auditors and accountants 1011 may interact with the system and regulators 1012.

[0152] FIG. 11 illustrates a block diagram of an activity flow chart of a two-layer tokenization platform. The activity flow chart 1100 of FIG. 11 and (for example) an infrastructure loan may be made by bank “A”. This may trigger a syndicated loan and may be acquired as part of an asset search by an administrator. The administrator may issue a general token. The contract for the general token may be stored in a blockchain distributed ledger system. A participation window may be created by the administrator. A user may select a general token and customize and use the general token to select a specific token. The user may then manage a portfolio in response to receiving the specific token. Once the user selects the specific token, the administrator may freeze the general token from which the specific token was generated. The frozen general token is managed in a token repository until it is activated for subsequent offering. In response to the creation of a participation window, specific tokens may be issued, allocated, and managed. The general asset token may be managed as an unclaimed asset. Payments may be received and allocated, including, for example, principal, interest, fees, other payments, etc. Bank "A" that made an infrastructure loan (example) can receive the settlement payment. After receiving and allocating the payment, the administrator activates the general token, the blockchain can burn the specific token, and the bank can receive the settlement payment.

[0153] In commercial terms, the two-layer tokenized digital asset platform provides technological innovations covering four major commercial areas, including the initial issuance and offering of general asset tokens, the creation of specific asset tokens, the subsequent offering of general asset tokens, payments related to general asset tokens and specific asset tokens, and trading of platform tokens between token holders.

[0154] The technology platform periodically offers general asset tokens to new or existing investors via the platform for a fee as a percentage of the offering price. General asset tokens are evergreen tokens. After they are issued to initial investors, the general asset tokens used to create specific asset tokens are frozen. Frozen general asset tokens can be reactivated for future rounds of offerings as a proxy for "secondary" vs. new issues. Repeated cycles of freezing and reactivation make the general asset tokens "evergreen."

[0155] In contrast to general asset tokens, specific asset tokens are created and burned or amortized over time as the underlying asset loan assets are repaid. General asset token holders initiate a series of protocols using general asset tokens to create specific asset tokens through subscription requests. Subscription requests are collected from general asset token holders who wish to participate in cast events to create customized exposure to specific assets.

[0156] All transactions and assets on the Platform are initially denominated in fiat currency. The Platform may select a base fiat currency for accounting purposes and may incorporate other currencies over time. In some cases, assets in other countries may be transacted in local currency and the system will determine the conversion to an effective base currency in accordance with prevailing business and tax laws.

[0157] The distributed ledger architecture maintains records of asset purchases and dispositions by the framework system, token transactions by general and asset-specific token holders, and payments between the platform and token holders.

[0158] In addition to the Platform's proprietary blockchain technology, which can utilize a combination of permissioned and public blockchains, the Platform is interoperable with decentralized technology applications, including accepting certain external tokens and interacting with external wallets and crypto exchanges.

[0159] FIG. 12 illustrates a block diagram of a computing environment for implementing a two-tier tokenization platform. The system 1200 of FIG. 12 may be implemented in the context of user machines 110, 120, and 130, a server 150, an administrator machine 170, a data store 180, and a distributed ledger machine 190, etc. The computing system 1200 of FIG. 12 includes one or more processors 1210 and a memory 1220. The main memory 1220 partially stores instructions and data for execution by the processor 1210. The main memory 1220 may store executable code during operation. The system 1200 of FIG. 12 further includes a mass storage device 1230, a portable storage media drive 1240, an output device 1250, a user input device 1260, a graphics display 1270, and peripherals 128.

[0160] The components shown in Figure 12 are depicted as being connected via a single bus 1290. However, the components may be connected via one or more data transfer means. For example, the processor unit 1210 and main memory 1220 may be connected via a local microprocessor bus, while the mass storage device 1230, peripheral devices 128, portable storage device 1240, and display system 1270 may be connected via one or more input / output (I / O) buses.

[0161] The mass storage device 1230, which may be implemented with a magnetic disk drive, optical disk drive, flash drive, or other device, is a non-volatile storage device for storing data and instructions for use by the processor unit 1210. The mass storage device 1230 may store system software for implementing embodiments of the present invention for purposes of loading that software into the main memory 1220.

[0162] Portable storage device 1240 operates in conjunction with a portable non-volatile storage medium, such as a floppy disk, compact disk or digital video disk, BS drive, memory card or stick, or other portable or removable memory, to input and output data and code to and from computer system 1200 of Figure 12. System software for implementing embodiments of the present invention may be stored on such portable media and input to computer system 1200 via portable storage device 1240.

[0163] Input devices 1260 provide part of the user interface. Input devices 1260 may include an alphanumeric keypad, such as a keyboard, pointing devices, such as a mouse, a trackball, a stylus, cursor direction keys, a microphone, a touch screen, an accelerometer, and other input devices for inputting alphanumeric and other information. In addition, system 1200 as shown in Figure 12 includes output devices 1250. Examples of suitable output devices include speakers, a printer, a network interface, and a monitor.

[0164] Display system 1270 may include a liquid crystal display (LCD) or other suitable display device. Display system 1270 receives textual and graphical information and processes the information for output to a display device. Display system 1270 may also receive input as a touch screen.

[0165] Peripherals 1280 may include any type of computer support device for adding additional functionality to a computer system. For example, peripherals 1280 may include modems or routers, printers, and other devices.

[0166] The system of 1200 may also include an antenna, a wireless transmitter, and a wireless receiver 1290 in some implementations. The antenna and radio may be implemented in devices such as smartphones, tablets, and other devices capable of wireless communication. The one or more antennas may operate at one or more radio frequencies suitable for transmitting and receiving data over commercial device networks such as cellular networks, Wi-Fi networks, Bluetooth devices, and other radio frequency networks. The device may include one or more wireless transmitters and receivers for processing signals transmitted and received using the antenna.

[0167] The components included in computer system 1200 of FIG. 12 are those typically found in computer systems that may be suitable for use with embodiments of the present invention and are intended to represent broad categories of such computer components that are well known in the art. Thus, computer system 1200 of FIG. 12 may be a personal computer, a handheld computing device, a smartphone, a mobile computing device, a workstation, a server, a minicomputer, a mainframe computer, or any other computing device. Computers may also include various bus configurations, network platforms, multi-processor platforms, and the like. Various operating systems may be used, such as Unix, Linux, Windows, Macintosh OS, Android, and Java, .NET, C, C++, Node.JS, and other suitable languages.

Claims

1. 1. A system for providing a tokenization platform, comprising: a server having a memory and a plurality of processors; one or more modules stored in memory and executed by the processors; the module is executable to generate one or more generic asset tokens for a generic asset pool by a token manager on an administration server, the token manager being stored in one of the administration server, a data store, a distributed ledger, and a memory, and generating the one or more generic asset tokens based on an asset protocol, the asset protocol being stored in one or more of a distributed ledger, the administration server, and the data store, the asset protocol defining asset attributes and including token state data; the asset protocol defines attributes of an asset that create a digital representation of the asset as the one or more generic asset tokens; The asset protocol automatically converts legal rights or obligations into elements that are incorporated into the one or more generic asset tokens; The token status data includes a status of a general asset token that is active or frozen; The system, wherein the one or more general asset tokens are associated with multiple users of a platform and are mapped to a general asset pool by an application, and the one or more general asset tokens created by the application are mapped to the general asset pool stored in one or more of the memory, the data store, the distributed ledger, and the administration server, and each of the general asset tokens has a first value.

2. 2. The system of claim 1, wherein the one or more modules are further operable to receive subscription requests from one or more client devices by the application, using one of the one or more general asset tokens to create one or more specific asset tokens that map to a portion of a specific asset from the general asset pool, each of the subscription requests including asset ownership data of a user associated with the one or more client devices making a request to the distributed ledger or the administration server, each of the one or more client devices being associated with one of a plurality of users associated with one of the one or more general asset tokens used to create one or more specific asset tokens.

3. The one or more modules include: creating, by the token manager on the administration server, in response to at least one received subscription request, a first specific asset token that maps to a portion of a specific asset in the general asset pool, the first specific asset token being based at least in part on data of the request and stored in the data store; storing a record of the generated specific asset token and an updated state of the general asset token as a digital asset, the record including tasks and data interactions between a plurality of users, each of the plurality of users being associated with a remote client device, the general asset token and the specific asset token being stored as data on the administration server or the data store; The system of claim 2 further comprising:

4. 2. The system of claim 1, wherein the one or more modules are further operable to associate, by an application on the administration server, each of the general asset tokens with one or more smart contract protocols, the one or more smart contract protocols being stored in one or more of the distributed ledger, the administration server, and the memory, and each of the one or more smart contract protocols validating one or more general asset tokens in the general asset pool.

5. 3. The system of claim 2, wherein the one or more modules are further operable to associate, via an application on the administration server, each of the specific asset tokens with one or more smart contract protocols, the one or more smart contract protocols being stored in one or more of the distributed ledger, the administration server, and the memory, and each of the one or more smart contract protocols validating one or more specific asset tokens in the general asset pool.

6. 3. The system of claim 2, wherein the one or more modules are further operable to transfer a portion of the specific asset that is mapped to the first specific asset token to the data store, the distributed ledger, the administration server, or a repository in a memory of the server, the transfer being controlled by data in the smart contract or logic associated with the specific asset.

7. The system of claim 6 , wherein the one or more modules are further operable to update a repository stored in memory on the administration server by an asset pool manager to include the general asset token or the specific asset token.

8. 7. The system of claim 6, wherein the one or more modules are further operable to remove the general asset token from the repository and associate the general asset token with an updated general asset pool having different member and value attributes, the general asset token having a second value based on the previous general asset pool extended by newly added assets.

9. 3. The system of claim 2, wherein the one or more modules include a second mapping stored in the data store between a first one of the specific assets and a first specific asset token, the first specific asset token mapping to a portion of the specific asset that is smaller than the specific asset.

10. The value of the specific asset token is equivalent to the general asset token associated with a portion of the specific asset plus a transaction fee. The system of claim 2.

11. The system of claim 2 , wherein the specific asset and all specific asset tokens mapped to the specific asset are associated with an asset that is a financial asset or a physical asset.

12. The system of claim 1 , wherein the one or more modules are further operable to store information of the general asset token in the data store, the distributed ledger, the administration server, or the memory by the application, the distributed ledger being maintained by one or more distributed machines.

13. 3. The system of claim 2, wherein the one or more modules are further operable to store information of a particular asset token by the application in the data store, the distributed ledger, the administration server, or the memory, the distributed ledger being maintained by one or more distributed machines.

14. The one or more modules include: receiving a request by the application stored on the administration server to transfer an interest in a particular asset token between a client device associated with a first user of the plurality of users and a second client device associated with a second user of the plurality of users; updating the data store, the distributed ledger, the administration server, or the memory based on the transfer of the shares of the particular asset token between the first user and the second user; The system of claim 13 further operable to:

15. The one or more modules include: receiving a request by the application stored on the administration server to transfer shares of a general asset token between a client device associated with a first user of the plurality of users and a second client device associated with a second user of the plurality of users; updating the data store, the distributed ledger, the administration server, or the memory based on the transfer of the shares of the particular asset token between the first user and the second user; The system of claim 12 further comprising:

16. The one or more modules include: receiving, by the application on the administration server, an asset recommendation request from a client device associated with one of the plurality of users; processing data associated with the user with a model to generate recommended asset information, the model being trained with the data; providing, by the application on the administration server, recommendation data to the client device associated with one of the plurality of users based on an output of the model; The system of claim 1 further comprising:

17. 2. The system of claim 1, wherein the data store is implemented at least in part by a distributed ledger on one or more remote machines with respect to the administration server.

18. The system of claim 1 , wherein the data store is implemented at least in part by a central server.

19. 3. The system of claim 2, wherein the data store is implemented at least in part by a distributed ledger on one or more remote machines with respect to the administration server.

20. The system of claim 2 , wherein the data store is implemented at least in part by a central server.

21. The system of claim 1 , wherein general asset tokens can be obtained using currency.

22. The system of claim 2 , wherein a particular asset token can be obtained using a currency.

23. The system of claim 2 , wherein general asset tokens create asset-specific tokens through an auction managed by the administration server.

24. The system of claim 2 , wherein the asset protocol automatically converts and updates asset valuation data into one or more elements that are encoded into the generic asset token.

Images