Siten Sanghvi / Granted August 4, 2020
File Transmission Validation
and Failure Location
A cryptographic system that knows exactly which block in a large-scale file transfer broke — and recovers it in isolation. At scale: instant integrity verification of trillions of records via a single Merkle root comparison.
US10735199B2Patent number
2018-01-02Filed
2 yr 7 moTime to grant
17 Claims3 independent
10 CitationsForward citations
SCROLL TO TRACE THE SYSTEM
Visual patent explainer
01 / The problem
One corrupted block.
Resend everything.
Enormous datasets travel as file payloads: genomic archives, satellite telemetry, financial settlement batches, medical imaging records. These are millions of structured records, packed into blocks, transmitted in bulk.
Millions of blocks.
A single corrupted block had no traceable location. The entire transfer had to restart. This was the state of the art before this patent.
"The trailer validation would fail but it would not tell the user which block had an issue. As such, the whole file would need to be re-transmitted." — Patent specification
How transfers failed before this patent
📡
A massive file payload queued for transmission
Genomic data, settlement records, imaging archives, telemetry — all block-structured
➡️
Transfer begins, block by block across the network
Could be thousands of blocks across a high-latency connection
⚡
Block N silently corrupts mid-transfer
Bit rot, packet loss, hardware fault, transient network error
❌
Trailer checksum fails at the receiver
Something is wrong. But which block? No information available.
🔄
Entire file retransmitted from block one
99.999% of valid blocks resent unnecessarily. Downstream processes stall.
💡
What if only the corrupted block was resent?
That is the precise problem this patent solves.
02 / The inventive move
Apply blockchain hash-chaining to file block validation.
Three ideas, working together, that no prior system combined in this way.
The inventive combination
01
Hash-Chained Blocks
Each block's fingerprint embeds the fingerprint of its predecessor. Corruption breaks every hash downstream — that cascade is the detection mechanism.
H(n) = hash(data_n + H(n-1)) — Altering a single bit in block N cascades through every subsequent hash. The first divergence pinpoints the failure address exactly.
02
Private Blockchain Network
A permissioned network of enterprise servers stores hash keys across all nodes simultaneously — an immutable audit trail before the file even arrives.
Only whitelisted nodes write to the chain. The private chain stores hash keys, not file data — every node independently holds ground truth for every transmission.
03
Surgical Retransmission
Once the failure block is identified — via linear back-search or Merkle tree traversal — only that block is retransmitted and integrated without discarding the rest.
In multi-file batches, the Merkle tree identifies which file in O(log n) steps; the hash chain identifies which block. One million blocks: one block resent.
03 / System architecture
The private blockchain witnesses every transmission — before and after delivery.
3
Authorized nodes hold identical hash records
0
Single points of failure in the hash store
100%
Audit trail before file reaches destination
04 / Hash chain mechanics
Click a block to corrupt it.
Watch the cascade. Then fix it.
Any collision-resistant hash function works: SHA-256, SHA-3, BLAKE2b, or future standards. The patent claims the chaining architecture, not a specific algorithm.
05 / Transmission structure
Three files travel together.
Two verify. One transmits.
01
Raw Data File
The actual payload: all data blocks in sequence — genomic sequences, transaction records, sensor readings, imaging metadata.
B1
B2
B3
…N
May include legacy format conversion during transmission — the system handles format normalization as blocks are prepared, so the receiver always gets a consistent structure regardless of the sender's legacy format.
02
Hash Chain File
One chained hash per block. Each hash encodes its block's data plus the previous block's hash. Also stored simultaneously on the private blockchain as immutable keys.
H1
H2
H3
…N
These hashes are used during the back-search phase. When the control hash fails, the system walks these block hashes to find the first divergence. Also the key source for any Merkle tree construction over multiple batches.
03
Control Hash File
A single hash of the entire file. The first check run at the receiver — a fast pass/fail gate. If it matches, no further processing needed. Mismatch triggers block-level investigation.
CTRL HASH
This two-tier design is critical for efficiency: on successful transfers (the overwhelming majority), only one hash comparison is performed. Block-level work is reserved for the rare failure case, keeping system load minimal.
Hover each file to see deeper technical context. The two-tier design means successful transfers cost one hash comparison. Failures cost O(log n) via tree traversal or O(n) via back-search.
06 / Failure detection and recovery
Find it. Fix it. Only that block.
Watch the two-tier validation execute in real time. The control hash acts as the fast gate; block-level back-search pinpoints the exact failure location.
2-tier
Validation gates
O(log n)
Tree traversal depth
1 block
Retransmitted vs millions
01
File Arrives
02
Control Hash Check
03
Mismatch Detected
04
Back-Search Begins
05
Block 3 Isolated
06
Retransmit Block 3
07
Validated
validation.log
$ click "Run Simulation" to begin_
07 / Merkle tree extension
Trillions of records.
One comparison.
At the Merkle root level, a single hash comparison verifies the integrity of an arbitrarily large dataset in microseconds. Click nodes in the tree to trace verification paths.
Traversal algorithms
Once the root hash fails, multiple search strategies locate the corrupted subtree: Binary search (halve each step), BFS (level-by-level), DFS (depth-first), or probabilistic skip for known-fragile segments. All converge in O(log n) comparisons.
Scale
A Merkle tree over 1 trillion transactions requires at most 40 comparisons to locate any corrupted record. At 10 billion transactions per second, the entire tree can be re-verified faster than a network round-trip.
Click a node in the tree to trace its verification path.
08 / Real-world applications
Wherever large data moves
and errors are expensive.
Application landscape
09 / Forward citations
Industry leaders built on this foundation.
When DocuSign, Wells Fargo, Dell, and Verizon need to patent innovations in data integrity and blockchain infrastructure — they cite this work as prior art.
These are forward patent citations. A citation shows relevance to later patent examination or disclosure; it does not by itself prove commercial use.
Forward citations shown by Google Patents / checked June 10, 2026
DocuSign
Wells Fargo
Dell
Verizon
iText Group
Optum
+ 4 more
Also cited by: Casio Computer Co. (JP2024172126A, 2024) and 浙江省金融综合服务平台 (CN115239339B, 2023). 10 total forward citations.
10 / Patent lifecycle
From insight to granted protection.
Active and building citations.
Jan 2, 2018
Priority Filed
Provisional application filed
establishing priority date
establishing priority date
2 yrs 7 mo
Aug 4, 2020
Patent Granted
USPTO granted US10735199B2
17 claims, 9 figures
17 claims, 9 figures
1 yr 4 mo
Late 2021
First 3 Citations
Wells Fargo, Duvon, and Verizon
cite this patent in their filings
cite this patent in their filings
1 year
2022
DocuSign + iText
Two major document platforms
cite this work independently
cite this work independently
2 years
2024
Dell + Optum
Enterprise infrastructure and
healthcare analytics citations
healthcare analytics citations
1+ year
2025 onward
Active
Citations continue growing
across multiple industries
across multiple industries
CPC Classifications
H04L9/3236 · Cryptographic Hash Functions
H04L9/50 · Blockchain and Hash Trees
H04L63/123 · Message Integrity Verification
H04L9/0643 · SHA-family Hash Functions
All patents are US-granted. Views are my own. This explainer is educational only — no confidential, proprietary, or non-public information is disclosed.
End / Patent 01