[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2010090162A1 - コンテンツ受信装置および方法、コンテンツ送信装置および方法、プログラム、並びに記録媒体 - Google Patents

コンテンツ受信装置および方法、コンテンツ送信装置および方法、プログラム、並びに記録媒体 Download PDF

Info

Publication number
WO2010090162A1
WO2010090162A1 PCT/JP2010/051370 JP2010051370W WO2010090162A1 WO 2010090162 A1 WO2010090162 A1 WO 2010090162A1 JP 2010051370 W JP2010051370 W JP 2010051370W WO 2010090162 A1 WO2010090162 A1 WO 2010090162A1
Authority
WO
WIPO (PCT)
Prior art keywords
content
information
broadcast
data
nrt
Prior art date
Application number
PCT/JP2010/051370
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 CN201080006450.1A priority Critical patent/CN102301734B/zh
Priority to RU2011132384/07A priority patent/RU2518513C2/ru
Priority to BRPI1008088A priority patent/BRPI1008088A2/pt
Priority to US13/147,459 priority patent/US9584841B2/en
Priority to EP10738494.3A priority patent/EP2395752A4/en
Priority to KR1020117017863A priority patent/KR101669604B1/ko
Publication of WO2010090162A1 publication Critical patent/WO2010090162A1/ja
Priority to US13/888,625 priority patent/US20130247124A1/en
Priority to US15/405,930 priority patent/US10257553B2/en

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/16Analogue secrecy systems; Analogue subscription systems
    • H04N7/173Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/2625Content 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 delaying content or additional data distribution, e.g. because of an extended sport event
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2362Generation or processing of Service Information [SI]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H20/00Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/40Arrangements for broadcast specially adapted for accumulation-type receivers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2365Multiplexing of several video streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26208Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
    • H04N21/26241Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints involving the time of distribution, e.g. the best time of the day for inserting an advertisement or airing a children program
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26283Content 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 associating distribution time parameters to content, e.g. to generate electronic program guide data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41Structure of client; Structure of client peripherals
    • H04N21/414Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/4147PVR [Personal Video Recorder]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4334Recording operations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/458Scheduling content for creating a personalised stream, e.g. by combining a locally stored advertisement with an incoming stream; Updating operations, e.g. for OS modules ; time-related management operations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/472End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47214End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for content reservation or setting reminders; for requesting event notification, e.g. of sport results or stock market
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64Addressing
    • H04N21/6405Multicasting
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H60/00Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/68Systems specially adapted for using specific information, e.g. geographical or meteorological information
    • H04H60/72Systems specially adapted for using specific information, e.g. geographical or meteorological information using electronic programme guides [EPG]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H60/00Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/68Systems specially adapted for using specific information, e.g. geographical or meteorological information
    • H04H60/73Systems specially adapted for using specific information, e.g. geographical or meteorological information using meta-information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643Communication protocols
    • H04N21/64322IP

Definitions

  • the present invention relates to a content receiving apparatus and method, a content transmitting apparatus and method, a program, and a recording medium, and in particular, a content receiving apparatus and method enabling realization of Push-type NRT service, and a content transmitting apparatus and method.
  • the present invention relates to a program and a recording medium.
  • an NRT service that reproduces the broadcasted content after temporarily recording the broadcasted content on the premise that the receiving terminal has a large-capacity storage is available. It is being considered.
  • the NRT (Non-Real Time) service does not assume viewing in real time, and does not need to view the content in synchronization with the broadcast time of the content, and transmits the content as data in the form of a broadcast signal.
  • the NRT service it is possible to complete recording (downloading) in a shorter time, for example, when the transmission band of the signal by the broadcast wave is large, unlike the recording reservation of the content of the conventional broadcast program. It is. Alternatively, for example, if the transmission band of the broadcast wave signal is small, the download will be completed in a longer time.
  • the terminal automatically performs the content.
  • Two methods of receiving and storing can be considered.
  • the former scheme is, for example, referred to as a Pull-type NRT service
  • the latter scheme is, for example, referred to as a Push-type NRT service.
  • the present invention has been made in view of such a situation, and aims to be able to realize a Push-type NRT service.
  • a control information receiving means for receiving control information on broadcast of content at a transmission rate not synchronized with a reproduction rate based on a signal transmitted as a broadcast wave, and the control information. And reservation information for receiving and recording content broadcasted on a logical channel corresponding to preset registration information, the download schedule generating means generating a download schedule, and the download schedule, based on the download schedule.
  • the content receiving apparatus is provided with a download unit that receives each of the content and records the content on a recording medium, and a reproduction unit that reproduces the content recorded on the recording medium at the reproduction rate.
  • the control information on the broadcast of the content relates to a logical channel obtained by dividing the physical channel into a plurality of transmission paths according to a predetermined method, when the transmission path of the broadcast wave signal in the frequency band is a physical channel. It is possible to include predetermined descriptive data in which information is described, and metadata in which information on content transmitted on each of the logical channels is described.
  • the download schedule generation unit generates a download schedule for receiving and recording all contents broadcasted on the logical channel corresponding to the registration information among a plurality of logical channels existing on the physical channel.
  • the download schedule generation unit specifies the broadcast start time of the content based on the description of the metadata, and location information for specifying the data of the content among the data transmitted by the logical channel.
  • the download schedule may be identified and generated.
  • the download means receives a broadcast wave of a frequency band corresponding to the physical channel at the broadcast start time of the content based on the download schedule, and based on the description of the predetermined description data, the download means
  • the transport packet of the logical channel corresponding to the registration information is extracted from the transport packets to be transmitted, and the content is received by specifying the data of the content based on the location information. be able to.
  • the transport packet of the logical channel is configured to include an IP packet, and the location information includes information for specifying a file transmission session of data of the content transmitted by the IP packet, and the download
  • the means may specify the data of the content based on the description of transmission control data acquired by specifying the file transmission session.
  • the download means can specify an address file described in an RSS format or an ATOM format based on the description of the transmission control data, and specify data of the content based on the address file.
  • the logical channel providing the Push type service for receiving the content to be viewed is specified among the logical channels regardless of the user request, and the Push type A list of logical channels providing services is presented to the user, registration of the Push type service by the user is accepted, and information specifying the logical channel of the registered Push type service is stored as the registration information. can do.
  • the download schedule generation unit is a content to be broadcasted on the logical channel corresponding to the registration information among the plurality of logical channels existing on the physical channel, and receives the content specified by the predetermined description data And download schedules for recording.
  • the download unit may include an overwrite determination unit that determines whether the received content is to be overwritten on the content recorded in the recording medium.
  • An expiration date may be set for the content recorded by the download unit based on the description of the metadata, and the content for which the expiration date has passed may be deleted.
  • control information related to broadcast of content at a transmission rate not synchronized with a reproduction rate is received based on a signal transmitted as a broadcast wave, and preset based on the control information. It is reservation information for receiving and recording content broadcasted on a logical channel corresponding to registration information, wherein a download schedule is generated, and each of the content is received based on the download schedule and recorded in a recording medium It is a content receiving method including the step of recording and reproducing the content recorded on the recording medium at the reproduction rate.
  • a control information receiving means for receiving control information on broadcast of content at a transmission rate not synchronized with a reproduction rate based on a signal transmitted as a broadcast wave from a computer, and the control information And reservation information for receiving and recording the content broadcasted on the logical channel corresponding to the preset registration information
  • the download schedule generation means for generating a download schedule, and the download schedule And a download unit that receives each of the content and records the content on a recording medium
  • control information related to broadcast of content at a transmission rate not synchronized with the reproduction rate is received based on a signal transmitted as a broadcast wave, and preset based on the control information. It is reservation information for receiving and recording the content broadcasted on the logical channel corresponding to the registered information, wherein a download schedule is generated, and each of the content is received based on the download schedule and a recording medium Content recorded on the recording medium and recorded on the recording medium is reproduced at the reproduction rate.
  • a content information acquisition means for acquiring information on content broadcast at a transmission rate not synchronized with a reproduction rate from a broadcast schedule created in advance, and the content is not based on a user request
  • a determination unit that determines whether the content is a Push-type service for receiving content to be viewed, and information about the content broadcasted on a predetermined logical channel when it is determined that the content is the Push-type service.
  • First control information generation means for describing information representing that the content is the content of the Push type service, together with the information relating to the content, in the first control information generated as In the physical channel as a signal transmission path, the logical channel Control information generation means for generating second control information in which information for specifying each of the channels is described, and the first control information and the second control information are multiplexed with the data of the content
  • multiplexing means for multiplexing data to be broadcasted on a plurality of the logical channels as data to be broadcasted on one physical channel, and broadcasting for transmitting the broadcast waves as modulating the multiplexed data. It is a content transmission apparatus provided with a wave transmission means.
  • a second aspect of the present invention wherein information about content broadcasted at a transmission rate not synchronized with a reproduction rate is acquired from a broadcast schedule created in advance, and the content is to be viewed If it is determined that the content is a Push-type service content, the first control generated as information on the content to be broadcast on a predetermined logical channel
  • the information describes the information indicating that the content is the content of the Push type service together with the information on the content, and in the physical channel as a transmission path of the broadcast wave signal of a predetermined frequency band, each of the logical channels is Second control information in which information for specifying is described And multiplexing the first control information and the second control information with the data of the content, and multiplexing data to be broadcasted on a plurality of the logical channels as data to be broadcasted on a single physical channel And modulating the multiplexed data and transmitting it as a broadcast wave.
  • a content information acquisition means for acquiring information on content broadcasted at a transmission rate not synchronized with a reproduction rate from a computer and a broadcast schedule created in advance, and the content is a user request Regardless of whether the content is a Push-type service for receiving the content to be viewed or not, if determined as the Push-type service content, the broadcast is performed on a predetermined logical channel.
  • First control information generating means for describing information representing that the content is the content of the Push type service together with the information on the content in the first control information generated as the information on the content; On the physical channel as the transmission path of the broadcast wave signal And second control information generation means for generating second control information in which information for specifying each of the logical channels is described; and the first control information and the second control information And multiplexing means for multiplexing data to be broadcasted on a plurality of the logical channels as data to be broadcasted on one physical channel, and modulating the multiplexed data to broadcast the broadcast wave And a program to function as a content transmission apparatus including broadcast wave transmission means for transmitting as.
  • information on content broadcasted at a transmission rate not synchronized with the reproduction rate is acquired from a broadcast schedule created in advance, and the content should be viewed regardless of the user's request. It is determined whether the content is a Push-type service content to be received, and when it is determined that the content is a Push-type service content, the first generated as information on the content broadcasted on a predetermined logical channel Information representing that the content is the content of the Push type service is described in the control information together with the information on the content, and in the physical channel as a transmission path of the broadcast wave signal of a predetermined frequency band, each of the logical channels Information for identifying the Two control information are generated, and the first control information and the second control information are multiplexed with the data of the content, and the data to be broadcasted on a plurality of the logical channels are broadcasted on one physical channel
  • the multiplexed data is modulated and transmitted as a broadcast wave.
  • a Push-type NRT service can be realized.
  • FIG. 1 An example in which the content of Push-type NRT broadcasting is accumulated in the receiving device 41 will be described. It is a figure which shows another structural example of VCT. It is a figure which shows the other structural example of NRT-IT. It is a figure explaining the example of the syntax of NRT-IT of FIG. It is a figure explaining the example of the syntax of NRT-IT of FIG. It is a figure explaining the example of the syntax of "Push type
  • FIG. 15 is a flowchart for describing an example of Push-type NRT broadcast service registration processing. It is a flowchart explaining the example of Push type
  • FIG. 16 is a diagram for explaining a method of transmitting new content and allowing the reception device 41 to view the content without newly receiving the VCT and NRT-IT into the reception device 41. It is a figure which shows the example of the address file described by the RSS format used in the example of FIG. It is a figure which shows the example of the address file described by the RSS format used in the example of FIG. It is a figure explaining the protocol stack in the signal of the broadcast wave containing the NRT broadcast of the system which conforms to the ARIB specification. It is a figure which shows the structural example of a group attribute table. It is a figure which shows the structural example of a program attribute table.
  • FIG. 1 is a diagram showing an example of the configuration of a broadcast system according to an embodiment of the present invention.
  • the broadcast system 1 is configured by a transmitting device 21 installed in the broadcasting station 11 and a receiving device 41 installed in the user home 12 or the like. Note that, in practice, a receiver is installed in each of a plurality of user homes.
  • a predetermined frequency band for example, 6 MHz
  • the assigned frequency band is regarded as one broadcast channel
  • the broadcast channel is set by the receiver 41.
  • Channel selection is performed by being selected.
  • digital broadcasting it is also possible to provide a plurality of logical channels in such a way as to be multiplexed into one broadcast channel.
  • the transmitter 21 transmits, for example, a digital broadcast wave signal, and can transmit a normal broadcast signal and an NRT broadcast signal.
  • the normal broadcast is a broadcast on the premise of viewing in real time in the receiving apparatus 41 which has received the signal of the broadcast, and the broadcast is assumed on the premise that the content is viewed in synchronization with the broadcast time of the content. Ru.
  • NRT broadcasting does not require viewing in real time, and it is not necessary to view the content in synchronization with the broadcast time of the content, and transmits the content as data by means of a broadcast wave signal.
  • NRT broadcasting unlike the recording reservation of the content of a conventional broadcast program, for example, when the transmission band of the signal by the broadcast wave is large, that is, when the transmission rate is high, recording (downloading) is completed in a shorter time. It is possible to do so. Alternatively, for example, if the transmission band of the signal by the broadcast wave is small, that is, if the transmission rate is low, the content download will be completed in a longer time. On the other hand, in normal broadcasting, since broadcasted content is viewed in real time, transmission of content is performed at almost the same transmission time as playback time of the content.
  • the NRT broadcast it is possible to transmit the content to be broadcast as digital data from the transmitting device 21 to the receiving device 41 at a transmission rate largely different from the reproduction rate.
  • the content to be broadcast as digital data can not be transmitted from the transmitting device 21 to the receiving device 41 at a transmission rate that is largely different from the reproduction rate.
  • the content composed of the signal transmitted by the transmitting device 21, the content broadcasted by the NRT broadcast is received by the receiving device 41 and recorded in the recording medium (storage) of the receiving device 41. Accumulated. Then, when the user of the receiving device 41 reproduces the content recorded in the recording medium, the content broadcasted by the NRT broadcast is viewed.
  • NRT broadcasting After the user selects individual content, a method for receiving and storing the content, and registration for viewing the set of specific content by the user are performed, and then the receiving device 41 automatically performs these content.
  • Two methods of receiving and storing can be considered.
  • the former scheme is referred to as Pull-type NRT broadcast
  • the latter scheme is referred to as Push-type NRT broadcast.
  • Push-type NRT broadcasting may be referred to as, for example, Subscription-type NRT broadcasting.
  • NRT broadcasting data configured to include metadata called control and program information (PSIP) data, control information, and the like is periodically received by the receiving device 41.
  • PSIP control and program information
  • the receiving device 41 generates a list of contents that can be received in NRT broadcasting based on metadata included in PSIP data, control information, and the like. This list of contents is called an ECG (Electronic Contents Guide).
  • ECG Electronic Contents Guide
  • the details of the PSIP data are described in the standard of Advanced Television Systems Committee (ATSC).
  • FIG. 2 is a diagram showing an example of an ECG displayed on the screen.
  • a list of contents that can be received in NRT broadcasting as the NRT program list is displayed together with the broadcast start time of the contents.
  • "XXXX” is assumed to display the title of each content, and the broadcast of the content is started by the description such as "1/30 15:00 (representing 15 o'clock on January 30)". The time is displayed.
  • FIG. 3 is a diagram showing an example of the EPG displayed on the screen.
  • EPGs of programs broadcasted on the channel "NRT # 1", the channel "NRT # 2", and the channel “RT # 1" are shown.
  • the channel “NRT # 1” and the channel “NRT # 2” are channels of NRT broadcasting
  • the channel “RT # 1” are channels of normal broadcasting.
  • Each of rectangular frames displayed in FIG. 3 represents a broadcast time zone of each program (or content).
  • the EPG indicates that the program (or content) can be viewed in the time slot displayed in a rectangular frame in the channel “RT # 1” of the normal broadcast.
  • the channel “NRT # 1" or “NRT # 2" of the NRT broadcast it is indicated that the program (or content) can be downloaded in the time zone displayed by the rectangular frame. .
  • the user of the receiving device 41 displays the ECG of FIG. 2 or the EPG of FIG. 3 on a screen of a display or the like, and operates, for example, a GUI to select desired NRT broadcast content.
  • the receiving device 41 downloads the content at the broadcast start time of the selected content.
  • the receiving device 41 receives a broadcast wave signal and records data corresponding to the signal on a recording medium, whereby download processing is performed.
  • FIG. 4 is a diagram showing an example of the content list displayed on the screen.
  • “XXXX” is to display the title of each content.
  • the user of the receiving device 41 displays the content list of FIG. 4 on the screen of the display or the like, and operates the GUI, for example, to select the content to be viewed. Thereby, the selected content is reproduced, and as shown in FIG. 5, an image of the content is displayed on the screen of the display. In this example, an image of a person playing golf is displayed as an image of content.
  • FIG. 6 is a diagram for explaining a protocol stack in a broadcast wave signal including NRT broadcast and normal broadcast.
  • the lowest layer is referred to as “Physical Layer”, and the frequency band of the broadcast wave allocated for the channel corresponds to this.
  • the upper hierarchy adjacent to “Physical Layer” is taken as “TS (Transport Stream)”.
  • TS Transaction Stream
  • packets in the upper layer are divided into fixed-length packets called transport packets and transmitted, and the succession of transport packets becomes a transport stream.
  • all signals transmitted in the frequency band corresponding to one broadcast channel are transmitted by transport packets having header information and the like corresponding to the broadcast channel.
  • the upper hierarchy adjacent to the transport stream is "Section” or "PES (Packetized Elementary Stream)".
  • PES Packetized Elementary Stream
  • data to be reproduced in real time such as content of normal broadcast, will be transmitted as a packet of "PES”.
  • data of file transfer, data of control information, etc. will be transmitted as a packet of "Section”.
  • Caption Coding As shown in FIG. 6, "Caption Coding", “Audio Coding”, and “Video Coding” are defined as upper layers of “PES” corresponding to the packet type of "PES". "Caption Coding” is a packet in which data relating to image subtitles is stored, “Audio Coding” is a packet in which audio data is stored, and “Video Coding” is a packet in which image data is stored. Ru.
  • PSIP Program Specific Information
  • PSI Program Specific Information
  • DSM-CC Digital Storage Media Command and Control
  • Interactive Data Coding is displayed as the upper hierarchy adjacent to “DSM-CC”.
  • Streaming broadcast is realized by data stored in “Interactive Data Coding”, “Caption Coding”, “Audio Coding”, and “Video Coding”. That is, by receiving these data, it is possible to receive and reproduce a program of normal broadcast.
  • IP is displayed as the upper hierarchy adjacent to "DSM-CC".
  • the “IP” displayed here is the same as the IP in the TCI / IP protocol stack, and an IP packet is specified by the IP address.
  • NRT broadcasting is configured using IP packets.
  • NRT broadcast is provided not as communication but as broadcast, it is not necessary to use the protocol stack of TCI / IP, which is a communication protocol, but it is not necessary to use IP format when downloading content. Packets are used.
  • the upper layer adjacent to the “IP” is “UDP”, and “FLUTE / ALC (Asynchronous Layered Coding Protocol) / LCT (Layered Coding Transport (Building Block))” is displayed as the upper layer. That is, in NRT broadcasting, a packet in which a UDP port in TCP / IP communication is designated is transmitted, and a session by, for example, File Delivery over Unidirectional Transport (FLUTE) is established. Then, the FLUTE session identifies the data that constitutes the content.
  • FLUTE is a communication protocol that can perform data distribution using a one-way transmission path (for example, a transmission path only in the downstream direction), and can transmit arbitrary files.
  • FLUTE The details of FLUTE are defined as RFC3926.
  • NRT broadcasting it is possible to multiplex one physical channel having a transmission band corresponding to the transmission rate (for example, 20 Mbps) of the transport packet of "TS" into a plurality of logical channels. . That is, for example, when a transmission channel of a broadcast wave signal of one broadcast channel to which a frequency band of 6 MHz is allocated is used as a physical channel, a plurality of logical channels are provided by dividing the physical channel into a plurality of transmission channels. It is possible.
  • VCT is control information on logical channels generated for each physical channel.
  • Each of the logical channels thus multiplexed is referred to as a virtual channel.
  • NRT broadcasting it is further possible to multiplex one logical channel by a plurality of FLUTE sessions.
  • one physical channel for example, one broadcast channel
  • one broadcast channel is made to correspond to one logical channel, and is not multiplexed into a plurality of channels as in NRT broadcast. Therefore, in the NRT broadcast, unlike the case of the normal broadcast, it is also possible to simultaneously broadcast (transmit) a plurality of contents on one broadcast channel.
  • VCT Virtual Channel Table
  • NRT-IT NRT Information Table
  • the VCT is a table including descriptors for making it possible to identify each of the virtual channels (logical channels) in the receiving device 41.
  • FIG. 7 is a diagram showing an example of VCT.
  • TS_id is an ID for identifying a transport stream, and in practice, predetermined characters, numerical values, and the like are described. This makes it possible to identify which physical channel (broadcast channel) is the VCT.
  • the “number of channels” is described as a numerical value or the like representing the number of logical channels included in the physical channel specified by “TS_id”.
  • channel unit description area 72-1 Information on one logical channel is described in the channel unit description area 72-1, the channel unit description area 72-2, and so on.
  • This description area is provided for the numerical value described in the "number of channels” described above. For example, when the number of logical channels included in the physical channel is 3, the numerical value "3" is described in the "number of channels”.
  • a channel unit description area 72-1, a channel unit description area 72-2, and a channel unit description area 72-3 are described.
  • channel name "Channel Name”, “Channel Number”, “Service Type”, “Program_number”, “Source_id”,... are described in the channel unit description area 72-1.
  • the “channel name” and the “channel number” describe predetermined characters and numerical values representing them, respectively.
  • the “channel name” of the description area 72-1 in the channel unit is described as "XX station NRT first channel” or the like, and the channel number is described as “5-1” or the like.
  • channel number is described as “XX station NRT second channel” or the like.
  • the “service type” describes information identifying whether the logical channel is a logical channel corresponding to normal broadcast or a logical channel corresponding to NRT broadcast. For example, if the logical channel corresponding to the description region 72-1 in units of channels is a logical channel of NRT broadcasting, the "service type" is described as "NRT".
  • Program_number is used to specify PSI (Program Specific Information) required to specify data of the logical channel.
  • Source_id is an ID for identifying the logical channel, and in fact, predetermined characters, numerical values, and the like are described. That is, the channel-based description area 72-1 is an area where information on one logical channel specified by the "Source_id” is described.
  • the VCT is configured in this way.
  • NRT broadcasting it is possible to broadcast different contents on each of a plurality of logical channels.
  • Information on the content transmitted on each of the logical channels is described in NRT-IT which is control information generated for each logical channel.
  • the NRT-IT is a table including descriptors for enabling identification of each of the NRT broadcast contents broadcasted on each logical channel in the reception apparatus 41.
  • FIG. 8 is a diagram showing an example of NRT-IT.
  • “Source_id”, “number of contents”, and description unit 92-1 for content unit, description region 92-2 for content unit, ... are described in the description region 91 of NRT-IT. It is done.
  • “Source_id” is the same as that described above with reference to FIG. 7 and is an ID for identifying a logical channel, and in fact, predetermined characters, numerical values, and the like are described. This makes it possible to associate the NRT-IT with any of the logical channels described in the channel unit description area 72-1 and the channel unit description area 72-2 in FIG. .
  • the “number of contents” is described as a numerical value or the like representing the number of contents to be broadcast in a predetermined unit time in the logical channel specified by “Source_id”.
  • Information on one piece of content is described in the content unit description area 92-1, the content unit description area 92-2, and so on.
  • This description area is provided for the numerical value described in the "number of contents" described above. For example, when the number of contents to be broadcast per unit time on the logical channel is 5, the numerical value "5" is described in the "number of contents”. Then, the content unit description area 92-1, the content unit description area 92-2,... And the channel unit description area 92-5 are described.
  • Content unit description area 92-1 is an ID for identifying the content, and in fact, predetermined characters, numerical values, and the like are described. That is, the content unit description area 92-1 is an area where information on one piece of content identified by the "content_item_id” is described.
  • Distribution schedule describes information indicating the broadcast start time and the broadcast end time of the content. Since the content is NRT broadcast content, the broadcast start time and the broadcast end time do not represent the time for which the content can be viewed, but the time to start downloading the content and the time to finish downloading the content Is represented.
  • the “content expiration date” describes information specifying the time when the content expiration date will be.
  • the content whose expiration date has passed is deleted from the recording medium of the receiving device 41 or the like, and can not be reproduced.
  • the “content transmission location information” describes the IP address, the UDP port number, and the identifier “TSI (Transport Session Identifier)” for specifying a FLUTE session, which are described above with reference to FIG.
  • TSI Transport Session Identifier
  • content_item_id information related to one piece of content specified by “content_item_id” is described in the content unit description areas 92-2,.
  • NRT-IT is configured in this way.
  • VCT VCT
  • NRT-IT NRT-IT
  • FIG. 9 is a view for explaining the data configuration of the content transmitted by the FLUTE session.
  • the data acquired by the FLUTE session constitutes a FLUTE session stream as shown at the bottom of the figure.
  • the FLUTE session stream is actually made up of a plurality of files divided into predetermined sizes, and each of the plurality of files is given an identifier called "TOI (Transport Object Identifier)". ing.
  • TOI Transport Object Identifier
  • a file having “TOI” of 0 is taken as an FDT (File Delivery Table).
  • the FDT is a table in which information on each of the other files constituting the FLUTE session stream is described.
  • a description area 112-1 of information in file units in a FLUTE session a description area 112-2 of information in file units of a FLUTE session,... There is.
  • “TOI”, “content_type”, “file name”,... are described in the file unit information description area 112-1 in the FLUTE session.
  • “TOI” is information for identifying a file in a FLUTE session, and in fact, a predetermined numerical value is described. That is, the description area 112-1 of file unit information in the FLUTE session is an area in which information on one file specified by the "TOI" is described.
  • Content_type describes information specifying the file format (type of data) of the file specified by “TOI”.
  • Content_type is, for example, "video” when the file is a file of image data, and "audio” when the file is a file of audio data.
  • the "file name” describes the name of the file.
  • the "file name” may be described as a URL.
  • Data of content transmitted by a predetermined FLUTE session is configured in this way.
  • step S11 the receiving device 41 receives metadata on NRT broadcasting, control information, and the like.
  • PSIP data is received.
  • the PSIP data is data configured to include VCT, NRT-IT, etc., and is periodically received by the receiving device 41.
  • acquiring VCT makes it possible to acquire information on each of the logical channels in the broadcast channel.
  • NRT-IT it becomes possible to acquire information on content broadcasted on each logical channel.
  • step S12 the receiving device 41 generates a list of contents that can be received in NRT broadcasting based on VCT and NRT-IT included in the PSIP data.
  • step S13 the receiving device 41 causes the display to display an ECG corresponding to the list generated in step S12. At this time, for example, an image of an ECG as shown in FIG. 2 is displayed. Alternatively, in step S13, an EPG as shown in FIG. 3 may be displayed.
  • step S14 the receiving device 41 receives the selection of the content by the user based on the ECG displayed in step S13. At this time, for example, the content of the NRT broadcast that the user wants to view is selected.
  • step S15 the receiving device 41 determines whether the broadcast start time of the content selected in the process of step S14 has come or not, and waits until it is determined that the broadcast start time has come. If it is determined in step S15 that the broadcast time has come, the process proceeds to step S16.
  • step S16 the receiving device 41 downloads the content.
  • the channel selection of the receiving device 41 is set to the broadcast channel of the content for which the selection has been accepted in step S14. Then, based on the VCT received in step S11, the receiving device 41 specifies data to be transmitted on the logical channel on which the content is to be broadcasted. Furthermore, based on the NRT-IT received in step S11, the receiving device 41 identifies a FLUTE session in which the content is to be transmitted, and acquires each of the files that constitute the FLUTE session stream. When the broadcast end time is reached, acquisition of all the files constituting the FLUTE session stream is completed in the receiving device 41, whereby the download of the content is completed.
  • the reception device 41 records, as one content, data configured by the file acquired as described above on a recording medium.
  • the metadata of the content included in the information received in step S11 is also recorded in association with the content.
  • the metadata includes, for example, “content name”, “distribution schedule”, “content expiration date” and the like described in NRT-IT.
  • step S17 the receiving device 41 displays a list of contents downloaded in the process of step S16. At this time, for example, an image as shown in FIG. 4 is generated and displayed on the display.
  • step S18 the receiving device 41 receives the selection of content by the user based on the list of content displayed in the process of step S17. At this time, for example, among the contents of the NRT broadcast already recorded on the recording medium of the reception device 41, the contents which the user wants to view are selected.
  • step S19 the receiving device 41 reproduces the content of which the selection is accepted in the process of step S18.
  • the receiving device 41 reproduces the content of which the selection is accepted in the process of step S18.
  • an image of the content is displayed on the display.
  • Push-type NRT broadcasting can be specifically realized.
  • the receiving device 41 automatically receives and stores the content. The following is assumed as a specific Push-type NRT broadcast.
  • the receiving device 41 automatically receives and stores the content of the weather forecast program broadcasted on a predetermined broadcast channel.
  • the weather forecast program is, for example, a 5-minute program, and delivers a forecast based on the latest weather information twice a day, for example, the content stored in the receiving device 41 is sequentially updated Updated to
  • the user can view the weather forecast based on the latest weather information at any time.
  • Push-type NRT broadcasting of a news clip For example, consider Push-type NRT broadcasting of a news clip.
  • the user registers in advance a Push-type NRT broadcast service called "news clip”. Then, the receiving device 41 automatically receives and stores the content of the news program broadcast on a predetermined broadcast channel.
  • the news program is, for example, a 15-minute program and transmits news about the latest political and economic information
  • the content stored in the receiving device 41 is updated to the latest one by one. Ru.
  • the content may be accumulated and deleted for a predetermined time.
  • the storage size (storage capacity) of the receiving apparatus 41 required when receiving the service of “news clip” is specified, and the content is overwritten and updated for the part exceeding the storage size. You may
  • Push-type NRT broadcasting the service of Push-type NRT broadcasting as described above is provided by, for example, each broadcasting station. Such services may be free or paid. Then, the user of the receiving device 41 selects a desired service and registers it in the receiving device 41.
  • logical channels corresponding to individual services of Push-type NRT broadcasting are provided. That is, when there are three Push-type NRT broadcast services, there are three logical channels.
  • FIG. 11 illustrates an example in which normal broadcast and NRT broadcast are performed on three broadcast channels of “Ch. 4”, “Ch. 5”, and “Ch. 6”.
  • "Ch. 4" is a broadcast channel of normal broadcast
  • "Ch. 5" and “Ch. 6” are broadcast channels of NRT.
  • the horizontal direction in the figure represents the frequency of the broadcast wave
  • the vertical direction in the figure represents the time.
  • the contents such as the type of content to be broadcasted in each channel are represented by hatching or the like in the figure.
  • the contents of normal broadcast, the contents of Pull-type NRT broadcast, the contents of Push-type NRT broadcast, and the broadcast pause period are represented by hatching or the like in the drawing.
  • each of rectangular frames displayed in each of the logical channel “VC5-1” to the logical channel “VC5-3” represents the broadcasting time zone of each content.
  • the logical channel “VC5-1” is a logical channel assigned to one Push-type NRT broadcast service.
  • the logical channel “VC5-2” is a logical channel assigned to Pull type NRT broadcasting.
  • the logical channel “VC5-3” is a logical channel assigned to another Push NRT broadcast service. Also, in this example, the logical channel “VC5-3” includes a time zone in which the channel is paused.
  • Three FLUTE sessions are provided in the logical channel “VC5-2”. That is, in Pull type NRT broadcasting broadcasted on the logical channel “VC5-2”, it is possible to broadcast three contents simultaneously.
  • each of rectangular frames displayed in each of the logical channel “VC 6-1” and the logical channel “VC 6-2” represents the broadcasting time zone of each content.
  • the logical channel “VC 6-1” is a logical channel assigned to one Push-type NRT broadcast service.
  • the logical channel “VC6-2” is a logical channel assigned to a Pull type NRT broadcast service.
  • Two FLUTE sessions are provided in the logical channel “VC6-1”. That is, in the Push-type NRT broadcast service provided on the logical channel “VC 6-1”, two contents are broadcast simultaneously.
  • the PSIP data periodically transmitted on the broadcast channel "Ch.5" includes one VCT in which "TS_id” for identifying the transport stream of the physical channel "Ch.5" is described.
  • the PSIP data also includes three NRT-ITs in which “Source_id” for identifying the logical channel “VC5-1”, the logical channel “VC5-2”, and the logical channel “VC5-3” is described, respectively.
  • PSIP data periodically transmitted on the broadcast channel "Ch. 6" includes one VCT in which "TS_id” is written that identifies the transport stream of the physical channel “Ch. 6".
  • the PSIP data also includes two NRT-ITs in which “Source_id” for identifying the logical channel “VC 6-1” and the logical channel “VC 6-2” are described, respectively.
  • the logical channel “VC5-1” is allocated to the "news clip” of the OO broadcasting station, and the logical channel “VC5-3” is allocated to the "weather forecast” of the OO broadcasting station.
  • the logical channel “VC 6-1” is assigned to the “news clip” of the xx station.
  • “Ch. 4” is not divided into a plurality of logical channels.
  • the logical channel “VC4-1” of the normal broadcast is substantially the same as the physical channel.
  • the receiving device 41 since the receiving device 41 periodically receives PSIP data, it can identify data to be transmitted on each logical channel based on the VCT. Therefore, for example, the receiving device 41 in which the service of “weather forecast” of the ⁇ broadcasting station is registered automatically downloads all the contents transmitted on the logical channel “VC5-3”.
  • the content is specified based on the VCT and the EIT (Event Information Table).
  • Push-type NRT broadcasting does not provide individual content selected by the user, but provides content to the user unilaterally, it is difficult to realize in the same broadcasting system as Pull-type NRT broadcasting and normal broadcasting.
  • the receiver 41 in which the Push-type NRT broadcast service is registered automatically downloads all of the content transmitted on the logical channel corresponding to the service. By doing this, it is possible to realize Push-type NRT broadcasting in the same broadcasting system as Pull-type NRT broadcasting and normal broadcasting.
  • FIG. 12 is a diagram for explaining a method in which data that configures content in NRT broadcasting is received by the receiving device 41.
  • a transmission band of a transport stream (TS) corresponding to one broadcast channel is shown by a cylinder 201.
  • the vertical direction in the figure represents time.
  • a logical channel (virtual channel: VC) multiplexed to the transport stream of the cylinder 201 is shown by the cylinder 202.
  • one logical channel (virtual channel: VC) is multiplexed in the transport stream, in reality, a plurality of logical channels can be multiplexed.
  • the FLUTE session present in the logical channel corresponding to the cylinder 202 is illustrated by the cylinder 203-1 and the cylinder 203-2. That is, within the logical channel corresponding to cylinder 202, there are two FLUTE sessions. Data constituting the content to be received and stored (recorded) by the receiving device 41 is transmitted as a file of FLUTE sessions of the cylinder 203-1 and the cylinder 203-2.
  • the receiving device 41 is set to receive the content A to content C broadcasted on the logical channel corresponding to the cylinder 202, which is the content of the NRT broadcast and is the broadcast channel of the transport stream corresponding to the cylinder 201. It shall be done.
  • the receiving device 41 since the receiving device 41 periodically receives PSIP data, it can obtain VCT and NRT-IT periodically. It is assumed that VCT 210, NRT-IT 211, and NRT-IT 212 are received first.
  • the receiving device 41 can specify “source_id” that identifies the logical channel on which the content A to be received and stored and the content B are to be transmitted by referring to the description of the VCT 210. Then, the receiving device 41 can specify the NRT-IT 211 related to the relevant logical channel based on the “source_id”.
  • the NRT-IT 212 is an NRT-IT corresponding to another logical channel not shown in the figure.
  • the receiving device 41 specifies a description area of a content unit in which information on the content to be received and stored is described in the description of the NRT-IT 211.
  • the NRT-IT 211 received first describes information related to the content to be broadcasted in the time zone indicated by the arrow 205 in the FLUTE session indicated by the cylinder 203-1. I assume. Further, it is assumed that the information regarding the content of the time zone indicated by the arrow 206 in the FLUTE session indicated by the cylinder 203-2 is also described in the NRT-IT 211 received first.
  • the receiving device 41 refers to the description area of the specified content unit and refers to the IP address, the UDP port number, and the identifier for specifying the FLUTE session “TSI included in the“ content transmission location information ”. Identify ".
  • the reception device 41 specifies the file of the FLUTE session indicated by the cylinder 203-1 and extracts the FDT. Then, the receiving device 41 receives and stores the content A by acquiring each of the files of the data forming the content A based on the FDT.
  • the reception device 41 specifies the file of the FLUTE session indicated by the cylinder 203-2 and extracts the FDT. Then, the receiving device 41 receives and stores the content B by acquiring each of the files of the data forming the content B based on the FDT.
  • VCT and NRT-IT are updated.
  • VCT 220, NRT-IT 221 and NRT-IT 222 are newly received and updated.
  • the updated NRT-IT 221 describes information related to the content to be broadcasted in the time zone indicated by the arrow 207 in the FLUTE session indicated by the cylinder 203-1.
  • the receiving device 41 can specify “source_id” that identifies the logical channel through which the content C to be received and stored is transmitted, by referring to the description of the VCT 220, as described above. Then, the receiving device 41 can specify the NRT-IT 221 related to the relevant logical channel based on the “source_id”.
  • the NRT-IT 222 is an NRT-IT corresponding to another logical channel not shown in the figure.
  • the receiving device 41 refers to the description area of the specified content unit and refers to the IP address, the UDP port number, and the identifier for specifying the FLUTE session “TSI included in the“ content transmission location information ”. Identify ".
  • the reception device 41 specifies the file of the FLUTE session indicated by the cylinder 203-1 and extracts the FDT. Then, the receiving device 41 receives and stores the content C by acquiring each of the files of the data forming the content C based on the FDT.
  • the transport stream (TS), the logical channel (virtual channel: VC), and the FLUTE session are indicated by cylinders.
  • the horizontal direction in the figure represents time.
  • the content "content 1" transmitted in one FLUTE session and the content “content 2" to “content 4" transmitted in another FLUTE session are received and stored.
  • “Content 1” is versioned content, and is designed to always overwrite the latest content. For example, “content 2” to “content 4” are accumulated until the time designated as “expiration date” has passed, and are deleted when the time designated as “expiration date” has passed.
  • the first version of the content "content 1” is received and accumulated first.
  • the first version of the content “content 1” is written as “content 1 (v 1)".
  • “Content 1” is designed to be broadcast twice by repeating the same version. Now, it is assumed that the receiving device 41 has received and accumulated the first broadcast. In this case, the receiving device 41 is configured not to receive and store the second broadcast.
  • the receiving device 41 receives and stores the content. That is, “content 1 (v 1)” already accumulated (recorded) is overwritten by “content 1 (v 2)".
  • the receiving device 41 is assumed to receive and accumulate the first broadcast again, and is configured not to receive and accumulate the second broadcast.
  • the reception device 41 starts reception of “content 2” while receiving “content 1 (v 1)”, and stores “content 2” when reception of “content 2” is completed. The same content is broadcasted twice repeatedly. Now, it is assumed that the receiving device 41 has received and accumulated the first broadcast. In this case, the receiving device 41 is configured not to receive and store the second broadcast.
  • the receiving device 41 receives and stores “content 3". Thereafter, the receiving device 41 also receives and stores “content 4”.
  • deletion of content may be performed at a time designated as "expiration date", for example, content for which "expiration date” has passed is collectively deleted at a predetermined time interval set in advance. It may be done. Furthermore, for example, when the display of the list of accumulated contents is instructed, the contents for which the “expiration date” has passed may be collectively deleted.
  • the Push-type NRT broadcast content can be updated one after another according to the version, and as in the Pull-type NRT broadcast, it is accumulated until the expiration date passes. It is also possible to
  • one Push NRT broadcast service is assigned to one logical channel.
  • information necessary for realizing Push-type NRT broadcasting is arranged at the position of the broadcast signal where information on a logical channel basis can be stored.
  • a description of information necessary for realizing Push-type NRT broadcasting is added.
  • a description of information necessary for realizing Push-type NRT broadcasting is added to the description area 91 of the NRT-IT described with reference to FIG.
  • FIG. 14 is a diagram showing an example of VCT used in the present invention.
  • TS_id “number of channels”, and channel unit description area 272-1, channel unit description area 272-2,... are described in the VCT description area 271. There is.
  • TS_id is an ID for identifying a transport stream, and in practice, predetermined characters, numerical values, and the like are described. This makes it possible to identify which physical channel (broadcast channel) is the VCT.
  • the “number of channels” is described as a numerical value or the like representing the number of logical channels included in the physical channel specified by “TS_id”.
  • Information on one logical channel is described in the channel unit description area 272-1, the channel unit description area 272-2, and so on.
  • This description area is provided for the numerical value described in the "number of channels" described above. For example, when the number of logical channels included in the physical channel is 3, the numerical value "3" is described in the "number of channels”. Then, a description area 272-1 in units of channels, a description area 272-2 in units of channels, and a description area 272-3 in units of channels are described.
  • Channel name “Channel Name”, “Channel Number”, “Service Type”, “Program_number”, “Source_id”, “Push Type NRT Meta Information”,... are described in the channel unit description area 272-1.
  • the “channel name” and the “channel number” describe predetermined characters and numerical values representing them, respectively.
  • the "channel name” of the description area 272-1 in the channel unit is described as "XX station NRT first channel” or the like, and the channel number is described as “5-1” or the like.
  • channel name of the description area 272-1 in the channel unit is described as “XX station NRT second channel” or the like, and the channel number is described as “5-2” or the like.
  • the “service type” describes information identifying whether the logical channel is a logical channel corresponding to normal broadcast or a logical channel corresponding to NRT broadcast. For example, when the logical channel corresponding to the description area 272-1 in units of channels is a logical channel of NRT broadcasting, the "service type" is described as "NRT".
  • Source_id is an ID for identifying the logical channel, and in fact, predetermined characters, numerical values, and the like are described. That is, the channel unit description area 272-1 is an area where information on one logical channel specified by the "Source_id” is described.
  • the “Push type NRT meta information” is information necessary to realize Push type NRT broadcasting, and for example, the following information is described.
  • Push type NRT meta information information indicating that the logical channel is a logical channel corresponding to a Push type NRT broadcast service, and a service name of the Push type NRT broadcast service are described. Furthermore, an outline of the Push-type NRT broadcast service may be described.
  • “Push type NRT meta information” includes the storage size (storage capacity) required when receiving provision of the Push type NRT broadcast service, and the minimum interval (time for content distribution in the Push type NRT broadcast service). Interval) is described.
  • “Push-type NRT meta information” is a URL for connecting to an Internet server that performs various registrations and the like prior to processing such as charging. Etc. are also described.
  • the VCT of the present invention is configured as described above.
  • FIG. 15 is a diagram showing an example of NRT-IT used in the present invention.
  • Source_id is the same as that described above with reference to FIG. 14, is an ID for identifying a logical channel, and in fact, predetermined characters, numerical values, and the like are described. This makes it possible to associate the NRT-IT with any of the logical channels described in the channel unit description area 272-1 and the channel unit description area 272-2 in FIG. .
  • the “number of contents” is described as a numerical value or the like representing the number of contents to be broadcast in a predetermined unit time in the logical channel specified by “Source_id”.
  • Push-type NRT meta information is information necessary to realize Push-type NRT broadcasting, and information similar to that described with reference to FIG. 14 is described.
  • Push-type NRT meta information information indicating that the logical channel is a logical channel corresponding to a Push-type NRT broadcast service, and a service name of the Push-type NRT broadcast service are described. Furthermore, an outline of the Push-type NRT broadcast service may be described.
  • “Push type NRT meta information” includes the storage size (storage capacity) required when receiving provision of the Push type NRT broadcast service, and the minimum interval (time for content distribution in the Push type NRT broadcast service). Interval) is described.
  • “Push-type NRT meta information” is a URL for connecting to an Internet server that performs various registrations and the like prior to processing such as charging. Etc. are also described.
  • Information on one piece of content is described in the content unit description area 292-1, the content unit description area 292-2, and so on.
  • This description area is provided for the numerical value described in the "number of contents" described above. For example, when the number of contents to be broadcast per unit time on the logical channel is 5, the numerical value "5" is described in the "number of contents”. Then, the content unit description area 292-1, the content unit description area 292-2,... And the channel unit description area 292-5 are described.
  • Content_item_id is an ID for identifying the content, and in fact, predetermined characters, numerical values, and the like are described. That is, the content unit description area 292-1 is an area where information on one piece of content identified by the "content_item_id" is described.
  • the “content version” describes information representing the version of the content. For example, when the contents of the first version (content1 (v1)) and the second version (content1 (v2)) described above with reference to FIG. 13 exist, the contents of “content1 (v1)” and “content1 (v2)” “Content_item_id” is the same. Therefore, “content version” is described as information for identifying content having the same “content_item_id” and different versions.
  • Distribution schedule describes information indicating the broadcast start time and the broadcast end time of the content. Since the content is NRT broadcast content, the broadcast start time and the broadcast end time do not represent the time for which the content can be viewed, but the time to start downloading the content and the time to finish downloading the content Is represented.
  • the “content expiration date” describes information specifying the time when the content expiration date will be.
  • the content whose expiration date has passed is deleted from the recording medium of the receiving device 41 or the like, and can not be reproduced.
  • the “content transfer location information” describes the IP address, the UDP port number, and the identifier “TSI” for identifying a FLUTE session, as described above with reference to FIG. By specifying this "content transmission location information", it is possible to identify data of one content specified by "content_item_id” among data transmitted on the logical channel specified by "Source_id”. It will be.
  • the NRT-IT of the present invention is configured as described above.
  • the information necessary for realizing Push-type NRT broadcasting may be described in VCT or may be described in NRT-IT.
  • NRT-IT the information necessary for realizing Push-type NRT broadcasting
  • the range indicated by a frame 291 in FIGS. 16 and 17 corresponds to the description area 291 in FIG. Further, the range indicated by a frame 292-1 in FIG. 17 corresponds to the description area 292-1 of the content unit in FIG.
  • one description area for each content is used to simplify the description.
  • each of the descriptors to be described in each description area is defined together with the number of bits (No. of Bits).
  • an 8-bit descriptor described in the area 310 represents an ID for identifying the type of this information, and a preset value is stored. This descriptor identifies that this information is NRT-IT.
  • the 16-bit descriptor described in the area 311 corresponds to “Source_id” described with reference to FIG. 15.
  • the descriptor described in the area 312 corresponds to the “Push type NRT meta information” described with reference to FIG. 15. The details will be described later with reference to FIG.
  • the 8-bit descriptor described in the area 313 corresponds to the “number of contents” described with reference to FIG.
  • the 14-bit descriptor described in the area 314 in FIG. 17 corresponds to the “content_item_id” described with reference to FIG.
  • the descriptor described in the area 316 describes information corresponding to the “delivery schedule” described with reference to FIG.
  • the descriptor described in the area 317 describes the information corresponding to the “content expiration date” described with reference to FIG. 15.
  • FIG. 18 is a diagram showing an example of syntax of “Push type NRT meta information” to be described in the area 312 of FIG.
  • each of the descriptors to be described in each description area is defined together with the number of bits (No. of Bits).
  • the 8-bit descriptor described in the area 341 of FIG. 18 indicates that the logical channel corresponds to a Push-type NRT broadcast service.
  • the service name of the Push-type NRT broadcast service is described by the descriptor described in the area 342 of FIG.
  • the descriptor described in the area 343 of FIG. 18 represents the minimum interval (time interval) of content delivery in the Push-type NRT broadcast service.
  • the descriptor described in the area 344 of FIG. 18 represents the storage size (storage capacity) required to receive the Push-type NRT broadcast service.
  • the URL for connecting to the Internet server that performs various registrations prior to processing such as charging is Described.
  • FIG. 19 is a block diagram showing a configuration example of the reception device 41 of FIG. In the figure, a signal based on a broadcast wave received via an antenna or the like (not shown) is supplied to a terminal 401.
  • the tuner 402 extracts a signal corresponding to a predetermined broadcast channel from the signal output from the terminal 401 based on the control of the controller 409, and outputs the signal as a digital signal to the TSDemux 403.
  • the TSDemux 403 generates a transport packet from the digital signal output from the tuner 402. Then, the TS Demux 403 extracts transport packets to which a predetermined identifier is added, based on the control of the controller 409, and outputs those transport packets as data of a predetermined logical channel.
  • the TS Demux 403 outputs the data of the logical channel to the video decoder 404 or the audio decoder 405.
  • the video decoder 404 and the audio decoder 405 respectively decode the encoded image data and the encoded audio data, and output an image signal and an audio signal to the terminal 410 and the terminal 411.
  • a display configured with a television receiver or the like and a speaker are connected to the terminal 410 and the terminal 411.
  • the TS Demux 403 outputs data of the logical channel to the FLUTE processor 407.
  • the FLUTE processor 407 obtains a file specified by the FLUTE session from data supplied as data of the logical channel, and records data configured by the file in the storage 408 as data of content. Note that metadata associated with content data, for example, generated by the controller 409 may also be recorded in the storage 408.
  • the storage 408 is, for example, a recording medium such as a hard disk drive (HDD), and records content data and other information necessary for the receiving device 41.
  • HDD hard disk drive
  • the file container Demux 406 reads data of content to be reproduced from the storage 408 under the control of the controller 409, and outputs the data to the video decoder 404 and the audio decoder 405. For example, when the content of the NRT broadcast recorded in the storage 408 is reproduced, the file container Demux 406 is configured to read the data of the content from the storage 408 based on the control of the controller 409.
  • the controller 409 is configured to have, for example, a processor, a memory, and the like, and controls each unit of the receiving device 41.
  • the controller 409 receives, for example, a signal such as a tuning instruction by the user, designation of content to be downloaded, or designation of content to be reproduced, which is supplied via a remote controller (not shown) or the like. Further, for example, the controller 409 generates display data of a graphical user interface (GUI) as necessary, and outputs the display data to the terminal 410 via the video decoder 404.
  • GUI graphical user interface
  • FIG. 20 is a view showing an example of an image displayed on the screen of the display connected to the receiving device 41. As shown in FIG.
  • the image shown in the figure is a GUI that displays a list of Push-type NRT broadcast services by the receiving device 41.
  • the GUI component in which “NRT” is displayed by the cursor 451 is selected.
  • an icon 452 and an icon 453 are displayed on the lower side of the GUI part displayed "NRT".
  • an image as shown in FIG. 21 is displayed on the screen of the display.
  • the image shown in the figure is a GUI that accepts registration of the Push-type NRT broadcast service "news clip”.
  • the reception apparatus 41 registers the Push-type NRT broadcast service “news clip”.
  • the receiver 41 registered with the Push-type NRT broadcast service "news clip” receives and stores the content of the "news clip”. Then, a list of contents downloaded by the receiving device 41 is displayed on the screen as a contents list shown in FIG. 22, for example.
  • “XXXX” displays the title of each content and information included in the metadata of the content.
  • the user of the reception device 41 displays the content list of FIG. 22 on the screen of the display or the like, and operates the GUI, for example, to select the content to be viewed. Thereby, the selected content is reproduced, and as shown in FIG. 23, the image of the content is displayed on the screen of the display. In this example, an image obtained by photographing the town is displayed as an image of the content.
  • Push-type NRT broadcast service registration processing by the receiving device 41 will be described with reference to the flowchart in FIG.
  • step S101 the controller 409 of the reception device 41 controls the tuner 402 to receive metadata about NRT broadcasting, control information, and the like.
  • PSIP data is received.
  • the PSIP data is data configured to include VCT, NRT-IT, etc., and is periodically received by the receiving device 41.
  • step S102 the controller 409 generates a list of Push-type NRT broadcast services.
  • the “Push type NRT meta information” described above with reference to FIG. 15 is checked for each of the NRT-ITs received in step S101. Then, in “Push type NRT meta information”, for example, it is determined whether or not the logical channel is a logic channel corresponding to a Push type NRT broadcast service by an 8-bit descriptor described in the area 341 of FIG. It is judged. When it is determined that the logical channel is a logical channel corresponding to a Push-type NRT broadcast service, the logical channel is determined based on the “channel name” and the “channel number” of the logical channel, and the descriptor of the area 342 of FIG. The service name of the Push NRT broadcast service is acquired.
  • the logical channel corresponding to the Push-type NRT broadcast service is specified. Then, a list of Push-type NRT broadcast services is generated and displayed as a GUI as described above with reference to FIG.
  • step S103 the controller 409 accepts the selection of a service by the user based on the list of Push-type NRT broadcast services generated in the process of step S102. At this time, a predetermined Push-type NRT broadcast service is selected.
  • step S104 the controller 409 stores “Source_id” corresponding to the Push-type NRT broadcast service selected in the process of step S103.
  • “Source_id” can be identified based on the NRT-IT received in step S101.
  • the storage size required to receive the Push-type NRT broadcast service is specified, and the storage area of the storage 408 is reserved. Ru.
  • the descriptor described in the area 345 of FIG. 18 is connected to the Internet server that performs various registrations prior to processing such as charging.
  • the URL for is specified. Then, based on the URL, the receiving device 41 accesses the Internet server, and the processing of the pay viewing subscription is executed.
  • Push-type NRT broadcast service registration processing is executed.
  • “Source_id” for specifying the logical channel corresponding to the registered Push type NRT broadcasting service is stored. It is
  • Push-type NRT broadcast reception and reproduction processing by the reception device 41 will be described with reference to the flowchart in FIG.
  • step S121 the controller 409 of the reception device 41 controls the tuner 402 to receive metadata about NRT broadcasting, control information, and the like.
  • PSIP data is received.
  • the PSIP data is data configured to include VCT, NRT-IT, etc., and is periodically received by the receiving device 41. Then, at the timing when the PSIP data is received, the download schedule generation process of step S122 is performed.
  • step S122 the controller 409 executes a download schedule generation process described later with reference to FIG. As a result, downloading of the Push-type NRT broadcast content is reserved.
  • step S122 of FIG. 25 a detailed example of the download schedule generation process of step S122 of FIG. 25 will be described with reference to the flowchart of FIG.
  • step S141 the controller 409 acquires the NRT-IT based on the "Source_id” stored in the process of step S104 in FIG. That is, among the NRT-ITs included in the PSIP data received in step S121, the NRT-IT corresponding to “Source_id” stored in the process of step S104 is extracted and acquired.
  • step S142 the controller 409 checks the description area of the NRT-IT content unit acquired in the process of step S141. At this time, for example, the description content of the description area 292-1 in the content unit of FIG. 15 is checked.
  • step S143 the controller 409 acquires “content_item_id” and “content version” described in the description area of the content unit checked in step S142.
  • step S 144 the controller 409 determines whether the same content is recorded in the storage 408. That is, it is determined whether "content_item_id" and “content version” have already received and stored the same content. If it is determined in step S144 that the same content is not recorded in the storage 408, the process proceeds to step S145.
  • step S145 the controller 409 determines whether downloading of the same content is scheduled. For example, in the case where the same content is broadcast twice repeatedly, such as “content1 (v1)” described above with reference to FIG. 13, the download may be performed by either one broadcast. Therefore, in step S145, it is determined whether the download of the same content is scheduled. If it is determined in step S145 that the download of the same content is not scheduled, the process proceeds to step S146.
  • step S146 the controller 409 acquires the “distribution schedule” described in the description area of the content unit checked in step S142. As a result, the broadcast start time and the broadcast end time of the content are acquired.
  • step S147 the controller 409 schedules download of the content corresponding to the description area of the content unit checked in step S142.
  • step S144 If it is determined in step S144 that the same content is recorded in the storage 408, the processing of steps S145 to S147 is skipped. In addition, when it is determined in step S145 that downloading of the same content is scheduled, the processes of steps S146 and S147 are skipped.
  • step S148 the controller 409 determines whether the NRT-IT acquired in the process of step S141 includes a description area for the next content unit. In the example of FIG. 15, since the description area 292-2 of the content unit is next to the description area 292-1 of the content unit, it is determined in step S148 that the description area of the next content unit is present. It returns to step S142.
  • step S142 the description content of the description area 292-2 in the content unit is checked, and the processing of step S143 to step S147 is repeatedly executed.
  • steps S142 to S148 is repeatedly performed until it is determined in step S148 that there is no description area for the next content unit. If it is determined in step S148 that there is no description area for the next content unit, the download schedule generation process ends.
  • the download schedule of the Push-type NRT broadcast content is stored in a memory or the like in the controller 409.
  • the download schedule is configured, for example, as a list of physical channels of the content to be downloaded, logical channels, information for specifying a FLUTE session, and the like. That is, the download schedule is, for example, reservation information for the reception device 41 to automatically execute download, as in conventional recording reservation information and the like.
  • the reception device 41 downloads the content according to the download schedule.
  • step S123 the controller 409 determines whether the broadcast start time of the content in the download schedule generated in the process of step S122 has come, and waits until it is determined that the broadcast start time has come. If it is determined in step S123 that the broadcast start time has come, the process proceeds to step S124.
  • step S124 the controller 409 controls the tuner 402, the TSDemux 403, and the FLUTE processor 407 to download content.
  • tuning of the tuner 402 of the receiving device 41 is set to the broadcast channel corresponding to the physical channel designated in the download schedule. Further, the TSDemux 403 outputs it to the data FLUTE processor 407 of the logical channel specified in the download schedule. Then, the FLUTE processor 407 acquires the file of the FLUTE session specified in the download schedule. When the broadcast end time of the content is reached, acquisition of all the files constituting the FLUTE session stream is completed in the reception device 41, whereby the download of the content is completed.
  • step S125 the controller 409 determines whether the content downloaded in the process of step S124 is to be overwritten on the content already recorded. For example, when the content already recorded and the “content_item_id” are the same and the content having a different “content version” is downloaded, it is determined that the content is to be overwritten.
  • step S125 it is determined whether to overwrite based on the storage size required to receive the Push-type NRT broadcast service designated by the descriptor described in the area 344 in FIG. Be done. That is, when it is necessary to record content data beyond the storage size designated in advance, it is determined that the content already recorded is to be overwritten. In this case, for example, the content downloaded in the process of step S124 is overwritten on the oldest content among the contents already recorded.
  • step S125 If it is determined in step S125 that the downloaded content is to be overwritten onto the already recorded content, the process proceeds to step S127, and the content downloaded in the process of step S124 is overwritten and recorded. As a result, the version of the content is updated.
  • step S125 when it is determined in step S125 that the downloaded content is not to be overwritten onto the content already recorded, the process proceeds to step S126, and the content downloaded in the process of step S124 is newly recorded in the storage 408 Ru.
  • Metadata of the content included in the information received in step S121 may also be recorded in association with the content.
  • the metadata includes, for example, “content name”, “distribution schedule”, “content expiration date” and the like described in NRT-IT.
  • step S128 the controller 409 displays the list of contents recorded in the process of step S126 or step S127. At this time, for example, an image as shown in FIG. 22 is generated and displayed on the display.
  • the expiration date is set for each content, and the content whose expiration date has passed is not included in the content list displayed in step S128.
  • the expiration date can be specified based on, for example, the “content expiration date” described with reference to FIG.
  • step S129 the controller 409 receives the selection of content by the user based on the list of content displayed in the process of step S128. At this time, for example, among the contents of the NRT broadcast already recorded in the storage 408, the contents that the user wants to view are selected.
  • step S130 the controller 409 controls the file container Demux 406 to reproduce the content of which selection is accepted in the process of step S129. Thereby, for example, as shown in FIG. 23, the image of the content is displayed on the display.
  • Push-type NRT broadcast reception and reproduction processing by the reception device 41 is executed.
  • the receiving device 41 in which the Push-type NRT broadcast service is registered automatically downloads all of the content transmitted on the logical channel corresponding to the service. Therefore, Push-type NRT service can be realized without making a large-scale change of existing facilities and standards.
  • the broadcast wave of the NRT broadcast received by the receiver 41 of the present invention is transmitted by the transmitter 21.
  • the transmission device 21 is configured to have, for example, a multiplexing unit that generates a signal in which data such as meta information and control information is multiplexed and data of content.
  • Content data is data including, for example, image data and audio data compressed and encoded in the MPEG system by an AV encoder that encodes video data and audio data.
  • Data such as meta information and control information is data configured of, for example, PSIP data.
  • the transmitting device 21 generates, for example, VCT and NRT-IT corresponding to a predetermined broadcast schedule, and generates, as additional data, data configured by PSIP data including VCT and NRT-IT. Then, based on the broadcast schedule, the transmission device 21 generates a signal in which the additional data and the data of the content are multiplexed by the multiplexing unit, modulates the signal, and outputs the signal as a broadcast wave.
  • step S161 the control unit of the transmission device 21 acquires a broadcast schedule.
  • the information regarding the content to be broadcast mentioned later shall be included in the broadcast schedule.
  • step S162 the control unit of the transmission device 21 acquires information on the content to be broadcast.
  • the information regarding content includes, for example, “content_item_id”, “distribution schedule”, “content expiration date”, “content name”, information indicating whether it is Push type content or Pull type content, etc. .
  • step S163 the control unit of the transmission device 21 determines whether the content related to the information acquired in the process of step S162 is a Push-type NRT broadcast content. In practice, the process of step S163 is executed for each of the plurality of contents described in the broadcast schedule.
  • step S163 If it is determined in step S163 that the content related to the information acquired in the process of step S162 is a Push-type NRT broadcast content, the process proceeds to step S164.
  • step S164 the control unit of the transmission device 21 generates an NRT-IT for Push-type broadcasting. At this time, for example, the NRT-IT described above with reference to FIG. 15 is generated.
  • step S163 If it is determined in step S163 that the content related to the information acquired in the process of step S162 is not a Push-type NRT broadcast content, the process proceeds to step S165.
  • step S165 the control unit of the transmission device 21 generates an NRT-IT for Pull-type broadcasting. At this time, for example, the NRT-IT described above with reference to FIG. 8 is generated.
  • step S166 the control unit of the transmission device 21 generates a VCT.
  • step S167 the control unit of the transmission device 21 generates additional data configured by PSIP data including VCT and NRT-IT.
  • step S168 the multiplexing unit of the transmission device 21 generates a signal in which the additional data and the data of the content are multiplexed based on the broadcast schedule.
  • data to be broadcasted on a plurality of logical channels is multiplexed as data to be broadcasted on one physical channel.
  • step S169 the transmission device 21 modulates the signal generated in the process of step S168, and outputs the broadcast wave of the signal modulated in the process of step S169 in step S170.
  • Push-type NRT meta information information necessary for realizing Push-type NRT broadcasting
  • NRT-IT information necessary for realizing Push-type NRT broadcasting
  • the information necessary to realize Push-type NRT broadcasting may be described in VCT, for example, as described with reference to FIG.
  • Push-type NRT service can be realized without making a large-scale change of existing facilities and standards.
  • Push-type NRT meta information is directly described in VCT. Such information may be described in another control information.
  • the description area 272-2 of the channel unit instead of “Push type NRT meta information” described in the description area 272-1 of the channel unit, the description area 272-2 of the channel unit, ..., “normal / NRT identification information” To be described.
  • the “normal / NRT identification information” is information indicating whether the logical channel is a normal broadcast logical channel or an NRT broadcast logical channel. Then, when the logical channel is a logical channel of NRT broadcasting, the receiving apparatus 41 adds SMT (Service Map Table) to VCT to be received. Then, information necessary for realizing Push-type NRT broadcasting (for example, “Push-type NRT meta information”) is described in the SMT.
  • SMT Service Map Table
  • an SMT is generated for each physical channel.
  • TS_id is an ID for identifying a transport stream, and in fact, predetermined characters, numerical values, and the like are described. This makes it possible to identify which physical channel (broadcast channel) is the VCT. For example, the SMT is identified based on the “TS_id”.
  • Source_id is an ID for identifying the logical channel, and in fact, predetermined characters, numerical values, and the like are described. That is, the channel unit description area 272-1 is an area where information on one logical channel specified by the "Source_id” is described.
  • Source_id is the same as that described above with reference to FIG. 14, is an ID for identifying a logical channel, and in fact, predetermined characters, numerical values, and the like are described. This makes it possible to associate the NRT-IT with any of the logical channels described in the channel unit description area 272-1 and the channel unit description area 272-2 in FIG. .
  • NRT-IT is generated on a logical channel basis.
  • NRT-IT can also be referred to as an example of metadata of content broadcasted on a logical channel.
  • the content broadcasted on one logical channel can be received as the Push-type NRT broadcast content.
  • contents broadcasted in a predetermined time zone are contents of Pull type NRT broadcast
  • contents broadcasted in another time zone are contents of Push type NRT broadcast It can also be received as
  • the VCT and the SMT may be configured and transmitted as described above.
  • the FLUTE session is specified by the “content transmission location information”, and data constituting the FLUTE session stream is acquired.
  • the FLUTE session stream is actually made up of a plurality of files divided into predetermined sizes, and each of the plurality of files is given "TOI".
  • TOI data of content transmitted by a predetermined FLUTE session is acquired based on FDT which is a file whose “TOI” is 0.
  • the FLUTE session can also be referred to as an example of a file transmission session used to transmit content data, and the FDT can be considered as control information of a file transmission session and an example of transmission control data.
  • application software such as a browser is implemented in the receiving device 41. Then, it makes it possible to analyze the address file described in RSS using the function of the browser's RSS reader.
  • RSS RDF Site Summary
  • XML extensible Markup Language
  • FIG. 28 is a diagram for explaining an example of the case where a file constituting content is acquired using an address file described in the RSS format.
  • “content transmission location information” for each content is described in the content area of the NRT-IT.
  • a FLUTE session is identified, and data constituting the FLUTE session stream is acquired.
  • “TOI” is attached to each of the plurality of files in the FLUTE session stream, and an FDT with “TOI” of 0 is acquired.
  • an XML sentence beginning with “ ⁇ File” is described in the area 501 which is a part of the FDT description area.
  • the receiving device 41 can reproduce the content by acquiring the file having the “TOI” of 2 as the file of the content, and decoding the file compressed and encoded in the MPEG4 format.
  • the receiving device 41 can be configured as, for example, a personal computer or the like on which application software such as a browser is implemented.
  • FIG. 29 shows an example of an address file described in RSS format.
  • the description “ ⁇ title> News Headline by XYZ ⁇ / title>” in the area 521 indicates that the title of the content specified by the address file is “News Headline by XYZ”.
  • application software such as a browser can be implemented in the receiving device 41, and an address file described in RSS can be analyzed using the function of the RSS reader of the browser. It becomes. Therefore, for example, it is possible to receive and view the content by the same device and method as in the case of browsing a WEB page on the Internet. Note that the method of viewing content using an address file described in the RSS format can be applied to both Push-type NRT broadcasting and Pull-type NRT broadcasting.
  • the download of the content in step S16 of FIG. 10 or step S124 of FIG. 25 may be performed by acquiring the content file as described above with reference to FIGS. 28 and 29. That is, an address file is specified based on the FDT, and a file constituting the content is acquired based on the address information described in the address file, so that the content is downloaded. It is also good. Further, in this case, the data of the content transmitted by the transmission device 21 is configured to include the address file in addition to the FDT and the content file as described above.
  • VCT 210, the NRT-IT 211, and the NRT-IT 212 are first received, and the logical channel through which the content A and content B are transmitted and the file of the FLUTE session are specified. Further, it has been described that VCT 220, NRT-IT 221 and NRT-IT 222 are newly received and updated, and the logical channel through which content C is transmitted and the file of FLUTE session are specified based on VCT 220 and NRT-IT 221.
  • new content is transmitted and viewed on the receiving device 41 without newly receiving the VCT and NRT-IT on the receiving device 41. be able to.
  • the contents of the FDT and the address file transmitted in the FLUTE session of the logical channel are changed at a predetermined timing. It is By doing this, even if the receiving apparatus 41 does not newly receive VCT and NRT-IT, new contents can be transmitted and viewed on the receiving apparatus 41.
  • FIG. 30 is a diagram for explaining a method for transmitting new content and allowing the receiving device 41 to view the content without newly receiving the VCT and NRT-IT.
  • the vertical axis in the figure represents time, and the arrow S represents the update cycle of VCT and NRT-IT.
  • the update cycle of VCT and NRT-IT is equal to the transmission cycle of PSIP data.
  • FDT instance 02 is an FDT file with a TOI of 0
  • RSS 02 is an address file described in the RSS format specified by “FDT instance 02”.
  • Content file 02 is a file of content specified by "FDT instance 02" and "RSS 02".
  • the reception device 41 can receive content D from 9 o'clock to 10 o'clock, After 10 o'clock, the content E can be received.
  • 31 and 32 show examples of the address file described in the RSS format used in the example of FIG.
  • FIG. 31 shows an address file corresponding to “RSS 01” in FIG. Since the areas 541 and 542 in the same figure are the areas which describe the same contents as the areas 521 and 522 of FIG. 29, respectively, the detailed description will be omitted.
  • an area 543 is provided in the example of FIG. In the area 543, “ ⁇ pubDate> Tue, 10 Jun 2003 09:00:00 GMT ⁇ / pubDate>” is described. This represents that the address file was generated at 9:00 (GMT (Greenwich Mean Time)) on June 10, 2003 (Tuesday) in the Christian era.
  • GTT Greenwich Mean Time
  • Region 544 describes “ ⁇ skipHours> ⁇ hour> 9 ⁇ / hour> ⁇ / skipHours>”.
  • This description is a description of "skipHours” element defined as a description format of RSS.
  • the “skipHours” element is a description specifying a time zone for prohibiting crawling, and crawling in the time zone corresponding to the numerical value described in the part enclosed by the “ ⁇ hour>” tag is prohibited.
  • the file is not updated (no crawling) for one hour from 9:00 on June 10, 2003.
  • the receiving device 41 receives VCT and NRT-IT at the time corresponding to the upper end of the arrow S in FIG. 30, and specifies the logical channel and the FLUTE session. Thus, the receiving apparatus 41 automatically acquires “FDT instance 01” at 9 o'clock, and also acquires the address file shown in FIG. 31 based on this. Receiving the address file shown in FIG. 31, the receiving apparatus 41 obtains the “content file 01” with reference to the area corresponding to the area 502 (FIG. 28) in the “FDT instance 01” at 9:00. Then, until one hour, that is, ten o'clock, the "content file 01" is not acquired. Further, the receiving device 41 which has acquired the address file shown in FIG. 31 automatically acquires (crawls) the content file after one hour from 9 o'clock.
  • FDT instance 02 is transmitted as a file having a TOI of 0.
  • the “FDT instance 02” is acquired by the receiver 41 regardless of the description regarding the “skipHours” element. This is because FDT is a file automatically acquired in the FLUTE session of the logical channel specified by the receiving device 41 based on VCT and NRT-IT.
  • the receiving device 41 automatically acquires "FDT instance 02". Also, as described above, at 10 o'clock, the receiving device 41 performs processing for automatically acquiring a content file based on the description content of the address file shown in FIG. Acquisition of the file here is performed based on the description regarding the "skipHours" element of FIG.
  • the reception apparatus 41 also acquires the address file shown in FIG. 32 based on the description of “FDT instance 02”. This is because the address file specified by "FDT instance 02" is "RSS 02".
  • FIG. 32 shows an address file corresponding to “RSS 02” in FIG.
  • the description of the area 541 and the description of the area 542 are the same as in the case of FIG. 31, and thus the detailed description will be omitted.
  • an area 543 describes “ ⁇ pubDate> Tue, 10 Jun 2003 10:00:00 GMT ⁇ / pubDate>”. This indicates that the address file is generated at 10 o'clock (GMT (Greenwich Mean Time)) on June 10, 2003 (Tuesday) in the Christian era.
  • An area 544 describes “ ⁇ skipHours> ⁇ hour> 10 ⁇ / hour> ⁇ / skipHours>”. This means that the file is not updated (does not crawl) for one hour from 10 o'clock on June 10, 2003 in the Christian era.
  • the receiving apparatus 41 that has acquired the address file shown in FIG. 32 acquires “content file 02” with reference to the area corresponding to the area 502 (FIG. 28) in “FDT instance 02” at 10:00. . Then, until one hour, that is, 11 o'clock, the "content file 02" is not acquired. Further, the receiving device 41 which has acquired the address file shown in FIG. 32 automatically acquires (crawls) the file after one hour from 10 o'clock.
  • FDT instance 02 is acquired as a file having a TOI of 0, regardless of the description of the "skipHours” element. This is because FDT is a file automatically acquired in the FLUTE session of the logical channel specified by the receiving device 41 based on VCT and NRT-IT.
  • the receiving device 41 when the receiving device 41 that has acquired the address file shown in FIG. 32 comes at 11:00 as described above, the receiving device 41 automatically generates a content file based on the description content of the address file shown in FIG. 32. Do the process of acquiring. Acquisition of the file here is performed based on the description regarding the "skipHours" element of FIG.
  • the receiving apparatus 41 also acquires the address file shown in FIG. 32 based on the description of “FDT instance 02”. This is because the address file specified by "FDT instance 02" is "RSS 02". Then, the “content file 02” is acquired again with reference to the area corresponding to the area 502 (FIG. 28) in the “FDT instance 02”. In this case, as a result, the file of the content acquired at 10 o'clock and the file of the content acquired at 11 o'clock have the same content ("content file 02").
  • new contents can be transmitted and viewed on the receiving device 41 without the receiving device 41 newly receiving VCT and NRT-IT.
  • the download of the content in step S16 of FIG. 10 or step S124 of FIG. 25 may be performed by acquiring the content file as described above with reference to FIGS. 30 to 32. . That is, based on FDT, an address file is specified, and based on the address information described in the address file, a file constituting the content is acquired. In addition, the content is downloaded by repeatedly acquiring the content file based on the information (for example, the description related to the “skipHours” element) for controlling the acquisition time zone of the file described in the address file. May be
  • Push-type NRT broadcasting In the examples described above, an embodiment has been described mainly enabling Push-type NRT broadcasting to be realized in a system that conforms to the Advanced Television Systems Committee (ATSC) standard. However, for example, it is possible to realize Push-type NRT broadcasting in a manner that conforms to the standard of Association of Radio Industries and Businesses (ARIB).
  • ATSC Advanced Television Systems Committee
  • ARIB Association of Radio Industries and Businesses
  • broadcasted programs are classified into groups.
  • the group is, for example, a unit in the case where programs broadcasted in series are collectively represented.
  • the groups are structured hierarchically, and for example, one group can be a parent group, and a plurality of child groups can be included in the parent group. It is also possible to think of this group as a logical channel in which physical channels are multiplexed as described later.
  • Programs have almost the same meaning as content, and for example, one group includes a plurality of programs.
  • NRT broadcast according to ARIB standards, in principle, it is assumed that the user of the receiver 41 makes a viewing contract for NRT broadcast in advance and pays a fee. That is, only the user who paid the fee can view the program that is the subject of the viewing contract.
  • files such as image data and audio data that constitute a program are encrypted and broadcast, and the receiving device 41 of the user who paid the fee acquires the license of the received program and decrypts the file of the program It is done.
  • FIG. 33 is a diagram for explaining a protocol stack in a broadcast wave signal including NRT broadcast according to ARIB standard.
  • the NRT broadcast according to ARIB standards is called satellite download broadcast.
  • the lowest layer is considered as the “physical layer”, and the frequency band of the broadcast wave allocated for satellite download broadcasting corresponds to this.
  • the upper hierarchy adjacent to the "physical layer” is considered as "slot".
  • the “slot” is a time-division transmission band, and for example, 48 slots are allocated to one broadcast channel.
  • TLV Type Length Value
  • all signals transmitted in the transmission band corresponding to one broadcast channel are transmitted by TLV packets having header information and the like corresponding to the broadcast channel.
  • the TLV stream transmission rate is assigned to each physical channel (broadcast channel).
  • IP Multicast
  • Header compression IP Multicast
  • TLV-NIT Network Information Table
  • AMT Address Map Table
  • IP (Multicast) is an IP packet of Multicast format.
  • Header compression IP (Multicast)” reduces transmission overhead by compressing the header of an IP packet. For example, instead of transmitting all header information of all packets, a packet of full header is intermittently transmitted, and other packets are replaced with compressed header and transmitted, and header information corresponding to a protocol for recovering header information on the receiving side It is assumed that the IP packet is attached.
  • TLV-NIT Network Information Table
  • AMT Address Map Table
  • the upper layer adjacent to “IP (Multicast)” and “header compression IP (Multicast)” is "UDP", and "data transmission protocol” is displayed as the upper layer.
  • the “data transmission protocol” is a hierarchy corresponding to a predetermined protocol for transmitting a file in which “ECG metadata” or “TTS” is stored. Based on this data transmission protocol, a download header to be described later is generated.
  • TTS Timestamped TS
  • TS packets fixed-length transport packets
  • TMS Video Coding (encoded image data)
  • Audio Coding encoded audio data
  • subtitle Coding encoded subtitle data
  • ECG metadata is a hierarchy in which data constituting ECG metadata to be described later is divided into packets of a fixed length and transmitted.
  • TTS transmission side protocol
  • ECG metadata ECG metadata
  • one broadcast channel (so-called physical channel) having a transmission band corresponding to the transmission rate of the TLV packet of "TLV" is grouped It is possible to multiplex into multiple logical channels, referred to as
  • group attribute table which is control information on logical channels (groups) generated for each broadcast channel
  • purchase attribute table which is control information corresponding to a user's viewing contract. ing.
  • the group attribute table and the purchase attribute table are information included in the ECG metadata, respectively, and the details will be described later.
  • the "group ID” which is the identifier of the group including the program to be downloaded is identified, and the "CRID” which is the program identifier is identified based on the "group ID”. Ru. Then, the IP address and port number of the IP packet to be received are specified based on “CRID”. Further, by referring to “TLV-NIT” and “AMT”, the identifier given to the TLV packet is specified, and the target IP packet is extracted.
  • a predetermined IP address and port number are added to the IP packet in which the ECG metadata is stored.
  • the IP address and port number of the ECG metadata are stored in advance in the receiving device 41.
  • the receiving device 41 specifies the identifier given to the TLV packet by referring to “TLV-NIT” and “AMT” based on the IP address and port number stored in advance, and the ECG meta It can retrieve IP packets of data.
  • the “group ID”, which is the identifier of the group including the program to be downloaded, is identified based on the group attribute table and the purchase attribute table included in the ECG metadata thus obtained. is there.
  • the ECG metadata includes a group attribute table, a program attribute table, a program location table, a purchase attribute table, a license attribute table, and a download control information table.
  • FIG. 34 is a diagram showing an example of a group attribute table (Group Information) used in the present invention.
  • the group attribute table is generated for each group.
  • the receiver 41 for receiving Push-type NRT broadcasts is configured to receive all the programs included in the group corresponding to the Push-type NRT broadcast.
  • the “group ID” is an identifier for identifying the group.
  • sales conditions of programs belonging to the group are described in the "group type". For example, when a program belonging to the group is broadcasted as a series of 10 times, information indicating whether the program is sold 10 times at once or a program sold separately is described.
  • Push-type NRT broadcasting and Pull-type NRT broadcasting do not differ in download method, but differ in data storage method after download.
  • the receiving device 41 determines whether or not to overwrite and record the data of the newly downloaded program. By doing this, when the user makes a viewing contract for Push-type NRT broadcast, the program data is automatically overwritten and recorded on the recording medium of the receiving device 41 thereafter.
  • a user who has made a subscription contract for Push-type NRT broadcast of "weather forecast” can always view the latest forecast.
  • the “group / number of programs” describes the group (child group) belonging to the group and the number of programs belonging to the group.
  • thumbnail images of programs belonging to the group is attached to "title media”.
  • the group attribute table is configured in this way.
  • FIG. 35 is a diagram showing an example of a program attribute table (Program Information) used in the present invention.
  • the program attribute table is generated for each program.
  • CID is an identifier that identifies the program.
  • the "group ID” describes the "group ID” of the group to which the program belongs.
  • thumbnail images of the program For example, data of thumbnail images of the program is attached to the “title media”.
  • the program attribute table is configured in this way.
  • FIG. 36 is a diagram showing an example of a purchase attribute table (Purchase Information).
  • “Purchase ID”, “group ID / program ID”, “charge”,... are described in the purchase attribute table.
  • the purchase attribute table is generated for each viewing contract of a group or program (content).
  • “Purchase ID” is an identifier that identifies the viewing contract.
  • group ID and the “program ID (ie, CRID)" are described in the "group ID / program ID” for the group or program that is the target of the viewing contract.
  • the purchase attribute table is configured in this way.
  • FIG. 37 is a diagram illustrating an example of a license attribute table (License Information).
  • “license ID”, “CRID”, “Purchase ID”, “use condition”,... are described in the license attribute table.
  • the license attribute table is generated for each viewing contract of the program (content).
  • “License ID” is an identifier of a license corresponding to the viewing contract, and at the same time, for example, is information of an address of a storage area in which a key for decrypting a file of an encrypted program is stored.
  • the receiving device 41 that has acquired the “license ID” accesses a server of a broadcasting station connected via the network based on the address. That is, the above address specifies a predetermined storage area of the server of the broadcast station, and the storage area stores a key for decrypting the file of the encrypted program.
  • the receiving device 41 when accessing the server of the broadcasting station, the receiving device 41 transmits “Purchase ID” and its identification information and the like to receive server authentication. If authentication is successful, it is possible to obtain a key for decrypting the file from the server.
  • the “use condition” describes, for example, information representing the number of times the file of the program can be decoded by the license (the number of times the content can be reproduced).
  • the license attribute table is configured in this way.
  • FIG. 38 is a diagram showing an example of a program location table (Program Location).
  • Program Location Program Location
  • “CRID”, “reference URL of program”, “Purchase ID”,... are described in the program location table.
  • the program location table is generated for each program.
  • Purchase ID describes “Purchase ID” of a viewing contract for the program.
  • the program location table is configured in this way.
  • FIG. 39 is a diagram illustrating an example of download control information (Download Control Information).
  • Download Control Information Download Control Information
  • “CRID”, “broadcast schedule”,... are described in the download control information. Download control information is generated for each program.
  • the "broadcast schedule” describes the broadcast channel, the broadcast start time, the broadcast end time, etc. of the program.
  • IP address and port number of the packet for transmitting the file of the program are described in the download control information.
  • the download control information is configured in this way.
  • Each of the group attribute table, the program attribute table, the program location table, the purchase attribute table, the license attribute table, and the download control information table described above is actually described as an XML sentence.
  • the user of the receiving device 41 that has received the ECG metadata determines a Push-type NRT broadcast that he / she wishes to view, with reference to the “title name”, “outline”, etc. included in the group attribute table. Then, the user makes a viewing contract according to a predetermined procedure and pays a fee necessary for the viewing contract of the Push type NRT broadcast.
  • the identification information of the receiving device 41 of the user who paid the fee is stored in association with the “Purchase ID” corresponding to the viewing contract concluded by the payment of the fee.
  • “Purchase ID” corresponding to the viewing contract concluded by the payment of the fee is stored.
  • the receiving device 41 that has received the broadcast after the viewing contract and the fee payment acquires the purchase attribute table, the license attribute table, and the program location table included in the ECG metadata based on the stored “Purchase ID”.
  • the reception device 41 acquires download control information included in the ECG metadata based on the URL described in the program location table.
  • the receiving device 41 specifies the broadcast schedule described in the download control information, thereby specifying the broadcast start time and broadcast end time of the program, the broadcast channel, the IP address, the port number, and the like.
  • the download schedule of the NRT broadcast program is stored in a memory or the like in the controller 409.
  • the receiving device 41 downloads the file constituting the program according to the download schedule, and specifies the address where the decryption key is stored using the license ID described in the license attribute table acquired based on “Purchase ID”. Then, for example, the receiving device 41 accesses the above-described address via the network to obtain a decryption key, and decrypts and reproduces the encrypted file.
  • NRT broadcast reception processing in the case where the receiver 41 receives NRT broadcast by a method conforming to the ARIB standard will be described.
  • step S201 the receiving device 41 acquires ECG metadata.
  • the receiving device 41 specifies the identifier given to the TLV packet by referring to “TLV-NIT” and “AMT” based on the IP address and port number stored in advance. Then, the receiving device 41 acquires ECG metadata by extracting an IP packet of ECG metadata from the identified TLV packet.
  • step S202 the receiving device 41 identifies "group ID”. At this time, the receiving device 41 acquires the purchase attribute table, the license attribute table, and the program location table included in the ECG metadata based on the stored “Purchase ID”. Then, the "group ID" included in the purchase attribute table is specified.
  • step S203 the receiving device 41 acquires a group attribute table based on the "group ID" identified in the process of step S202, and identifies a "group type".
  • step S204 the receiving device 41 generates a download schedule.
  • download control information is acquired based on the URL described in the program location table acquired along with the process of step S202.
  • the receiving device 41 specifies the broadcast schedule described in the download control information, thereby specifying the broadcast start time and broadcast end time of the program, the broadcast channel, the IP address, the port number, and the like.
  • the download schedule of the NRT broadcast program is stored in a memory or the like in the controller 409.
  • step S205 the receiving device 41 downloads program data based on the download schedule generated in the process of step S204.
  • step S206 the receiving device 41 associates the data of the program downloaded in the process of step S205 with the "group ID" and the "group type” specified in the processes of steps S202 and S203.
  • step S207 the receiving apparatus 41 determines whether the program downloaded in the process of step S205 is a Push-type NRT broadcast program. At this time, based on the “group type” associated in the process of step S206, it is determined whether the program is a Push-type NRT broadcast program.
  • step S207 If it is determined in step S207 that the program downloaded in the process of step S205 is a Push-type NRT broadcast program, the process proceeds to step S208.
  • step S208 the receiving device 41 overwrites and records the data of the program.
  • step S207 if it is determined in step S207 that the program downloaded in the process of step S205 is not a Push-type NRT broadcast program, the process proceeds to step S209.
  • step S209 the receiving device 41 records the program data without overwriting it.
  • step S208 or step S209 the downloaded program data is recorded in the recording medium in association with the "group ID" and the "group type".
  • the data obtained by downloading the Push-type NRT broadcast program is overwritten when another program belonging to the same group is downloaded (processing of step S208).
  • it is data of a program associated with the same "group ID" as the "group ID" specified in the process of step S202, and is downloaded by the process of step S205 to data of the program recorded earlier. Program data is overwritten.
  • the overwriting as described above is not performed (processing of step S209).
  • step S207 it is determined whether the receiving device 41 overwrites and records the data of the newly downloaded program based on the "group ID" and the "group type” (processing of step S207). .
  • the program data is automatically overwritten and recorded on the recording medium of the receiving device 41 thereafter.
  • a central processing unit (CPU) 701 executes various processes according to a program stored in a read only memory (ROM) 702 or a program loaded from a storage unit 708 to a random access memory (RAM) 703. Do.
  • the RAM 703 also stores data necessary for the CPU 701 to execute various processes.
  • the CPU 701, the ROM 702, and the RAM 703 are connected to one another via a bus 704.
  • An input / output interface 705 is also connected to the bus 704.
  • the input / output interface 705 is connected to an input unit 706 including a keyboard and a mouse, a display including an LCD (Liquid Crystal display) and the like, and an output unit 707 including a speaker and the like. Further, to the input / output interface 705, a storage unit 708 configured by a hard disk or the like, and a communication unit 709 configured by a network interface card such as a modem or a LAN card are connected. A communication unit 709 performs communication processing via a network including the Internet.
  • a drive 710 is connected to the input / output interface 705 as necessary, and a removable medium 711 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory is appropriately attached. Then, computer programs read from those removable media are installed in the storage unit 708 as necessary.
  • a program constituting the software is installed from a network such as the Internet or a recording medium such as a removable medium 711 or the like.
  • this recording medium is a magnetic disk (including a floppy disk (registered trademark) having a program recorded therein, which is distributed for distributing the program to the user separately from the apparatus main body shown in FIG.
  • Removable media consisting of an optical disk (including a compact disk-read only memory (CD-ROM) and a digital versatile disk (DVD)), a magneto-optical disk (including a mini-disk (MD) (registered trademark)) or a semiconductor memory
  • the configuration also includes one configured by the ROM 702 in which the program is recorded, delivered to the user in a state incorporated in advance in the apparatus main body, a hard disk included in the storage unit 708, and the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Databases & Information Systems (AREA)
  • Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Human Computer Interaction (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Television Signal Processing For Recording (AREA)
  • Circuits Of Receivers In General (AREA)

Abstract

 本発明は、Push型NRTサービスを実現することができるようにすることができるコンテンツ受信装置および方法、コンテンツ送信装置および方法、プログラム、並びに記録媒体に関する。 「Ch.4」は、通常放送の放送チャンネルとされ、「Ch.5」、および「Ch.6」は、NRTの放送チャンネルとされる。放送チャンネル「Ch.5」が論理チャンネル「VC5-1」、「VC5-2」、および「VC5-3」に多重化されている。論理チャンネル「VC5-1」は、1つのPush型NRT放送のサービスに割り当てられ、「VC5-2」は、Pull型NRT放送に割り当てられる。論理チャンネル「VC5-3」は、別の1つのPush型NRT放送のサービスに割り当てられる。「VC5-2」には、3つのFLUTEセッションが設けられる。

Description

コンテンツ受信装置および方法、コンテンツ送信装置および方法、プログラム、並びに記録媒体
 本発明は、コンテンツ受信装置および方法、コンテンツ送信装置および方法、プログラム、並びに記録媒体に関し、特に、Push型NRTサービスを実現することができるようにするコンテンツ受信装置および方法、コンテンツ送信装置および方法、プログラム、並びに記録媒体に関する。
 近年、デジタル放送の普及により、多チャンネル、或いは高精細なテレビジョン放送の受信が一般的になっている。
 一方で、デジタル放送で利用可能な帯域を利用して、通常のテレビジョン放送だけでなく、視聴者が求めるさらに高度な放送サービスを可能とするための技術検討、方式策定が行われつつある。
 視聴者の求める機能として、視聴者が視聴したい時にコンテンツを視聴することができるようにするオンデマンド視聴が挙げられる。しかしながら、双方向ではなく、一方向伝送の放送においてオンデマンド視聴を実現することは困難とされてきた。
 そこで、一方向伝送の放送においてオンデマンド視聴を可能とするために、受信端末が大容量のストレージを保有することを前提として、放送されたコンテンツを一旦ストレージに記録した後に、再生するNRTサービスが検討されている。NRT(Non-RealTime)サービスは、リアルタイムでの視聴を前提とせず、コンテンツの放送時刻に同期してコンテンツを視聴する必要がなく、コンテンツをデータとして放送信号により送信するものである。
 すなわち、NRTサービスでは、従来の放送番組のコンテンツの録画予約などとは異なり、例えば、放送波による信号の伝送帯域が大きい場合、より短時間で録画(ダウンロード)が完了するようにすることが可能である。あるいはまた、例えば、放送波による信号の伝送帯域が小さい場合、より長時間でダウンロードが完了することになる。
 また、近年、コンテンツの提供方式が多様化してきている。例えば、従来、ユーザが所望のコンテンツをリクエストし、そのコンテンツが提供されるものが主流であった。しかし近年は、リクエストしなくても、サーバ側が一方的にコンテンツをユーザに配信するPush型配信と称される提供方式も採用されている(例えば、特許文献1参照)。
 NRTサービスにおいても、視聴者が個々のコンテンツを選択した後、受信し蓄積する方式と、視聴者が特定のコンテンツの集合を視聴する登録を行った上で、端末がこれらのコンテンツを自動的に受信し蓄積する方式の二通りの方式が考えられる。前者の方式は、例えば、Pull型NRTサービスと称され、後者の方式は、例えば、Push型NRTサービスと称される。
特開2007-035135号公報
 Pull型NRTサービスに関しては、既に実現の方法が想定されているが、Push型NRTサービスに関しては、まだ実現方法が想定されていない。
 本発明はこのような状況に鑑みてなされたものであり、Push型NRTサービスを実現することができるようにするものである。
 本発明の第1の側面は、放送波として送信される信号に基づいて、再生レートと同期しない伝送レートでのコンテンツの放送に関する制御情報を受信する制御情報受信手段と、前記制御情報に基づいて、予め設定された登録情報に対応する論理チャンネルで放送されるコンテンツを受信して記録するための予約情報であって、ダウンロードスケジュールを生成するダウンロードスケジュール生成手段と、前記ダウンロードスケジュールに基づいて、前記コンテンツのそれぞれを受信して記録媒体に記録するダウンロード手段と、前記記録媒体に記録されたコンテンツを、前記再生レートで再生する再生手段とを備えるコンテンツ受信装置である。
 前記コンテンツの放送に関する制御情報には、前記周波数帯域の放送波の信号の伝送路を物理チャンネルとした場合、前記物理チャンネルを所定の方式で複数の伝送路に分割することにより得られる論理チャンネルに関する情報が記述された所定の記述データと、前記論理チャンネルのそれぞれにおいて伝送されるコンテンツに関する情報が記述されたメタデータが含まれるようにすることができる。
 前記ダウンロードスケジュール生成手段は、前記物理チャンネルに存在する複数の論理チャンネルのうち、前記登録情報に対応する前記論理チャンネルで放送される全てのコンテンツを受信して記録するためのダウンロードスケジュールを生成するようにすることができる。
 前記ダウンロードスケジュール生成手段は、前記メタデータの記述に基づいて、前記コンテンツの放送開始時刻を特定するとともに、前記論理チャンネルで伝送されるデータのうち、前記コンテンツのデータを特定するためのロケーション情報を特定して前記ダウンロードスケジュールを生成するようにすることができる。
 前記ダウンロード手段は、前記ダウンロードスケジュールに基づいて、前記コンテンツの放送開始時刻に、前記物理チャンネルに対応する周波数帯域の放送波を受信し、前記所定の記述データの記述に基づいて、前記物理チャンネルで伝送されるトランスポートパッケトのうち、前記登録情報に対応する論理チャンネルのトランスポートパケットを抽出し、前記ロケーション情報に基づいて、前記コンテンツのデータを特定することで、前記コンテンツを受信するようにすることができる。
 前記論理チャンネルのトランスポートパケットは、IPパケットを含んで構成され、前記ロケーション情報には、前記IPパケットにより伝送される前記コンテンツのデータのファイル伝送セションを特定するための情報が含まれ、前記ダウンロード手段は、前記ファイル伝送セションが特定されることにより取得される伝送制御データの記述に基づいて前記コンテンツのデータを特定するようにすることができる。
 前記ダウンロード手段は、前記伝送制御データの記述に基づいて、RSS形式またはATOM形式で記述されたアドレスファイルを特定し、前記アドレスファイルに基づいて前記コンテンツのデータを特定するようにすることができる。
 前記所定の記述データと前記メタデータの記述に基づいて、前記論理チャンネルのうち、ユーザのリクエストによらず、視聴すべきコンテンツを受信させるPush型サービスを提供する論理チャンネルを特定し、前記Push型サービスを提供する論理チャンネルの一覧をユーザに提示して、前記ユーザによる前記Push型サービスの登録を受け付け、前記登録されたPush型サービスの論理チャンネルを特定する情報を前記登録情報として記憶するようにすることができる。
 前記ダウンロードスケジュール生成手段は、前記物理チャンネルに存在する複数の論理チャンネルのうち、前記登録情報に対応する前記論理チャンネルで放送されるコンテンツであって、前記所定の記述データにより特定されるコンテンツを受信して記録するためのダウンロードスケジュールを生成するようにすることができる。
 前記ダウンロード手段は、前記受信したコンテンツを、前記記録媒体に記録されているコンテンツに上書きするか否かを判定する上書き判定手段を有するようにすることができる。
 前記ダウンロード手段により記録された前記コンテンツには、前記メタデータの記述に基づいて有効期限が設定され、前記有効期限が経過した前記コンテンツを削除するようにすることができる。
 本発明の第1の側面は、放送波として送信される信号に基づいて、再生レートと同期しない伝送レートでのコンテンツの放送に関する制御情報を受信し、前記制御情報に基づいて、予め設定された登録情報に対応する論理チャンネルで放送されるコンテンツを受信して記録するための予約情報であって、ダウンロードスケジュールを生成し、前記ダウンロードスケジュールに基づいて、前記コンテンツのそれぞれを受信して記録媒体に記録し、前記記録媒体に記録されたコンテンツを、前記再生レートで再生するステップを含むコンテンツ受信方法である。
 本発明の第1の側面は、コンピュータを、放送波として送信される信号に基づいて、再生レートと同期しない伝送レートでのコンテンツの放送に関する制御情報を受信する制御情報受信手段と、前記制御情報に基づいて、予め設定された登録情報に対応する論理チャンネルで放送されるコンテンツを受信して記録するための予約情報であって、ダウンロードスケジュールを生成するダウンロードスケジュール生成手段と、前記ダウンロードスケジュールに基づいて、前記コンテンツのそれぞれを受信して記録媒体に記録するダウンロード手段と、前記記録媒体に記録されたコンテンツを、前記再生レートで再生する再生手段とを備えるコンテンツ受信装置として機能させるプログラムである。
 本発明の第1の側面においては、放送波として送信される信号に基づいて、再生レートと同期しない伝送レートでのコンテンツの放送に関する制御情報が受信され、前記制御情報に基づいて、予め設定された登録情報に対応する論理チャンネルで放送されるコンテンツを受信して記録するための予約情報であって、ダウンロードスケジュールが生成され、前記ダウンロードスケジュールに基づいて、前記コンテンツのそれぞれを受信して記録媒体に記録され、前記記録媒体に記録されたコンテンツが、前記再生レートで再生される。
 本発明の第2の側面は、予め作成された放送スケジュールから、再生レートと同期しない伝送レートで放送されるコンテンツに関する情報を取得するコンテンツ情報取得手段と、前記コンテンツが、ユーザのリクエストによらず、視聴すべきコンテンツを受信させるPush型サービスのコンテンツであるか否かを判定する判定手段と、前記Push型サービスのコンテンツであると判定された場合、所定の論理チャンネルで放送されるコンテンツに関する情報として生成された第1の制御情報に、前記コンテンツに関する情報とともに、前記コンテンツが前記Push型サービスのコンテンツである表す情報を記述する第1の制御情報生成手段と、所定の周波数帯域の放送波の信号の伝送路としての物理チャンネルにおいて、前記論理チャンネルのそれぞれを特定するための情報が記述された第2の制御情報を生成する第2の制御情報生成手段と、前記第1の制御情報および第2の制御情報を、前記コンテンツのデータと多重化するとともに、複数の前記論理チャンネルで放送されるデータを、1つの物理チャンネルで放送されるデータとして多重化する多重化手段と、前記多重化されたデータを変調して放送波として送信する放送波送信手段とを備えるコンテンツ送信装置である。
 本発明の第2の側面は、予め作成された放送スケジュールから、再生レートと同期しない伝送レートで放送されるコンテンツに関する情報を取得し、前記コンテンツが、ユーザのリクエストによらず、視聴すべきコンテンツを受信させるPush型サービスのコンテンツであるか否かを判定し、前記Push型サービスのコンテンツであると判定された場合、所定の論理チャンネルで放送されるコンテンツに関する情報として生成された第1の制御情報に、前記コンテンツに関する情報とともに、前記コンテンツが前記Push型サービスのコンテンツである表す情報を記述し、所定の周波数帯域の放送波の信号の伝送路としての物理チャンネルにおいて、前記論理チャンネルのそれぞれを特定するための情報が記述された第2の制御情報を生成し、前記第1の制御情報および第2の制御情報を、前記コンテンツのデータと多重化するとともに、複数の前記論理チャンネルで放送されるデータを、1つの物理チャンネルで放送されるデータとして多重化し、前記多重化されたデータを変調して放送波として送信するステップを含むコンテンツ送信方法である。
 本発明の第2の側面は、コンピュータを、予め作成された放送スケジュールから、再生レートと同期しない伝送レートで放送されるコンテンツに関する情報を取得するコンテンツ情報取得手段と、前記コンテンツが、ユーザのリクエストによらず、視聴すべきコンテンツを受信させるPush型サービスのコンテンツであるか否かを判定する判定手段と、前記Push型サービスのコンテンツであると判定された場合、所定の論理チャンネルで放送されるコンテンツに関する情報として生成された第1の制御情報に、前記コンテンツに関する情報とともに、前記コンテンツが前記Push型サービスのコンテンツである表す情報を記述する第1の制御情報生成手段と、所定の周波数帯域の放送波の信号の伝送路としての物理チャンネルにおいて、前記論理チャンネルのそれぞれを特定するための情報が記述された第2の制御情報を生成する第2の制御情報生成手段と、前記第1の制御情報および第2の制御情報を、前記コンテンツのデータと多重化するとともに、複数の前記論理チャンネルで放送されるデータを、1つの物理チャンネルで放送されるデータとして多重化する多重化手段と、前記多重化されたデータを変調して放送波として送信する放送波送信手段とを備えるコンテンツ送信装置として機能させるプログラムである。
 本発明の第2の側面においては、予め作成された放送スケジュールから、再生レートと同期しない伝送レートで放送されるコンテンツに関する情報が取得され、前記コンテンツが、ユーザのリクエストによらず、視聴すべきコンテンツを受信させるPush型サービスのコンテンツであるか否かが判定され、前記Push型サービスのコンテンツであると判定された場合、所定の論理チャンネルで放送されるコンテンツに関する情報として生成された第1の制御情報に、前記コンテンツに関する情報とともに、前記コンテンツが前記Push型サービスのコンテンツである表す情報が記述され、所定の周波数帯域の放送波の信号の伝送路としての物理チャンネルにおいて、前記論理チャンネルのそれぞれを特定するための情報が記述された第2の制御情報が生成され、前記第1の制御情報および第2の制御情報を、前記コンテンツのデータと多重化するとともに、複数の前記論理チャンネルで放送されるデータが、1つの物理チャンネルで放送されるデータとして多重化され、前記多重化されたデータが変調されて放送波として送信される。
 本発明によれば、Push型NRTサービスを実現することができる。
本発明の一実施の形態に係る放送システムの構成例を示す図である。 ECGの例を示す図である。 EPGの例を示す図である。 コンテンツリストの例を示す図である。 再生されたコンテンツの画像の例を示す図である。 NRT放送、および通常放送を含む放送波の信号におけるプロトコルスタックを説明する図である。 VCTの構成例を示す図である。 NRT-ITの構成例を示す図である。 FLUTEのセッションにより伝送されるコンテンツのデータ構成を説明する図である。 Pull型NRT放送受信再生処理の例を説明するフローチャートである。 本発明におけるPush型NRT放送の例について説明する図である。 NRT放送においてコンテンツを構成するデータが受信装置41により受信される方式について説明する図である。 Push型NRT放送のコンテンツが受信装置41において蓄積される例について説明する。 VCTの別の構成例を示す図である。 NRT-ITの別の構成例を示す図である。 図15のNRT-ITのシンタックスの例を説明する図である。 図15のNRT-ITのシンタックスの例を説明する図である。 「Push型NRTメタ情報」のシンタックスの例を説明する図である。 図1の受信装置の構成例を示すブロック図である。 ディスプレイの画面に表示される画像の例を示す図である。 Push型NRT放送のサービスの登録を受け付けるGUIの例を示す図である。 コンテンツリストの別の例を示す図である。 再生されたコンテンツの画像の別の例を示す図である。 Push型NRT放送サービス登録処理の例を説明するフローチャートである。 Push型NRT放送受信再生処理の例を説明するフローチャートである。 ダウンロードスケジュール生成処理の例を説明するフローチャートである。 放送波送信処理の例を説明するフローチャートである。 RSS形式で記述されたアドレスファイルを用いてコンテンツを構成するファイルが取得される場合の例を説明する図である。 図28の例において用いられるRSS形式で記述されたアドレスファイルの例を示す図である。 VCT、NRT-ITを新たに受信装置41に受信させなくとも、新たなコンテンツを伝送して受信装置41で視聴させることができるようにする方式を説明する図である。 図30の例において用いられるRSS形式で記述されたアドレスファイルの例を示す図である。 図30の例において用いられるRSS形式で記述されたアドレスファイルの例を示す図である。 ARIBの規格に適合する方式のNRT放送を含む放送波の信号におけるプロトコルスタックを説明する図である。 グループ属性テーブルの構成例を示す図である。 プログラム属性テーブルの構成例を示す図である。 購入属性テーブルの構成例を示す図である。 ライセンス属性テーブルの構成例を示す図である。 プログラムロケーション(Program Location)テーブルの例を示す図である。 ダウンロード制御情報の構成例を示す図である。 NRT放送受信処理の例を説明する図である。 パーソナルコンピュータの構成例を示すブロック図である。
 以下、図面を参照して、本発明の実施の形態について説明する。
 図1は、本発明の一実施の形態に係る放送システムの構成例を示す図である。同図に示されるように、放送システム1は、放送局11に設置された送信装置21、およびユーザ宅12などに設置された受信装置41により構成されている。なお、実際には、複数のユーザ宅のそれぞれに受信装置が設置されている。
 例えば、1つの放送チャンネルには、放送波の中で所定の周波数帯域(例えば、6MHz)が割り当てられており、その割り当てられた周波数帯域が1つの放送チャンネルとされ、受信装置41により放送チャンネルが選択されることにより選局がなされる。また、デジタル放送においては、1つの放送チャンネルに多重化されるようにして複数の論理チャンネルを設けることも可能である。
 送信装置21は、例えば、デジタル放送波の信号を送出するものであり、通常放送の信号、およびNRT放送の信号を送出できるようになされている。ここで、通常放送は、当該放送の信号を受信した受信装置41におけるリアルタイムでの視聴を前提とした放送であり、コンテンツの放送時刻に同期してコンテンツが視聴されることを前提として放送とされる。一方、NRT放送は、リアルタイムでの視聴を前提とせず、コンテンツの放送時刻に同期してコンテンツを視聴する必要がなく、コンテンツをデータとして放送波による信号により送信するものである。
 NRT放送では、従来の放送番組のコンテンツの録画予約などとは異なり、例えば、放送波による信号の伝送帯域が大きい場合、すなわち、伝送レートが高い場合、より短時間で録画(ダウンロード)が完了するようにすることが可能である。あるいはまた、例えば、放送波による信号の伝送帯域が小さい場合、すなわち、伝送レートが低い場合、より長時間でコンテンツのダウンロードが完了することになる。これに対して、通常放送では、放送したコンテンツがリアルタイムで視聴されるので、常に、コンテンツの再生時間とほぼ同じ伝送時間でのコンテンツの伝送が行われる。
 すなわち、NRT放送では、デジタルデータとして放送されるコンテンツを、その再生レートと大きく異なる伝送レートで、送信装置21から受信装置41に送信することが可能となるのである。一方、通常放送では、デジタルデータとして放送されるコンテンツを、その再生レートと大きく異なる伝送レートで、送信装置21から受信装置41に送信することはできない。
 放送システム1において、送信装置21が送信する信号で構成されるコンテンツであって、NRT放送により放送されたコンテンツは、受信装置41により受信され、受信装置41が有する記録媒体(ストレージ)に記録されて蓄積される。そして、受信装置41のユーザが、記録媒体に記録されたコンテンツを再生することにより、NRT放送により放送されたコンテンツが視聴されるのである。
 NRT放送においては、ユーザが個々のコンテンツを選択した後、受信し蓄積する方式と、ユーザが特定のコンテンツの集合を視聴する登録を行った上で、受信装置41がこれらのコンテンツを自動的に受信し蓄積する方式の二通りの方式が考えられる。ここでは、前者の方式を、Pull型NRT放送と称することとし、後者の方式を、Push型NRT放送と称することとする。なお、Push型NRT放送は、例えば、Subscription型NRT放送と称されることもある。
 まず、Pull型NRT放送について説明する。
 NRT放送においては、PSIP(Program and System Information Protocol)データと称されるメタデータ、制御情報などを含んで構成されるデータが受信装置41により定期的に受信されるようになされている。受信装置41は、PSIPデータに含まれるメタデータ、制御情報など基づいて、NRT放送において受信可能なコンテンツのリストを生成する。このコンテンツのリストはECG(Electronic Contents Guide)と称される。なお、PSIPデータの詳細については、ATSC(Advanced Television Systems Committee)の規格に記載されている。
 図2は、画面に表示されるECGの例を示す図である。同図の例では、NRT番組リストとしてNRT放送において受信可能なコンテンツのリストが、それらのコンテンツの放送開始時刻とともに表示されている。なお、図2の例では、「XXXX」が各コンテンツのタイトルを表示するものとされ、「1/30 15:00(1月30日 15時を表す)」などの記載により当該コンテンツの放送開始時刻が表示されている。
 あるいはまた、NRT放送において受信可能なコンテンツがEPG(Electronic Program Guide)として表示されるようにしてもよい。図3は、画面に表示されるEPGの例を示す図である。同図においては、「NRT#1」というチャンネル、「NRT#2」というチャンネル、および「RT#1」というチャンネルで放送される番組のEPGが示されている。ここで、「NRT#1」というチャンネル、および「NRT#2」というチャンネルは、NRT放送のチャンネルとされ、「RT#1」というチャンネルは、通常放送のチャンネルとされる。
 図3に表示される矩形の枠のそれぞれが、各番組(またはコンテンツ)の放送時間帯を表すものとされる。このEPGにより、通常放送のチャンネル「RT#1」では、矩形の枠で表示される時間帯において、当該番組(またはコンテンツ)が視聴可能であることが表されている。これに対して、NRT放送のチャンネル「NRT#1」または「NRT#2」では、矩形の枠で表示される時間帯において、当該番組(またはコンテンツ)がダウンロード可能であることが表されている。
 受信装置41のユーザは、図2のECG、または図3のEPGをディスプレイの画面などに表示させ、例えば、GUIを操作して所望のNRT放送のコンテンツを選択する。受信装置41は、選択されたコンテンツの放送開始時刻に、当該コンテンツのダウンロードを実行する。ただし、NRTでは、受信装置41が放送波の信号を受信して、その信号に対応するデータを記録媒体に記録することにより、ダウンロードの処理が実行されることになる。
 そして、受信装置41によりダウンロードされたコンテンツの一覧が、例えば、図4に示されるコンテンツリストとして画面に表示される。図4は、画面に表示されるコンテンツリストの例を示す図である。なお、図4の例では、「XXXX」が各コンテンツのタイトルを表示するものとされる。
 受信装置41のユーザは、図4のコンテンツリストをディスプレイの画面などに表示させ、例えば、GUIを操作して視聴したいコンテンツを選択する。これにより、選択されたコンテンツが再生され、図5に示されるように、コンテンツの画像がディスプレイの画面に表示されるのである。この例では、ゴルフのプレーをする人の画像がコンテンツの画像として表示されている。
 このようにして、NRT放送のコンテンツが受信されて視聴されるのである。
 図6は、NRT放送、および通常放送を含む放送波の信号におけるプロトコルスタックを説明する図である。
 図6に示されるように、最も下位の階層は、「Physical Layer(物理層)」とされ、当該チャンネルのために割り当てられた放送波の周波数帯域がこれに対応する。「Physical Layer」に隣接する上位の階層は、「TS(トランスポートストリーム)」とされている。「TS」においては、上位の階層のパケットが、トランスポートパケットと呼ばれる固定長のパケットに分割されて伝送され、このトランスポートパケットの連続が、トランスポートストリームとなる。
 つまり、1つの放送チャンネルに対応する周波数帯域において伝送される信号は、全てその放送チャンネルに対応するヘッダ情報などを有するトランスポートパケットにより伝送されるのである。
 トランスポートストリームに隣接する上位の階層は、「Section」または「PES(Packetized Elementary Stream)」とされている。例えば、通常放送のコンテンツのように、リアルタイムで再生されるデータは、「PES」のパケットとして伝送されることになる。また、ファイル転送のデータ、制御情報のデータなどは、「Section」のパケットとして伝送されることになる。
 図6に示されるように、「PES」のパケットの種類に対応して、「Caption Coding」、「Audio Coding」、および「Video Coding」が「PES」の上位階層として規定されている。「Caption Coding」は、画像の字幕に関するデータが格納されるパケットであり、「Audio Coding」は、音声データが格納されるパケットであり、「Video Coding」は、画像データが格納されるパケットとされる。
 図6においては、「Section」に隣接する上位階層として、「PSIP」および「PSI(Program Specific Information)」が表示されている。「PSIP」は、後述するVCT、NRT-ITなどを有する階層とされる。「PSI(Program Specific Information)」は、PAT(Program Association Table)、PMT(Program Map Table)などを有する階層とされる。
 また、図6においては、「Section」に隣接する上位階層として、「DSM-CC(Digital Storage Media Command and Control)」が表示されている。「DSM-CC」は、放送ストリームのMPEG2-TS上でIPパケットを伝送するためのアダプテーションレイヤーとして用いられる。なお、「DSM-CC」は、ISO規格として規定されている。
 「DSM-CC」に隣接する上位階層として、「Interactive Data Coding」が表示されている。「Interactive Data Coding」、「Caption Coding」、「Audio Coding」、および「Video Coding」に格納されるデータにより、ストリーミング放送が実現される。すなわち、これらのデータを受信することで、通常放送の番組を受信して再生することができる。
 また、「DSM-CC」に隣接する上位階層として、「IP」が表示されている。ここで表示されている「IP」は、TCI/IPのプロトコルスタックにおけるIPと同じものであり、IPアドレスによりIPパケットが特定される。図6に示されるように、NRT放送は、IPパケットを用いて構成されるようになされている。勿論、NRT放送は、通信ではなく、放送として提供されるものであるから、本来、通信プロトコルであるTCI/IPのプロトコルスタックを用いる必要はないが、コンテンツのダウンロードを行うにあたり、形式的にIPパケットが用いられている。
 「IP」隣接する上位階層は、「UDP」とされ、その上位階層として「FLUTE/ALC(Asynchronous Layered Coding Protocol)/LCT(Layered Coding Transport (Building Block))」が表示されている。すなわち、NRT放送においては、TCP/IP通信におけるUDPのポートが指定されたパケットが送信され、例えば、FLUTE(File Delivery over Unidirectional Transport)によるセッションが確立されるようになされている。そして、FLUTEのセッションにより、コンテンツを構成するデータが特定されるのである。FLUTEは、片方向の伝送路(例えば,下り方向のみの伝送路)を用いてデータ配信を行うことが可能な通信プロトコルであり、任意ファイルの送信が可能とされている。
 なお、FLUTEの詳細は、RFC3926として規定されている。
 このように、NRT放送においては、「TS」のトランスポートパケットの伝送レート(例えば、20Mbps)に対応する伝送帯域を有する1つの物理チャンネルを、複数の論理チャンネルに多重化することが可能である。つまり、例えば、6MHzの周波数帯域が割り当てられた1つの放送チャンネルの放送波の信号の伝送路を物理チャンネルとした場合、その物理チャンネルを複数の伝送路に分割することにより複数の論理チャンネルを設けることができるのである。
 このような論理チャンネルのそれぞれに関する情報は、物理チャンネル毎に生成される論理チャンネルに関する制御情報であるVCTに記述されている。VCTの詳細は図7を参照して後述するが、VCTに基づいて、論理チャンネル毎の「Program_number」が特定され、「Program_number」に基づいて、「PSI」が特定される。そして、「PSI」の「PAT」と「PMT」に基づいて、「TS」のトランスポートパケットに付与された所定の識別子が特定される。このように特定された識別子が付与されたトランスポートパケットを抽出することで、1つの論理チャンネルのデータを特定することができる。このように、1つのトランスポートストリームを複数の論理チャンネルのパケットとして識別することができるので、1つの物理チャンネルを、複数の論理チャンネルに多重化することができるのである。
 このように多重化された論理チャンネルのそれぞれをバーチャルチャンネル(Virtual Channel)と称する。NRT放送においては、さらに、1つの論理チャンネルを、複数のFLUTEのセッションにより多重化することが可能となる。
 通常放送においては、1つの物理チャンネル(例えば、1つの放送チャンネル)が1つの論理チャンネルに対応するようになされており、NRT放送のように複数のチャンネルに多重化されない。従って、NRT放送においては、通常放送の場合と異なり、1つの放送チャンネルで複数のコンテンツを同時に放送(送信)することも可能となる。
 次に、上述したPSIPデータに含まれるVCT(Virtual Channel Table)、およびNRT-IT(NRT Information Table)について説明する。
 VCTは、受信装置41において、バーチャルチャンネル(論理チャンネル)のそれぞれを識別可能とするための記述子により構成されるテーブルである。図7は、VCTの例を示す図である。
 同図の例において、VCTの記述領域71には、「TS_id」、「チャンネル数」、および、チャンネル単位の記述領域72-1、チャンネル単位の記述領域72-2、・・・が記述されている。「TS_id」は、トランスポートストリームを識別するIDとされ、実際には、所定の文字や数値などが記述される。これにより、どの物理チャンネル(放送チャネル)のVCTであるかを識別することが可能となる。「チャンネル数」は、「TS_id」により特定される物理チャンネルに含まれる論理チャンネルの数を表す数値などとして記述される。
 チャンネル単位の記述領域72-1、チャンネル単位の記述領域72-2、・・・には、それぞれ1つの論理チャンネルに関する情報が記述される。この記述領域は、上述した「チャンネル数」に記述された数値の分だけ設けられることになる。例えば、当該物理チャンネルに含まれる論理チャンネルの数が3である場合、「チャンネル数」には数値「3」が記述される。そして、チャンネル単位の記述領域72-1、チャンネル単位の記述領域72-2、およびチャンネル単位の記述領域72-3が記述されることになる。
 チャンネル単位の記述領域72-1には、「チャンネル名」、「チャンネル番号」、「サービスタイプ」、「Program_number」、「Source_id」、・・・が記述されている。「チャンネル名」、および「チャンネル番号」は、それぞれそれらを表す所定の文字および数値が記述される。例えば、チャンネル単位の記述領域72-1の「チャンネル名」は、「○○局NRT第1チャンネル」などと記述され、チャンネル番号は、「5-1」などと記述される。また、チャンネル単位の記述領域72-1の「チャンネル名」は、「○○局NRT第2チャンネル」などと記述され、チャンネル番号は、「5-2」などと記述される。
 「サービスタイプ」は、当該論理チャンネルが通常放送に対応する論理チャンネルであるかNRT放送に対応する論理チャンネルであるかを識別する情報が記述される。例えば、チャンネル単位の記述領域72-1に対応する論理チャンネルが、NRT放送の論理チャンネルである場合、「サービスタイプ」は、「NRT」と記述される。
 「Program_number」は、当該論理チャンネルのデータを特定するために必要となるPSI(Program Specific Information)を特定するために用いられるものである。
 「Source_id」は、当該論理チャンネルを識別するIDとされ、実際には、所定の文字や数値などが記述される。すなわち、チャンネル単位の記述領域72-1は、この「Source_id」により特定される1つの論理チャンネルに関する情報が記述される領域なのである。
 同様に、チャンネル単位の記述領域72-2、・・・にも、それぞれ「Source_id」により特定される1つの論理チャンネルに関する情報が記述される。
 VCTは、このように構成されている。
 上述したように、NRT放送においては、複数の論理チャンネルのそれぞれにおいて、別々のコンテンツを放送することが可能である。論理チャンネルのそれぞれにおいて伝送されるコンテンツに関する情報は、論理チャンネル毎に生成される制御情報であるNRT-ITに記述されている。
 NRT-ITは、受信装置41において、各論理チャンネルにおいて放送されるNRT放送のコンテンツのそれぞれを識別可能とするための記述子により構成されるテーブルである。図8は、NRT-ITの例を示す図である。
 同図の例において、NRT-ITの記述領域91には、「Source_id」、「コンテンツ数」、および、コンテンツ単位の記述領域92-1、コンテンツ単位の記述領域92-2、・・・が記述されている。「Source_id」は、図7を参照して上述したものと同様であり、論理チャンネルを識別するIDとされ、実際には、所定の文字や数値などが記述される。これにより、図7のチャンネル単位の記述領域72-1、チャンネル単位の記述領域72-2、・・・のそれぞれに記述された論理チャンネルのいずれかと、当該NRT-ITを対応付けることが可能となる。「コンテンツ数」は、「Source_id」により特定される論理チャンネルにおいて、所定の単位時間に放送されるコンテンツ数を表す数値などとして記述される。
 コンテンツ単位の記述領域92-1、コンテンツ単位の記述領域92-2、・・・には、それぞれ1つのコンテンツに関する情報が記述される。この記述領域は、上述した「コンテンツ数」に記述された数値の分だけ設けられることになる。例えば、当該論理チャンネルにおいて単位時間に放送されるコンテンツの数が5である場合、「コンテンツ数」には数値「5」が記述される。そして、コンテンツ単位の記述領域92-1、コンテンツ単位の記述領域92-2、・・・およびチャンネル単位の記述領域92-5が記述されることになる。
 コンテンツ単位の記述領域92-1には、「content_item_id」、「配信スケジュール」、「コンテンツ有効期限」、「コンテンツ名」、「コンテンツ伝送ロケーション情報」、・・・が記述されている。「content_item_id」は、当該コンテンツを識別するIDとされ、実際には、所定の文字や数値などが記述される。すなわち、コンテンツ単位の記述領域92-1は、この「content_item_id」により特定される1つのコンテンツに関する情報が記述される領域なのである。
 「配信スケジュール」は、当該コンテンツの放送開始時刻および放送終了時刻を表す情報が記述される。なお、当該コンテンツは、NRT放送のコンテンツなので、放送開始時刻および放送終了時刻により、コンテンツを視聴できる時間が表されるものではなく、コンテンツのダウンロードを開始すべき時刻およびコンテンツのダウンロードが終了する時刻が表される。
 「コンテンツ有効期限」は、当該コンテンツの有効期限となる時刻を特定する情報が記述される。有効期限を経過したコンテンツは、受信装置41の記録媒体から削除されるなどして、再生できなくなるようになされている。
 「コンテンツ名」は、当該コンテンツのタイトルなどの文字が記述される。
 「コンテンツ伝送ロケーション情報」は、図6を参照して上述した、IPアドレス、UDPのポート番号、およびFLUTEのセッションを特定するための識別子「TSI(Transport Session Identifier)」が記述される。この「コンテンツ伝送ロケーション情報」が特定されることで、「Source_id」により特定される論理チャンネルにおいて伝送されるデータのうち、「content_item_id」により特定される1つのコンテンツのデータを識別することが可能となるのである。
 同様に、コンテンツ単位の記述領域92-2、・・・にも、それぞれ「content_item_id」により特定される1つのコンテンツに関する情報が記述される。
 NRT-ITは、このように構成されている。
 このように、VCTを取得することにより、放送チャンネル内の論理チャンネルのそれぞれに関する情報を取得することが可能となり、NRT-ITを取得することにより、各論理チャンネルで放送されるコンテンツに関する情報を取得することが可能となる。
 図9は、FLUTEのセッションにより伝送されるコンテンツのデータ構成を説明する図である。FLUTEのセッションにより取得されたデータは、同図の下側に示されるようなFLUTEセッションストリームを構成する。FLUTEセッションストリームは、実際には、所定のサイズに分割された複数のファイルにより構成されており、この複数のファイルのそれぞれには、「TOI(Transport Object Identifier)」と称される識別子が付されている。このTOIにより、複数のファイルのそれぞれの伝送順序を特定することができるようになされている。この例では、「TOI」が0のファイルは、「FDT」とされ、「TOI」が1のファイルは、「FILE#1」とされ、「TOI」が2のファイルは、「FILE#2」とされ、・・・とされている。
 FLUTEセッションストリームを構成する複数のファイルのうち、「TOI」が0であるファイルは、FDT(File Delivery Table)とされる。FDTは、FLUTEセッションストリームを構成する他のファイルのそれぞれに関する情報が記述されたテーブルとされる。図9の例では、FDTの記述領域111に、FLUTEセッション内のファイル単位の情報の記述領域112-1、FLUTEセッション内のファイル単位の情報の記述領域112-2、・・・が記述されている。
 FLUTEセッション内のファイル単位の情報の記述領域112-1には、「TOI」、「content_type」、「ファイル名」、・・・が記述されている。「TOI」は、FLUTEセッション内のファイルを識別するための情報とされ、実際には、所定の数値が記述される。すなわち、FLUTEセッション内のファイル単位の情報の記述領域112-1は、この「TOI」により特定される1つのファイルに関する情報が記述される領域なのである。
 「content_type」は、「TOI」により特定されるファイルのファイル形式(データの種類)を特定する情報が記述される。「content_type」は、例えば、当該ファイルが画像データのファイルである場合、「ビデオ」などとされ、当該ファイルが音声データのファイルである場合、「オーディオ」などとされる。
 「ファイル名」は、当該ファイルの名称が記述される。「ファイル名」は、URLとして記述されるようにしてもよい。
 同様に、FLUTEセッション内のファイル単位の情報の記述領域112-2、・・・にも、それぞれ「TOI」により特定される1つのファイルに関する情報が記述される。
 所定のFLUTEのセッションにより伝送されるコンテンツのデータは、このように構成されている。
 次に、図10のフローチャートを参照して、受信装置41によるPull型NRT放送受信再生処理について説明する。
 ステップS11において、受信装置41は、NRT放送に関するメタデータ、制御情報などを受信する。
 このとき、例えば、PSIPデータが受信される。なお、上述したように、PSIPデータは、VCT、NRT-ITなどを含んで構成されるデータとされ、受信装置41により定期的に受信されるようになされている。また、図7と図8を参照して説明したように、VCTを取得することにより、放送チャンネル内の論理チャンネルのそれぞれに関する情報を取得することが可能となる。さらに、NRT-ITを取得することにより、各論理チャンネルで放送されるコンテンツに関する情報を取得することが可能となる。
 ステップS12において、受信装置41は、PSIPデータに含まれるVCT、およびNRT-ITに基づいて、NRT放送において受信可能なコンテンツのリストを生成する。
 ステップS13において、受信装置41は、ステップS12で生成したリストに対応するECGをディスプレイに表示させる。このとき、例えば、図2に示されるようなECGの画像が表示される。あるいはまた、ステップS13において、図3に示されるようなEPGが表示されるようにしてもよい。
 ステップS14において、受信装置41は、ステップS13で表示したECGに基づく、ユーザによるコンテンツの選択を受け付ける。このとき、例えば、ユーザが視聴したいと考えるNRT放送のコンテンツが選択される。
 ステップS15において、受信装置41は、ステップS14の処理で選択が受け付けられたコンテンツの放送開始時刻になったか否かを判定し、放送開始時刻になったと判定されるまで待機する。ステップS15において、放送時刻になったと判定された場合、処理は、ステップS16に進む。
 ステップS16において、受信装置41は、コンテンツをダウンロードする。
 このとき、受信装置41の選局が、ステップS14で選択が受け付けられたコンテンツの放送チャンネルに設定される。そして、受信装置41は、ステップS11で受信したVCTに基づいて、当該コンテンツが放送される論理チャネルで伝送されるデータを特定する。さらに、受信装置41は、ステップS11で受信したNRT-ITに基づいて、当該コンテンツが伝送されるFLUTEのセッションを特定し、そのFLUTEセッションストリームを構成するファイルのそれぞれを取得する。放送終了時刻になると、受信装置41において、FLUTEセッションストリームを構成する全てファイルの取得が完了し、これにより、コンテンツのダウンロードが完了する。
 受信装置41は、ダウンロードが完了すると、上述のように取得したファイルにより構成されるデータを1つのコンテンツとして、記録媒体に記録する。このとき、ステップS11で受信した情報に含まれる、当該コンテンツのメタデータも、当該コンテンツに対応付けられて記録される。なお、メタデータは、例えば、NRT-ITに記述された「コンテンツ名」、「配信スケジュール」、「コンテンツ有効期限」などから構成される。
 ここでは、1つのコンテンツがダウンロードされる場合の例について述べたが、例えば、ステップS14において、複数のコンテンツが選択された場合、ステップS15、ステップS16では、それら複数のコンテンツがダウンロードされる。
 ステップS17において、受信装置41は、ステップS16の処理でダウンロードされたコンテンツのリストを表示する。このとき、例えば、図4に示されるような画像が生成されてディスプレイに表示される。
 ステップS18において、受信装置41は、ステップS17の処理で表示したコンテンツのリストに基づく、ユーザによるコンテンツの選択を受け付ける。このとき、例えば、既に受信装置41の記録媒体に記録されているNRT放送のコンテンツのうち、ユーザが視聴したいと考えるコンテンツが選択される。
 ステップS19において、受信装置41は、ステップS18の処理で選択が受け付けられたコンテンツを再生する。これにより、例えば、図5に示されるように、コンテンツの画像がディスプレイに表示されるのである。
 このようにして、受信装置41によるPull型NRT放送受信再生処理が実行される。
 ここまで、Pull型NRT放送について説明したが、上述したようなPull型NRT放送を実現するための技術は、その多くが、例えば、ATSC(Advanced Television Systems Committee)の規格として既に検討されている。このように、Pull型NRT放送については、例えば、放送局や受信装置のメーカなどの間で、どのようにして実現するか具体的な想定がなされている。しかし、Push型NRT放送に関しては、まだ具体的な実現方式が想定されていない。
 そこで本発明では、Push型NRT放送を具体的に実現できるようにする。上述したように、Push型NRT放送では、視聴者が特定のコンテンツの集合を視聴する登録を行った上で、受信装置41がこれらのコンテンツを自動的に受信し蓄積する。具体的なPush型NRT放送として、次のようなものを想定する。
 例えば、天気予報のPush型NRT放送を考える。この場合、ユーザが予め「天気予報」というPush型NRT放送のサービスに登録する。そうすると、受信装置41は、所定の放送チャンネルで放送される天気予報番組のコンテンツを自動的に受信して蓄積する。ここで、天気予報番組は、例えば、5分間の番組であって、1日2回最新の気象情報に基づく予報を伝えるものであるとし、例えば、受信装置41に蓄積されたコンテンツは、逐次最新のものに更新される。
 従って、ユーザは、いつでも、最新の気象情報に基づく天気予報を視聴することが可能となる。
 また、例えば、ニュースクリップのPush型NRT放送を考える。この場合、ユーザが予め「ニュースクリップ」というPush型NRT放送のサービスに登録する。そうすると、受信装置41は、所定の放送チャンネルで放送されるニュース番組のコンテンツを自動的に受信して蓄積する。
 ここで、ニュース番組は、例えば、15分間の番組であって、最新の政治経済情報に関するニュースを伝えるものであるとし、例えば、受信装置41に蓄積されたコンテンツは、逐次最新のものに更新される。あるいはまた、所定の時間だけコンテンツが蓄積されて消去されるようにしてもよい。また、例えば、「ニュースクリップ」のサービスの提供を受ける場合に必要となる受信装置41のストレージサイズ(記憶容量)を指定して、そのストレージサイズを超える分については、コンテンツが上書きされて更新されるようにしてもよい。
 このようなサービスの提供を受けることにより、ユーザは、いつでも、最新の政治経済情報に関するニュースを視聴することが可能となる。
 Push型NRT放送では、上述したようなPush型NRT放送のサービスが、例えば、各放送局などにより提供されるものとする。このようなサービスは、無料であっても有料であってもよい。そして、受信装置41のユーザは、所望のサービスを選択して受信装置41に登録する。
 本発明では、Push型NRT放送の個々のサービスに対応する論理チャンネルを設けることにする。すなわち、Push型NRT放送のサービスが3つ存在する場合、3つの論理チャンネルが存在することになる。
 図11を参照して、本発明におけるPush型NRT放送の例について説明する。図11は、「Ch.4」、「Ch.5」、「Ch.6」の3つの放送チャンネルにおいて、通常放送、およびNRT放送が行なわれる場合の例を表している。「Ch.4」は、通常放送の放送チャンネルとされ、「Ch.5」、および「Ch.6」は、NRTの放送チャンネルとされる。なお、同図においては、図中水平方向が放送波の周波数を表しており、図中垂直方向が時間を表している。
 また、各チャンネルにおいて放送されるコンテンツの種別などの内容が図中のハッチングなどにより表されている。この例では、通常放送のコンテンツ、Pull型NRT放送のコンテンツ、Push型NRT放送のコンテンツ、および放送休止期間が図中のハッチングなどにより表されている。
 図11の例では、「Ch.5」が3つの論理チャンネルに多重化されている。この例では、放送チャンネル「Ch.5」が論理チャンネル「VC5-1」、論理チャンネル「VC5-2」、および論理チャンネル「VC5-3」に多重化されている。なお、図中において、論理チャンネル「VC5-1」乃至論理チャンネル「VC5-3」のそれぞれの中に表示された矩形の枠のそれぞれが各コンテンツの放送時間帯を表している。
 論理チャンネル「VC5-1」は、1つのPush型NRT放送のサービスに割り当てられた論理チャンネルである。論理チャンネル「VC5-2」は、Pull型NRT放送に割り当てられた論理チャンネルである。論理チャンネル「VC5-3」は、別の1つのPush型NRT放送のサービスに割り当てられた論理チャンネルである。また、この例においては、論理チャンネル「VC5-3」では、チャンネル休止となる時間帯が含まれている。
 論理チャンネル「VC5-2」には、3つのFLUTEセッションが設けられている。すなわち、論理チャンネル「VC5-2」において放送されるPull型NRT放送では、同時に3つのコンテンツを放送することが可能である。
 また、図11の例では、「Ch.6」が2つの論理チャンネルに多重化されている。この例では、放送チャンネル「Ch.6」が論理チャンネル「VC6-1」、および論理チャンネル「VC6-2」に多重化されている。なお、図中において、論理チャンネル「VC6-1」および論理チャンネル「VC6-2」のそれぞれの中に表示された矩形の枠のそれぞれが各コンテンツの放送時間帯を表している。
 論理チャンネル「VC6-1」は、1つのPush型NRT放送のサービスに割り当てられた論理チャンネルである。論理チャンネル「VC6-2」は、Pull型NRT放送のサービスに割り当てられた論理チャンネルである。
 論理チャンネル「VC6-1」には、2つのFLUTEセッションが設けられている。すなわち、論理チャンネル「VC6-1」において提供されるPush型NRT放送のサービスでは、同時に2つのコンテンツが放送される。
 いまの場合、放送チャンネル「Ch.5」において定期的に送信されるPSIPデータには、「Ch.5」の物理チャンネルのトランスポートストリームを識別する「TS_id」が記述されたVCTが1つ含まれる。また、そのPSIPデータには、論理チャンネル「VC5-1」、論理チャンネル「VC5-2」、および論理チャンネル「VC5-3」を識別する「Source_id」がそれぞれ記述された3つのNRT-ITも含まれることになる。
 同様に、放送チャンネル「Ch.6」において定期的に送信されるPSIPデータには、「Ch.6」の物理チャンネルのトランスポートストリームを識別する「TS_id」が記述されたVCTが1つ含まれる。また、そのPSIPデータには、論理チャンネル「VC6-1」、および論理チャンネル「VC6-2」を識別する「Source_id」がそれぞれ記述された2つのNRT-ITも含まれることになる。
 例えば、論理チャンネル「VC5-1」は、○○放送局の「ニュースクリップ」に割り当てられ、論理チャンネル「VC5-3」は、○○放送局の「天気予報」に割り当てられる。論理チャンネル「VC6-1」は、××放送局の「ニュースクリップ」に割り当てられる。
 また、図11の例では、「Ch.4」は、複数の論理チャンネルに分割されていない。通常放送の論理チャンネル「VC4-1」は、実質的に物理チャンネルと同じである。
 上述したように、受信装置41は、PSIPデータを定期的に受信するので、VCTに基づいて、各論理チャンネルで伝送されるデータを識別することができる。従って、例えば、○○放送局の「天気予報」のサービスが登録された受信装置41は、論理チャンネル「VC5-3」において伝送されるコンテンツの全てを自動的にダウンロードする。
 一方、通常放送として伝送されるコンテンツ(番組)を受信する場合、VCTとEIT(Event Information Table)に基づいてコンテンツが特定される。
 このように、本発明によれば、Push型NRT放送およびPull型NRT放送、並びに通常放送でコンテンツを放送することが可能となる。
 Push型NRT放送は、ユーザにより選択された個々のコンテンツを提供するものではなく、一方的にコンテンツをユーザに提供するものなので、Pull型NRT放送、通常放送と同じ放送システムで実現することは難しかった。本発明では、Push型NRT放送のサービスが登録された受信装置41が、そのサービスに対応する論理チャンネルにおいて伝送されるコンテンツの全てを自動的にダウンロードするようにした。このようにすることで、Pull型NRT放送、通常放送と同じ放送システムでPush型NRT放送を実現することが可能となる。
 図12は、NRT放送においてコンテンツを構成するデータが受信装置41により受信される方式について説明する図である。同図においては、1つの放送チャンネルに対応するトランスポートストリーム(TS)の伝送帯域が円筒201で示されている。なお、図中垂直方向が時間を表すものとする。
 また、図12において、円筒201のトランスポートストリームに多重化された論理チャンネル(バーチャルチャンネル:VC)が円筒202で示されている。なお、この例では、トランスポートストリームにおいて多重化されている論理チャンネル(バーチャルチャンネル:VC)が1つであるが、実際には、複数の論理チャンネルが多重化されるようにすることができる。
 さらに、図12において、円筒202に対応する論理チャンネル内に存在するFLUTEセッションが、円筒203-1および円筒203-2によって示されている。すなわち、円筒202に対応する論理チャンネル内には、2つのFLUTEセッションが存在する。受信装置41が受信して蓄積(記録)すべきコンテンツを構成するデータは、円筒203-1および円筒203-2のFLUTEセッションのファイルとして伝送されるのである。
 いま、受信装置41は、NRT放送のコンテンツであって、円筒201に対応するトランスポートストリームの放送チャンネルの、円筒202に対応する論理チャンネルで放送されるコンテンツA乃至コンテンツCを受信するように設定されているものとする。
 上述したように、受信装置41は、定期的にPSIPデータを受信するので、定期的にVCT、およびNRT-ITを取得することができる。最初にVCT210、NRT-IT211、およびNRT-IT212が受信されたものとする。受信装置41は、VCT210の記述を参照することで、受信して蓄積すべきコンテンツA、コンテンツBが伝送される論理チャンネルを識別する「source_id」を特定することができる。そして、受信装置41は、その「source_id」に基づいて、当該論理チャンネルに関するNRT-IT211を特定することができる。
 なお、NRT-IT212は、同図においては図示されていない、別の論理チャンネルに対応するNRT-ITである。
 さらに、受信装置41は、そのNRT-IT211の記述の中で、受信して蓄積すべきコンテンツに関する情報が記述されたコンテンツ単位の記述領域を特定する。なお、図12の例において、最初に受信したNRT-IT211には、円筒203-1で示されるFLUTEセッションの中の矢印205で示される時間帯に放送されるコンテンツに関する情報が記述されているものとする。また、最初に受信したNRT-IT211には、円筒203-2で示されるFLUTEセッションの中の矢印206で示される時間帯のコンテンツに関する情報も記述されているものとする。
 いまの場合、コンテンツA、コンテンツBの「content_item_id」に基づいて、それらのコンテンツに関する情報が記述されたコンテンツ単位の記述領域が特定される。そして、受信装置41は、その特定されたコンテンツ単位の記述領域を参照して「コンテンツ伝送ロケーション情報」に含まれる、IPアドレス、UDPのポート番号、およびFLUTEのセッションを特定するための識別子「TSI」を特定する。
 そして、受信装置41は、円筒203-1で示されるFLUTEセッションのファイルを特定し、FDTを抽出する。そして、受信装置41は、FDTに基づいて、コンテンツAを構成するデータのファイルのそれぞれを取得することで、コンテンツAを受信して蓄積するのである。
 また同様に、受信装置41は、円筒203-2で示されるFLUTEセッションのファイルを特定し、FDTを抽出する。そして、受信装置41は、FDTに基づいて、コンテンツBを構成するデータのファイルのそれぞれを取得することで、コンテンツBを受信して蓄積するのである。
 受信装置41は、定期的にPSIPデータを受信するので、VCT、およびNRT-ITが更新される。いまの場合、VCT220とNRT-IT221およびNRT-IT222が新たに受信されて更新されたものとする。更新されたNRT-IT221には、円筒203-1で示されるFLUTEセッションの中の矢印207で示される時間帯に放送されるコンテンツに関する情報が記述されているものとする。
 受信装置41は、上述した場合と同様に、VCT220の記述を参照することで、受信して蓄積すべきコンテンツCが伝送される論理チャンネルを識別する「source_id」を特定することができる。そして、受信装置41は、その「source_id」に基づいて、当該論理チャンネルに関するNRT-IT221を特定することができる。
 なお、NRT-IT222は、同図においては図示されていない、別の論理チャンネルに対応するNRT-ITである。
 いまの場合、コンテンツCの「content_item_id」に基づいて、それらのコンテンツに関する情報が記述されたコンテンツ単位の記述領域が特定される。そして、受信装置41は、その特定されたコンテンツ単位の記述領域を参照して「コンテンツ伝送ロケーション情報」に含まれる、IPアドレス、UDPのポート番号、およびFLUTEのセッションを特定するための識別子「TSI」を特定する。
 そして、受信装置41は、円筒203-1で示されるFLUTEセッションのファイルを特定し、FDTを抽出する。そして、受信装置41は、FDTに基づいて、コンテンツCを構成するデータのファイルのそれぞれを取得することで、コンテンツCを受信して蓄積するのである。
 次に、図13を参照して、Push型NRT放送のコンテンツが受信装置41において蓄積される例について説明する。同図においては、図12の場合と同様に、円筒により、トランスポートストリーム(TS)、論理チャンネル(バーチャルチャンネル:VC)、およびFLUTEセッションが示されている。なお、同図においては、図中水平方向が時間を表すものとする。
 上述したように、受信装置41において、所定のPush型NRT放送のサービスが登録された場合、当該サービスに割り当てられた論理チャンネルで伝送される全てのコンテンツが受信装置41により自動的に受信されて蓄積される。
 図13の例では、1つのFLUTEセッションで伝送されるコンテンツである「content1」と、別のFLUTEセッションで伝送されるコンテンツである「content2」乃至「content4」が受信されて蓄積されることになる。「content1」は、バージョンが付されたコンテンツであり、常に最新のコンテンツが上書きされるようになされている。「content2」乃至「content4」は、例えば、「有効期限」として指定された時刻が経過するまで蓄積され、「有効期限」として指定された時刻が経過すると、削除されるようになされている。
 図13の例では、最初にコンテンツ「content1」の第1バージョンが受信されて蓄積されることになる。なお、図中において、コンテンツ「content1」の第1バージョンは、「content1(v1)」のように表記されている。「content1」は、同一のバージョンが2回繰り返して放送されるようになされている。いま、受信装置41は、第1回目の放送を受信して蓄積したものとする。この場合、受信装置41は、第2回目の放送を受信、蓄積しないようになされている。
 その後、コンテンツ「content1」の第2バージョンが放送されると、受信装置41は、そのコンテンツを受信して蓄積する。すなわち、既に蓄積(記録)されている「content1(v1)」が、「content1(v2)」によって上書きされるのである。ここでも、受信装置41は、やはり第1回目の放送を受信して蓄積したものとし、第2回目の放送を受信、蓄積しないようになされている。
 また、受信装置41は、「content1(v1)」の受信中に、「content2」の受信を開始し、「content2」の受信が完了すると「content2」を蓄積する。「content2」は、同じものが2回繰り返して放送されるようになされている。いま、受信装置41は、第1回目の放送を受信して蓄積したものとする。この場合、受信装置41は、第2回目の放送を受信、蓄積しないようになされている。
 同様に、受信装置41は、「content3」を受信して蓄積する。その後、さらに、受信装置41は、「content4」も受信して蓄積することになる。
 上述したように、「content2」と「content3」は、「有効期限」として指定された時刻が経過するまで蓄積され、「有効期限」として指定された時刻が経過すると、削除されるようになされている。図13において、「有効期限」として指定された時刻は、「expire」と記載されている。
 なお、コンテンツの削除は、「有効期限」として指定された時刻になされるようにしてもよいし、例えば、予め設定された所定の時間間隔で、「有効期限」を経過したコンテンツがまとめて削除されるようにしてもよい。さらに、例えば、蓄積済のコンテンツの一覧の表示が指令されたとき、「有効期限」を経過したコンテンツがまとめて削除されるようにしてもよい。
 このように、Push型NRT放送のコンテンツは、バージョンに対応して逐次更新されていくようにすることも可能であるし、Pull型NRT放送の場合と同様に、有効期限を経過するまで蓄積されるようにすることも可能である。
 上述したように、本発明では、Push型NRT放送の1つのサービスを1つの論理チャンネルに割り当てる。そして、本発明では、Push型NRT放送を実現するために必要な情報を、論理チャンネル単位の情報が格納可能となる放送信号の位置に配置する。具体的には、図7を参照して説明したVCTのチャンネル単位の記述領域72-1、72-2、・・・に、Push型NRT放送を実現するために必要な情報の記述が追加されるようにする。あるいはまた、図8を参照して説明したNRT-ITの記述領域91に、Push型NRT放送を実現するために必要な情報の記述が追加されるようにする。
 VCTのチャンネル単位の記述領域にPush型NRT放送を実現するために必要な情報の記述が追加されるようにする場合、VCTは図14のように構成される。図14は、本発明において用いられるVCTの例を示す図である。
 同図の例において、VCTの記述領域271には、「TS_id」、「チャンネル数」、および、チャンネル単位の記述領域272-1、チャンネル単位の記述領域272-2、・・・が記述されている。
 「TS_id」は、トランスポートストリームを識別するIDとされ、実際には、所定の文字や数値などが記述される。これにより、どの物理チャンネル(放送チャネル)のVCTであるかを識別することが可能となる。「チャンネル数」は、「TS_id」により特定される物理チャンネルに含まれる論理チャンネルの数を表す数値などとして記述される。
 チャンネル単位の記述領域272-1、チャンネル単位の記述領域272-2、・・・には、それぞれ1つの論理チャンネルに関する情報が記述される。この記述領域は、上述した「チャンネル数」に記述された数値の分だけ設けられることになる。例えば、当該物理チャンネルに含まれる論理チャンネルの数が3である場合、「チャンネル数」には数値「3」が記述される。そして、チャンネル単位の記述領域272-1、チャンネル単位の記述領域272-2、およびチャンネル単位の記述領域272-3が記述されることになる。
 チャンネル単位の記述領域272-1には、「チャンネル名」、「チャンネル番号」、「サービスタイプ」、「Program_number」、「Source_id」、「Push型NRTメタ情報」・・・が記述されている。「チャンネル名」、および「チャンネル番号」は、それぞれそれらを表す所定の文字および数値が記述される。例えば、チャンネル単位の記述領域272-1の「チャンネル名」は、「○○局NRT第1チャンネル」などと記述され、チャンネル番号は、「5-1」などと記述される。また、チャンネル単位の記述領域272-1の「チャンネル名」は、「○○局NRT第2チャンネル」などと記述され、チャンネル番号は、「5-2」などと記述される。
 「サービスタイプ」は、当該論理チャンネルが通常放送に対応する論理チャンネルであるかNRT放送に対応する論理チャンネルであるかを識別する情報が記述される。例えば、チャンネル単位の記述領域272-1に対応する論理チャンネルが、NRT放送の論理チャンネルである場合、「サービスタイプ」は、「NRT」と記述される。
 「Source_id」は、当該論理チャンネルを識別するIDとされ、実際には、所定の文字や数値などが記述される。すなわち、チャンネル単位の記述領域272-1は、この「Source_id」により特定される1つの論理チャンネルに関する情報が記述される領域なのである。
 「Push型NRTメタ情報」は、Push型NRT放送を実現するために必要な情報とされ、例えば、次のような情報が記述される。
 「Push型NRTメタ情報」には、当該論理チャンネルがPush型NRT放送のサービスに対応する論理チャンネルであることを表す情報、当該Push型NRT放送のサービスのサービス名が記述される。さらに、当該Push型NRT放送のサービスの概要が記述されるようにしてもよい。また、「Push型NRTメタ情報」には、当該Push型NRT放送のサービスの提供を受ける場合に必要となるストレージサイズ(記憶容量)、当該Push型NRT放送のサービスにおけるコンテンツ配信の最小インターバル(時間的間隔)が記述される。さらに、「Push型NRTメタ情報」には、例えば、当該Push型NRT放送のサービスが有料で提供される場合、課金等の処理に先立って各種の登録などを行うインターネットサーバに接続するためのURLなども記述される。
 同様に、チャンネル単位の記述領域272-2、・・・にも、それぞれ「Source_id」により特定される1つの論理チャンネルに関する情報が記述される。
 本発明のVCTは、このように構成されている。
 NRT-ITの記述領域91に、Push型NRT放送を実現するために必要な情報の記述が追加されるようにする場合、NRT-ITは、図15に示されるように構成される。図15は、本発明において用いられるNRT-ITの例を示す図である。
 同図の例において、NRT-ITの記述領域291には、「Source_id」、「コンテンツ数」、「Push型NRTメタ情報」および、コンテンツ単位の記述領域292-1、コンテンツ単位の記述領域292-2、・・・が記述されている。
 「Source_id」は、図14を参照して上述したものと同様であり、論理チャンネルを識別するIDとされ、実際には、所定の文字や数値などが記述される。これにより、図14のチャンネル単位の記述領域272-1、チャンネル単位の記述領域272-2、・・・のそれぞれに記述された論理チャンネルのいずれかと、当該NRT-ITを対応付けることが可能となる。「コンテンツ数」は、「Source_id」により特定される論理チャンネルにおいて、所定の単位時間に放送されるコンテンツ数を表す数値などとして記述される。
 「Push型NRTメタ情報」は、Push型NRT放送を実現するために必要な情報とされ、図14を参照して説明したものと同様の情報が記述される。
 すなわち、「Push型NRTメタ情報」には、当該論理チャンネルがPush型NRT放送のサービスに対応する論理チャンネルであることを表す情報、当該Push型NRT放送のサービスのサービス名が記述される。さらに、当該Push型NRT放送のサービスの概要などが記述されるようにしてもよい。また、「Push型NRTメタ情報」には、当該Push型NRT放送のサービスの提供を受ける場合に必要となるストレージサイズ(記憶容量)、当該Push型NRT放送のサービスにおけるコンテンツ配信の最小インターバル(時間的間隔)が記述される。さらに、「Push型NRTメタ情報」には、例えば、当該Push型NRT放送のサービスが有料で提供される場合、課金等の処理に先立って各種の登録などを行うインターネットサーバに接続するためのURLなども記述される。
 コンテンツ単位の記述領域292-1、コンテンツ単位の記述領域292-2、・・・には、それぞれ1つのコンテンツに関する情報が記述される。この記述領域は、上述した「コンテンツ数」に記述された数値の分だけ設けられることになる。例えば、当該論理チャンネルにおいて単位時間に放送されるコンテンツの数が5である場合、「コンテンツ数」には数値「5」が記述される。そして、コンテンツ単位の記述領域292-1、コンテンツ単位の記述領域292-2、・・・およびチャンネル単位の記述領域292-5が記述されることになる。
 コンテンツ単位の記述領域292-1には、「content_item_id」、「コンテンツバージョン」、「配信スケジュール」、「コンテンツ有効期限」、「コンテンツ名」、「コンテンツ伝送ロケーション情報」、・・・が記述されている。
 「content_item_id」は、当該コンテンツを識別するIDとされ、実際には、所定の文字や数値などが記述される。すなわち、コンテンツ単位の記述領域292-1は、この「content_item_id」により特定される1つのコンテンツに関する情報が記述される領域なのである。
 「コンテンツバージョン」は、そのコンテンツのバージョンを表す情報が記述される。例えば、図13を参照して上述した第1バージョン(content1(v1))、第2バージョン(content1(v2))のコンテンツが存在する場合、「content1(v1)」と「content1(v2)」の「content_item_id」は同一となる。このため、同一の「content_item_id」が付与されたコンテンツであって、バージョンが異なるコンテンツを識別するための情報として「コンテンツバージョン」が記述される。
 「配信スケジュール」は、当該コンテンツの放送開始時刻および放送終了時刻を表す情報が記述される。なお、当該コンテンツは、NRT放送のコンテンツなので、放送開始時刻および放送終了時刻により、コンテンツを視聴できる時間が表されるものではなく、コンテンツのダウンロードを開始すべき時刻およびコンテンツのダウンロードが終了する時刻が表される。
 「コンテンツ有効期限」は、当該コンテンツの有効期限となる時刻を特定する情報が記述される。有効期限を経過したコンテンツは、受信装置41の記録媒体から削除されるなどして、再生できなくなるようになされている。
 「コンテンツ名」は、当該コンテンツのタイトルなどの文字が記述される。
 「コンテンツ伝送ロケーション情報」は、図6を参照して上述した、IPアドレス、UDPのポート番号、およびFLUTEのセッションを特定するための識別子「TSI」が記述される。この「コンテンツ伝送ロケーション情報」が特定されることで、「Source_id」により特定される論理チャンネルにおいて伝送されるデータのうち、「content_item_id」により特定される1つのコンテンツのデータを識別することが可能となるのである。
 同様に、コンテンツ単位の記述領域292-2、・・・にも、それぞれ「content_item_id」により特定される1つのコンテンツに関する情報が記述される。
 本発明のNRT-ITは、このように構成されている。
 上述したように、Push型NRT放送を実現するために必要な情報は、VCTに記述されるようにしてもよいし、NRT-ITに記述されるようにしてもよい。以下では、Push型NRT放送を実現するために必要な情報がNRT-ITに記述される場合の例について説明する。
 図16および図17を参照して、本発明のNRT-ITのシンタックスの例を説明する。なお、図16と図17は、連続するシンタックスであり、図16の最後の行「num_item_in_section」の次の行として図17の最初の行「for(j=0;j<・・・{」が続くものである。
 図16と図17において枠291で示される範囲が、図15の記述領域291に対応する。また、図17において枠292-1で示される範囲が図15のコンテンツ単位の記述領域292-1に対応する。なお、図16と図17の例では、説明を簡単にするため、コンテンツ単位の記述領域が1つとされている。同図に示されるシンタックスでは、それぞれの記述領域に記述すべき記述子のそれぞれが、ビット数(No.of Bits)とともに定義されている。
 図16において、領域310に記述される8ビットの記述子は、この情報の種類を特定するIDを表すものとされ、予め設定された値が格納される。この記述子によって、この情報がNRT-ITであることが特定される。
 図16において、領域311に記述される16ビットの記述子として示されたものが、図15を参照して説明した「Source_id」に対応する。
 図16において、領域312に記述される記述子として示されたものが、図15を参照して説明した「Push型NRTメタ情報」に対応する。なお、この詳細については、図18を参照して後述する。
 図16において、領域313に記述される8ビットの記述子として示されたものが、図15を参照して説明した「コンテンツ数」に対応する。
 図17において、領域314に記述される14ビットの記述子として示されたものが、図15を参照して説明した「content_item_id」に対応する。
 図17において、領域315に記述される8ビットの記述子として示されたものが、図15を参照して説明した「コンテンツバージョン」に対応する。
 図17において、領域316に記述される記述子により、図15を参照して説明した「配信スケジュール」に対応する情報が記述される。
 図17において、領域317に記述される記述子により、図15を参照して説明した「コンテンツ有効期限」に対応する情報が記述される。
 図17において、領域318に記述される記述子として示されたものが、図15を参照して説明した「コンテンツ名」に対応する。
 図17において、領域319に記述される記述子として示されたものが、図15を参照して説明した「コンテンツ伝送ロケーション情報」に対応する。
 図18は、図16の領域312に記述すべき「Push型NRTメタ情報」のシンタックスの例を示す図である。
 なお、Push型NRT放送を実現するために必要な情報が、NRT-ITに記述されるようにする場合、同図が図16の領域312に記述すべき「Push型NRTメタ情報」のシンタックスの例となる。一方、VCTに記述されるようにする場合、同図は、図14のチャンネル単位の記述領域272-1、チャンネル単位の記述領域272-2、・・・内に記述される「Push型NRTメタ情報」のシンタックスの例となる。
 同図に示されるシンタックスでは、それぞれの記述領域に記述すべき記述子のそれぞれが、ビット数(No.of Bits)とともに定義されている。
 図18の領域341に記述された8ビットの記述子により、当該論理チャンネルがPush型NRT放送のサービスに対応する論理チャンネルであることが表される。
 図18の領域342に記述された記述子により、当該Push型NRT放送のサービスのサービス名が記述される。
 図18の領域343に記述された記述子により、当該Push型NRT放送のサービスにおけるコンテンツ配信の最小インターバル(時間的間隔)が表される。
 図18の領域344に記述された記述子により、当該Push型NRT放送のサービスの提供を受ける場合に必要となるストレージサイズ(記憶容量)が表される。
 図18の領域345に記述された記述子により、当該Push型NRT放送のサービスが有料で提供される場合、課金等の処理に先立って各種の登録などを行うインターネットサーバに接続するためのURLが記述される。
 図19は、図1の受信装置41の構成例を示すブロック図である。同図において、図示せぬアンテナなどを介して受信した放送波に基づく信号は、端子401に供給されるようになされている。
 チューナ402は、コントローラ409の制御に基づいて、端子401から出力される信号から所定の放送チャンネルに対応する信号を抽出し、デジタル信号としてTSDemux403に出力するようになされている。
 TSDemux403は、チューナ402から出力されるデジタル信号からトランスポートパケットを生成する。そしてTSDemux403は、コントローラ409の制御に基づいて、所定の識別子が付与されたトランスポートパケットを抽出し、それらのトランスポートパケットを、所定の論理チャンネルのデータとして出力する。
 当該論理チャンネルが通常放送の論理チャンネルである場合、TSDemux403は、当該論理チャンネルのデータを、ビデオデコーダ404、またはオーディオデコーダ405に出力する。
 ビデオデコーダ404とオーディオデコーダ405は、それぞれ符号化された画像データと符号化された音声データを復号し、画像信号と音声信号を、端子410と端子411に出力するようになされている。
 端子410と端子411には、例えば、テレビジョン受像機などにより構成されるディスプレイとスピーカが接続されるようになされている。
 一方、当該論理チャンネルがNRT放送の論理チャンネルである場合、TSDemux403は、当該論理チャンネルのデータを、FLUTEプロセッサ407に出力する。
 FLUTEプロセッサ407は、当該論理チャンネルのデータとして供給されたデータの中から、FLUTEセッションにより特定されるファイルを取得し、それらのファイルにより構成されるデータを、コンテンツのデータとしてストレージ408に記録する。なお、コンテンツのデータに対応付けられて、例えば、コントローラ409で生成されたメタデータも、ストレージ408に記録されるようにしてもよい。
 ストレージ408は、例えば、HDD(Hard Disk Drive)などの記録媒体であり、コンテンツのデータ、その他、受信装置41において必要な情報を記録する。
 ファイルコンテナDemux406は、コントローラ409の制御に基づいて、再生すべきコンテンツのデータをストレージ408から読み出し、ビデオデコーダ404とオーディオデコーダ405に出力するようになされている。例えば、ストレージ408に記録されているNRT放送のコンテンツが再生される場合、ファイルコンテナDemux406は、コントローラ409の制御に基づいて、そのコンテンツのデータをストレージ408から読み出すようになされている。
 コントローラ409は、例えば、プロセッサ、メモリなどを有する構成とされ、受信装置41の各部を制御する。コントローラ409は、例えば、図示せぬリモコンなどを介して供給される、ユーザによる選局の指令、ダウンロードすべきコンテンツの指定、再生すべきコンテンツの指定などの信号を受け付ける。また、コントローラ409は、例えば、必要に応じてGUI(Graphical User Interface)の表示データを生成し、ビデオデコーダ404を介して、端子410に出力するようになされている。
 図20は、受信装置41に接続されるディスプレイの画面に表示される画像の例を示す図である。
 同図に示される画像は、受信装置41によるPush型NRT放送のサービスの一覧を表示するGUIとされる。図20の例では、カーソル451により「NRT」と表示されたGUI部品が選択された状態とされている。ここでは、「NRT」表示されたGUI部品の図中下側に、アイコン452とアイコン453が表示されている。
 アイコン452の図中右側には、「ニュースクリップ」と表示されており、アイコン452がPush型NRT放送のサービス「ニュースクリップ」に対応するアイコンとされている。また、アイコン453の図中右側には、「天気予報」と表示されており、アイコン453がPush型NRT放送のサービス「天気予報」に対応するアイコンとされている。
 例えば、ユーザがリモコンなどを操作して、アイコン452を選択した場合、図21に示されるような画像がディスプレイの画面に表示される。同図に示される画像は、Push型NRT放送のサービス「ニュースクリップ」の登録を受け付けるGUIとされる。例えば、図21のボタン261が操作されると、受信装置41において、Push型NRT放送のサービス「ニュースクリップ」の登録がなされる。
 Push型NRT放送のサービス「ニュースクリップ」の登録がなされた受信装置41は、「ニュースクリップ」のコンテンツを受信して蓄積するようになされている。そして、受信装置41によりダウンロードされたコンテンツの一覧が、例えば、図22に示されるコンテンツリストとして画面に表示される。なお、図22の例では、「XXXX」が各コンテンツのタイトル、および当該コンテンツのメタデータに含まれる情報などを表示するものとされる。
 受信装置41のユーザは、図22のコンテンツリストをディスプレイの画面などに表示させ、例えば、GUIを操作して視聴したいコンテンツを選択する。これにより、選択されたコンテンツが再生され、図23に示されるように、コンテンツの画像がディスプレイの画面に表示されるのである。この例では、街の様子を撮影した画像がコンテンツの画像として表示されている。
 次に、図24のフローチャートを参照して、受信装置41によるPush型NRT放送サービス登録処理について説明する。
 ステップS101において、受信装置41のコントローラ409は、チューナ402を制御してNRT放送に関するメタデータ、制御情報などを受信させる。
 このとき、例えば、PSIPデータが受信される。なお、上述したように、PSIPデータは、VCT、NRT-ITなどを含んで構成されるデータとされ、受信装置41により定期的に受信されるようになされている。
 ステップS102において、コントローラ409は、Push型NRT放送サービスの一覧を生成する。
 このとき、ステップS101において受信されたNRT-ITのそれぞれについて、図15を参照して上述した「Push型NRTメタ情報」がチェックされる。そして、「Push型NRTメタ情報」において、例えば、図18の領域341に記述された8ビットの記述子により、当該論理チャンネルがPush型NRT放送のサービスに対応する論理チャンネルであるか否かが判定される。当該論理チャンネルがPush型NRT放送のサービスに対応する論理チャンネルであると判定された場合、当該論理チャネルの「チャンネル名」、「チャンネル番号」、および図18の領域342の記述子に基づいて当該Push型NRT放送のサービスのサービス名が取得される。
 このように、ステップS101において受信されたNRT-ITのそれぞれに基づいて、Push型NRT放送のサービスに対応する論理チャンネルが特定されていく。そして、Push型NRT放送サービスの一覧が生成され、図20を参照して上述したようなGUIとして表示される。
 ステップS103において、コントローラ409は、ステップS102の処理で生成されたPush型NRT放送サービスの一覧に基づいて、ユーザによるサービスの選択を受け付ける。このとき、所定のPush型NRT放送サービスが選択される。
 ステップS104において、コントローラ409は、ステップS103の処理で選択されたPush型NRT放送サービスに対応する「Source_id」を記憶する。ここで、「Source_id」は、ステップS101において受信されたNRT-ITに基づいて特定することが可能である。
 また、このとき、図18の領域344に記述された記述子に基づいて、当該Push型NRT放送のサービスの提供を受ける場合に必要となるストレージサイズが特定され、ストレージ408の記憶領域が予約される。
 さらに、例えば、当該Push型NRT放送のサービスが有料で提供される場合、図18の領域345に記述された記述子により、課金等の処理に先立って各種の登録などを行うインターネットサーバに接続するためのURLが特定される。そして、当該URLに基づいて、受信装置41がインターネットサーバにアクセスし、有料視聴契約の処理が実行される。
 このようにして、Push型NRT放送サービス登録処理が実行される。上述したように、本発明では、Push型NRT放送の個々のサービスに対応する論理チャンネルが設けられているので、登録されたPush型NRT放送サービスに対応する論理チャンネルを特定する「Source_id」が記憶されるのである。
 次に、図25のフローチャートを参照して、受信装置41によるPush型NRT放送受信再生処理について説明する。
 ステップS121において、受信装置41のコントローラ409は、チューナ402を制御してNRT放送に関するメタデータ、制御情報などを受信させる。
 このとき、例えば、PSIPデータが受信される。なお、上述したように、PSIPデータは、VCT、NRT-ITなどを含んで構成されるデータとされ、受信装置41により定期的に受信されるようになされている。そして、PSIPデータが受信されるタイミングで、ステップS122のダウンロードスケジュール生成処理が実行されるようになされている。
 ステップS122において、コントローラ409は、図26を参照して後述するダウンロードスケジュール生成処理を実行する。これにより、Push型NRT放送のコンテンツのダウンロードが予約される。
 ここで、図26のフローチャートを参照して、図25のステップS122のダウンロードスケジュール生成処理の詳細な例について説明する。
 ステップS141において、コントローラ409は、図24のステップS104の処理で記憶された「Source_id」に基づいて、NRT-ITを取得する。すなわち、ステップS121で受信したPSIPデータに含まれるNRT-ITのうち、ステップS104の処理で記憶された「Source_id」に対応するNRT-ITが抽出されて取得されるのである。
 ステップS142において、コントローラ409は、ステップS141の処理で取得されたNRT-ITのコンテンツ単位の記述領域をチェックする。このとき、例えば、図15のコンテンツ単位の記述領域292-1の記述内容がチェックされる。
 ステップS143において、コントローラ409は、ステップS142でチェックしたコンテンツ単位の記述領域に記述された「content_item_id」と「コンテンツバージョン」を取得する。
 ステップS144において、コントローラ409は、同一のコンテンツがストレージ408に記録されているか否かを判定する。すなわち、「content_item_id」と「コンテンツバージョン」がそれぞれ同じコンテンツを既に受信して蓄積済であるか否かが判定される。ステップS144において、同一のコンテンツがストレージ408に記録されていないと判定された場合、処理は、ステップS145に進む。
 ステップS145において、コントローラ409は、同一のコンテンツのダウンロードがスケジュールされているか否かを判定する。例えば、図13を参照して上述した「content1(v1)」のように、同一のコンテンツが2回繰り返して放送される場合、どちらか1回の放送でダウンロードを行えばよい。このため、ステップS145において、同一のコンテンツのダウンロードがスケジュールされているか否かが判定されるのである。ステップS145において、同一のコンテンツのダウンロードがスケジュールされていないと判定された場合、処理は、ステップS146に進む。
 ステップS146において、コントローラ409は、ステップS142でチェックしたコンテンツ単位の記述領域に記述された「配信スケジュール」を取得する。これにより、当該コンテンツの放送開始時刻と放送終了時刻が取得されることになる。
 ステップS147において、コントローラ409は、ステップS142でチェックしたコンテンツ単位の記述領域に対応するコンテンツのダウンロードをスケジュールする。
 なお、ステップS144において、同一のコンテンツがストレージ408に記録されていると判定された場合、ステップS145乃至ステップS147の処理は、スキップされる。また、ステップS145において、同一のコンテンツのダウンロードがスケジュールされていると判定された場合、ステップS146、およびステップS147の処理はスキップされる。
 ステップS148において、コントローラ409は、ステップS141の処理で取得されたNRT-ITの中に、次のコンテンツ単位の記述領域があるか否かを判定する。図15の例では、コンテンツ単位の記述領域292-1の次に、コンテンツ単位の記述領域292-2があるので、ステップS148では、次のコンテンツ単位の記述領域があると判定され、処理は、ステップS142に戻る。
 そして、ステップS142では、コンテンツ単位の記述領域292-2の記述内容がチェックされ、ステップS143乃至ステップS147の処理が繰り返し実行される。
 このように、ステップS148において、次のコンテンツ単位の記述領域がないと判定されるまで、ステップS142乃至ステップS148の処理が繰り返し実行される。ステップS148において、次のコンテンツ単位の記述領域がないと判定された場合、ダウンロードスケジュール生成処理は終了する。
 図26の処理の終了に伴って、例えば、コントローラ409の内部のメモリなどに、Push型NRT放送のコンテンツのダウンロードスケジュールが記憶される。ダウンロードスケジュールは、例えば、ダウンロードすべきコンテンツの物理チャンネル、論理チャンネル、FLUTEセッションを特定する情報などの一覧として構成される。すなわち、ダウンロードスケジュールは、例えば、従来の録画予約情報などと同様に、受信装置41が自動的にダウンロードを実行するための予約情報である。
 これ以後、受信装置41は、このダウンロードスケジュールに従って、コンテンツのダウンロードを行うことになる。
 図25に戻って、ステップS122の処理の後、処理は、ステップS123に進む。ステップS123において、コントローラ409は、ステップS122の処理で生成されたダウンロードスケジュールにおけるコンテンツの放送開始時刻になったか否かを判定し、放送開始時刻になったと判定されるまで待機する。ステップS123において、放送開始時刻になったと判定された場合、処理は、ステップS124に進む。
 ステップS124において、コントローラ409は、チューナ402、TSDemux403、およびFLUTEプロセッサ407を制御してコンテンツをダウンロードする。
 このとき、受信装置41のチューナ402の選局が、ダウンロードスケジュールにおいて指定されている物理チャンネルに対応する放送チャンネルに設定される。また、TSDemux403がダウンロードスケジュールにおいて指定されている論理チャンネルのデータFLUTEプロセッサ407に出力する。そして、FLUTEプロセッサ407がダウンロードスケジュールにおいて指定されているFLUTEセッションのファイルを取得する。コンテンツの放送終了時刻になると、受信装置41において、FLUTEセッションストリームを構成する全てファイルの取得が完了し、これにより、コンテンツのダウンロードが完了する。
 ステップS125において、コントローラ409は、ステップS124の処理でダウンロードしたコンテンツを既に記録されているコンテンツに上書きするか否かを判定する。例えば、既に記録されているコンテンツと「content_item_id」が同一であり、「コンテンツバージョン」が異なるコンテンツがダウンロードされた場合、コンテンツに上書きすると判定される。
 さらに、ステップS125では、図18の領域344に記述された記述子により指定された当該Push型NRT放送のサービスの提供を受ける場合に必要となるストレージサイズに基づいて、上書きするか否かが判定される。すなわち、予め指定されたストレージサイズを超えて、コンテンツのデータを記録する必要がある場合、既に記録されているコンテンツに上書きすると判定される。この場合、例えば、ステップS124の処理でダウンロードしたコンテンツが、既に記録されているコンテンツのうち、最も古いコンテンツに上書きされる。
 ステップS125において、ダウンロードしたコンテンツを既に記録されているコンテンツに上書きすると判定された場合、処理は、ステップS127に進み、ステップS124の処理でダウンロードしたコンテンツは、上書きして記録される。これにより、当該コンテンツのバージョンが更新されることになる。
 一方、ステップS125において、ダウンロードしたコンテンツを既に記録されているコンテンツに上書きしないと判定された場合、処理は、ステップS126に進み、ステップS124の処理でダウンロードしたコンテンツは、新たにストレージ408に記録される。
 なお、コンテンツが記録されるとき、ステップS121で受信した情報に含まれる、当該コンテンツのメタデータも、当該コンテンツに対応付けられて記録されるようにしてもよい。なお、メタデータは、例えば、NRT-ITに記述された「コンテンツ名」、「配信スケジュール」、「コンテンツ有効期限」などから構成される。
 ここでは、1つのコンテンツがダウンロードされる場合の例について述べたが、実際には、ダウンロードスケジュールに従って、複数のコンテンツがダウンロードされる。
 なお、例えば、送信装置41のユーザが、処理の途中で当該Push型NRT放送のサービスの登録を解除した場合、それ以後、コンテンツのダウンロードはなされない。
 ステップS128において、コントローラ409は、ステップS126またはステップS127の処理で記録されたコンテンツのリストを表示する。このとき、例えば、図22に示されるような画像が生成されてディスプレイに表示される。
 なお、上述したようにコンテンツには、それぞれ有効期限が設定されており、有効期限を経過したコンテンツは、ステップS128において表示されるコンテンツのリストには含まれないようになされている。有効期限は、例えば、図15を参照して説明した「コンテンツ有効期限」に基づいて特定することができる。
 ステップS129において、コントローラ409は、ステップS128の処理で表示したコンテンツのリストに基づく、ユーザによるコンテンツの選択を受け付ける。このとき、例えば、既にストレージ408に記録されているNRT放送のコンテンツのうち、ユーザが視聴したいと考えるコンテンツが選択される。
 ステップS130において、コントローラ409は、ファイルコンテナDemux406を制御して、ステップS129の処理で選択が受け付けられたコンテンツを再生する。これにより、例えば、図23に示されるように、コンテンツの画像がディスプレイに表示されるのである。
 なお、登録したPush型NRT放送のサービスが有料で提供される場合、当該サービスに対応する論理チャンネルのデータは全て暗号化されて放送される。しかし、当該サービスに登録した受信装置41には、予めEMMパケットとして当該サービスに対応する論理チャンネルのデータを復号するための鍵が伝送されるようになされている。従って、当該サービスに登録した受信装置41においては、予め伝送されて記憶されている鍵を用いて暗号化されたデータを復号し、コンテンツを視聴することが可能となる。
 このようにして、受信装置41によるPush型NRT放送受信再生処理が実行される。このように、本発明では、Push型NRT放送のサービスが登録された受信装置41が、そのサービスに対応する論理チャンネルにおいて伝送されるコンテンツの全てを自動的にダウンロードするようにした。従って、既存の設備や規格などの大規模な変更を行なうことなく、Push型NRTサービスを実現することができる。
 また、本発明の受信装置41により受信されるNRT放送の放送波は、送信装置21により送信される。送信装置21は、例えば、メタ情報、制御情報などのデータ、およびコンテンツのデータを多重化した信号を生成する多重化部を有する構成とされる。
 コンテンツのデータは、ビデオデータとオーディオデータをエンコードするAVエンコーダにより、例えば、MPEG方式で圧縮符号化された画像データおよび音声データからなるデータである。
 メタ情報、制御情報などのデータは、例えば、PSIPデータなどにより構成されるデータである。
 送信装置21は、例えば、予め定められた放送スケジュールに対応するVCTとNRT-ITを生成し、VCTとNRT-ITを含むPSIPデータなどにより構成されるデータを付加データとして生成する。そして送信装置21は、放送スケジュールに基づいて、多重化部で付加データとコンテンツのデータを多重化した信号を生成し、その信号を変調して放送波として出力するようになされている。
 図27のフローチャートを参照して、送信装置21によるNRT放送の放送波送信処理について説明する。
 ステップS161において、送信装置21の制御部は、放送スケジュールを取得する。なお、放送スケジュールには、後述する放送されるコンテンツに関する情報が含まれるものとする。
 ステップS162において、送信装置21の制御部は、放送されるコンテンツに関する情報を取得する。なお、コンテンツに関する情報には、例えば、「content_item_id」、「配信スケジュール」、「コンテンツ有効期限」、「コンテンツ名」、Push型のコンテンツかPull型のコンテンツかを表す情報などが含まれるものとする。
 ステップS163において、送信装置21の制御部は、ステップS162の処理で取得した情報に係るコンテンツがPush型NRT放送のコンテンツであるか否かを判定する。なお、実際には、放送スケジュールに記載されている複数のコンテンツのそれぞれについて、ステップS163の処理が実行されるものである。
 ステップS163において、ステップS162の処理で取得した情報に係るコンテンツがPush型NRT放送のコンテンツであると判定された場合、処理は、ステップS164に進む。
 ステップS164において、送信装置21の制御部は、Push型放送用のNRT-ITを生成する。このとき、例えば、図15を参照して上述したNRT-ITが生成される。
 ステップS163において、ステップS162の処理で取得した情報に係るコンテンツがPush型NRT放送のコンテンツではないと判定された場合、処理は、ステップS165に進む。
 ステップS165において、送信装置21の制御部は、Pull型放送用のNRT-ITを生成する。このとき、例えば、図8を参照して上述したNRT-ITが生成される。
 ステップS166において、送信装置21の制御部は、VCTを生成する。
 ステップS167において、送信装置21の制御部は、VCTとNRT-ITを含むPSIPデータなどにより構成される付加データを生成する。
 ステップS168において、送信装置21の多重化部は、放送スケジュールに基づいて、付加データとコンテンツのデータを多重化した信号を生成する。なお、このとき、付加データとコンテンツのデータの多重化と同時に、複数の論理チャンネルで放送されるデータが、1つの物理チャンネルで放送されるデータとして多重化される。
 ステップS169において、送信装置21は、ステップS168の処理で生成された信号を変調し、ステップS170において、ステップS169の処理で変調された信号の放送波を出力する。
 このようにして、NRT放送の放送波送信処理が実行される。
 なお、図24乃至図27を参照して上述した処理においては、Push型NRT放送を実現するために必要な情報(例えば、「Push型NRTメタ情報」)がNRT-ITに記述されることを想定して説明した。しかし、勿論、Push型NRT放送を実現するために必要な情報が、例えば、図14を参照して説明したように、VCTに記述されるようにしてもよい。
 このように、本発明によれば、既存の設備や規格などの大規模な変更を行なうことなく、Push型NRTサービスを実現することができる。
 ところで、図14を参照して上述した例では、Push型NRT放送を実現するために必要な情報(例えば、「Push型NRTメタ情報」)がVCTに直接記述されるようにしたが、このような情報は、別の制御情報に記述されるようにしてもよい。
 例えば、図14のVCTにおいて、チャンネル単位の記述領域272-1、チャンネル単位の記述領域272-2、・・・に記述される「Push型NRTメタ情報」に替えて「通常/NRT識別情報」が記述されるようにする。「通常/NRT識別情報」は、当該論理チャンネルが通常放送の論理チャンネルであるか、NRT放送の論理チャンネルであるかを表す情報とされる。そして、当該論理チャンネルがNRT放送の論理チャンネルである場合、受信装置41により、SMT(Service Map Table)がVCTに加えて受信されるようにする。そして、SMTに、Push型NRT放送を実現するために必要な情報(例えば、「Push型NRTメタ情報」)が記述されるようにする。
 この場合、例えば、物理チャンネル毎にSMTが生成されるようにする。
 例えば、図14を参照して上述したように、「TS_id」は、トランスポートストリームを識別するIDとされ、実際には、所定の文字や数値などが記述される。これにより、どの物理チャンネル(放送チャネル)のVCTであるかを識別することが可能となる。例えば、この「TS_id」に基づいて、SMTが特定される。
 また、上述したように、VCTのチャンネル単位の記述領域272-1には、「チャンネル名」、「チャンネル番号」、「サービスタイプ」、「Program_number」、「Source_id」、「Push型NRTメタ情報」・・・が記述されている。
 「Source_id」は、当該論理チャンネルを識別するIDとされ、実際には、所定の文字や数値などが記述される。すなわち、チャンネル単位の記述領域272-1は、この「Source_id」により特定される1つの論理チャンネルに関する情報が記述される領域なのである。
 同様に、チャンネル単位の記述領域272-2、・・・にも、それぞれ「Source_id」により特定される1つの論理チャンネルに関する情報が記述される。
 また、図15の例において、NRT-ITの記述領域291には、「Source_id」、「コンテンツ数」、「Push型NRTメタ情報」および、コンテンツ単位の記述領域292-1、コンテンツ単位の記述領域292-2、・・・が記述されている。
 「Source_id」は、図14を参照して上述したものと同様であり、論理チャンネルを識別するIDとされ、実際には、所定の文字や数値などが記述される。これにより、図14のチャンネル単位の記述領域272-1、チャンネル単位の記述領域272-2、・・・のそれぞれに記述された論理チャンネルのいずれかと、当該NRT-ITを対応付けることが可能となる。
 従って、NRT-ITは、論理チャンネル単位に生成されるのである。
 上述したSMTには、複数の「Source_id」のそれぞれに対応するNRT-ITのそれぞれに関する情報が記述される。そして、SMTには、複数のNRT-ITのそれぞれのコンテンツ単位の記述領域に記述されたコンテンツについての、Push型NRT放送を実現するために必要な情報が記述されるようにする。
 すなわち、SMTは、VCTと同様に、論理チャンネルに関する情報が記述された所定の記述データとして伝送される。また、NRT-ITは、論理チャンネルで放送されるコンテンツのメタデータの一例ということもできる。
 このようにすることで、例えば、1つの論理チャンネルで放送されるコンテンツの全てがPush型NRT放送のコンテンツとして受信されるようにすることができる。さらに、例えば、1つの論理チャンネルで放送されるコンテンツのうち、所定の時間帯に放送されるコンテンツがPull型NRT放送のコンテンツとし、他の時間帯に放送されるコンテンツがPush型NRT放送のコンテンツとして受信されるようにすることもできる。
 本発明の放送システム1においては、このようにVCTとSMTが構成されて伝送されるようにしてもよい。
 また、以上においては、NRT-ITにコンテンツ単位の記述領域を設けて、各コンテンツについての「コンテンツ伝送ロケーション情報」が記述される例について説明した。上述したように、「コンテンツ伝送ロケーション情報」が特定されることで、「Source_id」により特定される論理チャンネルにおいて伝送されるデータのうち、「content_item_id」により特定される1つのコンテンツのデータを識別することが可能となる。
 すなわち、「コンテンツ伝送ロケーション情報」によりFLUTEセッションが特定され、FLUTEセッションストリームを構成するデータが取得される。FLUTEセッションストリームは、実際には、所定のサイズに分割された複数のファイルにより構成されており、この複数のファイルのそれぞれには、「TOI」が付されている。上述した例では、「TOI」が0のファイルであるFDTに基づいて、所定のFLUTEのセッションにより伝送されるコンテンツのデータが取得されていくものと説明した。
 なお、FLUTEセッションは、コンテンツのデータの伝送に用いられるファイル伝送セッションの一例ともいうことができ、FDTは、ファイル伝送セッションの制御情報であって、伝送制御データの一例であるということもできる。
 しかし、近年、コンテンツの視聴は、テレビジョン受像機などのAV機器を用いずに、パーソナルコンピュータなどを用いて行なわれることも多くなっている。従って、受信装置41におけるコンテンツの視聴も、例えば、インターネットでのコンテンツの取得に対応する方式で行なうことができれば利便性が向上する。例えば、FDTに基づいて、当該コンテンツを構成するファイルのアドレス情報が記述されたアドレスファイルが特定され、アドレスファイルに記述されたアドレス情報に基づいて、当該コンテンツを構成するファイルが取得されるようにしてもよい。
 例えば、受信装置41にブラウザなどのアプリケーションソフトウェアを実装させる。そして、ブラウザのRSSリーダの機能を利用して、RSSで記述されたアドレスファイルを解析できるようにする。
 このアドレスファイルは、例えば、インターネットにおいて用いられているRSS(RDF Site Summary)形式で記述されるようにする。RSSは、ウェブサイトの見出しや要約などのメタデータを構造化して記述するXML(eXtensible Markup Language)文のフォーマットである。
 図28は、RSS形式で記述されたアドレスファイルを用いてコンテンツを構成するファイルが取得される場合の例を説明する図である。上述したように、NRT-ITのコンテンツ単位の記述領域に、各コンテンツについての「コンテンツ伝送ロケーション情報」が記述される。この例では、NRT-ITに記述された「content_item_id = http://example.com/NRT/rss.xml」という情報と、「IP_Address/Port/TSI = xx/xx/xx」という情報が表されている。「IP_Address/Port/TSI = xx/xx/xx」は、「コンテンツ伝送ロケーション情報」を表すものであり、「xx/xx/xx」として実際には、IPアドレス、ポート番号、TSIが記述される。
 これによりFLUTEセッションが特定され、FLUTEセッションストリームを構成するデータが取得される。FLUTEセッションストリームの複数のファイルのそれぞれには、「TOI」が付され、「TOI」が0のFDTが取得される。この例では、FDTの記述領域の一部である領域501に、「<File」で始まるXML文が記述されている。
 領域501には、「Content-Location=http://XYZ.com/newsHeadline/rss.xml」と記述されている。これは、領域501の記述により、「XYZ.com/newsHeadline/rss.xml」というRSS形式のアドレスファイルが特定されることを表している。そして、「TOI=“1”」という記述により、特定すべきアドレスファイルの識別子が表されている。すなわち、「TOI」が1のファイルがアドレスファイルであることを表している。さらに、「Content-Type="application/rss+xml"」という記述により、アドレスファイルがRSS形式で記述されていることが表される。
 受信装置41は、「TOI」が1のファイルをアドレスファイルとして取得し、アドレスファイルに記述されている「<enclosure」で始まるXML文のタグを参照することで目的とするコンテンツのファイルのアドレス情報を取得する。この例では、「url=http://XYZ.com/newsHeadline/title1.mp4・・・」と記述されている。これにより、FDTの記述領域の一部である領域502が特定されることになる。
 領域502には、「Content-Location=http://XYZ.com/newsHeadline/title1.mp4」と記述されている。これは、領域502の記述により、「XYZ.com/newsHeadline/title1.mp4・・・」というMPEG4(mp4)形式のコンテンツのファイルが特定されることを表している。そして、「TOI=“2”」という記述により、特定すべきアドレスファイルの識別子が表されている。すなわち、「TOI」が2のファイルがコンテンツのファイルであることを表している。さらに、「Content-Type="video/mp4" 」という記述により、そのファイルがMPEG4(mp4)形式で圧縮符号化されたファイルであることが表される。
 そして、受信装置41は、「TOI」が2のファイルをコンテンツのファイルとして取得し、MPEG4形式で圧縮符号化されたファイルを復号することにより当該コンテンツを再生することが可能となる。
 このようにすることで、受信装置41を、例えば、ブラウザなどのアプリケーションソフトウェアを実装したパーソナルコンピュータなどとして構成することが可能となる。
 図29は、RSS形式で記述されたアドレスファイルの例を示す図である。同図において、領域521の「<title>News Headline by XYZ</title>」という記述は、当該アドレスファイルにより特定されるコンテンツのタイトルが「News Headline by XYZ」であることを表している。
 また、領域522には、「<item」で始まるXML文が記述されている。領域522の中の「<enclosure url=http://XYZ.com/newsHeadline/title01.mp4 length="123456789" type="video/mp4"/>」という記述は、RSSの記述形式として規定されている「enclosure」要素に関する記述である。「enclosure」要素は、本来、RSSによって配信される配信物に添付されているメディアを示す要素であるが、いまの場合、FDTに記述された「<File」で始まるXML文を特定するための情報として用いられる。
 すなわち、「enclosure」要素の「url=http://XYZ.com/newsHeadline/title01.mp4」は、図28のFDTの領域502に記述された「Content-Location=http://XYZ.com/newsHeadline/title1.mp4」を特定するために用いられる。また、「enclosure」要素の「length="123456789"」は、当該コンテンツのファイルのバイト長を表す記述である。また、また、「enclosure」要素の「type="video/mp4"」は、当該コンテンツのファイルがMPEG4形式で圧縮された動画(video)ファイルであることを表す記述である。
 なお、アドレスファイルの中に領域522と同様に、「<item」で始まるXML文を複数記述すれば、当該アドレスファイルにより複数のコンテンツのファイルを特定することが可能となる。
 このように、本発明によれば、受信装置41にブラウザなどのアプリケーションソフトウェアを実装させ、ブラウザのRSSリーダの機能を利用して、RSSで記述されたアドレスファイルを解析できるようにすることが可能となる。従って、例えば、インターネットでのWEBページの閲覧などの場合と同様の装置と方式により、コンテンツを受信して視聴することが可能となる。なお、RSS形式で記述されたアドレスファイルを用いてコンテンツを視聴する方式は、Push型NRT放送にもPull型NRT放送にも適用することができる。
 例えば、図10のステップS16、または図25のステップS124におけるコンテンツのダウンロードは、図28と図29を参照して上述したようにコンテンツファイルが取得されることにより行なわれるようにしてもよい。つまり、FDTに基づいて、アドレスファイルが特定され、アドレスファイルに記述されたアドレス情報に基づいて、当該コンテンツを構成するファイルが取得されるようにすることで、コンテンツのダウンロードが行われるようにしてもよい。また、このようにする場合、送信装置21が送信するコンテンツのデータは、上述したように、FDTとコンテンツファイルの他にアドレスファイルを含んで構成されるものとなる。
 ところで、図12を参照して上述した例においては、受信装置41が定期的にPSIPデータを受信するので、定期的にVCT、およびNRT-ITを取得することができるものと説明した。そして、図12の例では、最初にVCT210、NRT-IT211、およびNRT-IT212が受信され、コンテンツA、コンテンツBが伝送される論理チャンネルとFLUTEセッションのファイルが特定されるものとされていた。さらに、VCT220とNRT-IT221およびNRT-IT222が新たに受信されて更新され、VCT220、NRT-IT221に基づいてコンテンツCが伝送される論理チャンネルとFLUTEセッションのファイルが特定されると説明した。
 すなわち、上述の例においては、コンテンツを新たに伝送する場合、予めPSIPデータを生成して、VCT、NRT-ITを新たに受信装置41に受信させる必要がある。
 しかし、RSS形式で記述されたアドレスファイルを用いてコンテンツを視聴する方式では、VCT、NRT-ITを新たに受信装置41に受信させなくとも、新たなコンテンツを伝送して受信装置41で視聴させることができる。
 すなわち、VCT、NRT-ITを受信装置41に受信させて、論理チャンネルとFLUTEセッションを特定させた後、当該論理チャンネルのFLUTEセッションにおいて伝送されるFDTとアドレスファイルの内容を所定のタイミングで変更するのである。このようにすることで、VCT、NRT-ITを新たに受信装置41に受信させなくとも、新たなコンテンツを伝送して受信装置41で視聴させることができる。
 図30は、VCT、NRT-ITを新たに受信装置41に受信させなくとも、新たなコンテンツを伝送して受信装置41で視聴させることができるようにする方式を説明する図である。同図の縦軸は時間を表しており、矢印SがVCT、NRT-ITの更新周期を表している。なお、VCT、NRT-ITの更新周期は、PSIPデータの送信周期と等しいものとなる。
 図30において、VCT、NRT-ITに基づいて受信装置41が特定した論理チャンネルのFLUTEセッションでは、9時(09:00:00)から10時(10:00:00)までの間、「FDT instance01」、「RSS 01」、「コンテンツファイル01」が繰り返し送信される。ここで、「FDT instance01」は、TOIが0のFDTのファイルであり、「RSS 01」は、「FDT instance01」により特定されるRSS形式で記述されたアドレスファイルである。「コンテンツファイル01」は、「FDT instance01」と「RSS 01」により特定されるコンテンツのファイルである。
 また、VCT、NRT-ITに基づいて受信装置41が特定した論理チャンネルのFLUTEセッションでは、10時(10:00:00)以後は、「FDT instance02」、「RSS 02」、「コンテンツファイル02」が繰り返し送信される。ここで、「FDT instance02」は、TOIが0のFDTのファイルであり、「RSS 02」は、「FDT instance02」により特定されるRSS形式で記述されたアドレスファイルである。「コンテンツファイル02」は、「FDT instance02」と「RSS 02」により特定されるコンテンツのファイルである。
 すなわち、図30の例では、VCT、NRT-ITに基づいて受信装置41が特定した論理チャンネルのFLUTEセッションは、同一であるものの、FDT、アドレスファイル、およびコンテンツのファイルが時間によって異なるものとされている。
 例えば、「コンテンツファイル01」がコンテンツDのファイルであり、「コンテンツファイル02」がコンテンツEのファイルであった場合、受信装置41では、9時から10時までの間はコンテンツDが受信でき、10時以後はコンテンツEが受信できるようになる。
 図31と図32は、図30の例において用いられるRSS形式で記述されたアドレスファイルの例を示す図である。
 図31は、図30の「RSS 01」に対応するアドレスファイルである。同図における領域541と領域542は、それぞれ図29の領域521と領域522と同様の内容を記述する領域なので、詳細な説明は省略する。
 図31の例では、図29の場合と異なり、領域543が設けられている。領域543には、「<pubDate>Tue, 10 Jun 2003 09:00:00 GMT</pubDate>」と記述されている。これは、当該アドレスファイルが、西暦2003年6月10日(火曜日)の9時(GMT(グリニッジ標準時))に生成されたことを表している。
 また、図31の例では、図29の場合と異なり、領域544が設けられている。領域544には、「<skipHours><hour>9</hour></skipHours>」と記述されている。この記述は、RSSの記述形式として規定されている「skipHours」要素に関する記述である。「skipHours」要素は、クロールを禁止する時間帯を指定する記述であり、「<hour>」のタグで囲まれた部分に記述された数値に対応する時間帯でのクロールが禁止される。図31の場合、西暦2003年6月10日の9時から1時間の間、ファイルを更新しない(クロールしない)ことを表している。
 受信装置41は、図30の矢印Sの上端部に対応する時刻においてVCT、NRT-ITを受信し、論理チャンネルとFLUTEセッションを特定する。これにより、受信装置41は、9時になると自動的に「FDT instance01」を取得し、これに基づいて、図31に示されるアドレスファイルも取得することになる。図31に示されるアドレスファイルを取得した受信装置41は、9時に「FDT instance01」における領域502(図28)に対応する領域を参照して、「コンテンツファイル01」を取得することになる。そして、その後1時間、すなわち10時になるまでの間は、「コンテンツファイル01」を取得することはない。また、図31に示されるアドレスファイルを取得した受信装置41は、9時から1時間経過後に、コンテンツのファイルを自動的に取得する(クロールする)ことになる。
 10時になると、当該FLUTEセッションで伝送されるFDTの記述が変更されることになる。すなわち、10時になると、TOIが0のファイルとして「FDT instance02」が伝送されるようになるのである。「FDT instance02」は、「skipHours」要素に関する記述の如何に係らず受信装置41により取得される。FDTは、VCT、NRT-ITに基づいて受信装置41が特定した論理チャンネルのFLUTEセッションにおいて自動的に取得されるファイルだからである。
 従って、受信装置41は、10時になると、自動的に「FDT instance02」を取得する。また、上述したように10時になると、受信装置41は、図31に示されるアドレスファイルの記述内容に基づいて、自動的にコンテンツのファイルと取得する処理を行う。ここでのファイルの取得は、図31の「skipHours」要素に関する記述に基づいて行なわれるものである。
 すなわち、受信装置41は、10時になると、「FDT instance02」の記述に基づいて、図32に示されるアドレスファイルも取得することになる。「FDT instance02」によって特定されるアドレスファイルは、「RSS 02」だからである。
 図32は、図30の「RSS 02」に対応するアドレスファイルである。図32において、領域541の記述と領域542の記述は、それぞれ図31の場合と同様なので、詳細な説明は省略する。
 図32においては、領域543に、「<pubDate>Tue, 10 Jun 2003 10:00:00 GMT</pubDate>」と記述されている。これは、当該アドレスファイルが、西暦2003年6月10日(火曜日)の10時(GMT(グリニッジ標準時))に生成されたことを表している。領域544には、「<skipHours><hour>10</hour></skipHours>」と記述されている。これは、西暦2003年6月10日の10時から1時間の間、ファイルを更新しない(クロールしない)ことを表している。
 従って、図32に示されるアドレスファイルを取得した受信装置41は、10時に「FDT instance02」における領域502(図28)に対応する領域を参照して、「コンテンツファイル02」を取得することになる。そして、その後1時間、すなわち11時になるまでの間は、「コンテンツファイル02」を取得することはない。また、図32に示されるアドレスファイルを取得した受信装置41は、10時から1時間経過後に、ファイルを自動的に取得する(クロールする)ことになる。
 従って、その後、TOIが0のファイルとして「FDT instance02」を、「skipHours」要素に関する記述の如何に係らず取得する。FDTは、VCT、NRT-ITに基づいて受信装置41が特定した論理チャンネルのFLUTEセッションにおいて自動的に取得されるファイルだからである。
 また、図32に示されるアドレスファイルを取得した受信装置41は、上述したように11時になると、受信装置41は、図32に示されるアドレスファイルの記述内容に基づいて、自動的にコンテンツのファイルと取得する処理を行う。ここでのファイルの取得は、図32の「skipHours」要素に関する記述に基づいて行なわれるものである。
 すなわち、受信装置41は、11時になると、「FDT instance02」の記述に基づいて、図32に示されるアドレスファイルも取得することになる。「FDT instance02」によって特定されるアドレスファイルは、「RSS 02」だからである。そして、「FDT instance02」における領域502(図28)に対応する領域を参照して、「コンテンツファイル02」を再度取得することになる。いまの場合、結果として10時に取得されたコンテンツのファイルと11時に取得されたコンテンツのファイルは同じ内容(「コンテンツファイル02」)であったことになる。
 このようにして、VCT、NRT-ITを新たに受信装置41に受信させなくとも、新たなコンテンツを伝送して受信装置41で視聴させることができる。例えば、ニュース速報をWEBページの画像として受信装置41のディスプレイに表示し、所定の時間間隔で自動的に画像が更新されていくようにすることも可能である。
 すなわち、例えば、図10のステップS16、または図25のステップS124におけるコンテンツのダウンロードは、図30乃至図32を参照して上述したようにコンテンツファイルが取得されることにより行なわれるようにしてもよい。つまり、FDTに基づいて、アドレスファイルが特定され、アドレスファイルに記述されたアドレス情報に基づいて、当該コンテンツを構成するファイルが取得されるようにする。また、そのアドレスファイルに記述されたファイルの取得時間帯を制御する情報(例えば、「skipHours」要素に関する記述)に基づいて繰り返しコンテンツのファイルが取得されることで、コンテンツのダウンロードが行われるようにしてもよい。
 このようにすることで、VCT、NRT-ITを含むPSIPデータを生成しなくても、新たなNRT放送のコンテンツを伝送して視聴させることができるようになる。従って、例えば、放送局などにおいて、新たなNRT放送のコンテンツを伝送するに際して、都度VCT、NRT-ITを含むPSIPデータを生成する必要がなく、より変化に富んだ放送スケジュールを策定することができる。
 以上においては、RSS形式で記述されたアドレスファイルを用いる場合の例について説明したが、ATOM形式で記述されたアドレスファイルが用いられるようにしても構わない。
 以上に説明した例については、主にATSC(Advanced Television Systems Committee)の規格に適合する方式でPush型NRT放送を実現できるようにする実施の形態について説明した。しかし、例えば、ARIB(Association of Radio Industries and Businesses)の規格に適合する方式でPush型NRT放送を実現できるようにすることも可能である。
 ARIBの規格に適合する方式のNRT放送の場合、放送される番組(プログラム)がグループに分類される。
 ここでグループは、例えば、シリーズで放送されるプログラムなどをまとめて表す場合の単位とされる。また、グループは、階層化されて構成されるようになされており、例えば、1つのグループを親グループとし、複数の子グループがその親グループに含まれるように構成することができる。このグループを、後述するように物理チャンネルを多重化した論理チャンネルとして考えることも可能である。
 プログラムは、コンテンツとほぼ同じ意味であり、例えば、1つのグループに複数のプログラムが含まれる。
 ARIBの規格に適合する方式のNRT放送の場合、原則として、受信装置41のユーザが予めNRT放送の視聴契約を行い、料金を支払うことが想定されている。すなわち、料金を支払ったユーザのみが、当該視聴契約の対象となっているプログラムを視聴することができるようになされている。
 例えば、プログラムを構成する画像データ、音声データなどのファイルは暗号化されて放送され、料金を支払ったユーザの受信装置41において、受信したプログラムのライセンスを取得して当該プログラムのファイルを復号するようになされている。
 ARIBの規格に適合する方式のNRT放送の場合、上述したグループ、プログラム、ライセンスなどの情報が、ECGメタデータとして送信され、受信装置41により受信されるようになされている。
 図33は、ARIBの規格に適合する方式のNRT放送を含む放送波の信号におけるプロトコルスタックを説明する図である。ARIBの規格に適合する方式のNRT放送は、衛星ダウンロード放送と称される。
 図33に示されるように、最も下位の階層は、「物理層」とされ、衛星ダウンロード放送のために割り当てられた放送波の周波数帯域がこれに対応する。「物理層」に隣接する上位の階層は、「スロット」とされている。「スロット」は、時分割された伝送帯域とされ、例えば、1つの放送チャンネルに48スロットが割り当てられる。
 「スロット」に隣接する上位の階層は、「TLV(Type Length Value)」とされている。「TLV」においては、上位の階層のパケットが、TLVパケットと呼ばれる可変長のパケットに分割されて伝送され、このTLVパケットの連続が、TLVストリームと称される。
 つまり、1つの放送チャンネルに対応する伝送帯域において伝送される信号は、全てその放送チャンネルに対応するヘッダ情報などを有するTLVパケットにより伝送されるのである。換言すれば、ARIBの規格に適合する方式のNRT放送の場合、物理チャンネル(放送チャンネル)毎にTLVストリームの伝送レートが割り当てられることになる。
 「TLV」に隣接する上位の階層として、「IP(Multicast)」、「ヘッダ圧縮IP(Multicast)」、「TLV-NIT(Network Information Table)」、および「AMT(Address Map Table)」とされている。「IP(Multicast)」は、Multicast形式のIPパケットとされる。「ヘッダ圧縮IP(Multicast)」は、IPパケットのヘッダを圧縮することによって伝送オーバーヘッドを削減するものである。例えば、全てのパケットのヘッダ情報を全て伝送する代わりに、フルヘッダのパケットを間欠的に伝送し、他のパケットでは圧縮ヘッダに付け替えて伝送し受信側でヘッダ情報を復元するプロトコルに対応するヘッダ情報が付されたIPパケットとされる。
 「TLV-NIT(Network Information Table)」、および「AMT(Address Map Table)」には、IPアドレス、ポート番号などに基づいて、TLVパケットに付与された識別子を特定するために用いられる情報が伝送される階層とされる。「TLV-NIT」、および「AMT」は、多重化されているIPパケットのマルチキャストグループの一覧など、TLVパケットの多重化の状態などが記述されている。受信装置41において、「TLV-NIT」、および「AMT」を参照することにより、TLVパケットに付与された識別子を特定し、目的のIPパケットを取り出すことができるようになされている。
 「IP(Multicast)」、「ヘッダ圧縮IP(Multicast)」に隣接する上位の階層は、「UDP」とされ、その上位階層として「データ伝送プロトコル」が表示されている。「データ伝送プロトコル」は、「ECGメタデータ」や、「TTS」が格納されるファイルを伝送するための所定のプロトコルに対応する階層とされる。このデータ伝送プロトコルに基づいて、後述するダウンロードヘッダが生成されることになる。
 「TTS(Timestamped TS)」は、符号化された画像データ、音声データなどを固定長のトランスポートパケット(TSパケット)に分割し、TSパケットの所定の位置にタイムスタンプ情報を付加したパケットが伝送される階層である。「TTS」に隣接する上位の階層として、「Video Coding(符号化された画像データ)」、「Audio Coding(符号化された音声データ)」、「字幕 Coding(符号化された字幕データ)」が記載されている。
 「ECGメタデータ」は、後述するECGメタデータを構成するデータが固定長のパケットに分割されて伝送される階層とされる。
 「TTS」階層のパケット、または「ECGメタデータ」階層のパケットに、そのパケットに格納されるファイルの識別情報、符号化方式、ブロック番号などの属性情報をダウンロードヘッダとして付加したものが、UDPパケットのペイロードとされる。
 このように、ARIBの規格に適合する方式のNRT放送である衛星ダウンロード放送においては、「TLV」のTLVパケットの伝送レートに対応する伝送帯域を有する1つの放送チャンネル(いわば物理チャンネル)を、グループと称される複数の論理チャンネルに多重化することが可能である。
 このような論理チャンネルのそれぞれに関する情報は、放送チャンネル毎に生成される論理チャンネル(グループ)に関する制御情報であるグループ属性テーブルと、ユーザの視聴契約に対応する制御情報である購入属性テーブルに記述されている。グループ属性テーブルと購入属性テーブルは、それぞれECGメタデータに含まれる情報であり、詳細については後述する。
 グループ属性テーブルと購入属性テーブルに基づいて、ダウンロードすべきプログラムが含まれるグループの識別子である「グループID」が特定され、「グループID」に基づいて、プログラムの識別子である「CRID」が特定される。そして、「CRID」に基づいて受信すべきIPパケットのIPアドレスとポート番号が特定される。さらに、「TLV-NIT」、および「AMT」を参照することにより、TLVパケットに付与された識別子が特定され、目的のIPパケットが取り出されることになる。
 なお、ECGメタデータが格納されるIPパケットには、予め定められたIPアドレスとポート番号が付与されるようになされている。ECGメタデータのIPアドレスとポート番号は、予め受信装置41に記憶されている。
 つまり、受信装置41は、予め記憶しているIPアドレスとポート番号に基づいて、「TLV-NIT」、および「AMT」を参照することにより、TLVパケットに付与された識別子を特定し、ECGメタデータのIPパケットを取り出すことができる。そのようにして得られたECGメタデータに含まれるグループ属性テーブルと購入属性テーブルに基づいて、上述のように、ダウンロードすべきプログラムが含まれるグループの識別子である「グループID」が特定されるのである。
 次にECGメタデータについて説明する。ECGメタデータには、グループ属性テーブル、プログラム属性テーブル、プログラムロケーションテーブル、購入属性テーブル、ライセンス属性テーブル、ダウンロード制御情報テーブルが含まれる。
 図34は、本発明において用いられるグループ属性テーブル(Group Information)の例を示す図である。グループ属性テーブルは、グループ毎に生成される。ARIBの規格に適合する方式のNRT放送の場合、Push型NRT放送を受信する受信装置41は、そのPush型NRT放送に対応するグループに含まれるプログラムを全て受信するようになされている。
 同図の例において、グループ属性テーブルには、「グループID」、「グループタイプ」、「グループ/プログラム数」、「親グループID」、「タイトル名」、「概要」、「ジャンル」、「キーワード」、「タイトルメディア」、・・・が記述されている。
 「グループID」は、当該グループを特定する識別子とされる。
 「グループタイプ」には、例えば、当該グループに属するプログラムの販売条件などが記述される。例えば、当該グループに属するプログラムが10回のシリーズとして放送される場合、10回分まとめて販売されるプログラムであるか、または、各回別に販売されるプログラムであるかなどを表す情報が記述される。
 また、「グループタイプ」には、当該グループに属するプログラムが、Push型NRT放送のプログラムであるか否かを表す情報が記述される。ARIBの規格に適合する方式のNRT放送の場合、Push型NRT放送とPull型NRT放送ではダウンロードの方式が異なるものではなく、ダウンロード後のデータの保存の方式が異なるものとなる。
 すなわち、ARIBの規格に適合する方式のNRT放送の場合、ダウンロードされたプログラムのデータは、「グループID」および「グループタイプ」と対応付けられて記録媒体に記録される。ARIBの規格に適合する方式のNRT放送の場合、例えば、Push型NRT放送のプログラムをダウンロードしたデータは、同一のグループに属する別のプログラムがダウンロードされたとき、上書きされるようになされている。一方、Pull型NRT放送のプログラムをダウンロードしたデータのときは、上述のような上書きはなされない。
 つまり、受信装置41が、「グループID」および「グループタイプ」に基づいて、新たにダウンロードしたプログラムのデータを上書きして記録するか否かを判定するようになされている。このようにすることで、ユーザがPush型NRT放送の視聴契約を行った場合、以後、自動的に受信装置41の記録媒体にプログラムのデータが上書きされて記録されていくようになる。
 これにより、例えば、「天気予報」のPush型NRT放送の視聴契約を行ったユーザは、常に最新の予報を視聴することができるようになる。
 「グループ/プログラム数」には、当該グループに属するグループ(子グループ)および当該グループに属するプログラムの数が記述される。
 「親グループID」には、当該グループの親グループがある場合、その親グループの「グループID」が記述される。
 「タイトル名」、「概要」、「ジャンル」、「キーワード」には、それぞれ当該グループのタイトル、概要、ジャンル、キーワードが記述される。
 「タイトルメディア」には、例えば、当該グループ属するプログラムのサムネイル画像のデータが添付される。
 グループ属性テーブルはこのように構成される。
 図35は、本発明において用いられるプログラム属性テーブル(Program Information)の例を示す図である。プログラム属性テーブルは、プログラム毎に生成される。
 同図の例において、プログラム属性テーブルには、「CRID(Contents Reference ID)」、「グループID」、「AV属性」、「タイトル名」、「概要」、「ジャンル」、「キーワード」、「タイトルメディア」、・・・が記述されている。
 「CRID」は、当該プログラムを特定する識別子とされる。
 「グループID」には、当該プログラムが属するグループの「グループID」が記述される。
 「AV属性」には、例えば、当該プログラムが字幕付きのプログラムであるか否かを表す情報などが記述される。
 「タイトル名」、「概要」、「ジャンル」、「キーワード」には、それぞれ当該プログラムのタイトル、概要、ジャンル、キーワードが記述される。
 「タイトルメディア」には、例えば、当該プログラムのサムネイル画像のデータが添付される。
 プログラム属性テーブルはこのように構成される。
 図36は、購入属性テーブル(Purchase Information)の例を示す図である。同図の例において、購入属性テーブルには、「Purchase ID」、「グループID/プログラムID」、「料金」、・・・が記述されている。購入属性テーブルは、グループもしくはプログラム(コンテンツ)の視聴契約毎に生成される。
 「Purchase ID」は、当該視聴契約を特定する識別子とされる。
 「グループID/プログラムID」には、当該視聴契約の対象となっているグループもしくはプログラムについて、その「グループID」、および「プログラムID(すなわちCRID)」が記述される。
 「料金」は、NRT放送の視聴契約に伴って支払われる料金が記述される。
 購入属性テーブルはこのように構成される。
 図37は、ライセンス属性テーブル(License Information)の例を示す図である。同図の例において、ライセンス属性テーブルには、「ライセンスID」、「CRID」、「Purchase ID」、「利用条件」・・・が記述されている。ライセンス属性テーブルは、プログラム(コンテンツ)の視聴契約毎に生成される。
 「ライセンスID」は、当該視聴契約に対応するライセンスの識別子であると同時に、例えば、暗号化されたプログラムのファイルを復号するための鍵が記憶されている記憶領域のアドレスの情報である。
 例えば、「ライセンスID」を取得した受信装置41は、そのアドレスに基づいてネットワークを介して接続される放送局のサーバなどにアクセスする。すなわち、上記のアドレスは、放送局のサーバの所定の記憶領域を特定するものであり、その記憶領域に暗号化されたプログラムのファイルを復号するための鍵が記憶されている。
 受信装置41は、例えば、放送局のサーバにアクセスする際に、「Purchase ID」および自身の識別情報などを送信してサーバの認証を受ける。認証に成功した場合、サーバからファイルを復号するための鍵を取得できるようになされている。
 「CRID」には、当該視聴契約により視聴可能となるプログラムの「CRID」が記述される。
 「Purchase ID」には、当該ライセンスに対応する視聴契約の「Purchase ID」が記述される。
 「利用条件」は、例えば、当該ライセンスによるプログラムのファイルの復号可能回数(コンテンツの再生可能回数)などを表す情報が記述される。
 ライセンス属性テーブルはこのように構成される。
 図38は、プログラムロケーションテーブル(Program Location)の例を示す図である。同図の例において、プログラムロケーションテーブルには、「CRID」、「プログラムの参照URL」、「Purchase ID」、・・・が記述されている。プログラムロケーションテーブルは、プログラム毎に生成される。
 「CRID」には、当該プログラムの「CRID」が記述される。
 「プログラムの参照URL」には、当該プログラムのダウンロード制御情報(後述)のURLが記述される。
 「Purchase ID」は、当該プログラムを対象とする視聴契約の「Purchase ID」が記述される。
 プログラムロケーションテーブルはこのように構成される。
 図39は、ダウンロード制御情報(Download Control Information)の例を示す図である。同図の例において、ダウンロード制御情報には、「CRID」、「放送スケジュール」、・・・が記述されている。ダウンロード制御情報は、プログラム毎に生成される。
 「CRID」には、当該プログラムの「CRID」が記述される。
 「放送スケジュール」には当該プログラムの放送チャンネル、放送開始時刻、放送終了時刻等が記述される。
 また、この他にも当該プログラムのファイルを伝送するパケットのIPアドレスとポート番号とがダウンロード制御情報に記述されるようになされている。
 ダウンロード制御情報はこのように構成される。
 なお、上述したグループ属性テーブル、プログラム属性テーブル、プログラムロケーションテーブル、購入属性テーブル、ライセンス属性テーブル、ダウンロード制御情報テーブルのそれぞれは、実際にはXML文として記述される。
 例えば、ECGメタデータを受信した受信装置41のユーザは、グループ属性テーブルに含まれる「タイトル名」、「概要」などを参考にして、視聴したいと思うPush型NRT放送を決める。そして、ユーザは、予め定められた手続きにより視聴契約を行って当該Push型NRT放送の視聴契約に必要となる料金を支払う。例えば、放送局のサーバには、料金を支払ったユーザの受信装置41の識別情報が、その料金の支払によって締結された視聴契約に対応する「Purchase ID」と対応付けられて記憶される。また、料金を支払ったユーザの受信装置41には、その料金の支払によって締結された視聴契約に対応する「Purchase ID」が記憶される。
 視聴契約と料金支払後に放送を受信した受信装置41は、記憶されている「Purchase ID」に基づいて、ECGメタデータに含まれる購入属性テーブル、ライセンス属性テーブル、およびプログラムロケーションテーブルを取得する。
 そして、受信装置41は、プログラムロケーションテーブルに記述されたURLに基づいて、ECGメタデータに含まれるダウンロード制御情報を取得する。受信装置41は、ダウンロード制御情報に記述された放送スケジュールを特定することで、プログラムの放送開始時刻と放送終了時刻、放送チャンネル、IPアドレス、ポート番号などを特定する。これにより、例えば、コントローラ409の内部のメモリなどに、NRT放送のプログラムのダウンロードスケジュールが記憶される。
 受信装置41は、ダウンロードスケジュールに従ってプログラムを構成するファイルをダウンロードし、「Purchase ID」に基づいて取得したライセンス属性テーブルに記述されたライセンスIDを用いて復号鍵が記憶されているアドレスを特定する。そして、受信装置41は、例えば、ネットワークを介して上述したアドレスにアクセスして復号鍵を取得し、暗号化されたファイルを復号して再生する。
 このようにして、ARIBの規格に適合する方式でPush型NRT放送を実現できるようにすることも可能である。
 次に、図40のフローチャートを参照して、受信装置41においてARIBの規格に適合する方式でNRT放送を受信する場合のNRT放送受信処理について説明する。
 ステップS201において、受信装置41は、ECGメタデータを取得する。このとき、受信装置41は、予め記憶しているIPアドレスとポート番号に基づいて、「TLV-NIT」、および「AMT」を参照することにより、TLVパケットに付与された識別子を特定する。そして、受信装置41は、特定されたTLVパケットからECGメタデータのIPパケットを取り出すことでECGメタデータを取得する。
 ステップS202において、受信装置41は、「グループID」を特定する。このとき、受信装置41は、記憶されている「Purchase ID」に基づいて、ECGメタデータに含まれる購入属性テーブル、ライセンス属性テーブル、およびプログラムロケーションテーブルを取得する。そして、購入属性テーブルに含まれる「グループID」を特定する。
 ステップS203において、受信装置41は、ステップS202の処理で特定した「グループID」に基づいてグループ属性テーブルを取得し、「グループタイプ」を特定する。
 ステップS204において、受信装置41は、ダウンロードスケジュールを生成する。このとき、ステップS202の処理に伴って取得されたプログラムロケーションテーブルに記述されたURLに基づいて、ダウンロード制御情報を取得する。受信装置41は、ダウンロード制御情報に記述された放送スケジュールを特定することで、プログラムの放送開始時刻と放送終了時刻、放送チャンネル、IPアドレス、ポート番号などを特定する。これにより、例えば、コントローラ409の内部のメモリなどに、NRT放送のプログラムのダウンロードスケジュールが記憶される。
 ステップS205において、受信装置41は、ステップS204の処理で生成されたダウンロードスケジュールに基づいて、プログラムのデータをダウンロードする。
 ステップS206において、受信装置41は、ステップS205の処理でダウンロードしたプログラムのデータと、ステップS202およびステップS203の処理で特定された「グループID」および「グループタイプ」とを対応付ける。
 ステップS207において、受信装置41は、ステップS205の処理でダウンロードしたプログラムは、Push型NRT放送のプログラムか否かを判定する。このとき、ステップS206の処理により対応付けられている「グループタイプ」に基づいて、当該プログラムがPush型NRT放送のプログラムか否かが判定される。
 ステップS207において、ステップS205の処理でダウンロードしたプログラムはPush型NRT放送のプログラムであると判定された場合、処理は、ステップS208に進む。
 ステップS208において、受信装置41は、プログラムのデータを上書きして記録する。
 一方、ステップS207において、ステップS205の処理でダウンロードしたプログラムはPush型NRT放送のプログラムではないと判定された場合、処理は、ステップS209に進む。
 ステップS209において、受信装置41は、プログラムのデータを上書きせずに記録する。
 すなわち、ステップS208またはステップS209において、ダウンロードされたプログラムのデータは、「グループID」および「グループタイプ」と対応付けられて記録媒体に記録されることになる。
 ここで、Push型NRT放送のプログラムをダウンロードしたデータは、同一のグループに属する別のプログラムがダウンロードされたとき、上書きされるようになされている(ステップS208の処理)。例えば、ステップS202の処理で特定された「グループID」と同一の「グループID」に対応づけられたプログラムのデータであって、先に記録されているプログラムのデータに、ステップS205の処理でダウンロードしたプログラムのデータが上書きされる。一方、Pull型NRT放送のプログラムをダウンロードしたデータのときは、上述のような上書きはなされない(ステップS209の処理)。
 つまり、受信装置41が、「グループID」および「グループタイプ」に基づいて、新たにダウンロードしたプログラムのデータを上書きして記録するか否かを判定するようになされている(ステップS207の処理)。このようにすることで、ユーザがPush型NRT放送の視聴契約を行った場合、以後、自動的に受信装置41の記録媒体にプログラムのデータが上書きされて記録されていくようになる。
 なお、上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。上述した一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータにネットワークや記録媒体からインストールされる。また、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば図41に示されるような汎用のパーソナルコンピュータ700などに、ネットワークや記録媒体からインストールされる。
 図41において、CPU(Central Processing Unit)701は、ROM(Read Only Memory)702に記憶されているプログラム、または記憶部708からRAM(Random Access Memory)703にロードされたプログラムに従って各種の処理を実行する。RAM703にはまた、CPU701が各種の処理を実行する上において必要なデータなども適宜記憶される。
 CPU701、ROM702、およびRAM703は、バス704を介して相互に接続されている。このバス704にはまた、入出力インタフェース705も接続されている。
 入出力インタフェース705には、キーボード、マウスなどよりなる入力部706、LCD(Liquid Crystal display)などよりなるディスプレイ、並びにスピーカなどよりなる出力部707が接続されている。また、入出力インタフェース705には、ハードディスクなどより構成される記憶部708、モデム、LANカードなどのネットワークインタフェースカードなどより構成される通信部709が接続されている。通信部709は、インターネットを含むネットワークを介しての通信処理を行う。
 入出力インタフェース705にはまた、必要に応じてドライブ710が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア711が適宜装着されている。そして、それらのリムーバブルメディアから読み出されたコンピュータプログラムが、必要に応じて記憶部708にインストールされる。
 上述した一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、インターネットなどのネットワークや、リムーバブルメディア711などからなる記録媒体からインストールされる。
 なお、この記録媒体は、図41に示される、装置本体とは別に、ユーザにプログラムを配信するために配布される、プログラムが記録されている磁気ディスク(フロッピディスク(登録商標)を含む)、光ディスク(CD-ROM(Compact Disk-Read Only Memory),DVD(Digital Versatile Disk)を含む)、光磁気ディスク(MD(Mini-Disk)(登録商標)を含む)、もしくは半導体メモリなどよりなるリムーバブルメディア711により構成されるものだけでなく、装置本体に予め組み込まれた状態でユーザに配信される、プログラムが記録されているROM702や、記憶部708に含まれるハードディスクなどで構成されるものも含む。
 なお、本明細書において上述した一連の処理は、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
 また、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。
 1 放送システム, 21 送信装置, 41 受信装置, 401 端子, 402 チューナ, 403 TSDemux, 404 ビデオデコーダ, 405 オーディオデコーダ, 406 ファイルコンテナDemux, 407 FLUTEプロセッサ,408 ストレージ, 409 コントローラ 410 端子, 411 端子

Claims (17)

  1.  放送波として送信される信号に基づいて、再生レートと同期しない伝送レートでのコンテンツの放送に関する制御情報を受信する制御情報受信手段と、
     前記制御情報に基づいて、予め設定された登録情報に対応する論理チャンネルで放送されるコンテンツを受信して記録するための予約情報であって、ダウンロードスケジュールを生成するダウンロードスケジュール生成手段と、
     前記ダウンロードスケジュールに基づいて、前記コンテンツのそれぞれを受信して記録媒体に記録するダウンロード手段と、
     前記記録媒体に記録されたコンテンツを、前記再生レートで再生する再生手段と
     を備えるコンテンツ受信装置。
  2.  前記コンテンツの放送に関する制御情報には、
     前記周波数帯域の放送波の信号の伝送路を物理チャンネルとした場合、前記物理チャンネルを所定の方式で複数の伝送路に分割することにより得られる論理チャンネルに関する情報が記述された所定の記述データと、
     前記論理チャンネルのそれぞれにおいて伝送されるコンテンツに関する情報が記述されたメタデータが含まれる
     請求項1に記載のコンテンツ受信装置。
  3.  前記ダウンロードスケジュール生成手段は、
     前記物理チャンネルに存在する複数の論理チャンネルのうち、前記登録情報に対応する前記論理チャンネルで放送される全てのコンテンツを受信して記録するためのダウンロードスケジュールを生成する
     請求項2に記載のコンテンツ受信装置。
  4.  前記ダウンロードスケジュール生成手段は、
     前記メタデータの記述に基づいて、前記コンテンツの放送開始時刻を特定するとともに、前記論理チャンネルで伝送されるデータのうち、前記コンテンツのデータを特定するためのロケーション情報を特定して前記ダウンロードスケジュールを生成する
     請求項3に記載のコンテンツ受信装置。
  5.  前記ダウンロード手段は、
     前記ダウンロードスケジュールに基づいて、
     前記コンテンツの放送開始時刻に、前記物理チャンネルに対応する周波数帯域の放送波を受信し、
     前記所定の記述データの記述に基づいて、前記物理チャンネルで伝送されるトランスポートパッケトのうち、前記登録情報に対応する論理チャンネルのトランスポートパケットを抽出し、
     前記ロケーション情報に基づいて、前記コンテンツのデータを特定することで、前記コンテンツを受信する
     請求項4に記載のコンテンツ受信装置。
  6.  前記論理チャンネルのトランスポートパケットは、IPパケットを含んで構成され、
     前記ロケーション情報には、前記IPパケットにより伝送される前記コンテンツのデータのファイル伝送セションを特定するための情報が含まれ、
     前記ダウンロード手段は、
     前記ファイル伝送セションが特定されることにより取得される伝送制御データの記述に基づいて前記コンテンツのデータを特定する
     請求項5に記載のコンテンツ受信装置。
  7.  前記ダウンロード手段は、
     前記伝送制御データの記述に基づいて、RSS形式またはATOM形式で記述されたアドレスファイルを特定し、
     前記アドレスファイルに基づいて前記コンテンツのデータを特定する
     請求項6に記載のコンテンツ受信装置。
  8.  前記所定の記述データと前記メタデータの記述に基づいて、前記論理チャンネルのうち、ユーザのリクエストによらず、視聴すべきコンテンツを受信させるPush型サービスを提供する論理チャンネルを特定し、
     前記Push型サービスを提供する論理チャンネルの一覧をユーザに提示して、前記ユーザによる前記Push型サービスの登録を受け付け、
     前記登録されたPush型サービスの論理チャンネルを特定する情報を前記登録情報として記憶する
     請求項2に記載のコンテンツ受信装置。
  9.  前記ダウンロードスケジュール生成手段は、
     前記物理チャンネルに存在する複数の論理チャンネルのうち、前記登録情報に対応する前記論理チャンネルで放送されるコンテンツであって、前記所定の記述データにより特定されるコンテンツを受信して記録するためのダウンロードスケジュールを生成する
     請求項2に記載のコンテンツ受信装置。
  10.  前記ダウンロード手段は、
     前記受信したコンテンツを、前記記録媒体に記録されているコンテンツに上書きするか否かを判定する上書き判定手段を有する
     請求項1に記載のコンテンツ受信装置。
  11.  前記ダウンロード手段により記録された前記コンテンツには、前記メタデータの記述に基づいて有効期限が設定され、
     前記有効期限が経過した前記コンテンツを削除する
     請求項1に記載のコンテンツ受信装置。
  12.  放送波として送信される信号に基づいて、再生レートと同期しない伝送レートでのコンテンツの放送に関する制御情報を受信し、
     前記制御情報に基づいて、予め設定された登録情報に対応する論理チャンネルで放送されるコンテンツを受信して記録するための予約情報であって、ダウンロードスケジュールを生成し、
     前記ダウンロードスケジュールに基づいて、前記コンテンツのそれぞれを受信して記録媒体に記録し、
     前記記録媒体に記録されたコンテンツを、前記再生レートで再生する
     ステップを含むコンテンツ受信方法。
  13.  コンピュータを、
     放送波として送信される信号に基づいて、再生レートと同期しない伝送レートでのコンテンツの放送に関する制御情報を受信する制御情報受信手段と、
     前記制御情報に基づいて、予め設定された登録情報に対応する論理チャンネルで放送されるコンテンツを受信して記録するための予約情報であって、ダウンロードスケジュールを生成するダウンロードスケジュール生成手段と、
     前記ダウンロードスケジュールに基づいて、前記コンテンツのそれぞれを受信して記録媒体に記録するダウンロード手段と、
     前記記録媒体に記録されたコンテンツを、前記再生レートで再生する再生手段と
     を備えるコンテンツ受信装置として機能させる
     プログラム。
  14.  予め作成された放送スケジュールから、再生レートと同期しない伝送レートで放送されるコンテンツに関する情報を取得するコンテンツ情報取得手段と、
     前記コンテンツが、ユーザのリクエストによらず、視聴すべきコンテンツを受信させるPush型サービスのコンテンツであるか否かを判定する判定手段と、
     前記Push型サービスのコンテンツであると判定された場合、所定の論理チャンネルで放送されるコンテンツに関する情報として生成された第1の制御情報に、前記コンテンツに関する情報とともに、前記コンテンツが前記Push型サービスのコンテンツである表す情報を記述する第1の制御情報生成手段と、
     所定の周波数帯域の放送波の信号の伝送路としての物理チャンネルにおいて、前記論理チャンネルのそれぞれを特定するための情報が記述された第2の制御情報を生成する第2の制御情報生成手段と、
     前記第1の制御情報および第2の制御情報を、前記コンテンツのデータと多重化するとともに、複数の前記論理チャンネルで放送されるデータを、1つの物理チャンネルで放送されるデータとして多重化する多重化手段と、
     前記多重化されたデータを変調して放送波として送信する放送波送信手段と
     を備えるコンテンツ送信装置。
  15.  予め作成された放送スケジュールから、再生レートと同期しない伝送レートで放送されるコンテンツに関する情報を取得し、
     前記コンテンツが、ユーザのリクエストによらず、視聴すべきコンテンツを受信させるPush型サービスのコンテンツであるか否かを判定し、
     前記Push型サービスのコンテンツであると判定された場合、所定の論理チャンネルで放送されるコンテンツに関する情報として生成された第1の制御情報に、前記コンテンツに関する情報とともに、前記コンテンツが前記Push型サービスのコンテンツである表す情報を記述し、
     所定の周波数帯域の放送波の信号の伝送路としての物理チャンネルにおいて、前記論理チャンネルのそれぞれを特定するための情報が記述された第2の制御情報を生成し、
     前記第1の制御情報および第2の制御情報を、前記コンテンツのデータと多重化するとともに、複数の前記論理チャンネルで放送されるデータを、1つの物理チャンネルで放送されるデータとして多重化し、
     前記多重化されたデータを変調して放送波として送信する
     ステップを含むコンテンツ送信方法。
  16.  コンピュータを、
     予め作成された放送スケジュールから、再生レートと同期しない伝送レートで放送されるコンテンツに関する情報を取得するコンテンツ情報取得手段と、
     前記コンテンツが、ユーザのリクエストによらず、視聴すべきコンテンツを受信させるPush型サービスのコンテンツであるか否かを判定する判定手段と、
     前記Push型サービスのコンテンツであると判定された場合、所定の論理チャンネルで放送されるコンテンツに関する情報として生成された第1の制御情報に、前記コンテンツに関する情報とともに、前記コンテンツが前記Push型サービスのコンテンツである表す情報を記述する第1の制御情報生成手段と、
     所定の周波数帯域の放送波の信号の伝送路としての物理チャンネルにおいて、前記論理チャンネルのそれぞれを特定するための情報が記述された第2の制御情報を生成する第2の制御情報生成手段と、
     前記第1の制御情報および第2の制御情報を、前記コンテンツのデータと多重化するとともに、複数の前記論理チャンネルで放送されるデータを、1つの物理チャンネルで放送されるデータとして多重化する多重化手段と、
     前記多重化されたデータを変調して放送波として送信する放送波送信手段とを備えるコンテンツ送信装置として機能させる
     プログラム。
  17.  請求項10または請求項13に記載のプログラムが記録された記録媒体。
PCT/JP2010/051370 2009-02-09 2010-02-02 コンテンツ受信装置および方法、コンテンツ送信装置および方法、プログラム、並びに記録媒体 WO2010090162A1 (ja)

Priority Applications (8)

Application Number Priority Date Filing Date Title
CN201080006450.1A CN102301734B (zh) 2009-02-09 2010-02-02 内容接收设备和方法、内容发送设备和方法
RU2011132384/07A RU2518513C2 (ru) 2009-02-09 2010-02-02 Устройство и способ приема содержания, устройство и способ передачи содержания, программа и носитель записи
BRPI1008088A BRPI1008088A2 (pt) 2009-02-09 2010-02-02 dispositivos e métodos de recepção e de transmissão de conteúdo, programa, e, meio de gravação
US13/147,459 US9584841B2 (en) 2009-02-09 2010-02-02 Contents reception device and method, contents transmission device and method, program, and recording medium
EP10738494.3A EP2395752A4 (en) 2009-02-09 2010-02-02 CONTENT RECEIVING DEVICE AND METHOD, CONTENT SENDING DEVICE AND METHOD, PROGRAM, AND STORAGE MEDIUM
KR1020117017863A KR101669604B1 (ko) 2009-02-09 2010-02-02 콘텐츠 수신 장치 및 방법
US13/888,625 US20130247124A1 (en) 2009-02-09 2013-05-07 Contents reception device and method, contents transmission device and method, program, and recording medium
US15/405,930 US10257553B2 (en) 2009-02-09 2017-01-13 Contents reception device and method, contents transmission device and method, program, and recording medium

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
JP2009-027390 2009-02-09
JP2009027390 2009-02-09
JP2009-164687 2009-07-13
JP2009164687 2009-07-13
JP2009271763A JP5541488B2 (ja) 2009-02-09 2009-11-30 コンテンツ受信装置および方法
JP2009-271763 2009-11-30

Related Child Applications (3)

Application Number Title Priority Date Filing Date
US13/147,459 A-371-Of-International US9584841B2 (en) 2009-02-09 2010-02-02 Contents reception device and method, contents transmission device and method, program, and recording medium
US13/888,625 Division US20130247124A1 (en) 2009-02-09 2013-05-07 Contents reception device and method, contents transmission device and method, program, and recording medium
US15/405,930 Continuation US10257553B2 (en) 2009-02-09 2017-01-13 Contents reception device and method, contents transmission device and method, program, and recording medium

Publications (1)

Publication Number Publication Date
WO2010090162A1 true WO2010090162A1 (ja) 2010-08-12

Family

ID=42542056

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/051370 WO2010090162A1 (ja) 2009-02-09 2010-02-02 コンテンツ受信装置および方法、コンテンツ送信装置および方法、プログラム、並びに記録媒体

Country Status (8)

Country Link
US (3) US9584841B2 (ja)
EP (1) EP2395752A4 (ja)
JP (1) JP5541488B2 (ja)
KR (1) KR101669604B1 (ja)
CN (1) CN102301734B (ja)
BR (1) BRPI1008088A2 (ja)
RU (1) RU2518513C2 (ja)
WO (1) WO2010090162A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130014202A1 (en) * 2010-03-29 2013-01-10 Jong Yeul Suh Method of processing non-real time service and broadcast receiver
WO2015137149A1 (ja) * 2014-03-14 2015-09-17 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
RU2585253C2 (ru) * 2011-04-28 2016-05-27 Сони Корпорейшн Приемное устройство и способ, передающее устройство и способ и программа

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070124395A1 (en) * 2005-09-22 2007-05-31 Stephen Edge Geography-based filtering of broadcasts
US8849183B2 (en) 2007-10-05 2014-09-30 Qualcomm Incorporated Location and time based filtering of broadcast information
US9280778B2 (en) 2008-12-15 2016-03-08 Qualcomm Incorporated Location logging and location and time based filtering
US9078031B2 (en) 2010-10-01 2015-07-07 Sony Corporation Reception apparatus, reception method, and program
US9485108B2 (en) 2011-03-14 2016-11-01 Qualcomm Incorporated System and apparatus for using multichannel file delivery over unidirectional transport (“FLUTE”) protocol for delivering different classes of files in a broadcast network
KR101713369B1 (ko) * 2011-03-15 2017-03-08 엘지전자 주식회사 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치
US9451401B2 (en) 2011-05-27 2016-09-20 Qualcomm Incorporated Application transport level location filtering of internet protocol multicast content delivery
WO2013108954A1 (ko) * 2012-01-20 2013-07-25 전자부품연구원 하이브리드 전송환경에서 스케일러블 초고해상도 비디오 서비스를 위한 프로그램 구성 정보 송수신 방법, 효율적인 스케일러 계층 정보 전송을 위한 방법 및 스케일러 계층 정보 전송을 위한 장치
MX2014008657A (es) * 2012-01-24 2014-10-06 Sony Corp Dispositivo de recepcion, metodo de recepcion, programa y sistema de procesamiento de informacion.
US9414002B2 (en) 2012-02-07 2016-08-09 Sony Corporation Receiving apparatus, receiving method, and program
US8806529B2 (en) * 2012-04-06 2014-08-12 Time Warner Cable Enterprises Llc Variability in available levels of quality of encoded content
CN103368686A (zh) * 2012-04-09 2013-10-23 联咏科技股份有限公司 用于传送及接收数据的装置和方法
US20130282870A1 (en) * 2012-04-18 2013-10-24 Sony Corporation Reception apparatus, reception method, transmission apparatus, transmission method, and program
WO2013175796A1 (ja) * 2012-05-24 2013-11-28 パナソニック株式会社 映像送信装置、映像送信方法、及び映像再生装置
US9264648B2 (en) 2012-10-09 2016-02-16 Sony Corporation Receiving device, receiving method, transmitting device, and transmitting method
CN102883188A (zh) * 2012-10-16 2013-01-16 北京千橡网景科技发展有限公司 实时下载播放mp4文件的方法和系统
US10257564B2 (en) * 2013-01-24 2019-04-09 Saturn Licensing Llc Distributed non-real-time content
US9942601B2 (en) * 2013-01-24 2018-04-10 Saturn Licensing Llc Storing non-real time content
WO2014158158A1 (en) * 2013-03-28 2014-10-02 Thomson Licensing Adaptive guide based on categorization
US9900166B2 (en) * 2013-04-12 2018-02-20 Qualcomm Incorporated Methods for delivery of flows of objects over broadcast/multicast enabled networks
WO2015035618A1 (zh) * 2013-09-13 2015-03-19 华为技术有限公司 传输数据的方法和装置
JP6382029B2 (ja) * 2013-09-20 2018-08-29 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America 送信方法、受信方法、送信装置、及び受信装置
WO2015040817A1 (ja) * 2013-09-20 2015-03-26 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 送信方法、受信方法、送信装置、及び受信装置
JP2015073245A (ja) * 2013-10-04 2015-04-16 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
CN103716076B (zh) * 2013-12-25 2017-03-01 华为技术有限公司 一种数据传输方法和设备
JP6426901B2 (ja) * 2014-03-14 2018-11-21 富士通クライアントコンピューティング株式会社 配信方法、再生装置、配信装置、転送制御プログラムおよび配信制御プログラム
JP6519586B2 (ja) * 2014-04-11 2019-05-29 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
WO2015198545A1 (ja) * 2014-06-24 2015-12-30 株式会社ソシオネクスト インタフェース装置およびそれを備えた受信装置
PT3179729T (pt) * 2014-08-07 2021-09-21 Sony Group Corp Dispositivo de transmissão, método de transmissão e dispositivo de receção
EP4254405A3 (en) * 2014-09-30 2023-12-13 Sony Group Corporation Transmitting device, transmission method, receiving device, and receiving method
EP3214845B1 (en) * 2014-10-28 2023-12-13 Sony Group Corporation Reception device, transmission device, and corresponding data processing methods
CN105900440B (zh) 2014-11-13 2020-05-29 索尼公司 接收设备、接收方法、发送设备以及发送方法
US20170272691A1 (en) * 2014-12-22 2017-09-21 Lg Electronics Inc. Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method
US10129308B2 (en) * 2015-01-08 2018-11-13 Qualcomm Incorporated Session description information for over-the-air broadcast media data
JP2017005613A (ja) * 2015-06-15 2017-01-05 ソニー株式会社 放送受信機および方法、並びにプログラム
WO2017164595A1 (ko) * 2016-03-21 2017-09-28 엘지전자(주) 방송 신호 송수신 장치 및 방법
US10812872B2 (en) 2016-06-30 2020-10-20 Sony Semiconductor Solutions Corporation Transmitting device, transmitting method, receiving device, and receiving method for providing emergency alert information
RU2658784C1 (ru) 2017-03-23 2018-06-22 Общество с ограниченной ответственностью "БУБУКА" Способ и система контроля за воспроизведением медиа-контента, включающего объекты интеллектуальных прав
FR3070566B1 (fr) * 2017-08-30 2020-09-04 Sagemcom Broadband Sas Procede de recuperation d'un fichier cible d'un logiciel d'exploitation et dispositif d'utilisation
US11606528B2 (en) * 2018-01-03 2023-03-14 Saturn Licensing Llc Advanced television systems committee (ATSC) 3.0 latency-free display of content attribute

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002077080A (ja) * 2000-06-13 2002-03-15 Matsushita Electric Ind Co Ltd 蓄積型放送サービスシステムおよび受信蓄積装置
JP2007035135A (ja) 2005-07-26 2007-02-08 Sony Corp 電子機器、記録制御方法、プログラムおよび記録媒体
WO2007050137A1 (en) * 2005-10-25 2007-05-03 Sony Ericsson Mobile Communications Ab Methods, systems and computer program products for accessing downloadable content associated with received broadcast content
WO2008117447A1 (ja) * 2007-03-27 2008-10-02 Pioneer Corporation 受信装置、受信方法、受信プログラムおよび記録媒体
JP2009027390A (ja) * 2007-07-18 2009-02-05 Sony Corp コンテンツ配信システム、配信サーバ、受信端末及びコンピュータプログラム

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6018359A (en) * 1998-04-24 2000-01-25 Massachusetts Institute Of Technology System and method for multicast video-on-demand delivery system
CA2331419C (en) * 1998-05-08 2010-02-09 Qualcomm Incorporated Apparatus and method for distribution of high quality image and audio programs to remote locations
US20010047516A1 (en) * 2000-02-01 2001-11-29 Compaq Computer Corporation System for time shifting live streamed video-audio distributed via the internet
US8261315B2 (en) * 2000-03-02 2012-09-04 Tivo Inc. Multicasting multimedia content distribution system
US7454166B2 (en) * 2003-04-25 2008-11-18 Xm Satellite Radio Inc. System and method for providing recording and playback of digital media content
EP1267572A2 (en) * 2001-06-11 2002-12-18 Canal+ Technologies Société Anonyme Improvements in the field of programme delivery
US20030028890A1 (en) * 2001-08-03 2003-02-06 Swart William D. Video and digital multimedia acquisition and delivery system and method
WO2003015394A2 (en) * 2001-08-06 2003-02-20 Digeo, Inc. System and method to provide local content and corresponding applications via carousel transmission
EP1311115A1 (en) * 2001-11-08 2003-05-14 Deutsche Thomson-Brandt Gmbh Method for recording digital video broadcast data, and digital video recorder
AU2002359882A1 (en) * 2001-12-28 2003-07-24 Pegasus Development Corporation Wideband direct-to-home broadcasting satellite communications system and method
JP2006517757A (ja) * 2003-02-12 2006-07-27 ビデオ、ネットワークス、アイピー、ホールディングス、リミテッド 放送番組を捕獲しかつ選択的に再生するためのシステム
JP4351904B2 (ja) * 2003-12-25 2009-10-28 株式会社東芝 放送受信装置
US20060037037A1 (en) * 2004-06-14 2006-02-16 Tony Miranz System and method for providing virtual video on demand
JP4806977B2 (ja) * 2005-06-21 2011-11-02 ソニー株式会社 情報処理装置および方法、並びにプログラム
JP4943416B2 (ja) * 2006-02-22 2012-05-30 株式会社Access 番組放送システム及び番組コンテンツ配信システム
JP2008148231A (ja) * 2006-12-13 2008-06-26 Sony Corp 放送受信装置とダウンロードコンテンツ取得方法
EP1968316A1 (en) 2007-03-06 2008-09-10 Nagravision S.A. Method to control the access to conditional access audio/video content
US20080271101A1 (en) * 2007-04-24 2008-10-30 Shoreline Associates X, Llc System and method for broadband digital video recording
KR101701853B1 (ko) * 2008-05-02 2017-02-02 엘지전자 주식회사 방송 신호 수신 방법 및 방송 신호 수신 장치
US8365229B2 (en) * 2008-06-09 2013-01-29 Lg Electronics Inc. Method for mapping between signaling information and announcement information and broadcast receiver
US8250619B2 (en) * 2008-06-09 2012-08-21 Lg Electronics Inc. Method of receiving a broadcasting signal and receiving system for receiving a broadcasting signal
US8422509B2 (en) * 2008-08-22 2013-04-16 Lg Electronics Inc. Method for processing a web service in an NRT service and a broadcast receiver
WO2010058964A2 (en) * 2008-11-18 2010-05-27 Lg Electronics Inc. Method for receiving a broadcast signal
US8099752B2 (en) * 2008-12-03 2012-01-17 Sony Corporation Non-real time services
CA2746186C (en) * 2008-12-09 2013-07-09 Lg Electronics Inc. Method for processing targeting descriptor in non-real-time receiver
US8161513B2 (en) * 2008-12-09 2012-04-17 Lg Electronics Inc. Method for receiving a broadcast signal and broadcast receiver

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002077080A (ja) * 2000-06-13 2002-03-15 Matsushita Electric Ind Co Ltd 蓄積型放送サービスシステムおよび受信蓄積装置
JP2007035135A (ja) 2005-07-26 2007-02-08 Sony Corp 電子機器、記録制御方法、プログラムおよび記録媒体
WO2007050137A1 (en) * 2005-10-25 2007-05-03 Sony Ericsson Mobile Communications Ab Methods, systems and computer program products for accessing downloadable content associated with received broadcast content
WO2008117447A1 (ja) * 2007-03-27 2008-10-02 Pioneer Corporation 受信装置、受信方法、受信プログラムおよび記録媒体
JP2009027390A (ja) * 2007-07-18 2009-02-05 Sony Corp コンテンツ配信システム、配信サーバ、受信端末及びコンピュータプログラム

Non-Patent Citations (1)

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

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130014202A1 (en) * 2010-03-29 2013-01-10 Jong Yeul Suh Method of processing non-real time service and broadcast receiver
US9154818B2 (en) * 2010-03-29 2015-10-06 Lg Electronics Inc. Method of processing non-real time service and broadcast receiver
RU2585253C2 (ru) * 2011-04-28 2016-05-27 Сони Корпорейшн Приемное устройство и способ, передающее устройство и способ и программа
WO2015137149A1 (ja) * 2014-03-14 2015-09-17 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
JPWO2015137149A1 (ja) * 2014-03-14 2017-04-06 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
US10536488B2 (en) 2014-03-14 2020-01-14 Saturn Licensing Llc Receiving device, reception method, transmitting device, and transmission method
US11102252B2 (en) 2014-03-14 2021-08-24 Saturn Licensing Llc Receiving device, reception method, transmitting device, and transmission method
US11575717B2 (en) 2014-03-14 2023-02-07 Saturn Licensing Llc Receiving device, reception method, transmitting device, and transmission method

Also Published As

Publication number Publication date
RU2518513C2 (ru) 2014-06-10
US9584841B2 (en) 2017-02-28
KR20110116023A (ko) 2011-10-24
US20110289542A1 (en) 2011-11-24
BRPI1008088A2 (pt) 2016-03-15
US20170264933A1 (en) 2017-09-14
CN102301734A (zh) 2011-12-28
JP2011041242A (ja) 2011-02-24
KR101669604B1 (ko) 2016-10-26
RU2011132384A (ru) 2013-02-10
US10257553B2 (en) 2019-04-09
JP5541488B2 (ja) 2014-07-09
EP2395752A4 (en) 2014-06-18
EP2395752A1 (en) 2011-12-14
US20130247124A1 (en) 2013-09-19
CN102301734B (zh) 2014-07-09

Similar Documents

Publication Publication Date Title
JP5541488B2 (ja) コンテンツ受信装置および方法
KR101814398B1 (ko) 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치
KR101689610B1 (ko) 비실시간 서비스 처리 방법 및 방송 수신기
EP1415473B1 (en) On-demand interactive magazine
CA2837638C (en) Method for transmitting and receiving broadcast service and receiving device thereof
KR20150042195A (ko) 양방향 방송 서비스를 포함하는 방송 신호 처리 방법 및 장치
KR20120099208A (ko) 프로그램 정보 처리 방법 및 방송 수신기
JP5045535B2 (ja) 受信装置及び受信方法
CA2829750C (en) Method for transmitting broadcast service, receiving method therefor, and receiving device therefor
JP3539858B2 (ja) タイムスタンプを利用する放送システムと受信端末装置
JP2008263434A (ja) テレビ装置および番組情報表示方法
KR20070043372A (ko) 홈단말에서 실시간 필터링된 방송 비디오 관리 시스템 및그 방법
JP4296631B2 (ja) 放送方法、及び受信装置
KR101094794B1 (ko) 디지털 방송 송수신 장치 및 송수신 방법.
JP2014232978A (ja) デジタル放送受信装置
JP2000201317A (ja) 受信方法、受信装置、記憶装置及び記憶媒体
KR20050080829A (ko) 디지털 방송 수신 시스템의 프로그램 정보 재생방법

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201080006450.1

Country of ref document: CN

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

Ref document number: 10738494

Country of ref document: EP

Kind code of ref document: A1

DPE2 Request for preliminary examination filed before expiration of 19th month from priority date (pct application filed from 20040101)
ENP Entry into the national phase

Ref document number: 20117017863

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2011132384

Country of ref document: RU

WWE Wipo information: entry into national phase

Ref document number: 13147459

Country of ref document: US

Ref document number: 5586/CHENP/2011

Country of ref document: IN

Ref document number: 2010738494

Country of ref document: EP

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: PI1008088

Country of ref document: BR

ENP Entry into the national phase

Ref document number: PI1008088

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20110802