[发明专利]在电话呼叫的回铃期间宣告在场信息

说明书

背景

当作出电话呼叫时，通常向呼叫者提供间歇性铃声，从而以信号告知呼叫还没有被连接到被呼叫方或被呼叫者。当被呼叫者接起呼叫时，间歇性铃声会停止，且被呼叫者被连接到呼叫者。从作出呼叫到呼叫被接起的时间段通常被称为“呼叫回铃”。间歇性铃声被称为“回铃音”。

近来各个电话服务供应商开始允许其客户挑选客户希望其呼叫者听到的回铃音。一个电话服务供应商允许其客户从上百个音乐剪辑中选择自定义回铃音。例如，一客户可以选择莫扎特交响乐的剪辑，而另一客户可以选择摇滚乐组的剪辑。

虽然作出电话呼叫是实时对话的常见形式，但实时对话的另一常见形式是即时消息通信。即时消息通信服务允许端点处的参与者发送消息，并且使得消息在一到两秒钟之内被对话中的其他参与者接收。接收参与者于是可以用类似的方式向其他参与者发送响应消息。为了有效，实时对话依赖于参与者能很快地知道、查看和响应接收到的消息。这种快速响应和传统的电子邮件系统形成对比，在后者中，电子邮件消息的接收者在他们方便时对消息作出响应。

当发起的参与者希望开始实时对话时，该参与者一般希望知道预期的参与者是否有空来实时地响应消息。如果否，那么经由传统的电子邮件、语音邮件或某种其他机制的通信是更适当的。例如，如果预期参与者的计算机当前被关闭，那么实时对话是不可能的。此外，如果其计算机当前被打开，但是预期参与者离开了其计算机，那么实时对话也是不可能的。发起参与者希望知道预期参与者的可用性，以便作出关于通信形式的适当决定。

诸如计算机系统(即端点)等实体或与该计算机系统相关联的用户的可用性状态被称为“在场信息”。在场信息标识用户的当前“在场状态”。用户使其在场信息可用，这样其他用户可以决定如何最好地与他们通信。例如，在场信息可以指示用户是登陆(“在线”)到实时消息通信服务器还是注销(“离线”)。在线信息也可提供有关用户的可用性的更详细信息。例如，即使用户在线，用户也可能在会议中离开其计算机。在这种情况下，在场状态会指示“在线”且“在会议中”。

在即时消息通信上下文中，发布用户(“发布者”)可向在场服务器提供其在场信息，在场服务器接着将在场信息提供给签订用户(“订户”)。因此，在场服务器可使用订户/发布者模型来提供关于在场服务器的用户的在场信息。只要用户的在场信息发生改变，就通过该用户的计算机系统将该改变通知给在场服务器，并接着将该改变通知给签订用户。签订用户于是可以基于预期参与者的在场信息来决定是否要启动即时消息通信对话。例如，如果在场信息指示发布用户当前处于会议电话呼叫中，那么签订用户可决定发送即时消息给发布用户，而非作出电话呼叫。然而如果签订用户需要呼叫并与发布用户谈话，那么签订用户需要监视发布用户的在场信息，以便知道何时可以作出呼叫。当签订用户注意到发布用户的在场信息指示电话会议已结束时，签订用户于是可以作出电话呼叫。

概述

提供了一种输出基于被呼叫者的在场信息的呼叫宣告作为回铃音的方法和系统。向该宣告系统提供用户的在场信息。当电话系统接收到来自呼叫者的呼入的指示时，电话系统标识被呼叫者。在标识了被呼叫者之后，宣告系统检索被呼叫者的在场信息，并基于该在场信息生成宣告。由此，宣告系统可以提供基于被呼叫者的在场信息的宣告作为回铃音。

提供本概述以便用简化的形式引入一些概念，这些概念会在以下详细描述中做进一步描述。本概述并非旨在标识所要求保护的主题的关键特征或必要特征，也并非旨在用于协助确定所要求保护的主题的范围。

附图简述

图1是示出在一个实施例中电话系统使用在场信息来定制回铃音的框图。

图2是示出一个实施例中的宣告系统的组件的框图。

图3是示出一个实施例中的签订组件的处理的流程图。

图4是示出一个实施例中的接收在场信息组件的处理的流程图。

图5是示出一个实施例中的宣告系统的接收呼入事件组件的处理的流程图。

图6是示出一个实施例中的宣告系统的开始宣告组件的处理的流程图。

图7是示出一个实施例中的宣告系统的接收呼叫者输入事件组件的处理的流程图。

图8是示出一个实施例中的宣告系统的接收结束宣告事件组件的处理的流程图。

详细描述