Token-Based Data Access Control and Filtering

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current methods for accessing user data, such as screen scraping and APIs, face challenges including data privacy risks, computational intensity, and complex negotiations, with a need for a secure and efficient mechanism to control access and filter user data without intermediaries.

Innovation Solution

The use of tokens and a key-value map data structure to authorize data access and filter user data based on directives from data providers, ensuring only necessary data is shared while maintaining user privacy and reducing computational burden.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Loss of information

If screen scraping is used to access user data, then data can be obtained for analysis and recommendations, but data privacy risks increase and significant computing resources are consumed

Engineering Contradiction:
Improveuser data access capabilityVSAvoiddata privacy risks
Core Design Contradiction:
Loss of informationVSObject-affected harmful factors

Solution Approach 1:

The patent introduces an intermediary token-based authentication system between data providers and data recipients. Instead of direct screen scraping that exposes credentials, the system uses tokens as mediators that grant controlled access to specific data elements without exposing user credentials or requiring the intermediary to store sensitive information.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent extracts only the necessary authentication credentials (tokens) from the authentication process, separating them from the actual user data. The token contains minimal information required for access authorization without including sensitive user credentials, thereby reducing data privacy risks while maintaining access capability.

Inventive Principle:
Principle #2Taking out (Extraction)

2Loss of information

If screen scraping is used to access user data, then data can be captured and stored, but computational intensity and bandwidth requirements increase significantly

Engineering Contradiction:
Improveuser data access capabilityVSAvoidcomputational resources
Core Design Contradiction:
Loss of informationVSUse of energy by moving object

Solution Approach 1:

The system extracts and transmits only essential data elements through the token mechanism rather than capturing and storing complete user data sets. This selective data extraction reduces the computational burden of data processing, storage, and transmission while maintaining the core functionality of data access.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

Instead of performing complete screen scraping of all available data, the system performs partial action by accessing only the specific data elements required for the intended purpose. The token-based approach enables selective data retrieval without the overhead of comprehensive data capture and storage.

Inventive Principle:
Principle #16Partial or excessive action

3Ease of operation

If APIs are used for data access with bilateral agreements, then structured data access is enabled, but negotiation complexity and time increase due to multiple financial institutions and fintechs

Engineering Contradiction:
Improvedata access structureVSAvoidnegotiation time
Core Design Contradiction:
Ease of operationVSLoss of time

Solution Approach 1:

The patent creates a universal token-based authentication framework that can be applied across multiple financial institutions and fintechs through a common standard. This universal approach eliminates the need for individual bilateral negotiations for each institution-recipient pair, as the token mechanism provides a standardized method for authorized data access that works across the entire ecosystem.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system segments the authentication and authorization process into distinct token issuance and token validation steps. This segmentation allows different financial institutions to issue tokens according to their own policies while maintaining compatibility with a common validation framework, reducing negotiation complexity compared to end-to-end bilateral agreements.

Inventive Principle:
Principle #1Segmentation

4Loss of information

If data filtering is performed on entire payload at byte level, then data can be filtered according to directives, but processing time increases significantly

Engineering Contradiction:
Improvedata filtering capabilityVSAvoidprocessing time
Core Design Contradiction:
Loss of informationVSLoss of time

Solution Approach 1:

The system performs preliminary action by establishing data directives and token-based access rules before data retrieval occurs. The token encapsulates authorization information and data element specifications in advance, allowing the receiving system to filter and access only authorized data elements without performing time-consuming byte-level scanning of entire data payloads.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS11379614B1Systems and methods for managing tokens and filtering data to control data access
Publication Date: 2022.07.05 AKOYA LLC
  • US11379614B1 patent drawing
  • US11379614B1 patent drawing
  • US11379614B1 patent drawing

AI summary

Systems and methods are described for receiving a first request from a user to grant authorization for a first data recipient to access user information associated with a data provider, and receiving a second request from the user to grant authorization for a second data recipient to access user information associated with the data provider. An authentication token is received from the data provider, where the authentication token enables access to user information associated with the data provider. A first token may be generated for, and provided to, the first data recipient and a second token may be generated for, and provided to, the second data recipient. In response to receiving the first token from the first data recipient, user information data may be provided to the first data recipient. In response to receiving the second token from the second data recipient, user information data may be provided to the second data recipient.