WO2018012315A1 - 情報処理装置、及び、情報処理方法 - Google Patents

情報処理装置、及び、情報処理方法 Download PDF

Info

Publication number
WO2018012315A1
WO2018012315A1 PCT/JP2017/024103 JP2017024103W WO2018012315A1 WO 2018012315 A1 WO2018012315 A1 WO 2018012315A1 JP 2017024103 W JP2017024103 W JP 2017024103W WO 2018012315 A1 WO2018012315 A1 WO 2018012315A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
viewing history
information processing
processing apparatus
compliant
Prior art date
Application number
PCT/JP2017/024103
Other languages
English (en)
French (fr)
Inventor
山岸　靖明
Original Assignee
ソニー株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ソニー株式会社 filed Critical ソニー株式会社
Priority to BR112019000345-2A priority Critical patent/BR112019000345A2/pt
Priority to JP2018527514A priority patent/JPWO2018012315A1/ja
Priority to CA3029413A priority patent/CA3029413A1/en
Priority to MX2018016225A priority patent/MX2018016225A/es
Priority to KR1020197000156A priority patent/KR20190029572A/ko
Priority to US16/306,993 priority patent/US20200053406A1/en
Priority to EP17827445.2A priority patent/EP3487182A4/en
Publication of WO2018012315A1 publication Critical patent/WO2018012315A1/ja

Links

Images

Classifications

    • 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
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/02—Arrangements for relaying broadcast information
    • H04H20/08—Arrangements for relaying broadcast information among terminal devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25866—Management of end-user data
    • H04N21/25891—Management of end-user data being end-user preferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/61—Arrangements for services using the result of monitoring, identification or recognition covered by groups H04H60/29-H04H60/54
    • H04H60/66—Arrangements for services using the result of monitoring, identification or recognition covered by groups H04H60/29-H04H60/54 for using the result on distributors' side
    • 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
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N17/00—Diagnosis, testing or measuring for television systems or their details
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44213—Monitoring of end-user related data
    • H04N21/44222—Analytics of user selections, e.g. selection of programs or purchase activity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/4508—Management of client data or end-user data
    • H04N21/4516—Management of client data or end-user data involving client characteristics, e.g. Set-Top-Box type, software version or amount of memory available
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/4508—Management of client data or end-user data
    • H04N21/4532—Management of client data or end-user data involving end-user characteristics, e.g. viewer profile, preferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content 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
    • 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/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL

Definitions

  • the present technology relates to an information processing device and an information processing method, and more particularly, to an information processing device and an information processing method that can flexibly perform operations related to a viewing history.
  • operations related to viewing history such as collecting and analyzing content viewing history by users, may be performed.
  • a technique for transmitting viewing history regularly or when necessary is disclosed (for example, see Patent Document 1).
  • This technology has been made in view of such a situation, and is intended to enable flexible operation related to viewing history.
  • An information processing apparatus is viewing history information related to a viewing history of digital broadcast content, and a device capable of processing data that conforms to the digital broadcast standard by a device that has played the content It is an information processing apparatus provided with the viewing history processing part which produces
  • the information processing apparatus may be an independent apparatus or may be an internal block constituting one apparatus.
  • the information processing method according to the first aspect of the present technology is an information processing method corresponding to the information processing apparatus according to the first aspect of the present technology described above.
  • the viewing history information related to the viewing history of the content of the digital broadcast, and the device that has played the content conforms to the digital broadcast standard
  • the viewing history information including device information indicating whether or not the device is capable of processing the processed data is generated.
  • An information processing apparatus is viewing history information related to a viewing history of a digital broadcast content, and a device capable of processing data that conforms to the digital broadcast standard by a device that has played the content
  • a receiving unit that receives the viewing history information including device information indicating whether or not, and collecting the viewing history information from a plurality of devices, and the plurality of collected viewing history information according to the device information
  • An information processing apparatus including a processing unit that performs processing.
  • the information processing apparatus may be an independent apparatus or may be an internal block constituting one apparatus.
  • the information processing method according to the second aspect of the present technology is an information processing method corresponding to the information processing apparatus according to the second aspect of the present technology described above.
  • the viewing history information related to the viewing history of the content of the digital broadcast, and the device that has played the content conforms to the digital broadcast standard
  • the viewing history information including device information indicating whether or not the device is capable of processing the received data is received, the viewing history information from a plurality of devices is collected, and the plurality of collected viewing history information is the Processed according to device information.
  • the operation related to viewing history can be flexibly performed.
  • FIG. 1 is a diagram illustrating an example of a protocol stack corresponding to the IP transmission method.
  • the upper layer of the physical layer (PHY: Physical Layer) and the MAC layer is a UDP / IP layer.
  • the UDP / IP layer is a layer corresponding to a network layer and a transport layer in a communication hierarchical model, and an IP packet and a UDP (User Datagram Protocol) packet are specified by an IP address and a port number.
  • LLS Low Level Signaling
  • SLS Service Layer Signaling
  • the LLS is stored in a UDP / IP packet and transmitted.
  • the LLS includes metadata such as SLT (Service List Table).
  • SLT metadata includes basic information indicating the configuration of a stream or service in a broadcast network, such as information necessary for service (channel) channel selection.
  • the SLT metadata is transmitted by being included in a UDP / IP packet that is an IP packet including a UDP packet.
  • ROUTE Real-time Object Delivery Service Unidirectional Transport
  • FLUTE FLUTE
  • SLS file Service Signaling File
  • DASH segment file Audio / Video / CC DASH File
  • LCC Longcally Cached Content file
  • SLS is service level signaling that provides information and attributes necessary for searching and selecting components belonging to the target service.
  • SLS includes metadata such as USBD (User Service Bundle Description), S-TSID (Service-based Transport Session Instance Description), and MPD (Media Presentation Description).
  • USBD User Service Bundle Description
  • S-TSID Service-based Transport Session Instance Description
  • MPD Media Presentation Description
  • USBD metadata includes information such as where to obtain other metadata.
  • the S-TSID metadata is an extension of LSID (LCT Session Instance Description) for ATSC 3.0, and is ROUTE protocol control information. Further, the S-TSID metadata can specify EFDT (Extended FDT) transmitted in the ROUTE session. EFDT is an extension of FDT (File Delivery Table) introduced in FLUTE, and is control information for transfer.
  • MPD metadata is video and audio file control information used for streaming delivery in conformity with MPEG-DASH.
  • MPEG-DASH is a streaming distribution standard according to OTT-V (Over The Top Video) and is a standard related to adaptive streaming distribution using a streaming protocol based on HTTP (Hypertext Transfer Protocol).
  • This MPEG-DASH standard defines a manifest file for describing metadata, which is control information of video and audio files, and a file format for transmitting moving image content.
  • the former manifest file is called MPD (Media Presentation Description), and the latter file format is also called a segment format.
  • the MP4 file format can be used as the streaming file format.
  • the MP4 file format is a derived format of ISO BMFF (ISO Base Media File Format) defined in ISO / IEC 14496-12.
  • ISO BMFF is composed of a tree structure called a box.
  • the segment transmitted in the ROUTE session is composed of an initialization segment (IS: Initialization Segment) and a media segment (MS: Media Segment).
  • the initialization segment includes initialization information such as a data compression method.
  • the media segment stores video, audio, and subtitle stream data. This media segment corresponds to a DASH segment (DASH segment file).
  • SLT metadata as LLS and metadata such as USBD, S-TSID, and MPD as SLS are text data described in a markup language such as XML (Extensible Markup Language), for example. Can do.
  • the video, audio, and subtitle stream, the SLS stream, and the LCC content stream transmitted in the ROUTE session are stored in the UDP / IP packet and transmitted.
  • the LCC content is once stored in the storage of the receiver and then played back.
  • a file other than the LCC content (for example, an application file) may be transmitted in the ROUTE session.
  • FIG. 2 is a diagram illustrating a configuration of a transmission system corresponding to the IP transmission scheme.
  • the IP transmission system a transmission system implementation model corresponding to ATSC 3.0 will be described.
  • the system refers to a logical collection of a plurality of devices.
  • the 2 includes a transmission system 10, a corresponding client device 20, and a non-compatible client device 30.
  • the corresponding client device 20 is connected to the transmission system 10 via the Internet 60.
  • the compatible client device 20 is connected to the non-compatible client device 30 via a LAN 70 such as a home LAN (Local Area Network).
  • the transmission system 10 is a system for delivering content such as a TV program via a predetermined transmission path.
  • the transmission path includes a communication transmission path such as the Internet 60 in addition to a broadcast transmission path such as a terrestrial wave.
  • the transmission system 10 processes content such as a TV program as data compliant with ATSC 3.0, and transmits it as a digital broadcast wave to a plurality of corresponding client devices 20 via the relay station 50 (broadcast distribution). ) Further, the transmission system 10 processes content such as a TV program as data for streaming distribution, and transmits (streams distribution) to the corresponding client device 20 via the Internet 60.
  • the compatible client device 20 is an electronic device (ATSC 3.0 compatible device) capable of processing data compliant with ATSC 3.0.
  • the corresponding client device 20 includes a fixed receiver such as a television receiver, a gateway, a network storage, and a set top box.
  • the corresponding client device 20 includes a control unit 200, a broadcast middleware 201, an HTTP proxy server 202, a browser 203, and communications 1 / F 204-1 and 204-2.
  • the control unit 200 includes, for example, a CPU (Central Processing Unit) and a microprocessor.
  • the control unit 200 controls the operation of each unit of the corresponding client device 20.
  • the broadcast middleware 201 is client local ATSC middleware in which a broadcast reception stack is mounted.
  • the broadcast middleware 201 receives a digital broadcast broadcast wave from the transmission system 10 according to control from the control unit 200 and processes data obtained from the broadcast wave.
  • the broadcast middleware 201 includes a PHY / MAC processing unit 211, an LLS retriever 212, an LLS parser 213, an SLS retriever 214, an SLS parser 215, and a segment retriever 216.
  • the PHY / MAC processing unit 211 includes, for example, a tuner and a demodulator.
  • the PHY / MAC processing unit 211 performs processing on a physical layer frame obtained from a broadcast wave.
  • An ALP (ATSC-Link-Layer Protocol) packet is extracted from the data part of the physical layer frame, and a UDP / IP packet is obtained from the payload of the ALP packet.
  • ALP ATSC-Link-Layer Protocol
  • the LLS retriever 212 acquires LLS (SLT metadata) included in the UDP / IP packet from the data processed by the PHY / MAC processing unit 211 and supplies the LLS to the LLS parser 213.
  • the LLS parser 213 performs syntax analysis on the LLS (SLT metadata) from the LLS retriever 212 and supplies the analysis result to the SLS retriever 214.
  • the SLS retriever 214 is a stream of a ROUTE session that is transmitted as a UDP / IP packet (an LCT packet included therein) from data processed by the PHY / MAC processing unit 211.
  • SLS metadata such as USBD and S-TSID
  • the SLS parser 215 performs syntax analysis on the SLS (metadata such as USBD and S-TSID) from the SLS retriever 214 and supplies the analysis result to the segment retriever 216 and the HTTP proxy server 202 (the proxy cache 221). .
  • the segment retriever 216 is a stream of a ROUTE session that is transmitted as a UDP / IP packet (an LCT packet included) from the data processed by the PHY / MAC processing unit 211. Is acquired and supplied to the HTTP proxy server 202 (the proxy cache 221).
  • the HTTP proxy server 202 is a client local HTTP proxy server (Client Local HTTP HTTP Server) installed on the corresponding client device 20.
  • the HTTP proxy server 202 stores the DASH segment file or SLS file received by the broadcast middleware 201 that performs broadcast reception processing or the communication I / F 204-1 that performs communication reception processing according to the control from the control unit 200.
  • the control unit 200 controls the HTTP proxy server 202 to an application that plays
  • the HTTP proxy server 202 includes a proxy cache 221, a proxy cache 222, and a broadcast / communication address resolver 223.
  • the proxy cache 221 acquires a DASH segment and MPD metadata file from the broadcast middleware 201.
  • the proxy cache 222 acquires the DASH segment and MPD metadata file received by the communication I / F 204-1.
  • the communication I / F 204-1 receives a DASH segment or MPD metadata file as data streamed from the transmission system 10 via the Internet 60 under the control of the control unit 200.
  • the broadcast / communication address resolver 223 is a DASH segment or MPD metadata file acquired by the proxy cache 221 or the proxy cache 222 in response to a request from an ATSC 3.0 client application (for example, the DASH client 231 or the DASH client 311). Is supplied to the browser 203 or the communication I / F 204-2.
  • the HTTP proxy server 202 that receives the request receives a broadcast / communication address resolver 223 via the broadcast. A determination is made whether to acquire (via the broadcast reception stack) or via communication (via the communication reception stack).
  • the SLS parser 215. makes an acquisition request for USBD metadata, T-TSID metadata, and the like to the SLS retriever 214.
  • the SLS retriever 214 extracts the signaling meta included in the SLS LCT packet received via the PHY / MAC processing unit 211.
  • the SLS parser 215 subtracts the signaling meta included in the LCT packet from the URL (Uniform Resource Locator) included in the request from the ATSC 3.0 client application, and obtains the broadcast distribution address information for acquiring the target file group. Resolve. Then, if it is found that it is distributed via broadcast, the segment retriever 216 acquires the LCT packet including the DASH segment file from the ROUTE session stream based on the broadcast distribution address information, and the proxy cache of the HTTP proxy server 202 Deploy within 221.
  • URL Uniform Resource Locator
  • the HTTP proxy server 202 returns the file group thus expanded in the proxy cache 221 as a response (HTTP response) to a request (HTTP request) from the ATSC 3.0 client application.
  • the HTTP proxy server 202 acquires it via the communication reception stack developed in the proxy cache 222. Return the file group as a response (HTTP response) to the request (HTTP request) from the ATSC 3.0 client application.
  • the browser 203 is, for example, a browser that supports HTML5 (HyperText Markup Language 5).
  • the browser 203 processes the DASH segment and MPD metadata file from the broadcast / communication address resolver 223 according to the control from the control unit 200 and reproduces the content distributed from the transmission system 10.
  • the browser 203 includes a DASH client 231, a decoder 232, and a renderer 233.
  • the DASH client 231 includes an MPD retriever 241, an MPD parser 242, a segment retriever 243, and an MP4 parser 244.
  • the DASH client 231 is an ATSC3.0 client application (ATSC3.0 DASH Client) executed by the browser 203 mounted on the corresponding client device 20.
  • the DASH client 231 processes the DASH segment and MPD metadata files received by the broadcast middleware 201 or the communication I / F 204-1 via the HTTP proxy server 202.
  • the DASH client 231 is not limited to an application executed on the browser 203, and may be provided as a so-called native application.
  • the MPD retriever 241 acquires an MPD metadata file from the data supplied from the HTTP proxy server 202 (broadcast / communication address resolver 223), and supplies it to the MPD parser 242.
  • the MPD parser 242 performs syntax analysis on the MPD metadata from the MPD retriever 241 and supplies the analysis result to the segment retriever 243.
  • the segment retriever 243 acquires a DASH segment file from the data supplied from the HTTP proxy server 202 (its broadcast / communication address resolver 223) based on the analysis result of the MPD metadata from the MPD parser 242, and the MP4 parser 244 To supply.
  • the MP4 parser 244 performs syntax analysis on the DASH segment file (segment) from the segment retriever 243 and supplies the analysis result to the decoder 232 together with the DASH segment file.
  • the decoder 232 decodes data obtained from the DASH segment file according to the analysis result from the MP4 parser 244 and supplies the decoded data obtained as a result to the renderer 233.
  • the renderer 233 performs a rendering process on the decoded data from the decoder 232.
  • the video corresponding to the video data obtained by this rendering process is displayed on a display such as LCD (Liquid Crystal Display) or OELD (Organic Electroluminescence Display), and the sound corresponding to the audio data is output from the speaker.
  • a display such as LCD (Liquid Crystal Display) or OELD (Organic Electroluminescence Display), and the sound corresponding to the audio data is output from the speaker.
  • the display and the speaker may be provided in the corresponding client device 20 or may be provided in an external device.
  • the communication I / F 204-2 exchanges data with the incompatible client device 30 via the LAN 70 such as a home LAN in accordance with the control from the control unit 200.
  • the communication I / F 204-2 is described as being provided separately from the communication I / F 204-1; however, the communication I / F 204-1 and the communication I / F 204-2 are described. May be configured as one communication interface circuit.
  • the communication I / F 204-2 supplies the request to the HTTP proxy server 202 (its broadcast / communication address resolver 223) when content distribution is requested from the non-compliant client device 30 via the LAN 70. .
  • the broadcast / communication address resolver 223 In response to a request (HTTP request) from the communication I / F 204-2, the broadcast / communication address resolver 223 converts the DASH segment or MPD metadata file acquired by the proxy cache 221 or the proxy cache 222 into the communication I / F 204. -2. Then, the communication I / F 204-2 transmits the DASH segment and MPD metadata file from the broadcast / communication address resolver 223 to the incompatible client device 30 via the LAN 70.
  • HTTP request HyperText Transfer Protocol request
  • the non-compliant client device 30 is an electronic device (ATSC 3.0 non-compliant device) that cannot process data compliant with ATSC 3.0.
  • the non-compliant client device 30 includes a mobile receiver such as a smartphone, a mobile phone, and a tablet computer.
  • the non-compliant client device 30 includes a control unit 300, a communication I / F 301, and a browser 302.
  • the control unit 300 includes, for example, a CPU and a microprocessor.
  • the control unit 300 controls the operation of each unit of the incompatible client device 30.
  • the communication I / F 301 is composed of, for example, a communication interface circuit.
  • the communication I / F 301 exchanges data with the corresponding client device 20 via a LAN 70 such as a home LAN in accordance with control from the control unit 300.
  • the communication I / F 301 when the communication I / F 301 requests the corresponding client device 20 to distribute content, the communication I / F 301 transmits the request (HTTP request) to the corresponding client device 20 via the LAN 70. As a result, the communication I / F 301 receives the DASH segment and MPD metadata files transmitted from the corresponding client device 20 via the LAN 70 and supplies them to the browser 302.
  • the browser 302 is a browser that supports HTML5, for example.
  • the browser 302 processes the DASH segment and MPD metadata file from the communication I / F 301 according to the control from the control unit 300, and reproduces the content transmitted from the corresponding client device 20.
  • the content transmitted from the corresponding client device 20 is the content distributed by the transmission system 10.
  • the browser 302 includes a DASH client 311, a decoder 312, and a renderer 313.
  • the DASH client 311 includes an MPD retriever 321, an MPD parser 322, a segment retriever 323, and an MP4 parser 324.
  • the DASH client 311 is an ATSC3.0 client application (ATSC3.0 DASH Client) executed by the browser 302 mounted on the non-compliant client device 30.
  • the DASH client 311 processes the DASH segment and MPD metadata file received by the communication I / F 301.
  • the DASH client 311 is not limited to an application executed on the browser 302, and may be provided as a so-called native application.
  • the MPD retriever 321 acquires an MPD metadata file from the data supplied from the communication I / F 301 and supplies it to the MPD parser 322.
  • the MPD parser 322 performs syntax analysis on the MPD metadata from the MPD retriever 321 and supplies the analysis result to the segment retriever 323.
  • the segment retriever 323 acquires a DASH segment file from the data supplied from the communication I / F 301 based on the analysis result of the MPD metadata from the MPD parser 322, and supplies it to the MP4 parser 324.
  • the MP4 parser 324 performs syntax analysis on the DASH segment file (segment) from the segment retriever 323 and supplies the analysis result to the decoder 312 together with the DASH segment file.
  • the decoder 312 decodes the data obtained from the DASH segment file according to the analysis result from the MP4 parser 324 and supplies the decoded data obtained as a result to the renderer 313.
  • the renderer 313 performs a rendering process on the decoded data from the decoder 312.
  • the video corresponding to the video data obtained by this rendering process is displayed on a display such as an LCD or OELD, and the audio corresponding to the audio data is output from the speaker.
  • the display and the speaker may be provided in the non-compliant client device 30 or may be provided in an external device.
  • the transmission system corresponding to the IP transmission method is configured as described above.
  • content distributed from the transmission system 10 compliant with ATSC 3.0 is not only supported by the corresponding client device 20 that is an ATSC 3.0 compatible device, but also by a non-compatible client device 30 that is not an ATSC 3.0 compatible device. Can also be played.
  • the non-compliant client device 30 cannot process data compliant with ATSC 3.0, but can include a DASH client 311 as an ATSC 3.0 client application. Then, the DASH client 311 processes the DASH segment and MPD metadata file obtained by the corresponding client device 20 to reproduce the content distributed from the transmission system 10.
  • the DASH client 231 and the DASH client 311 do not need to be aware of whether the file group to be processed is acquired via broadcast or via communication (the network transparency is low). Therefore, the portability of the application can be improved. As a result, it is not necessary to mount the client device exclusively for broadcast reception, and the client device can be mounted regardless of which of broadcast reception and communication reception is used.
  • Non-patent document 1 ATSC Candidate Standard: Service Service Usage (A / 333) Doc. S33-170r316 May 2016
  • the client device that is the end point of the viewing history is identified by the device ID, and the viewing history for each client device is reported.
  • a mode in which (ATSC3.0 non-compliant device) accesses content transmitted by the ATSC3.0 protocol is assumed.
  • the viewing history of the non-compliant client device 30 (ATSC 3.0 non-compliant device) is also reported, but the compatible client device 20 (ATSC 3.0 compliant device) and non-compliant client are reported. It is difficult to report the viewing history for each client device by distinguishing from the device 30 (device not compatible with ATSC 3.0). Therefore, a proposal for flexible operation of the viewing history is requested so that the compatible client device 20 (ATSC 3.0 compatible device) and the non-compatible client device 30 (ATSC 3.0 non-compatible device) can be distinguished. It was.
  • the viewing history information includes the device information indicating whether or not the client device that has reproduced the content is a device that can process data compliant with the digital broadcasting standard. It is possible to identify which report is the corresponding client device 20 (ATSC 3.0 compatible device) and the non-compatible client device 30 (ATSC 3.0 non-compatible device).
  • the non-compliant client device 30 accesses the HTTP proxy server 202 implemented in the corresponding client device 20 (ATSC 3.0 compliant device) as a gateway.
  • the viewing history information includes information unique to the device in the header of the HTTP request for the content to be played from) and the IP address of the transmission source of the HTTP request.
  • the non-compliant client device 30 (ATSC 3.0 non-compliant device) shown in FIG. 2 accesses the content transmitted by the ATSC 3.0 protocol (content distributed by the transmission system 10).
  • ATSC 3.0 non-compliant device accesses the content transmitted by the ATSC 3.0 protocol (content distributed by the transmission system 10).
  • CDM Consption Data Message
  • FIG. 3 is a diagram showing an example of the current CDM format.
  • CDM is described in JSON (JavaScript (registered trademark) Object Notation) format, which is a kind of text format.
  • Device information (device information) is specified in DeviceInfo.
  • DeviceInfo In the current CDM, deviceID, deviceModel, deviceManufacturer, deviceOS, and peripheralDevice are defined as DeviceInfo attribute values.
  • FIG. 4 shows the detailed contents of the attribute value of DeviceInfo. Only one DeviceInfo is described for each device.
  • the device ID that is the identifier of the target device is specified for deviceID. However, “NOTREPORTED” is described when this device ID is intentionally hidden.
  • model number of the target device is specified. However, this model number is in a vendor-specific format. When this model number is intentionally hidden, “NOTREPORTED” is described.
  • OS Operating System
  • peripheralDevice information for identifying whether the target device is a peripheral device is specified.
  • this identification information is intentionally hidden, “NOTREPORTED” is described.
  • AVService specifies information related to the ATSC 3.0 service stream played on the target device.
  • ServiceID, serviceType, and reportInterval are defined as AVService attribute values.
  • serviceID the ID of the service played on the target device is specified. However, this service ID is a globally unique value.
  • serviceType the type of service identified by the service ID is specified.
  • startTime, endTime, DestinationDeviceType, contentID, component, AppInterval are specified.
  • type and cid are defined as attribute values of contentID.
  • componentType, componentRole, componentName, componentID, componentLang, startTime, endTime, and SourceDeliveryPath are defined as component attribute values
  • type, startTime, and endTime are defined as attribute values in SourceDeliveryPath.
  • appId, startTime, endTime, LifeCycle, and Tags are defined as AppInterval attribute values.
  • DestinationDeviceType For example, when “0" is specified, it indicates that the target service is viewed by the television receiver, and "1" is specified. In this case, it indicates that the target service has been viewed by a device other than the television receiver (for example, a tablet computer).
  • 0-Content is presented on a Primary Device 1-Content is presented on a Companion Device 2-Content is sent to a Time-shift-buffer 3-Content is sent to a Hard-drive 4 to 255-Reserved.
  • EIDR or “Ad ID” can be specified as the contentID type.
  • EIDR is an abbreviation for Entertainment Identifier Registry, which can manage TV program and movie content with a single global ID.
  • Ad ID is an abbreviation for Advertising ID, and is an ID for advertisement.
  • SourceDeliveryPath when “0" is specified, it indicates that the component of the target service has been distributed via broadcasting, and "1" When specified, it indicates that the component of the target service has been distributed via communication.
  • 0-Broadcast delivery (content component is delivered by broadcast)
  • 1-Broadband delivery (content component is delivered by broadband)
  • 2-Time-shift-buffer source (content source is local time shift buffer)
  • 3-Hard-drive source (content source is local hard drive) 4 to 255-Reserved.
  • the Cardinality item represents the number of appearances. For example, when “1” is designated, only one element or attribute is designated. Also, for example, when “0..N” is specified, whether or not one or more of its elements or attributes are specified is arbitrary, and when "1..N” is specified, the element Alternatively, one or more attributes are specified.
  • FIG. 5 is a diagram illustrating a configuration of an embodiment of a transmission system to which the present technology is applied.
  • FIG. 5 as in FIG. 2, an implementation model of a transmission system corresponding to ATSC 3.0 will be described as an example of the IP transmission method.
  • portions corresponding to those of the transmission system of FIG. 2 are denoted by the same reference numerals, and the description thereof will be repeated, and will be omitted as appropriate.
  • the transmission system 10 is provided with a UR (Usage Reporting) server 101 that collects viewing history information. Further, the corresponding client device 20 is provided with a UR client 224 and an HTTP request handler 225 in the HTTP proxy server 202 as functions (modules) for reporting viewing history information.
  • UR User Reporting
  • the content reproduction history (viewing history) in the browser 203 (the DASH client 231) of the corresponding client device 20
  • the content reproduction history (viewing history) in the browser 302 (the DASH client 311) of the incompatible client device 30 can be recorded and reported.
  • the UR client 224 is a module that generates viewing history information having a CDM structure of the present technology in response to a notification from the HTTP request handler 225.
  • the HTTP request handler 225 is a module that first receives and analyzes a request (HTTP request) from an ATSC 3.0 client application (DASH client 231 or DASH client 311).
  • the UR client 224 responds to the notification from the HTTP request handler 225, and the viewing history information according to the content reproduction by the browser 203 (the DASH client 231) of the corresponding client device 20 or the non-compatible client device 30. Viewing history information corresponding to the reproduction of the content in the browser 302 (the DASH client 311) is generated.
  • the UR client 224 monitors the HTTP request traffic via the HTTP request handler 225, thereby implementing the DASH client 231 installed inside the corresponding client device 20 and the outside of the corresponding client device 20. It becomes possible to record the content reproduction history (viewing history) with the DASH client 311.
  • viewing history information consists of the CDM structure of this technology.
  • the CDM structure defined in ATSC 3.0 includes a DeviceInfo element as device information and an AVService element related to an ATSC 3.0 service stream reproduced by the device.
  • the CDM structure includes device information (non3.0DeviceAttributes) that indicates whether the client device that played back the content is a device that can process data compliant with ATSC 3.0. It is possible to identify whether the history information (CDM) is a report of the corresponding client device 20 (ATSC 3.0 compatible device) or the non-compatible client device 30 (ATSC 3.0 non-compatible device).
  • device information non3.0DeviceAttributes
  • the UR client 224 has information unique to the device in the header of the HTTP request for the content to be played from the non-compliant client device 30 (ATSC 3.0 non-compliant device) accessing the HTTP proxy server 202.
  • the IP address of the HTTP request source is included in the viewing history information (CDM).
  • CDM viewing history information
  • the UR client 224 supplies viewing history information to the communication I / F 204-1 at a predetermined timing.
  • the communication I / F 204-1 transmits viewing history information from the UR client 224 to the UR server 101 via the Internet 60.
  • the timing at which the UR client 224 transmits the viewing history information is, for example, periodically transmitted at a predetermined interval, or signaling transmitted from the transmission system 10 to the corresponding client device 20, video, It can be sent in response to comments included in an audio watermark message.
  • the UR server 101 receives viewing history information transmitted from the corresponding client device 20 (the UR client 224) via the Internet 60.
  • the UR server 101 includes a plurality of corresponding client devices 20 (from the UR clients 224). Viewing history information is received, and a plurality of viewing history information is collected.
  • the UR server 101 performs various processes such as viewing history analysis and analysis on the collected viewing history information. For example, the UR server 101 can generate a viewing history report related to a viewing history for each broadcasting station and provide it to each broadcasting station.
  • the viewing history information having the CDM structure of the present technology includes device information (non3.0DeviceAttributes) indicating whether or not the client device that has played the content is a device capable of processing data compliant with ATSC3.0. It is included.
  • the UR server 101 identifies whether the target viewing history information is a report of the corresponding client device 20 (ATSC 3.0 compatible device) or the non-compatible client device 30 (ATSC 3.0 non-compatible device). Thus, a viewing history report can be generated. That is, even if the non-compliant client device 30 (ATSC 3.0 non-compliant device) accesses content transmitted using the ATSC 3.0 protocol, the non-compliant client device 30 (ATSC 3.0 non-compliant device) The viewing history can be identified.
  • the content of the target service is reproduced by either the television receiver or the device other than the television receiver, depending on the DestinationDeviceType. It can be seen that the content of the target service has been played by either the compatible client device 20 (ATSC 3.0 compatible device) or the non compatible client device 30 (ATSC 3.0 non compatible device) like CDM. Absent.
  • the transmission system of this technology is configured as described above.
  • FIG. 6 is a diagram illustrating an example of a CDM format of the present technology. As described above, the CDM is described in the JSON format.
  • the CDM format shown in FIG. 6 is different from the above-mentioned CDM format (FIG. 3) in that non3.0DeviceAttributes are added in addition to deviceID, deviceModel, deviceManufacturer, deviceOS, and peripheralDevice as DeviceInfo attribute values. Is different.
  • Non3.0DeviceAttributes is an attribute indicating whether the device can process data compliant with ATSC3.0. With this non3.0DeviceAttributes, it is possible to identify whether the target CDM is a report of the corresponding client device 20 (ATSC3.0 compatible device) or the noncompatible client device 30 (ATSC3.0 noncompatible device). It becomes.
  • a set of "schemeIdUri” and “value” can be specified.
  • a value that is "urn: browserUserAgent” as a URI (Uniform Resource Identifier) that identifies the content of the header of the HTTP request user agent (UserAgent)
  • the character string (information) stored in the header can be described as the value of “value”.
  • the user agent header (HTTP request header) of the HTTP request for the DASH segment file or application file of the broadcast service issued by the non-compliant client device 30 includes information on the operating system (OS) as the user agent. Information indicating whether the terminal is a mobile terminal is included.
  • This HTTP request uses the GET method among the methods defined in HTTP.
  • the non-compliant client device 30 converts Windows (registered trademark) into an operating system (OS). It turns out that it is a personal computer.
  • OS operating system
  • the non-compliant client device 30 is a smartphone using Android (registered trademark) as an operating system (OS).
  • OS operating system
  • the user agent if “Mobile” is not described, it is understood that the user agent is a tablet computer.
  • JSON-formatted objects are key-value pairs that are separated by a colon (:), and these pairs are separated by commas (,), and zero or more are enumerated, and the whole is enclosed in curly braces ( ⁇ ). Expressed by wrapping.
  • FIG. 7 is a diagram illustrating a CDM description example when information related to a user agent is included as information unique to an ATSC 3.0 incompatible device.
  • FIG. 7 for simplification of explanation, a part of the attribute value of DeviceInfo and the attribute value of AVService are extracted and described.
  • deviceID, deviceModel, deviceManufacturer, deviceOS, peripheralDevice, and non3.0DeviceAttributes are included as DeviceInfo attribute values.
  • the value "NOTREPORTED" is specified as a pair for the key deviceID. That is, the device ID is intentionally hidden.
  • a value of "NOTREPORTED” is specified for deviceModel, deviceManufacturer, deviceOS, and peripheralDevice, respectively, and the model number of the target device, the manufacturer (vendor) of the target device, and the operating system (OS) of the target device And information for identifying whether the target device is a peripheral device is intentionally hidden.
  • SchemeIdUri a value that is "urn: browserUserAgent” is defined as a URI that identifies the contents of the HTTP request user agent header, and the character string stored in the user agent header (Information) is described as the value of “value”.
  • the value of “value” is “Mozilla / 5.0 (Linux; U; Android 2.2.1; en-us; Nexus One Build / FRG83) AppleWebKit / 533.1 (KHTML, like Gecko) Version / 4.0 Mobile Safari / 533.1 ", indicating that the non-compliant client device 30 is a smartphone using Android (registered trademark) as an operating system (OS).
  • OS operating system
  • AVService reportInterval a set of "type” and “cid” is specified as the ContentID attribute value.
  • a value that is “EIDR” is defined for “type”
  • “10.5240 / EA73-79D7-1B2B-B378” is defined as the value of “cid” that is the content identifier (CID: Content ID) of the EIDR format.
  • CID Content ID
  • ComponentType is specified as the component attribute value.
  • a value of “1” is set for “componentType”, indicating that the target component is video.
  • the incompatible client device 30 (ATSC3.0) as a smartphone identified by the attribute value of non3.0DeviceAttributes and using Android (registered trademark) as an operating system (OS).
  • OS operating system
  • the content reproduced by the non-compatible device is a video content having a content identifier (CID) in the EIDR format of “10.5240 / EA73-79D7-1B2B-B378-3A73-M”.
  • FIG. 8 is a diagram illustrating a description example of CDM when information related to a user agent and an IP address are included as information unique to an ATSC 3.0 incompatible device.
  • the DeviceInfo attribute value and a part of the AVService attribute value are extracted and described.
  • the description corresponding to the description example of FIG. Shall be omitted.
  • a pair of “schemeIdUri” and “value” is specified as the attribute value of non3.0DeviceAttributes.
  • “schemeIdUri” the content of the header of the user agent in the HTTP request is used.
  • the value that is "urn: ipAddress” is defined as the URI that identifies the contents of the IP address, and the value of the IP address is "value" Is listed as the value of ".
  • the smartphone is identified by the attribute value of non3.0DeviceAttributes and uses Android (registered trademark) as the operating system (OS), and is “192.168.0.12”.
  • Content identifier in EIDR format in which the content played by the non-compliant client device 30 (ATSC 3.0 non-compliant device) to which the local IP address is assigned is “10.5240 / EA73-79D7-1B2B-B378-3A73-M” This indicates that the video content has (CID).
  • the description format of the CDM of the present technology is not limited to the JSON format, but other formats such as an XML (Extensible Markup Language) format, for example. Data in text format can also be adopted.
  • JSON Joint Photographic Experts Group
  • XML Extensible Markup Language
  • JSON schema example 9 to 12 are diagrams illustrating examples of the JSON schema of the CDM of the present technology.
  • the JSON schema in FIGS. 9 to 12 corresponds to the CDM format of the present technology shown in FIG.
  • this JSON schema corresponds to the CDM of this technology that is an extension of the current CDM specified in ATSC 3.0, and the structure other than the extended part is the same as the JSON schema structure of the current CDM It is.
  • the structure of the current JSON schema of CDM is disclosed in “Annex A: Schema” of Non-Patent Document 1 described above, and therefore the description thereof is omitted here.
  • non3.0DeviceAttributes are defined as attribute values of DeviceInfo in the paragraphs 29 to 44 in FIG.
  • a pair of a character string type “schemeIdUri” and a character string type “value” is defined as an attribute value of non3.0DeviceAttributes that is an array type.
  • “schemeIdUri” is an essential element.
  • CDM JSON schema for example, by defining a value that is "urn: browserUserAgent” for “schemeIdUri", the user agent information in the HTTP request can be used as the value of "value”. Can be described. Also, for example, by defining a value “urn: ipAddress” for “schemeIdUri”, the local IP address can be described as the value “value”.
  • FIG. 13 is a diagram illustrating an example of a protocol between the UR server 101 illustrated in FIG. 5 and the UR client 224 of the corresponding client device 20.
  • the broadcast middleware 201 processes the LLS from the transmission system 10 to obtain SLT metadata.
  • the URL of the UR server 101 is included in this SLT metadata.
  • the communication I / F 204-1 can access the UR server 101 via the Internet 60 in accordance with the URL of the UR server 101 included in the SLT metadata. Note that details of the URL of the UR server 101 that is well-known in the SLT metadata will be described later with reference to FIGS. 15 and 16.
  • viewing history information generated by the UR client 224 of the HTTP proxy server 202 is transmitted to the UR server 101 via the Internet 60.
  • This viewing history information (CDM) can be stored in the body portion using the PUT method of the HTTP request.
  • viewing history information can be transmitted from the corresponding client device 20 (UR client 224) to the UR server 101 in the format of the CDM message shown in FIG.
  • “PUT” indicating the method
  • URI indicating the directory and path name of the specified URL
  • HTTP / 1.1 indicating the HTTP version
  • viewing history information transmitted from the corresponding client device 20 (UR client 224) is received and processed by the UR server 101 via the Internet 60.
  • CDM viewing history information
  • FIG. 14 is a diagram illustrating a configuration example of the UR server 101 of FIG.
  • the UR server 101 includes a communication I / F 111, a CDM recording unit 112, a CDM analysis unit 113, and an output unit 114.
  • the communication I / F 111 includes, for example, a communication interface circuit and the like, and exchanges data with the corresponding client device 20 via the Internet 60.
  • the communication I / F 111 receives viewing history information transmitted from a plurality of corresponding client devices 20 via the Internet 60 and supplies the viewing history information to the CDM recording unit 112.
  • the CDM recording unit 112 includes, for example, a hard disk (HDD: Hard Disk Drive), a semiconductor memory, and the like.
  • the CDM recording unit 112 records viewing history information from the communication I / F 111. Thereby, viewing history information from a plurality of corresponding client devices 20 is collected. This viewing history information has the CDM structure of the present technology shown in FIG.
  • the CDM analysis unit 113 is composed of, for example, a CPU and a microprocessor.
  • the CDM analysis unit 113 reads the viewing history information recorded in the CDM recording unit 112 and analyzes the read viewing history information.
  • the CDM analysis unit 113 generates a viewing history report related to the viewing history according to the analysis result of the viewing history information, and supplies the viewing history report to the output unit 114.
  • the output unit 114 includes, for example, an output interface circuit and a display such as an LCD.
  • the output unit 114 outputs the viewing history report from the CDM analysis unit 113 to an external device.
  • a viewing history report may be displayed on the display.
  • UR server 101 is configured as described above.
  • FIG. 15 is a diagram illustrating an example of the format of SLT metadata in the XML format.
  • “@” is added to the attribute. Further, the indented element and attribute are specified for the upper element.
  • Non-patent document 2 ATSC Candidate Standard: Signaling, Delivery, Synchronization, and Error Protection (A / 331) Doc. S33-174r15 January 2016
  • the SLT element is a root element and includes a sltInetUrl element.
  • a URL corresponding to the URL type specified by the attribute value of the urlType attribute can be specified for each frequency band (for example, 6 MHz) identified by the broadcast stream ID.
  • FIG. 16 shows an example of attribute values of the urlType attribute.
  • “3” indicates that the URL of the UR server 101 is specified in the sltInetUrl element. That is, when the configuration of the transmission system shown in FIG. 5 is adopted, the operation related to the viewing history of the content is performed as UsageUReporting, so the URL of the UR server 101 is described in the sltInetUrl element of the SLT metadata, "3" is specified as the attribute.
  • the SLT element includes one or more Service elements.
  • Information related to each service is specified for each service.
  • This Service element includes an svcInetUrl element.
  • a URL corresponding to the URL type specified by the attribute value of the urlType attribute can be specified for each service identified by the service ID.
  • the attribute value shown in FIG. 16 is also specified for the attribute value of the urlType attribute of the svcInetUrl element. That is, when “3” is specified as the urlType attribute, the URL of the UR server 101 is specified in the svcInetUrl element.
  • the URL of the UR server 101 when the URL of the UR server 101 is specified for each frequency band identified by the broadcast stream ID, it may be described in the sltInetUrl element under the SLT element. Further, when the URL of the UR server 101 is specified for each service identified by the service ID, it may be described in the svcInetUrl element under the Service element.
  • the use item represents the number of appearances. For example, when “0..N” is designated, whether or not one or more of the elements or attributes is designated is arbitrary. Also, for example, when “1" is specified, only one element or attribute is specified. When “1..N” is specified, one or more elements or attributes are specified.
  • the item “Data Type” represents the data format. For example, when “anyURI” is designated, the data represents a character string in the form of URI. For example, when “unsignedByte” is designated, it represents an integer from 0 to 255.
  • step S101 is executed by the transmission system 10. Further, the processing of steps S201 to S206 and S221 to S225 is executed by the corresponding client device 20. Further, the processing of steps S301 to S302 is executed by the non-compliant client device 30.
  • the control unit 300 of the non-compliant client device 30 controls the communication I / F 301 and requests the DASH segment file of the content from the compatible client device 20 via the LAN 70.
  • the control unit 300 of the non-compliant client device 30 controls the communication I / F 301 and requests the DASH segment file of the content from the compatible client device 20 via the LAN 70.
  • an IP packet storing an HTTP request from the non-compliant client device 30 is 20 is notified.
  • the IP packet storing the HTTP request from the incompatible client device 30 is received by the communication I / F 204-2 and supplied to the HTTP request handler 225 of the HTTP proxy server 202.
  • step S201 the HTTP request handler 225 checks the source address (source address) of the IP packet in which the HTTP request is stored.
  • step S202 the HTTP request handler 225 determines whether the transmission source address is from the local DASH client according to the transmission source address check result in step S201.
  • the IP address assigned to the non-compliant client device 30 on which the DASH client 311 is installed is the transmission source address, it is determined that the transmission source address is from the local DASH client (S202). "YES"), the process proceeds to step S203.
  • step S202 If it is determined in step S202 that the transmission source address is not from the local DASH client, the processing ends after the necessary processing is performed.
  • step S203 the HTTP request handler 225 notifies the UR client 224 of the transmission source address determined in the process of step S202. Thereby, in the HTTP proxy server 202, the transmission source address from the HTTP request handler 225 is received by the UR client 224.
  • step S221 the UR client 224 records the IP address corresponding to the transmission source address from the HTTP request handler 225 for the CDM (DeviceInfo.non3.0DeviceAttributes) managed for each non-compliant client device 30.
  • CDM DeviceInfo.non3.0DeviceAttributes
  • step S204 the HTTP request handler 225 extracts the character string of the user agent (UserAgent) from the HTTP request header stored in the IP packet of the transmission source address that is the determination target in step S202. Notify the client 224. Thereby, in the HTTP proxy server 202, the information of the user agent from the HTTP request handler 225 is received by the UR client 224.
  • UserAgent user agent
  • the UR client 224 records the user agent information from the HTTP request handler 225 in the CDM (DeviceInfo.non3.0DeviceAttributes) managed for each non-compliant client device 30.
  • the user agent information includes, for example, information about an operating system (OS) and information indicating whether the mobile terminal is a mobile terminal.
  • OS operating system
  • IP address IP address
  • user agent information do not necessarily have to be repeatedly acquired if they have the same content, and the acquired information can be reused.
  • the HTTP request handler 225 receives the DASH segment file, which is content data such as a TV program distributed from the transmission system 10 and obtained by the processing of the broadcast middleware 201, via the LAN 70. Transfer to the corresponding client device 30.
  • step S302 the DASH client 311 of the non-compliant client device 30 reproduces the DASH segment file transferred from the compatible client device 20 (the HTTP request handler 225 of the HTTP proxy server 202). Thereby, in the non-compliant client device 30, the content such as the television program distributed from the transmission system 10 is reproduced and viewed by the user.
  • step S206 the HTTP request handler 225 notifies the UR client 224 of the segment URL corresponding to the DASH segment file transferred to the non-compliant client device 30 in the process of step S205. Thereby, in the HTTP proxy server 202, the segment URL from the HTTP request handler 225 is received by the UR client 224.
  • step S223 the UR client 224 records information corresponding to the segment URL from the HTTP request handler 225 in the CDM (AVService) managed for each non-compliant client device 30.
  • CDM AVService
  • the content ID (ContentID) corresponding to the segment URL can be acquired by referring to the MPD metadata, and therefore the content ID can be recorded in AVService.reportInterval.contentID of the CDM.
  • information other than the content ID can be recorded as long as the information is included in the CDM structure shown in FIG.
  • the time processed as required can be recorded in AVService.reportInterval.startTime (endTime) of the CDM.
  • step S224 the control unit 200 determines whether it is time to transmit the CDM.
  • the determination condition includes, for example, a condition for periodically transmitting at a predetermined interval, a signaling transmitted from the transmission system 10 to the corresponding client device 20, and a video or audio watermark message. Conditions according to comments are used.
  • step S224 If it is determined in step S224 that it is not time to transmit the CDM, the process returns to step S221, and the subsequent processes are repeated. That is, in this case, the DASH segment file is transferred in response to a request from the incompatible client device 30, and the reproduction history (viewing history) is continuously recorded.
  • step S224 determines whether it is time to transmit the CDM. If it is determined in step S224 that it is time to transmit the CDM, the process proceeds to step S225.
  • step S225 the UR client 224 transmits CDM encoded in the JSON format obtained by the processing in steps S221 to S223 to the UR server 101 via the Internet 60 as viewing history information.
  • the communication I / F 204-1 accesses the UR server 101 via the Internet 60 in accordance with the URL of the UR server 101 obtained from the SLT metadata, so that the viewing history information (CDM) from the UR client 224 is obtained. ) Is transmitted to the UR server 101.
  • CDM viewing history information
  • the viewing history information (CDM) from the corresponding client device 20 is received by the communication I / F 111.
  • viewing history information is received from a plurality of corresponding client devices 20, and a plurality of viewing history information is collected.
  • step S101 the CDM analysis unit 113 of the UR server 101 analyzes the collected viewing history information (CDM) and generates a viewing history report related to the viewing history.
  • CDM collected viewing history information
  • the viewing history information (CDM) includes device information (non3.0DeviceAttributes) indicating whether or not the client device that has played the content is a device capable of processing data compliant with ATSC3.0. . Therefore, the CDM analysis unit 113 reports that the target viewing history information (CDM) is either the corresponding client device 20 (ATSC 3.0 compatible device) or the non-compatible client device 30 (ATSC 3.0 non-compatible device). And a viewing history report can be generated.
  • device information non3.0DeviceAttributes
  • the non-compliant client device 30 (non-ATSC 3.0 non-compliant device) is configured so that the non-compliant client device 30 accesses the content transmitted by the ATSC 3.0 protocol via the compatible client device 20.
  • non3.0DeviceAttributes is added to the attribute value of the DeviceInfo of the CDM so that information unique to the non-compliant client device 30 is designated.
  • information specific to the corresponding client device 20 may be specified for non3.0DeviceAttributes of DeviceInfo of CDM.
  • information included in the user agent of the HTTP request can be included as information unique to the corresponding client device 20.
  • FIG. 19 shows a CDM description example when information related to a user agent is included as information unique to an ATSC 3.0 compatible device.
  • a set of “schemeIdUri” and “value” is specified as the attribute value of non3.0DeviceAttributes.
  • a value that is "urn: browserUserAgent” is defined as a URI that identifies the contents of the HTTP request user agent header, and the character string stored in the user agent header (Information) is described as the value of “value”.
  • value for example, information related to an operating system (OS), information indicating whether the terminal is a mobile terminal, or the like is described.
  • OS operating system
  • the HTTP request from the DASH client 231 of the browser 203 to the HTTP proxy server 202 does not include the IP address assigned to the corresponding client device 20. Therefore, the non-compliant client device 30 (ATSC 3.0) that can include the IP address by not including the IP address in the viewing history information (CDM) of the compatible client device 20 (ATSC 3.0 compatible device). It is possible to distinguish it from viewing history information (CDM) (for example, the description example of the CDM in FIG. 8) of the non-compatible device.
  • CDM viewing history information
  • ATSC Advanced Television System
  • DVB Digital Video Broadcasting
  • the present invention is not limited to the IP transmission method and is applied to other methods such as an MPEG2-TS (Transport Stream) method. You may do it.
  • digital broadcasting standards include satellite broadcasting using broadcasting satellites (BS: Broadcasting Satellite) and communication satellites (CS: Communications Satellite), cable broadcasting such as cable TV (CATV), etc. Can be applied to
  • the above-mentioned names such as signaling and packet are examples, and other names may be used.
  • the difference between the names is a formal difference, and the substantial contents of the target signaling and packet are not different.
  • “non3.0DeviceAttributes” is defined as an attribute indicating whether the device can process data compliant with ATSC 3.0, but other names may be used.
  • USBD User Service Bundle Description
  • USD User Service Description
  • LCC Longcally Cached Content
  • NRT Non Real Time
  • FIG. 20 is a diagram illustrating a configuration example of the hardware of a computer that executes the above-described series of processing by a program.
  • a CPU Central Processing Unit
  • ROM Read Only Memory
  • RAM Random Access Memory
  • An input / output interface 1005 is further connected to the bus 1004.
  • An input unit 1006, an output unit 1007, a recording unit 1008, a communication unit 1009, and a drive 1010 are connected to the input / output interface 1005.
  • the input unit 1006 includes a keyboard, a mouse, a microphone, and the like.
  • the output unit 1007 includes a display, a speaker, and the like.
  • the recording unit 1008 includes a hard disk, a nonvolatile memory, and the like.
  • the communication unit 1009 includes a network interface or the like.
  • the drive 1010 drives a removable recording medium 1011 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory.
  • the CPU 1001 loads the program recorded in the ROM 1002 or the recording unit 1008 to the RAM 1003 via the input / output interface 1005 and the bus 1004 and executes the program. A series of processing is performed.
  • the program executed by the computer 1000 can be provided by being recorded on a removable recording medium 1011 as a package medium, for example.
  • the program can be provided via a wired or wireless transmission medium such as a local area network, the Internet, or digital satellite broadcasting.
  • the program can be installed in the recording unit 1008 via the input / output interface 1005 by attaching the removable recording medium 1011 to the drive 1010.
  • the program can be received by the communication unit 1009 via a wired or wireless transmission medium and installed in the recording unit 1008.
  • the program can be installed in the ROM 1002 or the recording unit 1008 in advance.
  • the processing performed by the computer according to the program does not necessarily have to be performed in chronological order in the order described as the flowchart. That is, the processing performed by the computer according to the program includes processing executed in parallel or individually (for example, parallel processing or object processing).
  • the program may be processed by a single computer (processor) or may be distributedly processed by a plurality of computers.
  • the present technology can take the following configurations.
  • the viewing history information relating to viewing history of digital broadcast content wherein the viewing history includes device information indicating whether or not the device that has played the content is a device that can process data compliant with the digital broadcast standard
  • An information processing apparatus including a viewing history processing unit that generates information.
  • the viewing history information includes, as the device information, information unique to a compatible device compatible with the digital broadcast standard or a non-compatible device not compatible with the digital broadcast standard. apparatus.
  • the information processing apparatus according to (2), wherein the unique information is information included in a user agent of an HTTP (Hypertext Transfer Protocol) request.
  • HTTP Hypertext Transfer Protocol
  • the unique information further includes an IP (Internet Protocol) address when the HTTP request is from the incompatible device.
  • the information processing apparatus includes at least information on an operating system (OS) and information indicating whether the user agent is a mobile terminal.
  • a receiver for receiving a broadcast wave of the digital broadcast A data processing unit for processing data obtained from the broadcast wave and compliant with the digital broadcasting standard; A communication unit that transmits the data from the data processing unit to the non-compliant device via a network in response to an HTTP request transmitted from the non-compliant device;
  • the viewing history processing unit assigns information included in a user agent obtained from an HTTP request from the non-compliant device to the non-compliant device with respect to the content viewing history played on the non-compliant device.
  • the information processing apparatus according to (4), wherein the viewing history information associated with an IP address is generated.
  • the information processing apparatus according to any one of (3) to (6), wherein the viewing history processing unit is implemented as a module of an HTTP proxy server.
  • the information processing apparatus according to any one of (2) to (6), wherein the content is played back on a browser in the compatible device or the non-compatible device.
  • the information processing apparatus according to (6), wherein the communication unit transmits the viewing history information to a viewing history server that collects the viewing history information via a network.
  • the information processing apparatus is The viewing history information relating to viewing history of digital broadcast content, wherein the viewing history includes device information indicating whether or not the device that has played the content is a device that can process data compliant with the digital broadcast standard
  • An information processing method including a step of generating information.
  • An information processing apparatus comprising: a processing unit that collects the viewing history information from a plurality of devices and processes the collected viewing history information according to the device information.
  • the viewing history information includes, as the device information, information unique to a compatible device compatible with the digital broadcast standard or a non-compatible device not compatible with the digital broadcast standard. apparatus.
  • the information processing apparatus according to (14), wherein the unique information further includes an IP address when the HTTP request is from the non-compliant device.
  • the user agent includes at least information related to an operating system (OS) and information indicating whether the user agent is a mobile terminal.
  • OS operating system
  • the information processing apparatus is The viewing history information relating to viewing history of digital broadcast content, wherein the viewing history includes device information indicating whether or not the device that has played the content is a device that can process data compliant with the digital broadcast standard Receive information,
  • An information processing method comprising: collecting the viewing history information from a plurality of devices and processing the collected viewing history information according to the device information.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Multimedia (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Social Psychology (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Graphics (AREA)
  • Biomedical Technology (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)
  • Circuits Of Receivers In General (AREA)
  • Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)

Abstract

本技術は、視聴履歴に関する運用を柔軟に行うことができるようにする情報処理装置、及び、情報処理方法に関する。 情報処理装置は、デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、コンテンツを再生した機器が、デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む視聴履歴情報を生成することで、視聴履歴に関する運用を柔軟に行うことができる。本技術は、例えば、視聴履歴に関する運用の対象となる機器に適用することができる。

Description

情報処理装置、及び、情報処理方法
　本技術は、情報処理装置、及び、情報処理方法に関し、特に、視聴履歴に関する運用を柔軟に行うことができるようにした情報処理装置、及び、情報処理方法に関する。
　放送の分野では、ユーザによるコンテンツの視聴履歴を収集して分析するなどの視聴履歴に関する運用が行われる場合がある。例えば、視聴履歴を、定期的に又は必要なときに伝送する技術が開示されている（例えば、特許文献１参照）。
特開２００９－２７８６５１号公報
　ところで、視聴履歴に関する運用を行うための技術方式が確立されていないため、視聴履歴に関する運用を柔軟に行うための提案が要請されていた。
　本技術はこのような状況に鑑みてなされたものであり、視聴履歴に関する運用を柔軟に行うことができるようにするものである。
　本技術の第１の側面の情報処理装置は、デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報を生成する視聴履歴処理部を備える情報処理装置である。
　本技術の第１の側面の情報処理装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面の情報処理方法は、上述した本技術の第１の側面の情報処理装置に対応する情報処理方法である。
　本技術の第１の側面の情報処理装置、及び、情報処理方法においては、デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報が生成される。
　本技術の第２の側面の情報処理装置は、デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報を受信する受信部と、複数の機器からの前記視聴履歴情報を収集し、収集された複数の前記視聴履歴情報を、前記機器情報に応じて処理する処理部とを備える情報処理装置である。
　本技術の第２の側面の情報処理装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面の情報処理方法は、上述した本技術の第２の側面の情報処理装置に対応する情報処理方法である。
　本技術の第２の側面の情報処理装置、及び、情報処理方法においては、デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報が受信され、複数の機器からの前記視聴履歴情報が収集され、収集された複数の前記視聴履歴情報が、前記機器情報に応じて処理される。
　本技術の第１の側面、及び、第２の側面によれば、視聴履歴に関する運用を柔軟に行うことができる。
　なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
IP伝送方式に対応したプロトコルスタックの例を示す図である。 IP伝送方式に対応した伝送システムの構成を示す図である。 現行のCDMのフォーマットの例を示す図である。 DeviceInfoの詳細な内容を説明する図である。 本技術を適用した伝送システムの一実施の形態の構成を示す図である。 本技術のCDMのフォーマットの例を示す図である。 ATSC3.0非対応機器のCDMの記載例を示す図である。 ATSC3.0非対応機器のCDMの記載例を示す図である。 CDMのJSONスキーマの例を示す図である。 CDMのJSONスキーマの例を示す図である。 CDMのJSONスキーマの例を示す図である。 CDMのJSONスキーマの例を示す図である。 URサーバとURクライアントとの間のプロトコルの例を示す図である。 URサーバの構成例を示す図である。 SLTのフォーマットの例を示す図である。 urlType属性の属性値の例を示す図である。 視聴履歴情報対応処理の流れを説明するフローチャートである。 視聴履歴情報対応処理の流れを説明するフローチャートである。 ATSC3.0対応機器のCDMの記載例を示す図である。 コンピュータの構成例を示す図である。
　以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
１．本技術の概要
２．システムの構成
３．本技術の視聴履歴情報（CDM）
４．Usage Reporting装置間のプロトコル
５．視聴履歴情報対応処理の流れ
６．変形例
７．コンピュータの構成
＜１．本技術の概要＞
　デジタル放送の伝送方式として、現状では、MPEG2-TS(Transport Stream)方式が広く普及しているが、今後は、通信の分野で用いられているIP(Internet Protocol)パケットをデジタル放送に用いたIP伝送方式が普及することが想定されている。例えば、次世代地上波放送規格の１つであるATSC(Advanced Television Systems Committee)3.0においても、IP伝送方式を採用して、より高度なサービスを提供できるようにすることが期待されている。
（プロトコルスタックの例）
　図１は、IP伝送方式に対応したプロトコルスタックの例を示す図である。
　図１のプロトコルスタックにおいて、物理層(PHY：Physical Layer)とMAC層の上位の階層は、UDP/IP層とされる。UDP/IP層は、通信の階層モデルにおけるネットワーク層とトランスポート層に相当する層であり、IPアドレスとポート番号により、IPパケットとUDP(User Datagram Protocol)パケットが特定される。
　ここで、ATSC3.0では、シグナリングとして、LLS(Low Level Signaling)とSLS(Service Layer Signaling)を用いることが想定されている。LLSは、SLSよりも下位の層で伝送されるシグナリングである。SLSは、サービス単位のシグナリングである。すなわち、ATSC3.0では、トランスポート層のシグナリングが、LLSとSLSの２階層で伝送される。
　LLSは、UDP/IPパケットに格納されて伝送される。LLSには、SLT(Service List Table)等のメタデータが含まれる。SLTメタデータは、サービス（チャネル）の選局に必要な情報など、放送ネットワークにおけるストリームやサービスの構成を示す基本情報を含む。このSLTメタデータは、UDPパケットを含むIPパケットであるUDP/IPパケットに含めて伝送される。
　UDP/IP層に隣接する上位の階層は、ROUTE(Real-time Object Delivery over Unidirectional Transport)とされる。ROUTEは、ストリーミングファイル転送用のプロトコルであって、FLUTE(File Delivery over Unidirectional Transport)を拡張したものである。
　このROUTEセッションにより、サービス（Service）ごとに、SLSのファイル（Service Signaling File）や、DASHセグメントのファイル（Audio/Video/CC DASH File）、LCC(Locally Cached Content)のファイル（LCC(NRT) File）などが伝送される。
　SLSは、サービスレベルのシグナリングであり、対象のサービスに属するコンポーネントの探索と選択に必要な情報や属性などを提供するものである。SLSは、USBD(User Service Bundle Description)，S-TSID(Service-based Transport Session Instance Description)，MPD(Media Presentation Description)等のメタデータを含む。
　USBDメタデータは、他のメタデータの取得先などの情報を含む。
　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に準拠したストリーミング配信を行うために用いられる、ビデオやオーディオのファイルの制御情報である。ここで、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)の派生フォーマットである。ISO BMFFは、ボックス（Box）と称される木構造から構成される。
　ROUTEセッションで伝送されるセグメントは、イニシャライゼイションセグメント（IS：Initialization Segment）と、メディアセグメント（MS：Media Segment）から構成される。イニシャライゼイションセグメントは、データ圧縮方式等の初期化情報を含んでいる。また、メディアセグメントは、ビデオやオーディオ、字幕のストリームのデータを格納している。なお、このメディアセグメントが、DASHセグメント（DASHセグメントファイル）に相当するものである。
　なお、LLSとしてのSLTメタデータと、SLSとしてのUSBD，S-TSID，MPD等のメタデータは、例えば、XML(Extensible Markup Language)等のマークアップ言語により記載されたテキスト形式のデータとすることができる。
　このように、ROUTEセッションで伝送される、ビデオ、オーディオ、及び、字幕のストリームと、SLSのストリームと、LCCコンテンツのストリームは、UDP/IPパケットに格納されて伝送される。なお、LCCコンテンツは、受信機のストレージに一旦蓄積された後で再生が行われる。また、LCCコンテンツ以外のファイル（例えばアプリケーションのファイル）がROUTEセッションで伝送されるようにしてもよい。
（伝送システムの構成）
　図２は、IP伝送方式に対応した伝送システムの構成を示す図である。ここでは、IP伝送方式の一例として、ATSC3.0に対応した伝送システムの実装モデルを説明する。なお、システムとは、複数の装置が論理的に集合したものをいう。
　図２の伝送システムは、送信システム１０、対応クライアント装置２０、及び非対応クライアント装置３０から構成される。対応クライアント装置２０は、インターネット６０を介して送信システム１０と相互に接続される。また、対応クライアント装置２０は、家庭内LAN(Local Area Network)等のLAN７０を介して非対応クライアント装置３０と相互に接続される。
　送信システム１０は、テレビ番組等のコンテンツを、所定の伝送路を介して配信するためのシステムである。ここで、伝送路としては、地上波等の放送伝送路のほか、インターネット６０等の通信伝送路がある。
　送信システム１０は、テレビ番組等のコンテンツを、ATSC3.0に準拠したデータとして処理し、デジタル放送の放送波として、中継局５０を介して、複数の対応クライアント装置２０に送信（一斉同報配信）する。また、送信システム１０は、テレビ番組等のコンテンツを、ストリーミング配信するためのデータとして処理し、インターネット６０を介して、対応クライアント装置２０に送信（ストリーミング配信）する。
　対応クライアント装置２０は、ATSC3.0に準拠したデータを処理可能な電子機器（ATSC3.0対応機器）である。例えば、対応クライアント装置２０は、テレビ受像機やゲートウェイ、ネットワークストレージ、セットトップボックスなどの固定受信機からなる。
　対応クライアント装置２０は、制御部２００、放送ミドルウェア２０１、HTTPプロキシサーバ２０２、ブラウザ２０３、及び通信1/F２０４－１，２０４－２から構成される。
　制御部２００は、例えば、CPU(Central Processing Unit)やマイクロプロセッサ等から構成される。制御部２００は、対応クライアント装置２０の各部の動作を制御する。
　放送ミドルウェア２０１は、放送系受信スタックが実装されたクライアントローカルATSCミドルウェア（Client Local ATSC Middleware）である。放送ミドルウェア２０１は、制御部２００からの制御に従い、送信システム１０からのデジタル放送の放送波を受信し、放送波から得られるデータを処理する。
　放送ミドルウェア２０１は、PHY・MAC処理部２１１、LLSレトリーバ２１２、LLSパーサ２１３、SLSレトリーバ２１４、SLSパーサ２１５、及びセグメントレトリーバ２１６から構成される。
　PHY・MAC処理部２１１は、例えば、チューナやデモジュレータ等から構成される。PHY・MAC処理部２１１は、放送波から得られる物理層フレームに対する処理を行う。この物理層フレームのデータ部からALP(ATSC Link-Layer Protocol)パケットが抽出され、さらに、ALPパケットのペイロードから、UDP/IPパケットが得られる。
　LLSレトリーバ２１２は、PHY・MAC処理部２１１で処理されたデータから、UDP/IPパケットに含まれるLLS（SLTメタデータ）を取得し、LLSパーサ２１３に供給する。LLSパーサ２１３は、LLSレトリーバ２１２からのLLS（SLTメタデータ）に対する構文解析を行い、その解析結果を、SLSレトリーバ２１４に供給する。
　SLSレトリーバ２１４は、LLSパーサ２１３からのLLSの解析結果に基づいて、PHY・MAC処理部２１１で処理されたデータから、UDP/IPパケット（に含まれるLCTパケット）として伝送されるROUTEセッションのストリームに含まれるSLS（USBD，S-TSID等のメタデータ）を取得し、SLSパーサ２１５に供給する。
　SLSパーサ２１５は、SLSレトリーバ２１４からのSLS（USBD，S-TSID等のメタデータ）に対する構文解析を行い、その解析結果を、セグメントレトリーバ２１６及びHTTPプロキシサーバ２０２（のプロキシキャッシュ２２１）に供給する。
　セグメントレトリーバ２１６は、SLSパーサ２１５からのSLSの解析結果に基づいて、PHY・MAC処理部２１１で処理されたデータから、UDP/IPパケット（に含まれるLCTパケット）として伝送されるROUTEセッションのストリームに含まれるDASHセグメントファイルを取得し、HTTPプロキシサーバ２０２（のプロキシキャッシュ２２１）に供給する。
　HTTPプロキシサーバ２０２は、対応クライアント装置２０上に実装されたクライアントローカルHTTPプロキシサーバ（Client Local HTTP Proxy Server）である。HTTPプロキシサーバ２０２は、制御部２００からの制御に従い、放送系受信処理を行う放送ミドルウェア２０１又は通信系受信処理を行う通信I/F２０４－１により受信されたDASHセグメントファイルやSLSのファイルを、コンテンツの再生を行うアプリケーションに供給する。
　HTTPプロキシサーバ２０２は、プロキシキャッシュ２２１、プロキシキャッシュ２２２、及び放送・通信アドレスリゾルバ２２３から構成される。
　プロキシキャッシュ２２１は、放送ミドルウェア２０１からのDASHセグメントやMPDメタデータのファイルを取得する。プロキシキャッシュ２２２は、通信I/F２０４－１により受信されたDASHセグメントやMPDメタデータのファイルを取得する。なお、通信I/F２０４－１は、制御部２００からの制御に従い、インターネット６０を介して、送信システム１０からストリーミング配信されたデータとして、DASHセグメントやMPDメタデータのファイルを受信する。
　放送・通信アドレスリゾルバ２２３は、ATSC3.0クライアントアプリケーション（例えば、DASHクライアント２３１やDASHクライアント３１１）からの要求に応じて、プロキシキャッシュ２２１又はプロキシキャッシュ２２２により取得されたDASHセグメントやMPDメタデータのファイルを、ブラウザ２０３又は通信I/F２０４－２に供給する。
　具体的には、ATSC3.0クライアントアプリケーションが、DASHセグメントやMPDメタデータのファイル群を要求（HTTPリクエスト）すると、それを受けたHTTPプロキシサーバ２０２では、放送・通信アドレスリゾルバ２２３が、放送経由で（放送受信スタックを介して）取得するか、あるいは通信経由で（通信受信スタックを介して）取得するかの判断を行う。
　この判断の材料となる情報は、SLSパーサ２１５から供給される。すなわち、SLSパーサ２１５は、SLSレトリーバ２１４に対し、USBDメタデータやT-TSIDメタデータ等の取得要求を行う。SLSレトリーバ２１４は、PHY・MAC処理部２１１を介して受信されるSLSのLCTパケットに含まれるシグナリングメタを抽出する。
　SLSパーサ２１５は、ATSC3.0クライアントアプリケーションからの要求に含まれるURL(Uniform Resource Locator)から、LCTパケットに含まれるシグナリングメタを引いて、対象となるファイル群を取得するための放送配信アドレス情報を解決する。そして、放送経由で配信されることがわかれば、その放送配信アドレス情報に基づき、セグメントレトリーバ２１６が、DASHセグメントファイルを含むLCTパケットを、ROUTEセッションのストリームから取得し、HTTPプロキシサーバ２０２のプロキシキャッシュ２２１内に展開する。
　HTTPプロキシサーバ２０２は、このようにしてプロキシキャッシュ２２１内に展開されたファイル群を、ATSC3.0クライアントアプリケーションからの要求（HTTPリクエスト）に対する応答（HTTPレスポンス）として返す。
　なお、ATSC3.0クライアントアプリケーションからの要求に含まれるURLが、LCTパケットのシグナリングメタに存在しない場合には、HTTPプロキシサーバ２０２は、プロキシキャッシュ２２２内に展開された、通信受信スタックを介して取得されたファイル群を、ATSC3.0クライアントアプリケーションからの要求（HTTPリクエスト）に対する応答（HTTPレスポンス）として返す。
　ブラウザ２０３は、例えば、HTML5(HyperText Markup Language 5)に対応したブラウザである。ブラウザ２０３は、制御部２００からの制御に従い、放送・通信アドレスリゾルバ２２３からのDASHセグメントやMPDメタデータのファイルを処理し、送信システム１０から配信されたコンテンツを再生する。
　ブラウザ２０３は、DASHクライアント２３１、デコーダ２３２、及びレンダラ２３３から構成される。また、DASHクライアント２３１は、MPDレトリーバ２４１、MPDパーサ２４２、セグメントレトリーバ２４３、及びMP4パーサ２４４から構成される。
　DASHクライアント２３１は、対応クライアント装置２０上に実装されたブラウザ２０３により実行されるATSC3.0クライアントアプリケーション（ATSC3.0 DASH Client）である。DASHクライアント２３１は、HTTPプロキシサーバ２０２を介して、放送ミドルウェア２０１又は通信I/F２０４－１により受信されたDASHセグメントやMPDメタデータのファイルを処理する。なお、DASHクライアント２３１はブラウザ２０３上で実行されるアプリケーションに限らず、いわゆるネイティブアプリケーションとして提供されるようにしてもよい。
　MPDレトリーバ２４１は、HTTPプロキシサーバ２０２（の放送・通信アドレスリゾルバ２２３）から供給されるデータから、MPDメタデータのファイルを取得し、MPDパーサ２４２に供給する。MPDパーサ２４２は、MPDレトリーバ２４１からのMPDメタデータに対する構文解析を行い、その解析結果を、セグメントレトリーバ２４３に供給する。
　セグメントレトリーバ２４３は、MPDパーサ２４２からのMPDメタデータの解析結果に基づいて、HTTPプロキシサーバ２０２（の放送・通信アドレスリゾルバ２２３）から供給されるデータから、DASHセグメントファイルを取得し、MP4パーサ２４４に供給する。
　MP4パーサ２４４は、セグメントレトリーバ２４３からのDASHセグメントファイル（セグメント）に対する構文解析を行い、その解析結果を、DASHセグメントファイルとともに、デコーダ２３２に供給する。
　デコーダ２３２は、MP4パーサ２４４からの解析結果に従い、DASHセグメントファイルから得られるデータのデコードを行い、その結果得られる復号後のデータを、レンダラ２３３に供給する。レンダラ２３３は、デコーダ２３２からの復号後のデータに対し、レンダリング処理を行う。
　このレンダリング処理で得られるビデオデータに対応する映像が、LCD(Liquid Crystal Display)やOELD(Organic Electroluminescence Display)等のディスプレイに表示され、オーディオデータに対応する音声が、スピーカから出力される。なお、ディスプレイやスピーカは、対応クライアント装置２０が備えるようにしてもよいし、あるいは外部の装置が備えるようにしてもよい。
　通信I/F２０４－２は、制御部２００からの制御に従い、家庭内LAN等のLAN７０を介して、非対応クライアント装置３０との間でデータのやりとりを行う。なお、図２では、説明の都合上、通信I/F２０４－２は、通信I/F２０４－１と別個に設けられるとして説明しているが、通信I/F２０４－１と通信I/F２０４－２を１つの通信インターフェース回路として構成するようにしてもよい。
　例えば、通信I/F２０４－２は、LAN７０を介して、非対応クライアント装置３０からコンテンツの配信が要求された場合、その要求を、HTTPプロキシサーバ２０２（の放送・通信アドレスリゾルバ２２３）に供給する。
　放送・通信アドレスリゾルバ２２３は、通信I/F２０４－２からの要求（HTTPリクエスト）に応じて、プロキシキャッシュ２２１又はプロキシキャッシュ２２２により取得されたDASHセグメントやMPDメタデータのファイルを、通信I/F２０４－２に供給する。そして、通信I/F２０４－２は、放送・通信アドレスリゾルバ２２３からのDASHセグメントやMPDメタデータのファイルを、LAN７０を介して、非対応クライアント装置３０に送信する。
　非対応クライアント装置３０は、ATSC3.0に準拠したデータを処理できない電子機器（ATSC3.0非対応機器）である。例えば、非対応クライアント装置３０は、スマートフォンや携帯電話機、タブレット型コンピュータなどのモバイル受信機からなる。
　非対応クライアント装置３０は、制御部３００、通信I/F３０１、及びブラウザ３０２を含んで構成される。
　制御部３００は、例えば、CPUやマイクロプロセッサ等から構成される。制御部３００は、非対応クライアント装置３０の各部の動作を制御する。
　通信I/F３０１は、例えば、通信インターフェース回路等から構成される。通信I/F３０１は、制御部３００からの制御に従い、家庭内LAN等のLAN７０を介して、対応クライアント装置２０との間でデータのやりとりを行う。
　例えば、通信I/F３０１は、対応クライアント装置２０に対し、コンテンツの配信を要求する場合、その要求（HTTPリクエスト）を、LAN７０を介して、対応クライアント装置２０に送信する。これにより、通信I/F３０１は、LAN７０を介して、対応クライアント装置２０から送信されてくるDASHセグメントやMPDメタデータのファイルを受信し、ブラウザ３０２に供給する。
　ブラウザ３０２は、例えば、HTML5に対応したブラウザである。ブラウザ３０２は、制御部３００からの制御に従い、通信I/F３０１からのDASHセグメントやMPDメタデータのファイルを処理し、対応クライアント装置２０から送信されてくるコンテンツを再生する。なお、対応クライアント装置２０から送信されてくるコンテンツは、送信システム１０により配信されたコンテンツとなる。
　ブラウザ３０２は、DASHクライアント３１１、デコーダ３１２、及びレンダラ３１３から構成される。また、DASHクライアント３１１は、MPDレトリーバ３２１、MPDパーサ３２２、セグメントレトリーバ３２３、及びMP4パーサ３２４から構成される。
　DASHクライアント３１１は、非対応クライアント装置３０上に実装されたブラウザ３０２により実行されるATSC3.0クライアントアプリケーション（ATSC3.0 DASH Client）である。DASHクライアント３１１は、通信I/F３０１により受信されたDASHセグメントやMPDメタデータのファイルを処理する。なお、DASHクライアント３１１はブラウザ３０２上で実行されるアプリケーションに限らず、いわゆるネイティブアプリケーションとして提供されるようにしてもよい。
　MPDレトリーバ３２１は、通信I/F３０１から供給されるデータから、MPDメタデータのファイルを取得し、MPDパーサ３２２に供給する。MPDパーサ３２２は、MPDレトリーバ３２１からのMPDメタデータに対する構文解析を行い、その解析結果を、セグメントレトリーバ３２３に供給する。
　セグメントレトリーバ３２３は、MPDパーサ３２２からのMPDメタデータの解析結果に基づいて、通信I/F３０１から供給されるデータから、DASHセグメントファイルを取得し、MP4パーサ３２４に供給する。
　MP4パーサ３２４は、セグメントレトリーバ３２３からのDASHセグメントファイル（セグメント）に対する構文解析を行い、その解析結果を、DASHセグメントファイルとともに、デコーダ３１２に供給する。
　デコーダ３１２は、MP4パーサ３２４からの解析結果に従い、DASHセグメントファイルから得られるデータのデコードを行い、その結果得られる復号後のデータを、レンダラ３１３に供給する。レンダラ３１３は、デコーダ３１２からの復号後のデータに対し、レンダリング処理を行う。
　このレンダリング処理で得られるビデオデータに対応する映像が、LCDやOELD等のディスプレイに表示され、オーディオデータに対応する音声が、スピーカから出力される。なお、ディスプレイやスピーカは、非対応クライアント装置３０が備えるようにしてもよいし、あるいは外部の装置が備えるようにしてもよい。
　IP伝送方式に対応した伝送システムは、以上のように構成される。
　この伝送システムにおいては、ATSC3.0に準拠した送信システム１０から配信されるコンテンツを、ATSC3.0対応機器である対応クライアント装置２０だけでなく、ATSC3.0非対応機器である非対応クライアント装置３０も再生することが可能となる。
　すなわち、非対応クライアント装置３０は、ATSC3.0に準拠したデータを処理することはできないが、ATSC3.0クライアントアプリケーションとしてのDASHクライアント３１１を搭載することはできる。そして、このDASHクライアント３１１によって、対応クライアント装置２０で得られるDASHセグメントやMPDメタデータのファイルを処理することで、送信システム１０から配信されるコンテンツを再生することが可能となる。
　また、このとき、ATSC3.0クライアントアプリケーションとしてのDASHクライアント２３１やDASHクライアント３１１からすれば、必ず、対応クライアント装置２０のHTTPプロキシサーバ２０２を介して、外部からのデータにアクセスすることになる。なお、LAN７０上の非対応クライアント装置３０からのHTTPリクエストが、すべて、HTTPプロキシサーバ２０２を経由するようにするための設定は、例えば、WPAD(Web Proxy Auto-Discovery Protocol)等を利用して行われる。
　そのため、DASHクライアント２３１やDASHクライアント３１１は、処理対象のファイル群を、放送経由で取得しているのか、あるいは通信経由で取得しているのかの区別を意識する必要がない（ネットワークの透過性が提供される）ため、アプリケーションの可搬性を高めることができる。その結果として、クライアント装置を、放送系受信にのみに特化して実装する必要がなく、また、放送系受信と、通信系受信のどうちらを使うかによらない実装にすることができる。
　ところで、放送の分野では、Usage Reportingとして、コンテンツの視聴履歴を収集して分析するなどの視聴履歴に関する運用が行われる場合がある。例えば、ATSC3.0においても、視聴履歴情報を収集するためのプロトコルが検討途上にある（例えば、非特許文献１参照）。
　非特許文献１：ATSC Candidate Standard : Service Usage Reporting(A/333) Doc. S33-170r316 May 2016
　現状のATSC3.0では、視聴履歴のエンドポイントとなるクライアント装置を、機器IDにより識別して、個々のクライアント装置ごとの視聴履歴をレポートすることになっている。ここで、図２に示した伝送システムの構成のように、ゲートウェイとしての対応クライアント装置２０（ATSC3.0対応機器）に実装されるHTTPプロキシサーバ２０２を介して、LAN７０上の非対応クライアント装置３０（ATSC3.0非対応機器）が、ATSC3.0のプロトコルで伝送されたコンテンツにアクセスする形態が想定される。
　このような構成の場合には、非対応クライアント装置３０（ATSC3.0非対応機器）の視聴履歴についてもレポートすることになるが、対応クライアント装置２０（ATSC3.0対応機器）と、非対応クライアント装置３０（ATSC3.0非対応機器）とを区別して、個々のクライアント装置ごとの視聴履歴をレポートすることは困難であった。そのため、対応クライアント装置２０（ATSC3.0対応機器）と、非対応クライアント装置３０（ATSC3.0非対応機器）とを区別できるようにして、視聴履歴に関する運用を柔軟に行うための提案が要請されていた。
　そこで、本技術では、視聴履歴情報に、コンテンツを再生したクライアント装置が、デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含めることで、当該視聴履歴情報が、対応クライアント装置２０（ATSC3.0対応機器）と、非対応クライアント装置３０（ATSC3.0非対応機器）のいずれのレポートであるのかを識別できるようにする。
　すなわち、本技術においては、例えば、ゲートウェイとしての対応クライアント装置２０（ATSC3.0対応機器）に実装されるHTTPプロキシサーバ２０２に対し、アクセスしてくる非対応クライアント装置３０（ATSC3.0非対応機器）からの再生対象のコンテンツに対するHTTPリクエストのヘッダの中の機器に固有な情報と、HTTPリクエストの送信元のIPアドレスが、視聴履歴情報に含まれるようにする。
　これにより、図２に示した、非対応クライアント装置３０（ATSC3.0非対応機器）が、ATSC3.0のプロトコルで伝送されたコンテンツ（送信システム１０により配信されたコンテンツ）にアクセスする形態であっても、非対応クライアント装置３０（ATSC3.0非対応機器）の視聴履歴を識別することが可能となる。その結果として、視聴履歴に関する運用を柔軟に行うことが可能となる。
　ここで、Usage Reportingとしてレポートされる視聴履歴情報であるが、ATSC3.0では、CDM(Consumption Data Message)の構造からなる。なお、CDMの構造は、上述した非特許文献１の「Table 4.1 CDM Logical Structure」に記載されている。
（CDMの構造例）
　図３は、現状のCDMのフォーマットの例を示す図である。なお、CDMは、テキストフォーマットの一種であるJSON(JavaScript（登録商標） Object Notation)形式で記載される。
　protocolVersionには、CDMのプロトコルのバージョンが指定される。
　DeviceInfoには、機器情報（デバイス情報）が指定される。ここで、現状のCDMでは、DeviceInfoの属性値として、deviceID，deviceModel，deviceManufacturer，deviceOS，peripheralDeviceが規定されている。ここで、図４には、DeviceInfoの属性値の詳細な内容が示されている。DeviceInfoは、各機器に対し、１つだけ記載される。
　deviceIDは、対象の機器の識別子である機器IDが指定される。ただし、この機器IDを意図的に隠す場合には、"NOTREPORTED"が記載される。
　deviceModelは、対象の機器のモデル番号が指定される。ただし、このモデル番号は、ベンダ固有のフォーマットとされる。また、このモデル番号を意図的に隠す場合には、"NOTREPORTED"が記載される。
　deviceManufacturerは、対象の機器のベンダが指定される。ただし、このベンダを意図的に隠す場合には、"NOTREPORTED"が記載される。
　deviceOSは、対象の機器のオペレーティングシステム（OS：Operating System）のバージョンが指定される。このバージョンを意図的に隠す場合には、"NOTREPORTED"が記載される。
　peripheralDeviceは、対象の機器が周辺機器であるかどうかを識別するための情報が指定される。この識別情報を意図的に隠す場合には、"NOTREPORTED"が記載される。
　図３の説明に戻り、AVServiceには、対象の機器で再生されたATSC3.0のサービスのストリームに関する情報が指定される。AVServiceの属性値として、serviceID，serviceType，reportIntervalが規定されている。
　serviceIDには、対象の機器で再生されたサービスのIDが指定される。ただし、このサービスIDは、グローバルでユニークな値とされる。serviceTypeには、サービスIDで識別されるサービスのタイプが指定される。
　reportIntervalの属性値として、startTime，endTime，DestinationDeviceType，contentID，component，AppIntervalが規定されている。また、contentIDの属性値として、type，cidが規定されている。また、componentの属性値として、componentType，componentRole，componentName，componentID，componentLang，startTime，endTime，SourceDeliveryPathが規定され、さらに、SourceDeliveryPathには、属性値として、type，startTime，endTimeが規定されている。また、AppIntervalの属性値として、appId，startTime，endTime，LifeCycle，Tagsが規定されている。
　これらの属性値によって、サービスIDで識別されるサービスごとに、視聴履歴に関する情報を記載することができる。
　ただし、DestinationDeviceTypeとしては、下記の値が規定されており、例えば、"0"が指定された場合には、テレビ受像機により対象のサービスが視聴されたことを表し、"1"が指定された場合には、テレビ受像機以外の機器（例えば、タブレット型コンピュータ等）により対象のサービスが視聴されたことを表している。
0 - Content is presented on a Primary Device
1 - Content is presented on a Companion Device 
2 - Content is sent to a Time-shift-buffer
3 - Content is sent to a Hard-drive
4 to 255 - Reserved.
　また、contentIDのtypeとしては、"EIDR"又は"Ad ID"を指定することができる。"EIDR"は、Entertainment Identifier Registryの略であり、テレビ番組や映画のコンテンツを、グローバルな単一のIDで管理することができる。"Ad ID"は、Advertising IDの略であり、広告用のIDである。
　また、SourceDeliveryPathのtypeとしては、下記の値が規定されており、例えば、"0"が指定された場合には、対象のサービスのコンポーネントが放送経由で配信されたことを表し、"1"が指定された場合には、対象のサービスのコンポーネントが通信経由で配信されたことを表している。
0 - Broadcast delivery (content component is delivered by broadcast)
1 - Broadband delivery (content component is delivered by broadband)
2 - Time-shift-buffer source (content source is local time shift buffer)
3 - Hard-drive source (content source is local hard drive)
4 to 255 - Reserved.
　なお、図３において、Cardinalityの項目は、出現数を表している。例えば、"1"が指定された場合には、その要素又は属性は必ず１つだけ指定される。また、例えば、"0..N"が指定された場合には、その要素又は属性を１以上指定するかどうかは任意であり、"1..N"が指定された場合には、その要素又は属性は１以上指定される。
＜２．システムの構成＞
　次に、図５を参照して、Usage Reportingに対応した伝送システムの構成について説明する。
（本技術の伝送システムの構成例）
　図５は、本技術を適用した伝送システムの一実施の形態の構成を示す図である。
　図５においては、図２と同様に、IP伝送方式の一例として、ATSC3.0に対応した伝送システムの実装モデルを説明する。図５の伝送システムにおいて、図２の伝送システムと対応する部分には、同一の符号が付してあり、その説明は繰り返しになるので、適宜省略するものとする。
　すなわち、図５において、送信システム１０には、視聴履歴情報を収集するUR(Usage Reporting)サーバ１０１が設けられている。また、対応クライアント装置２０には、視聴履歴情報をレポートするための機能（モジュール）として、HTTPプロキシサーバ２０２に、URクライアント２２４及びHTTPリクエストハンドラ２２５が設けられている。
　これらの機能を、送信側の送信システム１０と、受信側の対応クライアント装置２０に追加することで、対応クライアント装置２０のブラウザ２０３（のDASHクライアント２３１）でのコンテンツの再生履歴（視聴履歴）や、非対応クライアント装置３０のブラウザ３０２（のDASHクライアント３１１）でのコンテンツの再生履歴（視聴履歴）を記録して、レポートすることが可能となる。
　対応クライアント装置２０のHTTPプロキシサーバ２０２において、URクライアント２２４は、HTTPリクエストハンドラ２２５からの通知に応じて、本技術のCDMの構造からなる視聴履歴情報を生成するモジュールである。
　HTTPリクエストハンドラ２２５は、ATSC3.0クライアントアプリケーション（DASHクライアント２３１やDASHクライアント３１１）からの要求（HTTPリクエスト）を、最初に受信して解析するモジュールである。
　これにより、URクライアント２２４は、HTTPリクエストハンドラ２２５からの通知に応じて、対応クライアント装置２０のブラウザ２０３（のDASHクライアント２３１）でのコンテンツの再生に応じた視聴履歴情報や、非対応クライアント装置３０のブラウザ３０２（のDASHクライアント３１１）でのコンテンツの再生に応じた視聴履歴情報を生成することになる。
　すなわち、URクライアント２２４は、HTTPリクエストハンドラ２２５を介して、HTTPリクエストのトラフィックを監視することで、対応クライアント装置２０の内部に実装されたDASHクライアント２３１と、対応クライアント装置２０の外部に実装されたDASHクライアント３１１とのコンテンツの再生履歴（視聴履歴）を記録することが可能となる。
　ここで、視聴履歴情報は、本技術のCDMの構造からなる。上述したように、ATSC3.0で規定されたCDMの構造は、機器情報としてのDeviceInfo要素と、その機器で再生されたATSC3.0のサービスのストリームに関するAVService要素を含んでいる。
　本技術では、CDMの構造として、コンテンツを再生したクライアント装置が、ATSC3.0に準拠したデータを処理可能な機器であるかどうかを示す機器情報（non3.0DeviceAttributes）を含めることで、対象の視聴履歴情報（CDM）が、対応クライアント装置２０（ATSC3.0対応機器）と、非対応クライアント装置３０（ATSC3.0非対応機器）のいずれのレポートであるのかを識別できるようにする。
　すなわち、URクライアント２２４は、HTTPプロキシサーバ２０２に対してアクセスしてくる非対応クライアント装置３０（ATSC3.0非対応機器）からの再生対象のコンテンツに対するHTTPリクエストのヘッダの中の機器に固有な情報と、HTTPリクエストの送信元のIPアドレスが、視聴履歴情報（CDM）に含まれるようにする。なお、本技術のCDMの構造からなる視聴履歴情報の詳細な内容は、図６乃至図１２を参照して後述する。
　また、URクライアント２２４は、所定のタイミングで、視聴履歴情報を、通信I/F２０４－１に供給する。通信I/F２０４－１は、URクライアント２２４からの視聴履歴情報を、インターネット６０を介して、URサーバ１０１に送信する。
　なお、URクライアント２２４が視聴履歴情報を送信するタイミングとしては、例えば、あらかじめ定められた間隔で定期的に送信したり、あるいは、送信システム１０から対応クライアント装置２０に送信されるシグナリングや、ビデオやオーディオのウォータマークメッセージに含まれるコメントなどに応じて送信したりすることができる。
　URサーバ１０１は、インターネット６０を介して、対応クライアント装置２０（のURクライアント２２４）から送信されてくる視聴履歴情報を受信する。なお、図５においては、説明の都合上、１台の対応クライアント装置２０のみを図示しているが、実際には、URサーバ１０１では、複数の対応クライアント装置２０（のURクライアント２２４）からの視聴履歴情報が受信され、複数の視聴履歴情報が収集される。
　URサーバ１０１は、収集された視聴履歴情報に対して、視聴履歴の分析や解析などの各種の処理を行う。例えば、URサーバ１０１は、放送局ごとの視聴履歴に関する視聴履歴レポートを生成し、各放送局に提供することができる。
　ここで、本技術のCDMの構造からなる視聴履歴情報には、コンテンツを再生したクライアント装置が、ATSC3.0に準拠したデータを処理可能な機器であるかどうかを示す機器情報（non3.0DeviceAttributes）が含まれている。
　そのため、URサーバ１０１は、対象の視聴履歴情報が、対応クライアント装置２０（ATSC3.0対応機器）と、非対応クライアント装置３０（ATSC3.0非対応機器）のいずれのレポートであるのかを識別して、視聴履歴レポートを生成することができる。つまり、非対応クライアント装置３０（ATSC3.0非対応機器）が、ATSC3.0のプロトコルで伝送されたコンテンツにアクセスする形態であっても、非対応クライアント装置３０（ATSC3.0非対応機器）の視聴履歴を識別することが可能となる。
　なお、図３に示した現状のCDMにおいては、DestinationDeviceTypeにより、テレビ受像機と、テレビ受像機以外の機器のいずれかにより、対象のサービスのコンテンツが再生されたということは分かるが、本技術のCDMのように、対応クライアント装置２０（ATSC3.0対応機器）と、非対応クライアント装置３０（ATSC3.0非対応機器）のいずれかにより、対象のサービスのコンテンツが再生されたということまでは分からない。
　本技術の伝送システムは、以上のように構成される。
＜３．本技術の視聴履歴情報（CDM）＞
　次に、図６乃至図１２を参照して、本技術のCDMの構造からなる視聴履歴情報の詳細について説明する。
（本技術のCDMの構造例）
　図６は、本技術のCDMのフォーマットの例を示す図である。上述したように、CDMは、JSON形式で記載される。
　図６のCDMのフォーマットは、上述のCDMのフォーマット（図３）と比べて、DeviceInfoの属性値として、deviceID，deviceModel，deviceManufacturer，deviceOS，peripheralDeviceのほかに、non3.0DeviceAttributesが追加されている点が異なっている。
　non3.0DeviceAttributesは、ATSC3.0に準拠したデータを処理可能な機器であるかを示す属性である。このnon3.0DeviceAttributesにより、対象のCDMが、対応クライアント装置２０（ATSC3.0対応機器）と、非対応クライアント装置３０（ATSC3.0非対応機器）のいずれのレポートであるのかを識別することが可能となる。
　non3.0DeviceAttributesの属性値としては、"schemeIdUri"と"value"の組を指定することができる。例えば、"schemeIdUri"に対し、HTTPリクエストのユーザエージェント（UserAgent）のヘッダの内容であることを識別するURI(Uniform Resource Identifier)として、"urn:browserUserAgent"である値を定義することで、ユーザエージェントのヘッダに格納されている文字列（情報）を、"value"の値として記載することができる。
　ここで、非対応クライアント装置３０により発行される、放送サービスのDASHセグメントファイルやアプリケーションファイルに対するHTTPリクエストのユーザエージェントのヘッダ（HTTPリクエストヘッダ）には、ユーザエージェントとして、オペレーティングシステム（OS）に関する情報やモバイル端末であるかどうかを示す情報が含まれている。なお、このHTTPリクエストは、HTTPで定義されているメソッドのうち、GETメソッドを利用している。
　例えば、ユーザエージェントとして、"Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)"が得られると、非対応クライアント装置３０が、Windows（登録商標）をオペレーティングシステム（OS）とするパーソナルコンピュータであることが分かる。
　また、例えば、ユーザエージェントとして、"Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"が得られると、非対応クライアント装置３０が、Android（登録商標）をオペレーティングシステム（OS）とするスマートフォンであることが分かる。なお、当該ユーザエージェントにおいて、"Mobile"の記載がないと、タブレット型コンピュータで有ることが分かる。
　また、non3.0DeviceAttributesにおいて、"schemeIdUri"に対し、HTTPリクエストのユーザエージェントのヘッダの内容であることを識別するURI（"urn:browserUserAgent"）のほかに、IPアドレスの内容であることを識別するURIとして、"urn:ipAddress"である値を定義することで、ローカルのIPアドレスを、"value"の値として記載することができる。
　例えば、"value"の値として、"192.168.0.12"が得られると、非対応クライアント装置３０に割り当てられているローカルのIPアドレスが、"192.168.0.12"であることが分かる。
（本技術のCDMの記載例）
　次に、図７及び図８を参照して、本技術のCDMの記載例を説明する。なお、JSON形式のオブジェクトは、キーと値のペアをコロン（：）で対にして、これらの対を、コンマ（，）で区切ってゼロ個以上列挙し、全体を波括弧（｛｝）でくくることで表現される。
（Ａ）CDMの記載例１
　図７は、ATSC3.0非対応機器に固有な情報として、ユーザエージェントに関する情報を含めた場合のCDMの記載例を示す図である。なお、図７においては、説明の簡略化のため、DeviceInfoの属性値と、AVServiceの属性値の一部を抜粋して記載している。
　図７のCDMにおいては、DeviceInfoの属性値として、deviceID，deviceModel，deviceManufacturer，deviceOS，peripheralDevice，non3.0DeviceAttributesが含まれる。
　deviceIDであるキーに対し、"NOTREPORTED"である値がペアになって指定されている。すなわち、機器IDが意図的に隠されていることを表している。
　また、deviceModel，deviceManufacturer，deviceOS，peripheralDeviceに対しても、"NOTREPORTED"である値がそれぞれ指定され、対象の機器のモデル番号、対象の機器の製造元（ベンダ）、対象の機器のオペレーティングシステム（OS）のバージョン、及び対象の機器が周辺機器かどうかを識別するための情報が、意図的に隠されていることを表している。
　non3.0DeviceAttributesの属性値として、"schemeIdUri"と"value"の組が指定されている。ここでは、"schemeIdUri"に対し、HTTPリクエストのユーザエージェントのヘッダの内容であることを識別するURIとして、"urn:browserUserAgent"である値が定義され、ユーザエージェントのヘッダに格納されている文字列（情報）が、"value"の値として記載されている。
　図７の例では、"value"の値として、"Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"と記載されており、非対応クライアント装置３０が、Android（登録商標）をオペレーティングシステム（OS）とするスマートフォンであることを表している。
　AVServiceのreportIntervalにおいて、ContentIDの属性値として、"type"と"cid"の組が指定されている。ここでは、"type"に対し、"EIDR"である値が定義され、EIDRのフォーマットのコンテンツ識別子（CID：Content ID）である"cid"の値として、"10.5240/EA73-79D7-1B2B-B378-3A73-M"が設定されていることを表している。
　Componentの属性値として、"componentType"が指定されている。ここでは、"componentType"に対し、"1"である値が設定され、対象のコンポーネントが、ビデオであることを表している。
　以上のように、図７のCDMの記載例では、non3.0DeviceAttributesの属性値で識別された、Android（登録商標）をオペレーティングシステム（OS）とするスマートフォンとしての非対応クライアント装置３０（ATSC3.0非対応機器）により再生されたコンテンツが、"10.5240/EA73-79D7-1B2B-B378-3A73-M"であるEIDR形式のコンテンツ識別子（CID）を有するビデオのコンテンツであることを表している。
（Ｂ）CDMの記載例２
　図８は、ATSC3.0非対応機器に固有な情報として、ユーザエージェントに関する情報とIPアドレスを含めた場合のCDMの記載例を示す図である。なお、図８においても、説明の簡略化のため、DeviceInfoの属性値と、AVServiceの属性値の一部を抜粋して記載しているが、図７の記載例と対応する部分についてはその説明は省略するものとする。
　図８のCDMにおいては、non3.0DeviceAttributesの属性値として、"schemeIdUri"と"value"の組が指定されているが、ここでは、"schemeIdUri"に対し、HTTPリクエストのユーザエージェントのヘッダの内容であることを識別するURI（"urn:browserUserAgent"）のほかに、IPアドレスの内容であることを識別するURIとして、"urn:ipAddress"である値が定義され、IPアドレスの値が、"value"の値として記載されている。
　図８の例では、"value"の値として、"192.168.0.12"と記載されており、非対応クライアント装置３０に割り当てられているローカルのIPアドレスが、"192.168.0.12"であることを表している。
　以上のように、図８のCDMの記載例では、non3.0DeviceAttributesの属性値で識別された、Android（登録商標）をオペレーティングシステム（OS）とするスマートフォンであって、"192.168.0.12"であるローカルのIPアドレスが割り当てられた非対応クライアント装置３０（ATSC3.0非対応機器）により再生されたコンテンツが、"10.5240/EA73-79D7-1B2B-B378-3A73-M"であるEIDR形式のコンテンツ識別子（CID）を有するビデオのコンテンツであることを表している。
　なお、図７及び図８においては、JSON形式のCDMの記載例を示したが、本技術のCDMの記載形式は、JSON形式に限らず、例えば、XML(Extensible Markup Language)形式など、他のテキスト形式のデータを採用することもできる。
　また、図７及び図８においては、DeviceInfoの属性値（deviceID等）は、必須の値となるため、意図的に隠す場合には、"NOTREPORTED"が記載されるとしたが、DeviceInfoの属性値が任意の値となるようにすることで、意図的に隠す場合に、DeviceInfoの属性値自体の記載を省略することもできる。
（JSONスキーマの例）
　図９乃至図１２は、本技術のCDMのJSONスキーマの例を示す図である。
　図９乃至図１２のJSONスキーマは、図６に示した本技術のCDMのフォーマットに対応している。すなわち、このJSONスキーマは、ATSC3.0で規定されている現状のCDMを拡張した本技術のCDMに対応しており、拡張された部分以外の構造は、現状のCDMのJSONスキーマの構造と同様である。現状のCDMのJSONスキーマの構造は、上述の非特許文献１の「Annex A: Schema」に開示されているため、ここでは、その説明は省略するものとする。
　図９乃至図１２に示したCDMのJSONスキーマのうち、図９の29乃至44の段落には、DeviceInfoの属性値として、non3.0DeviceAttributesが定義されている。ここでは、配列型となるnon3.0DeviceAttributesの属性値として、文字列型の"schemeIdUri"と、文字列型の"value"との組が定義されている。ただし、それらの組において、"schemeIdUri"は、必須の要素とされる。
　このようなCDMのJSONスキーマを定義することで、例えば、"schemeIdUri"に対し、"urn:browserUserAgent"である値を定義することで、HTTPリクエストのユーザエージェントの情報を、"value"の値として記載することができる。また、例えば、"schemeIdUri"に対し、"urn:ipAddress"である値を定義することで、ローカルのIPアドレスを、"value"の値として記載することができる。
＜４．Usage Reporting装置間のプロトコル＞
（UsageReportingプロトコルの例）
　図１３は、図５に示したURサーバ１０１と、対応クライアント装置２０のURクライアント２２４との間のプロトコルの例を示す図である。
　対応クライアント装置２０においては、放送ミドルウェア２０１により、送信システム１０からのLLSが処理され、SLTメタデータが得られるが、このSLTメタデータに、URサーバ１０１のURLが含まれている。そして、通信I/F２０４－１は、SLTメタデータに含まれるURサーバ１０１のURLに従い、インターネット６０を介してURサーバ１０１にアクセスすることができる。なお、SLTメタデータにて周知されるURサーバ１０１のURLの詳細は、図１５及び図１６を参照して後述する。
　ここでは、HTTPプロキシサーバ２０２のURクライアント２２４により生成された視聴履歴情報（CDM）が、インターネット６０を介して、URサーバ１０１に送信される。この視聴履歴情報（CDM）は、HTTPリクエストのPUTメソッドを利用して、ボディ部に格納することができる。
　すなわち、対応クライアント装置２０（URクライアント２２４）から、URサーバ１０１に対しては、図１３に示したCDMメッセージの形式で、視聴履歴情報（CDM）を送信することができるが、このCDMメッセージでは、１行目のリクエスト行に、メソッドを示す「PUT」と、指定されたURLのディレクトリとパス名を示すURIと、HTTPバージョンを示す「HTTP/1.1」が記載される。
　また、CDMメッセージにおいて、２行目乃至４行目のヘッダ部に、指定されたURLのホスト名を示す「Host」と、データの形式が指定される「Content-Type」と、ボディ部の長さが指定される「Content-Length」が記載される。そして、改行を挟んで６行目のボディ部に、JSON形式でエンコードされたCDM構造からなる視聴履歴情報を格納することができる。
　このようなプロトコルに従い、対応クライアント装置２０（URクライアント２２４）から送信されてくる視聴履歴情報（CDM）が、インターネット６０を介してURサーバ１０１により受信され、処理されることになる。なお、URサーバ１０１の詳細な構成は、図１４を参照して後述する。
（URサーバの構成例）
　図１４は、図５のURサーバ１０１の構成例を示す図である。
　URサーバ１０１は、通信I/F１１１、CDM記録部１１２、CDM分析部１１３、及び出力部１１４から構成される。
　通信I/F１１１は、例えば、通信インターフェース回路等から構成され、インターネット６０を介して、対応クライアント装置２０とデータをやりとりする。通信I/F１１１は、インターネット６０を介して、複数の対応クライアント装置２０から送信されてくる視聴履歴情報を受信し、CDM記録部１１２に供給する。
　CDM記録部１１２は、例えば、ハードディスク（HDD：Hard Disk Drive）や半導体メモリ等から構成される。CDM記録部１１２は、通信I/F１１１からの視聴履歴情報を記録する。これにより、複数の対応クライアント装置２０からの視聴履歴情報が収集される。この視聴履歴情報は、図６に示した本技術のCDMの構造からなる。
　CDM分析部１１３は、例えば、CPUやマイクロプロセッサ等から構成される。CDM分析部１１３は、CDM記録部１１２に記録されている視聴履歴情報を読み出し、読み出された視聴履歴情報を分析する。CDM分析部１１３は、視聴履歴情報の分析結果に従い、視聴履歴に関する視聴履歴レポートを生成し、出力部１１４に供給する。
　出力部１１４は、例えば、出力インターフェース回路や、LCD等のディスプレイから構成される。出力部１１４は、CDM分析部１１３からの視聴履歴レポートを、外部の装置に出力する。また、出力部１１４がディスプレイから構成される場合には、当該ディスプレイに、視聴履歴レポートを表示させるようにしてもよい。
　URサーバ１０１は、以上のように構成される。
（SLTメタデータの構造例）
　図１５は、XML形式のSLTメタデータのフォーマットの例を示す図である。なお、図１５において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。
　ただし、SLTメタデータのフォーマットについては、下記の非特許文献２の「Table 6.2 SLT XML Format」にその詳細な内容が記載されている。そのため、図１５のフォーマットの例では、SLTメタデータのうち、特に本技術に関係する部分を抜粋して記載している。
　非特許文献２：ATSC Candidate Standard : Signaling, Delivery, Synchronization,and Error Protection(A/331) Doc. S33-174r15 January 2016
　SLT要素は、ルート要素であって、sltInetUrl要素を含んでいる。sltInetUrl要素には、ブロードキャストストリームIDで識別される周波数帯域（例えば6MHz）ごとに、urlType属性の属性値で指定されるURLタイプに応じたURLを指定することができる。
　ここで、図１６には、urlType属性の属性値の例を示している。
　urlType属性として、"1"が指定された場合、sltInetUrl要素に、SLSを提供するシグナリングサーバのURLが指定されることを表している。また、urlType属性として、"2"が指定された場合、sltInetUrl要素に、電子番組表（ESG：Electronic Service）を提供するESGサーバのURLが指定されることを表している。
　また、urlType属性として、"3"が指定された場合には、sltInetUrl要素に、URサーバ１０１のURLが指定されることを表している。すなわち、図５に示した伝送システムの構成を採用した場合、Usage Reportingとして、コンテンツの視聴履歴に関する運用が行われるので、SLTメタデータのsltInetUrl要素には、URサーバ１０１のURLが記載され、urlType属性として、"3"が指定される。
　図１５の説明に戻り、SLT要素は、１又は複数のService要素を含んでいる。Service要素には、サービス単位で、各サービスに関する情報が指定される。このService要素は、svcInetUrl要素を含んでいる。svcInetUrl要素には、サービスIDで識別されるサービスごとに、urlType属性の属性値で指定されるURLタイプに応じたURLを指定することができる。
　ここで、svcInetUrl要素のurlType属性の属性値についても、図１６に示した属性値が指定される。すなわち、urlType属性として、"3"が指定された場合には、svcInetUrl要素に、URサーバ１０１のURLが指定されることになる。
　このように、URサーバ１０１のURLを、ブロードキャストストリームIDで識別される周波数帯域ごとに指定する場合には、SLT要素の配下のsltInetUrl要素に記載すればよい。また、URサーバ１０１のURLを、サービスIDで識別されるサービスごとに指定する場合には、Service要素の配下のsvcInetUrl要素に記載すればよい。
　なお、図１５において、useの項目は、出現数を表している。例えば、"0..N"が指定された場合には、その要素又は属性を１以上指定するかどうかは任意である。また、例えば、"1"が指定された場合には、その要素又は属性は必ず１つだけ指定され、"1..N"が指定された場合には、その要素又は属性は１以上指定される。
　また、図１５において、Data Typeの項目は、データ形式を表している。例えば、"anyURI"が指定された場合には、そのデータは、URIの形式をした文字列であることを表している。また、例えば、"unsignedByte"が指定された場合には、0から255までの整数であることを表している。
＜５．視聴履歴情報対応処理の流れ＞
　次に、図１７及び図１８のフローチャートを参照して、図５の伝送システムにより実行される視聴履歴情報対応処理の流れを説明する。
　なお、図１７及び図１８において、ステップＳ１０１の処理は、送信システム１０により実行される。また、ステップＳ２０１乃至Ｓ２０６とＳ２２１乃至Ｓ２２５の処理は、対応クライアント装置２０により実行される。また、ステップＳ３０１乃至Ｓ３０２の処理は、非対応クライアント装置３０により実行される。
　図１７のステップＳ３０１において、非対応クライアント装置３０の制御部３００は、通信I/F３０１を制御し、LAN７０を介して、コンテンツのDASHセグメントファイルを、対応クライアント装置２０に要求する。ここでは、例えば、ユーザ操作により、送信システム１０から配信されるテレビ番組等のコンテンツの再生が指示された場合に、非対応クライアント装置３０からのHTTPリクエストが格納されたIPパケットが、対応クライアント装置２０に通知される。
　対応クライアント装置２０においては、非対応クライアント装置３０からのHTTPリクエストが格納されたIPパケットが、通信I/F２０４－２により受信され、HTTPプロキシサーバ２０２のHTTPリクエストハンドラ２２５に供給される。
　ステップＳ２０１において、HTTPリクエストハンドラ２２５は、HTTPリクエストが格納されたIPパケットの送信元アドレス（ソースアドレス）をチェックする。
　ステップＳ２０２において、HTTPリクエストハンドラ２２５は、ステップＳ２０１の送信元アドレスのチェック結果に従い、当該送信元アドレスが、ローカルDASHクライアントからのものであるかどうかを判定する。ここでは、DASHクライアント３１１が搭載された非対応クライアント装置３０に割り当てられたIPアドレスが、送信元アドレスとなるので、当該送信元アドレスが、ローカルDASHクライアントからのものであると判定され（Ｓ２０２の「YES」）、処理は、ステップＳ２０３に進められる。
　なお、ステップＳ２０２の判定処理で、送信元アドレスが、ローカルDASHクライアントからのものではないと判定された場合には、必要な処理が行われた後に、処理は終了される。
　ステップＳ２０３において、HTTPリクエストハンドラ２２５は、ステップＳ２０２の処理で判定対象となった送信元アドレスを、URクライアント２２４に通知する。これにより、HTTPプロキシサーバ２０２においては、HTTPリクエストハンドラ２２５からの送信元アドレスが、URクライアント２２４により受信される。
　ステップＳ２２１において、URクライアント２２４は、非対応クライアント装置３０ごとに管理されているCDM（のDeviceInfo.non3.0DeviceAttributes）に対し、HTTPリクエストハンドラ２２５からの送信元アドレスに応じたIPアドレスを記録する。
　また、ステップＳ２０４において、HTTPリクエストハンドラ２２５は、ステップＳ２０２の処理で判定対象となった送信元アドレスのIPパケットに格納されたHTTPリクエストヘッダから、ユーザエージェント（UserAgent）の文字列を抽出し、URクライアント２２４に通知する。これにより、HTTPプロキシサーバ２０２においては、HTTPリクエストハンドラ２２５からのユーザエージェントの情報が、URクライアント２２４により受信される。
　ステップＳ２２２において、URクライアント２２４は、非対応クライアント装置３０ごとに管理されているCDM（のDeviceInfo.non3.0DeviceAttributes）に対し、HTTPリクエストハンドラ２２５からのユーザエージェントの情報を記録する。このユーザエージェントの情報としては、例えば、オペレーティングシステム（OS）に関する情報やモバイル端末であるかどうかを示す情報が含まれている。
　なお、送信元アドレス（IPアドレス）やユーザエージェントの情報は、同一の内容となる場合には、必ずしも繰り返し取得する必要はなく、取得済みのものを再利用することができる。
　図１８のステップＳ２０５において、HTTPリクエストハンドラ２２５は、送信システム１０から配信されるテレビ番組等のコンテンツのデータであって、放送ミドルウェア２０１の処理で得られるDASHセグメントファイルを、LAN７０を介して、非対応クライアント装置３０に転送する。
　ステップＳ３０２において、非対応クライアント装置３０のDASHクライアント３１１は、対応クライアント装置２０（のHTTPプロキシサーバ２０２のHTTPリクエストハンドラ２２５）から転送されてくるDASHセグメントファイルを再生する。これにより、非対応クライアント装置３０では、送信システム１０から配信されるテレビ番組等のコンテンツが再生され、ユーザにより視聴されることになる。
　ステップＳ２０６において、HTTPリクエストハンドラ２２５は、ステップＳ２０５の処理で非対応クライアント装置３０に転送されたDASHセグメントファイルに対応したセグメントURLを、URクライアント２２４に通知する。これにより、HTTPプロキシサーバ２０２においては、HTTPリクエストハンドラ２２５からのセグメントURLが、URクライアント２２４により受信される。
　ステップＳ２２３において、URクライアント２２４は、非対応クライアント装置３０ごとに管理されているCDM（のAVService）に対し、HTTPリクエストハンドラ２２５からのセグメントURLに対応する情報を記録する。
　ここでは、例えば、MPDメタデータを参照することにより、セグメントURLに対応するコンテンツID（ContentID）を取得できるので、当該コンテンツIDを、CDMのAVService.reportInterval.contentIDに記録することができる。また、ここでは、図６に示したCDMの構造に含まれる情報であれば、コンテンツID以外の情報を記録することもできる。例えば、必要に応じて処理された時間を、CDMのAVService.reportInterval.startTime（endTime）に記録することができる。
　ステップＳ２２４において、制御部２００は、CDMを送信するタイミングであるかどうかを判定する。この判定条件としては、例えば、あらかじめ定められた間隔で定期的に送信するための条件のほか、送信システム１０から対応クライアント装置２０に送信されるシグナリングや、ビデオやオーディオのウォータマークメッセージに含まれるコメントなどに応じた条件などが用いられる。
　ステップＳ２２４において、CDMを送信するタイミングではないと判定された場合、処理は、ステップＳ２２１に戻り、それ以降の処理が繰り返される。すなわち、この場合には、非対応クライアント装置３０からの要求に応じてDASHセグメントファイルが転送されるとともに、その再生履歴（視聴履歴）が記録され続ける。
　一方で、ステップＳ２２４において、CDMを送信するタイミングであると判定された場合、処理は、ステップＳ２２５に進められる。ステップＳ２２５において、URクライアント２２４は、ステップＳ２２１乃至Ｓ２２３の処理で得られるJSON形式にエンコードされたCDMを、視聴履歴情報として、インターネット６０を介してURサーバ１０１に送信する。
　なお、ここでは、通信I/F２０４－１が、SLTメタデータから得られるURサーバ１０１のURLに従い、インターネット６０を介してURサーバ１０１にアクセスすることで、URクライアント２２４からの視聴履歴情報（CDM）が、URサーバ１０１に送信される。
　これにより、URサーバ１０１においては、対応クライアント装置２０からの視聴履歴情報（CDM）が、通信I/F１１１により受信される。なお、URサーバ１０１においては、複数の対応クライアント装置２０から視聴履歴情報が受信され、複数の視聴履歴情報が収集される。
　ステップＳ１０１において、URサーバ１０１のCDM分析部１１３は、収集された視聴履歴情報（CDM）を分析し、視聴履歴に関する視聴履歴レポートを生成する。
　ここで、視聴履歴情報（CDM）には、コンテンツを再生したクライアント装置が、ATSC3.0に準拠したデータを処理可能な機器であるかどうかを示す機器情報（non3.0DeviceAttributes）が含まれている。そのため、CDM分析部１１３は、対象の視聴履歴情報（CDM）が、対応クライアント装置２０（ATSC3.0対応機器）と、非対応クライアント装置３０（ATSC3.0非対応機器）のいずれのレポートであるのかを識別して、視聴履歴レポートを生成することができる。
　以上、視聴履歴情報対応処理の流れを説明した。
＜６．変形例＞
（ATSC3.0対応機器のCDMの記載例）
　上述した説明では、非対応クライアント装置３０が、対応クライアント装置２０を介して、ATSC3.0のプロトコルで伝送されたコンテンツにアクセスする形態において、非対応クライアント装置３０（ATSC3.0非対応機器）の視聴履歴を識別するために、CDMのDeviceInfoの属性値に、non3.0DeviceAttributesを追加して、非対応クライアント装置３０に固有な情報が指定されるようにしている。
　ここでは、対応クライアント装置２０（ATSC3.0対応機器）の視聴履歴を識別するために、CDMのDeviceInfoのnon3.0DeviceAttributesに対し、対応クライアント装置２０に固有な情報が指定されるようにしてもよい。この場合には、対応クライアント装置２０に固有な情報として、HTTPリクエストのユーザエージェントに含まれる情報を含めることができる。
　図１９には、ATSC3.0対応機器に固有な情報として、ユーザエージェントに関する情報を含めた場合のCDMの記載例を示している。図１９においては、non3.0DeviceAttributesの属性値として、"schemeIdUri"と"value"の組が指定されている。
　ここでは、"schemeIdUri"に対し、HTTPリクエストのユーザエージェントのヘッダの内容であることを識別するURIとして、"urn:browserUserAgent"である値が定義され、ユーザエージェントのヘッダに格納されている文字列（情報）が、"value"の値として記載されている。この"value"の値としては、例えば、オペレーティングシステム（OS）に関する情報や、モバイル端末であるかどうかを示す情報などが記載される。
　また、対応クライアント装置２０（ATSC3.0対応機器）において、HTTPプロキシサーバ２０２に対する、ブラウザ２０３のDASHクライアント２３１からのHTTPリクエストには、対応クライアント装置２０に割り当てられたIPアドレスは含まれていない。そのため、対応クライアント装置２０（ATSC3.0対応機器）の視聴履歴情報（CDM）に、IPアドレスを含めないようにすることで、IPアドレスを含めることが可能な非対応クライアント装置３０（ATSC3.0非対応機器）の視聴履歴情報（CDM）（例えば、図８のCDMの記載例）と区別することが可能となる。
（他の放送規格への適用）
　上述した説明としては、デジタル放送の規格として、米国等で採用されている方式であるATSC（特に、ATSC3.0）を説明したが、本技術は、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。また、上述した説明では、IP伝送方式が採用されるATSC3.0を例にして説明したが、IP伝送方式に限らず、例えば、MPEG2-TS(Transport Stream)方式等の他の方式に適用するようにしてもよい。
　また、デジタル放送の規格としては、地上波放送のほか、放送衛星（BS：Broadcasting Satellite)や通信衛星（CS：Communications Satellite）等を利用した衛星放送や、ケーブルテレビ（CATV）等の有線放送などの規格に適用することができる。
（その他の変形例）
　また、上述したシグナリングやパケットなどの名称は、一例であって、他の名称が用いられる場合がある。ただし、これらの名称の違いは、形式的な違いであって、対象のシグナリングやパケットなどの実質的な内容が異なるものではない。例えば、CDMにおいて、ATSC3.0に準拠したデータを処理可能な機器であるかを示す属性として、「non3.0DeviceAttributes」を定義したが、他の名称を用いるようにしてもよい。また、例えば、USBD(User Service Bundle Description)は、USD(User Service Description)と称される場合がある。また、例えば、LCC(Locally Cached Content)は、NRT(Non Real Time)などと称される場合がある。
＜７．コンピュータの構成＞
　上述した一連の処理（図１７及び図１８の視聴履歴情報対応処理）は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図２０は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
　コンピュータ１０００において、CPU(Central Processing Unit)１００１、ROM(Read Only Memory)１００２、RAM(Random Access Memory)１００３は、バス１００４により相互に接続されている。バス１００４には、さらに、入出力インターフェース１００５が接続されている。入出力インターフェース１００５には、入力部１００６、出力部１００７、記録部１００８、通信部１００９、及び、ドライブ１０１０が接続されている。
　入力部１００６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１００７は、ディスプレイ、スピーカなどよりなる。記録部１００８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１００９は、ネットワークインターフェースなどよりなる。ドライブ１０１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブル記録媒体１０１１を駆動する。
　以上のように構成されるコンピュータ１０００では、CPU１００１が、ROM１００２や記録部１００８に記録されているプログラムを、入出力インターフェース１００５及びバス１００４を介して、RAM１００３にロードして実行することにより、上述した一連の処理が行われる。
　コンピュータ１０００（CPU１００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体１０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
　コンピュータ１０００では、プログラムは、リムーバブル記録媒体１０１１をドライブ１０１０に装着することにより、入出力インターフェース１００５を介して、記録部１００８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部１００９で受信し、記録部１００８にインストールすることができる。その他、プログラムは、ROM１００２や記録部１００８に、あらかじめインストールしておくことができる。
　ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
　なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
　また、本技術は、以下のような構成をとることができる。
（１）
　デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報を生成する視聴履歴処理部を備える
　情報処理装置。
（２）
　前記視聴履歴情報は、前記機器情報として、前記デジタル放送の規格に対応した対応機器、又は前記デジタル放送の規格に対応していない非対応機器に固有な情報を含む
　（１）に記載の情報処理装置。
（３）
　前記固有な情報は、HTTP(Hypertext Transfer Protocol)リクエストのユーザエージェントに含まれる情報である
　（２）に記載の情報処理装置。
（４）
　前記固有な情報は、前記HTTPリクエストが、前記非対応機器からのものである場合、IP(Internet Protocol)アドレスをさらに含む
　（３）に記載の情報処理装置。
（５）
　前記ユーザエージェントは、オペレーティングシステム（OS：Operating System）に関する情報と、モバイル端末であるかどうかを示す情報を少なくとも含んでいる
　（３）又は（４）に記載の情報処理装置。
（６）
　前記デジタル放送の放送波を受信する受信部と、
　前記放送波から得られる、前記デジタル放送の規格に準拠したデータを処理するデータ処理部と、
　前記非対応機器から送信されてくるHTTPリクエストに応じて、ネットワークを介して、前記データ処理部からの前記データを、前記非対応機器に送信する通信部と
　をさらに備え、
　前記視聴履歴処理部は、前記非対応機器で再生された前記コンテンツの視聴履歴に対し、前記非対応機器からのHTTPリクエストから得られるユーザエージェントに含まれる情報と、前記非対応機器に割り当てられたIPアドレスを関連付けた前記視聴履歴情報を生成する
　（４）に記載の情報処理装置。
（７）
　前記視聴履歴処理部は、HTTPプロキシサーバのモジュールとして実装される
　（３）乃至（６）のいずれかに記載の情報処理装置。
（８）
　前記対応機器又は前記非対応機器において、前記コンテンツは、ブラウザ上で再生される
　（２）乃至（６）のいずれかに記載の情報処理装置。
（９）
　前記通信部は、前記視聴履歴情報を、ネットワークを介して、前記視聴履歴情報を収集する視聴履歴サーバに送信する
　（６）に記載の情報処理装置。
（１０）
　前記データ処理部からの前記データを再生する再生部をさらに備える
　（６）乃至（９）のいずれかに記載の情報処理装置。
（１１）
　情報処理装置の情報処理方法において、
　前記情報処理装置が、
　デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報を生成するステップを含む
　情報処理方法。
（１２）
　デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報を受信する受信部と、
　複数の機器からの前記視聴履歴情報を収集し、収集された複数の前記視聴履歴情報を、前記機器情報に応じて処理する処理部と
　を備える情報処理装置。
（１３）
　前記視聴履歴情報は、前記機器情報として、前記デジタル放送の規格に対応した対応機器、又は前記デジタル放送の規格に対応していない非対応機器に固有な情報を含む
　（１２）に記載の情報処理装置。
（１４）
　前記固有な情報は、HTTPリクエストのユーザエージェントに含まれる情報である
　（１３）に記載の情報処理装置。
（１５）
　前記固有な情報は、前記HTTPリクエストが、前記非対応機器からのものである場合、IPアドレスをさらに含む
　（１４）に記載の情報処理装置。
（１６）
　前記ユーザエージェントは、オペレーティングシステム（OS）に関する情報と、モバイル端末であるかどうかを示す情報を少なくとも含んでいる
　（１３）又は（１４）に記載の情報処理装置。
（１７）
　情報処理装置の情報処理方法において、
　前記情報処理装置が、
　デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報を受信し、
　複数の機器からの前記視聴履歴情報を収集し、収集された複数の前記視聴履歴情報を、前記機器情報に応じて処理する
　ステップを含む情報処理方法。
　１０　送信システム，　２０　対応クライアント装置，　３０　非対応クライアント装置，　５０　中継局，　６０　インターネット，　７０　LAN，　２００　制御部，　２０１　放送ミドルウェア，　２０２　HTTPプロキシサーバ，　２０３　ブラウザ，　２０４－１，２０４－２　通信I/F，　２１１　PHY・MAC処理部，　２１２　LLSレトリーバ，　２１３　LLSパーサ，　２１４　SLSレトリーバ，　２１５　SLSパーサ，　２１６　セグメントレトリーバ，　２２１　プロキシキャッシュ，　２２２　プロキシキャッシュ，　２２３　放送・通信アドレスリゾルバ，　２３１　DASHクライアント，　２３２　デコーダ，　２３３　レンダラ，　２４１　MPDレトリーバ，　２４２　MPDパーサ，　２４３　セグメントレトリーバ，　２４４　MP4パーサ，　３００　制御部，　３０１　通信I/F，　３０２　ブラウザ，　３１１　DASHクライアント，　３１２　デコーダ，　３１３　レンダラ，　３２１　MPDレトリーバ，　３２２　MPDパーサ，　３２３　セグメントレトリーバ，　３２４　MP4パーサ，　１０００　コンピュータ，　１００１　CPU

Claims (17)

  1. 　デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報を生成する視聴履歴処理部を備える
    　情報処理装置。
  2. 　前記視聴履歴情報は、前記機器情報として、前記デジタル放送の規格に対応した対応機器、又は前記デジタル放送の規格に対応していない非対応機器に固有な情報を含む
    　請求項１に記載の情報処理装置。
  3. 　前記固有な情報は、HTTP(Hypertext Transfer Protocol)リクエストのユーザエージェントに含まれる情報である
    　請求項２に記載の情報処理装置。
  4. 　前記固有な情報は、前記HTTPリクエストが、前記非対応機器からのものである場合、IP(Internet Protocol)アドレスをさらに含む
    　請求項３に記載の情報処理装置。
  5. 　前記ユーザエージェントは、オペレーティングシステム（OS：Operating System）に関する情報と、モバイル端末であるかどうかを示す情報を少なくとも含んでいる
    　請求項３に記載の情報処理装置。
  6. 　前記デジタル放送の放送波を受信する受信部と、
    　前記放送波から得られる、前記デジタル放送の規格に準拠したデータを処理するデータ処理部と、
    　前記非対応機器から送信されてくるHTTPリクエストに応じて、ネットワークを介して、前記データ処理部からの前記データを、前記非対応機器に送信する通信部と
    　をさらに備え、
    　前記視聴履歴処理部は、前記非対応機器で再生された前記コンテンツの視聴履歴に対し、前記非対応機器からのHTTPリクエストから得られるユーザエージェントに含まれる情報と、前記非対応機器に割り当てられたIPアドレスを関連付けた前記視聴履歴情報を生成する
    　請求項４に記載の情報処理装置。
  7. 　前記視聴履歴処理部は、HTTPプロキシサーバのモジュールとして実装される
    　請求項６に記載の情報処理装置。
  8. 　前記対応機器又は前記非対応機器において、前記コンテンツは、ブラウザ上で再生される
    　請求項６に記載の情報処理装置。
  9. 　前記通信部は、前記視聴履歴情報を、ネットワークを介して、前記視聴履歴情報を収集する視聴履歴サーバに送信する
    　請求項６に記載の情報処理装置。
  10. 　前記データ処理部からの前記データを再生する再生部をさらに備える
    　請求項６に記載の情報処理装置。
  11. 　情報処理装置の情報処理方法において、
    　前記情報処理装置が、
    　デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報を生成するステップを含む
    　情報処理方法。
  12. 　デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報を受信する受信部と、
    　複数の機器からの前記視聴履歴情報を収集し、収集された複数の前記視聴履歴情報を、前記機器情報に応じて処理する処理部と
    　を備える情報処理装置。
  13. 　前記視聴履歴情報は、前記機器情報として、前記デジタル放送の規格に対応した対応機器、又は前記デジタル放送の規格に対応していない非対応機器に固有な情報を含む
    　請求項１２に記載の情報処理装置。
  14. 　前記固有な情報は、HTTPリクエストのユーザエージェントに含まれる情報である
    　請求項１３に記載の情報処理装置。
  15. 　前記固有な情報は、前記HTTPリクエストが、前記非対応機器からのものである場合、IPアドレスをさらに含む
    　請求項１４に記載の情報処理装置。
  16. 　前記ユーザエージェントは、オペレーティングシステム（OS）に関する情報と、モバイル端末であるかどうかを示す情報を少なくとも含んでいる
    　請求項１４に記載の情報処理装置。
  17. 　情報処理装置の情報処理方法において、
    　前記情報処理装置が、
    　デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報を受信し、
    　複数の機器からの前記視聴履歴情報を収集し、収集された複数の前記視聴履歴情報を、前記機器情報に応じて処理する
    　ステップを含む情報処理方法。
PCT/JP2017/024103 2016-07-15 2017-06-30 情報処理装置、及び、情報処理方法 WO2018012315A1 (ja)

Priority Applications (7)

Application Number Priority Date Filing Date Title
BR112019000345-2A BR112019000345A2 (pt) 2016-07-15 2017-06-30 aparelho e método de processamento de informação
JP2018527514A JPWO2018012315A1 (ja) 2016-07-15 2017-06-30 情報処理装置、及び、情報処理方法
CA3029413A CA3029413A1 (en) 2016-07-15 2017-06-30 Information processing apparatus and information processing method
MX2018016225A MX2018016225A (es) 2016-07-15 2017-06-30 Aparato de procesamiento de informacion y metodo de procesamiento de informacion.
KR1020197000156A KR20190029572A (ko) 2016-07-15 2017-06-30 정보 처리 장치 및 정보 처리 방법
US16/306,993 US20200053406A1 (en) 2016-07-15 2017-06-30 Information processing apparatus and information processing method
EP17827445.2A EP3487182A4 (en) 2016-07-15 2017-06-30 INFORMATION PROCESSING APPARATUS AND INFORMATION PROCESSING METHOD

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016-140379 2016-07-15
JP2016140379 2016-07-15

Publications (1)

Publication Number Publication Date
WO2018012315A1 true WO2018012315A1 (ja) 2018-01-18

Family

ID=60952416

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/024103 WO2018012315A1 (ja) 2016-07-15 2017-06-30 情報処理装置、及び、情報処理方法

Country Status (8)

Country Link
US (1) US20200053406A1 (ja)
EP (1) EP3487182A4 (ja)
JP (1) JPWO2018012315A1 (ja)
KR (1) KR20190029572A (ja)
BR (1) BR112019000345A2 (ja)
CA (1) CA3029413A1 (ja)
MX (1) MX2018016225A (ja)
WO (1) WO2018012315A1 (ja)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070143776A1 (en) * 2005-03-01 2007-06-21 Russ Samuel H Viewer data collection in a multi-room network
JP5110661B2 (ja) 2009-07-27 2012-12-26 ソニー株式会社 受信装置および受信方法
US9203813B2 (en) * 2013-03-15 2015-12-01 Panasonic Intellectual Property Management Co., Ltd. Content distribution method, content distribution system, source device, and sink device

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"ATSC Candidate Standard: Service Usage Reporting (A/333)", ADVANCED TELEVISION SYSTEMS COMMITTEE (ATSC), S 33-170 R3, 16 May 2016 (2016-05-16), pages 1 - 16, XP055510699, Retrieved from the Internet <URL:http://www.atsc.org/wp-content/uploads/2016/05/A333S33-170r3-CS-Service-Usage-Reporting.pdf> [retrieved on 20170915] *

Also Published As

Publication number Publication date
CA3029413A1 (en) 2018-01-18
US20200053406A1 (en) 2020-02-13
BR112019000345A2 (pt) 2019-04-16
EP3487182A1 (en) 2019-05-22
JPWO2018012315A1 (ja) 2019-05-16
EP3487182A4 (en) 2019-05-22
KR20190029572A (ko) 2019-03-20
MX2018016225A (es) 2019-05-30

Similar Documents

Publication Publication Date Title
CN108293148B (zh) 接收装置、发送装置以及数据处理方法
JP7070630B2 (ja) 受信方法、及び、送信方法
US20100313235A1 (en) Providing syndication feed content on a television set-top box with limited decoder capability
US20200336526A1 (en) Reception device, reception method, transmission device, and transmission method for distributing signaling information
KR102499231B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
KR102496890B1 (ko) 정보 처리 장치, 클라이언트 장치, 및 데이터 처리 방법
WO2018079295A1 (ja) 情報処理装置、及び、情報処理方法
KR102533674B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
WO2018012315A1 (ja) 情報処理装置、及び、情報処理方法
US11159860B2 (en) Receiving device and receiving method, reproducing device and reproducing method, supply device and supply method, and program
US20110265138A1 (en) Method and apparatus for transmitting and receiving service discovery information in multimedia transmission system and file structure for the same
KR102600762B1 (ko) Atsc 3.0 기반의 방송 콘텐츠 전송 장치 및 방법과, 방송 콘텐츠 수신 장치 및 방법
WO2017212932A1 (ja) 受信装置、送信装置、及び、データ処理方法

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2018527514

Country of ref document: JP

Kind code of ref document: A

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17827445

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 3029413

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 20197000156

Country of ref document: KR

Kind code of ref document: A

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112019000345

Country of ref document: BR

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017827445

Country of ref document: EP

Effective date: 20190215

ENP Entry into the national phase

Ref document number: 112019000345

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20190108