A zero-knowledge proof (ZKP) is a cryptographic protocol in which a prover convinces a verifier that some statement is true — “I know the password,” “this transaction is valid,” “my balance exceeds the amount” — while revealing nothing beyond the truth of the statement itself. On a public blockchain, where every record is visible, that property is the basis for on-chain privacy and for scaling schemes that verify computation cheaply. A “zero-knowledge proof patent” is not a claim on that mathematical concept, which is decades old and unpatentable as an abstract idea. It is a claim on a specific implemented method — the concrete steps of generating, transmitting, and validating a proof inside a particular system. To read one correctly, you read the steps the independent claim recites.

Consider an issued grant assigned to International Business Machines Corporation, US11323243B2, titled “Zero-knowledge proof for blockchain endorsement.” Rather than claiming ZKPs in the abstract, its abstract walks a defined sequence of operations:

“An example operation may include one or more of receiving one or more responses to a storage request for a blockchain from one or more endorser nodes of the blockchain, extracting transaction data of the storage request included in the one or more responses, generating a zero-knowledge proof of endorsement based on the extracted transaction data and the one or more responses, and transmitting the zero-knowledge proof to a blockchain node for inclusion within a data block among a hash-linked chain of data blocks.”— Zero-knowledge proof for blockchain endorsement, US11323243B2

Notice what carries the claim: the specificity. It is not “use a zero-knowledge proof on a blockchain.” It is a particular pipeline — receive endorser-node responses, extract transaction data, generate a proof of endorsement from that data, and transmit it for inclusion in a hash-linked block. The limitations name the actors (endorser nodes), the input (transaction data from the responses), the artifact (a zero-knowledge proof of endorsement), and the destination (a data block in the chain). That detail is what distinguishes the claim from the bare idea and is what an examiner relied on. A different ZKP system that proves something else, or routes the proof differently, may fall outside this claim entirely — which is the whole point of reading limitations rather than titles.

The same pattern in a payments grant

The structure recurs across assignees. American Express Travel Related Services Company holds US12093948B2, “Zero-knowledge proof payments using blockchain.” Its abstract describes a system of “a customer device, a merchant system, an issuer system, and a blockchain network having a zero-knowledge proof (ZKP) smart contract,” implementing a ZKP algorithm “having a key generator function, a proof function, and a validate function.” Again the patent does not reach for the concept; it recites named components and three named functions — key generation, proof, and validation — bound to a smart contract on a blockchain network. Its CPC profile bears this out, combining payment codes (G06Q 20/389, G06Q 20/3827) with cryptography and blockchain codes (H04L 9/3221, H04L 9/50). The claim's footprint is the intersection of a payment protocol and a verifiable proof, not the proof technique alone.

How to read a ZK patent without overstating it

It is also worth noting what the cluster of ZK grants does not establish. The fact that multiple assignees — a technology company, a card issuer, a custody provider, an identity firm — each hold zero-knowledge-proof grants does not mean they hold overlapping or conflicting rights. Because each claim is fenced around a specific application (endorsement of a blockchain storage request in one, a merchant-payment flow in another, an authentication-data match in a third), the grants can coexist precisely because they recite different combinations. A reader who sees “ten companies hold zero-knowledge-proof patents” and infers a thicket of conflict is over-reading; what the records more often show is parallel, non-overlapping coverage of distinct use cases, each anchored in its own claim language. The shared phrase “zero-knowledge proof” in the titles is the least informative thing about them. The informative part is the verb sequence and the named domain inside each independent claim, which is exactly where scope — and the boundaries between one grant and the next — actually lives.

Three habits keep the reading honest. First, separate the mathematics from the claim: the soundness and zero-knowledge properties of a proof system are mathematical facts no patent owns; what a patent can own is a specific apparatus or method that uses such a proof in a defined way. Second, find the verb sequence in claim 1 — generate, transmit, receive, validate, store — because the order and the named inputs and outputs are the actual boundary of the right. Third, read the classification as a hint to scope: a ZK grant carrying G06Q 20 is fenced around a payment use; one carrying only H04L 9 cryptography subgroups is fenced around the proof-and-verification mechanism itself. None of this speaks to validity or breadth, which depend on the prior art and the full prosecution history. But it does let a reader say, accurately, what a “zero-knowledge proof patent” covers: a particular, recited way of proving something true on-chain without revealing the data — no more, and no less than the claim language allows. The concept is shared and unownable; the specific protocol, bound to named actors and a defined sequence of generate-transmit-verify steps, is what an issued grant fences, and it is the only thing a reader should describe it as covering when a project announces that its privacy feature has been “patented.”