DRM Header Translation for Multi-System Decryption

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current digital-rights management (DRM) systems, such as those using the Common Encryption (CENC) scheme, face challenges in playing encrypted videos when a client device only supports one DRM system but receives PSSH headers for multiple systems, leading to incomplete decryption information and playback issues.

Innovation Solution

A video player generates additional information on-the-fly to create a Widevine header, including a KeyID and ContentID, to enable decryption even if not all content protection information is readily available, allowing it to translate assets from HSS/PR to DASH/WV (CENC) and perform additional verification checks, thereby accessing encrypted content.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Device complexity

If a client device supports only one DRM system (e.g., Widevine) but receives PSSH headers for multiple DRM systems, then the device can maintain simple DRM support architecture, but it cannot decrypt assets encrypted with other DRM systems (e.g., PlayReady)

Engineering Contradiction:
ImproveDRM system support architectureVSAvoidDRM system compatibility
Core Design Contradiction:
Device complexityVSAdaptability or versatility

Solution Approach 1:

The patent introduces an intermediary translation layer that converts PSSH headers from one DRM system format (e.g., PlayReady) into another DRM system format (e.g., Widevine). This mediator enables the client device to work with multiple DRM systems without actually supporting multiple DRM decoders, thus resolving the contradiction between maintaining simple architecture and achieving broad compatibility.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If a video player includes all necessary PSSH headers for multiple DRM systems in the asset, then the asset can be decrypted by any DRM system, but the asset file size and complexity increase

Engineering Contradiction:
ImproveDRM system compatibilityVSAvoidAsset file size
Core Design Contradiction:
Adaptability or versatilityVSQuantity of substance

Solution Approach 1:

The patent extracts only the essential decryption information (KeyID and ContentID) from the original PSSH header and uses it to generate a translated PSSH header for a different DRM system. This extraction approach avoids including redundant or unnecessary data in the translated header, thus reducing the overall asset file size while maintaining compatibility across DRM systems.

Inventive Principle:
Principle #2Taking out (Extraction)

3Ease of operation

If a license request includes only standard PSSH header information, then the license server can process requests according to standard protocols, but additional verification checks cannot be performed

Engineering Contradiction:
ImproveLicense request processingVSAvoidAuthentication verification
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent performs preliminary actions by generating additional verification information (such as device identifiers or authentication tokens) and embedding them in the translated PSSH header before the license request is sent to the server. This allows the license server to perform additional verification checks without requiring changes to the standard license request protocol, thus improving reliability while maintaining ease of operation.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS10506288B2DRM addition authentication
Publication Date: 2019.12.10 PRJ HLDG CO LLC
  • US10506288B2 patent drawing
  • US10506288B2 patent drawing
  • US10506288B2 patent drawing

AI summary

There is provided a client device comprising a content protection decoder according to a first standard, comprising: a receiver for receiving an asset associated with content protection; a creation module for creating a content protection for the asset in accordance with the first standard, and including a parameter identifying information additional to the information associated with said standard; an interface for transmitting a request for a license to a license server based on said standard, the request including that parameter, and for receiving a license in response; and a controller for accessing content associated with the asset using the license. There is also provided a license server configured to: receive a license key request in accordance with a standard from a client device; transmit the request to a processing function associated with the standard; receive a parameter associated with the standard from the processing function; parse the parameter to retrieve additional information; process the additional information; access a license in accordance with the standard based on the parsed information; and transmit the accessed license in accordance with the standard to the client device.