WO2000060482A9

WO2000060482A9 - A program scheduler for an interactive information distribution system

Info

Publication number: WO2000060482A9
Application number: PCT/US2000/008349
Authority: WO
Inventors: Christopher W B Goode; Rocca Tobie J La
Original assignee: Diva Systems Corp
Priority date: 1999-04-01
Filing date: 2000-03-30
Publication date: 2002-04-04
Also published as: GB2364151A; AU3929300A; GB0123373D0; WO2000060482A1; GB2364151B; CA2368820A1

Abstract

An apparatus and method for distributing video assets in an interactive information distribution system (100) comprising a program scheduler (150) for identifying video assets for distribution, and a plurality of servers (108) coupled to the program scheduler (150) for receiving and storing the identified video assets. A plurality of programmers retrieve titles of the video assets stored in a title database (310) via a plurality of programmer interface front-end modules (302). Upon completion of defining the title-plans, the title-plans are stored in a title-plan database (314) via a back-end module (304). The back-end module (304) is coupled to the plurality of programmer interface front-end modules (302) and the title-plan database. Additionally, a content distribution planner (306) is coupled to the back-end module (304), via the title-plan database (314), and coupled to the plurality of servers (108) for selectively and timely distributing the video assets to the plurality of servers.

Description

A PROGRAM SCHEDULER FOR AN INTERACTIVE INFORMATION

DISTRIBUTION SYSTEM

CROSS REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Application No. 60/127,333, filed April 01, 1999, which is hereby incorporated by reference in its entirety.

BACKGROUND OF THE INVENTION 1. Field of Invention

The present invention relates to an interactive information distribution system such as a video-on-demand (VOD) system. More particularly, the present invention relates to a method and apparatus for providing an interactive scheduling system for use within an interactive information distribution system.

2. Description of the Background Art

Most information distribution systems established by a service provider utilize a plurality of head-ends. Each head end serves as a distribution point for transmitting a plurality of video assets to a plurality of subscribers corresponding to each head-end.

Requesting video information (video assets), such as a movie, is initiated by reviewing and selecting a title from a graphical menu displayed upon a subscriber's monitor. The graphical menus contain titles, schedules, and other information regarding video content available from the service provider. Using a remote control device, a subscriber selects a desired video title for viewing. The subscriber may choose from thousands of video titles. A current process used by programmers m an interactive information distribution system is to define the same programming for every server within the interactive video distribution system. Specifically, broadcast channels schedule their own content typically at a centralized source and distribute their content via satellite links to different head-ends. Scheduling for the broadcast world centers around play to air time Schedules are created for each day of the week and each hour of the day. Commercial time is also scheduled. Furthermore, Pay per View (PPV), and m particular near video on demand (NVOD) scheduling is also based on play to air time, i.e., what time will the video title be played.

The local servers at each head-end distribute the video assets to their respective subscribers at the scheduled time upon a subscriber request. The video assets are either stored individually at the head-ends, or are stored at a centralized location and are passed through the head-ends to the subscribers. Disbursement of video assets is the same from one head-end to another. Therefore, whether the viewers are m San Francisco, California, or Montgomery, Alabama, all of the subscribers receive the same scheduled play to air video information regardless of the head-end location. For Video- On-Demand, a program scheduler is not based on play to air time, but rather they must be available "on-demand". Therefore, there is a need for a program scheduler that does not depend upon specific times of the day as the broadcast and NVOD formats. There is also a need for a scheduler to manage video server storage space amongst various service providers and categories of service providers.

Moreover, as demographics vary between markets, such restrictive programming may result m a loss of viewership amongst the various subscribers. Accordingly, there is a need for a programming system that will permit a service provider to deliver customized program scheduling for video assets seamlessly, based upon demographics and other marketing considerations m the industry.

SUMMARY OF THE INVENTION The disadvantages discussed herein are overcome by the present apparatus and method for scheduling and distributing video assets to subscribers m an interactive information distribution system. The apparatus and method for distributing video assets m an interactive information distribution system comprises a program scheduler for identifying video assets for distribution, and a plurality of servers coupled to the program scheduler for receiving and storing the identified video assets.

Specifically, a plurality of programmers retrieve titles of the video assets stored m a title database to define title-plans for each video asset via a plurality of programmer interface front-ends modules. Upon completion of defining the title-plans, the title-plans are stored m a title-plan database via a back-end module. The back-end module is coupled to the plurality of programmer interface front-end modules and the title-plan database. Additionally, a content distribution planner is coupled to the back-end, via the title-plan database, and coupled to the plurality of servers for selectively and timely distributing the video assets to the plurality of servers. Thus, the distribution of the video assets to the subscribers corresponds with the servers pertaining to particular head-ends selected by the programmers m the title-plans. Accordingly, the program scheduler will allow a plurality of programmers to provide flexible and customized programming to various servers located in various market segments . This decentralized programming process benefits the subscribers by meeting their diversified demands.

BRIEF DESCRIPTION OF DRAWINGS The teachings of the present invention may be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which: FIG. 1 depicts a block diagram of an interactive information distribution system;

FIG. 2 depicts a detailed block diagram of the program scheduler corresponding to one of a plurality of head-ends in the interactive information distribution system;

FIG. 3 depicts a block diagram of a program scheduler, as well as the components of the content distribution center and the stream server that the scheduler interacts with; FIG. 4 depicts a method of operation of a program scheduler;

FIG. 5 depicts a graphical representation of the functional aspects of the program scheduler;

FIG. 6 depicts a graphical representation of the server administrative functionality of the program scheduler; FIG. 7 depicts a method of defining title-plans via the program scheduler;

FIG. 8 illustratively depicts a title-plan interface on a programmer's display;

FIG. 9 depicts a process for reviewing and storing newly defined, modified, or deleted title-plans;

FIG. 10 illustratively depicts a package-plan interface on a programmer's display; FIG. 11 illustratively depicts a video-sequence interface on a programmer's display; and

FIG. 12 illustratively depicts a list interface on a programmer's display. To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures.

DETAILED DESCRIPTION OF THE INVENTION The invention is a method and apparatus for providing a program scheduler capable of creating and implementing program schedules, i.e., "title-plans", "package-plans", "video-sequences", and "lists" for each of the plurality of video asset of a service provider. Each program schedule allows a programmer to selectively allocate a video asset to one or more head-ends based upon subscriber demographics, promotional criteria, and/or service provider agreements.

FIG. 1 depicts a block diagram of an interactive information distribution system 100. Specifically, the interactive information distribution system 100 comprises a content distribution center 101 and a plurality of program schedulers that are coupled to a plurality of neighborhoods 103_x through 103_n (collectively neighborhoods 103), via an inter-server network 105. Each neighborhood 103 comprises a plurality of head-ends 102_x through 102_m (collectively head- ends 102) coupled to a plurality of subscriber equipment 106_x through 106_n (collectively subscriber equipment 106) via an access network 104.

Furthermore, video assets may be transferred from either one head-end to another head-end (e.g., head-end 1 102₁ to head-end 2 102₂) or from the content distribution center 101 to one or more head-ends 102. The content distribution cen er 101 allocates such video asset ("title") transfers through the plurality of program schedulers 150, via the inter-server network 105. The program schedulers 150 may be remotely located from the content distribution center 101 and head-ends 102, and are used to facilitate scheduling of the video assets for each of the head-ends 102. In this manner, each head-end may timely receive video assets for distribution to subscribers based upon geographic and marketing considerations corresponding to the local demographics of the subscribers.

An interactive information distribution system for which the inventive program scheduler is intended to operate is disclosed in detail in United States patent application 08/984,710 filed December 3, 1997 and incorporated herein by reference. However, this specific hardware arrangement is considered illustrative of the type of system with which the invention is used. Any other hardware arrangement that facilitates information distribution through a plurality of stream servers is considered within the scope of the invention.

Specifically, FIG. 2 depicts a detailed block diagram of a portion of a neighborhood 103. The neighborhood 103 comprises a service provider head-end 102, a communications network 104 and a plurality of subscriber equipment 106_! through 106_n, (collectively, subscriber equipment 106) .

The head-end 102 contains a stream server 108 that is typically a parallel processing computer containing at least one central processing unit 110 and associated memory 112. The server interacts with a data storage device 114 (e.g., a disk drive array) that generally stores the video assets

(e.g., movies) that will be recalled and downloaded to the subscriber . Furthermore, within the service provider equipment is a stream session manager 122 that provides session control of the information flowing to and from the server 108. Furthermore, the stream session manager 122 comprises a central processing unit 124 and associated memory 126.

The stream server 108 is coupled to the stream session manager via data path 116, synchronization clock path 118 and control path 120. The server 108 provides data streams on path 116 and a synchronization clock on path 118 in response to requests for information from the stream session manager on path 120. These data streams are packetized and modulated onto a carrier that is compatible with the transmission requirements of the network 104.

The stream session manager 122 accomplishes all of the transmission interface requirements for the neighborhood 103. Specifically, the stream session manager 122 is coupled to subscriber equipment via a forward information channel 132, a forward command channel 133 and a back channel 134. The cable transport network supports all three of these channels. The stream session manager 122 contains a modulator (not shown) for modulating the server data streams onto one or more carrier frequencies for transmission on the forward information channel 132. Additionally, the stream session manager 122 contains a modem (not shown) for sending control information via the forward command channel 133 and receiving control information via the back channel 134. Moreover, a conventional cable television signal source 128 is optionally coupled to the forward information channel 132 via a signal coupler 130. The network 104 may be any one of a number of conventional broadband communications networks that are available such as a fiber optic network, a telephone network, existing cable television network and the like. For example, if the network 104 is a hybrid fiber-coax network, the transmission transport technique used in both forward channels may be modeled after the Moving Pictures Expert Group (MPEG) transport protocol for the transmission of video data streams .

In general, the transport mechanism for both of the forward channels that transport information to the set top terminal 136 must be able to carry unidirectional, asynchronous packetized data such as that defined in the MPEG video and audio signal transmission protocol, and the like. There are a number of such transport protocols available.

Each set top terminal 106 receives the data streams from the forward information channel 132, demodulates those streams and processes them for display on the display device 140 (e.g., a conventional television) . In addition, the set top terminal 136 accepts commands from a remote control input device 138 or other input device. These commands are formatted, compressed, modulated, and transmitted through the network 204 to the stream session manager 122.

Typically, this transmission is accomplished through the back channel 134. These commands are preferably transmitted through the same network 104 used to transmit information to the set top terminal 136. However, the back channel 134 coupling the set top terminal 136 to the stream server 108 may be a separate network, e.g., a forward information channel through a television cable network and a back channel through a telephone network.

The telephone network could also support the forward control channel 133. The stream session manager 122 interprets each command sent from the set top terminal 136 through the back channel 134 and instructs the stream server 108 to perform certain functions to implement the subscriber request .

A program scheduler 150 is generally located at a remote location and connected to each head-end 102 to facilitate programming of the stream servers 108 with program schedules. The program scheduler 150 generates lists of various programs that are available for scheduling.. From such listings, a programmer may interactively select various titles to be loaded onto the stream servers 108, as well as how the titles are presented to the subscriber. The programmer defines the subscriber presentations using title-plans, package-plans, video-sequences, and lists, which are discussed in further detail below.

FIG. 3 depicts a detailed block diagram of a program scheduler 150, as well as the components of the content distribution center 101 and the stream server 108 that the scheduler interacts with. The program scheduler 150 is utilized for timely distribution of video assets to a plurality of neighborhoods having a plurality of servers 108 at a plurality of head-ends 102. Specifically, the program scheduler 150 is coupled to a content distribution center 101 for retrieving, storing, and distributing video assets to a plurality of servers 108 as defined in the title-plans by one or more programmers. The program scheduler 150 comprises a plurality of programmer interface front-end modules 302 coupled to a back-end module 304, and a content distribution planner 306 for determining when to physically send the titles out to the server. Such determination is based upon when a video asset is needed, how much content is scheduled for loading, and how early the content is to be delivered to the plurality of servers 108. Each programmer front-end module 302 communicates with the back-end module 304, and a title database 310 at the content distribution center 101 via a title and rights manager 312. Furthermore, the content distribution planner 306 is coupled to the back-end module 304, via a title-plan database 314 also in the content distribution center.

Additionally, the content distribution center 101 comprises an asset manager 322, a work-order manager 320, and a content delivery manager 324, each coupled to the content distribution planner 306 to track the video assets at the content distribution center 101, create work-orders for missing components of the video assets, and deliver the video assets, respectfully. The content distribution planner 306 is also coupled to a plurality of content managers 330 located at each server 108 of each head-end 102 in the interactive information distribution system 100.

The programmer interface front-end modules 302 are typically graphical user interface (GUI) client applications that may be run from any desktop implementing an operating system such as a "MICROSOFT WINDOWS 95/ 98 /NT®" operating system. As such, the program scheduler 150 is capable of being accessed by multiple programmers to define, modify, or delete title-plans through each of the programmer interface front-ends 302. For purposes herein, a title-plan is defined as a time period in which a video asset (title) is programmed to be stored on a stream server 108 at a head-end 102, and thereby made available to a subscriber. In the event multiple programmers are simultaneously using the same functionality of the program scheduler 150, then the program scheduler 150 initiates a data locking mechanism. The back-end module 304 is a centralized module within the content distribution center 101 that communicates between the plurality of programmer interface front-end modules 302 and the title-plan database 314 The back-end module 304 stores all of the title-plans m the title-plan database 314 that have been created by the various programmers at each front-end module 302. Additionally, the back-end module 304 performs data checking for various server constraints such as storage availability, number of titles, categories, and the like.

During program scheduling, a programmer accesses one of the programmer interface front-end modules 302 and requests a list of titles via a filtering tool (not shown) . The filtering tool is utilized by a programmer to limit the titles a programmer selects and sees m order to improve system performance and ease title selection. The list of titles are provided from the title database 310 via the title and rights manager 312. The programmer discloses appropriate programmer information to satisfy various criteria of the title and rights manager 312, and thereafter the title information is retrieved from the title database 310.

Once the title is retrieved from the title database 310, the programmer may define a title-plan by adding various attributes to the title-plan. These attributes may include a modified title name, date range for title availability, server and/or server groups that will store the video assets corresponding to the title, as well as other attributes. The title-plans are then stored by the programmer m the title- plan database 314 via the back-end module 302. The stored title-plans m the title-plan database 310 are then available throughout the program scheduler 150 for retrieval by any other programmer, as required. The content distribution planner 306 functions to distribute the video assets. The video assets may be distributed to one or more servers 108 at one or more head- ends 102, respectively. Additionally, the content distribution planner 306 is linked to each server 108 via a content manager 330 at each respective head-end 102.

Specifically, the content distribution planner 306 determines when to distribute video assets to a particular server 108. Some video assets may not be stored at each server 108 of each head-end 102. Typically, only the most popular video assets are stored locally at each head-end 102. The content distribution planner 306 permits the interactive information distribution system 100 to store the video assets at the content distribution center 101 or at other head-ends 102, and deliver a requested video asset to a server 108, as required. In this manner, video assets at each server 108 may be controlled, and also avoid wasting storage space by storing only popular video assets at the servers 108.

In order to determine when one or more of the video assets are to be distributed to a particular server 108, m one embodiment, the content distribution planner 306 queries the content manager 330 of each stream server 108 at each head-end 102 via signal path 331. The content manager 330 of each server 108 then provides the content distribution planner 306 with an inventory of those video assets currently stored at the each head-end 102. Alternately, m a preferred embodiment, the content manager 330 proactively sends control messages to the back-end module 304 whenever any content changes state on a video server 108. Thereafter, m either embodiment, the inventoried video assets are then compiled and stored m the title-plan database 314. In this manner, the program scheduler 150 is periodically updated with regard to the video assets are currently stored at each server 108, and which video assets will subsequently require delivery from the content distribution center 101 to a particular head-end 102. Furthermore, the content distribution planner 306 polls the title-plans on a periodic basis from the title-plan database 314 in accordance with a title-plan retrieval frequency. Polling is performed periodically by the program scheduler 150 to maintain current accounting of any new, modified or deleted title-plans recently imputed by the programmers .

The content distribution planner 306 then communicates with the asset manager 322 to monitor the status of the video assets stored at the content distribution center 101. Such status includes the various components of each video asset, such as the title, associated movie information screens (MIS), previews, normal, fast-forward and reverse tracks, and the like.

After interacting with the asset manager 322, the content distribution planner 306 communicates the with the work-order manager 320. The work-order manager 320 prepares work-orders for video assets that have been scheduled. A work-order includes preparation of the MIS, previews, encoding of the title, normal, fast-forward and reverse tracks, and the like. In an instance where the work-order manager 320 notifies the content distribution planner 306 that the scheduled video assets are not ready for distribution, a work-order is created and fulfilled by the work-order manager 320. Each time the content distribution planner has polled the title-plan database 314, the content distribution planner 306 then sends a list of video assets to the content delivery manager 324 to schedule delivery of the title-plans and video assets to the appropriate video servers 108 defined by the title-plans. In particular, the content delivery manager 324 manages the link and bandwidth between the content distribution center 101 and each head-end 102. The scheduled title-plans and list are then delivered to a remote-end of a content distribution manager (not shown) coupled to each stream server 108. The content managers 330 of the individual servers 108 are notified by the remote-ends that the streamed video assets have been received, and the content manager 330 signals the video server 108 to load the video assets. Furthermore, the scheduled title-plans and lists are delivered to the content managers 330 of the individual servers 108 defined m the title-plans ahead of the video assets via signal path 333. In this manner, the content manager 330 is provided adequate time to ensure that there is space for the video assets, as well as notice as to the incoming content .

Thereafter, the video assets are delivered from the storage devices at the content distribution center 101, or from a server 108 at another head-end 102, to the server or server groups m accordance with the title-plan definitions. The interaction between the program scheduler 150 and its various application modules, and the servers at one or more head-ends is illustratively depicted by the method of FIG. 4. FIG. 4 depicts a method of operation of the program scheduler. The method 400 starts m step 401 and proceeds to step 402 where a programmer defines a new or modified title- plan for distribution of a video asset to a server or group of servers. In step 404, the back-end module stores the new or modified title-plan m the title-plan database. The method 400 then proceeds to step 406. In step 406, the content distribution planner periodically queries the title database for updated content changes provided by the content manager. In a preferred embodiment, the content manager sends a status message to the scheduler each time the content changes state. The information containing the content changes at each stream server is then stored in the title database. Thus, the content distribution planner periodically accesses the title database to determine what video assets are currently loaded at each of the plurality of servers. Alternately, in another embodiment, the content distribution planner periodically communicates with a content manager at each of the plurality of servers to determine what video assets are currently loaded at each of the servers . The data regarding what video assets are currently loaded in each of the servers is stored in a title-plan database. By either process the content distribution planner is always ensured of having the latest information regarding the video assets stored at each server. In step 408, on a periodic basis the content distribution planner polls the title-plan database for new and modified title-plans. The polling by the content distribution planner is performed as per a title-plan- retrieval-frequency. The title-plan-retrieval-frequency is defined by a system administrator, and establishes the days of the week and times within a day when the content distribution planner retrieves the new, modified, or deleted title-plans from the title-plan database. Typically, the title-plan-retrieval-frequency occurs numerous times daily. The method 400 then proceeds to step 410 where a query is made whenever the content distribution planner polls the title-plan database for new or modified title-plans. Specifically, in step 410, the content distribution planner communicates with an asset manager to track the availability of the video assets defined in the title-plans. The asset manager monitors the status of video assets including whether there are work-orders for each scheduled video asset. If, in step 410, the content distribution planner determines that there are scheduled video assets that are not yet available, then the method proceeds to step 412 where the content distribution planner communicates with a work-order manager to create a work-order to acquire the necessary video asset or assets. The system administrator defines the maximum number of days within which a work-order for video content should be completed.

In the event any work-orders are not completed within a specified maximum number of days, the content distribution planner will generate a report. The report is used to insure that either the pending work-order is completed or the title- plans are modified to reflect the lack of titles that would otherwise be available under the incomplete work order. Additionally, the content distribution planner polls the title-plan database to determine if there are deleted title- plans. In an instance where all title-plans corresponding to a title have been deleted, and if a work-order was earlier requested for that title, then the content distribution planner notifies the work-order manager of such deletion. Once the work-order by the work-order manager is completed, the method proceeds to step 414.

If, however, in step 410, the content distribution planner has contacted and confirmed from the asset manager that the video assets are available (i.e., the work-orders are complete) , then the method 400 proceeds to step 414. In step 414, the content distribution planner creates a list of video assets that are to be delivered to the servers and sends the list to a content delivery manager.

The content distribution planner will generate a report if any of the video assets to be distributed are not currently available for transfer. The list is forwarded to the content delivery manager in accordance with an administrator-defined frequency called a content-delivery- frequency. The content-delivery-frequency is defined as days of a week and times within a day, when the content distribution planner will provide the list of video assets to the content delivery manager.

The method 400 then proceeds to step 416. In step 416, the title-plans on the list are delivered to those servers designated in the title-plans. Specifically, and in accordance with the title-plan-retrieval-frequency, the content distribution planner sends the new and modified title-plans (as well as any programmer defined rules for title lists, and/or promotional packages) to the content manager for video assets that have been scheduled for the current day plus a title-plan-delivery-lead-period. A title- plan-delivery-lead-period is defined as number of days ahead of the actual start-date of a title-plan when the content distribution planner shall send the title-plan to the content manager . For a modified title-plan, if the content distribution planner has already sent the title-plan information to the content manager (i.e., the current date + title-plan- delivery-lead-period is greater than the start-date of the modified title-plan) , then the content distribution planner sends the modifications to the content manager. If the modified title-plan has not been sent earlier (i.e., the current date + title-plan-delivery-lead-period is less than the start-date of the modified title-plan) , then the content distribution planner treats this as in the case of a new title-plan .

Thus, every day, the content distribution planner sends changed title-plan information to the content manager for all days from the current date to the current date + title-plan- delivery-lead-period. The method 400 then proceeds to step 418. In step 418, the content distribution planner also calculates (based on an internal algorithm) the time ahead of the actual start-date, when the video assets themselves should be sent to each content manager at the plurality of servers .

Delivery of the video assets is based on the speed of the transport media and various other attributes . At the appropriate time in step 418, the content distribution planner instructs the content delivery manager to start the video asset transfer. After the stream server 108 successfully receives the content, the content manager sends an acknowledgement to the content distribution planner and the delivery process completes at that time. The method 400 then proceeds to step 420 where the method 400 ends.

Various circumstances are possible during the method 400. For instance, if a video asset has been scheduled but information (i.e., attributes) about the video asset changes in the title database 314, the content distribution planner 306 will retrieve the changed title-plan attributes for all titles that have title-plans for any days in the next title- plan-delivery-lead-period. Once the content distribution planner 306 detects that any title attribute has changed, then the content distribution planner 306 sends the new title attribute to the respective content manager 330. In another instance, programmers may define a new title- plan, modify a title-plan or delete a title-plan whose start- date is between current date and current date + title-plan- delivery-lead-period. Normally every day, the content distribution planner 306 sends title-plans, promotional packages, and rules for title-plan lists to the content manager for the day that is the title-plan-delivery-lead- period after the current date. Thus the content manager 330 always has the title-plans, package definitions and rules for lists for all days starting from the current date to the current date + title-plan-delivery-lead-period.

However, if the content distribution planner 306 detects that a new title-plan has been added, modified, or deleted, and where the start-date falls within the current date + title-plan-delivery-lead-period, then the content distribution planner 306 sends the changed title-plans to the content manager 330. This ensures that the content manager 330 always has the latest title-plans, packages, and rules for lists for the next title-plan-delivery-lead-period days. Additionally, if the remote-end detects that the content delivery manager 324 fails, e.g., due to corruption or a data link failure, the content distribution manager (not shown) coupled to the stream server 108 sends a signal to the content delivery manager 324 notifying it of the corruption. The content delivery manager 324 then initiates a re-send of the information (i.e., title-plans or video assets) to the remote stream server 108. This process will continue, until a successful acknowledgement is sent to the content delivery manager 324. If the content delivery manager 324 is unsuccessful in delivering the information after the maximum number of retries, the content distribution planner 306 generates a report . The number of retries that the content delivery manager 324 makes to deliver content is based upon a maximum defined by a system administrator.

FIG. 5 depicts a graphical representation of the functional aspects of the program scheduler 150. The program planner 150 allows various programmers to perform administrative functions 510, define title-plans 520, define package-plans 530, define video-sequences 540, define lists 550, as well as implement the content distribution planner functions 560.

In particular, the administrative functionality 510 may be segmented into two groupings, i.e., a video server function 512 and an administrator function 514. The administrative function 510 addresses various matters regarding system resources, programmer access rights, programming guidelines, and the like. The title-plan functionality 520 is used to define title-plans for the servers 108. A title-plan is defined as the time period in which a video asset is scheduled to be available m a server for selection by a subscriber. A title-plan is a unique combination of title ID, availability start-date, availability end-date, video server and/or video server group, on which the asset is stored and available in daily time slots. The package-plan functionality 530 is used to define packages, which are groups of titles that are eligible for pricing discounts . Multiple types of packages may be created. In particular, a subscription package is a package of titles that is included along with a monthly subscription. This monthly fee entitles the programmer to a certain type of discount. The discount includes the titles that are part of the package at the time of purchase. A second type of package is where a title is given a one-time discount. Such discount may be based on previous purchases the programmer has made, time of day, and/or the like. Additionally, the video- sequence functionality 540 is used to define a list of videos that will play in sequence. The videos may be movie previews, music videos, theatrical trailers, or similar short videos. Video-sequences may be sequential or randomized.

Furthermore, the list definition functionality 550 is used to group the titles that are planned to be available in a particular server 108. A list provides groupings that are used for the promotion of a set of titles (e.g., New Releases), and also provide ease of title selection by a subscriber .

Moreover, the content distribution planner 150, is used to manage the availability and distribution of scheduled titles. This function normally will not require any programmer intervention. The functional aspects of the content distribution planner 306 have been discussed hereinbefore (ref . FIG. 3 and 4) . The remaining functional aspects of the program scheduler are discussed in detail below in FIGS. 6 through 12.

In general, the storage space of a server 108 located at a head-end 102 may be utilized by one or more service providers. As such, the storage space of a server 108 must be configured in a manner that avoids conflicts and efficiently utilizes such storage space.

FIG. 6 illustratively depicts the video server administrative functionality of the program scheduler 512. Specifically, two distinct service providers 600 are depicted, "SP1" 602 and "SP2" 604. Each service provider 600 has a portion of their repository of video assets stored on individual servers S_x through S_n lOδi through 108_n ( collectively servers 108) located at a plurality of server head-ends 102 The entire repository of video assets may be collectively spread among the plurality of servers 108, or as m the preferred embodiment, a central repository may exist at a content distribution center 101.

As the number of video servers grows, it is increasingly difficult and time consuming for the programmers to independently schedule title-plans for each server 108. Therefore, one advantage of the program scheduler 150 is to allow a programmer to group individual servers 108 with other servers and thereby form server groups 620 The servers 108 may be grouped based on marketing requirements (e.g., demographics and/or geography) , or m any other manner that aids the programmers m scheduling. In this manner, the programmer does not have to repetitiously create duplicate title-plans for each server 108 scheduled to receive the same video asset.

The server groups 620 may be representative of either the service providers 600 (e.g., cable companies or any other multiple subscriber organization (MSO) ) , or a category 610 of the service provider 600. A category 610 or service provider 600 may have multiple server groups 620. In particular, SPl 602 comprises two categories named "Late Night" 612 and "New Release_l". The category Late Night 612 is further comprised of two server groups 620. One server group termed "Regular Only" 626 is comprised of servers Si and S2. The other server group 620 of the Late Night category 612 is labeled "Extreme & Regular" 628, and is comprised of the single server S3 Similarly, the New Release_l category 614 is comprised of three server groups 620. A server group 620 "Group_l" 632 has storage space on servers Si and S3. Similarly, the server groups "Group_2" 634 and "Group_3" 636 each have storage space on single servers S2 and S4 respectfully. The subdivision of video assets into various categories 610 of a service provider 600 is implemented to ensure a good mixture of video assets and prevent any additional conflicts during definition of title-plans.

Additionally, the service provider SP1 602 is also comprised of another server group "New Release_All" 622. The server groups 620 Group_l 632, Group_2 364, and Group_3 636 are also a subset of the New Release_All server group 622. The service provider SP2 604 is comprised of a server group termed SP2_A11 624. The server grouping for SP2_A11 624 is on the servers SI through S4. However, unlike the service provider SPl 602, SP2 604 does not have any categories representing any other combinations of video assets .

The grouping of video servers is limited by a set of genre-mix rules via the administrative functionality 512. The genre-mix rules are utilized in the scheduler programmer 150 to alleviate conflicts between defining server groups 620 and allocating the storage space at each of the servers 108 For example, the service providers SPl 602 and SP2 604 require separate storage space amongst servers SI through S4 108. Typically, the required attributes of a server group 620 comprise a server group name (unique) and group type i.e., whether this group represents the service provider or a category of a service provider. In this manner, the program scheduler 150 serves to prevent any conflict during the definition of title-plans and distribution of their video products from the content distribution center 300 to each server 108. The sub-divisions of storage space on the servers 108 as between the various categories 610 of a service provider 600 are not fixed. Conversely, a hierarchy of priorities is defined. Each higher priority category 610 of a service provider is able to use some percentage of server space allocated to a lower priority category 610 of that service provider 600. In this manner, a category 610 may use space from another category 610 to allow a programmer to set up server space allocation based upon expected usage of the server. Therefore, there is not an steadfast limit on the space usage, so in an instance where there are numerous new releases (which receive higher buy rates) in a particular month, space from a category 610 that typically has lower buy rates may be used. Generally, each category 610 will be allotted a minimum percentage of server storage space that may not be used by any higher priority category 610 of a service provider 600. However, this minimum percentage may be set by an administrator to zero as required. Furthermore, the video server functionality 512 ensures that the server storage space allocated to each server 108 in a server group 620 for each category 610, are almost the same, otherwise, there is a possibility of low server storage space utilization .

As such, the genre-mix rules permit a server group 620 representing a service provider 600 to include any subordinate server groups 620 representing subordinate categories 610 of that service provider server group 620. For example, the video server group labeled NEW RELEASE_ALL 622 of the service provider SPl 602 may contain various server groups 620, including those server groups 620 representing the subordinate New Release_l category 614 of SPl 602. In this instance, the server groups 620 termed Group_l 632, Group_2 634, and Group_3 636 comprise the New Release_l category 614. These three server groups 620 are also a part of the composite New Release_All server group 622.

However, the reverse is prohibited. Thus, a server group 620 representing a service provider 600, e.g., NEW

RELEASE_ALL 622, may not be included into any other server group 620, e.g., Group_l 632. Furthermore, a server 108 defined in one server group 620 of a category 610, may not be defined in another server group 620 for the same category 610.

Thus, server SI in the Regular Only server group 626 of the Late Night category 612 is restricted under the genre-mix rules from also being defined in the server group Extreme & Regular 628. This restriction occurs since Extreme & Regular 628 is also a part of the Late Night category 612.

Notwithstanding, the server SI of the Regular Only server group 626 may be defined in another category 610, such as New Release_l 614. In this instance, server SI is defined in the server group Group_l 632. Additionally, a server group 620 representing a category 610 of a service provider 600 may not be included in another server group 620 representing a different service provider 600 or a category 610 of a different service provider (e.g., Group-1 632 representing New Release_l 614 of "SP2" 602 may not be included in SP2_ALL 624) . As such, these subsequent genre-mix rules maintain the hierarchical grouping for the servers 108 and avoid conflicts in the allocation of server storage space.

Thus, a programmer may create title-plans for one or more servers 108 by specifying a group of servers that are to receive such title-plan. In this manner, each head-end is capable of supporting their respective subscribers based upon demographic, marketing and/or other considerations.

A principal aspect of the program scheduler 150 is an ability to define video titles in terms of what a subscriber desires to view and providing such subscriber with numerous choices for selection. The majority of the other functional attributes of the program scheduler 150 are based upon the programmers ability to create and implement "title-plans" . Specifically, a title-plan describes when a title, i.e., video asset, will be available on a particular server or group of servers for subsequent delivery to the subscribers.

FIG. 7 depicts a method of defining title-plans through use of the program scheduler. Title-plans are defined in terms of their various attributes . There may be multiple title-plans created, and they are created in advance of delivery to a server or server group (e.g., 60 days prior to delivery to thereby permit encoding the content, preparing trick tracks, creating MIS information, and the like) .

The method 700 starts in step 701, and proceeds to step 702 where the programmers must specify the period of time they are currently working. As such, the programmers define a filter-period (start-date and end-date) before creating, modifying or deleting any title-plan. The filtering is performed to limit the number of titles or title-plans to a manageable amount. Thereafter, a programmer is allowed to define, modify, or delete only those title-plans whose date ranges fall within the first defined filter-period.

In step 704, the programmer selects and retrieves a video asset title from a title database. The attributes of a title-plan for a video asset may then be added or modified in any order illustrated in the following steps. In steps 706 and 708, the programmer selects a server and/or server group that the video asset will be stored. The server and server groups correspond to each neighborhood of subscribers that are scheduled to have access to the video titles and assets. Multiple title-plans may be defined simultaneously by selecting multiple titles and/or by selecting multiple servers during title-plan definition.

Furthermore, in step 710, a date range (start-date and end-date" between which, or individual dates of which the title will be available on the server/ server group) .

Specifically, the dates associated with a title are rights dates, i.e., the dates in the title and rights manager in which a programmer has rights to schedule the video assets on the servers. Thus, the programmer defines a date range in which the programmers want the video assets loaded on a server and/or server group, within the allotted date range (window) defined by the title and rights manager. The default start-date of a title-plan is the "start-date" if the start- date for the title falls after the start-date of the filter period, otherwise, the default start-date of the title-plan is the start-date of the filter period. The default end-date of a title-plan is the "end-date" .

In step 712, a comment section allows the programmer to explain why a title was included in the title-plan, e.g., serving as a trigger title for a package, as part of normal scheduling, or any other comment as required.

Moreover, in step 714, the title-plan also allows a programmer to view a video asset in terms of a category or genre. A category or genre is initially created by the programmer to categorize and sub-categorize video assets depending on marketing considerations and the video asset's features . The categories and genres of step 714, as well as the other various attributes such as stars, box-office revenue, length of video (hr./mm.), distributor, and the like are defined m the title database. As such, the attributes may optionally be used by a programmer to filter the video assets for example to determine whether to create a title plan for a title.

In step 716, a two-stage "commit" process for title-plan definition is implemented. The two-stage commit process allows a programmer to see how a server may appear with a set of video assets. The programmer first defines or modifies the title-plans m a scratch pad, and then stores the plans m a title-plan database. In this manner, processing of a video asset will not start prematurely. The method 700 also allows the programmer to specify various reports to be displayed or printed. Illustratively, the various reports available for viewing or print may include the title-plans for a set of servers and server groups, for a set of service providers, and for a set of categories and a date range.

Moreover, the program scheduler will flag scheduled titles for which new work-orders need to be generated. Work- orders are generated because the title does not exist m ready form, and the earliest date on which such title may be scheduled (stored m the title database) falls after the title-plan start-date. Thus, the title must be "rush ordered" . Upon the programmer optionally receiving the various reports, the method 700 proceeds to step 718, where the method 700 ends. FIG. 8 illustratively depicts a title-plan interface on a programmer's display 800. Specifically, the title-plan interface is an interactive graphical user interface that allows a programmer to view various title-plan fields. A programmer may enter information m title-plan fields such as a filtering period 802, title name 804, video servers 808, server groups 810, date range 812, time interval 814, and comments 816. Viewable only title-plan fields may include title ID 806 (assigned by the title and rights manager) , category, and genre, as well as stars, box-office review, length, distributor and other 820. Additionally, a programmer may view server utilization of storage space 822. For example, the pre-defined filter period 802 is typically for a month, e g , from November 1, 1999 through November 30, 1999 The title name 804 "The 11^th Commandment" is the name of the video asset that is scheduled, along with the title ID 806, i.e., "3026". The video asset will be available for viewing on selected video servers 808 "S23-S26" and on video server groups 810 "8" and "9" during the date range 812 of December 15, 1999 through February 12, 2000.

Optionally, the specific time interval 814 may also be included. In this instance, the video asset will be available for selection by a subscriber from 3:30 p.m. through 11:00 p.m. each day, throughout the selected date range 812. Alternately, if no time intervals 814 are specified, then a video asset would be viewable at all times withm the defined date range. Additionally, the comments provision 816, e.g., "actresses 50^th birthday" is optionally added to describe the reason why the video title-plan was created.

The programmer is also provided with information pertaining to the selected video asset that may be displayed and read to identify the type of video asset the programmer has selected. Illustratively, the category is defined as "The 70' s" and the length of the film is 1-hour and 43 minutes .

Additionally, title-plans which belong to a particular server or server group may also be sorted, as well as, title- plans for a particular title, category, or genre. The filtering functionality may be a Boolean filter (e.g., "and", "not" and "or") . Furthermore, filtering a set of displayed titles may also be set in terms of category, genre, stars, box-office revenue, length, distributor, or otherwise. Moreover, the monitoring feature of the inventive application allows the programmer to observe the average server space usage 822 for a server or server group, within a chosen period for a current service provider. Such a programmer may also obtain detailed information regarding the server space usage on a daily basis, and view the average server space usage while adding, modifying and deleting title-plans for the current service provider. Similarly, the system administrator is able to display detailed information regarding server storage space usage on a daily basis for the entire server, grouped by service provider (not shown) .

Moreover, the program scheduler application is capable of storing information about the links from the content control center to each individual server site. The information is used to determine when the video assets require transmission from the content distribution center to the server or server group. Such information may include link type (satellite, terrestrial, and platter delivery), link speed, link latency, and link sharing, i.e., sharing bandwidth with multiple servers on a satellite link. FIG. 9 depicts a process for reviewing and storing newly defined, modified, or deleted title-plans 900. Specifically, the method 900 begins at step 901 and proceeds to step 902 where a two-stage "commit" process for title-plan definition is implemented so that the programmer may first define, modify or delete the title-plans in a scratch pad, and then store the title-plans in a title-plan database. In step 904, upon committing the title-plan, the application validates whether any new title-plan violates any genre-mix rules defined by the service administrator. In step 906, the program scheduler notifies the programmer of any genre-mix violation and subsequently permits overriding such genre-mix violation constraint as required. If the violation is overwritten, then in step 908, the method 900 generates a report stating the details of the violation. The method 900 then proceeds to step 912.

In step 912, the program scheduler validates that the total server space used by all the titles belonging to a service provider is not more than the total server space initially allocated to that service provider. If, in step 912, the allocated server space of a service provider has been exceeded, then in step 914, the programmer is notified of such occurrence, and the programmer must change the schedule to meet the partitioning constraints. Specifically, the programmer may remove a portion of the scheduled video assets to accommodate the server space limitations. The method 900 then proceeds to step 916. In step 916, the programmer validates that a set of video assets belonging to a category has not consumed more server space than has been allocated to such category. The method 900 then proceeds to step 918. In step 918, the programmer is notified by the program scheduler that the storage space for a category is either within or exceeding the storage space capacity. In step 920, the programmer may optionally consume more server space than was initially allocated to that category by appropriating unused server space from any lower priority categories of that service provider. Upon completion of checks and balances, in step 922, the title-plan is stored in a title-plan database and in step 924, the method 900 ends.

After defining a title-plan, a programmer may deem it necessary to modify or delete a title-plan or group of title- plans thereof. The methods 700 and 900 are also utilized to modify or delete title-plans. When modifying a title-plan, the title name, ID, server and server groups are non-modifiable attributes of a title- plan. The removal of a title or a server from a title-plan will require a programmer to delete that title-plan entirely and create a new title-plan. The program scheduler permits only the date ranges, the individual dates, or the time intervals in a day for a preexisting title-plan to be changed. No modification is permitted when the start-date of a title-plan has already begun. If the programmer has defined multiple title-plans simultaneously and tries to modify any of the title-plans from that set, the application queries the programmer whether the modifications shall be implemented in all the other title-plans in that set.

Furthermore, the 2-stage commit method 900 is implemented to save such modifications. Referring to method 700 in FIG. 7, in steps 702 through 720, the programmer first defines the modifications in a temporary space. Then, referring to FIG. 9, in step 902 of method 900, the programmer commits the changes. In step 904, the application performs genre-mix validation of step, and in steps 906 and 908, notifies the programmer of any genre-mix violation to correct or override the genre-mix violation warnings . The method then proceeds to through the steps 910 through 922, and the method 900 ends m step 924.

Likewise, the methods 700 and 900, as depicted m FIGS. 7 and 9 respectfully, may be utilized m part for deletion of title-plans. Deletion of title-plans is similar m format as the creation and modification aspects of the application. The method starts m step 701 and proceeds to steps 702 and 704 where the programmer selects a title-plan for deletion. The method then proceeds to step 722 where the program scheduler utilizes the 2-stage commit step to confirm the intent to delete that title-plan.

The method 700 then proceeds to the method 900 as depicted m FIG. 900. In step 902, upon deletion, the method 900 proceeds to step 904 where the program scheduler performs genre-mix validation. Then, m step 906 and 908, the application notifies the programmer of any genre-mix violation. The method 900 disregards steps 910 through 920, and proceeds to step 922 where the method 900 stores the changes to the title-plan database. Then m step 924 the method 900 ends.

Once a programmer has defined a title-plan, a programmer may create a package-plan to serve as a marketing tool by the service providers to reach specific subscribers. A package is a set of titles that are planned to be available on a server and are subject to some discount m price. There may be several kinds of packages depending on the discount criteria and discount amount.

FIG. 10 illustratively depicts a package-plan interface on a programmer's display 1000. Specifically, a package-plan is provided with a description 1002 and an identification number 1004. The identification number 1004 is unique for that specific package. Package-plans typically offer a discount on any title included m that package f a subscriber satisfies some package criteria 1006. Such package criteria 1006 may include subscribers that pay a monthly subscription fee where specific video assets are included m the monthly selection. Alternately, some packages may offer a promotional discount on a category of titles without any specific requirement, simply by paying for the package itself. Specifically, the subscriber may be given a discount for a title because the title is being promoted. For example, titles m the category "LAST CHANCE" may be packaged at a discount because they are being removed from the servers during the following week. Thus, the subscriber is given a last chance to view the video asset and at a lower purchase price . A programmer must also enter a discount amount 1008 for the titles of the package m terms of either a percentage of list pricing (100% to 0%) or a fixed dollar amount. Furthermore, a service code 1010 is utilized for packages having a monthly subscription fee. The service code 1010 allows a billing system of a service provider to automatically charge the subscriber for the ordered package.

The package-plan must specify the server 1012 and/or server groups 1014 that the package will be distributed. Thus, only those subscribers linked to such server or server groups at their respective head-ends are able to order such packages. In this manner, a package may be distributed to various subscribers based upon the subscriber's demographics or other marketing considerations .

Additionally, a programmer must enter a date range having a start date 1016 and an end date 1018. However, the end date 1018 may be ongoing. Furthermore, an optional time interval 1020, i.e., time of day, and days of a week 1022 allows a programmer to define packages such as a midday matinee, weeknight special, and the like. . Thus, a package will be available to selected subscribers on the date and times specified by the programmer. The programmer must define the specific video assets included m the package. To define the specific video assets, the programmer may include individual titles m a title field 1026 For example, a programmer would specify individual titles m an instance where the programmer wanted to give a discount to 5 titles featuring a specific movie star. Since that movie star may have more than 5 movies and the movies are not definable by either category or genre, the programmei must individually list the 5 selected movies for that movie star. Alternately, the programmers may define the specific video assets by specifying a genre m a genre field 1028. For example, specifying the genre "horror movies" will include all horror movies that are defined m the date range. Furthermore, the criteria for defining video assets m a package may be expanded to encompass any other business, marketing, or parameter such as distributor, box office sales, and the like.

Typically, the listed video assets m a package plan have title-plans already created However, there may be instances where particular video assets have been included m a package, which on their own merits would not have been scheduled for a server loading via a title plan within the defined date range.

Accordingly, the programmer is provided with the flexibility to define title-plans 1030 for any titles that were defined m the package plan, but did not previously have title-plans for the date range of the package. In this manner, such video assets may be promoted and possibly acquire renewed subscriber popularity.

Modification of any of the attributes of a package-plan is permitted. However, the programmer may not modify the start-date of a package that has already started. Moreover, package-plans not currently active may be deleted. The application confirms the intent to delete any package-plan. Upon completion of the package-plan, the programmer utilizes the two-stage "commit" interface of the program scheduler 1032. Thus, the programmer first defines or modifies a package-plan in a scratch window, and then commits (adds) the package to a package database after the genre-mix rules are validated.

FIG. 11 illustratively depicts a video-sequence interface on a programmer's display 1100. A video-sequence is provided to subscribers for viewing along with the titles and packages. A video-sequence is a sequence of videos that play in a succession. Examples of a video-sequence are movie previews, theatrical trailers, music videos, advertisements, or other short video clips.

A video-sequence is defined in terms of its attributes as depicted in FIG 11. The attributes include a video- sequence name 1102, a video-sequence type 1104 (e.g., music video, theatrical trailer, advertisement, movie previews, or otherwise), a video-sequence description 1106, and a server 1108 or server groups 1110 in which this video-sequence will be distributed.

Additionally, a date range having a start date 1112 and an end-date 1114, (wherein the end-date may be on-going) is provided for the programmer, as well as the time of day interval 1116, days of the week 1118, and any additional comments 1120 that the programmer may deem necessary. Other attributes that a programmer must define are video-sequence contents 1122 Such contents may include individual titles from music videos, theatrical trailers, advertisements, movie previews, or otherwise. Also available for selection by a programmer is any of the genres 1124. The program scheduler permits a programmer to view and select all the titles from a particular genre for inclusion into a video-sequence .

Programmers may define a video-sequence as a subset of a larger succession of videos, where the subset of videos may be randomly played or defined m a specific order. Furthermore, the programmer is able to modify or delete any of the attributes, excluding a video-sequence that already has started, i.e., past the start-date. Once the subscribers receive the video sequence, the subscribers may skip forward and backward between the video assets m the video-sequence.

Upon completion of creating the video sequence, the programmer utilizes the two-stage "commit" interface of the program scheduler 1126. Thus, the programmer first defines or modifies a package m a scratch window, and then commits the video-sequence to a video-sequence database after the genre- mix rules are validated.

FIG. 12 illustratively depicts a list interface on a programmer's display 1200. A list is a compilation of titles of video assets, screens, or other lists that are used for grouping, so that the subscriber may readily select a desired title or screen. The lists are also used to promote some of the video assets.

A list is defined m terms of the attributes specified by a programmer. Typically, the programmer defines a filter period 1202 having a start date 1204 and an end date 1206 before defining a list. The filtering assists the programmer by excluding from the database titles a programmer does not need to see. Thus, creating and implementing the lists becomes manageable from the perspective of a programmer. Any list that is defined, modified, or deleted must fall withm the specified filter period.

The attributes of a list comprise a unique list name 1208, and a list type 1210 must be specified. The list type 1210 illustratively may be a preview, normal, MIS or other component of a video asset. Thus, a preview list will contain only the preview tracks of the titles included m the list. Additionally, a list description 1212, a server 1216, server groups 1218, a date range 1213 having a start date 1214, and an end date 1216 (e.g., the end date may be "ongoing") must also be entered by a programmer. Furthermore, a time interval 1218 (i.e., time of day) , days of a week

1220, and a comments field 1220 are optional attributes that may be entered by the programmer. Thus, a list will be available only to subscribers corresponding to the specified server and/or server groups on the date and times set forth by the programmer.

The titles included the list are specified m a list contents attribute 1226. The list contents may include categories (i.e., all titles from these categories that have title-plans with the list date range), or genres (i.e., all titles from these genres that have title-plans withm the list date range) . Furthermore, the list contents 1226 may include titles having title-plans with the list date range 1201, other lists withm the list date ranges, packages scheduled withm the list date range, and other screens and corresponding texts (e.g., video clips and promos) . The lists are rule based m terms of genres or categories. When defining rules for a list, the programmer IS able to view and select all the genres, categories, and titles that are available with the filter period 1202. Additionally, the programmer may select previously defined lists that are available m the filter periods 1202, and all the servers 1222 and server groups 1224 Any packages 1000 and video-sequences 1100 that have already been defined and included are automatically used to generate the rules for individual lists.

In an event a programmer has defined rules for a list m terms of only genres or categories, the programmer has the option of defining "On-gomg" as an end-date for the list. "On-gomg" , as the end-date will signify that this list will continue unless the list is deleted or its end-date is modified. The programmer may associate a video-sequence 1100 with a standard list. One list shall be designated the master list, and the other list will be populated with the contents of the master list. For example, if the programmer has defined a master video-sequence named "Last Chance" the programmer may define a list and populate it with the contents of the video-sequence named "Last Chance" .

The programmer may modify any of the attributes of a list, excluding a start-date 1202 of a list that already started. A list containing only individual titles is modifiable on a periodic basis. For example, where a programmer recommends particular titles by specifying such titles a list, e.g., on a weekly basis, such list would have to be modified or new list created to replace the former list on a weekly basis. However, since most of the lists are rule based, that is, defined m terms of genres or categories, the lists will not be modified frequently. For example, a list for a genre "Westerns" 1228 is created once, and then remains as an ongoing list without requiring periodic programmer updates .

The programmer may delete a list not currently active, and after confirmation of intent. A view window for lists automatically refreshes itself with the updated contents after the programmer adds, modifies, or deletes a list.

Upon completion of the list, the programmer utilizes the two-stage "commit" interface 1232 of the program scheduler. Thus, the programmer first defines or modifies a list in a scratch window, and then commits the list to a list database after the genre-mix rules are validated.

Referring to FIG. 5, the administrator functions 514 of the administrative functionality 510 may be segmented into two groupings, i.e., system administration 516 performed by system administrators and service administration 518 performed by service administrators. The administrator function 514 addresses various matters regarding defining system resources, programmer access rights, programming guidelines, and the like. The system administration 516 allows a system administrator to subdivide the server space among various service providers, as well as setting the overall configuration information of the program scheduler 150. In particular, the system administrator 516 may allocate space on a video server (in terms of maximum allowable minutes or disk size) to each service provider as well as sub-divide video server space that has been pre-allocated to a service provider, among the various categories of that service provider. The allocation of video server space to the various categories of a service provider is prioritized so that a higher priority category shall be able to use server space allocated to a lower priority category of a service provider. Each category of a service provider is provided with a minimum percentage of server space allocated to it, which may not be used by any higher priority category of that service provider under any circumstances. However, the minimum maybe set to zero.

The program scheduler 150 provides notifications to the system administrator when the system administrator tries to delete a video server or modify the attributes of a video server. The program scheduler 150 disallows a video server from being deleted if there are title plans defined after the current date. This ensures that the system administrator cannot accidentally delete or modify the attributes of a video server. Furthermore, the system administrator may add and delete programmers for the program scheduler application as well as define programmer access rights (read, write, and no-access) defined for various functions of the program scheduler 150.

The various functions include video server related administrative functions, programming guideline related administrative functions, programmer definition and access right definition functions, and a title plan definition function for a set of video servers and/or server groups and a set of categories. Additional functions include a package definition function for a set of video servers/groups and a set of categories, a list definition function for a set of video servers and/or server groups and a set of categories, a video sequence definition function for a set of video servers and/or server groups and a set of categories, the service providers of which the programmer is associated, and other administrative functions. Additionally, the system administrator may indicate a programmer is a service administrator, and which service provider they may admimstrate Moreover, the system administrator 516 performs backup and recovery of the databases used to store the title-plans, the rules for the lists, and the packages Furthermore, a system administrator 516 may archive and restore old data from the title-plan database illustratively, to control the database size as required.

A second type of administrator is the service administrator 518. The service administrator is responsible for defining the scheduling parameters related specifically to a service provider. That is, while a system administrator 516 performs administrative functions for the entire scheduling system, the service administrator 518 is limited to performing administrative functions only for the specific service provider the service administrator 518 is assigned. The service administrators may add and delete video servers and modify the attributes of a video server The required attributes of a video server are a unique video server name, type (PVOD, and the like) , location, total storage space (minutes or gigabytes), and operator. Additionally, the service administrator may define video servers into multiple video server groups for a service provider, or for a category of a service provider. The required attributes of a video server group are video server group name (unique), group type (i.e , whether this group represents a service provider or a category of a service provider) , represented service provider name, represented category name (must be blank if this group represents a service provider, and not a category of a service provider) , and maximum allowable spread of server space between the included video servers (i.e., the difference between the server space size allocated to the video servers included this group, must fall withm this limit) The service administrators 518 may define "genre-mix" rules for each video server/ server group where the administrator shall specify the ideal percentages of video server space (in terms of allowable minutes) and/or number of titles that are to be used by title-plans belonging to each genre.

Furthermore, the program scheduler 150 ensures that the service administrators cannot include a single video server into multiple video server groups if the video server groups represent same service provider or same category of a service provider. Additionally, the service administrators shall be able to include a video server group that has been created for a category of a service provider into a video server group that has been created for that particular service provider. The scheduler 150 also ensures that video server groups that have been defined to represent a service provider does not get included into other video server groups. In addition, a video server group that has been defined to represent a category may not get included into a video server group for another category.

In order to prevent scheduling conflicts, the program scheduler 150 ensures that a video server group that has been defined to represent a category of a service provider does not get included into a video server group that has been defined to represent a different service provider. Moreover, the scheduler 150 ensures that if a video server group has been defined to represent a service provider, the server space allocated to that service provider on the included video servers' will fall within the "maximum allowable spread of server space" for that group. Likewise, the program scheduler 150 ensures that if a video server group has been defined to represent a category of a service provider, server space allocated to that category on the included video servers will fall withm the "maximum allowable spread of server space" for that group.

Service administrators 518 may add and delete programmers that only have access to the service that the service administrator is responsible for. Service administrator permissions include programmer definition and access right definition, title plan definition for a set of video servers and/or server groups and a set of categories, package definition for a set of video servers/groups and a set of categories, list definition for a set of video servers and/or server groups and a set of categories, and video sequence definition for a set of video servers and/or server groups and a set of categories . All data presented to the programmer is limited to the data of the service provider a programmer is associated with. For the convenience and efficiency of scheduling filtering may be performed for various criteria, i.e., genre, category, server groups, titles, etc. Thus, the program scheduler 150 restricts accessibility of a programmer, service administrator 518, and system administrator 516 withm the application 150 based on each of these aforementioned access rights.

A novel apparatus and method for distributing video assets to a plurality of subscribers based upon subscriber demographics and other marketing criteria has been disclosed. Specifically, a program scheduler m an interactive information distribution system allows program scheduling and management of video assets from a plurality of service providers. In particular, video assets of each individual service provider may be categorized and stored m selective servers, or groups of servers at specified dates and times Furthermore, hierarchical control of the program scheduler is divided between system administrators of the entire program scheduler, and service administrators and programmers for each service provider.

Thus, the video assets sent to the servers and groups of servers and made available are customized to the tastes and desires of the respective subscribers . Although various embodiments that incorporate the teachings of the present invention have been shown and described m detail herein, those skilled m the art can readily devise many other varied embodiments that still incorporate these teachings.

Claims

CLAIMSWhat is claimed is:

1. Apparatus for distributing video assets comprising: a program scheduler (150) for identifying video assets for distribution; a plurality of servers (108), coupled to said program scheduler (150) for receiving and storing said identified video assets.

2. The apparatus of claim 1 wherein said program scheduler

(150) identifies particular servers (108) to receive and store selected video assets.

3. The apparatus of claim 1 wherein said distribution system program scheduler comprises: a plurality of programmer interface front-end modules (302); a back-end module (304) coupled to said plurality of programmer interface front-ends (302); a title database (310) coupled to said plurality of programmer interface front-ends (302); and a content distribution planner (306) coupled to said back-end (304) via a title-plan database (314) .

The apparatus of claim 3 wherein said content distribution planner (306) is coupled to said plurality of servers (108) for selectively distributing said video assets to said plurality of servers (108) .

The apparatus of claim 4 wherein selectively distributing said video assets to said plurality of servers (108) based upon marketing and subscriber criteria is defined in title-plans via said plurality of programmer interface front-ends (302) .

6. The apparatus of claim 5 wherein each server of said plurality of servers (108) further comprises a content manager (330) that proactively sends control messages to said backend module (304) in an instance where inventory status of said video assets changes on said video server (108); said inventory status is stored in said title- plan database (314); and said content distribution planner (306) polls said title-plan database (314) to determine which video assets need to be sent to each said server (108) .

7. The apparatus of claim 6 wherein said content distribution planner (306) determines when to transfer said title-plans to said servers (108) .

8. The apparatus of claim 7 wherein a content delivery manager transfers said video assets not currently stored on said servers (108) to said servers (108) as defined in said title-plans .

9. The apparatus of claim 5 wherein said title-plans comprise : a title name (804) of a video asset; at least one server (808) to receive said title-plan and said video asset; and a time period (812, 814) when said video asset is available for viewing by a plurality of subscribers coupled to said at least one server (108) .

10. A method (400) for distributing video assets comprising the steps of : identifying (402) selected video assets to be stored on particular servers within a network of servers; and coupling (418) said selected video assets to said particular servers for storage.

11. The method (400) of claim 10 wherein said identifying step (402) further comprises the step of generating a title-plan comprising identification information for said selected video assets; and inventorying (406) said servers in view of said title-plan to identify the servers that require video assets to fulfill the title-plan.

12. The method (400) of claim 11 further comprising the steps of: inventorying (406) a plurality of servers (108) for video assets stored thereon; polling (408) for newly defined title-plans; inventorying (410) a title database (314) for availability of said video assets at a content distribution center (101); sending (414) a list of video assets scheduled for delivery to a content delivery manager (324); delivering (416) said list and said at least one title-plan periodically to a content manager (330) at each server of said plurality of servers (108) as defined in said title-plans; and transferring (418) said video assets to each said server of said plurality of servers (108) in accordance with said title-plan.

13 The method (700) of claim 11, wherein defining said at least one title-plan comprises the steps of: retrieving (704) a title of a video asset from said title database (310) via a title and rights manager (312) ; specifying (710) a date range of availability of said video asset; designating (706, 708) a server or group of servers from said plurality of servers (108) , and storing (716) said at least one title-plan m said title-plan database (314) .

14. The method (700) of claim 13, further comprising the steps of grouping at least one (108) server to form a server group (620) representing a service provider (600) or a plurality of categories (610) of a service provider (600) ; and prioritizing each said category (610) wherein a higher prioritized category may allocate storage space from a lower prioritized category.

15 The method (900) of claim 14, wherein storing said title-plans comprises the steps of: validating (904) genre-mix rules as between server groups (620) for categories (610) and server groups (620) of service providers (600); validatmg (912) said video assets belonging to a service provider (600) has not consumed more server space than allocated to such service provider (600) ; validating (916) said video assets belonging to a category (610) has not consumed more server space than allocated to such category (610) .

16. The method of claim 12, wherein inventorying said plurality of servers (108) comprises the steps of: receiving proactively sent status messages from a content manager (330) at each of said servers of said plurality of servers (108); and storing a l st of said inventoried video assets m said title-plan database (314) .

17. The method of claim 12, wherein polling for newly defined title-plans comprises the step of: polling said title-plan database (314) periodically for new or modified title-plans; querying an asset manager (322) for availability of video assets corresponding to said new or modified title-plans , and sending a list of available video assets from a content distribution planner (306) to a content delivery manager (324) .

18. The method of claim 11 further comprising the steps of: defining a package-plan (530) of video assets to selectively market groups of video assets at some discount price; transferrmg said package-plan (530) of video assets to at least one server (108) as defined m said package- plan (530) of video assets; and presenting said package plan (530) to a plurality of subscribers (106) corresponding to said at least one server ( 108 ) .

19. The method of claim 11 further comprising the steps of: defining a video-sequence (540) of video assets to selectively market groups of video assets; transferring said video-sequence (540) to at least one server (108) as defined said video-sequence (540) of video assets; and presenting said video-sequence (540) to a plurality of subscribers (106) corresponding to said at least one server ( 108 ) .

20. The method of claim 11 further comprising the steps of: defining a list (550) of video assets, screens, and other lists for subscriber viewing to selectively market groups of video assets; transferring said list (550) to at least one server (108) as defined m said lists (550) of video assets; and presenting said list (550) to a plurality of subscribers (106) corresponding to said at least one server (108) .

21. The method of claim 18, wherein selecting titles of said video assets for inclusion m said package (530) comprises the step of selecting a genre of titles.

22. A method of scheduling distribution of video assets to a plurality of servers (108) comprising the steps of: identifying at least one service provider (600); identifying video assets belonging to said at least one service provider (600); assigning at least one server of said plurality of servers (108) to at least one server group (620) of said at least one service provider (600); designating, said at least one server group (620) to represent a service provider (600) of said at least one service provider (600); assigning storage space on each of said at least one server (108) of said at least one server group (620) of said service provider (600) to store said identified video assets of said service provider.

23. The method of claim 22 further comprising the steps of: assigning said video assets belonging to a service provider (600) to at least one category (610); designating said at least one server group (620) to represent said at least one category (610); assigning storage space on each of said at least one server (108) of said at least one server group (620) to store said identified video assets of said at least one category (610) .

24. The method of claim 23 further comprising the steps of: defining a hierarchy of priorities between a plurality of categories (610) represented by said at least one server group (620) of said service provider (600); and allocating server space for said video assets in a category (610) having a higher priority from a category (610^' having a lower priority.