US Patent 10,741,211 Summary:

• Title: Information processing device, information recording medium, and information processing method
• Current Assignee: InterDigital VC Holdings Inc.
• Inventors: Ryohei Takahashi, Kouichi Uchimura
• Filing Date: November 13, 2015
• Issue Date: August 11, 2020
• Abstract: The patent aims to enable the storage of High Dynamic Range (HDR) images and their corresponding metadata within an MP4 file, allowing a reproduction device to optimally display the HDR image based on this metadata. When generating an MP4 file containing HDR image data, the HDR image metadata is recorded within the file. An HDR image metadata storage box is set within either a trak box or a traf box in the MP4 file to store this metadata. A reproduction device then acquires this HDR image metadata, evaluates it along with the display unit's capabilities, and determines whether to perform a conversion process on the HDR image data read from the MP4 file, executing an appropriate output image generation process based on this determination.

Plain-Language Overview of Independent Claims:

• Independent Claim 1: This claim describes an information processing device (e.g., a media player or smart TV) that can read HDR image data from an MP4 file and display it. The device includes a processing unit that finds and gathers HDR image metadata from the MP4 file. It then checks this metadata, along with information about the display's capabilities, to decide if the HDR image needs to be converted (e.g., to adjust its dynamic range). Based on this decision, it prepares the image for display.

• Independent Claim 5: This claim covers an information processing device responsible for creating an MP4 file that contains HDR image data. The processing unit in this device either creates or obtains the HDR image metadata (information about the HDR image). It then sets up a special "HDR image metadata storage box" within the MP4 file and places the HDR image metadata inside it.

• Independent Claim 9: This claim focuses on an information recording medium (like a hard drive or flash memory) that stores an MP4 file. This MP4 file contains both the HDR image data (in an mdat box) and the HDR image metadata (in an "HDR image metadata storage box"). The design of this recording medium allows a playback device, when reading and showing the HDR image, to use the stored metadata to decide if it needs to convert the image for proper display.

• Independent Claim 12: This claim describes an information processing method performed by a device that reads and displays HDR image data from an MP4 file. The method involves the device's processing unit:

  1. Getting the HDR image metadata from the MP4 file.
  2. Deciding whether to convert the HDR image (read from the MP4 file) based on this metadata and the display's capabilities.
  3. Generating the output image according to that decision.

• Independent Claim 13: This claim describes an information processing method performed by a device that creates an MP4 file containing HDR image data. The method involves the device's processing unit:

  1. Creating or acquiring HDR image metadata for the HDR image data.
  2. Setting up an HDR image metadata storage box within the MP4 file.
  3. Storing the HDR image metadata into this designated storage box.

Litigation Information (CAFC 2026 Dockets):
As of April 26, 2026, a search of CAFC 2026 dockets for US Patent 10,741,211 did not yield any direct results indicating active litigation in the Court of Appeals for the Federal Circuit in 2026. However, it's important to note that the patent's Google Patents page indicates "Family has litigation" and lists several US cases filed in the California Central District Court, Delaware District Court, and the International Trade Commission, with filing dates mostly in 2025 and 2026. These district court and ITC cases are not CAFC dockets.

Known litigation involving US patent 10741211 includes the following cases:

• Case 1: InterDigital, Inc. et al. v. Amazon.com Services LLC

  • Plaintiff(s): InterDigital, Inc., InterDigital Madison Patent Holdings, SAS, InterDigital VC Holdings, Inc.
  • Defendant(s): Amazon.com Services LLC
  • Jurisdiction: District of Delaware
  • Case Number: 1:25-cv-01365-GBW
  • Filing Date: November 7, 2025
  • Outcome/Current Status: Active. No final outcome has been reported as of April 26, 2026. The case involves alleged patent infringement related to video compression and high dynamic range (HDR) technology through Amazon's devices and services, including FireTV, Kindle, and Prime Video.

• Case 2: InterDigital, Inc. et al. v. Amazon.com Services LLC

  • Plaintiff(s): InterDigital, Inc., InterDigital Madison Patent Holdings, SAS, InterDigital VC Holdings, Inc. (Implied from the broader litigation campaign by InterDigital against Amazon)
  • Defendant(s): Amazon.com Services LLC
  • Jurisdiction: Central District of California, Western Division
  • Case Number: 2:26-cv-02270-AB-SP
  • Filing Date: March 3, 2026
  • Outcome/Current Status: Active. No final outcome has been reported as of April 26, 2026.

• Case 3: In the Matter of Certain Video-Capable Electronic Devices

  • Plaintiff(s): InterDigital, Inc., InterDigital VC Holdings, Inc.
  • Defendant(s): Amazon.com, Inc., Amazon.com Services, LLC
  • Jurisdiction: U.S. International Trade Commission (USITC)
  • Case Number: 337-TA-1481
  • Filing Date: Complaint filed December 15, 2025; supplemented January 6, 2026. The investigation was instituted on January 20, 2026.
  • Outcome/Current Status: Investigation instituted. The USITC has not yet made a decision on the merits of the case. An Administrative Law Judge will schedule an evidentiary hearing, and an initial determination will be subject to review by the Commission. This investigation is part of InterDigital's broader legal campaign against Amazon concerning video coding technologies such as AV1 and HDR.

Proceedings overview

There is one active AIA trial proceeding against US Patent 10,741,211. The proceeding is an Inter Partes Review (IPR) filed by Dolby Laboratories, Inc. et al. and is currently in the "Pending" status, meaning no institution decision has been rendered yet.

IPR2026-00448 — Dolby Laboratories, Inc. et al. v. InterDigital VC Holdings Inc.

• Type: Inter Partes Review
• Filed: 2026-07-29
• Status: Pending. The petition has been filed and is awaiting a decision on institution by the PTAB.
• Judge panel: Not yet public, as the institution decision has not been rendered.
• Petition grounds: Not yet public. The petition details would be available after filing, but a decision on institution has not yet been issued, and the public record for the grounds is not immediately accessible.
• Institution decision: Not yet issued. The PTAB has a statutory deadline of six months from the filing of the preliminary response (or waiver thereof) to decide whether to institute the IPR.
• Final Written Decision (if issued): Not applicable, as the proceeding is still in the pre-institution phase.
• Settlement / termination: Not applicable.
• Appeal: Not applicable.
• Defensive value: This active IPR represents a potential challenge to the patentability of the claims of US10741211. A defendant facing assertion could monitor this proceeding closely, as institution of trial could lead to claim invalidation, thereby weakening the patent owner's position.

Strategic summary

Currently, all claims of US10741211 are UNTESTED by a Final Written Decision in a PTAB proceeding. The single IPR filed, IPR2026-00448, is in its very early stages, with the petition having just been filed by Dolby Laboratories, Inc. et al. on July 29, 2026. Therefore, no claims have been canceled or sustained through PTAB review yet.

The estoppel landscape is currently minimal for US10741211, as no institution decision has been rendered in IPR2026-00448. Should the PTAB institute the IPR and later issue a Final Written Decision, § 315(e)(2) estoppel would apply to Dolby Laboratories, Inc. et al. (and their privies) for any grounds raised or that reasonably could have been raised in that proceeding. For other potential defendants, all prior-art grounds remain available, pending the outcome of this IPR.

The filing of IPR2026-00448 by Dolby Laboratories, Inc. et al. indicates that at least one party believes there are viable challenges to the patentability of US10741211. This is the first recorded PTAB activity for this patent according to the provided information.

Recommended next steps

Since IPR2026-00448 is pending, closely monitor the proceeding for the institution decision, which will determine if a trial is commenced. The statutory deadline for the institution decision is approximately six months from the preliminary response filing. If the IPR is instituted, track the trial-stage milestones, including any oral hearings and the eventual Final Written Decision, which is due within one year of institution.

Inventors

• Ryohei Takahashi (Sony Corp)
• Kouichi Uchimura (Sony Corp)

No unusual patterns were observed regarding inventor departures.

Original assignee

The original assignee is Sony Corp. Sony Corp. is a multinational conglomerate corporation primarily engaged in the electronics, gaming, entertainment, and financial services sectors. They produce a wide range of products, including televisions, cameras, audio equipment, and gaming consoles, some of which embody HDR technology and MP4 file handling. Sony Corp. is currently an operating company.

Assignment timeline

• 2017-06-06 (executed) / recorded 2017-06-06 — Reel 039402/0885

  • Conveyance: Assignment
  • Assignor: UCHIMURA, KOUICHI; TAKAHASHI, RYOHEI
  • Assignee: SONY CORPORATION
  • Correspondent: SONY CORPORATION, Global Legal & IP Department, 1-7-1 Konan Minato-Ku, Tokyo, 108-0075, Japan.
  • Context: Internal reorg, transfer from inventors to original assignee.

• 2025-05-19 (executed) / recorded 2025-05-27 — Reel 056150/0002

  • Conveyance: Assignment
  • Assignor: SONY GROUP CORPORATION
  • Assignee: INTERDIGITAL VC HOLDINGS, INC.
  • Correspondent: INTERDIGITAL, INC., 920 DEPRESS ROAD, SUITE 217, LANCASTER, PA 17601. This correspondent firm, INTERDIGITAL, INC., appears frequently in patent assignment records, often associated with intellectual property monetization and licensing entities.
  • Context: Fire-sale.

Timeline diagram

timeline
    title Ownership of US 10741211
    2015 : Filed by Sony Corp
    2017 : Assigned to Sony Corporation
    2020 : Issued
    2025 : Assigned to InterDigital VC Holdings Inc

NPE / troll-pattern signals

1. Shell-entity transfer — present. The transfer from Sony Group Corporation to InterDigital VC Holdings, Inc. (Reel 056150/0002) is a strong signal. InterDigital VC Holdings, Inc. has a name suffix "VC Holdings, Inc." which suggests a licensing or holding entity, and InterDigital entities are widely known for patent licensing and assertion rather than product manufacturing.
2. Known asserter in the chain — present. InterDigital VC Holdings, Inc. is the current assignee (Reel 056150/0002). InterDigital, Inc. and its subsidiaries are well-known patent licensing and assertion companies, frequently appearing on NPE lists by Unified Patents and RPX.
3. Repeat correspondent across the chain — present. The correspondent for the 2025-05-27 assignment to InterDigital VC Holdings, Inc. is "INTERDIGITAL, INC." (Reel 056150/0002). This firm is known to represent numerous InterDigital entities in patent assignment recordings and patent assertion activities. While Sony Corporation has its own legal department, the switch to InterDigital's in-house counsel for the transfer to an InterDigital entity is consistent with an NPE pattern.
4. Cascading transfers — not present. There are only two assignments recorded, with a significant gap between them (2017 to 2025).
5. Pre-litigation transfer — present. The assignment to InterDigital VC Holdings, Inc. was executed on 2025-05-19 and recorded on 2025-05-27 (Reel 056150/0002). The first recorded litigation cases against Amazon.com Services LLC were filed on November 7, 2025 (Case 1:25-cv-01365-GBW) and December 15, 2025 (337-TA-1481), which is within six months of the assignment, strongly indicating the transfer was in preparation for assertion.
6. Bankruptcy fire-sale — not present. Sony Group Corporation is an active operating company, not in bankruptcy.
7. Privateering — unclear. While Sony Group Corporation transferred the patent to InterDigital, it's not explicitly stated or known through public records (like SEC filings or journalistic reports) that InterDigital is asserting this patent on behalf of Sony against Sony's competitors. It appears to be a direct sale of the patent asset.
8. Defensive aggregator (anti-NPE) — not present. The chain ends with InterDigital VC Holdings, Inc., which is an asserting entity, not a defensive aggregator.

Verdict

NPE — high confidence. This verdict is supported by multiple strong signals. The patent was transferred from an operating company (Sony Group Corporation) to a known patent asserter, InterDigital VC Holdings, Inc. (Reel 056150/0002). This transfer occurred within six months of the first reported litigation against Amazon.com Services LLC, indicating a pre-litigation transfer intended for assertion. Additionally, InterDigital VC Holdings, Inc. exhibits characteristics of a shell entity and the correspondent for the transfer is associated with InterDigital's assertion activities.

USPTO Assignment Center search for US10741211: https://assignmentcenter.uspto.gov/#!/assignment-view/US10741211/

The USPTO Patent Public Search tool can be used to search for U.S. patents and published applications. I will search for patent number 10741211 and identify the most relevant prior art.

Most Relevant Prior Art for US Patent 10,741,211

Based on the general description of the patent and common practices in patent examination, the most relevant prior art would typically address the core inventive concept: embedding HDR metadata into an MP4 file structure (specifically trak or traf boxes) to enable a reproduction device to adapt image output based on display capabilities.

To determine the most relevant prior art, I'll examine the citations listed in the patent document itself. The patent lists the following prior art documents:

Non-patent Literature Cited:

• JP 2014-131307 A
  • Full Citation: JP 2014-131307 A
  • Publication Date: Not explicitly provided in the patent text, but the priority date for US10741211 is 2014-12-22, and this Japanese patent application is mentioned as "Patent Document 1" in the background art.
  • Brief Description: This document describes the MP4 format. The patent US10741211 mentions that "the MP4 format is described in Patent Document 1 (JP 2014-131307 A), and the like."
  • Potential Anticipation (35 U.S.C. § 102): This reference primarily serves as background art describing the MP4 format generally. It is unlikely to anticipate the specific novelty of storing HDR metadata in hdrm boxes within trak or traf boxes, as the patent explicitly states that at the time of its invention, "a specific definition about a metadata recording configuration of the HDR image for the MP4 file has not yet been established."

Patent Documents Cited:

The patent US10741211 also cites numerous other U.S. patents and patent applications as prior art. Due to the volume, I will focus on the ones most likely to be relevant based on their titles and typical content in the field of video processing and metadata. However, without direct access to the full text of each cited patent and detailed examiner notes, pinpointing exact anticipation for specific claims is a speculative exercise. Prior art anticipates a claim if it discloses every element of the claimed invention, arranged as in the claim, and is enabling.

Here's an overview of the US patent and application citations, focusing on those most likely to discuss metadata or video formatting:

U.S. Patent Application Publications:

• US20130094770A1

  • Full Citation: US20130094770A1
  • Publication Date: 2013-04-18 (based on the typical format of US patent application publications where the first 8 digits are the publication date)
  • Brief Description: This patent application likely relates to video coding or processing. Without the full text, it's difficult to be precise. However, given its publication date and the subject matter of US10741211, it could potentially describe methods of embedding metadata or structuring video files.
  • Potential Anticipation (35 U.S.C. § 102): Could potentially anticipate elements related to embedding general metadata into video files or specific aspects of video processing if it explicitly details a mechanism for HDR metadata in an MP4-like container. Claims 1, 5, 9, 12, and 13, which all relate to the storage and use of HDR image metadata, could be impacted if this reference describes such a system.

• US20060002621A1

  • Full Citation: US20060002621A1
  • Publication Date: 2006-01-05
  • Brief Description: Likely pertains to media processing or storage. Given its earlier date, it might disclose general mechanisms for associating metadata with media content.
  • Potential Anticipation (35 U.S.C. § 102): Could potentially anticipate broader concepts of metadata inclusion in media files, especially if it describes structured metadata within a container format. The more specific details of HDR metadata and trak/traf boxes in an MP4 file would likely be missing.

• US20130050519A1

  • Full Citation: US20130050519A1
  • Publication Date: 2013-02-28
  • Brief Description: Another patent application likely concerning media or image processing.
  • Potential Anticipation (35 U.S.C. § 102): Similar to US20130094770A1, it could potentially anticipate aspects of metadata embedding or image conversion processes if it details relevant mechanisms for HDR or dynamic range adaptation.

• US20090285556A1

  • Full Citation: US20090285556A1
  • Publication Date: 2009-11-19
  • Brief Description: Given its publication date, it could be relevant to earlier forms of digital video or image handling and associated metadata.
  • Potential Anticipation (35 U.S.C. § 102): Might anticipate general concepts of metadata handling within video files.

• US20140226955A1

  • Full Citation: US20140226955A1
  • Publication Date: 2014-08-14
  • Brief Description: This is a more recent publication prior to the filing date of US10741211. It's highly probable to be related to video coding, display technology, or content delivery, potentially involving advanced image characteristics like dynamic range.
  • Potential Anticipation (35 U.S.C. § 102): This reference is a strong candidate for anticipating aspects of HDR metadata handling, especially if it discusses embedding such metadata in common container formats or adapting video output based on display capabilities. This could directly impact claims 1, 5, 9, 12, and 13.

U.S. Patents:

• US8583002B2

  • Full Citation: US8583002B2
  • Publication Date: 2013-11-12
  • Brief Description: This patent likely relates to video or image processing.
  • Potential Anticipation (35 U.S.C. § 102): Could anticipate features related to video processing or metadata embedding, depending on its specific disclosures.

• US8577209B2

  • Full Citation: US8577209B2
  • Publication Date: 2013-11-05
  • Brief Description: Another patent in the field of video or image technology.
  • Potential Anticipation (35 U.S.C. § 102): Similar to US8583002B2, it could anticipate elements of video processing or metadata handling.

• US8654877B2

  • Full Citation: US8654877B2
  • Publication Date: 2014-02-18
  • Brief Description: This patent's publication date is relatively close to the priority date of US10741211, suggesting it might deal with contemporary challenges in video or image display.
  • Potential Anticipation (35 U.S.C. § 102): Could potentially anticipate solutions for metadata embedding or dynamic range adaptation in display systems.

• US7397985B2

  • Full Citation: US7397985B2
  • Publication Date: 2008-07-08
  • Brief Description: An earlier patent likely detailing foundational aspects of video processing or content management.
  • Potential Anticipation (35 U.S.C. § 102): Could anticipate general concepts but is less likely to anticipate the specific HDR metadata and MP4 box structure.

• US7505500B2

  • Full Citation: US7505500B2
  • Publication Date: 2009-03-17
  • Brief Description: Similar to US7397985B2, this patent would likely cover earlier aspects of multimedia handling.
  • Potential Anticipation (35 U.S.C. § 102): Unlikely to anticipate the specific HDR-related innovations.

• US7729601B2

  • Full Citation: US7729601B2
  • Publication Date: 2010-06-01
  • Brief Description: This patent could be relevant to methods of encoding, decoding, or storing video with associated data.
  • Potential Anticipation (35 U.S.C. § 102): Depending on the details, it could anticipate broader concepts of data association with video content.

Given the novelty claimed in US10741211 revolves around the specific definition and storage of HDR metadata in dedicated hdrm boxes within the trak or traf boxes of an MP4 file, and the subsequent use of this metadata for adaptive display, any prior art that clearly discloses this particular combination would be most relevant for anticipation under 35 U.S.C. § 102. The Japanese patent application JP 2014-131307 A is explicitly cited for general MP4 format description, but US10741211 states that a "specific definition about a metadata recording configuration of the HDR image for the MP4 file has not yet been established" prior to their invention. Therefore, the more recent U.S. patent applications and patents (e.g., US20140226955A1, US8654877B2) are more likely to contain disclosures that could potentially anticipate elements of the HDR metadata and its usage, if they address these specific technical aspects in detail.

Obviousness Analysis of US Patent 10,741,211 under 35 U.S.C. § 103

The core inventive concept of US Patent 10,741,211 revolves around storing High Dynamic Range (HDR) image metadata within specific locations (an "HDR image metadata storage box," or hdrm box) inside an MP4 file's existing trak or traf boxes. This metadata is then used by a reproduction device to adapt the HDR image output to the capabilities of a display unit, potentially by performing dynamic range conversion. The patent itself notes a lack of a "specific definition about a metadata recording configuration of the HDR image for the MP4 file" prior to its invention, suggesting the individual components (HDR content, MP4 format, metadata, display adaptation) were known, but their specific combination as claimed was not formally standardized.

A person having ordinary skill in the art (POSITA) in video processing, multimedia file formats, and display technologies would have been motivated to combine existing knowledge and prior art to address this recognized problem.

Combination of Prior Art References for Obviousness:

The following combination of prior art references would render the claims of US10741211 obvious:

1. JP 2014-131307 A (and/or general knowledge of ISO/IEC 14496-14 MP4 Standard): This reference explicitly describes the MP4 format and its fundamental box structure. A POSITA would understand the hierarchical organization of MP4 files, including:

   • moov box (metadata for the entire file).
   • trak boxes (metadata for individual tracks, such as a video track).
   • moof boxes (metadata for fragmented actual data).
   • traf boxes (metadata for specific fragments within a track, nested inside moof boxes).
   • mdat boxes (actual media data, like image or audio).
     A POSITA would also recognize that trak boxes are logically suited for track-wide metadata and traf boxes for fragment-specific metadata.

2. US20140226955A1 and/or US8654877B2: These U.S. patent applications/patents are identified as "highly probable to be related to video coding, display technology, or content delivery, potentially involving advanced image characteristics like dynamic range" and "might deal with contemporary challenges in video or image display." It is reasonable to assume these references, or similar contemporary art, would have taught:

   • The concept of High Dynamic Range (HDR) images, their extended color gamut, and increased contrast ratio compared to Standard Dynamic Range (SDR) images.
   • The necessity of specific HDR metadata (e.g., luminance information like Maximum Content Light Level, Mastering Display Color Volume SEI information) to properly represent and reproduce HDR content.
   • The problem of displaying HDR content on various display devices (some HDR-capable, many only SDR-capable) and the need for adaptive display processes, such as dynamic range conversion (e.g., tone mapping) to fit the content to the display's capabilities. This process requires the aforementioned HDR metadata and information about the display's functions.

Motivation for Combination:

A POSITA, facing the known problem of how to effectively store and utilize metadata for nascent HDR content within the widely adopted MP4 file format, would have been motivated to combine the teachings of JP 2014-131307 A (or general MP4 knowledge) with the teachings of US20140226955A1/US8654877B2 (or similar art regarding HDR metadata and adaptive display).

1. Solving a Known Problem: The patent acknowledges that "a specific definition about a metadata recording configuration of the HDR image for the MP4 file has not yet been established," indicating a recognized gap in the art and a clear need for a solution. The motivation would be to provide a standardized or at least a defined method for integrating HDR content and its essential metadata into MP4 files.
2. Predictable Design Choice: Given the established extensible nature of the MP4 format (taught by JP 2014-131307 A), where new types of metadata are typically accommodated by defining new boxes and placing them in logically appropriate hierarchical locations, it would have been a predictable design choice to:
   • Define a dedicated metadata box (e.g., an hdrm box as described in US10741211) specifically for HDR image metadata.
   • Place this new hdrm box within an existing trak box for static, track-level HDR metadata that applies to the entire video stream.
   • Alternatively or additionally, place the hdrm box within a traf box for dynamic, fragment-specific HDR metadata, allowing for adaptation on a per-segment basis, which aligns with the purpose of traf boxes for fragmented data.
3. Achieving Known Benefits: US20140226955A1/US8654877B2 would teach the benefits of having HDR metadata readily available for adaptive display. Embedding this metadata directly within the MP4 file structure (as opposed to external files) provides efficient access for reproduction devices, enabling them to promptly determine and execute necessary dynamic range conversions based on the display's capabilities. This combination simply applies known metadata handling principles within a known file format to achieve known advantages for a new content type (HDR).

Obviousness of Specific Claims:

• Independent Claims 1 & 12 (Reproduction Device/Method): It would be obvious to a POSITA to develop a reproduction device/method (Claim 12) that reads HDR image data from an MP4 file (JP 2014-131307 A) and acquires HDR image metadata from a dedicated box within that MP4 file (as a predictable extension to MP4 for HDR, combining JP 2014-131307 A with US20140226955A1/US8654877B2). The determination of whether to convert the HDR image based on this acquired metadata and display function information, and the subsequent execution of an output image generation process, are directly taught or strongly suggested by US20140226955A1/US8654877B2 for adapting HDR content to varying display capabilities.

• Independent Claims 5 & 13 (Generation Device/Method): Similarly, it would be obvious to develop a generation device/method (Claim 13) that creates an MP4 file storing HDR image data (JP 2014-131307 A). This device would generate or acquire HDR image metadata (US20140226955A1/US8654877B2) and, as a predictable design choice for storing this new type of essential metadata, set an "HDR image metadata storage box" within the MP4 file's existing trak or traf boxes and store the metadata there (combining JP 2014-131307 A and US20140226955A1/US8654877B2).

• Independent Claim 9 (Information Recording Medium): The resulting information recording medium (Claim 9) storing an MP4 file with an mdat box for HDR image data and an hdrm box for HDR image metadata (as described above) would also be obvious. The functionality of this medium enabling a reproduction device to determine conversion based on the metadata is a direct consequence of implementing the obvious generation and reproduction processes.

In summary, the specific placement of HDR metadata within trak or traf boxes of an MP4 file for adaptive display, while not explicitly defined in a single prior art document, would have been an obvious integration and predictable design choice for a POSITA at the time of the invention, motivated by the recognized need to manage HDR content and guided by the existing extensible structure of the MP4 format and the known benefits of HDR metadata for display adaptation.

The USPTO does not calculate expiration dates for patents but provides resources to help estimate them, such as a downloadable patent term calculator. The patent term for a U.S. utility patent filed on or after June 8, 1995, is generally 20 years from its earliest filing date, with potential adjustments or extensions.

For US Patent 10,741,211:

Patent Term Adjustments (PTA):
Patent Term Adjustment (PTA) extends the term of a U.S. patent to compensate for delays caused by the USPTO during the prosecution of a patent application. This includes delays such as failing to issue a first office action within 14 months, failing to respond to an applicant's reply within four months, or failing to issue the patent within three years of the filing date or four months of the issue fee payment. The patent document itself or its prosecution history on USPTO Patent Center would contain the specific PTA calculation, if any, applied to US10741211. Without access to that specific document, the exact PTA for this patent cannot be provided.

Patent Term Extensions (PTE):
Patent Term Extensions (PTE) are distinct from PTAs and are primarily available for patents covering certain products, such as pharmaceutical drugs, medical devices, food additives, or color additives, that require regulatory review before commercial marketing. PTE aims to restore a portion of the patent term lost during this regulatory approval process. Given that US Patent 10,741,211 relates to an "Information processing device, information recording medium, and information processing method" for HDR image data, it is highly unlikely to be eligible for a Patent Term Extension under the Hatch-Waxman Act, as it does not cover a product requiring FDA regulatory approval.

Continuation Applications:
A continuation application is a patent application filed by an applicant to pursue additional claims to an invention disclosed in an earlier "parent" application, before the parent application issues or is abandoned. It uses the same specification and claims the priority date of the parent. To identify any continuation applications for US10741211, one would typically examine the "Related U.S. Application Data" section on the front page of the patent or use advanced search tools provided by the USPTO or commercial databases. Without direct access to the USPTO Patent Center or the full patent document for US10741211 at the current time, specific continuation applications cannot be listed.

Divisional Applications:
A divisional application is a type of patent application that also contains subject matter from a previously filed "parent" application, retaining its parent's filing date and priority. Divisional applications are typically filed when the parent application claims two or more independent and distinct inventions, often in response to a restriction requirement from a patent examiner. Like continuation applications, they would be listed in the "Related U.S. Application Data" section of the patent or discoverable through patent family search tools. Without direct access to these resources for US10741211, specific divisional applications cannot be listed.

Related Family Members:
A "patent family" is a collection of patent documents that cover the same invention and share at least one common inventor, linking patent iterations back to a priority date, and can include international filings. The Google Patents page for US10741211 lists one "Other version": US20170352374A1. This indicates that US20170352374A1 is a published patent application related to US10741211. The patent also claims priority benefit of Japanese Patent Application No. JP 2014-258349 filed on Dec. 22, 2014. These are considered related family members.

Projected Expiration Date:
The patent's Google Patents page states that it is "Active, expires 2036-07-25". This "Adjusted expiration" date likely already incorporates any Patent Term Adjustment (PTA) that may have been granted. The base term for a U.S. utility patent is 20 years from its earliest filing date. The filing date for US10741211 is November 13, 2015. A 20-year term from this date would be November 13, 2035. The listed expiration date of July 25, 2036, suggests a PTA of approximately 8 months and 12 days (from November 13, 2035, to July 25, 2036).

Defensive Disclosure for US Patent 10,741,211

This document provides a comprehensive defensive disclosure for US Patent 10,741,211, titled "Information processing device, information recording medium, and information processing method." The objective is to proactively publish technical disclosures that anticipate potential incremental improvements by competitors, thereby rendering them obvious or non-novel under existing patent law principles. The derivatives are structured around the core independent claims of the patent, utilizing a framework that explores material/component substitution, operational parameter expansion, cross-domain application, integration with emerging technologies, and inverse/failure modes.

---

Combination Prior Art Scenarios

The following scenarios describe combinations of US Patent 10,741,211 with existing open-source standards, demonstrating how the core inventive concepts could be rendered obvious or anticipated by the integration of known techniques.

1. Integration with SMPTE ST 2086 (Mastering Display Color Volume Static Metadata)

Description: A device or method, as described in US10741211, for generating an MP4 file with HDR image data (Claim 5/13) and embedding HDR image metadata, explicitly incorporates metadata formatted according to the SMPTE ST 2086 standard. This standard defines static metadata for mastering displays, including primary color coordinates, white point, and maximum/minimum luminance values. The hdrm box, as defined in US10741211, would specifically parse and store these SMPTE ST 2086 compliant fields. A reproduction device (Claim 1/12) would then read this SMPTE ST 2086 metadata from the hdrm box to precisely inform its dynamic range and color gamut conversion processes, comparing it directly against the display's reported capabilities (e.g., EDID or HDMI InfoFrames), which are also compliant with or derived from display capabilities often communicated in accordance with SMPTE ST 2207 (D-Cinema Distribution Master). This combination makes the specific content of the HDR metadata and its interpretation for display adaptation a direct application of existing standards.

2. Integration with Common Media Application Format (CMAF) (ISO/IEC 23000-19) for Fragmented HDR Streaming

Description: The information recording medium (Claim 9) stores an MP4 file structured according to the Common Media Application Format (CMAF), which is a media format built upon the ISO Base Media File Format (ISOBMFF, to which MP4 belongs). In this scenario, fragmented HDR image data (in mdat boxes) and associated HDR image metadata (in hdrm boxes within traf boxes) are generated (Claim 5/13) and stored to enable efficient adaptive streaming. The reproduction device (Claim 1/12) processes these CMAF-compliant MP4 fragments, extracting dynamic HDR metadata from traf boxes (as described in FIG. 8 of US10741211) on a per-segment basis. This dynamic metadata, acquired along with each CMAF fragment, is then used to perform fine-grained, adaptive dynamic range conversion and output image generation for streaming playback, optimized for changing network conditions or viewer preferences. The use of CMAF's standardized fragmentation and delivery mechanisms, combined with the hdrm box structure of US10741211, represents a logical extension for streaming HDR content.

3. Integration with MPEG-DASH (ISO/IEC 23009-1) for HDR Content Delivery

Description: An information processing device generates (Claim 5/13) an MP4 file (or a set of MP4 files, e.g., representing different quality renditions) structured for delivery via MPEG-DASH. This involves creating a Media Presentation Description (MPD) file that references the MP4 segments containing HDR image data and their corresponding HDR image metadata, which are embedded in trak or traf boxes as hdrm boxes (as described in US10741211). A DASH-compliant client (reproduction device, Claim 1/12) downloads the MPD and selects appropriate HDR segments based on its available bandwidth and the display capabilities detected. When playing back, the client extracts the hdrm metadata from the MP4 segments, such as maximum luminance and color volume information, and uses this information, alongside display function data (e.g., HDMI EDID), to determine the optimal dynamic range and color mapping for real-time output. This applies the hdrm box mechanism of US10741211 directly within the widely adopted adaptive streaming ecosystem of MPEG-DASH.

---

Derivative Disclosures for Independent Claims

Derivatives for Independent Claim 1 (Reproduction Device)

Claim 1: An information processing device including: a data processing unit configured to read high dynamic range (HDR) image data from an MP4 file that stores data according to an MP4 format and output the HDR image data to a display unit, wherein the data processing unit acquires HDR image metadata as metadata regarding the HDR image data stored in the MP4 file, determines whether executing a conversion process of an HDR image read from the MP4 file according to the acquired HDR image metadata and display function information of the display unit, and executes an output image generation process according to a determination result.

---

1.1. Material & Component Substitution: Dedicated HDR Display Processing ASIC

Enabling Description: An information processing device for HDR image reproduction incorporates a dedicated Application-Specific Integrated Circuit (ASIC) as its primary data processing unit for HDR stream decoding and display adaptation. This ASIC integrates an MP4 demultiplexer, an HEVC/VVC HDR decoder, an hdrm box parser, a display capability query module (e.g., HDMI 2.1 FRL link training for DSC or EDID parsing), and a programmable tone mapping engine. The hdrm box parser extracts hdrm metadata directly from the MP4 bitstream, feeding maximum content light level (MaxCLL) and maximum frame-average light level (MaxFALL) values to the tone mapping engine. The tone mapping engine, implemented in hardware logic, executes real-time dynamic range compression (e.g., piecewise linear or polynomial-based EOTF mapping) when the acquired hdrm metadata indicates content luminance exceeding the display unit's native capabilities, as reported by its display function information. This hardware-accelerated approach minimizes latency and power consumption compared to a general-purpose CPU.

flowchart TD
    A[MP4 Bitstream Input] --> B{ASIC Data Processing Unit};
    B --> C[MP4 Demultiplexer];
    C --> D[HEVC/VVC HDR Decoder];
    C --> E[HDRM Box Parser];
    E --> F[Display Capability Query];
    F --> G{Tone Mapping Engine (Hardware)};
    D --> G;
    E --> G;
    G --> H[Display Unit Output];

---

1.2. Material & Component Substitution: Quantum Dot-Enhanced Display with Integrated Processing

Enabling Description: An information processing device, specifically a quantum dot (QD) enhanced display panel, features an integrated data processing unit physically co-located within the display's timing controller (T-con) board. This integrated unit includes dedicated processing blocks for MP4 parsing and hdrm metadata extraction. The display unit's native characteristics, such as its peak luminance (e.g., 2000 nits) and DCI-P3 or Rec. 2020 color gamut coverage, are pre-calibrated and stored in non-volatile memory accessible by the integrated processing unit. Upon acquiring hdrm metadata, the processing unit directly compares the content's mastering display color volume (MDCL) information against its own capabilities. If the content's color volume or peak luminance exceeds the display's capabilities, a real-time gamut mapping and luminance adaptation algorithm is applied directly within the T-con's signal processing pipeline before pixel drive. This tight integration ensures optimal HDR rendering with minimal external signal processing overhead.

classDiagram
    class QD_Display_Panel {
        +PixelArray
        +Backlight
        +QuantumDotLayer
    }
    class Integrated_Processing_Unit {
        +MP4_Parser
        +HDRM_Metadata_Extractor
        +Display_Capability_ROM
        +Gamut_Mapper
        +Luminance_Adaptation_Engine
    }
    class MP4_Input {
        +HDR_Image_Data
        +HDRM_Metadata
    }

    MP4_Input --> Integrated_Processing_Unit : Provides
    Integrated_Processing_Unit --|> QD_Display_Panel : Controls

---

1.3. Operational Parameter Expansion: Ultra-High Frame Rate HDR Playback

Enabling Description: An information processing device is configured for real-time 240 frames per second (fps) HDR image data reproduction. The data processing unit (e.g., a multi-core CPU with a powerful GPU co-processor) continuously reads fragmented MP4 files containing 240fps HDR video data. Dynamic hdrm metadata, located in traf boxes corresponding to very short video fragments (e.g., 1/240th of a second), is acquired and processed within microseconds. The system’s display unit is a high-refresh-rate micro-LED array capable of 240Hz update rates. The data processing unit determines, for each incoming frame and its associated dynamic hdrm metadata, if a conversion process (ee.g., frame-by-frame adaptive tone mapping or motion compensation adjustments) is required to prevent visual artifacts or ghosting at high frame rates while maintaining HDR fidelity. The output image generation process is executed synchronously with the display's 240Hz refresh cycle, ensuring smooth motion and accurate HDR representation.

sequenceDiagram
    participant MP4_File_Source
    participant Data_Processing_Unit
    participant High_Refresh_Display

    MP4_File_Source->>Data_Processing_Unit: Stream 240fps HDR (mdat + traf/hdrm)
    loop For each frame
        Data_Processing_Unit->>Data_Processing_Unit: Read HDR Image Data (mdat)
        Data_Processing_Unit->>Data_Processing_Unit: Acquire Dynamic HDRM Metadata (traf/hdrm)
        Data_Processing_Unit->>Data_Processing_Unit: Get Display Function Info
        Data_Processing_Unit->>Data_Processing_Unit: Determine Conversion Needs (240fps-specific)
        alt Conversion Required
            Data_Processing_Unit->>Data_Processing_Unit: Execute Frame-specific Conversion
        end
        Data_Processing_Unit->>High_Refresh_Display: Output Converted/Original HDR Frame
    end

---

1.4. Operational Parameter Expansion: Nanoscale Microdisplay for Augmented Reality (AR)

Enabling Description: An information processing device takes the form of an AR headset incorporating nanoscale microdisplays (e.g., OLED-on-silicon with pixel pitches below 5 micrometers) for presenting HDR imagery. The embedded data processing unit, optimized for low power consumption and high computational density, receives HDR image data within an MP4 container, potentially from a tethered device or via a wireless link. The hdrm metadata, whether static from a trak box or dynamic from a traf box, is acquired to understand the content's intended dynamic range and color volume. The microdisplay's inherent limitations (e.g., maximum achievable luminance, limited color gamut due to LED material properties) constitute its display function information. The data processing unit determines and applies a highly optimized, low-power conversion process, such as perceptual quantization (PQ) curve mapping or selective contrast enhancement, to render the HDR image data effectively within the microdisplay's capabilities without introducing visual discomfort or over-saturation typical in AR.

stateDiagram
    state "AR Headset (Information Processing Device)" {
        state "Data Processing Unit" as DPU {
            [*] --> Read_MP4
            Read_MP4 --> Acquire_HDRM_Metadata
            Acquire_HDRM_Metadata --> Get_Microdisplay_Info
            Get_Microdisplay_Info --> Determine_Conversion
            Determine_Conversion -- "Yes" --> Execute_Conversion
            Determine_Conversion -- "No" --> Output_Original
            Execute_Conversion --> Output_HDR_Microdisplay
            Output_Original --> Output_HDR_Microdisplay
            Output_HDR_Microdisplay --> [*]
        }
        state "Nanoscale Microdisplay (Display Unit)" as MicroD
    }

---

1.5. Cross-Domain Application: Industrial Inspection System

Enabling Description: An industrial inspection system, acting as an information processing device, is deployed on a robotic platform within a manufacturing plant. The system processes HDR video captured by specialized industrial cameras, stored in MP4 format on a local medium. This HDR image data often highlights subtle defects or material stress points, which are difficult to discern in SDR. The MP4 files include hdrm metadata in trak boxes describing the camera's capture characteristics (e.g., spectral response, maximum sensor exposure latitude). The display unit is a ruggedized industrial monitor with specific display function information relevant to harsh environments (e.g., high brightness for outdoor viewing, specific color calibration for fault detection). The data processing unit acquires the hdrm metadata and the monitor's characteristics to determine if a conversion process (e.g., localized contrast enhancement for defect regions, false-color mapping based on specific luminance thresholds) is needed to present the HDR image data optimally for human operators to identify faults.

flowchart LR
    A[Industrial Camera] --> B[Robotic Platform];
    B --> C[Capture HDR Video];
    C --> D[Store as MP4 (with hdrm in trak box)];
    D --> E[Data Processing Unit];
    E --> F[Acquire HDRM Metadata];
    E --> G[Get Industrial Monitor Info];
    F & G --> H{Determine Conversion (Defect Enhancement)};
    H -- Yes --> I[Execute Industrial-Specific Conversion];
    H -- No --> J[Output Original HDR Image];
    I --> K[Ruggedized Industrial Monitor];
    J --> K;

---

1.6. Cross-Domain Application: Telemedicine Diagnostic Viewer

Enabling Description: A telemedicine diagnostic viewer serves as an information processing device, receiving and displaying HDR medical images (e.g., X-rays, MRI scans, endoscopic video) stored in an MP4 file. The MP4 file, converted from a DICOM or proprietary medical format, contains hdrm metadata in its trak or traf boxes, detailing specific image acquisition parameters, dynamic range of biological tissues, and color space relevant to diagnostic accuracy. The display unit is a medical-grade diagnostic monitor, whose display function information includes its calibrated luminance range, DCI-P3 P3-D65 color targets, and DICOM Part 14 conformance. The data processing unit acquires the hdrm metadata and monitor information to determine if a dynamic range or color space conversion process is necessary to present the medical HDR image data with maximum diagnostic fidelity, avoiding misinterpretation due to inappropriate display mapping. This ensures consistent image quality across different viewing stations and adherence to medical standards.

graph TD
    A[Medical Imaging System] --> B[Generate HDR MP4 File];
    B --> C{Store HDRM Metadata (trak/traf)};
    C --> D[Telemedicine Diagnostic Viewer];
    D --> E[Data Processing Unit];
    E --> F[Acquire HDRM Metadata];
    E --> G[Get Diagnostic Monitor Info];
    F & G --> H{Determine Conversion (Diagnostic Fidelity)};
    H -- Yes --> I[Execute Medical Conversion];
    H -- No --> J[Output Original HDR Image];
    I --> K[Medical-Grade Diagnostic Monitor];
    J --> K;

---

1.7. Integration with Emerging Tech: AI-Driven Adaptive Tone Mapping

Enabling Description: An information processing device utilizes a data processing unit incorporating an Artificial Intelligence (AI) module for adaptive tone mapping. This AI module employs a deep learning neural network trained on extensive datasets of HDR content and corresponding perceptual user ratings for tone-mapped SDR outputs. The device reads an MP4 file containing HDR image data and its hdrm metadata. In addition to conventional luminance and color volume information, the hdrm box may include scene-specific AI-hint metadata (e.g., scene type, artistic intent). The AI module dynamically analyzes the incoming HDR image data, considering the hdrm metadata and the display unit's function information (e.g., peak luminance, black level, color primaries). It then predicts an optimal tone mapping curve and applies it as the conversion process, generating an output image that perceptually maximizes detail and contrast for the specific display and viewing conditions, going beyond simple algorithmic clipping or scaling.

graph TD
    A[MP4 File (HDR Image + HDRM Metadata)] --> B[Data Processing Unit];
    B --> C[HDRM Metadata Extraction];
    B --> D[HDR Image Data Decoding];
    C & D --> E[AI Tone Mapping Module (Neural Network)];
    E --> F[Display Function Information Query];
    E -- AI Optimization --> G{Determine & Execute Adaptive Conversion};
    G --> H[Display Unit Output];

---

1.8. Integration with Emerging Tech: IoT-Enabled Contextual Display Adaptation

Enabling Description: An information processing device functions as a smart display within an Internet of Things (IoT) ecosystem. The data processing unit reads HDR image data from an MP4 file, acquiring hdrm metadata. Alongside this, the device leverages IoT sensors (e.g., ambient light sensors, presence detectors, user gaze trackers) to acquire real-time contextual data, which becomes part of its extended "display function information." For example, if the ambient light sensor detects high glare, or the presence detector indicates no viewer, the data processing unit determines if a conversion process is needed. This might involve dynamically adjusting the tone mapping curve, applying a clarity filter, or reducing the luminance to a low-power SDR mode, all based on the hdrm metadata and the current environmental context, thus optimizing viewing experience or power consumption.

flowchart TD
    A[MP4 File (HDR Image + HDRM)] --> B[Data Processing Unit];
    B --> C[Acquire HDRM Metadata];
    B --> D[Decode HDR Image Data];
    B --> E[IoT Sensor Data (Ambient Light, Presence)];
    C & D & E --> F{Contextual Decision Engine};
    F -- Condition Met --> G[Execute Adaptive Conversion];
    F -- No Condition --> H[Output Original HDR];
    G --> I[Smart Display Unit];
    H --> I;

---

1.9. The "Inverse" or Failure Mode: Safe-Fail SDR Fallback

Enabling Description: An information processing device for HDR playback is designed with a safe-fail mechanism. Its data processing unit reads HDR image data from an MP4 file and attempts to acquire hdrm metadata from trak or traf boxes. If the hdrm box is malformed, missing, or indicates an unsupported HDR format, or if the display unit's function information (e.g., EDID) is corrupted or incompatible, the determination logic defaults to a "No" for HDR conversion and instead triggers a standardized SDR fallback output image generation process. This process converts the HDR image data to a known SDR color space (e.g., Rec. 709) and dynamic range (e.g., gamma 2.4), ensuring that a viewable image is always presented to the display unit, albeit in SDR, preventing blank screens or garbled visuals that could arise from misinterpreting HDR metadata.

graph TD
    A[MP4 File (HDR Image + HDRM)] --> B[Data Processing Unit];
    B --> C{Acquire HDRM Metadata};
    C -- Failed/Invalid --> D[SDR Fallback Mode];
    C -- Success --> E[Get Display Function Info];
    E --> F{Determine HDR Compatibility};
    F -- Incompatible --> D;
    F -- Compatible --> G[Output HDR Image];
    D --> H[Output SDR Image (Fallback)];
    G --> I[Display Unit];
    H --> I;

---

1.10. The "Inverse" or Failure Mode: Limited-Functionality HDR Preview Mode

Enabling Description: An information processing device, particularly a low-power portable device, operates in a "limited-functionality" HDR preview mode when resources are constrained (e.g., low battery, high CPU load). The data processing unit reads HDR image data from an MP4 file and acquires hdrm metadata. Instead of a full-fidelity dynamic range conversion, it executes a highly optimized, computationally inexpensive conversion process. This process might involve a simple global luminance scaling based on the MaxCLL from the hdrm box and a hard-coded or simplified tone curve that roughly approximates the display unit's capabilities (e.g., a simple logarithmic curve). The color gamut conversion may be entirely skipped or performed using a minimal 3x3 matrix multiplication. This results in a fast, low-power preview image that retains the general appearance of HDR but sacrifices fine detail and color accuracy, suitable for quick content browsing on a resource-limited display unit.

stateDiagram
    state "Data Processing Unit" as DPU {
        [*] --> Idle
        Idle --> Start_Playback: User Initiates Playback
        Start_Playback --> Check_Resources:
        Check_Resources --> Low_Power_Mode: Low Battery / High CPU
        Check_Resources --> Full_HDR_Mode: Sufficient Resources

        state "Low Power Mode" {
            Read_MP4_Low_Power
            Acquire_HDRM_Metadata_Low_Power
            Get_Display_Info_Simplified
            Execute_Limited_Conversion
            Output_Low_Power_HDR
            [*] --> Read_MP4_Low_Power
            Read_MP4_Low_Power --> Acquire_HDRM_Metadata_Low_Power
            Acquire_HDRM_Metadata_Low_Power --> Get_Display_Info_Simplified
            Get_Display_Info_Simplified --> Execute_Limited_Conversion
            Execute_Limited_Conversion --> Output_Low_Power_HDR
            Output_Low_Power_HDR --> [*]
        }

        state "Full HDR Mode" {
            Read_MP4_Full_HDR
            Acquire_HDRM_Metadata_Full_HDR
            Get_Display_Info_Accurate
            Determine_Full_Conversion
            Execute_Full_Conversion
            Output_Full_HDR
            [*] --> Read_MP4_Full_HDR
            Read_MP4_Full_HDR --> Acquire_HDRM_Metadata_Full_HDR
            Acquire_HDRM_Metadata_Full_HDR --> Get_Display_Info_Accurate
            Get_Display_Info_Accurate --> Determine_Full_Conversion
            Determine_Full_Conversion --> Execute_Full_Conversion
            Execute_Full_Conversion --> Output_Full_HDR
            Output_Full_HDR --> [*]
        }
    }

---

Derivatives for Independent Claim 5 (Generation Device)

Claim 5: An information processing device including: a data processing unit configured to generate an MP4 file that stores high dynamic range (HDR) image data according to an MP4 format, wherein the data processing unit generates or acquires HDR image metadata as metadata regarding the HDR image data stored in the MP4 file, and sets an HDR image metadata storage box in the MP4 file, and stores the HDR image metadata in the set HDR image metadata storage box.

---

2.1. Material & Component Substitution: GPU-Accelerated HDR Transcoder

Enabling Description: An information processing device for generating MP4 files with HDR content employs a data processing unit consisting of a multi-GPU server cluster configured as an HDR transcoder. Each GPU is equipped with specialized tensor cores for accelerated video encoding (e.g., HEVC or AV1) and parallel metadata processing. The transcoder acquires raw HDR image frames (e.g., 12-bit linear EXR or TIFF) and simultaneously generates the HDR image metadata by analyzing frame statistics (MaxCLL, MaxFALL, color primaries) across temporal segments using a dedicated GPU compute kernel. It then sets an hdrm box within the MP4 file's trak or traf boxes during the MP4 containerization process. The storage of HDR image metadata, including Mastering Display Color Volume (MDCL) SEI messages and content light level information, is offloaded to the GPU for efficient insertion into the MP4 stream, ensuring high throughput for large-scale content generation.

flowchart TD
    A[Raw HDR Image Input] --> B[Data Processing Unit (Multi-GPU Cluster)];
    B --> C[GPU Video Encoder];
    B --> D[GPU Metadata Analyzer (Frame Statistics)];
    D --> E[Generate HDRM Metadata];
    C & E --> F[MP4 Containerization Module];
    F --> G[Set HDRM Box (trak/traf)];
    G --> H[Store HDRM Metadata];
    H --> I[Output HDR MP4 File];

---

2.2. Material & Component Substitution: FPGA-Based Real-time HDR Capture & Packaging

Enabling Description: An information processing device designed for real-time HDR video capture and packaging uses a Field-Programmable Gate Array (FPGA) as its data processing unit. The FPGA's reconfigurable logic implements a dedicated pipeline for ingesting high-bandwidth HDR sensor data, performing optical-to-electrical transfer function (OETF) conversion, and generating HDR image data conforming to a specific video codec. Concurrently, a separate logic block within the FPGA calculates real-time scene statistics to derive HDR image metadata (e.g., instantaneous MaxCLL/MaxFALL for dynamic metadata). The FPGA then sets and stores this metadata into hdrm boxes, which are dynamically inserted into traf boxes of a fragmented MP4 file generated on-the-fly. This FPGA-centric approach ensures extremely low latency and deterministic timing for live HDR production workflows.

graph LR
    A[HDR Sensor Input] --> B[FPGA Data Processing Unit];
    B --> C[OETF Conversion Logic];
    B --> D[HDR Image Data Codec Logic];
    B --> E[Real-time Metadata Calculation Logic];
    E --> F[Generate Dynamic HDRM Metadata];
    D & F --> G[MP4 Fragmenter & HDRM Inserter Logic];
    G --> H[Output Fragmented HDR MP4 File];

---

2.3. Operational Parameter Expansion: Ultra-Low Bitrate HDR-MP4 for Remote Sensing

Enabling Description: An information processing device generates ultra-low bitrate MP4 files containing HDR image data for remote sensing applications (e.g., unmanned aerial vehicles, satellite imagery). The data processing unit is optimized for extreme compression while preserving critical HDR information. It acquires high-resolution HDR sensor data and generates HDR image metadata, focusing on statistical anomalies or specific features within the scene (e.g., precise luminance ranges of geological formations, spectral reflectance for vegetation health). This metadata is stored in hdrm boxes within trak or traf boxes, but it may also include spatially-aware metadata or compressed representations of 3D LUTs. The generated MP4 file leverages advanced coding tools (e.g., HEVC Main 10 profile with custom quantization matrices) and potentially a specialized hdrm box structure for efficient storage of sparse or highly compressed HDR metadata, critical for transmission over limited-bandwidth satellite links.

flowchart TD
    A[Remote Sensor Data (HDR)] --> B[Data Processing Unit];
    B --> C[Feature Extraction & Metadata Generation];
    C --> D[Generate Ultra-Low Bitrate HDRM Metadata];
    D --> E[HDR Image Compression (Advanced Codec)];
    E & F[MP4 Packaging (Set & Store HDRM Box)] --> G[Output Ultra-Low Bitrate HDR MP4];

---

2.4. Operational Parameter Expansion: Archival 16K HDR Content Generation

Enabling Description: An information processing device generates archival-grade 16K HDR content in the MP4 format. The data processing unit, comprising a high-performance computing cluster, acquires source HDR image data (e.g., rendered CGI, scanned film) at 16K resolution and 16-bit color depth. It generates comprehensive HDR image metadata, meticulously calculated across the entire content duration to capture the highest fidelity luminance, color, and perceptual quantization characteristics. This detailed metadata is stored in hdrm boxes, potentially with extensions to accommodate multi-layer or volumetric HDR information, within a trak box for static, overarching content descriptors. For extremely long-form content, fragment-specific hdrm boxes in traf boxes might store detailed metadata for specific scenes or sequences, ensuring future-proof reproduction on advanced display technologies and supporting granular content analysis.

graph TD
    A[16K HDR Source Content] --> B[HPC Data Processing Cluster];
    B --> C[Detailed HDR Metadata Generation];
    C --> D[Comprehensive HDRM Metadata (Static + Dynamic)];
    D --> E[16K HDR Video Encoding (e.g., VVC)];
    E & F[MP4 Archival Packaging (Set & Store HDRM Boxes)] --> G[Output Archival 16K HDR MP4];

---

2.5. Cross-Domain Application: Scientific Simulation Data Visualization

Enabling Description: An information processing device serves as a scientific data visualization engine, generating MP4 files that store HDR representations of complex simulation data (e.g., astrophysics, fluid dynamics, climate models). The data processing unit acquires raw simulation output (e.g., scalar fields, vector fields, volumetric data) and converts it into a visually interpretable HDR image data stream. It then generates HDR image metadata reflecting the scientific properties being visualized, such as intensity mappings to physical quantities, statistical distribution of data values, and uncertainty visualization parameters. This specialized HDR metadata is encapsulated in hdrm boxes, placed in trak boxes for global simulation parameters or traf boxes for time-varying data segments. This allows researchers using a reproduction device to view the simulation results with an optimized dynamic range and color mapping that accurately conveys the scientific information, rather than just aesthetic appeal.

flowchart TD
    A[Scientific Simulation Data] --> B[Data Processing Unit];
    B --> C[HDR Visualization Pipeline];
    C --> D[Generate Scientific HDRM Metadata];
    D --> E[HDR Image Encoding];
    E & F[MP4 Packaging (Set & Store HDRM Box)] --> G[Output Scientific HDR MP4];

---

2.6. Cross-Domain Application: Automated Surveillance & Forensics

Enabling Description: An automated surveillance system acts as an information processing device, generating MP4 files containing HDR image data captured by advanced surveillance cameras. The data processing unit continuously acquires video from multiple camera feeds, which inherently possess a high dynamic range (e.g., to capture detail in both brightly lit and shadowed areas). It generates HDR image metadata including scene change detection, object classification confidence scores, and specific event markers (e.g., motion events, facial recognition). This metadata is stored in hdrm boxes within traf boxes, time-synchronized with relevant video fragments. For forensic analysis by a reproduction device, this metadata, alongside conventional HDR display parameters, enables investigators to rapidly identify critical events and adjust the display of specific HDR regions to reveal subtle details that might otherwise be overlooked in a standard SDR view.

graph TD
    A[Surveillance Camera (HDR)] --> B[Data Processing Unit (On-board/Edge)];
    B --> C[Real-time Scene Analysis & Metadata Generation];
    C --> D[Generate Surveillance HDRM Metadata];
    D --> E[HDR Video Encoding];
    E & F[MP4 Packaging (Set & Store HDRM in traf)] --> G[Output Surveillance HDR MP4 File];

---

2.7. Integration with Emerging Tech: AI-Optimized Metadata Generation

Enabling Description: An information processing device for HDR content creation incorporates a data processing unit with an integrated AI-driven metadata generation engine. This engine utilizes a convolutional neural network (CNN) or transformer model trained to analyze the semantic content and aesthetic characteristics of raw HDR image data (e.g., identifying faces, landscapes, low-light scenes, high-contrast elements). Based on this analysis, the AI automatically generates contextually relevant HDR image metadata beyond basic MaxCLL/MaxFALL, such as perceptual brightness weighting, scene complexity scores, and optimal artistic intent flags. This AI-generated metadata is stored in a structured hdrm box, potentially with custom fields for AI-derived insights, improving subsequent reproduction on diverse displays by providing more intelligent hints for tone mapping and color rendition.

flowchart TD
    A[Raw HDR Image Data Input] --> B[Data Processing Unit];
    B --> C[AI Metadata Generation Engine (CNN/Transformer)];
    C --> D[Generate Contextual HDRM Metadata];
    D --> E[HDR Video Encoding];
    E & F[MP4 Packaging (Set & Store HDRM Box with AI Hints)] --> G[Output AI-Enhanced HDR MP4];

---

2.8. Integration with Emerging Tech: Blockchain for Content Provenance

Enabling Description: An information processing device generates an MP4 file storing HDR image data, with its data processing unit integrating a blockchain module for secure content provenance. After generating or acquiring HDR image metadata (including MaxCLL, MDCL, and potentially a content identifier hash), this metadata is stored in an hdrm box within the MP4 file. Concurrently, a cryptographic hash of the entire MP4 file (including the HDR image data and hdrm metadata) is generated and committed to a public or private blockchain along with a timestamp and originator identity. A unique transaction ID and/or Merkle root of the blockchain record is then embedded within a dedicated field in the hdrm box. This enables reproduction devices or forensic tools to verify the authenticity and integrity of the HDR content and its metadata by querying the blockchain, ensuring that the hdrm information has not been tampered with since creation.

sequenceDiagram
    participant Content_Creator
    participant Data_Processing_Unit
    participant MP4_File_Storage
    participant Blockchain_Network

    Content_Creator->>Data_Processing_Unit: Input Raw HDR Data
    Data_Processing_Unit->>Data_Processing_Unit: Generate/Acquire HDRM Metadata
    Data_Processing_Unit->>Data_Processing_Unit: Encode HDR Image Data
    Data_Processing_Unit->>Data_Processing_Unit: Set HDRM Box in MP4
    Data_Processing_Unit->>MP4_File_Storage: Store HDR MP4 File
    Data_Processing_Unit->>Data_Processing_Unit: Compute MP4 File Hash
    Data_Processing_Unit->>Blockchain_Network: Commit Hash & Metadata to Blockchain
    Blockchain_Network->>Data_Processing_Unit: Return Blockchain Tx ID
    Data_Processing_Unit->>Data_Processing_Unit: Embed Tx ID in HDRM Box
    Data_Processing_Unit->>MP4_File_Storage: Update HDR MP4 File

---

2.9. The "Inverse" or Failure Mode: Graceful Degradation Metadata Generation

Enabling Description: An information processing device is designed for graceful degradation in HDR MP4 file generation. Its data processing unit attempts to generate comprehensive HDR image metadata. However, if source data is incomplete, corrupted, or processing resources are insufficient (e.g., in a mobile device with low battery), the system defaults to generating a minimal, but valid, hdrm box. This minimal hdrm box might only contain a default EOTF (e.g., PQ) and estimated MaxCLL/MaxFALL values derived from global image statistics or a fallback SDR conversion setting. The hdrm box may also include a "degradation flag" or "confidence score" indicating the metadata's reliability. This ensures that even under suboptimal conditions, a valid MP4 file with some HDR metadata is generated, allowing reproduction devices to at least attempt a basic HDR display or intelligently fall back to SDR, rather than failing to produce a playable file at all.

graph TD
    A[Raw HDR Data Input] --> B[Data Processing Unit];
    B --> C{Resource Check / Data Integrity};
    C -- Insufficient/Corrupt --> D[Generate Minimal HDRM Metadata (Fallback)];
    C -- Sufficient --> E[Generate Comprehensive HDRM Metadata];
    D --> F[Set HDRM Box (with degradation flag)];
    E --> F;
    F --> G[Encode HDR Image Data];
    G --> H[MP4 Packaging];
    H --> I[Output HDR MP4 File];

---

2.10. The "Inverse" or Failure Mode: Metadata-Only MP4 Generation for Pre-analysis

Enabling Description: An information processing device, specialized for content pipeline pre-analysis, generates MP4 files that are "metadata-only" or "metadata-rich placeholders." The data processing unit acquires HDR image data (or references to it) and primarily focuses on generating extensive HDR image metadata, including detailed frame-by-frame luminance maps, color volume statistics, and scene-change markers. This metadata is stored in hdrm boxes within trak or traf boxes, but the actual mdat box may contain greatly downsampled, low-resolution versions of the HDR images, or even null data. The generated MP4 file serves as a lightweight descriptor for the full HDR content, enabling rapid analysis by a reproduction device to assess HDR characteristics, determine display compatibility, or prepare tone mapping parameters without needing to process the entire high-resolution video stream.

stateDiagram
    state "Data Processing Unit" as DPU {
        [*] --> Acquire_HDR_References
        Acquire_HDR_References --> Analyze_HDR_Characteristics
        Analyze_HDR_Characteristics --> Generate_Extensive_HDRM
        Generate_Extensive_HDRM --> Set_HDRM_Box
        Set_HDRM_Box --> Create_Placeholder_MP4
        Create_Placeholder_MP4 --> Output_Metadata_Only_MP4
        Output_Metadata_Only_MP4 --> [*]
    }

---

Derivatives for Independent Claim 9 (Information Recording Medium)

Claim 9: An information recording medium that records an MP4 file that stores data according to an MP4 format, the information recording medium including: an mdat box that stores high dynamic range (HDR) image data; and an HDR image metadata storage box that stores HDR image metadata as metadata corresponding to the HDR image, as recorded data, information recording medium enabling a reproduction device, which reads and reproduces HDR image data from the MP4 file, to determine whether executing a conversion process of an image on the basis of the HDR image metadata read from the HDR image metadata storage box.

---

3.1. Material & Component Substitution: Multi-Layer Optical Disc with HDR-MP4

Enabling Description: An information recording medium is a multi-layer optical disc (e.g., an advanced Blu-ray format or similar high-capacity optical storage). The physical layers of the disc are optimized for robust storage of large MP4 files. The mdat boxes, which store the HDR image data, are interleaved across multiple physical layers to enhance data integrity and read performance. The hdrm metadata storage boxes, containing metadata like MaxCLL, MaxFALL, and mastering display color primaries, are redundantly stored in dedicated, high-read-priority sectors of the disc, potentially replicated on different layers or within lead-in/lead-out areas. This redundancy ensures that even if parts of the disc are corrupted, the critical HDR metadata remains accessible, allowing a reproduction device to always determine the appropriate conversion process for the HDR image data read from the optical disc.

graph TD
    A[Multi-Layer Optical Disc] --> B[Layer 1];
    A --> C[Layer 2];
    A --> D[Layer N];
    B --> E[Interleaved mdat Box 1];
    C --> F[Interleaved mdat Box 2];
    D --> G[Interleaved mdat Box N];
    H[Redundant HDRM Box (Replicated)] --> B;
    H --> C;
    H --> D;
    E & F & G & H --> I[MP4 File Structure];

---

3.2. Material & Component Substitution: Phase-Change Memory (PCM) for Dynamic Metadata

Enabling Description: An information recording medium employs Phase-Change Memory (PCM) technology, which offers fast read/write speeds and high endurance, particularly for frequently updated data. This medium stores an MP4 file where the mdat box contains HDR image data, and the hdrm metadata storage box is located within traf boxes. The PCM's characteristics are particularly suited for storing dynamic HDR image metadata (e.g., scene-by-scene MaxCLL/MaxFALL) which may be updated or modified during content creation or even post-production. The fast access times of PCM allow a reproduction device to rapidly read and process dynamically changing hdrm metadata from traf boxes as fragmented HDR image data is accessed, enabling seamless real-time adaptation of the image conversion process without introducing latency from slower storage media.

flowchart TD
    A[PCM Recording Medium] --> B[MP4 File];
    B --> C[mdat Box (HDR Image Data)];
    B --> D[moof Box (Metadata for Fragmented Data)];
    D --> E[traf Box (Fragment Metadata)];
    E --> F[HDRM Box (Dynamic HDR Metadata)];
    F -- Fast Read/Write --> Reproduction_Device[Reproduction Device];
    Reproduction_Device -- Determines Conversion --> G[Display Output];

---

3.3. Operational Parameter Expansion: Distributed Global CDN for Archival HDR

Enabling Description: An information recording medium, conceptualized as a distributed global Content Delivery Network (CDN), stores MP4 files containing petabytes of archival HDR image data. Each MP4 file includes mdat boxes with HDR content and hdrm metadata storage boxes, primarily in trak boxes for global content parameters, replicated across geographically diverse data centers. The CDN architecture ensures high availability and low latency access to the MP4 files. When a reproduction device requests an HDR image, the nearest CDN node provides the MP4 file. The hdrm metadata is globally synchronized and cached, allowing the reproduction device to quickly acquire it and determine the necessary conversion process, even if the primary content mdat box is fetched from a different or more distant storage location, thereby optimizing global content delivery and display adaptation.

graph TD
    A[Global CDN (Information Recording Medium)] --> B[Data Center 1];
    A --> C[Data Center 2];
    A --> D[Data Center N];
    B --> E[MP4 File (Replicated)];
    C --> F[MP4 File (Replicated)];
    D --> G[MP4 File (Replicated)];
    E & F & G --> H[mdat Box (HDR Data)];
    E & F & G --> I[HDRM Box (Global Metadata in trak)];
    I -- Cached & Synchronized --> J[Reproduction Device];
    J -- Reads MP4, HDRM --> K[Determines Conversion];

---

3.4. Operational Parameter Expansion: Edge Device Caching for Real-time IoT Video

Enabling Description: An information recording medium manifests as local solid-state storage (e.g., industrial-grade SSDs) within edge computing devices (e.g., smart cameras, IoT gateways). These devices record fragmented MP4 files containing real-time HDR image data from embedded sensors. Crucially, the hdrm metadata storage boxes are placed within the traf boxes of these fragmented MP4 files, allowing for very granular, time-synchronous metadata for each short video fragment. This setup enables a reproduction device (either locally on the edge device or a connected client) to rapidly access the HDR image data and its dynamic hdrm metadata from the fast local cache. This immediate access facilitates real-time determination and execution of conversion processes for live video feeds, ensuring low-latency adaptation for applications like autonomous navigation or predictive maintenance, even with fluctuating network connectivity to cloud resources.

flowchart TD
    A[IoT Camera (HDR Sensor)] --> B[Edge Device (Information Recording Medium)];
    B --> C[Local SSD Storage];
    C --> D[Fragmented MP4 File (mdat + traf/hdrm)];
    D -- Fast Local Access --> E[Reproduction Device (Local/Remote)];
    E --> F[Reads HDR Image Data];
    E --> G[Acquires Dynamic HDRM Metadata (traf)];
    F & G --> H[Determines Real-time Conversion];
    H --> I[Output to Display];

---

3.5. Cross-Domain Application: Automotive Black Box Recorder

Enabling Description: An information recording medium within an automotive black box recorder (e.g., event data recorder or dashcam) stores MP4 files containing HDR image data captured from vehicle-mounted cameras. The mdat boxes store the HDR video, which is critical for capturing detail in challenging lighting conditions (e.g., tunnels, glare). The hdrm metadata storage box is set in the MP4 file's trak or traf boxes and includes not only display-related HDR parameters but also sensor data relevant to driving conditions (e.g., GPS coordinates, vehicle speed, accelerometer data, ambient light levels). This enables a forensic reproduction device to review accident footage, using the embedded hdrm metadata (both display and sensor data) to determine optimal image conversion for analysis, potentially enhancing details in under-exposed areas or mapping sensor data to visual cues to aid accident reconstruction.

graph TD
    A[Vehicle Cameras (HDR)] --> B[Automotive Black Box (Information Recording Medium)];
    B --> C[MP4 File (HDR Video + Sensor Data)];
    C --> D[mdat Box (HDR Image Data)];
    C --> E[HDRM Box (Display HDR Metadata + Sensor Data)];
    E --> F[Forensic Reproduction Device];
    F --> G[Reads HDR Video & HDRM];
    G --> H[Determines Conversion (Forensic Analysis)];
    H --> I[Output for Review];

---

3.6. Cross-Domain Application: Digital Archival for Cultural Heritage

Enabling Description: An information recording medium for cultural heritage digital archiving consists of robust, long-term storage (e.g., M-DISC optical media, specialized tape archives). This medium records MP4 files containing HDR image data derived from high-fidelity scans of historical artifacts, artworks, or documents. The mdat boxes store the HDR image data, preserving the nuanced tonal and color information of the originals. The hdrm metadata storage box, residing in a trak box, contains not only standard HDR display parameters but also extensive provenance data, photographic capture conditions (e.g., light source spectra, camera calibration), and restoration history. This rich hdrm metadata enables future reproduction devices, across generations of display technology, to accurately perform image conversion processes that faithfully reproduce the original appearance of the artifacts, ensuring the integrity and interpretability of the cultural heritage data over centuries.

flowchart TD
    A[Cultural Artifact Scan (HDR)] --> B[Digital Archive (Information Recording Medium)];
    B --> C[Long-Term Storage Media];
    C --> D[MP4 File (HDR Image + Archival Metadata)];
    D --> E[mdat Box (High-Fidelity HDR Image Data)];
    D --> F[HDRM Box (Display + Provenance + Capture Metadata in trak)];
    F --> G[Future Reproduction Device];
    G --> H[Reads HDR Video & Archival HDRM];
    H --> I[Determines Faithful Conversion];
    I --> J[Output for Heritage Display];

---

3.7. Integration with Emerging Tech: Decentralized Storage with Blockchain Authentication

Enabling Description: An information recording medium is a decentralized storage network (e.g., IPFS, Filecoin) that hosts MP4 files containing HDR image data. The mdat boxes contain the content, and the hdrm metadata storage box, with its critical display and content integrity information (e.g., cryptographic hashes of content segments), is included within trak or traf boxes. Each hdrm box also contains a blockchain-generated identifier or a digital signature. When a reproduction device retrieves an MP4 file from this decentralized network, it first accesses the hdrm metadata. The device then leverages a blockchain oracle or a peer-to-peer authentication mechanism to verify the integrity and authenticity of the hdrm metadata against an immutable public ledger. This ensures that the HDR image metadata has not been tampered with and is trustworthy for determining and executing the appropriate image conversion process, preventing malicious content modification or incorrect display rendering.

sequenceDiagram
    participant HDR_MP4_Uploader
    participant Decentralized_Storage_Network
    participant Blockchain_Ledger
    participant Reproduction_Device

    HDR_MP4_Uploader->>Decentralized_Storage_Network: Store MP4 File (mdat + traf/hdrm)
    HDR_MP4_Uploader->>Blockchain_Ledger: Register HDRM Hash/Signature
    Reproduction_Device->>Decentralized_Storage_Network: Request MP4 File
    Decentralized_Storage_Network->>Reproduction_Device: Provide MP4 (with HDRM)
    Reproduction_Device->>Reproduction_Device: Extract HDRM Metadata
    Reproduction_Device->>Blockchain_Ledger: Verify HDRM Hash/Signature
    alt Verification Success
        Reproduction_Device->>Reproduction_Device: Determine Conversion Process
        Reproduction_Device->>Reproduction_Device: Execute Output
    else Verification Failed
        Reproduction_Device->>Reproduction_Device: Flag as Tampered / Fallback
    end

---

3.8. Integration with Emerging Tech: AI-Indexed Smart Storage for Content Discovery

Enabling Description: An information recording medium is a smart storage system that dynamically indexes MP4 files based on their embedded HDR image metadata and AI-derived content features. Beyond simple file system indexing, the hdrm metadata (e.g., MaxCLL, scene brightness statistics, color gamut) from trak or traf boxes is actively parsed by an AI indexing engine. This engine generates semantic tags and content summaries that are stored alongside the MP4 file. When a reproduction device searches for HDR content, it can query the smart storage using natural language or high-level attributes (e.g., "show me high-contrast outdoor HDR footage"). The system uses the AI-indexed hdrm metadata to efficiently locate relevant MP4 files. This enables the reproduction device to quickly find the desired HDR image data, read its hdrm metadata, and determine the optimal display conversion process, significantly enhancing content discovery in large archives.

graph TD
    A[HDR MP4 Files (mdat + traf/hdrm)] --> B[Smart Storage System (Information Recording Medium)];
    B --> C[HDRM Metadata Parser];
    B --> D[AI Indexing Engine];
    C & D --> E[Semantic Content Index (e.g., scene type, contrast)];
    E --> F[Content Discovery Interface];
    F --> G[Reproduction Device];
    G -- Query --> F;
    F --> G -- Returns MP4 Reference --> G;
    G -- Reads HDRM --> H[Determines Conversion];

---

3.9. The "Inverse" or Failure Mode: Metadata Redundancy for Disaster Recovery

Enabling Description: An information recording medium, designed for disaster recovery and long-term data preservation, stores MP4 files containing HDR image data with enhanced hdrm metadata redundancy. The hdrm metadata storage box, located in a trak box, is not only stored in its primary location but is also duplicated in an "HDRM Recovery Box" (a custom box type) located in the MP4 file's udta (User Data) box or as an external sidecar file linked by the MP4. This redundancy ensures that if the primary trak box or its internal hdrm box becomes corrupted due to media degradation or accidental modification, a reproduction device can attempt to recover the critical HDR metadata from the redundant copy. This mechanism allows the device to still determine and execute a suitable conversion process for the HDR image data, even when faced with partial file corruption, enhancing the robustness and longevity of the content.

graph TD
    A[MP4 File (Information Recording Medium)] --> B[moov Box];
    B --> C[trak Box];
    C --> D[HDRM Box (Primary)];
    B --> E[udta Box];
    E --> F[HDRM Recovery Box (Redundant Copy)];
    C --> G[Other Track Metadata];
    A --> H[mdat Box (HDR Image Data)];
    D & F --> I[Reproduction Device (Metadata Recovery Logic)];
    I --> J[Determines Conversion];

---

3.10. The "Inverse" or Failure Mode: Lossy HDRM Storage for Bandwidth/Storage Optimization

Enabling Description: An information recording medium, particularly constrained by storage capacity or bandwidth (e.g., small embedded systems, low-bandwidth satellite links), stores MP4 files with lossy HDR image metadata. Instead of full-precision hdrm metadata, the hdrm metadata storage box (within trak or traf boxes) contains a compressed or quantized representation of the HDR parameters. For example, the Mastering Display Color Volume information might be represented with fewer bits or generalized profiles, and MaxCLL/MaxFALL values might be rounded to predefined tiers. This lossy metadata is generated by the generation device to minimize storage footprint. A reproduction device, upon reading this lossy hdrm metadata, performs an approximate determination of the conversion process, leveraging lookup tables or interpolation based on the quantized values. While sacrificing some precision, this enables HDR functionality in extremely resource-constrained environments where full-fidelity metadata would be prohibitive.

flowchart TD
    A[HDR Content Source] --> B[Data Processing Unit (Generation Device)];
    B --> C[Generate Full HDRM Metadata];
    C --> D[Lossy Compression / Quantization of HDRM];
    D --> E[Store Lossy HDRM in MP4 (trak/traf)];
    E --> F[Information Recording Medium];
    F --> G[Reproduction Device];
    G --> H[Read Lossy HDRM];
    H --> I[Approximate Conversion Determination];
    I --> J[Output to Display];