WO2019212958A1 - Systems and methods for token-based reimbursement and disbursement - Google Patents

Abstract

The development of new therapeutic treatments is efficiently financed through a tokenized funding mechanism. Tokens associated with a treatment such as a pharmaceutical are issued by a company developing the pharmaceutical and are purchasable either as an investment in the future success of the pharmaceutical or to mitigate the future cost associated with use of the pharmaceutical. Proceeds of the sale of tokens may fund development of the pharmaceutical and each token may initially represent a part of one pharmaceutical dose. The tokens may be purchased by individuals, investment funds, or insurers, are tradeable on an electronic exchange, and may have a defined or adjustable future redemption value. Revenue generated from pharmaceutical sales may be distributed to token holders. Prioritization in revenue distribution may account for token holder utilization of the products or services of the token issuer and may affect when and how many tokens may be redeemed.

Description

SYSTEMS AND METHODS FOR TOKEN-BASED

REIMBURSEMENT AND DISBURSEMENT

RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Patent Application Nos 62/664,713, filed April 30, 2018, 62/744,046, filed October 10, 2018, and 62/797,790, filed January 28, 2019, the entire disclosure of each of which is hereby incorporated herein by reference.

BACKGROUND

[0002] The resources needed to provide health care services threaten to overwhelm modem health care systems. To fully appreciate the extent of the challenge to our health care system, one may consider escalating costs in the context of the epidemiology of cancer in the West. In the US, for someone bom today, the lifetime risk of being diagnosed with any form of cancer is almost 40%, with half of this risk attributable to cancers of the lung, colon, bladder, skrn, kidney, head, and neck.

[0003] Advances achieved with immuno-oncology therapies are impacting the standard of care across a rapidly increasing number of tumor types, with therapies such as anti-CTLA- 4, anti-PD-1, and anti-PD-Ll antibodies already approved for numerous indications. In addition, combinations including these therapies are being investigated in hundreds of clinical studies, suggesting that success in even a small fraction of these clinical tests would further transform the field. Ultimately, there exists a significant chance for any healthy individual to face a diagnosis at some point in their life that could require treatment with such therapies, with corresponding financial risks and testing of their health insurance benefits.

SUMMARY OF THE EMBODIMENTS

[QQQ4] The disclosure herein advantageously provides for development of new' treatments, as well as advances in health care administration, by targeting cost reduction and risk profile mitigation using novel investment models. Specifically, and advantageously, certain embodiments herein override a prioritization that determines how a company distributes funds to a group of investors or stakeholders. Typically, the prioritization is based upon different types of instruments embedded with different levels of priority claims to distributed funds. For example, when a company issues both preferred stock and common stock, the preferred stock may have preference over the common stock in dividend payments. Thus, owners of the preferred stock receive dividends before owners of the common stock.

[0005] Certain embodiments herein change the prioritization that determines fund distribution by taking into account utilization of the company’s products and/or services Specifically, each stakeholder that utilizes one of the company’s products and/or services receives priority over the stakeholders that did not utilize any of tire company’s products and/or services. This change in prioritization advantageously uses only one type of instrument that, unlike stocks and certain types of bonds, does not require trading one type of instrument for another.

[0006] Certain embodiments herein change the prioritization using an instrument referred to herein as a token. Tokens are a fungible medium of exchange, with each token representing one quantum of investment in a company’s products, services, or other revenue generating assets and/or operations. In some embodiments, tokens represent investment in only one of a company’s revenue-generating assets; such tokens advantageously allow investment in only part of a company, as opposed to stocks that require investing in the entirety of the company. Therefore, tokens have a different risk profile compared to other prior-art instruments, and may find use among investors seeking to obtain a particular o verall risk profile of an investment portfolio.

[0007] In one example, a company issues a plurality of tokens for investment in a pharmaceutical to be developed and manufactured by the company. Each token can initially represent a part of one dose of the pharmaceutical (e.g., 1000 tokens equals one dose). The tokens may be generated and circulated as part of an initial coin offering (ICO) that generates revenue for the company to use to develop the pharmaceutical, demonstrate its efficacy, obtain FDA approval, and invest in manufacturing. When the company begins selling the pharmaceutical, revenue generated from sales of the pharmaceutical may be distributed to owners of the tokens, referred to herein as token holders. The company is one example of a token issuer that generates, circulates, and/or manages tokens. Tire token issuer may also oversee all token-related operations, including tracking token swaps between token holders, determining prioritization, and/or distributing to token holders revenue generated from sales. Other examples of a token issuer include an individual, an LLC or LLP, a non-profit organization, a public company, a cooperative, and a government entity. Alternatively, the token issuer may circulate tokens by means other than an ICO, such as giving them away or giving them to stock holders as a form of dividend payment.

Ί [QQQ8] In an additional example, the token issuer increases demand for tokens sold via the ICO by associating with each token a redemption value to be paid back to the token holder. The token issuer may assign an identical redemption value to the tokens such that all of the tokens have the same redemption value. For example, the token issuer may sell tokens for $1 each, with an identical redemption value of $5.75 each, corresponding to a 475% return on in vestment (RQ1). In exchange for a known RQI at the time of purchase, the token purchaser assumes the risk of not knowing when the return will come, as it may take several years for the product to be developed, released and/or approved for sale (e.g., FDA approval when the product is a pharmaceutical), and generate a revenue stream from which funds to distribute to token holders may be obtained.

[0009] Certain embodiments herein change the prioritization of distribution by controlling (1) when a token holder may redeem tokens, and (2) how many tokens a token holder may redeem at any given time. A token holder redeems a token by surrendering the token (i.e., relinquishing ownership of a token) in exchange for the redemption value. Embodiments herein implement these two controls by generating redemption slots into which an assigned token holder may“insert” tokens for redemption. When the assigned token holder inserts one token into a redemption slot, the redemption slot is“filled” and the assigned token holder is paid the redemption value. In one embodiment, each redemption slot accepts one token, thereby establishing a one-to-one relationship between a number of filled redemption slots and a number of corresponding redeemed tokens. After a token is redeemed by filling a redemption slot, the token may be removed from circulation.

[QQ10] Continuing the above pharmaceutical example, one of the token holders may be diagnosed with a disease or condition treatable with the pharmaceutical. This diagnosed token holder may submit a doctor s prescription and/or invoice proving their need and/or use of one or more doses of the pharmaceutical. As the cost of the pharmaceutical may be very high, the diagnosed token holder is given priority m funds distribution, advantageously increasing the liquidity of his or her tokens and thereby allowing the diagnosed token holder faster access to funds needed to cover the cost of the one or more doses.

[QQ11 ] Tire number of tokens to which the diagnosed token holder is given priority may depend upon one or more of: the number of doses used, or to be used, by the diagnosed token holder: a total number of tokens held by the diagnosed token holder; and a distribution budget containing the funds to be distributed to the token holders. The distribution budget may be determined from one or more of: sales revenue of the pharmaceutical during a previous fiscal period (e.g., fiscal quarter, month), a net sale price per dose during the previous fiscal period, a cost of goods sold (COGS) per dose during the previous fiscal period, and the redemption value. For example, if the diagnosed token holder is prescribed five doses of the pharmaceutical, and each dose corresponds to 1,000 tokens, the diagnosed token holder may redeem up to 5,000 tokens (assuming the diagnosed token holder is in possession of at least tliis many tokens). When the diagnosed token holder elects to redeem the tokens, he or she receives the redemption price, e.g., $5.75 per token or $28,750 in total, assuming tire distribution budget is larger than this amount. The diagnosed token holder may redeem only some of the tokens allowed, such as 2,500 tokens instead of the 5,000 maximum allowed. There may be more than one diagnosed token holder, in which case all of the diagnosed token holders may be given priority_' to redeem respectively-owned tokens.

[0012] In another example, one or more tokens are owned by an insurer covering one or more policyholders who were diagnosed with the disease or condition treatable with the pharmaceutical. Although the diagnosed policyholders are not direct token holders, the insurer may redeem tokens early to cover the costs of the diagnosed policyholders for purchasing doses of the pharmaceutical. Tire number of tokens to which the insurer is given priority may be determined by a total number of doses used, or to be used, for all of the insurer’s diagnosed policyholders. In addition, there may be more than insurer covering diagnosed policyholders, in which case all of the insurers may be given priority to redeem respectively-possessed tokens.

[0013] The change in prioritization and subsequent redemption of tokens may be repeated periodically, such as every fiscal quarter, calendar quarter, month, or biannually. When a new distribution period begins, the distribution budget may be updated according to sale revenue, net-price-per dose, and/or COGS-per-dose of the pharmaceutical from a previous distribution period. For example, at beginning of a second quarter, a first quarter sales figures may be used to size the distribution budget for distribution to the token holders during the second quarter.

[0014] Token holders who are allowed priority redemption of tokens may be referred to herein as priority token holders. The diagnosed token holders and the insurers covering diagnosed policyholders, as described above, are examples of priority token holders. The priority token holders may change from one distribution period to the next, such as when a token holder becomes a diagnosed token holder and is prescribed the pharmaceutical, or when a previous diagnosed token holder stops using the pharmaceutical. Similarly, an insurer^’s diagnosed policyholders may change from one distribution period to the next, changing how many tokens any one insurer is given priority to in a given distribution period. [QQ15] Embodiments herein redeem tokens via reimbursement and disbursement “Reimbursement” means distributing funds from the distribution budget to priority token holders related to their utilization of the asset (e.g., compensating for costs incurred to purchase doses of the pharmaceutical). “Disbursement” means distributing a remainder of the distribution budget to all token holders, including the priority token holders. Thus, certain embodiments herein reimburse the priority token holders, from the disbursement budget, prior to disbursing the remainder of the disbursement budget to all of the token holders.

[QQ16] In certain embodiments, reimbursement includes distributing funds to a priority token holder before the priority token holder has incurred costs associated with utilization of the asset. In certain embodiments, designation as a priority token holder is determined by demonstrated future utilization of the asset, such as by ordering the asset, being directed to use tlie asset, or budgeting to use the asset. For example, the patient described above may have ordered one or more doses of the pharmaceutical from a pharmacy, but not yet paid for the doses. Alternatively, the patient may have been prescribed one or more doses of the pharmaceutical, but not yet ordered them from the pharmacy. In an example in the context of a health insurer, the health insurer may have received claims for one or more doses of the pharmaceutical but not yet paid the claims. Alternatively, the health insurer may have determined according to appropriate insurance principles that it will need to budget for at least a certain number of doses of the pharmaceutical in a future period and may be designated a priority token holder with respect to those doses. In these examples, the patient or health insurer will incur costs in the future, and may thus be designated a priority token holder accordingly. In these examples, reimbursement before incurring costs advantageously minimizes cash flow limitations for the patient or health insurer.

[0Q17] Reimbursement and disbursement may each last a predetermined redemption period, such as one week or one month. For example, reimbursement may last a first redemption period of one month, after which disbursement occurs during a second redemption period that also lasts one month. Thus, each distribution period may have one or more redemption periods. In some embodiments, there is no delay between reimbursement and disbursement. That is, reimbursement and disbursement are both implemented during one redemption period.

[QQ18] In one embodiment, the token issuer circulates tokens having an identical redemption value that is fixed. In this embodiment, each token holder knows how much he/she will ultimately receive for each of their tokens. In another embodiment, the token issuer may change the redemption value of the tokens after issuance (i.e., generating and circulating the tokens) and before redemption. For example, the token issuer may change the redemption value with each redemption period. For one redemption period, the token issuer may set the redemption value based on total sales and/or net sales price per dose of a previous redemption period. Thus, the token issuer may control reimbursement and/or distribution by adjusting the redemption value in addition to a number of slots generated and assigned to each token holder

[0019] The term“utilization^’’ (as well as“utilize”) is used herein to include usage, transaction, and/or distribution of the company’s products and/or sendees. The term “utilization” may also include participating, either wholly or partially, in said usage, transaction, and/or distribution. Thus, in an example involving a pharmaceutical, a patient utilizes the pharmaceutical when taking the pharmaceutical, a doctor utilizes the pharmaceutical by prescribing the pharmaceutical to the patient, a pharmacy and/or hospital utilizes the pharmaceutical by dispensing the pharmaceutical to the patient, and the pharmaceutical company utilizes doses by distributing the pharmaceutical to hospitals, doctors, and/or pharmacies. Utilization also includes certain actions done by others, for example, a patient may utilize an asset when prescribed a pharmaceutical by a doctor. In an example involving a pharmaceutical, the insurer utilizes the pharmaceutical by, for example, paying for, budgeting for, or receiving claims for one or more doses of the pharmaceutical or otherwise facilitating transactions of the pharmaceutical between policyholders, doctors, hospitals, clinics, pharmacies, the pharmaceutical manufacturer, and/or other entities.

[0020] Although the above examples present the asset as a pharmaceutical, embodiments herein may be implemented with any of several other types of assets. For example, the asset may be a production line for a non -pharmaceutical product, wherein each token corresponds to a portion of one unit of the product. For example, the asset may be an assembly line manufacturing one model of a car, each unit corresponding to one car. Revenue generated from the sale of tokens (e.g., an ICO) may be used to pay for assembly line equipment, tooling, worker training, and/or raw materials. When the cars begin to sell, revenue generated from the sales may then be used to redeem tokens A token holder may be allowed priority redemption after purchasing one or more of the cars. In addition to individual investors, examples of token holders who may benefit from such priority redemption include car insurers and rental-car companies.

[QQ21] The asset may be non-tangible, such as computer software. For example, a software company may sell tokens to raise revenue to develop, document, test, and distribute the software. Each token may correspond, for example, to one license of the software or one monthly subscription fee or fraction thereof. When the software begins to generate revenue, such as through the sale of licenses and/or subscription fees, the generated revenue may then be used to redeem tokens. A token holder may be allowed priority redemption after purchasing one or more of the subscriptions. In addition to individual investors, examples of token holders who may benefit from such priority redemption include large corporations with specialized information technology needs.

[0022] In another example of a non-tangible asset, the asset may be a sendee and each token may correspond to a portion or fraction of a service. In some embodiments, the token may correspond to an amount of time providing the service or to a defined amount of sendee provided. The defined amount may correspond, for example, to one contract, or portion thereof, that the company signs with a client to provide the sendee to the client. The token may also correspond to a fraction of the service asset without specifying any particular portion of the service (e.g., 1000 tokens corresponds to one service unit). In a medical example, the sendee may be a diagnostic service provided by a physician and 1000 tokens may correspond to one diagnosi s. In another embodiment, the token may correspond to one quantum of revenue (e.g., a fixed amount of revenue) generated by a sendee. In one service example, a sendee-based company may sell tokens to raise revenue to invest in equipment to expand into a new line of services. When tire company completes the work, the generated revenue may then be used to redeem tokens, such as wiien token holders utilize the new line of services. The company may also redeem tokens as revenue is generated prior to completion of the sen ice or contract. A token holder may utilize a service by any means that are appropriate for the service (e.g., placing an order for the service, forming a contract, initiating use of the sendee, having the service partially or fully completed, reaching milestones in the sendee, or completing the contract). A token issuer may then allocate priority slots according to the utilization of the service by token holders (e.g., allocating priority slots to token holders who have placed an order for the service during the period). In another example, there is no association between tokens and assets. In this example, each token corresponds directly to a fixed amount of generated revenue. For example, a company may redeem one token for each $10 of re venue that the company generates.

[QQ23] Accordingly, the disclosure provides a new digital security that enables institutional and individual investors to participate side-by-side in financing of a single biotech asset (or other assets) with predictable venture-like returns. Proceeds are thus available to fund development through approval and commercialization, with returns to investors backed by product sales. [QQ24] Advantageously, therefore, this disclosure improves how companies and investors manage risk. In one exemplary industry, these improvements permit investment in biopharmaceutical drag development projects to overcome several challenges, such as:

• Efficiency. Allocation of the vast amount of capital invested in pharmaceutical R&D by public and private companies (nearly US $157 billion in 2017) is improved using the teachings of this disclosure by allowing investors to back specific projects over others within and across company pipelines.

Investor inclusion . Historically, promising biotech investments have been restricted to institutional investors, and participation from individual investors in deals with the greatest return potential is typically only possible by invitation into a syndicate.

Institutional investors get the opportunity to get in early, while individual investors are forced to w'ait for later offerings with smaller returns. Hie teachings of this disclosure level the playing field.

• Liquidity. A company may have a drug worthy of backing; however there is historically no standardized way for direct investment without buying tire company’s stock and incurring dilution risk. Further, when pro_ject financing is available, it is closely syndicated, and institutions do not have exit mechanisms to partially unwind their positions. Hie teachings of this disclosure provide needed liquidity.

• Predictable returns. The upside potential in a company’s stock is often correlated with the lead asset’s commercial potential. Commercial risk impacts investor returns leaving the upside uncertain e ven if a product is commercialized. But, through the teachings of this disclosure, returns are more predictable.

Involvement by key stakeholders. While payor organizations have long considered participation m funding of therapeutic drag programs, no investment instrument aligned with their business model has been available until now, as evidenced by this disclosure.

[0025] The tokens and methods presented herein address these challenges. For example, their implementation allows tokenization of a portion of future sales in an asset, some even in clinical trials. With each token purchased, an investor is thus entitled to a defined return (e.g., up to 10^c) on the token price, for example; and investors are able to claim this return through token-by-token redemption. In an example, investors may receive additional tokens (e.g., per 100 tokens held) as a form of token interest.

[0026] In embodiments, implementation of these digital tokens allows for unprecedented tradability for an asset-specific security, and equity conversion provisions provide risk mitigation features for investors. These tokens offer dilution protection while the redemption priority features described below turn redeemed royalties into product rebates for payors who are also token holders.

BRIEF DESCRIPTION OF THE FIGURES

[0027] FIG. 1 shows one example of a token registry storing token balances and priority-slot allotments prior to reimbursing priority token holders of a plurality of token holders, in an embodiment.

[QQ28] FIG. 2 show's the token registry of FIG. 1 after the priority token holders redeemed tokens in priority redemption slots during reimbursement, in an embodiment

[0029] FIG. 3 show's the token registry of FIG. 1 storing regular-slot allotments prior to disbursing to the plurality of token holders, in an embodiment.

[0030] FIG. 4 shows the token registry of FIG. 1 after the token holders redeemed tokens in regular redemption slots during disbursement, in an embodiment.

[0031] FIG. 5 is a flowchart illustrating one example method that reimburses priority token holders from a budget prior to disbursing a remainder of the budget to the token holders, in embodiments

[0032] FIG. 6 is a flowchart illustrating another example method that reimburses priority token holders from a budget prior to disbursing a remainder of the budget to the token holders, in embodiments.

[QQ33] FIG. 7 shows one example of a distributed-ledger-based computing platform on which embodiments herein may be implemented.

[QQ34] FIG. 8 show's one example of the smart contract of FIG. 7 containing data and executable instructions, in embodiments.

[0035] FIG. 9 is a flowchart illustrating execution of a priority-slot allocator of the smart contract of FIGS. 7-8, in embodiments.

[0036] FIG. 10 is a flowchart illustrating execution of a token redeemer of the smart contract of FIG S. 7-8, in embodiments.

[0037] FIG. 11 is a flowchart illustrating execution of a regular-slot allocator of the smart contract of FIGS. 7-8, in embodiments.

[0038] FIG. 12 is a functional diagram of an example computing device that communicates with the smart contract of FIGS. 7-8 via a node of the distributed-ledger-based computing platform of FIG. 7, in embodiments. [QQ39] FIG. 13 shows the computing device of FIG . 12 communicating with the node of FIG. 12 to deploy the smart contract of FIG. 7 on the distributed-ledger-based computing platform of FIG. 7, in an embodiment.

[0040] FIG. 14 is a block diagram of an example token allotment system that accesses, exchanges, and triggers redemption of treatment allotment tokens, in embodiments.

[0041] FIG. 15 shows a value ladder that illustrates issuance of additional tokens to holders of active tokens, in embodiments.

[QQ42] FIG. 16 is a flowchart illustrating one example method that allows participation in an allotment token exchange, in embodiments.

[0043] FIG. 17 is a flowchart illustrating another example method that allows participation in an allotment token exchange, in embodiments.

[0044] FIG. 18 is a functional diagram of one example allotment system, in an embodiment.

[0045] FIG. 19 is a flow-chart illustrating one example method that manages a digital token, in embodiments.

[0046] FIG. 20 is a flow-chart illustrating one example method that manages tokens with a token platform, in embodiments.

[0047] FIG. 21 is a flowchart illustrating one example method that redeems treatment or product associated with tokens, in embodiments.

[0048] FIG. 22 is a flow-chart illustrating one example method that resets a token having an assigned beneficiary, in embodiments.

[QQ49] FIG. 23 is a block diagram of one example distributed computer system in which various aspects and functions are practiced.

[0050] F1G. 24 shows one example of tokens being converted to interest-bearing tokens (IBTs) according to unfilled redemption slots remaining at the end of a redemption period, in embodiments.

[0051] FIGS. 25 and 26 show one example of simultaneous reimbursement and disbursement, in embodiments.

[QQ52] FIG. 27 shows the smart contract of FIGS. 7-8 additionally configured with a token recaller that implements token recall rights and recalling functionality described herein, m embodiments.

[0053] FIG. 28 is a flow-chart illustrating execution of the token recaller of FIG. 27, in embodiments. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0054] FIGS 1-4 show one example of a token registry 100 that tracks reimbursement and disbursement to a plurality of token holders. Token registry 100 has a plurality of indexed rows (see index 102), each corresponding to one token holder. Token registry 100 also has a plurality of columns storing token holder identifiers 104, token balances 106, redemption slot allotments (e.g., priority-slot allotments 108 and regular-slot allotments 308) and redemptions (e.g., priority-slot redemptions 1 10 and regular-slot redemptions 310). Beneath token registry 100, a total number of tokens, redemption slots, and redemptions (i.e., filled redemption slots) are displayed in the corresponding column. FIGS. 1-4 are best viewed together with the following description.

[0055] FIGS. 1-4 show only the first six rows of token registry 100, corresponding to first, second, third, fourth, fifth, and sixth token holders. However, it should be understood that a number of rows of token registry 100 equals a number of token holders and that any number of rows may be implemented in the token registry 100 without departing from the scope hereof. In token registry 100, each token holder has a token holder identifier 104 that is a hexadecimal address representing, for example, an account or key value. For example, the address may identify an account owned by the corresponding token holder on a distributed-ledger-based computing network (e.g., Ethereum, Bitcoin, or another blockchain-based computing network).

[0056] FIG. I shows token registry 100 as a first token registry 100(1) at the beginning of reimbursement to priority token holders. First token registry 100( 1 ) shows ten million tokens distributed among first, second, third, fourth, fifth, and sixth token holders. The first fourth, and fifth token holders represent priority token holders, as they have non-zero priority-slot allotments 108. More specifically, the third column of token registry 100(1) shows a total of 170,000 priority redemption slots, as determined from the distribution budget. The first token holder has an allotment of 50,000 priority redemption slots, the fourth token holder has an allotment of 20,000 priority redemption slots, and the fifth token holder has an allotment of 100,000 priority redemption slots. The second, third, and sixth token holders are not priority token holders, and therefore, each is allocated zero priority redemption slots.

[Q057] FIG. 2 shows token registry 100 as a second token registry 100(2) after the priority token holders redeemed tokens in priority redemption slots during reimbursement. For each priority token holder redeeming tokens, token balance 106 of said each priority token holder is reduced by a number of tokens redeemed by said each priority token holder. When each redemption slot receives only one token, each filled redemption slot reduces a corresponding token balance 106 by one token. In FIG. 2, three redemption scenarios are presented. The first token holder redeemed zero tokens, leaving the first token holder token with token balance 106 unchanged at 5,000,000 tokens. The fourth token holder redeemed 20,000 tokens, equal to the allocated priority-slot allotment, leaving the fourth token holder with token balance 106 of 30,000 tokens. The fifth token holder redeemed 50,000 tokens, equal to one-half of the allocated priority-slot allotment, leaving the fifth token holder with token balance 106 of 700,000 tokens.

[0058] Reimbursement may last for a predetermined first redemption period, such as one week or one month. After the first redemption period has expired, the remainder of the distribution budget may be used to determine disbursement to all of the token holders. In one embodiment, funds from priority redemption slots left unredeemed at the end of the first redemption period are included in the remainder of the disbursement budget for distribution during a subsequent second redemption period. That is, any funds remaining from unredeemed priority redemption slots may be disbursed to the token holders as pari of the remainder of the disbursement budget. In one embodiment, the first redemption period may end early, such as when each priority token holder has filled all of their priority redemption slots prior to the scheduled end of the first reimbursement period.

[QQ59] FIG. 3 shows token registry 100 as a third token registry 100(3) storing regular- slot allotments 308 prior to disbursing to the token holders. In this example, the remainder of the disbursement budget has a value equal to 399,999 tokens, and thus 399,999 regular redemption slots are allocated to the token holders. The regular redemption slots are allocated pro rata, i.e., each token holder is allocated a regular-slot allotment 308 according to a fraction of tokens owned by said each token holder. For example, the first token holder has token balance 106 of 5,000,000 token, corresponding to 50.35% of the 9,930,000 unredeemed tokens. Thus, the first token holder is allocated 50.35% of the 399,999 regular redemption slots, or 201,410 regular redemption slots.

[0060] FIG . 4 shows token regi stay 100 as a fourth token registry' 100(4) after the token holders redeemed tokens in regular redemption slots during disbursement. For each token holder redeeming tokens, token balance 106 of said each token holder is reduced by a number of tokens redeemed by said each token holder. Thus, in FIG. 4, each of the first, second, fourth, and sixth token holders redeemed the maximum number of tokens allowed, as indicated by the corresponding regular-slot allotments. For example, the second token holder redeemed 100,705 tokens, and the corresponding token balance 106 was reduced by the same number to 2,399,295 tokens. In FIG. 4, the fifth token holder redeemed zero tokens, and the third token holder redeemed one-half of their regular-slot allotment. [0061 ] Disbursement may last for a predetermined second redemption period, such as one week or one month. In some embodiments, after the second redemption period has expired, the remainder of the disbursement budget, as determined by regular redemption slots left unredeemed at the end of the second redemption period, may be again disbursed to the token holders during a third redemption period. For example, in FIG. 4 only 341,792 regular redemption slots were filled out of a total of 399,999 regular redemption slots. The 58,207 unredeemed redemption slots may be allocated pro rata to token holders, as described above in reference to FIG. 3, and disbursed as described above in reference to FIG. 4. Disbursement may be iterated any number of times until the distribution budget is fully distributed to the token holders or until the end of the distribution period is reached. Thus, one distribution period includes one or more redemption periods.

[0062] In the above examples, some of the token holders chose not to redeem tokens when given the opportunity to do so. In these situations, there is no reimbursement and/or disbursement with regard to said some of the token holders. Therefore, it should be understood that embodiments herein present opportunities for reimbursement and disbursement, and will complete any valid reimbursement and disbursement when accepted by an assigned token holder.

[0063] FIG. 5 is a flowchart illustrating one example method 500 that reimburses priority token holders from a distribution budget prior to disbursing a remainder of the distribution budget to all of token holders. Method 500 includes a step 502 that circulates tokens to token holders. In one example of step 502, tokens are sold to token holders as part of an ICO. Method 500 also includes a step 504 that allocates a distribution budget based on sales of an asset during a period, and a step 506 that reimburses each of the token holders from the distribution budget based on a number of units of the asset utilized by said each of the token holders during the period. FIGS. 1-2 illustrate one example of step 506. Method 500 also includes a step 508 that disburses a remainder of the distribution budget to the token holders FIGS. 3-4 illustrate one example of step 508.

[0064] FIG. 6 is a flowchart illustrating another example method 600 that reimburses priority token holders from a distribution budget prior to disbursing a remainder of the distribution budget to all of the token holders. Method 600 includes a step 602 that circulates tokens to token holders. In one example of step 602, token holders purchase tokens as part of an ICO. In one embodiment, step 602 sets identical redemption value to every token. In some embodiments, where the tokens are digital tokens (e.g., smart contracts) deployed on a computing platform based on a distributed ledger, such as shown in FIG. 7, step 602 sells at least one token to at least one token holder via a transaction, and digitally encodes the transaction in the distributed ledger. In one of these embodiments, step 602 circulates digital tokens that are tradeable on a regulated security token exchange. In another of these embodiments, step 602 circulates tokens that are not tradeable on the regulated security token exchange until after a trigger event has occurred.

[0065] Method 600 includes a step 604 that waits for a redemption condition to occur. In the pharmaceutical example above, the redemption condition may be a first commercial sale of the pharmaceutical. In one embodiment, step 602 circulates tokens that are passive, meaning that they are tradeable but not redeemable until after step 604. In one embodiment, step 604 converts passive tokens to active tokens that are redeemable. In another embodiment, active tokens are held in escrow by an escrow agent that initiates the converting upon occurrence of the redemption condition.

[0066] Method 600 also includes a step 606 that generates a plurality of redemption slots based on sales of an asset during a period. In some embodiments, step 606 determines a number of redemption slots based on at least one of: a net sale price per unit of the asset during the period, COGS per unit of the asset during the period, and the identical redemption value. In one embodiment, each unit of the asset is a dose of a pharmaceutical.

[0067] Method 600 also includes a step 608 that reimburses the token holders. Step 608 may include a step 610 that assigns a priority subset of the redemption slots to each token holder based on a number of units of the asset utilized by said each token holder during the period. FIG. 1 illustrates one example of step 610. Step 608 may also include a step 612 that, for each assigned redemption slot of each priority subset, redeems one of the tokens after the assigned token holder surrenders said one of the tokens. FIG. 2 illustrates one example of step 612. In should be understood that a subset may include the null set. It should also be understood that“after” includes when a first event is necessary for a second event, even though the events may be considered to occur concurrently or within close temporal proximity (e.g., immediately after). In such a case, the second event is after the first event.

[0068] Method 600 also includes a step 614 that disburses to the token holders. Step 614 may include a step 616 that assigns a remaining subset of the redemption slots to each token holder. FIG. 3 illustrates one example of step 616. In one embodiment, step 616 assigns each remaining subset by assigning unused redemption slots of all of the priority subsets. Step 614 may also include a step 618 that, for each assigned redemption slot of each remaining subset, redeems one of the tokens after the assigned token holder surrenders said one of the tokens. FIG. 4 illustrates one example of step 618. In some embodiments, step 616 assigns each remaining subset pro rata.

[0069] Method 600 also includes a step 620 that decides to again disburse remaining redemption slots to the token holders by going back to step 614. Thus, step 614 controls iterative disbursing. In one embodiment, method 600 iterates step 614 any number of times until all redemption slots are filled. In another embodiment, method 600 iterates step 614 until the end of the period (e.g., fi scal quarter) is reached. In some of the embodiments that iterate step 614, step 614 assigns each remaining subset by assigning unused redemption slots of all remaining subsets of a previous iteration.

[0070] In one embodiment, method 600 includes a step 622 that waits until the end of a first period (e.g., a fiscal quarter). When the first period ends and a subsequent second period begins, method 600 loops hack to step 606 to generate another plurality of redemption slots based on sales of the asset during the first period. Steps 606, 608, 614, 620, and 622 may then occur during the second period. In another embodiment, method 600 loops back to step 606, via step 622, once every period. In another embodiment, step 606 generates one redemption slot for each unused redemption slot remaining after expiration of a previous period.

[QQ71] In some embodiments, each token is a digital token implemented as a decentralized cryptocurrency on a distributed -ledger-based computing platform. In other embodiments, the digital token may be implemented on an existing cryptocurrency-based network, such as Bitcoin, Bitcoin Cash, NXT, Steiler, and Litecoin. In another example, the digital token is implemented as a smart contract on a computing platform that includes smart contract and/or distributed application functionality (i.e., scripting), such as Ethereum, Cardano, NEC), and EOS. In one example, the digital token is implemented on Ethereum according to the ERC-20 technical standard.

[0072] FIG. 7 shows one example of a distributed-ledger-based computing platform

701 on which embodiments herein may be implemented. Computing platform 701 includes a peer-to-peer network formed from a plurality of computing nodes (e.g., see node 1250 in FIGS. 12 and 13) that process transactions and store transaction information in a distributed ledger. In the example of FIG. 7, the distributed ledger is a blockchain 716. Although FIG. 7 only show's one blockchain 716, it should be understood that a copy of blockchain 716 exists on every' node of computing platform 701, and that the nodes work to add blocks to blockchain 716 such that each node stores an identical copy of blockchain 716. Alternatively, computing platform 701 may use a different type of distributed ledger, such as a directed acyclic graph. Computing platform 701 may use any type of consensus, including proof-of-work, proof-of- stake, and/or a voting system.

[0073] Computing platform 701 includes several externally-owned accounts (EGAs) 702, of which only six are shown in FIG. 7. One or more of the EGAs may be owned by the token issuer. One or more of the EGAs may he owned and/or operated by an entity acting as a proxy and/or agent on behalf of one or more of the token holders. One or more of the EGAs may be owned and/or operated by an entity acting as a proxy and/or agent on behalf of the token issuer. Computing platform 701 also includes a plurality of contract accounts, of which only one contract account 710 is shown in FIG. 7. Each of EGAs 702 and contract account 710 has a unique address that identifies that account on computing platform 701 (see EOA addresses 712 and contract account address 720). Contract account 710 stores a smart contract 704 with an associated contract storage 714. Each EOA 702 communicates with contract account 710 by sending a corresponding transaction 708. Smart contract 704 is, for example, a script that executes in response to receiving one of transactions 708. The received transaction 708 contains data that determines execution behavior of smart contract 704, as described in more detail below'. Smart contract 704 may send one or more outputs 718 to one or more of EGAs 702 as part of its execution.

[0074] EOAs 702 may be accessed via computing devices 706 communicatively coupled to computing platform 701. Each of computing devices 706 may be a computer, tablet, or smartphone storing one or more of addresses 712 of EOAs 702. One or more of addresses 712 may be stored on any of computing devices 706 as part of a digital wallet . Each computing device 706 also stores one or more private keys (see private key 1232 of FIG. 12) to access and control one or more corresponding EOAs 702. Although FIG. 12 shows computing devices 706 communicating with computing platform 701 via EOAs 702, it should be understood that each of computing devices 706 communicates to a node storing EGA information.

[0075] FIG. 8 shows one example of smart contract 704 containing data 802 and instructions 806. Which of instructions 806 is executed may depend upon the signature of the received transaction (i.e., which of EOAs 702 sent the transaction 708) and the number and/or values included in the data field of the received transaction . In FIG. 8, data 802 contains a token registry 840, address mappings 842, token data 844, circulation data 846, an owner address 848, a redemption value 850, and an active/passive status 852. Any of these data 802 may be implemented as a state variable permanently stored in contract storage 714. In FIG. 8, instructions 806 are shown with a constructor 808, a token generator 810, a token circulator 812, a token activator 814, a priority-slot allocator 816, a token redeemer 818, a token transfer agent 820, and a regular-slot allocator 824.

[0076] Token registry 840 stores token balances, slot allocations, and redemptions of the token holders. Token registry 100 of FIGS 1 -4 is one example of token registr ' 840 Address mappings 842 are addresses of computing platform 701 that have been mapped to unsigned integers, and are used by smart contract 704 to simplify processing of addresses. Token data 844 includes basic information about the tokens, such as a name for the token, a symbol for the token, and a number of decimal places to be used for calculations. Circulation data 846 may include, for example, the number of tokens in circulation, a cap on the number of circulating tokens, an initial base price for a token, and a number of tokens in reserve . Owner address 848 is the address, or mapped address, of an owner EOA that deployed smart contract 704 (e.g., a token issuer). Smart contract 704 checks each transaction 708 to determine if transaction 708 was sent from an address matching address 848. This matching to owner address 848 allows the owner to have administrative access to smart contract 704 via the owner EOA. Redemption value 850 is the value to be paid back to a token holder who redeems one token. Active/passive status 852 is a single data field that may take either the value“active” or “passive” to reflect whether all passive tokens have been converted to active tokens. Thus, active/passive status 852 indicates whether the redemption condition has been met.

[0077] There are several types of instructions 806 that may be executed by a transaction originating from any one of EGAs 702. Instructions 806 are machine-readable instructions configured to control one or more processors to process data and/or execute other instructions as now described. In particular, constructor 808 is a function that executes once, when smart contract 704 is deployed on computing platform 701. Token generator 810 mints new tokens. Token circulator 812 circulates newly-minted tokens to token holders. Token activator 14 changes active/passive status from“passive” to“active” after the redemption condition has been met. Token redeemer 818 is executed by token holders to redeem tokens. Token transfer agent 820 is also called by a token holder to update token registry 840 when the token holder transfers one or more tokens to another token holder. Regular-slot allocator 824 and priority- slot allocator 816 allocate regular redemption slots and priority redemption slots, respectively.

[Q078] FIG. 9 is a flowchart illustrating execution of priority-slot allocator 816 of smart contract 704. Priority-slot allocator 816 implements a step 902 that receives a transaction (e.g., one of transactions 708 of FIG. 7) containing new priority-slot allotments. Priority-slot allocator 816 also implements a step 904 that compares an originating address of the transaction to owner address 848 to determine if the transaction originated from owner EOA 702(1). If the addresses do not match, priority-slot allocator 816 continues to a step 906 that returns an invalid access error and stops. If the addresses match, priority-slot allocator 816 continues to a step 908 that checks active/passive status 852 to determine if tokens are active and thus redemption of tokens is permitted. If active/passive status 852 is equal to“passive”, then priority-slot allocator 816 continues to a step 910 that returns an error and stops. If active/passive status 852 is equal to“active”, then priority-slot allocator 816 continues to a step 914 that checks token registry 840 to determine if the new priority-slot allotments are valid. Specifically, step 914 checks that each new priority-slot allotment is less than or equal to a token balance of the token holder to which said each new priority-slot allotment is assigned. If at least one of the new priority-slot allotments is invalid, then priority-slot allocator 816 continues to a step 916 that returns an error and stops. If all of the new priority-slot allotments are valid, then priority-slot allocator 816 continues to a step 918 to update token registry 840 according to the new priority- slot allotments. Step 918 may also include setting the redemptions of all token holders (e.g., priority-slot redemptions 110 of FIGS. 1 -2, and regular-slot redemptions 310 of FIGS. 304} to zero.

[Q079] In one embodiment, priority-slot allocator 816 implements a step 920 that notifies the token holders about the new priority-slot allotments dims, the token holders are notified that they- may be able to redeem tokens. Each notification may include a number of new priority slots assigned to the notification receiver, and an expiration date of the current redemption period. In one embodiment, priority-slot allocator 816 implements a step 922 that notifies the contract owner (at owner address 848} that the new priority-slot allotments were successfully allocated.

[0080] FIG. 10 is a flowchart illustrating execution of token redeemer 818 of smart contract 704. Upon execution, token redeemer 818 implements a step 1002 that receives a transaction (e.g., one of transactions 708 of FIG. 7} with a request to redeem a requested number of tokens. Token redeemer 818 also implements a step 1004 that obtains from the transaction the address of the transaction sender. Token redeemer 818 also implements a step 1006 that uses the address of the transaction sender to determine if the transacti on sen der is a token holder. If the transaction sender is not a token holder, then token redeemer 818 continues to a step 1008 that returns an error and stops. If the transaction sender is one of the token holders, then token redeemer 818 continues to a step 1010 that accesses token registry 840 to determine if (1) the transaction sender has a token balance greater than or equal to the requested number of tokens, and (2) the requested number of tokens is less than or equal to the current redemption-slot allotment of the transaction sender (either priority slots or regular slots). If the transaction sender does not have a sufficient token balance or is attempting to redeem more tokens than currently allocated, then token redeemer 818 continues to a step 1012 that returns an error and stops. If the transaction sender has a sufficient token balance and is requesting to redeem an allowable number of tokens, then token redeemer 818 continues to a step 1014 that updates token registry 840 according to the redemption. For example, step 1014 may update token registry 840 by reducing the token balance of the transaction sender by the requested number of tokens, and increasing the number of redemptions of the tran saction sender by the requested number.

[0081 ] To complete redemption, token redeemer 818 implements a step 1016 that transfers cryptocurrency from the contract owner EOA to the EOA of the transaction sender. The quantity of cryptocurrency transferred may be determined by the number of redeemed tokens and the redemption value. If the redemption value is expressed in terms of an external currency that is not the native cryptocurrency of computing platform 701 (e.g., US $5.75), step 1016 may contact an oracle to determine a conversion factor between the native cryptocurrency and the external currency. Step 1016 may then use the conversion factor to determine the quantity of cryptocurrency to be transferred to the transaction sender.

[0Q82] In an alternative embodiment, the redemption value may be expressed in terms of shares of stock, which may further be of a particular class of stock of a respective issuing entity. For example, the stock may that of the token issuer. Alternatively, the stock may be that of an entity other than the token issuer. The token redeemer 828, at step 1016, may contact an oracle to obtain, instead of a eryptocurrency conversion factor, the current share price published by a mutually agreed upon resource. The share price may alternatively be a historical share price published by the resource a predefined time prior to the redemption request. Further still, the share price may be an average of the share price, published by the resource, over a predefined time period relative to the time of the redemption request.

[0083] FIG. 1 1 is a flowchart illustrating execution of regular-slot allocator 824 of smart contract 704. Regular-slot allocator 824 implements a step 1102 that receives a transaction (e.g., one of transactions 708 of FIG. 7) containing new regular-slot allotments. Regular-slot allocator 824 also implements a step 1 104 that compares an originating address of the transaction to owner address 848 to determine if the transaction originated from owner EOA 702(1). If tire addresses do not match, then regular-slot allocator 824 continues to a step 1106 that returns an invalid access error and stops. If the addresses match, then regular-slot allocator 824 continues to a step 1108 that checks active/passive status 852 to detemiine if tokens are active and thus redemption of tokens is permitted. If active/passive status 852 is equal to“passive”, then regular-slot allocator 824 continues to a step 1110 that returns an error and stops. If active/passive status 852 is equal to“active”, then regular-slot allocator 824 continues to a step 1112 that determines a number of unfilled slots remaining from the previous redemption period. For example, step 11 12 may calculate the number of unfilled redemption slots by subtracting a total number of redemptions, of die previous redemption period, from a total number of assigned redemption slots, of the previous redemption period. Regular-slot allocator 824 may also implement a step 1 114 that adds the number of unfilled redemption slots to the number of new redemption slots requested in the transaction to create a total number of redemption slots to be allocated. . Regular-slot allocator 824 may also implement a step 1116 that allocates the total number of regular slots to generate new regular-slot allotments. In one embodiment, step 1 1 16 allocates the total number of regular slots pro rata. FIG. 3 shows one example of step 11 16 allocating the total number of regular slots pro rata. Regular-slot allocator 824 may also implement a step 1122 that updates token registry 840 according to the new regular-slot allotments generated by step 1116. Step 1122 may reset the priority-slot allotments of all token holders to zero. Step 1122 may also reset the slot redemptions (e.g , priority-slot redemptions 110 of FIGS. 1-2, and regular-slot redemptions 310 of FIGS. 3-4) to zero.

[0084] In one embodiment, regular-slot allocator 824 implements a step 1126 that notifies die token holders about the new regular-slot allotments. Thus, die token holders are notified that they may be able to redeem tokens. Each notification may include a number of new redemption slots assigned to the notification receiver, and an expiration date of the current redemption period. In another embodiment, regular-slot allocator 824 implements a step 1 128 that notifies the contract owner (at owner address 848) that the new regular-slot allotments were successfully allocated.

[0085] After regular-slot allocator 824 successfully allocates the new regular-slot allotments, token holders may then redeem tokens b filling them into their newly assigned slots. When token holders redeem their tokens, token redeemer 818 updates token registry 840 of smart contract 704 accordingly. Thus, token redeemer 818 redeems a token holder filling either a priority slot or a regular slot.

[Q086] Token circulator 812 is implemented as machine-readable instructions configured to control at least one processor to circulate tokens to token holders (e.g., step 502 of method 500, and step 602 of method 600). Token generator 810 is implemented as machine- readable instructions configured control at least one processor to mint new tokens. Token circulator 812 may be configured to start and/or stop an ICO. Token circulator 812 may also execute token generator 810 to mint new tokens for circulating. Token generator 810 may update token registry 840 to reflect the newly-circulated tokens. Token generator 810 may also add new token holders to token registry 840 by adding a token holder identifier (e.g , token holder identifiers 104 of FIG. 1) for each new token holder. Token generator 810 and/or token circulator 812 may update circulation data 846 as newly-minted tokens are circulated.

[0087] Token activator 814 is implemented as machme-readabie instructions configured to control at least one processor to change active/passive status 852 from“passive” to“active” after the redemption condition has occurred. In one embodiment, token activator 814 is executed by an oracle that verifies, both offchain and independently of EGAs 702, that the redemption condition has occurred.

[0088] Token transfer agent 820 is implemented as machine-readable instructions configured to control at least one processor to update token registry 840 when a first token holder transfers a number of tokens to a second token holder. For example, token transfer agent 820 may reduce the token balance of the first token holder by the number of tokens, and increase the token balance of the second token holder by the number of tokens. If the second token holder is not included in token registry 840, token transfer agent 820 may add the second token holder to token registry 840 prior to increasing the token balance of the second token holder by the number of tokens. Token holder may also check that the first token holder has a sufficient token balance, i .e., the token balance of the first token holder is greater than or equal to the number of tokens to be transferred.

[0089] Constructor 808 is implemented as machine-readable instructions configured to control at least one processor when smart contract 704 is deployed on computing platform 701. Constructor 808 may be used to initially populate some of data 802, including token data 844, owner address 848, and redemption value 850. Constructor 808 may also set active/passive status 852 to“passive”. In one embodiment, constructor 808 initializes token registry 840 by' allocating some of contract storage 714 for storing token registry 840.

[0090] In the above examples, smart contract 704 is shown as a single smart contract. However, it should be appreciated that smart contract 704 may be implemented on computing platform 701 as several smart contracts, each with its own contract account. Different smart contracts may communicate with each other via messages, and some smart contracts may be configured to deploy and send messages to oilier smart contracts.

[0091] FIG. 12 is a functional diagram of an example computing device 1200 that communicates with smart contract 704 via a node 1250 of computing platform 701 Computing device 1200 includes a microprocessor circuit 1204 that processes data, a memory 1206 that stores instructions 1208 and data 1214, and a network adapter 1216 that communicatively couples computing device 1200 and node 1250. Microprocessor circuit 1204, memory 1206, network adapter 1216, and other components of computing device 1200 are communicatively coupled via a bus 1202. Computing device 1200 may be any of computing devices 706 of FIG. 7.

[0092] Node 1250 includes a node microprocessor circuit 1254 and a node memory 1256 that stores node instructions 1258, smart contract 704, a copy of bioekchain 716, and EGA data 1266. Node 1250 also includes a node network adapter 1270 that communicatively couples node 1250 and computing device 1200. Node microprocessor circuit 1254, node memory 1256, node network adapter 1270, and other components of node 1250 are communicatively coupled via a bus 1252.

[0093] Each of memory 1206 and node memory 1256 may include both volatile memory (e.g., RAM, SRAM, etc.) and nonvolatile memory (e.g., ROM, FLASH, hard drive, etc.). Instructions 1208 include machine-readable instructions that, when executed by processor 1204, control operation of computing device 1200. In FIG. 12, memory' 1206 is shown storing instructions 1208 that include a transaction generator 1210 and a transaction sender 1212. Memory 1206 is also shown storing data 1214 that includes a private key 1232 and a transaction package 1220 having a recipient address 1222, a sender signature 1224, cryptocurrency values 1226, a data field 1228, and a nonce 1230.

[0094] Node instructions 1258 include machine-readable instructions that, when executed by node processor 1254, control operation of node 1250. In FIG. 12, node memory_' 1256 is shown storing node instructions 1258 that include a transaction receiver 1260 and a transaction executor 1262. Transaction executor 1262 executes smart contract instructions 806 also to control operation of node 1250. Node instructions 1258 may further include instructions to update and maintain bioekchain 716 (e.g., mining new blocks, communicating blocks with other nodes, etc.).

[0095] Transaction generator 1210 is implemented as machine-readable instructions that control processor 1204 to populate transaction package 1220 with values for recipient address 1222, sender signature 1224, cryptocurrency values 1226, data field 1228, and/or nonce 1230. Transaction generator 1210 may query a user of computing device 1200 (e.g., via a graphical user interface (GUI) of computing device 1200) to enter an address (e.g., contract account address 720 of FIG. 7) for storing in recipient address 1222. The user may be, for example, one of the token holders or the token issuer. For example, the user may enter contract account address 720 as recipient address 1224, indicating that transaction package 1220 is intended for contract account 710.

[0096] Transaction generator 1210 may also populate one or snore cryptocurrency values 1226. For example, transaction generator 1210 may quer ' the user of computing device 1200 to enter one or more of cryptocurrency values 1226. In the example of Ethereum, cryptocurrency values 1226 may include an amount of ether to send to the recipient (i.e., the account at recipient address 1222), a GasPrice value representing a fee paid by the sender to the recipient per computational step performed by the recipient, and a StartGas value indicating a maximum number of steps the recipient is allowed to perform.

[0097] Transaction generator 1210 may also populate data field 1228 according to a desired functionality of smart contract 704. Thus, data field 1228 may contain values corresponding to function parameters that control execution of smart contract 704. In one embodiment, transaction generator 1210 queues tire user of computing device 1200 to determine how to fill data field 1228. For example, the user may indicate a request to redeem a number of tokens (e.g., step 1002 of token redeemer 818). In response, transaction generator

1210 may populate data field 1228 with two parameters, the first parameter chosen such that smart contract 704 executes token redeemer 818, and tire second parameter chosen to indicate the number of tokens to be redeemed. In certain embodiments, transaction generator 1210 uses an application binary interface to fill data field 1228.

[0098] Transaction generator 1210 may also communicate with node 1250 to retrieve a value for a nonce of the user’s EGA. Transaction generator 1210 may then populate nonce 1230 with a value one greater than the nonce of the user’s EGA, indicating that transaction package 1220 should be used to generate the next transaction initiated by the user’s EGA. After populating transaction package 1220, transaction generator 1210 may use private key 1232 to digitally sign transaction package 1220, thereby populating sender signature 1224. Private key 1232 may be stored as part of an Ethereum wallet file.

[0099] Transaction sender 1212 is implemented as machine-readable instructions that control processor 1204 to transmit digitally-signed transaction package 1220 to node 1250. For example, transaction sender 1212 may send digitally-signed transaction package 1220 over communication channel 1218 via network adapter 1216. Examples of communication channel 1218 include Ethernet, Wi-Fi, Bluetooth, ZigBee, and any of several cellular communication methods (e.g., 3G, 4G, LTE).

[0100] Transaction receiver 1260 is implemented as machine-readable instructions that control node processor 1254 to receive digitally-signed transaction package 1220 via communication channel 1218 and processes digitally-signed transaction package 1220 into transaction 1268. For example, transaction receiver 1260 may use a public key 1264 to verify sender signature 1224 to ensure that digitally-signed transaction package 1220 was generated by the owner of the EOA being accessed. Transaction receiver 1260 may also process cryptocurrency values 1226, as needed for executing transaction 1268.

[0101] Transaction executor 1262 is implemented as machine -readable instructions that control node processor 1254 to execute smart contract instructions 806 with transaction 1268. After smart contract instructions 806 have successfully executed, a state of computing platform 701 has changed into a new state, and node 1250 will attempt to incorporate the new' state and transaction 1268 into a new block for appending to blockchain 716.

[0102] In embodiments, transaction generator 1210 is configured to control processor 1204 to populate transaction package 1220 such that smart contract 704, in response to receiving transaction 1268 containing transaction package 1220, controls computing platform 701 to (i) allocate a distribution budget to a plurality of token holders based on sales of an asset during a period, and (ii) reimburse each token holder from the distribution budget based on a number of units of the asset utilized by said each token holder during the period. In one of these embodiments, transaction generator 1210 is configured to control processor 1204 to populate transaction package 1220 such that smart contract 704 controls computing platform 701 to allocate the distribution budget by generating a plurality of redemption slots, and reimburse each token holder by assigning a priority subset of tire redemption slots to each token holder based on the number of units of the asset utilized by said each token hol der during the period, and for each assigned redemption slot of each priority subset, redeeming one of the tokens when surrendered.

[Q1Q3] In other embodiments, transaction generator 1210 is configured to control processor 1204 to populate transaction package 122.0 such that smart contract 704, in response to receiving transaction 1268 containing transaction package 1220, controls computing platform 701 to disburse a remainder of the distribution budget to the plurality of token holders. In some of these embodiments, transaction generator 1210 is further configured to control computing platform 701 to disburse the remainder of the distribution budget by assigning a remaining subset of the redemption slots to each token holder, and for each assigned redemption slot of each remaining subset, redeeming one of the tokens when surrendered.

[0104] FIG. 13 show_'s computing device 1200 communicating with node 1250 to deploy smart contract 704 on distributed-ledger-based computing platform 701. In FIG. 13, computing device 1200 is shown storing data 1214 that includes private key 1232, smart contract code 1306, bytecode 3308, and a transaction package 1320. Computing system 1200 is also shown storing instructions 1208 that include a smart contract deployer 1304 implemented as machine -readable instructions configured to control processor 1204 to process smart contract code 1306 for execution on computing platform 701. In one embodiment, contract deployer 1304 converts smart contract code 1306 from a high-level language (e.g., Solidity ) into bytecode 1308, inserts bytecode 1308 into the data field of transaction package 1320 (e.g., data field 1228 of transaction package 1220 of FIG. 12), and sends transaction package 1320 to node 1250 via communication channel 1218. To cause node 1250 to deploy bytecode 1308, smart contract deployer 1304 may leave the recipient address of transaction package 1320 (e.g., recipient address 1222) blank.

[0105] In FIG. 13, transaction receiver 1260 processes the received transaction package 1320 into transaction package 1268, as described above in reference to FIG. 12. Transaction executor 1262, upon detecting tire blank recipient address in transaction 1268, generates a new contract account and stores bytecode 1308 as deployed smart contract 704 associated with the new contract account. Node 1250 may then notify other nodes of computing platform 1260 about the newly-generated contract account and smart contract 704 newly deployed therein.

[Q1Q6] Each of processor 1204 and node processor 1254 may include at least one central processing unit (CPU), graphics processing unit (GPU), digital signal processor (DSP), field-programmable gate array (FPGA), or other type of integrated circuit capable of performing logic, control, and input/ output operations. Each of processor 1204 and node processor 1254 may include a mixed-signal integrated circuit, such as a System-on-Chip (SoC) or microcontroller unit (MCU), that combines a processor, memory_', and input/output interfaces on a single chip. Each of processor 1204 and node processor 1254 may also include a memory controller, bus controller, graphics processing unit, and/or other components that manage data flow between microprocessor circuit 1204, memory' 1206, network adapter 1216 and other components communicatively coupled via bus 1202.

[0107] Additional Embodiments Applicable to Pharmaceuticals

[0108] Current mechanisms available for individuals to protect themselves against potential future needs for therapy associated with treating serious illness are inadequate. Further, health insurers have few options against these costs oilier than distributing risk across a large and diverse number of co vered lives. Accordingly, health insurance premiums escalate, underscoring the fact that risk for the sector is not adequately managed.

[0109] According to one aspect, a solution is grounded in novel technical implementation of a treatment allotment digital token. According to one embodiment, by launching a digital utility token that can be used to offset the cost of future therapy, various embodiments introduce both a vehicle to obtain allocations for treatment and a vehicle for risk management for individuals and insurers. According to one aspect, the inventors have realized a unique and unconventional approach to securing treatment shares or portions either in the context of experimental treatment or in the context of approved treatment. Digital tokens can be encoded to specific beneficiaries and mapped to specific treatment allocations or allotments. Investors can trade these treatment redemption vehicles when the costs are low (e.g , prior to approval) and hedge against future need for expensive treatment (e.g., for themselves or a beneficiary they chose to designate).

[0110] In further aspects, the system encoded digital tokens and the underlying distributed blockchain can be used for approved therapeutics and diagnostics. According to one embodiment, the token is the currency that enables access to an ecosystem of health-related services. Just as a ticket to an amusement park enables access to rides, the token is a ticket to specialize treatment and diagnostic resources. In additional embodiments, the tokens and provable encoding of the distributed blockchain enables a high-trust exchange, preventing “scalping” and potentially eliminating the need for insurance companies altogether - revolutionizing health care delivery.

[0111] According to various embodiments, a digital token (including, for example, a Royalty Fragment Security Token, also referred to as an“RFST”) is provided that enables the following options: manage treatment resource allocation (e.g., cost) associated risks at the individual patient level through a system of tradable allotments (e.g., treatment portions and/or discounts); bypass established pharmaceutical product distribution networks based on an established direct relationship between therapeutic drug developers and token holders; define a new resource allocation (e.g., including) and/or financing mechanism for development of therapeutic drugs; for example, tokens (e.g., RFSTs) are exchangeable for designated access to therapy under associated conditions specified as part of the token or utility rights (for example, with Agenus’ proprietary therapeutic candidate which could be designated AGEN0001) (in such example the utility rights for an Agenus token can be referred to as“RFST Utility Rights”) if the following are met: AGEN0001 is approved for use humans by the US FDA, for treatment of one or more designated diseases or conditions (approved indications); a treating physician makes the determination that a patient could benefit from treatment with AGEN0001; and the patient is designated as the beneficiary_' of the token (e.g., RFST) utility rights by a holder of the requisite number of tokens); and tokens (e.g., RFSTs) can be exchanged openly as Ethereum-based tokens on an electronic exchange provided by the system. The current marketplace and conventional approaches do not provide for such functionality.

[0112] FIG. 14 is a block diagram of an example token allotment system 1400 that accesses, exchanges, and triggers redemption of treatment allotment tokens. In various embodiments, token allotment system 1400 includes separate components tailored to specific functions of the allotment system. At least some of the components of token allotment system 1400 are discussed below to provide examples. In other embodiments, token allotment system 1400 can he configured to execute the same functionality without instantiating the separate components.

[0113] According to one embodiment, token allotment system 1400 includes a token encoder component 1402. Token encoder component 1402 is configured to use a digital token platform (e.g., ETHEREUM, BITCOIN, B!TCOIN CASH, etc.) to encode a treatment allotment token. According to various examples, each token is encoded to be a portion of a treatment (e.g., product or treatment session). Multiple tokens can be used to redeem a treatment session or multiple tokens can be redeemed to cover portions of multiple sessions. As discussed in greater detail below, the information encoded with each token can depend on the type of token being issued. For example, passive tokens are associated with treatment options that are not yet approved for use. According to one embodiment, these passive tokens only include information needed to purchase or exchange the tokens. Once a treatment is approved, the system is configured to manage issuance or exchange of active tokens for passive tokens, where additional information (e.g., treatment information and/or designation of beneficiary_' for redemption, prescription information, etc.) can be included and encoded with the active token.

[0114] According to various embodiments, active tokens (e.g., RFSTs) are instantiated with a default status in which a product and beneficiary association are undefined. The system is configured to execute a token reset operation that is configured to change the state of active tokens (e.g., RFSTs) to their default status. For example, once passive tokens are exchanged for active tokens, the system can be configured to associate specific tokens with their respective approved treatment (e.g., the system can associate the active tokens with AGEN0001 ). In other embodiments, the active tokens can be issued with the associations to the respective treatment. Various embodiments are configured to support multiple token lines where each token line is tied to a specific treatment. The multiple token line approach (e.g., a token line can have a passive set of tokens that can evolve into an active set of tokens or can be issued as active tokens initially) enables creation and use of additional tokens with different product associations and/or treatment profiles as newer approaches are defined and/or approved.

[0115] In some embodiments, the system can include functions for coin“mining.” Some value can be assigned to operations that generate the underlying coins and/or specific encodings for them. In some embodiments, token allotment system 1400 can execute functions to accept newly mined coins by end users solving problems associated with defining new tokens in one embodiment, the token encoder component can be configured to manage mining functions, and/or tying newly minted tokens to specific treatment encodings (e.g., specific treatment allotment, designated treatment facility, doctor validator (e.g., test valid prescription, etc.). The token encoder component can also he configured to manage exchange of passive tokens for active tokens.

[0116] According to various embodiments, token allotment system 1400 can be configured to issue two series of treatment tokens for a specific treatment option. The first series of tokens are passive - in that the passive tokens do not include the smart contract encoding that limit redemption of treatment. For example, treatments that are not yet approved (e.g., for human application) cannot be redeemed, and the associated tokens represent the option of redeeming a treatment allocation should the treatment receive approval for use (e.g., in humans). Once approval has been obtained the system manages the exchange of passive tokens for active or redeemable tokens.

[0117] In further embodiments, token allotment system 1400 can include a token allocation component 1404 configured to manage exchange of the allotment tokens. In some embodiments, token allocation component 1404 can manage a fixed pool of allotment tokens. In other embodiments, token allocation component 1404 can be configured to manage a dynamic pool (e.g., growing or shrinking) of allotment tokens. For example, treatment resources are typically limited, especially at the beginning of a new treatment option or just after approval. The token pool can be adjusted to the expected volume of available treatment resources, or in some examples, the amount of expected resources can exceed initial expectation and the token pool can be expanded accordingly.

[0118] In various embodiments, token allotment system 1400 can be configured to support multiple tokens offerings with each offering associated with a specific treatment option. In some implementations, the treatment offering is in a development phase or pre- approval. Thus, the opportunity exists to capture treatment allocations at marked discount based on the speculative nature of the treatment option. In further embodiments, treatment tokens may be exchanged for tokens associated with other treatment options, facilitating a thriving marketplace for distribution and exchange of treatment tokens.

[0119] According to some embodiments, token allotment system 1400 can include a token redemption component configured to manage redemption of tokens for actual treatment. For example, the redemption component can he configured to manage designation of beneficiary and/or assignment of utility. In on example, the designation is controlled based on provable encoding associated with each redeemable token. In some embodiments, to designate a patient as the beneficiary (e.g , 1414) of the utility rights (e.g., RFST utility), a holder (e.g , individual 1408 or institution or entity 1410) of the tokens (e.g., RFSTs) accesses the system hosted exchange to“put” the tokens back to issuer, along with securely encrypted identifying information (e.g., specifying patient secure information) for the beneficiary_' (e.g., 1414).

[0120] According to various embodiments, based on the encoding of the token, tire issuer is given no access to any patient information or corresponding security key - thus the allocation system is able to preserve security and secrecy in manner other conventional approaches cannot achieve. In some embodiments, the encrypted information encoded on the token is made available to the treating physician (e.g., 1412) - enabling association with the request for the underlying treatment (e.g., AGEN0001) when a prescription is issued.

[0121] According to another embodiment, the token redemption component is configured to verify prescription information associated with tire designated beneficiary. In one example, token allotment system 1400 requires that a redeemable token be encoded with provable information associated with a prescribed treatment (e.g., by a prescribing physician, etc.) to allow verification.

[0122] For example, when a prescription for an underlying treatment (e.g., AGEN0001) for treatment of a beneficiary is sent to a hospital pharmacy or filled in an outpatient oncology clinic treatment center, the prescribing physician can include the encrypted information (e.g , patient secure information) with the request for the product. According to another aspect, patient secure information is encoded to allow the pharmacy to request treatment or product directly from an issuer for the beneficiary' bypassing any distributor network (e.g., and without accessing any AGEN0001 inventory_' already purchased). Such operations can be managed by the token redemption component 1406.

[0123] Example Logic Flow: Prescription Trigger Event for Assignment of Benefit

[0124] According to one embodiment, if the benefactor and beneficiary are the same individual (self-assignment), or if the benefactor is a payer organization and the beneficiary' is a patient covered by one of tire payer's health insurance plans, the treating physician's act of prescribing a treatment associated with a token (e.g., AGEN0001 ) can be the trigger 5 event for assignment of benefit (“Prescription Trigger”). If the benefactor and beneficiary are two different individuals (e.g., a family member and a relative), HIPAA compliance and established medical practice prevents the benefactor from having direct access to the patient's prescription information without the latter’s consent. To enable token utilization in this situation, the benefactor may propose the benefit to an individual (“Benefit Candidate”) and the system can manage messaging to the benefit candidate to collect needed information for tying redemption to the patient and/or prescription information needed. For example, the benefit candidate can used the system (e.g., token allotment system 1400) to accept such benefit. The benefit candidate can provide and have encrypted information establishing the prescription trigger, at which point the benefactor could proceed with the assignment of benefit or the system can confirm candidate supplied information to encode the token to the selected candidate. Acceptance of the Benefit would include de facto agreement of health information disclosure (or specific disclosure requests can be displayed by the system when a candidate accesses the system to provide information) to the benefactor because it would imply the recipient has a medical condition that led their treating physician to prescribe the treatment (e.g., AGEN00G1 ).

[0125] According to various embodiments, token allotment system 1400 is configured to require a token reset action in order to change an encoded beneficiary (e.g., the system checks if a benefit status for a token is active). For example, once the benefit status for an active token is set, the token (and designated beneficiary) can only be changed through a token reset operation on the system via administration action.

[0126] In one example, execution of beneficiary assignment can include a request for a beneficiary designation assigned by token allotment system 1400 and/or token allocation component 1404. In some examples, the request can include a token status update operation in conjunction with the beneficiary designation. For example, to designate a patient as the beneficiary' of the token (e.g., FST utility), a holder of a threshold number (e.g., 50, 60, 70, 80, 90, 100 or more) of active tokens (e.g., active RFSTs) subnuts a request through the system for a unique encrypted identifier code (e.g., beneficiary code).

[0127] According to some embodiments, token allotment system 1400 can provide this code or generate this code (e.g., an encryption of patient secure information), as the issuer (e.g., the party responsible for providing treatment) is set up to have no access to any patient secure information. For example, the system can provide or execute an application configured to assign the benefactor’s active token with this code. In some example, the application is configured to assign beneficiaries to redeemable lots of tokens (e.g., the application can operate on lots of 50, 60, 70, 80, 90, 100 or more active tokens).

[0128] Token allotment system 1400 may also be configured to make the beneficiary code available for redemption of the treatment. For example, once the status of the benefactor’s tokens are updated on the system, the system is configured to communication the beneficiary- code to the beneficiary (e.g., the patient) so that that beneficiary code can be provided to the treating physician. In other examples, the system can he configured to communicate the beneficiary code to the treating physician as well. Token allotment system 1400 may be further configured to request inclusion of prescription information, which can be provided from the beneficiary or from the treating physician.

[0129] Example Process Flow : Prescription Verification

[0130] According to some embodiments, token allotment system 1400 is specially configured to validate prescribing information to ensure compliance with health regulation and/or state or local law. For example, according to Massachusetts state law, a prescription for a controlled substance should include: 1) registration number of practitioner; 2) date of issuance of tire prescription; 3) name, dosage, and strength per dosage unit of the controlled substance prescribed, and the quantity of dosage units; 4) name and address of tire patient; 5) directions for use, cautionary statements; and 6) number of refills. Any one or more or any combination of the preceding information requirements can be encoded as part of a token.

[0131] According to further embodiment, token allotment system 1400 is configured to avoid release of product for use outside of relevant jurisdictions (e.g., United States). For example, the system can be configured to require a valid registration number of a practitioner in order to permit product release. In one embodiment, token allotment system 1400 can be configured to prevent redemption absent a valid registration number and a beneficiary code. In various embodiments, the system is configured to limit information accept by the system as part of redemption to: 1) valid registration number of a practitioner and 2) a beneficiary_' code. In these embodiments, token allotment system 1400 is configured to limit access to sensitive patient information in further embodiments, token allotment system 1400 can require a treatment location where treatment will be performed or dispensed to a patient. Where token allotment system 1400 detects a blank or invalid practitioner registration number, ail tokens that have the corresponding patient identifier are subject to a token reset automatically.

[0132] Example Process Flow: Product Release

[0133] According to one embodiment, token allotment system 1400 is configured to manage a certain amount of inventory for direct distribution to treatment facilities (e.g., hospital or oncology clinic pharmacies) in response to requests for treatment of beneficiaries. For example, release of AGEN0001 can be managed by token allotment system 1400 based on veri fication that the beneficiary code provided by the requesti ng pharmacy match es one of the entries in the beneficiar ' code database. The beneficiary code database can be updated as active tokens are entered into the redemption procession (e.g., the database can be updated as RJFSTs are redeemed).

[0134] Various embodiments provide for alternate fulfillment, for example, from distributor inventory'. Where token allotment system 1400 is managing an inventory that is insufficient to meet direct demand for product for a beneficiary, the system can coordinate fulfillment of the prescription by a hospital or an oncology treatment center pharmacy using available inventory at that location (e.g., using AGEN0001 inventory' in place) at the time the prescription is received. Further embodiments are configured to manage batch prescription fulfillment. For example, based on system controls and input from the benefactors and the patients, token allotment system 1400 may be configured to manage the fraction of the total amount of treatment prescribed that is available through redemption of tokens (e.g , RFSTs), where the remaining balance of the treatment (e.g., product) can be accessed through existing fulfillment channels.

[0135] According to some aspects, the redemption tokens may have variable value in terms resource required to acquire or exchange. Notably, tokens may be acquired at early phases of a treatment development and or vetting cycle. For example, the value of RFSTs may increase (e.g., as AGEN0001) as the treatment option progresses through clinical development and regulatory' approval. In various examples, participants may choose to buy and sell RFSTs based on expectations of changes in value. In various embodiments, token allocation component 1404 is configured to execute the functions associated with token exchange. In some embodiments, the allocation system and/or token allocation component can be connected to an online exchange site that provides the functionality for accepting bids, asks, puts, or other exchange options. Token allocation component 1404 can manage any updating and/or publication of proof informati on needed as part of any exchange or purchase of a token.

[0136] Accordingly, it is realized that the underlying token are not a form of insurance. Rather, under expected operation, individuals or entities may acquire RFSTs as an investment, or hold several RFSTs for possible redemption against access to therapy for themselves or a family' member. Additionally, insurers may' also purchase RFSTs on the open market, initially' from the provider or the provider's shareholders (e.g., Agenus) in one example, to mitigate the impact of reimbursement of immuno-oncology therapies as treatment for some of their covered lives.

[0137] According to one aspect, rights to designate someone as beneficiary of the RFST utility rights and potentially receive treatment with AGEN0001 are gated as part of the encoding of the redemption token - and, for example, are only executable after AGEN0001 is approved by FDA or other drug regulatory authorities or medicines regulatory authorities (e.g., EMA, Health Canada, AN VISA, etc.) for treatment of a disease or medical condition in human subjects.

[0138] According to another aspect, various features support token redemption and/or exchange. In one example, designation of beneficiary and/or assignment of utility is controlled based on provable encoding associated with each redeemable token. In one example, to designate a patient as the beneficiary of the RFST utility, a holder of RFSTs uses the system hosted exchange to“put” the tokens back to issuer, along with securely encrypted identifying information (e.g., including patient secure info) for the beneficiary .

[0139] According to one embodiment, based on the encoding of the token, the issuer is given no access to any patient information or corresponding security key preserving security and secrecy in manner other conventional approaches cannot achieve. In some embodiments, the encrypted information encoded on the token is made available to the treating physician - enabling association with the request for the underlying treatment (e.g., AGEN0001) w'hen a prescription is issued.

[0140] According to another embodiment, the redeemable token is further configured to enable prescription verification. For example, when a prescription for treatment (e.g., with AGEN0001) of a beneficiary is sent to a hospital pharmacy or filled in an outpatient oncology clinic treatment center, the prescribing physician can include the encrypted information (e.g., patient secure information) with the request for the product. According to another aspect, patient encrypted information is encoded to allow the pharmacy to request treatment or product directly from an issuer for the beneficiary bypassing any distributor network (e.g., and without accessing any AGEN0001 inventory already purchased).

[0141 ] According to various embodiments, token allotment system 1400 is configured to manage a certain amount of inventory for direct distribution to hospital or oncology clinic pharmacies in response to requests for treatment of beneficiaries. For example, release of AGEN0001 is managed according to verification that the patient secure information provided by the requesting pharmacy matches one of the entries in the patient secure information database (e.g., updated as RFSTs are redeemed). [0142] In further embodiments, token allotment system 1400 can also be configured to manage insufficient inventory to meet direct demand for product for a designated beneficiary. For example, the system can manage prescription filling or treatment execution by another hospital or oncology treatment center pharmacy using inventory (e.g , AGENQ0Q1 ) in place at the time the prescription is received.

[0143] According to some embodiments, token allotment system 1400 can require the beneficiary provide patient secure information that allows an insurer to manage reimbursement or alternately in the event the beneficiar does not have appropriate insurance coverage, directly to the provider (e.g., Agenus), for corresponding rebate of the net price.

[0144] Execution Flow Examples: Product Substitution, Stacking and Unlocking

Additional Tokens

[0145] Various offerings/token lines are associated with experimental therapeutic agents (e.g., AGEN0001), and specifically for which there is no guarantee of successful development and approval by FDA. In the event it is determined that successful development and registration of the treatment is no longer possible, token allotment system 1400 can be configured to substitute a different agent from available treatment options (e.g., from a portfolio of experimental therapies) as the potential product to which beneficiaries would be granted access based on token utilization rights (e.g., RFST utility rights).

[0146] According to some embodiments, token allotment system 1400 can be configured to manage a product substitution by exchanging active or passive tokens associated with a first treatment (e.g., AGEN0001) with passive tokens associated with a new product or treatment. As discussed above, newly issued passive tokens are exchangeable for active tokens at the time the new product is approved.

[0147] According to further embodiments, existing token holders can be given access to developmental pipelines for new treatments. For example, based on prior support, holders of tokens (e.g., RFSTs) that have not been redeemed after product approval can be issued additional passive tokens (e.g., passive tokens) against future products. In some example, the ratio of newly issued tokens can be on a one-to-one basis, or on any percentage desirable to an issuing entity, as they advance any product development pipeline. Various experimental treatments and/or product pipelines can be tied to tokens, and include for example, antibody therapies (e.g., which could be designated AGEN0002), vaccine therapies (e.g., which could be designated AGEN0003), and/or other therapies.

[0148] According to one aspect, each additional product against which a holder of a token is issued can be issued additional tokens that represent further upside for the holders of unredeemed tokens. According to one example, someone who holds RFSTs through approval of AGEN0001, AGEN0002 and AGEN0003 would be able to redeem or monetize RFSTs for the equivalent value of one dose of therapy of each product for each 100 RFSTs. Over the course of development and approval, a $15 investment in the initial AGEN0001 RFST could be worth as much as ~$300 of therapy (20x) post approval.

[0149] FIG. 15 shows a value ladder that illustrates one example of issuance of additional tokens to holders of active tokens. The example shown can be extended generally to any treatment/product associated token.

[0150] According to some embodiments, the additional tokens can be made available to participants in one or more token offerings in exchange for participation in various additional information collection programs.

[0151] FIG. 16 is a flowchart illustrating one example method 1600 that allows participation in an allotment token exchange. Method 1600 includes a step 1602 that vets investors. According to one embodiment, step 1602 is executed by the provider of the treatment. In one example, the treatment provider (e.g., 1604 - Agenus) can establish qualification rules and publish the same to candidate investors. At step 1606, once an initial set of investors is identified and vetted, the treatment tokens can be established for trading. In one example, the allocation pool of treatment tokens is set at five million tokens with an initial declared value of fifteen dollars and a pool of four million purchasable tokens.

[0152] As part of establishing treatment tokens, step 1606 can include initializing an empty affiliates list and non-affiliates list to manage potential token holders. In further embodiments, step 1606 can include initialization of a balance list to which the tokens are assigned and distributed from. In one example, the provider (e.g., Agenus) can have a respective wallet to which all the tokens are initially assigned (e.g., at step 1606).

[0153] Method 1600 includes a step 1608 that populates two lists of Ethereum wallet addresses. The vetted investors are assigned to respective lists based on whether they are an affiliate (1610 YES) or not (1641 NO). Each assignment/list can include an optional trading freeze period - e.g., six months for affiliates and twelve months for non-affiliates (e.g., at steps 1612-1614). In other embodiments, different time periods for a trading freeze can be implemented, including no freeze period.

[0154] FIG. 17 is a flowchart illustrating another example method 1700 that allows participation in an allotment token exchange. Method 1700 begins at a step 502 with a confirmation that an entity can participate in a token exchange program (e.g., invest in a token line tied to a prospective treatment option). Investors 1704 access the system to send ether to token addresses (e.g., at 1706 ether is sent to an RFST Ethereum address). If the investor is vetted 1708 YES, the system manages the ether token exchange based on retrieving a dollar to ether value and issuing a corresponding number of tokens based on a current rate for the specific token (e.g., at 1710). If the investor is not vetted (not shown), the system can decline the transaction and request the investor provide information for vetting. At 1712, tokens (e.g., RFST tokens) are sent to the investor’s wallet.

[0155] Method 1700 may also include investor-to-investor exchange. For example, at a step 1714 an investor may accept a request to trade with another investor. If accepted, ether is sent to the token holder (e.g., at 1716). Method 1700 may include validation that the investor’s (purchaser’s or seller’s) wallet is not frozen (e.g., at step 1718). An additional check can be executed to validate that the investors are vetted (e.g., at step 1720). Once a trade is confirmed at step 1722, the token is communicated to the requesting investor at step 1724.

[0156] FIG. 18 is a functional diagram of one example allotment system 1800. Allotment system 1800 can be used by a treatment provider/developer (e.g., Agenus 604) to make allotment tokens available to a group of investors (e.g., vetted investors 1806). In one embodiment, a central exchange 1802 can be accessed over a communication network (e.g., the Internet) and host a platform for purchasing and exchanging any one more allotment tokens. The exchanges instantiates and maintains a wallet of tokens being issued by a provider at 1808 (e.g., Agenus). Exchange 1802 allows two types of investors to purchase or exchange the tokens. For example, exchange 1802 moderates purchases by affiliates and non-affiliate investors, which can include prohibiting re-sale by either group for specified periods of time. According to one embodiment, the wallet of tokens includes specification of the smart contract under which redemption and validation will take place, as well as the specification of the number of tokens available in the pool (e.g., at 1810). In some examples, the wallet can be configured with a token reserve of a percentage of the token pool to ensure liquidity and fulfillment.

[0157] During token exchange or purchase, allotment system 1800 can execute queries to establish an exchange rate, for example ether to dollars at 1812. Ethereum blockchain is used by the system record and validates transactions, such that once a transfer or purchase is executed the token itself can be used to prove the validity of the exchange. Exchange 1802 is configured to host a wallet 1816 for the investors (e.g., vetted investor). Non-vetted investors may be allowed to access exchange 1802, however various embodiments are configured to limit participation by non-vetted investors. For example, at 1818 non-vetted investors can be prevented from purchasing or exchanging tokens until vetting is complete. [0158] FIG. 19 is a flowchart illustrating one example method 1900 that manages a digital token. Method 1900 begins at step 1902 with approval of a treatment or diagnostic being managed (e.g., by an allotment or token management system). Once a treatment or diagnostic is approved, the treatment or diagnostic is configured to execute a number of functions. In this embodiment, the system provider and treatment provider or diagnostic provider can be the same (e.g., provider 1904). In other embodiments, the entity responsible for the system can be different from the entity responsible for the treatment, product, or diagnostic that is associated with respective tokens. At step 1906, the smart contract specifying the terms of redemption is deployed. In some examples, this includes setting a cap for the treatment, product, or diagnostic inventory. In further examples, a cap can also be established for a number of assignable doses or portions of a treatment. An initial price can also be set as part of step 1906.

[0159] According to various embodiments, initial operations include any one or more of the following options, including any combination and/or all of the following: a) initialization of an empty beneficiaries lists; b) initialization of an empty beneficiary-prescription list; c) initialization of an active balance list wiiere all tokens are initial assigned to the system or treatment manager wallet; d) initialization of an empty assigned token wallet; and e) initialization of an empty doses balance list.

[0160] FIG. 20 is a flowchart illustrating one example method 2000 that manages tokens with a token platform. For example, investors can be vetted and approved prior to participation in the exchange platform for treatment tokens. In one embodiment, an investor receives a system-generated confirmation message that he/she is able to start trading respective treatment tokens at 2002 In further embodiments, investors can be vetted by the system to participate in specific or limited groups of treatment tokens (e.g., the system can create approvals to participate based in individual treatments). At 2004 investors access the token platform and being trading. Initially, a new line of treatment tokens (e.g., tied to an experimental treatment) is defined and assigned to the system host wallet or a wallet for the treatment entity. As investors purchase tokens or trade tokens (e.g., RFST tokens, any AGENxxxx token line, or any provider line) with other investors, the tokens are sent to respective investor wallets (e.g., at 2006 and 2008). For tokens associated with an approved treatment, method 2000 also provides functionality to assign a beneficiary to a token and the associated redemption (e.g., for treatment (e.g., AGEN designated treatment or any other treatment associated with the token) at 2010. Token assignment can include at 2012 an attempt to assign a beneficiary to any token. For token lines where treatment portions are broken down into 100 token per treatment, method 2000 can include a check if the tokens to be assigned are in a group or multiple of 100. In other embodiments, different token-to-treatment ratios can be used and evaluated (e.g., at 2014).

[0161] Method 2000 continues with a step 2016 that implements a check that the designated beneficiary is valid (e.g., has prescription for the treatment, has consented to use of information (potentially including medical information), beneficiary registered in the system, etc.). Once determined valid the system can encode tokens (e.g., tied to specific treatment) to a specific beneficiary at 2018. As part of tying the beneficiary to the token, the system generates a unique encrypted identifier code that is made part of the token encoding at 2020. Method 2000 may include investor-to-investor trading of tokens (e.g., at 2022). In order to trade a token, an investor sends a request to trade, for example, based on an offer of ether set to another investor’s wallet at 2024. Method 2000 checks if the tokens being exchanged are not assigned to a beneficiary at 2026. If the tokens are assigned the system generates an error and informs the would-be traders that a token reset operation is required to remove a beneficiary' from the tokens prior to exchange. Once a token reset is completed by the current holder, the tokens can be traded freely. If the tokens are not assigned to a beneficiary, method 2000 includes a validation check of the trading parties (e.g., test if both investors are vetted at 2028). Where both investors are not vetted, the system can deny the transaction or check to determine that an appropriate waiting period has passed before allowing the exchange. If the investors are vetted and the trade is accepted (e.g., accepted to trade at 2030), then the token is sent to the request investor’s wallet at 2032.

[0162] Method 2000 also includes operations for verifying a beneficiary code and redeeming an associated treatment and/or product. The token holder may be the beneficiary, and in other examples the token holder can designate a beneficiary to receive the treatment and/or product associated with the token. At redemption, the token is accessed to verify an encoded beneficiary_' code at 2034. Once verified (e.g., confirmed to identify one or more and any combination of: a patient, a prescription, a facility, a doctor, a prescribes etc.) an associated amount of product or treatment is provided (e.g., return number of doses at 2036). Partial allotments may also be redeemed, where the beneficiary or a responsible party provide for any difference between the redeemable amount and the remainder at the time of delivery .

[0163] FIG. 21 is a flowchart illustrating one example method 2100 that redeems treatment or product associated with tokens. At 2102 the system receives information regarding a potential redemption. For example, the system can receive an order for doses of a treatment, communicated by a pharmacy or physician. In various embodiments, the system is configured to validate a valid registration number of the pharmacy and/or prescribing information of the physician as part of method 2100 According to various embodiments, the request (e.g., received at 2102) includes a beneficiary code that must also pass validation. A provider 2104 performs the validation operations and assuming a valid request, the system applies the beneficiary' code to release an allocated number of doses to the beneficiary (e.g., at 2106). The number of allocated doses can vary based on the token line, the associated treatment, and/or based on a specified redemption ratio defined with the encoding of the digital token. In some embodiments an optional test includes determining that the request originated from the system at 2108 (e.g , Provider (e.g., Agenus)), and that the beneficiary code is valid at 21 10.

[0164] If either check does not pass, the process ends. The initial request may specify a number of doses, in which case the system confirms that the beneficiary is entitled to redeem the requested number of doses at 21 12 Depending on the redemption ratio for the token a number of tokens is removed from the beneficiary’s assigned tokens at 2114 (for example, from a token holder’s wallet). The system can be configured to maintain a doses balance list, and in these embodiments, the doses balance list is updated to reflect the redemption as part of 21 14, and the associated (e.g., active) tokens are removed from the investor’s wallet. According to one embodiment, once the system operations to audit the redemption are complete, the product is released at 2116 for use by the beneficiary.

[0165] FIG. 22 is a flowchart illustrating one example method 2200 that resets a token having an assigned beneficiary'. According to one embodiment, method 2200 begins with a reset request at 902 communicated to the system (e.g., the Provider (e.g., Agenus) at 2204). A reset is executed against a designated number of tokens, or in some examples, all the tokens, in the token holder’s wallet. For example, at 2206, X tokens are reset or re-encoded such that no beneficiary is associated with the digital token. At 2208 validation is executed, wherein the reset tokens are analyzed to confirm no beneficiary is assigned. If the validation fails an optional force un-assignment operation takes place. In one example, the force un-assignment includes removing tokens from the beneficiary’s assigned token list, and re-issuing passive tokens in exchange for the active tokens being reset at 2214. Various approaches can be executed for the reset operation. In one example, passive tokens may be used to replace active tokens in an investor’s wallet, and active tokens may be issued when that investor requests a function to assign a beneficiary'. In other embodiments, steps of method 2200, as shown in FIG. 22, can be executed together or some steps may be omitted.

[0166] FIGS 19-22 illustrate processes and functions with an example token associated with an example treatment (e.g., RFST). Other embodiments link other treatments to other sets of tokens that may be exchanged using the system. The processes shown in FIGS. 19-22 can be executed on different token lines and different respective treatments or products. In yet other examples, tire tokens can be linked to diagnostics or products (e.g., having limited supply) and the token exchange and beneficiary designation can be used to establish a provable distribution mechanism that is able to avoid pitfalls of conventional approaches. In some examples, the token exchange and beneficiary designation/validation operations can eliminate third party insurers from die medical distribution entirely.

[0167] Various aspects and functions described herein may be implemented as specialized hardware or software components executing in one or more specialized computer systems. Further, aspects may be located on a single computer system or may he distributed among a plurality of computer systems connected to one or more communications networks. For example, various aspects, functions, and processes may be distributed among one or more computer systems configured to provide a service to one or more client computers, or to perform an overall task as part of a distributed system, such as a distributed computer system 2300 shown in FIG. 23. Additionally, aspects may be performed on a client-server or multi- tier system that includes components distributed among one or more server systems that perform various functions. Consequently, embodiments are not limited to executing on any particular system or group of systems. Further, aspects, functions, and processes may be implemented in software, hardware or firmware or any combination thereof. Thus, aspects, functions, and processes may be implemented within methods, acts, systems, system elements and components using a variety of hardware and software configurations, and examples are not limited to any particular distributed architecture, network, or communication protocol.

[0168] FIG. 23 is a block diagram of one example distributed computer system 2300 in w'hich various aspects and functions are practiced. As shown, distributed computer system 2300 includes one or more computer systems that exchange information. More specifically, distributed computer system 2300 includes computer systems 2302, 2304, and 2306. As shown, computer systems 2302, 2304, and 2306 are interconnected by, and may exchange data through, a communication network 2308. Network 2308 may include any communication network through which computer systems may exchange data. To exchange data using network 2308, computer systems 2302, 2304, and 2306 and network 2308 may use various methods, protocols and standards, including, among others, Fiber Channel, Token Ring, Ethernet, Wireless Ethernet, Bluetooth, IP, IPV6, TCP/IP, UDP, DTN, HTTP, FTP, SNMP, SMS, MMS, SS3, ISON, SOAP, CORBA, REST, and Web Sendees. To ensure data transfer is secure, computer systems 2302, 2304, and 2306 may transmit data via network 2308 using a variety of security measures including, for example, SSL or VPN technologies. While distributed computer system 2300 illustrates three networked computer systems, distributed computer system 2300 is not so limited and may include any number of computer systems and computing devices, networked using any medium and communication protocol.

[0169] As illustrated in FIG. 23, computer system 2302 includes a processor 2310, a memory 2312, an interconnection element 2314, an interface 2316 and data storage element 2318. To implement at least some of the aspects, functions, and processes disclosed herein, processor 2310 performs a series of instructions that result in manipulated data. Processor 2.310 may be any type of processor, multiprocessor or controller. Example processors may include a commercially available processor such as an Intel Xeon, Itanium, Core, Celeron, or Pentium processor; an AMD Opteron processor; an Apple A4 or A5 processor; a Sun UltraSPARC processor; an IBM Power5+ processor; or an IBM mainframe chip. Processor 2310 is connected to other system components, including one or more memory devices 2312, by the interconnection element 2314.

[0170] Memory 2312 stores programs (e.g., sequences of instructions coded to be executable by processor 2310) and data during operation of computer system 2302. Thus, memory 2312 may be a relatively high performance, volatile, random access memory such as a dynamic random access memory (‘DRAM”) or static memory (“SRAM”). However, memory 2312 may include any device for storing data, such as a disk drive or other nonvolatile storage device. Various examples may organize memory 2312 into particularized and, in some cases, unique structures to perform the functions disclosed herein. These data structures may be sized and organized to store values for particular data and types of data.

[0171] Components of computer system 2302 are coupled by an interconnection element such as the interconnection element 2314. Interconnection element 2314 may include any communication coupling between system components such as one or more physical busses in conformance with specialized or standard computing bus technologies such as IDE, SCSI, PCI and InfiniBand. Interconnection element 2314 enables communications, including instructions and data, to be exchanged between system components of computer system 2302.

[0172] Computer system 2302 also includes one or more interface devices 2316 such as input devices, output devices and combination input/output devices. Interface devices 2316 may receive input or provide output. More particularly, output devices may render information for external presentation. Input devices may accept information from external sources. Examples of interface devices include keyboards, mouse devices, trackballs, microphones, touch screens, printing devices, display screens, speakers, network interface cards, etc. Interface devices allow computer system 2302 to exchange information and to communicate with external entities, such as users and other systems.

[0173] Data storage element 2318 includes a computer readable and writeabie nonvolatile, or non-transitory, data storage medium in which instructions are stored that define a program or other object that is executed by processor 2310. Data storage element 2318 also may include information that is recorded, on or in, the medium, and that is processed by processor 2310 during execution of the program. More specifically, the information may be stored in one or more data structures specifically configured to conserve storage space or increase data exchange performance. The instructions may be persistently stored as encoded signals, and the instructions may cause processor 2310 to perform any of the functions described herein. The medium may, for example, be optical disk, magnetic disk or flash memory, among others. In operation, processor 2310 or some other controller causes data to be read from the nonvolatile recording medium into another memory, such as memory 2312, that allows for faster access to the information by processor 2310 than does the storage medium included data storage element 2318. The memory_' may be located in data storage element 2318 or in memory 2312; however, processor 2310 manipulates the data within the memory, and then copies the data to the storage medium associated with data storage element 2318 after processing is completed.

[0174] A variety of components may manage data movement between the storage medium and other memory elements and examples are not limited to particular data management components. Further, examples are not limited to a particular memory system or data storage system.

[0175] Although computer system 2302 is shown by way of example as one type of computer system upon which various aspects and functions may be practiced, aspects and functions are not limited to being implemented on computer system 2302 as shown in FIG. 23 Various aspects and functions may be practiced on one or more computers having different architectures or components than that shown in FIG. 23. For instance, computer system 2302 may include specially programmed, special-purpose hardware, such as an application-specific integrated circuit (“ASIC”) tailored to perform a particular operation disclosed herein. Another example may perform die same function using a grid of several general-purpose computing devices running MAC OS System X with Motorola PowerPC processors and several specialized computing devices running proprietary hardware and operating systems.

[0176] Computer system 2302 may be a computer system including an operating system that manages at least a portion of the hardware elements included in computer system 2302. In some examples, a processor or controller, such as processor 2310, executes an operating system. Examples of a particular operating system that may be executed include a Windows-based operating system, such as, the Windows-based operating systems, available from the Microsoft Corporation, a MAC OS System X operating system or an iOS operating system available from Apple Computer, one of many Linux-based operating system distributions, for example, the Enterprise Linux operating system available from Red Hat Inc., or a UNIX operating system available from various sources. Many other operating systems may be used, and examples are not limited to any particular operating system.

[0177] Processor 2310 and operating system together define a computer platform for which application programs in high-level programming languages are written. These component applications may be executable, intermediate, bytecode or interpreted code which communicates over a communication network, for example, the Internet, using a communication protocol, for example, TCP/IP. Similarly, aspects may be implemented using an object-oriented programming language, such as .Net, Java, C++, C# (C-Sharp), Python, or JavaScript. Other object-oriented programming languages may also be used. Alternatively, functional, scripting, or logical programming languages may be used.

[0178J Additionally, various aspects and functions may be implemented in a non- programmed environment. For example, documents created in HTML, XML or other formats, when viewed in a window' of a browser program, can render aspects of a graphical-user interface or perform other functions. Further, various examples may be implemented as programmed or non -prog rammed elements, or any combination thereof. For example, a web page may be implemented using HTML while a data object called from within the web page may be written in C++. Thus, the examples are not limited to a specific programming language and any suitable programming language could be used. Accordingly, the functional components disclosed herein may include a wide variety of elements (e.g , specialized hardware, executable code, data structures or objects) that are configured to perform the functions described herein.

[0179] In some examples, the components disclosed herein may read parameters that affect the functions performed by the components. These parameters may be physically stored in any form of suitable memory including volatile memory (such as RAM) or nonvolatile memory (such as a magnetic hard drive). In addition, the parameters may be logically stored in a propriety data structure (such as a database or file defined by a user space application) or in a commonly shared data structure (such as an application registry that is defined by an operating system). In addition, some examples provide for both system and user interfaces that allow external entities to modify the parameters and thereby configure the behavior of the components.

[0180] Implementation with Interest-Bearing Tokens

[0181] FIG. 24 shows one example of tokens being converted to interest-bearing tokens (IBTs) according to unfilled redemption slots remaining at the end of a redemption period. In FIG. 24, token registry 100 of F1GS. 1-4 has been expanded into a token registry' 2400 that tracks ΪBT balances 2406. Conversion of non-interesting -bearing tokens to IBTs may occur after a redemption period expires, wherein for each unfilled redemption slot remaining at the end of the redemption period, one non-interesting -bearing token is converted to one IBT; each non-interesting-bearing token may alternatively be converted to a different number of IBTs without departing from the scope hereof. IBTs are similar to the non -interesting -bearing tokens except that they generate interest until redeemed. The interest may take the form of additional IBTs added to IBT balances 2406, or another method of distribution. Interest may be calculated and/or distributed periodically, such as quarterly or biannually.

[0182] Token registry_' 2400(1) reproduces second token registry' 100(2) of FIG. 2, showing that at the end of reimbursement, the first token holder filled zero of 50,000 allocated redemption slots, and the fifth token holder filled half of 100,000 allocated redemption slots. Thus, token registry 2400(1) is updated into token registry 2400(2) by: adding 50,000 IBTs to the first token holder’s IBT balance 2406 and subtracting 50,000 tokens from the first token holder s token balance 106: and adding 50,000 IBTs to the fifth token holder s IBT balance 2406 and subtracting 50,000 tokens from the fifth token holder’s token balance 106.

[0183] Conversion of tokens to IBTs may be implemented after disbursement as well as reimbursement. For example, in FIG. 4 the third token holder tilled half of the 60,020 allocated redemption slots at the end of disbursement. From the 30,010 unfilled slots, 30,010 of the third token holder’s tokens may be converted into an equal number of IBTs with the third token holder’s IBT balance 2406 and token balance 106 updated accordingly.

[0184] In one embodiment, IBTs are tradeable on a regulated security token exchange. In another embodiment, each IBT is redeemable for the redemption value. In another embodiment, a token holder may not redeem tokens unless the token holder possesses zero IBTs; thus, each token holder must redeem IBTs before non-interest-bearing tokens.

[0185] Simultaneous Reimbursement and Disbursement

[0186] FIGS. 2.5 and 2.6 show one example of simultaneous reimbursement and disbursement. In FIGS 25 and 26, token registry 100 of FIGS 1 -4 is shown as a token registry 2500 that stores priority-slot allotments 108, regular-slot allotments 308, and total slot allotments 2508 Token registr ' 2500 also stores slot redemptions 2510 corresponding to a total number of filled redemption slots, both priority redemption slots and regular redemption slots.

[0187] FIG. 25 shows token registry 2500 as an initial token registry 2500(1 ). Using the example values in FIGS. 1-4, initial token registr 2500(1) shows 469,999 slots allocated to the six token holders, of which 170,000 slots are priority' slots and 299,999 slots are regular slots. The total number of redemption slots is the same in the examples of FIGS. 1 -4 and FIGS. 25-26 The 299,999 regular slots in FIG. 25 correspond to the 399,999 regular slots in FIG 3 less the 100,000 unredeemed priority slots in FIG. 2, because it is unknown how many priority slots will be redeemed. The 170,000 priority slots are allocated into priority-slot allotments 108 in the same way as in FIG. 1 , and the 299,999 regular slots are allocated pro rata to generate regular-slot allotments 308. For the pro rata allocation, it may be assumed that each priority token holder fills all of the allocated priority' slots. Thus, to determine proportional ownership of held tokens, each priority-slot allotment 108 may be first subtracted from the corresponding token balance 106. Each total slot allotment 2508 is the sum of the corresponding priority-slot allotment 108 and regular-slot allotment 308.

[0188] FIG. 26 show's token registry' 2500 as an updated token registry 2500(2) after the token holders have redeemed tokens in redemption slots during simultaneous reimbursement and disbursement. For each token holder redeeming tokens, token balance 106 of said each token holder is reduced by a number of tokens redeemed by said each token holder. Thus, in FIG. 26, each of the first and second token holders redeemed the maximum number of tokens allowed, as indicated by the corresponding total slot allotments 2508. For example, the first token holder redeemed 201,068 tokens and the corresponding token balance 106 of the first token holder was reduced by the same number to 4,798,932 tokens. The fourth token holder redeemed only 20,000 tokens corresponding to all of their priority-slot allotment 108 and none of their regular-slot allotment 308. The fifth token holder redeemed 50,000 tokens, corresponding to half of their priority-slot allotment 108. The sixth token holder redeemed 3,000 tokens, corresponding to a portion of their regular-slot allotment 308. The third token holder redeemed no tokens, and thus their token balance 106 of 207,000 tokens remains unchanged from token registry 2500( 1) of FIG. 25.

[0189] In some embodiments, the order in which priority slots and regular slots are redeemed may be set by the token issuer. In certain embodiments, priority slots are redeemed first. In certain embodiments, regular slots are redeemed first. In certain embodiments, tokens are redeemed proportionally in priority and regular slots. In some examples, slots are redeemed proportionally based on the number of tokens redeemed, the ratio or priority to regular slots allotted to the token holder, or any other proportion determined by the token issuer. In other embodiments, token holders may choose the order in which to redeem tokens.

[0190] The simultaneous reimbursement and disbursement shown in FIG. 25 may be advantageously implemented with IBTs described above when unredeemed priority slots are automatically used to convert tokens into IBTs at the end of a redemption period. In this case, the unredeemed priority slots are not reallocated during a subsequent disbursement (e.g., step 11 12 of method 1 100), and thus, regular slots may be allocated pro rata immediately without having to wait until reimbursement is over.

[0191] Tokens with Recall Rights

[0192] Embodiments herein may be implemented with a variety of mechanisms that reduce downside risk incurred by token holders. For example, in some embodiments tokens are issued/circulated with recall rights, wherein a token holder may recall a circulated token prior to disbursement and/or reimbursement (i.e., prior to when the token holder may redeem the token for the full redemption value). The token holder may exercise the recall rights of a token by exchanging the token for a recall value. The recall value may equal a fraction of the initial base price paid for the token. For example, if the initial base price is $1.00 per token and the fraction is set at 40% of the initial base price, then the recalling token holder is given a recall value of $0.40 for each recalled token. The recall value may be equal to a different fraction (e.g., 50%) of the initial base price without departing from the scope hereof. Alternatively, the recall value may be set to a fixed dollar amount (e.g., $0.50 per token).

[0193] In some embodiments, token holders are encouraged to hold their tokens until disbursement and/or reimbursement by limiting the recall value to less than 100% of the initial base price. Thus, a token holder may not receive at the time of recall more than the initial base price originally paid for the token.

[0194] In some embodiments, when a token holder recalls a token, the recalled token is removed from circulation. Thus, recall rights for one token may be exercised only once. A difference between the recall value and the initial base price, referred to herein as a‘"residual redemption value^”, represents a remaining portion yet to be returned to the token holder after recall. In some embodiments, the residual redemption value is assigned to a non-tradeable token that is issued to the recalling token holder for future redemption. The future redemption may occur using the same procedures as other tokens or may include additional limitations (e.g., redeemable once a certain number of periods of reimbursement and disbursement have occurred after the token has been recalled, or a similar trigger event). [0195] In some embodiments, the residual redemption value equals the difference between the initial base price and the recall value. Thus, the recalling token holder ultimately receives only the initial base price (i.e., the recall value at the time of recall, plus the residual redemption value at the time of future redemption). In other embodiments, the residual redemption value is greater than the difference between the initial base price and the recall value, wherein the recalling token holder ultimately receives more than the initial base price, but less than the full redemption value. In other embodiments, the residual redemption value equals the difference between the full redemption value and the recall value, wherein the recalling token holder ultimately receives die full redemption value of the token.

[0196] In some embodiments, the recall value is set by the token issuer (e.g., the owner

EOA having owner address 848 that deployed smart contract 704). The token issuer may- change the recall value at various times. For example, after initially circulating tokens, the token issuer may set the recall value to, for example, 20% of the initial base price. After two years (or a different period of time, or other trigger event (such as completion of preelinica! research or clinical research, but before FDA approval), the token issuer may increase the recall value to, for example, 30% of the initial base price. When each token corresponds to a portion of a dose of a pharmaceutical, the token issuer may again change the recall value (e.g., to 40% of the initial base price) after FDA approval of the pharmaceutical has been obtained. After one or periods of reimbursement and/or disbursement, the token issuer may again change the recall value to, for example, 50% of die initial base price. As shown by this example, the token issuer may increase the recall value as various milestones leading to positive revenue generation of the underlying assets and/or operations are met.

[0197] In some embodiments, the token holder exercising the recall rights sets the recall value. In some of these embodiments, token holders are encouraged to recall tokens with lower recall values in exchange for a higher residual redemption value. Thus, while the recalling token holder receives less than the initial base price at the time of recall, the token holder may- still ultimately receive more than die initial base price (i.e., after the future redemption of the non-tradeable token received by the token holder in exchange for the recalled token). For example, a token holder may recall a token with a recall value equal to 20% of the initial base price. In exchange, the residual redemption value of the resulting non-tradeable token may be set, for example, to 180% of the initial base price such that the token holder ultimately receives 200% of the initial base price (20% received at the time of recall plus 180% received after the future redemption of the non-tradeable token). In another example, the token holder recalls a token with a recall value equal to 60% of die initial base price. In exchange, the residual redemption value is set to 40% of the initial base price such that the token holder ultimately receives only 100% of the initial base price.

[0198] In some embodiments where the token holder sets the recall value, the token issuer may implement a recall ceiling equal to the highest allowable recall value. The token issuer may encourage token holders to hold their tokens until disbursement and/or reimbursement by setting the recall ceiling to less than 100% of the initial base price, such as 90% of the initial base price. Thus, while a token holder selects the recall value, the token holder never receives, at the time of recall, more than the initial base price originally paid for the token. In some embodiments, the token issuer changes the recall ceiling at different times and/or in response to different events (e.g., FDA approval of a pharmaceutical, a first sale, a first iteration of disbursement and/or reimbursement, etc.).

[0199] It should be appreciated from the above discussion that there are numerous ways to determine the residual redemption valise based on the recall value. In addition to the above examples, the residual redemption value and/or recall value may be determined from a total number of tokens recalled by one token holder, either at once or cumulatively. In one embodiment, the token issuer sets the recall value to limit a total recall amount given to the token holder. For example, in response to a token holder recalling 1,000 tokens, the token issuer may set the recall value to, for example, 40% of the initial base price, wherein the token holder receives, at the time of recall, 400 times the initial base price in exchange for recalling the 1,000 tokens (plus 1,000 non-tradeable tokens, each having a determined residual redemption value) .

[Q2Q0] In some embodiments, recall rights are exercisable immediately upon circulation. In some embodiments, recall rights become exercisable after a certain period of time after the tokens are circulated. For example, recall rights may become exercisable stalling two years after circulation. In another example, where each token corresponds to a portion of a dose of a pharmaceutical, recall rights become exercisable only after FDA approval (or some oilier milestone, such as prechnical research completion, or clinical research completion) of the pharmaceutical. In another example, recall rights become exercisable only after reimbursement and/or disbursement begins. In another example, recall rights stop being exercisable once reimbursement and/or disbursement begins.

[Q2Q1] In the previous examples, a token holder may recall one token or a plurality of tokens, up to a total number of tokens in possession by the token holder at the time of recall In one embodiment, recall rights are limited to a fixed number of tokens per token holder, wherein said token holder may not cumulatively recall more than the fixed number of tokens. In some embodiments, recall rights are limited such that a token holder does not receive more than a total recall value for all tokens cumulatively recalled by the token holder.

[0202] In certain embodiments, some of the tokens are circulated without recall rights while the remaining tokens are circulated with recall rights. Tire tokens without recall rights may be issued with a higher redemption value than the tokens with recall rights. Furthermore, the remaining tokens may be circulated with various types of recall rights (e.g., different exercise periods, recall ceilings, residual redemption values, etc.). Thus, a purchaser of tokens may choose which type of token to purchase by weighing downside risk against higher redemption values and/or residual redemption values. Tokens with different types of recall rights may be initially circulated with different initial base prices that reflect the different redemption values and/or residual redemption values.

[0203] FIG. 27 shows smart contract 704 of FIGS. 7-8 additionally configured with a token recaller 2718 that implements token recall rights and recalling functionality described herein . Token recaller 2718 is implemented as machine -readable instructions stored in instructions 706 and configured to control one or more processors to implement recalling of tokens. FIG. 27 also shows data 702 of smart contract 704 additionally storing a residual redemption value 2750, a recall ceiling 2740, and a recall value 2742.

[0204] FIG. 2.8 is a flowchart illustrating execution of token recaller 2718 of smart contract 704. Token recaller 2718 implements a step 2802 that receives a transaction (e.g., one of transactions 708 of FIG. 7) requesting a recall of a number of tokens. Token recaller 2718 also implements a step 2804 that obtains from the transaction the address of the transaction sender. Token recaller 2718 also implements a step 2806 that uses the address of the transaction sender to determine if the transaction sender is a token holder. For example, step 2806 may look up the address of the transaction sender in address mappings 842. If the transaction sender is not a token holder (e.g., not listed in address mappings 842), then token recaller 2718 continues to a step 2808 that returns an error and stops. If the transaction sender is one of the token holders, then token recaller 2 18 continues to a step 2810 that accesses token registry 840 to determine if the transaction sender has a token balance greater than or equal to the number of tokens requested. If the transaction sender does not have a sufficient token balance, then token recaller 2718 continues to a step 2812 that returns an error and stops. If the transaction sender has a sufficient token balance, then token recaller 2718 continues to a step 2818 that updates token registry 840 according to the number of recalled tokens. For example, step 2818 may update token registry 840 by reducing the token balance of the transaction sender by the requested number of recalled tokens. [Q2Q5] Token recaller 271 8 also implements a step 2820 that transfers recall value 2742 to the transaction sender (i.e., the confirmed token holder) for each recalled token. For example, step 2820 may transfer cryptoeurrency from the contract owner EOA to the EOA of the transaction sender. If transfer value 2742 is expressed in terms of an external currency that is not the native cryptoeurrency of computing platform 701 (e.g., US dollars), step 2820 may- contact an oracle to determine a conversion factor between the native cryptoeurrency and the external currency. Step 2820 may then use the conversion factor to determine the quantity of cryptoeurrency to be transferred to the transaction sender.

[Q2Q6] Token recaller 2718 also implements a step 2822 that determines residual redemption value 2750 for the recalled tokens. Several examples of how residual redemption value 2750 may he determined are presented above. For example, the residual redemption value may be equal to a difference between the initial base price and the recall value, wherein the recalling token holder ultimately receives only the initial base price. Token recaller 2718 also implements a step 2824 that issues non-tradeable tokens to the transaction sender, each storing residual redemption value 2750.

[Q2Q7] In some embodiments where the token holder selects the recall value, step 2802 also receives recall value 2742, as set by the token holder, from the transaction. In these embodiments, token recaller 2718 implements a step 2814 that determines if recall value 2742 is less than or equal to recall ceiling 2740. If true, recall value 2742 is valid and token recaller 2718 continues to step 2818. Otherwise, recall value 2742 is not valid and token recaller 2718 continues to a step 2816 that returns an error and stops. In embodiments where the token issuer sets recall value 2742, token recaller 2718 may be implemented without steps 2814 and 2816.

[Q2Q8] Based on the foregoing disclosure, it should be apparent to one of ordinary' skill in the art that the embodiments disclosed herein are not limited to a particular computer system platform, processor, operating system, network, or communication protocol. Also, it should be apparent that the embodiments disclosed herein are not limited to a specific architecture or programming language.

[0209] Changes may be made in the above methods and systems without departing from the scope hereof. It should thus be noted that the matter contained in the above description or show'n in the accompanying drawings should be interpreted as illustrative and not in a limiting sense. The following claims are intended to cover all generic and specific features described herein, as well as all statements of the scope of the present method and system, which, as a matter of language, might be said to fall therebetween.

Claims

CLAIMS What is claimed is:

1. A token-based reimbursement method, comprising:

circulating tokens to token holders;

generating a plurality of redemption slots based on sales of an asset during a period; reimbursing the token holders by:

assigning a priority subset of the redemption slots to each token holder based on a number of units of the asset utilized by said each token holder during the period; and

for each assigned redemption slot of each priority subset, redeeming one of the tokens after the assigned token holder surrenders said one of the tokens; and

disbursing to the token holders by:

assigning a remaining subset of the redemption slots to each token holder; and for each assigned redemption slot of each remaining subset, redeeming one of the tokens after the assigned token holder surrenders said one of the tokens.

2. The method of claim 1, further comprising:

before circulating, setting identical redemption value to every token;

wherein generating the plurality of redemption slots includes determining a number of redemption slots based on (a) net sale price per unit of the asset, (b) cost of goods sold per unit of the asset, and (c) the identical redemption value.

3. Hie method of claim 1, wherein assigning each remaining subset of the redemption slots includes assigning unused redemption slots of all of the priority subsets.

4. The method of claim 3, further comprising iteratively disbursing, wherein assigning the remaining subset includes assigning unused redemption slots of all remaining subsets of a previous iteration.

5. The method of claim 4, further comprising periodically generating, reimbursing, and iteratively disbursing.

6. The method of claim 5, wherein generating the plurality of redemption slots includes generating one redemption slot for each unused redemption slot remaining after expiration of a previous period.

7. The method of claim 6, wherein assigning the remaining subset includes assigning, pro rata, the remaining subset of the redemption slots.

8. The method of claim 1, wherein circulating the tokens comprises:

selling at least one token to at least one token holder via a transaction; and digitally encoding the transaction in a distributed ledger.

9. The method of claim 8, wherein circulating the tokens includes releasing the tokens for trading on a regulated security token exchange.

10. The method of claim 9, wherein releasing the tokens for trading begins after a trigger event has occurred.

1 1. The method of claim 8,

wherein selling at least one token includes selling at least one passive token; and further including converting, after the step of circulating, each passive token for an active token.

12. The method of claim 11, wherein converting occurs after a redemption condition.

13. The method of claim 12, further comprising holding active tokens in escrow by an escrow agent that initiates said converting upon occurrence of the redemption condition.

14. The method of claim 12, each unit of the asset being a dose of a pharmaceutical.

15. The method of claim 14, the redemption condition being a first sale of the

pharmaceutical.

16. The method of claim 1, further comprising exchanging a recall value for one token when the one token is recalled by a corresponding one of the token holders.

17. The method of claim 16, wherein exchanging includes:

determining a residual redemption value for the one recalled token; and

issuing to the corresponding one of the token holders one non-tradeable token having the residual redemption value

18. The method of claim 17, wherein determining includes calculating a difference

between the recall value and an initial base price of the one token

19. A token-based reimbursement method, comprising:

circulating tokens to token holders;

allocating a budget based on sales of an asset during a period;

reimbursing each of the token holders from the budget based on a number of units of the asset utilized by said each of the token holders during the period; disbursing a remainder of the budget to the token holders.

20. The method of claim 19, wherein:

allocating includes generating a plurality of redemption slots;

reimbursing each token holder includes:

assigning a priority subset of the redemption slots to each token holder based on the number of units of the asset utilized by said each token holder during the period; and

for each assigned redemption slot of each priority_' subset, redeeming one of the tokens when surrendered; and

disbursing includes:

assigning a remaining subse t of the redemption slots to each token holder; and for each assigned redemption slot of each remaining subset, redeeming one of the tokens when surrendered.

21. A token-based reimbursement method, comprising;

circulating tokens to token holders;

generating a plurality of redemption slots based on sales of an asset during a period; assigning a pri ority subset of the redempti on slots to each token holder based on a number of units of the asset utilized by said each token holder during the period;

for each assigned redemption slot of each priority subset, redeeming one of the tokens when surrendered;

assigning a remaining subset of the redempti on slots to each token holder; and for each assigned redemption slot of each remaining subset, redeeming one of the tokens when surrendered.

22. The method of claim 21, further comprising:

before circulating, setting identical redemption value to every token;

wherein generating the plurality of redemption slots includes determining a number of redemption slots based on (a) net sale price per unit of the asset, (b) cost of goods sold per unit of the asset, and (c) the identical redemption value.

23. The method of claim 21, wherein assigning each remaining subset of the redemption slots includes assigning unused redemption slots of all of the priority subsets.

24. The method of claim 23, further comprising, for each assigned redemption slot,

iterati vely assigning and redeeming while assigning unused redemption slots of all of the remaining subsets of a previous iteration.

25. The method of claim 24, further comprising periodically;

generating the plurality of redemption slots;

assigning the priority subset;

redeeming one of the tokens when surrendered for each assigned redemption slot of each priority subset; and

iteratively (a) assigning the remaining subset and (b) redeeming one of the tokens wiien surrendered.

26. The method of claim 25, wherein generating the plurality of redemption slots comprises generating one redemption slot for each unused redemption slot remaining after expiration of a previous period.

27. The method of claim 26, wherein assigning the remaining subset includes assigning, pro rata, the remaining subset of the redemption slots.

28. The method of claim 21 , wherein circulating the tokens comprises:

selling at least one token to at least one token holder via a transaction; and digitally encoding the transaction in a distributed ledger.

29. The method of claim 28, wherein circulating the tokens comprises releasing the

tokens for trading on a regulated security token exchange.

30. The method of claim 29, wherein releasing the tokens for trading begins after a trigger event has occurred.

31. The method of claim 28,

wherein selling at least one token comprises selling at least one passive token; and further comprising converting, after each said circulating, each passive token for an active token.

32. The method of claim 31 , wherein converting occurs after a redemption condition.

33. The method of claim 32, further comprising holding active tokens in escrow by an escrow agent that initiates said converting upon occurrence of the redemption condition.

34. The method of claim 32, each unit of the asset being a dose of a pharmaceutical.

35. The method of claim 34, the redemption condition being a first sale of the

pharmaceutical.

36. A token-based reimbursement system, comprising:

at least one processor;

distributed memory communicatively coupled with the at least one processor; a token circulator implemented as machine-readable instructions stored the distributed memory and configured to control the at least one processor to circulate tokens to token holders:

a disbursement allocator implemented as machine-readable instructions stored in the distributed memory and configured to control the at least one processor to allocate a disbursement budget based on sales of an asset during a period; a token-holder reimburser implemented as machine-readable instructions stored in the distributed memory' and configured to control the at least one processor to reimburse each token holder from the disbursement budget based on a number of units of the asset utilized by said each token holder during the period; and a token-holder disburser implemented as machine-readable instructions stored in the distributed memory' and configured to control the at least one processor to disburse a remainder of the disbursement budget to the token holders.

37. The token-based reimbursement system of claim 36, wherein:

the disbursement allocator includes machine-readable instructions configured to

control the at least one processor to generate a plurality of redemption slots; the token-holder reimburser includes machine -readable instructions configured to control the at least one processor to (i) assign a priority subset of the redemption slots to each token holder based on the number of units of the asset utilized by said each token holder during the period, and (ii) for each assigned redemption slot of each priority subset, redeeming one of the tokens when surrendered; and

the token-holder disburser includes machine-readable instructions configured to

control the at least one processor to (iii) assign a remaining subset of the redemption slots to each token holder, and (iv) for each assigned redemption slot of each remaining subset, redeem one of the tokens when surrendered.

38. The token-based reimbursement system of claim 37, wherein:

the token circulator further includes machine-readable instructions configured to control the at least one processor to assign identical redemption value to every_' token; and the machine-readable instructions of the disbursement allocator to generate a plurality of redemption slots include machine-readable instructions to determine a number of redemption slots based on (a) net sale price per unit of the asset, (b) cost of goods sold per unit of the asset, and (c) the identical redemption value.

39 The token-based reimbursement system of claim 37, wherein the machine-readable instructions of the token-holder disburser to assign a remaining subset of the redemption slots to each token holder include machine-readable instructions to assign unused redemption slots of all of the priority subsets.

40. The token-based reimbursement system of claim 39, wherein:

the machine-readable instructions of the token-holder disburser to disburse the

remainder of the disbursement budget to the token holders includes machine- readable instructions to iteratively disburse the remainder of the disbursement budget to the token holders; and

the machine-readable instructions of the token-holder disburser to assign a remaining subset of the redemption slots to each token holder include machine-readable instructions to assign unused redemption slots of all remaining subsets of a previous iteration.

41 . The token-based reimbursement system of claim 40, wherein the disbursement

allocator, the token-holder reimburses and the token-holder disburser are configured to execute periodically.

42. The token-based reimbursement system of claim 41, wherein the machine-readable instructions of the disbursement al locator to generate a plurality of redemption slots includes machine-readable instructions to generate one redemption slot for each unused redemption slot remaining after expiration of a pre vious period.

43. The token-based reimbursement system of claim 42, wherein the machine-readable instructions of the token-holder disburser to assign a remaining subset of the redemption slots to each token holder include machine-readable instructions to assign, pro rata, the remaining subset of the redemption slots.

44 The token-based reimbursement system of claim 37, wherein the machine-readable instructions of the token circulator to circulate the tokens includes machine-readable instructions to (i) sell at least one token to at least one token holder via a transaction, and (ii) digitally encode the transaction in a distributed ledger.

45 The token-based reimbursement system of claim 44, wherein the machine-readable instructions of the token circulator to circulate the tokens includes machine-readable instructions to release the tokens for trading on a regulated security token exchange.

46. The token-based reimbursement system of claim 45, wherein the machine-readable instructions of the token circulator to release the tokens for trading are configured to execute after a trigger event has occurred.

47. The token-based reimbursement system of claim 44,

wherein the machine-readable instructions of the token circulator to sell at least one token include machine -readable instructions to sell at least one passive token: and

the system further including a token converter implemented as machine-readable instructions configured to control the at least one processor to convert each passive token for an active token.

48. The token-based reimbursement system of claim 47, wherein the machine-readable instructions of the token converter to convert each passive token are configured to execute occur after a redemption condition.

49. The token-based reimbursement system of claim 48, each unit of the asset being a dose of a pharmaceutical.

50. The token-based reimbursement system of claim 49, the redemption condition being a first sale of the pharmaceutical.

51. The token-based reimbursement system of claim 36, further comprising a token

recaller implemented as machine-readable instructions stored in the distributed memory' and configured to control the at least one processor to:

exchange a recall value for each token recalled by a corresponding one of the token holders, detennine a residual redemption value for said each token, and

issue to the corresponding one of the token holders one non-tradeable token having the residual redemption value.

52. A token-based reimbursement system, comprising:

a processor;

memory communicatively coupled with the processor;

a network communicatively coupling the processor and memory with a distributed- ledger-based computing platform; and

machine-readable instructions stored in the memory and configured to control the processor to send a first transaction via the network to a smart contract deployed on the distributed-ledger-based computing platform such that the smart contract, in response to the first transaction, controls the distributed- ledger-based computing platform to:

(i) allocate a distribution budget to a plurality of token holders based on sales of an asset during a period, and

(ii) reimburse each token holder from the distribution budget based on a number of units of the asset utilized by said each token holder during the period.

53. The token-based reimbursement system of claim 52, wherein the machine-readable instructions are further configured to control the processor to send a second transaction via the network to the smart contract such that the smart contract, in response to the second transaction, controls the distributed-ledger-based computing platform to (iii) disburse a remainder of the distribution budget to the plurality of token holders.

54. The token-based reimbursement system of claim 53, wherein the machine-readable instructions control the processor to construct the first transaction such that the smart contract, in response to the first transaction, controls the distributed-ledger-based computing platform to:

al locate a distribution budget by generating a plurality of redemption slots; and reimburse each token holder by: assigning a priority subset of the redemption slots to each token holder based on the number of units of the asset utilized by said each token holder during the period, and

for each assigned redemption slot of each priority subset, redeeming one of the tokens when surrendered.

55. The token-based reimbursement system of claim 54, wherein the machine-readable instructions are configured to control the processor to construct the second transaction such that the smart contract in response to the second transaction, controls the distributed-ledger-based computing platform to disburse to the token holders by: assigning a remaining su bset of the redemption slots to each token holder, and for each assigned redemption slot of each remaining subset, redeeming one of the tokens when surrendered.

56. Idle token-based reimbursement system of claim 55, wherein the machine-readable instructions stored in the memory are further configured to control the processor to send a deployment transaction via the network to the distributed-ledger-based computing platform such that the distributed-ledger-based computing platform, in response to the deployment transaction, deploys the smart contract on the distributed- ledger-based computing platform.

57. The token-based reimbursement system of claim 52, wherein the machine-readable instructions are further configured to control the processor to send a third transaction via the network to the smart contract such that the smart contract, in response to the third transaction, controls the distributed-ledger-based computing platform to:

exchange a recall value for each token recalled by a corresponding one of the token holders,

determine a residual redemption value for said each token, and

issue to the corresponding one of the token holders one non-tradeable token having the residual redemption value.