WO2001093588A2

WO2001093588A2 - Method and system for recording scheduled programs without local recording equipment

Info

Publication number: WO2001093588A2
Application number: PCT/US2001/017440
Authority: WO
Inventors: Yousheng Cao; Reed Jeffery Majors; Ian Locke; Li Liu; Johnny C. Y. Ng; Nam Phu Thanh Do
Original assignee: Minerva Networks, Inc.
Priority date: 2000-05-31
Filing date: 2001-05-30
Publication date: 2001-12-06
Also published as: AU2001275026A1; WO2001093588A3

Abstract

Improved techniques to record a broadcasted program for later viewing are disclosed. According to one aspect of the invention, a system and method are able to record a scheduled program being broadcasted upon receiving a record request from a subscriber. According to a second aspect of the invention, a system and method are able to replay a previously recorded program to permit later viewing by a subscriber.

Description

METHOD AND SYSTEM FOR RECORDING SCHEDULED PROGRAMS WITHOUT

LOCAL RECORDING EQUIPMENT

BACKGROUND OF THE INVENTION 1. Field of the Invention

The present invention is generally related to media broadcasting and, more particularly, to multimedia delivery systems for facilitating recording rich media broadcasts as requested by users.

2. Description of the Related Art The Internet is a rapidly growing communication network of interconnected computers around the world and is penetrating into every household in the United States and many other countries in the world. Together, these millions of connected computers form a vast repository of multimedia information that is readily accessible by users through any of the connected computers from anywhere at anytime. Multimedia information that is commonly available and deliverable via the Internet may include text information, images and graphics, video and audio.

Continuous media information such as video and audio content are often the most demanded resources over the Internet. Delivery of such information over the Internet provides many advantages and benefits that cannot be matched by current television cable systems or broadcasting over the air. Given the vast accessibility of the Internet to the general population, many Internet service providers or Internet content providers are starting to broadcast continuous media programs over the Internet.

Like traditional broadcasting through the cable systems or over the air, continuous media programs can be scheduled for broadcasting over the Internet. However, often the scheduled times for programs are not convenient for some users. For example, a particular program may not be scheduled for delivery when a user desires to receive the program. As another example, a particular program of interest to the user might be broadcast when the user has to attend to an unexpected task or errand. Video Cassette Recorders (VCRs) were introduced many years ago to accommodate the need of users to record scheduled programs for later viewing. Although the VCR allows programs to be recorded, the VCR is inconvenient in various ways. Namely, the recording of a program requires that sufficient VCR tape capacity be provided. Often one sacrifices the recording quality to lengthen the effective tape capacity (e.g., extending a 2-hour tape to a 4- or 6-hour tape). Likewise, the playback of a recorded program on a VCR tape often requires the user to locate the start of the program on the VCR tape. This is a tedious, time consuming task when the program does not start at the beginning of the VCR tape. Also, to later view the program, the user must be in possession of not only the VCR tape having the program recorded thereon but also a VCR.

Personal Video Recorder (PVR) introduced by TiVo Inc. (see www.tivo.com) allows for local storage of broadcasted programs by a set-top box. While the PVR does not require use of a VCR tape, the user is nevertheless required to view previously recorded programs from the location of the PVR. Hence, conventional approaches to the recording of programs and their subsequent playback require local recording equipment (e.g., a VCR or PVR).

Thus, there is a need for improved techniques to provide a mechanism for a user to record a scheduled program without a need to provide recording equipment. SUMMARY OF THE INVENTION

Broadly speaking, the invention relates to improved techniques to record a broadcasted program for later retrieval (e.g., viewing or listening). According to one aspect of the invention, a system and method are able to record a scheduled program to be or being broadcasted upon receiving a record request from a subscriber. According to a second aspect of the invention, a system and method are able to replay a previously recorded program to permit later viewing by a subscriber.

The invention can be implemented in numerous ways, including a method, system, device, or a computer readable medium. Several embodiments of the invention are discussed below. As a method for recording of scheduled broadcasted programs at a server computer system for one or more clients, one embodiment of the invention includes at least the acts of: delivering a program schedule concerning broadcasted programs to one or more client machines via a transmission medium; receiving a record request via the transmission medium from at least a particular one of the client machines requesting to record at least a particular one of the broadcasted programs that are scheduled as indicated by the program schedule; and performing the record request by server-side retention of the program content for at least the particular one of the broadcasted programs so as to render the program content following the record request to be subsequently available to at least the particular one of the client machines.

As a media delivery server that provides media program content to client machines, one embodiment of the invention includes at least a storage area, an account manager, a program streaming manager, and a record/replay manager. The storage area stores program content for programs to be delivered to the client machines. The account manager operates to determine whether a client's request is authorized based on account information accessible by said account manager. The program streaming manager operates to stream the program content for the programs to the client machines. The record/replay manager receives a record request from a particular client machine, and causes the program content for a particular program to be stored in said storage area so that it is subsequently available for retrieval when said record/replay manager receives a replay request from the particular client machine.

As a computer readable medium including computer program code for recording of scheduled broadcasted programs at a server computer for one or more subscribers, one embodiment of the invention includes at least: computer program code for receiving a record request via a transmission medium from a particular one of the client machines requesting to record a particular one of the broadcasted programs that are scheduled to be broadcasted; and computer program code for performing the record request by server-side storage of the program content for a particular one of the broadcasted programs so as to render the program content following the record request to be subsequently available to at least the particular one of the client machines.

The advantages of the invention are numerous. Different embodiments or implementations may yield one or more of the following advantages. One advantage of the invention is that storage of program content for subscribers is centrally provided at a server so that subscribers need not be burdened with storage of digital data locally. Another advantage of the invention is that the previously stored program content is able to be subsequently viewed at the subscriber's convenience from anywhere network access is available (no recording equipment needed). Still another advantage is that the subscriber is able to record multiple programs from different channels at the same time. Still another advantage is that the subscriber does not have to worry if the recording storage may be run out. Yet still another advantage is that the subscriber is able to record an entire program even if the program has already begun to be broadcasted. Still another advantage of the invention is that access by subscribers to record and replay features can be controlled in accordance with account information (e.g., subscribed level of service).

Other aspects and advantages of the invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings which illustrate, by way of example, the principles of the invention. BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be readily understood by the following detailed description in conjunction with the accompanying drawings, wherein like reference numerals designate like structural elements, and in which:

FIG. 1A illustrates a media delivery system according to one embodiment of the invention;

FIG. 1B is a block diagram of a data delivery system according to one embodiment of the invention;

FIG. 2 is a block diagram of a server according to one embodiment of the invention; FIG. 3 is a flow diagram of client record processing according to one embodiment of the invention;

FIG. 4A is a representative screen shot for a client device according to one embodiment of the invention;

FIG. 4B illustrates a representative screen shot for a client device associated with one embodiment of the invention; FIG. 5 is a flow diagram of server recording processing according to one embodiment of the invention;

FIG. 6A illustrates a recorded program (i.e., compressed or digital video (e.g. MPEG)) stored in local server memory between a starting address and an ending address;

FIG. 6B illustrates a representative data table maintained by a server to track those subscribers that have requested to have a particular program recorded as well as the memory location for the recorded program;

FIG. 7 is a flow diagram of client playback processing according to one embodiment of the invention; and

FIG. 8 is a flow diagram of server replay processing according to one embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

The invention relates to improved techniques to record a program being broadcast for later retrieval (e.g., viewing or listening). According to one aspect of the invention, a system and method are able to record a scheduled program to be or being broadcasted upon receiving a record request from a subscriber. According to a second aspect of the invention, a system and method are able to replay a previously recorded program to permit later retrieval by a subscriber. Embodiments of this aspect of the invention are discussed below with reference to FIGs. 1A - 8. However, those skilled in the art will readily appreciate that the detailed description given herein with respect to these figures is for explanatory purposes as the invention extends beyond these limited embodiments.

FIG. 1A illustrates a media delivery system 100 according to one embodiment of the invention. The media content is provided by one or more media sources (i.e., content providers) 102. Examples of media sources include broadcast stations, satellite receivers, television relay stations, analog or digital radio station and Internet sites that provide continuous media signals over the Internet. The media content can take a variety of forms including movies (videos), audio, news, games, events, etc. The media delivery system 100 comprises one or more servers 106, of which only one is shown in FIG. 1A. The servers 106 can also be referred to as head-ends. Each of the servers 106 can provide continuous media services, video-on-demand services and audio-on-demand services to its subscribers. Each of the servers 106 can also provide video/audio mail services and commercial information delivery to its subscribers.

To facilitate the description of the invention, it is assumed below that the media source 102 delivers video programs and the server 106 is configured to provide video services to its subscribers (users). As noted above, it should be recognized that the media source 102 is not limited to delivering or supplying video programs. Those skilled in the art will understand that the description herein can be equally applied to other continuous media forms, such as audio programs delivered over a data network.

The server 106 communicates with the media source 102 through a delivery agent 104. Depending on implementation, the delivery agent 104 can, for example, represent a receiver, a data network, a transcoder (encoder and decoder), or a converter. When the media source 102 is a satellite dish, a broadcasting or relay station, then the delivery agent 104 includes a receiver which receives television (TV) signals that are often in a form that may need to be processed by a transcoder (i.e., encoder and decoder). Generally, such TV signals are in an analog format. Hence, the delivery agent 104 can include an encoder that digitizes the TV signals and converts the digitized TV signals to a digital format (e.g., MPEG) so that the signals can be further processed, stored, and redelivered over a network 108. In one embodiment in which the delivery agent 104 includes a transcoder, the transcoder can be a Minerva VNP, provided from Minerva Networks, Inc., having a business address of 2111 Tasman Drive, Santa Clara, CA 95054.

On the other hand, when the media source 102 is a network video resource over a data network (e.g., the Internet), the delivery agent 104 may be simply part of the data network or may include a converter. Typically, a network video resource provided by a service or content provider is in MPEG format and may/may not be converted depending on the version of the MPEG format. As described above, the media source 102 may take one of the many available video resources and supply it to the server 106 in an appropriate format via the delivery agent 104. In the following description, unless otherwise specifically required, the server 106 receives one or more appropriate video sources, typically in MPEG format, from the media source 102 via the delivery agent 104. The network 108 couples the server 106 to a terminal device 110. The network 108 can be part of a larger network including the Internet, the public switch telephone network (PSTN), a private network, or a wireless network. Through the network 108, the terminal device 110 can receive video services provided by the server 106. Examples of the terminal device 110 may include a desktop computer, a laptop or notebook computer, a set-top box, and a mobile device. In one embodiment, the terminal device 110 (utilized by one or more users) can be coupled to the network 108 by way of a circuit-switched or packet-switched connection. The network 108 can use one or more different transmission mediums, such as a telephone network, a broadband network (e.g., ATM or SONET), etc. It is, however, useful that the transmission mediums have high bandwidths to support delivery of media-rich content and the quality of service (QoS) thereof.

FIG. 1 B is a block diagram of a data delivery system 150 according to one embodiment of the invention. The data delivery system 150 can represent one embodiment of the media delivery system 200 illustrated in FIG. 1A. The data delivery system 150 includes a video delivery center 152 that controls the delivery of video content. The video delivery center 152 receives media-rich broadcasts, such as television or video, from various sources. As shown in FIG. 1 B, the video delivery center 152 can receive local TV broadcasts 154 and satellite broadcasts 156. In addition, the video delivery center 152 can couple to the Internet 158 and thereby also receive Internet broadcasts at the video delivery center 152. Regardless of the source of the media-rich broadcasts, the media-rich content (e.g., video content) thereof is stored by the video delivery center 152 in a digital form. The video delivery center 152 operates to receive the different types of broadcasts and to formulate them into digital content data that is subsequently streamed as scheduled broadcasts to various clients.

To distribute the scheduled programs from the video delivery system 152, the video delivery center 152 couples through a broadband local loop 160 to client machines 162 and 164. Although only two client machines 162 and 164 are shown in FIG. 1 B, the video delivery center 152 can support many client machines. Examples of client machines include personal computers, portable computers, Personal Digital Assistants (PDAs), set-top boxes, hand-held computers, etc. In one embodiment, the video delivery center 152 is provided in a local region and is thus able to couple to the broadband local loop 160 and thus have access to the client machines 162 and 164. The broadband local loop 160 offers broadband network access between the video delivery center 152 and the client machines 162 and 164. For example, the broadband local loop 160 can use one or more of xDSL, ATM, SONET, fiber optic lines, a private/public telephone network, or CAT-5.[jZ1]

FIG. 2 is a block diagram of a server 200 according to one embodiment of the invention. The server 200 is, for example, suitable for use as the server 106 illustrated in FIG. 1A or the video delivery center 152 illustrated in FIG. 1 B. The server 200 includes a pair of interfaces 202 and 204 as well as a media management module 206. The media management module 206 operates to perform delivery of broadcasted programs having media-rich content to clients, to permit recording of broadcasted programs, and to permit replay of previously recorded broadcasted programs.

The media management module 206 includes a management engine 208 and an account interface 210. The management engine 208 provides a mechanism for managing accounts (e.g., account information) for subscribers that have subscribed to the video services provided by the server 200. An account can be provided and managed for each subscriber. Such accounts can be referred to as subscriber (or user) accounts. The accounts (account information) can be stored in the server 200 or in an external device accessible by the server 200. The account interface 210 is used to access the accounts. The server 200 also includes a media storage space 212 that serves to store media-rich content of broadcasted programs that are received at the interface 202 of the server 200. In one embodiment, the broadcasted programs being received are cached in the media storage space 212 for a limited period of time. The media management module 206 operates to deliver (stream) the media-rich content of the broadcasted programs from the media storage space 212 to various clients over a network (e.g., network 108 or loop 160). The media storage space 212 can also store certain broadcasted programs for longer durations when subscribers have requested that the certain broadcasted programs be recorded. Additional details on the operation of the server 200 are described below with respect to FIGs. 5 and 8.

In one embodiment, the account information can be used to restrict the services that are made available to subscribers. For example, only certain subscribers may be permitted to perform record and playback features offered by the server 200. Hence, when a request (e.g., record request) is received from a subscriber over the network 108, the management engine 208 can check the corresponding account status through the account interface 210 and then allow the media management module 206 to perform the request when the account status permits. Hence, service agreements between subscribers and media delivery center can restrict or limit users access to features or services.

FIG. 3 is a flow diagram of client record processing 300 according to one embodiment of the invention. The client record processing 300 is, for example, performed by the terminal device 110 illustrated in FIG. 1A or the client machines 162 or 164 illustrated in FIG. 1B.

The client record processing 300 begins with a decision 302 that determines whether the subscriber associated with the client device is authenticated. When the decision 302 determines that the subscriber is not authenticated, the client pause processing 300 cannot be carried out until proper authentication is obtained. In one embodiment, the authentication is checked based on username and password which can be verified against information in the corresponding subscriber account.

Once the decision 302 determines that proper authentication has been provided, then information on scheduled broadcasted programs is received 304. Typically, the received information on the broadcasted programs is displayed on a display associated with the client device. In one embodiment, the received information of the broadcasted program can include a list of broadcasted programs in accordance with a schedule.

Next, a decision 306 determines whether a program selection has been made. Here, the subscriber of the client device is able to select a program from those broadcasted programs that are scheduled. In one embodiment, the subscriber of the client device selects a program from a list of scheduled programs being displayed on the display of the client device. When the decision 306 determines that a program selection has not been made, the client record processing 300 awaits such a selection. In this case, the subscriber can perform other actions, such as search or navigation actions, so as to display different information on broadcasted programs. Once the decision 306 determines that a program selection for viewing has been made, a decision 308 determines whether a record request has been received from the subscriber. In one embodiment, the record request is a selection of a record button or icon being displayed on the display of the client device. When the decision 308 determines that a record request has not yet been received, then the client record processing 300 awaits such a request. Once the decision 308 determines that a record request has been received, then a record request is generated 310. In one embodiment, the record request identifies the selected program or the appropriate channel, start time, and the subscriber. After the record request is generated 310, the record request is transmitted 312 to the server. In one embodiment, the pause request is transmitted over the Internet to the server using TCP/IP processing. In another embodiment, the pause request is transmitted over a private/public telephone network.

Next, a decision 316 determines whether the record request has been accepted. Here, the server can either accept or decline the record request. For example, the server might decline the record request when the subscriber has not signed-up for such service. In any case, when the decision 316 determines that the server has declined the record request, then the client record processing can return to repeat the operation 304 and subsequent operations so that additional record requests can be processed. In this case, the client record processing 300 can also notify the subscriber that the server has declined the record request by displaying a notification on the display of the client device. Such a notification can, for example, also indicate the reason why the server denied the request. On the other hand, when the decision 316 determines that the record request has been accepted, then the client record processing 300 is complete and ends. Alternatively, instead of ending, the client record processing 300 can return to repeat the operation 304 and subsequent operations so that additional programs can be selected and recorded from the same client device.

It should be noted that the client record processing 300 may be performed or repeated so as to record or request simultaneous or sequential recording of multiple programs. Such recordings may or may not be from the same channels or at the same time. For example, programs 1 , 2 and 3 from channel A and programs 4, 5 and 6 from channel B can be requested for recording where only programs 2 and 5 start at the same time. As a result, multiple programs from the same or different channels may be recorded provided that the recording is permitted by the owners of the programs. Also be noted that the client record processing 300 is equally applied to when one or more of the scheduled programs are already in progress, which will be further detailed below.

FIG. 4A is a representative screen shot 400 for a client device according to one embodiment of the invention. The screen shot 400 represents a Graphical User Interface (GUI) that appears on a display of a client device. Generally, the GUI is provided by the media delivery center and serves to provide a mechanism for a user to interact with the media delivery center. According to one embodiment, the GUI is provided in a markup language and includes a number of active links (e.g., buttons or hyperlinks), each of the links can be activated to bring up another GUI (screen) for a different service. For TV services, the screen shot 400 includes a toolbar region 402, a program selection region 404, and an action region 406. Each of the toolbar region 402, the program selection region 404 and the action region 406 include a number of buttons or icons (or controls) that enable a subscriber (or client) to interact with the GUI. The toolbar region 402 includes a chat button 408 for initiating a chat session, a help button 410 for initiating a help screen, a television (TV) button 412 for initiating a TV program mode, a Media-On-Demand (MOD) button 413 for initiating a MOD mode, a web button 414 for initiating web access, an email button 416 for initiating an email program, and a vault button (e.g., a personal library) 418 for accessing recorded programs. The program selection region 404 includes a mode indicator section 420 for indicating mode (e.g., TV mode being selected in FIG. 4A), a channel selector 422 for selecting channels, a guide button 424 for access to a program guide, a scan button 426 for scanning through programs, and a find button 428 for searching for programs. The action region 406 includes a selected program display area 430 for identifying a selected program, and a show designator 431. In addition, the action region 406 includes a pause button 432 to pause a program being viewed, an information button 434 for obtaining information, an alarm button 436 for providing alarm information, a record button 438 for requesting a record operation, and a rank button 440 for accessing, indicating or providing rank information.

FIG. 4B illustrates a representative screen shot 450 for a client device associated with one embodiment of the invention. The screen shot 450 represents one of the GUIs that appears on a display of a client device and permits a subscriber to enter the record request. Depending on an implementation, a user may enter the record request in various environments. For example, the record request may be entered when the user is browsing a program guide or the user is viewing a program. The screen shot 450 represents the screen shot 400 illustrated in FIG. 4A after the record button 438 has been pressed. After the record button 438 is activated, the display of the client device is updated, as shown by the screen shot 450, to include a record response region 452. In this embodiment, the record response region indicates that the selected program, namely, "Austin Powers, The Spy Who Shagged Me," will be recorded from channel 23, beginning at a start time of 9:30 am. It is noted that, in this embodiment, the selected program can be indicated for recordation once (default state), daily or weekly.

In order to have a program recorded for a subscriber, the subscriber needs only to select (or click) the record button 438. The selected program is then recorded automatically for the subscriber without the subscriber having to indicate a start time or end time for the recording or other inputs. It is also noted that the recording or storage of the program content occurs on the server-side so that the subscriber or client machine need not have access to any recording means for the recording the program content. FIG. 5 is a flow diagram of server recording processing 500 according to one embodiment of the invention. The server recording processing 500 is, for example, performed by the server 106 illustrated in FIG. 1 A or the video delivery center 152 illustrated in FIG. 1 B.

The server recording processing 500 initially receives 502 broadcasted programs from one or more sources. For example, as noted above, the sources of the broadcasted programs can include local TV broadcasts, satellite broadcasts or Internet broadcasts. As the broadcasted programs are received, the broadcasted programs are cached 504 in local storage space. Typically, the local storage space is associated with the server so that it is rapidly accessible. For example, the local storage space can reside within the server or can be a data storage device coupled thereto (e.g., media storage space 212).

Next, a program schedule guide is delivered 506 to a client machine. In one embodiment, the subscriber of a client machine can request the program schedule guide from the server by selecting the guide button 424. After the program schedule guide is delivered 506 to the client machine, a decision 508 determines whether a record request has been received. Here, the server monitors whether the record button 438 associated with the client machine has been pressed. When the decision 508 determines that the record request has not yet been received, the server record processing 500 awaits such a selection. At this time, it should be noted that other actions can be initiated by the subscriber at the client machine, such as pause, information request, alarm, movies-on-demand, email, etc. However, in this embodiment emphasis is placed on recording and playback of broadcasted programs and thus a description herein focuses on the same.

Once the decision 508 determines that a record request has been received, a decision 510 determines whether an account status associated with the subscriber permits the requested action. For example, account status can serve to limit the requested action based on one or more of outstanding balance due, service agreement, sub-account restrictions, and personalized storage space rental limit). Here, a subscriber has a particular account status (e.g., set by a fee arrangement) that allows the subscriber to utilize certain features, services or components offered by the server (e.g., video delivery center). Accordingly, the decision 510 determines whether the account status for the requesting subscriber allows the subscriber to record broadcasted programs for later replay. Depending on the level of service the subscriber has opted for or receives, the subscriber may or may not to be authorized to take advantage of the record and/or replay capabilities of the server. When the decision 510 determines that the subscriber's account status does not permit pause requests to be honored, then the server recording processing 500 returns to repeat the operation 508 to check if there are any requests from other subscribers to be processed.

On the other hand, when the decision 510 determines that the subscriber's account status does permit record requests, then the record request can be processed. More particularly, a decision 512 determines whether the requested program is already scheduled for recording. When a decision 512 determines that the requested program is not already scheduled for recording, then the recording of the requested program is scheduled 516. The server recording processing 500 operates to record programs as requested by various subscribers. Hence, if another subscriber has already scheduled the recording of the program by the server, then the subsequent request from the subscriber (being processed) need not schedule the recording of the same program. Hence, a single recording of a particular program can be later utilized by various subscribers. In any event, when the decision 512 determines that the requested program is already scheduled for recording, or otherwise following the operation 516, then the memory location of the recorded program is added to the subscribers account. Here, the memory location provides an indicator (or reference) to the subscriber's account of where in the local storage managed by the server the recorded program resides. The memory location may take various forms depending on implementation. In one embodiment, the memory location provides information where the requested program will be recorded. For example, a media delivery center maintains a number of media storage disks, each is labeled or referenced accordingly. Hence, the memory location may include the label or reference information of one or more disks which record the requested program when the program is broadcast as scheduled. According to another embodiment, a memory location of the requested program corresponds to the location of where the program is cached in the local storage. In this case, the requested program will not be actually recorded in a separate space, rather the location thereof in the local storage is simply noted in the corresponding subscriber's account. Since the program is cached, a user may request to record a program that has already been in progress. Still according to another embodiment, a memory space can be reserved upon receiving a request to record a program or rented by a subscriber. The memory space may be allocated out of larger media storage and can be later released for other uses after the program is replayed or after an amount of time for keeping the recorded program expires. In this case, the memory location may include memory addresses for the allocated memory for recording the requested program.

Regardless of the exact data or format, this memory location is subsequently used to locate the recorded program when the subscriber later requests that the recorded program be replayed for them. Following the operation 514, the server record processing 500 returns to repeat the operation 508 and subsequent operations so that additional record requests can be processed. Additionally, it should be noted that the server performs various other operations besides record processing and thus may operate to receive additional programs, cache additional programs, or service various other requests that might be received from a client machine.

FIG. 6A illustrates a recorded program (i.e., compressed video (MPEG)) stored in local server memory 600 (e.g., media storage space 212) between a starting address and an ending address. Depending on the implementation, the starting address or both of the starting and ending addresses may be included for the location of the recorded program. FIG. 6B illustrates a representative data table 650 maintained by the server to track those subscribers that have requested to have a particular program recorded as well as the memory location for the recorded program. The data table 650 includes program information 652 that describes the particular program to be recorded, location information 654 that describes the storage location (address) for the recorded program, and requestor information 656 that identifies each of the requestors that have requested that the program be recorded. The location information 654 can provide an indicator (or reference) to where in the local storage associated with the server the recorded program resides. The data table 650 can be used to determine whether a program has already been scheduled for recording (or has already been recorded). In one embodiment, after all the requestors have eventually replayed the recorded program, the recorded program can be removed from the data table 650 as well as the local server memory 600. Additionally, the recorded program can be removed from the data table 650 and/or the local server memory 600 after a predetermined time has elapsed. These approaches enable the local server to remove (or clean-up) stale data to efficiently utilize its storage capacity.

FIG. 7 is a flow diagram of client playback processing 700 according to one embodiment of the invention. The client playback processing 700 is, for example, performed by a media playing device. The media playing device can, for example, be the terminal 110 illustrated in FIG. 1A, the client machines 162 or 164 illustrated in FIG. 1 B, or some other portable device with a display screen and media-rich capabilities. The client playback processing 700 begins with a decision 702 that determines whether the subscriber associated with the client device is authenticated. When the decision 702 determines that the client is not authenticated, the client playback processing 700 cannot be carried out until proper authentication is obtained. In one embodiment, the authentication is checked based on a username and password.

Once the decision 702 determines that proper authentication has been provided, the client playback processing 700 continues. Specifically, a list of stored programs (i.e., server-side recorded programs) is received 704. Here, the list of stored programs can be provided by a server. Typically, the list is presented on a display device associated with the client so that the subscriber (user) can view the list and make a selection. The stored programs (i.e., server-side retained programs) are those programs that have been saved following a record request. For example, in one embodiment, the list of stored programs can be accessed by selecting the vault button 418 shown on the screenshot 400 illustrated in FIG. 4A.

Next, a decision 706 determines whether a stored program has been selected. Here, the subscriber can select one of the stored programs from the list. For example, the screenshot 400 indicates the name of a selected program in the selected program area 430. Hence, the decision 706 determines whether one of the stored programs has been selected. When the decision 706 determines that a stored program has not yet been selected, then the client playback processing 700 awaits such selection. Once the decision 706 determines that a stored program has been selected, then the client playback processing 700 generates 708 a replay request for the selected program. Then, the replay request is transmitted 710 to the server. Thereafter, the stored program content for the selected stored program is received and played 712. In one embodiment, the stored program content is transmitted (streamed) to the particular client device from which the subscriber has made the replay request. Typically, the stored content for the selected stored program contains the content for the broadcasted program. The playback request can be issued from, and the playback directed to, any client device, although it is typically performed by those of the client devices whose subscribers have previously requested the stored program to be saved (recorded). Following the playback of the retained program content at operation 712, the client playback processing 700 is complete and ends.

FIG. 8 is a flow diagram of server replay processing 800 according to one embodiment of the invention. The server replay processing 800 is, for example, performed by the server 106 illustrated in FIG. 1A or the video delivery center 152 illustrated in FIG. 1B.

The server replay processing 800 begins with a decision 802 that determines whether a replay request has been received. When the decision 802 determines that a replay request has not been received, then server maintenance can be performed while the server replay processing 800 awaits to receive a replay request. In particular, the media storage provided at the server can be cleaned-up 804 to remove stored programs no longer needed. In other words, when programs are stored in the media storage at the server, they can be retained for a certain duration or expire after some time period, or no longer be needed when there are no subscribers that have recorded the program but have not yet viewed it. Following the clean-up 804, the server replay processing 800 returns to repeat the decision 802 to await a replay request.

On the other hand, once the decision 802 determines that a replay request has been received, then the server replay processing 800 is effectively invoked. At this point, a decision 806 determines whether the recorded program associated with the replay request is still available. When the decision 806 determines that the recorded program associated with the replay request is not available, then the server replay processing 800 returns to repeat the decision 802 and subsequent blocks because the replay request cannot be satisfied. In this case, the subscriber who has made the replay request can also be notified that the requested program is no longer available and thus the reason why the replay request was denied. On the other hand, when the decision 806 determines that the recorded program associated with the replay request is still available, then the location where the recorded program is stored is determined 808. In one embodiment, the user account associated with the subscriber making the replay request can include the location, or a link (reference) thereto, where the previously recorded program is stored. Typically, the location would be stored in the user account and/or a central data table (e.g., data table 650) following the subscriber's request to record the program. After the location where the recorded program is stored has been determined 808, the recorded program can be delivered 810 to a client machine chosen by the subscriber. In one embodiment, the content for the recorded program is streamed to the client machine. The stored program can be delivered 810 (streamed) to a particular address wherever the subscriber happens to be located, thereby allowing the subscriber to watch the program at any location where a client device is located. The subscriber can also watch the program at times when convenient for the subscriber instead of according to a broadcast schedule. In one embodiment, the particular address is an IP address of a client device chosen by the subscriber. In another embodiment, the particular address is a telephone number to which a play device is coupled thereto. As a result, the subscriber can view the retained remaining portion from anywhere at anytime. Typically, the client machine would be the particular client machine in which the subscriber makes the replay request from. It should be noted, however, that the client machine need not be the same client machine upon which the record request was previously made. Thereafter, the subscriber can view the recorded program from the client machine. Following the operation 810, the server replay processing 800 has completed the replay request for the subscriber and thus processing returns to repeat the decision 802 and subsequent blocks so that additional replay requests can be processed from the same or other subscribers.

The invention is preferably implemented in software, but can be implemented in hardware or a combination of hardware and software. The invention can also be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data which can be thereafter be read by a computer system. Examples of the computer readable medium include read-only memory, random-access memory, floppy disks, CD- ROMs, DVDs, magnetic tape, optical data storage devices, carrier waves. The computer readable media can also be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.

The advantages of the invention are numerous. Different embodiments or implementations may yield one or more of the following advantages. One advantage of the invention is that storage of program content for subscribers is centrally provided at a server so that subscribers need not be burdened with storage of digital data locally. Another advantage of the invention is that the previously stored program content is able to be subsequently viewed at the subscriber's convenience from anywhere network access is available (no recording equipment needed). Still another advantage of the invention is that access by subscribers to record and replay features can be controlled in accordance with account information (e.g., subscribed level of service).

The many features and advantages of the present invention are apparent from the written description and, thus, it is intended by the appended claims to cover all such features and advantages of the invention. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction and operation as illustrated and described. Hence, all suitable modifications and equivalents may be resorted to as falling within the scope of the invention.

Claims

CLAIMSWhat is claimed is:

1. A method for recording of scheduled broadcasted programs at a server computer system for one or more clients, said method comprising: delivering a program schedule concerning broadcasted programs to one or more client machines via a transmission medium; receiving a record request via the transmission medium from at least a particular one of the client machines requesting to record at least a particular one of the broadcasted programs that are scheduled as indicated by the program schedule; and performing the record request by server-side retention of the program content for at least the particular one of the broadcasted programs so as to render the program content following the record request to be subsequently available to at least the particular one of the client machines.

2. A method as recited in claim 1 , wherein said method further comprises: receiving a selection of at least the particular one of the broadcasted programs that are scheduled to be broadcast in the future.

3. A method as recited in claim 2, wherein the record request requests to store a plurality of the broadcasted programs.

4. A method as recited in claim 1 , wherein the client is a user, and wherein only a single user action with respect to the particular one of the client machines is needed to initiate the record request.

5. A method as recited in claim 4, wherein the single user action is selection of a button or icon displayed on a display of the particular one of the client machines.

6. A method as recited in claim 1 , wherein said performing of the record request comprises: determining whether the program content for at least the particular one of the broadcasted programs has already been recorded or scheduled for recording; and avoiding the server-side retention of the program content for at least the particular one of the broadcasted programs when said determining determines that the program content for at least the particular one of the broadcasted programs has already been recorded or scheduled for recording.

7. A method as recited in claim 6, wherein the server-side retention of the program content is recorded at an area of the local storage associated with the server computer system, and wherein said performing of the record request further comprises: providing a reference to the area of the local storage where the program content for at least the particular one of the broadcasted programs is recorded.

8. A method as recited in claim 1 , wherein the server-side retention of the program content is recorded at an area of the local storage associated with the server computer system, and wherein said performing of the record request comprises: providing a reference to the area of the local storage where the program content for at least the particular one of the broadcasted programs is recorded.

9. A method as recited in claim 1 , wherein said performing of the record request by the server-side retention comprises recording the program content for the at least one of the broadcasted programs in a local storage associated with the server computer system.

10. A method as recited in claim 1 , wherein the transmission medium comprises the Internet.

11. A method as recited in claim 1 , wherein the transmission medium comprises a public telephone network.

12. A method as recited in claim 1 , wherein the broadcasted programs are externally produced.

13. A method as recited in claim 1 , wherein the server computer system is a media delivery center.

14. A method as recited in claim 1 , wherein said method further comprises: determining whether an account for the particular one of the clients permits the record request; and ignoring the record request when said determining determines that the account does not permit the particular one of the clients to record.

15. A method as recited in claim 1 , wherein said method further comprises: subsequently receiving a play request from the particular one of the client machines requesting to receive the program content for at least the particular one of the broadcasted programs that has been server-side retained following the record request; and thereafter, in response to the play request, delivering the program content for the particular one of the broadcasted programs to at least the particular one of the client machines by streaming the program content for the particular one of the broadcasted programs that has been server-side retained from the local storage to the particular one of the client machines via the transmission medium.

16. A method as recited in claim 15, wherein said delivering of the program content is directed to a location indicated by the play request.

17. A method as recited in claim 15, wherein the location pertains to a particular Internet Protocol (IP) address.

18. A method as recited in claim 15, wherein the transmission medium comprises the Internet.

19. A method as recited in claim 15, wherein the transmission medium comprises a public telephone network.

20. A method as recited in claim 15, wherein said method further comprises: determining whether an account for the particular one of the clients permits the record request; and ignoring the record request when said determining determines that the account does not permit the particular one of the clients to record.

21. A method as recited in claim 15, wherein said method further comprises: determining whether an account for the particular one of the clients permits the record request; and notifying the particular one of the clients that the record request has been processed.

22. A method as recited in claim 1 , wherein said method further comprises: receiving externally produced broadcasted programs; and caching program content of the broadcasted programs in local storage associated with the server computer system for subsequent delivery to one or more client machines in accordance with the program schedule.

23. A method as recited in claim 1 , wherein the record request identifies a plurality of the broadcasted programs to be recorded, and wherein said performing operates to perform server-side retention of the program content for the plurality of the broadcasted programs.

24. A method as recited in claim 23, wherein the plurality of the broadcasted programs are broadcasted at different times or on different channels.

25. A method as recited in claim 1 , wherein the server-side retention of the program content by said performing can be performed without regard to storage capacity limitations.

26. A method as recited in claim 1 , wherein said performing operates to properly retain the program content for at least the particular one of the broadcasted programs even when said receiving receives the record request after the beginning of the scheduled time of broadcast for the particular one of the broadcasted programs.

27. A media delivery server that provides media program content to client machines, comprising: a storage area, said storage area storing program content for programs to be delivered to the client machines; an account manager, said account manager operating to determine whether a client's request is authorized based on account information accessible by said account manager; a program streaming manager, said program streaming manager operating to stream the program content for the programs to the client machines; and a record/replay manager, said record/replay manager receiving a record request from a particular client machine, and causing the program content for a particular program to be stored in said storage area so that it is subsequently available for retrieval when said record/replay manager receives a replay request from the particular client machine.

28. A media delivery server as recited in claim 27, wherein said storage area receives the program content of the programs being broadcasted in accordance with a schedule.

29. A media delivery server as recited in claim 27, wherein said media delivery server couples to the client machines over the Internet.

30. A media delivery server as recited in claim 27, wherein the program content is stored and streamed in a MPEG format.

31. A computer readable medium including computer program code for recording of scheduled broadcasted programs at a server computer for one or more subscribers, said computer readable medium comprising: computer program code for receiving a record request via a transmission medium from a particular one of the client machines requesting to record a particular one of the broadcasted programs that are scheduled to be broadcasted; and computer program code for performing the record request by server-side storage of the program content for a particular one of the broadcasted programs so as to render the program content following the record request to be subsequently available to at least the particular one of the client machines.

32. A computer readable medium as recited in claim 31 , wherein said computer readable medium comprises: computer program code for delivering a program schedule concerning broadcasted programs to one or more client machines via the transmission medium; and computer program code for receiving a selection of at least the particular one of the broadcasted programs that are scheduled to be broadcasted in the future.

33. A computer readable medium as recited in claim 31 , wherein the subscriber is a user of the particular one of the client machines, and wherein only a single user action with respect to the particular one of the client machines is needed to initiate the record request.

34. A computer readable medium as recited in claim 33, wherein the single user action is selection of a button or icon displayed on a display of the particular one of the client machines.

35. A computer readable medium as recited in claim 31 , wherein said computer program code for performing the record request comprises: computer program code for determining whether the program content for at least the particular one of the broadcasted programs has already been recorded or scheduled for recording; and computer program code for avoiding the server-side storage of the program content for at least the particular one of the broadcasted programs when said computer program code for determining determines that the program content for at least the particular one of the broadcasted programs has already been recorded or scheduled for recording.

36. A computer readable medium as recited in claim 35, wherein the server-side storage of the program content is recorded at an area of the local storage associated with the server computer, and wherein said computer program code for performing of the record request operates to provide a reference to the area of the local storage where the program content for at least the particular one of the broadcasted programs is recorded.

37. A computer readable medium as recited in claim 31 , wherein the server computer is a media delivery center.

38. A computer readable medium as recited in claim 31 , wherein said computer readable medium further comprises: computer program code for determining whether an account for the particular one of the subscribers permits the record request; and computer program code for ignoring the record request when said computer program code for determining determines that the account does not permit the particular one of the subscribers to record.

39. A computer readable medium as recited in claim 31 , wherein said computer readable medium further comprises: computer program code for subsequently receiving a play request from the particular one of the client machines requesting to receive the program content for at least the particular one of the broadcasted programs that has been server-side stored following the record request; and computer program code for delivering the program content for the particular one of the broadcasted programs to at least the particular one of the client machines by streaming the program content for the particular one of the broadcasted programs that has been server-side stored from the local storage to the particular one of the client machines via the transmission medium.

40. A computer readable medium as recited in claim 39, wherein said computer program code for delivering of the program content is directed to a location indicated by the play request.

41. A computer readable medium as recited in claim 39, wherein the location pertains to a particular Internet Protocol (IP) address, and wherein the transmission medium comprises one of the Internet and a public telephone network.

42. A computer readable medium as recited in claim 31, wherein said computer readable medium further comprises: computer program code for determining whether an account for the particular one of the subscribers permits the record request; and computer program code for notifying the particular one of the subscribers that the record request has been processed or declined.

43. A computer readable medium as recited in claim 31 , wherein said computer readable medium further comprises: computer program code for receiving externally produced broadcasted programs; and computer program code for caching program content of the broadcasted programs in local storage associated with the server computer system for subsequent delivery to one or more client machines in accordance with the program schedule.

44. A computer readable medium as recited in claim 31 , wherein the record request identifies a plurality of the broadcasted programs to be recorded, and wherein said computer program code for performing operates to perform server-side retention of the program content for the plurality of the broadcasted programs.

45. A computer readable medium as recited in claim 44, wherein the plurality of the broadcasted programs are broadcasted at different times or on different channels.

46. A computer readable medium as recited in claim 31 , wherein the server-side retention of the program content by said computer program code for performing can be performed without regard to storage capacity limitations.

47. A computer readable medium as recited in claim 31 , wherein said computer program code for performing operates to properly retain the program content for at least the particular one of the broadcasted programs even when said computer program code for receiving receives the record request after the beginning of the scheduled time of broadcast for the particular one of the broadcasted programs.