The document describes a learning package on a dynamic privacy model for web services, which proposes formalizing privacy agreements using a finite state machine to model the private data use flow and define events and negotiation actions to handle changes over time while ensuring user privacy is maintained according to the agreement terms. It provides an example of modeling a purchase service private data use as a state machine to demonstrate how the proposed model works.

1. S-Cube Learning Package
Dynamic Privacy Model for Web Service
Université Paris 5, LIPADE, France
Salima Benbernou, Meziane Hassina
www.s-cube-network.eu

2. Learning Package Categorization
S-Cube
Quality Definition, Negotiation
and Assurance
Quality Assurance and Quality Prediction
Dynamic Privacy Model for Web Service
© S-Cube

3. Learning Package Overview
 Problem Description
 Dynamic privacy model for Web service
 Solution Validation
 Discussion
 Conclusions
© S-Cube

4. Problem Description :
Privacy
• One of the defining principles [AKSX 2002] of data
privacy, limited disclosure, is based on the premise that
data subjects have control over who is allowed to see
their personal informations and for what purpose
For example, the billing office may use the patient's
address information to process insurance claims, but the
hospital may not give patient address information to
charities for the purpose of solicitation without consent
[DHHS]
[AKSX 2002] R. Agrawal, J. Kiernan, R. Srikant, and Y. Xu. Hippocratic databases. In VLDB, Hong
Kong, China, August 2002
[DHHS] US Department of Health and Human Services. http://www.hhs.gov/ocr/hipaa
© S-Cube

5. Problem Description :
Standards as Case Study
A standards for Web Site – Definitions :
Platform for Privacy Preferences (P3P) enables Websites to express their
privacy practices in a standard format that can be retrieved automatically and
interpreted easily by user agents…
Enterprise Privacy Autorisation Language (EPAL) is a formal
language for writing enterprise privacy policies to govern data handling
practices in IT systems according to fine-grained positive and negative
authorization rights…
WS-Agreement - Definition:
“An XML language and a protocol for…
 Advertising the capabilities of service providers in templates”
 Creating agreements based on creational offers and templates”
 Expressing the guarantees regarding QoS.
 …”
© S-Cube

6. Problem Description :
Standard Weaknesses
Dynamic Web service Changes
 Specifications P3P, EPAL
─ Promises often non respected
─ No reasoning mechanism on it
─ take-it-or-live it model, no negotiation is allowed when
changes occur.
 WS-Agreement
─ Limited type of message
─ No interaction protocol
─ Does not handle privacy issue
© S-Cube

7. Problem Description :
Solutions
 A formal model more legal than promises expressing the
privacy in web services.
 Defining preferences of the client and provider policy .
 A state machine based model is provided in order to
describe the activation of ach privacy agreement clauses,
that is, it spells out the Private Data Use Flow.
 Management of the contract evolution.
 Defining Negotiation Protocol when conflit occurs.
© S-Cube

8. Learning Package Overview
 Problem Description
 Dynamic privacy model for Web service
 Solution Validation
 Discussion
 Conclusions
© S-Cube

9. Privacy Agreement :
Extension of WS-Agreement
Agreement
Service-Agreement
Name
Context
Terms
Service description
Guarantee Terms
Privacy-Agreement
© S-Cube

10. Privacy-Agreement : Definition
 Privacy-Agreement (PA) [SM2007, MS2010]a new component in
WS-Agreement, supports the privacy structure and the evolution
of the privacy.
 Privacy-Agreement spells out a set of requirements related to
costumer’s privacy rights in terms of how service provider must
handle privacy information.
[MS2007] S. Benbernou, H. Meziane, Y.H. Li, and M. Hacid. A privacy agreement model for web services.
IEEE International Conference on Service Computing SCC’07,July 2007.
[MS2010] H. Meziane and S. Benbernou. A dynamic privacy model for web services. Journal Computer
Standards & Interfaces, ELSEVIER, 32(5-6):288–304, 2010.
© S-Cube

11. Privacy-Agreement : Structure
 Policy level specifies clauses on the private data term including
garantees, validity period and a set of penalities.
 Negotiation level
− specifies all possible events that may happen in the service behavior
through the validity contract.
− Defines all possible actions to be taken if the guarantee of privacy
terms is not respected and a conflict arises. They are used through a
negotiation protocol between the service provider and the customer.

12. Privacy-Agreement : Structure
Privacy-Agreement
Policy Level
Privacy-Data-term
(Data-Right, Data-Obligation)
Negotiation Level
Events Triggering a set of actions,
Privacy-Event-term defined in the Agreement-
(Triggering Events) Negotiation-term, involving
changes in the Privacy-data-term
Agreement-negotiation-term
Agreement-Right
Agreement-Obligation Negotiation Protocol ANP includes
a negotiation language defined in
Agreement-Negotiation the Agreement–Negotiation-term
which induce changes in the
Privacy-data-term
© S-Cube

13. Privacy Data Model : Abstractions
Two abstractions of privacy model are defined in terms of :
 data-right, is a predefined action on data, the data-user is authorized to do if he
wishes to. We distinguish two types of actions :
i. actions used to complete the service activity for the current purpose for
which it was provided and are denoted by Opcurrent .
ii. actions used by a service to achieve other activities than those for which
they are provided, called Opextra−activity.
 data-obligation, is the expected action to be performed by service provider or
third parties (data-users) when handling personal data. This type of obligation is
related to the management of personal data in terms of their selection, deletion
or transformation.
© S-Cube

14. Privacy Data Model : Abstractions
 Data-Right rd: action on the private data the provider
wishes to do or not .
( u, d, p, ur)
  
U D OP
Data users Personal data Authorized Period of data
opérations retention
remail ( sp, email, send invoice, uremail )
© S-Cube

15. Privacy Data Model : Abstractions
 Data-Obligation od: security action that must be taken by
the provider on data.
(u, d, ao, uo)
  
U D A
Data users Personal data security Activated
Actions date
occn ( sp, cnn, crypt, [dpay,dpay+1day] )
A set of clauses (rd,od)
© S-Cube

16. Privacy Data Model: Privacy-Data Term
Data-guarantee
A data-guarantee g is a couple (rd,od) with rd ∈ Rd and od ∈ Od, where Rd is a set of rights on
personal data, and Od is a set of obligations on personal data defined in the privacy data model Pd.
Gd ⊆ Rd × Od is a set of guarantees.
Privacy-guarantee term
A privacy-guarantee term td is a couple (d,g) with d ∈ D and g ∈ Gd, where D is a set of personal
data and Gd is a set of data guarantees. Td ⊆ D× Gd is a set of terms td.
Privacy-agreement validity
A privacy agreement validity µ is defined by a tuple (IdA,ds,α), with IdA is an agreement
identifier, and ds is an absolute time indicating when the privacy-agreement was signed,
and α ∈ [ds,t], t ∈ R is an interval time indicating the validity period of the privacy agreement.
Penalty
A penalty P = PGd∪ Pn is a set of applicable punitive actions when guarantees on data (PGd) are not
satisfied or when negotiation process (Pn) terminates without success.
Privacy-Data Term
A privacy-data term pd is defined by a tuple (T d,µ,P) with T a set of guarantee terms, µ the privacy
agreement validity, and P the set of penalties.
© S-Cube

17. Privacy Model : Privacy Events Term
 A set of events that that can occur in the service behavior and may affect
different elements defined in the privacy-data term. These events trigger a
set of actions dictated by changes.
Actions dictated
by Changes
(e,a)
Event
© S-Cube

18. Privacy Model : Privacy Events Term
Event triggering changes Action dictated by change
Data-Driven : Create data-guarantee
adding new data. (data_right,data obligation)
Purpose-Driven : Create data-right
somes changes will affect data use on
data.
Data-User driven : Create data-right
A new user will use data.
Duration-Driven : Uptade data-right
the time retention of data may be
changed.
Security-Action Driven : Create data-obligation
to avoid new security threats, some new
security actions on the personal data are
needed.
© S-Cube

19. Privacy Model :
Agreement-Negotiation term
 Description of actions to be taken when an event occurs and if the
guarantee of privacy terms is not respected or a conflict arises
between signing parties . To make an efficient negotiation, we need :
− A negotiation actions, defining possible actions that each party
might take on,
− A agreement-negotiation protocol, enabling interaction
mechanism between the service provider and the customer by
means of previous set of Actions
© S-Cube

20. Privacy Model :
Agreement-Negotiation Term
 The language of the communication defines three types
of actions :
1. Agreement-Right, is an action that the signing entity will achieve if
he wishes during the negotiation time.
2. Agreement-Obligation, defines a set of duty actions that both the
provider and the customer must perform when a type of event e
happens during the agreement life.
3. Agreement-Negotiation, defines actions of the negotiation that can
be taken by signing parties when conflicts occur between them.
© S-Cube

21. Privacy Model : Grammar
Agreement Negotiation Language
Agreement –Negotiation-Action → AGr(Role, aid,date,validity)|
AGo(Role, aid,date,validity)|
AGn(Role, aid,date,validity)
aid → ActionRight|ActionObligation|ActionNegotiation
ActionRight → reject | accept
ActionObligation → reply | notify
ActionNegotiation → relate | proposal | justify
Role → sp | cu
© S-Cube

22. Agreement-Negotiation Term :
Example of Action types
Action Meaning Action Type
Notify The provider notifies the customer that an event agreement-obligation
happened at a time point te.
Relate The provider relates which data in the agreement is agreement-negotiation
affected by a change and sends a report.
Proposal The provider proposes a proposition to the customer agreement-negotiation
that contains the revised privacy-agreement.
Reply The customer must reply by sending an agreement-obligation
acknowledgment receipt of the proposition
Reject The customer rejects the proposition. agreement-right
Justify The customer justifies the refusal reply by some agreement-negotiation
explanations including additional informations about
his decision.
Accept The customer accepts a proposition. agreement-right
© S-Cube

23. Background:
Finite State Machine (FSM)
 FSM is a behavioral model used to design computer programs. It is composed of :
• a set of states (including the initial state),
• a set of input events,
• a set of output events,
• and a state transition function.
The transition function takes the current state and an input event and returns the
new set of output events and the next state. Some states may be designated as
"terminal states".
The state machine can also be viewed as a function which maps an ordered
sequence of input events into a corresponding sequence of (sets of) output events.
© Philipp Leitner

24. Background:
Finite State Machine (FSM)
 Mathematical model
A deterministic finite state machine is a quintuple (Σ,S,s0,δ,F), where :
• Σ is the input alphabet (a finite, non-empty set of symbols).
• S is a finite, non-empty set of states.
• s0 is an initial state, an element of S.
• δ is the state-transition function: δ : S × Σ S
• F is the set of final states, a subset of S.
© Philipp Leitner

25. Privacy Agreement use :
Private Data Use Flow
 Private data use flow model is described as a state
machine in the policy level.
 Describe the activation of different clauses in PA.
 Specify the states of each activated clause in the policy
level.
 Identify privacy vulnerabilities, where a service’s
compliance to privacy regulations may be compromised.
© S-Cube

26. Managing Privacy Agreement :
Private Data Use Flow
State Machine
defines all the triggered operations involving private data from the
activation of the agreement Initial state to the end of the
agreement Final state.
Private data use abstractions Authorization abstractions
describe the states in which the Provide the conditions that
agreement is – (1) which private data must be met for transitions to be fired.
is collected (2) when it is used (3) for
what (4) who use it.
© S-Cube

27. Private Data Use Flow :
Formal Definition
Private Data Use Flow F
Φ : C → σ(S)
set of clauses Associate rights and
C⊂ {Rdi ∪ Odj ,di, dj ∈ D} obligations with states
(S, T, C, Ψ, ρ, Φ)
set of states Ψ :T →S×S
set of ρ : C.r.op ∪ C.r.μr ∪ C.o.μo T
transitions Associate transition with associate operations and
source and target state elapsed time from the obligations
and the rights with transitions
© S-Cube

28. Private Data Use Flow :
Purchase Service Example
Agreement-
Opwrong-use/Forward[ email] Failure
A [Op marketing , µr2email]
C C1
Activation Agreement r1email[role, email,send I.,p1email]
date()≤ date-validity
µrccn r1email[role, email, send I., p1email]
r2email[role, email,send O.,p2emai]
rccn[role, ccn, payment , pccn] r2email[role,email,send O., p2email]
[Op marketing, D
[opcurrent,
µ µoccn
µrccn, µr1email r2email r1email[role,email, C2
send I., p1email] r1email[role, email, send I., p1email]
µrccn
B µr2email r2email[role,email,send O, p2email]
µoccn occn[role, ccn, delete, µccn]
r1 email[role,email,Send I., D1
p1email ] r1email[role, email, send I.,
rccn [role, ccn, payment, µr1email µr1email C3
p1email ] ,
pccn] occn[role, ccn, delete, µccn ] µr2email r2email[role, email, send O.,
p2email ]
D2 µr1email occn[role,ccn,delete, µccn]
µr2email
µrccn, µr1email occn[role,ccn,delete, µccn]
/µoccn, µoccn µoccn
E
occn[role, ccn, delete, µccn ] Max(αccn, αemail) End
oemail[role,email,hide, µemail ] Agreement
© S-Cube

29. Private Data Use Flow :
Clarification of Purchase Service Example
We take a part of private data use flow (path [A-B-C-C1-C2-C3-D2-E]) :
 In the state C, three clauses of the privacy agreement policy level are triggered :
1. the current operation for two private data (r1email, rccn) which is payment invoice, is still
activated by the provider to achieve the service aim. The rights are cumulated from the
previous state because the retention times of the rights r1email and rccn associated with
the private data are not elapsed.
2. the send-offer operation (r2email) is activated by entering C for marketing purpose of the
service (not to complete the service), it is an extra-activity of the service.
 In the state C2 three clauses of the privacy agreement policy level are triggered :
1. the current operation (r1email) is still activated and then cumulated from the previous state
C1.
2. the extra activity in r2email is still activated and then cumulated in the new state from C1 .
3. the action of security is triggered (occn) because the time of data retention is elapsed
(μrccn).
 In the state E two clauses are triggered
1. the obligation occn is still activated and cumulated from the previous state D2 .
2. the obligation oemail is activated because the time μoemail to activate is reached.
© S-Cube

30. Managing Privacy Agreement :
Privacy Lifecycle
Private data
use flow
Finished
Running
Running
Unchanged
[Rejected]
[Not-Changed]
Evolution Checking [Conflict]
Sleep Negotiated
Activated Whipped up Checked
Running
[Not-Violated]
Event [Accepted]
Revised
© S-Cube

31. Privacy Events Term :
The Semantics of States
[[sleep]] The agreement is created and not used monitored
[[activated]] The service involving the agreement is running then the agreement is
activated
[[whipped up]] During the running service an event occurs subject to change the
agreement
[[checked]][Not−violated] The agreement is checked if no conflict exists
[[checked]][Conflict] The agreement is checked when a conflict exists then a negotiation is
started
[[checked]][Not−changed] The checking implies no changes in the agreement
[[negotiated]][Accepted] The agreement is negotiated and accepted by the two parties
[[negotiated]][Rejected] The negotiation fails and starts again until an agreement is defined
[[revised]] The agreement is revised and is running again with new updates
[[unchanged]] After the occurrence of the events, the agreement remains
unchanged
[[finished]] The agreement is terminated
[[private data use flow]] Clauses of the agreement are activated
© S-Cube

32. Privacy Events Term :
The Semantics of Transitions
[[running]] An operation on a private data is running
[[evolution]] An event occurs and an evolution of the agreement is expected
[[checking]] The privacy-agreement is going to be checked whether a conflict arises
or not after the evolution
[[not−changed]] The change does not change the agreement
[[not−violated]] The change does not violate the agreement
[[accepted]] The negotiation is accepted
[[conflict]] The guarantee term is not satisfied
[[rejected]] The proposal is rejected and renegotiate again.
© S-Cube

33. Managing Privacy Agreement :
Agreement Negotiation Protocol ANP
 Event needs to start a negotiation Negotiation ANP
 ANP is a protocol that govern and structure interactions between
signing parties.
 ANP include a negotiation language and an interaction mechanism .
 Rubinstein Alternating Offers Protocol , a game theory based
approach.
 Weight is used to come up to a good negotiation.
 State machine is used to represent the agents behavior.
© S-Cube

34. Agreement Negotiation Protocol
ANP
ANP
f⊂S
set of final states
(end or penalties) set of penalties
(S, so, f, M, ∆ ,μn ,P)
set of states set of messages Δ ⊆ S ×S×M
initial state Negotiation
set of transitions time
© S-Cube

35. Provider’s Negotiation Protocol
M6: (µn+ , p) +
End
Negotiation
(e,te) ‘TimeOut’: µn+
Accept
notify Proposal
Idle Waitting for
Analysing Reply
Response
Relate Reject Justify
Proposal
Writing New
proposition
© S-Cube

36. Managing Privacy Agreement :
Policy Level Change Operations
 Evolution : Operations of Changes
 = {AddTransition, AddState, RemoveAddState,...}
…..
AddTransition (t, sp,ss,at) AddState(ss,sp,t)
ss,sp ∈ FP .S and t  FP .T ss  FP .S and t  FP .T
Fn.T = Fp.T∪{t} ╞ P1(rs)
╞ P2(t) Fn.S = Fp.S∪{ss}
Fn.Ψ= Fp.Ψ ∪{t → (sp,ss)} Fn.C = Fp.C∪{rs}
Fn.ρ = Fp.ρ ∪{{at → t}} where Fn.Φ= Fp.Φ ∪{rs → ss}∪{rp → ss}∪{op → ss}
at ∈ {r.op, o.µo,r.µr,timeout }
AddTransition(t, sp,ss,at)
© S-Cube

37. Learning Package Overview
 Problem Description
 Dynamic privacy model for Web service
 Solution Validation
 Discussion
 Conclusions
© S-Cube

38. Validation
A Framework to manage the
service development lifecycle
© S-Cube

39. Privacy Agreement Negotiation :
Realization
 Implementation of the negotiation model and the
interaction between signing parties to manage the
behavior of services when possible events may
happen.
 Providing tools to support the negotiation as well
as the detection and analysis of relevant events in
the dynamic environment of web services.
 Providing infrastructure to manage, propose and
evaluate the proposition.
© S-Cube

40. Privacy Agreement Negotiation :
Architecture
Privacy -
time customer provider
Agreement
Acceptation checker
Store& versionning Privacy -
Agreement
Weight
Proposal Evaluator administrator
Action Scheduler Proposition Decision [Justificationt]]
Actions didacted by changes AC Invocation negotiation
Negotiation Privacy-
Revision Agreement
Mediator Agreement
Update Privacy agreement proposition
Agent justification generator
reject
Agreement Negotiation Protocol
Data- Data- Data- Data- Event update
Obligation Ref Right Ref Conflit /no-conflit
Data-Guarantee Controller
Categorization
active agreement level checking
Events
Event
Privacy-Data Handler Environment
© S-Cube

41. Privacy Agreement Negotiation :
Architecture
 Event Handler monitors and detects relevant events in the environment.
 Data guarantee controller analyzes the events coming from the event handler by means
of the categorization event module and identifies the category of the event
 Negotiation Mediator Agent receives message from the Data controller and forwards it
to the Privacy Agreement generator (Invocation negotiation message or a revision
agreement message).
 Privacy-Agreement Generator, an editing interface which assists the provider to
generate a proposition, evaluates the proposal regarding the customer preferences and
generates an appropriate response.
 Weight Administrator assigns the weight to each proposal by summing separately the
weights affected by the provider and the customer for each term revised or proposed in
the proposal and select the best proposed agreement by calculating for each party the
maximum of the weights affected to the proposition.
 Acceptation Privacy-Agreement is the result of the negotiation or revision processes.
 Action Scheduler generates a set of actions in the table from document sent by the
Acceptation Privacy-Agreement module and specifies which data-obligations and data-
rights are concerned by these change actions.
 Update Privacy agreement executes all the actions defined in the action table on an
appropriate data-right and data-obligation.
© S-Cube

42. Learning Package Overview
 Problem Description
 Dynamic privacy model for Web service
 Solution Validation
 Discussion
 Conclusions
© S-Cube

43. Privacy Agreement Negotiation :
Evaluation
 Evaluation of the impact of each event in the negotiation.
 In the framework we consider many negotiations for a
single running event.
 Our experimental measurement is twofold :
1. the number of the solutions proposed by the service
provider to the customer.
2. the time of the negotiation when a change is needed in
the privacy agreement.
 The measurements express the persuasion degree to
convince the service customer to agree with the changes in
the privacy agreement.
© S-Cube

44. Privacy Agreement Negotiation :
Evaluation
 During the negotiation process, each party assigns a
weight to the proposition and we measure the
approbation degree of the proposed solution as for the
emphasis degree of the private data.
 The weight of the provider is uniform and does not
change, we have study the weight of the client side.
© S-Cube

45. Experimental Results
1. The evaluation of the acceptance degree of the propositions by the
customer :
a. the figure shows that the more the client accepts the proposed solution
by the provider with a high weight, the more the exchange of the proposition
decreases through time and both sides agree about a solution quickly
Event data-driven.new purpose.new third part
10
sp weight
8
cu weight
weight
6
4
cu weight
2
sp weight
0
p1 p2 p3 p4 p5 p6
no.proposition
© S-Cube

46. Experimental Results
b. In the figure , we can observe that the lower the assigned weight, the
less the client is able to accept the solution and the more he needs
propositions
Event data-user-driven.new third part
sp weight
cu weight
10
8
6
weight
4
2
0
p1 p2 p3 p4 p5 sp weight
p6 p7 p8 p9
p10 p11 p12
no.proposition
© S-Cube

47. Experimental Results
2. The graph shows for each event the time taken for the negotiation and the number of the
propositions proposed by the provider to persuade the customer to make the revision. As
we can see, the increasing number of the propositions causes a linear increase in the time
taken for the negotiation instance :
Event/no.Negotiation. Negotiation time and nbr. propositions
time negotiation (mn)
015 nbr.propostions
010
005 nbr.propostions
time negotiation (mn)
000
driven.new
driven.chang
purpose.new
purpose.new
duration-
data-user-
third part
driven.new
driven.new
e third part
third party
third party
driven
data-user-
purpose-
data-
© S-Cube

48. Conclusion
 We have proposed a formal model for privacy called privacy agreement
which is an extension of WS-Agreement specifications, that both
customer and provider might agree before any running process.
 We have emphasized a lifecycle of privacy which is an important issue
to date which has not been addressed.
 Based on a formalization of the private data use flow model, we have
presented privacy policy evolution primitives and an agreement
negotiation protocol that allow to evolve the privacy agreement to a new
one.
 we point out that the framework is one component of a Broader CASE
tool in ServiceMosaic platform, that manages the entire service development
lifecycle.
© S-Cube

49. Further S-Cube Reading
[Benbernou 2010] H. Meziane and S. Benbernou. A dynamic privacy
model for web services. Journal Computer Standards & Interfaces,
ELSEVIER, 32(5-6):288–304, 2010.
© S-Cube

50. References
[Benbernou 2007] S. Benbernou, H. Meziane, Y.H. Li, and M. Hacid. A privacy agreement model for web
services. IEEE International Conference on Service Computing SCC’07,July 2007.
[Oberholze 2005] H. Oberholzer, M. S. Olivier, Privacy contracts as an extension of privacy policies, in:
IProceedings of the 21st International Conference on Data Engineering, ICDE 2005, IEEE Computer
Society, Tokyo, Japan, 2005, p. 1192.
[Osborne 1990] M. Osborne, A. Rubinstein, Bargaining and markets, The Academic Press, 1990.
[. Karjoth 2002] G. Karjoth, M. Schunter, A privacy policy model for enterprises, in: 15th IEEE
Computer Security Foundations Workshop (CSFW-15 2002), IEEE Computer Society, Cape Breton, Nova
Scotia, Canada, 2002, pp. 271–281.
[Ashley2002] P. Ashley, S. Hada, G. Karjoth, M. Schunter, E-p3p privacy policies and privacy authorization,
in: Proceedings of the 2002 ACM Workshop on Privacy in the Electronic Society, WPES 2002, ACM,
Washington, DC, USA, 2002, pp. 103–109.
[Bertino 2009] Q. Ni, E. Bertino, J. Lobo, S. B. Calo, Privacy-aware role-based access control, IEEE
Security & Privacy 7 (4) (2009) 35–43.
[Bertino 2004] E. Bertino, E. errari, A. Squicciarini, Trust negotiations: Concepts, systems, and languages,
Computing in Science and Engg. 6 (4) (2004) 27–34.
[Parkin 2006] M. Parkin, D. Kuo, J. Brooke, A framework and negotiation protocol for service contracts, in:
IEEE International Conference on Service Computing SCC’06, IEEE Computer Society, Chicago, Illinois,
USA, 2006, pp. 253–256.
© S-Cube

51. Acknowledgements
The research leading to these results has
received funding from the European
Community’s Seventh Framework
Programme [FP7/2007-2013] under grant
agreement 215483 (S-Cube).
© S-Cube