KR20100056173A - Method for controlling to display a screen and apparatus thereof - Google Patents

Abstract

PURPOSE: A screen control method and a device thereof are provided to realize convenience of user by appropriately expressing a plurality of applications performing complicated and various functions in one screen. CONSTITUTION: A graphic device request command is received from an application(S603). Application priority information of the application is extracted by the request(S604). A graphic device object returns to the application by the extracted application priority information(S605). Signaling information including the application priority information is received.

Description

Method for controlling to display and screen a device

The present invention relates to a screen control method and an apparatus thereof, and more particularly, to a method and apparatus for controlling each application to be properly output on the screen when a plurality of applications using a single screen.

Conventional services have been limited to audio and video, but recently, various and complicated applications are gradually coming out due to high specification of hardware. Accordingly, one application may be recognized and used as a service.

Thus, the broadcast environment is also changing to enable such applications to operate. For example, if a user wants to operate and output multiple applications on one screen, the broadcast environment should be able to adequately support this.

However, the user's request, i.e., how to output a plurality of applications operating on one screen, for example, the screen layout of each application, and how to express which application, etc. are not controlled. While various applications can be utilized, there is a problem that it can be inconvenienced with the recognition that it is complicated.

In order to solve the above problems, an object of the present invention is to provide a screen control method between a plurality of applications that are output on one screen.

Another object of the present invention is to provide an apparatus for providing the screen control method as described above.

Receiving a graphics device request command from an application according to the invention for achieving the above object; Extracting application priority information of the corresponding application according to the request; And returning a graphic device object according to the extracted application priority information to a corresponding application.

In this case, receiving signaling information including application priority information; Parsing application priority information in the received signaling information.

The method may further include storing the parsed application priority information.

In addition, the application may generate an HScene for the layer according to the returned graphic device object.

The request and return may be made using a getHGraphicsDevices () function previously defined in the HScreen class.

In addition, the application priority information may include first information related to the priority of an individual application and second information defining a graphic device allocated corresponding to the first information.

The application priority information may be included in the XAIT table in the signaling information and transmitted.

One example of a digital broadcast receiver according to the present invention includes a tuner unit for receiving a digital broadcast signal including signaling information including application priority information; A demodulator for demodulating the received digital broadcast signal; A demultiplexer for demultiplexing signaling information in the demodulated digital broadcast signal; And receiving and parsing application priority information in the demultiplexed signaling information, extracting the received application priority information when a graphic device request is received from an application, and corresponding to the graphic device object according to the extracted application priority information. And a processor unit to return to the application.

In this case, the processor unit may further include a storage medium for storing the application priority information parsed.

The processor unit may include a plurality of applications and middleware, wherein the middleware includes an interface module for transmitting and receiving information or requests with each of the applications, and a graphics device according to the application priority information according to the graphics device request of each application. It may include a screen control module that controls to return the object to the application.

The screen control module may further include first information about a priority of each application in the parsed application priority information and a graphic device allocated corresponding to the first information according to the graphic device request of the respective application. Control to extract the second information to define.

Therefore, according to the screen control method and the device according to the present invention,

First, there is an effect that the convenience of the user can be pursued by controlling a plurality of applications that perform complex various functions to be appropriately represented on one screen.

Second, there is an effect that does not require a separate control application for screen control of a plurality of applications.

Third, the screen can be controlled to induce the development of various applications and to exclude complex scenarios.

Hereinafter, with reference to the accompanying drawings, an embodiment including the technical idea of the present invention for solving the above problems in detail. Here, the configuration and operation of the present invention shown in the drawings and described in connection with it will be described as an example for explaining the technical idea of the present invention, whereby the technical idea of the present invention and its core Configuration and operation are not limited.

In addition, the terms used below have been selected as widely used general terms as possible in consideration of the functions in the present invention, but may vary according to the intention or custom of the person skilled in the art or the emergence of new technologies. 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 and referenced based on the meanings of the terms and the contents throughout the present invention rather than the names of the terms.

Hereinafter, a screen control method and apparatus according to the present invention will be described in detail with reference to the accompanying drawings.

In connection with the present invention, screen control is possible according to various methods. However, in the present specification, in an environment in which a plurality of applications operate on one screen at the same time or with a difference in time, the information regarding priority for each application defined for screen control may be used. A method of controlling the application output on the screen will be described as an example.

In this context, the term “screen control” is used herein to mean a process in which an output is controlled on a screen by using information about priorities defined by each application in relation to screen control.

In addition, in the present specification, “layer” means that a graphic device is required for each application to be displayed on a screen, and may be used as a generic term for layering each graphic device.

Hereinafter, with reference to the accompanying drawings will be described in detail the present invention.

1 is a structural diagram illustrating a hierarchical structure of a broadcast receiver according to the present invention.

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

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

Applications 111, 112,... 119 are broadcast in a broadcast stream with digital television programs to a properly installed broadcast receiver 100. The applications 111, 112,..., 119 can be broadcast in a carousel format according to a protocol such as the DSM-CC protocol specified under the relevant standard, and are broadcast periodically.

Properly installed broadcast receiver 100 receives these applications 111, 112,..., 119 and executes 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.

In this regard, in the present specification, the application 110 will be described using an Xlet application (hereinafter, 'Xlet') as an example for convenience of description. However, the present invention is not limited thereto, and it is known that the present invention can be applied to an application running on all data broadcasting platforms.

Basic hardware for executing the Xlet may be a set-top box or digital television receiver supporting a Java TV platform (eg, middleware 120 of FIG. 1). Xlets do not have a "main" way and Xlets execute 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. Thus, 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.

Interface Xlet is defined by the javax.tv.xlet package, one of the packages defined in the Java TV ^TM Application Programming Interface (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 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 in connection with the present invention.

Referring to FIG. 2, the method summary of the interface Xlet, as defined by javax.tv.xlet, is as follows. The Xlet becomes 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 the destroyed state (240).

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. Each broadcast standard defines a request form for requesting a specific service provided by the middleware 120 so that the creator of the application 110 may use 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 for performing 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 defined by JAVA. In this regard, "javax.tv.xlet.Xlet" is an entity that is a defined interface and that can be executed and recognized under the relevant specifications.

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. For this purpose, the system service 126 includes an application manager 127. Here, the middleware 120 may be implemented according to a related standard, for example, to support an API of the corresponding standard.

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

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. The hardware resource refers to a tuner unit, a demodulator, a conditional access (CA), a demultiplexer, a decoder, a memory, a hard disk, and a network adapter. In addition, the software resource may represent a plurality of hardware entities grouped and may be a resource defined on an operating system such as a press 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. In other words, the program can be executed in a multithreaded manner. This multithreaded approach is a process in which each thread shares and uses memory within a process, unlike processes running independently and occupying 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, and as described above, the middleware 120 may provide the application 110 with the application 110. And mediate the resource (130). In addition, the resource 130 may be divided into a shared resource and a non-shared resource. Shared resources are 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.

To use the resource 130, the Xlet 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 of a broadcast receiver configured according to an embodiment of the present invention.

Referring to FIG. 3, the broadcast receiver 300 according to the present invention includes a tuner unit 311, a demodulator 312, a CA unit 313, a demultiplexer 314, a media decoder 315, and a user interface unit. 321, a storage medium 322, a network interface unit 323, and a processor 350. Here, the tuner unit 311, the demodulator 312, the CA unit 313, the demultiplexer 314, the media decoder 315, the user interface unit 321, the storage medium 322, and the network interface unit The processor 323 and the processor 350 are components 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 tuned frequency to the demodulator 312. The tuner unit 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 unit 311 is assumed to be a terrestrial broadcast tuner, at least one digital tuner and an analog tuner may be provided, respectively, 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.

Here, the broadcast data received by the tuner unit 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 may be data including System Information (SI), EAS, Application Information Table (AIT), and eXtended AIT (XAIT). In particular, an application information table (AIT) refers to a table including information on an application running in a receiver for data service, and is also called AMT in some cases. 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.), 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. In connection with the present invention, the XAIT includes information about the priority of each application in relation to screen control and information about a graphic device object allocated according to the information about the priority.

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. Here, 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, Ethernet protocol, etc. Can be used. In addition, the transmission method may be Broadcast Channel Protocols and Interaction Channel Protocols defined in a related 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 the application information using the 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 323 receives broadcast data through the Internet network, and outputs the received broadcast data to the CA unit 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 unit 313. The CA unit 313 descrambles the signal output from the demodulator 312 or the signal output from the network interface unit 323, and outputs the descrambled signal to the demultiplexer 314. The demultiplexer 314 is a digital data stream that is a signal output from the CA unit 313 in the form of a data stream (for example, MPEG-2 format) representing audio and video and a DSM-CC object carousel that is repeatedly broadcast. Demultiplex with data for applications Here, in another embodiment of the broadcast receiver capable of interfacing with the non-broadcast delivery channels, the tuner 311 may be replaced with a network interface suitable for the non-broadcast delivery channels. 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. Here, the displayed video 303 may include an image output from the user interface 321.

Process 350 executes application 370 and middleware 380. Here, 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 323. ) Is controlled or managed and assigned to the application 370. To this end, the middleware 380 may include a tuner control unit 381, a CA control unit 382, an MPEG-2 section filter unit 383, a service information processing unit 384, a DSM-CC 385, and a media control unit (3). 386, a storage control unit 387, and a communication control unit 388.

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 unit 383 extracts information for displaying the video by filtering a data stream related to the video demultiplexed by the demultiplexer 314, and the service information processor 384 extracts the information for the demultiplexer 314. The service information is extracted from the demultiplexed data and processed. That is, the MPEG-2 section filter unit 383 extracts MPEG section data from the received broadcast data. In particular, the MPEG-2 section filter unit 383 may extract host access guide information, which is guide information on a transmission mode, from the received broadcast data. Here, the host access guide information may be included in the AIT and transmitted as an example.

In this case, the MPEG-2 section filter unit 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 control unit searches for the host access guide information extracted by the MPEG-2 section filter unit 383 associated with the data access information stored in the storage medium 322, and broadcasts in the transmission mode indicated by the searched host access guide information. The tuner 311 or network interface 323 may be controlled to receive data. Here, instead of directly controlling the network interface 323, the media controller 386 allows the communication controller 388 to control the network interface 323 so that the host access guide information retrieved by the network interface 323 is indicated. Receive broadcast data in the 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 controller 388 supports the application 370 to enable network communication, and controls the network interface 323 for this purpose. In addition, the communication control unit 388 controls the network interface 323 to receive broadcast data. The communication control unit 388 may extract the application data from the broadcast data received by the network interface 323 and provide it to the storage control unit 387 to be stored in a storage medium. The / V data may be controlled to be output to the CA 313.

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

In relation to the present invention, a broadcast signal including signaling information including application priority information is received through the tuner unit 311, demodulated by the demodulator 312, and distinguished from other data in the demultiplexer 314. The signaling information is then demultiplexed. The demultiplexed signaling information is transmitted to the processor 350. The process 350 may transfer the delivered signaling information to the middleware 380, and the middleware 380 may control to parse the application priority information in the delivered signaling information and store it in the storage medium 322.

4 is a block diagram showing the configuration of a preferred embodiment of the middleware according to the present invention.

Referring to FIG. 4, the middleware 400 according to the present invention corresponds to the middleware 380, and may include an interface module 410 and a screen control module 420. Here, the interface module 410 and the screen control module 420 are components corresponding to the interface 121 and the system service 126, respectively. The application 401 is a component corresponding to the application 370 of FIG. 3, and the storage medium 402 is a component corresponding to the storage medium 322 of FIG. 3.

The interface module 410 exchanges information or commands with the application 401. For example, when the application 401 transmits a request for a graphic device in connection with a screen control, the interface module 410 receives a request for a graphic device in connection with the screen control and receives the screen control module 420. To transmit. In contrast, when the screen control module 420 transmits a response according to a request command of the graphic device in relation to screen control, the interface module 410 receives the response and transmits the response to the application 401.

Referring to FIG. 3, for example, the middleware 400 of FIG. 4 previously received information regarding application priority related to screen control according to the present invention included in a broadcast signal received from the broadcast receiver 300. Can assume At this time, the middleware 400 parses the received application priority information. The parsed information is stored in the storage medium 402.

Accordingly, when the screen control module 420 receives a request of the graphic device in connection with the screen control from the application 401 through the interface module 410, the screen control module 420 parses or parses application priority information in the previously received broadcast signal. Extract information related to the application from the previously stored application priority information. In this case, the extracted information may include, for example, information about a priority for each application and information about a graphic device object pre-allocated corresponding to the information about the priority.

Accordingly, the screen control module 420 extracts the information about the priority and the information about the graphic device object, and in response to the request, the graphic control object 420 suitable for the application to the corresponding application via the interface module 410. Can be returned or passed In this regard, a more detailed description will be given later.

In the context of the present invention, the current standards allow an environment in which multiple applications operate simultaneously. That is, multiple applications may be operated in combination on one screen.

Therefore, when a plurality of applications use a single screen at the same time or at time intervals, ranking on Z-order is necessary. For example, in the process of a specific application (EPG Xlet Application) (first application) operating on the screen with the highest priority, other applications (second application) (e.g., emergency message delivery) This is because the application (the second application) must preempt the screen first in order to express the highest priority on the screen. If such screen control is not properly performed, information important to a user or the like may not be delivered in a timely manner, which may cause inconvenience.

Relatedly, there is a method of controlling a screen by using a separate application (hereinafter, referred to as “control application”) having more control than other applications to adjust the priority of the screen. Here, the control application has the authority to approve or reject the change on the top of the screen or on the Z-order at the request of another application.

However, this is possible when the control application knows the status and current operation of other applications. That is, the screen control is possible only if information on which application the control application is currently operating and whether there is another UI (User Interface) on the Z-order. However, it is practically impossible and inefficient for a control application to grasp all operating scenarios of all applications.

Accordingly, the present invention intends to use a method of inducing an individual application to be freely positioned in the order in which it has been reviewed in advance in relation to a screen control on a portion to be located between a plurality of applications. This is much more efficient than using a control application.

To this end, in the present specification, it is intended to expand and use the contents in consideration of compatibility with existing related standards. That is, the description will be given of defining priority information related to screen control of an individual application and controlling the screen using the information defined in the control unit instead of the control application. Here, priority information related to screen control of an individual application is information that is defined and transmitted by a transmitter in accordance with a predetermined criterion and the like, and a part of each application to be located on the screen (for example, a layer). In general, information related to the screen control is collectively referred to as information related to the assigned order. Hereinafter, the information is referred to as application priority information. The controller may be, for example, middleware (M / W) of a receiver.

Therefore, according to the present invention, the transmitting end transmits the application priority information, and the receiving end receives the application priority information. When a request related to screen control is received from each application, the receiving end performs screen control by using the received application priority information.

Hereinafter, the screen control method according to the present invention will be described in more detail.

First, application priority information used for screen control according to the present invention will be described.

The application priority information is used by the middleware (M / W) according to the request related to the screen control of the application. Here, the information about the application priority may be included in, for example, an eXtended Application Information Table (XAIT) among a plurality of signaling information in a broadcast signal transmitted from a transmitter. Accordingly, the middleware (M / W) parses the application priority information in the XAIT table and stores the application priority information in the storage medium, and according to the priority of the application appropriate from the application priority information stored in the storage medium in response to a request of each application. You can respond.

Here, the application priority information may be defined and used, for example, as shown in the following table.

Priority GraphicDevice 1-10 One 11-20 2 21-30 3 ... ... 240-255 25

In general, one application uses only one graphic device. Accordingly, the present invention extends this portion to obtain a graphics device based on the priority of each application, thereby solving the above problems.

Referring to Table 1, priorities are assigned to each application from 1 to 255, and graphics devices corresponding to the priorities are assigned from 1 to 25. Here, in Table 1, for the purpose of describing one embodiment of the present invention, it is noted that it is not limited thereto. That is, in Table 1, an application with priority 1 to 10 allocates graphic device 1, and an application with priority 11 to 20 assigns graphic device 2, and prioritizes in the same manner as described above. An application with a rank of 240 to 255 may allocate a graphics device number 25. However, unlike Table 1 described above, one priority and one graphic device may be in one-to-one correspondence. This may be expressed in various combinations as previously determined by the transmitter.

5 illustrates a graphic device layer structure according to an embodiment of the present invention. Here, the graphic device shows a layer structure for the graphic device 25 from the graphic device 1 with reference to Table 1 above, and virtually manages it in the middleware. Referring to FIG. 5, the graphics device may have its own layer, thereby allowing the Z-order to be independent among certain priorities. That is, graphic device 25 represents the layer with the highest priority, graphic device 1 represents the layer with the lowest priority, and graphic device 25 is always positioned before graphic device 1, which is the priority. To ensure that.

Hereinafter, the screen control method according to the present invention will be described with an operation scenario.

6 is a flowchart illustrating a screen control method according to an embodiment of the present invention. Components described below will be described with reference to FIGS. 3 and 4.

In FIG. 6, a transmitter receives an application priority information predefined by assigning a priority for each application and a graphic device corresponding to the application, and receives the information related to screen control according to the present invention using the received information. Explain mainly.

The middleware 400 receives application priority information defined as shown in Table 1 above (S601). The middleware 400 parses the received application priority information and stores it in the storage medium 402 (S602).

When the middleware 400 receives a signal for requesting a graphic device from the application 401 (S603), the middleware 400 obtains application priority information of the corresponding application from the application priority information stored in the storage medium 402 according to the received request. Extract (S604). That is, the middleware 400 first checks the priority assigned to the corresponding application and determines what graphic device object corresponds to the checked priority. Here, a specific application (Xlet Application) calls getHGraphicsDevices of the HScreen class to obtain a graphics device. The actual implementation of the class is made in the middleware 400 that satisfies the relevant standard.

In the above description, an example of parsing and storing application priority information in the middleware 400 is described as an example. However, it is not necessary to parse and store the application priority information before the request, and the above-described process may be performed after receiving the request. In addition, although it was described above that the application priority information is directly received from the middleware 400 and parsed, the middleware 400 controls the receiving and parsing of the application priority information from the other components of FIG. Can also be used.

Therefore, the middleware 400 returns the graphic device object according to the application priority information extracted in the step S604 to the corresponding application (S605).

In the above, the request from the application 401 and the return of the graphic device object of the middleware 400 may both be performed according to the same function, for example, the HScreen.getHGraphicsDevices () function.

When the corresponding graphic device object is returned from the middleware 400, the application 401 generates an HScene according to operation S606, and operates according to the generated HScene.

Here, in connection with the present invention, the Xlet Application 401 needs HScene to draw something on the screen. HScene is a basic class that allows one to be assigned to each application to control the screen. Conceptually, HScene is dependent on HGraphicDevice, and HScene can be obtained using HGraphicDevice.

In addition, an associated API (Application Programming Interface) may be defined as described below. API refers to an interface created to control functions provided by an operating system (OS) or programming language for use in an application. The API is mainly used for file control, window control, image processing, character control, etc. Provides an interface for

public HScene getFullScreenScene (HGraphicsDevice device)

That is, a specific application (Xlet Application) may be displayed on the screen by using the HScene dependent on the HGraphicDevice as described above.

The present invention intends to be able to control the order of the HScene by delivering the HGraphicDevice from which the HScene can be obtained based on the application priority. Although described above in connection with the present invention, the description of the parts omitted in relation can be described with reference to the related standards.

Through the above-described process, screen control can be appropriately performed by allocating an appropriate graphic device object using application priority information corresponding to an individual application according to the present invention.

In connection with the present invention, the receiver receives application priority information from the transmitting end as shown in Table 1 above for individual applications related to screen control. The receiver parses and stores the received application priority information.

An embodiment of an operation scenario using the screen control method according to the present invention described above is as follows. 7 is a view illustrating an operation scenario according to an embodiment of the present invention.

In one embodiment of the operation scenario of the present invention, the return value of the HScreen.getHGraphicsDevices () method is transmitted based on the application priority and obtained through the HScreen.getHGraphicsDevices () method. The Graphic Device Object corresponds to a specific Z-order, and the HScene created using this corresponds to Application Priority, so that other control applications do not need to control the screen.

In the following description of an embodiment of an operation scenario according to the present invention, description of related functions and the like will be omitted.

Referring to FIG. 7, it can be seen that four applications operate on one screen. That is, the screen control method will be described when four applications, a monitor application, a VOD application, a next application, and a pop-up application, must be represented on the screen.

Here, for convenience of explanation, it is assumed that the transmitting end transmits application priority information defined as shown in Table 1 and the receiving end receives the information. In addition, when referring to the application priority information, assume the priority of each application and the graphics device as follows. Referring to FIGS. 7A to 7D, the monitor application has a priority value of 5, a VOD application has a priority value of 13, a next application has a priority value of 27, and a pop-up application has a priority. If the rank value is 255, each application will sequentially return graphics device 1, graphics device 2, graphics device 3 and graphics device 25 from the middleware.

Therefore, when each application generates an HScene according to the returned corresponding graphic device as shown in FIG.

According to the present invention, it is possible to efficiently control the screen because a separate control application is not required for screen control, and it is not necessary to consider operating scenarios of various and complicated applications, and thus an efficient system can be constructed. In addition, it will be possible to deliver information important to the user in a timely manner and contribute to the user's convenience.

Although the preferred embodiments of the present invention have been shown and described above, the present invention is not limited to the specific embodiments described above, and the present invention is not limited to the specific scope of the present invention as claimed in the claims. Anyone skilled in the art can make various modifications, as well as such modifications are within the scope of the claims.

1 is a structural diagram illustrating a hierarchical structure of a broadcast receiver according to the present invention.

2 is a conceptual diagram illustrating an example of a life cycle of an application in connection with the present invention.

3 is a block diagram of a broadcast receiver configured according to an embodiment of the present invention.

4 is a block diagram showing the configuration of a preferred embodiment of the middleware according to the present invention.

5 illustrates a graphic device layer structure according to an embodiment of the present invention.

6 is a flowchart illustrating a screen control method according to an embodiment of the present invention.

7 is a view illustrating an operation scenario according to an embodiment of the present invention.

* Description of the main signs of the invention

400: middleware 401: application

402: storage medium 410 interface module

420: screen control module

Claims (11)

Receiving a graphics device request command from an application; Extracting application priority information of the corresponding application according to the request; And And returning the graphic device object according to the extracted application priority information to a corresponding application. The method of claim 1, Receiving signaling information including application priority information; Parsing application priority information in the received signaling information. 3. The method of claim 2, And storing the parsed application priority information. The method of claim 1, The application, And generating an HScene for the layer according to the returned graphic device object. The method of claim 1, The request and return is a screen control method, characterized in that using the getHGraphicsDevices () function predefined in the HScreen class. The method of claim 1, The application priority information includes first information related to the priority of an individual application and second information defining a graphic device allocated corresponding to the first information. 3. The method of claim 2, And the application priority information is included in the XAIT table in the signaling information and transmitted. A tuner unit configured to receive a digital broadcast signal including signaling information including application priority information; A demodulator for demodulating the received digital broadcast signal; A demultiplexer for demultiplexing signaling information in the demodulated digital broadcast signal; And Receives and parses application priority information in the demultiplexed signaling information, extracts the received application priority information when a graphic device request is received from an application, and extracts the graphic device object according to the extracted application priority information from the corresponding application. And a processor unit to return to the digital broadcasting receiver. The method of claim 8, And a storage medium storing the application priority information parsed by the processor. The method of claim 9, The processor unit includes a plurality of applications and middleware, The middleware, And an interface module for transmitting and receiving information or requests with the respective applications, and a screen control module for controlling to return the graphic device object according to the application priority information to the corresponding application according to the graphic device request of the respective application. Digital broadcast receiver. The method of claim 10, The screen control module, Extract first information regarding a priority of each application in the parsed application priority information and second information defining a graphic device allocated corresponding to the first information according to a graphic device request of the respective application; Digital broadcast receiver characterized in that for controlling.

Images