METHOD AND SYSTEM FOR PAUSING AND REPLAYING SCHEDULED RICH MEDIA BROADCASTS
CROSS-REFERENCE TO RELATED APPLICATION
This application is related to U.S. Patent Application No. 09/586,247 (Att. Dkt. No.: INEP002), filed concurrently herewith, and entitled "METHOD AND SYSTEM FOR RECORDING SCHEDULED PROGRAMS WITHOUT LOCAL RECORDING EQUIPMENT", the content of which is hereby incorporated by reference.
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 that enable users to pause broadcasted programs.
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 information over the Internet.
To continuously receive a broadcasted program (e.g., a movie, a news report, a television show, etc.) when suddenly called upon to attend to unexpected tasks or errands, a user conventionally turns on a video cassette recorder (VCR) to record the
currently broadcasted program. Some time later the user can return to the VCR and replay the recording when the user desires to finish the program. The VCR solution is not helpful when the program is delivered over a network to a computing device such as a desktop computer or a portable device. The VCR solution also requires that the user later view the recording from the location of the recorded tape and VCR.
Recently, Personal Video Recorder (PVR) was made available by TiVo Inc. (see www.tivo.com). The PVR allows for local storage (including a pause type operation) 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.
Thus, there is a need for improved techniques to record broadcasted programs without a need for end users to provide recording equipment.
SUMMARY OF THE INVENTION
Broadly speaking, the invention relates to improved techniques to record a broadcasted program for later viewing. According to one aspect of the invention, a system and method are able to pause an ongoing program being broadcasted upon receiving a pause request from a subscriber. According to a second aspect of the invention, a system and method are able to replay a previously paused 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 delivery of scheduled broadcasted programs from a video delivery center to one or more client machines via a transmission media, one embodiment of the invention includes the acts of: receiving externally produced broadcasted programs; caching program content of the broadcasted programs in local storage associated with the video delivery center; delivering the broadcasted programs to the one or more client machines by streaming the program content from the local storage to the one or more client machines via the transmission medium; receiving a pause request from at least a particular one of the client machines requesting to pause a particular one of the broadcasted programs being delivered to the particular one of the client machines; and performing the pause request by server-side retention of the
program content for the particular one of the broadcasted programs so as to render the program content following the pause request to be subsequently available to a device decided by a user of the particular one of the client machines.
As a video delivery server that provides video program content to client machines, one embodiment includes at least a storage area, an account manager, a program streaming manager, and a pause/replay manager. The storage area stores program content for programs being delivered to the client machines. The account manager operates to determine whether a client's request is authorized based on account information accessible by the account manager. The program streaming manager operates to stream the program content for the programs to the client machines in accordance with a schedule. The pause/replay manager receives a pause request from a particular client machine, and causes the remaining program content for the program being streamed to the particular client machine to be retained in the storage area so that it is subsequently available to a device decided by a user of the particular client machine (e.g., the particular client machine itself) when the pause/replay manager receives a replay request from the device.
As a computer readable medium including computer program code for delivery of scheduled broadcasted programs from a video delivery center to one or more client machines via a transmission media, one embodiment of the invention includes at least: computer program code for receiving externally produced broadcasted programs; computer program code for caching program content of the broadcasted programs in local storage associated with the video delivery center; computer program code for delivering the broadcasted programs to the one or more client machines by streaming the program content from the local storage to the one or more client machines via the transmission medium; computer program code for receiving a pause request from at least a particular one of the client machines requesting to pause a particular one of the broadcasted programs being delivered to the particular one of the clients; and computer program code for performing the pause request by server-side retention of the program content for the particular one of the broadcasted programs so as to render the program content following the pause request to be subsequently available to a device decided by a user of 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 associated with paused programs is centrally provided at a server so that client machines need not be burdened with storage of digital data locally. Another advantage of the invention is that the portion of the program content stored after the program has been paused is able to be subsequently viewed at the subscriber's convenience from anywhere network access is available. Still another advantage of the invention is that access by subscribers to pause and replay features can be controlled in accordance with account information (e.g., subscribed level of service). Still another advantage of the invention is that the sufficient storage capacity provided at the remote site is advantageous because the user does not need to worry about a program being paused exceeding the storage capacity in a local recording equipment.
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. 1 B 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. 3A is a flow diagram of server processing according to one embodiment of the invention;
FIG. 3B is a diagram of exemplary program storage structure to retain a paused program in a remote storage space;
FIG. 4 is a flow diagram of client pause processing according to one embodiment of the invention; and
FIG. 5 is a flow diagram of client playback 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 viewing. According to one aspect of the invention, a system and method are able to pause an ongoing program being broadcasted upon receiving a pause request from a subscriber. According to a second aspect of the invention, a system and method are able to replay a previously paused program to permit later viewing by a subscriber.
Embodiments of this aspect of the invention are discussed below with reference to FIGs. 1 A - 5. 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 (content providers) 102. Examples of media sources include broadcast stations, satellite receivers, television relay stations, and Internet sites that provide continuous media signals over the Internet. 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 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. Generally, such TV signals are in analog form. Hence, the delivery agent 104 can include an encoder that digitizes the TV signals and converts the digitized TV signals to a digital format 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 (i.e., encoder and decoder), 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 digital format (e.g., MPEG), via the delivery agent 104 from the media source 102.
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.
FIG. 1B 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. 1B, 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, private/public telephone networks, or CAT-5. 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. 1B. The server 200 may be a cluster of server computing devices coupled together and operated by a media delivery enterprise. 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 pausing of broadcasted programs, and to permit replay of previously paused 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. 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).
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 pause and playback features offered by the server 200. Hence, when a request (e.g., pause 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.
FIG. 3A is a flow diagram of server processing 300 according to one embodiment of the invention. The server processing 300 is, for example, performed by the server 106 illustrated in FIG. 1A or the video delivery center 152 illustrated in FIG. 1B.
The server processing 300 initially receives 302 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 304 in local storage space provided such is permitted by the owners of the broadcasted programs. Typically, the local storage space is associated with the server [JZ1]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. Next, the
broadcasted programs are delivered 306 to client machines as scheduled. Here, the broadcasted programs are intended to be delivered by the server to various client machines in accordance with a schedule. Hence, the server operates to deliver 306 the broadcasted programs to the client machines by transmitting (or streaming) data that has been cached in the local storage space. Typically, the client machines that are desirous of receiving the broadcasted programs are able to receive the broadcasted programs from the server over a link. The link can be provided through one or more different transmission mediums, such as a telephone network, a broadband network (e.g., ATM, SONET), etc. It is, however, preferred that the transmission mediums have high bandwidths to support delivery of media-rich content and the quality of service (QoS) thereof.
While the broadcasted programs are being delivered 306 to the client machines as scheduled, the server may receive a pause request or a play request. A pause request is associated with a subscriber (client) of a client machine and serves to request to pause a particular broadcasted program that the subscriber is viewing. A replay request is a request by a subscriber of a client machine to start to transmit (or stream), to the subscriber, a broadcasted program that was previously caused to be retained or recorded through use of a pause request.
In any event, a decision 308 determines whether a request has been received at the server. When the decision 308 determines that a request is not received, then the server processing 300 returns to operation 306 to continue the delivery of the programs to the subscribers. On the other hand, when the decision 308 determines that a request has been received, a decision 309 determines whether the request is a pause request or a replay request. When the decision 309 determines that a pause request has been received, then a decision 310 determines whether an account status associated with the subscriber permits the requested action. Here, a subscriber has a particular account status (e.g., by a fee arrangement) that allows the subscriber to utilize certain features and components offered by the server (e.g., video delivery center). Accordingly, the decision 310 determines whether the account status for the requesting subscriber allows the subscriber to pause broadcasted programs for later replay. Depending on the level of service the subscriber has opted for or receives, the subscriber may or may not be authorized to take advantage of the pause and/or replay capabilities of the server. When the
decision 310 determines that the subscriber's account status does not permit pause requests to be honored, then the server processing 300 returns to the operation 306 to continue the delivery of the programs to the subscribers. On the other hand, when the decision 310 determines that the subscriber's account status does permit pause requests, then the pause request is performed 312 by server-side retention of the program content. In other words, when the pause request is performed, the server causes the program content (of the broadcasted program being viewed by the subscriber) that has not yet been delivered to be retained at the server. As a result, the balance of the broadcasted program that the subscriber desired to pause is retained for the subscriber so that the subscriber can later play the portion of the broadcasted program they have not yet viewed. In one embodiment, the pause request can include a subscriber identifier and a time stamp. The subscriber identifier allows the server to associate the pause request with a particular subscriber. The time stamp allows the server to determine the portion of the broadcasted program that is to be recorded. The manner in which the pause request is performed by the server-side retention can vary depending on implementation. In one embodiment, the server-side retention can operate to record the remaining program content in an allocated local storage space (e.g., rented by the subscriber). In another embodiment, the server may simply arrange a data structure to associate the remaining content such that it remains cached in the local storage space from the caching that was performing at operation 304.
FIG. 3B illustrates a representative data structure 350 for remote content storage. The data structure or index 350 includes a time, a date, a starting address, an ending address, a title and other information that will facilitate the retrieval of the program when a replay request is received. The time and the date indicate when a viewer made the pause request and may be obtained from a set-top box having a timer (i.e., a time stamp) preferably synchronized with the server. In practice, there may be a delay in receiving the pause request by the server. With the time information, the server does not have to receive the pause request instantly (which is impossible due to network delays). The starting address determined primarily by the time the pause request was entered 356 indicates where the remaining program shall be retained. The ending address indicates where the remaining program ends in memory 352. Other information possibly included in the index 350 may be the title of the program being requested for pausing. After the pause request has been
performed 312, the server processing 300 returns to continue the operation 306 and subsequent operations.
Alternatively, when the decision 309 determines that a replay request has been received. When the decision 309 determines that a replay request has been received, a decision 314 determines if the requested retained program content is available. In some cases, the original retained program content may have been deleted due to an expired term or time. If the decision 314 determines that the requested retained program is indeed available, the request is analyzed to determine where the requested program is to be delivered. In other words, the replay request causes the server-side retained program content to be delivered 316 to a subscriber at a particular address. Here, the subscriber need not be in the same location or utilize the same client machine from which the initial portion of the broadcasted program was viewed from. Hence, the retained program content can be delivered 316 (streamed) to a particular address wherever the subscriber happens to be located, thereby allowing the subscriber to watch the portion (e.g., remaining portion) they have not yet viewed. 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.
FIG. 4 is a flow diagram of client pause processing 400 according to one embodiment of the invention. The client pause processing 400 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 pause processing 400 begins with a decision 402 that determines whether the subscriber associated with the client device is authenticated. When the decision 402 determines that the client is not authenticated, the client pause processing 400 cannot be carried out until proper authentication is obtained. In one embodiment, the authentication is checked based on a pair of username and password. In another embodiment, the authentication further includes verification of the corresponding account status.
Once the decision 402 determines that proper authentication has been provided, then information on scheduled broadcasted programs is received 404.
Typically, the received information on the broadcasted programs is displayed on a display screen 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 406 determines whether a program selection for viewing has been made. Here, the subscriber of the client device is able to make program selections from those broadcasted programs that are scheduled. When the decision 406 determines that a program selection has not been made, the client pause processing 400 awaits such a selection. Once the decision 406 determines that a program selection for viewing has been made, then the selected broadcasted program is received and played 408 as scheduled. In one embodiment, the playing 408 of the selected broadcasted program operates to display video content on the display device associated with the client device, thereby allowing the subscriber at the client device to view the selected broadcasted program. While the selected broadcasted program is being received and played 408, a decision 410 determines whether a pause request has been made at the client device. When the decision 410 determines that a pause request has not been made, then a decision 412 determines whether the selected broadcasted program is over (has completed). When the decision 412 determines that the selected broadcasted program is over, then the client pause processing 400 is complete and ends because the entire selected broadcasted program has been played. Alternatively, when the decision 412 determines that the selected broadcasted program is not over, then the client pause processing 400 returns to repeat the operation 408 and subsequent operations so that additional portions of the selected broadcasted program can be received and played.
On the other hand, when the decision 410 determines that a pause request has been received, then a pause request is generated 414. In one embodiment, the pause request includes a pause identifier, a broadcasted program identifier, a subscriber identifier, and a time stamp. [JZ2]Then, the pause request is transmitted 416 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 PSTN. A decision 418 then determines whether the pause request has been accepted by the server. When the decision 418 determines
that the pause request has not been accepted by the server, then the client pause processing 400 returns to repeat the operation 408 and subsequent operations because the pause request has been denied. Alternatively, when the decision 418 determines that the pause request has been accepted, then the client pause processing 400 is complete and ends. The client pause processing 400 optionally can inform the subscriber whether the server accepted the pause request by displaying a message on the display device.
FIG. 5 is a flow diagram of client playback processing 500 according to one embodiment of the invention. The client playback processing 500 is, for example, performed by a play device. The playback device can, for example, be the terminal 110 illustrated in FIG. 1A or the client machines 162 or 162 illustrated in FIG. 1B or a portable device with a display screen.
The- client playback processing 500 begins with a decision 502 that determines whether the subscriber associated with the client device is authenticated. When the decision 502 determines that the client is not authenticated, the client playback processing 500 cannot be carried out until proper authentication is obtained. In one embodiment, the authentication is checked based on a pair of username and password.
Once the decision 502 determines that proper authentication has been provided, the client playback processing 500 continues. Specifically, a list of server- side retained programs is received 504. Here, the list of server-side retained 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 server-side retained programs are those programs that have been saved following a pause request. Typically, the list of server-side retained programs would list those programs that have been retained after the subscriber had requested to pause the broadcasted programs while receiving and viewing the broadcasted programs.
Next, a decision 506 determines whether a retained program has been selected. Here, the subscriber can select one of the server-side retained programs from the list. Hence, the decision 506 determines whether one of the server-side retained programs has been selected. When the decision determines that a retained program has not yet been selected, then the client playback processing 500 awaits
such selection. Once the decision 506 determines that a retained program has been selected, then the client playback processing 500 generates 508 a replay request for the selected program. Then, the replay request is transmitted 510 to the server. Thereafter, the server-side retained program content for the selected retained program is received and played. In one embodiment, the retained program content is transmitted (streamed) to the particular client device from which the subscriber has made the replay request. Typically, the server-side retained content for the selected retained program contains only content for the remaining portion of the broadcasted program. The remaining portion represents that portion of the broadcasted program following the activation of a pause request. Hence, the playback request can be issued from, and the playback directed to, any client device. Thus, subsequent viewing of a remaining portion of a broadcasted program can be replayed to a subscriber at any client device whenever requested. Following the playback of the retained program content at operation 512, the client playback processing 500 is complete and ends.
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 medium 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 associated with paused programs is centrally provided at a server so that clients need not be burdened with storage of digital data locally. Another advantage of the invention is that the portion of the program content stored after the program has been paused is able to be subsequently viewed at the subscriber's convenience from anywhere network access is available. Still another advantage of the invention is that access by subscribers to
pause 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.