The MobiSoC Middleware for Mobile Social Computing:Challenges, Design, and Early Experiences

(Invited Paper)

Cristian BorceaDept. of Computer Science

NJITNewark, NJ 07102, USAborcea@cs.njit.edu

Ankur GuptaDept. of Computer Science

NJITNewark, NJ 07102, USA

ag59@njit.edu

Achir KalraDept. of Computer Science

NJITNewark, NJ 07102, USA

ak95@njit.eduQuentin Jones

Dept. Of Information SystemsNJIT

Newark, NJ 07102, USAqjones@njit.edu

Liviu IftodeDept. Of Computer Science

Rutgers UniversityPiscataway, NJ 08854, USAiftode@cs.rutgers.edu

ABSTRACTRecently, we started to experience a shift from physical com-munities to virtual communities, which leads to missed socialopportunities in our daily routine. For instance, we are notaware of neighbors with common interests or nearby events.Mobile social computing applications (MSCAs) promise toimprove social connectivity in physical communities by lever-aging information about people, social relationships, andplaces. This paper presents MobiSoC, a middleware thatenables MSCAs development and provides a common plat-form for capturing, managing, and sharing the social stateof physical communities. Additionally, it incorporates al-gorithms that discover previously unknown emergent geo-social patterns to augment this state. To demonstrate Mo-biSoC’s feasibility, we implemented and tested on smartphones two MSCAs for location-based mobile social match-ing and place-based ad hoc social collaboration.

Categories and Subject DescriptorsC.2.4 [Distributed Systems]: Distributed Applications;D.2.11 [Software Engineering]: Software Architectures;H.4.3 [Information Systems Applications]: Communi-cations Applications

General TermsDesign, Experimentation, Human Factors, Algorithms

KeywordsMobile social computing, middleware, smart phones

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.Mobilware’08 February 12-15, 2008, Innsbruck, AustriaCopyright 2008 ACM 978-1-59593-984-5/08/02 ...$5.00.

1. INTRODUCTIONSocial computing applications such as Facebook [1], MyS-

pace [2], and LinkedIn [3] improve social connectivity viacollaboration and coordination by enabling compelling andeffective on-line social interactions. However, these applica-tions lead to a shift from physical communities to virtualcommunities. Currently, people living or working in thesame places routinely miss opportunities to leverage inter-personal affinities (e.g., shared interests and backgrounds)for friendship, learning, or business through a simple lackof awareness. Furthermore, they are not aware of nearbyplaces and social events, which they would normally like tovisit or attend.

Mobile social computing applications (MSCAs) can takeadvantage of mobile computing algorithms, wireless tech-nologies, and real-time location systems to help people re-connect with their physical communities and surroundings.For instance, MSCAs can answer questions such as: Are anyof my friends in the cafeteria right now? Is there anybodywho would like to play tennis nearby? Do people who workon wireless come often to this place? Which are the placeswhere CS students hang out on campus? With researchshowing that users are increasingly willing to share theirprofile information and location in return for services, thetime is ripe to develop MSCAs that can answer queries andprovide recommendations about people, places, and eventsof interests anytime, anywhere [4].

This paper presents MobiSoC, a mobile social comput-ing middleware that provides support for programming anddeploying MSCAs. MobiSoC offers a common platform forcapturing, managing, and sharing the social state of phys-ical communities. This state is composed of people pro-files, place profiles, people-to-people affinities, and people-to-places affinities [5]. The social state evolves continuouslyover time as new user profiles, social ties, place-related in-formation, or events are created. Additionally, the consis-tent view of the social state provided by MobiSoC enablesalgorithms that discover previously unknown emergent geo-social patterns (i.e., people-to-people and people-to-placesaffinities), which can further augment the state. MobiSoCruns on trusted servers and provides a simple API for de-

veloping MSCAs. To improve the responsiveness and en-ergy efficiency on mobile devices, each MSCA is split intoan MSCA service that runs on top of MobiSoC on regu-lar servers and a thin mobile client that interacts with theservice and MobiSoC over the Internet.

MobiSoC was implemented using an extensible service-oriented architecture. Its core modules were implementedas Java services that run over the Apache Tomcat server.These services are exposed using KSOAP, a SOAP toolkitdesigned to work with lightweight versions of JAVA on mo-bile devices. To develop MSCA applications, it is essentialto collect accurate and continuous user location data bothindoors and outdoors. Furthermore, the location system hasto be cheap and easily deployable. Finally, it has to allowusers to control the sharing of location data for privacy rea-sons. Considering all these requirements, we chose Intel’sPlaceLab location engine that computes location on mobiledevices using the position and signal strength of visible WiFiaccess points. In our campus, we have at least three visi-ble access points almost everywhere, and consequently, weobtained an accuracy of 10 - 15 meters. We used MobiSoCto build two MSCAs: Clarissa, a location-based mobile so-cial matching application, and Tranzact, an application forplace-based ad hoc social collaboration. These applicationswere tested successfully on Windows-based smart phones,which connect to the Internet over WiFi.

The rest of this paper is organized as follows. Section 2presents an MSCA taxonomy and motivating examples. Sec-tion 3 discusses the main challenges that face MSCA devel-opment. Section 4 describes the MobiSoC design and ex-plains its core modules. Section 5 explains how to build ap-plications over MobiSoC and illustrates that with two proto-type applications. Section 6 contains implementation detailsand early experiences. We discuss related work in Section 7and conclude in Section 8.

2. APPLICATIONSMSCAs can be categorized into people-centric and place-

centric. This section illustrates each category with severalexamples. We assume that users carry mobile locatable de-vices, which can access services across the Internet usingeither short range wireless interfaces (WiFi, Bluetooth) orcellular interfaces. Furthermore, all these examples assumethat mobile users are willing to share their profile informa-tion (including location) with trusted applications under cer-tain privacy constraints.

2.1 People-Centric ApplicationsMobile Social Matching. This application leverages

geo-social patterns to provide enhanced social matching rec-ommendations. Users initiate the matching process by reg-istering a match request with the application, which holdsdetails about the desired match. For instance, a studentcan specify that she looks to hang out with a person withsimilar interests on Monday from 2PM to 6PM. The ap-plication uses real-time and historical location information,the social network graph, and the basic user profiles to com-pute affinities between potential matches. A match alert isdelivered to the mobile device when all the constraints forthe match are satisfied. In our example, the application canselect as best match a nearby student who shares commonfriends (known from the social network graph) and commoninterests (known from the location history analysis) with the

requester.Social Event Planner. This application can be used to

plan and generate invitation lists for events, such as semi-nars or outdoor activities. For example, if there is a seminaron Mobile Computing in the CS department building, theapplication can suggest people who should be invited to theseminar. The list includes department’s members who haveexplicitly listed Mobile Computing as an area of interests intheir profiles, but also people who visit frequently the net-working and systems labs. Additionally, the social networksof these people are searched for friends from other depart-ments that might be interested in the topic.

2.2 Place-Centric ApplicationsAd Hoc Social Collaboration. This application sub-

mits location-based queries to mobile users identified by cer-tain profile properties. For example, let us consider that auser sitting in his office might wish to know the current menuat the cafeteria (which is not posted anywhere except insidethe cafeteria). Since the user does not know who is in thecafeteria at that moment, the application helps her by iden-tifying members of her social networks which are there andasks them to answer the query. This application can also beused to deliver queries anonymously to any person who canprovide information about a certain place subject to privacyand reputation constraints.

Place Information. This application associates socialsemantics to a place based on the profiles and interests ofthe users who visit that place. Then, it could recommend theplace to users with similar interests or answer queries aboutit. For instance, a CS student looking for a place to hang outcould be recommended to visit the game room of the studentcenter on Tuesday evenings, when it is typically occupiedby CS students. Using the same application, the campusadministration can discover places which need improvementby checking the statistical information about places (e.g.,type, size, and demographics of the groups that meet at eachplace). For instance, the settings and ambiance in certainrooms of the student center can be modified according tothe number of students who spend time there.

3. CHALLENGESSocial computing applications in the Internet, such as

MySpace [2] and Facebook [1], have been very successful inthe past few years because they attracted millions of userswho generated a large amount of social content (e.g., profiles,photos, videos). Similarly, the very existence of MSCAs willdepend on achieving a critical mass of users, who share theirprofiles, places, and real-time location information. To beready to satisfy the demands of the users, if they are to useMSCAs, the software platforms for mobile social computingmust address the following challenges.

3.1 Social Data Collection and ManagementMSCAs require complex geo-social community data about

people and places. Static data such as people demographicsor places’ coordinates are easy to collect, manage, and val-idate. Dynamic data, on the other hand, are much harderto handle. For instance, a software platform supportingMSCAs must provide mechanisms to: (1) capture ties be-tween users and between users and places, (2) model, vali-date, and store these ties, and (3) effectively share commu-nity data among multiple applications.

3.2 Location Collection and ManagementMost MSCAs need users’ location data to function prop-

erly. Therefore, it is essential to provide infrastructure sup-port to collect real-time user location. Ideally, a locationsystem should be accurate, scalable, cost effective, easily de-ployable, work both indoors and outdoors, and allow usersto control the sharing of their location. No currently avail-able system has all these features, and in fact, some of thefeatures are contradictory. Therefore, system designers willhave to consider which are the most important features forMSCAs when choosing the location system. Furthermore,the software that collects the location and shares it withMSCAs must scale to a large number of concurrent locationupdates to accommodate a large user population and theneed of MSCAs to react quickly to location changes.

3.3 Learning Emergent Geo-Social PatternsCommunities have rich geo-social ties, which cannot be

captured directly from the user profiles. However, the col-lection of raw data about people and places over time couldbe used to determine emergent patterns which are not ap-parent otherwise. For example, users’ mobility traces (i.e.,location indexed by time) over a long period can be pro-cessed to learn their significant individual or group places.Furthermore, these places can be semantically enhanced byanalyzing the user-generated tags associated with them. Inorder to identify such patterns, we need to model the globalstate of a community and design algorithms which can ex-tract new knowledge out of this state.

3.4 PrivacyIn addition to the privacy issues for desktop-based social

computing applications, the software platform which sup-ports MSCAs must also cope with location privacy, whichis highly sensitive for mobile users. The MSCAs and theirsoftware platform must ensure that users cannot track eachother. An even more difficult privacy problem than track-ing is the inference of social ties based on location. Forinstance, if Bob is allowed to see John’s location, and hesees that John is too often located at Alice’s office, he mightinfer that they might have a romantic relationship. Whilesolutions exist for direct inference channels (e.g., databasequery evaluation), more research is necessary to prevent in-direct inference channels such as the one in this example.

3.5 Energy EfficiencyBattery power represents the most important physical lim-

itation faced by MSCAs developers. For example, the basicquestion asked by a user who plans to run such an applica-tion on her smart phone is: How long can I use my phone ifI run this application? Therefore, developers need to under-stand the power consumption characteristics of each com-ponent of the mobile devices in order to design energy ef-ficient applications and protocols. Trade-offs between localexecution on mobile devices and offloading application com-ponents to servers, which results in extra communicationcosts, must be considered. For instance, common compu-tationally intensive tasks required by multiple applicationsor multiple users should be offloaded to servers. Further-more, data aggregation methods should be designed to runat the servers in order to reduce both the computation andcommunication costs.

Figure 1: Social State of a Community

4. MOBISOC ARCHITECTUREThis section presents the design of MobiSoC, our mobile

social computing middleware designed to address the chal-lenges discussed in the previous section. A key goal of Mo-biSoC is to capture and manage the social state of a com-munity and to learn emergent social state information asillustrated in Figure 1. The basic social state of a physi-cal community is composed of people profiles, place profiles,social ties between people, and associations between peopleand places. This state evolves continuously over time asnew user profiles, social ties, place-related information, andevents are created. Additionally, learning algorithms candetermine people-to-people and people-to-places affinities,and based on these affinities, discover previously unknownemergent geo-social patterns. The newly discovered infor-mation can be used to augment the user profiles and thecharacteristics of the places.

MobiSoC acts as a centralized entity for social state man-agement and provides a service API to programmers forapplication development. We chose a centralized solutionbecause it is simpler to maintain a consistent view of the so-cial state and to provide access control to privacy sensitivedata. Additionally, having servers in the system architecturehelps to improve the battery lifetime on the mobile devicesas certain parts of the applications can be executed at theserver side. The MobiSoC architecture is presented in Fig-ure 2. The internal modules can be physically distributedon multiple servers in order to achieve scalable operationfor thousands of mobile clients. In the following, we presenteach of the middleware modules.

4.1 Data CollectionThe People sub-module allows applications to collect,

store, and modify user profiles. Besides basic demographicinformation, users can provide information regarding socialinterests, preferences, and social ratings. This sub-modulealso provides mechanisms to introduce new groups and addnew social contacts, and it maintains a social network basedon this information. The Places sub-module supports thecollection of geographical data and maps for buildings, of-fices, and outdoor locations. Furthermore, it provides mech-anisms to introduce and modify social events associated witha place. The Location sub-module receives and stores loca-tion updates from the mobile devices. We decided to deter-

Figure 2: MobiSoC Architecture

mine the location of the mobile device on the device itself forprivacy reasons. We believe that users would be very con-cerned if a certain hardware/software infrastructure wouldtrack them to determine their real-time location. There-fore, we allow them to control when and how often locationupdates are sent to our middleware.

4.2 Social State LearningThis module learns emergent social state information. The

People Profiling sub-module is used to provide user-centricinformation to services such as profiles, social links, and so-cial groups. Additionally, this module enhances user pro-files based on newly discovered information about individ-ual users. For example, this module could find out that auser attends research seminars regularly, plays tennis everyFriday, or works together with another user. Similarly, thePlace Profiling sub-module shares place-centric informa-tion and enhances the semantics of the place with socialinformation. For instance, this module could find out howcrowded a place is at different times in the day, popular so-cial events which happen at that place, or the demographicsdata of people who visit the place frequently. The People-People Affinity Learning sub-module computes socialaffinities based on factors such as similar interests, similarbackgrounds, common friends, or common places. Ad hocsocial groups can be discovered based on co-location in thesame place at the same time. Similar interests can be dis-covered if people visit the same place at different times. Asthe user and place profiles change over time, these affinitiesare re-computed periodically. The People-Place Affin-ity Learning sub-module analyzes users’ mobility tracesto identify significant places for individuals or groups. Todiscover these geo-social ties between people and places, itbasically performs temporal synchronization on the mobilitytraces and uses clustering techniques to determine repeateduser co-presence at a place.

4.3 Event ManagerThis module is used for asynchronous communication with

the applications. The applications can register events withthe middleware to receive notifications when a certain partof the social state changes. For example, an applicationmight want to be notified in real-time of the co-location oftwo users, a user presence at a given place, or a new social

Figure 3: Building Applications over MobiSoC

match based on newly identified social affinities. We decidedto let the mobile devices pull their events from the middle-ware instead of having the middleware push the events ontothem. There are two reasons for this decision. First, mo-bile devices change frequently their IP addresses, and themiddleware would have to be aware of them. Second, thedevices might not have Internet connectivity all the timebecause power savings mechanisms might turn off certainwireless interfaces or the users might turn off the devicesthemselves. In such situations, the middleware would haveto keep track of the status of mobile devices, on-line or off-line. In our architecture, the mobile devices poll periodicallythe middleware for event notifications. To reduce uselesscommunication which could impact the battery lifetime, ourimplementation, as illustrated in Section 5, takes advantageof the location engine running on mobile devices to retrieveevent notifications during the location updates.

4.4 Privacy Management and EnforcementThis module manages and enforces privacy rules on be-

half of the entities in the system (users and applications).Entities register their privacy preferences using a privacystatement, which has a primary entity that issues the state-ment and a secondary entity on which the statement applies.A privacy statement includes access control objects, infor-mation objects, and action objects. An access control ob-ject defines the conditions under which a statement applies.Currently, these conditions are user’s location, co-locationwith other users, time of the day, or a combination of theseconstraints. The information object defines the informationthat is restricted, and we currently support restrictions overlocation, events, profile data, and social network data. Theaction object describes the action to be taken in case thesecondary entity tries to access the information defined bythe information object. Currently, we support denial of ac-cess and sending an appropriate message to the secondaryentity, or forwarding the request to the primary entity thatcan further allow or disallow information access. More so-phisticated actions, such as removing only the privacy sen-sitive data from an object, will be added in the future.

5. APPLICATION DEVELOPMENT OVERMOBISOC

This section presents the general structure of any MSCAbuilt on top of MobiSoC, the MobiSoC’s development API,and code examples for two prototype applications, Tranzact

Figure 4: Middleware API

and Clarissa, successfully developed and tested on smartphones.

5.1 Application StructureEach MSCA is split in two parts: (1) an MSCA service

that runs on servers and accesses social state information us-ing the MobiSoC’s service API, and (2) a thin MSCA clientthat interacts with the MSCA service over the Internet. Fig-ure 3 shows how our prototype applications are divided intoclient and service parts. This application structure improvesthe responsiveness and energy efficiency on mobile devices.Essentially, the MSCA services offload the computationallyintensive components of the applications on the servers. Inthis structure, MSCA clients cannot interact directly withthe middleware; they can only interact with their associatedservices. Therefore, the programmers are naturally forced todesign the applications in the required structure. Anotherbenefit of this structure is that services can easily maintainglobal state across the mobile clients.

MSCA clients can communicate synchronously (i.e., re-quest/reply) with the services. However, many times theyneed to be contacted when certain social, temporal, or ge-ographical conditions are met. To achieve this goal, theMSCA services register events with the middleware, whichwill deliver them to clients. As illustrated in Figure 3, theevent notification delivery is done periodically when the mo-bile clients update their location with the middleware. Al-though this mechanism introduces a one location updateperiod delay, it improves the energy efficiency on the mo-bile devices. Once the location engine receives events fromthe middleware, it passes them to an Event Dispatcher thatsubsequently delivers each event to its target MSCA client.

5.2 API and Code ExamplesThe current API exposed to MSCA services is presented

in Figure 4. Since most of the function names are self-explanatory, we provide a very brief overview of the maincategories of functions. The event manager API allows ser-vices to register and delete events. The data collection APIis used to store data about people (profiles, social ties, andsocial groups), places (physical descriptions, user generatedtags that characterize them, and associated events), and lo-cation. The people profiling API provides access to people-centric data such as searching profiles by tags and keywordsor retrieving the social groups associated with a given user.Furthermore, the data returned by this API could containprofile data mined by the middleware (e.g., emergent pat-terns). Similarly, the place profiling API offers access toplace-centric data such as attendance and demographic pat-terns or history of social events that happened at a givenplace.

The people-place affinity API provides information aboutthe emergent visiting patterns at a given place, by individ-ual users or groups, as well as real-time data about the oc-cupants of a place. The people-people affinity API can beinvoked to retrieve social connections between two users.Specifically, it can return an affinity matrix between twousers, computed across several geo-social factors, commonsocial groups and ties, or the co-presence history. The pri-vacy manager API allows services to set and delete privacystatements as well as to check privacy constraints.

As more applications will be developed over MobiSoC, weexpect to add new functions or even to update existing ones.Besides the service API, we also provide a very limited APIfor MSCA clients on mobile devices to check the current lo-cation, enable and disable the transmission of location data

to the middleware, and listen for events from the local eventdispatcher.

Tranzact is an application for place-based ad hoc socialcollaboration. Its clients send queries for real-time infor-mation from various places. Figure 5 shows the processingdone by the Tranzact service when it receives such a query.For instance, the requester might want to find out the cur-rent menu at the cafeteria (which is not posted anywhereoutside the cafeteria). In order to answer the query, whilenot bothering strangers, Tranzact starts by identifying thesocial contacts of the requester that are currently in thecafeteria. This task is achieved through two function callsto the People Profiling module and People-Place Affinitymodule. Before sending the query, Tranzact verifies if thepotential destinations are willing to accept events from thisapplication. In this case, the privacy constraints, verifiedthrough the Privacy Management module, are set by a userfor herself (i.e., when and where she wants to receive Tran-zact events). The available users receive the request usingour event-based communication mechanism. Responses aresent back through the same mechanism.

Clarissa is a location-based mobile social matching ap-plication. Figure 6 illustrates the processing done by theClarissa service when a student has a two hour break be-tween two classes and is looking for a hangout partner oncampus. This person must be available between 2PM and4PM, and she must be in close proximity of the requester.Additionally, she has to be either someone known by the re-quester or someone who shares common interests (in this ex-ample, we look for sports they play and music preferences).The service gets the union of known people, social contactsand members of common groups, from the People Profilingmodule. Then, it computes a matching score with all theremaining users. This score is computed by assigning higherweights to certain affinity factors (i.e., sports and music).The raw affinity scores are retrieved from the People-PeopleAffinity module. Once the potential matches are identified,Clarissa registers events for the requester, which are trig-gered by the co-presence with potential matches during thespecified time interval.

6. IMPLEMENTATION PROTOTYPE ANDEARLY EXPERIENCES

We built a prototype implementation for MobiSoC usinga service-oriented architecture, which supports evolution byproviding modularity, extensibility, and language indepen-dence. The core middleware modules are implemented asservices and written in JAVA. They run over the ApacheTomcat application server and store data in a PostgreSQLdatabase, which provides good support for GIS data such asmaps and place related information. MSCA clients run oniMate and htc TyTN smart phones. WebSphere EveryplaceMicro Edition Java (WEME) [6] was selected as the JavaMicro Edition implementation because it runs reliably onour smart phones with ARM processors and Window Mo-bile operating system. Personal Profile 1.0 and MDIP 2.0 isthe minimum configuration required.

We had a number of options for communication betweenclient applications on mobile nodes and the application ser-vices on the server. Since our services are written in JAVA,the easiest way would have been to serialize Java objectsand send them over sockets, but this option does not pro-

Figure 5: Tranzact pseudo-code

Figure 6: Clarissa pseudo-code

vide for language independence. The next option consideredwas to use a lightweight parser [7] to convert JAVA objectsto XML and then transport these objects over TCP. Unfor-tunately, we found compatibility issues between the JAVAmobile edition library (J2ME) and the parser. Finally, wedecided to expose our services via the Simple Object Ac-cess Protocol (SOAP). SOAP offers language independence,and SOAP clients are available for many popular languages.Additionally, it provides a clean transport mechanism, withthe client and services communicating over HTTP. We useKSOAP J2ME [8] library that implements a subset of SOAP1.1 and has a memory footprint less than 50KB. This makesit extremely suitable for resource constrained devices such assmart phones. Furthermore, the KXML parser provides fastperformance comparable to XML-RPC, yet provides sup-port for custom data types.

The location engine on the clients is a modified version ofIntel’s Place Lab software [9]. This engine estimates the userlocation based on the location and the signal strength of theWiFi access points visible from the mobile device. Mobiledevices hold a database consisting of access point names andtheir locations in the area of interest. When a mobile devicereceives beacon messages from the visible access points, itretrieves each access point’s coordinate from the database

and computes the estimated user position by averaging thelocation of the access points. We also implemented a fin-gerprinting based algorithm, such as the one described in[10], to improve the location accuracy. Currently our sys-tem provides room level accuracy (10-15 meters). However,a significant problem that we observed is that accuracy dif-fers significantly (up to 10 meters) for different mobile de-vices. In the near future, we plan to investigate solutionsthat accommodate device heterogeneity.

While this location engine provides many benefits, we hadconcerns about its power consumption on mobile devices. Toquantify the effect of the location engine on the overall en-ergy consumption on smart phones, we ran experiments inwhich the location was computed and delivered over WiFiat intervals between 10 seconds and 1 minute [11]. For theseexperiments, we used the centroid version of the locationcalculation. The results showed that the battery lifetimelasted between 4 and 6 hours, which translates into a con-sumption of 25%-50% of the total battery power. The mainconclusion is that adaptive strategies are necessary to com-pute and deliver the location in real-time in order to reducethe energy consumption. For instance, the location can beupdated only when users move more than a certain thresh-old. Furthermore, social knowledge can be used to decreasethe frequency of the updates or even to turn off the enginefor certain periods of time (e.g., attending weekly meetingsor classes).

While the People-to-People Affinity module of the middle-ware is relatively straightforward to implement, the People-to-Places Affinity module is more difficult due to the addi-tional uncertainties added by the location errors. The firstalgorithm which we developed for this module is GPI, analgorithm which learns previously unknown ad hoc socialgroups and their meeting places [12]. The middleware canshare the results of GPI with geo-social recommendation ap-plications subject to privacy constraints. For instance, newstudents can learn about popular hangouts on campus orfaculty could learn about students attending research sem-inars on certain topics. Our theoretical analysis and simu-lation results demonstrated that 90%− 96% of group mem-bers can be identified with negligible false positives whenthe user meeting attendance is at least 50%. Experimen-tal results using one-month of mobility traces collected fromsmart phones carried by students and faculty on our campussuccessfully identified all groups that met regularly duringthat period. Additionally, the group places were identifiedwith good accuracy.

7. RELATED WORKA number of projects developed toolkits and middleware

architectures for mobile context-aware applications. Aura [13]is a middleware architecture that allows mobile applicationsto adapt to dynamically-changing resources. GAIA [14] pro-vides dynamic resource discovery in ubiquitous computingenvironments and system configuration according to the avail-able resources. One.world [15] provides a framework fordeveloping pervasive computing applications with a focuson resource discovery and migration to cope with chang-ing usage environments. The context toolkit [16] presents aconceptual framework that supports the acquisition, repre-sentation, delivery, and reaction to context information.

Context-aware migratory services [17] is a distributed pro-gramming framework that provides a client-server model in

mobile ad hoc networks (MANETs), where services migrateto different nodes to maintain a semantically correct andcontinuous interaction with clients. A similar idea in a differ-ent context is presented in the MUM middleware [18], whichaims at relieving mobile services from the burden of main-taining service continuity in dynamic environments, withmultimedia services moving among different wireless accesspoints. REDMAN [19] is a middleware that disseminates,manages, and retrieve replicas of resources of common inter-est made available by cooperating nodes in dense MANETs.Spatial Programming [20] is a runtime system that providesan imperative programming model for distributed applica-tions in MANETs using location and properties to namethe nodes of interest. Contory [21] is a middleware for con-text provisioning on smart phones that provides an SQL-like interface to query context data across the Internet orMANETs.

A number of mobile social applications have been previ-ously developed. Lovegetty [22] is a wireless-enabled, spon-taneous matchmaking device that works within its limitedradio transmission range. Social Net [23] infers shared in-terests between people by storing the IDs of the nearby de-vices and analyzing this co-location data collected over along period of time. Social Serendipity [24] is another sim-ilar mobile phone-based application using Bluetooth and adatabase of user profiles to recommend face to face interac-tions between nearby users who share common preferences.GeoNotes [25] allows users to post virtual notes at places,which can be read by other users visiting the same place.Context-aware recommender systems which can assist userswith shopping are presented in [26, 27]. The Active Cam-pus [28] project is also host to several social computing ap-plications built on top of a centralized client-server architec-ture.

8. CONCLUSIONSThis paper presented MobiSoC, a middleware that pro-

vides a common platform for rapid development and deploy-ment of mobile social computing applications. This mid-dleware captures the social state of physical communities,learns previously unknown patterns from the emergent geo-social data, and augments the social state with this newknowledge. Additionally, it provides mechanisms to sharesocial state data, in real-time, with applications running onmobile devices, while respecting user’s privacy concerns. Weimplemented MobiSoC as a flexible service oriented architec-ture and used it to build Tranzact and Clarissa, two proto-type applications running on smart phones. MobiSoC wasdeveloped as part of the SmartCampus project [29], whichinvestigates the benefits of mobile social computing in uni-versity campus settings. As this project will provide severalhundred students with smart phones, we will be able to testour middleware and applications in a real-life large scalecommunity.

9. ACKNOWLEDGMENTSThis material is based upon work supported by the Na-

tional Science Foundation under Grants No. CNS-0454081,IIS-0534520, CNS-0520033, and CNS-0520123. Any opin-ions, findings, and conclusions or recommendations expressedin this material are those of the authors and do not neces-sarily reflect the views of the National Science Foundation.

10. REFERENCES[1] Facebook (2004). http://www.facebook.com.

[2] MySpace (2003). http://www.mysace.com.

[3] LinkedIn (2002). http://www.linkedin.com/.

[4] Q. Jones, S. Grandhi, S. Karam, S. Whittaker,C. Zhou, and L. Terveen. Geographic place andcommunity information preferences. In Journal ofComputer Supported Cooperative Work. 2007.

[5] Q. Jones, S. Grandhi, L. Terveen, and S. Whittaker.People-to-people-to-geographical places: The P3framework for location-based community systems. InJournal of Computer Supported Cooperative Work.Kluwer Academic Publishers, 2004.

[6] Weme: WebSphere Everyplace Micro Edition.www.ibm.com/software/wireless/weme/.

[7] Xstream: JAVA-XML parser.http://xstream.codehaus.org/.

[8] Ksoap: Simple object access protocol for J2ME.http://ksoap.objectweb.org/.

[9] B. Schilit, A. LaMarca, G. Borriello, W. Griswold,D. McDonald, E. Lazowska, A. Balachandran,J. Hong, and V. Iverson. Challenge: UbiquitousLocation-Aware Computing and the Place LabInitiative. In Proceedings of the 1st ACM InternationalWorkshop on Wireless Mobile Applications andServices on WLAN (WMASH 2003), San Diego, CA,Sep 2003.

[10] Y. Cheng, Y. Chawathe, A. LaMarca, and J. Krumm.Accuracy Characterization for Metropolitan-scaleWi-Fi Localization. In Proceedings of Mobisys 2004,Washington, DC, 2004.

[11] A. Anand, C. Manikopoulos, Q. Jones, and C. Borcea.A Quantitative Analysis of Power Consumption forLocation-Aware Applications on Smart Phones. InProceedings of the 2007 IEEE InternationalSymposium on Industrial Electronics, pages1986–1991, June 2007.

[12] A. Gupta, S. Paul, Q. Jones, and C. Borcea.Automatic Identification of Informal Social Groupsand Places for Geo-Social Recommendations. In theInternational Journal of Mobile Network Design andInnovation. To Appear. 2008.

[13] J. P. Sousa and D. Garlan. Aura: an architecturalframework for user mobility in ubiquitous computingenvironments. In 3rd Working IEEE/IFIP Conferenceon Software Architecture, pages 29–43. KluwerAcademic Publishers, Aug 2002.

[14] M. Roman, C. Hess, R. Cerqueira, R. H. Campbell,and K. Nahrstedt. Gaia: A middleware infrastructureto enable active spaces. In IEEE Pervasive ComputingMagazine, volume 4(1). Oct-Dec 2002.

[15] R. Grimm, J. Davis, E. Lemar, A. MacBeth,S. Swanson, T. Anderson, B. Bershad, G. Borriello,S. Gribble, and D. Wetherall. System support forpervasive applications. In ACM Transactions onComputer Systems, volume 22(4), pages 421–486. Nov2004.

[16] A. K. Dey, D. Salber, and G. D. Abowd. A conceptualframework and a toolkit for supporting the rapidprototyping of context-aware applications. InHuman-Computer Interaction, volume 16(2-4), pages97–166. 2001.

[17] O.Riva, T. Nadeem, C. Borcea, and L. Iftode.Context-aware Migratory Services in Ad HocNetworks. In IEEE Transactions on MobileComputing, volume 6(12), pages 1313–1328. December2007.

[18] P. Bellavista, A. Corradi, and L. Foschini. MUM: AMiddleware for the Provisioning of ContinuousServices to Mobile Users. In Proceedings of the 9thIEEE International Symposium on Computers andCommunications (ISCC’04). IEEE Computer SocietyPress, Jun 2004.

[19] P. Bellavista, A. Corradi, and E. Magistretti.Comparing and Evaluating Lightweight Solutions forReplica Dissemination and Retrieval in DenseMANETs. In Proceedings of the 9th IEEEInternational Symposium on Computers andCommunications (ISCC’05). IEEE Computer SocietyPress, Jul 2005.

[20] C. Borcea, C. Intanagonwiwat, P. Kang, U. Kremer,and L. Iftode. Spatial Programming using SmartMessages: Design and Implementation. In Proceedingsof the 24th International Conference on DistributedComputing Systems (ICDCS), pages 690–699, March2004.

[21] O. Riva. Contory: A Middleware for the Provisioningof Context Information on Smart Phones. InProceedings of the 7th ACM International MiddlewareConference (Middleware), pages 219–239. Springer,2006.

[22] Lovegety: Love Japanese Style.http://www.wired.com/news/culture/0,1284,12899,00.html.

[23] M. Terry, E. D. Mynatt, K. Ryall, and D. Leigh. SocialNet: Using Patterns of Physical Proximity Over Timeto Infer Shared Interests. In Proc. Human Factors inComputing Systems (CHI 2002), pages 816–817, 2002.

[24] N. Eagle and A. Pentland. Social serendipity:mobilizing social software. In Pervasive Computing,IEEE, volume 4(2), pages 28–34. 2005.

[25] Geo-notes: Place based virtual notes.http://csd.ssvl.kth.se/ csd2002-geonotes/.

[26] W. Yang, C. Cheng, and J. Dia. A location awarerecommender system for mobile shoppingenvironments. In Expert Systems with Applications:An International Journal, volume 34, pages 437–445.2008.

[27] H. Heijden, G. Kotsis, and R. Kronsteiner. Mobilerecommendation systems for decision making on thego. In Proceedings of International Conference onMobile Business, July 2005.

[28] W. G. Griswold, R. Boyer, S. W. Brown, and T. M.Truong. A component architecture for an extensible,highly integrated context-aware computinginfrastructure. In International Conference onSoftware Engineering (ICSE 2003), pages 363–372,May 2003.

[29] SmartCampus (2005). http://smartcampus.njit.edu.