Auto-Discovering DNS-SD Server Location for Cloud Service Access

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current service discovery mechanisms, such as DNS-SD and mDNS, require users to manually input the location of the DNS-SD server or restrict service discovery to the local link, limiting the ability of devices to discover and access cloud-based services without proprietary mechanisms or proxied devices.

Innovation Solution

The proposed solution enables devices to automatically discover the location of the DNS-SD server and UPnP/DLNA services in the cloud using existing standards, allowing for seamless discovery and consumption of cloud services by acting as a UPnP Service Registrar and utilizing specific namespaces and actions within the DNS-SD server, eliminating the need for manual input of server locations.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If DNS-SD server location is manually input by users, then service discovery can be performed, but user operation complexity increases and automation decreases

Engineering Contradiction:
Improveservice discovery operationVSAvoidserver location input
Core Design Contradiction:
Ease of operationVSExtent of automation

Solution Approach 1:

The system performs self-service by automatically discovering the DNS-SD server location without requiring manual user input. The client device autonomously queries the network to locate the DNS-SD server, eliminating the need for users to manually enter server addresses and thereby increasing both ease of operation and automation extent.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system performs preliminary action by pre-configuring automatic server location discovery mechanisms. Before service discovery begins, the client device is pre-programmed to automatically locate the DNS-SD server through network queries, so that when service discovery is initiated, the server location is already known without requiring user intervention.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If service discovery is restricted to local link, then network security is improved, but service accessibility deteriorates

Engineering Contradiction:
Improvenetwork securityVSAvoidservice accessibility
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The gateway acts as an intermediary between the local network and cloud services. It receives service discovery requests from local devices, forwards them to cloud-based DNS-SD servers, and relays the discovered service information back to local devices. This intermediary approach allows services to be discovered beyond the local link while maintaining network security boundaries.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system extends service discovery from the local network dimension to the cloud dimension. By introducing a new dimensional layer (cloud-based DNS-SD server accessible through the gateway), the system enables devices to discover services both locally and remotely, thereby increasing adaptability without compromising local network security.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

3Adaptability or versatility

If proprietary mechanisms are used for cloud service discovery, then service discovery capability is improved, but device complexity increases

Engineering Contradiction:
Improvecloud service discovery capabilityVSAvoiddiscovery mechanism complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system applies universality by using the existing DNS-SD protocol for both local and cloud service discovery. The same DNS-SD mechanism that works for local service discovery is extended to work with cloud-based services through the gateway, eliminating the need for proprietary or specialized discovery mechanisms and thereby reducing device complexity while maintaining versatility.

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

Solution Approach 2:

The system merges local and cloud service discovery into a unified process. By combining the existing DNS-SD protocol with gateway-mediated cloud access, the system creates a single integrated service discovery mechanism that handles both local and remote services, reducing complexity compared to maintaining separate proprietary mechanisms.

Inventive Principle:
Principle #5Merging (Combining)

4Adaptability or versatility

If multiple applications are used for different services, then service functionality is improved, but system complexity increases

Engineering Contradiction:
Improveservice functionalityVSAvoidapplication management complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The unified service discovery portal provides multi-functionality by enabling access to multiple different services (cloud-based and local) through a single interface. Instead of requiring separate applications for each service, the portal discovers and presents all available services in one location, allowing users to access diverse functionality without managing multiple applications, thereby reducing system complexity while maintaining versatility.

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

Data Source

PatentUS11115507B2Service discovery
Publication Date: 2021.09.07 CABLE TELEVISION LAB INC
  • US11115507B2 patent drawing
  • US11115507B2 patent drawing
  • US11115507B2 patent drawing

AI summary

Service discovery and other operations related to enabling devices to announce, discover or otherwise control their services and/or the services offered or available from other devices is contemplated. The service discovery may facilitate service discovery for services sourced from devices inside and outside of a network and/or from devices having incompatible messaging capabilities.