We illustrate the context influence on software applications in the following high-level scenario: Assume you are attending a meeting and someone wants to reach you via his cell phone (see picture below). However, since this is an important meeting, you may not want to be disturbed by such incoming calls. Therefore, the cell phone should provide a way to react to the context of use: You are currently in an important meeting - so phone calls should be signaled in a discreet way only. Assume further that an important relative of yours is currently in the hospital, and you want to be sure that you do not miss any call from the hospital. In this case, you want to receive a loud signal, even though you are in an important meeting.

What is important in this setting is the following: There are different context parameters that should influence the behavior of your device. Different context parameters may lead to different results in how the resulting behavior should look like. Finally, and this is a key issue, it is not only important what the context of your device looks like, but also what the context of the calling device is. Here, you may not know what the phone number or even the identity of the person is who will call you from the hospital. The only information you can rely on is the context of the calling device, which is the fact that the call originates from the hospital. In fact, you indeed want any call from the hospital to get through. So the resulting behavior on your device is potentially influenced by the contexts of one more device at least.

We are currently working on a solution based on roles for this type of scenarios.