US 10924573

I'll search for information on US patent 10924573, including any CAFC 2026 docket activity.

Let me search further for the CAFC docket activity and the related litigation involving this patent.

US Patent 10924573 — Summary

Bibliographic data

Prosecution lineage: The '573 patent is a continuation of US 15/645,584 (US 10,218,806), which is a continuation of US 12/880,324 (US 9,762,692), which is a continuation-in-part of US 12/408,681 (US 8,930,538), which claims priority to Provisional 61/042,412 (filed 2008-04-04).

Abstract (verbatim from the patent)

A content delivery network has at least a first tier of servers. A content delivery method includes, at a first server in the first tier of servers, obtaining a request from a client for a resource. If the resource is available at the first server or at a peer of the first server, then the resource is served to the client from the first server. Otherwise, it is determined whether the resource is popular, and if the resource is determined to be popular, then the first server obtains the resource and the first server serves the resource to the client. If the resource is determined not to be popular, the client is directed to a second server, not in the first tier of servers, and the second server serves the resource to the client. The second server may be in a second tier of servers or it may be an origin server.

Plain-language overview of the independent claims

Claim 1 (method): A method in which an edge server (a first server in a first tier of the CDN) receives a client's request for a resource. The edge server consults a "popularity service" to get a popularity designation for the resource. It requests the resource from a second server (e.g., a mid-tier/parent server). The second server returns a redirect instruction, which the edge server processes to obtain the resource from a content server (e.g., an origin or parent). Critically, the edge server also receives an instruction not to cache the resource at the edge when it obtains it from the content server. The edge server then provides the obtained resource to the requesting client. In short: long-tail (unpopular) content is fetched through the edge but is not stored at the edge.

Claim 11 (system): A content delivery network comprising a first tier of edge servers and a second tier of servers. An edge server receives a client request; a first server in the second tier receives the edge server's request for the content and responds with (i) a redirect instruction intended for the requesting device (directing it to obtain the resource from a content server) and (ii) an instruction not to cache the resource at the edge server. A popularity service tracks a popularity designation for the resource. The edge server processes the redirect, obtains the content from the content server, and provides it to the requesting device.

Claim 19 (method): Similar to claim 1, but the popularity service is associated with the first (edge) server itself. The edge server receives the client's request, accesses the popularity service to determine the resource's popularity designation, receives an instruction not to cache the resource at the edge when it is obtained from the content server, requests the resource from a second server based at least on the popularity designation, and provides the obtained resource to the requesting device.

The key distinguishing feature across all three independent claims is the "instruction to not cache" the resource at the edge server when the resource is obtained from a content server — i.e., serving long-tail content through the edge without populating the edge cache.

Litigation / PTAB / CAFC status (as of April 26, 2026)

• District court: Sandpiper CDN, LLC v. Google LLC, No. 2:24-cv-03951 (C.D. Cal., filed 2024-05-10) — listed on the patent's Google Patents "litigation" flags as a related matter.
• IPR2025-00860 (Google LLC v. Sandpiper CDN, LLC): Petition filed 2025-05-01 challenging all claims 1–20 of the '573 patent. Grounds: (1) anticipation by U.S. Pub. App. 2016/0094471 ("Newton-471"), and (2) obviousness over Dilley (US 7,133,905) in view of Pai (US 2006/0271972) and Wang (US 2005/0198250). The PTAB granted institution on all challenged claims and all grounds (Paper 15, institution decision — dated November 25, 2025, per the Docket Alarm exhibit copy). The central dispute is whether the "instruction to not cache" limitation was new matter added in the 2019 continuation application, which would strip the patent of its 2008 priority date and make Newton-471 (published 2016) available as prior art.
• IPR2026-00095 (Microsoft Corporation v. Sandpiper CDN, LLC): An active PTAB proceeding in which the Google institution decision was filed as an exhibit (Feb. 13, 2026); this appears to be a related IPR involving the same patent family, but I could not confirm from the search results whether it challenges the '573 patent itself.

Uncertainty notes

• CAFC 2026 docket: My searches for a Federal Circuit appeal docket for 10924573 returned no results. I did not find any CAFC appeal (e.g., an appeal of the district court case or a § 314/§ 315 appeal) as of today. If a CAFC appeal exists but is not yet indexed, I could not confirm it.
• The IPR2025-00860 institution decision date is reported inconsistently in search snippets (one source suggests the decision itself is dated Nov. 25, 2025, while another appears to date the exhibit filing in the IPR2026-00095 case to Feb. 13, 2026). I have high confidence that institution was granted for all claims 1–20, but the precise decision date should be verified against the PTAB docket if needed.
• Whether IPR2026-00095 (Microsoft) challenges the '573 patent (vs. a related Sandpiper patent) was not confirmed from the available snippets.

If you need verification of the exact CAFC status or the IPR2026-00095 patent number, I'd recommend a direct check of the PACER Federal Circuit docket and the PTAB's API/docket (PTACTS) — my searches did not surface a CAFC appeal for this specific patent number.

I'll research litigation involving US Patent 10924573 by searching several sources.

Initial searches returned unrelated results. Let me search more specifically for the known litigation indicators from the patent's Google Patents page.

I found strong leads. Let me dig deeper into the district court case and the IPR proceedings.

Known Litigation Involving U.S. Patent 10,924,573

Based on my research, US Patent 10,924,573 B2 ("Handling long-tail content in a content delivery network (CDN)") is currently involved in at least the following proceedings:

1. Sandpiper CDN, LLC v. Google LLC — No. 2:24-cv-03951 (C.D. Cal.)

• Plaintiff: Sandpiper CDN, LLC (current assignee of the '573 patent; formerly Level 3 Communications, LLC)
• Defendant: Google LLC
• Jurisdiction: U.S. District Court for the Central District of California (Western Division)
• Case number: 2:24-cv-03951-AB (RAO) (originally 2:24-cv-03951-PSG-RAOx)
• Filing date: May 10, 2024
• Patents-in-suit: Six patents, including U.S. Patent 10,924,573 (per the Google Patents litigation flags; the complaint also asserts other Sandpiper/Level 3 CDN patents, e.g., the '903 and '778 patents)
• Accused products: Google's CDN services — Google Cloud CDN, Google Media CDN, Google Cloud DNS, YouTube, and YouTube TV (Compl. ¶¶27–28)
• Status / key developments:
  • Case initially assigned to Judge Philip S. Gutierrez; reassigned to Judge André Birotte Jr. (order dated October 22, 2024).
  • Google's motion to dismiss Counts II and IV was granted with prejudice (ECF No. 28, Sept. 16, 2024); Google answered and demanded a jury (ECF No. 30, Sept. 30, 2024).
  • Trial was originally set for September 28, 2026.
  • Most recent status: On January 22, 2026, the court granted the parties' stipulation and stayed the action until final resolution (including appeals) of Google's IPRs — IPR2025-00806, IPR2025-00826, IPR2025-00860, IPR2025-00969, and IPR2025-01010 — and vacated all case-management deadlines, including the trial date (ECF No. 93). The case is therefore open but stayed.

2. Google LLC v. Sandpiper CDN, LLC — IPR2025-00860 (PTAB)

• Petitioner: Google LLC (sole real party in interest, per the institution decision)
• Patent Owner: Sandpiper CDN, LLC
• Patent challenged: U.S. Patent 10,924,573 B2 (the '573 patent)
• Forum: USPTO Patent Trial and Appeal Board (PTAB)
• Filing date: 2025 (petition; exact filing date not confirmed in my sources)
• Status: Instituted — pending. The Board's Institution Decision (Paper 15, dated November 25, 2025) found a reasonable likelihood that Google would prevail on at least one claim and instituted inter partes review as to all challenged claims of the '573 patent and all asserted grounds. Patent Owner's request for discretionary denial was denied (Paper 14).
• Related matter identified in the decision: Sandpiper CDN, LLC v. Google LLC, No. 2:24-cv-03951 (C.D. Cal.).

3. Possibly related PTAB proceeding — Microsoft Corporation v. Sandpiper CDN, LLC, IPR2026-00095

• Petitioner: Microsoft Corporation; Patent Owner: Sandpiper CDN, LLC (PTAB)
• This proceeding (petition materials dated February 13, 2026) cites the IPR2025-00860 institution decision for the '573 patent (as Exhibit 1034) and exhibits from the Google district court case. I could not confirm from the available search results whether IPR2026-00095 itself challenges US 10,924,573 or a different Sandpiper CDN patent. I flag it only as a related PTAB matter involving the same patent owner that references the '573 patent's IPR decision.

Summary Table

Caveats: My searches were constrained, and I could not pull the full PACER docket for the district court case or the complete PTAB records. The filing date of IPR2025-00860 and the precise list of all six patents-in-suit in the Google case (beyond the '573 patent, which is confirmed) were not fully verified from primary dockets. The RPX Insight listing shows "6 Patents-in-Suit" for the Google case, and the Google Patents page specifically flags US 10,924,573 as having litigation in that California Central District Court case.

The structured PTAB block reports no proceedings, but the Google Patents page flags IPR2025-00860 and web search already surfaced a second one (IPR2026-00095, Microsoft). Let me dig into both.

IPR2025-00860 (Google) is confirmed — instituted on all claims 1–20 and all grounds. IPR2026-00095 (Microsoft) appears to be on a different patent (8,478,903), not the '573. Let me verify there are no other IPRs on the '573 patent and check the current status/posture of IPR2025-00860.

Proceedings overview

The USPTO ODP structured data on file shows zero AIA trial proceedings for US 10,924,573 as of its most recent ingest — but that ingest is stale. Web search confirms one live proceeding: IPR2025-00860 (Google LLC v. Sandpiper CDN, LLC), which the Google Patents litigation metadata also flags ("PTAB case IPR2025-00860 filed (Pending - Instituted)"). Status breakdown: 1 instituted/pending, 0 claims invalidated, 0 claims sustained, 0 settled, 0 institution denied. Bottom line for a defendant: this patent is currently in the crosshairs — the Board instituted on all 20 claims and every ground on 2025-11-25, but no Final Written Decision has issued yet, so no claims are dead and the patent is not yet "hardened" or "narrowed." The single most dangerous issue in play is Google's priority-date attack, which, if successful, could take down all 20 claims at once.

IPR2025-00860 — Google LLC v. Sandpiper CDN, LLC

• Type: Inter Partes Review
• Filed: 2025-05-01 (petition accorded filing date; per PTAB docket aggregators — the ODP block does not yet list this case)
• Status: Instituted — trial pending (Google Patents metadata: "filed (Pending - Instituted)"). No Final Written Decision as of 2026-08-26; the statutory FWD deadline is 2026-11-25 (one year from institution).
• Judge panel: Mitchell G. Weatherly, Sheila F. McShane, and Michael T. Cygan, APJs (McShane authored the Institution Decision). The pre-institution discretionary-denial referral was decided by Acting Chief APJ Kalyan K. Deshpande (Paper 14, 2025-10-10; Deputy Director Coke Morgan Stewart recused).
• Petition grounds — all claims 1–20 challenged:
  • Ground 1 — Anticipation (§ 102) by Newton-471 (US 2016/0094471, published 2016), contingent on a priority-date challenge: Google argued the "instruction to not cache" limitation central to the allowed claims is new matter added in the 2019 continuation (16/284,791), so the '573 patent is not entitled to its claimed 2008-04-04 priority date; with an effective filing date in 2019, Newton-471's 2016 publication becomes anticipating prior art. Google's expert: Todd Mowry, Ph.D.
  • Ground 2 — Obviousness (§ 103) over Dilley (US 7,133,905) in view of Pai (US 2006/0271972) and Wang (US 2005/0198250) — Dilley for the tiered CDN architecture, Pai for the dynamic popularity service/thresholds, Wang for the "instruction to not cache" cache-control attribute.
• Institution decision: Granted in full — Paper 15, 2025-11-25. The Board instituted "inter partes review as to all of the challenged claims of the '573 patent and all of the asserted grounds of unpatentability in the Petition," finding Google established "a reasonable likelihood that it would prevail with respect to at least one claim." Sandpiper's earlier request for discretionary denial (Fintiv timing + § 325(d), Papers 6/9/11/12) was denied by the Director's delegate on 2025-10-10, which noted the '573 patent "has not been in force for a significant period of time (issued in 2021)" and that Sandpiper "has not developed strong settled expectations." Related matter identified by the parties: Sandpiper CDN, LLC v. Google LLC, No. 2:24-cv-03951 (C.D. Cal., filed 2024-05-10), which the district court has partially stayed pending resolution of the IPRs (fact/expert discovery stayed; claim-construction schedule pushed past the institution decisions).
• Final Written Decision: None yet. Institution was 2025-11-25, so the FWD is due on or before 2026-11-25 (35 U.S.C. § 316(a)(11); possible 6-month extension for good cause). No claim has been canceled or sustained on the merits.
• Settlement / termination: None. No settlement papers on the public docket.
• Appeal: None. No FWD exists to appeal; no CAFC docket number for this patent.
• Defensive value: No claims are dead yet, but this is the single highest-stakes IPR on the patent — all 20 claims and both grounds were instituted, including the priority-date/new-matter attack that could invalidate the entire patent in one stroke if the Board agrees the "instruction to not cache" limitation lacks written-description support in the pre-2019 chain (12/408,681 → 12/880,324 → 15/645,584). A defendant sued today should treat the FWD (due ~2026-11-25) as the pivotal milestone and should not assume an IPR defense is foreclosed: unless you are Google or in privity with it, you are not estopped from using the same art. Sources: Institution Decision (Paper 15) and Referral Decision (Paper 14, ptacts.uspto.gov), plus the Unified Patents case page.

Strategic summary

Claims status — CANCELED / SUSTAINED / UNTESTED. As of 2026-08-26, no claim of the '573 patent has been canceled and no claim has been sustained on the merits — the only IPR on the patent (IPR2025-00860) is mid-trial with institution on claims 1–20 and both grounds. Every claim is therefore "under active challenge" rather than untested in the usual sense; the entire claim set is exposed to the Newton-471 priority-date ground and the Dilley/Pai/Wang obviousness ground. If the Board rules for Google, all 20 claims fall together; if it rules for Sandpiper, the patent emerges validated on the exact "instruction to not cache" limitation that got it allowed — making later IPRs on similar art materially harder.

Estoppel landscape. Under 35 U.S.C. § 315(e)(2), once the FWD issues, Google (and its privies) will be barred from raising in any later PTAB proceeding any ground it raised or reasonably could have raised in IPR2025-00860 — i.e., Newton-471 anticipation and the Dilley/Pai/Wang combination, plus any obvious variants. That estoppel does not bind a new, unrelated defendant. A defendant being freshly asserted against can still deploy Newton-471 and Dilley/Pai/Wang, and can also develop different art Google didn't raise. One practical wrinkle: the "reasonable could have raised" net is broad for Google itself, so Google's § 315(b) one-year window (from service of the C.D. Cal. complaint) has long closed for new grounds, while a new defendant's own one-year clock starts from its own service date.

Pattern signals. This is not an isolated attack — it is one front in a coordinated, multi-patent offensive by defendants against the Sandpiper CDN (formerly Level 3 Communications) portfolio. Google alone filed at least five IPRs against Sandpiper (IPR2025-00806, -00826, -00860 ['573], -00969 ['903], -01010 ['322]), with the Director denying Sandpiper's discretionary-denial requests across the set. Microsoft separately filed IPR2026-00095 — but on the related '903 patent (8,478,903), not the '573 — and even used the same expert (Dr. Todd Mowry) and exhibits drawn from the Google IPRs, including a joinder motion referencing "the Google IPR." Sandpiper is asserting the family in multiple districts (Sandpiper v. Google, 2:24-cv-03951 C.D. Cal.; Sandpiper v. Microsoft, 2:25-cv-00664 E.D. Tex.; Sandpiper v. Comcast, 2:24-cv-00886 E.D. Tex.), and the C.D. Cal. case is partially stayed pending the IPRs. The patent owner has fought institution hard (Fintiv and § 325(d) requests — all denied) but has not settled any of these cases. Unified Patents appears in the metadata as the litigation-tracking data source, not as petitioner — the RPI in IPR2025-00860 is Google LLC.

Recommended next steps

• No claims are canceled yet — do not tell a client (or a court) that this patent is dead. The correct framing today: "All 20 claims are the subject of a fully-instituted IPR, with the FWD due on or before 2026-11-25." If you are a defendant in the C.D. Cal. action (or a new defendant elsewhere), the highest-value near-term move is a motion to stay pending IPR2025-00860 — the C.D. Cal. court has already shown willingness to partially stay this exact patent's litigation pending these IPRs.
• Preserve your own IPR rights. If you are not Google (or its privy), the § 315(b) one-year bar runs from service of your complaint. If you were served recently and want independent art, file before the bar. If your window is closed or closing, you can still ride Google's IPR result (no estoppel for you), and you can press the priority-date/new-matter argument in district court — it is the strongest lever in the file, and it is fully developed in the Google petition (Ex. 1001 chain: 16/284,791 → 15/645,584 → 12/880,324 → 12/408,681 → provisional 61/042,412, versus Newton-471's 2016 publication).
• Track the FWD deadline. Institution: 2025-11-25 → statutory FWD due 2026-11-25 (extendable to ~2027-05-25 for good cause). Watch the PTAB docket for the oral-hearing notice and the FWD; a Google win means all claims 1–20 canceled and the C.D. Cal. case collapses on the '573, while a Sandpiper win produces a § 315(e)(2) estoppel only against Google — not against you.
• Caveat on the record. The ODP structured data reports no proceedings because its ingest predates IPR2025-00860; treat the search-surfaced docket as authoritative and verify current status on PTAB E2E / PTACTS or the Unified Patents docket before any filing that depends on it. No FWD, settlement, or CAFC appeal exists as of 2026-08-26 — do not represent otherwise.

I'll research the assignment chain for US 10924573, cross-referencing USPTO records, litigation, and NPE directories. Let me start with several parallel searches.

I have strong leads: the Level 3 → Sandpiper CDN assignment (Reel 068256/Frames 0091-0115) and litigation against Google, Microsoft, and Comcast. Let me dig into the earlier inventor→Level 3 assignment, the entity behind Sandpiper CDN, and the IPR record.

I have enough verified information to reconstruct the chain. Note on method: I could not reach the USPTO Assignment Center directly; the entries below are triangulated from Google Patents legal-event records, the PTAB record (Microsoft IPR exhibits), and RPX/Unified Patents coverage. Where a field (e.g., correspondent of record) could not be confirmed, I say so rather than guess.

Inventors

All three inventors are named on the issued patent (front page: "Newton et al.," US 10,924,573 B2):

• Christopher Newton — Thousand Oaks, CA. Level 3 Communications CDN leadership (long-time CDN executive in the Sandpiper/Digital Island→Savvis→Level 3 lineage). Continued filing Level 3 CDN patents through at least 2014.
• Laurence Lipstone — Calabasas, CA. Level 3 CDN engineering; co-inventor on many Level 3 CDN-family patents through 2014.
• David Fullagar — Boulder, CO. Level 3 CDN engineering.

Pattern note: No "inventors-depart-within-12-months" pattern — all three remained with Level 3 (then Lumen) for years after the 2008 priority filing. The portfolio fire-sale came ~16 years later, driven by Lumen's corporate exit from the CDN market, not by inventor flight.

Original assignee

• Level 3 Communications, LLC (Broomfield, CO) — the entity named as applicant/assignee on the issued patent.
• Product: Yes. Level 3 was one of the largest US CDN operators; this patent's long-tail popularity-management technique was embodied in Level 3's production CDN. The complaint in Sandpiper CDN v. Google recounts Level 3 operating "one of the foremost CDN operators in the United States" on the foundation of these patents.
• Line of business: Tier-1 fiber/telecom and content delivery network services.
• Current status: Still an existing legal entity — a subsidiary of Lumen Technologies, Inc. (f/k/a CenturyLink, which acquired Level 3 in 2017). Lumen wound down/divested the CDN business (CDN contracts sold to Akamai in 2023) and sold 80+ US patents to Sandpiper CDN, LLC in 2024. The '573 patent remains in "Active" status, anticipated expiration 2029-03-21.

Assignment timeline

Two recorded ownership events are confirmed for US 10924573. No security agreements, mergers, or name changes affecting this patent were surfaced in my sources.

• 2019-02-25 (filing) / recorded 2019-02-26 — Reel/frame not retrievable from my sources (event confirmed via Google Patents legal-event record; the reel/frame is on the Assignment Center cover sheet for the continuation filing)

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: Christopher Newton, Laurence Lipstone, David Fullagar
  • Assignee: Level 3 Communications, LLC
  • Correspondent: not confirmed
  • Context: Standard inventor→employer assignment at filing of the continuation application (US 16/284,791).

• 2024-04-24 (executed) / recorded 2024-04-26 — Reel 068256 / Frames 0091–0115

  • Conveyance: Assignment (blanket assignment of 80+ US patents; cover sheet in the PTAB record as Microsoft IPR2026-00190 EX1036 and IPR2026-00095 EX1021)
  • Assignor: Level 3 Communications, LLC
  • Assignee: Sandpiper CDN, LLC (Delaware LLC formed 2024-03-21; parent Theseus LF Asset Holdings, LLC, Delaware, formed 2023-08-25)
  • Correspondent: not confirmed from my sources (the recorded cover sheet at reel 068256 would show the correspondent of record; I will not speculate)
  • Context: Transfer-to-asserter — Lumen's CDN patent monetization after exiting the CDN market; the complaint states the sale closed 2024-03-29, and the first infringement suit was filed 2024-05-10.

If the Assignment Center shows additional entries (e.g., a 2017-era Lumen re-organization or security-interest filing) not captured in my search results, this chain should be updated — but the two events above are the ownership spine.

Timeline diagram

timeline
    title Ownership of US 10924573
    2008 : Priority filed by Level 3
    2019 : Continuation filed
         : Inventors assign to Level 3
    2021 : Patent issued
    2023 : Lumen exits CDN market
    2024 : Assigned to Sandpiper CDN LLC
         : Google suit filed
    2025 : IPR filed on patent

NPE / troll-pattern signals

1. Shell-entity transfer — PRESENT (strong). Reel 068256/0091-0115 (recorded 2024-04-26) moved the patent from operating company Level 3 to Sandpiper CDN, LLC, a Delaware LLC formed 2024-03-21 with no products and no CDN operations, parented by Theseus LF Asset Holdings, LLC (Delaware, formed 2023-08-25). Direct non-practicing evidence: Google's stay motion in 2:24-cv-03951 states plaintiff "does not compete with Google and seeks only a reasonable royalty" (PTACTS docket, Dkt. 45-1).

2. Known asserter in the chain — PRESENT (strong). Sandpiper CDN is a multi-defendant, high-frequency plaintiff: v. Google (C.D. Cal. 2:24-cv-03951, filed 2024-05-10), v. Microsoft (E.D. Tex. 2:25-cv-00664), v. Comcast (E.D. Tex. 2:24-cv-00886-JRG-RSP). Unified Patents explicitly identifies Sandpiper CDN as "an NPE" (unifiedpatents.com insight, 2026-08-11) and the patent is challenged in IPR2025-00860 (per Google Patents legal-events; Google's stay motion lists it among Google's IPRs). RPX tracks the campaign. Also context: Level 3's earlier ~110-patent transfer to Optic153 LLC / Equitable IP Corp (John T. Meli Jr., 2017) shows a standing Level 3 pattern of monetizing via NPEs.

3. Repeat correspondent across the chain — UNCLEAR. I could not retrieve the correspondent-of-record names from available sources. The Level 3→Sandpiper cover sheet (reel 068256/0091-0115) is in the PTAB record and will list the correspondent; verify there or on the Assignment Center. The only other recorded event (2019 inventor assignment) is a routine employer assignment, not a recurrence signal. Litigation counsel for Sandpiper is Robert H. Reckers / Mayela C. Montenegro-Urch, but that is not the recording correspondent.

4. Cascading transfers — NOT PRESENT as defined. Only two recorded assignments; no chained LLC-to-LLC conveyances on this patent. (The Theseus→Sandpiper entity formation sequence in 2023–2024 is notable but is not a recorded assignment cascade.)

5. Pre-litigation transfer — PRESENT (strong). Assignment executed 2024-04-24 (sale closed 2024-03-29 per the complaint), recorded 2024-04-26 (reel 068256/0091-0115); first complaint (Sandpiper v. Google) filed 2024-05-10 — 14 days after recording. The chain was arranged immediately before assertion.

6. Bankruptcy fire-sale — NOT PRESENT. No bankruptcy; the transfer was an orderly CDN-market exit/monetization by Lumen/Level 3.

7. Privateering — UNCLEAR (weak). The structure fits privateering (operating company → NPE suing CDN competitors Google/Microsoft/Comcast), and RPX notes Level 3's prior Equitable IP/Optic153 transfers. But I found no SEC filing or revenue-share evidence tying Sandpiper's campaign back to Lumen, and Lumen had exited the market rather than remaining a direct competitor. Mark unclear.

8. Defensive aggregator (anti-NPE) — NOT PRESENT. Chain terminates at asserting NPE Sandpiper CDN. The defensive activity runs the other direction: Unified Patents is challenging the patent (IPR2025-00860).

Verdict

NPE — high confidence

Three strong signals converge: (1) the patent moved from operating company Level 3 to single-purpose Delaware LLC Sandpiper CDN (reel 068256/0091-0115, recorded 2024-04-26), with no products and a parent holding entity (Theseus LF Asset Holdings, LLC) — and Google's stay motion records that Sandpiper "does not compete with Google and seeks only a reasonable royalty"; (2) Sandpiper CDN is a recognized multi-defendant asserter, explicitly labeled an NPE by Unified Patents and tracked by RPX, suing Google, Microsoft, and Comcast; and (3) the transfer was recorded 14 days before the first complaint (2024-05-10), a textbook pre-litigation transfer. The only weak area is correspondent-of-record data, which was not retrievable in my sources; that gap does not change the conclusion.

Verification:

• USPTO Assignment Center: https://assignmentcenter.uspto.gov/ (search patent 10924573; see reel 068256/frames 0091–0115)
• Direct assignment search: https://assignment.uspto.gov/patent/index.html#/patent/search
• RPX case/news: https://litigation.rpxcorp.com/litigation/cacdce-[925901](/patent/925901)-sandpiper-cdn-v-google ; https://litigation.rpxcorp.com/news/80905-it-s-not-every-patent-complaint-that-name-checks-the-starr-report-and-big-bad-voodoo-daddy
• Unified Patents: https://www.unifiedpatents.com/insights/2026/8/11/sandpiper-cdn-patents-being-investigated ; IPR2025-00860 portal: https://portal.unifiedpatents.com/ptab/case/IPR2025-00860

I'll research the cited prior art for US 10,924,573, starting with the patent's own citation record and the key CDN references.

I have the cited-reference list. Let me verify the key CDN-specific citations (titles, dates, and disclosures) before mapping them to claim limitations.

Prior Art Analysis — U.S. Patent No. 10,924,573 B2

"Handling long-tail content in a content delivery network (CDN)" — Newton, Lipstone & Fullagar — Sandpiper CDN, LLC

Analysis date: April 26, 2026. Patent text from https://patents.google.com/patent/US10924573/en (authoritative).

0. Method, scope, and an important limitation on this answer

What I did. I pulled the "References Cited" record for US 10,924,573 and its immediate family members (US 9,762,692; US 8,930,538; US 10,218,806), and cross-checked individual references against Google Patents, FreePatentsOnline, and the PTAB/PTACTS record.

Three honesty caveats — please read before relying on this:

1. The citation list is enormous and partly truncated. Google Patents records 416 cited references for the '573 patent. The front-page PDF capture I retrieved truncates in the mid-1990s entries, and Google Patents itself renders the list in a paginated/JS-loaded form. I could not enumerate all 416. I therefore prioritized: (a) every CDN-, caching-, popularity-, redirect- and hashing-related reference; (b) references that map onto an element of the '573 independent claims; and (c) the art actually driving the pending IPR. The remaining bulk (VOD hardware, satellite, expert-system, hashing-table and distributed-database patents from 1979–2000) is inherited from the 2009–2011 parent filings and has no realistic § 102 purchase on these claims.
2. Family-list overlap. The '573 citation list closely mirrors the list on its parent US 9,762,692 / US 12/880,324. Where I could only verify a reference on a family member's record (notably US 2007/0055764 (Dilley)), I say so. I did not auto-correct any patent number, date, or name; where the record showed something odd (e.g., a title mismatch against the number), I flag it.
3. The most dangerous prior art is NOT on the face of the patent. The references Google actually relies on in IPR2025-00860 — Dilley (US 7,133,905), Pai (US 2006/0271972), Wang (US 2005/0198250), and Newton-471 (US 2016/0094471) — are not face citations of the '573. I treat them separately in § 4. This is consistent with, and builds on, the prior sections of this analysis (the prosecution-lineage, litigation, PTAB and obviousness sections), which established that institution was granted on all 20 claims and both grounds on 2025-11-25.

Claim-element map used throughout (from the '573 claims, § 1/11/19):

Claim 11 = system version of the same combination. Claim 19 = same, but the popularity service is associated with the first (edge) server. Claim 20 = the second server is the content server that stores the content. Dependents: 2/12 (not popular), 3/13 (popular + cache instruction), 4/14 (metro mid-tier), 5/15 (peer), 6/16 (threshold test), 7/17 (popularity service at second server), 8/18 (popularity service at first server), 9 (distinct second tier), 10 (later request served from edge cache).

1. Highest-relevance cited references (the "interesting" tier)

These are the face citations that bear directly on one or more claim elements. Dates are as printed in the reference record.

1.1 US 2008/0065724 A1 — Content delivery network — Seed et al. (Microsoft)

• Publication date: 2008-03-13 · Assignee: Microsoft Corporation
• Second family member also cited: US 2008/0071859 A1, pub. 2008-03-20 (Seed et al.)
• Disclosure (as quoted in the PTAB record): The edge server receives the user request; if the selected edge server does not have the object, it "initiate[s] a check … to determine whether the requested object is popular" (Seed ¶ [0026], Fig. 3(a)); popular content is stored/served at the edge, unpopular content is held on an intermediate tier of "parent" servers (¶¶ [0016], [0025]–[0028]); the network also partitions objects into chunks (¶ [0059]) and weighs "the cost of fetching" (¶ [0046]).
• Relationship to the '573: This is the closest thing on the face of the '573 to the claimed subject matter. It was cited by the examiner, and it is also one of the references the PTAB petitioner pairs with Swildens in an IPR against a sibling patent in this family.
• § 102 potential: Moderate as to claims 19, 8, 18, 2, 6, 12, 16 (popularity designation determined at/near the edge server; not-popular ≈ threshold test; parent-tier placement of unpopular content). Weak as to independent claims 1, 11: Seed's flow is edge determines popularity itself, not edge receives a redirect instruction from a second server (1[d]) plus a separate "instruction to not cache" (1[e]). On the strict claim language these two elements are the gap.
• Priority caution: published March 2008, i.e., before the claimed 2008-04-04 priority date, so its § 102(e) exposure depends on its own effective filing date pre-dating the '573's priority — verify the Seed application's filing/priority chain before relying on it as § 102(e) art.

1.2 US 6,754,699 B2 — Swildens et al. (Speedera Networks) — Content delivery and global traffic management network system

• Granted: 2004-06-22 · Related cited Swildens patents: US 6,484,143 B1 (User device and system for traffic management and content distribution over a world wide area network, filed 1999-11-22, granted 2002-11-19); US 6,694,358 B2 (granted 2004-02-17); US 6,754,706 B2 (Scalable domain name system with persistence and load balancing, granted 2004-06-22)
• Disclosure: Edge servers "maintain a dynamic number of popular files in their memory"; on a miss the edge "records the miss in its running count and redirects the user … to the origin site"; the edge "checks the frequency of requests over a certain amount of time … to see if any new files have gained enough popularity to replace another file in the local storage"; a miss-count threshold (e.g. 10) filters out marginally popular files; in an alternative embodiment a central "auto migration server" collects log files from the edge servers, tabulates miss counts, and decides whether content should be auto-migrated to the edge.
• Relationship to the '573: This is the single most § 102-dangerous face citation. The "auto migration server" is functionally a popularity service that (i) obtains information from edge servers about requests and (ii) tells the edges which tier should handle requests — the exact structure recited in the '573's claim-19 family and in the sibling patent's framework claim.
• § 102 potential: High as to claims 19, 20, 8, 18, 2, 6, 16 and the corresponding system elements of claim 11; high as to 1[a]–1[c]; the residual gap is 1[d]/1[e] — Swildens redirects the client to the origin, and I found no express "instruction to not cache" delivered back to the edge server. Confirm by reading the reference's full text before asserting anticipation of claims 1/11/19 in a filing.

1.3 US 2007/0055764 A1 — Dilley et al. (Akamai) — Method and system for tiered distribution in a content delivery network

• Publication date: 2007-03-08 · Priority: 2002-04-09 · Same family as US 7,133,905 B2 (granted 2006-11-07)
• Disclosure: Establishes a cache hierarchy in a CDN (edge region → single parent region or a subset of "core" parent regions → origin). On a miss in an edge region, "instead of contacting the origin server, the request is provided to either the single parent region or to a given one of the subset of edge server regions," "preferably as a function of metadata associated with the given object request." Also discusses the Danzig hierarchical-proxy-cache approach in which certain URLs are forced to resolve directly from the object's home rather than through the cache hierarchy.
• Relationship to the '573: This is the same Akamai tiered-distribution disclosure Google uses in its § 103 ground (as US 7,133,905) — meaning the examiner had the publication form of the Dilley family of record yet allowed the claims.
• § 102 potential: Moderate-to-high as to claims 1[a], 1[c], 1[d], 4, 9, 11, 14 (tiered CDN, edge→parent forwarding/redirect, distinct second tier). Low as to 1[b] (Dilley is metadata-driven, not popularity-driven) and low as to 1[e] (its no-cache-adjacent teaching is the "non-cacheable URL" discussion inherited from Danzig, not an instruction delivered to an edge server specifically to suppress caching of a fetched long-tail object).
• Caveat: I verified this citation on the family-member record (US 9,762,692 citation list) rather than reading it off the '573 front page directly. Confirm on the '573 face before citing it as "of record."

1.4 US 6,553,413 B1 — Leighton & Lewin (MIT) — Content delivery network using edge-of-network servers for providing content delivery to a set of participating content providers

• Granted: 2003-04-22 · Filed: 2000-06-28 · Priority: 1998-07-14 · Continuation of US 6,108,703
• Disclosure: Global hosting framework; content provider's most popular content replicated and served at an unlimited number of points worldwide; embedded objects served from "hosting/ghost servers" near the client; base HTML served from the content provider's site.
• § 102 potential: Low as to all independent claims. It is a pre-positioning/replication architecture; there is no popularity service with a designation (1[b]), no redirect instruction from a second server (1[d]), and no no-cache instruction (1[e]). It is background art only.

1.5 US 6,185,598 B1 — Farber et al. — Optimized Network Resource Location (the "repeater server / BRS" patent)

• Granted: 2001-02-06 · Also cited on the face: US 6,654,807 B2 (2003-11-25) and pub. US 2002/0099850 A1 (Internet content delivery network, 2002-07-25) and US 2005/0114296 A1 (Content delivery network and associated methods and mechanisms, 2005-05-26), all Farber et al.
• Disclosure: Repeater servers distributed in the network; a "Best Repeater Selector" resolves a client to a nearby repeater; content served from the repeater closest to the client.
• Relationship to the '573: The '573 specification expressly discusses this patent. It is cited as background for the server-selection function (Fig. 3's server selector 104), not as caching/popularity art.
• § 102 potential: None as to the independent claims — it addresses where to send the request, not whether to cache. Relevance is limited to 1[a] context.

1.6 US 6,502,125 B1 / US 6,003,030 / US 6,266,394 / US 6,314,565 / US 6,112,239 / US 6,154,744 / US 6,181,867 — Kenner et al. (InterVU / distributed-network storage family)

• Representative date: US 6,502,125 — System and method for optimized storage and retrieval of data on a distributed computer network, 2002-12-31; the others run 1999-12-14 through 2001-11-06.
• Disclosure: Distributed-network storage/retrieval using multiple servers; transferring and replicating content among nodes.
• § 102 potential: Low. They supply a generic "distributed network of content servers" environment. No popularity service, no no-cache instruction.

1.7 US 6,553,420 B1 and US 6,430,618 B1 — Karger et al. — hashing / consistent hashing / distributed caching

• Granted: 2003-04-22 and 2002-08-06 · Assignee: MIT
• Disclosure: Consistent hashing and distributed caching protocols for relieving hot spots on the Web.
• Relationship to the '573: The '573 specification's popularity tally hash (§ "Defining & Measuring Popularity," 100M slots per coserver, MAD/MD5 hash over object name) and its parent-tier hash partitioning draw on this line of art.
• § 102 potential: None as to the '573's independent claims (they recite no hash limitation). They would only matter if a party sought to attack partition-by-hash dependent claims; the '573 claim set does not contain them (they live in the '692/'538 claims).

1.8 US 7,274,658 B2 — Bornstein et al. — Optimal route selection in a content delivery network

• Granted: 2007-09-25 · Also cited: US 2002/0163882 A1 (Bornstein et al., pub. 2002-11-07) — a Level 3 co-owned publication, and US 7,376,644 B2 (Aborn, Automated server replication, 2008-05-13).
• § 102 potential: Low. Routing/replication art; no popularity designation and no no-cache instruction.

1.9 US 7,562,153 (Biliris et al., 2009-07-14) and US 7,577,754 (Garcia-Luna-Aceves et al., 2009-08-18)

• Both appear at the end of the cited-patent list, i.e., they post-date much of the family and were likely added by examiner amendment during later prosecution.
• § 102 potential: To be assessed but low on the present record. Neither title suggests a popularity service or a no-cache instruction. Given the timing (cited late), they are consistent with examiner "cumulative" citations rather than with a near-miss anticipation. I could not verify their disclosures in this session, so I will not characterize them beyond their citation position.

2. Second-tier cited references (supporting/background only)

Caveat on this table: these references matter to the file history narrative (they show the examiner was working in the CDN space and still allowed the "instruction to not cache" limitation), not as serious § 102 threats. I have deliberately not assigned detailed element-by-element § 102 mappings to entries whose full text I did not review.

3. Foreign references and non-patent literature cited

3.1 Foreign patent documents (selected, relevance-ranked)

• WO 2009/108593 A1 (2009-09-03) — this is Level 3's own PCT counterpart to the '573 family (PCT/US2009/037904). Not prior art; it is the applicant's own publication. Its inclusion on the face is a family artifact.
• WO 00/60861 A1 (2000-10-12) — Method and apparatus for hierarchical distribution of video content for an interactive information distribution system — hierarchical content distribution; low § 102 value (no popularity designation, no no-cache instruction).
• JP 2000-207270 A (2000-07-28) — WWW proxy device; JP 2001-290787 A (2001-10-19) — Data distribution method and storage medium; EP 1063831 A (2000-12-27) — Network status server, information distribution system…; EP 1104555 / AU 763380 / CA 2467998 / IL 140935 / JP 2005-124165 — end-user electronic-content-usage tracking family (all one family). All are low-relevance to the independent claims.
• CA 2202572 (1998-10-14) — A scaleable web server and method of efficiently managing multiple servers; CA 2288488 (2000-06-16) — Method and apparatus for transparently directing requests for web objects to proxy caches — the latter is mildly relevant to 1[d] (redirecting requests to caches), but it is a transparent-proxy routing reference, not a popularity/no-cache reference.
• GB 2281793 A (1995-03-15) — network load levelling; GB 2353877 A (2001-03-07) — resource management across heterogeneous servers. Background only.

3.2 Non-patent literature (the genuinely relevant subset)

• Kim, Y. J. et al., "Clustered multi-media NOD: Popularity-based article prefetching and placement," 16th IEEE Symp. on Mass Storage Systems, San Diego (Mar. 15–18, 1999), pp. 194–202. — Popularity-based placement across clustered storage. This is the most on-point NPL on the face: it addresses popularity-driven placement, i.e., element 1[b]'s concept and the claim 2/3 (not-popular/popular) dichotomy. § 102(b) exposure as to claims 2, 3, 6, 12, 13, 16 (popularity thresholds and placement) — but it does not disclose a tier-1 edge server receiving a redirect plus a no-cache instruction.
• Bestavros, A., "Demand-Based Document Dissemination to Reduce Traffic and Balance Load in Distributed Information Systems," IEEE Symp. on Parallel and Distributed Processing, San Antonio, TX (Oct. 1995) — demand/speculative dissemination; low-moderate § 102 value for 1[b]/1[c] concept only.
• Chankhunthod, A. et al., "A Hierarchical Internet Object Cache," Proc. 1996 USENIX Technical Conf. (Jan. 1996), pp. 153–163 — hierarchical cache resolution (parent/sibling fetch on miss). Relevant to 1[c]/1[d] architecture; low standalone § 102 value.
• Wessels, D. et al., "Internet Cache Protocol (ICP), Version 2," IETF RFC 2186 (Sep. 1997); Wessels, "Configuring Hierarchical Squid Caches" (1997) — cache-hierarchy protocols; background for 1[d].
• Cohen, J. et al., "Cache Array Routing Protocol v1.1" (1997); Ross, K. W., "Hash-Routing for Collections of Shared Web Caches," IEEE Network (Nov./Dec. 1997); Doi, K., "Super Proxy Script — How to distribute proxy servers by URL hashing"; Thaler & Ravishankar, "Using name-based mappings to increase hit rates," IEEE/ACM ToN (Feb. 1998); Karger et al., "Consistent Hashing and Random Trees" (STOC 1997) — the hash-based request-distribution line. Relevant only to the parent-tier partitioning/hash concepts found in the '692/'538 claims, not in the '573's 20 claims.
• Palmer, M. et al., "Fido: A Cache that Learns to Fetch," VLDB (Sep. 1991); Gwertzman & Seltzer, "The Case for Geographical Push-Caching" (HotOS 1995) and "World-Wide Web Cache Consistency" (USENIX 1996); Malpani et al., "Making World Wide Web Caching Servers Cooperate" (WWW4 1995); Gadde et al., "Reduce, reuse, recycle: An approach to building large internet caches" (HotOS 1997) — cache-fill decision policies. Low § 102 value but useful § 103 context.
• Kostadinova, R., "Peer-to-Peer Video Streaming" (KTH, 2008) — cited as an "other reference"; to be assessed — cited for the streaming/peer-serve overlay concept, apparently in connection with the 2010 CIP prosecution rather than the '573 claims.
• MD5/hash and RFC references (RFC 1034/1035 DNS, RFC 1945/2068 HTTP, RFC 1738 URL, etc.) — standard art; no § 102 value against the claims.

4. The art that is not of record but is driving the validity challenge (IPR2025-00860)

Flagging this because it is where the real § 102/§ 103 exposure sits, and because these references' status as "prior art of record" was a live issue at institution:

Analytical point worth carrying forward: the examiner never cited Pai or Wang, and never cited the Akamai patent (only its publication) — so the "instruction to not cache" limitation was allowed without the examiner seeing the reference (Wang) that most directly teaches the concept. That is precisely why institution was granted in full.

5. Bottom line — which cited references could actually anticipate, claim by claim

1. No face-cited reference anticipates independent claims 1, 11, or 19 in full. Every candidate fails at element 1[e] — a received instruction to not cache the resource at the edge server when it is obtained from a content server. Swildens and Dilley arrange redirects; Seed arranges popularity-based tier placement; none delivers the no-cache instruction back to the edge in the claimed manner.

2. The best § 102 candidates on the face, ranked:

• (i) Swildens (US 6,754,699 / 6,484,143 / 6,694,358 / 6,754,706; Speedera, 2002–2004) — strongest for claims 19, 20, 8, 18, 2, 6, 16; strong for elements 1[a]–1[c]; gap at 1[d]/1[e].
• (ii) Seed (US 2008/0065724; US 2008/0071859; Microsoft, 2008) — strongest for claims 19, 8, 18, 2, 6, 12, 16; gap at 1[d]/1[e]; also a § 102(e) timing question to verify.
• (iii) Dilley publication (US 2007/0055764; Akamai, 2007) — strongest for claims 4, 9, 11, 14 and elements 1[a], 1[c], 1[d]; gap at 1[b] (metadata ≠ popularity) and 1[e].
• (iv) Kim et al. (1999 NPL) — popularity-based placement; supports claims 2, 3, 6, 12, 13, 16 conceptually, not structural anticipation.

1. Anticipation risk to the full claim set comes from outside the citation list. Newton-471 (same family, published 2016) anticipates all of claims 1–20 if and only if the priority date is limited to 2019-02-25. That is the same issue on which the Board instituted on 2025-11-25, and it is pending, with the final written decision due on or before 2026-11-25. My earlier sections of this analysis reached the same conclusion; nothing in the citation record contradicts it.

2. The face-citation record has a defensive use. That US 2007/0055764 (Dilley) and both Seed publications were of record and were overcome is a fact worth pressing: it shows the examiner considered the tiered-CDN and edge-popularity-check teachings and still found the "instruction to not cache" combination patentable. That argument does nothing, however, against Pai and Wang, which were not before the examiner.

3. Consistency check against prior sections of this analysis. No contradiction found. The prosecution-lineage, litigation, PTAB and obviousness sections all treat IPR2025-00860 as the live threat on all 20 claims; the citation analysis above independently confirms that the face-cited art is weaker than the IPR art on the two limitations that matter (popularity designation at the edge; the no-cache instruction), which is why the new-matter/priority dispute — not the face citations — controls the outcome.

Verification pointers

• '573 full text and citation list: https://patents.google.com/patent/[US10924573B2](/patent/US10924573B2)/en
• Front-page PDF (References Cited): https://patentimages.storage.googleapis.com/86/83/00/d11c9761bdbeb4/US10924573.pdf
• Family member citation list (used to cross-verify Dilley/Seed/Kenner/Swiddens entries): https://www.freepatentsonline.com/[9762692](/patent/9762692).html
• Leighton US 6,553,413: https://patentimages.storage.googleapis.com/e0/b1/28/69701ecf4d6e30/US6553413.pdf
• Dilley US 2007/0055764 / US 7,376,716 (same family text): https://patentimages.storage.googleapis.com/ec/33/81/6f0323f68aec42/US7376716.pdf ; https://www.sumobrain.com/patents/usapp/Method-system-tiered-distribution-in/20070055764.html
• Swildens US 6,484,143: https://www.sumobrain.com/patents/us/User-device-system-traffic-management/6484143.html
• PTAB petition record quoting Seed and Swildens element-by-element (sibling patent IPR): https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1558761](/patent/1558761)/download-documents
• IPR2025-00860 institution decision (Paper 15): https://www.docketalarm.com/cases/PTAB/IPR2026-00095/Microsoft_Corporation_v._Sandpiper_CDN_LLC/docs/02-13-2026-Petitioner/Exhibit-1034-EX1034___Google_LLC_v_Sandpiper_CDN,_LLC,_IPR2025_00860,_Paper_15_Nov_25,_2025_Institution_Decision.pdf

Residual uncertainty: (a) the full 416-item citation list was not exhaustively characterized — the ~30 references above are the relevant subset, and the remainder are pre-1996 non-CDN patents; (b) I could not verify US 7,562,153, US 7,577,754, US 6,052,718, or the Seed publications' full texts in this session, and I have said so rather than characterizing them; (c) the exact scope of what the examiner considered versus what the PTAB petitioner relies on should be confirmed against the file wrapper (PTACTS) before any filing that turns on "art of record."

Obviousness Analysis — U.S. Patent 10,924,573 ("Handling Long-Tail Content in a CDN")

1. Scope and framework of the analysis

This analysis assesses whether the claims of US 10,924,573 B2 ("the '573 patent") would have been obvious to a person of ordinary skill in the art (POSITA) under 35 U.S.C. § 103, using the prior art identified in the pending inter partes review (IPR2025-00860, Google LLC v. Sandpiper CDN, LLC, institution granted in Paper 15, dated Nov. 25, 2025). The § 103 inquiry follows the Graham framework: (1) scope and content of the prior art; (2) differences between the prior art and the claims; (3) the level of ordinary skill in the art; and (4) secondary considerations.

The '573 patent has 20 claims. The independent claims are claims 1 (method), 11 (system), and 19 (method). As summarized in the earlier sections of this analysis, each independent claim shares the same core combination, with the key distinguishing limitation being an "instruction to not cache" the resource at the edge (first-tier) server when the resource is obtained from a content server. The dependent claims add detail on the popularity designation (claims 2, 3, 6–8, 12, 13, 16–18), the identity of the second server (claims 4–5, 9, 14–15), and subsequent request handling for cached content (claim 10).

2. The prior art references

2.1 Dilley — US 7,133,905 B2 ("Method and system for tiered distribution in a content delivery network")

• Assignee: Akamai Technologies, Inc.
• Filed: Apr. 9, 2002; Issued: Nov. 7, 2006 (well before the '573 patent's earliest claimed priority date of Apr. 4, 2008)
• Disclosure: A hierarchical, multi-tiered content delivery network with edge servers, parent/regional servers, and origin servers. Dilley teaches storing more frequently accessed content closer to requesting clients (edge caches) and less frequently requested content in further caches (parent/origin tiers), using metadata (e.g., "use-hierarchy" metadata, per the USPTO grant record at uspto.report/patent/grant/7133905) to determine distribution of content across the tiers. This is the foundational tiered-CDN architecture reference.

2.2 Pai — US 2006/0271972 A1 ("Popularity-based on-demand media distribution")

• Published: Nov. 30, 2006
• Disclosure: A popularity-driven content distribution system for on-demand media. Pai associates a popularity value with each media item (Fig. 5, steps 504–506), determines an appropriate media source level based on the popularity value, and deploys the media item accordingly. Content above a highest threshold is distributed to level-one media sources (Fig. 6, steps 602–606); content between thresholds goes to level-two sources (steps 608–610); content below the lowest threshold goes to level-three sources (steps 612–614). Popularity is recalculated over time and content is dynamically redistributed/migrated between sources (Figs. 7–8). This is the "dynamic popularity service" reference.

2.3 Wang — US 2005/0198250 A1 ("Network system, method and protocols for hierarchical service and content distribution via directory enabled network")

• Published: Sep. 8, 2005
• Disclosure: A hierarchical service/content distribution network managed via directory-enabled protocols (DGP/LDAP-style). Wang addresses cache consistency and cache invalidation, teaching that content can carry cache-control attributes and that lower-level servers may be instructed not to cache certain content — the reference relied on for the "instruction to not cache" limitation. Wang's specification expressly discusses cache invalidation "through DGP propagation ... to help maintain the cache freshness for this content delivery network."

2.4 Newton-471 — US 2016/0094471 A1 ("Handling long-tail content in a content delivery network")

• Published: Mar. 31, 2016 (approximately)
• Disclosure: A sibling application in the same family as the '573 patent, with a nearly identical specification, but which expressly discloses the "instruction to not cache" limitation (including Figure 8, "a flow diagram depicting a method of serving content from a CDN to a requesting client where the content is not cached"). Newton-471 is the primary § 102 anticipation reference in IPR2025-00860. It is also available as a § 103 reference if the '573 patent's priority date is limited to Feb. 25, 2019 (its actual filing date).

3. Threshold issue: the priority-date challenge and its effect on the prior art

Before the merits of obviousness, the IPR petition and the institution decision confront a threshold issue that is outcome-determinative for the § 103 (and § 102) analysis. Petitioner Google contends that the "instruction to not cache" limitation was new matter first introduced in the Feb. 25, 2019 continuation application (US 16/284,791) and lacks written-description support in the parent applications (US 12/408,681; US 12/880,324; US 15/645,584; Provisional 61/042,412). If the Board agrees, the '573 patent is not entitled to its claimed Apr. 4, 2008 priority date and is instead treated as prior-art-effective on Feb. 25, 2019.

The institution decision (Paper 15, Nov. 25, 2025) expressly notes:

• Petitioner's contention that "the written description of the '573 patent has no support for an 'instruction to not cache'; the limitation appears only in the claims" of the '573 patent;
• Patent Owner's counter-argument that the "follow me" redirect disclosure ("If the edge server 108 receives a redirect from the popularity service 102 without the 'follow me' flag set ... it simply forwards the redirect to the client ... If the edge server 108 receives a 'follow me' redirect, it obtains and caches the resource") inherently teaches an "instruction to not cache" as the alternative to the cache instruction; and
• The Board's institution on all claims (1–20) and all grounds, including the Dilley/Pai/Wang obviousness ground.

The consequence for the obviousness analysis: on the effective Feb. 25, 2019 date, all four references above are prior art (each published before 2019). Importantly, the institution decision records that even under the claimed Apr. 4, 2008 priority date, "the Ground 2 references remain prior art under pre-AIA § 102(b)" — i.e., Dilley (Nov. 2006), Pai (Nov. 2006), and Wang (Sep. 2005) each published more than one year before the Apr. 4, 2008 priority date. The Dilley/Pai/Wang combination is prior art under either priority-date scenario, which makes the § 103 analysis robust to the outcome of the new-matter dispute. Only the Newton-471 anticipation ground (and its availability as a § 103 reference) depends on the priority-date outcome.

4. The primary obviousness combination: Dilley + Pai + Wang

4.1 Claim 1 mapping (representative; claims 11 and 19 follow the same pattern)

The institution decision confirms this division of labor: "Petitioner relies upon the combination of Dilley and Pai for the teaching of the preamble of claim 1 and limitations 1(a)–1(c)," with Wang supplying the no-cache instruction. The Board found the petition's showing sufficient to institute on all claims.

4.2 Claims 11 and 19

• Claim 11 (system) recites the same functionality in apparatus form: a first tier (edge servers), a second tier whose first server returns (i) a redirect instruction intended for the requesting device and (ii) an instruction to not cache, plus a popularity service tracking the popularity designation. Dilley provides the tiered system architecture; Pai provides the popularity service; Wang provides the no-cache instruction.
• Claim 19 (method) is distinguished only in that the popularity service is "associated with the first server of the first tier" rather than with a second-tier server. This is a trivial design choice — the '573 patent's own specification states the popularity service "may located anywhere in the system, including in the edge tier" — and Pai's popularity determination is not tied to any particular network location. The IPR petition "provides ... some additional argument and evidence for claim 19," and the Board instituted on it.

4.3 Dependent claims

• Claims 2, 12 (popularity designation = not popular): directly supported by Pai's below-threshold distribution to lower tiers.
• Claims 3, 13 (popularity designation = popular; instruction to cache): supported by Pai's above-threshold deployment to level-one sources, and by Dilley's teaching of caching popular content at the edge.
• Claims 4, 14 ("metro mid-tier server"): the '573 patent's own CIP (US 12/880,324) and Newton-471 introduce the "metro" architecture (Fig. 7 of Newton-471); Dilley's parent/regional tier performs the mid-tier function.
• Claims 5, 15 (second server is a peer of the first tier): Dilley's peer/edge-server cluster disclosure covers this.
• Claims 6, 16 (popularity value vs. first predetermined threshold): Pai's threshold comparisons (Figs. 5–6) are squarely on point.
• Claims 7, 17 (popularity service associated with second server): Pai's popularity determination can be implemented at any tier; Dilley's regional/parent servers manage distribution metadata.
• Claims 8, 18 (popularity service associated with first server): same as claim 19 analysis.
• Claim 9 (second server in a distinct second tier): Dilley's edge/parent/origin hierarchy.
• Claim 10 (subsequent request served from edge cache): Dilley's edge-cache serving; Pai's redistribution of now-popular content toward the edge.
• Claim 20 (second server is a content server storing the requested content): the origin/content-server role in Dilley and Wang.

5. Motivation to combine (the KSR / Graham rationale)

The institution decision summarizes the Petitioner's motivation, which is well grounded in the references themselves:

1. Dilley's own incentive structure points toward popularity-aware distribution. Dilley teaches tiered distribution in which "more frequently accessed content" is stored "closer to the requesting clients and less frequently requested content in further caches." This is an explicit recognition that frequency of access (i.e., popularity) should drive tier placement. A POSITA reading Dilley would understand that the tier-placement decision is a popularity decision and would naturally look to known popularity-measurement mechanisms.

2. Pai supplies the missing popularity engine. Pai teaches exactly the mechanism Dilley's architecture implies but does not implement: assigning popularity values, comparing them to thresholds, and dynamically redistributing content among tiered sources as popularity changes over time ("how to distribute more and less popular content between different cache tiers and how to determine popularity and dynamically redistribute content"). The combination's purpose — "to provide an improved and dynamic tiered CDN with a popularity service" — is a straightforward application of a known solution (Pai) to a known problem (Dilley's static tiering).

3. The expert's reasoning tracks the KSR "predictable variation" principle. Petitioner's expert (Dr. Mowry) testified that combining Dilley's tiered hierarchy with Pai's real-time popularity calculations "would have improved Dilley's ability to handle high volumes of requests for different levels of popular content without overloading the origin servers" and "result[ed] in better performance and more efficient use of resources" (Ex. 1006 ¶ 209, as quoted in the institution decision). This is a predictable efficiency improvement from aggregating two known, complementary teachings in the same field.

4. Wang supplies the final piece as a routine optimization. Once the Dilley+Pai system decides that unpopular content should not be placed at the edge, the system must communicate that decision to the edge server. Wang's cache-control/no-cache attributes and cache-invalidation techniques are the standard, well-known mechanism for telling lower-level servers not to cache content ("a straightforward method to optimize storage and avoid caching unnecessary content, a well-known goal in CDN design"). The '573 patent itself identifies the same rationale: avoiding cache fills for unpopular resources saves bandwidth and prevents cache thrashing. Wang's teaching is the conventional implementation of that known goal.

5. No teaching-away or incompatibility. The references are all in the content-delivery/on-demand-distribution arts; none teaches away from combining popularity-based placement with tiered caching. Dilley's metadata-based distribution control affirmatively invites the substitution of Pai's popularity-based control logic. Wang's no-cache instruction complements rather than conflicts with Dilley's caching hierarchy.

6. Reasonable expectation of success. The combination applies known techniques (popularity thresholds, no-cache instructions, tiered caches) to a conventional CDN architecture for predictable results: faster delivery of popular content, reduced bandwidth cost for unpopular content, and improved cache efficiency. A POSITA would have had a reasonable expectation of success, as the Board implicitly credited in instituting on all claims.

6. Secondary considerations

Per the institution decision: "No evidence of objective indicia of nonobviousness is presented by Patent Owner." Accordingly, there are no industry praise, long-felt need, unexpected results, copying, or commercial-success showings in the record to rebut the prima facie case. In the IPR posture, this weighs in favor of a finding of obviousness.

7. Independent assessment: is the "instruction to not cache" limitation really non-obvious?

The '573 patent's prosecution history shows the "instruction to not cache" limitation was added to secure allowance — the IPR petition contends it "was central to the allowance of the '573 patent claims" and "appears only in the claims." But even accepting that the limitation lacks antecedent support in the 2008 priority documents (the new-matter question), it does not follow that the limitation is non-obvious:

• Wang expressly discloses instructing lower-level servers not to cache content — the identical functional teaching, in a hierarchical content-distribution network, published in 2005.
• Pai discloses not deploying below-threshold content to upper-tier sources, which is the placement-side equivalent of a no-cache instruction.
• The '573 patent's own specification describes the long-tail problem (unpopular content should not be cached at the edge to avoid bandwidth waste and thrashing) and describes the redirect-without-"follow-me" path, which necessarily results in the edge not caching the content.
• Applying a no-cache instruction to a tiered CDN is a textbook design choice that a POSITA would make to achieve the very efficiency goals Dilley and Pai already pursue.

Even if the Board were to find the limitation unsupported as new matter (defeating the 2008 priority date), the limitation would still be obvious over Wang in view of Dilley and Pai under the 2019 effective date. The two issues are legally distinct, and the obviousness ground does not depend on the priority-date outcome.

8. Alternative combination: Newton-471 as a § 103 reference

If the '573 patent is limited to its Feb. 25, 2019 filing date, Newton-471 (published Mar. 2016) becomes available not only as an anticipating reference under § 102 but also as a § 103 reference. Newton-471's specification is nearly identical to the '573 patent's and expressly discloses the "instruction to not cache" limitation (Fig. 8). Under that scenario, Newton-471 alone anticipates all claims (Ground 1); alternatively, Newton-471 in view of Dilley/Pai/Wang renders the claims obvious with even less need for inferential reasoning, since Newton-471 supplies the complete claimed combination. This is the strongest § 103 case available and is why the priority-date determination is the pivotal issue in the proceeding.

9. Conclusion

1. The Dilley + Pai + Wang combination renders claims 1–20 obvious under § 103, regardless of whether the '573 patent is entitled to its 2008 priority date, because all three references are prior art under either date (pre-AIA § 102(b) even as of Apr. 4, 2008). Dilley supplies the tiered CDN; Pai supplies the popularity service and threshold-based tier placement; Wang supplies the no-cache instruction for lower-tier servers.
2. A POSITA would have been strongly motivated to combine them: Dilley's tiering is popularity-driven in substance but static in implementation; Pai provides the known dynamic popularity engine; Wang provides the known cache-control mechanism; and the combination yields predictable efficiency gains (reduced origin load, reduced cache thrashing, lower bandwidth cost).
3. No objective indicia of nonobviousness appear in the record, per the institution decision.
4. The priority-date/new-matter dispute is dispositive only for the Newton-471 anticipation ground, not for the Dilley/Pai/Wang obviousness ground, which stands on independent footing.
5. The PTAB's institution decision in IPR2025-00860 (Paper 15, Nov. 25, 2025) granted review of all claims 1–20 on all grounds, including the Dilley/Pai/Wang obviousness ground, signaling that the Board found the petition's obviousness showing sufficient to warrant trial.

Caveats: This analysis relies on the IPR petition and institution-decision characterizations of Dilley, Pai, and Wang (via the Docket Alarm exhibit copy of Paper 15 and the Ex Parte summary of the petition), which I did not fully verify against the primary references. The final obviousness determination will turn on the Board's claim construction and its resolution of the new-matter/priority-date dispute, which remains pending. My searches did not surface any CAFC appeal docket for this patent as of today (Apr. 26, 2026); the IPR and the C.D. Cal. litigation (2:24-cv-03951) are the active proceedings.