ENABLING CONTEXT-AWARE SERVICES FOR MOBILE USERS

Transcription

1 ENABLING CONTEXT-AWARE SERVICES FOR MOBILE USERS Jukka Riekki, 1 Oleg Davidyuk, 2 Jari Forstadius, 3 Junzhao Sun, 4 Jaakko Sauvola Department of Electrical and Information Engineering and Infotech Oulu P.O.BOX 4500, University of Oulu, Finland Jukka.Riekki@ee.oulu.fi 1 Oleg.Davidyuk@ee.oulu.fi 2 Jari.Forstadius@ee.oulu.fi 3 Junzhao.Sun@ee.oulu.fi 4 Jaakko.Sauvola@ee.oulu.fi ABSTRACT We present an architecture that offers a set of generic services for building context-aware mobile applications. We present two realized prototypes that recognize user s context, learn his routines, use context information to constrain service discovery as well as to find relevant information, and manage connectivity on the basis of the given policy. Further, the user interfaces and applications are separated using a script language, and video message delivery is controlled based on presence information. We are not aware of any other prototypes offering equally wide context-aware functionality. KEYWORDS Context-awareness and mobile computing 1. INTRODUCTION According to the visions presented in the recent years by Weiser (1991) and many others, the future of technology and its users seems bright. A user can access any service at any place and at any time. The services adapt to the user s situation, her profile, and the resources provided by the local environment. Context-awareness is an essential ingredient in such services and hence an important research topic. In this paper, we present an architecture offering a set of generic services for building context-aware mobile applications for mobile users. The Capnet (Context-Aware and Pervasive Networks) architecture divides functionality into components from different domains. Components can be searched, downloaded, and started as required at run time. This allows the application structure to be adapted to the situation at hand. Furthermore, components are location-transparent and hence always communicate in the same fashion, regardless of whether they are located in the same address space or in devices far away from each other. The architecture specifies a service for obtaining context information, both synchronously and asynchronously as context events. Its other advanced features include data storage that associates documents with the context, dynamic and transparent connectivity adaptation, context-sensitive service discovery, asynchronous messaging between the applications. The main contributions of this work are the wide set of services collected into a single architecture, the wide usage of context, the ability of the services to adopt to the changes in the environment. We present the prototype that implements the architecture and demonstrates its features and abilities. The rest of the paper is organized as follows. The next section describes the architecture. The third section presents two prototypes and the experiments performed. The first prototype has the capacity of learning the user s behavior pattern according to context history. The second one offers various context-aware services for mobile users. Related work is discussed in the fourth section. The last section presents the discussion.

2 2. CAPNET ARCHITECTURE 2.1 Architecture The Capnet architecture divides functionality into components. A simple application consists of a single application logic component and some other components providing services for the application logic, all in the mobile device. At the other end of the continuum, the components in the mobile device and the network form a hierarchy, with the application requesting services from some components, which in turn request services from some other components. A few examples are shown in Figure 1. The functionality offered to the applications is divided into domains. Each component (that is not an application component) provides services to a given domain. The domains form a context-aware and pervasive middleware layer that offers a set of generic services for applications. In line with Bernstein s (1996) specification of middleware, this Capnet middleware masks the complexity of networks and distributed systems and thereby allows developers to focus on application-specific issues. Furthermore, it factors out commonly used functions into independent components, so that they can be shared across platforms and software environments. Component management domain controls all components and processes the requests of component access. Connectivity management domain controls communication channels in a dynamic and transparent fashion. The focus is on adapting the wireless connection of the mobile device. Service discovery domain locates resources and services, including other Capnet devices and components. A device hosting Capnet components contains the core component of each of these three domains. Components from the rest of the domains are optional. The media domain provides applications with a uniform interface for local and distributed multimedia capabilities. Context-based storage acts as a ubiquitous data storage. The user interface components create and manage application-specific graphical user interfaces on the basis of abstract descriptions provided by the applications. Figure 1. Component networks. Top left: one application (A) and three other (C) components in a mobile device. Top right: components in both a mobile device and the local environment. Bottom: components in remote environments are utilized as well. The context domain offers operations for obtaining context information, both synchronously and asynchronously, as context events. In addition to offering the context being experienced at the moment, it offers operations for learning the user s routines, i.e., recurring patterns of context and actions related to these patterns. An example is given in the section presenting the first prototype. The context domain manages the future context as well, e.g. it can produce an event informing the user that a meeting context is anticipated in 30 minutes.

3 The next subsections present the domains in more detail. As the context and context-based storage domains are responsible for the most complex data representations, these domains require more testing before they can be reported. 2.2 Components and Component Management A component is the smallest part of the Capnet architecture, i.e. the smallest distinguishable and identifiable entity used when building and managing applications. The resources needed by a component are specified in a component description that is presented in XML format. A component might, for example, pose special demands concerning processing power or memory space or require certain other components. Components are location-transparent, i.e. they always communicate in the same fashion, regardless of whether they are located in the same address space or far away from each other. Location transparency is achieved by using stubs. When a component wants to communicate with another, it requests from the local component management a reference to that component. If the requested component is running (or should be started) on a remote device, the request is forwarded to the component management of that device. Otherwise, the local component management downloads and starts the requested component, if it is not already running. In both local and remote cases, component management creates a local stub and returns the stub s reference to the requesting component, which can then start the communication. Component and connectivity management handle the messaging between the stub and the actual component. Stubs are used even between local components, as this approach keeps the component references valid even when components are moved on the fly. Component management, connectivity management, and service discovery make up a special triplet of components in the sense that other components always communicate with local instances of these core components. 2.3 Service Discovery Service discovery provides functionality for locating other components and services. When a component (client) needs the services of another component, service discovery tries to locate the components that offer the required service and provides a list of matches to the client. Based on that list, the client selects one component and asks component management to provide a reference to the selected component. Services are discovered for the user as well. One of the most apparent cases is the need to find services that are currently available and nearby. For example, when the user arrives in the meeting room, she may want to control with a mobile device a printer and a data projector located in the room. Another case of service discovery use is the need to find services that are available, but not necessarily in the vicinity, e.g. services that are near a hotel where the user is going to stay, or services providing information about stock quotes. Dynamic service discovery is also offered for automatically performing context-sensitive discovery. For example, the list of services shown at the mobile device s display can be automatically updated based on the user s context. The service discovery component uses different service discovery protocols, depending on their availability and suitability for the current situation. For example, a low-range Bluetooth protocol can be used when no other connection is available. The default protocol is an internal protocol based on a light, private XML registry running on the local device. This property allows service discovery to operate even when all other protocols are unavailable. 2.4 Connectivity Management Connectivity adaptation is realized by maintaining communication channels. A channel is a logical link between components located in different network devices. Various types of channels can be established, including HTTP channel, TCP/UDP channel, multicast and TCP listen channels. Thus, channel approach helps to hide complexity of network infrastructure and allows dynamic adaptation of the network services without interfering with ongoing communication. The clients, that are using channels are not able to see what network connection is utilized to transfer data. The connection can be switched from one network to another even without notifying the clients.

4 The connectivity management component monitors the context, including the status of the network, and adapts the channels connections as specified by the adaptation policies. A policy denotes the criteria for selecting the network interface. A static policy declares explicitly the network interface to be used for a particular channel, e.g. binding it to a static IP address or a concrete interface. An adaptive policy enables the connection to be switched during run time based on QoS parameters or cost, for example. Sun et al. (2003) and Davidyuk et al. (2004) discussed connectivity management component more in detail. 2.5 User Interface The User Interface (UI) component supports the design and implementation of application UIs using three different techniques: abstract UIs (XML), plug-in UIs (downloadable code) and web-based UIs (HTML). Abstract UIs are independent of any programming language, device type, operating system, or UI toolkit. This is achieved by separating the application from its UI implementation using an XML-based UI script language to describe the abstract UI elements and their properties. The UI component renders the actual UI implementation on the target device according to the script. The example of abstract XML-based UI script language is shown at the Figure 2. The UI component is responsible for managing the user preferences and modifying the UI to conform to context changes that affect the look and feel of the UI. The application logic is responsible for managing other context changes and modifying the UI abstraction accordingly as well as notifying the UI component of these changes. Multimodal input and output are provided using third-party components, such as ViaVoice from IBM (ViaVoice, 2003) for voice recognition and sound synthesis. The UI architecture is composed of UI core component, abstract UI, and platform UI layers. The applications and other components communicate with their UI implementations through the core component. The abstract UI controller, which is created separately for each application, is responsible for creating and modifying the application UI abstraction. The platform UI controller is responsible for creating and modifying the application UI implementation. It converts concrete UI events into their abstract counterparts and vice versa and manages input and output modalities. If the designer prefers to implement an application UI, or part of it, using a platform-specific UI toolkit, a UI plug-in can be used. The component takes care of downloading and initializing the plug-in code and showing the plug-in UI. Messages between the application and plug-in are mediated by the component. Another option is to use a web-based (HTML) user interface. A URL tag in the UI script causes the UI component to launch a web browser of the target device to open the page the URL points to. After that, communication between the application and the user interface embedded in the web browser occurs through the web infrastructure. More information about UI component can be found from paper written by Repo and Riekki (2004). Figure 1. An example of an XML user interface script (modified XUL) is shown in Source panel on the right. Corresponding user interface rendered by the Capnet User Interface component is shown in IPAQ simulation window on the left.

5 2.6 Media The media domain provides a unified interface for handling media over different platforms, which enables developers to focus on the media instead of the various underlying platforms. The Capnet component structure allows flexible chains of processing to be created for media processing. Traditional partition of media processing tasks into sources, filters, and sinks fits well into the component architecture allowing flexible configurations, which can be even distributed into network on-demand basis (Davidyuk et al, 2004). The component approach gives for the developers a choice to either use existing media components in their applications or to implement the components themselves. Registering a new component in service discovery makes it available to other developers as well and, therefore, a part of the media platform. Media is passed between the components as media objects. These objects can be atomic or composite. The relations between atomic media objects in composite media objects are described using the semantics provided by SMIL 2.0 (Synchronized Multimedia Working Group, 2001). Sharing of content between Capnet components is further enhanced by media messaging and media alert functionality. With media messaging, components and applications can pass media objects to each other in a peer-to-peer manner. Media alerts are event-based, and applications can subscribe for certain kinds of events to receive media objects when the specified event occurs. Distributed component structure also allows media analysis applications to support smart spaces, as devices for media capturing can be accessed from virtually anywhere, and processing can be dispersed in the network of devices. Such application scenarios are described in paper of Karunanidhi et al (2002). 3. PROTOTYPE AND EXPERIMENTS 3.1 Prototype for Reminders and Routine Learning The services offered by the first prototype can be described by the following short story: The user buys a new smart phone. In daily use, the device learns the user s habits of choosing the phone profile: normal, silent, loud, etc. The system may, for example, detect that the user switches the phone to the meeting mode whenever she enters a meeting room. The device may ask if the user wants this change to be done automatically. In addition, the user can attach location-triggered reminders to locations recognized by the system. This prototype contains the following application components: profile manager, reminder, and calendar. In addition, a personal assistant application is used to browse the available applications. Appointments are stored using the calendar application. The reminder application checks the user s calendar and requests the context component to be notified a certain time before the meeting. The profile manager gets information about the detected routines from the context components (the process of routine learning is described in more detail in paper of Pirttikangas et al (2004). The profile manager subscribes a notification about the user entering certain contexts and changes the phone s profile accordingly whenever it receives such a notification. The user context is based on the location, calendar, and device profile information. Figure 3 shows how the components co-operate to recognize the locations where the user has spent longer periods and which device profiles the user prefers at these locations. In the experiments a mobile device, Compaq ipaq PDA, equipped with WLAN card and Insignia s Jeode Java virtual machine, is used. Devices are located with the Ekahau positioning engine that utilizes WLAN signal strengths measured in the devices. Context-based storage utilizes the MySQL database, which is running as a server side component. The university s premises covered by WLAN are used as the test environment. The graphical user interfaces are described as extended XUL scripts that are rendered as AWT components in the PDA. All inter-device communications utilize XML-RPC; the open-source Marquee XML-RPC library is used. Service discovery is based on the Jini technology. Figure 4 shows the results of the experiments; the learnt locations and profiles.

6 Figure 3. The user s routine of setting the terminal to silent mode in the meeting room is learnt. 3.2 Prototype for Business Meeting The services offered by the second prototype can be illustrated by the following short story: Peter remembers at the airport that he should prepare a presentation for a meeting. He first checks remotely the services available in the meeting room. Then he prepares the presentation and associates it with the meeting. Next morning, his mobile device reminds him about the meeting. When he enters the meeting room, the available services are shown automatically on his mobile device s display. When it is his turn, he selects the data projector service. He is shown a list of files related to the meeting. He selects the correct file and starts his presentation using his mobile device. While he is giving the presentation, Susan tries to call him. The terminal informs her that Peter is in the meeting and asks her to leave a video message. Susan leaves a message and sends it. Peter is notified about the message after the meeting. He decides to view it later. The following application components have been implemented in this prototype: personal assistant, calendar, file browser, service browser, projector, profile manager, phonebook, and video messaging. File browser and service browser are context-sensitive user interfaces to context-based storage and service discovery, respectively. The projector application controls the physical projector, and the media application is used to capture, deliver, and show video messages. The prototype contains functionality from all domains. Component management is capable of starting components at run time; remote calls via stubs, and starting components remotely have been demonstrated as well. Dynamic application download and start-up are demonstrated when, for example, component management is requested to start the projector component. If this component is not available locally, component management downloads the component and starts it on the fly. The connectivity functionality required by the prototype has been implemented. Services can be registered and discovered using both an internal registry of service discovery and a Jini-based service discovery system. Services can be discovered from geographically remote locations and sorted according to their distance to the user. The user interface component provides all functionality required in the scenario. The user interface implementation can be modified during operation UI widgets can be added, changed, and removed. The designer may create customized UI widgets as plug-ins to UI implementation as well as web-based (HTML) user interfaces. Context component provides the types of context needed in the scenario as a synchronous service and asynchronous context events. All functionality of context-based storage has been implemented to store, retrieve, and organize user documents based on contextual information.

7 Figure 4. The locations and profile changes that were learnt when the first prototype was tested. Media components have been implemented for capturing images and videos, for processing and handling image and video data, and for media messaging and alerts. This prototype has been tested by researchers. The hardware and software environment was the same as in the first prototype except that we used IBM's J9 virtual machine and Flyview Fly-Cam CF with PDA. A laptop equipped with Windows XP and WLAN connection was used to host the projector service. The sequence diagrams presented in Figures 5 and 6 show some component level messages during the prototype s operation; details of the underlying architecture and communication have been left intentionally out. Figure 5. Peter prepares a presentation at the airport and is reminded about the meeting at home. The prototype provides to the user the services illustrated in the short story. Some experiments on dynamic connectivity adaptation have been made as well. Otherwise all the described functionality was provided by a single Capnet system, but video message sending and GPRS connectivity was demonstrated by a separate application because of the problems with a 3rd party codec. User experience testing has been started as well, but those results will be reported separately.

8 Figure 6. Peter s mobile device adapts to the meeting by changing the profile and listing the services available in the meeting room. Peter gives the presentation. 4. RELATED WORK We are not aware of any architecture covering such wide functionality as the Capnet architecture. As this paper focuses on a system offering a complete selection of general services to context-aware and pervasive applications, we do not present an extensive survey on individual domains but merely list some examples. In comparison to all the research listed below, the Capnet architecture provides to context-aware and pervasive applications a more complete selection of general services. Another major difference is the wide usage of context in the domain areas included in the Capnet architecture. Gaia OS (Roman et al, 2002) bears close resemblance to the Capnet architecture. The focus in Gaia is on matching the application to the devices available in the space, while we rather focus on mobile devices. Furthermore, in Gaia, various services are integrated into the kernel, whereas in the Capnet architecture these services are provided by separate components, and the minimum Capnet configuration can be small. In the Capnet architecture, the user I/O devices are wrapped as components providing services via interfaces, and the utilization of these resources is based on accessing them via a remote interface not via code mobility. BEACH (Tandler, 2001) is a software infrastructure providing support for constructing collaborative applications for meeting room environments. The system is similar to ours in the sense that software entities utilize widespread pervasive services available in the space. PIMA, imash, MetaGlue, and AURA (Banavar et al, 2000, Phan et al, 2001, Coen et al, 1999, Sousa, Garlan, 2002) also have similarities in that they tackle application partitioning and system structure reconfiguration in ubiquitous environments. The focus of all these projects is on component collaboration and I/O device utilization. Capnet's component-based structure and event mechanism are related to the event streams and operator graphs of Solar (Chen, Kotz 2002). Context-awareness has been previously widely studied. Dey et al. presented the Context Toolkit (Dey et al, 1999), which offers building blocks for context-aware applications following the conceptual model presented in the work. Schmidt's work on context-awareness (Schmidt, 2002) focused on implementing context-aware artefacts by adding sensing capabilities to everyday objects. Similar context-aware reminders, as presented in our first prototype, have been examined in multiple undertakings, including the commotion (Marmasse, Schmandt, 2000), CybreMinder (Dey, Abowd, 2000), and EventManager (McCarthy, Anagnost, 2000) systems. Furthermore, Lei et al. (2002) have realized a Context Service, a general middleware infrastructure for context collection and dissemination. Our approach is close to this work. However, our

9 focus is in general services consuming context information, not in the infrastructure producing context information. Connectivity management is closely related to the research on network-aware applications. Most research on network-aware applications (Bolliger, Gross 1998, Noble, Satyanaraynan, 1999, Joseph et al, 1997) focuses on network QoS parameters, such as bandwidth and delay. Connection fluctuation is taken into account by adjusting the data and content transferred. In Capnet, in addition to considering QoS parameters, a change in context can trigger a connection change, e.g. a new connection might become available as the user moves. The use of context-aware service discovery has been recognized and utilized by the creators of the Solar system (Guanling, Kotz, 2003). Czerwinski et al (1999) provide a secure service discovery service, which also uses XML-based descriptions and queries, such as Capnet service discovery. One difference is that Capnet utilizes context-aware discovery over standard third party service discovery protocols. The Capnet architecture supports the building of context-aware media applications, such as presented in papers written by Keranen et al. (2003) and Pan et al. (2002). An application can capture multimedia content, store it in context-based storage and later retrieve by using contextual information as keywords. Context information is not restricted to location information, as in paper written by Pan et al. (2002), or a pre-defined set of sources, as in paper written by Keranen et al. (2003), since the context component supports the handling of other types of context, such as meetings. Our UI framework differs from the related work in that it combines the techniques suggested separately by others: downloadable code (Newman et al, 2002), HTML and a web browser (Kindberg, Barton, 2001), and XML describing a UI abstraction (Vanderheiden et al, 2003). 5. DISCUSSION We presented an architecture that supports building context-aware applications for mobile users. The main contribution of this work is the wide usage of context; the wide set of context-aware services the prototypes offer for applications. Based on the experience that we have gained when building and testing the prototypes, we can conclude that the component-based approach was a good choice. Location transparency and the capability to load components at run time offer definite advantages. The component approach also facilitates extension of the Capnet system. DCOM,.NET, or CORBA components could have been used instead of defining our own component model and using XML-RPC for remote communications. The selected approach gives full independence of platform and language, gives full control over the implementation (e.g. switching channels of the fly), and produces a lightweight system. Server side component frameworks, such as EJB, were not suitable to our needs, as we need to run components on mobile clients as well. We have implemented the first two prototypes, which worked as expected. The architecture facilitated the construction of context-aware services, as the application developers could rely on the services offered by the Capnet components and concentrate on the application. In the prototypes, the role of context is obvious in supporting the user with automatic actions and presenting only the relevant information. For example, the reminder about the meeting is initiated by a context event, service browser shows the nearest services to the user, and file browser retrieves the files related to the current context from the context-based storage. We are studying the main issues in porting the architecture to the Symbian platform. Several new contextaware applications are being designed and implemented. The experience to be gained from this work will guide us in developing new architecture. Security and privacy are important issues, but they are currently waiting their turn on the task list. Finally, the need to develop knowledge representations is a major challenge that we are tackling by considering one application scenario at a time. The research will continue, and more extensive experiments will be reported soon. REFERENCES Banavar, G. at al Challenges: An application model for pervasive computing. Proc 6 th ACM MOBICOM, Boston, MA, pp

10 Bernstein, P.A., Middleware: a model for distributed system services. In Communications of the ACM. Vol. 39, Num. 2. ACM Press. pp Bolliger, J., Gross, T., A framework-based approach to the development of network-ware applications. In IEEE Trans. Software Engineering, Vol 24., Issue 5, pp Chen, G. et al, An open platform for context-aware mobile applications. In Proc First International Conference on Pervasive Computing, Zurich, Switzerland, June, pp Coen, M. et al, Meeting the computational needs of intelligent environments: The metaglue system. Proc MANSE99, Dubling, Ireland. Czerwinski, S.E. et al, An Architecture for a secure service discovery service. Fifth Annual International Conference on Mobile Computing and Networks (MobiCOM '99), Seattle, WA. Davidyuk, O. et al, Context-Aware Middleware for Mobile Multimedia Applications. In Proc 3rd International conference on Mobile and Ubiquitous multimedia (MUM2004), College Park, Maryland, USA, pp Dey, A.K., Abowd, G.D., CybreMinder: A context-aware system for supporting reminders. Proc 2nd International Symposium on Handheld and Ubiquitous Computing (HUC2000), Bristol, UK, pp Dey, A. et al, The Context Toolkit: Aiding the development of context-enabled applications. Proc CHI 99 Conference on Human Factors in Computer Systems, Pittsburgh, PA, pp Guanling, C., Kotz, D., Context-sensitive resource discovery. In Proc First IEEE International Conference on Pervasive Computing and Communications (PerCom 2003), IEEE Computer Society Press, pp Joseph, A.D., et al., Mobile computing with the Rover toolkit. In IEEE Trans. Computers, Vol. 46, Issue 3, pp Karunanidhi, A. et al, Video analysis applications for pervasive environments. Proc. 1st International Conference on Mobile and Ubiquitous Multimedia, Oulu, Finland, pp Keränen, H. et al, Sharing and presenting multimedia and context information within communities using mobile terminals. IEEE Conference on Multimedia and Expo, Vol.2, pp Kindberg, T., Barton, J., A Web-based nomadic computing system. In Computer Networks. Vol. 35, Issue 4. Elsevier, pp Lei, H., et al, The design and applications of a context service. In Mobile Computing and Communications Review. Vol. 6, Num. 4. ACM Press, pp Marmasse, N., Schmandt, C., Location-aware information delivery with commotion. Proc of the 2 nd International Symposium on Handheld and Ubiquitous Computing (HUC2000), Bristol, UK, pp McCarthy, J., Anagnost, T., EventManager: Support for the peripheral awareness of events. Proceedings of the 2 nd International Symposium on Handheld and Ubiquitous Computing (HUC2000), Bristol, UK (2000) Newman, M.W. et al, User interfaces when and where they are needed: An infrastructure for recombinant computing. Proc UIST 02, Paris, France, pp Noble, D., Satyanarayanan, M., Experience with adaptive mobile applications in Odyssey. In ACM Mobile Networks and Applications, Vol. 4, Issue 4, pp Pan, P. et al, M-Studio: An authoring application for context-aware multimedia. Proc 2002 ACM Workshops on Multimedia, pp Sun, J. et al, CME: a middleware architecture for network-aware adaptive applications. In proc. 14th IEEE International Symposium on Personal, Indoor and Mobile Radio Communications, Beijing, China, Vol. 1, pp Phan, T. et al, A new twist on mobile computing: Two-way interactive session transfer. Proc Workshop on Internet Applications (WIAPP 2001), San Jose, CA, pp Pirttikangas, S. et al, Know Your Whereabouts, 2004 Communication Networks and Distributed Systems Modeling and Simulation Conference (CNDS'04), San Diego, California, USA. Repo, P., Riekki, J., Middleware support for implementing context-aware multimodal user interfaces. In Proc 3rd International conference on Mobile and Ubiquitous multimedia (MUM2004), College Park, Maryland, USA, pp Roman, M. et al, A middleware infrastructure for active spaces. IEEE Pervasive Computing 1, pp Schmidt, A, Ubiquitous Computing - Computing in Context. Ph.D dissertation, Lancaster University. Sousa, J.P., Garlan, D., Aura: An architectural framework for user mobility in ubiquitous computing environments. Proc IEEE/IFIP Conference on Software Architecture, Montreal, pp Synchronized Multimedia Working Group of W3C, Synchronized Multimedia Integration Language (SMIL) 2.0 Specification. Tandler, P., Software infrastructure for ubiquitous computing environments: Supporting synchronous collaboration with heterogenous devices. Proc Ubicomp 2001, Atlanta, Georgia, pp Vanderheiden, G. et al, A standard for controlling ubiquitous computing and environmental resources from any personal device. Proc HCI International Crete, Greece. Vol. 2, pp ViaVoice, accessed November Weiser, M., The Computer for the Twenty-First Century. In Scientific American, September, pp