Common Software Environment for Platform-Independent Storage APIs

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Conventional programming environments for data storage devices lack flexibility and platform independence, leading to static and non-expandable programming models that hinder software development and integration, particularly due to varying hardware and software platforms with different interface protocols and management systems.

Innovation Solution

A common software environment (CSE) is introduced that leverages existing platform capabilities and technologies to provide a scalable, unified architecture for managing network-attached storage (NAS) and object/block services, enabling flexible and platform-independent programming across different storage systems by using APIs to insulate code from underlying platform dependencies and allowing execution in both user and kernel modes.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If conventional programming environments are used for data storage devices, then platform-specific implementation is achieved, but flexibility and platform independence deteriorate

Engineering Contradiction:

Improveplatform independenceVSAvoidprogramming model complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces an intermediary layer (common software environment and abstraction layer) between the hardware platform and the programming model. This intermediary provides unified interfaces and translation mechanisms that enable platform-independent code execution while handling platform-specific variations, thus resolving the contradiction between platform independence and programming complexity.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent segments the programming environment into distinct layers: a platform-independent common software environment layer and platform-specific implementation layers. This segmentation allows the upper layers to remain flexible and portable while the lower layers handle platform-specific complexities, resolving the contradiction between adaptability and device complexity.

Inventive Principle:

Principle #1Segmentation

2Adaptability or versatility

If static programming models are used, then implementation simplicity is maintained, but expandability and flexibility deteriorate

Engineering Contradiction:

Improvesoftware expandabilityVSAvoidimplementation simplicity

Core Design Contradiction:

Adaptability or versatilityVSEase of manufacture

Solution Approach 1:

The patent implements a dynamic programming model where the common software environment can be extended and configured at runtime. The system supports dynamic loading of modules, runtime configuration of storage services, and flexible composition of software components, enabling expandability while maintaining implementation simplicity through standardized interfaces.

Inventive Principle:

Principle #15Dynamics

Solution Approach 2:

The patent creates a universal programming model in the common software environment that can perform multiple functions across different storage platforms. The unified architecture supports various storage services, protocols, and operations through a single extensible framework, providing both expandability and implementation simplicity.

Inventive Principle:

Principle #6Universality (Multi-functionality)

3Productivity

If platform-specific code is written, then hardware optimization is achieved, but code portability and duplication efforts deteriorate

Engineering Contradiction:

Improvedevelopment efficiencyVSAvoidcode duplication time

Core Design Contradiction:

ProductivityVSLoss of time

Solution Approach 1:

The patent uses copying mechanisms where a single master copy of the software runs in the common software environment and can be replicated or instantiated multiple times across different platforms. This eliminates the need to write and maintain separate codebases for each platform, significantly reducing development time and effort while maintaining platform-specific optimizations through configuration rather than code duplication.

Inventive Principle:

Principle #26Copying

Data Source

PatentUS8850460B1Techniques for performing a remote procedure call using remote procedure call configuration information

Publication Date: 2014.09.30 EMC IP HLDG CO LLC

AI summary

Described are techniques for performing remote procedure calls (RPCs). An RPC API is described which provides for using an optimized technique and an unoptimized technique for performing RPCs. The optimized technique includes a client container performing a call to obtain RPC configuration information which is then stored by the client container and may be used by the client container in connection with multiple RPC invocations. Techniques are also described for communicating parameter information between containers executing in different address spaces by forming parameter information on the client side using embedded lists, encoding the parameter information on the client side prior to transmission to the server, and transmitting the encoded parameter information to the server which determines output parameters and returns the output parameters to the client.