The present invention is related to U.S. Pat. No. 6,640,230, titled “Calendar-Drive Application Technique for Preparing Responses to Incoming Events” (Ser. No. 09/671,001), filed concurrently herewith. This related invention is commonly assigned to International Business Machines Corporation (IBM), and is hereby incorporated herein by reference.
1. Field of the Invention
The present invention relates to a computer system, and deals more particularly with a method, system, and computer program product for defining calendar events for users of computer systems and using those calendar events to customize information pertaining to the user.
2. Description of the Related Art
Calendars, and electronic calendars in particular, often contain a wealth of information about their owner. For example, an individual may use an electronic calendar to maintain information about his work schedule, his meetings and other appointments, his vacation and business travel plans (including when he will be away, which flights or other transportation he will use, where he can be reached while away, who he may visit while away, etc.), phone calls that need to be made at particular times, and so forth. Examples of electronic calendaring systems include Microsoft Outlook® 2000 and Lotus Organizer®, which also allows a user to create entries on his calendar for other people. For example, a secretary might have calendar entries for his own schedule, but also keep information about his manager's appointments on his own calendar as well. Such systems are quite popular among users. (“Outlook” is a registered trademark of Microsoft Corporation, and “Lotus Organizer” is a registered trademark of Lotus Development Corporation.)
Use of electronic calendaring systems for purposes such as scheduling meetings of multiple persons is known in the art. For example, an invitation list may be created for a particular meeting, and a calendaring software application may then use this list to check each invitee's calendar for available time periods. A meeting may then be scheduled during a time period in which all (or some majority) of the invitees have sufficient time available on their calendar. However, it is desirable to more fully exploit the information stored in the calendaring system.
As an example, electronic calendar-based engines could be used to drive other software applications and agents, such as e-mail out-of-office agents which would provide automated responses to e-mail informing a sender that the recipient is currently away. Many facilities exist today with which users can configure their e-mail systems to respond with various forms of “I am away” messages, but these facilities require manual intervention by the user. Typically, the user selects a configuration action for his e-mail account and enters information (such as a text string) that he would like to have sent in an automated response upon receipt of incoming e-mail. A time period during which this automated response should be used may be entered; alternatively, the automated response may remain active until the user resets the configuration information for his account. Manual techniques such as these tend to be tedious for the user, especially if the user is frequently away and needs to repeat this configuration process often. Such techniques also tend to become out of date or out of synchronization with the user's actual status, as the user may forget to change his settings or may simply choose not to change them. It may be difficult for some users to change their status once they have left their office as well, as they may no longer have access to the necessary systems. The more tedious it is for the user to change his configuration settings, the more likely it is that he will choose to let them become out of synchronization with his status. This leads to the undesirable situation where it appears that the user is available and checking his e-mail—and may therefore be expected to reply quickly to messages—when in fact he is not.
U.S. Pat. No. 5,428,784, which is entitled “Method and Apparatus for Linking Electronic Mail and an Electronic Calendar to Provide a Dynamic Response to an Electronic Mail Message” discloses a technique for automatically responding to a received e-mail message using information stored in the addressee's electronic calendar. When an e-mail message is received, its receipt time is compared to the addressee's electronic calendar to see if any events are currently scheduled. If so, various types of information regarding the scheduled event (such as the start and stop time and what the event comprises) may be returned as a response to the e-mail sender so that the sender can determine whether the addressee is likely to be viewing his e-mail at the present time. If the user's calendar indicates that he is currently in a meeting or on vacation, for example, it is unlikely that the sender's mail will be read promptly. If the sender needs an immediate response to his e-mail message, the sender can evaluate the automated response to decide whether to try some other source of information. However, no automated technique for determining these alternative information sources is disclosed. Furthermore, no technique is disclosed for evaluating an electronic calendar for future user availability.
Voice mail systems are also typically manually configured, with the user recording a greeting change each time he is away from the office and again when he returns. As discussed above with reference to manually configuring e-mail systems, the process of manually changing voice mail greetings is especially tedious for those users who need to make changes often, such as those who travel frequently, who attend many off-site meetings or somewhat lengthy meetings, so forth. Most business people are familiar with the scenario of calling someone's office and receiving a recorded voice mail message indicating that the callee is away but will return on some particular date, where that date has long since passed.
In addition to the problem of not fully exploiting the information available on an electronic calendar, some existing electronic calendars may be difficult for others to visually inspect. That is, when a calendar owner has many events scheduled, it may be rather difficult for a human reader to determine exactly where that calendar owner is at a particular point in time. Furthermore, it may be quite difficult to determine how to contact the calendar owner at a point in time by visually reviewing his calendar, as the means of contact may vary widely if the owner is in different places throughout the day.
Accordingly, a need exists for a technique which enables calendar-driven personal assistant applications to better serve their users. This technique should take into account the context in which calendar events and calendar information have been created, and use this information in an automated manner to dynamically determine a calendar owner's availability (and/or other information) and dynamically generate an automated response.
An object of the present invention is to provide a technique which enables electronic calendar-driven personal assistant applications to better serve their users by analyzing the calendar events and calendar information.
Another object of the present invention is to provide a technique which enables automated, dynamic generation of responses to attempts to contact a calendar owner.
It is a further object of the present invention to provide this technique by defining different levels in a hierarchy of calendar events.
Yet another object of the present invention is to enable users to set default preferences for events in the calendar hierarchy.
Still another object of the present invention is to enable users to override the default preferences for one or more particular calendar events in the calendar hierarchy.
A further object of the present invention is to provide a technique for using electronic calendar events in project management applications.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides a system, method, and computer program product for providing an electronic calendar-driven application. This technique comprises: creating calendar events on an electronic calendar, the calendar events being organized according to a multi-level hierarchy comprising context events at an upper level of the hierarchy and specific events at a lower level of the hierarchy, wherein zero or more specific events may be scheduled on the electronic calendar during any particular context event; and interrogating the calendar events (either context events, specific events, or both context and specific events) created for a user to provide information about the user at a point in time or for a period of time.
The technique may further comprise automatically applying a default context during calendar periods when no other context event is active.
In one aspect, the technique further comprises detecting an incoming electronic mail message for the user, in which case the interrogation further comprises determining whether the user's calendar indicates that he is currently available for checking his electronic mail (e.g. whether he is in the office), and if not, generating an automated response informing a sender of the electronic mail message of the user's current status using a currently-active context event for the user and, for particular context events, any currently-active specific event for the user.
In a further aspect, the technique further comprises detecting an incoming instant message or request for instant messaging status for the user, in which case the interrogation further comprises determining whether the user's calendar indicates that he is currently available for instant messages, and if not, generating an automated response informing a sender of the instant message or requester of the instant messaging status of the user's current status using a currently-active context event for the user and, for particular context events, any currently-active specific event for the user.
In another aspect, the technique further comprises detecting an incoming voice call for the user, and the interrogation further comprises generating, if the user does not answer the incoming voice call, an automated response informing a caller making the incoming voice call of the user's current status using a currently-active context event for the user and, for particular context events, any currently-active specific event for the user.
In these aspects, the automated responses may further comprise information regarding when the user is next available.
In yet another aspect, the technique further comprises receiving a request for project or resource management information. In this aspect, the interrogation may interrogate the calendar events created for a plurality of users to provide information about the context events and specific events scheduled for the users at a target date and a target time period, and further comprises generating a response informing a requester of the project management information of the information for the users using a result of the interrogation. The request may ask whether any team member is available at a particular location during a particular time period on a particular date.
Zero or more attribute values may be specified for each of the context events and each of the specific events. In this case, the interrogation may further comprise interrogating the specified attributes of a currently-applicable context event and of any currently-applicable specific event. The interrogation performed in the various aspects may then further comprise using the specified attributes of the currently-applicable context event and the specified attributes of any currently-applicable specific event.
Default attribute values may be specified for context event types and for specific event types, in which case a particular context event and/or a particular specific event may include attribute values which override the default attribute values.
Attribute values may include information on how to immediately contact the user; an alternative contact person for the user; whether, and how often, the user checks electronic mail messages; whether and when the user is available for instant messaging; and whether, and how often, the user checks voice mail messages.
The present invention will now be described with reference to the following drawings, in which like reference numbers denote the same element throughout.
The workstation 10 may communicate with other computers or networks of computers, for example via a communications channel or modem 32. Alternatively, the workstation 10 may communicate using a wireless interface at 32, such as a CDPD (cellular digital packet data) card. The workstation 10 may be associated with such other computers in a local area network (LAN) or a wide area network (WAN), or the workstation 10 can be a client in a client/server arrangement with another computer, etc. All of these configurations, as well as the appropriate communications hardware and software, are known in the art.
Still referring to
The gateway computer 46 may also be coupled 49 to a storage device (such as data repository 48). Further, the gateway 46 may be directly or indirectly coupled to one or more workstations 10 and other devices such as those shown at elements 8 and 9.
Those skilled in the art will appreciate that the gateway computer 46 may be located a great geographic distance from the network 42, and similarly, the workstations 10 and other devices 8, 9, 11 may be located a substantial distance from the networks 42 and 44. For example, the network 42 may be located in California, while the gateway 46 may be located in Texas, and one or more of the workstations 10 may be located in New York. The workstations 10 and other devices such as those shown at elements 8 and 9 may connect to the wireless network 42 using a networking protocol such as the Transmission Control Protocol/Internet Protocol (“TCP/IP”), AppleTalk®, a particular wireless networking protocol (such as the Wireless Application Protocol, or “WAP”, the Global System for Mobile communications, or “GSM”, etc.), or the Systems Network Architecture (“SNA”) over a number of alternative connection media, such as cellular phone, radio frequency networks, satellite networks, etc. (“AppleTalk” is a registered trademark of Apple Computer, Inc.) The wireless network 42 preferably connects to the gateway 46 using a network connection 50a such as TCP or UDP (User Datagram Protocol) over IP, X.25, Frame Relay, ISDN (Integrated Services Digital Network), PSTN (Public Switched Telephone Network), etc. The workstations 10 may alternatively connect directly to the gateway 46 using dial connections 50b or 50c. Further, the wireless network 42 and network 44 may connect to one or more other networks (not shown), in an analogous manner to that depicted in
Software programming code which embodies the present invention is typically accessed by the microprocessor 12 of the workstation 10, other device such as those shown at 8 and 9, and/or server 47 from long-term storage media 30 of some type, such as a CD-ROM drive or hard drive. The software programming code may be embodied on any of a variety of known media for use with a data processing system, such as a diskette, hard drive, or CD-ROM. The code may be distributed on such media, or may be distributed from the memory or storage of one computer system over a network of some type to other computer systems for use by such other systems. Alternatively, the programming code may be embodied in the memory 28, and accessed by the microprocessor 12 using the bus 14. Furthermore, networked storage (including storage area networks and network-attached storage) may also be used. The techniques and methods for embodying software programming code in memory, on physical media, and/or distributing software code via networks are well known and will not be further discussed herein.
A user of the present invention may connect his computing device to a server using a wired connection, or a wireless connection. Wired connections are those that use physical media such as cables and telephone lines, whereas wireless connections use media such as satellite links, radio frequency waves, and infrared waves. Many connection techniques can be used with these various media, such as: using the computer's modem to establish a connection over a telephone line; using a LAN card such as Token Ring or Ethernet; using a cellular modem to establish a wireless connection; etc. The user's computing device may be any type of computer processor, including laptop, handheld or mobile computers; vehicle-mounted devices; desktop computers; mainframe computers; etc., having processing and communication capabilities. The features of the present invention may also be accessed by users who are not using computing devices, but instead are using devices such as conventional telephone 11 (as will be described). The remote server, similarly, can be one of any number of different types of computer which have processing and communication capabilities. These techniques are well known in the art, and the hardware devices and software which enable their use are readily available.
In the preferred embodiments, the present invention is implemented as one or more modules (also referred to as code subroutines, or “objects” in object-oriented programming) of a computer software program (or programs). The program code of the preferred embodiments may be implemented as objects in an object-oriented programming language, or in a conventional procedurally-oriented language, or in a mix of object-oriented and procedural language code. The code for addition of calendar entries (as well as for setting preferences and so forth) preferably operates on a workstation or other user device, or may operate on a server if the workstation is simply presenting a user interface. Other portions of the code (which analyze calendar entries, generate automated responses, etc., as will be described herein) preferably operate on one or more servers.
With sufficiently detailed calendar entries, the prior art problems previously described (difficulty of visually inspecting electronic calendar entries to determine a person's current status, the tedious and error-prone nature of e-mail and voice mail systems which require manual revision each time a user's status changes, etc.) can be overcome through use of software applications which evaluate a user's calendar; determine the calendar owner's status at a point in time (such as out of the office, in the office and available, in the office but attending a meeting, etc.); automatically provide dynamically-generated information based on this status (for example, upon receiving incoming e-mail, instant messages, or voice mail for the calendar owner, or receiving a request for information such as that used in project management or resource management scenarios), including information about how to most immediately contact the owner of the calendar; and dynamically triggering changes to the calendar owner's status, all without manual intervention. These functions may be referred to collectively as “personal assistant applications”. No existing prior art techniques are known to the inventors which overcome these problems and provide these functions efficiently and effectively, without manual intervention.
Personal assistant applications need to recognize that users' capabilities, needs, and behaviors change depending on where they are, what devices they have access to, and what their main purpose is in being there. For example, if a user is away from the office on a trip, whether or not that user can be contacted by e-mail (or telephone, pager, cellular phone, instant messaging, etc.) may depend on a number of factors including whether the trip is for vacation or business purposes. No existing prior art personal assistant applications nor calendaring applications are known to the inventors which consider such factors in an automated manner and determine how (or if) it is possible to interact with a particular user at a point in time. Personal assistant applications also need to be able to deal with time periods in which multiple concurrent events are listed on a user's electronic calendar, such as determining what action to take for a user whose calendar indicates that he is (1) away from the office on business but is (2) scheduled to participate in a meeting or teleconference. (For example, it may be that the user intends to participate in a meeting from his remote location if that meeting does not require his in-person attendance.)
The present invention provides an improved technique for defining calendar events and for using those events to customize information pertaining to the calendar owner. The present invention provides for automatically and dynamically deducing a calendar owner's status and associated information from his electronic calendar, and using that deduced status and associated information to dynamically generate an automated response to an attempt to contact the calendar owner. This information may be determined when an event occurs (such as an incoming phone call, e-mail message, or instant message), or alternatively it may be determined a priori and stored for use upon occurrence of such an event. In some cases (such as for an incoming phone call), the automated response may provide for forwarding the incoming event to a designated alternate contact. (Note that while the preferred embodiments are described herein primarily in terms of responding to attempts to contact the calendar owner, this is for purposes of illustration and not of limitation. The present invention may also be used advantageously for other purposes and in other scenarios.)
The present invention introduces the concept of a hierarchy of events into electronic calendaring systems. In the preferred embodiments, a 2-level hierarchy is defined. This 2-level hierarchy enables personal assistant applications to automatically account for a user's capabilities, needs, and behavior changes based on (inter alia) where the user happens to be at a point in time, what devices the user has access to, and when the user is away from the office, his current activity or the purpose for his being away.
The top level of the hierarchy is referred to herein as the “context level”, and events entered at this level are referred to as “context events”. The lower level is referred to as the “specific level”, and events at this level are referred to as “specific events”. Events which are created as context events are, by convention, typically longer in nature than specific events. Examples of context events include:
A default context may be used which is not required to be explicitly entered as a calendar event. For example, “in the office” may be used as a default context. If a user's normal work schedule is known to the calendaring system, the context event “outside normal working hours” may be deduced and therefore does not need to be explicitly calendared. Thus, the entries on a user's calendar will typically represent exceptions to some currently-applicable default context.
Optionally, context events may be logically grouped into categories. In the preferred embodiments, for example, context events such as “in the office”, “working at home”, “working at alternate location”, and “business trip” (which are all categories of “working”) comprise one logical group, while other context events such as “outside normal working hours”, “vacation”, “holiday”, etc. (which are all categories of “not working”) comprise a separate category. The significance of this type of grouping will be discussed in more detail below. As an alternative to using logical grouping, an additional upper layer in the hierarchy may be defined to explicitly provide this type of grouping.
Information relating to the user's capabilities, needs, and behaviors can differ depending on the user's current context. According to the present invention, this information is stored as attributes (referred to equivalently herein as preferences or characteristics) of a particular context event. Examples of attributes include:
Values of these different types of attributes may be specified as system-wide defaults; as user-specific preferences that the user enters into his calendar-driven personal assistant application; by explicit data that is entered (for example, using keywords) on the calendar entry itself for a particular context event; and/or using other techniques for specifying attribute values that are well known to one of skill in the art.
Note that in some cases, when an attribute indicates that a user is reachable using a particular type of device, it may be possible to dynamically determine whether that device is currently active and available (for example, by working with the carrier). Techniques for making this dynamic determination are outside the scope of the present invention.
Specific events occur within a context defined by an explicit or inferred context event, and may be considered as overriding or refining that context event. Specific events are therefore typically shorter in duration than context events. For example, if the user's context between 8 a.m. and 5 p.m. on a particular day is “in the office”, a meeting may be scheduled on the user's electronic calendar as a specific event from 9 a.m. to 10 a.m. within that context. Examples of specific events include:
Specific events may also have associated attributes. The types of information entered as specific event attributes may have semantics similar to, or different from, context event attributes. For example, if a user's context is “vacation”, an attribute for this context may be that the user is not checking voice mail or e-mail. The user may be participating in an electronic meeting (or perhaps a teleconference) during his vacation, however, which can be scheduled as a specific event using the present invention. The attributes for the specific event may then specify that the user will be checking his e-mail during the time period of the electronic meeting, or perhaps will check his voice mail before or after the teleconference, etc.
Attributes may be defined which pertain only to context events, only to specific events, or to either context events or specific events. When an attribute is defined as pertaining to both specific events and to context events, the values which are applicable at a point in time are coalesced to provide a result. In the examples which have been described above (of checking e-mail and checking voice mail, where the context event is “on vacation” and the specific event is “attending an electronic meeting” or “participating in a teleconference”), checking e-mail and checking voice mail are preferably defined as the latter type of attribute, enabling the attribute value for a particular specific event to automatically override the value of that attribute for the context event which is applicable at a point in time. In the preferred embodiments, default values may be specified for context and specific event attributes, and these default values may optionally be explicitly overridden for a particular instance of that context or specific event (e.g. when the calendar owner schedules an event on his calendar). Use of attributes, including default and overridden values, will be described in more detail below. (Attribute values for specific events may be specified in a similar manner to that described above for context event attribute values.)
By recognizing and reacting to this hierarchy of events, calendar-driven personal assistant applications can better serve their users by providing and using information associated with the context and specific events. For example, the manner in which a calendar owner can be most immediately contacted may be defined as an attribute of context and specific events. In this case, information on how to contact a calendar owner can be provided as an attribute value for a particular context event, and different contact information may be provided as an attribute value for a specific event occurring within the time period of the context event. By understanding the hierarchy of event types, the application can automatically adapt to switch to using the specific event contact information for the duration of that event and then switch back to using the context event contact information. Attributes defined as pertaining only to a specific event are used in addition to, and not to override, any attributes defined as pertaining to context events. Similarly, attributes defined as pertaining only to a context event do not need to be coalesced with attribute values of specific events. As an example of this situation, suppose an employee is traveling on business for an extended period of time. A context-only event attribute may be set to indicate where the employee's hard-copy mail should be delivered while this context event is active. It is unlikely that such an attribute will be meaningful for the relatively short duration of specific events, and thus the hard-copy mail attribute may be one element of the employee's status that has no corresponding specific event attribute.
It may also be useful to evaluate the calendar events from the multiple levels of the hierarchy in isolation, rather than as a coalesced result. Suppose, for example, that an employee wishes to know when her manager is out of the office during a particular week. The employee may be uninterested in why the manager is out, or what the manager is doing while away. In this example, it is preferable to provide the employee only with information from the context level of the hierarchy and omit information from the specific level. As another example, it may be desirable to generate reports providing information about how much time a company's employees spend on personal business, attending in-person meetings, or in other activities which may be identified as specific events. In this case, the context level information is not relevant to the report generation. Furthermore, there may be situations where it is useful to evaluate context and/or specific events based upon values of their associated attributes. As an example, context and specific events and their attributes may be evaluated to determine when a group of calendar owners have their pagers or cellular phones active; this information may then be useful in determining system costs and/or processing demands. There may also be security or privacy reasons for providing less detailed information. (Security or privacy concerns may also be used as a factor in the amount of detail provided to others regarding particular context and/or specific events on a user's calendar.)
As one example of an alternative scenario for using the present invention, project management and scheduling applications may make beneficial use of the hierarchical calendar entries to more efficiently and effectively manage resource utilization. Electronic calendars of the employees working on a project may be evaluated by a scheduling application to determine, for example, which team members have time available. This time can be accumulated to determine when a particular task might be expected to finish, given the existing human resources, the requirements of that task, etc. By using the multi-level event hierarchy of the present invention, blocks of time when a team member's calendar indicates he is in the office but is unavailable to work on the task (for example, when he is in a meeting) can be automatically computed. Or, a project manager who wishes to consult with a team member who is currently out of the office could programmatically determine whether (and using what means) that person is available for consultation. Also, knowing whether a team member who is traveling is nearby or is hundreds of miles away would allow the project manager to decide if that individual is available to assist in a local project emergency. Critical project situations in remote locations might be efficiently managed by using the present invention to determine which team members are currently traveling near the remote location, and which of those individuals has time available to address the critical situation. On large projects, automated techniques such as those which are available using the present invention are desirable to efficiently and reliably provide these types of information.
In addition to providing automated responses to incoming e-mail messages and voice mail calls, the present invention may also be used advantageously to generate responses for use in instant messaging systems. Instant messaging systems such as AOL Instant MessengersSM and Lotus Sametime™ Connect allow a user to change his status at a point in time. For example, Sametime™ has 3 states: “I am active”, “I am away”, and “Do not disturb me”. A user is also allowed to specify a status message to be displayed when he is in any of the 3 states. The techniques of the present invention may be used to automate the generation and content of these status messages. For example, suppose a user (1) schedules a specific event of “lunch” on his electronic calendar, where the lunch event is scheduled to end at 1 p.m., and (2) also sets an attribute of the lunch event to indicate that his preferred mode of contact during this event is by his pager, where the pager uses a certain specified telephone number. (This attribute may be a default attribute for all lunch events, or an override value for this particular lunch event, as has been discussed.) At the start of the lunch event period, anyone sending an instant message to the user will be automatically informed that the user's status is “I am away”, without the user having to manually change his instant messaging status. An accompanying status message during this lunch event might then use the text “Gone to lunch. Be back at 1:00. Page me at 888-555-4444if this is urgent.”. (Optionally, an implementation of the present invention may automatically forward incoming messages when appropriate, such as forwarding an incoming message to a user's alphanumeric pager in this example.) At the scheduled end of the lunch period, the user's instant messaging status will then automatically revert to the prior status (or to another status which may become applicable at that time). Furthermore, if a user's instant messaging status is set to “I am away”, either by the user or through the techniques of the present invention, mouse or keyboard activity occurring at the user's device may optionally cause the status to change to “I am active”. (This mouse and keyboard-driven status change is provided by prior art instant messaging systems.)
The logic which may be used to implement the preferred embodiments of the present invention will now be described with reference to the flowcharts in
Default attribute values (preferences) for event types may be set using the logic of
While the attributes of checking e-mail 620 and checking voice mail 630 are illustrated on GUI display panel 600, other attributes may be similarly presented. For example, a user who participates in instant messaging may set his preferences regarding when he uses his instant messaging system.
An implementation of the present invention may provide a status display 640 which shows the user information about the preferences he has entered. A template message 650 is shown in this example, where this message may be used in a dynamically-generated response to incoming e-mail in a particular user context. In the example of
Returning now to
While
The process of adding an event to a user's calendar begins at Block 400 of
Returning now to
Preference overrides for context events and specific events may be set using a selection menu, or using pop-up or pull-down menus, etc.
Upon reaching Block 430, the event and its associated preference overrides are added to the user's calendar. Preferably, a flag or other data structure variable is associated with the stored data for each calendar entry to indicate whether the entry is a context event or specific event. The processing of
In an optional aspect of the present invention, the user may be allowed to set priorities on the events he places on his electronic calendar. These priorities may then be used, for example, to resolve apparent scheduling conflicts, in a similar manner to how humans actually prioritize their time when overscheduled. For example, if a user has a meeting scheduled from 9 a.m. to noon and a teleconference scheduled on the same day from 10 a.m. until 10:30 a.m., the user may set a higher priority indicator on the calendar entry for the teleconference to show that he intends to briefly leave the meeting. When priority indicators are used in this manner, an implementation of the present invention may be adapted to consider the calendar owner as having the characteristics of the higher-priority simultaneous event for that event's duration. It will be obvious to one of ordinary skill in the art how this processing may be added to the logic of
According to the first preferred embodiment of the present invention, evaluation of calendar entries is performed on-demand, when an event occurs (such as an event indicating that it is desirable to contact a calendar owner, or an event requiring evaluation of calendar entries for project management purposes, etc.). In an alternative preferred embodiment, the evaluation is performed in advance by a calendar monitoring function. When the evaluation has been performed in advance, occurrence of an event then triggers use of the previously determined information. The logic used for this alternative embodiment is discussed below, with reference to
The logic of
At Block 500 of
In Block 535 of
Note that the logic in
Preferably, the subject line 1010 of the generated e-mail response indicates that the addressee is not currently available (see element 1020) so that the sender of the e-mail message which triggers this response will be quickly alerted to that fact. The addressee's applicable context event and specific event (if any) for the target period have been interrogated to programmatically determine when this addressee will return to the office, as shown at 1050. In this example, the context is out of the office, as shown at 1040. The addressee's attribute information for the applicable context event and specific event (if any) have also been interrogated to enable informing the e-mail sender as to when this addressee is likely to view the sender's message, as shown at 1060. The subject line 1010 may also notify the e-mail sender that the addressee is checking e-mail, as shown at 1030. An optional personal message 1070 may be provided as an attribute which may be overridden, if desired, using (for example) a text sting which has entered in field 840 or 850 of
The text message 1100 shown in
The spoken message preferably gives the caller an option to be transferred to another person who has been identified (using a particular attribute value, for example) as a backup contact, as shown at 1140, and another option to hear dynamically generated information regarding alternative means of immediately contacting the callee (using an immediate contact attribute value such as that depicted in
The alternative preferred embodiment for evaluating calendared entries, and their attributes, will now be described with reference to
In this embodiment, a table (or other similar storage structure) is preferably created to contain information about calendar owners for some particular period of time. The information in this table is then used to respond to incoming e-mail or instant messages (or to requests for instant messaging status), incoming phone calls, etc. For purposes of discussion, it will be assumed that the evaluation period covered by the table entries is the current day plus the next day. A calendar monitoring agent periodically inspects information on the electronic calendars for a set of users, and creates entries in this table accordingly. Preferably, each user's stored electronic calendar includes a bit or flag indicating whether this calendar data has been processed by the calendar monitoring agent. Thus, at the start of each new evaluation period and when a user's calendar is subsequently changed within this evaluation period, the flag is reset and the calendar monitoring agent therefore knows whether each user's calendared events need to be (re-)evaluated. Preferably, the calendar monitoring agent is invoked periodically, using a timer-driven means for example, to inspect the calendar entries looking for those which need (re-)evaluation. The invocation may be performed at differing time intervals according to the needs of a particular implementation. For example, it may be necessary to re-analyze calendars of the employees of a large corporation every 15 minutes, or every 5 minutes, while another environment may find other intervals more effective. (Alternatively, the invocation may be event-driven, such as by detecting that a threshold number of calendar changes has occurred.)
Referring now to
Using this parsed located information, the table entries previously discussed are created (Block 1220). An example table 1400 is shown in
Preferably, separate tables are created for use with e-mail, voice mail, and instant messaging (to allow each table to be separately customized without impacting the others, for example). Thus, the phone number entry 1410 is replaced by an e-mail address or instant messaging identifier for which the table entries of the corresponding table are to be used. When an event occurs for which it is necessary to generate an automated response, the phone number or e-mail target address or instant messaging target address, as appropriate, is preferably used as an index to the corresponding table 1400 (using the information stored in column 1410) to locate the entry for the current time period based on the information stored in columns 1415 and 1420.
The entries in this table 1400 are created using a set of rules for evaluating calendar entries. The rules may be adapted to the needs of a particular implementation of the present invention (where those rules may be the same as, or different from, rules which are used in an implementation of the first preferred embodiment). One such set of rules will now be described. First, a user is defined to always be in a context, and may or may not be in a specific event. It is necessary to determine which context and specific event (if scheduled) apply to the person for each moment of the day. If a user has scheduled overlapping context events, then the context with the later start time preferably takes precedence during the overlap. If multiple contexts are scheduled with the same start time, then another suitable conflict resolution technique may be used to determine which context takes precedence during the overlap. Similar analysis is preferably performed for specific events. Some types of context events, such as those which were previously described as being a category of “Out” events (i.e. Vacation, Holiday, Illness) may be defined for which all other events are ignored during this evaluation. If priority values have been assigned to the calendared events, as previously discussed, then apparent conflicts are preferably resolved using these priorities; when events of equal priority conflict, the rules may be applied using start time or another conflict resolution technique, as just described.
The user's calendar is then broken up into blocks of contiguous time (Block 1230 of
The following rules may be used to determine that a block should be ended, and a new block should begin: (1) the user's context is in the office or at an alternate work location, and a specific event ends without another specific event following; (2) the user's context is in the office or at an alternate work location, and a specific event begins when there was no preceding specific event; (3) the user changes from one specific event to another specific event having different attribute values (for example, changing from lunch, where the immediate means of contact is a pager, to a meeting, where the immediate means may be the user's secretary); and (4) an event (either context or specific) is scheduled outside the user's normal working hours. (It should be noted that these are merely representative rules that may be used.)
The process shown in
Returning now to the discussion of
As has been demonstrated, the present invention discloses advantageous techniques for more fully exploiting information on electronic calendars through use of a multi-level hierarchy of events and related attribute values for those events. Personal assistant applications can therefore better serve their users with automated, dynamically-generated information which accounts for the context of the calendar events.
A number of optional enhancements may be made in an implementation of the present invention, using the teachings which have been disclosed. For example, sender-specific filtering may be applied to incoming events, whereby the automated response is programmatically adapted based on an identification of the sender. A calendar user may designate certain individuals, or perhaps groups of individuals, who are to receive particular details while other senders are to receive a more generic response. The manner in which this filtering can be added to an implementation will be obvious to one of ordinary skill in the art.
Although the preferred embodiments are described herein in terms of predetermined context and specific event types, the disclosed techniques are easily adaptable to systems which provide for information of this type to be defined by a user (enabling use of event types which are tailored to the needs of an environment in which the present invention operates). In this case, the user-defined event type names are programmatically associated with attribute values for those names.
Furthermore, the disclosed techniques may be used advantageously for providing a general service in which the specific meaning and/or use of the information differs from that which has been described above.
While the preferred embodiments of the present invention has been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims shall be construed to include both the first preferred embodiment and the alternative embodiment, and all such variations and modifications as fall within the spirit and scope of the invention.
Number | Name | Date | Kind |
---|---|---|---|
4807154 | Scully et al. | Feb 1989 | A |
5428784 | Cahill, Jr. | Jun 1995 | A |
5528745 | King et al. | Jun 1996 | A |
5611050 | Theimer et al. | Mar 1997 | A |
5796394 | Wicks et al. | Aug 1998 | A |
5835762 | Gans et al. | Nov 1998 | A |
6016478 | Zhang et al. | Jan 2000 | A |
6327343 | Epstein et al. | Dec 2001 | B1 |
6380959 | Wang et al. | Apr 2002 | B1 |
6446118 | Gottlieb | Sep 2002 | B1 |
6463463 | Godfrey et al. | Oct 2002 | B1 |
6480885 | Olivier | Nov 2002 | B1 |
6640230 | Alexander et al. | Oct 2003 | B1 |
20020035607 | Checkoway et al. | Mar 2002 | A1 |