Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1998-12-16
2002-08-20
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
Reexamination Certificate
active
06438618
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention pertains to filtering events passed between a server and a client in a computer system.
The Microsoft® Component Object Model (COM) framework is a specification of a set of services that allows a user to create modular, object-oriented, customizable and upgradable, distributed applications using a number of programming languages.
See The Component Object Model Specification, Draft Version
0.9, Oct. 24, 1995, Microsoft Corporation, Seattle, Wash. and Digital Equipment Corporation, Maynard, Mass. An object is a unique instance of a data structure defined according to a template provided by a class. Each object has its own values for the variables belonging to its class of objects and can respond to the messages defined by its class. COM is an object-oriented framework, as COM objects have identity, state, and behavior and otherwise operate as programming objects in the traditional sense.
The COM specification defines how COM objects should be structured, and how they should operate. COM also includes a set of services, or application programming interfaces (APIs) that are part of a COM library. COM allows modular programming because it provides a communication mechanism to allow components in different modules to communicate. Another feature of COM is that location transparency is provided to applications, i.e., COM provides a communication mechanism that enables components to interact across a network, and for applications to be written without regard for the location of the components.
Events are used in COM frameworks and other systems to signal changes in the state of the system or in the state of a system component. In some systems, an event is a function call provided by an event source (e.g., a server) and implemented by an event subscriber (e.g., a client). A client may be an application executing on a computer that may take some action such as implementing a function based on receiving an event. The event may include (1) a notification that a change has occurred in a component of the system, (2) the new value of the changed variable, and (3) the prior value of the changed variable. An event may be generated, for example, when a home device is connected to a computer control system, or when a property of the home device has changed. This generates an event to indicate the connection or change and to cause the appropriate client (e.g., an application executing on a computer) to respond accordingly.
In current COM systems, events are typically passed from a server to all clients connected to that server regardless of the nature of each client and the nature of the event. Because events may initiate out-of-process calls, which require use of the operating system, and therefore consume a large amount of computer resources, it is desirable to have each client receive no more events than necessary. Furthermore, because some clients will not need to become active unless they receive an event, system resources are wasted when a client receives a particular event that it does not need. It is desirable, therefore, to provide a system for filtering events received by clients so that only events that will initiate a particular action by a particular client will be passed to that client.
Basic filtering of messages in computer systems with client and server software applications is known in the art. Certain factory automation systems and Internet “push” technologies (where a browser acts as a client desiring to be notified of changes in the server) employ event filtering. These systems include subscribing to events and publishing criteria by which those events are filtered. However, the standard COM mechanisms for event notification provide either no support for event filtering (for IConnectionPoint events) or very limited and non-extensible support (for IDataObject events).
SUMMARY OF THE INVENTION
In one embodiment of the present invention, an event notification system is constructed in a Component Object Model framework, to pass an event from an event source to an event subscriber. The event notification system comprises an event filter to represent a condition under which the event subscriber is to receive the event, and an event provider service for comparing the event to the event filter. The event source passes the event to the event provider service and the event provider service passes the event to the event subscriber if the condition of the event filter is met.
REFERENCES:
patent: 5682532 (1997-10-01), Remington et al.
patent: 5857190 (1999-01-01), Brown
patent: 5870605 (1999-02-01), Bracho et al.
patent: 5881315 (1999-03-01), Cohen
patent: 6021443 (2000-02-01), Bracho et al.
patent: 6029092 (2000-02-01), Stein
patent: 6038542 (2000-03-01), Ruckdashel
(no author given) “Events as Operations: IBM OOTIS/PCTE Object Event Notification Service Revised Proposal,” OMG TC Document 93-5-6, pp. 1-19, May 1993.
Lortz Victor B.
Ritchie Jonathan G.
Courtenay III St. John
Intel Corporation
Kenyon & Kenyon
LandOfFree
Method and device for filtering events in an event... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and device for filtering events in an event..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and device for filtering events in an event... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2924899