JPWO2018034172A1 - 情報処理装置、クライアント装置、及び、データ処理方法 - Google Patents
情報処理装置、クライアント装置、及び、データ処理方法 Download PDFInfo
- Publication number
- JPWO2018034172A1 JPWO2018034172A1 JP2018534344A JP2018534344A JPWO2018034172A1 JP WO2018034172 A1 JPWO2018034172 A1 JP WO2018034172A1 JP 2018534344 A JP2018534344 A JP 2018534344A JP 2018534344 A JP2018534344 A JP 2018534344A JP WO2018034172 A1 JPWO2018034172 A1 JP WO2018034172A1
- Authority
- JP
- Japan
- Prior art keywords
- proxy
- information
- request
- content
- communication
- 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.)
- Pending
Links
- 230000010365 information processing Effects 0.000 title claims abstract description 42
- 238000003672 processing method Methods 0.000 title claims abstract description 18
- 238000004891 communication Methods 0.000 claims abstract description 160
- 230000006854 communication Effects 0.000 claims abstract description 160
- 230000004044 response Effects 0.000 claims abstract description 39
- 238000012545 processing Methods 0.000 claims description 125
- 238000000034 method Methods 0.000 claims description 121
- 230000008569 process Effects 0.000 claims description 76
- 238000013507 mapping Methods 0.000 claims description 18
- 238000012546 transfer Methods 0.000 claims description 15
- 238000005516 engineering process Methods 0.000 abstract description 40
- 230000006870 function Effects 0.000 description 44
- 230000005540 biological transmission Effects 0.000 description 38
- 238000003780 insertion Methods 0.000 description 29
- 230000037431 insertion Effects 0.000 description 29
- 238000010586 diagram Methods 0.000 description 14
- 230000011664 signaling Effects 0.000 description 9
- 230000009471 action Effects 0.000 description 3
- 239000012634 fragment Substances 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 230000003213 activating effect Effects 0.000 description 1
- 230000003044 adaptive effect Effects 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 230000007175 bidirectional communication Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013144 data compression Methods 0.000 description 1
- 238000002716 delivery method Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000009795 derivation Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005401 electroluminescence Methods 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 230000003340 mental effect Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 210000000707 wrist Anatomy 0.000 description 1
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/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/236—Assembling 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/23614—Multiplexing of additional data and video streams
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
- H04H60/35—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users
- H04H60/37—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users for identifying segments of broadcast information, e.g. scenes or extracting programme ID
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
- H04H60/25—Arrangements for updating broadcast information or broadcast-related information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
- H04H60/29—Arrangements for monitoring broadcast services or broadcast-related services
- H04H60/31—Arrangements for monitoring the use made of the broadcast services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
- H04H60/35—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
- H04H60/76—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet
- H04H60/81—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself
- H04H60/82—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself the transmission system being the Internet
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/2517—Translation of Internet protocol [IP] addresses using port numbers
-
- 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/10—Architectures or entities
- H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
-
- 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/1066—Session management
- H04L65/1101—Session protocols
-
- 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/262—Content 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/26258—Content 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
-
- 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/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
- H04N21/43615—Interfacing a Home Network, e.g. for connecting the client to a plurality of peripherals
-
- 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/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
- H04N21/4363—Adapting the video stream to a specific local network, e.g. a Bluetooth® 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/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/437—Interfacing the upstream path of the transmission network, e.g. for transmitting client requests to a VOD server
-
- 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/61—Network physical structure; Signal processing
- H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
- H04N21/6112—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving terrestrial transmission, e.g. DVB-T
-
- 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/61—Network physical structure; Signal processing
- H04N21/6156—Network physical structure; Signal processing specially adapted to the upstream path of the transmission network
- H04N21/6175—Network physical structure; Signal processing specially adapted to the upstream path of the transmission network involving transmission via Internet
-
- 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/61—Network physical structure; Signal processing
- H04N21/6156—Network physical structure; Signal processing specially adapted to the upstream path of the transmission network
- H04N21/6181—Network physical structure; Signal processing specially adapted to the upstream path of the transmission network involving transmission via a mobile phone 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/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/835—Generation of protective data, e.g. certificates
- H04N21/8352—Generation of protective data, e.g. certificates involving content or source identification data, e.g. Unique Material Identifier [UMID]
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Databases & Information Systems (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本技術は、より柔軟に、放送と通信を利用したサービスの運用を行うことができるようにする情報処理装置、クライアント装置、及び、データ処理方法に関する。情報処理装置が、コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入することで、より柔軟に、放送と通信を利用したサービスの運用を行うことができるようになる。本技術は、例えば、家庭内LAN等のネットワークに接続されるゲートウェイ装置や、コンテンツを再生可能なクライアント装置に適用することができる。
Description
本技術は、情報処理装置、クライアント装置、及び、データ処理方法に関し、特に、より柔軟に、放送と通信を利用したサービスの運用を行うことができるようにした情報処理装置、クライアント装置、及び、データ処理方法に関する。
近年、放送サービスを高度化する目的で、放送だけでなく、通信を利用したサービスに関する技術が提案されている(例えば、特許文献1参照)。
ところで、放送と通信を利用したサービスの運用を行うに際して、インターネット上の通信サーバに対し、放送サービスをサービスエントリとしてアクセスしてくるデバイスと、一般のインターネットサイトをサービスエントリとしてアクセスするデバイスとが存在する場合が想定される。
そのような場合において、放送事業者等の事業者からは、それらのデバイスを区別して、アクセスの統計を管理する運用などを行いたいという要請があるが、現状では、そのような要請に応えるための技術方式は確立されていない。
本技術はこのような状況に鑑みてなされたものであり、より柔軟に、放送と通信を利用したサービスの運用を行うことができるようにするものである。
本技術の第1の側面の情報処理装置は、コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入する処理部を備える情報処理装置である。
本技術の第1の側面の情報処理装置は、独立した装置であってもよいし、1つの装置を構成している内部ブロックであってもよい。また、本技術の第1の側面のデータ処理方法は、上述した本技術の第1の側面の情報処理装置に対応するデータ処理方法である。
本技術の第1の側面の情報処理装置、及び、データ処理方法においては、コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報が挿入される。
本技術の第2の側面のクライアント装置は、放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置との接続を処理する処理部と、前記ゲートウェイ装置から、ネットワークを介して転送されてくる前記コンテンツを再生する再生部とを備え、前記ゲートウェイ装置は、プロキシとしての機能を有し、前記処理部は、前記ゲートウェイ装置から前記ネットワークを介して提供される、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報に基づいて、前記プロキシとの接続を確立するクライアント装置である。
本技術の第2の側面のクライアント装置は、独立した装置であってもよいし、1つの装置を構成している内部ブロックであってもよい。また、本技術の第2の側面のデータ処理方法は、上述した本技術の第2の側面のクライアント装置に対応するデータ処理方法である。
本技術の第2の側面のクライアント装置、及び、データ処理方法においては、放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置との接続が処理され、前記ゲートウェイ装置から、ネットワークを介して転送されてくる前記コンテンツが再生される。また、前記ゲートウェイ装置が、プロキシとしての機能を有しており、前記ゲートウェイ装置から前記ネットワークを介して提供される、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報に基づいて、前記プロキシとの接続が確立される。
本技術の第1の側面、及び、第2の側面によれば、より柔軟に、放送と通信を利用したサービスの運用を行うことができる。
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
1.システムの構成
2.本技術の概要
3.HTTPリクエストヘッダの拡張方法
4.トランスペアレントプロキシの発見・接続方法
5.プロキシの発見・接続処理と、拡張ヘッダ挿入処理の流れ
6.変形例
7.コンピュータの構成
2.本技術の概要
3.HTTPリクエストヘッダの拡張方法
4.トランスペアレントプロキシの発見・接続方法
5.プロキシの発見・接続処理と、拡張ヘッダ挿入処理の流れ
6.変形例
7.コンピュータの構成
<1.システムの構成>
(伝送システムの構成例)
図1は、本技術を適用した伝送システムの一実施の形態の構成を示す図である。なお、システムとは、複数の装置が論理的に集合したものをいう。
図1は、本技術を適用した伝送システムの一実施の形態の構成を示す図である。なお、システムとは、複数の装置が論理的に集合したものをいう。
図1において、伝送システム1は、ゲートウェイ装置10、クライアント装置20−1乃至20−N(N:1以上の整数)、放送サーバ40、及び通信サーバ70を含んで構成される。
伝送システム1において、ゲートウェイ装置10と、クライアント装置20−1乃至20−Nは、エンドユーザ宅2に構築された家庭内LAN(Local Area Network)等のネットワーク30を介して、相互に接続され、通信を行うことが可能である。
また、ゲートウェイ装置10は、送信所50から、放送伝送路60を介して送信される放送波を受信する機能とともに、インターネット80に接続可能な通信機能も有している。これにより、ゲートウェイ装置10は、インターネット80を介して、通信サーバ70と相互に接続され、通信を行うことが可能である。
ゲートウェイ装置10は、例えば、ゲートウェイ機能を提供するための専用のサーバや、通信機能を有するテレビ受像機やセットトップボックス(STB:Set Top Box)、ネットワークストレージなどから構成される。
ゲートウェイ装置10は、送信所50を介して、放送サーバ40から送信されてくる放送波を受信し、放送波から得られるコンテンツのデータを、ネットワーク30に接続されたクライアント装置20−1乃至20−Nに送信(転送)する。
また、ゲートウェイ装置10は、インターネット80を介して、通信サーバ70から送信されてくるコンテンツのデータを受信し、ネットワーク30に接続されたクライアント装置20−1乃至20−Nに送信(転送)する。
なお、ゲートウェイ装置10の詳細な構成は、図2を参照して後述する。
クライアント装置20−1は、ネットワーク30を介してゲートウェイ装置10から送信(転送)されてくるコンテンツを受信して再生する受信機である。すなわち、クライアント装置20−1は、エンドユーザの操作などに応じて、ゲートウェイ装置10を介して、放送経由又は通信経由で配信されるコンテンツを再生することができる。
クライアント装置20−1は、テレビ受像機やセットトップボックスなどの固定受信機、あるいは、スマートフォンや携帯電話機、タブレット型コンピュータなどのモバイル受信機である。
クライアント装置20−2乃至20−Nは、クライアント装置20−1と同様に、家庭内で使用される固定受信機又はモバイル受信機から構成され、ゲートウェイ装置10を介して、放送経由又は通信経由で配信されるコンテンツを受信して再生する。
なお、以下の説明では、クライアント装置20−1乃至20−Nを、特に区別する必要がない場合、単に、クライアント装置20と称するものとする。また、クライアント装置20の詳細な構成は、図3を参照して後述する。
放送サーバ40は、例えば、放送局などの放送事業者により提供されるサーバであって、送信所50に設置される送出設備と、専用線などの所定の回線を介して接続される。
放送サーバ40は、番組やCM等のコンテンツのファイル(データ)や制御情報(シグナリング)を処理し、その結果得られるデータを、専用線を介して送信所50内の送出設備に送信する。そして、送信所50内の送出設備は、放送サーバ40からのデータに対し、必要な処理(変調処理等)を施すことで、その結果得られる放送波が、放送伝送路60を介して、エンドユーザ宅2内のゲートウェイ装置10により受信される。
通信サーバ70は、例えば、放送局などの放送事業者やその他の事業者により提供されるサーバであって、インターネット80に接続される。
通信サーバ70は、ゲートウェイ装置10からのリクエストに応じて、番組やCM等のコンテンツのファイルや制御情報を処理し、その結果得られるデータを、インターネット80を介して送信(ストリーミング配信)する。
なお、図1の伝送システムでは、ゲートウェイ装置10とクライアント装置20が、エンドユーザ宅2内に配置される場合を説明したが、ゲートウェイ装置10は、エンドユーザ宅2内に限らず、例えば、ケーブルオペレータのヘッドエンドや、モバイル網の基地局などに設置されるようにして、より広範囲は領域をカバーできるようにしてもよい。
すなわち、例えば、ゲートウェイ装置10が、ケーブルオペレータのヘッドエンドに設置される場合、クライアント装置20は、同一のエンドユーザ宅内ではなく、ケーブルテレビのサービスを契約している各エンドユーザ宅内に設置されることになる。また、例えば、ゲートウェイ装置10が、モバイル網の基地局に設置される場合、クライアント装置20は、モバイルサービスを契約しているエンドユーザが、屋内又は屋外で所持しているデバイスとなる。
また、クライアント装置20は、車両に搭載される車載機器であってもよい。さらに、図1の伝送システム1において、ネットワーク30又はインターネット80に接続されるデバイスやサーバの間で行われる通信は、無線通信及び有線通信は勿論、無線通信と有線通信とが混在した通信、すなわち、ある区間では無線通信が行われ、他の区間では有線通信が行われるようなものであってもよい。
(ゲートウェイ装置の構成)
図2は、図1のゲートウェイ装置10の構成例を示す図である。
図2は、図1のゲートウェイ装置10の構成例を示す図である。
図2において、ゲートウェイ装置10は、処理部100、チューナ101、通信I/F102、通信I/F103、及び記憶部104から構成される。
処理部100は、例えば、CPU(Central Processing Unit)やマイクロプロセッサ等から構成される。処理部100は、各種の演算処理や、各部の動作制御などの処理を行う。
チューナ101は、アンテナを介して受信された放送波に対し、必要な処理(復調処理等)を施し、その結果得られる多重化ストリームを、処理部100に供給する。処理部100は、チューナ101から供給される多重化ストリームを処理し、その結果得られるデータを、通信I/F103に供給する。
通信I/F102は、処理部100からの制御に従い、インターネット80に接続された通信サーバ70に、コンテンツの配信を要求する。通信I/F102は、通信サーバ70から配信されるコンテンツのストリームを、インターネット80を介して受信し、処理部100に供給する。処理部100は、通信I/F102から供給されるコンテンツのストリームを処理し、その結果得られるデータを、通信I/F103に供給する。
通信I/F103は、ネットワーク30に接続されたクライアント装置20から送信されてくるデータを受信し、処理部100に供給する。また、通信I/F103は、処理部100から供給されるデータを、ネットワーク30を介して、クライアント装置20に送信する。
なお、通信I/F102と通信I/F103は、例えば、通信インターフェース回路等から構成される。また、図2のゲートウェイ装置10においては、説明の都合上、通信I/F102と通信I/F103を、別のブロックとして説明したが、通信I/F102と通信I/F103を共通化して、1つの通信I/Fとしてもよい。
記憶部104は、例えば、半導体メモリやハードディスクドライブ(HDD:Hard Disk Drive)等から構成される。記憶部104は、処理部100からの制御に従い、各種のデータを記憶する。
処理部100は、UPnP/SSDPサーバ111、プロキシアプリマネージャ112、ローカルプロキシ113、及びSLS処理系114を含む。
UPnP/SSDPサーバ111と、プロキシアプリマネージャ112は、ゲートウェイ装置10で稼働するサービスであって、ネットワーク30に接続されるクライアント装置20と、ローカルプロキシ113との接続を確立するための処理を行う。
なお、UPnP/SSDPサーバ111とプロキシアプリマネージャ112で行われる処理の詳細は、図17及び図18を参照して後述する。また、UPnP/SSDPサーバ111は、ウェブサーバ(ローカルウェブサーバ)の機能を有するようにすることができる。
ローカルプロキシ113は、ゲートウェイ装置10で稼働するサービスであって、ネットワーク30に接続されたクライアント装置20からのリクエストを、インターネット80に接続された通信サーバ70に送信する。また、ローカルプロキシ113は、通信サーバ70からのコンテンツのストリームを、インターネット80を介して受信し、ネットワーク30に接続されたクライアント装置20に送信(転送)する。
なお、ローカルプロキシ113は、クライアント装置20からのリクエストに対し、拡張ヘッダ挿入処理を行うが、その処理の詳細は、図17、図18、及び図27などを参照して後述する。
SLS処理系114は、放送経由又は通信経由で取得される制御情報であるSLS(Service Layer Signaling)に関する処理を行う。なお、SLSの詳細は、図6を参照して後述する。また、SLS処理系114で行われる処理の詳細は、図27を参照して後述する。
ゲートウェイ装置10は、以上のように構成される。
(クライアント装置の構成)
図3は、図1のクライアント装置20の構成例を示す図である。
図3は、図1のクライアント装置20の構成例を示す図である。
図3において、クライアント装置20は、処理部200、通信I/F201、表示部202、及びスピーカ203から構成される。
処理部200は、例えば、CPUやマイクロプロセッサ等から構成される。処理部200は、各種の演算処理や、各部の動作制御などの処理を行う。
通信I/F201は、例えば、通信インターフェース回路等から構成される。
通信I/F201は、処理部200からの制御に従い、ネットワーク30に接続されたゲートウェイ装置10に対し、コンテンツの配信を要求する。また、通信I/F201は、ネットワーク30を介して、ゲートウェイ装置10から送信(転送)されてくるコンテンツのデータを受信し、処理部200に供給する。
処理部200は、通信I/F201から供給されるコンテンツのデータを処理し、その結果得られるデータのうち、ビデオデータを、表示部202に供給し、オーディオデータを、スピーカ203に供給する。
表示部202は、例えば、LCD(Liquid Crystal Display)やOELD(Organic Electroluminescence Display)等のディスプレイから構成される。表示部202は、処理部200から供給されるビデオデータに対応する映像を表示する。スピーカ203は、処理部200から供給されるオーディオデータに対応する音声を出力する。
なお、表示部202が、タッチパネルの機能を有している場合には、当該タッチパネルに対するエンドユーザの操作に応じた操作信号が処理部200に供給され、処理部200は、当該操作信号に応じた処理を行う。また、図3には図示していないが、物理的なボタン等の入力部を設けて、当該入力部に対するエンドユーザの操作に応じた操作信号が、処理部200に供給されるようにしてもよい。
処理部200は、アプリケーション211及びブラウザ212を含む。アプリケーション211及びブラウザ212により、レンダラ機能が提供される。
アプリケーション211は、ネットワーク30に接続されるクライアント装置20が、ゲートウェイ装置10で稼働するローカルプロキシ113との接続を確立するための処理を行う。なお、アプリケーション211で行われる処理の詳細は、図17及び図18を参照して後述する。
ブラウザ212は、通信I/F201から供給されるコンテンツのデータであって、ゲートウェイ装置10により放送経由又は通信経由で受信されたデータを処理し、コンテンツを再生する。
なお、ブラウザ212は、DASHプレーヤとしての機能を有するが、その詳細は、図6を参照して後述する。また、ブラウザ212で行われる処理の詳細は、図17、図18、及び図27などを参照して後述する。
クライアント装置20は、以上のように構成される。
(受信側の装置の実装例)
ところで、図1の伝送システム1においては、ゲートウェイ装置10が、放送経由又は通信経由で、送信側のサーバから配信されるデータを、受信側のクライアント装置20に転送するための役割を担う構成を説明したが、その役割を、ネットワーク30に接続されたクライアント装置20のいずれかが担うようにした構成を採用することもできる。
ところで、図1の伝送システム1においては、ゲートウェイ装置10が、放送経由又は通信経由で、送信側のサーバから配信されるデータを、受信側のクライアント装置20に転送するための役割を担う構成を説明したが、その役割を、ネットワーク30に接続されたクライアント装置20のいずれかが担うようにした構成を採用することもできる。
ここでは、例えば、エンドユーザ宅2において、ネットワーク30に接続された複数のクライアント装置20のうち、クライアント装置20−1が、チューナ及び通信I/Fなどのゲートウェイ装置10と同様の機能を有し、放送経由及び通信経由で配信されるコンテンツのデータを受信可能な場合を想定する。
この場合において、クライアント装置20−2乃至20−Nは、ゲートウェイとして動作するクライアント装置20−1を介して、放送経由又は通信経由で配信されるコンテンツのデータを受信することができる。ただし、この場合でも、クライアント装置20−2乃至20−Nは、ゲートウェイ装置10に接続して、放送経由又は通信経由で配信されるコンテンツのデータを受信するようにしてもよい。
これらの関係をまとめると、図4に示すようになる。すなわち、図4において、ゲートウェイ装置10は、図2の構成に示したように、チューナ101とともに、処理部100として、UPnP/SSDPサーバ111、プロキシアプリマネージャ112、ローカルプロキシ113、及びSLS処理系114を含んで構成される。
また、図4において、クライアント装置20には、レンダラ機能のみを有する一般クライアント装置20と、レンダラ機能だけでなく、ゲートウェイ機能をも有するオールインワン型(All in One)のクライアント装置20との2種類がある。
なお、以下の説明では、適宜、オールインワンクライアント装置20を、「AOC(All in One Client)」とも記述し、一般クライアント装置20を、「NC(Normal Client)」とも記述する。また、ゲートウェイ装置10は、「GW(Gateway)」とも記述する。
一般クライアント装置(NC)20は、図3の構成に示したように、アプリケーション211及びブラウザ212によるレンダラ機能を含んで構成される。一方で、オールインワンクライアント装置(AOC)20は、レンダラ機能のほかに、ゲートウェイ装置(GW)10と同様に、チューナ101、UPnP/SSDPサーバ111、プロキシアプリマネージャ112、ローカルプロキシ113、及びSLS処理系114によるゲートウェイ機能を含んで構成される。
すなわち、一般クライアント装置(NC)20は、ゲートウェイ機能を有するゲートウェイ装置(GW)10、又はオールインワンクライアント装置(AOC)20を介して、送信側のサーバとデータをやりとりするが、オールインワンクライアント装置(AOC)20は、自身がゲートウェイ機能を有するため、単独で、送信側のサーバとデータをやりとりすることができる。
より具体的には、図5に示すような関係として表すことができる。
図5において、一般クライアント装置(NC)20は、ゲートウェイ装置(GW)10又はオールインワンクライアント装置(AOC)20を介して、放送経由又は通信経由のデータを受信する。すなわち、ゲートウェイ装置(GW)10は、一般クライアント装置(NC)20に対し、ゲートウェイ機能を提供することができる。また、オールインワンクライアント装置(AOC)20は、一般クライアント装置(NC)20に対し、ゲートウェイ機能を提供することができる。
また、オールインワンクライアント装置(AOC)20は、ゲートウェイ装置(GW)10からゲートウェイ機能の提供を受けて、一般クライアント装置(NC)20として機能することもできるが、通常は、自身のゲートウェイ機能を使って、放送経由又は通信経由のデータを受信する。
ゲートウェイ装置(GW)10は、ゲートウェイとして機能し、送信側のサーバから放送経由又は通信経由で配信されるデータを、一般クライアント装置(NC)20又はオールインワンクライアント装置(AOC)20に送信する。また、ゲートウェイ装置(GW)10は、一般クライアント装置(NC)20又はオールインワンクライアント装置(AOC)20からのリクエストに対し、拡張ヘッダ挿入処理を施し、その結果得られるリクエストを、通信経由で送信する。
オールインワンクライアント装置(AOC)20は、ゲートウェイとして機能し、送信側のサーバから放送経由又は通信経由で配信されるデータを、自身で処理するか、又は一般クライアント装置(NC)20に送信する。また、オールインワンクライアント装置(AOC)20は、自身で処理したリクエスト、又は一般クライアント装置(NC)20からのリクエストに対し、拡張ヘッダ挿入処理を施し、その結果得られるリクエストを、通信経由で送信する。
なお、受信側のクライアント装置20に対し、送信側のサーバからのデータを中継するゲートウェイ機能を有する装置としては、放送経由と通信経由のデータを、同一の装置で処理してもよいし、放送経由のデータを処理する装置と、通信経由のデータを処理する装置とが異なるようにしてもよい。例えば、一般クライアント装置(NC)20に対する、放送経由のデータを、ゲートウェイ装置(GW)10が処理し、通信経由のデータを、オールインワンクライアント装置(AOC)20が処理することができる。
(本技術のプロトコルスタック)
図6は、本技術のIP伝送方式のプロトコルスタックの例を示す図である。
図6は、本技術のIP伝送方式のプロトコルスタックの例を示す図である。
デジタル放送の伝送方式として、現状では、MPEG2-TS(Transport Stream)方式が広く普及しているが、今後は、通信の分野で用いられているIP(Internet Protocol)パケットをデジタル放送に用いたIP伝送方式が普及することが想定されている。
例えば、次世代地上波放送規格の1つであるATSC(Advanced Television Systems Committee)3.0においても、IP伝送方式を採用して、より高度なサービスを提供できるようにすることが期待されている。本技術においても、ATSC3.0等と同様に、IP伝送方式を採用することができる。
図6において、最も下位の階層は、物理層(Physical Layer)とされる。ATSC3.0等のIP伝送方式のデジタル放送では、一方向の放送を利用した伝送に限らず、一部のデータを、双方向の通信を利用して伝送する場合があるが、放送(Broadcast)を利用する場合、その物理層は、サービス(チャネル)のために割り当てられた放送波の周波数帯域等が対応することになる。
物理層(Physical Layer)の上位の階層は、データリンク層(Data Link Layer)とされる。また、データリンク層の上位の階層は、IP(Internet Protocol)層とUDP(User Datagram Protocol)層とされる。IP層とUDP層は、通信の階層モデルにおけるネットワーク層とトランスポート層に相当する層であり、IPアドレスとポート番号により、IPパケットとUDPパケットが特定される。
ここで、ATSC3.0では、制御情報(シグナリング)として、LLS(Low Level Signaling)とSLS(Service Layer Signaling)を用いることが想定されている。LLSは、SLSよりも下位の層で伝送される制御情報である。SLSは、サービス単位の制御情報である。すなわち、ATSC3.0では、トランスポート層の制御情報が、LLSとSLSの2階層で伝送される。
LLSには、SLT(Service List Table)等のメタデータが含まれる。SLTメタデータは、サービス(チャネル)の選局に必要な情報など、放送ネットワークにおけるストリームやサービスの構成を示す基本情報を含む。このSLTメタデータは、UDPパケットを含むIPパケットであるUDP/IPパケットに含めて伝送される。ただし、SLTメタデータを格納したUDP/IPパケットは、特別なIPアドレスとポート番号で伝送されることになる。
IP層とUDP層に隣接する上位の階層は、ROUTE(Real-time Object Delivery over Unidirectional Transport)とされる。ROUTEは、ストリーミングファイル転送用のプロトコルであって、FLUTE(File Delivery over Unidirectional Transport)を拡張したものである。
このROUTEセッションにより、サービスごとに、SLSのファイル(Signaling)や、NRT(Non Real Time)コンテンツのファイル(NRT)、DASHセグメントファイル(DASH)などが伝送される。
ここで、SLSは、サービスレベルの制御情報であり、対象のサービスに属するコンポーネントの探索と選択に必要な情報や属性などを提供するものである。SLSは、USBD(User Service Bundle Description),S-TSID(Service-based Transport Session Instance Description),MPD(Media Presentation Description)等のメタデータを含む。
USBDメタデータは、他のメタデータの取得先などの情報を含む。なお、USBDメタデータの詳細は、図14を参照して後述する。
S-TSIDメタデータは、LSID(LCT Session Instance Description)をATSC3.0向けに拡張したものであって、ROUTEプロトコルの制御情報である。また、S-TSIDメタデータは、ROUTEセッションで伝送されるEFDT(Extended FDT)を特定することができる。EFDTは、FLUTEで導入されていたFDT(File Delivery Table)を拡張したものであって、転送用の制御情報である。
MPDメタデータは、MPEG-DASHに準拠したストリーミング配信を行うために用いられる、ビデオやオーディオのファイルの制御情報である。なお、MPDメタデータの詳細は、図7乃至図11、及び図14などを参照して後述する。
ここで、MPEG-DASHは、OTT-V(Over The Top Video)に従ったストリーミング配信規格であって、HTTP(Hypertext Transfer Protocol)をベースとしたストリーミングプロトコルを用いたアダプティブストリーミング配信に関する規格である。
このMPEG-DASHの規格では、ビデオやオーディオのファイルの制御情報であるメタデータを記述するためのマニフェストファイルと、動画のコンテンツを伝送するためのファイルフォーマットが規定されている。ここでは、前者のマニフェストファイルが、MPD(Media Presentation Description)と称され、後者のファイルフォーマットは、セグメントフォーマットとも称される。
また、トランスポート・プロトコルとして、ROUTEを用いる場合には、ストリーミングのファイルフォーマットとして、MP4ファイルフォーマットを用いることができる。MP4ファイルフォーマットは、ISO/IEC 14496-12で規定されているISO BMFF(ISO Base Media File Format)の派生フォーマットである。
ROUTEセッションで伝送されるセグメントは、イニシャライゼイションセグメント(IS:Initialization Segment)と、メディアセグメント(MS:Media Segment)から構成される。イニシャライゼイションセグメントは、データ圧縮方式等の初期化情報を含んでいる。また、メディアセグメントは、ビデオやオーディオ、字幕のストリームのデータを格納している。すなわち、このメディアセグメントが、DASHセグメント(DASHセグメントファイル)に相当するものである。
このように、番組等のコンテンツを構成するサービスコンポーネント(ビデオやオーディオ、字幕等)のストリームデータは、ISO BMFFの規格に準じたDASHセグメント単位で、ROUTEセッションにより伝送されることになる。
なお、NRTコンテンツは、受信機のストレージに一旦蓄積された後で再生が行われる。また、NRTコンテンツ以外のファイル(例えば、アプリケーションや電子サービスガイド(ESG:Electronic Service Guide)のファイル)がROUTEセッションで伝送されるようにしてもよい。
また、LLSとしてのSLTメタデータや、SLSとしてのUSBD,S-TSID,MPD等のメタデータは、例えば、XML(Extensible Markup Language)等のマークアップ言語により記述されたテキスト形式のデータとすることができる。
一方で、双方向の通信(Broadband)を利用する場合、その物理層(Physical Layer)の上位の階層は、データリンク層(Data Link Layer)とされる。また、データリンク層の上位の階層は、ネットワーク層に相当するIP層とされる。IP層に隣接する上位階層は、トランスポート層に相当するTCP(Transmission Control Protocol)層とされ、さらに、TCP層に隣接する上位階層は、アプリケーション層に相当するHTTP層とされる。
すなわち、これらの階層によって、図1のインターネット80等の通信回線で稼働するTCP/IPなどのプロトコルが実装される。
HTTP層に隣接する上位階層のうち、一部の階層は、制御情報(Signaling)と、NRTコンテンツ(NRT)とされる。この制御情報としては、上述したROUTEセッションで伝送される制御情報など、すべての制御情報が含まれる。また、NRTコンテンツは、通信経由で取得されるコンテンツであって、例えば、アプリケーションが含まれる。
HTTP層に隣接する上位階層のうち、上述した階層以外の他の階層は、DASHセグメント(DASH)とされる。すなわち、双方向の通信系のストリーミング配信では、VOD(Video On Demand)番組等のコンテンツを構成するサービスコンポーネント(ビデオやオーディオ、字幕等)のストリームデータが、ISO BMFFの規格に準じたDASHセグメント単位で伝送されることになる。
以上のように、本技術のIP伝送方式のプロトコルスタックにおいては、一方向の放送系の階層と、双方向の通信系の階層の一部が共通のプロトコルとなって、一方向の放送と双方向の通信で、コンテンツを構成するサービスコンポーネントのストリームデータを、ISO BMFFの規格に準じたDASHセグメント単位で伝送することができる。
そのため、一方向の放送系のストリーミング配信と、双方向の通信系のストリーミング配信の双方を行う場合において、上位の階層のプロトコルが共通化されているため、例えば、クライアント装置20、放送サーバ40や通信サーバ70では、実装の負担や処理の負担を軽減することができる。
(MPDメタデータの詳細)
次に、図7乃至図11を参照して、SLSとして伝送されるMPDメタデータの詳細を説明する。
次に、図7乃至図11を参照して、SLSとして伝送されるMPDメタデータの詳細を説明する。
MPDメタデータには、Period要素、AdaptationSet要素、及び、Representation要素が階層構造で記述されている。
例えば、図7に示すように、ルート要素となるMPD要素の下には、時間の区切りを示すPeriod要素があり、さらに、Period要素の下に、ビデオやオーディオ、字幕などのそれぞれのストリーム(エレメンタリストリーム)ごとに、AdaptationSet要素を配置して、それぞれのストリームの属性を記述する。
また、AdaptationSet要素の下に、同一のストリーム(エレメンタリストリーム)から派生する、レート等の属性の異なる複数のストリームごとに、Representation要素に分けて、それぞれのレート等の属性を記述する。なお、Representation要素は、時間軸上で、複数のセグメント(Segment)に分割される。
クライアント装置20では、SLSとして伝送されるMPDメタデータをパースし、Representation要素に記述されたストリームに指定されるレートの値を参考にして、クライアント装置20のおかれているネットワーク環境に応じた最適なストリームを選択できるようになっている。
図8には、MPDメタデータにおける、Period要素と、AdaptationSet要素と、Representation要素との関係を詳細に示している。
なお、Representation要素の下には、Representation要素がさらに複数のストリームから構成される場合に、各々のストリームの属性を記述するために、SubRepresentation要素を配置することができる。
ここで、MPDメタデータに記述されるセグメントファイルは、URL(バイトレンジ)により特定される。セグメントは、Representation要素の一部であって、1つのRepresentation要素は、以下のいずれかにより構成される。
(1)1つかそれ以上のセグメントリスト
(2)1つのセグメントテンプレート
(3)1つかそれ以上のベースURLと最大1つのセグメントベース(この場合にはセグメントリストも、セグメントテンプレートもない)
(2)1つのセグメントテンプレート
(3)1つかそれ以上のベースURLと最大1つのセグメントベース(この場合にはセグメントリストも、セグメントテンプレートもない)
以下、上記の(1)乃至(3)に対応するMPDメタデータの記述例を示す。
図9は、セグメントベース(SegmentBase)を利用する場合のMPDメタデータの例を示す図である。
図9に示すように、セグメントベースは、1つのRepresentation要素に、1つのメディアセグメント(セグメント)しかない場合に利用される。図9において、初期化情報のバイト列とRAP(Random Access Points)のバイト列が、ファイルの最初の834バイト以内に収まっている。なお、この834バイトは、SegmentBase要素のindexRange属性により記述される。
図10は、セグメントリスト(SegmentList)を利用する場合のMPDメタデータの例を示す図である。
図10に示すように、セグメントリストは、1つのRepresentation要素に、複数のセグメントURLが配置される場合に利用される。図10のRepresentation要素において、SegmentList要素には、再生順に配置される複数のSegmentURL要素が列記される。
SegmentURL要素は、DASHセグメントファイルのURL(そのファイル内のバイトレンジ)により表現される。なお、SegmentList要素の最初に配置されるInitilization要素には、初期化情報を格納したファイル(InitSegment)を指示している。
図11は、セグメントテンプレート(SegmentTemplate)を利用する場合のMPDメタデータの例を示す図である。
図11に示すように、セグメントテンプレートは、セグメントURLを自動生成するときに利用する。このユースケースの典型的な例としては、ライブストリーミングがある。すなわち、セグメントテンプレートにおいては、SegmentTemplate要素に記述されるセグメントURLのひな形の中の特別なパラメタを動的に置き換えていくことにより、完全なセグメントURLのリストを生成する。
具体的には、SegmentTemplate要素のmedia属性の属性値として記述されるURLのうち、"$Number$"の部分が、置換パラメタ(ReplacementParameter)に相当し、当該パラメタを、startNumber属性の値から開始して、順次インクリメントしながら書き換えることで、セグメントURLが生成される。なお、このセグメントテンプレートを利用することで、MPDメタデータのサイズを非常に小さくすることが可能となる。
<2.本技術の概要>
ところで、伝送システム1においては、コンテンツの配信側(放送事業者)により管理されるサーバ(例えば通信サーバ70)で、あるコンテンツに対するクライアント装置20からのHTTPリクエストの履歴により、アクセス統計(視聴率)を管理するような運用が想定される。なお、ここでのコンテンツのデータは、DASHセグメントファイルのシーケンスのような、1つのコンテンツから生成されるチャンク化されたファイルシーケンス、又はフラグメントシーケンスにより伝送される。
このような運用を行う場合に、チャンク化された各々のDASHセグメントに対するHTTPリクエストを記録するとき、各々のリクエスト間の相関がわかりにくいと、同一のコンテンツに対するリクエストのシーケンスであるかどうかを判断することが難しい。
一方で、HTTPリクエストのリクエストヘッダ(以下、HTTPリクエストヘッダという)に記述されるリクエストURLの内容を解析して、同じパターンを特定することにより、HTTPリクエストのシーケンスを関連付ける(まとめる)ことは可能ではある。
しかしながら、それらのURLの内容の相関がわかりやすい場合には、この方法を適用することができるが、同一のコンテンツのデータから生成されたDASHセグメントファイルであっても、MPDメタデータに記述されるAdaptationSet要素や、Representation要素の構成方法によっては、そこに含まれるセグメントURL(segmentUrl)が、それぞれ、全く相関のない内容になる可能性がある。
そのような構成を記述したMPDメタデータの例を、図12に示している。図12のMPDメタデータにおいては、Period要素と、AdaptationSet要素と、Representation要素とが階層構造をなしているが、Representation要素には、セグメントリストとして、複数のセグメントURLが記述されている。
このセグメントURLは、BaseURL要素の値として指定されるベースURLと、SegmentURL要素のmedia属性の値として指定されるファイルのURLとを結合することで、完全なURLが得られる。
すなわち、図12のMPDメタデータにおいては、同一のコンテンツから生成される2つのRepresentation要素の系列が記述され、一方の系列が、"http://cdn1.com/seg-201.mp4","http://cdn1.com/seg-202.mp4",・・・となり、他方の系列が、"http://cdn2.com/s101.mp4","http://cdn2.com/s102.mp4",・・・となる。
なお、この例では、CDN(Content Delivery Network)サービスを利用して、同一のコンテンツを、異なるCDNのサーバから、配信元のパスを変えて配信する運用が行われる場合を示している。
ここで、"http://cdn1.com/seg-201.mp4"と"http://cdn2.com/s101.mp4"との関係などからは、図12の2つのRepresentation要素に記述された系列ごとのDASHセグメントのシーケンスが、同一のコンテンツから生成されたDASHセグメントのシーケンスであることを類推することは、容易ではない。
また、仮に、リクエストURLの内容に相関がある場合でも、HTTPリクエストを受けた通信サーバ70では、以前に処理したURLのシーケンスを、常に保持しておいて、後続のHTTPリクエストのリクエストURLとの比較を行い、その内容に相関があれば、それらを同一のコンテンツから生成されるDASHセグメントであると類推して記憶するといった処理が必要となる。
なお、ここで、リクエストURLの内容に相関がある場合とは、例えば、"http://cdn1.com/seg-201.mp4","http://cdn1.com/seg-202.mp4",・・・のように、時系列順に並び、ある部分が規則性のある整数としてエンコードされる場合などである。
しかしながら、このような運用を行う場合、通信サーバ70側で、過去のリクエストURLの履歴(状態情報)を保持する負担が大きくなり、かつ、リクエストURLの比較や、同一の出元となるコンテンツ(コンテンツのソースの同一性)の可能性の類推などの余計な処理負荷を増加させるため、スケーラビリティを損ねることになる。したがって、通信サーバ70側で、リクエストURLのみに頼るコンテンツの同一性の類推を行い、その結果を用いてアクセス統計の記録を行うことは、現実的ではない。
その一方で、例えば、現在策定中のATSC3.0においては、サービスを提供する放送事業者等は、ATSC3.0の放送サービス(以下、ATSC3.0サービスともいう)で配信されるDASHセグメントへのアクセス統計を、次のように行いたいという要請がある。
すなわち、ATSC3.0サービス(放送サービス)を、サービスエントリとしてアクセスしてくるエンドユーザデバイス(以下、ATSC3.0エンドデバイスともいう)と、そうではない一般のインターネットのサイトを、サービスエントリとしてアクセスしてくるエンドユーザデバイス(以下、一般エンドデバイスともいう)とを区別し、かつ、既存のCDNのロギングの機能を利用して、DASHセグメントへのアクセス統計を記録したいという要請がある。
なお、ここでのATSC3.0エンドデバイスには、一般クライアント装置(NC)20と、オールインワンクライアント装置(AOC)20が共に該当する可能性がある。また、一般エンドデバイスについても、一般クライアント装置(NC)20と、オールインワンクライアント装置(AOC)20が共に該当する可能性がある。
また、通信サーバ70が、CDNのサーバとして提供されるようにすることで、通信サーバ70によって、コンテンツのデータ(DASHセグメントファイル)の配信が行われるときに、既存のCDNのロギングの機能を利用して、DASHセグメントのアクセス統計を記録するという運用が可能となる。ここでは、既存のCDNの機能を利用することで、追加コストを最小限に抑えることができる。
以上のように、放送事業者等の事業者からは、ATSC3.0エンドデバイスと一般エンドデバイスとを区別して、アクセスの統計を管理する運用などを行いたいという要請があるが、現状では、そのような要請に応えるための技術方式は確立されていない。
そこで、本技術では、放送と通信を利用したサービスの運用を行う場合において、ATSC3.0サービス(放送サービス)を導線(サービスエントリ)として、通信経由でアクセスしてくるATSC3.0エンドデバイス(クライアント装置20)を識別可能にすることで、より柔軟に、放送と通信を利用したサービスの運用を行うことができるようにする。
すなわち、本技術では、放送サービスをサービスエントリとして、通信経由で、DASHセグメントに対するHTTPリクエストが送信される場合に、HTTPリクエストヘッダに対し、当該DASHセグメントの元となるコンテンツのソースの同一性を識別するための識別情報(以下、ソース識別情報という)が挿入されるようにする。
例えば、同一のコンテンツであっても、例えば、レート等の属性や、放送経由又は通信経由等の配信経路が異なる場合があり、そのような場合でも、コンテンツのソースが同一である場合には、同一のソース識別情報(ソース同一性を識別する識別子)が付加されるようにすることで、ソースの同一性を識別することができる。
これにより、通信サーバ70側では、HTTPリクエストヘッダに含まれるソース識別情報を記憶しておくだけで、異なるサービスの配信に起因する、DASHセグメントに対するHTTPリクエストのリクエストURLの間の相関性を、HTTPリクエストごとに処理する必要がなくなり、通信サーバ70側の処理負荷を大幅に低減することができる。
ただし、HTTPリクエストに対し、このような特殊なヘッダを追加する処理は、一般のDASHクライアント(DASHプレーヤ)の実装に、容易に加えることはできない。
そこで、本技術では、ATSC3.0サービス(放送サービス)で配信されるDASHセグメントに対するHTTPリクエストについては、それらのHTTPリクエストをすべて、ATSC3.0のプロキシサーバ(ゲートウェイ装置10で稼働するローカルプロキシ113)を経由させるようにする。これにより、ローカルプロキシ113上のモジュールやサーバサイドスクリプトなどによって、HTTPリクエストヘッダに対し、拡張ヘッダ(ソース識別情報)を、容易に挿入することができるようになる。
また、このローカルプロキシ113は、TLS(Transport Layer Security)等のセキュアなエンドトゥーエンドトランザクションをも透過的に処理可能な透過型のプロキシ(以下、トランスペアレントプロキシ(Transparent Proxy)という)として構成されるようにする。これにより、TLS等のエンドトゥーエンドのセキュアなトランスポートセッションで保護された(隠ぺいされた)DASHセグメントのリクエスト/レスポンストランザクションについても同様に、拡張ヘッダ挿入処理を行うことが可能となる。
なお、トランスペアレントプロキシに関する技術としては、既に各種の技術が提案されており、ここでは、それらの公知の技術を用いることができる。
<3.HTTPリクエストヘッダの拡張方法>
(拡張ヘッダの例)
図13は、本技術の拡張ヘッダの例を示す図である。
図13は、本技術の拡張ヘッダの例を示す図である。
図13には、HTTPリクエストヘッダの拡張の一例として、ATSC3.0サービスの場合の拡張ヘッダの記述例を示している。
図13において、HTTPリクエストヘッダの汎用ヘッダに拡張する拡張ヘッダ名は、例えば、"ATSC3.0-Requset"とされる。ここで、汎用ヘッダは、リクエストやレスポンスのエンティティボディではなく、接続に対して適用されるヘッダを意味する。なお、拡張ヘッダ名を、プライベートヘッダとして定義する場合には、"X-ATSC3.0-Requset"とすることができる。
拡張ヘッダの値としては、コンテンツのソースの同一性を識別するためのソース識別情報が配置される。このソース識別情報には、サービスID(service-id)、コンテンツID(contentId)、MPDメタデータのURL(mpd-uri)、及び時刻情報(broadcastTime)等のATSC3.0サービスの配信関連の主な属性を含めることができる。
サービスIDは、ATSC3.0で規定されるサービスを識別するためのID(グローバルサービスID)である。このサービスIDは、必須の値とされる。
なお、ATSC3.0規定のサービスID(globalServiceId)の詳細は、下記の非特許文献1の「Table 7.1 Semantics of the User Service Bundle Description Fragment for ROUTE/DASH」に開示されている。すなわち、サービスIDとしては、USBDメタデータのuserServiceDescription要素のglobalServiceID属性の値を用いることができる。
非特許文献1:ATSC Candidate Standard:Signaling, Delivery, Synchronization, and Error Protection(A/331) Doc. S33-174r15 January 2016
MPDメタデータのURLは、USBDメタデータにより参照されるMPDメタデータの絶対パスを表したURI(Uniform Resource Locator)である。このURLは、オプショナルな値とされる。
なお、上記の非特許文献1の「Table 7.1 Semantics of the User Service Bundle Description Fragment for ROUTE/DASH」に開示されているように、MPDメタデータのURLとしては、USBDメタデータのuserServiceDescription要素のfullMPDUri属性の値を用いることができる。
時刻情報は、コンテンツが実際に放送された時刻を表している。ただし、放送時刻の内容の選択は、実装依存とされる。つまり、例えば、放送時刻が、コンテンツの配信スケジュールの開始時刻であるのか、あるいは配信スケジュールの開始から終了までの任意の時刻(HTTPリクエストのパケットが到着した時刻)であるのかは、運用に応じて設定される。この時刻情報は、オプショナルな値とされる。
コンテンツIDは、コンテンツを識別するIDである。このコンテンツIDとしては、例えば、"EIDR"又は"Ad-ID"を指定することができる。ここで、"EIDR"は、Entertainment Identifier Registryの略であり、テレビ番組や映画のコンテンツを、グローバルな単一のIDで管理することができる。"Ad-ID"は、Advertising IDの略であり、広告用のIDである。このコンテンツIDは、オプショナルな値とされる。
ここで、図14には、HTTPリクエストに対し、拡張ヘッダとして挿入されるソース識別情報の例を示している。
すなわち、図14においては、XML形式のUSBDメタデータとMPDメタデータの記述例を示しているが、これらのメタデータから得られる情報を、ATSC3.0サービスの配信関連の属性として、ソース識別情報に含めることができる。
例えば、USBDメタデータにおいては、userServiceDescription要素のglobalServiceID属性の値から、サービスID(グローバルサービスID)が得られ、userServiceDescription要素のfullMPDUri属性の値から、MPDメタデータのURLが得られる。また、例えば、MPDメタデータにおいては、Period要素のAssetIdentifier要素の値から、EIDRに対応したコンテンツIDが得られる。
なお、詳細は、後述するが、拡張ヘッダ挿入処理に先立って、ソース識別情報を格納したマッピングデータベースをあらかじめ生成しておくことで、拡張ヘッダ挿入処理では、マッピングデータベースを参照することにより、HTTPリクエストに挿入すべき、ソース識別情報を取得することが可能となる。
また、USBDメタデータのDeliveryMethod要素に記述されるURLと、MPDメタデータのRepresentation要素に記述されるURL(セグメントURL)とのマッチングを行うことで、コンテンツのデータ(ストリーム)の配信経路が、放送経由であるのか、あるいは通信経由であるのかを特定することができる。なお、MPDメタデータにおけるセグメントURLの記述と導出については、図7乃至図11を参照して先に述べた通りである。
次に、図15及び図16を参照して、HTTPリクエストヘッダの具体的な例を示す。ここでは、まず、図15を参照して、拡張ヘッダ挿入前のHTTPリクエストヘッダを説明してから、図16を参照して、拡張ヘッダ挿入後のHTTPリクエストヘッダを説明する。
(HTTPリクエスト)
図15は、HTTPリクエストの例を示す図である。
図15は、HTTPリクエストの例を示す図である。
図15においては、セグメントURLが、"http://a.com/a.mp4"の場合に、このDASHセグメントファイルを取得するためのHTTPリクエストの例を示している。
このHTTPリクエストは、HTTPで定義されているメソッドのうち、GETメソッドを利用している。HTTPリクエストでは、HOSTにより、ホスト名(サーバ名)が指定され、GETメソッドにより、リソースが指定される。なお、"HTTP/1.1"は、HTTPのバージョンを表している。
なお、HTTPリクエストでは、1行目がHTTPリクエスト行となり、2行目以降がHTTPヘッダ行、すなわち、HTTPリクエストヘッダとされる。また、GETメソッドを利用する場合、HTTPボディ部には、何も記述されることはない。
(拡張ヘッダ挿入後のHTTPリクエスト)
図16は、拡張ヘッダが挿入されたHTTPリクエストの例を示す図である。
図16は、拡張ヘッダが挿入されたHTTPリクエストの例を示す図である。
図16においては、図15のHTTPリクエスト(HTTPリクエストヘッダ)に対し、拡張ヘッダとして、"atsc3.0-requset"である拡張ヘッダ名の行が追加されている。
すなわち、この拡張ヘッダとして追加されるDASHセグメントファイルのコンテンツの属性は、セグメントURLを主キーとして、マッピングデータベースを参照することで得られるソース識別情報からなる。具体的には、サービスID、コンテンツID、MPDメタデータのURL、及び時刻情報等のソース識別情報が、拡張ヘッダとして追加されている。
例えば、図16のHTTPリクエストの拡張ヘッダでは、USBDメタデータのglobalServiceID属性の値である"urn:atsc:serviceId:NBCU-NFL-1"が、サービスID(service-id)として指定され、USBDメタデータのfullMPDUri属性の値である"http://a.com/a.mpd"が、MPDメタデータのURL(mpd-uri)として指定されている。
また、図16のHTTPリクエストの拡張ヘッダでは、MPDメタデータのAssetIdentifier要素に記述されるEIDRである"md:cid:EIDR:10.5240%2f0EFB-02CD-126E-8092-1E49-W"が、コンテンツID(contentId)として指定されている。さらに、図16のHTTPリクエストの拡張ヘッダでは、当該コンテンツの放送時刻である2016年7月4日(金)23:54:58(グリニッジ標準時)を表した"Fri, 04 Jul 2016 23:54:58 GMT"が、時刻情報(broadcastTime)として指定されている。
以上のように、本技術では、HTTPリクエストに対し、拡張ヘッダとして、ソース識別情報を挿入することで、放送サービスをサービスエントリとして、通信経由で、DASHセグメントに対するHTTPリクエストが送信される場合でも、コンテンツのソースの同一性を識別することができるようにしている。
なお、ここでは、デジタル放送の規格として、米国等で採用される方式であるATSC(特にATSC3.0)を一例に説明したが、本技術は、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。
すなわち、ソース識別情報は、コンテンツのソースの同一性を識別可能な情報であって、放送サービス(例えば、ATSC3.0サービス等)を識別するための情報となるので、様々な放送方式に適用することができる。ただし、上述した説明では、ソース識別情報として、ATSC3.0サービスを前提に、サービスIDやコンテンツIDなどを例示列挙したが、それらに限らず、ISDBやDVB等の規格ごとに、より適した情報を用いることができる。
また、デジタル放送の規格以外で規定された情報を、必要に応じて、ソース識別情報に加えることもできる。例えば、移動体通信システムの標準化プロジェクトである3GPP(Third Generation Partnership Project)で規定された情報を追加することもできる。具体的には、例えば、ソース識別情報として、3GPP-MBMS(Multimedia Broadcast Multicast Services)で規定される要素や属性を加えることができる。
<4.トランスペアレントプロキシの発見・接続方法>
ところで、エンドユーザ宅2内のほか、ケーブルオペレータのヘッドエンドや、モバイル網の基地局などに設置される可能性のある、ゲートウェイ装置10(のローカルプロキシ113)を発見・接続する方法としては、いくつかの方法が想定される。
例えば、クライアント装置20において、ブラウザ212のインターネット接続設定のメニューにて、手動でローカルプロキシ113のIPアドレスやポート番号などを入力する方法や、プロキシ設定スクリプトのURLを登録する方法、あるいは自動設定による方法などがある。
自動設定の方法としては、例えば、DHCP(Dynamic Host Configuration Protocol)サーバを用いる方法や、WPAD(Web Proxy Auto Discovery)を用いる方法などがある。また、プロキシ設定スクリプトによる自動設定は、JavaScript(登録商標)等のスクリプト言語で記述されたプロキシ自動構成スクリプトファイルを用意して、そのファイルをウェブサーバ上に配置する一方で、そのファイルのURLを、ブラウザ212の自動設定のスクリプトのURLに設定すればよい。
WPADを用いる場合には、ブラウザ212自身が、プロキシ設定用のスクリプトファイルの位置(URL)を自動的に検出してダウンロードすることで、設定を行うことができる。なお、WPADでは、一般には、DHCPサーバのDHCPINFORMメッセージを用いる方法と、DNS(Domain Name System)を用いた方法により、"wpad"という名前を持つエントリを探して、そこからプロキシ設定スクリプトをダウンロードする方法が実装されている。
ゲートウェイ装置10(のローカルプロキシ113)の発見においても、同様の方法を用いることができる。ローカルプロキシ113では、HTTPSプロトコルによるセキュアなエンドトゥーエンドのトランスポートセッションを含むすべてのセッションを、ローカルプロキシ113が、仲介(横取り)できるようにする。一般的に、このようなプロキシが、トランスペアレントプロキシ(透過プロキシ)と呼ばれるのは、先に述べた通りである。
本技術では、クライアント装置20が、ネットワーク30において、ローカルプロキシ113が稼働しているサーバであるゲートウェイ装置10を発見し、当該ローカルプロキシ113がリクエストを待ち受けるIPアドレスとポート番号(以下、プロキシ待ち受けアドレス/ポートともいう)を取得する方式を提案する。
そのためには、クライアント装置20では、ローカルプロキシ113に対し、プロキシ待ち受けアドレス/ポートを問い合わせるためのWeb API(Application Programming Interface)を認識する必要がある。つまり、このWeb APIは、サービスを呼び出すためのインターフェースであると言える。
ここで、トランスペアレントプロキシであるローカルプロキシ113の発見に、ユニバーサルプラグアンドプレイ(UPnP:Universal Plug and Play)を利用する場合、ローカルプロキシ113の発見と、機能の公開には、SSDP(Simple Service Discovery Protocol)が用いられる。
なお、UPnPは、デバイスを接続するだけで、対象のネットワークに参加することを可能にするプロトコルである。また、SSDPは、UPnPで用いられるプロコトルの1つで、ネットワーク上のデバイスの探索や応答を行うためのものである。
一般に、SSDPにおいては、公開されるサービスを発見する際にやりとりされるデバイスディスクリプションとして、デバイスが提供可能な機能や情報が記述されたXML形式のファイルが用いられる。このファイルには、対象のデバイスそのものについて記述したデバイスディスクリプションと、対象のデバイス上に実装された各サービスが持つアクションとしてのサービスディスクリプションとが記述される。
本技術では、ローカルプロキシ113のディスクリプション(例えばサービスディスクリプション)に、当該ローカルプロキシ113がリクエストを待ち受けるIPアドレスとポート番号(プロキシ待ち受けアドレス/ポート)を返答するWeb APIのURLを記述できるようにする。
また、本技術では、ATSC3.0サービス等の放送サービスに対応するローカルプロキシ113のサービスを発見するためのプロトコルを追加することにより、放送サービスを実装していない一般クライアント装置(NC)20で、ブラウザ212のプロキシとして、プロキシ待ち受けアドレス/ポートを設定できるようにする。
すなわち、放送サービスを実装していない一般クライアント装置(NC)20(スマートフォンやタブレット型コンピュータ等の一般エンドデバイス)のブラウザ212で、あるスクリプト(Web API)を立ち上げると、放送サービスに対応するサーバであるゲートウェイ装置10を発見し、そこで稼働するローカルプロキシ113のプロキシ待ち受けアドレス/ポートを、当該ブラウザ212のプロキシとして設定できるようにする。
以下、このような、ゲートウェイ装置10で稼働するローカルプロキシ113の発見と、ローカルプロキシ113のプロキシ待ち受けアドレス/ポートの取得のシーケンス(プロキシの発見・接続処理)を、上述したHTTPリクエストヘッダの拡張のシーケンス(拡張ヘッダ挿入処理)とあわせて説明する。
なお、ここでは、ネットワーク上のデバイスの探索や応答を行うプロトコルとして、SSDPを一例に説明したが、DIAL(Discovery and Launch)等の他のプロトコルを用いることでも、同様の機能を実現することができる。DIALは、ネットワーク上にあるDIAL対応のデバイスをUPnPにより発見し、指定されたアプリケーションを起動させるプロトコルである。
<5.プロキシの発見・接続処理と、拡張ヘッダ挿入処理の流れ>
(プロキシの発見・接続処理と、拡張ヘッダ挿入処理)
図17及び図18のフローチャートを参照して、プロキシの発見・接続処理と、拡張ヘッダ挿入処理の一連の流れを説明する。
図17及び図18のフローチャートを参照して、プロキシの発見・接続処理と、拡張ヘッダ挿入処理の一連の流れを説明する。
ただし、図17及び図18の説明では、図19乃至図26に示したリクエストやレスポンス等のメッセージの内容を適宜参照しながら説明するものとする。
また、図17及び図18の説明では、ネットワーク30に接続されるゲートウェイ装置10には、IPアドレスとして、"192.168.1.1"が割り当てられているものとする。また、このゲートウェイ装置10で稼働するサービスのうち、UPnP/SSDPサーバ111には、"12345"であるポート番号、プロキシアプリマネージャ112には、"23456"であるポート番号、ローカルプロキシ113には、"34567"であるポート番号がそれぞれ割り当てられているものとする。
なお、図17及び図18において、ステップS101乃至S102の処理と、ステップS111の処理と、ステップS121乃至S123の処理は、ゲートウェイ装置10により実行される。一方で、ステップS201乃至S204の処理と、ステップS211乃至S212の処理は、クライアント装置20により実行される。
図17のステップS201において、アプリケーション211は、ゲートウェイ装置10で稼働するローカルプロキシ113の存在を確認するために、通信I/F201を介して、ネットワーク30に接続されたデバイス(サーバ)に対し、M-SEARCHリクエストを、マルチキャストで送信する。
図19は、M-SEARCHリクエストの例を示す図である。
M-SEARCHリクエストには、マルチキャストのIPアドレスとして、"239.255.255.250"が指定され、ポート番号として、"1900"が指定される。
また、上述したように、UPnPのプロトコルとして、SSDPを用いるので、MANには、"ssdp:discover"が指定される。さらに、探索の対象が、ATSC3.0に対応したプロキシであるローカルプロキシ113となるので、STには、"urn:atsc:proxy"が指定される。
図17に戻り、ステップS201の処理で、クライアント装置20により送信されるM-SEARCHリクエストは、ネットワーク30に接続されたゲートウェイ装置10により受信される。
ステップS101において、UPnP/SSDPサーバ111は、クライアント装置20から受信したM-SEARCHリクエストに応じて、デバイスディスクリプションURLを生成し、M-SEARCHレスポンスとして、ネットワーク30を介してクライアント装置20に送信する。
図20は、M-SEARCHレスポンスの例を示す図である。
M-SEARCHレスポンスにおいて、LOCATIONには、デバイスディスクリプションURLとして、"http://192.168.1.1:12345/deviceDescription.xml"が指定される。このデバイスディスクリプションURLは、XML形式のファイルのURLであって、このファイルは、ゲートウェイ装置10で稼働するローカルウェブサーバが処理する。
すなわち、ゲートウェイ装置10においては、UPnP/SSDPサーバ111がローカルウェブサーバとしての機能を有しているので、デバイスディスクリプションURLには、ゲートウェイ装置10に割り当てられたIPアドレスである"192.168.1.1"と、ローカルウェブサーバとしてのUPnP/SSDPサーバ111に割り当てられたポート番号である"12345"が記述される。
図17に戻り、ステップS101の処理で、ゲートウェイ装置10により送信されるM-SEARCHレスポンスは、M-SEARCHリクエストを送信したクライアント装置20により受信される。
ステップS202において、アプリケーション211は、ゲートウェイ装置10から受信したM-SEARCHレスポンス(のデバイスディスクリプションURL)に基づいて、ネットワーク30に接続されたゲートウェイ装置10で稼働するUPnP/SSDPサーバ111に対し、デバイスディスクリプションを要求する。
図21は、デバイスディスクリプションリクエストの例を示す図である。
デバイスディスクリプションリクエストには、GETメソッドの対象のリソースとして、"deviceDescripion.xml"であるデバイスディスクリプションが記述される。また、HOSTには、ホスト名として、"192.168.1.1:12345"が記述される。
すなわち、デバイスディスクリプションリクエストでは、M-SEARCHレスポンスに記述された内容に応じて、GETメソッドの対象のリソースが、"deviceDescripion.xml"となる。さらに、デバイスディスクリプションリクエストには、HOSTとして、"192.168.1.1"であるゲートウェイ装置10のIPアドレスと、"12345"であるUPnP/SSDPサーバ111(ローカルウェブサーバ)のポート番号とが記述される。
図17に戻り、ステップS202の処理で、クライアント装置20により送信されるデバイスディスクリプションリクエストは、ネットワーク30に接続されたゲートウェイ装置10により受信される。
ステップS102において、UPnP/SSDPサーバ111(ローカルウェブサーバ)は、クライアント装置20から受信したデバイスディスクリプションリクエストに応じて、デバイスディスクリプションを生成し、レスポンスとして、ネットワーク30を介してクライアント装置20に送信する。
図22及び図23は、デバイスディスクリプションレスポンスの例を示す図である。
デバイスディスクリプションレスポンスのヘッダには、図22に示すように、ファイルのタイプ等が指定される。また、図23には、XML形式のデバイスディスクリプションの内容が示されている。
すなわち、図23のデバイスディスクリプションには、root要素のxmlns属性として、"urn:schemas-upnp-org:device-1-0"が記述され、UPnP準拠のデバイスディスクリプションであることが宣言されている。
serviceList要素には、ゲートウェイ装置10でサポートされるサービスの一覧が記述される。serviceList要素には、1又は複数のservice要素が記述される。
service要素には、サポートされるサービスのうち、1つのサービスについての情報が記述される。service要素は、serviceType要素、serviceId要素、SCPDURL要素、及びcontrolURL要素などの上位要素となる。
serviceType要素には、サービスのタイプとして、"urn:atsc:proxy"が記述され、ATSC3.0サービスのプロキシサービスであることを意味している。
serviceId要素には、サービスIDとして、"urn:UPnP:serviceId:1234"が記述され、プロキシサービスのサービスIDを表している。
controlURL要素には、プロキシ待ち受けアドレス/ポート取得Web APIのURLとして、"http://192.168.1.1:23456/getATSC3.0ProxyAddressPort"が記述される。このURLは、ローカルプロキシ113がリクエストを待ち受けるIPアドレスとポート番号を示すプロキシ待ち受けアドレス/ポートを取得するためのWeb APIを呼び出すための情報である。
ここで、通常、SCPDURL要素には、ACRクライアントサービスについてのサービスディスクリプションのアドレスが記述されるので、HTTPで規定されるGETメソッドにより、サービスディスクリプションが取得される。その場合には、UPnPで規定されるSOAP(Simple Object Access Protocol)により、controlURL要素に記述されるURLに対し、アクションのメッセージを送付することで、アクションを呼び出すことになる。
一方で、本技術では、より簡便にWeb APIを呼び出せるように、UPnPの規定とは異なる方法で、Web APIのURLを周知する方法を提案する。すなわち、本技術では、図23に示すように、SCPDURL要素の値としては何も記述せずに(SCPDURL要素の中身は空にしておき)、SCPDURL要素に何も記述されていない場合に限り、controlURL要素に、直接、Web APIのURLを記述できるようにしている。
なお、controlURL要素に、直接、Web APIのURLを記述するための条件としては、上述したような、SCPDURL要素の中身を空にするほか、例えば、controlURL要素に、ダミーの文字列を記述するようにしてもよい。
図17に戻り、ステップS102の処理で、ゲートウェイ装置10により送信されるデバイスディスクリプションレスポンスは、デバイスディスクリプションリクエストを送信したクライアント装置20により受信される。
ステップS203において、アプリケーション211は、ゲートウェイ装置10から受信したデバイスディスクリプションレスポンス(のプロキシ待ち受けアドレス/ポート取得Web APIのURL)に基づいて、ネットワーク30に接続されたゲートウェイ装置10で稼働するプロキシアプリマネージャ112に対し、プロキシ待ち受けアドレス/ポートを要求する。
図24は、プロキシ待ち受けアドレス/ポートリクエストの例を示す図である。
プロキシ待ち受けアドレス/ポートリクエストには、GETメソッドの対象のリソースとして、"getATSC3.0ProxyAddressPort"である対象のプロキシ待ち受けアドレス/ポートが記述される。また、HOSTには、ホスト名として、"192.168.1.1:23456"が記述される。
すなわち、プロキシ待ち受けアドレス/ポートリクエストでは、デバイスディスクリプションレスポンスに記述された内容(controlURL要素の内容)に応じて、GETメソッドの対象が、"getATSC3.0ProxyAddressPort"となる。さらに、プロキシ待ち受けアドレス/ポートリクエストには、HOSTとして、"192.168.1.1"であるゲートウェイ装置10のIPアドレスと、"23456"であるプロキシアプリマネージャ112のポート番号が記述される。
図17に戻り、ステップS203の処理で、クライアント装置20により送信されるプロキシ待ち受けアドレス/ポートリクエストは、ネットワーク30に接続されたゲートウェイ装置10により受信される。
ステップS111において、プロキシアプリマネージャ112は、クライアント装置20から受信したプロキシ待ち受けアドレス/ポートリクエストに応じて、プロキシ待ち受けアドレス/ポートを生成し、レスポンスとして、ネットワーク30を介してクライアント装置20に送信する。
図25は、プロキシ待ち受けアドレス/ポートレスポンスの例を示す図である。
プロキシ待ち受けアドレス/ポートレスポンスのボディ部には、プロキシ待ち受けアドレス/ポートとして、"192.168.1.1:34567"が記述されている。
すなわち、ゲートウェイ装置10において、ローカルプロキシ113がプロキシサーバとしての機能を有しているので、当該レスポンスのボディ部には、ゲートウェイ装置10に割り当てられたIPアドレスである"192.168.1.1"と、ローカルプロキシ113に割り当てられたポート番号である"34567"が記述される。
なお、この例では、Web APIへのリクエスト(プロキシ待ち受けアドレス/ポートリクエスト)を受け取るのが、プロキシアプリマネージャ112であるとして説明しているが、ローカルプロキシ113本体が、当該リクエストを受け取って、処理するようにしてもよい。
図17に戻り、ステップS111の処理で、ゲートウェイ装置10により送信されるプロキシ待ち受けアドレス/ポートレスポンスは、プロキシ待ち受けアドレス/ポートリクエストを送信したクライアント装置20により受信される。
図18のステップS204において、アプリケーション211は、ゲートウェイ装置10から受信したプロキシ待ち受けアドレス/ポートレスポンス(のIPアドレスとポート番号)に基づいて、プロキシ自動構成スクリプトの更新と、ブラウザ212の起動(再起動)による構成変更の反映を行う。
すなわち、クライアント装置20において、アプリケーション211は、プロキシ待ち受けアドレス/ポートレスポンスから、プロキシ待ち受けアドレス/ポートとして得られるIPアドレスとポート番号(ATSC3.0ProxyAddressPort(192.168.1.1:34567))により、プロキシ自動構成スクリプトファイルを書き換える。
図26は、プロキシ自動構成スクリプトファイルの例を示す図である。
プロキシ自動構成スクリプトファイルは、スクリプト言語として、JavaScript(登録商標)を用いて記述することができる。
図26においては、FindProxyForURL関数が定義され、その引数として、url,hostが指定可能である。FindProxyForURL関数においては、条件分岐のelse文に、"PROXY 192.168.1.1:34567; DIRECT"、すなわち、プロキシ待ち受けアドレス/ポートが記述されている。つまり、"192.168.1.1"は、ゲートウェイ装置10に割り当てられたIPアドレスであり、"34567"は、ローカルプロキシ113に割り当てられたポート番号である。
このFindProxyForURL関数によって、サブネット内の特定のホストは直接外部と接続し、それ以外のホストは、ゲートウェイ装置10で稼働するローカルプロキシ113を介して、外部に接続することになる。ただし、ここでのホストには、クライアント装置20が含まれる。
すなわち、クライアント装置20では、アプリケーション211により、プロキシ自動構成スクリプトファイルが、プロキシ待ち受けアドレス/ポートにより書き換えられ、ブラウザ212が、起動(再起動)される。そして、当該ブラウザ212が参照するプロキシ自動構成スクリプトファイルにより、プロキシのIPアドレスとポート番号の設定(自動設定)が行われる。
これにより、クライアント装置20において、ブラウザ212は、ネットワーク30を介して、ゲートウェイ装置10で稼働するローカルプロキシ113にアクセスすることが可能となる。
ステップS211において、ブラウザ212は、放送サービスをサービスエントリとして、通信経由で、コンテンツの配信を受けるタイミングになった場合、DASHセグメントを、ネットワーク30を介して、ゲートウェイ装置10で稼働するローカルプロキシ113に要求する。
すなわち、ブラウザ212は、コンテンツのDASHセグメントを再生するDASHプレーヤとしての機能を有しており、一般クライアント装置20(NC)のブラウザ212(DASHプレーヤ)からのリクエスト(例えば、"http(s)://a.com/a.mp4"であるセグメントURLのDASHセグメントファイルのHTTPリクエスト)は、すべて、ローカルプロキシ113を経由することになる。
ステップS211の処理で、クライアント装置20により送信される、DASHセグメントのHTTPリクエストは、ゲートウェイ装置10で稼働するローカルプロキシ113により受信される。
ステップS121において、ローカルプロキシ113は、クライアント装置20から受信したHTTPリクエストに対し、拡張ヘッダを挿入する。
すなわち、ローカルプロキシ113は、トランスペアレントプロキシとしての機能を有し、拡張ヘッダ挿入処理を行うことで、クライアント装置20からのHTTPリクエストに対し、コンテンツのソースの同一性を識別するためのソース識別情報(ソース同一性を識別する識別子)を挿入する。この拡張ヘッダ処理で挿入されるソース識別情報として、例えば、ATSC3.0サービスの場合には、サービスIDやコンテンツID、MPDメタデータのURL、時刻情報などを含めることができるのは、先に述べた通りである。
なお、ATSC3.0サービスに対応した拡張ヘッダ挿入処理においては、トラップしたDASHセグメントファイルのHTTPリクエストに対して、拡張ヘッダを挿入する前に、あらかじめ生成されたマッピングデータベースを参照することで、当該HTTPリクエスト(のURL)が、ATSC3.0サービスで配信されたMPDメタデータに記述されたセグメントURLであるかどうかを確認する処理が行われる。この処理の詳細は、図27のフローチャートを参照して、後述する。
ステップS122において、ローカルプロキシ113は、ステップS121の処理(拡張ヘッダ挿入処理)で得られるHTTPリクエストを、通信I/F102を介して、インターネット80に接続された通信サーバ70に送信する。
なお、詳細は、図28を参照して後述するが、通信サーバ70は、インターネット80を介してゲートウェイ装置10から送信されてくるHTTPリクエストを受信する。また、通信サーバ70は、受信したHTTPリクエストに基づいて、DASHセグメントファイルを、インターネット80を介して、ゲートウェイ装置10に送信する。
ここで、通信サーバ70は、ゲートウェイ装置10から受信したHTTPリクエストヘッダに、サービスIDやコンテンツID、MPDメタデータのURL、時刻情報などのソース識別情報が挿入されているため、当該ソース識別情報を確認することで、HTTPリクエストが、ATSC3.0サービスを導線として要求されたリクエストであることを認識することができる。
通信サーバ70により送信されるDASHセグメントファイルは、インターネット80に接続されたゲートウェイ装置10により受信される。
ステップS123において、ローカルプロキシ113は、通信サーバ70から受信したDASHセグメントファイルを、通信I/F103を介して、ネットワーク30に接続されたクライアント装置20に転送する。
ステップS123の処理で、ゲートウェイ装置10により転送されるDASHセグメントファイルは、ネットワーク30に接続されたクライアント装置20により受信される。
ステップS212において、ブラウザ212は、ゲートウェイ装置10から受信したDASHセグメントファイルを処理し、DASHプレーヤによるDASHセグメントファイルの再生を行う。これにより、クライアント装置20においては、通信経由で配信された番組等のコンテンツが再生されることになる。
以上、プロキシの発見・接続処理と、拡張ヘッダ挿入処理の一連の流れを説明した。
(拡張ヘッダ挿入処理の詳細)
次に、図27のフローチャートを参照して、拡張ヘッダ挿入処理の詳細を説明する。
次に、図27のフローチャートを参照して、拡張ヘッダ挿入処理の詳細を説明する。
図27のフローチャートに示した処理は、図17及び図18のプロキシの発見・接続処理と、拡張ヘッダ挿入処理のうち、拡張ヘッダ挿入処理に相当する処理であって、図18のステップS121乃至S123の処理と、ステップS211乃至S212の処理に対応している。
なお、図27において、ステップS151乃至S154の処理と、ステップS161乃至S164の処理は、ゲートウェイ装置10により実行される。また、ステップS251乃至S252の処理は、クライアント装置20により実行される。
ゲートウェイ装置10においては、クライアント装置20からのHTTPリクエストに対する拡張ヘッダ挿入処理に先立って、ステップS151乃至S153の処理が実行され、SLS処理系114によって、マッピングデータベースが生成され、記憶部104に記憶される。
具体的には、ステップS151において、SLS処理系114は、多重化ストリームから、ROUTEセッションで伝送されるSLSを抽出する。
ステップS152において、SLS処理系114は、ステップS151の処理で得られたSLSをパースする。
ここでは、USBDメタデータとMPDメタデータが解析され、USBDメタデータのglobalServiceID属性により記述されるサービスID及びfullMPDUri属性により指定されるURI(MPDメタデータのURL)、並びにMPDメタデータに記述されるコンテンツID(EIDRやAd-ID)及びセグメントURLが得られる。
ステップS153において、SLS処理系114は、ステップS152の処理で得られた解析結果に基づいて、マッピングデータベースを生成する。このマッピングデータベースは、記憶部104に記憶される。
このマッピングデータベースは、クライアント装置20からのHTTPリクエストに含まれるURLが、ATSC3.0サービスのどのサービスのDASHセグメントに対応するものなのかを解決するためのデータベースとなる。
具体的には、マッピングデータベースでは、セグメントURLを主キーとして、サービスID、コンテンツID、MPDメタデータのURL、及び時刻情報が対応付けられている。すなわち、このマッピングデータベースは、セグメントURLと、ソース識別情報との対応関係を格納している。なお、主キーとしては、セグメントURLに限らず、例えば、MPDメタデータのBaseURL要素により指定されるベースURLなど、URLの最初のパートにマッチする文字列を用いるようにしてもよい。
このマッピングデータベースによって、SLS処理系114は、クライアント装置20からのHTTPリクエストのURLに応じた属性(ソース識別情報)を、ローカルプロキシ113に提供することができる。換言すれば、拡張ヘッダ挿入処理を行うに際し、このマッピングデータベースを参照することで、拡張ヘッダを挿入する前に、対象のHTTPリクエストのURLが、ATSC3.0サービスで配信されたMPDメタデータに記述されたセグメントURLであるかどうかを確認することができる。
ここで、クライアント装置20において、放送サービスをサービスエントリとして、通信経由で、コンテンツの配信を受けるタイミングになった場合、ブラウザ212は、DASHセグメントを、ネットワーク30を介して、ゲートウェイ装置10で稼働するローカルプロキシ113に要求する(S251)。
ステップS251の処理で、クライアント装置20により送信されるDASHセグメントのHTTPリクエストは、ゲートウェイ装置10で稼働するローカルプロキシ113により受信される。
ステップS161において、ローカルプロキシ113は、クライアント装置20から受信したHTTPリクエストヘッダのURLによる照会を、SLS処理系114に要求する。
ステップS154において、SLS処理系114は、ローカルプロキシ113からのHTTPリクエストヘッダのURLによる照会に応じて、記憶部104に記憶されたマッピングデータベースを参照し、当該HTTPリクエストのURLに対応する属性(ソース識別情報)を返答する。
ここで、マッピングデータベースには、セグメントURLを主キーとして、サービスID、コンテンツID、MPDメタデータのURL、及び時刻情報などのソース識別情報が格納されているので、クライアント装置20からのHTTPリクエストのURLに対応するセグメントURLに対応付けられたソース識別情報が取得され、当該HTTPリクエストヘッダのURLに対応する属性として返答される。
ステップS162において、ローカルプロキシ113は、クライアント装置20から受信したHTTPリクエストヘッダに対し、拡張ヘッダとして、SLS処理系114から返答された属性(ソース識別情報)を挿入する。これにより、図16に示したように、HTTPリクエストヘッダには、サービスID、コンテンツID、MPDメタデータのURL、及び時刻情報などのソース識別情報が挿入されることになる。
ステップS163において、ローカルプロキシ113は、拡張ヘッダが挿入されたHTTPリクエストを、通信I/F102を介して、インターネット80に接続された通信サーバ70に送信する。
なお、通信サーバ70で行われる処理の詳細は、図28を参照して後述するが、簡単に説明すると、次のようになる。すなわち、通信サーバ70は、インターネット80を介してゲートウェイ装置10から送信されてくるHTTPリクエストを受信する。そして、通信サーバ70は、受信したHTTPリクエストに応じたDASHセグメントファイルを、インターネット80を介して、ゲートウェイ装置10に送信する。
通信サーバ70により送信されるDASHセグメントファイルは、インターネット80に接続されたゲートウェイ装置10により受信される。
ステップS164において、ローカルプロキシ113は、通信サーバ70から受信したDASHセグメントファイルを、通信I/F103を介して、ネットワーク30に接続されたクライアント装置20に転送する。
ステップS164の処理で、ゲートウェイ装置10により転送されるDASHセグメントファイルは、ネットワーク30に接続されたクライアント装置20により受信される。
クライアント装置20では、ブラウザ212によって、ゲートウェイ装置10から受信したDASHセグメントファイルが再生される(S252)。これにより、クライアント装置20においては、通信経由で配信された番組等のコンテンツが再生されることになる。
以上、拡張ヘッダ挿入処理の詳細を説明した。
この拡張ヘッダ挿入処理では、ゲートウェイ装置10で稼働するローカルプロキシ113によって、クライアント装置20からのHTTPリクエストに、拡張ヘッダ(ソース識別情報)が挿入されるため、容易に、HTTPリクエストヘッダに対し、ソース識別情報を追加することができる。すなわち、このような特殊なヘッダを、HTTPリクエストに追加する処理は、一般のDASHプレーヤ(ブラウザ212)の実装に、容易に加えることはできないが、HTTPリクエストが、ローカルプロキシ113を経由するようにすることで、拡張ヘッダ挿入処理を、ローカルプロキシ113上のモジュールやサーバサイドスクリプトなどによって、容易に実装することができる。
(HTTPリクエスト対応処理)
次に、図28のフローチャートを参照して、通信サーバ70により実行されるHTTPリクエスト対応処理の流れを説明する。
次に、図28のフローチャートを参照して、通信サーバ70により実行されるHTTPリクエスト対応処理の流れを説明する。
図28のフローチャートに示した処理は、図17及び図18のプロキシの発見・接続処理と、拡張ヘッダ挿入処理における、ステップS122の処理(ローカルプロキシ113のHTTPリクエスト転送処理)に対応する処理、あるいは、図27の拡張ヘッダ挿入処理におけるステップS163の処理(ローカルプロキシ113のHTTPリクエスト転送処理)に対応する処理となる。
ステップS301において、通信サーバ70は、インターネット80を介してゲートウェイ装置10(のローカルプロキシ113)から送信されてくるHTTPリクエストを受信する。
ステップS302において、通信サーバ70は、ステップS301の処理で得られたHTTPリクエストを処理する。
ここで、HTTPリクエストヘッダには、サービスIDやコンテンツID、MPDメタデータのURL、時刻情報などのソース識別情報が挿入されている。通信サーバ70は、HTTPリクエストヘッダに挿入されたソース識別情報に基づいて、当該HTTPリクエストが、放送サービスを導線として要求されたリクエストであることを認識することができる。
すなわち、ゲートウェイ装置10からのHTTPリクエストに、拡張ヘッダとしてのソース識別情報が挿入されていない場合、通信サーバ70においては、例えば、"http(s)://a.com/a.mp4"であるセグメントURLのDASHセグメントファイルのHTTPリクエストが、ATSC3.0サービス等の放送サービスを導線(サービスエントリ)としたものかどうかを認識することはできない。
一方で、ゲートウェイ装置10からのHTTPリクエストに、拡張ヘッダとしてのソース識別情報が挿入されている場合、通信サーバ70は、サービスIDやコンテンツID、MPDメタデータのURL、時刻情報などから、当該HTTPリクエストが、ATSC3.0サービス等の放送サービスを導線(サービスエントリ)としたものかどうかを認識することが可能となる。
例えば、放送と通信を利用したサイマル放送を行う場合や、放送と通信でそれぞれ伝送されるストリームを結合して得られるコンテンツの配信を行う場合などの、放送と通信を利用したサービスの運用を行う場合に、クライアント装置20では、放送サービスをサービスエントリとして、通信経由で、コンテンツの配信を受けるタイミングが生じるときがある。そして、このような場合において、放送事業者等の事業者から、放送サービスを導線(サービスエントリ)として、通信経由でアクセスしてくるクライアント装置20を識別したいという要請があるが、その要請に応えることができる。例えば、放送事業者は、ATSC3.0エンドデバイスと一般エンドデバイスとを区別して、アクセスの統計を管理する運用を、容易に行うことができる。
また、ここでは、通信サーバ70が、CDNのサーバとして提供されるようにすることで、通信サーバ70によって、コンテンツのデータ(DASHセグメントファイル)の配信が行われるときに、既存のCDNのロギングの機能を利用して、DASHセグメントのアクセス統計を記録するという運用が可能となる。さらに、通信サーバ70が、既存のCDNの機能を利用することで、追加コストを最小限に抑えることができる。さらに、例えば、同一のコンテンツを、異なるCDNのサーバから、配信元のパスを変えて配信する運用を行う場合に、同一のコンテンツから生成されたDASHセグメントのシーケンスを、容易に類推することができる。
なお、上記の「放送と通信でそれぞれ伝送されるストリームを結合して得られるコンテンツの配信を行う」運用とは、例えば、放送経由で、ベースレイヤとして、低品質なビデオストリームを配信するとともに、通信経由で、エンハンスメントレイヤとして、ベースレイヤとしてのビデオストリームを強化するための付加情報(エンハンスのビデオストリーム)を配信するような運用が相当する。これにより、クライアント装置20では、ベースレイヤに対応した通常品質の映像(例えば2K解像度の映像)を再生するだけでなく、ベースレイヤとエンハンスメントレイヤを結合して得られる高品質の映像(例えば4K解像度の映像)を再生するが可能となる。
ステップS303において、通信サーバ70は、ステップS301の処理で得られたHTTPリクエストに応じたDASHセグメントファイルを、インターネット80を介してゲートウェイ装置10に送信する。
以上、通信サーバ70側のHTTPリクエスト対応処理の流れを説明した。
<6.変形例>
(他の放送規格への適用)
上述した説明としては、デジタル放送の規格として、米国等で採用されている方式であるATSC(特に、ATSC3.0)を説明したが、本技術は、日本等が採用する方式であるISDBや、欧州の各国等が採用する方式であるDVBなどに適用するようにしてもよい。また、上述した説明では、IP伝送方式が採用されるATSC3.0を例にして説明したが、IP伝送方式に限らず、例えば、MPEG2-TS(Transport Stream)方式等の他の方式に適用するようにしてもよい。
上述した説明としては、デジタル放送の規格として、米国等で採用されている方式であるATSC(特に、ATSC3.0)を説明したが、本技術は、日本等が採用する方式であるISDBや、欧州の各国等が採用する方式であるDVBなどに適用するようにしてもよい。また、上述した説明では、IP伝送方式が採用されるATSC3.0を例にして説明したが、IP伝送方式に限らず、例えば、MPEG2-TS(Transport Stream)方式等の他の方式に適用するようにしてもよい。
また、デジタル放送の規格としては、地上波放送のほか、放送衛星(BS:Broadcasting Satellite)や通信衛星(CS:Communications Satellite)等を利用した衛星放送や、ケーブルテレビ(CATV)等の有線放送などの規格に適用することができる。
(その他の変形例)
また、上述した制御情報(シグナリング)などの名称は、一例であって、他の名称が用いられる場合がある。ただし、これらの名称の違いは、形式的な違いであって、対象の制御情報やパケットなどの実質的な内容が異なるものではない。例えば、USBD(User Service Bundle Description)は、USD(User Service Description)と称される場合がある。また、例えば、NRT(Non Real Time)は、LCC(Locally Cached Content)などと称される場合がある。
また、上述した制御情報(シグナリング)などの名称は、一例であって、他の名称が用いられる場合がある。ただし、これらの名称の違いは、形式的な違いであって、対象の制御情報やパケットなどの実質的な内容が異なるものではない。例えば、USBD(User Service Bundle Description)は、USD(User Service Description)と称される場合がある。また、例えば、NRT(Non Real Time)は、LCC(Locally Cached Content)などと称される場合がある。
また、制御情報が、XML等のマークアップ言語により記述される場合において、それらの要素や属性の名称は一例であって、他の名称が採用されるようにしてもよい。ただし、これらの名称の違いは、形式的な違いであって、それらの要素や属性の実質的な内容が異なるものではない。
また、DASHプレーヤは、例えば、HTML5(HyperText Markup Language 5)などのマークアップ言語やJavaScript(登録商標)等のスクリプト言語で開発されたアプリケーションのほか、例えば、Java(登録商標)などのプログラミング言語で開発されたアプリケーションとすることができる。また、このアプリケーションは、ブラウザにより実行されるアプリケーションに限らず、いわゆるネイティブアプリケーションとして、オペレーティングシステム(OS:Operating System)環境などで実行されるようにしてもよい。
なお、アプリケーションは、何らかの情報を明示的に表示するだけでなく、非表示で(バックグラウンドで)動作されるようにしてもよい(エンドユーザに認識されずに起動するようにしてもよい)。また、コンテンツは、動画や音楽のほか、例えば、電子書籍やゲーム、広告など、あらゆるコンテンツを含めることができる。
<7.コンピュータの構成>
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図29は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
コンピュータ1000において、CPU(Central Processing Unit)1001、ROM(Read Only Memory)1002、RAM(Random Access Memory)1003は、バス1004により相互に接続されている。バス1004には、さらに、入出力インターフェース1005が接続されている。入出力インターフェース1005には、入力部1006、出力部1007、記録部1008、通信部1009、及び、ドライブ1010が接続されている。
入力部1006は、キーボード、マウス、マイクロフォンなどよりなる。出力部1007は、ディスプレイ、スピーカなどよりなる。記録部1008は、ハードディスクや不揮発性のメモリなどよりなる。通信部1009は、ネットワークインターフェースなどよりなる。ドライブ1010は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブル記録媒体1011を駆動する。
以上のように構成されるコンピュータ1000では、CPU1001が、ROM1002や記録部1008に記録されているプログラムを、入出力インターフェース1005及びバス1004を介して、RAM1003にロードして実行することにより、上述した一連の処理が行われる。
コンピュータ1000(CPU1001)が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体1011に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
コンピュータ1000では、プログラムは、リムーバブル記録媒体1011をドライブ1010に装着することにより、入出力インターフェース1005を介して、記録部1008にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部1009で受信し、記録部1008にインストールすることができる。その他、プログラムは、ROM1002や記録部1008に、あらかじめインストールしておくことができる。
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理(例えば、並列処理あるいはオブジェクトによる処理)も含む。また、プログラムは、1のコンピュータ(プロセッサ)により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
また、本技術は、以下のような構成をとることができる。
(1)
コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入する処理部を備える
情報処理装置。
(2)
前記処理部は、放送サービスをサービスエントリとして、通信経由で、前記リクエストが送信される場合に、前記リクエストに対し、前記識別情報を挿入する
(1)に記載の情報処理装置。
(3)
前記識別情報は、前記コンテンツの配信元を識別するための情報である
(1)又は(2)に記載の情報処理装置。
(4)
前記識別情報は、前記放送サービスを識別する識別子を少なくとも含む
(3)に記載の情報処理装置。
(5)
前記識別情報は、前記コンテンツを識別する識別子、前記コンテンツの再生を制御する制御情報の取得先を示す情報、及び前記コンテンツに関する時刻情報のうち、少なくとも1つの情報をさらに含む
(4)に記載の情報処理装置。
(6)
前記処理部は、プロキシとしての機能を有する
(1)乃至(5)のいずれかに記載の情報処理装置。
(7)
放送波を受信する受信部と、
インターネット上のサーバと通信を行う通信部と
をさらに備え、
前記処理部は、
前記放送波から得られる制御情報に基づいて、前記識別情報を格納したマッピングデータベースを生成し、
HTTP(Hypertext Transfer Protocol)リクエストを、前記サーバに送信する場合、前記マッピングデータベースから得られる前記識別情報を、前記HTTPリクエストのリクエストヘッダに挿入し、
前記通信部は、前記HTTPリクエストを、前記インターネットを介して、前記サーバに送信する
(6)に記載の情報処理装置。
(8)
前記情報処理装置は、ネットワークに接続されたクライアント装置に対し、放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置であり、
前記処理部は、前記クライアント装置からのHTTPリクエストを、前記サーバに送信する場合、前記HTTPリクエストのリクエストヘッダに、前記識別情報を挿入する
(7)に記載の情報処理装置。
(9)
前記情報処理装置は、放送経由又は通信経由で配信されるコンテンツを再生するクライアント装置であり、
前記処理部は、前記クライアント装置からのHTTPリクエスト、又はネットワークに接続された他のクライアント装置からのHTTPリクエストを、前記サーバに送信する場合、前記HTTPリクエストのリクエストヘッダに、前記識別情報を挿入する
(7)に記載の情報処理装置。
(10)
前記処理部は、前記クライアント装置との接続を確立する場合に、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報を、前記クライアント装置に提供する
(8)に記載の情報処理装置。
(11)
前記クライアント装置は、前記プロキシの構成を設定するためのスクリプトファイルの内容を、前記接続情報により書き換え、当該スクリプトファイルを実行することで、前記プロキシとの接続を確立する
(10)に記載の情報処理装置。
(12)
前記処理部は、前記クライアント装置により、前記接続情報を取得するためのAPI(Application Programming Interface)が実行された場合に、前記接続情報を、前記クライアント装置に提供する
(11)に記載の情報処理装置。
(13)
前記リクエストは、セキュアなプロトコルを用いて通信が行われ、
前記プロキシは、透過型のプロキシ(Transparent Proxy)である
(6)乃至(12)のいずれかに記載の情報処理装置。
(14)
情報処理装置のデータ処理方法において、
前記情報処理装置が、
コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入するステップを含む
データ処理方法。
(15)
放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置との接続を処理する処理部と、
前記ゲートウェイ装置から、ネットワークを介して転送されてくる前記コンテンツを再生する再生部と
を備え、
前記ゲートウェイ装置は、プロキシとしての機能を有し、
前記処理部は、前記ゲートウェイ装置から前記ネットワークを介して提供される、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報に基づいて、前記プロキシとの接続を確立する
クライアント装置。
(16)
前記処理部は、前記プロキシの構成を設定するためのスクリプトファイルの内容を、前記接続情報により書き換え、当該スクリプトファイルを実行することで、前記プロキシとの接続を確立する
(15)に記載のクライアント装置。
(17)
前記処理部は、前記ゲートウェイ装置から前記ネットワークを介して提供される、前記接続情報を取得するためのAPIを実行することで、前記接続情報を取得する
(16)に記載のクライアント装置。
(18)
前記プロキシは、前記クライアント装置からのコンテンツのリクエストを、インターネット上のサーバに送信する場合、前記リクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入する
(17)に記載のクライアント装置。
(19)
前記プロキシは、放送サービスをサービスエントリとして、通信経由で、前記リクエストが送信される場合に、前記リクエストに対し、前記識別情報を挿入する
(18)に記載のクライアント装置。
(20)
クライアント装置のデータ処理方法において、
前記クライアント装置が、
放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置との接続を確立する場合に、プロキシとしての機能を有する前記ゲートウェイ装置からネットワークを介して提供される、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報に基づいて、前記プロキシとの接続を確立し、
前記ゲートウェイ装置から、前記ネットワークを介して転送されてくる前記コンテンツを再生する
ステップを含むデータ処理方法。
コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入する処理部を備える
情報処理装置。
(2)
前記処理部は、放送サービスをサービスエントリとして、通信経由で、前記リクエストが送信される場合に、前記リクエストに対し、前記識別情報を挿入する
(1)に記載の情報処理装置。
(3)
前記識別情報は、前記コンテンツの配信元を識別するための情報である
(1)又は(2)に記載の情報処理装置。
(4)
前記識別情報は、前記放送サービスを識別する識別子を少なくとも含む
(3)に記載の情報処理装置。
(5)
前記識別情報は、前記コンテンツを識別する識別子、前記コンテンツの再生を制御する制御情報の取得先を示す情報、及び前記コンテンツに関する時刻情報のうち、少なくとも1つの情報をさらに含む
(4)に記載の情報処理装置。
(6)
前記処理部は、プロキシとしての機能を有する
(1)乃至(5)のいずれかに記載の情報処理装置。
(7)
放送波を受信する受信部と、
インターネット上のサーバと通信を行う通信部と
をさらに備え、
前記処理部は、
前記放送波から得られる制御情報に基づいて、前記識別情報を格納したマッピングデータベースを生成し、
HTTP(Hypertext Transfer Protocol)リクエストを、前記サーバに送信する場合、前記マッピングデータベースから得られる前記識別情報を、前記HTTPリクエストのリクエストヘッダに挿入し、
前記通信部は、前記HTTPリクエストを、前記インターネットを介して、前記サーバに送信する
(6)に記載の情報処理装置。
(8)
前記情報処理装置は、ネットワークに接続されたクライアント装置に対し、放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置であり、
前記処理部は、前記クライアント装置からのHTTPリクエストを、前記サーバに送信する場合、前記HTTPリクエストのリクエストヘッダに、前記識別情報を挿入する
(7)に記載の情報処理装置。
(9)
前記情報処理装置は、放送経由又は通信経由で配信されるコンテンツを再生するクライアント装置であり、
前記処理部は、前記クライアント装置からのHTTPリクエスト、又はネットワークに接続された他のクライアント装置からのHTTPリクエストを、前記サーバに送信する場合、前記HTTPリクエストのリクエストヘッダに、前記識別情報を挿入する
(7)に記載の情報処理装置。
(10)
前記処理部は、前記クライアント装置との接続を確立する場合に、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報を、前記クライアント装置に提供する
(8)に記載の情報処理装置。
(11)
前記クライアント装置は、前記プロキシの構成を設定するためのスクリプトファイルの内容を、前記接続情報により書き換え、当該スクリプトファイルを実行することで、前記プロキシとの接続を確立する
(10)に記載の情報処理装置。
(12)
前記処理部は、前記クライアント装置により、前記接続情報を取得するためのAPI(Application Programming Interface)が実行された場合に、前記接続情報を、前記クライアント装置に提供する
(11)に記載の情報処理装置。
(13)
前記リクエストは、セキュアなプロトコルを用いて通信が行われ、
前記プロキシは、透過型のプロキシ(Transparent Proxy)である
(6)乃至(12)のいずれかに記載の情報処理装置。
(14)
情報処理装置のデータ処理方法において、
前記情報処理装置が、
コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入するステップを含む
データ処理方法。
(15)
放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置との接続を処理する処理部と、
前記ゲートウェイ装置から、ネットワークを介して転送されてくる前記コンテンツを再生する再生部と
を備え、
前記ゲートウェイ装置は、プロキシとしての機能を有し、
前記処理部は、前記ゲートウェイ装置から前記ネットワークを介して提供される、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報に基づいて、前記プロキシとの接続を確立する
クライアント装置。
(16)
前記処理部は、前記プロキシの構成を設定するためのスクリプトファイルの内容を、前記接続情報により書き換え、当該スクリプトファイルを実行することで、前記プロキシとの接続を確立する
(15)に記載のクライアント装置。
(17)
前記処理部は、前記ゲートウェイ装置から前記ネットワークを介して提供される、前記接続情報を取得するためのAPIを実行することで、前記接続情報を取得する
(16)に記載のクライアント装置。
(18)
前記プロキシは、前記クライアント装置からのコンテンツのリクエストを、インターネット上のサーバに送信する場合、前記リクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入する
(17)に記載のクライアント装置。
(19)
前記プロキシは、放送サービスをサービスエントリとして、通信経由で、前記リクエストが送信される場合に、前記リクエストに対し、前記識別情報を挿入する
(18)に記載のクライアント装置。
(20)
クライアント装置のデータ処理方法において、
前記クライアント装置が、
放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置との接続を確立する場合に、プロキシとしての機能を有する前記ゲートウェイ装置からネットワークを介して提供される、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報に基づいて、前記プロキシとの接続を確立し、
前記ゲートウェイ装置から、前記ネットワークを介して転送されてくる前記コンテンツを再生する
ステップを含むデータ処理方法。
1 伝送システム, 10 ゲートウェイ装置, 20−1乃至20−N,20 クライアント装置, 30 ネットワーク, 40 放送サーバ, 50 送信所, 60 放送伝送路, 70 通信サーバ, 80 インターネット, 100 処理部, 101 チューナ, 102 通信I/F, 103 通信I/F, 104 記憶部, 111 UPnP/SSDPサーバ, 112 プロキシアプリマネージャ, 113 ローカルプロキシ, 114 SLS処理系, 200 処理部, 201 通信I/F, 202 表示部, 203 スピーカ, 211 アプリケーション, 212 ブラウザ, 1000 コンピュータ, 1001 CPU
Claims (20)
- コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入する処理部を備える
情報処理装置。 - 前記処理部は、放送サービスをサービスエントリとして、通信経由で、前記リクエストが送信される場合に、前記リクエストに対し、前記識別情報を挿入する
請求項1に記載の情報処理装置。 - 前記識別情報は、前記コンテンツの配信元を識別するための情報である
請求項2に記載の情報処理装置。 - 前記識別情報は、前記放送サービスを識別する識別子を少なくとも含む
請求項3に記載の情報処理装置。 - 前記識別情報は、前記コンテンツを識別する識別子、前記コンテンツの再生を制御する制御情報の取得先を示す情報、及び前記コンテンツに関する時刻情報のうち、少なくとも1つの情報をさらに含む
請求項4に記載の情報処理装置。 - 前記処理部は、プロキシとしての機能を有する
請求項2に記載の情報処理装置。 - 放送波を受信する受信部と、
インターネット上のサーバと通信を行う通信部と
をさらに備え、
前記処理部は、
前記放送波から得られる制御情報に基づいて、前記識別情報を格納したマッピングデータベースを生成し、
HTTP(Hypertext Transfer Protocol)リクエストを、前記サーバに送信する場合、前記マッピングデータベースから得られる前記識別情報を、前記HTTPリクエストのリクエストヘッダに挿入し、
前記通信部は、前記HTTPリクエストを、前記インターネットを介して、前記サーバに送信する
請求項6に記載の情報処理装置。 - 前記情報処理装置は、ネットワークに接続されたクライアント装置に対し、放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置であり、
前記処理部は、前記クライアント装置からのHTTPリクエストを、前記サーバに送信する場合、前記HTTPリクエストのリクエストヘッダに、前記識別情報を挿入する
請求項7に記載の情報処理装置。 - 前記情報処理装置は、放送経由又は通信経由で配信されるコンテンツを再生するクライアント装置であり、
前記処理部は、前記クライアント装置からのHTTPリクエスト、又はネットワークに接続された他のクライアント装置からのHTTPリクエストを、前記サーバに送信する場合、前記HTTPリクエストのリクエストヘッダに、前記識別情報を挿入する
請求項7に記載の情報処理装置。 - 前記処理部は、前記クライアント装置との接続を確立する場合に、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報を、前記クライアント装置に提供する
請求項8に記載の情報処理装置。 - 前記クライアント装置は、前記プロキシの構成を設定するためのスクリプトファイルの内容を、前記接続情報により書き換え、当該スクリプトファイルを実行することで、前記プロキシとの接続を確立する
請求項10に記載の情報処理装置。 - 前記処理部は、前記クライアント装置により、前記接続情報を取得するためのAPI(Application Programming Interface)が実行された場合に、前記接続情報を、前記クライアント装置に提供する
請求項11に記載の情報処理装置。 - 前記リクエストは、セキュアなプロトコルを用いて通信が行われ、
前記プロキシは、透過型のプロキシ(Transparent Proxy)である
請求項6に記載の情報処理装置。 - 情報処理装置のデータ処理方法において、
前記情報処理装置が、
コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入するステップを含む
データ処理方法。 - 放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置との接続を処理する処理部と、
前記ゲートウェイ装置から、ネットワークを介して転送されてくる前記コンテンツを再生する再生部と
を備え、
前記ゲートウェイ装置は、プロキシとしての機能を有し、
前記処理部は、前記ゲートウェイ装置から前記ネットワークを介して提供される、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報に基づいて、前記プロキシとの接続を確立する
クライアント装置。 - 前記処理部は、前記プロキシの構成を設定するためのスクリプトファイルの内容を、前記接続情報により書き換え、当該スクリプトファイルを実行することで、前記プロキシとの接続を確立する
請求項15に記載のクライアント装置。 - 前記処理部は、前記ゲートウェイ装置から前記ネットワークを介して提供される、前記接続情報を取得するためのAPIを実行することで、前記接続情報を取得する
請求項16に記載のクライアント装置。 - 前記プロキシは、前記クライアント装置からのコンテンツのリクエストを、インターネット上のサーバに送信する場合、前記リクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入する
請求項17に記載のクライアント装置。 - 前記プロキシは、放送サービスをサービスエントリとして、通信経由で、前記リクエストが送信される場合に、前記リクエストに対し、前記識別情報を挿入する
請求項18に記載のクライアント装置。 - クライアント装置のデータ処理方法において、
前記クライアント装置が、
放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置との接続を確立する場合に、プロキシとしての機能を有する前記ゲートウェイ装置からネットワークを介して提供される、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報に基づいて、前記プロキシとの接続を確立し、
前記ゲートウェイ装置から、前記ネットワークを介して転送されてくる前記コンテンツを再生する
ステップを含むデータ処理方法。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2016161194 | 2016-08-19 | ||
JP2016161194 | 2016-08-19 | ||
PCT/JP2017/028338 WO2018034172A1 (ja) | 2016-08-19 | 2017-08-04 | 情報処理装置、クライアント装置、及び、データ処理方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JPWO2018034172A1 true JPWO2018034172A1 (ja) | 2019-06-13 |
Family
ID=61196595
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2018534344A Pending JPWO2018034172A1 (ja) | 2016-08-19 | 2017-08-04 | 情報処理装置、クライアント装置、及び、データ処理方法 |
Country Status (8)
Country | Link |
---|---|
US (1) | US20210288735A1 (ja) |
EP (1) | EP3503568A4 (ja) |
JP (1) | JPWO2018034172A1 (ja) |
KR (1) | KR102496890B1 (ja) |
BR (1) | BR112019002867A2 (ja) |
CA (1) | CA3033735A1 (ja) |
MX (1) | MX2019001568A (ja) |
WO (1) | WO2018034172A1 (ja) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015105391A1 (en) * | 2014-01-13 | 2015-07-16 | Lg Electronics Inc. | Apparatuses and methods for transmitting or receiving a broadcast content via one or more networks |
CN109672613B (zh) * | 2018-12-12 | 2021-06-18 | 北京数码视讯软件技术发展有限公司 | 自适应访问方法、装置及电子设备 |
US11411918B2 (en) * | 2020-05-26 | 2022-08-09 | Microsoft Technology Licensing, Llc | User interface for web server risk awareness |
TWI806632B (zh) * | 2022-05-27 | 2023-06-21 | 新加坡商聯發科技(新加坡)私人有限公司 | 影音播放裝置及其影音信號資訊顯示方法 |
US11876713B1 (en) * | 2023-03-13 | 2024-01-16 | Intuit Inc. | Client side backoff filter for rate limiting |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPWO2002103964A1 (ja) * | 2001-06-18 | 2004-10-07 | ソニー株式会社 | データ転送装置、データ転送方法及びデータ転送方法のプログラム |
JP2007110586A (ja) * | 2005-10-17 | 2007-04-26 | Nec Corp | 映像配信システム、映像配信サーバ、映像配信方法、映像配信プログラム |
US8719375B2 (en) * | 2007-03-22 | 2014-05-06 | Microsoft Corporation | Remote data access techniques for portable devices |
US9826502B2 (en) * | 2011-07-25 | 2017-11-21 | Qualcomm Incorporated | Managing handoff triggering between unicast and multicast services |
JP5297510B2 (ja) * | 2011-09-15 | 2013-09-25 | 株式会社東芝 | 情報処理装置および情報提供方法 |
JP2013131882A (ja) * | 2011-12-21 | 2013-07-04 | Dainippon Printing Co Ltd | 連動情報配信サーバー装置、コンピュータプログラム |
JP5959206B2 (ja) | 2012-01-18 | 2016-08-02 | ソニー株式会社 | 受信装置、受信方法、及びプログラム |
US9674251B2 (en) * | 2013-06-17 | 2017-06-06 | Qualcomm Incorporated | Mediating content delivery via one or more services |
US10560509B2 (en) * | 2013-07-05 | 2020-02-11 | Qualcomm Incorporated | Method and apparatus for using HTTP redirection to mediate content access via policy execution |
US20210195254A1 (en) * | 2016-02-01 | 2021-06-24 | Lg Electronics Inc. | Device for transmitting broadcast signal, device for receiving broadcast signal, method for transmitting broadcast signal, and method for receiving broadcast signal |
-
2017
- 2017-08-04 WO PCT/JP2017/028338 patent/WO2018034172A1/ja unknown
- 2017-08-04 US US16/319,558 patent/US20210288735A1/en active Pending
- 2017-08-04 EP EP17841397.7A patent/EP3503568A4/en active Pending
- 2017-08-04 MX MX2019001568A patent/MX2019001568A/es unknown
- 2017-08-04 KR KR1020197003080A patent/KR102496890B1/ko active IP Right Grant
- 2017-08-04 JP JP2018534344A patent/JPWO2018034172A1/ja active Pending
- 2017-08-04 CA CA3033735A patent/CA3033735A1/en active Pending
- 2017-08-04 BR BR112019002867-6A patent/BR112019002867A2/pt not_active Application Discontinuation
Also Published As
Publication number | Publication date |
---|---|
MX2019001568A (es) | 2019-06-06 |
WO2018034172A1 (ja) | 2018-02-22 |
EP3503568A4 (en) | 2019-08-28 |
BR112019002867A2 (pt) | 2019-05-14 |
KR20190039403A (ko) | 2019-04-11 |
CA3033735A1 (en) | 2018-02-22 |
KR102496890B1 (ko) | 2023-02-08 |
US20210288735A1 (en) | 2021-09-16 |
EP3503568A1 (en) | 2019-06-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9723375B2 (en) | Apparatus and method for processing an interactive service | |
US9883251B2 (en) | Method and apparatus for managing connection between broadcast receiving device and another device connected by network | |
CN108293148B (zh) | 接收装置、发送装置以及数据处理方法 | |
KR102496890B1 (ko) | 정보 처리 장치, 클라이언트 장치, 및 데이터 처리 방법 | |
CN105227587B (zh) | 设立网际协议电视会话的网络装置以及方法 | |
US10554745B2 (en) | Method and apparatus for managing connection between broadcasting reception device and another device which are connected through network | |
KR102443060B1 (ko) | 정보 처리 장치 및 정보 처리 방법 | |
US11374670B2 (en) | Receiving device, transmitting device, and data processing method | |
US10979495B2 (en) | Information processing apparatus, information processing method, and information processing system | |
KR102611253B1 (ko) | 수신 장치, 송신 장치 및 데이터 처리 방법 | |
WO2018021015A1 (ja) | 受信装置、送信装置、及び、データ処理方法 | |
US20240137596A1 (en) | Methods for multimedia data delivery and apparatuses for implementing the same | |
WO2018012315A1 (ja) | 情報処理装置、及び、情報処理方法 |