Conversations with Connected Vehicles

ABSTRACTWe present a system that allows drivers and fleet managersto interact with their connected vehicles both by means ofdirect control and indirect goal-setting. The ability to movedata from vehicles to a remote server is established by theflexible and secure open vehicle telematics platform ”Cloud-Think.” Based on this platform, we present two examplesof vehicle data access enabled by CloudThink to providevaluable services to users. In the first case, a system is estab-lished to allow a user to select and interact with a connectedvehicle using object recognition methods and automaticallygenerated user interfaces on a smartphone or smartwatch.The second use case shows how functional semantic meta-data may be used to smooth the boundaries for interactingwith vehicles in the physical and virtual worlds. Finally, wepresent a method for monitoring interactions between vehi-cles and remote services which increases safety and securityby enhancing driver oversight and control over the data thatleaves and enters their vehicle.

Categories and Subject DescriptorsH.5 [Information Interfaces and Presentation]: Miscel-laneous

General TermsExperimentation, Human Factors

KeywordsCloudThink, Connected Vehicles, Internet of Things, UserInteraction and Interfaces, Web of Things

A car whose telemetry data is projected into the “cloud” andmade accessible for third parties via standard Web tech-nologies represents an interesting example of a Web-enabledsmart thing. With vehicles among people’s most frequentlyinteracted with objects, and a location where they spendthe most time outside home and the office, Web-enablingvehicles affords designers and developers a unique opportu-

nity to improve quality of life. Integrating and connectingautomobiles to the broader Web ecosystem paves the way toreducing transit cost and time through efficiency and relia-bility improvements, while unlocking richer information andactuator access than is presently available. It thus providesa unique lever to improve user experience, a primary differ-entiator in today’s vehicle market: from failure prognosticsto comfort and convenience improvements, a well-connectedcar has the ability to change how people see and interactwith transportation systems at large. By lowering barriers toapplication development, a whole new ecosystem of automo-tive applications may be developed, and OEMs, consumers,and infrastructure all stand to benefit. The key to makingvehicular connectivity a success lay in simplifying data ac-quisition and manipulation, and creating a platform that isbrand-agnostic. In essence, the challenge is creating a systemcapable of supporting the many modes of data acquisitionand actuation required by the various application builderswhile balancing the need for high safety and security forcritical systems integrated in user’s vehicles.

The basic infrastructure necessary to make cars accessibleover the Web is supplied by CloudThink, a platform developedto make vehicle data and actuation capabilities usable forclients in near real time via an intuitive REST API. Therebyintegrating cars into the Web of Things opens up many inter-action methods for smart things to the automotive domain:we can recognize cars and interact with them directly via userinterface devices such as smartphones or smartglasses, can vi-sualize their interactions with other smart things and remoteapplications, and can semantically describe the data andservices they provide to enable the automatic collaborationof vehicles with smart devices and remote Web services.

In this paper, after a brief introduction and discussion of theCloudThink platform, we discuss several applications thatwe developed on top of the platform to make it easier forusers and third-party applications to interact with vehicles.Specifically, we show a combination of a visual object recog-nition system with embedded model-based user interfacedescriptions that enables drivers to directly interact withtheir cars. We furthermore demonstrate the applicabilityof functional semantic service descriptions to automobiles– this system integrates cars with other smart devices andWeb services, thus creating physical mashups that make useof data and functionality provided by vehicles. Finally, weshow a system that we created to help users stay in control ofwhat data leaves their automobiles – and which commands

CARduino

Cellular Operator

CloudThink Infrastructure

Storage

Data Server

Gateway ServerClients

Figure 1: Overview of the CloudThink platform.The CARduino hardware is deployed on the car andcommunicates with the CloudThink back end viaGSM. In the back end, the data server parses andfilters the data and stores it in a database. Thegateway server provides a REST API for clients toconveniently access the data.

enter them – by using an augmented-reality interface thatvisualizes interactions of clients with cars.

1. THE CLOUDTHINK PLATFORMIn the context of a collaboration between ETH Zurich, Mas-sachusetts Institute of Technology (MIT), the SingaporeUniversity of Technology and Design (SUTD), the Univer-sity of North Texas, and the Masdar Institute of Scienceand Technology in the United Arab Emirates, we have de-veloped a vehicle-to-cloud communication platform calledCloudThink [1]. The core of this system consists of a low-costhardware platform (the CARduino) that connects to the on-board diagnostics port of a car using the OBD-II interface1

and a secure back-end server that stores data uploaded fromvehicles and makes it accessible to other applications via aREST API.

The main goal of CloudThink is to enable drivers to sharedata from their vehicles for processing by a wide variety ofthird-party applications while emphasizing an open, secureinterface to this data. CloudThink thereby aims to create an“App Store” for cars that hosts applications which can accessand process car telemetry. The platform is distinguishedfrom similar projects in the automotive domain in that itremains agnostic of the concrete type and make of vehicle andtherefore enables data sharing across the boundaries of carmanufacturers. Use cases for the CloudThink system stretchfrom enhancing vehicle security (for instance, a “virtual leash”for tracking of stolen vehicles) to reducing the environmentalimpact of cars by helping drivers to find out how they canbetter economize fuel. Drivers could also use such a systemto improve safety by adapting their driving style [2], andthe platform could help set economic incentives to do so byenabling pay-as-you-drive (PAYD) insurance schemes [3,4].Potentially, drivers could also use CloudThink to monetize

1This is a standard interface that every car manufactured inthe E.U. and U.S. after the year 1996 must support.

Figure 2: A virtual dashboard that displays datafrom different sensors of a Web-enabled car. Thecurrent location of the vehicle is shown on a mapor alternately in the form of a Google StreetViewimage.

their driving data, for instance by sharing usage statisticsand telemetry with the manufacturer of their car – or providethe same data to non-profit organizations to achieve bettertransparency of how specific vehicles fare in realistic situa-tions, for instance with respect to their fuel consumption ormaintenance effort. Another highly interesting applicationdomain is using real driving data for the improvement ofvehicle characteristics, for instance determining the optimalbattery size for electric cars [5]. On a larger scale, real-timefeedback from vehicles could help improve road quality –and safety – by enabling road operators to quickly reactto problems that range from potholes to developing trafficjams [6,7].

The main components of the CloudThink system are theCARduino hardware, the data server that stores data up-loaded from individual cars in a local database, and thegateway server that enables third parties to access the storeddata in a uniform way via a REST API (see Figure 1). Withinthe joint project, MIT is leading the hardware development(see Section 1.1), while ETH’s main responsibility is the im-plementation and maintenance of the back-end infrastructure(see Section 1.2). On top of the system, the consortium hasalso created applications that provide better access to datastored on the platform in the form of “virtual dashboards”(see Figure 2) that could be used, for instance, by fleet man-agers, and has used telemetry data from CloudThink tocreate an application that gives drivers more insight intotheir own driving behavior, especially with respect to cluesas to how they could improve their own fuel economy.

1.1 CARduino HardwareOur CARduino hardware2 (see Figure 3) is responsible fortransmitting information from the vehicle to the CloudThinkback-end infrastructure, where this data is stored in a SQL-based database. All information is sent via GSM connectionsand encoded in a custom message format that is tuned tominimize the volume of the transmitted data, thereby helpingto keep communication cost low. Each message that is sentto the back end consists of the recording timestamp, the

2The CARduino hardware is open-source. At the moment,its only manufacturer is CarKnow LLC., a company that hasbeen incorporated by one of our partners in the CloudThinkproject.

(a)

(b)

Figure 3: (a) The CARduino hardware (ca. 9.3cmx 4.4cm x 1.5cm). One can recognize the SIM cardand the SD card that is used for data buffering. TheGPS and GSM antennas are attached to the bottomof the module. The “CarKnow” silkscreen refers tothe name of the start-up hardware designer and dis-tributor. (b) The CARduino hardware shown in its3D-printed casing and with an OBD-II connector ca-ble.

type of the transmitted data, the data itself, and a checksum.Messages are received by the CloudThink data server thatparses and checks each message before storing the containeddata in the database.

The CARduino carries an on-board accelerometer and a GPSreceiver, and can be configured to listen on a car’s OBD-IIinterface for OBD messages that are tagged with specifiedOBD-II Parameter Identifiers (PIDs). This allows us to cap-ture information about many internal processes of a vehicle,for instance basic driving data (e.g., speed, runtime, etc.)and information related to motor management (e.g., motorrevolutions per minute, mass airflow, coolant temperature,etc.). In particular, we are able to gather all data requiredfor calculating an approximation of the instantaneous fuelconsumption of a car, which can be computed from the cur-rent vehicle speed and the mass airflow rate [8]. When theCARduino is unable to reach our back end, for instance dueto poor network connectivity, it uses an on-board memoryunit for buffering and transmits the contents of that bufferat the end of the trip. Finally, our hardware can also writeto the car’s OBD interface, thereby enabling it to actuatevehicle functions – we have successfully used it to lock andunlock cars, and to control wipers and power windows.

Figure 4: Example responses of the CloudThinkAPI’s HTML interface to a request for a minute ofcar telemetry (GPS coordinates, coolant tempera-ture, speed, and revolutions per minute).

1.2 Back-end InfrastructureAfter being stored in the CloudThink database by the dataserver, the vehicle information is processed by a synchroniza-tion script that aligns all received data points to common5-second time windows using linear interpolation and, aspart of this process, copies it to a different database. Thisscript is also responsible for calculating several metrics thatare derived from the raw data – such as the instantaneousfuel consumption, and distance driven – and persisting thesevalues together with the other synchronized data points.

It is the responsibility of the CloudThink gateway server togive client applications (which can be mobile applications,third-party servers, or Web browsers) access to the stored,synchronized data via a secure REST interface (SSL/TLSand HTTP Basic authentication). All data is provided inthe JSON and XML formats for machine clients, and canbe browsed and visualized using the HTML interface ofthe gateway server (see Figure 4). The server provides alayer of abstraction on top of the OBD PIDs that are usedinternally by our system and enables clients to request dataabout attributes such as “RPM,”“consumption,” and “speed”– information about which types of data a specific user isallowed to access on a specific car can also easily be loadedfrom the interface. Additionally, the gateway server enablesclients to send actuation commands to vehicles.

Another responsibility of the gateway server is to enforcethat only authorized users may access data stored in theCloudThink back end. For this, it makes use of anotherdatabase that stores, for each registered user and application,the data fields that this user may access (e.g., GPS location,acceleration, etc.) as well as, for each vehicle, the users thatare allowed to access data from this vehicle and whetherthey also hold actuation rights. The gateway server alsokeeps track of which user accesses which stored data item forbilling purposes and to be able to inform each driver aboutwho requests what kind of information about their cars.Finally, the gateway server features a public interface thatenables developers of client applications to test their ideasand software prior to registering their applications as datausers on the CloudThink platform: we provide a completeset of real data from a single car for this purpose, and havea car simulation application that constantly replays a set of

Figure 5: Our smart things interaction software rec-ognizes a car using its visual features.

sample data, for the purpose of supporting the testing ofapplications that make use of the near-real-time data storedon the CloudThink platform. The capabilities of the gatewayserver are detailed in its online REST API description, alongwith example queries. To further support developers ininterfacing with the platform, we provide sample code formultiple platforms and programming languages.

2. TALKING TO CONNECTED CARSEssentially, CloudThink aims to provide convenient access tovehicle data for third-party applications – how exactly theseprocess the provided data to create advanced services fordrivers and third parties is left to the application developers.We have developed several applications that make use of thedata made available via the CloudThink platform, including avirtual dashboard and a fuel economy assistant. The primarytopic of this paper, however, is how CloudThink can be usedto interact with Web-connected cars: to this end, we proposethe automatic generation of user interfaces for vehicles andto combine this technology with an object recognition systemfor allowing users to select which car to interact with (seeSection 2.1), the semantic annotation of services that areprovided by connected vehicles to enable the integration oftheir functionality within physical mashups (see Section 2.2),and the visualization of interactions with Web-enabled carsusing an augmented-reality interface (see Section 2.3).

2.1 Direct User Interaction with a VehicleFirst, we focus on the direct interaction of a user with aconnected car, meaning that we want to enable people tomonitor telemetry data produced by a vehicle and to controlactuators of a car using a user interface device, such as asmartphone, tablet, or smartglasses. Accomplishing thisrequires both: a means of selecting a vehicle to interact with,and rendering a suitable user interface to interact with it.We propose a system where a car is selected by means of avisual object recognition algorithm, i.e. making use of itsdistinctive visual features, and where the interaction takesplace via automatically generated user interfaces.

To select a vehicle to interact with, we make use of currentvisual object recognition methods that can be deployed onhandheld or wearable devices such as smartphones, smart-watches, or smartglasses (see Figure 5). Our approach

(a)

(b)

Figure 6: With the help of the CloudThink API,a smartphone application can display values fromsensors of a recognized vehicle (a) and provide userinterfaces to control its actuators (b).

combines a Bag of visual Words with linear SVMs andFAST/ORB feature detection/description and thus allows torecognize objects without relying on fiducial markers, mean-ing that our classification algorithm can be trained usingonly snapshots of the cars to interact with (see [9, 10]).

For automatically generating an interface that allows usersto control the actuators of a vehicle, and monitor sensorvalues, we incorporate a model-based user interface gener-ation system that relies on descriptions of the high-levelsemantics of interactions with Web-enabled devices (see [11]).This system can be applied in the context of generatinguser interfaces for the sensors and actuators of Web-enabledcars without requiring any changes to the CloudThink sys-tem other than the embedding of hyperlinks to the relevantinteraction descriptions.

Together, the described technologies yield a system thatpermits users to directly interact with vehicles that are con-nected to the CloudThink platform and whose features aredistinctive enough to enable them being recognized by ourobject recognition algorithm. As an example, Figure 6(a)demonstrates the interaction with the mileage “sensor” of aconnected vehicle, while Figure 6(b) enables users to controla car’s door locks: the embedded user interface descriptionsallow rendering interfaces for multiple interaction modalities,including haptic, speech, and graphical.

Figure 7: For cars, our visual object recognition soft-ware falls back to the few distinctive features of a ve-hicle, for instance on its rims, stickers, and the num-ber plate. Unfortunately, many of the other featuresare located “inside” the car.

Especially the application of our object recognition systemwithin the context of recognizing vehicles gives rise to severalchallenges, predominantly due to the visual similarity ofdistinct vehicles: being based on visual object recognitiontechnologies, our systems cannot differentiate between differ-ent cars that look alike, with the exception of cases whereunique features of the car are visible in the camera frame(and training images). While our approach is thus able tofind and match visual features of vehicles, these are oftenlocated on the rims or the number plate of a vehicle, oncustom stickers, inside the car, or on its reflective surfaces(see Figure 7), which makes the robustness of our systemheavily dependent on the current lighting conditions. Fur-thermore, especially in the case of “plain vanilla” cars withoutany distinct features, our software is not able to differentiatebetween cars of the same make, type, and color. Similarto humans, who often arbitrate between different cars thatlook alike by remembering their vehicle’s parking location,we propose to partially overcome this challenge by usingthe GPS location of a car (that can be obtained from theCloudThink API) in conjunction with the location of theuser interface device as an additional context parameter touniquely identify a vehicle. However, while this techniquecan indeed help to achieve stable selection results, it intro-duces another challenge: the (remote or local) applicationthat helps the user interface device arbitrate between dif-ferent cars requires access to the locations of cars that areregistered to the CloudThink platform or, as a minimum, aninterface to send geographically bounded queries for a car(i.e., “Is car C currently located within 100 meters of the GPScoordinates (Lat,Lon)”). Other types of context informationmight be used as well for this purpose, for instance ambientbeacons (e.g., Google PhysicalWeb3).

3https://google.github.io/physical-web/

@prefix :<ex#>.@prefix ex:<http://example.org/#>.@prefix http:<http://www.w3.org/2011/http#>.@prefix dbpedia:<http://dbpedia.org/resource/>.

{?car a dbpedia:Car;

ex:hasVin ?vin.}=>{_:request http:methodName "GET";

http:requestURI ("https://api.cloud-think.com/data/"?vin"?param=gpslat");

http:resp [ http:body ?gpslat ].

?gpslat a dbpedia:Latitude;ex:derivedFrom ?car.

}.

Listing 1: Part of the RESTdesc description of theCloudThink API that describes how the currentGPS latitude of a car can be obtained given its VIN,using an HTTP request to the CloudThink server.The server provides similar descriptions for otherinformation about the cars it has data about.

2.2 Functional Semantic Metadata forSmart Vehicles

Apart from the direct interaction with connected automo-biles, we have used functional semantic metadata in theform described in [12] to capture the functionality of theCloudThink API with respect to providing access to vehicletelemetry data of individual cars, where each car is uniquelyidentified using its Vehicle Identification Number (VIN). Asan example, Listing 1 shows the semantic description of theAPI that enables clients to obtain the GPS latitude of thecurrent location of a vehicle given its VIN: using Notation3,a superset of RDF, it specifies that, given a specific VIN, alatitude value can be obtained by sending an HTTP GETrequest to the specified URL – more specifically, that thislatitude value is conveyed in plain text within the body ofthe HTTP response.

The CloudThink API contains a similar description for eachparameter that can be accessed about its connected cars(e.g., their velocity, coolant temperature, and revolutionsper minute). These descriptions can be used by semanticreasoners to integrate functionality across different smartdevices and Web services – to demonstrate that our systemis capable of creating composite services on top of data pro-duced by vehicles and published via CloudThink, we usedits semantic descriptions together with those of a serviceable to display arbitrary images on a display, and semanti-cally annotated two mapping applications (Google Maps andOpenStreetMaps). Given this setup, users can formulate asemantic goal that expresses their desire to obtain an imageobject that is also a map and is derived from the VIN of aspecific car, and that a screen that is situated at the currentlocation of the user should be displaying this image – thisleads a semantic reasoner to propose that it could displaythe current location of a car on a nearby screen, by mashingup the CloudThink back end with either Google Maps orOpenStreetMaps and the screen API (see Figure 8 on thenext page). Our reasoning infrastructure, which is describedin greater detail in [12], then sends the appropriate HTTP

(a) (b)

Figure 9: Our application visualizes interactions with a Web-enabled automobile that are brokered by theCloudThink platform using a visual object recognition algorithm and an augmented reality overlay on ahandheld device. (a) Interactions of a client with a vehicle (and other endpoints). (b) Interaction of ahandheld device with a vehicle.

GET

GET

PUT

Figure 8: By publishing semantic metadata thatdescribes its interfaces, functionality of the Cloud-Think API (i.e., access to sensor values and actua-tors of connected vehicles) can be flexibly integratedwith other local and remote Web services. In thisexample, a user instructs an interface device (in thiscase, a smartphone) to display the location of his caron a map that is shown an a nearby computer screen.A reasoner then finds the necessary HTTP requeststo reach that goal and executes them.

requests to the client which can execute them and therebyachieve the desired user goal. Because this service mashupis not hard-coded but rather derived on demand from thecurrently available semantic descriptions, the mashup seam-lessly switches to using alternatives when services becomeunavailable – in this specific case, when we blocked accessto one of the two mapping services, the mashup seamlesslyswitched to using the other, thus demonstrating the flexibil-ity of our approach of using functional semantic metadatafor service composition.

2.3 Monitoring Car InteractionsAs described in [13], we believe that users are increasinglyprone to losing control over the actions of their smart devicesin an increasingly connected “Web of Things” world, espe-cially given the possibility that distributed services can beflexibly and automatically combined by reasoning programs.Indeed, Web-enabled cars and platforms such as CloudThinkrepresent an interesting domain where drivers would want tomonitor which services access their vehicles: the ability to su-pervise and control interactions is relevant to protect driversfrom attacks on their privacy such as location profiling orthe misuse of private data by authorities [14].

To support users to stay in control of their connected cars,we integrated a piece of software that logs HTTP requestsand responses with the CloudThink back end and makes thecollected data accessible to users in real time, using an aug-mented reality interface on their handheld devices [13]. UsingJava Agents which can modify the bytecode of Java classesand class transformers that can infuse any Web server basedon the Grizzly NIO framework4 with an HTTP request logger,the integration of the logging functionality with the Cloud-Think gateway server proved straightforward, and merelyrequired a restart of the server with attached transformers.The combined system allows users to monitor interactionsof clients with their vehicles using the Web interface of ourvisualization tool as well as displaying these interactions asa live overlay on handheld devices (see Figure 9).

4https://grizzly.java.net/

3. SUMMARYThe CloudThink platform, a joint effort of ETH and severalinternational partner institutions, has been created to makeautomobiles “first-class citizens” of the Web and enable third-party applications to easily access and process vehicle datawhile providing advanced services to drivers. We and othershave implemented several such applications on top of thisplatform, in particular in an effort to support users andapplications when interacting with connected vehicles: usingour systems, it is possible for users to directly interact withsensors and actuators of connected automobiles, monitor thecommunication of vehicles and clients in real time, and toseamlessly use functionality that is provided by cars withinphysical mashups.

The future developments for the CloudThink project includeexpanding the API to return interaction monitoring data forall available vehicles. Additionally, the ability for third-partyapplication builders to run their own scripts and modifyfirmware behaviour on the CARduino within safe and con-trolled boundaries will be implemented.

Acknowledgements. This work was supported by theSwiss National Science Foundation under grant number341627 and the SUTD-MIT International Design Center.The authors thank Yassin N. Hassan and Gabor Soros fortheir help with the object recognition and interactions visu-alization software.

4. REFERENCES[1] E. Wilhelm, J. Siegel, S. Mayer, J. Paefgen,

V. Tiefenbeck, M. Bicker, S. Ho, R. Dantu, andS. Sarma, “CloudThink: An Open Standard forProjecting Objects into the Cloud,” MassachusettsInstitute of Technology, ETH Zurich, SingaporeUniversity of Technology and Design, and theUniversity of North Texas, Tech. Rep., 2013.

[2] T. Lotan and T. Toledo, “An In-Vehicle Data Recorderfor Evaluation of Driving Behavior and Safety,”Transportation Research Record, vol. 1953, pp. 112–119,2006.

[3] J. Paefgen, T. Staake, and F. Thiesse, “Resolving theMisalignment between Consumer Privacy Concerns andUbiquitous IS Design: The Case of Usage-basedInsurance,” in Proceedings of the 33rd InternationalConference on Information Systems (ICIS), 2012.

[4] J. Zantema, D. H. van Amelsfort, M. C. J. Bliemer,and P. H. L. Bovy, “Pay-as-You-Drive Strategies: CaseStudy of Safety and Accessibility Effects,”Transportation Research Record, vol. 2078, pp. 8–16,2008.

[5] R. C. Smith, S. Shahidinejad, D. Blair, and E. L.Bibeau, “Characterization of urban commuter drivingprofiles to optimize battery size in light-duty plug-inelectric vehicles,” Transportation Research Part D:Transport and Environment, vol. 16, no. 3, pp. 218–224,2011.

[6] S. Rogers, P. Langley, and C. Wilson, “Mining GPSData to Augment Road Models,” in Proceedings of the5th ACM SIGKDD International Conference onKnowledge Discovery and Data Mining (KDD), ACM,

1999, pp. 104–113.

[7] W. Shi and Y. E. Liu, “Real-time urban trafficmonitoring with global positioning system-equippedvehicles,” Intelligent Transport Systems, vol. 4, no. 2, p.113, 2010.

[8] Rick Walter, “Fuel Economy Data,” 2014. [Online].Available: http://www.cert.ucr.edu/events/pems2014/liveagenda/24walter.pdf

[9] S. Mayer, M. Schalch, M. George, and G. Soros,“Device Recognition for Intuitive Interaction with theWeb of Things (Poster Abstract),” in AdjunctProceedings of the 2013 ACM International JointConference on Pervasive and Ubiquitous Computing(UbiComp), ACM, 2013, pp. 239–242.

[10] S. Mayer and G. Soros, “User Interface Beaming –Seamless Interaction with Smart Things usingWearables,” in Proceedings of the Glass and EyewearComputers Workshop, 2014.

[11] S. Mayer, A. Tschofen, A. K. Dey, and F. Mattern,“User Interfaces for Smart Things – A GenerativeApproach with Semantic Interaction Descriptions,”ACM Transactions on Computer-Human Interaction,vol. 21, no. 2, 2014.

[12] S. Mayer, N. Inhelder, R. Verborgh, R. V. de Walle,and F. Mattern, “Configuration of Smart EnvironmentsMade Simple – Combining Visual Modeling withSemantic Metadata and Reasoning,” in Proceedings ofthe 4th International Conference on the Internet ofThings (IoT), 2014.

[13] S. Mayer, Y. N. Hassan, and G. Soros, “A Magic Lensfor Revealing Device Interactions in SmartEnvironments,” in Proceedings of the SIGGRAPH Asia2014 Symposium on Mobile Graphics and InteractiveApplications (MGIA), 2014.

[14] F. Dotzer, “Privacy Issues in Vehicular Ad HocNetworks,” in Privacy Enhancing Technologies, ser.Lecture Notes in Computer Science, G. Danezis andD. Martin, Eds., Springer, 2006, vol. 3856, pp. 197–209.