Receiving device, client terminal device, and program

Abstract

To enhance inter-connectivity in a system that provides web resources based on broadcast resources from a receiving device to a client terminal device.SOLUTION: In a receiving device, a receiving unit receives a broadcast signal. A transcoding unit transcodes data of resources extracted from the received broadcast signal into data in a format available on a web platform, and outputs the data of the resources, as web resources. A web resource providing unit transmits the web resources output by the transcoding unit to the client terminal device through communication in response to a viewing request from the external client terminal device. A client terminal cooperation control unit controls a cooperation operation with the client terminal device by a hybrid-cast connect function and transmits information necessary for using the web resources to the client terminal device.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a receiving device, a client terminal device, and a program. [Background technology]

[0002] In conventional technology, television receivers utilize various resources (video, audio, subtitles, etc.) contained in broadcast waves. The utilization of resources contained in such broadcasts has basically been limited to television receivers and the like that have a broadcast tuner.

[0003] In response to this, technologies that enable resources contained in broadcast waves to be utilized on web platforms are becoming increasingly widespread. Such technologies enable terminal devices other than television receivers (e.g., web client terminals) to utilize resources contained in broadcasts. For example, television receivers that comply with the ATSC 3.0 standard (ATSC stands for "Advanced Television Systems Committee"), a standard used outside of Japan, can function as distribution servers. In other words, such television receivers can distribute the received broadcast video to other terminal devices.

[0004] On the other hand, in Japanese broadcasting standards (ISDB-T, etc.), remote viewing services are provided by recording devices provided by various electronics manufacturers. Non-Patent Document 1 describes remote viewing.

[0005] One standardized technology is the Hybridcast device linkage function, which is a mechanism for linking television receivers and viewing terminals. This function is called "Hybridcast Connect" or "Hybrid Connect." The technical standard for the Hybridcast device linkage function provides discovery, connection, and data transmission / reception protocols. Non-Patent Document 2 includes the provisions for the Hybridcast device linkage function. [Prior art documents] [Non-patent literature]

[0006] [Non-Patent Document 1] "About Remote Viewing of Digital Broadcasting," Broadcasting Service Advancement Promotion Association, [online], [downloaded April 10, 2021], Internet<URL:https: / / www.apab.or.jp / remote-viewing / pdf / remote-viewing.pdf> [Non-patent document 2] "IPTV Forum Standards and Operational Guidelines," IPTV Forum, General Incorporated Association, IPTVFJ-STD0010 Version 2.3, IPTVFJ-STD0011 Version 2.6, IPTVFJ-STD0013 Version 2.9, [October 2, 2020], Internet<URL:https: / / www.iptvforum.jp / download / input.html> Summary of the Invention [Problem to be solved by the invention]

[0007] However, the conventional techniques have the following problems to be solved.

[0008] In the remote viewing mechanism described in Non-Patent Document 1, the combination of a television receiver and a viewing terminal (and the application program running on that terminal) is fixed for each manufacturer. The reason for this is thought to be that each manufacturer uses its own proprietary technology for discovery and connection protocols between the television receiver and the viewing terminal, and for content protection. In other words, there is a problem that the interoperability between television receivers and viewing terminals does not improve. Due to these circumstances, user convenience does not improve, and the spread of the technology is hindered.

[0009] The mechanism of the hybrid cast terminal linkage function described in Non-Patent Document 2 has a problem in that the viewing terminal cannot acquire broadcast wave resources to play videos or display subtitles.

[0010] In other words, in order to improve the interoperability between television receivers and viewing terminals using standard technology, it is desirable to expand the standard technology for Hybridcast's terminal linkage function so that the various resources contained in broadcast waves can be utilized by viewing terminals.

[0011] Specifically, it is desirable to be able to use video, audio, subtitles, and other data contained in broadcast resources through a standard web interface.It is also desirable to be able to use web resources provided by a television receiving device (receiving terminal device) on a viewing terminal (client terminal device).

[0012] The present invention was made based on the recognition of the above-mentioned problems, and aims to provide a receiving device, a client terminal device, and a program with high interoperability in a system in which a receiving device (television receiver) provides web resources based on broadcast resources to a client terminal device (viewing terminal). [Means for solving the problem]

[0013] [1] In order to solve the above problem, a receiving device according to one aspect of the present invention comprises a receiving unit that receives a broadcast signal, and a client terminal cooperation control unit that controls cooperation with an external client terminal device using a hybridcast terminal cooperation function and transmits to the client terminal device information necessary for using resource data extracted from the broadcast signal as a web resource in a format that can be used on a web platform, and the client terminal cooperation control unit transmits at least location information for using the web resource to the client terminal device.

[0014] [2] Furthermore, one aspect of the present invention is a receiving device further comprising: a transcoding unit that transcodes video and audio resource data extracted from the received broadcast signal into data in a format usable by a web platform and outputs the data as video and audio web resources; and a web resource providing unit that transmits the video and audio web resources output by the transcoding unit to the client terminal device via communication in response to a viewing request from the client terminal device, and the client terminal cooperation control unit transmits location information for using the video and audio web resources transmitted by the web resource providing unit to the client terminal device.

[0015] [3] Another aspect of the present invention is that, in the above-mentioned receiving device, the client terminal cooperation control unit transmits location information for using the web resource to the client terminal device in response to a request from the client terminal device to discover a device that provides the web resource.

[0016] [4] Another aspect of the present invention is that, in the above-mentioned receiving device, the client terminal cooperation control unit transmits information regarding the availability of the web resource to the client terminal device in response to a request from the client terminal device to obtain information regarding the availability of the web resource.

[0017] [5] In addition, according to one aspect of the present invention, in the receiving device, the client terminal cooperation control unit transmits to the client terminal device information on availability of at least one of the types of the web resources, namely, video, audio, subtitles, SI (service information), EPG (electronic program guide), EM (event message), and AIT (application information table).

[0018] [6] Another aspect of the present invention is that in the above-mentioned receiving device, the client terminal cooperation control unit transmits information on a list of web services for the web resources that can be provided to the client terminal device in response to a request from the client terminal device to obtain a list of web services.

[0019] [7] Another aspect of the present invention is that, in the above-mentioned receiving device, the client terminal collaboration control unit transmits information on the web service list obtained from an external web programming information management server device to the client terminal device.

[0020] [8] Also, one aspect of the present invention is that in the above-mentioned receiving device, the client terminal cooperation control unit controls the transcoding unit in response to a request from the client terminal device to start or end processing by the transcoding unit, or to set parameters for processing by the transcoding unit.

[0021] [9] Another aspect of the present invention is that, in the above-mentioned receiving device, the client terminal cooperation control unit transmits information on the launch status of the web service to the client terminal device in response to a request from the client terminal device to obtain information on the launch status of the web service.

[0022]

[10] Also, one aspect of the present invention is that in the above-mentioned receiving device, the client terminal cooperation control unit transmits web service status information indicating whether the transcoding unit is running or not to the client terminal device in response to a request from the client terminal device to obtain the web service status information.

[0023]

[11] Furthermore, a client terminal device according to one aspect of the present invention comprises an application engine that runs a web application that receives and uses the web resource from the receiving device described in [1] above, and a receiving terminal cooperation control unit that executes the processing necessary to use the web resource as a cooperative operation with the receiving device using the Hybridcast terminal cooperation function (Hybridcast Connect function), and the receiving terminal cooperation control unit receives at least location information for using the web resource from the receiving device.

[0024]

[12] Another aspect of the present invention is that in the above-mentioned client terminal device, the receiving terminal cooperation control unit sends a request to the receiving device to discover a device that provides the web resource, and receives location information for using the web resource sent by the receiving device in response to the request to discover a device that provides the web resource.

[0025]

[13] Another aspect of the present invention is that, in the above-mentioned client terminal device, the receiving terminal cooperation control unit sends a request to the receiving device to obtain information on the availability of the web resource, and receives from the receiving device the information on the availability of the web resource that the receiving device sends in response to the request to obtain information on the availability of the web resource.

[0026]

[14] In addition, in one aspect of the present invention, in the above-mentioned client terminal device, the receiving terminal cooperation control unit receives from the receiving device information on availability of at least one of the types of the web resources, namely, video, audio, subtitles, SI (service information), EPG (electronic program guide), EM (event message), and AIT (application information table).

[0027]

[15] Another aspect of the present invention is that in the above-mentioned client terminal device, the receiving terminal cooperation control unit sends a request to the receiving device to obtain a list of web services, and receives from the receiving device information about the list of web services that the receiving device sends in response to the request to obtain the list of web services.

[0028]

[16] Also, in one aspect of the present invention, in the above-mentioned client terminal device, the receiving terminal cooperation control unit receives from the receiving device the information on the web service list that the receiving device has obtained from an external web programming information management server device.

[0029]

[17] Furthermore, one aspect of the present invention is that in the above-mentioned client terminal device, the receiving terminal cooperation control unit transmits to the receiving device a request to start or end processing by the transcoding unit on the receiving device side described in [2] above, or to set parameters for processing by the transcoding unit.

[0030]

[18] Another aspect of the present invention is that, in the above-mentioned client terminal device, the receiving terminal cooperation control unit sends a request to the receiving device to obtain information on the launch status of the web service, and receives from the receiving device the information on the launch status of the web service that is sent by the receiving device in response to the request to obtain information on the launch status of the web service.

[0031]

[19] Furthermore, one aspect of the present invention is that in the above-mentioned client terminal device, the receiving terminal cooperation control unit sends a request to the receiving device to obtain web service status information indicating whether the transcoding unit is running in the receiving device, and receives from the receiving device the web service status information sent by the receiving device in response to the request to obtain the web service status information.

[0032]

[20] Another aspect of the present invention is a program for causing a computer having a receiving unit that receives a broadcast signal to function as a receiving device described in any one of [1] to

[10] above.

[0033]

[21] Another aspect of the present invention is a program for causing a computer to function as the client terminal device described in any one of

[11] to

[19] above. [Effects of the Invention]

[0034] According to the present invention, by using the terminal linking function of hybridcast, a standard technology, it is possible to control the provision of web resources based on broadcast resources received by a receiving device to a client terminal device in a highly interconnected state. [Brief explanation of the drawings]

[0035] [Figure 1] 1 is a block diagram showing a configuration of a system according to an embodiment of the present invention. [Figure 2] FIG. 2 is a functional block diagram showing the functional configuration of a receiving terminal device according to the embodiment. [Figure 3] FIG. 10 is a schematic diagram (part 1) showing an example of a sequence of requests and responses between a receiving terminal device and a client terminal device using the terminal linking function of the extended Hybridcast in the embodiment. [Figure 4] 4 is a schematic diagram (part 2) showing an example of a sequence of requests and responses between a receiving terminal device and a client terminal device, similar to FIG. 3 above. [Figure 5] 10 is a schematic diagram showing an example of a message sent by a receiving terminal device according to the embodiment, the message including endpoint information of a web resource. FIG. [Figure 6] 10 is a flowchart illustrating an example of an operation based on protocol version number information by the client terminal device according to the embodiment. [Figure 7]10 is a schematic diagram showing a web resource availability acquisition request transmitted from a client terminal device to a receiving terminal device according to the embodiment. FIG. [Figure 8] 10 is a schematic diagram showing response data corresponding to the request for obtaining information on whether a web resource is available in the embodiment. FIG. [Figure 9] FIG. 10 is a schematic diagram showing another example (modification) of response data for acquiring availability of a web resource according to the embodiment. [Figure 10] 10 is a schematic diagram showing the structure of response data resulting from extending an available media acquisition API to transfer information on whether a web resource is available in the embodiment. FIG. [Figure 11] 10 is a schematic diagram showing a request for obtaining whether a web resource is available, which is transmitted from a client terminal device to a receiving terminal device according to the embodiment. FIG. [Figure 12] 10 is a schematic diagram showing response data corresponding to the request for obtaining a list of web services in the embodiment. FIG. [Figure 13] 10 is a schematic diagram showing a request for acquiring a list of programming services (extended to acquire a list of web services) sent from a client terminal device to a receiving terminal device according to the embodiment. FIG. [Figure 14] FIG. 2 is a block diagram showing the configuration and procedure of a system for a client terminal device according to the embodiment to acquire organization information of web resources provided by an external server device. [Figure 15] 10 is a schematic diagram showing an example of data (a response extended to include web resources) that the receiving terminal device transmits to the client terminal device as a response to the request for acquiring a list of programming services according to the embodiment. FIG. [Figure 16] 10 is a schematic diagram showing a web service initiation request sent from a client terminal device to a receiving terminal device according to the embodiment. FIG. [Figure 17] 17 is a schematic diagram showing an example in which a description of parameter settings is added to the request for the web service invocation request shown in FIG. 16 in the same embodiment. FIG. [Figure 18] FIG. 10 is a schematic diagram illustrating an example of a response corresponding to the above-described web service activation request in the same embodiment. [Figure 19] 10 is a schematic diagram showing a request for tuning and HC application activation (extended to allow a web service activation request) transmitted from a client terminal device to a receiving terminal device according to the embodiment. FIG. [Figure 20] FIG. 20 is a schematic diagram showing an example of a description of parameters added to the request for channel selection and HC application activation shown in FIG. 19 in the embodiment. [Figure 21] FIG. 10 is a schematic diagram showing an example of response data corresponding to the above-mentioned channel selection / HC application start request (including a web service start request) according to the embodiment. [Figure 22] 10 is a schematic diagram showing a request for acquiring the web service activation availability status transmitted from the client terminal device 3 to the receiving terminal device 2 according to the embodiment. FIG. [Figure 23] 23 is a schematic diagram showing an example of response data corresponding to the request for acquiring the web service activation status shown in FIG. 22 in the same embodiment. FIG. [Figure 24] 10 is a schematic diagram showing an example of response data when the API for acquiring the activation status in the embodiment is extended (extended so that the web activation status can be acquired). FIG. [Figure 25] 10 is a schematic diagram showing a request for obtaining the status of a web service sent from a client terminal device to a receiving terminal device according to the embodiment. FIG. [Figure 26] 26 is a schematic diagram showing an example of response data corresponding to the request for obtaining the status of a web service shown in FIG. 25 according to the same embodiment. FIG. [Figure 27] 10 is a schematic diagram showing an example of response data (extended to include the individual status of each service) returned in response to a request to obtain the status of a web service according to the embodiment. FIG. [Figure 28]10 is a schematic diagram showing an example of extended response data returned in response to a request to acquire the receiver status according to the embodiment. FIG. [Figure 29] 2 is a block diagram showing a schematic internal functional configuration of a client terminal device according to the embodiment. FIG. [Figure 30] FIG. 2 is a block diagram showing an example of the internal configuration of each device constituting the system according to the embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0036] Next, an embodiment of the present invention will be described with reference to the drawings.

[0037] In this embodiment, the receiving terminal device 2 has a function for enabling broadcast wave resources to be utilized on a web platform. In addition, the client terminal device 3 has a function for utilizing web resources provided by the receiving terminal device 2. Each of the receiving terminal device 2 and the client terminal device 3 realizes the above functions by an extended function of Hybridcast Connect (Hybridcast terminal linking function).

[0038] FIG. 1 is a block diagram showing the configuration of a system according to this embodiment. As shown in the figure, the system 1 includes a receiving terminal device 2, a client terminal device 3, an antenna 4, and a router 8. The receiving terminal device 2 is also called a "receiving device." In the system 1, the receiving terminal device 2 and the client terminal device 3 work together using a hybridcast terminal linking function. This allows the client terminal device 3 to present content based on broadcast resources provided by the receiving terminal device 2. Note that while this figure shows one receiving terminal device 2, one client terminal device 3, and one router 8, the system 1 may include any number of each of these devices. For example, the system 1 may be configured by connecting multiple receiving terminal devices 2 or multiple client terminal devices 3 to a single local network. The functions of each device that make up the system 1 will be described below.

[0039] The receiving terminal device 2 receives a broadcast signal (radio frequency, RF) via an antenna 4. The receiving terminal device 2 demodulates and decodes the digital broadcast signal to extract resources such as video, audio, and subtitles contained in the broadcast signal. In other words, the receiving terminal device 2 is a so-called television receiver. The receiving terminal device 2 communicates with the client terminal device 3 via a local area network using the Internet Protocol (IP). In other words, the receiving terminal device 2 can communicate with the client terminal device 3 via a router 8. The receiving terminal device 2 can access the router 8 via wireless or wired communication. An application program (hereinafter sometimes referred to as an "app") can be run on the receiving terminal device 2. The receiving terminal device 2 operates in cooperation with the client terminal device 3 using the terminal cooperation function of Hybridcast. The detailed functional configuration of the receiving terminal device 2 will be described later with reference to another diagram.

[0040] The client terminal device 3 is a terminal device that cooperates with the receiving terminal device 2. Specifically, the client terminal device 3 may be a device such as a PC (personal computer), a tablet device, a smartphone, or a smart speaker. The client terminal device 3 can run an app. An app for operating in cooperation with the receiving terminal device 2 runs on the client terminal device 3. The client terminal device 3 operates in cooperation with the receiving terminal device 2 using the terminal cooperation function of Hybridcast. The client terminal device 3 transmits various requests to the receiving terminal device 2 for viewing web resources. The client terminal device 3 can use the web resources according to the results of the requests. In other words, the client terminal device 3 presents the web resources to the user (viewer). Note that the client terminal device 3 itself does not need to have a tuner function for directly receiving broadcast signals.

[0041] The antenna 4 is for receiving the above-mentioned broadcast signals. The antenna 4 receives the broadcast signals as airwaves and supplies them to the receiving terminal device 2 as electric signals.

[0042] The router 8 is one of the devices that make up the local area network. The router 8 forwards IP packets sent from a source device connected to the local area network to a destination device. In the illustrated configuration, the router 8 forwards IP packets, enabling the receiving terminal device 2 and the client terminal device 3 to communicate with each other.

[0043] 2 is a functional block diagram showing the functional configuration of the receiving terminal device 2. The receiving terminal device 2 has a function for enabling resources such as video, audio, and subtitles contained in broadcast waves (broadcast signals) to be utilized on a web platform. Specifically, as shown in the figure, the receiving terminal device 2 is composed of a tuner unit 201, a descrambler 202, a demultiplexer 203, a data broadcasting processing unit 211, a video decoder unit 212, an audio decoder unit 213, a subtitle decoder unit 214, a data broadcasting engine 221, a communication unit 231, a streaming receiving unit 232, a demultiplexer 233, a video decoder unit 242, an audio decoder unit 243, a subtitle decoder unit 244, an application control unit 251, an application engine 252, an application launcher 253, a transcoding unit 261, a web resource providing unit 262, a client terminal cooperation control unit 263, a video output unit 271, and an audio output unit 272.

[0044] Each functional unit of the receiving terminal device 2 is configured using, for example, electronic circuits. At least some of the functions of the receiving terminal device 2 can be realized by a computer and a program. Each functional unit also has a storage means as needed. The storage means is, for example, a variable in the program or a memory allocated by the execution of the program. Furthermore, non-volatile storage means such as a magnetic hard disk drive or a solid state drive (SSD) may be used as needed. The functions of each unit of the receiving terminal device 2 are as follows:

[0045] Tuner unit 201 receives a broadcast signal, tunes (selects a channel) the received broadcast signal, and passes the selected broadcast signal to descrambler 202. The received broadcast signal is a broadcast signal such as ISDB-T (terrestrial digital broadcasting) or ISDB-S (satellite digital broadcasting). Tuner unit 201 is also called a "receiving unit."

[0046] The descrambler 202 descrambles the received broadcast signal and outputs the descrambled signal. The descrambler 202 passes the descrambled signal to the demultiplexer 203.

[0047] The demultiplexer 203 extracts and outputs individual resource signals from the multiplexed broadcast signal. Specifically, the demultiplexer 203 extracts and outputs the data broadcast signal, video signal, audio signal, subtitle signal, and other signals as needed from the signal output from the descrambler 202.

[0048] The data broadcast processing unit 211 processes the data broadcast signal extracted by the demultiplexer 203. The data broadcast signal is content described in, for example, BML (Broadcast Markup Language).

[0049] The video decoder unit 212 receives the video resources extracted by the demultiplexer 203 and decodes them as video. The video decoder unit 212 passes the video resulting from the decoding to the video output unit 271 and the transcode unit 261.

[0050] The audio decoder unit 213 receives the audio resource extracted by the demultiplexer 203 and decodes it as audio. The audio decoder unit 213 passes the audio resulting from the decoding to the audio output unit 272 and the transcode unit 261.

[0051] The subtitle decoder unit 214 receives and decodes the subtitle resources extracted by the demultiplexer 203. The subtitle decoder unit 214 passes the subtitle data resulting from the decoding to the video output unit 271. Furthermore, the subtitle decoder unit 214 may also pass the subtitle data to the transcode unit 261.

[0052] The data broadcasting engine 221 processes the content output from the data broadcasting processing unit 211. The data broadcasting engine 221 passes the processing result to the video output unit 271 as a video.

[0053] The communication unit 231 communicates with external devices. The communication unit 231 communicates with the outside world using, for example, the Internet Protocol (IP). The function of the communication unit 231 enables the receiving terminal device 2 to communicate with the client terminal device 3 and the like. The communication unit 231 can also communicate with an external (for example, outside the home) server device (such as a web editing information management server device 91) described below.

[0054] The streaming receiving unit 232 receives a signal of content that is distributed via streaming via communication (the Internet, etc.). The streaming receiving unit 232 passes the received signal to the demultiplexer 233.

[0055] The demultiplexer 233 extracts data of each resource from the content signal received by the streaming receiving unit 232. The extracted data includes video, audio, subtitles, etc. The demultiplexer 233 passes the video data to the video decoder unit 242, the audio data to the audio decoder unit 243, and the subtitle data to the subtitle decoder unit 244. The demultiplexer 233 may also extract resources of types other than video, audio, and subtitles.

[0056] The video decoder unit 242 decodes the video data passed from the demultiplexer 233 and outputs the decoded video.

[0057] The audio decoder unit 243 decodes the audio data passed from the demultiplexer 233 and outputs the decoded audio.

[0058] The subtitle decoder unit 244 decodes the subtitle data passed from the demultiplexer 233 and outputs the decoded subtitles (text).

[0059] The application control unit 251 controls application programs running on the receiving terminal device 2. Specifically, the application control unit 251 starts and stops specific application programs and performs other management operations. The application control unit 251 performs control based on Hybridcast technology (regulations).

[0060] The application engine 252 is an environment for running application programs that run on the receiving terminal device 2. The application programs are, for example, content written in HTML5. The content written in HTML5 includes page definitions for presentation on a screen or the like and executable code.

[0061] The application launcher 253 has a function for launching a specific application program on the application engine 252 .

[0062] The transcoding unit 261 receives the decoded video and audio data and converts (transcodes) it into a format (net video distribution format) for distribution via communication. Examples of the converted net video distribution format include MPEG-DASH (DASH is an abbreviation for "Dynamic Adaptive Streaming over HTTP") and HLS (HTTP Live Streaming). In other words, the transcoding unit 261 transcodes resource data extracted from the received broadcast signal into data in a format usable by the web platform and outputs it as a web resource. The data output by the transcoding unit 261 is passed to the web resource providing unit 262 and can be further provided to the client terminal device 3. Note that parameters used when the transcoding unit 261 transcodes content can be controlled and set by the application control unit 251 and the client terminal cooperation control unit 263.

[0063] Web resource providing unit 262 receives content in the form of online video distribution output from transcoding unit 261 and manages distribution to external devices (client terminal device 3, etc.). Web resource providing unit 262 can also store the video content output by transcoding unit 261 for at least a predetermined period of time. Web resource providing unit 262 can provide the video content to client terminal device 3, etc. via communication unit 231. In other words, in response to a viewing request from an external client terminal device 3, web resource providing unit 262 transmits the web resource output by transcoding unit 261 to client terminal device 3 via communication.

[0064] Furthermore, the web resource providing unit 262 generates endpoint information for a web client (such as the client terminal device 3) to use video content. The endpoint information is information that indicates the access destination of the video distribution content as seen from the web client side. The endpoint information generated by the web resource providing unit 262 is information that can be passed to the client terminal device 3 side via the client terminal cooperation control unit 263. This endpoint information allows the client terminal device 3 to know the access destination for obtaining the video content.

[0065] The client terminal cooperation control unit 263 controls cooperation between the receiving terminal device 2 and the client terminal device 3. Specifically, the client terminal cooperation control unit 263 controls cooperation between the receiving terminal device 2 and the client terminal device 3 by using the terminal cooperation function of Hybridcast. The terminal cooperation function of Hybridcast itself is an existing technology, but the client terminal cooperation control unit 263 realizes a function that is an extension of the terminal cooperation function of Hybridcast as a function unique to this embodiment.

[0066] Specifically, the client terminal cooperation control unit 263 controls cooperation with the client terminal device 3 using the terminal cooperation function (including the extended function) of Hybridcast, and transmits information necessary for using the web resource to the client terminal device. The client terminal cooperation control unit 263 transmits at least information on the location (endpoint, etc.) for using the web resource to the client terminal device 3.

[0067] The client terminal cooperation control unit 263 performs the following process in the extended hybridcast terminal cooperation function. That is, the client terminal cooperation control unit 263 provides the client terminal device 3 with the endpoint information described above. The client terminal cooperation control unit 263 also provides the client terminal device 3 with an API (Application Program Interface) for using web resources transcoded from broadcast resources. The client terminal cooperation control unit 263 also acquires information for controlling the transcoding unit 261 passed from the client terminal device 3, and passes this control information (parameters for transcoding processing, etc.) to the transcoding unit 261 via the application control unit 251. That is, the client terminal cooperation control unit 263 controls the transcoding unit 261 based on information from the client terminal device 3. The cooperation between the receiving terminal device 2 and the client terminal device 3 will be described in more detail later.

[0068] The video output unit 271 integrates the videos passed from the video decoder unit 212, the subtitle decoder unit 214, the video decoder unit 242, the subtitle decoder unit 244, the data broadcasting engine 221, etc., and outputs the integrated video. In other words, the video output unit 271 presents the video to the user (viewer). Specifically, the video output unit 271 outputs a video signal to be presented to a display device or the like. Note that in this embodiment, the receiving terminal device 2 may be configured not to have the video output unit 271. Even in this case, the receiving terminal device 2 can provide the video (including information equivalent to subtitles) to the client terminal device 3 as a web resource.

[0069] The audio output unit 272 outputs the audio passed from the audio decoder unit 213 or the audio decoder unit 243 to the outside. Specifically, the audio output unit 272 outputs an audio signal to a speaker, earphones, or the like. Note that in this embodiment, the receiving terminal device 2 may be configured not to have the audio output unit 272. Even in this case, the receiving terminal device 2 can provide the audio to the client terminal device 3 as a web resource.

[0070] With the above-described functional configuration, the receiving terminal device 2 can present (use) resources such as video, audio, and subtitles received as broadcast signals on a web browser (web platform) of the client terminal device 3. In other words, by using the receiving terminal device 2, broadcast resources can be used on the web platform.

[0071] The receiving terminal device 2 may optionally have the following functions: The receiving terminal device 2 functions as a web server for the client terminal device 3, and the web server may be configured to store video data (e.g., mp4) generated by the transcoding unit 261. This may enable, for example, rewinding and viewing (jumping to a specific playback position) based on a request from the client terminal device 3, or video-on-demand (VOD) viewing. The receiving terminal device 2 may also have a video playback player function or HTML content capable of playing video. This allows video playback even when the client terminal device 3 does not have the video playback player function. The receiving terminal device 2 may also be configured to use chunked-transfer-encoding when delivering video. This makes it possible to achieve ultra-low latency delivery in CMAF (Common Media Application Format).

[0072] 3 and 4 are schematic diagrams showing an example of a sequence of requests and responses between the receiving terminal device 2 and the client terminal device 3 using the terminal linking function of the extended Hybridcast in this embodiment.

[0073] Of the processes from steps S101 to S115 and steps S121 to S132 shown in the figure, steps S101 to S115 are performed using APIs (requests, responses, etc.) that also exist in conventional Hybridcast terminal linkage functions. However, at least a portion of the conventional requests or responses may be extended for this embodiment. In other words, not all of the processes from steps S101 to S115 described below belong to the prior art. Furthermore, steps S121 to S132 are performed using APIs (requests and responses) of the extended Hybridcast terminal linkage function that are particularly specific to this embodiment.

[0074] Furthermore, the receiving terminal device 2 and the client terminal device 3 do not necessarily execute all of the procedures from steps S101 to S115 and steps S121 to S132 in sequence. As shown in the figure, all processes except for step S115 are integrated as a pair of request and response. The process of step S115 is two-way communication, and the specific steps therein depend on the process content and data content to be applied.

[0075] Below, FIG. 3 and FIG. 4 will be described in turn.

[0076] 3, the client terminal device 3 transmits a device discovery request to the receiving terminal device 2. In response to the request, the receiving terminal device 2 transmits a device discovery response to the client terminal device 3 in step S102.

[0077] In step S103, the client terminal device 3 transmits an authentication request to the receiving terminal device 2. In response to the request, the receiving terminal device 2 transmits an authentication response to the client terminal device 3 in step S104.

[0078] In step S105, the client terminal device 3 transmits a request for obtaining available media to the receiving terminal device 2. In response to the request, in step S106, the receiving terminal device 2 transmits a response to the client terminal device 3 for obtaining available media.

[0079] In step S107, the client terminal device 3 transmits a request for acquiring a list of organized services to the receiving terminal device 2. In response to the request, in step S108, the receiving terminal device 2 transmits a response to the client terminal device 3 for acquiring a list of organized services.

[0080] In step S109, the client terminal device 3 transmits a request for channel selection and HC application startup to the receiving terminal device 2. In response to the request, in step S110, the receiving terminal device 2 transmits a response to the channel selection and HC application startup request to the client terminal device 3. Note that "HC" is an abbreviation for hybrid cast.

[0081] In step S111, the client terminal device 3 transmits a request for acquiring the activation status to the receiving terminal device 2. In response to the request, in step S112, the receiving terminal device 2 transmits a response to the client terminal device 3 for acquiring the activation status.

[0082] In step S113, the client terminal device 3 transmits a request to acquire the receiver status to the receiving terminal device 2. In response to the request, in step S114, the receiving terminal device 2 transmits a response to acquire the receiver status to the client terminal device 3. Note that the term "receiver" here refers to the receiving terminal device 2.

[0083] In step S115, the client terminal device 3 and the receiving terminal device 2 communicate bidirectionally. This enables the client terminal device 3 and the receiving terminal device 2 to operate in cooperation with each other. In other words, the client terminal device 3 and the receiving terminal device 2 perform terminal cooperation communication.

[0084] 4, in step S121, the client terminal device 3 transmits a web resource device discovery request to the receiving terminal device 2. In response to the request, in step S122, the receiving terminal device 2 transmits a web resource device discovery response to the client terminal device 3. This "web resource device discovery" request and response are procedures that do not exist in conventional hybridcast terminal linkage function technology.

[0085] In step S123, the client terminal device 3 transmits a request to acquire whether the web resource is available to the receiving terminal device 2. In response to the request, in step S124, the receiving terminal device 2 transmits a response to acquire whether the web resource is available to the client terminal device 3. This request and response to acquire whether the web resource is available is a procedure that does not exist in conventional hybridcast terminal linkage function technology.

[0086] In step S125, the client terminal device 3 transmits a request to acquire a list of web services to the receiving terminal device 2. In response to the request, in step S126, the receiving terminal device 2 transmits a response to acquire a list of web services to the client terminal device 3. This request and response to acquire a list of web services is a procedure that does not exist in conventional hybridcast terminal linkage function technology.

[0087] In step S127, the client terminal device 3 transmits a web service activation request to the receiving terminal device 2. In response to the request, in step S128, the receiving terminal device 2 transmits a web service activation request response to the client terminal device 3. This "web service activation request" request and response is a procedure that does not exist in conventional hybridcast terminal linkage function technology.

[0088] In step S129, the client terminal device 3 transmits a request to acquire the web service activation status to the receiving terminal device 2. In response to the request, in step S130, the receiving terminal device 2 transmits a response to acquire the web service activation status to the client terminal device 3. This request and response to "acquire the web service activation status" is a procedure that does not exist in conventional hybridcast terminal linkage function technology.

[0089] In step S131, the client terminal device 3 transmits a request to acquire the web service status to the receiving terminal device 2. In response to the request, in step S132, the receiving terminal device 2 transmits a response to acquire the web service status to the client terminal device 3. This request and response to acquire the web service status is a procedure that does not exist in conventional hybridcast terminal linkage function technology.

[0090] Next, a more detailed description will be given of the interactions between the receiving terminal device 2 and the client terminal device 3 in the system 1. These interactions are processes performed using the terminal linking function of Hybridcast, which has been extended in this embodiment.

[0091] Steps (1) to (3) described below are procedures for discovering a web resource device. Both an example of providing a new API for discovering a web resource device and other examples (such as extensions of conventional procedures) will be described. By processing web resource device discovery using one of the procedures described below, client terminal cooperation control unit 263 of receiving terminal device 2 transmits location information for using the web resource to client terminal device 3 in response to a request from client terminal device 3 to discover a device that provides the web resource. In other words, receiving terminal cooperation control unit 363 of client terminal device 3 transmits a request to discover a device that provides the web resource to receiving terminal device 2, and receives location information for using the web resource transmitted by receiving terminal device 2 in response to the request to discover a device that provides the web resource.

[0092] Furthermore, steps (4) to (7) are procedures for obtaining information on whether a web resource is available. Both an example in which a new API is provided for obtaining information on whether a web resource is available and other examples will be described. By processing to obtain information on whether a web resource is available using one of the procedures described below, client terminal cooperation control unit 263 of receiving terminal device 2 transmits information on whether the web resource is available to client terminal device 3 in response to a request from client terminal device 3 to obtain information on whether the web resource is available. The client terminal cooperation control section 263 may be configured to transmit to the client terminal device 3, in particular, information on the availability of web resources for each type of at least video, audio, subtitles, SI (service information), EPG (electronic program guide), EM (event message), and AIT (application information table). In other words, the receiving terminal cooperation control section 363 of the client terminal device 3 transmits to the receiving terminal device 2 a request to acquire information on the availability of web resources, and receives from the receiving terminal device 2 information on the availability of web resources that is transmitted by the receiving terminal device 2 in response to the request to acquire information on the availability of web resources. The receiving terminal cooperation control section 363 may be configured to receive from the receiving terminal device 2, in particular, information on the availability of web resources for each type of at least video, audio, subtitles, SI (service information), EPG (electronic program guide), EM (event message), and AIT (application information table).

[0093] Furthermore, steps (8) to (10) are procedures for acquiring a web service list. Both an example in which a new API for acquiring a web service list is provided and other examples will be described. By performing a process for acquiring web resource availability using one of the procedures described below, the client terminal cooperation control unit 263 of the receiving terminal device 2 transmits information about a web service list of available web resources to the client terminal device 3 in response to a request from the client terminal device 3 for acquiring the web service list. The client terminal cooperation control unit 263 may transmit information about the web service list acquired from an external web editing information management server device 91 (described below) to the client terminal device 3. In other words, the receiving terminal cooperation control unit 363 of the client terminal device 3 transmits a request to the receiving terminal device 2 for acquiring a web service list, and receives from the receiving terminal device 2 the information about the web service list transmitted by the receiving terminal device 2 in response to the request for acquiring the web service list. The receiving terminal cooperation control section 363 may be configured to receive, from the receiving terminal device 2, the information on the list of web services that the receiving terminal device 2 has acquired from the external web editing information management server device 91.

[0094] Furthermore, steps (11) to (13) are procedures for requesting the initiation of a web service. Both an example in which a new API for requesting the initiation of a web service and other examples will be described. By performing a process for obtaining web resource availability using one of the procedures described below, the client terminal cooperation control unit 263 of the receiving terminal device 2 controls the transcoding unit 261 in response to a request from the client terminal device 3 to start or end processing by the transcoding unit 261 or to set parameters for processing by the transcoding unit 261. In other words, the receiving terminal cooperation control unit 363 of the client terminal device 3 transmits a request to the receiving terminal device 2 to start or end processing by the transcoding unit on the receiving terminal device 2 side or to set parameters for processing by the transcoding unit.

[0095] Furthermore, steps (14) to (16) are procedures for acquiring the web service activation status. Both an example in which a new API is provided for web resource device discovery and other examples will be described. By processing for acquiring web resource availability using one of the procedures described below, client terminal cooperation control unit 263 of receiving terminal device 2 transmits information on the web service activation status to client terminal device 3 in response to a request from client terminal device 3 for acquiring information on the web service activation status. In other words, receiving terminal cooperation control unit 363 of client terminal device 3 transmits a request to receiving terminal device 2 for acquiring information on the web service activation status, and receives from receiving terminal device 2 the information on the web service activation status that receiving terminal device 2 transmits in response to the request for acquiring information on the web service activation status.

[0096] Also, steps (17) to (19) are procedures for acquiring the web service status. Both an example in which a new API for acquiring the web service status is provided and other examples will be described. By processing for acquiring web resource availability using one of the procedures described later, the client terminal cooperation control unit 263 of the receiving terminal device 2 transmits web service status information to the client terminal device 3 in response to a request from the client terminal device 3 for acquiring web service status information indicating whether the transcoding unit 261 is running. In other words, the receiving terminal cooperation control unit 363 of the client terminal device 3 transmits a request to the receiving terminal device 2 for acquiring web service status information indicating whether the transcoding unit 261 is running in the receiving terminal device 2, and receives from the receiving terminal device 2 the web service status information transmitted by the receiving terminal device 2 in response to the request for acquiring the web service status information.

[0097] Also, (20) explains the exchange (control, etc.) of various data using API for terminal link communication (link communication between the receiving terminal device 2 and the client terminal device 3).

[0098] The details of these processes (1) to (20) will be explained below in order.

[0099] (1) Web Resource Device Discovery (Steps S121 and S122 in Figure 4) - Part 1 The client terminal cooperation control unit 263 of the receiving terminal device 2 provides API endpoint information in response to a device discovery message (DIAL protocol: a protocol using the UPnP standard) from the client terminal device 3. DIAL is an abbreviation for "Discovery-and-Launch." UPnP is an abbreviation for "Universal Plug and Play." The client terminal cooperation control unit 263 provides the above endpoint information as data in XML format or the like.

[0100] In this embodiment, the client terminal device 3 uses web resources provided by the receiving terminal device 2. An example of a message description for such an extension is as follows: That is, the protocol version number can be used to distinguish whether a device is compatible with web resources or not.

[0101] 5 is a schematic diagram showing an example of a message description including endpoint information of a web resource. This message is an example of a message that the client terminal cooperation control unit 263 of the receiving terminal device 2 sends to the client terminal device 3. In other words, it is an example of a response that the client terminal cooperation control unit 263 sends to the client terminal device 3 in step S122 in response to the web resource device discovery request from the client terminal device 3 in step S121 of FIG. 4. Note that in this diagram, line numbers are used to refer to the data.

[0102] The message shown in FIG. 5 is written in XML format. The block from line 8 to line 10 of this message describes the version number of the Hybridcast protocol. In this example, the version number is "3.0." For example, this version number can be used to distinguish between a message about the Hybridcast terminal linkage function according to conventional technology and a message about the Hybridcast terminal linkage function extended in this embodiment. For example, if the version number is "3.0" or higher, the extended Hybridcast terminal linkage function can be used (i.e., web resources according to this embodiment can be utilized). Conversely, if the version number is lower than "3.0" (e.g., "2.3"), the Hybridcast terminal linkage function is based on the conventional technology before the extension. Note that the value "3.0" above is merely an example.

[0103] The block from line 17 to line 19 of the message shown in FIG. 5 describes the endpoint information for the receiving terminal device 2 to provide the web resource. Specifically, the "<iptv:X_Hybridcast_WebresourceURL> " and " on line 19< / iptv:X_Hybridcast_WebresourceURL> " is a tag for describing the above endpoint information. Also, the description "http: / / 192.168.1.11:1236 / hybridcast / webresource" on the 18th line is an example of a URL (endpoint information) that indicates the endpoint.

[0104] 6 is a flowchart showing an example of the operation based on the information on the version number of the above protocol. Below, the process of branching the operation based on the version number will be described with reference to this flowchart.

[0105] In step S201, the client terminal device 3 uses UPnP to transmit a web resource device discovery request to the receiving terminal device 2 (corresponding to step S121 in FIG. 4).

[0106] Next, in step S202, the client terminal device 3 acquires a response corresponding to the above request from the receiving terminal device 2. This response is written in XML, as shown in FIG.

[0107] Next, in step S203, the client terminal device 3 makes a determination based on the version number of the protocol. Specifically, the client terminal device 3 determines whether the version number corresponds to the web resource function.

[0108] If the protocol version number described in the received response indicates that it is compatible with the web resource function (for example, version 3.0 or higher) (step S203: compatible with web resource), the process proceeds to step S204. In other words, the client terminal device 3 can perform processing assuming that it will use web resources.

[0109] If the version number indicates that the web resource function is not supported (for example, lower than version 3.0) (step S203: web resource not supported), the client terminal device operates using the conventional hybridcast terminal linkage function. In other words, the client terminal device 3 performs processing assuming that web resources are not used.

[0110] If the process proceeds to step S204, in that step the client terminal device 3 acquires the endpoint information of the web resource from the response message received in step S202. That is, the client terminal device 3 acquires the information exemplified in lines 17 to 19 of Fig. 5. Based on this endpoint information, the client terminal device 3 becomes able to access the web resource provided by the receiving terminal device 2.

[0111] Next, in step S205, client terminal device 3 performs processing for viewing the web content. That is, client terminal device 3 receives data of web resources (video, audio, etc.) from receiving terminal device 2 and presents the content of that data to the user (viewer). After this, client terminal device 3 can continue to perform processing that assumes the use of web resources.

[0112] (2) Web Resource Device Discovery (Steps S121 and S122 in Figure 4) - Part 2 (Extending Conventional Endpoint Information) Next, we will explain an alternative method for discovering web resource devices. In the conventional (non-extended) Hybridcast device linking function, in response to a device discovery request, the endpoint information of the device linking API is "<iptv:X_Hybridcast_TVcontrolURL> " tag (see the block from line 14 to line 16 in the example in Figure 5).<iptv:X_Hybridcast_TVcontrolURL> " tag may be used to convey the endpoint information of the web resource as a descriptor from the receiving terminal device 2 to the client terminal device 3.

[0113] Furthermore, the receiving terminal device 2 may provide the endpoint information of the web resource using yet another method. For example, the endpoint information of the web resource may be provided in response to a request for available media acquisition from the client terminal device 3 (step S105 in FIG. 3). In the response to this available media acquisition, in the prior art, " <base URL> Instead, the receiving terminal device 2 may provide information on the endpoint of the web resource as the API endpoint of the hybridcast terminal linkage function. For example, the receiving terminal device 2 may provide " <base URL> You can provide information about / webresource. <base URL>" should be replaced by the base URL string for providing the service.

[0114] (3) Web resource device discovery (steps S121 and S122 in Figure 4) - Part 3 (only changes to the content of the conventional endpoint information) A further alternative method for discovering web resource devices will be described. This method changes only the content of the endpoint information in the existing hybridcast terminal linkage function technology. In other words, the receiving terminal device 2 sends a message describing the endpoint information of the web resource as a response to the client terminal device 3, instead of the existing endpoint information. When using this method, unlike the conventional technology, no additional endpoint information is added, but it is possible to communicate the endpoint information of the web resource to the client terminal device 3. This allows the client terminal device 3 to access and use the web resources provided by the receiving terminal device 2.

[0115] (4) Obtaining Web Resource Availability (Steps S123 and S124 in Figure 4) - Part 1 Next, an API for the client terminal device 3 to obtain information on whether a web resource is available will be described. Whether a web resource is available is information indicating whether a web resource exists that can be used by the client terminal device 3. The method described here introduces a new API for the client terminal device 3 to obtain information on whether a web resource is available. The client terminal device 3 requests information on whether the web resource is available (step S123 in FIG. 4). In response to this request, the receiving terminal device 2 returns a response to the client terminal device 3 (step S124 in FIG. 4).

[0116] FIG. 7 is a schematic diagram showing an API (request) for obtaining availability of a web resource, which is sent from the client terminal device 3 to the receiving terminal device 2. As shown in the figure, the URL of this API is <baseurl> / webmedia". <baseurl>" has already been explained. The method for calling this API is "get".

[0117] FIG. 8 is a schematic diagram showing response data corresponding to the request for obtaining web resource availability information. This response data is sent from the receiving terminal device 2 to the client terminal device 3. As shown in the figure, the response data can be written as JSON format data, for example. JSON stands for "JavaScript Object Notation." As shown in the figure, the response to the web resource availability information API includes a header section (block indicated by "head") and a body section (block indicated by "body"). The code "200" and message "OK" included in the header section indicate that the request was successful. The created date and time (created_at) included in the body section is information indicating the year, month, day, hour, minute, and second (Coordinated Universal Time). Furthermore, if the web (web) included in the body section is string data "Available," this indicates that the web resource is available. If the web resource is unavailable, string data "NotAvailable" is returned as the response instead of "Available."

[0118] (5) Obtaining Web Resource Availability - Part 2 (Steps S123 and S124 in Figure 4) Next, an alternative method for obtaining information on whether a web resource is available for use will be described. In the response data shown in FIG. 8 above, information indicating whether the web resource as a whole is available for use is returned from the receiving terminal device 2 to the client terminal device 3. In this method, information on whether each type of service that can be used as a web resource is available for use is returned from the receiving terminal device 2 to the client terminal device 3. In this method, the request data for the web resource availability acquisition API is the same as that shown in FIG. 7 above. On the other hand, the response data for the web resource availability acquisition API is as follows:

[0119] FIG. 9 is a schematic diagram showing response data of a web resource availability acquisition API in this technique. This response data is sent from the receiving terminal device 2 to the client terminal device 3. The response data is written as data in JSON format, for example. This response data includes a header section and a body section. The header section data illustrated here is the same as that described in FIG. 8. The creation date and time (created_at) included in the body section is the same as that described in FIG. 8. The "VIDEO," "AUDIO," "SUBTITLE," "EVENT" (event message), "BML" (data broadcasting content written in BML), "AIT" (hybridcast), and "SI" (service information) included in the body section each represent data indicating the availability of each type of web resource. SI is data related to program scheduling. "Available" indicates that the type is available. "NotAvailable" indicates that the type is unavailable.

[0120] For example, if the client terminal device 3 is a smart speaker, the client terminal device 3 can output audio content but cannot output video content. In other words, some web resources are available and some are unavailable depending on the type of client terminal device 3. In such cases, the client terminal device 3 can determine whether to use each type of web resource based on the information on availability of each type of web resource.

[0121] (6) Obtaining Web Resource Availability - Part 3 Hereinafter, a further alternative method for obtaining information on whether a web resource is available will be described. In this method, the API for obtaining available media in the existing Hybridcast terminal linkage function (steps S105 and S106 in FIG. 3) is extended so that the client terminal device 3 obtains information on whether a web resource is available.

[0122] FIG. 10 is a schematic diagram showing the structure of response data resulting from extending the available media acquisition API using this technique. This response data is sent by the receiving terminal device 2 to the client terminal device 3. The response data is written, for example, as JSON format data. This response data includes a header section and a body section. The data in the header section shown here is as already explained. The creation date and time (created_at) included in the body section is also as already explained. The "TD" (terrestrial digital), "BS" (satellite digital broadcasting), and "CS" (CS digital broadcasting) included in the body section are data in the interface of the terminal linkage function of hybridcast according to conventional technology. In other words, each of these items is data indicating the availability ("Available" or "NotAvailable") of terrestrial digital broadcasting, satellite digital broadcasting, and CS digital broadcasting.

[0123] The "WEB" included in the body of the data shown in Figure 10 is data specific to the extended Hybridcast terminal linkage function in this embodiment, and indicates whether the web resource is available. In other words, if the value of this "WEB" is "Available," it indicates that the web resource is available. On the other hand, if the value of this "WEB" is "NotAvailable," it indicates that the web resource is not available. By acquiring such response data, the client terminal device 3 can determine whether the receiving terminal device 2 is providing the web resource.

[0124] When this method is used, the client terminal device 3 can determine whether or not the web resource is available on the receiving terminal device 2, even if the device discovery response data does not include protocol version information, as shown in Figure 5. Therefore, the device discovery response data does not need to include protocol version information. However, by including the protocol version in the device discovery response data, the client terminal device 3 can determine whether or not the web resource on the receiving terminal device 2 is available, without going through the authentication flow. The authentication flow here refers to the processing procedures shown in steps S103 and S104 of Figure 3.

[0125] (7) Obtaining Web Resource Availability - Part 4 In this technique, the receiving terminal device 2 does not have an API for obtaining information on whether a web resource is available. Instead, the client terminal device 3 determines whether a web resource is available based on the response (data in FIG. 5) obtained in the web resource device discovery process described above (steps S121 and S122 in FIG. 4). That is, if the data obtained as a response to the web resource device discovery indicates that the receiving terminal device 2 supports the web resource (the determination result in step S203 in FIG. 6 is "web resource compatible"), the client terminal device 3 determines that the web resource is available. Conversely, if the data obtained as a response to the web resource discovery indicates that the receiving terminal device 2 does not support the web resource (the determination result in step S203 in FIG. 6 is "web resource incompatible"), the client terminal device 3 determines that the web resource is unavailable. In other words, in this technique, the response data (FIG. 5) obtained from the receiving terminal device 2 is interpreted as including information on whether the web resource is available. In this method, the client terminal device 3 can determine whether or not a web resource is available without performing the process of calling an API for obtaining whether or not the web resource is available (steps S123 and S124 in FIG. 4).

[0126] (8) Obtaining a list of web services - Part 1 (Steps S125 and S126 in Figure 4) After checking whether the web resource is available, the client terminal device 3 acquires data on a list of available services if the web resource is available. Specifically, the client terminal device 3 transmits an API request for acquiring a list of web services to the receiving terminal device 2 (step S125 in FIG. 4). In response to this request, the receiving terminal device 2 transmits response data on the list of web services to the client terminal device 3 (step S126 in FIG. 4).

[0127] FIG. 11 is a schematic diagram showing an API (request) for acquiring availability of a web resource, which is sent from the client terminal device 3 to the receiving terminal device 2. As shown in the figure, the URL of this API is <baseurl> / webservice". <baseurl>" has already been explained. The method for calling this API is "get".

[0128] FIG. 12 is a schematic diagram showing response data corresponding to the above-mentioned request to obtain a list of web services. This response data is sent by the receiving terminal device 2 to the client terminal device 3. The response data is written, for example, as JSON format data. As shown in the figure, the response to the web service list acquisition API includes a header section (a block indicated by "head") and a body section (a block indicated by "body"). The header section has already been described. The creation date and time (created_at) included in the body section has already been described. The media data included in the body section includes a type called "web".

[0129] Also, the list labeled "channels" (lines 11 to 29 in FIG. 12) contains a list of channel information. In the example shown, this response data contains data for two channels. The description of the first channel is from lines 12 to 19. The description of the second channel is from lines 20 to 27.

[0130] The data for the first channel is as follows: The logical channel number ("logical_channel_number") is "011" (line 13). The media information ("base") of the resource ("resource") is "TD" (terrestrial digital) (line 15). The information identifying the stream ("stream") is " / stream / 32736.mpd" (line 16). The broadcast channel name ("broadcast_channel_name") is "NHK General TV - Kanto Wide Area" (line 18).

[0131] The data for the second channel is as follows: The logical channel number ("logical_channel_number") is "021" (line 21). The media information ("base") of the resource ("resource") is "TD" (terrestrial digital) (line 23). The information identifying the stream ("stream") is " / stream / 32737.mpd" (line 24). The broadcast channel name ("broadcast_channel_name") is "NHK Educational - Kanto Region" (line 26).

[0132] The stream information described here is a stream transcoded for the web by the receiving terminal device 2, and is a URL for providing resources by the receiving terminal device 2. This URL is information indicating the location of a manifest file that allows the client terminal device 3 to obtain video content distributed over the Internet.

[0133] In the example shown in Fig. 12, the URL, which is information specifying the stream ("stream"), includes a transport ID (transport_id) defined by ARIB. That is, for the first channel, the transport ID is "32736." Also, for the first channel, the transport ID is "32737."

[0134] However, it is also possible to use a different format from the example shown in FIG. 12, for example, by using a common manifest file for all services and setting the URL to " / webresouce / stream.mpd".

[0135] With the response data as described above, the client terminal device 3 can obtain information on a list of services that can be acquired as web resources.

[0136] (9) List of Web Services - Part 2 This method replaces the API call for obtaining a list of web services (steps S125 and S126 in FIG. 4). Instead, this method extends the existing API for obtaining a list of programming services (steps S107 and S108 in FIG. 3) that the Hybridcast terminal linkage function has.

[0137] FIG. 13 is a schematic diagram showing an API (request) for acquiring a list of programming services, which is sent from the client terminal device 3 to the receiving terminal device 2 in this method. As shown in the figure, the URL of this API is <baseurl> / webservice". <baseurl>" has already been explained. The method for calling this API is "get". Here, the query "media=web" is used as an API extension. When the API is called with this query, the receiving terminal device 2 recognizes that it is a request to obtain a list of services using web resources.

[0138] The response data in this technique may be, for example, the data already described and shown in Fig. 12. That is, the response data includes data of a list of services that the client terminal device 3 can acquire from the receiving terminal device 2. This allows the client terminal device 3 to acquire information on all available services.

[0139] (10) Obtaining a list of web services - Part 3 (obtaining a list of services from an external server) In this method, the client terminal device 3 acquires information about web resource services provided by an external server device.

[0140] 14 is a block diagram showing a configuration for a client terminal device 3 to acquire web resource organization information in this method. As shown in the figure, in this method, a system 1 includes a web organization information management server device 91 in addition to a receiving terminal device 2 and a client terminal device 3.

[0141] The web composition information management server device 91 has the function of providing a list of web services available to the client terminal device 3 in response to a request. The web composition information management server device 91 is accessed by a large number of terminal devices and provides information on web services to those terminals. In the illustrated example, the client terminal device 3 obtains the list of services via the receiving terminal device 2. An example of a specific procedure is as follows.

[0142] In step S301, the client terminal device 3 transmits a request to acquire a list of programming services to the receiving terminal device 2. This request corresponds to the request described in step S107 of Fig. 3. In this request, the client terminal device 3 may add the query "media=web" described in Fig. 13. The receiving terminal device 2 receives this request.

[0143] In step S302, based on the request from the client terminal device 3, the receiving terminal device 2 transmits a request to acquire web programming information to the web programming information management server device 91. The web programming information management server device 91 receives this request.

[0144] In step S303, in response to the request in step S302, the web programming information management server device 91 transmits information on a list of web resource services to the receiving terminal device 2 as a response.

[0145] In step S304, the receiving terminal device 2 transmits the information on the list of web resource services received from the web publication information management server device 91 to the client terminal device 3. The client terminal device 3 receives this response data. This response corresponds to the one described in step S108 of FIG. 3.

[0146] FIG. 15 is a schematic diagram showing an example of data (extended response) transmitted by the receiving terminal device 2 to the client terminal device 3 as a response to the request for acquiring a programming service list. Similar to the data described with reference to FIG. 12, this response data includes information on the first channel (lines 12 to 19) and information on the second channel (lines 20 to 27). In the information on the first channel, the logical channel number is "011." The media type is "TD" (digital terrestrial broadcasting). The stream URL is " / stream / 32736.mpd." Meanwhile, in the information on the second channel, the logical channel number is "021." The media type is "TD" (digital terrestrial broadcasting). The stream URL is " / stream / 32737.mpd." This response data further includes a channel with a logical channel number of "000" (lines 29 to 36). This channel is a "WEB" (line 32) media, and its stream URL is " / stream / Utube.mpd" (line 33). The broadcast channel name (broadcast_channel_name) of this channel is "Utube Channel" (line 35).

[0147] According to this method, service configurations that reflect specific channels (such as paid channels, channels that prohibit distribution via transcoding, and services that are distributed only via communication (Internet)) can be reflected in the list.

[0148] In this method, the client terminal device 3 is configured to obtain information on a list of services from an external server device (web editing information management server device 91). As a variation, the client terminal device 3 may obtain information indicating whether or not each channel can be used as a web resource from the external server device.

[0149] As another modification, when the receiving terminal device 2 transmits a request to the web programming information management server device 91 (step S302 in FIG. 14), the request may include program programming information (terrestrial digital, broadcast satellite digital, CS digital). This allows the video content viewable on the client terminal device 3 to be tailored to the region.

[0150] (11) Web Service Invocation Request - Part 1 (Steps S127 and S128 in Figure 4) With this API, the client terminal device 3 makes a web service activation request to the receiving terminal device 2 based on the collected information. Through this web service activation request API, the client terminal device 3 can control the start or end of processing by the transcoding unit 261 in the receiving terminal device 2, and set (change) processing parameters.

[0151] FIG. 16 is a schematic diagram showing an API (request) for a web service invocation request sent from the client terminal device 3 to the receiving terminal device 2. As shown in the figure, the URL of this API is <baseurl> / webstream". <baseurl>" has already been explained. The method for calling this API is "post".

[0152] FIG. 17 is a schematic diagram showing an example in which a parameter setting description is added to the web service activation request shown in FIG. 16. In the example shown, " / content / manifest.mpd" is specified as the manifest file (line 3). Furthermore, "6" is specified as the segment size (line 4). Furthermore, "1" is specified as the chunk size (line 5). Furthermore, other parameters for the processing of the transcoding unit 261 may be specified. In this way, the client terminal device 3 can control the processing of the transcoding unit 261 via the API of this technique.

[0153] If parameters for processing by the transcoding unit 261 are set in advance, it is possible not to explicitly include parameter designation in the web service activation request.

[0154] The transcoding unit 261 of the receiving terminal device 2 performs encoding processing based on the web service activation request. That is, the transcoding unit 261 encodes the video and audio extracted from the broadcast signal received by the receiving terminal device 2 into communication content (net video) such as MPEG-DASH. That is, the transcoding unit 261 generates data in MPD format or MP4 format.

[0155] 18 is a schematic diagram showing an example of a response corresponding to the above-mentioned web service invocation request. This response is sent from the receiving terminal device 2 to the client terminal device 3. This response data includes a header section and a body section. The header section contains data with a code of "201" and a message of "Created," which indicates that the web service invocation request was successful and a resource was created. The body section also contains data indicating that the task ID is "15180375."

[0156] (12) Web service invocation request - Part 2 This method is an alternative method for requesting the initiation of a web service. In this method, the client terminal device 3 does not send an explicit request for the initiation of a web service via an API to the receiving terminal device 2. In this method, the transcoding unit 261 of the receiving terminal device 2 automatically starts transcoding processing in response to a channel selection request (Mode=tune) from the client terminal device 3 in the terminal linking function of Hybridcast. This channel selection request corresponds to the request for channel selection and HC application startup in step S109 of FIG. 3. In the receiving terminal device 2, the video and audio of the selected service are passed to the transcoding unit 261, which then generates video as web content.

[0157] In this method, the control (start / stop and parameter setting) of the transcoding unit 261 of the receiving terminal device 2 may be determined in advance. Alternatively, the transcoding unit 261 may be controlled from the client terminal device 3 using communication between the receiving terminal device 2 and the client terminal device 3 (terminal linked communication in step S115 of FIG. 3).

[0158] (13) Web Service Invocation Request - Part 3 This method is another alternative method for requesting a web service launch. This method extends the parameters of the above-mentioned channel selection request (the request for channel selection and HC application launch in step S109 of FIG. 3). In other words, the client terminal device 3 can add "Mode=web" as a parameter to the request for channel selection and HC application launch.

[0159] FIG. 19 is a schematic diagram showing an API (request) for a channel selection / HC application start request sent from the client terminal device 3 to the receiving terminal device 2 in this method. As shown in the figure, the URL of this API is " <baseurl> / Hybridcast". <baseurl>" has already been explained. The method for calling this API is "post." This request also has the description "Mode=web" as an extended query. This extended query indicates that this is a request for a web resource.

[0160] FIG. 20 is a schematic diagram showing an example of the description of parameters added to the request for channel selection and HC application launch request shown in FIG. 19. In the example shown, the description from line 2 to line 11 is a description for the existing Hybridcast terminal linkage function. Specifically, line 2 to line 6 are descriptions for specifying the transport stream ID, original network ID, and service ID of the service to be selected. Furthermore, line 7 to line 11 are descriptions related to the Hybridcast application. That is, line 8 specifies the URL of the AIT (application information table), line 9 specifies the service provider ID (orgid), and line 10 specifies the application ID (appid).

[0161] Lines 12 to 16 of the data shown in FIG. 20 are the extended description portion in this embodiment. In other words, this description is a description for the client terminal device 3 to control the transcoding unit 261 of the receiving terminal device 2 in order to acquire web resources. This description example corresponds to the data shown in FIG. 17. That is, "webstream" on line 12 indicates that this is a description related to web resources. Furthermore, line 13 is a description that specifies the URL of the manifest file. Furthermore, line 14 is a description that specifies the segment length. Furthermore, line 15 is a description that specifies the chunk length. This allows the client terminal device 3 to control the transcoding unit 261.

[0162] As a modification of this method, the descriptions from line 12 to line 16 in Fig. 20 may be omitted. In this case, the parameters of the transcoding unit 261 on the receiving terminal device 2 side are set in advance.

[0163] FIG. 21 is a schematic diagram showing an example of response data for a channel selection / HC application launch request (API) in this method. This response data is written in JSON format, for example. The response data has a header section and a body section. Of the messages included in the header section, the description of "webstream" is an expanded description in this embodiment. The value "Created" indicates that the generation of the web resource has been successfully completed. The body section also includes task ID information.

[0164] (14) Obtaining Web Service Invocation Status - Part 1 (Steps S129 and S130 in Figure 4) With this API, the client terminal device 3 requests the receiving terminal device 2 to acquire the web service activation status. In response, the receiving terminal device 2 transmits information on the web service activation status to the client terminal device 3 as a response. Specifically, the receiving terminal device 2 has a function to transmit information indicating the execution status of the transcoding unit 261 to the client terminal device 3 as the response. This allows the client terminal device 3 to know the processing status of transcoding in the receiving terminal device 2. In other words, it can know whether the service has been activated in the receiving terminal device 2.

[0165] FIG. 22 is a schematic diagram showing an API (request) for acquiring the web service activation status sent from the client terminal device 3 to the receiving terminal device 2. As shown in the figure, the URL of this API is <baseurl> / webstream". <baseurl>" has already been explained. The method for calling this API is "get".

[0166] FIG. 23 is a schematic diagram showing an example of response data corresponding to the request for obtaining the web service activation status shown in FIG. 22. This response data is sent by the receiving terminal device 2 to the client terminal device 3. As shown in the figure, the response data is written as, for example, JSON format data. As shown in the figure, the response to the web service activation status obtaining API has a header section and a body section. The header section has been described above. The body section also includes information about the task ID "15180375".

[0167] The "webresource" block (lines 8 to 14) in the body of this response contains data indicating whether the web service can be started. In the example shown, the result returned from the receiving terminal device 2 to the client terminal device 3 is as follows: The status is "Done" (startup successful). The code "200" and message "OK" also indicate that the request to start the web service has been completed successfully.

[0168] (15) Obtaining Web Service Invocation Status - Part 2 (Steps S129 and S130 in Figure 4) This method is a further extension of the API for acquiring the web service activation status described above. The response data described above with reference to FIG. 23 was used to notify the client terminal device 3 of the status of the entire web service from the receiving terminal device 2. In this method, the response data contains activation status (information indicating whether activation was successful or not) not for the entire web service but for each web resource such as video, audio, and subtitles. This allows the client terminal device 3 to grasp the activation status of each web resource.

[0169] (16) Obtaining the status of web service invocation - Part 3 In this method, instead of providing an API for acquiring the web service activation status, the API for acquiring the activation status (steps S111 and S112 in FIG. 3) is extended. Specifically, the response for acquiring the activation status (step S112 in FIG. 3) is extended.

[0170] Figure 24 is a schematic diagram showing example response data when the API for acquiring launch status is extended. The response data is written, for example, as JSON format data. The response to the API for acquiring launch status includes a header section and a body section. The header section has already been explained. The body section includes information on the task ID "15180375." In addition to a block representing the status of "hybridcast" (lines 8 to 14), the body section also has a block representing the status of the web resource (lines 15 to 21). In this example, the web resource status (status) is "Done" (launch successful, available). Note that the status can also take the value "NoProcess" (no process (i.e., launch failed)).

[0171] As described above, according to this method, instead of providing an API for acquiring the web service activation status, the API for acquiring the activation status is extended, thereby enabling the client terminal device 3 to acquire information on the activation status of the web service.

[0172] (17) Obtaining the Web Service Status - Part 1 (Steps S131 and S132 in Figure 4) With this API, the client terminal device 3 requests the receiving terminal device 2 to acquire the web service status. In response, the receiving terminal device 2 transmits web service status information to the client terminal device 3 as a response. This allows the client terminal device 3 to acquire the transcoding status (whether or not it is running, etc.).

[0173] FIG. 25 is a schematic diagram showing an API (request) for acquiring the status of a web service sent from the client terminal device 3 to the receiving terminal device 2. As shown in the figure, the URL of this API is <baseurl> / webstatus". <baseurl>" has already been explained. The method for calling this API is "get".

[0174] Fig. 26 is a schematic diagram showing an example of response data corresponding to the request for obtaining the web service status shown in Fig. 25. This response data is sent by the receiving terminal device 2 to the client terminal device 3. The response data is written as data in JSON format, for example. The response to the web service status obtainment API has a header section and a body section. The header section has been described above.

[0175] The body of the response to Get Web Service Status contains a block (lines 7 to 14) that indicates the status. This status contains the following data: Line 8 contains data indicating that the transcoding process is running. Lines 10 to 13 contain resource information indicating that the media is terrestrial digital (TD) and that the manifest file URL is / stream / 32736.mpd.

[0176] (18) Obtaining the Web Service Status - Part 2 (Steps S131 and S132 in Figure 4) In this method, the API for obtaining the web service status explained above is further expanded. The response data in Figure 26 above represents one status for the web service as a whole. In this method, the receiving terminal device 2 returns the status of each web service as a response to the client terminal device 3. Note that the request data in the API of this method is the same as the data already explained in Figure 25.

[0177] FIG. 27 is a schematic diagram showing an example of response data returned in response to a request to obtain the status of a web service in this technique. This response data is sent by the receiving terminal device 2 to the client terminal device 3. The response data is written, for example, as data in JSON format. The response of the web service status obtainment API has a header section and a body section. The header section has been described above.

[0178] The body of the response shown in Figure 27 includes a block (lines 7 to 22) that indicates the status (status). The contents of this status data are as follows: The data on line 8 indicates the status of the transcoding process ("transcode"). The data on line 9 indicates the status of the video ("VIDEO"). The data on line 10 indicates the status of the audio ("AUDIO"). The data on line 11 indicates the status of the subtitles ("SUBTITLE"). The data on line 12 indicates the status of the event message ("EVENT"). The data on line 13 indicates the status of the data broadcasting content ("BML") written in BML. The data on line 14 indicates the status of hybridcast ("AIT"). The data on line 15 indicates the status of the electronic program guide ("EPG"). The data on line 16 indicates the status of the service information ("SI"). In each of the above, "Running" indicates that the service is running. "NotRunning" indicates that the service is not running. Furthermore, lines 18 to 21 are data indicating, as resource information, that the media is terrestrial digital ("TD") and that the URL of the manifest file ("manifest") is " / stream / 32736.mpd".

[0179] (19) Obtaining the status of a web service - Part 3 In this method, no API is provided for acquiring the web service status, but the receiver status acquisition API (steps S113 and S114 in FIG. 3) is extended to enable the client terminal device 3 to acquire the web service status.

[0180] Fig. 28 is a schematic diagram showing an example of extended response data returned in response to a request to acquire the receiver status in this technique. This response data is sent by the receiving terminal device 2 to the client terminal device 3. The response data is written, for example, as data in JSON format. The response of the web service status acquisition API has a header section and a body section. The header section has been explained above.

[0181] The body of the response shown in FIG. 28 has a block (lines 7 to 16) that indicates the status. This status data includes information indicating the status of the transcoding process ("transcode") as extended data. In this example, the value is "Running." If the transcoding process is not running, the value is "NotStarted." This response data allows the client terminal device 3 to understand the status of the receiving terminal device 2.

[0182] (20) Utilization of device-linked communication API (Step S115 in Figure 3) By utilizing the API for device linkage communication through the device linkage function of Hybridcast, various processes in this embodiment can be realized. As a specific example, the client terminal device 3 can request the transcoding unit 261 of the receiving terminal device 2 to start encoding processing, change the settings of parameters related to transcoding processing, or delete the cache memory of the transcoding unit 261. Furthermore, the client terminal device 3 can send information about user operations to the transcoding unit 261 of the receiving terminal device 2 via this device linkage communication API. This information about operations includes operations such as starting or stopping video playback (web resources). In other words, by mutually communicating between the client terminal device 3 and the receiving terminal device 2 through the API for device linkage communication through the device linkage function of Hybridcast, web resources can be utilized on the client terminal device 3 side.

[0183] 29 is a block diagram showing a schematic internal functional configuration of the client terminal device 3. As shown in the figure, the client terminal device 3 includes a communication unit 331, an application engine 352, an application launcher 353, and a receiving terminal cooperation control unit 363. The client terminal device 3 can be realized using electronic circuits. At least some of the functions of the client terminal device 3 may be realized by a computer and a program. The functions of each unit are as follows:

[0184] It should be noted that the functions constituting the client terminal device 3 do not necessarily have to all be realized on the same hardware, and the client terminal device 3 may be realized in a form distributed (loosely coupled) across multiple devices (hardware).

[0185] The communication unit 331 communicates with external devices. The communication unit 331 communicates with the outside world using, for example, the Internet Protocol (IP). The function of the communication unit 331 enables the client terminal device 3 to communicate with the receiving terminal device 2 and the like.

[0186] The application engine 352 executes application programs. As shown in the figure, for example, a web application is one of the programs executed on the application engine 352. Specifically, the application engine 352 runs a web application that receives and uses web resources from the receiving terminal device 2.

[0187] The web application has the function of displaying web content, including content written in HTML (HyperText Markup Language) and MPEG-DASH video playback players.

[0188] The application launcher 353 launches a specific application program on the application engine 352. The application launcher 353 launches the above-mentioned web application based on, for example, a user operation.

[0189] The receiving terminal cooperation control unit 363 performs cooperation operation with the receiving terminal device 2 using the Hybridcast terminal cooperation function. Specifically, the receiving terminal cooperation control unit 363 acquires information for using web resources provided by the receiving terminal device 2 via the API of the Hybridcast terminal cooperation function. Because the Hybridcast terminal cooperation function is a standardized technology, it becomes possible for the receiving terminal device 2 and the client terminal device 3 to cooperate with each other in a manner that is independent of the device manufacturer, etc.

[0190] That is, the receiving terminal cooperation control unit 363 uses the terminal cooperation function of Hybridcast to execute the processing required to use the web resource as a cooperative operation with the receiving terminal device 2. Specifically, the receiving terminal cooperation control unit 363 receives at least information on the location (endpoint, etc.) for using the web resource from the receiving terminal device 2.

[0191] FIG. 30 is a block diagram showing an example of the internal configuration of each device (such as the receiving terminal device 2, the client terminal device 3, the web editing information management server device 91, or other necessary server devices) constituting the system 1 in this embodiment. Each device can be realized using a computer. As shown in the figure, the computer includes a central processing unit 901, a RAM 902, an input / output port 903, input / output devices 904 and 905, and a bus 906. The computer itself can be realized using existing technology. The central processing unit 901 executes instructions contained in a program read from the RAM 902 or the like. In accordance with each instruction, the central processing unit 901 writes data to the RAM 902, reads data from the RAM 902, and performs arithmetic and logical operations. The RAM 902 stores data and programs. Each element in the RAM 902 has an address and can be accessed using the address. RAM is an abbreviation for "random access memory." The input / output port 903 is a port through which the central processing unit 901 exchanges data with external input / output devices. Input / output devices 904 and 905 are input / output devices. The input / output devices 904 and 905 exchange data with the central processing unit 901 via an input / output port 903. A bus 906 is a common communication path used within the computer. For example, the central processing unit 901 reads and writes data from / to RAM 902 via the bus 906. Also, for example, the central processing unit 901 accesses the input / output port via the bus 906.

[0192] When implementing at least some of the functions of each device using a computer, a program for implementing these functions is recorded on a computer-readable recording medium, and the program recorded on the recording medium is loaded and executed by the computer system. Note that the term "computer system" here includes hardware such as an operating system and peripheral devices. Furthermore, "computer-readable recording medium" refers to portable media such as flexible disks, optical magnetic disks, ROMs, CD-ROMs, DVD-ROMs, and USB flash drives, as well as storage devices such as hard disks built into the computer system. In other words, a "computer-readable recording medium" may be a non-transitory computer-readable recording medium. Furthermore, the term "computer-readable recording medium" may also include media that temporarily and dynamically store programs, such as communication lines used when transmitting programs over networks like the Internet or telephone lines, or media that store programs for a fixed period of time, such as volatile memory within the server or client computer systems. The program may be a program that implements some of the functions described above, or it may be a program that can be implemented in combination with a program already stored in the computer system.

[0193] [Variation 1] In the above description of the embodiment, all the functions of the cooperative operation (various controls for the cooperation) between the receiving terminal device 2 and the client terminal device 3 were described. However, it is not necessary to implement all of the functions described above in the receiving terminal device 2 and the client terminal device 3. The receiving terminal device 2 and the client terminal device 3 may be implemented with some functions omitted. Even in this case, the client terminal device 3 can obtain and use data of the web resource provided by the receiving terminal device 2 based on the given location information.

[0194] [Variation 2] In the above embodiment, a case has been described in which, among resources included in a broadcast signal received by the receiving terminal device 2, video and audio in particular are transcoded and transmitted from the receiving terminal device 2 to the client terminal device 3 as video and audio web resources. However, the broadcast resources transmitted to the client terminal 3 through terminal cooperation are not necessarily limited to video and audio. Any of the information included in the broadcast resources, such as video, audio, subtitles, SI (service information), EPG (electronic program guide), EM (event message), and AIT (application information table), may be transmitted from the receiving terminal device 2 to the client terminal device 3 as a web resource. In this case, the above-described procedures for controlling cooperation between the receiving terminal device 2 and the client terminal device 3 can also be used.

[0195] The above has described in detail an embodiment of the present invention (including modified examples) with reference to the drawings, but the specific configuration is not limited to this embodiment, and also includes designs within the scope that do not deviate from the gist of the present invention. [Industrial Applicability]

[0196] The present invention can be used in industries that provide content such as video content, and industries that manufacture or sell equipment for that purpose, etc. However, the scope of use of the present invention is not limited to the examples given here. [Explanation of symbols]

[0197] 1 System 2. Receiving terminal device (receiving device) 3. Client terminal device 4 Antennas 8. Router 91 Web editing information management server device 201 Tuner unit (receiving unit) 202 Descrambler 203 Demultiplexer 211 Data broadcasting processing unit 212 Video decoder section 213 Audio decoder section 214 Subtitle decoder section 221 Data Broadcasting Engine 231 Communications Department 232 Streaming Receiver 233 Demultiplexer 242 Video decoder section 243 Audio decoder section 244 Subtitle Decoder 251 Application control unit 252 Application Engine 253 Application Launcher 261 Transcoding Section 262 Web Resources Department 263 Client terminal cooperation control unit 271 Video output section 272 Audio output section 331 Communications Department 352 Application Engine 353 Application Launcher 363 Receiving terminal cooperation control unit 901 Central Processing Unit 902 RAM 903 Input / Output Ports 904,905 Input / Output Devices 906 Bus< / baseurl> < / baseurl> < / baseurl> < / baseurl> < / baseurl> < / baseurl> < / baseurl> < / baseurl> < / baseurl> < / baseurl> < / baseurl> < / baseurl> < / baseurl> < / baseurl>

Claims

1. a receiving unit for receiving a broadcast signal; a client terminal cooperation control unit that controls cooperation with an external client terminal device by a terminal cooperation function of Hybridcast, and transmits location information to the client terminal device for using resource data extracted from the broadcast signal as a web resource in a format that can be used by a web platform; Equipped with Receiving device.

2. a transcoding unit that transcodes the video and audio resource data extracted from the received broadcast signal into data in a format usable by a web platform and outputs the data as video and audio web resources; a web resource providing unit that transmits the web resources of the video and audio output by the transcoding unit to the client terminal device via communication in response to a viewing request from the client terminal device; Furthermore, the client terminal cooperation control unit transmits to the client terminal device location information for using the video and audio web resources transmitted by the web resource providing unit; 2. The receiving device according to claim 1.

3. the client terminal cooperation control unit transmits location information for using the web resource to the client terminal device in response to a request from the client terminal device to discover a device that provides the web resource; 3. The receiving device according to claim 1 or 2.

4. the client terminal cooperation control unit transmits the information on availability of the web resource to the client terminal device in response to a request from the client terminal device to acquire the information on availability of the web resource; 4. A receiving device according to any one of claims 1 to 3.

5. The client terminal cooperation control unit transmits to the client terminal device information on availability of at least one of the types of video, audio, subtitles, SI (service information), EPG (electronic program guide), EM (event message), and AIT (application information table) of the web resources.

5. The receiving device according to claim 4.

6. the client terminal cooperation control unit transmits, in response to a request from the client terminal device for acquiring a list of web services, information on a list of web services of the web resources that can be provided to the client terminal device; 6. A receiving device according to any one of claims 1 to 5.

7. the client terminal cooperation control unit transmits the web service list information acquired from an external web editing information management server device to the client terminal device; 7. The receiving device according to claim 6.

8. the client terminal cooperation control unit controls the transcoding unit in response to a request from the client terminal device to start or end processing by the transcoding unit or to set parameters for processing by the transcoding unit.

3. The receiving device according to claim 2.

9. the client terminal cooperation control unit transmits information on whether the web service can be started to the client terminal device in response to a request from the client terminal device to acquire information on whether the web service can be started; 9. Receiving device according to any one of claims 1 to 8.

10. the client terminal cooperation control unit transmits web service status information indicating whether the transcoding unit is running or not to the client terminal device in response to a request from the client terminal device to acquire the web service status information, the web service status information indicating whether the transcoding unit is running or not.

3. The receiving device according to claim 2.

11. an application engine that runs a web application that receives and uses the web resource from the receiving device according to claim 1; a receiving terminal cooperation control unit that receives location information for using the web resource from the receiving device using a hybridcast terminal cooperation function; Equipped with Client terminal equipment.

12. the receiving terminal cooperation control unit transmits a request to the receiving device to discover a device that provides the web resource, and receives location information for using the web resource transmitted by the receiving device in response to the request to discover a device that provides the web resource.

12. The client terminal device according to claim 11.

13. the receiving terminal cooperation control unit transmits a request to the receiving device to acquire information on availability of the web resource, and receives from the receiving device the information on availability of the web resource transmitted by the receiving device in response to the request to acquire the information on availability of the web resource; 13. A client terminal device according to claim 11 or 12.

14. The receiving terminal cooperation control unit receives from the receiving device information on availability of at least one of the types of video, audio, subtitles, SI (service information), EPG (electronic program guide), EM (event message), and AIT (application information table) of the web resource.

14. A client terminal device according to claim 13.

15. the receiving terminal cooperation control unit transmits a request to the receiving device to acquire a web service list, and receives, from the receiving device, information on the web service list transmitted by the receiving device in response to the request to acquire the web service list; A client terminal device according to any one of claims 11 to 14.

16. the receiving terminal cooperation control unit receives, from the receiving device, the information on the web service list that the receiving device has acquired from an external web programming information management server device; 16. A client terminal device according to claim 15.

17. The receiving device is a transcoding unit that transcodes the video and audio resource data extracted from the received broadcast signal into data in a format usable by a web platform and outputs the data as video and audio web resources; a web resource providing unit that transmits the web resources of the video and audio output by the transcoding unit to the client terminal device via communication in response to a viewing request from the client terminal device; and the receiving-terminal cooperation control unit transmits to the receiving device a request to start or end processing by the transcoding unit on the receiving device side, or to set parameters for processing by the transcoding unit; A client terminal device according to any one of claims 11 to 16.

18. the receiving terminal cooperation control unit transmits a request to the receiving device to acquire information on whether or not the web service can be started, and receives from the receiving device the information on whether or not the web service can be started, the information being transmitted by the receiving device in response to the request to acquire the information on whether or not the web service can be started; A client terminal device according to any one of claims 11 to 17.

19. the receiving terminal cooperation control unit transmits to the receiving device a request to acquire web service status information indicating whether the transcoding unit is running in the receiving device, and receives from the receiving device the web service status information transmitted by the receiving device in response to the request to acquire the web service status information.

18. A client terminal device according to claim 17.

20. A computer including a receiving unit for receiving a broadcast signal, A receiving device according to any one of claims 1 to 10, A program to function as a

21. Computer, A client terminal device according to any one of claims 11 to 19, A program to function as a

Images