Application Number: AU 2026202234

Two Tokens Deep Turning a Pool of Bank Loans Into Claims on One Named Loan

Claim 1 is a method, and only a method. The divisional contains eleven claims and not one of them is a system, server or computer readable medium claim, which is worth knowing before reading the title.

Open for Public Inspection
AU 2026202234 Featured Image

View the Two Tokens Deep PDF

Download the PDF version of this Application Open to Public Inspection

This application covers a two layer scheme for dividing up a pool of illiquid assets, most concretely a pool of infrastructure project finance loans bought from banks. Investors first buy a general asset token, which is a pro rata claim on everything in the pool, and can later surrender it in an auction to obtain a specific asset token that is a claim on one named loan. It was filed by Pontoro, Inc., a United States fintech company, and names Monique Vaddhana-Moni Sinmao, Antonio Vitti, Ka Sham and Robert Havelock Dewing as inventors. The application is a divisional of Australian application 2020364092, filed 9 October 2020, and claims priority from US provisional application 62/743,859 filed 10 October 2018.

The Problem

The background section is unusually concrete for a software filing, and it describes a real market complaint rather than an abstract one. Financing a large infrastructure project in the United States, the specification says, is in practice restricted to large specialised financial institutions with a local presence. Overseas institutional investors are shut out by visibility, distance, language and lack of local market knowledge. Even investors who can get in are constrained by minimum investment amounts that usually exceed their funding capabilities.

The second complaint is about shape rather than size. Commitments to infrastructure funds or projects, the specification says, tend to be rigid and deal specific with high concentration risks, and once made there is very little liquidity available to get out of them. An investor who wants exposure to roads but not to power generation, or who wants to reduce a position after two years, has essentially no mechanism to do either.

Those two complaints pull in opposite directions, which is the real problem. Pooling assets solves the minimum ticket size and the concentration risk, because everyone owns a slice of everything. But pooling also destroys the thing sophisticated investors are paying for, which is the ability to choose the specific credit they want. A conventional fund gives you the pool. A conventional syndicated loan participation gives you the single asset at a ticket size you cannot afford. The specification states flatly that there is no technical system that addresses the nuances of financing large scale assets like infrastructure projects.

What This Invention Does

Claim 1 is a method, and only a method. The divisional contains eleven claims and not one of them is a system, server or computer readable medium claim, which is worth knowing before reading the title.

The method runs like this. A token manager on an administration server generates one or more general asset tokens from a general asset pool, based on an asset protocol that is stored in a distributed ledger and defines asset attributes and token status data. An application on the same server associates each general asset token with one or more smart contract protocols, also stored in the ledger, which validate the tokens against the pool. Those general asset tokens are held by a plurality of users and are mapped to the value of the assets in the pool.

Then comes the second tier. The application receives a subscription request from a client device asking to use a general asset token to create specific asset tokens that map to a portion of specific assets drawn from the pool. The token manager creates a first specific asset token mapping to a portion of the value of one specific asset, stores it in the ledger, and transfers the corresponding portion of value out of the general pool into a repository within the ledger, with the transfer controlled by data in the smart contract. Finally a record of the new token and the updated status of the general token or the pool is stored.

The description fills in the commercial mechanics that the claim only gestures at. General asset tokens are described as evergreen: once a holder uses one to create specific asset tokens it is frozen in a repository, and frozen tokens are pooled and reoffered in a later round. Specific asset tokens are the opposite, created and then burned as the underlying loan amortises and is repaid. Both kinds of holder receive cash flows from the assets, called rewards, which are loan principal and interest less network fees.

The allocation mechanism is the part with real numbers behind it. Subscription requests are collected during periodic events the specification calls casting events, and are allocated by a Dutch auction that prioritises the highest bid and settles at the lowest clearing price. The worked example: a specific asset has 100 units available and five owners each hold 20 units worth of general token allocation, but all five want to create 25 units, so the asset is oversubscribed by 25 units. Owner 1 bids a premium of 1.2 general tokens per unit, owners 2 and 3 bid 1.15, owners 4 and 5 bid 1.1. Owners 1, 2 and 3 get their full 25 units. Owners 4 and 5 split what is left and get 12.5 each. The clearing price is 1.1, so a 10 general token premium is paid by the winners to the two who ended up short, 5 tokens each.

A second example shows what the concentration limits do. Asset X is worth $200 and ten users each hold a $20 pro rata stake in it through the general pool. Apply a 25 per cent ownership limit and four users can each take $50 of specific asset token X, after which the asset is fully subscribed. The specification is explicit that partial securitisation is fine: even if only one user subscribes, a $50 specific token can be created and the remaining 75 per cent stays unclaimed in the general pool for a later casting event.

The third example covers what happens to a holder who does nothing. One hundred general tokens are issued at $10. Ninety eight get used and frozen. After twelve months the two unused ones are worth $7.50 each because the underlying loans have amortised. The system then auctions the 98 frozen tokens at $10. One of the two remaining round 1 holders surrenders his token first. The other does not, and is forcibly reset: his holding becomes 0.75 of a round 2 token, being $7.50 divided by $10, which brings him to parity. Total round 2 supply becomes 99.75.

Key Features

  • Two tiers of token over one pool. A general asset token is a pro rata claim on everything in the pool. A specific asset token is a claim on a stated portion of one named asset. The second is created by surrendering the first, so the two cannot double count the same value.
  • Freezing rather than burning the general token. Used general asset tokens go into a repository and are reoffered in later rounds, which the specification describes as a proxy for secondaries versus new issues and is what makes the general token evergreen.
  • Dutch auction allocation with a bid premium. Oversubscribed assets are allocated highest bid first and settled at the lowest allocated bid, with the premium paid across to holders who end up with less than their pro rata share.
  • Partial securitisation of a single asset. Unlike a conventional securitisation, the whole asset does not need to be subscribed for any of it to be tokenised. Whatever is unclaimed simply stays in the general pool and is reallocated to the remaining general token holders.
  • A forced reset to keep rounds at parity. Holders who sit out a round have their tokens revalued by the ratio of remaining round 1 value to the round 2 offer price, so old and new tokens have equal purchasing power at the next casting event.
  • An optional recommendation model. Claim 9 adds receiving an asset recommendation request, processing the user’s data through a model trained by data, and returning recommendation data. The specification does not say what the model is or what it is trained on.

Who Is Behind It

Pontoro is trading. Its site at pontoro.com carries a 2026 copyright, a current senior team with Antonio Vitti as chief executive and co-founder and Robert Dewing as co-founder, both named inventors here, and an investor list including Franklin Templeton, Ulu Ventures, Neva SGR, Illuminate Financial and the Stellar Development Foundation. The footer states that the platform is protected by US Patent Nos. 11,514,411 B2 and 12,288,197 B2, the first of which is the United States member of this family and is published as US 11,514,411.

What the site does not describe is the business in this specification. The product Pontoro markets in 2026 is an Automated Liquidity Pool for private funds, which pools short duration cash-like capital alongside illiquid private fund interests and uses an algorithm to price liquidity, manage redemption queues and allocate yield. Infrastructure loans are not the headline any more; private fund interests and secondary pricing are. That is a genuine shift from the 2020 filing, which is focused on buying syndicated infrastructure loans from banks and re-offering them. Coverage from the time, such as Ledger Insights in 2021, describes the original plan in those terms. Readers should treat the specification as a description of where the company started, not of what it currently sells.

The paper trail is fully stated in the document itself, which is a relief after several filings that state nothing. Paragraph [0001] claims the priority benefit of US provisional application 62/743,859, titled the same as this one, filed 10 October 2018. Paragraph [0002] states that the application is a divisional of Australian application 2020364092 filed 9 October 2020, published as AU 2020364092. The priority country is the United States.

Why It Matters

Most tokenisation filings are about the wrapper. This one is about the allocation rule, and that is the harder half of the problem. Splitting an asset into transferable units is trivial; deciding which of ten investors gets the piece of the one loan everybody wants is not, and a pro rata rule gives an answer nobody asked for. The specification’s response is to make the general token the currency of the auction, so that increasing your concentration in Asset X necessarily means accepting more of everything else and paying a premium to the people who take it. That is a coherent piece of market design, and it is the reason the worked examples in this document are worth reading where in most filings of this kind they would not be.

The second point worth noticing is how conventional the ledger is. Claim 7 stores token information in a distributed ledger maintained by distributed machines. Claim 10 says the datastore may be implemented at least in part by a distributed ledger on remote machines. Claim 11 says it may be implemented at least in part by a centralised server. The description talks about a combination of permissioned and public blockchain, KYC and anti money laundering checks on every participant, fiat denomination of all transactions and assets, and interaction with auditors, accountants and regulators. This is not a filing that expects the ledger to replace the intermediaries. It expects the ledger to be a shared record that the existing intermediaries agree on.

Finally, a note for anyone reading the claim set closely. Claim 1 refers to the transfer being controlled by data within the smart contract, though the antecedent it introduced was one or more smart contract protocols, and claim 2 refers to the asset pool manager when claim 1 introduced a token manager. Claim 1 also shifts between receiving a subscription request and responding to the at least one received subscription request. These are the sort of antecedent basis wobbles an examiner usually picks up, and they may well move before the case is accepted.

Related Concepts

  • Securitization – the conventional technique for pooling illiquid loans and selling claims on them, which this method varies by allowing an asset to be only partly subscribed.
  • Project finance – the lending structure behind the infrastructure loans the specification uses as its worked example asset class.
  • Market liquidity – the property the background says is absent from infrastructure investments and that the two tier token structure is meant to create.
  • Security token offering – the broader category of blockchain recorded claims on real assets that this platform belongs to.
  • Know your customer – the identity and anti money laundering checks the specification says the platform performs on every participant and counterparty.

AU 2026202234 was published in the Australian Official Journal of Patents on 9 April 2026 and is open for public inspection. Patent applications represent inventions that are sought to be protected and do not necessarily reflect commercially available products.

Related Patents Open to Public Inspections

See related Patents open to public inspection.

Disclaimer

The information presented in this article is provided for general informational and illustrative purposes only.

Content on this page may be derived from publicly available intellectual property records, including patent documentation and related materials. While reasonable care is taken in compiling and summarising this information, ATMOSS does not guarantee the accuracy, completeness, currency, or reliability of any content presented.

This article is not a substitute for reviewing the original source documents. Patent applications, specifications, claims, and related records may contain detailed technical, legal, and contextual information that is not fully represented in this summary.


ATMOSS does not provide legal, technical, or commercial advice. Users should not rely on this content for decision-making purposes.
For authoritative and up-to-date information, users should refer directly to the official records available via IP Australia and other relevant intellectual property databases. Links to these official sources are provided where applicable.


ATMOSS accepts no liability for any loss, damage, or consequences arising from the use of, or reliance on, the information contained in this article.