Tokenized Account Access for Secure Third-Party Revocation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing systems fail to securely revoke account credentials once shared and lack efficient methods for accessing and managing user account data from multiple disparate sources with proprietary interfaces.

Innovation Solution

The system employs virtualized or simulated instances of software applications that interface with external systems via proprietary APIs, allowing secure authorization and de-authorization of transactions without disclosing account credentials, and provides normalized data access through a standardized interface.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If account credentials are shared with third-party systems, then access to user account data is enabled, but security is compromised because credentials cannot be securely revoked

Engineering Contradiction:
Improveaccess to user account dataVSAvoidsecurity of account credentials
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent introduces a token as an intermediary between the user account credentials and third-party systems. Instead of sharing credentials directly, the system generates a token that represents authorized access. This token can be independently revoked without affecting the underlying credentials, thus enabling secure access control and revocation while maintaining ease of operation.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If virtualized application instances are implemented, then secure authorization without credential disclosure is achieved, but system complexity increases

Engineering Contradiction:
Improvesecure authorizationVSAvoidsystem architecture
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent creates virtualized or simulated copies of software application instances that can interact with external systems on behalf of the user without exposing actual credentials. These virtual instances replicate the necessary functionality while maintaining security isolation. The complexity is managed by confining virtualization to specific authorization components rather than the entire system.

Inventive Principle:
Principle #26Copying

3Adaptability or versatility

If multiple disparate external systems are accessed, then comprehensive data retrieval is enabled, but data normalization and access efficiency deteriorate

Engineering Contradiction:
Improvedata retrieval from multiple systemsVSAvoiddata access efficiency
Core Design Contradiction:
Adaptability or versatilityVSProductivity

Solution Approach 1:

The patent implements a universal token-based authorization mechanism that works across multiple disparate external systems. Instead of implementing separate authentication and data access logic for each system, the token serves as a universal credential that can be presented to any connected external system. This multi-functional approach enables comprehensive data retrieval while maintaining consistent access patterns and efficiency across all systems.

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

Data Source

PatentUS20260113309A1Secure permissioning of access to user accounts, including secure deauthorization of access to user accounts
Publication Date: 2026.04.23 PLAID INC
  • US20260113309A1 patent drawing
  • US20260113309A1 patent drawing
  • US20260113309A1 patent drawing

AI summary

A permissions management system is disclosed for enabling a user to securely authorize a third-party system to access user account data and initiate transactions related to a user account, without disclosing to the third-party system account credentials. The system enables the user to also securely de-authorize the third-party system. For example, records may be automatically generated that securely store account information, including one or more permissions related to the account and/or the third-party. A token associated with a record may be shared with the third-party system, but neither the record itself, nor the user account credentials, may be shared with the third-party. Accordingly, the third-party may request user account data and/or initiate transactions by providing the token, but does not itself know, e.g., the user account credentials. Further, the user may set various permissions related to the token, and may also revoke the token (e.g., de-authorize the third-party), thus providing increased security to the user's account.