LLM Codeless Framework for Secure Enterprise App Integration

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing enterprise applications face challenges in customization due to reliance on relational databases, leading to inefficient functioning, complex data abstraction issues, and difficulties in integrating multiple functions without impacting existing flows, along with vulnerabilities from plugin data processing and security concerns.

Innovation Solution

A large language model (LLM) based development application framework that includes LLM agents, an expression builder, and a plugin execution engine to structure enterprise applications, enabling secure and efficient codeless development by identifying intents, determining database relations, recommending plugins, and managing data flows.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a relational database (RDBMS) is used to provide transactional support, then data storage and transactional integrity are improved, but the system becomes a big monolith with inefficient complex application functions

Engineering Contradiction:
Improvetransactional integrityVSAvoidsystem architecture complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent segments the monolithic RDBMS architecture into a distributed graph database system where data is stored as interconnected nodes rather than in traditional relational tables. This segmentation allows the system to maintain transactional integrity through graph queries while reducing architectural complexity by eliminating the need for complex stored procedures and triggers.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent replaces the mechanical RDBMS storage engine with a graph database system that uses graph theory concepts to store and query data. This substitution eliminates the need for complex SQL queries, joined tables, and transactional locking mechanisms, thereby reducing system complexity while maintaining reliability.

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

2Adaptability or versatility

If stored procedures and database triggers are used to build logics, then data processing capabilities are improved, but technical issues arise resulting in inefficient complex application functions

Engineering Contradiction:
Improvedata processing capabilitiesVSAvoidapplication function efficiency
Core Design Contradiction:
Adaptability or versatilityVSProductivity

Solution Approach 1:

The patent extracts the business logic from the database layer and places it in the application layer. Instead of using stored procedures and triggers within the database, the system uses graph queries to retrieve data and then processes it using application-level code, thereby eliminating the technical issues associated with database-level logic while maintaining data processing capabilities.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent introduces an intermediary layer between the graph database and the application logic. This intermediary layer handles the translation between graph queries and application processing, allowing for efficient data retrieval while separating concerns to improve overall system productivity.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Loss of time

If codeless development is used to overcome modification problems, then development time is reduced, but the architecture remains unsupportive of multiple data abstractions and distinct data models

Engineering Contradiction:
Improvedevelopment timeVSAvoiddata abstraction support
Core Design Contradiction:
Loss of timeVSAdaptability or versatility

Solution Approach 1:

The patent creates a universal graph data model that can represent multiple data abstractions and distinct data models through a common graph structure. This universal model allows the codeless development platform to support various data types and relationships without requiring separate architectural support for each data abstraction, thereby maintaining adaptability while reducing development time.

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

Solution Approach 2:

The patent uses parameter changes in the graph query language to adapt to different data abstractions. By allowing flexible parameter definition in graph queries, the system can work with multiple data models and abstractions through a unified codeless interface, eliminating the need for architecture changes while maintaining versatility.

Inventive Principle:
Principle #35Parameter changes

4Ease of operation

If a single data abstraction is used to resolve data needs, then data access is simplified, but operations slow down when the system scale grows multifold

Engineering Contradiction:
Improvedata access simplicityVSAvoidsystem operation speed
Core Design Contradiction:
Ease of operationVSProductivity

Solution Approach 1:

The patent implements a dynamic data access layer that automatically adapts to the scale of the system. The graph database structure allows for dynamic query optimization where the system can adjust query execution strategies based on data volume and complexity, maintaining both simplicity of access and speed of operation even as the system grows.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent transitions from traditional two-dimensional relational table access to three-dimensional graph traversal. This dimensional change allows for more efficient data access patterns that scale better, enabling the system to handle larger datasets while maintaining simple access patterns through graph queries that traverse relationships rather than scanning tables.

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

5Adaptability or versatility

If plugins are integrated to enrich functionality, then system versatility is improved, but security vulnerabilities and data processing issues arise

Engineering Contradiction:
Improvefunctionality enrichmentVSAvoidsecurity vulnerabilities
Core Design Contradiction:
Adaptability or versatilityVSObject-affected harmful factors

Solution Approach 1:

The patent implements a feedback mechanism that continuously monitors and validates plugin operations against predefined security rules. This feedback loop detects potential vulnerabilities and data processing issues in real-time, allowing the system to prevent harmful actions while maintaining the versatility of plugin integration.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The patent applies prior cushioning by implementing security validation layers before plugins can access data. The system pre-establishes security rules and data processing constraints that must be satisfied before any plugin operation is permitted, thereby preventing security vulnerabilities and data processing issues before they can occur while still allowing functionality enrichment.

Inventive Principle:
Principle #11Beforehand cushioning (Prior cushioning)

Data Source

PatentUS20260079678A1LLM based development application framework for codeless development of enterprise application
Publication Date: 2026.03.19 NB VENTURES INC DBA GEP
  • US20260079678A1 patent drawing
  • US20260079678A1 patent drawing
  • US20260079678A1 patent drawing

AI summary

The present invention provides a large language model (LLM) based development application framework and a method for codeless development of one or more enterprise application. The invention includes a layered platform architecture for supporting and executing development of SCM applications. The development framework includes one or more LLM agents for executing various operations in the enterprise application.