Program-Dependent Component Amalgamation Without Full Build Instructions

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The complexity and incompleteness of build instructions in software development lead to challenges in determining build dependencies, security vulnerabilities, and licensing requirements, especially when build files are unavailable or incomplete, resulting in inefficiencies and limitations in security and licensing analyses.

Innovation Solution

The implementation of build dependency amalgamation (BDA) methods that ascertain multiple name resolutions for build dependencies, form a union of these resolutions, and supply it to analysis tools, enabling security and licensing analyses without requiring a full program build, thereby conserving computational resources.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If build instructions are made complete and detailed to accurately determine build dependencies, then analysis accuracy improves, but build process complexity and time increase

Engineering Contradiction:
Improveanalysis accuracyVSAvoidbuild process time
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The patent performs preliminary dependency extraction and program representation generation during the build process, storing results for later analysis. This allows security and licensing analyses to be conducted without requiring a complete rebuild, as the necessary dependency information has already been captured in advance.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent creates program representations (copies of build information) that can be used for analysis without executing the full build process. These representations include dependency graphs and component information that replicate the essential build data needed for security and licensing analyses.

Inventive Principle:
Principle #26Copying

2Loss of information

If a full program build is performed to obtain complete dependency information, then analysis completeness improves, but computational resource consumption increases

Engineering Contradiction:
Improvedependency information completenessVSAvoidcomputational resource consumption
Core Design Contradiction:
Loss of informationVSUse of energy by moving object

Solution Approach 1:

The patent extracts only the necessary dependency information and program representations needed for security and licensing analyses, rather than performing a complete build. The dependency extraction tool selectively gathers component identities, versions, and relationships without compiling the entire program.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent performs partial builds or dependency resolution only for the portions of the program needed for analysis. Instead of building the entire program, it resolves dependencies and generates representations for the specific components relevant to security and licensing checks.

Inventive Principle:
Principle #16Partial or excessive action

3Ease of operation

If build instructions are simplified to reduce complexity, then build process ease improves, but ability to handle incomplete or inconsistent instructions worsens

Engineering Contradiction:
Improvebuild process easeVSAvoiddependency determination reliability
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent implements self-service mechanisms where the dependency extraction tool automatically resolves ambiguities and inconsistencies in build instructions by analyzing multiple name resolutions and forming unions of candidate dependencies. The system autonomously handles incomplete information without requiring manual intervention or complex build configurations.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent uses feedback loops to iteratively refine dependency resolution by analyzing build attempts, identifying inconsistencies, and adjusting the dependency graph accordingly. The system learns from build outcomes and improves its dependency determination accuracy over time.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS20250328323A1Program dependent component amalgamation
Publication Date: 2025.10.23 MICROSOFT TECHNOLOGY LICENSING LLC
  • US20250328323A1 patent drawing
  • US20250328323A1 patent drawing
  • US20250328323A1 patent drawing

AI summary

Some embodiments construct a set of build dependencies for a program without access to a full set of build instructions. When multiple clashing name resolutions are identified for a particular dependency, a union of the alternative versions is formed. Intermediate representations of the union of program versions, such as symbol tables, abstract syntax trees, and other internal compiler data structures, are emitted to persistent non-volatile storage, instead of using a single resolution to create temporary intermediate data to build an executable program. Security analysis and licensing analysis utilize the persisted program representations to analyze the union of multiple overlapping but different versions of the program.