Intelligence Selection and Retrieval Language for Database Interoperability

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Interoperability issues between different data systems and architectures hinder efficient data retrieval and sharing, particularly in data-rich environments like the Intelligence Community, due to incompatibility and geographical barriers, and existing solutions like middleware are costly to maintain and limited in their applicability.

Innovation Solution

The Intelligence Selection and Retrieval Language (ISRL) enables seamless communication between data sources and applications by providing a common, open language for querying and retrieving data, eliminating the need for middleware and reducing maintenance costs through lightweight tools like the ISRL Developer's Kit and Application Connector Interface.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If middleware is used to enable communication between different data systems, then interoperability is improved, but maintenance cost and system complexity increase

Engineering Contradiction:
ImproveinteroperabilityVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent extracts the translation functionality from heavy middleware and embeds it directly into the database interfaces. Each database implements a translation layer that converts its proprietary query language to SQL, eliminating the need for complex external middleware while maintaining interoperability.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent introduces SQL as a universal intermediary language that all databases can understand. By translating various database query languages into SQL, the system enables communication between different database types without requiring complex middleware specific to each database pair.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If custom interfaces are developed for each new system, then data access is enabled, but development time and cost increase

Engineering Contradiction:
Improvedata access capabilityVSAvoiddevelopment time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent creates a universal interface layer based on SQL that can work with multiple database types (relational, object-oriented, hierarchical). This single universal interface replaces the need for developing custom interfaces for each database system, significantly reducing development time and enabling reuse across projects.

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

3Adaptability or versatility

If data accessibility is limited, then strategic advantage is maintained, but interoperability is reduced

Engineering Contradiction:
Improvedata accessibilityVSAvoidstrategic control
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent implements local quality control by allowing each database to maintain its own security policies and access control mechanisms at the local level, while the translation layer ensures standardized access patterns. This enables broad interoperability while preserving each system's ability to control its own data strategically.

Inventive Principle:
Principle #3Local quality

Data Source

PatentUS7747569B2Systems, methods, and language for selection and retrieval of information from databases
Publication Date: 2010.06.29 CALLIDUS SOFTWARE INC
  • US7747569B2 patent drawing
  • US7747569B2 patent drawing
  • US7747569B2 patent drawing

AI summary

The invention provides a system configured to enable a first entity to query a second entity for a result, the system comprising a language specification component and an interface between the first entity and the second entity. The language specification component defines a communications language by which the first and second entities can communicate with each other. The interface is operable to receive from the second entity an instance of a generic request that is specific to the second entity, the instance of the generic request providing information about at least one query element that is supported in a second-entity specific request; and convert a first query from the first entity to the second entity into a second query, wherein the second query includes the at least one query element that is supported in the second-entity specific request.