1. Optimizing Meeting Scheduling in
Collaborative Mobile Systems through
Distributed Voting
PerCol 2010 Workshop @ PerCom 2010, Mannheim, Germany
Ville Antila,
Jani Mäntyjärvi,
Ville Könönen
VTT Technical Research Centre of Finland,
Oulu, Finland

2. 12/04/2010 2

3. 12/04/2010 3
Overview
Introduction and motivation for the topic
Short description about the concepts of the paper
Voting mechanisms
Using voting for decision making in meeting negotiation
Utilizing user preferences in meeting scheduling
Example scenario
Prototype platform for mobile “person-to-person” collaboration
Discussion
Possibilities for future work
Conclusions

4. 12/04/2010 4
Introduction/Motivation
Mobile devices are widely used for personal information management
(PIM)
Much of this information is not fully utilized currently beyond the local
use
In contrast, much of the current (“computer-mediated”) collaboration is
done using Web-based applications and services
These are not usually very usable or effective used on-the-go (via a
mobile device)
There is a gap in between – for utilizing the implicit information
management and communication possibilities on mobile devices
But, in order to fully utilize the possibilities of pervasive devices we need
more (efficient) ways of interaction with this information
One way is automation of user tasks
In this study we are looking into automating meeting scheduling
between agents in a mobile user setting

5. 12/04/2010 5
Meeting negotiation
The goal of meeting negotiation: to schedule several people in the
same place at the same time…

6. 12/04/2010 6
Distributed decision making (1/3)
The goal for decision making is to make optimal decisions with
respect to a utility function modeling the preferences of the
decision maker
So to put simply: to find a solution which is the most suitable
one for the all of the participants/agents involved in the voting
(weighting out collisions, outliers etc.)

7. 12/04/2010 7
Distributed decision making (2/3)
Distributed decision making can be used to obtain more accurate
or suitable results for a group of ”participants” (participating in the
voting)
One example could be for a group of devices near-by each
other deciding on a shared context *
The goal in this is to detect the outliers and improve the
accuracy of the decision
* Könönen, V. & Mäntyjärvi, J. Decision Making Strategies for Mobile Collaborative Context
Recognition. Proceedings of the 4th International Mobile Multimedia Communications Conference,
MobiMedia 2008.

8. 12/04/2010 8
Distributed decision making (2/3)
Distributed decision making can be used to obtain a more accurate
or suitable results for a group of ”participants”we in
Are (participating in the
voting) PerCom2010?
One example could be for a group of devices near-by each
v
other deciding on a shared context *
v
The goal in this is to detect the outliers and improve the
accuracy of the decision
I am
(with
confidence) v
v
??
Me too (Where am I?)
(with some
confidence)
* Könönen, V. & Mäntyjärvi, J. Decision Making Strategies for Mobile Collaborative Context
Recognition. Proceedings of the 4th International Mobile Multimedia Communications Conference,
MobiMedia 2008.

9. 12/04/2010 9
Distributed decision making (3/3)
In this study we use distributed decision making in deciding on an
optimal time slot for a group of users to have a meeting (i.e.
meeting negotiation)
The decision is done over the user preferences and known
timetable constraints (availabilities)
Is tomorrow
Yep
9am ok for a (Just
meeting? fantastic)
v v
Ok v
Nope
(but only if it’s
important, I’m a v (can’t make it,
busy guy) luckily)

10. 12/04/2010 10
Voting in decision making for meeting scheduling
The simple goal for meeting negotiation is to find an optimal
timeslot from the groups’ calendars
OK
In addition we have consider an added requirement of minimizing
the communication cycles to obtain the optimal result
Hypothesis: By distributing part of the decision making processes
to the peer devices we can obtain satisfying results with a single
request-response cycle

11. 12/04/2010 11
Utilizing user preferences
A: Day of Week defines which weekdays are more preferable
B: Time of Day, defines which hours are more
preferable
C: Meeting Host, defines the importance of a meeting depending on the host (this
can be used to decide between meeting requests falling on the same timeslot)
D: Meeting Length, defines the importance of a meeting depending on its length
(this can be used to decide between meeting requests falling on the same
timeslot)

12. 12/04/2010 12
Automated meeting negotiation process
Each peer device has a calendar including the availability of the
corresponding person
Each device will also have user preferences of the corresponding
person
The decision between a set of possible meeting requests (on a
personal level) is done according to the above mentioned aspects
Then this information is returned to the meeting scheduler (the
host)
The host decides on the meeting time by assessing the “peer
winner” meeting slots and the weights given to them

13. 12/04/2010 13
Used voting process – a two phase approach
Phase 1 - Distributed ordering of requests (done on the peer devices)
The alternatives gets points based on their position in the voter’s
preference list
The first one gets n points, the second n-1 until the last one gets 1
point.
If a voter is indifferent to 2 or more alternatives, each one gets the
average of the alternatives
E.g. if the preference list is: p = {a, {b, c, d}, e, {f, g}}, then: g and f
gets 1.5; e gets 3; d, c, b each get 5 and a gets 7
Phase 2 - Deciding the winner through weighted majority voting (done on
the meeting host’s device)
The host will decide on the optimal solution by summing up the
received votes for each option returned by the peers
Finally, the host will distribute the decided meeting to the peer group
to complete the task.

14. 12/04/2010 14
Example scenario (1/6)
The user scenario consists of a small mobile team of five persons
(John, Jack, Jane, Peter and Emily)
All of the participants have their own user preferences for
meetings, mainly these can effect the decision of a meeting date
and time between different options
A: Day of Week Mon Tue Wed Thu Fri Sat Sun
Jack 0.65 0.85 0.7 0.7 0.5 0.1 0.05
Jane 0.7 0.95 0.8 0.9 0.7 0.15 0.1
Peter 0.8 0.75 0.5 0.6 0.4 0.2 0.05
Emily 0.95 0.85 0.7 0.8 0.8 0.15 0.1
Dimension A: example user preferences for the Day of Week
B: Time of Day 8am 9am 10am 11am 12pm 1pm 2pm 3pm 4pm 5pm 6pm
Jack 0.7 0.9 0.5 0.3 0.8 0.9 0.6 0.7 0.75 0.1 0.02
Jane 0.5 0.85 0.65 0.2 0.7 0.95 0.75 0.6 0.86 0.5 0.1
Peter 0.6 0.8 0.7 0.1 0.9 0.9 0.9 0.9 0.5 0.3 0.01
Emily 0.8 0.9 0.9 0.02 0.8 0.9 0.75 0.9 0.4 0.3 0.05
Dimension B: example user preferences for the Time of Day

15. 12/04/2010 15
Example scenario (2/6)
In order to balance out differences in weighting the dimensions we
use the ratio of each dimension to the total amount of weights
given by the user
For example, the ratio for dimension A is calculated as the
following:
RA PAH 100 0.85 100 27
i
Pi 3.1
Weights of Ratio of dimensions A B C D
dimensions A B C D Total Jack 27 29 23 21
Jack 0.85 0.9 0.7 0.65 3.1 Jane 29 32 21 18
Jane 0.8 0.9 0.6 0.5 2.8 Peter 29 29 23 19
Peter 0.9 0.9 0.7 0.6 3.1 Emily 29 32 25 14
Emily 0.85 0.95 0.75 0.4 2.95 The ratio for each dimension is calculated form the
user-defined weights
Example of user-specific weights for each dimension of preferences –
these weights are used to calculate the balanced weight ratio

16. 12/04/2010 16
Example scenario (3/6)
Taking into account the example user preferences, let’s consider
an example decision making process between a set of possible
meetings
John sends requests for a meeting for the team with the following
set of times and dates: at Monday 9am or 10am or at Tuesday
1pm or 2pm
ID A B C D
MR1 “Mon” “9am” “John” “60min”
MR2 “Mon” “10am” “John” “60min”
MR3 “Tue” “1pm” “John” “60min”
MR4 “Tue” “2pm” “John” “60min”
Example set of meeting requests

17. 12/04/2010 17
Example scenario (4/6)
The first voting is done on the peer devices by ordering the meeting requests
according to the user preferences
The number of votes for each meeting request (MR) is calculated by summing
up the votes of each dimension of that request
The votes for each dimension are calculated by multiplying the utility value of
the alternative (e.g. 1.5) with the weight ratio (e.g. 27) for that dimension:
Jack: MR3 (306 votes)
Jane: MR3 (295 votes)
Peter: MR1 (264.5 votes)
Emily: MR1 (294.5 votes)
In the weighted majority voting the winner is Meeting Request 3 (MR3: 601
votes)
MR1: 264.5 294.5 559
MR3: 306 295 601

18. 12/04/2010 18
Example scenario (5/6)
According to Jack’s preferences the best alternative is Meeting
Request 3 (MR3), with the weight 306
MR1: ( 27 1.5) ( 29 3.5) ( 23 2.5) ( 21 2.5) 252
MR2: (27 1.5) (29 1) (23 2.5) (21 2.5) 179.5
MR3: (27 3.5) (29 3.5) (23 2.5) (21 2.5) 306
MR4: (27 1.5) (29 2) (23 2.5) (21 2.5) 262.5
Winner: MR3 (306)

19. 12/04/2010 19
Example scenario (5/6)
ID A B C D
MR1 “Mon” “9am” “John” “60min”
MR2 “Mon” “10am” “John” “60min”
MR3 “Tue” “1pm” “John” “60min”
MR4 “Tue” “2pm” “John” “60min”
Jack (MR1): ( 27 1.5) ( 29 3.5) ( 23 2.5) ( 21 2.5) 252
A: Day of
Week Mon Tue Wed Thu Fri Sat Sun
Jack 0.65 0.85 0.7 0.7 0.5 0.1 0.05
B: Time of Day 8am 9am 10am 11am 12pm 1pm 2pm 3pm 4pm 5pm 6pm
Jack 0.7 0.9 0.5 0.3 0.8 0.9 0.6 0.7 0.75 0.1 0.02

20. 12/04/2010 20
Example scenario (6/6)
In addition to the presented values we can also have a ranking for
each of the participants according to their “necessity” to participate
In this case we would multiply the given weight for an alternative with
the necessity assessment for that particular participant (e.g. .25, .5,
.95)
In overall, this simple voting scheme allows us to weight the
availabilities, user preferences and the necessities for any given
person to participate to a meeting
Nevertheless, this model is not bullet-proof in all the cases since
there can be cases where the majority of others would over-rule a
single participant, even if the others would be almost indifferent for
several options
One way to deal with these “close-draw” situations would be to
consult the meeting host to decide on the best option subjectively

21. 12/04/2010 21
Prototype platform for collaborative meeting
scheduling*
Integrates a lightweight Web service architecture and a mobile device
equipped with a standard Web server and a Web-based UI (for example a
browser)
Can be characterized as a distributed client-server architecture
Can be extended to provide different services or applications with a unified
Web service API structure
Possible to use in an infrastructure connectivity (like 3G) or in an ad hoc (Wifi)
mode
* Antila, V. & Mäntyjärvi, J. Distributed RESTful Web Services for Mobile Person-to-Person Collaboration. Proceedings of Third
International Conference and Exhibition on Next Generation Mobile Applications, Services and Technologies, NGMAST'09, 2009.

22. 12/04/2010 22
Discussion (1/2)
Goals:
Reduce computational complexity but still get satisfying results
This is achieved by adding the “utility values” for each
decision done on the peer devices
Can affect in the close draw situations and to assure the
availability of key participants
Design so that user preferences can not be ”over emphasized”
Using proportional amounts of the overall amount of
weights (so if all of the dimensions are ranked high, their
effect will be balanced out)
This way the participants can not benefit from
exaggerating the importance factors on their calendar

23. 12/04/2010 23
Discussion (2/2)
Challenges:
The input of user preferences
Should be done “invisibly”
Could use initial ordering and learning from previous decisions
(to accept or reschedule)
User control over automation should be endorsed
All the actions should be authenticated and accepted by users in
the end (is this a bottleneck?)
Therefore can work maybe more as an “intelligent adviser” than
a fully automated agent
Evaluation
Evaluation weather the result is satisfying to the participants is
very subjective -> would need a longitudinal user study
This is something that we are looking into

24. 12/04/2010 24
Future work possibilities (1/2)
The use of voting schemes in distributed and pervasive systems
Can provide means for deciding on a shared state or to come
to a conclusion over a set of possibilities
For example devices can vote on their view about the
high-level context (such as “in a meeting”) to come to a
conclusion on the shared state for all of the co-located
devices
Can provide means for collaborative task automation by giving
more information to the user to decide on an action
For example by consulting the preferences of participants
for a given meeting time slot, it is possible to reduce
communication and rescheduling overhead between the
participants

25. 12/04/2010 25
Future work possibilities (2/2)
Other (remotely related) ideas for using voting in pervasive
systems:
Advertisement auctions (using voting mechanisms) in a
pervasive environment (e.g. mobile context-aware
advertisement)
Pervasive (dynamic) groups
Context adaptation in a group
Decision over an adaptation process within a group of
devices or a smart space
Joining a (context-based dynamic) group by voting among
the group members

26. 12/04/2010 26
Conclusions
We see that information management and collaboration in
pervasive applications could be enhanced by automating user’s
tasks
We have presented a solution for automating meeting negotiation
in a peer-to-peer mobile environment
Done using two-phased voting process
Targets to a satisfying result (also subjectively) using a single
request-response cycle
We have given an analysis of the process using an example
meeting negotiation process
We conclude that the process can help automate meeting
negotiation tasks in a mobile person-to-person interaction

27. 12/04/2010 27
Thank you!
Questions?
ville.antila@vtt.fi