Native Application Integration via API Key-Pair Account Linking

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing database systems hinder efficient communication and integration of applications between provider and consumer accounts, limiting the ability to utilize backward integration and requiring external functions that complicate operations.

Innovation Solution

Implementing an application program interface (API) with key-pair authentication for direct communication from consumer accounts to provider accounts, enabling backward integration across different cloud platforms and regions, and allowing synchronous communication.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If external functions are used for application integration, then operations can be performed outside the data system, but the integration becomes complex and requires operations outside the data system

Engineering Contradiction:
Improveapplication integration capabilityVSAvoidintegration complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces an intermediary mechanism (external function interface) that mediates between the data system and external applications. This intermediary allows controlled interaction while maintaining system boundaries, resolving the contradiction by providing integration capability without requiring full external operation complexity

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The integration architecture is segmented into distinct components: internal data system functions, external function interfaces, and application layers. This segmentation allows each component to operate independently with well-defined interfaces, reducing overall integration complexity while maintaining versatility

Inventive Principle:
Principle #1Segmentation

2Productivity

If direct integration from provider to consumer is provided, then application distribution is efficient, but backward integration from consumer to provider is not allowed

Engineering Contradiction:
Improveapplication distribution efficiencyVSAvoidbackward integration capability
Core Design Contradiction:
ProductivityVSAdaptability or versatility

Solution Approach 1:

The patent implements asymmetric integration capabilities where forward integration (provider to consumer) and backward integration (consumer to provider) are handled through different mechanisms. Forward integration uses direct deployment while backward integration uses external function interfaces, allowing both directions to operate efficiently with appropriate protocols for each

Inventive Principle:
Principle #4Asymmetry

3Productivity

If multi-tenant database system is used, then data storage and management is efficient, but direct communication between different tenant accounts is hindered

Engineering Contradiction:
Improvedata management efficiencyVSAvoidinter-account communication ease
Core Design Contradiction:
ProductivityVSEase of operation

Solution Approach 1:

The patent introduces an intermediary communication layer that mediates between different tenant accounts. This intermediary handles authentication, authorization, and data routing while maintaining the security boundaries of the multi-tenant system, enabling direct communication without compromising data management efficiency

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS12562898B2Native application integration in data system
Publication Date: 2026.02.24 SNOWFLAKE INC
  • US12562898B2 patent drawing
  • US12562898B2 patent drawing
  • US12562898B2 patent drawing

AI summary

Techniques for sharing application packages in a multi-tenant database system are described. A provider account can create and share an application package with provider key information. A consumer application can be installed in a consumer account based on the application package and consumer account can be registered using an onboard service user and the provider key information. A unique consumer service user can be registered in the provider account corresponding to the consumer account.