Patent 10057322

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.

✓ Generated

The USPTO Patent Public Search website provides a tool to search for patents. To search for U.S. Patent 10057322, one would typically input the patent number directly into the search interface. The search result confirms the availability of such a search function on the USPTO website.

Defensive Disclosure for US Patent 10057322: Network Address Resolution

This document details derivative variations of the inventions described in US Patent 10057322, aiming to establish prior art that would render future incremental improvements in this domain obvious or non-novel. The focus is on the core concepts of dynamic, API-driven CDN node selection for embedded resources, as outlined in independent claims 1, 11, and 15.

Derivative Variations

1. Material & Component Substitution

Variation 1.1: Hardware-Accelerated API/Compute Engine for Low-Latency Resolution

Enabling Description:
This variation implements the API (26) and its associated compute engine (30, 608) on dedicated hardware, such as Field-Programmable Gate Arrays (FPGAs) or Application-Specific Integrated Circuits (ASICs). The logic for processing delivery parameters (client IP, popularity, geo-restrictions) and generating optimal CDN node addresses (VIPs, URLs) is hardcoded or programmed into the FPGA fabric. This allows for nanosecond-level decision-making latency, critical for highly dynamic, real-time content delivery scenarios where traditional software-based API calls introduce unacceptable overhead. The FPGA/ASIC module would interface directly with network ingress/egress points (e.g., within a CDN PoP router or an origin server's network interface card), intercepting HTTP requests, extracting relevant metadata, performing rapid lookup/computation based on pre-provisioned CDN topology and real-time network telemetry (e.g., via a high-speed data plane interface like P4), and rewriting embedded resource URLs before the content resource is forwarded to the client. This bypasses typical operating system and software stack overhead, optimizing for throughput and latency.

flowchart TD
    A[Client Device] --> B{HTTP Request for Content Resource};
    B --> C[Origin Server / CDN Ingress];
    C -- Content Resource (w/ Tagged Embedded Resource) --> D[Hardware-Accelerated API/Compute Engine (FPGA/ASIC)];
    D -- Extract Tagged Resource & Parameters (Client IP, etc.) --> E[FPGA/ASIC Logic];
    E -- Real-time CDN Telemetry & Topology --> F[High-Speed Data Plane];
    E -- Compute Optimal CDN Node Address --> D;
    D -- Return Modified Embedded Resource --> C;
    C --> G[Content Resource (w/ Modified Embedded Resource)];
    G --> A;
    A -- Direct Link (Modified Embedded Resource) --> H[Optimal CDN Node (FPGA/ASIC Enabled)];
    H -- Deliver Content --> A;

Variation 1.2: Serverless, Event-Driven API for Elastic Scalability

Enabling Description:
Instead of a monolithic compute engine, the API (26) and its resolution logic are implemented as a collection of serverless functions (e.g., AWS Lambda, Google Cloud Functions, Azure Functions). When the origin system (or CDN ingress) identifies a tagged embedded resource, it triggers an event (e.g., an HTTP POST to the serverless endpoint or a message to a queue). Each serverless function instance is responsible for a specific part of the resolution, such as IP-to-geo lookup, popularity score retrieval, or CDN node selection algorithm execution. Parameters (client IP, resource name, popularity hints) are passed as event payloads. The serverless platform automatically scales the execution based on demand, enabling highly elastic and cost-effective resolution for fluctuating loads. The modified embedded resource (direct link) is returned asynchronously or via a callback mechanism. This architecture leverages ephemeral compute resources, only paying for actual execution time, and abstracts away server management.

sequenceDiagram
    participant C as Client Device
    participant O as Origin System
    participant SF as Serverless API Endpoint (e.g., Lambda)
    participant DB as CDN Information Store (DynamoDB/Firestore)
    participant CDN as CDN Node

    C->>O: HTTP GET /content (includes tagged resource)
    O->>O: Identify Tagged Resource
    O->>SF: Invoke Serverless Function (resource, client_ip, params)
    SF->>DB: Query Geo-IP, Popularity, Policy Data
    DB-->>SF: Return Parameters
    SF->>SF: Execute Optimal Node Selection Logic
    SF-->>O: Return Modified Embedded Resource (direct link)
    O-->>C: Deliver Content Resource (with modified link)
    C->>CDN: HTTP GET /embedded_resource (direct link)
    CDN-->>C: Deliver Embedded Resource

Variation 1.3: Cryptographically Signed Tags for Enhanced Trust and Tamper Detection

Enabling Description:
The embedded resource tag (e.g., "$") and its associated parameters (resource identifier, initial popularity hints, geo-restrictions) are digitally signed by the origin system using asymmetric cryptography before being embedded in the content resource. When the origin system or CDN ingress receives the content resource and identifies the signed tag, it uses a public key to verify the signature. This ensures the integrity and authenticity of the embedded resource's parameters, preventing malicious modification of the routing logic or "tag spoofing" attacks. The API/compute engine would only process parameters from validly signed tags. Invalid signatures would trigger a fallback to a default resolution mechanism or alert a security monitoring system. The signature could be embedded as an attribute within the tag or as a separate, adjacent data block.

graph TD
    A[Origin System] -- Embed Tagged Resource + Parameters --> B(HTML Document);
    B -- Apply Digital Signature --> C[Signed Tagged Resource in HTML];
    C -- Deliver to Client --> D[Client Device];
    D -- Request Content --> E[Origin System / CDN Ingress];
    E -- Identify Signed Tag --> F{Verify Digital Signature};
    F -- Invalid Signature --> G[Security Alert / Fallback];
    F -- Valid Signature --> H[API/Compute Engine];
    H -- Use Verified Parameters --> I[Generate Modified Embedded Resource];
    I --> E;
    E --> D;
    D -- Direct Link --> J[CDN Node];
    J --> D;

2. Operational Parameter Expansion

Variation 2.1: Hyper-Localized Resolution within Campus/Enterprise Networks

Enabling Description:
The network address resolution mechanism is deployed within a large campus or enterprise network, where "clients" are internal devices and "CDN nodes" are localized cache servers, network-attached storage (NAS) appliances, or virtual machine hosts distributed across different departments or buildings. The "delivery parameters" would include not only client IP but also parameters like departmental affiliation, access control lists (ACLs), physical location (e.g., building/floor from Wi-Fi access point data), and internal network segment load. The API/compute engine would then resolve embedded resources (e.g., internal documents, software artifacts, large datasets for scientific computing) to the closest, least-congested internal node, potentially bypassing external CDN routing entirely for internal content. This optimizes bandwidth usage and access speed within a private network.

graph LR
    subgraph Enterprise Network
        C[Internal Client Device]
        GW[Gateway/Proxy (Intercepts Requests)]
        API[Internal API/Compute Engine]
        DB[Internal Resource/Policy DB]
        N1[Local Cache Node 1 (Bldg A)]
        N2[Local Cache Node 2 (Bldg B)]
        C -- Request for Internal Resource (tagged) --> GW
        GW -- Identify Tag --> API
        API -- Client IP, Dept ID, Location, ACLs --> DB
        DB -- Optimal Internal Node --> API
        API -- Modified Embedded Resource (Internal Link) --> GW
        GW -- Delivers Content --> C
        C -- Direct Link --> N1
        C -- Direct Link --> N2
        N1 -- Delivers Content --> C
        N2 -- Delivers Content --> C
    end

Variation 2.2: Real-time Predictive Popularity and Traffic Metrics

Enabling Description:
The API/compute engine (30, 608) continuously ingests real-time network traffic data, CDN cache hit rates, server load metrics, and application-level popularity signals from all CDN nodes and origin servers. This data feeds a machine learning (ML) model that predicts future demand and optimal node performance per resource, per geographic region, and per time slice. For instance, instead of static or manually-set popularity, the system dynamically adjusts popularity scores and anticipates traffic surges (e.g., based on news events, social media trends, or scheduled releases) to proactively select CDN nodes and even pre-position content. When an API call (220, 540) is made, the ML model provides a predicted optimal node based on immediate and forecasted conditions, enabling highly adaptive routing that accounts for micro-bursts and evolving demand patterns.

graph TD
    subgraph CDN Data Plane
        N1(CDN Node 1) --> TD[Telemetry Data Stream (Load, Cache Hit, Latency)];
        N2(CDN Node 2) --> TD;
        ...
    end

    TD --> ML[Machine Learning Model (Predictive Analytics)];
    ML -- Predicted Optimal Node/Popularity --> API[API/Compute Engine];

    subgraph Control Plane
        OS[Origin System] --> API;
        API -- Modified Embedded Resource --> OS;
        OS --> C[Client Device];
        C --> N_OPT[Optimal CDN Node (predicted by ML)];
        N_OPT --> C;
    end

Variation 2.3: Ultra-Low Latency Edge Computing for AR/VR Content

Enabling Description:
For applications requiring extremely low latency, such as Augmented Reality (AR) or Virtual Reality (VR) streaming (e.g., 3D models, point clouds, real-time interactive environments), the CDN nodes are pushed to ultra-edge locations (e.g., telco central offices, roadside units, enterprise micro-datacenters). The API/compute engine's primary delivery parameter becomes round-trip time (RTT) and jitter to the client, measured dynamically and frequently from these micro-edge nodes. The "embedded resource" might be a segment of a 3D environment or a texture map that needs to be streamed with minimal delay. The modified embedded resource would contain a direct link to the specific edge server capable of delivering content within a guaranteed latency budget, potentially even to a specific GPU-accelerated server within a node cluster.

graph TD
    C[AR/VR Client Device] --> REQ{Request for Immersive Content (tagged)};
    REQ --> OS[Origin System/CDN Ingress];
    OS -- Tagged Resource, Client Latency Profile --> API[API/Compute Engine];
    API -- Real-time RTT/Jitter from Micro-Edge Nodes --> MECS[Multi-access Edge Compute System];
    MECS -- Geo-proximity, Compute Load, Latency Profiles --> API;
    API -- Optimal Micro-Edge Node --> OS;
    OS -- Modified Embedded Resource (Ultra-Low Latency Link) --> C;
    C -- Direct Link --> MEN[Optimal Micro-Edge Node];
    MEN -- Stream Immersive Content (<10ms latency) --> C;

3. Cross-Domain Application

Variation 3.1: Industrial IoT/SCADA Systems - Dynamic Firmware/Configuration Updates

Enabling Description:
In an Industrial IoT (IIoT) or SCADA environment, critical firmware updates or configuration files for a fleet of industrial sensors, actuators, or programmable logic controllers (PLCs) are "embedded resources" within a larger operational directive or control program (the "content resource"). These embedded resources require delivery from a highly reliable and potentially geographically specific repository. A "tag" in the operational directive would indicate that a specific firmware version needs to be retrieved. The origin system (e.g., a central control server or manufacturing execution system) would use an API to query an "Industrial Content Delivery Network" (I-CDN), passing parameters such as device ID, geographic location of the device, criticality level of the update, and network conditions of the IIoT gateway. The I-CDN's API would return a direct link (e.g., a secure MQTT endpoint or a dedicated file transfer protocol address) to the closest, most reliable I-CDN node (e.g., an edge gateway or private cloud instance) that hosts the validated firmware or configuration, ensuring timely and secure delivery to distributed industrial assets.

graph TD
    subgraph IIoT System
        CS[Central Control System] --> OD[Operational Directive (w/ tagged firmware)];
        OD --> API[I-CDN API/Compute Engine];
        API -- Device ID, Geo, Criticality, Network Status --> ICDS[I-CDN Data Store];
        ICDS -- Optimal I-CDN Node --> API;
        API -- Modified Firmware Link (secure endpoint) --> CS;
        CS -- Deliver Operational Directive (w/ modified link) --> IIoTD[IIoT Device];
        IIoTD -- Request Firmware --> ICN[Optimal I-CDN Node];
        ICN -- Deliver Firmware --> IIoTD;
    end

Variation 3.2: Autonomous Vehicle Map Data - On-Demand Localized Map Segment Delivery

Enabling Description:
For autonomous vehicles (AVs), the "content resource" could be a local navigation plan or route, and "embedded resources" are high-definition map segments, real-time traffic overlays, or dynamic obstacle data required for immediate perception and path planning. These embedded resources must be delivered with extreme precision and freshness based on the vehicle's current location, direction of travel, and predictive trajectory. The vehicle's onboard computer (acting as the origin system) would identify tagged map resource requests within its planning module. It would then call an "AV Map Data CDN" API, providing its precise GPS coordinates, velocity, anticipated route, and network connectivity status. The API/compute engine would use these parameters to identify the most relevant, up-to-date, and geographically proximate AV-CDN node (e.g., a roadside edge server or regional data center) to serve the required map data segments directly, minimizing download latency and ensuring situational awareness.

sequenceDiagram
    participant AV as Autonomous Vehicle
    participant OBD as Onboard Computer (Origin)
    participant API as AV-CDN API/Compute Engine
    participant MDS as Map Data Store (AV-CDN)
    participant CDN as AV-CDN Node

    AV->>OBD: Local Navigation Plan (w/ tagged map data)
    OBD->>OBD: Identify Tagged Map Data
    OBD->>API: Call API (GPS, Velocity, Route, Network Status)
    API->>MDS: Query Relevant Map Data, Traffic Overlays
    MDS-->>API: Return Optimal CDN Node
    API-->>OBD: Return Modified Map Data Link (direct to CDN)
    OBD-->>AV: Update Navigation Plan (w/ direct link)
    AV->>CDN: Request Map Segment (direct link)
    CDN-->>AV: Deliver High-Definition Map Data

Variation 3.3: Digital Twins/Simulations - Dynamic Asset Streaming for Large-Scale Simulations

Enabling Description:
In the realm of digital twins or complex simulations (e.g., urban planning, fluid dynamics, large-scale engineering models), the "content resource" is the core simulation environment, and "embedded resources" are high-fidelity 3D models, texture libraries, material properties, or computational fluid dynamics (CFD) mesh data required for specific localized areas or conditions within the simulation. As the simulation progresses or a user navigates a digital twin, the client (simulation rendering engine or analysis tool) identifies tagged asset requests. An API call is made to a "Simulation Asset CDN," providing parameters such as the simulation's current state, user's viewpoint coordinates, required level of detail (LoD), and available client compute/rendering resources. The API/compute engine would then return a direct link to the optimal Simulation-CDN node (e.g., a GPU-accelerated server cluster or high-performance storage array) that can stream the required assets with minimal latency, adapting to the dynamic demands of the simulation.

graph TD
    SE[Simulation Engine/Client] --> TMR{Tagged Model/Resource Request};
    TMR --> CS[Core Simulation (Origin)];
    CS -- Simulation State, Viewpoint, LoD, Client Resources --> API[Simulation-CDN API/Compute Engine];
    API -- Query Asset Repository, Node Load, Geo-proximity --> AR[Asset Repository & CDN Topology];
    AR -- Optimal Node --> API;
    API -- Modified Asset Link (direct to CDN Node) --> CS;
    CS -- Deliver Simulation Frame (w/ modified link) --> SE;
    SE -- Direct Link --> SN[Optimal Simulation-CDN Node];
    SN -- Stream High-Fidelity Assets --> SE;

4. Integration with Emerging Tech

Variation 4.1: AI-Driven Optimization for Proactive CDN Node Selection

Enabling Description:
The API/compute engine (30, 608) is augmented with an Artificial Intelligence (AI) module, specifically a deep reinforcement learning (DRL) agent. This DRL agent observes historical delivery parameters (client IP patterns, resource popularity, network latency, CDN node load, geopolitical restrictions, content policy violations) and the resulting client experience (measured latency, throughput, error rates). It learns to predict the optimal CDN node for an embedded resource by continually refining a policy that maps input parameters to CDN node choices. When an API call (220, 540) is received, the AI module provides the recommendation for the modified embedded resource's target, not just based on current conditions but proactively anticipating network changes or localized demand spikes. The DRL agent's training would occur offline, but its inference model would be integrated directly into the real-time API decision-making flow.

graph TD
    subgraph Data Ingestion & Learning
        C(Client Device) -- Performance Metrics (Latency, Throughput) --> TM[Telemetry Module];
        OS(Origin Server) -- Request Parameters (Client IP, Resource, Pop) --> TM;
        CDN_N(CDN Nodes) -- Load, Cache State --> TM;
        TM -- Historical Data --> DRL[Deep Reinforcement Learning Agent];
    end

    subgraph Real-time Inference
        OS_REQ(Origin System Request) -- Tagged Resource, Current Params --> API_AI[API/AI Compute Engine];
        API_AI -- Query DRL Inference Model --> DRL;
        DRL -- Optimal Node Prediction --> API_AI;
        API_AI -- Modified Embedded Resource --> OS_REQ;
        OS_REQ --> C;
        C --> OPT_CDN[Optimal CDN Node];
        OPT_CDN --> C;
    end

Variation 4.2: IoT Sensor Integration for Real-time Client Network Telemetry

Enabling Description:
The "client device" (10, 40) is an IoT device (e.g., smart appliance, vehicle telematics unit, remote sensor hub) equipped with various network environment sensors. These sensors collect real-time data such as local Wi-Fi signal strength, cellular network quality (RSRP, RSRQ), available bandwidth, and local processing load. This client-side telemetry is packaged and included as additional "delivery parameters" in the HTTP request to the origin system (210) or directly to the CDN (530). The API/compute engine (30, 608) then uses this granular, real-time client-side network health information, alongside traditional parameters, to make a highly informed decision about the optimal CDN node. This allows for dynamic routing that adapts to the specific, immediate network conditions experienced by individual IoT devices, rather than relying solely on server-side network probes or static geo-IP data.

sequenceDiagram
    participant IOT as IoT Client Device
    participant S as IoT Sensors (Wi-Fi, Cellular, Bandwidth)
    participant O as Origin System
    participant API as API/Compute Engine
    participant CDN as CDN Node

    IOT->>S: Collect Real-time Telemetry
    S-->>IOT: Telemetry Data
    IOT->>O: HTTP GET /content (tagged resource, telemetry params)
    O->>API: Call API (resource, client_ip, telemetry params, etc.)
    API->>API: Process all delivery parameters
    API-->>O: Return Modified Embedded Resource (direct link)
    O-->>IOT: Deliver Content Resource (with modified link)
    IOT->>CDN: HTTP GET /embedded_resource (direct link)
    CDN-->>IOT: Deliver Embedded Resource

Variation 4.3: Blockchain for Verifiable Content Provenance and Access Control

Enabling Description:
To enhance the trust and verifiability of content delivery, particularly for sensitive or rights-managed embedded resources, a blockchain (e.g., a permissioned ledger) is integrated. When an embedded resource is initially tagged at the origin, a hash of the resource, its associated metadata (popularity, geo-restrictions, policy), and its ownership rights are recorded on the blockchain. When the API/compute engine (30, 608) receives a request and processes delivery parameters, it also queries the blockchain for the immutable content provenance and access rules. The generation of the modified embedded resource (direct link) is contingent on verifying client eligibility (e.g., geographic rights, subscription status, digital rights management tokens) against the blockchain-recorded policies. Furthermore, successful content delivery by the CDN node could trigger a smart contract on the blockchain to record access, update popularity metrics on-chain, or track content consumption for royalty distribution.

graph TD
    OS[Origin System] --> HASH{Hash Resource & Metadata};
    HASH --> BC[Blockchain (Record Provenance/Rights)];
    BC -- Immutable Record --> API[API/Compute Engine];
    OS -- Tagged Resource Request, Client Params --> API;
    API -- Query Blockchain --> BC;
    BC -- Access Rules, Provenance --> API;
    API -- Verify Client Eligibility --> DECISION{Client Eligible?};
    DECISION -- No --> DENY[Deny Access / Fallback];
    DECISION -- Yes --> GEN[Generate Modified Embedded Resource];
    GEN --> OS;
    OS --> C[Client Device];
    C --> CDN[CDN Node];
    CDN --> C;
    CDN -- On Successful Delivery --> SC[Smart Contract (Record Access/Update Pop)];
    SC --> BC;

5. The "Inverse" or Failure Mode

Variation 5.1: Graceful Degradation with Static Fallback to Origin or Generic CDN

Enabling Description:
In the event that the API/compute engine (30, 608) responsible for dynamic resolution becomes unavailable or experiences high error rates, the system gracefully degrades its functionality. The tagged embedded resource in the content resource would include a fallback mechanism, such as a static, pre-defined URL pointing directly to the origin server (18) or a generic, non-optimized CDN domain. The origin system (or CDN ingress) would detect the API failure (e.g., via timeout, error codes, or health checks) and, instead of calling the API, would replace the tagged resource with this static fallback URL. This ensures that content remains accessible, albeit without the benefits of optimal CDN node selection, maintaining service continuity even under API operational disruptions. The fallback URL could be encoded directly into the tag itself or be retrieved from a local, highly-available configuration store.

graph TD
    C[Client Device] --> REQ{HTTP Request for Content (w/ Tag)};
    REQ --> OS[Origin System/CDN Ingress];
    OS -- API Health Check --> API_H{API Healthy?};
    API_H -- Yes --> API[API/Compute Engine];
    API -- Modified Embedded Resource --> OS;
    API_H -- No --> FB[Fallback Mechanism (Local Config/Static URL)];
    FB -- Static Fallback URL --> OS;
    OS -- Content with Embedded Resource (Dynamic or Fallback) --> C;
    C -- Request Embedded Resource --> TARGET_NODE[Optimal CDN Node / Origin Server / Generic CDN];
    TARGET_NODE --> C;

Variation 5.2: Low-Power/Limited-Functionality Mode for Resource-Constrained Clients/Networks

Enabling Description:
For client devices (10, 40) operating in low-power states, on metered or highly congested networks, or with limited processing capabilities (e.g., IoT edge devices, basic feature phones), the content delivery method would operate in a "limited-functionality mode." The origin system or CDN ingress would detect the client's resource constraints (e.g., via User-Agent string, network type detection, explicit client-provided capability flags). In this mode, the API call (220, 540) to the compute engine (30, 608) would use a reduced set of delivery parameters (e.g., only client geo-region, ignoring real-time popularity or complex policy checks). The API would then return a simpler, potentially less optimized but universally accessible embedded resource link (e.g., a standard HTTP URL instead of a VIP, or a link to a lower-bitrate version of the content), minimizing API overhead and ensuring content delivery, even if sub-optimally.

graph TD
    C[Resource-Constrained Client] --> REQ{HTTP Request (w/ Client Constraints)};
    REQ --> OS[Origin System/CDN Ingress];
    OS -- Detect Client Constraints --> CM[Constraint Manager];
    CM -- Limited-Functionality Mode --> API[API/Compute Engine];
    API -- Reduced Parameters --> API_L[Limited API Logic];
    API_L -- Simpler Node Selection --> API;
    API -- Modified Embedded Resource (e.g., Lower Bitrate, Standard URL) --> OS;
    OS -- Content with Limited-Functionality Link --> C;
    C -- Request Embedded Resource --> RES_CDN[Resource-Optimized CDN Node];
    RES_CDN --> C;

Variation 5.3: Disaster Recovery Routing with Pre-configured Geo-Redundant Links

Enabling Description:
To handle large-scale regional outages or CDN failures, a disaster recovery (DR) mode is implemented. The API/compute engine (30, 608) maintains a continuously updated map of CDN node health and regional network status. If a major outage is detected in a primary CDN region, the API automatically shifts to a DR routing policy. The modified embedded resource would then be generated with a direct link to a pre-configured, geographically redundant CDN node (e.g., across continents or in a different major internet backbone region) that has mirrored content. This DR link might bypass some fine-grained optimizations but prioritizes availability. The origin system might also embed multiple pre-configured DR links in the initial content resource, with the API simply selecting which one to "unhide" or prioritize based on the detected disaster.

graph TD
    CDN_MON[CDN Monitoring System] --> OUTAGE_DET{Outage Detected?};
    OUTAGE_DET -- Yes (e.g., Region A Down) --> API[API/Compute Engine];
    API -- Shift to DR Policy --> DR_POLICY[Disaster Recovery Policy];
    DR_POLICY -- Select Geo-Redundant Node --> GRC[Geo-Redundant CDN Node (e.g., Region B)];
    API -- Modified Embedded Resource (Direct Link to GRC) --> OS[Origin System];
    OS -- Content to Client --> C[Client Device];
    C -- Request Embedded Resource --> GRC;
    GRC -- Deliver Content --> C;
    OUTAGE_DET -- No --> NORMAL_API[Normal API Operation];
    NORMAL_API --> API;

Combination Prior Art Scenarios

Here are at least 3 "Combination Prior Art" scenarios where US Patent 10057322 is combined with existing open-source standards, demonstrating how the patent's teachings, when combined with these widely available technologies, could lead to obvious improvements.

1. Combination with DNS over HTTPS (DoH) / DNS over TLS (DoT)

Scenario: The network address resolution method of US10057322, which generates a direct link to a CDN node, is combined with modern DNS privacy standards like DoH (RFC 8484) or DoT (RFC 7858).

Enabling Description:
The core invention allows the origin system or CDN API to provide a "direct link" (e.g., IP address or specific hostname) to a CDN node, potentially bypassing traditional DNS resolution for that embedded resource. When this direct link is a hostname, the client typically resolves it via standard DNS. However, if the client's resolver (14) or the CDN's name servers (34) are configured to use DoH/DoT, the DNS queries for the modified embedded resource's hostname would be encrypted and authenticated over HTTPS/TLS. This combination enhances the privacy and security of the subsequent DNS lookup for the CDN-provided hostname, preventing eavesdropping and tampering of the DNS resolution chain for the optimally selected CDN node, without altering the CDN's intelligent routing logic. The API itself could be invoked over DoH/DoT for privacy as well.

sequenceDiagram
    participant C as Client Device
    participant CR as Client Resolver (DoH/DoT Capable)
    participant OS as Origin System
    participant API as API/Compute Engine
    participant CDN_NS as CDN Name Server (DoH/DoT Capable)
    participant CDN as CDN Node

    C->>OS: HTTP GET /content (w/ tagged resource)
    OS->>API: Call API (client_ip, resource_params)
    API-->>OS: Return Modified Embedded Resource (hostname)
    OS-->>C: Deliver Content Resource (w/ modified hostname)
    C->>CR: DNS Query for CDN Hostname (over HTTPS/TLS)
    CR->>CDN_NS: Encrypted DNS Query (DoH/DoT)
    CDN_NS-->>CR: Encrypted IP Address Response (DoH/DoT)
    CR-->>C: IP Address
    C->>CDN: HTTP GET /embedded_resource (to IP)
    CDN-->>C: Deliver Embedded Resource

2. Combination with HTTP/3 (QUIC) for Enhanced Transport Layer

Scenario: The content delivery method of US10057322 is combined with HTTP/3, leveraging the underlying QUIC transport protocol (RFC 9000).

Enabling Description:
The patent describes HTTP connections for requesting content (210, 530) and the delivery of content. By specifying the modified embedded resource link to a CDN node that supports HTTP/3 over QUIC, the client device (10, 40) can establish a connection with the optimal CDN node using this more efficient and resilient transport layer. This means that after the API/compute engine has determined the best CDN node and provided a direct link (e.g., an absolute URL or IP address), the actual fetch of the embedded resource will benefit from QUIC's features: reduced connection establishment latency (0-RTT/1-RTT), improved congestion control, multiplexing without head-of-line blocking, and connection migration. This significantly enhances the end-user experience for embedded content delivery without altering the intelligent routing decision logic of the patent.

sequenceDiagram
    participant C as Client Device
    participant OS as Origin System
    participant API as API/Compute Engine
    participant CDN as CDN Node (HTTP/3 over QUIC Capable)

    C->>OS: HTTP GET /content (w/ tagged resource)
    OS->>API: Call API (client_ip, resource_params)
    API-->>OS: Return Modified Embedded Resource (URL to HTTP/3 CDN)
    OS-->>C: Deliver Content Resource (w/ modified URL)
    C->>CDN: QUIC Connection Establishment (0-RTT/1-RTT)
    activate CDN
    C->>CDN: HTTP/3 GET /embedded_resource
    CDN-->>C: Deliver Embedded Resource (over QUIC Stream)
    deactivate CDN

3. Combination with WebAssembly (Wasm) for Client-Side Tag Processing

Scenario: The patent's concept of identifying a tag and processing parameters for embedded resources is shifted, in part, to the client-side using WebAssembly (Wasm) modules.

Enabling Description:
Instead of the origin system (18) or CDN node (54) solely performing the identification of the tag and initiating the API call (220, 540), a lightweight WebAssembly module is embedded within the primary HTML document (20, 56) delivered to the client device (10, 40). This Wasm module executes within the client's browser (12, 42) upon parsing the HTML. The Wasm module contains logic to:

  1. Scan the DOM for specific embedded resource tags (e.g., custom HTML attributes or special URL formats).
  2. Extract local client-side parameters (e.g., browser-reported location, local network speed from JavaScript APIs, device performance metrics).
  3. Construct an API call (220) to the CDN's API (26) by combining the resource identifier from the tag with the client-side parameters.
  4. Receive the modified embedded resource (direct link) from the API.
  5. Dynamically rewrite the embedded resource's URL in the client's DOM or initiate the direct request to the CDN node (32).

This offloads some processing from the origin/CDN ingress, potentially enabling richer, more real-time client context to be immediately leveraged by the CDN's API, while maintaining the core API-driven resolution approach.

sequenceDiagram
    participant OS as Origin System
    participant C as Client Device (Browser with Wasm Runtime)
    participant Wasm as WebAssembly Module
    participant API as CDN API/Compute Engine
    participant CDN as CDN Node

    OS->>C: Deliver HTML Document (with Wasm and tagged resource)
    C->>Wasm: Load & Execute Wasm Module
    Wasm->>C: Scan DOM for Tagged Resources
    Wasm->>C: Gather Client-side Parameters (Location, Network Speed)
    Wasm->>API: API Call (Resource ID, Client-side Params)
    API-->>Wasm: Return Modified Embedded Resource (Direct Link)
    Wasm->>C: Dynamically Rewrite DOM (Embedded Resource URL)
    C->>CDN: HTTP GET /embedded_resource (Direct Link)
    CDN-->>C: Deliver Embedded Resource

Generated 5/15/2026, 6:47:14 AM