US 11218566

I found the patent. Let me now retrieve the full details including the abstract and claims from authoritative sources.

I have the bibliographic details. Now let me retrieve the abstract and the independent claims from the patent itself.

Based on my searches, here is a concise summary of US Patent 11,218,566 (US11218566B2). I have high confidence in the bibliographic data (confirmed by Google Patents, USPTO report, and the patent text provided); I could not retrieve the verbatim text of the claims from my search results, so the claim overview below is flagged accordingly.

US Patent 11,218,566 B2 — "Control in a content delivery network"

Abstract (as published; matches the family's later continuations):

"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."

Plain-language overview of the independent claims

⚠️ Uncertainty caveat: The full claim text was not accessible in my search results (the specification text provided to me was truncated before the claims section). The overview below is my best characterization based on the published abstract, the specification, and the parallel family members — it should not be treated as verbatim claim language.

The invention generally covers a self-managing CDN architecture where control/configuration data is itself treated as CDN content that can be distributed among CDN components. Based on the abstract and specification, the independent claims appear to cover variations of the following core ideas:

1. System claim (CDN architecture): A content delivery network comprising multiple CDN components — including at least one rendezvous mechanism (e.g., DNS-based) and at least one control core — where the components are governed by control core data, where some components (e.g., caches) obtain CDN resources (including control core data such as configuration objects) from other CDN components rather than only from the control core, and where the rendezvous mechanism is used to select which CDN component(s) a component should obtain those resources from.

2. Method claim(s): Corresponding computer-implemented methods of operating the CDN — e.g., a control core distributing configuration data (such as a Global Configuration Object, GCO, and Customer Configuration Scripts, CCSs) to caches, caches obtaining that data from peer/parent caches, and caches using the rendezvous mechanism to select a component from which to fetch CDN resources.

3. Additional independent claims likely cover variations such as: treating control core data as web objects addressable by URLs; components acting as both clients and content providers within the CDN; and/or hierarchical distribution of control data through cache tiers. (Inferred — not verified.)

Litigation / CAFC 2026 docket note

• Google Patents lists the family as "Family has litigation" (Darts-ip family ID 48611345).
• My searches surfaced a district court case — Sandpiper CDN, LLC v. Microsoft Corporation (E.D. Tex., Case 2:25-cv-00664, complaint filed June 26, 2025) — which asserts related family patents (e.g., the '053 patent, US 9,456,053) against Microsoft's Azure CDN products.
• I found no CAFC 2026 docket entries specifically for US 11,218,566 in my searches. I cannot confirm or deny CAFC activity; the searches simply did not return any such docket record. If you need CAFC docket verification, I'd recommend checking PACER or the CAFC's public docket database directly.

Sources: Google Patents (US11218566B2 and family pages), uspto.report/patent/grant/11,218,566, CourtListener (Sandpiper CDN v. Microsoft complaint), PatentGuru/PatentLeaderboard inventor pages.

Based on my searches of publicly available litigation records (CourtListener, PACER Monitor, Docket Alarm, Unified Patents, PTAB), here is what I can confirm regarding litigation involving US Patent 11,218,566 ("Control in a content delivery network").

Direct answer

I could not identify any case in which US Patent 11,218,566 is specifically asserted or challenged as a named patent-in-suit. None of the complaint exhibits, docket sheets, or PTAB petitions I located list the '566 patent by number.

Context: the patent family is in litigation (family ID 48611345)

The Google Patents record for US 11,218,566 carries the notation "Family has litigation" with a Darts-IP entry for "First worldwide family litigation filed" (family ID 48611345). That litigation, however, involves related family members rather than the '566 patent itself. The '566 patent is a continuation (filed Nov. 11, 2020; priority Dec. 14, 2011), originally assigned to Level 3 Communications LLC and now assigned to Sandpiper CDN, LLC (parent: Theseus IP, LLC / Sandpiper Consulting, LLC).

Sandpiper CDN, LLC has been running a litigation campaign asserting other patents in this family. Known cases:

1. Sandpiper CDN, LLC v. Microsoft Corporation — E.D. Tex., Case No. 2:25-cv-00664 (filed 2025). Patents asserted per the complaint: at least U.S. Patent Nos. 8,478,903 ('903), 9,021,112 ('112), and others (exhibits A–H include '112, '903, 7,822,871, 7,860,964, 9,660,876, 9,647,899, 10,116,738, 8,156,066, 8,645,517, and 10,701,173 — not '566). Status: pending; Microsoft has served invalidity contentions; related PTAB proceeding IPR2026-00095 (Microsoft v. Sandpiper CDN LLC) references this case (Dkt. 43).

2. Sandpiper CDN, LLC v. Microsoft Corporation — E.D. Tex., Case No. 2:26-cv-00681 (filed 2026). Complaint exhibits list U.S. Patent Nos. 9,021,112; 7,822,871; 7,860,964; 9,660,876; 9,647,899; 10,116,738; 8,156,066; and 8,645,517 — again, not '566. Status: pending (initial AO 120 filings only).

3. Sandpiper CDN, LLC v. Google LLC — C.D. Cal., Case No. 2:24-cv-03951 (filed 2024; amended complaint Jan. 10, 2025). Asserted patents include 8,645,517 ('517), 9,021,112 ('112), 8,478,903 ('903), and others; the court dismissed the claim on U.S. Patent No. 8,719,886 in September 2024. '566 not identified. Related PTAB proceeding: IPR2025-00826 (Google LLC v. Sandpiper CDN LLC, challenging U.S. Patent No. 9,021,112).

4. Sandpiper CDN, LLC v. Comcast Cable Communications LLC — E.D. Tex., Case No. 2:24-cv-00886 (filed Nov. 1, 2024). Asserted patents: 9,628,347; 9,660,876; 8,478,903; 7,013,322; and 9,762,692. '566 not identified. Status: pending.

Caveats

• I did not have access to the full complaint exhibits for every case above (e.g., the complete exhibit lists in 2:25-cv-00664), so it is possible the '566 patent appears in a supplemental pleading, counterclaim, or IPR that my searches did not surface.
• The Darts-IP family-litigation flag confirms some member of family 48611345 has been litigated, but the specific member(s) asserted are not identified in the search results I obtained.
• For a definitive answer on whether the '566 patent itself is in suit, you would need to check the dockets directly (PACER/ECF for E.D. Tex. and C.D. Cal.) or the Darts-IP family record at the link provided on the Google Patents page.

Proceedings overview

There are zero (0) AIA trial proceedings — IPR, PGR, or CBM — on file against US 11,218,566 B2, per the canonical USPTO Open Data Portal data in this prompt, and web search did not surface any older or newly-filed petition against this patent either. No claims have been invalidated, no institution has been granted or denied, nothing has settled — the patent is PTAB-untested. For a defendant, that cuts both ways: there is no estoppel and no "dead claim" leverage from a prior FWD, but the patent is also completely un-hardened — it has never survived (or faced) a single merits review, and the same patent owner's related family members are currently being attacked by the very same defendants (Google, Microsoft) now in litigation against Sandpiper CDN, LLC.

No proceedings on US 11,218,566 B2

There is no per-proceeding section to write because no proceeding exists. What follows is what I can verify, and what I cannot.

• Type: N/A — no IPR, PGR, or CBM has been filed against US 11,218,566 B2.
• Filed / Status / Judge panel / Petition grounds / Institution decision / FWD / Settlement / Appeal: All N/A. I will not invent a proceeding number, panel, or verdict.
• Verification: The structured ODP block in this prompt is empty for this patent. My searches for US11218566 IPR, "11218566" PTAB, and "Control in a content delivery network" IPR Level 3 returned no PTAB docket referencing this patent number.

Defensive value: No PTAB estoppel attaches to anyone with respect to this patent, and no claim is canceled. Any IPR defense you mount today would be the first attack on the patent, not a follow-on — which means the full universe of § 102/§ 103 grounds remains available to you (subject to the one-year § 315(b) bar from service of a complaint, and any district-court timing issues).

Related proceedings in the same portfolio — NOT against US 11,218,566 (flagging so you don't confuse them with this patent)

Web search surfaced an active PTAB campaign by Google and Microsoft against other Sandpiper CDN / Level 3 patents in the same family and portfolio. These are context, not proceedings on this patent:

• IPR2026-00095 — Microsoft Corporation v. Sandpiper CDN, LLC — challenges US 8,478,903 (the "Sandpiper Networks" foundational CDN patent, expired 2023), not 11,218,566. Microsoft filed an opposition to Sandpiper's discretionary-denial request on 2026-02-13. (DocketAlarm: IPR2026-00095, No. 11.)
• IPR2026-00190 — Microsoft Corporation v. Sandpiper CDN, LLC — challenges US 9,456,053 (App. 13/714,410 — the parent of this patent's chain: 13/714,410 → 14/302,865 → 17/095,325 (US 11,218,566)). Filed 2025-12-29; per IPVerse/GreyB, the Director issued a discretionary denial on 2026-04-28, institution decision date 2026-05-15, and Microsoft's filing fee was refunded (approved 2026-06-03). So the Board declined to institute against the parent — a defensive win for Sandpiper, but it has no direct claim-cancellation effect on 11,218,566.

Microsoft's own brief in IPR2026-00095 references "the eight patents on which either Google or Microsoft has requested IPR" — i.e., a multi-front campaign across the Sandpiper portfolio. I do not have verified case numbers for the other six, and I will not guess at them. None of the two I can verify is against 11,218,566.

Strategic summary

Claims: CANCELED (0) / SUSTAINED (0) / UNTESTED (all 19 claims). US 11,218,566 B2 issued 2022-01-04 with claims 1–19 (independent claim 1 plus dependents 2–19, per the published application US 2021/0067601 A1). Not one claim has been challenged at the PTAB, so all 19 remain presumptively valid and fully in force. Note the patent is actively being extended: continuations US 11,838,385 B2 (2023) and US 12,284,260 B2 (2025) share the same "Control in a content delivery network" disclosure, so even if this patent were narrowed, the family continues.

Estoppel landscape. Because no petitioner has ever challenged 11,218,566, § 315(e)(2) estoppel is a non-issue for this patent — no one is estopped, and every prior-art ground remains available to a new petitioner. The only practical constraints are the statutory ones: a defendant served with a complaint must file any IPR within one year of service (§ 315(b)), and the Board may discretionarily deny under Fintiv if a parallel district-court trial is scheduled to finish first (the very tool Sandpiper is using against Microsoft in the family IPRs). The Microsoft IPRs also show Sandpiper will fight institution hard — expect discretionary-denial briefing if you file while the E.D. Tex. cases are active.

Pattern signals. This is a classic NPE pattern: Sandpiper CDN, LLC — a Delaware entity formed 2024-03-21 — acquired 80+ Level 3 Communications patents (assignment recorded 2024-04-26) and immediately sued Google (C.D. Cal. 2:24-cv-03951, filed 2024-05-10), Comcast (E.D. Tex. 2:24-cv-00886, filed 2024-11-01), and Microsoft (E.D. Tex. 2:25-cv-00664, filed 2025 — before Judge Gilstrap/Magistrate Payne, amended complaint 2025-10-30). The Google case is stayed pending instituted IPRs. The patent owner is not a defensive aggregator; it is the plaintiff side, and it is litigating aggressively — the Microsoft brief describes it as a 2024 shell acquiring expired and expiring CDN patents. Whether 11,218,566 is among the "Asserted Patents" in any of those complaints is something I could not confirm from the search results, and I won't assume it — check the complaint's asserted-patent exhibits before assuming exposure.

Recommended next steps

1. There is no FWD to cite and no canceled claim to quote. Do not let anyone tell you "claims 1–5 are dead" — they are not. Every claim of 11,218,566 stands. If a demand letter cites it, the troll's case is not defeated by any PTAB record.
2. Verify whether 11,218,566 is actually asserted in the Google, Comcast, or Microsoft suits (check the complaint exhibits). The public excerpts I found name other patents (8,478,903; 8,595,778; 8,645,517; 8,719,886; 9,021,112; 10,924,573 in the Google case) — I could not confirm 11,218,566 in any of them.
3. If you are being asserted against and want an IPR, move fast: the § 315(b) one-year clock runs from service of the complaint. Given the family-member denials/joinder battles, budget for a discretionary-denial fight (opposition to PO's Fintiv request) and consider whether joinder or a coordinated multi-patent petition strategy with other defendants (as Microsoft/Google are doing) maximizes the chance of institution.
4. Monitor IPR2026-00190's outcome on the parent ('053): the Board's discretionary denial there (2026-04-28) and the merits analysis in the Google '903 IPR may preview how the Board treats this family's claims — and the art Microsoft and Google are marshaling against the family is directly reusable against 11,218,566's claims, which are drawn to the same "CDN components obtain control-core data via the CDN rendezvous mechanism" concept.
5. Absence of PTAB activity is itself informative. 11,218,566 issued in January 2022 and has sat unchallenged for over 4.5 years while its owner litigated the portfolio — consistent with either (a) it hasn't been the asserted patent in suit, or (b) challengers have so far focused on the older, foundational patents in the portfolio. That may change quickly if Sandpiper adds it to a complaint.

Caveat on sources: The two proceeding numbers above (IPR2026-00095, IPR2026-00190) come from DocketAlarm and IPVerse/GreyB search results, not from the ODP feed, and both are against different patents (8,478,903 and 9,456,053). If you need the definitive list for a filing, pull the USPTO PTAB E2E docket for "Sandpiper CDN, LLC" as respondent — that will confirm the full campaign, but it will not, based on everything available today, show a proceeding against 11,218,566.

I've gathered the core assignment data from Google Patents legal events, the IPR record (Microsoft v. Sandpiper, IPR2026-00190), and RPX's coverage of the Level 3 → Sandpiper transfer. One transparency note up front: I could not pull the USPTO Assignment Center cover-sheet images themselves, so the correspondent of record on each recording is not confirmed from my sources — I flag that in the relevant sections rather than guessing.

Inventors

All six inventors were employees of Level 3 Communications, LLC (originally Level 3 Communications, Inc.'s CDN engineering group) at the time of the original 2011-2013 filings. They assigned their rights to Level 3 per the family assignment at Reel 030086/Frame 0867 (signing dates 2013-01-23 to 2013-02-26; recorded against the parent application that matured into US 9,456,053, whose chain includes US 11,218,566).

Pattern check: No unusual post-filing exodus — Newton, Fullagar, and others continued filing Level 3 CDN patents through the 2010s-2020s (e.g., US 11,838,385, filed Dec. 2021). The portfolio fire-sale happened at the company level (Lumen/Level 3 exiting CDN in 2023), not via inventor departures.

Original assignee

Level 3 Communications, LLC (Colorado LLC) — named as assignee on the issued patent (per Google Patents and the assignment at Reel 030086/0867).

• Shipped a product embodying the claims? Yes. Level 3 was one of the largest commercial CDN operators in the U.S. for ~15 years (per Sandpiper's own complaints and RPX); the claimed "control in a CDN" architecture was implemented in Level 3's production CDN.
• Line of business: Tier-1 fiber/network operator and commercial CDN provider.
• Current status: Operating — now a wholly owned subsidiary of Lumen Technologies, Inc. (formerly CenturyLink, which acquired Level 3 in 2017). Lumen publicly exited the CDN business in 2023 and sold the CDN patent portfolio (complaint ¶: "Level 3 decided to exit the CDN market in 2023 and began selling off its CDN assets").

Assignment timeline

Two recorded links in the chain (confirmed via Google Patents legal events for this patent and family, and via IPR2026-00190 Ex. 1036 identifying the cover sheet):

1. 2013-01-23 to 2013-02-26 (executed) / recorded ~2013-03 — Reel 030086/Frame 0867

• Conveyance: Assignment (employee-to-employer)
• Assignor: Christopher Newton; Lewis Robert Varney; Laurence R. Lipstone; and others (family-wide cover sheet including Crowder, Koller, Fullagar, Yevmenkin on the related applications)
• Assignee: Level 3 Communications, LLC
• Correspondent: not confirmed from available sources (cover sheet not retrievable in my searches)
• Context: Standard employee-inventor assignment on the original 2011-2012 filings; recorded against the parent application and flowing to continuations including US 11,218,566.

2. 2024-05-31 (effective) / recorded 2024-07-09 — Reel 068256/Frames 0091-0115

• Conveyance: Assignment
• Assignor: Level 3 Communications, LLC
• Assignee: Sandpiper CDN, LLC (Delaware LLC, formed 2024-03-21 per Delaware Division of Corporations filing, IPR2026-00095 Ex. 1020)
• Correspondent: not confirmed from available sources. (Note: Sandpiper's litigation counsel is Shook, Hardy & Bacon L.L.P. per RPX — but that is litigation counsel, not a verified assignment correspondent.)
• Context: Transfer-to-asserter — the terminal link of Level 3's 2023-24 CDN patent portfolio divestiture. RPX reported a batch assignment of "more than 80 US patents" dated 2024-04-24 and recorded 2024-04-26; the USPTO record for this patent (068256/0091) shows effective date 2024-05-31, recorded 2024-07-09 — there may have been multiple cover sheets for the same portfolio sale, and I note the date discrepancy explicitly rather than reconciling it without the primary record.

Not recorded for this patent: No security agreements, no mergers, no change-of-name entries, and no assignment to Optic153 LLC (the 2017 Level 3 → Equitable IP Corp transfer covered a different ~110-patent batch and does not include this 2022-issued patent).

Timeline diagram

timeline
    title Ownership of US 11218566
    2011 : Priority filing by Level 3 inventors
    2013 : Inventors assign to Level 3
    2022 : Patent issued
    2024 : Level 3 assigns to Sandpiper CDN LLC
         : Sandpiper sues Google
         : Sandpiper sues Comcast
    2025 : Sandpiper sues Microsoft

NPE / troll-pattern signals

1. Shell-entity transfer — present.
The patent moved from an operating company (Level 3, a CDN operator) to Sandpiper CDN, LLC, a Delaware LLC formed 2024-03-21 (Delaware filing, IPR2026-00095 Ex. 1020), weeks before its first suit. Sandpiper ships no products and, per its own complaint, is "named after, and in homage to" the defunct 1990s CDN pioneer Sandpiper Networks — a pure portfolio-holding/assertion vehicle. Supporting record: Reel 068256/Frames 0091-0115 (effective 2024-05-31, recorded 2024-07-09).

2. Known asserter in the chain — present.
Sandpiper CDN, LLC is an RPX-tracked repeat plaintiff: Sandpiper CDN v. Google LLC, 2:24-cv-03951 (C.D. Cal., filed 2024-05-10); Sandpiper CDN v. Comcast, 2:24-cv-00886-JRG (E.D. Tex., filed 2024-11-01); Sandpiper CDN v. Microsoft, 2:25-cv-00664 (E.D. Tex., filed 2025-06-26); plus multiple Microsoft and Google IPR petitions (IPR2026-00095, IPR2026-00190, IPR2025-00806/00826/00860, etc.). Google Patents flags the family ("Family has litigation"). Not on the classic Acacia/Marathon/IPNav list, but squarely "surfaced by RPX as a high-frequency plaintiff."

3. Repeat correspondent across the chain — unclear / not verifiable.
I could not retrieve the correspondent-of-record names from the USPTO cover sheets (Reels 030086/0867 and 068256/0091-0115). This is the one signal I cannot score from available data. For completeness: Shook, Hardy & Bacon L.L.P. appears as Sandpiper's litigation counsel (per RPX), which is a recurring NPE-assertion tell, but I will not count it as an assignment-correspondent finding without the cover sheet.

4. Cascading transfers — not present.
Only two links (inventors → Level 3 in 2013; Level 3 → Sandpiper in 2024). No chained LLCs, no multi-hop shell ladder in this patent's chain.

5. Pre-litigation transfer — present.
Sandpiper was formed 2024-03-21; the portfolio assignment for this patent took effect 2024-05-31 (recorded 2024-07-09; RPX reports the batch dated 2024-04-24 recorded 2024-04-26); the first portfolio suit (Sandpiper v. Google) was filed 2024-05-10. The transfer window is within weeks-to-months of the first assertion, i.e., the chain was arranged to enable litigation. Caveat: I could not confirm from my sources that US 11,218,566 itself is a specifically-asserted patent in any complaint (the Google suit asserts six different family patents); the family-level litigation flag and the IPR exhibits confirm the portfolio, not necessarily this exact patent's in-suit status.

6. Bankruptcy fire-sale — not present.
Neither Level 3 nor Lumen is in bankruptcy; this was a strategic divestiture by a solvent operating parent exiting the CDN market.

7. Privateering — unclear.
The complaint frames the sale as an outright divestiture ("Level 3 sold the Asserted Patents to Plaintiff Sandpiper CDN"), not a license-back/revenue-share arrangement, and Level 3 had exited the CDN market — so it is not asserting against direct competitors through a proxy in the classic sense. However, RPX notes this is "not Level 3's first to an NPE" (the 2017 Optic153 LLC / Equitable IP Corp transfer of ~110 patents), showing a corporate pattern of monetizing legacy patents through NPEs. Without the sale agreement, the economic relationship is unverified.

8. Defensive aggregator (anti-NPE) — not present.
The chain terminates at Sandpiper CDN, LLC — an assertor, not RPX/AST/LOT/Unified/OIN.

Verdict

NPE — high confidence.

Three strong signals converge: (1) the patent moved from operating company Level 3 to a newly formed, productless Delaware LLC (Sandpiper CDN, formed 2024-03-21; Reel 068256/0091, effective 2024-05-31, recorded 2024-07-09); (2) Sandpiper is an RPX-tracked repeat plaintiff that filed three CDN-portfolio suits in 13 months (Google 2024-05-10, Comcast 2024-11-01, Microsoft 2025-06-26); and (3) the transfer was timed to enable assertion, closing within weeks of Sandpiper's formation and first suit. The only unverified item — the cover-sheet correspondent — does not change the conclusion, because the shell-entity, known-asserter, and timing signals are independently sufficient.

Verify at the USPTO Assignment Center: https://assignmentcenter.uspto.gov/ (search Patent No. 11218566; records at Reel 030086/Frame 0867 and Reel 068256/Frames 0091-0115).

I'll research the prior art cited against US Patent 11,218,566 by searching authoritative sources for its citation list, then verify each reference.

I found a partial citation list. Let me now retrieve the complete citation list from Google Patents and the USPTO for US11218566B2.

Let me retrieve the complete citation list from the Justia and Google Patents pages for US11218566.

I have reached the search-step limit, so I will now answer directly based on the information gathered, with explicit caveats about what could and could not be verified.

Prior Art Analysis — US Patent 11,218,566 B2 ("Control in a content delivery network")

0. Verification and caveats (read first)

Patent verified. USPTO/Google Patents records confirm US 11,218,566 B2, titled "Control in a content delivery network", application 17/095,325 (continuation), filed Nov. 11, 2020, granted Jan. 4, 2022, priority date Dec. 14, 2011 (chain through 13/714,410 → 9,456,053 → 14/302,865 → 10,814,398 → 17/095,325), inventors Lipstone, Crowder, Koller, Fullagar, Yevmenkin, Newton; original assignee Level 3 Communications, LLC; current assignee Sandpiper CDN, LLC.

Limitations of this analysis (stated honestly):

1. I was unable to retrieve the verbatim claims of the '566 patent. The claim-feature mapping below is therefore at the concept level and is based on (a) the published abstract, (b) the specification supplied, and (c) the parallel family member claims — not verbatim claim language. Do not use this as a substitute for reading the actual claims.
2. I was unable to retrieve the complete, page-by-page citation list from USPTO Patent Center. The uspto.report mirror for grant 11,218,566 returned a partial, alphabetically-ordered list of cited U.S. published applications (beginning at 2002/0010798 through 2006/0047xxx, truncated), plus the specification's incorporated-by-reference patents. The full list is considerably longer (100+ entries, including later publications, foreign documents, and non-patent literature).
3. Where I have high confidence in a reference's title/assignee, I state it. Where I do not, I say so explicitly rather than guessing.

1. The claimed invention (working model for the § 102 analysis)

The abstract (and family) describe a CDN in which:

• the CDN comprises multiple components, including at least one rendezvous mechanism and at least one control core;
• the components are controlled by control core data from the control core;
• some CDN components obtain CDN resources (including control core data) from other CDN components (not only from the control core); and
• the components use the CDN rendezvous mechanism to select which CDN component(s) to obtain those resources from.

The specification elaborates: control core data (e.g., the Global Configuration Object "GCO", Customer Configuration Scripts "CCSs", HostTable/ClusterTable data) are treated as ordinary web objects addressable by URL; caches pull such data from peer/parent caches; the CDN's own DNS-based rendezvous (e.g., control.fp.net) selects the "best" control-core machine; caches register with the control core and warm up from neighbors; control core itself is an "origin" for CDN configuration content.

Under § 102, a single reference anticipates a claim only if it discloses every limitation. Given the multi-component combination in the independent claims, most citations are realistically § 103 combination references; the "potentially anticipates" assessments below indicate where a single reference comes closest to disclosing the full combination.

2. Specification-incorporated references (appear in the '566 patent's own text and on the citation record)

These are the highest-relevance references because the specification expressly relies on them for core architecture features:

3. Examiner-cited published applications (partial list from uspto.report for grant 11,218,566)

The uspto.report citation list begins as follows (listed alphabetically by publication number). I have high-confidence descriptions only where marked; the rest require verification:

Two additional references confirmed via Google Patents "Cited By" cross-references during this analysis:

• US 2012/0290911 A1, "Method for Content Folding," Zhao (Telefonaktiebolaget LM Ericsson), published Nov. 15, 2012 (application filed by Leon Zhao; the '566 patent appears in that application's citation trail) — relevant to content folding/optimization in CDN delivery; note the 2012 publication date is after the '566 priority date (Dec. 14, 2011), so this reference is not § 102 prior art — it would only be relevant to later-filed claims, if at all.
• US 2003/0115283 A1 (Barbir, above) — confirmed by search snippet as "Content request routing method."

4. Most relevant prior art — ranked

For the claimed combination ("CDN components controlled by control core data; some components obtain CDN resources including control core data from other CDN components; rendezvous selects the component to obtain from"), the strongest single-reference candidates are:

1. US 6,185,598 B1 (Farber/Digital Island) — foundational CDN + DNS rendezvous + distributed caches; closest to the overall claimed architecture. Highest anticipation potential for the architecture-level independent claim, subject to whether the "control core data obtained from other CDN components" limitation reads on its disclosure.
2. US 7,822,871 B2 (Swildens) — configurable adaptive global traffic control; closest on the rendezvous/selection limitations.
3. US 2005/0010653 A1 (McCanne) — scalable dynamic content delivery with feedback; closest on dynamic control data distributed through the delivery system.
4. US 2002/0091801 A1 (Lewin) and US 2003/0115283 A1 (Barbir) — request routing in distributed delivery systems; closest on the request-routing/selection limitations.
5. US 2004/0073596 A1 (Kloninger) — dynamic modification of CDN; closest on configuration being pushed/controlled centrally.
6. US 8,015,298 B2 (Yevmenkin) — cache cluster structure of the CDN components themselves.

Realistic § 102 outcome: no single reference in the verified set appears to disclose the entire combination (rendezvous + control core + control-core-data-as-CDN-content + component-to-component acquisition). The examiner's citations are most plausibly deployed in § 103 combinations (e.g., Farber '598 or Swildens '871 in view of McCanne '0653 / Kloninger '3596 for the control-data-distribution limitation). Any true single-reference anticipation argument would need to be tested against the verbatim claims, which I could not retrieve.

5. Recommended verification steps (required before reliance)

1. Pull the verbatim claims of US 11,218,566 B2 from USPTO Patent Center or Google Patents (Claims tab) — the claim-feature mapping above is concept-level only.
2. Pull the complete "Patent Citations" tab on Google Patents for US11218566B2 (the examiner-cited list is far longer than what I retrieved; my partial list stops at ~40 of 100+ entries).
3. Confirm titles/assignees for the unverified entries (2002/0010798, 2002/0116583, 2002/0120717, 2002/0141592, 2002/0161823, 2002/0165727, 2002/0174168, 2002/0174227, 2002/0184357, 2003/0028594, 2003/0065708, 2003/0115421, 2003/0135509, 2003/0140111, 2003/0154090, 2003/0158913, 2003/0200283, 2003/0217139, 2004/0068622, 2004/0162871, 2004/0167960, 2004/0193656, 2004/0215757, 2004/0230797, 2005/0086348, 2005/0086386, 2005/0160429, 2005/0177600, 2005/0188073, 2005/0190775, 2005/0192995, 2005/0289388, 2006/0031441, and all post-2006 entries).
4. For any § 102 argument, compare each reference against every limitation of the specific claim at issue — I have flagged where a reference covers only a subset.

Key takeaway: The '566 patent's core innovation — treating control core configuration data itself as CDN content distributable among CDN components and selectable via the CDN's own rendezvous mechanism — is the limitation most likely to survive single-reference anticipation; the strongest challenges will come from Farber '598 (architecture), Swildens '871 (rendezvous), and McCanne '0653 (dynamic control-data distribution), with the decisive issue being whether any single one of them discloses configuration data being fetched from peer CDN components via the CDN rendezvous system rather than directly from the control/origin core.

I'll start by noting that the user message references a "Prior Art section of this page," but the provided text does not include such a section. I'll search for the patent's cited prior art and related references, then construct the § 103 analysis.

The prior art section referenced in the task wasn't included in the message, so I'm gathering the relevant references myself. I've identified several strong candidates already. Let me dig deeper into the examiner-cited references and the key CDN prior art.

Preliminary notes on sources and scope

Missing "Prior Art section." The task instructs me to use "the results from the Prior Art section of this page," but no prior-art section was included in the message (the message contained only the patent summary and litigation summary). I therefore supplemented with targeted web searches of the examiner-cited references and the leading CDN prior art. Everything below is grounded in the search results and the patent specification; where a fact is uncertain, I say so.

Claim text caveat. I could not retrieve the verbatim claims of US 11,218,566 from my search results. The analysis below therefore maps prior art to the invention as defined by the published abstract and the specification's disclosed embodiments (GCO/CCS distribution, caches pulling control data from peer caches, DNS/rendezvous-based selection of CDN components, control core as "origin server" for CDN data). A claim-by-claim chart should be re-run against the actual claim language before reliance in litigation.

Applicable law. The '566 patent is a continuation in a family whose earliest non-provisional application (US 13/714,410, issued as US 9,456,053) was filed December 14, 2012 — before the March 16, 2013 AIA transition. Pre-AIA 35 U.S.C. § 103 applies. All references discussed below published before the December 14, 2011 priority date and qualify as prior art under pre-AIA §§ 102(a)/(b)/(e).

Legal standard

Obviousness under § 103 is assessed under Graham v. John Deere, 383 U.S. 1 (1966): (1) scope and content of the prior art; (2) differences between the prior art and the claims; (3) level of ordinary skill; (4) secondary considerations. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), permits a finding of obviousness where a PHOSITA had a reason to combine known elements with a reasonable expectation of success — including "common sense" combinations of prior-art elements each performing its known function, and the predictable application of a known technique to a known problem.

Person of ordinary skill in the art (PHOSITA). A person with a bachelor's degree in computer science or electrical engineering (or equivalent experience), roughly 2–4 years' experience designing distributed Internet systems — specifically content delivery networks, HTTP caching, DNS-based request routing, and large-scale configuration management — and familiarity with the CDN literature (e.g., Danzig et al. hierarchical caching, Akamai/Digital Island/Limelight CDN patents).

Scope of the claimed invention (as understood from the abstract and specification). The invention is a CDN in which: (a) CDN components include at least one rendezvous mechanism and at least one control core; (b) the components are controlled by control core data (e.g., a Global Configuration Object, GCO, and Customer Configuration Scripts, CCSs); (c) some CDN components obtain CDN resources — including control core data — from other CDN components (peer/parent caches), not only from the control core; and (d) the components use the CDN rendezvous mechanism to select which CDN component(s) to obtain those resources from. The specification itself concedes the building blocks were known: caches "may obtain the needed global data ... from a data source, preferably from a control core or from another cache"; internal components "may use the same rendezvous mechanisms as are used by entities outside the CDN"; and the control core may be treated as an "origin server" for CDN control data.

Prior art references

Obviousness combinations and motivation

Combination 1 (strongest): R1 (Akamai tiered distribution, US 2008/0222281 / US 7,603,439) + R3 (Akamai metadata transmission, US 7,240,100 / R1's own metadata system)

Limitation map. R1 discloses a CDN with multiple components (edge servers, parent/core regions) and a DNS rendezvous mechanism; on a cache miss an edge component obtains the resource from another CDN component (a parent region) rather than the origin, with the parent identified by metadata and selected via the CDN's DNS request-routing mechanism. R3 discloses CDN components controlled by control data — per-customer configuration metadata delivered from a control server through staging servers to content servers over HTTP.

The gap. What R1/R3 together do not expressly say is that the control data itself (the configuration/metadata) is distributed through the CDN cache hierarchy and fetched by caches from peer/parent caches using the rendezvous mechanism.

Why a PHOSITA would combine. The motivation is textbook KSR reasoning:

1. Same problem, same solution, different object. R1's stated purpose is to "insulate a content provider origin server from excessive traffic" by having edge servers fetch from intermediate CDN nodes. A CDN engineer reading R1 and R3 would immediately recognize the control/staging servers of R3 as the same kind of bottleneck as an origin server — indeed, the '566 spec itself adopts exactly this framing ("the control core may be considered to be an 'origin server'"), and admits the benefit is to "reduce direct load on the control core and accelerate retrieval." Applying the known cache-hierarchy fill technique to the known metadata-distribution problem is the predictable use of a known technique for a known purpose.
2. Configuration files are just HTTP resources. R3 already delivers metadata as files over HTTP servers; R1 already teaches edge servers fetching resources over HTTP from parents. Treating the metadata file as an ordinary cachable resource, subject to the same hierarchy and DNS rendezvous, requires no new insight — it is the direct combination of two disclosed mechanisms.
3. Rendezvous is requester-agnostic. R1/R2/R8 all use DNS-based selection for both end-user requests and server-to-server requests (R2's edge server does a DNS lookup for the map; R8's edge server resolves storage URLs). A PHOSITA had an explicit reason to reuse the same rendezvous for internal fetches — the '566 spec concedes internal components "may use the same rendezvous mechanisms as are used by entities outside the CDN."
4. Reasonable expectation of success. Every element (cache hierarchy, DNS rendezvous, HTTP config delivery, peer fills) was proven, commercially deployed technology by 2011 (Akamai FreeFlow; Speedera; Level 3/Savvis repeater networks).

Combination 2: R4 (Farber et al., US 2008/0215735, "Resource invalidation in a CDN") + R5 (Level 3 rendezvous patents, US 7,822,871 / US 7,860,964)

Limitation map. R4 is directly on point for "some CDN components obtain CDN resources from at least some other CDN components": its repeater server, on a request for an invalidated resource, obtains the resource "from another location in the CDN." R5 discloses the DNS-based, policy-driven rendezvous mechanism for selecting CDN components. R4 is in the same corporate lineage as R5 and the '566 itself (Level 3/Savvis), and the '566 specification incorporates R5 by reference.

Why combine. R4 tells the PHOSITA that a CDN server can fetch from another CDN location; R5 tells the PHOSITA how the CDN selects among locations (DNS/policy-based rendezvous). The combination — using the rendezvous mechanism to select which CDN component to fetch CDN resources from — is an implementation detail, not an inventive leap. The '566 spec's own description of FIG. 15C (caches pulling control data from the control core and from peers via HTTPS) is a straightforward embodiment of this combination. Note also that R4, being a Level 3-family reference cited by the examiner, would be prime material for a § 103 ground: if the examiner allowed the claims over R4 and R5 individually, the argument is that the combination was not considered.

Combination 3: R6 (Speedera WO 2002/007012) + R3 (Akamai metadata distribution) or R7 (Weller)

Limitation map. R6 discloses a CDN where the CDN's own operational data — server log files — is treated as data transported over the CDN's HTTP infrastructure and collected by a log server, with a DNS-based (SPD) mechanism directing requests to selected caching servers. R3/R7 disclose configuration metadata distributed from a control server to content servers. Together: CDN components controlled by control data (R3/R7), CDN components obtaining CDN resources (including internally generated data such as logs, and by extension configuration) from other CDN components (R6's log collection; R1's peer fills), and a DNS rendezvous used for selection (R6's SPD; R5).

Why combine. R6 already embodies the "CDN as its own customer" concept for logs — the very concept the '566 spec describes ("the inventors realized that logs can be treated as ordinary cache resources, retrievable via HTTP..."). Extending the same treatment to configuration objects (GCO/CCS) is an obvious generalization: both are internally generated, cacheable, HTTP-addressable objects. A PHOSITA with R6 and R3 in hand would have a documented reason — reducing control-server load and accelerating cache warm-up (the '566 spec's "warming phase") — to push configuration through the same channels.

Combination 4: R2 alone (Akamai optimal route selection, US 2002/0163882) or R2 + R1

Limitation map. R2 alone discloses nearly the entire claimed architecture in embryonic form: an edge server performs a DNS lookup to fetch control data (a route map) published by a mapmaker (a control-type component), and then fetches content through intermediate CDN servers (i.e., from other CDN components). Add R1's hierarchy and R3's config distribution, and the "control data as distributable CDN content, selected via rendezvous" concept is fully assembled.

Why combine. R2's map fetch is precisely "obtaining CDN resources including control core data ... using the CDN rendezvous mechanism to select ... CDN components." The mapmaker is a control core; the map is control data; the DNS lookup is the rendezvous. The only delta to the '566 concept is that the map is fetched from the mapmaker rather than from a peer cache that cached it — and R1's hierarchy teaches exactly that delta (fetch from a parent instead of the source). Combining R2's map-fetch with R1's hierarchy gives a system in which caches obtain control data from other caches selected via DNS.

Anticipated non-obviousness arguments and rebuttals

Bottom line

The core claim concept — CDN components (caches) obtaining CDN resources, including control core data, from other CDN components, with the CDN's DNS rendezvous mechanism selecting the source component — is a predictable combination of well-known CDN building blocks, each documented well before the December 14, 2011 priority date:

• Cache hierarchy / peer-parent fills (R1; Danzig et al.; R2; R4);
• DNS/rendezvous-based component selection (R1, R2, R5, R6, R8);
• Control/configuration data distributed from a control server to edge servers (R3, R7).

The strongest § 103 ground is R1 + R3 (Akamai tiered distribution + Akamai metadata transmission), optionally supplemented with R5 (Level 3 rendezvous) and R6 (Speedera), because the combination maps onto every element of the abstract and the specification's own embodiments, and the motivation (reduce control-core load; accelerate retrieval; reuse DNS rendezvous) is articulated in the '566 specification itself. A defendant (or IPR petitioner, e.g., in the Sandpiper campaign context) would have a credible obviousness position; the principal open question is the exact scope of the independent claims, which I could not verify verbatim and which should be checked before finalizing any invalidity chart.

Sources: Google Patents (US11218566B2; US9456053B2; US201202216482; family pages), uspto.report/patent/grant/11,218,566 (examiner-cited reference list), Unified Patents portal (US-7603439-B2; WO-2002007012-A2), patentsencyclopedia.com (US 2008/0222281 full text), uspto.report (US 2002/0163882; US 2002/0143798; US 7,376,727), patentimages.storage.googleapis.com (US20080215735A1 PDF), Espacenet (US2008215735A1), CourtListener (Akamai v. Limelight; Sandpiper v. Microsoft dockets), Finnegan/Akamai appellate brief (Farber '598/Footprint 1.0 history).