JP7842286B2 - Content protection processing method - Google Patents

Description

This invention relates to a content protection processing method.

One of the extended features of digital broadcasting services is data broadcasting, which transmits digital data via broadcast waves to display various information such as weather forecasts, news, and recommended programs. Numerous television receivers capable of receiving data broadcasting are already commercially available, and many technologies related to data broadcasting reception have been published, including Patent Document 1 below.

Japanese Patent Publication No. 2001-186486

In response to recent changes in the content distribution environment, television receivers are also being asked to undergo various functional enhancements. In particular, there are many demands for the distribution of content and linked applications using broadband network environments such as the internet, and for higher resolution/higher definition video content. However, simply reusing existing television receiver functions such as data broadcasting reception, or only enhancing those functions, will not be sufficient to provide high-value-added television receivers that can meet these demands.

The objective of this invention is to realize a content protection processing method that can perform functions with higher added value.

To solve the aforementioned problems, the technology described in the claims is used.

To give one example, a content protection processing method in a broadcast receiving device that receives broadcast program content transmitted by a broadcast signal from a broadcasting station, comprising: a reception step in which the broadcast receiving device receives the broadcast signal with a tuner; a demodulation step in which the broadcast signal received in the reception step is demodulated to obtain the broadcast program content; a storage step in which the broadcast program content demodulated in the demodulation step is stored; a video output processing step in which the video of the broadcast program content stored in the storage step is output via an interface different from the tuner that receives the broadcast signal in the reception step; and the broadcast program content stored in the storage step The system includes a copy processing step of copying the program content via an interface different from the tuner that receives the broadcast signal in the reception step, and a move processing step of moving the broadcast program content stored in the storage step via an interface different from the tuner that receives the broadcast signal in the reception step, wherein when the broadcast program content is content transmitted from the broadcasting station via the broadcast signal with protection allowing a predetermined number of copies specified, the storage step encrypts the broadcast program content so that it can be copied nine times and moved once, and can be played back only by the broadcast receiving device. This method stores the broadcast program content after processing. For content transmitted from the broadcasting station via the broadcast signal with the broadcast program content protected to allow a predetermined number of copies, the content protection processing when moving the stored broadcast program content in the move processing step includes multiple different levels of content protection, such as DTCP-IP and DTCP2. The storage in the storage step can be performed via an IP interface configured with Ethernet-compatible hardware provided in the broadcast receiving device, at a storage unit located at the output of the IP interface. Even when the broadcast program content is transmitted from the broadcasting station via the broadcast signal with the broadcast program content protected to allow a predetermined number of copies, and the content stored in the storage step is subjected to multiple different levels of content protection processing, the content protection processing in the storage step for content subject to multiple different levels of content protection processing in the move processing step does not require multiple different levels of content protection processing; a common content protection processing can be performed.

By using the technology of the present invention, it is possible to realize a content protection processing method that can perform functions with higher added value.

This is a configuration diagram of a broadcast communication system including a broadcast receiving device according to Example 1. This is an explanatory diagram of the components of the encoded signal in MMT. This is a diagram illustrating the configuration of the MPU in MMT. This is a diagram illustrating the structure of an MMTP packet in MMT. This is a conceptual diagram of the protocol stack of a broadcasting system using MMT. This is a hierarchical diagram of the control information used in broadcasting systems. This is a list of tables used in the TLV-SI broadcasting system. This is a list of descriptors used in the TLV-SI broadcasting system. This is a list of messages used in the MMT-SI broadcasting system. This is a list of tables used in the MMT-SI broadcasting system. This is a list (1) of descriptors used in the MMT-SI broadcasting system. This is a list (2) of descriptors used in the MMT-SI broadcasting system. This is a list (3) of descriptors used in the MMT-SI broadcasting system. This diagram shows the relationship between the components of the broadcasting system and each table. This diagram shows the data structure of the MPT in a broadcasting system. This diagram shows the data structure of location information in a broadcasting system. This diagram shows the data structure of the MPU timestamp descriptor in a broadcasting system. This diagram shows the data structure of the MH-EIT broadcasting system. This diagram shows the data structure of an event package descriptor for a broadcasting system. This is a block diagram of the broadcast receiving device according to Example 1. This is a diagram showing the logical plane structure of the presentation function of the broadcast receiving device according to Example 1. This is a software configuration diagram of the broadcast receiving device according to Example 1. This is a block diagram of the broadcasting station server according to Example 1. This is a block diagram of the service provider server according to Example 1. This is a block diagram of a portable information terminal according to Example 1. This is a software configuration diagram of a mobile information terminal according to Example 1. This is a system configuration diagram of the clock synchronization/presentation synchronization of the broadcast receiving device according to Example 1. This diagram shows the NTP-formatted data structure of a broadcasting system. This diagram shows the data structure of the MH-TOT broadcasting system. This diagram shows the format of the JST_time parameter in the broadcasting system. This diagram shows the data structure of time information in the TMCC extended information area of a broadcasting system. This figure shows the method for calculating the current date from the MJD of a broadcast receiving device according to Example 1. This is an operation sequence diagram of the broadcast receiving device during channel scanning according to Example 1. This diagram shows the data structure of the TLV-NIT broadcasting system. This diagram shows the data structure of the satellite distribution system descriptor for a broadcasting system. This diagram shows the data structure of a service list descriptor for a broadcasting system. This diagram shows the data structure of the AMT (Automated Manual) in a broadcasting system. This is an operation sequence diagram of the broadcast receiving device according to Example 1 when selecting a channel. This is a conceptual diagram illustrating the reference of each package's MPT by the PLT in a broadcasting system. This diagram shows the data structure of a PLT in a broadcasting system. This is an external view of a remote control capable of controlling a broadcast receiving device according to Embodiment 1. This diagram shows the data structure of the remote control key descriptor for a broadcasting system. This diagram illustrates the channel selection process for a multi-channel setup. This diagram illustrates the angle selection process for multi-view compatible programs. This diagram shows the data structure of the LCT in a broadcasting system. This diagram shows the data structure of the MPU presentation area descriptor for a broadcasting system. This diagram shows the assignment of layouts to layout numbers based on LCT. This diagram shows the assignment of layouts to layout numbers based on LCT. This diagram shows the assignment of layouts to layout numbers based on LCT. This diagram shows the assignment of layouts to layout numbers based on LCT. This diagram illustrates exception handling for screen layout control based on LCT. This diagram illustrates exception handling for screen layout control based on LCT. This diagram shows the data structure of a video component descriptor in a broadcasting system. This diagram explains the meaning of the video signal aspect ratio in a video component descriptor. This diagram illustrates the aspect ratio conversion process of a broadcast receiving device according to Example 1. This diagram illustrates the aspect ratio conversion process of a broadcast receiving device according to Example 1. This is a screen display diagram of the EPG screen of the broadcast receiving device according to Example 1. This is a screen display diagram of the EPG screen of the broadcast receiving device according to Example 1. This is a screen display diagram of the EPG screen of the broadcast receiving device according to Example 1. This is a screen display diagram of the broadcast receiving device according to Example 1 when an emergency warning broadcast is displayed. This diagram shows the data structure of the content copy control descriptor for a broadcasting system. This diagram shows the meaning of the copy control information in the content copy control descriptor. This diagram shows the data structure of the content usage control descriptor for a broadcasting system. This is a block diagram of a broadcast receiving device according to Example 2. This diagram illustrates the inconsistency in the current time display when broadcasting services are switched. This diagram illustrates the operation of the selection control for the current time information reference source according to Example 2. This is an operation sequence diagram of the current time information update process according to Example 2. This is a screen display diagram of the EPG screen of the broadcast receiving device according to Example 2. This is a screen display diagram of the EPG screen of the broadcast receiving device according to Example 2. This is a diagram illustrating the content protection process according to Example 3. This is a diagram illustrating the content protection process according to Example 4.

Examples of embodiments of the present invention will be described below with reference to the drawings.

(Example 1)
[System Configuration]
Figure 1 is a system configuration diagram showing an example of a broadcast communication system including a broadcast receiving device of this embodiment. The broadcast communication system of this embodiment consists of a broadcast receiving device 100 and an antenna 100a, a broadband network such as the Internet 200 and a router device 200r and an access point 200a, a broadcasting station's radio tower 300t and a broadcasting satellite (or communication satellite) 300s, a broadcasting station server 300, a service provider server 400, other application servers 500, a mobile telephone communication server 600 and a base station 600b of the mobile telephone communication network, and a mobile information terminal 700.

The broadcast receiving device 100 receives broadcast waves transmitted from the radio tower 300t via the broadcast satellite (or communication satellite) 300s and antenna 100a. Alternatively, it may receive the broadcast waves transmitted from the radio tower 300t directly via antenna 100a without going through the broadcast satellite (or communication satellite) 300s. Furthermore, the broadcast receiving device 100 can connect to the internet 200 via the router device 200r, enabling data transmission and reception through communication with various server devices and other communication equipment on the internet 200.

The router device 200r is connected to the internet 200 via wired communication, and is also connected to the broadcast receiving device 100 via wired or wireless communication, and to the personal information terminal 700 via wireless communication. The wireless communication may use a method such as Wi-Fi (registered trademark). This allows the broadcast receiving device 100 and the personal information terminal 700 to mutually transmit and receive data via the router device 200r. Alternatively, communication between the broadcast receiving device 100 and the personal information terminal 700 may be conducted directly using methods such as Bluetooth (registered trademark) or NFC (Near Field Communication), without going through the router device 200r.

The radio tower 300t is broadcasting equipment of the broadcasting station and transmits broadcast waves containing encoded data for broadcast programs, subtitle information, other applications, general-purpose data, etc. The broadcasting satellite (or communication satellite) 300s is a relay device that receives broadcast waves transmitted from the broadcasting station's radio tower 300t, performs frequency conversion as appropriate, and then retransmits the broadcast waves to the antenna 100a connected to the broadcasting receiving device 100. The broadcasting station also includes a broadcasting station server 300. The broadcasting station server 300 stores broadcast programs (video content, etc.) and metadata such as the program title, program ID, program summary, cast information, broadcast date and time, etc., and can provide the video content and metadata to service providers based on a contract. The provision of the video content and metadata to service providers may be done through the API (Application Programming Interface) provided by the broadcasting station server 300.

The service provider server 400 is a server device provided by the service provider and is capable of providing various services linked to broadcast programs distributed by the broadcasting station. The service provider server 400 also stores, manages, and distributes video content and metadata provided by the broadcasting station server 300, as well as various content and applications linked to broadcast programs. It also has the function of searching for and providing a list of available content and applications in response to inquiries from television receivers, etc. Note that the storage, management, and distribution of the content and metadata and the storage, management, and distribution of the applications may be performed by different server devices. The broadcasting station and the service provider may be the same or different. Multiple service provider servers 400 may be provided for different services. Furthermore, the functions of the service provider server 400 may also be provided by the broadcasting station server 300.

Other application servers 500 are known server devices that store, manage, and distribute other general applications, operating programs, content, data, etc. Multiple other application servers 500 may exist on the Internet 200.

The mobile telephone communication server 600 is connected to the Internet 200, and on the other hand, it is connected to the personal information terminal 700 via the base station 600b. The mobile telephone communication server 600 manages the telephone communication (calls) and data transmission/reception of the personal information terminal 700 via the mobile telephone communication network, and enables data transmission/reception through communication between the personal information terminal 700 and various server devices and other communication equipment on the Internet 200. Communication between the base station 600b and the personal information terminal 700 may be conducted using W-CDMA (Wideband Code Division Multiple Access) (registered trademark), GSM (Global System for Mobile communications) (registered trademark), LTE (Long Term Evolution), or other communication methods.

The personal information terminal 700 shall have functions for telephone communication (calls) and data transmission/reception via a mobile telephone network, as well as wireless communication functions such as Wi-Fi (registered trademark). The personal information terminal 700 can connect to the Internet 200 via a router device 200r and an access point 200a, or via a base station 600b and a mobile telephone communication server 600 of the mobile telephone network, and can transmit and receive data through communication with various server devices and other communication devices on the Internet 200. The access point 200a is connected to the Internet 200 by wired communication and to the personal information terminal 700 by wireless communication. The wireless communication may use a method such as Wi-Fi (registered trademark). Furthermore, communication between the personal information terminal 700 and the broadcast receiving device 100 may be conducted via the access point 200a and the Internet 200 and the router device 200r, or via the base station 600b, the mobile telephone communication server 600 and the Internet 200 and the router device 200r.

[Overview of the MMT method]
The broadcast receiving device 100 shown in Figure 1 is a television receiver that supports MMT (MPEG Media Transport) as a media transport method for transmitting video, audio, and other data, instead of TS (Transport Stream) (hereinafter referred to as MPEG2-TS), which is defined in the MPEG (Moving Picture Experts Group)-2 system that is widely used in conventional digital broadcasting systems. A television receiver that supports both MPEG2-TS and MMT is also acceptable.

MPEG-2-TS is characterized by multiplexing video, audio, and other components that make up a program into a single stream, along with control signals and a clock signal. Because it treats everything, including the clock signal, as a single stream, it is suitable for transmitting a single piece of content over a single transmission path with guaranteed transmission quality, and has been adopted in many conventional digital broadcasting systems. However, due to the limitations of MPEG-2-TS in the face of recent environmental changes related to content distribution, such as the diversification of content, the devices that utilize content, the transmission paths for content distribution, and the content storage environments, MMT (Media Manual Transmission) was newly developed.

Figure 2A shows an example of the encoded signal in the MMT of this embodiment. As shown in the figure, the MMT of this embodiment has, as elements constituting the encoded signal, an MFU (Media Fragment Unit), an MPU (Media Processing Unit), an MMTP (MMT Protocol) payload, and an MMTP packet.

An MFU (Media Function Unit) is a transmission format for video, audio, etc., and may be composed of NAL (Network Abstraction Layer) units or access units. An MPU (Media Processing Unit) includes one or more access units and is capable of performing video and audio decoding on its own. An MPU may consist of MPU metadata containing information about the overall MPU configuration, movie fragment metadata containing information about the encoded media data, and sample data which is the encoded media data. Multiple movie fragment data and sample data sets may exist within a single MPU. Furthermore, it is possible to extract an MFU from the sample data. Figure 2B shows an example of an MPU configuration. By assigning a sequence number to each MPU belonging to the same asset, any MPU can be distinguished from other MPUs using the asset ID (which identifies the asset) and the MPU sequence number. In the case of media such as video and audio components, presentation and decoding times may be specified on an MPU or access unit basis.

An MMTP packet consists of a header and an MMTP payload, and transmits control information for the MFU and MMT. The MMTP payload shall have a payload header corresponding to the contents (data units) stored in the payload. Figure 2C shows an example of the overview from configuring an MFU from video/audio signals to storing it in the MMTP payload and then configuring an MMTP packet. In the case of video signals encoded using inter-frame prediction, it is desirable to configure the MPU in units of GOP (Group Of Pictures). Also, if the size of the MFU to be transmitted is small, one MFU may be stored in one payload, or multiple MFUs of the same type may be stored in one payload. Also, if the size of the MFU to be transmitted is large, one MFU may be divided and stored in multiple payloads. Furthermore, MMTP packets may be protected using technologies such as AL-FEC (Application Layer Forward Error Correction) and ARQ (Automatic Repeat Request) to recover packet loss during transmission.

In the broadcast system of this embodiment, MPEG-H HEVC (High Efficiency Video Coding) is used as the video encoding method, and MPEG-4 AAC (Advanced Audio Coding) or MPEG-4 ALS (Audio Lossless Coding) is used as the audio encoding method. The encoded data of video and audio of the broadcast program, encoded using the above methods, shall be in MFU or MPU format, further packaged in an MMTP payload and transmitted as an IP (Internet Protocol) packet. Data content related to the broadcast program may also be in MFU or MPU format, further packaged in an MMTP payload and transmitted as an IP packet. Four types of data content transmission methods will be provided: (1) a subtitle/text overlay transmission method used for streaming data synchronized with broadcasts; (2) an application transmission method used for data transmission services asynchronous with broadcasts; (3) an event message transmission method used for synchronous/asynchronous message notifications from broadcasting stations to applications running on television receivers; and (4) a general-purpose data transmission method for transmitting other general-purpose data synchronously/asynchronously.

For MMTP packet transmission, UDP/IP (User Datagram Protocol/Internet Protocol) is used on broadcast transmission lines, and UDP/IP or TCP/IP (Transmission Control Protocol/Internet Protocol) is used on communication lines. Furthermore, in broadcast transmission lines, TLV (Type Length Value) multiplexing is used for efficient transmission of IP packets. An example of the protocol stack of the broadcast system in this embodiment is shown in Figure 3. In the figure, (A) is an example of the protocol stack on the broadcast transmission line, and (B) is an example of the protocol stack on the communication line.

In this embodiment of the broadcasting system, a mechanism is provided for transmitting two types of control information: MMT-SI (MMT-Signaling Information) and TLV-SI (TLV-Signaling Information). MMT-SI is control information indicating the structure of broadcast programs, etc. It is in the format of an MMT control message, loaded into an MMTP payload, and transmitted as an IP packet. TLV-SI is control information related to IP packet multiplexing, providing information for channel selection and information on the correspondence between IP addresses and services.

Furthermore, in broadcast systems using MMT, time information will be transmitted to provide absolute time. While MPEG2-TS displayed component display times based on different clocks for each TS, MMT displays component display times based on Coordinated Universal Time (UTC). These mechanisms enable terminal devices to synchronously display components transmitted from different transmission points via different transmission paths. To provide UTC, IP packets in NTP (Network Time Protocol) format will be used.

[Control information for broadcasting systems using MMT]
In the broadcasting system to which the broadcasting receiver 100 of this embodiment corresponds, as described above, control information is provided, including TLV-SI related to the TLV multiplexing method for IP packet multiplexing and MMT-SI related to the MMT media transport method. TLV-SI provides information for the broadcasting receiver 100 to demultiplex the IP packets multiplexed on the broadcasting transmission path. TLV-SI consists of a "table" and a "descriptor". The "table" is transmitted in section format, and the "descriptor" is placed within the "table". MMT-SI is transmission control information that shows the configuration of the MMT package and information related to broadcasting services. MMT-SI consists of three layers: a "message" that stores the "table" and "descriptor", a "table" that has elements and attributes that show specific information, and a "descriptor" that shows more detailed information. An example of the hierarchical structure of control information used in the broadcasting system of this embodiment is shown in Figure 4.

<Tables used in TLV-SI>
Figure 5A shows a list of "tables" used in the TLV-SI of the broadcasting system to which the broadcasting receiving device 100 of this embodiment corresponds. In this embodiment, the following "tables" of the TLV-SI are to be used.

(1) TLV-NIT
The Network Information Table for TLV (TLV-NIT) represents information about the physical configuration of TLV streams transmitted over the network, as well as the characteristics of the network itself.

(2) AMT
An Address Map Table (AMT) provides a list of multicast groups for IP packets that constitute each service transmitted on a network.

(3) Tables set by the service provider Other service providers may prepare tables that they set up on their own.

<Descriptors used in TLV-SI>
Figure 5B shows a list of 'descriptors' placed in the TLV-SI of the broadcasting system to which the broadcasting receiving device 100 of this embodiment corresponds. In this embodiment, the following 'descriptors' of the TLV-SI are to be used.

(1) Service list descriptor A service list descriptor provides a list of services by service identifier and service type.

(2) Satellite distribution system descriptor The satellite distribution system descriptor indicates the physical conditions of the satellite transmission path.

(3) System administration descriptors System administration descriptors are used to distinguish between broadcast and non-broadcast content.

(4) Network name descriptor The network name descriptor describes the network name using character codes.

(5) Remote control key descriptor The remote control key descriptor is used to configure the service to be assigned to the one-touch tuning button on the receiver's remote control.

(6) Descriptors set by service providers Other service providers may prepare their own descriptors.

<Messages used in MMT-SI>
Figure 6A shows a list of "messages" used in the MMT-SI broadcasting system to which the broadcast receiving device 100 of this embodiment corresponds. In this embodiment, the following are assumed to be used as "messages" of the MMT-SI.

(1) PA messages Package Access (PA) messages are used to transmit various tables.

(2) M2 Section Messages M2 section messages are used to transmit the section extension format of MPEG-2 Systems.

(3) CA message CA messages are used to transmit a table for identifying the restricted access method.

(4) M2 Short Section Messages M2 short section messages are used to transmit the section short format of MPEG-2 Systems.

(5) Data transmission messages A data transmission message is a message that stores a table related to data transmission.

(6) Messages set by the service provider In addition, service providers can prepare messages that they set independently.

<Tables used in MMT-SI>
Figure 6B shows a list of "tables" used in the MMT-SI of the broadcasting system to which the broadcast receiving device 100 of this embodiment corresponds. A table is control information that has elements and attributes indicating specific information, and is stored in a message and transmitted in an MMTP packet. The message in which the table is stored may be determined according to the table. In this embodiment, the following are used as the "tables" of the MMT-SI.

(1) MPT
The MMT Package Table (MPT) provides information that constitutes a package, such as a list of assets and the network location of those assets. The MPT may be stored in the PA message.

(2) PLT
The Package List Table (PLT) lists the IP data flows and packet IDs that transmit PA messages for MMT packages provided as broadcast services, as well as the IP data flows that transmit IP services. The PLT may be stored in the PA message.

(3) LCT
The Layout Configuration Table (LCT) is used to associate layout information for presentation with layout numbers. The LCT may be stored in the PA message.

(4) ECM
An Entitlement Control Message (ECM) is common information consisting of program information and control information, and it delivers key information for descrambling, etc. The ECM may be stored in an M2 section message.

(5) EMM
An Entitlement Management Message (EMM) transmits individual information, including contract information for each subscriber and key information for decrypting the ECM (Common Information). The EMM may be stored in an M2 section message.

(6) CAT(MH)
The CA table (Conditional Access Table: CAT) (MH) is used to store descriptors for identifying the restricted access scheme. The CAT (MH) may be stored in the CA message.

(7) DCM
The Download Control Message (DCM) transmits key-related information, including a key for decrypting the transmission channel encryption used for downloading. The DCM may be stored in an M2 section message.

(8) DMM
The Download Management Message (DMM) transmits key-related information, including the download key used to decrypt the DCM. The DMM may be stored in an M2 section message.

(9) MH-EIT
The MH-Event Information Table (MH-EIT) contains time-series information about events included in each service. The MH-EIT may be stored in an M2 section message.

(10) MH-AIT
The MH-Application Information Table (MH-AIT) stores all information about the application and the startup status required for the application. The MH-AIT may be stored in an M2 section message.

(11) MH-BIT
The MH-Broadcaster Information Table (MH-BIT) is used to display information about broadcasters present on the network. The MH-BIT may be stored in an M2 section message.

(12) MH-SDTT
The MH-Software Download Trigger Table (MH-SDTT) is used for download notification information. The MH-SDTT may be stored in the M2 section message.

(13) MH-SDT
The MH-Service Description Table (MH-SDT) has subtables representing services included in a specific TLV stream and transmits information about the programming channel, such as the channel name and the broadcaster's name. The MH-SDT may be stored in an M2 section message.

(14) MH-TOT
The MH-Time Offset Table (MH-TOT) transmits JST time and date (modified Julian day) information. The MH-TOT may be stored in an M2 short-section message.

(15) MH-CDT
The MH-Common Data Table (MH-CDT) is used to transmit common data to be stored in non-volatile memory in section format to all receivers that receive it. The MH-CDT may be stored in an M2 section message.

(16) DDM Table The Data Directory Management Table (DDM table) provides the directory structure of files that make up the application in order to separate the application's file structure from the structure for file transmission. The DDM table may be stored in the data transmission message.

(17) DAM Table The Data Asset Management Table (DAM table) provides the configuration of the MPU within the asset and version information for each MPU. The DAM table may be stored in the data transmission message.

(18) DCC Table The Data Content Configuration Table (DCC table) provides configuration information for files as data content in order to enable flexible and effective cache control. The DCC table may be stored in the data transmission message.

(19) EMT
The Event Message Table (EMT) is used to transmit information about event messages. The EMT may be stored in an M2 section message.

(20) Tables set by the service provider Other service providers may prepare tables that they set up on their own.

<Descriptors used in MMT-SI>
Figures 6C, 6D, and 6E show a list of 'descriptors' placed in the MMT-SI of the broadcasting system to which the broadcasting receiver 100 of this embodiment corresponds. Descriptors are control information that provides more detailed information and are placed in tables. The table in which the descriptors are placed may be determined according to the descriptor. In this embodiment, the following are used as 'descriptors' of the MMT-SI.

(1) Asset Group Descriptor An asset group descriptor provides the group relationships of assets and the priority within the group. Asset group descriptors may be placed in the MPT.

(2) Event Package Descriptor An event package descriptor provides a correspondence between events and packages that represent a program. The event package descriptor may be placed in the MH-EIT transmitted in the M2 section message.

(3) Background color descriptor The background color descriptor provides the background color for the backmost element in the layout specification. The background color descriptor may be placed in the LCT.

(4) MPU presentation area descriptor The MPU presentation area descriptor provides a location for presenting the MPU. The MPU presentation area descriptor may be placed in the MPT.

(5) MPU Timestamp Descriptor The MPU timestamp descriptor indicates the presentation time of the first access unit in the presentation order in the MPU. The MPU timestamp descriptor may be placed in the MPT.

(6) Dependency Descriptors Dependency descriptors provide the asset IDs of the dependent assets. Dependency descriptors may be placed in the MPT.

(7) Access control descriptors The access control descriptors provide information for identifying the restricted access scheme. The access control descriptors may be located in the MPT or CAT(MH).

(8) Scrambling scheme descriptor The scrambling scheme descriptor provides information for identifying the type of encryption target and encryption algorithm used during scrambling. The scrambling scheme descriptor may be placed in the MPT or CAT(MH).

(9) Message Authentication Method Descriptor The message authentication method descriptor provides information for identifying the message authentication method when performing message authentication. The message authentication method descriptor may be placed in the MPT or CAT (MH).

(10) Emergency Information Descriptor (MH)
The Emergency Information Descriptor (MH) is used when broadcasting an emergency warning. The Emergency Information Descriptor (MH) may be placed in the MPT.

(11) MH-MPEG-4 Audio Descriptor The MH-MPEG-4 audio descriptor is used to describe basic information for identifying the encoding parameters of an audio stream according to ISO/IEC 14496-3 (MPEG-4 audio). The MH-MPEG-4 audio descriptor may be placed in the MPT.

(12) MH-MPEG-4 Audio Extension Descriptor The MH-MPEG-4 Audio Extension Descriptor is used to describe the profile and level of an MPEG-4 audio stream and encoding scheme-specific settings. The MH-MPEG-4 Audio Extension Descriptor may be placed in the MPT.

(13) MH-HEVC video descriptor The MH-HEVC video descriptor is used to describe the basic encoding parameters of a video stream (HEVC stream) as defined in ITU-T Recommendation H.265 | ISO/IEC 23008-2. The MH-HEVC video descriptor may be placed in the MPT.

(14) MH-Link Descriptor The MH-Link descriptor identifies a service that is provided when a viewer requests additional information related to a specific item listed in the program scheduling information system. The MH-Link descriptor may be placed in the MPT, MH-EIT, MH-SDT, etc.

(15) MH-Event Group Descriptor The MH-Event Group Descriptor is used to indicate that a group of events is grouped together when there is a relationship between multiple events. The MH-Event Group Descriptor may be placed in MH-EIT.

(16) MH-Service List Descriptor The MH-Service List Descriptor provides a list of services by service identification and service type. The MH-Service List Descriptor may be placed in the MH-BIT.

(17) MH-Short Event Descriptor An MH-Short Event Descriptor represents the event name and a short description of the event in text format. MH-Short Event Descriptors may be placed in MH-EIT.

(18) MH-Extended Event Descriptor The MH-Extended Event Descriptor is used in addition to the MH-Short Event Descriptor to provide a detailed description of the event. The MH-Extended Event Descriptor may be placed in MH-EIT.

(19) Video Component Descriptor A video component descriptor indicates parameters and descriptions related to a video component and is also used to represent the elementary stream in text format. The video component descriptor may be placed in the MPT or MH-EIT.

(20) MH-Stream Identifier Descriptor The MH-Stream Identifier Descriptor is used to label the component streams of a service, and to reference the description content indicated in the video component descriptor within the MH-EIT by this label. The MH-Stream Identifier Descriptor may be placed in the MPT.

(21) MH-Content descriptor The MH-Content descriptor indicates the genre of the event. The MH-Content descriptor may be placed in MH-EIT.

(22) MH-Parental Rate Descriptor The MH-Parental Rate Descriptor represents age-based viewing restrictions and is used to extend them to other restriction conditions. The MH-Parental Rate Descriptor may be placed in the MPT or MH-EIT.

(23) MH-Voice Component Descriptor The MH-Voice Component Descriptor specifies each parameter of the voice elementary stream and is also used to represent the elementary stream in character format. The MH-Voice Component Descriptor may be placed in the MPT or MH-EIT.

(24) MH-Target Area Descriptor The MH-Target Area Descriptor is used to describe the region targeted by a program or a portion of the streams that make up a program. The MH-Target Area Descriptor may be placed in the MPT.

(25) MH-series descriptor The MH-series descriptor is used to identify a series program. The MH-series descriptor may be placed in the MH-EIT.

(26) MH-SI transmission parameter descriptor The MH-SI transmission parameter descriptor is used to indicate the transmission parameters of the SI. The MH-SI transmission parameter descriptor may be placed in the MH-BIT.

(27) MH-Broadcaster Name Descriptor The MH-Broadcaster Name Descriptor describes the name of the broadcaster. The MH-Broadcaster Name Descriptor may be placed in the MH-BIT.

(28) MH-Service Descriptor The MH-Service Descriptor represents the programming channel name and the operator name along with the service type using character codes. The MH-Service Descriptor may be placed in the MH-SDT.

(29) IP data flow descriptors IP data flow descriptors provide information about the IP data flows that constitute the service. IP data flow descriptors may be placed in the MH-SDT.

(30) MH-CA Startup Descriptor The MH-CA Startup Descriptor contains startup information for starting the CAS program on the CAS board. The MH-CA Startup Descriptor may be placed in MPT or CAT (CA).

(31) MH-Type Descriptor The MH-Type descriptor indicates the type of file transmitted by the application transmission method. The MH-Type descriptor may be placed in the DAM table.

(32) MH-Info Descriptor The MH-Info descriptor describes information about an MPU or item. The MH-Info descriptor may be placed in the DAM table.

(33) MH-Expire Descriptor The MH-Expire descriptor describes the expiration date of an item. The MH-Expire descriptor may be placed in the DAM table.

(34) MH-Compression Type Descriptor The MH-Compression Type Descriptor indicates that the item to be transmitted is compressed, and shows the compression algorithm and the number of bytes of the item before compression. The MH-Compression Type Descriptor may be placed in the DAM table.

(35) MH-Data Encoding Scheme Descriptor The MH-Data Encoding Scheme Descriptor is used to identify the data encoding scheme. The MH-Data Encoding Scheme Descriptor may be placed in the MPT.

(36) UTC-NPT reference descriptors UTC-NPT reference descriptors are used to communicate the relationship between NPT (Normal Play Time) and UTC. UTC-NPT reference descriptors may be placed in the EMT.

(37) Event message descriptors Event message descriptors convey information about event messages in general. Event message descriptors may be placed in the EMT.

(38) MH-Local Time Offset Descriptor The MH-Local Time Offset Descriptor is used to introduce a certain offset value between the actual time (e.g., UTC+9 hours) and the time displayed to human systems when daylight saving time is in effect. The MH-Local Time Offset Descriptor may be placed in MH-TOT.

(39) MH-Component Group Descriptor The MH-Component Group Descriptor defines and identifies combinations of components within an event. The MH-Component Group Descriptor may be placed in MH-EIT.

(40) MH-Logo Transmission Descriptor The MH-Logo Transmission Descriptor is used to describe a string for a simplified logo, pointing to a logo in CDT format, etc. The MH-Logo Transmission Descriptor may be placed in the MH-SDT.

(41) MPU Extended Timestamp Descriptor The MPU extended timestamp descriptor provides the decryption time of an access unit within the MPU. The MPU extended timestamp descriptor may be located in the MPT.

(42) MPU Download Content Descriptor The MPU Download Content Descriptor is used to describe the attribute information of content downloaded using the MPU. The MPU Download Content Descriptor may be placed in MH-SDTT.

(43) MH-Network Download Content Descriptor The MH-Network Download Content Descriptor is used to describe attribute information of content downloaded using the network. The MH-Network Download Content Descriptor may be placed in MH-SDTT.

(44) MH-Application Descriptor The MH-Application Descriptor describes information about the application. The MH-Application Descriptor may be placed in MH-AIT.

(45) MH-Transmission Protocol Descriptor The MH-Transmission Protocol Descriptor is used to specify a transmission protocol such as broadcasting or communications and to indicate location information for applications that depend on the transmission protocol. The MH-Transmission Protocol Descriptor may be placed in MH-AIT.

(46) MH-Simplified Application Location Descriptor The MH-Simplified Application Location Descriptor is written to specify the details of where to retrieve the application. The MH-Simplified Application Location Descriptor may be placed in MH-AIT.

(47) MH-Application Boundary Authority Setting Descriptor The MH-Application Boundary Authority Setting Descriptor is written to set application boundaries and to set permissions for accessing broadcast resources for each region (URL). The MH-Application Boundary Authority Setting Descriptor may be placed in MH-AIT.

(48) MH-Startup Priority Information Descriptor The MH-Startup Priority Information Descriptor is written to specify the startup priority of an application. The MH-Startup Priority Information Descriptor may be placed in MH-AIT.

(49) MH-Cache Information Descriptor The MH-Cache Information Descriptor is written for use in cache control when the resources constituting the application are cached and retained when the reuse of the application is expected. The MH-Cache Information Descriptor may be placed in MH-AIT.

(50) MH-Probabilistic Application Delay Descriptor The MH-Probabilistic Application Delay Descriptor is written to delay the timing of application control by a probabilistically set delay amount, assuming load balancing of server access for application acquisition. The MH-Probabilistic Application Delay Descriptor may be placed in MH-AIT.

(51) Linked PU Descriptor A linked PU descriptor describes other presentation units that may be accessed from the presentation unit (PU) in question. Linked PU descriptors may be placed in the DCC table.

(52) Lock cache specification descriptor The lock cache specification descriptor specifies the files to be cached and locked in the presentation unit. The lock cache specification descriptor may be placed in the DCC table.

(53) Unlock cache specification descriptor The unlock cache specification descriptor specifies which files to unlock from among the files locked in the presentation unit. The unlock cache specification descriptor may be placed in the DCC table.

(54) MH-Download Protection Descriptor The MH-Download Protection Descriptor describes the location information and transmission information of MMTP packets that transmit DCM or DMM. The MH-Download Protection Descriptor may be placed in the MPT or MH-SDTT.

(55) Application service descriptor An application service descriptor describes application entry information, etc., related to a service. Application service descriptors may be placed in the MPT.

(56) MPU node descriptor An MPU node descriptor indicates that the MPU corresponds to a directory node defined in the data directory management table. The MPU node descriptor may be placed in the DAM table.

(57) PU configuration descriptor The PU configuration descriptor indicates a list of MPUs that constitute the presentation unit as mapping information between the presentation unit and the transmission unit. The PU configuration descriptor may be placed in the DCC table.

(58) MH-Hierarchical Encoding Descriptor The MH-Hierarchical Encoding Descriptor describes information for identifying the hierarchically encoded video stream component. The MH-Hierarchical Encoding Descriptor may be placed in the MPT.

(59) Content Copy Control Descriptor The content copy control descriptor provides information that controls the copy generation in the digital recording equipment for the entire service, and is used by the broadcaster (copyright holder) to communicate copy information or the maximum transmission rate to the digital recording equipment when digital recording is expected to take place. The content copy control descriptor may be placed in the MPT, MH-EIT, MH-SDT, etc.

(60) Content Usage Control Descriptor The content usage control descriptor is used to indicate information regarding copy control and remote viewing control when storing a program on a hard disk or outputting video/audio signals from a receiver. The content usage control descriptor may be placed in the MPT, MH-EIT, MH-SDT, etc.

(61) Descriptors set by service providers Other service providers may prepare descriptors that they set independently.

<Relationship between data transmission and control information in the MMT system>
Here, using Figure 7A, the relationship between each component such as video and audio transmitted by the broadcasting system to which the broadcast receiving device 100 of this embodiment corresponds, and a typical table of MMT-SI will be explained. In the MMT method, components are defined as assets, and therefore, components may be referred to as assets below.

In the broadcasting system to which the broadcast receiving device 100 of this embodiment corresponds, data transmission can be performed via multiple paths, such as TLV streams via broadcast transmission lines and IP data flows via communication lines. The TLV stream includes TLV-SIs such as TLV-NIT and AMT, and IP data flows, which are data flows of IP packets. Within the IP data flow, there are video assets including a series of video MPUs and audio assets including a series of audio MPUs. Similarly, the IP data flow may also include subtitle assets including a series of subtitle MPUs, character superimposition assets including a series of character superimposition MPUs, and data assets including a series of data MPUs.

These various assets are associated with a "package" through a description in the MPT (MMT Package Table) stored and transmitted in the PA message. Specifically, this association is achieved by describing a package ID that identifies the package and an asset ID that identifies each asset contained within that package in the MPT. Figure 7B shows an example of the MPT data structure. In the figure, the 'MMT_package_id_byte' parameter corresponds to the package ID, and the 'asset_id_byte' parameter corresponds to the asset ID.

The assets constituting a package can consist only of assets within a TLV stream, but as shown in Figure 7A, assets transmitted via IP data flow over a communication line can also be included. This can be achieved by describing the location information of each asset, along with an asset ID that identifies each asset included in the package, within the MPT, allowing the broadcast receiving device 100 in this embodiment to understand the reference location of each asset. The location information is specified by `MMT_general_location_info()` in the MPT data structure shown in Figure 7B. Figure 7C shows an example of the location information data structure.

Furthermore, depending on the value of the 'location_type' parameter in the aforementioned location information,
(1) Data multiplexed on the same IP data flow as MPT (location_type=0x00)
(2) Data multiplexed in IPv4 dataflow (location_type=0x01)
(3) Data multiplexed in IPv6 dataflow (location_type=0x02)
(4) Data multiplexed into the broadcast MPEG2-TS (location_type=0x03)
(5) Data multiplexed in MPEG2-TS format within the IP data flow (location_type=0x04)
(6) Data located at the specified URL (location_type=0x05)
This makes it possible to configure the broadcast receiving device 100 so that it can access various types of data transmitted through various transmission paths.

Of the aforementioned references, (1) is, for example, the IP data flow included in the TLV stream of the digital broadcast signal received by the broadcast receiving device 100 of this embodiment via the antenna 100a. However, if the MPT is also transmitted along with the IP data flow on the communication line side, the reference in (1) may be the IP data flow received via the communication line. Furthermore, (2), (3), (5), and (6) are IP data flows received by the broadcast receiving device 100 of this embodiment via the communication line. Also, (4) can be used, for example, in the case of a broadcast receiving device having both a receiving function for receiving digital broadcast signals using the MMT method and a receiving function for receiving digital broadcast signals using the MPEG2-TS method, such as the broadcast receiving device 800 of Embodiment 2 described later, when referencing data multiplexed in the MPEG2-TS received by the receiving function for receiving digital broadcast signals using the MPEG2-TS method, based on the location information of the MPT included in the digital broadcast signal using the MMT method.

Furthermore, for media such as video and audio components, presentation and decoding times can be specified on an MPU or access unit basis. Information regarding the presentation and decoding times is described in the MPT as an MPU timestamp descriptor or an MPU extended timestamp descriptor. Figure 7D shows an example of the data structure of an MPU timestamp descriptor that describes the presentation time information. The presentation time information for each MPU is specified by the 'mpu_presentation_time' parameter of the MPU timestamp descriptor. The MPU targeted by this specification can be identified by the 'mpu_sequence_number' parameter. In the broadcast receiving device 100 of this embodiment, using this presentation time information, it is possible to synchronize the presentation (display, output, etc.) of multiple MPUs specified by the MPT, based on an NTP-based clock, which is time information in UTC notation. Similarly, information regarding the decoding time is also described by an MPU extended timestamp descriptor, but a detailed explanation is omitted. The control of various data presentations using the NTP-based clock will be described later.

In the broadcasting system of this embodiment, a series of data in the form of a "package" corresponds to a "service" of digital broadcasting. Furthermore, the "service" is a sequence of "programs" transmitted according to a schedule. In the MMT system, these "programs" are treated as "events." Each event is specified by the MH-EIT, with a start time and duration. The event package descriptor placed in the MH-EIT specifies the ID of the MMT package corresponding to each event. Figure 7E shows an example of the data structure of the MH-EIT. The "start_time" parameter in the figure specifies the start time, and the "duration" parameter specifies the duration. Figure 7F shows an example of the data structure of an event package descriptor. The "MMT_package_id_byte" parameter of the event package descriptor placed in the MH-EIT allows the correspondence between each event and an MMT package to be specified. MH-EIT can be used in the broadcast receiving device 100 of this embodiment for various processing on an "event" basis (for example, electronic program guide generation, control of recording and viewing reservations, and copyright management processing such as temporary storage).

[Hardware configuration of broadcast receiving equipment]
Figure 8A is a block diagram showing an example of the internal configuration of the broadcast receiving device 100. The broadcast receiving device 100 consists of a main control unit 101, a system bus 102, a ROM 103, a RAM 104, a storage unit 110, a LAN communication unit 121, an expansion interface unit 124, a digital interface unit 125, a tuner/demodulation unit 131, a separation unit 132, a video decoder 141, a video color gamut conversion unit 142, an audio decoder 143, a character super decoder 144, a subtitle decoder 145, a subtitle synthesis unit 146, a subtitle color gamut conversion unit 147, a data decoder 151, a cache unit 152, an application control unit 153, a browser unit 154, an application color gamut conversion unit 155, a sound source unit 156, a video synthesis unit 161, a monitor unit 162, a video output unit 163, an audio synthesis unit 164, a speaker unit 165, an audio output unit 166, and an operation input unit 170.

The main control unit 101 is a microprocessor unit that controls the entire broadcast receiving device 100 according to a predetermined operating program. The system bus 102 is a data communication path for transmitting and receiving data between the main control unit 101 and each operating block within the broadcast receiving device 100.

The ROM (Read Only Memory) 103 is a non-volatile memory that stores basic operating programs such as the operating system and other operational programs. For example, a rewritable ROM such as an EEPROM (Electrically Erasable Programmable ROM) or flash ROM may be used. The ROM 103 may also store operational setting values necessary for the operation of the broadcast receiving device 100. The RAM (Random Access Memory) 104 serves as the work area during the execution of basic operating programs and other operational programs. The ROM 103 and RAM 104 may be integrated with the main control unit 101. Furthermore, the ROM 103 may not have an independent configuration as shown in Figure 8A, but may utilize a portion of the storage area within the storage unit 110.

The storage unit 110 stores the operating program and settings of the broadcast receiving device 100, as well as the user's personal information. It can also store operating programs downloaded via the Internet 200 and various data created by those operating programs. Furthermore, it can store content such as video, still images, and audio acquired from broadcast waves or downloaded via the Internet 200. A portion of the storage unit 110 may replace all or part of the functions of the ROM 103. The storage unit 110 also needs to retain the stored information even when the broadcast receiving device 100 is not receiving external power. Therefore, devices such as flash ROM, SSD (Solid State Drive) or other non-volatile semiconductor memory, or HDD (Hard Disk Drive) or other magnetic disk drives are used.

Furthermore, the aforementioned operating programs stored in ROM 103 and storage unit 110 can be added, updated, and have their functions expanded through download processing from various server devices on the Internet 200.

The LAN (Local Area Network) communication unit 121 is connected to the Internet 200 via the router device 200r and transmits and receives data with various server devices and other communication devices on the Internet 200. It also acquires the MMT data sequence (or a portion thereof) of the program transmitted via the communication line. The connection to the router device 200r may be a wired connection or a wireless connection such as Wi-Fi (registered trademark). The LAN communication unit 121 shall be equipped with encoding circuits, decoding circuits, etc. Furthermore, the broadcast receiving device 100 may also be equipped with other communication units such as a Bluetooth (registered trademark) communication unit, an NFC communication unit, or an infrared communication unit.

The tuner/demodulator 131 receives broadcast waves transmitted from the radio tower 300t via the antenna 100a and tunes (selects) to the channel of the service desired by the user based on the control of the main control unit 101. Furthermore, the tuner/demodulator 131 demodulates the received broadcast signal to obtain the MMT data sequence. While the example shown in Figure 8A illustrates a configuration with one tuner/demodulator, the broadcast receiving device 100 may be configured with multiple tuners/demodulators for purposes such as simultaneous display of multiple screens or recording of programs while watching another.

The separation unit 132 is an MMT decoder and, based on the control signals in the input MMT data sequence, distributes real-time presentation elements such as video data sequences, audio data sequences, character superimposed data sequences, and subtitle data sequences to the video decoder 141, audio decoder 143, character superimposed decoder 144, and subtitle decoder 145, respectively. The data input to the separation unit 132 may be MMT data sequences transmitted via a broadcast transmission line and demodulated by the tuner/demodulation unit 131, or MMT data sequences transmitted via a communication line and received by the LAN communication unit 121. The separation unit 132 also plays back multimedia applications and their constituent file data and temporarily stores them in the cache unit 152. Furthermore, the separation unit 132 extracts general-purpose data for use in players that present data other than video, audio, and subtitles, or for streaming data to applications, and outputs it to the data decoder 151. Furthermore, the separation unit 132 may perform error correction and access restriction control on the input MMT data sequence based on the control of the main control unit 101.

The video decoder 141 decodes the video data sequence input from the separation unit 132 and outputs video information. The video color gamut conversion unit 142 performs color space conversion processing on the video information decoded by the video decoder 141, as needed, for video synthesis processing in the video synthesis unit 161. The audio decoder 143 decodes the audio data sequence input from the separation unit 132 and outputs audio information. Furthermore, the video decoder 141 and audio decoder 143 may also receive streaming data, such as MPEG-DASH (MPEG-Dynamic Adaptive Streaming over HTTP) format, acquired from the Internet 200 via the LAN communication unit 121. Additionally, multiple video decoders 141, video color gamut conversion units 142, audio decoders 143, etc., may be provided to simultaneously decode multiple types of video and audio data sequences.

The character super decoder 144 decodes the character super data sequence input from the separation unit 132 and outputs character super information. The subtitle decoder 145 decodes the subtitle data sequence input from the separation unit 132 and outputs subtitle information. The character super information output from the character super decoder 144 and the subtitle information output from the subtitle decoder 145 are combined in the subtitle combination unit 146, and further, the subtitle color gamut conversion unit 147 performs color space conversion processing as needed for the video combination processing in the video combination unit 161. In this embodiment, among the services centered on text information presented simultaneously with the video of a broadcast program, those related to the video content are called subtitles, and all others are called character supers. When they are not distinguished, they are collectively referred to as subtitles.

The browser unit 154 presents multimedia application files and their constituent file data obtained from a server device on the Internet 200 via the cache unit 152 or the LAN communication unit 121, according to instructions from the application control unit 153, which interprets control information contained in the MMT data sequence and control information obtained from the server device on the Internet 200 via the LAN communication unit 121. The multimedia application files may be HTML (Hyper Text Markup Language) documents, BML (Broadcast Markup Language) documents, etc. The application information output from the browser unit 154 is further subjected to color space conversion processing as needed by the application color gamut conversion unit 155 for video synthesis processing in the video synthesis unit 161. The browser unit 154 also plays application audio information by interacting with the sound source unit 156.

The video synthesis unit 161 receives video information output from the video color gamut conversion unit 142, subtitle information output from the subtitle color gamut conversion unit 147, and application information output from the application color gamut conversion unit 155, and performs appropriate selection and/or superposition processing. The video synthesis unit 161 is equipped with a video RAM (not shown), and the monitor unit 162, etc., are driven based on the video information, etc., input to the video RAM. Furthermore, the video synthesis unit 161, based on the control of the main control unit 101, performs scaling processing and superposition processing of EPG (Electronic Program Guide) screen information created based on information such as MH-EIT included in MMT-SI, as needed. The monitor unit 162 is a display device such as an LCD panel, and provides the video information selected and/or superimposed by the video synthesis unit 161 to the user of the broadcast receiving device 100. The video output unit 163 is a video output interface that outputs video information selected and/or superimposed by the video synthesis unit 161.

The display function of the broadcast receiving device 100 in this embodiment is equipped with a logical plane structure to display content as intended by the multimedia service provider. Figure 8B shows an example of the configuration of the logical plane structure of the display function of the broadcast receiving device 100 in this embodiment. In this logical plane structure, a character superplane for displaying character superimposition is placed at the front, and a subtitle plane for displaying subtitles is placed on the next layer. A multimedia plane for displaying broadcast video, multimedia applications, or their combined video is placed on the third layer, and a background plane is placed at the back. The subtitle synthesis unit 146 and the video synthesis unit 161 draw character superimposition information onto the character superplane, draw subtitle information onto the subtitle plane, and draw video information, application information, etc., onto the multimedia plane. In addition, the background color is drawn on the background plane based on the LCT, etc., included in MMT-SI. It is possible to provide multiple multimedia planes in the third layer depending on the number of video decoders 141. However, even if there are multiple multimedia planes, application information etc. output from the application color gamut conversion unit 155 will only be output to the frontmost multimedia plane.

The speech synthesis unit 164 receives audio information output from the audio decoder 143 and application audio information played back by the sound source unit 156, and performs appropriate selection and/or mixing processing. The speaker unit 165 provides the audio information selected and/or mixed by the speech synthesis unit 164 to the user of the broadcast receiving device 100. The audio output unit 166 is an audio output interface that outputs the audio information selected and/or mixed by the speech synthesis unit 164.

The expansion interface unit 124 is a group of interfaces for expanding the functionality of the broadcast receiving device 100. In this embodiment, it consists of an analog video/audio interface, a USB (Universal Serial Bus) interface, a memory interface, etc. The analog video/audio interface handles the input of analog video/audio signals from external video/audio output devices and the output of analog video/audio signals to external video/audio input devices. The USB interface connects to a PC or other device for data transmission and reception. An HDD may be connected to record broadcast programs and content. A keyboard or other USB device may also be connected. The memory interface connects to a memory card or other memory medium for data transmission and reception.

The digital interface unit 125 is an interface for outputting or inputting encoded digital video data and/or digital audio data. The digital interface unit 125 is capable of directly outputting MMT data sequences obtained by demodulation in the tuner/demodulation unit 131, MMT data sequences acquired via the LAN communication unit 121, or mixed data of the aforementioned MMT data sequences. Furthermore, the digital interface unit 125 may be controlled to input the MMT data sequences input to the separation unit 132. Output of digital content stored in the storage unit 110, or storage of digital content in the storage unit 110, may also be performed via the digital interface unit 125.

The digital interface unit 125 may be a DVI terminal, HDMI® terminal, DisplayPort® terminal, etc., and may output or input data in a format compliant with the DVI specification, HDMI specification, DisplayPort specification, etc. It may also output or input data in a serial data format compliant with the IEEE 1394 specification, etc. Furthermore, it may be configured as an IP interface that performs digital interface output via hardware such as Ethernet® or wireless LAN. In this case, the digital interface unit 125 and the LAN communication unit 121 may share their hardware configurations.

The operation input unit 170 is an instruction input unit that inputs operation instructions to the broadcast receiving device 100. In this embodiment, it consists of a remote control receiver unit that receives commands transmitted from a remote control (not shown) and an operation key with a row of button switches. Either one of these may be used. The operation input unit 170 may also be replaced by a touch panel superimposed on the monitor unit 162. It may also be replaced by a keyboard connected to the expansion interface unit 124. The remote control (not shown) may be replaced by a portable information terminal 700 equipped with a remote control command transmission function.

As mentioned above, if the broadcast receiving device 100 is a television receiver or the like, the video output unit 163 and the audio output unit 166 are not essential components of the present invention. Furthermore, the broadcast receiving device 100 may be an optical disc drive recorder such as a DVD (Digital Versatile Disc) recorder, a magnetic disc drive recorder such as an HDD recorder, an STB (Set-Top Box), etc. It may also be a PC (Personal Computer), tablet terminal, navigation device, game console, etc., equipped with digital broadcasting reception and broadcasting communication linkage functions. If the broadcast receiving device 100 is a DVD recorder, HDD recorder, STB, etc., the monitor unit 162 and the speaker unit 165 do not need to be provided. By connecting an external monitor and external speakers to the video output unit 163 and the audio output unit 166 or the digital interface unit 125, the same operation as the broadcast receiving device 100 in this embodiment becomes possible.

[Software configuration of broadcast receiving equipment]
Figure 8C is a software configuration diagram of the broadcast receiving device 100 in this embodiment, showing the software configuration in the ROM 103, RAM 104, and storage unit 110. In this embodiment, the ROM 103 stores the basic operation program 1001 and other operation programs, and the storage unit 110 stores the reception function program 1002, the cooperation function program 1003, the recording and playback function program 1004, and other operation programs. The storage unit 110 also includes a content storage area 1200 for storing content such as video, still images, and audio, an authentication information storage area 1300 for storing authentication information necessary when accessing external mobile terminal devices and various server devices, and various information storage areas for storing other various information.

The basic operation program 1001 stored in ROM 103 is loaded into RAM 104, and the main control unit 101 then executes the loaded basic operation program 1001 to constitute the basic operation execution unit 1101. Similarly, the receiving function program 1002, the cooperation function program 1003, and the recording/playback function program 1004 stored in storage unit 110 are also loaded into RAM 104, and the main control unit 101 then executes the loaded receiving function program 1002, the cooperation function program 1003, and the recording/playback function program 1004 to constitute the receiving function execution unit 1102, the cooperation function execution unit 1103, and the recording/playback function execution unit 1104. Furthermore, RAM 104 includes a temporary storage area for temporarily holding data created during the execution of each operation program as needed.

For the sake of simplicity, the following description assumes that the basic operation execution unit 1101 controls each operation block, rather than the main control unit 101 loading the basic operation program 1001 stored in the ROM 103 into the RAM 104 and executing it. The same description applies to other operation programs.

The receiving function execution unit 1102 controls each operating block of the broadcast receiving device 100 in order to reproduce video, audio, and other components transmitted in the broadcasting system of this embodiment. In particular, the transport processing unit 1102a mainly controls the MMT decoder function of the separation unit 132 and distributes the video data sequence, audio data sequence, etc., separated from the MMT data sequence to the corresponding decoding processing unit. The AV decoding processing unit 1102b mainly controls the video decoder 141, audio decoder 143, etc. The application processing unit 1102c mainly controls the cache unit 152, application control unit 153, browser unit 154, and sound source unit 156. The character superimposition processing unit 1102d mainly controls the character superimposition decoder 144. The subtitle processing unit 1102e mainly controls the subtitle decoder 145. The general-purpose data processing unit 1102f mainly controls the data decoder 151. The EPG generation unit 1102g interprets the description content of MH-EIT and other elements included in MMT-SI and generates the EPG screen. The presentation processing unit 1102h primarily controls the video color gamut conversion unit 142, subtitle synthesis unit 146, subtitle color gamut conversion unit 147, application color gamut conversion unit 155, video synthesis unit 161, and audio synthesis unit 164 based on the logical plane structure.

Furthermore, the collaboration function execution unit 1103 manages device authentication and connection, transmission and reception of data, etc., when the broadcast receiving device 100 performs collaborative operations with external devices such as a mobile information terminal 700. The recording and playback function execution unit 1104 controls the recording of broadcast programs acquired from the digital broadcast waves of this broadcasting system and content acquired from various server devices on the network to the content storage area 1200 of the storage unit 110 or to external storage connected to the expansion interface unit 124, or controls the playback of the aforementioned broadcast programs and content.

The aforementioned operating programs may be pre-stored in the ROM 103 and/or storage unit 110 at the time of product shipment. Alternatively, they may be acquired after product shipment from other application servers 500, etc., on the Internet 200 via the LAN communication unit 121. Furthermore, the aforementioned operating programs stored on memory cards, optical discs, etc., may be acquired via the expansion interface unit 124, etc.

[Broadcasting station server configuration]
Figure 9 is a block diagram showing an example of the internal configuration of the broadcasting station server 300. The broadcasting station server 300 consists of a main control unit 301, a system bus 302, a RAM 304, a storage unit 310, a LAN communication unit 321, and a digital broadcasting signal transmission unit 360.

The main control unit 301 is a microprocessor unit that controls the entire broadcasting station server 300 according to a predetermined operating program. The system bus 302 is a data communication path for sending and receiving data between the main control unit 301 and each operating block within the broadcasting station server 300. The RAM 304 serves as the work area during the execution of each operating program.

The storage unit 310 stores the basic operation program 3001, the broadcast content management/distribution program 3002, and the broadcast content transmission program 3003. Furthermore, it includes a broadcast content storage area 3200 and a metadata storage area 3300. The broadcast content storage area 3200 stores the program content of each broadcast program broadcast by the broadcasting station. The metadata storage area 3300 stores metadata such as the program title, program ID, program summary, cast, broadcast date and time, and copy control information related to each program's content.

Furthermore, the basic operation program 3001, the broadcast content management/distribution program 3002, and the broadcast content transmission program 3003 stored in the storage unit 310 are each loaded into the RAM 304. The main control unit 301 then executes each of these loaded programs, thereby configuring the basic operation execution unit 3101, the broadcast content management/distribution execution unit 3102, and the broadcast content transmission execution unit 3103.

For the sake of simplicity, in the following explanation, the process by which the main control unit 301 controls each operation block by loading the basic operation program 3001 stored in the storage unit 310 into the RAM 304 and executing it will be described as if the basic operation execution unit 3101 controls each operation block. The same description will be applied to other operation programs.

The broadcast content management/distribution execution unit 3102 manages the program content and metadata of each broadcast program stored in the broadcast content storage area 3200 and the metadata storage area 3300, and controls the provision of the program content and metadata of each broadcast program to service providers based on the contract. Furthermore, when providing the program content and metadata of each broadcast program to the service provider, the broadcast content management/distribution execution unit 3102 may, if necessary, perform authentication processing of the service provider server 400 based on the contract.

The broadcast content transmission execution unit 3103 manages the time schedule for transmitting the program content of broadcast programs stored in the broadcast content storage area 3200, and the MMT data sequence containing the program title, program ID, and copy control information of the program content stored in the metadata storage area 3300, from the radio tower 300t via the digital broadcast signal transmission unit 360.

The LAN communication unit 321 is connected to the Internet 200 and communicates with service provider servers 400 and other devices on the Internet 200. The LAN communication unit 321 is equipped with encoding circuits, decoding circuits, etc. The digital broadcast signal transmission unit 360 modulates the MMT data sequence, which consists of video data sequences, audio data sequences, program information data sequences, etc., of each broadcast program stored in the broadcast content storage area 3200, and transmits it as a digital broadcast wave via the radio tower 300t.

[Service provider server configuration]
Figure 10 is a block diagram showing an example of the internal configuration of a service provider server 400. The service provider server 400 consists of a main control unit 401, a system bus 402, RAM 404, a storage unit 410, and a LAN communication unit 421.

The main control unit 401 is a microprocessor unit that controls the entire service provider server 400 according to a predetermined operating program. The system bus 402 is a data communication path for sending and receiving data between the main control unit 401 and each operating block within the service provider server 400. The RAM 404 serves as the work area during the execution of each operating program.

The storage unit 410 stores the basic operation program 4001, the video content management/distribution program 4002, and the application management/distribution program 4004. Furthermore, it includes a video content storage area 4200, a metadata storage area 4300, an application storage area 4400, and a user information storage area 4500. The video content storage area 4200 stores program content of broadcast programs provided by the broadcasting station server 300 as video content. It also stores video content produced by the service provider. The metadata storage area 4300 stores metadata provided by the broadcasting station server 300, as well as metadata related to video content produced by the service provider. The application storage area 4400 stores various applications for realizing services linked to broadcast programs, distributed in response to requests from each television receiver. The user information storage area 4500 stores information (personal information, authentication information, etc.) about users authorized to access the service provider server 400.

Furthermore, the basic operation program 4001, the video content management/distribution program 4002, and the application management/distribution program 4004 stored in the storage unit 410 are each loaded into the RAM 404. The main control unit 401 then executes the loaded basic operation program, video content management/distribution program, and application management/distribution program, thereby configuring the basic operation execution unit 4101, the video content management/distribution execution unit 4102, and the application management/distribution execution unit 4104.

For the sake of simplicity, in the following explanation, the process by which the main control unit 401 controls each operation block by loading the basic operation program 4001 stored in the storage unit 410 into the RAM 404 and executing it will be described as if the basic operation execution unit 4101 controls each operation block. The same description will be applied to other operation programs.

The video content management/distribution execution unit 4102 acquires program content and metadata of broadcast programs from the broadcasting station server 300, manages the video content and metadata stored in the video content storage area 4200 and the metadata storage area 4300, and controls the distribution of the video content and metadata to each television receiver. Furthermore, when distributing the video content and metadata to each television receiver, the video content management/distribution execution unit 4102 may perform authentication processing for each television receiver as needed. The application management/distribution execution unit 4104 manages the applications stored in the application storage area 4400 and controls the distribution of each application to each television receiver in response to requests. Furthermore, when distributing the applications to each television receiver, the application management/distribution execution unit 4104 may perform authentication processing for each television receiver as needed.

The LAN communication unit 421 is connected to the Internet 200 and communicates with the broadcasting station server 300 on the Internet 200 and the broadcasting receiving device 100 via the router device 200r. The LAN communication unit 421 is equipped with encoding circuits, decoding circuits, etc.

[Hardware configuration of mobile devices]
Figure 11A is a block diagram showing an example of the internal configuration of a portable information terminal 700. The portable information terminal 700 consists of a main control unit 701, a system bus 702, a ROM 703, a RAM 704, a storage unit 710, a communication processing unit 720, an expansion interface unit 724, an operation unit 730, an image processing unit 740, an audio processing unit 750, and a sensor unit 760.

The main control unit 701 is a microprocessor unit that controls the entire portable information terminal 700 according to a predetermined operating program. The system bus 702 is a data communication path for sending and receiving data between the main control unit 701 and each operating block within the portable information terminal 700.

ROM 703 is memory that stores basic operating programs such as the operating system and other operational programs. For example, a rewritable ROM such as EEPROM or flash ROM is used. RAM 704 serves as the work area during the execution of basic operating programs and other operational programs. ROM 703 and RAM 704 may be integrated with the main control unit 701. Furthermore, ROM 703 may not have an independent configuration as shown in Figure 11A, but may utilize a portion of the storage area within the storage unit 710.

The storage unit 710 stores the operating program and settings of the personal information terminal 700, as well as the personal information of the user of the personal information terminal 700. It can also store operating programs downloaded via the Internet 200 and various data created by those operating programs. Furthermore, it can store content such as videos, still images, and audio downloaded via the Internet 200. A portion of the storage unit 710 may replace all or part of the functions of the ROM 703. The storage unit 710 also needs to retain the stored information even when the personal information terminal 700 is not receiving external power. Therefore, devices such as flash ROM, SSDs, or other non-volatile semiconductor memory, or HDDs, etc., are used.

Furthermore, the aforementioned operating programs stored in ROM 703 and storage unit 710 can be added, updated, and have their functions expanded through download processing from various server devices on the Internet 200.

The communication processing unit 720 consists of a LAN communication unit 721, a mobile telephone network communication unit 722, and an NFC communication unit 723. The LAN communication unit 721 is connected to the Internet 200 via a router device 200r or an access point 200a, and transmits and receives data with various server devices and other communication devices on the Internet 200. The connection with the router device 200r or access point 200a is made via a wireless connection such as Wi-Fi (registered trademark). The mobile telephone network communication unit 722 performs telephone communication (calls) and data transmission and reception via wireless communication with a base station 600b of the mobile telephone communication network. The NFC communication unit 723 performs wireless communication when in proximity to a corresponding reader/writer. The LAN communication unit 721, the mobile telephone network communication unit 722, and the NFC communication unit 723 are each equipped with a coding circuit, a decoding circuit, an antenna, etc. Furthermore, the communication processing unit 720 may also include other communication units, such as a Bluetooth® communication unit or an infrared communication unit.

The expansion interface unit 724 is a group of interfaces for expanding the functionality of the portable information terminal 700. In this embodiment, it consists of a video/audio interface, a USB interface, a memory interface, etc. The video/audio interface handles the input of video/audio signals from external video/audio output devices and the output of video/audio signals to external video/audio input devices. The USB interface connects to a PC or other device for sending and receiving data. It may also be used to connect a keyboard or other USB devices. The memory interface connects to a memory card or other memory medium for sending and receiving data.

The operation unit 730 is an instruction input unit that inputs operation instructions for the portable information terminal 700. In this embodiment, it consists of a touch panel 730t superimposed on the display unit 741 and an operation key 730k with a row of button switches. Either one or the other may be used. The portable information terminal 700 may also be operated using a keyboard connected to the expansion interface unit 724. Alternatively, the portable information terminal 700 may be operated using a separate terminal device connected via wired or wireless communication. That is, the portable information terminal 700 may be operated from the broadcast receiving device 100. Furthermore, the touch panel function may be provided by the display unit 741.

The image processing unit 740 consists of a display unit 741, an image signal processing unit 742, a first image input unit 743, and a second image input unit 744. The display unit 741 is a display device such as a liquid crystal panel, and provides image data processed by the image signal processing unit 742 to the user of the portable information terminal 700. The image signal processing unit 742 includes a video RAM (not shown), and the display unit 741 is driven based on the image data input to the video RAM. The image signal processing unit 742 also has functions to perform format conversion, menu and other OSD (On Screen Display) signal superposition processing as needed. The first image input unit 743 and the second image input unit 744 are camera units that input image data of the surroundings and objects by converting light input from the lens into electrical signals using electronic devices such as CCD (Charge Coupled Device) or CMOS (Complementary Metal Oxide Semiconductor) sensors.

The audio processing unit 750 consists of an audio output unit 751, an audio signal processing unit 752, and an audio input unit 753. The audio output unit 751 is a speaker and provides the audio signal processed by the audio signal processing unit 752 to the user of the portable information terminal 700. The audio input unit 753 is a microphone and inputs the user's voice and other audio data.

The sensor unit 760 is a group of sensors for detecting the state of the portable information terminal 700. In this embodiment, it consists of a GPS receiver 761, a gyro sensor 762, a geomagnetic sensor 763, an acceleration sensor 764, an illuminance sensor 765, and a proximity sensor 766. These sensors enable the detection of the position, tilt, direction, movement, ambient brightness, proximity of surrounding objects, etc., of the portable information terminal 700. The portable information terminal 700 may also be equipped with other sensors, such as a barometric pressure sensor.

The personal digital information terminal 700 may be a mobile phone, smartphone, tablet, etc. It may also be a PDA (Personal Digital Assistant) or a notebook PC. Furthermore, it may be a digital still camera, a video camera capable of recording video, a portable game console, a navigation device, or other portable digital device.

Note that the example configuration of the portable information terminal 700 shown in Figure 11A includes many components that are not essential to this embodiment, such as the sensor unit 760. However, the effectiveness of this embodiment will not be impaired even if these components are not included. Furthermore, additional components not shown, such as a digital broadcasting reception function or an electronic money payment function, may also be included.

[Software configuration of mobile devices]
Figure 11B is a software configuration diagram of the portable information terminal 700 in this embodiment, showing the software configuration in the ROM 703, RAM 704, and storage unit 710. In this embodiment, the ROM 703 stores the basic operation program 7001 and other operation programs, and the storage unit 710 stores the cooperation control program 7002 and other operation programs. The storage unit 710 also includes a content storage area 7200 for storing content such as video, still images, and audio, an authentication information storage area 7300 for storing authentication information necessary when accessing television receivers and various server devices, and various information storage areas for storing other various information.

The basic operation program 7001 stored in ROM 703 is loaded into RAM 704, and the main control unit 701 then executes the loaded basic operation program to constitute the basic operation execution unit 7101. Similarly, the cooperation control program 7002 stored in storage unit 710 is loaded into RAM 704, and the main control unit 701 then executes the loaded cooperation control program to constitute the cooperation control execution unit 7102. Furthermore, RAM 704 includes a temporary storage area for temporarily holding data created during the execution of each operation program as needed.

For the sake of simplicity, the following description assumes that the basic operation execution unit 7101 controls each operation block, whereas the main control unit 701 controls each operation block by loading the basic operation program 7001 stored in the ROM 703 into the RAM 704 and executing it. The same description applies to other operation programs.

The collaborative control execution unit 7102 manages device authentication and connection, transmission and reception of data, etc., when the mobile information terminal 700 performs collaborative operations with the television receiver. Furthermore, the collaborative control execution unit 7102 is equipped with a browser engine function for executing applications that interact with the television receiver.

The aforementioned operating programs may be pre-stored in the ROM 703 and/or storage unit 710 at the time of product shipment. Alternatively, they may be acquired after product shipment from other application servers 500, etc., on the Internet 200 via the LAN communication unit 721 or the mobile telephone network communication unit 722. Furthermore, the aforementioned operating programs stored on a memory card, optical disc, etc., may be acquired via the expansion interface unit 724, etc.

[Time management for broadcast receiving equipment]
The broadcast receiving device 100 of this embodiment is equipped with two types of time management functions. The first time management function is an NTP-based time management function, and the second time management function is an MH-TOT-based time management function. The following will describe these two types of time management functions.

<NTP-based time management function>
First, I will explain the NTP-based time management function.

Figure 12A shows an example of a system configuration for clock synchronization/presentation synchronization in a broadcast system to which the broadcast receiving device 100 of this embodiment corresponds. In the broadcast system of this embodiment, UTC is transmitted from the broadcast transmission system to the receiver (such as the broadcast receiving device 100 of this embodiment) in a 64-bit NTP timestamp format. In the NTP timestamp format, 32 bits represent "seconds or more" of UTC, and 32 bits represent "less than seconds." However, in reality, it is difficult to reproduce one second with 32-bit precision. Therefore, as a system clock for synchronizing the video system and a system clock for operating the NTP-formatted clock, a frequency of "2 to the power of 24" Hz (approximately 16.8 MHz), as shown in the figure, may be used. Considering that the system clock in conventional broadcast systems was 27 MHz and that the hardware configuration of the receiver can be easily constructed, it is desirable to adopt a power of 2 frequency, such as "2 to the power of 24" to "2 to the power of 28," as the system clock.

Furthermore, if the system clock on the broadcast transmission system side or the receiver side is set to a power of 2 frequency of approximately 2^24 to 2^28 as described above, the lower 8 to 4 bits of the NTP timestamp format transmitted from the broadcast transmission system side to the receiver side, which are not referenced by the system clock or the PLL (Phase Locked Loop) system for regenerating the NTP format clock, may be fixed to '0' or '1'. That is, if the system clock is 2^n Hz (n=24 in the example in Figure 12A, and so on), the lower 32-n bits of the NTP timestamp format may be fixed to '0' or '1'. Alternatively, the receiver side may process the lower 32-n bits of the NTP timestamp format by ignoring them.

On the broadcast transmission system side, upon obtaining NTP-formatted time information from an external source, a PLL system is configured using a 32+n bit counter with a VCO (Voltage Controlled Oscillator) operating at 2 to the power of n Hz, realizing a transmission system clock synchronized with the externally provided time information. Furthermore, the entire signal processing system is operated in synchronization with the 2 to the power of n Hz system clock. In addition, the output of the transmission system clock is periodically transmitted to the receiver side via the broadcast transmission line as NTP-length formatted time information. Note that the NTP-length formatted time information transmitted to the receiver side may have its lower 32-n bits, representing "less than a second," fixed to 0 or 1. This is because the broadcast transmission system's system clock counter is composed of 32+n bits.

On the receiver side, time information in NTP format is received via the broadcast transmission line, and, similar to the broadcast transmission system, the receiver system clock is regenerated using a PLL system based on a VCO with a frequency of 2 to the power of n Hz. This ensures that the receiver system clock is synchronized with the broadcast transmission system clock. Furthermore, by operating the receiver's signal processing system in synchronization with the 2 to the power of n Hz system clock, clock synchronization between the broadcast transmission system and the receiver is achieved, enabling stable signal regeneration.

Furthermore, the decoding time and presentation time for each presentation unit of the video/audio signal are set on the broadcast transmission system side based on the NTP-formatted time information. The decoding time is specified by an MPU extended timestamp descriptor (not shown) stored in the MPT. The presentation time is specified by an MPU timestamp descriptor (see Figure 7D) stored in the MPT. In the MPU timestamp descriptor, the 'mpu_sequence_number' parameter indicates the sequence number of the MPU describing the timestamp, and the 'mpu_presentation_time' parameter indicates the presentation time of the MPU in 64-bit NTP timestamp format. That is, by referring to the MPU timestamp descriptor stored in the MPT, the receiver can control the presentation (display, output, etc.) timing for each MPU of video/audio signals, subtitles, character overlays, etc.

Furthermore, when focusing on the control of decoding and presentation timing for each presentation unit of the aforementioned video/audio signals, synchronization of the video/audio signals can be ensured even with a clock of approximately 2 to the power of 16 Hz (approximately 65.5 kHz). In this case, the lower 16 bits of the NTP timestamp format described in the MPU timestamp descriptor, etc., do not need to be referenced. That is, if a clock of 2 to the power of m Hz, generated by frequency division of the system clock, etc., is used to control the decoding and presentation timing, the lower 32-m bits of the NTP timestamp format described in the MPU timestamp descriptor, etc., do not need to be referenced. Therefore, the lower 32-m bits of the NTP timestamp format described in the MPU timestamp descriptor, etc., may be fixed to 0 or 1.

<Time management function based on MH-TOT>
Figure 12B shows an example of the configuration of time information transmitted in NTP format in the NTP-based time management function described above. The 'reference_timestamp' parameter and the 'transmit_timestamp' parameter in the NTP format are 64-bit NTP-length time data, and the 'mpu_presentation_time' parameter in the MPU timestamp descriptor shown in Figure 7D is also 64-bit NTP timestamp-format time data. The NTP-length time data and the NTP timestamp-format time data represent 'seconds or more' in UTC with 32 bits and 'less than seconds' with 32 bits. In other words, NTP-format time information can transmit time information down to 'less than seconds'. Furthermore, since the NTP-formatted time information is in UTC notation, unlike conventional time management in digital broadcasting, as shown in Figure 3, by managing both the data flow transmitted via the broadcast transmission line and the data flow distributed via the communication line using the aforementioned NTP-formatted time information, it is possible to easily ensure consistency between the two sets of data.

In contrast, the time information transmitted via MH-TOT is as follows:

Figure 12C shows an example of the MH-TOT data structure. The broadcast receiving device 100 in this embodiment can obtain the current date and time from the 'JST_time' parameter of the MH-TOT. As shown in Figure 12D, the 'JST_time' parameter includes the lower 16 bits of encoded data of the current date using Modified Julian Date (MJD) and 24 bits of information representing Japan Standard Time (JST) using six 4-bit binary-coded decimal (BCD) numbers. The current date can be calculated by performing a predetermined operation on the 16-bit encoded data of the MJD. Furthermore, the six 4-bit binary-coded decimal numbers represent the following: the first two 4-bit binary-coded decimal numbers represent the 'hour' in two decimal digits, the next two 4-bit binary-coded decimal numbers represent the 'minute' in two decimal digits, and the last two 4-bit binary-coded decimal numbers represent the 'second' in two decimal digits.

In other words, the difference between time management based on the NTP format and time management based on MH-TOT is that the former, NTP-based time management, can transmit time information down to the second, as mentioned above, while the latter, MH-TOT-based time management, can only transmit time information down to the second in JST notation.

The broadcast receiving device 100 of this embodiment achieves higher-precision synchronization by using a time management function based on NTP, which is time information in UTC notation, for the decoding and display synchronization processing of video, audio, subtitles, text overlays, and other displayed data, which are the content of the broadcast signal. Furthermore, by referring to information in UTC notation rather than the clock notation of the broadcasting station, it is also possible to perform decoding and display synchronization processing between video, audio, subtitles, text overlays, or other data, which are the content received in the broadcast signal, and video, audio, subtitles, text overlays, or other data, which are acquired via the communication line path.

Furthermore, in the broadcast receiving device 100 of this embodiment, the time management function based on "JST_time," which includes 24 bits of information represented by six 4-bit binary-coded decimal numbers of the MH-TOT, may be used for the process of presenting the current time to the user or for each process that handles the MH-EIT shown in Figure 7E. Generally, in the process of presenting the current time to the user in a broadcast receiving device, precision down to the second is rarely required. Also, each time information written in the MH-EIT is 24 bits of information represented by six 4-bit binary-coded decimal numbers, similar to the EIT of conventional digital broadcasts transmitted using the MPEG2-TS method, and is stored in two decimal digits each for "hours," "minutes," and "seconds." For this reason, the time management function based on the MH-TOT in the broadcast receiving device 100 of this embodiment is easily compatible with each process that handles the MH-EIT. The processes that handle MH-EIT specifically include, for example, the generation of electronic program guides, the control of recording and viewing reservations, and copyright management processes such as temporary storage. None of these processes require sub-second precision; precision down to the second is usually sufficient.

Furthermore, the generation process of the electronic program guide, the control of recording and viewing reservations, and copyright management processes such as temporary storage are functions also included in receivers of conventional MPEG2-TS digital broadcasting systems. Therefore, in this embodiment, if the broadcasting system is configured to handle the generation of the electronic program guide, the control of recording and viewing reservations, and copyright management processes such as temporary storage using time management processes consistent with conventional MPEG2-TS digital broadcasting systems, then when configuring a broadcasting receiver that has both the reception capabilities of conventional MPEG2-TS digital broadcasting and MMT digital broadcasting, it becomes unnecessary to design separate processing algorithms for these processes (generation of the electronic program guide, control of recording and viewing reservations, and copyright management processes such as temporary storage), thereby reducing costs.

Furthermore, even for receivers that only have MMT digital broadcasting reception capabilities and lack the conventional MPEG2-TS digital broadcasting reception capabilities, development can be made at a lower cost because algorithms for processing such as electronic program guide generation, recording and viewing reservation control, and copyright management processing such as temporary storage can be reused from functions already implemented in receivers of conventional MPEG2-TS digital broadcasting systems, without having to completely create new algorithms.

Therefore, by configuring the time management function based on the MH-TOT's 'JST_time' parameter to be used for these processes (such as generating electronic program guides, controlling recording and viewing reservations, and copyright management processes like temporary storage), it becomes possible to provide MMT-type digital broadcasting receiving equipment at a lower cost by improving compatibility with conventional broadcasting systems.

As explained above, the broadcast receiving device 100 of this embodiment is equipped with a time management function that uses two types of time information with different accuracies. Specifically, the first time information is time information with a notation consistent with conventional digital broadcasting systems, and the second time information is time information with a higher resolution than the first time information. By using the second time information for the synchronization processing of each content data in the broadcast signal, more advanced information presentation processing than conventional broadcasting systems can be achieved. By using the first time information for processes such as generating electronic program guides, controlling recording and viewing reservations, and copyright management processes such as temporary storage, the broadcast receiving device can be provided at a low cost.

Therefore, the broadcast receiving device 100 of this embodiment, by incorporating the two types of time management functions described above, makes it possible to achieve both more advanced information presentation processing and lower costs.

[First variation of time management]
Next, a first modified example of time management in the broadcasting system of this embodiment will be described below.

In the first modification, in order to improve the accuracy of the managed time of the NTP-based time management function already explained using Figure 12A, information regarding the assumed delay time in time information transmission from the time management server (not shown) or broadcasting station server 300 to the broadcast receiving device 100 may be included in the broadcast signal and transmitted, and the broadcast receiving device 100 may be configured to use this assumed delay time information to correct the system clock of the NTP-based time management function.

In this case, the information regarding the assumed delay time may be configured to be transmitted not within the TLV multiplexed stream of the protocol stack in the broadcast transmission path shown in Figure 3(A), but within the TMCC (Transmission and Multiplexing Configuration Control) area outside the TLV multiplexed stream. Transmission within the TMCC area allows the broadcast receiver 100 to extract the information regarding the assumed delay time without going through the TLV multiplexed stream separation process (demaxing process). That is, it becomes possible to acquire information that is less affected by the delay caused by the separation process in the broadcast receiver 100, and therefore, highly accurate system clock correction processing can be performed. An example of the data structure of the time information transmitted by the TMCC signal will be explained using Figure 12E. This time information may be stored and transmitted, for example, in the TMCC extended information area. In the time information of the TMCC extended information area shown in the figure, the 'delta' parameter represents the expected transmission delay from the time management server distributing UTC or the server device creating the TMCC signal to a general broadcast receiving device as a 32-bit signed fixed-point number. The upper 16 bits represent the integer part, and the lower 16 bits represent the decimal part. The 'transmit_timestamp' parameter is the transmission timestamp, describing the time when this TMCC signal is sent from the server device in NTP timestamp length format. The upper 32 bits represent the integer part, and the lower 32 bits represent the decimal part.

In this first modification, the broadcast receiving device 100 of this embodiment can use the information regarding the assumed delay time (for example, the aforementioned 'delta' parameter and/or 'transmit_timestamp' parameter) described in the time information transmitted in the TMCC extended information area to correct the system clock of the NTP-based time management function used for synchronizing each content data of the broadcast signal with greater precision.

[Second variation of time management]
Next, a second modified example of time management in the broadcasting system of this embodiment will be described below.

As described above, the broadcast receiving device 100 of this embodiment has a time management function that acquires the current date and Japan Standard Time from the information transmitted via MH-TOT and manages the time accordingly. The current date and Japan Standard Time acquired from the information transmitted via MH-TOT are superimposed on video information and application information, etc., by the video synthesis unit 161 of the broadcast receiving device 100, and can then be output to the monitor unit 162 and video output unit 163 for use by the user. As described above, MH-TOT has the data structure shown in Figure 12C, and the broadcast receiving device 100 can acquire the current date and time from the 'JST_time' parameter of the MH-TOT.

However, the aforementioned 'JST_time' parameter uses only the lower 16 bits of the MJD encoded data, resulting in an overflow at 'April 22, 2038'. Therefore, the aforementioned predetermined calculation alone cannot represent dates after 'April 23, 2038'. In the second modification of this embodiment, the calculation method is switched depending on whether the MJD value is greater than or equal to a predetermined value or less than a predetermined value, thereby controlling the representation to include dates after 'April 23, 2038'.

Figure 12F shows an example of a first calculation method used when the value of MJD is greater than or equal to a predetermined value, and a second calculation method used when the value of MJD is less than a predetermined value. For example, if the predetermined value is set to "32768 (0x8000)", the current date is calculated using the first calculation method when MJD is "32768" or greater, and the current date is calculated using the second calculation method when MJD is less than "32768". Note that when MJD is less than "32768", it is equivalent to when the most significant bit of the 16-bit data of MJD is "0". As a result, the broadcast receiving device 100 of this embodiment can represent dates from "April 23, 2038" onwards. However, the predetermined value can be set arbitrarily, and the predetermined value may be set to "16384 (0x4000)" or "49152 (0xC000)", etc. The conditions for switching the calculation method may be set to either when the upper two bits of the 16-bit data of the MJD are '00', or when the upper two bits of the 16-bit data of the MJD are not '11'. Note that if the predetermined value is set to '32768' and the aforementioned method is used, it will not be possible to represent dates prior to 'September 4, 1948', but this does not pose any particular problem for practical use as a television receiver.

Furthermore, instead of switching between the first and second calculation methods based on the comparison result between the MJD and the predetermined value, the first and second calculation methods may be switched based on a flag that replaces or newly adds part or all of the 'reserved' parameter in the MH-TOT data structure shown in Figure 12C. For example, the flag could be set to '1' if the most significant bit of the 16-bit encoded data of the MJD is '0', and to '0' if the MJD indicates a date of 'April 23, 2038' or later, and to '0' if it does not indicate a date of 'April 23, 2038' or later. Then, when the flag is '1', the second calculation method shown in Figure 12F may be used, and when the flag is '0', the first calculation method may be used. Alternatively, a descriptor with the same meaning as the flag may be newly prepared and placed within the MH-TOT.

Furthermore, as described above, the broadcasting system of this embodiment transmits absolute time in NTP format, and the broadcasting receiver 100 of this embodiment has a time management function based on said NTP. Moreover, the broadcasting receiver 100 of this embodiment controls the decoding timing and presentation timing for each presentation unit of video/audio signals by referring to the NTP timestamp etc. described in the MPU timestamp descriptor set for each MPU unit. As described above, the NTP time information has the configuration shown in Figure 12B. The MPU timestamp descriptor has the configuration shown in Figure 7D.

Therefore, in the broadcast receiving device 100 of this embodiment, the device may refer to the 'reference_timestamp' parameter, the 'transmit_timestamp' parameter, or the 'mpu_presentation_time' parameter, etc., and select which of the first and second calculation methods to use according to the value of the referenced time data, etc. That is, for example, if the most significant bit of the 64-bit NTP-length time data is '0', the second calculation method may be used; otherwise, the first calculation method may be used.

By any of the methods described above, the broadcast receiving device 100 of this embodiment will be able to display dates from April 23, 2038 onwards.

[Broadcast receiving device channel selection process (initial scan)]
The AMT of the broadcasting system in this embodiment provides a list of multicast groups for IP packets in order to receive IP packets transmitted using the TLV multiplexing method with as little distinction as possible from IP packets transmitted over a communication line. Multiple IP multicast groups can be listed for a single service identifier. In addition, an address mask can be used to efficiently describe consecutive IP addresses.

In this embodiment, the broadcast receiving device 100 can store a list of services acquired from TLV-NIT in non-volatile memory such as ROM 103 or storage unit 110 during channel scanning for initial setup or during rescanning for setting changes. Furthermore, a list of IP multicast groups corresponding to each service can be stored in the non-volatile memory as IP-related information, associated with each service. By storing the service list and IP-related information in non-volatile memory and making them constantly accessible, it becomes unnecessary to reacquire TLV-NIT or AMT during channel switching, enabling efficient acquisition of broadcast content.

Figure 13A shows an example of the operation sequence during channel scanning (rescanning) in the broadcast receiving device 100 of this embodiment.

When a channel scan is initiated, the receiving function execution unit 1102 instructs the tuner/demodulator 131 to set an initial frequency value and tune to that frequency value (S101). If the tuner/demodulator 131 successfully locks to the set frequency value (S102: Yes), the receiving function execution unit 1102 then acquires the TLV-NIT from the received signal (S103).

If the TLV-NIT obtained in processing S103 is valid data (S104: Yes), the receiving function execution unit 1102 obtains information such as the TLV stream ID and original network ID from the obtained TLV-NIT (S105). Figure 13B shows an example of the TLV-NIT data structure. The TLV stream ID information can be obtained from the 'tlv_stream_id' parameter, and the original network ID information can be obtained from the 'original_network_id' parameter. Furthermore, distribution system information regarding the physical conditions of the broadcast transmission path corresponding to each TLV stream ID/original network ID is obtained from the distribution system descriptor (S106), and a list of service IDs is obtained from the service list descriptor (S107).

Figure 13C shows an example of the data structure of a satellite distribution system descriptor. Figure 13D shows an example of the data structure of a service list descriptor. Note that if the TLV-NIT has multiple different data such as TLV stream ID, original network ID, distribution system information, and a list of service IDs, the processing in S105 to S107 is repeated. Next, the receiving function execution unit 1102 creates a service list based on the data such as the TLV stream ID, original network ID, distribution system information, and list of service IDs obtained in the processing in S105 to S107, and stores the created service list in the ROM 103 or storage unit 110, etc. (updated during rescanning) (S108).

Next, the receiving function execution unit 1102 acquires the AMT from the received signal (S109), and then acquires a list of IP multicast groups related to each service ID stored in the service list (S110). Figure 13E shows an example of the AMT data structure. If the AMT has lists of IP multicast groups related to multiple service IDs, the process in S110 is repeated. If there are multiple AMTs, each having a list of IP multicast groups related to different service IDs, the processes in S109 to S110 are repeated. Next, the receiving function execution unit 1102 stores the list of IP multicast groups acquired in the S110 process as IP-related information, associated with the service IDs, in the ROM 103 or storage unit 110, etc. (updated during rescanning) (S111).

Furthermore, if the tuner/demodulator 131 fails to lock to the set frequency value during the S102 process (S102: No), and if the TLV-NIT obtained during the S103 process is not valid data (S104: No), then the processes S105 to S111 are not performed.

After completing the process in S111, the receiving function execution unit 1102 terminates processing if the frequency value set in the tuner/demodulation unit 131 is the final frequency value of the channel scan range (S112: Yes). On the other hand, if the set frequency value is not the final frequency value of the channel scan range (S112: No), the frequency value set in the tuner/demodulation unit 131 is increased (S113), and the processes in S102 to S111 are repeated. Note that if a single TLV-NIT can obtain service IDs for all services constituting the broadcast network, and can also obtain an AMT containing a list of IP multicast groups related to the service IDs, then the processes in S112 to S113 are unnecessary.

Through the series of processes described above, the broadcast receiving device 100 of this embodiment can, during channel scanning for initial setup or during rescanning for setting changes, simultaneously create/update a list of services constituting the broadcast network (service list) and create/update a list of IP multicast groups corresponding to each service (IP-related information), and further store this information in non-volatile memory such as ROM 103 or storage unit 110.

Furthermore, the rescan for the aforementioned setting change may be performed automatically when a change in the information within the table is detected by referring to the 'version_number' parameter of TLV-NIT or AMT. Alternatively, when a change in the 'version_number' parameter of either TLV-NIT or AMT is detected, only the information related to the table where the parameter change was detected may be automatically updated. However, when the aforementioned automatic update is performed, it is desirable to notify the user that an automatic rescan has been conducted. It is also possible to inform the user that a change has occurred in the information within the table and allow the user to choose whether or not to perform the rescan.

[Channel selection process (channel switching) for broadcast receiving equipment]
Figure 14A shows an example of the operation sequence when selecting a station (switching channels) in the broadcast receiving device 100 of this embodiment.

When a user operates a remote control (not shown in the diagram) to instruct a channel change, the receiving function execution unit 1102 interprets the command transmitted from the remote control and specifies the service ID of the target service (S201). Next, the receiving function execution unit 1102 starts acquiring the AMT from the received signal of the tuner/demodulation unit 131. If the AMT is successfully acquired within a predetermined time (S202: Yes), information regarding a list of IP multicast groups corresponding to the service ID is obtained from the acquired AMT (S204). On the other hand, if the AMT is not successfully acquired within a predetermined time (S202: No), information regarding a list of IP multicast groups corresponding to the service ID is obtained by referring to IP-related information stored in the ROM 103 or storage unit 110, etc. (S203) (S204). Note that the decision process in S202 may be omitted, and the system may always refer to IP-related information stored in the ROM 103 or storage unit 110, etc.

Next, the receiving function execution unit 1102 starts acquiring the TLV-NIT from the received signal of the tuner/demodulation unit 131. If the acquisition of the TLV-NIT is successful within a predetermined time (S205: Yes), the distribution system information for acquiring the IP data flow corresponding to the service ID is acquired from the acquired TLV-NIT (S207). On the other hand, if the acquisition of the TLV-NIT is not successful within a predetermined time (S205: No), the distribution system information for acquiring the IP data flow corresponding to the service ID is acquired by referring to the service list stored in the ROM 103 or storage unit 110, etc. (S206) (S207). Alternatively, the decision process in S205 may be omitted, and the system may always refer to the service list stored in the ROM 103 or storage unit 110, etc.

After obtaining the distribution system information in the S207 process, the receiving function execution unit 1102 then controls the tuner/demodulation unit 131 using the frequency value indicated by the obtained distribution system information, receives the IP data flow corresponding to the service ID (S208), extracts the MMT data sequence from the received IP data flow, and outputs it to the separation unit 132.

In the separation unit 132, the transport processing unit 1102a obtains an MMTP packet with a packet ID of '0' from the input MMTP data sequence (S209), and further obtains the MPT contained in the obtained MMTP packet (S210). Next, the transport processing unit 1102a refers to the 'MMT_package_id_byte' parameter of the obtained MPT and checks whether the lower 16 bits of the 'MMT_package_id_byte' parameter are the same value as the service ID. In the example of the MPT data structure shown in Figure 7B, if the lower 16 bits of the 'MMT_package_id_byte' parameter are the same as the service ID (S211: Yes), it is determined that the MMTP packet with a packet ID of '0' is an MMTP packet containing program data corresponding to the service ID, and the process proceeds to acquire the MFU based on the information obtained from the MPT.

On the other hand, if the lower 16 bits of the 'MMT_package_id_byte' parameter are not the same as the service ID (S211: No), the MMTP packet with a packet ID of '0' is determined not to be an MMTP packet containing program data corresponding to the service ID. In this case, the transport processing unit 1102a acquires a PLT again (S212) and, by checking the acquired PLT, confirms the packet ID (let's call it x) of the MMTP packet transmitting MPT with the 'MMT_package_id_byte' parameter corresponding to the service ID (S213). Furthermore, the transport processing unit 1102a acquires the MMTP packet with a packet ID of 'x' from the input MMTP data sequence (S214) and acquires the MPT contained in the acquired MMTP packet (S215). Furthermore, based on the information contained in the acquired MPT, the MFU acquisition process is started.

Alternatively, the processing in S209-S211 may be omitted, and processing in S212-S215 may always be performed. In this case, processing time can be shortened when the program data corresponding to the service ID is stored in an MMTP packet other than packet ID '0'.

Here, we will explain the process of identifying the packet ID of the MMTP packet containing the program data corresponding to the service ID by checking the PLT, as described above, and obtaining the MPT. An MMTP packet with a packet ID of '0' indicates that it transmits a PA message. When multiple packages are multiplexed, as shown in Figure 14B, this PA message includes a PLT (Package List Table). The PLT contains a list of packet IDs of MMTP packets that transmit PA messages containing the MPTs of other packages. By checking the PLT, it is possible to identify the MMTP packet that transmits the PA message containing the MPT that serves as the entry point for each service, based on the package ID. Figure 14C shows an example of the PLT data structure. The location information for transmitting the PA message of the package indicated by the 'MMT_package_id_byte' parameter is specified by 'MMT_general_location_info()'.

Returning to the explanation of the operation sequence shown in Figure 14A, in the MFU acquisition process, the transport processing unit 1102a first refers to the MPT acquired in the processing of S210 or S215 and obtains the IP address and packet ID of the IP data flow transmitting the desired MFU (S216). It also obtains the presentation time of the MPU from the MPU timestamp descriptor placed in the MPT, and the layout number of the MPU from the MPU presentation area specification descriptor placed in the MPT (S217, S218). Furthermore, it acquires the MFU based on the acquired IP address and packet ID of the IP data flow (S219). Next, encoded video data, encoded audio data, etc., are extracted from the acquired MFU, and video/audio decoding processing is performed based on the control of the AV decoding processing unit 1102b. Finally, presentation processing is performed based on the acquired presentation time information and layout control information under the control of the presentation processing unit 1102h (S220).

Furthermore, if the PLT could not be obtained in processing S212, if the 'MMT_package_id_byte' parameter matching the service ID could not be confirmed in processing S213, or if the MMTP packet with packet ID 'x' could not be obtained in processing S215, etc., the program display processing (i.e., processing S216-S220) may be performed based on the data of the MMTP packet with packet ID '0' obtained in processing S210. In this case, it is advisable to display a message indicating that the program corresponding to the service ID selected by the user could not be displayed.

Through the above series of processes, the broadcast receiving device 100 of this embodiment is capable of performing channel selection (channel switching) operations. In particular, as explained using Figures 13A and 14A, during the initial channel scan or during a rescan for setting changes, a service list and IP-related information are created and stored in non-volatile memory such as ROM 103 or storage unit 110, making them constantly accessible. By referencing the service list and IP-related information stored in the non-volatile memory such as ROM 103 or storage unit 110 during channel selection (channel switching), the efficiency of the channel selection (channel switching) operation can be improved. That is, compared to cases where AMT and TLV-NIT are reacquired during channel selection (channel switching), the time from the start to the end of channel selection (channel switching) can be shortened.

[Remote control key setting process for broadcast receiving device]
Figure 15A shows an example of the appearance of a remote control (remote controller) 100R used to input operation instructions to the broadcast receiving device 100 in this embodiment. The remote control 100R shall include at least a power key 100R1, a numeric keypad 100R2, channel up/down keys 100R3, a menu key 100R4, an EPG key 100R5, a cursor key 100R6, a select key 100R7, and a color key 100R8. It may also include volume up/down keys, a network switching key, an input switching key, a recording key, a playback key, etc.

For example, in the operation sequence for channel selection shown in Figure 14A, during the process of S201, when instructing the broadcast receiving device 100 of this embodiment to switch channels using the remote control 100R, the following three methods may be used. The first method is to directly input and specify the service ID of the desired channel (service) by pressing the numeric keypad 100R2 multiple times. The second method is to cycle through channels (forward or backward) by repeatedly pressing the channel up/down key 100R3 as needed until the desired channel (service) is displayed. The third method is a so-called one-touch channel selection method, where the predetermined channel (service) associated with each key of the numeric keypad 100R2 is recalled by pressing the numeric keypad 100R2 only once. While the third method, one-touch channel selection, is a convenient channel selection method, it requires that the association of predetermined channels (services) with each key of the numeric keypad 100R2 be set in advance on the broadcast receiving device 100.

The broadcast receiving device 100 corresponding to the broadcasting system of this embodiment is capable of automatically setting the association based on control information contained in the digital broadcast wave received by the tuner/demodulation unit 131. That is, the broadcasting system of this embodiment provides a remote control key descriptor as a TLV-SI descriptor. The association setting can be performed by referring to the remote control key descriptor.

Figure 15B shows an example of the data structure of a remote control key descriptor. The 'service_id' parameter in the figure is the service ID that identifies the channel (service). The 'remote_control_key_id' parameter is the recommended value for the remote control button number to which the channel (service) identified by the service ID is assigned. Depending on the values of each parameter, the channel (service) identified by the 'service_id' parameter should be associated with the key specified by the 'remote_control_key_id' parameter on the numeric keypad 100R2.

Furthermore, if there are many channels (services) within the same network, the channels (services) may be assigned to keys other than the numeric keypad 100R2. For example, a specific channel (service) could be assigned to the color key 100R8. In this case, a numerical value corresponding to the 'remote_control_key_id' parameter should be assigned to each key of the color key 100R8 beforehand.

The remote control key descriptor may be described as a TLV-NIT descriptor. Therefore, for example, if the TLV-NIT obtained in process S103 of the channel scan operation sequence shown in Figure 13A is valid data, the association can be set by storing the description of the remote control key descriptor in the ROM 103 or storage unit 110 of the broadcast receiving device 100 in non-volatile memory, in conjunction with processes S105 to S107.

Furthermore, the association settings can be configured not only according to the description in the remote control key descriptor as described above, but also by the user appropriately assigning services of any channel to each key of the numeric keypad 100R2 according to their preference. Alternatively, both the association settings according to the description in the remote control key descriptor and the association settings assigned according to the user's preference can be simultaneously stored in the non-volatile memory of the broadcast receiving device 100, and only one of the settings can be used through menu operation or other selection. In this case, the association settings assigned according to the user's preference may be used preferentially. Also, depending on the value of the priority flag described in the remote control key descriptor, the association settings according to the description in the remote control key descriptor may be used preferentially over the association settings assigned according to the user's preference. The priority flag may be set using part or all of the 'reserved' parameter of the remote control key descriptor shown in Figure 15B, or by adding a new parameter. In this case, the value of the priority flag may be controllable for each service ID.

Furthermore, if the non-volatile memory stores association settings assigned by the user according to their preferences, the association settings corresponding to the contents of the remote control key descriptor may not be stored in the non-volatile memory. Alternatively, the non-volatile memory of the broadcast receiving device 100 may only store the association settings assigned by the user according to their preferences. If a remote control key descriptor is written to the TLV-NIT being received, the association settings corresponding to the contents of the remote control key descriptor may be used. If a remote control key descriptor is not written to the TLV-NIT being received, the association settings assigned by the user according to their preferences may be used.

Furthermore, the process of changing the association of each key on the numeric keypad 100R2 with a predetermined channel (service) according to the contents of the remote control key descriptor may be performed simultaneously for all services described in the service list descriptor on the network specified by TLV-NIT, or it may be performed only for some services. If the above process is performed only for some services, the previous settings may be retained for the other services. Also, if the 'service_id' parameter is a predetermined value (e.g., 999), the settings specified by the 'remote_control_key_id' parameter may be erased from the non-volatile memory of the broadcast receiving device 100.

In other words, the broadcast receiving device 100 of this embodiment makes it possible to set the association of a predetermined channel (service) with each key of the numeric keypad 100R2.

[Channel selection process for multi-channel programming]
In this embodiment of the broadcasting system, it is assumed that multi-channel broadcasting, where multiple programs are broadcast in parallel on a single channel (service), is possible. When broadcasting multiple programs simultaneously using multi-channel broadcasting, it is conceivable that the aforementioned one-touch channel selection is only possible for the main channel of the multi-channel broadcast, and not for the sub-channels of the multi-channel broadcast. That is, when selecting a sub-channel of the multi-channel broadcast, it is necessary to either directly input the service ID to specify it, or to first select the main channel of the multi-channel broadcast using one-touch channel selection, and then select the desired sub-channel by pressing the channel up/down key 100R3, which results in a cumbersome operation.

To solve the aforementioned problem, the broadcast receiving device 100 of this embodiment extends the one-touch tuning function, enabling direct tuning of subchannels in a multi-channel system by repeatedly pressing the numeric keypad 100R2, to which a predetermined service ID is assigned, multiple times within a predetermined time.

Let's explain using Figure 16A. For example, suppose the '1' key on the numeric keypad 100R2 of the remote control 100R is pre-assigned to the 011 channel service. In this case, if the channel selection operation is performed when multi-channel configuration is not active (see (A) in the figure), the 011 channel will be selected regardless of the number of times the '1' key is pressed. On the other hand, if the channel selection operation is performed when multi-channel configuration is active (see (B) in the figure), pressing the '1' key only once will select the 011 channel. If the '1' key is pressed again within a predetermined time after the first press, the 012 channel will be selected. Similarly, if the '1' key is pressed three times within a predetermined time, the 013 channel will be selected. If the '1' key is pressed again after a predetermined time has elapsed since the first press, the 011 channel may remain selected.

By enabling the operations described above, the broadcast receiving device 100 of this embodiment allows for direct selection of subchannels during multi-channel broadcasting with simpler operation.

Similarly, angle selection for multi-view compatible programs and selection of a predetermined video asset from multiple video assets may be performed by repeatedly pressing the numeric keypad 100R2 multiple times. As shown in Figure 16B, if the service ID of a multi-view compatible program is assigned to the '1' key on the numeric keypad 100R2 of the remote control 100R, pressing the '1' key once will select the multi-view compatible program and display the main view. Furthermore, pressing the '1' key again within a predetermined time after the first press will display subview 1 of the multi-view compatible program. Similarly, if the '1' key is pressed three times within a predetermined time, subview 2 of the multi-view compatible program will be displayed. If the '1' key is pressed again after a predetermined time has elapsed since the first press, the main view of the multi-view compatible program may remain displayed. Selection of a predetermined video asset from multiple video assets may also be possible using the same operation as described above.

By enabling the operations described above, the broadcast receiving device 100 of this embodiment allows for easier selection of angles for multi-view compatible programs and selection of a predetermined video asset from multiple video assets.

Furthermore, if one or more programs in a multi-channel broadcast are multi-view compatible programs or programs with multiple assets, only one of the aforementioned operations should be enabled and the other disabled. For example, if one or more programs in a multi-channel broadcast are multi-view compatible programs or programs with multiple assets, the operation of pressing the same key multiple times within a predetermined time frame should be assigned to the direct channel selection process for multi-channel broadcasts. Which operations to enable and disable can be predetermined, or it can be left to the user's choice.

[Controlling the screen layout of broadcast receiving equipment]
In this embodiment, the broadcast receiving device 100 is capable of screen layout control based on the LCT description. Figure 17A shows an example of the LCT data structure. Figure 17B shows an example of the MPU display area specification descriptor data structure.

In the LCT data structure described above, the `left_top_pos_x` and `right_down_pos_x` parameters represent the horizontal positions of the top-left and bottom-right of the region, respectively, as a percentage of the total number of pixels in the horizontal direction, with the left side of the full-screen display being `0` and the right side being `100`. The `left_top_pos_y` and `right_down_pos_y` parameters represent the vertical positions of the top-left and bottom-right of the region, respectively, as a percentage of the total number of pixels in the vertical direction, with the top side of the full-screen display being `0` and the bottom side being `100`. Furthermore, the `layer_order` parameter indicates the relative position in the depth direction of the region.

An example of assigning a layout to a layout number based on the settings of the aforementioned parameters is described below, along with the settings for each parameter.

Figure 17C shows the default layout settings of the broadcast receiving device 100 in this embodiment, which is an example of setting only one area on the entire screen. Figure 17D shows an example where the entire screen is divided into three areas, and each area is named "Area 0", "Area 1", and "Area 2". For example, if the number of pixels on the entire screen is 7680 horizontal pixels / 4320 vertical pixels, then "Area 0" is set in the range of (0,0) - (6143,3455) because the "left_top_pos_x" parameter is "0", the "left_top_pos_y" parameter is "0", the "right_down_pos_x" parameter is "80", and the "right_down_pos_y" parameter is "80". Similarly, 'Region 1' is set to the range (6144, 0) - (7679, 4319), and 'Region 2' is set to the range (0, 3456) - (6143, 4319).

Figure 17E shows an example of setting three regions, similar to Figure 17D. Region 0 is set to the range (0,0)–(7679,4319), while Regions 1 and 2 are positioned in front of Region 0, within the same range as described above, according to the setting of the 'layer_order' parameter. Figure 17F shows an example where Region 0 is set on device 0 (the default device: in this embodiment, the broadcast receiving device 100) and Region 1 is set on device 1 (in this embodiment, the mobile information terminal 700).

As described above, in the broadcasting system of this embodiment, by using an LCT, it becomes possible to control the screen layout so that multimedia services are displayed on the receiver as intended by the service provider.

Furthermore, in areas where program video or data screens are not displayed due to the aforementioned screen layout control, a predetermined background color specified by a background color descriptor described in the LCT may be displayed. Also, if the LCT does not contain the background color descriptor, if the broadcast receiving device 100 fails to correctly acquire the background color descriptor, or if the predetermined background color specified by the background color descriptor cannot be displayed due to hardware limitations, the video display device 100 may display a predetermined pattern in the area. The area may also be used as a notification display area from the video display device 100 to the user. The notification may contain any information.

Furthermore, any fractional parts of the decimal point that occur when splitting the screen according to the settings of parameters such as 'left_top_pos_x' can be rounded up or down. Rounding to the nearest integer (or rounding to zero in binary) is also acceptable. For example, if the total screen resolution is 7680 pixels / 4320 vertical pixels, and the parameters for 'Region 0' are '0' for 'left_top_pos_x', '0' for 'left_top_pos_y', '51' for 'right_down_pos_x', and '51' for 'right_down_pos_y', then 'Region 0' may be set to the range (0,0) - (3916,2203) by rounding up, or to the range (0,0) - (3915,2202) by rounding down. Furthermore, considering macroblocks during video compression, rounding up/down may be performed in units of 8 pixels or 16 pixels, etc. This processing enables efficient region setting based on LCT and resolution conversion processing of multimedia content within the region.

Alternatively, the setting values of parameters such as 'left_top_pos_x' may be restricted to only multiples of 5 or 10 within the range of '0' to '100'. In this case as well, the range setting can be suitably performed.

The content displayed in each of the aforementioned areas is specified by the MPU display area descriptor shown in Figure 17B. The content of the MPU, whose sequence number is specified by the 'mpu_sequence_number' parameter in the figure, is associated with the LCT description by the 'layout_number' and 'regiment_number' parameters.

Furthermore, within the first 'for' loop of the MPU display area specification descriptor, multiple 'layout_number' and 'regiment_number' parameters may be described for a single 'mpu_sequence_number' parameter, allowing the user to select which description to follow for layout control. For example, within the first 'for' loop, if the parameters 'layout_number1', 'regiment_number1', 'layout_number2', and 'regiment_number2' are specified for a predetermined 'mpu_sequence_number' parameter, the user can be given the option to choose whether to control the layout of the MPU specified by the 'mpu_sequence_number' parameter based on the 'layout_number1' and 'regiment_number1' parameters, or based on the 'layout_number2' and 'regiment_number2' parameters. In this way, the user can control the layout of the video program according to their preferences.

[Exception handling for screen layout control of broadcast receiving devices]
In the broadcast receiving device 100 of this embodiment, even when the screen layout area is controlled by the aforementioned LCT, if the user instructs the display of the EPG screen, etc., it is possible to perform screen layout control that ignores the contents of the LCT as an exception. Figure 18A shows an example of the operation of the exception handling for screen layout control based on the LCT.

When the LCT description performs screen layout control similar to that shown in Figure 17D, and the broadcast program video is displayed in "Area 0," and broadcast content such as program linkage data linked to the broadcast program is displayed in "Area 1" and "Area 2," if the user instructs the display of the EPG screen using a remote control (not shown), the broadcast receiver 100 of this embodiment will, as shown in Figure 18A(A), revert the screen layout settings to the default settings (i.e., the same screen layout control as in Figure 17C) regardless of the LCT description, and control the display of the EPG screen across the entire screen. Furthermore, if the user instructs the end of the EPG screen display, the screen layout control according to the LCT description will be re-executed.

By performing the aforementioned control, it is possible to display the EPG screen larger and improve readability compared to the case where the EPG screen is displayed while maintaining the screen layout area control as shown in Figure 18A(B).

Furthermore, the exception handling for the screen layout control described above is not limited to the display of the EPG screen; as shown in Figure 18B, it may also be applied when displaying various setting screens of the broadcast receiving device 100 as sub-screens or in dual-screen mode.

In the case of the recording settings screen shown in Figure (A), the display area for broadcast content is changed from the entire screen to only the sub-screen portion in the lower right corner of the screen. Similarly, in the case of the dual-screen display shown in Figure (B), the display area for broadcast content is changed from the entire screen to only the split-screen portion in the middle left of the screen. In either case, since the display area for displaying broadcast content is narrower compared to when the entire screen is used, it is not visually desirable to maintain screen layout area control within the display area (i.e., to divide the area and display multiple broadcast contents simultaneously). Therefore, in the broadcast receiving device 100 of this embodiment, in the above situation, only the broadcast content of "Area 0" is selected and displayed in the display area. Alternatively, depending on the previous area selection status, broadcast content from "Area 1" or "Area 2" may be selected and displayed.

By implementing the aforementioned control, it becomes possible to improve the readability of broadcast content compared to displaying various broadcast content while maintaining screen layout area control. The same applies to sub-window displays in the recorded program list screen and browser displays of internet content.

[Aspect ratio conversion processing of video signals]
The aspect ratio of video signals in television broadcasting services includes '4:3', which was used in conventional SDTV, '16:9', which is used in recent HDTV, and '21:9', which is suitable for movie content, among others. In the broadcasting system of this embodiment, the aspect ratio information of the video signal may be described by a video component descriptor. Figure 19A shows an example of the data structure of a video component descriptor. In the figure, the 'video_aspect_ratio' parameter is information regarding the aspect ratio of the video signal. Figure 19B shows an example of the meaning of the 'video_aspect_ratio' parameter. Further aspect ratios different from those shown may be assigned.

On the other hand, the aspect ratio of the display unit of a television receiver capable of receiving the aforementioned television broadcasting service (such as the broadcasting receiver 100 in this embodiment) is generally 16:9. That is, when displaying video content with an aspect ratio of 4:3 or 21:9 on a typical television receiver, aspect ratio conversion processing may be performed.

Whether or not to perform the aspect ratio conversion process can be determined by comparing the specifications of the monitor unit 162 of the broadcast receiving device 100 with the 'video_aspect_ratio' parameter of the video component descriptor. For example, if the aspect ratio of the monitor unit 162 of the broadcast receiving device 100 is '16:9' (3840 pixels horizontally x 2160 pixels vertically, etc.), then if the value of the 'video_aspect_ratio' parameter is '0', '2', or '3', the aspect ratio conversion process should not be performed, and if it is '1' or '5', the aspect ratio conversion process should be performed. Furthermore, for example, if the aspect ratio of the monitor unit 162 of the broadcast receiving device 100 is "21:9" (5040 pixels horizontally x 2160 pixels vertically, etc.), then if the value of the "video_aspect_ratio" parameter is "0" or "5", aspect ratio conversion processing should not be performed, while if it is "1", "2", or "3", aspect ratio conversion processing should be performed.

Figures 19C and 19D show an example of aspect ratio conversion processing when the aspect ratio of the monitor unit 162 of the broadcast receiving device 100 is "16:9" and the value of the "video_aspect_ratio" parameter is "5". When displaying video content with an aspect ratio of "21:9" on the monitor unit 162 with an aspect ratio of "16:9", the aspect ratio may be converted to "16:9" by adding black bars to the top and bottom of the video content with an aspect ratio of "21:9" (display A in the figure). In this way, it is possible to display the entire original video content without distortion. Alternatively, only the central part of the video content with an aspect ratio of "21:9" may be cropped and displayed on the monitor unit 162 (display B in the figure). In this way, it is possible to display the main part of the original video content in a larger size. Alternatively, black bars can be added to the top and bottom of the 21:9 aspect ratio video content, and the central portion can be further cropped (displayed as C in the diagram). This allows for a larger display of the original video content. Alternatively, the left and right edges of the 21:9 aspect ratio video content can be compressed to display the entire content (displayed as D in the diagram). This allows for a larger display of the entire original video content, with the main portion displayed without distortion. Furthermore, black bars can be added to the top and bottom of the 21:9 aspect ratio video content, and the left and right edges can be compressed to display the entire content (displayed as E in the diagram). This allows for a larger display of the entire original video content, with less distortion at the left and right edges.

The user can choose how the aspect ratio conversion process is performed through menu settings or similar. Alternatively, it can be switched by pressing a designated key on a remote control. Note that the aforementioned aspect ratio "21:9" includes ratios that are roughly "21:9," such as the so-called Cinemascope "2.35:1." The same applies to other aspect ratio values.

[EPG display on broadcast receiving device]
In this embodiment of the broadcasting system, time-series information regarding events (so-called programs) included in each service constituting the broadcasting network is transmitted via MH-EIT. The MH-EIT shown in Figure 7E is identified into two classes by a table ID (corresponding to the 'table_id' parameter in the figure) and is capable of displaying information on the current/next event of its own TLV stream and schedule information for each event in its own TLV stream. The broadcasting receiver 100 in this embodiment can create an EPG screen by referring to the MH-EIT, etc., and identifying it by a service ID (corresponding to the 'service_id' parameter in the figure), thereby acquiring information such as the start time and broadcast time of each event. The created EPG can then be superimposed on video information, etc., by the video synthesis unit 161 and displayed on the monitor unit 162.

Figure 20A shows an example of the EPG screen in the broadcast receiving device 100 of this embodiment. The EPG screen 162a is a matrix shape with the vertical axis representing time and the horizontal axis representing service ID (channel), displaying detailed information of broadcast programs broadcast on each channel during each time period. The detailed information 162a1 for each broadcast program mainly consists of a title area 162a2 and a detailed description area 162a3. The detailed information 162a1 for each broadcast program may display program information, etc., that has been described and distributed in MH-short format event descriptors or MH-extended format event descriptors. If the amount of program information etc. described in each descriptor is large, it may be displayed in abbreviated form under normal circumstances, and all program information may be displayed via a pop-up or the like when selected using the remote control (not shown in the figure). Alternatively, when selected, the program information etc. described in each descriptor may be transmitted to the mobile information terminal 700 during linked operation, and the mobile information terminal 700 may be instructed to display it on the display unit 741.

The title area 162a2 of the detailed information 162a1 for each broadcast program displays the program title and symbols representing the program's attributes. These symbols representing the program's attributes may include, for example, symbols/characters indicating a new program or symbols/characters indicating a rebroadcast program. Alternatively, it could be a symbol representing "data," indicating that the program supports data broadcasting via the broadcast service. It could also be a symbol representing "NetWork," indicating that content and applications related to the broadcast program can be obtained from the network. Furthermore, the symbols representing the program's attributes may be replaced by differentiating the background color of the detailed information 162a1 or by enclosing the display area of the detailed information 162a1 with a thick border.

Furthermore, even if the control information (messages, tables, descriptors, etc.) in the broadcasting system of this embodiment indicates that content and applications related to the broadcast program can be obtained from the network, if access to the server devices on the network is not possible, such as when a LAN cable is not connected to the LAN communication unit 121 of the broadcasting receiver 100, the system may be controlled not to display the symbol 162a4 representing "Network".

Furthermore, if the broadcast program is a distributed program delivered via the Internet 200 and cannot be obtained solely from the broadcast signal, and if, as described above, the broadcast receiving device 100 is unable to access the server devices on the network, the detailed information 162b1 portion displayed on the EPG screen 162b may be controlled to gray out, as shown in Figure 20B. That is, the detailed information of a distributed program that cannot be viewed is not displayed. Alternatively, the background color of the detailed information 162b1 may be differentiated from the others as an alternative to the graying-out process. Alternatively, a message such as "This program cannot be viewed" may be displayed in the detailed description area 162a3 of the distributed program. When the detailed information 162b1 is selected using a remote control (not shown), the user may be notified via a pop-up or the like that the broadcast receiving device 100 is unable to access the server devices on the network, or that the distributed program associated with the detailed information 162b1 cannot be viewed.

Through the aforementioned controls, the broadcast receiving device 100 can provide the user with program information for each broadcast program in a more user-friendly format, depending on the network connection status.

Figure 20C shows another example of the EPG screen in the broadcast receiving device 100 of this embodiment. In the figure, 'M1 TV', 'M2 Broadcast', 'M3 Channel', 'M4 TV', 'TV M5', etc., are the names of the broadcasting stations for each channel. In particular, the 'M2 Broadcast' station is assumed to simultaneously provide broadcast programs distributed via broadcast waves and distributed programs distributed via the Internet 200 (information 162c1 in the frame indicated as 'Internet Broadcast' in the figure).

As shown in the figure, if there are channels that only have broadcast programs distributed via the Internet 200, under normal circumstances, the system is controlled to display information for all channels (including information 162c1) as shown in the EPG screen 162c of Figure (A). On the other hand, if the broadcast receiving device 100 is unable to access the server devices on the network, the system may be controlled not to display information for "M2 broadcasting (network broadcasting)" channels that only have broadcast programs distributed via the Internet 200 (information 162c1 in Figure (A)), as shown in the EPG screen 162d of Figure (B).

Through the aforementioned controls, users of the broadcast receiving device 100 will no longer need to check information about channels they cannot view.

[Emergency warning broadcast display on broadcast receiving device]
The broadcast receiving device 100 of this embodiment is capable of receiving an emergency warning broadcast when the emergency warning broadcast activation control signal bit of the TMCC signal included in the transmission data including the TLV stream changes from '0' to '1'.

The aforementioned emergency warning broadcast may be provided as a broadcast program on a dedicated channel (service ID), as a full-screen application, or as text information via text overlay. When the emergency warning broadcast is provided as text information via text overlay, it is preferable to display the text information regardless of the state of the broadcast receiving device 100 immediately before receiving the emergency warning broadcast. That is, as shown in Figure 21, if a user is watching a regular broadcast program and the program screen 162e of the broadcast program is displayed on the monitor unit 162 when an emergency warning broadcast is received, the text information 162e1 from the emergency warning broadcast is superimposed on the program screen 162e. Similarly, if a user instructs the display of the EPG screen and the EPG screen 162f is displayed on the monitor unit 162 when an emergency warning broadcast is received, the text information 162f1 from the emergency warning broadcast is superimposed on the EPG screen 162f.

Through the aforementioned control, the broadcast receiving device 100 of this embodiment can prevent users from missing important text information based on an emergency warning broadcast, even when they are selecting and displaying the EPG screen, various settings screens, recorded program list screen, internet browser, etc. This control may also be applied to regular text information displayed on screens that are not related to emergency warning broadcasts.

Furthermore, if the emergency warning broadcast is provided as a program on a dedicated channel (service ID), the system may automatically select the channel (service ID) of the emergency warning broadcast regardless of the channel (service ID) of the program currently being viewed. Also, if the emergency warning broadcast is provided as a program on a dedicated channel (service ID) or as an application, the cooperation function execution unit 1103 may control the distribution of the emergency warning broadcast program or application to a cooperating external mobile terminal device (in this embodiment, a mobile information terminal 700, etc.).

Furthermore, if the broadcast receiving device 100 is not powered on when the emergency warning broadcast is distributed, control may be implemented to automatically power on the broadcast receiving device 100. Alternatively, control may be implemented to send a notification to a portable information terminal 700 that has a history of coordinating with the broadcast receiving device 100, informing it that the emergency warning broadcast has begun.

Through the aforementioned control, the broadcast receiving device 100 of this embodiment makes it possible to avoid missing the display of important broadcast programs and application videos based on the emergency warning broadcast.

[Exception handling for display control]
In this embodiment, if the broadcast receiving device 100 cannot acquire data transmitted via a path other than the TLV stream among the data constituting the same package, it may perform exception handling such as the following.

As explained using Figure 7A, in the broadcasting system to which the broadcasting receiver 100 of this embodiment corresponds, data acquired from the TLV stream and data acquired from routes other than the TLV stream can be included in the same package based on location information stored in the MPT (see Figure 7C). However, data transmitted via data transmission routes other than the TLV stream, as indicated by the location information (for example, IPv4 data flow or IPv6 data flow of a communication line, or MPEG2-TS of broadcasting), is acquired by a reception function separate from the TLV/MMT stream reception function. Therefore, even when the broadcasting receiver 100 is operating, there may be situations where data cannot be acquired from these transmission routes, such as when the reception function of these transmission routes is not operating, when the reception function itself is operating but the relay device on the transmission route is not operating, when there is no wired or wireless connection to these transmission routes, or when the broadcasting receiver 100 is installed in an environment where these transmission routes cannot be connected in the first place.

Under these circumstances, if the MPT receives an event indicating that the location information stored therein should include data acquired from the TLV stream and data acquired from routes other than the TLV stream in the same package, the broadcast receiving device 100 of this embodiment may perform the following actions.

For example, if the LCT (Landing Card Terminal) has multiple areas set up on the screen, as shown in Figures 17D and 17E, and the program video based on data acquired from the TLV stream is displayed in "Area 0," and content based on data acquired from transmission paths other than the TLV stream is displayed in "Area 1" and "Area 2," and if data from transmission paths other than the TLV stream that should be displayed in "Area 1" and "Area 2" cannot be acquired, the display of the multiple area layout specified by the LCT may be prohibited. Specifically, even if the LCT is received, the default layout display shown in Figure 17C, with the program video based on data acquired from the TLV stream displayed in "Area 0," should remain, and the display should not transition to the multiple area layout display as shown in Figures 17D and 17E. Furthermore, even if a command to change from the default layout to the layout shown by the LCT is input to the operation input unit 170 of the broadcast receiving device 100, the display may remain in the default layout display shown in Figure 17C, or switch to another data broadcasting screen, thus preventing a transition to the multiple area layout display as shown in Figures 17D and 17E.

Furthermore, if the LCT has set up multiple areas on the screen as shown in Figures 17D and 17E, and the program video based on data acquired from the TLV stream is displayed in 'Area 0', and content based on data acquired from a transmission path other than the TLV stream is displayed in 'Area 1' and 'Area 2', then another example of operation in the case where data from a transmission path other than the TLV stream that should be displayed in 'Area 1' and 'Area 2' cannot be acquired is to first display the display frames for the multiple areas shown in Figures 17D and 17E indicated by the LCT, and then display the background color or a predetermined still image for 'Area 1' and 'Area 2'. If data from a transmission path other than the TLV stream indicated by the MPT's location information cannot be acquired even after a predetermined time has elapsed, the display may be switched back to the default layout display state shown in Figure 17C. In this case, it is preferable that the program video based on data acquired from the TLV stream continues to be displayed in 'Area 0' of each layout, even when changing from the layout in Figure 17C to the layouts in Figures 17D and 17E, and vice versa, so that the user can continue watching the program video.

Furthermore, if data from transmission paths other than the TLV stream that should be displayed in "Area 1" and "Area 2" cannot be acquired, and the program video based on data acquired from the TLV stream is displayed in "Area 0" of the default layout display shown in Figure 17C, it is possible that the operation of various communication functions and various reception functions of the broadcast receiving device 100 of this embodiment may start, or the communication environment/communication status of the various communication functions or the reception environment/reception status of the various reception functions may change, making it possible to acquire data from transmission paths other than the TLV stream that should be displayed in "Area 1" and "Area 2". In this case, the broadcast receiving device 100 of this embodiment may immediately switch from the default layout display shown in Figure 17C to a multi-area layout as shown in Figures 17D and 17E as indicated by LCT, and switch to displaying program video based on data acquired from the TLV stream in "Area 0" and content based on data acquired from transmission paths other than the TLV stream in "Area 1" and "Area 2". Alternatively, the layout change may not be performed immediately. Instead, the change may be executed only after a command to change from the default layout to the layout indicated by the LCT is received from the operation input unit 170. In this case, it is preferable to notify the user that the layout change is possible via an OSD display or similar means.

[Copyright protection function]
In the digital broadcasting system to which the broadcast receiving device 100 of this embodiment corresponds, the MPT, etc., may transmit copy control information along with the information to indicate the copy control status of the content referenced by the MPT, etc., such as, for example, "unlimited copying allowed" (which may be divided into two types: "unlimited copying allowed and encryption processing required during storage and output" and "unlimited copying allowed and encryption processing not required during storage and output"), "only one generation of copying allowed", "a predetermined number of copies allowed" (for example, 9 copies allowed + 1 move allowed is the so-called "Dubbing 10"), or "copy prohibited". In this case, the broadcast receiving device 100 of this embodiment may be configured to control the storage of the content in the storage unit 110, recording to a removable recording medium, output to an external device, copying to an external device, moving to an external device, etc., according to the copy control information.

Furthermore, the storage process may include not only the internal storage unit 110 of the broadcast receiving device 100, but also removable recording media and external devices that have undergone protection processing such as encryption so that they can be played back only by the broadcast receiving device 100. Specifically, this includes, for example, external recording devices such as HDDs connected to the expansion interface unit 124 that have been made capable of recording and playback only by the broadcast receiving device 100.

<Content Copy Control>
A specific example of content copy control processing based on the copy control information is described below.

First, if the copy control information included in the MPT, etc., indicates "unlimited copying," the broadcast receiving device 100 of this embodiment may perform storage in the storage unit 110, recording to a removable recording medium, output to an external device, copying to an external device, moving to an external device, etc., without restriction. However, if the control based on the copy control information is divided into "unlimited copying and encryption processing required during storage and output" and "unlimited copying and encryption processing not required during storage and output," and it indicates "unlimited copying and encryption processing required during storage and output," then storage in the storage unit 110, recording to a removable recording medium, output to an external device, copying to an external device, moving to an external device, etc., can be performed without restriction, but encryption processing is required in all cases.

Furthermore, if the copy control information included in the MPT, etc., indicates "only one generation can be copied," the broadcast receiving device 100 in this embodiment may enable encrypted storage in the storage unit 110, or recording to a removable recording medium that has undergone protection processing such as encryption so that it can only be played back by the broadcast receiving device 100. Also, when outputting the stored content to an external device for viewing, it shall be output encrypted along with copy control information indicating "copy prohibited." Furthermore, so-called move processing to an external device (a process in which the content is copied to an external device, and the content in the storage unit 110 of the broadcast receiving device 100 is rendered unplayable by erasure processing, etc.) is also possible.

Furthermore, if the copy control information included in the MPT, etc., indicates "copyable a predetermined number of times," the broadcast receiving device 100 in this embodiment may enable the process of encrypting and storing the content in the storage unit 110, or recording it to a removable recording medium that has undergone protection processing such as encryption so that it can only be played back by the broadcast receiving device 100. Also, when outputting the stored content to an external device for viewing, it shall be output encrypted along with copy control information indicating "copy prohibited." Furthermore, it may be possible to enable a predetermined number of copies and moves to an external device. In the case of the so-called "Dubbing 10" provision, it is possible to perform nine copies and one move to an external device.

Furthermore, if the copy control information included in the MPT, etc., indicates "copy prohibited," the broadcast receiving device 100 in this embodiment prohibits storage (copying) to the storage unit 110, etc. However, the broadcast receiving device 100 may be configured to have a "temporary storage" mode that allows retention in the storage unit 110, etc., only for a predetermined time or a predetermined time specified by the control information included in the broadcast signal (for example, by an MH-Expire descriptor or content usage control descriptor, etc.). In this case, even if the copy control information included in the MPT, etc., indicates "copy prohibited," the broadcast receiving device 100 allows temporary retention of the content in the storage unit 110, etc. When outputting content with "copy prohibited" copy control information included in the MPT, etc., for viewing to an external device, it shall be encrypted and output along with the "copy prohibited" copy control information.

Furthermore, the output for viewing to the aforementioned external device can be performed via the video output unit 163 and audio output unit 166 of the broadcast receiving device 100 in this embodiment, or via the digital I/F unit 125 or LAN communication unit 121, etc. The copying or moving process to the aforementioned external device can also be performed via the digital I/F unit 125 or LAN communication unit 121, etc.

Figure 22A shows an example of the data structure of the content copy control descriptor in the broadcasting system of this embodiment. The parameter 'digital_recording_control_data' in the figure represents digital copy control information, indicating information that controls the copy generation of the content. Figure 22B shows an example of the parameter values and their meanings for the digital copy control information. For example, a value of '00' indicates 'unlimited copying allowed', a value of '01' indicates that it can be defined by the service provider, a value of '10' indicates 'only one copy allowed', and a value of '11' indicates 'copy prohibited'. Figure 23 shows an example of the data structure of the content usage control descriptor in the broadcasting system of this embodiment. The parameter 'copy_restriction_mode' in the figure represents the copy restriction mode, indicating whether a limited number of copies are allowed.

In this embodiment, the broadcast receiving device 100 is configured to execute a storage process that allows for a predetermined number of copies, as determined in advance by the broadcaster, when the digital copy control information is "01". Alternatively, it may be configured to execute a storage process that allows for a predetermined number of copies, as determined in advance by the broadcaster, when the digital copy control information is not "11" and the copy restriction mode indicates that a limited number of copies are allowed. In this case, the number of copies allowed for each content item may be specified by using part or all of the "reserved_future_use" parameter of the digital content usage descriptor.

Through the above processing, the broadcast receiving device 100 of this embodiment becomes capable of realizing the aforementioned "allowing for a predetermined number of copies" content copy control.

Furthermore, the 'retention_mode' parameter in the content usage control descriptor shown in Figure 23 is a temporary storage control bit, indicating whether or not temporary storage of the target content is permitted when the digital copy control information indicates 'copy prohibited'. The 'retention_state' parameter is the temporary storage allowance time, indicating the temporary storage allowance time when the temporary storage allowance bit permits temporary storage of the target content.

In the broadcast receiving device 100 of this embodiment, by referring to the temporary storage control bit and the temporary storage allowance time information, it becomes possible to control whether or not temporary storage is permitted and the storage time when the digital copy control information for each content indicates "copy prohibited".

The process described above allows for appropriate content protection based on the copy control information associated with the content.

<Content Output Control>
Next, a specific example of the process for controlling the output of content to external devices is described below.

In the content usage control descriptor shown in Figure 23, the 'image_construct_token' parameter is a resolution limit bit, indicating whether or not image quality limiting is necessary when outputting content to an external device. If the resolution limit bit indicates that image quality limiting is necessary, the broadcast receiving device 100 in this embodiment will limit the image quality of the target content when outputting the target content to an external device. However, when storing content in the storage unit 110, etc., the image quality limiting may not be necessary. The image quality limiting may include, for example, converting the received (or stored) UHD (7680 pixels x 4320 pixels) video content to SHD (3840 pixels x 2160 pixels) video and outputting it, or converting HD (1920 pixels x 1080 pixels) video to SD (640 pixels x 480 pixels) video and outputting it. Furthermore, the extent to which the image quality of the target content is limited, that is, the resolution to which the image quality will be limited, may be specified by using part or all of the 'reserved_future_use' parameter of the digital content usage descriptor.

As described above, for example, some or all of the 'reserved_future_use' parameter may be used to prepare frame rate limiting bits and pixel resolution limiting bits, thereby controlling the frame rate limit and pixel resolution limit when outputting content to an external device. If the frame rate limiting bit indicates that frame rate limiting is necessary, the broadcast receiving device 100 in this embodiment shall limit the frame rate of the target content when outputting the target content to an external device. For example, it may convert video content with a frame rate of 120 Hz to a frame rate of 60 Hz before outputting. Furthermore, if the pixel resolution limiting bit indicates that pixel resolution limiting is necessary, the broadcast receiving device 100 in this embodiment shall limit the resolution of each pixel of the target content when outputting the target content to an external device. For example, it may convert each pixel of video content, where each pixel is composed of 12 bits, to 8 bits before outputting.

Furthermore, resolution limit control flags, frame rate limit control flags, and pixel resolution limit control flags may be provided by using some or all of the 'reserved_future_use' parameter, and whether or not to perform the image quality limit, frame rate limit, or pixel resolution limit may be controlled according to the resolution limit control flag, frame rate limit control flag, or pixel resolution limit control flag. For example, if the resolution limit control flag indicates that resolution limit control should be performed according to the interface specification, the control may be such that the image quality limit is not performed if the interface outputting the target content is equipped with a predetermined content protection technology, and the image quality limit is performed if it is not equipped with the predetermined content protection technology.

Specifically, for example, if the digital interface unit 125 is an HDMI interface and the target content is output to an external device connected to the HDMI interface, the output of the target content will be performed without image quality limitations if the HDMI interface of the external device supports HDCP (High-bandwidth Digital Content Protection) version 2.2 or later. If the HDCP version of the external device's HDMI interface is less than 2.2, the output of the target content will be performed with image quality limitations. In other words, the control over whether or not to apply image quality limitations to the target content will be based on whether the interface outputting the target content has a predetermined content protection technology, or, if it does have such a technology, on the version of that content protection technology. Note that if the resolution limitation control flag does not indicate that resolution limitation control should be performed according to the interface specifications, the presence or absence of image quality limitations may be controlled solely based on the resolution limitation bit. Similar processing may be applied to the frame rate limitation control flag and the pixel resolution limitation control flag.

Furthermore, regarding the copying of content to external devices via the LAN communication unit 121, where the aforementioned copy control information indicates copy restrictions such as "copyable only once," "copyable a predetermined number of times," or "copy prohibited," copying is permitted only if the IP address of the external device, which is the destination of the packet transmitted from the broadcast receiving device 100, is within the same subnet as the IP address of the broadcast receiving device 100. If the IP address of the external device is outside the same subnet as the IP address of the broadcast receiving device 100, copying may be prohibited. Content with copy control information indicating "unlimited copying and encryption processing required during storage and output" may be treated similarly.

Similarly, regarding content that indicates copy restrictions such as "only one generation can be copied," "a predetermined number of copies can be made," or "unlimited copies are allowed, but encryption processing is required during storage and output," after it has been stored in the storage unit 110, the move and copy processes to external devices via the LAN communication unit 121 are permitted only if the IP address of the external device, which is the destination of the packets transmitted from the broadcast receiving device 100, is within the same subnet as the IP address of the broadcast receiving device 100. If the IP address of the external device is outside the same subnet as the IP address of the broadcast receiving device 100, these processes may be prohibited.

Furthermore, as a general rule, video and audio output for viewing content stored in the storage unit 110 of the broadcast receiving device 100 is only possible if the IP address of the external device to which the transmitted packets from the broadcast receiving device 100 are destined is within the same subnet as the IP address of the broadcast receiving device 100. If the IP address of the external device is outside the same subnet as the IP address of the broadcast receiving device 100, it is prohibited. However, if the external device has been connected within the same subnet as the IP address of the broadcast receiving device 100 within a predetermined period, and has been registered (paired) as a device capable of viewing content even outside the same subnet as the IP address of the broadcast receiving device 100, then the system may be configured to allow video and audio output for viewing content stored in the storage unit 110 of the broadcast receiving device 100 to that external device, even if the IP address of the external device is outside the same subnet as the IP address of the broadcast receiving device 100. In this case, the video and audio output for viewing will be performed with the content encrypted.

However, the encryption process may be controlled according to the value of the 'encryption_mode' parameter in the content usage control descriptor shown in Figure 23. That is, if the value of the 'encryption_mode' parameter indicates that IP interface output protection is required, the encryption process will be performed; if it indicates that IP interface output protection is not required, the video and audio output for viewing will be performed without encryption. Furthermore, if the value of the 'encryption_mode' parameter indicates that IP interface output protection is required, a range of IP addresses of external devices capable of performing the video and audio output for viewing without encryption may be specified by using part or all of the 'reserved_future_use' parameter in the content usage control descriptor. That is, for predetermined IP addresses, video and audio output for viewing will be possible even if the IP address is not within the same subnet as the IP address of the broadcast receiving device 100.

Furthermore, the period during which the registration process (pairing) is valid may be specified by using part or all of the 'reserved_future_use' parameter of the content usage control descriptor. In this case, if the date and time the registration process (pairing) of the external device is performed is within the specified period, the system may allow video and audio output for viewing to the external device, even if the external device is outside the same subnet as the IP address of the broadcast receiving device 100. If it is outside the specified period, the system may control the system to not allow it.

Furthermore, the aforementioned processes of moving, copying, and outputting content to external devices via the LAN communication unit 121 may be controlled according to the value of the 'remote_view_mode' parameter in the content usage control descriptor. That is, if the value of the 'remote_view_mode' parameter does not allow remote viewing of the target content, the system may be controlled to prohibit all processes of moving, copying, and outputting content to external devices via the LAN communication unit 121.

The process described above ensures appropriate content protection even when outputting content to external devices.

<Exception handling for content copy control 1>
In the data structure of the content copy control descriptor shown in Figure 22A, the first digital copy control information (the 'digital_recording_control_data' parameter located immediately after 'descriptor_length') is the copy generation control information for the entire content, and the second digital copy control information (the 'digital_recording_control_data' parameter located immediately after 'component_tag') is the copy generation control information for each component that constitutes the content. Each component is specified by the 'component_tag' parameter.

In the broadcasting system of this embodiment, when controlling the copy generation of the entire content (program), only the first digital copy control information is described in the content copy control descriptor, and the copy generation is controlled by the first digital copy control information. On the other hand, when controlling the copy generation for each component constituting the content, both the first digital copy control information and the second digital copy control information are described in the content copy control descriptor, and the copy generation is controlled. Furthermore, when controlling the copy generation for each component constituting the content, a situation may arise where the descriptions of the first digital copy control information and the second digital copy control information described in the content copy control descriptor do not match. In the aforementioned situation, the broadcasting receiving device 100 of this embodiment should perform the operation shown below.

First, the first operational example is a method of controlling the system to operate based on the copy generation control indicated in the first digital copy control information when the descriptions in the first digital copy control information and the second digital copy control information do not match. In this case, a simple copy generation control common to each component constituting the same content becomes possible.

Next, the second example of operation is a method of controlling the system to operate based on the copy generation control indicated in the second digital copy control information when the descriptions in the first digital copy control information and the second digital copy control information do not match. In this case, even for components that constitute the same content, different copy generation controls are possible for each component, that is, more precise copy generation control becomes possible.

Furthermore, a third example of operation is a method of controlling the system to operate based on the stricter condition of the two different digital copy control information when the descriptions of the first and second digital copy control information do not match. For example, if one is "unlimited copying allowed" and the other is "only one generation of copying allowed," the system will follow the "only one generation of copying allowed" information. Or, if one is "a predetermined number of copies allowed" and the other is "copying prohibited," the system will follow the "copying prohibited" information. Or, if both are "a predetermined number of copies allowed," the system will follow the information of the smaller number of copies allowed, which will be specified separately. In this case, more precise copy generation control becomes possible.

By performing the above processing, the broadcast receiving device 100 of this embodiment can operate effectively even when two different digital copy control information entries are present in the content copy control descriptor.

<Exception handling for content copy control 2>
As explained using Figure 7A, in the digital broadcasting system to which the broadcast receiving device 100 of this embodiment is compatible, due to location information in the MPT (see Figure 7C), data acquired via a different route (IPv4, IPv6, MPEG2-TS, URL, etc.) than the data acquired via the TLV stream of the broadcast route may be included in the same package and event as the data acquired via the TLV stream. In this case, content protection when copy control information is included in the MPT, etc. will be explained.

First, if copy control information is included in MPT, etc., data included in the same package and event in the location information may be controlled according to the copy control information included in the TLV stream, even if the data was acquired via a different route (IPv4, IPv6, MPEG2-TS, URL, etc.) than the data acquired via the broadcast route's TLV stream. Based on this copy control information, the copy control status of the specified content can be set as follows: 'Unlimited copying allowed' (which may be divided into two types: 'Unlimited copying allowed and encryption required during storage and output' and 'Unlimited copying allowed and encryption not required during storage and output'), 'Copying allowed for one generation only', 'Copying allowed a predetermined number of times' (for example, 9 copies allowed + 1 move allowed is the so-called 'Dubbing 10'), 'Copy prohibited', etc.

Here, if the location information indicates the data's position, and that location includes MPEG2-TS data transmitted in another digital broadcast signal, then that MPEG2-TS data is also broadcast in that other digital broadcast signal, associated with copy control information. Therefore, the question arises as to which information should be used to control the copy of that MPEG2-TS data, and how (should it follow the copy control information contained in the TLV/MMT stream, or the copy control information contained in the MPEG2-TS itself)?

In this embodiment of the digital broadcasting system, the solution to this problem is to have the broadcasting receiver 100 perform one of the following multiple solutions.

<Example of operation 1>
In the first operational example, when copy control information is included in the MPT, etc., and the data included in the same package and event in the location information includes MPEG2-TS data transmitted by other digital broadcast signals, the copy control state indicated by the copy control information included in the TLV stream is given priority over the copy control state indicated by the copy control information included in the MPEG2-TS.

For example, if the copy control status indicated by the copy control information included in the TLV stream is "One-generation copy allowed," and the copy control status indicated by the copy control information included in the MPEG2-TS is "Multiple predetermined copy allowed," then even if the data was acquired via a different route than the data acquired in the TLV stream (digital broadcasting in MPEG2-TS transmission format), copy control may be applied to it as "One-generation copy allowed" content. Similarly, if the copy control status indicated by the copy control information included in the TLV stream is "Unlimited copy allowed," and the copy control status indicated by the copy control information included in the MPEG2-TS is "Multiple predetermined copy allowed," then even if the data was acquired via a different route than the data acquired in the TLV stream (digital broadcasting in MPEG2-TS transmission format), copy control may be applied to it as "Unlimited copy allowed" content.

In this operation, data acquired through routes other than the TLV stream can also be placed into a copy state that the broadcast receiving device 100 of this embodiment can manage in the corresponding broadcasting system.

<Example of Operation 2>
In the second example of operation, when copy control information is included in the MPT, etc., and the data included in the same package and the same event in the location information includes MPEG2-TS data transmitted by other digital broadcast signals, the copy control state indicated by the copy control information included in the TLV stream is compared with the copy control state indicated by the copy control information included in the MPEG2-TS. If the copy control state indicated by the copy control information included in the MPEG2-TS is stricter than the copy control state indicated by the copy control information included in the TLV stream, the system operates to exclude the MPEG2-TS data from the content to be processed when performing storage processing in the storage unit 110, recording processing to a removable recording medium, or output processing from the digital interface.

In this operation, for data acquired via a path other than the TLV stream, the duplication of copy control states on the broadcast receiving device 100 of this embodiment can be resolved while respecting the original copy control information set in the broadcasting system transmitting the data.

Furthermore, if the copy control state indicated by the copy control information contained in the MPEG2-TS is the same as, or less restrictive than, the copy control state indicated by the copy control information contained in the TLV stream, then copy control should be applied to the MPEG2-TS data included in the same package and event in the same location information, treating it as content with the copy control state indicated by the copy control information contained in the TLV stream.

In this operation, for data acquired via a path other than the TLV stream, the duplication of copy control states on the broadcast receiving device 100 of this embodiment can be resolved while respecting the original copy control information set in the broadcasting system transmitting the data.

In the above description, the copyright protection function of the broadcast receiving device 100 in this embodiment was described as being performed based on copy control information included in the MPT. However, the table in which the copy control information is placed is not limited to the MPT. In addition to the MPT, the information may also be placed and transmitted in the MH-Service Description Table (MH-SDT), the MH-Event Information Table (MH-EIT), or other tables as described in Figure 6B, and the broadcast receiving device 100 may perform copyright protection processing according to these tables.

According to the embodiment described above, a broadcast receiver compatible with MMT digital broadcasting can be provided.

(Example 2)
The following describes Embodiment 2 of the present invention. Unless otherwise specified, the configuration, processing, and effects in this embodiment are the same as those in Embodiment 1. Therefore, the following will mainly describe the differences between this embodiment and Embodiment 1, and will omit explanations of common points as much as possible to avoid duplication. Furthermore, the broadcast receiving device in this embodiment is assumed to be a television receiver that supports both the MMT system and the MPEG2-TS system as media transport systems, and the following description will proceed accordingly.

[Hardware configuration of broadcast receiving equipment]
Figure 24 is a block diagram showing an example of the internal configuration of the broadcast receiving device 800. The broadcast receiving device 800 consists of a main control unit 801, a system bus 802, a ROM 803, a RAM 804, a storage unit 810, a LAN communication unit 821, an expansion interface unit 824, a digital interface unit 825, a first tuner/demodulation unit 831, a second tuner/demodulation unit 832, an MMT decoding unit 841, an MPEG2-TS decoding unit 842, a video synthesis unit 861, a monitor unit 862, a video output unit 863, a sound synthesis unit 864, a speaker unit 865, a sound output unit 866, and an operation input unit 870.

The main control unit 801, system bus 802, ROM 803, RAM 804, storage unit 810, expansion interface unit 824, digital interface unit 825, monitor unit 862, video output unit 863, speaker unit 865, audio output unit 866, operation input unit 870, etc., have the same functions as the main control unit 101, system bus 102, ROM 103, RAM 104, storage unit 110, expansion interface unit 124, digital interface unit 125, monitor unit 162, video output unit 163, speaker unit 165, audio output unit 166, operation input unit 170, etc., in the broadcast receiving device 100 of Embodiment 1, and a detailed explanation is omitted.

The first tuner/demodulator 831 receives broadcast waves from a broadcasting service employing MMT as the media transport method via an antenna (not shown) and tunes (selects) to the channel of the service desired by the user based on the control of the main control unit 801. Furthermore, the first tuner/demodulator 831 demodulates the received broadcast signal to obtain an MMT data sequence and outputs it to the MMT decoding processing unit 841. The second tuner/demodulator 832 receives broadcast waves from a broadcasting service employing MPEG2-TS as the media transport method via an antenna (not shown) and tunes (selects) to the channel of the service desired by the user based on the control of the main control unit 801. Furthermore, the second tuner/demodulator 832 demodulates the received broadcast signal to obtain an MPEG2-TS data sequence and outputs it to the MPEG2-TS decoding processing unit 842.

The MMT decoding processing unit 841 receives the MMT data sequence output from the first tuner/demodulation unit 831 and performs separation and decoding processes for real-time presentation elements such as video data sequences, audio data sequences, character superimposition data sequences, and subtitle data sequences based on the control signals contained in the MMT data sequence. The MMT decoding processing unit 841 has functions corresponding to the separation unit 132, video decoder 141, video color gamut conversion unit 142, audio decoder 143, character superimposition decoder 144, subtitle decoder 145, subtitle synthesis unit 146, subtitle color gamut conversion unit 147, data decoder 151, cache unit 152, application control unit 153, browser unit 154, application color gamut conversion unit 155, sound source unit 156, etc., in the broadcast receiving device 100 of Embodiment 1. The MMT decoding processing unit 841 is capable of performing the various processes described in Embodiment 1. Details of these various processes are as described in Embodiment 1 and will therefore be omitted.

The MPEG2-TS decoding processing unit 842 receives the MPEG2-TS data stream output from the second tuner/demodulation unit 832 and performs separation and decoding processes for real-time presentation elements such as video data streams, audio data streams, character superimposition data streams, and subtitle data streams based on the control signals contained in the MPEG2-TS data stream. The MPEG2-TS decoding processing unit 842 has the same functionality as the IRD (Integrated Receiver Decoder) unit of a conventional television receiver that receives broadcast waves from broadcast services employing MPEG2-TS as the media transport method; therefore, a detailed explanation is omitted.

The video synthesis unit 861 receives video information, subtitle information, and application information output from the MMT decoding processing unit 841, and video information, subtitle information, and application information output from the MPEG2-TS decoding processing unit 842, and performs appropriate selection and/or superposition processing. The video synthesis unit 861 is equipped with a video RAM (not shown), and the monitor unit 862, etc., are driven based on the video information input to the video RAM. Furthermore, the video synthesis unit 861 performs scaling processing, EPG screen information superposition processing, etc., as needed, based on the control of the main control unit 801. The audio synthesis unit 164 receives audio information output from the MMT decoding processing unit 841 and audio information output from the MPEG2-TS decoding processing unit 842, and performs appropriate selection and/or mixing processing.

The LAN communication unit 821 is connected to the Internet 200 via the router device 200r and transmits and receives data with various server devices and other communication devices on the Internet 200. It also acquires the MMT data sequence (or a portion thereof) and the MPEG2-TS data sequence (or a portion thereof) of the program transmitted via the communication line and outputs them to the MMT decoding processing unit 841 and the MPEG2-TS decoding processing unit 842 as appropriate.

[Time display on broadcast receiving device]
In this embodiment, the broadcast receiving device 800 is capable of displaying the current date and time on the EPG screen and various setting screens. The information regarding the current date and time is transmitted via MH-TOT or the like in broadcast services that employ MMT as the media transport method, and via TOT (Time Offset Table) or the like provided in the SI (Service Information) specified in the MPEG-2 system in broadcast services that employ MPEG-2-TS as the media transport method. The broadcast receiving device 800 can acquire the information regarding the current date and time by referring to MH-TOT or TOT.

Furthermore, generally speaking, when the video synthesis unit 861 primarily selects video information output from the MMT decoding processing unit 841, it should be controlled to superimpose the current date and time information obtained from the MH-TOT onto the video information. Similarly, when the video synthesis unit 861 primarily selects video information output from the MPEG2-TS decoding processing unit 842, it should be controlled to superimpose the current date and time information obtained from the TOT onto the video information.

However, there are differences in encoding/decoding processes and transmission paths between broadcast services employing MMT as the media transport method and those employing MPEG2-TS. Therefore, inconsistencies may occur, particularly in the current time display, depending on whether the broadcast service employing MMT or MPEG2-TS is selected. For example, as shown in Figure 25, when switching the screen display from EPG screen 162g, which displays channel information for a broadcast service employing MMT, to EPG screen 162h, which displays channel information for a broadcast service employing MPEG2-TS, the current time display changes from current time display 162g1 to current time display 162h1. This inconsistency may cause a visual disturbance to the user.

In this embodiment, the broadcast receiving device 800, in order to prevent the user from experiencing visual discomfort, controls the video synthesis unit 861 to superimpose the current date and time information obtained from the TOT onto the video information, even when the video synthesis unit 861 primarily selects video information output from the MMT decoding processing unit 841. That is, it controls the device to superimpose the current time information provided by a broadcast service employing MPEG2-TS as the media transport method onto the content of a broadcast service employing MMT as the media transport method.

By performing the aforementioned control, the broadcast receiving device 800 in this embodiment will always display the current time information obtained by referring to the TOT when displaying the current time. Therefore, even when switching between broadcast services employing MMT as the media transport method and broadcast services employing MPEG2-TS as the media transport method, it is possible to prevent users from experiencing visual discomfort due to inconsistencies in the display of the current time.

Figure 26A shows an example of the selection control of the current time information source according to the reception status of each broadcast service in the broadcast receiving device 800 of this embodiment. In the broadcast receiving device 800 of this embodiment, when reception of a broadcast service employing MPEG2-TS as the media transport method is possible, the device always refers to the TOT to acquire the current time information. Only when reception of a broadcast service employing MPEG2-TS as the media transport method is impossible, and reception of a broadcast service employing MMT as the media transport method is possible, does the device refer to the MH-TOT to acquire the current time information.

Furthermore, conversely to the control described above, the same effect can be obtained by controlling the system to superimpose current time information provided by a broadcasting service using MMT as the media transport method onto the content of a broadcasting service using MPEG2-TS as the media transport method.

As mentioned above, in both cases—when controlling the system to superimpose current time information provided by a broadcasting service using MPEG2-TS as the media transport method onto content from a broadcasting service using MMT as the media transport method, and when controlling the system to superimpose current time information provided by a broadcasting service using MMT as the media transport method onto content from a broadcasting service using MPEG2-TS as the media transport method—it is possible to correct the current time information by referring to the 'delta' parameter of the time information in the TMCC extended information area, similar to the explanation in [Time Management of Broadcasting Receiving Device] in Example 1.

Furthermore, in both cases—whether a broadcast service employs MMT as its media transport method or MPEG2-TS as its media transport method—the MH-TOT or TOT transmitted by each broadcast service constituting the network may contain errors due to malfunctions or transmission errors in the transmitting system. In this embodiment, the broadcast receiving device 800 has a function to update the time information of its built-in clock by obtaining an MH-TOT or TOT from another broadcast service on the same network, or from any broadcast service on another network, and referencing the current time information, if it determines that the MH-TOT or TOT acquired from the currently received service contains an error.

Figure 26B shows an example of the current time information update process in the broadcast receiving device 800 of this embodiment when receiving a broadcast service using MPEG2-TS as the media transport method. Note that the same process as shown in the figure is possible even when receiving a broadcast service using MMT as the media transport method.

In this embodiment, when updating the time information of the built-in clock in the broadcast receiving device 800, first, the receiving function execution unit 1102 obtains the TOT (Time of Day) from the MPEG2-TS data sequence of the currently received broadcast service (a broadcast service employing MPEG2-TS as the media transport method) (S301), and then obtains the current time information by referring to the obtained TOT (S302). Next, the receiving function execution unit 1102 performs a process to compare the current time information obtained in the S302 process with the time information of the built-in clock.

If, as a result of the comparison process, the difference between the current time information obtained in the S302 process and the time information of the built-in clock is within a predetermined value (for example, within 3 minutes) (S303: Yes), the receiving function execution unit 1102 updates the time information of the built-in clock using the current time information obtained in the S302 process (S306). On the other hand, if, as a result of the comparison process, the difference between the current time information obtained in the S302 process and the time information of the built-in clock is not within a predetermined value (S303: No), or if the TOT obtained in S301 has a flag indicating that there is an error in the data, the receiving function execution unit 1102 obtains the TOT from the MPEG2-TS data sequence of another broadcasting service within the same network, or obtains the MH-TOT from the MMT data sequence of any broadcasting service on another network (a broadcasting service that employs MMT as the media transport method) (S304), and further obtains the current time information from the obtained TOT or MH-TOT (S305). The receiving function execution unit 1102 should then perform the comparison process in S303 again using the current time information obtained in the S305 process.

Through the above processing, if the broadcast receiving device 800 of this embodiment determines that the MH-TOT or TOT acquired from the currently received service is incorrect, it can acquire the MH-TOT or TOT from another broadcasting service on the same network, or from any broadcasting service on another network, and refer to the current time information to update the time information of its built-in clock.

Furthermore, if, during initial factory setup, the system fails to acquire current time information within a predetermined range by repeatedly performing steps S304 to S305, the current time information acquired in step S302 can be used to re-set the internal clock's time information. This approach allows the system to handle cases where there is an error in the internal clock's time information of the broadcast receiving device 800 in this embodiment.

[EPG display on broadcast receiving device]
Event schedule information for broadcast services employing MMT as the media transport method is transmitted via MH-EIT, etc. On the other hand, event schedule information for broadcast services employing MPEG2-TS as the media transport method is transmitted via EIT (Event Information Table), etc., provided by the SI specified in the MPEG-2 system. Therefore, generally speaking, when displaying video information, etc., provided by a broadcast service employing MMT as the media transport method, the event schedule information (MH-EIT) of the broadcast service employing MMT can be obtained, and when displaying video information, etc., provided by a broadcast service employing MPEG2-TS as the media transport method, the event schedule information (EIT) of the broadcast service employing MPEG2-TS can be obtained.

However, the broadcast receiving device 800 of this embodiment is capable of acquiring both the MH-EIT and the EIT, whether displaying video information provided by a broadcast service employing MMT as the media transport method, or whether displaying video information provided by a broadcast service employing MPEG2-TS as the media transport method, thereby improving usability for the user.

Figure 27A shows an example of the EPG screen in the broadcast receiving device 800 of this embodiment. In the figure, EPG screen 162i is an EPG screen created based on the MH-EIT of a broadcasting service employing MMT as the media transport method, and 'M1 TV', 'M2 Broadcasting', 'M3 Channel', 'M4 TV', 'TV M5', etc., are the names of broadcasting stations of broadcasting services employing MMT as the media transport method. EPG screen 162j is an EPG screen created based on the EIT of a broadcasting service employing MPEG2-TS as the media transport method, and 'T6 TV', 'T7 Broadcasting', 'T8 Channel', 'T9 TV', 'TV TA', etc., are the names of broadcasting stations of broadcasting services employing MPEG2-TS as the media transport method.

For example, when a user is watching a broadcast program provided by a broadcasting service that employs MMT as the media transport method, and operates a remote control (not shown in the illustration) to instruct the display of the EPG screen, the initial EPG screen (not shown in the illustration) is displayed. This initial EPG screen is created based on the MH-EIT of the broadcasting service employing MMT as the media transport method, and displays detailed information about broadcast programs on each channel from 5 PM on October 7, 2014 (today). Next, if the user wishes to check detailed information about broadcast programs on each channel from 8 PM on October 9, 2014, and operates a remote control (not shown in the illustration) to instruct the EPG screen to update, EPG screen 162i is displayed.

Furthermore, if a user wishes to check detailed information about broadcast programs provided by a broadcasting service employing MPEG2-TS as the media transport method, and instructs the network to switch using a remote control (not shown in the illustration), the EPG screen 162j will be displayed. In this case, the broadcasting receiver 800 of this embodiment controls the system to display detailed information about broadcast programs for each channel at the same time and date as the previously displayed EPG screen 162i (i.e., from 8 PM on October 9, 2014), rather than the initial EPG screen created based on the EIT of the broadcasting service employing MPEG2-TS as the media transport method (i.e., detailed information about broadcast programs for each channel from 5 PM on October 7, 2014).

The aforementioned control allows users to easily and continuously check detailed information about broadcast programs from multiple networks using different media transport systems at the same time on the same day. In other words, the usability of the broadcast receiving device 800 is improved.

Figure 27B shows a different example of the EPG screen in the broadcast receiving device 800 of this embodiment. EPG screen 162k shows the state after scrolling in the channel direction (horizontal direction) from the state where EPG screen 162i shown in Figure 27A is displayed, using a remote control (not shown). That is, in the example shown in Figure 27B, by scrolling the EPG screen in the channel direction (horizontal direction), channel information created based on the MH-EIT of a broadcast service employing MMT as the media transport method and channel information created based on the EIT of a broadcast service employing MPEG2-TS as the media transport method are seamlessly displayed on the same time axis.

Therefore, even if a user wishes to check channel information created based on the MH-EIT of a broadcasting service using MPEG2-TS as the media transport method while checking channel information created based on the EIT of a broadcasting service using MMT as the media transport method, it is not necessary to instruct the user to switch networks using the remote control (not shown in the diagram). Furthermore, the user can simultaneously check detailed information about broadcast programs on multiple networks with different media transport methods for the same day and time. In other words, the usability of the broadcasting receiver 800 is improved.

(Example 3)
The following describes Embodiment 3 of the present invention. Unless otherwise specified, the configuration, processing, and effects in this embodiment are the same as those in Embodiment 1. Therefore, the following will mainly describe the differences between this embodiment and Embodiment 1, and will omit explanations of common points as much as possible to avoid duplication.

Embodiment 3 of the present invention has a hardware configuration similar to the broadcast receiver 100 in Embodiment 1, but implements control that realizes a different copyright protection function. Note that this embodiment describes content protection control for video content; for audio, control equivalent to the following description may be performed, or different content protection control may be performed.

Figure 28 summarizes the copyright protection function processing in the broadcast receiving device 100 of Example 3. In the broadcast receiving device 100 of Example 3, the copyright protection processing for the content before and after content storage is switched depending on whether the received content is 4K content (3840 x 2160 pixels) or 8K content (7680 x 4320 pixels), which is content exceeding 2K resolution (content with a pixel count exceeding 1920 x 1080 pixels), or 2K or less content (content with a pixel count of 1920 x 1080 pixels or less).

Specifically, the broadcast receiving device 100 controls the content protection process based on the parameters included in the content copy control descriptor described in Figures 22A and 22B (for example, the 'digital_recording_control_data' parameter) and the parameters included in the content usage control descriptor described in Figure 23 (for example, the 'encryption_mode' parameter), switching the process according to the number of pixels of the content received by the broadcast receiving device 100, or the content after pixel count conversion if pixel count conversion is performed, as shown in Figure 28. Furthermore, in the broadcast receiving device 100 of Embodiment 3 of the present invention, the 'image_construct_token' parameter in the content usage control descriptor shown in Figure 23 is effectively disabled. That is, regardless of the value of the 'image_construct_token' parameter, the broadcast receiving device 100 of Embodiment 3 only needs to determine that it does not limit the resolution of the video signal output. In other words, the copyright protection concept of the broadcast receiving device 100 in Example 3 is not to impose a resolution restriction on the video signal output for the user according to the 'image_construct_token' parameter, but rather to apply appropriate content protection according to the pixel count state before and after content storage processing, as shown in the table in Figure 28.

The table in Figure 28 explains the process of recording received content in the storage unit 110 (Figure 8A) in a way that prevents playback by devices other than the broadcast receiver 100. It divides the process into pre-storage processing (performed before storage) and post-storage processing (performed after storage). First, we will explain pre-storage processing. In this embodiment, the expression "before storage" of content does not necessarily mean that the content is subsequently stored. It encompasses both the meaning of "the state before the actual storage of content" and "without storing the content."

[Content received]
In the broadcast receiver 100 of Example 3, content is received using the MMT transmission method, so in the example in Figure 28, the transmission method is always the MMT transmission method. Here, the content received may be 4K content (3840 x 2160 pixels) or 8K content (7680 x 4320 pixels), which are content exceeding 2K resolution (content with a pixel count exceeding 1920 x 1080 pixels), or it may be 2K or less content (content with a pixel count of 1920 x 1080 pixels or less).

The broadcast receiver 100 can determine whether the received content is over 2K content or 2K or less content by using data transmitted using the MMT method. Specifically, it may use the pixel count information contained in the header of the content's video encoding stream (e.g., H.265/HEVC encoding stream), or it may use the pixel count information stored in 'video_resolution' in the video component descriptor shown in Figure 19A, as described in Example 1. The determination can be made using any of the data transmitted using the MMT method.

[Pixel count conversion process after content reception and before storage]
In the broadcast receiver 100 of Example 3, there is a pixel count conversion unit (not shown) either before or after the video synthesis unit shown in Figure 8A that performs pixel count conversion of the video, enabling the execution of pixel count conversion processing of the decoded video of the received content. As shown in the table in Figure 28, for received content exceeding 2K resolution (content with a pixel count exceeding 1920 x 1080), there are cases where no pixel count conversion is performed, cases where pixel count conversion is performed and the content is converted to other content exceeding 2K resolution, and cases where pixel count conversion is performed and the content is converted to 2K or less resolution (content with a pixel count of 1920 x 1080 or less). Also, as shown in the table in Figure 28, for received content of 2K or less resolution (content with a pixel count of 1920 x 1080 or less), there are cases where no pixel count conversion is performed and cases where such pixel count conversion is performed and the content is converted to other 2K or less resolution (content with a pixel count of 1920 x 1080 or less).

[Output processing to external devices after content reception but before storage]
In the broadcast receiver 100 of Example 3, when outputting content to an external device after content reception but before storage, the content protection process is switched according to the pixel count of the content. Specifically, when outputting content to an external device after content reception but before storage, the content protection process is changed depending on whether the pixel count of the content exceeds 1920 x 1080 pixels or is 1920 x 1080 pixels or less. Changing the content protection process here means changing the interpretation of the parameters included in the content copy control descriptor explained in Figures 22A and 22B (for example, the 'digital_recording_control_data' parameter) and the parameters included in the content usage control descriptor explained in Figure 23 (for example, the 'encryption_mode' parameter), and switching the content protection process performed on these parameters.

The following describes a specific example of the output process to an external device after content reception and before storage, as shown in Figure 28. This output process to an external device can be applied to the video output process when outputting the video decoded by the video decoder 141 in Figure 8A, or the video converted by the pixel count conversion unit, from the video output unit 163 to an external device. Alternatively, the video output may be performed via an IP interface using the LAN communication unit 121 in Figure 8A as hardware.

(1-1) When outputting content exceeding 2K resolution (content with a pixel count exceeding 1920 x 1080) to an external device without performing pixel count conversion, or when performing pixel count conversion to output 2K content exceeding 1920 x 1080 resolution to an external device.

In this case, the value of the 'encryption_mode' in the content usage control descriptor is not considered for content output protection. If the 'digital_recording_control_data' in the content copy control descriptor is 00, content will be output without HDCP protection. If the 'digital_recording_control_data' in the content copy control descriptor is 10, advanced content protection from HDCP Revision 2.2 or later will be applied to the output. If the 'digital_recording_control_data' in the content copy control descriptor is 01, output will be prohibited. If the 'digital_recording_control_data' in the content copy control descriptor is 11, advanced content protection from HDCP Revision 2.2 or later will be applied to the output. If the content copy control descriptor for the received content is not included in the received data for any reason, content protection by HDCP will not be applied, and the data will be output.

The content protection process performed during output to an external device before storage, which involves interpreting the `digital_recording_control_data` parameter in the content copy control descriptor and the `encryption_mode` parameter in the content usage control descriptor as described above, will hereafter be referred to as the "2K+ content protection process" during output to an external device before storage.

(1-2) When receiving content exceeding 2K resolution (content with a pixel count exceeding 1920 x 1080), the content is converted to 2K or less resolution (content with a pixel count of 1920 x 1080 or less) and output to an external device.

If the content copy control descriptor 'digital_recording_control_data' is 00, or if the content copy control descriptor of the received content is not included in the received data for any reason, the system switches whether or not to perform content protection during output, depending on the value of the content usage control descriptor 'encryption_mode'. In this case, if the value of the content usage control descriptor 'encryption_mode' is 1 and content protection is not specified, the output can be performed without HDCP protection. If the value of the content usage control descriptor 'encryption_mode' is 0 and content protection is specified, the output will be performed with HDCP Revision 1 or Revision 2 or later protection.

Furthermore, if the content copy control descriptor 'digital_recording_control_data' is 10, regardless of the 'encryption_mode' value in the content usage control descriptor, the output will be protected by HDCP Revision 1 or Revision 2 or later. If the content copy control descriptor 'digital_recording_control_data' is 01, the output itself will be prohibited regardless of the 'encryption_mode' value in the content usage control descriptor. If the content copy control descriptor 'digital_recording_control_data' is 11, regardless of the 'encryption_mode' value in the content usage control descriptor, the output will be protected by HDCP Revision 1 or Revision 2 or later. If the content copy control descriptor for the received content is not included in the received data for any reason, content protection by HDCP will not be applied, and the data will be output.

The content protection process performed during output to an external device before storage, which involves interpreting the `digital_recording_control_data` parameter in the content copy control descriptor and the `encryption_mode` parameter in the content usage control descriptor as described above, will hereafter be referred to as the "2K or less content protection process" during output to an external device before storage.

(1-3) When outputting content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less) to an external device without performing resolution conversion, or when performing resolution conversion and outputting to another 2K resolution or less content (content with a resolution of 1920 x 1080 pixels or less) to an external device.

In this case, the "2K or lower content protection processing" described in (1-2) for output to external devices before storage is performed.

As explained in (1-1), (1-2), and (1-3) above, when outputting to an external device before storage, the interpretation of the 'digital_recording_control_data' parameter in the content copy control descriptor and the 'encryption_mode' parameter in the content usage control descriptor is switched according to the number of pixels of the content being output to the external device before storage. When outputting copy-restricted content exceeding 2K resolution (content with a pixel count exceeding 1920 x 1080) to an external device, a higher level of content protection is applied than when outputting copy-restricted content of 2K resolution or less (content with a pixel count of 1920 x 1080 or less) to an external device. This allows for the appropriate protection of higher-value content exceeding 2K resolution (content with a pixel count exceeding 1920 x 1080) even on external devices.

[Content protection process during content storage]
In the broadcast receiver 100 of Example 3, it has already been explained that, in the output process to an external device after content reception but before storage, the content protection process is switched according to the pixel count state of the content. This is because the playback device that plays the content at the output destination is an external device, and the level of content protection processing supported may differ depending on the device.

In contrast, when content is stored using a content storage function that allows playback only on the broadcast receiver 100 that received and recorded the content, it is unnecessary to change the processing according to the pixel count of the content. This is because, since the content is managed solely by the broadcast receiver 100 itself, there is no need to consider multiple levels of content protection processing. Therefore, to simplify management within the broadcast receiver 100, when content is stored using a content storage function that allows playback only on the broadcast receiver 100 that received and recorded the content, it is desirable to perform a common storage protection process regardless of whether the content is over 2K (content with a pixel count exceeding 1920 x 1080) or under 2K (content with a pixel count of 1920 x 1080 or less). The content storage process can, for example, be performed on the storage unit 110 (Figure 8A), which is a recording medium built into the broadcast receiver 100 in Example 3. However, if local encryption processing specific to the broadcast receiver 100 is performed and management is implemented so that playback is only possible on the broadcast receiver 100, storage may be performed on an external recording medium such as a hard disk.

In the content storage process shown in Figure 28, content that has not undergone pixel count conversion at the time of reception (content with a pixel count exceeding 1920 x 1080), content that has undergone pixel count conversion at the time of reception (content with a pixel count exceeding 1920 x 1080) to be converted into 2K content of other pixel counts (content with a pixel count exceeding 1920 x 1080), and content that has undergone pixel count conversion at the time of reception (content with a pixel count exceeding 1920 x 1080) In all cases—content converted to 2K or lower resolution (content with a resolution of 1920 x 1080 or less) by performing a pixel count conversion on the original content (Tents), content that was not converted to 2K or lower resolution (content with a resolution of 1920 x 1080 or less) upon reception, and content that was converted to other 2K or lower resolution (content with a resolution of 1920 x 1080 or less) by performing a pixel count conversion upon reception—the following common storage protection process will be performed.

Here, "common storage protection processing" means that the interpretation processing of the 'digital_recording_control_data' parameter included in the content copy control descriptor, the 'encryption_mode' parameter included in the content usage control descriptor, and other parameters is common to both 2K-plus content (content with a pixel count exceeding 1920 x 1080) and 2K-less content (content with a pixel count of 1920 x 1080 or less) during storage.

The following describes a specific example of the "common storage protection process" in the content storage process shown in Figure 28.

First, if the value of the `digital_recording_control_data` parameter in the content copy control descriptor is 00, meaning "copyable without restrictions," then the content can be stored without any copying restrictions. The copy control information on the recording medium at the time of storage, which manages the content to be stored on the recording medium, may be stored as "copyable without restrictions." Furthermore, the copy control information on the recording medium used for controlling the copying of stored content may be generated and managed separately from the value of the `digital_recording_control_data` parameter in the content copy control descriptor; there is no need to rewrite the value of the `digital_recording_control_data` parameter in the content copy control descriptor.

In this case, the value of the 'encryption_mode' parameter included in the content usage control descriptor is considered. If this value is 1, indicating content protection, then during the storage process, a local encryption process specific to the broadcast receiver 100 is applied to the content so that it can only be played back on the broadcast receiver 100. If the value of the 'encryption_mode' parameter in the content usage control descriptor is 0, indicating content protection is not specified, then the local encryption process does not need to be performed (however, in this case, the local encryption process may be performed). While the content is stored as "copyable without restrictions," a common content protection process is applied without changing the content's pixel count until external device output, external device copy, or external device move operations are performed, as described later. This simplifies management within the broadcast receiver 100.

If the value of the 'digital_recording_control_data' parameter in the content copy control descriptor is 10, and the value of the 'copy_restriction_mode' parameter (see Figure 23) in the content usage control descriptor is 1, the content is interpreted as "copyable only once," and during the storage process, the copy control information on the recording medium at the time of storage, which manages the content to be stored on the recording medium, is stored as "re-copy prohibited." Note that the copy control information on the recording medium used for copy control of stored content may be generated and managed separately from the value of the 'digital_recording_control_data' parameter in the content copy control descriptor, and there is no need to rewrite the value of the 'digital_recording_control_data' parameter in the content copy control descriptor. When performing storage processing as "re-copy prohibited," the content is stored with local encryption processing specific to the broadcast receiver 100 so that it can only be played back by the broadcast receiver 100. Content stored with the "Re-copying Prohibited" setting is protected from being copied. While content is stored with "Re-copying Prohibited," and before external device output or external device move operations (described later) are performed with "Re-copying Prohibited," the content protection process remains consistent regardless of the content's pixel count; a common content protection process is applied. This simplifies management within the broadcast receiver 100.

If the value of the 'digital_recording_control_data' parameter in the content copy control descriptor is 10 and the value of the 'copy_restriction_mode' parameter in the content usage control descriptor is 0, the content is interpreted as "copyable with a limit on the number of copies," and in the storage process, the copy control information on the recording medium at the time of storage, which manages the content to be stored on the recording medium, can be stored as "copyable with a limit on the number of copies." Note that the copy control information on the recording medium used for copy control of stored content may be generated and managed separately from the value of the 'digital_recording_control_data' parameter in the content copy control descriptor, and there is no need to rewrite the value of the 'digital_recording_control_data' parameter in the content copy control descriptor. When performing storage processing as "copyable with a limit on the number of copies," the content is stored with local encryption processing specific to the broadcast receiver 100 so that it can only be played back by the broadcast receiver 100. While content is being stored with "copying allowed with quantity limit," and before external device output, external device copying, or external device moving (described later as "re-copying prohibited") is performed, the content protection process remains consistent regardless of the content's pixel count. This simplifies management within the broadcast receiver 100.

If the value of the 'digital_recording_control_data' parameter included in the content copy control descriptor is 11, the content is interpreted as "copy-protected". In this case, if the broadcast receiver 100 supports the "temporary storage" function, temporary storage is possible. However, if the broadcast receiver 100 does not support the "temporary storage" function, storage is prohibited and no storage process is performed. If the broadcast receiver 100 supports the "temporary storage" function, during the storage process, copy control information on the recording medium at the time of storage, which manages the content to be stored on the recording medium, is stored as "temporary storage," allowing storage of content for a certain period of time (for example, 1 hour and 30 minutes). In this case, the storage time is managed in 1-minute increments, and the stored content must be rendered unplayable before the above-mentioned certain period + 1 minute exceeds the time from reception (= start of storage). Specific examples of rendering content unplayable include erasing the content itself or erasing the encryption key, thereby making it impossible to play the content. Content being stored as "temporarily stored" is protected from copying and moving. While content is being stored as "re-copy prohibited," and until external device output is performed as described later ("re-copy prohibited"), the content protection process remains consistent regardless of the content's pixel count; a common content protection process is applied. This simplifies management within the broadcast receiver 100.

As explained above, during content storage, the interpretation of the `digital_recording_control_data` parameter in the content copy control descriptor and the `encryption_mode` parameter in the content usage control descriptor is not switched according to the number of pixels of the content at the time of storage; instead, the content protection process is standardized. This simplifies management within the broadcast receiver 100.

[Pixel count conversion process after content storage]
The broadcast receiver 100 of Embodiment 3 has a pixel count conversion unit (not shown) that performs pixel count conversion of video either before or after the video synthesis unit in Figure 8A, and a pixel count conversion unit (not shown) that plays back the stored content from the storage unit 110 in Figure 8A, decodes the video data with the video decoder 141 and performs pixel count conversion of the video, enabling the execution of pixel count conversion processing of decoded video of content stored in the storage unit 110.

As shown in the table in Figure 28, in some cases, pixel conversion may not be performed when outputting, moving, or copying 2K content (content with a pixel count exceeding 1920 x 1080) that has been stored without pixel count conversion, or when 2K content (content with a pixel count exceeding 1920 x 1080) that has been stored after receiving 2K content (content with a pixel count exceeding 1920 x 1080) has been converted to other 2K content (content with a pixel count exceeding 1920 x 1080) by performing pixel count conversion. In this case, the content to be outputted, moved, or copied is 2K content (content with a pixel count exceeding 1920 x 1080).

Furthermore, in some cases, when storing received 2K+ content (content with a pixel count exceeding 1920 x 1080) without performing pixel count conversion, or when storing received 2K+ content (content with a pixel count exceeding 1920 x 1080) converted to other 2K+ content (content with a pixel count exceeding 1920 x 1080) after performing pixel count conversion, the content may be converted to other 2K+ content during output, move, or copy after storage. In this case, the content to be output, moved, or copied is 2K+ content (content with a pixel count exceeding 1920 x 1080).

Furthermore, in cases where received 2K+ content (content with a pixel count exceeding 1920 x 1080) is stored without pixel count conversion, or where received 2K+ content (content with a pixel count exceeding 1920 x 1080) is converted to other 2K+ content (content with a pixel count exceeding 1920 x 1080) and then stored, pixel count conversion may be performed during output, move, or copy after storage to convert it to 2K or lower content (content with a pixel count of 1920 x 1080 or less). In this case, the content to be output, moved, or copied is 2K or lower content (content with a pixel count of 1920 x 1080 or less).

Furthermore, even if received content exceeding 2K resolution (content with a pixel count exceeding 1920 x 1080) is converted to 2K or lower content (content with a pixel count of 1920 x 1080 or less) and stored, pixel conversion may not be performed during output, move, or copy after storage. In this case, the content to be output, moved, or copied will be 2K or lower content (content with a pixel count of 1920 x 1080 or less).

Furthermore, in some cases, when receiving content exceeding 2K resolution (content with a pixel count exceeding 1920 x 1080 pixels) and converting it to 2K or lower content (content with a pixel count of 1920 x 1080 pixels or less), and then storing this 2K or lower content (content with a pixel count of 1920 x 1080 pixels or less), the pixel count may be converted again during output, move, or copy to other 2K or lower content (content with a pixel count of 1920 x 1080 pixels or less). In this case, the content to be output, moved, or copied is 2K or lower content (content with a pixel count of 1920 x 1080 pixels or less).

Furthermore, in cases where received content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less) is stored without resolution conversion, or where received content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less) is converted to other content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less) and then stored, resolution conversion may not be performed during output, move, or copy after storage. In these cases, the content to be output, moved, or copied is 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less).

Furthermore, in some cases, content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less) is stored without resolution conversion, or content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less) is stored after resolution conversion, and then, during output, move, or copy of the stored content, resolution conversion is performed again to convert it to other content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less). In this case, the content to be output, moved, or copied is content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less).

[Output processing to external devices after content storage]
In the broadcast receiver 100 of Example 3, it has already been explained that in the content storage process, the content protection process is not switched according to the pixel count of the content, but a common content protection process is performed. This is because, when content is stored using a content storage function that can only be played back by the broadcast receiver 100 that received and recorded the content, the content is managed only by the broadcast receiver 100 itself, so there is no need to consider multiple levels of content protection processing. On the other hand, when the stored content is output to an external device, the level of content protection processing may differ depending on the playback device that plays the content at the output destination. Therefore, it is desirable to differentiate the content protection processing according to the pixel count of the content when outputting the stored content to an external device.

The following describes a specific example of the output process to an external device after content storage, as shown in Figure 28. This output process to an external device after content storage can be applied to the video output process when outputting the video obtained by decoding the video content stored in the storage unit 110 (Figure 8A) using the video decoder 141, or the video obtained by converting the decoded video using the pixel count conversion unit, from the video output unit 163 to an external device. Alternatively, the video output may be performed via an IP interface using the LAN communication unit 121 (Figure 8A) as hardware.

(2-1) When 2K content (content with a pixel count exceeding 1920 x 1080 pixels) that has been received and stored without pixel count conversion, or when 2K content (content with a pixel count exceeding 1920 x 1080 pixels) that has been received and stored after pixel count conversion to convert it into other 2K content (content with a pixel count exceeding 1920 x 1080 pixels), and no pixel count conversion is performed when outputting to an external device after storage.

In this case, the content to be output externally is 2K or higher content (content with a pixel count exceeding 1920 x 1080).

For content stored on a recording medium with copy control information set to "copyable without restrictions," content protection by HDCP can be omitted when the content is played back and output externally after storage. In this case, whether or not protection was specified based on the value of the 'encryption_mode' parameter in the content usage control descriptor at the time of storage is not considered. This allows for consistent processing with the case where 'digital_recording_control_data' in the content copy control descriptor in (1-1) above is 00 when outputting content externally before storage.

For content stored on a recording medium with copy control information set to "Re-copy prohibited," content stored with copy control information set to "Number of copies allowed," and content stored with copy control information set to "Temporary storage," advanced content protection of HDCP Revision 2.2 or later will be applied when playing back and outputting the content externally after storage.

When outputting stored content to an external device as 2K+ content (content with a pixel count exceeding 1920 x 1080), the content protection process performed according to the copy control information on the recording medium, as described above, will hereafter be referred to as the "2K+ content protection process" during output to an external device after storage.

(2-2) When storing received 2K+ content (content with a pixel count exceeding 1920 x 1080) without performing pixel count conversion, or when storing received 2K+ content (content with a pixel count exceeding 1920 x 1080) converted to other 2K+ content (content with a pixel count exceeding 1920 x 1080) and then performing pixel count conversion again when outputting to an external device after storage, to convert it back to other 2K+ content.

In this case, the content to be output to an external device is 2K+ content (content with a pixel count exceeding 1920 x 1080), and since it is the same as in (2-1) above, the "2K+ content protection processing" for output to an external device after storage, as explained in (2-1), is performed.

(2-3) When storing received 2K+ content (content with a pixel count exceeding 1920 x 1080) without performing pixel count conversion, or when storing received 2K+ content (content with a pixel count exceeding 1920 x 1080) converted to other 2K+ content (content with a pixel count exceeding 1920 x 1080) and then performing pixel count conversion to convert it to 2K or less content (content with a pixel count exceeding 1920 x 1080) when outputting to an external device after storage.

In this case, the content to be output externally is content of 2K resolution or lower (content with a resolution of 1920 x 1080 pixels or less).

In this case, for content stored on the recording medium with copy control information set to "copyable without restrictions," the content protection process is switched based on whether protection was specified or not, according to the value of the 'encryption_mode' parameter included in the content usage control descriptor at the time of storage. Specifically, if the value of 'encryption_mode' is 1 and content protection is not specified, the content can be output without HDCP content protection when played back and output to an external device after storage. If the value of 'encryption_mode' is 0 and content protection is specified, the content will be output with HDCP Revision 1 or Revision 2 or later protection when played back and output to an external device after storage. This allows for common processing with the case where 'digital_recording_control_data' in the content copy control descriptor in (1-2) above is 00 when outputting content to an external device before storage.

Furthermore, content stored on the recording medium with copy control information set to "re-copy prohibited," content stored with copy control information set to "number of copies allowed," and content stored with copy control information set to "temporary storage" will be protected by HDCP Revision 1 or Revision 2 or later before output.

When outputting stored content to an external device as content with a resolution of 2K or less (content with a resolution of 1920 x 1080 pixels or less), the content protection process performed according to the copy control information on the recording medium, as described above, will hereafter be referred to as the "2K or less content protection process" when outputting stored content to an external device.

(2-4) When receiving content exceeding 2K resolution (content with a pixel count exceeding 1920 x 1080) and converting it to content of 2K resolution or less (content with a pixel count of 1920 x 1080 or less), and then storing that content, if no further pixel conversion is performed when outputting it to an external device after storage:

In this case, the content to be output to an external device is 2K or lower content (content with a resolution of 1920 x 1080 pixels or less), and is the same as in case (2-3) above. Therefore, the "2K or lower content protection processing" described in (2-3) for output to an external device after storage is performed.

(2-5) When receiving content exceeding 2K resolution (content with a pixel count exceeding 1920 x 1080 pixels), performing pixel count conversion to convert it to 2K or less content (content with a pixel count of 1920 x 1080 pixels or less), and then storing that 2K or less content (content with a pixel count of 1920 x 1080 pixels or less), and then performing pixel count conversion again when outputting it to an external device after storage to convert it to other 2K or less content (content with a pixel count of 1920 x 1080 pixels or less).

In this case, the content to be output to an external device is 2K or lower content (content with a resolution of 1920 x 1080 pixels or less), and is the same as in case (2-3) above. Therefore, the "2K or lower content protection processing" described in (2-3) for output to an external device after storage is performed.

(2-6) When receiving content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less) and storing it without performing pixel resolution conversion, or when receiving content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less) and then converting it to other content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less) and storing it, and not performing pixel resolution conversion when outputting to an external device after storage.

In this case, the content to be output to an external device is 2K or lower content (content with a resolution of 1920 x 1080 pixels or less), and is the same as in case (2-3) above. Therefore, the "2K or lower content protection processing" described in (2-3) for output to an external device after storage is performed.

(2-7) When receiving content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less) and storing it without performing resolution conversion, or when receiving content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less) and performing resolution conversion to convert it to other content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less) and storing it, and then performing resolution conversion again when outputting the stored content to an external device to convert it to other content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less)

In this case, the content to be output to an external device is 2K or lower content (content with a resolution of 1920 x 1080 pixels or less), and is the same as in case (2-3) above. Therefore, the "2K or lower content protection processing" described in (2-3) for output to an external device after storage is performed.

As explained in sections (2-1) through (2-7) above, when outputting to an external device after storage, the content protection process is switched according to the pixel count of the content output to the external device. When outputting copy-protected content exceeding 2K resolution (content with a pixel count exceeding 1920 x 1080) to an external device, a higher level of content protection is applied than when outputting copy-protected content of 2K resolution or less (content with a pixel count of 1920 x 1080 or less). This allows for the proper protection of higher-value content exceeding 2K resolution (content with a pixel count exceeding 1920 x 1080) even on external devices.

[Moving content to external devices after it has been stored]
In the broadcast receiver 100 of Example 3, it has already been explained that in the content storage process, the content protection process is not switched according to the pixel count of the content, but a common content protection process is performed. This is because when content is stored using a content storage function that can only be played back by the broadcast receiver 100 that received and recorded the content, the content is managed only by the broadcast receiver 100 itself, so there is no need to consider multiple levels of content protection processing. On the other hand, when the stored content is moved to an external device, the level of content protection processing may differ depending on the destination device. Therefore, it is desirable to perform different content protection processing depending on the pixel count of the content when moving the stored content to an external device.

The following describes a specific example of the content transfer process to an external device after content storage, as shown in Figure 28. Note that the transfer of content to an external device after it has been stored in the storage unit 110 in Figure 8A can be performed, for example, via an IP interface using the LAN communication unit 121 in Figure 8A as hardware.

(3-1) When storing 2K+ content (content with a pixel count exceeding 1920 x 1080) without performing pixel count conversion on the received 2K+ content (content with a pixel count exceeding 1920 x 1080), or when storing 2K+ content (content with a pixel count exceeding 1920 x 1080) after performing pixel count conversion on the received 2K+ content (content with a pixel count exceeding 1920 x 1080) and converting it to other 2K+ content (content with a pixel count exceeding 1920 x 1080), if no pixel count conversion is performed when moving the stored content to an external device.

In this case, the content to be moved to the external device is 2K or higher content (content with a resolution exceeding 1920 x 1080 pixels).

For content stored on a recording medium with copy control information set to "copyable without restrictions," it can be moved to an external device after storage without DTCP content protection. In this case, whether or not protection was specified by the value of the 'encryption_mode' parameter included in the content usage control descriptor at the time of storage is not considered.

Content stored on a recording medium with copy control information set to "re-copy prohibited" and content stored with copy control information set to "number of copies allowed" can be protected by DTCP2 (described in Reference 1), a more advanced content protection system than DTCP-IP, and moved to external devices. However, even if an external device supports DTCP-IP content protection, it cannot play DTCP2-protected content (it will not receive DTCP2-protected content) unless it also supports DTCP2 content protection. Therefore, while DTCP2 offers stronger content protection, existing external devices cannot support DTCP2-protected content. In contrast, DTCP-IP content protection, while unable to utilize DTCP2's new content protection flags, enables moving content to existing DTCP-IP compatible external devices that do not support DTCP2.

[Reference 1: Digital Transaction Licensing Administrator DTCP2 Presentation to CPTWG January 27, 2016]

When moving stored content to an external device as 2K+ content (content with a pixel count exceeding 1920 x 1080), the content protection process performed according to the copy control information on the recording medium, as described above, will hereafter be referred to as the "2K+ content protection process" during the move to an external device after storage.

(3-2) When storing received 2K+ content (content with a pixel count exceeding 1920 x 1080) without performing pixel count conversion, or when storing received 2K+ content (content with a pixel count exceeding 1920 x 1080) converted to other 2K+ content (content with a pixel count exceeding 1920 x 1080) and then performing pixel count conversion again when moving the stored 2K+ content to an external device, and then converting it to other 2K+ content again:

In this case, the content to be moved to the external device is 2K+ content (content with a pixel count exceeding 1920 x 1080), and since it is the same as in (3-1) above, the "2K+ content protection processing" described in (3-1) for moving content to the external device after storage is performed.

(3-3) When storing received 2K+ content (content with a pixel count exceeding 1920 x 1080) without performing pixel count conversion, or when storing received 2K+ content (content with a pixel count exceeding 1920 x 1080) converted to other 2K+ content (content with a pixel count exceeding 1920 x 1080) and then performing pixel count conversion to convert it to 2K or less content (content with a pixel count exceeding 1920 x 1080) during the move to an external device after storage,

In this case, the content to be moved to the external device is content of 2K resolution or lower (content with a resolution of 1920 x 1080 pixels or less).

In this case, for content stored on the recording medium with copy control information set to "copyable without restrictions," the content protection process is switched based on whether protection was specified or not, according to the value of the `encryption_mode` parameter included in the content usage control descriptor at the time of storage. Specifically, if the value of `encryption_mode` is 1 and content protection is not specified, the content can be moved to an external device after storage without DTCP content protection. If the value of `encryption_mode` is 0 and content protection is specified, the content can be moved to an external device after storage with DTCP (or DTCP-IP if moving via an IP interface) protection. In this case, DTCP2 content protection is not necessary.

Furthermore, for content stored on the recording medium with copy control information set to "re-copy prohibited" and content stored with copy control information set to "number of copies allowed," protection using DTCP (or DTCP-IP if moving via an IP interface) will be applied during the move. In this case, DTCP2 content protection is not necessary.

When moving accumulated content to an external device as 2K or lower content (content with a resolution of 1920 x 1080 pixels or less), the content protection process performed according to the copy control information on the recording medium, as described above, will hereafter be referred to as the "2K or lower content protection process" during the move to an external device after accumulation.

(3-4) When receiving content exceeding 2K resolution (content with a pixel count exceeding 1920 x 1080) and converting it to content of 2K resolution or less (content with a pixel count of 1920 x 1080 or less), and then storing that content, if no further pixel conversion is performed when moving it to an external device after storage:

In this case, the content to be moved to the external device is 2K or lower content (content with a resolution of 1920 x 1080 pixels or less), and is the same as in case (3-3) above. Therefore, the "2K or lower content protection processing" described in (3-3) for moving content to the external device after storage is performed.

(3-5) When receiving content exceeding 2K resolution (content with a pixel count exceeding 1920 x 1080 pixels), performing a pixel count conversion to convert it to 2K or lower content (content with a pixel count of 1920 x 1080 pixels or less), and then, when moving this stored 2K or lower content (content with a pixel count of 1920 x 1080 pixels or less) to an external device, performing another pixel count conversion to convert it to other 2K or lower content (content with a pixel count of 1920 x 1080 pixels or less).

In this case, the content to be moved to the external device is 2K or lower content (content with a resolution of 1920 x 1080 pixels or less), and is the same as in case (3-3) above. Therefore, the "2K or lower content protection processing" described in (3-3) for moving content to the external device after storage is performed.

(3-6) When 2K or lower content (content with a resolution of 1920 x 1080 or less) is received and stored without resolution conversion, or when 2K or lower content (content with a resolution of 1920 x 1080 or less) is received, converted to other 2K or lower content (content with a resolution of 1920 x 1080 or less) and stored, and resolution conversion is not performed when moving the stored content to an external device.

In this case, the content to be moved to the external device is 2K or lower content (content with a resolution of 1920 x 1080 pixels or less), and is the same as in case (3-3) above. Therefore, the "2K or lower content protection processing" described in (3-3) for moving content to the external device after storage is performed.

(3-7) When storing received content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less) without performing resolution conversion, or when storing received content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less) after performing resolution conversion to convert it to other content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less), and then performing resolution conversion again when moving the stored content to an external device to convert it to other content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less).

In this case, the content to be moved to the external device is 2K or lower content (content with a resolution of 1920 x 1080 pixels or less), and is the same as in case (3-3) above. Therefore, the "2K or lower content protection processing" described in (3-3) for moving content to the external device after storage is performed.

As explained in sections (3-1) through (3-7) above, when moving stored content to an external device, the content protection process is switched according to the pixel count of the content being moved to the external device. When moving copy-protected content exceeding 2K resolution (content with a pixel count exceeding 1920 x 1080) to an external device, a higher level of content protection is applied than when moving copy-protected content below 2K resolution (content with a pixel count of 1920 x 1080 or less) to an external device. This ensures that higher-value content exceeding 2K resolution (content with a pixel count exceeding 1920 x 1080) is properly protected on external devices.

Furthermore, in any of the cases described above (3-1) through (3-7), moving content to an external device involves a series of processes that copy the content to only one authenticated external device and render the original content unplayable. In this process, the original content must be rendered unplayable within one minute of copying it to the external device. Specific examples of rendering the content unplayable include deleting the content itself or deleting the encryption key, thereby making playback of the content impossible.

[Copying content to external devices after storage]
In the broadcast receiver 100 of Example 3, it has already been explained that in the content storage process, the content protection process is not switched according to the pixel count of the content, but a common content protection process is performed. This is because when content is stored using a content storage function that can only be played back by the broadcast receiver 100 that received and recorded the content, the content is managed only by the broadcast receiver 100 itself, so there is no need to consider multiple levels of content protection processing. On the other hand, when the stored content is copied to an external device, the level of content protection processing may differ depending on the destination device. Therefore, it is desirable to perform different content protection processing depending on the pixel count of the content when copying the stored content to an external device.

The following describes a specific example of the content copying process to an external device after content storage, as shown in Figure 28. Note that the content copying process to an external device after storage in the storage unit 110 in Figure 8A can be performed, for example, via an IP interface using the LAN communication unit 121 in Figure 8A as hardware.

Furthermore, for content stored on the recording medium with copy control information set to "re-copy prohibited," copying to external devices is prohibited. For content stored on the recording medium with copy control information set to "number of copies allowed," up to nine copies can be generated in addition to the original content. However, if, for example, the storage unit 110 in Figure 8A, which stores content, is configured as a RAID system that performs backup processing that users cannot directly access, then copies for backup purposes that users cannot directly access may be excluded from the above nine-copy limit. When making copies within the above nine-copy limit to an external device via an IP interface, it is necessary to manage the number of copies, such as one copy per authenticated external device. After generating the above-mentioned nine copies, the original content can be moved to an external device using the move process described above. This process of creating nine copies and moving one copy of the original content is equivalent to generating nine copies within the broadcast receiver 100 during content storage and moving all ten content items, including the original content, one by one to external devices.

The following describes the specific process for differentiating content protection based on the pixel count of the content when copying stored content to external devices.

(4-1) When storing 2K+ content (content with a pixel count exceeding 1920 x 1080) without performing pixel count conversion on received 2K+ content (content with a pixel count exceeding 1920 x 1080), or when storing 2K+ content (content with a pixel count exceeding 1920 x 1080) after performing pixel count conversion on received 2K+ content (content with a pixel count exceeding 1920 x 1080) and converting it to other 2K+ content (content with a pixel count exceeding 1920 x 1080), and not performing pixel count conversion when copying to an external device after storage.

In this case, the content to be copied to the external device is 2K or higher content (content with a resolution exceeding 1920 x 1080 pixels).

For content stored on a recording medium with copy control information set to "copyable without restrictions," content can be copied to an external device after storage without DTCP content protection. In this case, whether or not protection was specified by the value of the 'encryption_mode' parameter included in the content usage control descriptor at the time of storage is not considered.

For content stored on a recording medium with copy control information set to "re-copy prohibited," copying to external devices is prohibited. For content stored on a recording medium with copy control information set to "limited number of copies allowed," copying to an external device within the aforementioned limit of nine copies is possible using DTCP2, a more advanced content protection system than DTCP-IP. (In this case, the number of content copies can be managed by sending each copy target to the external device using DTCP2's move process. In this case, since the move process is performed on one content item within the nine-item limit, the number of copy target contents is reduced, resulting in a treatment equivalent to unplayable content, but it is not necessary to unplayable the original content itself outside the nine-item limit.) Note that even if an external device supports DTCP-IP content protection, it cannot play DTCP2-protected content if it does not support DTCP2 content protection (it will not receive DTCP2-protected content). Therefore, while DPCT2 offers stronger content protection, existing external devices cannot handle content protected by DTCP2. In contrast, DTCP-IP content protection, while unable to utilize DPCT2's new content protection flags, allows copying to existing DTCP-IP compatible external devices that are not DPCT2 compatible.

When copying stored content to an external device as 2K+ content (content with a pixel count exceeding 1920 x 1080), the content protection process performed according to the copy control information on the recording medium, as described above, will hereafter be referred to as the "2K+ content protection process" during copying to an external device after storage.

(4-2) When storing 2K+ content (content with a pixel count exceeding 1920 x 1080) without performing pixel count conversion on received 2K+ content (content with a pixel count exceeding 1920 x 1080), or when storing 2K+ content (content with a pixel count exceeding 1920 x 1080) after performing pixel count conversion on received 2K+ content (content with a pixel count exceeding 1920 x 1080) and then performing pixel count conversion on the stored 2K+ content (content with a pixel count exceeding 1920 x 1080) when copying to an external device after storage, and then converting to other 2K+ content.

In this case, the content to be copied to the external device is 2K+ content (content with a pixel count exceeding 1920 x 1080), and since it is the same as in (4-1) above, the "2K+ content protection processing" described in (4-1) for copying to the external device after storage is performed.

(4-3) When storing received 2K+ content (content with a pixel count exceeding 1920 x 1080) without performing pixel count conversion, or when storing received 2K+ content (content with a pixel count exceeding 1920 x 1080) converted to other 2K+ content (content with a pixel count exceeding 1920 x 1080) and then performing pixel count conversion to convert it to 2K or less content (content with a pixel count exceeding 1920 x 1080) during copying to an external device after storage,

In this case, the content to be copied to external devices is content of 2K resolution or lower (content with a resolution of 1920 x 1080 pixels or less).

In this case, for content stored on the recording medium with copy control information set to "copyable without restrictions," the content protection process is switched based on whether protection was specified or not, according to the value of the `encryption_mode` parameter included in the content usage control descriptor at the time of storage. Specifically, if the value of `encryption_mode` is 1 and content protection is not specified, the content can be copied to an external device after storage without DTCP content protection. If the value of `encryption_mode` is 0 and content protection is specified, the content can be copied to an external device after storage with DTCP protection (or DTCP-IP if copying via an IP interface). In this case, DTCP2 content protection is not necessary.

For content stored on a recording medium with copy control information set to "Re-copy prohibited," copying to external devices is prohibited. For content stored on a recording medium with copy control information set to "Number of copies allowed," copying to an external device within the aforementioned nine-copy limit requires DTCP protection (DTCP-IP if copying via an IP interface). In this case, DTCP2 content protection is not necessary. To achieve content-controlled copying, the DTCP move function may be used for each individual copy. In this case, since the move process is performed on one content item within the nine-copy limit, the number of copied content items is reduced, resulting in a treatment equivalent to unplayable content. However, unplayable content of the original content outside the nine-copy limit is not necessary.

When copying stored content to an external device as 2K or lower content (content with a resolution of 1920 x 1080 pixels or less), the content protection process performed according to the copy control information on the recording medium, as described above, will hereafter be referred to as the "2K or lower content protection process" during copying to an external device after storage.

(4-4) When receiving content exceeding 2K resolution (content with a pixel count exceeding 1920 x 1080) and converting it to 2K or less content (content with a pixel count of 1920 x 1080 or less), and then storing this 2K or less content (content with a pixel count of 1920 x 1080 or less), if no further pixel conversion is performed when copying the stored content to an external device.

In this case, the content to be copied to the external device is 2K or lower content (content with a resolution of 1920 x 1080 pixels or less), and is the same as in (4-3) above. Therefore, the "2K or lower content protection process" described in (4-3) for copying to the external device after storage is performed.

(4-5) When receiving content exceeding 2K resolution (content with a pixel count exceeding 1920 x 1080 pixels), performing a pixel count conversion to convert it to 2K or lower content (content with a pixel count of 1920 x 1080 pixels or less), and then storing that 2K or lower content (content with a pixel count of 1920 x 1080 pixels or less), and then performing a pixel count conversion again when copying it to an external device after storage to convert it to other 2K or lower content (content with a pixel count of 1920 x 1080 pixels or less).

In this case, the content to be copied to the external device is 2K or lower content (content with a resolution of 1920 x 1080 pixels or less), and is the same as in (4-3) above. Therefore, the "2K or lower content protection process" described in (4-3) for copying to the external device after storage is performed.

(4-6) When receiving content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less) and storing it without performing resolution conversion, or when receiving content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less) and then converting it to other content of 2K resolution or less (content with a resolution of 1920 x 1080 pixels or less) and storing it, and not performing resolution conversion when copying to an external device after storage.

In this case, the content to be copied to the external device is 2K or lower content (content with a resolution of 1920 x 1080 pixels or less), and is the same as in (4-3) above. Therefore, the "2K or lower content protection process" described in (4-3) for copying to the external device after storage is performed.

(4-7) When storing 2K or lower content (content with a resolution of 1920 x 1080 pixels or less) without performing pixel resolution conversion on the received content, or when storing 2K or lower content (content with a resolution of 1920 x 1080 pixels or less) after performing pixel resolution conversion on the received content, and then performing pixel resolution conversion again when copying to an external device after storage to another 2K or lower content (content with a resolution of 1920 x 1080 pixels or less)

In this case, the content to be copied to the external device is 2K or lower content (content with a resolution of 1920 x 1080 pixels or less), and is the same as in (4-3) above. Therefore, the "2K or lower content protection process" described in (4-3) for copying to the external device after storage is performed.

As explained in sections (4-1) through (4-7) above, when copying stored content to an external device, the content protection process is switched according to the pixel count of the content being copied to the external device. When copying content exceeding 2K resolution (content with a pixel count exceeding 1920 x 1080) to an external device, a higher level of content protection is applied than when copying content below 2K resolution (content with a pixel count of 1920 x 1080 or less) to an external device. This ensures that higher-value content exceeding 2K resolution (content with a pixel count exceeding 1920 x 1080) is properly protected on external devices.

Furthermore, when copying content stored as "copyable with quantity limit" to an external device within the aforementioned limit of 9 copies, regardless of whether the "2K or higher content protection processing" or the "2K or lower content protection processing" used during copying to an external device after storage, as explained in (4-1) through (4-7) above, is employed, the remaining number of copyable copies will be reduced by one equally. Therefore, there is no need to differentiate the copy count management itself based on the difference in content protection processing during copying.

Furthermore, for any of the external output, external move, and external copy processes described above, you should configure the system to prohibit output, move, or copy to external devices that do not support the content protection features described under each respective condition.

Furthermore, if the same received content is protected, and the 'digital_recording_control_data' information and 'encryption_mode' information are transmitted via the broadcast transmission path using multiple different tables or descriptors, or if they are transmitted via both the broadcast transmission path and the communication line using the same or different tables or descriptors, then the information with the highest priority should be used for the content protection process described in this embodiment, based on a predetermined priority determination process that considers the type of table or descriptor and the type of transmission path.

Furthermore, HDCP, the content protection method used for the external device output processing before and after storage, protects decoded video and other content, while DTCP, DTCP-IP, and DTCP2, used for processing such as moving and copying to external devices after storage, protect encoded video and other content. The nature of the protected content differs between these methods. Despite this, the threshold for switching content protection processing according to the pixel count in the broadcast receiver 100 of Example 3 is set equally at the boundary between content exceeding 2K (content with a pixel count exceeding 1920 x 1080) and content of 2K or less (content with a pixel count of 1920 x 1080 or less). By setting the switching threshold equal for content protection processing according to pixel count, even for content protection methods with different types of protected content, the number of conditional branches for switching content protection processing can be minimized, simplifying the process and proving effective.

According to Embodiment 3 of the present invention described above, the content protection process is switched according to the pixel count of the content, not only during the output process to external devices before content storage, but also during the output process to external devices, the move process to external devices, or the copy process to external devices after content storage. This allows for appropriate protection of high-value, high-resolution content even on external devices. Furthermore, during content storage, the process can be simplified by applying a common content protection method regardless of the content's pixel count. That is, when outputting, moving, or copying to various external devices, the content protection process is switched according to the content's pixel count, while the storage of content that can only be played on the local device itself can be simplified by applying a common content protection method regardless of the content's pixel count.

(Example 4)
The following describes Embodiment 4 of the present invention. Embodiment 4 of the present invention has the same hardware configuration as the broadcast receiver 800 in Embodiment 2, and the configuration, processing, and effects in this embodiment are the same as in Embodiment 2, except for the content protection processing. For this reason, the following will mainly describe the differences between this embodiment and Embodiment 2, and will omit explanations of common points as much as possible to avoid duplication.

Embodiment 4 of the present invention has a hardware configuration similar to the broadcast receiver 800 in Embodiment 2, but implements control to realize different copyright protection functions. Note that this embodiment describes content protection control for video content; for audio, control equivalent to the following description may be performed, or different content protection control may be performed.

Figure 29 summarizes the copyright protection function processing in the broadcast receiving device 800 of Example 4. In the broadcast receiving device 800 of Example 4, the copyright protection processing for the content before and after content storage is switched depending on whether the received content is 2K or lower content (content with a pixel count exceeding 1920 x 1080), such as 4K content (3840 x 2160 pixels) or 8K content (7680 x 4320 pixels), or 2K or lower content (content with a pixel count of 1920 x 1080 pixels or less).

In Figure 29, the content protection processing shown in the row where the transmission method is MMT is applied to the content being received and processed by the MMT decoding processing unit 841 of the broadcast receiver 800 in Figure 24. Since its content is identical to the content protection processing shown in Figure 28 in Example 3, its explanation is omitted.

On the other hand, in Figure 29, the content protection processing shown in the row where the transmission method is MPEG2-TS is content protection processing applied to the content received and processed by the MPEG2-TS decoding processing unit 842 of the broadcast receiver 800 in Figure 24.

In Embodiment 4 of the present invention, the broadcast receiver 800 receives content using the MPEG2-TS transmission method, and all such content is 2K or less (content with a pixel count of 1920 x 1080 or less).

Since the content received via the MPEG2-TS transmission method is all 2K or less content (content with a resolution of 1920 x 1080 pixels or less), the broadcast receiver 800 of Embodiment 4 of the present invention unifies the processing for both 2K or less content (content with a resolution of 1920 x 1080 pixels or less) received via the MPEG2-TS transmission method and 2K or less content (content with a resolution of 1920 x 1080 pixels or less) received via the MMT transmission method. Specifically, in both cases, content protection processing for 2K or less content (content with a resolution of 1920 x 1080 pixels or less) received via the MMT transmission method as described in Embodiment 3 should be performed.

Here, the format of the table in which control information used for content protection is transmitted differs between the MMT transmission method and the MPEG2-TS transmission method. Specifically, in the MMT transmission method, the content copy control descriptor and content usage control descriptor are transmitted, for example, mainly in MPT (also MH-EIT and MH-SDT). In contrast, in the MPEG2-TS transmission method, the corresponding copy control-related information, the digital copy control descriptor and content usage descriptor, are transmitted, for example, mainly in PMT (Program Map Table) (also EIT and SDT). Therefore, the format of both the table and the descriptors in which copy control-related information is transmitted differs.

However, the `digital_recording_control_data` and `copy_restriction_mode` parameters stored within the descriptor can use the same format for both the MMT transmission method and the MPEG2-TS transmission method. Therefore, in the broadcast receiver 800 of Embodiment 4 of the present invention, the interpretation of the `digital_recording_control_data` and `copy_restriction_mode` parameters, which specify content protection, is standardized for both the MMT transmission method and the MPEG2-TS transmission method.

This allows for the unification of the following processes for 2K or lower content (content with a resolution of 1920 x 1080 pixels or less) received via MPEG2-TS transmission and 2K or lower content (content with a resolution of 1920 x 1080 pixels or less) received via MMT transmission: external output processing before content storage, content storage processing, external output processing after content storage, content move processing to external devices after content storage, and content copy processing to external devices after content storage. The specific processing steps for each are the content protection processing applied to 2K or lower content (content with a resolution of 1920 x 1080 pixels or less) received via MMT transmission, as explained in Example 3. Since the details are already explained in Example 3, the explanation will be omitted here.

Furthermore, this standardization of processing means that content protection processing for 2K or less content (content with a resolution of 1920 x 1080 pixels or less) received via the MPEG2-TS transmission method can be standardized not only for 2K or less content (content with a resolution of 1920 x 1080 pixels or less) received via the MMT transmission method, but also for content exceeding 2K resolution (content with a resolution exceeding 1920 x 1080 pixels) received via the MMT transmission method. This standardization, achieved through pixel count conversion processing before or after content storage, significantly simplifies the processing.

According to Embodiment 4 of the present invention described above, the same effects as in Embodiment 3 can be obtained for content received using the MMT transmission method. Furthermore, for content with a predetermined number of pixels or less, content protection processing can be standardized for both content received using the MMT transmission method and content received using MPEG2-TS, not only for outputting content to external devices before content storage, but also for outputting content to external devices after storage, moving content to external devices, or copying content to external devices. This simplifies processing across transmission methods.

The embodiments of the present invention have been described above using Examples 1 to 4. However, the configurations that realize the technology of the present invention are not limited to these examples, and various modifications are conceivable. For example, it is possible to replace a part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. All of these fall within the scope of the present invention. Furthermore, the numbers and messages appearing in the text and figures are merely examples, and using different ones will not impair the effects of the present invention.

The functions and features of the present invention described above may be implemented in hardware, either partially or entirely, by designing them, for example, using integrated circuits. Alternatively, they may be implemented in software by a microprocessor unit or the like interpreting and executing operational programs that realize each function. Hardware and software may also be used in combination.

Furthermore, the software that controls the broadcast receiving device 100 may be pre-stored in the ROM 103 and/or storage unit 110 of the broadcast receiving device 100 at the time of product shipment. Alternatively, it may be acquired after product shipment from other application servers 500 on the Internet 200 via the LAN communication unit 121. Alternatively, the software stored on a memory card or optical disc may be acquired via the expansion interface unit 124.

Furthermore, the control lines and information lines shown in the diagram are those deemed necessary for explanation and do not necessarily represent all control lines and information lines present in the product. In reality, it can be assumed that almost all components are interconnected.

100,800…Broadcast receiving device, 100a…Antenna, 101,801…Main control unit, 102,802…System bus, 103,803…ROM, 104,804…RAM, 110,810…Storage unit, 121,821…LAN communication unit, 124,824…Expansion interface unit, 125,825…Digital interface unit, 131,831,832…Tuner/demodulation unit, 132…Separation unit, 141…Video decoder, 142…Video color gamut conversion unit, 143…Audio decoder, 144…Character super decoder, 145…Subtitle decoder, 146…Subtitle synthesis unit, 147…Subtitle color gamut conversion unit, 151…Data decoder, 152…Cache unit, 153…Application control unit, 154…Browser 155…Application color gamut conversion unit, 156…Sound source unit, 161, 861…Video synthesis unit, 162, 862…Monitor unit, 163, 863…Video output unit, 164, 864…Speech synthesis unit, 165, 865…Speaker unit, 166, 866…Speech output unit, 170, 870…Operation input unit, 841…MMT decoding processing unit, 842…MPEG2-TS decoding processing unit, 200…Internet, 200r…Router device, 200a…Access point, 300t…Radio tower, 300s…Broadcasting satellite (or communication satellite), 300…Broadcasting station server, 400…Service provider server, 500…Other application server, 600…Mobile telephone communication server, 600b…Base station, 700…Personal information terminal.

Claims (1)

A content protection processing method for a broadcast receiving device that receives broadcast program content transmitted by a broadcast signal from a broadcasting station,
A receiving step in which the broadcast signal is received by a tuner in the broadcast receiving device,
A demodulation step which involves demodulating the broadcast signal received in the reception step to obtain the broadcast program content,
A storage step for storing the broadcast program content demodulated in the demodulation step,
A video output processing step which outputs the video of the broadcast program content stored in the storage step via an interface different from the tuner that receives the broadcast signal in the reception step,
A copy processing step involves copying the broadcast program content stored in the storage step via an interface different from the tuner that receives the broadcast signal in the reception step,
A move processing step which performs move processing on the broadcast program content stored in the storage step via an interface different from the tuner that receives the broadcast signal in the reception step,
Equipped with,
When the broadcast program content is content transmitted from the broadcasting station via the broadcast signal with protection that allows for a predetermined number of copies, the storage step stores the broadcast program content in a state where it can be copied nine times and moved once, and is encrypted so that it can be played back only by the broadcast receiving device.
With respect to content transmitted from the broadcasting station via the broadcast signal while the broadcast program content is protected to allow copying a predetermined number of times, the content protection process when moving the broadcast program content stored in the storage step in the move processing step includes multiple different levels of content protection, such as content protection processing by DTCP-IP and content protection processing by DTCP2.
The storage in the storage step can be performed in a storage unit located at the output destination of the IP interface, via an IP interface composed of Ethernet-compatible hardware provided in the broadcast receiving device.
Even when the broadcast program content is transmitted from the broadcasting station via the broadcast signal with protection allowing a predetermined number of copies specified, and when different levels of content protection processing are performed on the content stored in the storage step, it is possible to perform a common content protection process without the need for different levels of content protection processing in the storage step for the content that is subject to the different levels of content protection processing in the move processing step.
Content protection processing method.