Computing techniques to implement blockchain-based digital tokens with asset-specific attributes

Abstract

The present disclosure implements a digital token with a set of asset-specific attributes, where the set of asset-specific attributes is modifiable or capable of receiving new asset-specific attributes at least after issuing the digital token with the set of asset-specific attributes on a blockchain-based token platform. The functionality may be implemented with a digital token containing an attribute component having a set of key-value pairs populated with a subset of the asset-specific set of attributes, where the set of key-value pairs is programmed to be modified or added with new key-value pairs after issuing the digital token on the blockchain-based token platform.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims the benefit of priority to U.S. patent application 17 / 845,158, filed on June 21, 2022; the entire contents of which are incorporated herein by reference for all purposes. Technical Field

[0003] In general, the present disclosure relates to blockchain. More specifically, the present disclosure relates to blockchain-based digital tokens with asset-specific properties. Background Art

[0004] Assets (e.g., bonds) may be tokenized using digital tokens issued through smart contracts as directed by a decentralized application (dApp) on a blockchain-based tokenization platform (e.g., Ethereum). Traditionally, the dApp presents a menu to the user to create a digital token by selecting a standard for digital tokens (e.g., ERC20, ERC1400) and entering a set of asset-specific properties (e.g., what interest rate applies to the bond) that are encoded into the digital token according to the standard. The user then also operates the menu to request the dApp to interface with the smart contract to issue a digital token with a set of asset-specific properties on the blockchain-based tokenization platform based on the standard, wherein the set of asset-specific properties is encoded into the digital token according to the standard. Alternatively, instead of the user operating the menu, the dApp may be algorithmically triggered to interface with the smart contract to issue a digital token with a set of asset-specific properties on the blockchain-based tokenization platform based on the standard, wherein the set of asset-specific properties is encoded into the digital token according to the standard.

[0005] There are various technical problems with this prior art. First, since the asset-specific attribute set is defined before the digital token is issued on the blockchain-based tokenization platform using the standard, the user cannot modify the asset-specific attribute set encoded into the digital token because the standard is programmed to prohibit or fail to implement such functions. Second, since the asset-specific attribute set is defined before the digital token is issued on the blockchain-based tokenization platform using the standard, the user cannot add new asset-specific attributes to be encoded into the digital token because the standard is programmed to prohibit or fail to implement such functions. Third, since the standard may change after the digital token with the asset-specific attribute set is issued on the blockchain-based tokenization platform based on the standard, if the user expects the digital token with the asset-specific attribute set to remain consistent with the standard, the user may not be able to keep up with (e.g., maintain) such potential changes. Fourth, since a new standard may be developed / introduced after the digital token with the asset-specific attribute set is issued on the blockchain-based tokenization platform based on the standard, the user may want to adapt the digital token with the asset-specific attribute set issued on the blockchain-based tokenization platform based on the standard to the new standard. Summary of the invention

[0006] The present disclosure solves the above technical problems by enabling a digital token to have a set of asset-specific attributes, wherein the set of asset-specific attributes is modifiable or capable of receiving new asset-specific attributes at least after the digital token with the set of asset-specific attributes is issued on a blockchain-based tokenization platform based on a standard. The above functions can be implemented using a digital token including an attribute component having a set of key-value pairs populated with a subset of the set of asset-specific attributes, wherein the set of key-value pairs is programmed to be modified or have new key-value pairs added after the digital token is issued on a blockchain-based tokenization platform based on a standard.

[0007] In one embodiment, a method may include: presenting a user interface by a server to a client, wherein the user interface is programmed to receive (a) a set of asset-specific attributes of a digital token for tokenizing an asset of an asset type, and (b) an identifier of a blockchain-based tokenization platform from a set of identifiers of blockchain-based tokenization platforms capable of hosting the digital token having the set of asset-specific attributes; receiving the set of asset-specific attributes and the identifier of the blockchain-based tokenization platform from the client by the server; generating the digital token based on the set of asset-specific attributes and the identifier of the blockchain-based tokenization platform by the server; The digital token is a digital token, such that the digital token comprises a header component, an attribute component, and an immutable component, wherein the header component comprises an identifier of the asset and a version of the asset, wherein the attribute component comprises a first set of attributes for the asset type, the first set of attributes comprising a first set of key-value pairs populated with a first subset of the asset-specific attribute set, wherein the first set of key-value pairs is programmed to be modified or have new key-value pairs added after the digital token is issued on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform, and wherein the immutable component comprises a second set of attributes for the asset type, the second set of attributes comprising a first set of key-value pairs populated with a first subset of the asset-specific attribute set, wherein the first set of key-value pairs is programmed to be modified or have new key-value pairs added after the digital token is issued on the blockchain-based tokenization platform based on the identifier of the blockchain-based tokenization platform. The method further comprises: comprising: providing a second set of key-value pairs populated with a second subset of the set of asset-specific attributes, wherein the second set of key-value pairs is programmed to be non-modifiable or non-removable after the digital token is issued on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform; issuing the digital token on the blockchain-based tokenization platform based on the identifier of the blockchain-based tokenization platform by the server; and presenting the user interface to the client by the server after the digital token is issued on the blockchain-based tokenization platform based on the identifier of the blockchain-based tokenization platform, wherein the user interface is programmed to Receiving user input from the client, wherein the user input includes an identifier of the asset, a version of the asset, and content; after receiving the user input, based on identifying the digital token via the identifier of the asset and the version of the asset, taking an action with respect to the digital token by the server, wherein the action includes modifying the first set of key-value pairs based on the content or adding the new key-value pairs to the first set of key-value pairs based on the content; and after taking the action with respect to the digital token, reissuing the digital token on the blockchain-based tokenization platform based on the identifier of the blockchain-based tokenization platform by the server.

[0008] In one embodiment, a system may include: a server, which is programmed to: present a user interface to a client, wherein the user interface is programmed to receive (a) a set of asset-specific attributes of a digital token for tokenizing an asset of an asset type, and (b) an identifier of a blockchain-based tokenization platform from a set of identifiers of blockchain-based tokenization platforms capable of hosting the digital token with the asset-specific attribute set; receive the asset-specific attribute set and the identifier of the blockchain-based tokenization platform from the client; generate the digital token based on the asset-specific attribute set and the identifier of the blockchain-based tokenization platform; a digital token, such that the digital token comprises a header component, an attribute component, and an immutable component, wherein the header component comprises an identifier of the asset and a version of the asset, wherein the attribute component comprises a first set of attributes for the asset type, the first set of attributes comprising a first set of key-value pairs populated with a first subset of the asset-specific attribute set, wherein the first set of key-value pairs is programmed to be modified or have new key-value pairs added after the digital token is issued on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform, wherein the immutable component comprises a second set of attributes for the asset type, The second set of attributes comprises a second set of key-value pairs populated with a second subset of the set of asset-specific attributes, wherein the second set of key-value pairs is programmed to be non-modifiable or non-removable after the digital token is issued on the blockchain-based tokenization platform based on the identifier of the blockchain-based tokenization platform; issuing the digital token on the blockchain-based tokenization platform based on the identifier of the blockchain-based tokenization platform; after the digital token is issued on the blockchain-based tokenization platform based on the identifier of the blockchain-based tokenization platform, presenting the user interface to the client, wherein the user interface being programmed to receive user input from the client, wherein the user input includes an identifier of the asset, a version of the asset, and content; after receiving the user input, taking an action for the digital token based on identifying the digital token via the identifier of the asset and the version of the asset, wherein the action includes modifying the first set of key-value pairs based on the content or adding the new key-value pairs to the first set of key-value pairs based on the content; and after taking the action for the digital token, reissuing the digital token on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1An embodiment of a computing architecture for enabling a digital token to have a set of asset-specific properties that can be modified or added at least after the digital token is issued is shown.

[0010] Figure 2 An embodiment of a software stack for enabling a digital token to have a set of asset-specific properties that can be modified or added at least after the digital token is issued is shown.

[0011] Figure 3 Embodiments of digital tokens that are capable of having a set of asset-specific properties that may be modified or added at least after the digital token is issued are shown.

[0012] Figure 4 An embodiment of a set of functionalities of a digital token that is capable of having a set of asset-specific properties that may be modified or added at least after the digital token is issued is shown.

[0013] Figure 5 An embodiment of a computing architecture for enabling a digital token to have a set of asset-specific properties that can be modified or added at least after the digital token is issued, while enabling the digital token to be referenced or contain documents having human-readable text specific to the digital token, is shown.

[0014] Figure 6 An embodiment of a computing architecture for enabling a digital token to have a set of asset-specific properties that can be modified or added before or after the digital token is issued while enabling the digital token to be linked to information in a third-party computing system is shown.

[0015] Figure 7 An embodiment of a computing architecture for enabling a digital token to have a set of asset-specific properties that can be modified or added at least after the digital token is issued while enabling the digital token to be linked to another digital token in series or by inheritance is shown.

[0016] Figure 8 An embodiment of a computing architecture for a blockchain-based tokenization platform that enables users to choose to issue or reissue digital tokens thereon is shown. DETAILED DESCRIPTION

[0017] The present disclosure implements a digital token with a set of asset-specific attributes, wherein the set of asset-specific attributes is modifiable or capable of receiving new asset-specific attributes at least after the digital token with the set of asset-specific attributes is issued on a blockchain-based tokenization platform based on a standard. The above functionality can be implemented using a digital token including an attribute component having a key-value pair set populated with a subset of the set of asset-specific attributes, wherein the key-value pair set is programmed to be modified or have new key-value pairs added after the digital token is issued on a blockchain-based tokenization platform based on a standard. In this way, a user can modify the set of asset-specific attributes encoded into the digital token or add new asset-specific attributes for encoding into the digital token. Similarly, if the standard changes after the digital token with the set of asset-specific attributes is issued on a blockchain-based tokenization platform based on a standard, the user can keep up with (e.g., maintain) such changes when the user expects the digital token with the set of asset-specific attributes to remain consistent with the changed standard. Similarly, if a new standard is developed / introduced after issuing digital tokens with asset-specific sets of attributes on a blockchain-based tokenization platform based on a standard, users can adapt digital tokens with asset-specific sets of attributes issued on a blockchain-based tokenization platform based on a standard to the new standard. Note that digital tokens can virtually represent: traditional electronic assets (e.g., stocks, fixed income) created entirely in electronic, non-materialized form within a central database that records legal asset ownership and transactions, traditional physical assets (e.g., real estate, commodities, diamonds, cars, art, gold) created in the form of physical materials and securely held by a trusted regulatory entity (which records assets held for regulatory clients in a proprietary database of asset ownership and transactions), or new types of digital assets (e.g., investments, cryptocurrencies, fiat currencies) created in digital form directly on a distributed technology platform that records ownership and transactions.

[0018] For example, the technology can enable the definition of asset-specific properties of digital tokens at the time of digital token issuance or after the issuance of digital tokens, while enabling some asset life cycle processes to be embedded in digital tokens. The technology can support currently used DLT protocols and digital token standards, but in some cases, does not rely on any current standards or future standards. Digital tokens can be asset-agnostic and designed with a dynamic and flexible structure that allows digital tokens to represent a variety of asset classes, financial instruments or fixed assets, which can include real estate, collectibles, precious metals, carbon, non-fungible tokens or other forms of property. The compatibility of digital tokens with current smart contracts running on current DLTs enables automation of operations at the time of digital token issuance or after digital token issuance, where such automation is impossible for traditional digital token management technologies. Thus, the technology fills the gap between traditional blockchain-based tokenization platforms and a new generation of blockchain-based tokenization platforms. Blockchain-based tokenization platforms add features to current standards that enable greater security, faster and more efficient issuance or re-issuance of digital tokens, and better verification of underlying assets. Digital tokens can be dynamically created and managed through smart contracts deployed on distributed ledger technology. This "dynamic" nature of the token creation process refers to the ability to define token attributes "on the fly" by network participants when creating the token or at a later time, and token attributes can also be changed by authorized network participants. A third-party system can be implemented where certain token attributes can be inherited from a third-party database, or the third-party system can require the assignment of a separate state (e.g., unverified or verified), which can be updated by a participant with relevant permissions (e.g., a token administrator) or through a link to an applicable trusted third-party system via an application programming interface (API) (e.g., a company registration system) to record the blockchain-based tokenization platform that has changed the state of the identity component.

[0019] In conventional practice, many digital asset tokens are created using static code, which means that the basic token standard requires additional programming to define asset-specific properties. An example of the standard is the ERC1400 series, which is commonly used to express assets as tokens on the blockchain. The properties required for a given use case must be defined before the token can be issued, because the standard cannot define the features and functions of the token at or after issuance. Tokens representing specific asset classes, financial instruments, or fixed assets must be pre-defined and encoded in order to be issued on the DLT. In contrast, the digital token enables the definition of some or all properties that enable the digital token to represent the asset at or after the token is issued (or reissued). Digital tokens (including the properties required to meet the use cases for which they are designed) are created "on the fly" based on a token issuance computing facility constructed in conjunction with token standards and financial instruments, and data elements can constitute financial instruments. The design also enables the digital token to be compatible with other DLTs (not just Ethereum DLT or other current DLTs). The technology introduces a token creation process that provides the flexibility to define token characteristics at the time of token creation (or re-issue) or after the token is created (or re-issued). Under current practice, for example, when a loan digital token is issued, this would require an encoded attribute that defines whether the loan digital token is collateralized at the time of creation. This technology for dynamic token creation introduces flexibility through the "dynamic" nature of token issuance, and loan digital tokens can be created in a way that can meet any use case without having to encode the attributes that will make the digital token a collateralized loan or a non-collateralized loan. The dynamic token creation process can issue collateralized tokens or non-collateralized tokens without encoding or referencing pre-existing templates. In this way, the technology process also contrasts with the traditional way of creating reusable code blocks. The dynamic token creation does not reuse code, but generates digital tokens with attributes as needed when the token is issued (or re-issued) or after the token is issued (or re-issued), and avoids the introduction of pre-coded blocks or templates for representing pre-coded use cases. The technology: (1) implements token creation code by enabling users, systems, or applications to interact directly with the token creation code as it executes on a blockchain network to define, add, or remove asset-specific token properties as needed, (2) implements dynamic arrays by enabling dynamically allocated JavaScript Object Notation (JSON) data objects (e.g., dynamic arrays) to specify and configure asset properties (such as bond maturity dates) on the fly, and (3) implements flexible property requirements by enabling digital tokens to provide flexibility in whether properties are mandatory or required and whether properties are immutable or mutable.Since the digital token has required attributes, where the digital token cannot be issued without these required attributes, dynamic attributes can be mandatory and optional, and some attributes are immutable (cannot be changed) while other attributes are mutable (can be updated). The digital token provides the flexibility to dynamically specify any combination of mandatory / optional or immutable / mutable attributes as required by the business use case. The technology thus implements a digital token with blockchain network agnostic for any specific current DLT (for example, compatible with digital tokens issued on the Ethereum blockchain, but can also be issued on other DLTs). As disclosed herein, there may be a graphical user interface on which a user defines or selects token attributes from a list of asset attributes on the screen to correspond to a specific asset class to construct a digital token representing a traditional asset (such as a fixed income bond). There may be an API through which an application trusted by the digital token can trigger the creation or change of token attributes based on asset requirements such as capital calls. There may be a third-party service that provides data through a smart contract, where a triggering event (such as a price change) updates the token attributes. There can be system messages through which the receipt of a document such as a payment request can create a token with the desired properties and issue it on the blockchain. Properties can also be set in the token by other smart contracts executed in the blockchain environment.

[0020] The present disclosure is now described more fully with reference to the various drawings mentioned above, in which some embodiments of the present disclosure are shown. However, the present disclosure can be embodied in many different forms and should not be interpreted as necessarily being limited to the embodiments disclosed herein. On the contrary, these embodiments are provided so that the present disclosure is detailed and complete, and the various concepts of the present disclosure are fully conveyed to the technician.

[0021] Note that various terms used herein may imply an action or inaction, direct or indirect, full or partial, temporary or permanent. For example, when an element is referred to as being "on," "connected," or "coupled" to another element, the element may be directly on, connected, or coupled to the other element, or there may be intervening elements, including indirect or direct variations. In contrast, when an element is referred to as being "directly connected" or "directly coupled" to another element, there are no intervening elements.

[0022] Likewise, as used herein, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or." That is, unless specified otherwise or clear from the context, "X employs A or B" is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then "X employs A or B" is satisfied under any of the foregoing instances.

[0023] Similarly, as used herein, the various singular forms "a," "an," and "the" are intended to include the various plural forms (e.g., two, three, four) as well, unless the context clearly indicates otherwise. For example, the term "a" should mean "one or more" even if the phrase "one or more" is also used herein.

[0024] Furthermore, when used in this specification, the terms "comprises," "comprising," or "includes," "including," specify the presence of stated features, integers, steps, operations, elements, or components, but do not exclude the presence and / or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof. Furthermore, when the present disclosure states that something is "based on" something else, such a statement refers to a basis, which may also be based on one or more other things. In other words, unless explicitly indicated otherwise, as used herein, "based on" inclusively means "based at least in part on" or "based at least in part on."

[0025] In addition, although the term first, second and other can be used herein to describe various elements, components, regions, layers, subsets, figures or sections, these elements, components, regions, layers, subsets, figures or sections should not necessarily be limited by such terms. On the contrary, these terms are used to distinguish an element, component, region, layer, subset, figure or section from another element, component, region, layer, subset, figure or section. Like this, without departing from the present disclosure, the first element, component, region, layer, subset, figure or section discussed below can be referred to as the second element, component, region, layer, subset, figure or section.

[0026] In addition, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by those of ordinary skill in the art to which the present disclosure belongs. Therefore, terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant technology, and should not be interpreted in an idealized or overly formal sense, unless explicitly defined as such herein.

[0027] Therefore, all issued patents, published patent applications, and non-patent publications (including articles, web pages, websites, products, and manuals identified therein) mentioned in this disclosure are incorporated herein by reference in their entirety for all purposes, to the same extent as each individual issued patent, published patent application, or non-patent publication specifically and individually indicates that it is incorporated by reference. If any disclosure is incorporated herein by reference and such disclosure conflicts with this disclosure in part and / or in its entirety, then to the extent of the conflict and / or broader disclosure and / or broader definition of terms, this disclosure shall prevail. If these disclosures conflict with each other in part and / or in their entirety, then to the extent of the conflict, the disclosure with the later disclosure time shall prevail.

[0028] like Figures 1 to 8 As shown, the present disclosure discloses various systems and methods for dynamically creating digital tokens within distributed network nodes. In this way, digital tokens can be dynamically created and managed through smart contracts deployed on distributed ledger technology (DLT), such as blockchain-based tokenization platforms (e.g., Ethereum). As disclosed herein, the "dynamic" nature of creating digital tokens refers to the ability for network participants to "on the fly" define various asset-specific properties of digital tokens when creating tokens before issuance on a blockchain-based tokenization platform (e.g., Ethereum) or at a later time after a digital token is issued on a blockchain-based tokenization platform (e.g., Ethereum). For example, asset-specific properties can be changed by authorized network participants.

[0029] In conventional practice, many digital tokens (e.g., digital asset tokens) that tokenize assets are created using static code. Therefore, a user who wants to issue a digital token to virtually represent an asset selects the standard that the digital token will follow when it is issued on a blockchain-based tokenization platform (e.g., Ethereum). The asset-specific property set of the asset to be encoded into the digital token is determined and encoded according to the standard selected by the user (e.g., within a menu presented by a dApp). For example, the standard may be the ERC1400 series disclosed at https: / / polymath.network / erc-1400, which can be used to express assets as digital tokens on a DLT. The asset-specific property set required for a given use case must be defined before the digital token can be issued, as disclosed at https: / / ethereum.org / en / developers / tutorials / create-and-deploy-a-defi-app / , because the standard selected by the user does not enable the features and functions of the digital token to be defined at or after issuance. Thus, digital tokens that virtually represent a specific asset class, financial instrument, or fixed asset must be defined and encoded in advance before being issued as digital tokens on the DLT.

[0030] As disclosed herein, the present disclosure differs from such conventional approaches by enabling some, many, most, or all asset-specific attributes that virtually represent an asset to be defined on a digital token when the token is initially issued on a blockchain-based tokenization platform (e.g., Ethereum) or thereafter. Digital tokens are dynamically or "on the fly" created based on immediate user input (e.g., via a physical or virtual keyboard), including the set of asset-specific attributes required to satisfy the use case for which the asset-specific attributes are designed. For example, under current conventional practice, when issuing a digital token for tokenizing a loan asset, a user would need to navigate a menu of a dApp to have encoded asset-specific attributes that define whether the loan asset is tokenized as being mortgaged at the time of creation. In contrast, the present disclosure enables the creation of digital tokens for loan assets in a manner that can satisfy either use case without having to encode a set of asset-specific attributes that would make the digital token virtually represent a mortgage or non-mortgage loan. Thus, the digital tokens can be issued as collateralized virtual representations or non-collateralized virtual representations of assets without pre-coding or referencing pre-existing templates of standards (e.g., ERC20, ERC1400). In this way, the method also contrasts with the traditional way of creating reusable code blocks. For example, enabling the dynamic creation of digital tokens does not reuse code, but rather generates digital tokens with attributes as needed when issuing digital tokens, and avoids introducing pre-coded blocks or templates for virtually representing pre-coded use cases.

[0031] Figure 1 An embodiment of a computing architecture for enabling a digital token to have a set of asset-specific attributes that can be modified or added at least after the digital token is issued is shown. Specifically, computing architecture 100 includes: user 101, data center 104 (e.g., physical building) and data center 106 (e.g., physical building). Data center 104 includes server 102 (e.g., physical, virtual, web page, application, database) and server 103 (e.g., physical, virtual, web page, application, database). Data center 106 includes server 105 (e.g., physical, virtual, web page, application, database). User 101 includes a client (e.g., desktop computer, laptop computer, tablet computer, smart phone, wearable device) that communicates with server 102 or server 103 via a network (e.g., local area network, wide area network, cellular network). Data center 104 and data center 106 communicate with each other via a network (e.g., local area network, wide area network, cellular network). In data center 104, server 102 and server 103 communicate with each other via a network (e.g., local area network, storage area network).

[0032] The server 102 is programmed to interface with the user 101 to receive input from the user 101, the input including a set of asset-specific attributes that the digital token needs to virtually represent. For example, the server 102 may present a user interface with a menu (e.g., drop-down, text box) for the user to participate in to enter or select the set of asset-specific attributes. The input may also include other information related to the creation of the digital token as disclosed herein.

[0033] The server 103 runs a microservices architecture for communication between network components, including communication with external systems, messaging between internal systems, and communication with the DLT on which the digital token will be issued (e.g., a blockchain-based tokenization platform). The microservices architecture can be programmed to have dedicated microservices that perform dedicated tasks to enable digital tokens to be created (as disclosed herein) and subsequently modified or added (as disclosed herein). For example, there may be a dedicated microservice for presenting a menu to the user 101, a dedicated microservice for sending input from the user 101 to logic for creating digital tokens, a dedicated microservice for modifying digital tokens after issuance, a dedicated microservice for adding attributes to digital tokens after issuance, a dedicated microservice for accessing or recalling digital tokens after issuance, a dedicated microservice for reissuing modified or added digital tokens after issuance, or other dedicated microservices for computing tasks or actions disclosed herein.

[0034] Server 105 may serve as a node of a DLT (e.g., a blockchain-based tokenization platform). For example, server 105 may host a copy of the blockchain of the blockchain-based tokenization platform. In this way, based on a request from user 101 transmitted to server 105 via server 102 and server 103, server 105 may issue a digital token, as disclosed herein, wherein the digital token has a set of asset-specific properties derived from input from user 101. As disclosed herein, after the digital token is issued, the set of asset-specific properties may be modifiable or appendable. Note that the DLT on which the digital token can be issued may be of various types, functions, and configurations (e.g., Ethereum, Hyperledger Sawthooth (Sawtooth), Corda).

[0035] Figure 2 An embodiment of a software stack for enabling a digital token to have a set of asset-specific properties that can be modified or added at least after the digital token is issued is shown. Specifically, the software stack 200 runs on top of the computing architecture 100. The software stack 200 includes a user 201, a tokenization platform 206, and a service host 207. The user 201 (e.g., an application, a browser, an attachment for a browser, a mobile application, a messaging interface) is hosted via the user 101. The tokenization platform 206 is hosted via the data center 104. For example, the tokenization platform 206 may include or implement a web application (e.g., a dApp) that can interface with a smart contract on a blockchain-based tokenization platform (e.g., Ethereum, Hyperledger Sawtooth, Corda). The service host 207 is hosted via the data center 106. For example, the service host 207 can communicate with or serve as a node of a blockchain-based tokenization platform (e.g., Ethereum, Hyperledger Sawtoth, Corda).

[0036] The tokenization platform 206 includes an interface 202, a representational state transfer (REST) ​​application programming interface (API) 203, a DLT microservice 204, and an encryption vault 205. The server 102 runs the interface 202 to present a menu to the user 101, receives input from the user 101, and passes the input downstream within the tokenization platform 206 to the DLT microservice 204 via the REST API 203. The interface 202 may include a graphical user interface for human input or a messaging interface from an external financial asset electronic system (e.g., an electronic trading platform, a data warehouse). The server 103 runs the DLT microservice 204 via a microservice architecture. The server 103 runs the REST API 203. The server 103 hosts the encryption vault 205. The interface 202 communicates with the DLT microservice 204 via the REST API 203, but other ways of communicating with the DLT microservice 204 are also possible. Note that the REST API 203 may be used to communicate with the DLT microservice 204 , may be within the DLT microservice 204 , or may be from the DLT microservice 204 .

[0037] The service host 207 includes: a REST API 210, a DLT virtualization layer 209, and a copy of the blockchain of the DLT network 208. The server 105 hosts the REST API 210, the virtualization layer 209, and a copy of the blockchain of the DLT network 208. The REST API 210 communicates with the DLT virtualization layer 209. The DLT virtualization layer 209 communicates with the copy of the blockchain of the DLT network 208. The DLT virtualization layer 209 is logically inserted between the REST API 210 and the copy of the blockchain of the DLT network 208. The DLT microservice 204 communicates with the REST API 210, and vice versa. The DLT microservice 204 can be dedicated to the DLT virtualization layer 209, which is specific to the copy of the blockchain of the DLT network 208.

[0038] The software stack 200 is thus able to dynamically create digital tokens with a set of asset-specific attributes for an asset based on the set of asset-specific attributes and criteria input by the user 201, as disclosed herein. For example, the user 201 can interact with the tokenization platform 206, and the logical components of the tokenization platform 206 create, issue and manage digital tokens with asset-specific attributes, as disclosed herein. Note that the assets of the digital tokens are held by a custodial agent, which can be an entity different from the entity operating the computing architecture 100 and the software stack 200, or the entity operating the computing architecture 100 and the software stack 200 can be the custodial agent. In any case, based on the input from the user 201, the REST API 203 can instruct the DLT microservice 204 to create, retrieve, send, receive or process a message to the service host 207 for the REST API 210 to receive for delivery to the DLT virtualization layer 209, which in turn performs relevant actions on the copy of the blockchain 208 of the DLT network 208. When needed, a similar but reverse communication path can proceed to the DLT microservice 204 for processing. For example, to dynamically create a digital token, as disclosed herein, there can be an HTTP POST call for Token Issuance, Token Set Attributes, Token Set Immutables, or other related or suitable commands. Again, the results of the POST call are transmitted from the service host 207 using various key-value pair responses. For example, such a key-value response can be embodied as or in JavaScript Object Notation (JSON) content or another file format or data exchange format that uses human-readable text to store and send data objects consisting of attribute-value pairs and arrays (or other serializable values).

[0039] The DLT microservice 204 may include an event bus that routes messages within the DLT microservice 204, or is used to receive messages sent to the DLT microservice 204 from outside the DLT microservice 204, or is used to send messages downstream from the DLT microservice 204, as disclosed herein. Such messages may come from external banking and financial applications (e.g., web applications external to the tokenization platform 206 or service host 207) that provide: the messaging or financial instrument input required for the dynamic creation of digital tokens triggered by input from the user 201 to the interface 202 and required by the DLT network 208, including the delivery of token creation and management instructions. The REST API 203 may be configured to receive such messages before, within, or when the event bus routes such messages downstream, as disclosed herein.

[0040] The digital tokens and communications between the DLT microservice 204 and the DLT network 208 are encrypted by keys stored in and accessed through the cryptographic library 205. To issue digital tokens, various relevant instructions (which may be encrypted via the cryptographic library 205) are sent from the DLT microservice 204 to the DLT virtualization layer 209 via the REST API 210 as disclosed herein, and received by the DLT virtualization layer 209. The virtualization software converts the token issuance REST API call into the digital token structure required by the DLT network 208, and transmits status messages back to the DLT microservice 204 via the REST API 210 call.

[0041] Figure 3 An embodiment of a digital token capable of having a set of asset-specific attributes that can be modified or added at least after the digital token is issued is shown. Specifically, as disclosed herein, the digital token has a structure 300 that provides various technical capabilities for enabling dynamic creation of digital tokens, as disclosed herein. When the digital token is issued on a blockchain-based tokenization platform, the digital token has a structure 300 that includes: a header component 301, an attribute component 302, and an immutable component 305, which are logically separate and distinct from each other, although at least two of these components may be a single logical component. After the digital token is issued on the blockchain-based tokenization platform, the digital token may be searchable by the contents of the header component 301, the contents of the attribute component 302, or the contents of the immutable component 305, as disclosed herein.

[0042] The header component 301 (e.g., a set of fields, a set of strings, a set of files) contains at least some basic information about the asset virtually represented by the digital token. If necessary, the basic information includes the identifier, total supply content, version content, creation date, or other information of the asset. For example, after the digital token is issued on the blockchain-based tokenization platform, the digital token can be searched by the identifier, total supply content, version content, creation date, or other information of the asset.

[0043] The identifier of the asset includes a unique value for identifying the asset (e.g., US0118331001). For example, the identifier of the asset may be a Committee on Uniform Securities Identification Procedures (CUSIP) identifier (e.g., nine digits or alphanumeric or alphanumeric, 037833100, 38259P508), an International Security Identification Number (ISIN) identifier (e.g., a 12-character alphanumeric code, US0378331005), a Stock Exchange Daily Official List (SEDOL) identifier (e.g., a string having a length of seven characters formed by a six-digit alphanumeric code and a trailing check digit, 0263494), or other suitable identifiers. When issuing digital tokens on a blockchain-based tokenization platform, the identifier of the asset is set when the digital token is issued on the blockchain-based tokenization platform and cannot be changed at any time during the life cycle of the asset. When issuing digital tokens on a blockchain-based tokenization platform, the identifier of the asset may be used to link the asset to a traditional software system, if desired. When issuing digital tokens on a blockchain-based tokenization platform, the identifier may also be used to manage the asset, including transfer, update, and dissolution.

[0044] The total supply virtually represents the total authorized shares of an asset when issuing digital tokens on a blockchain-based tokenization platform. The total supply is a fixed amount that is set when issuing digital tokens on a blockchain-based tokenization platform. When issuing digital tokens on a blockchain-based tokenization platform, this fixed amount remains unchanged for the life of the asset. When issuing digital tokens on a blockchain-based tokenization platform, this fixed amount corresponds to the sum of all shares of the asset of all owners. For example, this fixed amount can be 200 or 1000000.00 or another suitable amount.

[0045] When issuing digital tokens on a blockchain-based tokenization platform, the version content includes asset-specific version details or a version identifier. For example, the version details or version identifier may be v0.1.24rc or another suitable versioned content.

[0046] The creation date is a date stamp that may include a timestamp of when a digital token is issued on a blockchain-based tokenization platform. When a digital token is issued on a blockchain-based tokenization platform, the creation date is fixed to the time when the digital token is issued on the blockchain-based tokenization platform and cannot be changed. For example, the date stamp may include 03 / 22 / 2020 or 16 / 04 / 2022_05:45pm ET or 04 / 08 / 2025 / 2312.

[0047] The property component 302 (e.g., a field set, a string set, a file set) is a dynamic component of a digital token that enables the issuance of a digital token with an asset-specific property set, as disclosed herein, which can be modified or added or appended with a wide range of properties on the fly before, during, or after the issuance of the digital token on a blockchain-based tokenization platform. The property component 302 contains a set of asset-specific properties organized in a multi-level hierarchy that allows for comprehensive multi-level grouping of various properties of the digital token. For example, if the digital token tokenizes a real estate asset held in the custody of a custodial agent, the property component 302 may contain level 1 properties including: basic properties (e.g., location, certificate, size, identification), document properties or links to document quantities or the document itself (e.g., mortgage loans) or payment schedules. This level allows arbitrary addition of name groupings (e.g., amortization schedules). Similarly, if the digital token tokenizes a bond held in the custody of a regulatory agent, the attribute component 302 may contain basic attributes that may have further sub-attributes, i.e., level 2 of the basic grouping may include characteristics of the financial asset (e.g., coupon rate, number of days).

[0048] The property component 302 is constructed according to the dynamic property structure 303. For example, all levels of the property component 302 can use the dynamic property structure 303. The dynamic property structure 303 includes dynamic properties that are virtually represented by or by dynamically allocated JSON data objects (e.g., dynamic arrays) to specify and configure assets using JSON key-value pairs 304. For example, the JSON data object can be a dynamic entity that is an instance of %DynamicObject or %DynamicArray, which is designed to seamlessly integrate JSON data manipulation into ObjectScript applications, where the JSON text constructor allows dynamic entities to be created by assigning JSON strings directly to variables (docs.intersystems.com / irislatest / csp / docbook / DocBook.UI.Page.cls?KEY=GJSON_CREATE). For example, after issuing a digital token on a blockchain-based tokenization platform, the digital token is searchable by key-value pairs 304. Note that JSON technology is not required, and other suitable key-value pair technologies can be used, whether additionally or alternatively.

[0049] Construct token properties using JSON key-value pairs as follows:

[0050] property

[0051] Group 1

[0052] Key 1: Value 1

[0053] Key 2: Value 2

[0054] Group 2

[0055] Key 1: Value 1

[0056] Key 2: Value 2

[0057] For example:

[0058] property

[0059] Basic Attributes

[0060] Asset Class

[0061] Asset Type

[0062] Coupon Rate

[0063] ...<more if needed>

[0064] document

[0065] Document Name: Link to the document

[0066] In this implementation, values ​​are defined as objects. Values ​​can be data strings, other key-value pairs, or other programs, including other DLT tokens. This provides additional flexibility for how attributes can be created and what types of asset attributes in tokens can be virtually represented. As disclosed herein, the attribute component 302 implements a digital token with an asset-specific attribute set, wherein the asset-specific attribute set is modifiable or capable of receiving new asset-specific attributes at least after issuing a digital token with an asset-specific attribute set on a blockchain-based tokenization platform based on a standard. This allows a digital token containing an attribute component having a key-value pair set populated with a subset of an asset-specific attribute set, wherein the key-value pair set is programmed to be modified or have new key-value pairs added after issuing a digital token on a blockchain-based tokenization platform based on a standard. In this way, a user can modify the asset-specific attribute set encoded into the digital token or add new asset-specific attributes for encoding into the digital token. Likewise, if the standard changes after issuing digital tokens with asset-specific property sets on a blockchain-based tokenization platform based on the standard, the user may be able to keep up with (e.g., maintain) such changes if the user desires the digital tokens with asset-specific property sets to remain consistent with the changed standard. Similarly, if a new standard is developed / introduced after issuing digital tokens with asset-specific property sets on a blockchain-based tokenization platform based on the standard, the user may adapt the digital tokens with asset-specific property sets issued on the blockchain-based tokenization platform based on the standard to the new standard.

[0067] Dynamic attributes can be mandatory and optional. Similarly, some attributes are immutable (cannot be changed), while other attributes are mutable (can be changed). As disclosed herein, digital asset tokens with asset-specific attribute sets provide at least some flexibility to dynamically specify any combination of mandatory / optional or immutable / mutable attributes as required by business use cases. In this way, the immutable component 305 (e.g., a field set, a string set, a file set) is another component of the token. The immutable component 305 is similar in structure to the attribute component 302, with the important difference that the information added to the immutable component 305 cannot be changed or removed. This enables support for specifying other ways to authenticate at least some physical assets, real assets, or financial assets virtually represented by digital tokens, such as signature marks by third parties (including regulators or financial institutions) outside the DLT network 208. For example, after issuing a digital token on a blockchain-based tokenization platform, the digital token is searchable by the key-value pairs therein.

[0068] Figure 4An embodiment of a feature set of a digital token is shown, wherein the digital token is capable of having a set of asset-specific properties that can be modified or added at least after the digital token is issued. Specifically, as disclosed herein, a digital token having a set of asset-specific properties has a feature set 400 (or can be called by a feature set 400). Based on the structure 300 implemented via a software stack 200 running on a computing architecture 100, the digital token can be agnostic with respect to at least one, two, three, four, five, six, seven, eight, nine, ten or more or any specific DLT (e.g., Ethereum, Hyperledger Sawtooth, Corda). The feature set 400 provides unique features to be included in the digital token as well as features that can be included in other standards (e.g., ERC20, ERC1404, etc.) (e.g., Figure 4 The functions are shown in brackets in the figure.

[0069] The update function 401 changes the mutable attributes of the digital token as follows:

[0070] Set Property 402 - Updates an existing property or adds a new property or property grouping to a property component 302 using JSON key-value pairs.

[0071] Set Immutable 403 - Adds the immutable attribute to the immutable section.

[0072] Transfer (ERC20) 404 - enables a share of an asset to be transferred from one entity to another under the protection of the owner's private key (eg, via cryptographic vault 205).

[0073] name (ERC20) 405 - Returns the name of the asset.

[0074] symbol(ERC20) 406 - Returns the symbol of the asset.

[0075] Total Supply (ERC20) 407 - Get the total supply of an asset.

[0076] Balance (ERC20) 408 - Returns the balance of a specific wallet address.

[0077] Detect Transfer Restrictions (ERC1404) 409 - Detect and restrict transactions based on regulatory and compliance requirements.

[0078] Message for Transfer Restrictions (ERC1404) 410 - Sends a text message with a restricted transaction error code.

[0079] As disclosed herein, digital tokens enable various investment types (e.g., assets) to be virtually represented as digital tokens on a computing architecture 100 running a software stack 200. For example, as disclosed herein, digital tokens can enable traditional electronic investments: traditional electronic assets (e.g., stocks, fixed income) that are created entirely in electronic, non-materialized form within a central database that records legal asset ownership and transactions. For example, digital tokens disclosed herein can enable traditional physical investments: traditional physical assets (e.g., commodities, diamonds, cars, art, gold) that are created in physical material form and securely held by a trusted regulatory entity that records assets held for regulatory clients in a proprietary database of asset ownership and transactions. For example, digital tokens disclosed herein can enable new types of digital assets: new types of digital assets (e.g., investments, cryptocurrencies, legal tender) created in digital form directly on a DLT platform 208 that records ownership and transactions. For example, digital tokens disclosed herein can enable token creation smart contracts: creating digital tokens with dynamically defined properties. Different assets with different characteristics can be virtually represented and stored on the DLT platform 208 using the same basic smart contract.

[0080] These features can enable use cases involving token document and repository smart contracts, where a token record may require a reference to a document (e.g., a productivity document, a portable document format (PDF) file, an image file, a video file, an audio file, an MS Word file) that virtually represents a particular investment attribute (e.g., a scan of company registration information, a memorandum of understanding). In this case, the computing architecture 100 on which the software stack 200 runs stores the document file in a document repository (e.g., on or accessible to the server 103 or in the data center 104) and executes the token document smart contract to generate a document hash value stored in the token record using a one-way mathematical hash function.

[0081] These features may enable use cases involving third-party systems where certain token attributes may be inherited from a third-party database or may require assignment of a separate state (e.g., unverified or verified) that may be updated by a participant with relevant authority (e.g., a token administrator) or via a link to an applicable trusted third-party system via an API (e.g., a corporate registry system). The computing architecture 100 on which the software stack 200 runs will record entities that change the state of an identity component on the DLT network 208.

[0082] These features can enable use cases including token relationship links / hierarchies, where the computing architecture 100 with the software stack 200 running thereon enables token relationship links and hierarchies to be established between various token records, and associated records can inherit token properties from parent tokens using smart contracts on the DLT network 208.

[0083] In one mode of operation, a method may include: presenting, by a server 103, a user interface (e.g., a visual menu, a visual wizard) to a client (e.g., a desktop computer, a laptop computer). The user interface may be programmed to receive (a) a set of asset-specific properties for a digital token used to tokenize an asset (property) of an asset type (e.g., real estate), and (b) an identifier of a blockchain-based tokenization platform from a set of identifiers of a blockchain-based tokenization platform (e.g., Ethereum, Corda, Hyperledger) that are capable of hosting digital tokens with the asset-specific property set. For example, the user interface may be presented via a dApp. The method may also include: receiving, by the server, the asset-specific property set and an identifier of the blockchain-based tokenization platform from the client (e.g., based on an interaction with the user interface). The method may also include: generating, by the server, a digital token based on the asset-specific property set and the identifier of the blockchain-based tokenization platform, such that the digital token includes a header component, an attribute component, and an immutable component, such as Figure 3 The header component contains the asset identifier and the asset version, as shown in Figure 3 The property component includes a first property set for the asset type, the first property set including a first key-value pair set populated with a first subset (e.g., all, less than all) of the asset-specific property set, such as Figure 3 The first set of key-value pairs is programmed to be modified or have new key-value pairs added after the digital token is issued on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform. The immutable component includes a second set of attributes for the asset type, the second set of attributes including a second set of key-value pairs populated with a second subset (e.g., all, less than all) of the asset-specific attribute set, such as Figure 3As shown. The second set of key-value pairs is programmed to be non-modifiable or non-removable after the digital token is issued on the blockchain-based tokenization platform based on the identifier of the blockchain-based tokenization platform. The method may also include: issuing the digital token on the blockchain-based tokenization platform based on the identifier of the blockchain-based tokenization platform by the server. The method may also include: after the digital token is issued on the blockchain-based tokenization platform based on the identifier of the blockchain-based tokenization platform, presenting a user interface to the client by the server. The user interface may be programmed to receive user input from the client, wherein the user input includes an identifier of the asset, a version of the asset, and content (e.g., modified or appended to Figure 3 The method may include, after receiving the user input, taking an action by the server for the digital token based on identifying the digital token via the identifier of the asset and the version of the asset (e.g., by recalling the digital token). The action may include modifying the first set of key-value pairs based on the content, or adding the new key-value pairs to the first set of key-value pairs based on the content (or other content). The method may include, after taking the action for the digital token, reissuing by the server on the blockchain-based tokenization platform based on the identifier of the blockchain-based tokenization platform, which may occur without issuing a new digital token.

[0084] Note that the first subset of the set of asset-specific attributes and the second subset of the set of asset-specific attributes may share at least one asset-specific attribute, which may be relevant to certain types of tokenization use cases (e.g., tokenization-specific attributes may need to be shared). However, the first subset of the set of asset-specific attributes and the second subset of the set of asset-specific attributes may not share any asset-specific attributes, which may be relevant to other types of tokenization use cases (e.g., tokenization-specific attributes are not shared). In other cases, the second subset of the set of asset-specific attributes is a copy of the first subset of the set of asset-specific attributes, which may be useful in other tokenization use cases (e.g., tokenization-specific attributes may need to be cloned).

[0085] Figure 5An embodiment of a computing architecture for enabling a digital token to have a set of asset-specific properties that can be modified or added at least after the digital token is issued while enabling the digital token to be referenced or to contain a document with human-readable text specific to the digital token is shown. Specifically, software stack 500 is similar to software stack 200. Software stack 500 includes: user 501, tokenization platform 502, storage 510, and digital token 504 with immutable properties 509, as disclosed herein. User 501 includes user 201 hosted via user 101. Tokenization platform 502 includes tokenization platform 206 hosted via server 102 and server 103 in data center 104. Tokenization platform 502 includes: file 503, DLT microservice 505, encryption library 506, encryption file 507, and hash value 508. DLT microservice 505 includes DLT microservice 204. Encryption library 506 includes encryption library 205. External to the tokenization platform 502, the software stack 500 includes a memory 510 (e.g., a database, a relational database, an in-memory database, a NoSQL database, a productivity document suite) and a digital token 504 with immutable properties 509, as disclosed herein. The digital token 504 includes the structure 300. The immutable properties 509 include the immutable component 305.

[0086] Collectively, the software stack 500 implements token document and repository smart contract technology, including technology for associating additional documents with digital tokens 504, which uses smart contracts for immutable references on blockchain nodes. For example, a digital token 504 may require a reference (e.g., link, address, pointer) to a document (e.g., productivity document, PDF file, image file, image file, video file, audio file, MS Word file) that publicly, references, or virtually represents a specific investment attribute (e.g., a scan of company registration information, a memorandum of understanding). In this case, the computing architecture 100 on which the software stack 500 runs stores the document file (e.g., productivity document, PDF file, image file, image file, video file, audio file, MS Word file) in a document repository (e.g., memory 510) and executes a token document smart contract to generate a document hash value stored in the digital token 504 using a one-way mathematical hash function. In particular, many of the digital tokens 504 disclosed herein may require token holders and investors to reference external documents. External documentation may not be available when those digital tokens 504 may be issued on a blockchain-based tokenization platform. Additionally, such documentation may accumulate during the life of a digital token 504. Under conventional token creation methods, external documentation cannot be added to an already issued digital token 504, and a new digital token must be created, which may not always be desirable or possible.

[0087] In contrast, the digital token 504 disclosed herein enables new attributes to be dynamically added to the digital token 504 after the digital token 504 is issued or reissued on a blockchain-based tokenization platform, thereby enabling the document to be referenced when an external document is created / modified and required. In addition, a document reference can be added by a cryptographic hash, which guarantees that the corresponding document has not been changed since the document was referenced in the digital token 504. This functionality can be implemented by a user 501 uploading a file 503 related to a digital asset token 504 that virtually represents an asset, as disclosed herein. This can occur after the digital token 504 is issued or reissued on a blockchain-based tokenization platform. The file 503 may include descriptive text that is generally human-readable in plain text format, but other types of content are also possible (e.g., barcodes). The file 503 may include (or refer to, point to, or link to) a productivity document, a PDF file, an image file, an image file, a video file, an audio file, an MS Word file, or another suitable file. The file 503 may be a legal contract, a technical description, a photo, or other documents related to an asset virtually represented by a digital token. DLT microservice 505 encrypts file 503 via encryption library 506 to form encrypted file 507. Encrypted file 507 is now identified by cryptographic hash value 508 that identifies encrypted file 507, which is necessary to decrypt encrypted file 507 into file 503 and ensure that encrypted file 507 has not been altered. DLT microservice 505 instructs that encrypted file 507 identified by hash value 508 be stored on external file storage 510. As disclosed herein, digital tokens 504 are dynamically generated, and as disclosed herein, new attributes can be added to digital tokens 504 on the fly. Using Figure 3In the illustrated structure 300, the DLT microservice 505 adds the hash value 508 as an immutable attribute 509 to the digital token 504, or requests that the hash value 508 be added as an immutable attribute 509 to the digital token 504, which can be before, during, or after the issuance of the digital token on the blockchain-based platform, as disclosed herein. Thus, the hash value 508 can be written to the immutable attribute 509. For example, after the identifier of the blockchain-based tokenization platform issues the digital token 504 on the blockchain-based tokenization platform, the hash value 508 can be written to a new key-value pair within the second set of key-value pairs without: (a) modifying or removing the second subset of the set of asset-specific attributes already recorded in the second set of key-value pairs from the second subset, and (b) creating a new digital token, so that the encrypted file 507 is linked to the digital token 504 to be retrieved and decrypted by the server 103 from the memory 510 via the hash value 508. The DLT microservice 505 may add the hash value 508 to a new key-value pair within the immutable attribute 509 of the digital token 504 or request that the hash value 508 be added to a new key-value pair within the immutable attribute 509 of the digital token 504 before or after the encrypted file 507 is sent from the tokenization platform 502 (e.g., via the server 103) to the storage 510. As a result, the encrypted file 507 is now linked to the digital token 504 for retrieval and decryption from the storage 510 by the server 103 via the hash value 508, whether within or via the encryption vault 506.

[0088] Figure 6An embodiment of a computing architecture for enabling digital tokens to have a set of asset-specific attributes that can be modified or added before or after the digital tokens are issued while enabling digital tokens to be linked to information in third-party computing systems is shown. Specifically, software stack 600 is similar to software stack 500 or software stack 200. Software stack 600 includes: a third-party software application 602, a tokenization platform 603, and a digital token 607 with attributes 608. The third-party software application 602 may include a client 201 hosted on client 101, or may be a software application (e.g., a web application, a microservice application, a dApp, a mobile application) external to the tokenization platform 206. The tokenization platform 603 includes the tokenization platform 502 or the tokenization platform 206 hosted via servers 102 and 103 in a data center 104. The tokenization platform 603 includes: a DLT microservice 604, an encryption library 605, and an identifier (ID) attribute value 606. The DLT microservice 604 may include the DLT microservice 505 or the DLT microservice 204. Cryptographic library 605 may include cryptographic library 506 or cryptographic library 205. Collectively, software stack 600 implements techniques for linking information in a third-party system (such as an account in an online banking system) to a digital token 607, where the third-party system includes third-party software application 602.

[0089] Some processes may require that the attributes (e.g., value, numerical value, alphanumeric value) of an asset (e.g., financial instrument, bond, real estate item, commodity) be inherited (e.g., copied) from a third-party software application 602 external to the DLT network 208 and the tokenization platform 603 onto the digital token 607. Such attributes may be statically linked to the third-party software application 602, or may require periodic updates by some network participants (e.g., blockchain nodes) with relevant rights. The technology disclosed herein links the DLT network 208 and the third-party software application 602 through the digital token 607 to contain a record on the DLT network 208 of any entity that changes the virtual representation of the asset in any way. For example, the digital token 607 is typically issued to manage digital currencies and financial instruments stored on the DLT network 208. However, there are situations where financial transactions need to reference assets and systems on both the DLT network 208 and traditional financial applications and databases (e.g., third-party software applications 602). Therefore, a mechanism to bridge digital currencies and traditional fiat currencies may be needed. Thus, the digital token 607 enables the addition of attributes of an asset to the digital token 607, wherein the attributes virtually represent an identification scheme used by a third-party software application 602 external to the DLT network 208 and the tokenization platform 603 used by the digital token 607. Furthermore, the software stack 600 may issue or reissue the digital token 607 using at least two, three, four, five, six, seven, eight, nine, ten, or more DLT protocols that may be computationally / operably different from one another. This DLT-agnostic design, combined with the ability to add attributes to the digital token 607 on the fly, provides a computational bridge between the digital token 607 and traditional asset computational systems without tying the token issuer (e.g., the tokenization platform 603) to only one specific current blockchain protocol. For example, in some cases, this DLT-agnostic design, combined with the ability to add attributes to digital tokens 607 on the fly, provides a computational bridge between digital tokens 607 and traditional asset computing systems without tying the token issuer (e.g., tokenization platform 603) to any particular current blockchain protocol.

[0090] The software stack 600 can be used to enable a digital token 607 to be virtually incorporated into a property or asset referenced on a conventional computing financial system (e.g., an electronic trading platform). The third-party software application 602 includes an identifier (ID) 601 for virtually representing a property or asset on the third-party software application 602, and sends the ID 601 (e.g., a copy thereof) to the tokenization platform 603 for retrieval by the DLT microservice 604. For example, the ID 601 may include a unique value (e.g., US0118331001) for identifying an asset. For example, the ID 601 may be a CUSIP identifier, an ISIN identifier, a SEDOL identifier, or other suitable identifier. For example, the ID 601 may virtually represent an account number, a security identifier, or other suitable identifier. The third-party software application 602 may also send the system identification data (e.g., a copy thereof) of the third-party software application 602 to the tokenization platform 603 for retrieval by the DLT microservice 604. The third-party software application 602 sends the ID 601 (and optionally the system identification data of the third-party software application 602) to the tokenization platform 603 for receipt by the DLT microservice 604 via a direct or indirect connection, an API, manual user input (e.g., a physical or virtual keyboard), or other suitable means. The DLT microservice 604 receives the ID 601 (and optionally the system identification data of the third-party software application 602). The DLT microservice 604 then encrypts the ID 601 (which may include encrypting the system identification data of the third-party software application 602) via the encryption library 605 to virtually represent the ID 601 (and optionally the third-party software application 602) as an ID attribute value 606 (which may be embodied as a cryptographic hash) of an attribute of the asset.

[0091] The ID attribute value 606 encrypted via the encryption library 605 is added to the digital token 607 (e.g., the attribute component 302) as an attribute 608, regardless of whether the digital token 607 already exists, is being newly created, is being reissued, or has been reissued. The ID attribute value 606 encrypted via the encryption library 605 is added (e.g., dynamically) to the digital token 607 as an attribute 608, added as a new key-value pair within the first key-value pair set to the key-value pair 304 in the attribute component 302 of the digital token 607, without modifying or removing the first subset of the asset-specific attribute set already recorded in the first key-value pair set. As the digital token 607 is later changed or updated (e.g., new key-value pairs of attributes 608), the blockchain-based tokenization platform records any updates and the specific parties that made those updates, thereby: (a) providing an immutable audit trail of those changes in the state of the digital asset 607 and (b) providing the ID 601 encrypted via the cryptographic hash 606 from the third-party application 602 to the server 103.

[0092] Figure 7 An embodiment of a computing architecture for enabling a digital token to have a set of asset-specific properties that can be modified or added at least after the digital token is issued while enabling the digital token to be linked to another digital token in series or by inheritance is shown. Specifically, the software stack 700 includes: a first digital token 701, a tokenization platform 702, and a second digital asset token 702 with properties 707. The tokenization platform 702 may include: a tokenization platform 603, a tokenization platform 502, or a tokenization platform 206 hosted via servers 102 and 103 in a data center 104. The tokenization platform 702 may include: a DLT microservice 703, an encryption library 704, and an ID value 705. The DLT microservice 703 may include: a DLT microservice 604, a DLT microservice 505, or a DLT microservice 204. The encryption library 704 may include: an encryption library 605, an encryption library 506, or an encryption library 205. The first digital token 701 or the second digital token 706 may include: digital token 607, digital token 504, or other digital tokens, whether or not including structure 300 or implementing functional set 400. Collectively, software stack 700 implements token relationship links via techniques for linking digital tokens in a serial manner or through parent-child relationships. For example, some digital token relationship links and hierarchies may be established between various digital token records, and associated records may reference other digital tokens on the blockchain and inherit token properties from the parent digital token.

[0093] Digital tokens are typically issued as a single digital token designed for a single task, such as transferring payments, granting asset ownership, or other. However, in some cases, a digital token may represent an entity with multiple parts, each with its own assets or transaction flows associated with it. In the case of issuing digital tokens to implement a single transaction function, at least some parts of the ongoing transaction or audit chain may be lost. Therefore, the digital tokens disclosed herein enable one digital token to reference other digital tokens, with child transactions derived from: contract digital tokens in a parent-child hierarchy, or digital token pairs or strings of digital tokens that need to be directly related and referenced to maintain contractual liability or audit integrity.

[0094] A digital token may need to reference one or more related digital tokens. The first digital token 701 or the second digital token 706 may be embodied as any digital token disclosed herein, whether before, during, or after issuance or re-issuance. For example, each of the first digital token 701 and the second digital token 706 has a structure 300, but the header component 301 may be different from each other (although it may also be the same), and the keys or values ​​within the attribute component 302 or the immutable component 305 may be different from each other. Using the software stack 700, the first digital token 701 virtually represents a portion of a transaction chain or asset transferred to the tokenization platform 702. A software application (e.g., a third-party software application 602) can transfer the ID to the tokenization platform 702 via a direct connection, an API, manual input, or other suitable means. The DLT microservice 703 receives the identification data set of the first digital token 701 and encrypts the identification data set through the encryption library 704 to represent the first digital token 701 as a token ID value 705 in cryptographic hash form. The token ID value 705 is added to the second digital token 706. Using Figure 3 In the illustrated structure 300, the attribute 707 is dynamically added to the attribute component 302 of the second digital token 706 (e.g., as a new key-value pair), causing the cryptographic hash value to be written to the new key-value pair within the set of key-value pairs within the second digital token 706 without modifying or removing those asset-specific attributes already recorded in the set of key-value pairs within the second digital token 706, and causing the changes in the new key-value pair to be re-encoded on the blockchain-based tokenization platform external to the data center 104 and the software application 602. When the second digital token 706 is changed or updated, the DLT network 208 records any updates and the party that made those changes or updates, thereby providing an immutable audit trail of those changes in the state of the second digital token 706, while maintaining the current relationship between and among the first digital token 701 and the second digital token 706.

[0095] Figure 8An embodiment of a computing architecture for a blockchain-based tokenization platform that enables users to choose to issue or reissue digital tokens on it is shown. Specifically, conventional digital tokens can be issued for a specific blockchain technology, which are usually hand-coded according to a preset template. Therefore, token use cases and asset classes must be predetermined and coded for a specific blockchain, providing less flexibility and the ability to respond quickly to market needs. This is solved by a computing architecture with a DLT-agnostic token issuance engine that enables users to determine the best DLT for digital tokens or issue digital tokens on the most competitive platform for digital tokens, regardless of the current DLT. Digital tokens are blockchain-agnostic and asset-agnostic, and are designed with a dynamic and flexible structure that allows digital tokens to represent a variety of financial instruments, physical assets, or digital asset management requirements. The computing architecture implements a virtualization layer that enables the tokenization engine to create digital tokens for many types of DLTs, where digital tokens can be created instantly for any current DLT required by the user, the virtualization layer abstracts DLT-specific requirements to provide general virtual token properties, logical connectors within the virtualization layer automatically create digital token properties based on the target DLT, and digital tokens can be issued on multiple DLTs simultaneously.

[0096] For example, there may be a graphical user interface for selecting a blockchain-based tokenization platform on which to issue or reissue digital tokens and for inputting at least a set of asset-specific properties that can be modified or added after the issuance or reissue of digital tokens. Figure 8 The graphical user interface enables a user to select a target DLT for the digital token from a list of available options, as disclosed herein.

[0097] In addition, the features described for some example embodiments can be combined in various other example embodiments in any arrangement or combination, or combined with various other example embodiments. The different aspects or elements of the example embodiments disclosed herein can be combined in a similar manner. The term "combination (combination, combinatory)" or "its combination" used herein refers to all permutations and combinations of the items listed before the term. For example, "A, B, C or its combination" is intended to include at least one of the following: A, B, C, AB, AC, BC or ABC, and if the order is important in a particular context, it is also BA, CA, CB, CBA, BCA, ACB, BAC or CAB. Continuing this example, the combination containing the repetition of one or more items or terms is clearly included, such as BB, AAA, AB, BBC, AAABCCCC, CBBAAA, CABABB, etc. It will be appreciated by those skilled in the art that there is usually no restriction on the number of items or terms in any combination, unless it is obvious from the context that it is other situations.

[0098] Various embodiments of the present disclosure may be implemented in a Da-ta processing system suitable for storing and / or executing program code, the system comprising at least one processor coupled directly or indirectly to a memory element via a system bus. The memory element includes, for example, a local memory employed during actual execution of the program code, a bulk memory, and a cache memory that provides temporary storage of at least some program code in order to reduce the number of times code must be retrieved from the bulk memory during execution.

[0099] I / O devices (including but not limited to keyboards, displays, pointing devices, DASD, tapes, CDs, DVDs, thumb drives and other storage media, etc.) can be coupled to the system either directly or through intervening I / O controllers. Network adapters may also be coupled to the system to enable the data processing system to be coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the available types of network adapters.

[0100] The present disclosure may be embodied in a system, method, and / or computer program product. The computer program product may include a computer-readable storage medium having thereon computer-readable program instructions for causing a processor to perform various aspects of the present disclosure. A computer-readable storage medium may be a tangible device capable of saving and storing instructions used by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a compact disc read-only memory (CD-ROM) with a port, a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanical encoding device having instructions recorded thereon (such as a punch card or a raised structure in a groove), and any suitable combination of the foregoing.

[0101] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or downloaded to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium in the corresponding computing / processing device.

[0102] Computer-readable program instructions for performing the operations of the present disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages, such as Smalltalk, C++, etc., and conventional procedural programming languages, such as "C" programming languages ​​or similar programming languages. Code segments or machine executable instructions may be represented by any combination of procedures, functions, subroutines, programs, routines, subroutines, modules, software packages, classes, or instructions, data structures, or program statements. Code segments may be coupled to another code segment or hardware circuit by passing and / or receiving information, data, independent variables, parameters, or memory contents. Information, independent variables, parameters, data, etc. may be passed, forwarded, or sent in any suitable manner, including memory sharing, message passing, token passing, network transmission, etc. Computer-readable program instructions may be executed entirely on a user's computer, partially on a user's computer, as a stand-alone software package, partially on a user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or a connection to an external computer (e.g., using an Internet service provider via the Internet) may be formed. In some embodiments, electronic circuits including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) may execute computer-readable program instructions to customize the electronic circuits by utilizing state information of the computer-readable program instructions to perform aspects of the present disclosure.

[0103] Aspects of the present disclosure are described herein with reference to the flowchart and / or block diagram of the method, device (system) and computer program product according to the embodiment of the present disclosure. It will be understood that each box of the flowchart and / or block diagram and the box combination of the flowchart and / or block diagram can be realized by computer-readable program instructions. The various illustrative logic boxes, modules, circuits and algorithm steps described in conjunction with the embodiments disclosed herein can be implemented as electronic hardware, computer software or a combination of the two. In order to clearly illustrate this interchangeability of hardware and software, various illustrative components, boxes, modules, circuits and steps have been generally described above around their functionality. As for whether such a function is implemented as hardware or software, it depends on specific applications and the design constraints imposed on the entire system. The technician can implement the described functionality in an alternative manner for each specific application, but such implementation decision should not be interpreted as causing a departure from the scope of the present disclosure.

[0104] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each frame in the flow chart or block diagram can represent a module, segment or part of an instruction, which includes one or more executable instructions for realizing a specified one (or more) logical function. In some alternative implementations, the function indicated in the frame may not occur in the order indicated in the accompanying drawings. For example, depending on the function involved, the two frames shown in succession can actually be executed substantially concurrently, or these frames can sometimes be executed in reverse order. It should also be noted that each frame in the block diagram and / or flow chart and the combination of frames in the block diagram and / or flow chart can be implemented by a system based on dedicated hardware that performs a specified function or action or performs a combination of dedicated hardware and computer instructions.

[0105] Words such as "then," "next," and the like are not intended to limit the order of operations; these words are merely used to guide the reader through the description of the method. Although a process flow diagram may describe the operations as a sequential process, many of these operations may be performed in parallel or simultaneously. In addition, the order of these operations may be rearranged. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, and the like. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function or the main function.

[0106] Features or functions described for certain example embodiments may be combined and sub-combined in various other example embodiments and / or combined and sub-combined with various other example embodiments. In addition, different aspects and / or elements of the example embodiments disclosed herein may also be combined and sub-combined in a similar manner. In addition, some example embodiments, whether individually and / or collectively, may be components of a larger system, wherein other processes may take precedence over their application and / or otherwise modify their application. In addition, as disclosed herein, several steps may be required before, after, and / or concurrently with the example embodiments. Note that at least any and / or all methods and / or processes disclosed herein may be at least partially performed in any manner via at least one entity or participant.

[0107] Although preferred embodiments have been depicted and described herein in detail, those skilled in the art will appreciate that various modifications, additions, substitutions etc. are possible without departing from the spirit of the present disclosure. These are therefore considered to be within the scope of the present disclosure as defined in the accompanying claims.

Claims

1. A method comprising: Presenting, by the server, a user interface to the client, wherein the user interface is programmed to receive (a) a set of asset-specific properties of a digital token for tokenizing an asset of an asset type, and (b) an identifier of a blockchain-based tokenization platform from a set of identifiers of blockchain-based tokenization platforms capable of hosting the digital token having the set of asset-specific properties; Receiving, by the server from the client, the set of asset-specific attributes and an identifier of the blockchain-based tokenization platform; generating, by the server, the digital token based on the asset-specific property set and an identifier of the blockchain-based tokenization platform, the digital token comprising a header component, a property component, and an immutable component, wherein the header component comprises an identifier of the asset and a version of the asset, wherein the property component comprises a first property set for the asset type, the first property set comprising a first set of key-value pairs populated with a first subset of the asset-specific property set, wherein the first set of key-value pairs is programmed to be modified or have new key-value pairs added after the digital token is issued on the blockchain-based tokenization platform based on the identifier of the blockchain-based tokenization platform, wherein the immutable component comprises a second property set for the asset type, the second property set comprising a second set of key-value pairs populated with a second subset of the asset-specific property set, wherein the second set of key-value pairs is programmed to be non-modifiable or non-removable after the digital token is issued on the blockchain-based tokenization platform based on the identifier of the blockchain-based tokenization platform; issuing, by the server, the digital token on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform; After issuing the digital token on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform, presenting, by the server, the user interface to the client, wherein the user interface is programmed to receive user input from the client, wherein the user input includes an identifier of the asset, a version of the asset, and content; After receiving the user input, based on identifying the digital token via the identifier of the asset and the version of the asset, taking an action by the server with respect to the digital token, wherein the action comprises modifying the first set of key-value pairs based on the content or adding the new key-value pairs to the first set of key-value pairs based on the content; and After the action is taken with respect to the digital token, the digital token is reissued by the server on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform.

2. The method according to claim 1, further comprising: presenting, by the server, the user interface to the client after issuing the digital token on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform, wherein the user interface is programmed to receive an identifier of the asset, a version of the asset, and a selection of a file containing human-readable descriptive text that discloses, references, or indicates specific investment attributes of the asset; receiving, by the server, an identifier of the asset, a version of the asset, and a copy of the file based on the selection after issuing the digital token on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform; After issuing the digital token on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform, encrypting the copy by the server so that an encrypted file is formed, and identifying the encrypted file by a cryptographic hash value; After issuing the digital token on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform, sending, by the server, the encrypted file for storage in a memory external to the server and the blockchain-based tokenization platform; identifying, by the server, the digital token via the identifier of the asset and the version of the asset after issuing the digital token on the blockchain-based tokenization platform based on the identifier of the blockchain-based tokenization platform; and After the digital token is issued on the blockchain-based tokenization platform based on the identifier of the blockchain-based tokenization platform, the server causes the cryptographic hash value to be written to a new key-value pair within the second set of key-value pairs without: (a) modifying or removing the second subset of the set of asset-specific attributes already recorded in the second set of key-value pairs, and (b) creating a new digital token, so that the encrypted file is linked to the digital token to be retrieved and decrypted by the server from the memory via the cryptographic hash value.

3. The method according to claim 1, further comprising: After issuing the digital token on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform, receiving, by the server from a software application hosted external to a data center containing the server, an identifier virtually representing an asset-specific attribute of the digital token; encrypting, by the server, the identifier virtually representing the asset-specific attribute of the digital token so as to form an attribute value represented as a cryptographic hash; as well as The server causes the cryptographic hash to be written to a new key-value pair within the first set of key-value pairs without modifying or removing the first subset of the set of asset-specific properties already recorded in the first set of key-value pairs, so that the changes in the new key-value pair are re-encoded on the blockchain-based tokenization platform external to the data center and the software application.

4. The method according to claim 1, wherein: The digital token is a first digital token, wherein the header component is a first header component, wherein the attribute component is a first attribute component, wherein the immutable component is a first immutable component, and the method further comprises: receiving, by the server, a set of identification data of the first digital token from a software application hosted external to a data center containing the server after issuing the digital token on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform; encrypting, by the server, the set of identification data so as to form an attribute value represented as a cryptographic hash; and The server causes the cryptographic hash to be added to a second digital token, the second digital token comprising a second header component, a second attribute component comprising a third set of key-value pairs, and a second immutable component, such that the cryptographic hash is written to a new key-value pair within the third set of key-value pairs without modifying or removing those asset-specific attributes already recorded in the third set of key-value pairs, and such that changes in the new key-value pair are re-encoded on the blockchain-based tokenization platform external to the data center and the software application.

5. The method according to claim 1, wherein: The first subset of the set of asset-specific attributes and the second subset of the set of asset-specific attributes share at least one asset-specific attribute.

6. The method according to claim 1, wherein: The first subset of the set of asset-specific attributes and the second subset of the set of asset-specific attributes do not share any asset-specific attributes.

7. The method according to claim 1, wherein: The second subset of the set of asset-specific attributes is a copy of the first subset of the set of asset-specific attributes.

8. The method according to claim 1, wherein: The first set of key-value pairs is programmed to be modified after the digital token is issued on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform.

9. The method according to claim 1, wherein: The first set of key-value pairs is programmed to have the new key-value pairs added after the digital token is issued on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform.

10. The method according to claim 1, wherein: The second set of key-value pairs is programmed to be unmodifiable after the digital token is issued on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform.

11. The method according to claim 1, wherein: The second set of key-value pairs is programmed to be non-removable after the digital token is issued on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform.

12. The method according to claim 1, wherein: The action includes modifying the first set of key-value pairs based on the content.

13. The method according to claim 1, wherein: The action includes adding the new key-value pair to the first set of key-value pairs based on the content.

14. A system comprising: Hardware servers that are programmed to: presenting a user interface to a client, wherein the user interface is programmed to receive (a) a set of asset-specific properties of a digital token for tokenizing an asset of an asset type, and (b) an identifier of a blockchain-based tokenization platform from a set of identifiers of blockchain-based tokenization platforms capable of hosting the digital token having the set of asset-specific properties; receiving, from the client, the set of asset-specific attributes and an identifier of the blockchain-based tokenization platform; generating the digital token based on the set of asset-specific properties and an identifier of the blockchain-based tokenization platform, such that the digital token comprises a header component, a property component, and an immutable component, wherein the header component comprises an identifier of the asset and a version of the asset, wherein the property component comprises a first set of properties for the asset type, the first set of properties comprising a first set of key-value pairs populated with a first subset of the set of asset-specific properties, wherein the first set of key-value pairs is programmed to be modified or have new key-value pairs added after the digital token is issued on the blockchain-based tokenization platform based on the identifier of the blockchain-based tokenization platform, wherein the immutable component comprises a second set of properties for the asset type, the second set of properties comprising a second set of key-value pairs populated with a second subset of the set of asset-specific properties, wherein the second set of key-value pairs is programmed to be non-modifiable or non-removable after the digital token is issued on the blockchain-based tokenization platform based on the identifier of the blockchain-based tokenization platform; issuing the digital token on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform; After issuing the digital token on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform, presenting the user interface to the client, wherein the user interface is programmed to receive user input from the client, wherein the user input includes an identifier of the asset, a version of the asset, and content; After receiving the user input, based on identifying the digital token via the identifier of the asset and the version of the asset, taking an action with respect to the digital token, wherein the action comprises modifying the first set of key-value pairs based on the content or adding the new key-value pairs to the first set of key-value pairs based on the content; and After taking the action with respect to the digital token, reissuing the digital token on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform.

15. The system of claim 14, wherein: The hardware server is further programmed to: presenting the user interface to the client after issuing the digital token on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform, wherein the user interface is programmed to receive an identifier of the asset, a version of the asset, and a selection of a file containing human-readable descriptive text that discloses, references, or indicates specific investment attributes of the asset; receiving, after issuing the digital token on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform, an identifier of the asset, a version of the asset, and a copy of the file based on the selection; After issuing the digital token on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform, encrypting the copy so that an encrypted file is formed, and identifying the encrypted file by a cryptographic hash value; After issuing the digital token on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform, sending the encrypted file for storage in a memory external to the hardware server and the blockchain-based tokenization platform; identifying the digital token via an identifier of the asset and a version of the asset after the digital token is issued on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform; and After the digital token is issued on the blockchain-based tokenization platform based on the identifier of the blockchain-based tokenization platform, the cryptographic hash value is caused to be written to a new key-value pair within the second set of key-value pairs without: (a) modifying or removing the second subset of the set of asset-specific attributes already recorded in the second set of key-value pairs, and (b) creating a new digital token, so that the encrypted file is linked to the digital token to be retrieved and decrypted from the memory by the hardware server via the cryptographic hash value.

16. The system of claim 14, wherein: The hardware server is further programmed to: receiving, after issuing the digital token on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform, an identifier virtually representing an asset-specific attribute of the digital token from a software application hosted external to a data center containing the hardware server; encrypting the identifier virtually representing the asset-specific attribute of the digital token so as to form an attribute value represented as a cryptographic hash; as well as Causing the cryptographic hash to be written to a new key-value pair within the first set of key-value pairs without modifying or removing the first subset of the set of asset-specific properties already recorded in the first set of key-value pairs, so that the changes in the new key-value pair are re-encoded on the blockchain-based tokenization platform external to the data center and the software application.

17. The system of claim 14, wherein: The digital token is a first digital token, wherein the header component is a first header component, wherein the attribute component is a first attribute component, wherein the immutable component is a first immutable component, and the hardware server is further programmed to: receiving a set of identification data of the first digital token from a software application hosted external to a data center containing the hardware server after issuing the digital token on the blockchain-based tokenization platform based on an identifier of the blockchain-based tokenization platform; encrypting the set of identification data so as to form an attribute value represented as a cryptographic hash; and Causing the cryptographic hash to be added to a second digital token, the second digital token comprising a second header component, a second attribute component comprising a third set of key-value pairs, and a second immutable component, such that the cryptographic hash is written to a new key-value pair within the third set of key-value pairs without modifying or removing those asset-specific attributes already recorded in the third set of key-value pairs, and such that changes in the new key-value pair are re-encoded on the blockchain-based tokenization platform external to the data center and the software application.

18. The system of claim 14, wherein: The first subset of the set of asset-specific attributes and the second subset of the set of asset-specific attributes share at least one asset-specific attribute.

19. The system of claim 14, wherein: The first subset of the set of asset-specific attributes and the second subset of the set of asset-specific attributes do not share any asset-specific attributes.

20. The system of claim 14, wherein: The second subset of the set of asset-specific attributes is a copy of the first subset of the set of asset-specific attributes.

21. The method according to claim 1, wherein: The server is a single server.

22. The method according to claim 1, wherein: The server is a server group.

23. The system of claim 14, wherein: The hardware server is a single server.

24. The system of claim 14, wherein: The hardware server is a server group.

Images