Software Analysis Work Allocation for ML Prompt Vetting

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing software analysis technologies face challenges in filtering out unsuitable machine learning model prompts, ensuring the availability of suitable prompts with appropriate metadata, and effectively dividing analysis tasks between machine learning and non-ML analyzers.

Innovation Solution

Implementing software analysis work allocation (SAWA) functionality that determines the suitability of prompts and allocates tasks between machine learning and non-ML analyzers, using a vetting process to ensure only actionable and secure prompts are executed, and optimizing computational resources based on cost thresholds.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If machine learning models are used to perform software analysis, then analysis capability and versatility are improved, but computational cost and resource consumption increase

Engineering Contradiction:
Improveanalysis capabilityVSAvoidcomputational cost
Core Design Contradiction:
Adaptability or versatilityVSUse of energy by moving object

Solution Approach 1:

The patent segments software analysis tasks into different categories and assigns them to appropriate analyzers (ML-based or non-ML) based on task characteristics, thereby optimizing resource usage while maintaining analysis capability

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system dynamically changes operational parameters by selecting different analysis paths (ML-based or non-ML) based on cost thresholds and task requirements, allowing flexible resource management

Inventive Principle:
Principle #35Parameter changes

2Reliability

If machine learning models are deployed for software analysis, then analysis effectiveness is improved, but system complexity increases

Engineering Contradiction:
Improveanalysis effectivenessVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent introduces an intermediary component (the system that selects between ML and non-ML analyzers) that manages the complexity of deploying multiple analysis approaches, simplifying the overall system architecture while maintaining effectiveness

Inventive Principle:
Principle #24Intermediary (Mediator)

3Reliability

If comprehensive prompt filtering is implemented, then security and reliability are improved, but processing time and operational complexity increase

Engineering Contradiction:
ImprovesecurityVSAvoidprocessing time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system performs preliminary actions by pre-evaluating and categorizing analysis prompts, assigning cost thresholds and selecting appropriate analyzers in advance, which reduces processing time during actual analysis operations while maintaining security

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS20250378003A1Software analysis work allocation
Publication Date: 2025.12.11 MICROSOFT TECHNOLOGY LICENSING LLC
  • US20250378003A1 patent drawing
  • US20250378003A1 patent drawing
  • US20250378003A1 patent drawing

AI summary

Embodiments facilitate software analysis by machine learning (ML) models, through extensible software analysis architecture (ESAA) or software analysis work allocation (SAWA). Pluggable ESAA ML modules include a vetted prompt which is actionable for software analysis, with a vetting certification. Some ML modules contain computational cost information such as a token count or model round trip time. Tools are tailored to ML analyzers to control background execution, availability offerings, and results displays. SAWA determines how well a software analyzer meets a prompt's software analysis requirements, and an ML planning model generates an analysis plan that balances software analysis workloads among ML analyzers and non-ML analyzers. ML analyzers are favored for summarization, task decomposition, task scheduling, and source code change review, while non-ML analyzers are otherwise favored. Non-ML analyzers gather control flow, data flow, internal structure, and similar context which is then supplied to an ML analyzer.