a wireless web for creating and sharing personal content through handsets

1536-1268/05/$20.00 © 2005 IEEE ■ Published by the IEEE CS and IEEE ComSoc PERVASIVEcomputing 67

T H E S M A R T P H O N E

A Wireless Web forCreating and SharingPersonal Contentthrough Handsets

The wireless Web will be dominatedby the dissemination of personalcontent created by individuals inreal time. Today, a primitive form ofwireless personal content creation

and dissemination exists through camera phonesand carriers supporting multimedia messaging.

This format allows only point-to-point media distribution—the user takes a picture andsends it directly to another user.Like the wired Web, which hascreated an intricate ecosystem

for content creation and dissemination that’s verysuccessful for media sharing, the wireless Webwill evolve to enable a similar ecosystem.

Mobile handsets have evolved from voicetransmission devices to sophisticated digital assis-tants permanently connected to the Internet.These handsets now include hardware attach-ments that let users capture images and video andaccurately track handsets’ positions. These newfeatures combined with the terminals’ data trans-mission capabilities support a rich multimediainteraction model that enables users to share dig-ital assets directly from their mobile devices. Wecall this model the Personalized Group WideWeb. PGWW aims to provide a flexible, simple,and efficient mechanism to enable next-genera-tion cellphone users to share their digital assets.

The goalThe phone will become a personal repository

of digital assets, capable of exporting and sharingthem dynamically. These assets include

• personal context (for example, position, activ-ity, and time of day),

• personal media (for example, pictures andvideo captured from the devices), and

• personal data (for example, calendar entries,contacts, and tasks).

Existing solutions (see the “Related Work inMedia Sharing” sidebar) let users upload picturestaken from camera phones to a Web site. How-ever, these solutions are neither flexible nor sim-ple enough for average users. They provide limitedaccess control and distribution mechanisms, sup-port picture sharing only, and require users toupload pictures to a specific Web site. Once thepictures are published on the Web, users can’t con-trol them from the phone. Instead, they must loginto the Web site, which might be feasible for onlya group of knowledgeable users. Furthermore,these solutions are inefficient because users mustupload all pictures in advance, regardless of theirpopularity. Uploading the pictures on demandbased on their popularity would be more efficient,saving bandwidth if users request only a small per-centage of pictures. (Uploading all pictures is a

Increasingly sophisticated handheld devices provide an appropriateinfrastructure to host a highly dynamic wireless WWW variant. Thisvariant uses a flexible middleware infrastructure to overcome handsetheterogeneity and resource limitations.

Manuel Roman, Nayeem Islam, and Shahid ShoaibDoCoMo USA Labs

useful backup mechanism, but we con-sider backup an orthogonal issue.)

PGWW achieves flexibility by pro-viding mechanisms to share differenttypes of digital resources—including usercontextual information—and offeringfunctionality to configure resource visi-bility and access control policies. Thesystem also provides a mechanism thatallows notifying users about changes inshared resources, creating a more inter-active experience.

PGWW achieves simplicity by pro-viding all functionality from the hand-set and hiding technical issues and imple-

mentation details from end users. Forexample, the system relies on servicesrunning on the network to enableresource sharing. However, this networksupport is hidden from the users. Thephone remains the central control ele-ment at all times and users perceive thatsharing occurs among handsets directly.

Finally, PGWW achieves efficiency byleveraging a collection of middleware ser-vices hosted on the network. For exam-ple, we provide a caching mechanismthat can be configured to retrieve assetsfrom the handsets on demand. When thesystem receives a request for a resource

that hasn’t been cached on the network,the infrastructure contacts the handset,retrieves the asset, and stores it for futurereference. These services mediate directinteraction with handsets to preservetheir assets. Interaction with the hand-sets is minimized and only allowed whenstrictly required. Nevertheless, the hand-set still plays an active role in the process.

Exporting and sharingpersonal mobile assets

The media involved in PGWW ismostly personal in nature, generated ondemand, and shared with many individ-

68 PERVASIVEcomputing www.computer.org/pervasive


T he concept of groups sharing media over the Internet isn’t

new. Several approaches enable groups of users to interact.

Yahoo Groups (http://groups.yahoo.com) and other Web-based

collaborative systems such as Artefact1 let people exchange mes-

sages, pictures, calendars, and database entries. However, this

model isn’t customized for handheld users because it requires

uploading all the media from their handsets to a central server. The

Personal Group Wide Web model is based on the assumption that

media is exported directly from the handsets and can be automati-

cally moved to an intermediate server based on a number of prop-

erties such as number of requests or user preferences.

Blogging is a combination of a diary and guide site that lets peo-

ple publish media and links in real time to a Web site. Blogging has

no concept of group—once a person logs into the Web site, the

media he or she generates is visible to everyone. This system also

assumes a connection to a central server that hosts the blog. Hand-

set users don’t have tools that let them leverage their devices by

preprocessing some of the data. Furthermore, blogs have no

mechanism to notify users when other users post new media. Users

must periodically check for new additions.

Instant messaging lets users exchange messages in real time,

and it’s used worldwide. Instant messaging programs have been

ported to smart phones, letting users exchange messages any-

time. Although we can extend the middleware infrastructure for

our PGWW to support instant messaging, our original approach

is intended to let users post media that can be accessed by inter-

ested parties.

Event distribution in PGWW is very similar to publish-subscribe

systems in a mobile environment.2 In PGWW, a mobile device can

be a publisher and subscriber at the same time. Our current imple-

mentation supports mobility of the event distributor, which allows

for optimizations based on network topology, available bandwidth,

and CPU load. Pavan Deolasee and his colleagues propose adaptive

distribution of content based on available bandwidth and CPU

resources.3 We take this idea one step further by supporting adap-

tive distribution of not only media content but links as well.

The personal server presents a handheld device that stores users’

data and provides a wireless interface to interact with resources pre-

sent in the user environment.4 Instead of providing a display and a

traditional input mechanism, the personal server leverages existing

surrounding resources. Our project is similar to the personal server

in that we assume a device that hosts and exports users’ data, but

we differ in the functionality we provide. Our goal is to export the

personal mobile assets with other users.

Cooltown provides Web presence for the real world by associat-

ing dynamic Web pages to people, places, and things.5 We leverage

this concept and associate a dynamic Web page to every person.

REFERENCES

1. J. Brandenburg et al., “Artefact: A Framework for Low-Overhead WebBased Collaborative Systems,” Proc. 1998 ACM Conf. ComputerSupported Cooperative Work (CSCW98), ACM Press, 1998, pp. 189–196.

2. Y. Huang and H. Garcia-Molina, “Publish/Subscribe in a Mobile Environ-ment,” Proc. 2nd ACM Int’l Workshop Data Eng. for Wireless and MobileAccess (MOBIDE01), 2001, pp. 27–34

3. P. Deolasee et al., “Adaptive Push-Pull: Disseminating Dynamic WebData,” Proc. 10th Int’l World Wide Web Conf. (WWW10), ACM Press,2001, pp. 265–274.

4. R. Want et al., “The Personal Server: Changing the Way We Think aboutUbiquitous Computing,” Proc. 4th Int’l Conf. Ubiquitous Computing(UbiComp 2002), LNCS 2498, Springer-Verlag, 2002, pp. 194–209.

5. T. Kindberg et al., “People, Places, Things: Web Presence for the RealWorld,” Proc. 3rd IEEE Workshop Mobile Computing Systems and Applica-tions (WMCSA00), IEEE Press, 2000, pp. 19–28.

Related Work in Media Sharing

uals and groups. A fundamental aspectof personal-content sharing is spontane-ity, which must be reflected in the tech-nology that enables asset manipulation.From an end users’ perspective, the gen-eration, organization, and visibility ofpersonal assets must be as simple as plac-ing a phone call, sending email, or tak-ing a picture.

As Figure 1 illustrates, three elementsenable PGWW: personal mobile assets(consisting of personal context, media,and data) and two components used toexport and share these assets—a personalWeb page (exporting) and dynamicmedia distribution (sharing).

Personal context includes dynamicinformation relevant to the user, such ascurrent activity, time, status, and loca-tion. This information lets remote peerslearn about the user’s context and makedecisions, such as not calling while theuser is in a meeting or meeting at theuser’s current location. Because userscarry their mobile handsets regularly,handsets are ideal candidates for cap-turing and exporting users’ contextualinformation. Personal media includespictures, audio, and video captured fromthe handset, as well as documents storedin the device. Finally, personal dataincludes information such as calendarentries, contacts, and tasks, which usersstore in the handset and manage throughthe handset’s personal information man-agement applications.

The personal Web page is dynamicallygenerated and exports information aboutthe user’s personal context, as well aslinks to personal media and personaldata. (We use a Web page format becauseit’s the best accepted information-shar-ing mechanism; however, our infrastruc-ture can be easily extended to supportadditional mechanisms.) Both the net-work and the handset middleware services

implement the generation and servingprocess. The network acts as a mediatingagent between clients and the handset,interacting with the phone to obtainrequired data and caching the obtaineddata to avoid further interaction. Thisapproach minimizes resource use at thehandset while allowing it to play anactive role in the process. (We discuss thisin detail in the “Enabling MiddlewareInfrastructure” section.)

The dynamic media distribution com-

ponent provides functionality to proac-tively share with a group of peers mediaelements generated at the handsets.Through the personal Web page, whichprovides links to media elements storedon the phone, remote peers can accessthese media elements on demand. How-ever, based on the popularity of cameraphones and multimedia messaging ser-vices, we advocate for a model whereusers can subscribe to receive media ele-ments from a specific user or group of

APRIL–JUNE 2005 PERVASIVEcomputing 69

Personal contextActivity: MeetingStatus: BusyLocation: E10 RoomTime: 10:15 PST

CalendarTasksContacts

Europe trip picturesCurrentPosition.jpg

Assets export

Personal data

CalendarTasks Contacts

Personal context

LocationTime Activity Status

Personal mobile assets

Media share

Personal context

Personal data

Personal media

Personal Web page Dynamic media distribution

Personal media

DocumentsVideo Pictures Audio

Figure 1. Personal mobile assets, apersonal Web page, and dynamic mediadistribution together enable the Person-alized Group Wide Web—a wireless Webfor use on handsets.

users. Instead of periodically checkingthe remote personal Web page forupdates or waiting for the remote userto send the media, the dynamic mediadistribution automatically distributes themedia when it’s created (for example, theuser takes a picture) or as soon as theuser decides to share it. This functional-ity is essential to support the dynamismassociated with PGWW.

In PGWW, media generation involvesa moderate amount of media, which iscaptured or generated in real time andhas minimum or no post-processing dueto the casual model and the limitedresources of most mobile terminals. Thegenerated media is associated with a spe-cific event that implicitly defines themedia’s lifetime, which is normallyshorter than the one for the wired WWWmodel.

Media organization involves creatingsets of related media elements that areassociated with certain activities andhave a minimum maintenance cost.PGWW fosters a dynamic model wheredata organization is likely to change overtime. Media visibility allows specifyingrules to configure what sets of data arevisible to remote users. This is a key dif-ference between WWW and PGWW. Inthe former model, the default behaviorfor most noncorporate media is to makeall media accessible to everybody. How-

ever, the latter model assumes that mediais accessible to specific groups of indi-viduals. As a result, mechanisms mustconfigure the media’s visibility dynami-cally. Because of the data generation andorganization’s dynamism, media visibil-ity must provide functionality to notifygroups of viewers that the data has beenmodified.

PGWW is mostly characterized bydynamic behavior in which data genera-tion is frequent and data organizationand visibility varies according to useractivities or external properties. InPGWW, the same individual is responsi-ble for the media’s capture and organi-zation. Media isn’t explicitly uploaded toa Web site; instead, the PGWW cachinginfrastructure retrieves the data at run-time from the handset. Uploading all gen-erated media to a third-party server mightnot be feasible. Users might generatelarge amounts of media but only publishsmall subsets of it, or they might changethe visible subsets frequently.

Traditional Web site design requiressophisticated authoring tools. This can’tbe the case for PGWW, where the aver-age user isn’t technically savvy and thedevice isn’t appropriate for input/outputintensive applications. Publishing mediahas to be a simple and quick processbecause that’s the nature of personal con-tent. Also, personal content is short-lived

and requires no maintenance. We don’texpect users to create their personal Webpages by editing a text file or using a Webpage authoring tool—not only becauseof technical reasons but also because theassociated dynamism would require con-stant changes to the Web page. We pro-vide an infrastructure that generates theWeb page dynamically using predefinedtemplates (customizable) and policiesthat users provide to guide the Web pagecreation process. These policies assistalso in creating groups and assigning vis-ibility rules that define what data is avail-able to what users.

Enabling middlewareinfrastructure

The middleware services that supportPGWW leverage a software constructioninfrastructure we built called micro build-ing blocks.1 MBBs enable the creation ofadaptive software that we can configure,inspect, migrate, repair, and partition atruntime. As a result, we can decide thelocation of the infrastructure’s differentcomponents, and we can change theirlocation while preserving the system’sexecution.

Personal Web pageFigure 2 presents the middleware

infrastructure used to generate the per-sonal Web page dynamically and anexample of a personal Web page.

The dynamic content generator in-spects the context, data, and media asso-ciated with the user and generates anXML document with a summary of eachaspect, including text, multimedia ele-ments, and references to the resources.The policies and preferences control thesummary’s contents. The generator isdivided into three components thataddress each of the three aspects (con-text, media, and data) separately.

The policies and preferences reposi-



PersonalWeb pagegenerator

Personalcontext

summarygenerator

Personalmedia

summarygenerator

Personaldata

summarygenerator

Personal Webpage templates

repository

Policies andpreferencesrepository

Dynamic content generator

(a) (b)

Cache

Figure 2. Personalized Group Wide Webuses (a) a middleware infrastructure todynamically generate (b) the personalWeb page.

tory stores information that controlsaspects related to the personal Webpage’s generation and presentation, aswell as security issues. For example, gen-eration policies define cache use rules(maximum allowed data staleness) andinfrastructure partitioning (what com-ponents run in the server and what com-ponents run in the handset). Presenta-tion policies refer to a Web page’s layout,including which template to use, theposition of the dynamic data, andwhether to use text links or thumbnailsfor media elements. Security includesresource visibility and access control.Our current implementation relies onsimple presentation policies such aschoosing what resources to export andtheir layout on the Web page. We planto provide additional policies and con-figuration parameters as we gain moreexperience with the system.

The personal Web page templatesrepository stores static templates that arecombined with the dynamically gener-ated data. Templates let users create theirown personalized Web pages. The sys-tem also lets users select different tem-plates according to a set of conditions(presentation policies) such as requesteridentity, time of the day, and location oractivity of the user.

The cache stores previously generatedpersonal Web pages. The system sup-ports total or partial reuse of existingdata. For example, the context datachanges more often than the personaland media data. So, the system canobtain a previously generated Web page,update the context data, and maintainthe rest of the Web page.

The personal Web page generatorcoordinates Web page generation. Whenit receives a request to generate the Webpage, it checks existing policies and inter-acts with the cache (depending on thepolicies). Depending on the cache results,the personal Web page generator inter-

acts with the dynamic content generator,obtains the XML document, retrievesthe appropriate template, and generatesthe personal Web page combining thestatic template and the dynamic infor-mation contained in the XML file.

Figure 2b shows a sample personalWeb page hosted in a Sony-EricssonP900 (with GPRS coverage) andaccessed from a PC. For this example,the whole infrastructure is running in thephone. However, to preserve handsetresources, we have an alternative con-figuration in which the personal Webpage generator and the cache are hostedat the network, while the dynamic con-tent generator is hosted at the phone.The user selects the templates, prefer-ence, and policies from the handset, andthe middleware infrastructure runningat the handset propagates them to thenetwork side. With this configuration,the network processes the requests andcontacts the phone to obtain dynamicdata not present in the cache. The phonestill plays a key role in the infrastructure(hosts data and controls the configura-tion of the system) but leverages the net-work to preserve resources. However,network support is transparent to users.

Dynamic media distributionDynamic media distribution provides

functionality to export media and dataitems both proactively and on demand.The proactive functionality provides aprogrammable mechanism to distribute

resources and notifications to groups ofusers. It relies on three functional aspects:group and membership management,media sharing, and group notification.Group management includes support forgroup creation, edition, suspension,resumption, and termination. Member-ship management provides functionalityto add and remove members to and fromgroups as well as functionality to specifythe role of the members in the group.These roles restrict the operations themembers can invoke on the group.Media sharing involves functionality toexport and remove media from thegroups and to define visibility policiesthat affect the exported media. Groupnotification provides functionality tosend notifications to all the members ofa group. This functionality is required toinform members about changes in thestate of the group, including media addedand removed from a group.

Figure 3 illustrates the middleware ser-vices that support dynamic media distri-bution. It is a hybrid middleware splitbetween the handsets and the network.At the network side are the notificationcoordinator, the group coordinator, andthe media coordinator. The notificationcoordinator provides functionality todeliver notifications to groups of hand-sets, specify delivery semantics, and con-figure its behavior in case of communi-cation errors with the handsets. Thegroup coordinator provides functional-ity for group creation, deletion, and con-


Personal GroupWide Webbrowser

Mediamanager

Notificationmanager

Handset infrastructure

Groupcoordinator

Mediacoordinator

Notificationcoordinator

Network infrastructure

Localcache

Groupcache

Figure 3. A hybrid middleware infrastructure supports dynamic mediadistribution.

figuration, as well as functionality tomanage group members and group poli-cies. These policies include rules to spec-ify who can post resources and to definethe resource sharing semantics (mediadigests, media links, or the actual media).

The media coordinator implementsfunctionality to add, remove, retrieve,and inspect media items. The mediacoordinator also manages a cache thatstores group media items. By default,when posting a media resource, theresource is stored in the handset, and thehandset receives the requests for theresources—that is, the handset is respon-sible for serving the media. However, byusing a media distribution policy, it’spossible to delegate the functionality tothe network, which receives a copy andserves the media. This policy makes themedia permanently available, regardlessof the handset availability, and reducesthe number of requests sent to the sourcehandset. This reduces bandwidth con-sumption as well as resource use at thehandset. Both the group and media coor-dinators interact with the notificationcoordinator to inform group membersabout the changes in the group.

At the handset side, we provide thenotification manager, the media man-ager, and the PGWW browser. The noti-fication manager receives notificationsfrom the notification coordinator andinteracts with it to implement differentnotification delivery semantics. Themedia manager provides functionality toprocess media before interacting with themedia coordinator (for example, chang-ing the media’s format); to retrieve mediafrom remote handsets or the media coor-dinator; to manage the local cache andkeep it synchronized with the rest of thegroup; and to serve media items stored inthe handset. This functionality is cus-tomized to the device properties, userpreferences, and contextual properties.The PGWW browser provides function-ality to visualize incoming notifications

and media items and to manage groupmembership and policy management.Figure 4 shows a screenshot of thePGWW browser that presents the list ofmedia resources posted to the group.

The architecture presented in Figure 3provides support for configurable man-agement and caching policies. Based onmedia access patterns, requests fromother peers might easily overload hand-sets. As a result, media sharing becomesa challenge that requires the provisioningof media caching mechanisms that allowmedia migration between the handsetand the network automatically whilepreserving data consistency.2 Further-more, media sharing requires mecha-nisms to manipulate the media formatso it can be displayed in devices with dif-ferent capabilities.3 The group modelalso requires access control, authentica-tion, and privacy mechanisms. Differentusers have access to different sets ofmedia depending on the visibility poli-cies the media provider defines. Thisrequires an access control mechanism toenforce the visibility rules, as well as anauthentication mechanism to validatethe identity of the users submitting therequests, and privacy to preserve theconfidentiality of the data transmittedand sent, depending on the context.

Using the public key infrastructure hasproblems the literature has already iden-tified.4 However, work on how to adapt

the PKI infrastructure to collaborativeenvironments addresses some of theissues.5 Previous work also enablessecure media sharing among groups ofdevices,6 which PGWW can leverage toprovide certain security guarantees. Wedon’t consider security a separate mod-ule; we consider it functionality thataffects the design of the overall middle-ware infrastructure.

Media posting and distributionpolicies

Media posting refers to the transmis-sion of a media resource or a link fromthe handsets to the media manager, whilemedia distribution provides functional-ity to notify group members of newmedia. Every group has a default mediadistribution and posting policy, whichgroup members can override.

Content distribution sends the actualresource to the group members. Link dis-tribution sends the link to the resourceand therefore lets group membersretrieve the media on demand. With thecontent posting policy, the handset post-ing the media delegates the media serv-ing responsibility to the media manager.This policy is useful in situations wherethe posting handset doesn’t acceptrequests for media (for example, thehandset disconnects from the network).The link posting policy lets the handsetkeep ownership of the media and lets itget involved in the media retrievalprocess. This model is useful in situationswhere the generator doesn’t consider themedia to be popular. Therefore, it sim-ply sends a link to the media, and theremaining group members retrieve themedia on demand. Our current versionof PGWW provides three policies formedia posting and distribution.

In content posting and content deliv-ery, the handset sends the actual mediato the media manager, which saves themedia in the group cache and interactswith the notification coordinator to



Figure 4. Personalized Group Wide Webbrowser GUI.

deliver the media to all remaining groupmembers. This combination is useful forpopular media but is expensive in termsof bandwidth.

In content posting and link delivery,the handset sends the media resource tothe media manager, which stores it in thegroup cache and interacts with the noti-fication coordinator to distribute the linkto the media (media stored in the groupcache). This combination applies tomedium popular media and requires lessbandwidth than the previous model.

In link posting and link delivery, themedia generator sends the media-resource link to the media manager. Themedia manager interacts with the noti-fication coordinator and delivers the linkto all the group members. For a memberto retrieve the media, it has to interactwith its local media manager, whichsends a request to the media coordina-tor to retrieve the resource. Dependingon the cache policy, either the mediamanager gets the resource, stores it, andsends it back to the requester, or it sim-ply forwards the request to the targethandset. This combination applies tolow popularity media and consumes theleast amount of bandwidth.

The PGWW isn’t a replacementfor the WWW. It’s a com-plementary technology thatenables a digital ecosystem of

rapidly evolving media. PGWW’s goal isto allow groups of users to share mediarelated to their current activities, any-where and anytime. Unlike the WWW,this media is short lived, mostly generatedin real time, and intended for specificgroups of individuals. As media becomesstale, the PGWW can transfer it to theWWW to preserve it for future access.

The traditional WWW model is evolv-ing from a data-only sharing environ-ment to a service-sharing model based onWeb Services. We envision the same trendfor PGWW, which will start as a media-sharing mechanism but will evolve intoa service-rich environment that willenable the construction of shared appli-cations. The personalized and dynamicnature of PGWW will require new appli-cation models where different applica-tion aspects can be partitioned dynami-cally across group members.

We have completed the media distri-bution infrastructure and a prototype ofthe personal Web page infrastructure.The system is currently implemented in

J2ME (personal profile) and runs onpocket PCs and smart phones with sup-port for J2ME personal profile (forexample, Sony-Ericsson P900). Our cur-rent personal Web page constructionmechanism is simple and relies on statictemplates and policies to choose the loca-tion of the different resources. We chosea simple solution so nonexperts wouldbe able to use the system. We plan to pro-vide advanced configuration options thatwill let advanced users customize theirpersonal Web pages.

REFERENCES1. M. Roman and N. Islam, “Dynamically

Programmable and Reconfigurable Mid-dleware Services,” Proc. ACM/IFIP/Usenix 5th Int’l Middleware Conf., LNCS3231, Springer-Verlag, 2004, pp. 372–396.

2. P. J. Braam, “The Coda Distributed File System,” Linux J., June 1998; www.linuxjournal.com/article/2390.

3. E.D. Lara et al., “Collaboration and Mul-timedia Authoring on Mobile Devices,”Proc. 1st Int’l Conf. Mobile Systems, Appli-cations and Services (MobiSys 2003),Usenix Assoc., 2003, pp. 287–301.

4. C. Ellison and B. Schneier, “Ten Risks ofPKI: What You are Not Being Told aboutPublic Key Infrastructure,” Computer Secu-rity J., vol. 16, no. 1, 2000.

5. S. Dohrmann and C. Ellison, “Public-keySupport for Collaborative Groups,” Proc.1st Annual PKI Research Workshop, NIST,2002, pp. 139–148.

6. E.C. Epp, “Relationship Management:Secure Collaboration in a Ubiquitous Com-puting Environment,” IEEE PervasiveComputing, vol. 2, no. 2, 2003, pp. 62–71.

For more information on this or any other comput-ing topic, please visit our Digital Library at www.computer.org/publications/dlib.


the AUTHORS

Manuel Roman is a member of the Mobile Software Lab at DoCoMo USA Labs. Hisresearch interests include ubiquitous computing, middleware, and dynamicallyreconfigurable software. He received his PhD from University of Illinois at Urbana-Champaign. Contact him at DoCoMo USA Labs, 181 Metro Dr., Suite 300, San Jose,CA 95110; [email protected].

Nayeem Islam is vice president and director of the Mobile Software Lab at DoCoMoUSA Labs. His research interests include operating systems, middleware, security,and proof-carrying code. He received his PhD from University of Illinois at Urbana-Champaign. Contact him at DoCoMo USA Labs, 181 Metro Dr., Suite 300, San Jose,CA 95110; [email protected].

Shahid Shoaib is a member of the Mobile Software Lab at DoCoMo USA Labs. Hisresearch interests include operating systems, fault-tolerant systems, and ubiquitouscomputing. He received his BE from National University of Science & Technology inPakistan and is currently a graduate student at University of Southern California.Contact him at DoCoMo USA Labs, 181 Metro Dr., Suite 300, San Jose, CA 95110;[email protected].