JP7744481B2 - Content protection processing method - Google Patents

Description

The present invention relates to a content protection processing method.

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

Japanese Patent Application Laid-Open No. 2001-186486

In response to recent changes in the content distribution environment, television receivers are also being required to expand their functionality in various ways. In particular, there is a strong demand for the distribution of content and linked applications using broadband network environments such as the Internet, as well as for higher resolution and definition video content. However, it is difficult to provide high-value-added television receivers that can meet these demands by simply reusing the data broadcasting reception functions and other features provided by current television receivers, or by simply expanding the functionality of said data broadcasting reception functions and other features.

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

The technology described in the claims is used as a means to solve the above problem.

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

1 is a configuration diagram of a broadcast communication system including a broadcast receiving device according to a first embodiment. FIG. 1 is an explanatory diagram of components of an encoded signal in MMT. FIG. 1 is a diagram illustrating the configuration of an MPU in MMT. FIG. 1 is a diagram illustrating the structure of an MMTP packet in MMT. FIG. 1 is a conceptual diagram of a protocol stack for a broadcasting system using MMT. FIG. 1 is a diagram showing a hierarchical structure of control information used in a broadcasting system. This is a list of tables used in the TLV-SI of the broadcasting system. This is a list of descriptors used in the TLV-SI of the broadcasting system. This is a list of messages used in MMT-SI of the broadcasting system. This is a list of tables used in MMT-SI of the broadcasting system. This is a list (1) of descriptors used in MMT-SI of the broadcasting system. This is a list (2) of descriptors used in MMT-SI of the broadcasting system. This is a list (3) of descriptors used in MMT-SI of the broadcasting system. FIG. 2 is a diagram showing the relationship between components of a broadcasting system and each table. A diagram showing the data structure of the MPT of the broadcasting system. FIG. 10 is a diagram showing the data structure of location information of a broadcasting system. A diagram showing the data structure of an MPU timestamp descriptor for a broadcasting system. A diagram showing the data structure of MH-EIT of a broadcasting system. FIG. 10 is a diagram illustrating the data structure of an event package descriptor for a broadcasting system. 1 is a block diagram of a broadcast receiving device according to a first embodiment. FIG. 2 is a configuration diagram of a logical plane structure of a presentation function of the broadcast receiving device according to the first embodiment. FIG. 2 is a software configuration diagram of the broadcast receiving device according to the first embodiment. FIG. 2 is a block diagram of a broadcast station server according to the first embodiment. FIG. 2 is a block diagram of a service provider server according to the first embodiment. FIG. 1 is a block diagram of a portable information terminal according to a first embodiment. FIG. 2 is a software configuration diagram of the portable information terminal according to the first embodiment. 1 is a system configuration diagram of clock synchronization/presentation synchronization of a broadcast receiving device according to a first embodiment. A diagram showing the NTP format data structure of a broadcasting system. A diagram showing the data structure of MH-TOT of the broadcasting system. FIG. 10 is a diagram illustrating the format of the JST_time parameter of a broadcasting system. A diagram showing the data structure of time information in the TMCC extension information area of a broadcasting system. 10 is a diagram showing a method for calculating the current date from the MJD of the broadcast receiving device according to the first embodiment. FIG. 4 is an operational sequence diagram of the broadcast receiving device according to the first embodiment during channel scanning. FIG. A diagram showing the data structure of TLV-NIT of a broadcasting system. FIG. 10 is a diagram illustrating the data structure of a satellite distribution system descriptor for a broadcasting system. FIG. 10 is a diagram illustrating the data structure of a service list descriptor for a broadcasting system. FIG. 1 is a diagram showing the data structure of an AMT of a broadcasting system. 4 is a diagram illustrating an operation sequence when selecting a channel in the broadcast receiving device according to the first embodiment. FIG. A conceptual diagram explaining the reference of the MPT of each package by the PLT of the broadcasting system. FIG. 1 is a diagram showing the data structure of a PLT of a broadcasting system. 1 is an external view of a remote control capable of controlling a broadcast receiving device according to a first embodiment. FIG. 10 is a diagram illustrating the data structure of a remote control key descriptor for a broadcasting system. FIG. 10 is a diagram illustrating a process for selecting multiple channels. FIG. 10 is a diagram illustrating the angle selection process for a multi-view compatible program. A diagram showing the data structure of an LCT of a broadcasting system. A diagram showing the data structure of an MPU presentation area designation descriptor for a broadcasting system. FIG. 10 illustrates the assignment of layouts to layout numbers based on the LCT. FIG. 10 illustrates the assignment of layouts to layout numbers based on the LCT. FIG. 10 illustrates the assignment of layouts to layout numbers based on the LCT. FIG. 10 illustrates the assignment of layouts to layout numbers based on the LCT. FIG. 10 is a diagram illustrating exception handling in screen layout control based on an LCT. FIG. 10 is a diagram illustrating exception handling in screen layout control based on an LCT. FIG. 10 is a diagram illustrating the data structure of a video component descriptor for a broadcasting system. FIG. 10 is a diagram illustrating the meaning of the video signal aspect ratio in the video component descriptor. 4A to 4C are diagrams illustrating aspect ratio conversion processing performed by the broadcast receiving device according to the first embodiment. 4A to 4C are diagrams illustrating aspect ratio conversion processing performed by the broadcast receiving device according to the first embodiment. FIG. 2 is a screen display diagram of an EPG screen of the broadcast receiving device according to the first embodiment. FIG. 2 is a screen display diagram of an EPG screen of the broadcast receiving device according to the first embodiment. FIG. 2 is a screen display diagram of an EPG screen of the broadcast receiving device according to the first embodiment. 3 is a diagram showing a screen display when an emergency alert broadcast is displayed on the broadcast receiving device according to the first embodiment. FIG. FIG. 10 is a diagram illustrating the data structure of a content copy control descriptor for a broadcasting system. FIG. 10 is a diagram showing the meaning of copy control information in a content copy control descriptor. FIG. 10 is a diagram showing the data structure of a content usage control descriptor for a broadcasting system. FIG. 10 is a block diagram of a broadcast receiving device according to a second embodiment. 10A and 10B are diagrams illustrating inconsistencies in the current time display when switching broadcast services. 10A and 10B are diagrams illustrating the operation of current time information reference source selection control according to the second embodiment. FIG. 10 is an operation sequence diagram of a current time information update process according to the second embodiment. FIG. 10 is a screen display diagram of an EPG screen of a broadcast receiving device according to a second embodiment. FIG. 10 is a screen display diagram of an EPG screen of a broadcast receiving device according to a second embodiment. FIG. 1 illustrates an application transmission method. FIG. 10 is a diagram illustrating types of assets. FIG. 10 is a diagram showing the data structure of location information of an asset acquisition destination. FIG. 10 is a diagram showing the meaning of asset acquisition destination types. A diagram showing the data structure of an MPU presentation area designation descriptor. A diagram showing the data structure of MH-AIT. FIG. 10 is a diagram illustrating the allocation of application types. FIG. 10 is a diagram illustrating the definition of an application control code. FIG. 10 is a diagram illustrating a data structure of an application identifier. A diagram showing the data structure of an MH-application descriptor. A diagram showing the data structure of an MH-transmission protocol descriptor. FIG. 10 is a diagram illustrating the meaning of protocol identification. FIG. 10 is a diagram illustrating the data structure of a selector area. A diagram showing the data structure of the MH-Simple Application Location Descriptor. A diagram showing the data structure of an MH-application boundary authority setting descriptor. A diagram showing the data structure of an MH-activation priority information descriptor. A diagram showing the data structure of an MH-cache information descriptor. A diagram showing the data structure of an MH-application expiration date descriptor. FIG. 10 illustrates the data structure of the MH-Probabilistic Adaptive Delay Descriptor. FIG. 11 is an operational sequence diagram of a broadcast receiving device according to a third embodiment when an application is started. FIG. 11 is an operational sequence diagram of a broadcast receiving device according to a third embodiment when an application is started. FIG. 11 is an operational sequence diagram of a broadcast receiving device according to a third embodiment when an application is started. FIG. 11 is an operational sequence diagram when the mobile information terminal according to the third embodiment cooperates with one another. FIG. 11 is an operational sequence diagram when the mobile information terminal according to the third embodiment cooperates with one another. 11 is an operational sequence diagram when an application is started in a broadcast receiving device and a mobile information terminal according to a third embodiment. FIG. FIG. 11 is a screen display diagram of a basic screen of a cooperative control application of a mobile information terminal according to a third embodiment. FIG. 11 is a screen display diagram of a basic screen of a cooperative control application of a mobile information terminal according to a third embodiment. FIG. 11 is a screen display diagram of a notification screen of a broadcast receiving device according to a third embodiment. FIG. 11 is a diagram illustrating a screen display of a broadcast cooperative application launcher of a broadcast receiving device according to a third embodiment. FIG. 11 is a screen display diagram of a data broadcast screen of a broadcast receiving device according to a third embodiment. FIG. 11 is a screen display diagram of a broadcast cooperative application execution screen of a broadcast receiving device according to a third embodiment. FIG. 11 is a screen display diagram of a broadcast cooperative application execution screen of a broadcast receiving device according to a third embodiment. FIG. 11 is a screen display diagram of a broadcast cooperative application execution screen of a broadcast receiving device according to a third embodiment. FIG. 11 is a screen display diagram of a broadcast cooperative application execution screen of a broadcast receiving device according to a third embodiment. FIG. 11 is a diagram showing an error display screen of a broadcast receiving device according to a third embodiment. FIG. 11 is a screen display diagram of a broadcast cooperative application execution screen of a mobile information terminal according to a third embodiment. FIG. 11 is a diagram showing detailed information on an EPG display screen of a broadcast receiving device according to a third embodiment. FIG. 11 is a diagram showing detailed information on an EPG display screen of a broadcast receiving device according to a third embodiment. FIG. 11 is a diagram showing detailed information on an EPG display screen of a broadcast receiving device according to a third embodiment. FIG. 11 is a diagram showing detailed information on an EPG display screen of a broadcast receiving device according to a third embodiment. FIG. 11 is a diagram showing detailed information on an EPG display screen of a broadcast receiving device according to a third embodiment. FIG. 11 is a diagram showing detailed information on an EPG display screen of a broadcast receiving device according to a third embodiment. FIG. 11 is an operational sequence diagram of a broadcast receiving device according to a third embodiment when acquiring a broadcast cooperative app. FIG. 11 is an operational sequence diagram when a broadcast cooperative application is acquired by a mobile information terminal according to a third embodiment. A diagram showing the data structure of an MH-application descriptor. FIG. 10 is an operational sequence diagram during terminal cooperation according to the fourth embodiment. FIG. 13 is an operational sequence diagram during terminal cooperation according to a fifth embodiment. FIG. 13 is an operational sequence diagram during terminal cooperation according to the sixth embodiment. FIG. 13 is an operational sequence diagram during terminal cooperation according to the sixth embodiment. FIG. 13 is a diagram illustrating a screen display of a broadcast cooperative application launcher of a broadcast receiving device according to a seventh embodiment. FIG. 13 is a diagram illustrating a screen display of a broadcast cooperative application launcher of a broadcast receiving device according to a seventh embodiment. FIG. 13 is a diagram illustrating a screen display of a broadcast cooperative application launcher of a broadcast receiving device according to a seventh embodiment. FIG. 13 is a diagram illustrating a screen display of a broadcast cooperative application launcher of a broadcast receiving device according to a seventh embodiment. FIG. 13 is a diagram showing a screen display of a broadcast receiving device according to a seventh embodiment. FIG. 13 is a diagram illustrating a screen display of a broadcast cooperative application of a mobile information terminal according to a seventh embodiment.

An example embodiment of the present invention will be described below with reference to the drawings.

Example 1
[System configuration]
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 is composed of a broadcast receiving device 100 and an antenna 100a, a broadband network such as the Internet 200, a router device 200r and an access point 200a, a broadcast station radio tower 300t and a broadcast satellite (or communication satellite) 300s, a broadcast station server 300, a service provider server 400, other application servers 500, a mobile telephone communication server 600 and a base station 600b of a mobile telephone communication network, and a portable information terminal 700.

Broadcast receiving device 100 receives broadcast waves transmitted from radio tower 300t via broadcast satellite (or communication satellite) 300s and antenna 100a. Alternatively, broadcast waves transmitted from radio tower 300t may be received directly from antenna 100a without going through broadcast satellite (or communication satellite) 300s. Broadcast receiving device 100 can also connect to Internet 200 via router device 200r, enabling it to send and receive data via communication with various server devices and other communication devices on Internet 200.

The router device 200r is connected to the Internet 200 via wired communication, and is connected to the broadcast receiving device 100 via wired or wireless communication, and to the mobile information terminal 700 via wireless communication. The wireless communication may use a method such as Wi-Fi (registered trademark). This allows each server device and other communication device on the Internet 200 to transmit and receive data to and from the broadcast receiving device 100 and the mobile information terminal 700 via the router device 200r. Note that communication between the broadcast receiving device 100 and the mobile information terminal 700 may also be performed directly using a method such as Bluetooth (registered trademark) or NFC (Near Field Communication), without going through the router device 200r.

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

The service provider server 400 is a server device provided by a service provider, and is capable of providing various services linked to broadcast programs distributed by broadcast stations. The service provider server 400 also stores, manages, and distributes video content and metadata provided by the broadcast 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. 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 broadcast station and the service provider may be the same or different. Multiple service provider servers 400 may be provided for different services. The functions of the service provider server 400 may also be provided by the broadcast station server 300.

The other application servers 500 are well-known server devices that store, manage, and distribute other general applications, operating programs, content, data, etc. There may be multiple other application servers 500 on the Internet 200.

Mobile telephone communication server 600 is connected to the Internet 200, and is also connected to mobile information terminal 700 via base station 600b. Mobile telephone communication server 600 manages telephone communications (calls) and data transmission and reception via the mobile telephone communication network for mobile information terminal 700, enabling data transmission and reception between mobile information terminal 700 and various server devices and other communication devices on the Internet 200. Communication between base station 600b and mobile information terminal 700 may be performed using the W-CDMA (Wideband Code Division Multiple Access) (registered trademark) system, GSM (Global System for Mobile communications) (registered trademark) system, LTE (Long Term Evolution) system, or other communication systems.

The mobile information terminal 700 is assumed to have the functions of telephone communication (calls) and data transmission/reception via a mobile telephone communication network, as well as wireless communication functions such as Wi-Fi (registered trademark). The mobile information terminal 700 can connect to the Internet 200 via a router device 200r or an access point 200a, or via a base station 600b of the mobile telephone communication network and a mobile telephone communication server 600, 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 via wired communication, and is connected to the mobile information terminal 700 via wireless communication. The wireless communication may use a method such as Wi-Fi (registered trademark). Note that communication between the mobile information terminal 700 and the broadcast receiving device 100 may be performed via the access point 200a, the Internet 200, and the router device 200r, or via the base station 600b, the mobile telephone communication server 600, the Internet 200, and the router device 200r.

[Overview of the MMT method]
1 is a television receiver that is compatible with MMT (MPEG Media Transport), instead of TS (Transport Stream) (hereinafter referred to as MPEG2-TS) defined in the MPEG (Moving Picture Experts Group)-2 system, which is widely used in conventional digital broadcasting systems as a media transport method for transmitting data such as video and audio. The television receiver may also be compatible with both MPEG2-TS and MMT.

MPEG2-TS is characterized by multiplexing the video, audio, and other components that make up a program into a single stream along with control signals and a clock. Because the clock is also treated 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, in recent years, the diversification of content, the diversification of devices that use content, the diversification of transmission paths for delivering content, and the diversification of content storage environments have all led to limitations in the functionality of MPEG2-TS in response to changes in the content distribution environment. Therefore, a newly developed media transport method is MMT.

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

An MFU is a transmission format for video, audio, etc., and may be configured in NAL (Network Abstraction Layer) units or access units. An MPU includes one or more access units and is capable of decoding video and audio on its own. An MPU may be configured with MPU metadata containing information about the overall configuration of the MPU, movie fragment metadata containing information about the encoded media data, and sample data, which is the encoded media data. A single MPU may contain multiple pieces of movie fragment data and sample data. It is also possible to extract an MFU from the sample data. Figure 2B shows an example of an MPU configuration. By adding a sequence number to each MPU belonging to the same asset, it is possible to distinguish any MPU from other MPUs using the asset ID that identifies the asset and the MPU sequence number. For media such as video components and audio components, the presentation time and decoding time may be specified on an MPU or access unit basis.

An MMTP packet consists of a header section and an MMTP payload, and transmits control information for the MFU and MMT. The MMTP payload has a payload header corresponding to the content (data unit) stored in the payload section. Figure 2C shows an example of an overview of how an MFU is constructed from video/audio signals, then stored in the MMTP payload to construct an MMTP packet. Note that for video signals encoded using inter-frame prediction, it is desirable to construct MPUs in GOP (Group of Pictures) units. Furthermore, if the size of the MFU to be transmitted is small, one MFU may be stored in one payload section, or multiple MFUs of the same type may be stored in one payload section. Furthermore, if the size of the MFU to be transmitted is large, one MFU may be divided and stored in multiple payload sections. In addition, MMTP packets may be protected using techniques such as AL-FEC (Application Layer Forward Error Correction) and ARQ (Automatic Repeat Request) to recover from packet loss on the transmission path.

In the broadcasting 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 the video and audio of the broadcast program encoded using each of the above methods is in MFU or MPU format, and then loaded onto an MMTP payload for MMTP packetization and transmitted in IP (Internet Protocol) packets. Data content related to the broadcast program may also be in MFU or MPU format, and then loaded onto an MMTP payload for MMTP packetization and transmitted in IP packets. Four types of data content transmission methods will be available: (1) a subtitle/superimposed text transmission method used for streaming data synchronized with broadcasting; (2) an application transmission method used for data transmission services asynchronous with broadcasting; (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 synchronous/asynchronous transmission of other general-purpose data.

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

The broadcasting system of this embodiment provides a mechanism for transmitting two types of control information: MMT-SI (MMT-Signaling Information) and TLV-SI (TLV-Signaling Information). MMT-SI is control information that indicates the configuration of a broadcast program, etc. It is formatted as an MMT control message, placed in an MMTP payload, packetized as an MMTP packet, and transmitted in an IP packet. TLV-SI is control information related to multiplexing of IP packets, and provides information for channel selection and information on the correspondence between IP addresses and services.

In addition, in broadcasting systems using MMT, time information is transmitted to provide absolute time. While MPEG2-TS indicates the display time of components based on a different clock for each TS, MMT indicates the display time of components based on Coordinated Universal Time (UTC). These mechanisms enable terminal devices to synchronize and display components transmitted from different transmission points over different transmission paths. To provide UTC, IP packets in NTP (Network Time Protocol) format are used.

[Control information for broadcasting systems using MMT]
As described above, the broadcast system compatible with the broadcast receiving device 100 of this embodiment provides the following control information: TLV-SI, which relates to the TLV multiplexing method for multiplexing IP packets, and MMT-SI, which relates to the MMT media transport method. TLV-SI provides information for the broadcast receiving device 100 to demultiplex IP packets multiplexed onto the broadcast transmission path. TLV-SI is composed of "tables" and "descriptors." Tables are transmitted in section format, and "descriptors" are placed within the "tables." MMT-SI is transmission control information that indicates the configuration of MMT packages and information related to broadcast services. MMT-SI is composed of three layers: "messages" that store "tables" and "descriptors,""tables" that contain elements and attributes indicating specific information, and "descriptors" that indicate 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>
5A shows a list of "tables" used in the TLV-SI of the broadcast system supported by the broadcast receiving device 100 of this embodiment. In this embodiment, the following "tables" are used as TLV-SI "tables."

(1) TLV-NIT
The Network Information Table for TLV (TLV-NIT) represents information about the physical configuration of TLV streams transmitted by a network and the characteristics of the network itself.

(2) AMT
The Address Map Table (AMT) provides a list of multicast groups for the IP packets that make up each service transmitted in the network.

(3) Tables Set by Service Providers In addition, service providers and the like can prepare tables that they have set independently.

<Descriptors used in TLV-SI>
5B shows a list of "descriptors" placed in the TLV-SI of the broadcasting system supported by the broadcast receiving device 100 of this embodiment. In this embodiment, the following "descriptors" are used as TLV-SI "descriptors."

(1) Service List Descriptor The service list descriptor provides a list of services by service identification and service format type.

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

(3) System Management Descriptor The system management descriptor is used to distinguish between broadcast and non-broadcast.

(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 set the service to be assigned to the one-touch channel selection button on the receiver remote control.

(6) Descriptors Set by Service Providers In addition, service providers and the like can prepare their own descriptors.

<Messages used in MMT-SI>
6A shows a list of "messages" used in MMT-SI of the broadcasting system supported by the broadcast receiving device 100 of this embodiment. In this embodiment, the following "messages" are used in MMT-SI.

(1) PA Message The Package Access (PA) message is used to transmit various tables.

(2) M2 Section Message The M2 section message is used to transmit the section extension format of the MPEG-2 Systems.

(3) CA Message The CA message is used to transmit a table for identifying the conditional access system.

(4) M2 Short Section Message The M2 Short Section Message is used to transmit the section short format of the MPEG-2 Systems.

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

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

<Tables used in MMT-SI>
FIG. 6B shows a list of "tables" used in MMT-SI of the broadcasting system supported by the broadcast receiving device 100 of this embodiment. A table is control information having elements and attributes indicating specific information, and is stored in a message and transmitted in an MMTP packet. Note that the message that stores the table may be determined depending on the table. In this embodiment, the following "tables" are used for MMT-SI.

(1) MPT
The MMT Package Table (MPT) provides information that configures a package, such as a list of assets and their locations on the network, etc. The MPT may be stored in a PA message.

(2) PLT
The package list table (PLT) indicates a list of IP data flows and packet IDs that transmit PA messages of MMT packages provided as broadcast services, and IP data flows that transmit IP services. The PLT may be stored in the PA message.

(3) LCT
A Layout Configuration Table (LCT) is used to associate layout information for presentation with a layout number, and may be stored in a PA message.

(4) ECM
An Entitlement Control Message (ECM) is common information consisting of program information and control information, and 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, key information for decrypting ECM (common information), etc. The EMM may be stored in an M2 section message.

(6) CAT(MH)
The Conditional Access Table (CAT) (MH) is used to store a descriptor for identifying a conditional access system. The CAT (MH) may be stored in a CA message.

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

(8) DMM
The Download Management Message (DMM) transmits key-related information such as a download key for decrypting the DCM. The DMM may be stored in the M2 section message.

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

(10) MH-AIT
The MH-Application Information Table (MH-AIT) stores all information related to applications and the activation state required for the application, etc. The MH-AIT may be stored in the M2 section message.

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

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

(13) MH-SDT
The MH-Service Description Table (MH-SDT) has sub-tables that represent services included in a specific TLV stream, and transmits information about the channel, such as the channel name, the broadcaster name, etc. The MH-SDT may be stored in the M2 section message.

(14) MH-TOT
The MH-Time Offset Table (MH-TOT) carries JST time and date (Modified Julian Date) information. The MH-TOT may be stored in the M2 short section message.

(15) MH-CDT
The MH-Common Data Table (MH-CDT) is used to transmit common data in section format to be stored in non-volatile memory for 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 a directory structure of files that constitute an application in order to separate the file structure of the application from the structure for file transmission. The DDM table may be stored in a data transmission message.

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

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

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

(20) Tables Set by Service Providers In addition, service providers and the like can prepare tables that they set independently.

<Descriptors used in MMT-SI>
6C, 6D, and 6E show a list of "descriptors" arranged in the MMT-SI of the broadcasting system supported by the broadcast receiving device 100 of this embodiment. Descriptors are control information that provide more detailed information and are arranged in a table. Note that the table in which a descriptor is arranged may be determined depending on the descriptor. In this embodiment, the following "descriptors" are used in the MMT-SI.

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

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

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

(4) MPU Presentation Area Designation Descriptor The MPU presentation area designation descriptor provides the location where the MPU is to be presented. The MPU presentation area designation 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 presentation order in the MPU. The MPU Timestamp Descriptor may be placed in the MPT.

(6) Dependency Descriptor The dependency descriptor provides the asset ID of the asset that is in dependency. The dependency descriptor may be placed in the MPT.

(7) Access Control Descriptor The access control descriptor provides information for identifying the conditional access method. The access control descriptor may be placed in the MPT or CAT (MH).

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

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

(10) Emergency Information Descriptor (MH)
The emergency information descriptor (MH) is used when an emergency alert is broadcast, and 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 specifying the coding parameters of an audio stream of 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 settings specific to the encoding method. 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 basic coding parameters of a video stream (HEVC stream) of 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 the service that will be provided if a viewer requests additional information related to a particular listing in the program service 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 multiple events are grouped when there is a relationship between them. The MH-Event Group Descriptor may be placed in the 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 located in the MH-BIT.

(17) MH-Short Event Descriptor The MH-Short Event Descriptor represents the event name and a short description of the event in text form. The MH-Short Event Descriptor may be placed in the 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 an event. The MH-Extended Event Descriptor may be placed in the MH-EIT.

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

(20) MH-Stream Identification Descriptor The MH-Stream Identification Descriptor is used to label a component stream of a service and to reference the description indicated by the video component descriptor in the MH-EIT using this label. The MH-Stream Identification 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 the MH-EIT.

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

(23) MH-Audio Component Descriptor The MH-Audio Component Descriptor indicates each parameter of an audio elementary stream and is also used to express the elementary stream in text form. The MH-Audio Component Descriptor may be placed in the MPT or the MH-EIT.

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

(25) MH-Series Descriptor The MH-Series Descriptor is used to identify a series of programs. 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 name of the channel and its operator together with the service format type in character codes. The MH-Service Descriptor may be placed in the MH-SDT.

(29) IP Data Flow Descriptor The IP Data Flow Descriptor provides information about the IP data flows that constitute a service. The IP Data Flow Descriptor may be located in the MH-SDT.

(30) MH-CA Activation Descriptor The MH-CA activation descriptor describes activation information for activating a CAS program on the CAS platform. The MH-CA activation descriptor may be located in the MPT or CAT (CA).

(31) MH-Type Descriptor The MH-Type descriptor indicates the type of file transmitted in 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 an item. The MH-Info descriptor may be placed in a 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 indicates 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 Coding Scheme Descriptor The MH-Data Coding Scheme Descriptor is used to identify a data coding scheme. The MH-Data Coding Scheme Descriptor may be placed in the MPT.

(36) UTC-NPT Reference Descriptor The UTC-NPT reference descriptor is used to convey the relationship between the NPT (Normal Play Time) and the UTC. The UTC-NPT reference descriptor may be placed in the EMT.

(37) Event Message Descriptor The event message descriptor conveys information about event messages in general. The event message descriptor may be placed in the EMT.

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

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

(40) MH-Logo Transmission Descriptor The MH-Logo Transmission Descriptor is used to describe a simple logo character string, 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 decoding time of an access unit in an MPU. The MPU extended timestamp descriptor may be placed in the MPT.

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

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

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

(45) MH-Transmission Protocol Descriptor The MH-Transmission Protocol Descriptor is used to specify a transmission protocol such as broadcasting or communication and to indicate location information of an application that depends on the transmission protocol. The MH-Transmission Protocol Descriptor may be placed in the MH-AIT.

(46) MH-Simple Application Location Descriptor The MH-Simple Application Location Descriptor is written to indicate details of where to obtain an application. The MH-Simple Application Location Descriptor may be placed in the MH-AIT.

(47) MH-Application Boundary Authority Setting Descriptor The MH-Application Boundary Authority Setting Descriptor is used to set an application boundary and to set broadcast resource access authority for each area (URL). The MH-Application Boundary Authority Setting Descriptor may be placed in the MH-AIT.

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

(49) MH-Cache Information Descriptor The MH-Cache Information Descriptor is written to be used for cache control when the resources constituting an application are cached and stored when the application is expected to be reused. The MH-Cache Information Descriptor may be placed in the MH-AIT.

(50) MH-Probabilistic Application Delay Descriptor The MH-Probabilistic Application Delay Descriptor is used 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 the MH-AIT.

(51) Link Destination PU Descriptor The link destination PU descriptor describes other presentation units that may transition from the presentation unit (PU). The link destination PU descriptor may be placed in the DCC table.

(52) Lock Cache Designation Descriptor The lock cache designation descriptor describes the designation of a file to be cached and locked in the presentation unit. The lock cache designation descriptor may be placed in the DCC table.

(53) Unlock Cache Designation Descriptor The unlock cache designation descriptor describes the designation of a file to be unlocked among the files locked in the presentation unit. The unlock cache designation 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 an MMTP packet that transmits a DCM or DMM. The MH-Download Protection Descriptor may be placed in the MPT or MH-SDTT.

(55) Application Service Descriptor The application service descriptor describes entry information of an application related to a service, etc. The application service descriptor may be placed in the MPT.

(56) MPU Node Descriptor The 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 a presentation unit as mapping information between the presentation unit and a transmission unit. The PU configuration descriptor may be arranged in the DCC table.

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

(59) Content Copy Control Descriptor The content copy control descriptor indicates information for controlling the copy generation in a digital recording device for the entire service, and is used by a broadcasting station (copyright holder) to convey copy-related information or the maximum transmission rate to a digital recording device when digital recording is expected. 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 about copy control and remote viewing control for a program when storing the program on a hard disk or the like or when 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 In addition, service providers and the like can prepare their own descriptors.

<Relationship between data transmission and each control information in the MMT system>
7A, the relationship between each component such as video and audio transmitted by the broadcast system supported by the broadcast receiving device 100 of this embodiment and a representative table of MMT-SI will be described. Note that in the MMT method, a component is defined as an asset, and hereinafter, a component may be referred to as an asset.

In the broadcasting system supported by the broadcast receiving device 100 of this embodiment, data can be transmitted via multiple routes, such as a TLV stream via a broadcast transmission path and an IP data flow via a communication line. A TLV stream contains TLV-SI such as TLV-NIT and AMT, and an IP data flow, which is a data flow of IP packets. An IP data flow contains video assets containing a series of video MPUs and audio assets containing a series of audio MPUs. Similarly, an IP data flow may contain subtitle assets containing a series of subtitle MPUs, superimpose assets containing a series of superimpose MPUs, data assets containing a series of data MPUs, etc.

These various assets are associated with a "package" through descriptions in the MPT (MMT Package Table), which is stored and transmitted in a PA message. Specifically, this association can be achieved by describing in the MPT a package ID that identifies the package and an asset ID that identifies each asset included in that package. Figure 7B shows an example of the data structure of an MPT. 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 that make up a package can consist only of assets in a TLV stream, but as shown in Figure 7A, they can also include assets transmitted via the IP data flow of a communication line. This can be achieved by describing the location information of each asset included in the package along with an asset ID that identifies the asset in the MPT, allowing the broadcast receiving device 100 of this embodiment to determine the reference destination of each asset. The location information is specified by "MMT_general_location_info()" in the data structure of the MPT shown in Figure 7B. Figure 7C shows an example of the data structure of location information.

Depending on the value of the "location_type" parameter of the location information,
(1) Data multiplexed in the same IP data flow as the MPT (location_type = 0x00)
(2) Data multiplexed in IPv4 data flow (location_type = 0x01)
(3) Data multiplexed in IPv6 data flow (location_type = 0x02)
(4) Data multiplexed into the broadcast MPEG2-TS (location_type = 0x03)
(5) Data multiplexed in IP data flow in MPEG2-TS format (location_type = 0x04)
(6) Data at the specified URL (location_type = 0x05)
It is possible to configure the broadcast receiving device 100 so that it can refer to various types of data transmitted via various transmission paths, such as the above.

Of the above references, (1) is, for example, an IP data flow included in the TLV stream of a digital broadcast signal received by the broadcast receiving device 100 of this embodiment via antenna 100a. However, if the MPT is also transmitted as part of the IP data flow on the communication line, 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. Furthermore, (4) can be used, for example, in the case of a broadcast receiving device that has both the receiving function for receiving digital broadcast signals using the MMT system and the receiving function for receiving digital broadcast signals using the MPEG2-TS system, such as the broadcast receiving device 800 of Example 2 described below, to reference data multiplexed into the MPEG2-TS received by the receiving function for receiving digital broadcast signals using the MPEG2-TS system based on the location information in the MPT included in the digital broadcast signal using the MMT system.

In addition, for media such as video components and audio components, presentation times and decode times can be specified on an MPU or access unit basis. Information regarding the presentation time and decode time 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 information regarding the presentation time. The presentation time information for each MPU is specified by the "mpu_presentation_time" parameter of the MPU timestamp descriptor. The MPU to be specified can be identified by the "mpu_sequence_number" parameter. In this embodiment, the broadcast receiving device 100 uses this presentation time information to present (display, output, etc.) multiple MPUs specified by the MPT in a synchronized manner based on a clock based on NTP, which is time information in UTC notation. Information regarding the decode time is also described by an MPU extended timestamp descriptor, but detailed description is omitted. The presentation control of various data using this NTP-based clock will be discussed later.

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

[Hardware configuration of broadcast receiving device]
8A is a block diagram showing an example of the internal configuration of broadcast receiving device 100. Broadcast receiving device 100 is composed of a main control unit 101, a system bus 102, a ROM 103, a RAM 104, a storage (accumulation) unit 110, a LAN communication unit 121, an extension interface unit 124, a digital interface unit 125, a tuner/demodulator unit 131, a separator unit 132, a video decoder 141, a video color gamut conversion unit 142, an audio decoder 143, a superimposed character 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 in accordance with 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.

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

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

The operating programs stored in ROM 103 and storage unit 110 can be added to, updated, and have their functions expanded by downloading them 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 to and from each server device and other communication devices on the Internet 200. It also acquires the MMT data string (or a portion thereof) of a program transmitted via a communication line. The connection to the router device 200r may be wired or wireless, such as via Wi-Fi (registered trademark). The LAN communication unit 121 includes an encoding circuit, a decoding circuit, etc. The broadcast receiving device 100 may also include 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 user's desired service under the control of the main controller 101. Furthermore, the tuner/demodulator 131 demodulates the received broadcast signal to obtain an MMT data sequence. Note that while the example shown in Figure 8A illustrates a configuration with one tuner/demodulator, the broadcast receiving device 100 may also be configured to include multiple tuner/demodulators for purposes such as simultaneous display on multiple screens or recording of other programs.

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

The video decoder 141 decodes the video data stream 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 necessary for video synthesis processing in the video synthesis unit 161. The audio decoder 143 decodes the audio data stream input from the separation unit 132 and outputs the audio information. Streaming data in MPEG-DASH (MPEG-Dynamic Adaptive Streaming over HTTP) format, for example, acquired from the Internet 200 via the LAN communication unit 121 may also be input to the video decoder 141 and audio decoder 143. A plurality of video decoders 141, video color gamut conversion units 142, audio decoders 143, etc. may be provided to simultaneously decode multiple types of video data streams and audio data streams.

The superimposed text decoder 144 decodes the superimposed text data string input from the separation unit 132 and outputs superimposed text information. The subtitle decoder 145 decodes the subtitle data string input from the separation unit 132 and outputs subtitle information. The superimposed text information output from the superimposed text decoder 144 and the subtitle information output from the subtitle decoder 145 are combined in the subtitle composition unit 146, and furthermore, the subtitle color gamut conversion unit 147 performs color space conversion processing as necessary for the video composition processing in the video composition unit 161. Note that in this embodiment, of the services centered on text information presented simultaneously with the video of a broadcast program, those related to the content of the video are referred to as subtitles, and other services are referred to as superimposed text. Furthermore, when there is no need to distinguish between them, they will be 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 in accordance with instructions from the application control unit 153, which interprets control information contained in the MMT data string 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 necessary in 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 influencing the sound source unit 156.

The video synthesis unit 161 inputs the video information output from the video color gamut conversion unit 142, the subtitle information output from the subtitle color gamut conversion unit 147, the application information output from the application color gamut conversion unit 155, etc., and performs processing such as selection and/or superimposition as appropriate. The video synthesis unit 161 is equipped with a video RAM (not shown), and drives the monitor unit 162 etc. based on the video information etc. input to the video RAM. Furthermore, under the control of the main control unit 101, the video synthesis unit 161 performs scaling processing and superimposition processing of EPG (Electronic Program Guide) screen information created based on information such as the MH-EIT included in the MMT-SI, as necessary. 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 the video information that has been selected and/or superimposed by the video synthesis unit 161.

The presentation function of the broadcast receiving device 100 in this embodiment is equipped with a logical plane structure to display multimedia services as intended by the provider. Figure 8B shows an example of the logical plane structure of the presentation function of the broadcast receiving device 100 in this embodiment. In this logical plane structure, a text superimposition plane for displaying text superimpositions is placed in the foreground, and a subtitle plane for displaying subtitles is placed in the next layer. A multimedia plane for displaying broadcast video, multimedia applications, or composite video thereof is placed in the third layer, and a background plane is placed in the background. The subtitle synthesis unit 146 and the video synthesis unit 161 draw text superimposition information on the text superimposition plane, subtitle information on the subtitle plane, and video information, application information, etc. on the multimedia plane. In addition, a background color is drawn on the background plane based on the LCT, etc. included in the MMT-SI. It is possible to provide multiple third-layer multimedia planes 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 is output only to the foreground multimedia plane.

The audio synthesis unit 164 inputs the audio information output from the audio decoder 143 and the application audio information played by the sound source unit 156, and performs processing such as selection and/or mixing as appropriate. The speaker unit 165 provides the audio information selected and/or mixed by the audio 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 audio synthesis unit 164.

The expansion interface unit 124 is a group of interfaces for expanding the functionality of the broadcast receiving device 100, and in this embodiment is composed of an analog video/audio interface, a USB (Universal Serial Bus) interface, a memory interface, etc. The analog video/audio interface inputs analog video/audio signals from external video/audio output devices, outputs analog video/audio signals to external video/audio input devices, etc. The USB interface connects to a PC or the like to send and receive data. A 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 to send and receive data.

Digital interface unit 125 is an interface that outputs or inputs encoded digital video data and/or digital audio data. Digital interface unit 125 is capable of directly outputting an MMT data string obtained by demodulation in tuner/demodulation unit 131, an MMT data string obtained via LAN communication unit 121, or mixed data of the above MMT data strings. It may also be possible to control the MMT data string input from digital interface unit 125 to be input to separation unit 132. Digital content stored in storage unit 110 may be output or digital content may be stored in storage unit 110 via digital interface unit 125.

The digital interface unit 125 may be a DVI terminal, HDMI (registered trademark) terminal, DisplayPort (registered trademark) terminal, etc., which outputs or inputs data in a format conforming to the DVI specification, HDMI specification, DisplayPort specification, etc. It may also output or input data in the form of serial data conforming to the IEEE 1394 specification, etc. It may also be configured as an IP interface that outputs digital interface data via hardware such as Ethernet (registered trademark) or wireless LAN. In this case, the digital interface unit 125 and the LAN communication unit 121 may share the same hardware configuration.

The operation input unit 170 is an instruction input unit that inputs operation instructions to the broadcast receiving device 100, and in this embodiment is configured with a remote control receiving unit that receives commands transmitted from a remote control (not shown) and an operation key with an array of button switches. Only one of these may be provided. The operation input unit 170 may also be replaced by a touch panel placed on top of the monitor unit 162. It may also be replaced by a keyboard or the like connected to the extended interface unit 124. The remote control (not shown) may also be replaced by a mobile 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 a television receiver, 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 broadcast reception functionality and broadcast communication linkage functionality. If the broadcast receiving device 100 is a DVD recorder, HDD recorder, STB, etc., the monitor unit 162 and the speaker unit 165 may not be included. By connecting an external monitor and external speakers to the video output unit 163 and audio output unit 166 or the digital interface unit 125, it becomes possible to perform operations similar to those of the broadcast receiving device 100 of this embodiment.

[Software configuration of broadcast receiving device]
8C is a software configuration diagram of the broadcast receiving device 100 of this embodiment, showing the software configuration in the ROM 103, RAM 104, and storage (accumulation) unit 110. In this embodiment, a basic operation program 1001 and other operation programs are stored in the ROM 103, and a reception function program 1002, a linkage function program 1003, a recording/playback function program 1004, and other operation programs are stored in the storage (accumulation) unit 110. The storage (accumulation) unit 110 is also assumed to include a content storage area 1200 for storing content such as moving images, still images, and audio, an authentication information storage area 1300 for storing authentication information and the like required when accessing external mobile terminal devices and each server device, and various information storage areas for storing various other information.

The basic operation program 1001 stored in ROM 103 is loaded into RAM 104, and the main control unit 101 executes the loaded basic operation program 1001 to form a basic operation execution unit 1101. The reception function program 1002, collaboration function program 1003, and recording/playback function program 1004 stored in the storage unit 110 are also loaded into RAM 104, and the main control unit 101 executes the loaded reception function program 1002, collaboration function program 1003, and recording/playback function program 1004 to form the reception function execution unit 1102, collaboration function execution unit 1103, and recording/playback function execution unit 1104. The RAM 104 also has a temporary storage area for temporarily storing data created when each operation program is executed, as needed.

In the following, for simplicity's sake, the process of the main control unit 101 expanding the basic operation program 1001 stored in ROM 103 into RAM 104 and executing it to control each operation block will be described as the basic operation execution unit 1101 controlling each operation block. Similar descriptions will be used for the other operation programs.

The receiving function execution unit 1102 controls each operating block of the broadcast receiving device 100 to play components such as video and audio transmitted by the broadcasting system of this embodiment. In particular, the transport processing unit 1102a primarily controls the MMT decoder function of the separation unit 132, and distributes the video data streams, audio data streams, etc. separated from the MMT data stream to the corresponding decoding processing units. The AV decoding processing unit 1102b primarily controls the video decoder 141, audio decoder 143, etc. The application processing unit 1102c primarily controls the cache unit 152, application control unit 153, browser unit 154, and sound source unit 156. The character superimposition processing unit 1102d primarily controls the character superimposition decoder 144. The subtitle processing unit 1102e primarily controls the subtitle decoder 145. The general-purpose data processing unit 1102f primarily controls the data decoder 151. The EPG generation unit 1102g interprets the description contents of the MH-EIT and other information included in the MMT-SI to generate an EPG screen. The presentation processing unit 1102h mainly 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.

In addition, the linkage function execution unit 1103 manages device authentication, connection, sending and receiving of various data, etc. when the broadcast receiving device 100 performs linkage operations with external devices such as the mobile information terminal 700. The recording and playback function execution unit 1104 controls the recording of broadcast programs obtained from the digital broadcast waves of this broadcast system and content obtained from various server devices on the network in the content storage area 1200 of the storage unit 110 or in external storage connected to the expansion interface unit 124, or the playback of such broadcast programs and content.

The operating programs may be stored in advance in the ROM 103 and/or storage unit 110 at the time of product shipment. After product shipment, they may be acquired via the LAN communication unit 121 from another application server 500 or the like on the Internet 200. Furthermore, the operating programs may be stored on a memory card, optical disc, or the like and acquired via the expansion interface unit 124, etc.

[Configuration of broadcast station server]
9 is a block diagram showing an example of the internal configuration of the broadcast station server 300. The broadcast station server 300 is made up 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 broadcast signal transmission unit 360.

The main control unit 301 is a microprocessor unit that controls the entire broadcast station server 300 in accordance with a predetermined operation program. The system bus 302 is a data communication path for transmitting and receiving data between the main control unit 301 and each operation block within the broadcast station server 300. The RAM 304 serves as a work area when each operation program is executed.

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

In addition, the basic operation program 3001, broadcast content management/distribution program 3002, and broadcast content sending program 3003 stored in the storage unit 310 are each expanded into RAM 304, and the main control unit 301 executes each of the expanded programs to form a basic operation execution unit 3101, a broadcast content management/distribution execution unit 3102, and a broadcast content sending execution unit 3103.

In the following, for simplicity's sake, the process of the main control unit 301 expanding the basic operation program 3001 stored in the storage unit 310 into RAM 304 and executing it to control each operation block will be described as the basic operation execution unit 3101 controlling each operation block. Similar descriptions will be used for the 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 the service provider based on a 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, as necessary, perform authentication processing of the service provider server 400 based on the contract.

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

LAN communication unit 321 is connected to Internet 200 and communicates with service provider server 400 and the like on Internet 200. LAN communication unit 321 is equipped with an encoding circuit, a decoding circuit, and the like. Digital broadcast signal transmission unit 360 modulates MMT data strings composed of video data strings, audio data strings, program information data strings, etc., of program content of each broadcast program stored in broadcast content storage area 3200, and transmits them as digital broadcast waves via radio tower 300t.

[Configuration of service provider server]
10 is a block diagram showing an example of the internal configuration of the service provider server 400. The service provider server 400 is made up of a main control unit 401, a system bus 402, a 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 in accordance with 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 a work area when each operating program is executed.

The storage unit 410 stores a basic operation program 4001, a video content management/distribution program 4002, and an application management/distribution program 4004, and further 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 broadcast station server 300 as video content. It also stores video content, etc. produced by the service provider. The metadata storage area 4300 stores various metadata provided by the broadcast station server 300 and metadata related to video content produced by the service provider. The application storage area 4400 stores various applications, etc. for realizing services linked to broadcast programs, which are distributed in response to requests from each television receiver. The user information storage area 4500 stores information (personal information, authentication information, etc.) related to users who are authorized to access the service provider server 400.

In addition, the basic operation program 4001, video content management/distribution program 4002, and application management/distribution program 4004 stored in the storage unit 410 are each expanded into RAM 404, and the main control unit 401 executes the expanded basic operation program, video content management/distribution program, and application management/distribution program to form a basic operation execution unit 4101, a video content management/distribution execution unit 4102, and an application management/distribution execution unit 4104.

In the following, for simplicity's sake, the process of the main control unit 401 expanding the basic operation program 4001 stored in the storage unit 410 into RAM 404 and executing it to control each operation block will be described as the basic operation execution unit 4101 controlling each operation block. Similar descriptions will be used for the other operation programs.

The video content management/distribution execution unit 4102 acquires program content and metadata for broadcast programs from the broadcast 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, the video content management/distribution execution unit 4102 may perform authentication processing for each television receiver as needed when distributing the video content and metadata to each television receiver. Furthermore, the application management/distribution execution unit 4104 manages applications stored in the application storage area 4400 and controls the distribution of each application in response to a request from each television receiver. Furthermore, the application management/distribution execution unit 4104 may perform authentication processing for each television receiver as needed when distributing the application to each television receiver.

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

[Hardware configuration of mobile information terminal]
11A is a block diagram showing an example of the internal configuration of a portable information terminal 700. The portable information terminal 700 is composed 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 in accordance with a predetermined operating program. The system bus 702 is a data communication path for transmitting 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 operating programs, and may be a rewritable ROM such as an EEPROM or flash ROM. RAM 704 serves as a work area when the basic operating programs and other operating programs are executed. ROM 703 and RAM 704 may be integrated with the main control unit 701. ROM 703 may also use a portion of the storage area within the storage unit 710, rather than being an independent configuration as shown in Figure 11A.

The storage unit 710 stores the operating programs and operating setting values of the mobile information terminal 700, personal information of the user of the mobile information terminal 700, etc. It can also store operating programs downloaded via the Internet 200 and various data created by the operating programs. It can also store content such as video, 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 must also retain the information stored therein even when power is not being supplied to the mobile information terminal 700 from an external source. Therefore, devices such as non-volatile semiconductor memory such as flash ROM or SSD, or magnetic disk drives such as HDD, are used.

The operating programs stored in ROM 703 and storage unit 710 can be added to, updated, and have their functions expanded by downloading them from various server devices on the Internet 200.

The communication processing unit 720 is composed 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 the router device 200r and the access point 200a, and transmits and receives data to and from each server device and other communication devices on the Internet 200. The connection to the router device 200r and the access point 200a is assumed to be wireless, 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 the base station 600b of the mobile telephone network. The NFC communication unit 723 performs wireless communication when in proximity to a compatible reader/writer. The LAN communication unit 721, the mobile telephone network communication unit 722, and the NFC communication unit 723 each include an encoding circuit, a decoding circuit, an antenna, etc. Additionally, the communication processing unit 720 may further include other communication units, such as a BlueTooth (registered trademark) communication unit or an infrared communication unit.

The expansion interface unit 724 is a group of interfaces for expanding the functionality of the mobile information terminal 700, and in this embodiment is composed of a video/audio interface, a USB interface, a memory interface, etc. The video/audio interface inputs video/audio signals from external video/audio output devices, outputs video/audio signals to external video/audio input devices, etc. The USB interface connects to a PC or the like to send and receive data. It may also be used to connect a keyboard or other USB device. The memory interface connects to a memory card or other memory medium to send and receive data.

The operation unit 730 is an instruction input unit for inputting operation instructions to the mobile information terminal 700, and in this embodiment is configured with a touch panel 730t arranged on top of the display unit 741 and operation keys 730k with an array of button switches. Only one of these may be used. The mobile information terminal 700 may also be operated using a keyboard or the like connected to the extended interface unit 724. The mobile information terminal 700 may also be operated using a separate terminal device connected via wired or wireless communication. In other words, the mobile information terminal 700 may be operated from the broadcast receiving device 100. The touch panel function may also be provided by the display unit 741.

The image processing unit 740 is composed 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 an LCD panel, and provides image data processed by the image signal processing unit 742 to the user of the mobile information terminal 700. The image signal processing unit 742 is equipped with a video RAM (not shown), and the display unit 741 is driven based on image data input to the video RAM. The image signal processing unit 742 also has the function of performing format conversion and superimposing processing of menus and other OSD (On Screen Display) signals as necessary. The first image input unit 743 and second image input unit 744 are camera units that input image data of the surroundings or object by converting light input from the lens into an electrical signal using electronic devices such as a CCD (Charge Coupled Device) or CMOS (Complementary Metal Oxide Semiconductor) sensor.

The audio processing unit 750 is composed 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 mobile information terminal 700. The audio input unit 753 is a microphone, and converts the user's voice, etc. into audio data and inputs it.

The sensor unit 760 is a group of sensors for detecting the state of the mobile information terminal 700, and in this embodiment is composed of a GPS receiver unit 761, a gyro sensor 762, a geomagnetic sensor 763, an acceleration sensor 764, an illuminance sensor 765, and a proximity sensor 766. These sensors make it possible to detect the position, inclination, direction, and movement of the mobile information terminal 700, as well as the ambient brightness and the proximity of surrounding objects. The mobile information terminal 700 may also be equipped with other sensors, such as a barometric pressure sensor.

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

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

[Software configuration of mobile information terminal]
11B is a software configuration diagram of the mobile information terminal 700 of this embodiment, showing the software configuration in the ROM 703, RAM 704, and storage unit 710. In this embodiment, a basic operation program 7001 and other operation programs are stored in the ROM 703, and a linkage control program 7002 and other operation programs are stored in the storage unit 710. The storage unit 710 is also assumed to include a content storage area 7200 for storing content such as moving images, still images, and audio, an authentication information storage area 7300 for storing authentication information and the like required when accessing a television receiver or each server device, and various information storage areas for storing various other information.

The basic operation program 7001 stored in ROM 703 is loaded into RAM 704, and the main control unit 701 executes the loaded basic operation program to form a basic operation execution unit 7101. Similarly, the collaborative control program 7002 stored in the storage unit 710 is loaded into RAM 704, and the main control unit 701 executes the loaded collaborative control program to form a collaborative control execution unit 7102. Furthermore, RAM 704 is provided with a temporary storage area for temporarily storing data created when each operation program is executed, as needed.

In the following, for simplicity's sake, the process of the main control unit 701 expanding the basic operation program 7001 stored in ROM 703 into RAM 704 and executing it to control each operation block will be described as the basic operation execution unit 7101 controlling each operation block. Similar descriptions will be used for the other operation programs.

The linkage control execution unit 7102 manages device authentication and connection, sending and receiving of various data, etc. when the mobile information terminal 700 performs linkage operations with the television receiver. The linkage control execution unit 7102 also has a browser engine function for executing applications that link with the television receiver.

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

[Time management of broadcast receiving device]
The broadcast receiving device 100 of this embodiment has two types of time management functions. The first time management function is a time management function based on NTP, and the second time management function is a time management function based on MH-TOT. The two types of time management functions will be explained below.

<NTP-based time management function>
First, the time management function based on NTP will be described.

Figure 12A shows an example of a system configuration for clock synchronization/presentation synchronization in a broadcasting system compatible with the broadcast receiving device 100 of this embodiment. In this broadcasting system, 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 this NTP timestamp format, UTC "seconds or more" are represented by 32 bits, and "less than a second" is represented by 32 bits. However, in practice, it is difficult to reproduce one second with 32-bit precision. For this reason, a system clock for synchronizing a video system or for operating an NTP-formatted clock may use a frequency of 2 to the 24th power (approximately 16.8 MHz), as shown in the figure. Note that, considering that the system clock in conventional broadcasting systems was 27 MHz and the ease of constructing receiver hardware, it is desirable to use a frequency that is a power of 2, such as 2 to the 28th power, as the system clock.

Note that if the system clock on the broadcast transmission system or receiver side is set to a frequency that is a power of 2, such as 2 to the 24th power to 2 to the 28th power, as described above, the lower 8 to 4 bits of the NTP timestamp format transmitted from the broadcast transmission system to the receiver side, which are not referenced by the PLL (Phase Locked Loop) system used to reproduce the system clock or NTP format clock, may be fixed to 0 or 1. In other words, if the system clock is 2 to the nth power Hz (n = 24 in the example of 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 to be ignored.

When the broadcast transmission system receives NTP-formatted time information from an external source, it configures a PLL system with a 32+n-bit counter using a 2 to the nth power VCO (Voltage Controlled Oscillator), creating a transmission system clock that synchronizes with the externally provided time information. The entire signal processing system operates in synchronization with the 2 to the nth power Hz system clock. Furthermore, the output of the transmission system clock is periodically transmitted to the receiver via the broadcast transmission path as NTP-long formatted time information. Note that the NTP-long formatted time information transmitted to the receiver may also have the lower-order 32-n bits of the 32 bits representing "less than a second" fixed to "0" or "1." This is because the system clock counter on the broadcast transmission system side is composed of 32+n bits.

On the receiver side, time information in NTP long format is received via the broadcast transmission path, and, just like on the broadcast transmission system side, the receiving system clock is regenerated using a PLL system based on a 2n Hz VCO. This makes the receiving system clock synchronized with the broadcast transmission system side. In addition, by operating the receiver's signal processing system in synchronization with the 2n Hz system clock, clock synchronization is achieved between the broadcast transmission system side and the receiver side, enabling stable signal reproduction.

The decoding time and presentation time for each presentation unit of the video/audio signal are set by the broadcast transmission system based on the NTP-format 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. The "mpu_sequence_number" parameter in the MPU timestamp descriptor 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. In other words, by referencing the MPU timestamp descriptor stored in the MPT, the receiver can control the presentation (display, output, etc.) timing of each MPU of video/audio signals, subtitles, superimposed text, etc.

Note that when focusing on the control of the decoding timing 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 about 2 to the power of 16 Hz (approximately 65.5 KHz), and in this case, it is not necessary to refer to the lower 16 bits of the NTP timestamp format described in the MPU timestamp descriptor, etc. In other words, if a 2 to the power of m Hz clock generated by dividing the system clock, etc., is used to control the decoding timing and presentation timing, it is not necessary to refer to the lower 32-m bits of the NTP timestamp format described in the MPU timestamp descriptor, etc. 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>
An example of the configuration of time information transmitted in NTP format in the NTP-based time management function described above is shown in Figure 12B. The "reference_timestamp" parameter and "transmit_timestamp" parameter in the NTP format are 64-bit NTP-long 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 long format time data and the NTP timestamp format time data are data in which UTC "seconds or more" are represented by 32 bits and "less than seconds" are represented by 32 bits. In other words, NTP format time information can transmit time information down to "less than seconds." Furthermore, since the time information in NTP format is expressed in UTC notation, unlike the time management in conventional digital broadcasting, as shown in Figure 3, by managing both the data flow transmitted via the broadcast transmission path and the data flow distributed via the communication line using the time information in NTP format, it is possible to easily ensure consistency between the two types of data.

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

Figure 12C shows an example of the data structure of MH-TOT. The broadcast receiving device 100 of 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 contains the lower 16 bits of the coded data for the current date in Modified Julian Date (MJD) and 24 bits of information representing Japan Standard Time (JST) as six 4-bit binary-coded decimal (BCD) numbers. The current date can be calculated by performing a specified calculation on the 16-bit coded data of the MJD. Furthermore, of the six 4-bit binary coded decimal numbers, 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 can achieve more accurate synchronization by using a time management function based on NTP, which is time information in UTC notation, to synchronize the decoding and display of the video, audio, subtitles, superimposed text, and other presented data that make up the content of the broadcast signal. Furthermore, by referencing information in UTC notation rather than the broadcast station's clock notation, it is also possible to synchronize the decoding and display of the video, audio, subtitles, superimposed text, or other data that make up the content received via the broadcast signal with the video, audio, subtitles, superimposed text, or other data acquired via the communication line path.

Furthermore, in the broadcast receiving device 100 of this embodiment, a time management function based on "JST_time," which contains 24 bits of information represented by six 4-bit binary-coded decimal numbers in the MH-TOT, may be used in the process of presenting the current time to the user or in each process handling the MH-EIT shown in Figure 7E. Generally, the process of presenting the current time to the user in a broadcast receiving device rarely requires accuracy down to the second. Furthermore, each piece of time information described in the MH-EIT is 24 bits of information represented by six 4-bit binary-coded decimal numbers, stored in two decimal digits for "hour," "minute," and "second," similar to the EIT of conventional digital broadcasts transmitted using the MPEG2-TS format. 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 handling the MH-EIT. Specifically, processes that handle MH-EIT include, for example, the generation of electronic program guides, control of recording and viewing reservations, and copyright management processes such as temporary storage. Precision down to the second is rarely required for any of these processes, and precision on the order of one second is sufficient.

Furthermore, the generation of the electronic program guide, control of recording and viewing reservations, copyright management processes such as temporary storage, and other functions are also implemented in receivers of digital broadcasting systems using the conventional MPEG2-TS format. Therefore, if the broadcasting system of this embodiment is configured to handle processes such as generation of the electronic program guide, control of recording and viewing reservations, and copyright management processes such as temporary storage using time management processes that are consistent with conventional MPEG2-TS digital broadcasting systems, then when configuring a broadcast receiving device that has both the reception functions for conventional MPEG2-TS digital broadcasts and the reception functions for MMT digital broadcasts, there will be no need to design separate processing algorithms for these processes (generation of the electronic program guide, control of recording and viewing reservations, copyright management processes such as temporary storage, and other processes), thereby reducing costs.

In addition, even if a receiver only has the ability to receive MMT digital broadcasts and does not have the ability to receive conventional MPEG2-TS digital broadcasts, it can utilize the algorithms for functions that are also included in receivers for digital broadcast systems that use the conventional MPEG2-TS format, without having to create completely new algorithms for processes such as generating an electronic program guide, controlling recording and viewing reservations, and copyright management processes such as temporary storage, making development more cost-effective.

Therefore, by configuring a system that uses the time management function based on the MH-TOT "JST_time" parameter for these processes (such as generating electronic program guides, controlling recording and viewing reservations, and copyright management processes such as temporary storage), it will be possible to provide MMT digital broadcast receiving devices at a lower cost by improving compatibility with conventional broadcasting systems.

As explained above, the broadcast receiving device 100 of this embodiment has a time management function that uses two types of time information with different degrees of accuracy. That is, the first time information is time information written in a format that is 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 to synchronize each piece of content data in the broadcast signal, more advanced information presentation processing than conventional broadcasting systems is realized, and by using the first time information for generating an electronic program guide, controlling recording and viewing reservations, and copyright management processing such as temporary storage, broadcast receiving devices can be provided at low cost.

Therefore, by being equipped with the two types of time management functions described above, the broadcast receiving device 100 of this embodiment can achieve both more advanced information presentation processing and lower costs.

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

In a first variant, in order to improve the accuracy of the management time of the NTP-based time management function already described using Figure 12A, information regarding the expected delay time in transmitting time information from a time management server (not shown) or broadcast 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 the information regarding the expected delay time to correct the system clock of the NTP-based time management function.

In this case, information regarding the expected delay time may be transmitted within a TMCC (Transmission and Multiplexing Configuration Control) area outside the TLV multiplexed stream, rather than within the TLV multiplexed stream of the protocol stack in the broadcast transmission path shown in Figure 3(A). Transmission within the TMCC area allows the broadcast receiving device 100 to extract information regarding the expected delay time without undergoing demultiplexing (demuxing) of the TLV multiplexed stream. In other words, it is possible to obtain information that is less affected by the delay caused by the demultiplexing process in the broadcast receiving device 100, thereby enabling highly accurate system clock adjustment processing. An example of the data structure of the time information transmitted in the TMCC signal is explained using Figure 12E. The time information may be stored and transmitted, for example, in a TMCC extended information area. In the time information in the TMCC extension information field shown in the figure, the "delta" parameter represents the estimated transmission delay from the time management server that distributes UTC or the server device that creates the TMCC signal to a general broadcast receiving device, using a 32-bit signed fixed-point number. The upper 16 bits describe the integer part, and the lower 16 bits describe the decimal point. The "transmit_timestamp" parameter is a transmission timestamp, and describes 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 point.

In this first variant, the broadcast receiving device 100 of this embodiment can more accurately correct the system clock of the NTP-based time management function used to synchronize each piece of content data in the broadcast signal, using information about the expected delay time (for example, the aforementioned "delta" parameter and/or "transmit_timestamp" parameter) described in the time information stored in the TMCC extended information area and transmitted.

[Second Modification of Time Management]
Next, a second modification of the time management in the broadcasting system of this embodiment will be described below.

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

However, the aforementioned "JST_time" parameter only uses the lowest 16 bits of the MJD encoded data, which results in an overflow at "April 22, 2038," making it impossible to express dates after "April 23, 2038" using only the specified calculation. Therefore, in the second variant of this embodiment, the calculation method is switched depending on whether the MJD value is greater than or equal to a specified value or less than the specified value, allowing dates after "April 23, 2038" to be expressed.

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

In addition, rather than 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 part or all of the "reserved" parameter in the MH-TOT data structure shown in FIG. 12C, or a newly added flag. For example, if the most significant bit of the 16-bit encoded data of the MJD is "0," the flag may be set to "1" if the MJD indicates "April 23, 2038" or later, or set to "0" if the MJD does not indicate "April 23, 2038" or later. Then, if the flag is "1," the second calculation method shown in FIG. 12F is used, and if the flag is "0," the first calculation method is used. Alternatively, a new descriptor having the same meaning as the flag may be prepared and placed in the MH-TOT.

Furthermore, as mentioned above, the broadcasting system of this embodiment transmits absolute time in NTP format, and the broadcast receiving device 100 of this embodiment has a time management function based on this NTP. Furthermore, the broadcast receiving device 100 of this embodiment controls the decoding timing and presentation timing for each presentation unit of video/audio signals by referencing the NTP timestamp etc. described in the MPU timestamp descriptor set on an MPU basis. As mentioned above, the time information in NTP format has the structure shown in Figure 12B. Furthermore, the MPU timestamp descriptor has the structure shown in Figure 7D.

For this reason, the broadcast receiving device 100 of this embodiment may refer to the "reference_timestamp" parameter, the "transmit_timestamp" parameter, or the "mpu_presentation_time" parameter, and select whether to use the first or second calculation method depending on the value of the referenced time data, etc. In other words, for example, if the most significant bit of the 64-bit NTP-length format time data is "0", the second calculation method may be used, and if it is not "0", the first calculation method may be used.

Using either of the above methods, the broadcast receiving device 100 of this embodiment can represent dates after April 23, 2038.

[Broadcast receiving device channel selection process (initial scan)]
The AMT of the broadcasting system of this embodiment provides a list of multicast groups for IP packets so that IP packets transmitted by the TLV multiplexing method can be received without distinction from IP packets transmitted over a communication line as much as possible. Multiple IP multicast groups can be listed for one service identifier. Address masks can also be used to efficiently describe consecutive IP addresses.

In the broadcast receiving device 100 of this embodiment, when scanning channels during initial setup or when rescanning to change settings, it is possible to store a list of services acquired from the TLV-NIT in non-volatile memory such as ROM 103 or storage unit 110. Furthermore, it is possible to associate a list of IP multicast groups corresponding to each of the services with each service as IP-related information and store it in the non-volatile memory. By storing the list of services and IP-related information in non-volatile memory and making them available for constant reference, it is no longer necessary to re-acquire the TLV-NIT or AMT when switching channels, etc., and broadcast content can be acquired more efficiently.

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

When channel scanning begins, the reception function execution unit 1102 sets an initial frequency value to the tuner/demodulator unit 131 and instructs it to tune to that frequency value (S101). If the tuner/demodulator unit 131 successfully locks onto the set frequency value (S102: Yes), the reception function execution unit 1102 then acquires the TLV-NIT from the received signal (S103).

If the TLV-NIT acquired in the processing of S103 is valid data (S104: Yes), the reception function execution unit 1102 acquires information such as the TLV stream ID and original network ID from the acquired TLV-NIT (S105). Figure 13B shows an example of the data structure of a TLV-NIT. The TLV stream ID information can be acquired from the 'tlv_stream_id' parameter, and the original network ID information can be acquired 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 acquired from the distribution system descriptor (S106), and a list of service IDs is acquired 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 contains multiple different pieces of data, such as a TLV stream ID, original network ID, distribution system information, and a list of service IDs, the processes of S105 to S107 are repeated. Next, the reception 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, acquired in the processes of S105 to S107, and stores the created service list in ROM 103 or storage unit 110 (updated when rescanning) (S108).

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

Note that if the tuner/demodulator unit 131 does not successfully lock onto the set frequency value in the process of S102 (S102: No), or if the TLV-NIT acquired in the process of S103 is not valid data (S104: No), the processes of S105 to S111 are not performed.

After completing the process of S111, the reception function execution unit 1102 ends the process if the frequency value set in the tuner/demodulator unit 131 is the final frequency value in the channel scan range (S112: Yes). On the other hand, if the set frequency value is not the final frequency value in the channel scan range (S112: No), the frequency value set in the tuner/demodulator unit 131 is increased (S113), and the processes of S102 to S111 are repeated. Note that if a single TLV-NIT can acquire service IDs for all services that make up the broadcast network, and if an AMT containing a list of IP multicast groups related to the service IDs can be acquired, the processes of S112 to S113 are not necessary.

Through the above-described series of processes, the broadcast receiving device 100 of this embodiment creates/updates a list of services (service list) that make up the broadcast network when scanning channels during initial setup or when rescanning to change settings, and at the same time creates/updates a list of IP multicast groups (IP-related information) corresponding to each of the services, and can then store this information in non-volatile memory such as ROM 103 or storage unit 110.

The rescan for the setting change may be performed automatically when a change in the information in the table is detected by referencing the "version_number" parameter in the TLV-NIT or AMT. When a change in the "version_number" parameter in either the TLV-NIT or AMT is detected, only the information related to the table in which the change in the parameter was detected may be automatically updated. However, when the automatic update is performed, it is desirable to notify the user that a rescan has been performed automatically. Alternatively, the user may be notified that a change has been made to the information in the table, and the user may be allowed to choose whether or not to perform the rescan.

[Broadcast receiving device tuning process (channel switching)]
FIG. 14A is a diagram showing an example of an 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) to instruct a channel change, the reception function execution unit 1102 interprets the command sent from the remote control and specifies the service ID of the desired service (S201). Next, the reception function execution unit 1102 begins acquiring an AMT from the signal received by the tuner/demodulator 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 acquired from the acquired AMT (S204). On the other hand, if the AMT is not successfully acquired within the predetermined time (S202: No), information regarding a list of IP multicast groups corresponding to the service ID is acquired by referencing IP-related information stored in the ROM 103 or storage unit 110 (S203). Note that the determination process of S202 may not be performed, and the IP-related information stored in the ROM 103 or storage unit 110 may always be referenced.

Next, the reception function execution unit 1102 begins acquiring the TLV-NIT from the signal received by the tuner/demodulator unit 131. If the TLV-NIT is successfully acquired within the specified time (S205: Yes), 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 TLV-NIT is not successfully acquired within the specified time (S205: No), distribution system information for acquiring the IP data flow corresponding to the service ID is acquired (S207) by referring to a service list stored in ROM 103 or storage unit 110, etc. (S206). Note that it is also possible to always refer to the service list stored in ROM 103 or storage unit 110, etc., without performing the judgment process of S205.

After acquiring the distribution system information in the processing of S207, the reception function execution unit 1102 then controls the tuner/demodulation unit 131 with the frequency value indicated in the acquired distribution system information, receives the IP data flow corresponding to the service ID (S208), extracts the MMT data string from the received IP data flow, and outputs it to the separation unit 132.

In the separation unit 132, the transport processing unit 1102a acquires an MMTP packet whose packet ID is "0" from the input MMT data sequence (S209), and further acquires the MPT contained in the acquired MMTP packet (S210). Next, the transport processing unit 1102a references the "MMT_package_id_byte" parameter contained in the acquired MPT and confirms whether the lowest 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 lowest 16 bits of the "MMT_package_id_byte" parameter have the same value as the service ID (S211: Yes), it is determined that the MMTP packet whose packet ID is "0" is an MMTP packet containing data for the program corresponding to the service ID, and the process proceeds to MFU acquisition processing based on the information contained in the acquired MPT.

On the other hand, if the lowest 16 bits of the "MMT_package_id_byte" parameter are not the same value as the service ID (S211: No), it is determined that the MMTP packet with the packet ID of "0" is not an MMTP packet containing program data corresponding to the service ID. In this case, the transport processing unit 1102a acquires the PLT again (S212) and checks the acquired PLT to confirm the packet ID (assumed to be x) of the MMTP packet transmitting the MPT containing the "MMT_package_id_byte" parameter corresponding to the service ID (S213). Furthermore, the transport processing unit 1102a acquires an MMTP packet with a packet ID of "x" from the input MMT data sequence (S214) and acquires the MPT contained in the acquired MMTP packet (S215). Furthermore, it starts the MFU acquisition process based on the information contained in the acquired MPT.

It is also possible to skip steps S209 to S211 and always perform steps S212 to S215. In this case, processing time can be shortened when program data corresponding to the service ID is stored in an MMTP packet with a packet ID other than "0."

Here, we will explain the process of identifying the packet ID of an MMTP packet containing program data corresponding to the service ID by checking the PLT, 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, this PA message includes a PLT (Package List Table), as shown in Figure 14B. The PLT contains a list of packet IDs of MMTP packets that transmit PA messages containing MPTs of other packages. By checking the PLT, it is possible to identify, from the package ID, the MMTP packet that transmits a PA message containing an MPT that serves as the entry point for each service. Figure 14C shows an example of the data structure of a PLT. 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 operational sequence shown in FIG. 14A, in the MFU acquisition process, the transport processing unit 1102a first references the MPT acquired in S210 or S215 and acquires the IP address and packet ID of the IP data flow transmitting the desired MFU (S216). The transport processing unit 1102a then acquires the MPU presentation time from the MPU timestamp descriptor placed in the MPT and the MPU layout number from the MPU presentation area designation descriptor placed in the MPT (S217, S218), and further acquires the MFU based on the IP address and packet ID of the acquired 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 under the control of the AV decoding processing unit 1102b. Then, presentation processing is performed under the control of the presentation processing unit 1102h based on the acquired information related to the presentation time and layout control (S220).

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

The above series of processes enable the broadcast receiving device 100 of this embodiment to perform channel selection (channel switching) operations. In particular, as described using Figures 13A and 14A, when scanning channels during initial setup or when rescanning to change settings, a service list and IP-related information are created and stored in non-volatile memory such as ROM 103 or storage unit 110 for continuous reference. When selecting a channel (switching a channel), the service list and IP-related information stored in non-volatile memory such as ROM 103 or storage unit 110 are referenced, thereby improving the efficiency of channel selection (channel switching). In other words, the time from the start of channel selection (channel switching) to the end of channel selection (channel switching) can be shortened compared to when re-acquiring AMT or TLV-NIT during channel selection (channel switching).

[Remote control key setting process for broadcast receiving device]
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 of this embodiment. The remote control 100R includes at least a power key 100R1, a numeric keypad 100R2, channel up/down keys 100R3, a menu key 100R4, an EPG key 100R5, cursor keys 100R6, an enter key 100R7, and color keys 100R8. The remote control 100R may further include volume up/down keys, a network switching key, an input switching key, a record key, a play key, etc.

For example, in the process of S201 of the channel selection operational sequence shown in FIG. 14A, when using the remote control 100R to instruct the broadcast receiving device 100 of this embodiment to change channels, 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 repeatedly press the channel up/down key 100R3 as necessary to advance (or reverse) through the channels until the desired channel (service) is displayed. The third method is a so-called one-touch channel selection method in which a specific channel (service) associated with each key on the numeric keypad 100R2 is called up by pressing the numeric keypad 100R2 only once. The third one-touch channel selection method is a user-friendly channel selection method, but it requires that the broadcast receiving device 100 be previously configured to associate each key on the numeric keypad 100R2 with a specific channel (service).

The broadcast receiving device 100 compatible with 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/demodulator unit 131. In other words, the broadcasting system of this embodiment provides a remote control key descriptor as a TLV-SI descriptor. The association can be set by referencing 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 a service ID that identifies a channel (service). The 'remote_control_key_id' parameter is a 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 of the above parameters, the channel (service) identified by the 'service_id' parameter can be associated with the key specified by the value of the 'remote_control_key_id' parameter on numeric keypad 100R2.

If there are a large number of 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) may be assigned to the color key 100R8. In this case, it is sufficient to assign a numerical value corresponding to the "remote_control_key_id" parameter to each key on the color key 100R8 in advance.

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

In addition to the method of setting the associations according to the contents of the remote control key descriptor as described above, the user may also assign any channel service to each key on the numeric keypad 100R2 according to their own preferences. Furthermore, both the association settings according to the contents of the remote control key descriptor and the association settings assigned by the user according to their preferences may be stored simultaneously in the non-volatile memory of the broadcast receiving device 100, and only one of the settings may be used by selecting it through a menu operation or the like. In this case, the association settings assigned by the user according to their preferences may be used preferentially. Furthermore, depending on the value of a priority flag described in the remote control key descriptor, the association settings according to the contents of the remote control key descriptor may be used preferentially over the association settings assigned by the user according to their preferences. The priority flag may be set by using some or all of the "reserved" parameter of the remote control key descriptor shown in FIG. 15B, or by adding a new parameter. In this case, the value of the priority flag may be controllable for each service ID.

Also, 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 store only the association settings assigned by the user according to their preferences, and if a remote control key descriptor is described in the TLV-NIT being received, the association settings corresponding to the contents of the remote control key descriptor may be used, and if a remote control key descriptor is not described in the TLV-NIT being received, the association settings assigned by the user according to their preferences may be used.

The process of changing the association of each key of the numeric keypad 100R2 with a specific 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 in the network specified by the TLV-NIT, or may be performed only for some of the services. If this process is performed only for some of the services, the previous settings for the other services may be retained as they are. Furthermore, if the 'service_id' parameter is a specific value (e.g., 999), only the settings specified by the 'remote_control_key_id' parameter may be erased from the settings stored in 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 associate each key on the numeric keypad 100R2 with a specific channel (service).

[Multi-channel selection processing]
The broadcasting system of this embodiment also allows for multi-channel broadcasting, in which multiple programs are broadcast in parallel on a single channel (service). When simultaneously broadcasting multiple programs using multi-channel broadcasting, the one-touch channel selection described above is only possible for the main channel of the multi-channel broadcasting, but not for the sub-channels of the multi-channel broadcasting. In other words, when selecting a sub-channel of the multi-channel broadcasting, it is necessary to either directly input the service ID and specify it, or to first select the main channel of the multi-channel broadcasting using one-touch channel selection, and then select the desired sub-channel by pressing the channel up/down key 100R3, which results in a problem of cumbersome operations.

To solve the above problem, the broadcast receiving device 100 of this embodiment expands the one-touch channel selection function, making it possible to directly select a multi-channel sub-channel by repeatedly pressing the numeric keypad 100R2, to which a specific service ID is assigned, multiple times within a specific period of time.

This will be explained using Figure 16A. For example, assume that the service for channel 011 is pre-assigned to the "1" key on numeric keypad 100R2 of remote control 100R. In this case, if a channel selection operation is performed when multi-programming is not in progress (see (A) in the figure), channel 011 will be selected regardless of the number of times the "1" key is pressed. On the other hand, if a channel selection operation is performed when multi-programming is in progress (see (B) in the figure), channel 011 will be selected if the "1" key is pressed only once, and channel 012 will be selected if the "1" key is pressed again within a predetermined time after the first press of the "1" key. Similarly, if the "1" key is pressed three times within a predetermined time, channel 013 will be selected. Note that if the "1" key is pressed again after a predetermined time has elapsed since the first press of the "1" key, channel 011 may remain selected.

By enabling the above-described operations, the broadcast receiving device 100 of this embodiment allows direct selection of sub-channels during multi-programming with simpler operations.

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

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

Note that if one or more programs in a multi-format broadcast are multi-view compatible or have multiple assets, only one of the above operations can be enabled and the other disabled. For example, if one or more programs in a multi-format broadcast are multi-view compatible or have multiple assets, pressing the same key multiple times within a specified period of time can be assigned to the process of directly selecting a sub-channel in a multi-format broadcast. Which operations are enabled and which are disabled can be determined in advance, or the user can select which operations are enabled and which are disabled.

[Screen layout control of broadcast receiving device]
In the broadcast receiving device 100 of this embodiment, it is assumed that screen layout control based on the description of the LCT is possible. Fig. 17A shows an example of the data structure of the LCT. Fig. 17B shows an example of the data structure of the MPU presentation area specification descriptor.

In the LCT data structure, the "left_top_pos_x" and "right_down_pos_x" parameters indicate the horizontal position of the top left and bottom right of the region, respectively, as a percentage of the total number of horizontal pixels, when the left side of the full-screen display is "0" and the right side is "100". The "left_top_pos_y" and "right_down_pos_y" parameters indicate the vertical position of the top left and bottom right of the region, respectively, as a percentage of the total number of vertical pixels, when the top side of the full-screen display is "0" and the bottom side is "100". The "layer_order" parameter indicates the relative position of the region in the depth direction.

An example of assigning layouts to layout numbers based on the settings of each of the above parameters is described below, along with the setting values of each of the above parameters.

Figure 17C shows the default layout setting for the broadcast receiving device 100 of this embodiment, in which only one area is set across the entire screen. Figure 17D shows an example in which the entire screen is divided into three areas, each designated "Area 0," "Area 1," and "Area 2." For example, if the number of pixels across the entire screen is 7,680 horizontally and 4,320 vertically, "Area 0" is set to the range (0,0)-(6,143,3,455) 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, "Area 1" is set to the range (6144,0)-(7679,4319), and "Area 2" is set to the range (0,3456)-(6143,4319).

Figure 17E shows an example of setting three regions, similar to Figure 17D, but "Region 0" is set in the range (0,0)-(7679,4319), and "Region 1" and "Region 2" are placed in front of "Region 0" in the same range as above, depending on the setting of the "layer_order" parameter. Figure 17F shows an example where "Region 0" is set to Device 0 (the default device: in this example, the broadcast receiving device 100), and "Region 1" is set to Device 1 (in this example, the mobile information terminal 700).

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

In addition, areas where program video or data screens are not displayed due to the above-mentioned screen layout control may display a predetermined background color specified by the background color specification descriptor described in the LCT. Furthermore, if the background color specification descriptor is not included in the LCT, if the broadcast receiving device 100 is unable to correctly acquire the background color specification descriptor, or if the predetermined background color specified by the background color specification descriptor cannot be displayed due to hardware limitations, the video display device 100 may display a predetermined pattern in the area. Furthermore, the area may be used as an area where the video display device 100 displays notifications to the user. The notifications may be any information.

When dividing the screen according to the setting values of parameters such as "left_top_pos_x", any fractional part after the decimal point can be rounded up or down. Rounding (or rounding to the nearest integer in binary numbers) is also acceptable. For example, if the total pixel count is 7680 pixels x 4320 pixels vertically, and the "left_top_pos_x" parameter of "Area 0" is "0," the "left_top_pos_y" parameter is "0," the "right_down_pos_x" parameter is "51," and the "right_down_pos_y" parameter is "51," "Area 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, taking into account macroblocks during video compression processing, rounding up/down may be performed in 8-pixel or 16-pixel units. This processing enables efficient area setting based on the LCT and resolution conversion of multimedia content in the area.

Alternatively, the setting values of parameters such as "left_top_pos_x" may be limited to only "multiples of 5" or "multiples of 10" in the range from "0" to "100". In this case, too, the area setting can be performed optimally.

The content to be displayed in each of the above areas is specified by the MPU presentation area specification 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 description of the LCT by the "layout_number" parameter and the "region_number" parameter.

In addition, within the first 'for' loop of the MPU presentation area specification descriptor description, multiple 'layout_number' parameters and 'region_number' parameters can be described for one 'mpu_sequence_number' parameter, allowing the user to select which description to use for layout control. For example, if a "layout_number1", "region_number1", "layout_number2", and "region_number2" parameters are written for a specific "mpu_sequence_number" parameter within the first "for" loop, the user can select whether to control the layout of the MPU specified by the "mpu_sequence_number" parameter based on the "layout_number1" and "region_number1" parameters, or based on the "layout_number2" and "region_number2" parameters. In this way, the user can control the layout of a video program according to their preferences.

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

When the same screen layout control as in Figure 17D is performed based on the LCT description, and broadcast program video is displayed in "Area 0," and broadcast content such as program linked data linked to the broadcast program is displayed in "Area 1" and "Area 2," and the user instructs the display of the EPG screen using a remote control (not shown), the broadcast receiving device 100 of this embodiment returns the screen layout setting to the default setting (i.e., a state in which the same screen layout control as in Figure 17C is being performed) regardless of the contents of the LCT description, as shown in Figure 18A (A), and controls the EPG screen to be displayed on the entire screen. Furthermore, when the user instructs the display of the EPG screen to end, the screen layout control is re-executed in accordance with the contents of the LCT description.

By performing the above-described control, the EPG screen can be displayed larger and easier to view than when the EPG screen is displayed while maintaining screen layout area control, as shown in Figure 18A (B).

Note that the above-mentioned exception processing of screen layout control is not only applied when displaying the EPG screen, but may also be applied when displaying a sub-screen or dual-screen display of various setting screens (the recording setting screen in the illustrated example) of the broadcast receiving device 100, as shown in Figure 18B.

In the case of the recording setting screen shown in Figure 1A, the display area for the broadcast content changes 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 1B, the display area for the broadcast content changes from the entire screen to only the split-screen portion in the middle left corner of the screen. In either case, the display area for displaying the broadcast content is narrower than when the entire screen is used, so maintaining area control of the screen layout within the display area (i.e., dividing the area and displaying multiple broadcast contents simultaneously) is not desirable from a visual perspective. Therefore, in the broadcast receiving device 100 of this embodiment, in the above situation, only the broadcast content in "Area 0" is selected and displayed in the display area. Note that it is also possible to select and display broadcast content in "Area 1" or "Area 2" depending on the previous area selection status.

By performing the above-mentioned control, it is possible to improve the ease of viewing broadcast content compared to when various broadcast content is displayed while maintaining area control of the screen layout. The same is true when displaying a sub-screen on the recorded program list screen, displaying internet content in a browser, etc.

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

On the other hand, the aspect ratio of the display of a television receiver capable of receiving the above television broadcasting services (such as the broadcast receiving device 100 of this embodiment) is generally 16:9. In other words, when displaying video content with an aspect ratio of 4:3 or 21:9 on a typical television receiver, aspect ratio conversion processing can 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" (e.g., 3840 pixels horizontally by 2160 pixels vertically), aspect ratio conversion process will not be performed if the value of the "video_aspect_ratio" parameter is "0," "2," or "3," and aspect ratio conversion process will be performed if the value is "1" or "5." Also, 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.), aspect ratio conversion processing will not be performed if the value of the "video_aspect_ratio" parameter is "0" or "5", and aspect ratio conversion processing will be performed if the value is "1", "2", or "3".

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 a monitor unit 162 with an aspect ratio of 16:9, the aspect ratio may be converted to 16:9 by adding black bands above and below the 21:9 video content (display A in the figure). This allows the entire original video content to be displayed without distortion. Alternatively, only the center portion of the 21:9 video content may be cropped and displayed on the monitor unit 162 (display B in the figure). This allows the main portion of the original video content to be displayed enlarged. It is also possible to add small black bands to the top and bottom of video content with an aspect ratio of 21:9, and then crop out the center portion (display C in the figure). This allows most of the original video content to be displayed in a larger size. It is also possible to compress the left and right edges of video content with an aspect ratio of 21:9 to display the entire area (display D in the figure). This allows the entire area of the original video content to be displayed in a larger size, and the main part to be displayed without distortion. It is also possible to add small black bands to the top and bottom of video content with an aspect ratio of 21:9, and then compress the left and right edges to display the entire area (display E in the figure). This allows the entire area of the original video content to be displayed in a larger size, and with less distortion at the left and right edges.

The way in which aspect ratio conversion is performed may be selectable by the user via a menu or other setting. Alternatively, it may be possible to switch by pressing a specific key on a remote control or the like. Note that the aspect ratio "21:9" mentioned above includes aspect 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 the broadcasting system of this embodiment, time-series information regarding events (so-called programs) included in each service constituting the broadcasting network is transmitted via the MH-EIT. The MH-EIT shown in FIG. 7E is distinguished into two classes by a table ID (corresponding to the "table_id" parameter in the figure), and is capable of indicating information on the current/next event of its own TLV stream and schedule information for each event of its own TLV stream. The broadcast receiving device 100 of this embodiment refers to the MH-EIT and performs identification by service ID (corresponding to the "service_id" parameter in the figure), thereby obtaining information such as the start time and broadcast time of each event and creating an EPG screen. The video synthesis unit 161 can superimpose the created EPG on video information and display it on the monitor unit 162.

Figure 20A shows an example of an EPG screen in the broadcast receiving device 100 of this embodiment. The EPG screen 162a is in a matrix format, with the vertical axis representing time and the horizontal axis representing service IDs (channels), and displays detailed information about broadcast programs broadcast on each channel during each time slot. The detailed information 162a1 for each broadcast program is primarily composed of a title area 162a2 and a detailed description area 162a3. The detailed information 162a1 for each broadcast program may display program information described in an MH-short event descriptor or an MH-extended event descriptor and distributed. If the volume of program information described in each of these descriptors is large, the information may be displayed in abbreviated form under normal circumstances, and when a program is selected using a remote control (not shown), all program information may be displayed in a pop-up or similar display. Alternatively, when a program is selected, the program information described in each of these descriptors may be sent to the mobile information terminal 700 in 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 attributes of the broadcast program. Symbols representing the attributes of the broadcast program include, for example, symbols/characters indicating that it is a new program or a rebroadcast program. Alternatively, they may be a symbol representing "data," which indicates that the program is compatible with data broadcasting via a broadcast service. They may also be a symbol representing "Network" 162a4, which indicates that content, applications, etc. related to the broadcast program can be obtained from the network. Symbols representing the attributes of the broadcast program may also be displayed by using a different background color for the detailed information 162a1 or by surrounding the display area of the detailed information 162a1 with a bold frame.

Incidentally, even if the control information (messages, tables, descriptors, etc.) in the broadcasting system of this embodiment indicates that content, applications, etc. related to the broadcast program can be obtained from the network, if the LAN cable is not connected to the LAN communication unit 121 of the broadcast receiving device 100, or if access to the server devices on the network is not possible, the mark 162a4 symbolizing "Network" etc. may be controlled not to be displayed.

Furthermore, if the broadcast program is a distributed program distributed via the Internet 200 and cannot be acquired solely from broadcast waves, and further, as described above, if the broadcast receiving device 100 is unable to access each server device on the network, the detailed information 162b1 displayed on the EPG screen 162b may be controlled to be grayed out, as shown in FIG. 20B. In other words, the detailed information of the distributed program that cannot be viewed is controlled not to be displayed. Alternatively, the graying out process may be replaced by using a different background color for the detailed information 162b1. Alternatively, a message such as "This program cannot be viewed" may be displayed in the detailed explanation area 162a3 of the distributed program. When the detailed information 162b1 is selected by operating a remote control (not shown), the user may be notified by a pop-up or the like that the broadcast receiving device 100 is unable to access each server device on the network or that the distributed program associated with the detailed information 162b1 cannot be viewed.

Through the above-mentioned controls, the broadcast receiving device 100 is able to provide program information for each broadcast program in a format that feels more natural to the user, depending on the network connection status.

Figure 20C is a diagram showing another example of an EPG screen in the broadcast receiving device 100 of this embodiment. In the figure, "M1 Television," "M2 Broadcast," "M3 Channel," "M4 TV," "Television M5," etc. are the names of the broadcast stations for each channel, and in particular, the "M2 Broadcast" station simultaneously provides broadcast programs distributed via airwaves and streamed programs distributed via the Internet 200 (slot information 162c1 indicated by "Internet Broadcast" in the figure).

As shown in the figure, when there is a channel that only has programs distributed via the Internet 200, the EPG screen 162c in the figure (A) is normally controlled to display information for all channels (including information 162c1). On the other hand, if the broadcast receiving device 100 is unable to access each server device on the network, the EPG screen 162d in the figure (B) may be controlled not to display information for the "M2 Broadcast (Internet Broadcast)" channel (information 162c1 in the figure (A)), which only has programs distributed via the Internet 200.

The above-mentioned controls enable users of the broadcast receiving device 100 to avoid having to check information about channels that they cannot watch.

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

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

With the above-described control, in the broadcast receiving device 100 of this embodiment, when an emergency alert broadcast is received, it is possible to avoid missing important text information based on the emergency alert broadcast, even if the user has selected and displayed an EPG screen, various setting screens, a recorded program list screen, an internet browser, etc. This control may also be applied to text information in regular superimposed text that is not based on emergency alert broadcasts.

Furthermore, if the emergency alert broadcast is provided as a broadcast program on a dedicated channel (service ID), the channel (service ID) of the emergency alert broadcast may be automatically selected regardless of the channel (service ID) of the currently viewed program. Furthermore, if the emergency alert broadcast is provided as a broadcast program on a dedicated channel (service ID) or as an application, the emergency alert broadcast program or application may be distributed to a linked external mobile terminal device (in this embodiment, mobile information terminal 700, etc.) under the control of the linking function execution unit 1103.

Furthermore, if the broadcast receiving device 100 is not powered on when the emergency alert broadcast is distributed, control may be performed to automatically power on the broadcast receiving device 100. Alternatively, control may be performed to send a notification that an emergency alert broadcast has started to mobile information terminals 700 that have a history of linked operation with the broadcast receiving device 100.

By using the above-described control, the broadcast receiving device 100 of this embodiment makes it possible to avoid missing important broadcast programs or application images based on the emergency alert broadcast.

[Display control exception handling]
In the broadcast receiving device 100 of this embodiment, if it is unable to obtain data that is transmitted via a route other than the TLV stream among the data that constitutes the same package, it may perform exceptional processing, for example, as described below.

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

Under such circumstances, when an event is received in which the location information stored in the MPT indicates that data obtained from the TLV stream and data obtained from a route other than the TLV stream should be associated and included in the same package, the broadcast receiving device 100 of this embodiment may perform the following operations.

For example, if an LCT defines multiple regions within the screen as shown in Figures 17D and 17E, and program video based on data obtained from the TLV stream is displayed in "Region 0," and content based on data obtained from a transmission path other than the TLV stream is displayed in "Region 1" and "Region 2," and data from a transmission path other than the TLV stream to be displayed in "Region 1" or "Region 2" cannot be obtained, the layout display of the multiple regions specified by the LCT may be prohibited. Specifically, even when the LCT is received, the program video based on data obtained from the TLV stream may remain displayed in "Region 0" of the default layout display shown in Figure 17C, and the transition to the multi-region layout display shown in Figures 17D and 17E may not be made. Furthermore, even if an instruction to change from the default layout to the layout indicated by the LCT is input to the operation input unit 170 of the broadcast receiving device 100 in this state, the default layout display shown in Figure 17C may remain, or the display may be switched to another data broadcasting screen, preventing the transition to the multi-region layout display shown in Figures 17D and 17E.

Furthermore, in a case where the LCT sets multiple areas within the screen as shown in Figures 17D and 17E, and program video based on data obtained from the TLV stream is displayed in "Area 0," and content based on data obtained via a transmission path other than the TLV stream is displayed in "Area 1" and "Area 2," and data from a transmission path other than the TLV stream to be displayed in "Area 1" or "Area 2" cannot be obtained, another example of operation is to first display the display frames of the multiple areas shown in Figures 17D and 17E indicated by the LCT, and display a background color or a specified still image in "Area 1" or "Area 2."If data from a transmission path other than the TLV stream indicated by the MPT location information cannot be obtained after a specified time has elapsed, the display can be switched back to the default layout display state shown in Figure 17C. In this case, even when changing from the layout of Fig. 17C to the layout of Fig. 17D or Fig. 17E, and when changing from the layout of Fig. 17D or Fig. 17E to the layout of Fig. 17C, it is preferable to operate so that the program video based on the data obtained from the TLV stream continues to be displayed in "Area 0" of each layout, as this allows the user to continue watching the program video.

Furthermore, when program video based on data obtained from a TLV stream is displayed in "Area 0" of the default layout display shown in Figure 17C due to the inability to obtain data from transmission paths other than the TLV stream to be displayed in "Area 1" or "Area 2," the various communication functions and reception functions of the broadcast receiving device 100 of this embodiment may begin to operate, or the communication environment/communication status of the various communication functions or the reception environment/reception status of the various reception functions may change, resulting in a situation where data from a transmission path other than the TLV stream to be displayed in "Area 1" or "Area 2" may become available. 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 such as those shown in Figures 17D and 17E indicated by the LCT, and switch to display program video based on data obtained from a TLV stream in "Area 0," and display content based on data obtained from transmission paths other than the TLV stream in "Area 1" or "Area 2." Alternatively, the layout change may not be performed immediately, but may be performed after an instruction to change from the default layout to the layout indicated by the LCT is input from the operation input unit 170. In this case, it is preferable to notify the user that the layout change is now possible by means of an OSD display or the like.

[Copyright protection function]
In a digital broadcasting system compatible with the broadcast receiving device 100 of this embodiment, copy control information may be included in and transmitted to the MPT or the like to indicate the copy control status of the content referenced by the MPT or the like, such as "unlimited copying permitted" (which may be divided into two types: "unlimited copying permitted with encryption processing required for storage and output" and "unlimited copying permitted with encryption processing not required for storage and output"), "one generation copying permitted,""a specified number of copies permitted" (for example, "dubbing 10" where nine copies permitted and one move permitted is 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 (storage) unit 110, recording on a removable recording medium, output to an external device, copying to an external device, moving to an external device, etc., in accordance with the copy control information.

The target of the storage process may not only be the storage (storage) unit 110 inside the broadcast receiving device 100, but may also include removable recording media and external devices that have been protected by encryption or other means so that they can only be played on 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 recordable and playable only on the broadcast receiving device 100.

<Content copy control>
A specific example of content copy control processing based on the copy control information will be described below.

First, if the copy control information included in the MPT or the like indicates "unlimited copying permitted," the broadcast receiving device 100 of this embodiment may store data in the storage unit 110, record data on removable recording media, output data to an external device, copy data to an external device, move data to an external device, etc., without any restrictions. However, if the control based on the copy control information is divided into "unlimited copying permitted but encryption processing required for storage and output" and "unlimited copying permitted but encryption processing not required for storage and output," and indicates "unlimited copying permitted but encryption processing required for storage and output," then data may store data in the storage unit 110, record data on removable recording media, output data to an external device, copy data to an external device, move data to an external device, etc., without any restrictions, but encryption processing is required for all of these.

Furthermore, if the copy control information included in the MPT or the like indicates "copyable for one generation only," the broadcast receiving device 100 of this embodiment may be able to encrypt and store the content in the storage unit 110, or record it on a removable recording medium that has been protected by encryption or other means so that it can only be played on the broadcast receiving device 100. Furthermore, when the stored content is output to an external device for viewing, it is encrypted and output together with copy control information indicating "copy prohibited." Furthermore, so-called move processing to an external device (copying the content to an external device and erasing the content from the storage unit 110 of the broadcast receiving device 100 or the like to make it unplayable) is possible.

Furthermore, if the copy control information included in the MPT or the like indicates "copyable a specified number of times," the broadcast receiving device 100 of this embodiment may be able to encrypt and store the content in the storage unit 110, or record it to a removable recording medium that has been protected by encryption or other means so that it can only be played on the broadcast receiving device 100. Furthermore, when the stored content is output to an external device for viewing, it is encrypted and output along with copy control information indicating "copy prohibited." It may also be possible to copy and move to an external device a predetermined number of times. In the case of the so-called "Dubbing 10" standard, it is possible to copy to an external device nine times and move once.

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

Note that output for viewing to the aforementioned external device may be performed via the video output unit 163 and audio output unit 166 of the broadcast receiving device 100 of this embodiment, or via the digital I/F unit 125, LAN communication unit 121, etc. Copying or moving to the aforementioned external device may be performed via the digital I/F unit 125, LAN communication unit 121, etc.

Figure 22A shows an example of the data structure of a content copy control descriptor in the broadcasting system of this embodiment. The "digital_recording_control_data" parameter in the figure is digital copy control information, and indicates information that controls the number of copies of the content. Figure 22B also shows an example of the parameter value of the digital copy control information and its meaning. For example, if the parameter is "00", it indicates "unlimited copying", if the parameter is "01", it can be defined by the provider, if the parameter is "10", it indicates "one generation copying only", and if the parameter is "11", it indicates "copying prohibited". Figure 23 also shows an example of the data structure of a content usage control descriptor in the broadcasting system of this embodiment. The "copy_restriction_mode" parameter in the figure is the copy restriction mode, and indicates whether or not limited number of copies are allowed.

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

Through the above processing, the broadcast receiving device 100 of this embodiment is able to implement the aforementioned "predetermined number of copies allowed" content copy control.

The "retention_mode" parameter in the content usage control descriptor shown in Figure 23 is a temporary storage control bit, which indicates whether 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 allowable time, which indicates the temporary storage allowable time when the temporary storage allowable bit allows temporary storage of the target content.

In the broadcast receiving device 100 of this embodiment, by referencing the temporary storage control bit and the temporary storage allowable time, it is 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 enables appropriate content protection to be achieved according to the copy control information associated with the content.

<Content output control>
Next, a specific example of the process of controlling the output of content to an external device will be described below.

In the content usage control descriptor shown in Figure 23, the "image_constraint_token" parameter is a resolution restriction bit that indicates whether image quality restriction is required when outputting content to an external device. If the resolution restriction bit indicates that image quality restriction is required, the broadcast receiving device 100 of this embodiment will restrict the image quality of the target content when outputting the target content to an external device. Note that the image quality restriction may not be required when storing the content in a storage unit 110, etc. The image quality restriction may, for example, convert received (or stored) UHD (7680 pixels x 4320 pixels) video content to SHD (3840 pixels x 2160 pixels) video and output it, or convert HD (1920 pixels x 1080 pixels) video to SD (640 pixels x 480 pixels) video and output it. The extent to which the image quality of the target content will be restricted, i.e., the resolution of the image quality after the image quality restriction, may be specified by using part or all of the 'reserved_future_use' parameter in the digital content usage descriptor.

As described above, for example, frame rate limit bits and pixel resolution limit bits may be prepared using part or all of the 'reserved_future_use' parameter to control frame rate and pixel resolution limits when outputting content to an external device. If the frame rate limit bit indicates that a frame rate limit is necessary, the broadcast receiving device 100 of this embodiment will limit the frame rate of the target content when outputting the target content to an external device. For example, video content with a frame rate of 120 Hz may be converted to a frame rate of 60 Hz and output. Furthermore, if the pixel resolution limit bit indicates that a pixel resolution limit is necessary, the broadcast receiving device 100 of this embodiment will limit the resolution of each pixel of the target content when outputting the target content to an external device. For example, each pixel of video content consisting of 12 bits may be converted to 8 bits and output.

Furthermore, a resolution restriction control flag, a frame rate restriction control flag, or a pixel resolution restriction control flag may be prepared by using some or all of the 'reserved_future_use' parameter, and whether or not to restrict image quality, frame rate, or pixel resolution may be controlled according to the resolution restriction control flag, frame rate restriction control flag, or pixel resolution restriction control flag. For example, if the resolution restriction control flag indicates that resolution restriction control is to be performed according to interface specifications, control may be performed so that if the interface that outputs the target content has a specified content protection technology, the image quality restriction is not performed, and if the interface does not have the specified content protection technology, the image quality restriction is performed.

Specifically, for example, when the digital interface unit 125 is an HDMI interface and the target content is output to an external device connected to the HDMI interface, if the HDMI interface of the external device supports HDCP (High-bandwidth Digital Content Protection) version 2.2 or later, the target content is output without the image quality restriction. However, if the HDCP version of the HDMI interface of the external device is lower than 2.2, the target content is output with the image quality restriction. In other words, whether or not to restrict the image quality of the target content can be controlled depending on whether the interface that outputs the target content has a predetermined content protection technology, or, if it does have the content protection technology, depending on the version of the content protection technology. Note that if the resolution restriction control flag does not indicate that resolution restriction control should be performed according to the interface specifications, the presence or absence of the image quality restriction can be controlled depending only on the resolution restriction bit. Similar processing can be performed with respect to the frame rate restriction control flag and pixel resolution restriction control flag.

In addition, with regard to the copying process to an external device via the LAN communication unit 121 of content whose copy control information indicates copy restrictions such as "copyable for one generation only," "copyable a specified number of times," or "copying prohibited," this may be permitted only if the IP address of the external device that is the destination of the packet transmitted from the broadcast receiving device 100 is within the same subnetwork as the IP address of the broadcast receiving device 100, and may be prohibited if the IP address of the external device is outside the same subnetwork as the IP address of the broadcast receiving device 100. Content whose copy control information indicates "unlimited copying permitted but requires encryption processing when stored and output" may also be handled in the same manner.

Similarly, for content whose copy control information indicates copy restrictions such as "copyable for one generation only," "copyable a specified number of times," or "unlimited copying with encryption required when storing and outputting" that has once been stored in the storage unit 110, moving or copying to an external device via the LAN communication unit 121 is only permitted if the IP address of the external device that is the destination of the packet sent from the broadcast receiving device 100 is within the same subnetwork as the IP address of the broadcast receiving device 100, and may be prohibited if the IP address of the external device is outside the same subnetwork as the IP address of the broadcast receiving device 100.

Furthermore, as a general rule, video and audio output for viewing content stored in the storage (accumulation) unit 110 of the broadcast receiving device 100 is only possible if the IP address of the external device that is the destination of the packet transmitted from the broadcast receiving device 100 is within the same subnetwork as the IP address of the broadcast receiving device 100. This is prohibited if the IP address of the external device is outside the same subnetwork as the IP address of the broadcast receiving device 100. However, if the external device has been connected within the same subnetwork as the IP address of the broadcast receiving device 100 within a specified period of time and has been registered (paired) as a device that can be viewed even outside the same subnetwork as the IP address of the broadcast receiving device 100, the system may be configured to enable video and audio output for viewing content stored in the storage (accumulation) unit 110 of the broadcast receiving device 100 to the external device even if the IP address of the external device is outside the same subnetwork as the IP address of the broadcast receiving device 100. In this case, the video and audio output for viewing is performed after the content is 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 FIG. 23. That is, if the value of the "encryption_mode" parameter indicates that output protection of the IP interface output is required, the encryption process may be performed; if the value of the "encryption_mode" parameter indicates that output protection of the IP interface output is not required, the viewing video output and audio output may be performed without the encryption process. Furthermore, if the value of the "encryption_mode" parameter indicates that output protection of the IP interface output is required, the range of IP addresses of external devices that can perform the viewing video output and audio output without encryption may be specified, for example, by using part or all of the "reserved_future_use" parameter in the content usage control descriptor. That is, viewing video output and audio output may be performed for a predetermined IP address even if the IP address is not in the same subnet as the IP address of the broadcast receiving device 100.

It is also possible to specify a period during which the registration process (pairing) is valid, for example by using part or all of the 'reserved_future_use' parameter in the content usage control descriptor. In this case, if the date and time when the external device registration process (pairing) was performed is within the specified period, audio and video output to the external device is permitted even if the external device is located outside the same subnetwork as the IP address of the broadcast receiving device 100, but is not permitted if the date and time is outside the specified period.

Furthermore, the aforementioned processes of moving, copying, outputting, etc. of 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. In other words, if the value of the 'remote_view_mode' parameter does not allow remote viewing of the target content, control may be exercised to prohibit all processes of moving, copying, outputting, etc. of content to external devices via the LAN communication unit 121.

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

<Content Copy Control Exception Processing 1>
In the data structure of the content copy control descriptor shown in Fig. 22A, the first digital copy control information (the "digital_recording_control_data" parameter located immediately after "descriptor_length") is 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 copy generation control information for each component that makes up the content. Each component is specified by the "component_tag" parameter.

In the broadcasting system of this embodiment, when copy generation control is performed for the entire content (program), only the first digital copy control information is described in the content copy control descriptor, and copy generation control is performed using the first digital copy control information. On the other hand, when copy generation control is performed for each component that makes up 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 copy generation control is performed. Furthermore, when copy generation control is performed for each component that makes up the content, there may be a situation 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 above-mentioned situation, the broadcast receiving device 100 of this embodiment may be configured to operate as shown below.

First, the first operational example is a method of controlling operation 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, simple copy generation control common to each component that makes up the same content becomes possible.

Next, the second operation example is a method of controlling operation 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, different copy generation control is possible for each component, even for components that make up the same content, meaning more precise copy generation control is possible.

Furthermore, a third operational example is a method of controlling operation so that, if the descriptions in the first digital copy control information and the second digital copy control information do not match, operation is based on the digital copy control information with the stricter conditions of the two different digital copy control information. For example, if one is "unlimited copying permitted" and the other is "one generation copying permitted," the "one generation copying permitted" information is followed. Alternatively, if one is "a specified number of copies permitted" and the other is "copying prohibited," the "copying prohibited" information is followed. Alternatively, if both are "a specified number of copies permitted," the separately specified information with the fewer number of copies permitted is followed. In this case, stricter copy generation control is possible.

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

<Content Copy Control Exception Processing 2>
As explained using Figure 7A, in the digital broadcasting system supported by the broadcast receiving device 100 of this embodiment, location information in the MPT (see Figure 7C) may mean that 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 the same event as the data acquired via the TLV stream. This section explains content protection when copy control information is included in the MPT, etc.

First, when copy control information is included in the MPT or the like, data included in the same package and the same event in the location information may be controlled in accordance with the copy control information included in the TLV stream, even if the data was obtained via a different path (IPv4, IPv6, MPEG2-TS, URL, etc.) than the data obtained via the TLV stream of the broadcast path. The copy control status of the content specified by this copy control information can be, as mentioned above, "unlimited copying" (which may be divided into two types: "unlimited copying with encryption required for storage and output" and "unlimited copying with no encryption required for storage and output"), "one generation only," "a specified number of copies allowed" (for example, 9 copies allowed + 1 move allowed is known as "dubbing 10"), "no copying allowed," etc.

Here, if the data position indicated by the location information includes MPEG2-TS data transmitted in another digital broadcast signal, that MPEG2-TS data is also broadcast in association with copy control information in that other digital broadcast signal. This raises the question of how and according to which information copy control of that MPEG2-TS data should be performed (should it be according to the copy control information contained in the TLV/MMT stream, or the copy control information contained in the MPEG2-TS itself?).

In the digital broadcasting system of this embodiment, to solve this problem, the broadcast receiving device 100 can perform one of the following solutions:

<Operation example 1>
In the first operation example, when copy control information is included in the MPT etc., and data included in the same package and the same event in the location information includes MPEG2-TS data transmitted in another digital broadcast signal, 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 contained in the TLV stream is "one-generation copy permitted" and the copy control status indicated by the copy control information contained in the MPEG2-TS is "a specified number of copies permitted," then even if the data was acquired via a different path than the data acquired in the TLV stream (digital broadcast in MPEG2-TS transmission format), copy control may be performed on the data as "one-generation copy permitted" content. For example, if the copy control status indicated by the copy control information contained in the TLV stream is "unlimited copying permitted" and the copy control status indicated by the copy control information contained in the MPEG2-TS is "specified number of copies permitted," copy control may be performed on the data as "unlimited copying permitted" content, even if the data was acquired via a different path than the data acquired in the TLV stream (digital broadcast in MPEG2-TS transmission format).

With this operation, data acquired via routes other than TLV streams can also be put into the copy state that you want to manage in the broadcast system supported by the broadcast receiving device 100 of this embodiment.

<Operation example 2>
In a second operation example, when copy control information is included in the MPT or the like, and data included in the same package and the same event in the location information includes MPEG2-TS data transmitted in another digital broadcast signal, 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, and 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 MPEG2-TS data is excluded from the content to be processed when storing the data in the storage unit 110 or the like, recording the data on a removable recording medium, or outputting the data from a digital interface.

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

Furthermore, if the comparison shows that the copy control status indicated by the copy control information contained in the MPEG2-TS is the same as or more lenient than the copy control status indicated by the copy control information contained in the TLV stream, then copy control can be performed on the MPEG2-TS data contained in the same package and event using that location information as content in the copy control status indicated by the copy control information contained in the TLV stream.

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

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

According to the embodiment described above, it is possible to provide a broadcast receiver compatible with MMT digital broadcasting.

Example 2
The following describes a second embodiment of the present invention. It should be noted that the configuration, processing, effects, and the like of this embodiment are the same as those of the first embodiment unless otherwise specified. Therefore, the following mainly describes the differences between this embodiment and the first embodiment, and explanations of commonalities are omitted as much as possible to avoid duplication. The following description also assumes that the broadcast receiving device of this embodiment is a television receiver that supports both the MMT and MPEG2-TS media transport methods.

[Hardware configuration of broadcast receiving device]
24 is a block diagram showing an example of the internal configuration of a broadcast receiving device 800. The broadcast receiving device 800 is composed 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 processing unit 841, an MPEG2-TS decoding processing unit 842, a video synthesis unit 861, a monitor unit 862, a video output unit 863, an audio synthesis unit 864, a speaker unit 865, an audio 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 equivalent functions to the main control unit 101, system bus 102, ROM 103, RAM 104, storage (accumulation) 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 Example 1, and detailed description thereof will be omitted.

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

The MMT decoding processing unit 841 inputs 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 a video data sequence, an audio data sequence, a superimposed text data sequence, and a subtitle data sequence based on a control signal included in the MMT data sequence. The MMT decoding processing unit 841 has functions equivalent to the separation unit 132, video decoder 141, video color gamut conversion unit 142, audio decoder 143, superimposed text 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, and sound source unit 156 of the broadcast receiving device 100 of Example 1. The MMT decoding processing unit 841 is capable of performing the various processes described in Example 1. Note that the details of the various processes are the same as those described in Example 1, and therefore will not be described here.

The MPEG2-TS decoding processing unit 842 inputs the MPEG2-TS data stream output from the second tuner/demodulation unit 832 and performs processes such as separating and decoding the real-time presentation elements, such as the video data stream, audio data stream, superimposed text data stream, and subtitle data stream, 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 a broadcast service that uses MPEG2-TS as the media transport method, and detailed description thereof will be omitted.

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

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

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

In general, when the video synthesis unit 861 primarily selects video information, etc. output from the MMT decoding processing unit 841, it can be controlled so that information relating to the current date and time obtained from the MH-TOT is superimposed on the video information, etc., and when the video synthesis unit 861 primarily selects video information, etc. output from the MPEG2-TS decoding processing unit 842, it can be controlled so that information relating to the current date and time obtained from the TOT is superimposed on the video information, etc.

However, because there are differences in encoding/decoding processes and transmission paths between broadcast services that use MMT as the media transport method and broadcast services that use MPEG2-TS as the media transport method, there is a possibility that inconsistencies may occur, particularly in the current time display, when selecting a broadcast service that uses MMT as the media transport method and a broadcast service that uses MPEG2-TS as the media transport method. For example, as shown in FIG. 25, when switching the screen display from EPG screen 162g, which displays channel information for a broadcast service that uses MMT as the media transport method, to EPG screen 162h, which displays channel information for a broadcast service that uses MPEG2-TS as the media transport method, the current time display switches from current time display 162g1 to current time display 162h1, creating an inconsistency that may cause the user to feel visually uncomfortable.

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

By performing the above control, the broadcast receiving device 800 of this embodiment always displays the current time information obtained by referencing the TOT when displaying the current time. Therefore, even when switching between a broadcast service that uses MMT as the media transport method and a broadcast service that uses MPEG2-TS as the media transport method, it is possible to prevent the user from feeling visually uncomfortable due to inconsistencies in the display of the current time.

Note that Figure 26A shows an example of the selection control of the current time information reference source in accordance with 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 that uses MPEG2-TS as the media transport method is possible, the device always references the TOT to acquire current time information, and only when reception of a broadcast service that uses MPEG2-TS as the media transport method is impossible and reception of a broadcast service that uses MMT as the media transport method is possible, the device is controlled to reference the MH-TOT to acquire current time information.

In addition, the same effect as described above can be achieved by controlling the content of a broadcast service that uses MMT as the media transport method to be superimposed on the content of a broadcast service that uses MPEG2-TS as the media transport method, in the opposite way to the above control.

As mentioned above, in either case, whether the current time information provided by a broadcast service that uses MPEG2-TS as the media transport method is superimposed on the content of a broadcast service that uses MMT as the media transport method, or the current time information provided by a broadcast service that uses MPEG2-TS as the media transport method is superimposed on the content of a broadcast service that uses MMT as the media transport method, the current time information can be corrected by referencing the "delta" parameter of the time information in the TMCC extension information area, as described in "Time Management of Broadcast Receiving Device" in Example 1.

In addition, in both cases of broadcast services that use MMT as the media transport method and broadcast services that use MPEG2-TS as the media transport method, there is a possibility that the MH-TOT or TOT transmitted by each broadcast service that makes up the network may contain errors due to malfunctions in the transmitting system, transmission errors, etc. As a countermeasure against such errors in the MH-TOT or TOT, the broadcast receiving device 800 of this embodiment has the function of acquiring the MH-TOT or TOT from another broadcast service on the same network or from any broadcast service on another network, referencing the current time information, and updating the time information of the built-in clock, if it determines that the MH-TOT or TOT acquired from the service being received contains an error.

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

When updating the time information of the built-in clock in the broadcast receiving device 800 of this embodiment, the reception function execution unit 1102 first acquires the TOT from the MPEG2-TS data stream of the currently being received broadcast service (a broadcast service that uses MPEG2-TS as the media transport method) (S301), and then acquires current time information by referencing the acquired TOT (S302). Next, the reception function execution unit 1102 performs a process of comparing the current time information acquired in the process of S302 with the time information of the built-in clock.

If the result of the comparison process shows that the difference between the current time information acquired in S302 and the time information of the built-in clock is within a predetermined value (e.g., within 3 minutes) (S303: Yes), the reception function execution unit 1102 updates the time information of the built-in clock using the current time information acquired in S302 (S306). On the other hand, if the result of the comparison process shows that the difference between the current time information acquired in S302 and the time information of the built-in clock is not within a predetermined value (S303: No), or if the TOT acquired in S301 contains a flag indicating an error in the data, the reception function execution unit 1102 acquires the TOT from the MPEG2-TS data sequence of another broadcast service on the same network, or acquires the MH-TOT from the MMT data sequence of any broadcast service on another network (a broadcast service that uses MMT as the media transport method) (S304), and further acquires the current time information from the acquired TOT or MH-TOT (S305). The reception function execution unit 1102 can then perform the comparison process of S303 again using the current time information acquired in the process of S305.

By performing the above process, if the broadcast receiving device 800 of this embodiment determines that the MH-TOT or TOT obtained from the service being received contains an error, it can obtain the MH-TOT or TOT from another broadcast service on the same network, or from any broadcast service on another network, and refer to the current time information to update the time information of the built-in clock.

Note that if repeating steps S304 and S305 fails to obtain current time information whose difference with the time information of the built-in clock falls within a specified range, such as during initial setup after shipping from the factory, the time information of the built-in clock can be set again using the current time information obtained in step S302. This makes it possible to deal with cases where there is an error in the time information of the built-in clock of the broadcast receiving device 800 of this embodiment.

[EPG display on broadcast receiving device]
Event schedule information for broadcast services that employ MMT as the media transport method is transmitted by MH-EIT, etc. On the other hand, event schedule information for broadcast services that employ MPEG2-TS as the media transport method is transmitted by EIT (Event Information Table) or the like provided in SI defined in the MPEG-2 system. Therefore, generally, when video information, etc. provided by a broadcast service that employs MMT as the media transport method is displayed, the event schedule information (MH-EIT) for the broadcast service that employs MMT can be acquired, and when video information, etc. provided by a broadcast service that employs MPEG2-TS as the media transport method is displayed, the event schedule information (EIT) for the broadcast service that employs MPEG2-TS can be acquired.

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

Figure 27A shows an example of an 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 broadcast service that uses MMT as the media transport method, with "M1 TV," "M2 Broadcast," "M3 Channel," "M4 TV," "Television M5," etc. being the names of broadcast stations for broadcast services that use MMT as the media transport method. Also, EPG screen 162j is an EPG screen created based on the EIT of a broadcast service that uses MPEG2-TS as the media transport method, with "T6 TV," "T7 Broadcast," "T8 Channel," "T9 TV," "Television TA," etc. being the names of broadcast stations for broadcast services that use MPEG2-TS as the media transport method.

For example, if a user operates a remote control (not shown) to display an EPG screen while watching a broadcast program provided by a broadcast service that uses MMT as the media transport method, the initial EPG screen (not shown) will be displayed. The initial EPG screen is an EPG screen created based on the MH-EIT of the broadcast service that uses MMT as the media transport method, and displays detailed information about broadcast programs on each channel from 5:00 PM on October 7, 2014 (today) (nearby the current time). Next, if the user wishes to check detailed information about broadcast programs on each channel from 8:00 PM on October 9, 2014, and operates a remote control (not shown) to update the EPG screen, EPG screen 162i will be displayed.

Furthermore, if the user wishes to check detailed information about a broadcast program provided by a broadcast service that uses MPEG2-TS as the media transport method and operates a remote control (not shown) to instruct a network switch, EPG screen 162j is displayed. In this case, the broadcast receiving device 800 of this embodiment is controlled to display detailed information about the broadcast programs on each channel on the same day and in the same time slot (i.e., from 8:00 PM on October 9, 2014) as the previously displayed EPG screen 162i, rather than the initial EPG screen (i.e., detailed information about the broadcast programs on each channel from 5:00 PM on October 7, 2014) created based on the EIT of the broadcast service that uses MPEG2-TS as the media transport method.

The above control allows the user to easily and continuously check detailed information about broadcast programs airing on the same day and at the same time on multiple networks using different media transport methods. This improves the usability of the broadcast receiving device 800.

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 in which EPG screen 162i shown in Figure 27A has been scrolled in the channel direction (horizontal direction) by operating a remote control (not shown). In other words, 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 that uses MMT as the media transport method and channel information created based on the EIT of a broadcast service that uses MPEG2-TS as the media transport method are seamlessly displayed on the same timeline.

Therefore, even if a user wishes to check channel information created based on the EIT of a broadcast service that uses MPEG2-TS as the media transport method while checking channel information created based on the MH-EIT of a broadcast service that uses MMT as the media transport method, there is no need to issue a command to switch networks using a remote control (not shown). Furthermore, the user can simultaneously check detailed information about broadcast programs airing on the same day and at the same time on multiple networks that use different media transport methods. This improves the usability of the broadcast receiving device 800.

Example 3
The following describes Example 3 of the present invention. It should be noted that the configuration and effects of this Example are the same as those of Example 1 or Example 2 unless otherwise specified. Therefore, the following mainly describes the differences between this Example and Example 1 or Example 2, and explanations of common points are omitted as much as possible to avoid duplication. Furthermore, in this Example, the cooperative operation between a broadcast receiving device and a mobile information terminal will be described.

[Application Transmission Method Overview]
The application transmission method of this embodiment will be described with reference to FIG.

The broadcasting system of this embodiment is capable of using a transmission method equivalent to the data carousel transmission method used in general digital broadcasting. In other words, when downloading data to a receiver or transmitting content for multimedia services, data is repeatedly sent, allowing the receiver to obtain the necessary data at any time during the broadcast. Data is encapsulated in an asynchronous MPU on a file-by-file basis and transmitted. Control information related to application transmission may be transmitted using a data transmission message. The data transmission message is assumed to store a data directory management table, a data asset management table, and a data content management table.

The files that make up an application are specified by path names within the application description, such as HTML5. The path name may be written as a combination of a directory node name and a file name. In addition, a node tag is defined as an identifier that combines the directory node and file, and is used as information that links each table.

When a path name is specified by an application, the receiver obtains the node tag of the file with the specified path name from the data directory management table in the data transmission message. Next, from the data asset management table also in the data transmission message, it obtains the component tag, download ID, MPU sequence number, and item ID of the asset to which the item with the obtained node tag is to be transmitted. Furthermore, by referencing the MP table, it obtains location information for the asset with the obtained component tag and identifies the asset to which the file will actually be transmitted. Within the identified asset, the obtained download ID and the download ID written in the multi-extension header field of the MMTP packet transmitting the item can uniquely identify the unit of repeated transmission of the file corresponding to the carousel, and from among the repeatedly transmitted items, it is possible to obtain the item with the obtained MPU sequence number and item ID as the desired file.

Note that the node tag is unique within the data transmission message, the MPU sequence number is unique within the asset, and the item ID is unique within the service provider.

Furthermore, by constantly monitoring the data asset management table, the receiver can detect when the files that make up an application have been updated, making it possible to always present the application in its latest state. Update detection can be performed at each stage: asset-by-asset, MPU-by-MPU, or file-by-file. The data asset management table is used to obtain the component tag, MPU sequence number, and item ID of the updated file. As with the file acquisition described above, the asset can be identified by referencing the MP table, and the item with the obtained MPU sequence number and item ID can be acquired as the desired updated file.

The data content management table provides configuration information for files as data content, enabling flexible and effective cache control. The unit presented within the data content (e.g., a page) is defined as a presentation unit, and information such as which items are related to that unit and which presentation units they are linked to is shown. This information makes it possible to know other items contained in the same presentation unit as the initially requested item. It is also possible to obtain information such as cache control on a presentation unit basis. As a result, the receiver can reduce the time it takes to retrieve the entire page and prioritize caching of the next page.

As mentioned above, applications and data are also transmitted as assets, and the asset type (asset_type) is recorded in the MP table (MPT: see Figure 7B). Asset types are summarized in Figure 29. In addition to broadcast video, audio, and subtitle data, applications and data used by applications are transmitted as assets. Furthermore, the assets for applications and data used by applications may be obtained via broadcast waves or via communication lines. Figure 30A shows an example of the data structure of location information (MMT_general_location_info) that describes the asset acquisition source. This location information describes the acquisition source type (location_type) and the acquisition source. The meaning of the acquisition source type is shown in Figure 30B.

[Application presentation format]
Like broadcast video and audio, applications are presented in regions defined in the layout setting table (LCT: see FIG. 17A). The region to be used is specified by the layout number (layout_number) and region number (region_number) in the MPU presentation region designation descriptor (MPU_Presentation_Region_Descriptor). An example of the data structure of the MPU presentation region designation descriptor is shown in FIG. 31.

[Application Control Information Overview]
The application control information in this embodiment is information intended to inform a television receiver or the like (in this embodiment, the broadcast receiving device 100) of the existence of an application (hereinafter, sometimes referred to as a broadcast-linked app) that links with a broadcast service and to instruct its control in the broadcast-communication linkage function supported by the broadcast receiving device 100. Note that the application control information in this embodiment is transmitted in the form of an MH-application information table (MH-AIT: see FIG. 6B) in the broadcast system.

Furthermore, the broadcast-linked apps may be classified into (1) broadcast-managed applications that operate only in a broadcast reception state based on control signals such as start/stop included in the broadcast signal and are permitted to access broadcast resources based on the control signals, (2) non-broadcast-managed applications that operate in a manner that is not controlled by the broadcast signal for start/stop etc. and are permitted to access broadcast resources based on means such as application authentication, and (3) other general applications that are not permitted to access broadcast resources.

The MH-AIT is stored in the M2 section message (see Figure 6A) and transmitted. An example of the data structure of the MH-AIT is shown in Figure 32A.

The type of application to be controlled by MH-AIT is indicated by the "application_type" parameter. The allocation of application types is shown in Figure 32B. The control code that controls the state of the application is indicated by the "application_control_code" parameter. The application control code may be specified for each application type. If there is no specification for each application type, the meaning shown in Figure 32C shall be used.

Applications are identified by an application identifier (application_identifier). An example of the data structure of an application identifier is shown in Figure 32D. The application identifier is a value that uniquely identifies each application, specified for each application type. The application identifier may consist of an organization identifier (organization_id) that identifies the operator and an application identifier (application_id) assigned to each operator. The same application identifier for each operator may be reused for different applications at different times, but in this case, it is desirable to take into account the application cache expiration date (MH-cache information descriptor: see Figure 6D) and to prevent the same identification value from being assigned to different applications within the receiver.

[Descriptors described in MH-AIT]
Information about each application is described in the descriptors in addition to the parameters described above. Figures 6C and 6D show a list of descriptors for this broadcasting system, but the main descriptors related to MH-AIT are described in detail below.

(1) MH-Application Descriptor One MH-Application Descriptor shall be placed for each application in the application information descriptor loop of the MH-AIT. An example of the data structure of the MH-Application Descriptor is shown in Figure 33. The "application_profile" parameter indicates the application profile of the receiver that can execute the target application. If the receiver implements this profile, it indicates that it has the ability to execute the target application. The content of the profile is defined for each application format.

(2) MH-Transmission Protocol Descriptor This descriptor is intended to specify the transmission protocol, such as broadcasting or communication, as the transmission means for an application and to indicate the location information of applications dependent on the transmission protocol. It is placed in the MH-AIT common descriptor loop or application information descriptor loop for the number of transmission protocol labels in the application descriptor. An example of the data structure of the MH-Transmission Protocol Descriptor is shown in Figure 34A. The "protocol_id (protocol identification)" parameter sets the protocol for transmitting the target application. The meaning of the protocol identification is shown in Figure 34B. Furthermore, supplementary information specified for each protocol identification is stored in the "selector_byte (selector area)." An example of the data structure of the selector area for HTTP/HTTPS transmission and MMT non-timed transmission is shown in Figure 34C. It is assumed that information about the URL for acquiring the target application can be obtained using the "URL_base_byte" parameter, the "URL_extension_byte" parameter, and the like.

(3) MH-Simple Application Location Descriptor The purpose of the MH-Simple Application Location Descriptor is to specify the details of where to obtain an application, and one MH-Simple Application Location Descriptor must be placed for each application in the application information descriptor loop of the MH-AIT. An example of the data structure of the MH-Simple Application Location Descriptor is shown in Figure 35. The "initial_path_byte (application URL)" parameter indicates the URL that is the entry point of the target application. This may be indicated by a relative path rooted at the location where the target application can be obtained, as described in the transmission protocol descriptor.

(4) MH-Application Boundary Authority Setting Descriptor The MH-Application Boundary Authority Setting Descriptor is intended to set the application boundary and to set broadcast resource access authority for each area (URL). One or more MH-Application Boundary Authority Setting Descriptors shall be placed in the application information descriptor loop of the MH-AIT. If this descriptor is not placed, the application boundary will be infinite, and access to all broadcast resources will be permitted. An example of the data structure of the MH-Application Boundary Authority Setting Descriptor is shown in Figure 36. The "permission_bitmap (access authority bitmap)" parameter configures the access permission for each broadcast resource using a bitmap for each function. The "managed_URL_byte (access authority management area setting information)" parameter indicates the URL of the area to which the access authority setting indicated by the access bitmap applies. The access authority management area setting information is specified by the domain or its subdirectory.

(5) MH-Launch Priority Information Descriptor The MH-Launch Priority Information Descriptor is intended to specify the application startup priority, and a maximum of one shall be placed per application in the application information descriptor loop of the MH-AIT. However, this descriptor may be placed only in application information descriptions indicating that the application control code indicates the automatic startup of the application (such as "AUTOSTART"). Furthermore, if this descriptor is not placed, it may be considered to have the lowest priority, including data broadcasting. An example of the data structure of the MH-Launch Priority Information Descriptor is shown in Figure 37. The "autostart_priority (launch priority)" parameter indicates the startup priority of the target application among data broadcasting and all applications linked to the currently received service.

(6) MH-Cache Information Descriptor The MH-Cache Information Descriptor is intended for use in cache control when caching and retaining resources that constitute an application when the application is expected to be reused. A maximum of one MH-Cache Information Descriptor shall be placed per application in the application information descriptor loop of the MH-AIT. If this descriptor is not placed, the receiver may delete the resources that constitute the application without retaining them when the application is terminated. An example of the data structure of the MH-Cache Information Descriptor is shown in Figure 38A. The "cache_priority" parameter indicates the priority for retaining the cache for the target application. The larger the value, the higher the priority. If the cache capacity is exceeded, cache deletion shall be performed on an application-by-application basis based on this information. If no priority is specified, this parameter shall be "0xFF." The "application_version" parameter indicates the version number of the target application.

The receiver stores the application version corresponding to the cached application, and if the application version has been updated when the application is launched subsequently, it will not use the application stored in the cache, but will instead retrieve and use the new application from the specified URL, and will also rewrite the contents of the cache. The "expire_date (cache expiration date)" parameter indicates the cache expiration date of the target application as a year, month, and day in the lowest 16 bits of the MJD. The receiver can cache the target application until this expiration date. If the expiration date is exceeded, the application will be deleted from the cache. For an indefinite expiration, set this parameter to "0xFFFF". If this cache expiration parameter is not set, it is possible to prioritize application stability and prohibit cache retention after the program ends, or to retain the cache indefinitely for viewer convenience, or to strike a balance between the two and retain the cache for a predetermined period of time.

Alternatively, instead of a cache expiration date, an expiration date for each application can be set. Figure 38B shows an example of the data structure of an MH-application expiration date descriptor, which describes the expiration date for each application. If this expiration date is exceeded, the use of that application will be prohibited. While long-term caching is not permitted, it is possible to allow the application to be re-acquired and used for a certain period of time, enabling a variety of application usage patterns.

(7) MH-Probabilistic Application Delay Descriptor The MH-Probabilistic Application Delay Descriptor is intended to delay the timing of application control by a probabilistically set delay amount, assuming load balancing of server access for application acquisition. Up to one MH-Probabilistic Application Delay Descriptor shall be placed per application in the MH-AIT application information descriptor loop. If this descriptor is not placed, the control operation indicated in the control code shall be performed when a specific version of MH-AIT is first received. An example of the data structure of the MH-Probabilistic Application Delay Descriptor is shown in Figure 39. The "range (delay time width)" parameter indicates the maximum delay time from the current time until the control code is applied, in seconds. The "rate (variance number)" parameter indicates the number of delay steps until the control code is applied probabilistically. The receiver calculates the delay time using the formula "N x range ÷ rate" based on the value "N" randomly selected from integers between "0" and "rate," and applies the control code by the delay amount from the time the MH-AIT was received. The "randomization_end_time" parameter indicates the time limit for the random application delay process. If an MH-AIT is received after the time indicated in this parameter, the control code is applied immediately. The date is coded in the lower 16 bits of MJD, and the time is coded in 24 bits of BCD for the hour, minute, and second in JST.

Furthermore, the MH-AIT of this embodiment may further include parameters, descriptors, etc. different from those described above.

The following describes the operation of the broadcast receiving device 100 in this embodiment.

[Application startup sequence]
First, the automatic start-up process of a broadcast-linked app based on MH-AIT transmitted by broadcast waves in the broadcast receiving device 100 of this embodiment will be described with reference to Fig. 40A. This is an example of a case where a broadcast-linked app related to a selected channel is automatically started.

When the tuner/demodulator unit 131 of the broadcast receiving device 100 performs the process of selecting the user's desired channel and acquires the MMT data sequence, the application control unit 153 checks the MH-AIT stored in the M2 section message (S1001). If the MH-AIT is not stored in the M2 section message, it is assumed that there is no broadcast-linked app related to the selected channel, and the automatic startup process can be terminated. Next, the application format and application control code of each broadcast-linked app described in the MH-AIT are checked (S1002). If the result of the process in S1002 shows that there is no broadcast-linked app with the application control code "AUTOSTART" (S1003: No), the automatic startup process can be terminated. In this case, the launcher process can be performed again, which will be described later.

On the other hand, if the result of processing S1002 indicates that there is a broadcast-linked app with an application control code of "auto-start" (S1003: Yes), the MH-start priority information descriptor in the MH-AIT associated with the broadcast-linked app is checked (S1004). Next, the broadcast-linked app with the highest priority among the broadcast-linked apps with an application control code of "auto-start" is selected (S1005), and the MH-application descriptor in the MH-AIT associated with the selected broadcast-linked app is checked (S1006). If the broadcast receiving device 100 satisfies the application profile described in the MH-application descriptor (S1007: Yes), proceed to the next processing. If the broadcast receiving device 100 does not satisfy the application profile described in the MH-application descriptor (S1007: No), it is determined that the selected broadcast-linked app cannot be started on the broadcast receiving device 100. In this case, it is checked whether there is a second-priority broadcast-linked app (S1008), and if there is no second-priority broadcast-linked app, the automatic start processing may be terminated. If there is a broadcast-linked app with the next highest priority, the broadcast-linked app with the next highest priority is selected (S1009), and the processes of S1006 to S1007 are repeated.

If the broadcast receiving device 100 determines in the processing of S1007 that the application profile described in the MH-application descriptor is satisfied, it checks the MH-transmission protocol descriptor of the MH-AIT related to the selected broadcast-linked app (S1010). If the result of the processing of S1010 indicates that the selected broadcast-linked app can be acquired via HTTP/HTTPS transmission based on the protocol identification described in the MH-transmission protocol descriptor (S1011: Yes), it further checks the MH-simple application location descriptor of the MH-AIT related to the selected broadcast-linked app (S1012) and acquires the URL of the entry point of the selected broadcast-linked app.

After obtaining the URL of the entry point of the selected broadcast-linked app in the process of S1012, the LAN communication unit 121 then requests the server specified by the URL on the Internet 200 (in this embodiment, the service provider server 400) to distribute the broadcast-linked app (S1013). The service provider server 400, which receives the distribution request, performs appropriate authentication processing for the broadcast receiving device 100, and then distributes the requested broadcast-linked app (S1014). Upon receiving the broadcast-linked app from the service provider server 400 via the LAN communication unit 121, the broadcast receiving device 100 launches the received broadcast-linked app in the browser unit 154 under the control of the application control unit 153 (S1018). The authentication processing for the broadcast receiving device 100 performed by the service provider server 400 may be a well-known process, and detailed description thereof will be omitted.

On the other hand, if the result of processing S1010 indicates that the selected broadcast-linked app can be acquired by data carousel transmission using the protocol identification described in the MH-transmission protocol descriptor (S1011: No), the application control unit 153 checks the DDM table and DAM table stored in the data transmission message (S1015, S1016) and identifies the asset to which the selected broadcast-linked app will be transmitted using the procedure described above in [Overview of application transmission method]. Furthermore, after acquiring the broadcast-linked app from the identified asset of the broadcast wave (S1017), the broadcast receiving device 100, under the control of the application control unit 153, launches the received broadcast-linked app in the browser unit 154 (S1018).

The above series of processes enables the broadcast receiving device 100 of this embodiment to automatically launch a broadcast-linked app based on the MH-AIT transmitted via broadcast waves. Note that the MH-AIT confirmation process in each of S1004, S1006, S1010, and S1012 may involve obtaining and confirming the MH-AIT from the broadcast waves each time, or may involve caching the MH-AIT obtained in S1001 and confirming the cached MH-AIT. Furthermore, the above operational sequence is merely an example, and different processing procedures may also be used.

Next, using Figure 40B, we will explain the launcher processing of a broadcast-linked app based on the MH-AIT transmitted via broadcast waves in the broadcast receiving device 100 of this embodiment. This is an example of when a broadcast-linked app related to a selected channel is launched based on a user instruction.

When the tuner/demodulator unit 131 of the broadcast receiving device 100 performs the process of selecting the user's desired channel and acquires the MMT data string, the application control unit 153 checks the MH-AIT stored in the M2 section message (S1101). Note that if the MH-AIT is not stored in the M2 section message, it may be assumed that there is no broadcast-linked app related to the selected channel, and the automatic startup process may be terminated. Next, the application format and application control code of each broadcast-linked app described in the MH-AIT are checked (S1102). If the result of the process of S1102 shows that there is a broadcast-linked app with an application control code of "AUTOSTART" (S1103: Yes), the automatic startup process shown in FIG. 40A can be performed.

On the other hand, if the result of processing S1102 shows that there is no broadcast-linked app with an application control code of "auto-start" (S1103: No), the system checks again to see if there is a broadcast-linked app with an application control code of "executable (PRESENT)," and if there is no broadcast-linked app with an application control code of "executable" (S1104: No), the launcher processing may be terminated. If there is a broadcast-linked app with an application control code of "executable" (S1104: Yes), the MH-application descriptor of the MH-AIT for each broadcast-linked app with the application control code of "executable" is checked (S1105). If the result of processing S1105 shows that there is no broadcast-linked app whose application profile described in the MH-application descriptor is satisfied by the broadcast receiving device 100 (S1106: No), the launcher processing may be terminated. If there is at least one broadcast-linked app for which the broadcast receiving device 100 satisfies the application profile described in the MH-application descriptor (S1106: Yes), proceed to the next process.

After completing the processing of S1101 to S1103 and S1104 to S1106, it is assumed that the broadcast receiving device 100 has not yet executed the broadcast-linked app, and that normal broadcast program video is displayed on the monitor unit 162. In this state, when the user issues an instruction to launch the broadcast-linked app launcher using a remote control or mobile information terminal capable of operating the broadcast receiving device 100 (S1107), a list of broadcast-linked apps that can be executed by the broadcast receiving device 100 is displayed on the monitor unit 162 via OSD (S1108). Furthermore, when the user operates the remote control or mobile information terminal to instruct selection of a desired broadcast-linked app from the list of broadcast-linked apps (S1109), the application control unit 153 selects a broadcast-linked app based on the user's instruction (S1110), and acquires and launches the selected broadcast-linked app (S1111 to S1119). Note that the processing of S1111 to S1119 may be the same as the processing of S1010 to S1018 shown in Figure 40A.

The above series of processes enables the broadcast receiving device 100 of this embodiment to perform launcher processing for broadcast-linked apps based on the MH-AIT transmitted via broadcast waves. Note that the MH-AIT confirmation process in each of S1105, S1111, and S1113 may involve obtaining and confirming the MH-AIT from the broadcast waves each time, or by caching the MH-AIT obtained in S1101 and confirming the cached MH-AIT. The order of S1104 to S1106 and S1107 to S1110 may also be reversed. In this case, the profile confirmation process in S1104 to S1106 may be performed only for the broadcast-linked app selected in S1110. Furthermore, the list of broadcast-linked apps displayed in the processing of S1108 may be configured to display only those that can be executed on the broadcast receiving device 100 depending on the status of the application profile, or it may be configured to display all broadcast-linked apps regardless of the status of the application profile and disable those that cannot be executed on the broadcast receiving device 100. Furthermore, the above operation sequence is merely an example, and different processing procedures may be used.

Next, we will use Figure 40C to explain the process of launching a broadcast-linked app based on MH-AIT transmitted via broadcast waves from the data broadcast screen in the broadcast receiving device 100 of this embodiment.

When the tuner/demodulator unit 131 of the broadcast receiving device 100 performs the process of selecting the user's desired channel and acquires the MMT data string, the application control unit 153 checks the MH-AIT stored in the M2 section message and determines whether there is a broadcast-linked app with an application control code of "AUTOSTART" or "PRESENT" (S1201 to S1206). Note that the processes of S1201 to S1206 may be the same as the processes of S1101 to S1106 shown in FIG. 40B.

After completing the processing of S1201 to S2106, it is assumed that the broadcast receiving device 100 has not yet executed the broadcast-linked app, and that the monitor unit 162 is displaying normal broadcast program video. In this state, when the user issues an instruction to launch the data broadcast screen using a remote control or mobile information terminal capable of operating the broadcast receiving device 100 (S1207), the data decoder 151 (if the data broadcast screen can be displayed) acquires a BML document, etc. from the data carousel of the MMT data string, interprets the acquired BML document, etc., creates a data broadcast screen, and displays it on the monitor unit 162 (S1208). Note that, if there is at least one broadcast-linked app for which the broadcast receiving device 100 satisfies the application profile confirmed in the processing of S1206, an entry button related to the broadcast-linked app is displayed on the data broadcast screen displayed in the processing of S1208. If the broadcast receiving device 100 does not have a single broadcast-linked app that satisfies the application profile confirmed in the processing of S1206, the entry button for the broadcast-linked app may not be displayed, or may be displayed in an inactive state.

Furthermore, when the user operates the remote control or mobile information terminal to select (launch) the entry button of the desired broadcast-linked app displayed on the data broadcasting screen (S1209), the application control unit 153 selects a broadcast-linked app based on the user's instruction (S1210) and acquires the selected broadcast-linked app (S1211 to S1218). Note that the processing of S1211 to S1218 may be the same as the processing of S1010 to S1017 shown in FIG. 40A. Once the acquisition of the selected broadcast-linked app has been completed through the processing of S1211 to S1218, the display of the data broadcasting screen is terminated (S1219), and the application control unit 153 launches the selected broadcast-linked app (S1220).

The above series of processes enables the broadcast receiving device 100 of this embodiment to launch a broadcast-linked app based on the MH-AIT transmitted via broadcast waves from the data broadcast screen. Note that the MH-AIT confirmation process in each of S1205, S1211, and S1213 may involve obtaining and confirming the MH-AIT from the broadcast waves each time, or by caching the MH-AIT obtained in S1201 and confirming the cached MH-AIT. The order of S1204 to S1206 and S1207 may be reversed. Furthermore, S1219 may be performed immediately after S1209. Alternatively, S1219 may not be performed, and the broadcast-linked app, data broadcast screen, broadcast program video, etc. may be simultaneously displayed in each of the divided areas of the display area of the monitor unit 162 based on the description in the LCT. Furthermore, the above operation sequence is merely an example, and different processing procedures may be used.

Note that the broadcast-linked app startup sequences described using Figures 40A to 40C all describe examples in which the MH-AIT is obtained from broadcast waves, but the MH-AIT file may also be obtained from a specific server device (such as the broadcast station server 300) specified by location information (MMT_general_location_info) or the like.

Furthermore, if there is no response from the service provider server 400 or the like for a predetermined period of time when a broadcast-linked app distribution request is made in S1013, S1114, or S1214, a message such as "Please wait a moment" may be displayed on the monitor unit 162. Alternatively, in this case, a message may be displayed inquiring the user about whether to stop execution of the broadcast-linked app.

Furthermore, the launch sequence for the broadcast-linked app is not limited to the three patterns mentioned above, and it may be launched using a different sequence.

[Operation sequence when mobile information terminals are linked]
In the broadcast receiving device 100 of this embodiment, it is assumed that the functionality of a broadcast-communication cooperative service can be expanded by cooperative operation between the broadcast receiving device 100 and the mobile information terminal 700. For example, by installing an application (cooperative control app) provided by a television receiver manufacturer, it is possible to use the mobile information terminal 700 as a high-function remote control for the broadcast receiving device 100. In addition, by executing the broadcast cooperative app on the mobile information terminal 700, it is possible to display, for example, a service linked to a broadcast program being displayed on the broadcast receiving device 100 on the mobile information terminal 700. Note that, in order to expand functionality through cooperative operation between the broadcast receiving device 100 and the mobile information terminal 700, it is desirable that the cooperative control app be running on the mobile information terminal 700, and the broadcast cooperative app running on the mobile information terminal 700 is controlled by the cooperative control app.

Figure 41A is an operational sequence diagram showing an example of the operation when the cooperative control app is launched on the mobile information terminal 700. The diagram shows a series of steps from when the mobile information terminal 700 performs authentication processing with the broadcast receiving device 100 until cooperative operation becomes possible. Note that the cooperative control app is assumed to be pre-installed in the storage unit 710 of the mobile information terminal 700 as a cooperative control program 7002. If the cooperative control program 7002 is not installed, the cooperative control program 7002 must first be installed.

When a user operates the operation unit 730 of the mobile information terminal 700 to instruct the launch of the linkage control app (S1301), the linkage control execution unit 7102 of the mobile information terminal 700 first searches for television receivers on the network that are capable of communication (linkage operation) (S1302) and displays the search results as a list of television receivers on the display unit 741 (S1303). The displayed list of television receivers may include a mixture of television receivers that have a history of linkage operation with the mobile information terminal 700 in the past and those that have not; in this case, it is desirable that the display format be able to determine whether or not there is a history of past linkage operation. Furthermore, if no television receivers capable of communication are found, a message to that effect may be displayed and the process may end.

When the user operates the operation unit 730 of the mobile information terminal 700 to select a specific television receiver (the broadcast receiving device 100 of this embodiment) from the list of television receivers (S1304), if the broadcast receiving device 100 has a history of linking with the mobile information terminal 700 in the past (S1305: Yes), authentication information related to the broadcast receiving device 100 (such as the login name and password specified by the broadcast receiving device 100) is read from the authentication information storage area 7300 of the storage unit 710 (S1306), and the process proceeds to the next step.

On the other hand, if the broadcast receiving device 100 has no history of linking with the mobile information terminal 700 in the past (S1305: No), the linkage control execution unit 7102 sends a login screen information request to the broadcast receiving device 100 (S1307). When login screen information is sent from the broadcast receiving device 100 in response to the processing of S1307 (S1308), the linkage control execution unit 7102 receives the login screen information and displays the login screen on the display unit 741 (S1309). Note that if the linkage control app already has login screen information for the broadcast receiving device 100, the processing of S1307 to S1308 may be omitted. When the user inputs authentication information on the displayed login screen (S1310), the input authentication information is stored in the authentication information storage area 7300 of the storage unit 710, and the process proceeds to the next step.

The determination of whether or not there is a history of the above-mentioned collaborative operation may be made by checking whether or not authentication information related to the broadcast receiving device 100 is stored in the authentication information storage area 7300 of the storage unit 710, or by other methods.

Next, the collaborative control execution unit 7102 transmits the authentication information read in the processing of S1306 or the authentication information input in the processing of S1310 to the broadcast receiving device 100 (S1311). Note that the process of transmitting the authentication information to the broadcast receiving device 100 may be performed via the LAN communication unit 721 and the router device 200r, or may be performed directly to the broadcast receiving device 100 via the NFC communication unit 723.

The broadcast receiving device 100 compares the authentication information transmitted from the mobile information terminal 700 with the authentication information stored in the authentication information storage area 1300 of the storage unit 110 to confirm whether the received authentication information is correct (S1312). If the processing of S1312 confirms that the received authentication information is correct, information capable of identifying the mobile information terminal 700 is stored in the authentication information storage area 1300, and an authentication result (authentication OK) is transmitted to the mobile information terminal 700 (S1313). If the processing of S1312 confirms that the received authentication information is incorrect, information capable of identifying the mobile information terminal 700 is not stored in the authentication information storage area 1300, and an authentication result (authentication NG) is transmitted to the mobile information terminal 700.

When the linkage control execution unit 7102 of the mobile information terminal 700 receives an authentication result (authentication OK) from the broadcast receiving device 100, it displays the basic screen of the linkage control app (e.g., a high-function remote control screen) on the display unit 741 (S1314). On the other hand, when an authentication result (authentication NG) is received, the linkage control execution unit 7102 does not display the basic screen of the linkage control app and terminates operation of the linkage control app. In this case, it is desirable to display an error message or the like informing the user that authentication was NG.

The above series of processes enables cooperative operation between the mobile information terminal 700 and the broadcast receiving device 100.

If you want to launch a broadcast-linked app on the broadcast receiving device 100 following the above-mentioned processing, you can simply perform the processing in Figures 40A to 40C after the above-mentioned processing.

Figure 41B is an operational sequence diagram showing an example of the operation when the cooperative control app is launched on the mobile information terminal 700. This diagram shows the series of steps until cooperative operation becomes possible when the broadcast receiving device 100, which executes the launch sequence of the broadcast cooperative app, requests the launch of the cooperative control app on the mobile information terminal 700.

When the tuner/demodulator unit 131 of the broadcast receiving device 100 performs the process of selecting the user's desired channel and acquires the MMT data string, the application control unit 153 checks the MH-AIT stored in the M2 section message, confirms whether there is a broadcast-linked app with an application control code of "autostart (AUTOSTART)", and checks the profile of the broadcast-linked app with the application control code of "autostart" (S1401). Note that the process of S1401 may be the same as the processes of S1001 to S1009 shown in FIG. 40A.

If, in the profile confirmation process for the highest priority app at S1401, the broadcast receiving device 100 satisfies the application profile of the highest priority app and it is determined that cooperative operation with a mobile terminal device is necessary, the authentication information storage area 1300 of the storage unit 110 is referenced to select a mobile terminal device (mobile information terminal 700 in this embodiment) that has a history of cooperative operation with the broadcast receiving device 100 in the past (S1402). If, in the profile confirmation process for the highest priority app at S1401, it is determined that the broadcast receiving device 100 satisfies the application profile of the highest priority app and cooperative operation with a mobile terminal device is not necessary, the same process as in FIG. 40A may be performed. If, in the profile confirmation process for the highest priority app at S1401, the broadcast receiving device 100 does not satisfy the application profile of the highest priority app, the launch process for the broadcast cooperative app and the launch process for the cooperative control app may be terminated.

When selecting the mobile information terminal 700 by referencing the authentication information storage area 1300, the mobile terminal device with the most recent collaboration history or the most frequently used mobile terminal device may be selected. Information about multiple mobile terminal devices with collaboration history may also be displayed on the monitor unit 162, prompting the user to select a mobile terminal device to collaborate with. If there is no collaboration history, this may be displayed on the monitor unit 162, and the collaboration control app may be launched by operating the mobile information terminal 700. The processing in this case is as shown in FIG. 41A.

The collaborative control execution unit (not shown) of the broadcast receiving device 100 sends a collaborative control app launch request to the mobile information terminal 700 selected in the processing of S1402 (S1403).

The main control unit 701 of the mobile information terminal 700 launches the collaboration control app (collaboration control execution unit 7102) in response to the collaboration control app launch request transmitted from the broadcast receiving device 100 (S1404). The collaboration control execution unit 7102 then executes a series of processes (S1405 to S1408), such as reading authentication information related to the broadcast receiving device 100 from the authentication information storage area 7300 of the storage unit 710, transmitting the authentication information to the broadcast receiving device 100, and authenticating the mobile information terminal on the broadcast receiving device 100. Note that the processes of S1405 to S1408 may be the same as the processes of S1306 and S1311 to S1313 shown in FIG. 41A.

When the linkage control execution unit 7102 of the mobile information terminal 700 receives an authentication result (authentication OK) from the broadcast receiving device 100, it displays the basic screen of the linkage control app (e.g., a high-function remote control screen) on the display unit 741 (S1409) and sends a linkage control app launch success response to the broadcast receiving device 100 (S1410). On the other hand, when the authentication result (authentication NG) is received, it does not display the basic screen of the linkage control app, but sends a linkage control app launch failure response to the broadcast receiving device 100, and terminates operation of the linkage control app.

When the broadcast receiving device 100 receives a launch success response from the mobile information terminal 700, it acquires and launches the broadcast-linked app selected in the processing of S1401 (S1411). Note that the processing of S1411 may be the same as the processing of S1010 to S1018 shown in FIG. 40A. On the other hand, when a launch failure response is received from the mobile information terminal 700, the broadcast receiving device 100 does not have to acquire and launch the broadcast-linked app selected in the processing of S1401. If the broadcast-linked app is capable of operating in a mode that does not require collaboration with a mobile terminal device, it may be configured to launch in that mode of operation.

The above series of processes enables cooperative operation between the mobile information terminal 700 and the broadcast receiving device 100.

Following the above-mentioned processing, if the broadcast-linked app (terminal side) is also launched on the mobile information terminal, the processing in Figure 41C can be performed after the above-mentioned processing.

Figure 41C is an operational sequence diagram showing an example of the operation when a broadcast-linked app (terminal side) is launched on the mobile information terminal 700 based on information transmitted from the broadcast receiving device 100.

That is, after executing the processes of S1401 to S1411 in FIG. 41B (S1501), the application control unit 153 of the broadcast receiving device 100 next checks the MH-transmission protocol descriptor of the MH-AIT associated with the terminal-side broadcast cooperative app (S1502). If the result of the process of S1502 indicates that the terminal-side broadcast cooperative app can be acquired via HTTP/HTTPS transmission based on the protocol identification described in the MH-transmission protocol descriptor (S1503: Yes), the application control unit 153 further checks the MH-simple application location descriptor of the MH-AIT associated with the terminal-side broadcast cooperative app (S1504) and acquires the URL of the entry point of the terminal-side broadcast cooperative app. Once the URL of the entry point of the terminal-side broadcast cooperative app is acquired in the process of S1504, the application control unit 153 transmits the URL information to the mobile information terminal 700 (S1505).

After receiving the URL information from the broadcast receiving device 100, the mobile information terminal 700 then requests the server specified by the URL on the Internet 200 (in this embodiment, the service provider server 400) via the LAN communication unit 721 to distribute the terminal-side broadcast cooperative app (S1506). The service provider server 400, which has received the distribution request, performs appropriate authentication processing for the mobile information terminal 700 and then distributes the requested terminal-side broadcast cooperative app (S1507). Upon receiving the terminal-side broadcast cooperative app from the service provider server 400 via the LAN communication unit 721, the mobile information terminal 700 launches the received terminal-side broadcast cooperative app in the browser engine based on the control of the already-launched cooperative control app (coordination control execution unit 7102) (S1512). The authentication processing for the mobile information terminal 700 performed by the service provider server 400 may be a well-known process, and detailed description thereof will be omitted.

On the other hand, if the result of processing S1502 indicates that the terminal-side broadcast-linked app can be acquired through data carousel transmission using the protocol identification described in the MH-transmission protocol descriptor (S1503: No), the application control unit 153 of the broadcast receiving device 100 checks the DDM table and DAM table stored in the data transmission message (S1508, S1509) and identifies the asset to which the terminal-side broadcast-linked app will be transmitted using the procedure described above in [Overview of Application Transmission Method]. Furthermore, after acquiring the terminal-side broadcast-linked app from the identified asset of the broadcast wave (S1510), the broadcast receiving device 100 transmits the acquired terminal-side broadcast-linked app to the mobile information terminal 700 (S1511). Furthermore, in the mobile information terminal 700, the terminal-side broadcast-linked app transmitted from the broadcast receiving device 100 is executed in a browser engine based on the control of the already-launched link control app (link control execution unit 7102) (S1512).

The terminal-side broadcast-linked app acquired in S1510 may be stored in the content information storage area 1200 of the storage unit 110, and in the processing of S1511, the URL of the content information storage area 1200 may be sent instead of the transmission processing of the terminal-side broadcast-linked app, and the mobile information terminal 700 may be caused to access the content information storage area 1200, thereby causing the mobile information terminal 700 to acquire the terminal-side broadcast-linked app. If the mobile information terminal 700 has a digital broadcast reception function, the mobile information terminal 700 may acquire the terminal-side broadcast-linked app from broadcast waves.

In addition, the processing of S1502 to S1512 may be executed after S1501, triggered by a terminal-side broadcast collaborative app transmission request (not shown) sent from the mobile information terminal 700 to the broadcast receiving device 100.

Furthermore, the operation sequences in Figures 40A to 40C and Figures 41A to 41C can be partially combined as appropriate, and some operation steps can be rearranged or operated simultaneously with other operation steps as appropriate.

[Mobile device linkage control app basic screen]
42A is a screen display diagram showing an example of a basic screen of the collaboration control app displayed by the process of S1314 in Fig. 41A, the process of S1409 in Fig. 41B, etc. In this embodiment, the basic screen 741a of the collaboration control app has the function of a high-function remote control compatible with the broadcast receiving device 100.

The basic screen 741a of the linked control app consists of a power key 741a1, a network selection key (digital terrestrial, BS, CS) 741a2, number keys (1-12) 741a3, volume up/down key 741a4, channel up/down keys 741a5, input switch key 741a6, program guide key 741a7, data key 741a8, linked app key 741a9, menu key 741aa, back key 741ab, cursor keys (up, down, left, right) 741ac, enter key 741ad, and color keys (blue, red, green, yellow) 741ae. Other operation keys may also be displayed.

For ease of use, the operation keys described above may have the same key layout and operation as those on the dedicated remote control included with the broadcast receiving device 100. Furthermore, the power key 741a1, network selection key 741a2, numeric keys 741a3, etc. have the same functions as those on a typical television remote control, and detailed explanations will be omitted. The linked application key 741a9 is an operation key provided for the broadcast/communication linkage function of this embodiment.

In the processing of S1107 in FIG. 40B, it is assumed that a request to launch the broadcast linked app launcher can be made by selecting the linked app key 741a9. Also, in the processing of S1207 in FIG. 40C, it is assumed that a request to launch data broadcasting can be made by selecting the data key 741a8. Also, in the processing of S1109 in FIG. 40B and the processing of S1209 in FIG. 40C, it is assumed that the executable broadcast linked app can be selected by operating the cursor keys 741ac and the enter key 741ad.

In this way, by providing the linked application key 741a9 or another operation key with a similar function on the basic screen 741a of the linked control application, it becomes possible to easily select/launch each broadcast linked application used in the broadcast linked system of this embodiment. Furthermore, the linked application key 741a9 or another operation key with a similar function may be provided on a dedicated remote control attached to the broadcast receiving device 100.

Figure 42B is a screen display diagram showing an example of the basic screen of the collaboration control app displayed by processing S1314 in Figure 41A, processing S1409 in Figure 41B, etc., and is an example different from that shown in Figure 42A.

The basic screen 741b of the collaboration control app is composed of a collaboration control in progress message 741b1 and a collaboration control app operation screen 741b2. Other objects may also be displayed. The collaboration control in progress message 741b1 is a message display to notify the user that the mobile information terminal 700 is operating in collaboration with the broadcast receiving device 100. The collaboration control app operation screen 741b2 is an area where any screen display is performed by the collaboration control app, and detailed explanation will be omitted in this embodiment. For example, the configuration within the collaboration control app operation screen 741b2 may be the same as the basic screen 741a of the collaboration control app described above. A sub-screen of the broadcast program being displayed on the broadcast receiving device 100 may also be displayed.

As shown in FIG. 42B, by displaying the cooperative control in progress message 741b1, the user of the mobile information terminal 700 can easily understand that the mobile information terminal 700 is operating cooperatively with the broadcast receiving device 100. Note that the cooperative control in progress message 741b1 is not limited to a text display, and may be a symbol display, a graphic display, etc. A different background color, etc. may also be used as an alternative to the cooperative control in progress message 741b1.

[Broadcast-linked app launcher screen on broadcast receiving device]
FIG. 43A is a screen display diagram showing an example of a notification screen for notifying the user that there is a broadcast-linked app that can be launched in the broadcast receiving device 100 of this embodiment.

For example, in the operational sequence shown in Figure 40B, after processing of S1106, the broadcast program video continues to be displayed without launching either the data broadcast by the broadcast service or the broadcast-linked app. In this case, however, displaying icon 162m0 as shown in Figure 43A on the broadcast program screen 162m to notify the user that there is a broadcast-linked app that can be launched improves the usability of the broadcast receiving device 100. In other words, displaying icon 162m0 prevents the user from missing the existence of a broadcast-linked app that can be launched.

Note that icon 162m0 may be displayed anywhere on the screen, but it is desirable that it be in a location that does not interfere with viewing of the broadcast program. For example, one of the four corners of the screen. The display position may be controlled by the LCT description. Also, icon 162m0 may be displayed as text as shown in FIG. 43A, or may be a symbol, graphic, etc. Also, icon 162m0 may be displayed all the time, or may be displayed for a predetermined period of time after the power is turned on or the channel is changed. Alternatively, it may be displayed simultaneously with program information, channel number, etc.

Figure 43B is a screen display diagram showing an example of a broadcast linked app launcher displayed by the processing of S1108 in Figure 40B. In this embodiment, it is assumed that three broadcast linked apps, linked app A, linked app B, and linked app C, are executable on the broadcast receiving device 100 based on the MH-AIT description, etc. In this case, the broadcast linked app launcher 162n1 is displayed at any position on the broadcast program screen 162n, and furthermore, an entry button 162n2 for linked app A, an entry button 162n3 for linked app B, an entry button 162n4 for linked app C, and a back button 162n5 are displayed within the broadcast linked app launcher 162n1. The position at which the broadcast linked app launcher 162n1 is displayed may be controlled by the LCT description.

When the broadcast cooperative app launcher 162n1 as shown in FIG. 43B is displayed, if the entry button 162n2, entry button 162n3, entry button 162n4, etc. is selected using the cursor keys 741ac and the enter key 741ad on the basic screen 741a of the cooperative control app, cooperative app A, cooperative app B, cooperative app C, etc. may be launched under the control of the application control unit 153. If the back button 162n5 is selected, the display of the broadcast cooperative app launcher 162n1 may be terminated.

When the broadcast linked app launcher 162n1 is displayed on the broadcast program screen 162n, the frame color, interior color, shape, font, size, blinking status, etc. of each entry button may be changed as appropriate depending on the type and security status of each broadcast linked app. For example, if the linked app A is a broadcast-managed application, the frame color of the entry button 162n2 may be blue; if the linked app B is a non-broadcast-managed application, the frame color of the entry button 162n3 may be yellow; and if the linked app C is a general application, the frame color of the entry button 162n4 may be red. Alternatively, if the linked app A is determined to be trustworthy from a security standpoint, the frame color of the entry button 162n2 may be blue; if the linked app B is determined not to be trustworthy from a security standpoint, the frame color of the entry button 162n3 may be yellow; and if the linked app C is determined to be a security risk, the frame color of the entry button 162n4 may be red.

In addition, the frame color, interior color, shape, font, size, blinking status, etc. of each entry button may be changed as appropriate depending on the function or genre of the broadcast-linked app, or the expiration date of each broadcast-linked app. The frame color, interior color, shape, font, size, blinking status, etc. of each entry button may be changed as appropriate depending on whether the broadcast-linked app has already been obtained from the network, etc. For example, if the linked app A has already been obtained from the network (cached in cache 152, etc.), the frame color of entry button 162n2 may be blue; if the linked app B is being obtained, the frame color of entry button 162n3 may be yellow; and if the linked app C has not yet been obtained, the frame color of entry button 162n4 may be red, etc.

In this way, the user of the broadcast receiving device 100 can easily understand the types of broadcast-linked apps that can be executed on the broadcast receiving device 100, the security status, etc.

Furthermore, if there is no broadcast-linked app that can be executed on the broadcast receiving device 100, the broadcast-linked app launcher 162n1 may not be displayed. Alternatively, in this case, a message such as "There are no available applications" may be displayed inside the broadcast-linked app launcher 162n1.

[Data broadcasting screen on broadcast receiving device]
44 is a screen display diagram showing an example of a data broadcast screen displayed by the processing of S1208 in FIG. 40C. In this embodiment, it is assumed that three broadcast cooperative applications, cooperative application A, cooperative application B, and cooperative application C, are executable on the broadcast receiving device 100 based on the description of the MH-AIT, etc. In this case, an entry button 162o2 for cooperative application A, an entry button 162o3 for cooperative application B, and an entry button 162o4 for cooperative application C are displayed at arbitrary positions on the data broadcast screen 162o. Note that the display positions of the program video 162o1, the entry buttons 162o2 to 162o4, and other content on the data broadcast screen 162o may be controlled by the description of the LCT after grouping them into areas.

On the data broadcasting screen 162o as shown in FIG. 44, when the entry button 162o2, entry button 162o3, entry button 162o4, etc. is selected using the cursor keys 741ac and the enter key 741ad on the basic screen 741a of the linkage control app, the display of the data broadcasting screen 162o will end, and linkage app A, linkage app B, linkage app C, etc. may be launched under the control of the application control unit 153.

When displaying the data broadcasting screen 162o, the frame color, interior color, shape, font, size, blinking status, etc. of each entry button may be changed as appropriate depending on the type and security status of the broadcast-linked app, the functions and genre of the broadcast-linked app, the acquisition status of the broadcast app from the network, etc., just as when displaying the entry buttons of each broadcast-linked app on the broadcast-linked app launcher 162n in Figure 43B.

In this way, the user of the broadcast receiving device 100 can easily understand the types of broadcast-linked apps that can be executed on the broadcast receiving device 100, the security status, etc.

[Broadcast linkage app execution screen of broadcast receiving device]
FIG. 45A is a screen display diagram showing an example of a broadcast-linked app execution screen displayed in the process of S1018 in FIG. 40A , the process of S1119 in FIG. 40B , the process of S1220 in FIG. 40C , etc. The broadcast-linked app of this embodiment is equipped with graphics capabilities and effect capabilities using HTML5 description, and is capable of overlay display with the broadcast program screen on the monitor unit 162. For example, as shown in FIG. 45A , a broadcast-linked app unit 162p1 that displays information such as weather forecasts and news is overlaid and displayed at an arbitrary position on the broadcast program screen 162p. The display position of the broadcast-linked app unit 162p1 may be controlled by the description of the LCT. The broadcast-linked app unit 162p1 is composed of a first main object 162p2, a second main object 162p3, a third main object 162p4, and a background object 162p5, etc. Other objects may also be displayed.

When the broadcast cooperative app section 162p1 is overlaid on the broadcast program screen 162p, it is possible to terminate execution of the broadcast cooperative app and move to the data broadcast screen by selecting the data key 741a8 on the basic screen 741a of the cooperative control app. Furthermore, it is possible to terminate execution of the broadcast cooperative app and return to displaying only the broadcast program screen 162p by selecting the cooperative app key 741a9 on the basic screen 741a of the cooperative control app. The above process may be performed using a different operation key.

In addition, when the broadcast cooperative app section 162p1 is overlaid on the broadcast program screen 162p, the transparency of the broadcast cooperative app section 162p1 can be changed by operating each operation key on the basic screen 741a of the cooperative control app. The transparency change process may be performed collectively on the entire broadcast cooperative app section 162p1, or may be performed individually on the first main object 162p2, the second main object 162p3, the third main object 162p4, and the background object 162p5. It may also be performed for each specified group (for example, multiple objects existing on the same graphics layer).

When performing the transparency change process, for example, an object is selected using the cursor keys 741ac on the basic screen 741a of the collaboration control app, and the transparency of the object is increased with the "blue" key of the color keys 741ae and decreased with the "yellow" key. The transparency change process may also be performed using different operation keys. The broadcast collaboration app unit 162p1 can be temporarily hidden by setting the entire broadcast collaboration app unit 162p1 to 100% transparency. For example, when an emergency broadcast is distributed via broadcast waves, the entire broadcast collaboration app unit can be set to 100% transparency, and only the broadcast program screen of the emergency broadcast can be displayed on the monitor unit 162. Alternatively, a commercial detection unit (not shown) may detect that the broadcast program has switched from main video to commercial video, and control the entire broadcast collaboration app unit 162p1 to 100% transparency (or a transparency that allows the broadcast program video to be clearly seen).

When the display control of the broadcast linked app unit 162p1 is performed using an LCT description, the broadcast linked app unit 162p1 may be temporarily hidden by controlling the "layer_order" parameter of the broadcast linked app unit 162p1 and moving the broadcast linked app unit 162p1 behind the broadcast program screen 162p. In this case, the video display state on the monitor unit 162 will be the same as when the entire broadcast linked app unit 162p1 is set to a transparency of 100%.

By performing the above-mentioned processing, if you want to check the broadcast program screen running in the background while a broadcast-linked app is running, you can do so without closing the broadcast-linked app.

Figure 45B is a screen display diagram showing a different example of the broadcast linked app execution screen displayed in the processing of S1018 in Figure 40A, the processing of S1119 in Figure 40B, the processing of S1220 in Figure 40C, etc., from those described above. In the example shown in Figure 45B, a broadcast linked app section 162p6 introducing recommended programs is overlaid and displayed at any position on the broadcast program screen 162p. The display position of the broadcast linked app section 162p6 may be controlled by the description of the LCT. The broadcast linked app section 162p6 displays first recommended program information 162p7, second recommended program information 162p8, third recommended program information 162p9, etc. More recommended program information may be displayed by scrolling, page switching, etc.

The recommended program information may be information about a program recommended in relation to the currently displayed broadcast program (broadcast program screen 162p), information about a program recommended based on the user's viewing history, or information about a program that is currently trending on the Internet, etc. It may also be information about a recommended program sent to the user by a friend of the user of broadcast receiving device 100. The recommended program may also be a program transmitted via broadcast waves from a digital broadcast service, or a VOD (Video On Demand) program distributed from a server device on the Internet 200. It may also be an information screen such as a homepage prepared on a server device on the Internet 200.

When the broadcast linkage app section 162p6 is overlaid on the broadcast program screen 162p, by using the cursor keys 741ac and the enter key 741ad on the basic screen 741a of the linkage control app to select first recommended program information 162p7, second recommended program information 162p8, third recommended program information 162p9, etc., the video of each recommended program will be displayed on the monitor section 162.

Needless to say, the transparency of the broadcast-linked app section 162p6 may also be changed on the broadcast-linked app execution screen shown in FIG. 45B, as described above.

Figure 45C is a screen display diagram showing an example of a case where program video recommended by the broadcast collaborative application section 162p6 that introduces recommended programs is displayed. For example, when the first recommended program information 162p7 of the broadcast collaborative application section 162p6 is selected using the cursor keys 741ac and the enter key 741ad on the basic screen 741a of the collaborative control application, program video 162pa of the program recommended by the first recommended program information 162p7 is displayed on the monitor section 162. The program video 162pa may be paused or jumped to a specified time by the user operating the operation terminal. Furthermore, when displaying program video 162pa, the original broadcast program screen 162p may be displayed at any position in PIP (Picture In Picture) format, etc. The display position of the original broadcast program screen 162p in PIP format, etc. may be controlled by the LCT description. In this case, the user may be able to change whether the main screen is the program video 162pa of the recommended program or the original broadcast program screen 162p by operating the operation terminal. The size of the window of the original broadcast program screen 162p may also be adjusted by operating the operation terminal.

Furthermore, user convenience can be improved by displaying an icon display 162pb at any position on the screen indicating that the program video 162pa of the recommended program is video displayed as a result of selecting any of the recommended program information displayed in the broadcast-linked application section 162p6.

Figure 45D is a screen display diagram showing a different example of the broadcast linked app execution screen displayed in the processing of S1018 in Figure 40A, the processing of S1119 in Figure 40B, the processing of S1220 in Figure 40C, etc., from those described above. In the example shown in Figure 45D, a broadcast linked app unit 162pc, which serves as a portal for SNS (Social Networking Service) services, is overlaid and displayed at an arbitrary position on the broadcast program screen 162p. The display position of the broadcast linked app unit 162pc may be controlled by the description of the LCT. The broadcast linked app unit 162pc displays an entry button 162pd for a first SNS service, an entry button 162pe for a second SNS service, an entry button 162pf for a third SNS service, etc. Entry buttons for even more SNS services may be displayed by scrolling, page switching, etc.

With the broadcast collaboration app section 162pc overlaid on the broadcast program screen 162p, the cursor keys 741ac and enter key 741ad on the basic screen 741a of the collaboration control app can be used to select the entry button 162pd for the first SNS service, the entry button 162pe for the second SNS service, the entry button 162pf for the third SNS service, etc., to activate the functions assigned to each entry button, such as the chat function, message board function, or internet phone function. This allows you to enjoy the currently displayed broadcast program (broadcast program screen 162p) while exchanging information with others. At the same time, the basic screen 741a of the collaboration control app on the mobile information terminal 700 may be changed to a character input screen such as a software keyboard, or a voice input screen for chatting or posting on message boards using voice input.

In addition to the above-mentioned examples, the broadcast-linked app that can be executed by the broadcast receiving device 100 of this embodiment may also be one that uses the linking function between the broadcast receiving device 100 and the mobile information terminal 700 to present a related commercial app on both the broadcast receiving device 100 and the mobile information terminal 700 in synchronization with the timing of the commercial broadcast. Alternatively, for a paid service available on the broadcast receiving device 100, the broadcast-linked app may check whether the user of the broadcast receiving device 100 has subscribed to the paid service, and change the display of the broadcast receiving device 100 and/or the mobile information terminal 700 depending on the result. When any broadcast-linked app is executed on the broadcast receiving device 100 of this embodiment, it is possible to obtain the effects described using Figures 45A, 45B, etc.

[Broadcast receiving device error display screen]
Fig. 46 is a screen display diagram showing an example of an error display screen when it is determined that execution of the broadcast-linked app is not possible by checking the application profile described in the MH-application descriptor of the acquired MH-AIT, etc., in the process of S1007 in Fig. 40A, the process of S1106 in Fig. 40B, the process of S1206 in Fig. 40C, etc. This may be displayed when there is a shortage in the profile of the broadcast receiving device 100, or when acquisition of the MH-AIT has failed, etc.

In the broadcast receiving device 100 of this embodiment, if it is determined that the broadcast-linked app cannot be executed, the reason why the broadcast-linked app cannot be executed, such as the result of checking the application profile, is displayed in error message 162q1. For example, if the result of checking the application profile indicates that a specified optional function is missing from the television receiver, this is displayed in error message 162q1. An error code and a link (such as a URL) to the television receiver manufacturer's website containing an explanation of the error code may also be displayed.

Alternatively, when a broadcast-linked app is acquired from a network, the network connection status is naturally checked in advance. At this time, if the broadcast-linked app cannot be acquired due to, for example, a faulty LAN cable connection, an error message 162q1 is displayed to that effect. Error message 162q1 may also be displayed when a network connection is established but the broadcast-linked app cannot be acquired correctly due to a poor error situation. Error message 162q1 may also be displayed when the broadcast-linked app is still being acquired but is not yet in a state where it can be executed. Error message 162q1 may also be displayed when the broadcast wave reception status is unstable and, even though information such as MH-AIT was initially able to be received, information such as MH-AIT becomes unable to be received midway through. In such cases, if the broadcast-linked app acquired from each server device is cached as is, it can be used as is after the broadcast wave reception status is restored.

Furthermore, if the result of checking the application profile indicates that a specified optional function is missing from the television receiver, an error message 162q1 may be displayed recommending checking for or updating the latest television receiver firmware. Alternatively, the broadcast receiving device 100 may automatically check for or update the latest firmware. Alternatively, if the broadcast-linked app can be executed by adding paid optional hardware or optional software to the television receiver, information about the paid optional hardware or optional software may be displayed. Note that the error message 162q1 may be displayed on the mobile information terminal 700 rather than on the broadcast receiving device 100.

[Broadcast linkage app execution screen on mobile information terminal]
Fig. 47 is a screen display diagram showing an example of the broadcast cooperative app (terminal side) execution screen displayed in the processing of S1512 of Fig. 41C. The broadcast cooperative app execution screen 741c shown in Fig. 47 is composed of a main window 741c1, a sub-window 741c2, a selection marker 741c3, cursor keys 741c4 and 741c5, a commentary display section 741c6, and an end button 741c7. Other objects may be further added.

In this embodiment, the broadcast linked app (terminal side) executed on the mobile information terminal 700 is an application for checking details of the broadcast program being displayed on the broadcast receiving device 100. The main window 741c1 displays the same image as the broadcast program screen being displayed on the broadcast receiving device 100, while the sub-window 741c2 displays an enlarged image of the position specified by the selection marker 741c3. The position of the selection marker 741c3 can be changed by selecting the cursor keys 741c4 and 741c5. The commentary display area 714c6 displays commentary subtitles about the broadcast program being displayed in the main window 741c1, comments posted by other users about the broadcast program, and the like. The end button 741c7 is a button for terminating the operation of the broadcast linked app (terminal side).

By running the broadcast collaboration app (terminal side) on the mobile information terminal 700, it is possible to expand the functionality of the broadcast communication collaboration service through collaboration between the broadcast receiving device 100 and the mobile information terminal 700.

[EPG screen of broadcast receiving device]
FIG. 48A is a diagram showing an example of detailed information 162a1 of each broadcast program on the EPG screen 162a in the broadcast receiving device 100 of this embodiment, which is different from the example described in the first embodiment.

In addition to the symbols/characters, marks, etc. described in Example 1, the title area 162a2 may also display a mark 162a5 symbolizing "Linkage," which indicates that the broadcast program is available with a broadcast-linked app that can be executed by the broadcast receiving device 100 of this example. In this case, information about the broadcast-linked app (such as the URL from which it can be obtained) may also be displayed in the detailed explanation area 162a3.

The symbol 162a5 of "Linkage" displayed in the title area 162a2 may not be displayed if the application profile check indicates that the broadcast program cannot be executed on the broadcast receiving device 100, even if the broadcast program has a broadcast-linked app available. The symbol 162a5 of "Linkage" displayed in the title area 162a2, which indicates that the broadcast program has an executable broadcast-linked app available, may further change its color, shape, font, etc. depending on whether or not the program can be linked with a mobile terminal device (such as a mobile information terminal 700). If linkage with a mobile terminal device is possible, the symbol 162a7 of "Mobile" may be displayed in addition to the symbol 162a5 of "Linkage" (Figure 48B).

Furthermore, in the case of a program that synchronizes asset presentation with an external device, including a mobile terminal device (such as a mobile information terminal 700), when the program operates in cooperation with the external device, a mark 162a8 symbolizing "Synchronization" may also be displayed (Figure 48C).

The display of the "Linkage" symbol 162a5, the "Mobile" symbol 162a7, and the "Synchronization" symbol 162a8 may be controlled by acquiring information previously stored in the MH-EIT, which contains detailed information about each broadcast program, such as whether a broadcast-linked app executable by the broadcast receiving device 100 of this embodiment is available for each broadcast program, and whether the executable broadcast-linked app is capable of linking with a mobile terminal device. In particular, when asset presentation synchronization with an external device is performed, it is desirable to control the display of the "Synchronization" symbol 162a8 by also referencing information about whether the external device is equipped with an NTP-format clock counter as shown in FIG. 12A or a counter with equivalent functionality. For example, if an external device capable of presentation synchronization cannot be recognized, a display indicating that presentation synchronization is not possible may be displayed, as in the symbol 162a9 of FIG. 48D. Additionally, if presentation synchronization is not possible, the use of the application may be prohibited, and the existence of the application may not be displayed in the electronic program guide.

Alternatively, the information obtained from the program distribution information of digital broadcast programs provided on a specified server device on the Internet 200 may be added to an EPG created based on a program information data sequence obtained from the broadcast waves of a digital broadcast service.

As mentioned above, by displaying on the EPG screen 162a the symbol 162a5 of "Linkage," which indicates that the broadcast program has an executable broadcast-linked app available, the symbol 167a7 of "Mobile," which indicates that linked operation with a mobile terminal device is possible, and the symbol 162a8 of "Synchronization," the user can easily understand the compatibility status of each broadcast program with broadcast-communication linked services on the broadcast receiving device 100. Needless to say, the symbolized symbols representing specific characters that represent the attributes of each broadcast program may be replaced with characters themselves, sentences, etc. The compatibility status of each broadcast program with broadcast-communication linked services may also be indicated by changing the background color of the detailed information 162a1 of each broadcast program. Furthermore, the mark 162a5 symbolizing "Linkage," the mark 162a7 symbolizing "Mobile," and the mark 162a8 symbolizing "Synchronization" may not normally be displayed in the title area 162a2, but may be popped up only when each broadcast program is selected.

The broadcast receiving device 100 of this embodiment has the function of making a viewing reservation and/or a recording reservation for each broadcast program from the EPG screen 162a. For example, while the EPG screen 162a is displayed, the user can use the cursor keys 741ac on the basic screen 741a of the linkage control app to move the program selection cursor on the EPG screen 162a, and select any broadcast program with the enter key 741ad, thereby making a viewing reservation and/or a recording reservation for the selected broadcast program.

In the above-described process, if the broadcast program for which the viewing and/or recording reservation has been made is a broadcast program that supports a broadcast-communication cooperative service, the viewing and/or recording reservation may be used as a trigger to start acquiring a broadcast-cooperative app prepared for the broadcast program, without waiting for the broadcast start time of the broadcast program. That is, information specifying the acquisition source of the broadcast-cooperative app (location information such as a URL) is written in the MH-EIT, which contains detailed information about each broadcast program. In this way, the broadcast receiving device 100 can grasp information such as the acquisition source of the broadcast-cooperative app prepared for each broadcast program at the time the broadcast program is selected with the program selection cursor. This allows the broadcast receiving device 100 to start acquiring the broadcast-cooperative app before the broadcast start time of the broadcast program.

Note that if the broadcast program for which the viewing reservation and/or recording reservation has been made is compatible with a broadcast/communication collaboration service and is capable of collaboration with a mobile terminal device, the broadcast collaboration app (terminal side) prepared for the mobile terminal device may also begin acquiring the information before the broadcast start time of the broadcast program using the same process as described above. Also, as shown in FIG. 48B, a two-dimensional barcode 162a6 or the like indicating information (location information such as a URL) from which the broadcast collaboration app (terminal side) prepared for the mobile terminal device is acquired may be displayed in the detailed description area 162a3 of the EPG screen 162a, prompting the user to download the broadcast collaboration app (terminal side) prepared for the mobile terminal device.

In this way, if the broadcast receiving device 100 references information such as the source where the broadcast-linked app is acquired, contained in the MH-EIT, and starts acquiring the broadcast-linked app before the broadcast program starts, it becomes possible to distribute the load on the service provider server 400 that stores the broadcast-linked app. Furthermore, even if the communication speed of the network between the service provider server 400 and the broadcast receiving device 100 is insufficient, the broadcast-linked app can be effectively used immediately after the broadcast program starts.

Figure 49A is an operational sequence diagram showing an example of the operation of acquiring a broadcast-linked app when a viewing and/or recording reservation for a broadcast program is made from the EPG screen 162a.

When the tuner/demodulator unit 131 of the broadcast receiving device 100 performs the tuning process for the user's desired channel and acquires the MMT data string, the EPG generation unit 1102g of the reception function execution unit 1102 acquires the MH-EIT stored in the M2 section message (S1601). Furthermore, by interpreting the acquired MH-EIT, an EPG screen for the broadcast service of this embodiment is generated (S1602). Note that the processes of S1601 to S1602 may be performed in the background while the broadcast program video of the channel for which the tuning process was performed is displayed on the monitor unit 162.

Here, when the user instructs the display (activation) of the EPG screen using a remote control or mobile information terminal capable of operating the broadcast receiving device 100 (S1603), the generated EPG screen is displayed on the monitor unit 162 using OSD (S1604). The EPG screen displayed in the process of S1604 may be in a format similar to EPG screen 162a shown in FIG. 20A. On EPG screen 162a, the user operates the remote control or mobile information terminal to instruct the selection of a desired broadcast program (S1605), and then instructs the user to schedule a viewing and/or recording of the selected broadcast program (S1606). A program reservation processing unit (not shown) of the reception function execution unit 1102 executes the processing of the viewing and/or recording of the selected broadcast program (S1607). The processing of the viewing and/or recording may be performed using a known broadcast, and detailed description thereof will be omitted.

After processing S1607, the application control unit checks the MH-EIT related to the selected broadcast program (S1608), checks whether a broadcast-linked app related to the selected broadcast program exists, and if a broadcast-linked app related to the selected broadcast program exists, checks the acquisition source (URL) of the broadcast-linked app (S1609). In processing S1609, the application control unit 153 may also check the application profile of the broadcast-linked app. Next, based on the acquired URL, the application control unit 153 requests the server specified by the URL (in this embodiment, the service provider server 400) to distribute the broadcast-linked app via the LAN communication unit 121 (S1610). Upon receiving the distribution request, the service provider server 400 performs authentication processing of the broadcast receiving device 100 as appropriate, and then distributes the requested broadcast-linked app (S1611). When the broadcast-linked app is received from the service provider server 400 via the LAN communication unit 121, the broadcast receiving device 100 caches the received broadcast-linked app in the cache unit 152 under the control of the application control unit 153 (S1612).

The above series of processes enables the broadcast receiving device 100 of this embodiment to acquire a broadcast-linked app when a viewing and/or recording reservation for a broadcast program is made on the EPG screen 162a. The MH-EIT confirmation process in S1608 may involve acquiring and checking the MH-EIT from the broadcast wave each time, or may involve caching the MH-EIT acquired in S1601 and checking the cached MH-EIT. The above operational sequence is merely an example, and different processing procedures may also be used.

Figure 49B is an operational sequence diagram showing an example of an operation in which a mobile terminal device such as a mobile information terminal 700 acquires a broadcast-linked app (terminal side) prepared for the mobile terminal device using a two-dimensional barcode 162a6 displayed in the detailed explanation area 162a3 of the EPG screen 162a.
First, the broadcast receiving device 100 generates and displays an EPG screen by performing the same processes as S1601 to S1604 in FIG. 49A (S1701).

Next, the user operates the operation unit 730 of the mobile information terminal 700 to issue an instruction to launch the collaborative control app, launching the collaborative control app (S1702), and then takes a picture of the two-dimensional barcode 162a6 displayed in the detailed explanation area 162a3 of the EPG screen 162a, as shown in FIG. 48 (S1703).

Next, the acquisition destination (URL) of the broadcast-linked app indicated by the two-dimensional barcode 162a6 is confirmed (S1704), and based on the acquired URL, a broadcast-linked app distribution request is made to the server specified by the URL (in this embodiment, the service provider server 400) via the LAN communication unit 721 or the telephone network communication unit 722 (S1705). Having received the distribution request, the service provider server 400 performs appropriate authentication processing of the mobile information terminal 700, and then distributes the requested broadcast-linked app (S1707).

Next, when the broadcast-linked app is received from the service provider server 400 via the LAN communication unit 721 or the telephone network communication unit 722, the mobile information terminal 700 caches the received broadcast-linked app in the storage unit 710 or the like (S1707).

The broadcast receiving device 100 of this embodiment described above makes it possible to perform functions with higher added value.

Example 4
The following describes a fourth embodiment of the present invention. It should be noted that the configuration and effects of this embodiment are the same as those of the third embodiment unless otherwise specified. Therefore, the following mainly describes the differences between this embodiment and the third embodiment, and explanations of commonalities are omitted as much as possible to avoid duplication. This embodiment also describes a more detailed implementation of a cooperative process between a broadcast receiving device and a mobile information terminal (hereinafter referred to as terminal cooperation).

When performing mobile information terminal linking processing, there are cases where it is desirable to limit the use of terminal linking to only mobile information terminals 700 located in the same home as the broadcast receiving device 100 (hereinafter, this restriction is referred to as the "same-home restriction"). For example, this may occur when the display screen of the broadcast receiving device 100 and the display screen of the mobile information terminal 700 are closely related in an application for using a broadcast linking service (hereinafter, referred to as the "broadcast linking app"), or when it is desirable to ensure that the user of the mobile information terminal 700 can view advertising video displayed on the broadcast receiving device 100.

One thing that must be considered in the procedure is whether the target broadcast-interactive app imposes a same-house restriction. If it is assumed that all broadcast-interactive apps impose a same-house restriction, this determination is not necessary. However, if there are broadcast-interactive apps that do not impose a same-house restriction, the broadcast receiving device 100 must obtain control information regarding the presence or absence of a same-house restriction and change the operating procedure. This control information regarding the presence or absence of a same-house restriction may be obtained from the broadcast signal (for example, by describing it as a parameter or descriptor in the MH-AIT, etc.) or may be obtained from a server designated by the broadcast station.

As an example, if remote viewing is not permitted in the content usage control descriptor (Figure 23) (if remote_view_mode is 0), all broadcast-linked apps related to that broadcast program may be treated as having the same-home restriction, and if remote viewing is permitted (if remote_view_mode is 1), all broadcast-linked apps related to that broadcast program may be treated as not having the same-home restriction.

Alternatively, even if remote viewing is possible, the MH-application descriptor (Figure 50) can have a "local_mode_flag" parameter, and if the value of this parameter is 1, the application can be treated as having a same-house restriction, and if the value of the parameter is 0, the application can be treated as not having a same-house restriction. This allows for control of same-house restrictions on an application-by-application basis, enabling more fine-grained control.

If there is no flag indicating whether remote viewing is permitted, remote viewing may be prohibited, placing importance on copyright protection, or remote viewing may be permitted, prioritizing viewer convenience.

Furthermore, if the "local_mode_flag" is not present, it is possible to prioritize license protection and prohibit the use of the application from outside the home, or to prioritize viewer convenience and allow the use of the application from outside the home.

In addition, the availability of remote viewing or the ability to run an application from outside the home may be displayed in the electronic program guide. For example, if remote viewing is permitted or an application is permitted for use from outside the home, a symbol 162a10 (Fig. 48E) that symbolizes "remote" may be displayed in the column for that program. Furthermore, if remote viewing is not permitted or the application is not permitted for use from outside the home, a symbol such as 162a11 may be displayed (Fig. 48F).

In this embodiment, we will explain the procedure for ensuring that the mobile information terminal 700 is located in the same home as the broadcast receiving device 100, including the above steps.

Normally, devices in the same home are on a local network connected to the same router device 200r. Therefore, if the mobile information terminal 700 is connected to the same local network as the broadcast receiving device 100, it can be determined that they are in the same home. Whether or not the target device is connected to a local network can be confirmed using a known method, and detailed explanation will be omitted.

Furthermore, even if a mobile information terminal 700 is not on the same local network as the broadcast receiving device 100, it can be determined that the mobile information terminal 700 is present in the same home if it communicates directly with the broadcast receiving device 100 via NFC, Bluetooth, infrared communication, etc. In this case, communication for acquiring a broadcast-linked app, etc., may be via the above-mentioned direct communication or via mobile telephone communication.

As mentioned above, there are several possible ways to confirm that devices are in the same home, but the method to be used can be described, for example, in the MH-AIT, and the broadcast receiving device 100 can select the method by reading the description in the MH-AIT, etc.

Also, once it has been confirmed that the mobile information terminal 700 is in the same home, it may be assumed to be in the same home until the program ends. Alternatively, a certain valid time period (for example, 10 minutes) may be set, during which the mobile information terminal 700 is assumed to be in the same home, but after the valid time period has elapsed, it is not assumed to be in the same home unless it is confirmed again. This valid time period may be written, for example, in the MH-AIT, and read by the broadcast receiving device 100.

Furthermore, for example, an event signal can be set in the broadcast signal at any point during the program, and each time this event signal is received, it can be confirmed that the mobile information terminal 700 is present in the same home. Furthermore, it is also possible to use a combination of the above methods as appropriate.

Next, a specific procedure for permitting terminal linkage only for mobile information terminals 700 present in the same home will be described. In this embodiment, restrictions are placed on the mobile information terminal 700 when it acquires a broadcast-linked app or when it acquires information used in the broadcast-linked app. (Note that, hereinafter, the broadcast-linked app and the information used in the broadcast-linked app, specifically HTML documents, streaming video, etc., will be collectively referred to as broadcast-linked information.) There are two methods for acquiring broadcast-linked information: communication acquisition from the broadcast station server 300 or operator server 400, etc., and broadcast acquisition from broadcast waves.

Furthermore, when acquiring via communication, there are two methods: acquiring after broadcast reception has started, and acquiring before broadcast reception has started. Furthermore, when acquiring via communication, the broadcast receiving device 100 may first acquire the data, and the mobile information terminal 700 may then acquire it from the broadcast receiving device 100, or the mobile information terminal 700 may acquire it directly from the broadcast station server 300 or the operator server 400, etc. There are various methods, but from the perspective of the mobile information terminal 700, they can be broadly divided into two: acquiring from the broadcast receiving device 100, and acquiring from the broadcast station server 300 or the operator server 400, etc.

In this embodiment, we will explain the case where the mobile information terminal 700 acquires broadcast linkage information from the broadcast receiving device 100, and the case where it is acquired from the broadcast station server 300, the operator server 400, etc. will be explained in the following examples.

Figure 51A shows the procedure for this example.

First, before performing terminal linkage, a linkage control app, which is an application that controls terminal linkage, is launched on each of the mobile information terminal 700 and the broadcast receiving device 100 (S10001, S10002). In this state, a terminal linkage request is made from the mobile information terminal 700 to the broadcast receiving device 100 (S10003). Next, the MH-AIT stored in the M2 section message of the broadcast signal is obtained (S10004). From the information in this MH-AIT, it is determined whether the app for the target mobile information terminal imposes a same-house restriction (S10006). If it does impose a same-house restriction, the process proceeds to step S10008. At the initial stage when a terminal linkage request is made, the process proceeds to step S10009, where it is determined whether the mobile information terminal 700 that made the terminal linkage request is in the same home as the broadcast receiver 100 (S10009). If the result of the determination is that they are not in the same home, a response refusing to permit collaboration is sent to the collaboration control app on the mobile information terminal, and processing ends (S10011).

Here, if it is assumed that all broadcast-linked apps are subject to the same-household restriction, the determination in S10006 can be skipped. The determination in S10006 should be performed when there is a possibility of both apps that impose the same-household restriction and apps that do not impose the same-household restriction.

If the processing of S10009 determines that the mobile information terminal 700 is located within the same home, or if the processing of S10006 determines that the app does not impose same-home restrictions, the process proceeds to S10012, where a broadcast-linked app-related service is performed. This broadcast-linked app-related service (S10012) processes a broadcast-linked information distribution request (S10013) from the mobile information terminal 700 and distributes broadcast-linked information to the mobile information terminal 700 (S10018). This broadcast-linked information may include information distributed by the broadcast receiving device 100 from a distribution server such as the broadcast station server 300 or the operator server 400 (S10014-S10016), information obtained from a broadcast signal (S10017), information stored (cached) in the broadcast receiving device 100, etc. The broadcast receiving device 100's process of receiving broadcast linked information (S10016 or S10017) does not necessarily have to be performed in response to a broadcast linked information distribution request (S10013) from the mobile information terminal 700; the broadcast receiving device 100 may also acquire the information autonomously, or may acquire the information based on the occurrence of an event in the broadcast signal. Furthermore, the broadcast linked information may also be distributed to the mobile information terminal 700 (S10018) voluntarily by the broadcast receiving device 100.

After the series of processes related to receiving (acquiring) and distributing the broadcast linkage information is completed, the broadcast receiving device 100 determines whether the user is continuing to watch the same program (S10019). If not, it responds to the linkage control app on the mobile information terminal that linkage is not permitted, and the process ends (S10020).

On the other hand, if viewing of the same program continues, the procedure returns to S10005. In the case of an app that imposes a same-house restriction, it is confirmed whether the mobile information terminal 700 is within the same house (S10009). However, it is determined (S10008) whether a preset valid time has elapsed since the last check, or whether a confirmation request (S10007) has been generated from the broadcast signal or distribution server since the last check. If neither of these conditions is met, it does not confirm whether the mobile information terminal 700 is within the same house (S10009), and instead proceeds via S10010 to execute the next broadcast-linked app-related service (S10012). Here, the confirmation request from the broadcast signal (S10007) is described as being obtained from the broadcast-linked information, but here, event messages are also described as being included in the broadcast-linked information. Furthermore, this confirmation request may be described in the MH-AIT.

The procedure described above is a loop processing procedure involving the broadcast signal, broadcast receiving device 100, mobile information terminal 700, and distribution server in the section indicated by the arrow in S10022. The confirmation request in S10007 can be made at any time within the loop.

Furthermore, the authentication information etc. described in the MH-AIT may be incorporated into the authentication key used in the authentication process (S10015) on the distribution server. This makes it possible to confirm that the authentication request is legitimate. Furthermore, by changing the authentication information etc. described in the MH-AIT as the program progresses and not performing authentication unless the distribution server incorporates an authentication key that incorporates information synchronized with the program's progress, it is possible to confirm that the same program is being viewed continuously. In this case, the information in the MH-AIT is read and updated as appropriate (S10021). Note that the authentication information etc. to be incorporated into the broadcast signal may be written in the MH-AIT or may be incorporated as broadcast-linked information. Furthermore, a method of essentially changing the authentication information etc. can be used in which the URL of the distribution server itself is changed as the program progresses.

In this way, while executing the broadcast-linked app-related service (S10012), the mobile information terminal 700 checks whether it is in the same home as the broadcast receiving device 100 every preset valid time, or every time there is a confirmation request from the broadcast signal or distribution server, thereby enabling the execution of broadcast-related apps that appropriately impose same-home restrictions. Furthermore, by using the authentication information embedded in the broadcast signal for authentication by the distribution server, the legitimacy of the distribution request can be ensured, and by changing the authentication information in the broadcast signal as appropriate, it can also be confirmed that the same program is being watched continuously.

The mobile information terminal linkage technology according to the present embodiment described above makes it possible to implement same-house restrictions for mobile information terminals that link with a broadcast receiving device.

Example 5
In this embodiment, a case will be described in which the portable information terminal 700 acquires broadcast cooperation information from a distribution server such as the broadcast station server 300 or the provider server 400.
FIG. 51B shows the procedure of this embodiment.

First, before performing device linkage, a linkage control app, which is an application that controls device linkage, is launched on each of the mobile information terminal 700 and the broadcast receiving device 100 (S10101, S10102). In this state, the mobile information terminal 700 sends a device linkage request to the broadcast receiving device 100 (S10103). Next, the MH-AIT stored in the M2 section message of the broadcast signal is acquired (S10104). Information such as the URL related to the distribution server is acquired from the information in this MH-AIT, and the acquired information is sent to the mobile information terminal 700 (S10105). Next, the broadcast receiving device 100 sends a time confirmation request to the distribution server (S10106). Based on the time confirmation request, the distribution server sends time information to the broadcast receiving device 100 (S10107).

The broadcast receiving device 100 can synchronize the operation of its internal clock with that of the distribution server using the time information obtained from the distribution server. This also makes it possible to issue an authentication key in a subsequent step (S10115) in accordance with the time of the distribution server. Note that if the time difference between the distribution server and the broadcast receiving device 100 is not a problem, steps S10106 to S10107 may be omitted. Also, if the distribution server also operates in synchronization with UTC, steps S10106 to S10107 may be omitted. The time information sent in step S10107 may be in NTP format or another format. From this point on, loop control is entered as indicated by the arrow at S10127.

First, the mobile information terminal 700 transmits an authentication key issuance request or a broadcast linked information distribution request to the broadcast receiving device 100 (S10109). The authentication key is used in a broadcast linked information distribution request to the distribution server in a subsequent step (S10125). The broadcast linked information distribution request is a distribution request for information obtained from the broadcast signal, and triggers the broadcast linked information distribution in a subsequent step (S10126).

In any case, when each request of S10109 is sent from the mobile information terminal 700, the broadcast receiving device 100 determines whether the broadcast-linked app imposes a same-house restriction (S10111). If it is a broadcast-linked app that imposes a same-house restriction, it proceeds to the next step (S10112). If it is not a broadcast-linked app that imposes a same-house restriction, it skips S10112 and proceeds to the subsequent step (S10114). If all broadcast-linked apps impose a same-house restriction, it does not make the determination of S10111 and proceeds to S10112. In S10112, it determines whether the mobile information terminals 700 that issued each request are located within the same home, and if it is determined that the mobile information terminals 700 are not located within the same home, it terminates terminal linkage (S10113). If it is determined that the mobile information terminal 700 is located within the same home, the next step in response to each of the requests is performed, namely, acquiring broadcast linkage information from the distribution server (S10125) or acquiring broadcast linkage information from the broadcast signal (S10126).

In reality, it is sufficient to execute either the process of S10125 or the process of S10126, but to show that the process of acquiring broadcast linkage information can be either acquisition from a distribution server or acquisition from a broadcast signal, both the process of S10125 and the process of S10126 are illustrated simultaneously.
First, the procedure for acquiring broadcast linkage information from the distribution server (S10125) will be described.

First, the broadcast receiver 100 issues an authentication key to the information-linked terminal 700 in response to the processing of S10109 (authentication key issuance request) (S10115). The issued authentication key includes time information at the time of issuance and is valid only for a predetermined validity period (e.g., 10 minutes). The mobile information terminal 700 makes a broadcast-linked information distribution request, including information about the authentication key, to the distribution server (S10116). The distribution server checks the authentication information, including whether the authentication key is within the validity period (S10117), and if authentication is successful, allows distribution of the broadcast-linked information (S10118). Thereafter, distribution of the broadcast-linked information is permitted if it is within the validity period, but distribution of the broadcast-linked information is stopped once the validity period has elapsed. This makes it possible to control streaming video so that it cannot be viewed after the validity period has elapsed, for example.

The validity period may be stored in advance by the distribution server, or may be acquired by the broadcast receiving device 100 from a broadcast signal (e.g., MH-AIT) and incorporated into the authentication key as validity period information. Furthermore, the mobile information terminal 700 may be notified of the validity period information in advance, and the broadcast receiving device 100 may be requested to issue an authentication key before the validity period expires. Alternatively, the validity period may be managed by the broadcast receiving device 100, and after confirming that the mobile information terminal 700 is within the same home, the broadcast receiving device 100 may automatically issue an authentication key to the mobile information terminal 700 before the validity period expires.

Furthermore, the validity period may be the same throughout a single program, or may change as the program progresses. Furthermore, if no validity period is set, authentication may be performed once and remain valid for the duration of the program.

Furthermore, the authentication information written in the MH-AIT may be incorporated into the authentication key used in the authentication process (S10117) on the distribution server. This makes it possible to confirm that the authentication request is legitimate. Also, by changing the authentication information written in the MH-AIT as the program progresses and not performing authentication unless the distribution server uses an authentication key that incorporates information synchronized with the program's progress, it is possible to confirm that the same program is being viewed continuously. In this case, the information in the MH-AIT is read and updated as appropriate (S10124).

Note that authentication information, etc., to be incorporated into the broadcast signal may be written in the MH-AIT, or may be incorporated as broadcast linkage information. Furthermore, a method of essentially changing authentication information, etc., is to change the distribution server URL itself as the program progresses. Note that the URL change in this case may involve using the same distribution server with only a different URL, or may involve changing to a new distribution server due to a change in the broadcast linkage app, etc. In this case, the following procedures are performed each time a change is made: transmission of distribution server information (S10105), time confirmation request (S10106), and transmission of time information (S10107). Next, the procedure for acquiring broadcast linkage information from the broadcast signal (S10126) will be described.

In this case, after it is confirmed that the mobile information terminal 700 is located within the same home, the broadcast receiving device 100 acquires broadcast linkage information from the broadcast signal (S10119), and then distributes the acquired broadcast linkage information to the mobile information terminal 700 (S10120).

When broadcast linkage information is changed as the program progresses, a change notification may be issued from the broadcast signal (S10110), and the change notification may trigger the acquisition of broadcast linkage information. In this case, if the information is acquired from the distribution server, the broadcast receiving device 100 issues an authentication key to the mobile information terminal 700 (S10115) and further notifies the mobile information terminal 700 that a change notification has been received. If the information is within the validity period, the issuance of the authentication key may be omitted and only the change notification may be sent. If the information is acquired from the broadcast signal, the broadcast receiving device 100 acquires the broadcast linkage information (S10119) and distributes it to the mobile information terminal (S10120). If the information is acquired from the broadcast signal, it may be possible to confirm that the mobile information terminal 700 is within the same home for each change notification, or, as in Example 4, this confirmation may be omitted if the information is within the validity period. Here, the change notification from the broadcast signal (S10110) is described as being acquired from the broadcast linkage information, but here, event messages are also described as being included in the broadcast linkage information. Furthermore, this change notification may be included in the MH-AIT.

After the series of processes related to receiving (acquiring) and distributing broadcast linkage information is completed, the broadcast receiving device 100 determines whether the user is continuing to watch the same program (S10121). If the user is not continuing to watch the same program, it responds to the linkage control app on the mobile information terminal that linkage is not permitted, and ends the process (S10123). On the other hand, if the user is continuing to watch the same program, the process returns to S10108 and continues the loop process S10127.

In this way, by including time information in the authentication key used in the authentication process on the distribution server and managing the validity period, it is possible to periodically confirm that the mobile information terminal 700 is in the same home as the broadcast receiving device 100, and to execute a broadcast-linked app that appropriately imposes same-home restrictions. Furthermore, by using the authentication information embedded in the broadcast signal for the authentication process on the distribution server, the legitimacy of the distribution request can be ensured, and by changing the authentication information in the broadcast signal as appropriate, it is also possible to confirm that the same program is being watched continuously.

The mobile information terminal linkage technology according to the present embodiment described above makes it possible to achieve same-home restrictions even when a mobile information terminal linked to a broadcast receiving device acquires broadcast linkage information from a distribution server.

Example 6
In the fourth and fifth embodiments, the procedure for realizing the same-home restriction in terminal linkage has been described, but depending on the broadcast-linked app, use from outside the home may be permitted. In this embodiment, such a case will be described.

For example, when a program such as a television shopping program itself is used for public relations and advertising, it is desirable for the broadcaster if the broadcast-linked app can be used whether inside or outside the home. For such programs, once the program is registered in the broadcast receiving device 100, use of the broadcast-linked app may be permitted regardless of whether the mobile information terminal 700 is inside the home. In this case, convenience is further enhanced if there is a broadcast-linked app that converts the broadcast video itself into streaming data and distributes it from the broadcast receiving device 100 to the mobile information terminal 700 via the Internet. The streaming data may be encrypted by the broadcast receiving device 100 for copyright protection. Whether the broadcast-linked app permits use from outside the home, including distribution of broadcast video outside the home, can be stated in data within the broadcast signal (e.g., MH-AIT).

Figure 51C shows the specific steps of this example. Note that some of these steps are common to Examples 4 and 5, so explanations of parts that overlap with Examples 4 and 5 will be omitted where appropriate.

First, the mobile information terminal 700 launches a linkage control app, which is an application that controls device linkage (S10202). Meanwhile, the linkage control app of the broadcast receiving device 100 may be launched in advance (S10201), or the linkage control app may be launched in response to a terminal linkage request (S10203) from the mobile information terminal 700 (described below).

When a terminal linking request (S10203) is received from a mobile information terminal 700 outside the home, the broadcast receiving device 100 first checks the MH-AIT (S10204) to see if the broadcast linking app allows use outside the home. If the broadcast linking app allows use outside the home, the broadcast receiving device 100 checks whether the requestor is a registered mobile information terminal 700 (S10205) and then allows the link. On the other hand, if the broadcast linking app is not allowed to be used outside the home, the processing ends (S10206).

For broadcast-linked apps that are permitted for use outside the home, authentication processing may then be performed between the mobile information terminal 700 and the broadcast receiving device 100, if necessary, to protect the copyright of the broadcast video and broadcast-linked information (S10207). Furthermore, information such as the URL of the distribution server is obtained from the MH-AIT information, and the obtained information is sent to the mobile information terminal 700 (S10208).

The authentication process may be authentication performed by the distribution server. Information regarding the need for copyright protection and the authentication method for copyright protection may be obtained from the broadcast signal (e.g., written in the MH-AIT, etc.), and control may be performed accordingly. If this information is not stored in the broadcast signal, a predetermined method determined in advance in the broadcast receiving device 100 may be followed. For example, a predetermined copyright protection process may be performed. Alternatively, if this information is not stored in the broadcast signal, it may be determined in advance that the broadcast receiving device 100 will not perform copyright protection processing.

Specific examples of authentication processes for copyright protection are shown below. Each of the following authentication processes may be performed alone. Alternatively, multiple authentication processes exemplified below may be performed in combination. Furthermore, an authentication process exemplified below may be performed in combination with other authentication processes not exemplified below.

[ID and password authentication]
When the portable information terminal 700 is registered with the broadcast receiving device 100, an ID and password are issued, and the broadcast receiving device 100 permits cooperation by verifying this ID and password.

[Encryption key usage]
In addition to the authentication using the ID and password, an encryption key for decrypting encrypted video data, etc. is transmitted from the broadcast receiving device 100 to the mobile information terminal 700. This encryption key may be obtained from a broadcast signal (for example, written in the MH-AIT, etc.).

[Use of distribution server]
In one method in which an encryption key for decrypting encrypted video data or the like is issued from the distribution server, the mobile information terminal 700 transmits an ID and password to the distribution server and obtains the encryption key. In this case, security is further enhanced by obtaining location information (specifically, a URL, etc.) of the distribution server from a broadcast signal (e.g., recorded in the MH-AIT, etc.) and having the broadcast receiving device 100 transmit this location information to the mobile information terminal 700. Since the mobile information terminal 700 cannot decrypt video data or the like unless it obtains the encryption key, the broadcast receiving device 100 may request authentication from the distribution server as a form of copyright protection authentication, or the mobile information terminal 700 may notify the broadcast receiving device 100 that the encryption key has been obtained, thereby completing the authentication. It is also acceptable for the distribution server to charge a fee.

[Mutual authentication of encryption keys]
The broadcast receiving device 100 and the portable information terminal 700 mutually authenticate and confirm the encryption keys they each have, thereby authenticating copyright protection.

Returning to the description of the operation sequence of FIG. 51C.
In the process of S10207, if the information stored in the broadcast signal indicates that copyright protection by a predetermined method is required and the authentication process for copyright protection by the predetermined method cannot be performed, terminal linkage is not permitted. Also, even if the broadcast signal does not specify copyright protection and the authentication process is to be performed by the default method of the broadcast receiving device 100, terminal linkage is not permitted if the authentication process for copyright protection by the default method cannot be performed.

If terminal linkage is permitted in the processing of S10201 to S10207, thereafter, no confirmation is made as to whether the mobile information terminal 700 is present in the same home, and the subsequent processing of S10221 and S10222 is executed in response to a request for authentication key issuance or a request for broadcast linkage information distribution (S10211) from the mobile information terminal 700. Note that the processing of steps S10212 to S10215 in the processing of S10221 may be the same as the processing of steps S10115 to S10118 in Figure 51B. However, control for setting the validity period does not have to be performed. Furthermore, the processing of steps S10216 to S10217 in the processing of S10222 may be the same as the processing of steps S10119 to S10120 in Figure 51B. Note that the processes of S10221 and S10222 may be performed in response to a change notification (S10210) sent from the broadcast signal as the program progresses. Alternatively, the processes of S10221 and S10222 may be performed under the autonomous control of the broadcast receiving device 100.

Furthermore, the processing of steps S10218 to S10220 following the processing of steps S10221 and S10222 may be similar to the processing of steps S10121 to S10124 in Figure 51B.

The mobile information terminal 700 located outside the home can obtain the broadcast linkage information from the broadcast receiving device 100 (S10217). Alternatively, it can obtain the information from the distribution server using an authentication key issued by the broadcast receiving device 100 (S10215). Furthermore, if the authentication key issued by the broadcast receiving device 100 incorporates authentication information obtained from the broadcast signal (for example, as described in the MH-AIT), and the distribution server allows access if the authentication key incorporates the authentication information obtained from the broadcast signal, it is possible to further optimize use outside the home.

Furthermore, there are cases where it is better not to allow unlimited use of the broadcast-linked app, such as when offering a discount as a premium for viewing a program. In such cases, it is preferable to perform authentication once while the mobile information terminal is in the same home, and then allow use of the distribution server even if the mobile information terminal is not in the same home. In this case, it is not necessary for the mobile information terminal 700 to be registered with the broadcast receiving device 100.

The specific procedure for this case is shown in Figure 51D. Some of the procedure is common to Figure 51C above, so explanation of the overlapping parts will be omitted.

First, before performing device linkage, a linkage control app, which is an application that controls device linkage, is launched on each of the mobile information terminal 700 and the broadcast receiving device 100 (S10301, S10302). Next, with the mobile information terminal 700 located in the same home as the broadcast receiving device 100, the mobile information terminal 700 sends a device linkage request to the broadcast receiving device 100 (S10303). After confirming that the mobile information terminal 700 is located in the same home (S10305), the broadcast receiving device 100 permits device linkage. Here, if necessary, authentication processing may be performed between the mobile information terminal 700 and the broadcast receiving device 100 to protect the copyright of the broadcast video and broadcast linkage information (S10307).

The authentication process may be authentication performed by an external distribution server. Information regarding the need for copyright protection and the authentication method for copyright protection may be obtained from the broadcast signal (e.g., written in the MH-AIT, etc.), and control may be performed accordingly. If this information is not stored in the broadcast signal, a predetermined method determined in advance in the broadcast receiving device 100 may be followed. For example, a predetermined copyright protection process may be performed. Alternatively, if this information is not stored in the broadcast signal, it may be determined in advance that the broadcast receiving device 100 will not perform copyright protection processing.

Specific examples of authentication processes for copyright protection are shown below. Each of the following authentication processes may be performed alone. Alternatively, multiple authentication processes exemplified below may be performed in combination. Furthermore, an authentication process exemplified below may be performed in combination with other authentication processes not exemplified below.

[Encryption key usage]
While the portable information terminal 700 is in the same home, an encryption key for decrypting encrypted video data, etc. is transmitted from the broadcast receiving device 100 to the portable information terminal 700. This encryption key may be obtained from a broadcast signal (e.g., written on the MH-AIT, etc.). The delivery of this encryption key within the same home constitutes authentication. Furthermore, if the encryption key can only be obtained from the broadcast signal at a certain point in the program and the delivery of the encryption key to the portable information terminal 700 is limited to within the same home, a restriction can be imposed that the user must be in the same home at that time, which can also be used to provide a premium for viewing.

[Use of distribution server]
In one method in which the distribution server issues an encryption key for decrypting encrypted video data, etc., the mobile information terminal 700 transmits an ID and password to the distribution server and obtains the encryption key. In this case, security is enhanced by obtaining the distribution server's location information (specifically, a URL, etc.) from the broadcast signal (e.g., recorded in the MH-AIT, etc.) and having the broadcast receiving device 100 transmit this location information to the mobile information terminal 700. Since the mobile information terminal 700 cannot decrypt the video data unless it obtains the encryption key, the broadcast receiving device 100 may request authentication from the distribution server as a form of copyright protection authentication, or the mobile information terminal 700 may notify the broadcast receiving device 100 that it has obtained the encryption key, thereby completing the authentication. Access to the distribution server can be performed both inside and outside the home, but by restricting the distribution server's location information to be obtained from the broadcast signal only at a certain point in time during the program and limiting the transfer of location information to the mobile information terminal 700 to within the same home, a restriction can be imposed, requiring the user to be within the same home at that time, which can also be used to provide a premium for viewing. It should be noted that the distribution server may charge a fee.

[Mutual authentication of encryption keys]
The broadcast receiving device 100 and the portable information terminal 700 mutually authenticate and confirm the encryption keys they each have, thereby authenticating copyright protection. This authentication may be performed either inside or outside the home.

Returning to the description of the operational sequence of FIG. 51D.
In the process of S10307, if the information stored in the broadcast signal indicates that copyright protection by a predetermined method is required and the authentication process for copyright protection by the predetermined method cannot be performed, terminal linkage is not permitted. Also, even if the broadcast signal does not specify copyright protection and the authentication process is to be performed by the default method of the broadcast receiving device 100, terminal linkage is not permitted if the authentication process for copyright protection by the default method cannot be performed.

If device linkage is permitted, the subsequent steps are the same as those in Figure 51C, so explanation will be omitted.

The mobile information terminal linkage technology according to the present embodiment described above makes it possible to use a mobile information terminal linked to a broadcast receiving device from outside the home while respecting copyright protection.

Example 7
In actual use, it is more desirable to easily know whether a program has a terminal-linked app, which terminal-linked app is available, etc. In this embodiment, a method for displaying the availability status of a terminal-linked app, etc., will be described. Note that the terminal-linked app refers to a broadcast-linked app used in terminal linkage.

Figure 52A is a screen display diagram showing an example of a broadcast-linked app launcher screen when a terminal-linked app is present. In Figure 52A, a broadcast-linked app launcher 162r11 is displayed at an arbitrary position on the broadcast program screen 162r, and broadcast-linked apps are displayed as icons with framed text. Broadcast-linked apps (162r12-162r14) for the broadcast receiving device 100 and broadcast-linked apps (162r15-162r17) for the mobile information terminal 700 that are linked to the program being viewed are displayed. A back button 162r18 for closing the broadcast-linked app launcher 162r11 is also displayed.

In this example, the status of the app is indicated by the thickness of the frame surrounding the text and the color within the frame. Main app A and B (162r12, 162r13) and terminal app A and B (162r15, 162r16) are available. Main app C (162r14) and terminal app C (162r17) are unavailable. Note that a terminal app being unavailable means that none of the mobile information terminals 700 that are capable of communicating with the broadcast receiving device 100 have the functionality to run the app in question.

Figure 52B shows the screen that appears after selecting terminal app A on the launcher screen in Figure 52A. It shows the status of each mobile information terminal 700 related to terminal app A. The mobile information terminals 700 displayed on this screen are assumed to be terminals that have previously linked with or are registered to the broadcast receiving device 100.

Mobile terminal 1 (162r22) and mobile terminal 2 (162r23) with solid icon borders are in a state where they can communicate with broadcast receiving device 100, while mobile terminal 3 (162r24) and mobile terminal 4 (162r25) with dotted icon borders are not in a state where they can communicate with broadcast receiving device 100. Furthermore, mobile terminal 1 (162r22) and mobile terminal 3 (162r24) with white icon borders have the function of executing terminal app A, while mobile terminal 2 (162r23) and mobile terminal 4 (162r25) with gray icon borders do not have the function of executing terminal app A. Furthermore, if an app is already running on the device, an icon with a design that indicates this may be used.
The following is an example of using pictures in icons to make them more visually understandable.

Figure 52C is an example of a launcher screen (162r31) showing a list of broadcast-linked apps. In addition to the broadcast receiving device 100, icons are shown for each type of mobile information terminal 700. Icons 162r32 and 162r33 are icons representing the broadcast receiving device 100, icons 162r34 and 162r35 are icons representing a smartphone-type mobile information terminal 700, and icon 162r36 is an icon representing a head-mounted display-type mobile information terminal 700. Each app is for the device represented by the icon.

In Figure 52C, if the app cannot be used, a mark indicating that it is unavailable (in this embodiment, a circle with a diagonal line) is displayed superimposed on the image of the device. Furthermore, for the broadcast receiving device 100, if the app is already running, a mark indicating this (in this embodiment, a circle with a dot) may be displayed superimposed. This display prevents unnecessary operations such as proceeding with the launcher procedure even though the app is already running. In the case of the mobile information terminal 700, it is also possible to display a mark indicating that the app is running when the app is running on all devices that are capable of communicating with the broadcast receiving device 100 and that can run the app.

Figure 52D is the screen that appears after terminal app C is selected on the launcher screen of Figure 52C. The state of the mobile information terminal 700 of the type that corresponds to terminal app C is shown. On this screen, if the mobile information terminal 700 does not have the function to execute terminal app C, is not in a state where it can communicate with the broadcast receiving device 100, or is already running terminal app C, a mark indicating this is displayed superimposed on the icon. In this embodiment, if the execution function is not available, a circle with a line through it (162r44, 162r46) is displayed; if it is not in a state where it can communicate, a triangle with an exclamation point (162r45, 162r46) is displayed; and if it is already running, a circle with a dot (162r43) is displayed.

Furthermore, it would be desirable to have a display method that would let users know that a broadcast-linked app is available when the situation changes, without having to launch a launcher each time. For example, when the power is turned on, the channel is changed, the broadcast-linked app is changed at the beginning of a program or even during a program, if there is a change in the communication status between the broadcast receiving device 100 and the mobile information terminal 700, if the execution status of the app changes, etc., an icon could be displayed for a predetermined period of time to show the current status.

Figure 52E shows an example of this case. When an icon indicating the type of device is displayed (162r51 to 162r53), it indicates that a broadcast-linked app is available for that type of device. In this embodiment, a circle with a diagonal line (162r53) indicates that there are no usable devices of that type that can run the app. A circle with a dot (162r51) indicates that the app is running on all or some of the usable devices of that type.

Figure 52F is a screen display diagram showing an example of a broadcast-linked app displayed on the display unit 741 of the mobile information terminal 700. When requesting terminal linkage from the mobile information terminal 700, it is convenient to know in a list which broadcast-linked app is available on which broadcast receiving device 100. Figure 52F shows the list 741d1 displayed on the basic screen 741d of the linkage control app. This list 741d1 shows which broadcast receiving devices 100 in the home are available for the broadcast-linked app corresponding to the program you are looking up. In addition, displaying the status of each broadcast receiving device 100 increases convenience, especially when using the mobile information terminal 700 outside the home. In this embodiment, the status of the broadcast receiving device 100 is displayed, such as receiving the program in question, receiving another program, available, or having another program scheduled (when another program has been scheduled to be recorded partway through the program).

Note that if the broadcast receiving device 100 is equipped with multiple tuners, displaying the status of each of the multiple tuners will increase convenience. In list 741d1, tuners within the same device are distinguished by sub-numbers. For example, receiving device B-1 and receiving device B-2 are one and the other of multiple tuners within the same broadcast receiving device 100. In the case of terminal linkage, if broadcast video and audio can be received as streaming data, there is no need to use the monitor unit 162 of the broadcast receiving device 100. In other words, if the tuners within the broadcast receiving device 100 can be used, broadcasts can be used, so it is convenient to know the usage status of each tuner.

In order to perform the display described in this embodiment, information must be available for each broadcast-linked app indicating whether the app is compatible with the broadcast receiving device 100 or what type of mobile information terminal 700 the app is compatible with. Also, information is required to run the compatible app on the broadcast receiving device 100 or mobile information terminal 700. This information can be obtained by the broadcast receiving device 100 by recording it in, for example, the MH-AIT.

The above describes examples of embodiments of the present invention using Examples 1 to 7, but the configurations that realize the technology of the present invention are not limited to the above examples, and various modifications are possible. For example, it is possible to replace part of the configuration of one example with the configuration of another example, or to add the configuration of one example to the configuration of another example. All of these fall within the scope of the present invention. Furthermore, the numerical values, messages, etc. that appear in the text and figures are merely examples, and the effects of the present invention will not be diminished even if different ones are used.

The functions of the present invention described above may be realized in part or in whole in hardware, for example by designing them as integrated circuits. They may also be realized in software, with a microprocessor unit or the like interpreting and executing an operating program that realizes each function. Hardware and software may also be used together.

The software that controls the broadcast receiving device 100 may be stored in the ROM 103 and/or storage unit 110 of the broadcast receiving device 100 before the product is shipped. It may also be acquired via the LAN communication unit 121 from another application server 500 on the Internet 200 after the product is shipped. Furthermore, the software stored on a memory card, optical disc, etc. may be acquired via the expansion interface unit 124, etc.

Furthermore, the control and information lines shown in the diagram are those considered necessary for explanation, and do not necessarily represent all control and information lines on the product. In reality, it is safe to assume 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...Separator, 141...Video decoder, 142...Video color gamut conversion unit, 143...Audio decoder, 144...Superimposed text 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 unit, 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...audio synthesis unit, 165, 865...speaker unit, 166, 866...audio output unit, 170, 870...operation input unit, 841...MMT decode processing unit, 842...MPEG2-TS decode processing unit, 200...Internet, 200r...router device, 200a...access point, 300t...radio tower, 300s...broadcast satellite (or communication satellite), 300...broadcast station server, 400...service provider server, 500...other application servers, 600...mobile telephone communication server, 600b...base station, 700...mobile information terminal.

Claims (1)

A content protection processing method in a broadcast receiving device that receives broadcast program content, comprising:
a receiving step of receiving the broadcast program content;
a recording reservation step for reserving a recording of a broadcast program from the EPG screen;
a storage step of storing the broadcast program content received in the receiving step for the broadcast program reserved for recording in the recording reservation step;
an output step of outputting the broadcast program content stored in the storage step to an external device for viewing;
a move processing step of moving the broadcast program content stored in the storage step to an external device;
Equipped with
The EPG screen displays the program names and attributes of the broadcast programs,
In the storing step, when the broadcast program content received in the receiving step is content designated as being copy-only-one-generation protected, or when the broadcast program content received in the receiving step is content designated as being copy-able without restriction and protected by encryption, the broadcast program content stored in the storing step is stored in an encrypted state so that it can be played back only by the broadcast receiving device,
The storage of the broadcast program content in the storage step can be performed in a storage unit at the output destination of an IP interface configured with Ethernet-compatible hardware provided in the broadcast receiving device, and the storage of the broadcast program content in the storage unit in the storage step, the output of the broadcast program content for viewing to the external device in the output step, and the move of the broadcast program content to the external device in the move processing step can be performed via the same IP interface configured with Ethernet-compatible hardware,
In the storage step, when the IP address of the external device is not in the same subnet as the IP address of the broadcast receiving device, from a state in which the broadcast program content has been stored in a storage unit at the output destination of the IP interface, the broadcast program content can be output for viewing to the external device in the output step for the external device paired with the broadcast receiving device, but the broadcast program content is prohibited from being moved to the external device in the move processing step,
In the display of the EPG screen, a broadcast program corresponding to data broadcasting is displayed indicating that the program is a broadcast program corresponding to data broadcasting.
Content protection processing method.