由呼叫发起系统控制的呼叫通知的制作方法

专利名称：由呼叫发起系统控制的呼叫通知的制作方法
技术领域：
本发明涉及一种呼叫通知系统和方法，更具体地，可应用于移动 电话、基于计算机的通信系统等中的呼叫通知定制。
背景技术：
各种不同的通信机制用于当今的生活。这里，将使用这些机制之 一进行的通信称为呼叫。所使用的机制包括标准电话呼叫移动和固定
线路、典型地使用基于因特网协议的语音VoIP的基于因特网或网络的 呼叫、视频电话呼叫、基于文字的聊天会话等，以及在可以由两个用 户控制单个机器上的应用程序时的应用程序共享会话，其中的用户之 一在远程机器上。使用MSN Messenger和其它类似封装，可以看到它
的工作情况。
所有机制均具有依次出现的至少三个阶段
启动阶段；
通信阶段；以及
终止阶段。
尽管启动和终止阶段将包括可能被认为是"通信"的数据传输，但 是在本文中所称的通信阶段意在指示一旦由一方发起呼叫并由另一方 接受呼叫的用户之间的(典型地，同步的)交互。
终止阶段包括资源恢复、记帐等。该阶段并不特别与本发明相关， 因而不再描述。
通过请求呼叫(以下称为"发起方")来触发启动阶段，并通过至 少另一方(以下称为"接收方")来接受该启动阶段。典型地， 一旦发 起方请求他或她的系统来启动呼叫，则经由被称为"握手"的数据通信 来建立与接收系统的连接。典型地，握手对于发起方和接收方来说是
透明的，并通过下层通信机制进行处理。在握手期间，发起方和接收 方的系统以及任何必要的中间系统交换启动通信阶段所必需的数据。 在面向连接的通信中的通信阶段内，握手阶段还可以包括诸如带宽之 类的必要设施与支持和路由数据的中间系统的协商。
当接收系统接收握手时，典型地，提供适合的通知以警告所请求 呼叫的接收方。接收方以适合于通信系统的方式(拾取话机、按下按 键、接受来自用户界面的提示等)来接受呼叫。典型地，通知的方式 取决于接收系统的性质和设施、以及已应用了的任何定制或个性化。 例如，接收方的系统可以选出要在接收呼叫时播放的特定铃音、要显 示的图标、要执行的动作(如移动电话中的振动)或其组合。
在PSTN或ISDN系统上作出的标准固定线路语音呼叫的启动阶 段包括:将通常被称为呼叫线路标识符CLI的数据的呼叫建立分组(但 是它并不包含比发起系统的电话号码更多的信息)发送给接收系统。 在传输CLI期间，将电话网络内的开关配置用于建立端到端连接。在 不同的系统上，存在呼叫建立数据格式的变体，但是它们在很大程度 上可以相互操作。
诸如基于GSM、 CDMA或UMTS系统之类的移动电话网络使用 与固定线路相同的CLI格式。然而，由于建立无线连接所需的技术， 移动电话倾向于比固定线路电话复杂得多。移动电话的使用之一是使 接收方能够将特定通知类型与一个或多个发起方的CLI相关联，例如， 从而以与另一发起方的呼叫不同的铃音来通知来自一个发起方的呼 叫。
VoIP系统以它们所实现的方式而具有很多变化，但是通常的方式 具有启动阶段，其中，发起和接收系统使用标准化的会话初始协议来 交换以由一组规则所定义的格式的少量数据。
IP技术允许基于文本的聊天、视频呼叫和共享图形环境的使用。 对于会话的发起，以与VoIP相同的方式来实现以上所有。

发明内容
根据本发明的一方面，提供了一种呼叫通知系统，设置用于响应
针对来自发起系统的呼叫的启动数据的接收，在接收系统处生成呼叫 通知，其中，通过发起系统来控制呼叫通知的至少多个方面。 发起和接收系统中的每个可以是以下之一
移动电话、运行在计算机上的应用程序、IP电话客户机、固定线 路电话、视频电话或者电话会议系统。
可以设置启动数据来触发接收系统，以便获得用于生成呼叫通知 的呼叫通知数据。
接收系统可以设置用于打开与发起系统的单独连接，以从发起系 统获得呼叫通知数据。
系统还可以包括设置用于存储与发起系统相关联的呼叫通知数据 的远程库，对接收系统和发起系统中的至少一个进行设置，以从用于 生成呼叫通知数据的远程库中获得与发起系统相关联的呼叫通知数 据。
远程库还可以包括用户界面，操作用于接受呼叫通知数据和/或来 自发起系统的用户的选择，并存储与发起系统相关联的呼叫通知数据 和/或选择。
发起系统可以设置用于针对每个所启动的呼叫，向远程库提供呼 叫通知数据。
启动数据可以包括以下的一个或多个呼叫通知数据、编码后的 呼叫通知数据、到呼叫通知数据的链接、或者在预定位置存储的唯一 标识符参考呼叫数据、图像联系数据、针对由接收系统所采取的动作 的指令、对于必须从中获得数据的源的参考、针对如何生成呼叫通知 的至少多个方面的指令、或者接收系统在输出之前需要编码、解码、 解译或再现的数据。
接收系统可以设置用于按需存储呼叫通知的至少多个方面。 根据本发明的另一方面，提供了一种生成呼叫通知的方法，包括: 在接收系统处接收针对来自发起系统的呼叫的启动数据；以及 在接收系统处生成呼叫通知，其中，通过发起系统预定呼叫通知 的至少多个方面。
该方法还可以包括在接收系统处获得呼叫通知数据，以用于生
成呼叫通知。
该方法还可以包括打开从接收系统至发起系统的单独连接，并 从发起系统中获得呼叫通知数据。
该方法还可以包括将呼叫通知数据存储在远程库中；以及
接收系统和发起系统中的至少一个从远程库中获得与发起系统相 关联的呼叫通知数据。
该方法还可以包括针对每个所启动的呼叫，向远程库提供来自 发起系统的呼叫通知数据。
该方法还可以包括在接收系统处按需存储呼叫通知的至少多个 方面。
本发明的实施例可以以软件、固件、硬件或其组合来实现。可以 预先安装实施例，和/或将实施例集成于系统中、或者可以用作可安装 的ad-onso
将本发明的所选实施例提供给通信通知系统，其中，与输入通信 相关联的通知和其它数据是启动该通信的一方所定制的。
使用本发明的实施例，可以向繁忙的会议期间接收呼叫的个人提 供告知该呼叫是否是紧急性质的附加装置(如，安静模式的紧急标志、 铃音或首选项)。
本发明的实施例优选允许用户在万维网、移动电话网络或任何其 它通信系统上经由用户界面来存储或更新简档数据。简档数据可以用 作呼叫通知数据，并且可以包括
铃音(或铃音的链接/定义)
与用户相关的图像
用户地址/联系数据
接收硬件所采取的行动(例如，可以指示PC来运行特定程序) 例如，呼叫通知数据可以
附加至握手或呼叫建立数据的头部或主体内、或者在握手或呼 叫建立数据的头部或主体内编码
可经由链接而在握手/呼叫建立数据的头部或主体可访问
与可兼容接收机知道如何用以获得呼叫通知数据的握手/呼叫
建立数据的头部或主体中的唯一ID相关联。
不考虑通信类型，接收系统处的用户应用程序(可以是软件、硬 件、固件或其某种组合)解译所提供的和/或所获得的呼叫通知数据以 显示或作用。此外，接收系统可以设置用于与发起系统或远程数据源 连接以获得其它数据，例如，获取/更新地址信息。
通知类型和内容与在接收系统处的任何预先配置的相独立，所以 发起方(发送方)可以真实地个性化他或她的通信。从中可以获得许
多益处，例如
公司可以强制使它们的商标/样式在接收到呼叫或电子邮件的 任何时候显示特定铃音和图像；
移动电话的用户可以使用自动更新的选项，利用丰富的数据来
更新他们的地址簿；
紧急标志可以使移动电话的接收方能够看到输入呼叫是否确实
需要应答、或者只是某人的聊天呼叫
移动电话系统上的通知数据可以显示呼叫意图主体的概要。 由于带宽的使用是有成本的，所以典型地，系统在启动阶段交换
的数据不会多于实际建立呼叫并启动通信阶段的数据。在发起方的标
识或小的仅文本字段中限制将在该阶段要发送的用户定义数据的可能性。
本发明的实施例允许发起方定义要提供给接收方的呼叫通知的属 性。在呼叫初始化期间，接收系统具有、或被触发以获得数据，并依 据该数据和由发送方定义的属性来生成通知。
可以定义的通知的各个方面的示例包括铃音、个人联系信息和拍 摄图像。
在通信阶段开始之前，本发明的实施例允许由发起者发送任何形 式的数据，并用作呼叫通知的一部分。
为了简化，本文中的大部分参照两方通信，但是将会理解，所描 述的原理和示例也可以用于多方通信。
在本发明的优选实施例中，在启动阶段获得呼叫通知数据，以定 义通知的多个方面来产生给接收方。在启动阶段由接收系统接收的数
据可以是使接收系统从发起系统或一些其它中介中获得呼叫通知数据 的触发。
可以在启动阶段内打开第二通信信道，以使接收系统访问呼叫通 知数据，启动阶段延长到时延通知，直至接收到呼叫通知数据。
这允许数据用户通知，例如以由发起方提供的音频警告来替换铃 音，或者显示发起方的图像、或者与呼叫特别相关的事物。
由于本发明的实施例能够在呼叫通知机制内执行重要通信，所以 在所选实施例中，可以在没有导致呼叫的通知的情况下，使用呼叫通 知进行通信。
在本发明的优选实施例中，广告产品(goods)或服务的方法包括: 响应于针对来自发起系统的呼叫的启动数据的接收，在接收系统
处生成呼叫通知，其中，呼叫通知的至少多个方面对产品或服务进行
了广告；以及
当在接收系统处接受了呼叫通知的情况下，将来自产品或服务的 代表的呼叫与接收系统连接。


现在将参照所附图示，对本发明的示例进行描述，其中
图1是结合了本发明实施例的通信系统的示意图2是示出了本发明实施例中的数据流的图示；
图3是结合了本发明实施例的通信系统的示意图4至12是示出了本发明实施例中的数据流的多个方面的图示；
以及
图13和14示出了使用本发明实施例的应用程序。
具体实施例方式
图1是结合了本发明实施例的通信系统的示意图。 通信系统包括由网络4所互连的发起系统3、接收系统2。 典型地，发起系统3通过向网络4发布与接收系统2连接的请求 来触发呼叫的启动阶段。
网络基于由发起系统3所提供的标识信息来建立接收系统2上的 标识数据。标识数据可以包括位置、标识和/或接收系统2的其它必要 信息。在移动电话的情况下，该标识数据包括MSIDN，通常被称为电 话号码。对于瞬时消息收发或其它服务，这可以是更加一般的IP地址 和/或"用户id"。
一旦网络4建立了用于接收系统2的标识数据，则它将会话启动 数据发送给接收系统2。会话启动数据包括通信会话的技术细节，如 视频或音频呼叫的编解码信息、或者文本通信的代码页。
在启动阶段的某点处(或在该阶段完成处)，在接收系统2生成 了呼叫通知。以下将对本发明的各种不同的实施例进行更加详细地讨 论，但是公共元素在于，发起者可以控制在接收系统2处生成的至少 呼叫通知的属性。
在所选实施例中，触发接收系统以获得呼叫通知数据用于生成呼 叫通知。可选地或此外，可以直接或间接地向接收系统2提供呼叫通 知数据。在一个实施例中，可以将呼叫通知数据附加在呼叫线路标识 符上、或者在呼叫线路标识符内进行编码。
将会理解，与诸如以上描述的那些现有系统的不同之处在于，发 起发不控制在接收系统2处生成的呼叫通知的属性，这种属性由接收 方控制。
通常，直至接收系统2的用户同意接受呼叫，才会认为成功地完 成了启动阶段，在此点处，开始通信阶段。然而，在本发明的所选实 施例中，可以认为在较早的阶段内完成了启动阶段。在这种实施例中， 在启动阶段和通信阶段之间引入通知阶段，从而一旦完成了启动阶段， 便开始了通知阶段，以及通信阶段仅在完成了通知阶段并接受了呼叫 之后才开始。
可以使用已经在接收系统2中存在的资源来生成呼叫通知(如， 使用接收系统2上的铃音发生器来选择特定的现有铃音或播放定制铃 音)。
在本发明的实施例中，启动系统3直接或间接地向接收系统2引 入数据，该数据用于在接收系统2上生成定制呼叫通知，可以是特定 铃音、视频图像或短消息的显示。
将会理解，不需要发起系统和接收系统是相同类型的。只要所使 用的下层通信机制与这两个系统兼容，本发明的实施例便是可用的。 例如，移动电话将能够触发固定线路电话上发起方控制的呼叫通知。 移动电话也能够触发计算机上的VoIP客户机上的发起方控制的呼叫 通知。在这种情况下，可以将移动电话呼叫看作是标准电话呼叫，并
由移动电话网络与VoIP网络之间的VoIP网关来处理。可选地，如果 该电话本来就可以支持VoIP,则将不会需要网关。如果通过网关传递
呼叫，则优选地，网关包括使启动数据内发起方控制的呼叫通知数据 能够被解译为接收系统所需要的任何格式的设施。
呼叫通知数据不需要是自持的(或者准备输出的)，并且可以包
括
对于必须从中获得数据的其它源的参考；
针对如何(使用接收系统上的资源或从别处获得的资源)产生呼
叫通知的指令；以及
在输出之前需要由接收系统编码、再现等的数据。 在所描述实施例的优选版本中，可以给予发起系统以下选项在
没有前进至通信阶段的情况下，使用这里所描述的机制之一来发送通
信通知。
在其它实施例中，呼叫通知最初可以不与单个发起方相关联，而 是如果接收系统处的用户接受了该呼叫通知，可以与号码或者与之相 连的呼叫中心相关联。以这种方式，可以发出查询用户兴趣的丰富的 广告呼叫通知。只有在用户接受了呼叫通知的时候，呼叫才会与发起 系统连接。这样，由于大多数标准呼叫和发起方可以潜在地在一次査 询多个接收方，而仅与积极接受呼叫通知的那些连接，所以不需要发 起方:接收方是1:1的映射。
图2是示出了本发明实施例中的数据流的图示。
一旦网络4建立了接收系统2的标识数据，便由发起系统3将启 动请求10发送至接收系统2。
在接收到启动请求10时，在接收系统2处执行检査，以在步骤
20中确定是否支持并启用了发起方生成的呼叫通知。
可以通过针对列表或数据库来査找发起方或会话的标识，来获得 对呼叫支持发起方生成的呼叫通知的检测，其中，列表或数据库可以 存储在接收系统或任何远程设备上。
如果支持并启用了发起方生成的呼叫通知，则在步骤30中，接 收系统2使用启动请求来获得生成呼叫通知所需的数据。
一旦在步骤40中接收系统2获得了数据，则在步骤50中，接收 系统2生成并输出呼叫通知。
当接收方2接受了呼叫时，呼叫通知结束，以及通信阶段60开始。
作为进行自我检查以确定是否支持发起方生成的呼叫通知的接 收系统2的可选项，作为替代，接收系统2可以利用在启动请求10 传递至接收系统2之前检査的网络4内的实体来登记接受。如果该实 体没有对于所识别的接收系统2的接受登记，则作为替代，将标准启 动请求传输至接收系统2，这导致触发了接收系统的标准呼叫通知而 不是发起方生成的呼叫通知。
在一个实施例中，如图3所示，可以设置服务器1形式的远程库 来存储用于发起系统3的数据、或可选地，通知属性。在这种实施例 中，可以在步骤40中触发接收系统2，以与服务器通信来获得发起系 统3的数据或任何属性设置。可以从启动请求中的CLI或类似标识符 中获得发起系统3的标识。服务器1的标识符、IP或网络地址还可以 包括在启动请求中。
服务器1优选包括使发起系统3的用户能够登记他或她自身、存 储或选择要用于呼叫通知的数据、并设置任何通知属性的界面。
启动请求可以包含特定信息，该特定信息要由发起系统用以标识 支持发起者生成的呼叫通知的呼叫。对于常规电话，这可以扩展到呼 叫方线路ID，对于SIP，它可以是主题线路中的特定代码，类似的方 式用于其它会话启动机制。
服务器l可以是网络代理或路由器的一部分。作为在呼叫之前上 载或选择数据的替代或除此之外，发起系统3可以在启动阶段之前、
或在启动阶段期间，将数据上载或选择给服务器1，或者向服务器1 提供要用户呼叫通知的数据的指示。
在可选实施例中，接收系统2可以从发起系统3中直接获得数据 和可选的任何通知属性。这可以通过对等连接或任何其它形式的连接 来实现。
本发明的实施例可以处理以不同方式和/或在不同时间获得呼叫 通知数据的接收系统。以下讨论各种示例性实施例，但是其它的变体 也是可能的。
在图4中的一个实施例中，接收系统在通信阶段开始120之前的 标准启动阶段110期间，接收呼叫通知数据可用的通知并对它进行访 问。扩展启动阶段110，以确保直至接收到呼叫通知数据才开始通信 阶段120，以及在相关的情况下，由接收系统2输出并处理。
发起系统3具有接收系统2可通过对等通信进行访问的呼叫通知 数据的通知包含在启动握手100中。在步骤105处结束启动握手之后、 但在通信阶段120开始之前，在步骤130中将呼叫通知数据从发起系 统3发送至接收系统2。这被称为"扩展启动阶段"140，以及它与通 信阶段120的不同之处在于，在该阶段内，不允许用户之间的全同步 通信，仅允许传递用于呼叫通知的呼叫通知数据。
作为"扩展启动阶段"的可选项，在图5的实施例中，在两个设 备之间建立独立的通信会话200。接收系统2在步骤205中请求传递 呼叫通知数据，然后由发起系统3在步骤210中传输该数据。仅在一 旦完成了以上过程并将呼叫通知呈现给用户，系统才会认为完成了启 动握手100，并允许开始通信阶段120。
在图6的实施例中，发起系统3向作为单独的通信会话250 —部 分的服务器l通知呼叫通知数据可用。然后，通过发起系统3来启动 通常的启动握手100，以及接收系统2创建另一单独的通信会话260 以检查服务器1是否呼叫通知数据可用。在确定了呼叫通知数据可用 时，接收系统2在步骤105中关闭启动握手，并打开与发起系统3的 通信会话270，但是不允许开始通信阶段。在该阶段280期间，将呼
叫通知数据从发起系统3传递至接收系统2。该阶段280仅在接收机 接受了呼叫时结束，此时，开始通信阶段120。
如图7的实施例中所示，接收系统2可以使用当前会话来请求来 自发起系统3的呼叫通知数据而不是开始新的会话。
在图8示出的实施例中， 一旦启动握手100从发起系统3传递给 了接收系统2，发起系统3便打开了单独的通信会话300，并在步骤 310中登记呼叫通知数据在单独的服务器1上可用。接收系统2类似 地在接收到握手100时打开单独的通信会话，并在步骤320中检查呼 叫通知数据是否可用。在确定了呼叫通知数据可用时，接收系统2关 闭启动握手100并打开与启动系统3的通信会话330，但是不允许开 始通信阶段。然后，发生扩展的启动阶段340，其中，将呼叫通知数 据从发起系统3传递至接收系统2。该阶段340仅在接收方接受了呼 叫时结束，此时开始通信阶段120。
在图9中示出的另一实施例中， 一旦启动握手100从发起系统3 传递至接收系统2，便开始启动阶段110。发起系统3打开单独的通信 会话400并在单独的服务器1上登记呼叫通知数据可用。接收系统2 类似地在接收到握手100时打开单独的通信会话，并在步骤410中检 查呼叫通知数据是否可用。在确定了呼叫通知数据可用时，接收系统 2在步骤420中使用当前的会话来请求来自发起系统3的呼叫通知数 据。在步骤430中，发起系统3将该数据传输至接收系统2，接收系 统2输出呼叫通知。 一旦接收方2接受了该呼叫，便完成了握手IOO， 并开始通信阶段120。
在图10的实施例中， 一旦将启动握手100从发起系统3传递至 接收系统2，便开始启动阶段110。发起系统3在步骤510中打开单独 的通信会话400，并将呼叫通知数据上载给单独的服务器1。接收系统 2类似地打开单独的通信会话，并在步骤520中请求来自服务器1的 适合的呼叫通知数据。如果呼叫通知数据可用，则在步骤530中将该 呼叫通知数据从服务器下载至接收系统2，接收系统2然后输出呼叫 通知。 一旦接收机接受了该呼叫，便完成了握手100，并开始通信阶 段120。
图11示出了图10中示出的实施例的可选项，其中，在会话启动
握手100之前出现数据的上载510。
在一个实施例中，可选地，可以分别在启动握手100之前和之后， 单独地执行给予服务器的出现呼叫通知数据和数据上载至服务器的通 知，这在图12中示出。
在移动电话实施方式的情况下，在呼叫建立期间，发起的移动电 话将发起方控制的呼叫通知传输至接收移动电话。接收移动电话对该 触发进行处理，并获得呼叫通知数据，以在决定是否接受该呼叫之前 生成输出给接收方用户的呼叫通知。
呼叫通知数据可以包括多个不同的数据类型，包括发起方定义的 铃音、发起方记录的铃音、优先级标记、文本消息、照片等。典型地， 通过发起方选择、创建或提供呼叫通知数据，并在接收方决定是否接 受该呼叫之前，使得该呼叫通知数据可用于接收方移动电话的下载或 后续使用。
在发起方移动电话处，发起用户能够定义要传输的信息、接收方 的标识，并利用网络载体来启动呼叫。
发起用户优选能够在电话默认参数内设置附加的优先级。当启用 了该优先级时，从电话中作出的所有呼叫将预定的发起方控制的呼叫 通知与呼叫链接，并在接收到呼叫时在兼容的接收方移动电话处产生 发起方生成的呼叫通知。默认的发起方控制的呼叫通知可能包括诸如 照片或铃音之类的用户指定项，而不是诸如消息或优先级标记之类的 呼叫指定项。
可选地或此外，用户优选可以在做出呼叫之前指定呼叫指定发起 方控制的呼叫通知与呼叫链接。这可以通过选择交替的呼叫按钮或按 键的组合来实现。在每种情况下，用户将必须在做出呼叫之前选择相 关的呼叫通知内容。
在呼叫指定信息和用户指定信息的情况下， 一旦发起方控制的呼 叫通知与呼叫进行了链接而做出呼叫的处理与现有的呼叫功能相同。 一旦拨打了该呼叫，则发起方听到铃音或回铃音(如果配置了)，直至 接收方应答该呼叫。可选地，发起方可以具有关于接收方是否接收了
附加信息的一些指令。
可以从呼叫通知的预定列表、或者在优先级、字符图示
(emoticons)等的情况下在移动电话上预先安装、或者更可能位于与 移动电话分离的服务器上的用于铃音、照片等的呼叫通知类型中选择 发起方控制的呼叫通知。
发起方可以选择性地生成个人信息，该个人信息可以在接收方移 动电话生成呼叫通知之前被传输至接收方。这可以包括短文本消息(虽 然不同于SMS消息)照片、铃音、视频或甚至自我录制的声音或视频。
优选地，在仅有有限带宽对于发起或接收系统可用的情况下，发 起系统或网络可以按比例减少要由接收系统下载以用户生成呼叫通知 的数据。这可以是数据高速缓存的本地复制、分辨率下降的照片回视 频、降采样后的音频等的形式。
优选地，如果选择了对于接收方禁止或保留他们的电话号码，则 发起方应当不可以利用发起方控制的呼叫通知来发送呼叫。
优选地，接收方可以配置他们的移动电话接受或拒绝发起方控制 的呼叫通知。由于大多数移动电话允许多个简档，所以优选地，使简 档意识到发起方控制的呼叫通知，并包括允许特定发起方控制的呼叫 通知超越简档设置的设置。例如，如果发起方控制的呼叫通知包含了 "高优先级"标签，则可以在"安静的(quiet)"简档期间播放标准 铃音。
在接收到定义了发起方控制的呼叫通知的呼叫建立握手时，接收 方移动电话检查当前配置以确定是否可以将发起方控制的呼叫通知再 现给用户。如果可以，则移动电话获得必要的通知数据，并将该呼叫 通知输出给用户。接收方移动电话还可以将通知发送给可以成功地接 受并输出呼叫通知的网络载体。在声音的情况下，这应当替换标准铃
音
一旦用户接受或拒绝了呼叫，便不再输出呼叫通知。如果呼叫通 知包括诸如铃音或视频之类的流数据，则不将剩余信息传输至接收方。
优选地，接收方移动电话包括使接收方能够节约(save)呼叫通 知的多个方面的选项。可以将诸如优先级标志、短文本消息和照片之类的呼叫通知的简单方面存储在接收方移动电话的存储器中，并在呼 叫历史上显示。可以针对接收方的请求(可能地，针对服务提供商或 网络载体的费用支付)来存储较大形式的数据。可以改变移动电话， 以使呼叫通知数据的所有形式本地地存储并在呼叫历史中可访问。
优选地，已经处理了呼叫的接收方移动电话不应具有仅可能多的 发起方控制的呼叫通知。就呼叫等待而言，在技术上可能的是网络至 网络的改变。优选地，至少优先级标记、短消息和照片被提供给处理 现有呼叫的接收方移动电话。
为了避免有人滥用骚扰呼叫的呼叫通知(例如，发送不适合的或 威胁性的附加信息)，用户应具有将特定发起方列入黑名单的能力，从 而决不会再接收来自该发起方的附加信息。
将会理解，存在可以使用本发明实施例的许多潜在应用。 一个潜在的应用程序是本发明的实施例在广告中的使用。呼叫通 知可以包括广告或意图。为了进一步利用人类操作者或自动系统来接 受该意图或讨论广告产品或服务，接收系统的用户仅需要接受该呼叫。 这将会将他或她与相关的人或系统连接。
如果用户不感兴趣，则他或她仅需要忽略该通知。 例如，用户可以选择接受提供用于出售的移动电话铃音或墙纸的 通知。该通知可以包括供用户预览的一个或多个铃音或墙纸的样本(例 如，这些可以特别再现或作为幻灯片等)。如果用户想要购买特定的铃 音或墙纸，则他或她应答该呼叫，并使它接通至人类或自动销售代表 以处理该购买。
以类似的方式，降采样或缩短版本的音乐轨道、视频等还可以作 为允许用户预览内容的通知发送，并通过接受该呼叫进行购买。
在图13中示出了本发明的一个实施例的应用程序。在所示出的 应用程序中，呼叫中心环境使用本发明实施例用于电话销售。
呼叫中心1000包括经由数据网络1040相互链接的多个操作者终 端1010、中心管理者终端1020和通知服务器1030。通知服务器1030 设置用于访问数据库1050，该数据库1050容纳了选择用来接收电话 销售意图的接收系统2上的数据。
中心管理者终端1020设置用于与操作者终端1010和通知服务器 1030进行通信以获得呼叫中心1000上的利用数据。经由中心管理者 终端1020，可以触发通知服务器1030来向预定个数的接收系统2发 出呼叫通知。每个呼叫通知包括电话销售意图的详情。 一旦在接收系 统1100处接收，便以上述讨论的方式之一 (例如，图形、视频或声音 文件之一或其组合)将通知输出给用户。如果接收系统2的用户应当 接受该呼叫，则设置通知服务器以将呼叫与可用的操作者终端1010 连接。
以这种方式，可以通过呼叫中心管理者终端来管理呼叫中心容 量，以及可以使所发布的通知的个数与操作中的操作者终端1010的个 数平衡。与直接邮件的交易和基于SMS的交易相反，可以控制通知， 从而
在呼叫中心的工作小时期间，将仅以接受意图(通知)的机会来 呈现给用户；
体积受限意图(诸如飞机座位、假期等)可以与适合个数的接收 方匹配，使得该意图不是认购超额的；以及
传统的商务可以操作上述系统的縮减版本，以基于立即可用性 (如餐厅中的桌位)提供"及时"意图。
可选地，可以提供给用户登记仅可以接受/拒绝特定类型广告的优 先级简档。系统还可以或可选地被提供监视所接受广告的类型以及相 应地调整后续广告。
可以预期其它事件驱动的应用。
例如，旅馆可以将它的警告呼叫设施与它的房间服务设施链接。 在该实例中，可以在前一晚预先设置通知，并用作警告呼叫。如果用 户决定起床，然后他或她可以应答该呼叫通知，并与房间服务连接以 定制他或她的早餐。可选地，如果他或她决定睡懒觉，则可以设置系 统在预定时间段之后发布另一通知。以这种方式，用户可以决定何时 起床然而仍接受温热/新鲜的早餐。
在类似的场景中，对于经常往返于两地的人等，可以通过旅行信 息公司向定制接收系统2提供警告呼叫。如果接受警告呼叫，则可以
以预定的费率来提供与用户位置或预设简档相匹配的旅行信息。
在图14中示出了另一示例。在本示例中，将搜索设施提供给接 收系统2的用户。
经由接收系统2上的用户界面，用户输入经由遥控搜索引擎1200 处理的适当的关键词。搜索引擎1200搜索与关键词相匹配的定制提供 者的数据库。将与关键词相匹配的提供者的广告组合为随后发送给接 收系统2的通知。在接收到通知时，接收系统2以用户可以经由接收 系统2上的适合按键1220进行导航的广告的幻灯片1210形式来输出 通知。在选择广告时，用户按下接收系统2上的呼叫按键，这触发了 呼叫(应当可用)或者与各个提供者1230的回呼请求。
还可以基于接收系统2的检测位置来预期基于位置的应用程序。 可以经由GPS类系统、基于呼叫的位置检测或其它这种技术来确定该 检测。例如，约会代理可以使用本发明的实施例来提供基于定购的服 务。在这种应用中，与用户预先同意的简档匹配的订户无论何时进入 用户移动电话的预定范围，都可以将与订户匹配的包含细节、照片等 的通知发送给用户的移动电话。如果用户基于在通知中所发送的信息 而应该对此感兴趣，则他或她可以选择接收该呼叫并与匹配订户连接。 在本实例中应注意，用户无法决定发出呼叫通知。依据系统配置，在 第三方发起两个其它方之间的呼叫通知的情况下，对于这两方来说， 接收与对方相关的呼叫通知并通过这两方接受使呼叫进入通信阶段的 预定条件是适合的。
尤其在基于销售的呼叫通知的情况下(尽管还可以应用其它呼叫 通知)，对于通知来说适合的是，如果不立即接受通知，则在接收系统 2上坚持预定时间量。坚持呼叫通知可以包括通知自身不同的多个预 编程阶段。
例如，在接收时，呼叫通知可以调用音频提示和图像或视频以由 接收系统2来输出(假设接收系统2在适合的模式中这样做，并且在 接收系统处当前不禁止这种通知类型)。如果在预定时间段内不接受通 知(例如10秒)，则可以进入第二阶段，其中，可以输出图像或视频 而没有任何声音。如果在另一预定时间段内不接受通知，则可以从接
收系统的屏幕中去除该通知，并记录在最近的通知列表中。在预定时
间之后，通知会到期，以及从接收系统2中删除该通知，或者以不再
可能接受呼叫的方式来进行配置。
优选地，每个接收系统2包括启用要拒绝的接收通知的按键，在 这种情况下，停止通知并从接收系统2中删除该通知。
可选地，可以设置通知，以控制接收系统2来防止接收系统2处 的用户接受呼叫，直至已经在接收系统上输出了整个通知或至少预定 部分。以这种方式，可以防止用户跳过重要信息，如发起方可以合法 地通知接收方的项和条件。如上所讨论，可以在任何时候拒绝通知。
可以选择性地将反馈数据提供给发起系统3，以使发起方能够监 视通知的状态。例如，可以使用不同的铃音以指示准备好了通知并传 输至接收系统2的情况。标准的网络铃音将典型地用于指示发起方在 接收系统2处输出通知。
出于容量的原因，尽可能在通知的初始阶段内保持呼叫通知所建 立的通信信道的幵放。如果在该时间段内不被接受，则该通信信道可 能再循环。在这种情况下，如果在不再有关联通信信道的情况下接受 通知，则接收系统2可以配置用于呼叫发起系统3或可选地请求回呼。
在另一实施例中，将RFID标签结合于接收系统2中。当标签在 RFID标签读取器的范围内传递时，可以向接收系统启动呼叫通知。 RFID标签可以包括标识符，用于由接收系统或甚至接收方的移动电 话(优选地，编码以避免滥用)来使RFID标签读取器能够标识接收 系统2。这种设置的一个应用将会是嵌入广告，或者将标签读取器与 广告相关联。以这种方式，可以向检测到在广告之前花费了预定时间 量的用户发送具有广告版本的呼叫通知，该广告版本可以在呼叫之前 以获得更多的信息、订票等。可选地，通知可以包括与无论什么所广 告的相关联的意图。
可以预期各种收费的结构。例如，可以向选择用于接收基于广告 的通知的用户提供免费呼叫。可选地，可以由于接收广告呼叫通知而 付费给用户或者奖励用户。在另一变体中，如果发起方/接收方允许在 通知之前或之后显示广告、或者允许将标题包括在通知中，则可以提
供免费或降低费用的通知能力。对于诸如呼叫中心之类的商务用户， 可以以对于后续呼叫的优选速率来设置通知的批速率。依据应用，可 以或不可以向接收方收费以获得通知之后的呼叫。在私下发起呼叫通 知并广告呼叫的情况中，通常不会对接收方收费。在经由呼叫提供的 信息产品和服务的情况下，通常会对接收方收费。
还可以预想商业内容。例如，可以利用呼叫广告客户接受所提供 的无论什么产品或服务的选项，向订户提供承载了每日的旅行或天气 信息的广告。在这种情况下，由于广告收入，将会减少或放弃对接收 方的收费。
优选地，在用于通知之前，载体必须针对发起方所生成的或所提 交的通知数据来执行特定活动，以确保在技术上的有效，并且不包含 有害的软件，如病毒。
在呼叫启动阶段内，载体接收用于呼叫接收方的标识符、以及发 起方控制的呼叫通知的指示或链接。载体确定在本地网络上存在接收 系统，并检查以确保登记了接收方以使用服务。
倘若登记了接收方以使用服务，则载体将呼叫路由至网络上适合
的被叫ID，并向接收方提供呼ID和发起方控制的呼叫通知的指示或
链接。如果接收方接受了该呼叫，则载体打开发起方与接收方之间的呼叫。
在基于外部(非本地)网络的接收方的情况下， 一旦载体确定了 接收方在外部网络上存在，则可以检查以确保外部网络支持发起方控 制的呼叫通知。依据载体之间的实施方式和协议，任何必要的通知信 息都可以从发起方网络上的服务器或资源中传递至外部网络的服务器 或资源，以简化接收方的访问。
可以做出控制，以在发起方或接收方在漫游网络或国外时防止发 起方控制的呼叫通知。发起方控制的呼叫通知可以吸引除了对发起方 或接收方或二者呼叫的收费之外的收费。在移动电话的情况下，可以 按照与包括多个免费发起方控制的呼叫通知的服务契约当前提供了免
费的呼叫分钟或SMS消息相同的方式，来预想这些契约。收费可以依 据呼叫通知本身(例如传输至接收方的呼叫通知数据量)。还可以针对
发起方控制的呼叫通知、而不考虑它所包含的呼叫通知数据量来进行 收费，以防止在接收方没有应答呼叫的情况下由发起方控制的呼叫通 知的免费通信使用。可以通过现有的网络载体记帐系统、主要可能通
过产生对于后付费顾客的附加CDR呼叫数据记录来承担记帐功能。
利用针对外部或本地网络、以及针对用于接收附加信息的用户提 供的完全检查，以与通常的呼叫相同的方式处理转向的呼叫。许多移
动网络中的实际考虑可以表示必须针对转向的呼叫来禁用服务，但 是这将从网络至网络发生改变。
尽管标准不断地合并、以及系统扩展以便能够支持不同的数据格 式，但是很可能会需要改变一些数据类型的格式以适于接收系统的输 出。例如，可以需要将音乐、照片或视频解码格式改变为适于接收系 统的格式(和/或大小)。本发明的实施例包括代码转换系统，通过该 系统，在将呼叫通知数据传输至接收方之前代理呼叫通知数据。
以上描述的各种实施例公开了可以依据所期望的实施方式以各 种方式可选地组合的特征。尽管所描述的特征是模块化的，但是基于 特征的不同组合的其它实施例也是可能的。
所描述的特征中没有一个是相互独占的，以及可以采用任何组合 来实现以上所描述的功能。
权利要求
1、一种呼叫通知系统，设置用于响应针对来自发起系统的呼叫的启动数据的接收，在接收系统处生成呼叫通知，其中，通过发起系统来控制呼叫通知的至少多个方面。
2、 如权利要求l所述的呼叫通知系统，其中，发起系统是以下之移动电话、运行在计算机上的应用程序、IP电话客户机、固定线 路电话、视频电话或者电话会议系统。
3、 如权利要求l所述的呼叫通知系统，其中，接收系统是以下之移动电话、运行在计算机上的应用程序、IP电话客户机、固定线 路电话、视频电话或者电话会议系统。
4、 如前述权利要求之一所述的呼叫通知系统，其中，设置启动数 据来触发接收系统，以便获得用于生成呼叫通知的呼叫通知数据。
5、 如权利要求4所述的呼叫通知系统，其中，接收系统设置用于 打开与发起系统的单独连接，以从发起系统获得呼叫通知数据。
6、 如前述权利要求之一所述的呼叫通知系统，还包括设置用于存 储与发起系统相关联的呼叫通知数据的远程库，对接收系统和发起系 统中的至少一个进行设置，以从用于生成呼叫通知数据的远程库中获 得与发起系统相关联的呼叫通知数据。
7、 如权利要求6所述的呼叫通知系统，其中，所述远程库还包括 用户界面，操作用于接受呼叫通知数据和/或来自发起系统的用户的选 择，并存储与发起系统相关联的呼叫通知数据和/或选择。
8、 如权利要求6或7所述的呼叫通知系统，其中，所述发起系统设 置用于针对每个所启动的呼叫，向远程库提供呼叫通知数据。
9、 如权利要求l所述的呼叫通知系统，其中，启动数据包括以下 的一个或多个呼叫通知数据、编码后的呼叫通知数据、到呼叫通知 数据的链接、或者在预定位置存储的唯一标识符参考呼叫数据，接收 系统设置用于依据呼叫通知数据来生成呼叫通知。
10、 如权利要求2至9之一所述的呼叫通知系统，其中，呼叫通知 数据包括以下的一个或多个-铃音、到呼叫通知数据的链接、要在接收系统处生成的呼叫通知 的定义、图像联系数据、针对由接收系统所采取的行动的指令、对于 必须从中获得数据的源的参考、针对如何生成呼叫通知的至少多个方 面的指令、或者接收系统在输出之前需要编码、解码、解译或再现的 数据。
11、 如前述权利要求之一所述的呼叫通知系统，其中，所述接收 系统设置用于按需存储呼叫通知的至少多个方面。
12、 一种生成呼叫通知的方法，包括在接收系统处接收针对来自发起系统的呼叫的启动数据；以及 在接收系统处生成呼叫通知，其中，通过发起系统预定呼叫通知 的至少多个方面。
13、 如权利要求12所述的方法，还包括在接收系统处获得呼叫通知数据，以用于生成呼叫通知。
14、 如权利要求13所述的方法，还包括打开从接收系统至发起系统的单独连接，并从发起系统中获得呼叫通知数据。
15、 如权利要求13或14所述的方法，还包括 将呼叫通知数据存储在远程库中；以及接收系统和发起系统中的至少一个从远程库中获得与发起系统相 关联的呼叫通知数据。
16、 如权利要求15所述的方法，还包括针对每个所启动的呼叫，向远程库提供来自发起系统的呼叫通知数据。
17、 如权利要求13至16之一所述的方法，其中，呼叫通知数据包 括以下的一个或多个-铃音、到呼叫通知数据的链接、要在接收系统处生成的呼叫通知 的定义、图像联系数据、针对由接收系统所采取的行动的指令、对于 必须从中获得数据的源的参考、针对如何生成呼叫通知的至少多个方 面的指令、或者接收系统在输出之前需要编码、解码、解译或再现的 数据。
18、 如权利要求12至17之一所述的方法，还包括在接收系统处按 需存储呼叫通知的至少多个方面。
19、 一种包括计算机程序代码装置的计算机程序，用于在所述程 序在计算机上运行时执行权利要求12至18之一所述的所有步骤。
20、 如权利要求19所述的计算机程序，嵌入在计算机可读介质中。
全文摘要
公开了呼叫通知系统、方法、计算机程序和广告方法。响应针对来自发起系统(3)的呼叫的启动数据的接收，在接收系统(2)处生成呼叫通知。通过发起系统(3)来控制呼叫通知的至少多个方面。
文档编号H04M3/42GK101116318SQ200680004274
公开日2008年1月30日 申请日期2006年2月8日 优先权日2005年2月8日
发明者乔纳森·埃利斯, 托比·拉塞尔·康斯坦丁, 汤姆·韦斯, 西蒙·沃特伏, 马修·卡拉斯 申请人:皮斯卡特服务有限责任公司