I. Field of the Invention
The present invention relates to event detection and alert systems implemented in computer software.
II. Description of the Related Art
An interrupt is a signal from a device attached to a computer or from a program within the computer that causes the main program that operates the computer (the operating system) to stop and figure out what to do next. Many computers today are interrupt-driven. They start down the list of computer instructions in one program (perhaps an application such as a word processor) and keep running the instructions until either they cannot go any further, or an interrupt signal is sensed. After the interrupt signal is sensed, the computer either resumes running the program it was running or begins running another program.
Basically, a single computer can perform only one computer instruction at a time. But, because it can be interrupted, it can take turns in which programs or sets of instructions that it performs. This is known as multitasking. It allows the user to do a number of different things at the same time. The computer simply takes turns managing the programs that the user effectively starts. Of course, the computer operates at speeds that make it seem as though all of the user's tasks are being performed at the same time. (The computer's operating system is good at using little pauses in operations and user think time to work on other programs.)
An operating system usually has some code that is called an interrupt handler. The interrupt handler prioritizes the interrupts and saves them in a queue if more than one is waiting to be handled. The operating system has another little program, sometimes called a scheduler, which figures out which program to give control to next. An interrupt request will have a value associated with it that identifies it as a particular device.
Although beneficial in the single-processor context, the state of the art is not completely satisfactory for systems with many different programs that require varying degrees of notification of a variety of different events. In current implementations, notifications are typically “hard-wired” in that they are provided through specific function calls supported by the specific functional area responsible for the notification. There implementations lack any facility for dynamically extending the mechanism. Further, in order to add a new type of notification, a new set of application programmer interfaces must be developed.
Consequently, known event notification schemes are not completely adequate for some applications due to certain unsolved problems.
USPTO Backgrounds
USPTO Backgrounds