Patent 29 / Token Rules Generation
01 / 11 US12368708B2
↑↓ navigate  ·  all patents →
Siten Sanghvi et al.  ·  Granted Jul 22, 2025

Token Rules Generation

A blockchain token customization engine: rules are built directly into tokens at creation — geofencing restrictions that limit where a token can be transferred, alert thresholds that fire when value crosses a boundary, automated triggers that execute trades without manual intervention, and hidden governance layers accessible only to authorized parties. All rules are immutably encoded and memorialized on the distributed ledger the moment the token is created.

US12368708B2Patent
Dec 5, 2022Filed
31 monthsTime to grant
System / Method / CRM3 independent claims
6 InventorsTeam
SCROLL TO EXPLORE
Visual patent explainer
02 / The Problem

Blockchain tokens are programmable — but their rules live outside the token in smart contracts that anyone can read, modify, or ignore.

Smart contracts on blockchain networks can encode logic that governs token behavior. But traditional smart contract architectures keep the rules separate from the tokens themselves — the token is just a value representation, and the rules are enforced externally. This creates a gap: rules can be changed post-deployment, bypassed by interacting with the token directly, or leaked because they're publicly visible on the ledger.

Rules Separate from TokensSmart contracts enforce behavior externally — a token can exist and transfer without necessarily passing through the intended rules layer, especially when interacting via non-standard paths
No Layered GovernanceDifferent stakeholders — institution, regulator, individual — may need different visibility into, and control over, the same token's rules. Flat smart contracts don't support layered access models natively
No Geographic Restriction LayerTokens that should be restricted to specific jurisdictions have no built-in enforcement mechanism — geofencing requires off-chain oracle integration or custom contract logic per token type
03 / The Invention

Rules are embedded into the token at creation — not enforced externally. The token carries its own governance layer.

The token customization module allows users to build rules directly into a token before it's issued on the distributed ledger. The token customization engine, transaction customization engine, and rules engine work together through a drag-and-drop user interface: a user selects from available rule templates, configures parameters, and the resulting rule set is baked into the token definition.

Once created, the customized rules are incorporated into the token and immutably memorialized in the distributed ledger. The token cannot be transferred, traded, or modified in ways that violate its embedded rules — the rules travel with the token. A smart contract can be associated with or incorporated into the token to layer additional functionality on top of the embedded rule set.

04 / Rule Types

Four core rule categories: geofencing, alerts, automated transactions, and layered hidden governance.

The customization system supports distinct rule types that can be combined. Geofencing rules gate transfers by geography — a token issued in one jurisdiction can be restricted from transferring to another based on device metadata, personal identifiers, or transaction location signals. Alert rules trigger notifications when value or properties cross defined thresholds.

Automated transaction rules enable the token to self-execute: when value reaches a threshold, the token can automatically convert from crypto to fiat, execute a trade, or trigger a linked smart contract operation — without manual authorization at execution time. Hidden rule layers add a governance dimension: certain rules are not visible to standard users, only to authorized parties with the right access credentials.

Rule Type Architecture — US12368708B2

Geofencing Rules

Restrict token transfers to specific geographic regions. Enforced using device location, transaction metadata, or personal identifier geography. Country, region, state, and locality granularity.

Alert / Threshold Rules

Trigger notifications when the token or linked property value meets, exceeds, or falls below a defined threshold. Configurable recipients and delivery channels.

Auto-Execute Rules

Automatically execute a transaction when a value condition is met — crypto-to-fiat conversion, trade execution, or transfer initiation — without requiring user action at execution time.

Hidden Rule Layers

Authorization-controlled rule layers that are not visible to standard token holders. The rules engine always has access; specific users or groups see only what they're authorized to see.

05 / Rule Hierarchy

Seven-layer rule hierarchy — country down to personal. Each layer independently configurable, independently accessible.

The customization system implements a layered rule hierarchy where each level can define its own rules, independently of the others. Layers cascade: higher levels (country, region) set outer bounds; lower levels (institution, personal) add specificity within those bounds. Any layer can be independently modified by authorized parties.

Rule Layer Stack — US12368708B2
Layer 1
Country
Broadest jurisdiction. Sets the outer compliance envelope — which sovereign rules apply to this token's lifecycle.
Layer 2
Region
Sub-national jurisdiction (EU, US-East, APAC). Regional regulatory requirements or commercial restrictions.
Layer 3
State / Province
State-level compliance. Money transmitter license jurisdictions, state-specific financial product rules.
Layer 4
Locality
City/county level. Hyper-local restrictions such as municipal bond issuance rules or local commerce limits.
Layer 5
Industry
Sector-specific rules. Different behavior for securities, insurance, lending, and retail token types.
Layer 6
Institution
Issuing institution's specific policies — transfer fees, counterparty whitelists, AML controls.
Layer 7
Personal
Individual user preferences — spending limits, notification settings, authorized counterparties.
06 / Rule Builder

Geofencing, alert threshold, auto-execute, and hidden governance — four rule types, each embedded at token creation.

Select a rule type to see how it's configured in the token customization module and what happens when the rule fires.

Token Rule Scenarios
07 / Smart Contract Layer

Smart contracts layer additional functionality on top of the embedded rule set — and can split a single token into multiple rule-differentiated layers.

Once a token's base rules are embedded, an associated smart contract can be linked or incorporated to extend behavior. The smart contract can trigger state changes in the token, enforce multi-party conditions, and — critically — split a transaction into multiple token layers, each governed by different embedded rules.

The system supports template reuse: a customized token or smart contract configuration can be saved as a template and shared with other users of the distributed ledger platform. This enables institutions to define standard token types with pre-configured rule sets that counterparties can adopt directly, reducing configuration overhead while maintaining governance consistency.

Smart Contract Integration — US12368708B2

Token-Smart Contract Link

Smart contract associated with or incorporated into the token at creation. Extends rule capabilities beyond what embedded rules alone can express.

Transaction Splitting

Smart contract can split a single transaction into multiple token layers — each layer with its own embedded rules. One payment can fork into fee, principal, and escrow components with different governance.

KYC Integration

Rules engine integrates with KYC (Know Your Customer) data stored in the distributed ledger system — restricting token transfers based on counterparty identity verification status.

Template Repository

Customized tokens and smart contract configurations saveable as templates. Institutions publish standard token types; counterparties adopt pre-configured templates directly.

08 / Applications

Jurisdiction-aware digital assets, self-enforcing financial instruments, and compliance-by-construction token issuance.

The core innovation — rules embedded in the token, not enforced externally — enables a class of digital assets that are self-governing and self-enforcing. The token carries its compliance constraints with it, independent of which platform, wallet, or counterparty it encounters.

Use Cases — US12368708B2
Express
Jurisdiction-Locked Security Token Token issued for a US-registered security. Geofencing rule embedded at creation: cannot transfer to wallets with non-US identifiers. No external oracle or platform enforcement needed — the token itself enforces the restriction. Compliant by construction across any blockchain platform that reads its embedded rules.
Express
Auto-Converting Stablecoin Corporate treasury token with embedded auto-execute rule: when token value is presented at a merchant terminal, automatically convert to local fiat currency at current exchange rate before settlement. Conversion logic is in the token — no middleware integration required at the point of sale.
Express
Layered Loan Token Mortgage-backed token with 7-layer rule stack. Country layer: US mortgage law. Institution layer: lender underwriting constraints. Personal layer: borrower payment schedule and prepayment penalties. Hidden layer (regulatory): servicer reporting obligations not visible to borrower. One token, full governance stack embedded.
Express
DeFi Platform Integration Token issued via DeFi lending, trading, or insurance platform. Platform-specific rules (collateral ratios, liquidation thresholds, coverage limits) embedded at issuance. Token can operate across multiple DeFi platforms while carrying its origin platform's risk parameters as embedded constraints.
09 / Citations

Forward Citations

No forward citations found as of this check. US12368708B2 was granted July 2025 — citation data is still accumulating. Verify the current list on Google Patents.

Forward citation check: Jun 23, 2026 · Static fetch; Google Patents citations are JS-rendered
Forward Citations — US12368708B2
No citations available yet Granted Jul 2025 — citation index still populating Check Google Patents for the current forward citation list.
10 / Blockchain Cluster

Three blockchain patents in sequence — token rules, token split/burn, and blockchain transfer requests — each covering a different layer of the token lifecycle.

Patents 29, 30, and 33 form a loose cluster around distributed ledger token infrastructure. Patent 29 (this patent) governs token creation — rules embedded at issuance. Patent 30 covers token lifecycle management — how a token splits into multiple tokens with on-chain burn of the original. Patent 33 addresses token-based transfer requests — using tokens as structured payment demands between data files in a blockchain network.

Patent 28 (NFT Auto-Segmentation) covers the orthogonal ML-routing dimension — where NFTs live based on their tier score. Together, these four patents cover token creation, governance, lifecycle management, transfer mechanics, and storage optimization — a comprehensive suite of blockchain token infrastructure patents.

Blockchain Patent Cluster

P29 · This Patent — Rules at Issuance

Geofencing, alert, auto-execute, and hidden governance rules embedded into the token at creation. The token carries its compliance constraints with it across any platform.

P30 · Token Split & Burn

One token splits into two: two new blocks both fork from the same preceding block. Original token burned (locked to dead wallet). Distributed node propagation of new token state.

P33 · Transfer Request Protocol

Blockchain pull payment: requesting party generates and sends tokens to the payer as a structured request. Tokens return with data objects as proof of settlement — the token is the receipt.

P28 · NFT ML Routing

Two-model ML platform scores NFTs and routes to distributed ledger or local storage based on tier threshold. Social media signals update scores in real time. Covers the storage layer.

11 / Timeline

Patent Lifecycle

Dec 5, 2022
Filed
Application filed — B2 patent
18 months
Jun 6, 2024
Published
Pre-grant publication US20240187399A1
13 months
Jul 22, 2025
Granted
US12368708B2 granted — 31 months from filing
~18 years
Jun 5, 2043
Expires
Adjusted expiration with Patent Term Adjustment
End / Patent 29