Chapter 4
Context-Aware Computing

The success of mobile computing is contingent on how gracefully the system adapts to changes in the environment. In Chap. 1 we introduced two approaches to developing adaptive mobile systems: the application-transparent approach and the application-aware approach. The application-transparent approach uses system software, such as the underlying operating system and networking software, to adapt to changes in operating conditions, such as a substantial reduction in available bandwidth or a drop in the level of battery power, in an application-independent manner. In contrast to this approach, application-aware adaptation uses collaboration between the system software and the application software to adapt to changes in the availability of computing and communication resources.

A step further in the direction of application-aware adaptation is the context-aware computing paradigm. In context-aware computing, the application adapts not only to changes in the availability of computing and communication resources but also to the presence of contextual information, such as who is in the vicinity, the time of day, where the system currently resides, the current emotional state of the user, the action the user is performing, and the intention with which that action is being performed. A context-aware (or context-sensitive) application requires contextual information that must be gathered from various sources, such as sensors that are embedded in the environment, devices that are worn by end users, repositories of historical data tracking use of the application, and information contained in user profiles.

Let’s consider an illustrative scenario that demonstrates context-aware computing. For example, suppose that you are a tourist visiting Bombay (Mumbai), India, for the first time. You have your personal digital assistant (PDA) with wireless service from a service provider that covers Bombay. Being an adventurous tourist, you have not made hotel reservations in advance. Fortunately, you have a context-based Web information service (WISE) available to you from your wireless service provider. The first thing you do is ask WISE for suggestions for hotels. WISE takes into account information such as your itinerary, preferences (such as price range), and current location and provides you with a list of hotels that are nearby. You then select one of the hotels and invoke an online hotel reservation form. Most of the details in the form are filled in automatically based on your preferences, which the system reads from your user profile. For example, it knows that you prefer to pay the hotel bill using your credit card, which earns you frequent flier miles, and that you favor staying in nonsmoking rooms.

This chapter will discuss how such context-aware applications can be developed. In later chapters of this book we discuss various sensing technologies and their applications, along with communication protocols employed in sensor networks formed by these sensing devices. In this chapter we assume the existence of such an infrastructure and concentrate on issues related to design and development of context-aware applications such as (1) how contextual information can be provided to the application and (2) how the application can be developed to react to the changing contextual information.

4.1 Ubiquitous or Pervasive Computing

Pioneering work in context-aware computing was started in the early 1990s at Xerox PARC Laboratory and Olivetti Research, Ltd. (now part of AT&T Laboratories Cambridge), under the vision of ubiquitous computing. (Since the mid-1990s, ubiquitous computing also has been known as pervasive computing.) Marc Weiser, in his seminal paper entitled, “The Computers of 21st Century” (Weiser, 1991), envisioned that in accordance with Moore’s law, future computing environments would consist of very cheap (disposable) interconnected specialized computers all around us, some embedded in our surroundings and others worn by us (Fig. 4.1). However, if the usage model of ubiquitous computing systems follows the trend of the usage model of mainframe and personal computers, where a substantial effort is required on the part of users to accomplish any computing or communication tasks, then we would be constantly distracted by these numerous devices. The aim of ubiquitous computing is to design computing infrastructures in such a manner that they integrate seamlessly with the environment and become almost invisible. This is analogous to the “profound technologies,” such as the electric motor (a typical automobile has more than 25 motors) and writing technology (our environment is equipped with whiteboards, notepads, Post-It notes for various needs without being a distraction), that “weave themselves into the fabric of everyday life until they are indistinguishable from it” (Weiser, 1991).

Figure 4.1 Ubiquitous computing vision.

To meet the goals of ubiquitous computing systems, Weiser and Brown (1996) suggest designing calm computing technology, which, rather than always being at the center of our attention, empowers our peripheral attention and has the agility to move fluidly between the periphery and the center of our attention. Researchers in Project Aura at Carnegie Mellon University (http://www-2.cs.cmu.edu/~aura) have found that to minimize human distraction, ubiquitous computing systems have to be proactive in anticipating the future demands of the user and adaptive (self-tunable) in order to be able to respond better to future user demands. The ability to sense and process context is fundamental to making a system proactive and self-tunable.

In this chapter the emphasis will be on context-aware mobile computing. Understandably, this form of computing is essential to meet the goals of ubiquitous computing. Motion is an integral part of our daily life, and any ubiquitous system that does not reasonably support mobility of computing devices will have difficulty in becoming “invisible” to the user. Essentially, this form of computing is broader than mobile computing because it concerns not just mobility of computers but, more important, mobility of people.

4.2 What Is a Context? Various Definitions and Types of Contexts

As human beings, we are adept in our understanding and use of context in our daily activities. We routinely use contextual information, such as who is in our vicinity or where we are, to modulate our responses to or interactions with other people. As we mature, we learn which contextual information is important given a particular situation. For example, when we are with our close friends, we rarely worry about how we speak: “Like, you know what I mean.” However, in a formal situation, we are careful in what we say and how we say it.

To use contextual information in adapting applications, there should exist a means to capture, store, and process context. However, what exactly is context? Let us look at an English definition of context. Merriam-Webster’s Collegiate Dictionary defines context as “(1) the parts of a discourse that surround a word or passage and can throw light on its meaning; (2) the interrelated conditions in which something exists or occurs.”

The word context has its origin in the Latin verb contexere, meaning “to weave together.” However, such dictionary definitions of the word context are too general to be of much use in developing context-aware applications. These definitions do not help in determining what contextual information an application should try to acquire or how it should use the contextual information it has. Attempts to provide a computer-friendly definition of context has led to numerous definitions, falling under two broad categories: enumeration-based, in which context is defined in terms of its various categorizations, and role-based, in which context is defined in terms of its role in context-aware computing.

4.2.1 Enumeration-based

An example of a definition of context in terms of various categories is Chen and Kotz’s (2000) refinement of Schilit’s definition of context: Context consists of the following categories:

1. Computing context includes network connectivity, communication costs, communication bandwidth, and local resources, such as printers, displays, and workstations.

2. User context includes user profiles, location, and people in the vicinity of the user.

3. Physical context includes lighting and noise levels, traffic conditions, and temperature.

4. Temporal context includes time of day, week, month, and season of the year.

5. Context history is the recording of computing, user, and physical context across a time span.

As we develop and use increasingly context-aware applications, a universally acceptable definition of context may evolve. For now, we can try to identify some essential types of context using these lines from a poem by Rudyard Kipling to guide us: “I keep six honest serving men. They taught me all I knew. Their names are What and Why and When and How and Where and Who.” The following five W’s of context can form the core of different context types used by an application (Abowd and Mynatt, 2000):

Who (social context). This consists of information such as user identification and identification of people near the user. A context-aware system can use the identification of the person who is using the system to determine how to respond based on the user’s preference. For example, WISE used the user’s ID to get information about the preferences. Programs can use an end-user’s information to implicitly perform certain actions.

What (functional context). This consists of information about what tasks the user is performing.

Where (location context). This consists of information about where the system is currently located. This information can be raw location information, such as the latitude and longitude of the user, or it can be obtained at a higher level, such as the number of the room in which the system is currently operating. Location context is the most prolifically used type of context for developing context-aware applications.

When (temporal context). This is the same as the temporal context defined earlier.

Why (motivating context). This specifies why the user is performing a certain task. This is one of the most difficult types of contextual information to determine.

In addition to these different kinds of contextual information, one also can consider information such as a user’s emotional state (emotional context) and information about the environment, such as room temperature and illumination level (environmental context) (Satyanarayanan, 2002).

Context can be categorized further into low-level context and high-level context (Chen and Kotz, 2000). Low-level context information can be sensed directly using sensors or through simple processing, e.g., by accessing a database, e.g., room temperature or devices that are in the vicinity of a user. High-level context information may involve the amalgamation of low-level context information as well as sophisticated processing, such as machine vision or artificial intelligence (AI) techniques. For example, low-level context information such as the current location of the user and the current time can be combined from the user’s calendar to obtain information about a user’s current social situation, inferring that the user “is in a meeting,”, “attending a lecture,” or “waiting at the airport.”

4.2.2 Role-based

Perhaps a more useful way to discern what context is and how to use it is to look at context in terms of how it can be used by mobile applications. Chen and Kotz (2002) define context as “the set of environmental states and settings that either determines an application’s behavior or in which an application event occurs and is interesting to the user.”

Based on this definition, two types of context can be identified. Active context is the contextual information used by the application to adapt its behavior, whereas passive context is the contextual information that is not critical for application adaptation but is provided to the user to enhance his or her understanding of the situation (Chen and Kotz, 2002).

The task of building a context-aware application that adapts its response to so many different types of contexts is not only challenging but also quite daunting. Figure 4.2 illustrates the various types of contexts we have discussed. In the rest of this chapter we will discuss various existing software tools that aid in the development of context-aware applications. First, however, we will study different kinds of context-aware applications that have been developed by various researchers in industry and academia around the world.

Figure 4.2 Various types of contexts.

4.3 Context-Aware Computing and Applications

Context-aware computing devices and applications respond to changes in the environment in an intelligent manner to enhance the computing environment for the user (Pascoe, 1997). Context-aware applications tend to be mobile applications for obvious reasons: (1) The user’s context fluctuates most frequently when a user is mobile, and (2) the need for context-aware behavior is greatest in a mobile environment. At a minimum, context-aware applications should be proactive in acquiring contextual information and adapt their response based on the acquired information. The response itself can be proactive (automatically initiated by the system or application) or reactive (in response to the user’s request). A context-aware application can perform various tasks, which may include providing a context-aware user interface, presenting contextual and noncontextual information to the user, context-sensitive information services, and either proactive (such as automatic reconfiguration) or reactive (such as context-sensitive querying) context-aware adaptation of behavior.

4.3.1 Core capabilities for context awareness

Applications should posses some of the following capabilities in order to be characterized as context-aware (Pascoe, 1998):

Contextual sensing refers to the detection of various environmental states and how they are presented to the user. A basic context-aware application is one that presents the contextual information it obtains in a user-friendly form. For example, the location information obtained from a location sensor such as global positioning satellite (GPS) device can be presented to the user via a map display annotated with a “you are here” marker.

Contextual adaptation is the capability of the system to adapt its behavior by using contextual information.

Contextual resource discovery is the capability by which a system can discover available resources, which it can use to better adapt to the user’s needs.

Contextual augmentation refers to having the capability to associate contextual information with some digital data.

4.3.2 Types of context-aware applications

In order to get a better understanding of context-aware applications, let us now consider several different types of useful context-aware applications. In the past decade or so, various context-aware applications have been developed, and many methods for classifying context-aware applications have been proposed (Schilit, Adams, and Want, 1994; Dey, Salber, and Abowd, 2002). According to Schilit, Adams, and West (1994), context-aware applications can be classified along three different dimensions: function or service type, initiating agent, and adaptation (Table 4.1).

Table 4.1 Types of Context-Aware Applications (Schilit, 1994)

Function or service type.

Context-aware applications have been developed to perform various tasks. However, they can be broadly classified into applications whose primary task is related to providing information or actuating some command.

Initiation.

The context-aware application either can be initiated explicitly by the user (manual) or can be invoked implicitly by the application.

Adaptation.

Adaptation performed by a context-aware application consists of various types: information, system, user interface, and command (behavior).

Contextual selection refers to the selection and presentation of physical or virtual objects based on the user’s context. The most important type of contextual selection in mobile computing is proximity selection (Schilit, Adams, and Want, 1994), where the selection of objects is based primarily on the location context of the user, e.g., (1) selection of resources and devices such as printers or speakers in the vicinity of the user, (2) selection of places such as gas stations and restaurants closest to the current location of the user, and (3) selection or addressing of objects with which the user is currently interacting, such as the group of people in the room to whom the user wants to send information. Under the umbrella of ubiquitous computing, many other types of contextual selections are possible. For example, one can perform selection based on the social context of the user. An example might be a user who wants to get information about the items in his family members’ “wish list” when doing online Christmas shopping at the last minute. Another type of contextual selection is the selection of objects based on the temporal context of the user. As an example, consider a scenario in which you have made a large number of trips during the last summer and you would like to obtain a list of all the interesting people you met, along with their contact information.

Contextual selection applications need to employ various user-interface techniques to assist the user in the selection of objects in the physical or virtual world based on the user’s context. An important issue is how to present the information to the user so that the relevance of the information is implicit in the presentation. In proximate selection, applications may employ various visual effects to convey the relative ordering of the objects to the user. For example, different sized fonts can be used to display a spatial relationship between an object and the user (the closer the object, the larger is the font size).

In order to minimize computation and communication resources, a contextual selection application may fine-tune the granularity and accuracy of information presented to the user. Suppose that it is almost lunchtime, and you are driving around in an unfamiliar city looking for a restaurant. Under such a scenario, the application may update the information regarding closer restaurants more frequently than that of distant restaurants.

Contextual information applications modulate their responses based on the context of the user. In contrast, contextual selection applications provide information about the context itself. These applications can be viewed as parameterizing user’s queries with contextual information. The main contextual information that is used is the location of the user.

Similar to contextual information applications, contextual commands modulate their behavior based on the current context of the user. For example, a print command may, by default, print to the printer nearest to the user.

Automatic contextual reconfiguration applications automatically adapt the system configuration in response to a change in context. For example, the application may configure itself to use the display device available to the user.

Context-triggered actions are simple IF-THEN rules used to specify how context-aware software should respond automatically to contextual changes. The condition in the IF-THEN statement is based on the contextual predicates. There is an action associated with each IF-THEN rule that is performed when the associated condition becomes true.

4.3.3 Developing context-aware applications

In general, the following steps are used for developing context-aware applications:

1. Identifying relevant context

2. Specifying context-aware behaviors

3. Integrating with mechanisms for acquisition of contextual information

The first step is application-dependent, and the third step is platform-dependent. Thus we will not discuss them any further. Since the techniques to achieve the second step can be used in several applications, let’s look at two different approaches to specifying context-aware behavior: context-triggered actions and Stick-E notes.

Context-triggered actions

Watchdog and contextual reminder for active badges.

The Watchdog program was designed for a UNIX environment that is coupled with an Active Badge Location System. The Active Badge is an electronic tag that periodically broadcasts a unique identifier for the purpose of determining the location of the wearer. Events such as “arriving,” “departing,” and “settled in” are generated by the Active Badge Location System, which gives information about the mobility of the wearer. If the system does not hear from a certain badge for certain duration, a “missing” event is generated. The badge incorporates a single finger button that, when pressed twice, generates an “attention” event.

Watchdog monitors Active Badge activity and executes relevant UNIX shell commands as required. The user specifies the context-triggered actions in a configuration file when the Watchdog program is first started. The configuration file contains descriptions of Active Badge events and actions to perform in the following format:

The badge and location are strings that match the badge wearer’s ID and the last sighting location, respectively. The event-type is a badge event type: arriving, departing, settled-in, missing, or attention.

Whenever an event of the type event-type is generated by the badge at the specified location, Watchdog invokes the action with a set of UNIX environment variables as parameters, which include the badge owner, owner’s office, sighting location, and name of the nearest host. For example,

specifies that an Emacs window should start at a nearby host whenever the attention signal is received from tag john.

Contextual Reminders is an application for ParcTabs. Contextual Reminders provide a more expressive way of specifying reminders. The following example shows a set of predicates that makes use of date, time, location, and proximity to another person to trigger a reminder.

This is similar to the Stick-E Note system we describe next.

Stick-E note.

Stick-E Note is a technology that has been developed to facilitate the creation of context-aware applications by nonprogrammers (Brown, 1995; Pascoe, 1997). It is motivated by the paradigm of the Post-It Note, those yellow sticky notes used to put down reminders at prominent spots in one’s environment. The Stick-E Note is designed with the assumption that a user is moving around with a personal digital assistant (PDA). The PDA has wireless connectivity to a communication network and is equipped with various sensors. such as a GPS transceiver.

Each Stick-E Note consists of two parts:

1. Context. A context that the Stick-E Note is attached to, which can consist of a location, the identity of nearby users, and a time (where, who, and when).

2. Content. The content that the note represents. This could be information, actions, and interfaces.

A Stick-E Note is an Standard Generalized Markup Language (SGML) document with a context section and a body. The following is an example Stick-E Note that will display a reminder on one’s PDA to pick up a library book when the person is in the vicinity of a particular library:

The <at> tag identifies the location, in this case the library where the book is being held for the user. The <body> tag specifies the message to be displayed on the PDA when the user is at the Noble Engineering Library. This Stick-E Note only uses the location, or where, context. A point to remember here is that the note assumes an infrastructure for translating low-level contextual information (the current location coordinates obtained from GPS) and high-level contextual information (the user is in the vicinity of the Noble Engineering Library). This note can be modified to include optional information, such as a frequency for triggering (displaying) the note, as illustrated below:

This note will be triggered only once and will avoid the problem of the note being triggered repeatedly whenever the user happens to be in the vicinity of the library.

4.4 Middleware Support

Context-aware applications need support for the acquisition and delivery of contextual data. Several methods have been proposed to accomplish this. Some are general ways to handle any form of contextual data. However, since location information is the most widely used contextual information, many approaches have been developed for providing location context. There are, however, some issues common to any infrastructure that supports the acquisition and delivery of contextual information.

The main complication in developing context-aware applications stems from the very nature of contextual information:

1. It is acquired from various heterogeneous and distributed sources:

a. Hardware and software sensors—obtained from various sensors, such as motion detectors, noise and temperature sensors, and location systems.

b. System recorded input—such as user-system interaction history. Context information history is essential for applications such as context-based retrieval.

c. Other applications:

i. User’s personal computing space—such as those obtained from schedules, calendars, address books, contact lists, and to-do lists (Satyanarayanan, 2002).

ii. Distributed computing environment—such as those obtained from applications running in the vicinity of these devices, e.g., services provided by the infrastructure of a shopping mall or freeway system.

2. The same type of contextual information may have to be obtained from different sources at different times. For example, a mobile device’s location information may be acquired from GPS receivers if the mobile device is outside or from an indoor positioning system if the mobile is inside a building.

3. The low-level contextual information obtained directly from sensors must be abstracted to be useful to the application. As an example, GPS receivers provide location information in terms of latitudes and longitudes. However, a tour-guide application may need location information in a form such as “user is on Lemon Street going west” or “user is near Goldwater Center.”

4. Context awareness is most relevant when the environment is highly dynamic, such as when a user is mobile. Changes in the context must be detected in real time and conveyed to the applications as soon as possible so that the applications, particularly those using context-triggered commands and contextual automatic reconfiguration, have ample time to adapt their behaviors.

4.4.1 Contextual services

As we have seen, in order for an application to be responsive to a rich set of contextual information, it needs to interact with various distributed and heterogeneous sources. The task of developing context-aware applications can be facilitated greatly by a middleware infrastructure that can provide the following services (Dey, Sabler, and Abowd, 2001):

1. Context subscription and delivery service. A service to which applications can subscribe that delivers context events back to the applications.

2. Context query service. A service for applications to query current context.

3. Context transformation service. A service that transforms low-level contextual information into high-level contextual information. More generally, it transforms contextual information in one form into contextual information in a form suitable for an application.

4. Context synthesis service. A service that fuses various types of contextual information.

5. Discovery and management service. A service that helps in the discovery of available services and manages all the sensors and software components used by these services. Further, it can provide a “white page” service to enable applications to locate a particular service and a “yellow page” service to enable applications to obtain the set of available services having certain attributes.

4.4.2 Actuator service

As opposed to contextual services that help an application acquire contextual input from sensors, an actuator is a service that helps an application perform a context-dependent output function.

4.4.3 An example: context toolkit

Several general-purpose approaches have been designed to facilitate development of context-aware applications by freeing them from the low-level and tedious task of context acquisition. Hopefully, this will accelerate the pace at which context-aware applications are developed in the future. Currently, there exists no commercially available product. All systems that exist to date have been developed in academic projects. In fact, some of the systems we have described are still in development and may currently have additional features beyond those described here. In this section we describe Context Toolkit’s approach to providing support for developing context-aware applications.

Context toolkit.

The Context Toolkit, created at Georgia Tech, is developed around the paradigm of widgets, similar to GUI widgets used for developing graphic user interfaces (GUIs). It is an object-oriented framework that allows retrieval of contextual information through polling and callbacks. The toolkit provides several software components that a software designer can use for context acquisition:

1. Context widgets. A context widget is a software component that provides context acquisition and delivery service. A widget serves as an interface between sensors and applications. It provides an abstraction layer allowing access to heterogeneous and distributed sensors in a uniform manner. Every context widget has a state and a behavior. The state is a set of attributes, and the behavior is a set of callback functions that are triggered by context changes. As opposed to GUI widgets, context widgets are persistent entities that can be shared by multiple applications. Since historical information is useful for predicting the future actions or intentions of the user, context widgets can store all the contextual information they gather automatically and make the history available to the applications.

2. Context interpreters. A context interpreter provides a context transformation service to the application. For example, a tourist guide application can use an interpreter to convert GPS data to street names. A context interpreter also can be used to determine the high-level context, such as a social or motivating context. For example, a context interpreter can be used to interpret context from all the widgets in a conference room to determine that a meeting is in progress.

3. Context aggregators. Aggregators merge context data from various sources (context widgets and interpreters) to represent context that is associated with an entity. An entity can be a person, room, another software system, or a hardware device, among many possibilities.

4. Discoverer. A discoverer provides discovery and management services for sources of contextual information. It maintains a registry of the capabilities of widgets that exist in the framework. An application can use a discoverer to find a particular component with a specific name. It also can use a discoverer to find a set of components that match a specific set of capabilities.

4.4.4 Providing location context

In Chap. 2 we saw that tracking the location information (point of attachment to the network) of a mobile host is essential for delivering messages to it. In the realm of mobile and ubiquitous computing, the location of the mobile user (e.g., the room in which the user is located or the resources located near a user) can be exploited by various context-aware applications to adapt their behavior and to provide various location-sensitive services to the user. For example, knowledge of the room a user is in can be used by a teleporting application to automatically transfer a user’s desktop session to the computer nearest to her.

A location information system (LIS) provides location information to the application. A LIS locates objects representing either a person or resources inside areas (Spreitzer and Theimer, 1993). We are mostly interested in issues related to providing location information about people. A LIS can obtain location information about the user from various sources:

1. Indoor locating systems such as infrared-based active badges or ultrasound-based bats (Harter et al., 1999)

2. Wireless nanocell communication activity

3. Outdoor locating systems such as GPS

4. Device input activity from various computers

5. Motion sensors and cameras

6. Explicit information from the user.

Several issues relate to providing the location information of the user. First and foremost is the issue of privacy. Many people feel uncomfortable if their whereabouts are tracked continuously and are freely accessible to anyone. Thus it is important to provide user control over location information. Another important issue is the accuracy of the location information. There are two aspects to this: spatial resolution and temporal resolution of the locating system. Spatial resolution depends on the accuracy of the underlying sensing technology. Temporal resolution depends on such factors as how frequently LIS updates the location information of each user and how sensitive the sensing technology is (e.g., how small a change in someone’s location can the sensing technology detect). The accuracy of the location information has implications on the kinds of applications that can be implemented. For example, consider a technology such as the Active Badge, which provides room-level resolution. This enables teleporting applications such as migrating a user’s desktop session from the user’s office computer to a computer in the conference room. However, supporting applications, which require finer-grained location information, such as flicking a window from one’s laptop computer to that of a neighbor sitting next to the user, would be difficult (Spreitzer and Theimer, 1993).

4.5 Summary

Context-aware computing is a new and rapidly evolving field. Already we are seeing availability of context-aware applications. For example, the Google search engine has started using location information to provide location-dependent results to search queries (see http://local.google.com/lochp). We are seeing the emergence of proximity-based services, such as serendipity (created by a team of students at MIT; see http://edition.cnn.com/2004/TECH/ptech/03/19/mobile.dating.reut/), which match profiles of people stored on their cell phones to socially connect two strangers with similar profiles who happen to be close proximity of each other (about 10 m for Bluetooth-enabled cell phones). “Bluejacking” (see http://www.bluejackq.com/) is a trick one can pull on an unsuspecting stranger in close proximity who also happens to have a Bluetooth-enabled phone. By using your Bluetooth-enabled phone to first locate another Bluetooth-enabled phone in your proximity, you can then send a surprise text message, such as “I like your pink sweater ”

These are simple context-aware computing applications, but they illustrate the power to change the ways in which we interact and use computing and communication devices. This chapter has described some fundamental issues related to context-aware computing, such as what is a context and how can context-aware behavior can be specified, We also looked at some of the middleware support and services that are being developed to help in the development of more sophisticated context-aware applications.

4.6 References

Abowd, G. D., and E. D. Mynatt, “Charting Past, Present, and Future Research in Ubiquitous Computing,” ACM Transactions on Computer-Human Interaction 7(1):29, 2000.

Brown, P. J., “The Stick-E Document: A Framework for Creating Context-Aware Applications,” Electronic Publishing 8(2-3):259, 1995.

Chen, G., and D. Kotz, “A Survey of Context-Aware Computing Research,” Darthmouth Computer Science Technical Report TR2000-381, Hanover, NH, 2000.

Dey, A. K., “Understanding and Using Context,” Personal Ubi Comp 5(1):4, 2001 (http://link.springer.de/link/service/journals/00779/tocs/t1005001.htm).

Dey, A. K., D. Salber, and G. D. Abowd, “A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications,” Human-Computer Interaction (HCI) Journal 16(2-4):97, 2001 (http://www.cc.gatech.edu/fce/ctk/pubs/HCIJ16.pdf).

Harter, A., A. Hopper, P. Steggles, et al., “The Anatomy of a Context Aware Application,” in Proceedings of the Fifth Annual ACM/IEEE International Conference on Mobile Computing and Networking (MOBICOM ’99). 1999, p. 59.

Pascoe, J., “The Stick-E Note Architecture: Extending the Interface Beyond the User,” in Proceedings International Conference on Intelligent User Interfaces. Orlando, Florida, pp 261–264, 1997.

Pascoe, J., “Adding Generic Contextual Capabilities to Wearable Computing,” in Proceedings of the Second International Symposium on Wearable Computers (ISWC pp 92–99, Pittsburgh, Oct. 1998.

Satyanarayanan, M., “Challenges in Implementing a Context-Aware System,” IEEE Pervasive Computing 1(3):2, 2002.

Satyanarayanan, M., “Pervasive Computing: Vision and Challenges,” IEEE Personal Communications 8(4):10, 2001.

Schilit, W. N., N. I. Adams, and R. Want, in Proceedings of the Workshop on Mobile Computing Systems and Applications. New York: IEEE, 1994, p. 85 (ftp://ftp.parc.xerox.com/pub/schilit/wmc-94-schilit.ps).

Spreitzer, M., and M. Theimer, “Providing Location Information in a Ubiquitous Computing Envrionment,” in Proceedings of the Fourteenth ACM Symposium on Operating Systems, Ashville, NC, Dec. 1993. 1993, p. 270.

Weiser, M., “The Computer of 21st Century,” Scientific American, September 1991. 265(3): 94–104.

Weiser, M., and J. S. Brown, “Designing Calm Technology,” PowerGrid Journal 1(1): XX (No page number available since it appeared in an online journal), 1996 (http://powergrid.electiciti.com/1.01).