Managing peripheral device drivers

Systems and methods are provided for processing device drivers, or software drivers, which enable a device, such as a peripheral device, to perform a particular task. One such method, among others, includes receiving a request for a task to be performed by a peripheral device. In response to receiving the request, the method further includes downloading a peripheral device driver that is configured to enable the peripheral device to perform the requested task.

TECHNICAL FIELD

The present invention is generally related to subscriber television systems, and, more particularly, is related to managing peripheral device drivers in a television set-top terminal.

BACKGROUND OF THE INVENTION

Cable television systems are now capable of providing many services in addition to analog broadcast video. In implementing enhanced programming, the set-top terminal (STT), otherwise known as the set-top box, has become an important computing device for accessing various video services. In addition to supporting traditional analog broadcast video functionality, many STTs now also provide other functionality, such as, for example, an interactive program guide, video-on-demand, and video recording and playback.

An STT is typically connected to a communications network (e.g., a cable or satellite television network) and includes hardware and software necessary to provide various services and functionality. Preferably, some of the software executed by an STT is downloaded and/or updated via the communications network. Each STT also typically includes a processor, communication components, and memory, and is connected to a television or other display device. While many conventional STTs are stand-alone devices that are externally connected to a television, an STT and/or its functionality may be integrated into a television or other device, as will be appreciated by those of ordinary skill in the art.

An STT may include a communication port (e.g., a universal serial bus (USB)) for allowing the STT to be connected to one or more types of peripheral devices, such as, for example, portable audio players, printers, or digital cameras, among others. However, in order for an STT to be capable of communicating with many types and models of peripheral devices, the STT may need to have a large number of suitable device drivers stored in the STT's memory. This may require a large amount of memory and may reduce the amount of memory available for other functionality. Alternatively, an STT may be configured to include additional memory resources for accommodating the large number of device drivers. However, such an STT may not be cost effective and may not be able to communicate with newer peripheral devices for which no device driver is stored in the STT's memory. Yet another alternative is to store a limited number of device drivers in the STT. This approach, however, may prevent STT users from using many types and models of peripheral devices in connection with their STTs. Therefore, there exists a need for addressing these and/or other problems associated with operating peripheral devices.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Preferred embodiments of the invention can be understood in the context of a subscriber television system comprising a set-top terminal (STT). In one embodiment of the invention, an STT receives a request (e.g., from an STT user) for a task to be performed by a peripheral device that is coupled to the STT. Then, in response to receiving the request, the STT downloads a software driver that can be used to enable the peripheral device to perform the requested task. This and other embodiments are explained in more detail below.

In the description that follows,FIGS. 1,2, and4will provide examples of components that may be used to implement a peripheral device driver (PDD) management system. Furthermore, examples of methods related to managing a PDD are illustrated in the flow charts of FIGS.3and5-8. Note, however, that the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Furthermore, all examples given herein are intended to be non-limiting, and are provided in order to help clarify the invention.

Reference is now made toFIG. 1, which is a block diagram depicting a non-limiting example of a subscriber television system (STS)100. In this example, the STS100includes a headend110and an STT120(representative of a plurality of STTs120) that are coupled to a communications network130. The STT120is typically situated at a customer's premises, and may be a stand-alone unit or integrated into another device such as, for example, a television140. The customer's premises may be a user's residence or place of business, for example. The STT120receives signals (video, audio and/or other data) from the headend110through the network130and provides upstream information to the headend110through the network130. The network130may be any suitable means for propagating signals between the headend110and the STT120, for example, a hybrid fiber coax (HFC) network, the Internet, or a satellite communications network, among others.

The STT120is communicatively coupled to a peripheral device150via a wired or wireless communication system. The peripheral device150may be, for example, but not limited to, a printer, a scanner, or a memory device, etc. The STT120is configured to download from the headend110(or some other location) a PDD for driving the peripheral device150. In one embodiment, a plurality of peripheral devices150may be coupled to the STT120.

FIG. 2is a block diagram depicting a non-limiting example of selected components of a headend110, according to one embodiment of the present invention. The headend110comprises a plurality of servers including a first content server102and a second content server104coupled to a BFS server106. Each content server may, in one embodiment, be dedicated to providing certain types of data or software. For example, a content server may be dedicated to providing peripheral device drivers to STTs120(FIG. 1). The BFS server106and/or the content servers104and106are coupled to the communications network130.

The BFS server106periodically broadcasts files over the communications network130. Such periodic broadcasts are preferably made unilaterally, i.e., not in response to requests for the files. In one embodiment, the STT120receives from the BFS server106one or more files comprising a software driver for operating the peripheral device150. Of course, other embodiments include two-way communication systems and methods in which a driver is provided to the STT120in response to a request for the driver by the STT120.

The repetitive broadcasts by the BFS server106may be achieved using, for example, a broadcast carousel mechanism that is defined in the Digital Storage Media Command and Control (DSM-CC) specification ISC/IEC 13818-6 IS, which is hereby incorporated by reference in its entirety. The DSM-CC standard was developed for the delivery of multimedia services and includes several protocol areas addressing different application needs. In one possible implementation, the BFS server106uses a DSM-CC User-to-User Object Carousel protocol to broadcast files to the STT120.

FIG. 3is a flow chart illustrating a data carousel method300in accordance with one possible embodiment of the invention, among others. When a content server wishes to broadcast a file (e.g., comprising data and/or software) via the communications network130, the content server initially registers (block301) with the BFS server106. The BFS server106then creates a hierarchical file system (block302) with all respective files available from each content server that is registered with the BFS server106.

The BFS server106may start with a home directory such as, for example, “\BFS\”, and each content server that has registered with the BFS server106may be assigned a respective directory in this hierarchical file system. For example, if the first content server102and the second content server104register with the BFS server106, then, a first directory “\BFS\first content server\” under the home directory “\BFS\” may be created for the first content server102, and a second directory “BFSsecond content server” under the home directory “\BFS\” may be created for the second content server104.

The first content server102and the second content server104may also create subdirectories under their respective directories. For example, the first content server may create a subdirectory “\BFS\first content server\first subdirectory\.” Additionally, a content server may create and maintain a file under the respective directory for that server. For example, the first content server102may create a file under its respective directory (e.g., “\BFS\first content server\first file”) or under a subdirectory (e.g., “\BFS\first content server\first subdirectory\first file”).

The BFS server106creates a directory index (block303) of all files available from the plurality of servers wishing to broadcast such files to the STT120via the communications network130. This directory index is periodically broadcast (block304) to the STT120via the communications network130by the BFS server106to inform the STT120of files that are available from the plurality of servers. A directory index may include channel information indicating which channel will be used to broadcast a particular file. Each content server may add files to be broadcast to the STT120under a respective directory assigned to that server by the BFS server106.

The directory index is updated as new servers register with the BFS server106, as old servers unregister with the BFS server106, and as each content server modifies the contents under its respective directory. For example, when a content server no longer wishes to broadcast any files via the communications network130, that server may unregister with the BFS server106to remove the respective directory for that server from the directory index. In addition to creating and modifying subdirectories and files under a respective directory assigned by the BFS server106, the content servers102and104may delete subdirectories and files.

The BFS server106and/or the content servers102and104periodically broadcast (block305) files to the STT120. The BFS server106may broadcast files using any of a number of possible broadcasting schemes. As a non-limiting example, among others, one scheme may involve broadcasting certain files more frequently than other files. The STT120extracts one or more desired files from among files broadcast by the BFS server and/or by the content servers102and104(block306).

FIG. 4is a block diagram depicting a non-limiting example of an STT120in accordance with one embodiment of the invention. The STT120includes a communications interface422for receiving signals (video, audio and/or other data) from the headend10, at least one processor424for controlling operations of the STT120, an output system428for driving the television140(FIG. 1), and a tuner system425for tuning to a particular television service to be displayed. The tuner system425may include, in one implementation, an out-of-band tuner for bidirectional quadrature phase shift keying (QPSK) data communication and a quadrature amplitude modulation (QAM) tuner (in-band) for receiving television signals. Files that are broadcast by the BFS server106and/or the content servers102&104are preferably received by the out-of-band tuner. In another embodiment, however, files may be received by the in-band tuner and/or by the out-of-band tuner, depending on a desired implementation. A receiver426receives externally-generated user inputs or commands from an input device such as, for example, a remote control device.

A communication port490is used to communicate with a peripheral device150(FIG. 1). The communication port490may comprise, for example, a USB (Universal Serial Bus), an Ethernet port (for connection to a computer), an IEEE-1394 connection, a serial port, a parallel port, a wireless radio frequency (RF) interface, and/or an infra-red (IR) interface, among others.

The processor424, memory system430, output system428, communication port490, receiver426, and tuner system425are coupled to a local interface410. The local interface410can be, for example but not limited to, one or more buses or other wired or wireless connections. The local interface410may have additional elements to enable communications, such as controllers, buffers (caches), drivers, repeaters, and/or receivers, which are omitted for simplicity.

The processor424is a hardware device for executing software, particularly that stored in memory system430. The processor424can be any custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the STT120, a semiconductor based microprocessor (in the form of a microchip or chip set), or generally any device for executing software instructions. When the STT120is in operation, the processor424is configured to execute software stored within the memory system430, to communicate data to and from the memory system430, and to generally control operations of the STT120pursuant to the software.

The memory system430can include any one or combination of volatile memory elements (e.g., random access memory (RAM), dynamic RAM (DRAM), static RAM (SRAM), synchronous DRAM (SDRAM), magnetic RAM (MRAM), etc.) and nonvolatile memory elements (e.g., read only memory (ROM), hard drive, tape, compact disk ROM (CD-ROM), etc.). Moreover, the memory system430may incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the memory system430can have a distributed architecture, where various components are situated remote from one another, but can be accessed by the processor424.

The software in memory system430may include one or more separate programs, each of which comprises executable instructions for implementing logical functions. In the example ofFIG. 4, the software in memory system430includes a BFS client application432, a host application433, a peripheral device manager434, a PDD436, a communication port driver437, and an operating system (OS)431. The BFS client application432is responsible for receiving BFS files that are broadcast over the communications network130. The host application433, which provides certain functionality to a user of the STT120, communicates with the peripheral device150with the help of the PDD436. The host application433may provide, for example, among others, video-on-demand, interactive television program guide, or Internet access functionality. The peripheral device manager434may, in one implementation, communicate with the BFS client application432in order to request a driver for the peripheral device150. The operating system431essentially controls the execution of the other applications, and provides scheduling, input-output control, file and data management, memory management, and/or communication control, among other functionality.

Each of the above applications may be a source program, an executable program (e.g., object code), a script, or any other entity comprising a set of instructions to be executed. When an application is a source program, then it may be translated via a compiler, assembler, interpreter, or the like, which may be included within the memory system430, so as to operate properly in connection with the OS431. Furthermore, an application can be written as (a) an object oriented programming language, which has classes of data and methods, or (b) a procedure programming language, which has routines, subroutines, and/or functions.

FIG. 5is a flow chart depicting a method500for downloading a PDD436according to one embodiment of the invention. As indicated in step501, the STT120(FIG. 1) receives a request (e.g., from an STT user) for a task to be performed by a peripheral device150(FIG. 1). As a non-limiting example, among others, the task may be a print job, and the peripheral device150may be a printer. If more than one peripheral device150are available for performing a requested task, then a user of the STT120may be able to select which peripheral device150will be used to perform the requested task. In response to receiving a request for the task, the STT120downloads, as indicated in step502, a PDD436that can be used to enable the peripheral device150to perform the requested task.

In one implementation, the peripheral device manager434may be informed by another application (e.g., the host application433) that a task is to be performed by the peripheral device150. In response to such notice, the peripheral device manager434may use a map file downloaded from the headend110to determine the appropriate driver for the peripheral device150. Such map file may contain entries that describe the download locations of respective peripheral device drivers. A map file entry may correspond to a driver that is specific to a particular peripheral device model or to a driver that is generic to a certain type of peripheral device. The peripheral device manager434may inform the BFS client432of the name of the BFS file containing the desired driver and/or of the download location of such file. The BFS client432may then extract the desired driver from a BFS carousel that is broadcast from the headend110, and cause the desired driver to be stored in memory system430. In an alternative embodiment, a PDD436may be downloaded via a unicast transmission or via a non-carousel broadcast from the headend110(or other remote location).

FIG. 6is a flow chart depicting a method600for deleting a PDD436according to one embodiment of the invention. As indicated in step601, the STT120(FIG. 1) determines that there is no pending task to be performed by a peripheral device150(FIG. 1). A counter may be used to keep track of the number of pending tasks to be performed by the peripheral device150. Such a counter may, for example, be decremented and then examined after each task is performed by the peripheral device150. When such counter reaches zero, then a determination may be made that there is no pending task to be performed by the peripheral device150.

In response to determining that there is no pending task to be performed by the peripheral device150, the STT120deletes the PDD436from memory system430and/or designates the memory resources occupied by the driver as available for storing other content, as indicated in step602. By deleting the PDD436when it is not in use, limited memory resources of the STT120may be utilized more efficiently. The steps601and/or602may be implemented by the STT120via, for example, the peripheral device manager434and/or other applications or elements of the STT120.

FIG. 7is a flow chart depicting a method700for downloading a PDD436according to one embodiment of the invention. Some or all of the steps of method700may be initiated and/or implemented by STT120(FIG. 1) through the peripheral device manager434(FIG. 4). As indicated in step701, the STT120determines whether a first type of driver is available to be downloaded. The first type of driver is preferably a driver that is specifically programmed to help operate peripheral devices having the same make and model as the peripheral device150. If the first type of driver is available, then the STT120downloads the first type of driver, as indicated in step702.

If the first type of driver is not available to be downloaded, then, as indicated in step703, the STT120determines whether a second type of driver is available to be downloaded. The second type of driver is preferably a driver that is programmed to help operate peripheral devices that are manufactured by the same manufacturer of the peripheral device150, and that therefore may be capable of enabling the operation of the peripheral device150. If the second type of driver is available, then the STT120downloads the second type of driver, as indicated in step704.

If the second type of driver is not available to be downloaded, then, as indicated in step705, the STT120determines whether a third type of driver is available to be downloaded. The third type of driver may be a generic driver that is not specifically programmed to help operate the peripheral device150, but that might, nevertheless, be capable of doing so, at least in part. If the third type of driver is available, then the STT120downloads the third type of driver, as indicated in step706. If, however, the third type of driver is not available, then the STT120informs the user of the STT120that a driver is unavailable and/or that a requested task to be performed by the peripheral device150is incapable of being performed.

FIG. 8is a flow chart depicting a method800for managing a PDD436according to one embodiment of the invention. Some or all of the steps of method800may be initiated and/or implemented by STT120(FIG. 1) through the peripheral device manager434(FIG. 4). As indicated in step801, the STT120receives a request (e.g., from an STT user) for a task to be performed by a peripheral device150(FIG. 1). In response to receiving a request for the task, the STT120determines in step802whether a driver for operating the peripheral device150currently resides in memory system430(FIG. 4). If such driver is currently residing in memory system430, then the driver is used to enable the peripheral device150to perform the requested task, as indicated in step803. If, however, a driver for operating the peripheral device150does not currently reside in memory system430, then the STT120downloads such a driver (e.g., from the headend110(FIG. 1) using a download approach mentioned above), as indicated in step804.

After a driver is downloaded from the headend110, the driver is used to enable the peripheral device150to perform the requested task, as indicated in step803. The peripheral device150then determines whether another task to be performed by the peripheral device150is currently pending, as indicated in step805. If there is no other pending task to be performed by the peripheral device150, the STT120deletes the PDD436from memory system430and/or designates the memory resources occupied by the driver as available for storing other content, as indicated in step806. If, however, there is another task pending, then the driver436is used to enable the peripheral device150to perform such task, as indicated in step803.

The steps depicted in FIGS.3and5-8may be implemented using modules, segments, or portions of code which include one or more executable instructions. In an alternative implementation, functions or steps depicted in FIGS.3and5-8may 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 of ordinary skill in the art.

The functionality provided by the methods illustrated in FIGS.3and5-8, can be embodied in any computer-readable medium for use by or in connection with a computer-related system (e.g., an embedded system) or method. In this context of this document, a computer-readable medium is an electronic, magnetic, optical, semiconductor, or other physical device or means that can contain or store a computer program or data for use by or in connection with a computer-related system or method. Furthermore, the functionality provided by the methods illustrated in FIGS.3and5-8can be implemented through hardware (e.g., an application specific integrated circuit (ASIC) and supporting circuitry), software, or a combination of software and hardware.

It should be emphasized that the above-described embodiments of the invention are merely possible examples, among others, of the implementations, setting forth a clear understanding of the principles of the invention. Many variations and modifications may be made to the above-described embodiments of the invention without departing substantially from the principles of the invention. All such modifications and variations are intended to be included herein within the scope of the disclosure and invention and protected by the following claims. In addition, the scope of the invention includes embodying the functionality of the preferred embodiments of the invention in logic embodied in hardware and/or software-configured mediums.