Key-Value Store Database for Dynamic Form Data

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing database systems for storing form-related data are inefficient, requiring frequent alterations and increased server capacity as data volumes grow, especially for large entities that need to modify forms frequently, leading to performance issues and storage challenges.

Innovation Solution

A key-value store database management system that processes data by assigning unique key-value pairs for each field in fillable forms, allowing real-time addition and modification without altering the entire database, using a combination of WIP, form, and field IDs, and supporting dynamic data types and structures.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Stability of the object's composition

If data is stored in a relational database with tables, links, primary keys and foreign keys, then data can be organized in a structured manner, but the database requires frequent alterations and more powerful servers when data volume increases or forms are modified

Engineering Contradiction:
Improvedatabase structure stabilityVSAvoiddata storage efficiency
Core Design Contradiction:
Stability of the object's compositionVSProductivity

Solution Approach 1:

The patent segments the database into independent form collections and document structures, where each form type is stored as a separate collection with its own schema. This allows individual form modifications without altering the entire database structure, resolving the contradiction between structural stability and storage efficiency.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements dynamic schema evolution by allowing forms to be added, modified, or removed without fixed structural constraints. The database adapts to changing form requirements in real-time, enabling productivity improvements while maintaining structural integrity through flexible document models.

Inventive Principle:
Principle #15Dynamics

2Reliability

If the entire database is altered when forms are modified or new fields are added, then data consistency is maintained, but server performance deteriorates and more powerful servers are required

Engineering Contradiction:
Improvedata consistencyVSAvoidserver capacity
Core Design Contradiction:
ReliabilityVSPower

Solution Approach 1:

The database is segmented into independent form collections where each collection can be modified without affecting others. This segmentation allows localized changes that maintain data consistency within each collection while avoiding system-wide alterations that would require increased server capacity.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent uses document copying mechanisms where form templates can be replicated and modified independently. This allows data consistency to be maintained through template-based replication rather than requiring expensive database-wide synchronization operations.

Inventive Principle:
Principle #26Copying

3Stability of the object's composition

If relational databases are used to store form data, then structured data organization is achieved, but real-time modification and scalability are limited

Engineering Contradiction:
Improvedata organization structureVSAvoidform modification capability
Core Design Contradiction:
Stability of the object's compositionVSAdaptability or versatility

Solution Approach 1:

The patent implements dynamic form schemas that can be modified in real-time without fixed structural constraints. Forms can be added, removed, or have fields modified dynamically, providing high adaptability while maintaining organized data structures through document models and collections.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The database allows parameter changes in form definitions without requiring structural alterations. Field types, validation rules, and form configurations can be modified dynamically, enabling versatile form customization while maintaining stable data organization through flexible document models.

Inventive Principle:
Principle #35Parameter changes

4Quantity of substance

If more powerful servers are deployed to handle increased data volume, then storage capacity increases, but system complexity and costs increase

Engineering Contradiction:
Improvedata storage capacityVSAvoidserver infrastructure complexity
Core Design Contradiction:
Quantity of substanceVSDevice complexity

Solution Approach 1:

The database segments data into manageable form collections that can be independently scaled and managed. This segmentation allows incremental capacity expansion without requiring complex monolithic server infrastructure, reducing system complexity while increasing storage capacity.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The database system is designed with universal document models that can handle diverse form types and data volumes using the same infrastructure. This multi-functionality eliminates the need for specialized server configurations for different data scenarios, reducing infrastructure complexity while maintaining scalable capacity.

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

Data Source

PatentUS11354492B2EDOC utility using non-structured-query-language databases
Publication Date: 2022.06.07 BANK OF AMERICA CORP
  • US11354492B2 patent drawing
  • US11354492B2 patent drawing
  • US11354492B2 patent drawing

AI summary

A database management system for processing large volumes of data in a key-value store database is provided. The system may be configured to receive a plurality of filled fillable request forms where each request form may include a request including a plurality of field labels and a plurality of fillable text fields corresponding to each of the plurality of the field labels. The system may be configured to extract each set of inputted data from each fillable text field. The system may be configured to store, in the key-value store database, for each request form, each of the plurality of field labels and the corresponding set of inputted data as a combination key-value pair. The combination key may be equal to a WIP ID number, form ID number and field ID number. The corresponding value may be equal to the set of data of the corresponding field ID number.