Holistic API for Unified Multi-Source Data Retrieval

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional systems require separate APIs for each type of resource or file, leading to inefficiencies in data retrieval as they are reactive, necessitating individual requests to multiple sources, resulting in latency and limited scalability.

Innovation Solution

A holistic API that pre-fetches instances of resources from various sources and stores them on a server system, allowing for unified search queries across different types and sources, reducing latency and enhancing scalability by providing aggregated search results.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If separate individual APIs are required to interface to each different source and query for each different type of resource, then the system can maintain simplicity in API design, but the system complexity increases and scalability is limited

Engineering Contradiction:
ImproveAPI versatilityVSAvoidSystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements a universal API that can interface with multiple different data sources and query for different types of resources through a single unified interface. This eliminates the need for separate individual APIs for each source and resource type, thereby reducing system complexity while maintaining high adaptability and versatility.

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

Solution Approach 2:

The patent segments the data retrieval process into two phases: automatic gathering of resource instances from various sources during system initialization, and selective querying based on user requests. This segmentation allows the API to maintain simplicity in its interface design while managing the complexity of multiple data sources internally.

Inventive Principle:
Principle #1Segmentation

2Loss of time

If conventional reactive APIs search for results in response to individual requests, then the system maintains low resource consumption, but the response time increases due to latency from multiple sequential requests

Engineering Contradiction:
ImproveResponse timeVSAvoidSystem resource consumption
Core Design Contradiction:
Loss of timeVSUse of energy by stationary object

Solution Approach 1:

The patent performs preliminary action by automatically gathering and storing instances of resources from multiple data sources during system initialization or background processes. This pre-fetching of data eliminates the need for sequential individual requests when users query the system, significantly reducing response time while the system only consumes resources when actually needed for storage and retrieval operations.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent enables continuous availability of resource instances in the system storage, allowing the API to respond immediately to user queries without interruption. This continuity of useful action eliminates the latency inherent in reactive sequential requests, improving response time while maintaining efficient resource consumption through on-demand access patterns.

Inventive Principle:
Principle #20Continuity of useful action

3Productivity

If a single holistic API gathers and stores instances of resources from multiple sources, then the system achieves fast search response and high scalability, but the initial resource consumption increases

Engineering Contradiction:
ImproveData retrieval efficiencyVSAvoidInitial resource consumption
Core Design Contradiction:
ProductivityVSUse of energy by stationary object

Solution Approach 1:

The patent implements preliminary action by having the system automatically gather and store resource instances from multiple data sources during initialization or background processes. This pre-fetching strategy enables fast search responses and high scalability for subsequent queries, while the initial resource consumption is justified by the significant performance improvements achieved during actual data retrieval operations.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent creates copies of resource instances from various data sources and stores them in the system's internal storage. This copying mechanism allows the system to serve multiple query requests efficiently without repeatedly accessing the original sources, thereby improving data retrieval efficiency and scalability while managing resource consumption through intelligent caching and storage strategies.

Inventive Principle:
Principle #26Copying

4Ease of operation

If conventional APIs require individual requests to each source, then the system maintains simplicity in request handling, but the ease of operation decreases due to the need to specify source and type for each query

Engineering Contradiction:
ImproveQuery simplicityVSAvoidRequest handling complexity
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The patent implements a universal API interface that can handle queries for different types of resources from multiple data sources through a single unified request mechanism. This eliminates the complexity of specifying individual source and type parameters for each query, significantly improving ease of operation while the request handling complexity is managed internally through the system's intelligent resource gathering and indexing mechanisms.

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

Data Source

PatentUS12019684B2Application programming interface arranged to interface with a plurality of data sources
Publication Date: 2024.06.25 MICROSOFT TECHNOLOGY LICENSING LLC
  • US12019684B2 patent drawing
  • US12019684B2 patent drawing
  • US12019684B2 patent drawing

AI summary

An API on a server system automatically gathers an instance of each multiple resources from different sources, storing each instance in the server system. Later, a call to the API is received from a querying application, the call comprising a search query comprising. In response, the API selects one or more of the plurality of resources as search results based on evaluating the criterion or criteria against the already-gathered instances of the resources as stored in the server system. The API returns a search response to the querying application, making the corresponding stored instances available to a consuming party In embodiments the API is “holistic” in nature, in that the search results may comprise different types of resource (e.g. file, email, task), from different types source (e.g. type of application they originate from), and/or related to the consuming part by different types of activity (e.g. used, modified shared, trending).