KR20110047687A - A broadcasting receiver and a method for monitoring a network device - Google Patents

Abstract

PURPOSE: A broadcasting receiver and a method for monitoring a network device are provided to offer the network state information in real time. CONSTITUTION: An application creates a listener instance(S1020). The application registers the listener instance(S1030). A middleware watches the state changes of a network device(S1040). If the state of the network device is changed, the middleware creates the event instance(S1050, S1060). The middleware transfers the event instance to a registered listener instance(S1070).

Description

A broadcasting receiver and a method for monitoring a network device}

The present invention relates to a broadcast receiver and a network device monitoring method, and more particularly, to a broadcast receiver and a network device monitoring method capable of detecting a state of a network device and providing sensed information.

In general, digital broadcasting is multichannel / multimedia broadcasting, unlike conventional analog broadcasting, not only providing high-quality / high-quality service but also having versatility. Versatility is a new service that provides multimedia information through broadcast media. It refers to data broadcasting or interactive broadcasting. Data broadcasting is a broadcast that uses information to broadcast receiver by transmitting multimedia data such as text, still picture, moving picture, graphic, document, software, etc., and is the best service for the current trend of convergence of broadcasting and communication.

In order to provide such services, middleware platform providers need to access multimedia data distributed over a number of heterogeneous broadcast and web-enabled networks. These networks are generally used as examples, such as Digital Video Broadcasting (DVB) (including DVB-C (cable), DVB-T (terrestrial), and DVB-S (satellite)), OpenCable.TM. Application platform United States or Europe, including OpenCable.TM.Applications Platform (OCA), Next Generation Television System Committee (ATSC), National Television System Committee (NTSC), GI Motorola Network, Multimedia Home Platform (MHP) standards, and more Based on industry digital broadcasting standards. In particular, the MHP standard extends existing DVB standards for broadcast and interactive services in all transport networks, including satellite, cable, terrestrial and microwave. The DVB / MHP standard defines a hardware independent, interface between the terminals and interactive digital applications that they run. This allows digital content providers to handle all types of terminals, from low functionality to high performance set top boxes, integrated digital TV sets and multimedia PCs.

Version 1.0.3 of the MHP standard supports a freely downloadable application called 'Xlet'. That is, the MHP standard uses Xlet Application to handle various user requirements. At this time, Xlet Application receives system resources from middleware and handles these tasks. In other words, Xlet applications can be run on all types of terminals, from low-functioning to high-end set-top boxes, integrated digital TV sets, and multimedia PCs, by allocating them through middleware rather than directly allocating resources from broadcast receivers.

An object of the present invention is to provide a broadcast receiver and a network device monitoring method capable of quickly providing network device state information by monitoring a state of a network device.

Another technical problem to be solved by the present invention is to provide a broadcast receiver and a network device monitoring method for promptly notifying when a state of a network device is dynamically changed.

In order to achieve the above technical problem, a broadcast receiver according to the present invention generates and registers a network interface unit connected to a network device, and a listener instance for receiving network device state information which is information about a state of the network device. Monitoring the state of the network device; if the state of the network device is changed, generating an event instance informing of the network device state information, and delivering the generated event instance to the registered listener instance. It is provided with a control unit. Here, the network device may be removable. In addition, the network device may be any one of a mounted state and a detached state.

Preferably, the control unit may generate a return channel device manager instance managing the network device.

Preferably, the control unit. The listener instance may be registered using a method provided by the return channel device manager instance.

Preferably, the return channel device manager instance includes an ATTACHED attribute, a DETACHED attribute, an instance obtaining method, a getRCDevices method, and a listener registration method (addRCDeviceListener method). And a removeRCDeviceListener method.

Preferably, the return channel device acquisition method may include a return channel interface acquisition method returning an instance of org.dvb.net.rc.RCInterface and a current status acquisition method return status of the return channel device. It can return a return channel device instance containing).

In accordance with another aspect of the present invention, there is provided a method for monitoring a network device, the method comprising: generating a listener instance that receives network device state information, which is information about a state of a network device, and registering the generated listener instance; Monitoring the state of the network device; and if the state of the network device changes, creates an event instance informing the network device state information, and converts the generated event instance to the registered listener instance. Delivering. Here, the network device may be removable. In addition, the network device may be any one of a mounted state and a detached state.

Advantageously, the network device monitoring method may further comprise receiving a request for network device status information.

Advantageously, the network device monitoring method may further comprise obtaining a return channel device manager instance managing the network device.

Preferably, in the registering step, the listener instance may be registered using a method provided by the obtained return channel device manager instance.

Preferably, the return channel device manager instance includes an ATTACHED attribute, a DETACHED attribute, an instance obtaining method, a getRCDevices method, and a listener registration method (addRCDeviceListener method). And a removeRCDeviceListener method.

Preferably, the return channel device acquisition method may include a return channel interface acquisition method returning an instance of org.dvb.net.rc.RCInterface and a current status acquisition method return status of the return channel device. It can return a return channel device instance containing).

According to the broadcast receiver and the network device monitoring method according to the present invention, since the status of the network device is monitored in real time, it is possible to provide the network device status information quickly and immediately detect when the status of the network device changes dynamically. It can provide a faster and more reliable service to the user.

Hereinafter, with reference to the accompanying drawings, preferred embodiments of the present invention that can specifically realize the above object will be described. At this time, the configuration and operation of the present invention shown in the drawings and described by it will be described as at least one embodiment, by which the technical spirit of the present invention and its core configuration and operation is not limited.

The terms used in the present invention have been selected as general terms widely used as possible in consideration of the functions in the present invention, but may vary according to the intention or custom of a person skilled in the art or the emergence of a new technology. In addition, in certain cases, there is also a term arbitrarily selected by the applicant, in which case the meaning will be described in detail in the description of the invention. Therefore, it is intended that the terms used in the present invention should be defined based on the meanings of the terms and the general contents of the present invention rather than the names of the simple terms.

1 is a structural diagram showing a configuration of a preferred embodiment of the hierarchical structure of a broadcast receiver.

Referring to FIG. 1, the broadcast receiver 100 according to the present invention includes an application 110, a middleware 120, and resources 130.

Application 110 is defined as a program executed to achieve various purposes in broadcast receiver 100. The application 110 may include a plurality of applications 111, 112,..., 119 running on the broadcast receiver 100.

 The applications 111, 112,..., 119 may be included in the broadcast stream and transmitted along with the broadcast program and the broadcast service information to the appropriately installed broadcast receiver 100. Applications 111, 112,..., 119 may be transmitted in a carousel format according to a protocol such as the DSM-CC protocol specified under ISO / IEC13818-6. The applications 111, 112,..., 119 may be broadcast periodically. Appropriately installed broadcast receiver 100 may receive these applications 111, 112,..., 119 and execute them locally. Example applications 111, 112,..., 119 include electronic program guides, play-along games, telebanking, menu navigation options, teleshopping, electronic newspapers, and similar information services.

The application 110 may be an Xlet application in a MHP-based standard. The basic hardware for running Xlets is a set top box or digital television receiver that supports the Java TV platform (eg, middleware 120 of FIG. 1). Xlets do not have a "main" way and Xlets implement the interface Xlet.

Xlets have a life cycle, and the life cycle method signature is defined by the interface Xlet. Interface Xlet provides lifecycle methods for reporting Xlet state changes such as creation, initialization, startup, and destruction. However, the interface Xlet does not provide execution for its lifecycle methods. All Java TV implementations have an application manager 127 that calls lifecycle methods to move one or more Xlets through various application states via an interface Xlet. Interface Xlet does not provide execution for its lifecycle methods. The developer provides application-specific executions for those methods by defining what happens at each point in the Xlet life cycle. For example, the iniXlet method for a game Xlet will create user interface components. The Xlet is designed to notify the application manager 127 of the state changes by initiating some state changes themselves and causing methods in the XletContext interface.

The interface Xlet is defined by the javax.tv.xlet package, one of the packages defined in the Java TVTM API. The Java TV API consists of interfaces and classes grouped into packages. These packages include interfaces and classes for processing video, audio, and data sent to a digital receiver via a broadcast stream sent by television networks.

The interface Xlet, defined in javax.tv.xlet, allows the application manager to create, initialize, start, stop, and destroy Xlets. The application manager 127 maintains the state of the Xlet and causes the methods on the Xlet through various lifecycle methods. The Xlet executes these methods to update its internal operations and resource usages as directed by the application manager 127.

2 is a conceptual diagram illustrating an example of a life cycle of an application.

Referring to FIG. 2, the method summary of the interface Xlet, as defined by javax.tv.xlet, is as follows. The Xlet is in a loaded state 210 in memory. initXlet initializes the Xlet itself in the loaded state (210) and signals the Xlet to enter the paused state (220). startXlet signals the Xlet to start providing services and to enter an active state (230). The PauseXlet signals the Xlet to stop providing service and enter the suspended state 220. destroyXlet signals the Xlet to terminate service provision and enter a destroyed state (240).

On the other hand, not only the first embodiment, but also other embodiments to be described below, in consideration of the convenience of explanation and understanding, the application 110 will be described by taking the case of an MHP application as an example. Therefore, the scope of the present invention is not limited to the MHP standard, and is applicable to other data broadcasting standards such as the OpenCable Application Platform (OCAP) standard, the Advanced Common Application Platform (ACAP) standard, and the Blu-ray Disc Java (BD-J) standard. This may be evident when considering the claims herein.

For example, the present invention can be applied not only to cables but also to data broadcasting through terrestrial and satellite broadcasting. That is, the broadcast receiver 100 according to the present invention may operate a terrestrial broadcast mode (Antenna), a satellite broadcast mode, a cable broadcast mode (cable) by operating a remote control or a "TV / Video" button of a local key. ), Video 1, IPTV broadcast mode and Video 2 can be input.

The middleware 120 plays a role of mediating between the application 110 and the resource 130. In addition, the middleware 120 receives the information or command of the application 110, executes the received command to calculate a result of the received command, and transmits the calculated result to the application 120. For this purpose, the middleware 120 includes an interface 121 and a system service 126.

The interface 121 performs a function of transmitting and receiving data, information, and commands between the application 110 and the system service 126. That is, the application 110 may use a service provided by the middleware 120 through the interface 121. In order for the producer of the application 110 to use the middleware 120, each broadcast standard defines a request form for requesting a specific service provided by the middleware 120. If the application 110 requests the middleware 120 to perform a specific service according to the request abbreviation defined in each broadcasting standard, the interface 121 receives a request to perform a specific service and the system service 126. The request for execution of the specific service is transmitted to the system service 126 so that the specific service can perform the specific service requested. Here, the request form for requesting a specific service provided by the middleware 120 defined in the broadcast standard may be an API (Application Programming Interface) defined by JAVA.

For example, the request form for requesting a specific service may be defined as an API of the MHP. As is well known, MHP 1.0.x is fundamental and specifies a wide range of application execution environments for digital interactive TVs, regardless of vendor specific hardware and software. This execution environment is based on the definition of generic APIs that provide the use of a Java ™ virtual machine and access to common resources and facilities of an interactive digital TV terminal. Java ™ applications that use these generic APIs are called DVB-J applications. In contrast, MHP 1.1 provides additional functionality for the MHP 1.0.x platform in a number of ways, including defining a new optional application type, DVB-HTML. For MHP 1.0.x, only DVB-J is required to be supported. Therefore, for DVB-J applications running under MHP 1.0.x, "javax.tv.xlet.Xlet" is a defined interface and an entity that can be executed and recognized under MHP 1.0.x.

The system service 126 performs the service according to the request transmitted by the interface 121 and provides the result to the interface 126. In addition, the system service 126 downloads the application 110 from the broadcasting station, manages the life cycle of the downloaded application 110, and allocates the resource 130 to the application 110 in an active state 230. And manages returns and manages information about allocated resources. To this end, the system service 126 includes an application manager 127. Here, the middleware 120 may be implemented according to the MHP standard, for example, to support the MHP API.

The application manager 127 is a module that manages life cycles of the applications 111, 112,..., 119. The application manager 127 manages generation, execution, and termination of the applications 111, 112,.

The resource 130 refers to a hardware entity having various functions, and the resource 130 may be represented as a hardware resource and a software resource. Hardware resources refer to tuners, demodulators, CAs, demultiplexers, decoders, memory, hard disks, and network devices. In addition, a software resource may represent a plurality of hardware entities grouped and may be a resource defined on an operating system such as a process or a thread. Here, a thread is a unit of flow that runs within a process. Generally, a program has one thread, but depending on the program environment, more than one thread can run at the same time. That is, the program can be executed in a multithreaded manner. This multithreaded approach is a method of execution in which each thread shares and uses memory within a process, unlike processes that run independently and occupy separate memory.

In addition, the resource 130 is provided transparently to the application 110 so that the application 110 can be used irrespective of the internal implementation. As described above, the middleware 120 may be connected to the application 110. It plays a role of mediating the resource 130. In addition, the resource 130 may be divided into a shared resource and a non-shared resource. Shared resources refer to resources that applications 111, 112, ..., 119 can share with each other, such as resources such as memory, threads, and network sessions. Non-shared resources are used by applications 111 as resources such as tuners. Refers to a resource that cannot be used by other applications 112,..., 119.

In order to use the resource 130, the Xlet application autonomously uses VM memory and threads. The protocol or management of these resources is entirely done in the middleware 120, and the application 110 operates without great consideration for the usage of its resources.

3 is a block diagram showing the configuration of a preferred embodiment of a broadcast receiver according to the present invention.

Referring to FIG. 3, the broadcast receiver 300 according to the present invention includes a tuner 311, a demodulator 312, a CA 313, a demultiplexer 314, a media decoder 315, and a user interface 321. , A storage medium 322, a network interface unit 323, and a processor 350. The tuner 311, the demodulator 312, the CA 313, the demultiplexer 314, the media decoder 315, the user interface 321, the storage medium 322, the network interface 323 and the processor. 350 is a component corresponding to the resource 130 of the broadcast receiver 100.

The tuner 311 receives broadcast data from at least one of the terrestrial wave, satellite, and cable, and outputs the broadcast data to the demodulator 312. That is, the tuner 311 tunes the frequency of a specific channel among the broadcast signals 301 input through any one of an antenna, a cable, and a satellite and outputs the tuner 312 to the demodulator 312. The tuner 311 may be provided for each broadcast source, for example, terrestrial wave, cable, and satellite, or may be an integrated tuner. In addition, when the tuner 311 is assumed to be a terrestrial broadcasting tuner, the tuner 311 may include at least one digital tuner and an analog tuner, or may be a digital / analog integrated tuner. When the terrestrial wave is an example, the tuner 311 tunes a terrestrial broadcast content transmitted through an antenna, that is, a broadcast signal of a channel selected by a user from among broadcast signals, and outputs the tuned signal to the demodulator 312.

The broadcast data received by the tuner 311 includes at least one of A / V data, MPEG section data, and application data. A / V data means audio data or video data. In addition, the MPEG section data is data including SI (System Information), EAS, and Application Information Table (AIT). In particular, an application information table (AIT) refers to a table including information on an application running in a receiver for data services, and in some cases, is also referred to as XAIT and AMT. These AITs provide information about the application, such as the name of the application, the version of the application, the priority of the application, the ID of the application, the state of the application (auto-start, user operable, kill, etc.), and the type of application. (Java or HTML), the location of the stream containing the classes and data files of the application, the base directory of the application, the location of the icon of the application, and the like.

Application data refers to data containing the program code of the application (110). The processor 350 may determine a transmission mode based on an application information table (AIT) and control to download application data in the determined transmission mode. Herein, the transmission mode refers to a transmission method and a type of transmission medium for receiving broadcast data. The transmission method refers to the type of protocol used for each network layer, and DSM-CC User-to-User, Data and Object Carousel protocols, HTTP, TCP, UDP, IP, MPEG-2 Transport Stream, and Ethernet protocol are optional. Can be used as In addition, the transmission method may be Broadcast Channel Protocols and Interaction Channel Protocols defined in the MHP standard.

Types of transmission media may include terrestrial, satellite, cable and Internet networks.

In addition, the transmission mode may include a transmission mode in which a transmission method and a transmission path vary depending on the type of broadcast data. That is, the broadcast receiver 300 may support a transmission mode in which A / V data is received through a cable and application data is received through an internet network.

In addition, the processor 350 may detect application information using an application information table (AIT). As a method of detecting application information using AIT, component_tag, original_network_id, transport_stream_id, and service_id may be detected. The component_tag refers to an elementary stream carrying DSI of the corresponding Object Carousel, and the original_network_id refers to the DVB-SI original_network_id of the TS providing the transport connection. In addition, the transport_stream_id refers to the MPEG TS of the TS providing the transport connection, and the service_id refers to the DVB-SI of the service providing the transport connection. The original_network_id, transport_stream_id, and service_id may be used to obtain information on a specific channel.

The network interface unit 323 is connected with a network device. The network device may be mounted on the network interface unit 323, may be detachable, or may be an external LAN card. The network device may also be a card bus LAN card, a USB wireless LAN card, a USB wired LAN card, or a real port LAN card.

The network interface unit 323 provides a return channel through the connected network device. The return channel here is a communication mechanism that provides a connection between the broadcast receiver 300 and the remote server. The remote server may be, for example, a server installed by a service provider to provide a broadcast service. Return channels include digital cable television (CATV) return channels, digital enhanced cordless telecommunications (DECT) return channels, public switched telephone network (PSTN) return channels, integrated services digital network (ISDN) return channels, and local multipoint distribution system (LMDS) returns. It may include at least one of a channel and a master-antenna television (MATV) return channel.

The broadcast receiver 300 may connect with a remote server through a return channel and transmit data to the remote server. In order to provide a return channel, the network interface unit 323 receives broadcast data through the Internet network and outputs the received broadcast data to the CA 313 or the communication control unit 388.

The demodulator 312 demodulates the signal output from the tuner 311 and outputs the demodulated signal to the CA 313. The CA 313 descrambles the signal output from the demodulator 312 or the signal output from the network interface 323, and outputs the descrambled signal to the demultiplexer 314. The demultiplexer 314 is an application in the form of a DSM-CC object carousel in which a data stream (for example, MPEG-2 format) representing audio and video and a DSM-CC object carousel are repeatedly broadcast. Demultiplex with data. Here in another embodiment of a broadcast receiver capable of interfacing with non-broadcast delivery channels, the tuner 311 may be replaced with a network interface suitable for a non-broadcast delivery channel. The non-broadcast delivery channel may be an Internet Protocol (IP) based delivery channel.

The media decoder 315 decodes the audio stream and the video stream demultiplexed by the demultiplexer 314 into audio 302 and video 303 which can be displayed, respectively. To this end, the media decoder 315 may include an audio decoder and a video decoder. The video 303 displayed here may include an image output from the user interface 321.

Process 350 executes application 370 and middleware 380. The application 370 and the middleware 380 are components corresponding to the application 110 and the middleware 120 of the broadcast receiver 100, respectively.

The middleware 380 includes a tuner 311, a demodulator 312, a CA 313, a demultiplexer 314, a media decoder 315, a user interface 321, a storage medium 322, and a network interface unit ( 323 is controlled or managed and assigned to the application 370. To this end, the middleware 380 includes a tuner controller 381, a CA controller 382, an MPEG-2 SECTION FILTER 383, a service information processor 384, a DSM-CC 385, a media controller 386, and a storage controller. 387 and a communication control unit 388 are provided.

The tuner controller 381 controls the tuner 811 to allocate the tuner 811 to the application 370 or to change the tuning frequency of the tuner 811 according to a command of the application 370. The CA controller 382 controls the CA 312 so that the CA 312 descrambles the signal output from the demodulator 312.

The MPEG-2 SECTION FILTER 383 extracts information for displaying a video by filtering a data stream related to the video demultiplexed by the demultiplexer 314, and the service information processor 384 demultiplexes 314. Service information is extracted and processed from the demultiplexed data. That is, the MPEG-2 SECTION FILTER 383 extracts MPEG section data from the received broadcast data. In particular, the MPEG-2 SECTION FILTER 383 may extract host access guide information, which is guide information on a transmission mode, from the received broadcast data. In this case, the host access guide information may be included in the AIT and transmitted. In such a case, the MPEG-2 SECTION FILTER 383 may extract host access guide information by extracting AIT from broadcast data.

The DSM-CC 385 parses application data demultiplexed by the demultiplexer 314 to extract application program and application information, and stores the extracted information in the storage medium 322. The application program stored in storage medium 322 is executed in process 350.

The media controller 386 controls the media decoder 315 to display the audio 302 and video 303. In addition, the media controller retrieves the host access guide information extracted by the MPEG-2 SECTION FILTER 383 associated with the data access information stored in the storage medium 322, and transmits the data in the transmission mode indicated by the retrieved host access guide information. The tuner 311 or the network interface unit 323 may be controlled to receive the signal. Here, the media control unit 386 controls the network interface unit 323 to control the network interface unit 323 instead of directly controlling the network interface unit 323, so that the host access guide information retrieved by the network interface unit 323 is stored. The broadcast data may be received in the indicated transmission mode.

The storage control unit 387 stores the audio stream, the video stream, the application program, the application information, and the service information in the storage medium 322, and the audio stream, the video stream, the application program, the application information, and the service information stored in the storage medium 322. Control access to The storage medium 322 may be any one of a RAM memory, a FLASH memory, and an HDD, or may include a RAM memory, a FLASH memory, and an HDD. The HDD may be an internal HDD or an external HDD.

The communication control unit 388 supports the application 370 to enable network communication, and controls the network interface unit 323 for this purpose. In addition, the communication control unit 388 controls the network interface unit 323 to receive broadcast data. The communication control unit 388 may provide application to the storage control unit 387 to extract application data from the broadcast data received by the network interface unit 323 and store it in the storage medium. The broadcast data received by the network interface unit 323 may be provided. The A / V data may be controlled to be output to the CA 313.

The communication controller 388 manages a return channel provided by the network interface unit 370. When the application 370 requests the use of the return channel, the communication control unit 388 provides the return channel interface to the application 370.

In addition, the communication controller 388 manages a network device connected to the network interface unit 370. When the application 370 requests network device state information, the communication control unit 388 provides the network device state information. Here, the network device state information refers to information about the state of the network device. The network device may be any one of a mounted state and a detached state.

In addition, the communication controller 388 may monitor whether the network device is in a state change and may provide network device state information to the application 370 when the state of the network device is changed. Here, in order to receive network device state information when the network device state changes, the application 370 may need to perform a separate request procedure to the communication controller 388. That is, the communication control unit 388 may provide network device state information when the state of the network device is changed depending on whether the application 370 performs the request procedure.

As an example of a request procedure for receiving network device state information when a state of a network device is changed, the application 370 may create a listener instance that receives network device state information and register the created instance. In this case, the listener instance may be registered through a method provided by the return channel device manager instance. The application 370 needs to obtain a return channel device manager instance that manages the network device, in order to register a listener instance.

The communication control unit 388 generates a return channel device manager instance, and when the application 370 requests the return channel device manager instance, the communication control unit 388 provides the corresponding return channel device manager instance to the application 370. In addition, when the state of the network device is changed, the communication controller 388 may generate an event instance informing the network device state information, and transfer the generated event instance to a listener instance registered by the application 370.

The process 380 may be implemented as a single process or a multi-process, and may include a tuner control unit 381, a CA control unit 382, an MPEG-2 SECTION FILTER 383, a service information processing unit 384, and a DSM of the middleware 380. The CC 385, the media controller 386, the storage controller 387, and the communication controller 388 may be made of hardware or firmware, respectively. In this case, the middleware 380 is a tuner control unit 381, CA control unit 382, MPEG-2 SECTION FILTER 383, service information processing unit 384, DSM-CC 385, the media control unit 386, the storage control unit 387, and the communication control unit 388 are used to mediate.

4 is a diagram illustrating a return channel device manager class and a listener class according to the present invention.

Referring to FIG. 4, the return channel device manager class RCDeviceManager may include a return channel device object. The return channel device object may be defined as a return channel device class RCDevice and the return channel device class RCDevice may be matched one-to-one with a class that models a network interface of the return channel. That is, the return channel device class RCDevice may obtain an instance of a class that models a matching network interface. Here, the class modeling the network interface of the return channel may be RCInterface included in the org.dvb.net.rc package. The org.dvb.net.rc package contains Java API related to session management for bidirectional IP connection proposed in DVB specification.

The application may obtain an instance of the return channel device manager class RCDeviceManager and check the state of the network device by using the obtained instance of the return channel device manager class RCDeviceManager. An application may create a listener instance (RCDeviceStatusListener) and register the created listener instance by using a method provided by an instance of the return channel device manager class (RCDeviceManager). In addition, the application may request network device information from the middleware 120 using a method provided by an instance of the return channel device manager class RCDeviceManager.

5 is a diagram illustrating a preferred example of the API specification of the RCDeviceManager, RCDevice and RCDeviceStatusListener according to the present invention.

Referring to FIG. 5, the RCDeviceManager is defined as a public class type, and has a ATTACHED attribute, a DETACHED attribute, an instance get method, a get channel device get method, a listener registration method. (addRCDeviceListener method) and remove listener method (removeRCDeviceListener method).

The mounting attribute indicates a state in which the network device is connected to the network interface unit 323 and can be used. The mounting property is defined as a public static final int type and is assigned a value of '0'.

The detachment property indicates a state in which a network device is not connected to the network interface unit 323 and is defined as a public static final int type and assigned a value of '1'.

The instance acquisition method is a factory API that returns an instance of RCDeviceManager. It is defined as a public static type and returns an instance of RCDeviceManager.

The return channel device acquisition method is an API for acquiring all network devices connected to the network interface unit 323. The return channel device acquisition method is defined as a public RCDevice [] type and is an instance of an RCDevice for all network devices connected to the network interface unit 323. Returns an array containing the strings.

The listener registration method is an API used to dynamically notify network device status changes. It is defined as a public void type and has a RCDeivceStatusListener object as a parameter. Here, RCDeviceStatusListener is a listener class for receiving network device status information. RCDeviceStatusListener may be implemented in an application and an instance of RCDeviceStatusListener may be created. The listener registration method registers an instance of RCDeviceStatusListener that is passed as a parameter.

The application can create an RCDeviceStatusListener instance and register the created RCDeviceStatusListener instance using the listener registration method. For example, an application can register RCDeviceStatusListener 1 by creating RCDeviceStatusListener 1, which is an instance of RCDeviceStatusListener, and running RCDeviceManager.addRCDeviceListener (RCDeviceStatusListener 1).

The listener removal method is an API used to remove a registered RCDeviceStatusListener. It is defined as a public void type and has a RCDeviceStatusListener object as a parameter. If the RCDeviceStatusListener instance passed as a parameter here is not registered or is invalid, it will be ignored.

The application can remove the registered RCDeviceStatusListener instance using the remove listener method. For example, an application can remove a registered RCDeviceStatusListener 1 by executing RCDeviceManager.removeRCDeviceListener (RCDeviceStatusListener 1).

RCDevice is a class that represents a physical network device. It is defined as a public class type and contains the getRCInterface () and getCurrentStatus () methods. The getRCInterface () method is defined as public RCInterface and returns an instance of the return channel interface (RCInterface) associated with the RCDevice. Here, the instance of the return channel interface (RCInterface) may be an org.dvb.net.rc.RCInterface instance.

The getCurrentStatus () method is used to check the current status of RCDevice. It is defined as a public int type. The getCurrentStatus () method returns either RCDeviceManager.ATTACHED or RCDeviceManager.DETACHED.

RCDeviceStatusListener is defined as a public interface type and contains the receiveRCDeviceEvent (RCDeviceEvent event) method. As RCDeviceStatusListener defines the public interface type, an application can implement RCDeviceStatusListener class by inheriting RCDeviceStatusListener. RCDeviceStatusListener is used to dynamically check the status of network device. In other words, the RCDeviceStatusListener should be implemented where you want to know the dynamic status of the network device.

The receiveRCDeviceEvent (RCDeviceEvent event) method sends an event to an application when the state of a network device changes. It is defined as a public void type and has a RCDeviceEvent object as a parameter. Here, the RCDeviceEvent object may be one of RCDeviceAttachedEvent and RCDeviceDetachedEvent.

FIG. 6 is a diagram illustrating a preferred example of an API specification of RCDeviceEvent, RCDeviceAttachedEvent, and RCDeviceDetachedEvent according to the present invention.

Referring to FIG. 6, RCDeviceEvent is an event class indicating network device state information. When a state of a network device is dynamically changed, a RCDeviceEvent object is generated. RCDeviceEvent is defined as a public class type, inherits from java.util.EventObject, and contains the RCDeviceEvent (java.lang.Object source) constructor. RCDeviceEvent is used by RCDeviceStatusListener.

When the state of the network device is dynamically changed, the middleware can create an RCDeviceEvent instance and deliver the created RCDeviceEvent to the application that registered the RCDeviceStatusListener instance using the RCDeviceStatusListener.receiveRCDeviceEvent (RCDeviceEvent event) method.

RCDeviceAttachedEvent is raised when the network device changes from detached state to attached state. RCDeviceAttachedEvent is defined as a public class type. It inherits RCDeviceEvent and includes the RCDeviceAttachedEvent (java.lang.Object source) constructor.

The constructor RCDeviceAttachedEvent (java.lang.Object source) includes source as a parameter. Where source is the RCDevice object where the event occurred.

RCDeviceDetachedEvent occurs when the state of the network device changes from the attached state to the detached state. RCDeviceDetachedEvent is defined as a public class type. It inherits RCDeviceEvent and includes the RCDeviceDetachedEvent (java.lang.Object source) constructor.

The constructor RCDeviceDetachedEvent (java.lang.Object source) includes source as a parameter. Where source is the RCDevice object where the event occurred.

When RCDeviceAttachedEvent is received through the registered RCDeviceStatusListener, the application 370 may recognize that the network device is changed from the detached state to the mounted state. In addition, when the RCDeviceDetachedEvent is received through the registered RCDeviceStatusListener, the application 370 may recognize that the network device is changed from the attached state to the detached state.

7 is a diagram showing another preferred embodiment of the API specification of RCDeviceEvent according to the present invention.

Referring to FIG. 7, RCDeviceEvent informs network device state information and occurs when a state of a network device is dynamically changed. RCDeviceEvent is defined as a public class type, inherits from java.util.EventObject, and includes the RCDeviceEvent (java.lang.Object source, int status) constructor and the getStatus () method.

The constructor of RCDeviceEvent (java.lang.Object source, int status) includes source and status as parameters. source is the RCDevice object where the event occurred. status is RCDeviceManager.ATTACHED if the network device is in the mounted state, and RCDeviceManager.DETACHED if the network device is in the detached state.

The getStatus () method provides the status parameter of the RCDeviceEvent (java.lang.Object source, int status) constructor.

When the state of the network device is dynamically changed, the middleware 380 may create a RCDeviceEvent instance and deliver the generated RCDeviceEvent to the application that registered the RCDeviceStatusListener instance by using the RCDeviceStatusListener.receiveRCDeviceEvent (RCDeviceEvent event) method. Here, if the state of the network device changes from the detached state to the attached state, the middleware executes RCDeviceEvent (RCDevice, RCDeviceManager.ATTACHED) to generate an RCDeviceEvent, and if the state of the network device changes from the attached state to the detached state The middleware 380 may generate RCDeviceEvent by executing RCDeviceEvent (RCDevice, RCDeviceManager.DETACHED).

8 is a sequence diagram of a preferred embodiment of a network device monitoring method according to the present invention.

Referring to FIG. 8, the application 810 executes getInterface () to obtain a reference of the RCDeviceManager instance 820 (S800). Here, the RCInterfaceManager instance 820 may be a component included in or correspond to the communication controller 388 of FIG. 3, and the application 810 may be a component corresponding to the application 370 of FIG. 3. In addition, the application 810 may obtain network device status information of the corresponding network device by executing RCDeviceManager.RCDevice []. GetCurrentStatus ().

The application 810 generates an RCDeviceStatusListenerImpl instance 840 which is an instance of a class implementing RCDeviceStatusListener (S802). The application 810 registers an RCDeviceStatusListenerImpl instance 840 generated by executing RCDeviceManager.addRCDeviceListener (RCDeviceStatusListener) (S804).

If the network device 830 is mounted and it is detected that the state of the network device is changed from the detached state to the attached state, the RCDeviceManager instance 820 generates an RCDeviceAttachedEvent as an event instance indicating the network device state information ( S806). Here, the RCDeviceManager instance 820 may generate RCDeviceEvent (RCDevice, RCDeviceManager.ATTACHED) in place of RCDeviceAttachedEvent.

The RCDeviceManager instance 820 executes RCDeviceStatusListenerImpl.receiveRCDeviceEvent (RCDeviceEvent), which is a generated event instance, RCDeviceAttachedEvent instance, and delivers it to the RCDeviceStatusListenerImpl instance 840 (S808).

If the network device 830 is detached and it is detected that the state of the network device is changed from the attached state to the detached state, the RCDeviceManager instance 820 generates an RCDeviceDetachedEvent as an event instance indicating the network device state information (S810). ). Here, the RCDeviceManager instance 820 may generate RCDeviceEvent (RCDevice, RCDeviceManager.DETACHED) in place of RCDeviceDetachedEvent.

The RCDeviceStatusListenerImpl instance 840 executes RCDeviceStatusListenerImpl.receiveRCDeviceEvent (RCDeviceEvent), which is a generated event instance, RCDeviceDetachedEvent instance, and delivers it to the RCDeviceStatusListenerImpl instance 840 (S812).

The application 810 removes the registered RCDeviceStatusListenerImpl instance 850 by executing RCDeviceManager.removeRCInterfaceListener (RCDeviceStatusListener) (S814).

9 is a block diagram of a preferred embodiment of a channel state monitoring method according to the present invention.

Referring to FIG. 9, the application 910 includes an RCDeviceStatusListenerImpl instance 912. Here, the application 910 is a component corresponding to the application 370 of FIG. 3. The application 910 may generate and include a required RCDeviceStatusListenerImpl instance 912 according to the number of network devices.

The application 910 executes getInterface () to obtain a reference of the RCDeviceManager 925 from the middleware 920. In addition, the application 910 may register the RCDeviceStatusListenerImpl instance 912 using RCDeviceManager.addRCDeviceListener (RCDeviceStatusListener). The registered RCDeviceStatusListenerImpl instance 912 may receive an RCDeviceAttachedEvent instance and an RCDeviceDetachedEvent instance. If an RCDeviceAttachedEvent instance is passed, the application 910 knows that the state of the network device has changed from a detached state to a mounted state, and if an RCDeviceDetachedEvent instance is passed, the state of the network device changes from a mounted state to a detached state. It can be seen that.

The application 910 may remove the registered RCDeviceStatusListenerImpl instance by using RCDeviceManager.removeRCDeviceListener (RCDeviceStatusListener).

The middleware 920 also includes an RCDeviceManager 925. RCDeviceManager 925 also includes an RCDevice instance 927. Here, the RCDeviceManager 925 may generate and include an RCDevice instance 927 according to the number of network devices. The middleware 920 is a component corresponding to the middleware 380 of FIG. 3.

The RCDevice instance 927 monitors whether the state of the network device has changed, and creates an RCDeviceAttachedEvent instance when the state of the network device is changed from the detached state to the attached state. Create an instance.

The network interface unit 930 is connected to the network device 940 and provides the RCDevice instance 927 with a mounting state and a detaching state of the network device.

10 is a flowchart illustrating a preferred embodiment of a method for monitoring a network device according to the present invention.

Referring to FIG. 10, the application 370 obtains a return channel device manager instance (S1000). In this case, the return channel device manager instance may be generated by the middleware 380. In addition, the return channel device manager class may be RCDeviceManager illustrated in FIG. 5.

The application 370 requests network device state information to obtain network device state information (S1010). Here, the application 370 may acquire network device state information by using the obtained method of the return channel device manager instance. For example, RCDeviceManager.RCDeivce []. GetCurrentStatus () shown in FIG. 5 may be used to obtain network device status information.

The application 370 generates a listener instance that receives network device state information, which is information about the state of the network device (S1020). The class of the listener instance created here may be RCDeviceStatusListener illustrated in FIG. 5.

The application 370 registers the created listener instance (S1030). Here, the application 370 may register a return listener instance using a method provided by the return channel device manager instance. For example, RCDeviceManager.addRCDeviceListener (RCDeviceStatusListener listener) illustrated in FIG. 5 may be used to register a listener instance.

The middleware 380 monitors whether the state of the network device changes (S1040). The middleware 380 may monitor at least one or more network devices.

The middleware 380 checks whether the state of the network device has changed (S1050).

When the state of the network device is changed, the middleware 380 generates an event instance informing the network device state information, and transfers the generated event instance to the listener instance registered by the application 380 (S1060). Here, the event instance for notifying the network device state information may be any one of the RCDeviceAttachedEvent instance and the RCDeviceDetachedEvent shown in FIG. 6 or the RCDeviceEvent shown in FIG. 7.

If a network device is connected to the network interface unit 323 and it is detected that the state of the network device is changed from the detached state to the mounted state, the middleware 380 generates an RCDeviceAttachedEvent as an event instance informing the network device state information. do. Here, the middleware 380 may generate RCDeviceEvent (RCDevice, RCDeviceManager.ATTACHED) in place of RCDeviceAttachedEvent.

If the network device is disconnected from the network interface unit 323, and it is detected that the network state is changed from the mounted state to the detached state, the middleware 380 generates an RCDeviceDetachedEvent as an event instance indicating the network device state information. do. The middleware 380 may generate RCDeviceEvent (RCDevice, RCDeviceManager.Dettached) in place of RCDeviceDetachedEvent.

The middleware 380 delivers the generated event instance to the registered listener instance (S1070). Here, the middleware 380 may deliver the event instance to the corresponding listener instance using the method of the listener instance. For example, the event instance may be delivered to the corresponding listener instance by using the RCDeviceStatusListener.receiveRCDeviceEvent method shown in FIG. 5. The application 370 may determine the state of the corresponding network device through the event instance delivered to the listener instance.

The present invention can also be embodied as computer-readable codes on a computer-readable recording medium. Computer-readable recording media include all kinds of recording devices that store data that can be read by a computer device. Examples of the computer-readable recording medium include a ROM, a RAM, a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like, and may be implemented in the form of a carrier wave (for example, transmission via the Internet) . The computer-readable recording medium may also be distributed to networked computer devices so that computer readable code can be stored and executed in a distributed manner.

Although the preferred embodiments of the present invention have been shown and described above, the present invention is not limited to the specific preferred embodiments described above, and the present invention belongs to the present invention without departing from the gist of the present invention as claimed in the claims. Various modifications can be made by those skilled in the art, and such changes are within the scope of the claims.

1 is a structural diagram showing a configuration of a preferred embodiment of a hierarchical structure of a broadcast receiver;

2 is a conceptual diagram illustrating an example of a life cycle of an application;

3 is a block diagram showing the configuration of a preferred embodiment of a broadcast receiver according to the present invention;

4 is a diagram illustrating a liter channel device manager class and a listener class according to the present invention;

5 is a view showing a preferred embodiment of the API specification of the RCDeviceManager class, RCDevice class and RCDeviceStatusListener class according to the present invention,

6 is a view showing a preferred embodiment of the API specification of RCDeviceEvent, RCDeviceAttachedEvent and RCDeviceDetachedEvent according to the present invention,

7 is a diagram showing another preferred embodiment of the API specification of RCDeviceEvent according to the present invention;

8 is a sequence diagram of a preferred embodiment of a network device monitoring method according to the present invention;

9 shows a block diagram of a preferred embodiment of a network device monitoring method according to the invention, and

10 is a flowchart illustrating a preferred embodiment of a method for monitoring a network device according to the present invention.

Claims (15)

Creating a listener instance for receiving network device state information which is information about a state of a network device, and registering the generated listener instance; Monitoring whether the network device has changed state; And When the state of the network device is changed, generating an event instance informing of the network device state information, and delivering the generated event instance to the registered listener instance. Way. The method of claim 1, The network device monitoring method, characterized in that the removable device. The method of claim 1, And a state of the network device is any one of a mounted state and a detached state. The method of claim 1, And receiving a request for the network device status information. The method of claim 1, Acquiring a return channel device manager instance managing the network device. The method of claim 5, In the step of registering, Registering the listener instance using a method provided by the obtained return channel device manager instance. The method of claim 5, The return channel device manager instance is At least one of the ATTACHED attribute, the DETACHED attribute, the getInstance method, the getRCDevices method, the addRCDeviceListener method, and the removeRCDeviceListener method. Network device monitoring method comprising a. The method of claim 7, wherein The return channel device acquisition method interrupt is Returns a return channel device instance that includes a return channel interface get method that returns an instance of org.dvb.net.rc.RCInterface and a getCurrentStatus method that returns the status of the return channel device. Network device monitoring method, characterized in that. A network interface connected to the network device; And Create and register a listener instance that receives network device state information, which is information about the state of the network device, monitor whether the state of the network device changes, and, when the state of the network device changes, the network device state information. And a controller configured to generate an event instance informing the event and to deliver the generated event instance to the registered listener instance. The method of claim 9, The network device is a broadcast receiver, characterized in that the removable. The method of claim 9, And a state of the network device is one of a mounting state and a detachable state. The method of claim 9, The control unit, And a return channel device manager instance for managing the network device. The method of claim 12, The control unit. And registering the listener instance using a method provided by the return channel device manager instance. The method of claim 12, The return channel device manager instance is At least one of the ATTACHED attribute, the DETACHED attribute, the getInstance method, the getRCDevices method, the addRCDeviceListener method, and the removeRCDeviceListener method. Broadcast receiver comprising a. 15. The method of claim 14, The return channel device acquisition method, Returns a return channel device instance that includes a return channel interface get method that returns an instance of org.dvb.net.rc.RCInterface and a getCurrentStatus method that returns the status of the return channel device. Broadcast receiver, characterized in that.

Images