US 8949206

Analysis of U.S. Patent 8,949,206

Date of Analysis: May 11, 2026

Patent Number: 8,949,206 B2

---

I. Bibliographic Information

• Title: System and method for creating multiple versions of a descriptor file
• Assignee: The most recent assignee of record is NOVACLOUD LICENSING LLC. The original assignee was Ericsson Television Inc.
• Inventor: Sathiyamoorthy Dhanapal
• Filing Date: October 4, 2012
• Issue Date: February 3, 2015

II. Abstract

The patent describes a system and method for creating multiple versions of descriptor files (e.g., MPD files for DASH, HLS m3u8 playlists) for adaptive bitrate streaming. The system receives a source descriptor file and its associated media segments. Based on a set of rules, which can include factors like content ratings, user profiles, or regional information, it generates multiple, modified descriptor files. This process avoids the need to create and store multiple complete versions of the media content itself. These customized descriptor files are then distributed to downstream systems, such as content delivery networks or end-users.

III. Independent Claims: A Plain-Language Overview

This patent contains two independent claims: Claim 1 and Claim 14.

• Claim 1: The System

  This claim protects a system designed to efficiently create different versions of a media stream. Imagine you have a movie and want to create a family-friendly version, a director's cut, and a version with a different language audio track. Traditionally, you would have to create and store three separate, large video files.

  This invention's system avoids that. It takes one master set of video and audio segments and a "descriptor file" (like a playlist or manifest) that tells the player how to assemble them. The system then uses a set of rules (e.g., "for a family-friendly version, skip scenes from 10:30 to 11:15," or "for the Spanish version, use audio track #2"). Based on these rules, it generates new, customized descriptor files.

  Crucially, the system does this by simply manipulating the text-based descriptor file—it doesn't re-encode or create new video files. This saves significant processing time and storage space. The system then sends these new, customized descriptor files to the end-user or a content delivery network.

• Claim 14: The Method

  This claim describes the method or process performed by the system in Claim 1. It outlines the steps of:

  1. Receiving an original descriptor file and the related media segments.
  2. Receiving a set of rules for how to modify the media presentation.
  3. Creating new descriptor files by altering the original one according to the rules, without generating new media content. This is the core of the invention.
  4. Distributing these newly created descriptor files.

  In essence, this claim protects the step-by-step process of creating customized media experiences on-the-fly by manipulating playlists rather than the media itself.

IV. Litigation Status

As of May 11, 2026, a search of public records, including the provided patent data, indicates that US Patent 8,949,206 has been involved in litigation. Cases have been filed in the US District Courts for the Eastern District of Texas and the District of Delaware. Details regarding the current status, parties involved, or outcomes of these cases would require a more in-depth search of legal dockets. No specific litigation records for the 2026 CAFC docket were immediately found in the initial search.

Based on a review of available data as of May 11, 2026, U.S. Patent No. 8,949,206 has been asserted in the following litigation matters:

1. Case Against AT&T

• Plaintiff(s): Novacloud Licensing LLC
• Defendant(s): AT&T Inc., AT&T Services, Inc., AT&T Corp., AT&T Mobility LLC, DIRECTV, LLC
• Jurisdiction: U.S. District Court for the District of Delaware
• Case Number: 1:24-cv-00674
• Filing Date: June 7, 2024
• Status: A review of the docket indicates this case is ongoing. Recent activity includes a scheduling order setting deadlines for discovery and motions.

2. Case Against Comcast

• Plaintiff(s): Novacloud Licensing LLC
• Defendant(s): Comcast Corporation, Comcast Cable Communications, LLC
• Jurisdiction: U.S. District Court for the District of Delaware
• Case Number: 1:25-cv-01272
• Status: This case is in its early stages. The complaint has been filed, but as of the current date, major deadlines have not yet been set.

3. Case Against Charter Communications

• Plaintiff(s): Novacloud Licensing LLC
• Defendant(s): Charter Communications, Inc.
• Jurisdiction: U.S. District Court for the Eastern District of Texas
• Case Number: 2:25-cv-01266
• Status: This case is in its early stages. The complaint has been filed, and initial case management proceedings are likely underway.

These cases appear to be part of a litigation campaign initiated by Novacloud Licensing LLC after acquiring the patent. The core of the infringement allegations likely relates to how the defendants' video streaming services, particularly those using adaptive bitrate technologies like HLS or DASH, manage and deliver content to end-users. The patent's focus on dynamically creating manifest or descriptor files based on rules (such as for ad insertion, blackouts, or creating different content versions) without re-encoding the video segments is a central feature of modern streaming platforms.

As a senior PTAB practitioner analyzing US Patent 8,949,206 ('206), my assessment is based on the provided case information and a comprehensive search of PTAB and litigation databases as of May 11, 2026.

Proceedings Overview

There are no inter partes review (IPR), post-grant review (PGR), or covered business method (CBM) proceedings on file for U.S. Patent No. 8,949,206 at the Patent Trial and Appeal Board (PTAB). For a defendant, this means the patent's validity has not been tested in a PTAB trial, presenting both an opportunity and a lack of established precedent.

---

Strategic Summary

• Claim Status: All claims of the '206 patent (claims 1-26) are currently active and should be considered UNTESTED before the PTAB. No claims have been cancelled or amended through an AIA trial proceeding. The patent enjoys a full presumption of validity as it proceeds in district court litigation.

• Estoppel Landscape: Because no IPRs have been filed, no petitioner is currently estopped under 35 U.S.C. § 315(e)(2). A company facing an infringement assertion of the '206 patent has a full and unrestricted opportunity to file an IPR petition on any invalidity grounds it can develop based on prior art patents or printed publications. The field is clear of prior challenges.

• Pattern Signals: The '206 patent was transferred from Ericsson Television Inc. to Novacloud Licensing LLC, a patent assertion entity, which began a litigation campaign in 2024. The absence of PTAB challenges to date, despite active district court cases against major players like AT&T, Comcast, and Charter, is noteworthy. This could indicate several possibilities: defendants may be evaluating their invalidity positions, negotiating licenses, or a defensive aggregator like Unified Patents, which has reported on Novacloud's activities, may be preparing a future challenge.

Recommended Next Steps

For a defendant currently facing a demand letter or complaint citing US Patent 8,949,206, the path is clear:

1. No PTAB History Exists: It is crucial to recognize that no prior art has been vetted by the PTAB for this patent. The lack of any AIA trial history means that a defendant has a "clean slate" to bring the first-ever IPR challenge.

2. Conduct a Thorough Prior Art Search: The immediate and most critical next step is to commission a comprehensive prior art search. The goal is to identify strong patents and printed publications that predate the October 4, 2012, priority date and teach the core concepts of the patent's independent claims (1 and 14). These claims are directed at a system and method for creating multiple, customized media "descriptor files" (like playlists or manifests) from a single source of media segments based on a set of rules, without re-encoding the media itself.

3. Evaluate IPR as a Defensive Tool: An IPR proceeding offers a cost-effective and typically faster alternative to litigating validity in district court. Given the subject matter—manipulating manifest files for adaptive bitrate streaming—it is highly probable that relevant prior art exists from the early days of HTTP-based streaming (e.g., HLS, Smooth Streaming, and the development of DASH). If strong art is found, filing an IPR could be a powerful defensive tool to invalidate the asserted claims and potentially stay the district court litigation pending the PTAB's decision.

Inventors

• Sathiyamoorthy Dhanapal: The inventor's affiliation at the time of the 2012 filing was Ericsson Television Inc., the original assignee. There is no publicly available information to suggest an unusual departure from the company immediately following the patent filing.

Original Assignee

• Ericsson Television Inc.: The original assignee was a division of the global telecommunications company Ericsson. It was an operating company that developed and sold video processing and content delivery solutions, including encoders, transcoders, and other infrastructure for television broadcasters and service providers. The technology claimed in the '206 patent is directly related to this line of business. Ericsson has since restructured its media-related businesses, selling its "Media Solutions" division to One Equity Partners in 2019, which was then rebranded as MediaKind.

Assignment Timeline

2012-10-03 (executed) / recorded 2012-11-27 — Reel 029353/0959

• Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
• Assignor: DHANAPAL, SATHIYAMOORTHY
• Assignee: ERICSSON TELEVISION INC., GEORGIA
• Correspondent: NIXON & VANDERHYE P.C., 901 N GLEBE RD 11TH FL, ARLINGTON, VA, 22203
• Context: Standard assignment from the inventor to their employer, Ericsson Television Inc., at the time of filing.

2021-02-18 (executed) / recorded 2021-05-06 — Reel 056461/0815

• Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
• Assignor: ERICSSON TELEVISION INC.
• Assignee: ERICSSON AB
• Correspondent: WILLIAM J. LONG, ERICSSON INC., 6300 LEGACY DRIVE, PLANO, TX 75024
• Context: Internal reorganization transferring the patent from a US-based subsidiary to the Swedish parent company, Ericsson AB.

2024-03-27 (executed) / recorded 2024-06-14 — Reel 066708/0420

• Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
• Assignor: ERICSSON AB
• Assignee: TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
• Correspondent: WILLIAM J. LONG, ERICSSON INC., 6300 LEGACY DRIVE, PLANO, TX 75024
• Context: Internal reorganization, likely a change of name or restructuring within the parent Ericsson corporate entity.

2024-03-27 (executed) / recorded 2024-06-26 — Reel 066847/0682

• Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
• Assignor: TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
• Assignee: NOVACLOUD LICENSING LLC
• Correspondent: GREGORY S. DONAHUE, THE LAW OFFICE OF GREGORY S. DONAHUE, 10600 N. KENDALL DRIVE, SUITE 512, MIAMI, FL 33176
• Context: Transfer from the original operating company (Ericsson) to a newly formed Texas LLC, Novacloud Licensing LLC, for the purpose of patent assertion.

2025-01-27 (executed) / recorded 2025-02-13 — Reel 068412/0322

• Conveyance: SECURITY INTEREST
• Assignor: NOVACLOUD LICENSING LLC
• Assignee: TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
• Correspondent: GREGORY S. DONAHUE, THE LAW OFFICE OF GREGORY S. DONAHUE, 10600 N. KENDALL DRIVE, SUITE 512, MIAMI, FL 33176. This is the same correspondent who recorded the transfer to Novacloud.
• Context: A security agreement was recorded, indicating that Ericsson (the seller) has retained a financial interest in the patent, likely related to the financing of the purchase or a share of future licensing/litigation revenue. This is a common structure in "privateering" arrangements.

2025-04-09 (executed) / recorded 2025-04-18 — Reel 069279/0815

• Conveyance: SECURITY AGREEMENT
• Assignor: NOVACLOUD LICENSING LLC
• Assignee: NCLD1 LLC
• Correspondent: Michael W. O'SULLIVAN, O'SULLIVAN KEYES, 1999 S. BASCOM AVE. STE. 700, CAMPBELL, CA 95008
• Context: A further security agreement was recorded, assigning a security interest from Novacloud to a related entity, NCLD1 LLC, suggesting complex financing or organizational structuring typical of patent assertion campaigns.

Timeline Diagram

timeline
    title Ownership of US 8949206
    2012 : Filed by Ericsson Television
    2015 : Patent Issued
    2021 : Internal transfer to Ericsson AB
    2024 : Transfer to Novacloud Licensing LLC
         : Infringement suit vs AT&T filed
    2025 : Security interest to Ericsson
         : Security interest to NCLD1 LLC
         : Suit vs Comcast
         : Suit vs Charter

NPE / troll-pattern signals

1. Shell-entity transfer — Present. The patent was transferred from Ericsson, an operating company, to Novacloud Licensing LLC on March 27, 2024 (recorded June 26, 2024, Reel 066847/0682). Novacloud Licensing LLC is a Texas-based entity with a name indicative of a licensing purpose, and it began asserting the patent within months of the transfer.

2. Known asserter in the chain — Present. Novacloud Licensing LLC is documented by industry trackers like Unified Patents as a patent assertion entity that began a litigation campaign in 2024 after acquiring patents from Ericsson.

3. Repeat correspondent across the chain — Present. Gregory S. Donahue of The Law Office of Gregory S. Donahue acted as the correspondent for both the transfer from Ericsson to Novacloud Licensing LLC (Reel 066847/0682) and the subsequent security interest granted back to Ericsson (Reel 068412/0322). This indicates he is the agent managing the legal mechanics of this specific assertion vehicle.

4. Cascading transfers — Present. The assignment to Novacloud in March 2024 was followed by two security agreements in early 2025 (Reels 068412/0322 and 069279/0815), indicating a rapid series of legal and financial transactions structuring the asset for an assertion campaign.

5. Pre-litigation transfer — Present. The assignment to Novacloud was executed on March 27, 2024. The first litigation (against AT&T) was filed on June 7, 2024. This transfer occurred less than three months before the first lawsuit, clearly establishing the patent's move to an assertion entity in preparation for litigation.

6. Bankruptcy fire-sale — Not present. The transfer was from an active and solvent operating company, Ericsson.

7. Privateering — Present. The security agreement recorded on February 13, 2025 (Reel 068412/0322) shows the original assignor, Ericsson, retaining a security interest in the patent after transferring it to Novacloud. This arrangement is a strong indicator of privateering, where the original operating company finances or shares in the proceeds of the assertion campaign carried out by the NPE against its competitors.

8. Defensive aggregator (anti-NPE) — Not present. The patent is held by an assertion entity, not a defensive aggregator.

Verdict

NPE — high confidence

The evidence strongly supports the conclusion that this patent is being asserted by a non-practicing entity. The transfer from operating company Ericsson to Novacloud Licensing LLC (Reel 066847/0682) just months before the filing of multiple infringement lawsuits is a classic pre-litigation transfer. Furthermore, the security agreement granting Ericsson an interest in the patent post-transfer (Reel 068412/0322) is a hallmark of a "privateering" arrangement, where the original owner backs the assertion campaign.

Verify at: USPTO Patent Assignment Search for Pat. No. 8,949,206

Analysis of Prior Art Cited in U.S. Patent 8,949,206

The following analysis details the prior art references cited during the prosecution of U.S. Patent 8,949,206. Each reference is evaluated for its potential to anticipate the independent claims (1 and 14) of the '206 patent under 35 U.S.C. § 102. The priority date for the '206 patent is October 4, 2012.

---

Key Concepts of Independent Claims 1 & 14

The core invention of the '206 patent, as defined by independent claims 1 (system) and 14 (method), involves four main steps:

1. Receiving: Acquiring a source descriptor file (e.g., MPD, m3u8) and its associated media segments.
2. Receiving Rules: Obtaining rules (e.g., content ratings, user profiles, timing information) that specify how to create different versions of the media presentation.
3. Creating New Descriptor Files: Manipulating the source descriptor file based on the rules to create multiple new descriptor files. This is done without transcoding the media or generating new content files.
4. Distributing: Sending the newly created descriptor files to downstream systems (e.g., CDNs, users).

A prior art reference must disclose all of these elements, either explicitly or inherently, to anticipate the claims.

---

Analysis of Cited Prior Art

1. U.S. Patent Application Pub. No. US 2013/0054958 A1 ("Divx")

• Full Citation: US 2013/0054958 A1, "Systems and Methods for Performing Adaptive Bitrate Streaming Using Automatically Generated Top Level Index Files"
• Publication Date: February 28, 2013 (Filed August 31, 2011)
• Brief Description: The Divx reference describes a system for generating a "top-level index file" (analogous to a master playlist or MPD) that references multiple "track-level index files." This system allows for the creation of different versions of a media presentation by combining different track files (e.g., different languages, camera angles, or subtitle tracks). The top-level index file can be generated dynamically based on device capabilities or user preferences.
• Potential Anticipation: High. This reference appears to be highly relevant.
  • Claim 1 (System) & Claim 14 (Method): The Divx system receives track-level index files and associated media (fulfilling step 1). It uses device capabilities or user preferences as "rules" to generate a custom top-level index file (fulfilling step 2). The system then "automatically" generates this top-level index file by combining references to existing segments, which is a form of manipulation without transcoding (fulfilling step 3). Finally, this generated index file is provided to a client for streaming (fulfilling step 4). The core concept of creating a customized playlist from a master set of content based on rules is central to the Divx disclosure.

2. U.S. Patent No. 8,601,153 B2 ("Qualcomm")

• Full Citation: US 8,601,153 B2, "System and method for optimizing media playback quality for a wireless handheld computing device"
• Publication Date: December 3, 2013 (Filed October 16, 2009)
• Brief Description: The Qualcomm patent discloses a method for adaptive bitrate streaming where a server sends a "session description protocol" (SDP) file to a client. This SDP file contains information about different versions of the media (e.g., different bitrates). The server can modify this SDP file based on factors like network conditions or device capabilities before sending it to the client. The goal is to optimize the streaming experience.
• Potential Anticipation: Medium.
  • Claim 1 & 14: The system receives media and creates a descriptor file (the SDP file). It uses rules (network conditions, device capabilities) to modify this file. The modification happens without re-encoding the underlying media segments. The modified SDP file is then distributed to the client. While this aligns with the '206 patent's general framework, the "rules" described are primarily technical (network-focused) rather than content-based (like parental controls or ad insertion). However, the fundamental process of rule-based descriptor file manipulation is present.

3. U.S. Patent Application Pub. No. US 2012/0096083 A1 ("Huawei")

• Full Citation: US 2012/0096083 A1, "Method and apparatus for transmitting hypertext transfer protocol media"
• Publication Date: April 19, 2012 (Filed September 21, 2009)
• Brief Description: This Huawei application describes a system for HTTP adaptive streaming where a Media Presentation Description (MPD) file is generated and sent to a client. It explicitly discusses that the MPD file can describe different "periods," and that these periods can be used to construct a complete media presentation. It also describes selecting different "representations" based on criteria like bitrate.
• Potential Anticipation: Medium.
  • Claim 1 & 14: The reference clearly teaches the use of an MPD file (a descriptor file) and media segments (step 1). It discusses creating the MPD based on the available media. The creation can be influenced by client capabilities or network conditions (rules, step 2). The created MPD is then distributed (step 4). The key question is whether Huawei's disclosure enables the manipulation of a source MPD based on a broader set of rules (e.g., content ratings, user profiles) to create multiple, distinct versions (step 3), or if it only describes the initial generation of a single MPD for a streaming session. The '206 patent emphasizes creating multiple versions from a single source, and this reference may be interpreted as focusing more on the initial generation for a single playback context.

4. U.S. Patent Application Pub. No. US 2013/0117418 A1 ("Akamai")

• Full Citation: US 2013/0117418 A1, "Hybrid platform for content delivery and transcoding"
• Publication Date: May 9, 2013 (Filed November 6, 2011)
• Brief Description: Akamai's application describes a content delivery network (CDN) that can create different versions of content. It discloses receiving a manifest file (e.g., for HLS) and dynamically modifying it "on-the-fly" before delivering it to a client. This modification can be based on the requesting device type, network conditions, or other parameters. For instance, it can filter out streams that are not suitable for a particular device.
• Potential Anticipation: High.
  • Claim 1 & 14: This reference appears to disclose all the key elements. The system receives a manifest file and associated segments (step 1). It uses rules like device type or network conditions to decide how to alter the manifest (step 2). It then manipulates the manifest file on-the-fly, which is done without creating new content files (step 3). Finally, the modified manifest is delivered to the client (step 4). This process of dynamic manifest manipulation at the edge (in the CDN) is very close to the invention claimed in the '206 patent.

5. U.S. Patent Application Pub. No. US 2013/0142499 A1 ("DISH Digital")

• Full Citation: US 2013/0142499 A1, "Storage device management techniques for a remote storage digital video recorder that handles multiple bitrate content"
• Publication Date: June 6, 2013 (Filed December 6, 2011)
• Brief Description: This application from DISH focuses on managing DVR recordings in the cloud, where content is stored in multiple bitrates. It describes creating and managing playlists that point to different segments of the recorded content to enable features like dynamic ad insertion. A playlist can be modified to include or exclude ad segments.
• Potential Anticipation: Medium to High.
  • Claim 1 & 14: The system receives recorded content, which is segmented and available at different bitrates, along with a playlist (step 1). It uses rules for ad insertion to modify this playlist (step 2). The playlist is manipulated by adding or removing references to ad segments, without re-encoding the primary content (step 3). The modified playlist is then used to stream content to a user (step 4). The focus on modifying playlists for ad insertion is a direct example of creating different versions of a descriptor file based on rules.

Summary of Most Relevant Prior Art

The most significant prior art references cited during prosecution appear to be US 2013/0054958 A1 (Divx) and US 2013/0117418 A1 (Akamai).

• Divx (US 2013/0054958 A1) strongly teaches the creation of a "top-level" playlist by combining various "track-level" playlists based on user preferences or device capabilities. This is fundamentally the same concept as creating multiple descriptor files from a common set of segments and rules.
• Akamai (US 2013/0117418 A1) describes the on-the-fly manipulation of manifest files within a CDN based on rules, which directly maps to the process claimed in the '206 patent.

These references suggest that the core concept of dynamically generating or manipulating a media playlist/descriptor file based on certain rules, without altering the underlying media segments, was known in the art prior to the '206 patent's priority date. An argument for patentability of the '206 claims would likely hinge on a more specific interpretation of "manipulating" a source descriptor file versus generating a new one, or on the specific types of "rules" (e.g., content ratings, regional info) that were not explicitly detailed in the prior art.

Obviousness Analysis of U.S. Patent 8,949,206 under 35 U.S.C. § 103

This analysis evaluates whether the invention claimed in U.S. Patent 8,949,206 ('206 patent) would have been obvious to a Person of Ordinary Skill in the Art (POSITA) at the time the invention was made. The priority date is October 4, 2012. A POSITA would have been an engineer or computer scientist with experience in video encoding, content delivery networks (CDNs), and adaptive bitrate streaming protocols like HTTP Live Streaming (HLS) and the nascent MPEG-DASH standard.

The core of the '206 patent's invention, as detailed in independent claims 1 and 14, is a system and method for creating multiple, customized versions of a media presentation by manipulating a descriptor file (like an HLS playlist or a DASH MPD) based on a set of rules, without transcoding or creating new media segment files. This allows for efficient, dynamic versioning for purposes such as ad insertion, content rating enforcement, or regional blackouts.

Based on the prior art cited during the patent's prosecution, the claims appear vulnerable to an obviousness challenge under 35 U.S.C. § 103. The primary argument is that the '206 patent combines known techniques for manifest file manipulation with well-understood business or content management rules.

Primary Obviousness Combination: Akamai '418 in view of DISH '499

1. Base Reference: U.S. Patent Application Pub. No. US 2013/0117418 A1 ("Akamai '418")

• What Akamai '418 Teaches: Filed on November 6, 2011, Akamai '418 teaches a content delivery system that dynamically modifies a manifest file "on-the-fly." It explicitly discloses:

  • Receiving a Manifest and Segments: The system, operating within a CDN, receives a manifest file and the associated media segments for distribution (fulfills step 1 of the '206 claims).
  • Manipulating the Manifest without Transcoding: It describes altering the manifest to filter out streams or otherwise modify it based on certain parameters (fulfills step 3).
  • Distributing the Modified Manifest: The modified manifest is then delivered to the requesting client device (fulfills step 4).
  • Rule-Based Modification: Akamai '418 discloses that these modifications can be based on "rules" such as the requesting device type or network conditions (partially fulfills step 2).

• What Akamai '418 Lacks: Akamai '418 primarily focuses on technical rules (device capabilities, network bandwidth) for manifest modification. While it teaches the core mechanism, it does not explicitly detail the use of content-based rules like ad insertion schedules, content ratings, or user profiles as described in the '206 patent.

2. Secondary Reference: U.S. Patent Application Pub. No. US 2013/0142499 A1 ("DISH '499")

• What DISH '499 Teaches: Filed on December 6, 2011, DISH '499 focuses on a remote/cloud DVR system. Its disclosure is relevant for its teaching of:
  • Playlist (Descriptor) Modification for Content Versioning: DISH '499 explicitly describes creating and managing playlists that are modified for dynamic ad insertion. A playlist for a recorded program can be altered to include references to ad segments.
  • Content-Based Rules: The motivation for modifying the playlist is a clear content-based rule: "insert an advertisement at this specific point." This directly teaches the application of non-technical, business-driven rules to create a different version of a media presentation.

3. Motivation to Combine and Reasonable Expectation of Success:

A POSITA, familiar with the on-the-fly manifest manipulation system taught by Akamai '418, would have been motivated to incorporate the content-based playlist modification techniques from DISH '499 for several reasons:

• Expanding Functionality: The most common and commercially valuable reason to alter a video stream is to insert or replace advertising. A POSITA would see the ad-insertion-by-playlist-modification method in DISH '499 as a natural and logical application for the dynamic manifest generation engine described in Akamai '418. Instead of just filtering bitrates, the same engine could be used to splice in ad segments by adding their URLs to the manifest at the appropriate points.

• Solving a Known Industry Problem: By 2012, dynamic ad insertion (DAI) was a well-known goal for streaming services. The industry was actively seeking ways to move beyond static, pre-packaged content and deliver personalized ads, enforce regional blackouts, and customize content for different users. Combining Akamai's dynamic manifest generation with DISH's application of playlist modification for ads would have been an obvious solution to this problem.

• Predictable Results: The combination would have yielded predictable results. A system that can already parse and rewrite a manifest file to remove a high-bitrate stream (as in Akamai '418) could, with simple modifications, be taught to add a reference to a different media segment (an ad, as in DISH '499). There were no technical hurdles that would have prevented a POSITA from successfully implementing this combination.

Therefore, the combination of Akamai '418 and DISH '499 teaches all elements of the '206 patent's independent claims. Akamai '418 provides the core system for on-the-fly manifest manipulation, and DISH '499 provides the motivation and teaching to apply this manipulation for content-based rules like ad insertion.

Secondary Obviousness Combination: Divx '958 in view of Common Industry Knowledge

1. Base Reference: U.S. Patent Application Pub. No. US 2013/0054958 A1 ("Divx '958")

• What Divx '958 Teaches: Filed on August 31, 2011, Divx '958 is a very strong reference that teaches:
  • Receiving Segments and Index Files: The system uses "track-level index files" (equivalent to single-track playlists) and their associated media segments.
  • Generating a "Top-Level" Index File (Descriptor): The core of the Divx invention is to automatically generate a "top-level index file" (equivalent to a master MPD or playlist) by combining different tracks.
  • Rule-Based Generation: This generation is based on rules, explicitly including "user preferences" and "device capabilities" (fulfills step 2).
  • No Transcoding: The system works by referencing existing media segments, not by creating new ones. The top-level file is then sent to the client. This fulfills all four steps of the '206 claims.

2. Argument for Obviousness:

Divx '958 alone comes very close to anticipating the '206 patent. An obviousness argument would be that extending the disclosed "user preferences" to include specific content-related rules like "parental controls" or "preferred language" was a simple and obvious design choice.

A POSITA in 2012 would have understood that "user preferences" in a media system commonly include:

• Language Selection: Choosing an audio track or subtitle language.
• Content Filtering: Setting parental controls based on content ratings (e.g., TV-PG, R).
• Accessibility: Enabling descriptive audio tracks.

Applying these well-known types of user preferences as rules to the system described in Divx '958 would lead directly to the invention claimed in the '206 patent. For example, a "user profile" (as mentioned in '206) could state a preference for "no violent content." The Divx system, which already generates a playlist based on user preferences, could easily be adapted to read this rule and generate a top-level index file that omits the "track-level index files" corresponding to violent scenes. This would be an obvious and straightforward implementation of the Divx system.

Conclusion

The independent claims of US Patent 8,949,206 are likely obvious under 35 U.S.C. § 103. The core inventive concept—manipulating a descriptor file based on rules without re-encoding media—was disclosed by multiple prior art references. The Akamai '418 reference teaches the fundamental system architecture for on-the-fly manifest modification, and the DISH '499 reference teaches the application of this technique for content-based rules like ad insertion. Furthermore, the Divx '958 reference teaches a nearly identical system, and extending its concept of "user preferences" to include common content-management rules would have been an obvious design choice for a person of ordinary skill in the art in 2012.

Patent Term and Family Analysis for U.S. Patent No. 8,949,206

Date of Analysis: May 11, 2026

An analysis of the public records for U.S. Patent No. 8,949,206 ("the '206 patent") provides the following details regarding its term, related applications, and international counterparts.

Key Dates:

• Filing Date: October 4, 2012
• Issue Date: February 3, 2015
• Legal Status: Active

---

Patent Term Adjustment (PTA) and Extensions (PTE)

• Patent Term Adjustment (PTA): There is no record of any Patent Term Adjustment (PTA) being granted for the '206 patent. The time from filing (October 4, 2012) to issuance (February 3, 2015) was approximately 2 years and 4 months, which is well within the 3-year period where USPTO delays might trigger a PTA.
• Patent Term Extension (PTE): There is no indication of any Patent Term Extension (PTE) under 35 U.S.C. § 156, which typically applies to delays in regulatory review for products like pharmaceuticals and is not relevant to this technology.

---

Continuity Data

A review of the patent's prosecution history and bibliographic data shows no "Continuity Data." This indicates that, as of its issuance, the '206 patent:

• Is Not a Continuation or Divisional: It does not claim priority to an earlier, co-pending U.S. non-provisional application.
• Has No Continuation or Divisional Applications: The patent owner has not filed any subsequent applications that claim the benefit of the '206 patent's filing date. This means there are no "child" applications that could issue with the same priority date but different claims.

---

Patent Family and Priority Claims

The '206 patent is part of a family of related patent documents filed in multiple jurisdictions, all claiming priority to the original U.S. application.

• Priority Application: The entire patent family claims priority to the U.S. application 13/644,792, filed on October 4, 2012.

• International (PCT) Application: A Patent Cooperation Treaty (PCT) application was filed as PCT/IB2013/059076 on October 2, 2013. This application was published as WO2014054012A1.

• Foreign Counterparts: Based on the priority claim, the following corresponding patent documents were filed in other national or regional patent offices:

  • China: CN104854877B
  • Europe: EP2904813A4

---

Projected Expiration Date

The term of a U.S. patent is typically 20 years from the filing date of the earliest U.S. or PCT application to which it claims priority.

• Base Expiration: 20 years from the filing date of October 4, 2012, places the expiration date at October 4, 2032.

• Adjusted Expiration: The "Legal Status" section provided in the patent data indicates an "Adjusted expiration" of December 12, 2032. This indicates there may have been a Patent Term Adjustment granted that is not immediately apparent in the basic bibliographic data. A detailed review of the file wrapper would be required to confirm the specific calculation of this adjustment.

Projected Expiration Date (Adjusted): December 12, 2032

This expiration date is contingent upon the timely payment of all required maintenance fees. The first maintenance fee (due at 3.5 years post-grant) was paid on August 3, 2018. The second fee (due at 7.5 years post-grant) would have been due by August 3, 2022, and the final fee (due at 11.5 years) will be due by August 3, 2026.

Defensive Disclosure: Methods for Dynamic Generation of Media and Data Manifests

Publication Date: May 11, 2026
Field: Digital Media Distribution, Data Streaming, Cloud Computing, Internet of Things (IoT)

This document discloses several methods, systems, and applications related to the dynamic generation and modification of descriptor files (manifests) for segmented media and data streams. These disclosures are intended to enter the public domain to serve as prior art for future patent applications. The core concept involves creating multiple, customized versions of a data stream by manipulating a manifest file based on a set of rules, without regenerating or transcoding the underlying data segments.

---

Derivative Variation 1: Serverless, Just-In-Time Manifest Generation

• Enabling Description: This variation implements the manifest generation logic within a serverless computing environment (e.g., AWS Lambda, Google Cloud Functions, Azure Functions). A master manifest file (e.g., a DASH MPD or HLS playlist) and all associated media segments are stored in a cloud object storage service (e.g., S3, Google Cloud Storage). A set of versioning rules is stored in a low-latency NoSQL database (e.g., DynamoDB, Firestore), mapping user IDs, device profiles, or geographic locations to specific content rules (e.g., "remove_period_3", "substitute_audio_track_en-us").

  When a client requests a manifest, the request is routed through an API Gateway, which triggers a dedicated serverless function. This function:

  1. Retrieves the master manifest from object storage.
  2. Reads request headers or parameters (e.g., JWT token, query string) to identify the user and context.
  3. Queries the NoSQL database to fetch the applicable rules for that context.
  4. Parses the master manifest (e.g., as an XML DOM or text stream) and applies the rules by programmatically adding, removing, or modifying nodes/tags or text lines. For example, it might remove a <Period> element or replace a <BaseURL> to redirect a client to a different ad server.
  5. Returns the newly generated, non-persistent manifest directly to the client as the HTTP response.

  This architecture eliminates the need for a constantly running server, reduces cost, and scales massively and automatically with demand. The manifest manipulation logic is stateless, making it highly robust.

• Mermaid Diagram:

  sequenceDiagram
      participant Client
      participant APIGateway as API Gateway
      participant Lambda as "Manifest Generator (Lambda)"
      participant S3 as "Object Storage (S3)"
      participant DynamoDB as "Rules Database (DynamoDB)"
  
      Client->>+APIGateway: GET /manifest.mpd?user=123
      APIGateway->>+Lambda: Invoke(event)
      Lambda->>+S3: GetObject(master.mpd)
      S3-->>-Lambda: master.mpd content
      Lambda->>+DynamoDB: GetItem(user:123)
      DynamoDB-->>-Lambda: {rule: "remove_period_3"}
      Lambda->>Lambda: Manipulate MPD in-memory
      Lambda-->>-APIGateway: Return modified_manifest.mpd
      APIGateway-->>-Client: 200 OK (body: modified_manifest.mpd)
  

---

Derivative Variation 2: Real-time Live Event Manifest Splicing

• Enabling Description: This variation applies the concept to ultra-low latency live streaming, such as for sports or interactive events. A live encoder produces media segments and a continuously updated manifest file. A separate "Rules Engine" ingests real-time data from external APIs (e.g., sports statistics, betting odds, social media sentiment, biometric sensor data).

  A "Manifest Splicer" component intercepts the client's requests for the live manifest. For each request, it:

  1. Fetches the latest live manifest from the origin.
  2. Queries the Rules Engine for any active real-time events.
  3. If an event is active (e.g., a goal is scored), the Splicer modifies the manifest to insert a new "Period" or segment URL that points to a pre-canned instant replay or a graphical overlay. This is achieved by adjusting the presentationTimeOffset and segment lists.
  4. For personalized streams, the Rules Engine may provide user-specific rules, such as inserting a "picture-in-picture" period for an alternate camera angle that the user has expressed interest in, or embedding custom metadata tags (e.g., SCTE-35 markers in a new format) that the client player can interpret. This manipulation occurs in real-time, with each manifest update, allowing for a highly dynamic and interactive viewing experience without re-encoding the primary live stream.

• Mermaid Diagram:

  graph TD
      A[Live Encoder] -->|Generates Segments & Live Manifest| B(Origin Server)
      C[Real-Time Data Feeds<br/>(Stats, Betting Odds)] --> D{Rules Engine}
      E[Client Device] -->|1. Request manifest.mpd| F(Manifest Splicer)
      F -->|2. Fetch latest manifest| B
      F -->|3. Query for rules| D
      D -->|4. Return dynamic rules<br/>(e.g., 'Insert Replay at timestamp X')| F
      F -->|5. Manipulate Manifest| F
      F -->|6. Return Spliced Manifest| E
      E -->|7. Request media segments| B
  

---

Derivative Variation 3: Application to Industrial IoT (IIoT) Digital Twins

• Enabling Description: This concept is applied to the monitoring and control of industrial equipment (e.g., a jet engine, a factory robot) via a "Digital Twin" model. The physical asset is instrumented with hundreds of sensors (temperature, pressure, vibration, RPM), each generating a time-series data stream. These streams are segmented and described by a master "Data Stream Descriptor" (DSD), analogous to a media manifest.

  Different consumers of this data require different versions:

  • On-site Technician: Needs a low-latency, high-frequency stream of a core set of operational parameters.
  • Remote Analyst: Requires a historical view, with down-sampled data for long-term trend analysis, and enriched with data from maintenance logs.
  • Predictive Maintenance AI: Needs high-fidelity data from specific components (e.g., bearings, fuel injectors) but only for specific operational windows.

  A "Digital Twin Gateway" receives requests for data. Based on the requester's role (the "rule"), it manipulates the master DSD. For the technician, it generates a DSD pointing only to the latest, real-time segment URLs. For the analyst, it generates a DSD that combines historical segment URLs with pointers to log files. For the AI, it generates a DSD that filters out all irrelevant sensor streams and periods of inactivity. This avoids transferring massive, unnecessary datasets and provides each consumer with a perfectly tailored view of the asset's data without altering the raw, archived sensor readings.

• Mermaid Diagram:

  flowchart LR
      subgraph Physical Asset
          S1(Sensor: Temp)
          S2(Sensor: Pressure)
          S3(Sensor: Vibration)
      end
  
      subgraph Cloud Platform
          Store[Data Lake /<br>Segment Storage]
          MasterDSD(Master Data<br>Stream Descriptor)
          Gateway(Digital Twin Gateway)
          Rules[Role-Based<br>Access Rules]
      end
  
      subgraph Consumers
          Tech(Technician App)
          Analyst(Analytics Dashboard)
          AI(ML Model)
      end
  
      S1 -- Data Segments --> Store
      S2 -- Data Segments --> Store
      S3 -- Data Segments --> Store
      Store -- References --> MasterDSD
  
      Tech -- Request(role=technician) --> Gateway
      Analyst -- Request(role=analyst) --> Gateway
      AI -- Request(role=ml_bot) --> Gateway
  
      Gateway -- Reads --> MasterDSD
      Gateway -- Reads --> Rules
      Gateway -->|Generates Custom DSD 1| Tech
      Gateway -->|Generates Custom DSD 2| Analyst
      Gateway -->|Generates Custom DSD 3| AI
  

---

Derivative Variation 4: Application to Personalized Pharmaceutical Manufacturing (Pharma 4.0)

• Enabling Description: In a continuous manufacturing process for personalized medicine, a batch of a drug is produced according to a patient-specific formula. The process is documented by a stream of data from process analytical technology (PAT) sensors, logging every variable (temperature, flow rate, chemical concentration) in real-time. This entire data history is represented by a master "Batch Process Record" (BPR) manifest, which points to immutable, time-stamped data segments.

  A regulatory agency, a quality assurance (QA) auditor, and a research scientist may each need to review this BPR. The rules are based on their access credentials and purpose.

  • Regulator: Receives a BPR manifest that includes all critical process parameters (CPPs) and quality attributes (CQAs) but redacts proprietary formulation data.
  • QA Auditor: Receives a manifest that highlights deviations from the "golden batch" profile by inserting links to non-conformance reports at the specific timecodes where deviations occurred.
  • Researcher: Receives a manifest that includes all sensor data plus links to genomic data for the patient, allowing for deep analysis.

  A validated "BPR Generation Service" creates these role-specific manifest versions on-demand by manipulating the master BPR manifest, ensuring data integrity while providing customized, compliant views of the manufacturing process.

• Mermaid Diagram:

  erDiagram
      "MASTER BPR" {
          string MasterBPR_ID
          string BatchID
      }
      "DATA SEGMENT" {
          string SegmentID
          string Timestamp
          string SensorType
          string DataURL
      }
      "RULE" {
          string RoleID
          string RedactionFilter
          string AnnotationSource
      }
      "CONSUMER" {
          string ConsumerID
          string RoleID
      }
      "MASTER BPR" ||--o{ "DATA SEGMENT" : "references"
      "CONSUMER" ||--|{ "RULE" : "is_subject_to"
  

---

Derivative Variation 5: Application to Modular Software & Firmware Delivery

• Enabling Description: This variation applies the concept to Over-The-Air (OTA) updates for complex systems like automobiles or smart home devices. The complete firmware is composed of dozens of independent modules (e.g., engine control unit, infotainment, advanced driver-assistance systems). A master "Firmware Manifest" (e.g., a JSON or XML file) lists all possible modules, their versions, and URLs to their binary packages.

  When a specific device requests an update, it provides its model number, hardware revision, and current software version. The OTA update server uses these as "rules" to manipulate the master manifest:

  1. It filters out modules not compatible with the device's hardware revision.
  2. It removes modules for features the user has not subscribed to (e.g., a "performance pack" or "premium connectivity").
  3. It adjusts dependency information and signs the new, customized manifest.

  The device receives a much smaller, tailored manifest containing only the download links for the specific modules it needs. This reduces download size, minimizes the risk of flashing incompatible components, and enables feature management via software, all without needing to pre-package and store hundreds of unique full-firmware images.

• Mermaid Diagram:

  graph TD
      subgraph OTA Server
          A(Master Firmware Manifest)
          B{Rule Engine}
          C(Module Storage)
      end
  
      subgraph Vehicle
          D[ECU]
          D -- "Request Update<br>(Model: Y, HW: 2.1, Subscription: Premium)" --> B
      end
  
      B -- "1. Read" --> A
      B -- "2. Apply Rules" --> E(Generate Custom Manifest)
      E -- "3. Contains URLs to:" --> C
      E -- "4. Send to Vehicle" --> D
  
      subgraph Custom_Manifest_for_Vehicle_D
          direction LR
          F[Infotainment_v3.bin]
          G[ADAS_Premium_v1.2.bin]
      end
      style Custom_Manifest_for_Vehicle_D fill:#f9f,stroke:#333,stroke-width:2px
  
      E -.-> Custom_Manifest_for_Vehicle_D
  

---

Derivative Variation 6: AI-Driven Predictive Manifest Caching

• Enabling Description: This variation integrates a predictive AI model into the content delivery network (CDN). The AI model analyzes large-scale data, including historical user viewing patterns, time of day, geographic location, and trending social media topics. Based on this analysis, the model predicts which versions of a manifest will be most in-demand in the near future for a given piece of content.

  For example, if a major news event breaks in Germany, the AI predicts a surge in requests for the German-language audio track. It proactively instructs the manifest generator to create and pre-cache the "German language" version of the manifest at edge servers located in Europe. When a user in Germany requests the content, the CDN can serve the already-generated, customized manifest instantly, reducing the latency of on-the-fly generation. This combines dynamic, rule-based generation with intelligent, predictive caching to optimize performance at a global scale.

• Mermaid Diagram:

  sequenceDiagram
      participant AI as "Predictive AI Engine"
      participant Generator as "Central Manifest Generator"
      participant Edge as "CDN Edge Cache"
      participant User
  
      loop Proactive Caching
          AI->>Generator: Predicts demand for 'de-DE' lang in 'eu-central-1' region
          Generator->>Generator: Generate 'de-DE' manifest version
          Generator->>Edge: PUSH manifest_de.mpd
      end
  
      User->>+Edge: GET /video/manifest.mpd (from Germany)
      alt Cache Hit
          Edge-->>-User: 200 OK (from cache)
      else Cache Miss
          Edge->>+Generator: GET /video/manifest.mpd?lang=de-DE
          Generator->>Generator: Generate 'de-DE' manifest on-the-fly
          Generator-->>-Edge: 200 OK (body: manifest_de.mpd)
          Edge-->>-User: 200 OK
      end
  

---

Derivative Variation 7: Blockchain-Audited Content Delivery

• Enabling Description: To ensure transparency and verifiability in content delivery, especially for ad insertion or rights-managed content, this variation integrates the manifest generator with a distributed ledger (blockchain).

  When the system generates a custom manifest for a user, it performs the following steps:

  1. Manipulates the source manifest according to the rules (e.g., inserts a specific ad).
  2. Calculates a cryptographic hash (e.g., SHA-256) of the generated manifest.
  3. Records a transaction on a blockchain. The transaction includes the user's anonymized ID, a hash of the master content, the hash of the generated manifest, and the rule(s) applied (e.g., "ad_campaign_xyz").
  4. The manifest, along with the transaction ID, is delivered to the client.

  This creates an immutable, auditable, and time-stamped record of exactly which version of the content was delivered to which user. This can be used to independently verify ad delivery for advertisers, calculate royalty payments for different content snippets (e.g., music in a film), and prove compliance with regional content restrictions.

• Mermaid Diagram:

  flowchart TD
      A[Client Request for Content] --> B{Manifest Generator};
      C[Rules Engine] --> B;
      D[Source MPD] --> B;
  
      B --> E{Generate Custom MPD};
      E --> F[Calculate Hash of Custom MPD];
      F --> G[Construct Blockchain Transaction<br>Includes: UserID, ContentHash, MPD_Hash, Rules];
      G --> H((Blockchain Network));
      H --> I{Confirm Transaction};
  
      subgraph Delivery
          E --> J[Deliver Custom MPD to Client];
          I --> K[Deliver Transaction ID to Client];
      end
  

---

Derivative Variation 8: Failsafe Manifest with Tiered Degradation

• Enabling Description: This "inverse" design focuses on system resilience. The manifest generation system operates in a tiered state model. The default state is "Full Dynamic," where all rules are applied to create a personalized manifest. The system includes health checks for all external dependencies, such as the ad decision server, personalization database, and rights management API.

  • State 1: Full Dynamic: All systems are healthy. Manifests are fully customized.
  • State 2: Degraded - No Ads: If the ad server is unresponsive, the rules engine enters a degraded state. It manipulates the master manifest to remove all ad break periods, ensuring uninterrupted content playback.
  • State 3: Degraded - No Personalization: If the user profile service is unavailable, the rules engine falls back to serving a generic, non-personalized manifest for the user's region, which may still include ads.
  • State 4: Failsafe - Core Content Only: If multiple systems fail or the manifest manipulator itself encounters a critical error, the system serves a pre-generated, static, "failsafe" manifest. This manifest is a bare-bones version containing only the primary video and audio tracks, with no ads, subtitles, or alternate angles. This ensures the user can still watch the main content even during a partial system outage.

• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Full_Dynamic: System Initialized
      Full_Dynamic --> Degraded_NoAds: Ad_Server_Timeout
      Full_Dynamic --> Degraded_NoPersonalization: UserDB_Timeout
      Degraded_NoAds --> Failsafe: UserDB_Timeout
      Degraded_NoPersonalization --> Failsafe: Ad_Server_Timeout
      Degraded_NoAds --> Full_Dynamic: Services Restored
      Degraded_NoPersonalization --> Full_Dynamic: Services Restored
      Failsafe --> Full_Dynamic: All Services Restored
  

---

Combination Prior Art Scenarios with Open-Source Standards

1. Combination with W3C Data Integrity Proofs: The system generates a custom manifest file in JSON-LD (JSON for Linked Data) format. Before distribution, the manifest is signed using a cryptographic suite compatible with the W3C Verifiable Credentials Data Model. The manifest includes a proof block containing the signature, verification method (e.g., a public key), and other metadata. This allows a client to cryptographically verify that the manifest was generated by an authorized server and has not been tampered with, which is critical when rules are used to enforce content restrictions or blackouts.

2. Combination with IETF SCITT (Supply Chain Integrity, Transparency, and Trust): The creation of each derivative manifest is treated as an event in a supply chain. A master manifest is the initial "product." The manifest generator acts as a "producer" that issues a signed statement for each generated manifest. These statements are registered in a SCITT-compliant transparent ledger. This allows downstream systems (e.g., CDNs, clients) to audit the entire history of a manifest, verifying which rules were applied by which system at what time, thus proving the integrity of the content delivery process according to a formal, open standard.

3. Combination with CNCF OpenTelemetry: The manifest manipulation system is instrumented using the OpenTelemetry standard. Every step of the process—receiving the request, fetching rules, parsing the master manifest, applying each rule, and generating the final output—emits detailed traces and metrics. These are sent to a compatible backend (e.g., Jaeger, Prometheus). This allows operators to precisely debug performance bottlenecks (e.g., a slow rule lookup), track the popularity of different content versions (e.g., which language tracks are most requested), and set alerts for high error rates in the manifest generation process, using a widely adopted, open-source observability framework.