US 9661049

Summary — U.S. Patent No. 9,661,049 (US9661049B2)

Note on sources: I searched for this patent on USPTO/Google Patents and for CAFC 2026 docket activity. The Google Patents record for US9661049B2 was confirmed (title, dates, assignee history, abstract, spec). No CAFC 2026 docket entries for this patent number were returned in my searches, so I cannot confirm or deny pending appeal activity — treat that as unverified. The full claims text was not included in the provided patent text, so claim numbering below is inferred from the specification's Brief Summary and flagged as such.

---

Bibliographic data (confirmed)

• Title: Systems and methods of providing interspersed manifest file specifications for adaptive streaming video
• Patent number: US9661049B2
• Application: US15/215,889 (filed 2016-07-21) — a continuation of US14/709,171 (filed 2015-05-11), which claims priority to U.S. Provisional App. No. 62/072,265 (filed 2014-10-29)
• Priority date: 2014-10-29
• Issue/publication date: 2017-05-23 (pre-grant publication US20160330261A1 on 2016-11-10)
• Inventor: Michael Gordon
• Original assignee: DLVR, Inc.
• Current listed assignee (per Google Patents): Adeia Media Holdings Inc. (transfers shown: DLVR, Inc. → Akita Investments LLC security interests → Adeia Media Holdings LLC/Inc. assignments in 2025)
• Status: Active; anticipated expiration 2035-05-11
• Classifications (representative): H04L65/60 (network streaming of media packets), H04L65/612, H04L67/02, H04N21/8586 (linking by URL), H04L47/783

Abstract (as published)

Techniques for serving a manifest file of an adaptive streaming video include receiving a request for the manifest file from a user device. The video is encoded at different reference bitrates and each encoded reference bitrate is divided into segments to generate video segment files. The manifest file includes an ordered list of universal resource locators (URLs) that reference a set of video segment files encoded at a particular reference bitrate. A source manifest file that indicates the set of video segment files is identified based on the request. An issued manifest file that includes a first URL and a second URL is generated based on the source manifest file. The first URL references a first domain and the second URL references a second domain that is different from the first domain. The issued manifest file is transmitted to the user device as a response to the request.

Plain-language overview of the independent claims

Caution: The claims section was not reproduced in the provided patent text, and my searches did not return the verbatim claims. The specification's Brief Summary describes three statutory embodiments that correspond to the typical independent claims of this patent. I am confident in the substance but not in the exact claim numbers:

1. System claim (likely claim 1) — manifest file server system. A manifest file server coupled to a network receives a request for a manifest file of an adaptive-streaming video from a user device/player. The video is encoded at multiple reference bitrates, each divided into segments to create video segment files, and the manifest lists URLs referencing segment files at a particular bitrate. The server identifies a source manifest file (from the content provider/CDN) based on the request, and generates an issued manifest file that contains at least a first URL and a second URL. The first URL points to a segment file hosted in a first domain, and the second URL points to a segment file hosted in a different second domain (e.g., interspersing URLs of the operator's own segment servers with URLs of third-party service providers/CDNs). The issued manifest is transmitted to the user device as the response.

2. Method claim (likely claim ~10 or similar) — method for serving a manifest file. The method mirrors the system: receiving the request from a user device, identifying the source manifest file indicating the set of segment files for the particular reference bitrate, generating an issued manifest file with a first URL referencing a segment file in a first domain and a second URL referencing a segment file in a different second domain, and transmitting the issued manifest to the user device.

3. Computer-readable medium claim (likely a later claim) — non-transitory medium. A non-transitory computer-readable medium stores instructions that, when executed, cause a computer to perform the same operations: receive the manifest request, identify the source manifest, generate the issued manifest with first/second URLs referencing segment files hosted in different domains, and transmit it to the user device.

Practical substance

The patent is directed to adaptive-bitrate streaming (HLS/DASH/HDS) where a manifest server rewrites a publisher's manifest to intersperse segment-file URLs across multiple domains — e.g., alternating between the operator's own segment servers (which can capture delivery telemetry, session IDs, and first/last-segment measurements) and third-party service provider (CDN) servers — to enable per-session performance measurement and multi-provider traffic allocation without installing software on the user device. Dependent features described in the spec (not claims-verified) include distribution policies/models, session IDs embedded in URLs, consistent vs. random positioning of URL types, and dynamic adjustment of the mix of server types.

Uncertainty flags

• Exact claim text and claim numbering not verified (claims section absent from provided text; web search results truncated before claims). Confirm against USPTO Patent Center before relying on specific claim language.
• CAFC 2026 docket status: no results found; unverified.
• The assignee chain shown by Google Patents (Adeia Media Holdings Inc. as current assignee; DLVR, Inc. as original) reflects recorded assignments/security interests; Google notes its assignee list may be inaccurate.

I found a lead: 1:26-cv-01373, Adeia Tech Inc. v. DISH Network Corp. (Colorado District Court), which matches the Unified Patents litigation link shown on the Google Patents record for US9661049B2. Let me verify the details.

The core case is confirmed. Now let me check whether other cases (the DirecTV DJ action and Adeia v. DirecTV) also involve this specific patent, and check the Unified Patents caselist.

Litigation Involving U.S. Patent No. 9,661,049 (US9661049B2)

Based on searches of PACER, Unified Patents, Ex Parte litigation analytics, SEC filings, and press releases, one confirmed case directly asserts US9661049, with one or two related cases that could not be confirmed to include this patent number.

---

1. CONFIRMED — Adeia Technologies Inc. et al. v. DISH Network Corporation et al.

Sources: Unified Patents litigation portal (linked from the Google Patents record for US9661049B2, showing "US case filed in Colorado District Court — 1:26-cv-01373"); PACERMonitor case page (case 63896596); Ex Parte/AI-Lab complaint analysis for 1:26-cv-01373; Adeia Inc. press release dated April 1, 2026 (GlobeNewswire); EchoStar Corporation Form 10-Q (SEC EDGAR, sats-20260331x10q.htm).

---

2. UNCONFIRMED — DirecTV, LLC v. Adeia Inc. et al. (declaratory judgment)

---

3. UNCONFIRMED — Adeia Media Holdings Inc. et al. v. DirecTV, LLC

---

4. Darts-ip "first worldwide family litigation" flag (unverified)

The Google Patents record for US9661049B2 carries a Darts-ip entry noting "First worldwide family litigation filed" for patent family 55853956. This flag indicates litigation somewhere in the broader family (which includes the parent applications — e.g., US14/709,171 and provisional 62/072,265 — and any related patents/continuations). Given the timing, the Colorado case (No. 1 above) is the most likely referent, but I could not open the Darts-ip record to confirm whether it refers to the Colorado case or to a separate family member case. Treat as unverified.

---

Summary

• Confirmed litigation asserting US 9,661,049: only Adeia Technologies Inc. et al. v. DISH Network Corp. et al., 1:26-cv-01373 (D. Colo., filed 2026-03-31) — currently open/active, with automatic-stay notices filed as to certain DISH entities per EchoStar's SEC disclosures; no merits ruling or judgment identified.
• No other case was confirmed to assert this specific patent number. The DirecTV DJ action (3:25-cv-11048) and Adeia v. DirecTV (2:26-cv-07222) are related Adeia litigation but their patent lists could not be verified to include 9,661,049.
• Caveats: (a) I could not verify the full complaint/claim lists for cases 2 and 3 before search limits were reached; (b) the Chapter 11/automatic-stay status of the DISH defendants comes from EchoStar's 10-Q and was not independently corroborated; (c) docket dates appearing after the stated "current date" (April 26, 2026) reflect search results that include later filings — the Colorado case's docket shows activity through at least July 2026, which is the most current available data.

Proceedings overview

There are zero AIA trial proceedings (IPR/PGR/CBM) on file for US Patent No. 9,661,049: the structured USPTO Open Data Portal block reports no proceedings, and independent web searches for "US9661049" / "9,661,049" against PTAB decision databases, Unified Patents, and CourtListener returned no IPR/PGR/CBM docket numbers, no institution decisions, and no Final Written Decisions. For a defendant, the bottom line is a clean but un-hardened slate: no claims have been canceled or even challenged at the PTAB, so every claim of the patent remains presumptively valid and untested — an IPR defense would have to be built from scratch, and the window to do so may already be closing (see § 315(b) note below).

---

PTAB proceedings (none found — stated plainly)

No proceeding entries exist. I will not invent proceeding numbers, panel names, grounds, or outcomes. What I can verify from the record instead:

• No AIA trial on file (USPTO ODP): The canonical structured data in this prompt states the ODP API returns no IPR/PGR/CBM for this patent as of the most recent ingest. That is the authoritative "on file" status.
• No PTAB decision surfaced by search: Searches for the patent number in connection with "IPR," "final written decision," "institution," and "PTAB" returned no matching proceedings (results were unrelated patents and cases).
• Adjacent (non-PTAB) activity that does exist: Google Patents' litigation metadata flags a district-court case — Colorado District Court, case 1:26-cv-01373 (per Unified Patents Litigation Data), plus Darts-ip "first worldwide family litigation" entries. This is federal court litigation, not a PTAB proceeding, and I have not verified its current posture, parties, or claims at issue.

Because there are no proceedings, there is nothing to report for judge panels, petition grounds, institution decisions, FWDs, settlements, or Federal Circuit appeals — and I will not speculate.

---

Strategic summary

Claim status. All claims of US 9,661,049 are UNTESTED — none have been canceled, narrowed, or sustained by the PTAB because no petition has been filed. (Caveat carried forward from the prior section of this analysis: the exact claim text and numbering were not verified from the issued patent; the independent claims correspond to the system / method / non-transitory-CRM embodiments in the Brief Summary — i.e., receiving a manifest request, identifying a source manifest, generating an issued manifest with first/second segment URLs hosted in different domains, and transmitting it to the user device.) A defendant facing assertion today confronts a patent with its full claim set intact.

Estoppel landscape. Because there has been no IPR, there is no § 315(e)(2) estoppel against anyone — no petitioner or privy has been barred from raising grounds, and no prior art has been "used up." For a defendant currently being sued, however, the critical constraint is § 315(b): an IPR petition must be filed within one year of service of a complaint alleging infringement. If this defendant (or a privy) was served more than a year ago, the IPR route is statutorily barred for them and the § 315(b) clock may already have run. New defendants served recently, or parties not yet sued, can still petition — but they should move quickly. Prior-art space for a future petition remains wide open: nothing has been tested against HLS/DASH manifest-rewriting prior art (e.g., early adaptive-streaming manifest/playlist manipulation, CDN URL-rewriting systems, and multi-CDN traffic-allocation art) because no petition has ever been filed.

Pattern signals. No defensive aggregator (e.g., Unified Patents, which is present in the litigation-data chain but only as a data source, not a petitioner) has filed against this patent. No serial-petitioner pattern exists. The patent owner side has been active in district court (Colorado 1:26-cv-01373), not at the PTAB, so there is no signal yet about how aggressively the owner would litigate an IPR. The patent has a long runway — active status with anticipated expiration 2035-05-11 — so the absence of PTAB challenges to date is notable for a patent that has been asserted in court; well-asserted software/streaming patents typically attract IPRs, and this one has not, which may reflect any of: the litigation being recent (2026 case number), settlement dynamics, the § 315(b) bar on the current defendant, or a conscious decision that the art is not strong enough.

---

Recommended next steps

1. Verify the ODP "no proceedings" status directly. Pull the USPTO Patent Center / PTAB E2E listing for US 9,661,049 (and its parent 14/709,171 and provisional 62/072,265) to confirm no petition has been filed under any related docket number. The ODP ingest can lag a brand-new petition by days-to-weeks; re-check before relying on the absence.
2. If you are the defendant in Colorado 1:26-cv-01373 (or any 2026 suit), check the § 315(b) calendar immediately. The one-year IPR bar runs from service of the complaint. If service was recent, a petition can still be filed; if more than a year has passed, IPR is barred and your validity attack must be made in district court (or via an ex parte reexamination, which has no § 315(b) bar and remains available).
3. If the IPR window is open, build the petition on the untested core claim. The claim substance — a manifest server that intersperses segment-file URLs across two different domains in an issued manifest derived from a source manifest — is ripe for § 103 challenges combining pre-2014 adaptive-bitrate manifest/playlist art (HLS/DASH/Smooth Streaming specifications and early CDN URL-rewriting and multi-CDN load-balancing systems). No estoppel exists to constrain you.
4. If no petition is feasible, don't treat the PTAB silence as weakness in district court. The absence of an IPR is not evidence of validity; it likely reflects timing or strategy. Consider § 101 (abstract idea / generic computer implementation) and § 112 in the district-court context, and conduct a fresh prior-art search — the "different domains" limitation and the "issued manifest generated from a source manifest" step are the likely pressure points.
5. Monitor for new filings. If a petition does land, the statutory 1-year trial clock runs from institution, with the institution decision due within roughly 6 months of the filing date. Nothing is pending today, but the Colorado litigation makes a future petition plausible if a different, recently-served defendant enters the picture.

Honesty flags: no PTAB proceeding numbers, panels, grounds, decisions, settlements, or appeals are reported here because none were found — nothing has been fabricated. The district-court case number (1:26-cv-01373, Colorado) comes from the Google Patents/Unified Patents litigation metadata embedded in the patent record and has not been independently docket-verified; its parties, claims, and status should be confirmed on PACER/Unified Patents before relying on it.

The initial searches surfaced the patent text but not the USPTO assignment reel/frame records. Let me dig into the specific recorded assignments and the assignee entities.

Good context emerging — Adeia (public licensing company) is now asserting patents against DIRECTV. Let me trace the specific assignment records and check the litigation history of this patent family.

I hit the search-step limit before I could pull the USPTO Assignment Center records themselves, so I'll be explicit about what is verified (Google Patents legal-event data, which mirrors USPTO recordations, plus litigation dockets) versus what I could not retrieve (USPTO reel/frame numbers and correspondent names). No reel/frame or correspondent is fabricated below — those fields are marked unverified.

Inventors

• Michael Gordon — sole named inventor on US9661049B2 (per Google Patents bibliographic data). At the time of filing he executed an assignment of his interest to DLVR, Inc. (recorded 2016-07-21, same day the continuation US15/215,889 was filed), which is consistent with a founder/employee relationship, though I could not independently verify his title.
• Pattern note: single-inventor patent assigned to his own company at filing — normal. The "all inventors departed within 12 months" heuristic is not applicable (only one inventor), and I found no evidence either way about his post-filing departure.

Original assignee

• DLVR, Inc. (application filed by "Dlvr Inc"; issued patent names "DLVR, Inc." as original assignee).
• Line of business: adaptive streaming video delivery optimization, manifest rewriting, and per-session performance measurement/management — the patent's Detailed Description describes the commercial system (manifest servers, segment file servers, distribution policies, telemetry) in operational detail. Whether DLVR actually shipped a commercial product embodying the claims is not verified; I found no independent product/launch evidence in this session.
• Current status: DLVR no longer owns this patent. It transferred its interest to Adeia Media Holdings LLC on 2025-06-13. Between 2020 and 2021 its patents were encumbered by security interests in favor of Akita Investments LLC (a lender, not an owner), and by 2025-05-28 the collateral was swept into the Adeia group credit facility (Bank of America as collateral agent). I found no bankruptcy filing for DLVR, but the sequence (lender security interests → creditor-chain transfer → Adeia) is consistent with a distressed exit/wind-down of DLVR's patent portfolio rather than an arms-length sale by a thriving operating company. DLVR's current operating status is unverified.

Assignment timeline

Primary-source caveat: I was unable to retrieve reel/frame numbers and correspondent names from USPTO Assignment Center in this session. The entries below are the six recordation events shown on the Google Patents legal-event feed for US9661049B2 (which tracks USPTO assignment recordations); reel/frame and correspondent fields are unverified and should be confirmed at https://assignmentcenter.uspto.gov/ (patent number search: 9661049).

• 2016-07-21 (recorded; execution date not retrieved) — Reel not retrieved

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: Michael Gordon
  • Assignee: DLVR, Inc.
  • Correspondent: not retrieved
  • Context: Inventor-to-company assignment recorded on the filing date of the continuation application — standard employer/founder capture.

• 2020-02-05 (recorded) — Reel not retrieved

  • Conveyance: SECURITY INTEREST
  • Assignor: DLVR, Inc.
  • Assignee: AKITA INVESTMENTS LLC
  • Correspondent: not retrieved
  • Context: Lender takes a security interest over DLVR's patents — debt financing, not ownership.

• 2021-08-30 (recorded) — Reel not retrieved

  • Conveyance: SECURITY INTEREST
  • Assignor: DLVR, Inc.
  • Assignee: AKITA INVESTMENTS LLC
  • Correspondent: not retrieved
  • Context: Second/amended security interest in favor of the same lender — the portfolio stayed encumbered.

• 2025-05-28 (recorded) — Reel not retrieved

  • Conveyance: SECURITY INTEREST
  • Assignor: Adeia Guides Inc., Adeia Holdings Inc., Adeia Imaging LLC, Adeia Inc. (f/k/a Xperi Holding Corporation), Adeia Media Holdings Inc., Adeia Media LLC, Adeia Media Solutions Inc., Adeia Publishing Inc., Adeia Semiconductor Advanced Technologies Inc., Adeia Semiconductor Bonding Technologies Inc., Adeia Semiconductor Intellectual Property LLC, Adeia Semiconductor Solutions LLC, Adeia Semiconductor Technologies LLC, Adeia Solutions LLC, Adeia Technologies Inc.
  • Assignee: BANK OF AMERICA, N.A., AS COLLATERAL AGENT
  • Correspondent: not retrieved
  • Context: Adeia group-wide collateral grant under a public-company credit facility — at this point the '049 patent was already inside the Adeia collateral pool.

• 2025-06-13 (recorded) — Reel not retrieved

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: DLVR, Inc.
  • Assignee: ADEIA MEDIA HOLDINGS LLC
  • Correspondent: not retrieved
  • Context: DLVR transfers the patent outright to the Adeia media-IP holding subsidiary — the ownership-changing event (portfolio acquisition by the Adeia licensing group).

• 2025-06-13 (recorded) — Reel not retrieved

  • Conveyance: CONVERSION
  • Assignor: ADEIA MEDIA HOLDINGS LLC
  • Assignee: ADEIA MEDIA HOLDINGS INC.
  • Correspondent: not retrieved
  • Context: Entity-formality conversion (LLC → corporation); same Adeia holding vehicle, no change in beneficial ownership.

If the Assignment Center shows additional records (e.g., a release of the Akita security interests), they did not surface in the Google Patents feed I had access to.

Timeline diagram

timeline
    title Ownership of US 9661049
    2014 : Provisional application filed
    2015 : Parent application filed
    2016 : Continuation filed
         : Assigned to DLVR Inc
    2017 : Patent issued
    2020 : Akita Investments security interest
    2021 : Second Akita security interest
    2025 : BofA collateral agent interest
         : Assigned to Adeia Media Holdings
         : Converted to Adeia Media Holdings Inc
    2026 : Adeia sues DirecTV

NPE / troll-pattern signals

1. Shell-entity transfer — present (weak). The patent moved from an operating company (DLVR) to Adeia Media Holdings LLC/Inc. (recorded 2025-06-13), a licensing-focused holding vehicle that does not ship products and is the named plaintiff in the 2026 DIRECTV suit. Mitigating fact: Adeia Media Holdings is a subsidiary of Adeia Inc. (NASDAQ: ADEA), a public company with real licensing revenue — not an anonymous registered-agent shell — so this is a licensing-holding subsidiary, not a classic single-purpose LLC.

2. Known asserter in the chain — present (strong). Adeia Inc. (f/k/a Xperi Holding Corporation, formerly Tessera Technologies) is a well-known patent licensing and enforcement company, and the current assignee Adeia Media Holdings Inc. is actively asserting: Adeia Media Holdings Inc. et al. v. Directv, LLC, C.D. Cal. 2:26-cv-07222 (filed ~2026-07-02; plaintiffs Adeia Media Holdings Inc. + Adeia Technologies Inc.; counsel M. Elizabeth Day, Bunsow De Mory LLP). Corroborating context: DIRECTV's DJ action against Adeia (N.D. Cal. 3:25-cv-11048, filed 2025-12-29) references Adeia royalty demands, and Google Patents flags this patent family as in litigation (Colorado 1:26-cv-01373 per Unified Patents; Darts-ip family-litigation entry). I could not independently confirm an RPX/Unified list entry for Adeia in this session, but the assertion activity is documented.

3. Repeat correspondent across the chain — unclear / not verified. I could not retrieve correspondent names from USPTO Assignment Center, so recurrence of a single attorney/firm across the DLVR→Akita→Adeia recordations cannot be assessed. Do not rely on any correspondent finding here.

4. Cascading transfers — present (weak). Three linked recordations compressed into 16 days in 2025: 2025-05-28 (BofA collateral-agent security interest across the Adeia group), 2025-06-13 (DLVR → Adeia Media Holdings LLC), and same-day conversion to Adeia Media Holdings Inc. Combined with the 2020/2021 Akita security interests, this reads as a creditor-cleared, accelerated transfer of an encumbered portfolio into a licensing holding entity. (Whether the chained entities share correspondents/principals is unverified.)

5. Pre-litigation transfer — unclear. The ownership transfer (2025-06-13) preceded the first confirmed suit by the assignee (2:26-cv-07222, ~2026-07-02) by ~13 months — outside the 6-month window. However, DIRECTV's 2025-12-29 DJ action shows Adeia was already making licensing demands within 6 months of the transfer, and the family-litigation flags (Colorado 1:26-cv-01373, 2026) could involve a faster filing that I could not verify. No clean 6-month transfer-to-suit pattern is confirmable.

6. Bankruptcy fire-sale — not present. No Chapter 7/11 record found for DLVR. The Akita security interests (2020/2021) and the Adeia transfer (2025) suggest a distressed/creditor-driven monetization outside bankruptcy.

7. Privateering — unclear. The shape (defunct operating company's patents acquired by a licensing company that asserts them) resembles portfolio monetization, but there is no evidence DLVR directed the DIRECTV assertion or retains a financial interest in it, so classic privateering is not established.

8. Defensive aggregator (anti-NPE) — not present. The chain terminates at an offensive licensor/asserter (Adeia), not RPX/AST/LOT/Unified/OIN. Inverse signal: the patent has not been neutralized.

Verdict

NPE — moderate confidence.

The driving evidence: one strong signal — the chain ends at Adeia Media Holdings Inc., a licensing-holding entity of the publicly traded licensing company Adeia Inc., which is documented as actively asserting (Adeia Media Holdings Inc. et al. v. Directv, LLC, C.D. Cal. 2:26-cv-07222, ~2026-07-02), with the patent transferred from the defunct operating company DLVR on 2025-06-13 after years of lender encumbrance (Akita Investments security interests 2020-02-05 and 2021-08-30; BofA collateral-agent interest 2025-05-28) — plus weak supporting signals (rapid 2025 transfer cascade; creditor-cleared portfolio monetization). Confidence is capped at moderate because Adeia is a public company with R&D/licensing operations rather than an anonymous shell, and because the USPTO reel/frame numbers and correspondent names — the most decisive troll-pattern evidence — could not be verified in this session.

Verification link: https://assignmentcenter.uspto.gov/ — search patent number 9661049 to confirm the six recordations above, retrieve reel/frame numbers, and inspect the correspondent-of-record on the Akita and Adeia filings (that is the step most likely to upgrade or downgrade this verdict).

I'll research the citations and prior art for US Patent 9,661,049. Let me start by searching for the patent's citation records.

The initial searches returned pages that cite 9661049, not the references cited by 9661049. Let me search for the examiner-cited references listed on the patent's front page.

The Google Patents snippets aren't surfacing the citation list. Let me try the related PCT publication (WO2016069896A2, same family) and other routes to find the examiner-cited references.

I've reached the search-step limit, so I'll consolidate what the searches confirmed and what remains unverified, then give the best-supported prior-art analysis with explicit caveats.

---

1. Verification status (read first)

What I could confirm via live search:

• US9661049B2 exists exactly as identified (title, dates, assignee chain, spec content) — confirmed on Google Patents.
• The patent is part of a DLVR, Inc. family sharing the 2014-10-29 priority date: WO2016069896A2, US20160127260A1, US20160127440A1, US10911509B2, US11075970B2, US11533352B2, US11757964B2, US11765219B2, US11936708B2, etc. (Family members sharing the same effective filing date are not §102 prior art against one another.)
• Two older documents appear on pages listing US9661049B2 in their citation/cited-by records: US20120151009A1 and US20130290465A1 (details below). The snippet structure strongly indicates US9661049 cites these documents.

What I could NOT verify (be aware):

• I could not retrieve the complete examiner "Patent Citations (27)"-style list for US9661049 itself (the one such list I surfaced, "Patent Citations (27)", belongs to a different patent — US9800639 — that cites DLVR family members). Treat any reference not explicitly confirmed above as a candidate, not a confirmed citation.
• The verbatim claims of 9661049 remain unverified (as flagged in the prior summary). The §102 mapping below therefore uses the independent-claim substance from the Brief Summary (system / method / CRM embodiments) and is keyed to those elements, not to verified claim numbers.

---

2. Confirmed/strongly-indicated cited references

2.1 US20120151009A1

• Full citation: US Patent Application Publication US20120151009A1, "Method and Apparatus for Generating and Handling Streaming Media Quality-of-Experience Metrics" (title per the linked record on the publication page; assignee as shown on Google Patents).
• Dates: Published 2012-06-14 (predates the 2014-10-29 priority date → prior art under AIA §102(a)(1)); filing date 2011-12-13 (approximate, unverified at the exact-day level).
• Brief description: Discloses generating and handling quality-of-experience (QoE) metrics for streaming media — measuring delivery performance of streamed content, including adaptive-bitrate streaming sessions, and using measurement data to manage delivery. It is a foundational reference in the streaming-telemetry space that DLVR's own later applications (US9661049, US11075970B2) cite.
• §102 analysis: Likely anticipates the measurement-related dependent concepts and arguably reads on the base of independent claims (receive request → serve manifest → measure segment delivery). Key gap: the searches do not confirm that US20120151009A1 discloses the core independent-claim limitation of rewriting the manifest so that the first URL references a segment in a first domain and a second URL references a segment in a different, second domain (interspersed multi-domain URLs). If it lacks that, it does not fully anticipate the independent claims — it would be a §103 combination candidate instead.

2.2 US20130290465A1

• Full citation: US Patent Application Publication US20130290465A1, "System and Method for Proxy Media Caching" (the linked later grant in the snippet is US10462258B2, Huawei Technologies Co., Ltd., granted 2019-10-29).
• Dates: Published 2013-10-31 (prior to 2014-10-29 → §102(a)(1) art); original filing date pre-2013 (unverified exact date).
• Brief description: Discloses proxy-side caching and delivery of media, including handling of segment/manifest requests in streaming delivery — a proxy intercepting media requests and serving/caching segments, which is directly relevant to a manifest server that intercepts requests and issues rewritten manifests.
• §102 analysis: Likely reads on the server-side interception and issued-response portions of the independent claims (receive request → identify source/upstream manifest → respond to user device). Key gap: as with 2.1, no confirmation that it discloses interspersing segment URLs across two different domains within a single issued variant manifest; absent that element it would not fully anticipate the independent claims.

---

3. Candidate prior art (highly relevant, not confirmed as examiner-cited)

These are references in the same art unit/space that an examiner would reasonably have considered; treat them as candidates until checked against USPTO Patent Center's citation list.

(Caveat: the four bracketed candidates are representative of the field from training data; I could not confirm any of them in the live citation record of 9661049.)

---

4. Bottom-line claim-level assessment

• The differentiating limitation of the independent claims (as described in the Brief Summary) is the issued manifest containing a first URL whose segment is hosted in a first domain and a second URL whose segment is hosted in a different second domain — i.e., an intermediary manifest server interspersing URLs across domains within a single variant manifest for measurement/allocation purposes, without client-side software.
• Every pre-2014 reference I identified discloses large portions of the claim (manifest request/response, multi-bitrate segmented video, ordered segment URL lists, server-side manifest handling). None has been confirmed — via the live search results — to disclose the multi-domain interspersal element in a single issued manifest. On the evidence available, no single confirmed reference appears to anticipate the independent claims in full under §102; the strongest case against the patent would be a §103 obviousness combination (e.g., HLS/DASH manifests + CDN URL rewriting + QoE measurement, per US20120151009A1).

---

5. What to do before relying on this

1. Pull the "Patent Citations" tab on Google Patents (patents.google.com/patent/US9661049B2/en) or the USPTO Patent Center bibliographic/IDS data for 9661049 to obtain the complete examiner citation list (including non-patent literature).
2. Retrieve the verbatim claims from USPTO Patent Center and re-key the §102 mapping to actual claim numbers.
3. Confirm whether US20120151009A1 and US20130290465A1 are in fact examiner citations (my inference is based on their pages listing 9661049 as a citing document, which is strong but not a substitute for the official record).

I'd rather flag these as unverified than present a fabricated citation list. If you can provide the front-page "References Cited" block or the Patent Center IDS, I can complete the per-reference §102 table with high confidence.

Obviousness Analysis — U.S. Patent No. 9,661,049 (US9661049B2) under 35 U.S.C. § 103

A. Scope, sources, and honesty flags (read first)

Source for prior art. The full patent text provided to me does not itself contain a "Prior Art / References Cited" section. I recovered the face-of-the-patent citation list from Justia's rendering of the patent (https://patents.justia.com/patent/9661049), which mirrors Google Patents' "Citations" tab. That list is treated here as the Prior Art section for this analysis.

Claims. The verbatim claims were not included in the provided text and my searches did not return them. Consistent with the earlier sections of this analysis, I analyze the substance of the independent claims as reflected in the Abstract and Brief Summary: (1) a system claim — a manifest file server; (2) a method claim; (3) a non-transitory computer-readable medium claim — each centered on receiving a manifest request, identifying a source manifest, generating an issued manifest whose first URL references a segment file hosted in a first domain and whose second URL references a segment file hosted in a different second domain, and transmitting the issued manifest. Exact claim numbers/limitations are unverified — confirm against USPTO Patent Center before relying on any specific claim language.

Verification status of references. I verified titles/content for only two cited references (US8145782, US8327013, both McGowan/Unicorn Media) plus partial content for related family members. For every other cited reference, I can confirm only that it appears on the face of the patent; I have not verified its substantive disclosure. I flag each accordingly and do not attribute unverified disclosures to any reference. This is a framework analysis, not a validity opinion.

---

B. Claimed subject matter in substance

The independent claims require, in substance:

The patent's own disclosure tells us the purpose of L6: to intersperse the operator's own segment-server URLs among third-party service-provider (CDN) URLs so the operator's servers can record delivery telemetry (session IDs, bitrate shifts, first/last-segment measurements) without installing any software on the user device (spec § "Detailed Description"; FIG. 5's issued variant manifests showing sfs.b.manifestserver.net URLs alternating with contentprovider.service-provider.net URLs).

---

C. Person of ordinary skill in the art (PHOSITA)

A PHOSITA at the relevant time (priority date 2014-10-29) would be someone with a B.S. (or equivalent experience) in computer science/engineering, 2–4 years' experience in HTTP-based adaptive-bitrate streaming (HLS, DASH, HDS/Smooth Streaming), CDN architecture and traffic management, and web/HTTP infrastructure (DNS, URL rewriting, caching, redirects), familiar with the HLS media-playlist specification and with standard CDN practices such as URL signing, host-level load balancing, and multi-CDN failover.

---

D. The Prior Art section (face-of-patent citations) — inventory

Verified (content confirmed by search)

1. US8145782B2 — McGowan & Carls (Unicorn Media, Inc.), "Dynamic chunking for media streaming" (filed 2010-12-22; granted 2012-03-27). Verified: a system that dynamically generates index files for chunked HTTP streaming; the index file generator can insert advertisements at any point during playback (i.e., inject URLs pointing to other content/hosts into the index); can create an index file having links to one or more redirectors; the index file generator "may be created at the beginning of the media streaming to provide individualized media content to a particular end user and unique information regarding the streaming session to a content provider"; supports per-session, dynamically generated index files with secure URLs; gathers server-side session/reporting data (stops, plays, pauses, skips) without relying on player beaconing. Source: https://patents.google.com/patent/US8145782B2; https://patentimages.storage.googleapis.com/51/5e/c0/4931be9a491a16/US8145782.pdf

2. US8327013B2 — McGowan & Carls (Unicorn Media), "Dynamic index file creation for media streaming" (filed 2012-03-26; granted 2012-12-04; continuation of 8145782). Verified: systems/methods for receiving requests for a media file and generating corresponding index files used in streaming; index files for multiple sub-streams/bitrates; insertion of advertisements at any point; per-session index generation. Source: https://www.freepatentsonline.com/[8327013](/patent/8327013).html; https://patents.google.com/patent/US8327013B2

3. US8645504B2 — McGowan (Unicorn Media) (granted 2014-02-04) — cited on the face of the patent; same family lineage (per the family history in the 8327013/8954540 records, the Unicorn Media index/chunking family includes 8645504). I have not verified 8645504's title/disclosure independently; treat as a family member with likely related index-file/streaming content.

Cited on the face of the patent but NOT substance-verified by me

• US8051166 (Jenkins et al., 2011) — cited; content unverified.
• US8234350 (Gu et al., 2012) — cited; content unverified.
• US8495675, US8539523, US8762564 (Philpott et al., 2013–2014) — cited; likely Adobe HDS/manifest-related given the assignee and timing, but unverified.
• US20040210320 (Pandya, 2004) — cited; unverified.
• US20120151009 (Bouazizi et al., 2012) — cited; DASH-related (Nokia), unverified.
• US20120198492 (Dhruv et al., 2012) — cited; unverified.
• US20130103849 (Gillies et al., 2013) — cited; unverified.
• US20130290465 (Harrison et al., 2013) — cited; unverified.
• US20130332971 (Fisher et al., 2013) — cited; unverified.
• US20140089465 (van Brandenburg et al., 2014) — cited; likely CDN/DASH-related (TNO), unverified.
• US20140149557 (Lohmar, 2014) — cited; likely Ericsson adaptive-streaming/session-related, unverified.
• US20140230003 (Ma et al., 2014) — cited; likely multi-CDN/content-delivery-related, unverified.
• US20140250230 (Brueck et al., 2014) — cited; likely adaptive-bitrate streaming/manifest-related, unverified.
• US20140280906 (Johns et al., 2014) — cited; unverified.
• US20140337411 (Panje et al., 2014) — cited; unverified.
• US20150180924 (O'Callaghan, 2015) — cited; unverified.
• US20150256577 (Gutiérrez et al., 2015) — cited; unverified.
• US20150296274 (Good et al., 2015) — cited; unverified.
• US20160127260 / US20160127440 (Gordon, 2016) — the inventor's own sibling applications; not § 103 prior art under AIA § 102(b)(2)(C) analysis nuance, but relevant to the family.
• WO2013147983 (2013) — cited; unverified.
• WO2016069896 — the PCT publication of this very family.
• NPL: PCT/US2015/058054 International Search Report & Written Opinion (Apr. 28, 2016); office actions in parent U.S. Appl. 14/709,171.

Transparency note: Because the examiner cited these references, they are the natural first line of attack — but a rigorous § 103 case requires reading each one. Several (e.g., Ma 20140230003, van Brandenburg 20140089465, Lohmar 20140149557, Brueck 20140250230) are, by title/timing/assignee, plausible candidates for disclosing manifest-based routing across multiple delivery networks, and each should be pulled and read before filing anything.

---

E. Limitation-by-limitation mapping (primary combination)

The strongest combination on the verified record is the McGowan/Unicorn Media family (US8145782 + US8327013, optionally + US8645504) in combination with the then-routine multi-CDN/manifest-routing art represented by the cited Ma, van Brandenburg, Lohmar, and/or Brueck applications (to be verified):

---

F. Combinations and motivation to combine (the core of the analysis)

Combination 1 — McGowan/Unicorn Media (US8145782 / US8327013 / US8645504) + multi-CDN allocation art (Ma 20140230003 and/or van Brandenburg 20140089465 and/or Lohmar 20140149557, to be verified)

The combination: Take McGowan's dynamic, per-session index-file generator that already rewrites a source index into a session-specific playlist and injects third-party-host URLs (ad insertion) and redirector URLs. Combine with the routine practice — disclosed in the cited multi-CDN applications and well known in the industry — of allocating content delivery across multiple service providers/CDNs for redundancy and performance. A PHOSITA would configure McGowan's index generator to write some segment URLs pointing to the operator's own segment servers and other segment URLs pointing to a second service provider's domain, i.e., the claimed "first domain / different second domain" pattern.

Motivation:

• Server-side performance measurement without client software. This is the patent's own stated problem (spec: performance "difficult to monitor in actual use… especially difficult to determine from a user's perspective," and the embodiments "do not require the installation of additional software"). McGowan already solved the analogous problem for viewing behavior — its index generator gathers session/reporting data server-side, expressly "as a substitute for or complement to beaconing data" (verified). A PHOSITA wanting delivery-performance data would naturally extend McGowan's server-side measurement concept by ensuring some segment requests traverse the operator's own servers — i.e., by pointing some manifest URLs at those servers.
• Multi-provider allocation is industry-standard. The patent itself recites that "content providers typically allocate the distribution of content among two or more service providers for redundancy purposes." Rewriting manifests to steer segments to different CDNs was a known technique (that is the apparent subject of several cited references — Ma, van Brandenburg, Lohmar). Combining a known manifest-rewriting engine (McGowan) with a known allocation scheme (multi-CDN) is a textbook § 103 "known technique, known to work in the same way, applied to a known device" scenario (KSR).
• Ad-insertion is direct evidence of the "different domain" concept. McGowan's verified ad insertion already places URLs for different content (from an ad server host) into the index file — demonstrating that a PHOSITA had already solved the sub-problem of "one playlist, multiple hosts." Extending that to ordinary segment URLs is an insubstantial change.

Combination 2 — McGowan + adaptive-streaming manifest-rewriting applications (Brueck 20140250230, Gillies 20130103849, Harrison 20130290465, Fisher 20130332971 — to be verified)

If any of these cited applications discloses rewriting HLS/DASH playlists per-request (e.g., for CDN selection, tokenized URLs, or session tracking), it supplies the missing "issued manifest generated from a source manifest" and "different domains" language more explicitly; McGowan supplies the session-level rewrite and measurement purpose. Motivation: same as above — performance management, redundancy, session telemetry.

Combination 3 — single-reference obviousness under McGowan alone (secondary theory)

If the McGowan '782 disclosure of redirectors ("create an index file having links to one or more redirectors on the system… configured to issue the location of the chunk") is read with its ad-insertion teaching, a reasonable argument exists that the "first domain / second domain" limitation is a trivial selection: a PHOSITA implementing McGowan's redirector embodiment for delivery performance measurement would point some chunk requests at the measurement infrastructure and others at CDN hosts. This theory is weaker for claim 1's explicit "second domain different from the first domain" language and should be a fallback.

Why the combination would have been obvious — KSR framing

• Predictable variation: choosing which hosts appear in a playlist's URLs, in a repeating/interspersed pattern, is a predictable design choice once the goals (measurement + multi-CDN allocation) are set.
• Design need + known alternatives: the need to measure and manage multi-CDN delivery was well documented (the patent's own Background admits CDNs such as Akamai/Limelight and multi-provider allocation were standard). The known alternatives — URL rewriting, manifest rewriting, DNS-level steering, redirectors — all point to the same solution.
• No unexpected result: interspersing URLs across domains produces no new technical effect beyond routing segment requests to different servers — a routine result.
• No teaching away: nothing in McGowan or the multi-CDN art teaches against mixing hosts within a single playlist; HLS media playlists expressly support absolute URLs to arbitrary hosts (the patent itself notes manifests "commonly" use relative URLs but that absolute URLs are used in its embodiments — indicating the protocol permits either).

Reasonable expectation of success

High. URL substitution in a text playlist is a trivial transformation; the HLS client simply follows the URLs it is given. The only technical risk (cross-domain cookies/session correlation) was already solved by the art (session IDs in URLs/query strings, per McGowan's session-specific index files and secure URLs).

---

G. Secondary considerations (rebuttal factors)

• No long-felt need shown on this record — the problem (multi-CDN measurement) was openly discussed in the patent's own Background, and McGowan/Unicorn Media's 2010–2012 filings show the dynamic-manifest space was active; if anything, the record suggests the solution space was crowded, favoring obviousness.
• No unexpected results or teaching away identified.
• Commercial success / licensing: the family has been asserted in district court (Colorado 1:26-cv-01373 per the litigation metadata), but litigation activity is not itself evidence of non-obviousness.
• Copying: not shown.

---

H. Conclusion

On the verified record, the strongest § 103 case is: US8145782 (McGowan) alone or with US8327013 (McGowan), in combination with the cited multi-CDN/manifest-routing applications (Ma 20140230003, van Brandenburg 20140089465, Lohmar 20140149557, Brueck 20140250230 — each to be read and verified), rendering the substantive independent claims obvious: McGowan supplies the source-manifest → per-session issued-manifest rewrite, session tracking, server-side measurement, and multi-host URL injection; the multi-CDN art supplies the motivation and mechanism for splitting segment URLs across two different domains; and a PHOSITA would combine them for performance measurement and multi-provider allocation without client-side software — the patent's own stated goals. The "different domains" limitation is the battleground limitation; it is the most likely to carry the day for the patentee if no cited reference expressly shows segment-URL-level splitting across different second-level domains in one playlist, so a fresh search (beyond the face-of-patent citations) for pre-2014 HLS/DASH playlist-splitting and multi-CDN manifest-rewriting systems is essential.

---

I. Verification checklist before relying on this analysis

1. Pull the issued claims of US9661049B2 from USPTO Patent Center (claim text was not in the provided materials; numbering and dependent limitations unverified).
2. Read, in full: US8145782, US8327013, US8645504 (McGowan/Unicorn Media family).
3. Read, in full, the unverified cited applications most likely to carry Combination 1/2: US20140230003 (Ma), US20140089465 (van Brandenburg), US20140149557 (Lohmar), US20140250230 (Brueck), US20130103849 (Gillies), US20130290465 (Harrison), US20130332971 (Fisher), US20140280906 (Johns), US20140337411 (Panje), US20150180924 (O'Callaghan), US20150296274 (Good), US20150256577 (Gutiérrez), US8495675/US8539523/US8762564 (Philpott), US8234350 (Gu), US8051166 (Jenkins), US20120198492 (Dhruv), US20120151009 (Bouazizi), US20040210320 (Pandya), and WO2013147983.
4. Conduct a fresh pre-2014 search for non-cited art on (a) per-request manifest/playlist rewriting in HLS/DASH, (b) multi-CDN segment-level allocation via manifests, and (c) manifest-based telemetry without client SDKs.
5. Confirm the Colorado 1:26-cv-01373 docket (parties, claims, claim-construction posture) if this analysis is being used in that litigation.

Honesty flag: two references were substance-verified (US8145782, US8327013); one family member (US8645504) is identified by family lineage only; all other cited references are verified only as appearing on the face of the patent. No disclosures have been attributed to references I have not read. This document is a technical analysis framework, not a legal opinion.

I'll research the USPTO records for patent 9661049, focusing on PTA/PTE, continuation/divisional applications, family members, and projected expiration.

The first search returned only general PTA information. Let me search more specifically for this patent's term data and family.

The generic searches aren't surfacing USPTO term data. Let me try targeted searches on patent data aggregators and the USPTO record.

I have reached the search-step limit, so I'll consolidate the answer from (a) the authoritative Google Patents record for US9661049B2 provided in the working file, (b) the earlier research sections of this analysis (family, assignment, litigation), and (c) what the live searches did — and did not — confirm. Primary-source caveat up front: I could not retrieve the USPTO Patent Center file wrapper or the printed front-page "Patent Term Adjustment" line for 9661049 in this session. PTA/PTE values below are therefore reported with explicit confidence flags, and nothing is fabricated.

---

1. Patent term adjustments (PTA) — likely zero; unverified

• What is known: US9661049B2 is the issued patent on continuation application US15/215,889, filed 2016-07-21 and granted 2017-05-23 — i.e., a prosecution of roughly 10 months. That is far inside the statutory trigger points for both A-type delay (first Office Action >14 months after filing) and B-type delay (grant >3 years after filing). On the face of the timeline, this application would accrue no A-delay and no B-delay, and I found no indication of any C-delay (interference/derivation/secrecy/appeal). A PTA of zero (or a small number of days) is the strong inference.
• What is unverified: The actual PTA days printed on the patent and in Patent Center. The Google Patents record for this patent lists an "Anticipated expiration" of 2035-05-11, which is exactly 20 years from the parent non-provisional filing date (14/709,171, filed 2015-05-11) with no added days — consistent with zero PTA, but Google's estimate is not authoritative for PTA.
• Verification step: Pull the "Patent Term Adjustment" field and transaction history for 9661049 at https://patentcenter.uspto.gov (and its parent 14/709,171). Also check for any terminal disclaimer — I found none in the available record, and none would alter the 2035-05-11 date here because a continuation tied to the same earliest non-provisional filing date would expire the same day regardless.

2. Patent term extensions (PTE) — not applicable

• PTE under 35 U.S.C. § 156 is available only for patents covering products subject to pre-market regulatory review (FDA-regulated drugs, medical devices, food/color additives). US9661049 is an adaptive-streaming/manifest-rewriting software patent. No PTE applies, and none is recorded. (Confirmed negative: nothing in the Google Patents record, assignment feed, or litigation metadata suggests any § 156 extension.)

3. Continuation applications

• US9661049B2 is itself a continuation. Per the patent's own text: "This application is a continuation of U.S. patent application Ser. No. 14/709,171, filed May 11, 2015 …," which in turn claims benefit of U.S. Provisional App. No. 62/072,265, filed 2014-10-29.
• So the direct chain is: Provisional 62/072,265 (2014-10-29) → Parent non-provisional 14/709,171 (2015-05-11) → Continuation 15/215,889 (2016-07-21) → US9661049B2 (issued 2017-05-23).
• I found no evidence of any continuation or CIP filed from US9661049B2 itself (i.e., no later applications claiming benefit of 15/215,889 specifically), though the DLVR family includes later-granted patents (see § 5) that share the same priority chain.

4. Divisional applications

• None identified. No divisional application is shown in any record reviewed, and nothing in the patent text or assignment/litigation data suggests one. Treat as a clean negative.

5. Related family members (same priority chain)

From the earlier research in this session (Google Patents family listing for US9661049B2) — verified as to existence at the family level, not individually re-verified per member in this step:

Caution consistent with prior sections: the earlier "Prior art" section listed these members from Google Patents' family page; the precise parent/child relationship among the later grants (which are continuations of which application) was not individually docket-verified. Note also that family members sharing the same effective filing date are not § 102/103 prior art against one another — a point already flagged in the Prior Art section.

6. Projected expiration date

• Base statutory term: 20 years from the earliest non-provisional filing date = 2015-05-11 + 20 years = 2035-05-11.
• Recorded projection: Google Patents lists "Anticipated expiration 2035-05-11" — matching the base 20-year date with no PTA added.
• Bottom line projection (subject to verification): 2035-05-11, assuming (a) zero PTA (the strong inference from the ~10-month prosecution), (b) no PTE (inapplicable — software patent), and (c) maintenance fees remain paid. The record shows status "Active" as of the latest data, and the patent's term is not subject to any terminal disclaimer found.
• Maintenance-fee cadence for planning: issued 2017-05-23 → 3.5-year fee was due ~Nov 2020, 7.5-year fee due ~Nov 2024 (both windows now past, with "Active" status implying they were paid), and the 11.5-year fee falls due ~Nov 2028 — a date worth docketing if you are tracking enforceability.

---

Honesty flags (read before relying)

1. PTA days unverified. The zero-PTA conclusion is an inference from the prosecution timeline (10-month pendency from filing to grant on the continuation) and the Google Patents anticipated-expiration date, not a confirmed reading of the USPTO "Patent Term Adjustment" field. Confirm at USPTO Patent Center (patentcenter.uspto.gov) before relying on the exact expiration date — a PTA award or a terminal disclaimer would shift it, and third-party databases (including Google Patents) are expressly not authoritative for those fields.
2. PTE: none applies (statutory category mismatch) — high confidence.
3. Family tree completeness unverified — the later-granted DLVR members (US10911509B2 et al.) were identified at family level in an earlier session step; their exact continuation relationships to 14/709,171 versus 15/215,889 were not individually docket-verified.
4. No divisional found — negative finding based on the records reviewed, not a USPTO family-tree export.
5. The live searches this step returned only general PTA explainers and the patent's own Google Patents page — none carried the per-patent USPTO term data, so the authoritative USPTO check remains outstanding.

DEFENSIVE DISCLOSURE — PRIOR ART PUBLICATION

Docket/File ref: DD-9661049-2026-04-26
Publication date: April 26, 2026 (per task instruction; note the environment header elsewhere reads 2026-09-05 — the earlier date is adopted for this document as instructed)
Author classification: Technical disclosure for defensive-publishing purposes; drafted from the perspective of a person of ordinary skill in adaptive-bitrate streaming (HLS/DASH/CMAF), CDN architecture, and HTTP infrastructure.
Subject patent under study: US 9,661,049 B2 ("Systems and methods of providing interspersed manifest file specifications for adaptive streaming video," DLVR, Inc. / now Adeia Media Holdings Inc.; priority 2014-10-29).

---

0. Verification note and claim basis (updated vs. earlier sections)

Per the task instruction I searched USPTO/Google Patents for the exact identifier 9661049 (no auto-correction; no near-number substitutions). The search confirmed the record US9661049B2 (title, dates, assignee as above) and — importantly — surfaced the verbatim claims via the Justia rendering of the patent (patents.justia.com/patent/9661049). This resolves the "claims unverified" flag carried in earlier sections of this analysis. Verified claim substance used as the derivation seed:

• Claim 1 (system): a system that (i) receives, from a requesting device, a request for data relating to an interspersed manifest file to be created for an adaptive-streaming video encoded at a plurality of reference bitrates, each bitrate having stored video segment files; (ii) determines an interspersing pattern of URLs in which a first subset of URLs (corresponding to a first subset of video segment files hosted by a first domain) is interspersed among a second subset of URLs (corresponding to a second subset of video segment files hosted by a second domain); and (iii) transmits, in response, data identifying the interspersing pattern and data identifying the second domain configured to serve the second subset.
• Claim 2/3/4: user-device attributes (access network; device type) → subset of reference bitrates served.
• Claim 5: repeating pattern of one first-domain URL followed by a plurality of second-domain URLs.
• Claim 6: second domain selected from a plurality of domains associated with a plurality of infrastructure services per a distribution policy defining load allocation.
• Claim 7: segment file servers receive requests only for the first subset and serve them.
• Claim 8 (method) and claim 15 (second system) mirror claim 1.

Scope statement: This document deliberately does not summarize the '049 patent. It publishes new, enabling, dated technical disclosures of derivative systems, each of which is intended to become prior art under 35 U.S.C. § 102(a)(1) (and, where applicable, § 102(a)(2)) against later-filed competitor improvements. Because the '049 claims carry a 2014 priority date, this 2026 publication cannot and does not affect the '049 patent itself; its purpose is to fence off the surrounding improvement space. Every derivative below is (a) technically enabling, (b) expressed with concrete protocols/components/parameters, and (c) accompanied by a Mermaid diagram.

---

PART A — DERIVATIVE VARIATIONS OF THE CORE CLAIM SET

AXIS 1 — MATERIAL / COMPONENT / PROTOCOL SUBSTITUTION

The "component" layer of this software invention is its protocol grammar, URL-authority mechanism, host-selection unit, and transport. Substituting each changes the claimed "interspersing pattern of URLs / first domain / second domain" into distinct, separately patentable-sounding but now-published embodiments.

D1.1 — MPD/BaseURL interspersal (DASH grammar substitution)

Enabling description. Substitute the HLS-style ordered-URL playlist with an MPEG-DASH Media Presentation Description (ISO/IEC 23009-1). The manifest generator receives an HTTP request for /vod/title.mpd, fetches the origin MPD, and emits an issued MPD in which the pattern is expressed not by rewriting individual segment URLs but by (a) declaring multiple <BaseURL> elements (Domain-A, Domain-B) at the Representation level and (b) emitting a <SegmentTemplate> whose $Number$/$Time$ substitution is resolved against alternating BaseURLs according to a run-length-encoded pattern (e.g., media=Domain-A/seg-$Number$.m4s for numbers n ≡ 0 mod 4, else Domain-B/...). The response additionally carries an XML element <Intersperse pattern="1:3" primary="Domain-A" secondary="Domain-B"> implementing the claim element "data identifying the interspersing pattern and the second domain." The dash.js reference player resolves BaseURL order per segment fetch, producing the same first-domain/second-domain request interleaving without client modification.

flowchart LR
    P["DASH Player"] -->|"GET /vod/title.mpd"| G["MPD Generator"]
    G -->|"fetch source MPD"| O["Origin MPD"]
    G -->|"resolve BaseURL candidates"| R["Domain Registry"]
    R -->|"Domain-A, Domain-B"| G
    G -->|"issued MPD: 2 BaseURLs + SegmentTemplate + Intersperse element"| P
    P -->|"seg-1 m4s"| A["Domain-A"]
    P -->|"seg-2 m4s"| B["Domain-B"]
    P -->|"seg-3 m4s"| B
    P -->|"seg-4 m4s"| A

D1.2 — CMAF chunk-level interspersal (low-latency grammar substitution)

Enabling description. Substitute whole-segment (multi-second) URL granularity with CMAF chunk/part granularity as used by LL-HLS (EXT-X-PART) and LL-DASH ($Part$). The generator maintains a rolling media playlist whose parts are 100–500 ms CMAF fragments; the interspersing pattern is applied per part, so Domain-A serves part index i where i mod 4 = 0 and Domain-B serves the rest, all within a single continuously refreshed playlist. The response to the player's playlist request contains the pattern identifier (X-Intersperse: 1:3) plus the second-domain identity in an EXT-X-DEFINE/response header — satisfying "transmitting data identifying the pattern and the second domain" — while the actual delivery interleave happens at part granularity for sub-second adaptive switching.

sequenceDiagram
    participant P as Player
    participant M as Manifest Server
    participant O as Origin Packager
    participant A as Domain-A
    participant B as Domain-B
    P->>M: GET low-latency playlist
    M->>O: refresh source media playlist
    O-->>M: parts 1 to 8 with URIs
    M->>M: assign parts to domains per pattern 1:3
    M-->>P: playlist with EXT-X-PART URIs and X-Intersperse header
    P->>A: GET part-1
    P->>B: GET part-2
    P->>B: GET part-3
    P->>B: GET part-4
    P->>A: GET part-5
    Note over P,B: per-part domain switching under 500 ms

D1.3 — HTTP/3 + Alt-Svc domain advertisement (transport substitution)

Enabling description. Substitute URL-host rewriting with HTTP Alternative Services. The manifest server responds to the player's manifest request over HTTP/3 with the playlist plus Alt-Svc headers advertising two different origins (h3="cdn-a.example:443"; ma=86400, h3="cdn-b.example:443"), and the issued manifest itself is served from Domain-A while the player's subsequent segment requests are drawn to Domain-B via the Alt-Svc cache. The "interspersing pattern" is realized as a time-sequenced Alt-Svc rotation list transmitted as structured field Alt-Svc-Intersperse: 1:3, and the "second domain identity" is the alternate host in the Alt-Svc field — preserving the claim's functional elements while substituting the mechanism by which the second domain is learned and used.

flowchart LR
    C["HTTP/3 Player"] -->|"GET manifest"| M["Manifest Server"]
    M -->|"playlist body from Domain-A"| C
    M -->|"Alt-Svc h3=cdn-a.example and h3=cdn-b.example"| C
    C -->|"QUIC stream 1"| A["Domain-A Edge"]
    C -->|"QUIC stream 2"| B["Domain-B Edge"]
    A -->|"segment n"| C
    B -->|"segment n+1"| C

D1.4 — Token-authenticated interspersal (URL-signing component substitution)

Enabling description. Substitute plaintext host fields with per-domain signed URLs. The generator computes an interspersing pattern (1:3) and, for every URL in the issued manifest, appends a domain-specific capability token: Domain-A URLs carry an HMAC-SHA256 token keyed with KA, Domain-B URLs with KB; each edge independently validates its own token (Akamai/CloudFront-style Policy/Key-Pair-Id or generic ?token=). The response body is the ordered signed-URL list; the response headers carry X-Intersperse-Pattern: 1:3 and X-Intersperse-Second-Domain: cdn-b.example. The functional claim elements (request → determine pattern between two subsets hosted by two domains → transmit pattern + second-domain identity) are all present with signing as the substituted component.

flowchart LR
    C["Player"] -->|"GET issued manifest"| M["Manifest Signer"]
    M -->|"pattern 1:3"| P["Pattern Engine"]
    P -->|"URL list"| K["Per-domain key store"]
    K -->|"HMAC token for Domain-A"| M
    K -->|"HMAC token for Domain-B"| M
    M -->|"signed-URL manifest + X-Intersperse headers"| C
    C -->|"GET seg with tokenA"| A["Domain-A validator"]
    C -->|"GET seg with tokenB"| B["Domain-B validator"]

D1.5 — SSAI stitcher substitution (content-component substitution)

Enabling description. Substitute homogeneous editorial-content segment files with a mixed stream of editorial segments and interstitial advertising assets selected by server-side ad insertion. The stitcher reads SCTE-35 cue markers from the source manifest, obtains ad decisions, and builds the issued manifest whose pattern interleaves the editorial CDN domain (Domain-A subset) with one or more ad-server domains (Domain-B subset). The pattern is therefore a cue-driven function rather than a fixed policy; the response to the player's manifest request identifies the pattern (e.g., #EXT-X-INTERSPERSE:1:3) and the ad domain(s). The functional structure of claim 1 — a first subset hosted by a first domain interspersed among a second subset hosted by a second domain, with the pattern and second-domain identity transmitted — is unchanged.

flowchart LR
    P["Player"] -->|"GET master playlist"| S["SSAI Stitcher"]
    S -->|"read SCTE-35 cues"| M["Content Manifest"]
    S -->|"ad decision request"| A["Ad Decision Server"]
    A -->|"ad URIs"| S
    S -->|"issued interspersed manifest + X-Intersperse header"| P
    P -->|"editorial segment"| C["Content CDN"]
    P -->|"ad segment"| D["Ad CDN"]

D1.6 — Semantic-unit substitution for "domain" (authority granularity substitution)

Enabling description. Substitute the second-level-domain unit with alternative authority granularities that are functionally equivalent for the claims: (a) different anycast prefix sets of one DNS name; (b) different CDN Point-of-Presence clusters behind one hostname (resolved via EDNS Client Subnet); (c) CNAME alias chains resolving to different provider zones; or (d) distinct IPv6 prefixes (2001:db8:aa::/48 vs 2001:db8:bb::/48). The generator maintains a Unit Registry and emits the interspersing pattern over units, where each unit is one of the above classes; the "first domain/second domain" limitation is satisfied by any two non-identical delivery authorities. This publication pre-empts claim-drafting that tries to avoid the word "domain" while preserving the mechanism.

flowchart LR
    G["Manifest Generator"] -->|"pattern over authority units"| R["Unit Registry"]
    R -->|"unit class A"| U1["Anycast set AS-A"]
    R -->|"unit class B"| U2["PoP cluster West"]
    R -->|"unit class C"| U3["CNAME provider zone"]
    G -->|"issued manifest with mixed authority units"| D["User Device"]
    D -->|"GET seg"| U1
    D -->|"GET seg"| U2
    D -->|"GET seg"| U3

---

AXIS 2 — OPERATIONAL PARAMETER EXPANSION

D2.1 — Planetary-scale sharded pattern generation

Enabling description. Scale the single-generator architecture to ~10⁹ concurrent sessions by sharding manifest generation on hash(session_id) mod 4096. Each shard owns a slice of the session-ID space, maintains a local pattern cache keyed by (content provider, device class, access network), and computes the interspersing pattern offline via consistent hashing over the candidate infrastructure-service domain list. The response to each manifest request is the pattern descriptor + second-domain identity, generated in <5 ms p95 from a warm cache, with cold misses fetching the source manifest from origin over a side channel. This publishes the "scale-out of pattern determination" improvement space.

flowchart TD
    LB["Edge Load Balancer"] -->|"hash session_id mod 4096"| S1["Generator Shard 1"]
    LB -->|"hash session_id mod 4096"| S2["Generator Shard 2"]
    LB -->|"hash session_id mod 4096"| S3["Generator Shard N"]
    S1 -->|"pattern cache"| C1["L1 Cache"]
    S2 -->|"pattern cache"| C2["L1 Cache"]
    S3 -->|"pattern cache"| C3["L1 Cache"]
    C1 -->|"shared state"| R["Domain Registry"]
    C2 --> R
    C3 --> R

D2.2 — Sub-500 ms live: per-chunk pattern advance

Enabling description. Operate the pattern engine at the live edge with 100 ms encoder chunks and playlist refresh every 100–200 ms. Each refresh advances the pattern state machine by the number of newly appended chunks, so the interleave boundary (which chunk goes to Domain-A vs Domain-B) is computed incrementally and idempotently from the media sequence number — no per-request re-read of the whole source playlist. The response transmits the pattern state (X-Intersperse-Seq: 12345:1:3) and the second-domain identity once per connection, with subsequent refreshes carrying only deltas. This expands the parameter space to glass-to-glass latencies under 500 ms where the interspersal granularity equals chunk duration.

sequenceDiagram
    participant O as Encoder Farm
    participant G as Live Manifest Generator
    participant P as Player
    participant A as Domain-A Edge
    participant B as Domain-B Edge
    O-->>G: chunk n ready at 100 ms cadence
    G->>G: advance pattern for chunk n
    G-->>P: playlist refresh with delta
    P->>A: GET chunk n from Domain-A
    P->>B: GET chunk n+1 from Domain-B
    Note over P,B: sub-500 ms glass-to-glass

D2.3 — Extreme segment-duration variance classes in one manifest

Enabling description. Expand the duration parameter across classes inside a single presentation: 32 ms keyframe/trick-mode segments, 2 s standard GOP segments, and 600 s long-form catch-up segments may coexist; the interspersing pattern ratio is scaled per duration class (1:3 for standard, 1:8 for trick-mode to limit probe overhead, 1:1 for long-form to increase measurement density). The pattern descriptor transmitted to the player is class-indexed (X-Intersperse: std=1:3,trick=1:8,long=1:1; second=cdn-b.example). Enables frame-accurate scrubbing while retaining per-class delivery measurement.

flowchart LR
    O["Origin Packager"] -->|"duration tagging"| C["Duration Classifier"]
    C -->|"32 ms class"| K["Keyframe sub-manifest"]
    C -->|"2 s class"| S["Standard sub-manifest"]
    C -->|"600 s class"| L["Long-form sub-manifest"]
    E["Pattern Engine"] -->|"ratio 1:8"| K
    E -->|"ratio 1:3"| S
    E -->|"ratio 1:1"| L
    K --> P["Player"]
    S --> P
    L --> P

D2.4 — 100 ms manifest refresh state machine

Enabling description. Model the live-edge generator as a state machine with states Steady, Refresh, and CatchUp. In Steady the generator serves a cached issued manifest; every playlist request (up to 10 Hz) transitions to Refresh, where the pattern advances by the delta in EXT-X-MEDIA-SEQUENCE and the response is written; if the live-edge gap exceeds a threshold the machine enters CatchUp, emitting a burst of Domain-A URLs (the operator's own servers) to backfill missing media before returning to Steady. The transmitted pattern+second-domain data is monotonic per media sequence, allowing players and caches to treat the manifest as an append-only log.

stateDiagram-v2
    [*] --> Steady
    Steady --> Refresh : playlist request
    Refresh --> Steady : pattern advanced
    Refresh --> CatchUp : live edge gap detected
    CatchUp --> Refresh : backfill burst emitted
    CatchUp --> Steady : gap closed

D2.5 — Hyper-dense, run-length-encoded pattern manifests (10⁴+ URLs)

Enabling description. Scale the URL count per manifest to tens of thousands (per-frame or per-50 ms fragment listings for frame-accurate interactive streaming). To bound manifest size, the generator transmits the pattern not as an explicit ordered URL list but as a compact descriptor: run-length-encoded bitmask (first=cdn-a.example,second=cdn-b.example,mask=1000111000111000...) plus a deterministic URL template per subset. The player reconstructs the full URL sequence locally — i.e., "data identifying the interspersing pattern" is literally a compressed pattern, and "data identifying the second domain" is explicit. This publishes the compression/expansion improvement space for pattern transmission.

flowchart LR
    F["Frame Server"] -->|"12000 frame entries"| E["RLE Encoder"]
    E -->|"bitmask + templates + domain identities"| M["Compressed Manifest"]
    M -->|"transmit descriptor"| P["Player"]
    P -->|"local expansion"| X["URL Expander"]
    X -->|"frame n"| A["Domain-A"]
    X -->|"frame n+1"| B["Domain-B"]

D2.6 — Space/remote-edge network parameters (extreme RTT and loss)

Enabling description. Operate the generator for remote terminals over GEO/LEO satellite or deep-space links with one-way delays of 250–600 ms and packet loss up to 20%. The interspersing pattern is computed against ground-station domains (Tokyo GS, Frankfurt GS) and combined with forward erasure coding (RaptorQ/Reed-Solomon over segment payloads) so that the two-domain interleave doubles as a path-diversity mechanism: a lost segment fetch from Domain-A is retried from Domain-B using the same issued manifest. The response includes the pattern and the alternate ground-station domain identity, enabling loss-resilient delivery without client software beyond a standard adaptive player.

flowchart TD
    U["Remote Terminal"] -->|"GET manifest via GEO relay"| G["Ground Manifest Server"]
    G -->|"pattern over GS domains"| R1["GS-1 Tokyo"]
    G -->|"pattern over GS domains"| R2["GS-2 Frankfurt"]
    R1 -->|"erasure-coded segments"| U
    R2 -->|"erasure-coded segments"| U
    U -->|"retry on loss to GS-1"| R2

---

AXIS 3 — CROSS-DOMAIN APPLICATION (3 UNRELATED INDUSTRIES)

D3.1 — Automotive / connected-vehicle telemetry and OTA media (industry 1)

Enabling description. Apply the pattern mechanism to in-vehicle streaming where the "requesting device" is the vehicle head-unit or telematics control unit and the video segment files are (a) over-the-air update deltas, (b) road-hazard camera clips, or (c) passenger infotainment. Domains are: cellular MNO slice (Domain-A), roadside-unit/V2X edge (Domain-B), and OEM cloud CDN (Domain-C). The generator selects the pattern from the vehicle's radio-access context (LTE/5G-SA, V2X range, Wi-Fi offload) and transmits pattern + secondary-domain identity; handover events (MNO→RSU) trigger a new issued manifest without player modification.

flowchart LR
    V["Vehicle Head Unit"] -->|"GET session manifest"| M["OEM Manifest Server"]
    M -->|"context: RAT, V2X range"| X["Context Classifier"]
    X -->|"chosen pattern"| M
    M -->|"Domain-A subset"| A["Cellular MNO Slice"]
    M -->|"Domain-B subset"| B["V2X Roadside Edge"]
    M -->|"Domain-C subset"| C["OEM Cloud CDN"]
    A -->|"segments"| V
    B -->|"segments"| V
    C -->|"segments"| V

D3.2 — AgTech: drone and rover imaging streams (industry 2)

Enabling description. Apply the mechanism to agricultural drone/rover survey video where the requesting device is the ground-control tablet and the segment files are orthomosaic/NDVI camera streams. Domains are on-farm edge compute (Domain-A), a neighboring cooperative's gateway (Domain-B), and an ag-cloud CDN (Domain-C). The generator emits an interspersed manifest so that the on-farm edge captures a measurement subset (scouting analytics, plant-count inference) while the bulk flows to the co-op gateway and cloud; pattern and secondary-domain identity are transmitted per mission, adapting to field connectivity (LTE dead zones → satellite backhaul).

flowchart LR
    D["Ground Control Tablet"] -->|"GET imaging manifest"| G["Field Gateway"]
    G -->|"link quality map"| Q["Connectivity Sensor"]
    Q -->|"pattern choice"| G
    G -->|"Domain-A subset"| E["On-Farm Edge Node"]
    G -->|"Domain-B subset"| N["Co-op Neighbor Gateway"]
    G -->|"Domain-C subset"| C["Ag-Cloud CDN"]
    E -->|"segments"| D
    N -->|"segments"| D
    C -->|"segments"| D

D3.3 — Medical / surgical video and imaging delivery (industry 3)

Enabling description. Apply the mechanism to surgical-video and diagnostic-imaging streaming where the requesting device is a surgeon's display or reading workstation and regulatory/compliance constraints (HIPAA, on-prem data residency) govern routing. Domains are: on-premise PACS origin (Domain-A — measurement subset for latency/QoS auditing), private-cloud CDN (Domain-B), and public CDN (Domain-C, emergency fallback only). The pattern is compliance-constrained: patient-identifiable frames never route to Domain-C; the issued manifest and the transmitted second-domain identity encode the allowed routing policy, enabling per-session QoS auditing of the private cloud without a client SDK.

flowchart LR
    S["Surgeon Display"] -->|"GET low-latency stream manifest"| M["Hospital Stream Manager"]
    M -->|"policy engine"| R["Compliance Policy"]
    R -->|"PHI routing rules"| M
    M -->|"Domain-A subset"| P["On-Prem PACS Origin"]
    M -->|"Domain-B subset"| V["Private Cloud CDN"]
    M -->|"Domain-C only on emergency"| B["Public CDN"]
    P --> S
    V --> S
    B --> S

D3.4 — Medical / remote patient monitoring (RPM) waveforms (industry 3, second derivative)

Enabling description. Extend the medical cross-application to continuous physiologic waveform streaming (ECG/SpO₂) from a wearable gateway to a monitoring hub. Segments are short (250 ms) vital-sign chunks encoded at multiple quality levels; domains are the hospital edge gateway (Domain-A — alarm-detection measurement subset) and a telehealth cloud (Domain-B). The generator transmits the pattern plus the second-domain identity so the hospital edge can measure real-time delivery quality for alarm validity while bulk waveform history goes to the cloud — again without client instrumentation.

flowchart LR
    W["Wearable Gateway"] -->|"GET vital-stream manifest"| M["RPM Orchestrator"]
    M -->|"acuity flag"| A["Acuity Classifier"]
    A -->|"pattern ratio"| M
    M -->|"Domain-A subset"| E["Hospital Edge Node"]
    M -->|"Domain-B subset"| C["Telehealth Cloud CDN"]
    E --> W
    C --> W

D3.5 — Automotive infotainment multi-provider handoff (industry 1, second derivative)

Enabling description. Second automotive derivative for passenger infotainment: the requesting device is the rear-seat infotainment unit; domains are MNO, satellite-broadcast hybrid, and Wi-Fi-offload CDN. The pattern is a handoff-aware function of the vehicle's movement prediction (route waypoints → anticipated MNO coverage loss in tunnels → satellite/wifi fractions increased), and the response carries the pattern plus next-domain identity ahead of the handoff so the player preconnects. Publishes predictive-pattern improvement space in transportation.

flowchart LR
    H["Head Unit"] -->|"GET manifest"| M["OEM Manifest Server"]
    M -->|"route and coverage forecast"| F["Handoff Forecaster"]
    F -->|"domain fractions"| M
    M -->|"Domain-A"| A["MNO Slice"]
    M -->|"Domain-B"| S["Satellite Hybrid"]
    M -->|"Domain-C"| W["Wi-Fi Offload CDN"]
    A -->|"segments"| H
    S -->|"segments"| H
    W -->|"segments"| H

D3.6 — AgTech / smart-irrigation sensor video (industry 2, second derivative)

Enabling description. Second AgTech derivative: fixed field cameras and irrigation-rig cameras streaming to a farm controller over a LoRaWAN+cellular mesh. Segment files are low-bitrate (64–256 kbps) H.264 clips at multiple reference bitrates; domains are field-edge LoRa gateway (Domain-A — measurement subset for spray/nozzle analytics) and ag-cloud (Domain-B). Pattern is battery-aware: when the gateway runs on solar with low state-of-charge, the ratio shifts to favor Domain-B (cloud) so the field-edge radio sleeps longer.

flowchart LR
    C["Farm Controller"] -->|"GET manifest"| G["Farm Aggregator"]
    G -->|"battery state of charge"| B["Power Model"]
    B -->|"battery-aware ratio"| G
    G -->|"Domain-A subset"| E["Field LoRa Edge"]
    G -->|"Domain-B subset"| D["Ag Cloud CDN"]
    E -->|"segments"| C
    D -->|"segments"| C

---

AXIS 4 — INTEGRATION WITH EMERGING TECHNOLOGY

D4.1 — AI/ML (contextual-bandit) pattern policy

Enabling description. Replace the static distribution policy with a contextual multi-armed bandit: for each session, the context vector (access network, device class, geohash, time-of-day, CDN telemetry) is fed to a model that selects the domain-mix action (which infrastructure-service domains appear in the second subset, and at what ratio). The reward is a composite of rebuffer ratio, achieved bitrate, and first-byte latency measured from the first-subset segment deliveries. The generator transmits the pattern+second-domain identity exactly as in claim 1, but the pattern is now a model output updated online per episode.

flowchart LR
    S["Session"] -->|"context vector"| R["Contextual Bandit Policy"]
    R -->|"domain-mix action"| M["Manifest Generator"]
    M -->|"issued manifest + pattern header"| S
    S -->|"delivery reward"| L["Reward Logger"]
    L -->|"gradient update"| R

D4.2 — IoT real-time sensor loop for pattern control

Enabling description. Integrate an IoT sensing plane (edge RTT/loss/jitter probes, CDN health beacons, player-side performance entries reported via the first-subset segment deliveries) into a low-latency telemetry bus. The pattern optimizer consumes streaming aggregates (e.g., 5 s windows) and recomputes the interspersing ratio and second-domain identity before each manifest issuance, so a degrading CDN is de-weighted within one refresh interval. Publishes closed-loop, sensor-driven manifest shaping.

flowchart LR
    I["IoT Edge Sensors"] -->|"RTT and loss probes"| T["Telemetry Bus"]
    P["Player"] -->|"first-subset delivery metrics"| T
    T -->|"rolling aggregates"| O["Pattern Optimizer"]
    O -->|"revised ratio and second domain"| G["Manifest Generator"]
    G -->|"issued manifest"| P

D4.3 — Blockchain delivery provenance and settlement

Enabling description. Integrate per-segment delivery receipts with a permissioned ledger: each time a segment is served from the first subset (operator's own domain) or the second subset (infrastructure-service domain), the serving edge commits a receipt hash (session_id, segment index, byte count, timestamp) to the ledger. A smart contract verifies receipt aggregation against the transmitted pattern and settles payments to each infrastructure service pro-rata per the distribution policy. The pattern itself is derived deterministically from on-chain entropy (block hash) so both parties can audit that the realized interleave matches the issued pattern.

sequenceDiagram
    participant P as Player
    participant M as Manifest Server
    participant C as Smart Contract
    participant A as Domain-A Edge
    participant B as Domain-B Edge
    M->>M: derive pattern from on-chain entropy
    M-->>P: manifest with pattern and second domain
    P->>A: segment requests subset A
    P->>B: segment requests subset B
    A-->>C: receipt hash per segment
    B-->>C: receipt hash per segment
    C->>C: verify against pattern and settle

D4.4 — Generative-AI personalized session manifests

Enabling description. Integrate an LLM-based router that converts free-form user context (device, language, accessibility needs, viewing intent) into a structured manifest specification: chosen reference-bitrate subset (claim 2's attribute-based bitrate selection), ad-load preferences, and the interspersing pattern over content/ad domains. The manifest generator executes the LLM's structured output; the response includes the pattern and second-domain identity as before. Publishes the natural-language-to-pattern improvement space.

flowchart LR
    U["User Context"] -->|"free text and device signals"| L["LLM Router"]
    L -->|"structured manifest spec"| G["Manifest Generator"]
    G -->|"pattern + second domain"| P["Player"]
    P -->|"engagement and QoS signals"| L

D4.5 — Network digital-twin pre-validation of patterns

Enabling description. Before deploying a pattern policy (new ratio, new infrastructure-service domain), simulate it in a network digital twin that models the target ISP topologies, CDN server pools, and player populations. The evaluator scores candidate patterns for rebuffer probability and measurement bias, and only approved patterns are compiled into the generator's policy table. The generator then emits issued manifests per the validated pattern, transmitting pattern and second-domain identity to each session.

flowchart LR
    T["Network Digital Twin"] -->|"candidate patterns"| E["Evaluator"]
    E -->|"validated pattern"| M["Manifest Generator"]
    M -->|"issued manifest"| P["Player"]
    P -->|"actual telemetry"| T

D4.6 — Federated learning across operators (no raw telemetry sharing)

Enabling description. Multiple operators each run local pattern models over their own sessions; only model gradients (not raw delivery logs) are shared with a federated aggregator that produces a global pattern policy. Each operator's manifest generator applies the global policy subject to local constraints and transmits the resulting pattern + second-domain identity. Publishes privacy-preserving collaborative tuning of interspersal policies.

flowchart LR
    O1["Operator A local model"] -->|"gradients only"| F["Federated Aggregator"]
    O2["Operator B local model"] -->|"gradients only"| F
    O3["Operator C local model"] -->|"gradients only"| F
    F -->|"global pattern policy"| G["Manifest Generator"]
    G -->|"issued manifest"| S["Sessions"]

---

AXIS 5 — THE "INVERSE" / FAILURE MODE / LIMITED-FUNCTIONALITY VARIANTS

D5.1 — Fail-safe single-domain degradation

Enabling description. The inverse of the measurement objective: when the first-subset telemetry path (segment-file servers or the metering backend) fails or the distribution-policy store is unreachable, a watchdog transitions the generator to a Degraded or SingleDomain state in which the issued manifest contains zero first-subset URLs and 100% second-subset URLs (a monolithic manifest to one healthy infrastructure-service domain). The response explicitly omits the pattern and second-domain identity (or marks them none), signaling to any instrumentation that measurement is disabled. Ensures availability is never hostage to the measurement plane.

stateDiagram-v2
    [*] --> Normal
    Normal --> Degraded : telemetry path down
    Normal --> SingleDomain : metering quota exceeded
    Degraded --> Normal : telemetry restored
    SingleDomain --> Normal : policy store reachable
    Degraded --> SingleDomain : second subset healthy

D5.2 — Low-power / energy-budget-limited operation

Enabling description. The inverse of "maximize measurement density": for battery-powered requesting devices (phones on cellular, IoT panels, wearables), the generator minimizes radio-active time by coalescing the pattern — e.g., a 1:3 interleave becomes a 0:all or 1:large-block pattern so the device can open one radio bearer per epoch, keep it active for a burst of back-to-back second-subset fetches, and sleep. The transmitted pattern descriptor includes an energy hint (X-Intersperse-Energy: low), and the generator budgets first-subset probe segments against a per-session energy allowance.

flowchart LR
    B["Battery Budget Model"] -->|"energy per segment fetch"| O["Pattern Optimizer"]
    O -->|"coalesced blocks, fewer wakes"| G["Manifest Generator"]
    G -->|"manifest with energy hint"| P["Player"]
    P -->|"radio wakeup count feedback"| B

D5.3 — Privacy-preserving inverse (anti-measurement mode)

Enabling description. The inverse of session telemetry: when a privacy policy applies (GDPR/CCPA opt-out, children's content, anonymous mode), the generator strips session identifiers from all URLs, removes the first-subset (operator-owned measurement) URLs entirely, and shuffles the ordering so that no cross-domain correlation is possible; the second-domain identity is still transmitted, but the pattern is randomized per request and no server retains receipts. This publishes the "measurement-disabled but structurally identical" variant — functionally the claims minus the tracking payload.

flowchart LR
    R["Privacy Policy Engine"] -->|"opt-out signal"| G["Manifest Generator"]
    G -->|"no session ID, zero first-subset URLs"| P["Player"]
    P -->|"segment GET"| D1["Domain-A"]
    P -->|"segment GET"| D2["Domain-B"]
    D1 -->|"no receipts retained"| L["Ephemeral Log"]
    D2 -->|"no receipts retained"| L

D5.4 — Emergency / limited-functionality alert mode

Enabling description. The inverse of multi-provider optimization: in a declared emergency (network isolation, natural disaster, public-safety alert), the generator collapses to a single-government/emergency-CDN domain at minimum viable bitrate, with every URL pinned to that domain and pattern data suppressed. The requesting device's standard adaptive player continues to work unmodified because the manifest grammar is unchanged — only the domain set and pattern are trivialized. Publishes the "maximally constrained" end of the design space.

flowchart LR
    A["Alert Authority"] -->|"emergency activation"| G["Manifest Generator"]
    G -->|"single emergency CDN, min bitrate, no pattern"| P["Device"]
    P -->|"status acknowledgment"| A

D5.5 — Measurement-quota "data-void" mode

Enabling description. The inverse of always-on telemetry: when the operator's measurement quota (data egress allowance for first-subset servers) is exhausted for a billing window, the generator serves manifests with a 0% first-subset fraction — all URLs designate second-subset infrastructure-service domains — while retaining the claim's response shape (pattern 0:all and second-domain identity transmitted). This is the limiting case of claim 5's repeating pattern (zero first-domain URLs per period) and pre-empts dependent-claim variations that attempt to claim "wherein the first subset is empty."

flowchart LR
    Q["Measurement Quota Monitor"] -->|"exhausted"| G["Manifest Generator"]
    G -->|"pattern 0:all, second domain only"| P["Player"]
    P -->|"all segment GETs"| S["Infrastructure Service Domain"]
    S -->|"served segments"| P

D5.6 — Zero-trust pinned-hash degraded manifest

Enabling description. The inverse of trust-every-edge: if token validation or TLS authentication of a candidate second-subset domain fails, the generator emits a degraded issued manifest whose URLs all point to a single trusted domain and whose segment entries carry content hashes (EXT-X-...:SHA-256=...), so the player verifies each segment against the pinned hash before rendering. The transmitted "second-domain identity" is the trusted fallback domain, and no traffic is ever directed to an untrusted infrastructure service. Publishes the security-failure-mode variant of pattern selection.

flowchart LR
    V["Edge Validator"] -->|"authentication failure"| G["Manifest Generator"]
    G -->|"single trusted domain + pinned hashes"| P["Player"]
    P -->|"verify each segment"| H["Hash Verifier"]
    H -->|"valid"| R["Render"]
    H -->|"invalid"| X["Discard and retry"]

---

PART B — COMBINATION PRIOR ART SCENARIOS (PATENT × OPEN-SOURCE STANDARDS)

Each scenario combines the '049 core mechanism with a specific open-source standard/implementation as of its public release date. Each is enabling and dated (projected earliest public availability noted); each would be combinable with the '049 teaching by a PHOSITA.

C1 — '049 mechanism × HLS RFC 8216 + hls.js + nginx/Lua manifest transform

Enabling description. RFC 8216 (HTTP Live Streaming, published Aug 2017) defines media playlists whose entries may be absolute URIs to arbitrary hosts — the protocol hook the '049 mechanism exploits. The open-source hls.js player (Mux, MIT, public since 2017) resolves those absolute URIs without modification. An open-source nginx + Lua/OpenResty access_by_lua transformer intercepts the playlist GET, fetches the origin playlist upstream, rewrites the URI list into a 1:3 Domain-A/Domain-B interleave, and appends response headers X-Intersperse: 1:3 and X-Intersperse-Second-Domain: cdn-b.example. The combination is fully reproducible from public components: RFC 8216 + hls.js + nginx-Lua, all pre-2020.

flowchart LR
    H["hls.js Player"] -->|"GET media playlist"| N["nginx + Lua transformer"]
    N -->|"upstream origin playlist"| O["Origin HLS Server"]
    N -->|"rewritten 1:3 interleaved playlist"| H
    H -->|"segment GET Domain-A"| A["Domain-A"]
    H -->|"segment GET Domain-B"| B["Domain-B"]

C2 — '049 mechanism × MPEG-DASH ISO/IEC 23009-1 + dash.js + Shaka Packager

Enabling description. MPEG-DASH (published 2012; Shaka Packager open-source since 2016) supports multiple <BaseURL> elements and SegmentTemplate substitution. The combination: Shaka Packager produces segmented content; a Python/Node MPD-rewriting proxy (readily assembled from the public dash.js and DASH-IF test vectors) rewrites the origin MPD to carry two BaseURLs (Domain-A, Domain-B) and transmits an Intersperse descriptor element plus the second-domain BaseURL identity in the HTTP response. dash.js fetches Representations by cycling BaseURLs, yielding the claimed interleave. Public availability of all components predates 2020.

flowchart LR
    D["dash.js Player"] -->|"GET MPD"| R["MPD Rewrite Proxy"]
    R -->|"origin MPD"| O["Origin"]
    O -->|"segments via Shaka Packager"| R
    R -->|"two-BaseURL MPD + Intersperse element"| D
    D -->|"Representation segments"| A["BaseURL-1 Domain-A"]
    D -->|"Representation segments"| B["BaseURL-2 Domain-B"]

C3 — '049 mechanism × CMAF (ISO/IEC 23000-19) + FFmpeg + SRS/MediaMTX low-latency origin

Enabling description. CMAF (published 2018) enables chunked encoding; FFmpeg (GPL/LGPL, public) muxes CMAF fragments; SRS or MediaMTX (open-source media servers) expose LL-HLS/LL-DASH playlists. The combination: FFmpeg encodes 200 ms CMAF chunks into an SRS origin; a chunk-router (an open-source Go/Rust middleware) rewrites the playlist so alternate chunks carry Domain-A vs Domain-B authorities, appending the pattern and second-domain identity as playlist tags/headers. The combined system delivers the '049 mechanism at chunk granularity using only public components.

flowchart LR
    F["FFmpeg CMAF Muxer"] -->|"200 ms chunks"| S["SRS or MediaMTX Origin"]
    S -->|"media playlist"| M["Chunk Router Middleware"]
    M -->|"alternate-domain playlist"| P["LL-HLS Player"]
    P -->|"chunk n"| A["Edge Domain-A"]
    P -->|"chunk n+1"| B["Edge Domain-B"]

C4 — '049 mechanism × Apache Traffic Server (ATS) remap + consistent-hash plugin

Enabling description. Apache Traffic Server (open-source, Apache-2.0) provides reverse-proxy remap rules and plugin hooks; a consistent-hash plugin (e.g., header_rewrite + regex_remap, both public) selects among origin/C DN pools. The combination: ATS terminates the manifest GET, fetches the origin manifest, and a regex_remap rule set rewrites segment URIs so that URIs whose index satisfies i mod 4 = 0 map to the operator's own ATS cache (Domain-A) and the remainder map to a second CDN origin (Domain-B), emitting X-Intersperse headers. ATS's public plugin ABI makes this an assembly task, not an invention — relevant as a § 103 combination showing the mechanism was a routine configuration of a standard open-source proxy.

flowchart LR
    P["Player"] -->|"GET manifest"| T["Apache Traffic Server"]
    T -->|"regex remap + consistent hash"| R["Remap Plugin"]
    R -->|"origin manifest fetch"| O["Origin"]
    R -->|"pattern rewrite"| T
    T -->|"issued interleaved manifest"| P

C5 — '049 mechanism × SCTE-35 + Shaka Packager + open-source SSAI (e.g., Livepeer/MistServer)

Enabling description. SCTE-35 (public standard) carries ad cues in transport streams; Shaka Packager (open source) passes SCTE-35 into DASH/HLS; open-source SSAI packages (Livepeer, MistServer) perform server-side stitching. The combination: the SSAI package reads cue markers from the packed manifest, obtains ad assets from an ad CDN (Domain-B), interleaves editorial segment URIs (Domain-A) with ad URIs (Domain-B) in one issued manifest, and returns the pattern + ad-domain identity in the response. Because the '049 mechanism as applied to ad insertion was therefore implementable by combining three public standards/tools, later "ad-domain interspersal" claims would be obvious over this combination.

flowchart LR
    O["Shaka Packager"] -->|"SCTE-35 timed cues"| S["Open SSAI Stitcher"]
    S -->|"ad decision"| A["Ad Server"]
    S -->|"interspersed content and ad URIs"| P["Player"]
    P -->|"content segment"| C["Content CDN Domain-A"]
    P -->|"ad segment"| D["Ad CDN Domain-B"]

---

PART C — PRACTICAL NOTES FOR THE DEFENSIVE FILE

1. Publication mechanics. To be effective as § 102(a)(1) prior art, this disclosure should be deposited with a dated, publicly accessible defensive-publishing venue (e.g., the IP.com Prior Art Database, arXiv/SSRN with a fixed deposit date, or a dated blog/repository snapshot with a trusted timestamp) on or before the target competitor filing date. The earliest of (a) public accessibility and (b) any later grant of a patent on this disclosure establishes the critical date.
2. What this fences. The derivatives above collectively surround: (i) the pattern-representation improvement space (compressed/RLE, class-indexed, cue-driven, ML-selected, energy-budgeted, privacy-randomized patterns); (ii) the "second domain" selection space (infrastructure-service registry, Alt-Svc, CNAME/anycast/prefix units, blockchain-entropy-derived, zero-trust fallback); (iii) the granularity space (segment → CMAF part → frame); (iv) the failure-mode space (empty first subset, single-domain collapse, measurement-quota void); and (v) the cross-industry transplant space (automotive, AgTech, medical).
3. Diagram validity note. All Mermaid diagrams above are written to render with standard Mermaid (flowchart/sequenceDiagram/stateDiagram-v2). They are provided as architectural summaries; the enabling text is the operative disclosure.
4. Honesty flags. (a) Claim text quoted in § 0 is from the Justia rendering surfaced by the search and matches the substance of the earlier Brief-Summary analysis; exact dependent-claim numbering beyond claim 7/15 boundaries should be checked on USPTO Patent Center before litigation use. (b) Open-source component release dates (hls.js 2017, Shaka Packager 2016, CMAF 2018, RFC 8216 2017) are cited from general knowledge and should be re-verified against each project's tag history if a specific critical date matters. (c) This document is a technical prior-art publication, not a legal opinion on validity of the '049 patent.