JPWO2017047433A1 - 送信装置、受信装置、およびデータ処理方法 - Google Patents

送信装置、受信装置、およびデータ処理方法 Download PDF

Info

Publication number
JPWO2017047433A1
JPWO2017047433A1 JP2017539841A JP2017539841A JPWO2017047433A1 JP WO2017047433 A1 JPWO2017047433 A1 JP WO2017047433A1 JP 2017539841 A JP2017539841 A JP 2017539841A JP 2017539841 A JP2017539841 A JP 2017539841A JP WO2017047433 A1 JPWO2017047433 A1 JP WO2017047433A1
Authority
JP
Japan
Prior art keywords
advertisement
content
data
information
transmission
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.)
Abandoned
Application number
JP2017539841A
Other languages
English (en)
Inventor
五十嵐 卓也
卓也 五十嵐
山岸 靖明
靖明 山岸
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
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 Sony Corp filed Critical Sony Corp
Publication of JPWO2017047433A1 publication Critical patent/JPWO2017047433A1/ja
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management 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/266Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2668Creating a channel for a dedicated end-user group, e.g. insertion of targeted commercials based on end-user profiles
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614Multiplexing of additional data and video streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management 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/262Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management 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/262Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26208Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
    • H04N21/26241Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints involving the time of distribution, e.g. the best time of the day for inserting an advertisement or airing a children program
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management 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/262Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing 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/433Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing 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/433Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4331Caching operations, e.g. of an advertisement for later insertion during playback
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45Management 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/4508Management of client data or end-user data
    • H04N21/4532Management of client data or end-user data involving end-user characteristics, e.g. viewer profile, preferences
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45Management 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/458Scheduling content for creating a personalised stream, e.g. by combining a locally stored advertisement with an incoming stream; Updating operations, e.g. for OS modules ; time-related management operations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45Management 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/462Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4621Controlling the complexity of the content stream or additional data, e.g. lowering the resolution or bit-rate of the video stream for a mobile client with a small screen
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45Management 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/462Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/475End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81Monomedia components thereof
    • H04N21/812Monomedia components thereof involving advertisement data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management 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/262Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26208Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
    • H04N21/26216Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints involving the channel capacity, e.g. network bandwidth
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/475End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data
    • H04N21/4751End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data for defining user accounts, e.g. accounts for children
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/475End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data
    • H04N21/4753End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data for user identification, e.g. by entering a PIN or password
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/475End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data
    • H04N21/4755End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data for defining user preferences, e.g. favourite actors or genre

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

選択出力可能な広告について送信順を制御し、受信装置において視聴可能性の高い広告の受信と再生可能性を高めた構成を実現する。送信装置が、受信装置における所定期間の広告出力時間に選択出力可能な複数の広告コンテンツの送信順を決定して送信する。視聴可能性の高い広告の送信時間を広告出力時間に最も近い時間とし、視聴可能性の低い広告の送信時間を視聴可能性の高いコンテンツの送信時間より前に設定して送信する。さらに、広告コンテンツの各々に対応する配信優先度情報(Delivery Priority)を受信装置に送信し、受信装置において、優先度情報に基づくキャッシュ処理の要否判定を実行可能とした。

Description

本開示は、送信装置、受信装置、およびデータ処理方法に関する。さらに詳細には例えば放送波やネットワークを介したデータの送信または受信を実行する送信装置、受信装置、および通信データ対応のデータ処理方法に関する。
画像データや音声データ等のコンテンツを各通信事業者のサービス形態に関わらず配信可能としたデータ配信方式としてOTT(Over The Top)がある。OTTによる配信コンテンツはOTTコンテンツと呼ばれ、また、OTTを利用した画像(ビデオ)データの配信サービスはOTTビデオやOTT−V(Over The Top Video)と呼ばれる。
OTT−Vに従ったデータストリーミング配信規格としてDASH(Dynamic Adaptive Streaming overHTTP)規格がある。DASHは、HTTP(HyperText Transfer Protocol)をベースとしたストリーミングプロトコルを用いたアダプティブ(適応型)ストリーミング配信に関する規格である。
アダプティブ(適応型)ストリーミングでは、放送局等のコンテンツ配信サーバは、データ配信先となる様々なクライアントにおいてコンテンツ再生を可能とするため、複数のビットレートの動画コンテンツの細分化ファイルとこれらの属性情報やURL(Uniform Resource Locator)を記述したマニフェスト・ファイルを作成し、クライアントに提供する。
クライアントは、マニフェスト・ファイルをサーバから取得して、自装置の表示部のサイズや利用可能な通信帯域に応じた最適なビットレートコンテンツを選択し、選択コンテンツを受信して再生する。ネットワーク帯域の変動に応じてビットレートの動的な変更も可能であり、クライアント側では、状況に応じた最適なコンテンツを随時切り替えて受信することが可能となり、映像途切れの発生を低減した動画コンテンツ再生が実現される。なお、アダプティブ(適応型)ストリーミングについては、例えば特許文献1(特開2011−87103号公報)に記載がある。
放送局やその他のコンテンツサーバ等の送信装置から、テレビ、PC、携帯端末等の受信装置に対して、放送波等による一方向通信、あるいは、インターネット等のネットワークを介した双方向通信、一方向通信を用いて放送番組等のコンテンツを送受信するシステムについての開発や規格化が、現在、盛んに進められている。
なお、放送波およびネットワークを介したデータ配信を実現するための技術を開示した従来技術として、例えば特許文献2(特開2014−057227号公報)がある。
放送波およびネットワークを介したデータ配信システムに関する規格として、現在、ATSC(Advanced Television System Committe)3.0の規格化が進行中である。
ATSC3.0では、ATSC3.0準拠物理層(ATSC−PHY)を実装した放送配信用デバイス(受信装置)上に、ATSC3.0放送の受信処理等を実行するミドルウェアを実装させることで、ATSC放送用の制御情報等を含むシグナリングデータを受信して、シグナリングデータによる様々な制御を可能とする構成を検討している。
具体的には、シグナリングデータによる制御によって、インターネット等で利用されているアプリケーションプログラム、いわゆるクライアントアプリケーションをそのまま利用して、放送コンテンツの出力処理や、放送波等によって提供される様々なアプリケーションを利用したデータ処理を実現可能とする構成を検討している。
例えば、家庭内やホットスポットに設置された放送サービスを受信するサーバ(専用サーバの他、PC、TV、タブレット、スマホ等)にATSC3.0準拠物理層(ATSC−PHY)、ならびに、ATSC3.0放送受信ミドルウェアを実装する。
これらのサーバが、いったんATSC3.0放送サービスを受信した後、ネットワーク(ホームネットワークやホットスポット等のLAN/WiFi等)を介して、ユーザ装置(PC、TV、タブレット、スマホ等)に放送受信データを転送する。
サーバを介して転送された放送受信データを入力したユーザ装置は、ユーザ装置の再生制御部やアプリケーション制御部上で稼働するアプリケーション(例えばATSC3.0 DASHクライアントアプリケーション)を利用して、放送コンテンツの再生や、放送で配信される様々なアプリケーションを実行することが可能となる。
さらに、国際標準仕様策定団体である3GPP(Third Generation Partnership Project)や、アダプティブ(適応型)ストリーミング技術の規格であるMPEG−DASH規格の規格化団体であるDASH−IFにおいては広告コンテンツの配信、再生構成についての規格化を進めている。
具体的には、例えば、受信装置側の視聴ユーザに応じて、各受信装置に出力する広告を動的に変更する構成等についての規格化を進めている。
ただし、この構成を実現する構成については、まだ、具体化されていないというのが現状である。
特開2011−87103号公報 特開2014−057227号公報
本開示は、例えば上記問題点に鑑みてなされたものであり、放送番組等を受信し、再生する受信装置において、受信装置側のユーザに応じた広告等、ユーザ対応コンテンツの選択的出力を可能とする送信装置、受信装置、およびデータ処理方法を提供することを目的とする。
本開示の第1の側面は、
受信装置における所定期間のコンテンツ出力時間に選択出力可能な複数コンテンツを送信する通信部と、
前記複数コンテンツの送信順を決定するデータ処理部を有し、
前記データ処理部は、
視聴可能性の高いコンテンツの送信時間を前記コンテンツ出力時間に最も近い時間とし、視聴可能性の低いコンテンツの送信時間を前記視聴可能性の高いコンテンツの送信時間より前に設定する送信順決定処理を実行する送信装置にある。
さらに、本開示の第2の側面は、
所定期間のコンテンツ出力時間に選択出力可能な複数コンテンツを受信し、キャッシュ部に格納するデータ処理部を有し、
前記データ処理部は、
前記複数コンテンツの各々に対応して設定された配信優先度情報(Delivery Priority)を取得し、
取得した配信優先度情報(Delivery Priority)に従い、配信優先度情報(Delivery Priority)の設定値の高いコンテンツを優先して受信し、キャッシュ部に格納する受信装置にある。
さらに、本開示の第3の側面は、
送信装置において実行するデータ処理方法であり、
データ処理部が、受信装置における所定期間のコンテンツ出力時間に選択出力可能な複数コンテンツの送信順を決定して送信する処理を実行し、
前記データ処理部は、
視聴可能性の高いコンテンツの送信時間を前記コンテンツ出力時間に最も近い時間とし、視聴可能性の低いコンテンツの送信時間を前記視聴可能性の高いコンテンツの送信時間より前に設定する送信順決定処理を実行するデータ処理方法にある。
さらに、本開示の第4の側面は、
受信装置において実行するデータ処理方法であり、
データ処理部が、所定期間のコンテンツ出力時間に選択出力可能な複数コンテンツを受信し、キャッシュ部に格納する処理を実行し、
前記データ処理部は、
前記複数コンテンツの各々に対応して設定された配信優先度情報(Delivery Priority)を取得し、
取得した配信優先度情報(Delivery Priority)に従い、配信優先度情報(Delivery Priority)の設定値の高いコンテンツを優先して受信し、キャッシュ部に格納するデータ処理方法にある。
さらに、本開示の第5の側面は、
受信装置において実行されるアプリケーション制御方法であり、アプリケーション制御部が、配信されるコンテンツをキャッシュ部に格納するかの指示、ならびに、キャッシュに格納されたコンテンツを所定期間に出力するか否かを指示するAPI(Application Programing Interface)を有し、最終的に広告コンテンツを出力するか否かを、配信優先度情報のみに寄らず、アプリケーションの判断によるAPI制御によって行うアプリケーション制御方法にある。
本開示のさらに他の目的、特徴や利点は、後述する本開示の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
本開示の一実施例の構成によれば、選択出力可能な広告について送信順を制御し、受信装置において、キャッシュ格納部の容量が限られた状況でも、視聴可能性の高い広告を受信しキャッシュに格納し、特定のユーザに広告コンテンツの再生可能性を高めた構成が実現できる。
具体的には、送信装置が、受信装置における所定期間の広告出力時間に選択出力可能な複数の広告コンテンツの送信順を決定して送信する。視聴可能性の高い広告の送信時間を広告出力時間に最も近い時間とし、視聴可能性の低い広告の送信時間を視聴可能性の高いコンテンツの送信時間より前に設定して送信する。さらに、広告コンテンツの各々に対応する配信優先度情報(Delivery Priority)を受信装置に送信し、受信装置において、優先度情報に基づくキャッシュ処理の要否判定を実行可能とした。
本構成により、選択出力可能な広告について送信順を制御し、受信装置において視聴可能性の高い広告を受信し、キャッシュ格納部に格納することを可能とし、放送地域のユーザに対する広告の再生可能性を高めた構成が実現できる。
なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また付加的な効果があってもよい。
本開示の処理を実行する通信システムの一構成例について説明する図である。 送信装置の送信データについて説明する図である。 送信装置および受信装置のプロトコルスタックの例を示す図である。 ROUTE、およびFLUTEに関するプロトコルスタックを示す図である。 受信装置(クライアント)30におけるデータ出力例を説明する図である。 様々なユーザ情報を利用した出力広告の選択例について説明する図である。 受信装置の構成例について説明する図である。 受信装置の構成例について説明する図である。 MPDの構成例について説明する図である。 MPDの構成例について説明する図である。 MPDの構成例について説明する図である。 MPDの利用シーケンス例について説明する図である。 MPD内の広告対応ピリオド情報の構成例について説明する図である。 受信装置におけるアプリケーションを利用した処理例について説明する図である。 受信装置におけるアプリケーションを利用した処理例について説明する図である。 受信装置におけるアプリケーションを利用した処理例について説明する図である。 複数の広告の配信順設定例について説明する図である。 複数の広告の配信順設定例と再生可能な広告について説明する図である。 送信装置の実行する処理シーケンスについて説明するフローチャートを示す図である。 受信装置の実行する処理シーケンスについて説明するフローチャートを示す図である。 送信装置の送信する広告コンテンツに配信優先度情報(Delivery Priority)を設定した例について説明する図である。 配信優先度情報(Delivery Priority)の送信処理を実行する送信装置の実行する処理シーケンスについて説明するフローチャートを示す図である。 配信優先度情報(Delivery Priority)の受信処理を実行する受信装置の実行する処理シーケンスについて説明するフローチャートを示す図である。 異なるチャンネルを介して送信される広告コンテンツの配信時間が重複する例について説明する図である。 異なるチャンネルを介して送信される広告コンテンツの配信時間が重複する場合において、受信装置が受信するデータを選択可能とした構成例について説明する図である。 異なるチャンネルを介して送信される広告コンテンツの配信時間が重複する場合において、受信装置が受信するデータを選択可能とした構成例について説明する図である。 サービス選択優先度情報(Service Selection Priority)の送信処理を実行する送信装置の実行する処理シーケンスについて説明するフローチャートを示す図である。 サービス選択優先度情報(Service Selection Priority)の受信処理を実行する受信装置の実行する処理シーケンスについて説明するフローチャートを示す図である。 優先度情報の記録と送信処理例について説明する図である。 優先度情報の記録構成の一例について説明する図である。 優先度情報の記録構成の一例について説明する図である。 優先度情報の記録構成の一例について説明する図である。 優先度情報の記録構成の一例について説明する図である。 優先度情報の記録構成の一例について説明する図である。 優先度情報の記録構成の一例について説明する図である。 通信装置である送信装置と受信装置の構成例について説明する図である。 通信装置である送信装置と受信装置のハードウェア構成例について説明する図である。
以下、図面を参照しながら本開示の送信装置、受信装置、およびデータ処理方法の詳細について説明する。なお、説明は以下の項目に従って行なう。
1.通信システムの構成例について
2.データ通信プロトコルFLUTE、およびROUTEについて
3.送信装置と受信装置の実行する通信処理例について
4.受信装置におけるデータ出力例について
5.受信装置の構成例と処理例について
6.MPDを利用したピリオド(Period)単位のシグナリングデータについて
7.ユーザ情報に応じた広告提供処理を実行するための具体的構成例について
8.広告コンテンツの配信順の制御構成について
9.配信優先度情報(Delivery Priority)に基づく処理例について
10.サービス選択優先度情報(Service Selection Priority)を適用した処理について
11.各優先度情報の記録構成例について
12.送信装置と受信装置の構成例について
13.本開示の構成のまとめ
[1.通信システムの構成例について]
まず、図1を参照して本開示の処理を実行する通信システムの一構成例について説明する。
図1に示すように、通信システム10は、画像データや音声データ等のコンテンツを送信する通信装置である送信装置20と、送信装置20の送信するコンテンツを受信する通信装置である受信装置30を有する。
送信装置20は、具体的には、例えば、主にTV番組等を送信する放送サーバ(放送局)21や、主に広告データを送信する広告サーバ22、様々なデータを送信するデータ配信サーバ23等、様々なコンテンツ(放送番組、広告、その他のデータ)を提供する側の装置である。
一方、受信装置30は、一般ユーザのクライアント装置であり、具体的には、例えばテレビ31、PC32、携帯端末33等によって構成される。
なお、図1では、送信装置20の例として、放送サーバ(放送局)21、広告サーバ22、データ配信サーバ23を区別して記載しているが、1つのサーバが放送番組、広告、その他のデータをすべて送信する構成もある。
送信装置20と受信装置30間のデータ通信は、インターネット等のネットワークを介した双方向通信、一方向通信、あるいは、放送波等による一方向通信の少なくともいずれか、あるいは両者を利用した通信として行われる。
送信装置20から受信装置30に対するコンテンツ送信は、例えばアダプティブ(適応型)ストリーミング技術の規格であるMPEG−DASH規格に従って実行する。
MPEG−DASH規格には、以下の2つの規格が含まれる。
(a)動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル(MPD:Media Presentation Description)に関する規格、
(b)動画コンテンツ伝送用のファイル・フォーマット(セグメント・フォーマット)に関する規格、
送信装置20から、受信装置30に対するコンテンツ配信は、上記のMPEG−DASH規格に従って実行する。
送信装置20は、コンテンツデータを符号化し、符号化データおよび符号化データのメタデータを含むデータファイルを生成する。符号化処理は、例えばMPEGにおいて規定されるMP4ファイルフォーマットに従って行われる。なお、送信装置20がMP4形式のデータファイルを生成する場合の符号化データのファイルは「mdat」、メタデータは「moov」や「moof」等と呼ばれる。
送信装置20が受信装置30に提供するコンテンツは、例えば音楽データや、映画、テレビ番組、ビデオ、写真、文書、絵画および図表などの映像データや、ゲームおよびソフトウェアなど、様々なデータである。
送信装置20の送信データについて図2を参照して説明する。
MPEG−DASH規格に従ってデータ送信を実行する送信装置20は、図2に示すように、大きく分けて以下の複数種類のデータの送信を行う。
(a)シグナリングデータ50
(b)AVセグメント60
(c)その他のデータ(ESG,NRTコンテンツ等)70
AVセグメント60は、受信装置において再生する画像(Video)や、音声(Audio)データ、すなわち例えば放送局の提供する番組コンテンツ等によって構成される。例えば、上述したMP4符号化データ(mdat)や、メタデータ(moov,moof)によって構成される。なお、AVセグメントは、DASHセグメントとも呼ばれる。
一方、シグナリングデータ50は、番組表等の番組予定情報や、番組取得に必要となるアドレス情報(URL(Uniform Resource Locator)等)、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報(符号化方式など)などからなる案内情報、アプリケーション制御情報等の様々な制御情報によって構成される。
受信装置30は、このシグナリングデータ50を、再生対象となる番組コンテンツを格納したAVセグメント60の受信に先行して受信することが必要となる。
このシグナリングデータ50は、例えばXML(Extensible Markup Language)形式のデータとして送信装置20から送信される。
シグナリングデータは、随時、繰り返し送信される。例えば100msec毎など、頻繁に繰り返し送信される。
これは、受信装置(クライアント)が、いつでも、即座にシグナリングデータを取得することを可能とするためである。
クライアント(受信装置)は、随時、受信可能なシグナリングデータに基づいて、必要な番組コンテンツのアクセス用アドレスの取得や、コーデック設定処理など、番組コンテンツの受信および再生に必要な処理を遅滞なく実行することが可能となる。
その他のデータ70は、例えばESG(Electronic Service Guide)、NRTコンテンツ等が含まれる。
ESGは、電子サービスガイド(Electronic Service Guide)であり、例えば番組表等の案内情報である。
NRTコンテンツはノンリアルタイム型のコンテンツである。
NRTコンテンツには、例えば、クライアントである受信装置30のブラウザ上で実行される様々なアプリケーションファイル、動画、静止画等のデータファイル等が含まれる。
なお、NRTコンテンツの配信時間、並びにプレゼンテーション時間などのスケジュールはESGに記述される。
図2に示す以下のデータ、すなわち、
(a)シグナリングデータ50
(b)AVセグメント60
(c)その他のデータ(ESG,NRTコンテンツ等)70
これらのデータは、例えば、データ通信プロトコル:FLUTE(File Delivery over Uni−directional Transport)に従って送信される。
[2.データ通信プロトコルFLUTE、およびROUTEについて]
データ通信プロトコル:FLUTE(File Delivery over Uni−directional Transport)はマルチキャストにより伝送するコンテンツのセッション管理を行うプロトコルである。
例えば送信装置であるサーバ側で生成されるファイル(URLとバージョンで識別される)は、FLUTEプロトコルに従って、受信装置であるクライアントに送信される。
受信装置(クライアント)30は、例えば記憶部(クライアントキャッシュ)に、受信ファイルのURLおよびバージョンとファイルを対応付けて蓄積する。
同じURLでバージョンが異なるものはファイルの中身が更新されているものとみなす。FLUTEプロトコルは一方向ファイル転送制御のみを行うもので、クライアントにおけるファイルの選択的なフィルタリング機能はないが、FLUTEで転送制御するファイルをそのファイルに紐づけられるメタデータを利用して、クライアント側で取捨選択することにより、選択的なフィルタリングを実現し、ユーザの嗜好を反映したローカルキャッシュを構成・更新管理することが可能となる。
なお、メタデータは、FLUTEプロトコルに拡張して組み込むこともできるし、別途ESG(Electronic Service Guide)等のプロトコルで記述することもできる。
なお、FLUTEは、当初マルチキャストにおけるファイル転送プロトコルとして仕様化された。FLUTEは、FDTと、ALCと呼ばれるスケーラブルなファイルオブジェクトのマルチキャストプロトコル、具体的にはそのビルディングブロックであるLCTやFECコンポーネント、の組み合わせにより構成される。
従来のFLUTEは、主に非同期型のファイル転送に利用するために開発されたが、現在、放送波およびネットワークを介したデータ配信システムに関する規格化団体であるATSC(Advanced Television System Committe)において、ブロードキャストライブストリーミングにも適用しやすくするための拡張を行っている。このFLUTEの拡張仕様がROUTE(Real−Time Object Delivery over Unidirectional Transport)と呼ばれる。
放送波およびネットワークを介したデータ配信システムに関する規格の1つとして現在、標準化が進められている規格としてATSC(Advanced Television System Committe)3.0がある。このATSC3.0は、ROUTEを従来のFLUTEプロトコルに置き換えて、シグナリングデータや、ESG、あるいは非同期ファイル、同期型ストリーム等の送信に採用したスタック構成を規定している。
[3.送信装置と受信装置の実行する通信処理例について]
次に、送信装置と受信装置の実行する通信処理例について説明する。
図3は、送信装置および受信装置のプロトコルスタックの例を示す図である。
図3に示す例は、以下の2つの通信データの処理を行なうための2つのプロトコルスタックを有する。
(a)ブロードキャスト(マルチキャストも含む)通信(例えば放送型データ配信)
(b)ユニキャスト(ブロードバンド)通信(例えばHTTP型のP2P通信)
図3の左側が(a)ブロードキャスト通信(例えば放送型データ配信)に対応するプロトコルスタックである。
図3の右側が、(b)ユニキャスト(ブロードバンド)通信(例えばHTTP型のP2P通信)に対応するプロトコルスタックである。
図3左側に示す(a)ブロードキャスト通信(例えば放送型データ配信)に対応するプロトコルスタックは、下位レイヤから順に、以下のレイヤを持つ。
(1)ブロードキャスト物理レイヤ(Broadcast PHY)
(2)IPマルチキャストレイヤ(IP Multicast)
(3)UDPレイヤ
(4)ROUTE(=拡張型FLUTE)レイヤ
(5)ESG,NRTcontent,DASH(ISO BMFF)およびVideo/Audio/CC
(6)アプリケーションレイヤ(Applications(HTML5))
なお、(2)IPマルチキャストレイヤ(IP Multicast)の上位レイヤとしてシグナリング(Signaling)レイヤが設定される。
シグナリングレイヤは、先に図2を参照して説明したシグナリングデータ50の送受信に適用されるレイヤである。シグナリングデータには、番組表等の番組予定情報や、番組取得に必要となるアドレス情報(URL等)、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報(符号化方式など)などからなる案内情報、制御情報などが含まれる。
シグナリングデータは、受信装置(クライアント)が受信、再生するAVセグメントのアクセス情報や、復号処理等の受信後の処理に必要となる案内情報や制御情報を含むデータであり、送信装置から随時繰り返し送信されるデータである。
シグナリングデータには、情報に応じた様々な種類がある。具体的には、例えば、サービス単位のシグナリングデータであるUSD(ユーザサービスディスクリプション(User Service Description))がある。
USDには、様々な種類の制御情報が含まれる。代表的な制御情報として、コンテンツ(AVセグメント)に対応する様々な案内情報、制御情報を格納したマニフェスト・ファイルを持つシグナリングデータであるMPD(メディアプレゼンテーションディスクリプション(Media Presentation Description))がある。
各種のシグナリングデータは、それぞれ受信装置(クライアント)において、送信装置から送信されるAVセグメントやアプリケーション(アプリケーションプログラム)の受信、再生処理、制御処理に必要となるデータであり、例えばカテゴリ別に個別のファイル(メタファイル)として設定され、送信装置から送信される。
なお、(1)ブロードキャスト物理レイヤ(Broadcast PHY)の上位レイヤとして将来の新たなプロトコルの利用許容レイヤ(Future Extensibility)が設定されている。
(1)ブロードキャスト物理レイヤ(Broadcast PHY)は、ブロードキャスト通信を実行するための例えば放送系の通信部を制御する通信制御部によって構成される物理レイヤである。
(2)IPマルチキャストレイヤ(IP Multicast)は、IPマルチキャストに従ったデータ送受信処理を実行するレイヤである。
(3)UDPレイヤは、UDPパケットの生成、解析処理レイヤである。
(4)ROUTEレイヤは、拡張型FLUTEプロトコルであるROUTEプロトコルにしたがって転送データの格納や取り出しを行うレイヤである。
ROUTEは、FLUTEと同様、ALCと呼ばれるスケーラブルなファイルオブジェクトのマルチキャストプロトコルであり、具体的にはそのビルディングブロックであるLCTやFECコンポーネントの組み合わせにより構成される。
図4に、ROUTE、およびFLUTEに関するプロトコルスタックを示す。
(5)ESG,NRTcontent,DASH(ISO BMFF)およびVideo/Audio/CCは、ROUTEプロトコルに従って転送されるデータである。
DASH規格に従った同報型配信サービスは、MBMS(Multimedia Broadcast Multicast Service)と呼ばれる。このMBMSをLTEで効率的に実現させる方式としてeMBMS(evolved Multimedia Broadcast Multicast Service)がある。
MBMSやeMBMSは、同報型配信サービスであり、特定のエリア内に位置する受信装置である複数のユーザ端末(UE)に対して共通のベアラで一斉に同一データ、例えば映画コンテンツなどを配信するサービスである。MBMSやeMBMSに従った同報配信により、配信サービス提供エリアに位置する多数のスマホやPC、あるいはテレビ等の受信装置に、同じコンテンツを同時に提供することができる。
MBMS、およびeMBMSは、3GPPファイルフォーマット(ISO−BMFFファイル、MP4ファイル)に従ったファイルを、転送プロトコルROUTE、またはFLUTEに従ってダウンロードする処理について規定している。
先に図2を参照して説明した以下のデータ、すなわち、
(a)シグナリングデータ50
(b)AVセグメント60
(c)その他のデータ(ESG、NRTコンテンツ等)70
これらのデータの多くはROUTEプロトコル、またはFLUTEプロトコルに従って送信される。
(5)ESG,NRTcontent,DASH(ISO BMFF)およびVideo/Audio/CCは、ROUTEプロトコルに従って転送されるデータである。
ESGは、電子サービスガイド(Electronic Service Guide)であり、例えば番組表等の案内情報である。
NRTcontentはノンリアルタイム型のコンテンツである。
前述したように、NRTコンテンツには、例えば、クライアントである受信装置のブラウザ上で実行される様々なアプリケーションファイル、動画、静止画等のデータファイル等が含まれる。
Video/Audio/CCは、DASH規格に従って配信されるビデオやオーディオ等、再生対象となる実データである。
(6)アプリケーションレイヤ(Applications(HTML5))は、ROUTEプロトコルに従って転送するデータの生成、あるいは解析、その他、様々なデータの出力制御等を実行するアプリケーションレイヤであり、例えばHTML5を適用したデータ生成、解析、出力処理等を行う。
一方、図3の右側に示す、(b)ユニキャスト(ブロードバンド)通信(例えばHTTP型のP2P通信)に対応するプロトコルスタックは、下位レイヤから順に、以下のレイヤを持つ。
(1)ブロードバンド物理レイヤ(Broaband PHY)
(2)IPユニキャストレイヤ(IP Unicast)
(3)TCPレイヤ
(4)HTTPレイヤ
(5)ESG,Signaling,NRTcontent,DASH(ISO BMFF)およびVideo/Audio/CC
(6)アプリケーションレイヤ(Applications(HTML5))
(1)ブロードバンド物理レイヤ(Broaband PHY)は、ブロードバンド通信を実行する例えばネットワークカード等の通信部を制御するデバイスドライバ等の通信制御部によって構成される物理レイヤである。
(2)IPユニキャストレイヤ(IP Unicast)は、IPユニキャスト送受信処理を実行するレイヤである。
(3)HTTPレイヤは、HTTPパケットの生成、解析処理レイヤである。
この上位レイヤは、図3左側の(a)ブロードキャスト通信(例えば放送型データ配信)のスタック構成と同様である。
なお、送信装置(サーバ)20、受信装置(クライアント)30は、図3の2つの処理系、すなわち、
(a)ブロードキャスト通信(例えば放送型データ配信)
(b)ユニキャスト(ブロードバンド)通信(例えばHTTP型のP2P通信)
これら2つの通信プロトコルスタックの少なくともいずれかに従った処理を行なう。
図3に示すプロトコルスタックにおいて、ROUTE(FLUTE)に従ってマルチキャスト転送されるファイル群の属性(ファイルの識別子であるURLを含む)は、ROUTE(FLUTE)の制御ファイル内に記述することもできれば、ファイル転送セッションを記述するシグナリング(Signaling)データ中に記述することもできる。また、ファイル転送セッションのさらなる詳細属性を(エンドユーザへの提示用途にも適用可能な)ESGにより記述することもできる。
前述したように、放送波およびネットワークを介したデータ配信システムに関する規格の1つとしてATSC(Advanced Television System Committe)3.0の規格化が進められている。
ATSC3.0におけるIPベースのトランスポートスタックの標準化において、MPEG−DASHのファイルフォーマット(ISO−BMFFファイル、MP4ファイル)に基づくファイルをFLUTE(File Delivery over Unidirectional Transport)を拡張したROUTE(Real−Time Object Delivery over Unidirectional Transport)プロトコルにより転送する方法が提案され、標準候補方式として設定された。
ROUTEプロトコルを適用することで、DASH規格のフラグメント化されたMP4(fragmented MP4)ファイルシーケンスと、DASH規格の制御情報(シグナリングデータ)格納メタファイルであるMPD(Media Presentation Description))、ならびに、放送配信のためのシグナリングデータであるUSBD/USD、S−TSID(Service based Transport Session Description)等を転送することができる。
前述したように、ROUTEプロトコルはFLUTEをベースとするプロトコルである。FLUTEにおける転送制御パラメータを記述したメタデータファイルをFDT(File Delivery Table)と呼び、ROUTEにおける転送制御パラメータを記述したメタデータファイルをS−TSID(Service based Transport Session Description)と呼ぶ。S−TSIDはFDTのスーパーセットでありFDTを含む。
ATSC3.0サービスレイヤのシグナリングデータ(SLS:Service Layer Signaling)として提案されているUSBD/USD、S−TSID、MPD等はすべてROUTEセッションにより転送される。
[4.受信装置におけるデータ出力例について]
次に、放送サーバ21、広告サーバ22等の送信装置20からデータを受信して、出力する受信装置(クライアント)30におけるデータ出力例について説明する。
図5は、受信装置(クライアント)30におけるデータ出力例を説明する図である。
受信装置30には、図5下部に示すタイムライン(時間軸(t))に従って、例えば映画やニュース、その他の放送番組(メインコンテンツ)と広告が交互に出力される。
ユーザが選択したあるチャンネルの番組開始時間をt0とすると、以下のように、時間推移に従って放送番組と広告が交互に出力される。
時間t0〜t1:広告
時間t1〜t2:放送番組
時間t2〜t3:広告
時間t3〜t4:放送番組
時間t4〜t5:広告
時間t5〜:放送番組
ここで、受信装置30に出力される広告は、多くの広告コンテンツの中から、受信装置30側の視聴ユーザに応じて選択された広告である。
受信装置30において設定されるユーザ(視聴者)情報に基づき、アプリケーションの制御により、ユーザに最適な広告が選択されて出力される。
ユーザ情報とは、例えば、ユーザ(視聴者)の年齢、性別、住所、趣味嗜好など、さまざまな情報である。
これらのユーザ情報は、受信装置の記憶部に予め登録した情報を用いる。
あるいは、番組開始時点で、ユーザ(視聴者)にユーザ情報を入力させ、この入力情報を用いる構成としてもよい。
あるいは、出力広告を受信装置30に対するユーザ入力に応じて自由に選択可能な構成としてもよい。
ユーザ情報の設定および利用態様には様々な態様がある。例えば、各番組単位でユーザ情報を設定させて利用する構成、チャンネル単位の設定、全チャンネル共通の設定等、様々な設定および利用構成が可能である。
これらのユーザ情報は、受信装置の記憶部に格納され、必要に応じて利用される。
ユーザ情報を利用した広告選択の具体的構成については後述する。
なお、ユーザに最適な広告の選択はアプリケーション制御部で実行されるアプリケーションが行うため、アプリケーションがインターネット経由にてサーバから取得しても良いし、アプリケーション自身が性別、年齢などの質問を表示し、ユーザの反応等によってユーザに問い合わせる等なども可能である。
図6を参照して、様々なユーザ情報を利用した出力広告の選択例について説明する。
図6には、以下の3種類の具体例を示している。
(A)年齢別の広告設定例
(B)居住地別の広告設定例
(C)年齢と、居住地別の広告設定例
(A)年齢別の広告設定例には、以下の例を示している。
ユーザ(視聴者)の年齢(age)=20歳以上→アルコール飲料(酒類)の広告を選択して出力する。
ユーザ(視聴者)の年齢(age)=15歳以下→おもちゃの広告を選択して出力する。
この例は、受信装置30側で登録されたユーザ情報として、ユーザの年齢の登録を実行させて、登録されたユーザ情報(視聴者年齢)に基づいて、そのユーザが利用している受信装置30に、ユーザ年齢に応じた広告を出力させる例である。
(B)居住地別の広告設定例には、以下の例を示している。
ユーザ(視聴者)の住所(Location)=アラスカ→暖房器具の広告を選択して出力する。
ユーザ(視聴者)の住所(Location)=ハワイ→冷房器具の広告を選択して出力する。
この例は、受信装置30側で登録されたユーザ情報として、ユーザの住所の登録を実行させて、登録されたユーザ情報(視聴者住所)に基づいて、そのユーザが利用している受信装置30に、ユーザの住所に応じた広告を出力させる例である。
(C)年齢と、居住地別の広告設定例には、以下の例を示している。
ユーザ(視聴者)の年齢(age)=18歳以上、かつ、
ユーザ(視聴者)の住所(Location)=ニューヨーク、
この2つの条件が満たされる場合に、ニューヨークの飲食店の広告を選択して出力する。
ユーザ(視聴者)の年齢(age)=15歳以下、かつ、
ユーザ(視聴者)の住所(Location)=カリフォルニア、
この2つの条件が満たされる場合に、カリフォルニアの玩具店の広告を選択して出力する。
この例は、受信装置30側で登録されたユーザ情報として、ユーザの年齢と住所を登録させて、登録されたユーザ情報(視聴者年齢と住所)に基づいて、そのユーザが利用している受信装置30に、ユーザ年齢と住所に応じた広告を出力させる例である。
このように、本開示の処理では、受信装置30側において設定された様々なユーザ情報に応じて、アプリケーション制御部で実行されるアプリケーションがユーザ(視聴者)に最適、すなわち広告効果が大きいと判断される広告を選択して出力する構成を実現する。
具体的な処理については、後述する。
[5.受信装置の構成例と処理例について]
次に、図7以下を参照して受信装置30の構成例と処理例について説明する。
なお、受信装置30は、先に図1を参照して説明したように、テレビ31、PC32、携帯端末33、あるいは、その他、例えば、スマートフォン、タブレット端末、スマートウォッチ、ウェアラブルデバイス等、様々な機器によって構成される。
図7に示す受信装置30は、放送サーバや、広告サーバ等の送信装置20からの送信データ、すなわち、先に図2を参照して説明した以下の各データ、
シグナリングデータ50、
AVセグメント60、
その他のデータ(ESG、NRTコンテンツ等)70、
これらのデータを受信して、処理を実行する。
受信装置30は、図7に示すように、アプリケーション制御部110、再生制御部(Embeded Media Player)120、ベースシステム130を有する。
アプリケーション制御部110は、アプリケーション実行部111を有し、例えば放送局等の送信装置20から送信されるアプリケーション、あるいは受信装置30内に予め格納されたアプリケーション等を実行する。
再生制御部120は、番組再生やアプリケーション実行によるデータ再生処理を実行する。
ベースシステム130は、キャッシュ制御部131、キャッシュ部132、第1通信部(チューナ)133、第2通信部(ネットワークI/F)134、出力制御部135を有し、送信装置20からのデータを受信し格納する処理、さらに表示部、スピーカ等に対するデータ出力制御等を実行する。
第1通信部(チューナ)133は、放送波の受信処理を実行する。第2通信部(ネットワークI/F)134は、インターネット等のネットワークを介したデータ通信を実行する。
再生制御部(Embeded Media Player)120は、例えばDASH(MPEG−DASH)規格に従って送信されたコンテンツの再生制御を実行する。
前述したように、MPEG−DASH規格には、以下の2つの規格が含まれる。
(a)動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル(MPD:Media Presentation Description)に関する規格、
(b)動画コンテンツ伝送用のファイル・フォーマット(セグメント・フォーマット)に関する規格、
送信装置20から、受信装置30に対するコンテンツ配信は、上記のMPEG−DASH規格に従って実行される。
コンテンツは、例えばMPEGにおいて規定されるMP4ファイルフォーマットに従って所定単位の分割データであるセグメント(AVセグメント等)として送信され、再生制御部120は、マニフェスト・ファイル(MPD)を参照して、再生対象コンテンツを格納したセグメントを取得する処理等を実行する。
なお、再生制御部120や、アプリケーション制御部110は、送信装置20(放送サーバ21、広告サーバ22等)が送信するシグナリングデータを参照し、シグナリングデータに記述された情報に従って必要なデータをキャッシュ部132から取得し、また、シグナリングデータに記述された情報に従って再生制御やアプリケーション制御を実行する。
なお、キャッシュ部132には、放送波、またはネットワークを介して受信したデータ等が格納される。
先に図2を参照して説明したように、シグナリングデータ50は、番組表等の番組予定情報や、番組取得に必要となるアドレス情報(URL(Uniform Resource Locator)等)、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報(符号化方式など)などからなる案内情報、アプリケーション制御情報等の様々な制御情報によって構成される。
再生制御部120や、アプリケーション制御部110は、シグナリングデータ(SLS:Service Layer Signaling)を取得して取得したシグナリングデータに基づくデータ取得処理や、データ再生制御や、アプリケーション実行制御等を実行する。
再生制御120や、アプリケーション制御部110は、コンテンツの再生、アプリケーションの制御情報等を記録したシグナリングデータとして、例えば、USBD/USDや、アプリケーション・インフォーメーション・テーブル(AIT:Application Information Table)や、S−TSID、MPD等の様々なシグナリングデータを取得して利用する。
シグナリングデータには、例えば、番組再生に必要となるAVセグメントや、アプリケーションの実行に必要となる様々なデータファイル(リソース)等を取得するためのアドレス情報(URL)が含まれる。
図8は、受信装置(クライアント)30の有する、
再生制御部120、
出力制御部135、
これらの詳細構成を示す図である。
受信装置(クライアント)30の再生制御部120は、MPD取得部121、MPD解析部122、セグメント取得部123、セグメント(MP4)解析部124を有する。
再生制御部120は、前述したように、DASH(MPEG−DASH)規格に従って送信されたコンテンツの再生制御を実行する。
MPD取得部121は、動画や音声ファイルの管理情報記述ファイルであるマニフェスト・ファイル(MPD:Media Presentation Description)を取得する。
MPDは、放送サーバ21、広告サーバ22等の送信装置20から提供され、キャッシュ部132に格納された後、再生制御部120が取得する。
MPD解析部122は、MPD取得部121の取得したMPDの記述内容を解析し、再生対象データに対応するセグメントの取得に必要となる情報等をセグメント取得部に提供する。
セグメント取得部123は、MPD解析部122のMPD解析結果に従って、再生対象データに対応するセグメントの取得を行う。
セグメントは、AVデータからなるコンテンツ伝送用のファイル・フォーマット(セグメント・フォーマット)に従って設定される所定の単位データである。
セグメント解析部124は、セグメント取得部123の取得したセグメントから、符号化画像データ、符号化音声データ等を取得して、出力制御部135の復号部(デコーダ)141に出力する。
受信装置(クライアント)30の出力制御部135は、復号部(デコーダ)141と、出力部(レンダラ)142を有する。
復号部(デコーダ)141は、セグメント解析部124から提供された符号化画像データ、符号化音声データの復号処理(デコード)を実行する。
出力部142は、復号された画像データ、音声データを出力部(ディスプレイ、スピーカ)に出力する。
受信装置(クライアント)30の再生制御部120は、ATSC3.0クライアントアプリケーション(3.0 DASH Client)の実行部である。
ATSC3.0クライアントアプリケーションは、ATSC3.0放送受信クライアントデバイス上に実装されたブラウザ上で実行される。あるいは、ブラウザアプリケーションとしてだけではなくネィティブアプリケーションとして実行される場合もある。
[6.MPDを利用したピリオド(Period)単位のシグナリングデータについて]
先に図2等を参照して説明したように、送信装置20は、受信装置30に対して、様々な制御情報からなるシグナリングデータ50を提供する。
前述したように、シグナリングデータには情報に応じた様々な種類がある。具体的には、例えば、番組等のサービス単位のシグナリングデータであるUSD(ユーザサービスディスクリプション(User Service Description))がある。
USDには様々な種類の制御情報が含まれる。代表的な制御情報として、コンテンツ(AVセグメント)に対応する案内情報、制御情報を格納したマニフェスト・ファイルを含むシグナリングデータであるMPD[メディアプレゼンテーションディスクリプション(Media Presentation Description)]がある。
DASH規格に規定されたシグナリングデータの1つであるMPD(Media Presentation Description)は、例えばある番組の放送時間を細分化した時間区間であるピリオド(Period)単位で、様々な制御データを受信装置(クライアント)30に提供することができる。
図9は、MPDのフォーマットの一例を示す図である。
MPDは、画像や、音声それぞれのストリームごとに、以下の様々な規定範囲単位で属性等の情報や制御情報を記述可能である。
(1)時間軸上の区間を規定したピリオド(Period)
(2)画像、音声等のデータ種類等を規定したアダプテーション(Adaptation)
(3)画像の種類、音声の種類等を規定したリプレゼンテーション(Representation)
(4)画像、音声のセグメント(AVセグメント)単位の情報記録領域となるセグメントインフォ(SegmentInfo)
図10は、MPDに記録されるAVセグメント対応の情報(制御情報や管理情報、属性情報など)を時系列に展開して示した図である。
左から右に時間が経過するものとする。この時間軸は、例えば受信装置におけるAVコンテンツの再生時間に対応する。
AVセグメントに対応する様々な情報がMPDに記録される。なお、MPDはシグナリングデータの一部であり、例えばAVセグメントに先行して送信される。
MPDは、図9を参照して説明したように、以下の各データ単位で情報が記録できる。
(1)時間軸上の区間を規定したピリオド(Period)
(2)画像、音声等のデータ種類等を規定したアダプテーション(Adaptation)
(3)画像の種類、音声の種類等を規定したリプレゼンテーション(Representation)
(4)画像、音声のセグメント(AVセグメント)単位の情報記録領域となるセグメントインフォ(SegmentInfo)
図10は、これらのデータ領域を時間軸、およびデータ種類別に展開して示した図である。
図10には、以下の2つのアダプテーション(Adaptation)を示している。
(V)画像対応情報記録領域であるアダプテーションV(Adaptation(V))
(A)音声対応情報記録領域であるアダプテーションA(Adaptation(A))
(V)画像対応情報記録領域であるアダプテーションV(Adaptation(V))は、異なる属性を持つストリーム単位の情報記録領域として、以下の2つのリプレゼンテーション(Representation)を有する。
(V1)低ビットレート画像対応の情報記録領域であるリプレゼンテーション(V1)(Representation(V1))
(V2)高ビットレート画像対応の情報記録領域であるリプレゼンテーション(V2)(Representation(V2))
同様に、(A)音声像対応情報記録領域であるアダプテーションA(Adaptation(A))は、異なる属性を持つストリーム単位の情報記録領域としての以下の2つのリプレゼンテーション(Representation)を有する。
(A1)日本語音声対応の情報記録領域であるリプレゼンテーション(A1)(Representation(A1))
(A2)英語音声対応の情報記録領域であるリプレゼンテーション(A2)(Representation(A2))
さらに、各リプレゼンテーション(Representation)は、再生時間軸対応のピリオド、さらに、セグメント単位で情報が記録可能な構成となっている。
例えば、高ビットレート画像と日本語音声を選択して再生する受信装置(クライアント)は、ピリオド1のセグメント(11)の再生に際して、再生対象とする高ビットレート画像と日本語音声に関する情報をMPDから選択して取得することになる。
この選択対象とするMPDの記録情報が、図に示すセグメント領域301,302の情報となる。
このように、受信装置は、シグナリングデータとして送信装置から送信されるMPDから、自装置で再生対象とするデータ(セグメント)に対応する情報のみを選択して参照する。
このように、MPDには、データ種別、時間単位のセグメント対応情報を記録することができる。
先に図5を参照して説明したように、放送番組と広告を交互に出力するコンテンツ出力処理を行なう場合、送信装置は、受信装置に対して、上述した所定時間(ピリオド)単位の制御情報を記録したMPDを利用することで、各時間単位のコンテンツ(放送番組、広告)の制御が可能となる。具体的には先に図5を参照して説明したユーザ対応の広告を提供する処理を実現することができる。
図11は、先に図5を参照して説明した放送番組と広告を交互に出力するコンテンツ出力処理に対応する制御情報記述データ(シグナリングデータ)であるMPDの構成例を示す図である。
MPDは、所定時間区間の出力コンテンツに相当する広告、および放送番組単位のピリオド情報311〜314に区分される。
ピリオド情報311は、時間t0〜t1に受信装置で出力される広告に対応する制御情報(シグナリングデータ)である。
ピリオド情報312は、時間t1〜t2に受信装置で出力される放送番組に対応する制御情報(シグナリングデータ)である。
ピリオド情報313は、時間t2〜t3に受信装置で出力される広告に対応する制御情報(シグナリングデータ)である。
ピリオド情報314は、時間t3〜t4に受信装置で出力される放送番組に対応する制御情報(シグナリングデータ)である。
ビリオド情報には、送信装置から送信される放送番組や広告のアクセス情報(URL)等、受信装置に出力するデータ(コンテンツ)の取得に必要となる情報や、復号方法(コーデック)等、受信装置においてコンテンツを取得し出力するために必要となる各種の情報が記録されている。
送信装置は、時間t0より以前に、図に示すMPDを受信装置に送信する。
受信装置は、このMPDを参照して、広告や放送番組を放送波やネットワークを介して取得し、指定されたコーデックを使用して復号処理等を行ない、表示部、スピーカ等に出力する。
図12は、受信装置において実行するMPDの解析処理(パース)の手順を説明する図である。
図12には、以下の各図を示している。
(1)MPD
(2)ピリオド情報
(3)リプレゼンテーション情報
(4)セグメント情報
AVセグメントを受信してAVコンテンツの再生処理を実行する受信装置(クライアント)は、AVセグメント受信前に予め受信するシグナリンクデータに含まれるMPDを取得し、自装置が再生するデータに対応する情報をMPDから取得する。
まず、図10に示す(1)MPDから、AVセグメント再生時間に相当する特定のピリオド(時間区間)の情報を記録した(2)ピリオド情報を選択する。
さらに、自装置(クライアント)において再生するデータの種類に対応した(3)リプレゼンテーション情報を選択し、さらに、再生対象セグメントに対応する(4)セグメント情報を選択する。
この(4)セグメント情報に記録されたデータを参照して、再生対象となるAVセグメントの取得や、AVセグメント再生に必要となる様々な情報を取得することができる。
[7.ユーザ情報に応じた広告提供処理を実行するための具体的構成例について]
次に、ユーザ情報に応じた広告提供処理を実行するための具体的構成例について説明する。
図13を参照して、図11に示すMPD中の1つのピリオド情報311の構成について説明する。
図11から理解されるように、ピリオド情報311は、時間t0〜t1において受信装置で出力する広告に対応する制御情報であるピリオド情報である。
図13に示すように、広告対応のピリオド情報311は、以下の記述データを有する。
Period A1 (Ad Break #1):
@xlink:href=http://adservice.com?user=$groupID$
@xlink:actuate="onRequest"
@start=0
@duration=60sec
・・・・・
広告対応のピリオド情報311には、先に、図10、図12を参照して説明した
アダプテーション、
リプレゼンテーション、
セグメントインフォ、
これらの具体的データの記述を省略し、これらの具体的記述を持つピリオド情報を取得するためのアクセス情報としてのリンク情報(xlink)が記録される。
「@xlink:href=http://adservice.com?user=$groupID$」
この情報記録フィールドはリンク(xlink)情報記録フィールドである。
なお、「@xlink:href=」は、参照すべきURLの設定フィールドであることを示している。
このxlinkURL(=ユーザ情報に応じたピリオド要素のアクセス情報)に基づいて、ユーザ情報に応じたピリオド要素を選択取得する処理は、例えば、送信装置から提供されるアプリケーション(リンク解決アプリ)によって実行される。
リンク解決アプリは、受信装置30のアプリケーション制御部110において実行される。
アプリケーション制御部110は、リンク解決アプリの実行によるリンク解決処理を実行する。
図14を参照して、ユーザ情報に応じた広告(Ad)出力処理のために行われるユーザ情報に応じたピリオド要素選択処理について説明する。
アプリケーション制御部110のアプリケーション実行部111では、例えば放送局等の送信装置20から提供されたアプリケーションを実行する。
アプリケーション実行部111は、リンク解決処理を行なうAPI(広告挿入API112)を適用した処理を実行する。
すなわち、アプリケーション実行部111は、広告挿入API112を適用して、Xlink URLを実行中のアプリケーションに通知し、アプリケーションはXlink URLならびにユーザ情報から広告挿入期間に挿入される広告コンテンツを選択し、その広告コンテンツに対応したピリオド要素を選択するリンク解決(xlink Resolver)処理を実行する。[0]
アプリケーション実行部111は、広告挿入API112を適用した処理によって、選択したユーザ情報対応の広告を格納した広告セグメントのURL等を含むピリオド要素を受信装置30の再生制御部120に返信する。
受信装置30の再生制御部120は、ピリオド要素に記録された広告セグメントURLを用いて広告セグメントの取得処理を行い、広告を再生する。
すなわち、広告挿入期間においては、MPDに記載されていた元のピリオド要素の代わりに、アプリケーションから指定されたピリオド要素、すなわち、広告コンテンツを再生する。
なお、受信装置30のアプリケーション制御部110のアプリケーション実行部111において実行されるアプリケーションは、放送局等の送信装置20から送信される様々な広告コンテンツの取得、キャッシュ処理の制御も行う。
なお、アプリケーションの起動は、放送の受信中であれば放送にて配信されるシグナリングデータであるAIT(Application Information Table)に記述データに従って行われる。放送を受信していない場合、例えば、深夜などにおいては、ESGにアプリケーションの起動時間をスケジュールすることもできる。
例えば、ユーザ情報に応じた様々な広告コンテンツは、NRT(ノンリアルタイム)コンテンツファイルとして、放送番組の配信と別に送信される。
受信装置30は、例えば予め取得するESG(電子サービスガイド:Electronic Service Guide)や、その他、FDT等のシグナリングデータに基づいて、広告データを格納したNRTコンテンツファイルの配信情報やアクセス情報を取得し、これらの情報を用いて広告データを取得する。
図15を参照して、受信装置30において実行される広告データの取得処理について説明する。
受信装置30のアプリケーション制御部110のアプリケーション実行部111では、例えば放送局等の送信装置20から提供されたアプリケーションが実行される。
アプリケーション実行部111で実行されるアプリケーションは、広告データのキャッシュ制御を実行するキャッシュ制御API(CacheStorageManager)114を適用したキャッシュ制御を行う。
アプリケーション実行部111で実行されるアプリケーションは、キャッシュ制御API(CacheStorageManager)114を適用して、受信装置30のベースシステム130内のキャッシュ制御部131の制御を行い、キャッシュ制御部131に、送信装置20から送信される広告データファイル(NRTコンテンツファイル)の取得、さらに、キャッシュ部132に対する格納処理を実行させる。
送信装置20から送信される広告データファイル(NRTコンテンツファイル)の取得、キャッシュ処理、さらに、キャッシュされた広告データの出力処理、これらの一連の処理シーケンスについて図16を参照して説明する。
図16は、左から右に示す時間(t)軸に従った処理を説明する図である。
時間軸に示す時間t1〜t9の各タイミングにおいて、受信装置30において実行される処理をステップS11〜S26の処理として示している。
図16に示す時間軸の上側の処理は、受信装置30のアプリケーション制御部110において実行するアプリケーションによる処理である。
一方、図16に示す時間軸の下側の処理は、受信装置30のキャッシュ制御部131、および再生制御部120の実行する処理である。
以下、図16に示す各ステップの処理について、順次、説明する。
(ステップS11)
まず、ステップS11において、アプリケーション制御部110において実行されるアプリケーションが、キャッシュ制御部131にアクセスし、広告データを格納するためのキャッシュスペースの確保要求(ファイル生成)を行う。
この処理は、先に図15を参照して説明したキャッシュ制御API114を適用して実行される。
(ステップS12)
次に、ステップS12において、アプリケーション制御部110において実行中のアプリケーションが、キャッシュ制御APII114を適用し、キャッシュ制御部に広告データ取得処理の開始を指示する。
この取得処理は、受信装置30が、事前に取得したESG(電子サービスガイド:Electronic Service Guide)を参照して実行される。ESGには、広告データを格納したNRTコンテンツファイルの配信スケジュールやアクセス情報が記録されており、これらの情報を用いて広告データを取得する。
(ステップS13〜S14)
ステップS13において、キャッシュ制御部131は、アプリケーションによって取得された広告データのキャッシュ部132に対する格納処理(フェッチ)を実行する。
ステップS14において、キャッシュ格納が完了する。
(ステップS21)
ステップS21以降の処理は、キャッシュ部132に格納された広告データファイル(NRTコンテンツファイル)を読み出して、出力する処理である。
なお、放送局からの配信コンテンツは、図16に示すように、所定の放送番組の間(時間t7〜t8)に予め規定の広告(デフォルト広告)が設定されたコンテンツとなっている。
従って、受信装置30側で、広告の差し替え処理を行なわなければ、この規定広告(デフォルト広告)が出力される。
以下、説明する処理は、先に図11、図13等を参照して説明したMPDの広告対応のピリオド情報に記録されたリンク(xlink)情報を適用して、ユーザ情報に基づいて選択されるユーザ対応の広告をアプリケーションが選択し、再生制御部に指示し、再生制御部はキャッシュ部132から指定されて広告コンテンツを取得して、規定広告(デフォルト広告)に差し替えて出力する処理である。
ステップS21において、受信装置30の再生制御部120は、MPDの解析処理を実行し、MPDの広告対応のピリオド情報に記録されたリンク(xlink)情報を検出する。
再生制御部120は、ピリオド情報に記録されたリンク(xlink)情報の検出に応じて、アプリケーション制御部110において実行中のアプリケーションに対して、リンク(xlink)解決要求を行う。
(ステップS22〜S23)
アプリケーション制御部110において実行中のアプリケーションは、再生制御部からのリンク解決要求の入力に応じて、リンク解決処理を実行する。
この処理は、先に図14を参照して説明した広告挿入API112を適用した処理である。アプリケーション制御部110は、広告挿入API112を適用して、xlinkURLに基づいて、ユーザ情報に応じたピリオド要素を選択するリンク解決(xlink Resolver)処理を実行する。
具体的には、ユーザ情報に応じたピリオド要素を選択し、選択したユーザ情報対応の広告を格納した広告セグメントのURL等を含むピリオド要素を受信装置30の再生制御部120に返信する。
(ステップS24〜S25)
次に、ステップS24において、受信装置30の再生制御部120は、ピリオド要素に記録された広告セグメントURLを用いて、キャッシュ部132から、広告セグメントの取得処理を行い、ステップS25において取得した広告を再生する。
すなわち、時間t7〜t8において放送番組に連続して再生予定の規定広告(デフォルト広告)を、キャッシュ部から取得した広告に差し替えて再生する処理を実行する。
この処理によって、ユーザ情報に応じて選択された広告の再生が行われることになる。
(ステップS26)
広告再生が完了すると、再生制御部120は指定された広告コンテンツの再生がおこなわれたことをアプリケーション制御部110の広告挿入API112を適用してアプリケーションに通知する。
(ステップS27)
アプリケーションは、広告挿入API112を適応してキャッシュ制御部にキャッシュされた広告コンテンツのファイルの削除を指示し、キャッシュ制御部131は、指定されたファイルの削除処理を行う。
このようにして、受信装置30では、アプリケーション制御部110において実行されるアプリケーションの管理の下、様々な広告コンテンツの取得処理、および選択再生処理が実行される。
[8.広告コンテンツの配信順の制御構成について]
次に、広告コンテンツの配信順の制御構成について説明する。
上述した説明から理解されるように、放送局等の送信装置20は、1つの広告再生時間に出力可能な広告として、多数の異なる広告コンテンツを受信装置30に提供する。
受信装置30は、送信装置20から送信される多数の広告コンテンツから、1つの広告を選択して再生することになる。
すなわち、送信装置20の提供する複数の広告コンテンツ中、1つの受信装置において再生される広告コンテンツは1つのみである。
受信装置30における広告選択処理は、広告再生時間より前に実行することが必要である。
受信装置30は、予め設定された広告出力時間の前に、その広告再生時間対応の複数の広告を受信装置30のキャッシュ部132に格納する処理を実行し、その中から、1つの再生対象のコンテンツを選択して出力することになる。
しかし、キャッシュ部に格納される複数の広告には、多くのユーザ(視聴者)によって選択される可能性の高い広告や、選択される可能性の低い広告が混在する。
例えば、広告の設定された番組が野球中継である場合、その視聴者は、野球の好きな男性視聴者である割合が高いと推定される。このような番組対応の広告として、以下の複数の異なる広告コンテンツを送信したものとする。
(広告1)子供向けの広告コンテンツ、
(広告2)成人男性向けの広告コンテンツ、
(広告3)女性向けの広告コンテンツ、
これらの、様々なユーザ層別広告コンテンツを送信しだ場合、受信装置30において選択される可能性の高い広告は、
(広告2)成人男性向けの広告コンテンツ、
であることが予想される。
このように、放送地域において選択可能性の高い広告と、選択可能性の低い広告が、予め推定されている場合、これら複数の広告コンテンツの配信順を制御することで、受信装置における広告の取得可能性や視聴率を高める制御を行う。
図17を参照して、広告コンテンツの配信順制御構成について説明する。
図17には、以下の図を示している。
(a)広告別ユーザ視聴分布予測データ
(b)広告送信順および配信優先度情報(Delivery Priority)の設定例
(a)広告別ユーザ視聴分布予測データは、広告配信を行う放送局等の送信装置20が保持しているデータである。例えば、過去の広告視聴履歴データ等に基づいて分析した結果である。
(b)広告送信順および配信優先度情報(Delivery Priority)の設定例は、(a)広告別ユーザ視聴分布予測データに基づいて設定した広告配信順に従った広告配信例を示している。
(b)には、送信装置20が送信する以下の各データを示している。
(b1)放送AVセグメント
(b2)NRTコンテンツファイル
送信装置20が送信する(b1)放送AVセグメントによる再生処理を行なう場合、受信装置では、放送番組と、予め設定された規定広告(デフォルト広告)としての広告1(Ad1)の出力が行われる。
送信装置20が送信する(b2)NRTコンテンツファイルには、時間ta〜tb間の広告再生時間において、規定広告(デフォルト広告)である広告1(Ad1)に差し替え可能な広告コンテンツファイル(NRTコンテンツファイル)の配信例を示している。
受信装置30は、(b2)NRTコンテンツファイルとして送信される広告2(Ad2)〜広告4(Ad4)をキャッシュ部に格納し、これらの広告のいずれかを選択し、再生時間:ta〜tbにおいて、広告1(Ad1)に差し替えて、選択広告を出力することができる。
(a)広告別ユーザ視聴分布予測データに示すように、広告別の視聴予測データは、以下の設定である。
広告1(Ad1)=55%
広告2(Ad2)=25%
広告3(Ad3)=15%
広告4(Ad4)=5%
これは、図17(b1)に示す放送AVセグメントに基づく再生番組中の時間ta〜tbにおいて選択出力可能な4種類の広告コンテンツ(Ad1〜Ad4)の視聴割合の予測データである。
すなわち、時間ta〜tbにおいて広告を視聴するユーザ全体を100%としたとき、広告1(Ad1)〜広告4(Ad4)の各広告の視聴割合の分布を示すデータである。
放送局が、この視聴予測データを、予め取得している場合、番組とともに配信する規定広告(デフォルト広告)を最も視聴可能性の高い広告(広告1(Ad1))とする。
さらに、広告再生時間taの直前に、次に視聴可能性の高い広告(広告2(Ad2))を送信する設定とする。
例えば、広告2(Ad2)は、時間t3〜t4に送信装置20から、受信装置30に送信される。
さらに、広告(広告2(Ad2))の配信前に、次に視聴可能性の高い広告(広告33(Ad3))を配信する設定とする。
例えば、広告2(Ad2)は、時間t2〜t3に送信装置20から、受信装置30に送信される。
さらに、広告(広告3(Ad3))の配信前に、次に視聴可能性の高い広告(広告4(Ad4))を配信する設定とする。
例えば、広告3(Ad3)は、時間t1〜t2に送信装置20から、受信装置30に送信される。
このように、広告再生開始時間(ta)に最も近い時間(t3)に視聴可能性の高い広告を送信する設定とする。最も視聴可能性の低い広告は、広告再生開始時間(ta)から最も離れた時間(t1)に送信が開始される。
図17(b1)に示す放送セグメントは、ある1つの放送局の配信番組であり、受信装置30がその放送局にチューニング(チャンネル設定)していなければ受信されないデータである。
図17(b2)に示すNRTコンテンツファイルもまた、(b1)に示す放送セグメントの受信設定、すなわち、その放送局にチューニング(チャンネル設定)を行なっている受信装置30のみが受信可能なデータである。
受信装置30は、ユーザ(視聴者)によって、任意のタイミングでON/OFFされ、また、任意タイミングでチャンネルの切り替えが行われる。
広告再生時間ta〜tbに、広告1(Ad1)〜広告4(Ad4)のいずれかの広告を視聴するユーザ(視聴者)は、受信装置がONであり、さらに、受信装置30をこの広告を配信しているチャンネルに設定しているユーザのみである。
例えば、図17(b)に示すデータを配信しているチャンネルをチャンネルAとする。
受信装置30側のユーザが、受信装置30のチャンネル設定を行い、チャンネルAに設定するタイミングは様々である。
図18には、受信装置30における複数のチャンネル設定タイミングの例を示している。
例えば、受信装置30が、時間TpにチャンネルAに設定すれば、受信装置30は、NRTコンテンツファイルとして送信装置20から送信される3つの広告コンテンツ(広告2〜広告4)の全てを取得してキャッシュ部に格納し、3つの広告コンテンツのいずれかを選択して出力することができる。
また、受信装置30が、時間TqにチャンネルAに設定した場合は、受信装置30は、NRTコンテンツファイルとして送信装置20から送信される3つの広告コンテンツ(広告2〜広告4)中、広告4(Ad4)については取得できず、広告2〜広告3のみを取得してキャッシュ部に格納し、これら2つの広告コンテンツのいずれかを選択して出力することができる。
また、受信装置30が、時間TrにチャンネルAに設定した場合は、受信装置30は、NRTコンテンツファイルとして送信装置20から送信される3つの広告コンテンツ(広告2〜広告4)中、広告3(Ad3)と広告4(Ad4)については取得できず、広告2(Ad2)のみを取得してキャッシュ部に格納し、この広告2(Ad2)を選択して出力することができる。
また、受信装置30が、時間TsにチャンネルAに設定した場合は、受信装置30は、NRTコンテンツファイルとして送信装置20から送信される3つの広告コンテンツ(広告2〜広告4)のいずれも取得できない、この場合、放送番組とともに送信される規定広告(広告1)の再生のみが可能となる。
なお、時間Tp〜Tsにおいて、受信装置30がチャンネルAに設定されていても、広告出力開始時間taより前に、受信装置30が他のチャンネルに切り替えられてしまうと、広告1〜広告4のいずれも視聴されないことになる。
受信装置30が、広告1〜広告4のいずれかを視聴するためには、広告出力タイミングtaに受信装置30がチャンネルAに設定していることが必要である。
広告出力タイミングtaに受信装置30が出力可能な広告は、受信装置30がチャンネルAに設定した時間に応じて以下のような設定となる。
(1)チャンネルA設定時間=Tp以前〜ta:広告1(Ad1)〜広告4(Ad4)
(2)チャンネルA設定時間=Tq〜ta:広告1(Ad1)〜広告3(Ad3)
(3)チャンネルA設定時間=Tr〜ta:広告1(Ad1)〜広告2(Ad2)
(4)チャンネルA設定時間=Ts〜ta:広告1(Ad1)
すなわち、各広告の再生可能なチャンネル設定タイミングは、以下のようになる。
(1)広告1(Ad1)=Tp,Tq,Tr,Ts
(2)広告2(Ad2)=Tp,Tq,Tr
(3)広告3(Ad3)=Tp,Tq
(4)広告4(Ad4)=Tp
このように、広告1(Ad1)が最も再生可能となる確率が高く、広告4(Ad4)が最も再生可能となる確率が低いという結果となる。
この検討結果から、規定広告(デフォルト広告(広告1))に差し替え可能な広告を、NRTコンテンツファイルとして送信する場合、再生開始時間taの直前に送信する方が、受信装置30における受信および再生可能性を高めることができるという結論が得られる。
すなわち、広告の出力開始時間(ta)の直前に、より視聴可能性の高い広告コンテンツを送信し、視聴可能性の低い広告コンテンツは、それ以前に送信するといった送信順の設定を行うことで、受信装置30におけるユーザ選択やユーザ情報に従って選択される広告の受信および再生可能性を高めることができる。
送信装置20は、この検討結果に基づいて、NRTコンテンツファイルとして送信する広告コンテンツの送信順を設定して送信する。
図19に示すフローチャートを参照して送信装置20の実行する広告コンテンツの配信制御シーケンスについて説明する。
(ステップS101)
送信装置のデータ処理部は、まず、ステップS101において、複数の配信広告に関する視聴分布予測データを取得する。
すなわち、例えば図17(a)に示すような広告別ユーザ視聴分布予測データである。例えば、広告別の視聴予測データは以下の設定を持つ。
広告1(Ad1)=55%
広告2(Ad2)=25%
広告3(Ad3)=15%
広告4(Ad4)=5%
これは、図17(b1)に示す放送AVセグメントに基づく再生番組中の時間ta〜tbにおいて選択出力可能な4種類の広告コンテンツ(Ad1〜Ad4)の視聴割合の予測データである。
すなわち、時間ta〜tbにおいて広告を視聴するユーザ全体を100%としたとき、広告1(Ad1)〜広告4(Ad4)の各広告の視聴割合の分布を示すデータである。
(ステップS102)
次に、送信装置は、ステップS102において、視聴予測データに基づいて、最も視聴可能性が高い広告(Ad1)を番組付随の規定広告(デフォルト広告)に設定する。
(ステップS103)
次に、送信装置は、ステップS103において、視聴予測データに基づいて、2番目以降の視聴可能性を持つ広告を、視聴可能性の高い順(Ad2)〜(Adn)に配列する。
(ステップS104)
次に、送信装置は、ステップS104において、視聴可能性の高い順に配列した広告(Ad2)〜(Adn)を、視聴可能性の低い広告(Adn)を先頭の送信データとし、視聴可能性の高い広告(Ad2)を広告再生時間taの直前に配信完了するように配信順と配信時間を決定し、決定した配信順と配信時間に従って、各広告データを格納したNRTコンテンツファイルを送信する。
(ステップS105)
次に、送信装置は、ステップS105において、最も視聴可能性が高い広告(Ad1)を番組付随の規定広告(デフォルト広告)として送信する。
このように、送信装置20は、例えば図17に示す広告別ユーザ視聴分布予測データに基づいて、広告の配信順を決定し、送信する。すなわち、視聴可能性の高いコンテンツの送信時間をコンテンツ出力時間に最も近い時間とし、視聴可能性の低いコンテンツの送信時間を視聴可能性の高いコンテンツの送信時間より前に設定する送信順決定処理を実行する。
例えば図17に示す広告別ユーザ視聴分布予測データは、遂次更新する設定としもよい。例えば、先行して出力された広告コンテンツの視聴率情報を取得し、取得した視聴率情報に基づいて、図17に示す広告別ユーザ視聴分布予測データを逐次、更新し、更新されたデータを利用して配信順を決定する処理を行なう構成としてもよい。
先行して出力された広告の視聴率は、受信装置もしくはアプリケーション実行部で実行されるアプリケーションがインターネット等の通信回線を用いて放送局に広告の出力結果を通知することで行える。
次に、受信装置30において実行する処理シーケンスの例について図20に示すフローチャートを参照して説明する。
(ステップS121)
まず、受信装置のデータ処理部は、ステップS121において、ユーザ情報、またはユーザ選択に従った再生広告の選択処理を実行する。
これは、例えば、先に図13等を参照して説明したユーザ情報を設定したリンク情報(xlink)に基づく広告選択処理、あるいは受信装置に対するユーザ入力に基づく広告選択処理である。
(ステップS122)
次に、受信装置は、ステップS122において、選択された広告は番組付随の規定広告(デフォルト広告)であるか否かを判断する。
選択された広告が番組付随の規定広告(デフォルト広告)である場合は、ステップS123に進む。
選択された広告が番組付随の規定広告(デフォルト広告)でない場合はステップS124に進む。
(ステップS123)
選択された広告が番組付随の規定広告(デフォルト広告)である場合は、ステップS123に進み、番組付随の規定広告(デフォルト広告)を再生する。
(ステップS124)
一方、選択された広告が番組付随の規定広告(デフォルト広告)でない場合は、ステップS124に進み、さらに、選択された広告が、キャッシュ済みであるか否かを確認する。
選択された広告が、キャッシュ済みである場合は、ステップS125に進む。
一方、選択された広告が、キャッシュ済みでない場合は、ステップS123に進み、番組付随の規定広告(デフォルト広告)を再生する。
(ステップS125)
ステップS124において、選択された広告が、キャッシュ済みである場合は、ステップS125に進み、ステップS125において、キャッシュ部から選択広告を取得して再生する。
[9.配信優先度情報(Delivery Priority)に基づく処理例について]
送信装置20からNRTコンテンツとして送信される差し替え処理用の広告コンテンツの各々には、それぞれ受信装置30における受信およびキャッシュ処理の実行要否を判定させる判定基準としての優先度を設定することができる。
この優先度を配信優先度情報(Delivery Priority)と呼ぶ。
配信優先度情報(Delivery Priority)は、NRTコンテンツファイルとして送信される広告コンテンツ自体にも設定可能であるが、広告コンテンツの配信前に送信されるデータ(例えば、FDT等のシグナリングデータやESG等)に記録して、予め受信装置に提供することが可能である。
以下、この配信優先度情報(Delivery Priority)を利用した処理例について説明する。
図21は、送信装置20が、送信するNRTコンテンツファイルとしての差し替え用広告コンテンツ(Ad2〜Ad4)各々に対応する対応情報(例えば、FDT等のシグナリングデータやESG等)の記録データの例を示す図である。
各広告データ(Ad2〜Ad4)の各々に対応する対応情報には、各広告に関する以下の属性データが記録される。
(a)配信優先度情報(Delivery Priority)
(b)配信時間情報(start/end time)
(c)広告出力開始終了時間(start/end time)
(a)配信優先度情報(Delivery Priority)は、各広告についての受信装置30における受信およびキャッシュ処理の実行要否を判定させる判定基準としての優先度であり、送信装置20側で自由に設定可能な値である。
図に示す例では、
広告2(Ad2)の配信優先度情報=5
広告3(Ad3)の配信優先度情報=4
広告4(Ad4)の配信優先度情報=1
上記設定であり、広告2(Ad2)の配信優先度情報の設定値が最も高くなっている。
受信装置30は、例えは、受信装置30において予め規定した判定基準値としての規定値を用い、規定値以上の配信優先度の設定された広告データを優先的に選択して受信し、キャッシュする処理を行なうことができる。
送信装置20は、受信装置30に送信する複数の広告コンテンツの各々について配信優先度情報(Delivery Priority)を設定し、配信優先度情報(Delivery Priority)を、受信装置30に送信する。
なお、配信優先度情報(Delivery Priority)は、例えば、視聴可能性の高低に応じた値として設定される。
(b)配信時間情報(start/end time)には、広告の配信される時間情報であり、配信開始時間と、配信終了時間が記録される。
(c)広告出力開始終了時間(start/end time)は、受信装置におけるその広告の出力開始時間と出力終了時間の記録領域である。
なお、これらの各情報を記録した具体的なデータ、例えば、FDT等のシグナリングデータやESG等の情報記録例については、後段で説明する。
図22に示すフローチャートを参照して送信装置20の実行する広告対応の配信優先度情報(Delivery Priority)の生成、送信シーケンスについて説明する。
(ステップS141)
送信装置のデータ処理部は、まず、ステップS141において、複数の配信広告に関する視聴分布予測データを取得する。
すなわち、例えば図17(a)に示すような広告別ユーザ視聴分布予測データである。例えば、広告別の視聴予測データは以下の設定を持つ。
広告1(Ad1)=55%
広告2(Ad2)=25%
広告3(Ad3)=15%
広告4(Ad4)=5%
これは、図17(b1)に示す放送AVセグメントに基づく再生番組中の時間ta〜tbにおいて選択出力可能な4種類の広告コンテンツ(Ad1〜Ad4)の視聴割合の予測データである。
すなわち、時間ta〜tbにおいて広告を視聴するユーザ全体を100%としたとき、広告1(Ad1)〜広告4(Ad4)の各広告の視聴割合の分布を示すデータである。
(ステップS142)
次に、送信装置は、ステップS142において、視聴予測データに基づいて、各広告(Ad1〜Adn)に対する配信優先度情報(Delivery Priority)を設定する。
例えば、図21を参照して説明した優先度情報、
広告2(Ad2)の配信優先度情報=5
広告3(Ad3)の配信優先度情報=4
広告4(Ad4)の配信優先度情報=1
これらの情報を設定する。
(ステップS143)
次に、送信装置は、ステップS143において、視聴予測データに基づく各広告(Ad1〜Adn)対応の配信優先度情報(Delivery Priority)を記録したデータ、例えばシグナリングデータを生成して送信する。
なお、ここで生成するシグナリングデータ等には、配信優先度情報(Delivery Priority)のみならず、その他の様々な広告対応の情報が記録されている。少なくとも、先に図21参照して説明したように、以下の各データが記録されている。
(a)配信優先度情報(Delivery Priority)
(b)配信時間情報(start/end time)
(c)広告出力開始終了時間(start/end time)
次に、受信装置30において実行する配信優先度情報(Delivery Priority)に基づく処理シーケンスの例について図23に示すフローチャートを参照して説明する。
(ステップS161)
まず、受信装置のデータ処理部は、ステップS161において、視聴予測データに基づく、各広告(Ad1〜Adn)対応の配信優先度情報(Delivery Priority)を記録したデータ、例えばシグナリングデータを受信する。
なお、受信したシグナリングデータには、先に図21を参照して説明したように、以下の各データが記録されている。
(a)配信優先度情報(Delivery Priority)
(b)配信時間情報(start/end time)
(c)広告出力開始終了時間(start/end time)
(ステップS162)
次に、受信装置は、ステップS162において、送信装置から送信される広告(Adx)各々について、配信優先度情報(Delivery Priority)の設定値を確認し、配信優先度情報(Delivery Priority)が、予め設定した規定値以上であるか否かを判定する。
送信広告(Adx)の配信優先度情報(Delivery Priority)が、予め設定した規定値以上である場合は、ステップS163に進む。
送信広告(Adx)の配信優先度情報(Delivery Priority)が、予め設定した規定値以上でない場合は、ステップS164に進む。
(ステップS163)
送信広告(Adx)の配信優先度情報(Delivery Priority)が、予め設定した規定値以上である場合は、ステップS163に進み、送信広告(Adx)を受信し、キャッシュ部に格納する処理を実行する。
(ステップS164)
一方、送信広告(Adx)の配信優先度情報(Delivery Priority)が、予め設定した規定値以上でない場合は、ステップS164に進み、送信広告(Adx)の受信処理、キャッシュ部格納処理を中止する。
このように、受信装置は、各広告対応の配信優先度情報(Delivery Priority)に基づいてキャッシュ格納処理の要否を判定し、より優先度の高い広告のみをキャッシュ部に格納して再生することが可能となる。
これにより、本来、配信されるNRTコンテンツをキャッシュに格納するかはアプリケーションの制御によって行われるが、キャッシュ制御部、あるいはキャッシュ制御部を制御する受信装置のデータ処理部はアプリケーションからの要求がない場合でも、配信優先度情報(Delivery Priority)に基づいて、キャッシュするかの判断が可能となる。
[10.サービス選択優先度情報(Service Selection Priority)を適用した処理について]
次に、複数の異なるチャンネルからの広告配信が競合した場合の処理について説明する。
具体的には、サービス選択優先度情報(Service Selection Priority)を適用した処理について説明する。
広告を配信する放送局は多数あり、それぞれの放送局等の複数の送信装置20が様々な時間に様々な広告配信を実行している。
受信装置30のユーザが、特定の放送局20を視聴中(チューニングされた)状態であれば、受信装置30は、その選択チャンネルの番組コンテンツと、その番組付随のNRTコンテンツ、例えば差し替え用の広告コンテンツを格納したNRTコンテンツファイルを受信することになる。
しかし、受信装置30が特定チャンネルの放送を受信していない状態、例えば、深夜、受信装置がスタンバイモードに設定されている間に、送信装置20は、様々なデータファィルを送信する場合がある。
受信装置30は、予め受信済みのESG(電子サービスガイド(Electronic Service Guide))等のシグナリングデータに基づいて、様々なコンテンツの配信スケジュールを予め知ることができ、深夜等に配信されるデータを、スタンバイモード状態で受信し、キャッシュ部に格納することができる。
例えばESGや、FDT等のシグナリングデータには、配信データのアクセス情報、配信タイミング情報が記録されており、受信装置30は、スタンバイモードにおいて、適宜、データを受信するためのチューニング(チャンネル設定)を自動的に実行して、配信データを取得してキャッシュ部に格納することができる。
しかし、例えば異なる放送局から同一タイミングで異なるデータ、例えば、2つの異なる放送局から、各々異なる広告、広告1(Ad1)と、広告2(Ad2)が送信されると、受信装置30は、いずれか一方の広告のみの受信処理しかできない。
すなわち、このような配信データの競合が発生した場合、受信装置30は、何らかのアルゴリズムに従って受信データの選択処理を実行することが必要となる。
図24は、異なる放送局(放送局Aと放送局B)から同一タイミングで異なる広告、広告1(Ad1)と、広告2(Ad2)が送信される場合の送信シーケンスを示している。
放送局A(cid=1)は、NRTコンテンツファイルとして、時間t1〜t2において、広告1(Ad1)を送信する。
放送局B(cid=2)も、NRTコンテンツファイルとして、時間t1〜t2において、広告2(Ad2)を送信する。
このような配信データの競合が発生した場合、受信装置30は、何らかのアルゴリズムに従って受信データの選択処理を実行することが必要となる。
以下、このような場合に、受信装置30がいずれかの広告を選択取得する構成について説明する。広告配信処理前に送信装置20から受信装置30に送信されるデータ、例えばESGやFDT等のシグナリングデータに選択取得判定用の優先度情報を設定し、この優先度情報に基づいて選択取得する広告を決定する。
なお、この広告選択に適用する優先度情報は、
サービス選択優先度情報(Service Selection Priority)と呼ぶ。
図25、図26を参照して、サービス選択優先度情報(Service Selection Priority)を記録したシグナリングデータの送信、利用処理について説明する。
図25には、放送局A(cid=1)、放送局B(cid=2)各々の送信する広告データ(NRTコンテンツファイル)と、広告対応属性情報、例えばESGやシグナリングデータの送信処理例を示している。図に示す広告対応属性情報は、各放送局の提供する広告1(Ad1)、広告2(Ad2)に関する属性情報、制御情報を記録したESG、あるいはFDT等のシグナリングデータである。
ESG、あるいはFDT等のシグナリングデータには、サービス選択優先度情報(Service Selection Priority)が記録される。
このサービス選択優先度情報(Service Selection Priority)は、広告等の配信コンテンツの配信時間が重複した場合に、1つのコンテンツを選択的に受信、キャッシュするためのコンテンツ選択判定処理に適用される。
図26を参照して、受信装置において実行するサービス選択優先度情報(Service Selection Priority)を用いた取得コンテンツ選択処理について説明する。
まず、受信装置は、ステップAに示すように、配信広告に関する配信時間情報等のアクセス情報を記録した事前取得データ、例えばESGや、シグナリングデータであるFDTを受信し、各広告の配信時間を確認する。
ここで、ステップBに示すように、複数の異なる広告の配信時間が重複(競合)していることが確認されたとする。
この場合、受信装置30は、各放送局から送信されるESG、またはFDT等のシグナリングデータを参照し、各配信広告に対応付けられたサービス選択優先度情報(Service Selection Priority)を参照する。
なお、サービス選択優先度情報(Service Selection Priority)の記録データとしては、例えば、
(a)番組表等を含む電子サービスガイドであるESG(Electronic Service Guide)
(b)各送信ファイルのメタデータを記録したFDT(File Delivery Table)
(c)サービス選択優先度情報(Service Selection Priority)記録用の専用データであるCRT(Conflict Resolution Table)
例えば、これらのデータのいずれかの利用が可能である。
次に、受信装置30は、図に示すステップCにおいて、各配信広告に対応付けられたサービス選択優先度情報(Service Selection Priority)を比較し、より高い優先度情報の設定された広告を受信、キャッシュ対象として選択する。
図26に示す例では、放送局A(cid=1)から送信される広告1(Ad1)対応のサービス選択優先度情報(Service Selection Priority)は、[5]である。
一方、放送局B(cid=2)から送信される広告2(Ad2)対応のサービス選択優先度情報(Service Selection Priority)は、[7]である。
この場合、受信装置30は、放送局B(cid=2)から送信される広告2(Ad2)を選択して受信し、キャッシュ処理を実行する。
このような処理を実行することで、受信装置30は、複数のコンテンツ(広告等)の配信時間が重複した場合でも、1つの受信コンテンツを確実に選択して、取得することが可能となる。
なお、各放送局対応の提供コンテンツを受信する場合、受信対象コンテンツの受信処理を実行するための放送局対応のアプリケーションを起動して処理を実行することになる。
すなわち、受信装置30は、各配信広告に対応付けられたサービス選択優先度情報(Service Selection Priority)を比較し、より高い優先度情報の設定された広告を受信することを決定し、その広告を受信するためのアプリケーションを起動して、広告受信処理およびキャッシュ処理を実行する。
図27に示すフローチャートを参照して送信装置20の実行するサービス選択優先度情報(Service Selection Priority)の生成、送信シーケンスについて説明する。
(ステップS201)
送信装置のデータ処理部は、まず、ステップS201において、配信広告対応のサービス選択優先度情報(Service Selection Priority)を記録した送信用データ(FDT,ESG,CRT等)を生成する。
前述したように、例えば、
(a)番組表等を含む電子サービスガイドであるESG(Electronic Service Guide)
(b)各送信ファイルのメタデータを記録したFDT(File Delivery Table)
(c)サービス選択優先度情報(Service Selection Priority)記録用の専用データであるCRT(Conflict Resolution Table)
例えば、これらのデータのいずれかにサービス選択優先度情報(Service Selection Priority)を記録する。
(ステップS202)
次に、送信装置は、ステップS202において、配信広告対応のサービス選択優先度情報(Service Selection Priority)を記録した送信用データ(FDT,ESG,CRT等)を送信する。
次に、受信装置30において実行するサービス選択優先度情報(Service Selection Priority)に基づく処理シーケンスの例について図28に示すフローチャートを参照して説明する。
(ステップS221)
まず、受信装置のデータ処理部は、ステップS221において、例えばESGや、FDT等の事前取得データから、配信広告の送信時間情報を取得する。
(ステップS222)
次に、受信装置は、ステップS222において、複数の異なる配信広告の送信時間が重複するか否かを判定する。
重複することが確認された場合は、ステップS223に進む。
重複しないことが確認された場合はステップS225に進む。
(ステップS223)
複数の異なる配信広告の送信時間が重複することが確認された場合は、ステップS223に進み、配信広告対応のサービス選択優先度情報(Service Selection Priority)を記録したデータ(FDT,ESG,CRT等)を参照する。
(ステップS224)
次に、受信装置は、ステップS224において、ステップS223で参照したサービス選択優先度情報(Service Selection Priority)に基づいて、サービス選択優先度情報の高い広告を受信、キャッシュ対象として選択し、選択した広告を受信し、キャッシュ部に格納する。
なお、アプリケーション制御により、この広告受信、キャッシュ処理を実行するためには、受信対象となる広告の受信、キャッシュ格納処理に適用するアプリケーションを起動することが必要であり、受信装置30は、選択広告対応の処理を実行するアプリケーションを起動して、広告の受信、キャッシュ処理を実行する。
(ステップS225)
一方、ステップS222の判定処理において、複数の異なる配信広告の送信時間が重複しないことが確認された場合はステップS225に進み、配信広告を順次、受信してキャッシュ部に格納する処理を実行する。
このようにして、受信装置30は、複数の異なる広告等のコンテンツの配信時間が競合した場合、1つのコンテンツを選択して受信、キャッシュ格納することが可能となる。
上記の実施例ではアプリケーションを起動してその制御によりキャッシュ処理を実行したが、事前にアプリケーションがキャッシュAPIによりNRTファイルの取得を指示していた場合は、アプリケーションの起動なしに、データ受信部はESGの配信時間から判断して、NRTコンテンツをキャッシュに格納する処理を行うことも可能である。
[11.各優先度情報の記録構成例について]
上述した説明において、受信装置30における広告等のコンテンツの優先取得判定に適用する優先度情報として、以下の2つの優先度情報について説明した。
(1)配信優先度情報(Delivery Priority)
(2)サービス選択優先度情報(Service Selection Priority)
(1)配信優先度情報(Delivery Priority)は、先に図21〜図23を参照して説明したように、特定の1つのチャンネルの1つの広告出力時間帯に出力可能な複数の広告コンテンツの各々に対応付けられた優先度情報である。
1つのNRT送信チャンネルを介して連続的に配信される異なるコンテンツ(例えば異なる広告)データの各々に設定される優先度情報である。
受信装置30は、配信優先度情報(Delivery Priority)に基づいて配信優先度の高いコンテンツ(広告)を選択的に受信、キャッシュすることができる。
(2)サービス選択優先度情報(Service Selection Priority)は、先に図24〜図28を参照して説明したように、複数の異なるチャンネルを介して配信される広告コンテンツの各々に対応付けられた優先度情報である。
受信装置30は、複数の異なるチャンネルを介して配信される広告コンテンツの配信時間が重複する場合、各広告対応のサービス選択優先度情報(Service Selection Priority)を参照し、サービス選択優先度の高いコンテンツ(広告)を選択して受信、キャッシュすることができる。
これら2つの優先度情報は、送信装置20が受信装置に送信する広告コンテンツそのものに付随して送信することも可能であり、また、各広告コンテンツに先行して送信されるESGや、FDT等のシグナリングデータに記録して提供することも可能である。
これら2つの優先度情報は、広告データファィル(NRTコンテンツファイル)に直接記録することも可能であるが、広告データファイルに先行して送信される、例えば、以下の各データに記録して送信装置20から受信装置30に送信することが可能である。
(a)番組表等を含む電子サービスガイドであるESG(Electronic Service Guide)
(b)各送信ファイルのメタデータを記録したFDT(File Delivery Table)
(c)サービス選択優先度情報(Service Selection Priority)記録用の専用データであるCRT(Conflict Resolution Table)
例えば、これらのデータのいずれかの利用が可能である。
図29に、各送信ファイルのメタデータを記録したFDT(File Delivery Table)に、以下の2つの優先度情報を記録した例を示す。
(1)配信優先度情報(Delivery Priority)
(2)サービス選択優先度情報(Service Selection Priority)
図29には、
(1)放送番組等の配信データ
(2)シグナリングデータ
(3)広告セグセメント(NRT)の配信データ
これらの各データの配信例を示している。
さらに、シグナリングデータの詳細として、
(2a)広告2(Ad2)対応のシグナリングデータ、
(2b)広告3(Ad3)対応のシグナリングデータ、
これらのシグナリングデータの詳細を示している。
各シグナリングデータには、
(1)配信優先度情報(Delivery Priority)
(2)サービス選択優先度情報(Service Selection Priority)
これらの各優先度情報が記録され、さらに広告の配信時間情報等が記録される。
受信装置は、各広告が送信装置から送信される前にこのシグナリングデータを受信し、シグナリングデータの解析を実行する。
このシグナリングデータの解析に基づいて、送信予定の各広告に関する以下の各優先度情報、すなわち、
(1)配信優先度情報(Delivery Priority)
(2)サービス選択優先度情報(Service Selection Priority)
これらの優先度情報を取得し、取得した優先度情報に基づいて、受信、キャッシュ処理を実行する広告コンテンツを選択することができる。
図30以下を参照して、各送信ファイルのメタデータを記録するシグナリングデータであるFDT(File Delivery Table)に、以下の2つの優先度情報を記録する場合の各優先度情報の記録位置の例について説明する。
(1)配信優先度情報(Delivery Priority)
(2)サービス選択優先度情報(Service Selection Priority)
図30、図31に示す例は、シグナリングデータであるS−TSIDの、
S−TSID/RS/LS/SrcFlow/EFDT要素の属性(Attribute)に、
(1)配信優先度情報(Delivery Priority)
(2)サービス選択優先度情報(Service Selection Priority)
これらの優先度情報を記録した例である。
図30は、ROUTEで規定しているシグナリングデータであるS−TSIDの構成を示している。S−TSIDは、以下の各要素の階層構成を持つ。
S−TSID要素411、
ROUTEセッション(ROUTESession)要素412、
LCTセッション(LCTSession)要素413、
ソースフロー(SourceFlow)要素414、
EFDT要素415、
ファイル(File)要素417、
これらの階層設定となる。
各広告データに関する優先度情報は、
EFDT要素415単位のアトリビュート(属性)(Attribute)データ要素416に記録することができる。
この詳細構成を図31に示す。
アトリビュート(属性)記録領域には、規定の属性(Attribute)情報の記録領域の他、自由なデータを格納可能なデータ記録フィールド(any)が設定される。
このデータ記録フィールド(any)に、
(1)配信優先度情報(Delivery Priority)421
(2)サービス選択優先度情報(Service Selection Priority)422
これらの優先度情報を記録する。
なお、このアトリビュート(属性)記録領域には、図に示すように、複数の広告対応の上記2種類の優先度情報を、各広告毎に記録する設定とすることができる。
あるいは、1つの広告対応の上記2種類の優先度情報のみを記録する設定としてもよい。
各優先度情報の具体的な記述例(XMLデータ)を図32、および、以下に示す。
<S−TSID>・・・<RS>・・・<LS>・・・<SrcFlow>・・・
<EFDT DeliveryPriority="10" ServiceSelectionPriority="8">・・・</EFDT>
<SrcFlow>・・・<LS>・・・<RS>>...</S−TSID>
上記XMLデータは、
(1)配信優先度情報(Delivery Priority)=10
(2)サービス選択優先度情報(Service Selection Priority)=8
の設定を持つ優先度情報を記録したデータの例である。
図30〜図32を参照して説明した例は、S−TSIDのEFDT要素の属性(Attribute)として、2つの優先度情報を記録した例であるが、図30に示すEFDT要素415の下位のFile要素417の属性(Attribute)要素418に2つの優先度情報を記録することも可能である。
すなわち、S−TSID/RS/LS/SrcFlow/EFDT/File要素の属性(Attribute)に、
(1)配信優先度情報(Delivery Priority)
(2)サービス選択優先度情報(Service Selection Priority)
これらの優先度情報を記録することもできる。
広告データの送信ファイルであるNRTコンテンツファイル単位の属性情報は、
ファイル(File)要素417単位のアトリビュート(属性)(Attribute)データ要素418に記録することができる。
この詳細構成を図33に示す。
アトリビュート(属性)記録領域には、規定の属性(Attribute)情報の記録領域の他、自由なデータを格納可能なデータ記録フィールド(any)が設定される。
このデータ記録フィールド(any)に、
(1)配信優先度情報(Delivery Priority)421
(2)サービス選択優先度情報(Service Selection Priority)422
これらの優先度情報を記録する。
さらに、図34を参照して、番組表等を含む電子サービスガイドであるESG(Electronic Service Guide)に、
(1)配信優先度情報(Delivery Priority)
(2)サービス選択優先度情報(Service Selection Priority)
これらの各優先度情報を記録する場合のデータ記録例について説明する。
図34は、ESGの構成(一部構成)を示す図である。
ESG510には、スケジュール(Schedule)要素511が設定される。
さらに、スケジュール(Schedule)要素511以下に、
コンテンツリフェランス(ContentReference)要素513、
ディストリビューションウィンドウ(DistributionWindow)要素515、
プレゼンテーションウィンドウ(PresentationWindow)要素516、
これらの要素が配置される。
各要素単位でアトリビュート(属性)要素が設定され、各要素単位の属性情報を記録することができる。
コンテンツリフェランス(ContentReference)要素513直下のアトリビュート(属性)要素514には、
idRef521が記録される。
idRef521は、このスケジュール要素全体に記録されている情報が、どのコンテンツセグメント対応の情報であるかを識別可能とした情報である。例えば、このスケジュール要素全体に記録されている情報が、どの広告コンテンツ対応の情報であるかを識別することができる。
「配信優先度情報(Delivery Priority)」は、
ディストリビューションウィンドウ(DistributionWindow)要素515直下のアトリビュート(属性)要素531に記録する。
また、「サービス選択優先度情報(Service Selection Priority)」は、
プレゼンテーションウィンドウ(PresentationWindow)要素516直下のアトリビュート(属性)要素532に記録する。
図35に、ディストリビューションウィンドウ(DistributionWindow)要素515直下のアトリビュート(属性)要素531の記録情報と、
プレゼンテーションウィンドウ(PresentationWindow)要素516直下のアトリビュート(属性)要素532の記録情報の例を示す。
ディストリビューションウィンドウ(DistributionWindow)要素515直下のアトリビュート(属性)要素531には、図に示すように、
広告コンテンツ(NRTコンテンツファイル)の配信時間情報、すなわち、広告コンテンツ(NRTコンテンツファイル)の配信開始時間と終了時間が記録され、さらに、
サービス選択優先度情報(Service Selection Priority)が記録される。
また、プレゼンテーションウィンドウ(PresentationWindow)要素516直下のアトリビュート(属性)要素532には、
広告コンテンツの出力時間情報、すなわち受信装置における広告の出力時間の開始時間と終了時間が記録され、さらに、
配信優先度情報(Delivery Priority)が記録される。
受信装置は、各放送局が送信する様々な広告コンテンツの配信前にESGを受信可能であり、受信したESGを解析して、配信予定の各広告コンテンツに対応する、以下の優先度情報、すなわち、
(1)配信優先度情報(Delivery Priority)
(2)サービス選択優先度情報(Service Selection Priority)
これらの各優先度情報を取得することが可能となる。
受信装置30は、取得した優先度情報に従って、受信、キャッシュ処理を実行する広告コンテンツを選択することが可能となる。
[12.送信装置と受信装置の構成例について]
次に、通信装置である送信装置(サーバ)20と、受信装置(クライアント)30の装置構成例について、図36、図37を参照して説明する。
図36には、送信装置(サーバ)20と、受信装置(クライアント)30の構成例を示している。
送信装置(サーバ)20は、データ処理部751、通信部752、記憶部753を有する。
受信装置(クライアント)30は、データ処理部771、通信部772、記憶部773、入力部774、出力部775を有する。
データ処理部には通信データ処理部771a、再生処理部771bが含まれる。
送信装置(サーバ)20のデータ処理部751は、データ配信サービスを実行するための各種のデータ処理を実行する。例えばデータ配信サービスの構成データの生成や送信制御を行う。さらに、データ処理部751は、受信装置(クライアント)30に提供するアプリケーション、NRTコンテンツファイル、その他の様々なデータや、シグナリングデータの生成、送信処理を行う。
通信部752は、AVセグメントの他、アプリケーション、NRTコンテンツファイル、その他の様々なデータ、シグナリングデータ等の配信等の通信処理を行う。
記憶部753は配信対象とするAVセグメント、NRTコンテンツファイル、アプリケーション、アプリケーションによって利用されるデータ、シグナリングデータなどが格納される。
さらに、記憶部753は、データ処理部751の実行するデータ処理のワークエリアとして利用され、また各種パラメータの記憶領域としても利用される。
一方、受信装置(クライアント)30は、データ処理部771、通信部772、記憶部773、入力部774、出力部775を有する。
通信部772は、送信装置(サーバ)20から配信されるデータ、例えばAVセグメントやアプリケーション、アプリケーションによって利用されるデータ、NRTコンテンツファイル、シグナリングデータ等を受信する。
データ処理部771は、通信データ処理部771a、再生処理部771bを有し、例えば先に説明した実施例に従った処理等を実行する。
具体的には、アプリケーションを利用したデータ処理等を実行する。
ユーザの指示コマンド、例えばチャンネル選択、アプリケーション起動、インストール等の様々なコマンドは入力部774を介して入力される。
再生データは表示部やスピーカ等の出力部775に出力される。
記憶部773はAVセグメント、アプリケーション、アプリケーションによって利用されるデータ、NRTコンテンツファイル、シグナリングデータなどが格納される。
さらに、記憶部773は、データ処理部771の実行するデータ処理のワークエリアとして利用され、また各種パラメータの記憶領域としても利用される。
図37は、送信装置20、受信装置30として適用可能な通信装置のハードウェア構成例を示している。
CPU(Central Processing Unit)801は、ROM(Read Only Memory)802、または記憶部808に記憶されているプログラムに従って各種の処理を実行するデータ処理部として機能する。例えば、上述した実施例において説明したシーケンスに従った処理を実行する。RAM(Random Access Memory)803には、CPU801が実行するプログラムやデータなどが記憶される。これらのCPU801、ROM802、およびRAM803は、バス804により相互に接続されている。
CPU801はバス804を介して入出力インタフェース805に接続され、入出力インタフェース805には、各種スイッチ、キーボード、マウス、マイクロホンなどよりなる入力部806、ディスプレイ、スピーカなどよりなる出力部807が接続されている。CPU801は、入力部806から入力される指令に対応して各種の処理を実行し、処理結果を例えば出力部807に出力する。
入出力インタフェース805に接続されている記憶部808は、例えばハードディスク等からなり、CPU801が実行するプログラムや各種のデータを記憶する。通信部809は、インターネットやローカルエリアネットワークなどのネットワークを介したデータ通信の送受信部、さらに放送波の送受信部として機能し、外部の装置と通信する。
入出力インタフェース805に接続されているドライブ810は、磁気ディスク、光ディスク、光磁気ディスク、あるいはメモリカード等の半導体メモリなどのリムーバブルメディア811を駆動し、データの記録あるいは読み取りを実行する。
なお、データの符号化あるいは復号は、データ処理部としてのCPU801の処理として実行可能であるが、符号化処理あるいは復号処理を実行するための専用ハードウェアとしてのコーデックを備えた構成としてもよい。
[13.本開示の構成のまとめ]
以上、特定の実施例を参照しながら、本開示の実施例について詳解してきた。しかしながら、本開示の要旨を逸脱しない範囲で当業者が実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本開示の要旨を判断するためには、特許請求の範囲の欄を参酌すべきである。
なお、本明細書において開示した技術は、以下のような構成をとることができる。
(1) 受信装置における所定期間のコンテンツ出力時間に選択出力可能な複数コンテンツを送信する通信部と、
前記複数コンテンツの送信順を決定するデータ処理部を有し、
前記データ処理部は、
視聴可能性の高いコンテンツの送信時間を前記コンテンツ出力時間に最も近い時間とし、視聴可能性の低いコンテンツの送信時間を前記視聴可能性の高いコンテンツの送信時間より前に設定する送信順決定処理を実行する送信装置。
(2) 前記データ処理部は、
視聴可能性の高い順に複数コンテンツを配列して、最も視聴可能性の低いコンテンツを先行して送信し、最も視聴可能性の高いコンテンツの送信時間を前記コンテンツ出力時間に最も近い時間となるように送信順と送信時間を決定する(1)に記載の送信装置。
(3)前記コンテンツは、広告コンテンツである(1)または(2)に記載の送信装置。
(4) 前記コンテンツは、
受信装置において、ユーザ(視聴者)情報に応じて選択出力される広告コンテンツである(1)〜(3)いずれかに記載の送信装置。
(5) 前記コンテンツは、放送番組間に出力される広告コンテンツであり、
前記データ処理部は、
最も視聴可能性の高い広告コンテンツを放送番組に併せて送信する設定とし、
第2番目以降の高い視聴可能性の複数の広告コンテンツを前記放送番組配信処理とは別の配信処理によって並列配信する(1)〜(4)いずれかに記載の送信装置。
(6) 前記データ処理部は、
第2番目以降の高い視聴可能性の複数の広告コンテンツを、NRT(ノンリアルタイム)コンテンツとして視聴可能性の低い順から順に配列して送信する(5)に記載の送信装置。
(7) 前記データ処理部は、
予め取得済みの視聴分布予測データに基づいて、前記複数コンテンツの送信順を決定する(1)〜(6)いずれかに記載の送信装置。
(8) 前記データ処理部は、
前記視聴分布予測データを、視聴率データに基づいて逐次更新する処理を実行する(7)に記載の送信装置。
(9) 前記データ処理部は、
前記複数コンテンツの各々について、受信装置におけるキャッシュ処理優先度判定基準として利用可能な配信優先度情報(Delivery Priority)を設定し、
該配信優先度情報(Delivery Priority)を、前記受信装置に送信する(1)〜(8)いずれかに記載の送信装置。
(10) 前記データ処理部は、
前記複数コンテンツの各々について、視聴可能性の高低に応じた配信優先度情報(Delivery Priority)を設定する(9)に記載の送信装置。
(11) 前記データ処理部は、
前記配信優先度情報(Delivery Priority)を、電子サービスガイド(ESG:Electronic Service Guide)に記録して送信する(9)または(10)に記載の送信装置。
(12) 前記データ処理部は、
前記配信優先度情報(Delivery Priority)を、シグナリングデータに記録して送信する(9)または(10)に記載の送信装置。
(13) 前記シグナリングデータは、FDT(File Delivery Table)である(12)に記載の送信装置。
(14) 所定期間のコンテンツ出力時間に選択出力可能な複数コンテンツを受信し、キャッシュ部に格納するデータ処理部を有し、
前記データ処理部は、
前記複数コンテンツの各々に対応して設定された配信優先度情報(Delivery Priority)を取得し、
取得した配信優先度情報(Delivery Priority)に従い、配信優先度情報(Delivery Priority)の設定値の高いコンテンツを優先して受信し、キャッシュ部に格納する受信装置。
(15) 前記コンテンツは、広告コンテンツである(14)に記載の受信装置。
(16) 前記コンテンツは、
受信装置において、ユーザ(視聴者)情報に応じて選択出力される広告コンテンツである(14)または(15)に記載の受信装置。
(17) 前記データ処理部は、
前記配信優先度情報(Delivery Priority)を、電子サービスガイド(ESG:Electronic Service Guide)から取得する(14)〜(16)ていずれかに記載の受信装置。
(18) 前記データ処理部は、
前記配信優先度情報(Delivery Priority)を、シグナリングデータから取得する(14)〜(16)いずれかに記載の受信装置。
(19) 送信装置において実行するデータ処理方法であり、
データ処理部が、受信装置における所定期間のコンテンツ出力時間に選択出力可能な複数コンテンツの送信順を決定して送信する処理を実行し、
前記データ処理部は、
視聴可能性の高いコンテンツの送信時間を前記コンテンツ出力時間に最も近い時間とし、視聴可能性の低いコンテンツの送信時間を前記視聴可能性の高いコンテンツの送信時間より前に設定する送信順決定処理を実行するデータ処理方法。
(20) 受信装置において実行するデータ処理方法であり、
データ処理部が、所定期間のコンテンツ出力時間に選択出力可能な複数コンテンツを受信し、キャッシュ部に格納する処理を実行し、
前記データ処理部は、
前記複数コンテンツの各々に対応して設定された配信優先度情報(Delivery Priority)を取得し、
取得した配信優先度情報(Delivery Priority)に従い、配信優先度情報(Delivery Priority)の設定値の高いコンテンツを優先して受信し、キャッシュ部に格納するデータ処理方法。
また、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。例えば、プログラムは記録媒体に予め記録しておくことができる。記録媒体からコンピュータにインストールする他、LAN(Local Area Network)、インターネットといったネットワークを介してプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。
なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
以上、説明したように、本開示の一実施例の構成によれば、選択出力可能な広告について送信順を制御し、受信装置において、キャッシュ格納部の容量が限られた状況でも、視聴可能性の高い広告を受信しキャッシュに格納し、特定のユーザに広告コンテンツの再生可能性を高めた構成が実現できる。
具体的には、送信装置が、受信装置における所定期間の広告出力時間に選択出力可能な複数の広告コンテンツの送信順を決定して送信する。視聴可能性の高い広告の送信時間を広告出力時間に最も近い時間とし、視聴可能性の低い広告の送信時間を視聴可能性の高いコンテンツの送信時間より前に設定して送信する。さらに、広告コンテンツの各々に対応する配信優先度情報(Delivery Priority)を受信装置に送信し、受信装置において、優先度情報に基づくキャッシュ処理の要否判定を実行可能とした。
本構成により、選択出力可能な広告について送信順を制御し、受信装置において視聴可能性の高い広告を受信し、キャッシュ格納部に格納することを可能とし、放送地域のユーザに対する広告の再生可能性を高めた構成が実現できる。
10 通信システム
20 送信装置
21 放送サーバ
22 広告サーバ
23 データ配信サーバ
30 受信装置
31 TV
32 PC
33 携帯端末
50 シグナリングデータ
60 AVセグメント
70 その他のデータ
110 アプリケーション制御部
111 アプリケーション実行部
112 広告挿入API
114 キャッシュ制御API
120 再生制御部
121 MPD取得部
122 MPD解析部
123 セグメント取得部
124 セグメント解析部
130 ベースシステム
131 キャッシュ制御部
132 キャッシュ部
133 第1通信部(チューナ)
134 第2通信部(ネットワークI/F)
133 出力制御部
141 復号部
142 出力部
311〜314 ピリオド情報
751 データ処理部
752 通信部
753 記憶部
771 データ処理部
772 通信部
773 記憶部
774 入力部
775 出力部
801 CPU
802 ROM
803 RAM
804 バス
805 入出力インタフェース
806 入力部
807 出力部
808 記憶部
809 通信部
810 ドライブ
811 リムーバブルメディア

Claims (20)

  1. 受信装置における所定期間のコンテンツ出力時間に選択出力可能な複数コンテンツを送信する通信部と、
    前記複数コンテンツの送信順を決定するデータ処理部を有し、
    前記データ処理部は、
    視聴可能性の高いコンテンツの送信時間を前記コンテンツ出力時間に最も近い時間とし、視聴可能性の低いコンテンツの送信時間を前記視聴可能性の高いコンテンツの送信時間より前に設定する送信順決定処理を実行する送信装置。
  2. 前記データ処理部は、
    視聴可能性の高い順に複数コンテンツを配列して、最も視聴可能性の低いコンテンツを先行して送信し、最も視聴可能性の高いコンテンツの送信時間を前記コンテンツ出力時間に最も近い時間となるように送信順と送信時間を決定する請求項1に記載の送信装置。
  3. 前記コンテンツは、広告コンテンツである請求項1に記載の送信装置。
  4. 前記コンテンツは、
    受信装置において、ユーザ(視聴者)情報に応じて選択出力される広告コンテンツである請求項1に記載の送信装置。
  5. 前記コンテンツは、放送番組間に出力される広告コンテンツであり、
    前記データ処理部は、
    最も視聴可能性の高い広告コンテンツを放送番組に併せて送信する設定とし、
    第2番目以降の高い視聴可能性の複数の広告コンテンツを前記放送番組配信処理とは別の配信処理によって並列配信する請求項1に記載の送信装置。
  6. 前記データ処理部は、
    第2番目以降の高い視聴可能性の複数の広告コンテンツを、NRT(ノンリアルタイム)コンテンツとして視聴可能性の低い順から順に配列して送信する請求項5に記載の送信装置。
  7. 前記データ処理部は、
    予め取得済みの視聴分布予測データに基づいて、前記複数コンテンツの送信順を決定する請求項1に記載の送信装置。
  8. 前記データ処理部は、
    前記視聴分布予測データを、視聴率データに基づいて逐次更新する処理を実行する請求項7に記載の送信装置。
  9. 前記データ処理部は、
    前記複数コンテンツの各々について、受信装置におけるキャッシュ処理優先度判定基準として利用可能な配信優先度情報(Delivery Priority)を設定し、
    該配信優先度情報(Delivery Priority)を、前記受信装置に送信する請求項1に記載の送信装置。
  10. 前記データ処理部は、
    前記複数コンテンツの各々について、視聴可能性の高低に応じた配信優先度情報(Delivery Priority)を設定する請求項9に記載の送信装置。
  11. 前記データ処理部は、
    前記配信優先度情報(Delivery Priority)を、電子サービスガイド(ESG:Electronic Service Guide)に記録して送信する請求項9に記載の送信装置。
  12. 前記データ処理部は、
    前記配信優先度情報(Delivery Priority)を、シグナリングデータに記録して送信する請求項9に記載の送信装置。
  13. 前記シグナリングデータは、FDT(File Delivery Table)である請求項12に記載の送信装置。
  14. 所定期間のコンテンツ出力時間に選択出力可能な複数コンテンツを受信し、キャッシュ部に格納するデータ処理部を有し、
    前記データ処理部は、
    前記複数コンテンツの各々に対応して設定された配信優先度情報(Delivery Priority)を取得し、
    取得した配信優先度情報(Delivery Priority)に従い、配信優先度情報(Delivery Priority)の設定値の高いコンテンツを優先して受信し、キャッシュ部に格納する受信装置。
  15. 前記コンテンツは、広告コンテンツである請求項14に記載の受信装置。
  16. 前記コンテンツは、
    受信装置において、ユーザ(視聴者)情報に応じて選択出力される広告コンテンツである請求項14に記載の受信装置。
  17. 前記データ処理部は、
    前記配信優先度情報(Delivery Priority)を、電子サービスガイド(ESG:Electronic Service Guide)から取得する請求項14に記載の受信装置。
  18. 前記データ処理部は、
    前記配信優先度情報(Delivery Priority)を、シグナリングデータから取得する請求項14に記載の受信装置。
  19. 送信装置において実行するデータ処理方法であり、
    データ処理部が、受信装置における所定期間のコンテンツ出力時間に選択出力可能な複数コンテンツの送信順を決定して送信する処理を実行し、
    前記データ処理部は、
    視聴可能性の高いコンテンツの送信時間を前記コンテンツ出力時間に最も近い時間とし、視聴可能性の低いコンテンツの送信時間を前記視聴可能性の高いコンテンツの送信時間より前に設定する送信順決定処理を実行するデータ処理方法。
  20. 受信装置において実行するデータ処理方法であり、
    データ処理部が、所定期間のコンテンツ出力時間に選択出力可能な複数コンテンツを受信し、キャッシュ部に格納する処理を実行し、
    前記データ処理部は、
    前記複数コンテンツの各々に対応して設定された配信優先度情報(Delivery Priority)を取得し、
    取得した配信優先度情報(Delivery Priority)に従い、配信優先度情報(Delivery Priority)の設定値の高いコンテンツを優先して受信し、キャッシュ部に格納するデータ処理方法。
JP2017539841A 2015-09-18 2016-09-05 送信装置、受信装置、およびデータ処理方法 Abandoned JPWO2017047433A1 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2015186008 2015-09-18
JP2015186008 2015-09-18
PCT/JP2016/076051 WO2017047433A1 (ja) 2015-09-18 2016-09-05 送信装置、受信装置、およびデータ処理方法

Publications (1)

Publication Number Publication Date
JPWO2017047433A1 true JPWO2017047433A1 (ja) 2018-07-05

Family

ID=58289120

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017539841A Abandoned JPWO2017047433A1 (ja) 2015-09-18 2016-09-05 送信装置、受信装置、およびデータ処理方法

Country Status (7)

Country Link
US (1) US10904603B2 (ja)
EP (1) EP3352463B1 (ja)
JP (1) JPWO2017047433A1 (ja)
KR (1) KR102628917B1 (ja)
CA (1) CA2998080A1 (ja)
MX (1) MX2018002982A (ja)
WO (1) WO2017047433A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3082084A1 (fr) * 2018-05-31 2019-12-06 Orange Lecture de contenu multimedia

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100527828C (zh) * 2000-05-15 2009-08-12 株式会社电通 控制广告发送的方法和装置
US20020194585A1 (en) * 2001-06-15 2002-12-19 Connelly Jay H. Methods and apparatus for providing ranking feedback for content in a broadcast system
JP4276616B2 (ja) * 2004-11-26 2009-06-10 株式会社ライフビジネスウェザー コマーシャル提供システム
JP4792842B2 (ja) * 2005-07-06 2011-10-12 ソニー株式会社 情報処理装置,情報処理方法,およびコンピュータプログラム
US20070150342A1 (en) * 2005-12-22 2007-06-28 Law Justin M Dynamic selection of blended content from multiple media sources
EP2033465A4 (en) * 2006-06-23 2011-08-24 Nokia Corp RESOURCE-LIMITED ELECTRONIC DEVICE WITH MEANS FOR PRIORIZING SERVICES
US20080127246A1 (en) 2006-09-14 2008-05-29 Nortel Networks Limited Digital media recorder based advertising
KR20060129983A (ko) * 2006-11-08 2006-12-18 (주)아루온게임즈 게임진행 중 광고노출을 통한 게임콘텐츠 무료제공시스템및 그 방법
CN101296246B (zh) * 2007-04-24 2012-06-27 华为技术有限公司 通过单向文件传输协议传输、接收通知消息的方法及装置
KR20100053618A (ko) 2007-08-07 2010-05-20 톰슨 라이센싱 방송 클립 스케줄러
US8359612B2 (en) * 2008-08-13 2013-01-22 Tivo Inc. Content distribution system using transportable memory devices
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
JP2011087103A (ja) 2009-10-15 2011-04-28 Sony Corp コンテンツ再生システム、コンテンツ再生装置、プログラム、コンテンツ再生方法、およびコンテンツサーバを提供
US20110239253A1 (en) * 2010-03-10 2011-09-29 West R Michael Peters Customizable user interaction with internet-delivered television programming
KR20120060134A (ko) * 2010-08-16 2012-06-11 삼성전자주식회사 광고 재생 방법 및 장치
JP2012095149A (ja) * 2010-10-27 2012-05-17 New Knowledge Co Ltd 広告情報処理システムと該システムに用いるプログラム
US8657680B2 (en) * 2011-05-31 2014-02-25 United Video Properties, Inc. Systems and methods for transmitting media associated with a measure of quality based on level of game play in an interactive video gaming environment
CN103975602B (zh) * 2011-10-20 2017-06-09 Lg电子株式会社 广播服务接收方法和广播服务接收装置
CN103650520A (zh) 2012-05-10 2014-03-19 索尼公司 接收设备、接收方法、发送设备、发送方法和程序
US20130347033A1 (en) * 2012-06-22 2013-12-26 United Video Properties, Inc. Methods and systems for user-induced content insertion
JP6348251B2 (ja) 2012-09-13 2018-06-27 サターン ライセンシング エルエルシーSaturn Licensing LLC 端末装置、受信方法、およびプログラム
US8782683B2 (en) 2012-10-12 2014-07-15 At&T Intellectual Property I, Lp Method and apparatus for managing advertising
JP5749295B2 (ja) * 2013-06-19 2015-07-15 ヤフー株式会社 広告配信管理装置、広告配信システム、広告配信管理方法および広告情報管理プログラム
US9258747B2 (en) * 2013-09-17 2016-02-09 Intel IP Corporation User equipment and methods for fast handover failure recovery in 3GPP LTE network
WO2015081260A1 (en) * 2013-11-27 2015-06-04 Cloudwear Responding to an advertisement using a mobile computing device
US20170132659A1 (en) * 2014-01-13 2017-05-11 Google Inc. Potential Revenue of Video Views
US9578385B2 (en) * 2014-02-25 2017-02-21 Rovi Guides, Inc. Systems and methods for sorting media assets based on playback information
US20160260123A1 (en) * 2015-03-06 2016-09-08 Spotify Ab System and method for providing advertisement content in a media content or streaming environment

Also Published As

Publication number Publication date
WO2017047433A1 (ja) 2017-03-23
EP3352463A1 (en) 2018-07-25
EP3352463A4 (en) 2019-03-20
US20180213272A1 (en) 2018-07-26
US10904603B2 (en) 2021-01-26
MX2018002982A (es) 2018-05-02
KR20180058220A (ko) 2018-05-31
KR102628917B1 (ko) 2024-01-25
CA2998080A1 (en) 2017-03-23
EP3352463B1 (en) 2021-08-25

Similar Documents

Publication Publication Date Title
WO2016203850A1 (ja) 受信装置、送信装置、およびデータ処理方法
US20170289616A1 (en) Receiving device, transmitting device, and data processing method
EP2288151A1 (en) Methods and apparatuses for generating channel information, access controlling and delivering and iptv system
CN107534793B (zh) 接收装置、传输装置以及数据处理方法
JP6257611B2 (ja) 個人向けのメディア・コンテンツの提供
JP6359539B2 (ja) レンダリング時の制御
WO2018079295A1 (ja) 情報処理装置、及び、情報処理方法
KR102640835B1 (ko) 송신 장치, 수신 장치, 및 데이터 처리 방법
CN107615774B (zh) 接收装置、发送装置及数据处理方法
WO2017038353A1 (ja) 受信装置、送信装置、およびデータ処理方法
WO2019188393A1 (ja) 情報処理装置、情報処理方法、送信装置、及び送信方法
WO2016067987A1 (ja) 受信装置、送信装置、およびデータ処理方法
WO2017047433A1 (ja) 送信装置、受信装置、およびデータ処理方法
CN107534792B (zh) 接收设备、发送设备以及数据处理方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190820

A762 Written abandonment of application

Free format text: JAPANESE INTERMEDIATE CODE: A762

Effective date: 20200331