####  1\. Executive Summary

The involvement of end users in the experiments created on top of the project
federation of testbeds, platforms and living labs is one of the project main
challenges. And it serves several complementary objectives: it is the guaranty
of realistic experimentation conditions, ensures the accurate and useful
collection of feedback, provides better understanding the potential impacts of
technology and its perception at societal level, and offers opportunities of
harnessing co-creation creativity and future exploitations of the project
results.

The project consortium is committed to conducting responsible research and
innovation and, as such as realized at proposal stage, an ethic self-
assessment of potential risks and ethical impacts.

Two main points can be concerned in the FESTIVAL project:

 The involvements of end users in the experiments run on the test-beds.  The
potential collection and handling of personal data.

In addition, the project focused on the Internet of Things requires us to look
into the current privacy and ethical concerns identified on this technology
domain, and to liaise with the existing work carried out in the ecosystem.

This deliverable thus defines guidelines for end user involvement and handling
of privacy, data protection and ethics issues in experiments on the federated
testbeds. These guidelines will help experimenter from both the consortium and
external stakeholders to handle end user involvement accordingly.

It includes a review of the context and motivation for end user involvement,
and presents the current state of the experiments defined for the project in
terms of expected end users involvement. This list of experiments is directly
related with activities of WP3 and will evolve in the future linked with the
project activities and with the involvement of external experimenters.

Based on this analysis of the context and state of the art, a project strategy
has been defined to ensure responsible involvement of external participants.
It focuses on the following points:

  * **A technological and legal watch** activity to ensure that the project stays up to date with the state of the art in research experiment setup, involvement of external participants, protection of data and privacy and the accompanying legal framework. 

  

  * **Raising Awareness:** The creation of training materials for both experimenters and participants to present and explain in a rapid and accessible way some of the important challenges that can be raised by the participation to the project experiments. 

  

  * **Informed Consent Process:** The creation off the processes and document for ensuring the legal participation of the end users to the experiments: processes for the collection of informed consent, set up of a complaint procedure through a neutral third party, technical mechanisms ensuring the protection of experiments data (in joint work with WP2 and WP3). 

  

  * **Assessment of Personal Data Management:** The set-up of a basis for a “privacy impact assessment” process that can be used by the project experiments (and external experimenters) to assess the potential risks linked with their technology deployments in order to identify the ones that would require specific measures and oversight. 

  

  * **The organization of training sessions** and support for the experimenters to accompany the creation of the experiments and the actual involvement of the experimenters. 

  

The deliverable also provides a report on the first year of activity and
presentation of the initial results:

  * **The project Factsheets** on responsible user engagement aimed at raising the awareness on the issue. The Factsheet, a visual document of a single page, that can be widely distributed and that focus on a single issue, or a specific process set up by the project. They provide a general overview of the topic they address without entering into the details but rather as an invitation to consider a specific point. The Factsheets target usually the experimenters, but can be also very useful for experiment participants as they inform them of the project practices. 

  

  * **The informed consent, complaint and data withdrawal procedures.** Informed consent is an ethical requirement for most research and must be considered and implemented throughout the research lifecycle, from planning to publication. Gaining consent must include making provision for sharing data and take into account any immediate or future uses of data. 

  

  * **A first assessment of the Privacy and Security impacts of the project experiments.** The FESTIVAL PIA process consists of a fifteen question questionnaire, covering the entire information flow of an experiment, and describing how the data is handled in each phase and what associated security measures are provided. A first evaluation of the project experiment is provided. 

  

Finally, the deliverable also looks into the differences of perspective
between European and Japanese side, which can be considered as limited as
privacy protection and ethical research are a strong concern on both sides of
the project.

Over the first year, we have not only set up an operational environment for
the involvement of external participants to the project, but also increased
our knowledge on these issues and disseminated this knowledge in the
consortium and even outside (thanks to the first distributions of factsheets).

The project effort on this task will continue over the following period, to
pursue the effort already engaged and finalise the project infrastructure, but
also to gather feedbacks and improve our framework. As the project experiment
move into an operational phase and as the project opens up to external
experimenters, we foresee that this task will also progressively evolve into
an operation support task that will provide guidance to experimenters.

####  2\. Introduction

The involvement of end users in the experiments created on top of the project
federation of testbeds, platforms and living labs is one of the project main
challenges. And it serves several complementary objectives: it is the guaranty
of realistic experimentation conditions, ensures the accurate and useful
collection of feedback, provides better understanding the potential impacts of
technology and its perception at societal level, and offers opportunities of
harnessing co-creation creativity and future exploitations of the project
results.

This deliverable objective is to define guidelines for end user involvement
and handling of privacy, data protection and ethics issues in experiments on
the federated testbeds. These guidelines will help experimenter from both the
consortium and external stakeholders to handle end user involvement
accordingly.

The following plan has been followed:

  * **Section 3: Context and Motivation** reminds the project’s motivation for contacts and feedbacks from end users and its importance for the project. We present the context of experiments and trials in the project that will involve end users with a first description of the planned interactions with end user for each of the experiment envisioned by the project (experiment presented in more details in Deliverable 3.1). And we also present the main ethical issues risen by the project activities and an overview of the ethical and privacy discussion in the Internet of Things domain. 

  

  * **Section 4: Strategy for Responsible User Involvement** presents the project overall strategy for responsible user involvement. It looks into the main challenges identified, based on the context and motivation included in section 3, and provides a general strategy and list of planned activities. To provide an operational vision of the project effort, a summary of the actions preformed in the first year and a plan for future activities are also provided. 

  

  * **Section 5: Raising Awareness: Factsheets,** in this section the project activity toward raising the end users and experimenters awareness toward ethical issues and responsible research and innovation are presented. Thus the concept of factsheets proposed by the project and the current and foreseen factsheets are shown. 

  

  * **Section 6: Informed Consent Process,** the process proposed for the project for the informed consent procedure and the tools set up are included. The general procedure principles, and the current set of document for informing the user about the project and experiments, gathering their consent and providing a process for complaints and withdrawal of their data are included. Additionally, future plans for an electronic version of the informed consent process to be included in the project portal for Experimentation as a Service is presented. 

  

  * **Section 7: Assessment of Personal Data Management,** the project activities to assess the risks associated with the management of data in the project testbeds and experiments and the associated measures to safeguard privacy and data confidentiality are shown. This includes a general overview of the principles of the project and the Privacy Impact Assessment process set up by the project. It also provides for each of the experiment currently envisioned by the project, a first version of the Privacy Impact Assessment, identifying the way data is collected, stored, used, shared, destroyed and managed. This section also provides updates on the current status of relation with the Data Protection Authorities of each of the project experiment location. 

  

  * **Section 8: Europe – Japan Differences** presents the main differences identified in this task between European and Japanese approaches to involve of end users in experiments and safeguard of privacy. 

  

  * Finally, a conclusion is provided (Section 9) and additional documents and references are presented in the Annex of this deliverable. 

  

This deliverable provides a first complete overview of the project approach,
activities and results regarding responsible end user involvement in the
project experiments. As the project develops with more detailed experiment
definition (and actual implementation), and progressively opens to external
experimenters, the task 4.1 will concentrate on making sure that the
guidelines defines in this deliverable are applied and kept up to date.

####  3\. Context and motivation

_In this section we remind the motivation behind contacts and feedbacks with
end users and its importance for the project. We present the context of
experiments and trial in the project that will involve end users. And we also
present the main ethical issues risen by the project activities._

#####  3.1. Motivations for end user involvement

The involvement of end users in the experiments created on top of the project
federation of testbeds, platforms and living labs is one of the project main
challenges as emphasised in the project description of work:

_“**Challenge 5 - User involvement, privacy:** The development of an open
federation of testbeds enabling “Experimentations as a Service” can only make
sense and have a real impact by the number and quality of the experimentations
that are run on the testbed. The infrastructure federated in the project will
enable both small and large scale trials over various application domains. As
the technologies of the Future Internet move ever closer to the market, in an
ever shorter innovation cycle, the need to validate the experimentation in
“real life” trials with end user is a strong requirement of the project. Given
the number and complexity of the privacy and ethics concerns in the deployment
of future connected applications (user informed consent, continuity and
availability of services, contextualization of risk, profiling, ownership,
management and captivity of data, applicable legislation and enforcement…), a
strong focus has to be put on the protection of the end users participating in
the trials.” _

The involvement of end users in the project’s experiments serves several
complementary objectives:

  * First, user involvement is **the guaranty of realistic experimentation conditions** . Indeed, the experiments that can be built on top of the project federation are not solely technical application but rather socio-technical systems. The potential interactions between the technological system set up and the human users and bystanders can have strong impacts on the viability of the proposed experiments. Therefore the presence and involvement of human participants in the experiment is a requirement to validate the proposed applications in conditions as close as possible to those of a final deployment of the technology. 

  

  * The involvement of end users, especially when they are external to the project, is also a guaranty of **accurate and useful feedback collection** . They can provide an alternate view on the experiment going on and complement the technical evaluation made of the system from a different perspective. It is also a key element to validate some of the non-functional requirements of the applications (system usability, training time, acceptability…) 

  

  * The engagement of users can also help research on **better understanding the potential impacts of technology and its perception at societal level** . The actual involvement of end users 

  

in experiments is superior to a simple presentation of potential applications
scenario in terms of collection of impressions, reactions, beliefs, and
opinions on future technologies and innovations. The project evaluation
activities (especially task 4.3) will thus strongly benefit from end user
involvement and require adequate methodologies to involve end users and gather
feedbacks.

  * Some of the experiments proposed by the project as well as those that will be proposed by external experimenters have **direct exploitation opportunities** . These exploitation opportunities, however, require more than test in the Lab to validate their potential commercial viability. Thus, the involvement of external users in experiments can also help with the project exploitation strategy (developed in WP5) to identify the most promising exploitations. 

  

  * Finally, the involvement of end users also opens **the opportunity for co-creation mechanisms** . The engagement of end users can provide external ideas that directly influence the set-up of the experiment by enlarging the number and broadening the scope of the inputs on which the future experimentations, applications and services are built. 

  

As the experiments proposed by the project cover many technologies,
application domains and require the involvement of various stakeholders, the
term “end users” can cover various categories of stakeholders in FESTIVAL. And
it is important to grasp this diversity of stakeholders that are to be
involved in the experiments. This involves:

  * External decision makers that would (in a real deployment set up) be the customer of the potential applications covered by the experiment. 

  

  * External technical stakeholders that would be involved in (or impacted by) the technology deployment (system operators, IT infrastructure). 

  

  * Actual end users of the applications proposed by the experiments. 

  

  * Citizens at large that could be impacted by the deployment of the application. 

  

#####  3.2. FESTIVAL Field Trials and experiments involving end users

The following section presents the current state of the experiments defined
for the project in terms of expected end users involvement. This list of
experiments is directly related with activities of WP3 and will evolve in the
future linked with the project activities and with the involvement of external
experimenters.

######  3.2.1. Smart Energy

3.2.1.1. PTL - Energy Management sensiNact  
  
<table>  
<tr>  
<th>

**Experiment Name:**

</th>  
<th>

Autonomous Smart energy application and the real user perception

</th> </tr>  
<tr>  
<td>

**Responsible Partner:**

</td>  
<td>

CEA (PTL)

</td> </tr>  
<tr>  
<td>

**Topic:**

</td>  
<td>

Smart building Smart energy

</td> </tr>  
<tr>  
<td>

**Start date:**

</td>  
<td>

M20

</td> </tr>  
<tr>  
<td>

**End date:**

</td>  
<td>

M25

</td> </tr>  
<tr>  
<td>

**Min number of end users:**

</td>  
<td>

1 user

</td> </tr>  
<tr>  
<td>

**Max number of end users:**

</td>  
<td>

10 users

</td> </tr>  
<tr>  
<td>

**Openness of the experiment/Selection of end users:**

</td> </tr>  
<tr>  
<td>

The users chosen to interact with the system should be able to express their
impression about a given software interface, meaning, that they should have a
minimum vocabulary in order to describe the aspects of the system that are not
pleasing from the user point of view.

</td> </tr>  
<tr>  
<td>

**Nature of interactions with end users:**

</td> </tr>  
<tr>  
<td>

In order to save energy, the system might take actions that the user is not
necessarily aware or may not understand completely ( _e.g_ system may close
the shutter when the user asks to decrease the temperature of a room).

</td> </tr>  
<tr>  
<td>

**Expected outcome**

</td> </tr>  
<tr>  
<td>

This experiment will point how comfortable (or not) the user would be with
autonomous systems taking decisions that he/she is not completely aware of.
This would allow us to know how intrusive the smart energy application can be.

</td> </tr>  
<tr>  
<td>

**Description of the Experiment for end users:**

</td> </tr>  
<tr>  
<td>



</td>  
<td>

The user should be driven to perform actions in the environment (equipped with
a smart energy application) that would produce indirect actions.

</td> </tr>  
<tr>  
<td>



</td>  
<td>

Autonomous indirect actions should not be explained by the researcher
responsible by the experiment.

</td> </tr> </table>

3.2.1.2. ATR DC – xEMS control  
  
<table>  
<tr>  
<th>

**Experiment Name:**

</th>  
<th>

xEMS (Energy Management System)

</th> </tr>  
<tr>  
<td>

**Responsible Partner:**

</td>  
<td>

OSK

</td> </tr>  
<tr>  
<td>

**Topic:**

</td>  
<td>

Smart Energy (Data Center)

</td> </tr>  
<tr>  
<td>

**Start date:**

</td>  
<td>

M20

</td> </tr>  
<tr>  
<td>

**End date:**

</td>  
<td>

M36

</td> </tr>  
<tr>  
<td>

**Min number of end users:**

</td>  
<td>

4 as the data center users

</td> </tr>  
<tr>  
<td>

**Max number of end users:**

</td>  
<td>

100 as the data center users

</td> </tr>  
<tr>  
<td>

**Openness of the experiment/Selection of end users:**

</td> </tr>  
<tr>  
<td>

In the first stage, first 20 months, the algorithm for the energy control will
be established and the AIDCIM (AI-Data Center Infrastructure Management
System) will be built for the ATR Data Center. After 20 months, the AI-DCIM
will be extended to other data centers.

</td> </tr>  
<tr>  
<td>

**Nature of interactions with end users:**

</td> </tr>  
<tr>  
<td>

The end users demonstrate the energy management of the data center from
outside via network, including ASP.

</td> </tr>  
<tr>  
<td>

**Description of the Experiment for end users:**

</td> </tr>  
<tr>  
<td>

The end user demonstrates the optimum energy management for the data centers
by using the AIDCIM software provided as an OSS. Also by using secure
communication protocols IEEE1888 developed and standardized, the management
will be achieved from the outside of the data centers.

</td> </tr> </table>

3.2.1.3. Knowledge Capital – SNS-like EMS  
  
<table>  
<tr>  
<th>

**Experiment Name:**

</th>  
<th>

xEMS (Energy Management System)

</th> </tr>  
<tr>  
<td>

**Responsible Partner:**

</td>  
<td>

OSK

</td> </tr>  
<tr>  
<td>

**Topic:**

</td>  
<td>

Smart Energy

</td> </tr>  
<tr>  
<td>

**Start date:**

</td>  
<td>

M20

</td> </tr>  
<tr>  
<td>

**End date:**

</td>  
<td>

M36

</td> </tr>  
<tr>  
<td>

**Min number of end users:**

</td>  
<td>

1

</td> </tr>  
<tr>  
<td>

**Max number of end users:**

</td>  
<td>

1000

</td> </tr>  
<tr>  
<td>

**Openness of the experiment/Selection of end users:**

</td> </tr>  
<tr>  
<td>

End users that have fundamental knowledge on using smartphone are selected.
For floor pressure sensor, the pedestrian that walk on the sensor are
(automatically) selected as test users.

</td> </tr>  
<tr>  
<td>

**Nature of interactions with end users:**

</td> </tr>  
<tr>  
<td>

End users can input their feelings and requests by using smartphones to the
system. The system would change the configuration based on users’ inputs.
Also, end users would input their movement through floor pressure sensors.

</td> </tr>  
<tr>  
<td>

**Description of the Experiment for end users:**

</td> </tr>  
<tr>  
<td>

The energy management systems would gather end users’ inputs and control
various actuators based on the users’ inputs

</td> </tr> </table>

######  3.2.2. Smart Building

3.2.2.1. PTL - People counting using a single / multiple camera(s)  
  
<table>  
<tr>  
<th>

**Experiment Name:**

</th>  
<th>

People counting using a Single/Multiple camera(s)

</th> </tr>  
<tr>  
<td>

**Responsible Partner:**

</td>  
<td>

CEA (PTL)

</td> </tr>  
<tr>  
<td>

**Topic:**

</td>  
<td>

Smart Building and Smart Shopping

</td> </tr>  
<tr>  
<td>

**Start date:**

</td>  
<td>

M24

</td> </tr>  
<tr>  
<td>

**End date:**

</td>  
<td>

M36

</td> </tr>  
<tr>  
<td>

**Min number of end users:**

</td>  
<td>

10

</td> </tr>  
<tr>  
<td>

**Max number of end users:**

</td>  
<td>

100

</td> </tr>  
<tr>  
<td>

**Openness of the experiment/Selection of end users:**

</td> </tr>  
<tr>  
<td>

The experiment will be opened the participants. Generated data will be of
restricted access. The end users will be involved when they go in the filmed
area.

</td> </tr>  
<tr>  
<td>

**Nature of interactions with end users:**

</td> </tr>  
<tr>  
<td>

No specific interaction is needed from the end users, thus the experiment is
transparent for end users. They will only be informed that an experiment is
being conducted.

</td> </tr>  
<tr>  
<td>

**Description of the Experiment for end users:**

</td> </tr>  
<tr>  
<td>

A smart imaging system is currently working. This system sends an anonymized
description of the scene to a centralized computing system. For instance,
those image features can help to provide statistics about the number of
persons that are inside the room. The entire system enables the computation of
relevant information regarding people trajectories keeping a high level of
privacy protection. The two main goals of this experiment are first to
evaluate the accuracy of such system and secondly what are the potential
usages of those statistics for smart building/smart advertising applications.

</td> </tr> </table>

3.2.2.2. PTL - Using actuator based on interpreting the scene using a smart
camera  
  
<table>  
<tr>  
<th>

**Experiment Name:**

</th>  
<th>

Using actuator based on interpreting the scene using a smart camera

</th> </tr>  
<tr>  
<td>

**Responsible Partner:**

</td>  
<td>

CEA (PTL)

</td> </tr>  
<tr>  
<td>

**Topic:**

</td>  
<td>

Smart Building and Smart Shopping

</td> </tr>  
<tr>  
<td>

**Start date:**

</td>  
<td>

M24

</td> </tr>  
<tr>  
<td>

**End date:**

</td>  
<td>

M36

</td> </tr>  
<tr>  
<td>

**Min number of end users:**

</td>  
<td>

3

</td> </tr>  
<tr>  
<td>

**Max number of end users:**

</td>  
<td>

10

</td> </tr>  
<tr>  
<td>

**Openness of the experiment/Selection of end users:**

</td> </tr>  
<tr>  
<td>

The experiment will be opened the participants. Generated data will be of
restricted access. The end users will be involved when they go in the filmed
area.

</td> </tr>  
<tr>  
<td>

**Nature of interactions with end users:**

</td> </tr>  
<tr>  
<td>

The end user will interact with their body and gesture when they will be
filmed. The participants will act on various actuators (not defined yet) using
their own behaviours and gestures

</td> </tr>  
<tr>  
<td>

**Description of the Experiment for end users:**

</td> </tr>  
<tr>  
<td>

A smart imaging system is currently collecting information. The system
processes and saves only anonymized image features without storing any
information about personal data (i.e. images or image features possibly linked
to an identity). A “computer interpretation” of the scene provides signals to
control media such as sounds, videos… Multimodal interactions are also
investigated to act on the mood of the room (e.g. by modifying air ambient
temperature, humidity level, synthetic lights).

</td> </tr> </table>

3.2.2.3. ATR DC – Cold storage geo-replication  
  
<table>  
<tr>  
<th>

**Experiment Name:**

</th>  
<th>

Geo-replication

</th> </tr>  
<tr>  
<td>

**Responsible Partner:**

</td>  
<td>

OSK

</td> </tr>  
<tr>  
<td>

**Topic:**

</td>  
<td>

Smart Data Center

</td> </tr>  
<tr>  
<td>

**Start date:**

</td>  
<td>

M20

</td> </tr>  
<tr>  
<td>

**End date:**

</td>  
<td>

M36

</td> </tr>  
<tr>  
<td>

**Min number of end users:**

</td>  
<td>

4

</td> </tr>  
<tr>  
<td>

**Max number of end users:**

</td>  
<td>

100

</td> </tr>  
<tr>  
<td>

**Openness of the experiment/Selection of end users:**

</td> </tr>  
<tr>  
<td>

In the first stage before month 20, the algorithm for the geo-replication for
IoT data will be established. After M20, geo-replication will be established
between two locations.

</td> </tr>  
<tr>  
<td>

**Nature of interactions with end users:**

</td> </tr>  
<tr>  
<td>

The end users demonstrate the geo-replication for the IoT data between at
least two locations.

</td> </tr>  
<tr>  
<td>

**Description of the Experiment for end users:**

</td> </tr>  
<tr>  
<td>

This experiment demonstrates the optimum geo-replication for IoT data between
at least two locations.

</td> </tr> </table>

3.2.2.4. iHouse – Smart House  
  
<table>  
<tr>  
<th>

**Experiment Name:**

</th>  
<th>

Smart House

</th> </tr>  
<tr>  
<td>

**Responsible Partner:**

</td>  
<td>

OSK

</td> </tr>  
<tr>  
<td>

**Topic:**

</td>  
<td>

Smart House

</td> </tr>  
<tr>  
<td>

**Start date:**

</td>  
<td>

M20

</td> </tr>  
<tr>  
<td>

**End date:**

</td>  
<td>

M36

</td> </tr>  
<tr>  
<td>

**Min number of end users:**

</td>  
<td>

1

</td> </tr>  
<tr>  
<td>

**Max number of end users:**

</td>  
<td>

10

</td> </tr>  
<tr>  
<td>

**Openness of the experiment/Selection of end users:**

</td> </tr>  
<tr>  
<td>

The end users who have basic knowledge on controlling smart home appliances in
the smart house are selected, since the experiment monitors and gathers
various sensing data from sensors in iHouse for energy efficient control of
appliances and actuators in smart house.

</td> </tr>  
<tr>  
<td>

**Nature of interactions with end users:**

</td> </tr>  
<tr>  
<td>

The end users emulate the daily life in the smart house with smart home
appliances. For example, they may monitor the power consumption of the house
and each appliance and also control them.

</td> </tr>  
<tr>  
<td>

**Description of the Experiment for end users:**

</td> </tr>  
<tr>  
<td>

Various sensing data are gathered with end users’ emulated living in the smart
house. Real-time monitoring and control home appliances would be conducted
based on end users’ inputs on the appliances.

</td> </tr> </table>

3.2.2.5. Smart Station at Maya  
  
<table>  
<tr>  
<th>

**Experiment Name:**

</th>  
<th>

Smart Station at Maya

</th> </tr>  
<tr>  
<td>

**Responsible Partner:**

</td>  
<td>

JCOMM

</td> </tr>  
<tr>  
<td>

**Topic:**

</td>  
<td>

Smart Building

</td> </tr>  
<tr>  
<td>

**Start date:**

</td>  
<td>

M18

</td> </tr>  
<tr>  
<td>

**End date:**

</td>  
<td>

M36

</td> </tr>  
<tr>  
<td>

**Min number of end users:**

</td>  
<td>

85 (assuming 1% of the station ride personnel)

</td> </tr>  
<tr>  
<td>

**Max number of end users:**

</td>  
<td>

850 (assuming 10% of the station ride personnel)

</td> </tr>  
<tr>  
<td>

**Openness of the experiment/Selection of end users:**

</td> </tr>  
<tr>  
<td>

This experiment will be held at the Maya Station in Kobe city. Maya station is
the new station of the JR Kobe Line which will be opened in March 2016. All
users at the Maya Station can get useful information about this station to
watch digital signage and web site _._

</td> </tr>  
<tr>  
<td>

**Nature of interactions with end users:**

</td> </tr>  
<tr>  
<td>

  1. An agreement with station users is not required because personal information is not treated. 

  

  2. Useful information about Maya Station will be provided. By watching digital signage in front of the train gates, users can get information about temperature, weather, solar power generation, location of bus access information and so on. Libelium sensors and Wi-Fi packet sensors to gather these data are used. The acquired information is expected to use Jose testbed, etc. 

  

  3. Anonymous user feedback by questionnaire after the experiment. 

  

  

</td> </tr>  
<tr>  
<td>

**Description of the Experiment for end users:**

</td> </tr>  
<tr>  
<td>

This experiment will be held at the Maya Station in Kobe city. Maya station is
the new station of the JR Kobe Line which will be opened in March 2016. All
users at the Maya Station can get useful information about Maya Station by
watching digital signage and web site _._

</td> </tr> </table>

######  3.2.3. Smart Shopping

3.2.3.1. Knowledge Capital – Smart Shopping system and recommendation analysis  
  
<table>  
<tr>  
<th>

**Experiment Name:**

</th>  
<th>

Smart Exhibition at the LAB

</th> </tr>  
<tr>  
<td>

**Responsible Partner:**

</td>  
<td>

OSK

</td> </tr>  
<tr>  
<td>

**Topic:**

</td>  
<td>

Smart Shopping

</td> </tr>  
<tr>  
<td>

**Start date:**

</td>  
<td>

M14

</td> </tr>  
<tr>  
<td>

**End date:**

</td>  
<td>

M14

</td> </tr>  
<tr>  
<td>

**Min number of end users:**

</td>  
<td>

350

</td> </tr>  
<tr>  
<td>

**Max number of end users:**

</td>  
<td>

1400

</td> </tr>  
<tr>  
<td>

**Openness of the experiment/Selection of end users:**

</td> </tr>  
<tr>  
<td>

This experiment will be held at the Lab. in Grand front Osaka. Any visitorscan
participate in this experiment as long as they accept the agreement on
personal data usage. We assume that the number of the exhibitions is around 20
in the Lab. and the number of simultaneous users participating this experiment
is 20 at most.

</td> </tr>  
<tr>  
<td>

**Nature of interactions with end users:**

</td> </tr>  
<tr>  
<td>

  1. We make an agreement on personal data usage with end users before their participation. 

  

  2. We provide users a Beacon device during the experiment, which emits Beacon signals for detecting user location and staying duration. Then the system recommends other exhibitions and controls the user environment according to user behaviours. 

  

  3. User feedback by questionnaire after the participation. 

  

  

This experiment will be held at the LAB in Grand front Osaka during November,
2015. The feature of this experiment is to recommend exhibitions and control
the user environment by actuators (candidates are playing music, changing the
light colour, and changing the smell of the air ) according to user
behaviours, so that the staying time of the users in the Lab. can be
maximized.

</td> </tr>  
<tr>  
<td>

**Description of the Experiment for end users:**

</td> </tr>  
<tr>  
<td>

In this experiment, we ask people to walk in the Lab. and see exhibitions with
Beacon emitters. Our system analyses users’ behaviours in the Lab., whowill
spending more or less time at differentexhibitions, and then this system will
analyse all user behaviours and generate behaviour model. Then, this system
recommends users another suitable exhibitions you seems to stay longer by
estimating how long time you stayed at the previous exhibitions. The idea of
this experiment is similar to the recommendation system used by amazon.com,
but it is extended to be applied to real world users. Moreover, this system
also controls users’ environment by using aroma refusers according to their
attributes, gender, age, and other profiles, so that the users could stay
longer by personalizing the environment.

</td> </tr> </table>

3.2.3.2. Santander – Connected Shops  
  
<table>  
<tr>  
<th>

**Experiment Name:**

</th>  
<th>

Connected Shop in Santander (SmartSantander)

</th> </tr>  
<tr>  
<td>

**Responsible Partner:**

</td>  
<td>

SAN

</td> </tr>  
<tr>  
<td>

**Topic:**

</td>  
<td>

Smart Shopping

</td> </tr>  
<tr>  
<td>

**Start date:**

</td>  
<td>

M07

</td> </tr>  
<tr>  
<td>

**End date:**

</td>  
<td>

M34

</td> </tr>  
<tr>  
<td>

**Min number of end users:**

</td>  
<td>

At the moment is planned to have at least five external experimenters
throughout the project lifespan that will use the data generated.

</td> </tr>  
<tr>  
<td>

**Max number of end users:**

</td>  
<td>

There is no maximum number of experimenters to use the available data. The
number of citizens involved in the experiment is about of one hundred citizens
per day during the data gathering.

</td> </tr>  
<tr>  
<td>

**Openness of the experiment/Selection of end users:**

</td> </tr>  
<tr>  
<td>

The experimenters who want to make use the available positioning and
environmental data will need to request the specific permissions to the UC and
Santander Municipality. Additionally, gathered data will be made available
under the FESTIVAL EaaS. Therefore, the data access will follow agreed access
policies.

</td> </tr>  
<tr>  
<td>

**Nature of interactions with end users:**

</td> </tr>  
<tr>  
<td>

Experimenters will access positioning data to perform and test their own
positioning and customer behaviour algorithms.

Citizens will not interact directly with the experiment, but the anonymized
data sent automatically from their smartphones will be collected to get the
different measurements.

</td> </tr>  
<tr>  
<td>

**Description of the Experiment for end users:**

</td> </tr>  
<tr>  
<td>

The experiment aims at providing a trusted source of SNR data from the two
major technologies used in the smartphones, tablets or laptops: Bluetooth and
WiFi. Data will also be sent along with the metadata regarding the area where
the devices are installed, the environmental parameters, and the exact
location of the devices in the market. These data will be provided the
possibility of testing their own algorithms to verify and improve the
behaviour.

Furthermore, several algorithms tested on the gathered data will provide
useful parameters about the number of users in the market area as well as
their location. These data will be made available to the shop owners to better
understand the citizen behaviour.

</td> </tr> </table>

3.2.3.3. Santander - Advertised premium discounts  
  
<table>  
<tr>  
<th>

**Experiment Name:**

</th>  
<th>

Advertised premium discounts in Santander (SmartSantander)

</th> </tr>  
<tr>  
<td>

**Responsible Partner:**

</td>  
<td>

SAN

</td> </tr>  
<tr>  
<td>

**Topic:**

</td>  
<td>

Smart Shopping

</td> </tr>  
<tr>  
<td>

**Start date:**

</td>  
<td>

M07

</td> </tr>  
<tr>  
<td>

**End date:**

</td>  
<td>

M34

</td> </tr>  
<tr>  
<td>

**Min number of end users:**

</td>  
<td>

At least one hundred citizens will be end users and receive or use discounts
during the project lifespan. Additionally, ten shop owners will access the
platform to provide specific discount data.

</td> </tr>  
<tr>  
<td>

**Max number of end users:**

</td>  
<td>

There is no limit in the number of end users.

</td> </tr>  
<tr>  
<td>

**Openness of the experiment/Selection of end users:**

</td> </tr>  
<tr>  
<td>

There will be no restriction to become part of the experimentation and access
to the specific discounts based on the location and other parameters. The only
requirement will be downloading the application from the marketplace of iOS
and Android to access the offers and activating GPS, WIFI and/or Bluetooth at
the smartphone.

</td> </tr>  
<tr>  
<td>

**Nature of interactions with end users:**

</td> </tr>  
<tr>  
<td>

Citizens will use the smartphone application to get different parameters from
the shopping area, such as temperature, humidity, position, etc. Citizens will
get different discounts based on their location as well as other parameters.
These discounts will be generated by the shop owners in order to engage
citizens.

Additionally, citizens will be able to provide their feedback regarding the
offers generated as well as to the different parameters in the shop
(temperature, humidity…).

</td> </tr>  
<tr>  
<td>

**Description of the Experiment for end users:**

</td> </tr>  
<tr>  
<td>

This experiment aims at shortening the relation between the shop and customers
by giving different tools to communicate both. These tools are characterized
at following:

 Customers will receive premium offers depending on several parameters,
including their location.Customers will be able to access to environmental
data in the shops, including parameters such as temperature or
humidity.Customers will have access to communication tools in order to send
feedback about their feelings in the shop (e.g. the temperature is low) and
the offers received.

</td> </tr> </table>

######  3.2.4. Multi-domain

3.2.4.1. JOSE/JOSE (Japan-wide Orchestrated Smart/Sensor Environment)  
  
<table>  
<tr>  
<th>

**Experiment Name:**

</th>  
<th>

Constructing and providing IoT testbed on JOSE as IaaS testbed

</th> </tr>  
<tr>  
<td>

**Responsible Partner:**

</td>  
<td>

ACUTUS

</td> </tr>  
<tr>  
<td>

**Topic:**

</td>  
<td>

Federation Experiment

</td> </tr>  
<tr>  
<td>

**Start date:**

</td>  
<td>

M7

</td> </tr>  
<tr>  
<td>

**End date:**

</td>  
<td>

M36

</td> </tr>  
<tr>  
<td>

**Min number of end users:**

</td>  
<td>

No end user involved in the experiment itself

</td> </tr>  
<tr>  
<td>

**Max number of end users:**

</td>  
<td>

No end user involved in the experiment itself

</td> </tr>  
<tr>  
<td>

**Openness of the experiment/Selection of end users:**

</td> </tr>  
<tr>  
<td>

This experiment is not open for any end users but open for other experimenters
and federation experiment in FESTIVAL project.

</td> </tr>  
<tr>  
<td>

**Nature of interactions with end users:**

</td> </tr>  
<tr>  
<td>

Experimenter users on this experiment will interact with end users of each
experiment.

</td> </tr>  
<tr>  
<td>

**Description of the Experiment for end users:**

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr> </table>

3.2.4.2. Engineering FIWARE-Lab  
  
<table>  
<tr>  
<th>

**Experiment Name:**

</th>  
<th>

FIWARE GE experiment over a federated domain

</th> </tr>  
<tr>  
<td>

**Responsible Partner:**

</td>  
<td>

ENG

</td> </tr>  
<tr>  
<td>

**Topic:**

</td>  
<td>

Federation Experiment

</td> </tr>  
<tr>  
<td>

**Start date:**

</td>  
<td>

M12

</td> </tr>  
<tr>  
<td>

**End date:**

</td>  
<td>

M14

</td> </tr>  
<tr>  
<td>

**Min number of end users:**

</td>  
<td>

The number of user is related to the specific experiment that will use the
FIWARE-lab.

</td> </tr>  
<tr>  
<td>

**Max number of end users:**

</td>  
<td>

The number of user is related to the specific experiment that will use the
FIWARE-lab

</td> </tr>  
<tr>  
<td>

**Openness of the experiment/Selection of end users:**

</td> </tr>  
<tr>  
<td>

In the first phase of the project the access to the FIWARE-lab resources will
be restricted to a set of users.

</td> </tr>  
<tr>  
<td>

**Nature of interactions with end users:**

</td> </tr>  
<tr>  
<td>

The users will be able to use the FIWARE-lab resources (e.g. VM for GE) using
both the OpenStack interface and the FESTIVAL experiment portal.

</td> </tr>  
<tr>  
<td>

**Description of the Experiment for end users:**

</td> </tr>  
<tr>  
<td>

The FIWARE testbed will support different types of experiments providing to
the experimenter IT resources (e.g. virtual machines or virtual networks) in
order to instantiate FIWARE Generic Enabler.

</td> </tr> </table>

The GE can be used directly in the experiment offering their different
functionalities (e.g. data processing, networking security etc.)

3.2.4.3. IoT based experiment over a federated domain  
  
<table>  
<tr>  
<th>

**Experiment Name:**

</th>  
<th>

IoT-based experiment over a federated domain

</th> </tr>  
<tr>  
<td>

**Responsible Partner:**

</td>  
<td>

UC

</td> </tr>  
<tr>  
<td>

**Topic:**

</td>  
<td>

Federation Experiment

</td> </tr>  
<tr>  
<td>

**Start date:**

</td>  
<td>

M12

</td> </tr>  
<tr>  
<td>

**End date:**

</td>  
<td>

M34

</td> </tr>  
<tr>  
<td>

**Min number of end users:**

</td>  
<td>

At the moment is planned to have at least five external experimenters will be
able to access to the federated IoT-based experiment.

</td> </tr>  
<tr>  
<td>

**Max number of end users:**

</td>  
<td>

At the time being, no maximum users are considered. However, this will depend
on the number of free resources available.

</td> </tr>  
<tr>  
<td>

**Openness of the experiment/Selection of end users:**

</td> </tr>  
<tr>  
<td>

The final authorisation for accessing the resources will depend on the
responsible of the involved testbeds. However, the experimentation will be
performed on top of the FESTIVAL EaaS. Therefore, the data access will follow
agreed access policies.

</td> </tr>  
<tr>  
<td>

**Nature of interactions with end users:**

</td> </tr>  
<tr>  
<td>

Experimenters will interact with the EaaS platform to reserve available
resources and to link them automatically.

</td> </tr>  
<tr>  
<td>

**Description of the Experiment for end users:**

</td> </tr>  
<tr>  
<td>

The idea of this experiment is to provide the possibility to automatically
create links between available resources within FESTIVAL. The experimenter
will be able to reserve virtual machines and receive the data from the sensors
in these machines. This will provide to the experimenters an easy way to
access the sensor data in the reserved virtual machines, in order to perform a
fast deployment of applications and perform experiments.

The main benefit for experimenters will be the possibility of testing their
own applications and experiments with real time data without having an
available physical infrastructure, as it will be provided by the FESTIVAL
federation EaaS.

</td> </tr> </table>

3.2.4.4. Messaging/Storage/Visualization platform federation example  
  
<table>  
<tr>  
<th>

**Experiment Name:**

</th>  
<th>

Messaging/Storage/Visualization platform federation use case

</th> </tr>  
<tr>  
<td>

**Responsible Partner:**

</td>  
<td>

KSU

</td> </tr>  
<tr>  
<td>

**Topic:**

</td>  
<td>

Smart Building

</td> </tr>  
<tr>  
<td>

**Start date:**

</td>  
<td>

M12

</td> </tr>  
<tr>  
<td>

**End date:**

</td>  
<td>

M36

</td> </tr>  
<tr>  
<td>

**Min number of end users:**

</td>  
<td>

No end user is directly involved in the experiment. In the current plan, end
users are involved via the experiment of Smart Station at Maya.

</td> </tr>  
<tr>  
<td>

**Max number of end users:**

</td>  
<td>

No end user is directly involved in the experiment. In the current plan, end
users are involved via the experiment of Smart Station at Maya.

</td> </tr>  
<tr>  
<td>

**Openness of the experiment/Selection of end users:**

</td> </tr>  
<tr>  
<td>

This experiment is not open for any end users but open for other experimenters
and federation experiment in FESTIVAL project.

</td> </tr>  
<tr>  
<td>

**Nature of interactions with end users:**

</td> </tr>  
<tr>  
<td>

Experimenters on this federation experiment will interact with end users of
each experiment.

</td> </tr>  
<tr>  
<td>

**Description of the Experiment for end users:**

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr> </table>

#####  3.3. FESTIVAL potential Ethical issues

The project consortium is committed to conducting responsible research and
innovation and, as such as realized at proposal stage, an ethic self-
assessment of potential risks and ethical impacts.

Two main points can be concerned in the FESTIVAL project:

 The involvements of end users in the experiments run on the test-beds.  The
potential collection and handling of personal data.

In addition, the project focused on the Internet of Things requires us to look
into the current privacy and ethical concerns identified on this technology
domain, and to liaise with the existing work carried out in the ecosystem.

######  3.3.1. Involvements of end users in the experiments run on the test-
beds

The involvement of end users in research experiments requires specific
methodologies to ensure the safety of the participants (and of the experiment
as a whole) and the correct understanding and acceptance of the participants
to the experiment.

Regarding the safety of experiments, the risk can be considered very limited
or inexistent in the case of the FESTIVAL experiments as the planned
experiment concerns providing additional services, mostly in an informative
way, rather than disrupting existing process or handling devices that could
harm humans. Additionally, only the most mature experiment, already tested in
the lab, will be deployed to populated areas.

The understanding of the experiments using new technologies that are not
familiar to the general public and proposing applications in domains and scope
that could prove disrupting is however a significant challenge. The project is
addressing this challenge by Task 4.1 and this deliverable is here to document
these activities. As such the objectives set up by the project regarding this
challenge are:

  * Engaging with end user only on an informed way: making sure they are aware of the presence of experiments and that relevant documentation, in understandable format (language and avoidance of technical jargon) is available. 

  

  * Gathering end user consent as a prerequisite for interaction and any data collection 

  

  * Providing a complaint procedure with a neutral third party 

  

  * Ensuring that end-users are free to refuse the experiment at any moment, including after it is started, without any prejudice or disadvantage. 

  

######  3.3.2. The potential collection and handling of personal data

Although not a key part of the project, it is possible that some experiment,
for specific reasons, may need to collect data that is directly or that could
become through secondary use (profiling) personal data, even if no such
secondary use is planned within the project. This is true of most ICT related
project involving in one way or another end users in experiments and not a
specific focus of FESTIVAL, nevertheless it should be taken into account.

The data collected will be treated as confidential and security processes and
techniques will be applied to ensure their confidentiality. Overall the
following general principles will be used regarding any data collection by the
project experiments:

  * Transparency of usage of the data: User – data subject in the European Union (EU) parlance - shall give explicit consent of usage of data. 

  

  * Collected Data shall be adequate, relevant and not excessive: The data shall be collected on “need to know” principle. This principle is also known as “Data Minimization”, which also helps to setup the user contract, to fulfill the data storage regulation and enhance the “Trust” paradigm. 

  

  * Collector shall use data for explicit purpose: Data shall be collected for legitimate reasons and shall be deleted (or anonymize) as soon as data is no longer relevant. 

  

  * Collector shall protect data at communication level: The Integrity of the information is important because modification of received information could have serious consequences for the overall system availability. User has accepted to disclose information to a specific system, not all the systems. The required level of protection depends on the data to be protected according the cost of the protection and the consequence of data disclosure to unauthorized systems. 

  

  * Collector shall protect collected data at data storage: User has accepted to disclose information to a specific system, not all the systems. It also could be mandatory to get infrastructure certification. The required level of protection depends on the data to be protected according the cost of the protection and the consequence of data disclosure to unauthorized systems. As example, user financial information can be used to perform automatic billing. Such data shall be carefully protected. Security keys at device side and server side are very exposed and shall be properly protected against hardware attacks. 

  

  * Collector shall allow user to access / remove Personal Data: Personal Data may be considered as a property of the user. User shall be able to verify correctness of the data and ask – if necessary – correction. Dynamic Personal Data – for instance home electricity consumption – shall also be available to the user for consultation. For static user identity, this principle is simply the application of current European regulations according access to user profile. 

  

######  3.3.3. Internet of Things Ethical and Privacy concerns

We have in previous work [1] studied in depth the potential ethical and
privacy implications of the Internet of Things. This existing knowledge is
taken into account in the set-up of the project experiments and the project
will be continuously involved in the IoT ecosystem activities regarding ethics
and privacy protection.

The following presents rapidly the main identified concerns related to ethics
and privacy in the IOT domain:

3.3.3.1. IoT Potential Ethical Implications

As presented in details in the Ethics Factsheet summarizing the findings of
the ethics subgroup of the IoT Expert Group of DG Connect [2] the main
identified issues regarding Ethics in IoT are:

  * **The risk of social divides** : although many societal benefits are envisioned for IoT, their deployment and spreading may not be uniform across the population, creating a risk of an increased digital divide (between those who can afford and use the new applications and services and those who cannot). This risk is reinforced and may even be amplified in a “knowledge divide”, between those who know and understand the technologies behind an IoT world and those who don’t and who are therefore unable both to take full profit of it and to avoid potential dangers. 

  

  * The key issue **of trust and reliance on IoT** which is mostly linked, but clearly not limited to the respect of privacy and data security. The massive deployment of IoT enabled technologies and services will pose the question of their reliability and how, when, and why the user can, or has to rely on these new services in a trustful relationship. This need for a trustful relationship and the risk associated are even stronger in the case of “smart”, context aware applications who advise decisions to the end user. This pleads for the need for openness and reputation / ranking systems as strong needs to establish this trust. 

  

  * The risk of a **blurring of context** in the society perception of what is private and public, what is virtual and what is real. This evolution of society values and perception is not necessarily an issue in itself, but it has to be understood, monitored and reflected upon to make sure that it doesn’t result in additional issues or increase existing risks (such as the risk of social divides, especially between different age groups). 

  

  * The **non neutrality of the IoT metaphors and vocabulary** . Many terms and metaphors (such as the “smart”-things) used to describe IoT technologies, products and services assume that IoT will ease the lives of people, and they convey this meaning and raises expectations. This non neutrality and the associated expectations are important to be understood not only by the stakeholders defining the IoT but also by the targeted market. 

  

  * The necessity of **a social contract between object and peoples** . This necessity arises from the stronger and stronger reliance of societies on technologies envisioned in the IoT vision. As IoT objects are more and more autonomous, connected and involved in our lives, this may result in loss of control for users (as object take decisions for them) and in blurring of responsibilities for stakeholders (whose in the end really responsible for the decision). This pleads for a strong reflection on how IoT objects should behave and interact with people and with each others. A need that is furthermore reinforced in the case of context awareness by the ability of objects to create profiles of users and stakeholders based on the data gathered. 

  

  * And the **issue of informed consent and obfuscation of functionalities** which here again rejoin the privacy and data protection issue (without being limited to it). The actual understanding of what is happening in IoT scenarios, which is necessary for a truly “informed” consent by the user, is complicated by the strong tendency of IoT deployments to be actually nearly invisible as communicating objects are miniaturized, hidden, and their true features obfuscated. This pleads for an ability to make IoT deployment visible for inspection, education and explanation needs. 

  

3.3.3.2. IoT potential implications on privacy, data protection and security

Based on the findings of the privacy and security subgroup of the IoT Expert
Group of DG Connect [2], and their analysis in the BUTLER project [1], the
main identified privacy and data protection issues in IoT are:

  * **Continuity and availability of services:** As the deployment of IoT spreads and more and more systems and persons rely on these new products, applications and services, the issue of continuity and availability of the services rises. The strong integration of IoT devices in our day to day lives, and especially in critical services (such as health, security, and energy) increase the impact of a potential loss of service. 

  

  * **Sensibility of user data and contextualization of risks:** As Smart services gather more and more information on the user (willingly or even without notice), the question of the sensibility of these data, arise. The Internet of Things complicates this issue as it gathers more and more information that, despite a harmless appearance, can turn out to become sensitive when analysed on a large scale. For example, the collection of household power consumption can seem to hold no important privacy issues, however these data when statistically analysed can reveal much on the content of the user home and his/her day to day habits. The actual sensibility of gathered information is therefore not always known at the time when data gathering is decided and / or accepted by the user. In an IoT world, the risks related to privacy and data security are dependant of the context and purpose in which data is gathered, and used. And this context can be evolving, which support the need for a context-aware management of security and data protection. 

  

  * **Security of user data** : The user data must therefore be protected against unauthorized access, and this security should be ensured at each level of communication. The multiplication of communicating devices characteristic of the Internet of Things therefore increases the difficulty of this protection as the number of link to be protected increases. The potential impact of security breaches is also on the rise as the data stored have more and more applications, and thus give more and more information on the user and give more and more access to critical parts of our lives, increasing risks linked to identity theft and electronic identification. 

  

  * **Management of data:** Even when the security of the user data can be guaranteed against unauthorized access, the question of the actual management and storage of the information by the service provider remains. Questions such as: “How much data is collected to provide the service?”, “Is this strictly necessary?”, “Who is responsible to handle these data?”, “Who has access, how and when to the data?”; can be expected from the user. 

  

  * **Ownership, repurposing and communication of data:** The question of the ownership of the data collected is also central to the IoT Ethics issue: getting propriety or access to user data and reselling these data can be a significant source of revenue. The monetization of user data can raise several issues: how is the additional revenue shared between the service provider and the user? How aware is the user of this use of his/her data? How much control does he/she have on it? What are the third parties who get access to the data and for what? 

  

  * **Captivity of data:** Even as the service is becoming more and more used and accepted by the user, the ethics question remains: what happens to the user data if the user leaves the service? And how feasible is it for a user or consumer to change service provider once he has been engaged with one 

  

for a significant time? These questions are important to avoid consumer
captivity through data that would result in an unfair advantage, destroying
competition with all the eventual consequences (suppression of consumer
choice, degradation of user service and reduction of innovation).

  * **Applicable legislation and enforcement:** Given the global nature of IoT and the number of stakeholders necessarily involved in an IoT deployment, the question of responsibility and applicable legislation arise. This is reinforced by the fact that in a truly “Internet” of things vision the different actors will be spread across different countries and regions, increasing the number of potential legislation involved. This issue impacts not only the users, which may be confused on which legislation the service he/she is using follows, but also the policy makers and the whole IoT value chain as developing IoT applications and deployment without a clearly identified chain of responsibilities and applicable law represent a strong business risks. 

  

  * **Availability of information:** Finally, in a world where technical and legal complexity increases, the quality of the information available to the user is key to the management of the ethical issues: the service provider must ensure not only that the information is available, but that it is presented in a way that ensures it is correctly understood by the user. 

  

####  4\. Strategy for responsible user involvement

_In this section we present the project overall strategy for responsible user
involvement, a summary of the actions preformed in the first year and a plan
for future activities._

#####  4.1. General strategy for responsible user involvement

As presented above in section 3, the involvement of end users in the
experiments created over the FESTIVAL federation of platforms and testbeds,
responds to several objectives and requires specific attention to ensure a
responsible research and innovation practice. It is based on this analysis
that the project has defined a strategy for preparing and supporting the user
involvement.

######  4.1.1. Main challenges identified

The strategy proposed has to face several operational challenges:

  * First, the nature of the project means that the experiment that will be set up on the federation are research experiment that will take place in **an evolving framework** . The scientific knowledge of the field, the technical set up, and the legal and societal framework in which the experiment will be conducted are progressing in parallel and these evolutions create requirement for adaptability and evolution capabilities in the experiment themselves. This implies a need for openness to potential evolutions in the way the user involvement is carried out. 

  

  * A direct requirement of user involvement in research experiment is, of course, to ensure that the experiment and interactions with the participants is done in a valid legal framework that protects both the participants and the project. An additional point of attention in this matter lies in the fact that the FESTIVAL project involves partners and experiments in various countries in Europe (with different legislations) and in Japan. 

  

  * The nature of the experiments that look into new ways to collect, use and / or store data can also imply challenges to personal data protection (as presented in section 3.3). As aforementioned, although personal data collection and processing is not a goal of the project, a clear assessment of the risks and the set up of safeguard is clearly necessary to ensure a minimal hazard. 

  

  * Finally, we consider that a foremost challenge of the user involvement in experiment is in raising the awareness and knowledge of both participants and experimenters in the importance of the ethical issues at stake, the responsible involvement methodologies, and the potential impacts of novel ICT innovation at a societal level. Therefore, significant effort has to be dedicated to training and produce education material for both participants and experimenters. 

  

######  4.1.2. Project strategy and planned activities

From the challenges presented above derives the project strategy and planned
activities:

The project strategy articulates around two phases:

  * A first phase (M1 – M12) focuses on the preparation of the user involvement before the start of any project experiments. In this first phase, all the preparatory work and document must be made ready for the beginning of the experiments. 

  

  * A second phase (M13 – M36) where the activity focus more on a direct support to the experimenters in the set up of their experiment and in the actual participant involvement. However, in this second phase the project will have to continue to produce additional training material and to ensure that the material created in the first phase stays up to date and adapted to the experiments. 

  

The strategy will be implemented through a set of complementary activities:

  * **A technological and legal watch** activity to ensure that the project stays up to date with the state of the art in research experiment setup, involvement of external participants, protection of data and privacy and the accompanying legal framework. 

  

  * **Raising Awareness:** The creation of training materials for both experimenters and participants to present and explain in a rapid and accessible way some of the important challenges that can be raised by the participation to the project experiments. 

  

  * **Informed Consent Process:** The creation off the processes and document for ensuring the legal participation of the end users to the experiments: processes for the collection of informed consent, set up of a complaint procedure through a neutral third party, technical mechanisms ensuring the protection of experiments data (in joint work with WP2 and WP3). 

  

  * **Assessment of Personal Data Management:** The set-up of a basis for a “privacy impact assessment” process that can be used by the project experiments (and external experimenters) to assess the potential risks linked with their technology deployments in order to identify the ones that would require specific measures and oversight. 

  

  * **The organization of training sessions** and support for the experimenters to accompany the creation of the experiments and the actual involvement of the experimenters. 

  

#####  4.2. First year activity report

######  4.2.1. Overview of the task activities

Based on this strategy, we have set up the following activity schedule for the
project first year:

**Figure 1 - First Year Activity Schedule**

Within the first year, this schedule decomposes into four overlapping period
of activity:

  * During Month 1 to 4, the task conducted a state of the art analysis through a literature review and confrontations between the various existing knowledge in the consortium. It defined the project strategy and activity schedule. 

  

  * During Month 3 to 6, the task concentrated on the creation of initial drafts of the planned output of the task: the informed consent process, first examples of Factsheets, and an initial draft of the Privacy Impact Assessment process. The objective of the task was to have these initial draft ready for discussion and initial validation at the consortium level for the second project plenary meeting (April 25  th  in Osaka). 

  

  * During Month 5 to 12, the initial draft processes and documents were refined based on the comments and the specific needs of the envisioned experiments. 

  

  * During Month 10 to 12, the task focused on the documentation of the activities in this deliverable. 

  

To coordinate and conduct these activities, the project consortium organised
specific meetings and participated to the project meetings. The following
table presents the main meetings in which the task activities were discussed.
The organisation of task specific meetings was especially necessary in the
first phases of the activity as the task had to work in closed group on
setting up the processes. The participation to the plenary meetings of the
project enabled to communicate the task proposals and results to the whole
consortium to enable more complete discussions.

**Meeting Date Type of Meeting**  
  
<table>  
<tr>  
<th>

**November 27 th  2014 **

</th>  
<th>

Plenary Meeting (Santander)

</th> </tr>  
<tr>  
<td>

**January 27 th  2015 **

</td>  
<td>

Plenary conference call

</td> </tr>  
<tr>  
<td>

**February 13 th  2015 **

</td>  
<td>

Task Specific conference call

</td> </tr>  
<tr>  
<td>

**February 24 th  2015 **

</td>  
<td>

Plenary conference call

</td> </tr>  
<tr>  
<td>

**March 24 th  2015 **

</td>  
<td>

Task Specific conference call

</td> </tr>  
<tr>  
<td>

**March 31 st  2015 **

</td>  
<td>

Plenary conference call

</td> </tr>  
<tr>  
<td>

**April 25 th  2015 **

</td>  
<td>

Plenary Meeting (Osaka)

</td> </tr>  
<tr>  
<td>

**May 19 th  2015 **

</td>  
<td>

Task Specific conference call

</td> </tr>  
<tr>  
<td>

**June 6 th  2015 **

</td>  
<td>

Plenary conference call

</td> </tr>  
<tr>  
<td>

**July 24 th  2015 **

</td>  
<td>

Plenary conference call

</td> </tr>  
<tr>  
<td>

**September 18 th  2015 **

</td>  
<td>

Plenary Meeting (Grenoble)

</td> </tr> </table>

######  4.2.2. Specific local activities

In addition to these high level coordinated activities, some of the project
experiment set up required already some specific work toward user involvement.
These specific efforts are documented here:

4.2.2.1. Santander

In order to evaluate the potential impact of Festival initiative, the first
step was to arrange a meeting with the Responsible of the Municipal office of
Market Support to present the current situation of Smart Shopping in
Santander, and how it could be improved thanks to FESTIVAL project. He liked
the idea of using new technologies to promote shopping activity within the
city and he proposed several places where to install new devices, including
indoor and outdoor scenarios. One of the indoor scenarios is a Municipal
Market (Mercado del Este) whereas the proposed outdoor scenario consists of a
couple streets full of shops located at the old town (Cádiz St., Lealtad St,).
After this first meeting, we decided to arrange a second one to show him real
devices, analyse proposed locations and start contacting with other
stakeholders.

During the second meeting, the Responsible of the Municipal office of Market
Support proposed another streets of the city center where to install FESTIVAL
devices, taking into account not only the number of shops, but also, the
degree of involvement of shopkeepers: Arrabal St. or Medio St. located both at
the old town, include shops with the most participative shopkeepers in the
city: they have organized different initiatives, in collaboration with bars
and restaurants, to foster shopping activity.

Regarding the indoor scenario, and in order to get feedback and feelings from
shop owners of Mercado del Este we held a meeting with the manager of the
owner’s association of Mercado del Este, together with the Municipal office of
Market Support. Although he liked the idea, he raised a potential problem:
shop owners could request the exclusiveness of the offers sent, if Festival
devices installed at Mercado del Este premises. Additionally, it was required
to analyse the technical/economic viability of the installation at the Mercado
del Este: there is no assigned budget for equipment, so, it is essential to
minimise installation costs. Therefore, a meeting with the Municipal
responsible of computing department, in charge of new installations, was also
arranged to find the balanced suitable location of FESTIVAL devices, taking
into account available points to access to internet, available power supply
access and also, the best location in terms of counting people and location.
Finally, these devices may be installed at the central corridor of the market,
being the most transient part of this building.

During the last meeting with the manager of the owner’s association of Mercado
del Este and the Municipal office of Market Support, the first one informed us
that there was no exclusiveness requirement from shop owners, therefore, it
was possible to install there new devices.

At this point, the idea is to install Festival devices at Mercado del Este,
which will serve to develop and test in real scenarios the counting people and
localization, functionalities being tested already in the UC premises.

Once these functionalities are validated in Mercado del Este, sending offers
functionality will be developed. Regarding this new functionality, several
meetings will be arranged with main actors of Smart Shopping:

  * Shop owners, informing them about this innovative initiative, which will allow them to generate and deliver offers and special discounts of their products for free. Getting their involvement is one of the main goals, because attractive offer generation is essential in order to get citizen involvement. 

  

  * Citizens, as final users, who will have on their mobiles devices new offers and discounts. We will try to reach as many citizens as possible, so we will use different communication channels, such as, meetings with neighbourhood associations and providing information at centre for Demonstration of Smart City (Enclave Pronillo). 

  

Generating offers will be done by shop owners through CreateAnOffer app, which
will allow to know statistics about: number of shops, number of offers
generated by shop, length of the offer,… This will be valuable information in
order to evaluate shop owners engagement.

Additionally, it will be suitable to arrange follow-up meetings to analyse
obtained results, get feedback from shop owners and citizens, and, taking it
into account to improve the process.

#####  4.3. Future plans

This first year of the project has enabled, as presented in this report, the
creation of the baseline infrastructure to enable the responsible involvement
of end users in the project experiments. Over the following period, the focus
of the task 4.1 will progressively shift to a supporting role to ensure that
the infrastructure set up is used efficiently and that it is kept up to date.

The task priorities are:

  * Continuing the existing efforts in the set-up of the baseline infrastructure. 

  

  * Providing support to the project partners and external experimenters in the set-up and usage of the tools provided by the project. 

  

  * The extension and improvement of the existing infrastructure and processes to complete the existing offer. 

  

Thus, the main activities envisioned to develop the responsible user
engagement framework of the project are:

  * **The continuation of the creation of project factsheets** raising awareness on specific topics of the user engagement in experiment. This includes the finalisation of the translation work on all factsheet and the creation of new factsheets on new topics. Section 5.3 present a list of the future envisioned factsheets. 

  

  * **Support to the project experiment description:** The current deliverable presents in section 3.2 a first description of the experiment envisioned by the project from a user engagement perspective, and in section 7.2 a first assessment of the security and privacy mechanisms set up by each experiment. This first analysis will evolve as the project experiments become better defined and start to be implemented and deployed over the federation. The Task 4.1 will ensure that the current descriptions are maintained up to date as the experiments evolve and that they reach a higher level of maturity and consistency. Future description of the experiments and privacy impact assessment will be integrated in deliverable 3.2 (month 22) and 3.4 (month 34). 

  

  * **The Privacy Impact Assessment process may evolve,** as presented in section 7.1, the current process is an introduction to a full Privacy Impact Assessment procedure, and depending on the direction taken by the project experiments and their potential collection and use of personal data, it may be necessary to go further in the definition of a Privacy Impact Assessment process. 

  

  * **An electronic version of the informed consent process** will be developed and integrated in the FESTIVAL federation portal, as presented in section 6.3. 

  

  * **The feedback collection process** will be defined in cooperation with task 4.2 and 4.3. The deployment and further development of existing tools (such as the BUTLER User Feedback Tool [3]) will be considered. The integration of such tool to the federation portal would be a strong asset to improve the experience of the external experimenters: the portal would enable them to enter in contact with experiment participants not only to gather their informed consent but also to gather feedbacks on the experiment. 

  

  * Finally, the project will continue to keep watching the evolution of the state of the art and interact with other research project involving end users in experiment to gather (and reproduce) good practices and if necessary adapt the strategy of the project toward responsible end user engagement. 

  

####  5\. Raising Awareness: Factsheets

_In this section we present the project activity toward raising the end users
and experimenters awareness toward ethical issues and responsible research and
innovation. We thus present the concept of factsheets proposed by the project
and the current and foreseen factsheets._

#####  5.1. Rational and concept for factsheets

As presented above in section 4, raising the awareness of both participants to
the experiments and experimenters regarding the process of responsible
research and potential ethical impacts of the experiment, is a significant
challenge for the project. The challenge is complex from the issues it
addresses (the protection of privacy and potential ethical impacts of the IoT
being a research topic by itself), but also from the fact we address audiences
(experimenters and participants) that are usually not aware of the potential
issues. This is especially the case when the trade-off is between immediate
rewards (the conduction of the experiment / the discovery of new technologies)
and potential long term risks (long term societal impacts of applications that
would be based on the project work).

The challenge is of high importance for the project as an increased awareness
and understanding of the potential issues is important both for experimenters
(to ensure they comply with the project processes) and for participants (to
ensure a real “informed” consent to the experiments).

The state of the art on the ethical implications of IoT, on the protection of
privacy and on data security is already consequent and does not represent a
core domain of research for the FESTIVAL project. We decided therefore to
focus our work on creating training material that increase the awareness of
the experimenters and participant on the potential issues and link with
existing solutions. With this in mind we came up with the **Factsheet
concept.**

The Factsheet, a visual document of a single page, that can be widely
distributed and that focus on a single issue, or a specific process set up by
the project. They provide a general overview of the topic they address without
entering into the details but rather as an invitation to consider a specific
point. The Factsheets target usually the experimenters, but can be also very
useful for experiment participants as they inform them of the project
practices.

The Factsheets serve several complementary objectives:

  * They can raise awareness on a specific potential problem to attract experimenters and participants to ask themselves the right questions. 

  

  * They provide a rapidly accessible general overview of complex issues, without definitive answers but as invitation to look into a subject or seek additional advice. 

  

  * They can provide also directly usable high level guidelines on the processes and activities of the project. 

  

  * They are also useful in disseminating the project vision and/or best practices with the community with the double objective of promoting the work of the project and participating to the community discussions on these important issues. 

  

Concretely the factsheet will be part of the document disseminated by the
project in coordination with Work Package 5. The factsheet will thus be
disseminated on the project website in a dedicated section (Experimentations
Documents:  _http://www.festival-project.eu/en/?page_id=424_ )  . They will be
also disseminated in the events the project participates, in relevant
communities (such as the RRI-ICT Forum:  _http://www.rri-ict-forum.eu/_ )  .
Finally and most importantly the factsheet will be made available, translated
in the local language in the project experimentation locations and living labs
so they are directly available for local experimenters and experiment
participants.

#####  5.2. Year 1 factsheets

######  5.2.1. Overall vision

The first year factsheets aim to enable to experimenter to grasp the primary
issues responsible research and the ethical impacts of the experiments. Once
the content had been agreed on (in an English version), the factsheets are
being translated in the languages of the various experiment platforms and
living labs of the project to make them easily accessible for experimenters
and participants.

The following table sums up the factsheets created over the first year, and
the languages in which they are available.  
  
<table>  
<tr>  
<th>

**#**

</th>  
<th>

**Topic**

</th>  
<th>

**Main Partner**

</th>  
<th>

**Date**

</th>  
<th>

**En**

</th>  
<th>

**Jp**

</th>  
<th>

**Fr**

</th>  
<th>

**Sp**

</th> </tr>  
<tr>  
<td>

#1

</td>  
<td>

Personal Data Protection

</td>  
<td>

inno

</td>  
<td>

March 2015

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

X

</td> </tr>  
<tr>  
<td>

#2

</td>  
<td>

Informed Consent Process

</td>  
<td>

inno

</td>  
<td>

April 2015

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

X

</td> </tr>  
<tr>  
<td>

#3

</td>  
<td>

Camera use in trial

</td>  
<td>

CEA

</td>  
<td>

August 2015

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

X

</td>  
<td>

X

</td> </tr>  
<tr>  
<td>

#4

</td>  
<td>

Usage of Open Data

</td>  
<td>

Santander & KSU

</td>  
<td>

August 2015

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

</td>  
<td>

X

</td> </tr>  
<tr>  
<td>

#5

</td>  
<td>

Privacy Impact Assessment

</td>  
<td>

inno

</td>  
<td>

August 2015

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

</td>  
<td>

X

</td> </tr> </table>

######  5.2.2. Factsheet #1 Personal Data Protection

The first factsheet created is a general information factsheet on personal
data protection.

The objective of this factsheet is to inform the audience about what are
Personal Data, and to state the general principles regarding Personal Data
protection that are being followed by the FESTIVAL project.

Although the collection of personal data is not a focus of the project
experiments, the broad definition of personal data makes it possible that some
of the project experiments will indeed deal with personal data at some point.
Therefore, this factsheet was created to inform experimenters of the specific
care that should be taken in these cases.

The targeted audience for this factsheet is therefore both the participants to
the experiments (so that they understand the policy of the project regarding
personal data) as well as the experimenters (so that they take specific care
if they ever have to deal with personal data in their experiments). In
addition, we think this factsheet can also be useful to raise the general
public awareness on what is personal data, why they should care and how
responsible ICT experiments and applications should handle such data.

The factsheet was already presented to the RRI-ICT event 2015 (Brussels July 8
– 9) and received positive feedbacks.

######  5.2.3.Factsheet #2 Informed Consent

The second factsheet deals with the process of getting informed consent of the
participants for an experiment.

The objective of this factsheet is to provide all the information to gather
the informed consent of an experiment participant to be in line with the
ethical requirement of research.

As the FESTIVAL project aims to carry out several experiments and to involve a
number of external participants, it was essential to prepare a step by step
guideline on how to ethically involve end users in the experimentations. The
audience targeted by the factsheet is thus the experimenters that wish to
conduct experiments in regards to the ethics requirement of research but also
the participants that wish to be informed of the benefits and risks of the
experiment, and their potential way to complain or to withdraw from it.

The factsheet in itself provides the steps of getting the informed consent and
the content necessary documents to do so. In this way, it provides the links
to the informed consent templates.

######  5.2.4.Factsheet #3 Camera use in Trials

This Factsheet focuses on the use of video data in project experiments.
Dealing with video data means particular requirements in terms of precaution
related to privacy. It also implies specific agreements either from an
independent local authority or from the end-users (i.e. the experiment
participants).

This factsheet aims at informing potential experimenters about specific
requirements needed when they are dealing with video data. More generally, the
target audience corresponds to any person involved in the project that is
related to a video experiment. It also provides particularly useful
information for the end-users and participants in the case they are involved
in a video experiment.

As the FESTIVAL project aims to carry out several video experiments involving
external experimenters and external participants, it was essential to clarify
how the protagonists may deals with those data which are of a specific nature.
It was necessary to identify main measures to take in regards to the ethics
requirements but also to follow local applicable laws.

######  5.2.5.Factsheet #4 Usage of Open Data

The fourth factsheet deals with the process of using Open Data for an
experiment.

The objective of this factsheet is to provide the information to Open up Data,
including useful recommendations and which steps should be followed in this
process, not forgetting the promotion of new datasets and/or catalogs.

It is important to define first what Open Data is, and then, step by step
guideline to be followed when you are facing with this type of information.

The audience targeted by the factsheet includes the experimenters that will
generate new datasets and catalogs based on developed experiments.

The factsheet consists of three sections, as can be seen in the following
figure,:

  * definition of Open Data, 

  

  * how to Open up Data, including some recommendations and steps, 

  

  * how to promote new datasets and/or catalogs, including catalogue federation by a simple API. 

  

######  5.2.6.Factsheet #5 Privacy Impact Assessment

This Factsheet focuses on the process set up in the project to evaluate the
risks associated with data protection in the project experiment.

The objective of this Factsheet is to inform the audience about the process
followed by the project, that should be applied by every project experiment
done both by the consortium or external experimenters.

The process set up in the project (presented here in section 7) aims to
rapidly evaluate the way data is collected, stored, used, shared and
destructed by the experiment to identify potential risks early on.

The target audience of this factsheet is mainly the experimenters as it
summarizes the idea behind the Privacy Impact Assessment process of the
project. It can also be useful for participants to the experiments as an
explanation of how the experimenters had to question themselves on these
important questions. Along with the results of the experiments Privacy Impact
Assessment (which have to be communicated to the participants), it can help
build trust in the experiment participants.

#####  5.3. Future factsheets

The project approach (factsheets) to raise the stakeholders awareness on
responsible end user involvement topics and the processes set up by the
project, has for now received positive feedbacks. Although the factsheets are
relatively new and have been presented on relatively few occasions, they seem
to respond to a demand for rapid overview and introductions on important
topics. We will of course continue to monitor the feedbacks on the existing
factsheets in the following months to be able to fully judge of our approach
success, and these feedbacks will strongly influence the future roadmap on
factsheets.

However, we can already present a temporary list of the topics that we
consider could make useful future factsheets, shown in what we consider could
be a chronological order:

  * **Project thematic experiments and user involvement:** We consider the creation of four specific factsheets on the topics of experiments of the project: Smart Energy, Smart Building, Smart Shopping and Federation Experiment: 

  

o **Smart Energy Experiments and User Involvement.** o **Smart Building
Experiments and User Involvement.** o **Smart Shopping Experiments and User
Involvement.** o **Federation Experiments and User Involvement.**

Each of these factsheets would present an overview of the project use cases
and planned experiments on the specific topic, present the challenges and
importance of the planned experiments, the planned end user involvement and
its relevance to the topic, and the foreseen impacts. These factsheets would
help experiment participants to understand the experiment they participate to
in a broader context, and the external experimenters to identify the work
already carried out in the project they can relate to. These factsheets would,
of course, have to be created in close cooperation with Work Package three.

  * **Responsible End User Involvement in Experiment:** This factsheet would present the general approach and strategy of the project toward responsible end user involvement. It would present some of the content documented in the current deliverable: section three on motivation and context, and section four on overall strategy. The factsheet would be useful for external experimenters and experiment participants to understand the approach of the project globally,as a complement to the focus of the other factsheets on specific topics. The Factsheet could also be useful as a dissemination tool, ensuring that the approach developed in the project can reach other research projects and be replicated. 

  

  * **Evaluating Experiments:** This factsheet would provide an introduction to the evaluation framework created by task 4.2 and 4.3 and presented in deliverable 4.2. The factsheet would present the motivation for setting up an evaluation framework, the approach followed by the project, how it can be used, and the role of the relationship and feedbacks of end users in the collection of feedbacks. This factsheet would be useful for external experimenters and experiment participant to understand one of the key motivation for end user involvement (the collection of useful feedback) and to thus put in context the responsible involvement of end users in experiments. This factsheet would be created in close cooperation with Task 4.2 and 

  

4.3.

  * **Using FESTIVAL in your Experiments:** This factsheet would provide an introduction on how external experimenters can use the FESTIVAL federation to create and conduct their experiments. It would present a rapid overview of the type of resources available and the process of using the federation portal. This factsheet would be useful for external experimenters as a first introduction to the project EaaS offer. The factsheet would be created in close cooperation with Task 3.4. 

  

  * **Collecting feedbacks in Experiments:** This factsheet would present the project process and tools for collecting end users feedbacks in experiments. It would be useful for external experimenters as an introduction to the project tools for feedback collection. The factsheet would be created in close cooperation with Task 4.2 and 4.3. 

  

  * **Experimentation as a Service Model:** This factsheet would present the EaaS model set up by the FESTIVAL federation. It would present the principles of the business model and the envisioned set up beyond the project end as a common exploitation opportunity. This factsheet would target external experimenters, to provide them information on the sustainability of the project approach and on the future business model. It would also be useful as a dissemination tool for other projects working on EaaS models. The factsheet would be created in close cooperation with Task 5.1. 

  

  * **FESTIVAL Socio-economic impacts:** This factsheet could present the result of the socioeconomic evaluation carried out by task 4.3 and present in a general way the envisioned long term socio economic impact perspective of the experiments carried out on the FESTIVAL federation and on the federation itself. It would be useful for experiment participant and external experimenters as a vision of the context in which the experiment take place, and could also serve as a dissemination tool for the project. The factsheet would be created in close cooperation with Task 4.3. 

  

Additionally, it has been discussed the opportunity of creating similar
factsheet on topic less related to this specific task (responsible end user
involvement) and more general to the project. If the factsheet model gathers
good feedbacks and is considered useful, it could be extended as a
dissemination material on other subject, especially technical subjects such as
a general introduction to the project architecture, or a presentation of the
APIs of the federations, etc…

As already mentioned, the subjects presented above are our current vision of
what could be useful as future factsheet. The list will evolve based on the
feedback we receive on the current factsheets and on the general development
of the project.

####  6\. Informed Consent process

_In this section we present the process proposed for the project for the
informed consent procedure and the tools set up._

#####  6.1. General Procedure Principles

Informed consent is one of the key notions of personal data protection. Indeed
several General principles must then be taken into account when dealing with
personal data:

  * The right to access and to rectify collected data. 

  

  * The protection of the rights of individuals, and 

  

  * The control and protection of these data by an independent national authority. 

  

  * **_The informed consent of the concerned persons._ **

  

Informed consent is a term which originates in the medical research community
and describes the fact that a person has been fully informed about the
benefits and risks of a medical procedure and has agreed on the medical
procedure being undertaken on them. **Informed consent** is an ethical
requirement for most research and must be considered and implemented
throughout the research lifecycle, from planning to publication. Gaining
consent must include making provision for sharing data and take into account
any immediate or future uses of data.

The provisions European law, national laws and guidelines of many professional
research organizations recommend the following principles be followed to
ensure that consent is informed:

  * Consent must be freely given with sufficient detail to indicate what participating in the study will involve. 

  

  * There must be active communication between the parties - what is expected from participants and why their participation is required. 

  

  * Documentation outlining **consent has to differentiate between consent to participate and consent to allow data to be published and shared.**

  

  * Consent cannot be inferred from a non-response to a communication such as a letter or invitation to participate. 

  

The general procedure principles followed by the project were then to produce
an experiment documentation that would follow the four principles cited above.
To do so several documents were produced.

#####  6.2. Informed Consent documents

######  6.2.1. Information sheet

Before collecting the consent, the participants must understand the nature of
the research and the risks and benefits involved if they are to make an
informed decision about their participation. To do so, the document given out
to describe the study must be simple and understandable by any subject and
must gather the following elements:

  * Purpose of the research. 

  

  * What is involved in participating. 

  

  * Benefits and risks. 

  

  * Terms for withdrawal: 

    * Participants have a right to withdraw at any time without prejudice and without providing a reason. 

  

    * Thought should be given to what will happen to existing, already provided, data in the event of withdrawal. 

  

  

  * Usage of the data: 

    * During research. 

  

    * Dissemination. 

  

    * Storage, archiving, sharing and re-use of data. 

  

  

  * Strategies for assuring ethical use of the data: 

    * Procedures for maintaining confidentiality. 

  

    * Anonymization data where necessary, especially in relation to data archiving. 

  

  

  * Details of the research: 

    * Funding source/ sponsoring institution/ name of project/ contact details for researchers/ how to file a complaint. 

  

  

The Festival project has prepared an information sheet template (see annex A),
that provides a generic project description with simple language and
understandable by all, as well as a second section to be filled out with the
element described below according to the specificities of each experiment.

######  6.2.2. Letter of consent

Once the participants have been aware of the nature of the study and the risks
and benefits involved, a formal consent in the participation to the experiment
is required. A specific form has been produced to ensure that the participant
has fully understood the specificities of the experiments and agrees to take
part in the study. This form also provides information on the withdrawal
procedure, the data collected and encourages the participants to ask further
questions to the researcher.

######  6.2.3. Withdrawal Procedure

As detailed in the informed consent forms, the participant has all the rights
to decide at any time during the research that he/she no longer wish to
participate in the study, and that he/she can notify the researchers involved
and withdraw from it immediately without giving any reason. A specific form is
provided for this purpose:

######  6.2.4. Complaint Procedure Documents

In addition to the feedback collection that will take place during the
experiment, participant will be given the possibility to file a formal
complaint on their participation to the study. A complaint procedure
information document and a complain form will be provided to the participants:

#####  6.3. Electronic consent form

The existing consent procedure is focusing on the use of paper forms that the
participants to experiment have to fill upon their arrival in an
experimentation facility. To make it more convenient and enable a larger
participation to experiment, the project will create an electronic version of
the forms on a webpage. The following diagram presents the high level
functional requirements for the portal:

Integrated in the FESTIVAL federation portal, the web form for gathering
consent would be the main entry point for experiment participants to the
participant part of the portal.

An initial screen would enable to select the experiment in which the
participant is involved (screen 1).

Based on the experiment selected and the experiment location, the mother
tongue of the experiment participant can be assessed. Of course, the
possibility to change language will still be offered to the participant in
case he/she prefers to get access to the forms in another language than the
local language of the experiment.

A second screen (screen 2) will present the general project description, as
well as a commonly understandable description of the experiment and a brief
explanation of the informed consent process. This screen will also give access
to more information on the experiment, such as the result of the experiment
Privacy Impact Assessment.

The participant will then be presented with the consent form (screen 3) using
the same language and format as the “paper” version of the form presented in
this deliverable.

If the participant accepts the conditions of the experiment he/she will
receive by emails a confirmation of the conditions of the experiment as well
the complaint and withdrawal procedures.

In case the experiment participant feels uncomfortable about sharing his/her
email for the experiment, the webpage will remind him/her of the existence of
a paper version of the forms which don’t require to provide a contact email.

####  7\. Assessment of Personal Data Management

_In this section we present the project activities to assess the risks
associated with the management of data in the project testbeds and experiments
and the associated measures to safeguard privacy and data confidentiality._

#####  7.1. Privacy Impact Assessment Procedure

######  7.1.1. Requirements and State of the Art

As presented in section four, one of the challenges of the project involvement
of participants in experiment is to correctly understand and assess the type
of data that are collected by the experiments, how they are treated, stored,
used, communicated and eventually destroyed. This is important to understand
and detect rapidly any potential privacy impact in case personal data would be
collected, and any other potential security and ethical issues related to data
protection. This is a challenge from the innovative and evolving nature of the
experiments carried out in the project. Additionally, it is an opportunity to
better explain to participant the nature of the experiment and what is done
with the data collected, to reinforce the “informed” nature of the consent
gathered.

To correctly carry out the assessment, the project looked into the state of
the art of Privacy Impact

Assessment. There is no standard definition for Privacy Impact Assessment (or
Privacy and Data Protection Assessment, as sometimes found in literature), nor
any standard process recommended that could be directly adopted. Evaluations
of various existing Privacy Impact Assessment initiatives and processes exist
such as the PIAW@tch website [4] or the evaluation of existing initiative in
various EU member states done by the PIAF project [5]. To build our own
framework we looked into the existing standards for RFID applications at
European Level [6] (to see how it could be adapted to the project
technologies). We also looked more specifically into recommendations and
process established at national level by public authorities: the UK ICO
Privacy Impact Assessment process [7], the French CNIL recommendations
regarding Privacy Impact Assessments [8], and beyond Europe with the Privacy
Impact Assessment Guidance [9] from US Homeland Security department.

The process we have set up in the first phase of the project respond to
several requirements:

  * The need to have a process that allows for relatively rapid evaluation of risks, within the project budget, and that can be applied both by the consortium and by future external experimenters. 

  

  * The need to have a process that enables an identification of experiments and applications that would require more advanced and in depth evaluation and additional procedures. 

  

  * The need to have a process that look with enough detail in the technical complexity of an experiment. The innovative nature of the potential experiment requires a real look at the experiment information flows to be able to assess with certainty the potential risks of an application. 

  

  * The need to have a process that provides results that can be communicated to the experiment participants. 

  

######  7.1.2. FESTIVAL PIA process at phase 1

Based on these requirements, we created a process that aims to identify the
need for a more advanced Privacy Impact Assessment and that accurately
describes the information flows of the experiment.

The FESTIVAL Privacy Impact Assessment is a process designed to evaluate the
potential privacy impacts and data security risks of an experiment. The PIA
should be conducted throughout the lifespan of an experiment, from its early
design phase to its deployment, help to identify potential impact on the
fundamental rights of individuals, and be publicly available to the
experiment’s participants.

The FESTIVAL PIA process consists of a fifteen question questionnaire,
covering the entire information flow of an experiment, and describing how the
data is handled in each phase and what associated security measures are
provided.

The questions are not limited to the way personal data are handled but concern
any type of data collected or used by the experiment. This allows to identify
not only direct privacy risks, but also to look into other potential security
issues. It is also a guarantee against the mischaracterization of data as
being not concerned by the personal data guidelines.

The questionnaires of the experiments are first shared and reviewed by the
consortium to evaluate the soundness of the questionnaire answer and look into
any unidentified potential issues.

The results of the Privacy Impact Assessment questionnaire have to be
communicated to participants to the experiments, along with the factsheet
explaining the principle of the process,as part of the informed consent.

The PIA is presented in Annex B.

######  7.1.3. Foreseen evolutions

We are confident that the current process can help us to look into any
potential issues related with the project experiment and remove any doubts
about the ethical impact of our experiment. However, if we identify some
experiments that require more advanced evaluation, we have plans to complete
the current process with the following steps:

  * A process for the identification of privacy and security risks based on the description of the information flows available in the current form. This assessment will describe the identified risks, and for each the probability of occurrence, and the potential impacts. 

  

  * A process for the evaluation of security solutions. For each risk identified, a description of the prevention measures (describing solutions set up to limit the occurrence of risks) and a description of mitigation measures (solutions set up to limit the impact of the risk) accompanied by an evaluation to determine whether the final impact on individuals after implementing each solution is a justified, compliant and proportionate response to the aims of the project. 

  

  * The involvement of external experts to analyze the results of the whole Privacy Impact Assessment and provide recommendations. 

  

#####  7.2. PIA Results

The following section presents the result of the initial evaluation of the
experiments planned by the project.

######  7.2.1. Smart Energy

7.2.1.1. PTL – Energy Management sensiNact  
  
<table>  
<tr>  
<th>

**Data Collection**

</th> </tr>  
<tr>  
<td>

_**What data is collected for the experiment?** _

</td> </tr>  
<tr>  
<td>

The user comfort to deal with the autonomous system.

</td> </tr>  
<tr>  
<td>

_**How is the data collected?** _

</td> </tr>  
<tr>  
<td>

  * The data from the user will be collected in a form of interview. 

  

  * Sensor information will be collected in a hard drive in form of a _log._

  

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data collection phase?** _

</td> </tr>  
<tr>  
<td>

No network data transmission will be used, the log data will be collected in
place.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Storage**

</th> </tr>  
<tr>  
<td>

_**How and where are the data stored?** _

</td> </tr>  
<tr>  
<td>

The data collected will be stored in a secured server behind a firewall and
with a security network agent as the responsible to setup such server.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data storage?** _

</td> </tr>  
<tr>  
<td>

The data will be password protected and the computer network access will be
restricted.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Usage**

</th> </tr>  
<tr>  
<td>

_**What are the data used for?** _

</td> </tr>  
<tr>  
<td>

The data will be used to detect which autonomous system action (or at what
point) it became an issue for the user.

</td> </tr>  
<tr>  
<td>

_**Are you using profiling techniques?** _

</td> </tr>  
<tr>  
<td>

No profiling technique adopted.

</td> </tr>  
<tr>  
<td>

_**Are you verifying the data?** _

</td> </tr>  
<tr>  
<td>

The researcher assigned to perform the experiment will be in charged to verify
the quality of the data and the coherence of the subject (the user) before
submit the data for the analysis.

</td> </tr>  
<tr>  
<td>

_**Are you considering secondary/future use?** _

</td> </tr>  
<tr>  
<td>

Negative, a report will be produced with the experiment and the data can be
disposed.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Sharing**

</th> </tr>  
<tr>  
<td>

_**Are you sending/sharing the collecting data with a third party or
publishing the data?** _

</td> </tr>  
<tr>  
<td>

Not applicable.

</td> </tr>  
<tr>  
<td>

_**How is data exchange with third party protected?** _

</td> </tr>  
<tr>  
<td>

Not applicable.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Destruction**

</th> </tr>  
<tr>  
<td>

_**How long is data stored?** _

</td> </tr>  
<tr>  
<td>

The data will be available until the report be produced containing the
relevant information.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Management**

</th> </tr>  
<tr>  
<td>

_**What regulation / legislation is followed by the experiment to protect data
and user privacy?** _

</td> </tr>  
<tr>  
<td>

Not applicable.

</td> </tr>  
<tr>  
<td>

_**Who has access to the data for management purpose?** _

</td> </tr>  
<tr>  
<td>

Only the researcher assigned for the experiment will have access to the data
collected.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data management?** _

</td> </tr>  
<tr>  
<td>

No data will be transmitted through the network or data storage will be done
without the consent of the subject. The data collected will be stored in a
secure server managed by a specialist assigned during the experiment, this
specialist might be one collaborator coming from one of the partners of the
project.

</td> </tr> </table>

7.2.1.2. ATR DC – xEMS control  
  
<table>  
<tr>  
<th>

**Data Collection**

</th> </tr>  
<tr>  
<td>

_**What data is collected for the experiment?** _

</td> </tr>  
<tr>  
<td>

Describe in particular what type of data is collected: are you collecting:

  * Energy consumption of equipment in the data center Servers, Air conditioners, Electric power sources - Task (Work load) assignment. 

  

  * Data center operator (including ASP). 

  

</td> </tr>  
<tr>  
<td>

_**How is the data collected?** _

</td> </tr>  
<tr>  
<td>

_Describe what process you use for the data collection?_

\- Environment sensors including temperature, humidity and pressure. - Are you
requesting the data directly from the user? Yes.

_Are you using external data sources?_

No _._

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data collection phase?** _

</td> </tr>  
<tr>  
<td>

For data transmission via wide area networks, secure communication protocols
such as ssh, HTTPS, IEEE1888, are utilized.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Storage**

</th> </tr>  
<tr>  
<td>

_**How and where are the data stored?** _

</td> </tr>  
<tr>  
<td>

The data are stored inside and outside of the data centers. Especially, as the
ASP model, the data are handled for the energy management from outside
(management office).

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data storage?** _

</td> </tr>  
<tr>  
<td>

The secure communication protocol is used for the communications and the data
is protected.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Usage**

</th> </tr>  
<tr>  
<td>

_**What are the data used for?** _

</td> </tr>  
<tr>  
<td>

The data are used only for energy management of the data centers.

</td> </tr>  
<tr>  
<td>

_**Are you using profiling techniques?** _

</td> </tr>  
<tr>  
<td>

The data are only sensing data for energy management. By analyzing the data
with machine learning, the data center operation is demonstrated from outside.

</td> </tr>  
<tr>  
<td>

_**Are you verifying the data?** _

</td> </tr>  
<tr>  
<td>

The data in only environment data. By using developed heuristic, the data
quality is maintained.

</td> </tr>  
<tr>  
<td>

_**Are you considering secondary/future use?** _

</td> </tr>  
<tr>  
<td>

The data obtained in the data center is not used for other case. The
management system with heuristic and algorithm developed for the data center
is expanded to other data center.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Sharing**

</th> </tr>  
<tr>  
<td>

_**Are you sending/sharing the collecting data with a third party or
publishing the data?** _

</td> </tr>  
<tr>  
<td>

The data obtained in the data center is not used for other case. The
management system with heuristic and algorithm developed for the data center
is expanded to other data center. The system is widely used as an OSS.

</td> </tr>  
<tr>  
<td>

_**How is data exchange with third party protected?** _

</td> </tr>  
<tr>  
<td>

The data obtained in the data center is not used for other case. The
management system with heuristic and algorithm developed for the data center
is expanded to other data center. The system is widely used as an OSS.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Destruction**

</th> </tr>  
<tr>  
<td>

_**How long is data stored?** _

</td> </tr>  
<tr>  
<td>

The data are overwritten every year.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Management**

</th> </tr>  
<tr>  
<td>

_**What regulation / legislation is followed by the experiment to protect data
and user privacy?** _

</td> </tr>  
<tr>  
<td>

The data are only sensing data for energy management. By analyzing the data
with machine learning, the data center operation is demonstrated from outside.
CPU task (workload) assignment information is normally not opened.

</td> </tr>  
<tr>  
<td>

_**Who has access to the data for management purpose?** _

</td> </tr>  
<tr>  
<td>

The data center manager access the data are for energy management.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data management?** _

</td> </tr>  
<tr>  
<td>

The data are only sensing data for energy management. By analyzing the data
with machine learning, the data center operation is demonstrated from outside.
Only CPU task (workload) assignment information is normally not opened.
Therefore, the workload assignment information for real use case is securely
controlled.

</td> </tr> </table>

7.2.1.3. Knowledge Capital – SNS like EMS  
  
<table>  
<tr>  
<th>

**Data Collection**

</th> </tr>  
<tr>  
<td>

_**What data is collected for the experiment?** _

</td> </tr>  
<tr>  
<td>

For smart energy management, the following data is collected:

\- End users’ inputs through smartphones and web browsers on PC. - Various
sensor data such as Temperature, humidity, GPS, … - People movement data
through floor pressure sensors.

…

</td> </tr>  
<tr>  
<td>

_**How is the data collected?** _

</td> </tr>  
<tr>  
<td>

For end users’ input, web browsers and smartphone applications are utilized.
Sensor data is collected through designated sensor devises. For collecting
data via wide area network, secure communications such as HTTPS, IEEE1888 are
utilized. For local transmission, local protocols such as ECHONET Lite,
Bluetooth are exploited.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data collection phase?** _

</td> </tr>  
<tr>  
<td>

For data transmission via wide area networks, secure communication protocols
such as ssh, HTTPS, IEEE1888, are utilized.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Storage**

</th> </tr>  
<tr>  
<td>

_**How and where are the data stored?** _

</td> </tr>  
<tr>  
<td>

Collected data is stored on the storage servers at NICT JOSE platform.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data storage?** _

</td> </tr>  
<tr>  
<td>

JOSE virtual servers are located behind strong firewall. So, restricted access
is permitted with high security.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Usage**

</th> </tr>  
<tr>  
<td>

_**What are the data used for?** _

</td> </tr>  
<tr>  
<td>

Collected data is utilized for smart energy management for building controls.
It is also utilized for research objectives to find further efficient energy
management.

</td> </tr>  
<tr>  
<td>

_**Are you using profiling techniques?** _

</td> </tr>  
<tr>  
<td>

No

</td> </tr>  
<tr>  
<td>

_**Are you verifying the data?** _

</td> </tr>  
<tr>  
<td>

Various statistical methods are exploited for finding efficient energy
management. On that process, the data is verified

</td> </tr>  
<tr>  
<td>

_**Are you considering secondary/future use?** _

</td> </tr>  
<tr>  
<td>

No

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Sharing**

</th> </tr>  
<tr>  
<td>

_**Are you sending/sharing the collecting data with a third party or
publishing the data?** _

</td> </tr>  
<tr>  
<td>

No

</td> </tr>  
<tr>  
<td>

_**How is data exchange with third party protected?** _

</td> </tr>  
<tr>  
<td>

No

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Destruction**

</th> </tr>  
<tr>  
<td>

_**How long is data stored?** _

</td> </tr>  
<tr>  
<td>

Collected data is stored until the FESTIVAL project ends.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Management**

</th> </tr>  
<tr>  
<td>

_**What regulation / legislation is followed by the experiment to protect data
and user privacy?** _

</td> </tr>  
<tr>  
<td>

Not Applicable

</td> </tr>  
<tr>  
<td>

_**Who has access to the data for management purpose?** _

</td> </tr>  
<tr>  
<td>

Only researchers and operators that have appropriate authorization can access
and manage the collected data.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data management?** _

</td> </tr>  
<tr>  
<td>

Data is accessed and managed only through secure protocols such as HTTPS, ssh,
and IEEE1888.

</td> </tr> </table>

######  7.2.2. Smart Building

7.2.2.1. PTL – People counting using a single / multiple camera(s)  
  
<table>  
<tr>  
<th>

**Data Collection**

</th> </tr>  
<tr>  
<td>

_**What data is collected for the experiment?** _

</td> </tr>  
<tr>  
<td>

The collected data are mainly from video data. Video frames are neither stored
nor transmitted.

</td> </tr>  
<tr>  
<td>

_**How is the data collected?** _

</td> </tr>  
<tr>  
<td>

The image sensors being involved can be of different natures. The only
information that is stored or transmitted corresponds to anonymized image
features.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data collection phase?** _

</td> </tr>  
<tr>  
<td>

No image frame is neither stored nor transmitted. Background images or image
features are transmitted via secured protocols. Depending on privacy issues,
transmitted image features can be shared using an encryption technique.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Storage**

</th> </tr>  
<tr>  
<td>

_**How and where are the data stored?** _

</td> </tr>  
<tr>  
<td>

To Be Determined

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data storage?** _

</td> </tr>  
<tr>  
<td>

To Be Determined

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Usage**

</th> </tr>  
<tr>  
<td>

_**What are the data used for?** _

</td> </tr>  
<tr>  
<td>

The data are used for statistics and monitoring.

</td> </tr>  
<tr>  
<td>

_**Are you using profiling techniques?** _

</td> </tr>  
<tr>  
<td>

Profiling technique is not planned because not needed by target applications.

</td> </tr>  
<tr>  
<td>

_**Are you verifying the data?** _

</td> </tr>  
<tr>  
<td>

For the moment, no procedure is defined to verify the collected data.

</td> </tr>  
<tr>  
<td>

_**Are you considering secondary/future use?** _

</td> </tr>  
<tr>  
<td>

No future use of collected data is planned.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Sharing**

</th> </tr>  
<tr>  
<td>

_**Are you sending/sharing the collecting data with a third party or
publishing the data?** _

</td> </tr>  
<tr>  
<td>

The data will not be made available to third parties.

</td> </tr>  
<tr>  
<td>

_**How is data exchange with third party protected?** _

</td> </tr>  
<tr>  
<td>

**\--**

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Destruction**

</th> </tr>  
<tr>  
<td>

_**How long is data stored?** _

</td> </tr>  
<tr>  
<td>

The data will not be stored after the end of the experiment.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Management**

</th> </tr>  
<tr>  
<td>

_**What regulation / legislation is followed by the experiment to protect data
and user privacy?** _

</td> </tr>  
<tr>  
<td>

National legislation and rules about video experiments will be followed. In
France, where the experiment will be conducted, guidelines edited by the local
authority the CNIL (Commission Nationale de l'Informatique et des Libertés)
will be taken into account.

</td> </tr>  
<tr>  
<td>

_**Who has access to the data for management purpose?** _

</td> </tr>  
<tr>  
<td>

Only the experimenters will have access to stored data.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data management?** _

</td> </tr>  
<tr>  
<td>

An admin with login and password system will be used to access to the data.

</td> </tr> </table>

7.2.2.2. PTL – Using actuator based on interpreting the scene using a smart
camera  
  
<table>  
<tr>  
<th>

**Data Collection**

</th> </tr>  
<tr>  
<td>

_**What data is collected for the experiment?** _

</td> </tr>  
<tr>  
<td>

The collected data are mainly from video data. Video frames are neither stored
nor transmitted.

</td> </tr>  
<tr>  
<td>

_**How is the data collected?** _

</td> </tr>  
<tr>  
<td>

The image sensors being involved can be of different natures. The only
information that is stored or transmitted corresponds to anonymized image
features.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data collection phase?** _

</td> </tr>  
<tr>  
<td>

No image frame is neither stored nor transmitted. Background images or image
features are transmitted via secured protocols. Depending on privacy issues,
transmitted image features can be shared using an encryption technique.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Storage**

</th> </tr>  
<tr>  
<td>

_**How and where are the data stored?** _

</td> </tr>  
<tr>  
<td>

To Be Determined

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data storage?** _

</td> </tr>  
<tr>  
<td>

To Be Determined

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Usage**

</th> </tr>  
<tr>  
<td>

_**What are the data used for?** _

</td> </tr>  
<tr>  
<td>

The data are used for statistics and monitoring.

</td> </tr>  
<tr>  
<td>

_**Are you using profiling techniques?** _

</td> </tr>  
<tr>  
<td>

Profiling technique is not planned because not needed by target applications.

</td> </tr>  
<tr>  
<td>

_**Are you verifying the data?** _

</td> </tr>  
<tr>  
<td>

For the moment, no procedure is defined to verify the collected data.

</td> </tr>  
<tr>  
<td>

_**Are you considering secondary/future use?** _

</td> </tr>  
<tr>  
<td>

No future use of collected data is planned.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Sharing**

</th> </tr>  
<tr>  
<td>

_**Are you sending/sharing the collecting data with a third party or
publishing the data?** _

</td> </tr>  
<tr>  
<td>

The data will not be made available to third parties.

</td> </tr>  
<tr>  
<td>

_**How is data exchange with third party protected?** _

</td> </tr>  
<tr>  
<td>

**\--**

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Destruction**

</th> </tr>  
<tr>  
<td>

_**How long is data stored?** _

</td> </tr>  
<tr>  
<td>

The data will not be stored after the end of the experiment.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Management**

</th> </tr>  
<tr>  
<td>

_**What regulation / legislation is followed by the experiment to protect data
and user privacy?** _

</td> </tr>  
<tr>  
<td>

National legislation and rules about video experiments will be followed. In
France, where the experiment will be conducted, guidelines edited by the local
authority the CNIL (Commission Nationale de l'Informatique et des Libertés)
will be taken into account.

</td> </tr>  
<tr>  
<td>

_**Who has access to the data for management purpose?** _

</td> </tr>  
<tr>  
<td>

Only the experimenters will have access to stored data.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data management?** _

</td> </tr>  
<tr>  
<td>

An admin with login andpassword system will be used to access to the data.

</td> </tr> </table>

7.2.2.3. ATR DC – Cold storage geo replication  
  
<table>  
<tr>  
<th>

**Data Collection**

</th> </tr>  
<tr>  
<td>

_**What data is collected for the experiment?** _

</td> </tr>  
<tr>  
<td>

Describe in particular what type of data is collected: are you collecting:

  * IoT data (Log information, SNS, etc…) 

  

  * Sensitive personal data are not included. 

  

  * Location information is essential for geo-replication. 

  

  * Users with at least two data center share the data. 

  

</td> </tr>  
<tr>  
<td>

_**How is the data collected?** _

</td> </tr>  
<tr>  
<td>

Describe what process you use for the data collection?

\- IoT data are replicated with at least two data centers.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data collection phase?** _

</td> </tr>  
<tr>  
<td>

IoT data including log information are stored in the cold storage (Tape, Blu-
ray, etc) and secured managed.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Storage**

</th> </tr>  
<tr>  
<td>

_**How and where are the data stored?** _

</td> </tr>  
<tr>  
<td>

The data are stored in at least two data centers as cold data.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data storage?** _

</td> </tr>  
<tr>  
<td>

Encryption is applied.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Usage**

</th> </tr>  
<tr>  
<td>

_**What are the data used for?** _

</td> </tr>  
<tr>  
<td>

Archiving cold data for several users.

</td> </tr>  
<tr>  
<td>

_**Are you using profiling techniques?** _

</td> </tr>  
<tr>  
<td>

Profiling of IoT data is required.

</td> </tr>  
<tr>  
<td>

_**Are you verifying the data?** _

</td> </tr>  
<tr>  
<td>

No, the verification is not essential for Cold-storage replication.

</td> </tr>  
<tr>  
<td>

_**Are you considering secondary/future use?** _

</td> </tr>  
<tr>  
<td>

The algo **ri** thm developed is opened to public as OSS.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Sharing**

</th> </tr>  
<tr>  
<td>

_**Are you sending/sharing the collecting data with a third party or
publishing the data?** _

</td> </tr>  
<tr>  
<td>

The data is not opened. The algorithm of cold data replication developed is
opened to public as OSS.

</td> </tr>  
<tr>  
<td>

_**How is data exchange with third party protected?** _

</td> </tr>  
<tr>  
<td>

The data is not opened. The algorithm of cold data replication developed is
opened to public as OSS.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Destruction**

</th> </tr>  
<tr>  
<td>

_**How long is data stored?** _

</td> </tr>  
<tr>  
<td>

Cold data is stored at least 10 years

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Management**

</th> </tr>  
<tr>  
<td>

_**What regulation / legislation is followed by the experiment to protect data
and user privacy?** _

</td> </tr>  
<tr>  
<td>

No regulation.

</td> </tr>  
<tr>  
<td>

_**Who has access to the data for management purpose?** _

</td> </tr>  
<tr>  
<td>

The Cold data are not opened.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data management?** _

</td> </tr>  
<tr>  
<td>

The Cold data are not opened.

</td> </tr> </table>

7.2.2.4. iHouse – Smart House

#####  **Data Collection**  
  
<table>  
<tr>  
<th>

_**What data is collected for the experiment?** _

</th> </tr>  
<tr>  
<td>

Data from sensors in iHouse is collected, such as temperature, humidity, door
open/close information, illuminance, power consumption of each device, power
generation by solar panels, power data of battery, wind, rain, and so on.

</td> </tr>  
<tr>  
<td>

_**How is the data collected?** _

</td> </tr>  
<tr>  
<td>

For each data, designated sensors are utilized. The data is collected by
wireless/wired network using communication protocols such as ECHONET Lite
protocol and IEEE1888, with openHAB protocol bindings.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data collection phase?** _

</td> </tr>  
<tr>  
<td>

Data transmission to outside networks from iHouse is conducted by IEEE1888
protocol that generated encrypted path with enough security.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Storage**

</th> </tr>  
<tr>  
<td>

_**How and where are the data stored?** _

</td> </tr>  
<tr>  
<td>

The data is stored at SQL server at NICT JOSE VM, and local storage servers on
OSK for data analysis.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data storage?** _

</td> </tr>  
<tr>  
<td>

Both storage servers are behind the strong firewall so that the restricted
access is only permitted.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Usage**

</th> </tr>  
<tr>  
<td>

_**What are the data used for?** _

</td> </tr>  
<tr>  
<td>

The data is used for energy monitoring and control of home appliances in
iHouse. Also, the collected data is analyzed for finding various relationships
among appliances for further smart house controls.

</td> </tr>  
<tr>  
<td>

_**Are you using profiling techniques?** _

</td> </tr>  
<tr>  
<td>

No

</td> </tr>  
<tr>  
<td>

_**Are you verifying the data?** _

</td> </tr>  
<tr>  
<td>

Various statistical methods are exploited for finding relationships among each
data. On that process, the data is verified.

</td> </tr>  
<tr>  
<td>

_**Are you considering secondary/future use?** _

</td> </tr>  
<tr>  
<td>

No.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Sharing**

</th> </tr>  
<tr>  
<td>

_**Are you sending/sharing the collecting data with a third party or
publishing the data?** _

</td> </tr>  
<tr>  
<td>

Making the collected data to be open data is under discussion with NICT, that
is an original data holder. For publishing journal papers and conference
presentations, only statistically summarized data is utilized.

</td> </tr>  
<tr>  
<td>

_**How is data exchange with third party protected?** _

</td> </tr>  
<tr>  
<td>

JOSE CKAN platform will be used for publishing data as open data.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Destruction**

</th> </tr>  
<tr>  
<td>

_**How long is data stored?** _

</td> </tr>  
<tr>  
<td>

The data will be stored until the end of FESTIVAL project (e.g. M36).

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Management**

</th> </tr>  
<tr>  
<td>

_**What regulation / legislation is followed by the experiment to protect data
and user privacy?** _

</td> </tr>  
<tr>  
<td>

Nothing to be noted.

</td> </tr>  
<tr>  
<td>

_**Who has access to the data for management purpose?** _

</td> </tr>  
<tr>  
<td>

Only researchers of the FESTIVAL project can access data.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data management?** _

</td> </tr>  
<tr>  
<td>

Storage servers are behind the strong firewall so that the restricted access
with secure protocols such as IEEE1888 and ssh is only permitted.

</td> </tr> </table>

7.2.2.5. Smart Station at Maya  
  
<table>  
<tr>  
<th>

**Data Collection**

</th> </tr>  
<tr>  
<td>

_**What data is collected for the experiment?** _

</td> </tr>  
<tr>  
<td>

\- Amount of solar power generation. - Amount of reduce CO2.

</td> </tr>  
<tr>  
<td>

  * Current temperature. 

  

  * Weather of region. 

  

  * Amount of pollen. 

  

  * Bus access information at Maya Station. 

  

</td> </tr>  
<tr>  
<td>

_**How is the data collected?** _

</td> </tr>  
<tr>  
<td>

  * _What sensors are you using?_

  

  * Iberium _sensor, Wi-Fi packet sensor._

  

  * _Are you requesting the data directly from the user?_

  

  * No we are requesting the data directly. 

  

  * _Are you using external data sources?_

  

  * Under review. 

  

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data collection phase?** _

</td> </tr>  
<tr>  
<td>

The data will be password protected and the computer network access will be
restricted.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Storage**

</th> </tr>  
<tr>  
<td>

_**How and where are the data stored?** _

</td> </tr>  
<tr>  
<td>

Under review.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data storage?** _

</td> </tr>  
<tr>  
<td>

Under review.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Usage**

</th> </tr>  
<tr>  
<td>

_**What are the data used for?** _

</td> </tr>  
<tr>  
<td>

We provide useful information about Maya Station. Watching digital signage in
front of the train gates, users can get information about temperature,
weather, solar power generation, bus access information and so on.

</td> </tr>  
<tr>  
<td>

_**Are you using profiling techniques?** _

</td> </tr>  
<tr>  
<td>

No profiling technique used.

</td> </tr>  
<tr>  
<td>

_**Are you verifying the data?** _

</td> </tr>  
<tr>  
<td>

We are going to verify the data such as searching information to use digital
signage at Maya Station.

</td> </tr>  
<tr>  
<td>

_**Are you considering secondary/future use?** _

</td> </tr> </table>

We do not consider it at the moment.  
  
<table>  
<tr>  
<th>

**Data Sharing**

</th> </tr>  
<tr>  
<td>

_**Are you sending/sharing the collecting data with a third party or
publishing the data?** _

</td> </tr>  
<tr>  
<td>

We do not consider sending/sharing the collecting data with others at the
moment, because now we are unconfident to collect accurate data at Maya
Station and now we do not recognize the importance and the usefulness for our
collecting information at Maya Station. If the experiment of Maya Station is
successful, we will start to consider about sending/sharing the collecting
data with others.

</td> </tr>  
<tr>  
<td>

_**How is data exchange with third party protected?** _

</td> </tr>  
<tr>  
<td>

Undecided.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Destruction**

</th> </tr>  
<tr>  
<td>

_**How long is data stored?** _

</td> </tr>  
<tr>  
<td>

Undecided.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Management**

</th> </tr>  
<tr>  
<td>

_**What regulation / legislation is followed by the experiment to protect data
and user privacy?** _

</td> </tr>  
<tr>  
<td>

For personal information is not treated in Maya Station experiment, we
measures for the protection of personal information is not carried out. Jcomm
has acquired the Privacy Mark defined by JIPDEC.

If we need to treat personal information in future, we handling in accordance
with the Privacy Mark.

</td> </tr>  
<tr>  
<td>

_**Who has access to the data for management purpose?** _

</td> </tr>  
<tr>  
<td>

Personal information handling manager of Jcomm and people who permitted to
treat personal information from handling manager of Jcomm

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data management?** _

</td> </tr>  
<tr>  
<td>

Undecided.

</td> </tr> </table>

######  7.2.3. Smart Shopping

7.2.3.1. Knowledge Capital – Smart Shopping system and recommendation analysis  
  
<table>  
<tr>  
<th>

**Data Collection**

</th> </tr>  
<tr>  
<td>

_**What data is collected for the experiment?** _

</td> </tr>  
<tr>  
<td>

We will collect direct personal data (name, phone number, email address) and
location information of users inside of the Lab. in Knowledge Capital.

</td> </tr>  
<tr>  
<td>

_**How is the data collected?** _

</td> </tr>  
<tr>  
<td>

Direct personal data: we collect the direct personal data directly by the
users.

Location information of users: we collect the location information of the
users by using Beacon signals.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data collection phase?** _

</td> </tr>  
<tr>  
<td>

Direct personal data: We keep the direct personal data only written in papers
not stored in computer systems so that the data will never be copied and used
by other purposes.

Location information of users: We anonymize the location information of users
so that the data does not contain any direct persona data.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Storage**

</th> </tr>  
<tr>  
<td>

_**How and where are the data stored?** _

</td> </tr>  
<tr>  
<td>

Direct personal data: We keep the direct personal data only written in papers.

Location information of users: We store Location information of users in a
distributed file system.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data storage?** _

</td> </tr>  
<tr>  
<td>

Direct personal data: Only the managers of the experiments can access to the
direct personal data written in papers.

Location information of users **:** Authorization is required for the data
access.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Usage**

</th> </tr>  
<tr>  
<td>

_**What are the data used for?** _

</td> </tr>  
<tr>  
<td>

Direct personal data: we need the contact information of the users (direct
personal data), because we provide the users the iPad mini during the
experiments and we have to contact the users in case they may steal the iPad
mini.

Location information of users: The location information of the users is used
for the recommendation service.

</td> </tr>  
<tr>  
<td>

_**Are you using profiling techniques?** _

</td> </tr>  
<tr>  
<td>

No.

</td> </tr>  
<tr>  
<td>

_**Are you verifying the data?** _

</td> </tr>  
<tr>  
<td>

Direct personal data: We validate the data manually.

Location information of users: We will install the Beacon devices properly in
the Lab. so that they provide us good quality of the user locations.

</td> </tr>  
<tr>  
<td>

_**Are you considering secondary/future use?** _

</td> </tr>  
<tr>  
<td>

Basically we will not consider secondary use of the raw data. But, we compute
the statistics of the location information of users (not personal data any
more) and make it as an open research data.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Sharing**

</th> </tr>  
<tr>  
<td>

_**Are you sending/sharing the collecting data with a third party or
publishing the data?** _

</td> </tr>  
<tr>  
<td>

We will share the statistics of the location information of users as an open
research data. We make the data public so that other users can make analysis
over the data.

</td> </tr>  
<tr>  
<td>

_**How is data exchange with third party protected?** _

</td> </tr>  
<tr>  
<td>

The statistic is open to everyone (no protection).

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Destruction**

</th> </tr>  
<tr>  
<td>

_**How long is data stored?** _

</td> </tr>  
<tr>  
<td>

The data is kept during the life time of the FESTIVAL project.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Management**

</th> </tr>  
<tr>  
<td>

_**What regulation / legislation is followed by the experiment to protect data
and user privacy?** _

</td> </tr>  
<tr>  
<td>

We have to follow the privacy data management law in Japan for the direct
personal data and location information of users.

</td> </tr>  
<tr>  
<td>

_**Who has access to the data for management purpose?** _

</td> </tr>  
<tr>  
<td>

The managers of the experiments.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data management?** _

</td> </tr>  
<tr>  
<td>

The direct personal data is not store in computer systems. Authentication is
used for the Location information of users.

</td> </tr> </table>

7.2.3.2. Santander – Connected Shops  
  
<table>  
<tr>  
<th>

**Data Collection**

</th> </tr>  
<tr>  
<td>

_**What data is collected for the experiment?** _

</td> </tr>  
<tr>  
<td>

This experiment will collect environmental data such as temperature or
humidity.

Furthermore, the experiment will also collect the SNR data from the signals
sent by the devices within the deployment area, which will make possible the
positioning of the devices.

</td> </tr>  
<tr>  
<td>

_**How is the data collected?** _

</td> </tr>  
<tr>  
<td>

_What sensors are you using?_

The SNR from WiFi and BT signals are collected using both radio interfaces
located in several points in the deployment. Additionally, temperature and
humidity sensors will be also used.

_Are you requesting the data directly from the user?_

No.

_Are you using external data sources?_

SmartSantander environmental data will be also available to be accessed.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data collection phase?** _

</td> </tr>  
<tr>  
<td>

Data will be collected and anonymized locally using secure hash algorithms,
before being sent to the SmartSantander platform. The devices will be
connected to internet through the municipality network (what is behind a
firewall only accessible for specific machines). Stored data will be only
accessible through the EaaS federation platform or the SmartSantander using an
X509 certificate for authentication _._

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Storage**

</th> </tr>  
<tr>  
<td>

_**How and where are the data stored?** _

</td> </tr>  
<tr>  
<td>

The data is stored using the IoT API (RESTful API) in SmartSantander. The
storage facility is located in the UC premises and it is based in a Mongo
database engine.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data storage?** _

</td> </tr>  
<tr>  
<td>

Data access will only be possible through the IoT API (RESTful API) in
SmartSantander. Authentication is based in an x509 based certificate for
authentication. The Machines storing the data are only accessible from a
specific IPs.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Usage**

</th> </tr>  
<tr>  
<td>

_**What are the data used for?** _

</td> </tr>  
<tr>  
<td>

Data collected will be used to provide useful information to the shop owners
about customer’s behavior. Additionally, environmental data will be also
delivered to the customers.

</td> </tr>  
<tr>  
<td>

_**Are you using profiling techniques?** _

</td> </tr>  
<tr>  
<td>

Users can never be identified but some profiling techniques can be applied to
recognize when the same user has accessed to the shopping area.

</td> </tr>  
<tr>  
<td>

_**Are you verifying the data?** _

</td> </tr>  
<tr>  
<td>

Data quality cannot be verified by common means. Only strange behaviors (e.g.
SNR surpass certain limits) can be inferred to discard wrong measurements.

</td> </tr>  
<tr>  
<td>

_**Are you considering secondary/future use?** _

</td> </tr>  
<tr>  
<td>

At the moment no future use is being considered.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Sharing**

</th> </tr>  
<tr>  
<td>

_**Are you sending/sharing the collecting data with a third party or
publishing the data?** _

</td> </tr>  
<tr>  
<td>

Data will be available through the federation of FESTIVAL EaaS. External
experimenters will be able to access to the data but authorization must be
given from UC/Santander municipality. Future results from the experiments made
on top of that data will be also shared with the shop owners regarding the
number of people in the market, people preferences, etc.

</td> </tr>  
<tr>  
<td>

_**How is data exchange with third party protected?** _

</td> </tr>  
<tr>  
<td>

In SmartSantander, authentication is made through x509 based certificates and
it will also be used to authorize the experimenters to use corresponding
resources. Data will be also delivered using HTTPS (SSL/TLS).

In EaaS, the information will be secured using the platform methods.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Destruction**

</th> </tr>  
<tr>  
<td>

_**How long is data stored?** _

</td> </tr>  
<tr>  
<td>

There is no time limit to destroy data. In principle, it is considered to be
stored two years.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Management**

</th> </tr>  
<tr>  
<td>

_**What regulation / legislation is followed by the experiment to protect data
and user privacy?** _

</td> </tr>  
<tr>  
<td>

We have inquired Data Protection Office about the use of anonymized MAC
address in Smart Shopping use case, in order to know if it is considered
private/personal information or not. Other experiences in Spain shows that MAC
address are not personal data.

</td> </tr>  
<tr>  
<td>

_**Who has access to the data for management purpose?** _

</td> </tr>  
<tr>  
<td>

UC and Santander municipality will have access for management purposes.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data management?** _

</td> </tr>  
<tr>  
<td>

Authentication and authorization are made using the same methods as they were
external experimenters, but with management permissions.

</td> </tr> </table>

7.2.3.3. Santander – Advertised Premium Discounts  
  
<table>  
<tr>  
<th>

**Data Collection**

</th> </tr>  
<tr>  
<td>

_**What data is collected for the experiment?** _

</td> </tr>  
<tr>  
<td>

During the experiment there will be collected shop offers what are all
publicly available. Additionally, customers will provide feedback about the
offers and the shop environment.

</td> </tr>  
<tr>  
<td>

_**How is the data collected?** _

</td> </tr> </table>  
<table>  
<tr>  
<th>

Data is gathered through a web application and the smartphones (shop offers)
and smartphones (customer feedback).

</th> </tr>  
<tr>  
<td>

_**Describe security measures used in the data collection phase?** _

</td> </tr>  
<tr>  
<td>

Data will be collected and sent using SSL/TLS encryption from the smartphones.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Storage**

</th> </tr>  
<tr>  
<td>

_**How and where are the data stored?** _

</td> </tr>  
<tr>  
<td>

At the time being, shop offers are stored depending on the source, some in the
municipality facilities and other in the UC premises. Customer feedbacks will
be stored in the UC.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data storage?** _

</td> </tr>  
<tr>  
<td>

Data access will only be possible through the IoT API (RESTful API) in
SmartSantander. Authentication is based in an x509 based certificate for
authentication. The Machines storing the data are only accessible from a
specific IPs.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Usage**

</th> </tr>  
<tr>  
<td>

_**What are the data used for?** _

</td> </tr>  
<tr>  
<td>

The goal of the application is to provide premium offers to the customers
based on their location. Additionally, data will provide a way to improve the
shop conditions to the owners.

</td> </tr>  
<tr>  
<td>

_**Are you using profiling techniques?** _

</td> </tr>  
<tr>  
<td>

No, but application users will have access to their own feedback.

</td> </tr>  
<tr>  
<td>

_**Are you verifying the data?** _

</td> </tr>  
<tr>  
<td>

Only registered shops can send offers to the platform. Users can be banned if
the system detects pernicious content.

</td> </tr>  
<tr>  
<td>

_**Are you considering secondary/future use?** _

</td> </tr>  
<tr>  
<td>

No at this moment.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Destruction**

</th> </tr>  
<tr>  
<td>

_**How long is data stored?** _

</td> </tr>  
<tr>  
<td>

Shop offers are stored at least until the offer is expired. Customer feedback
will also be accessible with no restriction at the moment.

</td> </tr> </table>  
<table>  
<tr>  
<th>

Shop offers are publicly available. Customer’s feedback is shared with the
shop owners.

</th> </tr>  
<tr>  
<td>

_**How is data exchange with third party protected?** _

</td> </tr>  
<tr>  
<td>

Open data can be freely accessed.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Management**

</th> </tr>  
<tr>  
<td>

_**What regulation / legislation is followed by the experiment to protect data
and user privacy?** _

</td> </tr>  
<tr>  
<td>

No personal data is stored so it fulfil the Spanish regulation regarding
personal data protection.

</td> </tr>  
<tr>  
<td>

_**Who has access to the data for management purpose?** _

</td> </tr>  
<tr>  
<td>

UC and Santander municipality will have access for management purposes.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data management?** _

</td> </tr>  
<tr>  
<td>

Authentication and authorization is made using the same methods as they were
external experimenters, but with management permissions.

</td> </tr> </table>

######  7.2.4. Multi-domain

7.2.4.1. JOSE/JOSE (Japan-wise Orchestrated Smart/Sensor Environment)  
  
<table>  
<tr>  
<th>

**Data Collection**

</th> </tr>  
<tr>  
<td>

_**What data is collected for the experiment?** _

</td> </tr>  
<tr>  
<td>

This experiment itself will collect only logs from components of the system.
Experimenter users on this experiment system will collect their own data.

</td> </tr>  
<tr>  
<td>

_**How is the data collected?** _

</td> </tr>  
<tr>  
<td>

Each components of the system will output logs to the system storage.

Experimenter users on this experiment system will collect data by their own
measures

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data collection phase?** _

</td> </tr>  
<tr>  
<td>

Logs will be collected on securely protected machines (authorization needed to
log into the machines) and transferred only by encrypted (by SSL/TLS/SSH)
connection. Experimenter users on this experiment system should use secure
measures in the data collection phase.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Storage**

</th> </tr>  
<tr>  
<td>

_**How and where are the data stored?** _

</td> </tr>  
<tr>  
<td>

Data (logs and user data) will be stored on storage servers provided by JOSE
testbed. Each server is placed at one of data centers of NICT in Japan.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data storage?** _

</td> </tr>  
<tr>  
<td>

Only authorized users can access to the machines providing storage.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Usage**

</th> </tr>  
<tr>  
<td>

_**What are the data used for?** _

</td> </tr>  
<tr>  
<td>

Logs will be used for maintaining and tuning of the experiment system.
Experimenter users may have their own goal.

</td> </tr>  
<tr>  
<td>

_**Are you using profiling techniques?** _

</td> </tr>  
<tr>  
<td>

No, but experimenter users on the system may use profiling techniques on their
own data.

</td> </tr>  
<tr>  
<td>

_**Are you verifying the data?** _

</td> </tr>  
<tr>  
<td>

No for the logs, but experimenter users may have their own verification
process of their data.

</td> </tr>  
<tr>  
<td>

_**Are you considering secondary/future use?** _

</td> </tr>  
<tr>  
<td>

Logs may also be used for collecting statistical information of the system
usage.

</td> </tr>  
<tr>  
<td>

Logs will not be shared with third parties and not be published. Statistical
information may be published as a part of future Deliverables. Experimenter
users on the system may have their own sharing policy for their data.

</td> </tr>  
<tr>  
<td>

_**How is data exchange with third party protected?** _

</td> </tr>  
<tr>  
<td>

Logs will not be exchanged with third parties. Experimenter users on the
system may have their own data exchanging policy for their data.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Destruction**

</th> </tr>  
<tr>  
<td>

_**How long is data stored?** _

</td> </tr>  
<tr>  
<td>

Undecided. Logs may be saved as long as the system is operating. Experimenter
users on the system will have their own storing periods of their data.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Collection**

</th> </tr>  
<tr>  
<td>

_**What data is collected for the experiment?** _

</td> </tr>  
<tr>  
<td>

The FIWARE lab will support multi-domain experiment in which will be collected
specific information. From the point of the FIWARE-lab usage will be collected
system logs related to performance or security or for statistical reasons.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Management**

</th> </tr>  
<tr>  
<td>

_**What regulation / legislation is followed by the experiment to protect data
and user privacy?** _

</td> </tr>  
<tr>  
<td>

No personal data will be stored on this experiment system. So we will not be
subject to Japanese Act on the Protection of Personal Information.

</td> </tr>  
<tr>  
<td>

_**Who has access to the data for management purpose?** _

</td> </tr>  
<tr>  
<td>

The operators of the experiment system from ACUTUS have access to the logs.
Experimenter users will have their own policy for management of their data.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data management?** _

</td> </tr>  
<tr>  
<td>

Authentication and authorization are needed for managing data on the system.

</td> </tr> </table>

7.2.4.2. Engineering FIWARE-lab  
  
<table>  
<tr>  
<th>

_**How is the data collected?** _

</th> </tr>  
<tr>  
<td>

The data are collected internally by the FIWARE-lab system components.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data collection phase?** _

</td> </tr>  
<tr>  
<td>

Logs will be collected on securely protected machines (authorization needed to
log into the machines) and transferred only by encrypted (by SSL/TLS/SSH)
connection.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Storage**

</th> </tr>  
<tr>  
<td>

_**How and where are the data stored?** _

</td> </tr>  
<tr>  
<td>

The data will be collected by log components and stored in specific database
located in the same infrastructure of FIWARE-lab.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data storage?** _

</td> </tr>  
<tr>  
<td>

The data will be accessible only for authorized users.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Usage**

</th> </tr>  
<tr>  
<td>

_**What are the data used for?** _

</td> </tr>  
<tr>  
<td>

The log data provided by FIWARE-lab will be used to monitor system
performance, for maintenance reasons (e.g. identifications of bug/errors) and
for security reasons (monitor access and authorization to the
functionalities).

</td> </tr>  
<tr>  
<td>

_**Are you using profiling techniques?** _

</td> </tr>  
<tr>  
<td>

No, but experimenter users on the system may use profiling techniques on their
own data.

</td> </tr>  
<tr>  
<td>

_**Are you verifying the data?** _

</td> </tr>  
<tr>  
<td>

No for the logs, but experimenter users may have their own verification
process of their data.

</td> </tr>  
<tr>  
<td>

_**Are you considering secondary/future use?** _

</td> </tr>  
<tr>  
<td>

The data will be also used to calculate specific KPI.

</td> </tr>  
<tr>  
<td>

Data will not be shared with third parties and not be published. Statistical
information may be published as a part of future Deliverables. Experimenter
users on the system may have their own sharing policy for their data.

</td> </tr>  
<tr>  
<td>

_**How is data exchange with third party protected?** _

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Destruction**

</th> </tr>  
<tr>  
<td>

_**How long is data stored?** _

</td> </tr>  
<tr>  
<td>

Undecided. Logs may be saved as long as the system is operating. Experimenter
users on the system will have their own storing periods of their data.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Management**

</th> </tr>  
<tr>  
<td>

_**What regulation / legislation is followed by the experiment to protect data
and user privacy?** _

</td> </tr>  
<tr>  
<td>

Italian and European regulation will be followed.

</td> </tr>  
<tr>  
<td>

_**Who has access to the data for management purpose?** _

</td> </tr>  
<tr>  
<td>

The FIWARE-lab system administrator will have the access to the information.
Part of the information can be also accessible by the experimenters.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data management?** _

</td> </tr>  
<tr>  
<td>

Authentication and authorization are needed for managing data on the system.

</td> </tr> </table>

7.2.4.3. IoT based experiment over a federated domain  
  
<table>  
<tr>  
<th>

**Data Collection**

</th> </tr>  
<tr>  
<td>

_**What data is collected for the experiment?** _

</td> </tr>  
<tr>  
<td>

No data are collected for the experiments. Federation experiment is made with
legacy data from testbeds.

</td> </tr>  
<tr>  
<td>

_**How is the data collected?** _

</td> </tr> </table>  
<table>  
<tr>  
<th>

It depends on the testbed involved. SmartSantander data are collected from
deployed sensors.

</th> </tr>  
<tr>  
<td>

_**Describe security measures used in the data collection phase?** _

</td> </tr>  
<tr>  
<td>

Data is collected using the SmartSantander network. Most gateways access
internet through the internet.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Storage**

</th> </tr>  
<tr>  
<td>

_**How and where are the data stored?** _

</td> </tr>  
<tr>  
<td>

Data storage depends on the facility. In SmartSantander data is stored in a
mongo database which is located in the UC premises.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data storage?** _

</td> </tr>  
<tr>  
<td>

It depends on the testbed, but in a close future security access layer will
depend on the EaaS.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Usage**

</th> </tr>  
<tr>  
<td>

_**What are the data used for?** _

</td> </tr>  
<tr>  
<td>

Data will be used for the experimenters which access to the EaaS.

</td> </tr>  
<tr>  
<td>

_**Are you using profiling techniques?** _

</td> </tr>  
<tr>  
<td>

No.

</td> </tr>  
<tr>  
<td>

_**Are you verifying the data?** _

</td> </tr>  
<tr>  
<td>

Data is gathered from sensors but verification depends on the testbed. Several
reasonable limit can be set to know whether a sensor is broken or not.

</td> </tr>  
<tr>  
<td>

_**Are you considering secondary/future use?** _

</td> </tr>  
<tr>  
<td>

Automated links for data and VMs will be used under the EaaS in a future.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Sharing**

</th> </tr>  
<tr>  
<td>

_**Are you sending/sharing the collecting data with a third party or
publishing the data?** _

</td> </tr>  
<tr>  
<td>

Data from testbeds will be shared with the experimenters who have access.

</td> </tr>  
<tr>  
<td>

_**How is data exchange with third party protected?** _

</td> </tr>  
<tr>  
<td>

It depends on the testbed. In SmartSantander, authentication is made through
x509 based certificates and it will also be used to authorize the
experimenters to use corresponding resources. Data will be also delivered
using HTTPS (SSL/TLS).

In EaaS, the information will be secured using the platform methods.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Destruction**

</th> </tr>  
<tr>  
<td>

_**How long is data stored?** _

</td> </tr>  
<tr>  
<td>

There is no limit at the moment for data storage.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Management**

</th> </tr>  
<tr>  
<td>

_**What regulation / legislation is followed by the experiment to protect data
and user privacy?** _

</td> </tr>  
<tr>  
<td>

The experiment will follow the regulation of the EaaS.

</td> </tr>  
<tr>  
<td>

_**Who has access to the data for management purpose?** _

</td> </tr>  
<tr>  
<td>

Each testbed will have its own managers. UC will manage SmartSantander data.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data management?** _

</td> </tr>  
<tr>  
<td>

It depends on the testbed. Authentication and authorization is made using the
same methods as they were external experimenters, but with management
permissions.

</td> </tr> </table>

7.2.4.4. Messaging/Storage/Visualization platform federation use case  
  
<table>  
<tr>  
<th>

**Data Collection**

</th> </tr>  
<tr>  
<td>

_**What data is collected for the experiment?** _

</td> </tr>  
<tr>  
<td>

This experiment itself will collect only logs from components of the federated
platform. Experimenters using the platform of this federation experiment will
collect their own data

</td> </tr>  
<tr>  
<td>

_**How is the data collected?** _

</td> </tr>  
<tr>  
<td>

Each components of the federated platform will output logs to the system
storage.

\- Experimenters using platform of this federation experiment will collect
data by their own measures

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data collection phase?** _

</td> </tr>  
<tr>  
<td>

Logs will be collected on securely protected machines (authorization needed to
log into the machines) and transferred only by encrypted (by SSL/TLS/SSH)
connection. Experimenters using the platform of this federation experiment
should use secure measures in the data collection phase.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Storage**

</th> </tr>  
<tr>  
<td>

_**How and where are the data stored?** _

</td> </tr>  
<tr>  
<td>

Data (logs and user data) will be stored on storage servers provided by JOSE
testbed and CKP Umekita Network testbed. Each server is placed at one of data
centers of NICT and CKP dojima data center in Japan

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data storage?** _

</td> </tr>  
<tr>  
<td>

Only authorized users can access to the machines providing storage.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Usage**

</th> </tr>  
<tr>  
<td>

_**What are the data used for?** _

</td> </tr>  
<tr>  
<td>

Logs will be used for maintaining and tuning of the experiment system.
Experimenters may have their own goal.

</td> </tr>  
<tr>  
<td>

_**Are you using profiling techniques?** _

</td> </tr>  
<tr>  
<td>

No, but experimenters using the federated platform may use profiling
techniques on their own data.

</td> </tr>  
<tr>  
<td>

_**Are you verifying the data?** _

</td> </tr>  
<tr>  
<td>

No for the logs, but experimenters may have their own verification process of
their data.

</td> </tr>  
<tr>  
<td>

_**Are you considering secondary/future use?** _

</td> </tr>  
<tr>  
<td>

Logs may also be used for collecting statistical information of the system
usage.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Sharing**

</th> </tr>  
<tr>  
<td>

_**Are you sending/sharing the collecting data with a third party or
publishing the data?** _

</td> </tr>  
<tr>  
<td>

Logs will not be shared with third parties and not be published. Statistical
information may be published as a part of future Deliverables. Experimenters
using federated platform may have their own sharing policy for their data.

</td> </tr>  
<tr>  
<td>

_**How is data exchange with third party protected?** _

</td> </tr>  
<tr>  
<td>

Logs will not be exchanged with third parties. Experimenters using federated
platform may have their own data exchanging policy for their data.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Destruction**

</th> </tr>  
<tr>  
<td>

_**How long is data stored?** _

</td> </tr>  
<tr>  
<td>

Undecided. Logs may be saved as long as the system is operating. Experimenters
using federated platform will have their own storing periods of their data.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Data Management**

</th> </tr>  
<tr>  
<td>

_**What regulation / legislation is followed by the experiment to protect data
and user privacy?** _

</td> </tr>  
<tr>  
<td>

Currently, we have no plan to store personal data into the federated platform.
So we will not be subject to Japanese Act on the Protection of Personal
Information.

</td> </tr>  
<tr>  
<td>

_**Who has access to the data for management purpose?** _

</td> </tr>  
<tr>  
<td>

The KSU/ACUTUS operators of the federated platforms have access to the logs
which are generated by the shared platforms. Experimenters will have their own
policy for management of their data and the logs of their own platforms.

</td> </tr>  
<tr>  
<td>

_**Describe security measures used in the data management?** _

</td> </tr>  
<tr>  
<td>

Authentication and authorization are needed for managing data on the system.

</td> </tr> </table>

######  7.3. Contacts with Data Protection authorities

In this section we present the current state of the discussions with the
responsible Data Protection Authorities for the different project locations
that will be in contact with external participants to the project experiments.

7.3.1. PTL

Storage and manipulation of personal digital information are regulated by an
independent French organization known as _Commission Nationale de
l'informatique et des libertés_ (CNIL - http://www.cnil.fr/). From whom the
actual president is _Isabelle Falque-Pierrotin_ .

Thus, to ensure that the experiments are fully compliant with constraints
ruled by CNIL, regarding personal data collection, a legal entity with
expertise in this field has been contacted to provide the legal support on the
experimentation.

The administrative procedure to get a specific authorization might not be
required for the targeted applications at first. Thus, it is yet planned to
ask for an accreditation, notice that this accreditation might not be
necessary, the specific case required by the competent authority will be
promulgated in near future through another deliverable.

The delay for the authorization document from CNIL is estimated to be three
months. Thus, it is required three months of previous preparation before the
experiments take place.

7.3.2. TUBA

The Tuba depends also on the requirements of the French authority CNIL.

As for now, the GrandLyon Data platform contains only anonymized data and
therefore is in compliance with the CNIL guidelines.

Since the Data platform of GrandLyon is about Open Data, the data contained in
this platform should be kept anonymized and not contain personal data.
Otherwise, some private data should be created and a request/simplified
submission sent to the CNIL.

Delays are :

  * Special request : 3 months 

  

  * Simplified submission (if the request fits one established CNIL use case) : immediate 

  

7.3.3. Santander

In order to ensure what kind of treatment we should apply to data involved in
the Smart Shopping use cases, we have sent a query to the Spanish Data
Protection Office regarding the use of anonymized MAC address required by the
different functionalities to be developed in this area. As it was commented,
location, tracking and delivery of offers require capturing MAC address of
citizen devices, which is anonymized and erased, using from that moment, the
anonymized MAC. We have not received any answer by now.

In parallel and in order to know if there is any previous case similar to
ours, we have found a resolution from Spanish Data Protection Office related
to the use of anonymized MAC address. Zaragoza Municipality launched a project
to detect traffic congestion and estimate time spent by citizens driving in
the city, through the use of Bluetooth devices which detect MAC address of
smartphones. In this case, MAC address is also anonymized. The resolution says
that this data is not considered as private data, so it is not required to
apply Data Protection Law.

7.3.4. iHouse, ATR DC, and the Lab

For sensing data of iHouse, the agreement for data exploitation for FESTIVAL
project has been contracted. In addition for publishing as open data, the
discussion with NICT is undergoing.

####  8\. Europe – Japan differences

_In this section we present the main differences identified in this task
between European and Japanese approach to involvement of end users in
experiments and safeguard of privacy._

#####  8.1. Personal data and consent

Personal data in Japan has been protected by the Act on the Protection of
Personal Information (Act No. 57 of 2003) (APPI). The term “personal
information” is defined in the Article 2 (1) of the Act as “information about
a living individual which can identify the specific individual by name, date
of birth or other description contained in such information (including such
information as will allow easy reference to other information and will thereby
enable the identification of the specific individual).

English translation of Act on the Protection of Personal Information (Act No.
57 of 2003),  _http://www.cas.go.jp/jp/seisaku/hourei/data/APPI.pdf_

The amendment to APPI was approved in the House of Representatives in Japan on
September 3, 2015. One of the backgrounds of the amendment is that it was
inconvenient especially for commercial use and application of personal data by
companies because the range of personal information was not clearly defined in
APPI. So the definition of “personal information” is extended by the amendment
to include additional types of information related to the physical
characteristics of individuals such as fingerprint data and face recognition
data along with the numeric codes allocated to individuals such as passport
numbers and driver’s license numbers.

Another background is that the incidents related to personal information
leakage increased the concerns of people. Therefore, the amendment enhances
the protection of personal data by maintaining the traceability of the records
when the personal data is transferred to third parties as well as introducing
a new criminal penalty to deal with the misuse of personal data.

One of the notable features of the amendment is the establishment of a new
government authority named “Personal Information Protection Committee” on
January 2016 to ensure the protection of personal data as well as coping with
the cross-border transfer of personal data with countries that have a legal
system equivalent to the Japanese personal data protection system such as EU
member countries.

Regarding the data subject’s prior consent, Article 16 (Restriction by the
Purpose of Utilization) states that “a business operator handling personal
information shall not handle personal information about a person, without
obtaining the prior consent of the person” and Article 23 (Restriction of
Provision to A Third Party) also states that “A business operator handling
personal information shall not, except in the following cases, provide
personal data to a third party without obtaining the prior consent of the
person.”

However, how to obtain the prior consent is not specifically expressed in
APPI. In some business fields, certain ministries and government offices
responsible for the fields prepare certain guidelines to deal with personal
information and the way of obtaining the prior consent. For instance,
Financial Services Agency (FSA) defines “Guidelines for Personal Information
Protection in the Financial Field,” and Article 4 Regarding the Format of
Consent (relevant to Article 16 and 23 of the Law) states that “When acquiring
the consent of the person prescribed in Article 16 and 23 of the Law, entities
handling personal information in the financial field shall, in principle, do
so by document (including a record made by an electronic method, a magnetic
method, or any other method not recognizable to human senses. Hereinafter this
applies).” So, the “document” means not necessarily a paper document but also
includes any other digital alternatives including web-based systems obtaining
user’s consent.

Guidelines for Personal Information Protection in the Financial Field,
_http://www.fsa.go.jp/frtc/kenkyu/event/20070424_02.pdf_

Introduction of significant amendments to Japan’s Privacy Law,

_http://globalcompliancenews.com/introduction-of-significant-amendments-to-
japans-privacy-lawpublished-20150904/_

#####  8.2. Video Experiment

The use of camera in experiment is usually not done in Japanese experiments as
Japanese tend to refuse excessively captured body by the camera in a public
space.

NICT and Osaka station City had planned experiments using cameras to measure
the flow of people at JR Osaka station (in April, 2014). However the
experiment was cancelled due to opposition of station users and scholars. The
reasons of the opposition were that:

  * The users of JR Osaka Station and station building could not refuse to participate in the experiment without changing their commuting route. 

  

  * There is no personal information protection, etc. unified rules concerning experiment of public space. 

  

####  9\. Conclusions

_This section concludes the deliverable with lesson learned and plans for
future activities._

Over the first year the project has focused on creating a responsible
environment for involving end users and external experimenters in the project.

The context of the project experiments, and the associated risks towards
ethics and privacy has been studied carefully and although the project will
make very limited use of personal data and overall represent a very limited
ethical hazard in its research, a strong policy on the issue has been decided,
as a testimony of the importance of this issue for the consortium. The state
of the art in responsible research and innovation has been studied and the
project has defined its strategy to integrate some of its principles in the
project experiments.

The project has set up the infrastructure for its external participant
involvement, from factsheets aimed at raising the awareness on important
issues, to guidelines and processes for user consent, complaints and data
withdrawal, as well as a first scheme for Privacy and Security Impact
Assessment.

The project experiments, although they are still in the early process of their
own definition have all participated to this effort and provided a first
evaluation of their potential contacts and interactions with end users and of
the way they deal with data.

Over this process we have not only set up an operational environment for the
involvement of external participants to the project, but also increased our
knowledge on these issues and disseminated this knowledge in the consortium
and even outside (thanks to the first distributions of factsheets).

The project effort on this task will continue over the following period, to
pursue the effort already engaged and finalise the project infrastructure, but
also to gather feedbacks and improve our framework. As the project experiment
move into an operational phase and as the project opens up to external
experimenters, we foresee that this task will also progressively evolve into
an operation support task that will provide guidance to experimenters.