WO2011001291A2

WO2011001291A2 - Method and apparatus for managing interpersonal communications

Info

Publication number: WO2011001291A2
Application number: PCT/IB2010/001936
Authority: WO
Inventors: Tara Rosenberger Shankar; Aurélien Guillou; Chaochi Chang; Adrian Budiu
Original assignee: France Telecom
Priority date: 2009-06-30
Filing date: 2010-06-25
Publication date: 2011-01-06
Also published as: WO2011001291A3

Abstract

A method for using at least one Computing device connected to a common network for managing a call meeting between a plurality of end users, each end user employing one or more devices connectable to the common network The method performing the acts of receiving at least one call meeting invitation from a first end user, the call meeting invitation including one or more invitees to the at least one call meeting, generating one or more sequential mutual Windows of opportunity based on availability of the one or more invitees, subscribing to presence information of the first end user and the one or more invitees during an actuated window of opportunity, and initiating the call meeting when acceptance of the call meeting invitation during a current mutual window of opportunity for ail of the first end user and the one or more invitees is indicated.

Description

METHOD AND APPARATUS FOR MANAGING INTERPERSONAL COMMUNICATIONS

FIELD OF THE PRESENT SYSTEM:

The present system relates to a method and system for scheduling and managing real-time interpersonal communications such as voice calls, IM, and video calls between two or more parties, and more particularly to a method and system that uses real-time context information, pre-planning devices such as calendars, and prediction models of their availability for real-time communications from two or more parties to coordinate events between them in a just in time manner BACKGROUND OF THE PRESENT SYSTEM:

In the era when computers were limited to desktops and phones were limited by the landline to homes, offices, and stationary public phonebooths, it was easier for a caller to gauge when to call another person, e g , an acquaintance or friend, in an appropriate manner Work colleagues called during work hours, family members called at lunchtime or other breaks and at home In the current age, with pervasiveness of mobile phones, it is difficult to know how to reach another person or called party on the phone or other real-time communication device without interrupting an important meeting or function, disturbing the called party's concentration while driving, or simply calling at inappropriate times, such as when the called party is sleeping

The popularization of unified communication systems that use single "reach me anywhere" numbers that redirect communications to other device numbers, e g , office, work mobile, personal mobile, home landline, etc , with "follow me" or "ring everywhere" services, e g , GrandCentral/Google

Voice, Wildfire, has complicated the above scenario further by blurring the home/office distinction that the caller and called party might share, by directing the call to a certain mobile or home phone number

Now, while these services provide a simpler interface for the caller, such as fewer numbers to call or remember, the called party still does not have any control over when a caller will call or understand any better why the caller is calling Furthermore, with unified communication systems, the fact that a certain device, such as a work phone, is ringing, no longer holds intrinsic meaning, like the call will be work-related since it is being received on a work number, as routing algorithms in a unified communication system may direct calls to any end point, thereby redirecting work oriented calls to ring through at the called party's home and personal calls directed to ring through at work, all potentially at inconvenient times

Systems that make use of a person's contextual information to actively intervene in call placement and routing must choose to what extent to leave decision-making responsibilities with the technology (system-driven) or with the humans (user-driven) User driven approaches focus on how to make the called party's presence known or visible to the caller so that the communication needs may be fulfilled in the best, unintrusive way possible, such as at a best time, over the most appropriate media channel, to communicate

Some user driven approaches rely completely on the user to push there own context and presence manually, see for example, Les Nelson, S BIy, and T Sokoler, "Quiet Calls Talking Silently on Mobile Phones," Proceedings of the SIGCHI conference on Human factors in computing systems, 2001 , pp 174-181 , E R Pederson, "Calls calm" Enabling Caller and Callee to Collaborate," ACM Transactions on Computer-Human Interaction, 2001 , pp 235-236, C Peπng, "Taming of the Ring Context Specific Social Mediation for Communication Devices," Conference on Human Factors in Computing Systems, 2002, pp 712-713, and A Schmidt and A Takaluoma, "Context-Aware Telephony Over WAP," Personal and Ubiquitous Computing, VoI 4, Issue 4, 2000, pp 225-229 This approach may be burdensome to the user

To solve this problem, some have developed sensor-based statistical models to automatically categorize the user's context and presence, see for example, M Danninger et al , "The Connector - Facilitating Context-aware Communication," Proceedings of the 7th international conference on Multimodal interfaces, 2005, pp 69-75, hereinafter referred to as ("Danninger 1 "), M Danninger, T Kluge, and R Stiefelhagen, "MyConnector - Analysis of Context Cues to Predict Human Availability for Communication," Proceedings of the 8th international conference on Multimodal interfaces, 2006, pp 12-19, hereinafter referred to as ("Danninger 2"), J Fogarty, S E Hudson, and J Lai, "Examining the Robustness of Sensor-Based Statistical Models of Human Interruptibility," International Journal of Human-Computer Studies, vol 61 , issue 3, 2004, pp 207-214 hereinafter referred to as ("Fogarty") This is typically done in an office or other special environments that may be especially instrumented for the context detection, (see Danninger 1 and Danninger 2), but some approaches have involved mobile detection as well, see for example, Fogarty and E Horvitz et al , "Bayesphone Precomputation of Context-Sensitive Policies for Inquiry and Action in Mobile Devices," Proc of User Modeling, 2005, hereinafter referred to as ("Horvitz") Both of these approaches work best when the user's context is projected with as much detail as possible But projecting detailed user context and presence may be an invasion of privacy especially in a mobile environment when the user has to reveal her status at all times, (e g , 24 hours a day, 7 days a week) Furthermore, these approaches trust the caller to make a mutually beneficial decision, but all decision making power actually remains in the hands of the caller As automated voice calls and spam increases, it is not wise to trust the caller with the mutual well- being of both parties

Some unique efforts include a Negotiator to balance the decision making between the caller and called party by collaboratively developing and committing to a plan for communicating at an offset from the current time, see for example, M Wiberg and S Whittaker, "Managing Availability Supporting Lightweight Negotiations to Handle Interruptions," ACM Transactions on Computer-Human Interaction, vol 12, 2005, pp 356-387 In the Negotiator's mobile interface, the caller and called party exchange proposals for a time commitment expressed as an offset from the current time, and who is responsible for placing the call

A different approach to this problem is to use sensor-based statistical models to categorize the user's situation into a model of activity to which rules are applied automatically for call-handling and other interruptions, see Horvitz While this establishes an active advocate for the called party, it is not often thought to be capable of making the right call management decisions Typical problems with this approach are that the sensor-based statistical models are quite simplistic relative to a human's ability to categorize human contexts and availability, often leading to bad decisions For example, an urgent or important call may be blocked that shouldn't have been This is related to the fact that statistical models simply maynot predict the exceptional case People will not commit to using a system that might cause them to miss that one potential emergency or important call in important domains such as call handling, instead accepting inconvenience and many inopportune interruptions Additional problems are in the typical "black box" implementation of any automatic classification system that learns from a user's previous behavior and makes decisions on the user's behalf users do not know precisely what decisions the machine will make on their behalf, have no way of asking questions or running simulations, do not have a good way of reviewing and evaluating its decisions in a kind of feedback loop, and do not know or have the means of quickly changing the responses or resetting of such systems when previous behavior is no longer a valid model for future decisions, such as when a person changes jobs or moves to a different house

In addition to the problems identified above, scheduling multiparty calls for three or more people adds exponential challenges to the above pre-existing problems, including coordinating the scheduled commitments of many people, their time preferences for a call, as well as any last minute changes to their on-the-ground context and availability Scheduling a multiparty call in a just-in-time manner is very difficult Typically multiparty calls involve a lot of advance planning through asynchronous and synchronous communication exchanges If multiparty calls might include some mobile users, the difficulty of scheduling a multiparty call in a just in time manner increases because of the many different kinds of environments that participants might find themselves in, e g , driving, public transportation, loud or quiet environments In a conference call distributed across time zones due to travel or to an international organization, scheduling is difficult due to shorter overlaps in the working day and potential for encountering very different kinds of contexts, such as some people may be at work while some people, such as in a different time zone, may be at home Since the investment in time and planning is so high, conference calls are inflexible and are likely maycelled or rescheduled less often than other calls Due to the inflexibility they add to a person's schedule, conference calls or multiparty calls are likely used less often than they might otherwise be

What is needed is for a way to schedule, manage and execute multiparty calling from various available devices, such as, mobile phones, computers, TV set top boxes, PSTN phones, VoIP phones, so as to be easier to plan and successfully complete the multiparty call SUMMARY OF THE PRESENT SYSTEM:

It is an object of the present system to overcome disadvantages and/or make improvements in the prior art

It is another object of the present system to provide a system and a method for scheduling and managing real time interpersonal communications such as voice calls, instant messaging (IM), video calls, and other forms of communicaiton between two or more people In one embodiment, the present system includes an interactive and iterative three stage process to (1 ) generate predictive models of recipients' availability for a proposed meeting of an estimated length and expiration time and merge these models to reveal a set of mutual windows of opportunity Specifically, the predictive models may be based on explicit events drawn from the user's pre-planning tools, such as calendars, etc , and from routines and habits predicted from the user's call history and the user's location and mobility history, (2) provide a computer supported collaborative visual interface tailored for a mobile device for participants to monitor (passively or actively) detailed upcoming meeting proposals, and if they wish, explicitly influence the set of windows of opportunities identified based on their personal preferences In accordance with an embodiment of the present system, each invited participant may postpone the meeting from occurring at certain windows of opportunity or reject the call altogether before it happens, and (3) when a possible time or window of opportunity for the real time meeting arrives, the system subscribes to real-time presence information for all parties to the call invitation The system may then seek to determine if a moment may be identified in real-time when all participants are available for a call To do so, the system monitors each party's real-time context, e g , 'moment to moment activity based on sensor data from the party's mobile device, primarily location, mobility, and call status which the system makes available on a central server And, if all recipients and the initiator of the call invitation become available simultaneously during a window of opportunity, the system will link all parties on a real-time audio connection Of course it is understood that while the discussion in the present document uses the term audio, audio/visual, video, and textual, real-time connections are assumed

In accordance with other embodiments of the present system, the above three stages may be used to coordinate real-time events between multiple parties using mobile devices, context sensors, and server application technology to book other real-time events such as a lunch/coffee date, book an online game for multiple participants, book a meeting, and so on

Provided is a method for using at least one computing device connected to a common network for managing a call meeting between a plurality of end users, each end user employing one or more devices connectable to the common network The method performing the acts of receiving at least one call meeting invitation from a first end user The call meeting invitation may include one or more invitees to the at least one call meeting, the one or more invitees may be selected from the plurality of end users One or more sequential mutual windows of opportunity may be generated based on availability of the one or more invitees, wherein the availability is determined through application of prediction models Collaborative user interfaces may be provided for all of the one or more invitees and the first end user to refine the set of windows of opportunity identified by the system All of the first end user and the one or more invitees may subscribing to real-time presence information during a current mutual window of opportunity The call meeting may be initiated when acceptance of the call meeting invitation during a current mutual window of opportunity for all of the first end user and the one or more invitees is indicated The call meeting is initiated on the end users' devices having modes of communication selected from at least one of audio, video, and text

BRIEF DESCRIPTION OF THE DRAWINGS:

The present system is explained in further detail, and by way of example, with reference to the accompanying drawings wherein

FIG 1 is a diagram of a system for managing interpersonal communications in accordance with an embodiment of the present system,

FIG 2 is an exemplary user interface for meeting creation in accordance with an embodiment of the present system,

FIG 3 is a flowchart diagram of acts performed by a server agent of an embodiment of the present system to achieve a meeting creation,

FIG 4 is a sequence diagram illustrating the meeting creation in accordance with an embodiment of the present system,

FIG 5A is an exemplary user interface of the homescreen of the application from which a complete list of upcoming meetings and historical meetings may be browsed and acted upon in accordance with an embodiment of the present system,

FIG 5B is an exemplary user interface for all of the invited participants and the end user to collaborate by removing certain windows of opportunity, i e a timeslot, from consideration by the system, in accordance with an embodiment of the present system,

FIG 6 is a sequence diagram for collaboratively selecting a window of opportunity in accordance with an embodiment of the present system,

FIG 7 is an exemplary user interface for providing a meeting invitation in accordance with an embodiment of the present system,

FIG 8 is a flowchart diagram of acts performed by a notification manager of the present system to achieve a meeting creation in accordance with an embodiment of the present system,

FIG 9 is a sequence diagram for generation of meeting invitations in accordance with an embodiment of the present system, FIG 10 is a flowchart diagram for making a meeting decision in accordance with an embodiment of the present system,

FIG 1 1 is a sequence diagram for making a meeting decision in accordance with an embodiment of the present system,

FIG 12 is a flowchart diagram for a predictive manager that predicts for all of the invited participants and the end user their individual availability in accordance with an embodiment of the present system,

FIG 13 is a flowchart diagram for a calendar manager in accordance with an embodiment of the present system,

FIG 14 is a flowchart diagram for a Decision Algorithm in accordance with an embodiment of the present system,

FIG 15 is a flowchart diagram for a Basic Decision Algorithm in accordance with an embodiment of the present system,

FIG 16 is a flowchart diagram for a Decision Algorithm based on interruptibility level of the participants and call priority (fuzzy logic) in accordance with an embodiment of the present system,

FIG 17 is a flowchart diagram for a Decision Algorithm based on user profiles and call priority in accordance with an embodiment of the present system,

FIG 18 is a flowchart diagram for a Conference Call manager in accordance with an embodiment of the present system,

FIG 19 is a flowchart diagram for a Presence sequence in accordance with an embodiment of the present system,

FIG 20 is a flowchart diagram for a client component for detecting device presence in accordance with an embodiment of the present system,

FIG 21 is a flowchart diagram of a Status Monitor Component in accordance with an embodiment of the present system,

FIG 22 is a flowchart diagram of a Status Monitor Component with error handling in accordance with an embodiment of the present system,

FIG 23 is a sequence diagram for Location History component in accordance with an embodiment of the present system, and

FIG 24 is a diagram of a computing device for executing various components of the present system in accordance with an embodiment of the present system

DETAILED DESCRIPTION OF THE PRESENT SYSTEM:

The following are descriptions of illustrative embodiments that when taken in conjunction with the following drawings will demonstrate the above noted features and advantages, as well as further ones In the following description, for purposes of explanation rather than limitation, illustrative details are set forth such as architecture, interfaces, techniques, element attributes, etc However, it will be apparent to those of ordinary skill in the art that other embodiments that depart from these details would still be understood to be within the scope of the appended claims Moreover, for the purpose of clarity, detailed descriptions of well known devices, circuits, tools, techniques and methods are omitted so as not to obscure the description of the present system It should be expressly understood that the drawings are included for illustrative purposes and do not represent the scope of the present system In the accompanying drawings, like reference numbers in different drawings may designate similar elements

An inventive system 10 shown in FIG 1 uses one or more server agents 100 to achieve a collaboration of a plurality of client agents 102 The server agents 100 are running on computing devices (see FIG 24) connectable to a wide area network, such as the Internet, via wired or wireless means The server agents 102 are running or executing on devices such as mobile devices, including cell phones, laptops, desktops, TV set-top boxes, SIP devices, etc , also connectable to the wide area network, such as through wired or wireless means The system 10 enables the end users, i e , the owners of the devices, to interact with the internal functions of the server agent 100 in order to make creation and realization of a multiparty call meeting a more transparent, collaborative, and simple process

The server agent 100 comprises three main components, including click to book a call (C2BC) 104, Presence component 106, and History component 108 Each of these components may be implemented as Web Services in a modular way For example, Conference Call Manager 1 10, used to setup a conference call, maybe implemented without using services of the entire C2BC 104 Each component 110-130 manages its own data A database 132 may also be managed by/from the server agent 100 The database 132 stores data, such as, user names, email addresses, phone numbers, device ID (IMEI) of devices running client agents 102, etc

C2BC 104 comprises Conference Call, Notification, and Calendar Managers 1 10, 1 12, 114

The Calendar Manager 1 14 is used to merge several end users' calendars to produce a list of timeslots called "windows of opportunity" during which the group of end users invited to a call meeting is available according to events recorded on these end users' calendars The calendar events may be either explicit events created by the unique end users or implicit "routine events" created by the computing device, based on the end users' prior context and presence history Conference Call Manager 1 10 permits a setup of a conference call between one or more end users The system 10 may be limited to conference calls that are proposed to occur within the next 24 hours or open to calls that are proposed to occur within an unlimited or open-ended time frame Thus C2BC 104 may be enabled to setup the conference call Notification Manager 1 12 is used to send a private SMS notification using, for example, the ClickAtell Web Service API, by the system 10 to, for example, the Client Agent 102 of an end user device 12 Presence component 106 may include a server that stores context information automatically sensed from the end user devices 12, e g , mobile devices, and a context processing component that makes a decision regarding the end user's presence based on the aggregate context data The presence decision may be used by the server agent 100 to time the start of the proposed call meeting, or in any other notification that requires the end user's immediate attention The context data may include one or more of mobility status, e g , is the user driving, walking, stationary, etc , call status, e g , is the user in a call, and screen status e g is the user typing something on their device

The end users' status may also be developed from other sources including various social and community websites subscribed to by the end users Such sites, e g , Facebook com, MySpace com, Linkedln com, Twitter com, www2 orange co uk are to be found on the Internet and include user addresses, logged in status, activity level status, "What are you doing?" explicit status, and moods

History component 108 may be used to make inferences and predictions about the end user's behavior based on a history of automatically sensed behavioral data The data set used to model location and communication history 126 and 128, may come from any number of sources that a triple play telecom (voice, broadband Internet, and video from the same provider) has access to, including a history of the server agent 100 itself in performing connections, e g , Internet Messenger, Video, Voice usage Thus, inferences generated may be based on the end user's behavior across a wide set of communication services For example, the end user's call history provides information about the end user's habits in calling or receiving calls, such as at what time, in which locations, and from whom From the end user's history of mobility, History component 108 might discover regular periods of time when the end user should not be interrupted, e g , during a morning or evening commute on weekdays, or periods of time when the end user prefers to be interrupted by a certain group of identifiable individuals, e g , close friends and family may call during lunch hour or break time on weekdays The server agent 100 uses these inferences and predictions to decide at which time frames or windows of opportunity is the end user likely available to receive a notification or are all users likely available to take a person to person or a conference call

FIG 2 shows an exemplary user interface for creation of a call meeting that may be implemented in the C2BC component 104 An initiator end user defines a call meeting invitation, which may include the initiator end user's and called party's identities, a reason for the invitation, including a subject for the meeting, e g , a series of words like "Meet and greet ", a URL that refers to some media object such as an audio recording of a previous meeting, a previous call or minutes from a call, or a document

Additional information on the call meeting invitation may include the initiator end user's mood, e g , represented in an iconic form, call importance, e g , low to high urgency, and the initiator's local context, e g , location, mobility status, type of device used in the invitation, people or other end users from an address book, and specifying a required (default) or optional status This status may be used by the server 100 to handle collaborative input from the recipients, e g , required participants' preferences carry more weight in the algorithm

After the participants are selected, the server agent 100 may follow a meeting creation flowchart 300 shown in FIG 3 to establish call meeting duration and expiration The information on the call meeting invitation may include an estimation of the length of the meeting/call, e g , 10 minutes, and an expiration date and time for the invitation, e g , four hours from the present, after which the invitation is no longer active Accordingly, during act 302, further discussed below with reference to FIG 13, the calendars of all the participants may be merged with the help of the Calendar Manager 1 14, thereby creating a list of windows of opportunity in accordance with an embodiment of t present system During act 304, further discussed below with reference to FIG 4, invitations may be distributed to the client agents 102 with reference to FIG 1 , and shown with further reference to FIG 5A, the client agent 102 homescreen containing all the upcoming meeting proposals and list of historical meetings that have occurred, expired, or been rejected After receiving notification of the meeting invitation and before a meeting occurs, the user may influence the set of windows of opportunity as follows During act 306, further discussed below with reference to FIG 5B, a collaborative window of opportunity may be removed from consideration by the server agent 300 In a case wherein the current time is greater or equal to the onset of any window of opportunity during act 308, a check is made to see if a window of opportunity has to be activated If not activated, act 308 is repeated, e g , every minute or other defined interval Otherwise, the server agent 100 may send a call meeting invitation to the participants during 310, as will be further discussed below with reference to FIGs 8 and 9, and during 312, users may make decisions regarding the call meeting invitation, as will be further discussed below with reference to FIG 10 Act 312 is fulfilled when all users receive the call meeting invitation and decide to "accept", "postpone", or reject entirely the proposal to hold a real-time call at the present moment"", with reference to FIG 10

As illustrated in FIG 4, a host end user of device 12 may create a meeting from the client application 102 As discussed above, the host may create a subject, select the participants, the duration and the expiration time/date of the meeting, and may select "create" on the client application 102, which sends the information to the server agent 100 On the server side, the calendar manager 1 14 may merge all the calendars of the requested call meeting participants', in order to provide all the available meeting times between the requested participants' and the host end user before the invitation's expiration date Then, the notification manager 1 12 may create the corresponding events for the call meeting, which will be activated at the beginning of each timeslot of a call meeting, as will be discussed with reference to FIG 8

As soon as a call meeting is created, its status is "pending" Before the meeting becomes "active", the "pending" status allows each call meeting participant to choose the window of opportunity or timeslots for the meeting which best match his/her availability or preference This is illustrated in FIG 5B, where three timeslots 3 00, 3 30, and 4 00 may be postponed, such as not considered by the server, through a selectable Ul button This input shapes the time at which the server 104 will attempt to actuate the real-time call meeting This collaborative feature is optional all the meeting times identified by the server 104 may be enabled by default

As shown in FIG 6, each call meeting participant, using a device 12, e g , a phone, may select or unselect each time slot for a particular meeting In the implementation of an embodiment of the present system, a required or requested call meeting participants' selection or de-selection of windows of opportunities impacts the overall set of windows of opportunities treated by the server 104 If a window of opportunity is enabled, the call meeting participants might receive a meeting invitation based on their corporate availability If a window of opportunity is disabled, the server 104 will not send a call meeting invitation at this time, as will be discussed with reference to FIG s 8 and 9

The timeslot selection may be provided as an optional interface action, by default, all windows of opportunity identified by the server agent 100 during the calendar merge (see FIG 4) may be considered active

The notification manager 112 sends the call meeting invitation (see FIG 7) to all the call meeting invitees and the initiator in a "just-in-time" fashion, proposing to all a real-time call that would begin in the next few moments To make this happen, the identified windows of opportunity may be recorded as events on the server agent 100 A call meeting becomes active when at least one of the windows of opportunity is greater than or equal to the current time As shown in FIG 8, when a window of opportunity is active, during acts 802 and 804, the server agent 100 repeatedly checks the presence of each call meeting participant If and when all of the participants are simultaneously available, during act 806, the server agent 100 may send the call meeting invitation to the participants This is also discussed with reference to FIGs 9 and 15

As shown in FIG 9, at the beginning of a call meeting, during act 902 the server agent 100 checks the presence information of each of the call meeting participants If all the call meeting participants, using the end user devices 12, are "available" simultaneously, they will each receive a call meeting invitation during act 904 If not, the agent 100 will continue to check every invitee's context every minute, for example, during an active window of opportunity during act 902 until the windows of opportunity are exhausted

As shown in FIG 10, upon receipt of the call meeting invitation, the call meeting participant may either accept, decline or postpone the meeting If one or more required the call meeting invitees decline the call meeting (act 1006), the server 100 will delete the call meeting from the list of active call meetings, and the call meeting will be listed in History component 108 as being declined (act 1012) If during act 1004 one or more required call meeting invitees postpone the call meeting, the server 104 deletes the current window of opportunity from further consideration and re-lists the call meeting again as upcoming The server 100 waits until the next event notifying of the next window of opportunity to start the process all over again (act 804)

After accepting the call meeting invitation (act 1008), as shown in FIG 11 , the participant or end user may have the opportunity to choose which real time communication channel to use In one embodiment of the present system, IM, Voice, and Video channels are available If all the call meeting participants accept the call meeting, either an IM session meeting, video conference meeting, voice conference meeting will be created, e g , a bridge may be created based on the channel selected and the capability of the user agent profiles of the client agents 12, with the lowest common denominator channel used, e g , if one participant chooses IM and all devices are capable of IM, then all participants must use IM

The discussion of FIG 12 that follows, assumes that the video channel has been chosen for the call meeting as shown in FIG 1 1 On a regular basis the predictive manager 130 (FIG 1 ) may access the user's location history and communication components in order to update predictive models of each end user based on that end user's context, e g , location, activity, and communications (act 1202) These models are interpreted as new rules, which are added in the user's calendar as new events The predictive component 130 processes the end users' model daily and generates the corresponding "rules", including confidence levels (act 1206), which will be recorded or updated in the users' calendar as calendar events (act 1206) These machine generated calendar events have specific tags to label these events as machine-generated These tags will help the server agent 100 (and other services) to distinguish predicted calendar events from user specified events

For example, if between 6 00pm and 6 30pm an end user usually drives, e g , to go home from the office, the rule generated by the predictive model will be "does not take calls between 6 00pm and 6 30pm every weekday" As a result of such rule, the model processing will create a special class of event - a machine hypothesized event - between 6 00pm and 6 30pm in the end user's calendar The system 100 uses this calendar event to prevent interrupting the user at these times on weekdays As a result, the calendar not only contains the events explicitly created by the user, but also events generated implicitly by the Predictive Component 130 and based on the end user's history of communication and location data When the user creates a call meeting invitation, the Calendar Manager 1 14 will use these explicit end-user-generated and implicit machine-generated events to provide the windows of opportunity or timeslots

As shown in FIG 13, the end user using the device 12 creates a call meeting on the client agent 102 (See FIGs 3 and 4) First the C2BC component 104 passes end user selected contact list, call duration, and delay variables to the calendar manager 1 14, which retrieves calendar events from all the participants (act 1302), merges all the participants' calendars (act 1304) and provides the available timeslots of the day (1310), retrieve available timeslots (act 1306), and select the valid Timeslots (act 1308) depending on the delay and the duration variables, and generating available Timeslots of the day In accordance with an embodiment of the present system, the present system may use a decision algorithm (act 1404) with reference to FIG 14 Three embodiments of this algorithm that may be used, e g , for checking presence of the meeting participants for the server agent 100, are discussed below The decision algorithm in accordance with an embodiment of the present system is a binary matrix This matrix reflects the presence status of all the participants of a conference call This algorithm may be enriched with prediction and inference mechanisms based on history data such as the communication history and the location history

FIG 14 shows how a Decision Algorithm 1404 may used to evaluate presence status provided during act 1402 and indicate to act 1406, which sets up the call, that all participants are available

FIG 15 shows a basic Decision Algorithm having binary operations and results Deciding if a participant is "available" or present involves evaluating the context sensor data from the presence client executing on the device 12, and applying a binary logical formula 1502 or 1504

The decision algorithm 1500 provides binary results, it informs the system to make a call or not This approach does not include call priority management or an interruptibility profile management supplied, for example, by the end user

FIG 16 shows a Decision Algorithm able to process a priority level of a call or conference call set by the initiator end user Sometimes, it is important to receive a call even if the user status is indicated as not "available", e g , the end user is in a meeting or driving, because the importance or priority of the call outweighs the end user's need to not be interrupted That's why the algorithm should yield a decision with a probability score associated with it Depending on the call priority and the probability of the user's availability, the server could attempt to setup the call meeting or not

The presence status from all participants provided in table 1602 is ascertained in table 1604 Default interruptibility Level profiles are described at 1612 The participant interruptibility level is defined as Mobility + Screen + Call / 3, and the interruptibility level is∑ PIL / n, where n is the number of participants As illustrated, after the interruptibility level 1606 may be calculated, during act 1608 the call priority is checked with the interruptibility level of the participants If the interruptibility level of the participants is greater or equal to a call priority, e g , set at 0 5, then during act 1610 it is indicated that participants are available, otherwise during act 1614 it is indicated that some participants are not available

The end users have individual preferences about interpersonal communications Where some don't like to be interrupted, e g , while at a scheduled event or driving, others welcome interruptions The decision algorithm shown in FIG 17, assumes that the end users manage their own interruptibility profiles Accordingly, to provide for any missing profiles the system provides default profiles 1712 These profiles may be changed either from a client GUI installed on a client agent 12 or from a web portal having a network connection to the server 100 (See also 1612 of FIG 16) The call priority is set by the initiator of a conference call or the caller In one embodiment of the present system the Conference Call manager 110, shown in FIG 18, may use an enabler, e g , Clιck2Call enabler from orange co uk, to set up a conference call bridge and automatically place calls out to all the participants Other such products may be used by the server agent 100 to manage several channels for the meetings, e g , IM, Audio, Video, and other The presence status is determined by the presence component 106 shown in FIG 19 As shown, the presence manager 106 checks mobility, screen, and call status 1901 , 1902, and 1903 The statuses are provided by a client 102, Status Monitor program shown in FIG 20, running on the device 12

The Status Monitor program 2002 may run on the device 12, e g , the Android, to collect context data on the end user Technical details, including the design, the features used in the implementation, and how the Phone Status Monitor 2002 publishes the context data to the presence server will now be discussed

For example, when the phone 12 is used, the server 100 supports monitoring certain statuses of the phone, such as the phone call status, phone location, etc The client Status Monitor component 2002 utilizes these native phone status monitoring APIs to monitor the change of the phone status These APIs may includes

• Location Listener 2006 - a listener class for monitoring the phone's moving speed,

• Phone State Listener 2004 - a listener class for monitoring the phone's call activity, and

• On Configuration Changed 2008 - an event handler of Service class for monitoring the phone's configuration change, such as screen orientation

All these APIs work in a callback manner, i e , the system 100 will notify these APIs when events these APIs registered to monitor happened For example, the Phone Status Listener 2004 will be notified by the system when any call event happens, such as a call is coming in So the registered Phone Status Listener 2004 may inform Phone Status Monitor 2002 component accordingly

FIG 20 shows the interactions among Status Monitor 2002 component, various listeners, and the system When notified by sub-components monitoring various phone statuses about the status change, the Phone Status Monitor 2002 will try to publish the up to date presence information to the presence server 106 (FIG 1 ), which may be implemented as a machine to machine microblog service The Phone Status Monitor 2002 component may use RESTful APIs provided by microblog services to publish the presence information The system 10 network agent retrieves and searches presence information of particular specified end users using the flexibility and language-independence of RESTful APIs as well

FIG 21 illustrates the workflow of the Status Monitor 2002 component, including determining the status change and publishing the presence information In an embodiment when any status change is detected on the phone 12, the Phone Status Monitor 2002 aggregates all the other context statuses being monitored and sends a context update to the server using a defined JSON format, e g {"#ftrd" {"ID" "351676030178786","CS" "0","MS" "1 ","SS" "1 ","TS" "1242317160071 "}}

This method eliminates the need to track the user's state in the system 10 context network agent since each published message contains a complete record of the end user's current context However, the microblog message length, i e , 140 characters, limits the scalability of this method, e g , it may be impossible to add more context sensors without changing the client implementation - whereas the microblog server implementation has no such limits to scalability Ultimately, the Phone

Status Monitor 2002 will publish only the context status that has changed in a structured semantic format incorporating nanoformats, i e #object_name, @person_addressed, and the user's context state will be constructed actively through search

The communication between the Phone Status Monitor 2002 component and the system 10 microblog context server happens mostly in the cellular data network, which is not always stable Further, the present embodiment of the Phone Status Monitor 2002 takes extra care to handle potential publishing failure due to the network instability

1 The "Retry" mechanism The Phone Status Monitor 2002 may re-send the presence information message several times if it may not successfully publish it in the first attempt, and will stop retry if the retry count exceeds the pre-configured value This mechanism reduces the unnecessary publish attempt when the network connection is unstable If new status changes occur while the Phone Status Monitor 2002 re-attempts, the newest aggregated presence information message will be sent first, instead of the queue of unsent messages

NOTE This implementation, publishing the latest status only, will need to handle publishing a backlog queue of all detected status changes when a single context change is mapped to a single message in the next prototype iteration Timer based update In addition to publishing the aggregate context information when any status change happens, the Phone Status Monitor 2002 also attempts to send the aggregate context information message to the microblog context server in a fixed time period This implementation gives the latest presence information message another chance to be published in the event that the Retry mechanism failed (See FIG 22) In addition, it functions as a "heart beat" for the system 10 network agent to know if the phone is still attached to the system or is turned off or out of range In other words, if the system 10 network agent discovered that a particular phone did not update any presence information, the system 10 network agent knows that particular phone is either switched off or the Phone Status Monitor 2002 component was stopped or is out of network coverage, and will label the user's, i e owner of client device 12, current presence as "unknown"

As illustrated in FIG 23, the end user devices 12 collect location related data such as geographic coordinates (latitude, longitude) and/or other data which may be used to translate to a location, such as cell tower information (formatted as "Mobile Country Code" + "Mobile Network Code" + "Location Area Code" + "Cell ID") with the associated RSSI (Received Signal Strength Indication), a list of WI-FI access points with the corresponding RSSI readings, an IP address, etc The location related data will be stored locally on the client Depending on the location determination mechanism, and thus based on precision, only deltas or changes will be recorded A threshold will specify this delta which is different depending on the location determination mechanism In this way a smaller amount of data will be stored locally and a smaller amount of data will be sent to the server The data upload to the server 100 will be configurable based on a time interval or based on the availability of different types of data connections in the mobile device The location information may be collected from other third party sources such as a location server within the mobile network This will be provided via "adapters" to third party systems The decision to collect data from third party systems may be initiated by the Location and Location History comonent, based on the incoming request and the availability of the data

FIG 24 shows a portion of a system 2400 (e g , peer, server, etc ) in accordance with an embodiment of the present system For example, a portion of the present system may include a processor 2410 operationally coupled to a memory 2420, a display 2430 and a user input device 2470 The memory 2420 may be any type of device for storing application data as well as other data related to the described operation The application data and other data are received by the processor 2410 for configuring (e g , programming) the processor 2410 to perform operation acts in accordance with the present system The processor 2410 so configured becomes a special purpose machine particularly suited for performing in accordance with the present system

The operation acts may include requesting, providing, and/or rendering of information related a conference call request The user input 2470 may include a keyboard, mouse, trackball or other device, including touch sensitive displays, which may be stand alone or be a part of a system, such as part of a personal computer, personal digital assistant, mobile phone, set top box, television or other device for communicating with the processor 2410 via any operable link The user input device 2470 may be operable for interacting with the processor 2410 including enabling interaction within a Ul as described herein Clearly the processor 2410, the memory 2420, display 2430, and/or user input device 2470 may all or partly be a portion of a computer system or other device such as a client and/or server as described herein

The methods of the present system are particularly suited to be carried out by a computer software program, such program containing modules corresponding to one or more of the individual acts or acts described and/or envisioned by the present system Such program may of course be embodied in a computer-readable medium, such as an integrated chip, a peripheral device or memory, such as the memory 2420 or other memory coupled to the processor 2410 The program and/or program portions contained in the memory 2420 configure the processor 2410 to implement the methods, operational acts, and functions disclosed herein The memories may be distributed, for example between the clients and/or servers, or local, and the processor 2410, where additional processors may be provided, may also be distributed, or may be singular The memories may be implemented as electrical, magnetic or optical memory, or any combination of these or other types of storage devices Moreover, the term "memory" should be construed broadly enough to encompass any information able to be read from or written to an address in an addressable space accessible by the processor 2410 With this definition, information accessible through a network is still within the memory, for instance, because the processor 2410 may retrieve the information from the network for operation in accordance with the present system

The processor 2410 is operable for providing control signals and/or performing operations in response to input signals from the user input device 2470 as well as in response to other devices of a network and executing instructions stored in the memory 2420 The processor 2410 may be an application-specific or general-use integrated cιrcuιt(s) Further, the processor 2410 may be a dedicated processor for performing in accordance with the present system or may be a general- purpose processor wherein only one of many functions operates for performing in accordance with the present system The processor 2410 may operate utilizing a program portion, multiple program segments, or may be a hardware device utilizing a dedicated or multi-purpose integrated circuit

Finally, the above discussion is intended to be merely illustrative of the present system and should not be construed as limiting the appended claims to any particular embodiment or group of embodiments A further embodiment of the present system may provide a Ul that operates as a browser extension, such as a browser plug-in, that may add selection items (e g , radio buttons), visualizations of real-time planning collaboration by the invited people to the call, visualization of the end user's proposed communication schedule, modify selection items, and/or modify operation of the browser (e g , enable intercepting of an encrypted communication prior to rendering and/or sending the confidential communication) as described herein In addition, wile a radio button selection item is illustratively discussed for invitation to confidential communications etc , other Ul action elements may be similarly utilized, such as corresponding menu items, etc

Thus, while the present system has been described with reference to exemplary embodiments, including user interfaces, it should also be appreciated that numerous modifications and alternative embodiments may be devised by those having ordinary skill in the art without departing from the broader and intended spirit and scope of the present system as set forth in the claims that follow Further, while exemplary user interfaces are provided to facilitate an understanding of the present system, other user interfaces may be provided, and/or elements of one user interface may be combined with another of the user interfaces in accordance with further embodiments of the present system The section headings included herein are intended to facilitate a review but are not intended to limit the scope of the present system Accordingly, the specification and drawings are to be regarded in an illustrative manner and are not intended to limit the scope of the appended claims

In interpreting the appended claims, it should be understood that

a) the word "comprising" does not exclude the presence of other elements or acts than those listed in a given claim,

b) the word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements,

c) any reference signs in the claims do not limit their scope,

d) several "means" may be represented by the same item or hardware or software implemented structure or function,

e) any of the disclosed elements may be comprised of hardware portions (e g , including discrete and integrated electronic circuitry), software portions (e g , computer programming), and any combination thereof,

f) hardware portions may be comprised of one or both of analog and digital portions, g) any of the disclosed devices, portions thereof, acts, etc , may be combined together or separated into further portions, acts, etc , unless specifically stated otherwise,

h) no specific sequence of acts or acts is intended to be required including an order of acts or acts indicated within a flow diagram, and

ι) the term "plurality of an element includes two or more of the claimed element, and does not imply any particular range of number of elements, that is, a plurality of elements may be as few as two elements, and may include an immeasurable number of elements

Claims

What is claimed is

1 A method for using at least one computing device connected to a common network for 5 managing a call meeting between a plurality of end users, each end user employing one or more devices connectable to the common network, the method comprising the acts of

receiving at least one call meeting invitation from a first end user, the call meeting invitation including one or more invitees to the at least one call meeting, the one or more invitees are selected from the plurality of end users,

10 generating one or more sequential mutual windows of opportunity based on availability of the one or more invitees and the first end user, the availability is determined through application of implicit machine-generated prediction models and explicit user-generated information,

passively notifying all of the one or more invitees of the call meeting invitation by listing it as an upcoming event on the client devices of all of the first end user and the one or more invitees

I ⁴S providing collaborative user interfaces for the one or more invitees and the first end user to influence the system-generated set of windows of opportunity, based on which timeframes are the least and most appealing,

subscribing to presence information of the first end user and the one or more invitees when any particular window of opportunity is actuated,

0 initiating the call meeting when acceptance of the call meeting invitation during a current mutual window of opportunity for all of the first end user and the one or more invitees is indicated, wherein the call meeting is initiated on the end user s' devices having an appropriate mode of communication selected from at least one of audio, video, and text 5 2 The method of claim 1 , wherein the identifying act comprises an act of monitoring real-time context feed provided by the first end user and the one or more invitees

3 The method of claim 2, wherein the real-time context feed is selected from at least one of end user's moment to moment availability, primary location, mobility, and call status

0

4 The method of claim 2, wherein the acceptance is indicated automatically without input from the first end user and the one or more invitees by making a presence decision during the windows of opportunities based on the real-time context feed 5 5 The method of claim 1 , further comprising an act of sending the call meeting proposal to the first end user and the one or more invitees after the one or more mutual windows of opportunity are generated

6 The method of claim 1 , wherein the acceptance is indicated by a response selected fromS one of "accept now", "try again later", or "reject the call altogether"

7 The method of claim 1 , wherein the at least one call meeting invitation further includes information selected from at least one of a reason for the call meeting, a mood of the one or more invitees, an importance of the call meeting, the local context relevant to the first end user, a lifespan of the invitation, an urgency level, and an expected call meeting length

8 The method of claim 7, wherein the identifying act is based on the lifespan of the invitation, expected call meeting length, and the presence information 9 The method of claim 7, wherein the lifespan of the invitation and expected call meeting length are suggested to the first end user based on previous successful call meeting invitations sent between the first end user and the one or more invitees to the call meeting

10 The method of claim 7, wherein the at least one call meeting invitation further includes registration information identifying the first end user at third party enablers connected to the common network

1 1 The method of claim 10, wherein the third party enablers are selected from one or more Internet social and community websites having user email addresses, usernames or aliases, statuses, and moods

12 The method of claim 10, wherein the third party enablers comprise Facebook com, MySpace com, Linkedln com, Twitter com, www2 orange co uk 13 The method of claim 1 , wherein the presence information is selected from at least one of static calendar availability, dynamic mobility status, and dynamic in call status

14 The method of claim 13, wherein the dynamic mobility status defines an end user as stationary, walking, driving, biking, transporting, or unknown 15 The method of claim 1 , wherein the prediction models are based on previous call meeting invitations and calls between the first end user and the one or more invitees

16 The method of claim 15, wherein the first end user and the one or more invitees may monitor outstanding call meeting invitations and influence one or more mutual windows of opportunity by an act selected from changing the one or more mutual windows of opportunity, rejecting a specific window of opportunity, and rejecting the call meeting invitation

17 The method of claim 15, wherein the prediction models include a communication history enabler and device target enabler,

the communication history enabler modeling the first end user's call history across all devices employed by the first end user, the call history including time-stamped events for outbound and inbound calls with answered/ignored status and call duration, and

the device target enabler inferring on which of the plurality of devices and which channel to execute the call meeting

18 The method of claim 17, wherein the communication history enabler provides default values for the expected call meeting length and lifespan of the invitation by calculating historical averages

19 The method of claim 18, wherein the communication history enabler prioritizes call invitations in accordance with how important is the one or more invitees to the first end user