Scalable Orchestration for Off-Network Payment Service Format Translation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing systems face challenges in providing value-added services to payment transactions originating from a different payment network due to format incompatibilities and geographic restrictions, limiting the accessibility of these services to transactions processed within the same network.

Innovation Solution

A scalable orchestration framework that includes an orchestrator platform to receive, decode, and dynamically create service execution layers in a cloud environment, allowing for the provision of value-added services across networks by translating and applying business rules to transaction messages.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If value-added services are provided only within the home network, then security and format compatibility are maintained, but service accessibility is limited to transactions originating on the same network

Engineering Contradiction:
Improveservice accessibilityVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces an intermediary service layer that acts as a mediator between the home network and off-network value-added services. This intermediary receives transactions from the home network, translates them into formats compatible with off-network services, executes the value-added services, and returns results to the home network. This resolves the contradiction by enabling service accessibility across networks while managing complexity through a dedicated translation and coordination layer.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent replaces direct mechanical connectivity requirements with a software-based service invocation mechanism. Instead of requiring physical or network-level direct connections between home network and off-network services, the system uses standardized API calls and service invocation patterns. This substitution enables service accessibility without increasing network infrastructure complexity.

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

2Adaptability or versatility

If message formats are translated for off-network processing, then service compatibility is improved, but processing time and complexity increase

Engineering Contradiction:
Improveformat compatibilityVSAvoidprocessing time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent implements preliminary action by pre-defining translation rules and service invocation patterns before transactions occur. The system maintains a registry of supported message formats and pre-configures translation mappings, allowing rapid conversion during transaction processing without ad-hoc translation overhead. This reduces processing time while maintaining format compatibility across networks.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent employs parameter changes by dynamically adjusting message format parameters based on the target service requirements. Instead of complete message rewriting, the system modifies specific parameters such as data types, field ordering, and encoding formats while preserving the core transaction structure. This selective parameter transformation minimizes processing time while achieving necessary format compatibility.

Inventive Principle:
Principle #35Parameter changes

3Adaptability or versatility

If value-added services are applied to all transactions, then service coverage is increased, but security risks and data policy compliance challenges increase

Engineering Contradiction:
Improveservice coverageVSAvoidsecurity compliance
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent applies local quality by implementing different service execution strategies based on transaction characteristics and data sensitivity. The system evaluates each transaction against defined security policies and data residency requirements, then executes value-added services accordingly. Sensitive transactions are processed with enhanced security measures or restricted to specific services, while less sensitive transactions can access the full service portfolio. This maintains broad service coverage while ensuring security compliance through differentiated processing.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The patent implements dynamics by making service selection and execution adaptive rather than static. The system dynamically determines which value-added services to apply based on real-time evaluation of transaction data, user preferences, and security policies. This dynamic service invocation allows the system to expand service coverage for eligible transactions while automatically restricting access for those violating security or compliance requirements, thus maintaining reliability.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentUS20250232289A1Scalable orchestration framework for accessing off-network value-added services
Publication Date: 2025.07.17 MASTERCARD INT INC
  • US20250232289A1 patent drawing
  • US20250232289A1 patent drawing
  • US20250232289A1 patent drawing

AI summary

A scalable orchestration framework for accessing a plurality of value-added services platforms is provided. The framework includes an orchestrator platform having a memory and a processor. The processor programmed to: (i) receive a first request data signal including a plurality of elements; (ii) extract the plurality of elements of the first request data signal; (iii) determine a total number of services of a plurality of value-added services to be invoked; (iv) instantiate a service execution layer corresponding to each service of the plurality of services to be invoked at the plurality of services platforms; (v) provision each instantiated service execution layer with business rules and an endpoint configuration file corresponding to a service of the plurality of services; (vi) transmit a message to each instantiated service execution layer to receive a response from the respective service platform; and (vii) transmit a first response data signal based upon the received response.