Akkapeddi & Sanghvi · Granted Apr 21, 2026

Blockchain Transfer Requests

A blockchain pull-payment protocol: the requester generates digital tokens equal to the requested amount and sends them to the payer's data file as a structured payment demand. The payer returns the tokens along with data objects as proof of settlement — the token receipt is the confirmation. Smart contracts encode recurring schedules, multi-payer simultaneous splits, and cascading sub-delegation chains where the received amount automatically flows outward to a fourth data file.

US12609917B2Patent

Jan 17, 2024Filed

27 monthsTime to grant

20 Claims / 3 IndependentSystem, Method, CRM

2 InventorsAkkapeddi & Sanghvi

SCROLL TO EXPLORE

Visual patent explainer

02 / The Problem

Blockchain transfers are push-only: the sender initiates. There's no native blockchain protocol for requesting payment — for the recipient to generate a structured demand that the payer must fulfill.

Standard blockchain transaction flow is unidirectional: the payer initiates, signs, and broadcasts a transaction. The payee is passive — they receive whatever the payer sends. This creates a fundamental gap in blockchain-based financial infrastructure: no mechanism exists for the payee to generate a formal, structured payment request that is addressed to a specific payer's data file, carries metadata (reason, due date, requester identity), and provides a cryptographic settlement confirmation when fulfilled.

No Pull-Payment Native MechanismInvoice and bill-payment scenarios require a second communication channel (email, bank portal, EDI) to carry the payment request — the blockchain itself carries only the eventual transfer. The request and the settlement are disconnected across two different systems

No Structured Request + Receipt PairWhen a payer fulfills an obligation, neither party has a blockchain-native record that proves (a) a request was made, (b) by whom and for what, and (c) that the specific request was fulfilled. Settlement proofs require off-chain reconciliation against off-chain records

No Multi-Payer Request BroadcastA payee who needs to collect from multiple payers simultaneously (shared expense, group invoice) must generate and track separate payment requests for each payer off-chain, with no on-chain coordination or confirmation of which payers have settled and which haven't

03 / The Invention

The requester generates tokens equal to the requested amount and sends them as the request. The payer returns those exact tokens with data objects. Token receipt = settlement proof. The token is both the demand and the receipt.

The first user (requester) generates digital tokens equal to the amount they're requesting from the second user (payer). These tokens are transmitted to the second user's data file on the blockchain, along with request metadata: the requester's identity, the reason for the request, and a due date. The token transmission is the payment request — it's a pull request encoded directly on the blockchain.

When the second user fulfills the request, they transmit the tokens back to the requester's data file — along with the corresponding data objects (the actual value being transferred). The requester's receipt of these tokens constitutes proof of settlement: the system confirms that the specific tokens that were sent as a request have been returned, along with the accompanying value. No off-chain reconciliation is needed — the token lifecycle on the blockchain documents both the request and its fulfillment.

04 / Token Flow

Four steps: requester generates tokens, sends them as demand, payer returns tokens + data objects, receipt confirms settlement.

The pull-payment flow is symmetric: tokens flow from requester to payer as the demand, and back from payer to requester as the confirmation. The data objects (the actual value being transferred) flow in one direction only — from payer to requester. The token round-trip is the settlement protocol.

Pull-Payment Token Flow — US12609917B2

Step 1

Requester Generates Tokens First user generates digital tokens = requested amount. Tokens represent the payment demand, not a value transfer — they are markers, not the payment itself.

Step 2

Request Sent to Payer's Data File Tokens transmitted to second user's data file. Request metadata accompanies: requester identity, reason, due date. This is the pull-payment demand — on-chain, structured, addressable.

Step 3

Payer Returns Tokens + Data Objects Second user fulfills the request: returns the tokens to the requester's data file + transmits data objects (the actual value — funds, assets, or digital resources) to the requester.

Step 4

Receipt = Settlement Proof Requester's receipt of the returned tokens, along with the data objects, constitutes on-chain proof of settlement. The token lifecycle documents request + fulfillment in a single blockchain record.

05 / Claim Layers

20 claims across three independent forms — system, method, CRM — with six dependent layers adding recurring schedules, multi-payer support, and cascading sub-delegation.

The core pull-payment protocol is captured in three independent claims. Six dependent claim layers build on each, adding progressively more complex transfer scenarios: smart contract governance, recurring schedule execution, simultaneous multi-payer collection, cascading outflow to a fourth data file, and partial transfer with sub-delegation.

Claim Architecture — US12609917B2

Claims 1/8/15 — Core

Requester generates tokens = amount, sends to payer's file with metadata, payer returns tokens + data objects, receipt = settlement proof

Claims 2/9/16 — Smart Contract

Smart contract stored at data file governs transfer rules — encoding the obligation and automatically managing the token exchange protocol

Claims 3/10/17 — Recurring

Smart contract auto-executes on recurring schedule — monthly subscription, quarterly payment, annual recurring obligation — without manual re-initiation per period

Claims 4/11/18 — Multi-Payer

Simultaneous transfer from second AND third data file — requester collects from multiple payers in a single request cycle, both returning tokens + data objects concurrently

Claims 5/12/19 — Cascading

After receiving from two sources, system automatically transfers combined amount outbound to a fourth data file — cascading payment chain fully encoded on-chain

Claims 6/13/20 — Partial

Partial transfer only: a portion of received amount forwarded to a third data file. Sub-delegation: requester receives partial and routes the remainder

06 / Pull-Payment Scenarios

Single payer, recurring smart contract, multi-payer split, sub-delegation chain — four pull-payment scenarios through the blockchain request protocol.

Select a scenario to trace a pull-payment request through the blockchain — from token generation through settlement confirmation.

Pull-Payment Flow Scenarios

07 / Cascading Transfers

After collecting from two payers simultaneously, the system automatically routes the combined amount outward to a fourth data file — a fully on-chain cascading payment chain.

Claims 5/12/19 add a cascading transfer layer: once the requester has received tokens and data objects from both the second and third data files (multi-payer collection), the system automatically initiates an outbound transfer of the combined received amount to a fourth data file. This completes a multi-hop payment chain entirely on-chain: request → collect from two sources → forward to destination.

This architecture enables complex financial workflows that previously required off-chain orchestration: a supplier collecting from multiple buyers and forwarding to a distributor, an escrow account collecting partial payments and releasing to a payee when fully funded, or a shared expense manager collecting from group members and forwarding to the vendor — all executed as a single blockchain transaction flow with no off-chain coordination layer.

Multi-Hop Cascading Flow — US12609917B2

Request Phase

Requester generates tokens and sends pull-payment request to both second and third data files simultaneously. Each file receives the request with metadata — amount, reason, due date.

Collection Phase

Second data file: returns tokens + data objects. Third data file: returns tokens + data objects. Both return paths complete — requester's data file now holds both received amounts.

Cascade Phase

System automatically initiates outbound transfer of combined received amount to fourth data file. No additional user action required — the cascade is encoded in the smart contract at the requester's data file.

On-Chain Audit Trail

Every hop — request to payer 2, request to payer 3, receipt from payer 2, receipt from payer 3, outbound to file 4 — is recorded on-chain as token movements. Full payment chain is auditable from the blockchain.

08 / Applications

Recurring invoices, shared expenses, multi-party escrow, and supplier payment chains — pull-payment brings blockchain's settlement efficiency to the request side of finance.

The pull-payment model maps naturally to a wide range of real-world financial scenarios where the payee initiates the payment process — invoicing, subscription billing, shared expense collection, and multi-party settlement chains. Encoding the request on-chain with the same rigor as the payment itself creates a complete end-to-end blockchain record of the obligation lifecycle.

Use Cases — US12609917B2

Express

Recurring Subscription Billing SaaS platform tokenizes monthly subscription as a pull-payment smart contract. Each billing period: smart contract auto-executes — generates tokens = monthly fee, sends to subscriber's data file. Subscriber's data file (pre-authorized) returns tokens + data objects automatically on due date. No manual payment initiation. Subscription history: full on-chain record of every monthly token exchange. Cancellation: smart contract termination stops further auto-execution.

Express

Shared Expense Collection Group of four colleagues shares a $1,200 quarterly expense. One colleague generates pull-payment tokens = $300 each and sends to the other three data files simultaneously (multi-payer claim). Each files returns tokens + data objects. Requester's receipt of all three confirms full collection. Smart contract cascades the combined $1,200 outbound to the vendor's data file. Full shared expense settled on-chain in one transaction cycle.

Express

Invoice Factoring Supplier issues pull-payment request to buyer for $50,000 invoice, due in 30 days. Partial transfer claim: supplier immediately routes $47,000 portion to a factoring firm's data file (sub-delegation for early liquidity). Requester retains $3,000 as factoring fee offset. On due date: buyer returns tokens + data objects. Settlement confirmed on-chain. Factoring firm's tokens confirmed. Full invoice lifecycle — issuance, partial sub-delegation, settlement — documented on the blockchain.

Inferred

DeFi Yield Collection Liquidity provider deploys capital across multiple DeFi pools. Pull-payment smart contracts generate yield collection requests to each pool's data file on a recurring schedule. Each pool returns tokens + accumulated yield data objects automatically. Cascading transfer: collected yield automatically forwarded to reinvestment vault. Compounding cycle runs fully on-chain — no off-chain yield aggregator, no manual claim transaction per pool.

09 / Citations

Forward Citations

No third-party forward citations found as of this check. US12609917B2 was granted April 21, 2026 — approximately two months ago. Citation data has not yet accumulated. Verify the current list on Google Patents.

Forward citation check: Jun 23, 2026 · Static fetch; Google Patents citations are JS-rendered

Forward Citations — US12609917B2

No citations yet — patent too recent Granted Apr 21, 2026 — ~2 months old at time of check Check Google Patents for the current forward citation list.

10 / Sibling Patents

P33 and P34 are sibling patents — same filing date, same inventors, complementary mechanics. P33 is the pull-payment (request) side; P34 is the delegation (pre-authorization) side.

Patents 33 and 34 were filed on the same day (January 17, 2024) by the same two inventors: Naga Vamsi Krishna Akkapeddi and Siten Sanghvi. Both were published as pre-grant applications on July 17, 2025. They address complementary blockchain payment mechanics that together cover the full spectrum of non-initiator-controlled transfers.

P33 (this patent) handles the pull model: the payee initiates by sending a token-encoded request to the payer's data file. The payer's response — returning the tokens with data objects — is the settlement event. P34 handles the delegation model: the first user pre-authorizes a second user by sending tokens to their data file ahead of time, and when an entity requests payment from the first user, the second user's pre-positioned tokens are used as the authorization mechanism. Two different non-push payment architectures, coordinated filing.

P33 + P34 — Filed Jan 17, 2024 · Same Inventors

P33 · Pull-Payment Request

Requester sends tokens as demand. Payer returns tokens + data objects as settlement. Token round-trip = on-chain proof of obligation + fulfillment. Smart contract governs recurring, multi-payer, and cascading flows.

P34 · Delegated Transfer

First user pre-authorizes second user by sending tokens to their data file. When entity requests payment from first user, second user's tokens serve as the authorization. Smart contract encodes authorization rules, per-transfer cap, and type whitelist.

Shared Inventors

Naga Vamsi Krishna Akkapeddi and Siten Sanghvi — joint inventors on both P33 and P34. Both patents share the blockchain data file architecture and token-as-protocol design philosophy.

Combined Coverage

P33 (pull-payment) + P34 (delegation) together cover two distinct modes of payer-agnostic blockchain transfer: payee-initiated demand and first-user pre-authorization. Neither requires the paying party to initiate the original transaction.

11 / Timeline

Patent Lifecycle

Jan 17, 2024

Filed

Filed same day as P34 (US12452066B2) — sibling blockchain patents

18 months

Jul 17, 2025

Published

Pre-grant publication US20250233851A1 — same date as P34

9 months

Apr 21, 2026

Granted

US12609917B2 granted — 27 months from filing

~18 years

Aug 18, 2044

Expires

Adjusted expiration with Patent Term Adjustment

Read the granted patent Browse all patents

End / Patent 33