Secure Element Token Splitting for Offline Transaction Efficiency
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing electronic payment systems face challenges in managing and transferring tokens efficiently offline, leading to increased data size and processing requirements, which can result in time-outs and reduced user acceptance due to limited storage and processing capacity in secure elements, while maintaining security and anonymity.
Innovation Solution
The method involves generating and managing electronic second-type tokens, which can be split and merged without recording modifications as proofs, maintaining constant data size and allowing for flexible offline transactions by transforming first-type tokens into second-type tokens and vice versa, ensuring no additional or destroyed monetary value is created within the secure element.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If first-type tokens are used for offline transactions with token history recording, then security and anonymity are maintained, but data size increases and processing requirements increase leading to time-outs
Solution Approach 1:
The patent segments tokens into two types: first-type tokens with full token history for online/secure transactions, and second-type tokens without token history for rapid offline transactions. This segmentation allows offline transactions to proceed without the overhead of recording and verifying token history, eliminating time-outs while maintaining security through the dual-token system.
Solution Approach 2:
The patent extracts the token history component from tokens intended for offline transactions. By removing the token history recording requirement for second-type tokens, the system eliminates the data size increase and processing delays associated with token history management, while first-type tokens retain full token history for security-critical operations.
2Adaptability or versatility
If first-type tokens are split or merged offline with token history recording, then token flexibility is maintained, but data size increases due to proof recording
Solution Approach 1:
The patent segments token operations into two categories: operations on first-type tokens that record proofs in token history, and operations on second-type tokens that do not record proofs. This allows token splitting and merging to occur without increasing data size, as second-type tokens simply update their monetary value without appending proof data.
Solution Approach 2:
The patent extracts the proof recording mechanism from token splitting and merging operations. By removing the requirement to record modification proofs for second-type tokens, the system maintains token flexibility while preventing data size increase, as only the monetary value field is updated without adding historical proof data.
3Reliability
If token history is recorded for each modification, then detection of double-spending and uncovered payments is enabled, but processing capacity requirements increase beyond secure element capabilities
Solution Approach 1:
The patent segments the detection mechanism into two approaches: token history recording for first-type tokens that requires full processing capacity, and simplified value comparison for second-type tokens that uses only the monetary value field. This allows secure elements to handle second-type token transactions within their limited processing capacity while maintaining double-spending detection through the absence of token history requirements.
Solution Approach 2:
The patent extracts the token history data structure from transactions involving second-type tokens. By removing the need to store and process token history for these tokens, the system reduces processing capacity requirements to levels compatible with secure elements, while first-type tokens continue to use full token history for enhanced security verification.
4Reliability
If online connection is used for token verification, then token validity is confirmed, but user convenience decreases due to connectivity requirements
Solution Approach 1:
The patent segments verification requirements into two modes: online verification with token register communication for first-type tokens, and offline verification using only monetary value comparison for second-type tokens. This segmentation provides users with the convenience of offline transactions for second-type tokens while maintaining the option for enhanced online verification when using first-type tokens.
Solution Approach 2:
The patent extracts the online connectivity requirement from token verification processes involving second-type tokens. By removing the need to communicate with the token register for second-type token verification, the system provides users with convenient offline transaction capability, while first-type tokens continue to support optional online verification for enhanced security.
Data Source
AI summary
A secure element for providing electronic second-type tokens, and includes an electronic first-type token having a monetary value. The secure element is configured to: generate an electronic second-type token based on the electronic first-type token, wherein the monetary value of the generated electronic second-type token is equal to the monetary value of the electronic first-type token; split the generated electronic second-type token into two or more electronic second-type tokens, a split electronic second-type token of the split electronic second-type tokens having the defined monetary value; and send to the second secure element the split electronic second-type token having the defined monetary value.