Function-Criticality Software Classification for Partial Updates

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Current software update management techniques are inefficient and resource-intensive, often requiring interruptions and wasteful use of processing and memory resources due to incompatibilities between legacy and new software versions, and fail to address update failures effectively.

Innovation Solution

A system that classifies software codes based on functionality, criticality levels, and common flow paths, deploys them into different racks, monitors updates, and addresses failures by switching back to the current version upon error detection, using video recordings and log files for recovery.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If software code is updated from legacy to new version, then software functionality is improved, but processing resources are wasted due to interruptions and restarts

Engineering Contradiction:

Improvesoftware update reliabilityVSAvoidprocessing resource waste

Core Design Contradiction:

ReliabilityVSLoss of energy

Solution Approach 1:

The software code is divided into multiple functions, and the system identifies and updates only the specific functions that need modification rather than interrupting and restarting the entire software code. This segmentation allows partial execution to continue while updating specific portions, reducing processing resource waste.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The system performs preliminary analysis to identify common flow paths and critical functions before updating. By pre-identifying which functions can be updated independently and which require coordination, the system avoids unnecessary interruptions and restarts, thereby reducing processing resource consumption during updates.

Inventive Principle:

Principle #10Preliminary action

2Reliability

If all functions of software code are tested during update, then update reliability is improved, but processing time and resources increase significantly

Engineering Contradiction:

Improveupdate compatibilityVSAvoidtesting duration

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

The system extracts and identifies the main function from multiple functions in the software code. During testing, it focuses specifically on testing whether the main function operates as expected after updates, rather than testing all functions comprehensively. This extraction approach maintains update reliability while significantly reducing testing time and processing resources.

Inventive Principle:

Principle #2Taking out (Extraction)

Solution Approach 2:

The system performs partial testing by focusing only on the main function and critical paths rather than exhaustive testing of all functions. This partial action approach is sufficient to ensure update compatibility while avoiding the excessive time and resource consumption of complete testing.

Inventive Principle:

Principle #16Partial or excessive action

3Adaptability or versatility

If software code execution is interrupted for updates, then new functionality is deployed, but productivity is reduced due to restarts

Engineering Contradiction:

Improvesoftware version updateVSAvoidupdating efficiency

Core Design Contradiction:

Adaptability or versatilityVSProductivity

Solution Approach 1:

The system dynamically determines which functions can be updated during execution and which require interruption. By dynamically analyzing the software code structure and execution state, it allows updates to proceed without interruption for functions that can be updated independently, thereby maintaining productivity while enabling software version updates.

Inventive Principle:

Principle #15Dynamics

Solution Approach 2:

The system maintains continuous execution of software code by updating only specific functions rather than interrupting the entire execution flow. This continuity allows the software to remain productive during updates, as non-affected functions continue to execute while update-related functions are modified and tested.

Inventive Principle:

Principle #20Continuity of useful action

4Productivity

If software code is classified and deployed into different racks, then resource allocation is optimized, but system complexity increases

Engineering Contradiction:

Improveresource utilization efficiencyVSAvoidsystem architecture

Core Design Contradiction:

ProductivityVSDevice complexity

Solution Approach 1:

The system implements a universal classification framework that can categorize software code by multiple criteria (functionality, criticality, dependencies) using the same rack structure. This multi-functional classification approach optimizes resource allocation across different dimensions without requiring separate complex systems for each classification type.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Data Source

PatentUS12423092B2System and method for classifying software code based on functionality and criticality

Publication Date: 2025.09.23 BANK OF AMERICA CORP

AI summary

A system for classifying software code determines a first function, a first set of operations, and a first criticality level of a first software code. The system determines a second function, a second set of operations, and a second criticality level of the second software code. The system determines that the first function of the first software code corresponds to the second function of the second software code. The system compares the operations of the first software code with the operations of the second software code and determines that the first and second software code have at least one operation in common with each other. The system determines that the first criticality level of the first software code corresponds to the second criticality level of the second software code. In response, the system classifies the first software code and the second software code in a first group.