US 11838385

I'll search for information about US patent 11838385 from the USPTO and any CAFC 2026 docket activity.

The first search returned a different patent (12,208,385 — microfluidic devices, Draper Lab), not our number, so I'll disregard it. The CAFC result (NetList/Micron, 24-1312) is unrelated. Let me run more targeted searches.

I have solid bibliographic data. Now I need the actual claims text (the full patent text provided earlier was truncated before the claims section). Let me search for the independent claims.

I've reached the search step limit, so I'll answer based on the information gathered. Here's my analysis.

Verification notes

USPTO database: I confirmed the bibliographic record for patent 11838385 via Google Patents (which mirrors USPTO data) and secondary databases (Golden, PatentLeaderboard, PatentGuru). Note: one search surfaced patent 12,208,385 (Charles Draper Laboratory, "Systems and methods for fabricating microfluidic devices") — that is a different number and I've disregarded it per your instruction not to auto-correct or return similar numbers.

CAFC 2026 dockets: A targeted search of cafc.uscourts.gov for "11838385" returned no results. The only CAFC-related hit in my searches (NetList v. Micron, Appeal No. 24-1312, Feb. 2026) is a memory-module case and is unrelated to this patent. I found no evidence of a CAFC 2026 docket for 11838385. However, note the patent family has an active litigation flag (per Google Patents / Darts-ip family ID 48611345), and assignee Sandpiper CDN, LLC is litigating related CDN patents (e.g., Sandpiper CDN, LLC v. Google LLC, C.D. Cal. 2:24-cv-03951; Sandpiper CDN, LLC v. [Microsoft Corp.](/litigations/by-plaintiff/Microsoft%20Corp.), E.D. Tex. 2:25-cv-00664). I did not find 11838385 itself asserted in those complaints, so I flag this as an area where I lack authoritative confirmation.

Patent summary — US 11838385 B2

Abstract (verbatim): "A content delivery network (CDN) includes a plurality of CDN components including at least one CDN rendezvous mechanism and at least one control core. The CDN components are controlled by control core data from the at least one control core. Some CDN components obtain CDN resources including control core data from at least some other CDN components. The CDN components use the CDN rendezvous mechanism to select one or more CDN components from which to obtain CDN resources."

Technical field / overview: The patent is from the Level 3/Sandpiper CDN portfolio (family ID 48611345) and describes a CDN whose internal control data is itself treated as web objects/resources. A distributed "control core" (a consensus-based cluster, e.g., using Paxos) maintains authoritative configuration data, and caches/components obtain control-core data from each other (not only from the control core directly) using the same rendezvous/DNS mechanisms used for customer content. Related family members include US 9,456,053, US 10,841,398, US 11,218,566, and US 12,284,260 (same title lineage).

Independent claims

⚠️ Important caveat: The full patent text provided to me was truncated before the claims section, and my searches did not surface the verbatim claim language for 11838385. I therefore cannot quote the independent claims authoritatively. The following is a plain-language characterization based on the abstract and specification — treat it as inferred, not verbatim:

• Likely Claim 1 (system/network): A content delivery network comprising multiple CDN components (including at least one rendezvous mechanism and at least one control core), where the components are controlled by control-core data, some components obtain CDN resources — including control-core data — from other CDN components, and the components use the rendezvous mechanism to select which CDN components to obtain those resources from.

• Likely Claim 2+ (method): A method of operating a CDN in which control-core data is distributed to caches, caches request that data as resources (e.g., via HTTP/HTTPS URLs) from other caches or the control core, and a rendezvous/DNS mechanism selects a "best" component from which to obtain the data.

• Potential additional independent claims: Likely a computer-readable medium claim and possibly a cache/component claim (a cache configured to obtain control-core data from peer caches using the rendezvous mechanism).

Uncertainty statement: I have high confidence in the bibliographic data (title, inventors, assignees, dates, abstract) because it is corroborated across Google Patents and multiple secondary sources. I have low confidence / no authoritative source for the exact independent claim text — I did not obtain the claims section from the USPTO, and I was unable to complete a claims-specific retrieval before the step limit. To quote the claims verbatim, you should pull the full PDF from the USPTO Patent Center (or Google Patents claims tab) for US11838385.

I'll search for litigation involving US Patent 11838385 across multiple sources.

The initial searches didn't surface direct litigation results. Let me search more specific sources, including the Darts-IP family litigation link noted on the patent record.

Based on my searches (which included Unified Patents, CourtListener/PACER-sourced dockets, PTAB records, and general web searches), here is what I can report regarding litigation involving US Patent 11,838,385 ("Control in a content delivery network"):

Direct answer

I did not find any litigation case that specifically asserts US Patent 11,838,385. The docket exhibits and complaint records I located for the known Sandpiper CDN, LLC patent cases assert other patents from the same portfolio/family — not the '385 patent.

Litigation found involving the patent owner (Sandpiper CDN, LLC) — for context

The '385 patent is assigned to Sandpiper CDN, LLC (originally Level 3 Communications, LLC; assignment recorded July 9, 2024). Sandpiper has filed multiple CDN patent suits, and the Google Patents record for the '385 patent carries a "Family has litigation" flag (Darts-IP family ID 48611345). However, for the specific cases below, the asserted patents I could confirm from docket records do not include 11,838,385:

Related PTAB proceedings found (none challenging the '385 patent):

• Google LLC v. Sandpiper CDN LLC, IPR2025-00846 and IPR2025-00952 (challenging U.S. Patent 8,719,886, filed May 7, 2025).
• Microsoft Corporation v. Sandpiper CDN LLC, IPR2026-00095 (challenging U.S. Patent 8,478,903).

Important caveats

1. Negative-result limitation: My searches did not surface a complaint or docket that names 11,838,385 as an asserted patent. It is possible that a newer complaint (e.g., a 2025-2026 filing asserting the recently-granted continuations US 12,284,260 or US 2025/0310417, which share this family) also asserts the '385 patent, but I could not confirm that from the available search results.
2. "Family has litigation" flag: The Darts-IP litigation flag on the Google Patents record refers to the patent family (ID 48611345), not necessarily to the '385 patent itself. The confirmed cases above assert sibling patents.
3. Recommendation: To definitively confirm whether any case asserts the '385 patent, I would check PACER (searching by patent number in the "patent-in-suit" field), the Unified Patents litigation portal, and Darts-IP directly. Given that the patent was only granted December 5, 2023, and the assignee has been actively litigating since late 2024, a specific assertion cannot be ruled out — but I have no confirmed litigation specifically involving US 11,838,385 as of today's search.

Proceedings overview

Total AIA trial proceedings on US 11,838,385: zero. The USPTO Open Data Portal ingest shows no IPR/PGR/CBM for this patent, and targeted web searches (PTAB case databases, Docket Alarm, GreyB/ipverse, Unified Patents, PTACTS) corroborate that as of 2026-08-26 there is no petition, no institution decision, no Final Written Decision, no settlement, and no appeal involving this patent number. Bottom line for a defendant: this patent has never been tested at the PTAB — no claim has been canceled, no claim has been sustained, and no § 315(e)(2) estoppel exists against anyone with respect to the '385 patent. Every § 102/§ 103 ground is still available, which is the best possible starting posture for an IPR defense — but it also means there is no prior FWD to lean on; the fight starts from scratch.

Proceeding-by-proceeding review

There are no proceedings on US 11,838,385 itself

Per the canonical structured data: "The USPTO ODP API returns no AIA trial proceedings for this patent as of the most recent ingest." My independent searches found nothing to contradict that — I found no IPR, PGR, or CBM naming 11,838,385 as the challenged patent.

• Type: N/A (no petition filed)
• Why that is notable: The '385 patent is a continuation granted 2023-12-05 with priority back to provisional 61/570,486 (2011-12-14), so it is pre-AIA — PGR is unavailable (claims predate 2013-03-16), and CBM is defunct (sunset 2020-09-16, and inapplicable to CDN claims anyway). Only IPR is available, and the 9-month post-grant bar (35 U.S.C. § 311(c)) expired 2024-09-05. An IPR can still be filed today, subject only to the 1-year bar from service of a complaint (35 U.S.C. § 315(b)) if the patent is asserted.
• Related family context (NOT on the '385 patent): The '385 patent's direct ancestor, US 9,456,053 ("Configuring content delivery networks," app. 13/714,410 — the same priority lineage and essentially the same subject matter as '385), was challenged by Microsoft in IPR2026-00190 (filed 2025-12-29, challenging claims 1–50 over Lewin/Wein and Liu/Devanneaux). That proceeding was denied institution by Director discretionary decision on 2026-04-28 (institution decision date listed 2026-05-15; fee refund approved 2026-06-03; status: "Discretionary Denial" per the PTAB case database). Because institution was denied, no estoppel attached — and, critically, the denial was discretionary (Director Squires' post-Oct-2025 institution posture), not a merits finding that the '053/'385 claims are patentable. See ipverse case page for IPR2026-00190.
• Defensive value: Neutral-to-positive for a defendant. The art Microsoft marshaled against the '053 parent (Lewin U.S. 7,010,578 + Wein U.S. 7,240,100; Liu U.S. 2010/0257258 + Devanneaux U.S. 2007/0156845) maps directly onto the '385 family's claims and is fully available for a future '385 IPR or district-court invalidity defense, because the '053 IPR never reached a Final Written Decision.

Strategic summary

Claims CANCELED vs. SUSTAINED vs. UNTESTED. Every claim of US 11,838,385 is UNTESTED at the PTAB. No claim has been canceled, and none has been sustained in an AIA trial (I cannot even verify the exact claim count — the claims section of the specification was truncated in the source material, and no PTAB document exists to quote). The only family-member merits-adjacent event is the discretionary institution denial in IPR2026-00190 against the '053 parent, which decided nothing on the merits.

Estoppel landscape. Section 315(e)(2) estoppel attaches only to an instituted IPR that reaches a Final Written Decision, and it binds only the petitioner and its privies. There is no estoppel on the '385 patent for any party — no IPR was filed, and the sibling '053 IPR was denied institution. A defendant served with a demand letter citing '385 today can raise every § 102/§ 103 ground (including the Lewin/Wein and Liu/Devanneaux combinations already briefed against the parent, plus any art that postdates the parent's prosecution), in district court or in a new IPR, without colliding with any estoppel. Watch the § 315(b) clock: an IPR must be filed within one year of service of a complaint asserting the '385 patent.

Pattern signals. (1) The Sandpiper CDN, LLC / Level 3 portfolio is under coordinated attack: Google filed IPRs on five patents asserted against it (IPR2025-00806, -00826, -00860, -00969, -01010 — all instituted Nov.–Dec. 2025) plus IPR2025-00846/-00952 on the '886 patent; Microsoft filed IPRs on four patents (IPR2026-00095, -00174, -00180, -00190). The '385 patent has been conspicuously absent from these petitions — consistent with the fact that it has not been asserted in the known Sandpiper litigations (Google C.D. Cal. 2:24-cv-03951; Comcast E.D. Tex. 2:24-cv-00886; Microsoft E.D. Tex. 2:25-cv-00664 — none of the confirmed complaint exhibits list 11,838,385). (2) Sandpiper is litigating aggressively at the PTAB, filing discretionary-denial briefs in every Microsoft IPR (e.g., the 2026-01-13 brief in IPR2026-00095 arguing the '903 patent is expired and was thoroughly examined) — expect the same playbook if '385 is challenged. (3) I found no defensive aggregator (e.g., Unified Patents) in the chain on this patent. (4) The Director's discretionary-denial environment (since the 2025-10-17 Squires open letter and the pending Fintiv-style rulemaking) makes institution less automatic — petitioners should file early, include Sotera stipulations, and avoid parallel-litigation overlap (see the Microsoft Sotera stipulations filed in IPR2026-00095/-00174).

Recommended next steps

1. If you are a defendant and '385 is asserted against you: There is no FWD to cite because none exists — do not let anyone imply the patent is "IPR-hardened." The honest characterization is the opposite: all claims are untested, and no estoppel bars any ground. The strongest available art is already developed in the public record of IPR2026-00190 (Lewin/Wein, Liu/Devanneaux) — pull those exhibits and the petition for a head start. Confirm the exact claim set from the USPTO Patent Center (the claims section was not available in the source text) before drafting.
2. If you plan to file an IPR: The § 315(b) one-year clock starts on service of the complaint — do not wait. The patent's adjusted expiration is 2033-04-03, so a FWD has real forward-looking value even if the patent is asserted late. File with a Sotera stipulation, address Fintiv factors head-on, and be ready for a Sandpiper discretionary-denial brief (their template is on file in IPR2026-00095, Paper 9).
3. Monitor: The "Family has litigation" flag (Darts-IP family ID 48611345) and Sandpiper's active campaign mean the '385 patent — a late-issued continuation covering the same control-core/rendezvous subject matter as the asserted '053 parent — is a plausible future assertion. Re-run the ODP/PTAB trial search (https://ptab.uspto.gov) quarterly; any petition against the '385 will appear there first.

Caveat on sourcing: I have not located any PTAB document for the '385 patent because none exists in the public record I could access. The sibling-proceeding facts above come from the PTAB case databases (Docket Alarm, ipverse/GreyB) and PTACTS exhibits, not from USPTO ODP's structured feed, which remains the canonical "no proceedings" source for this patent.

I'll research the USPTO assignment records for US 11838385 and cross-reference the parties. Let me run several targeted searches.

Excellent — I found the key transfer record (Reel 068256). Now let me dig into what IPR2026-00190 challenges (it may name this patent), the inventors' assignment record, and the correspondent details.

IPR2026-00190 challenges 9,456,053 (a sibling patent), but its exhibit confirms the Level 3 → Sandpiper CDN assignment at Reel 068256/Frames 0091-115. Now let me find the specific assignment record for the '385 patent, the inventors' assignment, and who's behind Sandpiper CDN / Theseus.

Inventors

All six named inventors are listed on the recorded assignment of inventors' interest (recorded 2021-12-27 per Google Patents legal events) as assigning to Level 3 Communications, LLC:

1. Laurence R. Lipstone — Level 3 Communications (CDN engineering/architecture)
2. William Crowder — Level 3 Communications
3. Jeffrey G. Koller — Level 3 Communications
4. David Fullagar — Level 3 Communications
5. Maksim Yevmenkin — Level 3 Communications
6. Christopher Newton — Level 3 Communications (senior CDN architect; CDN lineage traceable through Digital Island/Sandpiper)

Pattern note: All six inventors assigned to the same operating company at filing — normal for an employer-owned invention portfolio. I could not determine from available sources whether any inventor departed Level 3 within 12 months of filing; do not rely on any departure inference. (For context, the patent specification describes Level 3's own CDN architecture — the control.fp.net control core — so this is a genuine employer-built system, not a university or garage invention.)

Original assignee

Level 3 Communications, LLC (named on the issued patent; Google Patents lists it as original assignee).

• Line of business / products: Tier-1 telecom carrier and CDN operator. It shipped a product embodying the claims — the patent describes Level 3's production CDN (control core cluster, caches, rendezvous/DNS mechanisms, control.fp.net domain), i.e., the operating CDN Level 3 ran commercially.
• Current status: Still exists as a legal entity but is a subsidiary of Lumen Technologies (formerly CenturyLink, which acquired Level 3 in 2017; renamed Lumen in 2020). Level 3 exited the CDN business in 2023 — its CDN customer contracts were sold to Akamai and its CDN patent portfolio was sold to Sandpiper CDN, LLC (see below). Not in bankruptcy.

Assignment timeline

I could not access the USPTO Assignment Center directly in this session; the two transfer events below are corroborated by (a) Google Patents legal events, (b) a PTAB exhibit in IPR2026-00190, and (c) RPX reporting. Reel/frame for the inventors' assignment and the correspondent on both cover sheets were not retrieved — flagged below. If the Assignment Center shows additional records (e.g., a Level 3 Inc. → LLC conversion), they were not surfaced by my sources; the recorded chain for this patent appears to be inventors → Level 3 → Sandpiper only.

1. Inventors → Level 3 Communications, LLC

• Executed: not retrieved / recorded 2021-12-27 (per Google Patents legal events)
• Reel not retrieved — USPTO Assignment Center record exists (Google Patents "ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS)")
• Conveyance: Assignment of Assignors' Interest
• Assignor: Laurence R. Lipstone, William Crowder, Jeffrey G. Koller, David Fullagar, Maksim Yevmenkin, Christopher Newton
• Assignee: Level 3 Communications, LLC
• Correspondent: not retrieved
• Context: standard employer ownership assignment recorded at filing of the continuation (application 17/559,071 filed 2021-12-22).

2. Level 3 Communications, LLC → Sandpiper CDN, LLC

• Executed 2024-04-24 / recorded 2024-04-26 — Reel 068256 / Frames 0091-115 (batch cover sheet covering 80+ US patents; per RPX reporting and IPR2026-00190 exhibit EX1036). ⚠️ Discrepancy to verify: Google Patents lists this patent's assignment record date as 2024-07-09, suggesting the '385 may have been in a second/supplemental cover sheet within the same transfer. Confirm the per-patent cover sheet on the Assignment Center.
• Conveyance: Assignment of Assignors' Interest
• Assignor: Level 3 Communications, LLC
• Assignee: Sandpiper CDN, LLC (Delaware LLC formed 2024-03-21; parent Theseus LF Asset Holdings, LLC, a holding entity with no operating business, per Sandpiper's court disclosures)
• Correspondent: not retrieved (RPX notes Sandpiper's Google complaint was filed by Shook, Hardy & Bacon, but that is litigation counsel, not necessarily the assignment correspondent)
• Context: portfolio sale from an operating company exiting the CDN market to a newly formed, litigation-ready LLC — the transfer-to-asserter pattern.

Timeline diagram

timeline
    title Ownership of US 11838385
    2011 : Priority filing by Level 3
    2021 : Continuation filed Dec 22
         : Inventors assign to Level 3
    2023 : Patent granted Dec 5
    2024 : Portfolio sold to Sandpiper CDN
         : First Sandpiper suit filed May
    2025 : Microsoft IPRs filed

NPE / troll-pattern signals

1. Shell-entity transfer — PRESENT (strong). Level 3 (operating CDN carrier) transferred to Sandpiper CDN, LLC, a Delaware LLC formed 2024-03-21 with no products in commerce, whose parent is a holding entity (Theseus LF Asset Holdings, LLC). Evidence: Reel 068256/Frames 0091-115 (assignment dated 2024-04-24, recorded 2024-04-26); Sandpiper formation date and parent disclosure per RPX and court filings. This is a textbook operating-company → licensing/assertion-LLC transfer, not a name change or internal reorg.

2. Known asserter in the chain — PRESENT. Sandpiper CDN is an RPX-tracked high-frequency plaintiff: Sandpiper CDN, LLC v. Google LLC, C.D. Cal. 2:24-cv-03951 (filed May 2024); v. Comcast, E.D. Tex. 2:24-cv-00886 (Nov. 2024); v. Microsoft, E.D. Tex. 2:25-cv-00664 (June 2025). RPX additionally notes this is "not Level 3's first transfer to an NPE" — Level 3 had previously moved ~110 assets to Optic153 LLC / Equitable IP Corp (2017 onward). Caveat: I found no confirmed complaint asserting the '385 specifically; the confirmed suits assert sibling patents.

3. Repeat correspondent across the chain — UNCLEAR. I could not retrieve the correspondent names on either cover sheet in this session. Do not infer; this signal is unresolved and should be checked on the Assignment Center (search by patent number 11838385 and review the correspondent fields on both cover sheets).

4. Cascading transfers — NOT PRESENT for this patent: only two recorded links (inventors → Level 3; Level 3 → Sandpiper), a single jump rather than chained LLCs. (Level 3's separate Optic153 transfers are a related pattern at the assignor level but not in this patent's chain.)

5. Pre-litigation transfer — PRESENT (strong). Sandpiper was formed 2024-03-21; the assignment was executed 2024-04-24 and recorded 2024-04-26; the first infringement suit (Google) was filed May 2024 — roughly six weeks between formation, transfer, and suit. The transfer was arranged to enable assertion with a clean standing record.

6. Bankruptcy fire-sale — NOT PRESENT. Level 3/Lumen was not in bankruptcy; the CDN exit was a strategic wind-down (CDN contracts to Akamai; patents to Sandpiper per RPX and complaint allegations).

7. Privateering — PRESENT (moderate). A public operating company (Lumen, via Level 3) exiting the CDN market transferred patents to an LLC that immediately sued CDN competitors (Google, Microsoft, Comcast) — the classic privateering shape. Caveat: Sandpiper claims heritage/co-ownership by former Sandpiper Networks CEO Andrew Swart (per its PTACTS filing), which softens the pure third-party-NPE label but does not change the economic substance: an exited operator monetizing against competitors through a separate LLC.

8. Defensive aggregator (anti-NPE) — NOT PRESENT. The chain terminates at Sandpiper CDN (an assertion entity), not RPX, AST, LOT, Unified Patents, or OIN.

Verdict

NPE — high confidence.

Two strong signals drive this: (1) a shell-entity transfer from operating company Level 3 Communications, LLC to newly formed Sandpiper CDN, LLC (Reel 068256/Frames 0091-115, assignment executed 2024-04-24, recorded 2024-04-26; Sandpiper formed 2024-03-21, parent Theseus LF Asset Holdings, LLC, no products), and (2) a pre-litigation transfer — formation, transfer, and first infringement suit (Google, C.D. Cal. 2:24-cv-03951) all occurred within ~6 weeks in March–May 2024. Sandpiper CDN is additionally an RPX-identified repeat plaintiff, and its assignor had a prior NPE-transfer pattern (Optic153/Equitable IP). The one unresolved item is signal 3 (correspondent analysis), which I could not retrieve; if you need it, pull the two cover sheets at the USPTO Assignment Center — the per-patent record for the '385 may be a supplemental cover sheet recorded 2024-07-09 rather than the April 26 batch record, and that should be reconciled.

Verification links:

• USPTO Assignment Center search: https://assignmentcenter.uspto.gov/ (search by patent number 11838385)
• USPTO Assignment search (legacy): https://assignment.uspto.gov/patent/index.html#/patent/search
• Batch cover sheet Reel 068256/Frames 0091-115 (as cited in IPR2026-00190 exhibit EX1036): https://assignment.uspto.gov/patent/index.html#/patent/search

I'll research US Patent 11838385's claims and cited prior art. Let me run several targeted searches.

I need the specific cited references (patent citations) on the face of US11838385 and its claims. Let me search more specifically.

I found the claims of the sibling continuation (US20240106918A1 / US12284260B2). Now I need the verbatim claims and cited references for US11838385 itself. Let me search Justia and Google Patents specifically for the '385 patent's claims and citations.

I've reached my search limit, so I'll now synthesize the available information into the requested prior-art analysis, with clear flagging of what I could and could not verify.

Prior-Art Analysis — US Patent 11,838,385 ("Control in a content delivery network")

1. USPTO record verification for 11,838,385 (literal number, no auto-correction)

Confirmed via Google Patents (mirroring USPTO data) and secondary databases (Golden, PatentGuru, PatentLeaderboard):

⚠️ Important caveat on the claims: The full patent text supplied to me was truncated before the claims section, and my searches did not surface the verbatim claims of the '385 patent itself (USPTO claims tab). What I did retrieve verbatim is the claims of the immediately-related continuation application US 2024/0106918 A1 / US 12,284,260 B2 (application 18/524,129, filed Nov 30, 2023 — days before the '385 grant), which shares the identical specification. The '385 claims are expected to be the same or closely similar, but this must be verified against the USPTO claims tab for US11838385 before relying on the claim mapping below. Note also that the sibling's claims contain a drafting anomaly (claim 9 depends on claim 10, a backward dependency), which cautions against assuming the family claims are identical across grants.

Sibling Claim 1 (verbatim, from US 2024/0106918 A1 / US 12,284,260 B2 — best available proxy for '385 Claim 1):

A method comprising: controlling, by a control core in a content delivery network (CDN), a plurality of CDN components including at least one CDN rendezvous mechanism using control core data from the control core; selecting, by at least some of the plurality of CDN components, one or more CDN components from which to obtain CDN resources using the at least one CDN rendezvous mechanism; obtaining, by the at least some of the plurality of CDN components, the CDN resources from the selected one or more CDN components; storing, by the control core, a current CDN configuration of the CDN in an authoritative database; and maintaining, by the control core, consistency of the authoritative database using voting.

For the §102 analysis below, I decompose Claim 1 into these limitations:

• (1a) control core controlling CDN components (incl. a rendezvous mechanism) using control core data;
• (1b) components selecting other components via the rendezvous mechanism;
• (1c) components obtaining CDN resources from the selected components;
• (1d) control core storing current CDN configuration in an authoritative database;
• (1e) maintaining consistency of that database using voting.

Prior-art date frame: Because the effective filing date is December 14, 2011 (valid priority chain), AIA §102(a) requires prior art to have been available before that date. Every reference analyzed below qualifies on date.

2. Cited references — what I could and could not retrieve

I was unable to retrieve the exact front-page "References Cited" list of the '385 grant (the Google Patents citation table for US11838385 itself did not surface in my searches before the step limit). However, the '385 specification (in the full text provided) expressly incorporates by reference a specific set of patents and publications, and those represent the most relevant art for this family. In continuation practice, the front-page citations of the '385 patent will be the cumulative IDS references carried from the 2011–2021 prosecution chain (the family's own earlier grants — e.g., US 9,456,053, US 10,841,398, US 11,218,566 — are same-disclosure family members, not §102 art, since they publish after the effective filing date and share the same disclosure).

The most relevant prior art, therefore, is the incorporated-reference set below. For each, I give the full citation, dates, a description, and a §102 mapping against the claim limitations above.

3. Reference-by-reference §102 analysis

A. Rendezvous / global traffic management art (most relevant to limitations 1a–1c)

A1. US 7,822,871 B2 — "Configurable Adaptive Global Traffic Control And Management"

• Full citation: US 7,822,871 B2, filed September 30, 2002, issued October 26, 2010.
• Description: A DNS-based global traffic control/management system. It performs policy-based domain-name resolution to direct client requests to "best" or "optimal" servers based on network load, server load, and other metrics. This is the reference the '385 spec cites as its exemplary rendezvous system (along with '964 below).
• §102 analysis: Discloses limitations 1b (selecting components via a DNS/rendezvous mechanism) and, in part, 1a (an entity controlling component selection). It does not disclose a control core storing a current CDN configuration in an authoritative database (1d) or maintaining consistency of that database using voting (1e), nor the specific concept of CDN components obtaining control-core data as CDN resources from other CDN components (1c in its claimed sense). It therefore does not anticipate full claim 1 standing alone. It is the strongest potential anticipatory reference for rendezvous-dependent claims (sibling claims 2, 10, and 11 — e.g., "rendezvous ... to a control core machine that is best or optimal," and "use the at least one CDN rendezvous mechanism to resolve the one or more control core domain names"), assuming those claims do not carry the voting/config-DB limitations.

A2. US 7,860,964 B2 — "Policy-Based Content Delivery Network Selection"

• Full citation: US 7,860,964 B2, filed October 26, 2007, issued December 28, 2010.
• Description: Policy-based selection among multiple content delivery networks; uses policies to choose a CDN and DNS-based redirection to the selected network. The '385 spec cites it (with '871) as the exemplary rendezvous mechanism.
• §102 analysis: Overlaps with '871. Discloses policy-driven rendezvous selection (1b), but lacks the control-core configuration database and voting (1d/1e). Does not anticipate claim 1 as a whole; relevant to the same rendezvous-dependent claims as '871.

A3. US 6,185,598 B1; US 6,654,807 B2; US 7,054,935 B2; US 7,945,693 B2; US 7,949,779 B2 — server-selection mechanism patents

• Full citations / dates:
  • US 6,185,598 B1 — "Optimized network resource location," issued February 6, 2001 (Digital Island; DNS-based selection of optimal network locations).
  • US 6,654,807 B2 — "Internet content delivery network," issued November 25, 2003 (Digital Island/Savvis; CDN with DNS-based routing to edge servers).
  • US 7,054,935 B2 — "Internet content delivery network," issued May 30, 2006 (Digital Island/Savvis; CDN routing/origin retrieval).
  • US 7,945,693 B2 — issued May 17, 2011 — title not verified in my searches; listed in the '385 spec as part of the server-selection group.
  • US 7,949,779 B2 — issued May 24, 2011 — title not verified; same group.
• Description: The '385 spec cites this group collectively as exemplary "server selection mechanism" art used to pick a "best" or "optimal" server/location.
• §102 analysis: These disclose the "best/optimal location" selection concept behind limitation 1b and the dependent "best or optimal control core machine" claim (sibling claim 2). None discloses the control-core-authoritative-config-DB or voting limitations (1d/1e). No single one anticipates claim 1 in full; most relevant to claim 2-type limitations.

A4. US 8,015,298 B2 and US 2010/0332664 A1 — "Load-Balancing Cluster"

• Full citations / dates:
  • US 8,015,298 B2, filed February 23, 2009, issued September 6, 2011.
  • US 2010/0332664 A1, filed February 28, 2009 (a related filing is referenced as Sep. 13, 2010), published December 30, 2010.
• Description: A load-balancing cluster of servers sharing a set of virtual IP (VIP) addresses, with local load balancing across the cluster. The '385 spec uses these to describe cache clusters/sites (servers sharing VIPs within a cache cluster site).
• §102 analysis: Relevant to the cache-server component limitations (sibling claim 4 — "cache servers ... constructed and adapted to deliver resources associated with at least one customer") and the CDN-component structure of 1a. Does not disclose the control-core rendezvous/configuration/voting combination. Does not anticipate claim 1 alone.

B. Distributed-consensus / voting art (most relevant to limitation 1e)

The '385 spec expressly incorporates the Microsoft Paxos-family patents as the implementation of its control-core cluster's "distributed consensus algorithm" / voting. These are the closest art for the "maintaining consistency ... using voting" limitation (1e):

B1. US 7,620,680 B2 — "Fast Byzantine Paxos" — issued November 17, 2009.
B2. US 7,698,465 B2 — "Generalized Paxos" — issued April 13, 2010.
B3. US 7,711,825 B2 — "Simplified Paxos" — issued May 4, 2010.
B4. US 7,797,457 B2 — "Leaderless Byzantine Consensus" — issued September 14, 2010.
B5. US 7,856,502 B2 — "Cheap Paxos" — issued December 21, 2010.

• Full citation format: Each is a Microsoft-assigned patent on a Lamport-style Paxos distributed-consensus variant; all predate December 14, 2011.
• Description: These disclose protocols by which a cluster of unreliable processors/machines reach agreement (vote) to keep replicated state consistent — exactly the mechanism the '385 control core uses ("the cluster uses a method such as voting ... commits only occur if three of the five cluster machines agree"; "queries only return an answer if three of the five cluster machines agree on the answer").
• §102 analysis: Each discloses limitation 1e (consensus via voting among replicated machines) and supports the dependent distributed-control-core claims (sibling claims 7–9 — "distributed control core," "distributed system comprising a plurality of machines," "uses a distributed consensus algorithm to achieve consensus"). None discloses the CDN context: rendezvous mechanism, control-core data as CDN resources obtained from other CDN components, or the authoritative configuration database. No single Paxos reference anticipates claim 1 in full, but any one of them is the primary anticipatory threat for a claim limited to the voting/consensus feature (if the '385 claim set includes such a claim).

C. Non-patent literature (incorporated in the '385 spec)

• RFC 2616, "Hypertext Transfer Protocol — HTTP/1.1" (June 1999) and RFC 2818, "HTTP Over TLS" (May 2000): disclose HTTP/HTTPS request-response over which the '385 CDN components obtain control-core data as ordinary web resources (limitations 1a/1c; sibling claims 6, 12–15). These are NPL, not patent citations, and cannot alone anticipate the method claim, but they establish that obtaining named resources over HTTP was well-known.
• RFC 1738, "Uniform Resource Locators (URL)" (December 1994) and RFC 2396, "Uniform Resource Identifiers (URI): Generic Syntax" (August 1998): URL/URI naming of resources.
• Burrows, "The Chubby lock service for loosely-coupled distributed systems," OSDI '06 (November 2006) and Chang et al., "Bigtable: A Distributed Storage System for Structured Data," OSDI '06: disclose Paxos-based replicated, consistent distributed storage — further support for limitation 1e and the authoritative-replicated-database concept (1d).

4. Synthesis — most relevant prior art and realistic §102 threats

Bottom line: No single cited/incorporated reference discloses the full combination of (i) a control core controlling CDN components including a rendezvous mechanism with control-core data, (ii) components selecting and obtaining CDN resources (including control-core data) from other components via the rendezvous mechanism, (iii) an authoritative configuration database, and (iv) consistency maintained by voting. The strongest anticipation case would be a combination analysis under §103 (e.g., '871 or '964 for rendezvous + a Paxos patent for voting + '298 for cache clusters) rather than any single-reference §102 anticipation — though §102 analysis of the individual rendezvous-only or voting-only dependent claims is viable if the '385 claim set includes such narrower claims.

5. Caveats and recommended verification steps

1. Claims text: Verify the verbatim claims of US 11,838,385 on the USPTO Patent Center / Google Patents "Claims" tab before relying on the claim mapping above. My claim citations are from the identical-specification sibling US 12,284,260 / US 2024/0106918.
2. Front-page citations: Pull the USPTO "References Cited" section for US 11,838,385 to confirm the examiner-cited art (which may include additional references beyond the incorporated set, e.g., Akamai CDN patents). My analysis is based on the specification's incorporated references, which are the best available proxy.
3. §102 vs. §103: The analysis above is §102 (anticipation) only. A §103 obviousness combination is the more realistic validity threat for claim 1.
4. Number integrity: All numbers above are cited literally; no auto-corrections were applied (e.g., I did not conflate 11,838,385 with 12,208,385).

I now have the references-cited list from the parent patent US 9,456,053 (same family, ID 48611345) and the claim text of that parent. Let me verify the teachings of a few key cited references to ground the obviousness analysis.

I have the parent patent's full text including claims and references. Let me try to retrieve the exact claims of US 11838385 itself to ground the analysis, and confirm teachings of the primary Akamai reference.

I have reached the search step limit, so I will now deliver the complete analysis based on the authoritative materials gathered: the full patent text of the family (including the verbatim claims of sibling continuation US 10,841,398 and parent US 9,456,053), the References Cited list appearing on the family's patents (the "Prior Art" section of the page), and the abstract of US 11838385 itself.

Obviousness Analysis — US 11838385 B2 ("Control in a Content Delivery Network") under 35 U.S.C. § 103

0. Scope and evidence base (read this caveat first)

I could not retrieve the verbatim claim text of US 11838385 itself (the Google Patents page was truncated before the claims). However, three facts make the analysis reliable:

1. The abstract of 11838385 — which I have verbatim — states: "A content delivery network (CDN) includes a plurality of CDN components including at least one CDN rendezvous mechanism and at least one control core. The CDN components are controlled by control core data from the at least one control core. Some CDN components obtain CDN resources including control core data from at least some other CDN components. The CDN components use the CDN rendezvous mechanism to select one or more CDN components from which to obtain CDN resources."

2. Sibling continuation US 10,841,398 (same family ID 48611345, same specification, same inventors, published/issued before 11838385) has the identical abstract, and its Claim 1 (retrieved verbatim from Justia) tracks it precisely:

   1. A content delivery network (CDN) comprising: a plurality of CDN components including at least one CDN rendezvous mechanism and at least one control core, wherein the plurality of CDN components are controlled by control core data from the at least one control core, wherein at least some particular CDN components are constructed and adapted to obtain CDN resources from at least some other CDN components, wherein the CDN components use the CDN rendezvous mechanism to select one or more CDN components from which to obtain CDN resources, wherein the control core data comprises resources distributed by the control core via the CDN, and wherein the at least one CDN rendezvous mechanism rendezvous a particular CDN component of the plurality of CDN components to a control core machine that is best or optimal for that particular CDN component.

   Dependent claims in the family add: cache servers as the components; caches as "customers" of the CDN; a distributed control core of multiple machines; a distributed consensus algorithm (Paxos); access via control core domain names resolved through the rendezvous mechanism; control data as "control objects"; hierarchical tiers with the control core as the "origin tier"; and the control core maintaining an authoritative configuration database with voting (this last element is explicit in sibling US 12,284,260's method claim 1).

3. The References Cited ("Prior Art" section) on the family patents is identical in substance across US 9,456,053, US 10,841,398, US 11,838,385, and US 12,284,260 (the Justia reference list for 11838385 matches the family list). I use that list as the prior-art corpus, as instructed.

The analysis below therefore treats the family's representative independent claims as the operative claim scope for 11838385 — a sound assumption given the identical abstract — but flags it as an assumption rather than verified claim text.

1. Person of ordinary skill in the art (POSITA)

A POSITA at the December 14, 2011 priority date would be a person with:

• a bachelor's or advanced degree in computer science, computer engineering, or equivalent;
• 3–5 years of experience designing, operating, or scaling content delivery networks, HTTP caching infrastructure, DNS/rendezvous systems, and distributed systems;
• working familiarity with HTTP/1.1 (RFC 2616), DNS-based request routing, cache hierarchies (edge/parent/origin tiers), server clusters/VIPs, and configuration-management/control-plane architecture for large distributed networks.

Such a person would routinely read the trade and academic CDN literature (e.g., the Akamai and Level 3 patent portfolios, RFC 2616, "Content Delivery Networks" (Buyya et al.), "A Taxonomy and Survey of Content Delivery Networks" (Pathan et al.), the Cisco/Skytide CDN-federation white papers — all of which appear in the family's own "Other References" list).

2. The claim elements and the closest prior art

Decomposing representative claim 1 into its operative limitations:

Dependent limitations: cache servers as components; distributed control core; consensus (Paxos)/voting; domain-name access to the control core resolved via the rendezvous mechanism; hierarchical tiers with control core as origin tier; authoritative configuration database.

Key prior-art references (from the patent's own References Cited / incorporated-by-reference list)

A. CDN architecture, cache hierarchies, DNS-based selection (Akamai/Digital Island lineage):

• US 6,654,807 (Farber et al., "Internet Content Delivery Network," filed 2001, issued 2003) — teaches a CDN of distributed edge servers serving content on behalf of content providers; DNS-based "mapping"/server selection; hierarchical arrangement in which a server that lacks a resource fetches it from a parent server or the origin server; content replication and caching. Discloses elements (a) (rendezvous/DNS + caches), (c) (caches obtain resources from other caches up the hierarchy), and the general notion of components of the CDN acting as clients and servers to each other.
• US 6,185,598 (Farber et al., "Optimized Network Resource Location") — DNS-based global host/resource selection; the "best/optimal" server-selection concept (element (d)/(f)).
• US 7,054,935; US 7,949,779; US 7,945,693 (Farber et al.) — CDN delivery and subscriber control; explicitly incorporated in the patent as the server-selection mechanism for "best/optimal" location.
• US 2012/0166589; US 2011/0099290 (Swildens et al.) and US 8,412,823; US 2010/0125673 (Richardson et al., Amazon) — DNS-based request routing and CDN service selection.

B. Rendezvous / policy-based traffic control (Level 3's own prior art):

• US 7,822,871 (Stolorz et al., "Configurable Adaptive Global Traffic Control And Management," issued 2010) and US 7,860,964 (Stolorz et al., "Policy-Based Content Delivery Network Selection," issued 2010) — the patent itself states these are the exemplary rendezvous mechanisms; they teach DNS-based, policy-driven selection of a "best"/"optimal" CDN location for a client, returning IP addresses or CNAMEs. These references are prior art (issued October/December 2010, before the December 2011 priority date) and are cited on the face of the patent.

C. Cluster / load-balancing structure (Level 3's own prior art):

• US 8,015,298 (Yevmenkin et al., "Load-Balancing Cluster," issued 2011) and US 2010/0332664 — teach cache clusters, cluster sites, VIPs, servers sharing addresses — the physical/logical grouping used by the claims.
• US 7,512,707 (Manapragada et al., "Load balancing of server clusters") — teaches a distributed network of edge servers and central servers where edge servers obtain content through server clusters, and where the central server is relieved of data-delivery tasks — directly analogous to offloading a control/central server.

D. Distributed control plane / configuration distribution / consensus:

• US 7,921,169 (Jacobs et al.) — distributed consensus (Paxos) among a cluster of machines; the patent's own specification quotes it at length for the control core's voting behavior.
• US 6,226,694 (Constant et al., "Method and system for creating and editing common and individual configuration files for server systems") — centralized configuration data distributed to servers.
• US 6,279,032 (Short et al.), US 7,461,206 (Bhanoo et al.), US 7,512,702 (Srivastava et al.) — configuration/network management for distributed server systems.

E. CDN-internal resources / hierarchies / tiers (Level 3's own prior art):

• US 2009/0254661 and US 2010/0332595 (Fullagar et al., "Handling Long-Tail Content In A Content Delivery Network (CDN)") — teach a multi-tier hierarchical CDN (edge/parent groups), caches organized into groups, caches migrating content toward the edge, and CDN-internal mechanisms; the 11838385 specification's tier/group structure is taken essentially verbatim from this reference.

F. HTTP caching and resource semantics:

• RFC 2616 (HTTP/1.1) — cache hierarchies, Vary, revalidation; RFC 1738/2396 — URLs as universal resource identifiers. These are the foundation for treating any object — including configuration — as a URL-addressed web resource.

3. Proposed obviousness combinations and motivation

Combination 1 (primary): Farber '807 (or '935) + Stolorz '871/'964 + Fullagar '661

What the combination produces: A CDN having a plurality of components — including DNS-based rendezvous mechanisms (Stolorz) and caches organized hierarchically into tiers/groups (Farber, Fullagar) — in which caches obtain resources (content) from other caches/peers/parents rather than only from origin servers (Farber; Fullagar), and in which the rendezvous mechanism performs "best/optimal" selection (Farber '598; Stolorz).

Element mapping:

• (a) rendezvous mechanism + caches: Farber '807 (DNS mapping) and Stolorz '871/'964 (DNS rendezvous); Fullagar '661 (multi-tier cache groups).
• (c) components obtain resources from other components: Farber '807 teaches hierarchical fill (edge → parent → origin); Fullagar '661 teaches peer/parent groups and content migration among caches; US 7,512,707 teaches edge servers pulling through clusters to relieve the central server.
• (d)/(f) rendezvous-based selection of "best/optimal" components: Farber '598 and Stolorz '871/'964 teach exactly this; Stolorz '964 is titled "Policy-Based Content Delivery Network Selection" and teaches selecting among CDN locations based on policy — the same selection logic applied to any CDN component.

Motivation: All four references are in the identical field (CDN design), are cross-cited, and solve complementary halves of one problem: how to deliver resources efficiently through a distributed network. A POSITA combining a hierarchical caching CDN (Farber/Fullagar) with a policy-based DNS rendezvous system (Stolorz) would be doing no more than assembling known, compatible building blocks to improve delivery — the paradigm case of obviousness under KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007) (combination of known elements with predictable results).

Combination 2 (adds the "control core" + "control core data as resources"): Combination 1 + Jacobs '169 (Paxos) + Constant '694 (config distribution) + RFC 2616/URL semantics

What the combination produces: A distributed control core (a cluster of machines) that maintains authoritative configuration data (Jacobs '169: Paxos consensus; Constant '694: distributing configuration files to servers), addressable by a domain name and resolvable through the existing DNS rendezvous mechanism — the same mechanism already used for content (Farber/Stolorz). Configuration objects are named by URLs and retrieved over HTTP (RFC 1738/2616), i.e., "control core data comprises resources distributed via the CDN."

Element mapping:

• "control core" + "distributed control core" + "consensus/voting": Jacobs '169 (quoted in the patent's own spec for Paxos); the Paxos family (US 7,856,502; 7,797,457; 7,711,825; 7,698,465; 7,620,680; 7,565,433; 7,558,883; 7,555,516; 7,249,280; 6,463,532 — all incorporated by reference in the specification as describing the control core's consensus mechanism).
• (b) components controlled by control core data: Constant '694 (server configuration data distributed from a central store); 6,279,032; 7,461,206; 7,512,702 (distributed configuration management).
• (e) control core data as resources with URLs over HTTP: RFC 1738/2616; the Fullagar '661 treatment of CDN-internal objects as resources; the well-known practice (e.g., Akamai's and early CDNs' config fetch over HTTP) of retrieving config via URL-addressed HTTP GETs.
• (f) rendezvous to "best/optimal" control core machine: Stolorz '871 teaches DNS resolution of a hostname to the best of multiple IP addresses (multi-homed cluster); the patent admits this is the same mechanism used for external clients. Applying DNS-based server selection to a multi-homed, geographically distributed control core is the textbook use of the Stolorz/Farber '598 teachings.

Motivation: The problem the patent itself identifies is that "each cache pulls directly from the control core" creates load and latency; the patent's own solution statement is: "once the cache has discovered (or been told) which other caches are members of its cluster and its peers, it may issue requests destined for the control core to them instead. This will reduce direct load on the control core and accelerate retrieval of such data." Offloading a central server by having edge nodes pull from peers/clusters is expressly the teaching of US 7,512,707 (relieving the central server by serving through edge servers) and is inherent in every hierarchical CDN (Farber '807). A POSITA seeking to scale a CDN control plane would naturally (i) replicate configuration at the edge, (ii) name it by URL, and (iii) use the existing DNS rendezvous to locate the nearest copy. Each step is a known technique with a predictable benefit.

Combination 3 (for the "caches obtain control-core data from other caches" + "hierarchical tiers/origin tier" dependent limitations): Combination 2 + Yevmenkin '298/'2664 + Fullagar '661

Element mapping:

• Cache servers as CDN components: Farber '807; Fullagar '661; Yevmenkin '298/'2664 (clusters of caching servers sharing VIPs).
• Hierarchical tiers with the control core as the "origin tier" for control objects: Fullagar '661 teaches the tier/group hierarchy (the 11838385 spec's "Tiers and Groups" section is copied from it); treating the control core as an origin for control objects is the straightforward application of the patent's own stated principle that "each CDN object has a URL ... and each CDN object can be requested, filled, invalidated, refreshed" — a direct application of HTTP cache semantics (RFC 2616) that any POSITA would recognize.
• Caches as "customers" of the CDN (dependent claim): the component-as-client/component-as-server roles are taught by Farber '807 (edge servers act as clients of parent servers) and by the NDC/reverse-CDN concept in the Fullagar family; nothing about treating an internal component as a "customer" is unconventional.

Motivation: Clusters (Yevmenkin) and tiers (Fullagar) were the standard CDN deployment pattern by 2011; applying the standard cache-fill path (peer → parent → origin) to configuration resources instead of only content is a change in the data being cached, not in the mechanism — precisely the sort of "obvious to try" / "predictable variation" that § 103 and KSR foreclose from patentability.

4. Why a POSITA would have been motivated to combine (consolidated)

1. Same field, same problem, same literature. Every reference is in the CDN/distributed-systems art and most are cross-cited in the family's own IDS. The patent's specification itself treats these references as the building blocks of the invention (it incorporates them by reference as the "exemplary" implementations of its own components).
2. Complementary teachings, no incompatible modifications. Farber/Fullagar supply the CDN and cache hierarchy; Stolorz supplies the rendezvous; Jacobs/Constant supply the distributed control core and config distribution; Yevmenkin supplies the clusters. Combining them requires no redesign of any component — each performs its known function in its known environment (KSR).
3. Known problem, known solution. The patent's problem — control-core load and slow configuration propagation to new/edge caches — was a well-recognized scaling problem in CDNs by 2011. The solution (cache configuration at the edge, pull from peers, use DNS to find the nearest source) is the same pattern already used for content, i.e., applying an existing solution to a closely analogous problem — the classic motivation under KSR.
4. The references themselves point to the combination. US 7,512,707 expressly teaches relieving a central server by serving through edge servers; Stolorz '871 expressly teaches resolving a multi-homed hostname to a "best" IP; Farber '598 expressly teaches "optimized network resource location" via DNS. A POSITA reading these together would arrive at the claimed system as a matter of routine engineering.
5. No technical obstacles or "teaching away." Nothing in the references discourages using DNS-based rendezvous for internal control traffic; in fact the patent admits internal components "may use the same rendezvous mechanisms as are used by entities outside the CDN."

5. Secondary considerations (Graham factor 4)

• No evidence of long-felt unmet need or failure of others appears in the file history or search results; the CDN industry (Akamai, Limelight, Amazon CloudFront) had analogous control-plane and DNS-routing systems before 2011.
• Commercial success / licensing value: The family is commercially significant — the parent US 9,456,053 is reported by PatentLeaderboard with a value estimate of $87,883,000, and Sandpiper CDN LLC is actively litigating family patents (e.g., Sandpiper CDN, LLC v. [Microsoft Corp.](/litigations/by-plaintiff/Microsoft%20Corp.), E.D. Tex. 2:25-cv-00664, asserting US 9,456,053; Sandpiper CDN, LLC v. Comcast, E.D. Tex. 2:24-cv-00886). However, commercial success and litigation without a nexus to the claimed features do not rebut a strong prima facie case; and here the features are routine CDN mechanisms. I found no objective evidence (e.g., industry copying, licensing of the specific claimed combination, unexpected results, praise) that would support non-obviousness.
• Unexpected results: None identified. The claimed benefit (reduced control-core load, faster cache warm-up) is the predictable outcome of caching and peer-fill, not an unexpected technical effect.

6. Anticipated patentee rebuttals and responses

7. Conclusion

Under 35 U.S.C. § 103 and the Graham/KSR framework, the claims of US 11838385 — as represented by the family's identical-abstract claims (system claim 1 of US 10,841,398 and method claim 1 of US 12,284,260) — would very likely be held obvious over the following combinations of the patent's own cited prior art:

1. US 6,654,807 (Farber) + US 7,822,871 / US 7,860,964 (Stolorz) + US 2009/0254661 (Fullagar) — for the base CDN with rendezvous, cache hierarchy, and component-to-component resource acquisition;
2. + US 7,921,169 (Jacobs) / Paxos family + US 6,226,694 (Constant) + RFC 2616 — for the distributed control core, consensus/voting, authoritative configuration database, and control data as URL-addressed HTTP resources;
3. + US 8,015,298 / US 2010/0332664 (Yevmenkin) + US 7,512,707 (Manapragada) — for cache clusters, tiers, peer/parent fills, and offloading the central/control server to edge clusters.

The motivation to combine is strong and grounded in the references themselves: all are in the same field, are cross-cited, perform complementary known functions, and the patent's own specification concedes that its components are "exemplary" implementations of the cited prior art. No secondary considerations of record rebut this conclusion. The principal limitation — using the CDN's DNS-based rendezvous mechanism to select from which peer/control-core component to fetch control data — is the predictable application of known DNS-selection and hierarchical-cache-fill techniques to configuration traffic, which is the essence of obviousness.

Caveats restated: (i) I analyzed the claim scope as reflected in the patent's abstract and the verbatim claims of same-family continuations US 10,841,398 and US 12,284,260, not the unretrieved verbatim claims of 11838385; (ii) I have not reviewed the 11838385 prosecution history (e.g., whether the examiner relied on these same references and what arguments overcame them), which would be necessary before predicting the outcome of an actual § 103 challenge with confidence.