Increase of Travel Safety for Public Transport by Mobile Applications

Wolfgang Kluth, Karl-Heinz Krempels, Christoph Terwelp and Stefan W¨uller

Information Systems & Databases, RWTH University, Aachen, Germany

Keywords:

Public Transport Systems, Emergency Call Processing, Context Awareness.

Abstract:

Mitigating vandalism in local trafﬁc and at stations, violent disorder, and theft by employing security guards,

installing video cameras are expensive and only partially solve existing the problems. Related costs directly

affect the fares and thus the attractiveness of local public transport. We discuss a concept to implement a

Report-service to forward emergency and complaint messages in local public transport. The service is based on

a mobile application and a message routing system. The aim is to increase travel safety and the attractiveness

of the local public transport. On the base of theoretical approaches and the usage of paper prototypes we show

the possibilities how such a Report-service could be implemented.

1 INTRODUCTION

The local public transport offers a lot of beneﬁts com-

pared to the individual transport. On the one hand,

considering the continuous increasing of petrol prices

and the problematic parking situation in many Ger-

man cities, the local public transport will gain impor-

tance. On the other hand, German transportation com-

panies are struggling with a variety of problems, e.g.,

delays, vandalism, late removalof defects, and the co-

ordination of complaints and problem reports incom-

ing decentralized. Hence, a lot of trafﬁc participants

are discouraged to switch to local public transport.

The countermeasures to mitigate vandalism in lo-

cal trafﬁc and at stations, violent disorder, and theft

by employing security guards, cooperating with the

police, installing video cameras, and school projects

are expensive and solve the problems only partially

(Bahn.de, 2011), (Schumacher, 2009). The related

costs directly affect the fares and thus the attractive-

ness of local public transport.

Until now the participants were left on their own

transmitting information to the transportation compa-

nies, e.g., they have to search for phone numbers or

email addresses of the responsible department. This

possibly entails that information can’t be forwarded

locally instead only when the participant is able to

access the internet. By then, important information

details can be lost. Absence of feedback and the un-

certainty that the information reaches the right divi-

sion, possibly inﬂuences the participant’s motivation

and willingness of forwarding information. With re-

gard to the transportation companies similar problems

occur. If information reach the wrong division or is

forwarded incorrectly, they can’t be processed ade-

quately. In the worst case the information becomes

worthless.

An approach for an interface to exchange infor-

mation between transportation companies and their

participants would be desirable to improve the travel

safety preventively and the client satisfaction as well

as saving expenses.

In this position paper we present an intermodalap-

proach to realize such a measure in form of a mobile

application we call Report combined with a central

reporting unit. With this application the participant is

able to forward emergencyand complaint messages to

a central reporting unit which in turn controls the for-

warding to the involved institutions. The integration

of smartphones entails the advantage that no longer,

participants are on their own by searching for the cor-

rect contact and information reach the wrong place.

Furthermore involving the smartphones components

and the application’s user interface, the participants

can be led through the input procedure and supported

with articulation.

This paper is structured as follows: By means of

use case scenarios, provided in Section 2, we out-

line how the Report-application could be integrated

in the local public transport and simplify the informa-

tion forwarding. With Section 3 we give a survey of

related work, followed by our theoretical approach in

Section 4, depicting the essentials for the central re-

porting unit as well as the analysis of the requirements

106

Kluth W., Krempels K., Terwelp C. and Wüller S..

Increase of Travel Safety for Public Transport by Mobile Applications.

DOI: 10.5220/0004642801060114

In Proceedings of the 4th International Conference on Data Communication Networking, 10th International Conference on e-Business and 4th

International Conference on Optical Communication Systems (ICE-B-2013), pages 106-114

ISBN: 978-989-8565-72-3

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

and the input data of the application. With Section

5 we present our paper prototype and its evaluation.

Finally with Section 6, we summarize our approach,

depict the next steps, and provide an outlook for en-

hancements and additional areas of deployment.

2 USE CASE SCENARIOS

Based on the following use case scenarios, we exem-

plify the advantages the Report application entails and

sketch possible operational scenarios.

2.1 Forwarding a Hazard Warning

Late at night, Richard waits at the underground sta-

tion for his line to get home. He discovers a heavy

metallic object lying on the rails. To prevent a col-

lision with the underground he uses his smartphone

to report the hazardous situation. He sends an emer-

gency message selecting the option that the rails are

blocked by an object from a list of predeﬁned option.

Further information concerning Richard’s location are

determined automatically and appended to the emer-

gency message by the Report-application in the back-

ground. The central reporting unit processes the re-

ceived message and forwards it to the involved enti-

ties, e.g, the affected underground lines and the trans-

portation company.

2.2 Reporting an Act of Violence

In the early morning, Jessica drives to her position

by train. In the same compartment she watches two

groups of youths between which it comes to a con-

tention followed by acts of violence. Thereby, the in-

stallations of the train get damaged. To prevent grab-

bing the youths attention, Jessica inconspicuously ac-

cesses her smartphoneto send an emergencymessage.

She indicate the presence of a threatening situation

involving a scufﬂe. Additionally, Jessica roughly in-

dicates her position in the train and adds a photo of

the happening. Automatically the Report-application

adds personal details and the train number. The cen-

tral reporting unit forwards the message to the trans-

portation company and the closest police station.

2.3 Notiﬁcation of a Defective Elevator

Charlie visits his relatives traveling by train. He ar-

rives at a provincial station and because he carries a

lot of luggage, he wants to take the elevator on his way

to the exit. He realizes that the elevator is not work-

able. Since there is no staff he can turn to, he uses his

Report-application to inform the transportation com-

pany within seconds. Fortunately, the application de-

termines his position and appends it to the message

because Charlie is not familiar with the environment.

On the same day, Charlie gets an pleasant answer that

the defect will be ﬁxed as soon as possible.

3 RELATED WORK

A large part of reporting systems research is dis-

cussing the analyzing and ﬁltering of social media

(e.g., Twitter

, Facebook

) for detecting patterns of

civil relevance (Kavanaugh et al., 2011), (Linders,

2011). Additionally, there are approaches involving

citizens taking part in creating government decissions

(Greenwood et al., 2012) on the base of social net-

works.

The focus in this chapter lies on target based and

explicit digital data collections for emergencies and

complaints transmitted by citizens in the domain of

public transport. We have to increase the radius of the

topic, because there is no related work for the special

domain of public transport. Digital citizens engage-

ment in civil matters include a few research projects

and a lot of running applications. The related work is

strictly split into reporting complaints and emergen-

cies.

Typical examples for mobile complaint services

are FixMyStreet

, SeeClickFix

, NeatStreets

, and

CitySourced

where citizens report complaints online

via website or mobile application. Users can create

reports (in most cases inputs are images, locations, a

type, and a description) and get an overviewof reports

in different areas. Town administrations can subscribe

to their region to get the newest complaints in their

area. 1,748 reports were posted in week no. 22 at

FixMyStreet.

In (Foth et al., 2011) an iOS App is presented

which works as an overlay for an online formula for

complaints with similar inputs like the mentioned ser-

vices. Their evaluation illustrates the positive aspects

of reporting complaints via mobile devices. For their

future work they plan an enlarged feedback system to

include the citizens into the act of improvement.

A further approach is (Whittle et al., 2010) which

is a complaining system based on a kiosk system, lo-

cated in a city. Citizens can give comments on current

http://www.twitter.com

http://www.facebook.com

http://www.ﬁxmystreet.com/

http://seeclickﬁx.com/

http://neatstreets.com.au/

http://www.citysourced.com/

IncreaseofTravelSafetyforPublicTransportbyMobileApplications

107

problems and suggestions how to improve it.

In contrast to complaining services, emergency

services, especially mobile emergency applications

on the basis of distress radiobeacon are major tools

in this area. Mobile applications like Emergency Dis-

tress Beacon

, CerberTouch

, CrimePush

and Emer-

gency Beacon

send messages with a predeﬁned

emergency text and user’s location. While the most

functional approaches are available in the App Store,

research is mostly done on the technical site to in-

tegrate GPS coordinates into emergency messages

(Stastny and Merka, 2006).

Another approach is the community platform

SpotCrime

, where users can report crimes and

emergencies to an online platform to make crime pub-

lic and comprehensible.

Overall, the applications and approaches show

that there is currently no system which combines

emergency and complaining reports in one tool. Fur-

thermore, the degree of complexity for input data

ist very low. There is no positioning operation for

moving vehicles like trains or more complex places

like rail stations. The classiﬁcation of complaints is

mostly based on one stage, while for complex infras-

tructures with many departments a ﬁner classiﬁcation

is essential for a fast and robust work ﬂow. This is

where we focus on.

4 APPROACH

The Report-service basically consists of two compo-

nents: the mobile Report-application and the cen-

tral reporting unit (see Figure 1). The transporta-

tion company supplies the Report-application which

its customers can download on their smartphones. To

send an emergency or a complaint message the cus-

tomers interact with the mobile application’s user in-

terface which requests all relevant information from

him. The message is send to a system of servers,

the central reporting unit, which makes the decision

based on routing information where to forward the

message to. The notiﬁed institution is able to directly

process the transmitted information and is able to get

in touch with the customer intermediately.

https://itunes.apple.com/us/app/emergency-distress-

beacon/id288770664

http://cerberus.briartek.com/cerbertouch

http://crimepush.com/

http://emergencybeaconapp.com/

http://spotcrime.com/

4.1 Requirement Analysis

We divide the requirement analysis into the analysis

of sending emergency messages and sending com-

plaint messages.

4.1.1 Emergency Messages

Especially time-critical situations (danger of life,

property damage, and infringing the law generally)

belong to the category of emergency. It is important

that those messages contain all relevant information

to enable processing them, that is to comply with the

ﬁve questions for the controlled process of emergency

calls:

Who? - identify yourself

What? - the reason for sending the message

Where? - the location of the event

How Many? - number of involved/injured people

When? - the point in time of the event

The Report-application has to require and request

those ﬁve items. Due to the time factor, the user inter-

face has to assist the user doing the input. Information

which the mobile device is able to determine by itself

shouldn’t be requested. Supporting user’s articulation

as well as providing precast options helps the user to

concentrate on the essential information and to save

time.

If the location is a station the following inputs

have to be made: the city where the station is located,

which kind of station it is, the name of the station, and

further location restrictions. We consider rail stations,

bus stops, tram stops, underground stations, and city

train stations.

If the locality is a transport the following in-

puts are required: the city of departure (to restrict

the transports to a speciﬁc environment), the kind

of transport (train, bus, tram, underground, and city

train), the train number or the line, and further loca-

tion restrictions of the transport, e.g., the wagon num-

ber or the seat number.

The determined event, this is the possible reason

for sending an emergency message, could be divided

into three categories: threat, hazard, and vandalism.

To declare the reason for an emergency message, the

event category and next a speciﬁc event from the pre-

deﬁned event list of the correlating category has to be

chosen. If the actual event is not listed, the descrip-

tion text could be use to describe the speciﬁc event.

The transmission time and veriﬁed contact infor-

mation are required, too. The latter are essential to

make contact with the sender.

ICE-B2013-InternationalConferenceone-Business

108

Figure 1: Report-Service in the Overall Context.

To realize time-critical actions, we take into account

the following approaches:

• design a clear, structured, and intuitive user inter-

face,

• involve hardware components of the mobile de-

vice to determine information in the background

to minimize user input,

• choice options instead of user input,

• search bars integrated into table views,

• send partial information ahead,

• store personal information,

• and use the camera of the mobile device.

4.1.2 Complaint Messages

If the user of the Report-application notices deﬁ-

ciency states concerning the transportation company

he is able to communicate it through sending a com-

plaint message. This action is less time-critical, hence

there are various possibilities to design the user in-

terface but still the same information are required as

for an emergency message. Still the user should be

supported doing his inputs by the smartphone, not for

time-critical reasons but to retain his willingness to

forward such messages.

The required inputs to describe the location are the

same as for emergency messages. Instead of events,

we consider deﬁciencies which we divided into four

categories: hygienic, architectural, functional and ser-

vice deﬁciencies. It has to be distinguished between

deﬁciencies concerning transports and stations. Just

as for emergency messages, the description text can

be used to input a deﬁciency not listed in the pre-

selections.

4.2 Hierarchical Structure

Classiﬁcation of the User Interface

On the basis of the previous sections we can construct

a taxonomy for information categories for the user

input (see Figure 2 which depicts the taxonomy for

emergency messages send from stations). From the

taxonomy we can deduce, to which information cate-

gory an input value belongs to. Furthermore the tax-

onomy provides a precise vocabulary, isolating infor-

mation classes from each other, and coins class names

for the implementation phase. The objects of the tax-

onomy can be mapped to hierarchical numbers as it is

done in Figure 2. With this technique we can use the

taxonomy analogously to a Management Information

Base (MIB). Dynamically adding those hierarchical

numbers depending on the sending procedure, they

can be used as routing information at the central re-

porting unit (see 4.3).

IncreaseofTravelSafetyforPublicTransportbyMobileApplications

109

Figure 2: Taxonomy for Emergency Messages from Stations.

4.3 Basic Concepts for the Central

Reporting Unit

For the implementation of the central reporting unit

the SOA-design pattern Intermediate Routing, applied

in the area of Content-Based Routing (CBR), is suit-

able. An incoming message at the Content-Based

Routing Agent (CBRA) is forwarded by its content

using decision logic.

The numbering we introduced in Section 4.2 en-

ables us to use the taxonomy for a Management In-

formation Base. Each object is called a Managed Ob-

ject (MO) and its number is called Object Identiﬁer

(OID). For clarity, the OID of each MO is depicted

as complete string from the beginning of the root ob-

ject, e.g., 1.1.1.3.1 instead of 1. The advantage of

employing the MIB pattern is that existing network

protocols can be used to integrate and handle OIDs

without modiﬁcation.

The central reporting unit uses the OID of in-

coming emergency and complaint messages for rout-

ing purposes, this is to decide to which instances

the message has to be forwarded. It is denoted as

x = x

. ... .x

In the following we assume that an emergency

message consists at most of two messages, the ﬁrst

one with the required and the second one with the op-

tional information. A complaint message consists of

one single message. The OIDs can be extended to

speciﬁc events and deﬁciencies by appending an ad-

ditional number to the OID string of the father object

for each of them.

Figure 3 depicts how the central reporting unit

could be realized applying the Intermediate Routing

pattern. A detail view of the Content-Based Routing

Agent demonstrates how the progressive process of

message forwarding proceeds. On the ﬁrst stage we

distinguish between emergency messages from sta-

tions and transports and complaint messages. Com-

plaint messages are forwarded immediately to the

transportation company. For emergency messages

there is a second stage to determine the event cate-

gory. If events are not speciﬁed any further (x

NULL) the message includes the ﬁrst part of the emer-

gency message which is send ahead and forwarded to

the responsible instances. If x

6= NULL the message

is forwarded depending on the selected event.

Introducing further routing variables regarding

cities, stations, and transports as well as using

company-internal Content-Based Routing Agents, a

precise forwarding to local branches and departments

could be realized.

ICE-B2013-InternationalConferenceone-Business

110

Figure 3: Dynamic Message Forwarding.

5 MOBILE APPLICATION

PROTOTYPE

In this work we used the concept of evolutionary pro-

totyping, this is continually enhancing an initial pro-

totype. The criteria for extendings, modiﬁcations, im-

provements, and new concepts were gained by inter-

mediate usability tests of paper prototypes which pro-

vide scenarios the Report-application can be used for.

Using paper prototypes we were able to simulate the

application for the end-user, demonstrate concepts,

examine design decisions, and localize problems.

In the following we present a sophisticated paper

prototype basing on the fundamentals of Section 4

and its evaluation. The evaluation has been carried

out with ten persons which regularly making use of

local transports and owning a smartphone.

5.1 Paper Prototype

Fig. 4 and 5 present the sophisticated prototype. Fig.

4 provides the prototype for sending emergency mes-

sages. The user starts with view 1 where he has to

specify the location of the event (station, transport).

If the location is a station it has to be speciﬁed

in view 2. Via tables with an integrated search bar

providing options, the city and the station’s name can

be selected. The location can be restricted, e.g., by

commitment of the track, the passage, or the forecourt

(see view 3.1 and 3.2). Pressing the button ’use po-

sition’ activates a routine which automatically deter-

mines the user’s position utilizing on location based

data provided by the smartphone and enables to re-

strict the location options in view 3.1 and 3.2.

In the next view(view 4), the eventhas to be deter-

mined, a description text, and a picture can be added

to the emergencymessage which is sent after pressing

the ’send’-button.

If transportation is selected the prototype works

similarly except instead of determining the station,

the transport and the location within the transporta-

tion have to be selected.

Figure 5 provides the prototype for sending com-

plaints. View 1,2, and 3 behave accordingly to the

prototype for emergency messages. Furthermore, in

view 4, ﬁrst the category of deﬁciencies is selected

whereupon in view 5 the speciﬁc deﬁciency with re-

spect to the speciﬁed location can be selected with

the help of a picker. The following views (6,7) ask

the user to add a description text or a picture to the

complaint-message. View 8 presents the transacted

inputs grouped by the information area. This view

enables the user to verify his inputs and to send the

message.

IncreaseofTravelSafetyforPublicTransportbyMobileApplications

111

Figure 4: Sophisticated Paper Prototype (emergency).

Table 1: Evaluation of the Emergency-Prototype.

evaluation of 1 2 3 4 x

clarity 1 9 0 0 1.9

understandability 1 9 0 0 1.9

simple operability 0 2 7 1 2.9

user guidance 1 7 2 0 2.1

no surprises 8 2 0 0 1.2

predictability 9 1 0 0 1.1

not fussy 2 7 1 0 1.9

efﬁciency of user guidance 1 6 3 0 2.2

efﬁcient operability 0 3 5 2 2.9

5.2 Evaluation

The usability test consists of four tasks. Task 1

and 2 describe scenarios the prototype is applied to.

Subsequently the users have to rate the operationality,

the predictability, and the efﬁciency. With task

3, asking the user to describe how speciﬁc views

could look like, we obtain information about the

consistency of our user interface. In task 4 there are

some contextless views the user has to embed into a

context. The evaluation bases on the grades the users

assigned, and their oral and written comments.

Figure 5: Sophisticated Paper Prototype (complaint).

Table 2: Evaluation of the Complaint-Prototype.

evaluation of 1 2 3 4 x

clarity 4 6 0 0 1.6

understandability 3 7 0 0 1.7

simple operability 1 4 5 0 2.4

user guidance 3 6 1 0 1.8

no surprises 9 1 0 0 1.1

predictability 9 1 0 0 1.1

not fussy 4 5 1 0 1.7

efﬁciency of user guidance 3 5 2 0 1.9

efﬁcient operability 1 5 4 0 2.3

The evaluation for the emergency-prototype and the

complaint-prototype can be found in Table 1 and 2

(1 is the best rating, 4 the worst). On average the

results for the complaint-prototype are a bit better,

but the tendencies stay the same. It becomes clear

that especially there are shortcomings concerning the

operating and the user guidance. Hence, the prob-

lematic aspects of both prototypes coincide, we cover

them all by concentrating on those which resulted

from the evaluation of the emergency-prototype.

View 1. To select the kind of station before the city

ICE-B2013-InternationalConferenceone-Business

112

is selected turned out to be unfavorable because

in many cities there is no underground, suburban

train, or tram.

View 2. There are deﬁcits in the user guidance. In

view 2, input related to the station is requested. In

view 3, the city and again information concerning

the station are required.

View 3. There is the possibility to create wrong in-

put: It is possible to enter the city and next the

station in this city. Afterwards the city can be

changed again. The station will be an invalid one

for that city.

View 4. The ’use location’-button is positioned in-

conveniently because it counteracts the operating

sequence. To list the chosen location once more

proved to be annoying because it wastes the re-

stricted display space. An option to choose a spe-

ciﬁc event required. So far it is only possibly to

specify an event using the description text. The

association between the photo button, located in

the navigation bar, and the corresponding table

entry couldn’t be deduced contemporary.

View 6. To consider trains generally instead of re-

stricting them to the departure location turned out

to be unfavorably.

View 7. Similar problems to view 4 occurred. Fur-

thermore the grouped table view should be used

to separate synonymous information.

Generally. It came out that there are areas for im-

provement considering the distribution of infor-

mation requests. For now, it is not possible to

send urgent information, e.g., the precise location,

ahead and process them appropriately. Further-

more it is not obvious which requested informa-

tion are required and which are optional.

5.3 Solution Approaches

The following solution approaches describe how to

circumvent the problematic aspects listed above.

We discarded the ’use location’-button. If GPS

coordinates are available, the city is determined in the

background and ﬁlled into the appropriate table cell

automatically. Furthermore, the spatial data is used

to determine nearby stations and transports whose

course of the road coincide with it to restrict the pre-

selections. There is still the possibility to change

those data manually. If the smartphone is not able

to determine spatial data this has to be communicated

to the user early.

Furthermore we relinquished the repetition dis-

playing data to give an overview. For time-critical

activities, duplicated information are counterproduc-

tive.

Instead of providing a photo-button in the naviga-

tion bar, a picture can be taking by interacting with

the corresponding table entry in view 4.

The absolutely required information for emer-

gency messages is the city, the station or the trans-

portation, and the event category.

The focus of the occurred problemsis on the struc-

ture of the user interface. It has to be redesigned to

accommodate the requirements. View 2 and 5 were

discarded. If the station option is selected in view

1, the required information a requested: city, sta-

tion/transportation, station’s name/train number/line,

and the event category. This view is completed with

a ’send’ button which sends the required information

ahead. Afterwards, the user is able to ﬁll in optional

information: a restriction of the location, a restriction

of the event, a description text, and taking a photo.

Those data can be send independently of the required

data. For complaint-messages the same information

are relevant but they don’t have to be categorized by

urgency. Instead they are retrieved by context.

6 CONCLUSIONS

AND FUTURE WORK

This position paper presents basic approaches and

concepts to implement a central service for mobile

devices to send emergency and complaint messages

in the area of local public transport. The next step

would be to implement this approach for a speciﬁc

mobile platform followed by an evaluated ﬁeld test.

There are other non considered ﬁelds, the Report-

service could be applied to, e.g., the urban space. The

Report-service could be used to improve the urban

security architecture and the civilian security by en-

abling message forwarding to the police, the ﬁre ser-

vice, the regulatory agency, and contract cleanings to

call attention to crime, dangers, vandalism, and pol-

lution. Especially, this approach can be utilized to

improve the sense of security in areas of critical in-

frastructures.

The Report-service could be extended to an infor-

mation platform regarding behavior in critical situa-

tions, sensitization of citizen for hazards and dangers,

and to communicate improvement suggestions con-

cerning the urban design.

The question rises how to motivate customers and

citizens to make use of the Report-service. On the one

hand, there already is the demand of such a Report-

service in Germany (see (Lange, 2011)). On the other

hand, the idea of providing feedback can be elabo-

IncreaseofTravelSafetyforPublicTransportbyMobileApplications

113

rated. It could be used to inform of and hand out of

premiums if the transportation company beneﬁts from

the forwarded information.

REFERENCES

Bahn.de (2011). Sicherheit der Fahrgaeste im Fokus der S-

Bahn Hamburg. http://www.s-bahn-hamburg.de/

hamburg/view/aktuell/presse/sicherheit.shtml.

Foth, M., Schroeter, R., and Anastasiu, I. (2011). Fix-

ing the city one photo at a time: mobile logging of

maintenance requests. In Proceedings of the 23rd

Australian Computer-Human Interaction Conference,

OzCHI ’11, pages 126–129, New York, NY, USA.

ACM.

Greenwood, P., Rashid, A., and Walkerdine, J. (2012). Ude-

signit: towards social media for community-driven de-

sign. In Proceedings of the 2012 International Con-

ference on Software Engineering, ICSE 2012, pages

1321–1324, Piscataway, NJ, USA. IEEE Press.

Kavanaugh, A., Fox, E. A., Sheetz, S., Yang, S., Li, L. T.,

Whalen, T., Shoemaker, D., Natsev, P., and Xie, L.

(2011). Social media use by government: from the

routine to the critical. In Proceedings of the 12th An-

nual International Digital Government Research Con-

ference: Digital Government Innovation in Challeng-

ing Times, dg.o ’11, pages 121–130, New York, NY,

USA. ACM.

Lange, M. (2011). Nicht meckern, sondern rasch Loesun-

gen ﬁnden. http://www.bahn.de/dbbahn/view

/interview-facebook-huesing.shtml.

Linders, D. (2011). We-government: an anatomy of citi-

zen coproduction in the information age. In Proceed-

ings of the 12th Annual International Digital Govern-

ment Research Conference: Digital Government In-

novation in Challenging Times, dg.o ’11, pages 167–

176, New York, NY, USA. ACM.

Schumacher, O. (2009). Starker Anstieg von Vandalismus

und Grafﬁti. http://www.pressrelations.de/new

/standard/result

main.cfm?aktion=jour pm&r=393613.

Stastny, R. and Merka, M. (2006). Next generation emer-

gency services: die zukunft der notrufe. e & i Elek-

trotechnik und Informationstechnik, 123(7-8):323–

332.

Whittle, J., Simm, W., Ferrario, M.-A., Frankova, K., Gar-

ton, L., Woodcock, A., Nasa, B., Binner, J., and Ariy-

atum, A. (2010). Voiceyourview: collecting real-time

feedback on the design of public spaces. In Pro-

ceedings of the 12th ACM international conference

on Ubiquitous computing, Ubicomp ’10, pages 41–50,

New York, NY, USA. ACM.

ICE-B2013-InternationalConferenceone-Business

114