Merchant-Specific Tokenization for Secure Data Deletion Control
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing tokenization systems are prone to data leakage and lack merchant-level data storage, leading to inefficiencies in data deletion and access control.
Innovation Solution
A tokenization system that generates unique tokens based on a combination of data controller and provider IDs, allowing for different tokens for the same data across different controllers or providers, with options for deletion and access control.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of manufacture
If granular tokenization is used for each piece of information, then data can be tokenized separately, but the system becomes prone to data leakage through reverse engineering
Solution Approach 1:
The patent combines multiple data pieces (first name, last name, email address, phone number, zip code) into a single tokenized record. Instead of tokenizing each field separately, the system creates one token that represents the entire set of personal information, making reverse engineering significantly more difficult while maintaining ease of tokenization.
Solution Approach 2:
The patent introduces a new dimension to tokenization by incorporating a merchant identifier into the tokenization process. This creates merchant-specific tokens that are unique to each merchant-data subject relationship, adding a layer of complexity that prevents cross-merchant data leakage and enhances overall data security.
2Stability of the object's composition
If the same token is provided for the same input data, then token consistency is maintained, but data leakage risk increases through analysis of tokens
Solution Approach 1:
By merging multiple data fields into a single tokenized record, the system maintains token consistency for the complete data set while preventing analysis of individual fields. The unified token structure ensures that consistent input produces consistent tokens without exposing individual data elements that could be analyzed for leakage.
Solution Approach 2:
The addition of merchant-specific identifiers creates a new dimension in token uniqueness. The same personal data will produce different tokens when associated with different merchants, preventing cross-merchant data leakage while maintaining consistency within each merchant's context.
3Device complexity
If data is stored without merchant-level separation, then storage simplicity is maintained, but deletion requests cannot be fine-tuned for specific merchants
Solution Approach 1:
The patent segments the tokenization system by merchant, creating separate token spaces for each merchant. This segmentation is achieved by incorporating merchant identifiers into the tokenization process, allowing independent deletion and management of data for each merchant without affecting other merchants' data, thus enabling fine-tuned deletion requests.
Solution Approach 2:
The system adds a merchant dimension to the data storage structure, organizing data by merchant rather than just by data subject. This dimensional change enables precise control over deletion requests, allowing a data subject to remove their data from specific merchants while retaining it with others, without significantly increasing overall system complexity.
4Ease of operation
If a centralized tokenization system is used, then data management is simplified, but access control and deletion requests lack granularity
Solution Approach 1:
The patent implements segmentation by merchant within the centralized tokenization system. Each merchant has their own token space and data vault, allowing the system to maintain centralized management benefits while providing granular access control. This enables different levels of access and deletion control for each merchant without sacrificing the simplicity of centralized operation.
Solution Approach 2:
By adding the merchant dimension to the centralized system, the patent enables granular access control while preserving centralized management. The system can operate centrally with a single tokenization engine, but the merchant-specific tokens and data vaults provide the necessary granularity for precise access control and deletion requests.
Data Source
AI summary
Systems and methods for tokenization of sensitive data are described, such as a method that includes receiving data to be protected which is provided by a data provider and obtained by or on behalf of a data controller, determining a data controller ID associated with the data controller and a data provider ID associated with the data provider, and generating, by a tokenization engine, a corresponding token for the data controller ID in combination with the data provider ID and in combination with the data to be protected, wherein the token is a reference that maps back to the data to be protected. The data controller ID in combination with the data provider ID and the data to be protected may be stored in a data vault, wherein the data to be protected is accessible from the data vault when the corresponding token is presented.