US 8145721

Analysis of U.S. Patent 8,145,721: Bit Streams Combination of Downloaded Multimedia Files

As of April 26, 2026, this report provides a concise summary of U.S. Patent 8,145,721, including its key details and an overview of its independent claims. A search of the 2026 dockets for the Court of Appeals for the Federal Circuit (CAFC) did not yield any specific litigation related to this patent.

---

Title: Bit streams combination of downloaded multimedia files

Assignee: The patent was originally assigned to Telefonaktiebolaget LM Ericsson (PUBL). However, records indicate a subsequent assignment to Novacloud Licensing LLC.

Inventors: Andreas Olsson and Mårten Sundberg.

Filing Date: March 1, 2007.

Issue Date: March 27, 2012.

Abstract: The patent describes a method for downloading a multimedia file from a server to a user device, particularly over a connection with limited bandwidth. The core idea is to divide the multimedia file into two parts: a first, low-quality part and a second, high-quality part. The low-quality version can be streamed to the user device for immediate playback in real-time. The high-quality part is downloaded separately. The user device can then combine the two parts to reconstruct the original, full-quality multimedia file. This allows the user to start experiencing the content quickly without waiting for a large file to download completely.

---

Plain-Language Overview of Independent Claims

Independent claims represent the broadest protection granted by a patent. US Patent 8,145,721 has four independent claims:

Claim 1: A Method for a Server to Download a Multimedia File

This claim outlines a method performed by a server. When a user requests a multimedia file, the server divides it into two pieces: a "first part" with a lower quality encoding and a "second part" with a different, higher quality encoding. The server then streams the low-quality part to the user's device so they can start playing it right away. The higher-quality second part is sent as a separate download. The server sets different conditions for sending each part, for example, prioritizing the streaming of the low-quality version.

Claim 7: A Method for a User Device to Reproduce a Multimedia File

This claim focuses on the user's device. The device requests a multimedia file to be sent in two separate "bit streams." It first receives the low-quality stream and can immediately play this "limited version" of the file in real-time. It also receives the second, high-quality stream. The device then decodes both parts and combines them to create a "complete version" of the original file. Both the limited and complete versions can then be stored on the device.

Claim 10: A User Device for Reproducing Multimedia Files

This claim describes the user device itself. It specifies that the device must have a processor capable of performing the actions described in Claim 7. This includes requesting the two separate streams, receiving them, decoding each part with a different decoder, reproducing both a limited and a complete version of the file, storing these versions, and playing them back for the user.

Claim 14: A Server for Downloading Multimedia Files

This claim details the server's components. It states the server must have a processor that can manage the download service. This includes receiving the user's request, splitting the multimedia file into two parts with different coding, storing these parts, and then sending them as two separate bit streams under different conditions. The server specifically codes the first part based on the requirements for smooth streaming.

Based on the provided authoritative patent record, there is a contradiction with the previously generated summary. The summary dated April 26, 2026, stated that a search "did not yield any specific litigation related to this patent." However, the patent's own record indicates significant litigation activity was initiated in 2025.

As of May 11, 2026, U.S. Patent 8,145,721 is involved in the following known litigation. The plaintiff is inferred to be Novacloud Licensing LLC, which became the assignee of record in June 2024, prior to these cases being filed.

---

Known Litigation for U.S. Patent 8,145,721

The following cases have been identified from the patent's legal status records (Source: https://patents.google.com/patent/[US8145721](/patent/US8145721)/en).

1. Texas Eastern District Court Case

• Plaintiff(s): Likely Novacloud Licensing LLC.
• Defendant(s): Not specified in the provided information.
• Jurisdiction: U.S. District Court for the Eastern District of Texas.
• Case Number: 2:25-cv-01266.
• Filing Date: The case number indicates a filing year of 2025.
• Status: Given the recent filing date, this case is presumed to be active and ongoing.

2. Delaware District Court Case (a)

• Plaintiff(s): Likely Novacloud Licensing LLC.
• Defendant(s): Not specified in the provided information.
• Jurisdiction: U.S. District Court for the District of Delaware.
• Case Number: 1:25-cv-01272.
• Filing Date: The case number indicates a filing year of 2025.
• Status: Given the recent filing date, this case is presumed to be active and ongoing.

3. Delaware District Court Case (b)

• Plaintiff(s): Likely Novacloud Licensing LLC.
• Defendant(s): Not specified in the provided information.
• Jurisdiction: U.S. District Court for the District of Delaware.
• Case Number: 1:25-cv-00674.
• Filing Date: The case number indicates a filing year of 2025.
• Status: Given the recent filing date, this case is presumed to be active and ongoing.

4. California Northern District Court Case

• Plaintiff(s): Likely Novacloud Licensing LLC.
• Defendant(s): Not specified in the provided information.
• Jurisdiction: U.S. District Court for the Northern District of California.
• Case Number: 3:25-cv-08118.
• Filing Date: The case number indicates a filing year of 2025.
• Status: Given the recent filing date, this case is presumed to be active and ongoing.

Proceedings Overview

As of May 11, 2026, there are no AIA trial proceedings (IPR, PGR, or CBM) on file for U.S. Patent 8,145,721 at the Patent Trial and Appeal Board (PTAB). For a defendant, this means the patent has not been tested or "hardened" by a PTAB challenge, and all claims remain as originally granted, without any having been canceled or confirmed by the Board.

---

No PTAB proceedings were found for U.S. Patent 8,145,721.

---

Strategic Summary

The absence of any PTAB challenges against U.S. Patent 8,145,721 is a critical strategic data point, especially given the patent's assertion in multiple district court litigations starting in 2025.

• Claim Status: UNTESTED. All claims of patent 8,145,721, both independent (1, 7, 10, 14) and dependent, are currently valid as issued by the USPTO. None have been canceled or sustained by the PTAB. This provides a clear landscape for a defendant, as there is no PTAB-related history to complicate claim construction or validity arguments.

• Estoppel Landscape: WIDE OPEN. Petitioner estoppel under 35 U.S.C. § 315(e)(2), which prevents a petitioner from re-litigating grounds that were raised or reasonably could have been raised in an IPR, does not apply. Since no entity has filed an IPR, a defendant facing an infringement suit is completely free to challenge the validity of any claim in patent 8,145,721 at the PTAB using any available prior-art-based arguments under § 102 (anticipation) or § 103 (obviousness).

• Pattern Signals: The lack of PTAB activity is notable. Despite Novacloud Licensing LLC initiating at least four district court cases in 2025, none of the defendants appear to have responded with an IPR filing. This could suggest several possibilities: the defendants may have settled quickly, they may be planning a coordinated validity challenge within the district court litigation, or they may assess the patent as being less vulnerable to a standard prior art challenge suitable for an IPR. The absence of a challenge from a defensive aggregator like Unified Patents is also a relevant signal, as these groups often target patents asserted by non-practicing entities (NPEs).

Recommended Next Steps

For a defendant currently facing an assertion of U.S. Patent 8,145,721:

• Confirm No Pending Proceedings: The primary finding of this analysis is that no PTAB proceedings exist. This is based on the USPTO's own data portal and a supplemental web search. A defendant's counsel should perform a final check of the PTAB's E2E system to confirm no petitions have been filed in the last few days.

• Evaluate an IPR Filing: Given that the patent is "untested" at the PTAB and there is no estoppel, a defendant should immediately evaluate the merits of filing an inter partes review. The key advantages would be:

  • A potentially faster and lower-cost path to invalidating the asserted claims compared to district court litigation.
  • The use of a broader claim construction standard ("broadest reasonable interpretation") at the PTAB, which can make it easier to find invalidating prior art.
  • The possibility of a stay in the district court litigation pending the outcome of the IPR, which would pause expensive discovery and other litigation activities.

• Conduct Prior Art Search: The viability of an IPR depends entirely on the strength of the available prior art. A comprehensive prior art search focused on the key limitations of the independent claims is the most critical next step. The goal is to identify patents or printed publications that predate the 2007-03-01 priority date and teach the claimed methods of splitting a multimedia file into a low-quality streamable part and a high-quality downloadable part.

In summary, the lack of PTAB proceedings on US Patent 8,145,721 presents a clean slate and a significant opportunity for a defendant to be the first to challenge its validity at the Board.

Inventors

• Andreas Olsson: At the time of filing, likely employed by the original assignee, Telefonaktiebolaget LM Ericsson AB, in Sweden.
• Mårten Sundberg: At the time of filing, likely employed by the original assignee, Telefonaktiebolaget LM Ericsson AB, in Sweden.

There are no unusual patterns discernible from the inventors' status; they appear to be employees of the original developing company.

Original assignee

• Telefonaktiebolaget LM Ericsson (PUBL): A multinational networking and telecommunications company headquartered in Stockholm, Sweden. As a major developer and vendor of mobile network infrastructure, software, and services, Ericsson was an operating company that almost certainly developed and shipped products and services (e.g., media delivery platforms for network operators) that could embody the claims of the patent. The company remains a major global technology provider.

Assignment timeline

• 2009-09-17 (executed) / recorded 2010-04-16 — Reel 024247/0213

  • Conveyance: Assignment
  • Assignor: Andreas Olsson; Mårten Sundberg (the inventors)
  • Assignee: TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
  • Correspondent: Roger S. R Rydin, Ericsson Inc., Plano, TX 75024
  • Context: Standard assignment of invention from employees to their employer.

• 2024-04-09 (executed) / recorded 2024-06-26 — Reel 068522/0499

  • Conveyance: Assignment of Assignors Interest
  • Assignor: TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
  • Assignee: NOVACLOUD LICENSING LLC
  • Correspondent: Christopher P. Singer, Rimon, P.C., 4 Embarcadero Ctr Ste 1400, San Francisco, CA 94111
  • Context: Transfer from the original operating company to a non-practicing entity for the purpose of assertion.

• 2024-04-08 (executed) / recorded 2025-02-13 — Reel 070226/0533

  • Conveyance: Security Interest
  • Assignor: NOVACLOUD LICENSING LLC
  • Assignee: TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
  • Correspondent: David L. Fehrman, Perkins Coie LLP, 1201 Third Avenue, Suite 4900, Seattle, WA 98101
  • Context: Securitization; the original seller (Ericsson) records a security interest in the patent, indicating the sale to Novacloud was likely financed and the patent serves as collateral for the debt.

• 2025-04-18 (executed) / recorded 2025-04-18 — Reel 070888/0066

  • Conveyance: Security Agreement
  • Assignor: NOVACLOUD LICENSING LLC
  • Assignee: NCLD1 LLC
  • Correspondent: Christopher P. Singer, Rimon, P.C., 4 Embarcadero Ctr Ste 1400, San Francisco, CA 94111. This is the same correspondent who recorded the initial transfer to Novacloud.
  • Context: Internal securitization within the NPE structure, likely part of a financing arrangement for its litigation campaign.

• 2025-04-18 (executed) / recorded 2025-04-24 — Reel 071033/0001

  • Conveyance: Security Agreement
  • Assignor: NOVACLOUD LICENSING LLC
  • Assignee: NCLD1 LLC
  • Correspondent: Christopher P. Singer, Rimon, P.C., 4 Embarcadero Ctr Ste 1400, San Francisco, CA 94111. This is the same correspondent.
  • Context: A duplicate or related internal securitization, further reinforcing the financing structure for the assertion campaign that began in 2025.

Timeline diagram

timeline
    title Ownership of US 8145721
    2007 : Filed by Ericsson inventors
    2010 : Assigned to Ericsson
    2012 : Patent issued
    2024 : Assigned to Novacloud Licensing LLC
    2025 : Security interest back to Ericsson
         : Security agreement to NCLD1 LLC
         : First infringement suits filed

NPE / troll-pattern signals

1. Shell-entity transfer — Present. The patent was transferred from an operating company, Ericsson, to "Novacloud Licensing LLC," an entity whose name explicitly suggests a licensing/assertion business model rather than product development (Reel 068522/0499).

2. Known asserter in the chain — Present. The current assignee, Novacloud Licensing LLC, is documented by industry trackers like Unified Patents as a non-practicing entity that began asserting a portfolio of patents acquired from Ericsson in 2024 and 2025.

3. Repeat correspondent across the chain — Present. Christopher P. Singer of Rimon, P.C. is the correspondent of record for the initial transfer to Novacloud Licensing LLC (Reel 068522/0499) and the subsequent security agreements to NCLD1 LLC (Reels 070888/0066 and 071033/0001). This recurrence demonstrates a common hand guiding the transactions for the assertion entity.

4. Cascading transfers — Present. The sequence of security interest and security agreement recordings between Novacloud, Ericsson, and NCLD1 LLC occurred in a short span between February and April 2025 (Reels 070226/0533, 070888/0066, 071033/0001), indicative of a complex financial structure being put in place to support a litigation campaign.

5. Pre-litigation transfer — Present. The key assignment to Novacloud Licensing LLC was executed in April 2024 (recorded June 2024) and the litigation campaign began in 2025, placing the transfer squarely in the pre-litigation window to establish the entity for assertion.

6. Bankruptcy fire-sale — Not present. The transfer was from the large, solvent operating company Ericsson.

7. Privateering — Present. An operating company (Ericsson) transferred a patent to a known NPE (Novacloud) that subsequently asserted it against others in the market. The security interest recorded in Reel 070226/0533, where Ericsson holds the patent as collateral, strongly suggests an ongoing financial relationship consistent with a privateering arrangement.

8. Defensive aggregator (anti-NPE) — Not present. The chain ends with a known asserter.

Verdict

• NPE — high confidence

The ownership chain of US 8145721 displays multiple, strong signals of a classic NPE assertion model. The patent was transferred from its original operating-company home, Ericsson, to a licensing-focused LLC (Novacloud Licensing LLC, per Reel 068522/0499) which is a known asserter. This transfer immediately preceded the filing of at least four infringement lawsuits in 2025. The pattern is further confirmed by the complex securitization agreements and the use of a single, recurring correspondent to manage the transactions for the asserting entity.

Verify the assignment records at the USPTO Patent Assignment Search portal by searching for patent number 8145721.

Prior Art Analysis (35 U.S.C. § 102)

As of May 11, 2026, this analysis reviews the prior art cited during the prosecution of U.S. Patent 8,145,721 to assess potential anticipation of the claims under 35 U.S.C. § 102. Anticipation requires that every element and limitation of a claim be found in a single prior art reference. The following three references were cited by the applicant or the examiner during prosecution.

---

1. WO2003042783A2 ("WO '783")

• Full Citation: WO2003042783A2, "File splitting scalade coding and asynchronous transmission in streamed data transfer."
• Assignee: Musicmatch, Inc.
• Dates: Published May 22, 2003; priority date November 9, 2001. This reference qualifies as prior art.
• Brief Description: WO '783 discloses a system for delivering media files using scalable coding. A media file is split into a "base layer" (a playable, lower-quality version) and one or more "enhancement layers" (which contain data to improve the quality). The system allows for "asynchronous transmission," where the base layer can be streamed to a user for immediate playback, while the enhancement layers can be downloaded separately, either concurrently or at a later time. The client device combines the layers to reproduce the full-quality media file.
• Potential Anticipation: High. This reference appears to anticipate the independent claims of US 8,145,721.

Anticipates Claim(s)	Analysis
1, 14 (Server Method & Apparatus)	WO '783 teaches every element of the server claims. It describes dividing a multimedia file into a "base layer" (first part) and an "enhancement layer" (second part). Scalable coding inherently means the base layer uses a different, lower-bitrate coding (first coding) than the combination of layers (second coding). The reference explicitly teaches sending the base layer first for immediate streaming ("streaming said first part") and sending the enhancement layer separately ("downloading said second part") via "asynchronous transmission," which maps directly to setting different conditions for the transfer of each part.
7, 10 (User Device Method & Apparatus)	WO '783 likewise teaches the user device claims. The client device in WO '783 is designed to receive the separate streams. It receives the base layer (first bit stream) and can play it immediately (reproducing a limited version... in real-time). It subsequently receives the enhancement layer (second bit stream). The fundamental purpose of the client's scalable decoder is to decode both parts and combine them to create the full, original-quality file (a complete version), which can then be stored.

---

2. US20060135200A1 ("US '200")

• Full Citation: US Patent Application Publication No. 2006/0135200 A1, "Method for transmitting massive data effectively on multi-mode terminal."
• Assignee: Min-Hong Yun.
• Dates: Published June 22, 2006; priority date December 16, 2004. This reference qualifies as prior art.
• Brief Description: US '200 discloses a method for a device with multiple network interfaces (e.g., cellular and Wi-Fi) to download large data files efficiently. It teaches pausing a download on one network and resuming it on another, more optimal network (e.g., faster or cheaper). The goal is to optimize the data transfer based on network availability and user preferences.
• Potential Anticipation: Low. This reference does not appear to anticipate any of the independent claims on its own.

Anticipates Claim(s)

Analysis

None

While highly relevant to an obviousness argument for dependent claim 3, US '200 does not appear to teach the core limitations of the independent claims. It does not disclose splitting a single multimedia file into a low-quality streamable part and a high-quality downloadable part based on different encodings. Instead, it teaches a method for managing the download of a pre-existing data file across different networks. It lacks the essential elements of dividing, differential coding, and combining a base layer with an enhancement layer as required by claims 1, 7, 10, and 14.

---

3. US7236988B2 ("US '988")

• Full Citation: U.S. Patent 7,236,988 B2, "Methods and systems for providing random access to structured media content."
• Assignee: Microsoft Corporation.
• Dates: Granted June 26, 2007; priority date December 1, 1999. This reference qualifies as prior art.
• Brief Description: US '988 describes a method for organizing media content into "packets" or chunks that are indexed. This structure allows a client to request and download specific portions of a media file without having to download the entire file, enabling features like seeking to a specific point in a video that has not yet been downloaded. The system focuses on providing random access to a uniformly coded file.
• Potential Anticipation: None. This reference does not anticipate any claims.

Anticipates Claim(s)

Analysis

None

US '988 does not teach the central inventive concept of US 8,145,721. It does not describe dividing a file into a low-quality "first part" and a high-quality "second part" with different codings. The "packets" in US '988 are simply structural divisions of a single, homogeneously encoded file to enable random access. It does not teach streaming a low-quality version for immediate playback while a separate, high-quality component is downloaded to enhance it. Therefore, it fails to disclose key limitations present in all independent claims.

As of May 11, 2026, this report provides an obviousness analysis of U.S. Patent 8,145,721 under 35 U.S.C. § 103, based on the prior art cited during its prosecution. This analysis concludes that the patent's independent claims are likely obvious over a single reference, and that key dependent claims are obvious over a combination of references.

Obviousness of Independent Claims (1, 7, 10, 14)

The central inventive concept recited across all independent claims of US 8,145,721 is a method and system where a multimedia file is divided into a low-quality, streamable "first part" and a high-quality "second part" which are sent separately and later combined on the user's device. This concept appears to be rendered obvious by the teachings of a single prior art reference.

Primary Reference: WO2003042783A2 ("WO '783")

A person of ordinary skill in the art (POSITA) at the time of the invention (before March 1, 2007) would have been familiar with scalable coding techniques for media streaming. The teachings in WO '783 are not just relevant; they appear to describe the exact same system and method claimed in US 8,145,721, making the claims obvious.

• Argument for Obviousness: WO '783 teaches "file splitting scalade coding," where a file is divided into a "base layer" (a low-quality, playable version) and one or more "enhancement layers" (data to improve quality). This is synonymous with the "first part" and "second part" in claim 1 of US 8,145,721.
  • Dividing and Coding: WO '783 explicitly describes dividing the file. The use of scalable coding inherently means the base layer ("first part") has a different, lower-bitrate coding than the combination of the base and enhancement layers ("second part"), fulfilling the "coded using a second coding, other than the first coding" limitation of claim 1.
  • Streaming and Downloading Separately: WO '783 teaches "asynchronous transmission," where the base layer can be streamed first for immediate playback, while the enhancement layers are sent separately. This directly maps to the limitations of "streaming said first part" and "downloading said second part" under different conditions.
  • Combining on User Device: The fundamental principle of scalable media codecs, as described in WO '783, is that the client device receives the base layer, decodes it for immediate playback, and then combines it with the subsequently received enhancement layers to reproduce the full-quality media. This directly teaches the core limitations of the user device claims (7 and 10).

Because WO '783 alone teaches every significant limitation of the independent claims, a strong argument exists that these claims are obvious. The claimed invention is merely the application of a known and well-understood media delivery technique (scalable/progressive streaming) for the known purpose of enabling real-time playback over limited-bandwidth connections while still delivering a high-quality file.

Obviousness of Dependent Claims

Even if the independent claims were considered non-obvious, key dependent claims are rendered obvious by combining the teachings of WO '783 with other prior art that addresses specific implementation details.

Combination for Claim 3: WO '783 in view of US20060135200A1 ("US '200")

• Claim 3 Limitation: "...said first part is streamed via a first access technology, and ... said second part is downloaded via a second access technology, different from the first access technology."
• Teachings of US '200: This reference explicitly teaches a method for a multi-mode device to download data more effectively by using different network technologies. For example, starting a download on a cellular network and completing it when a faster or cheaper Wi-Fi network becomes available.
• Motivation to Combine: A POSITA, having the scalable streaming system of WO '783, would have been motivated to combine it with the network optimization technique of US '200 for a clear and predictable benefit. The base layer (the "first part" from WO '783) is small, time-sensitive, and required for immediate playback, making it perfectly suited for transmission over a widely available but potentially slow or expensive network like cellular (e.g., the GSM/EDGE network explicitly mentioned in US 8,145,721). The enhancement layer (the "second part") is larger, less time-sensitive, and can be downloaded in the background. It would have been obvious to apply the teaching of US '200 to defer the download of this larger part until the user's device connected to a more suitable network, such as Wi-Fi, to save cost and network resources. This combination directly arrives at the invention described in claim 3.

Summary of Obviousness Findings

Claim(s)	Prior Art Combination	Rationale
1, 7, 10, 14 (Independent)	Obvious over WO2003042783A2	WO '783 teaches all key limitations: splitting a media file into a low-quality base layer and a high-quality enhancement layer, transmitting them asynchronously, and combining them at the client for scalable playback. This represents the same inventive concept.
3 (Dependent)	Obvious over WO2003042783A2 in view of US20060135200A1	It would have been obvious to a POSITA to apply the multi-network download optimization method of US '200 to the scalable media system of WO '783. This would involve sending the small, time-critical base layer over one network (e.g., cellular) and the larger, less critical enhancement layer over a different, more optimal network (e.g., Wi-Fi).

In conclusion, the prior art cited during prosecution provides a strong foundation for an obviousness challenge against the claims of U.S. Patent 8,145,721. The core invention appears to be a straightforward application of known scalable streaming principles, and the more specific dependent claims represent an obvious combination of those principles with known network optimization techniques.

Term, Related Applications, and Family Status for US Patent 8,145,721

As of May 11, 2026, this analysis details the term status and application history for U.S. Patent 8,145,721.

---

Patent Term and Expiration

• Filing Date: The patent originates from an international application (PCT/SE2007/000200) filed on March 1, 2007. This date serves as the priority date.
• Standard Term: Patents filed on this date are subject to a 20-year term from the earliest priority date.
• Patent Term Adjustment (PTA): There is no record of any Patent Term Adjustment (PTA) granted for this patent. The USPTO did not add any days to the patent's term to compensate for administrative delays during prosecution.
• Patent Term Extension (PTE): There is no record of any Patent Term Extension (PTE). PTE, which is typically granted for delays caused by regulatory review (e.g., by the FDA), is not applicable to this patent's technology area.
• Projected Expiration Date: Based on the March 1, 2007, priority date and a standard 20-year term with no adjustments, the projected expiration date for U.S. Patent 8,145,721 is March 1, 2027. This is consistent with the "Anticipated expiration" date listed in the authoritative patent record.

---

Continuations and Divisional Applications

A search of the USPTO database and the patent's family records reveals no subsequent U.S. continuation or divisional applications stemming from U.S. Patent 8,145,721 or its parent application (U.S. Application No. 12/529,468). The prosecution history shows a direct path from the national stage entry of the PCT application to the issuance of this single U.S. patent.

This indicates that the assignee pursued and obtained only one patent in the United States from this specific inventive disclosure. There are no related U.S. applications pending or granted that would expand the scope or subject matter of the patented invention.

---

Patent Family

U.S. Patent 8,145,721 is part of a larger international patent family, all claiming priority to the same initial PCT application. This demonstrates a broader strategy to protect the invention in multiple key markets.

• Priority Application: PCT/SE2007/000200 (Filed: March 1, 2007)
• International Publication: WO2008105695A1
• Family Members:
  • United States: US8145721B2 (this patent)
  • China: CN101622846B
  • Germany: DE112007003305B4
  • Great Britain: GB2458846B

The existence of this patent family, particularly with granted patents in major jurisdictions like China and Europe (via the German patent), indicates that the original assignee, Ericsson, considered the invention to be of significant international value.

Publication Date: April 26, 2026
Title: Defensive Disclosure of Derivative Embodiments and Obvious Improvements for Systems of Progressive Multimedia File Delivery

This document is intended to enter the public domain as prior art. It discloses a series of derivative works, improvements, and alternative embodiments based on the core concepts described in U.S. Patent 8,145,721. The purpose is to render obvious any future patent claims on these or similar incremental improvements.

Core Concept Background

The foundational concept involves a client-server architecture where a multimedia file is split into a low-quality, streamable first part and a high-quality second part. These parts are transmitted separately and subsequently combined on the client device to reconstruct the original file. This disclosure expands upon that concept.

---

1. Derivative Implementations

1.1. Component Substitution: Scalable Codec Implementation

• Enabling Description: This embodiment replaces the abstract "first coding" and "second coding" with a standards-based scalable codec. For video, the server utilizes a Scalable Video Coding (SVC) encoder (ITU-T H.264 Annex G) or Scalable High Efficiency Video Coding (SHVC) (ITU-T H.265 Annex F). The multimedia file is encoded once into a multi-layer bitstream. The "first part" consists of the temporal and spatial base layer (BL). The "second part" consists of one or more enhancement layers (ELs). The server sends the BL via a first bitstream for immediate decoding and playback. The ELs are sent via a second bitstream. The client's SVC/SHVC-compliant decoder combines the decoded layers in real-time or post-facto to render the full resolution/quality video. This method is more efficient than two separate encodings as the enhancement layers re-use information from the base layer.
• Diagram:

  sequenceDiagram
      participant Client
      participant Server
      Client->>Server: Request Scalable Video (SVC/SHVC)
      Server-->>Client: Stream 1: Base Layer (BL)
      Server-->>Client: Stream 2: Enhancement Layer(s) (EL)
      activate Client
      Note over Client: Decode and Play BL immediately
      Note over Client: Buffer ELs
      Note over Client: Combine decoded BL + ELs for full quality
      deactivate Client
  

1.2. Component Substitution: Asymmetric Transport Protocol

• Enabling Description: This embodiment utilizes different transport protocols for each bitstream to optimize for their distinct purposes. The "first part" (low-quality) is streamed using Real-time Transport Protocol (RTP) over UDP to minimize latency for real-time playback, accepting potential minor packet loss. The "second part" (high-quality) is transmitted using the QUIC protocol (IETF RFC 9000), which leverages UDP but provides stream multiplexing, congestion control, and improved error recovery over TCP. This ensures the larger, high-quality data is transferred reliably and efficiently without the head-of-line blocking issues of TCP, while the real-time stream remains unimpeded.
• Diagram:

  graph TD
      subgraph Server
          A[Multimedia File] --> B{Encoder};
          B --> C[Part 1: Low-Q];
          B --> D[Part 2: High-Q];
      end
      subgraph Network
          E[RTP over UDP]
          F[QUIC over UDP]
      end
      subgraph Client
          G[Real-time Player]
          H[File Buffer]
          I{Decoder & Combiner}
      end
      C -- Stream 1 --- E --> G;
      D -- Stream 2 --- F --> H;
      G --> I;
      H --> I;
  

1.3. Operational Parameter Expansion: Volumetric Microscopy Data Delivery

• Enabling Description: The system is applied to terabyte-scale volumetric data sets from sources like light-sheet fluorescence microscopy (LSFM). The "first part" is a decimated point cloud representation of the data, generated using an octree algorithm, resulting in a file of a few megabytes. This part is streamed to a researcher's workstation for interactive 3D navigation. The "second part" comprises the full-resolution voxel data blocks. As the researcher selects a specific region of interest in the low-resolution viewer, the client requests the corresponding high-resolution data blocks for that region from the server, which are then downloaded and combined with the base model to provide a high-fidelity view of the selected area.
• Diagram:

  flowchart LR
      subgraph Server
          A[TB-scale Voxel Data] --> B{Octree Decimator};
          B --> C[Part 1: Low-Res Point Cloud];
          A --> D[Part 2: Full-Res Voxel Blocks];
      end
      subgraph Researcher Client
          E[3D Viewer] --> F{ROI Selection};
          F --> G[Request High-Res Blocks];
          H[Combiner]
      end
      C -- Stream 1 --> E;
      F -- Generates --> G;
      G -- Sends to --> Server;
      Server -- Sends blocks from D --> H;
      E -- Feeds into --> H;
  

1.4. Operational Parameter Expansion: Industrial Digital Twin Synchronization

• Enabling Description: This embodiment is applied to a digital twin of a manufacturing facility. The "first part" is a continuous, low-bandwidth telemetry stream using the MQTT protocol, containing key performance indicators (KPIs) and state data for major machinery, rendered as a simplified 3D schematic. The "second part" consists of high-fidelity Computer-Aided Engineering (CAE) and physics-based simulation models. When an anomaly is detected in the real-time MQTT stream (e.g., vibration exceeds a threshold), a diagnostic request is triggered. The server then transmits the relevant high-fidelity simulation model ("second part") for the specific malfunctioning asset, which is loaded by the engineer's workstation for detailed root-cause analysis.
• Diagram:

  stateDiagram-v2
      [*] --> Streaming_Low_Fi
      Streaming_Low_Fi: Client displays live MQTT telemetry on schematic.
      Streaming_Low_Fi --> Anomaly_Detected: Vibration > Threshold
      Anomaly_Detected --> Downloading_High_Fi: Engineer requests diagnostic model.
      Downloading_High_Fi --> Analysis: High-fidelity CAE model loaded and combined with telemetry data.
      Analysis --> Streaming_Low_Fi: Diagnostic complete.
  

1.5. Cross-Domain Application: Aerospace In-Flight Entertainment (IFE)

• Enabling Description: In an IFE system, bandwidth is variable and costly. The "first part" of a film, a 480p H.264-encoded version, is pre-loaded on the seatback unit's solid-state drive or streamed over the cabin Wi-Fi from the central server. The "second part," containing the delta information required to upgrade the stream to 1080p or 4K (using a scalable video codec), is downloaded opportunistically. The aircraft's network management system prioritizes the "second part" download when the aircraft is within a high-throughput Ku/Ka-band satellite spot beam or connected to a gate's ground-based Wi-Fi, minimizing satellite data costs. The user can start watching immediately, and the quality improves seamlessly once the second part is downloaded and combined.
• Diagram:

  sequenceDiagram
      participant SeatbackUnit
      participant AircraftServer
      participant GroundLink
      SeatbackUnit->>AircraftServer: User selects movie
      AircraftServer-->>SeatbackUnit: Stream/Load Part 1 (480p)
      loop Opportunistic Download
          AircraftServer->>GroundLink: Is High-Bandwidth Link available?
          GroundLink-->>AircraftServer: Yes (Spot Beam/Gate WiFi)
          AircraftServer-->>SeatbackUnit: Download Part 2 (HD/4K Delta)
      end
      Note over SeatbackUnit: Combines Part 1 & Part 2 for HD playback
  

1.6. Cross-Domain Application: Agricultural Drone Imagery

• Enabling Description: A fixed-wing drone captures 100GB of multispectral imagery of a farm. While in the air, its onboard 5G transmitter sends the "first part": a heavily compressed, low-resolution NDVI (Normalized Difference Vegetation Index) map. This allows a farmer on the ground to identify stress areas in near real-time. The "second part," the full-resolution, multi-band GeoTIFF data, is stored on the drone's local storage. Upon landing and connecting to a local Wi-Fi network, the drone automatically transmits this second part to a local server for detailed analysis, variable rate fertilizer prescription map generation, and archival.
• Diagram:

  flowchart TD
      A[Drone captures 100GB multispectral image] --> B{Onboard Processing};
      B --> C[Part 1: Compressed NDVI Map];
      B --> D[Part 2: Full-Res GeoTIFF on SSD];
      C -- 5G Link --> E[Farmer's Tablet for Real-time Triage];
      D -- Wi-Fi at base --> F[Farm Server for Detailed Analysis];
      F --> G{Prescription Map Generation};
  

1.7. Cross-Domain Application: Progressive Video Game Loading

• Enabling Description: In a large open-world video game, the initial download and installation are split. The "first part" comprises the game engine, core logic, and low-polygon models and low-resolution (e.g., 512x512) textures for the starting zone, allowing the player to begin gameplay in minutes. The "second part" contains the high-resolution (e.g., 4K) texture packs, detailed character models, and audio for other game zones. This second part is downloaded in the background using a bandwidth-throttled downloader while the user is playing. The game engine's asset manager swaps the low-resolution assets for the high-resolution ones from the second part as they become available, storing them in a local cache.
• Diagram:

  classDiagram
      class AssetManager {
          -lowResCache
          -highResCache
          +requestAsset(assetID)
          +streamHighRes(assetID)
      }
      class GameEngine {
          +loadLevel()
      }
      class Renderer {
          +drawObject(model, texture)
      }
      GameEngine o-- AssetManager
      GameEngine o-- Renderer
      note for AssetManager "On first request, returns low-res asset from Part 1 and triggers background download of high-res asset from Part 2."
  

1.8. Integration: AI-Driven Predictive Delivery

• Enabling Description: A machine learning model (e.g., a recurrent neural network) on the server analyzes real-time data to optimize the split. It considers: 1) Network telemetry from the client (latency, jitter, packet loss), 2) User context (device model, screen resolution, time of day), and 3) Content characteristics (scene complexity, motion). The model dynamically adjusts the bitrate and GOP (Group of Pictures) structure of the "first part" for optimal real-time playback. It also predicts future network availability (e.g., likelihood of connecting to Wi-Fi in the next 15 minutes based on user mobility patterns) to schedule the download of the "second part" for a time of lowest cost and highest throughput.
• Diagram:

  graph LR
      subgraph Client
          A[Device/Network Sensors] --> B[Telemetry Data]
      end
      subgraph Server
          C[ML Model (RNN)]
          D{Dynamic Encoder}
          E{Download Scheduler}
      end
      B --> C
      C -- Optimal Encoding Params --> D
      C -- Predicted Network State --> E
      D --> F[Part 1 Stream]
      E --> G[Part 2 Download]
      F --> Client
      G --> Client
  

1.9. Integration: Blockchain-Verified Secure Firmware Updates

• Enabling Description: This system delivers Over-The-Air (OTA) firmware updates to an automotive Electronic Control Unit (ECU). The "first part" is a small, critical security patch that must be deployed immediately. The "second part" is a larger file containing new features and performance enhancements. The manufacturer generates hashes for both parts and registers them on a private consortium blockchain. The ECU downloads the "first part" over a cellular connection, verifies its hash against the blockchain, and applies it. It then downloads the "second part," often during a scheduled maintenance window over Wi-Fi, and again verifies its hash. The ECU's bootloader only combines and activates the full new firmware image after both parts have been successfully received and cryptographically verified against the immutable blockchain record.
• Diagram:

  sequenceDiagram
      participant Manufacturer
      participant Blockchain
      participant ECU
      Manufacturer->>Blockchain: Register Hashes (H1, H2)
      ECU->>Manufacturer: Request Update
      Manufacturer-->>ECU: Send Part 1 (Security Patch)
      ECU->>Blockchain: Verify Hash(Part 1) == H1
      Note over ECU: If verified, apply Part 1
      Manufacturer-->>ECU: Send Part 2 (Feature Update)
      ECU->>Blockchain: Verify Hash(Part 2) == H2
      Note over ECU: If verified, combine Parts 1 & 2 for next boot
  

1.10. Inverse Mode: Graceful Degradation on Unreliable Networks

• Enabling Description: The system is designed for environments with intermittent connectivity, such as maritime or tactical military networks. The "first part" is a fully self-contained, playable media file (e.g., a 360p H.264 file). The "second part" is a binary diff file created using a utility like xdelta. If the "second part" download fails to complete or its checksum verification fails, the client application is explicitly designed to halt the combination process. It presents the user with the successfully downloaded "first part" for playback and marks it as "Low Quality." It provides a UI option to re-attempt the download of only the "second part" later, thus preserving a usable asset instead of creating a corrupted file.
• Diagram:

  stateDiagram-v2
      [*] --> Downloading
      Downloading: Get Part 1 (playable), Get Part 2 (diff)
      Downloading --> Verifying: Download complete
      Downloading --> Playable_LQ: Part 2 download fails
      Verifying --> Playable_HQ: Part 2 checksum OK --> Combine
      Verifying --> Playable_LQ: Part 2 checksum fail
      Playable_LQ --> Downloading: User re-attempts Part 2 download
  

---

2. Combination with Open-Source Standards

2.1. Combination with MPEG-DASH

• Enabling Description: The system is implemented using the MPEG-DASH standard. The server generates a Media Presentation Description (MPD) manifest file that defines two distinct Periods. The first Period contains AdaptationSets for a low-bitrate, immediately playable version of the content (the "first part"). The second Period, with a start time of 0, contains a single AdaptationSet with a high-bitrate, non-segmented representation of the complete file (the "second part"). A custom DASH client is configured to: 1) Parse the MPD and begin streaming the first Period for immediate playback. 2) Simultaneously, initiate a background HTTP GET request for the entire resource described in the second Period. 3) Once the background download is complete and the first Period playback finishes, the client combines the files to create the full quality version for storage.
• Diagram:

  erDiagram
      MPD_MANIFEST {
          string Period1_ID
          string Period2_ID
      }
      PERIOD_1 {
          string AdaptationSet_LQ_video
          string AdaptationSet_LQ_audio
      }
      PERIOD_2 {
          string AdaptationSet_HQ_complete
      }
      MPD_MANIFEST ||--o{ PERIOD_1 : "contains"
      MPD_MANIFEST ||--o{ PERIOD_2 : "contains"
  

2.2. Combination with WebRTC and File API

• Enabling Description: A browser-based client uses WebRTC to connect to a server. The server establishes two channels. The first is a standard MediaStream which carries the low-quality, real-time audio/video "first part." The second is a RTCDataChannel, configured for reliable transmission, which is used to send the "second part" as a sequence of binary chunks. The client JavaScript receives the MediaStream and attaches it to an HTML5 <video> element for playback. Concurrently, it listens for message events on the RTCDataChannel, appending the received chunks into a Blob using the File API. Once the DataChannel signals the transfer is complete, the client can use a library like ffmpeg.wasm (WebAssembly) to combine the buffered low-quality stream and the high-quality Blob into a single MP4 file for local storage.
• Diagram:

  sequenceDiagram
      participant BrowserClient
      participant WebRTC_Server
      BrowserClient->>WebRTC_Server: Initiate PeerConnection
      WebRTC_Server-->>BrowserClient: Establish MediaStream (Part 1)
      WebRTC_Server-->>BrowserClient: Establish DataChannel (Part 2)
      Note over BrowserClient: Play MediaStream in <video> element
      loop Transfer Chunks
          WebRTC_Server-->>BrowserClient: Send chunk over DataChannel
          BrowserClient->>BrowserClient: Append chunk to Blob
      end
      Note over BrowserClient: Use ffmpeg.wasm to combine stream and blob
  

2.3. Combination with BitTorrent Protocol

• Enabling Description: To distribute a large media file (e.g., a 4K movie), the system uses a hybrid approach. The server hosts the "first part" (a 720p version) on a standard HTTP CDN for fast, centralized delivery. Embedded within this file's metadata (e.g., in an MP4 udta box) is a magnet: URI for the "second part". A custom client application begins by downloading and playing the file from the CDN. While playing, it parses the metadata, extracts the magnet link, and joins a BitTorrent swarm to download the "second part" (a high-quality data file) from other peers in a decentralized manner. This reduces server load for the larger portion of the data. Once the peer-to-peer download is complete, the client combines the two parts.
• Diagram:

  graph TD
      subgraph Centralized Delivery
          A[CDN HTTP Server] -- Part 1 (720p version with embedded magnet link) --> B[Client Player];
      end
      subgraph Decentralized Delivery
          C{BitTorrent Swarm}
      end
      B -- Extracts magnet link & joins swarm --> C;
      C -- Part 2 (High-Q data) --> B;
      B --> D{Combiner};