专利名称：用于用在线信息确定下一次联合可用性的通信系统和方法
技术领域：
本发明一般地涉及基于在线的(presence-based)通信系统，并且特别地涉及使用在线信息来确定两方或多方之间的通信会话的下一个可用时间。
背景技术：
基于在线的交互通信服务通过使被叫方(在线实体)向主叫方(在线观察者(watcher))实时地发布其在线信息(诸如可用性、活动性、本地时间、位置、活动设备/应用程序的当前状态等)以及其首选项信息(例如设备首选项)实现了更高效和更有效的通信会话。在线信息和首选项信息提高了建立各种类型的通信会话的效率，这些通信会话诸如语音通信会话、文本通信会话和多媒体(video+)通信会话。
在线系统采用管理多个在线实体的在线信息的在线服务器。在线服务器操作为从诸如日历/日程应用程序、电话应用程序或即时消息应用程序之类的各种在线源中收集在线信息，并整合该在线信息以反映在线实体的在线状态。例如，只要发生了预定的在线实体事件，诸如打开或关闭在线实体设备、从设备上修改注册信息、改变设备上的即时消息状态或将预定的事件输入到在线实体的日历中，负责的在线源就向在线服务器生成在线信息。作为示例，如果在线实体的日历上安排了一个从10:00a.m.(上午)到12:00p.m.(下午)的会议，则在10:00a.m，日历/日程应用程序会通知在线服务器将在线实体的在线状态设置为“正在开会”。作为另一个例子，当在线实体发起或接听电话呼叫时，电话应用程序通知在线服务器将在线实体的在线状态设置为“正在通话”。
定制了在线实体的在线信息的观察者当前可访问该在线信息。例如，假定观察者是发起用户并且在线实体是目的地用户，则发起用户能够得到反映目的地用户的当前可用性和通信首选项的目的地用户在线状态，并在尝试与目的地用户建立通信会话时利用该目的地用户在线状态。然而，如果目的地用户当前不可用或者如果通信尝试失败，则发起用户必须在稍后的时间上在不了解发起用户和目的地用户的下一次联合可用的时间的先验知识的情况下重新进行通信尝试。因此，当目的地用户再次不可用时，发起用户可能进行下一次尝试。
因此，需要一种通信系统，其用于整合多方的当前可用性和未来可用性，以在多方之间进行立即的通信或在所有参与方的下一次联合可用的时间上在多方之间进行未来的通信。
发明内容
本发明的实施例提供了一种用于确定发起用户与至少一个目的地用户之间的通信会话的当前用户可用性和未来用户可用性的通信系统。该通信系统包括在线服务器，该在线服务器用于收集和存储来自多个在线源的关于多个在线实体的在线信息，其中在线信息表明在线实体的当前可用性和未来可用性。该通信系统还包括通信管理器，该通信管理器用于接收来自发起用户的进行通信会话的请求，从在线服务器中提取发起用户和目的地用户的在线信息，并且响应于发起用户和/或目的地用户当前不可用，根据发起用户和目的地用户的在线信息来确定通信会话的下一个可用时间。
在一个实施例中，通信管理器还操作为向发起用户提供用于与目的地用户开始随后的通信会话的下一个可用时间。在另外的实施例中，在线服务器还维护每个在线实体的在线信息，并且通信管理器基于发起用户和/或目的地用户的首选项信息而对提供给发起用户的与通信会话的下一个可用时间有关的信息进行过滤。
在另一个实施例中，该通信系统还包括媒体服务器，该媒体服务器用于接收来自发起用户的进行通信会话的请求并将该请求提供给通信管理器。该媒体服务器还可操作为在下一个可用时间上在发起用户与目的地用户之间建立通信会话。
本发明的实施例还提供了一种用于使用表明发起用户和目的地用户的当前可用性和未来可用性的在线信息来确定发起用户与至少一个目的地用户之间的通信会话的可用性的方法。该方法包括接收来自发起用户的进行通信会话的请求，提取发起用户和目的地用户的在线信息，以及响应于发起用户和/或目的地用户当前不可用，根据发起用户和目的地用户的在线信息来确定通信会话的下一个可用时间。
结合附图，参考以下详细描述，可以获得对本发明的更全面理解，其中图1示出了根据本发明实施例的示例性在线系统；图2示出了根据本发明实施例的用于使用在线信息来确定通信会话的下一可用性的示例性通信系统；图3示出了根据本发明实施例的用于使用在线信息来确定下一次通信会话的联合可用性的示例性过程的流程图；并且图4是示出根据本发明实施例的示例性通信会话流程的信号流程图。
具体实施例方式
参考图1，其中示出了能够实现本发明的各种实施例的示例性在线系统100。在线系统100包括在线实体110以及与在线实体110相关联的一个或多个设备120。在线实体110代表目的地用户并向在线系统100提供关于目的地用户的在线状态的在线信息。每个设备120都是能够在通信网络130上发送和/或接收通信的物理通信设备。这种设备120的例子包括但不限于座机电话120a、笔记本计算机120b、个人计算机120c、移动电话120d以及个人数字助理(PDA)120e。在图1中，通信网络130代表可以从中发送媒体(电路交换或分组交换的语音或数据)的任意类型的网络。例如，通信网络130可以包括公共交换电话网(PSTN)、公共陆地移动网(PLMN)、一个或多个专用局域网(LAN)、因特网和/或任意其他类型的网络或网络的组合。
在线系统100还包括一个或多个在线用户代理140(PUA)，一个在线代理(PA)150，一个在线服务器160以及在线实体110的一个或多个观察者170。PUA 140能够处理并提供在线实体110的在线信息。在图1中，针对每个设备120示出了一个单独的PUA 140。然而，应当理解，在其他实施例中，PUA 140的数目可以基于设备120的数目和类型、设备120所支持的应用程序以及系统配置而变化。每个PUA 140独立地生成在线实体110的全部在线信息的一部分。通常，当在线状态发生改变时，PUA 140生成在线信息。在线状态改变的例子包括但不限于打开和关闭设备120、从设备120上修改注册信息以及改变设备120上的即时消息状态。
由一个或多个在线代理(PA)150收集来自每个PUA 140的在线信息。在图1中，为简单起见仅示出一个PA 150。然而，应当理解，在其他实施例中，一个在线实体110可以有多个PA 150，每个PA 150负责当前对在线实体110有效的全部定制(来自观察者170的对在线信息的请求)的一个子集。此外，PA 150收集来自日历/日程应用程序50(例如Microsoft Exchange Server，IBM Lotus Notes，MeetingMaker或其他类似的应用程序)和其他在线信息源60(例如即时消息应用程序)的在线信息。PA 150整合来自每个源(例如PUA140、日历50和其他源60)的在线信息并维护在线实体110的当前的完整在线信息。PA 150还向在线实体110的一个或多个观察者170(主叫方或通信会话发起者)提供在线信息。
在线服务器160还存储用于在线系统100的在线实体110和观察者170的首选项信息190。例如，首选项信息190可以同时包括由在线实体110针对每个观察者170而设置的在线实体首选项信息(例如隐私过滤器)以及由每个观察者170针对在线实体110而设置的观察者首选项信息(例如观察者过滤器)。首选项信息190操作为对提供给观察者170的在线实体110的在线信息180进行过滤以符合隐私考虑、优先级划分要求、管理器策略和安全考虑。
在线服务器160是一个物理实体，其可以操作为PA 150或者操作为用于将来自观察者170的请求路由到PA 150的代理服务器。在线服务器160存储多个在线实体110的在线信息180和首选项信息190。因此，可结合在线服务器160将PA 150操作为接收来自PUA 140的在线实体110的在线信息，接收来自观察者170的对在线信息的请求，并向观察者170提供在线信息。当用作PA 150时，在线服务器160还可以与PUA 140协同定位。
在线系统100使用在线协议来向在线实体110和观察者170提供在线服务。可以用于在线系统100中的在线协议的例子是会话初始化协议(SIP)，J.Rosenberg等人于2002年6月发表的“SIP会话初始化协议”草案3261(“SIPSession Initiation Protocol”RFC3261)以及A.Roach等人于2002年6月发表的“会话初始化协议(SIP)—特定事件通知”草案3265(“Session Initiation Protocol(SIP)-SpecificEvent Notification”RFC3265)中对此进行了描述，在此通过引用的方式包含其内容。SIP是用于创建、修改和终止通信(语音、文本和/或多媒体)会话的应用层控制协议。SIP可以与诸如实时传输协议(RTP)、实时流协议(RTSP)、会话描述协议(SDP)、国际电联电信委员会(ITU-T)H.263标准(视频编解码)、G.711标准和G.729标准(音频编解码)以及其他的或附加的标准或协议之类的其他协议一起使用。应当意识到，可以使用其他的或附加的协议和配置。
SIP网络能够将来自该网络上的任意用户的请求路由到维护该用户的注册状态的服务器上。因此，SIP网络使主叫方(观察者)能够发送对与将路由到在线服务器160的特定被叫方(在线实体110)有关的在线信息的SUBSCRIBE(定制)请求，其中在线服务器160维护在线实体110的在线信息。出于效率上的目的，运行时，在线服务器160与PA 150可以和SIP代理/注册器协同定位。
现在参考图2，其中示出了根据本发明实施例的用于使用在线信息来确定通信会话的下一可用性的示例性通信系统200。在图2中，发起用户210通过通信网络130(例如PSTN、PLMN、LAN、因特网等)向媒体服务器230发送与一个或多个目的地用户220(为方便起见，仅示出了其中一个)进行通信会话(例如实时或非实时的语音、文本或多媒体)的请求250。媒体服务器230包括对媒体(例如数据等)进行路由和/或将媒体从一种类型的网络所需的格式转换为另一类型的网络所需的格式的任意设备，诸如电路交换机、路由器、网关设备或其他设备。
请求250可以是用以与目的地用户220开始立即的通信会话(例如通过在GUI(图形用户界面)中点击名字而进行的拨号)的实际尝试或用以确定目的地用户220进行未来通信会话的可用性的查询。例如，可以将目的地用户在线信息显示给发起用户210，通知发起用户210目的地用户220当前可以进行通信会话，从而使得发起用户210发送进行未来通信会话的请求250。
响应于接收到的请求250，媒体服务器230向目的地用户的通信管理器(CM)240转发请求250。CM 240管理注册到在线服务器160的目的地用户220和其他在线实体/用户(观察者)的通信会话。CM240通常位于具有在线服务器160的目的地用户端。然而，在其他实施例中，CM 240可以与在线服务器160分散或相距遥远。CM 240可以与媒体服务器230或在线服务器160协同定位或者可以在独立设备上实现。
请求250包括发起用户210的标识(例如主叫方URI(统一资源标识符))，目的地用户220的标识(例如被叫方URI)，以及所请求的用于新的通信会话的媒体类型。此外，请求250可以包括用于通信会话的其他标准。例如，这种其他标准可以包括发起用户210所请求的安全模式或协议。在接收到请求250后，CM 240向在线服务器160发送对目的地用户220的在线信息180和首选项信息190以及发起用户210的在线信息180和首选项信息190的请求。
在线服务器160对来自由PUA(如图1所示)提供的电话信息的发起用户210和目的地用户220的在线信息180、由与发起用户210和/或目的地用户220相关联的日历应用程序50提供的调度信息以及由在线信息的其他源提供的另外的在线信息进行整合，并将整合后的在线信息180和首选项信息190发回CM 240。CM 240处理从在线服务器160返回的在线信息180和首选项信息190，以确定发起用户210针对所请求的媒体类型的当前在线状态以及目的地用户220针对所请求的媒体类型的当前在线状态。
发起用户210和目的地用户220的当前在线状态是类似地确定的，并且因此在此只讨论目的地用户220的在线状态。为了确定目的地用户220的在线状态，CM 240首先确定目的地用户220以所请求的媒体类型和其他媒体类型进行所请求的通信会话的媒体状态和可用性。
在线信息180包括在网络中注册到目的地用户220的每个设备，以及每个设备所支持的媒体类型和在每个设备上运行以获得目的地用户220的媒体类型能力的每个应用程序所支持的媒体类型。此外，在线信息180包括目的地用户220正在进行的(现行的)的实时通信会话。例如，在线信息180可以包括目的地用户220所参与的实时语音通信会话的当前数目、目的地用户220所参与的实时多媒体通信会话的当前数目以及目的地用户220所参与的实时文本通信会话的当前数目。此外，在其他的实施例中，在线信息180可以包括活动-媒体状态映射(activity-media status mapping)，以在开始/结束预定活动(诸如会议、外出午餐、驾驶汽车等)之后更新媒体状态。例如，目的地用户220可以将首选项数据输入到在线系统中，规定当目的地用户的日历表明目的地用户正在开会时媒体类型都不可用或只有某些媒体类型可用。
在示例性实施例中，CM 240将目的地用户220针对所请求的媒体类型和其他媒体类型的当前媒体状态与首选项信息190相比较，首选项信息190规定了进入在线系统中的目的地用户的各设备所支持的每种媒体类型的最大交互数目。特定媒体类型的最大交互数目表明在特定媒体状态进入“繁忙”状态之前用户/在线实体能够处理的实时交互的最大数目。用户/在线实体将最大交互数目规定为其首选项规则的一部分。根据由在线服务器160提供的首选项信息190和在线信息180中的最大交互数目，CM 240确定目的地用户220以所请求的媒体类型和其他媒体类型与发起用户进行所请求的实时通信会话的媒体状态和可用性。
例如，在一个实施例中，目的地用户220针对特定媒体类型的媒体状态可以处于以下状态中的一种状态“激活”、“使用中”、“繁忙”和“非激活”。然而，应当理解，术语“媒体状态”不限于这些状态，并且可以用任意其他方式来确定和表明。采用以上状态示例，对于每种媒体类型，“非激活”状态表明用户/在线实体还没有准备好处理与该特定媒体类型的交互。例如，当目的地用户220没有使用任何能够支持该特定媒体类型的设备登录到网络时，“非激活”状态适用。“激活”状态表明用户/在线实体已经准备好处理该特定媒体类型的交互。例如，当目的地用户220使用一个或多个能够支持该特定媒体类型的设备登录到网络时，“激活”状态适用。
对于每种媒体类型，“使用中”状态通知CM 240目的地用户220参与了使用该特定媒体类型的一个或多个通信会话。然而，目的地用户220仍然能够处理同一媒体类型的另外的交互。对于每种媒体类型，“繁忙”状态表明目的地用户220不能参与该媒体类型的任何通信会话。例如，“繁忙”状态可能由资源(例如通信信道)的局限性引起，由在线实体能力的局限性(例如，已经达到针对特定媒体类型的最大交互数目)引起，或者由规定当目的地用户的日历表明该目的地用户正在开会、旅行、离站(off-site)等时特定媒体类型不可用的首选项引起。此外，引起“繁忙”状态的原因是认为当前没有同时支持所请求的媒体类型并符合由发起用户210规定的其他标准的目的地用户220的激活设备。
如果目的地用户220针对所请求的媒体类型的媒体状态为“繁忙”并且/或者发起用户210针对所请求的媒体类型的媒体状态为“非激活”或“繁忙”，则CM 240确定目的地用户220和发起用户210中的一个对于所请求的通信会话“不可用”或者二者都“不可用”。然而，如果目的地用户220和发起用户210的媒体状态表明当前二者对于通信会话都可用，则CM 240确定用于新的通信会话的设备，并将诸如设备标识、设备的应用程序和媒体信道之类的设备信息发送给媒体服务器230，以经由通信网络130建立通信会话。
如果CM 240确定发起用户210和/或目的地用户220当前对于所请求媒体类型的所请求的通信会话不可用或者发起用户210或目的地用户220没有对通信会话进行应答，则CM 240确定通信会话失败。如果通信会话失败或者如果请求250是对未来通信会话的请求，则CM 240将目的地用户220的在线信息180和首选项信息190与发起用户210的在线信息180和首选项信息190相比较，以确定发起用户210和目的地用户220接下来对于所请求的媒体类型或其他媒体类型的通信会话都应当可用的一个或多个时间(下文中称为下一个可用时间260)。
例如，CM 240可以将发起用户210的日历在线信息180与目的地用户220的日历在线信息180相比较，以确定发起用户210和目的地用户220针对一个或多个媒体类型都可用的下一时间。作为示例，假定当前时间是9:00a.m.，并且目的地用户的日历表明该目的地用户在9:00a.m与10:00a.m.之间不可用(例如正在开会)，并且发起用户的日历表明该发起用户在9:30a.m.与10:30a.m.之间不可用，则发起用户210和目的地用户220都会可用的第一个时间是10:30a.m.。
在一个实施例中，CM 240确定通信会话的下一个可用时间260并将下一个可用时间260发送给发起用户210，这通知了发起用户210何时进行与目的地用户220建立通信会话的下一次尝试。下一个可用时间260包括特定时间(例如10:30a.m.)或时间间隔。继续以上示例，假定目的地用户的日历表明该目的地用户在11:00a.m.又会变得不可用(例如正在进行另一个会议)，则下一个可用时间260有可能表明发起用户210应当在10:30a.m与11:00a.m.之间的某个时候重新尝试与目的地用户220进行通信会话。
在另一个实施例中，CM 240检查发起用户210和目的地用户220的首选项信息，以确定任一方是否还没有定制“下一个可用时间”功能，或者任一方是否已经限定了与提供给发起用户210和/或目的地用户220的下一个可用时间有关的信息的范围。在此情况下，CM 240不会确定下一个可用时间或者CM 240对提供给发起用户210和目的地用户220中的一个或者同时提供给二者的与下一个可用时间260有关的信息进行过滤。
在其他实施例中，CM 240确定多个下一个可用时间260并将这些下一个可用时间260中的一个或多个下一个可用时间发送给发起用户210。例如，如果CM 240确定发起用户210和目的地用户220在10:30a.m.与11:00a.m.之间以及2:00p.m.与3:30p.m.之间的时间间隔上都会可用，则CM 240可以将两个时间间隔都发送给发起用户210。
在另一个实施例中，CM 240还设置一个触发点以在下一个可用时间260上自动地在发起用户210与目的地用户220之间建立通信会话。例如，当CM 240的内部(本地)时钟表明当前时间是下一个可用时间260，则CM 240可以通过分别建立通信会话的每个分支来尝试建立通信会话。如果下一个可用时间上的通信会话由于一方或两方现在当前不可用而失败，则CM可以发送通知消息给发起用户210，通知发起用户210通信会话失败，在失败时间上所确定的下一个可用时间上重新尝试通信会话并且/或者在未来的预定时间上重新尝试通信会话。例如，可以根据连续的通信会话尝试之间的预先配置的时间周期来确定未来的预定时间。
在又一个实施例中，CM 240访问发起用户210和目的地用户220的日历应用程序50，并在下一个可用时间260上对发起用户和目的地用户的日历应用程序50中的通信会话进行调度。例如，如果下一个可用时间260是10:30a.m.，则CM 240在10:30时同时在发起用户和目的地用户的日历上输入“在发起用户与目的地用户之间进行通信会话”。
在又一个实施例中，CM发送通知消息(例如即时消息、电子邮件、语音邮件等)给目的地用户220，通知目的地用户220发起用户对通信会话的请求以及通信会话的下一个可用时间260。例如，可以将下一个可用时间260作为与发起用户210进行通信会话的建议时间提交给目的地用户220。目的地用户220可以确认并同意该下一个可用时间260或者建议通信会话的备选时间。CM 240可以采用例如即时消息(IM)、电子邮件、语音邮件、终端显示器、用户按键或其他类型的通信在发起用户210与目的地用户220之间协商一个双方都方便的时间。可以将达成一致的下一个可用时间260作为触发点存储于CM 240中以建立通信会话，或者将该下一个可用时间260安排到发起用户210和目的地用户220的日历中。
应当注意，可以采用用于管理通信会话(例如实时的或非实时的语音、文本和多媒体通信会话)的硬件、软件、固件或其组合来构造或配置CM 240。作为一个例子，CM 240可以包括执行指令的一个或多个处理器以及存储处理器所用的指令和数据的存储器。一般认为处理器是驱动通用计算机的设备。然而，请注意，同样可以使用诸如微控制器、现场可编程门阵列(FPGA)、专用集成电路(ASIC)或其组合之类的其它处理器设备，并且这些处理器设备可以获得在此所述的好处和优势。在一个实施例中，CM 240可以包括诸如软件应用程序之类的一个或多个过程，这些过程提供产生特定结果的活动、功能或一系列任务，用于管理通信会话。
图3是示出根据本发明实施例的用于使用在线信息来确定下一次通信会话的联合可用性的示例性过程300的流程图。在方框310中，保持表明多个在线实体的当前可用性和未来可用性的在线信息。这些在线信息是从诸如电话应用程序、日历应用程序和其他应用程序之类的多个在线源中收集的。在方框320中，接收进行从发起用户到至少一个目的地用户的通信会话的请求。
在方框330中，提取发起用户的在线信息和每个目的地用户的在线信息，以在方框340中确定发起用户和目的地用户进行通信会话的当前可用性。如果所有参与方当前都可用(方框340的“是”分支)，则在方框350中在发起用户与目的地用户之间建立通信会话。然而，如果基于在线信息或基于不能建立通信会话(方框340的“否”分支)，发起用户和目的地用户中的一个或多个用户当前对于通信会话不可用，则在方框360中根据发起用户和目的地用户的在线信息来确定通信会话的下一个可用时间。在方框370中，将该下一个可用时间提供给发起用户用于与目的地用户建立未来的通信会话。
图4是示出根据本发明实施例的基于发起用户210和目的地用户220的联合可用性而建立通信会话的示例性流程的信号流程图。在步骤410中，发起用户210发送与目的地用户进行通信会话的请求给通信管理器(CM)240。响应于接收到的请求，在步骤420中，CM 240从在线服务器160请求发起用户的在线信息和目的地用户的在线信息，并且在步骤430中，在线服务器160将所请求的在线信息提供给CM 240用于确定发起用户210和目的地用户220进行通信会话的当前可用性和未来可用性。
如果发起用户210和/或目的地用户220当前对于通信会话不可用，则在步骤440中，CM 240根据发起用户210和目的地用户220的在线信息来确定通信会话的下一个可用时间。在步骤450中，CM240将该下一个可用时间提供给发起用户210用于与目的地用户220建立未来的通信会话。因此，在步骤460中，发起用户210在所指示的下一个可用时间上发送与目的地用户220进行通信会话的新的请求。
响应于接收到的请求，在步骤470中，CM 240再次从在线服务器160请求发起用户的在线信息和目的地用户的在线信息，并且在步骤480中，在线服务器160将所请求的在线信息提供给CM 240用于确定发起用户210和目的地用户220进行通信会话的当前可用性。如果两方当前都可用，则在步骤490中，在发起用户210与目的地用户220之间建立通信会话。
本领域的普通技术人员应当认识到，对于各种各样的应用，可以对本发明中所描述的新颖原理进行修改和变更。因此，本专利主题的范围不应限于所述任何特定示例性描述，而应由以下权利要求来限定。
权利要求
1.一种用于使用在线信息来确定发起用户与至少一个目的地用户之间的通信会话的可用性的通信系统，包括在线服务器，其用于收集和存储来自多个在线源的关于多个在线实体的在线信息，所述多个在线实体包括所述发起用户和所述至少一个目的地用户，所述在线信息表明所述在线实体的当前可用性和未来可用性；以及通信管理器，其连接为接收来自所述发起用户的进行所述通信会话的请求；其中所述通信管理器可操作为从所述在线服务器中提取所述发起用户和所述至少一个目的地用户的所述在线信息；并且其中响应于所述发起用户和所述至少一个目的地用户中的一个或多个用户当前不可用，所述通信管理器可操作为根据所述发起用户和所述至少一个目的地用户的所述在线信息来确定所述通信会话的下一个可用时间。
2.根据权利要求1所述的通信系统，其中所述多个在线源包括日历应用程序，所述日历应用程序为所述发起用户和所述至少一个目的地用户提供调度信息；并且所述在线信息包括所述调度信息。
3.根据权利要求1所述的通信系统，其中所述通信管理器还可操作为在用于所述发起用户和所述目的地用户的所述日历应用程序中把所述通信会话调度在下一个可用时间。
4.根据权利要求2所述的通信系统，其中所述多个在线源还包括电话应用程序，所述电话应用程序提供用于确定与所述发起用户和所述至少一个目的地用户相关联的一个或多个媒体类型的媒体状态的媒体状态信息；所述在线信息包括所述媒体状态信息；以及所述请求包括所述媒体类型中的一个所请求的媒体类型。
5.根据权利要求4所述的通信系统，其中所述下一个可用时间包括针对一个或多个所述媒体类型的一个或多个下一个可用时间。
6.根据权利要求1所述的通信系统，其中所述下一个可用时间包括以下时间中的一个或多个时间所述至少一个目的地用户可用的特定时间；所述至少一个目的地用户和所述发起用户都可用的特定时间；所述至少一个目的地用户可用的时间间隔；所述至少一个目的地用户和所述发起用户都可用的时间间隔；所述至少一个目的地用户可用的多个时间间隔；以及所述至少一个目的地用户和所述发起用户都可用的多个时间间隔。
7.一种用于确定发起用户与至少一个目的地用户之间的通信会话的可用性的方法，包括维护从多个在线源收集的关于多个在线实体的在线信息，所述多个在线实体包括所述发起用户和所述至少一个目的地用户，所述在线信息表明所述在线实体的当前可用性和未来可用性；接收来自所述发起用户的进行所述通信会话的请求；提取所述发起用户和所述至少一个目的地用户的所述在线信息；以及响应于所述发起用户和所述目的地用户中的一个或多个用户当前不可用，根据所述发起用户和所述至少一个目的地用户的所述在线信息来确定所述通信会话的下一个可用时间。
8.根据权利要求7所述的方法，其中所述维护还包括从日历应用程序中收集作为用于所述发起用户和所述至少一个目的地用户的调度信息的所述在线信息的步骤，并且所述方法还包括步骤在用于所述发起用户和所述目的地用户的所述日历应用程序中把所述通信会话调度在下一个可用时间。
9.根据权利要求8所述的方法，其中所述维护还包括步骤从电话应用程序中收集作为用于确定与所述发起用户和所述至少一个目的地用户相关联的一个或多个媒体类型的媒体状态的媒体状态信息的所述在线信息，并且其中所述下一个可用时间与一个或多个所述媒体类型相关联。
10.根据权利要求7所述的方法，还包括步骤在所述下一个可用时间在所述发起用户与所述至少一个目的地用户之间建立所述通信会话。
全文摘要
一种通信系统使用在线信息来确定发起用户与至少一个目的地用户之间的下一次通信会话的联合可用性。该通信系统包括在线服务器，其用于收集和存储表明发起用户和目的地用户的当前可用性和未来可用性的在线信息。当接收到来自发起用户的进行通信会话的请求，并且目的地用户当前无法进行通信会话时，根据发起用户和目的地用户的在线信息来确定通信会话的下一个可用时间。
文档编号H04L12/18GK1901513SQ200610072640
公开日2007年1月24日 申请日期2006年4月5日 优先权日2005年5月3日
发明者杰克·杰克纳 申请人:阿尔卡特公司