Samsung Patents a System That Controls Which Cached Search Results Each User Can See
Every time a database returns an answer, that answer could be cached and reused by someone who shouldn't see it. Samsung's new patent describes a system that checks your permissions before deciding which saved results you're allowed to read.
What Samsung's permission-tiered cache actually does
A database administrator runs a report on employee salaries. The result gets saved in a fast-access cache so the next request doesn't have to rerun the whole query. The problem: if another user asks the same question, should they get the same cached answer? Not if they don't have permission to see that data.
Samsung's patent proposes a system that sorts cached results into three buckets: one for you alone, one for your team, and one for everyone. Before serving any cached result, the system runs a quick test version of your query to figure out what kind of data is involved and what your credentials allow. It then picks the right bucket, or none at all.
The goal is speed without the security shortcut. Right now, many systems either skip caching to stay safe or cache everything and hope permissions were applied correctly upstream. This approach tries to do both at once.
generate a token for managing data permissions of a user requesting a query, determine a cache type available to the user by using the query and the token, and request cache data corresponding to an execution result of the query based on the determined cache type …
Translation: The system checks who is asking and what they want before deciding which saved search results they are allowed to see.
How the dry-run token decides which cache you can reach
The core idea is a three-tier cache architecture gated by a permission token. When you send a database query, the system generates a token that encodes your identity and access rights. It then runs what the patent calls a dry run (a simulated execution of the query that figures out what data would be touched, without actually returning results) to collect what it calls job information.
Using the job information, the token type, and whether the query calls any special functions (like row-level security filters or user-specific functions), the system classifies which cache tier applies:
- User cache: results only you can retrieve, for queries touching data restricted to your identity
- Group cache: results shared within a team or role that shares the same permissions
- Shared cache: results available to anyone, for queries on fully public or unrestricted data
The dry-run step is the key design choice. Instead of trusting that permissions were applied correctly when data was first cached, the system re-evaluates access rights at retrieval time. That means a result cached for a manager won't accidentally serve a lower-privileged employee just because they asked the same question.
The patent also handles session-specific functions (query elements that return different results depending on who is running them) by routing those queries away from shared caches entirely, preventing any bleed between users.
… determine the cache type available to the user to be at least one of a user cache, a group cache, or a shared cache based on security information included in the job information, specific function information included in the query, and a type of the token.
Translation: Saved results are divided into private, team, and public tiers depending on security rules and user permissions.
What this means for enterprise data privacy at scale
Database caches are one of the biggest speed levers in enterprise software. Skipping them for security reasons is genuinely expensive; rerunning complex queries wastes compute and slows down every dashboard, report, and app that depends on them. A system that can safely cache and reuse results at the right permission level could meaningfully cut costs for large organizations running cloud data warehouses.
For everyday users, the effect would be invisible but real: the same business intelligence tool loads faster because your permitted results are already waiting, without any risk that you're seeing data meant for someone else. Samsung's growing interest in enterprise data infrastructure suggests this is aimed squarely at cloud platform customers rather than consumer devices.
That makes this Samsung's 1224th filing in our Samsung coverage since May, adding to work like the single-chip AI idea and the handwriting-reading display.
Running a simulated version of every request before deciding which saved answer to use adds waiting time to every single lookup, and for quick, simple questions that extra step could easily take longer than just finding the answer fresh.
The patent never says how expensive that simulation is compared to the original request, which is the one number that determines whether this whole approach saves time or wastes it.
What the design does earn is a cleaner structure: instead of checking who is allowed to see what as a separate, easily-forgotten step, it folds access control directly into the decision about which saved result to hand over. That is fewer places for something to go wrong, and the tradeoff reads as worth it for large, slow requests where the simulation cost is trivial by comparison, and probably not worth it for everything else.
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
5 drawing sheets from US 2026/0268009 A1 · click any drawing to enlarge
Want this weekly breakdown for a company we don't cover? Patentlyze Pro →