KR20090105324A - Middlleware for supporting digital broadcast, broadcasting receiver, method for managing information about allocating resources of broadcasting receiver, recording media for the method - Google Patents

Abstract

PURPOSE: A middleware for supporting the digital broadcasting is provided to enable an application to confirm the used amount of its resources by managing information about resources allocated to the application, and providing it to the application. CONSTITUTION: A middleware(400) for supporting the digital broadcasting comprises an interface module(410) and a resource information management module(420). The interface module transmits/receives information and commands to/from an application(401). The resource information management module manages the resource allocation information, that is, information about resources assigned to the application, and transmits the resource allocation information to the interface module when a resource information request command is received from the interface module.

Description

Recording medium recording middleware supporting digital broadcasting, method for managing allocation information for broadcast receiver and broadcast receiver resources, and method for managing allocation information for broadcast receiver resource {Middlleware for supporting digital broadcast, broadcasting receiver, method for managing information about allocating resources of broadcasting receiver, recording media for the method}

The present invention relates to a recording medium for recording middleware supporting digital broadcasting, a method of managing allocation information for a broadcast receiver and a broadcast receiver resource, and a method of managing allocation information for a broadcast receiver resource. The present invention relates to middleware, a broadcast receiver, and a method for allocating resources to an executed application and managing the resources.

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 receivers by transmitting multimedia data such as text, still images, graphics, documents, and software, and is a service that best fits 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 generally include, for example, Digital Video Broadcasting (DVB) (including DVB-C (cable), DVB-T (terrestrial), and DVB-S (satellite)), OpenCable.TM. Application platforms. 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 functionality set top boxes, integrated digital TV sets and multimedia PCs.

Version 1.0.3 of the MHP standard supports free downloadable applications called 'Xlets'. 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.

The technical problem to be achieved by the present invention is to solve the problem that the application operates without significant consideration of the resource usage, the resource state of the broadcast receiver leads to the resource limit that the resource is exhausted, and thereby interferes with the operation of other applications The present invention provides a method for managing allocation information for middleware, a broadcast receiver, and a broadcast receiver resource that supports digital broadcasting that can provide information about a resource allocated to an application to the application.

Another technical problem to be solved by the present invention is to enable an application to set a limit on the resource usage allocated to the application, and when the usage of the resource allocated to the application reaches the set limit, the information that the application has reached the limit. The present invention provides a method for managing allocation information for middleware, a broadcast receiver, and a broadcast receiver resource that supports digital broadcasting.

Another object of the present invention is to provide a computer-readable recording medium having recorded thereon a program for executing a method of managing allocation information for a broadcast receiver resource on a computer.

In order to achieve the above technical problem, the middleware for supporting digital broadcasting according to the present invention includes an interface module for transmitting and receiving information and commands with an application; And a resource information management module that manages resource allocation information, which is information about resources allocated to an application, and transmits the resource allocation information to the interface module when a resource information request command is received from the interface module.

Preferably, the resource information management module receives a resource limit setting command including a resource limit setting value from the interface module, and compares an application resource usage value and resource limit setting value included in the resource allocation information to reach a resource limit. Determine whether or not.

Preferably, the resource information management module includes: a resource allocation information management unit for updating existing resource allocation information based on the information on the allocated resource when a resource is allocated to the application; Receiving a resource limit setting command including a resource limit setting value from the interface module, and when the resource allocation information is updated, the resource limit setting value is compared by comparing the application resource usage value and the resource limit setting value included in the resource allocation information. A resource limit investigation unit determining whether an arrival warning event has occurred; And a resource allocation information providing unit for transmitting the resource allocation information to the interface module when a resource information request command is received from the interface module.

In this case, the application is preferably an Xlet application in a MHP (Multimedia Home Platform) based standard. In addition, the resource is preferably a shared resource. In addition, the resource may include at least one of a memory and a thread.

In order to achieve the above another technical problem, a broadcast receiver according to the present invention includes a middleware according to the present invention.

According to another aspect of the present invention, there is provided a method of managing allocation information for a broadcast receiver resource, the method comprising: receiving a resource allocation request command from an application; Allocating the requested resource to an application; And an updating step of updating resource allocation information based on the information about the resource allocated to the application.

Preferably, the method for managing allocation information for a broadcast receiver resource according to the present invention comprises: receiving a resource information request command from an application; And providing the resource allocation information to the application.

Preferably, the method for managing allocation information for a broadcast receiver resource according to the present invention comprises: receiving a resource limit setting command including a resource limit setting value from an application; A comparison step of comparing the received resource limit setting value with an application resource usage value included in the resource allocation information; And providing a resource limit arrival warning event when the application resource usage value is equal to or greater than a resource limit setting value.

Preferably, the comparing step may be performed when the updating step is performed.

Here, preferably, the application may be an Xlet application in a MHP (Multimedia Home Platform) based standard, and the resource may be a shared resource. In addition, the resource may include at least one of a memory and a thread.

Another object of the present invention is to provide a computer-readable recording medium having recorded thereon a program for executing a method of managing allocation information for a broadcast receiver resource according to the present invention.

According to the method for managing allocation information for middleware, broadcast receiver, and broadcast receiver resources supporting digital broadcasting according to the present invention, the application manages resource allocation information, which is information about resources allocated to the application, and provides the same to the application. It is possible to check the usage of resources and manage its own resources on the basis of this, so that the resource status of the broadcast receiver can not reach the resource limit when the resource is depleted, and the resource state of the broadcast receiver can reach the resource limit. This can prevent the operation of other applications from interfering.

In addition, an application may set a limit on resource usage allocated to the application. When the application sets a threshold using the application, it is determined whether the usage of the resource allocated to the application reaches the set threshold based on the resource allocation information. By providing the result to the application, the application can prevent the broadcast receiver's resource status from reaching the resource limit quickly without affecting the service provided to the user by performing a predetermined operation when the limit is reached. .

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;

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

5 is a block diagram showing the configuration of a preferred embodiment of a resource information management module;

6 illustrates an example of an specification of an API for an interface module;

7 illustrates another example of an specification of an API for an interface module, and

8 is a flowchart illustrating a process of performing an embodiment of a method for managing allocation information for broadcast receiver resources according to the present invention;

9 is a flowchart illustrating a process of performing another preferred embodiment of the method for managing allocation information on a broadcast receiver resource according to the present invention;

10 is a flowchart illustrating a process of performing another preferred embodiment of the method for managing allocation information on a broadcast receiver resource according to the present invention.

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 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 ISO / IEC1381-6, where the applications 111, 112,. 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.

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 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. 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 TVTV 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, but may be applied to other data broadcasting standards, and this point is apparent when considering the claims of the present specification.

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 to a user. Allows input of Video 1, Video 2, and so on.

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. To this end, 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 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 basic 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 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. Hardware resources refer to tuners, demodulators, CAs, demultiplexers, decoders, memory, hard disks, and network adapters. 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 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. 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, and as described above, the middleware 120 may use the application 110 for this purpose. And mediate 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. Such a structure may reach a resource limit of the broadcast receiver 100, and may possibly interfere with the operation of another application. In extreme cases, the entire service of the broadcast receiver 100 may be stopped. There are two reasons for this. One may be because the middleware 120 does not control the resource used by the application 110 to control the use of more than a certain limit. Another reason is that the application 110 does not consider managing the resources that it is using. Accordingly, the middleware 120 may provide the application 110 with information for managing and managing information on resources used by the application 110.

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 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 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 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 and outputs it to the demultiplexer 314. The demultiplexer 314 is a digital data stream, which is a signal output from the CA 313, a data stream (for example, MPEG-2 format) representing audio and video, and applications in the form of DSM-CC object carousel that is 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 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 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.

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.

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 unit 388 supports the application 370 to enable network communication, and controls the network interface 323 for this purpose.

The process 380 may be implemented as a single process or a multi-process, the tuner control unit 381 of the middleware 380, CA control unit 382, MPEG-2 SECTION FILTER 383, service information processing unit 384, The DSM-CC 385, the media control unit 386, the storage control unit 387, and the communication unit 388 may be 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 unit 388 may be used to mediate.

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 includes an interface module 410 and a resource information management module 420 as corresponding to the middleware 380. The interface module 410 and the resource information management 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, and the storage medium 402 is a component corresponding to the storage medium 322.

The interface module 410 exchanges information or commands with the application 401. When the application 401 transmits a resource information request command, the interface module 410 receives the resource information request command and transmits the received resource information request command to the resource information management module 420. When the resource information management module 420 transmits resource allocation information related to the resource information request command, the interface module 410 responds to the resource information request command requested by the application 401, and the resource information management module 420. The transmitted resource allocation information is transmitted to the application 401. In this case, the resource allocation information means information about a resource allocated to the application 401. Table 1 below shows an example of resource allocation information.

Application ID Memory Thread Communication session OX4200 5M One One OX4300 20M 2 One OX4400 40M 4 0

The resource allocation information transmitted by the interface module 410 to the application 401 may be the amount or number of specific resources allocated. That is, the allocated memory usage amount 65M may be transmitted to the application 401 as resource allocation information. In addition, the resource allocation information may be the amount or number of all resources allocated. That is, the allocated memory amount 66M, the allocated thread number 7, and the allocated communication session number 2 may be transmitted to the application 401 as resource allocation information. In addition, the resource allocation information transmitted by the interface module 410 to the application 401 may be information about a resource allocated to the application 401 which has transmitted the resource information request command. That is, when an application with an application ID of OX4200 transmits a resource information request command, the interface module 410 uses 5M, the number of threads, and 1, which is a communication session, as resource allocation information as the amount of memory allocated to the application having the application ID of OX4200. Send to an application whose application ID is OX4200.

When the application 401 transmits a resource allocation request command, the interface module 410 receives the resource allocation request command and transmits the received resource allocation request command to the resource information management module 420. The resource information management module 420 allocates the corresponding resource to the application 401 according to the resource allocation request, and updates the existing resource allocation information based on the information about the allocated resource. Here, the interface module 410 may transmit a resource allocation request command to another module included in the application manager 127 or the system service 126. In this case, the application manager 127 or another module included in the system service 126 that has received the resource allocation request command allocates the resource to the application 401 according to the resource allocation request and provides information about the allocated resource. When transmitting to the resource information management module 420, the resource information management module 420 updates the existing resource allocation information based on the received information.

When the application 401 transmits the resource limit setting command, the interface module 410 receives the resource limit setting command and transmits the received resource limit setting command to the resource information management module 420. Then, the resource information management module 420 sets a resource limit setting value for each resource included in the resource limit setting command.

When the resource information management module 420 generates a resource limit arrival warning event, the interface module 410 may transmit a resource limit arrival warning event to the application 401.

5 is a block diagram showing the configuration of a preferred embodiment of the resource information management module.

Referring to FIG. 5, the resource information management module 420 manages resource allocation information, which is information about a resource allocated to the application 401, and receives resource allocation information when a resource information request command is received from the interface module 410. Transmit to interface module 410. In addition, the resource information management module 420 receives a resource limit setting command including a resource limit setting value from the interface module 410, and compares the resource limit setting value with the application resource usage value included in the resource allocation information. Determine if you have reached it. To this end, the resource information management module 420 includes a resource allocation information management unit 510, a resource limit investigation unit 520, and a resource allocation information providing unit 530.

The resource allocation information manager 510 updates existing resource allocation information based on the information about the resource allocated to the application 401. When the application 401 transmits a resource allocation request command, the resource allocation information manager 510 receives a resource allocation request command transmitted by the application 401 through the interface module 410. The resource allocation information manager 510 allocates the corresponding resource to the application 401 according to the resource allocation request, and updates the existing resource allocation information based on the allocated resource information. For example, when an application having an application ID of OX4200 requests a thread creation with a resource allocation request command, the resource allocation information manager 510 creates a thread allocated to an application having an application ID of OX4200, as shown in Table 2 below. The resource allocation information of Table 1 is updated based on the generated information.

Application ID Memory Thread Communication session OX4200 5M 2 One OX4300 20M 2 One OX4400 40M 4 0

The resource limit research unit 520 receives a resource limit setting command including a resource limit setting value from the interface module 410. The resource limit survey unit 520 may store the resource limit setting value together with the resource allocation information or separately. Table 3 below shows an example in which the resource limit survey unit 520 stores resource limit setting values together with resource allocation information.

Application ID Memory Thread Communication session Memory limit setting Thread limit setting Communication session limit setting value OX4200 5M 2 One 100M 4 2 OX4300 20M 2 One Unspecified Unspecified Unspecified OX4400 40M 4 0 50M 5 Unspecified

The application with the application ID of OX4200 set the memory limit setting to 100M, the thread limit setting of 4, the communication session limit setting of 2, the application with the application ID of OX4300 did not set the resource limit, and the application ID of the OX4400. The application set the memory limit setting to 50M, the thread limit setting to 5, and did not set the communication session limit setting.

In another embodiment, the resource allocation information management unit 510 may store the resource limit setting value together with the resource allocation information instead of the resource limit research unit 520.

When the resource allocation information is updated, the resource limit investigation unit 520 compares the application resource usage value included in the resource allocation information and the resource limit setting value to determine whether a resource limit arrival warning event has occurred. That is, when an application having an application ID of OX4400 receives a resource allocation request command requesting memory 10M addition to the interface module 410 and is allocated memory 10M, the resource allocation information manager 510 receives information to which the memory 10M is added. On the basis, the resource allocation information of Table 3 is updated as shown in Table 4 below.

Application ID Memory Thread Communication session Memory limit setting Thread limit setting Communication session limit setting value OX4200 5M 2 One 100M 4 2 OX4300 20M 2 One Unspecified Unspecified Unspecified OX4400 50M 4 0 50M 5 Unspecified

The resource limit research unit 520 compares the memory usage value 50M, which is the resource allocation information, with the memory limit setting value 50M, and determines that the memory usage value of the application whose application ID is OX4400 has reached the memory limit setting value. Determine that a warning event should be raised. Here, the resource limit investigator 520 may directly generate a resource limit reach warning event or allow another module included in the system service 126 to generate a resource limit reach warning event. The resource limit reached warning event is sent to the application with application ID OX4400, and the application with application ID OX4400 knows that the resource limit has been reached through the received resource limit reached warning event. Can be done.

6 is a diagram illustrating an example of an specification of an API for an interface module.

Referring to FIG. 6, the resource limit setting unit 520 receives the resource information setting command from the application 401 and sets the resource limit setting unit 520 to set the resource limit setting value included in the resource information setting command. The interface module 410 that transmits the data may be represented by the SystemResourceManager 600. SystemResourceManager (600) is defined as a class that implements ResourceServer (601) defined as a Java interface in org.davic.resources. setMaxMemory 610 is a method corresponding to a resource information setting command for setting a memory limit setting value. setMaxMemory 610 may have appID 611 and size 612 as parameters. Here, appID 611 means an application ID, and size 612 means a memory limit setting value. When the application 401 calls SystemResourceManager.setMaxMemory (OX4200, 100M), the memory limit setting value of the application whose application ID is OX4200 is set to 100M.

setMaxThread (620) is a method corresponding to a resource information setting command for setting a thread limit setting value. setMaxThread 620 may have appID 621 and amount 622 as parameters. Here, appID 621 denotes an application ID, and amount 622 denotes a thread limit setting value. When the application 401 calls SystemResourceManager.setMaxThread (OX4400, 5), the thread limit setting of the application whose application ID is OX4400 is set to 5.

addResourceStatusEventListener 630 is a method of registering a listener to receive a resource limit warning event, and has a listener 631 to receive a resource limit warning event as a parameter.

removeResourceStatusEventListener 640 is a method for removing a listener registered to receive a resource limit reached warning event, and has a listener (listenenr) 641 to remove as a parameter.

Here, the listener 631 and the listener 641 are of ResourceStatusListener type, and ResourceStatusListener is defined in org.davic.resources.

 When a resource information request command is received from the interface module 410, the resource allocation information providing unit 530 transmits resource allocation information to the interface module 410. When the application 401 transmits a resource information request command, the interface module 410 receives the resource information request command and transmits the received resource information request command to the resource allocation information providing unit 530. The resource allocation information providing unit 530 detects resource allocation information related to the resource information request command and transmits the detected resource allocation information to the interface module 410.

7 is a diagram illustrating another example of an specification of an API for an interface module.

Referring to FIG. 7, an interface module 410 that receives a resource information request command from an application 401 and transmits corresponding resource allocation information to the application 401 in response thereto may be represented by a SystemResourceStatusEvent 700. SystemResourceStatusEvent 700 inherits ResourceStatusEvent defined in org.davic.resources. getUsedMemory 710 is a resource information request command for requesting a usage value of memory allocated to the corresponding application 401 among resource allocation information. GetUsedThread 720 is a resource information request command for requesting a usage value of a thread allocated to the corresponding application 401 among resource allocation information. When the application 401 calls SystemResourceStatetusEvent.getUsedMemory, the interface module 410 receives it and transmits it to the resource allocation information providing unit 530. The resource allocation information providing unit 530 detects the usage value of the memory allocated to the application 401 calling the resource allocation information SystemResourceStatusEvent.getUsedMemory, and transmits it to the application 401 through the interface module 410.

When the application 401 calls SystemResourceStatusEvent.getUsedThread, the interface module 410 receives it and transmits it to the resource allocation information providing unit 530. The resource allocation information providing unit 530 detects the use value of the thread allocated to the application 401 calling the resource allocation information SystemResourceStatusEvent.getUsedThread, and transmits the value to the application 401 through the interface module 410.

8 is a flowchart illustrating a process of performing a preferred embodiment of the method for managing allocation information on a broadcast receiver resource according to the present invention.

Referring to FIG. 8, the interface module 410 receives a resource limit setting command including a resource limit setting value from the application 401 (S800). The resource limit research unit 520 registers the resource limit setting value included in the resource limit setting command received by the interface module 410 (S810).

The interface module 410 receives a resource allocation request command from the application 401 (S820). The resource allocation information providing unit 530 allocates the resource requested by the application 401 to the application 401 and updates the resource allocation information based on the information about the resource allocated to the application 401 (S830). Then, the resource limit investigation unit 520 compares the set resource limit setting value with the application resource usage value included in the resource allocation information (S840).

If the application resource usage value is greater than or equal to the resource limit setting value, the resource limit investigation unit 520 allows a resource limit reach warning event to be provided to the application 401 (S850). Here, the resource limit survey unit 520 may directly generate a resource limit reach warning event, and may be generated by another module included in the system service 126.

9 is a flowchart illustrating a process of performing another preferred embodiment of the method for managing allocation information on a broadcast receiver resource according to the present invention.

Referring to FIG. 9, the interface module 410 receives a resource information request command from an application 401 (S900). The resource allocation information providing unit 530 provides the resource allocation information to the application 401 (S910). The interface module 410 receives a resource allocation request command from the application 401 (S920). The resource allocation information providing unit 530 allocates the resource requested by the application 401 to the application 401 and updates the resource allocation information based on the information about the resource allocated to the application 401 (S930).

10 is a flowchart illustrating a process of performing another preferred embodiment of the method for managing allocation information on a broadcast receiver resource according to the present invention.

Referring to FIG. 10, the interface module 410 receives a resource limit setting command including a resource limit setting value from the application 401 (S1000). The resource limit research unit 520 registers the resource limit setting value included in the resource limit setting command received by the interface module 410 (S1010).

The interface module 410 receives a resource allocation request command from the application 401 (S1020). The resource allocation information providing unit 530 allocates the resource requested by the application 401 to the application 401 and updates the resource allocation information based on the information about the resource allocated to the application 401 (S1030). Then, the resource limit investigation unit 520 compares the set resource limit setting value with the application resource usage value included in the resource allocation information (S1040).

If the application resource usage value is equal to or greater than the resource limit setting value, the resource limit investigation unit 520 causes the resource limit arrival warning event to be delivered to the application 401 (S1050). Here, the resource limit survey unit 520 may directly generate a resource limit reach warning event, and may be generated by another module included in the system service 126.

The interface module 410 receives a resource information request command from the application 401 (S1060). The resource allocation information providing unit 530 provides the resource allocation information to the application 401 (S1070).

The invention can also be embodied as computer readable code on a computer readable recording medium. The computer-readable recording medium includes all kinds of recording devices in which data that can be read by a computer device is stored. Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage, and the like, and may also be implemented in the form of a carrier wave (for example, transmission over the Internet). Include. The computer readable recording medium can also be distributed over network coupled computer devices so that the computer readable code is stored and executed in a distributed fashion.

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.

Claims (15)

An interface module for transmitting and receiving information or commands with an application; And And a resource information management module managing resource allocation information, which is information about resources allocated to an application, and transmitting the resource allocation information to the interface module when a resource information request command is received from the interface module. Middleware that supports digital broadcasting. The method of claim 1, The resource information management module, Receiving a resource limit setting command including a resource limit setting value from the interface module, and comparing the application resource usage value and the resource limit setting value included in the resource allocation information to determine whether the resource limit is reached or not; Middleware that supports broadcasting. The method of claim 2, The resource information management module, A resource allocation information management unit for updating the existing resource allocation information based on the information on the allocated resource when a resource is allocated to the application; Receiving a resource limit setting command including a resource limit setting value from the interface module, and when the resource allocation information is updated, the resource limit setting value is compared by comparing the application resource usage value and the resource limit setting value included in the resource allocation information. A resource limit investigation unit determining whether an arrival warning event has occurred; And When the resource information request command is received from the interface module, the resource allocation information providing unit for transmitting the resource allocation information to the interface module; middleware supporting digital broadcasting. The method of claim 1, The application is a middleware supporting digital broadcasting, characterized in that the Xlet (Xlet) application in the specification based on the Multimedia Home Platform (MHP). The method of claim 1, The middleware supporting digital broadcasting, characterized in that the resource is a shared resource. The method of claim 1, And the resource includes at least one of a memory and a thread. A broadcast receiver comprising the middleware supporting the digital broadcasting according to any one of claims 1 to 6. Receiving a resource allocation request command from an application; Allocating the requested resource to an application; And And updating the resource allocation information based on the information about the resource allocated to the application. The method of claim 8, Receiving a resource information request command from an application; And And providing the resource allocation information to the application. The method of claim 8, Receiving a resource limit setting command including a resource limit setting value from an application; A comparison step of comparing the received resource limit setting value with an application resource usage value included in the resource allocation information; And If the application resource usage value is equal to or greater than a resource limit setting value, providing a resource limit arrival warning event. The method of claim 10, The comparing step, Method for managing allocation information for a broadcast receiver resource, characterized in that performed when the update step is performed. The method of claim 8, The application is a method for managing allocation information for a broadcast receiver resource, characterized in that the Xlet (Xlet) application in the Multimedia Home Platform (MHP) based standard. The method of claim 8, And the resource is a shared resource. The method of claim 8, And the resource includes at least one of a memory and a thread. A computer-readable recording medium having recorded thereon a program for executing a method of managing allocation information for a broadcast receiver resource according to any one of claims 8 to 14.