Data-Masking Labels for Privacy-Safe Consortium Request Fulfillment

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing systems fail to efficiently and securely identify requests that require a consortium of entities for fulfillment, leading to denial or additional user action, without a mechanism to handle complex requests in a scalable and secure manner.

Innovation Solution

A request fulfillment platform that trains an analysis model to generate complexity scores and smart contracts based on historical event processing information, using data-masking labels like optical tones, to determine if a consortium is needed, and securely facilitate fulfillment.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a single entity processes event processing requests independently, then data privacy is maintained, but the system cannot satisfy complex requests requiring multiple entities

Engineering Contradiction:

Improveability to satisfy complex requestsVSAvoidsystem structure

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments the request fulfillment process into distinct components: a computing platform that analyzes requests using trained analysis models, identifies consortium requirements, and generates smart contracts. This segmentation allows the system to handle complex requests by distributing tasks across multiple entities while maintaining a structured processing framework.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The computing platform acts as an intermediary between users and consortium entities. It receives event processing requests, analyzes them using trained models, determines whether consortium fulfillment is needed, and coordinates the generation of smart contracts. This intermediary role enables complex request handling without requiring direct complex interactions between all parties.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Productivity

If the system identifies requests requiring consortium fulfillment, then complex requests can be satisfied, but data privacy and security risks increase

Engineering Contradiction:

Improverequest fulfillment capabilityVSAvoiddata privacy and security risks

Core Design Contradiction:

ProductivityVSObject-affected harmful factors

Solution Approach 1:

The patent replaces traditional mechanical data sharing and verification processes with blockchain-based smart contracts. These self-executing contracts encode request parameters, consortium member identities, and fulfillment conditions, enabling automated, transparent, and secure coordination without requiring direct trust between parties or exposure of sensitive data.

Inventive Principle:

Principle #28Mechanics substitution (Replace mechanical system)

Solution Approach 2:

The system transforms request information into standardized parameters that can be processed by analysis models. By converting complex requests into structured data with specific parameters (e.g., funding requirements, relationship types, interaction history), the system enables automated analysis and decision-making while maintaining data privacy through parameterized representation rather than raw data exposure.

Inventive Principle:

Principle #35Parameter changes

3Productivity

If manual authentication and analysis are used for event processing requests, then security is maintained, but processing efficiency decreases

Engineering Contradiction:

Improverequest processing efficiencyVSAvoidauthentication security

Core Design Contradiction:

ProductivityVSReliability

Solution Approach 1:

The system performs preliminary actions by training analysis models on historical event processing information before processing new requests. These pre-trained models can automatically analyze incoming requests, identify patterns, and determine consortium requirements without manual intervention. Authentication and analysis are performed automatically based on pre-established criteria, maintaining security while dramatically improving processing efficiency.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The computing platform provides self-service capabilities through automated analysis models that independently evaluate event processing requests. The models authenticate requests, identify parameters, and determine fulfillment requirements without human intervention. This self-service approach maintains security through consistent application of authentication rules while enabling high-volume processing.

Inventive Principle:

Principle #25Self-service

4Object-affected harmful factors

If data-masking labels like optical tones are used, then data privacy is protected, but the complexity of processing and analyzing requests increases

Engineering Contradiction:

Improvedata privacy protectionVSAvoidprocessing complexity

Core Design Contradiction:

Object-affected harmful factorsVSDevice complexity

Solution Approach 1:

The analysis models are designed with multi-functionality to handle various types of data-masking labels including optical tones, encrypted data, and parameterized representations. The models can process different label formats uniformly, extracting necessary information while preserving privacy. This universal processing capability protects data privacy across different request types without proportionally increasing processing complexity.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Data Source

PatentUS20250328908A1Protecting data privacy using data-masking labels in systems providing request fulfillment by consortium

Publication Date: 2025.10.23 BANK OF AMERICA CORP

AI summary

Aspects related to protecting data privacy using data-masking labels in systems providing request fulfillment by consortium are provided. A request fulfillment platform may train an analysis model to output smart contracts. The platform may receive an event processing request. The platform may identify a label corresponding to the event processing request. The platform may authenticate the event processing request based on the label. The platform may identify parameters of the event processing request based on information of a market corresponding to the event processing request. The platform may generate a complexity score for the event processing request based on inputting the label into the analysis model. The platform may generate an indication of whether fulfillment of the event processing request requires a consortium based on the complexity score. The platform may generate smart contracts based on the indication. The platform may send the smart contracts to a device.