Distributed SaaS Stack Fusion for Data Sovereignty

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current real-time communications services for businesses face challenges in on-premise deployments, such as high upfront costs, slow upgrade cycles, and difficulties in providing business-to-business communications, while cloud-based services struggle with latency and data sovereignty concerns, as sensitive information may be stored in third-party data centers that lack trust.

Innovation Solution

A distributed Software-as-a-Service (SaaS) system is implemented, allowing businesses to run a portion of the communications software within their own data centers, while still utilizing cloud services, ensuring data sovereignty and security through a loosely federated identity service and cluster-based Representational State Transfer (REST) architecture, enabling global namespace and seamless communication across multiple companies.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of manufacture

If cloud-based SaaS deployment is used, then upfront costs and IT project complexity are reduced, but latency and data sovereignty concerns increase

Engineering Contradiction:
Improvedeployment complexityVSAvoiddata sovereignty
Core Design Contradiction:
Ease of manufactureVSReliability

Solution Approach 1:

The system segments the SaaS deployment into multiple independent clusters, each associated with a specific organization. Each cluster operates autonomously while maintaining federated identity service connectivity, allowing data to remain in local data centers (preserving sovereignty) while enabling cloud-based service delivery (reducing deployment complexity).

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

A federated identity service acts as an intermediary between distributed clusters, enabling seamless authentication and authorization across organization boundaries without requiring centralized data storage. This mediator allows cloud-based identity management while keeping user data in local data centers.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If on-premise deployment is used, then data sovereignty and security are maintained, but upfront costs and upgrade cycle speed increase

Engineering Contradiction:
Improvedata sovereigntyVSAvoidupgrade speed
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The system implements dynamic cluster configurations where organizations can start with on-premise deployments and gradually integrate with cloud services. The federated identity service dynamically routes authentication requests, allowing seamless transitions from static on-premise to flexible cloud-based models without service disruption.

Inventive Principle:
Principle #15Dynamics

3Ease of operation

If centralized cloud data centers are used, then service management is simplified, but latency and trust concerns increase

Engineering Contradiction:
Improveservice managementVSAvoidcommunication latency
Core Design Contradiction:
Ease of operationVSSpeed

Solution Approach 1:

Each cluster is configured with local quality characteristics optimized for its specific organization's requirements. Clusters can be geographically distributed closer to users, reducing latency while maintaining standardized service management through the federated identity framework. Each cluster's data processing occurs locally, minimizing communication delays.

Inventive Principle:
Principle #3Local quality

Data Source

PatentUS9654518B2Stack fusion software communication service
Publication Date: 2017.05.16 CISCO TECHNOLOGY INC
  • US9654518B2 patent drawing
  • US9654518B2 patent drawing
  • US9654518B2 patent drawing

AI summary

A stack fusion method is implemented at an originator cluster of software services in a distributed Software-as-a-Service (SaaS) system. The method includes receiving a request for a communication service from an originator registered to the originator cluster. The method further includes, responsive to the request, creating a communication protocol object in the originator cluster, discovering a participant cluster on which the participant is registered, notifying the participant via the participant cluster that the communication protocol object exists, and updating an index protocol object in the participant cluster that tracks communication sessions in which the participant is engaged with a reference that points to the communication protocol object in the originator cluster.