Transpositive network for converting variable-volume fixed-value units to fixed-volume variable-value units and vice versa

Abstract

To enable use of variable-volume fixed-value units as fixed-volume variable-value units, and vice versa, through a multi-step transpositive network operating according to specific transpositive network principles.SOLUTION: In a general aspect, a transpositive network is configured for converting variable-volume fixed-value units to fixed-volume variable-value units and vice versa. In some aspects, a computer system includes means of transposing between a variable-volume fixed-value (VVFV) item comprising VVFV units and a fixed-volume variable-value (FVVV) item comprising FVVV units. The means of transposition implements one or more transpositive network rules.SELECTED DRAWING: Figure 9

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Provisional Application No. 63 / 258,323, entitled “Private Currency Paired With Interest-Inpooled Units Further Paired With External Stores Of Value,” filed April 21, 2021. The above priority application is incorporated herein by reference.

[0002] (Technical field) The following description relates to enabling variable amount fixed value units to be used as fixed amount variable value units, and vice versa, through a multi-stage transposition network that operates according to certain transposition network principles. [Background technology]

[0003] In various situations, the properties characteristic of certain elements present in a network limit or prevent desired functionality. In such cases, a method or system that transposes an element of certain properties and functionality to another element of varying properties and functionality while maintaining the continuity and variation of values ​​between the two disparate elements provides valuable flexibility and opportunities to benefit from the properties and functionality of both elements in the same network. The present disclosure enables such a goal. [Brief description of the drawings]

[0004] [Figure 1] FIG. 1 is a block diagram illustrating a transposition network computing system. [Diagram 2] FIG. 1 illustrates a transposed node network. [Diagram 3] FIG. 1 illustrates a transposed node network and a company. [Figure 4] FIG. 2 illustrates the actionable elements of a transaction instance. [Diagram 5]FIG. 13 illustrates possible elements of an Interest In Pooled Unit Entry. [Figure 6] FIG. 13 illustrates possible elements of a pairing record. [Figure 7] 1 is a flowchart illustrating an example process for the creation of transaction instances, interest in pooled units, and pairing records. [Figure 8] 13 is a flowchart illustrating an example process for determining values ​​of transaction instances and interest in pooled units, as well as the amount of interest in pooled units and FVV to be transferred. [Figure 9] 13 is a flowchart showing properties and pairing of transposed items. [Figure 10] 1 is a flowchart illustrating an exemplary process for the transfer of transaction instances and interest in pooled units. [Figure 11] 1 is a flowchart illustrating an example process for subdivision of transaction instances and interest-in pooled units. [Figure 12] 1 is a flowchart illustrating an example process for disaggregation of transaction instances and interest-in pooled units. [Figure 13] 1 is a flowchart illustrating an example process for paying TI microtransaction fees (MTFs). [Figure 14] 1 is a flowchart illustrating an example process for pooling transaction instances for MTF calculation. [Figure 15] FIG. 1 illustrates Network Participation Rewards (NPR). [Figure 16] FIG. 13 illustrates a dividend payment for a transaction instance. [Figure 17] FIG. 13 illustrates pooling of transaction instances for dividend payments. [Figure 18]FIG. 1 illustrates the retirement of transaction instances and interest-in pooled units. [Figure 19] FIG. 1 illustrates partial appreciation participation. [Figure 20] FIG. 2 illustrates the functionality of paired transaction instances and interest-in pooled units. [Figure 21] A diagram showing the correspondence and usage of VVFV units and transaction instances. [Figure 22] FIG. 13 illustrates multiple pairings between interest in pooled units, transaction instances, VVFV and external currencies. [Figure 23] FIG. 13 illustrates display options. [Figure 24] 13 shows a transport request from VVFV to an interest-in-pooled unit, FVVV. [Diagram 25] FIG. 13 illustrates the transfer of interest-in-pooled units. [Figure 26] FIG. 13 is a diagram showing the subdivision of interest-in-pooled units. [Figure 27] FIG. 13 illustrates non-fragmentation of interest-in-pooled units. [Figure 28] FIG. 1 illustrates the retirement of interest-in-pooled units. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0005] While there are many network ecosystems to which the present disclosure may be applied, in some implementations, the systems and techniques described herein may enable entities with the ability to monetize corporate securities into tradable currency, which other current ecosystems of stablecoins and tokenized securities do not allow for.

[0006] Stablecoins, fiat currencies and other units of exchange are essentially variable quantity fixed value units, whereas corporate securities and other stores of value such as Bitcoin, other cryptocurrencies and commodities are essentially fixed quantity variable value units, and these two categories cannot be used interchangeably due to their appropriate properties. Application of a series of transposition network principles through the pairing and pooling of sequentially variable literal and value equivalents can, by way of example, remove interference that would prevent full circuitry of currencies and corporate securities.

[0007] In all examples and embodiments described in this disclosure: all steps in the figures can occur in various orders, not all steps are illustrated, and not all steps illustrated are necessarily required; when a client node is referred to as having a particular role, given that the client node has the lowest functionality of all nodes, such role and functionality can be assumed by other nodes in the system (e.g., a merchant node, a company node, or a transpose node); none of these techniques described herein are exclusive, and each can be combined with one or more other techniques depending on the desired configuration; steps described with respect to a financial instrument or store of value can be accomplished with either a particular asset or a derivative instrument representing such an asset (provided that such derivative instrument is legally binding and valid). For example, any instantiation of a pairing of values ​​in a pool of FVVV can be achieved using actual FVVV or through derivatives or other financial instruments to provide approximately the same performance; at every step of execution of the software of the modules stored in the node storage, such execution includes loading such software and related data into appropriate memory to enable the desired operations to be performed by the node processor; in such an embodiment, the separate elements of the TI and IPU can be combined into a single unit of integrated currency, where the functionality of the TI and IPU are integrated into one instantiation of the currency in the network. In such cases, any reference to the TI or IPU shall be construed as a reference to such integrated currency; where reference is made herein to a transposition node network or network, such reference may instead refer to a distributed ledger technology (DLT) implementation of the network in which one or more nodes, possibly transposition nodes, function on a deterministic basis to verify, record and search transactions recorded on a private, semi-public or public blockchain.

[0008] 1 is a diagram illustrating a transposition network computing system 100. The transposition network computing system 100 includes one or more software modules 101 residing in storage, loaded into memory, or on a processor, one or more processors 102, various types of memory 103, one or more types of storage 104, and one or more display devices 105, one or more input devices 106, one or more output devices 107, all of which may be linked together by a communications interface 108, and the input and output devices may be linked to a communications network 109. In some implementations, the transposition network computing system 100 is implemented to perform operations in, or otherwise perform, the example processes 900, 1000, 1100, 1200, 1300, 1400, 1500, 1600, 1700, 1800, 1900, 2000, 2100, 2200, 2400, 2500, 2600, 2700, 2800 of Figures 9-22 and 24-28.

[0009] All software of the module 101 including instructions resides in the cache of the processor 102 , memory 103 or storage 104 , and data is presented on the display 105 and stored in the storage 104 .

[0010] The processor 102 of the transposed network computing system may be one or more processors or integrated circuits with specialized functions integrated with various levels of cache. The communication interface 108 may include I / O interfaces, communication interfaces and buses. The memory 103 may include various forms of memory such as flash, RAM, DRAM, or a combination of memory types. The storage 104 may include solid state drives, hard drives, USB drives, SD cards, DVDs, or various other optical, magnetic or other media.

[0011] The transposition network computing system may function as a transposition or transformation node, a company node, a client node, a merchant node or a third party node, or any combination or variation of the above.

[0012] As described herein, all steps of receiving data occur through input device 106, and all steps of transmitting data occur through output device 107. All communications among the components of transposed network computing system 100 occur through communications interface 108.

[0013] 2 illustrates a transpose node network 200. The transpose node network 200 can be comprised of a transpose node or federated transpose node 201, a company node 202, a client node 203, a merchant node 205, and a third party node 206 coupled together by a communication network 204. In some implementations, the transpose node network 200 is implemented to perform operations in the example processes 900, 1000, 1100, 1200, 1300, 1400, 1500, 1600, 1700, 1800, 1900, 2000, 2100, 2200, 2400, 2500, 2600, 2700, 2800 of FIGS. 9-22 and 24-28, or in another manner.

[0014] In various embodiments, the disclosed technology includes at least one transpose node, one or more client nodes, optionally a company node, and optionally one or more merchant nodes, which may variously communicate and transact with each other, i.e., client node to client node, client node to merchant node, client node to transpose node, merchant node to transpose node, and external third party nodes. The client nodes, merchant nodes, client nodes, and transpose nodes may belong to one or more classes that are differentiated by differences in liabilities, responsibilities, and functionality.

[0015] Client node 203 may display a variety of data, such as data indicating current and historical amounts of TI or other store of value held, transaction history, frequent trading partners, loans or liabilities, accumulations or rewards, availability of other opportunities, etc.

[0016] A client node 203 may provide a variety of functions, such as initiating a purchase of TI, using TI to purchase goods or services, depositing the TI for various purposes, lending or borrowing TI, exchanging the TI for other TI or other currencies or stores of value, or financial instruments or investments. A client node 203 may provide the ability to communicate with other nodes, share files, or allow limited access to certain data. Permissions to a client node 203 may be shared between two or more people, granting different levels of access and privileges to different individuals. A client node 203 may enable the ability to be accessed from multiple locations simultaneously, providing an additional layer of information regarding access and security. A client node 203 may request an upgrade or downgrade of account limits or access to additional features or functionality.

[0017] A merchant node 205 may include all of the functionality of a client node 203, but may also include more functionality related to offering goods or services for sale or lease to other users. Such goods or services may be offered for sale on another system, but payment is made through the transposition node network 200, or may connect to the transposition node network 200 through one or more interfaces utilizing a common protocol. A merchant node 205 may offer rewards and loyalty programs, and may also offer the functionality to calculate advantageous offers or predictions of purchasing patterns. Merchants may offer the ability to interconnect back-end analytical systems with the transposition node network 200 to optimize spender predictions and offers, as well as the ability to cooperate with other merchant nodes 205 to form mutually beneficial federations. A merchant node 205 may have additional comprehensive reporting capabilities related to sales, returns, inquiries, repeat purchases, purchase volume or frequency, and patterns related thereto. A merchant node 205 may offer the functionality to offer its TI as a sub-offering in the transposition node network 200.

[0018] The transposition node 201 may include all of the functionality of the client nodes 203, company nodes 202 and merchant nodes 205, but will also act as the central processor, trusted source database and clearinghouse for all TI creation, issuance, exchange and reward. The transposition node 201 will maintain various accounts for the client nodes 203, company nodes 202 and merchant nodes 205, including VVFV accounts, TI accounts, USD accounts, FVVV accounts, loans and various other currency or value store accounts. All communications and transactions in the transposition node network 200 initiated by the client nodes 203, company nodes 202 and merchant nodes 205 will be processed and recorded, or sent onward to the ultimate recipient, or received by the transposition node 201 for further action.

[0019] Responsibilities of a transposition node may be shared by two or more transposition nodes in a federated manner, where roles and functions are assigned by agreement, such an embodiment may still include senior transposition nodes or transposition nodes with differing degrees of responsibility and authority, configured and operated based on such agreement.

[0020] In various embodiments, the disclosed technology may enable the creation of a multi-transposition node network in which two or more transposition nodes operate in a cooperative or federated manner. Such a multi-transposition node network would include standardization or interoperability in the calculation of TI records and exchange rates, and uniformity of user liabilities and responsibilities.

[0021] In various embodiments, the network may be implemented using distributed ledger technology ("DLT"), where certain nodes in the network, possibly one or more transposition nodes operating in a federated capacity, are responsible for verifying transactions on an official distributed ledger based on various verification approaches, such as Hashgraph, virtual voting, proof of work, proof of stake, or other consensus algorithms. In such DLT networks, in addition to their status as transposition nodes, company nodes, merchant nodes, client nodes, nodes may act as validating nodes in addition to being leading nodes, and some nodes may be read-only nodes. Validating nodes are responsible for approving transactions on the ledger, while read-only nodes can see transactions on the ledger, but the ability to write transactions to the ledger will depend on the configuration of the DLT network.

[0022] Additionally, in some cases, there may be interactions with parties outside the transposition node network, i.e., Third-Party Nodes 206. Such Third-Party Nodes 206 may be financial institutions, foreign corporations, or individuals that do not participate in the transposition node network 200, but that have a need for transactions.

[0023] 3 is a diagram illustrating a transposition node network 300 having companies. The transposition node network 200 can also be oriented to include multiple companies 301a, 301b, 301c as issuers of FVV that are pooled to fix the value of IPU, where various nodes, such as client nodes 203, can purchase TIs that are tied to the value of one or more companies' FVV. In some implementations, the transposition node network having companies 300 is implemented to perform or otherwise operate in the example processes 900, 1000, 1100, 1200, 1300, 1400, 1500, 1600, 1700, 1800, 1900, 2000, 2100, 2200, 2400, 2500, 2600, 2700, 2800 of FIGS. 9-22 and 24-28.

[0024] In some embodiments, a transposition node network 200 oriented around multiple businesses offering FVV includes such businesses 301a, 301b, 301c, one or more client nodes 203, possibly a merchant node 205, a transposition node 201, etc., all connected together by a communications network 204.

[0025] In such an embodiment, the network may be operated by a transpose node that equates the TI to the FVV of one or more different enterprises, the TI being formulated into separate categories based on the FVV of such enterprises, and the IPUs may reside in a common pool covering the FVV of multiple enterprises or in separate pools, but in either configuration, such IPUs will be paired with the TI issued by the transpose node. The transpose node may operate a system of enterprise-specific networks, where each enterprise may operate a network based on its own FVV, but such enterprise-specific networks may be combined and interoperable with the entire network operated by the transpose node using the TI issued by the transpose node. The network may also be operated by a single enterprise as the transpose node with its FVV forming the sole basis for the pooled and paired FVV with the IPUs.

[0026] 4 is a diagram illustrating possible elements of a transaction instance 400. In various embodiments, upon creation of such a transaction instance (or transaction entry), the transposing node 201 will create a TI record ("TI Record") 400, possibly including a unique identifier for such TI 401, the identity of the company issuing the FVV 402, quantitative data regarding such TI (e.g., number of TIs or IPUs) 403, possibly price or value data 404, introducer or chain of title data 405, a time element 406, an authentication or security element 407, possibly a category or class of the TI 408, possibly pooling, segmentation and probabilistic data 409, and possibly other data and metadata 410.

[0027] 5 illustrates possible elements of an Interest In Pooled Unit Entry 500. In various embodiments, upon creation of an Interest In Pooled Unit, the transposing node 201 will create an IPU Record 500, which may include a unique identifier 501 for such IPU, the identity of the issuer of the FVV 502, quantitative data (e.g., number of IPUs or paired FVVs) 503, possibly price or value data 504, introducer or chain of title data 505, a time element 506, an authentication or security element 507, possibly a category or class of TI 508, possibly pooling, segmentation and probabilistic data 509, and possibly other data and metadata 510.

[0028] 6 is a diagram illustrating possible elements of a pairing record 600. In various embodiments, upon pairing of a TI and an IPU, the transposition node 201 will create a pairing record ("pairing record") 600 that optionally includes a unique identifier for such pairing record 601, the identity of the issuer of the FVV 602, quantitative data (e.g., number of .IPUs or paired FVVs) 503, optionally price or value data 604, introducer or chain of title data 605, a time element 606, an authentication or security element 607, optionally a category or class of the TI 608, optionally pooling, segmentation and probabilistic data 609, and optionally other data and metadata 610.

[0029] Additionally, in some embodiments, a pairing record may be created between the IPU and the FVV, such pairing record being substantially similar to the pairing record between the TI and the IPU, with modifications made to reflect the pairing of the IPU and the FVV.

[0030] 7 is a diagram illustrating the creation 700 of transaction instances, interest in pooled units, and pairing records. In various embodiments, a transposition node receives a conversion request 701 from a client node and converts VVFV units to FVVV units.

[0031] The transposition node 201 creates a transaction instance entry in the database according to the request 702 .

[0032] The transposition node 201 creates an interest-in pooled unit entry in the interest-in pooled unit entry database according to the transaction instance 703 .

[0033] The transposition node 201 creates a pairing record that pairs the interest-in-pooled unit entry with the transaction instance entry 704 .

[0034] 8 is a diagram illustrating determining the values ​​of a transaction instance and interest-in pooled units, as well as the quantity of interest-in pooled units and FVV to be transferred 800. In various embodiments, the transposition node 201 determines 801 the value of the transaction instance based on the value of the VVFV units used to obtain the transaction instance.

[0035] The transposition node 201 determines 802 the total value of interest-in pooled units to be created and the total value of FVVV to be transferred to the FVVV pool based on the value of the transaction instance.

[0036] The transposition node 201 determines the unit value of FVV based on the value of the transaction instance to determine the quantity of interest-in-pooled units to be created and the quantity of FVVV units to be transferred to the FVVV pool 803. If a dividend, partial appreciation participation, or other event occurs with respect to the IPU, the effect of the particular event shall be passed on to the introducer of the TI or holder of the IPU.

[0037] 9 illustrates the properties and pairings of a transposition item 900. In various embodiments, the transposition network computing system 100 achieves an unconventional transposition between a variable amount fixed value unit 903 and a fixed amount variable value unit 909. This transposition is difficult because the two elements being transposed have different characteristics and can only be transformed back and forth through a multi-layer system of variable literals and quantity equivalent pairings mediated by the generation of interest-in-pooled units that operate according to specified rules.

[0038] Activation of the transposition network computing system 100 begins with the input of a variable quantity fixed value unit 903 that has such a property 904 .

[0039] Input of a particular amount of variable amount fixed value units 903 to the transposition network 100 results in the creation of a transaction instance 905. Although the transaction instance 905 is not literally paired with the variable amount fixed value units 903 by unique identification, at the time of creation there is value equivalence between the transaction instance 905 and the variable amount fixed value units 903. This value equivalence necessarily exists only at the time of the creation of the transaction instance 905; at any subsequent time the value of the transaction instance 905 may fluctuate, making it equivalent to a greater or lesser amount of the variable amount fixed value units 903.

[0040] The creation of a transaction instance 905 results in the creation of an interest-in pooled unit 907, which is a fixed-quantity variable-value unit that has opposite properties to the variable-quantity fixed-value unit 903 that served as the initial input to the transposition network computing system 100. The interest-in pooled unit 907 is bound to the transaction instance 905 by literal pairing and unique identification. The literal pairing between the transaction instance 905 and the interest-in pooled unit 907 continues throughout the existence of such two items in the transposition network computing system 100, and the transaction instance 905 and the interest-in pooled unit 907 cannot be created, transferred, atomized, un-atomized, or retired without the same action occurring in the other.

[0041] Part of the pairing between transaction instances 905 and interest-in pooled units 907 is such that the values ​​of transaction instances 905 and interest-in pooled units 907 are always equivalent.

[0042] However, value equivalence between transaction instances 905 and interest-in pooled units 907 does not result in quantity equivalence due to the fact that a transaction instance 905 is a single document that records a particular transaction. As a single transaction record, its quantity can be understood to be one, but it can have a variable amount of value of the interest-in pooled units 907 that it is paired with. The quantity relationship between transaction instances 905 and interest-in pooled units 907 is fixed at creation time and does not change, so if a particular transaction instance 905 is worth 10 interest-in pooled units 907, it will always be equivalent to 10 interest-in pooled units 907.

[0043] An important function in the creation of items to be transposed in the transposition network computing system 100 is the quantity determination of interest-in pooled units 907. During creation, the transposition node 201 checks the unit value of the fixed amount variable value unit 909 at the transposition endpoint. Based on this unit value of the fixed amount variable value unit 909, the transposition node 201 divides the value of the transaction instance 905 by the unit value of the fixed amount variable value unit 909 to determine the amount of the fixed amount variable value unit 909 to be transferred to the fixed amount variable value unit pool 910.

[0044] The amount of the fixed amount variable value units 909 is also determined by determining the amount of the interest-in pooled units 907. The total amount of the interest-in pooled units 907 in the transposition network computing system 100 is always equal to the amount of the fixed amount variable value units 909 in the fixed amount variable value unit pool 910. Since the value of the fixed amount variable value units 909 determines the value of the fixed amount variable value units 907, the interest-in pooled units 907 are paired with the fixed amount variable value units 909 in value in addition to being paired in amount. Unlike the pairing of the transaction instance 905 and the transaction instance 907, the transaction instance 907 and the fixed amount variable value units 909 are not paired with each other literally, but are paired only in quantity equivalent, such that when one transaction instance 907 occurs, one unit of the fixed amount variable value units 909 must be transferred to the fixed amount variable value unit pool 910.

[0045] Furthermore, the value of an interest-in pooled unit 907 determines the value of the transaction instance 905 with which the interest-in pooled unit 907 is paired. Furthermore, the value of the transaction instance 905 may be represented in variable amount fixed value units 903, such representation being simply an item of information on the client node 203 display, or the transposition network computing system 100 may dynamically add or subtract variable amount fixed value units 903 to or from the account of the associated client node 203 according to fluctuations in the value of the transaction instance 905. Alternatively, rather than real-time addition and subtraction, the transposition node 201 may display a running balance of the variable amount fixed value units 903, but may only instantiate variable amount fixed value units 903 in response to transfer or retirement requests.

[0046] In summary, the rules for operating the transposition network computing system 100 that can transpose variable amounts of fixed-value units to fixed amounts of variable-value units and vice versa are as follows: 1. At the start, the value of the variable amount of fixed value unit's input is equal to the value of the output of the created transaction instance. 2. At the start, the amount of variable amount fixed value unit inputs does not need to be equal to the amount of output of the transaction instances created. 3. At initiation, variable amount fixed value units are not paired with transaction instances by unique identity, but only by equal value. 4. At start-up, the values ​​of the inputs of a transaction instance are equal to the values ​​of the outputs of the created interest-in-pooled unit. 5. At the start, the amount of inputs of a transaction instance need not be equal to the amount of outputs of interest-in-pooled units created. 6. At initiation, a transaction instance is paired with an interest-in pooled unit by a unique identification. 7. At the start, the value of the input of the interest-in pooled unit is equal to the value of the output of the identified fixed quantity variable value unit that is transferred to the pool of fixed quantity variable value units. 8. At the start, the amount of input of the interest-in-pooled unit is equal to the amount of output of the fixed-amount variable-value unit. 9. At inception, interest-in-pooled units will not be paired with fixed amount variable value units by unique identification, but only by equal value. 10. At initiation, the amount of the fixed amount variable value unit is determined by dividing the unit price of the fixed amount variable value unit by the value of the transaction instance, which is equivalent to the value of the interest-in-pooled unit. 11. At the start, an input of an amount of fixed amount variable value units is equivalent to an output of an amount of interest-in-pooled units. 12. In all operations of networks in which variable amount fixed value units are transposed to fixed amount variable value units or vice versa, the following rules continue to apply: 2, 3, 4, 5, 6, 7, 8, 9 and 11. 13. When requesting transfer of a transaction instance, the transfer request can be expressed in a variable amount of fixed value units. 14. At transfer request time, the value of the transfer request, expressed in a variable amount of fixed-value units, is mapped to the values ​​of one or more transaction instances, and those transaction instances are identified as receiving the transfer. 15. At the time of the transfer request, if the value of the transfer request is not equivalent to the value of the transaction instance, the transaction instance can be subdivided to be equivalent to the value of the transfer request by creating two descendant transaction instances, one which is the desired subdivision and the other which is the remainder. 16. Upon a transfer request, the identified transaction instance and any identified atomized descendant transaction instances are to be transferred. 17. Upon a transfer request, when a transaction instance is transferred, the interest-in-pooled unit that is paired with it is transferred accordingly. 18. Upon a transfer request, if the transaction instance is fragmented for transfer, the paired interest-in pooled units are fragmented accordingly and the identified and fragmented descendant interest-in pooled units are transferred accordingly. 19. When a transaction instance and interest-in pooled unit are fragmented at the time of a transfer request, the descendant transaction instances and descendant interest-in pooled units that are not transferred remain as the transferor. 20. If at the time of the transfer request the recipient of the transfer is not within the network, the associated transaction instance and interest-in pooled units are considered retired from the network and an equivalent value of fixed-amount variable value units is transferred from the fixed-amount variable value unit pool and liquidated into an acceptable medium of exchange for transfer to a recipient outside the network.

[0047] FIG. 10 illustrates a transfer of transaction instances and interest-in pooled units 1000. A user may wish to use or spend an amount of a transaction instance, which requires a transfer of the transaction instance. In some embodiments, a client node 203 sends a transfer request to the transposition node 201, which may include data regarding the amount and destination, and may also include a preference regarding which transaction instance or category of transaction instances should be used in the transfer request. In such a case, the transposition node 201 receives a transfer request 1002 from the client node 203. In some implementations, the exemplary process is performed by the exemplary networks 100, 200, 300 shown in FIGS. 1-3.

[0048] The transposition node 201 determines 1003 the transaction instance that is to receive the transfer request according to the client node's preferences or network principles.

[0049] The transposition node 201 determines 1004 the interest-in-pooled units for which it will receive a transfer request based on the pairing records.

[0050] The transposition node 201 forwards 1005 the identified transaction instance and the interest in pooled unit.

[0051] The transposing node 201 records 1006 the transfer in a transfer record database.

[0052] In some embodiments, a user may be provided with options regarding which units of TI they wish to transfer, as different units will have different values ​​and attributes. For example, in some embodiments, if incentives or rewards are provided for holding TIs for longer periods of time, a user may default to transferring their most recently acquired TIs first. A user may prefer to transfer TIs with the lowest FVVV purchase price, or may prefer to spend TIs based on a uniform average of all TIs held. If dividends are paid in connection with such TIs, consideration of the impact of spending TIs eligible for dividend participation may influence the decision regarding which TI to spend.

[0053] 11 is a diagram illustrating transaction instance subdivisions and interest in pooled units 1100. A user may wish to use or spend an amount of a transaction instance that is not equivalent to or perfectly divisible into the value of a particular transaction instance. In such cases, subdivisions of the transaction instance are utilized to allow for exchange or trading in the desired subdivision amount 1100. In some implementations, the example process is performed by the example networks 100, 200, 300 shown in FIGS.

[0054] In some embodiments, a client node 203 makes a transfer request that requires fragmentation 1101. The transposition node 201 receives such transfer and fragmentation requests and determines 1102 the transaction instances to be fragmented and forwarded.

[0055] The transpose node 201 subdivides 1103 the identified transaction instance into descendant transaction instances that are equal in value to the original transaction instance.

[0056] The transposition node 201 identifies and subdivides 1104 the interest-in pooled units that are paired with the identified transaction instance into descendant interest-in pooled units that are equal in value to the original interest-in pooled units.

[0057] The transposition node 201 generates 1105 descendant pairing records for pairing the descendant transaction instances with the descendant interest-in pooled units.

[0058] The transposition node 201 leaves 1106 the descendant interest-in pooled units paired with the remaining descendant transaction instances to the client node requesting the transfer.

[0059] The transposition node 201 forwards 1107 the descendant interest-in pooled unit paired with the descendant transaction instance to be forwarded according to the forwarding request.

[0060] The transposition node 201 records 1108 the forwarding request, the descendant transaction instance, the descendant interest-in pooled unit entry, and the descendant pairing record in the transposition node's storage.

[0061] 12 illustrates a disaggregation 1200 of transaction instances and interest-in-pooled units. The network burden of fragmentation, and in particular the conservation of network resource usage as transaction instances are successively broken down into smaller pieces over successive transfers, is benefited by the disaggregation 1200 program. In some implementations, the example process is performed by the example networks 100, 200, 300 shown in FIGS. 1-3.

[0062] In such an embodiment, the transposition node 201 initiates 1201 a procedure for un-amounting descendant transaction instances in the transaction instance database. The transposition node 201 identifies 1202 descendant transaction instances in the transaction instance database for un-amounting.

[0063] The transpose node 201 identifies 1203 a descendant transaction instance of the larger fragment in the transaction instance database or creates one or more of the descendant transaction instances.

[0064] The transposition node 201 replaces 1204 the identified or generated larger fragment transaction instance with the identified smaller fragment transaction instance.

[0065] The transposition node 201 causes the interest-in pooled units paired with the identified or created large fragment transaction instance to undergo the same actions as the associated transaction instance and generates 1205 an adjusted pairing record reflecting this.

[0066] The transposition node 201 causes the interest-in pooled units paired with the associated small fragment transaction instance to undergo the same actions as the associated transaction instance and generates 1206 an adjusted pairing record to reflect this.

[0067] The transpose node 201 records 1207 the descendant transaction instances, descendant interest-in pooled units and descendant pairing records in the transpose node's storage according to the de-fragmentation.

[0068] FIG. 13 illustrates a diagram of a microtransaction fee (MTF) payment 1300 for a TI. In various embodiments, the transposing node network 200 can track a TI from introduction to retirement and enable maintaining certain data in a transaction instance database related to the original introduction of such TI. Such original introduction data can be maintained as part of the transaction instance despite multiple transactions and subdivisions being generated. Based on such records, an introducer of a TI can receive an MTF for downstream usage of such TI introduced by the introducer 1300. Such MTF can participate in actual transaction fees generated by the use of such TI. In some implementations, the exemplary process is performed by the exemplary networks 100, 200, 300 shown in FIGS. 1-3.

[0069] By way of example only, a transpose node 201 creates TI1 and forwards it (for example) to a client node 203, Node 1301. Such client node receives such TI1 and is considered its introducer 1302. Such client node 203 spends 1303 TI1 at a merchant node.

[0070] The transpose node 201 processes 1304 the TI1 payment, calculates the MTF, charges the payer, payee, or both 1305, and forwards 1306 the net payment to the merchant node. The merchant node receives 1307 the net TI1 payment.

[0071] The transpose node 201 sends the MTF to the introducer, but may subtract a share of the client node's 203 possible MTF, which may be negative, i.e., the client node's share is greater than the introducer's MTF, in which case it will be added to the payment to the merchant node 1308. The client node 203 receives a percentage of the MTF generated by TI1 1309.

[0072] The transposition node network 200 will compensate for the possibility that a user intentionally retires a TI with the intent of reintroducing the TI in order to receive credit as a TI introducer. The transposition node network 200 can do this through models that predict unfair behavior based on churn, time between transactions, patterns of TI retirement and introduction, and other factors. Additionally, various penalties can be imposed for retiring a TI, especially if the same or related user repurchases a TI as an introducer.

[0073] 14 illustrates Pooling 1400 of transaction instances for MTF calculation. In some embodiments, using metadata, pooling and probabilistic calculations, a meta-value can be assigned 1400 to specific TIs or classes of TIs held by a user to simplify the calculation of MTF payments to introducers or other users. In some implementations, the example process is performed by the example networks 100, 200, 300 shown in FIGS. 1-3.

[0074] By way of example only, a node, say client node 203, may have been the introducer of TI1, created on 1 / 1 / 23, TI2, created on 2 / 13 / 23, and EC3, created on 5 / 11 / 23. Such a user may hold rights in an MTF, although they do not necessarily yet hold the TIs in question 1401.

[0075] Such TIs provide a constant revenue stream to client nodes 203, but the amount decreases over time according to network calculations. Also, on the transpose node network 200 side, as the time passes since the creation of a TI, the computational complexity of MTF payments becomes more resource intensive for smaller amounts, so it is in the interest of the transpose node 201 to modify the MTF payment calculation basis.

[0076] One possibility is for the transposition node 201 to collect metadata from similar TIs, pool such data, and make a probabilistic determination of the likely average MTF payout for such TIs 1402. The transposition node may also include factors such as geography, size of the TI's subdivisions, the likely cyclical life of the TI, velocity of transactions, factorization of the value of the TI being traded, the user's network score, and other factors in determining the likely average MTF payout for that particular TI 1403.

[0077] Based on all relevant variables, the transposition node 201 arrives at a pooled probabilistic MTF value for the TI, revised over a period of time 1404. Based on such pooled probabilistic value, the transposition node 201 can present the user with an offer to buy out future MTFs for a lump sum payment, fixed payments over the expected TI life, or issue a new TI to the user with the intact MTF in exchange for retiring the MTF components of such downstream TI 1405.

[0078] If the client node 203 accepts, the MTF's share of the TI is retired or consolidated into a network account and processed on a pooled basis to complete the promised exchange 1406.

[0079] 15 is a diagram illustrating a network participation reward (NPR) 1500. In some embodiments, users may be awarded bonuses with network participation rewards ("NPR") 1500. Such NPR may be calculated according to the value of TIs held, the amount of TIs used, introducer credits earned, the length and amount of time TIs held, credits for user referrals, the length of user participation, and other factors 1501. In some implementations, the example process is performed by the example networks 100, 200, 300 shown in FIGS. 1-3.

[0080] Based on such various factors 1501, an NPR point score can be assigned to the user 1502. Based on such NPR point score 1502, the user can receive NPR periodically 1503. Furthermore, the user can introduce the network to other parties 1504. Such other parties join the network and start participating in various activities such as introducing TI, transferring TI, receiving MTF, NPR, dividends and appreciation rewards 1505. The transposition node can calculate a percentage value of all such activities and add it to the user's NPR or pay it separately 1506.

[0081] NPR can be used to incentivize any desired behavior and can be used on a cross-platform basis with other networks. NPR can also be earned by participating in educational opportunities regarding the network's offerings or other goods and services.

[0082] In some embodiments, users may be given rankings or points for other activities or characteristics, such as the ratio of TI purchases to sales or the average time a TI is held, and credits may be given to users who commit to purchasing or holding TIs in larger amounts or proportions and for longer periods of time.

[0083] Nodes may also offer incentives and rewards to other users related to the node's services, products, or relationships. For example, users who pay for goods and services using a transposition node's TI may receive greater discounts and loyalty rewards than if they used other currencies.

[0084] 16 illustrates a transaction instance dividend payout 1600. In some embodiments, the disclosed technology allows for the introduction and possibly subsequent holders to participate in dividend payouts for IPUs. Such dividend payouts may be based on the fragmentation, assumed pooling, metadata and probabilistic principles applied to FVVV appreciate and other rewards described herein 1600. In some implementations, the exemplary process is performed by the exemplary networks 100, 200, 300 shown in FIGS. 1-3.

[0085] In some embodiments, a transposition node 201 may create a TI1 and transfer it to a node, such as a client node 1601. A client node 203 receives the TI1 and will be considered the introducer of the TI1 1602. The introducer will receive certain rights to dividends related to the TI1, which may continue even after the introducer transfers the TI1 1603.

[0086] The client node 203 may spend the TI1 at the merchant node retailer 1604. The merchant node retailer will receive the TI1 1605. Upon the first dividend payment for TI1, even though the client node 203 no longer owns TI1, a dividend payment may be paid to the client node 1606 as the introducer of TI1. The client node as the introducer will receive all or a portion of the dividend for TI1 1607. Note that when a TI is retired, such dividend payments are no longer provided and such dividend payments may be subject to expiration or pooling.

[0087] 17 illustrates pooling 1700 of transaction instances for dividend payment. In some embodiments, using metadata, pooling and probabilistic computations, specific TIs or classes of TIs held by a user can be assigned a metavalue to simplify the calculation of dividend payment for an introducer or other user 1700. In some implementations, the example process is performed by the example networks 100, 200, 300 shown in FIGS.

[0088] By way of example only, a node, say client node 203, may have been the introducer of TI1 created on 1 / 1 / 23, TI2 created on 2 / 13 / 23, and EC3 created on 5 / 11 / 23. Such a user may hold dividend rights, even though they do not necessarily yet hold the TIs in question 1701.

[0089] Such TIs provide a constant stream of dividend income to client nodes 203, but the amount decreases over time according to network calculations. Also, as time passes since the creation of a TI, the amount and complexity of dividend calculations on the part of the transposition node network 200 becomes more resource-intensive for small amounts, so it is in the interest of the transposition node network 200 to modify the basis for dividend payment calculations.

[0090] One possibility is for the transposition node 201 to collect metadata from similar TIs, pool such data, and make a probabilistic determination of the likely average dividend payout for such TI 1702. The transposition node 201 may also include factors such as geography, size of the TI's subdivision, the likely cyclical life of the TI, velocity of trading, factorization of the value of the TI being traded, the user's network score, and other factors in determining the likely average dividend payout for that particular TI 1703.

[0091] Based on all relevant variables, the transposition node 201 arrives at a pooled probabilistic dividend value for that TI, revised over a period of time 1704. The transposition node 201 submits an offer to the client node 203 to buy out all future dividend payments in a lump sum or provide fixed payments over the expected life of such TI based on such probabilistic network value, rather than actual dividend rights, and if accepted, such dividend rights for such TI are consolidated into a retirement or network account and treated on a pooled basis 1705.

[0092] 18 illustrates the retirement 1800 of transaction instances and interest-in pooled units. In some embodiments, a transaction instance is retired 1800. A node, such as a client node 203, may wish to spend or use a transaction instance with a third party node 204, i.e., a party completely outside the network. In such a case, the client node 203 sends a retirement request 1801 to the transposition node 201. In some implementations, the example process is performed by the example networks 100, 200, 300 shown in FIGS. 1-3.

[0093] The transpose node 201 receives 1802 a retirement request from a client node 203 .

[0094] The transposition node 201 determines 1803 the transaction instance to which the retirement request should be applied.

[0095] The transposition node 201 determines 1804 the interest-in pooled units for which it will receive retirement requests based on the pairing records.

[0096] The transposition node 201 retires 1805 the identified transaction instance and the interest-in pooled unit.

[0097] The transposing node 201 records 1806 the retirement in a transfer record database.

[0098] 19 illustrates a partial appreciation participation 1900. In some embodiments, as enabled by network tracking of TI ownership and usage, an introducer may grant a partial appreciation participation in a possible increase in the value of the FVV in a pool paired with an IPU paired with a TI, even if such introducer no longer holds such TI. In some implementations, the exemplary process is performed by the exemplary networks 100, 200, 300 shown in FIGS. 1-3.

[0099] In such an embodiment, the transposition node 201 creates a TI1 and forwards 1901 such TI1 to a client node 203. The client node 203 receives the TI1 and becomes the introducer of the TI1 1902. Upon such receipt, the client node 203 owns a partial appreciation participation credit for the TI1 1903. The client node 203 can then spend 1904 the TI1 at a retailer at a merchant node 205. The merchant node 205 receives the TI1, holds the TI1, and then retires 1905 the TI1.

[0100] Upon such retirement of TI1, the client node 203 may partially participate in the evaluation of the IPU and the value of the FVV paired with that IPU 1906, even though the client node 203 no longer holds TI1.

[0101] Upon such retirement, the introducer may receive a partial appreciation participation payment for that TI1 1907 .

[0102] 20 is a diagram illustrating the paired transaction instances and the functionality of the interest-in-pooled unit 2000. Based on the FVVV price data, the transposition node 201 updates the value of the TI paired to the IPU 2000. In some implementations, the example process is performed by the example networks 100, 200, 300 shown in FIGS.

[0103] In some implementations, by way of example only, it may be possible to view the functionality of such pairing 2000 by looking at time point 2001, IPU value 2002, TI1 value 2003, and TI2 value 2004.

[0104] At time point 1 2005, the value of the IPU is $100 per unit 2006. At time point 1 2005, a TI1 is created and paired with an IPU such that at time point 1 2007, the paired IPU and TI1 have an equivalent value of $100 due to the pairing.

[0105] At time point 2 2008, the value of the IPU has increased by $100, making it $200 per IPU in 2009. At time point 2 2008, an IPU and the TI1 still have equal value, and since the IPU now has a value of $200, the TI1 now also has a value of $200 due to the pairing in 2010.

[0106] At time point 2 2008, where the value of IPU is $200 per unit 2009, if a user purchases a new TI, say TI2, then if he purchases the equivalent of one IPU, the value of said TI2 will be $200 in 2011.

[0107] At time point three 2012, the value of that same IPU has increased by a cumulative $200 and is now $300 per unit in 2013. At time point three 2012, the one IPU and the TI1 still have equivalent value, and since the IPU now has a value of $300, if the TI1 also purchased the equivalent of one IPU, the pairing would now have a value of $300 in 2014.

[0108] At Time Point 3, 2012, the IPU and the TI2 still have equivalent value, and the IPU is now worth $300, so if the equivalent of the IPU is purchased in 2015, the TI2 would also be worth $300 due to the pairing.

[0109] FIG. 21 illustrates the mapping and use 2100 of VVFV units and transaction instances. In some embodiments, a dual system of VVFV and TI can be utilized to achieve certain goals 2100, with VVFV being a parallel currency to TI in the network. TI is paired with IPU, but VVFV can be introduced into such pairing to express the value of TI and IPU in value units pegged to an external currency, e.g., USD. VVFV can exist as an actual unit in an account in the network, or as a conversion basis for users to more easily understand the value of their holdings. VVFV can also exist only in the network, or trade more broadly without the TI or IPU components, functioning like a static stablecoin without the downstream or metadata aspects of TI. In some implementations, the exemplary process is performed by the exemplary networks 100, 200, 300 shown in FIGS. 1-3.

[0110] A node, for example a client node 203, wishes to spend TI 2101. For ease of reference and calculation, such client node 203 displays various balances of TI, but also displays 2102 the equivalent balance of such TI in VVFV.

[0111] Instead of selecting which TI to spend, the client node 203 inputs the amount of VVFV they wish to spend and sends this amount of VVFV to the transposition node 2103. The transposition node 201 receives such instructions and selects the corresponding TI to sell according to various selected principles based on the client node's 203 preferences, such as optimizing the selection of TI to spend based on being linked to a particular company, last in, first out, MTF payment, dividend payment, partial appreciation participation, or maximizing network participation rewards 2104. The transposition node 201 then debits the client node 203 and credits the merchant node 205 for the TI, and debits the client node 203 and credits the merchant node 205 for the VVFV 2105.

[0112] The client node 203 receives a fractional return of TI, if any. The balance of VVFV and TI is adjusted 2106a. The merchant node receives payment for TI and VVFV 2106b.

[0113] In other situations, the client node 203 may wish to transfer the VVFV outside of the TI system, i.e., to another party that accepts the VVFV but does not participate in the TI system 2107. In such a case, the client node 203 may send the desired payment instructions 2108 to the transposition node 201.

[0114] The transpose node 201 receives payment instructions from the client node 203 to pay VVFV standalone, i.e. not tied to a TI, to a party that does not accept the TI. The transpose node 201 debits the client node 203 the VVFV, retires the TI, and sends the VVFV to the third party 2109. The client node 203 receives an atomized return of the TI, if there is any, and the balance of TI and VVFV is adjusted 2109a. The merchant node receives payment for the VVFV not tied to a TI 2109b.

[0115] FIG. 22 illustrates a multi-pairing 2200 between interest in pooled units, transaction instances, VVFV, and external currencies. Based on the price data of the IPU, the transposition node 201 will update the value of the TI paired to such IPU. In some embodiments, additional representations of the value VVFV pegged to the external currency may be utilized to help users more easily ascertain the value of their network holdings or to allow easier exchange with external parties. For example, multiple pairings between IPU, TI, VVFV, and external currencies may be utilized in the network. The VVFV may simply be a display value generated by the transposition node 201 for the benefit of the client node 203 to easily reference to ascertain the value of the client node's 203 account holdings. Alternatively, the VVFV may be a digital currency or coin, such as a stable coin issued by the transposition node or another entity, or a digital dollar, that is continually added and subtracted from the client node's 203 account as the value of the holdings in the client node's 203 account fluctuates. Yet another alternative is for the transposition node 201 to create on-demand, e.g., at transaction time, the specific VVFV used in the transaction according to the balance between the value of the transaction and the value held in the client node's account 203. In some implementations, the example process is performed by the example networks 100, 200, 300 shown in Figures 1-3.

[0116] In some implementations, by way of example only, it may be possible to view a function of such multiple pairings 2200 by looking at a time point 2201, the value of the IPU 2202, the value of the TI paired with the IPU 2203, and the value of the VVFV paired with an external currency 2204.

[0117] At time point 12205, the value of the IPU is $100 per unit 2206. At time point 12205, TI1 is created and paired with one IPU, so that at time point 1, due to such pairing 2207, the IPU and TI1 have an equivalent value of $100.

[0118] Further, if at time point one 2205, 1VVFV is equal to one dollar and such TI1 has a value of $100, then due to such pairing and equality 2208, such TI1 will have a value of 100VVFV or $100.

[0119] At time point 2 2209, the value of that same IPU has increased by $300, to $400 per unit 2210. At time point 2 2209, the value of one IPU and such TI1 are still equivalent, and since the value of one IPU is now $400, by such pairing 2211, such TI1 also has a value of $400. Furthermore, if, at time point 2 2209, 1VVFV is equal to $1 and such TI1 has a value of $400, by such pairing and equivalence, such TI1 also has a value of 400VVFV 2212.

[0120] At time point 3 2213, the value of the IPU has increased by a cumulative $700 and is now $800 per unit 2214. At time point 3 2213, an IPU and the TI1 still have equivalent values, and since an IPU now has a value of $800, the TI1 also has a value of $800 due to the pairing 2215. Furthermore, if, at time point 3 2213, 1VVFV equals $1 and such TI1 has a value of $800, then due to the pairing and equivalence 2216, such TI1 will have a value of 800VVFV.

[0121] 23 is a diagram illustrating display options 2300. In various embodiments, such subdivision can include the implementation of complex grids that present the user with various options for viewing, analyzing, and using their TI 2300.

[0122] Display options may include a list of TIs 2301, an identification of the listed TIs 2302, the value of the TI in VVFV 2303, the value of the TI in USD 2304, the equivalence of the TI in number of IPUs 2305, the change in the value of the TI 2306, the MTF earned 2307, the dividends earned 2308, partial appreciation participations paid 2309, and whether there are any pooling offers from the network 2310, as well as other fields.

[0123] 24 illustrates a transposition request 2400 from VVFV to an interest-in-pooled unit, FVVV. In various embodiments, the transposition node 201 receives the request from the client node 203 and converts 2401 the VVFV unit to an FVVV unit. In some implementations, the exemplary process is performed by the exemplary networks 100, 200, 300 shown in FIGS. 1-3.

[0124] The transposition node 201 generates interest-in pooled units in the database according to the request 2402 .

[0125] The value of the interest in pooled units is equal to the value of VVFV2403.

[0126] The interest in pooled unit includes data regarding the date of the transfer request and the identity of the FVV units transferred at the same time, and possibly the identity of the client node 203 making the request 2404 .

[0127] The unit value of an interest-in-pooled unit is equal to the unit value of an FVVV unit 2405 .

[0128] The amount of interest-in-pooled units is equal to the amount of FVVV units 2406 .

[0129] The determined amount of FVVV units is transferred 2407 to the FVVV pool. FIG. 25 illustrates a transfer 2500 of interest-in pooled units. A client node 203 may wish to use or spend an amount of interest-in pooled units, and such use or expenditure requires a transfer of that interest in interest-in pooled units. In some embodiments, the client node 203 sends a transfer request to the transposition node 201, which may include data regarding the amount and the transfer destination 2501. In such a case, the transposition node 201 receives 2502 the transfer request from the client node 203. In some implementations, the exemplary process is performed by the exemplary networks 100, 200, 300 shown in FIGS. 1-3.

[0130] The transposition node 201 determines 2503 the interest-in-pooled unit for which it will receive a transfer request.

[0131] The transposition node 201 forwards 2504 the identified interest in pooled units.

[0132] The transposing node 201 records 2505 the transfer in a transfer record database.

[0133] 26 is a diagram illustrating subdivision of interest-in pooled units 2600. A client node may wish to use or spend an amount of interest-in pooled units that is not equivalent to or perfectly divisible into the value of a particular stake in interest-in pooled units. In such cases, subdivision of the interest-in pooled units may be utilized to enable exchange or transaction in the desired subdivision amount 2600. In some implementations, the example process is performed by the example networks 100, 200, 300 shown in FIGS.

[0134] In some embodiments, a client node 203 makes a transfer request that requires fragmentation 2601. The transposition node 201 receives such a transfer and fragmentation request and determines 2602 the interest-in pooled units to be fragmented and forwarded.

[0135] The transpose node 201 subdivides 2603 the identified interest-in pooled unit into two descendant interest-in pooled units equal in value to the original interest-in pooled unit.

[0136] The transpose node 201 creates 2604 a descendant interest-in pooled unit entry in the interest-in pooled unit database.

[0137] The transposition node 201 leaves 2605 the remaining descendant interest-in pooled units to the client node requesting the transfer.

[0138] The transposition node 201 forwards 2606 the descendant interest-in pooled units to be forwarded according to the forwarding request.

[0139] The transposition node 201 records 2607 the transfer request and the descendant interest-in-pooled units in the transposition node's storage.

[0140] 27 illustrates a non-fragmentation 2700 of an interest-in pooled unit. The network burden of fragmentation, and in particular the conservation of network resource usage, as interest-in pooled units are successively broken down into smaller pieces over successive transmissions, benefit from the non-fragmentation 2700 program. In some implementations, the example process is performed by the example networks 100, 200, 300 shown in FIGS. 1-3.

[0141] In such an embodiment, the transposition node 201 initializes 2701 a procedure for disaggregating interest-in pooled units in a database of interest-in pooled units.

[0142] The transposition node 201 identifies and disaggregates pooled units in the interest-in pooled unit database 2702. Such identification may be based on characteristics of the interest-in pooled units, such as creation date, location, ease of disaggregation, or other factors.

[0143] The transposition node 201 identifies or generates 2703 one or more of the interest-in pooled units of the larger fragment.

[0144] The transposition node 201 replaces 2704 the identified or generated interest-in pooled units of the large fragment with the identified interest-in pooled units of the small fragment.

[0145] The transposition node 201 records 2705 the descendant interest-in pooled units in the transposition node's storage according to the non-subdivision.

[0146] 28 illustrates the retirement 2800 of an interest-in pooled unit. In some embodiments, the interest-in pooled unit is retired 2800. A node, such as a client node 203, may wish to spend or use the interest-in pooled unit with a third party node 204, i.e., a party completely outside the network. In such a case, the client node 203 sends 2801 a retirement request to the transposition node 201. In some implementations, the exemplary process is performed by the exemplary networks 100, 200, 300 shown in FIGS. 1-3.

[0147] The transpose node 201 receives 2802 a retirement request from a client node 203 .

[0148] The transposition node 201 determines 2803 the interest-in-pooled unit for which the retirement request is to be received.

[0149] The transposition node 201 retires 2804 the identified interest-in pooled units.

[0150] The transposing node 201 records 2805 the retirement in a transfer record database.

[0151] A loan to a transposition node and the creation of a TI based on the loan. Alternatively, in some embodiments, a TI may be created through other methods and steps, such as a transposition node sending an offer to a user to initiate a loan of a certain amount of funds to the transposition node, which may be managed by a user loan protocol. Upon seeing such an offer to initiate a loan to the transposition node, the user may accept the loan offer by sending a loan acceptance to the transposition node. The transposition node will receive such an acceptance of the loan offer.

[0152] According to the loan verification protocol, the transposition node queries the contents of various databases, either in the transposition node storage or externally, to verify the identity of the user, the authenticity of the message containing the loan offer acceptance, the balance of the user's account to be debited, and whether the user has the authority or authorization to complete the purchase offer. If all verification values ​​are sufficiently positive, the transposition node executes the loan from the user to the transposition node by debiting the user's payment account and crediting the transposition node's account receiving the funds. In this regard, the transposition node creates a unique identifier and record regarding the transaction, the loaned funds, their terms, account and balance, and stores the identifier and record.

[0153] Additionally, as part of making such a loan to the transposition node, the transposition node will create or originate a unique TI in a coinbase transaction in an amount then equal to the face value of the loan. In some embodiments, such TI may be paired or correlated, literally or virtually, with the transposition node's FVV or the transposition node's IPU by means of issuing a unique identifier for such pairing or correlation. Such pairing or correlation may be maintained by various granularity, pooling, or metadata steps, as further described below. Such identifiers and records are stored by the transposition node, and the user who first receives such a TI is considered the introducer of such TI. The transposition node creates a TI account associated with the introducer, updates the ledger of all TI accounts, and stores such records.

[0154] The transposition node then sends a TI creation confirmation message to the user and forwards the TI to the user.

[0155] In some embodiments, rather than purchasing TI, a user may purchase FVV and commit it to the network on a custodial basis with predefined rules and obligations. Based on the FVV held in custody by the network, the network may issue IPUs and TI in equivalent amounts to the user, which may be considered a loan from the network to the user, secured by the FVV held in custody by the network.

[0156] In various embodiments, a TI may be paired to the FVVV itself, and each instantiation of the TI, including its subdivisions, would retain a pairing with the ongoing current value of that FVVV. In such embodiments, the value of a particular TI would increase or decrease based on the increase or decrease in the value of such FVVV, and a fixed pairing, which may be full or partial, between such TI and such FVVV would be maintained. Such pairing requires recording the value of that FVV on the date of the TI's creation, and continually updating the value of that FVV to determine the value of the TI. Such record-keeping is required to be maintained if and when the TI is transferred.

[0157] The transposition node may continue to hold the FVV for purposes of maintaining the correlation, or may sell or pledge the FVV to maintain the correlation through the use of derivative instruments or contractual obligations, subject to the parameters of the relationship established between the user and the transposition node.

[0158] In some embodiments, the transposition node will query the external network or receive, via the same instrumentation, price data from the external network regarding the relevant FVV. Based on such price data, the transposition node will update such database records with the latest price information regarding such FVV. Such price information will be stored in one or more databases and accessible by the transposition node when responding to price inquiries from other nodes or when pushing price data.

[0159] Note that pairings with either FVV or the external currency may include upper and lower bands or limits and may be adjusted according to a formula that is not necessarily strict. The paired external currency may be a basket of currencies, and the paired external currency may be changed to another external currency or currencies to provide a different peg to VVFV.

[0160] In some embodiments, in response to standing instructions, the transposition node will use the price data to update various user accounts by calculating values ​​for VVFV, USD, or another value store available to users based on the users' TI holdings. Such updates will utilize and be based on TI records. Such calculated values ​​may be sent based on standing instructions or specific requests by nodes to the transposition node.

[0161] Further, in all examples of this disclosure, the separate functions of TI and IPU may be combined into a unified currency on the network, where acquisition of TI would be acquisition of the unified currency, transfer of TI would be transfer of the unified currency, subdivision and non-subdivision of TI would be subdivision and non-subdivision of the unified currency, and retirement of TI would be retirement of the unified currency. In such a case, the TI record and IPU record would be combined into a unified currency record, and pairing records would not be necessary. Such a unified currency would function similarly to an IPU with respect to pairing with associated FVVV values, and similarly to a TI with respect to network transactions and recordkeeping. To the extent desired, such a unified currency would enable recordkeeping that supports MTF payments, dividend payments, partial appreciation participation, and network participation rewards.

[0162] Portions of the subject matter and operations described herein may be implemented in digital electronic circuitry, including the structures disclosed herein and their structural equivalents, or in computer software, firmware, or hardware, or in any combination of one or more of these. Portions of the subject matter described herein may be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, encoded in a computer storage medium for execution by or to control the operation of a data processing device. A computer storage medium may be or be included in a computer-readable storage device, a computer-readable storage substrate, a random-access or serial-access memory array or device, or a combination of one or more of these. Furthermore, a computer storage medium is not a propagating signal, but a computer storage medium may be a source or destination of computer program instructions encoded in an artificially generated propagating signal. A computer storage medium may also be or be included in one or more separate physical components or media.

[0163] Some of the operations described herein may be implemented as operations performed by a data processing device on data stored in one or more computer-readable storage devices or data received from other sources.

[0164] The term "data processing apparatus" encompasses all kinds of apparatus, devices, and machines for processing data, including, by way of example, a programmable processor, a computer, a system on a chip, or a plurality or combination of the above. An apparatus may include special purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit). An apparatus may also include, in addition to hardware, code that establishes an execution environment for the computer program, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform execution environment, a virtual machine, or a combination of one or more of these.

[0165] A computer program (also known as a program, software, software application, script, or code) can be written in any type of programming language, including compiled or interpreted, declarative or procedural, and can be deployed in any form, as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program can correspond to a file in a file system, but need not. A program can be stored as part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program, or in multiple coordinated files (e.g., files that store one or more modules, subprograms, or portions of code). A computer program can be deployed to run on one computer, on multiple computers located at one site, or distributed across multiple sites interconnected by a communication network.

[0166] Some of the processes and logic flows described herein may be performed by one or more programmable processors executing one or more computer programs to perform operations by operating on input data and generating output. The processes and logic flows may also be performed by, and apparatus may be so implemented as, special purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[0167] In a general aspect, a transposition network is configured to convert variable amount fixed value units to fixed amount variable value units and vice versa.

[0168] In a first embodiment, the computer system includes means for transposing between variable quantity fixed value (VVFV) items containing VVFV units and fixed quantity variable value (FVVV) items containing FVVV units, the transposing means executing one or more transposition network rules.

[0169] Implementations of the first embodiment may include one or more of the following features: The transposition network rules include a rule that specifies:

[0170] At the start, the values ​​of the inputs of the VVFV unit are equal to the values ​​of the outputs of the created transaction instance.

[0171] At the start, the amount of inputs of the VVFV units is not required to be equal to the amount of outputs of the created transaction instances.

[0172] At initiation, VVFV units are not paired with transaction instances by unique identity, but only by equal value.

[0173] At the start, the values ​​of the inputs of a transaction instance are equal to the values ​​of the outputs of the interest-in-pooled unit.

[0174] At the start, the amount of inputs of a transaction instance is not required to be equal to the amount of outputs of the interest-inpooled unit.

[0175] At initiation, a transaction instance is paired with an interest-in pooled unit by a unique identification.

[0176] At initiation, the value of the input of the interest-in pooled unit is equal to the value of the output of the identified FVVV unit that is transferred to the FVVV unit pool.

[0177] At the start, the amount of input of the Interest Inpooled unit is equal to the amount of output of the FVVV unit.

[0178] At inception, interest-in-pooled units will not be paired with FVVV units by unique identity, but only at equal value.

[0179] At inception, the amount of FVVV units is determined by dividing the unit price of an FVVV unit by the value of the transaction instance, which is equivalent to the value of an interest-in-pooled unit.

[0180] At the start, an input of an amount of FVVV units is equivalent to an output of an amount of Interest Inpooled units.

[0181] When a transfer request for a transaction instance is made, the transfer request is expressed in VVFV units.

[0182] At transfer request time, the value of the transfer request expressed in VVFV units is mapped to the value of one or more transaction instances, and those transaction instances are identified as receiving the transfer.

[0183] If the value of the forwarding request is not equal to the value of the transaction instance, the transaction instance is subdivided to be equal to the value of the forwarding request by creating two descendant transaction instances, one which is the desired subdivision and the other which is the remainder.

[0184] Upon a transfer request, the identified transaction instance and any identified atomized descendant transaction instances are transferred.

[0185] Upon a transfer request, if a transaction instance is transferred, the paired interest-in-pooled unit is transferred correspondingly.

[0186] Upon a transfer request, if the transaction instance is fragmented for transfer, the paired interest-inpooled units are correspondingly fragmented and the identified descendant fragmented interest-inpooled units are correspondingly transferred.

[0187] When a transfer request occurs, if a transaction instance and interest-in pooled unit are fragmented, the descendant transaction instances and descendant interest-in pooled units that are not transferred remain with the transferor.

[0188] If the recipient of the transfer is not within the network at the time of the transfer request, the transaction instance and interest-in pooled units are considered retired from the network and the equivalent value of FVVV units is transferred from the FVVV unit pool and liquidated into an acceptable medium of exchange for transfer to a recipient outside the network.

[0189] Although many details are described herein, these should not be understood as limitations on the scope that may be described in the claims, but rather as descriptions of features specific to particular embodiments. Certain features that are described herein or illustrated in the drawings in the context of separate implementations may also be combined. Conversely, various features that are described or illustrated in the context of a single implementation may also be implemented in multiple implementations separately or in any suitable subcombination.

[0190] Similarly, although operations are depicted in the figures in a particular order, this should not be understood to require that such operations be performed in the particular order shown, or in sequential order, or that all of the operations shown be performed, to achieve desirable results. In certain situations, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system components in the embodiments described above should not be understood to require such separation in all embodiments, and it should be understood that the program components and systems described may generally be integrated together in a single product or packaged in multiple products.

[0191] Although several embodiments have been described, it will be understood that various modifications may be made and, therefore, other embodiments are within the scope of the following claims.

[0192] All references herein are to the following: Dividend means any benefit given to holders of FVVV; FVVV or Store of Value means fixed quantity variable value units, which may be stocks, equity, securities, debt, derivatives, commodities, digital currencies, cryptocurrencies, fiat currencies, tokens, or other stores of value; A fixed amount variable value unit pool refers to a pool into which fixed amount variable value units are transferred when brought into the network, such pool being achieved by a segregated account or obligation. Introducer means the User who is the initial introducer of a transaction instance; IPU means Interest Inpooled Unit; MTF means Microtransaction Fees; Network means a transposition network computing system; Node may additionally refer to a client node ("Client Node"), a merchant node ("Merchant Node"), a company node ("Company Node") or a transpositive node ("Transpositive Node"), and further, one or more "nodes" may alternatively refer to an individual or entity operating such node; NPR means Network Participation Rewards; Off-network means outside the network, and entities that are off-network are third-party nodes, which are not members of the network and do not accept transaction instances as valid payments. To make a payment from within the network to a third party, a value within the network must be converted into a variable amount of fixed-value units of exchange that are accepted by the third party; TI means a transaction instance, also known interchangeably as a transaction entry or a transaction instance entry, as described in this disclosure; TI, VVFV, IPU and FVVV also imply references to their fractions; Unified currency means a single currency of TI and IPU combined to exist as one unit containing the functionality of both TI and IPU; By user is meant a user of the network. VVFV or Unit of Exchange means a variable quantity fixed value unit, which may be a fiat currency, stable coin, cryptocurrency, or other unit of exchange. [Explanation of symbols]

[0193] 900 Transposed Item Properties and Pairings 901 items 902 Properties and Pairings 903 VVFV unit 904 Variable amount fixed value unit 905 Transaction Instances 906 A single transaction instance is not literally paired with a VVFV, but a transaction instance is purchased using a VVFV. 907 Interest Inpooled Units 908 Variable-value fixed-amount units are paired to literals by transaction instances with unique IDs. 909 FVVV in the FVVV pool 910 Variable value fixed amount units are not literally paired to interest-in-pooled units by unique ID, but by value.

Claims

1. 1. A computer system comprising:

1. A computer system comprising: means for transposing between VVFV items containing variable quantity fixed value (VVFV) units and FVVV items containing fixed quantity variable value (FVVV) units, the means for transposing implementing one or more transposition network rules.

2. The transposition network rule is: At the start, the values ​​of the inputs of the VVFV unit are equal to the values ​​of the outputs of the created transaction instance.

2. The computer system of claim 1, further comprising a rule specifying:

3. The transposition network rule is: At the start, the amount of inputs of the VVFV unit is not required to be equal to the amount of outputs of the created transaction instance.

3. The computer system according to claim 1, further comprising a rule specifying:

4. The transposition network rule is: At the start, the VVFV units are not paired with transaction instances by unique identity, but only by equal value.

4. The computer system according to claim 1, further comprising a rule specifying:

5. The transposition network rule is: At the start, the values ​​of the inputs of a transaction instance are equal to the values ​​of the outputs of the created interest-in-pooled unit.

5. The computer system according to claim 1, further comprising a rule specifying:

6. The transposition network rule is: At the start, the amount of inputs of a transaction instance is not required to be equal to the amount of outputs of the interest-in-pooled units created.

6. The computer system according to claim 1, further comprising a rule specifying:

7. The transposition network rule is: At initiation, a transaction instance is paired with an interest-in-pooled unit by a unique identification.

7. The computer system according to claim 1, further comprising a rule specifying:

8. The transposition network rule is: At the start, the value of the input of the interest-in pooled unit is equal to the value of the output of the identified FVVV unit that is transferred to the pool of FVVV units.

8. The computer system according to claim 1, further comprising a rule specifying:

9. The transposition network rule is: At the start, the amount of input of the interest-inpooled unit is equal to the amount of output of the FVVV unit.

9. The computer system according to claim 1, further comprising a rule specifying:

10. The transposition network rule is: At inception, interest-in-pooled units are not paired with said FVVV units by unique identity, but only by equal value.

10. The computer system according to claim 1, further comprising a rule specifying:

11. The transposition network rule is: At initiation, the amount of the FVVV units is determined by dividing the unit price of the FVVV units by the value of the transaction instance, which is equivalent to the value of an interest-in-pooled unit.

11. The computer system according to claim 1, further comprising a rule specifying:

12. The transposition network rule is: At the start, the input of the amount of FVVV units is equal to the output of the amount of interest-in-pooled units.

12. The computer system of claim 1, further comprising a rule specifying:

13. The transposition network rule is: When a transfer request for a transaction instance is made, the transfer request is expressed in VVFV units.

13. The computer system of claim 1, further comprising a rule specifying:

14. The transposition network rule is At the time of a transfer request, the value of the transfer request expressed in the VVFV units is mapped to values ​​of one or more transaction instances, and the transaction instances are identified as receiving the transfer.

14. The computer system of claim 1, further comprising a rule specifying:

15. The transposition network rule is At the time of the forwarding request, if the value of the forwarding request is not equal to the value of the transaction instance, the transaction instance is subdivided to be equal to the value of the forwarding request by creating two descendant transaction instances, one with the desired granularity and the other with the remainder.

15. The computer system of claim 1, further comprising a rule specifying:

16. The transposition network rule is Upon a transfer request, the identified transaction instance and any identified granular descendant transaction instances are transferred.

16. The computer system of claim 1, further comprising a rule specifying:

17. The transposition network rule is Upon a transfer request, a transaction instance is transferred and, in response, the paired interest-in-pooled units are transferred.

17. The computer system of claim 1, further comprising a rule specifying:

18. The transposition network rule is Upon a transfer request, if the transaction instance is fragmented for transfer, the paired interest-in pooled units are fragmented accordingly, and the identified and fragmented descendant interest-in pooled units are transferred accordingly.

18. A computer system according to claim 1, further comprising a rule specifying:

19. The transposition network rule is When a transaction instance and an interest-in-pooled unit are fragmented at the time of a transfer request, the descendant transaction instances and descendant interest-in-pooled units that are not transferred remain the transferors.

19. The computer system of claim 1, further comprising a rule specifying:

20. The transposition network rule is If the recipient of a transfer is not within the network at the time of the transfer request, the associated transaction instance and interest-in pooled units are considered retired from the network and the equivalent value of the FVVV units is transferred from the FVVV unit pool and liquidated into an acceptable medium of exchange for transfer to the recipient outside the network.

20. The computer system of claim 1, further comprising a rule specifying:

Images