Decentralized Transaction Data Storage Beyond Card Authorization

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing payment card transaction standards limit the type and amount of data that can be transmitted between parties, restricting the information available to merchants and financial institutions.

Innovation Solution

Storing transaction data in a decentralized manner using a blockchain or distributed ledger, allowing merchants to add additional transaction details beyond the authorization request, which can be retrieved and enriched for account holders.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Loss of information

If traditional payment card transaction standards are used, then transaction processing is standardized and reliable, but the type and amount of data that can be transmitted are limited

Engineering Contradiction:
Improvetransaction data completenessVSAvoiddata transmission system complexity
Core Design Contradiction:
Loss of informationVSDevice complexity

Solution Approach 1:

The system segments transaction data into two parts: essential authorization data transmitted through traditional standardized channels, and additional descriptive data stored on a blockchain. This segmentation allows the patent to maintain compatibility with existing payment standards while enabling enhanced data transmission capabilities through the blockchain's append-only ledger mechanism.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The blockchain acts as an intermediary between the payment card association's standardized data requirements and the merchant's need to transmit additional transaction details. It provides a bridge that accommodates both the standardized authorization data and the enriched descriptive data without compromising either system.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Loss of information

If additional transaction data is transmitted beyond authorization requests, then more information is available to merchants and customers, but data security and integrity challenges increase

Engineering Contradiction:
Improvetransaction information availabilityVSAvoiddata integrity and security
Core Design Contradiction:
Loss of informationVSReliability

Solution Approach 1:

The system performs preliminary actions by pre-establishing cryptographic hashes of transaction data and pre-configuring blockchain smart contracts that automatically enforce data integrity rules. These preliminary measures ensure that when additional transaction data is transmitted and stored, its integrity is maintained from the outset through cryptographic verification and immutable blockchain recording.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system changes the parameter of data storage from traditional centralized databases to a decentralized blockchain ledger with specific cryptographic parameters. This parameter change enhances data integrity through cryptographic hashing and immutable recording, while the blockchain's distributed nature provides security without requiring complex centralized security systems.

Inventive Principle:
Principle #35Parameter changes

3Reliability

If decentralized storage is implemented, then data integrity and security are enhanced, but system complexity and implementation difficulty increase

Engineering Contradiction:
Improvedata integrityVSAvoiddecentralized storage system complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The blockchain platform is designed with multi-functionality to handle various transaction data types and enrichment operations. It serves as a universal ledger that can store authorization data, descriptive data, and cryptographic hashes simultaneously, reducing the need for multiple specialized systems and simplifying implementation.

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

Solution Approach 2:

Instead of requiring complex real-time synchronization across all nodes, the system uses cryptographic copying of transaction data hashes to the blockchain. This allows each participant to maintain a copy of the essential transaction information without requiring complex real-time data sharing mechanisms, simplifying the overall system architecture.

Inventive Principle:
Principle #26Copying

4Ease of operation

If existing industry standards are followed, then compatibility and ease of operation are maintained, but the ability to provide detailed transaction information is restricted

Engineering Contradiction:
Improvetransaction processing simplicityVSAvoiddata transmission flexibility
Core Design Contradiction:
Ease of operationVSAdaptability or versatility

Solution Approach 1:

The system segments the data transmission process into two independent parts: traditional standardized authorization transactions that maintain simplicity and compatibility, and additional descriptive data transactions that utilize blockchain's flexible data storage capabilities. This segmentation allows each part to operate under its own optimal standards without compromising the other.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent adds another dimension to data transmission by introducing blockchain-based descriptive data storage alongside traditional authorization channels. This dimensional addition allows the system to maintain existing simple authorization processes while enabling rich, detailed transaction information storage and retrieval through the blockchain's additional data layer.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

Data Source

PatentUS20250328898A1Decentralized storage of transaction data
Publication Date: 2025.10.23 AMERICAN EXPRESS TRAVEL RELATED SERVICES CO INC
  • US20250328898A1 patent drawing
  • US20250328898A1 patent drawing
  • US20250328898A1 patent drawing

AI summary

Disclosed are various embodiments for decentralized storage of transaction data. An authorization request for a transaction is received from a second computing device. The transaction is then authorized. In response to authorization of the transaction, a node representing the transaction can be generated. The node is then stored in a graph. Moreover, in response to authorization of the transaction, a response is provided to the second computing device. The response can include a transaction identifier.