Rule Migration Canonicalization for Vendor-Locked Low-Code Platforms

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Low-code platforms face vendor lock-in issues due to vendor-specific languages, leading to rule redundancy, inconsistency, and difficulty in migrating rules to new platforms, which are hard-coded and lack clear movement or adoption, resulting in inefficient and complex data management.

Innovation Solution

A seamless automated migration system using machine learning algorithms for de-duplication, recontextualization, and canonicalization to transform rules into a clean state, enabling migration to another platform while maintaining integrity and reducing redundancy.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If rules are hard-coded in vendor-specific languages to meet business requirements, then the rules can be executed on the legacy system, but the rules become redundant and difficult to migrate to new platforms

Engineering Contradiction:
Improverule execution reliabilityVSAvoidplatform adaptability
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent introduces an intermediary representation layer between the legacy system and the target platform. Rules are transformed into an intermediate format that preserves their logical meaning while being platform-agnostic. This intermediary representation enables rules to be migrated across different platforms without being locked into vendor-specific languages, thus maintaining both execution reliability and platform adaptability.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent segments rules into modular components that can be independently analyzed, transformed, and migrated. By breaking down complex vendor-specific rules into fundamental logical segments, the system can reassemble them in the target platform's language, ensuring both fidelity to the original logic and compatibility with the new platform.

Inventive Principle:
Principle #1Segmentation

2Adaptability or versatility

If rules are copied and modified to meet new use cases, then the rules can be adapted to different scenarios, but rule redundancy increases and consistency is lost

Engineering Contradiction:
Improverule adaptabilityVSAvoidrule management complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent uses intelligent copying mechanisms that automatically replicate rules across different contexts while maintaining consistency through centralized management. Instead of manual copying and modification that leads to redundancy, the system copies rules in a controlled manner and automatically synchronizes changes across all instances, reducing management complexity while preserving adaptability.

Inventive Principle:
Principle #26Copying

Solution Approach 2:

The patent creates universal rule templates that can serve multiple use cases through parameterization. A single rule definition can be instantiated multiple times with different parameters to meet various business scenarios, eliminating the need to create and manage separate copies of similar rules, thus reducing complexity while maintaining versatility.

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

3Ease of manufacture

If vendor-specific languages are used to implement rules, then the rules can be executed on the legacy system, but vendor lock-in occurs and switching to another provider becomes difficult

Engineering Contradiction:
Improverule implementation easeVSAvoidvendor independence
Core Design Contradiction:
Ease of manufactureVSAdaptability or versatility

Solution Approach 1:

The patent introduces an intermediary representation layer between the legacy system and the target platform. Rules are transformed into an intermediate format that preserves their logical meaning while being platform-agnostic. This intermediary representation enables rules to be migrated across different platforms without being locked into vendor-specific languages, thus maintaining both execution reliability and platform adaptability.

Inventive Principle:
Principle #24Intermediary (Mediator)

4Productivity

If rules are authored in different languages not tailored for the new platform, then the rules can be migrated from the legacy system, but the rules are difficult to read and interpret

Engineering Contradiction:
Improvemigration efficiencyVSAvoidrule interpretability
Core Design Contradiction:
ProductivityVSEase of operation

Solution Approach 1:

The patent applies parameter changes by transforming rules from one language format to another through systematic substitution of syntax elements. The transformation process maps source language constructs to target language equivalents while preserving semantic meaning, enabling efficient migration while producing readable and interpretable rules in the new platform's native language.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS20260079701A1Method and system for code migration
Publication Date: 2026.03.19 JPMORGAN CHASE BANK NA
  • US20260079701A1 patent drawing
  • US20260079701A1 patent drawing
  • US20260079701A1 patent drawing

AI summary

System and methods for migrating codes from one system to another system are provided. A rule repository receives a set of rules of a legacy system. A processor is connected to the rule repository. The processor performs de-duplication to identify and eliminate duplicated entries to produce de-duplicated rules. The processor uses a machine learning algorithm to generate clusters of rules in a clean state by arranging similar de-duplicated rules into groups that meets a similarity threshold. A migration module is provided to present a migration option that uses a recontextualization technique that replaces symbols in the clusters of rules in the clean state with table names and column names to create a set of reduced redundancy and clean rules that can be optionally returned to and executed on the legacy system and to map the clusters of rules in the clean state to a specific format, application, or language.