Calendar-induced desktop security

[0002] The present invention is related to the subject matter of the following commonly assigned, U.S. patent applications: Ser. No. 09/343,628 entitled “CALENDAR-INDUCED PROGRAM EXECUTION” and filed Jun. 30, 1999; and Ser. No. 09/343,626 entitled “CALENDAR BASED POWER MANAGEMENT” and filed Jun. 30, 1999. The content of the above-referenced applications is incorporated herein by reference.

[0003] 1. Technical Field

[0004] The present invention generally relates to security for data processing systems and in particular to security systems providing keyed locking for system operation. Still more particularly, the present invention relates to a data processing security system which takes into account a user's schedule of activities when activating a locking mechanism.

[0005] 2. Description of the Related Art

[0006] Security mechanisms for personal computers, whether desktop or mobile, generally provide security through a password locking mechanism, which is typically activated either by explicit invocation from the user or by an inactivity timer. The password locking mechanism is activated early in the startup process to prevent user from operating a system without the password. Some systems must remain continually powered, however, to serve data requests from a network and for similar reasons.

[0007] The problem with requiring explicit invocation of a locking mechanism is a running system is that the user may forget to invoke the locking mechanism before leaving for an extended period of time, compromising the security of the system. On the other hand, locking a system after detecting a period of inactivity may prove a nuisance to the user, who may be working but simply not have need to use the system before the timeout period expires. Having to unlock the system repeatedly to continue working may frustrate the user into disabling the inactivity timer.

[0008] Current locking technology also fails to take into consideration the user's behavior. In particular, if the user is absent for extended periods of time and the system is not locked as a result of inactivity, the system remains unlocked, exposing the confidentiality of the system and its data, and potentially endangering the integrity of the system through unauthorized use.

[0009] It would be desirable, therefore, to provide a security system which accounts for a user's behavior and scheduled activities in activating a system lock.

[0010] It is therefore one object of the present invention to provide improved security for data processing systems.

[0011] It is another object of the present invention to improve data processing system security systems having keyed locking for system operation.

[0012] It is yet another object of the present invention to provide a data processing security system which takes into account a user's schedule of activities when activating a locking mechanism.

[0013] The foregoing objects are achieved as is now described. For events scheduled within a user's calendar, a security mode is associated with the event. At the start of the scheduled event, the calendar notifies the security module of the security mode and the security mode is initiated. Different security modes may be defined, such as locking the system indefinitely, until the user unlocks the system with the password, locking the system for the duration of the event, or setting a shorter or longer inactivity period for a timer activated lock. Different event types may thus be matched with appropriate security modes, providing better overall security. The security mode, once initiated, may be maintained until the end of the schedule event, at which time the system may revert to a default security mode. Alternatively, the security mode may, by user specification or by default, be maintained until a different security mode is requested by the user, utilizing a password. The security system thus takes into consideration a user's behavior and scheduled activities in activating a system lock or other security mode.

[0014] The above as well as additional objectives, features, and advantages of the present invention will become apparent in the following detailed written description.

[0015] 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 embodiment when read in conjunction with the accompanying drawings, wherein:

[0016] FIG. 1 depicts a block diagram of a data processing system in which a preferred embodiment of the present invention may be implemented;

[0017] FIG. 2 is a diagram of a calendar-induced security system in accordance with a preferred embodiment of the present invention; and

[0018] FIGS. 3A-3B depict high level flow charts for processes of establishing and employing calendar-induced system security in accordance with a preferred embodiment of the present invention.

[0019] With reference now to the figures, and in particular with reference to FIG. 1, a block diagram of a data processing system in which a preferred embodiment of the present invention may be implemented is depicted. Data processing system 100 includes a processor 102, which is connected in the exemplary embodiment to a level two (L2) cache 104, connected in turn to a system bus 106.

[0020] Also connected to system bus 106 is system memory 108 and input/output (I/O) bus bridge 110. I/O bus bridge 110 couples I/O bus 112 to system bus 106, relaying and/or transforming data transactions from one bus to the other. Peripheral devices such as nonvolatile storage 114, which may be a hard disk drive, compact disk read-only memory (CD-ROM) drive, or digital video disk (DVD) drive, and keyboard/pointing device 116, which may include a conventional mouse, a trackball, or the like, are connected to I/O bus 112. Data processing system 100 further includes graphics adapter 116 connected to system bus 106, receiving primitives for rendering from processor 102 and generating pixels for display 120.

[0021] The operation of data processing system 100 is well known to those skilled in the art. A basic input/output system (BIOS), power-on self-test (POST), and various startup routines initialize the hardware and permit interaction between hardware components. An operating system, such as a version of the Windows operating system available from Microsoft Corporation of Redmond, Wash., provides a platform for execution of applications and for basic user interaction, such as display of information or manipulation of a cursor within the display by a pointing device. Operating system device drivers allow software components to interact with and control hardware components. Data processing system may be connected to a server 122 via a communications link 124 in accordance with known networking techniques.

[0022] In the present invention, either the operating system includes a calendar utility or a calendar application runs on top of the operating system. Additionally, the operating system preferably includes a security module. Alternatively, a security application runs on top of the operating system and provides the capability to prevent a user from operating the system unless a password or other key is employed.

[0023] Referring to FIG. 2, a diagram of a calendar-induced security system in accordance with a preferred embodiment of the present invention is illustrated. Calendar-induced security system 202 includes a security module 204 and a calendar 206. Security module 204 provides a locking mechanism preventing a system from being utilized unless a password or other key is employed to disable the lock. Security module 204 may include a system activity timer 208 for timing periods of inactivity in accordance with the known art. However, security module 204 also provides a locking mechanism which is augmented by incorporating the user's behavior represented in the user's calendar of activities 206.

[0024] Calendar 206 contains a plurality of data objects or records 210 for each date within a range of dates, such as all dates within a given year and/or each date for which some event is created. The user may create entries 212a-212nwithin any given date 210n, which entries 212a-212nspecify events or activities within the user's schedule. Such events or activities may include “Vacation,” “Trip,” “Meeting,” “Out-of-Office Meeting,” etc. The events or activities specified by an event entry 212a-212nmay be one of a number of predefined events or activities, or may be a user-defined event or activity.

[0025] Event entries 212a-212ncontain a description of the user's activities, including the location of meetings, events, and personal and company holidays. Event entries 212a-212nneed not be created by the user, but may be (locally or remotely) created by a network administrator for company holidays, sick days taken by the user, and the like.

[0026] During creation of an event entry 212a-212n, the user is prompted (as a menu option, for example) to specify a security mode 214a-214nin which the system should be placed for the duration of the event, together with a timer for initiating system locking, if applicable, before or after the start of the event. The security mode 214a-214nmay specify locking the system, either completely or with a user override, or setting a timed lock with a specified timeout period of inactivity. Thus, for instance, the system inactivity timeout period for a particular event—say, a business meeting with a supplier—may be set much shorter than the user would employ for normal working conditions (e.g., five minutes versus thirty minutes). The security provided for the event is thus much more appropriate and leaves less likelihood of unauthorized access to data on the system.

[0027] Thus, for example, for a vacation entry, a user may specify that the system should be locked, since leaving the machine operating and unlocked would pose a substantial security risk. If the user has not already locked the system prior to going on vacation, the security module 204 will lock the system for the user. Particular dates 210n, such as holidays, may also have an associated security mode 218, initiated for the duration of those dates.

[0028] The security mode 214a-214nmay be predefined for certain event or activity types, such as “Vacation” or “Meeting.” Such predefined security modes 214a-214nmay simply be a default for that event type, and the user may be provided the option of overriding or altering the predefined security mode 214a-214n. If the security mode 214a-214nis not predefined for a particular event type, or if an event entry 212a-212nis created which is not a predefined event type, the user is prompted to set the security mode 214a-214nin which the system should be placed for the duration of the event.

[0029] As the start time is reached for calendared events 212a-212n, the security mode 214a-214nassociated with the event is sent by calendar 206 to security module 204, which initiates the specified security mode. For concurrent events, the highest security mode associated with any event is employed by the security module 204. Therefore, if the user is absent from the environs of the system and unable to utilize the system, the system may be automatically locked, and remain locked for the absence period. Upon the user's anticipated return, as reflected by the calendar entry or entries 212a-212n, the system may be automatically unlocked. Even if the system is automatically unlocked, other locking mechanisms remain in effect such that if the user is late in returning from an event, the system relocks based on inactivity.

[0030] Prior to the start time of an event, the user can be notified via a pop-up dialog, which can be set to activate a predetermined period prior to the start time of the event. If the user acknowledges the pop-up, the desktop locking mechanism is induced to lock the system at the start time of the event. If the user does not acknowledge the pop-up, the system recognizes the user as overriding the scheduled event and the system locking mechanisms remain as previously configured.

[0031] Alternatively, user acknowledgement of the pop-up may be recognized as confirmation of the scheduled event, and the security mode associated with the scheduled event is invoked at the start of the event. As yet another alternative, the security module 204 may simply invoke the security mode associated with scheduled events as the start time is reached without prior warning to the user, allowing the user to manually override any lock which is applied.

[0032] The system security mode initiated at the start of a scheduled event may lapse at the end of the event, or continue until the user again actively utilizes the system. If the security mode associated with an event is allowed to lapse at the end of the event and the user does not utilize the system for several consecutive events, the calendar 206 need not present acknowledgement pop-ups and may keep the system locked until the system is unlocked by the user.

[0033] The present invention may also be utilized as a second level security mechanism. The system is most susceptible to unauthorized use when the user is absent. If an intruder manages to acquire the user's password, the best time for the intruder to take advantage of the acquired password and engage in unauthorized use of the system is when the user is absent. However, security module 204 may lock the system during events within calendar 206 for which the user is absent. Any attempt to override the system lock induced by the calendar event may require a second password, providing an extra level of security for the system. The present invention may thus also be employed for highly sensitive systems, limiting even an authorized user to access only during specified periods during which the user is permitted access to the system (e.g., between 9:00 a.m. and 5:00 p.m. on weekdays). In this case, when an attempt to access the system occurs when the user's schedule indicates that he is absent, a notification of the attempted intrusion into the system may be sent to the user (e.g., e-mail to a personal digital assistant or text-based pager).

[0034] In addition, as part of the invention, the user's background desktop image and motif can change automatically based on the type of event specified in the calendar 206. Thus, for example, if the user is attending a remote conference, the desktop theme, background images, and motifs can inform passersby of the whereabouts of the system's owner.

[0035] With reference now to FIGS. 3A and 3B, high level flow charts for processes of establishing and employing calendar-induced system security in accordance with a preferred embodiment of the present invention are depicted. The process of establishing calendar-induced system security, depicted in FIG. 3A, begins with step 302, which depicts an event or activity entry being created within a user's calendar.

[0036] The process then passes to step 304, which depicts a determination of whether a new user-defined event entry type (i.e., not predefined or previously user-defined) was created. If not, the process proceeds to step 306, which illustrates a determination of whether a security mode is specified for the event entry type created. Predefined event entry types (e.g., “Vacation”) may have associated default security modes (typically “locked” for the example of “Vacation”) within their definition. Alternatively, the user may have previously defined the event entry type selected (e.g., “Mom's house”) for the event or activity entry created, and specified a security mode to be associated with event entries of that type. Since different security modes are possible, the user may also employ different passwords (e.g., short versus long) depending on whether the user is scheduled to be using the system or scheduled to be altogether away from the system.

[0037] If a new user-defined event type is created (step 304), or if no security mode is specified for the entry type of the entry just created (step 306), the process proceeds instead to step 308, which illustrates displaying a list of possible security modes for a user, and then to step 310, which depicts prompting the user to specify a security mode for the event entry just created. The process then passes to step 312, which illustrates a determination of whether a security mode has been specified for the event entry just created within the user's calendar.

[0038] If a security mode is defined for an event type of the newly-created event entry (step 306), or if the user specifies a security mode to associate with the event entry (step 312), the process proceeds to step 314, which depicts setting the security mode as specified or defined for the just-created event entry. Otherwise, the process proceeds instead to step 316, which illustrates setting the security mode associated with the event entry to a null value.

[0039] From either of steps 314 or 316, the process next passes to step 318, which depicts the process becoming idle until another event or activity entry is created in the user calendar. The calendar, however, should be preconfigured to send a notification of the security mode associated with an event to the security module when the beginning date and time for an event having a non-null associated security mode is reached.

[0040] The process of employing calendar-induced system security, depicted in FIG. 3B, begins at step 320, which illustrates the start date and time for a scheduled event being reached, or a predetermined point before the scheduled start date and time being reached. The process then passes to step 322, which depicts a determination of whether a security mode is associated with the scheduled event. If so, the process proceeds to optional step 324, which illustrates prompting the user for confirmation of the scheduled event.

[0041] If step 324 is implemented, the process passes to optional step 326, which depicts a determination of whether the scheduled event was confirmed by the user. If not, the process proceeds to optional step 328, which illustrates cancelling the notification to the security module of the security mode associated with the scheduled event and remaining in a current security mode.

[0042] If optional steps 324, 326, and 328 are not implemented, or if the scheduled event is confirmed by the user, the process proceeds instead to step 330, which depicts the calendar notifying the security module of the security mode associated with the scheduled event, and the security module initiating the specified security mode. The calendar may also notify the security module of the end of the scheduled event with which the security mode was associated.

[0043] The process then passes to optional step 332, which illustrates a determination of whether the user has accessed the system since the start of the scheduled event. This step may be implemented if the security mode associated with the scheduled event is to be maintained until the user accesses the system to override the security mode. If step 332 is implemented and the user has not accessed the system since the scheduled event's start time, the process proceeds to step 334, which depicts maintaining the security mode initiated at the start of the scheduled event, until the user accesses the system.

[0044] Steps 332 and 334 need not be implemented if the system is to revert to a default security mode at the end of a scheduled event for which the security mode was initiated. If steps 332 and 334 are not implemented, or if the user attempts to access the system subsequent to the initiation a security mode associated with the scheduled event, the process proceeds instead to step 336, which depicts reverting to a default security mode for the system, which may be either higher or lower than the security mode associated with the scheduled event. The process then passes to step 338, which illustrates the process becoming idle until the start time for another scheduled event is reached.

[0045] As noted above, if concurrent or overlapping events occur, the highest security mode associated with any scheduled event is initiated and maintained until no longer called for (e.g., the end of the scheduled event having the highest security mode). The system then transitions to the next highest security mode for any ongoing scheduled event, etc. For certain event types, such as travel events during which the system may be lost or stolen, the associated security mode may be maintained indefinitely, until overridden by the user. For other event types, the security mode may be employed for only as long as the scheduled event. The present invention thus provides greater flexibility in setting security for a system, taking into consideration the user's schedule of activities to improve overall security.

[0046] It is important to note that while the present invention has been described in the context of a fully functional data processing system and/or network, those skilled in the art will appreciate that the mechanism of the present invention is capable of being distributed in the form of a computer usable medium of instructions in a variety of forms, and that the present invention applies equally regardless of the particular type of signal bearing medium used to actually carry out the distribution. Examples of computer usable mediums include: nonvolatile, hard-coded type mediums such as read only memories (ROMs) or erasable, electrically programmable read only memories (EEPROMs), recordable type mediums such as floppy disks, hard disk drives and CD-ROMs, and transmission type mediums such as digital and analog communication links.

[0047] While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.