Privacy-Aware Graph Query Plan Caching by Caller Trust

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current graph data infrastructures face inefficiencies in generating query execution plans, leading to significant resource consumption and latency, and the caching of queries is hindered by the need to comply with data privacy and security regulations, which is computationally complex and resource-intensive.

Innovation Solution

A system utilizing a cache suitability determination engine and query plan generation engine to apply multiple caching policies based on query caller trust and scenario, modifying queries to ensure privacy compliance, and caching query plans in specific regions or for limited times to optimize resource use and reduce latency.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Use of energy by moving object

If query plans are cached and reused, then computing resource use is reduced and service cost is reduced, but privacy and confidentiality restrictions prevent caching of queries containing sensitive data

Engineering Contradiction:
Improvecomputing resource useVSAvoidprivacy compliance
Core Design Contradiction:
Use of energy by moving objectVSReliability

Solution Approach 1:

The patent segments the caching process into multiple policies: a first caching policy for queries from trusted callers/scenarios that can be cached with minimal verification, and a second caching policy for other queries that require privacy verification before caching. This segmentation allows the system to cache more queries overall while maintaining privacy compliance for sensitive data.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent changes the parameter of cache suitability determination by introducing trusted caller and trusted scenario parameters. Instead of requiring full privacy verification for all queries, the system uses these parameters to identify queries that can be cached without verification, thereby reducing computing resource use while maintaining privacy compliance where needed.

Inventive Principle:
Principle #35Parameter changes

2Productivity

If optimal query plans are generated, then query execution efficiency is improved, but the process consumes significant memory storage and processing resources

Engineering Contradiction:
Improvequery execution efficiencyVSAvoidmemory storage and processing resources
Core Design Contradiction:
ProductivityVSQuantity of substance

Solution Approach 1:

The patent performs preliminary action by determining cache suitability and generating query plans in advance, then caching them for reuse. By identifying trusted callers and scenarios beforehand and pre-generating query plans that can be safely cached, the system reduces the need to generate optimal query plans repeatedly, thereby reducing memory storage and processing resource consumption while maintaining query execution efficiency.

Inventive Principle:
Principle #10Preliminary action

3Loss of time

If query plans are cached to reduce latency, then query processing speed is improved, but identifying sensitive data in queries is computationally complex and resource intensive

Engineering Contradiction:
Improvequery processing latencyVSAvoidcomputation complexity for privacy verification
Core Design Contradiction:
Loss of timeVSDevice complexity

Solution Approach 1:

The patent segments the query processing into two paths: a fast path for trusted callers/scenarios where queries are cached without privacy verification (reducing latency and computation complexity), and a verification path for other queries where privacy checking is performed. This segmentation significantly reduces the overall computation complexity while maintaining low latency for the majority of queries.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent applies partial action by performing privacy verification only when necessary (for non-trusted callers/scenarios) rather than for all queries. This selective approach reduces the computational complexity and resource intensity of privacy verification while still ensuring that sensitive data is protected in the cached query plans.

Inventive Principle:
Principle #16Partial or excessive action

4Productivity

If multiple caching policies are applied based on query caller trust and scenario, then resource use is optimized and latency is reduced, but the system complexity increases

Engineering Contradiction:
Improveresource efficiencyVSAvoidsystem complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent divides the caching system into distinct policies (first caching policy for trusted callers/scenarios, second caching policy for other queries) with clear rules for when each applies. This segmentation, while adding some system complexity, enables optimized resource use and reduced latency by allowing aggressive caching where safe and selective caching where needed, improving overall productivity.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentEP4589447A1System and method of privacy-preservation in caching of graph query execution plans
Publication Date: 2025.07.23 MICROSOFT TECHNOLOGY LICENSING LLC
  • EP4589447A1 patent drawingFigure 1
  • EP4589447A1 patent drawingFigure 2
  • EP4589447A1 patent drawingFigure 3

AI summary

A method of and system for caching a query submitted to a graph data storage system, the method including receiving a query directed to the graph data storage system, the query being received from a query caller, and examining the query, via a cache suitability determination engine, to determine if the query is suitable for caching under a first graph query caching policy based on the query caller being a trusted caller and/or the query scenario being a trusted query scenario. Upon determining that the query is suitable for caching under the first policy, generating a query execution plan for the query via a graph query plan generating engine and examining the query plan to determine if the query plan is suitable for caching under the first policy. Upon determining that the query is not suitable for caching under the first policy, caching the query under a second graph query caching policy or a third graph caching policy, and providing the query execution plan for execution. The third policy is based on the geographic location of a memory system on which the query plan is stored and a limitation on an amount of time for which the query plan is stored.