Standardized API for DASH Event Subscription and Interactivity

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current technologies lack standardized Application Programming Interfaces (APIs) between Dynamic Adaptive Streaming over HTTP (DASH) aware applications and DASH clients for subscribing to and delivering DASH events, timed web asset tracks, and interactivity usage logging, which hinders personalized and interactive service capabilities in broadcast and streaming services.

Innovation Solution

Defining a set of APIs between DASH Aware Applications (DAA) and DASH clients for subscription, notification, and interactivity usage reporting, including APIs for registering applications, subscribing to event streams, delivering event messages, and forwarding interactivity usage logs.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If standardized APIs are defined between DASH aware applications and DASH clients for subscription and delivery of DASH events and timed web asset tracks, then service interactivity and user engagement are improved, but device complexity and system integration requirements increase

Engineering Contradiction:
Improveservice interactivityVSAvoidsystem integration
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces a standardized API interface as an intermediary layer between DASH aware applications and DASH clients. This API acts as a mediator that enables subscription to DASH events and timed web asset tracks without requiring direct complex integration between the application and client components, thus improving service interactivity while managing system complexity through a well-defined interface contract

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The standardized API provides universal functionality for multiple operations including subscription, notification, and delivery of various DASH-related data types (events, timed web asset tracks, usage logs). This multi-functional interface allows different applications to interact with the DASH client in a consistent manner, enhancing adaptability while avoiding redundant integration code

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Loss of information

If APIs are implemented for interactivity usage logging and data forwarding, then user engagement tracking and personalized service capabilities are improved, but loss of time in data processing and transmission increases

Engineering Contradiction:
Improveusage data trackingVSAvoiddata processing time
Core Design Contradiction:
Loss of informationVSLoss of time

Solution Approach 1:

The API enables preliminary configuration of usage logging parameters and data forwarding destinations before actual usage occurs. Applications can pre-register interest in specific DASH events and timed web asset tracks, so that when events occur, the system already has the necessary subscription information ready to process and forward data immediately, reducing processing delays

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The standardized API establishes feedback mechanisms where the DASH client can notify DASH aware applications about event occurrences and delivery status. This feedback loop allows the system to track usage patterns efficiently and adjust data collection in real-time, improving information tracking while minimizing time delays through asynchronous notification mechanisms

Inventive Principle:
Principle #23Feedback

Data Source

PatentEP3707908B1Interfaces between dash aware application and dash client for service interactivity support
Publication Date: 2023.03.08 QUALCOMM INC
  • EP3707908B1 patent drawingFigure 1
  • EP3707908B1 patent drawingFigure 2
  • EP3707908B1 patent drawingFigure 3

AI summary

In one example, a device includes one or more processors implemented in circuitry and configured to execute a Dynamic Adaptive Streaming over HTTP (DASH) aware application (DAA) and a DASH client, and one or more user interfaces. The DAA subscribes to DASH events of a DASH event stream via a first application programming interface (API) between the DAA and a DASH client executed by the one or more processors. The DAA then receives data for one or more DASH events of the DASH event stream from the DASH client via a second API between the DAA and the DASH client, the data for the one or more DASH events specifying interactivity-related content. The DAA then presents the interactivity-related content via the one or more user interfaces. The DAA may further send usage measurements on usage of the interactivity-related content to the DASH client, for reporting to a report server device.