precise: privacy-aware recommender based on context information for cloud service environments

IEEE Communications Magazine • August 201490 0163-6804/14/$25.00 © 2014 IEEE

The authors are with theUniversity of Murcia.

This work has been par-tially funded with supportfrom the SpanishMICINN (projectRECLAMO, Virtual andCollaborative Honeynetsbased on Trust Manage-ment and AutonomousSystems applied to Intru-sion Management, withcode TIN2011-28287-C02-02, and project Mejo-ra de Arquitectura deServidores, Servicios yAplicaciones, with codeTIN2012-38341-C04-03)and the European Com-mission (FEDER/ERDF).Thanks also to the Fund-ing Program for ResearchGroups of Excellencegranted by the SénecaFoundation with code04552/GERM/06.

INTRODUCTION

Context awareness is a concept that combines theenvironment, users’ locations, identities of nearbypeople and objects, and changes in the previousterms [1]. The ability to determine users’ andobjects’ locations at a particular time suppliesvaluable information to offer services from theelements of the environment where they are.These services can range from a simple location-based service (LBS) to emergency services, carnavigation systems, or tour planning for tourists.

Nowadays, we can find some proposals that aimat offering context-aware services based on loca-tion, such as LOC8 [2], SOCAM [3], and CoCA[4]. LOC8 is a powerful framework that supportsquerying the environment in which users are locat-ed, whereas SOCAM infers information about agiven context considering information from others.Instead, CoCA proposes a collaborative context-aware service platform where the users’ location isinferred by considering information about the con-text and the location of the elements.

However, the ability to locate people raisesserious privacy concerns, such as the right of

users to determine when, how, and under whatconditions their location can be released toother users or services. In this sense, other con-text-aware systems are focused on preservinglocation privacy by using policies. Among them,CoBrA [5] protects the privacy of its users byusing rules, inferring whether they have the rightpermissions to share and/or receive information.Another example is CoPS [6], where users cancontrol who can access their context data, when,and at what level of granularity. Finally, a morerecent work, PPCS [7], proposes that the users’location and context information are shared (ornot) depending on their privacy policies.

With previous solutions, users cannot protecttheir privacy against services, only against otherusers. Furthermore, they are oriented to offer localservices in specific environments, setting aside dis-tributed schemes. Providing context-aware servicesbased on location is a complex task due to:• The need to acquire the users’ location and

context-aware information from differentsources

• The large amount of data required to shapethe context-aware information

• The processing power requirements to ana-lyze the information and provide the services

• The mobility of users when they make useof the services

• The management of the users’ privacyaccording to their preferences

• The need to offer services that run on feder-ated systems spanning different organizationsIn attempting to meet these requirements, we

figured out that the mobile cloud computing(MCC) paradigm can play a key role [8]. MCC pro-vides mobile users with data processing and storageservices in a cloud environment. Thus, mobiledevices belonging to roaming users do not needlarge capacity for storage and processing. Further-more, context-aware services based on location canshare certain information to provide users with bet-ter and more personalized services, by using federa-tion mechanisms as the one presented in [9]. To thebest of our knowledge, there is not a wide spread ofcontext-aware services based on location facingusers’ privacy concerns in MCC, this being a priori-ty recently identified in [8].

ABSTRACT

Context-aware systems based on locationopen up new possibilities to users in terms ofacquiring custom services by gathering contextinformation, especially in systems where the highmobility of users increases their usability. In thiscontext, this article presents a privacy-preservingsolution offering context-aware services based onlocation in MCC. We propose a middleware,called PRECISE, which provides users with cus-tom context-aware recommendations. These rec-ommendations are given by considering thecontext information, and the users’ locations,privacy policies, and previously visited places.MCC plays a key role in this solution, movingthe data processing and storage needs to thecloud, as well as further advantages such as elas-ticity and load balancing. A thorough discussionwhen comparing PRECISE with other relatedworks confirms that our solution improves themost relevant proposals so far.

CONTEXT-AWARE NETWORKING ANDCOMMUNICATIONS

Alberto Huertas Celdrán, Manuel Gil Pérez, Félix J. García Clemente, and Gregorio Martínez Pérez

PRECISE: Privacy-Aware RecommenderBased on Context Information for Cloud Service Environments

GIL-PEREZ_LAYOUT_Layout 7/30/14 1:38 PM Page 90

IEEE Communications Magazine • August 2014 91

In this article, we present an evolution of ourwork called SeCoMan [10]. Concretely, we pro-pose a privacy-preserving and context-aware sys-tem that provides location-based services (LBS)in the MCC paradigm, which allows users todefine privacy policies regarding services(although it is able to do it between users too, asan extension of the SeCoMan approach). Thisimplies that the architectures and the benefitsobtained from both solutions are rather differ-ent. With PRECISE, users can:• Release their locations to specific services• Hide their positions to specific users• Mask their locations to other users by gen-

erating fictitious (fake) positions• Establish the granularity and closeness at which

they want to be located by services or users• Preserve their anonymity to specific services

The central component of our solution is amiddleware, called Privacy-Aware Recom-mender Based on Context Information forCloud Service Environments (PRECISE),placed between users and context-aware ser-vices. PRECISE is allocated at the platform as aservice (PaaS) layer of the MCC paradigm. Thismanages the context-aware users’ information,their privacy policies, and their behavior pat-terns (i.e., the users’ movements while staying inthe environment). Context-aware services are inturn allocated at the software as a service (SaaS)layer of MCC, providing users with recommen-dations about context-aware information. Thus,PRECISE is a context-aware system thatreceives the users’ location, context information,and changes in both from independent middle-ware, which can belong to the cloud environ-ment or not.

HOW TO PRESERVEUSERS’ PRIVACY IN LBS

Users should be able to dynamically controltheir information by using rules that form poli-cies, for example. Among the different sets ofpolicies, we emphasize here the use of privacy-oriented policies, with which users can definetheir privacy preferences related to their loca-tion, identity, and personal information.

The set of rules forming the policies in PRE-CISE are composed of the following elements:Type is the kind of policy; the target is the personwho defines the policy and whose information isbeing managed; the requester is the service orperson who requests information about the tar-get; the place is the region of the environmentwhere the policy will be enforced; and the resultdetermines the relationship the requester willhave with the target’s information. PRECISE isin charge of managing the context-aware infor-mation implicitly contained in each rule. Notethat the context can be composed of some ele-ments, such as Profile, Date, or Time.

TypeTargetRequesterPlace[Profile][Date][Time]→Result

In the above context, PRECISE allows usersto define two kinds of policies, which are intro-duced below.

LOCATION MANAGEMENT POLICIES

These policies are defined by the users to specifytheir privacy preferences regarding their loca-tion. They are divided into five groups: Release,Hiding, Cloaking, Granularity, and Closeness. Inany of the foregoing policies, the target candefine different policies with the same requesterregarding certain Places , Profiles , Dates , orTimes, whether this requester is a user or a ser-vice, depending on the kind of policy.

As PRECISE hides the users’ location to ser-vices by default, release policies are oriented toreveal the users’ locations to specific services.This will allow a requester (service) to know thetarget’s position (user). On the other hand, hid-ing and cloaking policies are oriented to users,as, unlike in the previous case, the users’ loca-tion is available to other users by default. Theycan hide their location to a given set of users bydefining hiding policies. Cloaking (or masking)policies are intended to generate one or morefake positions for a particular user, so otherusers cannot distinguish the real position inwhich the target is. Granularity policies can alsobe defined indicating the maximum accuracy atwhich users want to be located, may it be appliedto users or services. With this kind of policy, it ispossible to define several levels of granularitydepending on the context in which the service isbeing provided. An example of these levels couldbe the section or building where the user islocated.

Finally, closeness policies can be applied toboth users and services with the aim of indicat-ing the minimum level of nearness at which thetarget (user) wants to be located. The nearnesslevel is established with the same values as theones defined for the granularity policies.

ANONYMITY MANAGEMENT POLICIESPRECISE guarantees anonymous use of context-aware services, as users do not want a priori toreveal either their identity or personal informa-tion on what they consider sensitive data. To dis-close such information, we define a new type ofpolicy, called Revealing, oriented to services. Thiskind of policy can be specified by the users toreceive custom recommendations from specificcontext-aware services. Otherwise, users will onlyreceive general context-aware recommendations.In the literature, we can find several proposals inovercoming the anonymity of a user. For exam-ple, in [11], a solution for the anonymous use ofservices by using pseudonyms is proposed.

Depending on the users’ needs and prefer-ences, they can use some profiles defined by thesystem, or created by them, to reveal the rightinformation (e.g., their location only) to theright requester (service), at the right place andtime, in order to receive custom context-awarerecommendations. A profile in our solution isrelated to a specific topic and is formed by agiven set of policies. As an example, Fig. 1 showshow a user can select a given profile to startreceiving recommendations, edit an alreadydefined profile, or create a determined policy byusing a mobile application. Note that the contentof these three subfigures are subsequentlyexplained in the next section.

Users should be able

to dynamically con-

trol their informa-

tion, by using rules

that form policies,

for example. Among

the different sets of

policies, we empha-

size here the use of

the privacy-oriented

policies, with which

users can define

their privacy prefer-

ences related to their

location, identity,

and personal infor-

mation.


IEEE Communications Magazine • August 201492

A MOTIVATING EXAMPLE

We present in this section an example to showhow our solution manages the users’ privacy incontext-aware services based on their location.We define a scenario based on a mall whereusers receive recommendations about productsand offers on their mobile devices. In this sce-nario, the main entity of PRECISE acts as themall’s middleware itself, giving recommenda-tions according to the users’ location, their pro-files, and the context-aware information relatedto the space description of the environment, thedescription of the elements close to the user,and their relevance and meaning.

In our scenario, we have a mall with differentstores and places to buy products and enjoyleisure time. This mall has the infrastructure toknow the location of its users and a service toprovide custom context-aware recommendations.Users’ location is registered by the mall’s mid-dleware, that is, by PRECISE, to record theirpatterns of behavior when interacting with allservices and stores provided in the mall; forexample, time visiting a given store or routinesof the users after staying in a given space. Usingthis information, PRECISE (the mall’s middle-ware) is able to give useful recommendations toits users about products and offers provided bythe stores located at the mall. These recommen-dations take into consideration the context-aware information, the users’ location, someprofiles defining typical customs of the users,and patterns about their behavior. Changes inthe context are managed by PRECISE receivingthe context-aware information from the infra-structure deployed at the mall. The map of themall is graphically depicted in Fig. 2.

As an example to show how the previousmall’s middleware (PRECISE) gives recommen-dations to its users, suppose a user (Andy) mov-ing around the shopping center who is interestedin electronic products. To receive recommenda-tions, he uses his mobile device, access to the

mall’s middleware, and selects ElectronicProfile(Fig. 1a).

ELECTRONIC PROFILEThis profile contains policies that form theAndy’s privacy preferences. The first rule con-sists of a release policy, indicating that his posi-tion has to be released to the services withElectronicProfile when he is at the mall (Fig. 1b).Thus, he will only receive recommendations ofelectronic stores.

Person(#Andy)isLocated(#Andy, #Mall)Service(?Requester)hasProfile(?Requester , #ElectronicProfile) → hasRelease(#Andy,?Requester)

The next rule is a closeness policy. It indicatesthat Andy only wants to receive recommenda-tions of stores located in the same and adjacentcorridors when he is located in CorridorB1 (rec-ommendation point 1 in Fig. 2). As a result,Andy will only receive recommendations ofElectronicStoreB.

Person(#Andy)isLocated(#Andy, #CorridorB1)→ hasGranularity(#Andy, #Floor)

The last rule is a granularity policy (Fig. 1c),indicating that Andy only wants to receive rec-ommendations of the stores placed on the samefloor when he is at AreaA (recommendationpoint 2, Fig. 2). Thus, Andy will receive recom-mendations of ElectronicStoreA and Electronic-StoreB.

Person(#Andy)isLocated(#Andy, #AreaA) →hasGranulariaty(#Andy, #Floor)

Suppose that Andy is on the Underground-Floor (recommendation point 3, Fig. 2), stillusing the ElectronicProfile set. The mall’s mid-dleware will recommend some products of Elec-tronicStoreA, ElectronicStoreB, andElectronicStoreC, taking into account that Andyvisited ElectronicStoreA after receiving the sec-ond recommendation. Moreover, Andy willreceive no recommendation of CinemaA, as Cin-emaA’s service is not contained in Electron-icProfile. After (maybe) visiting some electronicstores, Andy decides to change his profile foranother (Fig. 1a): LeisureProfile.

LEISURE PROFILEAs before, the first rule consists of a release poli-cy. This indicates that Andy wants to release hisposition to the services with LeisureProfile whenhe is at the mall. He will then receive generalrecommendations about movies in theaters.

Person(#Andy)isLocated(#Andy, #Mall)Ser-vice(?Requester)hasProfile(?Requester, #Leisure-Profile)→hasRelease(#Andy, ?Requester)

The next rule is a revealing policy, and indi-cates that Andy wants to reveal his pseudonymto CinemaA just when he is on the FirstFloor(recommendation point 4, Fig. 2). Andy willstart receiving custom recommendations aboutmovies when he is on the first floor, considering

Figure 1. How a user can choose a given profile and how the policies can becreated or edited through a mobile application: a) selecting a given profileto start receiving custom context-aware recommendations; b) editing aprofile to receive recommendations when meeting a number of policies; c)defining a granularity policy about where receiving recommendations.



his records and preferences. This information isknown by CinemaA’s service because Andy pro-vided it during a previous registration process.

Person(?Andy)isLocated(#Andy, #FirstFloor)→hasRevealing(#Andy, #CinemaA)

Finally, suppose that half an hour before themovie starts, Andy receives a notification of can-cellation and recommendations about other inter-esting movies. This implies that when there arecontext changes, the mall’s middleware will receivethese changes and report such information to userswho have the previous policies set, like Andy.

ARCHITECTUREThis section describes our architecture to deploya privacy-preserving and context-aware systemthat provides services based on location. Figure3 depicts the proposed architecture.

This architecture is oriented to the cloud inorder to allow actors to use and manage theresources more efficiently. Context-aware ser-vices, ElectronicStores and CinemaA in the previ-ous section, are located at the SaaS layer toprovide recommendations according to theirinternal context. Instead, PRECISE (the mall’smiddleware) is a privacy-preserving middlewareallocated at the PaaS layer to manage the globalsystem context as well as the users’ information.

The context awareness and space informationare provided by independent middleware (the

mall’s infrastructure), which can belong to thecloud or not. The storage and computing require-ments are allocated at the IaaS layer of the MCCparadigm in order to manage the large amount ofdata needed to shape the contextual informationand the processing power to provide the services.

ACTORSThe PRECISE administrator (the mall’s adminis-trator in the previous section) manages the infor-mation related to users’ locations and registrationof the context-aware services. This actor also indi-cates to the Communication manager the differentmiddleware required to receive location and con-text-aware information. On the other hand, theService administrators (the administrators of Elec-tronicStores and CinemaA) are in charge of man-aging the context-aware information of theirservices, so each service has its own administrator.

The last type of actor in our solution is theuser (Andy). Users are people who use PRECISEto obtain recommendations about the context inwhich they are located. They define their policiesto manage their privacy directly in PRECISE,without having to rely on context-aware services.

COMPONENTSThe layers composing our system architectureprovide the necessary resources so that theactors can use and manage the system. The Elec-tronicStores and CinemaA of the previous sectionare privacy-preserving services because they donot know Andy’s identity, location, or personal

Figure 2. Overview of the scenario.

4

2

Services

Andy

Recommendationpoint

Andy’s movements

AreaBAreaA

FirstFloor

GroundFloor

CorridorB1

UndergroundFloor

CinemaA

ElectronicStoreA

ElectronicStoreB

ElectronicStoreC

1

3

...

...

The storage and

computing

requirements are

allocated at the IaaS

layer of the MCC

paradigm, in order

to manage the large

amount of data

needed to shape

the contextual

information and the

processing power to

provide the services.



information. As Andy is registered with Cine-maA and defined a revealing policy for such aservice, PRECISE will only reveal to CinemaA apseudonym for him. Using that pseudonym, Cin-emaA will access Andy’s information (providedby Andy during the registration process) and willbe able to provide him with more personalizedcontext-aware recommendations. Instead, theElectronicStores will only provide Andy generalcontext-aware recommendations.

As shown, PRECISE is a middleware that man-ages the context and preserves the users’ privacy,without having to undergo a registration process.This implies that Andy, for example, will have dif-ferent pseudonyms in different sessions, so PRE-CISE will not be able to track him. Thus, Andy’sbehavior pattern will just contain informationabout the current session. In another case, whenAndy is registered in PRECISE, it will be able toaccess Andy’s pseudonym and link his behaviorpatterns of different sessions, thereby providinghim better suited context-aware recommendations.

In order to manage the context, PRECISEuses ontologies to shape the contextual and userinformation, semantic rules to define the policies,and semantic reasoning to infer new knowledge.The complete definition of the PRECISE ontolo-gies can be accessed and downloaded from [12].

To perform all tasks, PRECISE has differentcomponents. The Engine component is in chargeof requesting recommendations to the context-aware services, and provides users with recom-mendations based on previous ones. TheReasoner component makes the decision whetheror not to request recommendations to specificservices. This component infers the decisionmaking as input for the updated ontologicalmodel formed by the union of the context-awareinformation and the users’ information, and thesemantic rules defined by the users.

The Communication manager component is incharge of receiving the context-aware and spaceinformation from the middlewares. This provides

independence for PRECISE with regard to thesources of information.

Finally, the Administration component isresponsible for supporting administrative tasks ofthe actors, including policy management, registra-tion of the context-aware services, and manage-ment of the Communication manager component.

SEQUENCE DIAGRAMThe interaction between the PRECISE compo-nents is formed by four main blocks of steps,which are represented on the right of Fig. 4.This figure shows the sequence diagram,remarked on below, when Andy is at AreaA (rec-ommendation point 2, Fig. 2). These blocks,from the perspective of PRECISE, are:• Obtain the contextual and space informa-

tion from independent middleware solu-tions and store it.

• Manage the context-aware informationgathered earlier, and use Andy’s locationand his policies to decide with which ser-vices to ask for recommendations in a pri-vacy preserving fashion.

• Ask for recommendations to the corre-sponding services and receive their prod-ucts and offers.

• Provide Andy with recommendations by con-sidering the services’ recommendations, Andy’spreferences, and his patterns of behavior.

DISCUSSIONWe present here a thorough comparison betweenour solution and the main related work intro-duced in the first section, which is shown inTable 1. First, LOC8 provides users with spaceand context information, although it does notallow users to define rules to dynamically man-age their information or protect their privacy. Inthis sense, PRECISE lets users manage theirinformation and privacy preferences by usingrules to protect their identities, personal infor-mation, and locations against specific context-aware services or users.

SOCAM uses rules for inferring specific con-text information by considering other contextsand facts. CoCA is another solution that usesrules to dynamically manage context informa-tion. It infers users’ locations taking into accountthe context and space information. Instead,PRECISE makes use of reasoners to infer newknowledge considering the context and spaceinformation. In spite of SOCAM’s and CoCA’suse rules, they do not allow users to define poli-cies to manage their privacy preferences.

CoBrA allows users to protect their privacyby using policies, indicating the personal infor-mation that they want to reveal to other users.Instead, PRECISE is a privacy-preserving solu-tion that, by default, protects users’ identities,not revealing personal information to context-aware services. PRECISE allows users to definepolicies to specific services and users, not just tousers as CoBrA does. On the other hand, thepolicies defined in CoBrA take into account theusers’ location and the context in which they arelocated, whereas PRECISE allows users todefine richer policies than CoBrA. Users ofCoBrA cannot define policies to manage their

Figure 3. The PRECISE architecture.

IaaS

PaaS

SaaS

Engine

Andy

Users Precise

Preciseadministrator

Prec

ise

Adm

inis

trat

ion

Middlewares

Services

...

Serviceadministrators

Reasoner

Communicationmanager

ElectronicStoreA

ElectronicStoreB

ElectronicStoreC

CinemaA

...



location privacy, which is considered an impor-tant requirement in context-aware systems.

CoPS addresses the inability of CoBrA tomanage users’ location privacy, although CoPSdoes not consider privacy preferences about per-sonal information. Using policies, CoPS allowsusers to decide to whom and at which precisionthey want to share their location and contextinformation with other users. Instead, PRECISE’susers can define polices to specific users, services,or a group of them depending on their location,profiles, context, and time. Therefore, PRECISEcovers the users’ location privacy of CoPS throughhiding and granularity policies. Furthermore,

PRECISE allows users to generate fictitious posi-tions for specific users and manage the level ofcloseness at which they want to be located.

PPCS takes into account the shortcomings ofthe two previous systems. Specifically, PPCS pro-tects users’ information and locations by allowingusers to decide the granularity at which they wantto share their information, to whom, and where;and the time during which they want to revealinformation. However, PPCS is not able to gener-ate fictitious positions or establish the level of close-ness at which users want to reveal their information.

Finally, SeCoMan addresses the drawbacks ofPPCS, allowing users to define cloaking and close-

Figure 4. Sequence diagram showing the interactions between the PRECISE components when Andy is located at AreaA.

1-2

Get the context-aware andspace information fromindependentmiddlewares about whereAndy is

3-8

Manage the context-awareinformation gathered fromthe previous block, plusthe Andy’s policies, todecide at what servicesto ask for recommendations

9-12

Request recommendationsto the services inaccordance with theprevious information(Andy’s policies and thecontext-aware and spaceinformation)

13-1

4 Generate recommendationsto Andy by considering theservices’ recommendationsand the Andy’s behaviorpattern and preferences

1 Context-aware& space

information

Updateontology

Ontology &Andy’s policies

Ontologies

Ontology

& policies

Asynchronous process

Ontologies

ElectronicStoreB

ElectronicStoreAEngine

PRECISE

Andy

UsersMall’s servicesMall’s middleware

2

ReasonerMiddlewares

Mall’sinfrastructure

Communicationmanager

67

5

Andy is locatedat Area A

At what services to ask forrecommendations byconsidering Andy’s policies?

The Andy’s pseudonym is notprovided to ElectronicStoreAnor electronicStoreB as Andydid not define a revealingpolicy

Awaiting recommendations

Request ontology& Andy’s policies

Andy has the applicationrunning in the background

4

8

9

Provide the location ofAndy to ElectronicStoreAand ElectronicStoreB

3

11

13

11

1212

TabletB=600$Smartphone=400$, TabletA=500$

Ask for recommendations

Generaterecommendation

Aggregaterecommendations

ElectronicStoreA, AreaAElectronicStoreB, AreaB 10

14Display the recommendations to Andy

Main blocks of steps

Table 1. Comparison of context-aware systems.

LOC8 SOCAM CoCA CoBrA CoPS PPCS SeCoMan PRECISE

Context awareness ¸ ¸ ¸ ¸ ¸ ¸ ¸ ¸

Cloud paradigm ¸

Rules ¸ ¸ ¸ ¸ ¸ ¸ ¸

User privacy ¸ ¸ ¸ ¸ ¸

Service privacy ¸

Anonymity policies ¸ ¸ ¸

Release policies ¸

Revealing policies ¸

Hiding policies ¸ ¸ ¸ ¸

Cloaking policies ¸ ¸

Granularity policies ¸ ¸ ¸ ¸

Closeness policies ¸ ¸



ness policies, as well as to stay in certain locationsdepending on their privileges and manage the con-text-aware information through operational poli-cies. Furthermore, SeCoMan’s users can sharetheir location to the right person at the right placeand at the right time. In addition, PRECISE allowsusers to manage their privacy regarding services,although it is able to do it for users too as PRE-CISE is an extension of SeCoMan. This impliesthat their architectures, use cases, and the benefitsobtained from both solutions are rather different.

Additionally, all previous solutions are notoriented to the cloud paradigm, as PRECISE is,so they cannot obtain its profits such as dis-tributed processing and storage, scalability, loadbalancing, and monitoring.

Table 2 shows the technologies used by the pre-vious systems. For shaping the context, OWL 2 ismore expressive than the rest because it wasdesigned as an ontological language, besides beingan open standard language. Furthermore, we thinkthat Pellet is the appropriate reasoner because itsupports semantic rules expressed in the SWRLlanguage. SWRL is widely used in semantic web,which includes a type of axiom of the form if …then …, called Horn clause logic. Finally, the Jenaapplication programming interface is used in oursolution to generate the ontological models consid-ering the ontologies and the semantic rules.

CONCLUSION AND FUTURE WORKWe have presented a solution offering context-aware recommendations that takes into accountcontext information, and users’ locations, privacy,and behavior patterns. Context-aware servicesare allocated at the SaaS layer of the MCCparadigm, providing users with recommendationsabout context-aware information. The centralelement of our system is a middleware allocatedat the PaaS layer, called PRECISE, which man-ages the context, preserves the users’ informa-tion, and is independent of the middlewareproviding the space and context information.

As the next steps of this research, we plan todeploy a federation of services where they canshare some information according to users’ pri-vacy and preferences. It will allow PRECISE tooffer better custom context-aware recommenda-tions to users.

REFERENCES[1] G. Adomavicius and A. Tuzhilin, “Context-Aware Rec-

ommender Systems,” Recommender Sys. Handbook,Sept. 2011, pp. 217–53.

[2] G. Stevenson et al., “LOC8: A Location Model and eXtensi-ble Framework for Programming with Location,” IEEE Per-vasive Computing, vol. 9, no. 1, Jan.–Mar. 2010, pp.28–37.

[3] T. Gu et al., “An Ontology-Based Context Model inIntelligent Environments,” Proc. Commun. Net. and Dis-trib. Sys. Modeling and Simulation Conf., Jan. 2004,pp. 270–75.

[4] D. Ejigu, M. Scuturici, and L. Brunie, “CoCA: A CollaborativeContext-Aware Service Platform for Pervasive Computing,”Proc. 4th Int’l. Conf. Info. Tech., Apr. 2007, pp. 297–302.

[5] H. Chen, T. Finin, and A. Joshi, “An Ontology for Con-text-Aware Pervasive Computing Environments,” Knowl.Eng. Rev., vol. 18, no. 03, Sept. 2003, pp. 197–207.

[6] V. Sacramento, M. Endler, and F. N. Nascimento, “A Pri-vacy Service for Context-Aware Mobile Computing,”Proc. 1st Int’l. Conf. Security and Privacy for EmergingAreas in Commun. Networks, Sept. 2005, pp. 182–93.

[7] P. Jagtap et al., “Preserving Privacy in Context-AwareSystems,” Proc. 5th IEEE Int’l. Conf. Semantic Comput-ing, Sept. 2011, pp. 149–53.

[8] H. T. Dinh et al., “A Survey of Mobile Cloud Computing:Architecture, Applications, and Approaches,” WirelessCommun. and Mobile Computing, vol. 13, no. 18, Dec.2013, pp. 1587–1611.

[9] P. Falcarin et al., “Context Data Management: An Archi-tectural Framework for Context-Aware Services,” Ser-vice Oriented Computing Applications, vol. 7, no. 2,June 2013, pp. 151–68.

[10] A. Huertas Celdrán et al., “SeCoMan: A Semantic-AwarePolicy Framework for Developing Privacy-Preserving andContext-Aware Smart Applications,” IEEE Sys. J., to appear.

[11] A. Pfitzmann and M. Köhntopp, “Anonymity, Unobserv-ability, and Pseudonymity — A Proposal for Terminology,”Designing Privacy Enhancing Technology, Feb. 2001, pp.1–9.

[12] University of Murcia, “Complete Definition of the PRE-CISE Ontologies,” http://reclamo.inf.um.es/precise.

BIOGRAPHIESALBERTO HUERTAS CELDRÁN is a research associate in theDepartment of Information and Communications Engineer-ing at the University of Murcia, Spain. His scientific inter-ests include security, semantic technology, and policy-basedcontext-aware systems. He received an M.Sc. in computerscience from the University of Murcia.

MANUEL GIL PÉREZ is a research associate in the Departmentof Information and Communications Engineering at theUniversity of Murcia. His scientific activity is mainly devotedto security infrastructures, trust management, and intru-sion detection systems. He received an M.Sc. in computerscience from the University of Murcia.

FÉLIX J. GARCÍA CLEMENTE is an associate professor in theDepartment of Computer Engineering at the University ofMurcia. His research interests include security and man-agement of distributed communication networks. Hereceived a Ph.D. in computer science from the Universityof Murcia.

GREGORIO MARTÍNEZ PÉREZ is an associate professor in theDepartment of Information and Communications Engineer-ing at the University of Murcia, Spain. His research inter-ests include security and management of distributedcommunication networks. He received a Ph.D. in computerscience from the University of Murcia.

Table 2. Comparison between context-aware systems in terms of the technologies they are using.

LOC8 SOCAM CoCA CoBrA CoPS PPCS SeCoMan PRECISE

Contextmodeling

OntologiesOWL

OntologiesOWL

OntologiesRDF/OWL

OntologiesOWL Database Ontologies

OWL-DL N3OntologiesOWL 2

OntologiesOWL 2

Policiesmodeling

Not supported Jena rules Jena rules Rei policy RBAC Jena rules

N3 rules SWRL SWRL

Reasoner Not defined Jena Jena Flora-2 Not supported Jena Jena/Pellet Jena/Pellet


precise: privacy-aware recommender based on context information for cloud service environments

Documents