CAESAR: A Context-Aware, Social Recommender System for Low-End Mobile Devices Lakshmish Ramaswamy1 , Deepak P2 , Ramana Polavarapu2 Kutila Gunasekera3 , Dinesh Garg4 , Karthik Visweswariah2 , Shivkumar Kalyanaraman2 1 The University of Georgia, Athens, GA 2 IBM India Research Laboratory, Bangalore, India 3 Monash University, Australia 4 Yahoo! Labs, Bangalore, India [email protected], {deepak.s.p,rpolavar}@in.ibm.com [email protected], [email protected], {v-karthik,shivkumar-k}@in.ibm.com

Abstract Mobile-enabled social networks applications are becoming increasingly popular. Most of the current social network applications have been designed for high-end mobile devices, and they rely upon features such as GPS, capabilities of the world wide web, and rich media support. However, a significant fraction of mobile user base, especially in the developing world, own low-end devices that are only capable of voice and short text messages (SMS). In this context, a natural question is whether one can design meaningful social network-based applications that can work well with these simple devices, and if so, what the real challenges are. Towards answering these questions, this paper presents a social network-based recommender system that has been explicitly designed to work even with devices that just support phone calls and SMS. Our design of the social network based recommender system incorporates three features that complement each other to derive highly targeted ads. First, we analyze information such as customer’s address books to estimate the level of social affinity among various users. This social affinity information is used to identify the recommendations to be sent to an individual user. Second, we combine the social affinity information with the spatiotemporal context of users and historical responses of the user to further refine the set of recommendations and to decide when a recommendation would be sent. Third, social affinity computation and spatio-temporal contextual association are continuously tuned through user feedback. We outline the challenges in building such a system, and outline approaches to deal with such challenges.

1. Introduction Social networks capture the behavior of individuals influenced by the communities they belong to. Social networking and applications that leverage them is moving from our real physical lives to virtual communities in cyberspace and now,

more recently, into the Mobisphere (mobile cyberspace). Social network analysis views social relationships in terms of nodes and ties. Social network analysis produces a view, where the attributes of individuals are less important than their relationships and ties with other actors within the network. Mobility adds a few key ingredients to virtual communities. First, usage of mobile devices is increasing tremendously leading to people becoming icnreasingly accessible anytime through their personal mobile phone. Second, people do more things in their lives away from a computer whereas the mobile device, being personal, is still accessible to them. To the extent that social networks influence of what people do, and the decisions they make in the real world (i.e. in context-sensitive, and location-sensitive manners), the mobile virtual community is now available on hand to fulfill that role. Examples of mobile social network applications that have been mentioned in the literature or Blogosphere include those that find friends and potential friends (in the user’s locality), crowd-sourcing recommendations of physical businesses, behavioral and location-based ad-targeting, personal/social blogging and microblogging (Eg: Facebook1 , Twitter2 ), gaming with friends in the local neighborhood, sharing files/home-made videos etc with virtual social circles and so on. Several of these applications are enabled with Thirdgeneration (3G) mobile phones. However, an overwhelming majority of phones in vogue are simple 2G phones, especially in emerging markets (over 2.96 billion 2G GSM phones out of 3.66 billion phones as of 2008 [1]). Virtual community formation and social network applications with low-end (2G) phones is a relatively new phenomena. SMS GupShup [2] is a micro-blogging startup similar to Twitter, but uses SMSes. Google SMS channels lets one subscribe 1. http://www.facebook.com 2. http://www.twitter.com

to user-generated channels (forming pub-sub communities of interest) for soccer scores, jokes etc, and is free for content publishers and phone users who subscribe. Our paper focuses on simple 2G phones and socialnetwork enabled applications in the commercial arena. In particular, we examine easy-to-use social recommendation systems seamlessly coupled with location-sensitive advertisement/couponing systems: the delivery and the data collection both achieved over 2G wireless networks. This paper presents the design and implementation of CAESER - a social recommendation system that is sensitive to the context of the persons receiving the recommendations. In our system, users who like businesses (and are incentivized to recommend them, as part of a loyalty programme), can call a phone number associated with the establishment (controlled by the telecom provider), but simply not allow the call to complete (i.e. a missed or dropped call). This action (or any simple alternative that may be employed instead of this) is equivalent to giving thumbs up (recommendation) for the business (from your unique phone number). Now we assume that the telecom operator can derive a social influence graph based upon users communication patterns using implicit social networks (e.g., SNAzzy [3]) or explicit social networks (eg: Facebook3 , MySpace4 ). Such social influence graphs edges can be labeled with numbers (and possibly made directed edges), depending upon the social affinity between the nodes. Social affinity can be derived based upon communication patterns, intensity etc. Such derived social influence graphs may be used in a variety of interesting ways. In the simplest incarnation, when people who are influenced by a customer are in the spatiotemporal context of the business that were recommended by the latter, a message is sent to them (for example, such a message could be: your friend is in the vicinity of a great restaurant you recommended during lunch time); or alternatively, they could be provided the option of browsing recommendations of the latter, about stores in the vicinity. More interestingly, such recommendations can be seamlessly coupled with advertisements/coupons independently issued by the business. The response to such messages can also be used to refine the underlying social affinity and contextual relevance models. The next section (Section 2) describes an example scenario to illustrate the above concept and motivates the utility of various factors that we attempt to harness in CAESAR. We describe the system in Section 3. The described system allows for sending of very highly targeted recommendations using a variety of factors such as the ones already mentioned. We describe the Social Affinity Computation approach in Section 4 and the derivation of context in Section 5. Section 6 discusses some implementation issues and viable 3. http://www.facebook.com 4. http://www.myspace.com

business models. Section 7 describes our CAESAR prototype. We outline our empirical evaluation of some key issues in the system in Section 8 and conclude in Section 10.

2. Motivation and Challenges: A Use-Case Scenario In this section, we outline an example behavior of the system, and show how such behavior could be useful in many common scenarios. Example Scenario and System Behavior: Assume a fine restaurant in a residential neighborhood, called Heavenly Foods. People who live in the vicinity may know about it and want to recommend it to their social circles. Ram who has visited Heavenly Foods in his locality, gives it a thumbs up by a missed call to their publicly displayed phone number (registered with the telecom operator). When his friend Dev is in the vicinity (in the same zip-code) around lunch time, he gets a message saying: ”Your friend Ram recently visited Heavenly Foods and found the food to be truly Heavenly. Visit us for lunch today and get an appetizer free with an entree! . Use this coupon at Heavenly Foods and get 5 bonus minutes”. Discussion: Observe that Ram’s recommendations, even though trusted, did not get blindly broadcasted to all his friends (as in Facebook Wall5 ). His recommendations are delivered, only in a spatio-temporal context, and seamlessly integrated with advertisements/coupons. The telecom operator also offers loyalty bonus minutes (i.e., free calls upto a certain amount of time) to further incentivize Dev (again paid for by the advertiser) to respond. Alternatively, Dev could have been sent a message which could initiate a browsing session to see recommendations of all his friends coupled with incentive coupons. Dev is more likely to respond to such ads, delivered or invited to be browsed in context and from trusted social sources, rather than spammed into his SMS Inbox. It is insightful and useful to also reflect on the technical challenges in designing the CAESAR system. First, we only depend upon 2G phones that almost universally support SMS and USSD (secure-sessions)6 . The recommendationand-coupon can be delivered as an SMS message, or can be browsed via a USSD session. No multimedia support is needed, and low-end phones can also avail of this service. The context information necessary is coarse-grained (zipcodes for location, and hour-of-day for time). The challenge however is to build up a rich recommendation database for the simplest scenarios, and to build up the social influence graphs that drive such recommendations. The missed-call method simplifies the process of uploading the recommendation. Back-end analysis of call-data-records 5. http://www.webopedia.com/TERM/F/Facebook wall.html 6. http://en.wikipedia.org/wiki/USSD

(that provide details about who called whom, when etc.) [3] is one interesting way of building up a social network graph. Another way is to upload address books and analyse connectivity across users (e.g., a leading mobile service provider, Vodaphone7 acquired a small company ZYB [4] that does such analyses). The graphs further need to be annotated with a measure of affinity (i.e. edge labels).

3. System Overview This section describes the architecture of the contextaware social network-based recommender system. We also discuss its key components and the associated algorithms and techniques. Figure 1 depicts the architectural design of our system. The proposed system consists of four major components. The system is driven by user-supplied recommendation that are gathered using simple mechanisms. Recommendations can be uploaded in variety of ways such as text messages to a given number, an endorsement at the store, by visiting a website, or, as mentioned in the introduction, by placing a missed call to a pre-specified number. The uploaded recommendations are stored in a recommendation database. Users uploading recommendations may optionally be incentivized by the respective businesses. The social influence mining component analyzes various user activity logs (call records, SMS records, etc.) and address books, and computes the social affinity between a given pair of users. Higher social affinity implies a greater degree of influence of one user over the other, and viceversa. The context mining component extracts the location information of users. The location information can be obtained from the telecom company infrastructure or through the cell phone devices themselves. It also analyzes the temporal characteristics of businesses to derive information on when (what time periods) a particular type of business would attract maximum customers. Furthermore, this component analyzes user-profiles to determine their likes and dislikes. Social affinity information, context mining information, and user-uploaded recommendations are fed to the recommendation matching engine which determines which recommendation, if any, has to be dispatched to a particular user. The recommendation is optionally attached with a mobilecoupon (provided by the respective business) and sent to the user. User feedback, which could either be explicit or implicit is tracked and stored in the user feedback database. This user feedback is used to tune both social influence and context mining. The next few sections are devoted to the unique techniques and mechanisms we propose for social influence mining, context modeling and mining, and user feedback processing. 7. http://www.vodafone.com

4. Social Affinity Computation In this section we consider computing the social affinity between any pair of users. We would like for each pair of users u and v to get a weight wuv that indicates the amount of influence user u exerts over user v. Note that influence is not necessarily symmetric (wuv = wvu , in general). A unique feature of Caeser it that social affinity is derived by analyzing the action patterns of users on the wireless platform. In fact, social affinity can be meaningfully quantified in several different ways by analyzing various types of user action patterns. In this paper, we describe two distinct ways of computing social affinity by analyzing two different data sources.

4.1. Social Affinity Computation from Call Data Records If we had access to the call data records of the users of the recommendation system, we could use this to estimate of social affinity weights based on the talk time between pairs of users. The assumption here is that persons who are socially close to one another interact more frequently and talk longer. Thus, the longer u talks with v relative to the amount of time v talks with other users, the more influence u has on v: Tuv 0 = , wuv  u Tu v where Tuv is the amount of time that u and v spend talking to each other. Along similar lines, we could also incorporate the number of SMS messages sent between the two users in the formula for computing social affinity values among users. Note, however, that call data records and SMS records are generally available only with the telecom service providers. Thus, the above method for computing social affinity requires partnership with telecom providers. Next, we propose a method to compute social affinity from data that is entirely available at the users’ devices.

4.2. Social Affinity Computation from User Address Books Address books stored on users’ phones can also be utilized for computing the social affinity between two users. The rationale here is that persons with strong social ties tend to have significant number of common entries in their address books. Thus, the social affinity between u and v is computed as the fraction of common entries in their address books. Specifically, 0 = δu∈Av δv∈Au wuv

2 ∗ |Au ∩ Av | , |Au | + |Av |

Figure 1. CAESAR Architecture. where Au is the address book of user u, δS is 1 if S is true and 0 otherwise, and |Au | denotes the size of the set Au . The advantage of this method is that the address books are available in the users’ mobile devices themselves, and hence it does not require partnership with telecom companies. Furthermore, mobile applications frameworks like J2ME provide convenient APIs for retrieving this information. We will see this in detail in Section 7.

products or services of various kinds we could have the influence weights depend on the category of product or service. We would then only use recommendations in a particular category to update the influence weights for that particular category.

5. Spatio-Temporal Computation

Contextual

Relevance

4.3. Feedback-based Tuning Once a system for recommendations is in place, we could use explicit or implicit feedback to keep track of when a recommendation sent to a user was found useful. This data can then be used to update the influence weights: wuv =

0 + + Nuv Kwuv , K + Nuv

0 is our initial estimate of the influence that u where wuv has on v, Nuv is the number of recommendations that + is the number of u made that were sent to v and Nuv recommendations that u made that were sent to v and that v found useful. K is a parameter that controls how quickly we learn from data, the higher it is set to the more data we will need before we change our inital estimates. These influence weights will be used to decide which recommendations will be received by a user. Since recommendations can be for

The second important feature of CAESAR is that the recommendations are delivered in appropriate spatio-temporal context. Businesses vary widely in their characteristics and the products or services that they deal with. Such differences manifest in the temporal relevance of businesses for customers. For example, customers visit cafes more often during the afternoons and the evenings, whereas movie theaters typically do bulk of their business during weekend evenings. This is in contrast with other businesses such as medical stores that have a more or less uniform distribution of customers through the day. Since mobile devices are carried by the users at all times, the recommendations sent through them are likely to be noticed by the users almost immediately. Thus, the effectiveness of recommender system can be greatly enhanced by leveraging temporal and spatial relevance information to deliver more targeted content to the customer.

5.1. Temporal Hotness Function A recommendation for a business is most useful when sent around the time when the user is very likely to use it; recommendations outside of such time zones are more likely to be perceived as spam by the customer. Determining the exact time periods when an individual business is most relevant to the customers is a complex endeavor as it requires analyzing footfall logs of the business. However, we observe that the time periods when a business is hot for customers inherently depends upon the nature of its product/services. Thus, we divide stores into various categories based on the nature of products/services, and model the temporal relevance characteristics of various categories via temporal hotness functions). Based on a preliminary assessment of businesses that cater to end-users, we designed size categories of products, and hotness functions for each category which could be used for businesses that deal with products in that category. The categories were restaurants, apparel & books, consumer durables, entertainment, food items & other perishables and service points. These categories were also loosely based on eBay8 product categories. For all businesses that deal with products outside the categories specified, we used a uniform hotness function, i.e., the the relevance of the business is invariant throughout the day. For businesses that deal with multiple of these categories we used the union of the component functions. Certain businesses may have a weekly hotness cycle; consider, for example, a restaurant close to a church which could peak in customer activity after the sunday service times at the church. However, in a bid to keep things simple, we model the hotness function as a periodic step function9 where the hotness function has a positive value during specific times and has a period of a day. For example, restaurants were modeled to have nonzero hotness during the intervals between 1200 hours and 1500 hours and again during the evening between 1900 hours and 2200 hours as shown in Figure 3. Stores selling apparels and books were observed to be more active during the evenings, leading to a temporal hotness function modeled as in Figure 2.

5.2. Spatial Relevance Function Customers have a natural preference for businesses that are closer to their current location. Mobile service providers are capable of determining customer location in real-time to a reasonable level of accuracy [5] using techniques such as triangulation from cell towers10 and cell id information. Most mobile devices (even some of the most basic ones) can 8. http://ebay.in/ 9. http://en.wikipedia.org/wiki/Step function 10. http://en.wikipedia.org/wiki/GSM localization

Figure 2. stores.

Temporal Hotness Function for Apparel

Figure 3. Temporal Hotness Function for Restaurants.

themselves determine the cell tower ID they are attached to (J2ME provides an API to obtain this information). CAESAR harnesses the current location information about users to further improve the effectiveness of the recommendation sent to users. We model the spatial relevance of a business b to a customer u as an exponential function whose value exponentially deteriorates with the distance of the business from the customer’s current geographic location: SR(b, u) = λe−λDist(Locb ,Locu ) where Locx denotes the location of the entity x and Dist(., .) is a function that gives the distance between the locations indicated by the parameters. However, in certain cases, we may not be able to track the customer’s location due to various reasons, a very common case being absence of multiple towers catering to the same region (triangulation using cell towers is usually possible when multiple towers cater to the same location). Even in such cases, since the mobile towers are installed and managed by the service provider, the zip code of the location of the tower is usually available. Businesses are often static entities, whose location does not vary much with time. For such scenarios, we use a two step function as below: ⎧ ⎨ 1.0 : 0.5 : SR(b, u) = ⎩ 0 :

Zipb = Zipu IsN eighbor(Zipb , Zipu ) otherwise

where Zipx denotes the Zip code of the tower within whose coverage area x is present.

5.3. Feedback-based Tuning The other critical factors that can help decide which recommendation should be sent to a user are as follows: 1) The feedback from a user on the analogous recommendations that were shown to him or her in the past and 2) The feedback from people who are strongly socially connected on the similar recommendations that were sent to them in the past. Here, by feedback we mean the kind of action that user took after receiving a particular recommendation. The possible actions are as follows: 1) Visit the business but don’t execute any transaction 2) Visit the business and execute the transaction 3) Just ignore the recommendation The past actions taken by the user as well as the members of user’s social network can provide a plethora of information that can be harnessed to compute the likelihood that the user will visit the business and execute some transaction if the recommendation is sent to the user. There are numerous ways in which this information can be utilized. One possible scheme we use is that for every user-business pair, system maintains a probability score and every time system sends a recommendation for this business to the user then it updates it based on the observed action. There are several ways of tracking the feedback of the user. A few schemes are listed below: 1) All the users are issued a loyalty card which has inbuilt identity of the user. Every time, user visits any business then the user needs to produce this card in order to avail any discount offer that was sent along with the recommendation. This way, each transaction can be captured. 2) The recommendations are supplied along with a barcode that will be scanned at the checkout counter towards offering the discount to the user. Irrespective of whatever tracking scheme is used, we still need to answer the question that how to revise these probability scores and what can be taken as starting scores. A simple heuristic that we propose is is as follows: 1) For any new user -business pair, system can start with probability 1 2) Every time a recommendation for this business is sent to the user, the system waits till the expiry date of the discount coupon attached with this recommendation. a) If system does not receive any signal of user availing the deal then system revises the probability as follows: Pnew = αPold

where α is a positive constant strictly less than 1. α could be chosen empirically. b) If system receives the signal of user availing the deal then the system revises the probability as follows: Pnew = 1 − β(1 − Pold ) where β is positive constant strictly less than 1. β could be chosen empirically. The above probability score can be used in conjunction with SA score, temporal hotness function, etc. in order to improve the relevance and context awareness of the recommendations that are sent to the user.

6. Discussion In this section, we discuss the some of the important implementation-related issues, and techniques to address them. We also outline a business model to commercialize the proposed recommender system.

6.1. Implementation Issues The proposed system has to work with a widely heterogeneous set of mobile devices. In addition, the system should be highly scalable. These requirements pose a number of implementation challenges. The proposed system can be either implemented within the telecom infrastructure or as a third party application. Most data needed for computing relevance of recommendations as well as contextual information of users are readily available within the telecom infrastructure. In case, the recommender system is implemented as a third party application (without involvement of telecom infrastructure), these data would need to be obtained from the mobile devices themselves, which makes the implementation more complex. We mainly focus on the challenges that are common to both incarnations. The recommender system requires various kinds of data that are quite heterogeneous in terms of their dynamicity. For example, the location and CDR (i.e., call data record; such records typically are one per call, and hold details about the call) information of a user are likely to change quite frequently, whereas the address books are relatively more stable. The rate at which recommendations arrive can vary widely across businesses. Furthermore, these data are dispersed through out the system. Obtaining and maintaining these information in a scalable and efficient manner is challenging. One way to address this issue would be to employ lazy update strategies wherever possible. For example, call data records, address books records and recommendation database can easily tolerate a few hours of updation delays. Thus, the changes to these data can be consolidated over a

certain duration and communicated periodically. Additionally, the updations can be scheduled during nights when the data volumes are expected to be low. In contrast, the recommendation system is very sensitive to the location of the user, and hence this information needs to be as fresh as possible. A second strategy that can reduce the communication overheads is to pull data only when it is needed. For example, retrieval of location data can be limited to periods when a reasonable number of businesses are hot. This would also conserve battery power on cell devices. The second issue is the high computational effort involved in mining call data records, address books and other contextual data. The problem is further exacerbated by semi-real time response requirements. However, we observe that a majority of the computation-intensive tasks can be performed periodically in the background. Typically, these would include computations that rely on data which tolerate lazy updation. For example, social affinity among individuals can be computed once in a few days, and the results can be re-used wherever necessary. Sensitivity towards the battery power remaining in the mobile device is yet another important issue. The system should desist from sending recommendations when the battery is running low. This can be implemented by having the device send out a signal to stop issuing recommendations whenever its battery life falls below a threshold. The device can automatically (without intervention from the user) ask for resumption of recommendations upon battery recharge.

6.2. Business Model The recommender system can be commercialized through the following business model. The businesses whose services/products are recommended via the system would be charged a certain fee. The fee could be based on pay-perimpression model, pay-per transaction model, or a combination of the two. Furthermore, businesses could provide discount mobile coupons (m-coupons) which can be attached with the respective recommendations. The other possibility is to charge a small fee from mobile users receiving the recommendation. However, this might not be appreciated by the mobile users.

7. Prototype Development. The following are the main subsystems of the above specified recommender system ordered by their purpose: 1) Gathering interests of mobile customers in receiving recommendations 2) Gathering details of participating businesses 3) Recommendation Engine 4) Rewarding recommenders The two major parties involved in the proposed recommender system are the customers (subscribers to the mobile

service) and the businesses that sign-up for the service so that their recommendations are sent out to customers. The former benefits from getting more targeted content. Quantifiable monetary benefit is achieved by the businesses in terms of increased footfalls. The effectiveness of our system, in turn, relies on participation from the customers as well as the businesses. The first sub-system ensures that only those customers interested are served with targeted ads; this is usually required due to legal regulations. The second sub-system allows for a mechanism for businesses to sign-up for the service; possibly, by offering to pay for increased footfalls induced by the recommendation engine. An incentive mechanism that tracks the footfalls by whether they were induced by the recommender system is realized by the last sub-system.

7.1. Techniques for Retrieving Customer Information. The recommendation engine utilizes multiple sources of information to make targeted recommendations such as: 1) Anonymized Address Books of Customers: This is required since the social influence of one customer over the other could be a function of the cardinality of intersection between their address books. 2) Customer’s Geographical Location: The location information would be used to prioritize recommendations of nearby businesses Since advanced communication technologies such as GPRS and bluetooth (among other nearfield communication techniques) are usually not available in mobile devices that are popular among customers in the emerging economies such as India and China, we need to leverage ubiquitous mobile device features such as SMS to ship the address book information from the customer to the recommendation engine. Towards this end, we leverage the capabilities of various Java Service Requests (JSRs) which are part of the Java ME platform to retrieve customer information for use in the recommendation engine. JSR 75. This JSR11 deals with extraction of Personal Information from the mobile device and also can handle file connections. File connections allow us to access file systems residing on mobile devices, and thus can easily access address books. JSR 120. This JSR12 enables programs to send Short Text Messages from mobile devices. This is an easy way to ship address books from mobile devices to the engine. JSR 179. JSR 17913 enables retrieval of the physical location of the mobile device. The physical location can be retrieved using GPS on devices that are armed with such 11. http://www.jcp.org/en/jsr/detail?id=75 12. http://www.jcp.org/en/jsr/detail?id=120 13. http://www.jcp.org/en/jsr/detail?id=179

advanced functionality. In devices that do not have such functionality, JSR 179 is capable of retrieving geographical location by triangulating its position using signals from towers. This is done using E-OTD14 that measures the difference in the time of arrival signals from different towers.

8. Experiments The system, as detailed in the previous section, has a strong social-network based component. The social network influence score is heavily based on the capability to retrieve address books from customer’s mobile devices. This involves the communication overhead of having to ship address books and changes to it to the server side, and also the computational overhead of re-calculating the social network influence graph. If the system is able to leverage the capabilities of the mobile service provider’s infrastructure, it could receive a stream of location updates from each customer at minimal cost. However, since access to the mobile service provider’s infratsructure may not always be possible, the system would have to make location update requests to each mobile device frequently to ascertain whether a chosen recommendation (chosen using the other parameters) is close enough to the customer’s current location to be relevant to him. We empirically evaluate these key issues in this section, and show that seemingly simple techniques can reduce the computational and communication costs for address book updates, and that heuristics based on the average mobility capability of customers could help in reducing the number of location requests that need to be made.

8.1. Address Book Update Analysis. Address book updates often happen very rarely. However, in volatile markets that are characteristic of emerging economies, customers tend to switch mobile operators relatively frequently, thus changing their mobile number often. Each such change results in updates in each of their contact’s address books. We analyse the communication and computation costs involved in a hypothetically volatile system; high dynamism being hostile to our system in that it induces a lot of communication and computation. We simulate a system that has 5000 users, with an average address book size of 100 entries, and a test period of 10 months. We vary the address book change rate from once in 7 hours to once in 1000 hours, uniformly. Each update operation could be the addition, deletion or modification of a single entry in the address book. We design the server side application to have re-compute the social influence graph every 7 hours; however, if no updates have been received, within the 7 hours, no re-computation would be performed. Now, there could be two distinct approaches for 14. http://www.phonescoop.com/glossary/term.php?gid=188

communicating changes of the address book to the server. They are: 1) Eager: Whenever a change occurs, the client-side application communicates the change to the server 2) Lazy: The client-side application keeps track of address book changes, and sends the change only when the address book has changed at least t% from the last communicated version For both these approaches, the server-side application behaves in the same manner, re-computing the graph only during the 7 hour cycles, if any updates have been received since the last cycle. Communication Cost: The communication cost is quantified as the number of updates sent from the client-side application. Since each update involves less than 5% of the address book, it may be assumed that each such update could be sent in one unit of communication (a packet, an SMS etc. depending upon the communication mechanism used). Computation Cost: Since we use 7% hour update cycles at the server side for the re-computation, any savings for computation may be achieved only if there are cycles, in between whom, there are no updates received from any client. We use the number of update operations performed during the simulated 10 month period to quantify the computation cost. It may also be noted that re-computation is always a fixed cost operation regardless of the number of updates received, since a single update can change the weight of any edge in the social influence graph. We analyze the costs for the eager approach and various versions of the lazy approach with the parameter t set of values of 5, 10 and 50. The communication costs are seen to reduce drastically with increasing laziness (Ref. Figure 4). The exponential reduction suggests that client side buffering can go a long way in reducing the communication overhead, even when address book change rates are very high. However, the lazy approach has the disadvantage that the social influence graph maintained at the server side may be stale for a while, i.e., not up-to-date with current information. However, update frequencies in a steady state user-base can be expected to be very low, in which case, the eager approach could be employed without incurring a high network overhead. The graph in Figure 4 serves to illustrate that easy techniques can be employed to realize a communication-accuracy trade-off in the system, even in cases of a highly volatile user-base with frequent address book edits. A similar pattern is seen with the computation costs in Figure 5 (although the reduction in costs is not as drastic as in the former, partly since updates are performed only at update cycle boundaries), where the number of compute cycles without receiving any updates is significantly increased with increasing laziness.

Figure 4. Communication Costs.

Figure 5. Computation Costs.

8.2. Optimizing Location Updates. When the system is deployed as a third-party application, without access to the mobile service provider’s infrastructure, ads and their relevance may be assessed using means other than physical proximity. However, to ensure that ads of a store are not sent to customers who are very far away, the system has to assess the proximity of the customer to the chosen store. The client-side application may be queried in such scenarios, to retrieve up-to-date location information about the customer. On the lines of the strategies detailed in Section 8.1, we could have alternative strategies as below: 1) Eager: Query the location of the customer each time an ad is to be sent, and send the ad only if the store is close enough to the customer’s present location. 2) Likelihood-based: Retrieve the last known location of the customer, and assess whether the customer could have reached close enough to the store within the time that has elapsed from the time of the last location update; this is based on an assessment of maximum speed at which the customer could travel. Query for the customer’s location only if there is a likelihood that he could have reached close enough to the store. The likelihood based approach has the maximum speed as a parameter, which could vary according to the nature of the area which is catered to, by the system. For example, cities could have a maximum speed of 50 miles/hour whereas, it could be much higher in suburbs which have highways. Optimizing the number of location update requests is not necessary in highly dense small cities, since most of the stores would be relevant to all users since the covered area is not huge. In this section, we illustrate how we could optimize requesting location updates in vast coverage areas which have very few users. We simulate a system that caters to 5000 customers, spread across a huge area of 4000 square miles, and the number of stores are set to a low value of 100. We vary the maximum speed parameter from 8 miles/hour to 200 miles/hour to create various versions of the likelihood based approach. It may be noted that the eager approach is an instance of the likelihood based approach where the maximum speed is set to infinity.

Figure 6. Location Requests Savings Analysis.

Figure 6 plots the percentage of location requests made (when compared to the number of requests made by the eager approach) by various instances of the likelihood-based approach, with varying maximum speeds. It may be seen that when the maximum speeds are as less as 8 mi/hr, the likelyhood based approach needs to make only around 15% of the requests made by the eager approach. In summary, the likelihood based approach is seen to be very effective in reducing the communication for location tracking.

9. Related Work Mobile marketing has been gathering much attention of late [6], [7], [8]. Research has shown that consumers react negatively to unsolicited SMS/voice call based advertisements [9]. Thus, it is important that intrusiveness of mobile advertisements should be minimized not only to increase effectiveness but also to avoid negative results. By targeting advertisements such that advertisements are relevant to the recipient it is possible to reduce the intrusiveness of SMS ads. It has also been shown to be important to ensure that advertising messages are only sent at times (and situations) which are not inconvenient to users [10]. Recommender systems have also acquired prominence after their high-profile use in Amazon, Ebay, Slashdot, and Netflix. Recommender systems for physical locations (eg: restaurants) based upon critiques is examined by Ricci et al [11]. It can support queries such as Find me a cheaper restaurant in a Queens, NY. Modsching et al [12] construct a mobile personalized recommender systems based upon physical entities and location-awareness. Ziv et al [13] and Dixit [14] explore the concept of location-based social networking with a detailed study of Dodgeball, a commercial service. Dix et. al [15] is an early paper that discusses context in great detail especially the role of location as a contextual attribute. There are also examples of interesting uses of social networking and recommender applications in the literature. Tomiyasu et al [16] discuss an interesting application where a query from a user is propagated to a persons social neighbourhood, narrowed down by matching the query to a profile. This is a reverse of a recommendation service,

and does require active human participation for resolution of queries. Groh and Ehmig [17] compare collaborative filtering against social filtering for a task of rating clubs, and they find that social filtering gives better results. In contrast to these papers, our work combines recommender systems, with a number of other components, viz., social network business intelligence (based upon social influence graphs), personalization and spatio-temporal context (including location).

[2] “Sms gupshup: Free http://www.smsgupshup.com/.

10. Conclusion

[5] M. Richtel, “Live tracking of mobile phones prompts court fights on privacy,” The New York Times, 2005.

Most of the current mobile social network applications are designed for Third-generation (3G) mobile phones, whereas a majority of users, especially, in emerging markets own a simple 2G device. In this paper, we proposed a contextaware social network-based recommender system called Caeser that operates even with 2G devices. A unique feature of Caeser is that the most basic user-activity patterns on the mobile platform are utilized to derive the level of social affinity among various users. Furthermore, it uses the spatio-temporal context of the users to further refine the set of recommendations a user receives. We present several implementation techniques to improve the efficiency of CAESAR. We have performed a set of experiments which demonstrates that the computation and communication costs of CAESAR are quite reasonable. CAESAR is the first recommender system on the mobile platform that utilizes temporal and spatial context along with the social network. A variety of enhancements are possible in such a system to suit heterogeneous infrastructures. For example, in sparsely populated areas, even stores that are a few miles away from the user’s location may be of interest (in contrast to urban areas). In cases where mobile towers may have limited computational power, approaches that distribute the computational load may come in handy since they could be leveraged to computations may be moved as close to the user as possible. Most SIM cards are Java enabled; this provides the opportunity for building applications that reside on the SIM memory. Such an approach would mitigate CAESAR’s dependency on the capability of the mobile device. The robustness of the business models (to loss of connectivity, attacks by individuals or groups to artificially boost up the number of recommendations sent for a store of their interest) for such a mobile advertising system would be interesting to explore. We are in the process of addressing such challenges to make CAESAR more effective in computation and accuracy of outbound recommendations.

References

group

sms,”

[3] A. A. Nanavati, S. Gurumurthy, G. Das, D. Chakraborty, K. Dasgupta, S. Mukherjea, and A. Joshi, “On the structural properties of massive telecom call graphs: findings and implications,” in CIKM, 2006, pp. 435–444. [4] “Vodaphones zyb acquisition: More mobile social networking,” http://www.wirelessdesignasia.com/article8568-vodafoneszybacquisitionmoremobilesocialnetworkingAsia.html.

[6] T. R. H Bauer, S Barnes and M. Neumann, “Driving consumer acceptance of mobile marketing: A theoretical framework and empirical study,” Journal of Electronic Commerce and Research, 2005. [7] M. M. Tsang, S.-C. Ho, and T.-P. Liang, “Consumer attitudes toward mobile advertising: An empirical study,” Int. J. Electron. Commerce, vol. 8, no. 3, pp. 65–78, 2004. [8] R. Vatanparast, “Piercing the fog of mobile advertising,” in ICMB. IEEE Computer Society, 2007, p. 19. [9] M. M. Tsang, S.-C. Ho, and T.-P. Liang, “Consumer Attitudes Toward Mobile Advertising: An Empirical Study,” International Journal of Electronic Commerce, 2004. [10] D. Xu, “The influence of personalization in affecting. consumer attitudes toward mobile advertising in. china,” Journal of Computer Information Systems, 2006. [11] F. Ricci and Quang Nhat Nguyen, “Acquiring and revising preferences in a critique-based mobile recommender system,” IEEE Intelligent Systems, 2007. [12] M. Modsching, R. Kramer, K. Hagen, and U. Gretzel, “Effectiveness of mobile recommender systems for tourist destinations: A user evaluation,” in Intelligent Data Acquisition and Advanced Computing Systems: Technology and Applications, 2007. [13] N. D. Ziv and B. Mulloth, “An exploration on mobile social networking: Dodgeball as a case in point,” in International conference on mobile businesses, 2006. [14] J. Dixit, “The artful and mobile dodger,” IEEE Spectrum, 2005. [15] A. J. Dix, T. Rodden, N. Davies, J. Trevor, A. Friday, and K. Palfreyman, “Exploiting space and location as a design framework for interactive mobile systems,” ACM Trans. Comput.-Hum. Interact., vol. 7, no. 3, pp. 285–321, 2000. [16] H. Tomiyasu, T. Maekawa, T. Hara, and S. Nishio, “Profilebased query routing in a mobile social network,” in MDM. IEEE Computer Society, 2006, p. 105.

[17] G. Groh and C. Ehmig, “Recommendations in taste related domains: collaborative filtering vs. social filtering,” in GROUP, T. Gross and K. Inkpen, Eds. ACM, 2007, pp. [1] “Gsm facts and figures, 2q 2008,” http://www.gsmworld.com/news/statistics/pdf/gsma stats q2 08.pdf. 127–136.