System and method for a master scheduler

Abstract

A system and method for associating and controlling multimedia supporting events with a primary event. The events are translated into tasks and sent to media servers for execution at a predetermined time by being further translated into media specific tasks to control a bit-pump.

Claims

What I claim is:

1. A method for scheduling multimedia programs comprising:

creating a primary event in a schedule wherein said creating uses a graphical user interface;

selecting a multimedia event to associate with said primary event wherein said selecting uses said graphical user interface;

associating said multimedia event with said primary event in said schedule wherein said associating uses said graphical user interface;

transforming said schedule into at least one task wherein said transforming creates a task for a media server to provide said associated multimedia event;

distributing said task to said media server;

executing said task at a predetermined time.

2. A method according to claim 1 wherein said graphical user interface uses a grid layout for scheduling.

3. A method according to claim 2 wherein said selecting a multimedia event using a graphical user interface presents to a user a menu of choices.

4. A method according to claim 2 wherein said creating of said primary event and said associating said multimedia event with said primary event uses a cell in said grid in said graphical user interface.

5. A method for scheduling multimedia events comprising:

creating a primary event in a schedule;

associating a supporting event with said primary event in said schedule;

processing said schedule and creating at least one task from said supporting event;

distributing said task to a media server wherein said media server accesses multimedia corresponding to said supporting event;

processing said task and initiating at a predetermined time said media server to access and distribute said multimedia.

6. A method according to claim 5 wherein said primary event and said supporting event are associated with a cell in said schedule.

7. A method according to claim 5 wherein said associating said primary event and said supporting event creates a graph wherein said primary event is a node and said secondary event is a leaf on a graph.

8. A method according claim 5 wherein said predetermined time includes a delta variance.

9. A method for scheduling related events comprising:

creating a primary event in a schedule;

associating a supporting event with said primary event wherein said supporting event is a multimedia event that will be distributed at a predetermined time and does not use cue tones;

translating said supporting event into at least one task by a master scheduler;

distributing said task to a media server;

translating said task into at least one device specific command for a bit-pump at a predetermined time;

sending said device specific command to said bit-pump;

processing said device specific command by said bit-pump and distributing requested data corresponding to said supporting event.

10. A method according to claim 9 wherein said media server is independent of the availability of said master scheduler when a task has been distributed to said media server wherein said task will execute at a predetermined time even if said master scheduler has become unavailable.

11. A method according to claim 10 wherein a status signal is sent to the master scheduler upon the completion of said execution of said task.

12. A system for scheduling multimedia programs comprising:

creating means for creating a primary event in a schedule wherein said creating uses a graphical user interface;

selecting means for selecting a multimedia event to associate with said primary event wherein said selecting uses said graphical user interface;

associating means for associating said multimedia event with said primary event in said schedule wherein said associating uses said graphical user interface;

transforming means for transforming said schedule into at least one task wherein said transforming creates a task for a media server to provide said associated multimedia event;

distribution means for distributing said task to said media server;

executing means for executing said task at a predetermined time.

13. A system for scheduling multimedia events comprising:

a graphical user interface for scheduling primary and supporting events;

a master scheduler wherein said master scheduler generates tasks from said schedule;

a media server;

a distributor module wherein said distributor distributes said tasks to said media server;

said media server comprising

a bit pump;

a timeline and task management module wherein said time and task management module receives said task from said distributor module;

a task translation module to receive said task, translate said tasks into commands and send said commands to said bit pump.

14. A computer program embodied on a computer-readable medium for scheduling multimedia programs comprising:

event creation code segment for creating a primary event in a schedule wherein said creating uses a graphical user interface;

selection code segment for selecting a multimedia event to associate with said primary event wherein said selecting uses said graphical user interface;

association code segment for associating said multimedia event with said primary event in said schedule wherein said associating uses said graphical user interface;

transforming code segment for transforming said schedule into at least one task wherein said transforming creates a task for a media server to provide said associated multimedia event;

distribution code segment for distributing said task to said media server;

execution code segment for executing said task at a predetermined time.

15. A computer program embodied on a computer-readable medium for scheduling multimedia events comprising:

creation code segment for creating a primary event in a schedule;

association code segment for associating a supporting event with said primary event in said schedule;

first processing code segment for processing said schedule and creating at least one task from said supporting event;

distribution code segment for distributing said task to a media server wherein said media server accesses multimedia corresponding to said supporting event;

first processing code segment for processing said task and initiating at a predetermined time said media server to access and distribute said multimedia.

16. A computer program embodied on a computer-readable medium for scheduling related events comprising:

creating code segment for creating a primary event in a schedule;

associating code segment for associating a supporting event with said primary event wherein said supporting event is a multimedia event that will be distributed at a predetermined time and does not use cue tones;

first translation code segment for translating said supporting event into at least one task by a master scheduler;

distribution code segment for distributing said task to a media server;

second translation code segment for translating said task into at least one device specific command for a bit-pump at a predetermined time;

sending code segment for sending said device specific command to said bit-pump;

processing code segment for processing said device specific command by said bit-pump and distributing requested data corresponding to said supporting event.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to a system and method for controlling, identifying and coordinating multimedia assets for a broadcast program and for increasing the tolerance of broadcast systems to the failure of the scheduler.

2. Description of the Related Art

The task of producing a broadcast program is a complicated, time consuming and error-prone job. Traditionally, a programmer (which is understood by one skilled in the art to be a person who creates a broadcast schedule, in contrast to a computer programmer who writes code) assigns a broadcast program (a broadcast event), to a time slot and ensures that other events, like interstitial, such as commercials, are available to be inserted into the output stream when a cue tone is detected. If the programmer desires to add other types of information, such as multimedia data, the programming is complicated even further and may not even be possible using current broadcast scheduling technology.

There are generally two classes of program schedulers. The first class are traffic system schedulers and these type of schedulers are used primarily in analog and analog-digital hybrid broadcast systems. A common use for this type of scheduler is to sell advertising space to broadcast sponsors and to control the allocation of ads within a broadcast stream. Generally, program schedulers in this class, use the well-known cue tone method. To schedule a program, a programmer would enter into the scheduler the time when a movie or show was to be broadcast and a list of interstitials that are to be inserted into the movie during the broadcast of the movie. At the appropriate time, the program scheduler itself would, for example, initiated playing the scheduled movie and prepare the devices, such as tape drives, containing the list of interstitials. Interspersed within the movie are cue tones to indicate where interstitials are to be inserted. A cue tone detector detects the cue tone and inserts an interstitial from the list into the output stream of the movie at each detected cue tone by controlling the device to output the requested interstitial. Ads, treated as interstitial, are thus merged into a single output broadcast stream.

A second class of program schedulers are broadcast schedulers. These schedulers are used not only to control devices but to also and identify the flow of the various parts of a broadcast program. An electronic program guide ("EPG") is created from the program schedule data. Broadcast schedulers may interface with other databases, such as system configuration and product databases. In a digital broadcast system (in contrast to an analog broadcast system) the programmer inputs the time that a media bit pump (such as a device to play a DVD movie or even a tape drive) is to play a specific event, where the media resides, what media bit pump should play it and how to control the media bit pump. This information often resides in one or more databases, which can be, for instance, flat-file, relational or object-oriented databases. The typical broadcast scheduler would continuously examine the database and, at the scheduled time, the broadcast scheduler would control the appropriate media server to play the desired broadcast event.

Current broadcast schedulers may be further divided into centralized and distributed architectures. Centralized broadcast schedulers utilizing a centralized architecture are very basic and serve primarily as a repository for data. These types of broadcast schedulers directly control devices such as tape drives and have little or no capability in terms of controlling these devices remotely.

Distributed broadcast schedulers are more sophisticated than centralized broadcast schedulers and may include the ability to control devices remotely, that is, the devices and the scheduler do not have to be in the same computer, but may be connected through a network. Although these schedulers often have more sophisticated interfaces to databases than other schedulers, they too can only schedule broadcast events. In operation, when the scheduled time for arrives to broadcast, a movie, for instance, the distributed broadcast scheduler sends out an agent to set-up the movie located on the media bit pump and begin playing the movie. Examples of distributed architecture schedulers are systems by SunUp and Lysis.

One of major limitation of all these schedulers is that the devices, whether they are bit pumps or analog devices such as tape drives, are unable to operate independently without the scheduler controlling these devices. The scheduler is a single point of failure and in the event of a scheduler failure, the entire broadcast system would fail.

Other limitations of the prior art schedulers, include their inability to handle different types of events in addition to simply inserting interstitials. A particular vexing problem is their inability to handle multimedia events. Existing schedulers can deal with a single type of event, but in today's interactive television and digital and multimedia world, it is desirable to be able to schedule and associate a number of events with a broadcast program. These events may include, for instance, information from an Internet site and supplemental information about the broadcast program itself.

Another limitation is that prior art schedulers are unable to synchronize with other devices. Yet another limitation is that they can handle only one service model--the traditional broadcast service model with interstitials. Yet further, they cannot integrate new devices and media servers rapidly and easily, do not integrate with content management and do not support last minute schedule changes and transmissions to a set-top box ("STB").

Because of these deficiencies, prior art schedulers are unable to provide the necessary services required in today's interactive television environment. Accordingly, there is a need in interactive TV to address the deficiencies of prior art schedulers.

SUMMARY OF THE INVENTION

The present invention solves these deficiencies by providing, in accordance with one aspect of the present invention supporting events which are associated with primary events via a graphical user interface. In another aspect of the invention, a distributed broadcast scheduler architecture is disclosed which addresses the deficiencies of prior art program schedulers where devices, such as media servers and tape drives can operate independently of the scheduler by being providing, in accordance with one aspect of the invention, a Master Scheduler and a Slave Task Scheduler thereby ensuring that a failure of the Master Scheduler does not bring down the entire broadcast system. In yet another aspect of the present invention, the Master Scheduler is adapted to schedule events where the viewing of an asset, such as graphics, animation, audio, text, video, or any other such digital media, constitutes the event and changes to a primary event causes all supporting events to be updated, as necessary.

Control of different devices and media servers, and hence, assets, is attained by the use of multiple device independent abstraction layers. In accordance with another aspect of the present invention, the Master Scheduler is a central repository of all schedule data and uses different schedule data models for different media servers.

A programmer enters the programming schedule into the Master Scheduler's data models. Once entered the Master Scheduler processes the schedule and creates a number of tasks based on the schedule. Each task is then distributed to a Slave Task Scheduler on the relevant media server for execution at the proper time. The Slave Task Scheduler is adapted to track the tasks given to it, and, prepare media device to send the scheduled information at the appropriate time. When the task is completed, the Slave Task Scheduler notifies the Master Scheduler of its completion so the Master Scheduler can track the status of the task and update its database.

Another advantage to this architecture over the prior art is the use of a heartbeat monitor, which allows Master Scheduler 120 to determine if Slave Task Scheduler 140 is "alive" and if not, to institute recovery procedures.

These and additional objects of this invention can be obtained by reference to the following detailed description of the preferred embodiments thereof in connection with the attached drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high-level overview of an exemplary embodiment of a system in accordance with one aspect of the invention.

FIG. 2 is a block diagram depicting the compute implementation of the invention is a system such as that shown in FIG. 1.

FIG. 3a shows an exemplary embodiment of Service Specific GUI 110.

FIG. 3b shows an exemplary embodiment of Master Scheduler 120.

FIG. 3c shows an exemplary embodiment of Media Server 130.

FIGS. 4a and 4b show exemplary embodiments of System Scheduling Mechanism 340.

FIG. 5 shows an exemplary embodiment of Slave Task Scheduler 140.

FIGS. 6-22 shows exemplary screen shots of one embodiment of Service Specific GUI 110.

FIGS. 23a, 23b, 24a, 24b, 24c, 24d, 24e and 24f show exemplary screen shots of another embodiment of Service Specific GUI 110.

FIGS. 25-28 shows exemplary data models used on one aspect of the present invention.

FIGS. 29-31 shows exemplary tables used in Publish and Subscribe 420 and the result of calls to registered routines.

FIGS. 32a, 32b, 33a and 33b show exemplary embodiments of tables used in the Queue 3200.

FIG. 34 shows one aspect of a finite state machine and four states.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring now to FIG. 1, there is shown a system in accordance with one aspect of the invention. In particular, there is shown Service Specific GUI 110 which communicates with Master Scheduler 120 through Service/Master Scheduler API 170. In the preferred embodiment, Service Specific GUI 110 resides on one computer while Master Scheduler 120 resides on a second computer, thus, Service/Master Scheduler API 170 is comprised of two parts, Service/Master Scheduler API 170a which is part of with Service Specific GUI 110 and Service/Master Scheduler API 170b which is part of Master Scheduler 120.

Master Scheduler 120 communicates with Media Server 130 through Master/Slave Scheduler API 180. Media Server 130 is comprised of Slave Task Scheduler 140 which communicates with Master Scheduler 120 through Master/Slave Scheduler API 180 and with Bit pump 150 through Device Specific API 190. Bit pump 150 controls and retrieves data from Storage Device 160, which may be, for instance, a disk, tape, CD-ROM, DVD, or even a server.

The Master/Slave Scheduler API 180 acts as the interface between Master Scheduler 120 a media server's Slave Task Scheduler 140. This API is used by Master Scheduler 120 for, among other things, to distribute, administrate and monitor task and media server availability, heartbeat monitoring, and specific media server control, such as initialization, reset and shutdown. Functions such as heartbeat monitoring, which enables Master Scheduler 120 to ensure that Slave Task Scheduler 140 is alive and operating, allows Master Scheduler 120 to institute a recovery procedure, if necessary.

In the preferred embodiment Master Scheduler 120 communicates with Media Server 130 over a network, and thus Master/Slave Scheduler API 180 is comprise of two parts, Master/Slave Scheduler API 180a and Master/Slave Scheduler API 180b as part of Master Scheduler 120 and Slave Task Scheduler 140, respectively. In another preferred embodiment, Master Scheduler 120 communicates with Media Server 130 using shared memory or a common area of memory. This embodiment allows Master Scheduler 120 to communicate more quickly with Media Server 130 and is also more effective if Master Scheduler 120 and Media Server 130 are in single physical box. Of course, to one skilled in the art, other means of communication may also be used, such as wireless communication techniques.

Slave Task Scheduler 140 can communicates with Bit Pump 150 in a number of different ways, for instance, over a network (LAN, WAN, wired, wireless, optical, RF or otherwise). Since Slave Task Scheduler 140 and Bit Pump 150 may be separate, there is a latency inherent in the system. For example, if Master Scheduler 120 expects Media Server 130 to output a NVOD movie a 8:00 PM, in reality, Slave Task Scheduler 140 must begin sending controls down to Bit Pump 150 at, for instance, 7:59:53 PM. This seven (7) seconds difference, called a delta variable or delta variance, allows time for Slave Task Scheduler 140 to send a command or series of commands over a network to Bit Pump 150 to initialize, retrieve the movie, fill its buffer and begin outputting the requested data by 8:00 PM. Slave Task Scheduler 140 has the appropriate data about the delta variance needed to account for each type of Bit Pump 150 that it may encounter and the interconnections type between it and Bit Pump 150.

In the preferred embodiment, Slave Task Scheduler 140 is incorporated with Bit Pump 150 in one physical case, and thus a traditional network is not needed. Instead, Slave Task Scheduler 140 communicates with Bit Pump 150 using well known techniques of shared memory. This embodiment allows for faster access and reduces the delta variance required for Bit Pump 150 to prepare for and begin retrieving and sending out data.

Device Specific API 190 is comprised of two parts, Device Specific API 190a as part of Slave Task Scheduler 140 and Device Specific API 190b as part of Bit Pump 150.

A programmer uses Service Specific GUI 110 for creating a schedule. Prior creating a schedule services are created. A service is a relationship between a primary event and supporting events. A primary event is an event that a viewer can select from the EPG. A supporting event is an event that is subsidiary to the primary event and provides a viewer with additional multimedia data enhancing the primary event. A broadcast service may be defined, for instance has a primary event with two supporting services--text captions and Internet facts. Once defined, Service Specific GUI 110 is able to use the service definition to constrain the choices made by a programmer to ensure that the desired supporting events are available. For instance, if the primary event is a broadcast show, i.e., a broadcast event and the programmer wants, for instance, to provide additional text information about the broadcast event from a data carousel and other facts from the Internet, then there would also be two supporting events--a text caption event and an Internet facts event. Both of these events are supporting events, while the data carousel and the system which obtains the Internet facts would be the supporting services.

The relationship between a primary event and a supporting event may be thought of, in graph theory, as an inverted tree where the primary event is a high level node that is visible and selectable by the consumer, while supporting events are either additional nodes or leaves under such node. A service is thus the set of nodes that can be under a particular type of node. Using the above example, for the broadcast service, a broadcast event node can only have a data carousel for text information and/or Internet material for supporting events. The broadcast event node would thus be the root node and, at most, two leaves (assuming no supporting services for the supporting events) under that root node. If the data carousel is in turn supported by other events, then the data carousel service would not be a leaf, but is itself a node, and would have other leaves under such node.

In the preferred embodiment, the programmer uses a graphical user interface, although other types interfaces, including non-graphical interfaces, may also be used. Moreover, Service Specific GUI 110 may be specifically tailored for particular types of program services, such as broadcast, pay-for-view movies, restricted access, public service and children's programming, although one GUI may suffice for all desired services.

Master Scheduler 120 processes the schedule created by the programmer using Service Specific GUI 110 and generates tasks. Tasks are commands which instruct Media Server 130 to perform an action, such as Initialize or Play. These tasks are then distributed to Slave Task Scheduler 140 in Media Server 130. In accordance with one aspect of the invention, tasks can be distributed months, even years ahead of schedule. Alternatively the tasks can be distributed in "real-time," as long as the distribution is sufficiently prior to the scheduled task to permit Slave Task Scheduler 140 to account for any delta variance.

Moreover, in accordance with another aspect of the invention, the distributed nature of the Master Scheduler 120 from the Media Server 130 and the ability to distribute and have tasks executed independently of Master Scheduler 120 provides the benefit of allowing for recovery in the event of a failure in a media server, thereby providing a degree of fault tolerance to system failures. In particular, Master Scheduler 120 monitors the heartbeat from each media server. The heartbeat is, in its simplest form, a signal from a media server indicating to the Master Scheduler 120 that it is alive and functioning. Master Scheduler 120 can determine from the heartbeat when a media server goes down, and can quickly reassign tasks to other media servers or backup media servers as necessary. When the media server has been brought back up, its heartbeat will provide an indication of this to Master Scheduler 120, which can then reassign to it any of its original unexpired tasks.

At the appropriate time, Slave Task Scheduler 140 executes the task by issuing a device specific command or series of device specific commands to Bit Pump 150. Bit Pump 150 responds to the device specific commands by, for example retrieving the data from Storage Device 160.

Referring now to FIG. 2, there is shown a Computer 210 which executes the code for Service Specific GUI 110. In particular, Computer 210 is, as an exemplary embodiment, comprised of CPU 211 which interacts with Keyboard 212, Monitor 213, Storage 214, Memory 215 and Network Interface 216 and operates in a manner well known to those skilled in the art. Although shown in FIG. 2 as a single processor system, Computer 210 is not limited to this embodiment and may be, for instance, a multiprocessor system, mainframe, or even a client/server system. Similarly, Computer 230 and 240 runs the code for Master Scheduler 120 and Slave Task Scheduler 140, respectively. The details of Computer 230 and 240 are likewise well-known to those skilled in the art an may be similar to those computer systems described for Computer 210. Bit Pump 150, upon receipt of device specific command performs the request action, and, if requested to retrieve data, sends that data over Network 270.

In the preferred embodiment, Computer 210 communicates with Computer 230 via Network 220 and Computer 230 communicates with Computer 240 via Network 260. As can be appreciated by one skill in the art, Network 220, 260 and 270 do not have to be separate independent networks and may, as an example, be a single network where Computers 210, 230 and 240 are simply nodes on that single network. Network 220, 260 and 270 may, for instance, be a LAN, WAN or even a VPN over the Internet and be physically connected or connected wirelessly.

Referring now to FIG. 3a there is shown a more detailed diagram of Service Specific GUI 110. In particular, different supporting services may be addressed and scheduled in different ways. For instance, a data carousel has different specification and information than a NVOD device, which in turn has different specifications than a multiscreen browser service or a music server. Accordingly, different GUIs are available for each of the different supporting services. These are represented by, but are not limited to, Data Carousel GUI 310a, NVOD GUI 310b, MSB GUI 310c, IPPA GUI 310d and Music GUI 310e.

A data carousel media server is a device that provides multiple streams of data, where each stream of data is identified by a process ID ("PID") and where each such stream stores or references data in a number of logical slots. The data carousel then cyclically cycles through the slots for each PID and transmits the data stored or referenced in those slots. A NVOD media server (Near Video On Demand) has the ability to retrieve and play a number of different videos on different channels. A MSB media server (Multi-Screen Browser) is a device that is designed to take a number of video streams, for example, a number of broadcast channels, and display them concurrently on one television screen. The screen may be divided into a number of windows, with each stream displayed in reduced format in a separate window. An IPPA media server (Internet Push Pull Agent) is a device that is connected to the Internet and can transmit information from a service such as Pointcast or can retrieve information from an Internet or internal site. A Music media server is a device that transmits music on one or more channels. These devices are only examples of different types of media servers that may be used in accordance with this invention and there are other types of devices such as channel management devices that may also be used.

Of course, scheduling these different services do not have to be through separate independent GUIs. In the preferred embodiment, these supporting services are accessible through a single master GUI, with additional details of each supporting service displayed as needed. The user creates the schedule using Service Specific GUI 110, which communicates with Master Scheduler 120 through Service/Master Scheduler API 170a.

Referring now to FIG. 3b, there is shown a more detailed diagram of Master Scheduler 120. In particular, Service Specific GUI 110 communicates with Table Manipulation Routines 330 to add and manipulate events, as needed, in the relevant data models. More specifically, the data pertaining to events for a particular service, primary or supporting, is stored in a set of tables. The set of tables for a particular service is called a data model, as exemplified by Data Models 320a-e. Each data model is generally tailored to specific service, although a single data model may be used for different services. For example, a data model for a data carousel service may require a specification of the loop cycle of the data carousel, number of slots and data storage size of slots. In such a case Data Carousel Data Model 320 may include data pertaining to the loop cycle of the data carousel, slots, data storage size of each slot and the data model may hold data and packet information. Of course, other information may be required or included in the tables, as determined by the needs of the service. In the preferred embodiment, the data models are object-based and an object-oriented database is used.

As an exemplary embodiment, there is shown Data Carousel Data Model 320a, NVOD Data Model 320b, MSB Data Model 320c, IPPA Data Model 320d and Music Data Model 320c, which correspond to different supporting services scheduled using Data Carousel GUI 310a, NVOD GUI 310b, MSB GUI 310c, IPPA GUI 310d and Music GUI 310e, respectively. It is not required, however, that each service has its own data model. In some instances where the services are similar, a single data model may be used for a number of different services.

Table Manipulation Routines 330 provide a means for Service Specific GUI 110 and other processes, such as System Scheduling Mechanisms 340, to create, store, retrieve and remove event data from the Data Models 320a-e (and any other data models). Usually there are different routines for different Data Models since the data tables tend to be different for each service and hence data model. In the preferred embodiment additional routines may be designed, constructed and added to Table Manipulation Routines 330 to provide increased flexibility and expandability in the system. Alternatively, the different routines may be simplified and abstracted at higher levels to provide a set of generic APIs to include in the Service/Master Scheduler API 170 to minimize the need to construct new and different routines for Table Manipulation Routines 330 for each Service Specific GUI 110.

Table 1, below, shows exemplary Table Manipulation Routines in the preferred embodiment which may be used to manipulate various data models.

    TABLE 1
    Routine                   Type    Comment
    Tmr_CreateDM              Generic Creates an instance of a data
                                      model
    Tmr_DefineDMTables        Generic Defines the set of tables of
                                      the data model
    Tmr_DefineTableField      Generic Adds a field to a table
                                      definition
    Tmr_CreateTableEntryInstance Generic Populates an entry into a data
                              and/or  model table.
                              Specific
    Tmr_ImportDMData          Generic Imports data from an external
                                      data model
    Tmr_ExportDMData          Generic Exports data model local data
    Tmr_DefineSched           Generic Schedule data may be spread
                                      across several tables. This
                                      routine creates a virtual
                                      schedule table. Note: It is
                                      possible to have different
                                      types of schedules within the
                                      same data model by defining
                                      different schedule tables.
    Tmr_DefineSchedField      Generic Defines a field to be added to
                                      a virtual schedule table.
    Tmr_CreateSchedInstance   Specific Populates an instance of a
                                      schedule table. This routine is
                                      specific to a data model.
    Tmr_TransSchedToTask      Specific Translates an instantiated and
                                      populated schedule
                                      into a task.
    Tmr_DistributeTask        Generic Distributes a task to a specific
                                      Task Scheduler or
                                      Media Server
    Tmr_MonitorSched          Generic Reports on the status of a
                                      particular schedule
    Tmr_SetTimer              Generic Sets a timer trigger
    Tmr_RemoveTimer           Generic Removes a timer trigger
    Tmr_RegisterEvent         Generic Creates a new event
    Tmr_RegisterEventInterest Generic Registers interest in a specific
                                      event.
    Tmr_LogEvent              Generic Logs the occurrence of
                                      a specific event.

    TABLE 2
                                  Return
    Message   Function  Fields    Value     Comments
    Ms_In-    Installs  IN:       msSUC-    The NotifySw [on, off]
    stallTask a task    MasterId  CEED      indicates whether the
              in a      SlaveId   msFAIL    slave should notify the
              slave     TaskId              status of the task
              schedular <noti-           whenever it changes
                        fySw>            state.
                        {task-           Specific task data is
                        Data}           transported by taskData
                                            and will vary depending
                                            on the type of task. E.g.
                                            time, date, asset list,
                                            operation, stream
                                            number.
                                            Note: Tasks that have
                                            expired (i.e. their
                                            execution time is past
                                            the current time) can
                                            not be installed.
    Ms.sub.--  Modifies  IN:       msSUC-    Specific task data is
    Modify-   the data  MasterId  CEED      transported by taskData
    Task      of a task SlaveId   msFAIL    and will vary depending
              installed TaskId              on the type of schedule.
              in a      {sched-           E.g. time, date, asset
              slave     Data}           list, operation, stream
              schedular                     number. It will replace
                                            the pre-existent task
                                            data.
    Ms_Re-    Removes   IN:       msSUC-    Removes taskId from
    moveTask  a task    masterId  CEED      the salve scheduler
              from a    slaveId   msFAIL    timeline. If the task has
              slave     taskId              expired in the slave it is
              scheduler                     automatically removed.
    Ms_Task-  Retrieves IN:       msSUC-    Retrieves a set of tasks
    Image     a list    masterId  CEED      from a task scheduler,
              of tasks  slaveId   msFAIL    including all the
              installed {taskId-           supporting data. Hence,
              in a      List}           {tasks} is composed of
              media     OUT:                tuples of the form
              server    {tasks}           [taskId, assetList,
                                            operator, time, data].
    Ms.sub.--  Monitor   IN:       msSUC-    This message instructs
    Monitor-  the status masterId  CEED      the slave to send a
    Task      of a task slaveId   msFAIL    notification every time
              executed  taskId              the state of taskId
              by a      <moni-           changes. E.g. when the
              slave     torSw>           task is inactive and
              scheduler                     changes to executing,
                                            when it finishes, if an
                                            when it encounters and
                                            error condition, etc.
                                            The monitorSw [on,
                                            off] turns monitoring on
                                            or off.
    Ms.sub.--  Monitor   IN:       msSUC-    Used to set a heartbeat
    Monitor-  the status masterId  CEED      every secs of time, to
    Slave     of a      slaveId   msFAIL    guarantee the sanity of a
              particular secs                slave scheduler. The
              slave     <moni-           monitorSw [on, off]
              schedular torSw>           turns monitoring on or
                                            off.
    Ss_Task-  Notifies  IN:       msSUC-    The new state of the
    Status    the       masterId  CEED      schedule is sent via
              Master    slaveId   msFAIL    taskStatus [installed,
              Schedular taskId              waiting, executing,
              about a   <task-           completed, removed,
              change    Status>           error1, . . . , errorN],
              in the    {status-           which indicates the new
              status of Data}           state just entered. The
              a task                        field statusData holds
                                            data resulting from the
                                            change of state of the
                                            schedule. E.g. a call
                                            collector returning
                                            billing information as a
                                            consequence of the
                                            completion of a call
                                            task.
    Ss_Heart- Notifies  IN:       msSUC-    The heartbeat message
    Beat      the       slaveId   CEED      is sent every time
              Master    masterID  msFAIL    period to the master,
              that the  <slave-           with a slaveStatus
              slave     Status>           [normal, alarm1, . . . ,
              schedular                     alarmN].
              is alive                      Note: The heartbeat is
              and well                      really a cross-tier
                                            function and should be
                                            an SNMP level service.
    Ss_Task-  Notifies  IN:       msSUC-    Schedule data may be
    Change    the       slaveId   CEED      changed manually,
              Master    masterId  msFAIL    which would create and
              Schedular taskId              inconsistency between
              about a   {task-           the slave and the
              change in Data}           master. This message
              the task                      notifies the master that
              data                          synchronization of the
                                            master and slave data is
                                            required, with taskData
                                            being the current data.
    Ms_Sync-  Synchro-  IN:       msSUC-    The syncTime is a
    Slave-    nizes     masterId  CEED      structure composed of
    Clock     the slave slaveId   msFAIL    the timeZone, date and
              scheduler syncTime            time, the latter
              clock with                     expressed in seconds.
              the                           The timeZone [GMT0,
              Master                        . . . , GMTN is used for
              Schedular                     locality. It is used to
              clock                         synchronize the clocks
                                            of the slaves with the
                                            master scheduler clock.
                                            Note: This is a soft
                                            clock sync function. A
                                            hardware clock sync is
                                            highly recommended as
                                            there is some inherent
                                            clock drift in this
                                            approach.
    Ss_Get-   Get a     IN:       msSUC-    Returns a syncTime
    Master-   clock     slaveId   CEED      structure containing the
    Clock     value     masterId  msFAIL    current master clock
              from the  OUT:                time.
              Master    syncTime            Note: This is a soft
              Scheduler                     clock sync function. A
              to syn-                       hardware clock sync is
              chronize                      highly recommended as
              the local                     there is some inherent
              slave                         clock drift in this
              clock                         approach.
    Ms_Con-   Issues    slaveId   msSUC-    Control of specific
    trolSlave a         masterId  CEED      features of slave devices
              control   {slave- msFAIL    may demand control
              instruc-  Control}           calls that are specific to
              tion                          the slave device. E.g. a
              specific                      NVOD server may
              to a                          require an emergency
              slave                         procedure to restart the
              device                        system or change output
                                            ports for a stream. A
                                            series of
                                            Ms_ControlSlave
                                            messages containing
                                            slaveControl
                                            instructions (specific to
                                            a slave device) can
                                            achieve such specific
                                            need.
                                            Note: This API
                                            message is used to code
                                            emergency procedures
                                            and specific setup and
                                            teardown procedures
                                            (such as initialization)
                                            for the specific devices.
    .cndot. {and} denote a list of items.
    .cndot. <and> denote an enumerated set of values.
    .cndot. The suffix Sw denotes a variable used as a switch with values [on,
     off].
    .cndot. Ids are 64-bit integers.
    .cndot. A prefix of Ms (for Master Scheduler) indicates messages flowing
     from the Master Scheduler towards a Slave Task Scheduler.
    .cndot. A prefix of Ss (for Slave Scheduler) indicates messages flowing
     from the Slave Task Scheduler to the Master Scheduler.

    TABLE 3
    MES-      FUNC-               RETURN
    SAGE      TION      FIELDS    VALUE     COMMENTS
    Tt_Task-  Initialize OUT:      TtSUC-    Initializes Task
    Init      the Task  OpStatus  CEED      Translation Layer 420
              Trans-              ttFAIL    and the Media Server
              lation                        controlled by it.
              Layer                         OpStatus conveys the
              and the                       result of the
              device                        initialization procedure.
    Tt_Task   Execute a IN:       TtSUC-    taskId identifies a task
              task      TaskId    CEED      that is to be executed
                        <asset.sub.--  TtFAIL    immediately.
                        list>            <asset_list> denotes a
                        operator            list of physical names.
                        <op.sub.--            In the NVOD server
                        spec.sub.--            case, <asset_list> is
                        data>            equivalent to play list.
                        OUT:                <op_spec_data> is a
                        OpStatus            variable length list used
                                            to transport device
                                            dependent information
                                            necessary to carry out
                                            the operation. The valid
                                            values for operator are
                                            (in the NVOD server
                                            case): ttPLAY,
                                            ttPAUSE, ttABORT.
    Ms_Task-  Callback  IN:       TtSUC-    status has one of the
    Status    returning TaskId    CEED      following values:
              a task    Status    TtFAIL    ttLOADED,
              status    StatusText           ttEXECUTING,
                        OUT:                ttCOMPLETED,
                        OpStatus            ttERROR. StatusText
                                            is used to further specify
                                            the nature of error.

• Inventors
  Sequeira, William J.;
• Assignee
  Corporate Media Partners (Los Angeles, CA)
• Published
  Apr-24-2001
• Current US Classes:
  715/500.1
• Application #
  137618
• International Classes
  H04N 007/173
• Field of Search
  709/217 709/218 709/219 345/327 345/302 348/906 348/722 348/7 348/9 348/6 348/12 348/13 348/10 348/907 455/6.2 455/6.3 455/5.1 455/6.1
• Examiner
  Grant; Chris
• Agent
  Brown Raysman Millstein Felder & Steiner LLP
• US Patent References:
  5027400
  5099319
  5499046