Receiving device, client terminal device, and program

Abstract

To allow a client terminal device side cooperating with a receiving device to use a content of a hybrid-cast application.SOLUTION: A receiving device includes a content conversion unit and a web resource providing unit. The content conversion unit converts an application into an application in a format available on a web platform. The web resource providing unit activates the application on the basis of, an application activation request transmitted from a client terminal device. The web resource providing unit transmits the application available on the web platform, which is a result of conversion by the content conversion unit to the client terminal device through communication.SELECTED DRAWING: Figure 2

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 linking 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 Hybridcast Connect (Hybridcast device linking function) provides discovery, connection, and data transmission / reception protocols. Non-Patent Document 2 includes the provisions for Hybridcast device linking 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 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] In this situation, the problem to be solved by the present invention is as follows: A television receiver (hereinafter referred to as a receiving terminal device or receiving device) equipped with a broadcast tuner not only extracts video and audio from received broadcast signals and presents them to viewers, but also presents various content. One such content is content from a hybridcast app. Content from a hybridcast app is launched in a manner managed by a specific broadcast service, or launched based on the viewer's remote control operation, etc. In conventional technology, content output by a hybridcast app could be viewed on a receiving terminal device, but could not be viewed on a viewing terminal (hereinafter referred to as a client terminal device) that operates in conjunction with the receiving terminal device.

[0012] However, it is desirable to be able to view not only the video and audio of broadcast programs but also the content of Hybridcast apps on a client terminal device linked to a receiving terminal device.Furthermore, it is desirable to enable the client terminal device to use and utilize the content of Hybridcast apps in a format that conforms to a standard web interface between the receiving terminal device and the client terminal device.

[0013] The present invention has been made based on the recognition of the above-mentioned problems, and aims to provide a receiving device, a client terminal device, and a program that enable the content of a hybridcast app to be transferred from a receiving device (television receiver) to a client terminal device (viewing terminal) in a form that can be used by the client terminal device. [Means for solving the problem]

[0014] [1] In order to solve the above problem, a receiving device according to one aspect of the present invention includes a receiving unit that receives a broadcast signal, and a web resource providing unit that transmits, via communication, to a linked client terminal device, at least one of an application information table obtained based on the received broadcast signal or location information of the application information table based on the received broadcast signal.

[0015] [2] In addition, according to one aspect of the present invention, the receiving device further comprises a content conversion unit that converts an application identified by the application information table into an application that can be used on a web platform.

[0016] [3] In accordance with another aspect of the present invention, the receiving device further includes an application control unit that controls the operation of an application identified by the application information table.

[0017] [4] Furthermore, one aspect of the present invention is that in the above-mentioned receiving device, the web resource providing unit instructs the application control unit to launch the app based on an app launch request sent from a client terminal device with which the content conversion unit has performed conversion, and transmits the app that can be used on the web platform to the client terminal device via communication.

[0018] [5] Furthermore, one aspect of the present invention is that the above-mentioned receiving device further comprises a transcoding unit that transcodes at least one of the data of the video resource or the audio resource extracted from the received broadcast signal into data in a format usable by a web platform and outputs it as a web resource, and the web resource providing unit transmits the web resource output by the transcoding unit to the client terminal device via communication.

[0019] [6] Furthermore, in one aspect of the present invention, in the above-mentioned receiving device, the web resource providing unit instructs the application control unit to launch the app identified by information included in the app launch request from the client terminal device.

[0020] [7] Also, one aspect of the present invention is that in the above-mentioned receiving device, the web resource providing unit instructs the application control unit to launch the app identified by information contained in the broadcast signal received by the receiving unit.

[0021] [8] Furthermore, in one aspect of the present invention, in the above-mentioned receiving device, when the application control unit receives an instruction from the web resource providing unit to launch the app based on an app launch request sent from the client terminal device, the application control unit queries an external launch eligibility determination server device, and based on the response from the launch eligibility determination server device, decides whether to send an app that is available on the web platform to the client terminal device.

[0022] [9] Also, one aspect of the present invention is that in the above-mentioned receiving device, the web resource providing unit transmits data on the launch status of an app available on the web platform to the client terminal device in response to a request from the client terminal device to obtain the launch status.

[0023]

[10] Also, one aspect of the present invention is that in the above-mentioned receiving device, the web resource providing unit transmits receiver status data for apps available on the web platform to the client terminal device in response to a request for receiver status acquisition from the client terminal device.

[0024]

[11] Furthermore, a client terminal device according to one aspect of the present invention includes a receiving terminal cooperation control unit that transmits an application launch request for an application output by the content conversion unit of the receiving device described above in [2] to the receiving device, and receives from the receiving device an application that can be used on a web platform as a result of conversion by the content conversion unit.

[0025]

[12] Furthermore, one aspect of the present invention is that the above-mentioned client terminal device further comprises an application engine that runs a web application that receives and uses the web resources output by the transcoding unit of the receiving device described in [5] above, and the receiving terminal cooperation control unit executes the processing necessary to use the web resources as a cooperative operation with the receiving device using the terminal cooperation function of Hybridcast.

[0026]

[13] Furthermore, in one aspect of the present invention, in the above-mentioned client terminal device, the receiving terminal cooperation control unit transmits, together with the application launch request, information identifying the application to be launched to the receiving device.

[0027]

[14] Furthermore, one aspect of the present invention is that in the above-mentioned client terminal device, when the receiving terminal cooperation control unit sends the application launch request, it does not send information identifying the application to be launched to the receiving device, but requests the receiving device to identify the application to be launched based on information contained in the broadcast signal received by the receiving device.

[0028]

[15] 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 the launch status, and receives data on the launch status of the app from the receiving device.

[0029]

[16] 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 acquire the receiver status to the receiving device and receives receiver status data of the app from the receiving device.

[0030]

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

[10] above.

[0031]

[18] 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

[16] above. [Effects of the Invention]

[0032] According to the present invention, data of a hybridcast application running on a receiving device can also be utilized on the client terminal device side. [Brief explanation of the drawings]

[0033] [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. 2 is a functional block diagram showing the functional configuration of a client terminal device according to the embodiment. [Figure 4]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 5] 5 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. 4 above. [Figure 6] FIG. 10 is a schematic diagram showing an extended API for requesting the client terminal device to start hybridcast content to the receiving terminal device according to the embodiment (method 1). [Figure 7] 7 is a schematic diagram showing an example of data transmitted from the client terminal device to the receiving terminal device at the time of the activation request of FIG. 6 in the same embodiment (method 1). FIG. [Figure 8] FIG. 10 is a schematic diagram showing an example of response data returned from a receiving terminal device to a client terminal device in the same embodiment (method 1). [Figure 9] FIG. 10 is a schematic diagram showing an API of a Hybridcast application start request sent from a client terminal device to a receiving terminal device according to the embodiment (method 2). [Figure 10] FIG. 10 is a schematic diagram showing a new API of a Hybridcast application start request sent from a client terminal device to a receiving terminal device according to the same embodiment (method 3). [Figure 11] 11 is a schematic diagram showing an example of data transmitted from the client terminal device to the receiving terminal device when the startup request of FIG. 10 is made in the same embodiment (method 3). FIG. [Figure 12] FIG. 10 is a schematic diagram showing an example of an interface for transmitting a request (possibility inquiry) from a receiving terminal device to an AIT activation possibility determination server device according to the same embodiment (method 4). [Figure 13] 13 is a schematic diagram showing an example of response data from the AIT activation possibility determination server device to the receiving terminal device in response to the request (inquiry) of FIG. 12 in the same embodiment (method 4). FIG. [Figure 14] FIG. 10 is a schematic diagram showing an example of an interface for transmitting a request (possibility inquiry) from a receiving terminal device to an AIT activation possibility determination server device according to the embodiment (modification 2 of method 4). [Figure 15] 15 is a schematic diagram showing an example of response data from the AIT activation possibility determination server device to the receiving terminal device in response to the request (inquiry) of FIG. 14 in the embodiment (modification 2 of method 4). FIG. [Figure 16] FIG. 10 is a schematic diagram showing an example of data transmitted from a client terminal device to a receiving terminal device when requesting activation of a hybridcast application (activation of an application provided based on a broadcast signal) according to the same embodiment (method 6). [Figure 17] FIG. 11 is a schematic diagram showing an API for a client terminal device to request a receiving terminal device to start a Hybridcast application in the same embodiment (method 7). [Figure 18] FIG. 11 is a schematic diagram showing an API for a client terminal device to request a receiving terminal device to start a Hybridcast application in the same embodiment (method 8). [Figure 19] 10 is a schematic diagram showing an example of response data sent from a receiving terminal device to a client terminal device in a start permission status acquisition API extended by the same embodiment (method 10). FIG. [Figure 20] FIG. 11 is a schematic diagram showing the API (web Hybridcast application launch request) of the Hybridcast terminal linkage function that is available in the same embodiment (Method 11). [Figure 21] 21 is a schematic diagram showing an example of response data returned by the receiving terminal device to the client terminal device in response to the request shown in FIG. 20 in the same embodiment (method 11). FIG. [Figure 22] FIG. 11 is a schematic diagram showing an example of response data sent from a receiving terminal device to a client terminal device in an API (receiver state acquisition) extended in the same embodiment (method 12). [Figure 23]FIG. 10 is a schematic diagram showing a new API (obtaining receiver status related to a web hybridcast application) between a client terminal device and a receiving terminal device used in the same embodiment (method 13). [Figure 24] 24 is a schematic diagram showing an example of response data sent from a receiving terminal device to a client terminal device using the API shown in FIG. 23 in the same embodiment (method 13). FIG. [Figure 25] 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

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

[0035] 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 the terminal linking function of Hybridcast.

[0036] In this embodiment, video resources and audio resources extracted from the broadcast signal are distributed from the receiving terminal device 2 to the client terminal device 3 as online video content used on a standard web platform. In this embodiment, a hybridcast app is made available on the client terminal device 3 side. The hybridcast app is written in HTML5, for example, and may include JavaScript (registered trademark) executable code. In conventional technology, hybridcast apps run in a dedicated environment of the broadcast receiving terminal. In this embodiment, the hybridcast app is made to run on the client terminal device 3 using the method described below.

[0037] 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, a router 8, a communication network 9, and an AIT activation feasibility determination server device 11. The receiving terminal device 2 is also referred to as 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. The receiving terminal device 2, the client terminal device 3, the antenna 4, and the router 8 may be installed or placed, for example, in a home or a business. While this figure shows one receiving terminal device 2, one client terminal device 3, one router 8, and one AIT activation feasibility determination server device 11, the system 1 may include any number 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 are described below.

[0038] 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 set. 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 "application" or "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.

[0039] 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.

[0040] 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.

[0041] 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.

[0042] The communication network 9 is a communication network used when the receiving terminal device 2 communicates with the outside. The receiving terminal device 2 can communicate with the AIT activation feasibility determination server device 11 and other external devices via the communication network 9.

[0043] The AIT activation possibility determination server device 11 is a device that determines whether or not a hybridcast application can be activated and returns the determination result. The AIT activation possibility determination server device 11 receives, for example, information that identifies a broadcast service and information that identifies a hybridcast application (for example, AIT location information) from the receiving terminal device 2. The AIT activation possibility determination server device 11 determines whether or not a hybridcast application can be activated in a combination of that broadcast service and hybridcast application. There are cases where a broadcast service and a hybridcast application are associated with each other, and the hybridcast application can be activated only in the combination of that broadcast service and that hybridcast application. The AIT activation possibility determination server device 11 can make a determination by, for example, storing possibility information for each combination in advance, and can respond to an inquiry from the receiving terminal device 2.

[0044] The AIT activation possibility determination server device 11 of this embodiment can distinguish between whether a normal (i.e., not for the web) hybridcast application can be activated and whether a web-based hybridcast application (in other words, a web resource) can be activated. In other words, the AIT activation possibility determination server device 11 of this embodiment may determine whether only one of the above two types can be activated. Alternatively, the AIT activation possibility determination server device 11 of this embodiment may determine whether both of the above two types can be activated. In either case, the AIT activation possibility determination server device 11 passes information on whether the hybridcast application can be activated to the receiving terminal device 2 in response to an inquiry from the receiving terminal device 2. Note that the interface between the AIT activation possibility determination server device 11 and the receiving terminal device 2 will be described later for each of a plurality of methods.

[0045] 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, subtitles, event information, etc. contained in broadcast waves (broadcast signals), or other resources, 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, an audio output unit 272, a data analysis unit 281, an event processing unit 282, and a hybridcast content conversion unit 291.

[0046] 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:

[0047] Note that there are also communications between functional units that are omitted in Fig. 2. These will be explained separately in this embodiment.

[0048] 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."

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

[0050] 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.

[0051] 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).

[0052] 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.

[0053] 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.

[0054] 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.

[0055] 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.

[0056] 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.

[0057] 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.

[0058] 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.

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

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

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

[0062] The application control unit 251 controls application programs running on the receiving terminal device 2. That is, the application control unit 251 controls the running of applications in the application engine 252 described below. Specifically, the application control unit 251 starts and stops specific application programs and performs other management. The application control unit 251 performs control based on the technology (regulations) of Hybridcast.

[0063] The application control unit 251 may receive an instruction from the web resource providing unit 262 to start an application based on an application start request transmitted from the client terminal device 3. In this case, the application control unit 251 performs control to start the application. As a result, the application is executed in the application engine 252.

[0064] Furthermore, when receiving an instruction from the web resource providing unit 262 to start an application, the application control unit 251 may make an inquiry to the external AIT start possibility determination server device 11, as will be described later. In this case, the application control unit 251 determines whether to start the application based on a response from the AIT start possibility determination server device 11. The application started by the application control unit 251 in response to a start request from the client terminal device 3 may be an application available on the web platform that is output as a conversion result by the hybridcast content conversion unit 291 and transmitted to the client terminal device 3.

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

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

[0067] 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 (at least one of video resources and audio resources) extracted from the received broadcast signal into data in a format usable by the web platform, and outputs the data as web resources. 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.

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

[0069] 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.

[0070] The web resource providing unit 262 of this embodiment further receives and manages the data of the AIT received by the tuner unit 201 or the data of the location information (URL) of the AIT.

[0071] Furthermore, the web resource providing unit 262 communicates with the client terminal cooperation control unit 263 and performs processing according to the control of the terminal cooperation function of Hybridcast. Specifically, the web resource providing unit 262 receives requests from the client terminal device 3 to start a Hybridcast application, requests to acquire the startability status of a Hybridcast application, and It performs processing in response to requests to obtain the receiver status related to the broadcast application.

[0072] Furthermore, the web resource providing unit 262 has a function of transmitting the content of the hybridcast application as a web resource to the client terminal device 3. Furthermore, the web resource providing unit 262 communicates with the hybridcast content conversion unit 291, and has a function of transmitting the hybridcast application and receiving the result of the conversion process.

[0073] That is, the web resource providing unit 262 transmits the web resources output by the transcoding unit 261 to the client terminal device 3 as the cooperation destination via communication. Furthermore, the web resource providing unit 262 instructs the application control unit 251 to start an application based on an application start request transmitted from the client terminal device 3. That is, the web resource providing unit 262 instructs the application control unit 251 to start an application based on an application start request transmitted from the client terminal device 3 as the cooperation destination, and transmits the application usable on the web platform, which is the result of conversion by the hybridcast content conversion unit 291, to the client terminal device 3 via communication.

[0074] The web resource providing unit 262 determines the application to be launched using one of a number of methods, as will be described later.

[0075] As one method, the web resource providing unit 262 instructs the application control unit 251 to start an application specified by information included in the application start request from the client terminal device 3. In this method, as an example, the URL of the AIT is included in the data of the application start request. This makes it possible to access the AIT. Furthermore, the AIT includes information that specifies the application code. This allows the application control unit 251 to start the specific application.

[0076] The web resource providing unit 262 can transmit at least one of the application information table acquired based on the received broadcast signal or the location information of the application information table based on the received broadcast signal to the client terminal device with which it is associated via communication.

[0077] As another method, the web resource providing unit 262 instructs the application control unit 251 to start an application identified by information included in the broadcast signal received by the tuner unit 201. In this method, as an example, the URL of the AIT is included in the received broadcast signal. This makes it possible to access the AIT. Furthermore, the AIT includes information that identifies the application code. This allows the application control unit 251 to start the specific application.

[0078] When the client terminal device 3 requests acquisition of information via the API of the hybridcast terminal linkage function, the web resource providing unit 262 may provide the requested information to the client terminal device 3. The information provided by the web resource providing unit 262 may be the receiver status of the hybridcast app of the web resource or the launchability status of the hybridcast app of the web resource. In other words, in response to a request from the client terminal device 3 to acquire the launchability status, the web resource providing unit 262 transmits to the client terminal device 3 data on the launchability status of apps available on the web platform. In addition, in response to a request from the client terminal device 3 to acquire the receiver status, the web resource providing unit 262 transmits to the client terminal device 3 receiver status data on apps available on the web platform.

[0079] 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.

[0080] Specifically, the client terminal cooperation control unit 263 controls cooperation with the client terminal device 3 using the Hybridcast terminal cooperation function (including extended functions), and transmits information necessary for using web resources 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 resources to the client terminal device 3. In other words, the client terminal cooperation control unit 263 communicates with the web resource providing unit 262 and transmits the results of processing for cooperation between terminals to the client terminal device 3. In this case, the client terminal cooperation control unit 263 transmits information to the client terminal device 3 via the API of the Hybridcast terminal cooperation function, or transmits information via the WebSocket protocol.

[0081] 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.

[0082] The client terminal cooperation control unit 263 further has a function of performing the following processes to control the Hybridcast application.

[0083] The client terminal cooperation control unit 263 interprets a request to start a Hybridcast application from the client terminal device 3 through the terminal cooperation function of Hybridcast. Specifically, the client terminal cooperation control unit 263 interprets the start request from the client terminal device 3 to determine which AIT the start request from the client terminal device 3 is based on. As will be described later, when the client terminal device 3 explicitly specifies location information (URL, uniform resource locator) of the AIT, the client terminal cooperation control unit 263 interprets this as a request to start an application based on the AIT identified by the location information. When the client terminal device 3 does not explicitly specify location information (URL) of the AIT, the client terminal cooperation control unit 263 interprets this as a request to start an application based on information (URL, etc.) of the AIT extracted by the receiving terminal device 2 from the broadcast signal. When the location information of the AIT is not explicitly specified, for example, this occurs when the specified information is a null string or when the specified information does not directly indicate a specific AIT. For example, even when the client terminal device 3 explicitly instructs the receiving terminal device 2 to use the AIT derived from the broadcast signal, the client terminal cooperation control unit 263 interprets this as a request to launch an app based on the AIT information extracted by the receiving terminal device 2 from the broadcast signal.

[0084] The client terminal cooperation control unit 263 also transmits and receives necessary information to and from the client terminal device 3 regarding the control of the hybridcast application. That is, the client terminal cooperation control unit 263 communicates with the web resource providing unit 262, passes request information received from the client terminal device 3 to the web resource providing unit 262, and transmits information on the result (response) of the control of the hybridcast application to the client terminal device 3. The client terminal cooperation control unit 263 exchanges control information between the receiving terminal device 2 and the client terminal device 3 via an API of the hybridcast terminal cooperation function, or by bidirectional transmission and reception of data (text) via websocket.

[0085] 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.

[0086] 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.

[0087] The data analysis unit 281 analyzes data and manages metadata associated with video data and audio data. Specifically, the data analysis unit 281 analyzes video data received and extracted by the receiving terminal device 2, and manages information about people or objects included in the video, superimposed text (text) synchronized with the video, and the like as metadata. The data analysis unit 281 also analyzes audio data received and extracted by the receiving terminal device 2, and manages information about the content of utterances included in the audio data (such as the speaker and the text of the utterance) as metadata. The data analysis unit 281 can provide the metadata managed in association with the video data and audio data to the client terminal device 3. Specifically, the data analysis unit 281 cooperates with the web resource providing unit 262 to provide the above metadata to the client terminal device 3.

[0088] The data analysis unit 281 can, for example, compare the subtitle data extracted from the broadcast signal with the analysis results of the audio data extracted from the broadcast signal (for example, the results of analysis including voice recognition processing, etc.), and generate such subtitle processing results.

[0089] The data analysis unit 281 also has a function of matching the above metadata with program information (information such as EPG-API) received by the receiving terminal device 2. EPG is an abbreviation for "Electronic Programming Guide."

[0090] The video analysis and audio analysis techniques used by the data analysis unit 281 are existing techniques.

[0091] The event processing unit 282 performs processing related to the event information contained in the received broadcast signal.

[0092] The event processing unit 282 has a function to generate media timed event (MTE, MediaTimedEvents) data as event metadata for online video distribution. MTE data is MPD or EMSG. MPD stands for "Media Presentation Description." EMSG is a format for storing in-band messages. The event processing unit 282 inserts the MTE into the online video (video and audio) output by the transcoding unit 261. The event processing unit 282 works in conjunction with the web resource providing unit 262. In other words, when the web resource providing unit 262 provides web resources to the client terminal device 3, the event processing unit 282 inserts the MTE into the online video to be provided.

[0093] Instead of transmitting an event using an MTE, the event processing unit 282 can also transmit text data representing information about the event to the client terminal device 3 using the bidirectional terminal linkage communication of the Hybridcast terminal linkage function.

[0094] That is, the event processing unit 282 generates event information including accompanying information accompanying at least one of video and audio based on resources extracted from the broadcast signal. Here, the accompanying information is any of an event message, subtitles, superimposed characters, application information table (AIT), service information (SI), and data broadcasting content extracted from the broadcast signal. Alternatively, the accompanying information is metadata obtained by analyzing at least one of the video resources and audio resources extracted from the broadcast signal.

[0095] The hybridcast content conversion unit 291 performs various conversions and the like to make the hybridcast content available to the client terminal device 3. The hybridcast content conversion unit 291 is also simply called a "content conversion unit." The hybridcast content conversion unit 291 of this embodiment converts an application (hybridcast application) into an application in a format that can be used on a web platform. Specifically, the hybridcast content conversion unit 291 performs the following processes.

[0096] The hybridcast content conversion unit 291 converts the data of the content of the hybridcast application output for the hybridcast browser into data in a format that can be used by a general web browser. More specifically, the hybridcast content conversion unit 291 converts an API dedicated to the hybridcast browser into an API that can be used by a general web browser. Also, the hybridcast content conversion unit 291 converts tags output for the hybridcast browser into tags that can be interpreted by a general web browser. As an example, the hybridcast content conversion unit 291 converts the content of the hybridcast application output for the hybridcast browser into data in a format that can be used by a general web browser. <object>Tags, <video>The hybridcast content conversion unit 291 converts the received terminal device 2 status information into a tag. The hybridcast content conversion unit 291 also converts an API for understanding the status of the receiving terminal device 2 into an API request provided by the hybridcast terminal cooperation function. For example, the hybridcast content conversion unit 291 converts "getAvailableMedia()", which is an API (a function that can be called from within the hybridcast app) for understanding the status of the receiving terminal device 2, into a request for an available media acquisition API of the hybridcast terminal cooperation function. The hybridcast content conversion unit 291 also converts "getChannelInformation()", which is an API (function) for understanding the status of the receiving terminal device 2, into a request for a service list acquisition API of the hybridcast terminal cooperation function. The hybridcast content conversion unit 291 also converts other APIs into APIs of the hybridcast terminal cooperation function that have similar functions as appropriate.

[0097] It should be noted that some APIs of the Hybridcast application cannot be substituted by the Hybridcast device linkage function. For example, an API for obtaining a postal code in the operating environment (receiving terminal device 2) falls into this category. For such APIs, the Hybridcast content conversion unit 291 uses the device linkage communication (bidirectional) function of the Hybridcast device linkage function to construct a flow in which processing is entrusted from the client terminal device 3 to the receiving terminal device 2. At this time, the Hybridcast content conversion unit 291 enables a request from the client terminal device 3 to be sent to the receiving terminal device 2 using the sendtexttohostdevice function. The Hybridcast content conversion unit 291 also enables the processing result (response) of the receiving terminal device 2 to be sent to the client terminal device 3 using the endtexttocompaniondevice function.

[0098] In this manner, the hybridcast content conversion unit 291 performs processing to make the content of the hybridcast application available to the client terminal device 3.

[0099] 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.

[0100] 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).

[0101] 3 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:

[0102] 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).

[0103] 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.

[0104] 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.

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

[0106] 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.

[0107] 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.

[0108] That is, the receiving terminal cooperation control unit 363 executes processing required to use web resources as a cooperative operation with the receiving terminal device 2 using the terminal cooperation function of Hybridcast. Specifically, the receiving terminal cooperation control unit 363 receives at least information on the location (endpoint, etc.) for using the web resources from the receiving terminal device 2. In addition, the receiving terminal cooperation control unit 363 transmits to the receiving terminal device 2 an application activation request for acquiring an application that can be used on the web platform output by the Hybridcast content conversion unit 291 of the receiving terminal device 2.

[0109] When the receiving terminal cooperation control unit 363 transmits the above-mentioned application launch request, it may either transmit the request with information for specifying a specific application or transmit the request without information for specifying a specific application. In the former case, the receiving terminal cooperation control unit 363 may transmit, together with the application launch request, information for specifying the application to be launched, such as the URL of an AIT. The AIT specified by the URL includes location information of the application. In the latter case, the receiving terminal cooperation control unit 363 does not transmit information for specifying the application to be launched when transmitting the application launch request. In this case, the receiving terminal cooperation control unit 363 may, for example, transmit a null character string instead of the URL of the AIT or transmit predetermined data indicating that no application is specified. In this case, the receiving terminal device 2 can extract information for specifying the application, such as the URL of the AIT, from the broadcast signal and launch the application specified thereby.

[0110] Furthermore, the receiving terminal cooperation control unit 363 can transmit a request to the receiving terminal device 2 to acquire information from the receiving terminal device 2. Specifically, the receiving terminal cooperation control unit 363 transmits a request to acquire the activation status of the app. The receiving terminal cooperation control unit 363 receives data on the activation status transmitted by the receiving terminal device 2 in response to this request. The receiving terminal cooperation control unit 363 also transmits a request to acquire the receiver status of the app. The receiving terminal cooperation control unit 363 receives data on the receiver status transmitted by the receiving terminal device 2 in response to this request. The above app running on the receiving terminal device 2 side may be a hybridcast app. Furthermore, content output from the app may be a web resource available to the client terminal device 3.

[0111] 4 and 5 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.

[0112] 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.

[0113] 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.

[0114] Below, FIG. 4 and FIG. 5 will be described in turn.

[0115] 4, 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.

[0116] 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.

[0117] 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.

[0118] 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.

[0119] 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.

[0120] 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.

[0121] 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.

[0122] 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.

[0123] 5, 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.

[0124] 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.

[0125] 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.

[0126] 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.

[0127] 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.

[0128] 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.

[0129] Next, we will explain the procedures for controlling the hybridcast application and obtaining information on the operating status of the hybridcast application based on a request from the client terminal device 3. Specifically, we will explain each of methods 1 to 13 below. We will also explain variations (modified examples) of these methods.

[0130] [Method 1] Utilizing Hybridcast content via Hybridcast's device linkage function (Part 1: Expanding Hybridcast's device linkage function) In this method, the terminal linking function of Hybridcast is extended to enable Hybridcast content to be launched from the client terminal device 3. The API used here is steps S109 (request) and S110 (response) in Fig. 4. In this method, this API is extended.

[0131] Specifically, in this method, the system 1 operates as follows. That is, pairing has already been established between the receiving terminal device 2 and the client terminal device 3 based on mutual device discovery. That is, the receiving terminal device 2 and the client terminal device 3 are already linked. From this state, the client terminal device 3 transmits a hybridcast content launch request (mode=app) to the receiving terminal device 2. The receiving terminal device 2 receives this launch request and launches the specified hybridcast application. Specifically, the receiving terminal device 2 selects a broadcast service (channel) in accordance with the "resource" specification included in the launch request from the client terminal device 3, and acquires the hybridcast application in accordance with the URL information of the hybridcast AIT (Application Information Table) included in the launch request.

[0132] FIG. 6 is a schematic diagram showing an extended API for the client terminal device 3 to request the activation of hybridcast content using this method. As shown in the figure, the URL of this API is <baseurl> / hybridcast". <baseurl>is a predetermined base URL (the same applies hereafter). The method for calling this API is POST.

[0133] FIG. 7 is a schematic diagram showing an example of data transmitted from the client terminal device 3 to the receiving terminal device 2 when the above-mentioned channel selection / hybridcast application launch request (step S109 (request) in FIG. 4) is made. This data is written in, for example, JSON (JavaScript Object Notation) format. As shown in the figure, this data has a "resource" block (lines 2 to 6) and a "hybridcast" block (lines 7 to 11). As described above, the "resource" block has information specifying the broadcast service to be selected. Specifically, the broadcast service can be specified by a set of a transport stream ID (transport_stream_id), an original network ID (original_network_id), and a service ID (service_id). The "hybricast" block includes location information (URL) of the URL of the hybridcast AIT (application information table) described above. The "hybricast" block also has information on an organization ID (org_id) and an application ID (app_id).

[0134] Upon receiving the request for tuning and launching the hybridcast application, the receiving terminal device 2 launches the hybridcast application and performs processing for the client terminal device 3 to use the hybridcast content. That is, the hybridcast content conversion unit 291 of the receiving terminal device 2 converts the hybridcast content into a web resource. The hybridcast content conversion unit 291 also generates a URL for the client terminal device 3 to use the hybridcast content resulting from the conversion. The web resource providing unit 262 of the receiving terminal device provides the acquired hybridcast content to the client terminal device 3. That is, the web resource providing unit 262 transmits a response corresponding to the above request to the client terminal device 3.

[0135] FIG. 8 is a schematic diagram showing an example of response data (corresponding to step S110 in FIG. 4) returned from the receiving terminal device 2 to the client terminal device 3. This data is written in, for example, JSON format. As shown in the figure, this data has a header ("head") block (lines 2 to 5) and a body ("body") block (lines 6 to 9). The header ("head") data indicates that a hybridcast application has been launched. The body ("body") data has information on a task ID (taskid) and a web hybridcast URL (webhybridcasturl). The task ID is information for uniquely identifying the running task (here, the hybridcast application). The web hybridcast URL is location information for using the hybridcast content as a web resource, generated by the hybridcast content conversion unit 291 described above. In this example, the URL is " / webhybridcast / 15180375.html." In other words, in this example, the URL uses the above task ID. This URL information is also called an "endpoint."

[0136] [Modification 1 of Method 1: How to specify the URL of hybridcast content] Here, a modified example of this method will be described. In the above description, information on the web hybridcast URL is included in the response from the receiving terminal device 2 to the client terminal device 3. Alternatively, as a modified example 1, the URL information may not be included in the response, and the client terminal device 3 may be able to use the hybridcast content at a specific URL (endpoint) that is known in advance by the client terminal device 3. In this case, as an example, a fixed URL may be used.

[0137] However, when multiple client terminal devices 3 are operating simultaneously, it is necessary to devise a way to prevent URLs from conflicting with each other. For example, a URL containing a unique character string (such as a terminal ID) can be used for each client terminal device 3. Alternatively, instead of using this modified example, a URL can be dynamically generated each time a request occurs.

[0138] [Modification 2 of Method 1: Example of Conversion Processing by Hybridcast Content Conversion Unit 291] There are various specific details of the process by which the hybridcast content conversion unit 291 converts the hybridcast content into a web resource that can be used on the client terminal device 3 side, but an example will be described here.

[0139] As mentioned above, the receiving terminal device 2 is a television receiver. In other words, a hybridcast browser runs on the receiving terminal device 2. In this method, the hybridcast content conversion unit 291 converts tags so that the content output by the hybridcast application can be used in a general web browser (for example, Chrome, etc.). The hybridcast application converts tags, for example, as tags for displaying broadcast content. <object>The hybridcast content conversion unit 291 uses this tag. <object>Tag <video>This allows the browser running on the client terminal device 3 to <video>Videos provided by tags can be presented to viewers.

[0140] Furthermore, the API for the Hybridcast browser provided by the Hybridcast app may be converted so that it can be used in a general web browser by the Hybridcast content conversion unit 291. Although the Hybridcast app is originally intended to run in the Hybridcast browser, converting the API in this way makes the Hybridcast app usable in a general web browser.

[0141] For example, in the API of a Hybridcast application (such as obtaining a postal code), the response data may be sent as text data from the receiving terminal device 2 to the client terminal device 3 using the sendtext function in the Hybridcast terminal linkage function.

[0142] [Modification 3 of Method 1: Conversion process of hybridcast content on the client terminal device 3 side] In the above, the content converted by the hybridcast content conversion unit 291 in the receiving terminal device 2 is transmitted from the receiving terminal device 2 to the client terminal device 3. In this modified example, the hybridcast content is not converted on the receiving terminal device 2 side. The receiving terminal device 2 transmits the content data output by the hybridcast application to the client terminal device 3 as is. The client terminal device 3 side is provided with a conversion processing function similar to that of the hybridcast content conversion unit 291 in the receiving terminal device 2 already explained. Then, the hybridcast content conversion processing is performed on the client terminal device 3 side. This makes it possible to use the hybridcast content on the client terminal device 3 side.

[0143] [Modification 4 of Method 1: Use the Hybridcast app that can be used with a general web browser] In this modification, the receiving terminal device 2 does not have a hybridcast content conversion unit 291. Instead, in this modification, a hybridcast application that can be used with a general web browser (such as Chrome) is prepared in advance. A server device that provides the hybridcast application to the receiving terminal device 2 provides a hybridcast application that can be used with a general web browser instead of a normal hybridcast application. The receiving terminal device 2 acquires the hybridcast application that can be used with a general web browser from the server device and runs it. This makes it possible to use hybridcast content on the client terminal device 3 side.

[0144] [Method 2: Utilizing Hybridcast content via Hybridcast's device linkage function (Part 2: Another functional extension of Hybridcast's device linkage function)] In this method, by extending the terminal linking function of Hybridcast, it is possible to launch Hybridcast content from the client terminal device 3. In this method, when the client terminal device 3 calls the API for the channel selection / HC application launch request (step S109 (request) in Fig. 4), it is possible to specify "mode=web" as a query parameter.

[0145] Fig. 9 is a schematic diagram showing an API for a hybridcast application launch request from a client terminal device 3 in this technique. As shown in the figure, the URL and method for calling this API are the same as those shown in Fig. 6. However, the API shown in Fig. 9 specifies "mode=web" as an extended query. By acquiring this query parameter "mode=web," the receiving terminal device 2 receiving such a request can explicitly understand that the request from the client terminal device 3 is for the use of hybridcast content on the web.

[0146] In this method, the data transmitted when the client terminal device 3 makes a request to the receiving terminal device 2 may be the same as the data described with reference to FIG.

[0147] [Method 3: Utilizing Hybridcast content via Hybridcast's device linkage function (Part 3: New API in Hybridcast's device linkage function)] This method makes it possible to use a new API for a request from the client terminal device 3 to the receiving terminal device 2 to start up a Hybridcast application.

[0148] FIG. 10 is a schematic diagram showing an API for requesting activation of a hybridcast application from the client terminal device 3 to the receiving terminal device 2 for use on the web platform. As shown in the figure, a new API called "webhybridcast" is available from the client terminal device 3 side. The URL of this API is " <baseurl> / webhybridcast". The method for calling this API is POST.

[0149] 11 is a schematic diagram showing an example of data transmitted from the client terminal device 3 to the receiving terminal device 2 when requesting the launch of a hybridcast application for use on a web platform via the API of the present technique. As shown in the figure, this data also has a "resource" block (lines 2 to 6) and a "hybridcast" block (lines 7 to 11). As described above, the "resource" block has information identifying the broadcast service to be selected (transport stream ID (transport_stream_id), original network ID (original_network_id), service ID (service_id)). The "hybridcast" block includes location information (URL) of the URL of the hybridcast AIT (application information table) described above.

[0150] [Method 4] Querying the server device that determines whether the Hybridcast app can be launched In this method, the receiving terminal device 2 in the system 1 is enabled to make an inquiry to the AIT activation possibility determination server device 11. The AIT activation possibility determination server device 11 provides the receiving terminal device 2 with information indicating in what form the specified hybridcast application program can be run.

[0151] Specifically, the system 1 operates in the following procedure. The client terminal device 3 requests the receiving terminal device 2 to start a hybridcast application. The method of the request from the client terminal device 3 may be any of methods 1 to 3 described above. When the receiving terminal device 2 receives the request from the client terminal device 3, it inquires of the AIT start-up feasibility determination server device 11 as to whether or not the hybridcast application can be started. In response to this, the AIT start-up feasibility determination server device 11 replies to the receiving terminal device 2 that originated the inquiry with information on whether or not the hybridcast application can be started. In response to the response from the AIT start-up feasibility determination server device 11, the receiving terminal device 2 decides whether or not to start the hybridcast application requested by the client terminal device 3.

[0152] If the receiving terminal device 2 receives a response from the AIT activation possibility determination server device 11 indicating that activation is not possible, the receiving terminal device 2 does not activate the hybridcast application in that form. In this case, the receiving terminal device 2 may, if necessary, report some kind of error as a processing result to the client terminal device 3 that requested activation of the hybridcast application in that form.

[0153] If a response indicating that the hybridcast application can be started is received from the AIT start possibility determination server device 11, the receiving terminal device 2 starts the hybridcast application in that form. In this case, the receiving terminal device 2 may, as necessary, report normal completion or a similar result as the processing result to the client terminal device 3 that requested the start of the hybridcast application in that form.

[0154] FIG. 12 is a schematic diagram showing an example of an interface for transmitting a request from the receiving terminal device 2 to the AIT activation feasibility determination server device 11 in this technique. As shown in the figure, this request inquires about whether or not a Hybridcast application can be activated, and the method is GET. The URL of this request includes the URL of the AIT activation feasibility determination server device 11 and a query string. The receiving terminal device 2 creates this query string based on the content of the Hybridcast application activation request received from the client terminal device 3. In the example shown in the figure, the query string is "transport_stream_id=32736&original_network_id=32736&service_id=1024&aiturl=https%3A%2F%2Fexample.com%2Fait.xml&orgid=16&appid=5." In other words, this query string corresponds to the data of the channel selection / Hybridcast application activation request exemplified in FIGS. 7 and 11. As described above, the query string specifically specifies the transport stream ID, the original network ID, the service ID, the URL of the AIT, the ORGID, and the APPID.

[0155] FIG. 13 is a schematic diagram showing an example of response data from the AIT activation possibility determination server device 11 to the receiving terminal device 2 in response to the request (inquiry) of FIG. 12. As shown in the figure, this data has a header ("head") block (lines 2 to 5) and a body ("body") block (lines 6 to 9). The body block has information on whether or not the data can be activated as a normal hybridcast application (not output as web content) and information on whether or not the data can be activated as a hybridcast application output for the web. In the example shown here, the data indicated with the label "hybridcast" is "OK". This indicates that activation as a normal hybridcast application is possible. Also, the data indicated with the label "webhybridcast" is "OK". This indicates that activation as a hybridcast application output as a web resource is possible.

[0156] As in the above example, the AIT launch feasibility determination server device 11 transmits to the receiving terminal device 2 information on whether the hybridcast app specified by the parameters can be launched as a normal hybridcast app and whether it can be launched as a web hybridcast app.

[0157] [Modification 1 of Method 4: AIT Startup Determination Server Device] The AIT activation possibility determination server device 11 used in Method 4 transmits both information on whether or not an application can be activated as a normal hybridcast application and information on whether or not an application can be activated as a web hybridcast application to the receiving terminal device 2. As a variation, the AIT activation possibility determination server device that returns information on whether or not an application can be activated as a normal hybridcast application to the receiving terminal device 2 and the AIT activation possibility determination server device that returns information on whether or not an application can be activated as a web hybridcast application to the receiving terminal device 2 may be separately provided or hosted. In this case, these two types of AIT activation possibility determination server devices are each accessed by their own unique URLs. The receiving terminal device 2 can make an inquiry to either or both of the AIT activation possibility determination server devices as needed.

[0158] [Variation 2 of Method 4: Using a parameter keyword in the query string to distinguish between a query to launch a normal Hybridcast app and a query to launch a Web-based Hybridcast app] In the second variation of the fourth method, a keyword in the query string is used to distinguish between an inquiry about a normal hybridcast application and an inquiry about a web hybridcast application.

[0159] FIG. 14 is a schematic diagram showing an example of an interface for transmitting a request from the receiving terminal device 2 to the AIT activation possibility determination server device 11 in this modified example. In the example of the request (query) shown in FIG. 12, the keyword for the parameter specifying the URL of the AIT is "aiturl." On the other hand, in the example of the request shown in FIG. 14 of this modified example, the URL of the AIT is specified by the keyword "webaiturl." That is, the character string in question is "···webaiturl=https%3A%2F%2Fexample.com%2Fait.xml···." As in this example, the URL specified using the keyword "webaiturl" is the URL of the AIT that is the target of an inquiry about whether it can be activated as a web-based hybridcast application. Note that when the keyword "aiturl" is specified, the query is an inquiry about a normal hybridcast application.

[0160] FIG. 15 is a schematic diagram showing an example of response data returned by the AIT activation possibility determination server device 11 in response to the request of FIG. 14. As shown in the figure, the data of this response has only a header ("head") block. The response in this example has the code ("code") value "200" and the message ("message") value "OK" as the contents written in the header. The response data indicates that the Hybridcast application can be activated. If activation is not possible, the AIT activation possibility determination server device 11 returns data indicating that activation is not possible as a response.

[0161] In this modification, whether the inquiry is about a normal application or a web application is clearly indicated by a keyword at the time of inquiry from the receiving terminal device 2. This allows the response data returned by the AIT activation feasibility determination server device 11 to be data with a simple structure.

[0162] [Method 5: Utilizing hybridcast content based on broadcast signals (Part 1)] In this method, instead of specifying the location information (URL) of the AIT from the client terminal device 3 side, hybridcast content based on the location information of the AIT included in the broadcast signal can be utilized on the client terminal device 3 side.

[0163] Specifically, the process is as follows: The broadcast signal received by the receiving terminal device 2 includes the URL of the AIT for launching the hybridcast application. Such an application is also called a broadcast-managed application. The receiving terminal device 2 has already completed pairing with the client terminal device 3 through a predetermined procedure of the hybridcast device linkage function. That is, the receiving terminal device 2 is linked with the client terminal device 3. In this situation, the client terminal device 3 requests the receiving terminal device 2 to launch the hybridcast application using the sendtext (text transmission) function of the hybridcast device linkage function. Sendtext is one of the functions provided by websocket (bidirectional linked device communication) of the hybridcast device linkage function. The request data from the client terminal device 3 does not include location information of the AIT of the hybridcast application. That is, the client terminal device 3 requests the receiving terminal device 2 to launch the hybridcast application based on the location information of the AIT extracted by the receiving terminal device 2 from the broadcast signal.

[0164] In response to the request from the client terminal device 3, the receiving terminal device 2 acquires an AIT based on the URL extracted from the broadcast signal and starts the hybridcast application using the AIT. The hybridcast content conversion unit 291 of the receiving terminal device 2 converts the output from the hybridcast application into a form usable on the web platform. The web resource providing unit 262 uses the sendtext function to send a URL for accessing the hybridcast application to the client terminal device 3. This allows the client terminal device 3 to use the hybridcast content using the web platform.

[0165] As described above, in this method, the client terminal device 3 requests the receiving terminal device 2 to launch a hybridcast application using the linked terminal communication function. However, the client terminal device 3 does not need to transmit location information of the AIT. Furthermore, the receiving terminal device 2 launches the hybridcast application and transmits URL information for using the content to the client terminal device 3 using the linked terminal communication function.

[0166] [Method 6: Utilizing hybridcast content based on broadcast signals (part 2)] In this method, similar to the above-described method 5, the receiving terminal device 2 starts the Hybridcast application based on the location reception method of the AIT acquired from the broadcast signal. However, in this method, the client terminal device 3 uses a request to start the Hybridcast application of the Hybridcast terminal cooperation function.

[0167] Specifically, it is as follows: The broadcast signal received by the receiving terminal device 2 includes the URL of the AIT for launching the Hybridcast application. Furthermore, the receiving terminal device 2 has already completed pairing with the client terminal device 3 through a predetermined procedure of the Hybridcast terminal linkage function. In this situation, the client terminal device 3 requests the receiving terminal device 2 to launch the Hybridcast application via the API of the Hybridcast terminal linkage function. This is a launch request with "mode=app". The API for this launch request has been described with reference to FIG. 6.

[0168] Fig. 16 is a schematic diagram showing an example of data transmitted from the client terminal device 3 to the receiving terminal device 2 when a request to start the above-mentioned hybridcast application is made. As shown in the figure, this data is composed of the same data items as the data shown in Fig. 7. However, in the data shown in Fig. 16, the URL of the AIT ("aiturl") is not stored, and is a null character string. Note that when a specific character string or the like is designated as the URL ("aiturl") instead of a null character string, location information of the AIT acquired from a broadcast signal may be used.

[0169] When the data shown in FIG. 16 is received from the client terminal device 3, the receiving terminal device 2 selects the broadcast service identified by the broadcast resource information ("resource") indicated by this data. While receiving the broadcast service, the receiving terminal device 2 can extract the information of the URL of the AIT from the broadcast signal. Meanwhile, the URL of the AIT specified in the data shown in FIG. 16 is a null character string. Therefore, the receiving terminal device 2 starts the hybridcast application based on the URL of the AIT obtained from the broadcast signal.

[0170] In addition, with respect to matters other than those explained in Method 6, the system 1 operates in accordance with Method 5 described above.

[0171] [Method 7: Utilizing Hybridcast Content Based on Broadcast Signals (Part 3: Expanding the API for Hybridcast Device Linkage Functions)] This method is a modified example of Method 6. That is, in this method, when the client terminal device 3 requests the receiving terminal device 2 to start a Hybridcast application, “mode=web” can be explicitly specified as a query parameter.

[0172] 17 is a schematic diagram showing an API used by the client terminal device 3 to request the receiving terminal device 2 to launch a hybridcast application in this technique. As shown in the figure, this API specifies "mode=web" as an extended query. By acquiring the query parameter "mode=web," the receiving terminal device 2 receiving such a request explicitly understands that the request from the client terminal device 3 is for the use of hybridcast content on the web.

[0173] Other points in Method 7 are the same as Method 6. That is, the client terminal device 3 does not explicitly state the location information of the AIT in the request to the receiving terminal device 2. The receiving terminal device 2 starts the hybridcast application based on the location information of the AIT included in the broadcast signal.

[0174] [Method 8: Utilizing Hybridcast Content Based on Broadcast Signals (Part 4: New API for Hybridcast Device Linkage Function)] This method is a variation of Method 6. In this method, a new API is used to request the client terminal device 3 to start a Hybridcast application to the receiving terminal device 2. This new API is an interface that can be used between the receiving terminal device 2 and the client terminal device 3 that are linked by the Hybridcast terminal linking function.

[0175] FIG. 18 is a schematic diagram showing an API for the client terminal device 3 to request the receiving terminal device 2 to start up a hybridcast application in this method. As shown in the figure, in this method, a new API called "webhybridcast" is available from the client terminal device 3 side. The URL of this API is " <baseurl> / webhybridcast". The method for calling this API is POST.

[0176] Other points in Method 8 are the same as Methods 6 and 7. That is, the client terminal device 3 does not explicitly state the location information of the AIT in the request to the receiving terminal device 2. The receiving terminal device 2 starts the hybridcast application based on the location information of the AIT included in the broadcast signal.

[0177] [Method 9: Utilizing Hybridcast Content Based on Broadcast Signals (Part 5: Inquiry to the Server Device for Determining Whether or Not to Start)] This method is a modified example of any of methods 5 to 8. That is, in addition to the processing of any of methods 5 to 8, this method enables the receiving terminal device 2 to make an inquiry to the AIT activation feasibility determination server device 11. The AIT activation feasibility determination server device 11 provides the receiving terminal device 2 with information indicating in what form the specified hybridcast application program can be run.

[0178] The function of the AIT activation possibility determination server device 11 is the same as that of the above-described method 4. Furthermore, the procedure of the request (inquiry) from the receiving terminal device 2 to the AIT activation possibility determination server device 11 and the response thereto are also the same as those explained in method 4. That is, the receiving terminal device 2 inquires of the AIT activation possibility determination server device 11 about whether or not a normal hybridcast application and / or a web hybridcast application can be activated. In response, the AIT activation possibility determination server device 11 transmits activation possibility information to the receiving terminal device 2. The receiving terminal device 2 determines whether or not to activate a hybridcast application based on the activation possibility information received from the AIT activation possibility determination server device 11.

[0179] [Method 10: Extending the API for acquiring launch availability status (launch availability status of Hybridcast apps provided as web resources)] In this method, by extending the launch availability status acquisition API (steps S111 and S112 in Figure 4), the client terminal device 3 is able to receive the launch availability status of a hybridcast application provided as a web resource from the receiving terminal device 2.

[0180] In this method, the client terminal device 3 makes a request to the receiving terminal device 2 by calling the activation permission status acquisition API. The URL for making the request is <baseurl>The request is " / hybridcast". The method is GET. As a result, the receiving terminal device 2 receives a request to acquire the launch status. The feature of this method is that the receiving terminal device 2 returns the launch status of the web hybridcast application ("webhybridcast" below) to the client terminal device 3.

[0181] FIG. 19 is a schematic diagram showing an example of response data sent from the receiving terminal device 2 to the client terminal device 3 in the launch availability status acquisition API extended by this technique. As shown in the figure, this response data has a header ("head") block (lines 2 to 5) and a body ("body") block (lines 6 to 22). The body ("body") data includes a task ID ("taskid"), the launch availability status of a normal hybridcast app ("hybridcast"), and the launch availability status of a web-based hybridcast app ("webhybridcast"). The launch availability status of the normal hybridcast app and the launch availability status of the web-based hybridcast app are launch availability status data returned by the receiving terminal device 2 to the client terminal device 3. The launch availability status of the normal hybridcast app and the launch availability status of the web-based hybridcast app each include a status ("status"), a code ("code"), and a message ("message").

[0182] In this example, the status of whether or not a normal Hybridcast application can be launched is "NoProcess" and the code is "500." This indicates that the normal Hybridcast application cannot be launched. Also, the status of whether or not a Web-based Hybridcast application can be launched is "Done" and the code is "200." This indicates that the Web-based Hybridcast application can be launched.

[0183] As explained above, in this method, the activation availability status acquisition API is extended, so that the client terminal device 3 can acquire the activation availability status of a web-based hybridcast application.

[0184] [Method 11: New API for obtaining the launch status of a Hybridcast app provided as a web resource] In the above method 10, an existing API is extended so that the client terminal device 3 receives the launch availability status of a hybridcast application provided as a web resource from the receiving terminal device 2. In contrast, in the present method, a new API for the hybridcast terminal linkage function is provided to obtain the launch availability status of a hybridcast application provided as a web resource.

[0185] FIG. 20 is a schematic diagram showing the API of the Hybridcast terminal linkage function that can be used in this technique. This API is used by the client terminal device 3 to obtain the activation status of the Hybridcast application for web resources from the receiving terminal device 2. The client terminal device 3 can obtain the activation status using the API in FIG. 20 instead of the activation status acquisition procedure shown in steps S111 and S112 in FIG. 4. As shown in the figure, the URL of this API is " <baseurl> / webhybridcast" and the method is GET.

[0186] FIG. 21 is a schematic diagram showing an example of response data returned by the receiving terminal device 2 in response to the request from the client terminal device 3 shown in FIG. 20. As shown in the figure, the response data has a header ("head") block (lines 2 to 5) and a body ("body") block (lines 6 to 15). The body ("body") data includes a task ID ("taskid") and a launchability status ("webhybridcast") of the web hybridcast application. The launchability status of the web hybridcast application includes a status ("status"), a code ("code"), and a message ("message"). In the example shown, the status is "Done," the code is "200," and the message is "OK." This data indicates that the web hybridcast application can be launched. If the web hybridcast application cannot be launched, the status takes values ​​such as "NoProcess" and the code is "500."

[0187] As explained above, this method uses a dedicated API for inquiring about the launch status of a web-based Hybridcast application. This allows the response data returned from the receiving terminal device 2 to the client terminal device 3 to have a simple structure.

[0188] [Method 12: Extending the receiver status acquisition API (status of Hybridcast application provided as a web resource)] In this method, the receiver status acquisition API of the hybridcast terminal linkage function (steps S113 and S114 in Figure 4) is extended to enable the client terminal device 3 to acquire the startup status of the hybridcast application provided as a web resource.

[0189] FIG. 22 is a schematic diagram showing an example of response data sent from the receiving terminal device 2 to the client terminal device 3 in the API (receiver status acquisition) extended by this technique. As shown in the figure, this response data has a header ("head") block (lines 2 to 5) and a body ("body") block (lines 6 to 17). The body data includes receiver status data for a normal hybridcast app (labeled "hybridcast") and receiver status data for a web hybridcast app (labeled "webhybridcast"). In this data example, the receiver status for the normal hybridcast app is "NotStarted," which means that the app is not running (nothing). Furthermore, the receiver status for the web hybridcast app is "Running," which means that the app is running and in operation. The status block (lines 7 to 16) in the body ("body") contains the above two pieces of data indicating the running status of the app, as well as data on companion apps ("companion_apps") and resources ("resource"). The resource data is information that identifies the broadcast service tuned in by the receiving terminal device 2.

[0190] [Method 13: New API for obtaining the running status of Hybridcast apps provided as web resources] In the above method 11, the state of the web-based hybridcast application is passed from the receiving terminal device 2 to the client terminal device 3 by extending an existing API. In this method, a new API for the hybridcast terminal linkage function is used. In other words, in this method, instead of extending the existing API, a new API is used for the client terminal device 3 to obtain the state of the web-based hybridcast application.

[0191] FIG. 23 shows the API between the client terminal device 3 and the receiving terminal device 2 used in this method. FIG. 1 is a schematic diagram showing a new API. The client terminal device 3 can call this API to inquire of the receiving terminal device 2 about the running status of a hybridcast application provided as a web resource. As shown in the figure, the URL of this API is " <baseurl>4. The API is " / webstatus". The method for calling this API is GET. The client terminal device 3 can call the API of this method instead of the procedure shown in steps S113 and S114 of FIG.

[0192] FIG. 24 is a schematic diagram showing an example of response data sent from the receiving terminal device 2 to the client terminal device 3 in the API shown in FIG. 23 above. As shown in the figure, this response data has a header ("head") block (lines 2 to 5) and a body ("body") block (lines 6 to 16). The body data has status ("status") data. One of the elements of the status data is data on the startup status ("status") of the web hybridcast app. In the example shown in this figure, the startup status value of the web hybridcast app is "Running," which indicates that the web hybridcast app has been started and is running. If the web hybridcast app is not started (there is nothing), the startup status value of the web hybridcast app is, for example, "NotStarted."

[0193] 24 also includes data on companion apps ("companion_apps") and resources ("resources"). The resource data is information that identifies the broadcast service selected by the receiving terminal device 2.

[0194] As explained above, this method makes it possible to use a new API for the Hybridcast terminal linkage function. This API can be used by the client terminal device 3 to obtain information on the running status of the Hybridcast application of the web resource from the receiving terminal device 2.

[0195] As described above, the receiving terminal device 2 and the client terminal device 3 perform processing using any one of methods 1 to 13. Note that the receiving terminal device 2 and the client terminal device 3 may perform processing using a combination of two or more of methods 1 to 13.

[0196] FIG. 25 is a block diagram showing an example of the internal configuration of each device (receiving terminal device 2, client terminal device 3, and other necessary server devices, etc.) constituting 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, RAM 902, input / output port 903, input / output devices 904, 905, etc., and bus 906. The computer itself can be realized using existing technology. The central processing unit 901 executes instructions contained in a program read from RAM 902, etc. In accordance with each instruction, the central processing unit 901 writes data to RAM 902, reads data from RAM 902, and performs arithmetic and logical operations. RAM 902 stores data and programs. Each element contained in 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, etc. 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.

[0197] 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.

[0198] [Variation A] In the embodiment described above, the receiving terminal device 2 includes the transcoding unit 261. The transcoding unit 261 converts video and audio extracted from a broadcast signal into web resources in a format usable by a web platform. However, as a modified example, the receiving terminal device 2 may not include the transcoding unit 261. Even in such a configuration, the client terminal device 3 can request the receiving terminal device 2 to start an application (hybridcast application). Furthermore, the receiving terminal device 2 can output an application (content data) based on the start request, and the application can be used on the client terminal device 3 side. Furthermore, video and audio distributed via communication other than broadcasting can be combined with the output from the application and used on the client terminal device 3 side.

[0199] [Variation B] In the modification B, the application does not require conversion by the hybridcast content conversion unit 291 in order to run on the client terminal device 3. In other words, this application does not use a function that can only be used on the receiving terminal device 2.

[0200] In Modification B, too, the web resource providing unit 262 of the receiving terminal device 2 enables the client terminal device 3 to acquire an application identified based on a broadcast signal received by the receiving terminal device 2. As an example, the web resource providing unit 262 transmits, via communication, an application information table (AIT) acquired based on the received broadcast signal to the linked client terminal device 3. Alternatively, the web resource providing unit 262 may transmit, via communication, location information (such as a URL) of the application information table identified based on the received broadcast signal to the linked client terminal device 3. In either of these cases, the client terminal device 3 can acquire the application information table via communication. Then, the client terminal device 3 can ascertain location information of the application code itself from the acquired application information table and acquire the application.

[0201] As described above, in this embodiment (including the modified example), the client terminal device 3 cooperates with the receiving terminal device 2. Furthermore, the client terminal device 3 requests the receiving terminal device 2 to start an application. Furthermore, the receiving terminal device 2 converts the application into an application in a format usable on the web platform and transmits it to the client terminal device 3. In other words, the client terminal device 3 can use applications usable on the web platform.

[0202] 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]

[0203] 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]

[0204] 1 System 2. Receiving terminal device (receiving device) 3. Client terminal device 4 Antennas 8. Router 9. Communication Networks 11 AIT startup determination 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 281 Data Analysis Department 282 Event Processing Unit 291 Hybridcast Content Conversion Unit 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> < / video> < / video> < / object> < / object> < / baseurl> < / baseurl> < / video> < / object>

Claims

1. a receiving unit for receiving a broadcast signal; a web resource providing unit that transmits, via communication, to a client terminal device as a cooperating destination, at least one of an application information table acquired based on the received broadcast signal and location information of the application information table based on the received broadcast signal; a content conversion unit that converts the application identified by the application information table into an application that can be used on a web platform; A receiving device comprising:

2. an application control unit that controls the operation of an application identified by the application information table; The receiving device according to claim 1 , further comprising:

3. the web resource providing unit instructs the application control unit to start the application based on an application start request transmitted from a client terminal device as a cooperation destination, and transmits the application usable on the web platform, which is a result of conversion by the content conversion unit, to the client terminal device via communication.

3. The receiving device according to claim 2.

4. a transcoding unit that transcodes at least one of the data of the video resource and the audio resource extracted from the received broadcast signal into data in a format usable by a web platform and outputs the data as a web resource; Furthermore, the web resource providing unit transmits the web resource output by the transcoding unit to the client terminal device via communication.

4. The receiving device according to claim 3.

5. the web resource providing unit instructs the application control unit to launch the application identified by information included in the application launch request from the client terminal device; 5. The receiving device according to claim 3 or 4.

6. the web resource providing unit instructs the application control unit to launch the application identified by information included in the broadcast signal received by the receiving unit; 6. A receiving device according to any one of claims 3 to 5.

7. When the application control unit receives an instruction from the web resource providing unit to start the application based on the application start request transmitted from the client terminal device, the application control unit inquires of an external start-up possibility determination server device, and determines whether to transmit an application available on the web platform to the client terminal device based on a response from the start-up possibility determination server device.

7. A receiving device according to any one of claims 3 to 6.

8. the web resource providing unit transmits data on the launchability status of the application available on the web platform to the client terminal device in response to a request for acquisition of the launchability status from the client terminal device; 8. A receiving device according to any one of claims 3 to 7.

9. the web resource providing unit transmits receiver status data for applications available on the web platform to the client terminal device in response to a request for receiver status acquisition from the client terminal device; 9. Receiving device according to any one of claims 3 to 8.

10. a receiving terminal cooperation control unit that transmits an application startup request for an application output by the content conversion unit of the receiving device according to claim 1 to the receiving device, and receives from the receiving device an application that is usable on a web platform and is the result of conversion by the content conversion unit; A client terminal device comprising:

11. an application engine that runs a web application that receives and uses the web resource output by the transcoding unit of the receiving device according to claim 4; Furthermore, The receiving terminal cooperation control unit executes a process required for using the web resource as a cooperative operation with the receiving device by a terminal cooperation function of Hybridcast.

11. The client terminal device according to claim 10.

12. the receiving terminal cooperation control unit transmits, together with the application activation request, information specifying the application to be activated to the receiving device; 12. A client terminal device according to claim 10 or 11.

13. When transmitting the application launch request, the receiving terminal cooperation control unit does not transmit information identifying the application to be launched to the receiving device, but requests the receiving device to identify the application to be launched based on information included in the broadcast signal received by the receiving device.

12. A client terminal device according to claim 10 or 11.

14. the receiving terminal cooperation control unit transmits a request for acquiring a launch status to the receiving device, and receives data on the launch status of the application from the receiving device; A client terminal device according to any one of claims 10 to 13.

15. the receiving terminal cooperation control unit transmits a request for acquiring a receiver status to the receiving device, and receives data on the receiver status of the application from the receiving device; A client terminal device according to any one of claims 10 to 14.

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

17. Computer, A client terminal device according to any one of claims 10 to 15. A program to function as a

Images