JP2017517167A - メディアデータをストリーミングするためのターゲット広告挿入 - Google Patents

メディアデータをストリーミングするためのターゲット広告挿入 Download PDF

Info

Publication number
JP2017517167A
JP2017517167A JP2016558191A JP2016558191A JP2017517167A JP 2017517167 A JP2017517167 A JP 2017517167A JP 2016558191 A JP2016558191 A JP 2016558191A JP 2016558191 A JP2016558191 A JP 2016558191A JP 2017517167 A JP2017517167 A JP 2017517167A
Authority
JP
Japan
Prior art keywords
data
client
dash
xlink
mbms
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2016558191A
Other languages
English (en)
Other versions
JP6612249B2 (ja
JP2017517167A5 (ja
Inventor
チャールズ・ヌン・ロー
トーマス・ストックハンマー
ゴードン・ケント・ウォーカー
ジュン・ワン
ナガラジュ・ナイク
カルロス・マルセロ・ディアス・パゾス
Original Assignee
クアルコム，インコーポレイテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by クアルコム，インコーポレイテッド filed Critical クアルコム，インコーポレイテッド
Publication of JP2017517167A publication Critical patent/JP2017517167A/ja
Publication of JP2017517167A5 publication Critical patent/JP2017517167A5/ja
Application granted granted Critical
Publication of JP6612249B2 publication Critical patent/JP6612249B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25866—Management of end-user data
    • H04N21/25883—Management of end-user data being end-user demographical data, e.g. age, family status or address
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0241—Advertisements
    • G06Q30/0251—Targeted advertisements
    • G06Q30/0269—Targeted advertisements based on user profile or attribute
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/765—Media network packet handling intermediate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25866—Management of end-user data
    • H04N21/25891—Management of end-user data being end-user preferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/4508—Management of client data or end-user data
    • H04N21/4524—Management of client data or end-user data involving the geographical location of the client
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/4508—Management of client data or end-user data
    • H04N21/4532—Management of client data or end-user data involving end-user characteristics, e.g. viewer profile, preferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/812—Monomedia components thereof involving advertisement data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Accounting & Taxation (AREA)
  • Marketing (AREA)
  • Computer Graphics (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Physics & Mathematics (AREA)
  • Game Theory and Decision Science (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

一例では、メディアデータを取り出す方法は、クライアントデバイスのマルチメディアブロードキャストマルチキャストサービス(MBMS)クライアントによって、1つまたは複数の広告グループの広告メディアデータを受信するステップと、クライアントデバイスの動的適応ストリーミングオーバーHTTP(DASH)クライアントから広告グループのうちの1つに関する識別子値を受信するステップと、識別子値に対応する広告グループの広告メディアデータを抽出するステップと、抽出した広告メディアデータをDASHクライアントに提供するステップとを含む。

Description

本出願は、各々の内容全体が参照によって本明細書に組み込まれている、2014年3月24日に出願した米国仮出願第61/969,707号、および2014年3月31日に出願した米国仮出願第61/973,063号の利益を主張するものである。
本開示は、メディアデータのトランスポート、たとえば、ブロードキャストトランスポートサービスを使用したメディアデータのストリーミングに関する。
デジタルビデオ機能は、デジタルテレビ、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップコンピュータまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラー電話または衛星無線電話、ビデオ会議デバイスなどを含む、幅広いデバイスに組み込まれ得る。デジタルビデオデバイスは、MPEG-2、MPEG-4、ITU-T H.263またはITU-T H.264/MPEG-4、Part 10、Advanced Video Coding(AVC)によって定義される規格、およびそのような規格の拡張に記載されるようなビデオ圧縮技法を実装して、デジタルビデオ情報をより効率的に送信および受信する。
ビデオ圧縮技法は、空間的予測および/または時間的予測を実行し、ビデオシーケンスに固有の冗長性を低減または除去する。ブロックベースのビデオコーディングの場合、ビデオフレームまたはスライスがマクロブロックに区分され得る。各マクロブロックはさらに区分され得る。イントラ符号化(I)フレームまたはスライスにおけるマクロブロックは、近接マクロブロックに関する空間的予測を使用して符号化される。インター符号化(PまたはB)フレームまたはスライスにおけるマクロブロックは、同じフレームまたはスライスにおける近接マクロブロックに関する空間的予測または他の参照フレームに関する時間的予測を使用し得る。
ビデオデータ(および/または、オーディオおよび/または時限テキストデータなど、他のメディアデータ)が符号化された後、メディアデータは送信または記憶のためにパケット化され得る。パケット化されたメディアデータは、ハイパーテキストトランスファープロトコル(HTTP)などのユニキャストプロトコル、または拡張マルチメディアブロードキャストマルチキャストサービス(eMBMS)などのブロードキャストプロトコルまたはマルチキャストプロトコルを使用して送られることが可能である。
Overview of 3GPP Release 12 V0.1.1、2013年12月 Enhanced MBMS Operation、3GPP TR 26.848 v. 12.0.0(2014年12月) MBMS Protocols and Codecs、3GPP TS 26.346 v. 12.4.0(2014年12月) 3rd Generation Partnership Project、Technical Specification Group Services and System Aspects、Multimedia Broadcast/Multicast Service(MBMS)、Protocols and Codecs(Release 12)、V12.0.0、2013年12月 R. Fielding他、RFC 2616、「Hypertext Transfer Protocol - HTTP/1.1」、Network Working Group、IETF、1999年6月 T. Paila他、「FLUTE-File Delivery over Unidirectional Transport」、Network Working Group、RFC 6726、2012年11月
概して、本開示は、メディアデータにターゲット広告を挿入することに関する技法について説明する。具体的には、メディアアプリケーションは、ユーザ詳細および/またはユーザデータ(たとえば、ユーザプリファレンスの選択)を動的適応ストリーミングオーバーHTTP(dynamic adaptive streaming over HTTP)(DASH)クライアントなど、ストリーミングクライアントに提供することができる。ストリーミングクライアントは、対応するデータをブロードキャストミドルウェアユニットまたはマルチキャストミドルウェアユニットに提供することができる。ミドルウェアユニットは、1つまたは複数の広告グループをブロードキャストサーバまたはマルチキャストサーバから受信し、次いで、ストリーミングクライアントからのデータに基づいて、広告グループのうちの1つを選択することができる。代替として、たとえば、広告グループに関する識別子に対応する置換属性を含むリンクをアクティブ化する(すなわち、デリファレンスする)とき、その識別子をその属性に関する値としてそのリンクに挿入することによって、ストリーミングクライアントは、広告グループのうちの1つに関する識別子をミドルウェアユニットに提供することができる。
一例では、動的適応ストリーミングオーバーHTTP(DASH)クライアントによって、メディアデータを取り出す方法は、複数の広告グループの広告メディアデータと関連付けられた広告グループ識別子のセットを決定するステップであって、広告メディアデータがメインメディアコンテンツに関する広告ブレークの間に再生され、メインメディアコンテンツがマニフェストファイルと関連付けられる、決定するステップと、マニフェストファイルに対する更新を取り出すステップであって、更新が広告メディアデータに対応するリモートPeriodを定義し、マニフェストファイルに対する更新が識別子属性を含む拡張マークアップ言語(XML)リンク付け言語(XLink)ユニフォームリソースロケータ(URL)に関するテンプレートを指定する、取り出すステップと、DASHクライアントに関するユーザの特性に少なくとも部分的に基づいて、広告グループのうちの1つをセットから選択するステップと、テンプレートに従って、選択された広告グループに対応する識別子値をXLink URLの識別子属性に割り当てるステップと、選択された広告グループの広告メディアデータをリモートPeriodから取り出すために、選択された広告グループに対応する識別子値を含むXLink URLをデリファレンスするステップと、広告メディアデータをメディアアプリケーションに提供するステップとを含む。
別の例では、クライアントデバイスのマルチメディアブロードキャストマルチキャストサービス(MBMS)クライアントによって、メディアデータを取り出す方法は、1つまたは複数の広告グループの広告メディアデータを受信するステップと、クライアントデバイスの動的適応ストリーミングオーバーHTTP(DASH)クライアントから広告グループのうちの1つに関する識別子値を含む拡張マークアップ言語(XML)リンク付け言語(Xlink)ユニフォームリソースロケータ(URL)を受信するステップと、識別子値に対応する広告グループの広告メディアデータを抽出するステップと、抽出した広告メディアデータをDASHクライアントに提供するステップとを含む。
別の例では、コンピュータ可読記憶媒体は、実行されると、クライアントデバイスのプロセッサに、複数の広告グループの広告メディアデータと関連付けられた広告グループ識別子のセットを決定することであって、広告メディアデータがメインメディアコンテンツに関する広告ブレークの間に再生され、メインメディアコンテンツがマニフェストファイルと関連付けられる、決定することと、マニフェストファイルに対する更新を取り出すことであって、更新が広告メディアデータに対応するリモートPeriodを定義し、マニフェストファイルに対する更新が識別子属性を含む拡張マークアップ言語(XML)リンク付け言語(XLink)ユニフォームリソースロケータ(URL)に関するテンプレートを指定する、取り出すことと、クライアントデバイスのユーザの特性に少なくとも部分的に基づいて、広告グループのうちの1つをセットから選択することと、テンプレートに従って、選択された広告グループに対応する識別子値をXLink URLの識別子属性に割り当てることと、選択された広告グループの広告メディアデータをリモートPeriodから取り出すために、選択された広告グループに対応する識別子値を含むXLink URLをデリファレンスすることと、広告メディアデータをメディアアプリケーションに提供することと行わせる命令を記憶している。
別の例では、コンピュータ可読記憶媒体は、実行されると、クライアントデバイスのプロセッサに、1つまたは複数の広告グループの広告メディアデータを受信させ、クライアントデバイスの動的適応ストリーミングオーバーHTTP(DASH)クライアントから広告グループのうちの1つに関する識別子値を含む拡張マークアップ言語(XML)リンク付け言語(Xlink)ユニフォームリソースロケータ(URL)を受信させ、識別子値に対応する広告グループの広告メディアデータを抽出させ、抽出した広告メディアデータをDASHクライアントに提供させる命令を記憶している。
別の例では、クライアントデバイスのマルチメディアブロードキャストマルチキャストサービス(MBMS)クライアントによって、メディアデータを取り出す方法は、広告メディアデータに対応するリモートPeriodに関する識別子属性を含む拡張マークアップ言語(XML)リンク付け言語(XLink)ユニフォームリソースロケータ(URL)をクライアントデバイスの動的適応ストリーミングオーバーHTTP(DASH)クライアントから受信するステップと、ブロードキャストトランスポートまたはマルチキャストトランスポートを介して、リモートPeriodに関するデータ(たとえば、ファイル配信テーブル(FDT)、またはgroupIDFilterシンタックス要素を含むフィルタ記述フラグメント)を受信するステップと、ブロードキャストトランスポートまたはマルチキャストトランスポートのデータがXLink URLの識別子値と整合する識別子値を含むとき、リモートPeriodに関するデータがXLink URLと整合すると決定するステップと、リモートPeriodに関するデータがXLink URLと整合すると決定することに応答して、リモートPeriodに関するデータをDASHクライアントに配信するステップとを含む。
1つまたは複数の例の詳細が、以下の添付の図面および説明において述べられる。他の特徴、目的、および利点は、説明、図面、および特許請求の範囲から明らかになるであろう。
ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステムを示すブロック図である。 図1の取出しユニットの構成要素の例示的なセットをより詳細に示すブロック図である。 例示的なマルチディアコンテンツの要素を示す概念図である。 本開示の技法を実装し得る別の例示的なシステムを示すブロック図である。 本開示の技法を実装し得る別の例示的なシステムを示すブロック図である。 DASHクライアントが適切な広告コンテンツの受信を確実にする例示的な方法を示すシーケンス図である。 DASHクライアントが適切な広告コンテンツの受信を確実にする例示的な方法を示すシーケンス図である。 DASHクライアントが適切な広告コンテンツの受信を確実にする例示的な方法を示すシーケンス図である。 DASHクライアントが適切な広告コンテンツの受信を確実にする例示的な方法を示すシーケンス図である。 DASHクライアントが適切な広告コンテンツの受信を確実にする例示的な方法を示すシーケンス図である。 DASHクライアントが適切な広告コンテンツの受信を確実にする例示的な方法を示すシーケンス図である。 ロケーションフィルタデータを搬送するための、現在定義されている、例示的なフィルタ記述フラグメントを示す概念図である。 ユーザプリファレンス&プロファイル(UP/P)データを搬送するためのフィルタ記述フラグメントに対する拡張を示す概念図である。 本開示の技法による、MBMSクライアント支援型広告選択のための例示的な方法を示すシーケンス図である。 本開示の技法による、MBMSクライアント支援型広告選択のための例示的な方法を示すシーケンス図である。 本開示の技法による、リアルタイムトランスポートプロトコル(RTP)に関するMBMSクライアント支援型広告選択および挿入のための例示的な方法を示すシーケンス図である。 ファイル配信テーブル(FDT)ファイル要素に対する例示的な拡張を示す概念図である。 ファイル配信テーブル(FDT)ファイル要素に対する例示的な拡張を示す概念図である。 ファイル配信テーブル(FDT)ファイル要素に対する例示的な拡張を示す概念図である。 ファイル配信テーブル(FDT)ファイル要素に対する例示的な拡張を示す概念図である。 本開示の技法を実行し得る別の例示的なシステム300を示すブロック図である。 本開示の技法による例示的な方法を示すシーケンス図である。 本開示の技法による例示的な方法を示すシーケンス図である。
概して、本開示は、ターゲット広告(広告)挿入のための技法について説明する。これらの技法は、たとえば、ユニキャストサービス、ブロードキャストサービス、または拡張マルチメディアブロードキャストマルチキャストサービス(eMBMS)などのマルチキャストサービスに従って、メディアデータをストリーミングするときに使用され得る。たとえば、本開示の技法は、MBMS改善拡張MBMS動作(MI-EMO:MBMS Improvements-Enhanced MBMS Operation)の技法とともに、またはその技法を強化するために使用され得る。MI-EMOは、たとえば、http://www.3gpp.org/ftp/Information/WORK_PLAN/Description_Releases/Rel-12_description_20131224.zip.において入手可能な、Overview of 3GPP Release 12 V0.1.1、2013年12月に記載されている。これらの技法はまた、www.3gpp.org/ftp/Specs/archive/26_series/26.848/26848-c00.zipにおいて入手可能なEnhanced MBMS Operation、3GPP TR 26.848 v. 12.0.0(2014年12月)、および/またはwww.3gpp.org/ftp/Specs/archive/26_series/26.346/26346-c40.zipにおいて入手可能なMBMS Protocols and Codecs、3GPP TS 26.346 v. 12.4.0(2014年12月)に記載されている拡張MBMS*(eMBMS)において使用され得る。
本開示の技法は、MI-EMOの以下の例示的な使用事例に従って使用され得る。人口の多い都市の2つの主要サッカーチームが、週末にかけて互いとダービーマッチを行う予定である。ゲームはファンの間に多くの関心を生み出すことが予想されるため、オペレータはMBMSを介してその加入者にサービスを提供することを計画している。オペレータは、各サッカークラブのファン店舗からの商品を販売促進すること、クラブ関連ニュースを共有することなどに向けて、すなわち、ゲーム休憩の間に再生されるように、ターゲット広告の別個のセットをクラブファンに配信することを計画する。
本開示の技法は、MBMSおよびeMBMSにおけるターゲット広告挿入をサポートし得る。本開示の技法は、メインコンテンツおよび広告をブロードキャストし、ダウンロードクライアント要素(たとえば、ソフトウェア要素、ハードウェア要素、またはハードウェアとソフトウェアの組合せ)のサポートによるターゲット広告の挿入を可能にするために使用され得る。ライブイベント(すなわち、キャプチャ、符号化、およびパケット化の後に可能な限り迅速にストリーミングされるライブキャプチャされたメディアコンテンツ)の場合、本開示の技法は、広告がメインコンテンツ内にリアルタイムで挿入され得るように、ターゲット広告の配信をスケジュールすることを可能にし得る。本開示の技法はまた、MBMSクライアントが、ユーザ特徴に従って、MBMSを介して配信される広告を選択的に受信することを可能にし得る。そのようなユーザ特徴は、たとえば、クライアントデバイス内に記憶されたユーザプリファレンス/プロファイルデータリポジトリ内に記憶された情報に対応し得る。
本開示の技法は、以下の制限の準備が整ったときに適用され得る。MBMSを介したターゲット広告コンテンツ配信は、同じ一時的モバイルグループ識別情報(TMGI:Temporary Mobile Group Identity)に関して同じファイル配信オーバー単方向トランスポート(FLUTE:File Delivery over Unidirectional Transport)セッションを介してすべての広告関連リソースを送ることによってのみ可能であり得る。その場合、広告コンテンツを特定のユーザ特徴によって識別された特定のグループと関連付けることができない可能性があるため、TS 26.346のsection 7.2に定義されるような無差別な(promiscuous)手法を用いて受信を行うことが可能である。TS 26.346は、http://www.3gpp.org/DynaReport/26234.htmで入手可能な、3rd Generation Partnership Project、Technical Specification Group Services and System Aspects、Multimedia Broadcast/Multicast Service(MBMS)、Protocols and Codecs(Release 12)、V12.0.0、2013年12月に記述されている。同様に、本開示の技法は、以下の追加のまたは代替の制約の準備が整ったときに使用され得る。MBMSクライアントが、(fileURI、または潜在的に他のパターンによって識別された)1つまたは複数の特定のファイルの複写を受信するようにFLUTEに命令するためのワンコピー(one-copy)動作を可能にするために、ユーザ特徴に従って、MBMSを通して配信された広告コンテンツを選択的に受信することを可能にすることができない場合がある。本開示の技法は、MBMSを介したリアルタイムトランスポートプロトコル(RTP)ストリーミング配信のためのターゲット広告挿入を提供するためにも適用され得る。
概して、本開示は、ターゲット広告挿入をサポートするための3つの例示的な技法について説明する。第1の例示的な技法は、アプリケーションベースの広告選択を対象とする。第2の例示的な技法は、たとえば、動的適応ストリーミングオーバーHTTP(DASH)クライアントを含めて、サーバベースの広告選択を対象とする。第3の例示的な技法では、MBMSクライアントは広告選択を支援する。これらの例示的な技法、ならびにこれらの仕様、組合せ、および部分組合せの追加の詳細について下でより詳細に説明する。
いくつかの例では、ブロードキャストまたはマルチキャストを使用してメディアコンテンツを受信するとき、MBMSクライアントまたはeMBMSクライアントは、メディアコンテンツを受信し、次いで、そのメディアコンテンツをDASHクライアントなどのストリーミングクライアントに利用可能にすることができる。DASHクライアントは、たとえば、HTTP取出し動作を使用して、MBMSクライアントからメディアコンテンツを取り出すことができる。DASHなどのHTTPストリーミングにおいて、頻繁に使用される動作には、HEAD、GETおよび部分GETがある。HEAD動作は、URLまたはURNと関連付けられたペイロードを取り出さずに、所与のユニフォームリソースロケータ(URL)またはユニフォームリソースネーム(URN)と関連付けられたファイルのヘッダを取り出す。GET動作は、所与のURLまたはURNと関連付けられたファイル全体を取り出す。部分GET動作は、入力パラメータとしてバイト範囲を受信し、ファイルの連続した数のバイトを取り出し、この場合、バイトの数は受信されるバイト範囲に対応する。したがって、部分GET動作は1つまたは複数の個々の動画フラグメントを取得できるので、動画フラグメントはHTTPストリーミングのために提供され得る。動画フラグメントにおいて、異なるトラックのいくつかのトラックフラグメントが存在し得る。HTTPストリーミングでは、メディアプレゼンテーションは、クライアントにアクセス可能なデータの構造化された集合体であり得る。クライアントは、メディアデータ情報を要求およびダウンロードして、ユーザにストリーミングサービスを提示することができる。
HTTPストリーミングを使用して3GPPデータをストリーミングする例では、マルチメディアコンテンツのビデオおよび/またはオーディオデータに関して複数のリプレゼンテーションが存在し得る。以下で説明するように、異なるリプレゼンテーションは、異なるコーディング特性(たとえば、ビデオコーディング規格の異なるプロファイルまたはレベル)、異なるコーディング規格またはコーディング規格の拡張(マルチビューおよび/またはスケーラブル拡張など)、または異なるビットレートに対応し得る。そのようなリプレゼンテーションのマニフェストは、メディアプレゼンテーション記述(MPD:Media Presentation Description)データ構造において定義され得る。メディアプレゼンテーションは、HTTPストリーミングクライアントデバイスにアクセス可能なデータの構造化された集合体に対応し得る。HTTPストリーミングクライアントデバイスは、メディアデータ情報を要求およびダウンロードして、クライアントデバイスのユーザにストリーミングサービスを提示することができる。メディアプレゼンテーションは、MPDの更新を含み得るMPDデータ構造で記述され得る。
メディアプレゼンテーションは、1つまたは複数のピリオドのシーケンスを包含し得る。ピリオドは、MPDにおいてPeriod要素によって定義され得る。各ピリオドは、MPDにおいて属性startを有し得る。MPDは、ピリオドごとにstart属性とavailableStartTime属性とを含み得る。ライブサービスの場合、ピリオドのstart属性とMPD属性availableStartTimeとの合計が、UTCフォーマットによるピリオドの利用可能時間、特に、対応するピリオドにおける各リプレゼンテーションの最初のメディアセグメントを指定し得る。オンデマンドサービスの場合、最初のピリオドのstart属性は0であり得る。任意の他のピリオドについては、start属性は、対応するPeriodの開始時間と最初のPeriodの開始時間との間の時間オフセットを指定し得る。各ピリオドは、次のPeriodの開始まで、または最後のピリオドの場合にはメディアプレゼンテーションの終了まで及び得る。Periodの開始時間は正確であり得る。Periodの開始時間は、すべての先行ピリオドのメディアの再生から生じる実際のタイミングを反映することができる。
各ピリオドは、同じメディアコンテンツのための1つまたは複数のリプレゼンテーションを包含し得る。リプレゼンテーションは、オーディオデータまたはビデオデータの、多数の符号化バージョンの選択肢の1つであってもよい。リプレゼンテーションは、符号化のタイプ、たとえば、ビデオデータのビットレート、解像度、および/またはコーデック、ならびにオーディオデータのビットレート、言語、および/またはコーデックによって異なり得る。リプレゼンテーションという用語は、ある特定の方法で符号化された、マルチメディアコンテンツのある特定のピリオドに対応する符号化オーディオデータまたは符号化ビデオデータのあるセクションを指すために使用され得る。
ある特定のピリオドのリプレゼンテーションは、リプレゼンテーションが属する適応セットを示すMPD内の属性によって示されるグループに割り当てられ得る。同じ適応セット内のリプレゼンテーションは、一般に、クライアントデバイスが、たとえば帯域幅に適応するためにこれらのリプレゼンテーションの間で動的かつシームレスに切り替わることができる点で、互いに対する代替物と見なされる。たとえば、ある特定のピリオドのビデオデータの各リプレゼンテーションは、同じ適応セットに割り当てられ得るので、リプレゼンテーションのうちのいずれもが、対応するピリオドのマルチメディアコンテンツの、ビデオデータまたはオーディオデータなど、メディアデータを提示するように復号するために選択され得る。いくつかの例では、1つのピリオド内のメディアコンテンツは、存在する場合にはグループ0からの1つのリプレゼンテーション、または各々の非ゼロのグループからの最大でも1つのリプレゼンテーションの組合せのいずれかによって表され得る。あるピリオドの各リプレゼンテーションのタイミングデータは、ピリオドの開始時間に対して表され得る。
リプレゼンテーションは1つまたは複数のセグメントを含み得る。各リプレゼンテーションは、初期化セグメントを含んでもよく、またはリプレゼンテーションの各セグメントは、自己初期化するものであってもよい。初期化セグメントは、存在する場合、リプレゼンテーションにアクセスするための初期化情報を包含し得る。一般に、初期化セグメントは、メディアデータを包含しない。セグメントは、ユニフォームリソースロケータ(URL)、ユニフォームリソースネーム(URN)、またはユニフォームリソース識別子(URI)のような、識別子によって一意に参照され得る。MPDは、セグメントごとに識別子を提供することができる。いくつかの例では、MPDはまた、URL、URN、またはURIによってアクセス可能なファイル内のセグメントのためのデータに対応し得る、range属性の形式で、バイト範囲を提供することができる。
異なるタイプのメディアデータに関して実質的に同時に取り出すために異なるリプレゼンテーションを選択することができる。たとえば、クライアントデバイスは、そこからセグメントを取り出すオーディオリプレゼンテーション、ビデオリプレゼンテーション、および時限のテキストリプレゼンテーションを選択することができる。いくつかの例では、クライアントデバイスは、帯域幅に適応するために特定の適応セットを選択することができる。すなわち、クライアントデバイスは、ビデオリプレゼンテーションを含む適応セット、オーディオリプレゼンテーションを含む適応セット、および/または時限のテキストを含む適応セットを選択することができる。代替として、クライアントデバイスは、あるタイプのメディア(たとえば、ビデオ)に関する適応セットを選択し、他のタイプのメディア(たとえば、オーディオおよび/または時限のテキスト)に関するリプレゼンテーションを直接選択することができる。
図1は、ネットワークを介してメディアデータをストリーミングするための技法を実施する例示的なシステム10を示すブロック図である。この例では、システム10は、コンテンツ準備デバイス20と、サーバデバイス60と、クライアントデバイス40とを含む。クライアントデバイス40およびサーバデバイス60は、インターネットを含み得るネットワーク74によって通信可能に結合される。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60も、ネットワーク74または別のネットワークによって結合されてもよく、または直接通信可能に結合されてもよい。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60は、同じデバイスを含み得る。
図1の例では、コンテンツ準備デバイス20は、オーディオソース22とビデオソース24とを含む。オーディオソース22は、たとえば、オーディオエンコーダ26によって符号化されるべきキャプチャされたオーディオデータを表す電気信号を生成するマイクロフォンを含んでもよい。あるいは、オーディオソース22は、以前に記録されたオーディオデータを記憶する記憶媒体、コンピュータ化されたシンセサイザのようなオーディオデータ生成器、またはオーディオデータの任意の他のソースを含んでもよい。ビデオソース24は、ビデオエンコーダ28によって符号化されるべきビデオデータを生成するビデオカメラ、以前に記録されたビデオデータで符号化された記憶媒体、コンピュータグラフィックスソースのようなビデオデータ生成ユニット、またはビデオデータの任意の他のソースを含んでもよい。コンテンツ準備デバイス20は必ずしも、すべての例において、サーバデバイス60に通信可能に結合されるとは限らないが、サーバデバイス60によって読み取られる別個の媒体にマルチメディアコンテンツを記憶する場合がある。
生のオーディオデータおよびビデオデータは、アナログデータまたはデジタルデータを含んでもよい。アナログデータは、オーディオエンコーダ26および/またはビデオエンコーダ28によって符号化される前にデジタル化されてもよい。オーディオソース22は、話している参加者から、その参加者が話している間にオーディオデータを取得する場合があり、ビデオソース24は、話している参加者のビデオデータを同時に取得する場合がある。他の例では、オーディオソース22は、記憶されたオーディオデータを含むコンピュータ可読記憶媒体を含んでもよく、ビデオソース24は、記憶されたビデオデータを含むコンピュータ可読記憶媒体を含んでもよい。このようにして、本開示で説明する技法は、ライブの、ストリーミングの、リアルタイムのオーディオデータおよびビデオデータに、または保管された、以前に記録されたオーディオデータおよびビデオデータに、適用されてもよい。
ビデオフレームに対応するオーディオフレームは一般に、ビデオフレーム内に包含されたビデオソース24によってキャプチャ(または、生成)されたビデオデータと同時に、オーディオソース22によってキャプチャ(または、生成)されたオーディオデータを包含するオーディオフレームである。たとえば、話している参加者が一般に話すことによってオーディオデータを生成している間、オーディオソース22はオーディオデータをキャプチャし、ビデオソース24は同時に、すなわち、オーディオソース22がオーディオデータをキャプチャしている間に、話している参加者のビデオデータをキャプチャする。したがって、オーディオフレームは、1つまたは複数の特定のビデオフレームに時間的に対応し得る。したがって、ビデオフレームに対応するオーディオフレームは一般に、オーディオデータおよびビデオデータが同時にキャプチャされた状況に対応し、その状況に対して、オーディオフレームおよびビデオフレームがそれぞれ、同時にキャプチャされたオーディオデータおよびビデオデータを含む。
いくつかの例では、オーディオエンコーダ26は、各符号化オーディオフレームにおいて、符号化オーディオフレームのオーディオデータが記録された時間を表すタイムスタンプを符号化することができ、同様に、ビデオエンコーダ28は、各符号化ビデオフレームにおいて、符号化ビデオフレームのビデオデータが記録された時間を表すタイムスタンプを符号化することができる。そのような例では、ビデオフレームに対応するオーディオフレームは、タイムスタンプを含むオーディオフレームと同じタイムスタンプを含むビデオフレームとを含み得る。コンテンツ準備デバイス20は、オーディオエンコーダ26および/またはビデオエンコーダ28がタイムスタンプを生成し得るようにする、またはオーディオソース22およびビデオソース24がそれぞれオーディオデータおよびビデオデータをタイムスタンプと関連付けるために使用し得る内部クロックを含み得る。
いくつかの例では、オーディオソース22は、オーディオデータが記録された時間に対応するデータをオーディオエンコーダ26に送ることができ、ビデオソース24は、ビデオデータが記録された時間に対応するデータをビデオエンコーダ28に送ることができる。いくつかの例では、オーディオエンコーダ26は、符号化オーディオデータにおいて、符号化オーディオデータの相対的な時間順序を示すために、オーディオデータが記録された絶対的な時間を必ずしも示すとは限らないが、シーケンス識別子を符号化することができ、同様に、ビデオエンコーダ28も、符号化ビデオデータの相対的な時間順序を示すためにシーケンス識別子を使用することができる。同様に、いくつかの例では、シーケンス識別子がタイムスタンプとともにマップされるか、あるいはタイムスタンプと相関することがある。
オーディオエンコーダ26は一般に、符号化オーディオデータのストリームを生成する一方、ビデオエンコーダ28は、符号化ビデオデータのストリームを生成する。データの個別の各ストリーム(オーディオかビデオかにかかわらず)は、エレメンタリストリームと呼ばれることがある。エレメンタリストリームは、リプレゼンテーションの、単一のデジタル的に符号化された(場合によっては、圧縮された)構成要素である。たとえば、リプレゼンテーションの符号化されたビデオまたはオーディオの部分は、エレメンタリストリームであり得る。エレメンタリストリームは、ビデオファイル内にカプセル化される前に、パケット化されたエレメンタリストリーム(PES:packetized elementary stream)に変換され得る。同じリプレゼンテーション内で、ストリームIDが、あるエレメンタリストリームに属するPESパケットを他のエレメンタリストリームに属するPESパケットと区別するために使用され得る。エレメンタリストリームのデータの基本単位は、パケット化されたエレメンタリストリーム(PES)パケットである。したがって、符号化ビデオデータは一般に、エレメンタリビデオストリームに対応する。同様に、オーディオデータは、1つまたは複数のそれぞれのエレメンタリストリームに対応する。
ITU-T H.264/AVCおよび今度の高効率ビデオコーディング(HEVC)規格など、多くのビデオコーディング規格は、エラーのないビットストリームのためのシンタックス、意味論、および復号プロセスを定義し、それらのいずれもが、一定のプロファイルまたはレベルに準拠する。ビデオコーディング規格は、一般的にエンコーダを規定しないが、エンコーダは、生成されたビットストリームがデコーダのための規格に準拠することを保証する役割を課される。ビデオコーディング規格の文脈では、「プロファイル」は、アルゴリズム、機能、またはツールのサブセット、およびこれらに適用される制約に相当する。H.264規格によって定義されるように、たとえば、「プロファイル」は、H.264規格によって規定される全体のビットストリームシンタックスのサブセットである。「レベル」は、たとえば、デコーダメモリおよび計算のような、デコーダのリソース消費の制限に相当し、これは、ピクチャの解像度、ビットレート、およびブロック処理速度に関連する。プロファイルは、profile_idc(プロファイルインジケータ)値によってシグナリングされ得るが、レベルは、level_idc(レベルインジケータ)値によってシグナリングされ得る。
たとえば、所与のプロファイルのシンタックスによって課される範囲内で、復号されるピクチャの規定されたサイズのようなビットストリーム内のシンタックス要素のとる値に応じて、エンコーダおよびデコーダの性能に大きい変動を要求することが依然として可能であることを、H.264規格は認める。多くの用途において、特定のプロファイル内のシンタックスのすべての仮想的な使用を扱うことが可能なデコーダを実装するのは、現実的でも経済的でもないことを、H.264規格はさらに認める。したがって、H.264規格は、ビットストリーム内のシンタックス要素の値に課される制約の規定されたセットとして、「レベル」を定義する。これらの制約は、値に対する単純な制限であってもよい。あるいは、これらの制約は、値の算術的な組合せの制約の形式(たとえば、1秒当たりに復号されるピクチャの数と、ピクチャの高さと、ピクチャの幅との積)をとってもよい。個々の実装形態が、サポートされるプロファイルごとに異なるレベルをサポートしてもよいことを、H.264規格はさらに規定する。
プロファイルに準拠するデコーダは普通、プロファイル内で定義されるすべての機能をサポートする。たとえば、コーディング機能として、Bピクチャコーディングは、H.264/AVCのベースラインプロファイルではサポートされないが、H.264/AVCの他のプロファイルではサポートされる。あるレベルに準拠するデコーダは、レベル内で定義された制限を超えるリソースを要求しない、あらゆるビットストリームを復号することが可能であるべきである。プロファイルおよびレベルの定義は、解釈力のために有用であり得る。たとえば、ビデオ送信の間、一対のプロファイルとレベルの定義が、送信セッション全体に対して取り決められ合意され得る。より具体的には、H.264/AVCにおいて、レベルは、処理される必要があるマクロブロックの数、復号ピクチャバッファ(DPB:decoded picture buffer)のサイズ、符号化ピクチャバッファ(CPB:coded picture buffer)のサイズ、垂直方向の運動ベクトルの範囲、2つの連続するMBあたりの運動ベクトルの最大の数に対する制限、および、Bブロックが8×8ピクセルよりも小さいサブマクロブロック区画を有し得るかどうかを定義することができる。このようにして、デコーダは、デコーダが適切にビットストリームを復号できるかどうかを決定することができる。
図1の例では、コンテンツ準備デバイス20のカプセル化ユニット30は、ビデオエンコーダ28からの符号化ビデオデータを含むエレメンタリストリームと、オーディオエンコーダ26からの符号化オーディオデータを含むエレメンタリストリームとを受信する。いくつかの例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化データからPESパケットを形成するためのパケッタイザを含み得る。他の例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化データからPESパケットを形成するためのそれぞれのパケッタイザとインターフェースをとる場合がある。さらに他の例では、カプセル化ユニット30は、符号化オーディオデータおよび符号化ビデオデータからPESパケットを形成するためのパケッタイザを含み得る。
ビデオエンコーダ28は、種々の方法でマルチメディアコンテンツのビデオデータを符号化して、ピクセル解像度、フレームレート、様々なコーディング規格に対する準拠、様々なコーディング規格のための様々なプロファイルおよび/もしくはプロファイルのレベルに対する準拠、1つまたは複数のビューを有するリプレゼンテーション(たとえば、2次元または3次元の再生用)、または他のそのような特性などの、様々な特性を有する様々なビットレートのマルチメディアコンテンツの様々なリプレゼンテーションを生成してもよい。本開示で使用される場合、リプレゼンテーションは、オーディオデータ、ビデオデータ、(たとえば、クローズドキャプション用の)テキストデータ、または他のそのようなデータのうちの1つを含み得る。このリプレゼンテーションは、オーディオエレメンタリストリームまたはビデオエレメンタリストリームなどのエレメンタリストリームを含み得る。各PESパケットは、PESパケットが属するエレメンタリストリームを特定するstream_idを含んでもよい。カプセル化ユニット30は、様々なリプレゼンテーションのビデオファイル(たとえば、セグメント)へとエレメンタリストリームを組み立てる役割を担う。
カプセル化ユニット30は、オーディオエンコーダ26およびビデオエンコーダ28からのリプレゼンテーションのエレメンタリストリームのためのPESパケットを受信し、PESパケットから対応するネットワーク抽象化レイヤ(NAL)ユニットを形成する。H.264/AVC(Advanced Video Coding)の例では、符号化ビデオセグメントはNALユニットへと編成され、NALユニットは、ビデオ電話、記憶、ブロードキャスト、またはストリーミングのような、「ネットワークフレンドリ」なビデオリプレゼンテーションのアドレッシング適用(addressing application)を実現する。NALユニットは、ビデオ符号化レイヤ(VCL)NALユニットおよび非VCL NALユニットに分類されてもよい。VCLユニットは、コア圧縮エンジンを包含し得、ブロック、マクロブロック、および/またはスライスレベルのデータを包含し得る。他のNALユニットは、非VCL NALユニットであってもよい。いくつかの例では、1つの時間インスタンスにおける符号化ピクチャは、通常はプライマリ符号化ピクチャとして提示され、1つまたは複数のNALユニットを含み得るアクセスユニットに包含され得る。
非VCL NALユニットは特に、パラメータセットのNALユニットおよびSEI NALユニットを含み得る。パラメータセットは、(シーケンスパラメータセット(SPS)内に)シーケンスレベルヘッダ情報を包含し、(ピクチャパラメータセット(PPS)内に)頻繁には変化しないピクチャレベルヘッダ情報を包含し得る。パラメータセット(たとえば、PPSおよびSPS)があれば、この頻繁には変化しない情報は、各シーケンスまたはピクチャに対して繰り返される必要がなく、したがって、コーディング効率が向上し得る。さらに、パラメータセットの使用が、重要なヘッダ情報の帯域外送信を可能にでき、エラーの復元のための冗長な送信の必要がなくなる。帯域外送信の例では、パラメータセットのNALユニットが、SEI NALユニットなどの他のNALユニットとは異なるチャネル上で送信され得る。
サプリメンタルエンハンスメント情報(SEI:Supplemental Enhancement Information)は、VCL NALユニットから符号化ピクチャサンプルを復号するために必要ではない情報を包含し得るが、復号、表示、エラーの復元、および他の目的に関係するプロセスを支援し得る。SEIメッセージは、非VCL NALユニットに包含され得る。SEIメッセージは、いくつかの標準仕様の規範的部分であり、したがって、規格に準拠するデコーダの実装において常に必須であるとは限らない。SEIメッセージは、シーケンスレベルSEIメッセージまたはピクチャレベルSEIメッセージであり得る。いくつかのシーケンスレベル情報は、SVCの例におけるスケーラビリティ情報SEIメッセージおよびMVCにおける表示スケーラビリティ情報SEIメッセージなどのSEIメッセージに包含され得る。これらの例示的なSEIメッセージは、たとえば動作点の抽出および動作点の特性に関する情報を伝達することができる。加えて、カプセル化ユニット30は、リプレゼンテーションの特性を記述するメディアプレゼンテーション記述(MPD)などのマニフェストファイルを形成することができる。カプセル化ユニット30は、拡張可能マークアップ言語(XML)に従ってMPDをフォーマットすることができる。
カプセル化ユニット30は、マニフェストファイル(たとえば、MPD)とともに、マルチメディアコンテンツの1つまたは複数のリプレゼンテーションのためのデータを出力インターフェース32に提供してもよい。出力インターフェース32は、ユニバーサルシリアルバス(USB)インターフェースのような記憶媒体へ書き込むためのネットワークインターフェースもしくはインターフェース、CDもしくはDVDのライターもしくはバーナー、磁気記憶媒体もしくはフラッシュ記憶媒体へのインターフェース、または、メディアデータを記憶もしくは送信するための他のインターフェースを含んでもよい。カプセル化ユニット30は、マルチメディアコンテンツのリプレゼンテーションの各々のデータを出力インターフェース32に提供することができ、出力インターフェース32は、ネットワーク送信または記憶媒体を介してデータをサーバデバイス60に送ることができる。図1の例では、サーバデバイス60は、各々がそれぞれのマニフェストファイル66と1つまたは複数のリプレゼンテーション68A〜68N(リプレゼンテーション68)とを含む様々なマルチメディアコンテンツ64を記憶する記憶媒体62を含む。いくつかの例では、出力インターフェース32はネットワーク74にデータを直接送ることもできる。
いくつかの例では、リプレゼンテーション68は、適応セットへと分割され得る。つまり、リプレゼンテーション68の様々なサブセットは、コーデック、プロファイルおよびレベル、解像度、ビューの数、セグメントのファイルフォーマット、たとえば話者による、復号され提示されるべきリプレゼンテーションおよび/またはオーディオデータとともに表示されるべきテキストの言語または他の特性を識別し得るテキストタイプ情報、カメラの角度または適応セット内のリプレゼンテーションのシーンの現実世界のカメラの視野を表し得るカメラ角度情報、特定の視聴者に対するコンテンツの適切性を表すレーティング情報のような、特性のそれぞれの共通のセットを含み得る。
マニフェストファイル66は、特定の適応セットに対応するリプレゼンテーション68のサブセットを示すデータ、さらには、適応セットの共通の特性を含んでもよい。マニフェストファイル66はまた、適応セットの個々のリプレゼンテーションのための、ビットレートのような個々の特性を表すデータを含んでもよい。このようにして、適応セットは、簡略化されたネットワーク帯域幅の適応を行ってもよい。適応セット内のリプレゼンテーションは、マニフェストファイル66の適応セット要素の子要素を使用して示されてもよい。
サーバデバイス60は、要求処理ユニット70とネットワークインターフェース72とを含む。いくつかの例では、サーバデバイス60は、複数のネットワークインターフェースを含み得る。さらに、サーバデバイス60の機能のうちのいずれかまたはすべてが、ルータ、ブリッジ、プロキシデバイス、スイッチ、または他のデバイスのような、コンテンツ配信ネットワークの他のデバイス上で実装され得る。いくつかの例では、コンテンツ配信ネットワークの中間デバイスは、マルチメディアコンテンツ64のデータをキャッシュし、サーバデバイス60の構成要素に実質的に準拠する構成要素を含み得る。一般に、ネットワークインターフェース72は、ネットワーク74を介してデータを送るように、また受信するように構成される。
要求処理ユニット70は、記憶媒体62のデータに対するネットワーク要求をクライアントデバイス40のようなクライアントデバイスから受信するように構成される。たとえば、要求処理ユニット70は、R. Fielding他による、RFC 2616、「Hypertext Transfer Protocol-HTTP/1.1」、Network Working Group、IETF、1999年6月に記述されるような、ハイパーテキスト転送プロトコル(HTTP)バージョン1.1を実装する場合がある。すなわち、要求処理ユニット70は、HTTP GET要求または部分GET要求を受信して、それらの要求に応答して、マルチメディアコンテンツ64のデータを提供するように構成されてもよい。要求は、たとえば、セグメントのURLを使用して、リプレゼンテーション68のうちの1つのセグメントを指定してもよい。いくつかの例では、要求はまた、セグメントの1つまたは複数のバイト範囲を指定することができ、したがって、部分GET要求を含む。要求処理ユニット70はさらに、リプレゼンテーション68のうちの1つのセグメントのヘッダデータを提供するために、HTTP HEAD要求に対応するように構成されてもよい。いずれの場合でも、要求処理ユニット70は、要求されたデータをクライアントデバイス40のような要求側デバイスに提供するために、要求を処理するように構成されてもよい。
追加または代替として、要求処理ユニット70は、ブロードキャストまたはeMBMSなどのマルチキャストプロトコルを介してメディアデータを配信するように構成され得る。コンテンツ準備デバイス20は、DASHセグメントおよび/またはサブセグメントを、説明したのと実質的に同じ方法で作成することができるが、サーバデバイス60は、これらのセグメントまたはサブセグメントをeMBMSまたは別のブロードキャストもしくはマルチキャストのネットワークトランスポートプロトコルを使用して配信することができる。たとえば、要求処理ユニット70は、クライアントデバイス40からマルチキャストグループ参加要求を受信するように構成され得る。すなわち、サーバデバイス60は、マルチキャストグループと関連付けられたインターネットプロトコル(IP)アドレスを、クライアントデバイス40を含む、特定のメディアコンテンツ(たとえば、ライブイベントのブロードキャスト)と関連付けられたクライアントデバイスに広告することができる。次にクライアントデバイス40は、マルチキャストグループに参加することを求める要求を提出することができる。この要求は、ネットワーク74、たとえば、ネットワーク74を構成するルータを通じて伝搬され、それによりルータに、マルチキャストグループと関連付けられたIPアドレス宛のトラフィックを、クライアントデバイス40などの加入側クライアントデバイスに向けさせることができる。
図1の例に示すように、マルチメディアコンテンツ64は、メディアプレゼンテーション記述(MPD)に対応し得るマニフェストファイル66を含む。マニフェストファイル66は、様々な代替のリプレゼンテーション68(たとえば、品質が異なるビデオサービス)の記述を包含してよく、この説明は、たとえば、コーデック情報、プロファイル値、レベル値、ビットレート、およびリプレゼンテーション68の他の説明のための特性を包含し得る。クライアントデバイス40は、メディアプレゼンテーションのMPDを取り出して、リプレゼンテーション68のセグメントにどのようにアクセスするかを決定してもよい。
特に、(本開示の技法を実装し得る)取出しユニット52は、クライアントデバイス40の構成データ(図示せず)を取り出して、ビデオデコーダ48の復号能力およびビデオ出力44のレンダリング能力を決定することができる。構成データはまた、クライアントデバイス40のユーザによって選択される言語の選好、クライアントデバイス40のユーザによって設定される深さの選好に対応する1つまたは複数のカメラ視野、および/または、クライアントデバイス40のユーザによって選択されるレーティングの選好のいずれかまたはすべてを含み得る。取出しユニット52は、たとえば、HTTP GET要求および部分GET要求を提出するように構成されたウェブブラウザまたはメディアクライアントを含み得る。取出しユニット52は、クライアントデバイス40の1つまたは複数のプロセッサまたは処理ユニット(図示せず)によって実行されるソフトウェア命令に対応し得る。いくつかの例では、取出しユニット52に関して説明した機能のすべてまたは一部は、ハードウェア、ハードウェアの組合せ、ソフトウェア、および/またはファームウェアで実装されてよく、この場合、必須のハードウェアは、ソフトウェアまたはファームウェアのための命令を実行するために提供され得る。
取出しユニット52は、クライアントデバイス40の復号能力およびレンダリング能力を、マニフェストファイル66の情報によって示されるリプレゼンテーション68の特性と比較することができる。取出しユニット52は、最初に、マニフェストファイル66の少なくとも一部分を取り出して、リプレゼンテーション68の特性を決定することができる。たとえば、取出しユニット52は、1つまたは複数の適応セットの特性を記述する、マニフェストファイル66の一部分を要求する場合がある。取出しユニット52は、クライアントデバイス40のコーディング能力およびレンダリング能力によって満たされ得る特性を有するリプレゼンテーション68のサブセット(たとえば、適応セット)を選択することができる。取出しユニット52は、次いで、適応セット内のリプレゼンテーションに対するビットレートを決定し、ネットワーク帯域幅の現在利用可能な量を決定し、ネットワーク帯域幅によって満たされ得るビットレートを有するリプレゼンテーションのうちの1つからセグメントを取り出すことができる。
概して、リプレゼンテーションのビットレートが高くなると、ビデオ再生の品質が高くなる一方、リプレゼンテーションのビットレートが低くなると、利用可能なネットワーク帯域幅が縮小したときに、ビデオ再生の品質が十分なものになる場合がある。したがって、利用可能なネットワーク帯域幅が比較的高いときには、取出しユニット52は、ビットレートが比較的高いリプレゼンテーションからデータを取り出すことができ、利用可能なネットワーク帯域幅が低いときには、取出しユニット52は、ビットレートが比較的低いリプレゼンテーションからデータを取り出すことができる。このようにして、クライアントデバイス40は、ネットワーク74を介してマルチメディアデータをストリーミングすることができる一方、ネットワーク74の変化するネットワーク帯域幅の利用可能性に適応することもできる。
追加または代替として、取出しユニット52は、ブロードキャスト、またはeMBMSまたはIPマルチキャストなどのマルチキャストネットワークプロトコルに従ってデータを受信するように構成され得る。そのような例では、取出しユニット52は、特定のメディアコンテンツと関連付けられたマルチキャストネットワークグループに参加することを求める要求を提出することができる。取出しユニット52は、マルチキャストグループに参加した後、サーバデバイス60またはコンテンツ準備デバイス20にさらなる要求を出すことなしに、マルチキャストグループのデータを受信することができる。取出しユニット52は、マルチキャストグループのデータが必要ではなくなったときにマルチキャストグループを離れること、たとえば、再生を中断すること、または異なるマルチキャストグループにチャネルを変えることを求める要求を提出することができる。
本開示の第1の例示的な技法(アプリケーションベースの広告選択)では、取出しユニット52(または、取出しユニット52の一部を形成し得る、DASHクライアントのクライアントアプリケーションなど、クライアントデバイス40の別の要素)は、DASHクライアントからのまたはMBMSサーバ層からの支援なしに、ターゲット広告選択を実行することができる。この例では、広告を選択するためのインテリジェンスは本明細書に存在するかまたは本明細書の任務であり、これは、3GPP TS 26.346(マルチメディアブロードキャスト/マルチキャストサービス(MBMS)、プロトコル、およびコーデック)など、適用可能な規格によって指定されない他のサービスイネーブラとの相互作業に関連し得る。この例は、たとえば、キャッシングおよび/またはクッキーを使用した異なるHTTPベースの配信技法を可能にし得る。この例では、MBMSサービス層は広告配信を単に提供することができる。DASHクライアントはアプリケーションによって命令されたMPDを単にフェッチすることができる。この例は、DASH-IF(DASH Industry Forum)によって考案された広告挿入フレームワークの後にモデル化され得る。この第1の例示的技法のさらなる詳細は、図4に関して下で説明する。
本開示の技法の第2の例示的なセット(DASHクライアントを含むサーバベースの広告選択)では、取出しユニット52は、ネットワーク74のデバイス(たとえば、サーバデバイス60、コンテンツ準備デバイス20、または図1に示さない別のデバイス)からの支援により、ターゲット広告選択を実行するDASHクライアントを含み得る。概して、ネットワーク74は、DASHイベント機構を採用して、広告決定に影響を及ぼすためのメタデータを包含する更新されたMPDをフェッチするように取出しユニット52のDASHクライアントをトリガするデバイスを含む。取出しユニット52のMBMSクライアントが、すべての広告をダウンロードできるか、または選択された広告だけをダウンロードできるかについて、公称モードと拡張モードの両方を採用することができる。この技法は、DASH-IFによって考案された広告挿入フレームワークの後にモデル化され得る。この第2の例による技法の様々な態様については、図5〜図8Bに関して説明する。
例のために、MPDを更新するためのDASHイベント機構が説明されてきたが、(更新されたMPDが、プログラム内への挿入/スプライスポイントの間にフェッチされることになる広告(広告)セグメントを記述するリモートPeriod要素を包含するとき)DASHイベント機構の使用は更新されたMPDの配信/獲得を可能にするために必須でないことを理解されたい。MPD更新に関してチェックし続けることによって、DASHクライアントが広告ブレークの動的発生を逃すことにならないように、(MPD@minimumUpdatePeriodによってシグナリングされる)周期的な予想されるMPD更新を十分に高い周波数でシグナリングすることによって等価の機能を提供することも可能である。そのような最小更新期間の使用の一例については、下で図15A〜図15Bの方法に関して説明する。
第3の例示的な技法(MBMSクライアントアシスト型広告選択)では、取出しユニット52のMBMSクライアントは、ユーザサービス記述(USD)内に包含されたメタデータの処理に基づいて、広告選択を実行する。広告選択インテリジェンスおよび制御は、この例では、取出しユニット52のMBMSクライアント内にだけ存在すると仮定してよい。MBMSクライアントは、ストリーミングプログラム配信に先立って、広告を選択的にダウンロードおよび事前キャッシュすることができる。この例は、アプリケーションサービスとしてDASHに制限されないコンテンツパーソナル化機構を表す。したがって、この第3の例示的な技法は、リアルタイムトランスポートプロトコル(RTP)ベースのストリーミングサービス配信に等しく適用可能であり得、それと共通の方法で動作し得る。この第3の例による技法の様々な態様については、図9〜図11Bに関して説明する。
ネットワークインターフェース54は、選択されたリプレゼンテーションのセグメントのデータを受信し、取出しユニット52に提供することができ、次に取出しユニット52は、セグメントをカプセル化解除ユニット50に提供することができる。カプセル化解除ユニット50は、ビデオファイルの要素を、構成要素であるPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化データを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化データがオーディオストリームの一部かビデオストリームの一部かに応じて、符号化データをオーディオデコーダ46またはビデオデコーダ48のいずれかに送ることができる。オーディオデコーダ46は、符号化オーディオデータを復号し、復号したオーディオデータをオーディオ出力42に送り、一方でビデオデコーダ48は、符号化ビデオデータを復号し、ストリームの複数のビューを含み得る復号したビデオデータをビデオ出力44に送る。
ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、取出しユニット52、およびカプセル化解除ユニット50は各々、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェア、またはこれらの任意の組合せのような、種々の適切な処理回路のいずれかとして、適宜実装され得る。ビデオエンコーダ28およびビデオデコーダ48の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてよく、これらのいずれもが、結合されたビデオエンコーダ/デコーダ(コーデック)の一部として統合され得る。同様に、オーディオエンコーダ26およびオーディオデコーダ46の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてよく、これらのいずれもが、結合されたコーデックの一部として統合され得る。ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、取出しユニット52、および/またはカプセル化解除ユニット50を含む装置は、集積回路、マイクロプロセッサ、および/またはセルラー電話のようなワイヤレス通信デバイスを含み得る。
クライアントデバイス40、サーバデバイス60、および/またはコンテンツ準備デバイス20は、本開示の技法に従って動作するように構成され得る。例として、本開示は、クライアントデバイス40およびサーバデバイス60に関するこれらの技法を説明する。しかしながら、コンテンツ準備デバイス20は、サーバデバイス60の代わりに(または、加えて)これらの技法を実行するように構成され得ることを理解されたい。
カプセル化ユニット30は、NALユニットが属するプログラム、ならびにペイロード、たとえばオーディオデータ、ビデオデータ、またはNALユニットが対応するトランスポートまたはプログラムストリームを記述するデータを特定するヘッダを含むNALユニットを形成することができる。たとえば、H.264/AVCにおいて、NALユニットは、1バイトのヘッダおよび可変サイズのペイロードを含む。そのペイロード内にビデオデータを含むNALユニットは、ビデオデータの様々な粒度レベルを含み得る。たとえば、NALユニットは、ビデオデータのブロック、複数のブロック、ビデオデータのスライス、またはビデオデータの全ピクチャを含み得る。カプセル化ユニット30は、ビデオエンコーダ28からの符号化ビデオデータをエレメンタリストリームのPESパケットの形で受信することができる。カプセル化ユニット30は、各エレメンタリストリームを対応するプログラムと関連付けることができる。
カプセル化ユニット30はまた、複数のNALユニットからアクセスユニットを組み立てることができる。一般に、アクセスユニットは、ビデオデータのフレーム、ならびにそのようなオーディオデータが利用可能であるときにそのフレームに対応するオーディオデータを表すために1つまたは複数のNALユニットを含むことができる。アクセスユニットは、一般に、1つの出力時間インスタンスに対するすべてのNALユニット、たとえば1つの時間インスタンスに対するすべてのオーディオデータおよびビデオデータを含む。たとえば、各ビューが20フレーム毎秒(fps)のフレームレートを有する場合、各時間インスタンスは、0.05秒の時間間隔に対応し得る。この時間間隔の間、同じアクセスユニット(同じ時間インスタンス)のすべてのビューに対する特定のフレームは、同時にレンダリングされ得る。一例では、アクセスユニットは、プライマリ符号化ピクチャとして提示され得る、1つの時間インスタンス内の符号化ピクチャを含み得る。
したがって、アクセスユニットは、共通の時間インスタンスのすべてのオーディオフレームおよびビデオフレーム、たとえば時間Xに対応するすべてのビューを含むことができる。本開示はまた、特定のビューの符号化ピクチャを「ビューコンポーネント(view component)」と呼ぶ。すなわち、ビューコンポーネントは、特定の時間における特定のビューに対する符号化ピクチャ(または、フレーム)を含み得る。したがって、アクセスユニットは、共通の時間インスタンスのすべてのビューコンポーネントを含むものとして定義され得る。アクセスユニットの復号順序は、必ずしも出力または表示の順序と同じである必要はない。
メディアプレゼンテーションは、異なる代替リプレゼンテーション(たとえば、異なる品質を有するビデオサービス)の記述を包含し得るメディアプレゼンテーション記述(MPD)を含むことができ、記述は、たとえば、コーデック情報、プロファイル値、およびレベル値を含み得る。MPDは、マニフェストファイル66など、マニフェストファイルの一例である。クライアントデバイス40は、メディアプレゼンテーションのMPDを取り出して、様々なプレゼンテーションの動画フラグメントにどのようにアクセスするかを決定することができる。動画フラグメントは、ビデオファイルの動画フラグメントボックス(ムーフボックス(moof box))内に配置され得る。
マニフェストファイル66(たとえば、MPDを含み得る)は、リプレゼンテーション68のセグメントの利用可能性を広告することができる。すなわち、MPDは、リプレゼンテーション68のうちの1つの第1のセグメントが利用可能になる壁時計時間を示す情報、ならびにリプレゼンテーション68内のセグメントの持続時間を示す情報を含み得る。このようにして、クライアントデバイス40の取出しユニット52は、開始時間ならびに特定のセグメントに先行するセグメントの持続時間に基づいて、各セグメントが利用可能になるときを決定することができる。
カプセル化ユニット30が、受信されたデータに基づいてNALユニットおよび/またはアクセスユニットをビデオファイルに組み立てた後、カプセル化ユニット30は、ビデオファイルを出力のために出力インターフェース32に渡す。いくつかの例では、カプセル化ユニット30は、ビデオファイルを直接クライアントデバイス40に送る代わりに、ビデオファイルをローカルに記憶するか、または出力インターフェース32を介してビデオファイルをリモートサーバに送ることができる。出力インターフェース32は、たとえば、送信機、トランシーバ、たとえばオプティカルドライブ、磁気媒体ドライブ(たとえば、フロッピードライブ)などのコンピュータ可読媒体にデータを書き込むためのデバイス、ユニバーサルシリアルバス(USB)ポート、ネットワークインターフェース、または他の出力インターフェースを含み得る。出力インターフェース32は、たとえば、送信信号、磁気媒体、光学媒体、メモリ、フラッシュドライブ、または他のコンピュータ可読媒体など、コンピュータ可読媒体34にビデオファイルを出力する。
ネットワークインターフェース54は、ネットワーク74を介してNALユニットまたはアクセスユニットを受信し、NALユニットまたはアクセスユニットを取出しユニット52を介してカプセル化解除ユニット50に提供する。カプセル化解除ユニット50は、ビデオファイルの要素を、構成要素であるPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化データを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化データがオーディオストリームの一部かビデオストリームの一部かに応じて、符号化データをオーディオデコーダ46またはビデオデコーダ48のいずれかに送ることができる。オーディオデコーダ46は、符号化オーディオデータを復号し、復号したオーディオデータをオーディオ出力42に送り、一方でビデオデコーダ48は、符号化ビデオデータを復号し、ストリームの複数のビューを含み得る復号したビデオデータをビデオ出力44に送る。
図2は、図1の取出しユニット52の構成要素の例示的なセットをより詳細に示すブロック図である。この例では、取出しユニット52は、eMBMSミドルウェアユニット100と、DASHクライアント110と、メディアアプリケーション112とを含む。
eMBMSミドルウェアユニット100は、eMBMS受信ユニット106と、キャッシュ104と、プロキシサーバ102とをさらに含む。この例では、eMBMS受信ユニット106は、たとえば、http://tools.ietf.org/html/rfc6726において入手可能な、T. Paila他、「FLUTE-File Delivery over Unidirectional Transport」、Network Working Group、RFC 6726、2012年11月に記述されたファイル配信オーバー単方向トランスポート(FLUTE)に従って、eMBMSを介してデータを受信するように構成される。すなわち、eMBMS受信ユニット106は、たとえば、BM-SCとして機能し得るサーバデバイス60からブロードキャストを介してファイルを受信することができる。
eMBMSミドルウェアユニット100がファイルに関するデータを受信すると、eMBMSミドルウェアユニットは受信したデータをキャッシュ104内に記憶することができる。キャッシュ104は、フラッシュメモリ、ハードディスク、RAM、または任意の他の適切な記憶媒体など、コンピュータ可読記憶媒体を含み得る。
プロキシサーバ102は、DASHクライアント110に関するプロキシサーバとして機能し得る。たとえば、プロキシサーバ102は、MPDファイルまたは他のマニフェストファイルをDASHクライアント110に提供することができる。プロキシサーバ102は、MPDファイル内、ならびにそこからセグメントを取り出すことができるハイパーリンク内のセグメントに関する利用可能性時間を広告することができる。これらのハイパーリンクは、クライアントデバイス40に対応するローカルホストアドレスプレフィックス(たとえば、IPv4に関する127.0.0.1)を含み得る。このようにして、DASHクライアント110は、HTTP GET要求または部分GET要求を使用して、プロキシサーバ102からセグメントを要求することができる。たとえば、リンクhttp://127.0.0.1/rep1/seg3から利用可能なセグメントに関して、DASHクライアント110は、http://127.0.0.1/rep1/seg3に関する要求を含むHTTP GET要求を構築し、その要求をプロキシサーバ102に提出することができる。プロキシサーバ102は、キャッシュ104から要求されたデータを取出し、その要求に応答して、そのデータをDASHクライアント110に提供することができる。
セグメントを受信した後、DASHクライアント110は、セグメントが完全に受信されようと、部分的に受信されようと、セグメントのデータをメディアアプリケーション112に渡すことができる。DASHクライアント110は、セグメントを処理して、たとえば、メディアデータをセグメントから抽出すること、および/またはメディアアプリケーション112によって使用可能でないデータを廃棄することができる。
下でより詳細に説明する、本開示の技法によれば、eMBMSミドルウェアユニット100は、1つまたは複数の広告グループを受信し、その広告グループのうちの1つに関するデータをDASHクライアント110に提供することができる。たとえば、DASHクライアント110は、広告グループのうちの1つを識別することができるか、またはeMBMSミドルウェアユニット100が広告グループのうちの1つを選択することができるように、ユーザに関するデータをeMBMSミドルウェアユニット100に提供することができる。
図3は、例示的なマルチメディアコンテンツ120の要素を示す概念図である。マルチメディアコンテンツ120は、マルチメディアコンテンツ64(図1)、または記憶媒体62に記憶された別のマルチメディアコンテンツに対応し得る。図3の例では、マルチメディアコンテンツ120は、メディアプレゼンテーション記述(MPD)124と複数のリプレゼンテーション130〜140とを含む。リプレゼンテーション130は、任意選択のヘッダデータ132およびセグメント134A〜134N(セグメント134)を含み、一方でリプレゼンテーション140は、任意選択のヘッダデータ142およびセグメント144A〜144N(セグメント144)を含む。文字Nが、便宜的に、リプレゼンテーション130、140の各々の最後の動画フラグメントを指定するために使用される。いくつかの例では、リプレゼンテーション130、140の間に、異なる数の動画フラグメントが存在し得る。
MPD124は、リプレゼンテーション130〜140とは別個のデータ構造を含み得る。MPD124は、図1のマニフェストファイル66に対応し得る。同様に、リプレゼンテーション130〜140は、図1のリプレゼンテーション68に対応し得る。一般に、MPD124は、コーディング特性およびレンダリング特性、適応セット、MPD124が対応するプロファイル、テキストタイプ情報、カメラ角度情報、レーティング情報、トリックモード情報(たとえば、時間的なサブシーケンスを含むリプレゼンテーションを示す情報)、および/またはリモートPeriodを検索するための情報(たとえば、再生中のメディアコンテンツへのターゲット広告の挿入)のような、リプレゼンテーション130〜140の特性を一般に表すデータを含み得る。
ヘッダデータ132は、存在する場合、セグメント134の特性、たとえば、ランダムアクセスポイント(RAP、ストリームアクセスポイント(SAP)とも呼ばれる)の時間ロケーション、セグメント134のいずれがランダムアクセスポイントを含むか、セグメント134内のランダムアクセスポイントに対するバイトオフセット、セグメント134のユニフォームリソースロケータ(URL)、またはセグメント134の他の側面を記述し得る。ヘッダデータ142は、存在する場合、セグメント144の同様の特性を表すことができる。追加または代替として、そのような特性はMPD124内に完全に含まれてもよい。
セグメント134、144は、1つまたは複数の符号化ビデオサンプルを含み、ビデオサンプルの各々が、ビデオデータのフレームまたはスライスを含み得る。セグメント134の符号化ビデオサンプルの各々は、同様の特性、たとえば、高さ、幅、および帯域幅の要件を有し得る。そのような特性は、MPD124のデータによって記述され得るが、そのようなデータは図3の例には示されていない。MPD124は、本開示で説明するシグナリングされた情報のいずれかまたはすべてが加えられた、3GPP仕様によって記述されるような特性を含み得る。
セグメント134、144の各々は、固有のユニフォームリソースロケータ(URL)に関連付けられ得る。したがって、セグメント134、144の各々は、DASHのようなストリーミングネットワークプロトコルを使用して、独立して取出し可能であり得る。このようにして、クライアントデバイス40のような宛先デバイスは、HTTP GET要求を使用して、セグメント134または124を取り出すことができる。いくつかの例では、クライアントデバイス40は、HTTP部分GET要求を使用して、セグメント134または124の特定のバイト範囲を取り出すことができる。
図4は、本開示の技法を実装し得る別の例示的なシステム150を示すブロック図である。図4のシステム150の要素は、概して、図1の要素に対応し得る。たとえば、システム150は、広告(広告)判定サーバ154と、コンテンツ配信システム180と、クライアントデバイス152とを含む。コンテンツ配信システム180の要素は、概して、図1のコンテンツ準備デバイス20および/またはサーバデバイス60に対応し得るのに対して、クライアントデバイス152の要素は、図1のクライアントデバイス40に対応し得る。いくつかの例では、クライアントデバイス152の要素は、図1の取出しユニット52に対応し得る。
この例では、コンテンツ配信システム180は、MPD生成器156と、パッケージャ(packager)158と、オリジンサーバ160とを含む。MPD生成器156は、メインメディアコンテンツ(たとえば、ユーザが見ることを希望するプログラムに関するメディアデータ)に関するMPD162、ならびに、MPD164など、広告に関する1つまたは複数のMPDを生成する。MPD162はメディアコンテンツ166A〜166Cを記述するのに対して、MPD164は広告データ168A〜168Cを記述する。パッケージャ158は、メディアコンテンツ166A〜166Cおよび広告データ168A〜168Cを組み立てる。パッケージャ158は、概して、カプセル化ユニット30(図1)に対応し得る。
クライアントデバイス152は、それ自体が広告管理サービス172を含むメディアアプリケーション170を含む。クライアントデバイス152はまた、メインメディアコンテンツを取り出すためのDASHクライアント176と広告データを取り出すためのDASHクライアント174とを含む。アプリケーション170は、広告管理サーバ172を介して広告判定サーバ154からMPD URLを取り出し、MPD URLをDASHクライアント176およびDASHクライアント174に提供する。DASHクライアント174およびDASHクライアント176のうちのいずれかまたは両方は図2のDASHクライアント110に対応し得る。広告管理サービス172は、下でより詳細に論じる、本開示の技法に従って、広告に関するMPDを選択することができる。DASHクライアント174は、広告に関するMPDを使用して、広告データ(たとえば、広告データ168A〜168Cのうちの1つまたは複数)をオリジンサーバ160から取り出すことができる。DASHクライアント176は、メインコンテンツ(たとえば、メインコンテンツ166A〜166Cのうちの1つまたは複数)をオリジンサーバ160から取り出すことができる。
本開示の技法の第1の例によれば、アプリケーション固有イベントはアプリケーション170に渡されてよく、アプリケーション170は、外部広告判定サーバ154と相互に作用し、広告コンテンツ、たとえば、広告データ168A〜168Cを指すMPD URLをDASHクライアント174に提供する。広告コンテンツが取得され、再生される間に、アプリケーション170はメインプログラムを休止する。広告挿入の後、アプリケーション170はメインプログラムの再生を再開する。
広告管理サービス172は、ユーザプロファイル/プリファレンス(「UP/P」)情報、コンテンツ消費履歴、広告推奨エンジンなどを(単独で、または任意の組合せで)採用して、ターゲット広告挿入をサポートすることができる。このために、一般的なウェブ技術を使用することができる。追加または代替として、IAB(Interactive Advertising Bureau)によって定義されたVMAP(Video Multiple Ad Playlist)など、他の方法を使用することもできる。
この例では、MBMSサービス層(図示せず)は、DASHクライアント174、176に関する厳密な配信機能を提供する。たとえば、MBMSサーバ層は、ターゲットユーザグループまたはターゲットユーザプロファイルに関して設計された利用可能な広告コンテンツデータを配信することができ、この場合、各カテゴリーは一意のURLにマッピングされ得る。MBMSクライアントは、アプリケーション170の代わりに、DASHクライアント176による選択的な要求のためにすべてのブロードキャスト広告をダウンロードし、キャッシュすることができる。
アプリケーション170、DASHクライアント174、176、MPD生成器156、およびパッケージャ158は、ハードウェアまたはソフトウェアで実装され得る。ソフトウェアで実装されるとき、1つまたは複数の処理ユニットおよび1つまたは複数のコンピュータ可読記憶媒体など、必須ハードウェアも提供されることが推定される。コンピュータ可読記憶媒体は、ソフトウェアに関する命令を記憶することができ、処理ユニットは、それらの命令を実行して、上で説明した機能を実行することができる。
図5は、本開示の技法を実装し得る別の例示的なシステム200を示すブロック図である。図5のシステム200の要素は、概して、図1の要素に対応し得る。たとえば、システム200は、広告(広告)判定サーバ208と、コンテンツ配信システム212と、クライアントデバイス206とを含む。コンテンツ配信システム212の要素は、概して、図1のコンテンツ準備デバイス20および/またはサーバデバイス60に対応し得るのに対して、クライアントデバイス206の要素は、図1のクライアントデバイス40に対応し得る。いくつかの例では、クライアントデバイス206の要素は、図1の取出しユニット52に対応し得る。
この例では、クライアントデバイス206は、メディアエンジン202と、DASHアクセスクライアント204とを含む。DASHアクセスクライアント204は、図2のDASHクライアント110に対応し得るのに対して、メディアエンジン202は、図2のメディアアプリケーション112に対応し得る。コンテンツ配信システム212は、MPD生成器214と、パッケージャ216と、コンテンツ配信ネットワーク(CDN)/オリジンサーバ218とを含む。オリジンサーバ218は、MPD220と、メインコンテンツ222A〜222Cと、広告データ224A〜224Cとを記憶する。
図5の例は、本開示の技法の第2の例示的なセットの考えられる実装を表す。この技法の第2の例示的なセットでは、基本概念は、DASHアクセスクライアント204およびHTTPスタックは適切な広告を取得する役割を担うことである。MPD220に記述されるリモートPeriodは広告コンテンツ(たとえば、広告データ224A〜224C)と呼ばれる場合があり、広告コンテンツは、Period@xlink:hrefの適切なフォーマットによって、特定のユーザグループ/プロファイルをターゲットとし得る。したがって、DASHアクセスクライアント204はXLink(すなわち、XMLリンク付け言語データ)をXLinkレゾルバ210に導き、XLinkレゾルバ210は、適切なリモートPeriodを記述するデータを広告判定サーバ208から取り出す。MPD生成器214がMPD220を生成するときに広告ブレーク時間が知られている場合、CDN/オリジンサーバ218は、リモートPeriodを包含するMPD220を事前に送ることができる。代替として、CDN/オリジンサーバ218は、DASH固有イベントを使用して、リモートPeriodデータを動的に送り、DASHアクセスクライアント204がMPD220に対する更新を獲得するのをトリガすることができる。
広告を選択するための技法は、図4に関して上で説明した技法と同様であり得る。たとえば、UP/P情報、コンテンツ消費履歴、および広告推奨エンジンなどを採用して、ターゲット広告挿入をサポートすることができる。
上述のように、第2の例は技術のあるセットを含む。すなわち、(単独で、または何らかの組合せで使用される)様々なオプションが可能である。第1のオプションでは、MBMSサービス層(図示せず)は非選択的広告受信を実行する。MBMSサーバ層は、ターゲットユーザグループまたはターゲットユーザプロファイルに関して設計された利用可能な広告コンテンツデータを配信することができ、この場合、各カテゴリーは一意のURLにマッピングされ得る。MBMSクライアントは、DASHアクセスクライアント204および/またはメディアエンジン202による選択的な要求のためにすべてのブロードキャスト広告をダウンロードし、キャッシュすることができる。
第2のオプションでは、MBMSサービス層は選択的広告受信を実行する。ブロードキャストマルチキャストサービスセンター(BM-SC:Broadcast Multicast Service Center)は、メタデータを各広告(たとえば、広告データ224A〜224C)に添付することができ、DASHアクセスクライアント204は、MBMSクライアントがブロードキャスト広告(たとえば、広告データ224A〜224Cのうちの1つ)を選択的にダウンロードし、キャッシュするように、選択的にダウンロードし、キャッシュするための広告データの好ましいカテゴリーについてMBMSクライアントに知らせることができる。
メディアエンジン202、DASHアクセスクライアント204、MPD生成器214、およびパッケージャ216は、ハードウェアまたはソフトウェアで実装され得る。ソフトウェアで実装されるとき、1つまたは複数の処理ユニットおよび1つまたは複数のコンピュータ可読記憶媒体など、必須ハードウェアも提供されることが推定される。コンピュータ可読記憶媒体は、ソフトウェアに関する命令を記憶することができ、処理ユニットは、それらの命令を実行して、上で説明した機能を実行することができる。
図6A〜図8Bは、DASHクライアント(たとえば、DASHアクセスクライアント204)が適切な広告コンテンツの受信を確実にする様々な例示的な方法を示すシーケンス図である。図6A〜図8Bの様々な方法は、図5に関して上で説明した、本開示の技法の第2の例示的なセットに一致する。
図6A〜図8Bは、様々なタスクを実行するとして説明される。これらの要素は、アプリケーション(たとえば、メディアエンジン202)と、DASHクライアント(たとえば、DASHアクセスクライアント204)と、MBMSクライアント(ローカルHTTPプロキシおよびXLinkレゾルバ210を含み得る)と、BM-SC(たとえば、CDN/オリジンサーバ218)と、広告判定サーバ(たとえば、判定サーバ208)と、コンテンツプロバイダ(たとえば、MPD生成器214およびパッケージャ216を含む)と、広告プロバイダ(図5に示さず)とを含む。
図6Aおよび図6Bは、本開示の技法の第2の例示的なセットに関して上で説明した第1のオプションによる方法の一例を示す。さらに、図6Aおよび図6Bの例は、(たとえば、ライブイベントの場合)MPDが生成されるとき広告ブレーク開始時間が知られていない状況に対応する。図6Aおよび図6Bは、アプリケーション(たとえば、図2のメディアアプリケーション112)と、DASHクライアント(たとえば、図2のDASHクライアント110)と、MBMSクライアント(たとえば、図2のeMBMSミドルウェアユニット100)と、BM-SCと、広告判定サーバと、コンテンツプロバイダと、広告プロバイダとを含めて、様々な要素によって実行される活動を示す。
図6Aおよび図6Bの例では、DASHクライアントは、ローカルgroupIDが「B」に等しいことを認識していると仮定される。また、コンテンツ/広告プロビジョニングおよびMPDフォーマットに関して、MBMSオペレータとコンテンツプロバイダと広告プロバイダとの間に取引合意が存在すると仮定する。図6Aおよび図6Bの例では、当初、BM-SCは、MPDフラグメントを有するUSDをMBMSクライアントに配信し、MBMSクライアントはMPDをDASHクライアントに転送する。BM-SCは、次いで、ブロードキャストを介して、各々が将来の時間T1におけるPeriodの開始時間を有する、たとえば、1) http://adserver.com/ad1?id="A"、2) http://adserver.com/ad1?id="B"、および3) http://adserver.com/ad1?id="C"のBaseURLを備えたリモートPeriod要素に対応する3つのファイルを配信することができる。MBMSクライアントはすべてのリモートPeriod要素をダウンロードし、キャッシュする。
将来の何らかの時点で、近い将来の広告挿入発生を示すキューメッセージを広告プロバイダから受信する結果として、BM-SCは、MBMSクライアントが受信し、DASHクライアントに転送する、更新されたMPDの獲得をトリガするためのDASH固有イベントを(たとえば、MPDイベントまたはインバンドイベントメッセージを介して)シグナリングする。BM-SCは、次いで、更新されたMPD、USBD、およびスケジュールフラグメントをブロードキャストし、この場合、USBDはリモートPeriod内で広告コンテンツを搬送するFLUTEセッションを参照する配信方法を包含し、スケジュールは次の広告送信を宣言する。応答して、DASHクライアントは更新されたMPDをフェッチする(この場合、この例では、MPDは、Period@xlink:href=http://adserver.com/ad1?id=$groupID$および@xlink:actuate="onRequest"を有するリモートPeriodを示す)。この場合、DASHクライアントは、リモートPeriodに関するリンクを即時にデリファレンスすることを試みないが、関連するコンテンツの再生がその期間に入ることが予想されるまで、そのようなデリファレンス活動を延期する。
BM-SCは、次いで、ターゲットgroupID(たとえば、下で図13Aおよび図13Bを参照して論じるような、たとえば、ファイル配信テーブル(FDT)「File」要素拡張属性「$groupID$」など)によって各広告をタグ付けして、リモートPeriod要素によって参照された広告コンテンツをブロードキャストする。追加または代替として、下で論じるように、フィルタ記述フラグメントのgroupIDFilterは広告データを識別することができる。MBMSクライアントは、この例では、広告のすべてをダウンロードし、キャッシュする。時間T1が近づくと、DASHクライアントは、@xlink:href内に出現するURLに関するHTTP要求を発行することによって、リモートPeriod要素のデリファレンスを要求し、「B」のローカルgroupID値をMBMSクライアントに提供する。応答して、MBMSクライアントは、要求時に、適切な広告配信のためのgroupID=「B」を記録し、BaseURL=「http://adserver.com/ad1?id="B"」と関連付けられた期間をDASHクライアントに配信する。DASHクライアントは、次いで、この広告のセグメントをアプリケーションに提供する。このプロセスは、広告データが完全に再生されるまで続き、次いで、メインコンテンツの標準ブロードキャストが再開し得る。
図7Aおよび図7Bは、(たとえば、ライブイベントに関する)MPDが生成される時点で広告可用性(広告可用性)時間が知られていない一例を示す。図7Aおよび図7Bの例は、MBMSクライアントによる選択的な広告受信が存在する、上で説明したオプション2に対応する。この例では、ブロードキャスト広告配信は、広告可用性時間の直前に発生する。図7Aおよび図7Bは、アプリケーション(たとえば、図2のメディアアプリケーション112)と、DASHクライアント(たとえば、図2のDASHクライアント110)と、MBMSクライアント(たとえば、図2のeMBMSミドルウェアユニット100)と、BM-SCと、広告判定サーバと、コンテンツプロバイダと、広告プロバイダとを含めて、様々な要素によって実行される活動を示す。
図7Aおよび図7Bの例では、状態情報(たとえば、クッキー、加入情報、使用履歴など)は、ユーザ装置(UE)上に存在し、HTTP要求内でDASHクライアントによってネットワークのデバイスに配信可能であると仮定する。同様に、この例では、コンテンツ/広告プロビジョニングおよびMPDのフォーマットに関して、MBMSオペレータとコンテンツプロバイダと広告プロバイダとの間に取引合意が存在すると仮定する。
当初、BM-SCは、MPDフラグメントを有するUSDをMBMSクライアントに配信し、MBMSクライアントはMPDをDASHクライアントに転送する。BM-SCは、次いで、ブロードキャストを介して、各々が将来の時間T1におけるPeriod開始時間を有する、たとえば、1) http://adserver.com/ad1?id="A"、2) http://adserver.com/ad1?id="B"、および3) http://adserver.com/ad1?id="C"のBaseURLを備えたリモートPeriod要素に対応する3つのファイルを配信することができる。MBMSクライアントはすべてのリモートPeriod要素をダウンロードし、キャッシュする。将来の何らかの時点で、近い将来の広告挿入発生を示すキューメッセージを広告プロバイダから受信する結果として、BM-SCは、MBMSクライアントが受信し、DASHクライアントに転送する、更新されたMPDの獲得をトリガするためのDASH固有イベントを(たとえば、MPDイベントまたはインバンドイベントメッセージを介して)シグナリングする。BM-SCは、次いで、更新されたMPD、USBD、およびスケジュールフラグメントをブロードキャストし、この場合、USBDはリモートPeriod内で広告コンテンツを搬送するFLUTEセッションを参照する配信方法を包含し、スケジュールは次の広告送信を宣言する。
応答して、DASHクライアントは更新されたMPDをフェッチする(この場合、MPDは、Period@xlink:href=http://adserver.com/ad1?id=$groupID$および@xlink:actuate="onLoad"を有するリモートPeriodを示す)。この場合、DASHクライアントは、MPDをロードするとすぐに、リモートPeriodに関するリンクをデリファレンスすることになり、上で説明したUE状態情報をXlinkレゾルバとして機能するMBMSクライアントに渡すことになる。MBMSクライアントは、次いで、状態情報を後続のターゲット広告ダウンロードのための広告グループのうちの1つにマッピングする。この例では、MBMSクライアントは状態情報をgroupID=「B」にマッピングすると仮定する。
DASHクライアントは、次いで、@xlink:href内に出現するURLに関するHTTP GETを発行することによって、リモートPeriod要素のデリファレンスを要求する。MBMSクライアントは、この例では、BaseURL=「http://adserver.com/ad1?id="B"」と関連付けられたPeriod要素を配信することによって応答する。BM-SCは、次いで、ターゲットgroupID(たとえば、下で図13Aおよび図13Bを参照して論じるような、たとえば、FDT拡張属性など)によって各広告をタグ付けして、リモートPeriod要素によって参照され広告コンテンツファイルをブロードキャストする。追加または代替として、下で論じるように、フィルタ記述フラグメントのgroupIDFilterは広告データを識別することができる。
MBMSは、次いで、この例では、groupID=「B」を有する広告を選択的にダウンロードし、キャッシュすることができる。時間T1が近づくと、DASHクライアントは、@xlink:href内に出現するURLに関するHTTP要求を発行することによって、リモートPeriod要素のデリファレンスを要求し、「B」のローカルgroupID値をMBMSクライアントに提供する。応答して、MBMSクライアントは、要求時に、適切な広告配信のためのgroupID=「B」を記録し、BaseURL=「http://adserver.com/ad1?id="B"」と関連付けられたPeriodをDASHクライアントに配信する。DASHクライアントは、次いで、この広告のセグメントをアプリケーションに提供する。このプロセスは、広告データが完全に再生されるまで続き、次いで、メインコンテンツの標準ブロードキャストが再開し得る。
図8Aおよび図8Bは、(たとえば、ライブイベントに関する)MPDが生成される時点で広告可用性(広告可用性)時間が知られていない一例を示す。図7Aおよび図7Bの例は、上で説明したオプション2に対応し、この場合、広告はMBMSクライアントによる選択的な広告受信が存在する直前にブロードキャストされる。図8Aおよび図8Bのこの例では、ブロードキャスト広告配信は、広告可用性時間のかなり前に発生し、その広告を再生する時間まで、選択的にキャッシュされる。図8Aおよび図8Bは、アプリケーション(たとえば、図2のメディアアプリケーション112)と、DASHクライアント(たとえば、図2のDASHクライアント110)と、MBMSクライアント(たとえば、図2のeMBMSミドルウェアユニット100)と、BM-SCと、広告判定サーバと、コンテンツプロバイダと広告プロバイダとを含めて、様々な要素によって実行される活動を示す。
図8Aおよび図8Bの例では、状態情報(たとえば、クッキー、加入情報、使用履歴など)は、ユーザ装置(UE)上に存在すると仮定する。図7Aおよび図7Bの例とは対照的に、DASHクライアントは、DASHコンテンツに関する初期HTTP要求の間、状態情報をMBMSクライアントに渡す。図7Aおよび図7Bの例と同様に、コンテンツ/広告プロビジョニングおよびMPDのフォーマットに関して、MBMSオペレータとコンテンツプロバイダと広告プロバイダとの間に取引合意が存在すると仮定する。
したがって、この例では、MBMSクライアントは、後続のターゲット広告ダウンロードのために、クライアントデバイス(UE)に関する状態情報を早い段階でgroupID、たとえば、groupID=「B」にマッピングすることができる。次いで、BM-SCは、USDフラグメント内で配信されたスケジュールに従って、広告コンテンツをブロードキャストすることができ、これは初期の広告可用性が可能になるかなり前に発生し得る。ターゲットgroupID(下で図13Aおよび図13Bを参照して論じるような、たとえば、FDT拡張属性など)によって各広告をタグ付けして、広告コンテンツはリモートPeriod要素によって参照される。追加または代替として、下で論じるように、フィルタ記述フラグメントのgroupIDFilterは広告データを識別することができる。MBMSクライアントは、次いで、この例では、groupID=「B」を有する広告を選択的にダウンロードし、キャッシュする。
次に、BM-SCは、MPDフラグメントを有するUSDをMBMSクライアントに配信し、MBMSクライアントはMPDをDASHクライアントに転送する。BM-SCは、次いで、ブロードキャストを介して、各々が将来の時間T1におけるPeriod開始時間を有する、たとえば、1) http://adserver.com/ad1?id="A"、2) http://adserver.com/ad1?id="B"、および3) http://adserver.com/ad1?id="C"のBaseURLを備えたリモートPeriod要素に対応する3つのファイルを配信することができる。MBMSクライアントはユーザと関連付けられたgroupID値をすでに決定しているため(この例では、groupID=「B」)、MBMSクライアントはBaseURL http://adserver.com/ad1?id="B"と関連付けられたリモートPeriod要素をダウンロードし、キャッシュすることができる。将来の何らかの時点で、近い将来の広告挿入発生を示すキューメッセージを広告プロバイダから受信する結果として、BM-SCは、MBMSクライアントが受信し、DASHクライアントに転送する、更新されたMPDの獲得をトリガするためのDASH固有イベントを(たとえば、MPDイベントまたはインバンドイベントメッセージを介して)シグナリングする。BM-SCは、次いで、更新されたMPDフラグメントをブロードキャストし、MBMSクライアントがその更新されたMPDフラグメントを受信する。
次いで、DASHクライアントは更新されたMPDをフェッチする(この場合、MPDは、Period@xlink:href=http://adserver.com/ad1?id=Bおよび@xlink:actuate="onLoad"を有するリモートPeriodを示す)。この場合、DASHクライアントは、リモートPeriodに関するリンクをデリファレンスすることになる。同様に、この例では、DASHクライアントは、Xlink URL内のパラメータに関する値を置き換えなくてよいが、これは、MPD自体が広告グループ(この例では、B)に関する値を指定するためである。MBMSクライアントは、この例では、BaseURL=「http://adserver.com/ad1?id="B"」と関連付けられたPeriod要素を配信することによって応答する。すなわち、MBMSクライアントは、上で論じたように、この例では、広告グループ「B」と関連付けられたデータだけをキャッシュすることになる。
時間T1が近づくと、DASHクライアントは、前に受信したPeriod要素と関連付けられるコンテンツの第1のセグメント、すなわち、ターゲット広告を要求し、MBMSクライアントから受信する。DASHクライアントは、次いで、広告のこのセグメントのメディアコンテンツをアプリケーションに提供する。このプロセスは、広告データが完全に再生されるまで続き、次いで、メインコンテンツの標準ブロードキャストが再開し得る。
6A〜図8Bは、本開示の技法による、可能な例のうちのいくつかだけを表す。サーバベースの方法に関する他のコールフロー変形体も同様に可能である。たとえば、広告可用性よりかなり前に発生するブロードキャスト広告配信の場合、MPD更新内で搬送されるPeriod@xlink:actuateの値は(「onLoad」の代わりに)「onRequest」に設定され得る。ターゲット広告はすでにUE上に選択的にダウンロードされ、キャッシュされているため、それが広告可用性の前に発生する限り、xlinkを解決する時間的緊急性は存在しない。いくつかの理由により、広告可用性の発生時に何のターゲット広告もデバイス上で利用可能でない場合、デフォルトの事前記憶された広告をその場所で再生することができる。
それによって、MBMSクライアントがDASHクライアントによって提供されたUE状態情報から適切な「groupID」値を配信する様々な可能な機構も存在する。一例として、ローカルUP/Pデータベース、コンテンツ推奨エンジン、または局所的に記憶された使用履歴ログを使用した推論の実行など、UE常駐イネーブラに対するアクセスが存在し得る。別の例として、外部UP/Pデータベース、またはコンテンツ推奨エンジンなど、ネットワーク側イネーブラに対するアクセスが存在し得る。
MBMSクライアント支援型広告選択を対象とする、本開示の技法の第3の例については、図9〜図11Bに関して説明する。第3の例の基本概念は、MBMSクライアントが、USD内に包含されたメタデータおよび/またはフィルタ規則に基づいて、ブロードキャスト広告を選択的にダウンリードし、キャッシュすることである。フィルタ記述フラグメントは広告フィルタリングデータを搬送するように拡張され得る。この例は、MBMSクライアントに対するUP/P情報、コンテンツ消費情報などのイネーブラの可用性を推定する。たとえば、イネーブラは、MBMSクライアントにアクセス可能なデバイス常駐UP/P情報を含み得る。特定のUP/Pデータおよび相互作用については説明しないが、当業者によって決定され得る。
さらに、MBMSサービス層は広告フィルタリング/選択機能を提供する。ブロードキャスト広告は、MBMSクライアントによる選択的なダウンロードおよびキャッシュのためにプログラム(たとえば、DASHメディアプレゼンテーション)に先立って配信されると仮定する。MBMSクライアントによる選択機構は実装固有であり得る。
図9は、ロケーションフィルタデータを搬送するための、現在定義されている、例示的なフィルタ記述フラグメントを示す概念図である。図10は、ユーザプリファレンス&プロファイル(UP/P)データを搬送するためのフィルタ記述フラグメントに対する拡張を示す概念図である。図10の例では、userPrefProfData要素は、広告選択のための属性値の対(たとえば、ユーザ人口統計、コンテンツカテゴリー、レーティング、人気など)を包含する。userPrefProfRule要素は、広告選択のためのフィルタリング規則(特定の条件および論理)を包含する。
図11Aおよび図11Bは、本開示の技法による、MBMSクライアント支援型広告選択のための例示的な方法を示すシーケンス図である。この例では、MPDが生成される時点で広告ブレーク開始時間は知られている。図11Aおよび図11Bのアクティブユニットは、図6A〜図8Bのアクティブユニットと実質的に同様である。図11Aおよび図11Bは、アプリケーション(たとえば、図2のメディアアプリケーション112)と、DASHクライアント(たとえば、図2のDASHクライアント110)と、MBMSクライアント(たとえば、図2のeMBMSミドルウェアユニット100)と、BM-SCと、広告判定サーバと、コンテンツプロバイダと、広告プロバイダとを含めて、様々な要素によって実行される活動を示す。
図11Aおよび図11Bの例では、MBMSクライアントはUP/Pデータに対するアクセスを有し、コンテンツ/広告プロビジョニングおよびMPDのフォーマットに関して、MBMSオペレータとコンテンツプロバイダと広告プロバイダとの間に取引合意が存在すると仮定する。最初に、BM-SCは、たとえば、図10の例に従って、MPDとフィルタ記述とを含むUSDを提供する。アプリケーションはMPD URLをDASHクライアントに送り、DASHクライアントはURLからMPDをフェッチする。MPDは、通常コンテンツに関するPeriod_1と、広告コンテンツに対するXLinkを有し、属性xlink:actuate="onRequest"を有するリモートPeriod_2と、さらなる通常コンテンツを有するPeriod_3とを含むと仮定する。すなわち、この例では、Period_2は事前決定された広告ブレークを表す。コンテンツプロバイダは、通常(または、メイン)コンテンツをBM-SCに提供し、広告プロバイダは広告コンテンツをBM-SCに提供する。
BM-SCは(Period_2においてXLinkによって参照されるコンテンツに対応する)広告をMBMSクライアントにブロードキャストする。MBMSクライアントは、たとえば、UP/Pデータまたはフィルタ記述の規則に従って、広告を選択的にダウンロードし、キャッシュする。BM-SCは、次いで、Period_1のセグメントをMBMSクライアントにブロードキャストする。Period_2の開始が近づくと、DASHクライアントは、@xlink:href内に出現するURLに関するHTTP要求を発行することによって、(この例では、Period_2に対応する)リモートPeriod要素のデリファレンスを要求する。MBMSクライアントは、次いで、@xlink:hrefによって参照される(Period_2に対応する)Period要素を配信する。DASHクライアントは、Period_1のセグメント(たとえば、「http://example.com/per-1/rep-512/seg-i.3gp」などのセグメントURL、この場合、i∈{1,99})をフェッチする。
DASHクライアントは、次いで、Period_1(プログラムコンテンツ)のセグメントをアプリケーションに送る。DASHクライアントはまた、MBMSクライアントから(xlinkによって参照される)Period_2のセグメントを要求する。MBMSクライアントは、ローカルキャッシュからPeriod_2のセグメントを取り出すために、たとえば、HTTP303応答を使用して、ローカルホストアドレスにDASHクライアントを導く。DASHクライアントは、次いで、キャッシュされた広告コンテンツ(たとえば、「http://localhost.com/per-2/rep-512/seg-j.3gp」などのセグメントURL、この場合、j∈{100,129})に関してPeriod_2のセグメントをフェッチする。
DASHクライアントは、次いで、Period_2(広告コンテンツ)のセグメントをアプリケーションに送る。BM-SCはまた、Period_3のセグメントをMBMSクライアントにブロードキャストする。DASHクライアントはまた、MBMSクライアント(たとえば、「http://example.com/per-3/rep-512/seg-k.3gp」などのセグメントURL、この場合、k∈{130,200})からPeriod_3のセグメントを要求する。DASHクライアントは、次いで、Period_3(プログラムコンテンツ)のセグメントをアプリケーションに送る。
図12は、本開示の技法による、リアルタイムトランスポートプロトコル(RTP)に関するMBMSクライアント支援型広告選択および挿入のための例示的な方法を示すシーケンス図である。この例では、ユーザプロファイルはMBMSクライアントに知られている。広告が送られるとき、FDTは広告に関するメタデータを含み得る。ユーザプロファイルとフィルタ記述とに基づいて、MBMSクライアントは、広告を選択的にダウンロードし、キャッシュすることができる。任意選択で、クライアントデバイス(UE)は、プロファイルデータによって指定されたロケーションエリア内にある場合、広告を挿入するかどうかを判定することができる。図12は、アプリケーション(たとえば、図2のメディアアプリケーション112)と、DASHクライアント(たとえば、図2のDASHクライアント110)と、MBMSクライアント(たとえば、図2のeMBMSミドルウェアユニット100)と、BM-SCと、広告判定サーバと、コンテンツプロバイダと、広告プロバイダとを含めて、様々な要素によって実行される活動を示す。
図12の例では、MBMSクライアントはUP/Pデータに対するアクセスを有し、コンテンツ/広告プロビジョニングに関して、MBMSオペレータとコンテンツプロバイダと広告プロバイダとの間に取引合意が存在すると仮定する。最初に、BM-SCは、たとえば、図10の例に従って、フィルタ記述を含むUSDを提供する。アプリケーションはURLをDASHクライアントに送り、DASHクライアントは、RTPに従って、セットアップおよび再生を実行する。コンテンツプロバイダは、通常(または、メイン)コンテンツをBM-SCに提供し、広告プロバイダは広告コンテンツをBM-SCに提供する。
BM-SCは、次いで、(メタデータを有する)広告のブロードキャストを開始する。MBMSクライアントは、UP/Pおよびフィルタ記述内の規則に従って、広告を選択的にダウンロードし、キャッシュする。BM-SCは、RTPを使用して、ビデオデータおよびオーディオデータを送る。MBMSクライアントは、次いで、クライアントデバイス(UE)がプロファイルデータごとに広告を挿入するために望まれるロケーション内にあるかどうかを決定する。クライアントデバイスがそのようなロケーション内にあることを仮定して、MBMSクライアントは、RTPビデオパケットおよびオーディオパケットを用いてメタデータごとに広告を挿入する。MBMSクライアントは、次いで、広告の期限が切れるとき、メタデータごとに広告を削除する。
図13A〜図13Dは、ファイル配信テーブル(FDT)ファイル要素に対する例示的な拡張を示す概念図である。この例では、ファイル要素は、上で論じたように、groupID値に対応し得るグループ属性を含むように拡張される。具体的には、ファイル要素250は、この例では、タイプxs:stringを有する「mbms2014:groupID」と称するグループ属性252を含めるために拡張されている。
いくつかの例では、クライアントデバイスは、上で説明した、第1の例、第2の例、および第3の例の技法のうちのいずれかまたはすべてを実行するように構成され得る。たとえば、異なるコンテンツ分散ネットワークは、ターゲット広告挿入のための異なる機構をサポートすることができ、クライアントデバイスは、第1の例、第2の例、および/または第3の例のうちのいずれかまたはすべての技法を実装することができる。別の例として、コンテンツ配信ネットワークは、上で説明した、第1の例、第2の例、および第3の例の技法のうちのいずれかまたはすべてをサポートし得る。さらに、上で説明した第1の例、第2の例、および/または第3の例の技法は、任意の組合せで一緒に実行されてもよい。
図13A〜図13Dに示す「groupID」のFDT拡張パラメータは単なる一例である。本開示の技法に従って、他の技法を使用することができる。たとえば、関連する広告ファイルに関するメタデータとしてのFDT拡張パラメータ(「groupID」)の使用に加えて、または代替として、MBMSクライアントがユーザに関して特に適した広告だけをフィルタリングすることを可能にするためのもう1つの可能性は、既存のUSDを拡張することである。たとえば、新しい要素「groupIDFilter」をフィルタ記述フラグメントに追加することができる(この場合、フィルタ記述フラグメントは、スケジュール記述フラグメント内のファイルスケジュールインスタンスによって参照され、ファイルスケジュールは広告ファイルに関する送信スケジュールを提供する)。
図14は、本開示の技法を実行し得る別の例示的なシステム300を示すブロック図である。システム300の構成要素は、BM-SCを介したコンテンツプロバイダおよび広告ソースからユーザ装置(UE)へのDASHフォーマットメディアコンテンツおよびターゲット広告のソーシング、スケジューリング、および配信に関連する機能エンティティを含む。この例では、システム300は、クライアントデバイス302と、コンテンツプロバイダ314と、広告判定サーバ316と、プロバイダ318と、ブロードキャストマルチキャストサービスセンター(BM-SC)320とを含む。クライアントデバイス302は、メディアエンジン304と、DASHクライアント306と、MBMSクライアント308とを含む。クライアントデバイス302はUEの一例を表す。MBMSクライアント308は、XLinkレゾルバ310と、HTTPプロキシキャッシュ312とをさらに含む。BM-SC320は、USBD322、MPD324、コンテンツ326A〜326C(コンテンツ326)、および広告(広告)328A〜328C(広告328)に関するデータを含む。
一般に、コンテンツプロバイダ314は、コンテンツ326をBM-SC320に提供する。広告判定サーバ316は、(広告挿入キューを使用して)広告がいつ挿入されるべきかをシグナリングし、広告に関するリモートPeriodをプロビジョニングする。広告プロバイダ318は、広告328をBM-SC320に提供する。広告328A〜328Cは、各々、上で論じたように、広告をユーザにターゲットするために、異なるユーザグループに対応し得る。
MBMSクライアント308は、コンテンツ326のうちの1つまたは複数からデータを受信するために、グループをブロードキャストまたはマルチキャストするために加入する。さらに、図15Aおよび図15Bに関して下でより詳細に説明するように、MBMSクライアント308は、広告ブレークに挿入するために広告328A〜328Cのうちの1つを選択的に受信することができる。MBMSクライアント308は、コンテンツデータと広告データとをHTTPプロキシキャッシュ312内に記憶する。このようにして、DASHクライアント306は、HTTP要求をMBMSクライアント308に提出することによって、メディアデータ(たとえば、メインコンテンツデータおよび広告データ)を取り出すことができ、次に、MBMSクライアントは、MPDデータおよびセグメントをDASHクライアント306に送る。適切に広告データを選択するために、DASHクライアント306はXLinkをMBMSクライアント308に送ることができる。XLinkレゾルバ310は、XLinkを解決して、受信されるべき広告データを決定することができる。
図14の例示的なアーキテクチャでは、広告関連情報はMPD324とコンテンツ326のセグメントとを使用して宣言可能であり、広告判定は、MPDに対するDASHクライアント306の要求と、そのMPDが記述するリソース、すなわち、リモートPeriod要素およびセグメントとによって開始可能である。MPD生成の時点で広告ブレークの発生時間が知られている場合、広告ブレークのかなり前に、リモートPeriod要素を包含するMPDをDASHクライアントに送ることができる。さもなければ、ターゲット広告挿入のための近い将来の機会をシグナリングするために、たとえば、MPD@minimumUpdatePeriodによって定義される周期性を伴う同時MPD更新に基づくMPD更新機能に依存する必要があり得る。予測不可能な広告ブレークの動作シナリオを以下の議論で仮定する。
最新のMPDを獲得するための、DASHクライアント306とMPDサーバ(この場合、後者はUE(すなわち、クライアントデバイス302)内に、およびローカルHTTPプロキシおよびキャッシュ312を含むMBMSクライアント308内の一部内に存在すると仮定する)との間の公称相互作用は周期的であるが、休憩の発生は、純粋に非同期的であり得、たとえば、フットボールゲームにおけるインジャリータイムの間に生じ得る。広告ブレークをトリガするインシデントから始まる広告挿入の実際のスプライスタイムまでの広告ブレークの予想されるセットアップ時間に応じて、DASHクライアント306がそのような動的イベントを逃さないように、それに応じて、MPD@minimumUpdatePeriod値を調整することができる。条件付きGETを介する可能性が最も高い、MPD更新のためのHTTP相互作用は、UE内で局所的に発生し得、その結果、何のユニキャストネットワークトラフィックも生じず、ほぼ常に、DASHクライアント306によって前に獲得されたMPDは依然として有効である。更新されたとき、MPDは、Period@xlink:hrefを介して外部Period要素に対するポインタを搬送し得る。
MBMSクライアント308とのHTTP相互作用の一環として、DASHクライアント306は、UE/ローカルユーザに関する状態情報をMBMSクライアント308に渡すことができる。そのような状態情報の例には、クッキーと、加入情報と、コンテンツ消費履歴データとがある。状態情報は、MPDまたはメディアセグメントに関する公称要求/応答の間に、またはXLink解決手順の間に、MBMSクライアント308に提供され得る。MBMSクライアント308は、TS26.346(たとえば、ローカルユーザプロファイル/プリファレンス情報、コンテンツ消費履歴、またはコンテンツ推奨エンジンに対するアクセス)の範囲外のいくつかの機構を利用して、ユーザに関する特定のグループまたはプロファイル識別子を決定することができる。そのような「groupID」は、そのユーザに関して適切なまたは好ましい広告コンテンツのインジケータとして使用され得る。広告コンテンツがブロードキャストされるとき(この場合、様々な広告ファイルが異なるユーザをターゲットとする)、MBMSクライアントは、後の要求時に、DASHクライアントに提供されることになる、1つまたは複数の特定の広告をダウンロードおよびキャッシュするためのフィルタとしてgroupIDを使用する。広告のブロードキャスト配信は、広告ブレークのかなり前に(たとえば、翌日のフットボール試合の前夜)、または実際の広告ブレークに先立って時間的により近接して発生し得る。
MBMSクライアント308による広告の選択的なダウンロードおよびキャッシングは、MBMSクライアント308がローカル状態情報を獲得し、そのデータをユーザのgroupID値にマッピングする限り可能である。MBMSクライアントによる選択的な広告受信を可能にするために、関連付けられた広告に関するメタデータとしてgroupIDを伝達するための異なる方法が可能である。たとえば、TOIおよびContent-Locationによって識別される広告ファイルに関してFLUTE FDT拡張属性groupIDを指定することができる。その配信スケジュールがファイルスケジュールのインスタンスによって発表されている対応する広告フィルタに関する識別子として、新しい子要素groupIDFilterをfilterData要素の下に追加することによって、既存のフィルタ記述フラグメントを拡張することも可能である。
XLinkの解決において、MBMSクライアント308は、そのユーザに対して(たとえば、groupIDによって)カスタマイズされたリモートPeriod要素を戻すことができる。そのPeriod要素はセグメントURL情報を含めて、Periodの持続時間に関する広告コンテンツに対する参照を包含する。DASHクライアント306は、その情報を使用して、広告ブレークの適切な時点において広告コンテンツに関するセグメントをフェッチすることができる。対応する広告コンテンツはMBMSクライアント308によってすでにダウンロードされ、キャッシュされている(HTTPプロキシキャッシュ312内にキャッシュされている)ため、その広告コンテンツはDASHクライアント306に戻されてよく、次に、広告ブレークの間にレンダリングするためにメディアプレーヤ/アプリケーション(たとえば、メディアエンジン304)に戻されてよい。
図15Aおよび図15Bは、本開示の技法による例示的な方法を示すシーケンス図である。図15Aおよび図15の方法は、図14のシステム300の構成要素によって実行されるが、他のシステムもこの方法を実行することができる。コンテンツおよび広告のプロビジョニングおよびMPD324のフォーマットに関して、MBMSオペレータとコンテンツプロバイダ314と広告プロバイダ318との間に取引合意が存在すると仮定する。図15Aおよび図15Bは、アプリケーション(たとえば、図2のメディアアプリケーション112または図14のメディアエンジン304)と、DASHクライアント(たとえば、図2のDASHクライアント110または図14のDASHクライアント306)と、MBMSクライアント(たとえば、図2のeMBMSミドルウェアユニット100または図14のMBMSクライアント308)と、BM-SC(たとえば、図14のBM-SC320)と、広告判定サーバ(たとえば、図14の広告判定サーバ316)と、コンテンツプロバイダ(たとえば、図14のコンテンツプロバイダ314)と、広告プロバイダ(たとえば、図14の広告プロバイダ318)とを含めて、様々な要素によって実行される活動を示す。
最初に、BM-SC320は、(MPDフラグメントを含む)USDの配信をMBMSクライアント308にブローキャストすることができる。メディアアプリケーション(たとえば、メディアエンジン304)はMPD URLをDASHクライアント306に送ることを要求することができ、DASHクライアント306は、次に、(MPDをHTTPプロキシキャッシュ312内にキャッシュすることができる)MBMSクライアント308からMPD(たとえば、MPD324)を獲得することができる。DASHクライアント306はまた、状態情報をMBMSクライアント308に渡すことができ、MBMSクライアント308は、クライアントデバイス302のユーザに関して取得されることになる広告データのセット(たとえば、広告グループ)を示し得る。DASHクライアント306は、オリジナルMPD内でシグナリングされ得るMPD@minimumUpdatePeriodに従って、MPD更新に関してポーリングすることができる。MBMSクライアント308は、次いで、後続のターゲット広告ダウンロードのために、グループ識別子、たとえば、この例では、groupID=「B」に状態情報をマッピングすることができる。
メインコンテンツの場合、DASHオーバーMBMSメディアプレゼンテーションの通常のブロードキャスト配信および消費が存在し得る。後で、広告プロバイダ318は広告をBM-SC320にプロビジョニングすることができる。BM-SC320は、上で論じたように、USDフラグメント内で配信されたスケジュールに従って、広告コンテンツファイルをブロードキャストすることができる。ターゲットgroupIDで各広告をタグ付けして、広告コンテンツ(たとえば、広告328)はリモートPeriod要素によって参照され得る。上で論じたマッピングに基づいて、MBMSクライアント308は、groupID=「B」でタグ付された広告を(HTTPプロキシキャッシュ312内に)選択的にダウンロードし、キャッシュすることができる。
判定サーバ316は、BM-SC320に、各々が、将来の時間T1におけるPeriodのstartを有する、1) http://adserver.com/ad1?id="A"、2) http://adserver.com/ad1?id="B"、および3) http://adserver.com/ad1?id="C"のBaseURLを備えたリモートPeriod要素に対応する3つのファイルを提供することができる。BM-SC320は、次いで、これらの3つのリモートPeriod要素ファイルをブロードキャストし得る。MBMSクライアント308は、上で論じたマッピングに基づいて、BaseURL http://adserver.com/ad1?id="B"と関連付けられたリモートPeriod要素だけをダウンロードし、キャッシュすることができる。BM-SC320はまた、帯域内で、メディアプレゼンテーションに関して更新されたMPDを配信することができる。
MPD最小更新期間に従って、DASHクライアント306は、MBMSクライアント308から更新されたMPDを要求することができる。更新されたMPDは、Period@xlink:href="http://adserver.com/ad1?id="B""および@xlink:actuate="onLoad"を用いてリモートPeriodをシグナリングすることができる。DASHクライアント306は、@xlink:href内に出現するURLに関するHTTP GETを発行することによって、リモートPeriod要素のデリファレンスをさらに要求することができる。MBMSクライアント308は、BaseURL=「http://adserver.com/ad1?id="B"」と関連付けられたPeriod要素を配信することができる。時間T1が近づくと、DASHクライアント306は、(セグメントをHTTPプロキシキャッシュ312内にキャッシュした)MBMSクライアント308からのリモートPeriod要素によって記述された広告コンテンツのセグメントをフェッチし、次いで、セグメントをメディアアプリケーション(たとえば、メディアエンジン304)に提供することができる。
このようにして、図15Aおよび図15Bは、DASHクライアントによって、複数の広告グループの広告メディアデータと関連付けられた広告グループ識別子のセットを決定するステップであって、広告メディアデータがメインメディアコンテンツに関する広告ブレークの間に再生される、決定するステップと、DASHクライアントに関するユーザの特性に少なくとも部分的に基づいて、そのセットから広告グループのうちの1つを選択するステップと、選択された広告グループの広告メディアデータを取り出すステップと、広告メディアデータをメディアアプリケーションに提供するステップとを含む方法の一例を表す。
同様に、図15Aおよび図15Bは、MBMSミドルウェアユニットによって、1つまたは複数の広告グループの広告メディアデータを受信するステップと、クライアントデバイスの動的適応ストリーミングオーバーHTTP(DASH)クライアントから広告グループのうちの1つに関する識別子値を受信するステップと、識別子値に対応する広告グループの広告メディアデータを抽出するステップと、抽出した広告メディアデータをDASHクライアントに提供するステップとを含む方法の一例を表す。
1つまたは複数の例において、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、1つもしくは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、またはコンピュータ可読媒体を介して送信されてよく、かつハードウェアに基づく処理ユニットによって実行されてよい。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応するコンピュータ可読記憶媒体、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む通信媒体を含むことがある。このようにして、コンピュータ可読媒体は、概して、(1)非一時的な有形コンピュータ可読記憶媒体、または(2)信号もしくは搬送波などの通信媒体に対応する場合がある。データ記憶媒体は、本開示で説明した技法を実装するための命令、コード、および/またはデータ構造を取り出すために1つまたは複数のコンピュータまたは1つまたは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であってよい。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。
限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、フラッシュメモリ、または、命令もしくはデータ構造の形式の所望のプログラムコードを記憶するために使用され、コンピュータによってアクセスされ得る任意の他の媒体を含んでもよい。また、任意の接続が、適切にコンピュータ可読媒体と呼ばれる。たとえば、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから命令が送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的な媒体を含まず、代わりに非一時的な有形記憶媒体を指すことを理解されたい。ディスク(disk)およびディスク(disc)は、本明細書において使用されるときに、コンパクトディスク(disc)(「CD」)、レーザディスク(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(「DVD」)、フロッピーディスク(disk)およびブルーレイディスク(disc)を含み、ディスク(disk)は通常、データを磁気的に再生し、一方、ディスク(disc)は、レーザを用いてデータを光学的に再生する。上記のものの組合せも、コンピュータ可読媒体の範囲内に含まれるべきである。
命令は、1つもしくは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の同等の集積またはディスクリート論理回路などの、1つまたは複数のプロセッサによって実行されてもよい。したがって、本明細書で使用される「プロセッサ」という用語は、前述の構造、または本明細書で説明する技術の実装に適した任意の他の構造のいずれかを指す場合がある。さらに、いくつかの態様では、本明細書で説明する機能は、符号化および復号のために構成された専用のハードウェアモジュールおよび/またはソフトウェアモジュール内に与えられてもよく、あるいは複合コーデックに組み込まれてもよい。また、技術は、1つまたは複数の回路または論理要素において完全に実装されてもよい。
本開示の技法は、ワイヤレスハンドセット、集積回路(IC)、またはICのセット(たとえば、チップセット)を含む、多種多様なデバイスまたは装置において実装され得る。本開示では、開示される技法を実行するように構成されたデバイスの機能的態様を強調するために、様々なコンポーネント、モジュール、またはユニットについて説明したが、それらのコンポーネント、モジュール、またはユニットは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。そうではなくて、上で説明したように、様々なユニットは、コーデックハードウェアユニットにおいて結合されてよく、または適切なソフトウェアおよび/もしくはファームウェアとともに、前述のような1つもしくは複数のプロセッサを含む、相互動作可能なハードウェアユニットの集合によって提供されてよい。
様々な例を説明してきた。これらおよび他の例は以下の特許請求の範囲内に入る。
10 システム
20 コンテンツ準備デバイス
22 オーディオソース
24 ビデオソース
26 オーディオエンコーダ
28 ビデオエンコーダ
30 カプセル化ユニット
32 出力インターフェース
40 クライアントデバイス
42 オーディオ出力
44 ビデオ出力
46 オーディオデコーダ
48 ビデオデコーダ
50 カプセル化解除ユニット
52 取出しユニット
54 ネットワークインターフェース
60 サーバデバイス
62 記憶媒体
64 マルチメディアコンテンツ
66 マニフェストファイル
68 リプレゼンテーション
68A〜68N リプレゼンテーション
70 要求処理ユニット
72 ネットワークインターフェース
74 ネットワーク
100 eMBMSミドルウェアユニット
102 プロキシサーバ
104 キャッシュ
106 eMBMS受信ユニット
110 DASHクライアント
112 メディアアプリケーション
120 マルチメディアコンテンツ
124 メディアプレゼンテーション記述(MPD)
130 リプレゼンテーション
132 ヘッダデータ
134 セグメント
134A〜134N セグメント
140 リプレゼンテーション
142 ヘッダデータ
144 セグメント
144A〜144N セグメント
150 システム
152 クライアントデバイス
154 広告(広告)判定サーバ
156 MPD生成器
158 パッケージャ
160 オリジンサーバ
162 MPD
164 MPD
166A〜166C メディアコンテンツ
168A〜168C 広告データ
170 メディアアプリケーション
172 広告管理サービス
174 DASHクライアント
176 DASHクライアント
180 コンテンツ配信システム
200 システム
202 メディアエンジン
204 DASHアクセスクライアント
206 クライアントデバイス
208 広告(広告)判定サーバ
210 XLinkレゾルバ
212 コンテンツ配信システム
214 MPD生成器
216 パッケージャ
218 コンテンツ配信ネットワーク(CDN)/オリジンサーバ
220 MPD
222A〜222C メインコンテンツ
224A〜224C 広告データ
300 システム
302 クライアントデバイス
304 メディアエンジン
306 DASHクライアント
308 MBMSクライアント
310 XLinkレゾルバ
312 HTTPプロキシキャッシュ
314 コンテンツプロバイダ
316 広告判定サーバ
318 広告プロバイダ
320 ブロードキャストマルチキャストサービスセンター(BM-SC)
322 USBD
324 MPD
326 コンテンツ
326A〜326C コンテンツ
328 広告
328A〜328C 広告

Claims (29)

  1. 動的適応ストリーミングオーバーHTTP(DASH)クライアントによって、メディアデータを取り出す方法であって、
    複数の広告グループの広告メディアデータと関連付けられた広告グループ識別子のセットを決定するステップであって、前記広告メディアデータが、メインメディアコンテンツに関する広告ブレークの間に再生され、前記メインメディアコンテンツがマニフェストファイルと関連付けられる、決定するステップと、
    前記マニフェストファイルに対する更新を取り出すステップであって、前記更新が、前記広告メディアデータに対応するリモートPeriodを定義し、前記マニフェストファイルに対する前記更新が、識別子属性を含む拡張マークアップ言語(XML)リンク付け言語(XLink)ユニフォームリソースロケータ(URL)に関するテンプレートを特定する、取り出すステップと、
    前記DASHクライアントに関するユーザの特性に少なくとも部分的に基づいて、前記セットから前記広告グループのうちの1つを選択するステップと、
    前記テンプレートに従って、前記選択された広告グループに対応する識別子値を前記XLink URLの前記識別子属性に割り当てるステップと、
    前記リモートPeriodから前記選択された広告グループの広告メディアデータを取り出すために、前記選択された広告グループに対応する前記識別子値を含む前記XLink URLをデリファレンスするステップと、
    前記広告メディアデータをメディアアプリケーションに提供するステップと
    を含む、方法。
  2. 前記DASHクライアントがクライアントデバイス内に含まれ、前記XLink URLをデリファレンスするステップが、前記識別子値を含む前記XLink URLを指定する要求を前記クライアントデバイスのマルチメディアブロードキャストマルチキャストサービス(MBMS)クライアントに送るステップを含む、請求項1に記載の方法。
  3. 前記DASHクライアントがクライアントデバイス内に含まれ、前記方法が、前記クライアントデバイスのマルチメディアブロードキャストマルチキャストサービス(MBMS)クライアントによって、
    前記DASHクライアントからの前記識別子値を含む前記XLink URLを受信するステップと、
    ブロードキャストトランスポートまたはマルチキャストトランスポートを介して、前記リモートPeriodに関するデータを受信するステップと、
    前記ブロードキャストトランスポートまたは前記マルチキャストトランスポートに関するファイル配信テーブル(FDT)が前記XLink URLの前記識別子値と整合する識別子値を含むとき、前記リモートPeriodに関する前記データが前記XLink URLと整合すると決定するステップと、
    前記リモートPeriodに関する前記データが前記XLink URLと整合すると決定することに応答して、前記リモートPeriodに関する前記データを前記DASHクライアントに配信するステップと
    をさらに含む、請求項1に記載の方法。
  4. 前記リモートPeriodに関する前記データを受信するステップが、前記広告グループの各々に関するデータを受信するステップを含む、請求項3に記載の方法。
  5. 前記リモートPeriodに関する前記データを受信するステップが、前記XLink URLの前記識別子値に対応する前記広告グループ以外の前記広告グループのすべてに関するデータを廃棄するステップを含む、請求項3に記載の方法。
  6. 前記DASHクライアントがクライアントデバイス内に含まれ、前記方法が、前記クライアントデバイスのマルチメディアブロードキャストマルチキャストサービス(MBMS)クライアントによって、
    前記DASHクライアントからの前記識別子値を含む前記XLink URLを受信するステップと、
    ブロードキャストトランスポートまたはマルチキャストトランスポートを介して、前記リモートPeriodに関するデータを受信するステップと、
    フィルタ記述フラグメントのgroupIDFilterシンタックス要素の値が前記XLink URLの前記識別子値に対応するとき、前記リモートPeriodに関する前記データが前記XLink URLと整合すると決定するステップと、
    前記リモートPeriodに関する前記データが前記XLinkと整合すると決定することに応答して、前記リモートPeriodに関する前記データを前記DASHクライアントに配信するステップと
    をさらに含む、請求項1に記載の方法。
  7. 前記取り出すステップが、
    マニフェストファイル更新期間を定義するデータを取得するステップ
    を含み、
    前記更新を取り出すステップが、前記マニフェストファイル更新期間に従って、前記更新を取り出すステップを含む、請求項1に記載の方法。
  8. 前記マニフェストファイル更新期間を定義する前記データが、前記マニフェストファイルのMPD@minimumUpdatePeriod要素を含む、請求項7に記載の方法。
  9. 前記マニフェストファイルがメディアプレゼンテーション記述を含む、請求項1に記載の方法。
  10. 前記DASHクライアントがクライアントデバイス内に含まれ、前記方法が、
    前記DASHクライアントによって、前記ユーザまたは前記デバイスに関連する状態情報を前記クライアントデバイスのマルチメディアブロードキャストマルチキャストサービス(MBMS)クライアントに提供するステップと、
    前記MBMSクライアントによって、ブロードキャストトランスポートまたはマルチキャストトランスポートを介して、前記広告メディアデータを受信するステップと、
    前記MBMSクライアントによって、前記状態情報を一意の広告グループ識別子にマッピングするステップと
    をさらに含む、請求項1に記載の方法。
  11. 前記状態情報が、クッキー、加入情報、ユーザプリファレンス&プロファイル(UP/P)、および使用履歴のうちの1つまたは複数を含む、請求項10に記載の方法。
  12. 選択するステップが、ユーザプリファレンスおよびプロファイルデータ、コンテンツ消費履歴、または広告推奨エンジンのうちの少なくとも1つに基づいて選択するステップを含む、請求項1に記載の方法。
  13. クライアントデバイスのマルチメディアブロードキャストマルチキャストサービス(MBMS)クライアントによって、メディアデータを取り出す方法であって、
    1つまたは複数の広告グループの広告メディアデータを受信するステップと、
    前記クライアントデバイスの動的適応ストリーミングオーバーHTTP(DASH)クライアントから前記広告グループのうちの1つに関する識別子値を含む拡張マークアップ言語(XML)リンク付け言語(Xlink)ユニフォームリソースロケータ(URL)を受信するステップと、
    前記識別子値に対応する前記広告グループの前記広告メディアデータを抽出するステップと、
    前記抽出した広告メディアデータを前記DASHクライアントに提供するステップと
    を含む、方法。
  14. 前記識別子値を受信するステップが、前記DASHクライアントから、前記クライアントデバイスに関する状態情報を受信するステップを含む、請求項13に記載の方法。
  15. 前記状態情報が、クッキー、加入情報、ユーザプリファレンス&プロファイル(UP/P)、および使用履歴のうちの1つまたは複数を含む、請求項14に記載の方法。
  16. 実行されると、クライアントデバイスのプロセッサに、
    複数の広告グループの広告メディアデータと関連付けられた広告グループ識別子のセットを決定することであって、前記広告メディアデータが、メインメディアコンテンツに関する広告ブレークの間に再生され、前記メインメディアコンテンツがマニフェストファイルと関連付けられる、決定することと、
    前記マニフェストファイルに対する更新を取り出すことであって、前記更新が、前記広告メディアデータに対応するリモートPeriodを定義し、前記マニフェストファイルに対する前記更新が、識別子属性を含む拡張マークアップ言語(XML)リンク付け言語(XLink)ユニフォームリソースロケータ(URL)に関するテンプレートを特定する、取り出すことと、
    前記クライアントデバイスのユーザの特性に少なくとも部分的に基づいて、前記セットから前記広告グループのうちの1つを選択することと、
    前記テンプレートに従って、前記選択された広告グループに対応する識別子値を前記XLink URLの前記識別子属性に割り当てることと、
    前記リモートPeriodから前記選択された広告グループの広告メディアデータを取り出すために、前記選択された広告グループに対応する前記識別子値を含む前記XLink URLをデリファレンスすることと、
    前記広告メディアデータをメディアアプリケーションに提供することと
    を行わせる命令を記憶したコンピュータ可読記憶媒体。
  17. 前記プロセッサに前記XLink URLをデリファレンスさせる前記命令が、前記プロセッサに、前記識別子値を含む前記XLink URLを指定する要求を前記クライアントデバイスのマルチメディアブロードキャストマルチキャストサービス(MBMS)クライアントに送らせる命令を含む、請求項16に記載のコンピュータ可読記憶媒体。
  18. 前記命令が、動的適応ストリーミングオーバーHTTP(DASH)クライアントに関し、マルチメディアブロードキャストマルチキャストサービス(MBMS)クライアントに関する命令をさらに含み、前記MBMSクライアントに関する前記前記命令が、前記プロセッサに、
    前記DASHクライアントからの前記識別子値を含む前記XLink URLを受信させ、
    ブロードキャストトランスポートまたはマルチキャストトランスポートを介して、前記リモートPeriodに関するデータを受信させ、
    前記ブロードキャストトランスポートまたは前記マルチキャストトランスポートに関するファイル配信テーブル(FDT)が前記XLink URLの前記識別子値と整合する識別子値を含むとき、前記リモートPeriodに関する前記データが前記XLink URLと整合すると決定させ、
    前記リモートPeriodに関する前記データが前記XLink URLと整合すると決定することに応答して、前記リモートPeriodに関する前記データを配信させる、請求項16に記載のコンピュータ可読記憶媒体。
  19. 前記プロセッサに、前記リモートPeriodに関する前記データを受信させる前記命令が、前記プロセッサに、前記広告グループの各々に関するデータを受信させる命令を含む、請求項18に記載のコンピュータ可読記憶媒体。
  20. 前記プロセッサに、前記リモートPeriodに関する前記データを受信させる前記命令が、前記プロセッサに、前記XLink URLの前記識別子値に対応する前記広告グループ以外の前記広告グループのすべてに関するデータを廃棄させる命令を含む、請求項18に記載のコンピュータ可読記憶媒体。
  21. 前記クライアントデバイスのマルチメディアブロードキャストマルチキャストサービス(MBMS)に、
    前記DASHクライアントからの前記識別子値を含む前記XLink URLを受信させ、
    ブロードキャストトランスポートまたはマルチキャストトランスポートを介して、前記リモートPeriodに関するデータを受信させ、
    フィルタ記述フラグメントのgroupIDFilterシンタックス要素の値が前記XLink URLの前記識別子値に対応するとき、前記リモートPeriodに関する前記データが前記XLink URLと整合すると決定させ、
    前記リモートPeriodに関する前記データが前記XLink URLと整合すると決定することに応答して、前記リモートPeriodに関する前記データを前記DASHクライアントに配信させる
    命令をさらに含む、請求項16に記載のコンピュータ可読記憶媒体。
  22. 前記プロセッサに、前記更新を取り出させる前記命令が、前記プロセッサに、マニフェストファイル更新期間を定義するデータを取得させる命令を含み、前記プロセッサに前記更新を取り出させる前記命令が、前記プロセッサに、前記マニフェストファイル更新期間に従って、前記更新を取り出させる命令を含む、請求項16に記載のコンピュータ可読記憶媒体。
  23. 前記マニフェストファイル更新期間を定義する前記データが、前記マニフェストファイルのMPD@minimumUpdatePeriod要素を含む、請求項22に記載のコンピュータ可読記憶媒体。
  24. 前記マニフェストファイルがメディアプレゼンテーション記述を含む、請求項16に記載のコンピュータ可読記憶媒体。
  25. クライアントデバイスのマルチメディアブロードキャストマルチキャストサービス(MBMS)クライアントによって、メディアデータを取り出す方法であって、
    前記クライアントデバイスの動的適応ストリーミングオーバーHTTP(DASH)クライアントから広告メディアデータに対応するリモートPeriodに関する識別子属性を含む拡張マークアップ言語(XML)リンク付け言語(Xlink)ユニフォームリソースロケータ(URL)を受信するステップと、
    ブロードキャストトランスポートまたはマルチキャストトランスポートを介して、前記リモートPeriodに関するデータを受信するステップと、
    前記ブロードキャストトランスポートまたは前記マルチキャストトランスポートのデータが前記XLink URLの前記識別子値と整合する識別子値を含むとき、前記リモートPeriodに関する前記データが前記XLink URLと整合すると決定するステップと、
    前記リモートPeriodに関する前記データが前記XLink URLと整合すると決定することに応答して、前記リモートPeriodに関する前記データを前記DASHクライアントに配信するステップと
    を含む、方法。
  26. 識別子値を含む前記データが、前記ブロードキャストトランスポートまたは前記マルチキャストトランスポートに関するファイル配信テーブル(FDT)を含む、請求項25に記載の方法。
  27. 前記識別子値を含む前記データが、groupIDFilterシンタックス要素を含むフィルタ記述フラグメントを含む、請求項25に記載の方法。
  28. 前記リモートPeriodに関する前記データを受信するステップが、複数の広告グループの各々に関するデータを受信するステップを含む、請求項25に記載の方法。
  29. 前記リモートPeriodに関する前記データを受信するステップが、前記XLink URLの前記識別子値に対応する前記広告グループ以外の前記広告グループに関するデータを廃棄するステップを含む、請求項25に記載の方法。
JP2016558191A 2014-03-24 2015-03-24 メディアデータをストリーミングするためのターゲット広告挿入 Expired - Fee Related JP6612249B2 (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201461969707P 2014-03-24 2014-03-24
US61/969,707 2014-03-24
US201461973063P 2014-03-31 2014-03-31
US61/973,063 2014-03-31
US14/665,500 2015-03-23
US14/665,500 US10902474B2 (en) 2014-03-24 2015-03-23 Targeted advertisement insertion for streaming media data
PCT/US2015/022257 WO2015148513A1 (en) 2014-03-24 2015-03-24 Targeted advertisement insertion for streaming media data

Publications (3)

Publication Number Publication Date
JP2017517167A true JP2017517167A (ja) 2017-06-22
JP2017517167A5 JP2017517167A5 (ja) 2018-04-19
JP6612249B2 JP6612249B2 (ja) 2019-11-27

Family

ID=54142548

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016558191A Expired - Fee Related JP6612249B2 (ja) 2014-03-24 2015-03-24 メディアデータをストリーミングするためのターゲット広告挿入

Country Status (6)

Country Link
US (1) US10902474B2 (ja)
EP (1) EP3123734A1 (ja)
JP (1) JP6612249B2 (ja)
CN (1) CN106165434B (ja)
BR (1) BR112016022201B1 (ja)
WO (1) WO2015148513A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018050332A (ja) * 2013-09-17 2018-03-29 インテル アイピー コーポレイション 目標メディアコンテンツの配信
JP7442919B2 (ja) 2020-04-07 2024-03-05 テンセント・アメリカ・エルエルシー データ操作のためのパッチ可能なリモート要素方法、装置、およびコンピュータプログラム

Families Citing this family (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2015218353A1 (en) 2014-02-14 2016-09-01 Pluto Inc. Methods and systems for generating and providing program guides and content
CN105095216A (zh) * 2014-04-22 2015-11-25 深圳市志友企业发展促进中心 一种数据组装方法、装置及资源传播系统
US20160094986A1 (en) * 2014-09-29 2016-03-31 Sprint Communications Company L.P. Content delivery metadata exchange in wireless communication systems
US10045058B2 (en) * 2014-10-23 2018-08-07 At&T Intellectual Property I, L.P. Method and apparatus to deliver a personalized media experience
KR101740451B1 (ko) * 2014-12-10 2017-05-26 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US20170272691A1 (en) * 2014-12-22 2017-09-21 Lg Electronics Inc. Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method
KR101995197B1 (ko) 2015-03-02 2019-09-30 닛본 덴끼 가부시끼가이샤 디코딩 장치, 수신기기, 송신기기, 송수신 시스템, 디코딩 방법, 및 디코딩 프로그램이 저장된 저장매체
WO2016199513A1 (ja) 2015-06-09 2016-12-15 ソニー株式会社 受信装置、送信装置、およびデータ処理方法
CN112019884B (zh) 2015-07-06 2022-04-19 Lg电子株式会社 发送广播信号的方法和设备及接收广播信号的方法和设备
CN107925583B (zh) * 2015-07-08 2022-01-28 康维达无线有限责任公司 服务层任播和些播
WO2017102021A1 (en) * 2015-12-18 2017-06-22 Telefonaktiebolaget Lm Ericsson (Publ) Handling of content delivery in a client node
WO2017133659A1 (en) * 2016-02-03 2017-08-10 Mediatek Inc. Method and system of push-template and url list for dash on full-duplex protocols
US9942577B1 (en) * 2016-02-23 2018-04-10 Amazon Technologies, Inc. Dynamic objects caching for media content playback
US11038938B2 (en) * 2016-04-25 2021-06-15 Time Warner Cable Enterprises Llc Methods and apparatus for providing alternative content
US11039181B1 (en) 2016-05-09 2021-06-15 Google Llc Method and apparatus for secure video manifest/playlist generation and playback
US11069378B1 (en) 2016-05-10 2021-07-20 Google Llc Method and apparatus for frame accurate high resolution video editing in cloud using live video streams
US10785508B2 (en) * 2016-05-10 2020-09-22 Google Llc System for measuring video playback events using a server generated manifest/playlist
US10595054B2 (en) 2016-05-10 2020-03-17 Google Llc Method and apparatus for a virtual online video channel
US10771824B1 (en) 2016-05-10 2020-09-08 Google Llc System for managing video playback using a server generated manifest/playlist
US11032588B2 (en) 2016-05-16 2021-06-08 Google Llc Method and apparatus for spatial enhanced adaptive bitrate live streaming for 360 degree video playback
US9872049B1 (en) * 2016-06-30 2018-01-16 SnifferCat, Inc. Systems and methods for dynamic stitching of advertisements
EP3520062B1 (en) * 2016-09-29 2023-08-23 Jio Platforms Limited Systems and methods for providing targeted content in an embms stream to a user device
CN109937575B (zh) * 2016-12-30 2022-04-01 谷歌有限责任公司 中断经不可侵犯清单协议提供的流传输内容的系统和方法
US9872062B1 (en) * 2017-02-22 2018-01-16 Wyse Technology L.L.C. Enforcing synchronization by embedding audio within video frame data
US11062497B2 (en) * 2017-07-17 2021-07-13 At&T Intellectual Property I, L.P. Structuralized creation and transmission of personalized audiovisual data
CN109792394B (zh) * 2017-08-15 2021-05-11 谷歌有限责任公司 使用多播的流式带宽的优化利用
CN110663039B (zh) * 2017-08-16 2023-08-15 谷歌有限责任公司 动态内容加载选择的方法和系统
WO2019069326A1 (en) * 2017-10-06 2019-04-11 Nilesh Suryawanshi METHOD AND APPARATUS FOR REPLACING ADVERTISING BY EXTRACTING METADATA
US11310540B2 (en) * 2017-11-10 2022-04-19 Qualcomm Incorporated Interfaces between dash aware application and dash client for service interactivity support
CN108122198A (zh) * 2017-12-07 2018-06-05 北京奇虎科技有限公司 一种在视频中融合推荐内容的实现方法、装置和服务器
CN108040267A (zh) * 2017-12-07 2018-05-15 北京奇虎科技有限公司 一种在视频中融合推荐内容的方法和装置
US20190238950A1 (en) * 2018-01-31 2019-08-01 Qualcomm Incorporated Dynamic conditional advertisement insertion
US10938872B2 (en) * 2018-03-12 2021-03-02 Qualcomm Incorporated Processing interactivity events for streaming media data
US11533527B2 (en) 2018-05-09 2022-12-20 Pluto Inc. Methods and systems for generating and providing program guides and content
EP3791599B1 (en) 2018-05-09 2024-03-20 Pluto Inc. Methods and systems for generating and providing program guides and content
US11514532B1 (en) 2018-06-12 2022-11-29 United Services Automobile Association (Usaa) Transaction data transfer management
US10951960B1 (en) * 2018-07-17 2021-03-16 Amazon Technologies, Inc. Dynamic content insertion
US10965966B1 (en) * 2018-07-17 2021-03-30 Amazon Technologies, Inc. Dynamic content insertion
US11184665B2 (en) 2018-10-03 2021-11-23 Qualcomm Incorporated Initialization set for network streaming of media data
US20200112753A1 (en) * 2018-10-03 2020-04-09 Qualcomm Incorporated Service description for streaming media data
WO2020125783A1 (zh) * 2018-12-20 2020-06-25 青岛海信电器股份有限公司 广播信号接收装置以及广播信号接收方法
US11356715B2 (en) * 2018-12-28 2022-06-07 Tencent America LLC Dynamic shortening of advertisement duration during live streaming
US11144956B1 (en) * 2019-02-14 2021-10-12 Amazon Technologies, Inc. Targeted media delivery based on previous consumer interactions
FR3094167B1 (fr) 2019-03-18 2021-04-23 Ateme Procédé de gestion de contenus multimédia et dispositif pour la mise en œuvre du procédé
US10986382B2 (en) 2019-06-07 2021-04-20 The Nielsen Company (Us), Llc Content-modification system with system resource request feature
US11509972B2 (en) * 2019-07-09 2022-11-22 Dolby International Ab Method and device for personalization of media data for playback
US11178433B2 (en) * 2019-11-21 2021-11-16 Pluto Inc. Methods and systems for dynamic routing of content using a static playlist manifest
US11765421B2 (en) 2020-02-28 2023-09-19 Hulu, LLC Client based storage of remote element resolutions
CN115136611A (zh) * 2020-02-28 2022-09-30 葫芦有限责任公司 用于动态元素替换的组中元素的标识
WO2022165066A1 (en) * 2021-01-27 2022-08-04 Arris Enterprises Llc Systems and methods for delay manifests in abr content delivery
US11799943B2 (en) * 2021-10-06 2023-10-24 Tencent America LLC Method and apparatus for supporting preroll and midroll during media streaming and playback
US11973820B2 (en) * 2021-10-06 2024-04-30 Tencent America LLC Method and apparatus for mpeg dash to support preroll and midroll content during media playback
US11509946B1 (en) 2021-11-08 2022-11-22 Pluto Inc. Methods and systems configured to manage video transcoder latencies

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012138909A1 (en) * 2011-04-05 2012-10-11 Qualcomm Incorporated Ip broadcast streaming services distribution using file delivery methods
WO2013036451A1 (en) * 2011-09-07 2013-03-14 Qualcomm Incorporated Streaming of multimedia data from multiple sources
WO2014011097A1 (en) * 2012-07-09 2014-01-16 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for distributing information during broadcast delivery

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7739708B2 (en) 2005-07-29 2010-06-15 Yahoo! Inc. System and method for revenue based advertisement placement
KR101599743B1 (ko) 2009-04-21 2016-03-16 삼성전자주식회사 휴대 방송망을 이용한 휴대 광고 제공 장치, 방법 및 광고 서버 그리고 그 시스템
US8621520B2 (en) 2009-05-19 2013-12-31 Qualcomm Incorporated Delivery of selective content to client applications by mobile broadcast device with content filtering capability
US8849950B2 (en) 2011-04-07 2014-09-30 Qualcomm Incorporated Network streaming of video data using byte range requests
US20150149279A1 (en) * 2013-11-22 2015-05-28 Cellco Partnership D/B/A Verizon Wireless Targeted advertising for broadcasted content

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012138909A1 (en) * 2011-04-05 2012-10-11 Qualcomm Incorporated Ip broadcast streaming services distribution using file delivery methods
WO2013036451A1 (en) * 2011-09-07 2013-03-14 Qualcomm Incorporated Streaming of multimedia data from multiple sources
WO2014011097A1 (en) * 2012-07-09 2014-01-16 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for distributing information during broadcast delivery

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
AD INSERTION IN DASH ARCHITECTURES AND GUDELINES, JPN5017003915, 7 January 2014 (2014-01-07) *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018050332A (ja) * 2013-09-17 2018-03-29 インテル アイピー コーポレイション 目標メディアコンテンツの配信
JP7442919B2 (ja) 2020-04-07 2024-03-05 テンセント・アメリカ・エルエルシー データ操作のためのパッチ可能なリモート要素方法、装置、およびコンピュータプログラム

Also Published As

Publication number Publication date
JP6612249B2 (ja) 2019-11-27
BR112016022201A8 (pt) 2021-07-13
BR112016022201A2 (pt) 2017-08-15
US10902474B2 (en) 2021-01-26
WO2015148513A1 (en) 2015-10-01
CN106165434A (zh) 2016-11-23
BR112016022201B1 (pt) 2023-12-12
CN106165434B (zh) 2019-10-18
EP3123734A1 (en) 2017-02-01
US20150269629A1 (en) 2015-09-24

Similar Documents

Publication Publication Date Title
JP6612249B2 (ja) メディアデータをストリーミングするためのターゲット広告挿入
US10193994B2 (en) Signaling cached segments for broadcast
JP6545804B2 (ja) オーバージエアブロードキャストメディアデータに関するセッション記述情報
JP6770000B2 (ja) ＤＡＳＨクライアントＱｏＥメトリックのミドルウェア配信
JP6474830B2 (ja) 連続的マルチピリオドコンテンツ処理
US11290755B2 (en) Signaling data for prefetching support for streaming media data
JP5932070B2 (ja) コード化ビデオデータのネットワークストリーミングのためのメディア表現グループ
US11617019B2 (en) Retrieving and accessing segment chunks for media streaming
CN111837403B (zh) 处理用于以流传送媒体数据的交互性事件
US20160337424A1 (en) Transferring media data using a websocket subprotocol
US11321516B2 (en) Processing dynamic web content of an ISO BMFF web resource track
US20180176278A1 (en) Detecting and signaling new initialization segments during manifest-file-free media streaming
US11184665B2 (en) Initialization set for network streaming of media data
KR20160138044A (ko) 미디어 데이터를 스트리밍하기 위한 목표된 광고 삽입
US20210306703A1 (en) Determination of availability of chunks of data for network streaming media data
JP2024503647A (ja) メディアデータのバックグラウンドデータトラフィック配信
US20210344992A1 (en) Calculating start time availability for streamed media data

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180307

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180307

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20181207

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20181217

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190130

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20190610

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190717

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20190725

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190930

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20191030

R150 Certificate of patent or registration of utility model

Ref document number: 6612249

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees