WO2018034172A1 - 情報処理装置、クライアント装置、及び、データ処理方法 - Google Patents

情報処理装置、クライアント装置、及び、データ処理方法 Download PDF

Info

Publication number
WO2018034172A1
WO2018034172A1 PCT/JP2017/028338 JP2017028338W WO2018034172A1 WO 2018034172 A1 WO2018034172 A1 WO 2018034172A1 JP 2017028338 W JP2017028338 W JP 2017028338W WO 2018034172 A1 WO2018034172 A1 WO 2018034172A1
Authority
WO
WIPO (PCT)
Prior art keywords
proxy
request
information
content
client device
Prior art date
Application number
PCT/JP2017/028338
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 CA3033735A priority Critical patent/CA3033735A1/en
Priority to MX2019001568A priority patent/MX2019001568A/es
Priority to KR1020197003080A priority patent/KR102496890B1/ko
Priority to US16/319,558 priority patent/US20210288735A1/en
Priority to EP17841397.7A priority patent/EP3503568A4/en
Priority to JP2018534344A priority patent/JPWO2018034172A1/ja
Priority to BR112019002867-6A priority patent/BR112019002867A2/pt
Publication of WO2018034172A1 publication Critical patent/WO2018034172A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614—Multiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/35—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users
    • H04H60/37—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users for identifying segments of broadcast information, e.g. scenes or extracting programme ID
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/29—Arrangements for monitoring broadcast services or broadcast-related services
    • H04H60/31—Arrangements for monitoring the use made of the broadcast services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/25—Arrangements for updating broadcast information or broadcast-related information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/35—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/76—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet
    • H04H60/81—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself
    • H04H60/82—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself the transmission system being the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2517—Translation of Internet protocol [IP] addresses using port numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/43615—Interfacing a Home Network, e.g. for connecting the client to a plurality of peripherals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4363—Adapting the video stream to a specific local network, e.g. a Bluetooth® network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/437—Interfacing the upstream path of the transmission network, e.g. for transmitting client requests to a VOD server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6112—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving terrestrial transmission, e.g. DVB-T
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6156—Network physical structure; Signal processing specially adapted to the upstream path of the transmission network
    • H04N21/6175—Network physical structure; Signal processing specially adapted to the upstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6156—Network physical structure; Signal processing specially adapted to the upstream path of the transmission network
    • H04N21/6181—Network physical structure; Signal processing specially adapted to the upstream path of the transmission network involving transmission via a mobile phone network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835—Generation of protective data, e.g. certificates
    • H04N21/8352—Generation of protective data, e.g. certificates involving content or source identification data, e.g. Unique Material Identifier [UMID]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Definitions

  • the present technology relates to an information processing apparatus, a client apparatus, and a data processing method, and in particular, an information processing apparatus, a client apparatus, and an information processing apparatus that are capable of operating a service using broadcasting and communication more flexibly.
  • the present invention relates to a data processing method.
  • Patent Document 1 In recent years, techniques related to services using communication as well as broadcasting have been proposed for the purpose of enhancing broadcasting services (see, for example, Patent Document 1).
  • the present technology has been made in view of such a situation, and is capable of operating a service using broadcasting and communication more flexibly.
  • the information processing apparatus is an information processing apparatus including a processing unit that inserts identification information for identifying the identity of the content source in response to a content request.
  • the information processing apparatus may be an independent apparatus or may be an internal block constituting one apparatus.
  • the data processing method according to the first aspect of the present technology is a data processing method corresponding to the information processing apparatus according to the first aspect of the present technology described above.
  • connection with a gateway device that transfers content distributed via broadcasting or communication is processed, and is transmitted from the gateway device via a network.
  • the transferred content is reproduced.
  • the gateway device has a function as a proxy, and the proxy is provided from the gateway device via the network based on connection information regarding an IP address and a port number on which the proxy waits for a request.
  • a connection with is established.
  • the gateway device 10 receives the broadcast wave transmitted from the broadcast server 40 via the transmitting station 50, and transmits the content data obtained from the broadcast wave to the client devices 20-1 to 20- connected to the network 30. Send (transfer) to N.
  • the gateway device 10 receives data of content transmitted from the communication server 70 via the Internet 80, and transmits (transfers) it to the client devices 20-1 to 20-N connected to the network 30.
  • gateway device 10 The detailed configuration of the gateway device 10 will be described later with reference to FIG.
  • the client devices 20-2 to 20-N are composed of fixed receivers or mobile receivers used in the home, and via the gateway device 10 via broadcast or communication. Receive and play distributed content.
  • the client devices 20-1 to 20-N are simply referred to as the client device 20 when it is not necessary to distinguish them.
  • the detailed configuration of the client device 20 will be described later with reference to FIG.
  • the communication server 70 is a server provided by, for example, a broadcaster such as a broadcasting station or other operators, and is connected to the Internet 80.
  • the gateway device 10 and the client device 20 are arranged in the end user home 2 in the transmission system of FIG. 1, the case where the gateway device 10 and the client device 20 are arranged in the end user home 2 has been described.
  • the gateway device 10 is not limited to the end user home 2, for example, a cable It may be installed in an operator's head end, a mobile network base station, or the like so that a wider area can be covered.
  • the processing unit 100 includes, for example, a CPU (Central Processing Unit) and a microprocessor.
  • the processing unit 100 performs various kinds of arithmetic processing and processing such as operation control of each unit.
  • the storage unit 104 includes, for example, a semiconductor memory or a hard disk drive (HDD: Hard Disk Drive).
  • the storage unit 104 stores various data according to control from the processing unit 100.
  • the UPnP / SSDP server 111 and the proxy application manager 112 are services that operate on the gateway device 10 and perform processing for establishing a connection between the client device 20 connected to the network 30 and the local proxy 113.
  • the UPnP / SSDP server 111 can have the function of a web server (local web server).
  • the local proxy 113 is a service that operates on the gateway device 10, and transmits a request from the client device 20 connected to the network 30 to the communication server 70 connected to the Internet 80.
  • the local proxy 113 receives a content stream from the communication server 70 via the Internet 80 and transmits (transfers) the content stream to the client device 20 connected to the network 30.
  • the local proxy 113 performs an extension header insertion process on the request from the client device 20, and details of the process will be described later with reference to FIGS. 17, 18, and 27.
  • the SLS processing system 114 performs processing related to SLS (Service Layer Signaling), which is control information acquired via broadcast or communication. Details of the SLS will be described later with reference to FIG. Details of processing performed in the SLS processing system 114 will be described later with reference to FIG.
  • SLS Service Layer Signaling
  • the gateway device 10 is configured as described above.
  • the processing unit 200 includes, for example, a CPU, a microprocessor, and the like.
  • the processing unit 200 performs various types of arithmetic processing and processing such as operation control of each unit.
  • the communication I / F 201 requests distribution of content to the gateway device 10 connected to the network 30 according to control from the processing unit 200. Also, the communication I / F 201 receives content data transmitted (transferred) from the gateway device 10 via the network 30 and supplies the content data to the processing unit 200.
  • the processing unit 200 processes content data supplied from the communication I / F 201, supplies video data to the display unit 202 among the data obtained as a result, and supplies audio data to the speaker 203.
  • the display unit 202 includes a display such as an LCD (Liquid Crystal Display) or an OELD (Organic Electroluminescence Display).
  • the display unit 202 displays a video corresponding to the video data supplied from the processing unit 200.
  • the speaker 203 outputs sound corresponding to the audio data supplied from the processing unit 200.
  • an operation signal according to an end user operation on the touch panel is supplied to the processing unit 200, and the processing unit 200 responds to the operation signal.
  • an input unit such as a physical button is provided so that an operation signal corresponding to an end user operation on the input unit is supplied to the processing unit 200. Good.
  • the processing unit 200 includes an application 211 and a browser 212.
  • a renderer function is provided by the application 211 and the browser 212.
  • the application 211 performs processing for the client device 20 connected to the network 30 to establish a connection with the local proxy 113 operating in the gateway device 10. Details of processing performed by the application 211 will be described later with reference to FIGS. 17 and 18.
  • the browser 212 processes content data supplied from the communication I / F 201 and received by the gateway device 10 via broadcast or communication, and reproduces the content.
  • the browser 212 has a function as a DASH player, and details thereof will be described later with reference to FIG. Details of processing performed by the browser 212 will be described later with reference to FIGS. 17, 18, and 27.
  • the client device 20 is configured as described above.
  • the gateway apparatus 10 plays a role for transferring the data distributed from the server on the transmission side to the client apparatus 20 on the reception side via broadcasting or communication.
  • the gateway apparatus 10 plays a role for transferring the data distributed from the server on the transmission side to the client apparatus 20 on the reception side via broadcasting or communication.
  • the client device 20-1 among the plurality of client devices 20 connected to the network 30 has the same functions as the gateway device 10 such as a tuner and a communication I / F. Assume that the content data distributed via broadcast and communication can be received.
  • the client devices 20-2 to 20-N can receive content data distributed via broadcast or communication via the client device 20-1 operating as a gateway.
  • the client devices 20-2 to 20-N may be connected to the gateway device 10 to receive content data distributed via broadcast or communication.
  • the gateway device 10 includes a UPnP / SSDP server 111, a proxy application manager 112, a local proxy 113, and an SLS processing system 114 as the processing unit 100 together with the tuner 101 as shown in the configuration of FIG. It is comprised including.
  • FIG. 4 there are two types of client devices 20, a general client device 20 having only a renderer function and an all-in-one client device 20 having not only a renderer function but also a gateway function. is there.
  • the general client device (NC) 20 receives data via broadcast or communication via the gateway device (GW) 10 or the all-in-one client device (AOC) 20. That is, the gateway device (GW) 10 can provide a gateway function to the general client device (NC) 20.
  • the all-in-one client device (AOC) 20 can provide a gateway function to the general client device (NC) 20.
  • the all-in-one client device (AOC) 20 can also function as a general client device (NC) 20 upon receiving a gateway function from the gateway device (GW) 10, but normally uses its own gateway function. To receive data via broadcast or communication.
  • NC general client device
  • GW gateway device
  • the gateway device (GW) 10 functions as a gateway, and transmits data distributed from the transmitting server via broadcast or communication to the general client device (NC) 20 or the all-in-one client device (AOC) 20. Further, the gateway device (GW) 10 performs an extension header insertion process on the request from the general client device (NC) 20 or the all-in-one client device (AOC) 20, and transmits the request obtained as a result via communication. .
  • the all-in-one client device (AOC) 20 functions as a gateway and processes the data distributed from the transmitting server via broadcast or communication by itself or transmits it to the general client device (NC) 20. Further, the all-in-one client device (AOC) 20 performs an extension header insertion process on a request processed by itself or a request from the general client device (NC) 20, and transmits a request obtained as a result via communication. .
  • data transmitted via broadcast and communication may be processed by the same device.
  • the device that processes data via the communication may be different from the device that processes data via communication.
  • the gateway device (GW) 10 can process data via broadcasting for the general client device (NC) 20 and the all-in-one client device (AOC) 20 can process data via communication.
  • FIG. 6 is a diagram illustrating an example of a protocol stack of the IP transmission scheme of the present technology.
  • ATSC Advanced Television Systems Committee
  • IP transmission method can be adopted as in ATSC 3.0 and the like.
  • the lowest hierarchy is a physical layer.
  • IP transmission system such as ATSC3.0
  • the physical layer corresponds to the frequency band of the broadcast wave allocated for the service (channel).
  • LLS Low Level Signaling
  • SLS Service Layer Signaling
  • the LLS includes metadata such as SLT (Service List).
  • the 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. However, a UDP / IP packet storing SLT metadata is transmitted with a special IP address and port number.
  • ROUTE Real-time Object Delivery Service Unidirectional Transport
  • FLUTE FLUTE
  • 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.
  • the MPEG-DASH standard defines a manifest file for describing metadata, which is control information for 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 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. That is, this media segment corresponds to a DASH segment (DASH segment file).
  • stream data of service components (video, audio, subtitles, etc.) constituting content such as a program is transmitted by a ROUTE session in units of DASH segments conforming to the ISO BMFF standard.
  • NRT content is stored once in the receiver storage and then played.
  • files other than NRT content for example, files of applications and electronic service guides (ESG: Electronic Service Guide)
  • ESG Electronic Service Guide
  • SLT metadata as LLS and metadata such as USBD, S-TSID, and MPD as SLS should be text data described in a markup language such as XML (Extensible Markup Language). Can do.
  • DASH DASH segments
  • VOD Video On Demand
  • the Period element, AdaptationSet element, and Representation element are described in a hierarchical structure.
  • the attributes such as the respective rates are described by dividing them into Representation elements.
  • the Representation element is divided into a plurality of segments (Segment) on the time axis.
  • the client device 20 parses MPD metadata transmitted as SLS, and refers to the value of the rate specified in the stream described in the Representation element, so that it is optimal for the network environment in which the client device 20 is located. You can select the right stream.
  • the segment file described in MPD metadata is specified by URL (byte range).
  • the segment is a part of the Representation element, and one Representation element is configured by one of the following.
  • FIG. 9 is a diagram showing an example of MPD metadata when using the segment base (SegmentBase).
  • the segment base is used when there is only one media segment (segment) in one Representation element.
  • the byte sequence of initialization information and the byte sequence of RAP are within the first 834 bytes of the file.
  • the 834 bytes are described by the indexRange attribute of the SegmentBase element.
  • the communication server 70 as a CDN server, when the content data (DASH segment file) is distributed by the communication server 70, the existing CDN logging function is used. Then, the operation of recording the access statistics of the DASH segment becomes possible. Here, additional costs can be minimized by using the existing CDN functions.
  • FIG. 13 shows a description example of the extension header in the case of the ATSC 3.0 service as an example of the extension of the HTTP request header.
  • FIG. 14 shows an example of description of USB-format metadata and MPD metadata in XML format. Information obtained from these metadata is used as attribute related to delivery of the ATSC 3.0 service, and the source identification information Can be included.
  • the service ID (global service ID) is obtained from the value of the globalServiceID attribute of the userServiceDescription element
  • the MPD metadata URL is obtained from the value of the fullMPDUri attribute of the userServiceDescription element.
  • a content ID corresponding to EIDR is obtained from the value of the AssetIdentifier element of the Period element.
  • the attribute of the content of the DASH segment file added as the extension header includes source identification information obtained by referring to the mapping database using the segment URL as a primary key. Specifically, source identification information such as a service ID, content ID, MPD metadata URL, and time information is added as an extension header.
  • automatic setting methods include a method using a DHCP (Dynamic Host Configuration Protocol) server and a method using a WPAD (Web Proxy Auto Discovery).
  • automatic setting using a proxy setting script prepares a proxy automatic configuration script file written in a script language such as JavaScript (registered trademark) and places the file on the web server, while changing the URL of the file.
  • the URL of the script for automatic setting of the browser 212 may be set.
  • the same method can also be used for discovery of the gateway device 10 (its local proxy 113).
  • the local proxy 113 enables the local proxy 113 to mediate (intercept) all sessions including a secure end-to-end transport session using the HTTPS protocol.
  • a proxy is called a transparent proxy (transparent proxy) as described above.
  • the client device 20 finds the gateway device 10 that is a server on which the local proxy 113 is operating in the network 30, and the IP address and port number on which the local proxy 113 waits for a request (hereinafter, proxy standby address).
  • proxy standby address the IP address and port number on which the local proxy 113 waits for a request.
  • the client device 20 needs to recognize the Web API (Application Programming Interface) for inquiring the proxy proxy address / port to the local proxy 113.
  • this Web API is an interface for calling services.
  • SSDP an XML format file that describes functions and information that can be provided by a device is used as a device description that is exchanged when discovering a public service.
  • this file a device description describing the target device itself and a service description as an action of each service installed on the target device are described.
  • the description of the local proxy 113 can describe the URL of the Web API that returns the IP address and port number (proxy standby address / port) at which the local proxy 113 waits for a request. To do.
  • a proxy standby address / port can be set.
  • the discovery of the local proxy 113 operating in the gateway device 10 and the proxy standby address / port acquisition sequence (proxy discovery / connection processing) of the local proxy 113 are described in the extension of the HTTP request header described above. This will be described together with the sequence (extension header insertion processing).
  • FIG. 19 is a diagram illustrating an example of an M-SEARCH request.
  • FIG. 20 is a diagram illustrating an example of an M-SEARCH response.
  • the device description request transmitted by the client apparatus 20 is received by the gateway apparatus 10 connected to the network 30 in the process of step S202.
  • 22 and 23 are diagrams showing examples of device description responses.
  • serviceList element a list of services supported by the gateway device 10 is described.
  • serviceList element one or a plurality of service elements are described.
  • the local proxy 113 since the local proxy 113 has a function as a proxy server in the gateway device 10, “192.168.1.1”, which is the IP address assigned to the gateway device 10, is included in the body part of the response. “34567” which is the port number assigned to the proxy 113 is described.
  • step S204 of FIG. 18 the application 211 updates the proxy automatic configuration script and starts (restarts) the browser 212 based on the proxy standby address / port response (IP address and port number) received from the gateway device 10. ) To reflect the configuration change.
  • step S122 the local proxy 113 transmits the HTTP request obtained in the process of step S121 (extension header insertion process) to the communication server 70 connected to the Internet 80 via the communication I / F 102.
  • step S212 the browser 212 processes the DASH segment file received from the gateway device 10, and reproduces the DASH segment file by the DASH player.
  • the client device 20 reproduces content such as a program distributed via communication.
  • step S154 the SLS processing system 114 refers to the mapping database stored in the storage unit 104 in response to the inquiry by the URL of the HTTP request header from the local proxy 113, and attributes (sources) corresponding to the URL of the HTTP request. (Identification information) is returned.
  • the communication server 70 receives an HTTP request transmitted from the gateway device 10 via the Internet 80. Then, the communication server 70 transmits a DASH segment file corresponding to the received HTTP request to the gateway device 10 via the Internet 80.
  • names such as the above-described control information (signaling) are examples, and other names may be used. However, the difference between these names is a formal difference and does not differ from the substantial contents of the target control information and packets.
  • USBD User Service Bundle Description
  • USD User Service Description
  • NRT Non Real Time
  • LCC Long Cellally Cached Content
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本技術は、より柔軟に、放送と通信を利用したサービスの運用を行うことができるようにする情報処理装置、クライアント装置、及び、データ処理方法に関する。 情報処理装置が、コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入することで、より柔軟に、放送と通信を利用したサービスの運用を行うことができるようになる。本技術は、例えば、家庭内LAN等のネットワークに接続されるゲートウェイ装置や、コンテンツを再生可能なクライアント装置に適用することができる。

Description

情報処理装置、クライアント装置、及び、データ処理方法
　本技術は、情報処理装置、クライアント装置、及び、データ処理方法に関し、特に、より柔軟に、放送と通信を利用したサービスの運用を行うことができるようにした情報処理装置、クライアント装置、及び、データ処理方法に関する。
　近年、放送サービスを高度化する目的で、放送だけでなく、通信を利用したサービスに関する技術が提案されている（例えば、特許文献１参照）。
特開2013-150089号公報
　ところで、放送と通信を利用したサービスの運用を行うに際して、インターネット上の通信サーバに対し、放送サービスをサービスエントリとしてアクセスしてくるデバイスと、一般のインターネットサイトをサービスエントリとしてアクセスするデバイスとが存在する場合が想定される。
　そのような場合において、放送事業者等の事業者からは、それらのデバイスを区別して、アクセスの統計を管理する運用などを行いたいという要請があるが、現状では、そのような要請に応えるための技術方式は確立されていない。
　本技術はこのような状況に鑑みてなされたものであり、より柔軟に、放送と通信を利用したサービスの運用を行うことができるようにするものである。
　本技術の第１の側面の情報処理装置は、コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入する処理部を備える情報処理装置である。
　本技術の第１の側面の情報処理装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面のデータ処理方法は、上述した本技術の第１の側面の情報処理装置に対応するデータ処理方法である。
　本技術の第１の側面の情報処理装置、及び、データ処理方法においては、コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報が挿入される。
　本技術の第２の側面のクライアント装置は、放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置との接続を処理する処理部と、前記ゲートウェイ装置から、ネットワークを介して転送されてくる前記コンテンツを再生する再生部とを備え、前記ゲートウェイ装置は、プロキシとしての機能を有し、前記処理部は、前記ゲートウェイ装置から前記ネットワークを介して提供される、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報に基づいて、前記プロキシとの接続を確立するクライアント装置である。
　本技術の第２の側面のクライアント装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面のデータ処理方法は、上述した本技術の第２の側面のクライアント装置に対応するデータ処理方法である。
　本技術の第２の側面のクライアント装置、及び、データ処理方法においては、放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置との接続が処理され、前記ゲートウェイ装置から、ネットワークを介して転送されてくる前記コンテンツが再生される。また、前記ゲートウェイ装置が、プロキシとしての機能を有しており、前記ゲートウェイ装置から前記ネットワークを介して提供される、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報に基づいて、前記プロキシとの接続が確立される。
　本技術の第１の側面、及び、第２の側面によれば、より柔軟に、放送と通信を利用したサービスの運用を行うことができる。
　なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
本技術を適用した伝送システムの一実施の形態の構成を示す図である。 ゲートウェイ装置の構成例を示す図である。 クライアント装置の構成例を示す図である。 受信側の装置の実装例を説明する図である。 受信側の装置の実装例を説明する図である。 本技術のIP伝送方式のプロトコルスタックの例を示す図である。 MPDメタデータの詳細を説明する図である。 MPDメタデータの詳細を説明する図である。 セグメントベースを利用する場合のMPDメタデータの例を示す図である。 セグメントリストを利用する場合のMPDメタデータの例を示す図である。 セグメントテンプレートを利用する場合のMPDメタデータの例を示す図である。 MPDメタデータの例を示す図である。 本技術の拡張ヘッダの例を示す図である。 拡張ヘッダとして挿入される識別情報の例を示す図である。 HTTPリクエストの例を示す図である。 拡張ヘッダが挿入されたHTTPリクエストの例を示す図である。 プロキシの発見・接続処理と、拡張ヘッダ挿入処理の一連の流れを説明するフローチャートである。 プロキシの発見・接続処理と、拡張ヘッダ挿入処理の一連の流れを説明するフローチャートである。 M-SEARCHリクエストの例を示す図である。 M-SEARCHレスポンスの例を示す図である。 デバイスディスクリプションリクエストの例を示す図である。 デバイスディスクリプションレスポンスの例を示す図である。 デバイスディスクリプションの例を示す図である。 プロキシ待ち受けアドレス/ポートリクエストの例を示す図である。 プロキシ待ち受けアドレス/ポートレスポンスの例を示す図である。 プロキシ自動構成スクリプトファイルの例を示す図である。 拡張ヘッダ挿入処理の詳細を説明するフローチャートである。 通信サーバ側のHTTPリクエスト対応処理の流れを説明するフローチャートである。 コンピュータの構成例を示す図である。
　以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
１．システムの構成
２．本技術の概要
３．HTTPリクエストヘッダの拡張方法
４．トランスペアレントプロキシの発見・接続方法
５．プロキシの発見・接続処理と、拡張ヘッダ挿入処理の流れ
６．変形例
７．コンピュータの構成
＜１．システムの構成＞
（伝送システムの構成例）
　図１は、本技術を適用した伝送システムの一実施の形態の構成を示す図である。なお、システムとは、複数の装置が論理的に集合したものをいう。
　図１において、伝送システム１は、ゲートウェイ装置１０、クライアント装置２０－１乃至２０－Ｎ（Ｎ：１以上の整数）、放送サーバ４０、及び通信サーバ７０を含んで構成される。
　伝送システム１において、ゲートウェイ装置１０と、クライアント装置２０－１乃至２０－Ｎは、エンドユーザ宅２に構築された家庭内LAN(Local Area Network)等のネットワーク３０を介して、相互に接続され、通信を行うことが可能である。
　また、ゲートウェイ装置１０は、送信所５０から、放送伝送路６０を介して送信される放送波を受信する機能とともに、インターネット８０に接続可能な通信機能も有している。これにより、ゲートウェイ装置１０は、インターネット８０を介して、通信サーバ７０と相互に接続され、通信を行うことが可能である。
　ゲートウェイ装置１０は、例えば、ゲートウェイ機能を提供するための専用のサーバや、通信機能を有するテレビ受像機やセットトップボックス（STB：Set Top Box）、ネットワークストレージなどから構成される。
　ゲートウェイ装置１０は、送信所５０を介して、放送サーバ４０から送信されてくる放送波を受信し、放送波から得られるコンテンツのデータを、ネットワーク３０に接続されたクライアント装置２０－１乃至２０－Ｎに送信（転送）する。
　また、ゲートウェイ装置１０は、インターネット８０を介して、通信サーバ７０から送信されてくるコンテンツのデータを受信し、ネットワーク３０に接続されたクライアント装置２０－１乃至２０－Ｎに送信（転送）する。
　なお、ゲートウェイ装置１０の詳細な構成は、図２を参照して後述する。
　クライアント装置２０－１は、ネットワーク３０を介してゲートウェイ装置１０から送信（転送）されてくるコンテンツを受信して再生する受信機である。すなわち、クライアント装置２０－１は、エンドユーザの操作などに応じて、ゲートウェイ装置１０を介して、放送経由又は通信経由で配信されるコンテンツを再生することができる。
　クライアント装置２０－１は、テレビ受像機やセットトップボックスなどの固定受信機、あるいは、スマートフォンや携帯電話機、タブレット型コンピュータなどのモバイル受信機である。
　クライアント装置２０－２乃至２０－Ｎは、クライアント装置２０－１と同様に、家庭内で使用される固定受信機又はモバイル受信機から構成され、ゲートウェイ装置１０を介して、放送経由又は通信経由で配信されるコンテンツを受信して再生する。
　なお、以下の説明では、クライアント装置２０－１乃至２０－Ｎを、特に区別する必要がない場合、単に、クライアント装置２０と称するものとする。また、クライアント装置２０の詳細な構成は、図３を参照して後述する。
　放送サーバ４０は、例えば、放送局などの放送事業者により提供されるサーバであって、送信所５０に設置される送出設備と、専用線などの所定の回線を介して接続される。
　放送サーバ４０は、番組やCM等のコンテンツのファイル（データ）や制御情報（シグナリング）を処理し、その結果得られるデータを、専用線を介して送信所５０内の送出設備に送信する。そして、送信所５０内の送出設備は、放送サーバ４０からのデータに対し、必要な処理（変調処理等）を施すことで、その結果得られる放送波が、放送伝送路６０を介して、エンドユーザ宅２内のゲートウェイ装置１０により受信される。
　通信サーバ７０は、例えば、放送局などの放送事業者やその他の事業者により提供されるサーバであって、インターネット８０に接続される。
　通信サーバ７０は、ゲートウェイ装置１０からのリクエストに応じて、番組やCM等のコンテンツのファイルや制御情報を処理し、その結果得られるデータを、インターネット８０を介して送信（ストリーミング配信）する。
　なお、図１の伝送システムでは、ゲートウェイ装置１０とクライアント装置２０が、エンドユーザ宅２内に配置される場合を説明したが、ゲートウェイ装置１０は、エンドユーザ宅２内に限らず、例えば、ケーブルオペレータのヘッドエンドや、モバイル網の基地局などに設置されるようにして、より広範囲は領域をカバーできるようにしてもよい。
　すなわち、例えば、ゲートウェイ装置１０が、ケーブルオペレータのヘッドエンドに設置される場合、クライアント装置２０は、同一のエンドユーザ宅内ではなく、ケーブルテレビのサービスを契約している各エンドユーザ宅内に設置されることになる。また、例えば、ゲートウェイ装置１０が、モバイル網の基地局に設置される場合、クライアント装置２０は、モバイルサービスを契約しているエンドユーザが、屋内又は屋外で所持しているデバイスとなる。
　また、クライアント装置２０は、車両に搭載される車載機器であってもよい。さらに、図１の伝送システム１において、ネットワーク３０又はインターネット８０に接続されるデバイスやサーバの間で行われる通信は、無線通信及び有線通信は勿論、無線通信と有線通信とが混在した通信、すなわち、ある区間では無線通信が行われ、他の区間では有線通信が行われるようなものであってもよい。
（ゲートウェイ装置の構成）
　図２は、図１のゲートウェイ装置１０の構成例を示す図である。
　図２において、ゲートウェイ装置１０は、処理部１００、チューナ１０１、通信I/F１０２、通信I/F１０３、及び記憶部１０４から構成される。
　処理部１００は、例えば、CPU(Central Processing Unit)やマイクロプロセッサ等から構成される。処理部１００は、各種の演算処理や、各部の動作制御などの処理を行う。
　チューナ１０１は、アンテナを介して受信された放送波に対し、必要な処理（復調処理等）を施し、その結果得られる多重化ストリームを、処理部１００に供給する。処理部１００は、チューナ１０１から供給される多重化ストリームを処理し、その結果得られるデータを、通信I/F１０３に供給する。
　通信I/F１０２は、処理部１００からの制御に従い、インターネット８０に接続された通信サーバ７０に、コンテンツの配信を要求する。通信I/F１０２は、通信サーバ７０から配信されるコンテンツのストリームを、インターネット８０を介して受信し、処理部１００に供給する。処理部１００は、通信I/F１０２から供給されるコンテンツのストリームを処理し、その結果得られるデータを、通信I/F１０３に供給する。
　通信I/F１０３は、ネットワーク３０に接続されたクライアント装置２０から送信されてくるデータを受信し、処理部１００に供給する。また、通信I/F１０３は、処理部１００から供給されるデータを、ネットワーク３０を介して、クライアント装置２０に送信する。
　なお、通信I/F１０２と通信I/F１０３は、例えば、通信インターフェース回路等から構成される。また、図２のゲートウェイ装置１０においては、説明の都合上、通信I/F１０２と通信I/F１０３を、別のブロックとして説明したが、通信I/F１０２と通信I/F１０３を共通化して、１つの通信I/Fとしてもよい。
　記憶部１０４は、例えば、半導体メモリやハードディスクドライブ（HDD：Hard Disk Drive）等から構成される。記憶部１０４は、処理部１００からの制御に従い、各種のデータを記憶する。
　処理部１００は、UPnP/SSDPサーバ１１１、プロキシアプリマネージャ１１２、ローカルプロキシ１１３、及びSLS処理系１１４を含む。
　UPnP/SSDPサーバ１１１と、プロキシアプリマネージャ１１２は、ゲートウェイ装置１０で稼働するサービスであって、ネットワーク３０に接続されるクライアント装置２０と、ローカルプロキシ１１３との接続を確立するための処理を行う。
　なお、UPnP/SSDPサーバ１１１とプロキシアプリマネージャ１１２で行われる処理の詳細は、図１７及び図１８を参照して後述する。また、UPnP/SSDPサーバ１１１は、ウェブサーバ（ローカルウェブサーバ）の機能を有するようにすることができる。
　ローカルプロキシ１１３は、ゲートウェイ装置１０で稼働するサービスであって、ネットワーク３０に接続されたクライアント装置２０からのリクエストを、インターネット８０に接続された通信サーバ７０に送信する。また、ローカルプロキシ１１３は、通信サーバ７０からのコンテンツのストリームを、インターネット８０を介して受信し、ネットワーク３０に接続されたクライアント装置２０に送信（転送）する。
　なお、ローカルプロキシ１１３は、クライアント装置２０からのリクエストに対し、拡張ヘッダ挿入処理を行うが、その処理の詳細は、図１７、図１８、及び図２７などを参照して後述する。
　SLS処理系１１４は、放送経由又は通信経由で取得される制御情報であるSLS(Service Layer Signaling)に関する処理を行う。なお、SLSの詳細は、図６を参照して後述する。また、SLS処理系１１４で行われる処理の詳細は、図２７を参照して後述する。
　ゲートウェイ装置１０は、以上のように構成される。
（クライアント装置の構成）
　図３は、図１のクライアント装置２０の構成例を示す図である。
　図３において、クライアント装置２０は、処理部２００、通信I/F２０１、表示部２０２、及びスピーカ２０３から構成される。
　処理部２００は、例えば、CPUやマイクロプロセッサ等から構成される。処理部２００は、各種の演算処理や、各部の動作制御などの処理を行う。
　通信I/F２０１は、例えば、通信インターフェース回路等から構成される。
　通信I/F２０１は、処理部２００からの制御に従い、ネットワーク３０に接続されたゲートウェイ装置１０に対し、コンテンツの配信を要求する。また、通信I/F２０１は、ネットワーク３０を介して、ゲートウェイ装置１０から送信（転送）されてくるコンテンツのデータを受信し、処理部２００に供給する。
　処理部２００は、通信I/F２０１から供給されるコンテンツのデータを処理し、その結果得られるデータのうち、ビデオデータを、表示部２０２に供給し、オーディオデータを、スピーカ２０３に供給する。
　表示部２０２は、例えば、LCD(Liquid Crystal Display)やOELD(Organic Electroluminescence Display)等のディスプレイから構成される。表示部２０２は、処理部２００から供給されるビデオデータに対応する映像を表示する。スピーカ２０３は、処理部２００から供給されるオーディオデータに対応する音声を出力する。
　なお、表示部２０２が、タッチパネルの機能を有している場合には、当該タッチパネルに対するエンドユーザの操作に応じた操作信号が処理部２００に供給され、処理部２００は、当該操作信号に応じた処理を行う。また、図３には図示していないが、物理的なボタン等の入力部を設けて、当該入力部に対するエンドユーザの操作に応じた操作信号が、処理部２００に供給されるようにしてもよい。
　処理部２００は、アプリケーション２１１及びブラウザ２１２を含む。アプリケーション２１１及びブラウザ２１２により、レンダラ機能が提供される。
　アプリケーション２１１は、ネットワーク３０に接続されるクライアント装置２０が、ゲートウェイ装置１０で稼働するローカルプロキシ１１３との接続を確立するための処理を行う。なお、アプリケーション２１１で行われる処理の詳細は、図１７及び図１８を参照して後述する。
　ブラウザ２１２は、通信I/F２０１から供給されるコンテンツのデータであって、ゲートウェイ装置１０により放送経由又は通信経由で受信されたデータを処理し、コンテンツを再生する。
　なお、ブラウザ２１２は、DASHプレーヤとしての機能を有するが、その詳細は、図６を参照して後述する。また、ブラウザ２１２で行われる処理の詳細は、図１７、図１８、及び図２７などを参照して後述する。
　クライアント装置２０は、以上のように構成される。
（受信側の装置の実装例）
　ところで、図１の伝送システム１においては、ゲートウェイ装置１０が、放送経由又は通信経由で、送信側のサーバから配信されるデータを、受信側のクライアント装置２０に転送するための役割を担う構成を説明したが、その役割を、ネットワーク３０に接続されたクライアント装置２０のいずれかが担うようにした構成を採用することもできる。
　ここでは、例えば、エンドユーザ宅２において、ネットワーク３０に接続された複数のクライアント装置２０のうち、クライアント装置２０－１が、チューナ及び通信I/Fなどのゲートウェイ装置１０と同様の機能を有し、放送経由及び通信経由で配信されるコンテンツのデータを受信可能な場合を想定する。
　この場合において、クライアント装置２０－２乃至２０－Ｎは、ゲートウェイとして動作するクライアント装置２０－１を介して、放送経由又は通信経由で配信されるコンテンツのデータを受信することができる。ただし、この場合でも、クライアント装置２０－２乃至２０－Ｎは、ゲートウェイ装置１０に接続して、放送経由又は通信経由で配信されるコンテンツのデータを受信するようにしてもよい。
　これらの関係をまとめると、図４に示すようになる。すなわち、図４において、ゲートウェイ装置１０は、図２の構成に示したように、チューナ１０１とともに、処理部１００として、UPnP/SSDPサーバ１１１、プロキシアプリマネージャ１１２、ローカルプロキシ１１３、及びSLS処理系１１４を含んで構成される。
　また、図４において、クライアント装置２０には、レンダラ機能のみを有する一般クライアント装置２０と、レンダラ機能だけでなく、ゲートウェイ機能をも有するオールインワン型（All in One）のクライアント装置２０との２種類がある。
　なお、以下の説明では、適宜、オールインワンクライアント装置２０を、「AOC(All in One Client)」とも記述し、一般クライアント装置２０を、「NC(Normal Client)」とも記述する。また、ゲートウェイ装置１０は、「GW(Gateway)」とも記述する。
　一般クライアント装置（NC）２０は、図３の構成に示したように、アプリケーション２１１及びブラウザ２１２によるレンダラ機能を含んで構成される。一方で、オールインワンクライアント装置（AOC）２０は、レンダラ機能のほかに、ゲートウェイ装置（GW）１０と同様に、チューナ１０１、UPnP/SSDPサーバ１１１、プロキシアプリマネージャ１１２、ローカルプロキシ１１３、及びSLS処理系１１４によるゲートウェイ機能を含んで構成される。
　すなわち、一般クライアント装置（NC）２０は、ゲートウェイ機能を有するゲートウェイ装置（GW）１０、又はオールインワンクライアント装置（AOC）２０を介して、送信側のサーバとデータをやりとりするが、オールインワンクライアント装置（AOC）２０は、自身がゲートウェイ機能を有するため、単独で、送信側のサーバとデータをやりとりすることができる。
　より具体的には、図５に示すような関係として表すことができる。
　図５において、一般クライアント装置（NC）２０は、ゲートウェイ装置（GW）１０又はオールインワンクライアント装置（AOC）２０を介して、放送経由又は通信経由のデータを受信する。すなわち、ゲートウェイ装置（GW）１０は、一般クライアント装置（NC）２０に対し、ゲートウェイ機能を提供することができる。また、オールインワンクライアント装置（AOC）２０は、一般クライアント装置（NC）２０に対し、ゲートウェイ機能を提供することができる。
　また、オールインワンクライアント装置（AOC）２０は、ゲートウェイ装置（GW）１０からゲートウェイ機能の提供を受けて、一般クライアント装置（NC）２０として機能することもできるが、通常は、自身のゲートウェイ機能を使って、放送経由又は通信経由のデータを受信する。
　ゲートウェイ装置（GW）１０は、ゲートウェイとして機能し、送信側のサーバから放送経由又は通信経由で配信されるデータを、一般クライアント装置（NC）２０又はオールインワンクライアント装置（AOC）２０に送信する。また、ゲートウェイ装置（GW）１０は、一般クライアント装置（NC）２０又はオールインワンクライアント装置（AOC）２０からのリクエストに対し、拡張ヘッダ挿入処理を施し、その結果得られるリクエストを、通信経由で送信する。
　オールインワンクライアント装置（AOC）２０は、ゲートウェイとして機能し、送信側のサーバから放送経由又は通信経由で配信されるデータを、自身で処理するか、又は一般クライアント装置（NC）２０に送信する。また、オールインワンクライアント装置（AOC）２０は、自身で処理したリクエスト、又は一般クライアント装置（NC）２０からのリクエストに対し、拡張ヘッダ挿入処理を施し、その結果得られるリクエストを、通信経由で送信する。
　なお、受信側のクライアント装置２０に対し、送信側のサーバからのデータを中継するゲートウェイ機能を有する装置としては、放送経由と通信経由のデータを、同一の装置で処理してもよいし、放送経由のデータを処理する装置と、通信経由のデータを処理する装置とが異なるようにしてもよい。例えば、一般クライアント装置（NC）２０に対する、放送経由のデータを、ゲートウェイ装置（GW）１０が処理し、通信経由のデータを、オールインワンクライアント装置（AOC）２０が処理することができる。
（本技術のプロトコルスタック）
　図６は、本技術のIP伝送方式のプロトコルスタックの例を示す図である。
　デジタル放送の伝送方式として、現状では、MPEG2-TS(Transport Stream)方式が広く普及しているが、今後は、通信の分野で用いられているIP(Internet Protocol)パケットをデジタル放送に用いたIP伝送方式が普及することが想定されている。
　例えば、次世代地上波放送規格の１つであるATSC(Advanced Television Systems Committee)3.0においても、IP伝送方式を採用して、より高度なサービスを提供できるようにすることが期待されている。本技術においても、ATSC3.0等と同様に、IP伝送方式を採用することができる。
　図６において、最も下位の階層は、物理層（Physical Layer）とされる。ATSC3.0等のIP伝送方式のデジタル放送では、一方向の放送を利用した伝送に限らず、一部のデータを、双方向の通信を利用して伝送する場合があるが、放送（Broadcast）を利用する場合、その物理層は、サービス（チャネル）のために割り当てられた放送波の周波数帯域等が対応することになる。
　物理層（Physical Layer）の上位の階層は、データリンク層（Data Link Layer）とされる。また、データリンク層の上位の階層は、IP(Internet Protocol)層とUDP(User Datagram Protocol)層とされる。IP層とUDP層は、通信の階層モデルにおけるネットワーク層とトランスポート層に相当する層であり、IPアドレスとポート番号により、IPパケットとUDPパケットが特定される。
　ここで、ATSC3.0では、制御情報（シグナリング）として、LLS(Low Level Signaling)とSLS(Service Layer Signaling)を用いることが想定されている。LLSは、SLSよりも下位の層で伝送される制御情報である。SLSは、サービス単位の制御情報である。すなわち、ATSC3.0では、トランスポート層の制御情報が、LLSとSLSの２階層で伝送される。
　LLSには、SLT(Service List Table)等のメタデータが含まれる。SLTメタデータは、サービス（チャネル）の選局に必要な情報など、放送ネットワークにおけるストリームやサービスの構成を示す基本情報を含む。このSLTメタデータは、UDPパケットを含むIPパケットであるUDP/IPパケットに含めて伝送される。ただし、SLTメタデータを格納したUDP/IPパケットは、特別なIPアドレスとポート番号で伝送されることになる。
　IP層とUDP層に隣接する上位の階層は、ROUTE(Real-time Object Delivery over Unidirectional Transport)とされる。ROUTEは、ストリーミングファイル転送用のプロトコルであって、FLUTE(File Delivery over Unidirectional Transport)を拡張したものである。
　このROUTEセッションにより、サービスごとに、SLSのファイル（Signaling）や、NRT(Non Real Time)コンテンツのファイル（NRT）、DASHセグメントファイル（DASH）などが伝送される。
　ここで、SLSは、サービスレベルの制御情報であり、対象のサービスに属するコンポーネントの探索と選択に必要な情報や属性などを提供するものである。SLSは、USBD(User Service Bundle Description)，S-TSID(Service-based Transport Session Instance Description)，MPD(Media Presentation Description)等のメタデータを含む。
　USBDメタデータは、他のメタデータの取得先などの情報を含む。なお、USBDメタデータの詳細は、図１４を参照して後述する。
　S-TSIDメタデータは、LSID(LCT Session Instance Description)をATSC3.0向けに拡張したものであって、ROUTEプロトコルの制御情報である。また、S-TSIDメタデータは、ROUTEセッションで伝送されるEFDT(Extended FDT)を特定することができる。EFDTは、FLUTEで導入されていたFDT(File Delivery Table)を拡張したものであって、転送用の制御情報である。
　MPDメタデータは、MPEG-DASHに準拠したストリーミング配信を行うために用いられる、ビデオやオーディオのファイルの制御情報である。なお、MPDメタデータの詳細は、図７乃至図１１、及び図１４などを参照して後述する。
　ここで、MPEG-DASHは、OTT-V(Over The Top Video)に従ったストリーミング配信規格であって、HTTP(Hypertext Transfer Protocol)をベースとしたストリーミングプロトコルを用いたアダプティブストリーミング配信に関する規格である。
　このMPEG-DASHの規格では、ビデオやオーディオのファイルの制御情報であるメタデータを記述するためのマニフェストファイルと、動画のコンテンツを伝送するためのファイルフォーマットが規定されている。ここでは、前者のマニフェストファイルが、MPD(Media Presentation Description)と称され、後者のファイルフォーマットは、セグメントフォーマットとも称される。
　また、トランスポート・プロトコルとして、ROUTEを用いる場合には、ストリーミングのファイルフォーマットとして、MP4ファイルフォーマットを用いることができる。MP4ファイルフォーマットは、ISO/IEC 14496-12で規定されているISO BMFF(ISO Base Media File Format)の派生フォーマットである。
　ROUTEセッションで伝送されるセグメントは、イニシャライゼイションセグメント（IS：Initialization Segment）と、メディアセグメント（MS：Media Segment）から構成される。イニシャライゼイションセグメントは、データ圧縮方式等の初期化情報を含んでいる。また、メディアセグメントは、ビデオやオーディオ、字幕のストリームのデータを格納している。すなわち、このメディアセグメントが、DASHセグメント（DASHセグメントファイル）に相当するものである。
　このように、番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータは、ISO BMFFの規格に準じたDASHセグメント単位で、ROUTEセッションにより伝送されることになる。
　なお、NRTコンテンツは、受信機のストレージに一旦蓄積された後で再生が行われる。また、NRTコンテンツ以外のファイル（例えば、アプリケーションや電子サービスガイド（ESG：Electronic Service Guide）のファイル）がROUTEセッションで伝送されるようにしてもよい。
　また、LLSとしてのSLTメタデータや、SLSとしてのUSBD，S-TSID，MPD等のメタデータは、例えば、XML(Extensible Markup Language)等のマークアップ言語により記述されたテキスト形式のデータとすることができる。
　一方で、双方向の通信（Broadband）を利用する場合、その物理層（Physical Layer）の上位の階層は、データリンク層（Data Link Layer）とされる。また、データリンク層の上位の階層は、ネットワーク層に相当するIP層とされる。IP層に隣接する上位階層は、トランスポート層に相当するTCP(Transmission Control Protocol)層とされ、さらに、TCP層に隣接する上位階層は、アプリケーション層に相当するHTTP層とされる。
　すなわち、これらの階層によって、図１のインターネット８０等の通信回線で稼働するTCP/IPなどのプロトコルが実装される。
　HTTP層に隣接する上位階層のうち、一部の階層は、制御情報（Signaling）と、NRTコンテンツ（NRT）とされる。この制御情報としては、上述したROUTEセッションで伝送される制御情報など、すべての制御情報が含まれる。また、NRTコンテンツは、通信経由で取得されるコンテンツであって、例えば、アプリケーションが含まれる。
　HTTP層に隣接する上位階層のうち、上述した階層以外の他の階層は、DASHセグメント（DASH）とされる。すなわち、双方向の通信系のストリーミング配信では、VOD(Video On Demand)番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータが、ISO BMFFの規格に準じたDASHセグメント単位で伝送されることになる。
　以上のように、本技術のIP伝送方式のプロトコルスタックにおいては、一方向の放送系の階層と、双方向の通信系の階層の一部が共通のプロトコルとなって、一方向の放送と双方向の通信で、コンテンツを構成するサービスコンポーネントのストリームデータを、ISO BMFFの規格に準じたDASHセグメント単位で伝送することができる。
　そのため、一方向の放送系のストリーミング配信と、双方向の通信系のストリーミング配信の双方を行う場合において、上位の階層のプロトコルが共通化されているため、例えば、クライアント装置２０、放送サーバ４０や通信サーバ７０では、実装の負担や処理の負担を軽減することができる。
（MPDメタデータの詳細）
　次に、図７乃至図１１を参照して、SLSとして伝送されるMPDメタデータの詳細を説明する。
　MPDメタデータには、Period要素、AdaptationSet要素、及び、Representation要素が階層構造で記述されている。
　例えば、図７に示すように、ルート要素となるMPD要素の下には、時間の区切りを示すPeriod要素があり、さらに、Period要素の下に、ビデオやオーディオ、字幕などのそれぞれのストリーム（エレメンタリストリーム）ごとに、AdaptationSet要素を配置して、それぞれのストリームの属性を記述する。
　また、AdaptationSet要素の下に、同一のストリーム（エレメンタリストリーム）から派生する、レート等の属性の異なる複数のストリームごとに、Representation要素に分けて、それぞれのレート等の属性を記述する。なお、Representation要素は、時間軸上で、複数のセグメント（Segment）に分割される。
　クライアント装置２０では、SLSとして伝送されるMPDメタデータをパースし、Representation要素に記述されたストリームに指定されるレートの値を参考にして、クライアント装置２０のおかれているネットワーク環境に応じた最適なストリームを選択できるようになっている。
　図８には、MPDメタデータにおける、Period要素と、AdaptationSet要素と、Representation要素との関係を詳細に示している。
　なお、Representation要素の下には、Representation要素がさらに複数のストリームから構成される場合に、各々のストリームの属性を記述するために、SubRepresentation要素を配置することができる。
　ここで、MPDメタデータに記述されるセグメントファイルは、URL（バイトレンジ）により特定される。セグメントは、Representation要素の一部であって、１つのRepresentation要素は、以下のいずれかにより構成される。
（１）１つかそれ以上のセグメントリスト
（２）１つのセグメントテンプレート
（３）１つかそれ以上のベースURLと最大１つのセグメントベース（この場合にはセグメントリストも、セグメントテンプレートもない）
　以下、上記の（１）乃至（３）に対応するMPDメタデータの記述例を示す。
　図９は、セグメントベース（SegmentBase）を利用する場合のMPDメタデータの例を示す図である。
　図９に示すように、セグメントベースは、１つのRepresentation要素に、１つのメディアセグメント（セグメント）しかない場合に利用される。図９において、初期化情報のバイト列とRAP(Random Access Points)のバイト列が、ファイルの最初の834バイト以内に収まっている。なお、この834バイトは、SegmentBase要素のindexRange属性により記述される。
　図１０は、セグメントリスト（SegmentList）を利用する場合のMPDメタデータの例を示す図である。
　図１０に示すように、セグメントリストは、１つのRepresentation要素に、複数のセグメントURLが配置される場合に利用される。図１０のRepresentation要素において、SegmentList要素には、再生順に配置される複数のSegmentURL要素が列記される。
　SegmentURL要素は、DASHセグメントファイルのURL（そのファイル内のバイトレンジ）により表現される。なお、SegmentList要素の最初に配置されるInitilization要素には、初期化情報を格納したファイル（InitSegment）を指示している。
　図１１は、セグメントテンプレート（SegmentTemplate）を利用する場合のMPDメタデータの例を示す図である。
　図１１に示すように、セグメントテンプレートは、セグメントURLを自動生成するときに利用する。このユースケースの典型的な例としては、ライブストリーミングがある。すなわち、セグメントテンプレートにおいては、SegmentTemplate要素に記述されるセグメントURLのひな形の中の特別なパラメタを動的に置き換えていくことにより、完全なセグメントURLのリストを生成する。
　具体的には、SegmentTemplate要素のmedia属性の属性値として記述されるURLのうち、"$Number$"の部分が、置換パラメタ（ReplacementParameter）に相当し、当該パラメタを、startNumber属性の値から開始して、順次インクリメントしながら書き換えることで、セグメントURLが生成される。なお、このセグメントテンプレートを利用することで、MPDメタデータのサイズを非常に小さくすることが可能となる。
＜２．本技術の概要＞
　ところで、伝送システム１においては、コンテンツの配信側（放送事業者）により管理されるサーバ（例えば通信サーバ７０）で、あるコンテンツに対するクライアント装置２０からのHTTPリクエストの履歴により、アクセス統計（視聴率）を管理するような運用が想定される。なお、ここでのコンテンツのデータは、DASHセグメントファイルのシーケンスのような、１つのコンテンツから生成されるチャンク化されたファイルシーケンス、又はフラグメントシーケンスにより伝送される。
　このような運用を行う場合に、チャンク化された各々のDASHセグメントに対するHTTPリクエストを記録するとき、各々のリクエスト間の相関がわかりにくいと、同一のコンテンツに対するリクエストのシーケンスであるかどうかを判断することが難しい。
　一方で、HTTPリクエストのリクエストヘッダ（以下、HTTPリクエストヘッダという）に記述されるリクエストURLの内容を解析して、同じパターンを特定することにより、HTTPリクエストのシーケンスを関連付ける（まとめる）ことは可能ではある。
　しかしながら、それらのURLの内容の相関がわかりやすい場合には、この方法を適用することができるが、同一のコンテンツのデータから生成されたDASHセグメントファイルであっても、MPDメタデータに記述されるAdaptationSet要素や、Representation要素の構成方法によっては、そこに含まれるセグメントURL（segmentUrl）が、それぞれ、全く相関のない内容になる可能性がある。
　そのような構成を記述したMPDメタデータの例を、図１２に示している。図１２のMPDメタデータにおいては、Period要素と、AdaptationSet要素と、Representation要素とが階層構造をなしているが、Representation要素には、セグメントリストとして、複数のセグメントURLが記述されている。
　このセグメントURLは、BaseURL要素の値として指定されるベースURLと、SegmentURL要素のmedia属性の値として指定されるファイルのURLとを結合することで、完全なURLが得られる。
　すなわち、図１２のMPDメタデータにおいては、同一のコンテンツから生成される２つのRepresentation要素の系列が記述され、一方の系列が、"http://cdn1.com/seg-201.mp4"，"http://cdn1.com/seg-202.mp4"，・・・となり、他方の系列が、"http://cdn2.com/s101.mp4"，"http://cdn2.com/s102.mp4"，・・・となる。
　なお、この例では、CDN(Content Delivery Network)サービスを利用して、同一のコンテンツを、異なるCDNのサーバから、配信元のパスを変えて配信する運用が行われる場合を示している。
　ここで、"http://cdn1.com/seg-201.mp4"と"http://cdn2.com/s101.mp4"との関係などからは、図１２の２つのRepresentation要素に記述された系列ごとのDASHセグメントのシーケンスが、同一のコンテンツから生成されたDASHセグメントのシーケンスであることを類推することは、容易ではない。
　また、仮に、リクエストURLの内容に相関がある場合でも、HTTPリクエストを受けた通信サーバ７０では、以前に処理したURLのシーケンスを、常に保持しておいて、後続のHTTPリクエストのリクエストURLとの比較を行い、その内容に相関があれば、それらを同一のコンテンツから生成されるDASHセグメントであると類推して記憶するといった処理が必要となる。
　なお、ここで、リクエストURLの内容に相関がある場合とは、例えば、"http://cdn1.com/seg-201.mp4"，"http://cdn1.com/seg-202.mp4"，・・・のように、時系列順に並び、ある部分が規則性のある整数としてエンコードされる場合などである。
　しかしながら、このような運用を行う場合、通信サーバ７０側で、過去のリクエストURLの履歴（状態情報）を保持する負担が大きくなり、かつ、リクエストURLの比較や、同一の出元となるコンテンツ（コンテンツのソースの同一性）の可能性の類推などの余計な処理負荷を増加させるため、スケーラビリティを損ねることになる。したがって、通信サーバ７０側で、リクエストURLのみに頼るコンテンツの同一性の類推を行い、その結果を用いてアクセス統計の記録を行うことは、現実的ではない。
　その一方で、例えば、現在策定中のATSC3.0においては、サービスを提供する放送事業者等は、ATSC3.0の放送サービス（以下、ATSC3.0サービスともいう）で配信されるDASHセグメントへのアクセス統計を、次のように行いたいという要請がある。
　すなわち、ATSC3.0サービス（放送サービス）を、サービスエントリとしてアクセスしてくるエンドユーザデバイス（以下、ATSC3.0エンドデバイスともいう）と、そうではない一般のインターネットのサイトを、サービスエントリとしてアクセスしてくるエンドユーザデバイス（以下、一般エンドデバイスともいう）とを区別し、かつ、既存のCDNのロギングの機能を利用して、DASHセグメントへのアクセス統計を記録したいという要請がある。
　なお、ここでのATSC3.0エンドデバイスには、一般クライアント装置（NC）２０と、オールインワンクライアント装置（AOC）２０が共に該当する可能性がある。また、一般エンドデバイスについても、一般クライアント装置（NC）２０と、オールインワンクライアント装置（AOC）２０が共に該当する可能性がある。
　また、通信サーバ７０が、CDNのサーバとして提供されるようにすることで、通信サーバ７０によって、コンテンツのデータ（DASHセグメントファイル）の配信が行われるときに、既存のCDNのロギングの機能を利用して、DASHセグメントのアクセス統計を記録するという運用が可能となる。ここでは、既存のCDNの機能を利用することで、追加コストを最小限に抑えることができる。
　以上のように、放送事業者等の事業者からは、ATSC3.0エンドデバイスと一般エンドデバイスとを区別して、アクセスの統計を管理する運用などを行いたいという要請があるが、現状では、そのような要請に応えるための技術方式は確立されていない。
　そこで、本技術では、放送と通信を利用したサービスの運用を行う場合において、ATSC3.0サービス（放送サービス）を導線（サービスエントリ）として、通信経由でアクセスしてくるATSC3.0エンドデバイス（クライアント装置２０）を識別可能にすることで、より柔軟に、放送と通信を利用したサービスの運用を行うことができるようにする。
　すなわち、本技術では、放送サービスをサービスエントリとして、通信経由で、DASHセグメントに対するHTTPリクエストが送信される場合に、HTTPリクエストヘッダに対し、当該DASHセグメントの元となるコンテンツのソースの同一性を識別するための識別情報（以下、ソース識別情報という）が挿入されるようにする。
　例えば、同一のコンテンツであっても、例えば、レート等の属性や、放送経由又は通信経由等の配信経路が異なる場合があり、そのような場合でも、コンテンツのソースが同一である場合には、同一のソース識別情報（ソース同一性を識別する識別子）が付加されるようにすることで、ソースの同一性を識別することができる。
　これにより、通信サーバ７０側では、HTTPリクエストヘッダに含まれるソース識別情報を記憶しておくだけで、異なるサービスの配信に起因する、DASHセグメントに対するHTTPリクエストのリクエストURLの間の相関性を、HTTPリクエストごとに処理する必要がなくなり、通信サーバ７０側の処理負荷を大幅に低減することができる。
　ただし、HTTPリクエストに対し、このような特殊なヘッダを追加する処理は、一般のDASHクライアント（DASHプレーヤ）の実装に、容易に加えることはできない。
　そこで、本技術では、ATSC3.0サービス（放送サービス）で配信されるDASHセグメントに対するHTTPリクエストについては、それらのHTTPリクエストをすべて、ATSC3.0のプロキシサーバ（ゲートウェイ装置１０で稼働するローカルプロキシ１１３）を経由させるようにする。これにより、ローカルプロキシ１１３上のモジュールやサーバサイドスクリプトなどによって、HTTPリクエストヘッダに対し、拡張ヘッダ（ソース識別情報）を、容易に挿入することができるようになる。
　また、このローカルプロキシ１１３は、TLS(Transport Layer Security)等のセキュアなエンドトゥーエンドトランザクションをも透過的に処理可能な透過型のプロキシ（以下、トランスペアレントプロキシ(Transparent Proxy)という）として構成されるようにする。これにより、TLS等のエンドトゥーエンドのセキュアなトランスポートセッションで保護された（隠ぺいされた）DASHセグメントのリクエスト/レスポンストランザクションについても同様に、拡張ヘッダ挿入処理を行うことが可能となる。
　なお、トランスペアレントプロキシに関する技術としては、既に各種の技術が提案されており、ここでは、それらの公知の技術を用いることができる。
＜３．HTTPリクエストヘッダの拡張方法＞
（拡張ヘッダの例）
　図１３は、本技術の拡張ヘッダの例を示す図である。
　図１３には、HTTPリクエストヘッダの拡張の一例として、ATSC3.0サービスの場合の拡張ヘッダの記述例を示している。
　図１３において、HTTPリクエストヘッダの汎用ヘッダに拡張する拡張ヘッダ名は、例えば、"ATSC3.0-Requset"とされる。ここで、汎用ヘッダは、リクエストやレスポンスのエンティティボディではなく、接続に対して適用されるヘッダを意味する。なお、拡張ヘッダ名を、プライベートヘッダとして定義する場合には、"X-ATSC3.0-Requset"とすることができる。
　拡張ヘッダの値としては、コンテンツのソースの同一性を識別するためのソース識別情報が配置される。このソース識別情報には、サービスID（service-id）、コンテンツID（contentId）、MPDメタデータのURL（mpd-uri）、及び時刻情報（broadcastTime）等のATSC3.0サービスの配信関連の主な属性を含めることができる。
　サービスIDは、ATSC3.0で規定されるサービスを識別するためのID（グローバルサービスID）である。このサービスIDは、必須の値とされる。
　なお、ATSC3.0規定のサービスID（globalServiceId）の詳細は、下記の非特許文献１の「Table 7.1 Semantics of the User Service Bundle Description Fragment for ROUTE/DASH」に開示されている。すなわち、サービスIDとしては、USBDメタデータのuserServiceDescription要素のglobalServiceID属性の値を用いることができる。
　非特許文献１：ATSC Candidate Standard：Signaling, Delivery, Synchronization, and Error Protection(A/331) Doc. S33-174r15 January 2016
　MPDメタデータのURLは、USBDメタデータにより参照されるMPDメタデータの絶対パスを表したURI(Uniform Resource Locator)である。このURLは、オプショナルな値とされる。
　なお、上記の非特許文献１の「Table 7.1 Semantics of the User Service Bundle Description Fragment for ROUTE/DASH」に開示されているように、MPDメタデータのURLとしては、USBDメタデータのuserServiceDescription要素のfullMPDUri属性の値を用いることができる。
　時刻情報は、コンテンツが実際に放送された時刻を表している。ただし、放送時刻の内容の選択は、実装依存とされる。つまり、例えば、放送時刻が、コンテンツの配信スケジュールの開始時刻であるのか、あるいは配信スケジュールの開始から終了までの任意の時刻（HTTPリクエストのパケットが到着した時刻）であるのかは、運用に応じて設定される。この時刻情報は、オプショナルな値とされる。
　コンテンツIDは、コンテンツを識別するIDである。このコンテンツIDとしては、例えば、"EIDR"又は"Ad-ID"を指定することができる。ここで、"EIDR"は、Entertainment Identifier Registryの略であり、テレビ番組や映画のコンテンツを、グローバルな単一のIDで管理することができる。"Ad-ID"は、Advertising IDの略であり、広告用のIDである。このコンテンツIDは、オプショナルな値とされる。
　ここで、図１４には、HTTPリクエストに対し、拡張ヘッダとして挿入されるソース識別情報の例を示している。
　すなわち、図１４においては、XML形式のUSBDメタデータとMPDメタデータの記述例を示しているが、これらのメタデータから得られる情報を、ATSC3.0サービスの配信関連の属性として、ソース識別情報に含めることができる。
　例えば、USBDメタデータにおいては、userServiceDescription要素のglobalServiceID属性の値から、サービスID（グローバルサービスID）が得られ、userServiceDescription要素のfullMPDUri属性の値から、MPDメタデータのURLが得られる。また、例えば、MPDメタデータにおいては、Period要素のAssetIdentifier要素の値から、EIDRに対応したコンテンツIDが得られる。
　なお、詳細は、後述するが、拡張ヘッダ挿入処理に先立って、ソース識別情報を格納したマッピングデータベースをあらかじめ生成しておくことで、拡張ヘッダ挿入処理では、マッピングデータベースを参照することにより、HTTPリクエストに挿入すべき、ソース識別情報を取得することが可能となる。
　また、USBDメタデータのDeliveryMethod要素に記述されるURLと、MPDメタデータのRepresentation要素に記述されるURL（セグメントURL）とのマッチングを行うことで、コンテンツのデータ（ストリーム）の配信経路が、放送経由であるのか、あるいは通信経由であるのかを特定することができる。なお、MPDメタデータにおけるセグメントURLの記述と導出については、図７乃至図１１を参照して先に述べた通りである。
　次に、図１５及び図１６を参照して、HTTPリクエストヘッダの具体的な例を示す。ここでは、まず、図１５を参照して、拡張ヘッダ挿入前のHTTPリクエストヘッダを説明してから、図１６を参照して、拡張ヘッダ挿入後のHTTPリクエストヘッダを説明する。
（HTTPリクエスト）
　図１５は、HTTPリクエストの例を示す図である。
　図１５においては、セグメントURLが、"http://a.com/a.mp4"の場合に、このDASHセグメントファイルを取得するためのHTTPリクエストの例を示している。
　このHTTPリクエストは、HTTPで定義されているメソッドのうち、GETメソッドを利用している。HTTPリクエストでは、HOSTにより、ホスト名（サーバ名）が指定され、GETメソッドにより、リソースが指定される。なお、"HTTP/1.1"は、HTTPのバージョンを表している。
　なお、HTTPリクエストでは、１行目がHTTPリクエスト行となり、２行目以降がHTTPヘッダ行、すなわち、HTTPリクエストヘッダとされる。また、GETメソッドを利用する場合、HTTPボディ部には、何も記述されることはない。
（拡張ヘッダ挿入後のHTTPリクエスト）
　図１６は、拡張ヘッダが挿入されたHTTPリクエストの例を示す図である。
　図１６においては、図１５のHTTPリクエスト（HTTPリクエストヘッダ）に対し、拡張ヘッダとして、"atsc3.0-requset"である拡張ヘッダ名の行が追加されている。
　すなわち、この拡張ヘッダとして追加されるDASHセグメントファイルのコンテンツの属性は、セグメントURLを主キーとして、マッピングデータベースを参照することで得られるソース識別情報からなる。具体的には、サービスID、コンテンツID、MPDメタデータのURL、及び時刻情報等のソース識別情報が、拡張ヘッダとして追加されている。
　例えば、図１６のHTTPリクエストの拡張ヘッダでは、USBDメタデータのglobalServiceID属性の値である"urn:atsc:serviceId:NBCU-NFL-1"が、サービスID（service-id）として指定され、USBDメタデータのfullMPDUri属性の値である"http://a.com/a.mpd"が、MPDメタデータのURL（mpd-uri）として指定されている。
　また、図１６のHTTPリクエストの拡張ヘッダでは、MPDメタデータのAssetIdentifier要素に記述されるEIDRである"md:cid:EIDR:10.5240%2f0EFB-02CD-126E-8092-1E49-W"が、コンテンツID（contentId）として指定されている。さらに、図１６のHTTPリクエストの拡張ヘッダでは、当該コンテンツの放送時刻である2016年7月4日(金)23:54:58(グリニッジ標準時)を表した"Fri, 04 Jul 2016 23:54:58 GMT"が、時刻情報（broadcastTime）として指定されている。
　以上のように、本技術では、HTTPリクエストに対し、拡張ヘッダとして、ソース識別情報を挿入することで、放送サービスをサービスエントリとして、通信経由で、DASHセグメントに対するHTTPリクエストが送信される場合でも、コンテンツのソースの同一性を識別することができるようにしている。
　なお、ここでは、デジタル放送の規格として、米国等で採用される方式であるATSC（特にATSC3.0）を一例に説明したが、本技術は、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。
　すなわち、ソース識別情報は、コンテンツのソースの同一性を識別可能な情報であって、放送サービス（例えば、ATSC3.0サービス等）を識別するための情報となるので、様々な放送方式に適用することができる。ただし、上述した説明では、ソース識別情報として、ATSC3.0サービスを前提に、サービスIDやコンテンツIDなどを例示列挙したが、それらに限らず、ISDBやDVB等の規格ごとに、より適した情報を用いることができる。
　また、デジタル放送の規格以外で規定された情報を、必要に応じて、ソース識別情報に加えることもできる。例えば、移動体通信システムの標準化プロジェクトである3GPP(Third Generation Partnership Project)で規定された情報を追加することもできる。具体的には、例えば、ソース識別情報として、3GPP-MBMS(Multimedia Broadcast Multicast Services)で規定される要素や属性を加えることができる。
＜４．トランスペアレントプロキシの発見・接続方法＞
　ところで、エンドユーザ宅２内のほか、ケーブルオペレータのヘッドエンドや、モバイル網の基地局などに設置される可能性のある、ゲートウェイ装置１０（のローカルプロキシ１１３）を発見・接続する方法としては、いくつかの方法が想定される。
　例えば、クライアント装置２０において、ブラウザ２１２のインターネット接続設定のメニューにて、手動でローカルプロキシ１１３のIPアドレスやポート番号などを入力する方法や、プロキシ設定スクリプトのURLを登録する方法、あるいは自動設定による方法などがある。
　自動設定の方法としては、例えば、DHCP(Dynamic Host Configuration Protocol)サーバを用いる方法や、WPAD(Web Proxy Auto Discovery)を用いる方法などがある。また、プロキシ設定スクリプトによる自動設定は、JavaScript（登録商標）等のスクリプト言語で記述されたプロキシ自動構成スクリプトファイルを用意して、そのファイルをウェブサーバ上に配置する一方で、そのファイルのURLを、ブラウザ２１２の自動設定のスクリプトのURLに設定すればよい。
　WPADを用いる場合には、ブラウザ２１２自身が、プロキシ設定用のスクリプトファイルの位置（URL）を自動的に検出してダウンロードすることで、設定を行うことができる。なお、WPADでは、一般には、DHCPサーバのDHCPINFORMメッセージを用いる方法と、DNS(Domain Name System)を用いた方法により、"wpad"という名前を持つエントリを探して、そこからプロキシ設定スクリプトをダウンロードする方法が実装されている。
　ゲートウェイ装置１０（のローカルプロキシ１１３）の発見においても、同様の方法を用いることができる。ローカルプロキシ１１３では、HTTPSプロトコルによるセキュアなエンドトゥーエンドのトランスポートセッションを含むすべてのセッションを、ローカルプロキシ１１３が、仲介（横取り）できるようにする。一般的に、このようなプロキシが、トランスペアレントプロキシ（透過プロキシ）と呼ばれるのは、先に述べた通りである。
　本技術では、クライアント装置２０が、ネットワーク３０において、ローカルプロキシ１１３が稼働しているサーバであるゲートウェイ装置１０を発見し、当該ローカルプロキシ１１３がリクエストを待ち受けるIPアドレスとポート番号（以下、プロキシ待ち受けアドレス/ポートともいう）を取得する方式を提案する。
　そのためには、クライアント装置２０では、ローカルプロキシ１１３に対し、プロキシ待ち受けアドレス/ポートを問い合わせるためのWeb API(Application Programming Interface)を認識する必要がある。つまり、このWeb APIは、サービスを呼び出すためのインターフェースであると言える。
　ここで、トランスペアレントプロキシであるローカルプロキシ１１３の発見に、ユニバーサルプラグアンドプレイ(UPnP：Universal Plug and Play)を利用する場合、ローカルプロキシ１１３の発見と、機能の公開には、SSDP(Simple Service Discovery Protocol)が用いられる。
　なお、UPnPは、デバイスを接続するだけで、対象のネットワークに参加することを可能にするプロトコルである。また、SSDPは、UPnPで用いられるプロコトルの１つで、ネットワーク上のデバイスの探索や応答を行うためのものである。
　一般に、SSDPにおいては、公開されるサービスを発見する際にやりとりされるデバイスディスクリプションとして、デバイスが提供可能な機能や情報が記述されたXML形式のファイルが用いられる。このファイルには、対象のデバイスそのものについて記述したデバイスディスクリプションと、対象のデバイス上に実装された各サービスが持つアクションとしてのサービスディスクリプションとが記述される。
　本技術では、ローカルプロキシ１１３のディスクリプション（例えばサービスディスクリプション）に、当該ローカルプロキシ１１３がリクエストを待ち受けるIPアドレスとポート番号（プロキシ待ち受けアドレス/ポート）を返答するWeb APIのURLを記述できるようにする。
　また、本技術では、ATSC3.0サービス等の放送サービスに対応するローカルプロキシ１１３のサービスを発見するためのプロトコルを追加することにより、放送サービスを実装していない一般クライアント装置（NC）２０で、ブラウザ２１２のプロキシとして、プロキシ待ち受けアドレス/ポートを設定できるようにする。
　すなわち、放送サービスを実装していない一般クライアント装置（NC）２０（スマートフォンやタブレット型コンピュータ等の一般エンドデバイス）のブラウザ２１２で、あるスクリプト（Web API）を立ち上げると、放送サービスに対応するサーバであるゲートウェイ装置１０を発見し、そこで稼働するローカルプロキシ１１３のプロキシ待ち受けアドレス/ポートを、当該ブラウザ２１２のプロキシとして設定できるようにする。
　以下、このような、ゲートウェイ装置１０で稼働するローカルプロキシ１１３の発見と、ローカルプロキシ１１３のプロキシ待ち受けアドレス/ポートの取得のシーケンス（プロキシの発見・接続処理）を、上述したHTTPリクエストヘッダの拡張のシーケンス（拡張ヘッダ挿入処理）とあわせて説明する。
　なお、ここでは、ネットワーク上のデバイスの探索や応答を行うプロトコルとして、SSDPを一例に説明したが、DIAL(Discovery and Launch)等の他のプロトコルを用いることでも、同様の機能を実現することができる。DIALは、ネットワーク上にあるDIAL対応のデバイスをUPnPにより発見し、指定されたアプリケーションを起動させるプロトコルである。
＜５．プロキシの発見・接続処理と、拡張ヘッダ挿入処理の流れ＞
（プロキシの発見・接続処理と、拡張ヘッダ挿入処理）
　図１７及び図１８のフローチャートを参照して、プロキシの発見・接続処理と、拡張ヘッダ挿入処理の一連の流れを説明する。
　ただし、図１７及び図１８の説明では、図１９乃至図２６に示したリクエストやレスポンス等のメッセージの内容を適宜参照しながら説明するものとする。
　また、図１７及び図１８の説明では、ネットワーク３０に接続されるゲートウェイ装置１０には、IPアドレスとして、"192.168.1.1"が割り当てられているものとする。また、このゲートウェイ装置１０で稼働するサービスのうち、UPnP/SSDPサーバ１１１には、"12345"であるポート番号、プロキシアプリマネージャ１１２には、"23456"であるポート番号、ローカルプロキシ１１３には、"34567"であるポート番号がそれぞれ割り当てられているものとする。
　なお、図１７及び図１８において、ステップＳ１０１乃至Ｓ１０２の処理と、ステップＳ１１１の処理と、ステップＳ１２１乃至Ｓ１２３の処理は、ゲートウェイ装置１０により実行される。一方で、ステップＳ２０１乃至Ｓ２０４の処理と、ステップＳ２１１乃至Ｓ２１２の処理は、クライアント装置２０により実行される。
　図１７のステップＳ２０１において、アプリケーション２１１は、ゲートウェイ装置１０で稼働するローカルプロキシ１１３の存在を確認するために、通信I/F２０１を介して、ネットワーク３０に接続されたデバイス（サーバ）に対し、M-SEARCHリクエストを、マルチキャストで送信する。
　図１９は、M-SEARCHリクエストの例を示す図である。
　M-SEARCHリクエストには、マルチキャストのIPアドレスとして、"239.255.255.250"が指定され、ポート番号として、"1900"が指定される。
　また、上述したように、UPnPのプロトコルとして、SSDPを用いるので、MANには、"ssdp:discover"が指定される。さらに、探索の対象が、ATSC3.0に対応したプロキシであるローカルプロキシ１１３となるので、STには、"urn:atsc:proxy"が指定される。
　図１７に戻り、ステップＳ２０１の処理で、クライアント装置２０により送信されるM-SEARCHリクエストは、ネットワーク３０に接続されたゲートウェイ装置１０により受信される。
　ステップＳ１０１において、UPnP/SSDPサーバ１１１は、クライアント装置２０から受信したM-SEARCHリクエストに応じて、デバイスディスクリプションURLを生成し、M-SEARCHレスポンスとして、ネットワーク３０を介してクライアント装置２０に送信する。
　図２０は、M-SEARCHレスポンスの例を示す図である。
　M-SEARCHレスポンスにおいて、LOCATIONには、デバイスディスクリプションURLとして、"http://192.168.1.1:12345/deviceDescription.xml"が指定される。このデバイスディスクリプションURLは、XML形式のファイルのURLであって、このファイルは、ゲートウェイ装置１０で稼働するローカルウェブサーバが処理する。
　すなわち、ゲートウェイ装置１０においては、UPnP/SSDPサーバ１１１がローカルウェブサーバとしての機能を有しているので、デバイスディスクリプションURLには、ゲートウェイ装置１０に割り当てられたIPアドレスである"192.168.1.1"と、ローカルウェブサーバとしてのUPnP/SSDPサーバ１１１に割り当てられたポート番号である"12345"が記述される。
　図１７に戻り、ステップＳ１０１の処理で、ゲートウェイ装置１０により送信されるM-SEARCHレスポンスは、M-SEARCHリクエストを送信したクライアント装置２０により受信される。
　ステップＳ２０２において、アプリケーション２１１は、ゲートウェイ装置１０から受信したM-SEARCHレスポンス（のデバイスディスクリプションURL）に基づいて、ネットワーク３０に接続されたゲートウェイ装置１０で稼働するUPnP/SSDPサーバ１１１に対し、デバイスディスクリプションを要求する。
　図２１は、デバイスディスクリプションリクエストの例を示す図である。
　デバイスディスクリプションリクエストには、GETメソッドの対象のリソースとして、"deviceDescripion.xml"であるデバイスディスクリプションが記述される。また、HOSTには、ホスト名として、"192.168.1.1:12345"が記述される。
　すなわち、デバイスディスクリプションリクエストでは、M-SEARCHレスポンスに記述された内容に応じて、GETメソッドの対象のリソースが、"deviceDescripion.xml"となる。さらに、デバイスディスクリプションリクエストには、HOSTとして、"192.168.1.1"であるゲートウェイ装置１０のIPアドレスと、"12345"であるUPnP/SSDPサーバ１１１（ローカルウェブサーバ）のポート番号とが記述される。
　図１７に戻り、ステップＳ２０２の処理で、クライアント装置２０により送信されるデバイスディスクリプションリクエストは、ネットワーク３０に接続されたゲートウェイ装置１０により受信される。
　ステップＳ１０２において、UPnP/SSDPサーバ１１１（ローカルウェブサーバ）は、クライアント装置２０から受信したデバイスディスクリプションリクエストに応じて、デバイスディスクリプションを生成し、レスポンスとして、ネットワーク３０を介してクライアント装置２０に送信する。
　図２２及び図２３は、デバイスディスクリプションレスポンスの例を示す図である。
　デバイスディスクリプションレスポンスのヘッダには、図２２に示すように、ファイルのタイプ等が指定される。また、図２３には、XML形式のデバイスディスクリプションの内容が示されている。
　すなわち、図２３のデバイスディスクリプションには、root要素のxmlns属性として、"urn:schemas-upnp-org:device-1-0"が記述され、UPnP準拠のデバイスディスクリプションであることが宣言されている。
　serviceList要素には、ゲートウェイ装置１０でサポートされるサービスの一覧が記述される。serviceList要素には、１又は複数のservice要素が記述される。
　service要素には、サポートされるサービスのうち、１つのサービスについての情報が記述される。service要素は、serviceType要素、serviceId要素、SCPDURL要素、及びcontrolURL要素などの上位要素となる。
　serviceType要素には、サービスのタイプとして、"urn:atsc:proxy"が記述され、ATSC3.0サービスのプロキシサービスであることを意味している。
　serviceId要素には、サービスIDとして、"urn:UPnP:serviceId:1234"が記述され、プロキシサービスのサービスIDを表している。
　controlURL要素には、プロキシ待ち受けアドレス/ポート取得Web APIのURLとして、"http://192.168.1.1:23456/getATSC3.0ProxyAddressPort"が記述される。このURLは、ローカルプロキシ１１３がリクエストを待ち受けるIPアドレスとポート番号を示すプロキシ待ち受けアドレス/ポートを取得するためのWeb APIを呼び出すための情報である。
　ここで、通常、SCPDURL要素には、ACRクライアントサービスについてのサービスディスクリプションのアドレスが記述されるので、HTTPで規定されるGETメソッドにより、サービスディスクリプションが取得される。その場合には、UPnPで規定されるSOAP(Simple Object Access Protocol)により、controlURL要素に記述されるURLに対し、アクションのメッセージを送付することで、アクションを呼び出すことになる。
　一方で、本技術では、より簡便にWeb APIを呼び出せるように、UPnPの規定とは異なる方法で、Web APIのURLを周知する方法を提案する。すなわち、本技術では、図２３に示すように、SCPDURL要素の値としては何も記述せずに（SCPDURL要素の中身は空にしておき）、SCPDURL要素に何も記述されていない場合に限り、controlURL要素に、直接、Web APIのURLを記述できるようにしている。
　なお、controlURL要素に、直接、Web APIのURLを記述するための条件としては、上述したような、SCPDURL要素の中身を空にするほか、例えば、controlURL要素に、ダミーの文字列を記述するようにしてもよい。
　図１７に戻り、ステップＳ１０２の処理で、ゲートウェイ装置１０により送信されるデバイスディスクリプションレスポンスは、デバイスディスクリプションリクエストを送信したクライアント装置２０により受信される。
　ステップＳ２０３において、アプリケーション２１１は、ゲートウェイ装置１０から受信したデバイスディスクリプションレスポンス（のプロキシ待ち受けアドレス/ポート取得Web APIのURL）に基づいて、ネットワーク３０に接続されたゲートウェイ装置１０で稼働するプロキシアプリマネージャ１１２に対し、プロキシ待ち受けアドレス/ポートを要求する。
　図２４は、プロキシ待ち受けアドレス/ポートリクエストの例を示す図である。
　プロキシ待ち受けアドレス/ポートリクエストには、GETメソッドの対象のリソースとして、"getATSC3.0ProxyAddressPort"である対象のプロキシ待ち受けアドレス/ポートが記述される。また、HOSTには、ホスト名として、"192.168.1.1:23456"が記述される。
　すなわち、プロキシ待ち受けアドレス/ポートリクエストでは、デバイスディスクリプションレスポンスに記述された内容（controlURL要素の内容）に応じて、GETメソッドの対象が、"getATSC3.0ProxyAddressPort"となる。さらに、プロキシ待ち受けアドレス/ポートリクエストには、HOSTとして、"192.168.1.1"であるゲートウェイ装置１０のIPアドレスと、"23456"であるプロキシアプリマネージャ１１２のポート番号が記述される。
　図１７に戻り、ステップＳ２０３の処理で、クライアント装置２０により送信されるプロキシ待ち受けアドレス/ポートリクエストは、ネットワーク３０に接続されたゲートウェイ装置１０により受信される。
　ステップＳ１１１において、プロキシアプリマネージャ１１２は、クライアント装置２０から受信したプロキシ待ち受けアドレス/ポートリクエストに応じて、プロキシ待ち受けアドレス/ポートを生成し、レスポンスとして、ネットワーク３０を介してクライアント装置２０に送信する。
　図２５は、プロキシ待ち受けアドレス/ポートレスポンスの例を示す図である。
　プロキシ待ち受けアドレス/ポートレスポンスのボディ部には、プロキシ待ち受けアドレス/ポートとして、"192.168.1.1:34567"が記述されている。
　すなわち、ゲートウェイ装置１０において、ローカルプロキシ１１３がプロキシサーバとしての機能を有しているので、当該レスポンスのボディ部には、ゲートウェイ装置１０に割り当てられたIPアドレスである"192.168.1.1"と、ローカルプロキシ１１３に割り当てられたポート番号である"34567"が記述される。
　なお、この例では、Web APIへのリクエスト（プロキシ待ち受けアドレス/ポートリクエスト）を受け取るのが、プロキシアプリマネージャ１１２であるとして説明しているが、ローカルプロキシ１１３本体が、当該リクエストを受け取って、処理するようにしてもよい。
　図１７に戻り、ステップＳ１１１の処理で、ゲートウェイ装置１０により送信されるプロキシ待ち受けアドレス/ポートレスポンスは、プロキシ待ち受けアドレス/ポートリクエストを送信したクライアント装置２０により受信される。
　図１８のステップＳ２０４において、アプリケーション２１１は、ゲートウェイ装置１０から受信したプロキシ待ち受けアドレス/ポートレスポンス（のIPアドレスとポート番号）に基づいて、プロキシ自動構成スクリプトの更新と、ブラウザ２１２の起動（再起動）による構成変更の反映を行う。
　すなわち、クライアント装置２０において、アプリケーション２１１は、プロキシ待ち受けアドレス/ポートレスポンスから、プロキシ待ち受けアドレス/ポートとして得られるIPアドレスとポート番号（ATSC3.0ProxyAddressPort(192.168.1.1:34567)）により、プロキシ自動構成スクリプトファイルを書き換える。
　図２６は、プロキシ自動構成スクリプトファイルの例を示す図である。
　プロキシ自動構成スクリプトファイルは、スクリプト言語として、JavaScript（登録商標）を用いて記述することができる。
　図２６においては、FindProxyForURL関数が定義され、その引数として、url，hostが指定可能である。FindProxyForURL関数においては、条件分岐のelse文に、"PROXY 192.168.1.1:34567; DIRECT"、すなわち、プロキシ待ち受けアドレス/ポートが記述されている。つまり、"192.168.1.1"は、ゲートウェイ装置１０に割り当てられたIPアドレスであり、"34567"は、ローカルプロキシ１１３に割り当てられたポート番号である。
　このFindProxyForURL関数によって、サブネット内の特定のホストは直接外部と接続し、それ以外のホストは、ゲートウェイ装置１０で稼働するローカルプロキシ１１３を介して、外部に接続することになる。ただし、ここでのホストには、クライアント装置２０が含まれる。
　すなわち、クライアント装置２０では、アプリケーション２１１により、プロキシ自動構成スクリプトファイルが、プロキシ待ち受けアドレス/ポートにより書き換えられ、ブラウザ２１２が、起動（再起動）される。そして、当該ブラウザ２１２が参照するプロキシ自動構成スクリプトファイルにより、プロキシのIPアドレスとポート番号の設定（自動設定）が行われる。
　これにより、クライアント装置２０において、ブラウザ２１２は、ネットワーク３０を介して、ゲートウェイ装置１０で稼働するローカルプロキシ１１３にアクセスすることが可能となる。
　ステップＳ２１１において、ブラウザ２１２は、放送サービスをサービスエントリとして、通信経由で、コンテンツの配信を受けるタイミングになった場合、DASHセグメントを、ネットワーク３０を介して、ゲートウェイ装置１０で稼働するローカルプロキシ１１３に要求する。
　すなわち、ブラウザ２１２は、コンテンツのDASHセグメントを再生するDASHプレーヤとしての機能を有しており、一般クライアント装置２０（NC）のブラウザ２１２（DASHプレーヤ）からのリクエスト（例えば、"http(s)://a.com/a.mp4"であるセグメントURLのDASHセグメントファイルのHTTPリクエスト）は、すべて、ローカルプロキシ１１３を経由することになる。
　ステップＳ２１１の処理で、クライアント装置２０により送信される、DASHセグメントのHTTPリクエストは、ゲートウェイ装置１０で稼働するローカルプロキシ１１３により受信される。
　ステップＳ１２１において、ローカルプロキシ１１３は、クライアント装置２０から受信したHTTPリクエストに対し、拡張ヘッダを挿入する。
　すなわち、ローカルプロキシ１１３は、トランスペアレントプロキシとしての機能を有し、拡張ヘッダ挿入処理を行うことで、クライアント装置２０からのHTTPリクエストに対し、コンテンツのソースの同一性を識別するためのソース識別情報（ソース同一性を識別する識別子）を挿入する。この拡張ヘッダ処理で挿入されるソース識別情報として、例えば、ATSC3.0サービスの場合には、サービスIDやコンテンツID、MPDメタデータのURL、時刻情報などを含めることができるのは、先に述べた通りである。
　なお、ATSC3.0サービスに対応した拡張ヘッダ挿入処理においては、トラップしたDASHセグメントファイルのHTTPリクエストに対して、拡張ヘッダを挿入する前に、あらかじめ生成されたマッピングデータベースを参照することで、当該HTTPリクエスト（のURL）が、ATSC3.0サービスで配信されたMPDメタデータに記述されたセグメントURLであるかどうかを確認する処理が行われる。この処理の詳細は、図２７のフローチャートを参照して、後述する。
　ステップＳ１２２において、ローカルプロキシ１１３は、ステップＳ１２１の処理（拡張ヘッダ挿入処理）で得られるHTTPリクエストを、通信I/F１０２を介して、インターネット８０に接続された通信サーバ７０に送信する。
　なお、詳細は、図２８を参照して後述するが、通信サーバ７０は、インターネット８０を介してゲートウェイ装置１０から送信されてくるHTTPリクエストを受信する。また、通信サーバ７０は、受信したHTTPリクエストに基づいて、DASHセグメントファイルを、インターネット８０を介して、ゲートウェイ装置１０に送信する。
　ここで、通信サーバ７０は、ゲートウェイ装置１０から受信したHTTPリクエストヘッダに、サービスIDやコンテンツID、MPDメタデータのURL、時刻情報などのソース識別情報が挿入されているため、当該ソース識別情報を確認することで、HTTPリクエストが、ATSC3.0サービスを導線として要求されたリクエストであることを認識することができる。
　通信サーバ７０により送信されるDASHセグメントファイルは、インターネット８０に接続されたゲートウェイ装置１０により受信される。
　ステップＳ１２３において、ローカルプロキシ１１３は、通信サーバ７０から受信したDASHセグメントファイルを、通信I/F１０３を介して、ネットワーク３０に接続されたクライアント装置２０に転送する。
　ステップＳ１２３の処理で、ゲートウェイ装置１０により転送されるDASHセグメントファイルは、ネットワーク３０に接続されたクライアント装置２０により受信される。
　ステップＳ２１２において、ブラウザ２１２は、ゲートウェイ装置１０から受信したDASHセグメントファイルを処理し、DASHプレーヤによるDASHセグメントファイルの再生を行う。これにより、クライアント装置２０においては、通信経由で配信された番組等のコンテンツが再生されることになる。
　以上、プロキシの発見・接続処理と、拡張ヘッダ挿入処理の一連の流れを説明した。
（拡張ヘッダ挿入処理の詳細）
　次に、図２７のフローチャートを参照して、拡張ヘッダ挿入処理の詳細を説明する。
　図２７のフローチャートに示した処理は、図１７及び図１８のプロキシの発見・接続処理と、拡張ヘッダ挿入処理のうち、拡張ヘッダ挿入処理に相当する処理であって、図１８のステップＳ１２１乃至Ｓ１２３の処理と、ステップＳ２１１乃至Ｓ２１２の処理に対応している。
　なお、図２７において、ステップＳ１５１乃至Ｓ１５４の処理と、ステップＳ１６１乃至Ｓ１６４の処理は、ゲートウェイ装置１０により実行される。また、ステップＳ２５１乃至Ｓ２５２の処理は、クライアント装置２０により実行される。
　ゲートウェイ装置１０においては、クライアント装置２０からのHTTPリクエストに対する拡張ヘッダ挿入処理に先立って、ステップＳ１５１乃至Ｓ１５３の処理が実行され、SLS処理系１１４によって、マッピングデータベースが生成され、記憶部１０４に記憶される。
　具体的には、ステップＳ１５１において、SLS処理系１１４は、多重化ストリームから、ROUTEセッションで伝送されるSLSを抽出する。
　ステップＳ１５２において、SLS処理系１１４は、ステップＳ１５１の処理で得られたSLSをパースする。
　ここでは、USBDメタデータとMPDメタデータが解析され、USBDメタデータのglobalServiceID属性により記述されるサービスID及びfullMPDUri属性により指定されるURI（MPDメタデータのURL）、並びにMPDメタデータに記述されるコンテンツID（EIDRやAd-ID）及びセグメントURLが得られる。
　ステップＳ１５３において、SLS処理系１１４は、ステップＳ１５２の処理で得られた解析結果に基づいて、マッピングデータベースを生成する。このマッピングデータベースは、記憶部１０４に記憶される。
　このマッピングデータベースは、クライアント装置２０からのHTTPリクエストに含まれるURLが、ATSC3.0サービスのどのサービスのDASHセグメントに対応するものなのかを解決するためのデータベースとなる。
　具体的には、マッピングデータベースでは、セグメントURLを主キーとして、サービスID、コンテンツID、MPDメタデータのURL、及び時刻情報が対応付けられている。すなわち、このマッピングデータベースは、セグメントURLと、ソース識別情報との対応関係を格納している。なお、主キーとしては、セグメントURLに限らず、例えば、MPDメタデータのBaseURL要素により指定されるベースURLなど、URLの最初のパートにマッチする文字列を用いるようにしてもよい。
　このマッピングデータベースによって、SLS処理系１１４は、クライアント装置２０からのHTTPリクエストのURLに応じた属性（ソース識別情報）を、ローカルプロキシ１１３に提供することができる。換言すれば、拡張ヘッダ挿入処理を行うに際し、このマッピングデータベースを参照することで、拡張ヘッダを挿入する前に、対象のHTTPリクエストのURLが、ATSC3.0サービスで配信されたMPDメタデータに記述されたセグメントURLであるかどうかを確認することができる。
　ここで、クライアント装置２０において、放送サービスをサービスエントリとして、通信経由で、コンテンツの配信を受けるタイミングになった場合、ブラウザ２１２は、DASHセグメントを、ネットワーク３０を介して、ゲートウェイ装置１０で稼働するローカルプロキシ１１３に要求する（Ｓ２５１）。
　ステップＳ２５１の処理で、クライアント装置２０により送信されるDASHセグメントのHTTPリクエストは、ゲートウェイ装置１０で稼働するローカルプロキシ１１３により受信される。
　ステップＳ１６１において、ローカルプロキシ１１３は、クライアント装置２０から受信したHTTPリクエストヘッダのURLによる照会を、SLS処理系１１４に要求する。
　ステップＳ１５４において、SLS処理系１１４は、ローカルプロキシ１１３からのHTTPリクエストヘッダのURLによる照会に応じて、記憶部１０４に記憶されたマッピングデータベースを参照し、当該HTTPリクエストのURLに対応する属性（ソース識別情報）を返答する。
　ここで、マッピングデータベースには、セグメントURLを主キーとして、サービスID、コンテンツID、MPDメタデータのURL、及び時刻情報などのソース識別情報が格納されているので、クライアント装置２０からのHTTPリクエストのURLに対応するセグメントURLに対応付けられたソース識別情報が取得され、当該HTTPリクエストヘッダのURLに対応する属性として返答される。
　ステップＳ１６２において、ローカルプロキシ１１３は、クライアント装置２０から受信したHTTPリクエストヘッダに対し、拡張ヘッダとして、SLS処理系１１４から返答された属性（ソース識別情報）を挿入する。これにより、図１６に示したように、HTTPリクエストヘッダには、サービスID、コンテンツID、MPDメタデータのURL、及び時刻情報などのソース識別情報が挿入されることになる。
　ステップＳ１６３において、ローカルプロキシ１１３は、拡張ヘッダが挿入されたHTTPリクエストを、通信I/F１０２を介して、インターネット８０に接続された通信サーバ７０に送信する。
　なお、通信サーバ７０で行われる処理の詳細は、図２８を参照して後述するが、簡単に説明すると、次のようになる。すなわち、通信サーバ７０は、インターネット８０を介してゲートウェイ装置１０から送信されてくるHTTPリクエストを受信する。そして、通信サーバ７０は、受信したHTTPリクエストに応じたDASHセグメントファイルを、インターネット８０を介して、ゲートウェイ装置１０に送信する。
　通信サーバ７０により送信されるDASHセグメントファイルは、インターネット８０に接続されたゲートウェイ装置１０により受信される。
　ステップＳ１６４において、ローカルプロキシ１１３は、通信サーバ７０から受信したDASHセグメントファイルを、通信I/F１０３を介して、ネットワーク３０に接続されたクライアント装置２０に転送する。
　ステップＳ１６４の処理で、ゲートウェイ装置１０により転送されるDASHセグメントファイルは、ネットワーク３０に接続されたクライアント装置２０により受信される。
　クライアント装置２０では、ブラウザ２１２によって、ゲートウェイ装置１０から受信したDASHセグメントファイルが再生される（Ｓ２５２）。これにより、クライアント装置２０においては、通信経由で配信された番組等のコンテンツが再生されることになる。
　以上、拡張ヘッダ挿入処理の詳細を説明した。
　この拡張ヘッダ挿入処理では、ゲートウェイ装置１０で稼働するローカルプロキシ１１３によって、クライアント装置２０からのHTTPリクエストに、拡張ヘッダ（ソース識別情報）が挿入されるため、容易に、HTTPリクエストヘッダに対し、ソース識別情報を追加することができる。すなわち、このような特殊なヘッダを、HTTPリクエストに追加する処理は、一般のDASHプレーヤ（ブラウザ２１２）の実装に、容易に加えることはできないが、HTTPリクエストが、ローカルプロキシ１１３を経由するようにすることで、拡張ヘッダ挿入処理を、ローカルプロキシ１１３上のモジュールやサーバサイドスクリプトなどによって、容易に実装することができる。
（HTTPリクエスト対応処理）
　次に、図２８のフローチャートを参照して、通信サーバ７０により実行されるHTTPリクエスト対応処理の流れを説明する。
　図２８のフローチャートに示した処理は、図１７及び図１８のプロキシの発見・接続処理と、拡張ヘッダ挿入処理における、ステップＳ１２２の処理（ローカルプロキシ１１３のHTTPリクエスト転送処理）に対応する処理、あるいは、図２７の拡張ヘッダ挿入処理におけるステップＳ１６３の処理（ローカルプロキシ１１３のHTTPリクエスト転送処理）に対応する処理となる。
　ステップＳ３０１において、通信サーバ７０は、インターネット８０を介してゲートウェイ装置１０（のローカルプロキシ１１３）から送信されてくるHTTPリクエストを受信する。
　ステップＳ３０２において、通信サーバ７０は、ステップＳ３０１の処理で得られたHTTPリクエストを処理する。
　ここで、HTTPリクエストヘッダには、サービスIDやコンテンツID、MPDメタデータのURL、時刻情報などのソース識別情報が挿入されている。通信サーバ７０は、HTTPリクエストヘッダに挿入されたソース識別情報に基づいて、当該HTTPリクエストが、放送サービスを導線として要求されたリクエストであることを認識することができる。
　すなわち、ゲートウェイ装置１０からのHTTPリクエストに、拡張ヘッダとしてのソース識別情報が挿入されていない場合、通信サーバ７０においては、例えば、"http(s)://a.com/a.mp4"であるセグメントURLのDASHセグメントファイルのHTTPリクエストが、ATSC3.0サービス等の放送サービスを導線（サービスエントリ）としたものかどうかを認識することはできない。
　一方で、ゲートウェイ装置１０からのHTTPリクエストに、拡張ヘッダとしてのソース識別情報が挿入されている場合、通信サーバ７０は、サービスIDやコンテンツID、MPDメタデータのURL、時刻情報などから、当該HTTPリクエストが、ATSC3.0サービス等の放送サービスを導線（サービスエントリ）としたものかどうかを認識することが可能となる。
　例えば、放送と通信を利用したサイマル放送を行う場合や、放送と通信でそれぞれ伝送されるストリームを結合して得られるコンテンツの配信を行う場合などの、放送と通信を利用したサービスの運用を行う場合に、クライアント装置２０では、放送サービスをサービスエントリとして、通信経由で、コンテンツの配信を受けるタイミングが生じるときがある。そして、このような場合において、放送事業者等の事業者から、放送サービスを導線（サービスエントリ）として、通信経由でアクセスしてくるクライアント装置２０を識別したいという要請があるが、その要請に応えることができる。例えば、放送事業者は、ATSC3.0エンドデバイスと一般エンドデバイスとを区別して、アクセスの統計を管理する運用を、容易に行うことができる。
　また、ここでは、通信サーバ７０が、CDNのサーバとして提供されるようにすることで、通信サーバ７０によって、コンテンツのデータ（DASHセグメントファイル）の配信が行われるときに、既存のCDNのロギングの機能を利用して、DASHセグメントのアクセス統計を記録するという運用が可能となる。さらに、通信サーバ７０が、既存のCDNの機能を利用することで、追加コストを最小限に抑えることができる。さらに、例えば、同一のコンテンツを、異なるCDNのサーバから、配信元のパスを変えて配信する運用を行う場合に、同一のコンテンツから生成されたDASHセグメントのシーケンスを、容易に類推することができる。
　なお、上記の「放送と通信でそれぞれ伝送されるストリームを結合して得られるコンテンツの配信を行う」運用とは、例えば、放送経由で、ベースレイヤとして、低品質なビデオストリームを配信するとともに、通信経由で、エンハンスメントレイヤとして、ベースレイヤとしてのビデオストリームを強化するための付加情報（エンハンスのビデオストリーム）を配信するような運用が相当する。これにより、クライアント装置２０では、ベースレイヤに対応した通常品質の映像（例えば２Ｋ解像度の映像）を再生するだけでなく、ベースレイヤとエンハンスメントレイヤを結合して得られる高品質の映像（例えば４Ｋ解像度の映像）を再生するが可能となる。
　ステップＳ３０３において、通信サーバ７０は、ステップＳ３０１の処理で得られたHTTPリクエストに応じたDASHセグメントファイルを、インターネット８０を介してゲートウェイ装置１０に送信する。
　以上、通信サーバ７０側のHTTPリクエスト対応処理の流れを説明した。
＜６．変形例＞
（他の放送規格への適用）
　上述した説明としては、デジタル放送の規格として、米国等で採用されている方式であるATSC（特に、ATSC3.0）を説明したが、本技術は、日本等が採用する方式であるISDBや、欧州の各国等が採用する方式であるDVBなどに適用するようにしてもよい。また、上述した説明では、IP伝送方式が採用されるATSC3.0を例にして説明したが、IP伝送方式に限らず、例えば、MPEG2-TS(Transport Stream)方式等の他の方式に適用するようにしてもよい。
　また、デジタル放送の規格としては、地上波放送のほか、放送衛星（BS：Broadcasting Satellite)や通信衛星（CS：Communications Satellite）等を利用した衛星放送や、ケーブルテレビ（CATV）等の有線放送などの規格に適用することができる。
（その他の変形例）
　また、上述した制御情報（シグナリング）などの名称は、一例であって、他の名称が用いられる場合がある。ただし、これらの名称の違いは、形式的な違いであって、対象の制御情報やパケットなどの実質的な内容が異なるものではない。例えば、USBD(User Service Bundle Description)は、USD(User Service Description)と称される場合がある。また、例えば、NRT(Non Real Time)は、LCC(Locally Cached Content)などと称される場合がある。
　また、制御情報が、XML等のマークアップ言語により記述される場合において、それらの要素や属性の名称は一例であって、他の名称が採用されるようにしてもよい。ただし、これらの名称の違いは、形式的な違いであって、それらの要素や属性の実質的な内容が異なるものではない。
　また、DASHプレーヤは、例えば、HTML5(HyperText Markup Language 5)などのマークアップ言語やJavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションのほか、例えば、Java（登録商標）などのプログラミング言語で開発されたアプリケーションとすることができる。また、このアプリケーションは、ブラウザにより実行されるアプリケーションに限らず、いわゆるネイティブアプリケーションとして、オペレーティングシステム（OS：Operating System）環境などで実行されるようにしてもよい。
　なお、アプリケーションは、何らかの情報を明示的に表示するだけでなく、非表示で（バックグラウンドで）動作されるようにしてもよい（エンドユーザに認識されずに起動するようにしてもよい）。また、コンテンツは、動画や音楽のほか、例えば、電子書籍やゲーム、広告など、あらゆるコンテンツを含めることができる。
＜７．コンピュータの構成＞
　上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図２９は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
　コンピュータ１０００において、CPU(Central Processing Unit)１００１、ROM(Read Only Memory)１００２、RAM(Random Access Memory)１００３は、バス１００４により相互に接続されている。バス１００４には、さらに、入出力インターフェース１００５が接続されている。入出力インターフェース１００５には、入力部１００６、出力部１００７、記録部１００８、通信部１００９、及び、ドライブ１０１０が接続されている。
　入力部１００６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１００７は、ディスプレイ、スピーカなどよりなる。記録部１００８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１００９は、ネットワークインターフェースなどよりなる。ドライブ１０１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブル記録媒体１０１１を駆動する。
　以上のように構成されるコンピュータ１０００では、CPU１００１が、ROM１００２や記録部１００８に記録されているプログラムを、入出力インターフェース１００５及びバス１００４を介して、RAM１００３にロードして実行することにより、上述した一連の処理が行われる。
　コンピュータ１０００（CPU１００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体１０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
　コンピュータ１０００では、プログラムは、リムーバブル記録媒体１０１１をドライブ１０１０に装着することにより、入出力インターフェース１００５を介して、記録部１００８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部１００９で受信し、記録部１００８にインストールすることができる。その他、プログラムは、ROM１００２や記録部１００８に、あらかじめインストールしておくことができる。
　ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
　なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
　また、本技術は、以下のような構成をとることができる。
（１）
　コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入する処理部を備える
　情報処理装置。
（２）
　前記処理部は、放送サービスをサービスエントリとして、通信経由で、前記リクエストが送信される場合に、前記リクエストに対し、前記識別情報を挿入する
　（１）に記載の情報処理装置。
（３）
　前記識別情報は、前記コンテンツの配信元を識別するための情報である
　（１）又は（２）に記載の情報処理装置。
（４）
　前記識別情報は、前記放送サービスを識別する識別子を少なくとも含む
　（３）に記載の情報処理装置。
（５）
　前記識別情報は、前記コンテンツを識別する識別子、前記コンテンツの再生を制御する制御情報の取得先を示す情報、及び前記コンテンツに関する時刻情報のうち、少なくとも１つの情報をさらに含む
　（４）に記載の情報処理装置。
（６）
　前記処理部は、プロキシとしての機能を有する
　（１）乃至（５）のいずれかに記載の情報処理装置。
（７）
　放送波を受信する受信部と、
　インターネット上のサーバと通信を行う通信部と
　をさらに備え、
　前記処理部は、
　　前記放送波から得られる制御情報に基づいて、前記識別情報を格納したマッピングデータベースを生成し、
　　HTTP(Hypertext Transfer Protocol)リクエストを、前記サーバに送信する場合、前記マッピングデータベースから得られる前記識別情報を、前記HTTPリクエストのリクエストヘッダに挿入し、
　前記通信部は、前記HTTPリクエストを、前記インターネットを介して、前記サーバに送信する
　（６）に記載の情報処理装置。
（８）
　前記情報処理装置は、ネットワークに接続されたクライアント装置に対し、放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置であり、
　前記処理部は、前記クライアント装置からのHTTPリクエストを、前記サーバに送信する場合、前記HTTPリクエストのリクエストヘッダに、前記識別情報を挿入する
　（７）に記載の情報処理装置。
（９）
　前記情報処理装置は、放送経由又は通信経由で配信されるコンテンツを再生するクライアント装置であり、
　前記処理部は、前記クライアント装置からのHTTPリクエスト、又はネットワークに接続された他のクライアント装置からのHTTPリクエストを、前記サーバに送信する場合、前記HTTPリクエストのリクエストヘッダに、前記識別情報を挿入する
　（７）に記載の情報処理装置。
（１０）
　前記処理部は、前記クライアント装置との接続を確立する場合に、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報を、前記クライアント装置に提供する
　（８）に記載の情報処理装置。
（１１）
　前記クライアント装置は、前記プロキシの構成を設定するためのスクリプトファイルの内容を、前記接続情報により書き換え、当該スクリプトファイルを実行することで、前記プロキシとの接続を確立する
　（１０）に記載の情報処理装置。
（１２）
　前記処理部は、前記クライアント装置により、前記接続情報を取得するためのAPI(Application Programming Interface)が実行された場合に、前記接続情報を、前記クライアント装置に提供する
　（１１）に記載の情報処理装置。
（１３）
　前記リクエストは、セキュアなプロトコルを用いて通信が行われ、
　前記プロキシは、透過型のプロキシ（Transparent Proxy）である
　（６）乃至（１２）のいずれかに記載の情報処理装置。
（１４）
　情報処理装置のデータ処理方法において、
　前記情報処理装置が、
　コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入するステップを含む
　データ処理方法。
（１５）
　放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置との接続を処理する処理部と、
　前記ゲートウェイ装置から、ネットワークを介して転送されてくる前記コンテンツを再生する再生部と
　を備え、
　前記ゲートウェイ装置は、プロキシとしての機能を有し、
　前記処理部は、前記ゲートウェイ装置から前記ネットワークを介して提供される、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報に基づいて、前記プロキシとの接続を確立する
　クライアント装置。
（１６）
　前記処理部は、前記プロキシの構成を設定するためのスクリプトファイルの内容を、前記接続情報により書き換え、当該スクリプトファイルを実行することで、前記プロキシとの接続を確立する
　（１５）に記載のクライアント装置。
（１７）
　前記処理部は、前記ゲートウェイ装置から前記ネットワークを介して提供される、前記接続情報を取得するためのAPIを実行することで、前記接続情報を取得する
　（１６）に記載のクライアント装置。
（１８）
　前記プロキシは、前記クライアント装置からのコンテンツのリクエストを、インターネット上のサーバに送信する場合、前記リクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入する
　（１７）に記載のクライアント装置。
（１９）
　前記プロキシは、放送サービスをサービスエントリとして、通信経由で、前記リクエストが送信される場合に、前記リクエストに対し、前記識別情報を挿入する
　（１８）に記載のクライアント装置。
（２０）
　クライアント装置のデータ処理方法において、
　前記クライアント装置が、
　放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置との接続を確立する場合に、プロキシとしての機能を有する前記ゲートウェイ装置からネットワークを介して提供される、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報に基づいて、前記プロキシとの接続を確立し、
　前記ゲートウェイ装置から、前記ネットワークを介して転送されてくる前記コンテンツを再生する
　ステップを含むデータ処理方法。
　１　伝送システム，　１０　ゲートウェイ装置，　２０－１乃至２０－Ｎ，２０　クライアント装置，　３０　ネットワーク，　４０　放送サーバ，　５０　送信所，　６０　放送伝送路，　７０　通信サーバ，　８０　インターネット，　１００　処理部，　１０１　チューナ，　１０２　通信I/F，　１０３　通信I/F，　１０４　記憶部，　１１１　UPnP/SSDPサーバ，　１１２　プロキシアプリマネージャ，　１１３　ローカルプロキシ，　１１４　SLS処理系，　２００　処理部，　２０１　通信I/F，　２０２　表示部，　２０３　スピーカ，　２１１　アプリケーション，　２１２　ブラウザ，　１０００　コンピュータ，　１００１　CPU

Claims (20)

  1. 　コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入する処理部を備える
    　情報処理装置。
  2. 　前記処理部は、放送サービスをサービスエントリとして、通信経由で、前記リクエストが送信される場合に、前記リクエストに対し、前記識別情報を挿入する
    　請求項１に記載の情報処理装置。
  3. 　前記識別情報は、前記コンテンツの配信元を識別するための情報である
    　請求項２に記載の情報処理装置。
  4. 　前記識別情報は、前記放送サービスを識別する識別子を少なくとも含む
    　請求項３に記載の情報処理装置。
  5. 　前記識別情報は、前記コンテンツを識別する識別子、前記コンテンツの再生を制御する制御情報の取得先を示す情報、及び前記コンテンツに関する時刻情報のうち、少なくとも１つの情報をさらに含む
    　請求項４に記載の情報処理装置。
  6. 　前記処理部は、プロキシとしての機能を有する
    　請求項２に記載の情報処理装置。
  7. 　放送波を受信する受信部と、
    　インターネット上のサーバと通信を行う通信部と
    　をさらに備え、
    　前記処理部は、
    　　前記放送波から得られる制御情報に基づいて、前記識別情報を格納したマッピングデータベースを生成し、
    　　HTTP(Hypertext Transfer Protocol)リクエストを、前記サーバに送信する場合、前記マッピングデータベースから得られる前記識別情報を、前記HTTPリクエストのリクエストヘッダに挿入し、
    　前記通信部は、前記HTTPリクエストを、前記インターネットを介して、前記サーバに送信する
    　請求項６に記載の情報処理装置。
  8. 　前記情報処理装置は、ネットワークに接続されたクライアント装置に対し、放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置であり、
    　前記処理部は、前記クライアント装置からのHTTPリクエストを、前記サーバに送信する場合、前記HTTPリクエストのリクエストヘッダに、前記識別情報を挿入する
    　請求項７に記載の情報処理装置。
  9. 　前記情報処理装置は、放送経由又は通信経由で配信されるコンテンツを再生するクライアント装置であり、
    　前記処理部は、前記クライアント装置からのHTTPリクエスト、又はネットワークに接続された他のクライアント装置からのHTTPリクエストを、前記サーバに送信する場合、前記HTTPリクエストのリクエストヘッダに、前記識別情報を挿入する
    　請求項７に記載の情報処理装置。
  10. 　前記処理部は、前記クライアント装置との接続を確立する場合に、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報を、前記クライアント装置に提供する
    　請求項８に記載の情報処理装置。
  11. 　前記クライアント装置は、前記プロキシの構成を設定するためのスクリプトファイルの内容を、前記接続情報により書き換え、当該スクリプトファイルを実行することで、前記プロキシとの接続を確立する
    　請求項１０に記載の情報処理装置。
  12. 　前記処理部は、前記クライアント装置により、前記接続情報を取得するためのAPI(Application Programming Interface)が実行された場合に、前記接続情報を、前記クライアント装置に提供する
    　請求項１１に記載の情報処理装置。
  13. 　前記リクエストは、セキュアなプロトコルを用いて通信が行われ、
    　前記プロキシは、透過型のプロキシ（Transparent Proxy）である
    　請求項６に記載の情報処理装置。
  14. 　情報処理装置のデータ処理方法において、
    　前記情報処理装置が、
    　コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入するステップを含む
    　データ処理方法。
  15. 　放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置との接続を処理する処理部と、
    　前記ゲートウェイ装置から、ネットワークを介して転送されてくる前記コンテンツを再生する再生部と
    　を備え、
    　前記ゲートウェイ装置は、プロキシとしての機能を有し、
    　前記処理部は、前記ゲートウェイ装置から前記ネットワークを介して提供される、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報に基づいて、前記プロキシとの接続を確立する
    　クライアント装置。
  16. 　前記処理部は、前記プロキシの構成を設定するためのスクリプトファイルの内容を、前記接続情報により書き換え、当該スクリプトファイルを実行することで、前記プロキシとの接続を確立する
    　請求項１５に記載のクライアント装置。
  17. 　前記処理部は、前記ゲートウェイ装置から前記ネットワークを介して提供される、前記接続情報を取得するためのAPIを実行することで、前記接続情報を取得する
    　請求項１６に記載のクライアント装置。
  18. 　前記プロキシは、前記クライアント装置からのコンテンツのリクエストを、インターネット上のサーバに送信する場合、前記リクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入する
    　請求項１７に記載のクライアント装置。
  19. 　前記プロキシは、放送サービスをサービスエントリとして、通信経由で、前記リクエストが送信される場合に、前記リクエストに対し、前記識別情報を挿入する
    　請求項１８に記載のクライアント装置。
  20. 　クライアント装置のデータ処理方法において、
    　前記クライアント装置が、
    　放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置との接続を確立する場合に、プロキシとしての機能を有する前記ゲートウェイ装置からネットワークを介して提供される、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報に基づいて、前記プロキシとの接続を確立し、
    　前記ゲートウェイ装置から、前記ネットワークを介して転送されてくる前記コンテンツを再生する
    　ステップを含むデータ処理方法。
PCT/JP2017/028338 2016-08-19 2017-08-04 情報処理装置、クライアント装置、及び、データ処理方法 WO2018034172A1 (ja)

Priority Applications (7)

Application Number Priority Date Filing Date Title
CA3033735A CA3033735A1 (en) 2016-08-19 2017-08-04 Information processing apparatus, client apparatus, and data processing method
MX2019001568A MX2019001568A (es) 2016-08-19 2017-08-04 Aparato de procesamiento de informacion, aparato del cliente y metodo de procesamiento de datos.
KR1020197003080A KR102496890B1 (ko) 2016-08-19 2017-08-04 정보 처리 장치, 클라이언트 장치, 및 데이터 처리 방법
US16/319,558 US20210288735A1 (en) 2016-08-19 2017-08-04 Information processing apparatus, client apparatus, and data processing method
EP17841397.7A EP3503568A4 (en) 2016-08-19 2017-08-04 INFORMATION PROCESSING DEVICE, CLIENT DEVICE AND DATA PROCESSING METHOD
JP2018534344A JPWO2018034172A1 (ja) 2016-08-19 2017-08-04 情報処理装置、クライアント装置、及び、データ処理方法
BR112019002867-6A BR112019002867A2 (pt) 2016-08-19 2017-08-04 aparelho de processamento de informação, método de processamento de dados, e, aparelho cliente.

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016161194 2016-08-19
JP2016-161194 2016-08-19

Publications (1)

Publication Number Publication Date
WO2018034172A1 true WO2018034172A1 (ja) 2018-02-22

Family

ID=61196595

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/028338 WO2018034172A1 (ja) 2016-08-19 2017-08-04 情報処理装置、クライアント装置、及び、データ処理方法

Country Status (8)

Country Link
US (1) US20210288735A1 (ja)
EP (1) EP3503568A4 (ja)
JP (1) JPWO2018034172A1 (ja)
KR (1) KR102496890B1 (ja)
BR (1) BR112019002867A2 (ja)
CA (1) CA3033735A1 (ja)
MX (1) MX2019001568A (ja)
WO (1) WO2018034172A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109672613A (zh) * 2018-12-12 2019-04-23 北京数码视讯软件技术发展有限公司 自适应访问方法、装置及电子设备

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015105391A1 (en) * 2014-01-13 2015-07-16 Lg Electronics Inc. Apparatuses and methods for transmitting or receiving a broadcast content via one or more networks
US11411918B2 (en) * 2020-05-26 2022-08-09 Microsoft Technology Licensing, Llc User interface for web server risk awareness
TWI806632B (zh) * 2022-05-27 2023-06-21 新加坡商聯發科技（新加坡）私人有限公司 影音播放裝置及其影音信號資訊顯示方法
US11876713B1 (en) * 2023-03-13 2024-01-16 Intuit Inc. Client side backoff filter for rate limiting

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002103964A1 (en) * 2001-06-18 2002-12-27 Sony Corporation Data transmission apparatus, data transmission method, and data transmission method program
JP2007110586A (ja) * 2005-10-17 2007-04-26 Nec Corp 映像配信システム、映像配信サーバ、映像配信方法、映像配信プログラム
JP2010527048A (ja) * 2007-03-22 2010-08-05 マイクロソフト コーポレーション 携帯機器のためのリモート・データ・アクセス技術
JP2013080988A (ja) * 2011-09-15 2013-05-02 Toshiba Corp 情報処理装置および情報提供方法
JP2013131882A (ja) * 2011-12-21 2013-07-04 Dainippon Printing Co Ltd 連動情報配信サーバー装置、コンピュータプログラム

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9826502B2 (en) * 2011-07-25 2017-11-21 Qualcomm Incorporated Managing handoff triggering between unicast and multicast services
JP5959206B2 (ja) 2012-01-18 2016-08-02 ソニー株式会社 受信装置、受信方法、及びプログラム
US9674251B2 (en) * 2013-06-17 2017-06-06 Qualcomm Incorporated Mediating content delivery via one or more services
US10560509B2 (en) * 2013-07-05 2020-02-11 Qualcomm Incorporated Method and apparatus for using HTTP redirection to mediate content access via policy execution
US20210195254A1 (en) * 2016-02-01 2021-06-24 Lg Electronics Inc. Device for transmitting broadcast signal, device for receiving broadcast signal, method for transmitting broadcast signal, and method for receiving broadcast signal

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002103964A1 (en) * 2001-06-18 2002-12-27 Sony Corporation Data transmission apparatus, data transmission method, and data transmission method program
JP2007110586A (ja) * 2005-10-17 2007-04-26 Nec Corp 映像配信システム、映像配信サーバ、映像配信方法、映像配信プログラム
JP2010527048A (ja) * 2007-03-22 2010-08-05 マイクロソフト コーポレーション 携帯機器のためのリモート・データ・アクセス技術
JP2013080988A (ja) * 2011-09-15 2013-05-02 Toshiba Corp 情報処理装置および情報提供方法
JP2013131882A (ja) * 2011-12-21 2013-07-04 Dainippon Printing Co Ltd 連動情報配信サーバー装置、コンピュータプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3503568A4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109672613A (zh) * 2018-12-12 2019-04-23 北京数码视讯软件技术发展有限公司 自适应访问方法、装置及电子设备
CN109672613B (zh) * 2018-12-12 2021-06-18 北京数码视讯软件技术发展有限公司 自适应访问方法、装置及电子设备

Also Published As

Publication number Publication date
EP3503568A4 (en) 2019-08-28
JPWO2018034172A1 (ja) 2019-06-13
MX2019001568A (es) 2019-06-06
CA3033735A1 (en) 2018-02-22
KR20190039403A (ko) 2019-04-11
BR112019002867A2 (pt) 2019-05-14
US20210288735A1 (en) 2021-09-16
KR102496890B1 (ko) 2023-02-08
EP3503568A1 (en) 2019-06-26

Similar Documents

Publication Publication Date Title
US9723375B2 (en) Apparatus and method for processing an interactive service
CN108293148B (zh) 接收装置、发送装置以及数据处理方法
WO2018034172A1 (ja) 情報処理装置、クライアント装置、及び、データ処理方法
JP2015073316A (ja) Ｉｐマルチキャストのための発見情報
KR102443060B1 (ko) 정보 처리 장치 및 정보 처리 방법
US10469919B2 (en) Broadcast signal transmission apparatus, broadcast signal reception apparatus, broadcast signal transmission method, and broadcast signal reception method
KR102499231B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
US11374670B2 (en) Receiving device, transmitting device, and data processing method
KR102532046B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
US11012761B1 (en) Techniques for replacement content signaling in advanced television systems committee (ATSC) 3.0 television
US10979495B2 (en) Information processing apparatus, information processing method, and information processing system
KR102620220B1 (ko) 지상파 uhd 방송 브로드캐스터 어플리케이션 재전송 시스템 및 그 방법
US20240137596A1 (en) Methods for multimedia data delivery and apparatuses for implementing the same
EP4358523A1 (en) Methods for multimedia data delivery and apparatuses for implementing the same
WO2018012315A1 (ja) 情報処理装置、及び、情報処理方法

Legal Events

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

Ref document number: 17841397

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2018534344

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 20197003080

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 3033735

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112019002867

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 2017841397

Country of ref document: EP

Effective date: 20190319

ENP Entry into the national phase

Ref document number: 112019002867

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20190212