JP5349660B2 - Digital broadcast receiver and digital broadcast receiving system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a receiver which prevents a user from being confused. <P>SOLUTION: A receiver 100 realizes a function with a download application acquired via a network and a built-in application. A menu management part 62 of the receiver 100 determines whether management information of the download application is received or not and controls a display of a predetermined function on the built-in menu to be executed by the built-in application. The predetermined function is common to the download application and the built-in application. The menu management part 62 controls a display of the built-in menu so that the predetermined function cannot be displayed on the built-in menu when the management information is received and the predetermined function can be displayed on the built-in menu when management information is not received. <P>COPYRIGHT: (C)2013,JPO&amp;INPIT

Description

  The present invention relates to a receiver for digital broadcasting such as cable broadcasting, and more particularly to a receiver that realizes various functions based on a built-in application and a downloaded application.

  In recent years, digitalization has progressed also in cable broadcasting, and various services are provided. Various technologies have been developed as such cable broadcast receivers (see, for example, Patent Document 1). OCAP (Open Cable Application Platform) has been proposed as a standard for next-generation cable broadcasting for North America.

  According to OCAP, receivers such as STB (Set Top Box) can download various applications (Java applications) such as electronic program guide (EPG) and VOD (Video on Demand) viewing applications from broadcasting stations. A predetermined function is realized by executing the downloaded application based on an API (Application Program Interface) determined by the OCAP standard. In other words, the receiver only operates based on the determined API, and does not recognize a specific function realized by the download application.

  Such a receiver checks whether or not a download application or the like periodically transmitted from the station side is distributed when the power is turned on, and executes the download application if distributed.

  The receiver holds an originally installed application (hereinafter referred to as “built-in application”) in addition to the download application transmitted from the station side. When there is no download application, the receiver executes a function according to the built-in application.

JP-T-2006-511106

  Important functions such as subtitle setting and password setting may be provided in both the menu by the OCAP application and the menu by the built-in application. Thus, when the same function exists between the two menus, the user can It is confusing to decide which menu should be used.

  The present invention has been made to solve the above-described problems, and it is an object of the present invention to provide a receiver that prevents user confusion.

  In the present invention, there is provided a digital broadcast receiver that realizes functions by a download application and a built-in application acquired via a network. The digital broadcast receiver according to the first aspect includes a determination unit that determines whether or not management information of a download application has been received, and menu management that controls display of a predetermined function on a built-in menu executed by the built-in application. A section. The predetermined function is a function common to the download application and the built-in application. When the management information is received by the determination unit, the menu management unit does not display the predetermined function on the built-in menu. When the management information is not received by the determination unit, the menu management unit displays the predetermined function on the built-in menu. Control the display of the built-in menu to display.

  ADVANTAGE OF THE INVENTION According to this invention, in a cable broadcasting receiver, a user's confusion can be prevented by controlling the display of a built-in menu.

  Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings.

1. Hardware Configuration of Receiver FIG. 1 is a diagram showing a hardware configuration of a receiver that receives a cable broadcast in the embodiment of the present invention. The receiver 100 is installed in a cable broadcasting station, and is connected to a server 200 that provides cable broadcasting via a cable 250. A cable card 300 for receiving cable broadcasting is inserted into the receiver 100. The receiver 100 receives user operation information (key code) via the remote controller 400 and performs processing according to the operation. The receiver 100 according to the present embodiment can receive a cable broadcast that conforms to the OCAP (Open Cable Application Platform) standard. In FIG. 1, a configuration for processing an audio signal is omitted for the sake of simplicity.

  The receiver 100 has a hardware configuration as shown in FIG. The display 11 displays the video reproduced by the built-in application or the OCAP application or the received video. The video memory 12 holds video data displayed on the display 11. The AV decoder 13 decodes the audio / video data distributed in the MPEG format or the like from the cable station. The TD decoder 14 filters a transport stream in which audio / video / data is multiplexed. The tuner 15 receives a signal distributed from a cable broadcasting station via a cable.

  The CPU 10 is a controller that controls the operation of the receiver 100. The CPU 10 is connected with a hard disk drive (HDD) 22, a volatile memory 20, and a cache memory 21 as a nonvolatile storage means as data storage means.

  The receiver 100 further includes a cable card interface 18 for exchanging data with the cable card 300 and a remote control receiver 19 for receiving a signal from the remote controller 400. The cable card 300 is a card for enabling broadcast reception from a specific cable broadcasting station.

  The receiver 100 further includes a cable modem 16 for connecting to the Internet via the cable 250 and an Ethernet chip 17 for transmitting and receiving Ethernet packets.

  The receiver 100 has a plurality of video / audio information input systems (input 1, input 2, input 3) in addition to information from cable broadcasting. Processing circuits 23 a to 23 c for processing video / audio signals are connected to each input, and one of the outputs of the processing circuits 23 a to 23 c is selected by the selector 24 and output to the display 11. In the receiver 100 of the present embodiment, any one of cable broadcasting and inputs 1 to 3 is selected by the CPU 10 based on a user operation and output to the display 11.

2. Functional Configuration of Receiver FIG. 2 shows a functional configuration of the receiver 100. The functional configuration shown in FIG. 2 is realized by the CPU 10 executing a predetermined program. In FIG. 2, only main functions are shown for convenience of explanation. It goes without saying that even if the function is not shown in FIG. 2, the function of the receiver 100 to be described later can be realized by the CPU 10 executing a predetermined program.

  As shown in FIG. 2, the receiver 100 includes applications installed at the time of shipment (hereinafter referred to as “built-in applications”) 51a and 51b, and applications obtained by downloading from a cable broadcasting station (hereinafter referred to as “OCAP applications”). 52a, 52b. The built-in application management unit 53 performs screen exclusion control and key distribution control for the built-in application. The OCAP application management unit 54 is middleware that executes the Java bytecode and the OCAP application, and also performs screen exclusive control and key distribution control of the OCAP application.

  The operation mode management unit 55 is a module that manages the operation mode of the receiver 100. The operation mode includes an operation mode for executing an OCAP application (hereinafter referred to as “OCAP mode”) and an operation mode for executing a built-in application (hereinafter referred to as “IDTV mode (or non-OCAP mode)”).

  The key distribution unit 56 is a module that distributes the key code received from the key driver 79 from the remote controller 400 to the built-in application management unit 53 or the OCAP application management unit 54.

  The cable card management unit 59 is a module that receives, manages, and executes requests from the cable card 300. The cable modem management unit 61 is a module for controlling the cable modem 16 such as DSG channel scan / DSG tunnel acquisition.

  The menu management unit 62 is a module that manages a setting menu presented by the OCAP application or the built-in application.

  The resource control unit 63 is a module for controlling control requests such as video output and audio output from applications for resources such as the display 11 and speakers.

  The file system 71 is a subsystem on the OS that manages a file system API (Open / close / write / ioctl, etc.) from the application to the OS (Operating System). A socket (SocketAPI) 72 is a subsystem that manages a network API from the application to the OS.

  The TCP 74 is a module that controls TCP communication requested from the socket 72. The UDP 73 is a module that controls UDP communication requested by the socket 72. The IP 75 is a module that controls transmission / reception of IP packets and routing of packets. The ether modules 76a and 76b are modules that control transmission and reception of ether packets. The filter 77 is a driver that distributes the Ethernet packet to the Ethernet module 76a or the Ethernet module 76b.

  The network driver 78 is a device driver that controls the Ethernet chip 17. The key driver 79 is a device driver that receives a key code transmitted from the remote controller 400. The cable card driver 80 is a device driver that controls transmission / reception of data from the cable card 300. The AV driver 81 is a device driver that decodes the AV stream in the AV decoder 13.

  The TD driver is a device driver that filters section data in the TD decoder 14. The drawing subsystem 82 is a subsystem that displays on the display 11 an image drawn by the OCAP application or the built-in application.

3. The various functions of the receiver 100 of the present embodiment will be described below with the function above configuration of the receiver.

3.1 Remote Control Key Delivery Control In the OCAP standard, remote control keys that can be used in an OCAP application are determined. Similarly, remote control keys that can be used in built-in applications are also determined. The remote control 400 has a menu key for starting a menu (hereinafter referred to as “built-in menu”) executed by a built-in application of the receiver 100. In such a situation, the remote control key for executing a predetermined function of the OCAP application and the remote control key for starting the built-in menu of the receiver 100 may be the same. In such a case, when the receiver 100 is operated in the OCAP mode, there is a problem that the built-in menu of the receiver 100 cannot be displayed using the remote controller 400.

  In order to solve the above problem, in this embodiment, the remote controller 400 is provided with a changeover switch so that the key code to be sent can be switched according to the operation mode. Furthermore, the receiver 100 is configured to change the delivery destination of the received key code according to the operation mode. This will be specifically described below.

  FIG. 3 shows the configuration of the remote control 400. The remote control 400 includes a control unit 41 that controls the operation thereof, an operation unit 42 that includes various operation keys that are operated by the user, and a key code sending unit 43 that transmits a key code. The operation unit 42 includes a menu key for starting a menu. The remote control 400 has a mode changeover switch 46, which enables transmission of a key code corresponding to the operation mode. The remote control 400 includes a normal key code holding unit 44 that holds a key code corresponding to the OCAP mode (hereinafter referred to as “normal key code”) and a key code corresponding to the IDTV mode (non-OCAP mode) (hereinafter referred to as “another key code”). And a separate key code holding unit 45 holding. Another key code may be generated by adding predetermined byte data (for example, “0A”) to the head of the normal key code corresponding to the function.

  When the mode switch 46 is on, the remote controller 400 transmits a normal key code corresponding to the OCAP mode. That is, the remote control 400 transmits a key code for the OCAP mode corresponding to the key operated by the user from the key code sending unit 43. On the other hand, when the mode switch 46 is off, the remote control 400 transmits another key code corresponding to the IDTV mode. That is, the remote control 400 transmits another key code corresponding to the key operated by the user from the key code sending unit 43.

  Next, the operation of the receiver 100 when receiving the key code from the remote controller 400 will be described with reference to FIG.

  When the user operates the remote control 400, the key code is transmitted from the remote control 400 to the receiver. When receiving the key code from the remote controller 400, the receiver 100 transmits the key code received by the key driver 79 to the key delivery unit 56.

  The key delivery unit 56 determines whether or not the operation mode of the receiver 100 is the OCAP mode (S11). If the operation mode is the OCAP mode, the key delivery unit 56 further determines whether or not the received key code is a “normal key code” that is a key code for OCAP (S12).

  If the received key code is a normal key code, the received key code is delivered to the OCAP application (S13). The OCAP application executes a function based on the received key code (S14).

  If the received key code is not a normal key code, the received key code is delivered to the built-in application (S15). The built-in application executes a function based on the received key code (S16).

  On the other hand, if the operation mode of the receiver 100 is not the OCAP mode in step S11, that is, if it is the IDTV mode, the key distribution unit 56 distributes the received key code to the built-in application (S15). The built-in application executes a function based on the received key code (S16).

  According to the above processing, for example, when the mode switch 46 is turned on and the menu key of the remote controller 400 is pressed, the OCAP mode key code (ordinary key code) is transmitted from the remote controller 400, so the OCAP application A menu is displayed. On the other hand, when the mode switch 46 is turned off and the menu key is pressed, a key code (another key code) for the IDTV mode is sent from the remote controller 400, so that the menu by the built-in application, that is, the built-in menu is displayed. . That is, if the mode changeover switch 46 of the remote controller 400 is turned off, the built-in menu of the receiver 100 can be displayed by remote control operation even when the receiver 100 is operating in the OCAP mode.

3.2 Display Control of Common Function on Built-in Menu When the receiver 100 operates in the IDTV mode, subtitle setting, PIN (PIN) setting, etc. are set from the built-in menu of the receiver 100.

  When operating in the OCAP mode, various functions are realized by an OCAP application created by a cable broadcaster (MSO). Since what kind of function is included in the OCAP application is determined by the cable broadcaster, the OCAP application does not necessarily support the above-described function for setting the subtitle and the code number.

  Subtitle setting and personal identification number setting are important functions, and these functions must be realized in the receiver 100. For this reason, the receiver 100 controls the display of the built-in menu so that caption setting and PIN setting can be executed during operation in the OCAP mode even when the OCAP application does not support such a function. There is a need to.

  FIG. 5A shows a display example of the built-in menu, and FIG. 5B shows a menu display example by the OCAP application. The built-in menu 500 includes an icon 501 selected by the user when setting the caption and an icon 503 selected when setting the password. Similarly, the menu 520 executed by the OCAP application includes an icon 521 that is selected when setting a caption and an icon 523 that is selected when setting a password. As shown in FIGS. 5A and 5B, important functions such as subtitle setting and password setting may be provided in both the menu 520 by the OCAP application and the menu 500 by the built-in application. Thus, when the same function exists between two menus, the user is at a loss as to which menu should be used and is confused.

  Therefore, in the receiver 100 of the present embodiment, the display of the built-in menu is controlled so that the display of functions that overlap between the OCAP application and the built-in application is not basically performed.

  Specifically, with respect to a predetermined function that can be displayed in common between the menu by the OCAP application and the built-in menu (hereinafter referred to as “common function”), basically, when the OCAP application is received, Do not display. However, the user can set whether or not to display the common function on the built-in menu when the OCAP application is received. Hereinafter, this setting is referred to as “common function display setting”. That is, a common function can be displayed on the built-in menu even when an OCAP application is received according to a user's request. This is because there is no problem if the user is not confused in the operation. On the other hand, when the OCAP application is not received, the common function is always displayed on the built-in menu.

  The display settings for common functions on the built-in menu will be described. FIG. 6A shows an example of a screen for setting display of common functions on the built-in menu. In the figure, the subtitle display setting is “ON”, and the password setting is “OFF”. These settings specify that when the receiver 100 can receive the OCAP application, the caption display is displayed on the built-in menu, but the password is not displayed on the built-in menu. The default value of the common function display setting is “OFF”. That is, when the receiver 100 can receive the OCAP application, basically, the common function is not displayed on the built-in menu, and the function is displayed only when the user requests it.

  In the present embodiment, whether or not the OCAP application has been received is determined based on whether or not an XAIT (Extended Application Information Table) has been received. Here, XAIT is download application management information transmitted from the cable broadcasting station, and includes information on the application storage location and the application to be started. The receiver 100 periodically receives XAIT from the server 200 of the cable broadcasting station.

  The receiver 100 controls the presence / absence of the display of the common function on the built-in menu according to the presence / absence of reception of XAIT and the display setting of the common function on the built-in menu. Table 1 shows the contents. As shown in Table 1, when XAIT can be received, display according to the display setting of the common function is performed. When the XAIT cannot be received, the common function is displayed on the built-in menu regardless of the content of the common function display setting.

  FIG. 7 shows a processing flow of the menu management unit 62 of the receiver 100 related to the above control. The menu management unit 62 determines whether XAIT has been received (S21). The reception of XAIT means that the receiver 100 can operate in the OCAP mode. In this case, two menus exist between the OCAP application and the built-in application, and the above-described problem of overlapping display of common functions may occur.

  If XAIT is received, check the display setting of the common function on the built-in menu. When the display setting is “OFF”, that is, when the function is set not to be displayed (executed) on the built-in menu, the display of the built-in menu is controlled so that the function is not displayed on the built-in menu. (S23). When the display setting is “ON”, that is, when the function is set to be displayed (executed) on the built-in menu, the display of the built-in menu is controlled so that the function is displayed on the built-in menu. (S24).

  If XAIT cannot be received, it means that the receiver 100 operates only in the IDTV mode. Therefore, in this case, it is required that subtitle setting and password setting can be performed on the built-in menu. Therefore, when the XAIT cannot be received, the display of the built-in menu is controlled so that each function is displayed on the built-in menu (S24). The above processing is performed for each common function.

  For example, when the display setting as shown in FIG. 6A is made for the subtitle setting and the password setting, when the XAIT is received, the icon for the subtitle setting as shown in FIG. 6B. 501 is displayed, and the built-in menu 500 in which the password 503 icon 503 is not displayed is displayed. On the other hand, when XAIT is not received, a built-in menu 500 in which an icon 501 for subtitle setting and an icon 503 for password setting are displayed as shown in FIG.

  By controlling the display of the built-in menu as described above, it is possible to eliminate duplicate display of functions displayed between the built-in menu and the menu by the OCAP application, prevent user confusion, and provide a user-friendly operating environment. .

3.3 Exclusive control of resources at the time of input source switching As shown in FIG. 1, the receiver 100 of this embodiment has a plurality of input systems (input 1, input 2, input 3) in addition to cable broadcasting. One input system (input source) is selected.

  In the receiver 100, when an input is switched from an input source that is executing an OCAP application such as VOD (Video On Demand) to another input source, the OCAP application that is being executed is not terminated in the background. Let it run continuously. Hereinafter, the process of executing the OCAP application in the background is referred to as “pause process”. The pause process is controlled by the OCAP application management unit 54. By this pause processing, it is possible to quickly execute the OCAP application when the input is switched to the original input source again.

  When the OCAP application is in the pause state, if the user operates a remote control key related to the OCAP application, the OCAP application may react to the key and output video or audio. Further, depending on the original specifications of the OCAP application running in the background, there may be a case where a control request (for example, a pop-up window display request) for resources such as video output and audio output is generated. In such a case, the use of resources such as the screen and audio is not arbitrated, and there is a possibility that video, audio, and the like are disturbed. Also, when operating an external input (PC / HDMI, etc.) or a built-in application such as Jpeg Viewer while operating an OCAP application in the background, resources such as screens and audio shared by multiple applications There is a possibility that video, audio, etc. will be distorted without mediation.

  In order to solve the above problem, the receiver 100 according to the present embodiment controls the OCAP application being executed to a pause state when the input is switched from the input source that is executing the OCAP application to another input source. In addition, in the pause state, control is performed so that the key code input from the outside and the resource control request generated inside are discarded (ignored). This will be described in detail with reference to FIG.

  FIG. 8 is a flowchart of resource exclusive control during input switching. When an input switching instruction is received from the input source that is executing the OCAP application to another input source, the input is switched (S31). Accordingly, the OCAP application is controlled to a pause state (S32).

  When the OCAP application is in the pause state, the OCAP application management unit 54 does not deliver the key code to the OCAP application even if the key code is input to the OCAP application from the remote controller 400 or the like (S33). In the pause state, even if the resource control unit 63 receives a resource control request from an OCAP application running in the background, the resource control unit 63 discards (ignores) the control request (S34).

  Thereafter, when the input source is switched to the original input source (S35), the pause process is terminated (S36). Thereafter, the delivery of the key code to the OCAP application and the control of resources from the OCAP application are performed as usual.

  By the above method, for example, even when the input is switched during VOD (Video On Demand) viewing by the OCAP application, the screen / audio is not disturbed, and the input is switched again to VOD viewing. When displayed, VOD can be displayed quickly.

3.4 High-speed start-up control when the power is turned on The receiver 100 executes the following processing after the main power is turned on until an EPG (program guide) application, which is one of the OCAP applications, is started.

(1) The receiver 100 receives a DSG (Docsis Set-up Gateway) mode instruction from the cable card 300 and requests the cable modem 16 to scan the DSG channel.
(2) The cable modem 16 completes the scan and transmits a DCD (Downstream Channel Descriptor) to the CPU 10.
(3) The CPU 10 sends a DCD to the cable card 300, receives the XAIT DSG tunnel Open request from the cable card 300, and instructs the cable modem 16.
(4) The CPU 10 sends the DSG tunnel packet received from the cable modem 16 to the cable card 300, and receives XAIT data from the cable card 300.
(5) The CPU 10 specifies a monitor application to be activated from the XAIT and activates it.
(6) The monitor application starts the EPG application.

  As described above, the receiver 100 needs to acquire XAIT in order to acquire activation information for activating EPG. Since it is necessary to execute various procedures for acquiring the XAIT, it takes time to acquire the XAIT, and as a result, it takes time to start the EPG.

  Therefore, the receiver 100 of the present embodiment stores the received XAIT in the nonvolatile cache memory 21 and starts up using the XAIT stored in the cache memory 21 when the main power is turned on. As a result, the XAIT acquisition time is shortened, and the time required for EPG activation is shortened. Hereinafter, this process will be described with reference to the flowcharts of FIGS.

  When the main power supply of the receiver 100 is turned on, it is determined whether or not XAIT is stored in the cache memory 21 (S51). If it is stored in the cache memory 21, the OCAP application described in XAIT is activated (S52). As described above, since XAIT can be acquired immediately after the main power is turned on, the time until the EPG is activated can be shortened.

  Here, when the main power supply of the receiver 100 is turned on, the procedures (1) to (4) described above are executed in parallel with the procedures shown in FIGS. It is running. After the main power is turned on, it is determined whether XAIT is received within a predetermined time (for example, within 10 seconds) (S53).

  If XAIT cannot be received within a predetermined time, the active OCAP application is terminated, the cache memory 21 is cleared (S54), and the built-in application is started (S55). This is because it is determined that the cable broadcast received by the receiver 100 does not support OCAP.

  If XAIT can be received within a predetermined time, it is determined whether or not the received XAIT is equal to the cached XAIT (S56). If both XAITs are equal, the process is terminated. This is because the XAIT used for startup is correct. If both XAITs are different, the received XAIT is stored in the cache memory 21 (S57). Thereafter, the active OCAP application is terminated, and the OCAP application described in the received XAIT is started (S58). This is because it is necessary to start the OCAP application using the correct XAIT.

  On the other hand, if XAIT is not stored in the cache memory 21 in step S51, it is determined whether or not XAIT is received within a predetermined time after the main power is turned on (S61). If the XAIT is received within the predetermined time, the received XAIT is stored in the cache memory 21 (S62), and the OCAP application described in the received XAIT is activated (S63). If the XAIT cannot be received within a predetermined time after the main power is turned on, the built-in application is activated (S64).

  As described above, the start-up waiting time of the EPG when the main power is turned on can be shortened by starting using the cached XAIT. In addition, it cannot be overemphasized that the starting time of not only EPG but another OCAP application can be shortened by the said method.

3.5 Communication Control According to the OCAP standard, both the OCAP application and the cable card 300 perform IP communication using different MAC addresses. Conventionally, there is an IP alias that realizes a plurality of IP addresses with one ether chip, but with this technology, it is not possible to assign separate MAC addresses.

  The receiver manages two IP addresses for the cable card and the OCAP application. Those IP addresses are addresses on the same network. Under this situation, when an IP packet is transmitted using a socket (SocketAPI), an OS (Operating System) assigns an IP address. In this case, there is a possibility that an IP address for the cable card is assigned to the packet transmitted by the OCAP application. In order to solve this problem, there is a method of explicitly assigning an IP address using a socket. In this case, the OCAP application needs to explicitly specify the IP address. However, since an OCAP application is provided by a cable broadcaster, it cannot be expected that the OCAP application is always designed to have such a specification.

  Hereinafter, a configuration for solving the above-described problems and performing IP communication by assigning separate MAC addresses to the OCAP application and the cable card with one Ethernet chip will be described.

  FIG. 11 is a diagram showing in more detail the configuration of the part related to the communication of the receiver 100 in relation to FIG.

  The receiver 100 has two IP addresses for the cable card 300 and the OCAP application. Those IP addresses are addresses on the same network.

  The Ethernet module 1 (76a) is a module for controlling transmission / reception of an Ethernet packet to the OCAP application 52. The Ethernet module 2 (76b) is a module for controlling transmission / reception of the Ethernet packet to / from the cable card 300.

  The reception of the Ethernet packet will be described. In this embodiment, the network driver 78 is set to a promiscuous mode and acquires all packets that pass through.

  The filter 77 acquires and manages the MAC address assigned to the OCAP application 52 and the MAC address assigned to the cable card 300 in advance. The filter 77 analyzes the headers of all the packets acquired by the network driver 78, and extracts a packet whose MAC address is equal to the MAC address of the OCAP application 52 or the MAC address of the cable card 300. Then, the filter 77 transmits a packet whose MAC address is equal to the MAC address of the OCAP application 52 to the Ethernet module 1 (76a). On the other hand, a packet whose MAC address is equal to the MAC address of the cable card 300 is transmitted to the Ethernet module 2 (76b). With this method, data of two types of MAC addresses can be received by one ether chip.

  Next, a method for assigning an IP address to data from the OCAP application 52 or the cable card 300 will be described.

  When the receiver 100 is activated, the DHCP client of the receiver 100 designates the MAC addresses of the OCAP application 52 and the cable card 300, inquires the DHCP server for the respective IP addresses, acquires the two acquired IP addresses, Register with the OS. The cable card 300 obtains its own IP address by inquiring of the OS.

  The routing management 83 sets the metric value of the IP address of the cable card 300 to a value larger than the metric value of the IP address of the OCAP application 52 in the routing table. In general, when an OS assigns an IP address, the OS assigns priority from an IP address having a small metric value. Therefore, by making the metric value of the IP address of the OCAP application 52 smaller than the metric value of the IP address of the cable card 300, the IP address of the OCAP application 52 is preferentially assigned.

  When transmitting data, the OCAP application 52 designates a transmission destination and sends the data to the OCAP communication unit 57 without designating its own IP address. The OCAP communication unit 57 sends the data to the socket 72 without specifying an IP address. Since no IP address is assigned to the data of the OCAP application 52, the OS assigns an IP address. At this time, since the metric value of the IP address of the OCAP application 52 is smaller than the metric value of the IP address of the cable card 300, the IP address of the OCAP application 52 assigned by the DHCP server is surely set by the OS. 52 data are allocated.

  On the other hand, since the cable card 300 has acquired an IP address from the OS, when the cable card 300 transmits data, the transmission destination and its own IP address are designated for the data and transmitted to the cable card communication unit 84. . The cable card communication unit 84 sends data to the socket 72. The data from the cable card 300 is not given an IP address by the OS because the IP address is explicitly designated.

  As described above, an IP address is assigned to the data of the OCAP application 52 by the OS, and the cable card 300 explicitly specifies its own IP address for the data of the cable card 300. Thus, an appropriate IP address is assigned to each data.

  With the above processing, one Ethernet chip can perform IP communication with a plurality of Mac addresses. The OCAP application can communicate with the correct IP address without being conscious of the IP address.

  In the above embodiment, an example in which a cable is used as a transmission medium for broadcast data has been described. The type of transmission medium to which the present invention can be applied is not limited to a cable. It goes without saying that the idea of the present invention can be applied to a receiver that receives broadcast data and that has a function realized by both a built-in application and a download application.

  In addition to the display device, there is an STB as a receiver to which the idea of the present invention can be applied.

  INDUSTRIAL APPLICABILITY The present invention is useful for receivers that receive broadcast data, such as STB receivers whose functions are realized by both built-in applications and download applications.

The figure which showed the hardware constitutions of the receiver which receives cable broadcasting in embodiment of this invention Diagram showing functional configuration of receiver Diagram showing the configuration of the remote control Flow chart showing processing of receiver when key code is received from remote control (A) The figure which shows an example of a built-in menu, (b) The figure which shows an example of the menu by an OCAP application (A) A figure showing an example of a screen for setting display of common functions on the built-in menu, (b) A figure showing a display example of the built-in menu when receiving XAIT, (c) A table of the built-in menu when not receiving XAIT Figure showing an example The flowchart which shows the process of the menu management part regarding the display control of the common function on the built-in menu Flow chart for exclusive control of resources during input switching Flow chart of processing at receiver startup Flow chart of processing at receiver startup The figure which showed the composition of the part which relates to the communication of the receiver in detail

17 Etherchip 10 CPU
DESCRIPTION OF SYMBOLS 11 Display 19 Remote control reception part 21 Cache memory 23a-23c Input 24 Selector 51a, 51b Built-in application 52a, 52b OCAP application 55 Operation mode management part 56 Key distribution part 62 Menu management part 63 Resource control part 77 Filter 83 Routing management part 100 Reception Machine 200 Office server 250 Cable 300 Cable card 400 Remote control

Claims (2)

A receiver that realizes the function by a download application and a built-in application acquired via a network,
A determination unit for determining whether the management information of the download application has been received;
A menu management unit that controls display of a predetermined function on a built-in menu executed by the built-in application,
The predetermined function is a function common to the download application and the built-in application,
When the management information is received by the determination unit, the menu management unit does not display the predetermined function on the built-in menu, and when the management information is not received by the determination unit, A receiver that controls display of the built-in menu so that a predetermined function is displayed on the built-in menu. The menu management unit further includes means for performing display setting indicating whether or not to display a predetermined function on the built-in menu executed by the built-in application on the built-in menu,
When the determination unit receives the management information, the display unit determines whether or not the predetermined function is displayed on the built-in menu according to the display setting, and the determination unit does not receive the management information. 2. The receiver according to claim 1, wherein display of the built-in menu is controlled so that all of the predetermined functions are displayed on the built-in menu regardless of the display setting.

Images