IBM Files Patent to Protect Encrypted Document Searches by Adding Random Filler Text
IBM's filing describes hiding what a document means by padding it with random filler text before an AI reads it, plus a loop that decides how much padding is enough.
What IBM's filler-text encryption tweak does
A burglar stands outside a locked records room and slides question after question under the door. Which file is closest to this topic? And this one? Every answer leaks a little about what the files contain.
Something similar can happen with encrypted document databases built for search. To let you search without unlocking everything, each document is stored as a long list of numbers (called an embedding) that captures its meaning, and the encryption keeps closeness intact so similar documents still sit near each other. That helps you, and it also helps a patient attacker.
IBM's filing adds a layer of fuzz. Before each document is converted, extra random text is attached to it. A loop then checks the results and adds more filler until adding more stops helping much.
… appending to output a first set of augmented documents, by executing a first specifically purposed code within a noise generating module of an encryption manager application, a first amount of text data to a first portion of a natural language document …
Translation: The system adds random padding text to natural language documents using a special encryption module.
How IBM tunes the amount of added filler text
The filing covers a way to pick how much noise to add before encrypting a database of text documents. A large language model (the technology behind modern chatbots) turns each document into an embedding, a long list of numbers where similar meanings land near each other. The encryption described is distance preserving, meaning those near-and-far relationships survive encryption so a server can still find the closest match to a search.
The noise here is literal text. The description says a fresh random piece of text is attached to the start or end of each document before the model reads it. The steps look like this:
- Measure a property of the embeddings (the filing mentions pairwise distances, cluster sizes, or nearest-neighbor results) and compare it to a threshold.
- Use that result to set a noise parameter, which decides how much text gets appended.
- Run the longer documents through the model again, measure again, and adjust.
- Stop when the latest change brings less than a preset amount of benefit, and keep the last set of embeddings.
Those final embeddings are then used to tune the distance-preserving setting in the encryption step. The description also mentions applying different noise levels to different embeddings, depending on how close each one sits to the edge of a cluster of similar documents.
The embodiment iteratively adjusts the noise parameter, wherein each iteration changes the first amount of text data according to a comparison in the successive comparisons, and outputs an adjusted noise parameter for the iteration.
Translation: The software repeatedly tweaks the amount of random text until the security level is just right.
Why encrypted search attacks make this matter
If you store sensitive files in a cloud service that lets you search by meaning, such as contracts, medical notes, or research papers, you would want the stored number lists to give away as little as possible. The filing targets attackers who send many slightly changed queries and watch which results come back. Tuning the noise to the data, instead of using one fixed setting for everyone, is meant to keep your searches useful while making that probing less revealing.
The filing describes no specific product, so treat it as a research direction for protecting AI search databases. It does mention delivery as a cloud service, with usage metered and billed. The examiner's first review rejected the claims as filed, a routine step that is usually followed by amendments, so the final scope could look different.
IBM's 11th filing we've tracked since July in our on-device AI privacy watchlist builds on earlier work like sorting documents blindly and splitting AI across device and cloud.
Claim 1 reaches further than the headline idea suggests. It never requires the encryption step itself. It ends once the padded-text embeddings are produced and are 'usable to tune' an encryption setting, and the actual encrypting only shows up in claim 2.
The narrowing comes from three requirements: a large language model must create the embeddings, the noise must come from appended text, and a loop must adjust that amount against a threshold. The threshold itself is left open. A distance, a cluster size, or a nearest-neighbor measure all appear in the dependent claims, so many measurement choices would fit.
If granted, that wording would cover anyone who tunes padded-text noise in a loop for encrypted search. A system that adds noise straight to the numbers would appear to fall outside it. The stop rule (quit when extra text helps only a little) sits in dependent claim 7, so claim 1 would also reach loops that stop for other reasons.
Get our take in your Top Stories
Liked this breakdown? Add Patentlyze as a preferred source on Google, and our plain-English take shows up more often in your Top Stories the next time IBM patent news breaks.
There are more where this came from
We read every patent application Big Tech publishes and send you the ones worth knowing. Plain English, free, every week.
The drawings
7 drawing sheets from US 2026/0330053 A1 · click any drawing to enlarge
Want this weekly breakdown for a company we don't cover? Patentlyze Pro →
Be the first to weigh in