Patent 10735488
Derivative works
Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.
Active provider: Google · gemini-2.5-flash
Derivative works
Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.
Defensive Disclosure for US Patent 10735488
Current Date: 2026-05-15
Patent Under Analysis: US10735488B2 - "Method of downloading digital content to be rendered"
Goal: To establish prior art for potential future incremental improvements, rendering them obvious or non-novel, based on the core claims of US10735488B2. The independent claims of US10735488B2 describe a method (Claim 1) and a non-transitory computer-readable storage medium (Claim 2) for downloading digital content by:
- Downloading a list of content servers.
- Tracking service level statistics for these servers.
- Selecting a first content server based on these statistics.
- Downloading a first content segment.
- Detecting service degradation from the first server and imperceptibly selecting a second content server based on statistics.
- Downloading a second content segment from the second server.
This defensive disclosure will generate derivative variations along five axes, providing enabling descriptions and visual diagrams.
Derivative Variations
Axis 1: Material & Component Substitution
Derivative 1.1: Client-Side Hardware-Accelerated Service Level Tracking
Enabling Description:
A client device, specifically an embedded system with a dedicated Network Processing Unit (NPU) or a specialized hardware accelerator, performs service level statistics tracking. Instead of software-only metrics, the NPU directly monitors network interface card (NIC) performance counters, packet loss rates at the physical and data link layers, and latency measurements for each server in the downloaded list. This hardware-offloaded tracking reduces CPU overhead and provides more precise, real-time performance data. The NPU aggregates these low-level statistics and exposes them via a dedicated memory-mapped register interface or a high-speed inter-processor communication bus to the main application processor. Server selection logic, potentially implemented as firmware within the NPU or as a highly optimized kernel module, uses these hardware-derived statistics to select content servers for digital content segments.
graph TD
A[Network Accessible Server] --> B{Download Server List};
B --> C[Client Device with NPU];
C --> D[NPU / Hardware Accelerator];
D -- Monitors --> E[NIC Performance Counters];
E -- Provides Real-time Stats --> D;
D -- Aggregates & Exposes Stats --> F[Client Application Processor];
F -- Uses Stats for Selection --> G[Server Selection Logic];
G --> H{Select First Content Server};
H --> I[First Content Server];
I -- Downloads First Segment --> C;
C -- Detects Degradation (via NPU/F) --> G;
G --> J{Select Second Content Server};
J --> K[Second Content Server];
K -- Downloads Second Segment --> C;
Derivative 1.2: Content Server Substitution with Edge Computing Nodes
Enabling Description:
The "content servers" are replaced by geographically distributed edge computing nodes, optimized for content delivery to proximate client devices. These edge nodes are low-power, high-density computing clusters specifically designed for caching and serving digital content segments at the network edge. The client device, upon receiving the server list, receives a list of these edge computing nodes. Service level statistics tracked by the client would include not only network latency and throughput but also the geographical proximity and current load of these edge nodes, potentially determined via IP geolocation services or advertised load metrics from the edge nodes themselves. Server selection prioritizes edge nodes to minimize last-mile latency and improve content rendering continuity.
graph TD
A[Central Network Server] --> B{Download Edge Server List};
B --> C[Client Device];
C -- Tracks --> D[Edge Computing Nodes (Content Servers)];
D -- Provide Content Segments --> C;
subgraph Service Level Tracking
E[Network Latency]
F[Edge Node Load]
G[Geographical Proximity]
end
D -- Exposes Metrics --> E, F, G;
C -- Selects based on E, F, G --> D;
C -- Degradation Detection --> H{Seamless Switch to another Edge Node};
H --> D;
Derivative 1.3: Data Storage Substitution with Solid-State Persistent Memory
Enabling Description:
On the client device, the temporary storage for downloaded content segments (e.g., in a spooler directory as described in the patent) is implemented using Solid-State Persistent Memory (SSPM) instead of conventional DRAM or flash storage. SSPM offers DRAM-like speeds with non-volatility, allowing for rapid buffering, low-latency access, and instant resume capabilities across power cycles without requiring re-downloading of segments. This improves the "substantially imperceptible" server replacement by minimizing any potential I/O bottlenecks on the client side. Service level tracking might also incorporate client-side SSPM write/read performance metrics to ensure segments are effectively staged for rendering.
classDiagram
class ClientDevice {
+CPU
+NetworkInterface
+SSPM (Storage)
+MediaPlayer
+DownloadManager
+MemoryManager
}
class ServerList {
+serverIDs: List<string>
+serverURLs: List<string>
}
class ContentServer {
+serverID: string
+contentSegments: List<byte[]>
}
class ServiceLevelStats {
+serverID: string
+latency: float
+throughput: float
+errorRate: float
+sspmWritePerf: float
}
ClientDevice "1" -- "*" ContentServer : downloads from
ClientDevice "1" -- "1" ServerList : downloads
ClientDevice "1" -- "1" ServiceLevelStats : tracks
ClientDevice -- DownloadManager
ClientDevice -- MemoryManager
MemoryManager -- SSPM : manages
DownloadManager -- SSPM : stores segments
SSPM -- MediaPlayer : provides segments
Axis 2: Operational Parameter Expansion
Derivative 2.1: Hyper-Scale, Ultra-Low Latency Live Event Streaming
Enabling Description:
The method is scaled to manage content delivery for hyper-scale live events (e.g., global esports tournaments, concurrent virtual reality concerts) with millions of simultaneous users, requiring sub-100ms end-to-end latency. Content segments are reduced to micro-segments (e.g., 50ms duration) to enable extremely fine-grained switching. Service level statistics are tracked and updated at sub-second intervals, utilizing hardware-timed packet injection and reception to measure network jitter, packet reordering, and micro-burst packet loss. Server selection algorithms incorporate predictive analytics to anticipate degradation based on traffic patterns, server load forecasts, and historical performance, allowing pre-emptive server switching before a perceptible degradation occurs. This also involves geographically distributed content servers and client-side buffers optimized for minimal pre-buffering to achieve near-real-time rendering.
graph TD
A[Global Content Orchestrator] --> B{Distribute Micro-Segment Server Lists};
B --> C[Millions of Client Devices (Sub-100ms Latency)];
C -- Track Sub-Second SL Stats --> D[Distributed Content Servers/CDNs];
D -- Serve Micro-Segments --> C;
subgraph Predictive AI/ML
E[Traffic Pattern Analysis]
F[Server Load Forecast]
G[Historical Performance]
end
D -- Feeds Data --> E, F, G;
C -- Proactive Server Selection (Pre-emptive Switching) --> D;
C -- Detects Micro-Degradation --> H{Imperceptible Micro-Switch};
H --> D;
Derivative 2.2: Deep Space Communication with Extreme Latency and Intermittency
Enabling Description:
This derivation applies the method to content delivery in deep space communications, where latency can be minutes or hours, and network connectivity is highly intermittent. The "list of content servers" would include orbital relays, deep space probes, or lunar/Martian base stations. Service level statistics would primarily focus on link availability windows, projected signal strength, historical error correction rates, and estimated round-trip light time (RTT). Content segments are large, designed to survive long periods of disconnection, and are accompanied by extensive metadata for integrity checks. Server selection prioritizes links with the longest predicted stable contact windows and highest data integrity guarantees, even if instantaneous throughput is low. Degradation detection triggers a switch to a pre-negotiated alternative relay or initiates a delayed transmission schedule for the next available window, with the "imperceptible" aspect reinterpreted as avoiding data corruption or complete mission failure rather than real-time user experience.
sequenceDiagram
participant CD as Client Device (Deep Space Probe)
participant NCS as Network Control Station (Earth)
participant OR1 as Orbital Relay 1
participant OR2 as Orbital Relay 2
NCS->CD: Download Server List (OR1, OR2, etc.)
CD->>OR1: Probe SL Stats (Link Avail, RTT)
CD->>OR2: Probe SL Stats (Link Avail, RTT)
CD->CD: Track SL Stats for OR1, OR2
CD->CD: Select OR1 (e.g., best predicted link)
CD->OR1: Request First Large Segment
OR1-->CD: Download First Large Segment (long latency)
CD->CD: Detect Degradation (e.g., link drop)
CD->CD: Select OR2 (best alternative)
CD->OR2: Request Second Large Segment (during OR2 window)
OR2-->CD: Download Second Large Segment (long latency)
CD->CD: Render Content (once complete)
Derivative 2.3: High-Frequency Financial Data Stream Failover
Enabling Description:
The patent's method is adapted for distributing high-frequency financial market data to trading platforms. The "digital content" comprises real-time tick data, order book updates, and news feeds. "Content servers" are exchange data feeds or co-located primary data vendors. Service level statistics are measured in nanoseconds for jitter, latency, and packet loss, crucial for algorithmic trading. The client device, a high-performance trading workstation, employs FPGA-accelerated network interfaces to track these statistics. Server selection prioritizes the feed with the absolute lowest and most consistent latency. Degradation in service (even a few microseconds of increased latency or a single dropped packet) triggers an immediate, hardware-level switch to a backup, geographically diverse, redundant data feed. The "imperceptible" replacement ensures no market data is missed, which could lead to significant financial loss.
stateDiagram-v2
state "Initialize: Download Feed List" as Init
state "Tracking Feeds & Selecting Primary" as TrackSelect
state "Receiving Primary Feed" as PrimaryActive
state "Degradation Detected" as Degraded
state "Switching to Backup Feed" as Switching
state "Receiving Backup Feed" as BackupActive
state "Monitoring Backup Feed" as MonitorBackup
[*] --> Init
Init --> TrackSelect: List received
TrackSelect --> PrimaryActive: Best primary selected
PrimaryActive --> Degraded: Primary SL degrades (nanoseconds)
Degraded --> Switching: Initiate immediate failover
Switching --> BackupActive: Backup feed selected & connected
BackupActive --> MonitorBackup: Continue monitoring all feeds
MonitorBackup --> PrimaryActive: Primary recovers/becomes better (revert if policy allows)
MonitorBackup --> Degraded: Backup degrades (initiate switch to another)
BackupActive --> Degraded: Backup degrades (fallback to another)
Axis 3: Cross-Domain Application
Derivative 3.1: Autonomous Vehicle Real-Time Map Data Delivery
Enabling Description:
The method is applied to autonomous vehicles (AVs) for downloading real-time high-definition map data, traffic information, and over-the-air (OTA) software updates. The "client device" is the AV's onboard computational platform. "Content servers" are roadside units, centralized cloud servers, or other AVs (peer-to-peer). The "list of content servers" includes available communication channels (5G, V2X, satellite) and their associated data sources. Service level statistics track network bandwidth, latency, and predictive availability based on vehicle location and known network coverage. The AV continuously selects the optimal server/channel for streaming map segments, critical for navigation. If a degradation is detected (e.g., entering a cellular dead zone), the system imperceptibly switches to a pre-cached map segment, a V2X peer, or a satellite link, ensuring uninterrupted navigation.
flowchart TD
A[Cloud Map Service] -- Distributes Initial Server List --> B(Autonomous Vehicle);
B -- Tracks SL Stats for --> C[Roadside Units];
B -- Tracks SL Stats for --> D[Central Cloud Servers];
B -- Tracks SL Stats for --> E[V2X Peers];
B --> F{Select Optimal Content Source};
F --> G[Download Map Segment 1];
G --> B;
B -- Detect Degradation (e.g., Signal Drop) --> H{Imperceptible Switch};
H --> I[Download Map Segment 2 from new source];
I --> B;
B -- Renders --> J[Real-time Navigation];
Derivative 3.2: Remote Patient Monitoring Data Stream Management
Enabling Description:
The method is utilized for managing the download of real-time biometric and medical sensor data from wearable devices or implanted sensors to a central healthcare platform or a local patient gateway. The "client device" could be a patient's smartphone or a dedicated home health hub. "Content servers" are secure cloud endpoints, local hospital servers, or authorized medical device gateways. The "list of content servers" includes various communication protocols (Bluetooth Low Energy, Wi-Fi, cellular) and their associated secure endpoints. Service level statistics track data integrity, encryption overhead, transmission success rate, and latency, with an emphasis on ensuring critical alerts are delivered. In case of degradation (e.g., loss of Wi-Fi connectivity at home), the system imperceptibly switches to a cellular uplink or buffers data locally for later secure transmission, ensuring continuous patient data collection without interruption to critical monitoring or alert generation.
sequenceDiagram
participant WS as Wearable Sensor
participant PGH as Patient Gateway/Hub
participant HCS as Healthcare Cloud Server
participant HS as Hospital Server
WS-->>PGH: Stream Biometric Data Segments
PGH->PGH: Download Server List (HCS, HS)
PGH->>HCS: Track SL Stats (Data Integrity, Latency)
PGH->>HS: Track SL Stats (Data Integrity, Latency)
PGH->PGH: Select HCS (Primary)
PGH->HCS: Upload Data Segment 1
activate HCS
HCS-->>PGH: ACK Data Segment 1
deactivate HCS
PGH->PGH: Detect Degradation (HCS upload issues)
PGH->PGH: Imperceptibly Select HS (Backup)
PGH->HS: Upload Data Segment 2
activate HS
HS-->>PGH: ACK Data Segment 2
deactivate HS
Derivative 3.3: Space-Based Satellite Constellation Control Link Management
Enabling Description:
The method is adapted for managing control links to individual satellites within a large constellation. The "client device" is a ground station or another satellite (for inter-satellite links). The "digital content" is command sequences, software updates, or telemetry requests. "Content servers" are other ground stations, orbital relay satellites, or direct-to-satellite uplink facilities. The "list of content servers" includes available ground stations, their current operational status, weather conditions affecting RF links, and scheduled pass times. Service level statistics track link quality, signal-to-noise ratio (SNR), expected contact duration, and command acknowledgment rates. If a primary ground station experiences degradation (e.g., severe weather causing signal attenuation), the system imperceptibly switches to an alternative ground station or an inter-satellite link to ensure continuous command and control of the satellite, preventing mission-critical delays or failures.
graph LR
GS1[Ground Station 1]
GS2[Ground Station 2]
ORS[Orbital Relay Satellite]
SC[Satellite Constellation (Client Device)]
GS1 --Provides Server List--> SC
GS2 --Provides Server List--> SC
ORS --Provides Server List--> SC
SC --Tracks SL Stats (SNR, Contact Time)--> GS1
SC --Tracks SL Stats (SNR, Contact Time)--> GS2
SC --Tracks SL Stats (SNR, Contact Time)--> ORS
SC --Selects GS1 (Primary)--> GS1
GS1 --Transmits Command Segment 1--> SC
SC --Detects Degradation (GS1)--> SC
SC --Imperceptibly Switches to ORS--> ORS
ORS --Transmits Command Segment 2--> SC
Axis 4: Integration with Emerging Tech
Derivative 4.1: AI-Driven Predictive Server Optimization
Enabling Description:
The service level statistics tracking and server selection mechanisms are enhanced by an Artificial Intelligence (AI) / Machine Learning (ML) model. This model, trained on historical network performance data, server load patterns, geographical traffic flows, and anticipated degradation events (e.g., peak hours, known network congestion points), proactively predicts potential service degradation from content servers. Instead of reacting to observed degradation, the AI model, deployed on the client device or a proximate edge compute node, analyzes real-time statistics and predicts future performance for all servers in the list. It then advises the server selection logic to switch to an optimal server before degradation occurs, ensuring a truly pre-emptive and imperceptible transition. The AI model continuously learns and refines its predictions based on ongoing performance feedback.
sequenceDiagram
participant Client as Client Device
participant AI as AI/ML Prediction Engine
participant SL as Server List
participant CS1 as Content Server 1
participant CS2 as Content Server 2
Client->SL: Download Server List
Client->Client: Start Tracking Real-time SL Stats
Client->AI: Feed Real-time & Historical SL Stats
AI->AI: Train & Predict Server Performance
AI->Client: Output Predicted Optimal Server
Client->CS1: Select & Download Segment 1 (Primary based on AI)
Client->AI: Feedback Actual Performance of CS1
AI->AI: Update Predictions
Client->Client: Detect Impending Degradation (AI-predicted)
Client->AI: Re-request Optimal Server
AI->Client: Output Predicted Optimal Server (CS2)
Client->CS2: Imperceptibly Switch & Download Segment 2 (New Primary)
Derivative 4.2: IoT Sensor-Augmented Network Infrastructure for SLT
Enabling Description:
The "service level statistics" are collected not just from client-side observations, but are augmented by a dense network of Internet of Things (IoT) sensors embedded within the network infrastructure itself. These IoT sensors, located at network hops, switches, routers, and content server racks, continuously monitor environmental conditions (temperature, power fluctuations), network traffic load, physical link integrity, and application-layer performance. This real-time, distributed sensor data is aggregated into a centralized network monitoring platform, which then pushes refined, granular service level statistics and predictive alerts to client devices. The client's local tracking combines its observed metrics with this external, infrastructure-derived IoT data for a more comprehensive and accurate assessment of server health and network path quality, enabling highly informed server selection.
graph TD
A[IoT Sensors (Network Infrastructure)] --> B[IoT Data Aggregation Platform];
B -- Push Refined SL Stats & Alerts --> C[Network Accessible Server];
C -- Download Server List & IoT-Augmented SL Stats --> D[Client Device];
D -- Local Tracking (Client-Observed) --> E[Combined SL Stats];
D -- Uses E for Selection --> F[Content Servers];
F -- Serve Digital Content Segments --> D;
D -- Degradation Detected --> G{Imperceptible Switch};
G --> F;
Derivative 4.3: Blockchain for Verifiable Content Provenance and Server Reputation
Enabling Description:
A blockchain network is integrated to provide immutable verification of content segments and transparent, trustless server reputation for service level statistics. Each content segment delivered is cryptographically hashed, and its hash, along with the serving server's identity and a timestamp, is recorded on a distributed ledger. When a client downloads a segment, it verifies the segment's integrity against the blockchain record. Service level statistics, such as confirmed delivery, integrity checks, and perceived performance, are also anonymously attested by clients and recorded on the blockchain, building a decentralized, verifiable reputation score for each content server. Server selection then considers not just real-time performance but also a server's blockchain-verified historical reputation, making the selection more robust against malicious or compromised servers. The imperceptible switch includes verifying the new server's identity and the next segment's hash on the blockchain.
sequenceDiagram
participant Client as Client Device
participant CS1 as Content Server 1
participant CS2 as Content Server 2
participant BC as Blockchain Network
participant NAS as Network Accessible Server
NAS->Client: Download Server List (CS1, CS2)
Client->Client: Track Local SL Stats
Client->CS1: Request Segment 1
CS1->Client: Send Segment 1
Client->BC: Verify Segment 1 Hash & Report Performance/Integrity
activate BC
BC->BC: Update CS1 Reputation Score
deactivate BC
Client->Client: Detect Degradation (CS1)
Client->BC: Query CS2 Reputation Score
activate BC
BC->Client: Return CS2 Reputation
deactivate BC
Client->CS2: Select & Request Segment 2 (based on local SL + BC Reputation)
CS2->Client: Send Segment 2
Client->BC: Verify Segment 2 Hash & Report Performance/Integrity
Axis 5: The "Inverse" or Failure Mode
Derivative 5.1: Graceful Degradation to Offline/Low-Fidelity Mode
Enabling Description:
In the event of severe, unrecoverable degradation from all available content servers, or if the client device detects critical resource constraints (e.g., low battery, near-zero available network bandwidth), the system initiates a "graceful degradation" mode. Instead of attempting a frantic search for a new server, the content rendering seamlessly switches to a pre-cached, lower-fidelity version of the digital content (e.g., a mono audio track at a reduced bitrate, or a simplified visual representation). If no cached content is available, the system falls back to playing locally stored, non-network-dependent placeholder content (e.g., a "network unavailable" audio message, or a static image). The imperceptible replacement means the user experiences a reduction in quality or a transition to offline content rather than a complete halt in playback, maintaining some level of continuous experience. This mode also prioritizes minimal power consumption and network usage.
stateDiagram-v2
state "Online Rendering (High Fidelity)" as Online
state "Degradation Detected" as Degraded
state "Offline/Low-Fidelity Mode" as OfflineLowFi
state "Network Unavailable Placeholder" as Placeholder
Online --> Degraded: All servers degraded/Critical Resource Low
Degraded --> OfflineLowFi: Switch to cached low-fidelity content
OfflineLowFi --> Placeholder: No cached content available
Placeholder --> Online: Network/Resources Restored
OfflineLowFi --> Online: Network/Resources Restored
Online --> [*]: User stops/completes
OfflineLowFi --> [*]: User stops/completes
Placeholder --> [*]: User stops/completes
Derivative 5.2: Secure Forensic Logging and Content Blackout
Enabling Description:
In a scenario where degradation is identified as a potential security breach, data tampering, or system compromise (e.g., detected by unusual packet patterns, unauthorized server responses, or cryptographic validation failures), the system enters a "secure forensic logging" mode. Content download and rendering are immediately blacked out or halted. Instead of switching to an alternative content server for rendering, the client device prioritizes logging all network communication attempts, server responses, and internal system states to a secure, immutable local log (e.g., a hardware-encrypted partition or a write-once memory module). This logging is performed with minimal system footprint to prevent further compromise. No new content segments are downloaded or rendered until a security review is complete or the threat is neutralized. The "imperceptible" aspect is replaced by an immediate, deliberate, and secure interruption to prevent data leakage or propagation of malicious content, while ensuring evidence is preserved.
sequenceDiagram
participant Client as Client Device
participant CS1 as Content Server 1
participant CS2 as Content Server 2
participant SLM as Secure Log Module
Client->CS1: Download Segment 1
CS1->Client: Send Segment 1
Client->Client: Render Segment 1
Client->Client: Detect Critical Anomaly (Security Threat)
Client->>CS1: STOP Request (Optional)
Client->SLM: Initiate Secure Forensic Logging
activate SLM
Client->Client: Content Blackout / Halt Rendering
Client->SLM: Log all network activity, internal states
deactivate SLM
Client->Client: Await Security Clearance / Manual Intervention
Derivative 5.3: User-Controlled Perceptible Interruption for Feedback
Enabling Description:
This derivation introduces a "deliberate interruption" mode, where degradation is not always imperceptible. Instead, if service degradation persists across multiple server switches or falls below a user-defined acceptable threshold, the system intentionally pauses content rendering and presents the user with a prompt for feedback or intervention. For example, a pop-up dialog could ask: "Service degraded, current quality is [X]. Would you like to switch to a lower quality stream, wait for better service, or report the issue?" This allows the user to make an informed decision, especially in scenarios where uninterrupted, high-fidelity playback is less critical than user agency or reporting problems. The "imperceptible" aspect is bypassed to allow for user-centric control, with the pause itself serving as a clear signal that the system requires input due to persistent performance issues.
graph TD
A[Client Device] --> B{Download Server List};
B --> C[Content Servers];
C -- Downloads Segments --> A;
A -- Track SL Stats --> D[Performance Monitor];
D -- Detects Degradation --> E{Persistent Degradation?};
E -- Yes --> F[Present User Feedback/Intervention Prompt];
F --> G{User Action: Select Option};
G -- Option 1: Lower Quality --> H[Switch to Lower Bitrate Stream];
G -- Option 2: Wait --> I[Pause Playback & Monitor];
G -- Option 3: Report --> J[Send Diagnostic Report];
E -- No --> A[Continue Normal Rendering];
H --> A;
I --> A;
J --> A;
Combination Prior Art Scenarios
This patent's core concept of client-side service level tracking and imperceptible server switching can be combined with existing open-source standards to demonstrate obviousness for future improvements.
1. HTTP Adaptive Streaming (DASH/HLS) with Client-Side Server Prioritization
Combination: US10735488B2's method for downloading server lists, tracking service level statistics, and imperceptibly switching between content servers is applied directly to an existing HTTP Adaptive Streaming (HAS) client, such as those implementing MPEG-DASH (ISO/IEC 23009-1) or HLS (Apple HTTP Live Streaming).
Description: An HAS client typically manages multiple bitrate representations from a single content source or CDN. This combination involves the HAS client augmenting its segment fetching logic to select not just the optimal bitrate from an Adaptation Set, but also the optimal content server (e.g., a specific CDN POP or origin server) from a dynamically managed list. The client would download a ServerList.xml (as described in US10735488B2) alongside the DASH Media Presentation Description (MPD) or HLS M3U8 manifest. The client-side player's buffer health and network conditions, in addition to the traditional HAS segment download metrics, would feed into the service level statistics tracking for each available content server. If a segment download from the currently selected server degrades (e.g., stalling, increased latency for the next segment), the HAS client would imperceptibly switch to another server from its ServerList.xml for subsequent segment requests, while simultaneously adapting the bitrate as per standard HAS logic. This would provide robust content delivery even with highly distributed and variable-performance content server infrastructure.
graph TD
A[Origin Server] --> B(Generate MPD/M3U8 + ServerList.xml);
B --> C[Client HAS Player];
C -- Downloads --> D[MPD/M3U8];
C -- Downloads --> E[ServerList.xml];
C -- Tracks SL Stats for --> F[CDN Server 1];
C -- Tracks SL Stats for --> G[CDN Server 2];
C -- Combines HAS Logic + SL Stats --> H{Select Bitrate & Server};
H --> I[Download Segment from F];
I --> C;
C -- Detects Degradation --> J{Imperceptible Switch to G (for next segment)};
J --> K[Download Segment from G];
K --> C;
C -- Renders --> L[Seamless Playback];
2. Kubernetes-Managed Content Delivery with Client-Side Failover
Combination: The patent's client-side server selection and failover mechanism is integrated with a backend content delivery system deployed on Kubernetes, where "content servers" are dynamically scaled Kubernetes pods.
Description: A content delivery service is deployed as a set of microservices within a Kubernetes cluster, served by multiple pods that can scale horizontally. The "network accessible server" that provides the list of content servers is a Kubernetes Ingress controller or a service mesh (e.g., Istio) that exposes the available content-serving pods and their network addresses. The client device, upon receiving this dynamic list of Kubernetes-managed content server endpoints, tracks service level statistics (latency, throughput, error rates) for each. Kubernetes' inherent load balancing might initially distribute traffic. However, US10735488B2's method adds a layer of client-side intelligence: if a specific Kubernetes pod (acting as a content server) exhibits degradation that Kubernetes' own service discovery or load balancing might not immediately detect or react to sufficiently quickly for a seamless user experience, the client-side logic performs an imperceptible switch to another healthy pod endpoint from its dynamically updated list. This provides faster, user-perceptible failover than purely server-side orchestration.
graph TD
subgraph Kubernetes Cluster (Content Servers)
Pod1[Content Server Pod 1]
Pod2[Content Server Pod 2]
PodN[Content Server Pod N]
Ingress[Kubernetes Ingress/Service Mesh]
end
Ingress -- Provides Dynamic Server List --> Client[Client Device];
Client -- Tracks SL Stats for --> Pod1;
Client -- Tracks SL Stats for --> Pod2;
Client -- Tracks SL Stats for --> PodN;
Client -- Selects Pod1 (Initial) --> Pod1;
Pod1 -- Downloads Segment 1 --> Client;
Client -- Detects Degradation (Pod1) --> Client;
Client -- Imperceptibly Switches to Pod2 --> Pod2;
Pod2 -- Downloads Segment 2 --> Client;
Client -- Renders --> Playback[Seamless Content Playback];
3. WebRTC-Based Peer-to-Peer Content Distribution with Hybrid Server Selection
Combination: The patent's server selection and failover mechanism is adapted for a hybrid WebRTC-based content distribution network (CDN) that blends peer-to-peer (P2P) connections with traditional HTTP servers.
Description: The "digital content" is distributed using a hybrid approach where clients can receive segments from traditional HTTP content servers or directly from other peer clients via WebRTC data channels. The "list of content servers" would include both traditional HTTP/CDN URLs and a list of available WebRTC peer IDs, along with their respective connection details (e.g., ICE candidates, signalling server information). The client device tracks service level statistics for both types of sources: for HTTP servers, standard network metrics; for WebRTC peers, metrics like peer latency, available bandwidth (as reported by WebRTC statistics API), and peer churn rate. The server selection algorithm prioritizes sources based on a combined score, potentially favoring P2P sources for cost efficiency or reduced load on origin servers, but seamlessly falling back to HTTP servers if P2P connections degrade or peers become unavailable. The imperceptible switch allows the client to transition between HTTP content servers and WebRTC peers (or between different peers) without interruption to content rendering.
graph TD
A[Origin Content Server] --> B{Downloads Initial Seed Content};
B --> C[WebRTC Peer 1 (Client Device)];
C -- Publishes Peer ID + SL Stats --> D[WebRTC Signalling Server];
C -- Downloads Server List (HTTP Servers + Peer IDs) --> C;
C -- Tracks SL Stats for --> E[HTTP Server 1];
C -- Tracks SL Stats for --> F[WebRTC Peer 2];
C -- Selects (e.g., HTTP Server 1) --> E;
E -- Downloads Segment 1 --> C;
C -- Detects Degradation (HTTP Server 1) --> G{Imperceptible Switch};
G -- Selects (e.g., WebRTC Peer 2) --> F;
F -- Downloads Segment 2 (via WebRTC) --> C;
C -- Renders --> H[Continuous Playback];
Generated 5/15/2026, 12:48:09 AM