Distributed Sink and Filter Architecture for Real-Time Data Routing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing real-time communications systems, such as videoconferences, face challenges in efficiently managing and routing data across distributed networks, leading to potential congestion and reliance on single servers, which can result in instability and limited scalability.

Innovation Solution

A method that utilizes a distributed configuration of sinks, filters, and resources across a network, allowing requests to be forwarded and processed through a hierarchical identifier system, such as URL-based identifiers, to enable efficient data routing and execution without relying on a single server, and allows for dynamic creation and termination of resources like conference bridges based on demand.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Device complexity

If a single server is used to manage real-time communications events, then the system architecture is simple, but the system stability and scalability are limited

Engineering Contradiction:
Improvesystem architectureVSAvoidsystem stability
Core Design Contradiction:
Device complexityVSReliability

Solution Approach 1:

The patent divides the single server architecture into multiple distributed nodes (sources, sinks, and filters) that can independently process communications events. Each node handles specific tasks such as audio mixing, video processing, or data routing, eliminating the single point of failure and improving system reliability while maintaining manageable complexity through modular design.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces intermediary components (filters and conference bridges) that mediate between sources and sinks in the distributed network. These intermediaries manage resource allocation, routing, and coordination between multiple nodes, enabling scalable system growth without requiring direct peer-to-peer connections between all components.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If a distributed configuration of sinks and filters is used across the network, then the scalability and stability are improved, but the device complexity increases

Engineering Contradiction:
Improvesystem stabilityVSAvoidsystem architecture
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent designs distributed nodes with multi-functional capabilities where sources, sinks, and filters can perform multiple roles. For example, a node can simultaneously act as a video source, an audio mixer, and a routing filter for other participants. This universality reduces the total number of specialized components needed, managing system complexity while maintaining distributed architecture benefits.

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

Solution Approach 2:

The patent implements dynamic resource allocation and node registration mechanisms where distributed components can join and leave the network dynamically. The sink data repository and request routing systems automatically adapt to changing network conditions, allowing the system to scale flexibly without requiring rigid pre-configured architectures.

Inventive Principle:
Principle #15Dynamics

3Productivity

If multiple event servers are running to interface very large numbers of participants, then the scalability is improved, but the coordination complexity between servers increases

Engineering Contradiction:
Improvenumber of participantsVSAvoidcoordination between servers
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent introduces conference bridge components as intermediaries that manage coordination between multiple event servers. These bridges handle participant registration, resource allocation, and inter-server communication protocols, reducing the coordination complexity by providing standardized interfaces and automated management functions that simplify multi-server operations.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent implements feedback mechanisms where distributed nodes continuously report their status, resource availability, and load conditions to the network. This feedback enables dynamic load balancing, automatic failover, and intelligent routing decisions that coordinate multiple servers efficiently without requiring complex manual configuration or centralized control.

Inventive Principle:
Principle #23Feedback

4Productivity

If hierarchical identifier system such as URL-based identifiers is used for data routing, then the routing efficiency is improved, but the system complexity increases

Engineering Contradiction:
Improvedata routing efficiencyVSAvoididentifier system
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent adopts universal hierarchical identifier systems (such as URL-based identifiers) that can represent multiple levels of network organization and resource types using a single standardized format. This universal approach simplifies the identifier system by providing consistent routing rules across different network layers, reducing complexity while maintaining high routing efficiency through the structured hierarchy.

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

Data Source

PatentUS8144632B1Methods, systems and program products for efficient communications during data sharing event
Publication Date: 2012.03.27 IOCOM UK LTD
  • US8144632B1 patent drawing
  • US8144632B1 patent drawing
  • US8144632B1 patent drawing

AI summary

One example embodiment of the invention is a method for communicating streaming data between a plurality of users participating in a real-time communications event over a packet based data network, the method comprising the steps of: a source identifying a first sink corresponding to a request, the request including at least a method, one or more method parameters, and a time to live value; the source using a sink data repository to identify a first sink address corresponding to the first sink, the sink data repository comprising sink addresses for a plurality of different sinks; the source communicating the request to said first sink; and, the first sink returning an error message if the time to live has expired, and if the time to live has not expired the first sink processing the request through one or more steps of: acting as a resource by executing the method using the method parameters and communicating a response to the source; acting as a filter by forwarding the request to a second sink; and, redirecting the request back to the source for communicating to a second sink.