WO2001076229A1

WO2001076229A1 - Service resource environment management system

Info

Publication number: WO2001076229A1
Application number: PCT/US2001/010624
Authority: WO
Inventors: Dean F. Jerding
Original assignee: Scientific-Atlanta, Inc.
Priority date: 2000-04-03
Filing date: 2001-04-03
Publication date: 2001-10-11

Abstract

A system is provided for managing resources in a cable television client device such as a digital home communication terminal, or DHCT, which provides flexible and predictable management of such resources as a screen area of an attached television and a tuner in the DHCT, among others. The system includes an application programming interface (API) that includes providing service resource environment information during times of application activation and execution. At least one resource manager interprets service resource environment information to allocate resources in response to the service resource environment information. The service resource environment system, or model, enables multiple applications executing in the DHCT to flexibly co-exist and share resources without imposing undo coupling and linkages directly between the applications themselves.

Description

SERVICE RESOURCE ENVIRONMENT MANAGEMENT SYSTEM

FIELD OF THE INVENTION This invention relates in general to the field of television systems, and more particularly, to the field of resource management in client devices.

BACKGROUND OF THE INVENTION A digital home communication terminal ("DHCT")-, otherwise known as a settop box or client device, has become an important computing device for accessing video services and navigating a subscriber, or user, through a maze of services available through a cable television system. In additio to supporting traditional broadcast video and audio functionality, DHCTs now also support an increasing number of services in addition to traditional television viewing services, including, among many others, services with two-way communications such as video-on-demand (VOD), impulse pay- per- view (PPV), Internet e-mail, and Internet web browsing.

The DHCTs generally include hardware and software necessary to provide the functionality of the digital television system at a subscriber location, or client side. Each DHCT typically includes at least a processor, communication components and memory, and is connected to a television or other display device, such as a personal computer. While many conventional DHCTs are stand-alone devices that are externally connected to televisions, a DHCT and/or its functionality may be integrated into a television, personal computer, or other subscriber device.

As more and more services and applications are made available, it becomes increasingly important to solve the problem of properly managing, the resources of the client device. For example, there are finite memory and processing capabilities on the

DHCT. Additionally, there is typically only one screen attached to a DHCT and only one tuner inside the DHCT for receiving television audio and video signals, although DHCTs with multiple screens and tuners are becoming available. In addition, other resources that need to be managed often include a front panel display, user input devices such as a remote control and keyboard, among others. As a result, there is a need for a system that solves the problem of properly managing. DHCT resources. SUMMARY OF THE INVENTION Briefly described, the preferred embodiment of the present invention provides a system for managing resources in a television client device such as a digital home communication terminal, or DHCT, which provides, flexible, predictable, and scalable management of such resources as a screen area of an attached- television and a tuner in the

DHCT, among others. The system includes an application programming interface (API) that includes providing service resource Environment (SRE) information during times of application activation and execution. At least one resource manager interprets service resource environment information to allocate resources in response to the service resource environment information. The service resource environment system, or model, enables multiple applications executing in the DHCT to flexibly co-exist and share resources without imposing undo coupling and linkages directly between the applications themselves.

Other advantages of the present invention will become apparent to one with skill in the art upon examination of the following drawings and detailed description. ,

BRIEF DESCRIPTION OF THE DRAWINGS The invention can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present invention. In the drawings, like reference numerals designate corresponding parts throughout the several views.

FIG. 1 is a block diagram representation of a cable television system in accordance with one embodiment of the present invention.

FIG. 2 is a block diagram representation of one example of a channel table and a service table of a DHCT of the cable television system of FIG. 1.

FIG. 3 is a block diagram representation of one example of a progression of television screen views for a television connected to the DHCT of FIG. 1.

FIGS. 4 - 6 are flow chart representations of a resource management process executed in the DHCT for the screen progression shown in FIG. 3.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS FIG. 1 is a block diagram of a cable television system 10, including a headend 11 for originating and receiving television signals, such as satellite television signals, and converting the signals into a format for transmitting the signals over a network 20. The transmitted signals can, for example, be radio frequency (RF) signals or optical signals, transmitted over fiber optic or coaxial cables in the network 20. When optical signals are transmitted by the headend 11 , one or more optical nodes are included in the network 20 for converting the optical signals to RF signals that are thereafter routed over other media, such as coaxial cables. Taps are provided within the network 20 for splitting the RF signal off to subscriber equipment, including a plurality of digital home communications terminals (DHCTs), one of which is shown as DHCT 16. While the DHCT 16 is shown as a stand alone settop box connected to a television 21 and a user input device 27, the functionality of the DHCT 16, as well as many of the elements of the DHCT 16, may also be include in cable-ready television sets, satellite-based settop boxes, video recorders, computers, etc., as would be understood by those reasonably skilled in the art of the present invention.

The DHCT 16 preferably includes, at least, a communications interface 22 for receiving the RF signals, which can include video, audio and data information, from the headend 11 through the network 20 and for providing any reverse information to the headend 11 through the network 20. The DHCT 16 further includes a processor 24 for controlling operations of the DHCT 16, including an RF output system 28 for driving the television display 21, a tuner system 25 for tuning into a particular television channel to be displayed and for sending and receiving various types of data from the headend 11. The tuner system includes, in one implementation, an out-of-band tuner for bi-directional quadrature phase shift keying (QPSK) data communication and a quadrature amplitude modulation (QAM) tuner for receiving television signals. Additionally, DHCT 16 includes a receiver 26 for receiving externally-generated information, such as subscriber inputs or commands from other devices. The subscriber inputs may, for example, be provided by a computer or a remote control transmitter with buttons or keys located either on the exterior of the terminal or by a hand-held remote control device 27 that includes subscriber-actuated buttons, such as an infrared (IR) keyboard or remote control device.

In one implementation, the DHCT 16 includes system memory 29, which includes flash memory 31 and dynamic random access memory (DRAM) 32, for storing various applications, modules and data for execution and use by the processor 24 of the DHCT 16. Both the flash memory 31 and the DRAM memory 32 are coupled to the processor 24 for storing configuration data and operational parameters, such as commands that are recognized by the processor 24. Basic functionality of the DHCT 16 is provided by an operating system 33 that is contained in flash memory 31. Among other things, the operating, system 33 includes at least one resource manager 47 that provides an interface to resources of the DHCT 16. In one implementation, system resources include the tuner system 25, screen data output to the television 21, a DHCT front panel display (not shown), memory, IR remote input, front panel input, IR keyboard input, etc. Depending on the embodiment of the invention, there may one resource manager for many resources, one resource manager for each resource, or some level in between, as discussed in further detail below.

An application referred to as navigator 35 is also resident in flash memory 31 for providing a navigation framework for services provided by the DHCT 16. Examples of services include, without limitation and in accordance with one implementation, watching television programs (available through a watchtv application 42), and purchasing pay-per- view events (available through a PPV application 44), listening to digital music (not shown), and an interactive program guide (not shown}. In general, the concept of a service includes an application executable that provides the service along with a set of application-dependent parameters that indicate to the application the service to be provided. The application clients may be resident in in flash memory 31 or downloaded into DRAM 32. The navigator 35 also allows users to access various settings of the DHCT 16, including volume, parental control, etc., as well as access the various services.

The flash memory 31 also contains a platform library 36. The platform library 36 is a collection of functionality useful to applications, such as a timer manager, compression manager, configuration manager, an HTML parser, database manager, widget toolkit, string managers, and other utilities (not shown). These utilities are accessed by applications via APIs as necessary so that each application does not have to contain these utilities. Two components of the platform that are shown in FIG. 1 for the platform library 36 are a window manager 39 and a service application manager (SAM) 37. An example of a service application manager is provided in U.S. Application Number 08/802833, DeFreese et al.

System and Method for Providing a Full Service Television System, filed 2/18/98, which is incorporated herein by reference.

The window manager 39 provides a mechanism for implementing sharing of the screen real estate and subscriber input. The window manager 39 on the DHCT 16 is responsible for, as directed by one or more applications, implementing the creation, display, and de-allocation of the limited DHCT 16 screen resources. It allows multiple applications to share the screen by assigning ownership of screen regions, or windows. The window manager 45 also maintains, among other things, a user input registry 30 in DRAM 32 so that when a subscriber enters a key or a command via the remote device 27 or another input device such as a keyboard or mouse, the user input registry 30 is accessed to determine which of various applications running on the DHCT 16 should receive the inputted key and in which order. As an application is executed, it registers a request to receive certain user input keys or commands. When the subscriber presses a key corresponding to one of the commands on the remote 27, the command is received by the receiver 26 and relayed to the processor 24. The processor 24 dispatches the event to the operating system 31 where it is forwarded to the window manager 45 which ultimately accesses the user input registry 30 and routes the incoming command to the appropriate application. For example, the navigator 35 registers for and in some cases reserves certain user input related to navigational keys such as channel increment/decrement, last channel, favorite channel, etc. The SAM 37 is a client component of a client-server pair of components, with the server component (not shown) being located on the headend 11. Together, the client-server SAM components provide a model in which the subscriber can access services, which consist of an application to run and a parameter, such as particular data content, specific to ^■ that service. A SAM database 40 in DRAM 32 includes a table of services and a table of channels that are created and updated by the headend 11. The client-server SAM components also manage the life cycle of the applications on the system, including the definition, activation, and suspension of services they provide and the downloading of the applications into the DHCT 16 as necessary. Many services can be defined using the same application component, with different parameters. As a non-limiting example, an application to tune video programming could be executed with one set of parameters to view HBO and a separate set of parameters to view CNN. Each association of the application component (tune video) and one parameter component (HBO or CNN) represents a particular service that has a unique service I.D. The SAM 37 also interfaces with the resource manager 47, as discussed below, to control resources of the DHCT 16. Also, as mentioned above and below, alternate embodiments include separate resource managers for each of the resources, in which case the SAM 37 would interface with each of the resource managers.

Application clients can also be downloaded into DRAM 32 at the request of the SAM 37, typically in response to a request by the user or in response to a message from the headend.. In this non-limiting example DRAM 32 contains a video-on-demand application (VOD) 43, an e-mail application 45, and a web browser application 46, among others (not shown). It should be clear to one with ordinary skill in the art that these applications are not limiting and merely serve as examples for this present embodiment of the invention. These applications, and others provided by the cable system operator, are top level software entities on the network for providing services to the subscriber. In one implementation, applications executing on the DHCT 16 work with the navigator 35 by abiding by several guidelines. First, an application must utilize the SAM 37 for provisioning, activation, and suspension of services. Second, an application must share DHCT 16 resources with other applications and abide by the resource management policies of the SAM 37, the operating system 33, and the DHCT 16, as discussed in more detail below. Third, an application must handle all situations where resources are unavailable without navigator 35 intervention. Fourth, when an application loses service authorization while providing a service, an application should suspend the service via the SAM. The navigator 35 will reactivate an individual service application when it later becomes authorized. Finally, an application client must be designed to not have access to certain user input keys reserved by the navigator (i.e., power, channel +/-, volume +/-, etc.). DRAM 32 also includes application memory 50 for utilization by the various applications, including, for storage of resource environment settings, as is discussed below.

As discussed above, the SAM database 40 includes a channel table and a service table. Refer now to FIG. 2, which shows a block diagram representation of a channel table 61 and a service table 62. Each entry in the channel table 61 includes a channel number and a pointer to a service ID corresponding to an entry in the service table 62, as represented by arrows 63. Each entry in the service table 62 includes, in accordance with one implementation, a service ID, an application identifier, or Uniform Resource Locator (URL), , a parameter (such as a television program name, etc.), a short title for the service, a long title for the service, and a logo for the service. Of course, other implementations of the present invention include tables with greater or fewer elements of information in each table entry. Also, while a system operator normally defines the information contained in the service table 62, various applications in the DHCT 16 (FIG. 1) may also create entries into the service table 62 via the SAM server API. The system operator defines the channel table(s) 61 for the lineup of services to be provided in any particular system. With continued reference to elements of FIG. 1, refer to FIG. 3, which shows a block diagram representation of one example of a progression of television screen views for a television 21 connected to the DHCT 16 of FIG. 1. In the example shown, a subscriber first turns on the television 21 and the DHCT 16 to watch television, as shown in a first screen view 70 in which the watchtv application 42 displays a television program. At some later point in time, the subscriber decides to check his/her e-mail. After the subscriber manipulates the user input device 27 to indicate a desire to execute the e-mail application 45, a second screen view 72 is displayed which includes a reduced version of the television program in a reduced window 73 inset on top of or "floating over" an obstructed full-screen rendering driven by the e-mail application 45. In this manner, the user can continue watching a television program in the reduced screen window 73 while interacting with the e- mail application 45 in the main portion of screen view 72. Assuming the subscriber at some point desires to utilize the entire view area for the e-mail application 45, the subscriber then so manipulates the user input device 27 to cause the DHCT 16 to display a third screen view 73 in which only the e-mail application 45 is displayed. Of course, depending on implementations, and as may be requested by the subscriber, the screen view 73 could be displayed before the screen view 72, the screen view 70 may be displayed after the screen view 72, etc.

FIGS. 4 - 6 are flow chart representations of a resource management process executed in the DHCT 16 for the screen progression shown in FIG. 3. With continued reference to elements of preceding figures, FIG. 4 includes steps 80 representing selected elements of a process for activating the watchtv application 42 from a power up condition. In step 82, after power is supplied to the DHCT 16, the channel table 61 and service table 62 are received from the headend 11 and stored in the SAM database 40. When a power key on the DHCT 16 is pressed, as shown in step 84, the navigator 35 receives notification through the operating system 33 and window manager 39, as discussed above, and determines that a particular channel is a default channel to be displayed upon power up, which the navigator 35 uses to query the SAM 37 in order to identify a service associated with the default channel. The default channel can be the most recent channel accessed by the DHCT 16 or a standard power up default channel, as may be configured by a user. When the SAM 37 receives the request for an identification of a service associated with a particular channel, step 86, the SAM 37 references the channel table 62 and returns the service ID to the navigator 35. Typically, the default channel corresponds to a service of watching a particular television program, thus the application is watchtv 42, for which a parameter could be CNN, NBC, etc.

In step 88, the navigator 35 responds to receiving the service ID from the SAM 37 by setting a "channel service" state variable (also referred to as a setting, or information) in a navigator 35 area of application memory 50 to include the newly discovered service ID along with service resource environment (SRE) variables, or information, equal to "full screen" and "unobstructed." In addition, an "overlay service" state variable (also referred to as a setting, or information) is defined in application memory 50 without reference to any service, i.e., no "overlay service" is defined. In general, the navigator 35 manages the channel service and overlay service settings in application memory 50. Each of the settings refers to a service with accompanying SRE settings, or to no service at all.

The SRE variables, or information, are used to establish with the SAM 37, the underlying resource controller(s) 47, and a respective application, the service resource environment (SRE) for a particular service. In one implementation, one aspect of the SRE is the "screenRect" variable. The "full screen" screenRect value is a screen rectangle variable defined with rectangular coordinates (xmin, ymin, xmax, ymax) for a window size on a screen, such as 0,0,639,479 for a 640 x 480 screen size. Likewise, a "no screen" value would be 0,0,0,0, and other values would be a "reduced screen" value located as a "floating" window of a particular size and at a particular location as defined by the values. In accordance with one implementation, the service defined with a "full screen" screenRect value is interpreted to be the service with primary control, or "focus", of all controllable system resources In other implementations, a screenState variable is also included to affirmatively indicate which service is to have primary control of system screen resources. In addition, as discussed below, other embodiments include independent control of different resources, including prioritized control mechanisms. As discussed in the above example, a service can also be "obstructed" or

"unobstructed," as defined by another rectangular coordinate setting called the "obstructedRect" in one embodiment. An "unobstructed" value would be 0,0,0,0, while an "obstructed" value would include a rectangular coordinates value matching that of a "reduced screen" for another active service, as is discussed in more detail below. In step 90, the navigator 35 requests the SAM 37 to activate the service (using the recently obtained service ID, which corresponds to a service referencing, watchtv 42 on a particular source ("NBC", "HBO", etc.) in accordance with the full screen unobstructed SRE. The SAM 37 responds, in step 92, by evaluating the request to determine if the referenced application is available and whether any additional authorization is necessary. In this particular example, since watchtv 42 is resident in the DHCT 16, no downloading is necessary. However, whenever the navigator 35 requests activation of a service involving an application not resident in flash memory 31 or previously downloaded into DRAM 32, the SAM 37 launches a download daemon (not shown) to handle the download, as discussed below. In addition, in step 94, the SAM 37 requests the resource manager 47 to allocate control of system resources to the watchtv 42 application since it was assigned a full screen SRE by navigator 35.

In other embodiments of the present invention, all resident applications are viewed as one combined application from the perspective of the resource control manager 47. Also, in other embodiments, if another application already has primary control, the resource manager 47 will first inform the other application that it is losing control and will wait for acknowledgment, or engage in negotiations with the other and new applications to ensure that the new application can and will handle the SRE before assigning control to the new application. In still other embodiments, as discussed above, rather than one resource manager

47, a separate resource manager is used for each system resource, and in such embodiments, some of those resource managers, such as a screen manager and a tuner manager, could maintain priority schemes whereby one application controls, but other applications have lower levels of priority. Establishing the attributes of the service resource environment for a particular embodiment (DHCT, operating system, etc.) is done as follows, Regardless of whether a centralized resource manager manages the resources or whether separate resource managers manage respective resources, if control of each resource is separable: the service resource environment attribute variables will include separate priority settings for each of the various resources, including primary /secondary levels in some embodiments, as well as additional levels of priority in other embodiments. The SAM 37 will then implement the resource environment during service activation and subsequent change to service resource environments, by communicating with each resource manager to update the resource state for the applications as dictated by the attributes in the SRE. For some embodiments, possible service resource environment attributes include controlled resources such as screen rectangle, obstructed rectangle, front panel display, remote, keyboard, mouse, joystick, tuner(s), non- volatile memory, system memory, graphics/media memory, etc.

As shown in step 96, the resource manager 47 responds to the request from the SAM 37 by allocating control of system resources to the watchtv application 42. The

SAM 37, in step 98, also sends a message to watchtv 42 instructing it to activate with the specific service parameter (source) , using the full screen unobstructed SRE variables received from the navigator 35. In one implementation, the message is handled through the operating system 33 as an interprocess communication event. Finally, watchtv 42 acts on the activation by tuning the source identified in the service parameter and displaying the source in the full screen unobstructed view, as shown in the screen view 70 of FIG. 3. Creation of such a window by watchtv 42 includes interfacing with the window manager 39, as discussed above, to create a window owned by watchtv 42. The watchtv 42 application, like any active application, also keeps track of its SRE in application memory

50.

FIG. 5 includes selected steps 110 representing selected elements of a process for transitioning from the screen view 70 to the screen view 72 in FIG. 3. Responsive to receiving user input indicating that the user desires to invoke e-mail application 45, as determined by the navigator 35 in step 112, the navigator 35 first suspends any existing overlay service in step 114. In the example shown, there is no existing overlay service to suspend, but such may not always be the case, depending on preceding views in other examples. Subsequently, in step 116, for the example shown, the navigator 35 sets the overlay service state variable (which previously referenced no service) in application memory 50 as the service ID for the e-mail application 45 with a full screen obstructed SRE, and the navigator 35 changes the channel service SRE to be a reduced screen with coordinates matching the obstructed area coordinates of the overlay service. The navigator 35 then, in step 118, requests the SAM 37 to activate the e-mail service with a full screen obstructed SRE. In step 120, the SAM 37 evaluates the e-mail service activation request and if the

DHCT 16 is authorized launches a download daemon (not shown) to download the e-mail application 45 if it is not already in DRAM 32. If the e-mail application 45 needs to be downloaded, the user needs to know that the application is being downloaded since downloading will take time, and in this implementation, the single in-band tuner system 25 of the DHCT 16 is unable to simultaneously download the e-mail application and decode video signals for the watchtv application 42. Thus, besides launching the download daemon, the SAM 37 tells the navigator 35 that the e-mail application 45 needs to be downloaded, to which the navigator 35 replies with a request for the SAM 37 to activate a download barker service which informs the subscriber that the e-mail service is being loaded, on the television screen 21.

When the download, if necessary, is complete, and immediately if no download is necessary, the SAM 37 instructs the resource controller 47 to give primary resource control to the e-mail application 45, as shown in step 122, followed by the resource controller 47 complying with the request in step 124. The SAM 37 then, in step 126, instructs the e-mail application 45 to activate with a full screen obstructed SRE. Next, if a download was necessary, the navigator 35 is informed by the SAM 37 of the completion of the download, at which point the navigator 35 tells the SAM 37 to suspend the download barker service. The navigator 35 then directs the SAM 37 in step 127 to change the resource environment for the watchtv channel service to a reduced screen matching the obstructed area of the new e-mail overlay service (i.e., the SRE for the watchtv service is changed). In response to this request, the SAM 37instructs the watchtv application 42 in step 128 to operate with a new SRE in which its screen is reduced to match the obstructed area of the e-mail application 45.

Finally, in step 129, the e-mail application 45 receives and processes the activate message from the SAM 37, and the watchtv application 42 receives and processes the environment change message from the SAM 37, resulting in screen view 72 in FIG. 3. For watchtv 42, changing the SRE involves interacting with window manager 39 to delete the existing full-screen window and creating a new watchtv window 73 in the specified screen rectangle of the upper right-hand portion of the display screen 72. Thus, it should be clear that SRE variables can be used in both activating new services, such as e-mail, and changing resources while a service is active, such as changing the watchtv service from full screen to reduced screen. Since the e-mail application 45 is now in focus for the centralized system resources, downloading of e-mail information has primary priority, but as the e-mail application 45 allows it, audio and video are still available in the watchtv window 73. In other embodiments, as discussed above, priorities could be established so that the watchtv application 42 could have secondary control of the tuner system 25 so that when the e- mail application 45 is not using the tuner system 25, the watchtv application 42 gets control next before any other applications wanting control of the tuner system 25. In one implementation, one rule of the service resource environment is that each application must create a backdrop window when it has a full screen screenRect, which the e-mail application 45 does in this example, and when an application goes from full screen to a reduced screen, as the watchtv application 42 does in this example, it must first delete its full screen window (all window commands going through the window manager 39) and establish a floating window at the coordinates specified in the SRE information. In addition, as dictated by the particular embodiment, each application should use screen resolution information from the window manager 39 to scale accordingly, and if the application is unable to function properly in a particular resolution, an appropriate message should be displayed by the application on the screen. Also, an application can use SRE information assigned to it to alter the content of the screen itself, such as when the screen it is being reduced in size. FIG. 5 includes selected steps 140 representing selected elements of a process for transitioning from the screen view 72 to the screen view 74 in FIG. 3. In step 142, responsive to user input directed to the e-mail application 45 from the window manager 39, the e-mail application 45 determines that the e-mail service is to be given a full screen, but that the audio from the current television program is to continue being output through the television 21. Consequently, in step 144, the e-mail application 45 requests the navigator 35 to change the overlay service SRE to full screen unobstructed and to change the channel service SRE to no screen, which it does in step 146. Then, in step 148, the navigator 35 requests the SAM 37 to instruct the e-mail application 45 to change its SRE to full screen unobstructed and to instruct the watchtv application 42 to change its SRE to no screen. Finally, the SAM 37 so instructs the applications in step 150, and the applications react accordingly in step 152 to result in the screen view 74 of FIG. 3.

Another example screen progression would include a PPV service utilizing the PPV application 44 beginning in full screen view with a selectable option for a subscriber to indicate a desire to view a free preview in a reduced screen. In response to selection of that option, the PPV application would utilize the SAM 37 to cause the activation of a watchtv service showing a preview program in a reduced screen. In that view, the PPV service would continue to be the channel service with a full screen obstructed SRE as far as the navigator 35 is concerned, and it is the responsibility of the "parent" PPV service to manage the resource environment of the "child" watchtv service it activated. In one implementation, an application such as PPV that activates another "child" service cannot specify a service resource environmant containing a greater or higher level of access to resources than the "parent" application itself has in its own SRE. Since the PPV service has a full screen SRE, it is in control and can interface with the user as necessary. When the user buys the PPV selection, PPV uses the SAM to set the watchtv service to a full screen unobstructed SRE, equal to that of the PPV service..

By creating a system and framework that clearly indicates which application is in control of a screen, as well as other resources, there is also no confusion or contention regarding which application has the responsibility for controlling such things as screen resolution and whether video can be decoded, thus ensuring that video memory usage is properly controlled. Screen resolution affects how much video memory is used, as does decoding television video. Consequently, total memory usage can be minimized if low resolution is required to be used whenever video decoding is taking place. If memory usage were not properly controlled in a limited memory environment, operational difficulties might otherwise be encountered as memory runs low.

In different embodiments, the level of enforcement of the SRE can vary depending on the capabilities of the resource controllers 47 and the operating system 33. For example, the window manager (screen and user input resource controller), could be integrated such that it will only let applications build windows and otherwise use resources according to the screen rectangles in the SRE. In other embodiments, enforcement of the policy prescribed by the SRE is up to good coding practices in the applications, as might be verified in some certification before an application is installed onto a system.

As mentioned previously, the SAM 37 could enforce an environment rule that no application can give another application a resource environment more powerful than the

SRE it has in order to reduce risks of improper usage. Also, while the navigator 35 keeps track of and controls the state of the channel service and overlay service information in the preferred embodiment, the other applications know their SRE, and the SAM 37 keeps track of the SRE information for each of the active services in an active services list in order to handle such tilings as independent suspensions as discussed below. However, other embodiments might include the SAM 37 controlling the channel service and overlay service designations, with the applications asking the SAM 37 for the information.

If an application with full screen control suspends itself, such as if it decides to time out, it will tell the SAM 37 that it is suspending itself, and the SAM 37 will give the control back to the previous application that had full screen control. It will also notify the navigator 35 about the suspension in case the navigator 35 needs to update the channel or overlay service state variables, if the service that suspended itself is one of those services. If the SAM 37 chose incorrectly, the navigator 35 will fix the designations when it then sets and implements the channel service and the overlay service. In other embodiments where the SAM 37 manages the channel service and the overlay service, such back and forth communication is unnecessary.

The method and system, as described above, may be implemented in a manner including one or more programs which comprises an ordered listing of executable instructions for implementing logical functions. Additionally, the program(s) can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this document; a "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a nonexhaustive list) of the computer-readable medium would include the following: an electrical connection (electronic) having one or more wires, a portable computer diskette (magnetic), a random access memory (RAM) (magnetic), a read-only memory (ROM) (magnetic), an erasable programmable read-only memory (EPROM or Flash memory) (magnetic), an optical fiber (optical), and a portable compact disc read-only memory (CDROM) (optical). Note that the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via for instance optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory. Furthermore, any process descriptions or blocks in flow charts should be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process, and alternate implementations are included within the scope of the preferred embodiment of the present invention in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the present invention.

It should be emphasized that the above-described embodiments of the present invention, particularly, any "preferred embodiments" are merely possible examples of the implementations, merely setting forth for a clear understanding of the principles of the inventions. Any variations and modifications may be made to the above-described embodiments of the invention without departing substantially from the spirit of the principles of the invention. All such modifications and variations are intended to be included herein within the scope of the disclosure and present invention and protected by the following claims.

Claims

1. A method in a television client device of managing client resources, said method comprising steps of: receiving user input; responsive to receiving the user input, determining an intended service resource environment for an application; and instructing the application of the intended service resource environment through an application programming interface.

2. The method of claim 1 , wherein the intended service resource environment defines a change to an existing service resource environment for an active application.

3. The method of claim 1 , wherein the intended service resource environment defines an initial service resource environment for an application that is being communicated to the application upon activation of the application.

4. The method of claim 1, wherein the intended service resource environment is defined by a plurality of variables, including at least one screen control variable.

5. The method of claim 4, wherein screen control and tuner control for the television client are defined by the at least one screen control variable.

6. The method of claim 4, wherein an application designated as having full screen control through the at least one screen control variable is given highest priority in screen control.

7. The method of claim 1, wherein the receiving, determining and instructing steps are performed at least in part by a navigator application, and wherein a service application manager delivers the service resource environment to the application from the navigator application.

8. The method of claim 1, wherein the determining step includes determining that an active application currently having a full screen unobstructed service resource environment is intended to have a reduced screen service resource environment and that an inactive application is to have a full screen obstructed service resource environment, and wherein the instructing step includes instructing the active application to have the reduced screen service resource environment and instructing the inactive application to activate with the full screen obstructed service resource environment.

9. A method in a television client device of managing client resources, said method comprising the steps of: requesting activation of a service with a service activation request, wherein the service activation request includes a service resource environment request; allocating resource control to the service responsive to and in accordance with the service resource environment request; and activating the service responsive to the service activation request.

10. The method of claim 9, wherein the service resource environment request includes a plurality of service resource environment variables.

11. The method of claim 10, wherein the plurality of service resource environment variables include screen control information.

12. The method of claim 11, wherein the allocating step includes allocating tuner control in accordance with the screen control information.

13. The method of claim 10, wherein the service resource environment variables include tuner control information.

14. The method of claim 9, wherein the allocating step includes allocating control of all controllable resources to an application with full screen control.

15. The method of claim 9, wherein the allocating step includes independently allocating control of controllable resources in accordance with independent service resource environment variables.

16. The method of claim 15, wherein the allocating step includes allocating control of controllable resources in accordance with a plurality of priorities established by the independent service resource environment variables.

17. The method of claim 9, wherein the allocating step includes allocating control of resources only to the extent that service resource environment variables are included in the service activation request.

18. The method of claim 9, wherein the service activation request includes a service identification that is also stored in a services table along with application identifications and application parameters.

19. The method of claim 18, further including a step of downloading the services table from a server prior to the requesting step.

20. The method of claim 18, further including a step of downloading a channel table from a server prior to the requesting step, wherein the requesting step includes identifying the service from the channel table.

21. The method of claim 9, wherein the requesting step is executed by a navigational application responsive to receiving indication of input from a user of the client device.

22. The method of claim 9, wherein the allocating step is executed by a resource manager function of an operating system.

23. The method of claim 9, wherein the service defines a first service, and wherein the method further comprises the steps of: requesting activation of a second service with a second service activation request, wherein the second service activation request includes a second service resource environment request; allocating resource control to the second service responsive to and in accordance with the second service resource environment request; activating the second service responsive to the second service activation request; requesting a service resource environment change for the first service with a first service resource environment change request; and allocating resource control to the first service responsive to and in accordance with the first service resource environment change request.

24. The method of claim 23, wherein the first service includes presenting a television program, and wherein the second service includes a service other than presenting a television program.

25. The method of claim 23 , wherein the service resource environment request for the second service includes a request for full screen control, and wherein the first service resource environment change request includes a request for reduced screen control.

26. A system for managing client resources in a cable television client device, said system comprising: a processor; a plurality of system resources coupled to the processor; and memory coupled to the processor for utilization by the processor, wherein the memory includes request logic configured to request activation of a service with a service activation request, wherein the service activation request includes a resource control request, allocation logic configured to allocate resource control to the service responsive to and in accordance with the resource control request, and activation logic configured to activate the service responsive to the service activation request.

27. The system of claim 26, wherein the service activation request includes a service resource environment variables.

28. The system of claim 27, wherein the service resource environment variables include screen control information.

29. The system of claim 28, wherein the allocation logic includes logic configured to allocate tuner control in accordance with the screen control information.

30. The system of claim 27, wherein the service resource environment variables include tuner control information.

31. The system of claim 26, wherein the allocation logic includes logic configured to allocate control of all controllable resources to an application with full screen control.

32. The system of claim 26, wherein the allocation logic includes logic configured allocate control of controllable resources in accordance with independent service resource environment variables.

33. The system of claim 32, wherein the allocation logic includes logic configured to allocate control of controllable resources in accordance with a plurality of priorities established by the independent service resource environment variables.

34. The system of claim 26, wherein the allocation logic includes logic configured to allocate control of resources only to the extent that service resource environment variables are included in the service activation request.

35. The system of claim 26, wherein the service activation request includes a service identification that is also stored in a services table along with application identifications and application parameters.

36. The system of claim 35, wherein the memory further includes logic configured to download the services table from a server prior to the requesting step.

37. The system of claim 35, the memory further includes logic configured to download a channel table from a server prior to the requesting step, wherein the request logic includes logic configured to identify the service from the channel table.

38. The system of claim 26, wherein the request logic is executed by a navigational application responsive to receiving indication of input from a subscriber.

39. The system of claim 26, wherein the allocation logic is executed by a resource manager function of an operating system.

40. The system of claim 26, wherein the service defines a first service, and wherein the memory further includes second request logic configured to request activation of a second service with a second service activation request, wherein the second service activation request includes a second resource control request, second allocation logic configured to allocate resource control to the second service responsive to and in accordance with the second resource control request, second activation logic configured to activate the second service responsive to the second service activation request, third request logic configured to request a service environment change for the first service with a first service environment change request, wherein the first service environment change request includes a first service resource control change request, and third allocation logic configured to allocate resource control to the first service responsive to and in accordance with the first service resource control change request.

41. The system of claim 40, wherein the first service includes presenting a television program, and wherein the second service includes a service other than presenting a television program.

42. The system of claim 40, wherein the resource control request for the second service includes a request for full screen control, and wherein the first service resource control change request includes a request for- reduced screen control.