Abstract:
A method and apparatus are provided for playback conflict detection. In one embodiment, the invention determines a time interval for the playback of the isosynchronous data object, said time interval including both a beginning time and a duration, and determines whether any calendar event falls at least partially within the time interval for playback. The invention may be initiated by opening the isosynchronous data object for playback. The user who requested the playback will be notified of any potential conflict between the complete playback of the data object and any events scheduled on the user&#39;s electronic calendar.

Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates to a data processing system capable of playing multimedia presentations and relates more particularly to a data processing system that warns a user that the complete playback of a multimedia presentation will conflict with an upcoming calendar event. 
     2. Description of the Related Art 
     A data processing system may be capable of playing back, or displaying, multimedia presentations that may contain motion video or audio data. Such multimedia presentations are isosynchronous in nature; that is, timing characteristics are the basis for conveying information. For example, motion video may be optimally presented by presenting individual video frames in a particular order and at a particular rate of frames per unit of time. Similarly, audio, such as recorded or synthesized speech and recorded or synthesized music, may be optimally presented at a particular rate. Such multimedia presentations may be contrasted with, for example, graphical data or, ordinarily, textual information, whose rate of presentation to a human user of the data processing system is not normally significant. Under certain circumstances, however, even text can be considered isosynchronous, as where a text-to-speech process is used to convert the text to spoken audio speech. Similarly, if the text is presented to the user by scrolling it across a display screen, the scrolling rate, which may be measured in characters or in lines per unit of time, give the presentation of the text isosynchronous properties. 
     The optimal rate of presentation of the information in an object that contains isosynchronous data gives that object an optimal playback duration, which may be expressed in time. Some multimedia objects expressly state their duration; for example, the directory structure of audio compact discs may state the time duration of individual tracks. An isosynchronous data object differs in this manner from a non-isosynchronous data object such as a graphical image file--while both objects typically have a file size, which may be expressed in bytes, only the isosynchronous object also has a time duration, which may be expressed in seconds, minutes or hours or the like. 
     A data processing system may include an electronic calendar application which allows the user to maintain a schedule of upcoming events of interest to him. Calendar events may have a start time, a stop time and a duration. When adding a new event to a calendar, the calendar application may check the existing calendar events for any events that conflict in time with the event to be added. However, data processing systems, even those that include calendar applications, do not notify a user that a scheduled calendar event will conflict with the complete playback of an isosynchronous data object. Thus, there is a need for a data processing system that notifies a user that a scheduled calendar event will conflict with the complete playback of an isosynchronous data object. 
     SUMMARY OF THE INVENTION 
     In accordance with the invention, a method and apparatus are provided for playback conflict detection. In one embodiment, the invention determines a time interval for the playback of the isosynchronous data object, said time interval including both a beginning time and a duration, and determines whether any calendar event falls at least partially within the time interval for playback. The invention may be initiated by opening the isosynchronous data object for playback. The user who requested the playback will be notified of any potential conflict between the complete playback of the data object and any events scheduled on the user&#39;s electronic calendar. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objects and advantages thereof, will best be understood by reference to the following detailed description of an illustrative detailed embodiment when read in conjunction with the accompanying drawings, wherein: 
     FIG. 1 is a block diagram of an apparatus used in performing the method of a preferred embodiment of the present invention and forming a part of the apparatus of a preferred embodiment of the present invention; 
     FIG. 2 is a block diagram illustrating the method of a preferred embodiment of the present invention; 
     FIG. 3 is a high level logic flowchart illustrating the registration process of the preferred embodiment of the method of the present invention; 
     FIG. 4 is a high level logic flowchart illustrating the incoming reception process of the preferred embodiment of the method of the present invention; and 
     FIG. 5 is a high level logic flowchart illustrating the invocation process of the preferred embodiment of the method of the present invention. 
     While the invention will be described in connection with a preferred embodiment, it will be understood that the description is not intended to limit the invention to that embodiment. On the contrary, the invention is intended to cover all alternatives, modifications and equivalents as may be included within the spirit and scope of the invention as described by the appended claims. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
     With reference now to the Figures, and in particular with reference to FIG. 1, there is shown, in block diagram form, an apparatus according to the present invention. The apparatus includes a data processing system 100. The data processing system 100 includes a processor 102, which includes a central processing unit (CPU) 104 and memory 106. Additional memory, such as a hard disk file storage 108 and a floppy disk device 110 may be connected to the processor 102. Floppy disk device 110 may write to or read from a removable diskette 112 which may have computer program code recorded thereon that implements portions of the present invention in the data processing system 100. Inputs may also be received from a fax/modem 114, which is connected to a telephone line 116, and from a microphone 124. The data processing system 100 also includes user interface hardware, such as a mouse 120, a keyboard 122 and a scanner 118, for allowing user input to the processor 102. The data processing system 100 also includes visual display devices, such as a monochrome or color display monitor 126 and a monochrome or color display printer 128, for rendering visual information. The data processing system may also include an audio display device, such as a speaker 130 for rendering audio information. A telephone 132 may be connected to the telephone line 116 through the fax/modem 114. 
     With reference now to FIG. 2, there is depicted a block diagram which illustrates the method of a preferred embodiment of the present invention for playback conflict detection and resolution. The process begins at block 200 upon the initiation of the sending of an isosynchronous data object by a human user called a sender. The data processing system presents the sender with a distribution interface that offers the sender the option of assigning a time duration to the isosynchronous data object. After the option is accepted or rejected, the process proceeds to block 205 and processes the sender&#39;s request to distribute the object to one or more recipients, as specified by the sender. The process then proceeds to optional block 210, where an elapser of the data processing system determines the time duration of the isosynchronous data object. 
     The elapser of block 210 may use different processes to determine the time duration necessary for the object to be completely conveyed. The elapser may playback the object and measure the elapsed time required. It may compute the duration of a motion video object by applying the frame display rate to the number of frames of the object, which number may be either supplied by the object or counted by the elapser. It may estimate the duration of a text object by applying a specified transfer rate to the number of words or even the number of bytes, if the text is to be converted to speech or visually displayed by scrolling. The elapser of block 210 associates the time duration to the isosynchronous data object before forwarding it to the specified recipients, unless a time duration is already associated to the object, as by block 200 above, or unless the use of an elapser is not offered or elected during the sending process. 
     The process now proceeds to block 220, which, together with the remainder of FIG. 2, illustrates the process as it operates on behalf of the recipient of the isosynchronous data object. The object is received in the recipient&#39;s inbasket, block 220, where it is monitored by the inbasket monitor, block 225. The inbasket monitor analyzes incoming objects to ascertain whether the incoming objects should be checked for playback conflict detection. The inbasket monitor checks the types of incoming objects to determine whether they are isosynchronous object types such as motion video or audio, as illustrated by block 230. All isosynchronous object types will be registered with association table 240. 
     The inbasket monitor also checks other, user configurable characteristics of incoming objects that are determined to be isosynchronous, as illustrated by event selector block 235. These characteristics determine whether an isosynchronous object to be registered in the association table 240 will be marked for conflict resolution or not. Such characteristics monitored may include the sender&#39;s identity, keywords in the object&#39;s subject field, abstract or body, or the object&#39;s classification as &#34;important,&#34; &#34;urgent,&#34; &#34;personal,&#34; &#34;private,&#34; or the like. 
     Incoming objects that meet the inbasket monitor&#39;s criteria create event record entries in the association table 240. Each record contains a pointer to the incoming object in the inbasket and the time duration of the object. The time duration may be derived from that associated with the object during the send process of blocks 200-210, if present. Alternatively, the time duration may be derived by an elapser 245, which is similar to elapser 210 described above. Elapser 245 may optionally be used to modify or confirm a duration previously associated with an isosynchronous data object, or to conform the duration to differing user display rate preferences or to different data processing system hardware display rate capabilities. 
     Registration service 250 is also provided to permit user configuration of the operation of the inbasket monitor 225, as described above, through the use of user registration interface 255. The user may configure the object types to be monitored, as illustrated by block 235 above, for example choosing to include text objects for scrolling display or text-to-speech conversion. The user may also optionally enter object classifications or keywords to be monitored, as illustrated by block 230 above. The user may also configure the elapser 245 to enable calculation of durations from application of estimated display rates to incoming objects, or alternatively, require that such objects be played and their playing times measured, called preplaying. 
     Notification service 260 is activated by user input to the user interface 265, as by the opening of an inbasket item for display to the user. Upon the user&#39;s specification of the inbasket item to be opened, the notification service 260 checks the association table 240 to determine whether that object is registered in the association table 240. If so, the process accesses the calendar service 275 so as to have access to the user&#39;s calendar events. The process then returns to the association table 240 to determine whether the object is of the event type registered for conflict. If so, the process retrieves the object&#39;s duration from the association table 240, retrieves the current time from timer service 270, and compares them to the user&#39;s calendar events of calendar service 275 to determine whether the immediate playback of the isosynchronous data object will present a conflict with a scheduled calendar event on the user&#39;s calendar. If so, the process notifies the user of the conflict through user interface 265 and allows the user to abort the playback of the isosynchronous data object. If the playback is aborted, the process terminates; otherwise, the process returns control of the playback to the data processing system&#39;s normal inbasket services. 
     Turning now to FIG. 3, there is shown a high level flowchart of the registration pro(less illustrated by blocks 250 and 255 of FIG. 2. The registration process commences at block 300 when the user makes a registration request. The process proceeds to block 305 for input of whether the process should notify the user of conflicts only for certain selected event types. If so, the process proceeds to block 310 for the input of specific events for conflict notification. As discussed above, such events may include the existence, in an isosynchronous data object, of characteristics such as the sender&#39;s identity, keywords in the object&#39;s subject field, abstract or body, or the object&#39;s classification as &#34;important,&#34; &#34;urgent,&#34; &#34;personal,&#34; &#34;private,&#34; or the like. 
     After the input of such characteristics, the process proceeds to block 320 and registers such characteristics as events requiring conflict resolution. Returning to block 310, if conflict notification only upon selected events is not elected, the process proceeds to block 315 and selects all events for conflict notification. 
     The process proceeds from block 320 to block 325 for the input of specific object types that activate notification. This permits the user to specify whether certain object types, such as text objects, shall be treated as isosynchronous. Text objects may be isosynchronous if they are displayed to the user by scrolling or by text-to-speech conversion, whereas a text object to be printed would not ordinarily be treated as isosynchronous. The registration process then proceeds to block 330 to register the object types, and then terminates. 
     Turning next to FIG. 4, there is shown a high level flowchart of the incoming reception process illustrated by blocks 220 through 245 of FIG. 2. This process begins at block 400 upon the receipt of a data object by inbasket 220. The process then proceeds to block 405 for a determination of whether the object is of a registered type and characteristic. If not, the process terminates. If so, the process proceeds to block 410 for a determination of whether the object has a duration time already specified. If not, the process proceeds to block 415, accesses the user profile, and proceeds to block 420 for a determination of whether the user profile permits calculation of duration from an estimate. 
     If calculation of a duration from an estimate is permitted, the process retrieves a display rate from the user profile and applies it to a length of the isosynchronous data object, such as the number of frames of a motion video object, to compute a duration. The process then proceeds to block 435 to register the duration time in the association table 240, and then terminates. 
     Returning to block 420, if calculation of duration from estimate is not permitted, the process preplays the isosynchronous data object and measures its actual duration. The process then proceeds to block 435, records the actual duration in the association table, and terminates. 
     Returning to block 410, if the isosynchronous data object already has a duration time specified, the process proceeds from block 410 to block 435 and records the specified duration time in the association table and then terminates. 
     Turning next to FIG. 5, there is shown a high level flowchart of the invocation process illustrated by blocks 260 through 275 of FIG. 2. The process commences at block 500 upon the data processing system&#39;s receipt of a request from a user to open an object in the user&#39;s inbasket for display to the user. The process then proceeds to block 505 for a determination of whether the inbasket object is registered in the association table 240 as an isosynchronous type. If yes, the process proceeds to block 510 and accesses the calendar service to access the user&#39;s calendar events. The process then proceeds to block 515 for a determination of whether the inbasket object has an event characteristic registered for conflict. If yes, the process proceeds to block 520, accesses the present time from the timer service 270, and, using the isosynchronous data object&#39;s duration from the association table 240, determines whether the user&#39;s calendar events accessed in block 510 above present an imminent time conflict. 
     Stated otherwise, the process determines at block 520 whether the playback duration of the isosynchronous data event, beginning at the current: time, will overlap or present a conflict with any calendar event on the user&#39;s calendar. If a conflict is detected, the process proceeds to block 525, notifies the user of the conflict, proceeds to block 530 and determines whether the user still wishes to open the isosynchronous data object for immediate playback. If not, the process terminates. If so, the process proceeds to block 535 and returns control of the playback request to the normal inbasket display service of the data processing system. The process then terminates. 
     Returning to block 505, if the object is not a registered isosynchronous data type, the process proceeds to block 535 and returns control of the playback request to the normal inbasket display service of the data processing system. The process then terminates. 
     Returning to block 515, if the object is not a registered event type for conflict resolution, the process proceeds to block 535 and returns control of the playback request to the normal inbasket display service of the data processing system. The process then terminates. 
     Returning to block 520, if no imminent conflict is detected, the process proceeds to block 535 and returns control of the playback request to the normal inbasket display service of the data processing system. The process then terminates. 
     While the invention has been particularly shown and described with reference to a preferred embodiment and process, it will be understood that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.