WO2002093445A1

WO2002093445A1 - Interactive messaging

Info

Publication number: WO2002093445A1
Application number: PCT/SE2002/000925
Authority: WO
Inventors: Jan Gabrielsson; Lori Robertsson; Per-Olof Nerbrant
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2001-05-15
Filing date: 2002-05-15
Publication date: 2002-11-21
Also published as: SE0101708D0

Abstract

In distributing information such as messages to a plurality of users (3) and to devices (9) associated with users personal context are formed for the users. The personal context of a user is in a rule and context manager (5) evaluated and adapted for selective distribution to other users. The adapted personal context can be shown at displays of the devices associated with the other users. The central manager (5) has a rule engine applying personal rules to adapt the personal context and also applying rules to personal contexts to set parameters. The change of a parameter value can trigger an external action such a generating and transmitting an electronic message. A very versatile distribution of context information is obtained and also actions can be triggered by the use of rules evaluating contexts of a plurality of users.

Description

INTERACTIVE MESSAGING TECHNICAL FIELD

The present invention is related to a method for generating and distributing specialized information to users and to a network in which specialized information is 5 distributed to users of the network. BACKGROUND

Presently, in many families the situation can be rather mobile. For instance, parents can be working and away from home while the children are at school and/or day-care. All family members have to maintain a continuous contact with each other in order to 0 coordinate tasks, perform dynamic planning, and maintain a strong social relationship.

Any person usually is member of at least one group of people. The membership can be characterised in various ways, e.g. as a relationship between family members, common interests, or as a relation between professionals.

Today, most family members have access to a mobile device. They are used for s direct communication - e.g. telephony or non-direct communication such as messaging - e.g. SMS. There are pilots now using ICQ or chat services based upon WAP or GSM data.

In the published International patent application WO 00/18166 having the title "Personalised call treatment in a communication system" a method is disclosed in which o the context of a user is submitted to a context register. When two users are setting up a communication, the network and an application may use the context information of the two parties to determine a best communication mode and optimal communication resources. In the disclosed method sensors can be used producing values comprising said contextual information. A characteristic of the system is that context information is solely 5 used within a technical system and that context information is not directly available to a user.

It can be observed that context information, within a group of people having strong relationships, can be very informative in itself. Thus, a user knowing the context of another user may take manual actions to affect the communication mode and the means 0 for communication.

Prior art systems and methods fail to disclose presentation of at least part of a personal context to dedicated persons. Further, a limitation of known systems, that use context information, is the use of static rules to affect the communication mode between two parties. 5 Although the cited patent application WO 00/18166 discloses an arrangement whereby direct user control influences a further refined selection of contextually determined interaction modalities and communication media, the application fails to describe how said user control may be implemented.

There is, thus, a need for a system and method for presentation of at least part of a personal context to other persons of a group. There is further a need for a system implementing dynamically defined rules according to which context affects the communication mode between members of a group.

In U.S. Patent 5,493,692 a method for selectively delivering electronic messages is 5 disclosed. In the method a user context is utilized affecting the delivery.

SUMMARY

It is an object of the invention to overcome deficiencies of prior art systems for context based communication.

It is another object of the invention to provide a system and a method for sharing o user defined contextual information between members of a group of persons.

A further object of the invention is to provide a system for analysis of user defined contextual information, the system taking automatic actions in response to specific rules being fulfilled.

Still another object is to provide a system and method for user control of contextual 5 information and inference rules governing automatic actions related to communication between group members.

Generally thus, in a system and a method the context of each user is monitored and then this information can be automatically provided to the other users within a predefined group. Thus, for each user there is an associated context. Context is defined to be a set o of parameters having values. A context can also be assigned a technical subsystem, e.g. a refrigerator. A refrigerator may, e.g., have a temperature and a shopping list.

The context can be provided to other users via a shared area comprising a compilation of the monitored parameters of each user. Each user has the ability to define her/his own context and decide how it should be shared or interpreted by the other users 5 within the group by means of a dynamic set of rules. More generally, a user may define conditions affecting the presentation of the user context to other persons. The conditions may include personal access rights, dependency of time, location or fulfilment of certain conditions as specified by rules.

Each individual user within this group is allowed to specify events that are 0 connected to his/her own context or the contexts of other users and the context of subsystems that can trigger actions within the system. This is achieved by defining rules that are executed by a rule engine and depend upon the conditions of the parameters that have been designated within the context of each user.

Each individual user can also define parameters for virtual objects that have an 5 associated meaning to her/his own context such as a car. A virtual object of this type has or is associated with a set of parameters representing a subsystem context. These parameters, however, only receive a meaning when certain conditions are fulfilled, e.g. that a user occupies a car as a driver and then the location of the car, and traffic conditions are examples of parameters associated with the car and receive a meaning at occupation of the car. The particular car, in this example, is bound to the car object defined by the user.

Thus, the system as described herein has a structure allowing a context to be dependent on other contexts. Virtual objects are used that have an associated meaning to the contexts and that are associated with a set of parameters which can represent a subsystem context. Each user context is dynamically dependent on other user contexts and of the status of virtual objects. For example, while a user is working in the office a user context might be defined in terms of location of equipment such as printers, displays, projectors, PCs, status of colleagues. During office work, the virtual object represented by a car is not an active component of the context. However, while the car is occupied it becomes an active part of the context whereas the previous active components representing office equipment become inactivated. Further, occupation of the car at e.g. 4 pm would involve the contexts of children and wife, as these persons are then believed to change activities, finishing school and work. While driving home the rule engine might evaluate a rule to indicate suitable time and place for the driver to pick up other persons. Further, a shopping list might previously have been excluded from the active context of the driver. However, while approaching a shopping center, the list might become an active part of the context and remind the driver to do some shopping on the way home. A characteristic of the system described herein is further that a user context might depend on other users interacting with the system. In the example above, while occupying the car the context of a child at school might be included in the car driver's context. However, the inclusion of the child context into the drivers context might be in dependence of the child replying to a question, resulting from the evaluation of a rule, whether or not the child wants to be picked up by the car driver. This kind of interaction might be described in terms of messages: the rules engine launches an action resulting in a message for an identified person who responds to the message. Other messages carry sensor values that are pushed into a user's part of the context database.

Furthermore, a parameter might have properties and might be associated with information, e.g. a message. In the above example, the question to a child whether it wishes to be picked up or not could be extended from a simple Yes/No question to include a message suggesting a meeting place.

Additional objects and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objects and advantages of the invention may be realized and obtained by means of the methods, processes, instrumentalities and combinations particularly pointed out in the appended claims. BRIEF DESCRIPTION OF THE DRAWINGS

While the novel features of the invention are set forth with particularly in the appended claims, a complete understanding of the invention, both as to organization and content, and of the above and other features thereof may be gained from and the invention will be better appreciated from a consideration of the following detailed description of non-limiting embodiments presented hereinbelow with reference to the accompanying drawings, in which: 5 - Fig. 1 is a schematic diagram of a network for utilizing context information,

- Fig. 2 is a block diagram of basic steps performed by a rule engine,

- Fig. 3 is a block diagram illustrating the basic blocks and functions of a context service,

- Fig. 4 is diagram illustrating sensors, parameters and actions for part systems of a rule engine associated with two users, o - Fig. 5 is a flowchart illustrating steps performed by rule engine, and

- Fig. 6 is a picture illustrating the fields of a context database.

DETAILED DESCRIPTION

A network for providing information is schematically illustrated in Fig. 1. The network comprises a plurality of sensors 1 collecting data, sensors being taken in a s general sense as devices, physical or logical, indicating some varying condition or state. The sensors can be monitored for changes or themselves indicate or signal a change of a condition. Each sensor defines one or more parameters available for building rules, the parameters including e.g. an output signal or a state of the sensor that can be accessed on request. Some sensors 1 can also operate as actuators. An example thereof is an electric o lock that could be momtored for its status, i.e. whether it is locked or unlocked, but also be remotely controlled to lock or unlock. Some sensors can include only the on/off state of conditions manually set by a user.

A user 3 in the network has a set of the sensors 1 associated with her/him. Some sensors can be global, accessible to all users, such as sensors providing information on 5 the weather or the traffic situation, or they can be restricted to be only associated with a single user or a group of users. Sensors can be connected to or included in devices carried by the user or to devices owned by the user but not carried around, such as a car or a home. Some of these devices can be considered "shared" amongst some of the users of the network. For instance, the sensors located in a private home can be associated with 0 all the members of the family living in the home.

The sensors 1 may relate to measurements, e.g. of temperature, time, location, heart beat of a person, and thus provide measured values as parameters. Other sensors are related to virtual objects or events or states, e.g. sensing that a person has occupied a particular car as the driver thereof. 5 The network further comprises a logical unit 5, also called a rule and context manager, as will be described below, that collects, interprets, evaluates and modifies context information of users, i.e. the parameters from or comprised in the sensors, and, based on a rule engine 6 comprised therein, see Fig. 3, triggers actions when a specific rule is fulfilled. The rule and context manager 5 monitors the parameters of the sensors 1 and when a change is detected it stores the new values and evaluates, in the rule engine, associated rules to form adapted context information. Also new values of derived or virtual parameters can be formed using rules evaluated in the rule engine 6. Thus, when such rules that are found to be fulfilled the new derived parameter values can trigger 5 associated actions.

In Fig. 4 distributed parts E: A and E:B of the rule engine 6 are illustrated, the parts E:A and E:B belonging to users A and B respectively and e.g. executed in mobile user devices, as will be described below. The sensors 1 having labels SI - S4 provide parameter values designated PI , P2, P5 and P6 respectively. The value of parameter PI o provided by sensor SI is pushed into, i.e. is automatically transmitted to, the part system E:A that is associated with user A, whereas the value of the parameter P2 provided by sensor S2 is pulled on request by the part rule engine E:A, i.e. the value of the parameter P2 is obtained by polling or interrogating the sensor S2. In the same way, the sensors S3 and S4 provide values of parameters P5 and P6 which are delivered on s request to the part system E:B of user B and are directly or automatically provided to the same part system E:A, respectively. The parameter indicated at P8 has a value that is manually set by the user B. In the part rule engines E:A, E:B respectively first rules of the respective user as indicated at 8 are executed and are applied to the parameters PI , P2, P3 and to the parameters P5, P6, P8. The rule of user A results in the setting of the o virtual parameter P4 that can operate the actuator Al. The parameter P3 used by the first rule of user A in the part rule engine E:A associated with the user A is a shared parameter that is pushed by the part rule engine E:B associated with the other user B. A shared parameter is defined to be a parameter that is pushed to at least one other user than the user with which the parameter is primarily associated. The rule of user B results 5 in the setting of the virtual parameter P7.

Actions can be utilised to update the user's context information that is then automatically processed to be shared with other users within a group. For instance, the virtual parameter P7 set by the rule engine of user B can be such a parameter that e.g. can be displayed to other users. In another preferred case, the parameter P7 can have an 0 associated action, e.g. as defined by an executive file that when the parameter is set is executed in one of the devices of the system. The execution of action files can be considered to be performed in an action handler unit that can be a logic unit assigned to execute actions and physically being any of the devices of the system suitable for this kind of work. An action can use the values of parameters of the rule with which the 5 action is associated and other values computed from the parameters. Such an executable action file can then for instance generate an electronic message being sent to a selected user or to a user group, at a specific time or several specific times, the type of message such as SMS or voice message. Also the contents of or the text inside such a message can be dependent on the parameter values, i.e. on the context of the user considered and also on the shared contexts of other users. For example, the message can contain information on the current place where the considered user is currently located such "I am driving the car" or "I am at home", the underlined word being set in the execution of the action.

5 The rule and context manager unit 5 may find a rule, associated with the context of a particular user that is almost fulfilled but for at least one ambiguous parameter. An ambiguous parameter is defined as a parameter the value of which is currently unknown. The rule engine 6 is designed to have the capability of resolving this and other types of conflicts, if specified by special rules. For example, the rule engine may decide to launch o a request for the value of an ambiguous parameter. The request for a parameter value may, e.g., be directed to the person 3 having said context. However, generally, the system may contain information of persons, devices or entities, which may provide the requested value. The rule and context manager may then launch successive requests to said persons, devices or entities until a value is received or it may launch parallel s requests to said persons, devices or entities.

In order to provide a non-intrusive system, data may be provided to the rule and context manager 5 and the rule engine 6 thereof in regard of the way in which it is to react to ambiguous parameters. For example, the system may be instructed only to prompt a user for ambiguous parameters in the case where there is a change within the o system that changes other parameters within the same rule. As another example, the system may be required not to prompt a named person for the ambiguous parameter. In this case, the system may request another person or other entity for the value or the parameter is left with no defined value at all.

The rule engine 6 is further designed so that each user 3 has a personal rules area in s the list 21 of all personal rules, see Fig. 3, allowing personalization of rules and creation of new rules. The rule engine 6 and/or the context manager 11 or parts thereof may further be more or less decentralised and then e.g. at least said personal rules area can be located at a preferred device or entity capable of executing the rules. Evidently, a distributed rule device or entity must be capable of communicating with the appropriate 0 database of compiled contexts, see items 13 and 17 of Fig. 3 and the description below.

Within the network, an aggregation of parameters can be defined to create new parameters. As illustrated in Fig. 1, one or more sensors/parameters can be aggregated to form a joint sensor 7 creating a new "virtual" parameter. The aggregation can be carried out by the rule engine 6 evaluating formulae involving two or more parameters and 5 setting the value of a new virtual parameter equal to the result of the evaluation. This is also illustrated in Fig. 4, compare the parameter P4.

Within the network, the user 3 can assign properties to the parameters in different ways so that they behave according to the requirements of the respective user. For example, parameters can be set to control the rule engine 6 to question the user 3 at the times when a value is needed or at predetermined time intervals. Further, parameters can be defined to be polled by the system, e.g. so that a logical function accesses the value of a sensor that is continuously measuring the parameter. Other parameters can be blocked from the "shared view". Further, parameters can be connected to an aggregated value of

5 other parameters.

In Fig. 1 is also illustrated that the user's 3 own context as well as his/hers view of the other users contexts can be visually represented on an awareness area, typically a display 9', e.g. at a personal mobile device 9. Results of events and notifications may also be represented on the same mobile device. Another way of sharing contexts could be o to have parameters connected or provided to heat/audio or tactile actuators that the user can sense. An example can include that when the body temperature of a person's child reaches a certain threshold the wristwatch of the person starts to vibrate. The awareness area can also make the user aware of the contexts of persons that the user has defined as belonging to various groups, e.g. family members. The awareness area comprises a s plurality of views selectable on a user terminal, e.g. a mobile telephone 9. The current context of a user 3 is submitted to the rule and context manager 5, which can use these data to control the information for presentation on the user awareness area. For example, while in a meeting, a person may not be interested in context information relating to members of the golf club whereas context information relating to family members may o still be important. Further, the data can also affect the types of modes of communication that the user can use in the current context. For example, in the meeting case mentioned above, the data may instruct the rule engine 6 not to allow any oral communication with the user.

In Fig. 3 the basic functions of the rule and context manager 5 are illustrated and in 5 particular the interaction between a context manager unit 11 and the rule engine 6. Thus, with reference to Fig. 3, sensors associated with two users A and B provide context information to the context manager 11. Contexts compiled from the users A and B are stored in a context database 13, each user A, B having a personal context area 13 A, 13B within the database. The compilation of context information is controlled by a context 0 control unit 15 that is part of the rule engine 6. For example, the context control unit can request the context manager 11 to ask a specified person, device or sensor for the value of a certain parameter.

A context distributor 16, also controlled by or part of the rule engine 6, processes the contexts of the users, i.e. the contents of the database 13, to form "shared" context 5 information stored in a shared context information database 17 that contains personal areas 17A, 17B and is further distributed for presentation on awareness areas of other users than that user which "owns" the considered context information, such as at the displays of the mobile terminals of the users B and A, respectively. The context distributor 17 further includes functionality for pushing shared parameters to the areas 21 A, 21B for personal rules which have indicated a need for these parameters. Referring to Fig. 4, the parameter P3 is an example thereof. A separate part 21 of the rule engine 6 implements the personal rules so that the personal rules 21 A belonging to user A can use the unprocessed context 13 A of user A and the context information, i.e. the processed

5 contexts, of other persons, e.g. the open or shared context information 17B of user B. Furthermore, the whole or parts of the rule engine 6 and the context manager 11 can be decentralised or distributed as indicated above, and e.g. the personal part of the rule engine 6 for user A and/or B may be distributed. For example the personal rules associated with user A may be implemented in a mobile device 9 belonging to user A. o The context of a first member of a group may be in conflict with the context of a second member of the group, e.g. in relation to the communication media that are allowed. For example, a first group member may be driving a car and then a message for a second party can only be created as a verbal message. Said second party, however, may be in a meeting in which oral communication is not preferred. In such a 5 circumstance, the message may be rerouted for transcoding from an oral format to a text format by the change of an associated parameter value, the value changed by the rule engine 6. For example, if at least part of said rule engine 6 is implemented in a user terminal, an oral message created at that terminal may be rerouted to an entity or device that performs transcoding to text and further delivery to the intended recipient. o In Fig. 2 the main different steps performed by the rule and context unit 5 are illustrated. The parameters are collected, as shown in a first block 25. The parameters collected can be classified in different categories depending on the way in which they are perceived within the system. A parameter can belong to one or many of the following categories: 5 - Periodically polled parameters, such as the quantity obtained from a temperature sensor. This is useful for parameters that can be read without disturbing users or demanding too many resources within the system or has some other cost that makes it inconvenient to perform excessive readings.

- Change driven parameters. Some sensors/parameters only report to the rule and context 0 unit 5 when a change has occurred. Sensors could be configured to only report changes greater then a predetermined threshold. Typically a GPS parameter would only change when the object has moved a predetermined distance or to a specific place.

- Manually set parameters. A parameter which is hard to automatically measure or over which a user wants a total control may be manually set by the user owning the 5 parameter.

- Parameters collected at events, i.e. when a rule is evaluated.

Rules are usually evaluated on demand, see the block 27, e.g. when a change occurs in the network that may affect a rule or typically when a parameter gets a new value. Rules that are prevented from being fulfilled due to an ambiguous parameter value may, if the owner of the parameter has allowed it, ask the owner or any other named person or specified device for the current value of parameter to determine whether the rule can be fulfilled and hence the associated action can be carried out. This may be the case of manually set parameters. Parameters can generally be associated with a time 5 stamp and an expiration time period so that they are undefined after the expiration period.

Events are associated with changed parameter values, i.e. changed contexts. Events are related to rules in that fulfilled rules may change parameter values and, thus, create new events. Events, i.e. changed parameter values, may trigger actions in devices that use parameters for device control, e.g. locking a door. Events can also be defined to set 0 the value of another parameter, i.e. to create a new event. This is the way in which a rule can aggregate the value of one or more parameters to form a new virtual parameter.

The main fields of each record in the context database 13 are seen in Fig. 6. Each record contains the data of one parameter and can e.g. have the following fields:

- A number or other identification of the parameter. s - An ordinary language name of the parameter.

- The name of the user to which the parameter belongs.

- The current value of the parameter where an unknown value is denoted by a special character.

- The start time for the validity of the current parameter value. o - The expiration time for the validity of the current parameter value.

- A field for telling whether the parameter is the type that is polled or the parameter provides its new value directly.

- The times when the parameter is polled in the case where the parameter is the polled type. 5 - Names of other users or user groups to which the parameter value should be made available.

- The rules in which the parameter is used.

- The action, e.g. a file name, to be performed directly, for a change of the value of the parameter. 0 In the flowchart of Fig. 5, the steps performed by the rule and context manager 5 for a new event associated with a considered user are illustrated, an event here being either a change of a parameter value or the fact that a new polling time has been reached. In a first step 51 there is thus a new event. In a second step 53 it is determined whether the new event is the type "parameter changed" , i.e. whether the event is the result of the 5 fact that the value of the parameter has changed. If it is determined that the new event is this type a step 55 is executed in which it is determined whether an action should be started for a change of this parameter X and then executing the action if there is such an action. In a next step 57 the value of the parameter is pushed to the rule engine parts of other users which require this parameter according to the specification for this parameter. In the next step 59 a loop is started for each rule involving the parameter. Thus, in a step 61 for each rule A is investigated whether the values of all other parameters Y involved in the rule are known and in the next step 63 unknown values of such parameters are searched for, such as by asking some user or device or polling in the case

5 where the parameter having the unknown value is a polled parameter. When all parameter values involved in the processed rule have been investigated, it is determined in a step 65 whether the rule A is resolvable, i.e. whether the result of the rule can be decided, and whether the result of the rule is true. If it cannot be resolved or the result is not true the next rule is processed and if there is no more rule the loop is ended in a step ιo 67, and a new event is awaited in the start step 51.

If it was decided in the step 65 that the result of the rule can be determined and that also the result is the logical value TRUE a step 69 is executed in which a target or virtual parameter T is set, e.g. by some calculation, if this has been defined for the rule, compare parameter P4 of Fig. 4. The setting or changing of the value of the virtual is parameter can T generate a new event, as indicated in the next block 71. Thereupon, as above the next rule is processed if there is one and if there is no more rule the loop is ended in a step 67, and a new event is awaited in the start step 51.

If it was decided in the step 53 that the new event is not the type "Parameter changed" , a step 75 is executed in which a loop is started for each polled parameter Z.

2o Thus, in a step 77 the parameter is polled for its value. Thereafter, in a step 79 it is decided whether the value of the parameter Z has changed from its previous value. If the value has not changed, the next parameter is polled in the case where there is one and if it no more such parameter, the loop is ended in a step 81 and a new event is awaited in the start step 51. If it was decided in the step 79 that the value of the parameter has

25 changed a new event of the type "Parameter changed" is generated in a step 83 and then the start step 51 is again executed.

A rule has the following general properties: First, it is possible to evaluate the rule, i.e. to find whether a composite condition a true, and second, the rule is capable of making algebraic calculations. The rule based calculation is generally performed if the

3o rule is evaluated to have the value TRUE. A rule can have the general format: 1. A condition starting the evaluation of the rule, e.g. "parameter No. 1 changing value" or "parameter No. T equal to 10.30". In the latter example parameter No. T is assumed to be the current time.

352. A logical function of parameters of the user to which the rule belongs and of parameters of other users. The function can have the values TRUE and FALSE. A simple example of a logical function is "parameter No. 1 AND parameter No. 2" in which it is assumed that the parameters Nos. 1 and 2 are logical parameters and which has the meaning that an action will be taken in the case where the two parameters both are true.

3. The action or actions performed in the case where the logical function is determined to have the value true. The actions are generally defined by a file that is to be executed in a predetermined one of the devices of the system. The file can include algebraic or logical operations on parameter values, setting or changing the same or other parameter values and can when executed generate an electronic message.

Also, rules are used which govern the processing of parameter values whether they are to be made available to other users. They can have the following general format for each other user to which the parameter value or some other value derived therefrom should be presented:

1. The name of another user or group of users.

2. A logical function of parameters of the considered user and of other users.

3. Parameter value to be presented in the case where the logical function has the value true. The network as described herein allows the users within a defined group to automatically share their contexts with each other as a supplement to existing forms of communication - e.g. telephony and messaging. In addition, the users can combine information about their contexts with actions such as notification, messaging, and/or actions that are performed to a user's environment, e.g. devices, objects. The network as described herein provides the users within a group with automatic information about their contexts without requiring other users to request such information. It allows each user to establish her/his own parameters and to flexibly create new parameters that can also trigger actions towards objects within their environment or towards other users. While specific embodiments of the invention have been illustrated and described herein, it is realized that numerous additional advantages, modifications and changes will readily occur to those skilled in the art. Therefore, the invention in its broader aspects is not limited to the specific details, representative devices and illustrated examples shown and described herein. Accordingly, various modifications may be made without departing from the spirit or scope of the general inventive concept as defined by the appended claims and their equivalents. It is therefore to be understood that the appended claims are intended to cover all such modifications and changes as fall within a true spirit and scope of the invention.

Claims

1. An arrangement for generation of messages affecting or improving communication between users in a telecommunications network, each user associated with a set of parameters, characterized by: - a plurality of devices providing parameter values,

- means for determining, for each user, a user context comprising values of a set of parameters at least partly obtained through signal exchange with said plurality of devices,

- means for evaluation of rules applied to at least a said user context,

- means for performing actions in dependence of at least one of the rules being fulfilled, said actions including generation of at least one message sent to one of the users or to one of the devices.

2. An arrangement according to claim 1, characterized in that at least one of said plurality of devices is an input device for manually setting a parameter value.

3. An arrangement according to claim 1, characterized in that the means for performing actions are arranged to modify at least one user context by updating at least one parameter value.

4. An arrangement according to claim 1, characterized in that in the case where the means for performing actions are arranged to perform an action including that a message is sent to a device, the message includes updated parameter values for determining an action at said device.

5. An arrangement according to claim 1, characterized in that the means for performing actions comprises a plurality of distributed means, each one of which capable of performing a specific one or specific ones of the actions.

6. An arrangement according to claim 1, characterized in that the message comprises a request for at least one parameter value.

7. An arrangement according to claim 6, characterized in that the request is directed to a plurality of predefined devices providing parameter values.

8. An arrangement according to claim 7, characterized in that the request is directed consecutively to each device of said plurality of predefined devices.

9. An arrangement according to claim 7, characterized in that the request is directed in parallel to each of said plurality of predefined devices.

10. A method of generating messages affecting the communication between users in a telecommunications system, characterized by the steps of:

- receiving a first set of parameter values and applying first set of rules to form a second set of parameter values,

- applying second set of rules to said second set of parameter values whereby at least a rule being satisfied causes a change of value of at least a parameter of said second set of parameters,

- generating a message including at least one changed parameter value.

11. A method according to claim 10, characterized in that said message is a message for a user of a mobile terminal, the message comprising a selection of parameter values of said second set of parameters.

12. A method of generating messages affecting or improving the communication 5 between users in a telecommunication network, the users interacting with each other and each user having an associated set of characterizing parameters having properties, characterized by the steps of:

- forming, for each user, a user context by retrieving a specified set of stored parameters,

- applying inference rules to the collection of said user contexts to determine, for each o user, a modified user context,

- generating, in dependence of said modified user contexts, a message for at least a said user.

13. A method according to claim 12, characterized in that said specified set is determined by at least a parameter value. 5

14. A method according to claim 12, characterized in that said specified set is determined in response to at least one parameter, not previously assigned a value, is being assigned a value.

15. A method according to claim 12, characterized in that said at least one parameter comprises a location parameter. o

16. A method according to claim 12, characterized in that said specified set is at least partly determined by a user.

17. A method according to claim 12, characterized in that said generating is, further, in dependence of properties associated with at least one parameter.

18. A method according to claim 12, characterized in that said properties 5 determine one of: a time when the generated message is to be sent, the user or users to which the generated message is to be sent, a request for the value of one of the parameters and the type of the generated message.

19. A method of distributing information to a plurality of users and to devices associated with users, characterized by the steps of: 0 - forming a personal context for at least one of the users,

- evaluating the personal context,

- modifying the personal context as a result of the evaluating,

- adapting the personal context for selective distribution to at least one selected among the other users and the devices. 5

20. A method according to claim 19, characterized by the additional step of presenting the adapted personal context at a display of said at least one selected among the other users and the devices.

21. A method according to claim 19, characterized in that in the step of evaluating, the evaluating is made by applying rules to the personal context.

22. A method according to claim 21, characterized by the additional step of executing, in response to at least one rule being fulfilled, at least one action.

23. A method according to claim 22, characterized in that said at least one action includes setting at least one parameter.

5 24. A method according to claim 19, characterized in that in the step of forming a personal context, the personal context is formed to include values of a set of parameters.

25. A method according to claim 24, characterized in that in the step of evaluating, the evaluating is made by applying rules to parameters included in the personal context.

26. A method according to claim 24, characterized by the additional step of o obtaining values of the parameters by one selected among: receiving the value from a sensor or device, polling a sensor or device, calculating, manually setting the value by one of the users and by applying rule based operations to at least one of the parameters.

27. A method according to claim 24, characterized by the additional step of obtaining values of the parameters by s - directing a request to one of the users, and - said one of the users manually setting the value in response to the request.

28. A method according to claim 24, characterized by the additional step of executing at least one action in response to determining that at least one parameter has changed its value. o

29. A method according to claim 24, characterized by the additional step of allowing a user to create or modify at least one rule.

30. A network for selectively distributing information to a plurality of users, characterized by a unit for compiling contextual information and distributing adapted contexts associated with persons, the unit including a context manager and a rule engine. 5

31. A network according to claim 30, characterized in that the context manager and/or the rule engine are at least partly distributed, in particular executed in user devices.

32. A network according to claim 30, characterized in that the context manager comprises a context database means and a context distributor means. 0

33. A network according to claim 30, characterized in that the context distributor means comprise for each user an adapted database for distribution to other users.

34. A network according to claim 30, characterized in that the rule engine comprises means for context control and means for personal rules.

35. A network according to claim 34, characterized in that the means for personal 5 rules are distributed.

36. A network according to claim 35, characterized in that the means for personal rules are at least in part implemented at a mobile device.