System and method for capturing broadcast assets for on-demand viewing

Abstract

An asset provider can identify a segment of a broadcast stream to be extracted at a distribution endpoint and formatted for on-demand viewing by cable subscribers. An asset provider can use a start time code and a stop time code to identify the start and end of the segment in the broadcast stream. The asset provider can also insert tags into the broadcast stream identifying a segment to be extracted at the distribution endpoint. Upon receiving the broadcast stream, the distribution endpoint can then extract the segment identified by either the start and stop time codes or the tags.

Description

FIELD OF THE INVENTION

[0002] The present invention is generally directed to cable television networks. More particularly described, the present invention supports identifying a segment of a television broadcast stream to be available to cable subscribers on-demand, extracting the identified segment from the broadcast stream, and formatting the extracted segment for on-demand viewing.

BACKGROUND OF THE INVENTION

[0003] Recent developments in the cable television industry have allowed content providers (or “asset providers”), such as Home Box Office, NBC, and Warner Bros., to provide a variety of cable television services to cable subscribers. For example, a Movie-on-Demand service allows a cable subscriber to view a movie over the cable network with the same type of control that a person typically has over a video cassette recorder (“VCR”) or digital versatile disk (“DVD”) player. More specifically, the Movie-on-Demand service allows a cable subscriber to view a movie over the cable network at any time and to control the delivery of the movie using fast-forward, stop, pause, or rewind functions. However, one limitation of conventional Movie-on-Demand services is that content providers must pre-package Movie-on-Demand assets in a Movie-on-Demand format and distribute the asset to each cable headend that will make the asset available on-demand to cable subscribers. In other words, cable subscribers can only request to view those assets that have been specifically formatted by the content providers for Movie-on-Demand viewing and distributed to one or more cable headends.

[0004] In addition, the television industry has recently witnessed the introduction of Personal Video Recorder (“PVR”) devices, which allow subscribers to record television content and to view the recorded content at a later time. In the conventional art, a PVR device installed in a subscriber's home can record and store television content in digital format on the hard disk of the PVR device. In this way, a subscriber can control the delivery of recorded television content using stop, pause, rewind, and fast-forward commands similar to those used on a VCR or DVD player.

[0005] PVR devices, however, have several limitations. First, a PVR device is limited in the amount of digital television content it can store on its hard disk. Additionally, a cable subscriber must first manually pre-select the television content it wants to record (or the PVR device must record the television content according to a pre-defined profile for the cable subscriber) before the cable subscriber can actually view the recorded television content at a later time. In other words, a cable subscriber cannot view at a later time any television content that has not been previously recorded by the PVR device. Moreover, a PVR device is limited to the number of television programs it can record at one time by the number of tuners it has available.

[0006] Additionally, in pre-selecting what television content to record, a cable subscriber must rely on the program information contained in an electronic program guide. Thus, if a scheduling change alters the air-time of the selected television program, then the PVR device may not record the entire selected television program. For example, if the program guide indicates that the selected television program will be aired from 10:00 p.m. to 11:00 p.m., but the air-time of the program is shifted to 10:30 p.m. to 11:30 p.m. to accommodate a breaking news alert or a live sports program, the PVR device will nonetheless only record the content that is aired between 10:00 p.m. and 11:00 p.m., thereby missing thirty minutes of the program selected by the cable subscriber.

[0007] Moreover, once a PVR device records television content, content providers no longer have any control over the delivery of the content. For example, when viewing television content recorded on the PVR device, cable subscribers can avoid viewing television commercials by fast-forwarding past them. Similarly, once the television content is recorded, the content providers and the cable headends can no longer supplement old television commercials with newer television commercials based upon when the cable subscriber chooses to view the recorded television content. Finally, the cost of installing and maintaining PVR devices in the customers' homes is very expensive compared to the current class of digital set top boxes used to provide television services.

[0008] Consequently, there is a need in the art for a system and method that allows a content provider to offer assets for on-demand applications without requiring the content provider to pre-package the assets in an on-demand application format or to distribute the on-demand asset separately to one or more cable headends. Additionally, there is a need in the art for a system and method that allows a content provider or cable headend to designate an asset for on-demand viewing independent of when an electronic program guide indicates the asset will be aired. Finally, there is a need in the art for a system and method that will allow a content provider or cable headend to maintain control over television content that is made available for on-demand viewing by cable subscribers.

BRIEF DESCRIPTION OF DRAWINGS

[0009] FIG. 1 is a functional block diagram illustrating an exemplary environment in which assets are distributed by multiple asset providers to multiple receivers that are located at one or more distribution endpoints.

[0010] FIG. 2 is a functional block diagram illustrating an exemplary system for identifying one or more segments of a broadcast stream to be extracted at a distribution endpoint and for extracting the identified segments at the distribution endpoint in accordance with one exemplary embodiment of the present invention.

[0011] FIG. 3 is a logic flow diagram illustrating an exemplary process for creating an asset for on-demand viewing from a broadcast stream.

[0012] FIG. 4 is a logic flow diagram illustrating an exemplary sub-process of FIG. 3 for identifying a segment of a broadcast stream to be extracted for on-demand viewing.

[0013] FIG. 5 is a logic flow diagram illustrating an exemplary sub-process of FIG. 3 for extracting a segment from a broadcast stream and preparing the segment for on-demand viewing.

[0014] FIG. 6 is a logic flow diagram illustrating an exemplary sub-process of FIG. 3 for extracting a segment from a broadcast stream when the pre-authored stream metadata is received from the asset provider before the segment is broadcast.

[0015] FIG. 7 is a logic flow diagram illustrating an exemplary sub-process of FIG. 3 for identifying a segment of a broadcast stream to be extracted for on-demand viewing by inserting tags into the broadcast stream.

[0016] FIG. 8 is a logic flow diagram illustrating an exemplary sub-process of FIG. 3 for extracting a segment of a broadcast stream identified by one or more tags and for preparing the segment for on-demand viewing.

[0017] FIG. 9 is a logic flow diagram illustrating an exemplary sub-process of FIG. 3 for extracting a segment of a broadcast stream identified by one or more tags and for preparing the segment for on-demand viewing.

SUMMARY OF THE INVENTION

[0018] The present invention can solve the aforementioned problems by providing a system and method for identifying and extracting a segment of a broadcast stream. In one aspect of the present invention, an asset provider can identify the segment of the broadcast stream to be extracted. The distribution endpoint, upon receiving the broadcast stream, can extract the segment identified by the asset provider. More particularly described, the asset provider can identify the segment using a start time to indicate the start of the segment and a stop time to indicate the end of the segment in the broadcast stream. Using the start time and the stop time, the distribution endpoint can then extract the segment identified by the asset provider from the broadcast stream.

[0019] In another aspect of the present invention, the asset provider can insert one or more tags into the broadcast stream to identify a segment of the broadcast stream to be extracted. Upon receiving the broadcast stream comprising the one or more tags, the distribution endpoint can extract the segment identified by the tags.

[0020] Various aspects of the present invention may be more clearly understood and appreciated from a review of the following detailed description of the disclosed embodiments and by reference to the drawings and claims.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

[0021] Although the illustrative embodiments will be generally described in the context of the cable television industry, those skilled in the art will recognize that other exemplary embodiments of the present invention may be implemented for any application in which an asset provider desires to identify one or more segments of a broadcast stream to be extracted and formatted for a particular application or use. Moreover, those skilled in the art will also recognize that the broadcast stream can comprise a broadcast of any type of media content, including and not limited to analog audio or video media content, MP3 files, digital video files, digital audio or music files, and other digital media and multimedia content. Additionally, those skilled in the art will recognize that an identified portion of the broadcast stream can be extracted and used for a variety of purposes or applications, including for on-demand viewing of a media asset, on-demand listening to a media asset, advertisement-insertion, archiving, and in distance-learning applications.

[0022] In one exemplary embodiment of the present invention, one or more asset providers can broadcast media assets, such as television movies, television series, television episodes, commercials, news programs, sporting events, other broadcast events and programs, or a combination thereof, to one or more exemplary receivers (typically located at cable headends), for further distribution to an audience, such as cable subscribers. An asset provider can comprise any entity that distributes the asset to one or more receivers. An exemplary receiver at a cable headend can receive a broadcast stream of assets from one or more asset providers. Using a segment processor and a live spool, the cable headend can record each broadcast stream or a portion (or “segment”) of each broadcast stream as it is aired to cable subscribers. Upon receiving a request from the asset provider to extract a particular segment of the broadcast stream and to format the segment for use in an on-demand application, the cable headend can extract the identified segment from the broadcast stream or from the broadcast stream recorded in the live spool and format the extracted segment for viewing as an on-demand asset. The cable headend can then store the formatted on-demand asset in an exemplary segment library Video-On-Demand (“VOD”) server.

[0023] In another exemplary embodiment of the present invention, the asset provider can insert tags into the broadcast stream that identify one or more segments to be extracted at the cable headend and formatted for use in on-demand applications. Upon receiving the broadcast stream at the receiver and identifying the one or more tagged segments, the cable headend can extract the tagged segments and format the extracted segments for on-demand viewing. The cable headend can then store the formatted on-demand asset in an exemplary segment library VOD server.

[0024] Referring now to the drawings in which like numerals represent like elements throughout the several figures, exemplary embodiments of the present invention and the illustrative operating environment will be described.

[0025] FIG. 1 is a functional block diagram illustrating an exemplary environment 100 in which assets are distributed by multiple asset providers 10 to multiple receivers 20 that are located at one or more distribution endpoints. Though individual components are illustrated in the exemplary environment of FIG. 1, multiple components can be employed without departing from the scope and spirit of the present invention.

[0026] The exemplary environment 100 can comprise one or more asset providers 10 and receivers 20 coupled to a communications medium 30 and operative to communicate with a satellite 25. Asset providers 10 with a finite number of asset delivery resources can distribute assets to the receivers 20 over various types of network technologies. The asset providers 10 can distribute assets to the receivers 20 via the satellite 25 or an alternative communications link 30 using a broadcast, multicast, or unicast communications methodology.

[0027] Receivers 20 with a finite number of available resources receive assets from one or more asset providers 10 at a distribution endpoint, such as a cable headend. In one exemplary embodiment, a receiver 20 receives assets from multiple asset providers 20 via multiple satellite transponders at varying times. In another exemplary embodiment, a receiver 20 receives assets from multiple asset providers 20 via multiple satellite transponders concurrently. In other exemplary embodiments, the receiver 20 can comprise multiple receivers 20, or the receiver 20 can receive assets from other receivers 20 via an IP or other communication network 30, or the receiver 20 can comprise multiple receivers 20 and receive assets from other receivers 20 via a communication network 30.

[0028] FIG. 2 is a functional block diagram illustrating an exemplary system 200 for identifying one or more segments of a broadcast stream to be extracted at a distribution endpoint and for extracting the identified segments at the distribution endpoint in accordance with one exemplary embodiment of the present invention. Though individual components are illustrated in the exemplary environment of FIG. 2, multiple components can be employed without departing from the scope and spirit of the present invention.

[0029] The asset provider 10 comprises an authoring workstation 215, which assists the asset provider 10 in identifying one or more segments to be extracted from a broadcast stream and used for on-demand applications. The authoring workstation 215 comprises an authoring application 220. Using the authoring application 220, the asset provider 10 creates stream metadata and segment package metadata for each segment to be extracted from the broadcast stream.

[0030] Specifically, the asset provider 10 uses stream metadata to define the attributes of the segment to be extracted from the broadcast stream at the distribution endpoint. In one exemplary embodiment, stream metadata comprises a start time code, identifying the start of a segment; a stop time code, identifying the end of the segment; the duration or length of the segment; a transport stream identifier, identifying the transport stream from which to extract the segment; an asset identifier to be associated with the segment once it is extracted; encoding parameters, such as the bit rate at which the broadcast stream is encoded and any audio channels to be captured; live spool cache controls; encoder controls; and segment creation controls. Exemplary stream metadata can be represented in Extensible Markup Language (“XML”) format.

[0031] In one exemplary embodiment of the present invention, in order to define the attributes of a segment of a broadcast stream, the authoring application 220 spools the broadcast stream into a local live spool 230 along with reference marks, or “synch” marks, that ensure that the broadcast stream stored in the local live spool 230 at the asset provider 10 can be synchronized with the broadcast stream stored in the live spool 250 located at the distribution endpoint. In one exemplary embodiment, the reference marks comprise time codes that are associated with the actual broadcast time codes of the broadcast stream. The asset provider 10 uses this spooled content to describe the segment to be extracted from the broadcast stream. In other words, the authoring application 220 determines the start time code, the stop time code, and the duration of the segment to be extracted by the distribution endpoint based upon the time codes associated with the spooled broadcast stream recorded by the live spool 230.

[0032] If the asset provider 10 knows the start time code, the stop time code, and/or the duration of the segment before the segment is broadcast to the distribution endpoints, the asset provider 10 can pre-author the stream metadata and insert the stream metadata into the broadcast stream. If the pre-authored metadata is transmitted to the distribution endpoint before the segment is broadcast, a segment processor 240 located at the distribution endpoint captures the segment identified by the stream metadata from the broadcast stream and sends it to the segment library VOD server 260 for storage. By having the stream metadata before the segment is broadcast, the distribution endpoint can capture the segment directly from the broadcast stream without first recording and storing the broadcast stream in a live spool 250, thereby alleviating any need for a live spool 250 at the distribution endpoint.

[0033] On the other hand, if the pre-authored stream metadata is distributed to the distribution endpoint during or after the broadcast of the identified segment has begun, and the broadcast stream has been cached in a live spool 250 located at the distribution endpoint, then the segment processor 240 uses the stream metadata to extract the identified segment from the recorded broadcast stream in the live spool 250.

[0034] As storage space is depleted on the live spool 250, the live spool 250 deletes the oldest stored content. However, the asset provider 10 can create stream metadata that modifies this “first-in-first-out” algorithm of the live spool 250. For example, an asset provider 10 can send an instruction to the live spool 250 to save a particular segment of a broadcast stream in the live spool 250 for a specific period of time. Thus, the live spool 250 will not delete the segment when new content arrives.

[0035] The asset provider 10 also uses the authoring application 220 to create segment package metadata. Segment package metadata is used by the asset provider 10 to describe the extracted segment. Specifically, segment package metadata comprises a description of the segment and the lifecycle information for the segment. The segment package metadata is typically made available to a cable subscriber through a digital cable guide to assist the subscriber in searching or selecting an on-demand asset to view. Thus, the segment description describes the attributes of the particular on-demand asset. For example, if the on-demand asset is a television episode, the segment description comprises the episode's title, the names of the actors and actresses who appear in the episode, the plot of the episode, the episode's genre, the television rating of the episode, the viewing time of the episode, and any relevant copyright information about the episode. The segment lifecycle information specifies the amount of time that the segment is to be stored in the segment library VOD server 260 and when or how the segment may be viewed by a cable subscriber.

[0036] Segment package metadata can be transmitted by the asset provider 10 to the distribution endpoint either in-band with the broadcast stream or out-of-band in a separate transport stream. Thus, segment package metadata can be sent either before or after the broadcast stream comprising the identified segment is broadcast to the distribution endpoint. In one exemplary embodiment, segment package metadata is represented in XML format.

[0037] The asset provider 10 also comprises an exemplary multiplexor and scheduling processor 280. The multiplexor and scheduling processor 280 inserts stream metadata into the broadcast stream. Specifically, the multiplexor and scheduling processor 280 determines when the metadata for a segment is inserted into the transport stream, how often metadata is sent to the distribution endpoints, and how the metadata is sent.

[0038] Those skilled in the art will recognize that the stream metadata and segment package metadata may be delivered over communications networks other than satellite multicast or broadcast networks and that applications other than video services may also be provided or enabled without departing from the scope and spirit of the present invention. For example, the metadata may be distributed separately from the broadcast stream, such as via an IP network or other communications network.

[0039] For example, in one exemplary embodiment, in the case of an analog broadcast, the metadata is inserted into the vertical blanking interval (VBI) portion of the broadcast stream using the DVS 253 specification. However, as is recognized by those skilled in the art, other mechanisms for inserting metadata can be used, including inserting metadata using the ATVEF specification.

[0040] In another exemplary embodiment, in the case of a digital broadcast, the metadata is sent as private data in a Moving Pictures Expert Group (MPEG) transport stream. For example, this metadata may be sent in an elementary stream comprising private data. The elementary stream may be associated with a specific program (i.e. CNN metadata sent in the CNN transport stream); with the entire multiplex (i.e. CNN, CNNfn, CNNsi, CNNhn, etc); or an elementary stream in a separate transport stream (i.e., metadata for multiple transport streams sent in a transport stream that carries an elementary stream for this metadata), in which a single receiver 20 is tuned to different transport streams to extract segments. The metadata can be inserted into the MPEG transport stream using the ATVEF specification. However, other mechanisms for inserting metadata can be used without departing from the scope of the present invention.

[0041] In another exemplary embodiment, metadata is sent through a transport mechanism that is not a part of the broadcast stream. For example, the multiplexor and scheduling processor 280 sends the metadata to a receiver 20 over a wide area network (WAN) connection such as the Internet.

[0042] The multiplexor and scheduling processor 280 also controls the operation of the live spool 250 at the headend. For example, the multiplexor and scheduling processor 280 can specify which segments and how many segments are to be stored in the live spool 250. The multiplexor and scheduling processor 280 also maintains a log of all changes made to metadata.

[0043] In one exemplary embodiment, the asset provider 10 transmits the broadcast stream from a transmitter 210 via satellite 25 to the distribution endpoint. A receiver 20 at a distribution endpoint receives a broadcast stream of assets from one or more asset providers 10. The distribution endpoint distributes the broadcast stream to one or more set top boxes 270 located at a cable subscriber's home. The receiver 20 also delivers the broadcast stream to a segment processor 240, which extracts metadata and segments of the broadcast stream identified by an asset provider 10 to create segment packages for use in on-demand applications. Specifically, a segment processor 240 captures the identified segment from the appropriate transport stream as specified by the asset provider 10. The segment processor 240 also maintains a log of segments that are received and any errors that are encountered. A log is maintained as segments are converted and delivered to one or more segment library VOD servers 260.

[0044] More particularly described, in one exemplary embodiment, the segment processor 240 uses the stream metadata received from an asset provider 10 to identify a segment of the broadcast stream that is to be extracted, packaged, archived, formatted, or exported for use in on-demand applications. Specifically, the segment processor 240 uses the start time code, the stop time code, and/or the length of the segment, and the transport stream identifier to identify the segment of the broadcast stream to be extracted. The segment can be extracted directly from the broadcast stream or from a live spool 250 located at the distribution endpoint.

[0045] If necessary, a real time encoder 245 formats the extracted segment as an on-demand asset, so that it may be viewed upon request by a cable subscriber. For example, in one exemplary embodiment, the real time encoder 245 receives analog audio and video broadcast streams and converts the analog audio and video streams into Moving Picture Experts Group (MPEG) video and Dolby audio files. In another exemplary embodiment, the real time encoder 245 receives digital broadcast streams and formats the received digital broadcast streams to a compatible digital format for on-demand viewing by cable subscribers. The extracted and formatted segment of the broadcast asset can be stored in a segment library VOD server 260. In other words, the converted asset and its associated segment package metadata are packaged into a segment package and delivered to a segment library VOD server 260 for storage. In one exemplary embodiment, the segment package is distributed using CableLabs Asset Distribution Interface (ADI) throughout the Video On Demand network. In other exemplary embodiments, other distribution mechanisms may be used.

[0046] If the distribution endpoint comprises a live spool 250, the segment processor 240 can be instructed by the stream metadata to convert all content received during a period of time and pass the converted content to the live spool 250. Any segment package metadata received in the broadcast stream is stored in the segment processor 240. The live spool 250 stores all content passed to it from the segment processor 240 using the same time codes (or other reference marks) that were broadcast with the original content. In other words, the time codes (or other reference marks) of the live spool 250 at the distribution endpoint are in synch with the time codes (or other reference marks) of the live spool 230 at the asset provider 10. Thus, a reference mark that identifies a segment of a broadcast stream in the asset provider's live spool 230 will identify the same segment of the broadcast stream in the live spool 250 at the distribution endpoint.

[0047] The converted content and its associated segment package metadata are packaged by the segment processor 240 into a segment package and delivered to the appropriate segment library VOD server 260. In one exemplary embodiment of the present invention, the segment library VOD server 260 comprises a CableLabs Asset Management System. However, other distribution mechanisms may be used, depending on the capability of the storage subsystem.

[0048] The segment library VOD server 260 maintains an archive of the segment packages that are received from the segment processor 240. Each segment package comprises the segment extracted from the broadcast stream and the segment package metadata associated with the segment. The segment package is maintained in the segment library VOD server 260 in accordance with the lifecycle information in the segment package metadata. The lifecycle information specifies when and how the segment may be requested and viewed by a cable subscriber and when the segment should be deleted from the segment library VOD server 260. The segment library VOD server 260 can also be connected to a billing/authorization system that determines which cable subscribers may request and receive a segment and how much to charge for the viewing of that segment.

[0049] An asset provider 10 can override the lifecycle information for a particular segment stored in the segment library VOD server 260. This override mechanism allows the asset provider 10 to shorten or lengthen the time that a segment remains in the segment library VOD server 260.

[0050] Additionally, the segment library VOD server 260 maintains a log of all segment activity. Segment activity may comprise information about the addition and deletion of segments from the segment library VOD server 260, changes to the configuration of the segment library VOD server 260, and information related to when a segment is requested by a cable subscriber via the interactive television infrastructure 280.

[0051] In another exemplary embodiment of the present invention, a set-top box 270 (as opposed to the segment library VOD server 260) may store the segment package metadata associated with a segment. In yet another exemplary embodiment, a distribution network hub or node (such as a digital cable TV network hub or node) (as opposed to the segment library VOD server 260) may store the segment package metadata associated with each segment.

[0052] Certain steps in the processes described below in connection with FIGS. 3 through FIG. 9 must naturally precede others for the present invention to function as described. However, the present invention is not limited to the order of the steps described, if such order or sequence does not alter the functionality of the present invention. It is recognized that some steps may be performed before or after other steps without departing from the scope and the spirit of the present invention.

[0053] FIG. 3 is a logic flow diagram illustrating an exemplary process 300 for creating an asset for on-demand viewing from a broadcast stream. Step 310 is the first step in the exemplary process 300. In Step 310, an asset provider 10 identifies a portion (or “segment”) of a broadcast stream to be extracted and prepared for on-demand viewing. In one exemplary embodiment, the asset provider 10 uses the authoring application 220 to author stream metadata, which identifies the segment to be extracted from the broadcast stream, an asset identifier to be associated with the segment, and a transport stream identifier. In another exemplary embodiment, the asset provider 10 identifies a segment of a broadcast stream to be extracted by the distribution endpoint by inserting segment-identifying tags into the broadcast stream. In Step 320, a distribution endpoint extracts the segment identified by the asset provider 10 and prepares the segment for on-demand viewing.

[0054] In Step 330, the asset provider 10 authors and distributes segment package metadata to be associated with the extracted on-demand asset. Specifically, the asset provider 10 uses the authoring application 220 to author segment package metadata that describes the attributes of the extracted segment and that specifies the lifecycle information for the segment.

[0055] In Step 340, the distribution endpoint determines whether it has received the segment package metadata authored by the asset provider 10 for the extracted segment. If the distribution endpoint has received the segment package metadata, then in Step 350, the distribution endpoint associates the segment package metadata with the on-demand asset using the asset identifier.

[0056] In Step 360, the distribution endpoint creates an on-demand segment package comprising the segment package metadata, the segment, and the asset identifier that identifies the segment. In Step 370, the distribution endpoint makes the segment available to cable subscribers for on-demand viewing by exporting the on-demand segment package to an on-demand video server.

[0057] FIG. 4 is a logic flow diagram illustrating an exemplary sub-process 310a of FIG. 3 for identifying a segment of a broadcast stream to be extracted for on-demand viewing. Step 410 is the first step in the exemplary process 310a. In Step 410, the asset provider 10 transmits a linear broadcast of assets to one or more distribution endpoints. In Step 420, a live spool 230 located at the asset provider 10 records the broadcast stream and associates the recorded broadcast stream with a reference mark or “synch mark.” In one exemplary embodiment, the reference mark comprises time codes. The time codes can comprise standard time codes or any other industry-standard mechanisms for authoring time codes.

[0058] In Step 430, the authoring application 220 identifies a segment of the broadcast stream to be formatted for on-demand viewing. Specifically, using the recorded broadcast stream and time codes recorded in the live spool 230, the authoring application 220 authors stream metadata that defines a start time code identifying the start of the segment, a stop time code identifying the end of a segment, the length of the segment to be extracted, an asset identifier to be associated with the extracted segment that uniquely identifies the segment, and a transport stream identifier.

[0059] In Step 440, the authoring application 220 sends a command to the segment processor 240 to extract the segment from the broadcast stream. The command comprises the stream metadata identifying the segment to be extracted. In Step 450, the authoring application 220 stores the stream metadata.

[0060] FIG. 5 is a logic flow diagram illustrating an exemplary sub-process 320a of FIG. 3 for extracting a segment from a broadcast stream and preparing the segment for on-demand viewing. Step 510 is the first step in the exemplary sub-process 320a. In Step 510, the live spool 250 located at the distribution endpoint records the broadcast stream. In Step 520, the distribution endpoint determines whether it has received a command from the asset provider 10 to extract a segment of the broadcast stream for on-demand viewing.

[0061] In Step 530, if the distribution endpoint has received such a command, then the segment processor 240 retrieves the broadcast segment from the live spool 250 using the stream metadata. Specifically, the segment processor 240 retrieves the segment from the live spool 250 using the start time code, the stop time code, the duration of the segment, and the transport stream identifier.

[0062] In Step 540, the segment processor 240 associates the retrieved segment with the asset identifier received from the asset provider 10 in the stream metadata. In Step 550, the segment processor 240 formats the retrieved segment as an on-demand asset for on-demand viewing.

[0063] FIG. 6 is a logic flow diagram illustrating an exemplary sub-process 320b of FIG. 3 for extracting a segment from a broadcast stream when the pre-authored stream metadata is received from the asset provider 10 before the segment is broadcast. Step 520 is the first step in the exemplary sub-process 320b. In Step 520, the distribution endpoint determines whether it has received a command from the asset provider 10 to extract a segment of the broadcast stream for on-demand viewing. In Step 610, if the distribution endpoint has received such a command, then the segment processor 240 captures the segment from the broadcast stream using the stream metadata (without first recording the broadcast stream in a live spool 250). Specifically, the segment processor 240 retrieves the segment from the broadcast stream using the start time code, the stop time code, the duration of the segment, and the transport stream identifier.

[0064] In Step 540, the segment processor 240 associates the retrieved segment with the asset identifier received from the asset provider 10 in the stream metadata. In Step 550, the segment processor 240 formats the retrieved segment as an on-demand asset for on-demand viewing.

[0065] FIG. 7 is a logic flow diagram illustrating an exemplary sub-process 310b of FIG. 3 for identifying a segment of a broadcast stream to be extracted for on-demand viewing by inserting tags into the broadcast stream. Step 710 is the first step in the exemplary process 310b. In Step 710, the asset provider 10 identifies a segment of a broadcast stream to be extracted by a distribution endpoint by inserting tags into the broadcast stream. More specifically, the multiplexor and scheduling processor 280 inserts a start tag identifying the start of the segment and an end tag identifying the end of the segment to be extracted at the distribution endpoint. In one exemplary embodiment, tags are inserted into the broadcast stream using the DVS 253 specification, as is understood by those skilled in the art. In Step 410, the asset provider 10 broadcasts the broadcast stream comprising the inserted tags to the receiver 20 via satellite 25.

[0066] FIG. 8 is a logic flow diagram illustrating an exemplary sub-process 320c of FIG. 3 for extracting a segment of a broadcast stream identified by one or more tags and for preparing the segment for on-demand viewing. Step 810 is the first step in the exemplary sub-process 320c.

[0067] In Step 810, the distribution endpoint receives the linear broadcast stream from the asset provider 10 via satellite 25. In Step 820, the distribution endpoint determines whether it sees a tag in the broadcast stream. If the distribution endpoint sees a tag in the broadcast stream, then in Step 830, the live spool 250 records the segment of the linear broadcast stream identified by the tags In Step 840, upon recording the tagged segment in the live spool 250, the segment processor 240 retrieves the recorded segment from the live spool 250. In Step 540, the segment processor 240 associates the segment retrieved from the live spool 250 with the asset identifier received from the asset provider 10 in the stream metadata. In Step 550, the segment processor 240 formats the retrieved segment as an on-demand asset for on-demand viewing.

[0068] FIG. 9 is a logic flow diagram illustrating an exemplary sub-process 320d of FIG. 3 for extracting a segment of a broadcast stream identified by one or more tags and for preparing the segment for on-demand viewing. Step 810 is the first step in the exemplary sub-process 320d.

[0069] In Step 810, the distribution endpoint receives the linear broadcast stream from the asset provider 10 via satellite 25. In Step 820, the distribution endpoint determines whether it sees a tag in the broadcast stream. If the distribution endpoint sees a tag in the broadcast stream, then in Step 910, the segment processor 240 captures the segment identified by the tags directly from the broadcast stream. By capturing the identified segment directly from the broadcast stream, the use of a live spool at the distribution endpoint 250 to record the broadcast stream can be avoided. In Step 540, the segment processor 240 associates the segment captured from the broadcast stream with the asset identifier received from the asset provider 10 in the stream metadata. In Step 550, the segment processor 240 formats the retrieved segment as an on-demand asset for on-demand viewing.

[0070] Those skilled in the art will appreciate that the exemplary system 200 allows an asset provider 10 to offer assets for on-demand applications without requiring the asset provider 10 to pre-package the assets in an on-demand application format or to distribute the on-demand asset separately to one or more distribution endpoints. For example, the asset provider 10 can identify a segment of a broadcast stream to be extracted by the distribution endpoint for on-demand applications by specifying a start time code and a stop time code of the segment to be extracted. Additionally, the asset provider 10 can insert tags into the broadcast stream, which identify the segment to be extracted at the distribution endpoint. Moreover, those skilled in the art will also recognize that the exemplary system 200 allows an asset provider 10 or distribution endpoint to designate an asset for on-demand viewing independent of when an electronic program guide indicates the asset will be aired. Finally, those skilled in the art will recognize that the exemplary system 200 allows the asset provider 10 or distribution endpoint to maintain control over the extracted segments that are made available for on-demand viewing by maintaining the segment packages on segment library VOD servers 260 at the distribution endpoint or throughout the on-demand system 200.

[0071] It should be understood that the foregoing relates only to illustrative embodiments of the present invention, and that numerous changes may be made therein without departing from the scope and spirit of the invention as defined by the following claims.

Claims

1. A system for capturing a segment of a broadcast stream, comprising: an asset provider, operative to identify the segment of the broadcast stream to be captured and to issue a command to capture the segment; and a distribution endpoint, coupled to the asset provider via a communication medium, operative to capture the segment of the broadcast stream upon receiving the command.

2. The system of claim 1, wherein the command comprises a start time to indicate the start of the segment to be captured and a stop time to indicate the end of the segment to be captured.

3. The system of claim 2, wherein the distribution endpoint comprises a segment processor, operative to capture the segment of the broadcast stream using the start time and the stop time.

4. The system of claim 1, wherein the asset provider comprises an authoring application, operative to insert tags into the broadcast stream to identify the segment of the broadcast stream to be captured.

5. The system of claim 4, wherein the segment processor is further operative to capture the segment of the broadcast stream identified by the inserted tags.

6. The system of claim 1, further comprising a live spool, operative to record and store the broadcast stream.

7. The system of claim 6, wherein the live spool is further operative to record the segment of the broadcast stream identified by the inserted tags.

8. A system for capturing a segment of a broadcast stream, comprising: a live spool, operative to record the broadcast stream; and a distribution endpoint, functionally coupled to the live spool, operative to capture the segment of the broadcast stream from the live spool.

9. The system of claim 8, wherein the distribution endpoint comprises a segment processor, operative to capture the segment from the live spool using a start time and a stop time identifying the segment to be captured.

10. The system of claim 8, wherein the segment to be captured is identified by at least one tag in the broadcast stream.

11. The system of claim 10, wherein the live spool is further operative to record the segment of the broadcast stream identified by the at least one tag.

12. A system for identifying a segment of a broadcast stream to be captured, comprising an authoring application, operative to identify the segment of the broadcast stream by using a start time identifying the start of the segment and a stop time identifying the end of the segment and by inserting at least one tag identifying the segment into the broadcast stream.

13. The system of claim 12, further comprising a live spool, coupled to the authoring application, operative to record the broadcast stream.

14. A method for retrieving a segment of a broadcast stream, comprising the steps of: identifying the segment of the broadcast stream to be retrieved using a start time and a stop time, wherein the start time identifies the start of the segment and the stop time identifies the end of a segment; issuing a command to capture the segment, wherein the command comprises the start time and the stop time; recording the broadcast stream on a live spool; and retrieving the segment from the live spool using the start time and the stop time, in response to receiving the command to retrieve the segment.

15. The method of claim 14, wherein the command further comprises an asset identifier to be associated with the retrieved segment.

16. The method of claim 15, further comprising the step of associating the asset identifier with the retrieved segment.

17. The method of claim 15, further comprising the steps of: receiving metadata describing the retrieved segment; and associating the metadata with the retrieved segment using the asset identifier.

18. A method for capturing a segment of a broadcast stream, comprising the steps of: receiving the broadcast stream comprising at least one tag identifying the segment to be captured; recording the segment identified by the tag at a live spool; and retrieving the identified segment from the live spool for distribution of the segment via a communication medium to at least one storage device.

19. The method of claim 18, further comprising the step of associating the retrieved segment with an asset identifier.

20. The method of claim 19, further comprising the steps of: receiving metadata describing the retrieved segment; and associating the metadata with the retrieved segment using the asset identifier.

21. A method for formatting a segment of a broadcast stream for on-demand viewing, comprising the steps of: recording the broadcast stream on a live spool; retrieving the segment from the live spool using stream metadata identifying the segment; and formatting the segment for on-demand viewing.

22. The method of claim 21, wherein the stream metadata comprises a start time identifying the start of the segment, a stop time identifying the end of the segment, and an asset identifier for identifying the retrieved segment.

23. The method of claim 21, wherein the stream metadata comprises a length of the segment.

24. The method of claim 22, further comprising the step of associating the retrieved segment with the asset identifier.

25. The method of claim 22, further comprising the steps of: receiving package metadata describing the retrieved segment; and associating the package metadata with the retrieved segment using the asset identifier.

26. A method for capturing a segment of a broadcast stream for on-demand viewing, comprising the steps of: extracting the segment from the broadcast stream, wherein the segment to be extracted is identified by at least one tag; and storing the segment and package metadata describing the segment in a storage device upon receiving the package metadata via a communication medium.

27. The method of claim 26, wherein the package metadata comprises a description of the segment.

28. The method of claim 26, wherein the package metadata comprises lifecycle information identifying a length of time the segment is to be stored in the storage device.

29. A method for extracting a segment from a broadcast stream for on-demand viewing, comprising the steps of: receiving stream metadata identifying the segment to be extracted from the broadcast stream; and extracting the identified segment from the broadcast stream.

30. The method of claim 29, wherein the stream metadata comprises a start time identifying the start of the segment and a stop time identifying the end of the segment.

31. The method of claim 29, wherein the stream metadata comprises a transport stream identifier identifying the transport stream from which to extract the segment.

32. The method of claim 29, wherein the stream metadata comprises an asset identifier for identifying the segment.

33. The method of claim 32, further comprising the step of associating the segment with the asset identifier.

34. The method of claim 32, further comprising the steps of: receiving package metadata describing the segment; and associating the package metadata with the segment using the asset identifier.

35. A method for identifying a segment to be extracted from a broadcast stream, comprising the step of issuing a command to extract the segment from the broadcast stream, wherein the command comprises stream metadata.

36. The method of claim 35, wherein the stream metadata comprises a start time identifying the start of the segment to be extracted and a stop time identifying the end of the segment to be extracted.

37. The method of claim 35, wherein the stream metadata further comprises an asset identifier to be associated with the segment.

38. The method of claim 35, wherein the stream metadata further comprises a transport stream identifier identifying the broadcast stream from which to extract the segment.

39. A method for identifying a segment to be extracted from a broadcast stream, comprising the steps of: inserting at least one tag into the broadcast stream identifying the segment to be extracted; and issuing segment package metadata describing the extracted segment for use in an on-demand application.