CA2401622A1 - System and method for a client device to load applications during initialization - Google Patents
System and method for a client device to load applications during initialization Download PDFInfo
- Publication number
- CA2401622A1 CA2401622A1 CA002401622A CA2401622A CA2401622A1 CA 2401622 A1 CA2401622 A1 CA 2401622A1 CA 002401622 A CA002401622 A CA 002401622A CA 2401622 A CA2401622 A CA 2401622A CA 2401622 A1 CA2401622 A1 CA 2401622A1
- Authority
- CA
- Canada
- Prior art keywords
- services
- service applications
- individual service
- denoted
- load application
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
- H04N21/4432—Powering on the client, e.g. bootstrap loading using setup parameters being stored locally or received from the server
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
- H04N21/4383—Accessing a communication channel
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
- H04N21/4431—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB characterized by the use of Application Program Interface [API] libraries
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
- H04N21/458—Scheduling content for creating a personalised stream, e.g. by combining a locally stored advertisement with an incoming stream; Updating operations, e.g. for OS modules ; time-related management operations
- H04N21/4586—Content update operation triggered locally, e.g. by comparing the version of software modules in a DVB carousel to the version stored locally
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/65—Transmission of management data between client and server
- H04N21/654—Transmission by server directed to the client
- H04N21/6543—Transmission by server directed to the client for forcing some client operations, e.g. recording
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/81—Monomedia components thereof
- H04N21/8166—Monomedia components thereof involving executable data, e.g. software
Abstract
A method is provided for a cable television client device during a power-up sequence to load selected applications into a memory from a cable televisions server device coupled to the client device. The server device transmits a table of services to all client devices in the network. The client devices receive the table of services and store the table in memory. The table of services comprises a list of a plurality of individual service applications available to a subscriber utilizing the client device. The client device then determines which of the plurality of individual service applications in the table of services is denoted as a load-on-boot application and attempts to download each such file from the server device. Applications denoted as must-load applications are required by the server to be fully downloaded before a client device can begin normal operations, but applications denoted as preferred-load applications may be interrupted by a subscriber initiated command to the client device requiring the client device to immediately commence normal operations.
Description
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 to 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 15 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, 2o 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 audiovisual 25 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 andlor services. Thus, in order to provide these more powerful and complex features, the simple conventional chamzel 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 andlor to 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 15 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 20 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 fiu~ther 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 25 flexibility is limited.
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 to 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 15 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, 2o 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 audiovisual 25 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 andlor services. Thus, in order to provide these more powerful and complex features, the simple conventional chamzel 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 andlor to 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 15 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 20 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 fiu~ther 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 25 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 to 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 15 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 2o 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 25 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
to 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 15 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 2o 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.
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 to 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 15 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 2o 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 25 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
to 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 15 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 2o 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 l0 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-15 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 20 (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 25 (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 2o 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 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 l0 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, VCR commands, etc. The 2o 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 to 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 15 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 2o 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 25 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 muque service LD.
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 (VOD) 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, 2o activation, and suspension of services. Second, an application must share 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 to 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 15 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 20 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 S I" 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 def nitions 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 to 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 15 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 20 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 25 operator configures the SAM Server 56 in designating an individual application to either be a must-load or preferred-load application. 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 1o 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 1.6 can commence normal viewing operations. As previously stated, application clients that are 15 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 2o 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 25 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 to 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 15 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 2o 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 25 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-1 o 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 15 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 20 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 25 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 l0 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 15 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 20 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 medimn"
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 2o 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 to 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.
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 l0 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-15 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 20 (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 25 (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 2o 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 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 l0 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, VCR commands, etc. The 2o 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 to 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 15 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 2o 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 25 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 muque service LD.
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 (VOD) 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, 2o activation, and suspension of services. Second, an application must share 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 to 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 15 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 20 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 S I" 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 def nitions 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 to 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 15 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 20 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 25 operator configures the SAM Server 56 in designating an individual application to either be a must-load or preferred-load application. 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 1o 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 1.6 can commence normal viewing operations. As previously stated, application clients that are 15 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 2o 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 25 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 to 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 15 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 2o 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 25 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-1 o 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 15 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 20 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 25 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 l0 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 15 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 20 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 medimn"
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 2o 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 to 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.
Claims (16)
1. A method in a cable television client device during a power-up sequence to load at least one application into a memory from a cable television headend server device coupled to the client device, comprising the steps of:
receiving from a server device and storing into memory a table of services wherein the table of services comprises a list of a plurality of individual service applications available to a subscriber utilizing the client device;
determining which of the plurality of individual service applications in the table of services is denoted in the table of services to be loaded during the power-up sequence; and receiving from the server device and storing in memory each of the plurality of the individual service applications denoted in the table of services to be loaded during the power-up sequence.
receiving from a server device and storing into memory a table of services wherein the table of services comprises a list of a plurality of individual service applications available to a subscriber utilizing the client device;
determining which of the plurality of individual service applications in the table of services is denoted in the table of services to be loaded during the power-up sequence; and receiving from the server device and storing in memory each of the plurality of the individual service applications denoted in the table of services to be loaded during the power-up sequence.
2. The method of claim 1, further comprising the steps of:
determining which of the plurality of individual service applications in the table of services is denoted in the table of services as a must-load application; and receiving and storing in memory each of the plurality of the individual service applications denoted in the table of services as a must-load application, wherein receipt of user input during the receiving and storing of a must-load application is unexecuted until receipt of the must load application is complete.
determining which of the plurality of individual service applications in the table of services is denoted in the table of services as a must-load application; and receiving and storing in memory each of the plurality of the individual service applications denoted in the table of services as a must-load application, wherein receipt of user input during the receiving and storing of a must-load application is unexecuted until receipt of the must load application is complete.
3. The method of claim 2, further comprising the steps of:
determining which of the plurality of individual service applications in the table of services is denoted in the table of services as a preferred-load application;
and receiving and storing from the server device in memory each of the plurality of the individual service applications denoted in the table of services as a preferred-load application unless the subscriber commands the client device to cease receiving the plurality of the individual service applications denoted as a preferred-load application and to immediately activate one of the individual service applications already stored on the client device.
determining which of the plurality of individual service applications in the table of services is denoted in the table of services as a preferred-load application;
and receiving and storing from the server device in memory each of the plurality of the individual service applications denoted in the table of services as a preferred-load application unless the subscriber commands the client device to cease receiving the plurality of the individual service applications denoted as a preferred-load application and to immediately activate one of the individual service applications already stored on the client device.
4. The method of claim 3, further comprising the step of:
providing the subscriber the option to abort the receiving and storing in memory of each of the plurality of the individual service applications denoted in the table of services as a preferred-load application from the server device and immediately enable television program viewing.
providing the subscriber the option to abort the receiving and storing in memory of each of the plurality of the individual service applications denoted in the table of services as a preferred-load application from the server device and immediately enable television program viewing.
5. The method of claim 1, further comprising the step of:
launching each of a plurality of the individual service applications downloaded from the server during the power-up sequence of the client device, wherein the individual service may be instantaneously activated to the subscriber upon command.
launching each of a plurality of the individual service applications downloaded from the server during the power-up sequence of the client device, wherein the individual service may be instantaneously activated to the subscriber upon command.
6. The method of claim 5, further comprising the step of:
storing the individual service applications denoted in the table of services as a must-load application in a dynamic random access memory.
storing the individual service applications denoted in the table of services as a must-load application in a dynamic random access memory.
7. A method in a cable television headend server device for downloading applications to a plurality of client devices comprising the steps of:
generating a table of services on the server device, wherein the table of services comprises a listing of each of a plurality of individual service applications available to the plurality client devices from the server device;
transmitting the table of services to the plurality of client devices; and transmitting service applications to the plurality of client devices.
generating a table of services on the server device, wherein the table of services comprises a listing of each of a plurality of individual service applications available to the plurality client devices from the server device;
transmitting the table of services to the plurality of client devices; and transmitting service applications to the plurality of client devices.
8. The method of claim 7, wherein the table of services on the server device includes configurable information about whether any of the plurality of individual service applications is a must-load application, or a preferred-load application.
9. A system for a cable television client device during a power-up sequence to load at least one application into a memory from a cable television headend server device coupled to the client device, comprising:
a table of services received from a server device and stored in memory, wherein the table of services comprises a list of a plurality of individual service applications available to a subscriber utilizing the client device;
logic configured to determine which of the plurality of individual service applications in the table of services is denoted in the table of services to be loaded during the power-up sequence; and logic configured to receive from the server device and store in memory each of the plurality of the individual service applications denoted in the table of services to be loaded during the power-up sequence.
a table of services received from a server device and stored in memory, wherein the table of services comprises a list of a plurality of individual service applications available to a subscriber utilizing the client device;
logic configured to determine which of the plurality of individual service applications in the table of services is denoted in the table of services to be loaded during the power-up sequence; and logic configured to receive from the server device and store in memory each of the plurality of the individual service applications denoted in the table of services to be loaded during the power-up sequence.
10. The system of claim 9, further comprising:
logic configured to determine which of the plurality of individual service applications in the table of services is denoted in the table of services as a must-load application; and logic configured to receive and store in memory each of the plurality of the individual service applications denoted in the table of services as a must-load application, wherein receipt of user input during the receiving and storing of a must-load application is unexecuted until receipt of the must load application is complete.
logic configured to determine which of the plurality of individual service applications in the table of services is denoted in the table of services as a must-load application; and logic configured to receive and store in memory each of the plurality of the individual service applications denoted in the table of services as a must-load application, wherein receipt of user input during the receiving and storing of a must-load application is unexecuted until receipt of the must load application is complete.
11. The system of claim 10, further comprising:
logic configured to determine which of the plurality of individual service applications in the table of services is denoted in the table of services as a preferred-load application; and logic configured to receive from the server device and store in memory each of the plurality of the individual service applications denoted in the table of services as a preferred-load application unless the subscriber commands the client device to cease receiving the plurality of the individual service applications denoted as a preferred-load application and to immediately activate one of the individual service applications already stored on the client device.
logic configured to determine which of the plurality of individual service applications in the table of services is denoted in the table of services as a preferred-load application; and logic configured to receive from the server device and store in memory each of the plurality of the individual service applications denoted in the table of services as a preferred-load application unless the subscriber commands the client device to cease receiving the plurality of the individual service applications denoted as a preferred-load application and to immediately activate one of the individual service applications already stored on the client device.
12. The system of claim 11, further comprising:
logic configured to provide the subscriber the option to abort the receiving and storing in memory of each of the plurality of the individual service applications denoted in the table of services as a preferred-load application from the server device and immediately enable television program viewing.
logic configured to provide the subscriber the option to abort the receiving and storing in memory of each of the plurality of the individual service applications denoted in the table of services as a preferred-load application from the server device and immediately enable television program viewing.
13. The system of claim 9, further comprising:
logic configured to launch each of a plurality of the individual service applications downloaded from the server during the power-up sequence of the client device, wherein each of the plurality of individual service applications may be instantaneously activated to the subscriber upon command.
logic configured to launch each of a plurality of the individual service applications downloaded from the server during the power-up sequence of the client device, wherein each of the plurality of individual service applications may be instantaneously activated to the subscriber upon command.
14. The system of claim 13, further comprising:
logic configured to store the individual service applications denoted in the table of services as a must-load application in a dynamic random access memory.
logic configured to store the individual service applications denoted in the table of services as a must-load application in a dynamic random access memory.
15. A system for a cable television headend server device to download applications to a plurality of client devices comprising:
a table of services on the server device, wherein the table of services comprises a listing of each of a plurality of individual service applications available to the plurality client devices from the server device;
logic configured to transmit the table of services to the plurality of client devices; and logic configured to transmit service applications to the plurality of client devices.
a table of services on the server device, wherein the table of services comprises a listing of each of a plurality of individual service applications available to the plurality client devices from the server device;
logic configured to transmit the table of services to the plurality of client devices; and logic configured to transmit service applications to the plurality of client devices.
16. The system of claim 15, wherein the table of services on the server device includes configurable information about whether any of the plurality of individual service applications is a must-load application, or a preferred-load application.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US51612300A | 2000-03-01 | 2000-03-01 | |
| US09/516,123 | 2000-03-01 | ||
| PCT/US2001/006664 WO2001065850A2 (en) | 2000-03-01 | 2001-02-28 | System and method for a client device to load applications during initialization |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2401622A1 true CA2401622A1 (en) | 2001-09-07 |
Family
ID=24054215
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002401622A Abandoned CA2401622A1 (en) | 2000-03-01 | 2001-02-28 | System and method for a client device to load applications during initialization |
Country Status (3)
| Country | Link |
|---|---|
| EP (1) | EP1260100A2 (en) |
| CA (1) | CA2401622A1 (en) |
| WO (1) | WO2001065850A2 (en) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| SE0104080D0 (en) | 2001-12-05 | 2001-12-05 | Ericsson Telefon Ab L M | A method and apparatus for negotiating mobile services |
| DE60324782D1 (en) * | 2002-04-12 | 2009-01-02 | Koninkl Philips Electronics Nv | DOWNLOAD PROGRAMS IN RADIO RECEPTION |
| FR2860677B1 (en) * | 2003-10-07 | 2006-05-19 | Sagem | METHOD FOR CONTROLLING A DECODER PARK |
| KR100849842B1 (en) | 2003-12-23 | 2008-08-01 | 삼성전자주식회사 | Apparatus and method for performing broadcast application |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5440632A (en) * | 1992-12-02 | 1995-08-08 | Scientific-Atlanta, Inc. | Reprogrammable subscriber terminal |
| US5734589A (en) * | 1995-01-31 | 1998-03-31 | Bell Atlantic Network Services, Inc. | Digital entertainment terminal with channel mapping |
| US5826166A (en) * | 1995-07-06 | 1998-10-20 | Bell Atlantic Network Services, Inc. | Digital entertainment terminal providing dynamic execution in video dial tone networks |
| US5951639A (en) * | 1996-02-14 | 1999-09-14 | Powertv, Inc. | Multicast downloading of software and data modules and their compatibility requirements |
| US5940074A (en) * | 1996-06-03 | 1999-08-17 | Webtv Networks, Inc. | Remote upgrade of software over a network |
| JP3567696B2 (en) * | 1997-09-24 | 2004-09-22 | 松下電器産業株式会社 | Software download system |
-
2001
- 2001-02-28 EP EP01918290A patent/EP1260100A2/en not_active Withdrawn
- 2001-02-28 CA CA002401622A patent/CA2401622A1/en not_active Abandoned
- 2001-02-28 WO PCT/US2001/006664 patent/WO2001065850A2/en not_active Application Discontinuation
Also Published As
| Publication number | Publication date |
|---|---|
| WO2001065850A2 (en) | 2001-09-07 |
| EP1260100A2 (en) | 2002-11-27 |
| WO2001065850A3 (en) | 2002-03-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2405491C (en) | System for providing alternative services | |
| US6629227B1 (en) | System and method for a communication terminal to manage memory and maintain a current application version for multiple applications | |
| US8776134B2 (en) | Context sensitive television menu | |
| JP4663199B2 (en) | Navigation menu to access the TV system | |
| US6817028B1 (en) | Reduced screen control system for interactive program guide | |
| US6804708B1 (en) | Media-on-demand flexible and adaptive architecture | |
| US20060059525A1 (en) | Media services window configuration system | |
| US20090119708A1 (en) | User interface display without output device rendering | |
| US9537916B2 (en) | Media services devices and methods | |
| CA2376678A1 (en) | Reduced screen control system for interactive program guide | |
| CA2401622A1 (en) | System and method for a client device to load applications during initialization | |
| WO2012169833A2 (en) | Method for providing semantic application | |
| CA2606753C (en) | System and method for a communication terminal to manage memory and maintain a current application version for multiple applications | |
| KR100242643B1 (en) | Automatic main power off method of multi television | |
| WO2001076229A1 (en) | Service resource environment management system | |
| WO2002063881A1 (en) | User model for interactive television system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued | ||
| FZDE | Discontinued |
Effective date: 20060228 |