Methods for distributing digital assets registered on a blockchain and autonomous computing agents

By embedding notification addresses within blockchain transactions and using autonomous agents to manage asset ownership and revenue distribution, the method addresses inefficiencies in current blockchain systems, ensuring secure and anonymous asset transfers and revenue distribution directly on the blockchain.

JP7852097B2Active Publication Date: 2026-04-27NCHAIN LICENSING AG
View PDF 3 Cites 0 Cited by

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
NCHAIN LICENSING AG
Filing Date
2025-01-22
Publication Date
2026-04-27

AI Technical Summary

Technical Problem

Current blockchain technologies face inefficiencies in managing and maintaining separate off-chain databases for asset ownership and revenue distribution, leading to synchronization issues and complexity, while also lacking secure and anonymous communication mechanisms for asset transfers.

Method used

A method and system that embeds notification addresses within blockchain transactions, utilizing autonomous computing agents to traverse the blockchain, determine current ownership, and generate electronic communications to unknown or anonymous recipients, ensuring secure and anonymous asset transfers and revenue distribution.

Benefits of technology

Enables secure, anonymous, and efficient asset transfers and revenue distribution directly on the blockchain, eliminating the need for separate databases and enhancing privacy and security in asset management systems.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007852097000011
    Figure 0007852097000011
  • Figure 0007852097000012
    Figure 0007852097000012
  • Figure 0007852097000013
    Figure 0007852097000013
Patent Text Reader

Abstract

To provide a block chain-based method and system.SOLUTION: A method comprises a step of submitting a transaction to a block chain, where the transaction (Tx1) comprises an unspent output (UTXO) that includes a Redeem script that requires provision of a notification address within metadata of an unlocking script in order to spend the unspent output (UTXO). The Redeem script further comprises a value indicating how many notification addresses must be supplied by the unlocking script.SELECTED DRAWING: Figure 1
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention generally relates to distributed ledgers and blockchain technology, and more particularly to the use of blockchain technology for implementing a system for automatic control of processes executed by a computer. One embodiment of the present invention provides a solution for recording and controlling the ownership or control of electronic assets via a blockchain, and for generating and achieving blockchain transactions in response to current ownership data. The present invention also provides a novel and advantageous solution for controlling and enabling the transmission of electronic communications to a recipient. The present invention utilizes blockchain technology to realize the storage of recipient addresses or identifiers, so as to expand privacy and / or security, and enable the recipient to specify and / or change the notification address stored on the blockchain. The present invention is suitable for use with, but not limited to, the Bitcoin blockchain.

Summary of the Invention

[0002] As used herein, the term "blockchain" is used to encompass all forms of electronic, computer-based distributed ledgers, including but not limited to blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known use of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. Bitcoin is mentioned herein for convenience and illustrative purposes, but it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention.

[0003] A blockchain is a consensus-based electronic ledger implemented as a computer-based, decentralized system composed of blocks. Blocks are composed of transactions. Each transaction contains at least one input and at least one output. Each block contains the hash of the previous block, and together the blocks form a chain, generating a permanent, immutable record of all transactions written to the blockchain from its inception. A transaction contains a small program known as a script embedded in its input and output. The script specifies how and by whom the transaction's output is accessible. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] For a transaction to be written to the blockchain, it must be "verified". Network nodes (miners) perform work to ensure that each transaction is valid, and invalid transactions are rejected from the network. Software clients installed on the nodes perform this verification work on unused transactions (UTXOs) by executing their own lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to true, the transaction is valid and is written to the blockchain. Therefore, for a transaction to be written to the blockchain, it must i) be verified by the first node that receives the transaction, and if the transaction is verified, the node relays the transaction to other nodes in the network, ii) be added to a new block built by miners, and iii) be mined, that is, added to the public ledger of past transactions.

[0005] While blockchain technology is most widely known for its use in cryptocurrency implementations, digital entrepreneurs are beginning to explore the use of both Bitcoin's underlying cryptocurrency security system and data that can be stored on the blockchain to implement new systems. Blockchain would be highly advantageous if it could be used for automated tasks and processes not limited to the realm of cryptocurrency. Such solutions would leverage the advantages of blockchain (e.g., permanence, tamper-proof event recording, distributed processes, etc.) while being more diverse in their applications.

[0006] One area of ​​current research is the use of blockchain for the implementation of "smart contracts." These are computer programs designed to automate the execution of machine-readable transactions or agreement conditions. Unlike traditional transactions, which can be written in natural language, smart contracts are machine-executable programs that contain rules that can process inputs to produce an outcome, and can perform actions depending on that outcome.

[0007] Another area of ​​interest related to blockchain is the use of “tokens” (or “colored coins”) for the representation and transfer of real-world entities over the blockchain. Potentially confidential or secret items can be represented by tokens that do not have an identifiable meaning or value. Thus, tokens function as identifiers that allow real-world items to be referenced from the blockchain.

[0008] Data related to smart contracts needs to be registered, tracked, and recorded. For example, data related to the owners of assets managed by smart contracts needs to be recorded. This is especially important for smart contracts relating to assets owned by multiple entities where ownership is divided into shares. In such cases, transfers of ownership need to be recorded in a secure manner. It is also important that related costs are taken against the assets and / or the revenue generated and paid therefrom. Another important consideration is that it is often desirable to protect the identities of the real-world parties involved.

[0009] Typically, holding tokenized assets on a blockchain means that there are UTXOs (unspent transaction outputs) allocated to current asset holders and that determine the scale of those current holdings. These are encapsulated within the Redeem script required to transfer the assets and can typically take the following form:

[0010] XOP_CHECKMULTISIG(Metadata-A Metadata-B PublicK-A)Y However, the information held within the blockchain is not the script itself, but rather the hash of the script. This means that important public key information is not available for public viewing.

[0011] In some cases, revenue distribution is paid through the same tokenized product as the original asset, for example, as dividends when additional shares are issued within the company. In such cases, the non-availability of the public key is not an issue, as revenue distribution can simply be paid to the same Redeem script hash as the original issuance transaction.

[0012] However, in the more common scenario where revenue distribution is paid as alternative assets (e.g., BTC dividends for shares), this flaw in public key information means that, according to the current state of technology, a separate off-chain database of public keys associated with each issuance transaction must be maintained. While such a solution is clearly feasible, it means the existence of two systems (the blockchain and the off-chain database) maintaining the asset register. This introduces complexity to the solution, as the two databases could become out of sync with each other. This also requires an efficient storage configuration.

[0013] Therefore, it is desirable to provide a solution that does at least the following: By enabling the automatic determination of where income should be paid, the requirements of the second database mentioned above, and therefore the risks and inefficient storage requirements it imposes, • The income can be paid in a way that ensures only current asset holders are entitled to claim those funds. • Provides a general mechanism for generating actions and technical responses (for example, in response to revenue generation) in proportion to the current ownership of assets represented and / or referenced via the blockchain. • Blockchain transactions enable the secure automatic transfer of assets and the recording of such transfers and payments on the blockchain, thus providing benefits such as tamper-resistant recording of events and data. • To enable the protection of "real-world" identities, such as those of asset owners, the solution should enable or achieve anonymity. • Provides a solution that enables and controls electronic communications that need to be sent to an "unknown" party.

[0014] Such improved solutions have been devised. The present invention provides at least the technical effects discussed above. The present invention is defined in the appended claims.

[0015] Therefore, according to the present invention, a control method and a corresponding system may be provided.

[0016] The present invention can control the transmission of electronic communications. The present invention may be a method for establishing an electronic communication channel between two or more parties.

[0017] Additionally or alternatively, the present invention may be configured to enable and / or achieve completion of incomplete blockchain transactions. Accordingly, the present invention may be described as a method for controlling or influencing the validity and / or propagation of blockchain transactions on a blockchain network.

[0018] Therefore, the terms "communication," "notification," and "warning" can be used synonymously.

[0019] The present invention may provide a method for controlling and / or generating electronic communications. Additionally or alternatively, the present invention may provide a solution for determining the destination of electronic communications / transmissions. This solution may be implemented by a blockchain. The present invention may be a method / system configured to enable (electronic, off-blockchain) communication with an anonymous or quasi-anonymous recipient. This recipient may be, for example, an asset owner or controller, but the present invention is not limited thereto. The communication may be transmitted using information stored or "embedded" within a sequence of blockchain transactions. The present invention may be described as a method for specifying and / or determining the destination of electronic communications via a blockchain.

[0020] The method may include the step of sending a signal to an address. The address may be a notice address. The signal may be called or perform the function of (electronic) notice or communication.

[0021] The present invention is not limited with respect to the context, purpose, or content of the notice.

[0022] The notification may be provided as metadata within an unlock script associated with the input of a transaction (Tx1) on the blockchain. The term “identifier” may be used synonymously with “address.” This sending step may be triggered by an event. The event may be specified, determined, or influenced by a smart contract. The sending (dispatch) of the notification may be performed by a computer-based resource. This may be performed as at least part of an automated process.

[0023] The notification may function as a request and / or trigger for the completion of an incomplete transaction. The method may include steps to complete the incomplete transaction. Completion may include providing a cryptographic signature (provision).

[0024] The unlock script may be provided to use the output from a further transaction (Tx2) on the blockchain. (This means that the input of transaction Tx1 may use the output of transaction Tx2, and may be a "preceding" transaction on the blockchain.) Therefore, the present invention may include a step of requesting the provision of a notification address within the unlock script in order to unlock the lock script. This step may be repeated. Thus, a sequence of notification addresses may be requested and provided. The notification addresses may be requested to use each output in the chain of blockchain transactions. This allows for the provision of different addresses over time. Thus, the present invention enables and realizes the modification of the recipient address for notification.

[0025] The input of transaction (Tx1) and / or the output of a further transaction (Tx2) may be associated with a tokenized asset represented on the blockchain or referenced via the blockchain. This token may be referred to as a "colored coin".

[0026] The electronic notification may include an incomplete or completed blockchain transaction and / or information related to an incomplete or completed blockchain transaction.

[0027] This may be incomplete in that a required piece of data is missing.

[0028] This may include information regarding the location of the completed / incomplete transaction and / or how to access it.

[0029] The notification address may be associated with an asset or resource represented on the blockchain or a controller of an asset or resource represented on the blockchain. The controller may be the same or a different entity from the actual ("real-world") owner of the asset.

[0030] The method may further include the step of traversing the blockchain to identify transaction Tx1 or a further transaction Tx2. One skilled in the art can understand how this traversal can be performed as known art.

[0031] The method may include the step of submitting a transaction to the blockchain, wherein the transaction (Tx1) includes an unspent output (UTXO) that includes a Redeem script that requires the provision of a notification address within the metadata of the unlock script for use of the output (UTXO).

[0032] Unused Outputs (UTXOs) may transfer ownership of tokenized assets represented on or referenced through the blockchain, or otherwise be related thereto.

[0033] The notification address may be provided as a parameter in the unlock script for transaction (Tx1). This may be provided as a second parameter.

[0034] The method may include a step that uses a Redeem script to ensure that notification addresses are provided within the unlock script. The Redeem script may include a value indicating how many notification addresses must be provided by the unlock script.

[0035] Multiple notification addresses may be provided within the unlock script.

[0036] The notification address may be a network address, an encryption key, a URI (uniform resource locator), an email address, or any other address or identifier that is represented in the script's metadata and can be used as a destination for electronic communications. Therefore, the notification address may function as an identifier for the recipient of the notification / communication.

[0037] At least one step of the method may be performed by an automated computing resource or agent, which may be called a “bot” or “oracle.”

[0038] The method and / or system may be substantially as described below in the chapter titled “Notification Addresses Embedded in the Blockchain.”

[0039] The present invention may further provide a system implemented by a computer arranged and configured to perform steps of any embodiment of the method described herein.

[0040] The system is Blockchain and At least one autonomous computing agent, Traversing the blockchain and / or, To generate and / or transmit electronic notices, It may include at least one autonomous computing agent configured in such a way.

[0041] Any feature described in relation to a method may also be applicable to a system, and vice versa.

[0042] The present invention may be substantially as described in the embodiments for the description set forth in the following examples, descriptions, and drawings. The above-mentioned and other aspects of the present invention are evident from the embodiments described in this specification and are taught with reference to those embodiments.

[0043] Embodiments of the present invention are described below with reference to the accompanying drawings, merely as examples. [Brief explanation of the drawing]

[0044] [Figure 1] This document provides an overview of embodiments for explaining the present invention. [Figure 2] This provides an explanation of the traverse logic used when iterating on the blockchain to determine the current ownership of an asset. [Figure 3] This document provides a description of the transaction outputs required according to one embodiment of the present invention. [Figure 4] This provides an explanation of how to build initial, incomplete blockchain transactions. [Figure 5] Figure 4 provides an explanation of the incomplete transaction after it has been modified and completed by the asset controller. [Figure 6] This document provides an embodiment of a system in which a notification is sent to an asset controller to inform the asset controller that there are incomplete transactions that require attention and modification. [Figure 7] This document describes an example model using one embodiment of the present invention. [Figure 8] This provides blockchain transaction number 100.10, related to the example provided below, which can be used to generate shares among assets represented on the blockchain. [Figure 9] We provide blockchain transaction number 100.120, related to the example provided below, which can be used to issue a share of an asset to a recipient. Note that the notification address is specified as a requirement within ScriptSig. This requires the recipient (i.e., the asset owner or controller) to provide the notification address as metadata within the unlock script when "claiming" the share via an input in a later transaction. [Figure 10] We provide blockchain transaction number 150.10, which can be used to transfer ownership of a portion of an asset to a recipient. In this case, the current asset controller retains a portion of the asset and allocates or transfers the other portion to another party. [Figure 11] The following provides the incomplete blockchain transaction number 400.1 that may be generated in relation to the example provided below. [Figure 12] When modified by the asset controller, it provides blockchain transaction number 400.10, which is the completed version of the incomplete transaction shown in Figure 11. [Modes for carrying out the invention]

[0045] The present invention provides a general-purpose solution that enables control over the secure transfer of digital entities through blockchain transaction inputs and outputs. In the examples provided in this specification, the present invention is discussed for illustrative purposes in the context of paying revenue or accrued costs on an asset registered on the blockchain, in accordance with the terms of an underlying investment agreement, for example, in direct proportion to how ownership of the asset is divided. For example, if an asset is divided into 100 shares, the revenue to be paid may be calculated per share.

[0046] However, it is important to note that the present invention is not limited to such use case scenarios, but rather provides more general transport control and notification solutions that can be used to benefit various applications and situations.

[0047] <Main Terms> This technical specification uses the following terms throughout to define the main concepts and components. [Table 1]

[0048] As described herein, the present invention provides an automated, secure, and robust mechanism that enables at least the following: The ability to determine the current ownership of an asset from a blockchain (such as the Bitcoin blockchain). • The ability to control the transmission of electronic communications to unknown parties associated with the asset. The ability to pay income generated by an asset in proportion to the current ownership of that asset.

[0049] In the latter two cases, this process can be used to benefit situations where assets maintain a separate ownership database, or where ownership is hidden by the blockchain through the use of (payment) addresses.

[0050] The present invention offers at least two advantageous aspects. 1) The ability to make payments to asset owners via blockchain when the owner of the asset is unknown and anonymous. 2) The ability to notify anonymous owners using information stored within a sequence of blockchain transactions. This feature is the focus of this application.

[0051] <Determination of current ownership of assets represented on the blockchain> In order to allocate costs / revenue to assets represented on the blockchain, it is necessary to be able to determine the current ownership of those assets. There are two mechanisms that can achieve this. • Ownership may be maintained in a separate register, which is maintained off-chain by the asset (and updated by having the asset countersign the transfer). This mechanism is ideal for regulated assets to which formal "Know Your Customer" rules apply. Ownership can be determined by scanning transactions on the blockchain to dynamically generate a current ownership list. It should be noted that this approach does not determine ownership itself, but identifies the Bitcoin address responsible for the asset. This may be referred to as the “asset controller,” which may or may not be the actual owner. This blockchain traversal technique is used in this invention.

[0052] <Generating actions related to ownership, such as calculating and paying income> In order to pay income from assets in proportion to the current ownership of the assets, The asset must have the ability to determine current ownership. • The asset must be able to record total income over a given period. • The asset must be such that income can be divided among the current owners. Assets must be able to offset costs from revenue. • The asset must be able to retain revenue if previous costs have not been paid. • The asset must be capable of triggering income payments to the current asset holder.

[0053] This income may occur at the end of a time period (e.g., every six months) or when it is generated (e.g., immediately). Depending on the characteristics of the contract, the same conditions may allow for proportional payments of income under several contracts, or merely allow for payments to the current holder over a certain period.

[0054] <Technical Solutions> The technical solution provided by the present invention provides a mechanism that allows an investment or asset controller to generate a set of payment transactions for both cost recovery or revenue payment via an agent or smart contract. The solution relies on automated oracle processing (or multiple oracle processing depending on the structure of the underlying contract) triggered by off-chain conditions. For example, this condition may be the date on which the reward is to be paid. When this trigger condition is activated, the oracle will: • Calculate the total payment amount for all assets, Based on payment rules (e.g., proportional), calculate individual payments across the current ownership divisions of the asset. • Generate a payment transaction for each individual asset holder.

[0055] Figure 1 shows the basic flow of how the individual payments that a technological solution should generate are determined.

[0056] The steps in the flowchart in Figure 1 will be defined in more detail in the following chapters. [Table 2]

[0057] <Traversing the blockchain from issuance transactions> To determine the current location (ownership) of a share within an asset, the relevant oracle needs to be able to traverse the blockchain from the initial issuance transaction to determine where the current share of the asset currently resides. The issuance transaction is referred to as the “anchor transaction” in Figure 1. Figure 2 shows an exemplary transaction chain that may be used during such traversal. Essentially, this process involves moving from transaction to transaction on the blockchain, following the trace, until the oracle finds the UTXO associated with the asset. When this output is not being used, this indicates that the asset controller using the last input in the asset should still be the controller. Therefore, the traversal process may stop at this transaction.

[0058] Each individual issue or transfer transaction output has an associated Redeem script. The fact that a transaction output is unused allows the oracle to determine which Redeem script was used to utilize the output from the previous transaction, and therefore which percentage of the asset it "owns" at any given time.

[0059] <Generate distribution payments> By understanding the Redeem script, the revenue distribution transaction can utilize the SIGHASH_NONE capability to redirect its output only in a way that the Redeem script's controller can modify. For this purpose, the distribution transaction needs to be constructed as shown in Figure 3.

[0060] A distribution transaction has two outputs. 1) The output to be sent back (reissued) to the current controller so that the same controller is determined to be the current controller when the traverse process is performed next. 2) An output that transfers several electronic funds to the controller.

[0061] The reissue output can be constructed because it can simply regenerate (i.e., copy) the Redeem script hash from the previous issue / transfer transaction.

[0062] However, based on the number of signatures required, and because a lock script for revenue payment to A cannot be constructed at the time of construction, it is impossible to construct a distribution transaction in one step.

[0063] To resolve this, the distribution transaction is initially constructed and broadcast in the format shown in Figure 4.

[0064] By setting the signature hash as the input to SIGHASH_NONE, one of the outputs can be modified. However, by locking it in the last issuing transaction, only the legitimate owner of the asset can make the modification, as they are required to sign the input (and obviously not unless they are interested). It should be noted that a signature does not need to be supplied in the last asset issuance / transfer to the transaction. Assuming the asset issuer is a co-signer of any transfer transaction, as shown in Figure 4, if they are not present, this transaction is simply joined with a signature to the revenue for distribution to achieve the same effect.

[0065] <Redirect distribution payments> When the current asset owner receives an incomplete template transaction, they decide it is of most interest to them and complete the transaction by signing the final asset issue / transfer input to the transaction after modifying the revenue payment transaction to pay the revenue to themselves. This modified completed transaction is shown in Figure 5. The transaction is now complete and therefore mineable.

[0066] Therefore, the outcome is achieved without the requirement of knowing about the fundamental owner of the asset, other than the ownership share of the asset contained in the blockchain record itself.

[0067] <Notification required> As described above, payment distribution transactions are initially generated in an incomplete form. This then needs to be communicated to an asset controller in some way so that the asset controller becomes aware of the transaction, makes the necessary changes to complete it, and submits it to the blockchain.

[0068] However, incomplete transactions cannot be broadcast through the blockchain itself. This is because, by default, blockchain propagation nodes do not propagate incomplete transactions across the network. Since the original version of the distribution transaction is incomplete (lacking signatures), the controller / owner has no prospect of receiving the incomplete transaction and applying signatures before it is dropped by the network. This does not affect asset ownership, but it means that the relevant parties will not be paid the revenue they are entitled to.

[0069] To resolve this, there needs to be a channel available to broadcast this incomplete transaction to interested parties (or at least make interested parties aware of the existence and / or location of the incomplete transaction).

[0070] To solve this, there are various possible methods, including the following: A contract may expose a “broadcast” channel as part of the contract. In this broadcast channel, all incomplete transactions are broadcast by asset owners who listen to and respond to the channel to determine which transactions are of interest. This exposure / subscribe mechanism is a standard IT feature. • Upon sale or other transfer of the asset, the new asset owner / controller locks the notification address to the sale transaction. This allows the communication channel to be established without any other information about the asset owner / controller being known. The asset then uses this private channel to send the incomplete transaction to the current owner, or to notify them that the transaction is available from a location where it can be accessed, for example, for download and subsequent completion.

[0071] None of these solutions affect or impact the first aspect of the present invention described above, in that the asset still does not recognize ownership of the asset itself beyond the information held on the blockchain itself. In the following example, the transaction utilizes a second option for transaction notification. This notification technique forms a second novel aspect of the present invention and provides privacy or anonymity of transaction information.

[0072] <Notification address embedded in the blockchain> This novel and advantageous aspect of the present invention provides a solution to the propagation problem identified above by enabling the ability to embed a notification address within a blockchain transaction. The notification address is therefore available for subsequent notifications.

[0073] The notification can take any suitable form, such as email. In such a case, the email may be sent to an email address embedded in the previous transaction. However, other conventionally known forms of electronic communication are also included within the scope of this invention. Essentially, the identifier captured in the initial transaction functions as the address or location to which the notification is sent.

[0074] This chapter explains how this model works and is the focus of this application. It should be noted that this notified technique can be used, on its own and in a wide range of situations and applications, independently of the first aspect of the invention described above, to be beneficial as a solution to a problem.

[0075] This solution means that communications can be sent to recipients without any further information being provided or known. The present invention therefore provides enhanced alert, notification, or communication technology that protects or enhances privacy and security. No additional information about the recipient is required other than the address provided within and subsequently extracted from the transaction script. This itself can be facilitated by automated processes such as bots.

[0076] The sending of notifications to a specified address may be triggered by an event. The event may be specified within or influenced by a smart contract.

[0077] The notification may simply be a signal sent to an address and / or may contain predetermined content. Thus, any desired informational message can be sent. Additionally or alternatively, the receipt of the notification may serve as a signal to an automated process, thus triggering a predetermined or programmed response, for example, supplying a signature to a transaction or performing some other action.

[0078] The present invention is not limited to the content of notification messages sent to embedded addresses. In some cases, the notification may include a copy of an incomplete transaction. In the examples of the present invention, however, the role of the notification address is to ensure that, when the author of a given target transaction does not have other information about the relevant interested party (which may be a human or a computer-based resource), the relevant interested party (which may be a human or a computer-based resource) is notified or warned that it is necessary to apply their signature to the target transaction (and make other changes). In practice, the present invention thus enables the execution and completion of future blockchain transactions. By providing the necessary signature, a partially invalid transaction is transformed into an executable and valid transaction that is acceptable to the blockchain. Thus, the present invention solves the problem of how to control, realize, and / or enable the validity of blockchain transactions and their propagation on the blockchain network.

[0079] To achieve this, a "seed" transaction needs to be generated that forces the capture of the notification address in all subsequent transactions. This can typically occur before the issuance transaction (in a standard tokenization transaction). This issuance or "source" transaction requests additional attributes that should be supplied on the unlock script, including the notification address. The complete flow of this process is shown in Figure 6.

[0080] <Notification Redeem Script> The main formats for unlock scripts are as follows:

number

[0081] As can be seen from the structure above, the elements shown within the frame represent standard scripts, but with a new prefix. This prefix takes the form shown here.

number

[0082] In this specific example, <Count of notification addresses> can range from 1 to 4, but the structure can be extended to support different maximum values if necessary. This script prefix effectively drops the relevant notification addresses from the stack and then checks to ensure that the number of notification addresses matches the number that should be present.

[0083] <Usage example model> The model provided in FIG. 7 shows the main usage examples included in the scope of the non-recourse lending model.

[0084] <

[0100] Issuance of shares> The asset guarantees that it issues shares to the appropriate asset holders within itself and captures the notification address of that entity during the issuance. Here, the primary entity is the asset.

[0085] <Main successful scenarios> This step is only necessary if the details of the current holder's notification are retained in the blockchain itself.

Table 3

[0086] The share generation transaction is shown as transaction 100.10 in FIG. 8.

[0087] The complete Redeem script for output 1 of transaction 100.10 is shown below.

[0088] OP_DROP OP_CHECKSIG The share issuance transaction is shown as transaction 100.20 in FIG. 9.

[0089] The complete Redeem script for output 1 of transaction 100.20 is shown below.

number

[0090] This exemplary Redeem script allows subsequent sales to transfer ownership to up to four buyers. If a purchase involves more than four buyers, multiple transactions may be required. It should be noted that, obviously, it is possible to expand (or limit) the number of possible new purchases by repeating (or reducing) the "if" block in the script above.

[0091] <

[0150] Selling Shares> The asset holder needs to sell a portion of their ownership stake to another interested party. In this case, the primary entity is the asset holder.

[0092] Main success scenarios: [Table 4]

[0093] This generates many key features that are essential to support the underlying income distribution. • Sales are limited to a maximum of four new holders (for example, four output transactions, but any number from one to four). • If the sale includes a partial hold on shares, only the slots will be reclaimed by the current holder for reallocation, so only three new holders can be supported.

[0094] <Transaction 150.10> In the example transaction 150.10 provided in Figure 10, the transaction performs a partial sale by the current asset holder, who holds one stake and sells one other stake to a new holder. It should be noted that in a real-world scenario, additional inputs may be required to cover mining costs. This is ignored in the template in Figure 10, improving the readability of transaction 150.10.

[0095] The Redeem script for the output of transaction 150.10 (Figure 10) is the same as that for transaction 100.20 (Figure 9), except that the public key is as follows.

[0096] <pubk-secondaryassetholder>and <pubk-asset> This Redeem script for output 2 of transaction 150.10 (Figure 10) is identical to that of transaction 100.20 (Figure 9).

[0097] <

[0200] Determination of Ownership> Even if the asset does not recognize the current asset holders, it needs to decide how to allocate the income from payments to the current asset holders. The primary entity in this action is the asset.

[0098] Main success scenarios: [Table 5]

[0099] <

[0300] Calculate payment> Here, the asset wants to calculate the amount of income that should be paid to its current owner. The primary entity in this action is the asset.

[0100] Main success scenarios: [Table 6]

[0101] <

[0400] Payment of Income> Here, the assets want to pay income to their owners in proportion to their ownership. The primary entity is the asset.

[0102] Main success scenarios: [Table 7]

[0103] Transaction 400.10 - Provisional (incomplete) transaction is shown in Figure 11. Transaction 400.10 - Final (completed) transaction is shown in Figure 12. In Figure 12, changes are shown in bold for clarity.

[0104] <Example Scenario: Asset-Based Equity Capital> The primary type of scenario supported by this model is traditional equity capital for a company-like asset. The company (NewCo plc) issues a fixed quantity of freely tradable shares (1000) from which revenue is paid periodically (annually). When revenue distribution represents the company's profits, there are no requirements to support the collection of costs from the asset holder base (profits have already offset costs from them).

[0105] <The main advantages of this invention include the following> This invention enables autonomous activity on the blockchain and allows for the creation of entities capable of paying revenue / costs without the need to maintain a separate off-chain ownership database (except for legal reasons).

[0106] The present invention makes it possible to embed a notification address or identifier within a transaction, specifically within the transaction script.

[0107] Therefore, the present invention provides enhanced privacy, security, and communication. This is particularly advantageous in applications relating to the control and recording of asset and / or fund transfers via blockchain.

[0108] It should be noted that the embodiments described above are not limiting to the present invention, and those skilled in the art can devise numerous alternative embodiments without departing from the scope of the invention as defined by the appended claims. No reference numerals enclosed in parentheses in the claims should be considered limiting to the claims. The terms “comprising” or “comprises,” etc., do not, as a whole, exclude the existence of elements or steps other than those enumerated in any claim and specification. In this specification, “comprises” means “includes” or “consists of,” and “comprising” means “including” or “including of.” A singular reference to an element does not exclude the existence of multiple elements of that element, and vice versa. The present invention may be carried out by hardware having multiple distinct elements or by a appropriately programmed computer. In claims for an apparatus that enumerates multiple means, these multiple means may be implemented by a single identical hardware element. The fact that certain quantities are described in different dependent claims does not mean that combinations of these quantities cannot be used advantageously.

[0109] Further embodiments are disclosed below. (Example A1) An electronic communication or notification method, wherein the method is The step of sending an electronic notification to a notification address provided as metadata in the unlock script of the input for the transaction (Tx1) on the blockchain, A method that includes this. (Example A2) The method according to Embodiment A1, wherein the unlock script is configured and / or provided to use the output from a further transaction (Tx2) on the blockchain. (Example A3) The method according to Embodiment A1 or A2, wherein the input of the transaction (Tx1) and / or the output of the further transaction (Tx2) are associated with a tokenized asset represented on or referenced via the blockchain. (Example A4) The aforementioned electronic notification is, Incomplete or completed blockchain transactions, and / or Information relating to the location of incomplete blockchain transactions, or means of accessing them, and / or Information related to incomplete or completed blockchain transactions, The method according to any one of Examples A1 to 3, including the method described in Example A1 to 3. (Example A5) The method according to any one of Embodiments A1 to 4, wherein the notification address is associated with an asset or resource represented on the blockchain, or a controller of an asset or resource represented on the blockchain. (Example A6) The method according to any one of Embodiments A1 to 5, further comprising the step of traversing the blockchain to identify the transaction (Tx1) or a further transaction (Tx2). (Example A7) A step of submitting a transaction to the blockchain, the transaction (Tx1) further includes an output (UTXO) which includes a Redeem script that requests the provision of a notification address in the metadata of an unlock script in order to use the unused output (UTXO), Preferably, the method according to any one of Embodiments A1 to 6, wherein the unused output (UTXO) transfers ownership or control of or related to the tokenized asset represented on or referenced therein on the blockchain. (Example A8) The notification address is provided as a parameter in the unlock script of the transaction (Tx1) according to the method of any one of Embodiments A1 to 7. (Example A9) A step of using a Redeem script to ensure that the notification address is provided within the unlock script, The method according to any one of Examples A1 to 8, further comprising the above. (Example A10) The method according to Embodiment A9, wherein the Redeem script includes a value indicating how many notification addresses must be provided by the unlock script. (Example A11) Multiple notification addresses are provided within the unlock script, as described in any one of Examples A1 to 10. (Example A12) The method according to any one of Examples A1 to A11, wherein the notification address is a network address, an encryption key, a URI (uniform resource locator), an email address, or any other address or identifier that is represented in the metadata of a script and can be used as a destination for electronic communications. (Example A13) The method according to any one of Examples A1 to A2, wherein at least one step described in any one of Examples A1 to A2 is performed by an automated computing resource or agent. (Example A14) Steps include detecting a specified or predetermined event, The steps include sending the electronic notification in response to the detection of the event, The method according to any one of Examples A1 to 13, including the method described above. (Example A15) A system implemented by a computer arranged and configured to perform the steps described in any one of Examples A1 to A14. (Example A16) The aforementioned system, Blockchain and At least one autonomous computing agent, Traversing the aforementioned blockchain and / or, The electronic notification described above is generated and / or transmitted. A system comprising at least one autonomous computing agent configured in such a way, The system described in Example A15, including the above. (Example B1) A method carried out by an autonomous computing agent, wherein the method is A step of traversing the blockchain to identify a transaction, wherein a notification address is provided as metadata in the unlock script of the transaction, The steps include sending an electronic notification to the aforementioned notification address off-blockchain, A method that includes this. (Example B2) Starting from the aforementioned transaction, the steps include traversing the transaction history on the blockchain to determine the current unused output (UTXO), Based on the aforementioned UTXO, the steps include determining the ownership ratio among multiple ownerships related to the digital asset, For each UTXO, The steps include generating an incomplete transaction based on the aforementioned ownership ratio, The steps include sending the aforementioned incomplete transaction off-blockchain, The method according to Example B1, further comprising the above. (Example B3) Starting from the aforementioned transaction, traversing the transaction history on the blockchain is: The method according to Embodiment B2, comprising traversing until the current set of blocks, the notification address for the output of the current set of blocks, and the Redeem script are determined. (Example B4) Based on the aforementioned UTXO, the step of determining the ownership ratio among multiple ownerships related to the digital asset is: The method according to Example B2 or 3, wherein the ownership ratio is determined based on which Redeem script was used to use the output of the previous transaction. (Example B5) The signature hash of the input for the incomplete transaction is set to SIGHASH_NONE, as described in any one of Examples B2 to B4. (Example B6) The step of sending the aforementioned incomplete transaction off-blockchain is: The method according to any one of Embodiments B2 to B5, comprising sending the incomplete transaction to the notification address embedded in the transaction. (Example B7) The method according to any one of Examples B2 to B6, wherein the step of sending an electronic notification to the notification address off-blockchain is triggered by an off-chain condition, the off-chain condition being the date on which the distribution of the digital assets is paid. (Example B8) The method according to Embodiment B1, wherein the notification address is associated with an asset or resource presented on the blockchain, or with the controller of an asset or resource presented on the blockchain. (Example B9) Steps include detecting a specified or predetermined event, The steps include sending the electronic notification to the notification address off-blockchain in response to the detection of the event, The method according to Example B1, further comprising the above. (Example B10) The method according to Embodiment B1, wherein the notification address is a network address, a URI (uniform resource locator), an email address, or any other address or identifier presented in the metadata of the script that can be used as an off-blockchain destination for electronic communication. (Example B11) An autonomous computing agent configured to perform the method described in any one of Examples B1 to B10. (Example B12) A computer including the autonomous computing agent described in Example B11.

Claims

1. A computer implementation method performed by an automated computing resource or agent, wherein the method is: The steps include: incorporating the notification address into the metadata within the unlock script for the transaction input, The steps include submitting the aforementioned transaction to the blockchain, Methods that include...

2. The unlock script is configured and / or provided to use the output from a preceding transaction on the blockchain. The method according to claim 1.

3. A step of traversing the blockchain to identify the transaction or the preceding transaction, It further includes, The step of traversing the blockchain includes traversing the transaction history on the blockchain until the current issuing block, notification address, and Redeem script are determined for the unused output of the preceding transaction. The method according to claim 2.

4. The step of submitting the preceding transaction to the blockchain, The step further includes, the preceding transaction includes unused output, the unused output includes a hash of a Redeem script which requests the provision of a notification address in the metadata of the unlock script in order to use the unused output, The method according to claim 2 or 3.

5. The input of the transaction is associated with a tokenized asset that is represented on or referenced via the blockchain. The method according to any one of claims 1 to 4.

6. Multiple notification addresses are provided within the unlock script. The method according to any one of claims 1 to 5.

7. A step of sending an electronic notification to the notification address in the metadata of the unlock script, The method according to any one of claims 1 to 6, further comprising:

8. The aforementioned electronic notification is, Incomplete or completed blockchain transactions, and / or Information relating to the location of incomplete blockchain transactions, or means of accessing them, and / or Information related to incomplete or completed blockchain transactions, The method according to claim 7, including the method described in claim 7.

9. The notification address is associated with an asset or resource represented on the blockchain, or with the controller of an asset or resource represented on the blockchain. The method according to claim 7 or 8.

10. The notification address is a network address, encryption key, URI (uniform resource locator), email address, or any other address or identifier represented in the metadata of the script and usable as a destination for electronic communications. The method according to any one of claims 7 to 9.

11. Steps include detecting a specified or predetermined event, The steps include sending the electronic notification in response to the detection of the event, The method according to any one of claims 7 to 10, further comprising:

12. A computer-implemented system arranged and configured to perform the steps described in any one of claims 1 to 11.

13. The aforementioned system, Blockchain and At least one autonomous computing agent, Traversing the aforementioned blockchain and / or, To generate and / or transmit electronic notices, A system comprising at least one autonomous computing agent arranged and configured in such a manner, The system according to claim 12, including the following:

Citation Information

Patent Citations

  • System and method for overseas remittance

    JP2002197278A

  • Remittance control system, remittance control method, and program

    JP2016018393A

  • Digital asset intermediary electronic settlement platform

    US20160292680A1