Cloud API Data Retrieval With Abstraction-Layer Privacy Filtering

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

The use of shared data repositories in cloud computing systems, where different APIs issue commands for data in varying formats, poses a security and privacy risk, particularly with sensitive data like PII, as conventional methods may inadvertently share unauthorized data due to differing definitions and authorizations across APIs.

Innovation Solution

An abstraction layer (Logical Entity Layer, LEL) interprets API requests to determine the necessary data fields, generating substitute requests that exclude unrequested data, ensuring only authorized information is transmitted, using API request mappings to standardize data retrieval.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a shared data repository sends composite field sets to all requesting APIs, then all APIs receive complete data, but sensitive unauthorized data is transmitted creating security and privacy risks

Engineering Contradiction:

Improvedata completenessVSAvoidsecurity and privacy risk

Core Design Contradiction:

Adaptability or versatilityVSObject-affected harmful factors

Solution Approach 1:

The patent introduces an abstraction layer as an intermediary component between the shared data repository and multiple APIs. This layer receives requests from various APIs, determines the appropriate field sets based on request characteristics, and generates customized responses. The intermediary prevents direct exposure of the entire composite field set to each API, thereby securing sensitive data while maintaining adaptability to different API needs.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent applies local quality by customizing the data response for each specific API request rather than providing a uniform composite field set to all. Each API receives only the field sets locally relevant to its specific needs and authorization level. This selective data transmission maintains data completeness for authorized fields while preventing exposure of unauthorized sensitive data.

Inventive Principle:

Principle #3Local quality

2Adaptability or versatility

If different APIs request data with varying formats and definitions, then each API gets customized data, but the complexity of data management increases

Engineering Contradiction:

ImproveAPI-specific data customizationVSAvoiddata management complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent creates a universal abstraction layer that handles multiple API requests with different formats and definitions through a single standardized interface. This layer universally processes requests by determining request types, selecting appropriate field sets, and generating responses according to each API's specific needs. The universal solution manages diverse data requirements without proportionally increasing system complexity.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent utilizes parameter changes by dynamically adjusting the data response parameters based on the specific API request. The abstraction layer modifies field set selections, data formats, and response structures according to the requesting API's characteristics. This parameter adaptation enables customized data delivery while maintaining a unified data management approach.

Inventive Principle:

Principle #35Parameter changes

3Object-affected harmful factors

If the shared data repository filters sensitive data at the API level after transmission, then data security is maintained, but data transmission efficiency decreases and security risks persist during transmission

Engineering Contradiction:

Improvedata securityVSAvoiddata transmission efficiency

Core Design Contradiction:

Object-affected harmful factorsVSProductivity

Solution Approach 1:

The patent implements preliminary action by filtering and customizing data field sets before transmission to each API. The abstraction layer determines the appropriate field sets and generates customized responses in advance, eliminating the need for post-transmission filtering. This preliminary data preparation maintains security by preventing sensitive data exposure from the outset while maximizing transmission efficiency by sending only necessary data.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The patent applies the extraction principle by selectively removing sensitive unauthorized field sets from the composite data before transmission to each API. The abstraction layer extracts only the authorized and relevant field sets for each specific request, preventing unnecessary data transmission. This extraction approach enhances both security by eliminating sensitive data exposure and efficiency by reducing transmitted data volume.

Inventive Principle:

Principle #2Taking out (Extraction)

Data Source

PatentUS12361431B2Systems and methods for remotely retrieving sensitive data in cloud computing systems featuring shared data repositories

Publication Date: 2025.07.15 CAPITAL ONE SERVICES LLC

AI summary

Systems and methods that use an abstraction layer (e.g., a logical entity layer) that reinterprets API requests in order to prevent unrequested and/or unauthorized data to be served in an API request. The abstraction layer accomplishes this by determining a characteristic of the composite field set that is to be returned based on a request from an API for a first field set. The system may then determine an API request mapping. The abstraction layer may then generate a substitute request corresponding to the field attribute using the API request mapping, wherein the substitute request modifies the first request to exclude data in a potential composite field set to exclude data not specifically requested (e.g., a second field set in the composite field).