SYSTEM AND METHOD FOR A CLIENT DEVICE TO LOAD APPLICATIONS
DURING INITIALIZATION
FIELD OF THE INVENTION This invention relates in general to the field of television systems, and more particularly, to the field of cable system application management.
BACKGROUND OF THE INVENTION Historically, television services have been comprised of analog broadcast audio and video signals. Cable television systems now receive broadcasts and retransmit them with other programming to subscribers over land-line networks, typically comprising fiber optic cable and/or coaxial cable. With the recent advent of digital transmission technology, cable television systems are now capable of providing much more than the traditional analog broadcast video. In addition, two-way and advanced one-way communications between a subscriber and a cable system headend are now possible.
In implementing enhanced programming, the home communication terminal ("HCT"), otherwise known as the settop box, has become an important computing device for accessing video services and navigating a subscriber through a maze of services available. In addition to supporting traditional analog broadcast video and functionality, digital HCTs (or "DHCTs") now also support an increasing number of services which are not analog, but rather digital; are not basic broadcast, but rather two-way communication such as video-on-demand; and are not basic video, such as e-mail or web browsers. These are all in addition to the host of other television services which are increasingly being demanded by consumers, examples of which include audio and audio/visual programming, advance navigation controls, impulse pay-per-view technology, and on-
line commerce. In addition to the interactive services, the increased bandwidth available through a digital television system has made it possible for a subscriber to have access to hundreds, or even thousands, of channels and/or services. Thus, in order to provide these more powerful and complex features, the simple conventional channel abstractions need to be extended beyond those which have traditionally been provided.
Each HCT and DHCT (collectively hereinafter "DHCT") are typically connected to a cable or satellite television network. The DHCTs generally include hardware and software necessary to provide the functionality of the digital television system at the client's site. Preferably, some of the software executed by a DHCT is downloaded and/or updated via the cable television network. Each DHCT typically includes a processor, a communication component 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 a television, a DHCT and/or its functionality may be integrated into a television or personal computer, as will be appreciated by those of ordinary skill in the art.
As more and more services and applications are made available, it becomes increasingly important to properly manage limited client resources. Because the memory contained in the DHCT is typically finite, only a limited number of services and applications may be downloaded to and stored on the DHCT at any given time. Because of the limitations on memory, the cable television system providers must make decisions in regard to what services and applications are always immediately available to the subscribers in the DHCT. In making these decisions, the cable television system providers must further decide what applications are always stored in the DHCT and what applications are additionally downloaded to the DHCT. Such decisions can be difficult and complicated, particularly if flexibility is limited.
Also, because a single tuner system is often used in the DHCT to either download applications or view a television program, television viewing can be unacceptably delayed during initialization of the DHCT after a power failure. Historically, the time required to download the individual applications and services can take a substantial amount of time, thereby preventing the user from viewing the desired television program.
For this reason, the cable television system providers are unable to always download desired applications and services to the DHCT because of the additional time delay required in the downloading process. As a result, there is a need for a system and a method for flexible downloading of applications to a DHCT during initialization, or power up booting of the DHCT.
SUMMARY OF THE INVENTION Briefly described, the preferred embodiment of the present invention provides a system and method for a DHCT during a power up sequence to obtain and store applications into memory from a headend service device coupled to the DHCT. In one implementation, the DHCT, when it is initially booted upon power-up, receives a table of services from the server device and stores that table of services in memory. As an example, the table of services preferably comprises a list of each individual service application available to the subscriber utilizing the DHCT with indications of whether each application is to be loaded during initialization, including whether the download can be interrupted by a user.
One advantage of the preferred embodiment of the present invention is that it solves the problem of requiring a subscriber to wait an unreasonably long period of time while a DHCT downloads applications during an initial power up sequence.
Another advantage of the preferred embodiment of the present invention is that it enables selected applications and services to be available to a subscriber immediately upon
command even though the application and/or service is not permanently installed on the
DHCT in non-volatile memory.
Another advantage of the preferred embodiment of the present invention is that it
enables a subscriber to quickly view an individual television service by terminating the
download of applications denoted as preferred-load by a cable television system operator.
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 of a cable television system in accordance with one embodiment of the present invention.
FIG. 2 is a block diagram of selected DHCT components and applications in various
memories with related equipment in accordance with the preferred embodiment of the present invention depicted in FIG. 1.
FIG. 3 is a diagram of the cable television system of FIG. 1 including selected
components located in the headend of the cable television system and a layered view of
selected elements in the DHCT.
FIGS. 4 and 5 are a flowchart representation of the application loading process in
accordance with the preferred embodiment of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT FIG. 1 is a block diagram of a cable television system 10 including a headend 11 for receiving television signals, such as satellite television signals, and converting the signals into a format for transmitting the signals over the system 10. The transmitted signals can, for example, be radio frequency (RF) signals or optical signals, as shown, transmitted over fiber optic cable 12. When the optical signals are transmitted by the headend 11, one or more optical nodes 13 are included in the system 10 for converting the optical signals to RF signals that are thereafter routed over other media, such as coaxial cables 14. Taps 15 are provided within the cable system 10 for splitting the RF signal off, via cables 17, to subscriber equipment such as DHCTs 16, cable-ready television sets, video set recorders, or computers. Thus, headend 11 is connected through a network 20 to multiple DHCTs 16. FIG. 2 is a block diagram illustrating the DHCT 16 and other system equipment. The DHCT 16 is typically situated within the residence or business of a subscriber. It may be integrated into a device that has a display 21, such as a television set, or it may be a stand- alone unit that couples to an external display 21, such as a display included in a computer or a television, and that processes television signals for presentation to a subscriber. The terminal 16 preferably comprises a communications interface 22 for receiving the RF signals, which can include video, audio and data information, from the tap 15 and for providing any reverse information to the tap 15 for transmission back to the headend 11 (FIG. 1). The DHCT 16 further includes a processor 24 for controlling operations of the
DHCT 16, including an RF output system 28 for driving the 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) demodulator.
Additionally, DHCT 16 includes a receiver 26 for receiving externally-generated information, such as subscriber inputs or commands for other devices. The subscriber inputs may, for example, be provided by a computer or 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.
In one implementation, contained in the DHCT 16 is system memory 29, including flash memory 31 and dynamic random access memory (DRAM) 32, for storing various applications and modules for execution by 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. The operating system 33 operates a broadcast file system (BFS) client module 41. The BFS client 41 is in constant communication with a similar module on the server side (BFS Server 55 in FIG. 3) in the headend 11. This BFS system 41, 55 provides a mechanism for delivering various types of data from a group of servers to a client such as the DHCT 16 attached to the network 10. This data can contain practically any type of information. Applications on both the server and the client can access the data via the BFS API in a similar manner to a file system found on disk operating systems. The DHCT 16 does not typically have enough memory resources to store all the data that is capable of being broadcast from the BFS Server 55. Even if the DHCT 16 could store all the data, there is no guarantee that the DHCT 16 would receive an error-free copy of the data in a single transmission. In some implementations of a broadcast environment, the DHCT 16 does not request that a server re-send any data that was missed and received in error. Also, since the data is being sent to many similar DHCTs 16, it is prohibitive in some implementations to require that the server re-send missed data to each DHCT 16 that
requests it. To ensure that all DHCTs 16 are able to receive an error-free copy of the data, a BFS Server 55 (shown in FIG. 3) repeatedly sends the data over a period of time so that the DHCT 16 that is interested in the data may receive it only when it is required. Thus, the BFS client 41 is the module in the DHCT 16 that receives the broadcast from the BFS Server 55. Consequently, in some implementations, if the DHCT data has an error, the BFS client
41 waits for the next broadcast of the data to receive any data that it may need.
The BFS 41, 55 is implemented to appear to applications as a standard hierarchial file system that is common in computer operating systems. The underlying mechanism for transporting files from a headend server 11 to a DHCT 16 relies on a broadcast data carousel mechanism (not shown). Uniform resource locators (URL) specify BFS 41, 55 as the protocol identity files on the carousel.
Also contained in flash memory 31 is a Navigator module 35, which provides a navigation framework for the subscriber to access services available on the cable system. Examples of the services include, without limitation and in one implementation, watching television programs (available through a WATCHTV application 42) and watching pay-per- view events (available through a PPV application 44), listening to digital music (not shown), and an interactive program guide (not shown), each of which is controlled through separate applications in flash memory 31. The Navigator 35 also allows users to access various settings of the DHCT 16, including volume, parental control, NCR commands, etc. The Navigator 35 additionally is responsible for providing the subscriber with the capability to select 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, a HTML Parser, Database Manager, Widget Toolkit, String Managers, and other utilities (not shown). These utilities are accessed by applications as necessary so that each
application does not have to contain these utilities, thereby making them too large. Three
utilities that are shown in FIG. 2 for the platform library 36 are a Service Application
Manager 37, a Configuration Manager 38, and a Window Manager 39.
The Window Manager 39 provides the mechanism for sharing the screen real estate
and subscriber input. The Window Manager 39 on the DHCT 16 is responsible for 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. 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. The
Configuration manager 38 is a module responsible for receiving information from the
headend server regarding the configuration data files for presentation to the subscriber by the
DHCT 16. A system operator at the headend 11 may utilize a configuration server (not
shown) to construct multiple configuration files for downloading to each DHCT 16. The
Configuration Manager 38 on the DHCT 16 receives the configuration data files and makes
the configuration data available to the applications executing on the DHCT 16, such as the Navigator 35.
The Service Application Manager (SAM) server (not shown) and client 37 provide a
model in which the subscriber can access services, which consist of an application to run and
a parameter, such as data content, specific to that service. The SAM 37 manages a service database 40 in DRAM 32, which includes a tables of services that is updated by the headend 11. The SAM server (not shown) and client 37 also handle the life cycle of the applications on the system, including the definition, activation, and suspension of services they provide and the downloading of the application 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) represent a particular service that has a unique service I.D.
Application clients can be downloaded into DRAM 32 via the BFS at the request of the SAM 37. In this non-limiting example, as shown in FIG. 2, DRAM 32 contains a video- on-demand application (NOD) 43, an e-mail application 45, and a web browsing application 46. It should be obvious 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 all others provided by the cable system operator are top level software entities on the network for providing services to the subscriber. In one implementation, all applications executing on the DHCT 16 work with the Navigator 35 by abiding by several guidelines. First, an application must utilize and implement 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 OS 31, and the DHCT 16. 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. The Navigator 35 will reactivate an individual service application when
it later becomes authorized. Finally, an application must be configured so it does not have access to certain user subscriber input keys (i.e., power, channel +/-, volume +/-, etc.).
The applications that are stored in the DRAM 32 may be applications that are load on-boot or are applications that are downloaded to the DHCT 16 upon a subscriber-initiated command using the remote 27. As will be discussed in more detail, the applications designated as load on-boot may be applications that are must-load or preferred-load depending on their qualification as defined by the system operator at the headend 11. If an application is designated as a must-load application on boot, the SAM 37 provides that the application will be loaded into DRAM 32 when the DHCT 16 powers up and connects to the network 10. As a result, any application that is denoted as a must-load application behaves as if it is resident in flash memory 31 in that it executes immediately at boot and is available to provide services to the subscriber upon command.
FIG. 3 is a diagram of the cable television system of FIG. 1 including selected components located in the headend of the cable television system and a layered view of selected elements in the DHCT. In the implementation shown, the headend 11, includes multiple application servers 51 , 51 ' , 51 " that are responsible for provisioning the services provided by the application and for providing the content or data needed by the DHCT 16. Provisioning is the process that defines an applications' services, including the reservation and configuration of system resources needed to provide those services, and the capability to bill for such services. In a non-limiting example, a first application server 51 ' may be a video-on-demand application and a second application server 51" may be a pay-for-view application. A series of application servers 51 are connected to a digital network control system 53 via an Ethernet connection 52 such as a lOBaseT or a 100BaseT. An application server manager (not shown) may be included to serve as a registry for all application servers
51 residing on the system headend 11. Through the application server manager graphical user interface (GUI), the GUI for all application servers 51 can be accessed.
The digital network control system (DNCS) 53 provides complete management,
monitoring, and control of the network's elements and broadcast services provided to
subscribers. The DNCS 53 includes the definitions of sources, DSM-CC user-to-network
configuration of DHCTs in the network 10 and conditional access management. The
application server 51 communicates via the Ethernet 52 to the SAM Server 56 contained on
the DNCS 53. The application server 51 defines a particular application to the SAM Server
56, and the SAM Server 56 instructs the BFS Server 55 to add the particular application
client executable code to the carousel (not shown) for distribution to the various DHCTs of
the network 10. The SAM Server 56 provides various features for each application that
directs its execution in the network 20. The SAM Server 56 also provides a mapping from the display channel number presented to the subscriber to the service, and vice versa,
including the capability to have one service on a channel for a specified time and another service on that channel for a different specified time. The SAM Server 56 additionally
provides an interface on the SAM Server 56 to specify service-related data, and the SAM
client 36 on the DHCT 16 provides an interface to access this information efficiently. The
SAM Server 56 contains information and configuration data whereby applications and
services on the DHCT 16 can be activated and suspended remotely by the SAM Server 56
by a signaling message. Also, as a part of the present invention, the SAM Server 56 includes
configuration information that denotes whether a specific application is denoted as a load-
on-boot application of the DHCT 16 and whether it can be optionally launched, as discussed
below.
For an application to be loaded when the DHCT 16 powers up, or boots, a system
operator configures the SAM Server 56 in designating an individual application to either be
a must-load or preferred-load apphcation. All other applications not designated as load-on- boot are either already resident in the Flash memory 31 of the DHCT 16, or must be downloaded subsequent to initialization in response to a subscriber request. As a non- limiting example, a digital music application may not be designated by a system operator as a must-load or preferred-load application; therefore, the digital music application would not be downloaded nor would any attempt to download the application would be made during initialization of the DHCT 16. If a subscriber subsequently desired to utilize the digital music application, the DHCT 16 would only then download the digital music application from the BFS Server 55 and thereafter launch and activate the digital music application for the subscriber. In general, the headend 11 includes corresponding counterparts to applications running on the DCHTs 16.
A must-load application is one that must be loaded from the BFS Server 55 to the DHCT 16 when the DHCT 16 is initially powered up by the subscriber before the DHCT 16 can commence normal viewing operations. As previously stated, application clients that are installed in the system headend 11 by the application server 51 are included in the carousel, of the BFS Server 55.
With additional reference to FIGS. 4 and 5, which show a flowchart of the load-on- boot process 60 implemented by the DHCT 16 as depicted in FIG. 2. When a subscriber initially powers up the DHCT 16, as a part of the power up sequence, the DHCT 16 receives a table of services from the SAM Server 56 denoting a complete list of services available from the system headend 11 for implementation by the DHCT 16 and stores the table of services in the service database 40, as indicated in step 62. The SAM client 37 resident on the platform 36 analyzes the table of services list and determines if any of the services are denoted as must-load applications, as indicated in step 64. If any of the services are denoted as must-load applications, the SAM 37 instructs the BFS client 41 to obtain the application
client providing the service from the BFS Server 55. Thus, in a non-limiting example, if a
system operator has determined that the pay-per-view service 44 is a must-load application,
the pay-per-view application 44 would always be loaded from the BFS Server 55 each time
the DHCT 16 is turned on by the subscriber. Upon downloading the pay-per-view
application from the BFS Server 55, the BFS Client 51 loads the pay-per-view application
44 into the DRAM 32. After the pay-per-view application 44 is downloaded and stored in
DRAM 32, the pay-per-view application 44 is launched and prepared for activation by the
subscriber, as shown in step 67. In launch, a thread is created by the DHCT 16 and the main
function of the pay-per-view application 44 is called by the operating system 33 for
implementation upon command.
As a part of the power-up sequence, the DHCT 16 is required to download each
application that is designated by the SAM Server 56 as must-load application during the boot process, as depicted in step 66. In one implementation, while the DHCT 16 is
involved in the downloading process, as shown in steps 68 and 69, the DHCT 16 is not able
to present a subscriber viewing data until the download process of the must-load applications is complete because one tuner system is utilized to alternatively receive applications or view
data.
The system operator at the system headend 11 may also configure the SAM Server
56 to designate an application as a preferred-load application. A preferred-load application
is one whose download may be interrupted by the subscriber that wishes to immediately
activate the DHCT for viewing other services rather than waiting for the download process
to complete. Because of the nature of the BFS carousel and inherent latencies in
downloading files, downloading the must-load and the preferred-load applications may take
seconds and even minutes, and during this time, the subscriber cannot view video, as
discussed above. In one implementation, because the download process occurs in-band
during power-up, the tuner system 25 is busy and unable to tune to video. Alternatively, in
other embodiments of the present invention, a second in-band tuner or an out-of-band tuner
may be available in the DHCT 16 to use for loading applications on boot without preventing
the subscriber from accessing television services already loaded on the DHCT. In a non-
limiting example, the SAM Server 56 may be configured such that the e-mail application 45
in FIG. 2 is denoted as a preferred-load application. In this non-limiting example, where the
pay-per-view application 44 is denoted as a must-load application, the boot sequence
requires that the pay-per-view application 44 must be downloaded to the DHCT 16 before
the DHCT 16 commences viewing operations. After the DHCT 16 downloads the pay-per-
view application 44 as described above, the DHCT begins loading all preferred-load
applications, as shown in step 73, including the e-mail application 45. While the e-mail
application 45 is in the process of being downloaded in step 75 from the BFS Server
carousel 55, the subscriber may choose to interrupt this download process and implement the
DHCT 16 for immediate viewing of other applications. Thus, continuing this non-limiting example, the DHCT 16 may present the subscriber on the display 21 an option to cancel the
download of the preferred load applications as in step 78, in this case the e-mail application,
and commence watching normal television. Thus, the e-mail application 45 and any other
applications denoted as a preferred-load application would not be downloaded, as in step 81,
from the BFS Server 55 to the DHCT 16 and stored in DRAM 32 if the subscriber chooses to cancel the download process 79. The subscriber would not be able to immediately access
any services provided by the preferred-load application that had not been downloaded in the
power up sequence. If the subscriber wished to activate the e-mail application, that
application would have to be downloaded from the BFS Server carousel server 55 before the
subscriber could access the service, as shown in step 83. If, on the other hand, the subscriber
did not interrupt the download process of the preferred load e-mail application 45, the
application would be stored in DRAM 32 in a similar manner as was the pay-per-view
application 44, as shown in step 85. After download of the application is completed, it is
launched and prepared for activation, as shown in step 76. Finally, the DHCT 16 begins
normal viewing operations, as shown in step 84, and any must-load or preferred-load
application that was downloaded in the initialization process is stored in DRAM 32 for
future utilization by the subscriber.
In the case when the subscriber wishes to subsequently download a preferred-load
application or other application client not currently resident in DHCT memory, the DHCT
16 must retrieve the application from the BFS Server carousel 55 before it can be executed
by the DHCT 16 on the display 21. The downloaded operation is asynchronous so that a
suspension request can cancel the activation. If appropriate, the Navigator 35 presents a
download barker or other informational banner to the subscriber to inform the subscriber that
the service is being downloaded. The subscriber may cancel the download process simply by changing the channel or initiating some other input to the DHCT 16 contrary to the current operation.
The flowchart of FIGS. 4 and 5 show the architecture, functionality, and operation
of a possible implementation of software to load and store applications during
initialization. In this regard, each block represents a module, segment, or portion of code,
which comprises one or more executable instructions for implementing the specified
logical function(s). It should also be noted that in some alternative implementations, the
functions noted in the blocks may occur out of the order noted in FIGS. 4 and 5. For
example, two blocks shown in succession in FIGS. 4 or 5 may in fact be executed
substantially concurrently or the blocks may sometimes be executed in the reverse order,
depending upon the functionality involved, as will be further clarified hereinbelow.
The method and system, as described above, enabling the DHCT 16 to obtain and store applications during initialization, may be implemented as a program which comprises an ordered listing of executable instructions for implementing logical functions. Additionally, the program 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. For example, an alternative embodiment might use a TCP-IP based connection to download applications from an HTTP server, instead of the BFS.