Open-Source, Web-Based, Framework for Integrating Applications with Social Media Services and Personal Cloudlets

Transcription

1 ICT Cloud Computing, Internet of Services & Advanced Software Engineering, FP7-ICT Open-Source, Web-Based, Framework for Integrating Applications with Social Media Services and Personal Cloudlets Deliverable Social media related services evaluation phase 1 Workpackage: Authors: Status: WP5 Service and Application Development Timotheos Kastrinogiannis (Velti), Theodoros Michalaeras(Velti), Iosif Alvertis (NTUA), Evmorfia Biliri(NTUA), Fenareti Lampathaki, (NTUA), Claudia Villalonga (CGI), Susana Ortega (CGI) Final Date: 16/09/2014 Version: 1.2 Classification: Public Disclaimer: The OPENi project is co-funded by the European Commission under the 7 th Framework Programme. This document reflects only authors views. EC is not liable for any use that may be done of the information contained therein.

2 OPENi Project Profile Contract No.: Acronym: Title: URL: FP7-ICT OPENi Open-Source, Web-Based, Framework for Integrating Applications with Social Media Services and Personal Cloudlets Start Date: 01/10/2012 Duration: 30 months Partners Waterford Institute of Technology Coordinator Ireland National Technical University of Athens (NTUA), Decision Support Systems Laboratory, DSSLab Greece Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V Germany INFORMATICA GESFOR SA Spain AMBIESENSE LTD UK VELTI SA Greece BETAPOND LIMITED Ireland 2

3 Document History Version Date Author (Partner) Remarks /05/ /06/2014 Iosif Alvertis (NTUA), Evmorfia Biliri(NTUA), Fenareti Lampathaki, (NTUA) Timotheos Kastrinogiannis (Velti), Theodoros Michalaeras (Velti) Contribution for Recommender SE section Contribution for Advertising SE section /07/2014 Claudia Villalonga (CGI) First integrated version /08/2014 Susana Ortega (CGI) Integration of Health SE section /08/2014 Susana Ortega (CGI) Deliverable provided to Project Coordinator and reviewers /09/2014 Timotheos Kastrinogiannis (Velti) Fixing reviewers comments 1.2 Gary McManus (WIT) Final Review and Submission 3

4 Executive Summary This deliverable describes the outcome of T5.2 Social Media related services evaluation software, Phase 1 of the OPENi project. This task is responsible for developing the Service Enablers that provide enhanced features to OPENi developers. These features will be available for WP6 applications. For each Service Enabler in this document, there is a description of their features, design considerations, and a demonstration (where applicable) for the first phase implementation. These Service Enabler (SE) first prototypes will be developed further in the next phase in order to enhance their functionalities or implement the missing ones. 4

5 Table of Contents 1 Introduction Advertising SE Prototype Advertising SE Overview, Motivation and Goals OPENi Advertising SE Overview OPENi Advertising SE Motivation, Goals, and Key Innovations Mobile Marketing and Advertising Landscape and Motivations Advertising SE Goals OPENi Advertising SE Key Introduced Innovations OPENi Advertising SE Methodology Advertising SE Prototype Design and Architecture Advertising SE Functionality and Components Overview Advertising SE: Process, Information Flow & Privacy Awareness Advertising SE: Data Modelling and API Specification Advertising SE Audience Management Metrics and Innovations Advertising SE Prototype Implementation On Advertising SE Audience Management Dashboard and Dashboard Features Audience Management Dashboard Use Case: Mobile Applications Marketing Campaign Audience Management Web Application Map Audience Management Dashboard Plots Audience Management Dashboard Analysis Cooperation with OPENi Components and Interdependency with other Work Packages Advertising SE Prototype Demonstration and Source Code OPENi Advertising SE Web Application Technology and the use of the Dashboard Advertising SE conclusions and outlook Recommender SE Prototype Recommender SE Features Goals of the Recommender SE Features Unique Value Proposition Interdependency with other Work Packages

6 3.2 Recommender SE Prototype Specification Scenarios Categorizations Context Dimensions Data Modelling API Places Products Applications Recommender SE Prototype Implementation Algorithm Architecture & Workflow Techstack Recommender SE Prototype Demonstration Recommender SE Conclusions and Outlook Health SE Prototype Health Service Enabler Features Health Service Enabler Goals Interdependency with other Work Packages Health Service Enabler Prototype Components Specification API Health Service Enabler Prototype Implementation Tools and technologies Description and Workflow Health SE Prototype Demonstration Health SE Conclusions and Outlook Conclusion for prototype Prototype 2 Plans Annex I: References

7 List of Figures Figure 1. Mobile Marketing and Advertising Land Scape Figure 2. Mobile Marketing Limitations and Drawbacks Figure 2-3: Advertising SE Role in Mobile Ad Serving Ecosystem Figure 4. Advertising SE Architecture and Functional Blocks Figure 5. Advertising SE Information Flow Diagram Figure 6 Advertising SE GUI Web Application Map Figure 7: Relation of Recommender SE with other Work Packages Figure 8: The general domain model of the Recommender SE Figure 9: Recommender SE Architecture Figure 10: Recommender SE Sequence Workflow Diagram Figure 11: User1 gets recommended categories Figure 12: User1 issues a request for recommendations, asking that only his gender and age range are taken into consideration Figure 13: User2 issues a request for recommendations, asking that only his gender is taken into consideration Figure 14: User2 issues the same request, but only age should influence the result Figure 15: Health SE interactions Figure 16: Sequence diagram for retrieving all objects from a cloudlet Figure 17: POSTing an ORU_R01 message to the cloudlet Figure 18: BMI cloudlet Figure 19: REST Client: HL7 ORU_R01 message from retrieving a cloudlet List of Tables Table 1 Advertising SE Targeting Segment Table 2 Advertising SE User Profile Targeting Segment Metrics Table 3 Advertising SE User Mood Targeting Segment Metrics Table 4 Advertising SE Location-aware Targeting Segment Metrics Table 5 Advertising SE Social Life Targeting Segment Metrics Table 6 Advertising SE Mobile Device Environment Targeting Segment Metrics Table 7 Advertising SE Apps Centric (User Experience) Targeting Segment Metrics Table 1-1: Categories of CBS used to correlate them with user groups Table 1-2: Context used as input either from the system or from the user Cloudlet (after given permissions) Table 1-3: The general form of the methods supported by the recommender

8 Table 1-4: Get Recommender Places API Method Table 1-5: The Recommendation Algorithm of the Recommender SE Table 1-6: Calculate_similarity (context node N1, context node N2) Table 3-7: Recommendation Frameworks Table 3-8: Graph Databases

9 1 Introduction Under the description provided in the OPENi DoW, T5.2 will make use of the social media related APIs (social, video, photo, music, location based services) to provide services that will take advantage of information and functionality otherwise only inherently available through implementing dedicated social media APIs in close collaboration with Task 5.1 so as to ensure the security of users data and the anonymity of all users. These service definitions will provide the building blocks of the demonstrators produced in WP6. The Serve Enablers included in this task are the following: Advertising SE Recommender SE Health SE The Advertising Service Enabler (SE) aims at enabling advertisers (OPENi service providers) to use OPENi opted-in users anonymized personal data in order to enable proficient mobile marketing audience management, as well as targeting optimization and personalization in advertising. The OPENi Recommender SE is an extension over the central OPENi Architecture (D4.1) that allows developers to build applications enhanced with recommendations natively provided by OPENi, without violating users cloudlet privacy policy. The Health SE aims at managing health and wellness data stored in the Cloudlet in order to enrich the results derived from those data via transforming the latter into a standard HL7 format in order any Health Organization with the necessary integration system to be able to exploit them. 9

10 2 Advertising SE Prototype 2.1 Advertising SE Overview, Motivation and Goals OPENi Advertising SE Overview In line with the description of Task 5.2, the following requirements (R) have been set for the creation of OPENi Service Enablers in the area of Social Media Related Services : This task will make use of (R_1) the social media related APIs (social, video, photo, music, location based services) to provide services that (R_2) will take advantage of information and functionality otherwise only inherently available through implementing dedicated social media APIs, in close collaboration with Task 5.1 so as (R_3) to ensure the security of users data and the anonymity of all users. These service definitions (R_4) will provide the building blocks of the demonstrators produced in WP6. Towards fulfilling the above requirements, with respect to OPENi WP2 use cases, the Advertising SE is introduced and analysed, while the corresponding Service Enabler s (SE) prototype is presented in detail. Advertising Service Enabler (SE) aims at enabling advertisers (OPENi service providers) to use OPENi opted-in users anonymized personal data in order to enable proficient mobile marketing audience management, as well as targeting optimization and personalization in advertising. The Advertising SE exploits OPENi Cloudlet and API Platform features to enable innovation in mobile marketing & advertising, via the collection, anonymization, aggregation, analysis, and correlation of large amounts of consumers personal data, in a privacy-aware manner, towards: optimizing the overall performance of mobile marketing and advertising campaigns; (Addressing R_2) enabling consumer-centric and context-aware (i) audience management and (ii) consumer targeting in mobile marketing, towards maximizing the benefit to end-users as a result of the content of the ads that they interact with; (Addressing R_1) providing mobile users enhanced advertising personalized experiences by utilising their digital and social footprint; (Addressing R_1) reassuring mobile end-users privacy, by introducing a novel privacy-by-design pull ad serving model, that decouples the processes of i) ad campaign audience estimation/targeting and ii) ad delivery (to users mobile devices). (Addressing R_3) OPENi Advertising SE Motivation, Goals, and Key Innovations Mobile Marketing and Advertising Landscape and Motivations Current widely adopted (state-of-the-art) methodologies and techniques in mobile marketing and advertising are highly affected and driven by the rapid evolution of a) mobile device technology (i.e., smartphones global penetration with enhanced computational/storage and internet connectivity capabilities), b) wireless access networks (WiFi, 3G/4G) and rich media technologies (e.g., HTML5) 10

11 and c) native application developers evolving communities (mainly driven by three application stores i.e., Google Play (Android), Windows Store and Apple Store (ios)). As a consequence, key factors that affect and determine the success of a marketing campaign such as end-users/customers overall experience and campaign targeting /performance optimization (e.g., tangible ROI), have not yet been sufficiently addressed. Figure 1. Mobile Marketing and Advertising Landscape As depicted in the above figure, the existing mobile marketing ecosystem consists of a large variety of stakeholders that interact along the path of serving an advertisement; from the Brand to the Consumers. The latter process involves: a) advertising services (for creating ads and optimising advertising campaign performance across channels) b) ad networks (for serving ads to end-users mobile devices) c) analytics and data collection services (for tracking campaign performance and collecting endusers data) d) application developers (for creating applications, often integrated with multiple ad serving networks, as a mean of monetization) e) application stores (for publishing and distributing mobile apps). Figure 2. Mobile Marketing Limitations and Drawbacks 11

12 The complexity and multiplicity of accessing and analysing consumers digital and behavioural data in the above ecosystem from various data sources (e.g., mobile marketing channels) and services (i.e., CBS such as social networks, ad networks, tracking and analytics services etc.), limits, or even prohibits, the realization of optimized and personalized mobile marketing campaigns. What is more, end-consumer s personal data are monopolised among the latter stakeholders leading to: - Consumers Data Fragmentation across multiple 3 rd party data services, imposing limitations not only on uniquely identifying users profile, but also on extracting and isolating valuable information due to the plethora of duplications; - Persona Data Privacy Leaks, due to the lack of a common and transparent way for enabling users to efficiently control and manage the use and the access on their digital data via advertisers thus, limiting the added value gained from their advertising experiences; The emerging era of Mobile Marketing and Advertising is characterized by personalization and audience targeting towards enabling enhanced end-user s experiences in line with their profile, interests, contextual trends and needs, and ultimately, maximizing the added value to the consumer. Towards this direction, advertisers and marketers need to deliver personalized marketing campaigns that take into consideration various user activities, behaviors, and digital trails, from preferences/interests and geo-location attributes to behavioral data and social networking interactions, towards addressing/targeting population segments with specific characteristics. An ideal behavioral targeting model should enable advertising agencies to combine consumers/users digital personal data for delivering ads that are relevant to the intended targeted market segment, at a rate which is convenient (and not intrusive) and using the channel which is most appealing to them (e.g., SMS, , Native Apps Banner Ads, Push Notifications, e.t.c.) Advertising SE Goals Motivated by the above emerging needs, the OPENi Advertising SE will enable the efficient introduction and exploitation of end-users personal data information in the overall life-cycle of mobile marketing and advertising in a privacy-by-design manner. Identifying the luck of such information due to data fragmentation in today s advertising process/lifecycle, Advertising SE aims at facilitating the design and realization of a large variety of new innovative ways for enabling personalised advertising. How about a mechanism to allow users monitise their data; include something that rewards users for sharing their data (in a privacy preserving way) with an advertising service? Advertising SE OPENi Platform A C Personal Data ADVERTISER Targeting Audience Management - Dashboard Ad Serving (Targeted) Audience Demographics Targeting Analysis B Campaign Audience Monitoring AD Network Targeting Data Retargeting & Optimization (Mobile Ad Server, Rich Media Server) Figure 2-3: Advertising SE Role in Mobile Ad Serving Ecosystem 12

13 Towards this direction, as depicted in the above figure, the Advertising SE will allow advertisers to efficiently perform: A. Audience Management. During the planning and creation of a new advertising campaign, advertisers will have the ability to designate a plethora of OPENi end-users personal data types appropriate for campaign audience targeting (such as: age, profile information, etc.). This will allow them to optimise campaign planning by deriving useful and practical insights on the estimated available audience per OPENi application or across applications, in terms of available audience volume (number of end-users) matching/fulfilling the required advertising criteria. B. Targeting & Personalization. Upon selecting the preferred target audience, the Advertising SE will provide advertisers with the requisite information (i.e., a unique Campaign ID) to realise targeted ad serving. Specifically, based on the above Campaign ID, OPENi users applications will be able to request an ad for a specific user by integrating with the application ad network. This approach reveals a new privacy-aware and personalised ad serving pull model (compared to the traditional push model) where an ad serving network had to maintain a user profile database in order to target specific user segments based on Users IDs (uuids). In the model we propose, the device/application of a user is requesting an ad from a specific ad network, based on a Campaign ID, without revealing any information regarding the consumer/user to the ad network. C. Campaign Audience Monitoring. Finally, throughout the duration of a marketing campaign, advertisers will be able to monitor the performance of a campaign and correlate it to the fluctuations of the original target audience (due to users opt-in and opt-out from the use of specific personal data). This will allow them to derive insights on the importance/accuracy/usefulness of the selected targeting metrics (audience segments) OPENi Advertising SE Key Introduced Innovations In line with the previous analysis, the Advertising SE introduces a variety of innovative features in the overall process of mobile marketing, made possible by the unique features of the OPENi platform as detailed bellow (and further justified within the following sections): I. Proficient Audience Management, prior to the initiation of an advertising campaign via the exploitation of end-users personal and behavioural profile data form multiple CBS (via OPENi platform), bridging the existing gap among multiple fragmented sources of consumers data. II. Plethora of Targeting Dimensions, supporting more than 60 targeting metrics and 900 targeting options, with unique features such as application context (in line with W3C) and users digital life context, leading to a new era of mobile marketing personalization. III. Real-time Targeting Optimization, via enabling the monitoring of the fluctuations in the volume of a campaign s audience (due to consumers opt-in/opt-out events), allowing the extraction of comparative and intuitive insights on the efficacy of the used targeting options. IV. Privacy Awareness in Personal Data Exploitation, via founding SE s operation on three privacy pillars that decouple the use of end-users personal data information (and users identifiers) from the process of audience estimation i.e., a) OPENi User s Consent/Control, in terms of accessing personal data that users have explicitly allowed to be used for advertising purposes; b) Data Anonymization and c) Data Aggregation, prior the latter are processed by Advertising SE. 13

14 V. Consumer-Centric Privacy-by-Design Ad Serving Process (Pull Model), via introducing a new privacy-aware and personalised ad serving pull model, compared to the traditional push model, where and ad serving network had maintain user profiles databases in order to target specific user segments, where the device/application is just requesting an ad from a specific ad network, based on a Campaign ID, without revealing any information regarding the application user to the ad network. As a result, Mobile Marketing/Advertisers will benefit from the ability to: Get advanced reports that create real-world value by interconnecting complex end-users anonymised personal and behavioural data to look for trends, outliers, and patterns yielding deeper insights into the interests of end-users and thus, building smarter targeted features and running more effective campaigns. Allow the dynamic estimation and adaptation of campaigns targeting mobile users, estimating expected behaviors and needs that would increase the efficacy of targeting and personalization in mobile marketing. This would ultimately optimize overall user s experience. Enable the graphical representation of deployed services, cross-channel campaign performance, audience demographic estimates, benchmark comparisons, cross-funnels conversations rates and ROI where applicable. while Mobile Users (Consumers) will gain from: Experiencing personalized mobile marketing campaigns based on their current interests and needs; Managing and explicitly controlling the use of their personal data (used for marketing and advertising purposes) in a transparent way; OPENi Advertising SE Methodology To facilitate the above goals a concrete methodology has been followed, consisting of two distinct phases in line with corresponding Task 5.2 deliverables. In this section, the goals of the first phase () are indicated and the main steps towards accomplishing them are detailed. Finally, a summary of the goals of the second development phase (D5.5) is provided. Adverting SE First Phase Methodology Step 1. Overall Adverting SE architecture and features have been initially designed, based on overall OPENi platform features and progress in WP4. Step 2. Audience Management KPIs have been studied and analysed (in line with existing SoTA), resulting in a detailed taxonomy of marketing campaign targeting metrics. Step 3. Analysis/Optimization and Performance Monitoring Algorithms have been developed and justified. Step 4. SE Dashboard GUI (web application) has been designed, including wireframes and mockups. Step 5. Audience Management GUI Prototye has been developed. 14

15 Let us underline that in the first phase of the Advertising SE prototype implementation, due to the dependencies with the development of the core OPENi platform, emphasis was placed on: a) the design of the Advertising SE (in terms of features, algorithms, information flow and APIs); b) the design and implementation of the Advertising SE GUI (mobile web application); c) data collection and processing algorithms towards enabling the envisioned GUI; d) the definition of interfaces and integration requirements (in terms of features and performance) of OPENi Platform components that will be used by the Advertising SE, towards reassuring the efficient functionality of the latter. Following the above methodology, in the second phase of the Advertising SE the following goals have been set: a. Advertising SE implementation and testing; b. Adverting SE API creation; c. Integration among Adverting SE and Web application GUI d. End-to-end demo scenario implementation; e. Advertising SE documentation f. Advertising SE integration with WP6 application prototypes. 2.2 Advertising SE Prototype Design and Architecture This section aims at providing a detailed analysis and justification of the Advertising SE design principles, its architectural components, and their corresponding interconnections. Moreover, the operation of the Advertising SE is analysed, in terms of data/information flows required towards enabling the envisioned features, placing emphasis on ensuring OPENi users personal data privacy. Finally, the SE algorithms (for processing data) are analysed and the resulting innovative metrics for supporting audience management and targeting optimization are detailed Advertising SE Functionality and Components Overview The overall functionality of the Advertising SE is founded on two main components, as depicted in the following figure: A. Adverting SE, part of OPENi API Platform, exposing a corresponding RESTful API. B. Advertising SE GUI, an external web interface, which facilitates advertisers (or any user of the SE) to visualise the outcome of the SE, control the available provided options and ultimately, exploit its features. Let us underline that Advertising SE can be directly used by a third party service via the exposed SE API, without necessarily using the corresponding GUI. 15

16 Figure 4. Advertising SE Architecture and Functional Blocks On one hand, the Advertising SE (upper side of the figure) is part of the OPENi API Platform, inheriting its design principles and features. The SE is built upon key operations and features of the OPENi API Platform and the Cloudlet to realise its goals. To that end, the Advertising SE interacts/consists of the following components: 1. Search API for identifying and revealing information across multiple cloudlets, multiple cloudlet object types and their corresponding attributes; 2. Data Aggregation Component for obtaining the identified information per Cloudlet in a concise manner in order to further anonymize it and create aggregations. 3. Cloudlet Notifications for monitoring the alteration of the value of specific objects attributes in users Cloudlets, especially the ones related to users opt-in/opt-out preferences for the use of their personal data. 4. Service Enable API for exposing the SE functionality to a 3 rd party service. 5. Advertising SE that implements SE logic, in terms of processing, anonymising and aggregating the retrieved data and then, exposing the latter though the SE API. Via the exploitation of the above core components, the Advertising SE gains the enhanced flexibility of performing advanced queries across Cloudlets towards identifying/retrieving similarity percentages among a) the targeting audience users profile criteria set by an advertiser for a specific ad campaign and b) the actual profile/contextual/behavioural data of users stored in their Cloudlets. As a result, the expected target audience, in terms of the amount of users with high similarity to the targeted profile, can be efficiently obtained (i.e., profile vectors similarity upon a specific threshold). In addition to the above, during the duration of a campaign, any alteration in the above audience can be detected via the use of the Cloudlet notifications component. On the other hand, the Advertising SE GUI is responsible for enabling advertisers (users of the SE, in general) to a) graphically realise operations via the SE and thus, b) to efficiently observe the outcome of the latter via intuitive visual representations (dashboards, plot, etc). To that end, the Advertising SE consists of the following components: 1. Data Analysis and Optimization, for deriving SE data and processing them towards feeding dashboard elements (e.g., plots); 16

17 2. Audience Targeting Wizard, Audience Evolution Monitoring Dashboard and Campaign Performance Evolution Dashboard, which are the core components of the web/mobile web GUI; 3. Campaign Audience Management Tracking Analytics; for retrieving complementary marketing campaign performance data from Analytics SE and correlating them in SE dashboards; 4. Personalising and Targeting Information; for enabling advertisers (end users) to export in a zip file information related to the targeted audience per campaign, as well as retrieve the corresponding Campaign ID (unique per campaign) that will allow them to perform targeted ad serving Advertising SE: Process, Information Flow & Privacy Awareness In this section, the operation of the Advertising SE is analysed from information flow point of view. These are the main actors involved, as depicted in the following figure: A. An Advertiser, that exploits the Advertising SE via the corresponding mobile web GUI; B. Advertising SE, that takes as input, user s (advertiser s) preferences, and then enables the business logic (e.g., algorithms, collection of information from multiple Cloudlets, e.t.c.) while exposing the outcome of the latter to the user via the GUI or the corresponding SE API. C. OPENi Platform, that provides the appropriate tools to the SE for searching and collecting OPENi users data from their corresponding Cloudlets. Figure 5. Advertising SE Information Flow Diagram Step I. Campaign Initiation. Assuming an advertiser wants to initiate a new marketing campaign and therefore, utilises the Advertising SE to optimising a target audience. To achieve this, she/he either uses Advertising SE GUI 17

18 or the Advertising SE API directly. For simplicity, in the rest of this analysis we assume that they use the provided GUI, but in both cases the flow of information is the same. I.A. The advertiser/user creates a new campaign, e.g., Ad Campaign X. I.B. The Advertising SE provides to the user the supported metrics for targeting and their corresponding available values (e.g., attribute type: Age; attribute values: 23-33, 33-43, 43-53); Step II. Audience Estimation. II.A. The advertiser/user indicates/selects the attributes of users profiles that she/he would like to target, given the particulars of Ad Campaign X. (e.g., attribute type: Age; attribute value: 23-33); II.B. The Advertising SE collects the relevant information and uses the Search API and Data Aggregation components (of OPENi Platform) to identify Cloudlets where the requested target information exists (e.g., Cloudlets, where in users profile object attribute Age exists) for all the target metrics set in Step I. The outcome of the latter is a matching percentage (vector similarity) per user (i.e., per Cloudlet) characterising how similar the overall users attributes values are with the ones set by the advertiser. Thus, if the derived matching percentage for a user is above a specific threshold, then the volume of overall target audience is increased (by one) and corresponding demographics are updated (e.g. target audience with age in increased). II.C. Upon collecting and aggregating the latter information (which are anonymised, since user IDs are not collected, merely used to produce an aggregate) the Advertising SE provides the latter information to the GUI (e.g., target audience volume is 1K users). Let us underline the following, towards highlighting the way OPENi end-users privacy is reassured in the above process: A. On OPENi User Consent/Control: In Step II.B, before identifying if a targeting metric exists among a user s personal data in her/his Cloudlet (e.g., user s age attribute in her/his Profile Object), the corresponding access rights policies/rules are queried, in order to indicate whether or not the user has provided her/his consent for accessing this information (i.e., the user has opt-in for the use of this data). If the user has opted-out then Advertising SE is never informed of the existence of this data (as if this data was never created). B. On Data Anonymization. In Step II.B, even if the user has explicitly consented to the use of specific data, its actual value is never exposed to the Advertising SE, since only a similarity percentage is retrieved (across all attributes). C. On Data Aggregation. In Step II.C, Advertising SE exposes to the GUI (and in general to the advertiser) only aggregated (and thus, anonymised) results e.g., expected audience volume 1K users with 80% of them between ages The above features justify how OPENi users privacy is reassured, since neither users IDs or users personal data types and/or values are exposed, while users privacy control rules dominate over the search process of the latter. Step III. Advertising Campaign Initiation. When an advertiser creates the preferred target audience, the Advertising SE provides her/him a unique Campaign ID. The latter ID is also stored, via the Products and Services API of OPENi API 18

19 Platform into an Advertising object in users Cloudlets. Consequently, OPENI users apps, if they support an ad serving mechanism from a specific ad network, are able to request a specific ad for this user via the knowledge of this Campaign ID. The above approach reveals a new privacy-by-design ad serving pull model, compared to the traditional existing push model, where an ad-serving network had to maintain/update users profiles databases in order to target specific user segments based on a unique User ID (UUID). In the proposed case: A. The device/application is just requesting an ad from a specific ad network, based on a Campaign ID, without revealing any information regarding the application user to the ad network. B. The latter Campaign ID and corresponding information related to the ad (e.g., the advertising brand) is stored in OPENi users Cloudlets Advertisement type of objects. This implies that the user will be able to explicitly control the access/use of this object(s) by his apps. Moreover, by opting-out from the use of the latter object, her/his OPENi applications will not have the ability to access the above object and thus, the user will never get a Campaign X ad. C. Finally, the ad serving process (via any of the existing methods) by the use of an ad network is completely decoupled from targeting and personalisation (via the Advertising SE) and thus, completely decoupled from user device and user profile data. Thus, end-user takes complete control in any of the steps in the above process. Step IV. Target Audience Evolution. Throughout the duration of a campaign, an advertiser can further monitor the evolution of the original target audience, in order to gain meaningful insights into it s efficacy. To facilitate the above: IV.A, Each time a user opt-ins or opt-outs from the use of a specific data attribute a notification will be sent to the Advertising SE to correspondingly adjust the volume of the target audience. IV.B, Upon collecting and aggregating the latter information, the Advertising SE exposes the update to the GUI. Input (for all phases) Output Advertising SE Data Flow I. End-user Targeting Criteria (from a predefined list) and targeting criteria values (e.g., Age: 21+, Gender: Male, Interests: Sports). Such information can be accessed mainly via Profile API and Context API objects (e.g., user, account, personalisation). II. Device Targeting Criteria (from a predefined list) and targeting criteria values (e.g., Device OS: ios, Device Manufacturer: Apple). III. Application Targeting Criteria (from a predefined list) and targeting criteria values (e.g., App developer: Marco Castro, App Ad networks: Admob App Type: Sports, Ad formats: HTML5/native formats (e.g., Rich Media Display Ads for WEB/mobile web/mraid, coupons, loyalty, e.t.c.). Targeting Audience Estimation The Advertising SE will obtain and derive audience volume metrics (i.e., number of end-user) matching advertisers targeting criteria along with corresponding a) audience demographics (e.g., age distribution, location distribution), b) device-centric characteristics (e.g., device OS) and c) OPENi Application characteristics (e.g., number of OPENi application the user of which 19

20 match with the target criteria or OPENi Application IDs (or corresponding developers ID) integrated/supporting a specific ad network(s) or a specific advertiser. Output Output Targeting & Personalization Advertising SE will create and update a unique Campaign ID that will facilitate advertisers (via the used ad networks to enable targeting/personalisation) Campaign Audience Evolution Advertising SE will obtain, analyse, and provide advertisers data related to campaigns audience demographics and corresponding alteration (through the duration of the latter) e.g. due to end-users opt-in/out-out actions Advertising SE: Data Modelling and API Specification In order to enable the envisioned features (Steps I, II and IV), the Advertising SE is exploiting a large variety of users personal data objects and corresponding attributes, towards supporting a range of targeting metrics (as detailed in the following chapter). A summary of these objects is provided below: OPENi API Type Profile API Activity API Location API Context API Objects Explored by Advertising SE Account, Application, Device, User Checking, Event, Like, Favourite, Comment, Dislike Event, Place, Route Context Attributes for Profile, Location, Device, Application In addition to the above objects, the realisation of an advertising campaign (i.e., Campaign ID creation and storage, Step III) is enabled via the use of an additional object, namely Advertising (under OPENi Products and Services API), described in the following: Advertisement Object Name Description Result id The object ID string object_type The object s type ("advertisement") string url The object s url string name The name of the advertising campaign (Campaign ID) string time duration A set of properties defining the time properties of the Advertising campaign A set of properties defining the duration Advertising campaign Set of Properties Set of Properties 20

21 Advertisement Object Name Description Result [adtype] [adnetwork] [adservices] Type of ads supported by in the campaign: HTML5, Rich Media Display Ads, MRAID, Coupons, Loyalty, etc.). A list of ad networks via which the advertisement is served. A list of ad services launching the advertising campaign. list of strings list of object ids list of object ids [applications] A list of application ids that this advertisement is linked with. List of object ids [criteria] Targeting criteria (users' personal data used for the campaign list of strings The attributes of this object, not only allows OPENi users to know how they are related with specific advertisements (via OPENi Privacy Visualisation Dashboard (see OPENi Deliverable D4.3)) but more importantly, to completely manage/control the ad serving process by opting-out from the use of these objects (i.e., not allowing apps to access the above objects or specific attributes of the latter). Advertising SE API will be RESTful and will support only HTTP GET methods in order to retrieve the related information. It has a certain path as an extension to the main, Generic API Path, and also required to specify the required objects that will be returned. The general form of the API call is shown in the table below. Method Path EXAMPLE Available objects Required Properties Optional Properties Response GET API_PATH/advertising/[objects] GET API_PATH/advertising/accounts?device=mobile Application, Device, User, Event, Place, Route, Checking, Event, Like, Favourite, Comment, Dislike, Account None. The audience management is related automatically with the authenticated users that allow Advertising SE to access their personal data (given the privacy rules that have set). Advertizing: adnetwork, adservice, adtype Time: start time, end time An audience object (with attributes: a) audience volume metrics (number of audience) b) audience demographics (age distribution, location distribution), c) device-centric demographics (device OS, ad network(s), advertiser, etc.) (Details are provided in following section) Method GET 21

22 Path API_PATH/advertising/name/[TYPE_OF_TARGETING] Available objects Required Properties Optional Properties Response None. The targeting is related automatically with the authenticated users that allow Advertising SE to access their personal data for enabling marketing/targeting. title={type_of_targeting} e.g, adnetwork, adservice, adtype Campaign ID Advertising SE Audience Management Metrics and Innovations In this section, a detailed list of the available/supported metrics and their corresponding values for audience management optimization via the Advertising SE is presented. Furthermore, the data structure of Audience Objects (JSON) managed via the Advertising SE API is highlighted. Specifically, via the assistance of an Audience Management Wizard (detailed in the following section) or directly via the use of the Advertising SE API, advertisers will be able to perform audience management by exploiting 64 Targeting Metrics Types with more than 900 Options. Towards enhancing presentation s efficacy, the latter have been clustered into the following six categories: Table 1 Advertising SE Targeting Segment Categories Wizard Steps Segment Title (Type of Targeting) # of Targeting Types Metrics 1 User Profile (e.g., age, genre, ) 10 (>100 targeting options) 2 User Mood Context 2 (>20 targeting options) 3 User Location, Geo-Interests and Geo-Context 10 (>200 targeting options) 4 User Social Life Footprint 13 (>200 targeting options) 5 Device/User Network Environment Context ; Device Features and Use 20 (>200 targeting options) 6 Application Centric Targeting Criteria 9 (>200 targeting options) Let us underline that the plethora and variety of the above metrics, as detailed bellow, is one of the unique features of the Advertising SE since the majority of existing targeting platforms (e.g., FB Ads) are supporting a subset of the above dimensions. This would not only enable advertisers to maximise the accuracy of the estimated audience, but more importantly ensure the end user receives ads relevant to their current content and needs. Table 2 Advertising SE User Profile Targeting Segment Metrics 22

23 User Profile Name Description Type Age Range Any, 13-24, 25-34, 35-44, 45-54, 55-64, 65+ string Gender Any, Male, Female string Has Children Children, No children string Race/Ethnicity White, Color, Asian, AIAN, NHPI, Other string Income High, Medium, Low, string Household Size Any, Exactly 1, Exactly 2, Exactly 3, Exactly 4, 2 or fewer, 2 or more, 3 or more, 4 or more, 5 or more string Education Any, High School Degree, Some college/associate, Bachelor s Degree, Graduate Degree string Interests Consumer (tag) Any Automotive Business & Finance Careers City/Region Communities & Services Education Entertainment Family Food & Drink Games Health & Fitness Home & Garden Mobile Content Music News & Information Religion & Spirituality Science Search Shopping Sports & Recreation Technology Travel Weather Any, Those who received, Those who interacted with (For Past/Launched Campaigns) (The above enable the reuse of already implemented campaign s targeting groups, segmented per end users behavior). string string Language Users Language string Table 3 Advertising SE User Mood Targeting Segment Metrics Users Mood Name Description Type Mood The mood of the user when the activity was performed (for a give object) string Table 4 Advertising SE Location-aware Targeting Segment Metrics Location Preferences Name Description Type Street The name of the street or streets intersection string Type of Residence The type of residence such as: Apartment, House etc. string City The city where the road is located string Locality The broader area where the city belongs string Country All Countries string Post Code Postal code or zip code string 23

24 Location Preferences Name Description Type Region Include a specific region string Town Include a specific town string Check-in and Location Likes latitude The latitude of a geolocation string longitude The longitude of a geolocation string height The height of the location, if available string visit Number of visits to a point of interest integer comment User comment for his visit string Table 5 Advertising SE Social Life Targeting Segment Metrics Social Life Footprint Name Description Type Account Users Active Social Accounts (e.g., FB, TW, e.t.c) string shop A physical or virtual location where someone can acquire a product or service, under a specific string like This connection refers to most objects that have a social aspect, it is unique per user and has a timestamp. It declares awareness, approval or support. string comment This connection leaves a text comment to another object. string dislike This connection refers to other objects, and declare string favorite This connection pins an object as favorite. string friendship event A mutual connection between two users. When there is a "follow" relationship, an "/incoming" or "/outgoing" additional path can be used under a GET method. Represents an event that occurs at a certain location during a particular period of time. string string game Represents a game or competition of any kind. string measuremen t product an entry for a measurement (blood pressure, weight, diabetes, general body) Represents a commercial good or service. Objects of this type MAY contain an additional fullimage property whose value is an Activity Streams Media Link to an image resource representative of the product. string string service Represents any form of hosted or consumable service that performs some kind of string 24

25 work or benefit for other entities. Examples of such objects include websites, businesses, etc. Table 6 Advertising SE Mobile Device Environment Targeting Segment Metrics Device/User Network Environment Name Description Type Bearer 2G, 3G, GPRS, CSD, Other string Roaming Roaming Not Roaming string Carrier User s Carrier Provider (Name) string Handset User s Device Type string Device ID Unique Device ID (UDID, Android ID, e.t.c.) string Application ID Unique Application ID string Device Type The name of the device model string Device OS The name of the OS installed string Device Logs Wireless Network Type Wireless Channel Quality Acceleromet ers The type of the access network The quality of the wireless channel Device accelerometer state string string string Cell Log The sequence of Cell ID during operation string Running Application Installed Applications Device running applications (list) Device installed applications (list) string string Screen State Device screen state string Battery Status Device battery status string Table 7 Advertising SE Apps Centric (User Experience) Targeting Segment Metrics 25

26 Application Centric Criteria Name Description (as defined by W3C) Type Background color Application background color string Format A description of application s block-level elements formatting. string Font A description of application s font properties. string Color A description of application s color properties. string Background A description of application s background color properties. string Text A description of application s text properties. string Box A description of application s box properties. string Classification A description of application s classification properties. string Text Copy A description of application s text copy properties. string 2.3 Advertising SE Prototype Implementation As already mentioned at the beginning of this report, in the first phase of the OPENi SEs prototypes implementation, due to the dependencies with the development of core OPENi platform, emphasis is placed on a) the design of the Advertising SE (in terms of: features, algorithms, information flow and APIs), as detailed in the previous section, b) the design and implementation of the Advertising SE GUI, c) data collection and processing features for enabling the envisioned GUI functionalities, as well as d) the definition of interfaces and integration requirement (in terms of features and performance) of OPENi Platform components that will be used by the Advertising SE, towards reassuring the efficient functionality of the latter. This section serves as a detailed report on the last three goals On Advertising SE Audience Management Dashboard and Dashboard Features Audience Management Dashboard Use Case: Mobile Applications Marketing Campaign Prior to the detailed analysis of the Advertising SE GUI, a brief analysis of the mobile advertising campaign scenario (use case) considered for the creation of the Advertising SE GUI is provided. Specifically, due to the multiplicity and complexity of mobile marketing campaigns due to the large variety of: a) marketing campaign scope/goals and b) means/technologies for serving mobile ads (to the end users mobile devices), for a specific combination of the above preferences, there exists a set of key performance indicators (KPIs) appropriate for intuitively reflecting the evolution and progress of the corresponding marketing campaign. 26

27 Fundamental Mobile Marketing Campaign Scopes: 1. Product Advertising; aiming at communicating the features and benefits of a product to customers and prospects. 2. Brand-Awareness; that plays an important part in business-to-business marketing, particularly for companies trying to win a major sale or contract. 3. Direct Response Advertising; that encourages prospects to register their details, typically in return for an incentive offer, such as a free gift, special discount or a copy of a business report for business prospects. Popular Mobile Marketing Campaign Means 1 : 1. Rich Media Banner Ads; where a promotional banner is served (appear) within users applications. To achieve the latter the application should be integrated with an ad-network that controls the process of ad serving. 2. Push Notifications; where short notifications are shown on the top of the screen of users device. 3. SMS/MMS; where marketing is enabled through cellphones' SMS (Short Message Service). 4. Mobile Web Marketing; advertising on web pages specifically meant for access by mobile devices. Within the scope of the Advertising SE GUI, the case of product advertising has been considered and specifically, the case of advertising a native mobile application (e.g., OPENi-enabled mobile application), while the means of i) rich media banner ads and ii) push notifications has been taken into account (as the two most popular means 2 in current mobile advertising). The selection of the above is not only justified by the popularity 3 of the latter (since mobile applications promotion via mobile ads is one of the most popular scopes), but also is tightly related to OPENi WP6 demo applications (where OPENi mobile apps promotions is part of the main functionality of the envisioned apps). To that end, the case of: Mobile Applications Marketing via Banner Ads and Push Notifications Mobile Campaigns has been selected for designing Advertising SE GUI, without of course limiting the use and exploitation of Advertising SE for the any of the above scopes. In the rest of this section details on the main steps and KPIs of the latter mobile campaign type are provided, justifying the information/plots used in the Advertising SE GUI campaign dashboards. Scope: Promoting the X OPENi Application via a banner ad (and/or push notifications) campaign, with the goal of maximizing the overall volume of downloads/installations of the app and ultimately, the number of application users). Campaign Sequential Process:

28 A. Banner ads (or push notifications) promoting the application X are sent to a target segment of OPENi applications/users. The banners may include text, images or rich media components motivating the user to install and use application X (Metric: Impressions, denoting the volume/number of banner ads severed/sent to the end-users). B. End-users clicks on the disseminated banners (Metric: Clicks (Unique Clicks), denoting the volume/number of clicks (unique users that clicked at least once in the banner ad)). C. Upon clicking on the banner, users are directed to the app store (e.g., Google Play in the case of Android applications), towards downloading and installing the application (Metric: Conversion, denoting the volume/number of user that installed application X). Campaign KPIs: Metric Indicative Results (example) Audience Impressions Clicks Unique Clicks Conversions 8 CTR (%) Click-Through Rate Audience Management Web Application Map In this section, the core elements (pages) and the overall map of the developed web application that serves as Advertising SE GUI are presented and analysed. Figure 6 Advertising SE GUI Web Application Map 28

29 As illustrated in the above figure, the Advertising SE web application consists of four basic navigation pages, eight dashboard pages and one wizard element with multiple sub-components (wizard steps). In the following a short description of the above is provided: 1. Audience Management Landing Page, where the user/advertiser is able to manage her/his OPENi account, to register or log-in; 2. Dashboard Overview & Main Navigation, where the user/advertiser is able to get an intuitive overview of her/his active campaigns and thus, either create a new audience targeted campaign, or select/navigate to an existing one, towards monitoring the evolution of the latter s audience and the corresponding performance; 3. Audience Management Wizard, where the user/advertiser is able to create a new target audience for the purpose of a new mobile application promotion campaign, via the assistance of a flexible wizard that enables her/him to navigate and determine the required audience profile among the variety of metrics/options provided by the Advertising SE (6 dimensions, more than 60 metrics and 900 options). 4. Targeting & Campaign Initiation, where the user/advertiser is able to retrieve a unique Campaign ID via which the ad serving process can be realised (e.g., via an ad network). 5. Campaign Performance Dashboard, where the user/advertiser is able to view campaign performance KPIs evolution and correlate them to the corresponding evolution of its audience. 6. Audience Evolution Dashboard, where the user/advertiser is able to navigate among various subdashboards, analysing the evolution of the initially selected/targeted audience, and how the volume of the latter is affected by end-users preferences (i.e. opt-ins and opt-outs from the user a personal data/attribute), for the majority of the selected targeting metrics. The latter information will enable an advertiser to acquired useful insights on the efficacy of the targeted audience towards adjusting and optimising the latter, as the campaign evolves. Let us underline that the developed audience evolution dashboards are one of the unique features of the Adverting SE, enabled in turn by the unique features of the OPENi platform Audience Management Dashboard Plots In line with the previous analysis, the majority of the plots enabled via the use of the Advertising SE, concerning one of multiple targeting metrics (e.g., genre (male/female), age (16-26, 26-36, 36-40), independently of the selected suitable plot format, provides aggregated information in three key dimensions: A. Time (from the beginning of the campaign) B. Performance/Engagement (in terms of number or percentage of users participated in the campaign (e.g., Clicked a banner, visited home page, performed an action)) C. Audience (in terms of number or percentage of users engaged/disengaged (opt-in / opt-out) from the use of this attribute towards targeting/participating in the campaign) 29

30 To the best of our knowledge, such a comparative analysis (due to the existence of dimension C) is one of the unique features introduced by the OPENi Advertising SE, leading to a new era of mobile marketing personalisation and optimization Audience Management Dashboard Analysis In this section a set of fundamental mockups are presented, from which the Advertising SE prototype has been implemented, while the corresponding functionality is analysed and justified. Audience Management Landing Page Functionality: Advertisers Account Management and Registration (new Cloudlet Creation); Log-in and Authentication OPENi Advertiser/User unique ID generation; Advertising GUI Main Overview Dashboard (& Navigation Page) Information Displayed: Local Time; Notifications/Alerts (on key campaign performance events; Current Campaigns Overview # of Active App Campaign # of Counties # of Targeting Metrics Used Overall Active Campaigns Performance Insights (Aggregated KPIs) Most Efficient Targeting Metrics (that positively affected: a) targeted audience increase and b) campaign s conversions increase). Functionality: New targeting campaign Creation Existing Campaign Selection (Navigation via side bar) Global Campaign Filters: Ad Networks, App Developers, Advertising Brands, App Developers 30

31 Audience Management Wizard Functionality: Advertiser s wizard for selecting target audience profile in terms of targeting metrics and corresponding values. 6+1 Steps Wizard (6 dimensions, 68 metrics); Left side: Audience Selection Right Side: Audience Visualization Intuitive real-time insight; Final Step: Save Targeting. Targeting & Campaign Initiation Functionality: Obtain Campaign ID. Export a zip with OPENi developers (ID or names) and/or Ad networks that the applications of the target audience belong/collaborate/integrate. This will allow the advertiser to know which ad networks to interact with towards enabling his campaign. 31

32 Campaign Performance Dashboard Information Displayed: The performance dashboard aims at providing detailed insights on the performance of a selected campaign and thus, to provide fruitful correlations of the accomplished campaign results with respect to the selected target audience profile. Specific details provided include: A. Unique Aggregated Values on Campaign KPIs (audience, impressions, clicks, conversions, CTR); B. Target Audience vs Click vs Conversions (installation) evolution over time. C. Campaign users geo-distribution. D. Key target metrics types that contributed the most (or less) to the success of the campaign, in terms of audience volume evolution. 32

33 Audience Evolution Dashboard Information Displayed: Audience evolution dashboard aims at providing detailed insights on the evolution of the volume of the initially targeted audience (due to users opt-in and opt-out actions) for each of the six core targeting dimensions supported by Advertising SE. Specific details provided include: A. Aggregated Values on the Audience Volume fluctuations within specific period of time B. Target Audience vs Click vs Conversions evolution over time. C. Key target metrics types that contributed the most (or less) to the success of the campaign, in terms of audience volume evolution. D. Comparative Analysis among multiple targeting metrics and their contribution to the overall campaign performance over time Cooperation with OPENi Components and Interdependency with other Work Packages In the following section an analysis of the main Advertising SE interactions with the OPENi API Platform and Cloudlet Components is provided. Search API (part of OPENi API Platform), for identifying and revealing information across multiple cloudlets, multiple cloudlet object types, and their corresponding attributes; Products and Services API (part of OPENi API Platform), for creating, updating and managing Advertising objects; Aggregation Component (Cloudlet Platform), for obtaining the identified information per Cloudlet in a concise manner since the data aggregation (DA) component will offer 3rd parties the ability to view aggregated user data from multiple cloudlets while concealing the individual cloudlet owner s identity. Advertising SE will exploit/use AG component in order to match OPENi end-user with marketing/targeting criteria (given a specific list of targeting metrics) further enabling the SE to provide enhanced audience management reports. Moreover, it will enable the Advertising SE to retrieve and provide advertisers appropriate targeting information. To reassure end-users personal data privacy the Advertising SE via the DA component will negotiate with the authorisation component to identify cloudlets that wish to share data with the 3rd party in a privacy preserving way. 33

34 Notifications (Cloudlet Platform), since various services can sign up for notifications of events on a user s Cloudlet, the Advertising SE will collaborate with the Notifications Component towards Campaign Audience management. As an example, when a user opts-in/opts-out to allow his personal data be used as targeting criteria of a campaign, the Advertising SE will be notified to reproduce the targeting audience. The Advertising SE has dependencies with other Work Packages, as identified below (in two different phases): Regarding WP4, integrated OPENi Platform with Cloudlets: Generic APIs (Search API, Products and Services API) Context API Authentication & Authorization (Phase II) OPENi Policy Eng. And Privacy Rules (Phase II) SPARQL interfaces (Data Aggregation Component) (Phase II) Notifications API (Phase II) Regarding WP6, Advertising SE will be used/integrated with the following apps towards enabling endto-end use case scenarios: Task 6.2 OPERA (Openi Personalized Recommendations and Advertising Application) for enabling mobile applications advertising campaigns/recommendations; Task 6.2 OPERA (Openi Personalized Recommendations and Advertising Application) for enabling personalized advertising campaigns; Task 6.3 PSA (Personal Shopping Assistant Application) for enabling location aware personalized ad campaigns related to products. 2.4 Advertising SE Prototype Demonstration and Source Code OPENi Advertising SE Web Application Technology and the use of the Dashboard Towards developing the features and components of the Advertising SE GUI web application prototype, as detailed in the previous section, the following technologies have been used: Web/Mobile Web Application. It has been developed in HTML5 (Rich Media Mobile Web) and the required features and functions have been implemented in JavaScript. Responsive Design has been adopted towards efficiently creating a web application that dynamically adapts its UI/UX flows and properties according to the attributes of the displayed interface, aiming primarily on supporting web application s rendering over desktop browsers (Chrome and Firefox (latest versions)) and mobile tablets, as well as high end mobile devices. Front-end framework is Bootstrap ( Dashboard Plots. In the case of specific plots, open source plug-ins have been used (Highcharts ( Plugindetector ( 34

35 Finally, the Advertising SE Web Application is packaged and can be provided to OPENi developer/users for directly using it (along with OPENi Platform and Advertising SE). The template can be easily customised/parameterised by the developer. OPENi Advertising SE is accessible at: - Demo GUI: - Source Code: 449/tree/T5.2/AdvertisingSE/ Note: The above demo dashboard is not fully functional, since the integration of the latter with Advertising SE is a prerequisite. 2.5 Advertising SE conclusions and outlook As detailed at the beginning of this section, during the second phase of the Advertising SE implementation the following milestones have been set: a. Advertising SE Implementation and Testing; b. Adverting SE API Creation; c. Integration between the Advertising SE and Web application GUI d. End-to-end Demo Scenario Implementation; e. Advertising SE Documentation f. Advertising SE Integration with WP6 Application Prototypes. 35

36 3 Recommender SE Prototype 3.1 Recommender SE Features Goals of the Recommender SE Under the description provided in the DoW, T5.2 will make use of the social media related APIs (social, video, photo, music, location based services) to provide services that will take advantage of information and functionality otherwise only inherently available through implementing dedicated social media APIs. [ ], in close collaboration with Task 5.1 so as to ensure the security of users data and the anonymity of all users. These service definitions will provide the building blocks of the demonstrators produced in WP6. The OPENi Recommender SE is an extension over the central OPENi Architecture (D4.1) that allows developers to build applications enhanced with recommendations natively provided by OPENi, without violating users cloudlet privacy policy. The main goals of the OPENi recommender SE are to (a) provide enhanced, useful recommendations to users that fit their preferences, (b) reduce developing time and build an ecosystem of powerful, OPENi-enabled applications, and (c)exploit multiple Cloudlet information, in a way of respectful community (d) with respect to users privacy. As described in relative chapter for Service Enablers in D3.1, there is lot of progress done in Recommender Systems, with different solutions to match in different problems. Nevertheless, no generic solution can apply for all different types of objects (e.g. persons, places, products, videos etc.). Additionally, most of the Recommender Systems that outperform are based on historical data and on user correlation (i.e. collaborative filtering), in order to identify patterns among users and no specific preferences over existing objects. But under the scope of OPENi, where data belongs and must be stored only in user s personal Cloudlet, such an approach could not be used. Thus the recommender has quite a few technical challenges to overcome, such as: Not caching multiple users data centrally and not storing users correlations; thus a typical collaborative filtering (CF) approach cannot be followed Not storing data that can identify users, or interrelate them Avoiding the cold start problem; for many objects (e.g. places, products etc.) it is expected not to find any relative interactions in the Cloudlet, to provide the necessary recommendations Features The Recommender SE provides both suggested categories for specific object types, and recommended objects to end-users. In more detail, the SE builds a recommendation system that can run with the distributed data architecture of OPENi by using contextual data of various objects, including the latest status of the authenticated user, in order to match users to specific contextual groups. Such contextual groups of users are interrelated with general object categories, thus the developer of an OPENi application can show what object categories are in the interest of the user, but also ask for specific objects under these categories in order to present final recommendations to the application users. The Recommender uses categories to build user preferences rather than specific 36

37 objects, in order to avoid the cold start problem and the privacy limitations, as most of the objects can be found in Cloud Based Services rather than in users Cloudlets, like places or products. The objects that have been identified as the most interesting to be part of the recommender, in relation to the described scenarios in WP2 and the applications in WP6, are places, products and applications Unique Value Proposition The field of recommendations has reached a great level of optimization, with impressive levels of specialization for certain industries; the Netflix 4 prize is a common example of the progress certain algorithms have achieve in recent years. It would be naïve, therefore, to claim that the OPENi Recommender SE can outperform such solutions since it aims at fulfilling a different need, that of providing more generic recommendations, which are then extendable with new objects. A Collaborative Filtering approach would need to store profiles of users and history of activity centrally; common platforms like Amazon, Facebook, Netflix or Twitter that control and own users data can optimize their solutions with data caching. Thus, the main offering (UVP) of the OPENi Recommender SE is the respect of users privacy and their right to keep their data in their own personal storage, without any caching or processing of their profile that could identify them without their permissions. To achieve this, the OPENi Recommender SE uses contextual data, collaboratively enhanced through different applications, in order to classify contextual and situational profiles of users and interrelate them with specific product categories and secure user privacy. In that way, a user gives access to specific data only when she uses the service, to match a specific profile, on the condition that the results cannot be used to identify any specific identity of the user and that their personal data cannot be stored centrally. When the user context changes (e.g. user mood, used device, current application), recommendations will also change Interdependency with other Work Packages The Recommender SE has dependencies with other Work Packages, identified in two different phases, as shown in Figure 7. In more details, the Recommender interacts with: a) WP4 - The Integrated OPENi Platform with Cloudlets: Generic APIs for communication with Cloudlets and CBS Context API Authentication & Authorization (Phase II) SPARQL interfaces (Phase II) Figure 7: Relation of Recommender SE with other Work Packages 4 Netflix Prize. Wikipedia. 37

38 b) WP6 - Personalised Shopping Assistant: Recommend Places from CBS services and Cloudlets Recommend Products coming from Cloudlets (Phase II) c) WP6 - Personalised Advertising Prototype Recommend Applications coming from CBS services Recommend Applications coming from Cloudlets (Phase II) 3.2 Recommender SE Prototype Specification Scenarios The Recommender SE does not interact directly with end-users, thus it is the relevance and the personalisation of the results that highlights the power of a native recommender system that does not violate user privacy, but is enhanced with contextual information from OPENi Cloudlets. Note: The following scenarios try to highlight the user experience via applications that are developed in WP6, as users have no direct interaction with the Recommender SE; this does not mean that the current task is going to develop any UI or application for the following scenarios, it will only be integrated through its Recommender API. I. Basic scenario: Maria wants to look for interesting places nearby while shopping (e.g. restaurants to eat in, stores to shop in etc.). She opens the OPENi personalised shopping application & gets a list of various places around her. She decides to search only for restaurants, as she is exhausted and she needs to eat something. Maria gets a restaurant with her favorite cuisine, but she also notices an interesting bar with Jazz music that serves some dishes too; the OPENi application knew from her music preferences and her current mood that Maria would need something more relaxing. Maria loves Jazz, and now loves her app for the perfect recommendations. II. Shopping scenario: Maria enters an OPENi-enabled travel agency store, found through a place recommendation in the personalized shopping application. While shopping around, she chooses the store and she gets a list of the holiday packages that fit her profile. Maria was tired lately, and by taking into account her age group, the application presents some offers related to cruises in the Greek Islands or all-inclusive holidays in Andalucia. III. Application recommendations: Maria is bored while waiting at the bus station. She opens the Personal Advertising application and browses recommended applications. Based on her profile, she gets a list of applications, like the new BMI health app to keep fit and the Messaging application to keep in touch with her friends. Apart from these basic recommendation functionalities, as soon as a SPARQL interface or a general search method is enabled, to get data from multiple Cloudlets without violating any users privacy, it will be easy for the recommender to return (a) top objects (e.g. places), (b) objects that my friends had interacted with (e.g. places my friends had been), (c) trending objects or make (d) location based queries for specific objects, coming from various Cloudlets. The capability of supporting such scenarios will be studied in collaboration with WP4, to secure user privacy and the scalability of such 38

39 solutions. The adaption of such scenarios will become available in Phase II, if enabled by central architecture Categorizations In order to interrelate objects from different services and use categories to get more personalised results, the most common categories used in CBS must be identified. The Recommender SE will use these categories to correlate them with user profiles and use them as a filter to the CBS APIs in order to return the proper objects, which are available in Table 3-1. Table 3-1: Categories of CBS used to correlate them with user groups OPENi Categories CBS Categories Places Facebook Page Categories: Google Places: Foursquare: Yelp: Products Google products: Central Product Classification (UN): United Nations Standard Products and Services Code (unspsc): Amazon Products API. US store categories: html Applications Mobile App Categories: Context Dimensions The Recommender SE depends on contextual information derived either from the system, by the time of the API call, or from specific objects coming from authenticated user s Cloudlet. In Table 3-2 there is a detailed description of all the properties and the available values that are expected as input for the system. Table 3-2: Context used as input either from the system or from the user Cloudlet (after given permissions) CONTEXT (from system) application_classification Books, Business, Communication, Education, Entertainment, Fashion, Finance, Food & Drink, Health & Fitness, Lifestyle, Local, Music & Audio, News, Contests, Photo & Video, Productivity, Reference, Shopping, Sports, Travel, Utilities, 39

40 Movies & TV Time-window (from current_location_time) Week-period (from current_location_time) Season (from current_location_time) Morning, Noon, Afternoon, Evening, Night Daily, Weekend, Holidays Winter, Summer, Spring, Autumn USER SPECIFIC (from cloudlet) mood_value Basic Emotions: Happy, Angry, Sad, Scared, More for recommender purposes: Hungry, Bored, Tired, Anxious, Calm Note on Mood Dimensions: feeling good, high energy (happy) feeling good, low energy (calm) feeling bad, high energy (anxious) feeling bad, low energy (depressed) personalization_age_range 13-17, 18-24, 25-34, 35-44, 45-54, 55-64, 65+ personalization_education Primary, Secondary, Bachelor, Master, Doctoral 5 personalization_country GR, EN, FR, IT,... 6 personalization_gender personalization_interests personalization_ethnicity personalization_town personalization_household_size personalization_has_children personalization_income Male, Female books,cars,shopping,games Hellenic, French etc. Athens, Berlin, Waterford etc. Number of household Boolean Group of income 5 International Standard Classification of Education. Wikipedia. 6 Country Codes. 40

41 3.2.4 Data Modelling Figure 8 describes how the recommender in a graph database is modelled. The main idea behind the modelling is that every CBS service consists of various categories and subcategories, and a group of contextual properties, derived either from the system or the user, shows preferences of specific subcategories. The model is generic in order to be extended to different objects. In particular, the main objects/nodes are: Service (type, version): the specific category and the version of its API that the recommender will interact with, to get the recommended objects. Category (name): the hierarchical category of a service. Subcategory (name): multiple subcategories, under a category or another subcategory. Service specific. System Context (id, datetime): a set of contextual properties derived from the system. User Context (id, datetime): a set of contextual properties derived from a user Cloudlet, used to match him with an existing profile or create a new one if there is no match. There are also a series of other contextual nodes, like country, age group etc., which are not finalized if they are going to be different nodes to exploit the graph capabilities of a database or as node properties, in order to use the filtering capabilities of a query language (i.e. Cypher). Thus a more generic approach is used in the current model mapping. 41

42 service (type, version) hascategory 1...Μ 1...Ν issimilarto category (name) 0...N 0...Μ issimilarto showpreferenceon (matched, viewed) 0...N country (code) 0...M activity (type) hassubcategory showpreferenceon (matched, viewed) hassubcategory 0...Μ 0...Μ age (range) 0...N 0...N 0...Μ showpreferenceon (matched, viewed) 0...Μ education (level) subcategory (name) showpreferenceon (matched, viewed) 0...N 0...N 0...N hascontext hascontext hascontext 0...Μ hascontext 0...N 0...Μ 0...Μ 0...Μ 0...Μ showpreferenceon (matched, viewed) 0...N mood (type) hascontext 0...Μ 0...Μ showpreferenceon (matched, viewed) showpreferenceon (matched, viewed) gender (type) hascontext 0...Μ showpreferenceon (matched, viewed) showpreferenceon (matched, viewed) physicalstatus (status) 0...N 0...N device appcategory (type) showpreferenceon (matched, viewed) 0...N 0...N 0...N hascontext hascontext 0...M musicpreferences (type) 0...M hascontext hascontext 0...N systemcontext (id, datetime) usercontext (id, datetime) 0...N Figure 8: The general domain model of the Recommender SE 42

43 Privacy and Security framework evaluation software phase 1 D API The Recommender SE supports a series of resources, accessed under a RESTful API. The recommender objects can be accessed, as can the recommended categories, and also the context the developers can use to identify the properties that can be used to improve requests, as presented in Table 3-3. Table 3-3: The general form of the methods supported by the recommender Resource Path Results [OPEN_API_PATH]/recommender/[objects] A list of recommended objects, as defined in the path, for the authenticated user. [OPEN_API_PATH]/recommender/[objects]/categories A list of the recommended categories for the authenticated user. [OPEN_API_PATH]/recommender/context Returns a list of all the available context properties that are supported by the recommender. Supportive method for the developers. In the following paragraphs, the available objects are analysed and described in depth Places Table 3-4: Get Recommender Places API Method URL Method [OPEN_API_PATH]/recommender/places GET Parameter long the longitude of the area where the places should be found lat the latitude of the area where the places should be found rad - optional the radius of the area where the places should be found in (in km, default is 3km) category - optional a filter for specific categories where recommender s places should belong, if available (bar, restaurant, monument, all etc.) method optional when there are more sophisticated methods (Phase II), this property sets the specific method used on the resources (i.e. popular, trending, friends) orderby optional when changing the order of the resutls (name, distance, score) context - optional - a list of contextual data used for the recommender (all, gender, age, off etc.) 43

44 Privacy and Security framework evaluation software phase 1 D4.3 Response A list of places, with the following properties: name the name of the place url a URL to the resource type the object type, by default place service the service where this object comes from (facebook, foursquare, google, openi) picture - a URL to the picture representing the place description any available place description address the address of the place location {long, lat} the location of the place score the score given by the recommender categories a list of categories where this place belongs to URL Method Response /recommender/places/categories GET A list of categories, with the following properties: type the object type, in that case place name the name of the category score the score given to the certain category Products URL [OPEN_API_PATH]/recommender/products Method GET Parameter category - optional a filter for specific categories where recommender s products should belong, if available (bar, restaurant, monument, all etc.) method optional when there are more sophisticated methods (Phase II), this property sets the specific method used on the resources (i.e. popular, trending, friends) orderby optional when changing the order of the resutls (name, price, score) context - optional - a list of contextual data used for the recommender (all, gender, age, off etc.) price-from optional the starting point of the price 44

45 Privacy and Security framework evaluation software phase 1 D4.3 price-to optional the upper limit of the price currency optional the currency where the price filter will apply. Currently only euro supported Response name the name of the product url a URL to the resource type the object type, by default product service the service where this object comes from (etsy, ebay, openi) picture - a URL to the picture representing the product description any available product description score the score given by the recommender categories a list of categories where this product belongs to price the price of the product currency the currency of the returned product URL /recommender/products/categories Method GET Response A list of categories, with the following properties: type the object type, in that case product name the name of the category score the score given to the certain category Applications URL [OPEN_API_PATH]/recommender/applications Method GET Parameter category - optional a filter for specific categories where recommender s applications should belong, if available (bar, restaurant, monument, all etc.) method optional when there are more sophisticated methods (Phase II), this property sets the specific method used on the resources (i.e. popular, trending, friends) orderby optional when changing the order of the resutls (name, price, score) context - optional - a list of contextual data used for the recommender (all, gender, 45

46 Privacy and Security framework evaluation software phase 1 D4.3 age, off etc.) Response name the name of the application url a URL to the resource type the object type, by default application service the service where this object comes from (etsy, ebay, openi) picture - a URL to the picture representing the application description any available application description score the score given by the recommender categories a list of categories where this application belongs to price the starting price of the application rating any given average rating to the application price the price where this application is sold os the platform where the application is available, e.g. ios URL /recommender/applications/categories Method GET Response A list of categories, with the following properties: type the object type, in that case application name the name of the category score the score given to the certain category 3.3 Recommender SE Prototype Implementation Algorithm The OPENi recommender could not be based on typical recommendation algorithms, as no indexing or correlation of data is allowed or facilitated by the OPENi architecture. For that reason a Graph oriented approach was followed, which uses the context of the current user to extract the correct matching. The general algorithm that is used in that phase of the recommender SE development is available at Table 3-5; weights and specific contextual properties used to match contextual profiles will be constantly improved based on the data stored in the Cloudlets and the testing process that will be followed through Phase II of the SE development. The following algorithm is applied over a Graph Database to allow extendibility with future objects. 46

47 Privacy and Security framework evaluation software phase 1 D4.3 Table 3-5: The Recommendation Algorithm of the Recommender SE Step 1. get user context CU Step 2. for every context node Ci Step 3. Simi = calculate_similarity(cu,c) Step 4. for every node of the k nodes with largest Sim Step 5. calculate number of times every category has been accessed as a_score Step 6. calculate sum of importance for every category access as i_score7 Step 7. calculate combination of a_score and i_score as score Step 8. add scores for the same category from all nodes Step 9. rank the categories Step 10. return the category with largest score (keep all scores to later refine returned results) Table 3-6: Calculate_similarity (context node N1, context node N2) Step 1. similarity = 0 Step 2. for every field f of N1 Step 3. if N2(f) = N1(f) Step 4. similarity = similarity + 1*field_importance 8 Step 5. return similarity Architecture & Workflow The Recommender SE runs in parallel with the OPENi platform, over a Container to allow sandboxing and remain independent of any technology. It communicates with the OPENi platform through the common Generic API, RESTful services in other words, and is exposed through a RESTful Recommender API too, as described in When a SPARQL or an aggregated search interface becomes available through the platform, in Phase II, the Recommender will extend its functionalities in that direction too. The Recommender SE is built over a Graph Database where the contextual information is stored, after permissions given to the Service Enabler via the authentication and authorization system of OPENi. Then the algorithm extracts and matches categories, communicates with CBS services and the Cloudlet through the platform, and final results are combined and returned to the third party application via the RESTful Recommender API. The architecture is available at Figure 9. 7 importance of an access differs based on whether it was a direct access or propagated from parentchild-sibling category 8 context fields belong to one of the following categories: demographics, system, preferences. Each of the categories is associated with an importance score that affects how much a field can influence the similarity measure between context nodes. 47

48 Privacy and Security framework evaluation software phase 1 D4.3 Figure 9: Recommender SE Architecture In more detail, in Figure 10 there is an example workflow diagram that describes the basic interactions between the Recommender SE and different components (for places only). The main processes are: checkin : For every check-in in the user cloudlet that has not been synced yet, an edge is created connecting the user context node with the proper object subcategories. Edges are also created from the user context node to the super-categories and sub-categories of the initial ones, but with a lower importance score. context : Similarity of current context to existing context nodes is calculated and the k best matching nodes are identified find most suitable categories : For every context node selected in the previous step, the categories with the highest score are calculated. The scores of same category nodes are added, and based on these scores the categories are ranked. The category with the highest score is returned. sort places": All returned places belong to the category that was used to perform the search. In instances where some places also belong to a subcategory of that category, if there is a corresponding score from previous step it can be used to further improve the result. For the category pairs that can be compared this way, the list is sorted accordingly. All places belonging directly to the initial category are left at the top of the list. 48

49 Privacy and Security framework evaluation software phase 1 D4.3 Figure 10: Recommender SE Sequence Workflow Diagram Techstack An analysis of relevant technologies has been carried out, to choose the most appropriate database and recommendation framework. The recommendations frameworks (Table 3-7: Recommendation Frameworks) have mainly opensource licenses, but most are machine learning and data mining frameworks used to analyse existing data. After the analysis of the available graph databases (Table 3-8: Graph Databases), it was chosen to go with a Neo4j database, which has integrated in the Cypher language many graph analysis capabilities; thus using the native features of Neo4j, does not require any extra framework for analysis. The API is currently exposed through the Jersey framework, as Neo4j has better performance with the native Java libraries, but as long as the algorithm is improved the Recommender will progressively move towards a Django framework to have a familiar, homogenized technology stack with the platform. The whole system is sandboxed in a Docker container. Table 3-7: Recommendation Frameworks Name Language License Capabilities 49

50 Privacy and Security framework evaluation software phase 1 D4.3 Weka 9 Java GNU License Machine Learning Scikit 10 Python BSD License Machine Learning Mahout 11 Java Apache License Machine Learning & Data Mining Lenskit 12 Java GNU License Recommender Toolkit Crab 13 Python BSD License Recommender Framework Pandas 14, Numby Python BSD License Data Analysis Library Gensim 15 Python GNU License Statistical Semantic Analysis Reco4j 16 N/A N/A Recommendation framework over Neo4j Py2neo 17 C, Python Creative Commons Accessing Neo4j through RESTful services TinkerPop 18 Java Apache License A Graph Computing Framework Table 3-8: Graph Databases Name Technology Query Language License Neo4j 19 Object Graph Database Cypher Community License & Commercial Sesame 20 RDF Database SPARQL BSD License Virtuoso 21 Multi-model data server (RDB, XML, RDF, Free Text) SPARQL, SQL OpenSource i & Commercial 9 Weka Scikit Mahout Lenskit Crab Pandas Gensim Reco4j Py2neo TinkerPop Neo4j Sesame Virtuoso. 50

51 Privacy and Security framework evaluation software phase 1 D Recommender SE Prototype Demonstration The development of the Recommender SE is a work in progress and the latest status is available at the OpenSource platform 22. Nevertheless a first demo showing how the context changes recommendations for similar users with similar check-ins, has been developed and presented in this section. For the purpose of the demo, Foursquare check-ins from two different users in Greece have been used, including the users profiles with full contextual information in order to match the specific contextual groups. Additionally, as long as the Recommender SE is not yet integrated with the authentication and authorization system, user ids are used to simulate a query coming from a specific authenticated user. Also all the users get recommendations for places in Cork, Ireland (long=51.896, lat=-8.46), a place never visited before. User1 wants to get place recommendations around Cork. In order to respond, the system will first find the most suitable place category for the user, in order to retrieve places belonging to this category. For the purpose of the demo, the method is demonstrated separately (Figure 9). Figure 11: User1 gets recommended categories The place category with the largest score is "College Engineering Building" and so the retrieved places will belong to direct or distant places of this category. Making a request both for User1 (Figure 12) and for User2 (Figure 13) without taking age-group context into account, the results are similar as both users have common activity. 22 OPENi opensource repository. 51

52 Privacy and Security framework evaluation software phase 1 D4.3 Figure 12: User1 issues a request for recommendations, asking that only his gender and age range are taken into consideration Figure 13: User2 issues a request for recommendations, asking that only his gender is taken into consideration But then, if it is selected for User2 to put age-group context in priority, the results are significantly different for User2 compared to User1 (Figure 14). 52

53 Privacy and Security framework evaluation software phase 1 D4.3 Figure 14: User2 issues the same request, but only age should influence the result 3.5 Recommender SE Conclusions and Outlook In conclusion, it was a great challenge to build a recommendation system that cannot have prior access to data, but also cannot store or cache data for related users or objects. It has been proven in this report that context coming from various objects, including the authenticated user, can be used to improve recommendations to users without allowing interrelation with their real identity or previous history of activities; the Recommender SE is an ideal, privacy aware, third party solution that can provide recommendations on the fly for different objects, for various services (i.e. either OPENi Cloudlet resources or CBS resources). The only prerequisite is having a common hierarchy of categories for every object family (e.g. places, products, applications), and feeding the Recommender SE with the proper contextual information as described in and based on the Context API as described in D3.1. It is understandable nevertheless that such a generic solution needs continuous testing in order to integrate different contextual information and provide better recommendations, but also to handle cases where such data will be missing from the request. For that reason the Recommender SE will be constantly enhanced with more objects, tested with real data, and will be improved in order to increase user experience and usability. In parallel, in close collaboration with WP4, the Recommender SE will work and experiment with different interfaces with the platform, like a SPARQL interface, to evaluate if such a solution violates privacy and if response time is acceptable. 53

54 Privacy and Security framework evaluation software phase 1 D4.3 4 Health SE Prototype 4.1 Health Service Enabler Features Health Service Enabler Goals This SE will facilitate the management of health and wellness data stored in the cloudlet in order to enable further services reliant on such data. In other words, the goal for this SE is to transform data stored in the cloudlet into a standard format, HL7 in this case, that any Health Organization with the necessary integration system would be able to manage and store Interdependency with other Work Packages The Health Service Enabler has dependencies with Work Package 4 and Work Package 5. In more detail: WP4 dependencies: The OPENi platform and cloudlets, particularly the measurement type objects from the Activity API. WP6 dependencies: The HealthLife Application within the MyLife Application may use this Service Enabler if necessary, in order to communicate with Health Organizations. 4.2 Health Service Enabler Prototype Components Specification You can find Health SE interactions in the figure below, as formerly shown in D3.1. Figure 15: Health SE interactions API Resource Path Results [OPEN_API_PATH]/health/hl7/{cloudletId} A list of activity objects from the given cloudlet. 54

55 Privacy and Security framework evaluation software phase 1 D4.3 [OPEN_API_PATH]/health/hl7/{cloudletId}/{objId} The activity object for the given identifier and cloudlet. 4.3 Health Service Enabler Prototype Implementation Tools and technologies The tools and technologies used for the Health Service Enabler implementation are: Java REST API (Restlet 2.2 Framework) HAPI API (Management of HL7 standard) We are using HL7 v2.51 for parsing our examples. At this version, messages come into a pipes and hats ( ^) text document. This is the selected format since it is the format used by the majority of health organizations Description and Workflow We use the HAPI API 23 in order to parse this pipes and hats message to a java object and vice versa. The message we are focusing on is the Result Message (ORU_R01). This message sends observations and results to a requesting system. All HL7 messages have one segment which identifies which kind of message is the current one (MSH segment) and due to our message type ORU_R01 (Observation Result), two other segments are taken into account: the OBR (Observation request) segment and the OBX (Observation) segment. This information is reported in the table below: ID Description Content Required MSH Message Header Contains the message type and trigger event Required PID Patient Identification Patient identification and demographics Optional OBR Observation Request Identifies what was originally asked and who ordered it Required OBX Observation results Contains the results of the observation Optional (one or more) The current format for the message is called pipes and hats ( ^) because these are the delimiters which split the sections into appropriate segments. Pipe ( ) is for splitting segments and groups into the segments and hats (^) are used for specifying fields into every field of a segment. The workflow for GET and POST operations are described in the figures below:

56 Privacy and Security framework evaluation software phase 1 D4.3 Figure 16: Sequence diagram for retrieving all objects from a cloudlet 56

57 Privacy and Security framework evaluation software phase 1 D4.3 Figure 17: Posting an ORU_R01 message to the cloudlet 4.4 Health SE Prototype Demonstration At this moment, the Health SE is capable of GET requests to the cloudlet and transforming the retrieved JSON documents into an ORU_R01 HL7 message (v2.51). We can retrieve one object from a cloudlet or all objects from a cloudlet and generate a basic ORU_R01. In any case, only the measurement objects are taken into account. Health SE is capable of doing a POST of an ORU_R01 hat and pipes to a cloudlet, transforming it internally into an OPENi measurement object. From the OPENi measurement object below { "_id": "0015dfc1a26e3d7d17bb22b3021a5adb-30", "_rev": " a4668f6f219d6b54b268ec74d", "result": "152", "metric": "cm } The Health SE obtains the following message: MSH ^~\& ORU^R01^ORU_R T OBR 1 Health Organization Id^LAB

58 Privacy and Security framework evaluation software phase 1 D4.3 OBX 1 NM ^HEIGHT^LN 152 cm In order to code the measurements, we are using the Logical Observation Identifiers Names and Code (LOINC 24ii ) dictionary. As this is an initial prototype, we are using just two measurements: weight (Body Weight Measure: LOINC code) and height (Body Height Measure: LOINC code). The Health SE has been implemented using Velti s cloudlet as storage and taking its object structure, specifically measurement objects defined at OPENi Health Demo Application - BMI in section into D4.2 document. Figure 18: BMI cloudlet