Patents Wiki
Back to briefings
PatentBlockchain

When Sponsors Quietly Pay for a Stranger's Subscription

A new US patent application, US20260127567A1, describes a system where one party quietly pays for another party's software subscription, with an internal currency the filing calls "tokens" as the medium of exchange. The mechanism is not new. What landed in May 2026 is the latest continuation of a 2013 original (a continuation patent inherits the original filing date while letting the inventor rewrite the claims). The chain behind it has five issued patents and one prior pending parent, and the new continuation adds a smaller, more focused workflow: a logged-in user of a client app can pay to extend a third party's soon-to-expire subscription, and the system then applies the extension and notifies the third party. The big idea is older. The small addition is what makes this continuation worth a closer look.

The Patent at a Glance

  • Publication number: US20260127567A1
  • Title: Application of Dynamic Tokens
  • Kind code: A1 (published application, not yet examined or granted)
  • Inventors: Ryan Hardin; Andrew Hill
  • Assignee: Listed as "Individual" on Google Patents (the filing has no recorded corporate assignee at the time of publication; the USPTO assignment database is the authoritative source for ownership)
  • Filing date: December 30, 2025
  • Publication date: May 7, 2026
  • Application number: 19/437,246 (continuation of 18/616,466)
  • Priority chain: 7 linked filings, original US 9,245,284 filed 2013-07-31, issued 2016-01-26
  • Claims published: 2 (1 independent, 1 dependent)
  • Drawings: 10 figures

The continuation chain matters more than usual here. Every patent in the family has the same two inventors, the same title, and the same fundamental disclosure, but each one refines the claim language. The current continuation's two published claims are the narrowest yet, which is why the headline mechanism is "extend someone else's subscription," not the broader token-economy engine underneath.

The Handshake That Bill Never Went to the Customer

Almost every modern software product runs on a subscription. A chamber of commerce pays $300 a month for a membership platform. A SaaS user pays $9.99 a month for a productivity tool. A nonprofit pays a recurring fee to a CRM vendor. In each case, the bill flows from the entity that uses the service to the entity that provides it. The relationship is direct, and pricing is more or less a sticker price.

This patent starts from a different premise. What if the bill did not flow from the user at all? What if a third party, the sponsor, paid cash into a service platform, and the platform used that cash to mint an internal credit called a token? What if the user, in this filing called an "entity," never wrote a check, and the platform still delivered the service? The filing walks through this idea in fine detail, including the corner cases (what if the sponsor under-funds? what if the entity has leftover tokens? what if the entity's membership size changes mid-month?).

The result is something that looks like a sponsored-content model, but applied to software subscriptions. A local bakery could sponsor the chamber of commerce's CRM and the chamber would still pay $0 out of pocket. A parent could renew a kid's tutoring app after the kid's own balance ran out. None of these are built products, but the patent lays out the contractual and accounting scaffolding that would let a platform do them.

Tokens That Recalculate Themselves

The title says "Dynamic Tokens," and the dynamic part is the heart of the disclosure. Instead of a fixed monthly fee, the platform computes a per-subscription token requirement (the internal quantity of credits a subscriber must produce to receive a service) on the fly, using a formula whose inputs the filing calls customization factors: signals like the entity's member count, the number of sponsorships, or recent activity, with each factor allowed to be turned on, turned off, or weighted individually. The general token-requirement formula is a weighted sum of customization factors, where each f(⋅)f(\cdot) represents one customization function:

tO(i)=α⋅f(xP)+β⋅f(xO)+γ⋅f(N)+δ⋅f(C)+ε⋅f(Mi)+ζ⋅f(MT)+η⋅f(r(S))+θ⋅f(p(D))+ι⋅f(xE)+κ⋅f(A)+λ⋅f(Z)t^{(i)}_O = \alpha \cdot f(x_P) + \beta \cdot f(x_O) + \gamma \cdot f(N) + \delta \cdot f(C) + \varepsilon \cdot f(M_i) + \zeta \cdot f(M_T) + \eta \cdot f(r(S)) + \theta \cdot f(p(D)) + \iota \cdot f(x_E) + \kappa \cdot f(A) + \lambda \cdot f(Z)

Each lowercase Greek letter is a Boolean or a value in the open interval (0,1](0, 1] or [−1,0)[-1, 0), and each f(⋅)f(\cdot) is a customization function the platform can define. The patent lists eleven candidate functions:

  • f(xP)f(x_P) — a price the platform itself sets as a floor
  • f(xO)f(x_O) — a price the entity (subscriber) is willing to pay
  • f(N)f(N) — the number of members associated with the entity
  • f(C)f(C) — the number of contacts (anonymous end-users) in the entity's database
  • f(Mi)f(M_i) — the number of sponsorships of a particular type
  • f(MT)f(M_T) — the total number of sponsorships on the platform
  • f(r(S))f(r(S)) — a function of accepted sponsorship revenue
  • f(p(D))f(p(D)) — a function of membership dues the entity charges
  • f(xE)f(x_E) — a value an external party donates toward the subscription
  • f(A)f(A) — a function of tracked activity (status updates, profile completions, etc.)
  • f(Z)f(Z) — a catch-all the patent leaves open

Eleven Boolean toggles, in other words, can produce up to 211−1=2,0472^{11} - 1 = 2{,}047 distinct token-requirement definitions, all without changing the underlying engine. The patent walks through the combinatorial argument explicitly, then walks through numerical examples.

Here is one of the simpler ones, a piecewise function based purely on membership size NN:

f(N)={50,N≤100100,100<N<2000.1N+100,N≥200f(N) = \begin{cases} 50, & N \le 100 \\ 100, & 100 < N < 200 \\ 0.1 N + 100, & N \ge 200 \end{cases}

If an entity has 40 members, its token requirement is 50. If it has 125 members, the requirement jumps to 100. If it has 500 members, the requirement is 150. The platform can recompute this on a recurring schedule, so a chamber that signs up 60 new members in a quarter can see its bill quietly double in tokens.

The activity-based discount is more interesting. Suppose the platform combines a fixed-price component f(xP)=50f(x_P) = 50 with a negative-weight activity component μ⋅f(A)\mu \cdot f(A), where:

f(A)={0,A<10 or A>2015⋅A,A≥10f(A) = \begin{cases} 0, & A < 10 \text{ or } A > 20 \\ 15 \cdot A, & A \ge 10 \end{cases}

The patent works through one numerical example. A member posts 12 status updates in the prior 30 days. f(xP)=50f(x_P) = 50, μ=−1\mu = -1, and f(A)=15×12=180f(A) = 15 \times 12 = 180. The formula as written gives a final token requirement of −130-130, but the patent states 3232. The math does not add up, but the intuition does. The platform can pay members back in reduced token requirements for engagement signals it can observe.

Two more mechanisms round out the disclosure. The platform can allocate sponsorships by auction: if two parties want the same sponsorship, the higher bid wins, with optional exclusive advertising rights for the winner. The platform also reconciles surpluses and shortfalls on a recurring schedule. Surplus tokens roll over, shortfalls become balances that can be invoiced, and excess surplus can be returned to a designated entity as a "dividend." None of this is crypto. There is no blockchain, no wallet, no token on a public ledger. The platform records the token in its own database as an internal accounting unit.

The Sponsor, the Platform, the Subscriber

The full picture, stripped of all the patent's internal flowcharts, is just three actors and two hops. A sponsor pays cash. The platform converts the cash into tokens and applies them against an entity's dynamically computed requirement. When the requirement is met, the platform delivers the service to the entity, and the entity's own bank account never sees a debit.

Core Architecture/Flow

The diagram is intentionally minimal. The orange ellipse on the left is the sponsor, the warm-colored origin of the cash. The blue rectangle in the middle is the platform, doing the work of converting cash into tokens and running the dynamic-formula engine. The green ellipse on the right is the entity, the recipient of the service. The first arrow carries a number ("→ 100 tokens"), the concrete evidence that something tangible crossed the boundary. The second arrow carries a status check ("✓ requirement met"), the concrete evidence that the system worked.

The formula inside the platform box, f(members, contacts, sponsors, activity)f(\text{members, contacts, sponsors, activity}), is the patent's whole point reduced to a single line: prices are not static, they are a function of the entity's own data.

What the Two Published Claims Actually Ask For

Both claims are short. Claim 1 is an independent claim (a stand-alone claim that defines the invention without leaning on any other claim) and claim 2 is a dependent claim, layering an extra limitation on top of claim 1 and inheriting everything claim 1 already covers. Here is claim 1 in full:

A method for improving delivery of services having token requirements, comprising: receiving, from a first device associated with a first user and an executing application, identity of the first user, wherein the identity includes a unique identifier and is received in a communication associated with the executing application; determining an expiration of an application subscription of a third party; determining that the third party is eligible to have the application subscription extended by the first user based on the expiration of the application subscription being within a predetermined period of time of a current date; transmitting an eligibility indication to the first device; receiving confirmation of payment by the first user to extend the application subscription of the third party; applying an extension to the application subscription of the third party in response to the confirmation of payment; and notifying the third party of the extension to the application subscription.

And claim 2, the only dependent claim:

The method of claim 1 wherein, receiving the identity of the first user includes registering the first user for the delivery of services.

The applicant kept the scope narrow on purpose. They are not trying to monopolize the entire token-economy architecture disclosed in the 193-paragraph specification. They are trying to lock down a specific workflow: an authenticated user of a client app, looking at a third party's soon-to-expire subscription, paying to extend it, and the system applying the extension. The predetermined "eligibility window" (the third party's expiration is within a set time of today) is the only algorithmic novelty, and even that is a fairly common "renewal nudge" pattern from consumer SaaS.

The broader token-platform architecture, including the customization-factor formula, the sponsorship auctions, the dividend engine, the OAuth dance with the third-party payment processor, all of that lives in the specification but is not in the published claims. That is the long-standing split in patent law: the specification teaches, the claims own. The continuation is teaching the world about the bigger system while asking for protection on a much smaller workflow.

Why Twelve Years of Continuations Is the Real Story

A continuation chain this long is unusual. Two or three generations is the norm, and the cost of repeated examination, along with the shifting standards of patentable subject matter, pushes most applicants to settle long before they reach a seventh filing. Read across the 12-year chain, the patent trail is a logbook of a single idea, refined in public, claim by claim.

There are three plausible reasons. First, the underlying idea, that subscriptions can be funded by a sponsor's cash via internal tokens, is a new pricing category. It is not crypto, not advertising, not freemium, not gift cards. The inventor may be working on a real product around it. Second, the continuation strategy keeps the priority date anchored at 2013, which is useful if the inventor ever wants to assert the broader claims in litigation. Third, the early-filed original (US 9,245,284) is now in the public prior art window, so competitors are reading it. Continuing the chain keeps the latest claim language in force while letting older patents lapse naturally.

Whatever the motive, the practical effect is a thick trail of public disclosure. Anyone trying to build a tokenized-subscription system today has a free, detailed walkthrough of one such design, including the math, the entity model, the OAuth flow, and the corner cases. The patent is more useful as a blueprint than as a weapon.

From Filing to Enforcement: What This Patent Does Not Yet Prove

A few caveats are worth stating out loud, because the gap between "patent application published" and "enforceable patent" is wide.

  • Pending, not granted. The two published claims reflect what the applicant is asking the USPTO to allow. The USPTO has not yet allowed them. An examiner has not yet reviewed the application. Claim scope, and even the number of claims that survive, can change substantially during prosecution (the back-and-forth between the applicant and a USPTO examiner that turns a filed application into an issued patent, or rejects it). Until that process finishes, the application is not enforceable against anyone.
  • Assignee ambiguity. Google Patents lists the assignee (the legal owner of the patent, who would collect license fees or damages if the patent were enforced) as "Individual," with the explicit note that the listing may be inaccurate. The USPTO assignment database is the authoritative source, and it may show a different owner of record.
  • No product, no benchmarks, no deployment data. The filing is a method and platform design on paper. There is no evidence in the public record that the system has been built, deployed, or used at scale. The disclosure is an architectural proposal, not a working system.
  • The "translated from" tags are a UI artifact. Google Patents flags the abstract and claims as "translated from," but the text is fluent English with no source language identified. The tags are a quirk of Google's rendering pipeline, not evidence of a foreign-filed original.
  • Independent claim 1 is narrow. Even if granted as written, claim 1 only covers a specific multi-step method for extending a third-party subscription when (a) the user is authenticated, (b) the third party's subscription is within a predetermined eligibility window, and (c) the user pays. Most plausible competing systems would design around at least one of those steps.

The most important caveat, though, is about the broader token-economy architecture. The patent describes it in detail across 10 figures and 193 paragraphs, but the published claims do not protect it. If you are a developer reading this and thinking "I want to build that," the path of least resistance is to design your own token-requirement formula, your own customization factors, and your own eligibility windows, and to skip the renewal-extension workflow that the only published claim actually targets.

The single best thing about this filing is what it shows: a serious, almost 13-year effort to design a non-crypto token economy, in patent form. That is why it is worth a newsletter. The filing is more candid than a white paper and more rigorous than a blog post. It is a public, citable, line-numbered description of how a system could work. The inventor includes worked numerical examples and a combinatorial argument for how many configurations the system can express. If the broader disclosure ever becomes the basis for a real product, the patent trail will read as a 12-year logbook of a single idea, refined in public, claim by claim.

Sources