1. Ubiquiplex The Scrap Devices Company Engineering: Joshua Doubleday Maksim Noy Jing Su Daniel Tran Steve Zhang Managed By: Daniel Howe Business: Eddie Chung Linda Pruitt George Donegan Matt Boos

2. Project Overview  Goal Create an infrastructure environment where the user's data is device independent and devices are automatically configured to the user using the device.  Principal elements  SpotON  Internet Connection  Applications  Profile Server  Platforms:  Video Wall  Compaq iPaq PDA  PalmOS PDA (maybe)  Business Plan

3. SpotON  RF-Based Location Sensing Based on Signal Strength  Connects through the serial port of a device  Senses other devices and radio tags  Developed and supported by Jeff Hightower  Portable protocol stack already exists for C/Java/VB  Jeff promises that it works great ;-)  Complexity and Unknowns  Need to do location calculations ourselves  What if two people walk up to a device at the same time?  Software implemented as a 3-thread model thus has to be rewritten for the Palm

4. Internet Connection  Connection to the Infrastructure  802.11b Wireless Ethernet  Available in PCMCIA for Video Wall and the iPaq PDA  Protocol used is XML over TCP/IP  Request: a SQL-like query/update expressed in XML  Response: a SQL-like response wrapped in XML  Policy: Update server whenever information changes  Complexity and unknowns  How to connect Palm devices?  Would like to be low-bandwidth enough so that it can be run over widely-deployed WAN infrastructures  Would like to work over Bluetooth but not in this version

5. Applications  Date book  Initial snapshot around current date/time is retrieved at sign-on; after that it’s on-demand  Address Book  Retrieved on-demand  Memo pad  Retrieved on-demand  Instant Messaging  Messages can be picked up from any device and disappear from all when they are  Open Architecture!  3 rd parties are free to write applications leveraging our platform

6. Profile Server  Description:  Handles sign-on/off, keeps the master copy of user’s profile  Distributes updates to all signed-on devices  Information store is mySQL  Written in Java for ease of development  Plug-in Architecture for easy extension  Complexity and unknowns  Possible concurrency and collision issues for updates of a single profile from multiple devices

7. Platforms: Video Wall  Description:  Access Point designed to be put in public places  “Magic Touch” touchscreen  On-screen keyboard  Implemented on top of a Windows 98 laptop  Applications written in VC++ with MFC  Heavily shares code with the iPaq implementation  Complexity and unknowns  How much of the code will need to be rewritten from the iPaq?

8. Platforms: iPaq PDA (WinCE)  Description:  Demonstrates a Scrap PDA  Also important since Win CE is the first platform we are deploying on according to the business plan  SpotON connects through the serial port  Applications written in VC++ with MFC  Code meant to be shared with the Video Wall  Complexity and unknowns  Limitations of WinCE when it comes to TCP connections, serial port access, threading, and 802.11b are not well- understood.  Possible porting issues to full Windows 98

9. Platforms: PalmOS PDA  Description:  Would demonstrate another Scrap PDA  Not likely to be done due to the complexities  Complexity and unknowns  Palm’s devices only have a single serial port so connecting a network connection (even a modem) and the SpotON is impossible for all practical purposes.  Handspring’s Visors appear to remove this limitation but network connection is still limited to a modem.  PalmOS only supports a single thread requiring a rewrite of the SpotON stack  Would not be able to reuse much of the iPaq code

10. Technology  New technology being used  SpotON  Standards being leveraged  802.11b, TCP/IP, XML

11. Demonstration plans  On sensing user’s SpotON pin, the Video Wall and/or PDA automatically configure themselves with user’s profile information. Multiple devices can be authenticated to and used at the same time with information instantly synchronized between them.

12. Business Plan  Company Name: "Ubiquiplex“ (from Ubiquitous + Multiplex)  Will attempt to enter the market by “riding the tablet and e-book wave”  First product: “u-book”  Plan to enter the UW Business Plan Competition

13. Schedule  4-10 Feb:  7 Feb, Update I  Client Apps working at a prototype level on iPaq  Server working at above prototype level  11-17 Feb  Client Apps working at above prototype level on both iPaq and Windows  Server at alpha level  18-24 Feb  Apps at alpha level on iPaq and Windows  Server at beta level  Server and Applications working together

14. Schedule (cont)  25 Feb – 3 March  2 March, Update II  Apps and Sever at beta level  Work on integration and bugs  4-10 March  Apps and Server at beta+ level  11-14 March  14 March, Final Demo/Report

15. Assessment of project  Strengths  Simple authentication  Separates data from devices  Standards-based  Weaknesses  Weak security  No offline operation

16. Current Status  High-level overview of progress  On-track:  Profile Server, SpotON  Behind:  Applications  Possible delays and issues  Problems with SpotON on PDA or Video Wall