Common Data Model for Redundant Message Processing

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing message standards, such as ISO 20022, include multiple message sets with common data elements, leading to redundant data and the need for separate validation rules and processing for each message type, which complicates message processing and validation.

Innovation Solution

The system converts a complex message standard to a common data model by combining common name classes into superset classes, allowing for simplified messaging and reduced processing time. This is achieved by stripping validation rules, de-duplicating complexTypes, absorbing data elements into superset classes, and generating a protobuf object for message-agnostic processing.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If multiple message sets with common data elements are used in a message standard, then data can be defined for different message types (e.g., inquiry versus authorization), but redundant data and separate validation rules are required for each message type, complicating message processing

Engineering Contradiction:

Improvemessage type differentiationVSAvoidvalidation rule complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent merges common data elements across multiple message sets into a single common data model. Instead of maintaining separate validation rules for each message type, the system combines them into one unified model that can handle all message types. This is achieved by identifying common name classes (e.g., Amount, AccountDetails) that appear across different message sets and consolidating them into superset classes with unified validation logic.

Inventive Principle:

Principle #5Merging (Combining)

Solution Approach 2:

The common data model serves as a universal structure that can validate and process multiple different message types through a single framework. The superset classes are designed to be multi-functional, accommodating various message types (inquiry, authorization, financial initiation, etc.) while using the same validation rules and processing logic, thereby eliminating the need for separate validation rules for each message type.

Inventive Principle:

Principle #6Universality (Multi-functionality)

2Reliability

If separate validation rules are maintained for each message type, then specific validation can be applied to each message set, but processing time increases due to redundant validation logic

Engineering Contradiction:

Improvemessage validation accuracyVSAvoidmessage processing speed

Core Design Contradiction:

ReliabilityVSProductivity

Solution Approach 1:

The patent combines redundant validation logic into a single unified validation framework. By merging common data elements and their validation rules into the common data model, the system eliminates repeated validation checks across different message types. The superset classes inherit validation logic from parent classes, reducing the overall validation workload while maintaining accuracy.

Inventive Principle:

Principle #5Merging (Combining)

Solution Approach 2:

The common data model is pre-configured with validation rules for common data elements before message processing occurs. This preliminary setup allows the system to quickly validate messages without needing to execute separate validation rules for each message type. The validation logic is prepared in advance within the superset classes, enabling faster processing while ensuring reliability.

Inventive Principle:

Principle #10Preliminary action

3Manufacturing precision

If common name classes are treated as distinct numbered classes (e.g., CardData6a and CardData9), then specific data requirements for different message sets can be maintained, but processing complexity increases due to multiple similar classes

Engineering Contradiction:

Improvedata element specificityVSAvoidclass structure complexity

Core Design Contradiction:

Manufacturing precisionVSDevice complexity

Solution Approach 1:

The patent merges numbered variants of common name classes into unified superset classes. Instead of treating CardData6a and CardData9 as completely distinct classes with separate processing logic, the system identifies them as variants of a common data structure and consolidates them into a single superset class. This maintains the necessary data specificity while eliminating the complexity of processing multiple similar classes separately.

Inventive Principle:

Principle #5Merging (Combining)

Solution Approach 2:

The patent uses inheritance and composition to segment the class structure hierarchically. The superset classes are designed with parent-child relationships that allow specific data requirements to be maintained through inheritance while using a unified structure. This segmentation approach allows the system to handle different message types with specific data needs without creating separate processing logic for each variant.

Inventive Principle:

Principle #1Segmentation

Data Source

PatentUS20250124216A1Systems and methods for publishing messages in a common model

Publication Date: 2025.04.17 MASTERCARD INT INC

AI summary

Example networks and methods are provided for defining a common data model for redundant data in a data specification. One example method includes accessing a message standard, the message standard having multiple message types, each message type including a plurality of classes, each of the classes defined by an .xsd file; splitting the .xsd files into named complexTypes, where each .xsd file includes one complexType which is named for the one complexType; updating references to duplicate named complexTypes to reference an unnumbered superset complexType; and absorbing each of the unique data elements of the duplicate named complexTypes into the unnumbered superset complexType.