Private Cloud Routing Server Connection Mechanism

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional methods for Smart Device Clients to access private cloud servers are cumbersome, requiring complex setups, fixed IP addresses, or reliance on public cloud-based routing servers, which compromise privacy and security, and are not user-friendly for consumer environments.

Innovation Solution

A system and method that employs a private cloud call-back server and private cloud routing server to establish a secure session-based message mechanism, allowing Smart Device Clients to access private cloud services without a public cloud-based routing server, enabling secure and private communication through a public cloud network, while minimizing latency and setup complexity.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If a fixed IP address and port opening are configured for the router to access the private cloud storage server, then the smart device client can locate and access the server from outside the LAN, but the setup becomes complex and requires technical expertise that is not user-friendly for consumers

Engineering Contradiction:
ImproveEase of access to private cloud serverVSAvoidRouter configuration complexity
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The system performs self-service by automatically generating unique identifiers and cryptographic keys for each device, and automatically establishing secure communication channels without requiring manual router configuration. The smart device client and private cloud server independently negotiate their connection parameters, eliminating the need for users to configure fixed IP addresses or open ports on routers.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

A public key infrastructure acts as an intermediary, allowing devices to establish secure connections without direct IP address exposure. The cryptographic key exchange mechanism mediates the connection process, enabling devices to communicate securely through the internet without requiring traditional port forwarding or fixed IP configuration.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If dynamic DNS service and port mapping are configured to enable access without fixed IP address, then the setup complexity increases with additional router configuration, but flexible access is enabled

Engineering Contradiction:
ImproveAccess flexibility without fixed IPVSAvoidRouter and DDNS configuration complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

Each device independently generates and manages its own cryptographic identity and connection parameters. The system automatically adapts to dynamic IP addresses by using peer-to-peer connection establishment based on exchanged cryptographic keys, eliminating the need for DDNS or port mapping configuration.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent replaces the mechanical network configuration system (fixed IPs, port forwarding, DDNS) with a cryptographic system for establishing connections. Instead of relying on network infrastructure configuration, devices use cryptographic key exchange to establish secure channels, substituting network-layer mechanisms with application-layer cryptographic mechanisms.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

3Adaptability or versatility

If a public cloud-based routing server is used to enable access without fixed IP address, then access flexibility is improved, but privacy and security are compromised

Engineering Contradiction:
ImproveAccess flexibility from anywhereVSAvoidPrivacy and security
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent extracts the trusted third party (public cloud routing server) from the connection establishment process. Instead of relying on an external server to route connections, the system enables direct peer-to-peer connections between devices using cryptographic key exchange, removing the intermediary that compromises privacy and security.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

Devices independently establish secure connections with each other without requiring a public cloud server to mediate the connection. Each device generates its own cryptographic credentials and directly negotiates secure communication channels, making the system self-sufficient and eliminating reliance on external routing infrastructure.

Inventive Principle:
Principle #25Self-service

4Ease of operation

If traditional firewall penetration methods are used to access the private cloud server, then external access is enabled, but the setup becomes cumbersome and requires technical expertise

Engineering Contradiction:
ImproveExternal access to private cloudVSAvoidFirewall configuration complexity
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

Cryptographic key exchange acts as an intermediary mechanism that bypasses the need for firewall penetration. Instead of attempting to establish direct IP-based connections that require firewall configuration, devices exchange cryptographic credentials that enable secure communication through the firewall without requiring firewall rule changes.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent replaces the mechanical firewall penetration approach with a cryptographic authentication approach. Rather than configuring firewall rules to allow incoming connections, the system uses outbound cryptographic handshakes that are typically permitted by firewalls, substituting network configuration with cryptographic authentication.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

Data Source

PatentUS11863529B2Private cloud routing server connection mechanism for use in a private communication architecture
Publication Date: 2024.01.02 KINGSTON DIGITAL INC
  • US11863529B2 patent drawing
  • US11863529B2 patent drawing
  • US11863529B2 patent drawing

AI summary

A method for use with a public cloud network is disclosed. The method includes setting up at least one virtual machine, at least one private cloud call-back server (PCCBS) and at least one smart device client on the side of the PCCBS to provide cloud based web services, and at least one private cloud routing server (PCRS) and at least one smart device client on the side of the PCRS in a client server relationship. The virtual machine and PCCBS usually reside in a hyperscale data center, while the PCRS resides in the client's remote premises. An internet platform owner that maintains the virtual machine, offers to a subscriber to host the PCCBS in the virtual machine, constructs and deploys a community pair of peer-to-peer communication relationship between at least one PCCBS Device Client and a PCRS Device Client.