Final Report

About the Group
Description
Proposal

Parts List
Update 1
Update 2

Timeline
Status

Final Report

Summary
Description
Presentations
Appendices

Group Members:

Joshua Doubleday - d2@cs.washington.edu
Maksim Noy - mnoy@cs.washington.edu
Jing Su - jingsu@cs.washington.edu
Daniel Tran - dannyt@cs.washington.edu
Steve Zhang - steveyz@cs.washington.edu
group mailing list - 476scrap@cs.washington.edu

Summary

Abstract

The scrap device project is an effort to further bring invisible computing into reality. As our world begins to fill with ubiquitous computing devices, the attachment of data to devices and need to individually configure devices becomes a major obstacle to natural work.

Thus, the goal of this project is to create an infrastructure environment where the user's data is device independent. In this environment, devices are automatically configured to the user using the device. This allows devices to be multiplexed within an environment, allowing sharing of computing devices everywhere. Furthermore, to free the user from mundane authentication tasks, device authentication detection is done automatically based on the user's proximity or touch. By making the physical action of picking up or standing next to a computing device to be the authentication, the user's environment becomes an unbroken computing resource, allowing greater focus on the task at hand.

Elements of the project:

small, low power authentication beacon worn by users.
a scrap-able video-wall device, with only a touch screen interface.
one or more scrap-able personal data devices to access information.
an environment server infrastructure to store the user's profile information, and facilitate inter-user messages.
mini-XML data format for ubiquitous data transport and flexible support at the application level.
support third party vendors.

Status

At a limited level, we have reached all of our goals in some fashion. We have devices which are "scrap-able", we have a hands-free invisible authentication system, we have a profile server to separate the user's data from the devices, and we have compliant sample applications on the devices.

We used the SpotON devices for authentication/proximity beacons.
We developed applications for a video wall, simulated by a PC. We also developed applications for the iPaq. Unfortunately, development for the Palm platform fell through the hole and never got resurrected.
We do have a nice profile server accessible through TCP/IP.
We have created several sample high-level protocols and some 3rd party application tags.
3rd party vendors are able to develop for our framework, assuming they implement certain interfaces.

In brief, the SpotON tags didn't work for us as well as we had hoped. There's nothing wrong with the SpotON technology, but it just wasn't the best solution for our problem. Other technologies would have been better for us, but we did not realize this until late in the project, when it was too late to change.

We would have liked the devices to figure out for themselves who was within proximity and who wasn't. Instead, to simplify how the SpotON hardware was attached to the devices, we decided to have the devices get notified by a central "watcher", which would notify devices of proximity changes.

This proximity notification scheme change actually solved a big problem for us. Before, we could not find a way to attach a modem/network adapter to a Palm as well as a SpotON tag. But, by making devices receive notifications via TCP/IP from a central "watcher", there was no need to deliver proximity data from the SpotON device to the Palm. Unfortunately, this shift occurred near the middle of the project, and the Palm platform never got resurrected. Thus, we have no Palm platform.

Project Description

Specification

As computing devices become ubiquitous and tuned for specific functions, it becomes impossible to carry around different kinds of devices to access various pieces of one's data. In a closed infrastructure, such as a corporate environment, we would like to multiplex devices so that the devices are allocated in maximum utilization. The key to this is two fold. First, the user's data must be separated from device association. Second, the authentication mechanism for allowing a user to activate devices should be as seamless as possible.

Mini-Scenario:

ScrapTech is a high tech company that internally has a scrap device capable infrastructure. Within the company are several video walls, and many scrap-able PDA devices. We will briefly follow two employees, John and Lisa.

Lisa comes to work, and after authenticating her identity, puts on her authentication pin (i.e. the radio beacon). After walking by her mailbox to check for any snail-mail, Lisa picks up a scrap-able PDA. Instantly, the PDA is configured with Lisa's profile. Lisa checks her messages and schedule, and proceeds to attend her scheduled meetings.

John comes to work, authenticates himself, and puts on his pin. John is on his way to discuss project plans with Lisa when he happens to meet her in the hallway as she was leaving her meeting. John and Lisa walk to the nearest video wall. As Lisa walks up to the video wall, it automatically configures to her settings. Lisa brings up the latest project status document, and discusses it with John.

After the discussion, Lisa and John decide to set a meeting time for next week's status report. Since Lisa no longer needs her PDA, she hands it to John. Invisibly, the PDA becomes reconfigured with John's profile. Lisa arranges a meeting time on her schedule using the video wall, and John does the same on his PDA.