A Personal Meeting Scheduling
Agent
Elhadi M. SHAKSHUKIa,b*, S M Mozammal HOSSAINa
a
Jodrey School of Computer Science, Acadia University, Wolfville, Nova Scotia,
Canada B4P 2R6
b
King Faisal University, Al-hassa, Kingdom of Saudi Arabia 31982
* TEL: +1- 902-585-1524 FAX: +1- 902-585-1067 Email: elhadi.shakshuki@acadiau.ca;
eshakshuki@kfu.edu.sa
When setting up a meeting, meeting participants need to reach a mutual agreement to hold the
meeting subject to their personal constraints and preferences. It is a time consuming process and a
variety of calendaring applications are in use assisting users to schedule meetings. Software
applications failed to overcome the constraints of the traditional scheduling process and works as a
supporting tool for managing meeting information. One of the main constraints in automated
scheduling is the unavailability of a standard structured communication protocol. In addition,
automated scheduling requires other issues to be considered such as automated decision making
paradigm, negotiation strategy selection mechanism, etc. This paper proposes a Personal Meeting
Scheduling Agent (PMSA) and a Personal Meeting Scheduling Protocol (PMSP). PMSP is
embedded in the PMSA for handling bilateral and multilateral negotiations. PMSA is designed
using model-based, goal-based methodology. Additionally, PMSP is designed following a
structured negotiation protocol influenced by Simultaneous Response Protocol (SRP). To evaluate
all meeting invitations and to make decisions subject to users’ preferences, participants’ profiles,
and the schedule availability, this paper utilizes the Naïve Bayes model of Maximum Likelihood
Estimation. The PMSP goal is to automatically make decisions and select the appropriate
negotiation strategies to avoid or resolve possible meeting conflicts. To demonstrate the feasibility
of the proposed PMSP, a simulation environment with experimental results is presented.
Meeting scheduling; Negotiation; Strategy selection;
1. Introduction
Meeting Scheduling (MS) is a well-known naturally distributed agreement problem [1][2][3].
It is a routine, tedious and time consuming daily activity. MS requires coordination and
cooperation among all attendees [4][5]. Efficient scheduling is hard [1]. A wide range of
scheduling tools is in use for scheduling meetings in large office environment. For example,
traditional paper planners, telephone arrangements, face-to-face meetings, and sophisticated
calendaring tools are commonly used software tools for scheduling meetings. Recently, web-based
calendaring tools and instant messaging has also gained popularity for the same purpose [2][6][7].
These diverse methods to perform scheduling activities show the rigidity of the process [2] and the
need for an automated tool to perform the scheduling task automatically.
Managing time is essential for a busy decision maker. In particular, the management of
interactions with other people, including colleagues and customers, involves careful scheduling,
1
and calendar adjustment [8]. Engaging a personal assistant is a natural solution for the problem.
Traditionally, one’s daily schedule has been managed by engaging a Personal Assistant (PA) or by
the person himself maintaining a notebook or electronic calendar. Computing technology has
transformed this traditional scheduling process into a hybrid structure i.e. a mixture of traditional
methods and using software applications. A typical appointment or meeting request in this hybrid
structure is as follows: 1) a person requests for a meeting to the PA, 2) the PA checks the
availability of time, and 3) the PA confirms or proposes a new meeting time to the meeting
requester. At the end of a successful scheduling process, the PA enters the meeting data into the
recipient’s electronic calendar to inform their daily or weekly schedule. Though this process has
proved efficient, it has two major drawbacks. Firstly, it requires a mediator to convey meeting
information from a meeting inviter to a PA and from a PA to a meeting invitee. Secondly, it
increases operational cost by engaging an additional person as a PA and cost of the software
applications. Although, electronic communication makes easier to initiate a meeting invitation
directly, one’s schedule is still maintained manually using the traditional method.
A PA is becoming a luxury considering the operational costs. To reduce operational costs, one
of the popular approaches is to outsource the scheduling task. Electronic communication makes
outsourcing possible. It is a convenient way to reduce operational costs and achieve efficiency.
The outsourcing industry is growing rapidly. These are found mostly in third world countries
where labor cost is low. Outsourcing companies provide many services such as data entry,
programming, call centers, and most surprisingly Virtual Personal Assistant (VPA). Many
companies and individuals, e.g. medical practitioners are engaging a VPA located in a different
geographical location. Although this approach reduces the operational costs, it violates user
privacy. One’s daily schedule information is a sophisticated piece of information and it may bring
serious consequences if the information is made public.
Email is a flexible and powerful computer-mediated communication medium. Initially, email is
designed for maintaining regular day-to-day electronic communication. However, email has been
in use for many formal and informal coordinated regular activities such as scheduling a meeting
[2]. Calendaring applications such as Microsoft Outlook, Novell GroupWise are the most
commonly used and well adapted software platforms for scheduling meetings in an enterprise [2].
These applications use email as a communication medium for scheduling meetings. This email
based scheduling mechanism requires an access and to view free time slots of participants’
calendar which is achieved by using Open Calendaring Protocol (OCP). OCP enables users to
utilize a particular network and reserve a meeting on other people’s calendars without any direct
interactions. For example, a combination of Microsoft Outlook [9] and Microsoft Exchange Server
[10] allows users to reserve meetings on another user’s calendar. However, the scheduling remains
a manual process.
We consider this as an inefficient approach for several reasons. First of all, email is semistructured communication medium and does not support computation such as finding scheduling
availability and common meeting times [2][11]. The semi-structured manner of emails makes
automatic decision making hard. In addition, Bellotti [12] concluded that email is a difficult
medium for applications that require coordination. Secondly, since all meeting invitations and their
responses come as emails, the number of email messages is proportional to the number of meeting
invitees. If one attendee cannot attend a meeting and propose a new meeting time, the new
proposal starts a new email thread. In a worst-case scenario, for a single meeting request with n
number of participants, the process could generate n! number of emails. For a large number of
invitees, it becomes a burden for the meeting inviter handling such a large number of emails.
Thirdly, the process suffers from transparency. Only the meeting inviter can see all responses from
other invitees. If one invitee proposes a new time, the information flows to the inviter only [2]. All
other invitees are unaware of the new proposal until they receive a new meeting time from the
inviter. This adds additional responsibility to the meeting inviter. At the same time, it requires
more time handling the increasing number of emails. Doodle (a polling based calendaring
platform) has addressed this problem and attempts to reduce the quantity of emails during the
meeting scheduling process [2]. Finally, OCP violates user privacy [4]. A person’s daily schedule
is naturally private. Circulating a schedule in network that OCP advocates surely violates user’s
privacy. On the other hand, circulating ones calendar brings other scheduling complexities. For
example, assume a person wants to initiate a meeting and uses a suitable time slot on their calendar.
It is possible that during a meeting initiation process, another meeting initiation process occupies
that same time slot. In this case, it is a natural phenomenon that the meeting invitation will be
either rejected or rescheduled [1]. If this scenario occurs, the scheduling process suffers from
difficulties.
With these limitations, email based scheduling applications are unable to schedule meetings
automatically on behalf of their users. Individual users are responsible to manage their own
2
calendars, make a decision, and resolve a meeting conflict manually. It is mentioned earlier that
people are required to work in a cooperative manner. Attending a meeting is an opportunity for
them to develop new relationships, maintaining old relationships and above all achieve
professional and personal goals. As such, scheduling a meeting has been transformed into a
strategic agreement problem. This transformation is a motivation for us to study the problem more
deeply.
This paper proposes a Personal Meeting Scheduling Agent (PMSA) architecture, a negotiation
protocol named Personal Meeting Scheduling Protocol (PMSP), and a reasoning mechanism for
evaluating a meeting invitation to make a decision. Our main goal for proposing the agent and the
negotiation protocol are to overcome the email based scheduling burden, limitations of the OCP,
and handling bilateral, multilateral negotiations automatically. After placing our work, we provide
an overview of the proposed negotiation protocol and scheduling agent. We describe the PMSA
development process and the approach used to tackle challenges of meeting scheduling. We
conclude reporting a prototype Meeting Scheduling Application (MSA) and its effectiveness in a
controlled environment.
2. Related work
Recently, agent oriented software development has gained much popularity. Agents are often
deployed in an environment where they interact and cooperate with other agents or humans that
possibly have conflicting aims. For example, in a meeting scheduling environment, an agent must
interact and cooperate with other agents (as a meeting inviter or invitee) in order to come to a joint
agreement. In this environment, the meeting inviter agent’s intention is to convince meeting
participants to accept a meeting invitation at a proposed time. Whereas, the invitee agent’s
intention is to evaluate the meeting invitation and make a decision that would bring a desirable
win-win result. Designing an agent for scheduling meetings is a daunting assignment due to its
complexities [1]. For example, in a meeting scheduling environment one has to consider not only
available time but also user’s preference, participant’s status, etc. Agent based-systems for
scheduling meetings were introduced in [3][5][8][13][14][15]. Most of these systems used
automated negotiation to handle scheduling constraints. However, the authors’ view of a
scheduling problem is not similar.
Sen [15] viewed meeting scheduling as a distributed search problem and proposed an agent
that works in a distributed manner. In his proposed approach, the agent uses email as a primary
communication medium for exchanging scheduling information and has a process that analyzes
meeting invitations. In order to resolve meeting conflicts via automated negotiation, the agent uses
the well known Contract Net Protocol [16]. However, this agent has several questionable features.
Since the agent uses email as a communication medium, it is dependent on an email server or
dispatcher. This process can result in communication delays. Furthermore, there is always a
possibility of overuse or abuse of emails. Recent statistics showed that in a single day, 1.97 billion
Internet users worldwide generate 294 billion emails and 89.1% of them are spam [17]. The
contribution [15] provided an algorithmic solution to conclude a particular meeting invitation and
claimed to have an internal process to analyze a meeting invitation. However, there are few details
on how the analysis was done.
Similarly, the Radar project [13] made another attempt to handle meeting scheduling by
proposing a Personal Assistant Agent. This attempt was focused on sequential scheduling with a
limited information exchange among participating agents. In this contribution, email is also
considered as the primary communication medium. A template is employed to extract meeting
information from emails. Although the project clearly formulates meeting scheduling problems
and provides an information extraction mechanism, we believe that the template is platform
dependent and may not be able to extract necessary information from emails generated from
different platforms. For example, the structure of an email containing a meeting invitation from
Microsoft Outlook differs from that of Novell GroupWise. Moreover, there is less explanation
about how the limited information exchange works i.e. what information will be shared during the
scheduling process? Researchers [5][8][18] had also proposed a similar agent-based system for
scheduling meetings. Shintani et al. [18] presented a persuasion-based approach for evaluating
meeting invitations using multi attribute utility theory (MAUT). Lei [5] had proposed an Artificial
Neural Network for assessing a meeting invitation. Recently, Berry et al. proposed a preference
based Learning Cognitive Assistant Agent (PTIME) [8]. PTIME is focused solely on user
preference over a set of meeting initiators. However, it is very difficult to set preference for all
3
meeting participants. Since all of these proposed scheduling agents use email as a communication
medium, they face the aforementioned limitations.
A Negotiation strategy is an expression of the sequence of functions that a negotiating agent’s
must follow. A strategy is generally carried out in private and its results revealed through its
actions. Strategies play a crucial role in automated negotiation for reaching agreements. For
example, a strategy should define whether a proposal is satisfactory or whether a counter proposal
needs to be sent. Two classical strategies to cope with conflicts include either avoiding or solving
conflicts. For a meeting scheduling, researchers [11][14] [19][20] proposed several negotiation
strategies with specific properties. Modi et al. [13] proposed three negotiation strategies, “Greedy”,
“Bumping” and “NCost”. Berres and Oliveira [14] proposed “First Possible” and “Take Best”
strategies. These strategies are based on finding free time slots in a calendar. Shakshuki et al.
proposed “First-Come-First-Served (FCFS)”, “High Rank”, and “Voting” strategies [11]. These
strategies are focused on free time, user preference, and a user poll on a particular meeting.
Likewise, Wainer et al. [20] proposed strategies that depend on the availability of user information,
time and preferences. Nevertheless, very little has been done to decide in which circumstances the
proposed strategies will be selected and applied in order to achieve a desirable outcome.
Selecting an inappropriate strategy may lengthen the negotiation process and lead to
undesirable results. For example, meeting invitations from persons of higher and lower ranking in
an organization need to be treated differently. Applying free time strategies may over constrain
user schedules and increases the possibility of rejection important meetings dates. Though an
invitee might agree to attend a meeting, they might not have a free time slot in their calendar.
However, it is possible to use other strategies to make the calendar less constrained. A user can
group meeting invitations on the basis of user status, meeting importance, and preferences.
Grouping meeting invitations and selecting a strategy depending on them will decrease the
possibility of overload one’s calendar. Crawford and Veloso [4] introduced playbook and
Exploration-Exploitation Experts (EEE) approaches for selecting negotiation strategies. They also
mentioned the importance of learning for selecting strategies [1]. Jiang and Wu [21] proposed
Case-Based Reasoning (CBR) and Reinforcement Learning together for the same purpose.
However, these attempts were not focusing on the meeting scheduling problem. The proposed
meeting scheduling agent (PMSA) presented in this paper selects a negotiation strategy by
grouping meeting invitations. In cases where meeting invitations cannot be grouped, it uses a
computation model to evaluate an invitation and selects negotiation strategy based on evaluation
results. In addition, where both approaches fail to make a decision the agent evaluates and a makes
decision based on inviter and invitee’s interpersonal relationship.
3. Personal meeting scheduling protocol
In order to negotiate, agents must have the ability to interact with other agents via a common
communication protocol. The protocol must be public and open to all negotiating agents [22]. The
proposed PMSP is guided by Simultaneous Response Protocol (SRP) for strategic negotiation [23].
SRP is an extension of Rubinstein Alternating Offer Protocol (RAOP) [24] which is suitable for
Bilateral Negotiations. SRP overcomes constraints of RAOP and hence can work perfectly in both
Bilateral and Multilateral Negotiations [24]. The proposed PMSP advocates circulating
communication messages among meeting participants’. By circulating communication messages
among participants, it saves time for negotiation process and eliminates the necessity for continuous
monitoring. Symbolic representation of the proposed PMSP is presented in Table 1:
Table 1. Symbolic Representation of PMSP
Notation
Description
A
A1, A2, A3… An} is a set of Agents where Ar = Requester Agent, Ap = Participating
Agent or Agents, and Ah = Host Agent
M
Meetings identifier or meeting details where Mi = Meeting identifier and Md =
Meeting identifier including details
Ts
Meeting date and time
Td
Meeting duration (in minutes)
D
Decision regarding a meeting request where Da = Accept and Dr = Reject
I
Message identifier where Ii = Meeting initiation, Ir = Meeting response, Ic = Counter
proposal and Iack= Acknowledgement
ID
Meeting Identifier
R
Remarks (Optional)
4
When a meeting is at the initiation stage, the host agent Ah broadcasts an initiation message to
all participants. The initiation message format is < Ii, Ah, Ap, Md, Ts, Td, R >. When a meeting
invitee receives a meeting initiation message, it replies to all other invitees and the inviter using one
of the following messages format:



<ID, Ir, Ar, Da, R> for meeting invitation acceptance;
<ID, Ir, Ar, Dr, R> for rejection; and
<ID, Ic, Ar, Ts, R> for proposing new offer.
The PMSP uses the email address to identify a meeting participant because of its uniqueness.
This paper defines several constants for the PMSP. To identify a PMSP message, this paper
defines message identifier Ii (meeting initiation), Ir (response) and Ic (counter proposal) as 1, 2, and
3 respectively. Similarly, meeting acceptance (D a) and rejection (Dr) is defined by 1 and 0. The
PMSP uses the date and time format as year+month+day+hour+minute+sec, e.g. 20121004152645
implies 4th October 2012 at 3:26:45pm. In order to maintain uniqueness, the meeting identifier is
generated by combining year, month and day followed by a 4 digits number starting form 0000.
For example, the meeting identifier 201210250015 implies that the meeting was initiated on 25th
October, 2012 and the meeting number was 15. For the acknowledge message (I ack), 0 and 1
represents unsuccessful and successful respectively. Initially, a meeting invitation will not have a
message identifier. After an initiation message or other message is successfully circulated, an
acknowledgement message will return a meeting identifier in order to distinguish a meeting from
other meetings. A detail meeting initiation and acceptance message structure is presented in Fig. 1
and Fig. 2.
Message Identifier = 20121004152645
Meeting initiator = “Inviter’s email address”
Meeting Participant 1 = “Participant 1 email address”
Meeting Participant 2 = “Participant 2 email address”
Meeting Participant 3 = “Participant 3 email address”
Meeting Details = “Meeting Description”
Meeting Date and Time = “20121003110000”
Remarks = Null
Fig. 1: Meeting Initiation Message Structure
ID = 201210250015
Message Identifier (Ir) = 2
Requester Agent (Ar) = “email address of the proposer”
Date and Time (T) = “20121004120000”
Remarks = Null
Fig. 2: Meeting Acceptance Message Structure
4. Personal meeting scheduling agent
The goal for designing the PMSA is to reduce the email based scheduling burden, overcome
constraints that the OCP brings, and schedule meetings automatically. For communication, PMSA
uses the proposed PMSP presented in section 3. The agent accepts meeting invitations in such a
way that there will be less possibility of rescheduling. However, if a conflict appears, the PMSA
will take the next available meeting slot to offer a new meeting time. The PMSA is designed to act
in a semi-cooperative manner. In some cases, the agent allows the user an advantage in terms of
social networking and maintaining an organizational chain of command. In other cases, the PMSA
shows cooperative behavior with the intention of maintaining old and creating new relationships
among meeting participants. The agent requires user intervention when its reasoning mechanism
fails to make a decision regarding a meeting invitation. During meeting negotiation, one of the
main objectives of the proposed PMSA is to detect and avoid scheduling conflicts automatically.
For a successful negotiation, having opponent’s information is an essential requirement. This
paper acknowledges this requirement and the PMSA achieves this by collecting and analyzing
invitee/inviter’s profiles and previous meeting interactions. The proposed PMSA has four
components and an internal database to perform automatic scheduling activities. The components
are 1) Communication, 2) Analysis, 3) Offer Generator, and 4) Knowledge Update. The PMSA
5
formulates a meeting invitation according to the PMSP. Then, it evaluates the invitations and
makes decisions whether to accept, reject the invitation or propose a new meeting time. After
making the decision, the agent selects an appropriate negotiation strategy to execute the decision.
At the end of the process, the agent prepares an offer and circulates among meeting participants.
The following sections discuss the components of PMSA architecture. The PMSA architecture is
presented in Fig. 3.
Fig. 3: PMSA Architecture
4.1. Communication
The Communication component of the PMSA is responsible for receiving, sending, and
encoding/decoding messages from/to meeting participants. After receiving an invitation, this
component forwards the messages to other components. At the same time, it stores the information
in the internal knowledge-base via the Knowledge Update component using the following format:
<Meeting Identifier, Requester Information, Participants Information, Meeting Details, Meeting
Time, Meeting Duration, Remarks>
4.2. Analysis
When designing an agent-based system, it is important to determine how sophisticated the
agents reasoning mechanism will be. The proposed PMSA analyze and evaluate meeting invitations
through the Analysis component. Every meeting invitation must go through the evaluation process
via this component. The evaluation process follows a hybrid mechanism. Initially, it evaluates an
invitation based on free time, inviter status, and user preference. If the initial evaluation process is
unable to determine any decision, it uses the Naïve Bayes model of Maximum Likelihood
Estimation (MLE) [25]. The Analysis component depends on a knowledge base, which is the
repository of previous interactions between the user and the meeting participants, negotiation
outcomes, and strategies used for the negotiation process. The Analysis component processes and
analyzes historical data via five processes. The processes are 1) Knowledge Retriever, 2) Profile
Manager, 3) Preference Manager, 4) Reasoning, and 5) Offer Generator. The following sub sections
discuss these processes.
4.2.1. Knowledge retriever
Historical and current information comprise the foundation of the Reasoning Component. This
historical data is the input for the evaluation process. Knowledge Retriever (KR) is a dedicated
process for collecting historical information and calendar status from the internal knowledge
database. This process is guided by the ongoing meeting invitations. It retrieves previously
accepted, rejected, and rescheduled meeting information. At the same time, it retrieves recent status
for an ongoing meeting invitation, participants’ profiles, user preferences, calendar status, and
negotiation status. The meeting data collection process is independent of times and dates i.e. the
component collects all previous meeting interactions.
6
4.2.2. Profile manager
A user’s profile is a way to identify people in a community with similar interests. It is highly
valuable information for people in a community [26]. For an intelligent agent, a user profile plays a
vital role in determining the meeting invitee and inviter’s status [27]. For PMSA, it is necessary to
have knowledge about the participants’ status and their importance to decide whether to accept,
reject a meeting invitation or propose a new time. However, a person’s profile may change over
time. In an organization, a person can be promoted or change his or her responsibilities. The Profile
Manager process is also responsible for updating the user profile in the agent’s internal knowledge
database by collecting recent information from external sources which this paper assume contains
recent profile information.
4.2.3. Preference manager
Individual preference contributes significantly to scheduling meetings. A user’s preference can
be a particular period of time, day of the week, a meeting inviter, or invitee. However, a
participant’s preference may change over time considering the nature of the meeting invitation. For
example, if a meeting invitation is received from an inviter, proposing a less preferable time, who
holds superior organizational authority, it will be strategically improper to reject or propose a new
time for the meeting. In the proposed architecture, the preference manager process is responsible for
managing, updating and suggesting the addition of more preferences for the meeting inviter and
invitees. For instance, if a user receives frequent meeting invitations from a particular person who
does not exist in the preference list and the user accepts the majority of the invitations, the
preference manager process will suggest adding that particular meeting inviter to the preference list.
Similar scenarios apply for setting preferences for time and days of the week.
4.2.4. Preference manager
The Reasoning process serves as the main function of the Analysis component. Knowing the
opponent is one of the essential requirements for a successful negotiation. In order to avoid or
resolve conflicts, it is mandatory that a logical relationship be developed between the recent and
previous meeting interactions that have been received and the ongoing invitation. The Reasoning
process uses four criteria to evaluate a meeting invitation.




At the beginning, the process uses meeting inviters’ profile information and makes a
decision.
Secondly, it uses invitees’ preference information for the evaluation.
Thirdly, the Reasoning process uses the computation model to evaluate a meeting
invitation.
As a fourth criterion, the process evaluates an invitation based on interpersonal
relationships between the meeting inviter and invitees.
However, if all the four evaluation criteria fail to make a decision, the evaluation process request
user to handle the invitation manually. While requesting user to make the decision, the Reasoning
process provides all analysis results to the user required for making a rational decision. Based on the
evaluation result or user decision, the Reasoning process guides the Strategy Selector process to
select appropriate negotiation strategy in order to conclude the negotiation process.
There are many approaches for reasoning and designing negotiation strategies. This paper
focuses on mathematical science. Mathematical science formulates mathematical models and
captures elements of negotiation strategies. In mathematical science, reasoning and strategy
development is also divided into two categories i.e. Analytic and Computational model. The aim of
computational models is to provide computational tractability using approximation algorithms.
Computational research aims to have models implemented as an autonomous process. These
processes are able to incorporate realistic factors of negotiation (e.g. argumentation, information
seeking, and cognitive factors) and thus engage in negotiations in a decentralized manner [28]. This
paper use the computational model i.e. Naïve Bayes Model of MLE for evaluating meeting
invitations and making decisions.
Bayesian statistics is a framework for a logical and consistent reasoning mechanism. It provides
a complete paradigm for both statistical inference and decision making when there is an uncertainty.
Conventional statistical methods face many difficulties in solving complex problems. However, the
Bayesian method uses frequentist (interpretation of probability) procedures to overcome the
difficulties and extend the applicability of the conventional statistical methods [29]. The Naive
7
Bayes classier selects the most likely classification VNB given the attribute values a1 , a2 , a3 ,...an .
This results in:
P(a1 , a2 , a3 ,...an | v j )  P(v) P(ai | v j ) ……………………… (1)
i
Hence, we get the following classifier:
 P(a | v ) …………….……………………… (2)
V NB  arg max P(v j )
i
j
i
Estimating P (v j ) is simple since it can be done by computing relative frequency for each
target class. However, estimating P (a1 , a2 , a3 ,...an | v j ) is difficult due to the sparse data. In
order to resolve this problem, m-estimate of probabilities has been used, using ( 3).
P (ai | vi ) 
nc  mp
……………………….……………………… (3)
nm
Where,
n = the number of examples for which v  v j
nc = number of examples for which v  v j and a  ai
p = a priori estimate for P(ai | vi )
m = the equivalent sample size (constant)
Fig. 4 shows the algorithm by which the Reasoning process analyzes a meeting invitation.
- Collect user preferences for the meeting inviter
- Collect calendar preference
- Collect inviter’s profile information
- Collect meeting history between inviter and invitee
- For each invitee
- P (Inviter, Invitee, evidence) = Probability of accepting a invitation based on previous
evidence
- End For
- Calculate previous meeting acceptance ratio received from the invitee
- Calculate previous meeting acceptance ratio sent to the invitee
- Select Strategy (Analysis results, Invitation)
- Save analysis result and return
Fig. 4: Reasoning Algorithm
4.2.5. Strategy selector
Selecting an appropriate strategy ensures a negotiation process to achieve a desired result. The
Strategy Selector component holds the strategies discussed in section II. In addition this paper
introduces two negotiation strategies. The first strategy this paper is introducing is based on user
profile and the later one is based on the previous interactions with other meeting inviter and
invitees. The strategies are explained below:
In real life, people consider individual social and organizational status. Although preference
adds significant importance to a meeting participant, it is dependent on the user. It may happen that
the user has no preference to a particular meeting inviter or the invitees. For example, consider an
organizational environment where a meeting inviter has higher organizational authority. A user
receives occasional meeting invitations from inviters and hence preference has not been set for that
inviter. In this case, it will be short sighted for a user to reject or propose a new meeting time for a
meeting invitation based on preference.
The second strategy captures people’s social behavior. In social life, interpersonal relationships
remain an important factor handing bilateral and multilateral negotiations. This strategy uses this
social behavior for evaluating a meeting invitation. Though it is an irrational behavior but human
beings cannot ignore this while negotiating. It is human nature to develop and maintain good
relationship with others. Assume a meeting invitation, where meeting inviter does not enjoys higher
level of authority and user preference. However, over a period of time whenever the user invites for
a meeting, he/she accepts. By rejecting an invitation from such a user may give a wrong impression
8
in the long run. The Reasoning process guides the Strategy Selector process to select appropriate
strategies from the strategy repository that it possesses. The Strategy Selector process uses
algorithmic steps to select a strategy as shown in Fig. 5.
oo- If the inviter’s organizational authority is higher than invitee then
- Call Offer Generator (Decision, Analysis summery)
- Save result and return
- End If
- If inviter preference is high then
- Call Offer Generator (Decision, Analysis summery)
- Save result and return
- End If
- If classifier result is ‘yes’ and rescheduling classifier result is ‘no’
- Call Offer Generator (Decision, Analysis summery)
- Save result and return
-Else
- Save result and return
- End If
- If inviter and invitee meeting acceptance ratio >= 50%
- Call Offer Generator (Decision, Analysis summery)
- Save result and return
- End If
- If classifier result is ‘no’
- Call Offer Generator (Decision, Analysis summery)
- Save result and return
- End if
- Return
Fig. 5: Strategy Selector Process Algorithm
4.3. Offer generator
The Offer Generator component (OGC) is guided by the Analysis component and prepares an
offer or a counter-offer following PMSP message structure. The Offer Generator receives the
calendar status via the Analysis component. For example through the Analysis component, the
OGC finds the free and the occupied time slots in the calendar. To prepare an acceptance offer, the
OGC checks the calendar status to find possible time conflicts with the proposed meeting time. If
there is time conflict, the OGC searches for an available time slot and makes a counter offer. Fig. 6
presents the algorithm for generating offers.
- If Decision = “yes” Then
- Check calendar availability
- If meeting slot is free then
- Prepare an acceptance offer
- Else
- Get available meeting slot
- If no time slot is available then
- Prepare a counter offer
- Else
- Request user to intervene
- End If
- End If
- Return
- End If
- Prepare a rejection offer
- Save result
- Return
Fig. 6: Offer Generator
9
4.4. Knowledge update
The Knowledge Update component is responsible for collecting and updating meeting data
into the internal Knowledge Database. The component consists of multiple processes and performs
several functions. First of all, it collects user profile information from an external database. The
process periodically checks the changes made and updates the internal Knowledge Database
accordingly. Second of all, its connection with the Communication component means that it
receives data from that component about any intermediate information regarding acceptance,
rejection, or counter offers in the negotiation process. For example, during an ongoing meeting
negotiating process, assume one of the participants responds to the meeting invitation by either
accepting or rejecting the invitation. This information helps the Analysis component to analyze
meeting invitations and make a decision to select appropriate negotiation strategies to avoid or
resolve conflicts. Finally, once the OGC prepares an offer, it updates the internal Knowledge
Database with the analysis results.
5. Simulation and results
The proposed PMSA and PMSP are implemented using the Microsoft Visual Basic (VB)
programming language under Microsoft .NET framework. The PMSA is integrated into the
prototype MSA developed using the same platform. The MSA is a desktop application and uses
MySQL Relational Database for storing historical meeting data. In order to collect meeting
invitations, the MSA uses Blackboard architectural pattern. The algorithms presented in the Section
4 were implemented using MySQL stored procedure. Microsoft Visual Studio 5 is used as the
programming environment and the Open Database Connectivity (ODBC) for accessing the database.
The application is developed under a Microsoft Windows 7 operating system.
For the simulation, this research utilized a hierarchical academic institution where the president
holds the highest organizational authority (level) and undergraduate students hold the lowest. Ten
users from different levels of authority are randomly chosen. The level of authority is represented
by a numeric value started from 1 to  (highest to lowest) i.e. for undergraduate student the numeric
value is 7. A similar approach is used for user preference, where 1, 2 and 3 represent high, medium
and low respectively. If a user does not set any preference for a particular person, the value is set to
. Table 2 shows the user and their levels used in this paper.
Table 2. User Level
No.
Email Address
Level
1
Danny.silver@acadiau.ca
3
2
Jeff.hooper@acadiau.ca
3
3
Elhadi.shakshuki@acadiau.ca
4
4
Darcy.benoit@acadiau.ca
5
5
Haiyi.Zhang@acadiau.ca
5
6
Wael.alghamdi@acadiau.ca
6
7
Hossain@acadiau.ca
6
8
Azam@acadiau.ca
6
9
Qianli.shu@acadiau.ca
7
10
Sam.shi@acadiau.ca
7
For the simulation, this paper use p=1/k in the (3) where value of is set to 2 since it takes only
two values; Yes or No i.e. whether to accept or reject the meeting invitation. Also, m in (3) is set to
10 (constant) and P equals to 0.5 (1/ (number of attribute values)). In order to verify the proposed
PMSP, communication messages were collected randomly and checked with the reference message
structure presented in section 3.
The prototype application manages meeting scheduling activities using two Graphical User
Interfaces (GUIs). They are 1) Configuration and 2) Meeting Scheduling. The following subsections
describe each GUI and show how a user interact with the application and perform meeting
scheduling activities.
10
5.1. Configuration
The MSA requires certain configurations to perform automated scheduling activities. The main
intention of the Configuration GUI is to capture all configurations required for the MSA. The
configurations personalize the MSA by building an address book, setting calendar and contact’s
preferences. The Configuration GUI is divided into two interfaces. They are: 1) Calendar Preference
and 2) User Preference.
5.1.1. Calendar preference
The “Calendar Preference” is the first interface of the Configuration GUI. Fig. 7 shows
“Calendar Preference” interface where a user has personalized the application by entering his email
address, name, and calendaring preference. The “Calendar Preference” interface also captures the
working hours and time slots when the user wishes to accept meeting invitations. The time slot of a
particular day is divided into 16 equal slots of 30 minutes. By using this interface, it is also possible
for the user to add temporary calendar preference e.g. a professor can add temporary calendar
preference for a particular academic session.
Fig. 7: Calendar Preference
5.1.2. User preference
The “User Preference” interface is used to develop an address book for the user. A user can add
his/her contact list and set/modify user preferences. The MSA provides three categories to set or
modify the user preference. These categories are: 1) High, 2) Medium, and 3) Low.
5.2. Meeting scheduling
The second GUI of MSA prototype is Meeting Scheduling. The MSA manages scheduling
activities via this GUI. This interface is designed in a very compact manner. The compact design
enables users to stay in one interface and manage all activities. The interface is divided into three
sub-interfaces. They are 1) Meeting Invitation, 2) Meeting Negotiation, and 3) Event Log.
5.2.1. Meeting invitation
“Meeting Invitation” is the first interface of the “Meeting Scheduling” GUI. This interface
allows users to view recent accepted meeting invitations and their details in read only mode. It also
allows users to initiate a meeting invitation. In order to initiate a new meeting, users are required to
access the address book and “Meeting Invitation” provides a mechanism to access it. A calendar is
incorporated with this interface. By using this calendar, a user can browse previous meetings.
11
5.2.2. Meeting negotiation
“Meeting Negotiation” is the second interface of the “Meeting Scheduling” GUI. The proposed
PMSA is embedded with this interface. The integrated PMSA periodically collects meeting
invitations as well as offers from the blackboard on a predefined time interval. This interface
performs the negotiation process in a semi-automatic manner. For example, when the Analysis
component is unable to make a decision, it alerts the user to handle the meeting invitation manually.
All the activities performed by this interface are logged in the ‘Event Log’ interface. Figure 8 shows
the “Meeting Negotiation” interface.
Fig. 8: Meeting Negotiation
Figure 8 shows a meeting negotiation summary of a particular meeting invitation. Please note
that, there three buttons available in this interface i.e. “Accept”, “Reject”, and “Reschedule”. These
buttons will available to the user if the PMSA is unable to make a decision regarding a meeting and
requests the user to intervene. After a successful meeting negotiation, meeting details can be
accessed by using the “Meeting Invitation”.
5.2.3. Event log
The main purpose of the “Event Log” is to store and view all activities performed by the
‘Meeting Invitation’ and the ‘Meeting Negotiation’ interface i.e. activities performed by the PMSA.
For example, when a new meeting invitation is received “Event Log” interface shows when the
invitation was received and what decision has made. The agent’s activities are stored in the database
for future meeting analysis.
5.3. Scenario 1
This scenario will demonstrate how the PMSA handles bilateral negotiation and evaluates a
meeting invitation, subject to participant’s profile. This scenario describes a bilateral negotiation
where the meeting invitee concentrates on the profile. It is very likely that an inviter at a higher
organizational level will expect persons at lower levels to accept the invitation. One of the
challenges of the bilateral negotiation is user behavior prediction. The PMSA handles this challenge
by using profile based strategies. The meeting details are presented below:
Inviter: Elhadi
Invitee: Wael; Hossain
12
Here, the PMSA evaluates the meeting invitation on behalf of the meeting invitee Hossain.
Since the meeting inviter (Elhadi) holds a higher level of authority (see Table 2) than the user
(Hossain), the PMSA accepts the meeting invitation subject to the availability of free time slots in
the calendar.
5.4. Scenario 2
This scenario will demonstrate how the proposed PMSA evaluates a meeting invitation subject
to user preference. This scenario focuses on meeting inviter only and also a form of bilateral
negotiation. During the negotiation, the PMSA uses the proposed negotiation protocol (PMSP).
Therefore, the agent overcomes another challenge (need for a suitable negotiation protocol) of
bilateral negotiation. For this scenario, meeting details are:
Inviter: Haiyi
Invitee: Elhadi; Danny; Darcy; Jeff
Assume the PMSA evaluates the meeting invitation on behalf of invitee Elhadi. Here, the
meeting inviter holds lower organizational authority than the invitee Elhadi. The preference list for
the user Elhadi is presented in Table 3.
Table 3. Preference list for scenario 2
No.
Email Address
1
Danny
2
Jeff
3
Haiyi
4
Darcy
Preference
1
3
1
1
Since the meeting inviter enjoys preference “High”, the Analysis component evaluates the
meeting invitation based of preference (See Figs. 4 and 5) and makes the decision to accept the
meeting invitation.
5.5. Scenario 3
This scenario will show how the meeting evaluation process analyzes an invitation where a
meeting inviter neither enjoys higher organizational level nor higher preference. This scenario is a
form of multilateral negotiation as the PMSA considers not only meeting inviter but invitees as
well. The evaluation process makes the decision using the computational model presented section 4.
The computational model assists the PMSA to predict the decision of the other meeting
participants’. In multilateral negotiation, users’ decision making partner selection is a challenge. By
predicting other meeting invitees’ decisions and following their decisions, the PMSA shows a
cooperative behavior and thus overcome this challenge. This cooperative attitude allows the PMSA
not only to avoid future meeting conflicts but also developing or maintaining a relationship with
meeting inviter. The meeting details for this scenario are:
Inviter: Qianli
Invitee: Wael; Hossain; Sam; Azam
In this invitation, the meeting inviter is an undergraduate student who is requesting a meeting
consisting of three graduate students and one undergraduate student. Assume the PMSA evaluates
the meeting invitation on behalf of the user Hossain. The preference list for the user Hossain is
presented in Table 4.
Table 4. Preference list for scenario 3
No.
Email Address
1
Wael
2
Qianli
3
Azam
4
Sam
Preference
3
3
3
3
Due to the properties of the inviter (see Table 2 and 4), the Reasoning process evaluates the
meeting invitation using the computational model. Table 5 shows the frequency distribution of the
previous interactions with the inviter and invitees.
13
Table 5. Frequency distribution for scenario 3
Inviter
Invitees
Qianli
Wael
Azam
Sam
Decision
Accept
8
10
6
Reject
2
0
4
Bu using (3) we calculate the Maximum Priori Estimate of each meeting participants’. The
detail calculation process is presented below:
P (Wael| Accept) =
P (Wael |Reject) =
8  10  0.5
 0.65
10  10
2  10  0.5
 0.35
10  10
Using the same procedure we calculated P (Azam |Accept) = 0.75, P (Azam| Reject) = 0.25, P
(Sam |Accept) = 0.55, and P (Sam |Reject) = 0.45. Finally, using (2), we interpret the probability to
a Naïve Bayes Classifier.
P (Accept | Yes) = 0.5  0.65  0.75  0.55  0.1340625
P (Accept | No) = 0.5  0.35  0.25  0.45  0.0196875
Since the classifier shows that P (Accept | Yes) > P (Accept | No) i.e. 0.01340625 > 0.0196875),
the naïve classifier provides the decision as “Yes”. Therefore, the Offer Generator component
attempts to accommodate the meeting invitation in the calendar. However, if there is a time conflict,
the OGC proposes a new offer using available meeting slot. If no time slot is available, the PMSA
will request the user to intervene. To assist user, the MSA will provide an analysis summary in
order to make an appropriate decision. In addition, if the agent receives a counter offer for the same
meeting, it will not evaluate the request again since the decision has already been made unless all
other users reject the invitation.
5.6. Scenario 4
Assume the PMSA was unable to make a decision for the meeting invitation presented in
scenario 3 due to insufficient historical data. This scenario will show how the proposed PMSA
evaluates a meeting invitation where other evaluation processes fail to make a decision. In such
circumstances, the PMSA uses a strategy for meeting evaluation which is based on interpersonal
relationships between meeting inviter and invitee. Since the evaluation process focuses on meeting
inviter only, the meeting invitation falls in the bilateral negotiation level. The meeting details are
similar to Scenario 3 and Table 6 summarizes the meeting information. The table shows the
frequency distribution for the previous interactions between the meeting inviter “Qianli” and the
invitee “Hossain”.
Table 6. Frequency distribution for scenario 4
Inviter
Invitees
Decision
Accept
Reject
Qianli
Hossain
8
2
Hossain
Qianli
7
3
Ratio
Accept
80%
70%
Reject
20%
30%
6. Simulation and results
Each scenario presented in this paper was simulated 50 times. 10 test runs as one trial for the
sake of verification and validation. Every trial run uses multiple numbers of participants ranging
from 1 to 5 invitees. The number of meeting invitees included in each test run varies in order to
verify whether the proposed PMSA is able to handle bilateral and multilateral negotiations and
whether the PMSP is working as desired. After every trial, results were recorded and summarized in
a single number as percentile. During the trial runs, PMSA was able to make automatic decisions
more than 70% of the time.
To verify the PMSA, a random meeting invitation was selected and processed the invitation step
by step manually using the algorithms presented in section 4. The invitation was then processed via
14
PMSA and verified with the reference outcome previously processed manually In order to validate a
decision and selected negotiation strategy, a similar approach for the verification was used. During
the trial, several meeting invitations were selected randomly and invitations were manually
evaluated subject to the inviter’s profile, user preference, computational model, and interpersonal
relationships between meeting inviter and invitee. The results were then validated with the result
given by the PMSA during the trial run. The validation and verification process was maintained for
every scenario presented in this paper.
6.1. Efficiency
Time is an important factor in agent negotiation. It is directly related to negotiation operational
performance. During a negotiation process, negotiating agents must come to a decision quickly and
apply strategies to achieve desired goals. In many cases delayed decision brings desirable results.
However, in general decision making should be prompt. A delayed decision generally lengthens the
negotiation process and brings an undesirable result. For instance, consider a meeting invitation
where there are several high status participants in the invitee list. A prompt decision by a high status
participant can accelerate the scheduling process considering other participants are aware that a high
status (organizationally superior) participant has made a decision. On the other hand, in a
conflicting scenario, a decision made by other participants can influence a particular meeting invitee
to make his/her decision quickly. This paper considers an agent’s performance based on how
quickly an agent makes a decision regarding a meeting invitation. The negotiation time is calculated
as:


Negotiation Time (TN) = Communication Time (Tcomm) + Reasoning Time (Trsn)
Communication Time (Tcomm) = Request Collection Time (T rc) +
Encoding/Decoding Time (Ted) + Decision Dispatching Time (Tdd)
Reasoning Time (Trsn) = Data Collection Time (Tdc) + Calculation Time (Tcal)

Message
To test the efficiency of the PMSA, a number of meeting invitations were simulated and
decision making time was recorded for each invitation. It has been found that with 10 participants,
the PMSA requires less than 5 seconds to make a decision. It has also been found that the decision
making time of the PMSA is proportional to the number of meeting invitees. Fig. 9 shows the time
taken by the PMSA with respect to number of meeting participants to make a decision.
Decision Making Time (Sec.)
PMSA Efficiency
4.5
4
3.5
3
2.5
2
1.5
1
0.5
0
3
4
5
6
7
8
9
10
11
12
Number of Participants
Fig. 9: PMSA Efficiency
6. Conclusion
Our daily activities are filled with a variety of problem areas, such as in meeting, buying or
selling products, etc. Recently, technological developments especially in the area of communication
15
have affected our lifestyle in numerous ways. Mobile communication and the World Wide Web
have significantly influenced our lives. People are busier and becoming more competitive and there
is a growing need for personalized services [30]. In this article, we made an effort to ease people’s
time constraints by proposing a semi-automatic agent to maintain and schedule meetings
automatically. The strengths of the agent are: it overcomes the limitations of the existing
approaches; automatically make decisions and selects negotiation strategies to execute decisions.
These strengths are demonstrated in different meeting scheduling scenarios.
The meeting scheduling agent proposed in this article is heavily dependent on historical meeting
data, user profiles and recent changes of the scheduling environment. User preference based model
for recommending negotiation strategies are also evolving [30][31].As mentioned in section 1,
commercial scheduling applications are widely used for scheduling meetings. They also support
users to store individual meeting data locally or in remote servers. This meeting data can be
imported to a specific format and used for the proposed PMSA.
Another challenge for the proposed approach is to evaluate meeting invitations based on user
profile and environment changes. Creating and managing user profiles is a daunting task. One of the
main problems is populating user profiles with correct and updated data. This is because accurate
data entry is mostly based on human inspection. However, there are models evolving such as the
Real Time Enterprise (RTE) [32] to collect environment information. At the same time, research
has been ongoing to manage and develop user profiles. Automated systems such as the Folksonomy
system [26] contribute to this research. We believe that by integrating all contributions together, a
useful result is achievable for of scheduling meetings.
This research has a number of future directions for research. For instance, we have not looked
at identifying meeting importance and a mechanism for rescheduling a meeting. We plan to extend
our work to identify suitable mechanisms to identify meeting importance and meeting rescheduling.
We also plan to contribute to the ongoing research for creating and managing user profiles and
testing our prototype system in the real-world environment.
7. Reference
[1] E. Crawford. “Learning to Improve Negotiation in Semi-Cooperative Agreement Problems,”
Ph.D. Thesis, Carnegie Mellon University, Pittsburgh, PA, 2009. Available: http://reportsarchive.adm.cs.cmu.edu/anon/2009/CMU-CS-09-111.pdf.
[2] M. Masli, W. Geyer, C. Dugan and B. Brownholtz, "The design and usage of tentative events
for time-based social coordination in the enterprise," in International World Wide Web
Conference, 2011.
[3] A. BenHassine and T. B. Ho, "An agent-based approach to solve dynamic meeting scheduling
problems with preferences," Engineering Applications of Artificial Intelligence, vol. 20, sep, 2007,
pp. 857-873.
[4] E. Crawford and M. Veloso, "An experts approach to strategy selection in multiagent meeting
scheduling," Autonomous Agents and Multi-Agent Systems, vol. 15, August, 2007, pp. 5-28.
[5] T. E. Lai. “Neural network preference learning approaches for improving agent-based meeting
scheduling
problems,”
M.Sc.
Thesis,
Universiti
Putra,
Malaysia,
2007.
Available:
http://psasir.upm.edu.my/5218/1/FSKTM_2007_19.pdf.
[6] M. Handel and J. D. Herbsleb, "What is chat doing in the workplace?" in Proceedings of the
2002 ACM Conference on Computer Supported Cooperative Work, New Orleans, Louisiana,
USA, 2002, pp. 1-10.
[7] J. C. Tang, E. A. Isaacs and M. Rua, "Supporting distributed groups with a montage of
lightweight interactions," in Proceedings of the 1994 ACM Conference on Computer Supported
Cooperative Work, Chapel Hill, North Carolina, United States, 1994, pp. 23-34.
16
[8] P. M. Berry, M. Gervasio, B. Peintner and N. Yorke-Smith, "PTIME: Personalized assistance
for calendaring," ACM Transactions on Intelligent Systems and Technology, vol. 2, July, 2011,
pp. 40:1-40:22.
[9] Microsoft Corporation, "Microsoft Outlook," Microsoft, 2012, [Online]. Available:
http://office.microsoft.com/en-us/outlook/ [Accessed: July 2012].
[10] Microsoft. Corporation, "Microsoft Exchange," Microsoft, 2012, [Online]. Available:
http://www.microsoft.com/exchange/en-us/default.aspx/ [Accessed: July 2012].
[11] E. Shakshuki, H. Koo, D. Benoit and D. Silver, "A distributed multi-agent meeting
scheduler," Journal of Computer and System Sciences, vol. 74, March, 2008, pp. 279-296.
[12] N. Ducheneaut and V. Bellotti, "E-mail as habitat: an exploration of embedded personal
information management," Interactions, vol. 8, sep, 2001, pp. 30-38
[13] P. J. Modi, M. Veloso, S. F. Smith and J. Oh, "CMRadar: A personal assistant agent for
calendar management," in Proceedings of the 19th National Conference on Artifical Intelligence,
San Jose, California, 2004, pp. 1020-1021.
[14] R. Berres and E. Oliveira. Automated distributed meeting scheduler. Faculdade de
Engenharia, Universidade do Porto, NIAD&R-LIACC. Rua dos Bragas, 4099 Porto Codex,
Portugal. 1999Available: http://paginas.fe.up.pt/~eol/ADMS/adms.html.
[15] S. Sen, "Developing an Automated Distributed Meeting Scheduler," IEEE Expert: Intelligent
Systems and their Applications, vol. 12, July, 1997, pp. 41-45.
[16] R. G. Smith, "The Contract Net Protocol: High-Level Communication and Control in a
Distributed Problem Solver," IEEE Transactions on Computers in Computers, vol. 29, dec, 1980,
pp. 1104-1113.
[17] J. Yarow, “107,000,000,000,000” Business Insider, January 14, 2011, [Online]. Available:
http://www.businessinsider.com/internet-statistics-2011-1 [Accessed: July 2012].
[18] T. Shintani, T. Ito and K. Sycara, "Multiple negotiations among agents for a distributed
meeting scheduler," in Proceedings of the Fourth International Conference on MultiAgent
Systems, 2000, pp. 435-436.
[19] P. J. Modi and M. Veloso, "Multiagent meeting scheduling with rescheduling," in Distributed
Constraint Reasoning, (DCR), 2004.
[20] J. Wainer, J. Ferreira Paulo Roberto and E. R. Constantino, "Scheduling meetings through
multi-agent negotiations," Decision Support Systems, vol. 44, November, 2007, pp. 285-297.
[21] G. Jiang and L. Wu, "Research on method of multi-agent negotiation strategy selection," in
Proceedings of the 2010 Fifth International Multi-Conference on Computing in the Global
Information Technology, 2010, pp. 110-115.
[22] C. Bartolini, C. Preist and H. Kuno, "Requirements for Automated Negotiation", HewlettPackard Labs, [Online]. Available: http://www.w3.org/2001/03/WSWS-popa/paper19, [Accessed:
July 2012].
[23] S. Kraus, "Mutli-agents systems and applications," in J. G. Carbonell and J. Siekmann, Eds.
New York, NY, USA: Springer-Verlag New York, Inc, 2001, pp. 150-172.
[24] A. Rubinstein, "Perfect Equilibrium in a Bargaining Model," Econometrica, vol. 50, January,
1982, pp. 97-109.
17
[25] F. Keller, "Connectionist and Statistical Language Processing," October, 2003, [Online].
Available: http://www.coli.uni-saarland.de/~crocker/courses/learning/lecture1_2up.pdf [Accessed:
July 2012].
[26] J. Diederich and T. Iofciu, "Finding communities of practice from user profiles based on
folksonomies," in Proceedings of the EC-TEL06 Workshops, Crete, Greece , October 1-2, 2006.
[27] S. Schiaffino and A. Amandi, "Artificial intelligence," in , M. Bramer, Ed. Berlin, Heidelberg:
Springer-Verlag, 2009, pp. 193-216.
[28] K. Sycara and D. T, "Agent Reasoning in Negotiation," In Handbook of Group Decision and
Negotiation, C.Eden and M.Kilgour (Eds), ISBN 978-90-481-9096-6, 2010, July, 2010.
[29] J. M. Bernardo, "Probability and statistics," Encyclopedia of Life Support Systems, 2003.
[30] M. Salamó, K. Mccarthy, and B. Smyth, “Generating recommendations for consensus
negotiation in group personalization services”, Personal Ubiquitous Computing, Vol. 16, June
2012, pp. 597-610.
[31] J. I. Vazquez and D. Lopez, “WebProfiles: A Negotiation Model for User Awareness in
Personal Area Networks”, in Proceedings of the The Second Annual International Conference on
Mobile and Ubiquitous Systems: Networking and Services (MOBIQUITOUS). IEEE Computer
Society, Washington, DC, USA, 2005, pp. 373-383.
[32] N. Yim and S. Choi, "Strategic decision making support model on RTE approach from the
BPM," in Proceedings of the 7th International Conference on Electronic Commerce, Xi'an, China,
2005, pp. 400-407.
18