Sophisticated network users, including users of home networks, may create scripts or programs to have the devices in that user's network perform a particular task or set of tasks. This user then may enact a pattern of sharing functionality by providing the script, program, or a textual description, referred to here as information, to other users. The user may post the information on a web site, private or public electronic bulletin board, e-mail it to others, or transfer it to a physical memory component such as a floppy diskette, a compact disc, ‘thumb’ drive and use the ‘sneaker net’ to transfer it to other users.
Another user may then take the script or program and adapt it for the other user's needs. This may involve editing or otherwise manipulating the information to fit the needs and configuration of the other user's network and the other user's devices on that network. The other user's network may have devices, such as cameras, displays, printers, etc., that provide the other use with similar functionality, but are not the same type of components as the first user.
This requires a relatively high level of sophistication. The first user must have the knowledge to describe or otherwise document the configuration program or script with enough detail that someone can understand the function being described. The other user wanting to employ the configuration script or program must also have a level of sophistication that allows the other user to adapt the script to that user's network and devices on the network.
An embodiment is a computer-controlled method to configure a network of devices that acquires a specific instance of an abstract application of at least one component in a first network, captures and stores fields of the component in the abstract application, classifies the fields as to how the fields are to be used in matching, provides field values for fields within each component to be used in matching, and store the fields, components and values as a general instance of the abstract application.
Another embodiment is an apparatus that has an acquisition mechanism to acquire a specific instance of an abstract application of at least one component in a first network, a generalization mechanism to identify and generalize fields and values associated with the component, and a store to store the fields, components and values as a general instance of the abstract application.
Another embodiment is computer-controlled method to configure a network of devices that receives, at a network, a general instance of an abstract application having fields of at least one component and fields having values, identifies at least one component in the network having at least one of the fields in the general instance, and using the fields and values to resolve the general instance into a specific instance of the abstract application in the network.
Another embodiment is an apparatus that has a discovery mechanism for discovering a generalized instance of an abstract application, the abstract application having at least one component having fields and the fields having values, and an importation mechanism to identify a component in the network having at least one of the fields in the general instance and to use the fields and values to resolve the general instance into a specific instance of the abstract application in the network.
Embodiments of the invention may be best understood by reading the disclosure with reference to the drawings, wherein:
A user could explicitly create an abstract application by intending to create a file or other storage, such as an XML file, that characterizes or documents a connection between two devices to perform some task or to relate to each other in a particular way. The user may implicitly create an abstract application by configuring the devices to talk to each other, and the system would create the abstract application automatically, or transparently to the user.
An abstract application allows components on a network to form associations with one another, referred to here as “configurations,” and to execute operations that combine to provide some functionality to a user or another computer system. In a simple form, an abstract application contains sufficiently detailed information such that when the abstract application is used, it recreates a previously used component configuration. In a more general form, an abstract application allows a new component configuration to be created, based on aspects of the current context of use that has a similar functionality to a previously used configuration. Abstract applications may be saved as files, in component context, in searchable databases or file structures. The embodiments discussed here provide mechanisms to allow users with considerably less training and skill to both share and receive network configurations, and provides an advantage over the current approaches.
Once the specific instance of the network relationship, the abstract application, is acquired at 20, a generalization mechanism may generalize it for sharing at 22. Acquiring an abstract application may involve mechanisms for discovering the abstract application, receiving it from another user, or from the system that generated it automatically, as well a creating one. Generalizing for sharing will be discussed in more detail later, but a generalizing mechanism may identify fields of the components involved in the abstract application, and providing values for fields that describe those components.
At 24, A decides to share the general instance of the abstract application, and at 26, the targeted user or users discover the generalized instance. User B has a second environment or network 12 in which the abstract application will be used. At 28, the general instance is imported and the components corresponding to the general fields of the components specified at 22 are identified. Values, or flags, for the various fields of the components are evaluated and resolved into selection of a camera and a display device, in the example used above. At 30, the local instance of the network relationship, or abstract application, is then employed in the second network.
For case of understanding and to provide a concrete example of such sharing, the example of a first user configuring a camera to display images on a particular display device being generalized and then imported to another network will be discussed. No intention of limiting the scope of the claims to such a specific example is intended and none should be inferred.
The networks discussed here may include any combination of devices and services that communicate, and may have anywhere from one device to as many devices as a user desires. The environment may have a network administration device such as a server or computer, or any device on the network may act as the importing system. The methods of the embodiments discussed herein may be controlled by the network device importing or exporting the abstract application. The device that is responsible for importing or exporting the abstract application may be referred to here as a computer. The reference to a computer, such as COMP1 in
In
Fields may also be marked with a high or low priority indicating that the first user or first system believes that a particular field is important or unimportant to consider when finding a match in the new environment. A field may also be marked as ‘linked’ with a different field within the same abstract component description or a different abstract component description within the same abstract application. An example may include having two components that share a same location, such as the camera and the display should both be in the kitchen.
The information about how the fields should be used in importation is recorded in field descriptors. The actual value of the field descriptor will be referred to as field descriptor values. A particular type of field descriptor is an importance descriptor, which will have an importance descriptor value such as ‘high’ or ‘low’. The ComponentType field has a field descriptor value of ‘default value.’
In the example, the field descriptors have field descriptor values of ‘default,’ ‘blank,’ and ‘fixed.’ The ‘default’ field descriptor value indicates that the first user or environment recommends or believes that the value of the field to be whatever the value is, but that the second user or environment can override it. The ‘blank’ field descriptor value indicates that the first user is not sharing the specific values he or she specified in the local instance of the abstract application. The field descriptor value ‘fixed’ indicates that the value should not be changed. Further, field descriptors may also identify the fields as ‘linked,’ meaning that that field value for the source and destination should be the same. The field descriptors could be implemented in name-value pairs, such as ‘absolute’ as the name and the value being ‘true’ or ‘false.’ Alternatively, the field descriptors could be implemented as flags, with the value defined by the presence or absence of flags. Both field descriptor values and flags will be referred to as field descriptor values.
In the example of the kitchen camera and display, the field descriptor values for the source show that the component type of camera and the media format of MPEG (Moving Pictures Experts Group) are default values, meaning that they may be overridden. The media type of video is a fixed value, meaning that it should not be changed.
The field descriptor for location is a default value, meaning that it can be overridden. The field descriptor for location is also coupled, so that the source and destination values for these fields should be the same.
Other field descriptors may also be possible. In one embodiment, the importance of fields in finding a matching value between the exporting and importing environments. One embodiment may use a constraint resolution approach, the system would attempt to preserve any default values as possible, using importance descriptors to decide the order in which defaults may be overridden. In the example of
In the example of
Having provided the general instance of the abstract application shown in
In
In addition to having the ability to import and export abstract applications as configurations, it is also possible to manage connections and components. Up until this point, the discussion has centered on configurations having one connection between two components and how that connection may be generalized and imported. In addition, it is possible to nest generalizations of the connections within an abstract application. In one embodiment, a connection or component may be designated as ‘required’ in order for a particular abstract application to be used. An embodiment may also designate that any connection not designated as ‘required’ becomes ‘optional’ by default.
For example, a user may have a specific instance of an abstract application that involves four devices, A, B, C and D. When that instance is generalized for sharing, the components may be designated as required or optional. For example, components A, B and C are required and D is optional. When the importing network attempts to import the abstract application, the importation process will try to find equivalents of all four components, but will still operate if component D is missing. If any component A, B, or C is missing, the abstract application will not work.
Within a Connection field, a fixed value implies a required field, as in the abstract application discussion above. The importing system would interpret this field as necessarily available for the system to successfully import and use the abstract application, meaning that the second environment must have devices or services that have the capability to make the connection.
For example, a video conference abstract application may designate audio connections as required, such as a microphone and speaker(s) must be available, while allowing video connections to be optional. A first example of an abstract application having such a required connection is shown below.
The generalization of connections further allows for importation of abstract applications that will function in the second environment. By designating connections that are necessary in the second environment, the probability of success of importation is increased.
In this manner, then, a specific instance of an abstract application is generalized in a first environment. As an optional process, the generalization may include importance descriptors to add an importing system in resolving the general instance. The general instance may also include configuration of connections. The general instance is then imported into a second environment and resolved into a second specific instance.
It will be appreciated that several of the above-disclosed and other fields and functions, or alternatives thereof, may be desirably combined into many other different systems or applications. Also that various presently unforeseen or unanticipated alternatives, modifications, variations, or improvements therein may be subsequently made by those skilled in the art which are also intended to be encompassed by the following claims.
This application is related to the following U.S. patent applications, incorporated by reference herein in their entirety: U.S. patent application Ser. No. 10/317,764, filed Dec. 12, 2002, “Methods, Apparatus, and Program Products for Abstract Applications/Components in a Ubiquitous Computing Environment;” U.S. patent application Ser. No. 10/317,621, filed Dec. 12, 2002, “Methods, Apparatus, and Program Products for Analyzing Context in a Networked Computing Environment;’ U.S. patent application Ser. No. 10/317,342, filed Dec. 12, 2002, “Methods, Apparatus, and Program Products for Configuring Components in Networked Computing Environments;” and U.S. patent application Ser. No. 10/317,580, filed Dec. 12, 2002, “Methods, Apparatus, and Program Products for Utilizing Contextual Property Metadata in Network Computing Environments.”
This invention was made with Government support under Cooperative Agreement No. 70NAB3H3052 awarded by the National Institute of Standards and Technology. The Government has certain rights in this invention.