Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1998-12-17
2002-12-24
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C700S019000
Reexamination Certificate
active
06499062
ABSTRACT:
FIELD OF THE INVENTION
The invention relates to an information processing system and a method, in particular, but not exclusively, for control of consumer electronics equipment in the home or office environment.
BACKGROUND ART
Consider a computing model based on Component Object Model (COM/DCOM) technology of Microsoft. For more information, see, e.g., the Component Object Model Specification version 0.9 of October 1995 as supplied by Microsoft, herein incorporated by reference. COM is object-oriented. An object has properties that represent control functionalities of an associated electronic device as exposed to a software application. A state change of an object as a consequence of an event from outside is passed on to the software application. The application manipulates the objects by changing or setting their properties. When the application modifies a property of an object associated with a certain physical device a command is sent to the associated device.
COM is a generic mechanism allowing applications to communicate in a consistent way and is a framework for developing and supporting program component objects. It provides capabilities similar to those defined in CORBA (Common Object Request Broker Architecture), the framework for the interoperation of distributed objects in a network. OLE (object linking and embedding) provides services for the compound document that users see on their display, COM provides the underlying services of interface negotiation and event services (putting one object into service as the result of an event that has happened to another object). In this implementation clients are modeled as OLE Automation objects (abstract representations) that use properties to expose controls and events to signal state changes. OLE Automation is a COM technology that enables scripting and late binding of clients to servers. OLE Automation provides communication with other programs through calls to features (commands and queries) that the programs have made available for external use. Before using an object, a client application has first to obtain the object's interface pointer. The interface pointer is obtained through the network's directory by binding the object's name or by enumerating devices. Standard COM API's for moniker binding can be used. References to objects can be obtained by calling GetObject or CoGetObject with a string specifying the desired device's name or ID. The application can then manipulate the object by setting or retrieving its properties through “set property” calls to the appropriate properties. When an application sets or modifies a property of an object corresponding with a device the property-setting operation or modification operation is converted into a command that is sent across the network to the relevant device. The objects may differ in implementation, but expose a similar property-based model to client applications running on a controller, e.g., a PC with a Windows-based operating system.
OBJECT OF THE INVENTION
Consider an information processing system comprising such objects (i.e., a collection of software modules, e.g., as introduced above) and client software applications that control the interaction among the objects. For example, the system comprises a home automation sub-system with audio/video equipment for entertainment, a security sub-system and an inhouse-climate control sub-system. These sub-systems and their components are modeled as, e.g., OLE Automation objects that use properties to expose their controls to application clients and events to signal state changes to the application clients. The sub-systems may use different communication protocols for their control signals. Accordingly, since they cannot communicate with each other directly, they communicate at the object-level. A client application could register for notification of changes to the “state” property of a first object representing a first (software) sub-system or first device and respond by setting a specific property of a second object representing a second sub-system or second device. However, the client application would need to be running all the time to provide this interaction. An alternative solution is therefore to specify that, whenever a change occurs to a property of a first object, the property's new value be propagated as a SetProperty call to a property of a second object. This mechanism is being referred to as a property route. A property route interconnects objects and is registered at the network's directory as a system-wide OLE Automation object itself. Registering a route creates a link between properties, typically, but not necessarily, between properties of different objects. Whenever a first property changes, the change triggers a call to change a second property via the registered route interconnecting these properties. For more background on a home automation system of the above kind see, for example, Ser. No. 09/146,020 filed Sep. 2, 19998 for Yevgeniy Shteyn for “LOW DATA-RATE NETWORK REPRESENTED ON HIGH DATA-RATE HAVi-NETWORK”, herein incorporated by reference.
Now, consider such a system with an object, a property of which is controllable through a state change from each of multiple other objects via property routes. Consider, for example, a lighting system wherein a light is controllable through two switches at two different locations. The two switches are represented by first and second software objects and the light is represented by a third software object. A first client application registers a first property route so that a change of a state of the first switch object propagates to the third light object to cause a corresponding state change of its brightness property. A second application registers a second property route to control the brightness of the light through a state change of the second switch object. Now, when the second switch changes its state to “ON”, the light's brightness goes to 100%. The state of the first switch is not updated, unless a third route has been registered for propagating the light's brightness state to the first switch. However, in many cases such behavior seems counter-intuitive as it requires a conscious effort from the user or application developer to keep the system synchronized. It also requires the system to use complicated logical rules to avoid looping route propagation. The state change of the light propagated to the first object may cause a call from the first switch object to the light object and thus a change in its brightness, etc.
As another example, consider a home entertainment system, wherein a particular functionality (e.g., sound volume) of an apparatus is controllable both through a physical slider at a control panel, and through a remote control device. Assume that the slider and remote control device are represented by first and second software objects and that the controllable functionality of the equipment is represented by a third software object. A first client application registers a first property route so that a change of a state of the slider object propagates to the third object to cause a corresponding state change in the volume property. A second application registers a second property route to control the sound volume through a state change of the object associated with the remote control. In order to keep the first, second and third object synchronized, one could register routes that propagate the state changes of the apparatus to the controls. This, however, renders the control complicated, as in the light case above, and requires checking for endless loops.
The inventor has realized that the user or the application developer has to make an effort in order to keep the behavior of the system's components synchronized. The inventor has also realized that it further a requires the system to use a complicated logic rule base in order to prevent the system from entering an endless loop.
It is therefore an objective of the invention to provide a system and a method for controlling physical compon
Courtenay III St. John
Schmitt Michael
LandOfFree
Synchronizing property changes to enable multiple control... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Synchronizing property changes to enable multiple control..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Synchronizing property changes to enable multiple control... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2984154