MXPA01003617A - Software application lifecycle and management for broadcast applications - Google Patents

Abstract

A software architecture for managing applications at a television set-top terminal. An Application Programming Interface (API) provides an ITU-T X.731-based mechanism for monitoring and controlling the applications. Applications, such as a grogram guide, stock ticker or the like, are recovered at the terminal according to an associated locator. The applications are registered (205) and installed at the terminal, and a user is notified of the presence of the applications after registration thereof. The API (270) enables running, pausing, resuming and stopping of the applications. The API also enables the applications to advertise their respective states to other applications, such as alarm statuses (325), availability statuses (330), procedural statuses (335), operational states (310), administrative states (305), and usage states (315).

Description

LIFE CYCLE AND PROGRAM APPLICATION ADMINISTRATION AND PROGRAMMING SYSTEMS FOR EMISSION APPLICATIONS BACKGROUND OF THE INVENTION The present invention provides an architecture of programs and programming systems for managing applications in an upper terminal of a television set. The following acronyms and terms were used API Programming Interface ATSC Application - Television Systems Committee Advanced DASE - Digital TV Application Programming and Programming Environment ATSC T3 / S17 DAVIC Digital Audio-Video Board DTV - Digital TV EPG - Electronic Programming Guide IRD - Integrated Receiver Decoder; ISO - International Standards Organization; JVM - Java Virtual Machine PSIP - Program and Systems Information Protocol (for Terrestrial and Cable Emissions) RAM - Random Access Memory and UML - Unified Simulation Language A superior device terminal, also known as an IRD or a terminal subscriber, is a device that receives and decodes television signals for presentation by means of a television, the signals can be delivered on a satellite, through a ground floor, or by means of a terrestrial broadcast, for example Several applications have been proposed, or are currently available, via modern superior devices, including video on demand (VOD), audio on demand, pay per event, interactive shopping, electronic commerce, electronic programming guides, Internet browsers , mail services (for example, e-mail in the form of text, voice mail, audio mail and / or video mail), television services phone, quote indicator, weather data, travel information, games, betting, banking, shopping, voting and others. Applications can also allow connectivity to the Internet and possibly Internet-based telephony. The functionality of the superior apparatus is activated through physical computing components and specialized programs and programming systems.

In addition, with the increasing integration of computer networks such as the Internet, telephony networks and broadcast distribution networks, many opportunities arise to provide new types of 5 applications. Applications can be communicated to a higher appliance terminal via a network, locally loaded (for example, via a smart card), or fc installed at the time of manufacture, for example. In particular, the Service Requirements of the DASE Application Administration System propose a number of requirements for managing the applications in a higher appliance terminal. This is a section of the ATSC T3 / S17 specification which describes the requirements related to the administration of the application (Section 13). Accordingly, it would be desirable to provide programs and programming system for superior apparatuses to handle applications in a terminal of upper appliance. Programs and programming systems should provide an API to retrieve and register new applications that are received at the terminal, for example, via a download of an input section, and provide an identifier for each application.

The API must be independent of the operating system and the physical computing components of the terminal. It would be desirable to provide a mechanism based on the ITU-T X.731 for the verification and control application. The mechanism should control the start, stop, pause and resumption of applications. The mechanism should allow an application to notify its status to other applications, and allow other applications to access the notified state. The mechanism should allow the recovery of the application and information of the version of the resources. The mechanism should allow access to the location information of the application. The mechanism shall provide verification of the integrity of an application, and validation of the suitability of the application to be used in the terminal of the superior apparatus. The mechanism must notify the user of the existence of a new application after it is registered. The mechanism must provide an administrative lock or unlock of an application.

The mechanism shall notify the operational status, alarm status and availability status • of an application. The architecture must be compatible with Java (mr), ActiveX (mr) or an equivalent type of object-oriented technology based on the component. The mechanism should be suitable for use with any application in a terminal, regardless of how it has been received or installed. • The present invention provides a system having the foregoing and other advantages.

BRIEF DESCRIPTION OF THE INVENTION The present invention provides a programming architecture and programming systems for. administer applications in a television terminal • superior device. An upper terminal of a television set includes a computer readable medium having means 20 for encoding computer programs, and means for executing means for encoding computer programs to implement an application programming interface (API). With the API, the application data defining applications are retrieved at terminal 25 according to the locators associated with the applications. For example, the locator may be a PID, channel number, channel name, Transport Flow ID, Service ID, a combination thereof, or something else. The locator can be in form 5 of a Uniform Resource Locator (URL). The applications are registered and installed in the terminal, and a user is notified of the presence of the applications after the registration and installation of the same. In this way, the user is • 10 notified when the application becomes available locally in the terminal and is ready to be invoked / initiated. An application may use a resource, usually a device, function or process in the receiver (eg, tuner, modem, database, etc.). • The API allows the recovery of applications such as applications of downloadable programs and programming systems, or applications of programs and systems of broadcast programming. The API can be independent of an operating system and physical computing components of the terminal.

The API can provide a mechanism based on ITU-T X.731 to verify and control applications. The API can allow the execution and later detention of the applications. The API can allow a pause of the applications once they are being executed, and then resume the applications. The API can allow applications • 10 individuals notify their respective states to other applications. The API can allow at least one of the other applications to access the reported state of at least one of the particular advertiser applications. An application state can have several different values (activated, deactivated, etc.). To have • Access to a state means having the ability to learn about the value of the current state. The API can allow the recovery of the version information associated with the applications. The API can allow the verification of the integrity of the applications. Integrity in this case may mean that the code that was received by the recipient is legal and valid based on the specification of the programming language used to encode the application (for example, Java programming language, etc.). The API can allow the validation of the suitability of the applications for the terminal. 5 The API can allow administrative blocking and unlocking of applications. The API can allow particular applications to notify alarm states, states of (H) availability, states of procedure, states operational, administrative states and states of use of the same to other applications. A corresponding method is also presented.

SHORT DESCRIPTION OF THE DRAWINGS 15 FIGURE 1 shows relationships and dependencies of packets according to the present invention. • FIGURE 2 represents the classes and interfaces related to the application and their relationships according to the present invention. FIGURE 3 describes those classes and interfaces related to the administration of the state according to the present invention. FIGURE 4 describes relationships between the classes of utility interfaces according to the present invention.

FIGURE 5 is an interaction / sequence diagram showing how an EPG application, which presents video channels as well as data channels with applications available on them to the user, can invoke a download and the subsequent execution of the downloaded application in accordance with the present invention. FIGURE 6 shows a set of interactions / sequences demonstrating how an application can be administered by means of an application manager and verified by an agent according to the present invention.

DETAILED DESCRIPTION OF THE INVENTION The present invention provides an architecture of programs and programming systems for managing applications in a superior apparatus television terminal. 1. General View The present invention specifies an API, which satisfies the requirements of the DASE Application Administration System Service. Note that portions of the description were automatically generated from the CASE Rational Rose (mr) tool, developed by Rational Software Corporation, USA. The exceptions and pre and postconditions associated with the individual methods are not shown. Exceptions will be displayed in a Javadoc format. 5 The figures use the Rational Rose (mr) description of the UML. FIGURES 1-4 are class diagrams and FIGURES 5 and 6 are sequence (or interaction) diagrams. A class diagram represents the static structure of a system, and shows a pattern of • 10 behaviors exhibited by the system. This is achieved by showing the existence of classes and their relationships. Each class is represented by a table with three sections. The upper section lists the class name. The middle section 'denotes a list of attributes, and the section below denotes a list of operations. A solid or discontinuous line between classes • denotes an association or dependency. A white diamond tip denotes aggregation as a reference, while a black diamond tip denotes aggregation as value. A triangular arrow head denotes a restricted navigation, for example, inheritance of the operation but not of the structure. A class is a pattern that defines a data structure, method calls and function for an object. An interface defines a set of methods / function calls that can be manipulated by a class. The class provides the code to implement an interface. • 2. REQUIREMENTS 5 The proposed APIs impose the following requirements: 1. The API will provide a document to retrieve a downloadable or erasable application. ^^ This is done via a registration mechanism, the which can specify a URL of an application (obtained from the PSIP API or its extensions based on a work T3 / S13 and S16) to be downloaded and made available. The specifications T3 / S13 and T3 / 16 of the ATSC define protocols to distribute applications to receiver, signaling its presence in the transport flow and providing information about the applications. The URL is used as an identifier for applications in an exemplary mode, but other identifiers may be used. 20 2. The API will provide a mechanism to install and uninstall an application. The Registry mechanism installs the application so that it can be invoked / started. 3. The API provides a mechanism for initialize (launch), start, and stop an application.

The Application interface provides methods to perform those actions. 4. The API will provide a mechanism to pause and resume an application. 5 The Application interface provides methods to perform those actions. 5. The API will provide a mechanism for applications to maintain a state of access. Each application implements the interface • 10 Object States can be managed in a way defined by ITU-T. The ITU-TX.731 is an international standard, which defines the states of administration, state codes and state transitions for objects (devices, resources, applications, etc.) administrable. 15 The API will provide a mechanism to retrieve version information for the application of those resources, • including the required APIs. The Application Information interface allows the retrieval of the previous information. 20 6. The API will provide a mechanism to access location information or location of the application. The location or location information of the application can be represented in a URL format (to be standardized by the ATSC) in the DAVIC Locator class. A locator is an opaque object which encapsulates a URI (Universal Resource Identifier) of a particular resource (an application in this case). 7. The API will provide a mechanism to verify the integrity of an application and validate its accuracy. For example, this means that it does not include viruses or it will not inflict any damage to the recipient. The JV.M verifier satisfies this requirement; therefore, it is not necessary to define an API to do this. 8. The API will provide a registration mechanism that allows the application to notify the user of its existence. This is done in conjunction with the PSIP and the S13 APIs, which provide information about a specific application. This information can be used to download an application by registering it with the Application Registry. Once registered, a user can use it. 3. DESCRIPTION This proposal consists of two main packages: org. atsc. application and org. atsc. administration, and an org help package. atsc. services. The first package includes classes and interfaces specific to the application. The other packet represents classes and interfaces that are related to administration application states based on the ITU-T administration standard. The latter is separated in its own package since it can be applied to any administrable object such as DTV receiver resources, or downloadable applications. An application is free to support a • 10 subset of the defined states and state attributes that are appropriate for the specific application. The DASE can send a subset of those to provide better interoperability between applications with respect to administration. Some applications can be very simple, and some of the statuses and statuses defined by the X.731 standard • may not be applicable. The ATSC can define a minimum set of statuses and state codes that are reported by all applications. Some more complex applications can support more. For example, some applications may not support the "degraded" Availability State, - they may or may not work - without anything between them. 4. OBJECT MODEL FIGURE 1 shows the relationships and dependencies of the packets according to the present invention. The org package atsc. Application 105 uses classes and interfaces defined in the org package. atsc. administration 110, the org package. atsc. 115 services and the org package. davic. network 120. The packages are logically related by the dotted arrows, which denote dependence. FIGURE 2 represents classes and interfaces related to the application and their relationships according to the present invention. An interface is marked by < < interface ", while those that are not marked are classes. Classes include: _ »Record Factory 215, Exception 220, Exception of Application Availability 225, ExceptionofApplicationYaRegistrada 230, ExceptionofApplicationNotRegistered 235, ApplicationRegistration Event 245, and Event Object 250. The interfaces include: ApplicationRegistration 205, Record 210, Application Cause 240, Listen to Application Record 255, Listen to the Status Change 260, Object States 265, Application 270 and Application Information.

FIGURE 3 describes those kinds of interfaces related to state management • according to the present invention. The elements numbered in a similar way correspond to each other in the figures. Classes or interfaces include: Administrative Status 305, Operational Status 310, Use State 315, Status of Obj 320, State of Alarm 325, Availability Status 330, Procedural Status 335, • 10 Exception of Resource Status 340, Resource Indicator 345, and Status Change Event 350. FIGURE 4 describes relationships between classes of service interfaces according to the present invention. The classes and interfaces include the 15Record Type 405.

. INTERACTION DIAGRAMS The following sections will describe exemplary interactions between related classes with the application, and show how other objects can use the Application Administration API. Since an application is made up of objects, an API accessed by other objects means that the API is accessed by parts (objects) of other applications, or by the code present in the terminal. . 1 Application Registry FIGURE 5 is an interaction / sequence diagram showing how an EPG application, which presents video channels as well as data with applications available on them to the user, can invoke a download and later execution of the downloaded application according to the present invention. The diagrams were generated using the programs and programming systems Rational Rose (mr). A number of exemplary objects are provided, including "user" 505, "EPG: Application" 270 '(an example of Application interface 270 of FIGURE 2), "PSIP Database" 515, "Data Channel" 520, "factory: Factory Registration "215," registration, Application Registry "205," downloador "525 and" ap: Application "270" (an example of the Application interface 270 of FIGURE 2) The EPG retrieves the application information including the URL (Locator), access the Application Registry via the Registration Factory and request a registration of the new application. When an application is registered with the Application Registry, the application locator (URL) is used to download the application. When this is available, the active record (for example, sends / broadcasts) an event to all listeners to indicate • that the new application is registered and available. The EPG application listens to those events and notifies the user 5 of the new availability of the application. Once the application is downloaded and installed, the user can request its execution via the registry. Registration really starts the application. ^? The previous sequence can be implemented via the following steps 1-13 copies: 1. The object "EPG: Application" 270 'calls (for example, invokes) the "obtain Virtual Channels" method of the object "PSIP Database" 515; 2. The object "EPG: Application" 270"calls the" 15 method of "obtainingAdapData" of the object "DataChannel" 520; 3. The object "EPG: Application" 270 'calls the method "submitAp" of the object "user" 505; 4. The "user" object 505 calls the "selectAp" method of the object "EPG: Application" 270 '; 20 5. The object "EPG: Application" 270 'calls the method of "getRegistration (Ordered Sequence)" of the object "factory: Registration Factory" 215; 6. The object "EPG: Application" 270 'calls the method of "Application (Locator) of Record" of the object "Registration: Application Registry" 205; 7. The object "Registration: Application Registry" 205 calls the "download" method of the object • "downloader" 525; 8. The object "Registry: Registration of 5 Application" 205 calls the method of "Change of registration (Event of Application Registration)" of the object "EPG: Application" 270 '; 9. The object "EPG: Application" 270 'calls the method of "getApplication (Locator) information" of the object "Registry: Application Registry" 205; 10. The object "EPG: Application" 270 'calls the method "presentainfodeAp" of the object "user" 505; 11. The "user" 505 object calls the "invokeAp" method of the object "EPG: Application" 270 '; 15 12. The "user" 505 object calls the method of "start Application (Locator)" of the object "record: Application Registry" 205; and 13. The object "Registry: Application Registry" 205 calls the "start ()" method of the object "ap: Application" 270". . 2 Administration of States of Application FIGURE 6 shows a set of interactions / sequences that demonstrate how a The application can be administered by an application administrator and verified by an agent according to the present invention. • A number of exemplary objects are provided, including "api: application" 270", "Administratordeap: State Change" 260 ', "event: State Change Event" 350 ', and "agent: EscuchadeCa biodestado" 260"(or 270"). The agent registers as a StatusChangeListener for an application specific. The application changes its internal states based on internal or external causes. In this example, the application was suspended, which changed its Operational Status to OFF. The application creates a State Change Event and sends it to all registered listeners, in this case, the agent. The agent can determine the state that changed and its old and new values by questioning the event, for example, by invoking the methods available in the State Change Event object, such as getValueViej or (), getnewValue (), etc. The previous sequence can be implemented via the following steps 1-11 copies: 1. The object "Administratordeap: CambiodeEstado" 260 'calls the method "start ()" of the object api: Application " 270"; 2. The object "agent: StateChangeListener" 260"calls the" addStateScheduleSchooper "method • of the object "api: Application" 270"; 3. The object" Administrator of Ap: 5 Change of State "260" calls the method "suspend ()" of the object "api: Application" 270"; 4. The object "api Application" 270 calls the method of "State Change Event" of the object "event: State Change Event" 350 '; • 10 5. The object "api: Application" 270"calls the method of" State Change (State Change Event) "of the object" agent: Status Change Hearing "260"; 6. The object "agent: StateChangeListen" 260"calls the method" getState () "of the object "event: State Change Event" 350"; 7. The object "agent: StateListenChange" 260"calls the method of" getOldValue () "of object" event: StateChangeEvent "350 '; 8. The object" agent: StateListenChange "20 260" calls the method of "getNewValue () "of the object "event: State Change Event" 350"; 9. The object "Administrator of Ap: Change of State" 260"calls the method of" summarize () "of the object" api Application "270"; . The object "api Application" 270"calls the method of" Status Change Event "of the object • "event: State Change Event" 350 '; and 11. The object "api Application" 270"calls the method of" State Change (Status Change Hearing) "of the object" agent: Status Change Hearing "260". 6. Description of Class and Interface (^ As many APIs as possible are defined as interfaces more than as classes. This provides more freedom and fewer restrictions for the implementation of the API. Since Java interfaces do not have static constructors or methods, some interfaces such as the Application Registry have a class of 15 Registry Factory that returns the appropriate implementation of Application Registry. The Factory of Record Factory • it can be based on the factory method pattern, which, as we know from the field of object-oriented programming, is a methodology and structure for solving a problem. Section 6.1 describes the packages related to the application. 6.1 org. atsc. application This package includes classes and interfaces • related to the life cycle application, registration and administration. 6. 1.1 Application This class represents a base class of all downloadable applications. Provides basic support of the life cycle application and information further descriptive about the application in the form of an InfodeAplication class. This class implements the Generic States interface to add management capacity to a downloadable application. This interface provides rt 15 a uniform mechanism to manage any object in a standard way. An application can support a subset of those states as appropriate for the specific application. The class is derived from Object States. 20 Public Operations: start (): Called by the control process to start the execution of an application. The application may require any necessary resources, perform its initialization and start its execution.

If this application supports the Administrative State, it will make an exception when it is in the • Blocked state. Public operations are those methods that can be called and used by other objects since they are visible outside the object (for example, class). In contrast, private operations are visible only to the class itself. high (): • 10 Called by the control process to stop the execution of this application. The application must release all resources and finish. suspend (): Called by the control process to make rt 15 a temporary pause of the execution of this application. It is not required that this application be given resources unless it is requested to do so using a different mechanism. If this application supports Operational Status, it will change the Disabled status after completing this method. summary (): Called by the control process to resume an execution of the application that was previously suspended.

If this application supports the Operational State, it will change the status to On after completing • this method. getApplicationID (): Called Locator to determine the identification of the application represented as a Locator such as a URL. tffc 6.1.2 Application information 10 This class provides additional information about an Application, such as a name, version number, author, etc. Public Operations: getTitle (): Orderly Sequence rt 15 Returns a short description of the application, such as its name or title. GetSeller (): Orderly Sequence Returns a name of the seller or author of the application. 20 getVersion (): Orderly Sequence Return the version of this implementation. This consists of an ordered sequence assigned by the vendor of this implementation.

The version numbers use a "Dewey Decimal" syntax consisting of positive decimal integers separated by periods ".", For example, "2.0" or "1.2.3.4.5.6.7". This 5 allows an extendable number to be used to represent major, minor, micro, etc. versions. The version number must begin with a number. Get Required Profile (): Ordered Sequence k Returns the minimum profile identifier, such as the ID of the DASE profile, which is expected to execute this application. getResources (): Locator Returns the original resource of the application in a URL format. The resource is where the application comes from (for example, channel 39, HBO, CNBC, etc.) 6. 1.3. Application Registry This interface provides limited access to Application Registry. Allows other applications get information about existing applications, to show an interest in a particular application (registering this) and get access to applications themselves.

The interface is derived from the Registry. Public Operations: Application Registry (Locator Application Id): Call to add this application from the registry. The application is specified via its Locator (URL). The registry is responsible for locating the application, downloading this and notifying the calling party of its availability. This is a nonblocking method; will return immediately after verifying the request. The Available Application Event will be sent to all Listen to the Application Registry with an indication of the result of the registration of this application. deregisterApplication (applicationID: Locator): Call to remove this application from the registry. getApplication Information (Application ID: Locator): Call Application Information for a description of this application. The application is identified by a Locator (URL). get Application (Application ID: Locator): Call Application to access a specific loaded and installed application.

This method is protected via security mechanisms to protect against unauthorized access to applications. getApplications (): Application [] This method allows a recovery of all registered applications. This method is protected via the security mechanism to protect against unauthorized access to applications. start Application (Application ID: Locator): Call to invoke a previously registered application. The called method returns as soon as the requested application starts running in its own loaded space. This method is protected via security mechanisms to protect against unauthorized access to applications. addListen toApplicationRegister (listen toApplicationRequestListener) Call to record events generated by the Application Registry. removeListeningApplicationRecord (listening: ListeningApplicationRegistration) Call to remove from a record the events generated by the application registration. 6. 1.4 Listening to Application Registry • This interface allows an object to listen for changes made to the Application Registry. 5 Public Operations: ChangeofRegistration () ApplicationRegistration Event This method of all Registered ApplicationRegistration Listeners is called by? J the ApplicationRegistration object when an application registration is activated.

Application Registration event. 6. 1.5 Event of Application Registry Derived from the Event Object. Public Operations: rt 15 getApplication (): Application Information Call to determine which application caused the event. getCause (): short 20 Call to determine what caused this event. 6. 1.6 Exception of Application Availability This exception occurs when the requested application availability condition was violated. It is derived from Exception. 6. 1.7 Unregistered Application Exception • Derived from ExceptionofApplicationAvailability 5 6.1.8ExceptionofApplicationAndRegistrada Derivado de ExceptionofApplicationAvailability 6.1.9 Cause of Application Public Attributes: REGISTERED: short = 1 The application was registered in the registry. "Short" is a format for integers ^ (2 bytes 15 against 4 bytes). DELETE THE RECORD: short = 2 The application was removed from the registry. INITIATED: short = 3 The application was started. 20 6.2 org. atsc. administration This package includes classes and interfaces related to the administration of objects. This can be applied in its entirety or as a subset relevant to the specific managed entity. This is applicable for managing state and resource status attributes, as well as receiver applications.

• DTV. This is based on the ITU-T X.731 standard for 5 State Administration. 6. 2.1 Administrative State An interface that defines Masks for different Administrative States: • 10 -blocked: The resource is administratively prohibited to perform services for its users. This could be related to a local block, such as a blocking of origin of certain channels or applications, but it can also be used to rt 15"lock" remotely (from the operator of the input section, uplink or cable) the application, from • so that the user can not start it, for example, if a problem with an application is detected. -Unlocked: The resource is allowed administratively to perform services for users. This is independent of its inherent operability. -Interruption: The use of a resource is > allowed administratively in the existing cases of 25 users only. The administrator can at any time make the object revert to an Unlocked state. • Public Attributes: UNBLOCKED: int = 0x00000001 5 LOCKED: int = 0x00000002 INTERRUPTION: int = 0x00000004 TYPE_ADMIN: short = 1 Public Operations: • get Administration Status (): int 10 Call to obtain the current value of the administrative status. setBlock (AdministrativeStatus: int: Call to change the value of the Administrative State.) 6.2.2 Operational State An interface that defines the Operational state for resources and applications: -Deactivated: The resource is totally inoperable and unable to provide service to users. -Active: The resource is partially operable and is available for use Public Attributes: 25 OFF: int = 0x8 ON: int = 0x10 OPERATIONALTYPE: short = 2 Public Operations: getOperationalState (): int Call to get the current value of the state operational. 6. 2.3 Alarm Status Interface that defines all alarm states. When the value of this attribute is an empty set, this implies that none of the state conditions described below are present: -under repair: The resource is currently being repaired. When the value under repair is present, the operational status is deactivated or activated -critical: One or more critical alarms that indicate that a failure in the resource has been detected, and that it has not been cleared. The operational state of the managed object can be deactivated or activated. -major: One or more major alarms that indicate that a fault has been detected in the resource, and has not yet been cleared. The operational state of the managed object can be deactivated or activated. -minor: One or more minor alarms that indicate that a fault has been detected in the resource, and that it has not been cleaned yet. The operational state of the managed object can be deactivated or activated. • Notable alarm: One or more alarms have been detected in the resource. The condition may or may not be deactivating. If the operational status is activated, additional attributes, particular to the managed object class, can indicate the nature and cause of the condition and the services that are affected. ^ b The presence of state conditions of previous alarms do not suppress the generation of future notifications related to failures. Public Attributes: LOW_REPARATION: int = 0x00000001 CRITICAL: int = 0x00000002 rt 15 HIGHER: int = 0x00000004 MINOR: int = 0x00000008 ALARM_NOTABLE: int = 0x0010 TYPE_ALARM: short = 8 Public Operations: 20 Clear Alarm (alarm: int): Call to clear a specific alarm. The control process has acted on the alarm. GetAlarmState (): int Called to obtain the set of current values of the Alarm Status. 6. 2.4 Availability Status • Defines the Availability State. When the value of this attribute is an empty set, this implies 5 that none of the state conditions described below are present: -in test: The resource is being subjected to a test procedure. If the administrative state ^ B} is blocked or interrupted, then 10 normal users are prevented from using the resource and the control status attribute has the value reserved for the test. Tests that do not exclude additional users may be presented in any operational or administrative state but the one reserved for the rt 15 test condition will not be present. -Failed: The Resource has an internal failure that • prevents it from operating. The operational state is deactivated. -paid: The resource requires that you apply power and it is not turned on. For example, if you know that a fuse or other protection device has removed power, or a low voltage condition has been detected. The operation status is deactivated. -Outline: The resource requires that a routine operation be performed to place it online and make it available for use. The operation can be manual or automatic, or both. The operation status is deactivated. • -out of service: The resource has become inactive through an internal control process according to a predetermined time schedule. Under normal conditions it can be expected that the control process will reactivate the resource at some programmed time, and therefore, it is considered to be optional. The operational state is activated or deactivated. 10 -dependency: The resource can not operate because some other resources on which it depends (for example, a resource not represented by the same managed object) are not available. For example, a device is not accessible because its controller rt 15 is turned off. The operational state is deactivated. -degraded: The resource available service • it is degraded in some aspect, such as in the speed or capacity of operation. The failure of an unacceptable test or measurement of performance has established that Some or all of the services are not functional or degraded due to the presence of a defect. However, the resource remains available for your service, either because some services are satisfactory or because the degraded service is The absence of total service is preferable. The specific attributes of the object can be defined to represent additional information that indicates, for • example, what services are not functional and the nature of the degradation. The operational state is 5 activated. -not installed: The resource is represented but the managed object is not present, or incomplete. For example, a connection module is absent, a cable is disconnected or a module of 10 programs and programming systems is not loaded. Operational states are disabled. -file-filled: This indicates a full record condition, the semantics of which is defined in CCITT'Rec. X.735 | ISO / IEC 10164-6. rt 15 Public Attributes: TEST: int = 0x00000400 FAILURE: int = 0x00000800 INTERRUPTED: int = 0x00001000 OUT OF LINE: int = 0x00002000 20 OUT OF SERVICE: int = 0x00004000 DEPENDENCY: int = 0x00008000 DEGRADED: int = 0x00010000 NOT_INSTALED: int = 0x00020000 LONG_REME: int = 0x00040000 25 TYPE AVAILABILITY: short = 32 Public Transactions: getAvailability Status (): int Called to obtain the set of current values of the Availability State. 6. 2.5 Procedure Status An interface that defines the status of the procedure. The state of procedure attribute is supported only by those classes of managed objects that represent some procedure (for example, a test process) that progresses through a sequence of phases. Depending on the definition of the managed object class, the procedure may be required to reach a certain phase for the resource to be operational and available for use (ie, for the managed object to be activated). Not all phases can be applicable to each class of managed object. If the value of this attribute is an empty set, the managed object is ready, for example, the initialization is complete. When the value of this attribute is an empty set, this implies that none of the state conditions described below are present. -required initialization: The resource requires that the initialization be invoked by the administrator before it can perform its normal functions, and this procedure has not been initiated. The administrator may be able to invoke such initialization through an action. The termination condition may also be present. The operational state is deactivated. -not initialized: The resource requires initialization before it can perform its normal functions, and this procedure has not been initiated. The resource is initialized by itself autonomously, but the operational state can be disabled or activated, depending on the definition of the managed object class. rt '-initialize: The resource requires initialization before it can perform its normal functions, and this procedure has been started but is not yet complete. When this condition is present, the required initialization condition is absent, since the initialization has already started. The operational state can be deactivated or activated, depending on the definition of the managed object class. - reporting: The resource has completed some processing operation and is notifying the results of the operation, for example, a test process is sending its results. The operation status is activated. - ending: The resource is in an end phase. If the resource is not self-resetting autonomously, the Requested Initialization Condition is also present and the operation status is deactivated. Otherwise, the operational state can be deactivated or activated, depending on the class definition of the managed object. Public Attributes: INIC_REQUERED: int = 0x00000020 NO_INICIALIZED: int = 0x00000040 INITIALIZE: int = 0x00000080 REPORTING: int = 0x000000100 rt ENDING: int = 0x00000200 TYPE_PROCEDIMIENTO: short = 16 Public Operations: obtainState of Procedure (): int Called to obtain the set of Current values of the State of Procedure. 6. 2.6 Use Status This interface defines the Mask for the Use Status.

Unoccupied: The resource is not currently in use. - Active: The resource is in use, but has an additional operational capacity to provide additional users at this time. - Busy: The resource is in use, but has no additional operational capacity to provide additional users at this time. Public Attributes: UNCOUPLED: int = 0X00000020 ACTIVE: int = 0x00000040 OCCUPIED: int = 0x000000080 TYPE_USO: short = 4 Public Operations: getUser Status (): int Called to obtain the current value of the Use Status. 6. 2.7 Object States This interface allows objects that are inferior to be managed in a standard way to implement a unified interface that supports all, or a suitable subset of states and state values. The defined state and state attributes are specified by the X.731 standard of the ITU-T for the State Administration. • Derivated from Estado deAlarma, Procedural Status, Availability State, State of Use, Operational Status and Administrative Status. Public Operations: GetSupportedStates (): short [] Call to determine which state and attributes? K of states are supported by the class that implements this interface. addStateChangeListener (listen: StatusChangeListener) Call to register a StateChangeListener for StateChange Events. 15 removeStateChangeSchooper (listen: StateChangeListener): • Call to remove a StateChangeListener from the register. get Current Status (): int 20 Listen to Change Status Call to get the current value of all supported states. Returns a bit mask that represents the individual states. get CurrentStatus (): int Called to obtain the current value of all attributes of reported states. Return a mask • of bits that represent the individual status attributes. 6. 2.8 Status Change Listening This interface must be implemented by the interested parties that are being notified of the change in state of objects that the 10 United States Generic interface implements. If an object that is a State ChangeChange is registered via the method of adding StateChangeLearn, it will be notifying by calling the StateChanged method, which includes the appropriate StateChange Event. rt 15 Public Operations: Change of State (event: State Change Event) Call to notify a State Change Monitor about a change of status. The event parameter provides information about what state has changed. 6. 2.9 Exception of the Status of a Resource A class of Base Exception related to the Generic State interface. This exception or its extensions are enforced when an invalid state change would be caused by a method call. By • example: An object in a Disabled state can not perform a certain operation unless it is Unlocked. 5 The class is derived from Exception. Public Operations: get Short () State Call to determine which state consistency has been violated. 10 getValue (): int Call to get the current value of the violated state. 6. 2.10 State Change Event rt 15 This event triggers when a state changes its value. This is distributed to all Registered State Change Listeners. The event is derived from the Event Object. Public Operations: 20 getState (): short Call to determine which state has changed. getValueOld (): int Call to determine the original value of the state. getNewValue (): int Call to determine the new value of the state. Get Resource Indicator (): short Call to determine the cause of the event. 6. 2.11 Public Attributes Resource Indicator: INITIAL CAUSE: short = 1 Change of state caused by an internal activity. CAUSE-EXTERNAL: short = 2 Change of state caused by an external activity. rt 6. 3 org. atsc. service This package provides a set of classes and support and service interfaces used by other packages. 6.3.1 Registry This interface provides a common root for all specialized registry interfaces, such as Application Registry, Resource Registry, etc. It is provided so that the Record Factory can return a base type. The interface is derived from RecordType. Public Operations: getRegistrationType () Ordered Sequence Call to determine the type of record implemented by the object returned by the RecordManager method of obtainingRegistration (). 6. 3.2 RecordManufacturing This class provides a mechanism for creating objects that implement specific registry interfaces, such as the Application Registry. Public Operations: Record Factory (): rt Constructor get Record (name of Record Ordered Sequence): record Returns a case of an object that implements the specified record interface. Returns null when the specified record does not exist or can not be created. The type of object returned will be one of the derived record types, such as the Application Record. 6. 3.3 Type of Registration This interface defines names for different types of records, such as an application record, etc. Public Attributes: REGISTRATION APPLICATION Ordered Sequence = Application Registry REGISTRATION RESOURCE Orderly Sequence Resource Record, Totals 3 Logical Packages 23 Classes Logical Package Structure: Logical View java lang util org atsc application administration services davic network Accordingly, it can be seen that the present invention provides a program architecture and • programming systems to manage applications in a superior television device terminal. The application data 5, such as a programming guide, quote indicator or the like, are retrieved in the terminal according to a locator associated with the application data. The application data is registered and installed in the terminal, and a user is • 10 notified of the presence of the application data after registration and installation thereof. Although the invention has been described in connection with several specific embodiments, those skilled in the art will appreciate that they can be made various adaptations and modifications thereto without departing from the spirit and scope of the invention as set forth in the claims. For example, although several syntax elements have been discussed here, note that they are examples only, and that any syntax can be used. In addition, the invention is suitable for use with virtually any type of network, including cable or satellite broadband communication networks, local area networks (LAN), metropolitan area networks (MAN), wide area networks (WAN), internets, intranets, and the Internet, and combinations thereof. Additionally, physical computing components, physical instructions and / or programs and programming systems may be used to implement the invention. It is noted that in relation to this date, the best method known to the applicant to carry out the aforementioned invention, is the one that is clear • 10 of the present description of the invention •

Claims (21)

1. CLAIMS Having described the invention as

   • foregoing, the content of the following claims is claimed as property. 1. A terminal of a superior television apparatus, characterized in that it comprises: a computer-readable medium having means of coding computer programs; and means to execute the coding means

   • 10 computer programs to implement an Application Programming Interface (API) where: the application data that defines the application is retrieved in the terminal according to the locators associated with the applications; 15 the applications are registered and installed in the terminal; and a user is notified of the presence of the applications after the registration and installation of the same.
2. 2. The terminal according to claim 1, characterized in that: the API allows the recovery of the applications as applications of programs and downloadable programming systems.
3. 3. The terminal according to claim 1, characterized in that: • the API allows the recovery of the applications as applications of programs and systems of broadcast programming.
4. The terminal according to claim 1, characterized in that: the API is independent of an operating system and the physical computing components of the terminal.
5. • The terminal according to claim 1, characterized in that: the API provides a mechanism based on the ITU-T X.731 to verify and control the applications.
6. 6. The terminal according to claim 1, characterized in that: the API allows applications to be executed and stopped later.
7. The terminal according to claim 6, characterized in that: the API allows the applications to pause once they are being executed, and to subsequently resume the applications.
8. 8. The terminal according to claim 1, characterized in that: the API allows particular applications to notify their respective states to other applications.
9. 9. The terminal according to claim 8, characterized in that: the API allows at least one of the other applications to access the notified state of at least one of the particular notified applications.
10. 10. The terminal according to claim 1, characterized in that: the API allows the retrieval of the version information associated with the applications.
11. The terminal according to claim 1, characterized in that: the locator is in the form of a Uniform rt Resource Locator (URL).
12. 12. The terminal according to claim 1, characterized in that: the API allows the verification of the integrity of the applications.
13. The terminal according to claim 1, characterized in that: the API allows the validation of the suitability of the applications for the terminal.
14. 14. The terminal according to claim 1, characterized in that: the API allows the administrative block and unlock of the applications.
15. 15. The terminal according to claim 1, characterized in that: the API allows particular applications to notify respective alarm states to other applications. The terminal according to claim 1, characterized in that: the API allows particular applications to notify their respective availability states to other applications. 17. The terminal according to claim 1, characterized in that: the API allows particular applications to notify respective process states thereof to other applications. • The terminal according to claim 1, characterized in that: the API allows particular applications to notify respective operating states thereof to other applications. 19. The terminal according to claim 1, characterized because: the API allows particular applications to notify their respective administrative states to other applications. The terminal according to claim 1, characterized in that: the API allows particular applications to notify their respective usage states to other applications. 21. A method for implementing an architecture of programs and programming systems to a terminal of superior television apparatuses, characterized in that it comprises the steps of: providing a computer readable medium having coding means of computer programs; and executing the means of coding computer media to implement an Application Programming Interface (API) to: recover application data, which define applications in the. terminal according to a locator associated with the application data; register and install the applications in the terminal; and notify a user of the presence of the application after the registration and installation of the same.