Blockchain API Balancing via Smart Contract Hash Validation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing API request and response balancing and control systems rely on third-party intermediaries, which increase development time, introduce complexity, and add an additional point of failure, while lacking tamper-proofness and real-time validation capabilities.

Innovation Solution

A blockchain-based system for peer-to-peer API transactions that writes confirmations and acknowledgments to a distributed database, utilizing smart contracts for real-time validation and tamper-proof logging, eliminating the need for third-party intermediaries and enabling near-instant balancing and control of API requests and responses.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a third party intermediary is used for API request and response balancing and control, then data transfer validation can be performed, but development time increases and system complexity increases

Engineering Contradiction:
Improvedata transfer validationVSAvoiddevelopment time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent extracts the balancing and control functionality from the third party intermediary system and implements it directly within the API gateway. This allows the system to maintain data transfer validation capabilities while eliminating the need for external proprietary systems, thereby reducing development time and complexity.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent introduces an on-chain event mechanism as an intermediary between API requests and responses. This event-driven approach enables validation and balancing functionality to be implemented within the existing API gateway infrastructure without requiring a separate third party system, thus maintaining reliability while reducing development overhead.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If a third party intermediary is used for API request and response balancing and control, then data transfer validation can be performed, but device complexity increases

Engineering Contradiction:
Improvedata transfer validationVSAvoidapplication design complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent removes the need for complex third party intermediary systems by extracting the essential balancing and control functionality and implementing it natively in the API gateway. This simplifies application design by eliminating the need to integrate with external proprietary systems while maintaining validation capabilities.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The API gateway performs balancing and control operations autonomously using on-chain events and smart contracts. This self-service approach eliminates the need for complex third party integration and manual configuration, thereby reducing application design complexity while maintaining data transfer validation.

Inventive Principle:
Principle #25Self-service

3Reliability

If a third party intermediary is used for API request and response balancing and control, then central authority for B&C process is established, but tamper-proofness is compromised

Engineering Contradiction:
Improvecentral authority for B&C processVSAvoidtampering risk
Core Design Contradiction:
ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The patent uses blockchain on-chain events as an intermediary to establish a decentralized authority for balancing and control. This approach maintains the central coordination function while leveraging blockchain's inherent tamper-proof characteristics, thereby eliminating the vulnerability associated with third party intermediaries.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent replaces the mechanical third party intermediary system with a blockchain-based smart contract mechanism. This substitution maintains the central authority function for B&C process while providing cryptographic tamper-proof guarantees, as blockchain data cannot be altered without detection.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

4Reliability

If third party proprietary systems are used, then B&C monitoring can be performed, but time to market increases

Engineering Contradiction:
ImproveB&C monitoringVSAvoidtime to market
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent extracts B&C monitoring functionality from third party proprietary systems and implements it directly in the API gateway using on-chain events. This eliminates the need for lengthy integration processes with external systems, thereby maintaining monitoring capabilities while significantly reducing time to market.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The API gateway performs B&C monitoring autonomously through smart contracts and on-chain events without requiring third party systems. This self-service capability eliminates dependency on external proprietary solutions, maintaining monitoring reliability while accelerating time to market by removing integration overhead.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS11283596B2API request and response balancing and control on blockchain
Publication Date: 2022.03.22 AMERICAN EXPRESS TRAVEL RELATED SERVICES CO INC
  • US11283596B2 patent drawing
  • US11283596B2 patent drawing
  • US11283596B2 patent drawing

AI summary

A balancing and control (B&C) system for API transactions is disclosed. The system may write a request confirmation and a request acknowledgement to a blockchain in response to an API request being transmitted from a consumer system to a provider system, with the request confirmation and the request acknowledgement each comprising a request hash of the API request. The system may also write a response confirmation and a response acknowledgement to the blockchain in response to an API response being transmitted from the provider system to the consumer system, with the response confirmation and the response acknowledgement each comprising a response hash of the API response. The blockchain may execute a smart contract to compare the request hashes from the request confirmation and the request acknowledgement and the response hashes from the response confirmation and the response acknowledgement to identify one or more out-of-balance events.