CN106464752B - 关于呼叫者的附加信息 - Google Patents

Abstract

为了提供关于呼叫者的信息给被叫者，将对于包含与呼叫者有关的实时或近实时信息或者通过使用所述实时或近实时信息导出的信息的资源的引用、或者实时或近实时信息、或者通过使用实时或近实时信息导出的信息与连接建立请求一起传输，以及，在建立所请求的连接前向被叫者显示资源中的信息或所接收的信息，使得被叫者可决定是否应答呼叫。

Description

关于呼叫者的附加信息

技术领域

本发明涉及从第一方到一个或多个第二方的连接建立发起，特别是涉及向一个或多个第二方中的至少一个传送关于第一方的信息。

背景技术

一般地，电话或允许它的用户在与另一用户的连接上通信(例如进行对话)的相应用户装置被配置为在用户决定是否接受连接建立之前向它的用户提供关于连接建立的发起者的信息，该发起者通常被称为呼叫方。通常地，在响铃信号期间或者当正在建起连接但在用户接受连接建立之前时经由显示器向用户显示该信息。最简单的情况是，所显示的信息可以是呼叫者标识，该呼叫者标识或者为呼叫方的号码，或者为通过使用呼叫方的号码从用户装置的存储器中的电话簿或者从网络中的数据库检索的姓名。智能电话和相应装置的突破增加了不同应用的数量，这些应用还包括可显示关于呼叫方的更多信息的应用(app)。例如，对于以Android为操作系统的装置，可下载应用，该应用在用户与呼叫方连接时，除了姓名和号码及照片以外，还输出与社交简档(profile)(比如Facebook和Twitter上的简档)的链接，以及可能输出关于呼叫方的位置以及该位置的天气的信息。当用户没有与呼叫方连接时，如果公共可用号码信息是可用的，那么通过使用公共可用号码信息检索姓名信息。由此，即使应用也使用预定的预存储的数据以基于呼叫方的号码信息提供与呼叫方有关的信息。此外，附加信息要求该用户和呼叫方已预先连接并且两者还都具有简档账户。

发明内容

本发明的一般方面是，向第一方尝试与其建立连接的一个或多个第二方传送关于第一方的一些实时或近实时信息，这借助于对于包含实时或近实时信息的资源的引用(该引用由呼叫方给出)、或者通过在建立连接之前向一个或多个第二方发送实时或近实时信息来实现。

本发明在由独立权利要求中陈述的内容所表征的方法、装置、计算机程序产品和系统方面进行限定。本发明的优选实施例在从属权利要求中公开。

附图说明

以下，将参照附图更详细地描述不同的实施例，其中，

图1示出系统的简化结构和示例性装置的示意图；

图2和图3是例示网络装置功能的示例的流程图；

图4～11例示出根据不同的示例的信令；以及

图12是示例性装置的框图。

具体实施方式

以下的实施例是示例性的。虽然说明书可能在几处提到“某个”、“一个”或“一些”实施例，但这未必意味着每次这种说法均与相同实施例有关或者该特征仅适用于单个实施例。不同实施例的单个特征也可被组合以提供给其它的实施例。

本发明的实施例适用于被配置为在通信系统中使用并且支持向它的用户显示关于呼叫方的信息的任何装置。通信系统可以是无线通信系统或既利用一个或多个固定网络也利用一个或多个无线网络的通信系统。特别是在无线通信中，所使用的协议和通信的规范迅速发展。这种发展可能要求实施例的额外的改变。因此，所有措词和表达应被广义地解释，并且旨在例示(不是限制)实施例。

在图1中例示出根据示例性实施例的系统100的一般架构。图1是仅示出一些要素和功能实体的高度简化的系统架构，所有要素和功能实体都是其实施方式可能与所示出的不同的逻辑单元。图1所示的连接是逻辑连接的示例；实际的物理连接可以不同。对于本领域技术人员来说，显然系统还包括其它功能、结构和装置。应当理解，用于建立连接以及经由连接传输不同的媒体格式或者在建立连接以及经由连接传输不同的媒体格式时所使用的功能、结构、要素和协议以及连接所需要的实际信道的数量与实际的发明无关。因此，它们不需要在这里被更详细地讨论。

图1所示的示例性系统100包括经由接入网络120、120′被连接至核心网络130的一个或多个用户装置110、110′(图1中仅示出两个)，该核心网络130包含一个或多个包括对于呼叫者信息的资源的服务器装置(或者服务器系统)140。

核心网络130和接入网络120、120′中的一个或多个可以是移动网络、公共交换电话网络、广域网络WAN、因特网、对所有用户开放或者具有受限的接入的局域网络LAN(例如，企业LAN或办公室LAN)、比如Wi-Fi的无线LAN、私有网络、专有网络或它们的任何组合。但是，如上所述，网络所基于的类型和系统不代表什么，而是可以使用可输用户数据的任意类型的网络/连接。

在图1中，仅例示用于用户装置110、110′的一些单元。用户装置110、110′可以是可充当通信端点并且支持在一个或多个网络上的通信的任意类型的计算装置，并且它可被称为用户终端或者用户装备或用户设备。这种用户装置的示例包括在硬件或软件上与订户识别模块(SIM)一起或不一起操作的便携式无线移动通信设备，包括但不限于以下类型的设备：移动电话、智能电话、个人数字助理(PDA)、手持机、膝上型计算机、电子阅读设备、平板机、专用于服务的移动设备。此外，应当理解，可以使用任何类型的操作系统。这种操作系统的示例包括Android、iOS、Windows和OSX。另外，可以支持基于包含操作系统独立语言的任何编程语言的任何应用，诸如基于Java、HTML(超文本标记语言)、HTML5、ActionScript(“Flash”)和QT(跨平台应用构架)的应用。在例示出的示例中，用户装置110、110′包含用于传送关于用户的实时或近实时信息(以下，称为“实时呼叫者信息”或简称为“呼叫者信息”)并且用于输出关于呼叫方的实时呼叫者信息的呼叫方信息单元112、112′。如后面更详细地描述的那样，当使用拉(pull)原理时，呼叫方信息单元112、112′被用于传送对包含呼叫者信息的资源的引用，以及用于在由用户发起具有引用的连接建立时控制呼叫者信息被传送给资源，以及用于在具有引用的连接建立请求被接收时获取/检索要向用户显示的关于呼叫方的呼叫者信息。当使用推(push)原理时，呼叫方信息单元112、112′用于或者与连接建立请求一起或者在连接建立请求之后基本上立即地传送可被称为统一呼叫者信息或者以其它方式的呼叫者信息，如果UCI不与连接建立请求一起被传输，那么，当由用户发起具有UCI的连接建立时，呼叫方信息单元112、112′用于控制呼叫者信息被传送给被叫方，当具有UCI或者后跟UCI的连接建立请求被接收时，呼叫方信息单元112、112′用于获取/检索要向用户显示的关于呼叫方的呼叫者信息，如以下将更详细地描述的那样。应当理解，虽然UCI可包含呼叫者标识作为一条UCI，但是作为不可重复使用的实时信息的UCI不能与重复使用的呼叫者标识相同。呼叫方信息单元112、112′可被配置为仅实现拉原理、仅实现推原理或者实现这两种原理。用户装置110、110′还包含一个或多个不同的用于通信的接口单元111、111′，诸如用于发送和接收不同的媒体类型的一个或多个天线；以及不同的用户接口单元，诸如一个或多个屏幕(远程或集成的)、一个或多个扬声器(远程或集成的)、一个或多个照相机(远程或集成的)、触摸屏、开关、键盘、虚拟键盘、鼠标、操纵杆、选择器滚筒(selectorroller)、选择轮、选择器开关、绘制板、触摸板等。但是，在这里没有详细例示出它们。例如，用户装置110、110′还包含可以用于储存联系人信息的一个或多个存储器113、113′。取决于呼叫方单元的实现细节，存储器还可包含与呼叫方信息单元的联系人信息相关的设定和/或规则和/或简档和/或附加信息。例如，附加信息可以是具有未列号码或者具有预付账户的用户的名称，或者附加信息可以是描述针对呼叫的组织和/或原因的文本，诸如“我在电话销售公司xyz工作，打电话来告诉你在杂志xxx上有非常吸引人的职位”，或者一些测量数据，诸如位置、温度、风速、气压、心电图和呼吸中的酒精含量。将在以下描述设定、规则、简档(简档是一组设定)的不同示例和附加信息的另外的示例，而不将它们限于示例。

在图1中，仅例示出用于一个服务器装置140的一些单元。服务器装置140可以是可由具有适当的访问权限的用户装置或者由所有的用户装置访问并且可有助于传送先前储存的呼叫者信息和/或实时或近实时的信息呼叫者信息的任意类型的计算装置，它可被称为服务器或服务器系统。换句话说，服务器装置140可以是可编程或者以其它方式可配置为向一个或多个客户端实施专用资源共享的任何通用装置(设备)，客户端或者为另一装置中的远程客户端或者为服务器装置中的内部客户端。例如，服务器装置140可以是计算机或其它计算组件，比如web服务器或媒体服务器或者认证服务器或者用于验证呼叫方的身份的受信任第三方服务器。在例示出的示例中，服务器装置140包含一个或多个接口141、用于暂时储存先前使用的呼叫者信息和/或实时或近实时的呼叫者信息和/或用于储存由服务器提供的服务的附加信息的至少一个储存单元142以及至少一个存储器143。这种附加信息的示例包含验证用户所需要的验证信息或者认证用户所需要的认证信息。例如，服务器可以被配置为基于所接收的照片执行面部识别，然后将比如姓名、性别和/或年龄的身份信息与照片一起储存在资源中，并因此提供用于呼叫方的最终验证或认证的信息。应当理解，服务器装置所处位置对本发明不代表什么。例如，服务器装置可位于接入网络中。如果服务器装置被用作呼叫者信息中间人(mediator)，那么它可被用户装置访问就够了。在一种实施方式中，系统是一种集中式系统，即，总是经由服务器系统传送呼叫者信息的系统(可以是出于该目的的专用系统)。在基于集中式系统的实施方式中，各用户装置，或者，更确切地说，各客户端，建立与中心服务器的连接而不建立与其它用户装置的连接，并且，服务器映射连接，使得端用户体验到连接为端到端用户装置的连接。在另一实施方式中，系统是分散式系统，其中，经由其传送呼叫者信息的服务器可被自由选择，包括使用呼叫方的用户装置作为呼叫者信息的服务器的选项。但是，也存在没有服务器装置介入于呼叫者信息的传送的实施方式。

先前储存的呼叫者信息是事先捕获以伴随呼叫建立被使用一次的信息。用于确保先前储存的呼叫者信息仅被使用一次的任何手段都可以使用。例如，先前储存的呼叫者信息可在被获取/检索时被删除或者在被使用时被标记/标示。先前储存的呼叫者信息可与特定寿命相关联，如果寿命到期，那么该信息不能被使用。先前储存的呼叫者信息可以是用户的图片和/或文本消息和/或语音消息。应当理解，这些仅是示例，可以使用任何类型的信息。

实时信息或近实时信息在本质上是一次性信息。实时信息或近实时信息可以是来自呼叫方的用户装置的图像流、视频流和/或音频流，和/或由与呼叫方的用户装置一体化或者以其它方式与其连接的测量单元/设备/传感器测量的一些识别/个人数据，和/或由与呼叫方的用户装置一体化或者以其它方式与其连接的照相机捕获的图像。识别测量数据(即，使得能够识别呼叫方的信息)也被称为个人信息，借助于个人信息，呼叫方是可识别的，识别测量数据的示例包含指纹、虹膜打印、面部图像和语音。应当理解，以上的列表不是详尽的列表，也可以使用其它信息作为实时或近实时信息；在用户的控制下通过用户装置或者通过与呼叫方的用户装置一体化或者以其它方式连接的另一装置/设备/部件捕获信息就够了。在这里，表述“在用户的控制下”意味着，用户知悉什么信息被发送，并因此可决定不发送它(虽然这可能必须结束呼叫)，以及对于使用该信息的连接建立请求，优选地但不是必须地针对连接建立而捕获该信息。这里，实时或近实时信息意味着被捕获并且在被捕获之后的一定时间段内被使用的信息。例如，该时间段可被设定为15分钟。该时间段可被设定为取决于所使用的信息类型。例如，对于视频，时间段可为15秒、对于音频为25秒，对于照片为15分钟，以及对于其它识别测量数据为2分钟。另一示例包括对于视频和音频为20秒以及对于其它为15分钟。虽然必须使用该信息的时间段可被自由设定，但是，为了确保信息的实时特性，该时间段不应太长。例如，15分钟作为最大上限是合理的限制。

以下，术语实时信息还涵盖近实时信息。

以下，呼叫被用作连接建立的示例，以及，当通过使用拉原理传送呼叫者信息时，URI(统一资源标识符)被用作对资源的引用的示例。URI是通过对在一个或多个网络上可用的资源的明确引用而识别抽象或物理资源的紧凑的字符序列。换句话说，URI被用作呼叫者信息的指针的示例。作为URI的替代，可以使用除了在连接建立请求中被使用以出于将响应路由回呼叫方的目的而指示呼叫方的标识符以外的标识符。此外，如果呼叫方使用被叫方以外的另外的系统或应用，诸如flash客户端和m4y客户端，那么可能必须桥接不同的指针，使得被叫方的客户端可获取呼叫方的呼叫者信息。当实现连接至其结束并且其映射连接的集中式服务器时，对资源的引用可以是呼叫者标识和呼叫方标识的组合。但是，应当理解，即使在这种情况下，也可使用URI。对于本领域技术人员，同样显然的是，当通过使用推原理传送呼叫者信息时，不需要引用，但是与连接建立请求一起或者在连接建立请求之后基本上立即地传送UCI。

图2是例示被叫方的用户装置的示例性功能，或者更确切地说，是例示在接收连接建立请求时的呼叫方识别单元的示例性功能的流程图。在图2的示例中，用户已限定了如果没有URI的连接建立请求被接收且呼叫方不在联系人列表中，那么用户不被提醒，否则，通过播放铃声提醒用户。此外，假定通过显示呼叫者信息向用户输出呼叫者信息。应当理解，也可使用其它的输出内容(呼叫者信息)的方式。例如，可通过语音产生器读取文本信息。

当在步骤200中接收呼叫建立请求时，在例示出的示例中，在步骤201中检查呼叫建立请求是否是可接受的。例如，设定或配置可以从呼叫用户装置要求某些能力，诸如使用相同应用。但是，步骤201的检查在其它的实施方式中可被省略。

如果呼叫建立请求是可接受的(步骤201)，那么通过在步骤202中向呼叫方发送指示待定状态的相应消息，确认该请求为待定的。应当理解，当呼叫建立协议不需要周期性的“待定指示”时，省略步骤202。当呼叫方的用户装置接收消息(指示)时，呼叫方听到“提醒”或“响铃”。但是，在示例中，在该时刻在被叫方的用户装置中没有产生铃声。然后在步骤203中检查呼叫建立邀请是否包含URI。如果是，那么在步骤204中从请求中提取URI，并且，在步骤204中对由URI指向的资源建起连接以在资源中检索内容。内容可以是例如近期的照片、带有附加的文本的近期的照片或者源自呼叫方的用户装置的视频流。然后，在步骤205中向被叫方显示内容，并且在步骤205中产生铃声。当然，如果用户装置处于静音模式，那么不输出铃声。内容可被显示在用户装置的显示器上、在单独附接的设备上，或者被具有适当的接口硬件的附接的计算机处理，或者在电视屏幕上。

然后，在步骤206上设定定时器，并且，监视定时器是否到期(步骤207)、呼叫是否被用户拒绝(步骤208)或者呼叫是否被用户软拒绝(步骤209)或者呼叫是否被用户接受(步骤210)。

如果定时器到期(步骤207)或者呼叫被拒绝(208)，那么在步骤211中停止显示和铃声产生，并且，在步骤212中发送对呼叫建立请求的否定确认。由此，定时器的目的是，确保如果呼叫方耐心并且不挂断(如在图2所例示的示例中假定的)，而用户不对提醒起反应，那么提醒将不会一直继续。

如果呼叫被软拒绝(步骤209)，那么在步骤213中停止显示和铃声产生，使得用户装置认为呼叫建立被拒绝，但不向呼叫方的用户装置通知。因此，在步骤214中，继续发送确认呼叫建立请求为一个待定请求的消息，直到呼叫方放弃。应当理解，当呼叫建立协议不需要周期性“待定指示”时，省略步骤214。换句话说，在例示出的示例中，软拒绝意味着呼叫建立被拒绝，由此，被叫方的用户装置能够接收，并且能够发送新的呼叫建立请求，但是不向呼叫方的用户装置发送对在步骤200中接收的呼叫建立请求的否定确认。由此，呼叫方认为呼叫建立请求仍待定。应当理解，在另一示例中，软拒绝可以仅停止显示和铃声产生(即，暂时将用户装置设定为静音模式)。

如果呼叫被接受，那么在步骤215中停止显示和铃声产生，并且，在步骤216中继续呼叫建立。如果呼叫建立请求指示视频呼叫，那么基于接受呼叫时的用户的选择，呼叫可被建立为音频呼叫或视频呼叫。但是，由于本发明不必须改变为实际的呼叫建立，这里不更详细地描述。

如果呼叫建立邀请不包含URI(步骤203)，那么在步骤217中检查是否在用户的联系人列表中找到呼叫方的号码。如果是，那么在步骤218中向用户装置的用户显示借助于联系人列表可获取的信息，并且在步骤218中产生铃声。当然，如果用户装置处于静音模式，那么不输出铃声。然后，处理前进到步骤206以设定定时器。

如果呼叫方的号码不在联系人列表中(步骤217)，那么在步骤219中禁用铃声的产生并且处理前进到步骤214以继续发送确认建立请求为一个待定请求的消息，直到呼叫方挂断。应当理解，如果提醒设定不自动触发提醒的产生或者假定要对提醒执行某事项，那么步骤219可被省略。

在另一实施方式中，在步骤215中，仅停止产生铃声，而继续显示内容，除非用户输入停止显示的指令。在该实施方式中，如果呼叫是视频呼叫，那么可通过使用用于视频呼叫的屏幕以外的另一屏幕显示内容。

在另外的实施方式中，如果在请求中不存在URI并且呼叫方不在联系人列表中，那么处理从步骤219(或者，如果省略步骤219，则从步骤217)直接前进到步骤212，即，不等待到呼叫方挂断，或者，作为替代方案，可设定定时器，在该定时器到期时，处理前进到步骤212。定时器可具有与在步骤207中被监视的定时器相同的等待时间或者另一时间。

在又另一实施方式中，提供具有定时器的软拒绝，该定时器的到期导致处理从步骤214前进到步骤212，以在如果呼叫方非常耐心且不挂断时发送否定确认。定时器可以具有与以上的定时器中的一个相同的等待时间或者另一时间。在实施方式中，如果在请求中没有URI并且呼叫方不在联系人列表中，那么可以使用这里描述的处理中的任一个。

在又另一实施方式中，不提供软拒绝。在实施例中，省略步骤209和213，并且，从步骤217，即，如果在请求中不存在URI并且呼叫方不在联系人列表中，则处理前进到步骤212，以发送对于呼叫建立请求的否定确认。

如果呼叫方的号码不在联系人列表中(步骤217)，那么还可以检查呼叫方的号码是否处于“被拦截的呼叫方”的列表中。如果呼叫方的号码处于“被拦截的呼叫方”的列表中，那么在步骤219中禁用铃声的产生并且处理前进到步骤214或步骤212，或者，如果省略步骤219，那么处理直接前进到步骤214或步骤212。但是，如果呼叫方的号码不处于“被拦截的呼叫方”的列表中，那么产生铃声并且显示号码，处理前进到步骤206以开始定时器。还可以先检查“被拦截的呼叫方”的列表，如果在列表上没有找到，那么检查联系人列表。又另一替代方案是仅检查“被拦截的呼叫方”的列表。这些替代方案的优点在于，被叫方接收有人正在呼叫的信息，但是被叫方不被通知关于来自被拦截的呼叫方的呼叫/不被来自被拦截的呼叫方的呼叫打扰。

如果呼叫建立请求不是可接受的(步骤201)，那么在例示的示例中，处理前进到步骤212，以发送对于呼叫建立请求的否定确认。应当理解，也可使用处理呼叫建立请求的任何其它方式。

从以上清楚地看出，不需要呼叫方和被叫方事先相互连接，或者被叫方具有关于呼叫方的任何信息；如果呼叫方的用户装置或者自动或者响应于用户输入而将URI添加到请求上，那么呼叫者信息是可用的。此外，另一优点是，由于向被叫方显示的呼叫者信息不与呼叫方的联系人信息(比如电话号码)有关系，因此呼叫方可保持其联系人信息保密并且还能被被叫方识别。

图3是例示出呼叫方的用户装置的示例性功能，或者更确切地说，例示出发起连接建立请求时的呼叫方识别单元的示例性功能的流程图。在图3的示例中，设定用户设定，使得每次触发呼叫建立时可以选择对于呼叫者信息的不同替代方案。应当理解，呼叫者信息可被设定为总是为一种类型，诸如视频，或者它可作为联系人信息的一部分与被叫者号码相关(在该情况下，使用缺省类型)，或者对不包含于联系人信息中的号码显示替代方案。

当检测到指示呼叫建立的用户输入时(步骤301)，在步骤302中提示用户输入要被作为呼叫者信息发送的信息。例如，可向用户显示不同的替代方案，诸如“使用近期储存的信息”、“发送视频”、“新捕获的图像”、“测量的数据”和“身份验证”。应当理解，可以提供任何数量的替代方案，以上的示例仅是示例，不是详尽的列表。本示例中的替代方案之间的基本不同在于，或者替代方案在例示出的示例中被提前储存给用户装置，或者替代方案是需要通过被配置为获取考虑之中(in question)的信息或者可导出信息的信息的相应部件获取的实际实时信息，然后，在例示出的示例中，需要向充当呼叫者信息中间人的服务器传送信息。使用的服务器可取决于要作为呼叫者信息被发送的信息或者在使用中的设定。例如，设定可以是“服务器1”被用于视频流、“服务器2”被用于从捕获的信息导出信息，除非包含设定“使用服务器X”的简档是用户装置中的选择的简档。还可以在某些简档中或者如果在简档设定中没有定义其它服务器时，限定用户装置自身被用作服务器。由此，不存在对使用什么服务器以及如何选择服务器的限制。

当用户选择被接收时，在步骤303中确定选择是否指示实时信息。如果用户选择传送实时信息，那么在步骤304中激活与选择的信息有关的设备/单元/接口/传感器，在步骤305中捕获信息，并且在步骤306中将其发送到服务器以用于暂时的储存和/或用于进一步的处理。应当理解，如果用户装置自身是服务器，那么发送到服务器意味着至少暂时存储于用户装置的存储器中的储存区域。取决于选择的信息，捕获和发送可以是孤立的步骤或者在后台中是继续的。例如，捕获用户的照片和发送它是孤立的步骤，但是发送视频流是连续的步骤。取决于实施方式，可继续连续的捕获和发送，直到建立呼叫或者确定呼叫不会被建立或者直到所建立的呼叫结束或者响应于接收指示停止捕获和发送的用户输入。为了清楚起见，在图3中没有例示出这些步骤。在步骤307中，从服务器接收URI，该URI指示存储内容(即捕获的信息或基于捕获的信息导出的信息)的资源。

当接收URI时，在步骤308中产生呼叫建立请求，并且，在步骤308中向呼叫建立请求添加URI，该呼叫建立请求然后在步骤309中被发送到一个或多个被叫方。为了清楚起见，这里假定呼叫建立请求仅被发送到一方。

然后，在步骤310中，开始定时器并且监视是否接收到指示请求为待定请求的消息(步骤311)、定时器是否到期(步骤312)、用户是否挂断(步骤313)、是否接收到对于呼叫建立请求的拒绝(步骤314)或者是否接收到对呼叫建立请求的接受(步骤315)。

如果接收到指示请求为待定请求的消息(步骤311)，那么在步骤316中向用户输出铃声，然后，监视继续。

如果定时器到期(步骤311)或者如果用户挂断(步骤312)或者如果接收到拒绝(步骤313)，那么在步骤317中结束处理。

如果接收到接受(步骤315)，那么在步骤318中继续呼叫建立。但是，由于本发明不是必须改变为实际呼叫建立，因此不在这里更详细地描述。

如果用户选择传送提前储存的信息(步骤303)，那么在步骤319中提示用户指示要发送的信息(内容)，例如通过浏览。在实施方式中，假定出于这种目的提前储存的信息具有寿命并且在到期之后不可使用(不可指示)。一旦在步骤320中接收到用户指示，就在步骤321中检索与指示的信息有关的URI，然后，处理继续到步骤308以产生具有URI的请求。

在另一实施方式中，可在步骤321之前检查用户指示的信息是否足够新，并且，如果信息太旧，那么再次提示用户。

在又另一实施方式中，提供的所有替代方案是实际的实时替代方案，因此，步骤303和319～321被省略。

从以上清楚地看出，提供实时信息(比如视频流或从呼叫者刚刚拍摄的照片)的可能性确保即使当呼叫方使用其它人的用户装置时，被叫方也可容易地识别呼叫方，或者如果被叫方忙并且不想被中断，那么仍然通过其中有明显的紧急状况或抓狂的呼叫方的视频来得到被叫方的关注。

在另一实施方式中，例如，如果将呼叫者信息预设为替代方案中的一个，那么可提示用户提供信息，因此隐含地接受信息被发送，或者提示信息捕获开始，因此，如果他/她不接受发送信息或者用户根本没有被通知，那么向用户提供结束呼叫建立的可能性，在这种情况下，用户可通过利用应用来进行呼叫或者通过开始使用用户装置和/或通过将在它的设定“关于呼叫者信息传送不通知我”中具有的简档付诸使用而可能已经接受了信息被发送。

图4～9是例示出其它示例的信令图。由于可以使用任何合适的协议以传送需要的信息，因此，信令图例示出一般意义上的信息交换。合适的协议的示例包括HTTP(超文本传输协议)、RTHTTP(实时HTTP，如于2013年4月23日提交的专利申请GB 1307340.8中描述的那样)、SIP(会话发起协议)、SDP(会话描述协议)、RTP(实时传输协议)、RTCP(RTP控制协议)、RTMP(实时消息收发协议)、封装于HTTP请求内以越过防火墙的比如RTMPT的RTMP的任何变化形式和Skype协议。应当理解，也可使用其它协议，包括还在被定义的新协议和标准。此外，通过阅读说明书，本领域技术人员能够利用现有的或者将来开发的任何合适的协议和/或标准实现这里描述的功能。此外，应当理解，用于呼叫建立的协议可以与用于呼叫者信息传送的协议不同或者相同。

为了清楚起见，在以下的示例中，呼叫是两方之间的。对于本领域技术人员来说，对于多人呼叫或者电话会议(即对具有三个或更多个参与方的呼叫)实现相同的原理是能直接得到的。

在图4和图5的示例中，假定呼叫者信息是从Alice的用户装置UA1直接传送的视频流并且UA1包含到Bob或者到Bob使用的用户装置UA2的地址。

参照图4，Alice已经向她的用户装置UA1输入她想呼叫Bob。因此，UA1向UA2发送作为呼叫建立消息的消息4-1，该呼叫建立消息包含呼叫方地址、被叫方地址、作为与呼叫有关的附加信息的指针的URI，以及在例示出的示例中，包含对音频呼叫以及对于视频呼叫的媒体定义以及其它信息。消息4-1的示例是对于URI包含在SDP中限定为将用于传输与会话有关的附加信息的指针的附加域“u”的SIP INVITE。另一示例是在其本体中包含URI的HTTP呼叫请求。使用URI以指向呼叫者信息具有呼叫者信息可被独立传送操作系统的优点，并且呼叫者信息可在不取决于呼叫方的地址信息的情形下被传送。

UA2在点4-2中检测到消息4-1包含URI。因此，虽然在消息4-3中向UA1发送对于呼叫建立消息的正常响应，UA2却不产生铃声。但是，应当理解，在另一实施方式中，不发送消息4-3。响应于检测到UR1，UA2建立与由URI指示的资源的连接以获取信息。在例示出的示例中，通过向作为至少暂时储存视频的储存区域的资源发送连接建立消息4-4而执行它。由于URI指示UA1，因此消息4-4是定向到UA1且包含URI的消息。

响应于在点4-5中检测到对于UA1内的资源的连接建立请求，UA1发送接受与资源的连接的消息4-6，以及在消息4-7(在图4中仅表示第一消息)中，内容被从UA1转发到UA2。在示例中，假定内容是视频流。消息4-7形成一种单播视频会议。响应于接收到呼叫者信息，UA2在点4-8中产生铃声并且向Bob显示视频流。在点4-9中，UA2检测到Bob应答呼叫。在例示出的示例中，UA2被配置为通过发送消息4-10结束对于呼叫者信息建立的连接。此外，UA2发送指示Bob应答Alice的呼叫的消息4-11。应当理解，在其它实施方式中，不发送消息4-10，但消息4-11可以解释为以指示相同的信息，即，当建立对于呼叫的连接时，解除对于呼叫者信息传送建立的连接，或者只要实际呼叫正在进行中，就可发送消息4-7。

响应于消息4-10，UA1通过消息4-13确认它并且在点4-12中停止经由对于呼叫者信息传送建立的连接而传送视频流。此外，由于呼叫被接受(消息4-11)，UA1通过发送消息4-14确认呼叫接受，以及，在Alice与Bob之间建立双向媒体流4-15。媒体流4-15可以是音频流和/或视频流。

应当理解，作为发送消息4-10的替代，UA2可被配置为对于在消息4-7中传送的单向呼叫者信息停止发送确认(在图4中未示出)。此外，UA2可被配置为响应于检测到(点4-9)Bob接受Alice的呼叫而立即停止显示视频。另外的替代方案在于UA1被配置为将消息4-11解释为隐含的消息4-10，在这种情况下，不发送消息4-10和4-13。

总结图4的示例，在双向连接建立是待定的时，建立从呼叫者到被叫者的单向连接(图4中的斜体字)，该单向连接最晚在当建立双向连接时被解除。应当理解，在一些其它的实施方式中，单向媒体连接可被升级为双向媒体连接。

图5例示出与图4类似的情形下的信令。Alice已经向她的用户装置UA1输入她想呼叫Bob。因此，UA1向UA2发送作为呼叫建立消息的消息5-1，该呼叫建立消息包含呼叫方地址、被叫方地址，以及在例示出的示例中，包含对于音频呼叫以及对于视频呼叫的媒体定义以及其它信息。但是，与图4中的消息4-1不同，消息5-1不包含URI。

UA2在点5-2中检测到消息5-1不包含URI。但是，Bob的设定要求呼叫者信息。因此，虽然UA2在消息5-3中向UA1发送对于呼叫建立消息的正常响应，但是在消息5-4中向UA1发送呼叫者信息请求。

UA1在点5-5中检测到请求呼叫者信息，或者更确切地说，检测到请求可获取呼叫者信息的信息。UA1从Alice的设定中检查Alice是否授权呼叫者信息传送。在例示出的示例中，假定Alice已接受呼叫者信息传送。因此，UA1向原始消息5-1添加URI，并且向UA2发送消息5-1′，该消息5-1′是与上述的消息5-1对应的消息。从此以后，过程如利用图4描述的那样继续，由此不在这里无用地重复描述。

从图4和图5的示例可以看出，如果呼叫方的用户装置在没有来自被叫方的用户装置的任何特定请求的情形下向呼叫建立请求添加URI，那么呼叫建立花费更少的时间并且使用更少的网络资源。通过这样做，避免了消息5-3、5-4和5-1′以及点5-5。但是，通过消息5-4和5-1′以及点5-5，确保呼叫者信息具有被叫方的用户装置或者订购支持的格式。换句话说，如果UA1处于消息5-1中，那么UA2可在点5-2中检测到它不支持呼叫者信息的格式，该格式由URI指示，并因此发送指示UA2支持的格式的消息5-4。

图6例示出集中式系统中的信令，在该集中式系统中，为了确保信息满足实时或近实时的标准，总是经由被配置为仅储存呼叫者信息非常短的时间(诸如若干毫秒)的服务器S1传送呼叫者信息。在图6的示例中，假定呼叫者信息是视频流，Alice的用户装置UA1包含Bob或者Bob使用的用户装置UA2的地址，并且，Alice的用户装置中的设定指示总是在Alice选择呼叫某人时传送呼叫者信息。

参照图6，Alice已经向她的用户装置UA1输入她想呼叫Bob。为了传送根据Aclice的设定要被传送的呼叫者信息，UA1向S1发送消息6-1，消息6-1是请求用于传送呼叫者信息的连接的消息。S1通过消息6-2响应，消息6-2是接受针对呼叫者信息的连接并且指示将呼叫者信息发送到的地址的消息。地址可以是也可用于实际呼叫的地址。在接收地址之后，UA1在点6-3中开始捕获视频，UA1在视频流6-4中将该视频推向S1。应当理解，UA1可响应于检测到Alice想要呼叫或者响应于接收到地址而立即地或者在以上提及的时间之间的任何时间中开始捕获视频。

在接收UR1之后，UA1经过S1向UA2发送作为呼叫建立消息的消息6-5，该呼叫建立消息包含呼叫方地址，被叫方地址，作为与呼叫有关的附加信息的指针在消息6-2中指示的地址，以及，在例示出的示例中，包含对于音频呼叫以及对于视频呼叫的媒体定义以及其它信息。UA2通过经过S1向UA1发送消息6-6确认消息6-5，(UA1然后可开始输出声音，使得Alice认为Bob的用户装置正在提醒/响铃)。响应于消息6-5中的URI，UA2向S1发送消息6-7，消息6-7指示对于URI后面的内容的拉请求，该内容在消息6-8中被接收。

响应于接收呼叫者信息，UA2在点6-9中产生铃声并且向Bob显示视频流。在点6-10中，UA2检测Bob应答呼叫，因此，UA2经过S1向UA1发送消息6-11，消息6-11是指示Bob应答Alice的呼叫的消息。然后，或者经过S1(如图6所示)或者在消息6-12没有穿过S1的情形下，在UA1与UA2之间在消息6-12中传送实际呼叫内容。

在图7和图8的示例中，假定呼叫者信息是视频流，Alice的用户装置UA1包含到Bob或者到Bob使用的用户装置UA2的地址，视频流以及UA1与UA2之间的任何其它用户业务穿过服务器S1。

参照图7，Alice已经向她的用户装置UA1输入她想呼叫Bob。因此，UA1经过S1向UA2发送作为呼叫建立消息的消息7-1，该呼叫建立消息包含被叫方地址，以及在例示出的示例中，包含对于音频呼叫的媒体定义。应当理解，在其它的示例中，消息7-1包含对于音频呼叫以及对于视频呼叫的定义或者仅对于视频呼叫的定义。

S1将消息7-1转发到UA2，并且，在消息7-2中发送对它的确认。响应于消息7-2，UA1开始输出铃声，使得Alice假定Bob的用户装置正在响铃。

为了传送根据Alice的设定要被传送的呼叫者信息，UA1向S1发送消息7-3，消息7-3是请求用于传送呼叫者信息的连接的消息。S1通过消息7-4响应，消息7-4是接受针对呼叫者信息的连接并且指示将呼叫者信息发送到的地址的消息。现在，UA1开始向S1转发视频流7-5。

同时，UA2在点7-6中检测到消息7-1不包含URI。由于Bob的设定要求呼叫者信息，因此UA2向S1发送消息7-8，消息7-8是请求与在消息7-1中接收的呼叫建立请求有关的呼叫者信息的消息。

S1在点7-9中检测到消息7-8请求已被S1接收的呼叫者信息。因此，S1向UA2转发视频流7-5，即呼叫者信息。

响应于接收到呼叫者信息，UA2在点7-10中产生铃声并且向Bob显示视频流。在点7-11中，UA2检测到Bob通过选择视频呼叫应答呼叫，虽然原始呼叫建立请求指示仅音频呼叫。UA2发送消息7-12，消息7-12是指示Bob应答Alice的呼叫并且想进行视频呼叫的消息。

在例示出的示例中，S1和UA1被配置为解释消息7-12也结束转发呼叫者信息。因此，S1转发消息7-12并且也在点7-13中停止转发视频流7-5。

当接收消息7-12时，UA1停止转发视频流7-5，并检测到7-12包含原本请求的另一类型的呼叫以及Alice的用户设定要求允许将类型从音频呼叫改变为视频呼叫，因此，在点7-14中提示Alice或者接受呼叫为视频呼叫或者将呼叫约束为音频呼叫。应当理解，在另一实施方式中，不提示Alice接受从音频呼叫到视频呼叫的改变。在例示出的示例中，Alice接受视频呼叫。UA1通过发送消息7-15通知UA2视频呼叫被接受。然后，针对呼叫建立双向视频流7-16。

在另一实施方式中，作为消息7-1的替代，S1发送包含呼叫建立请求和URI的消息。

图8例示出与图7类似的情形下的信令。但是，在示例中，在没有源自被叫方的用户装置的明确请求的情形下，不从UA1传送呼叫者信息。

参照图8，Alice已经向她的用户装置UA1输入她想要呼叫Bob。因此，UA1向S1发送与消息7-1对应的消息8-1。S1向UA2转发消息8-1，并且在消息8-2中发送对消息8-1的确认。响应于消息8-2，UA1开始输出铃声，使得Alice认为Bob的用户装置正在响铃。

UA2在点8-3中检测到消息8-1不包含URI。由于Bob的设定要求呼叫者信息，因此UA2经过S1向UA1发送消息8-4，该消息请求关于呼叫者的呼叫者信息，其中在消息8-1中接收的呼叫建立请求源自该呼叫者的用户装置。

S1在点8-5中检测到消息8-4请求没有从UA1接收的呼叫者信息。S1向UA1发送消息8-6，消息8-6是请求用于传送呼叫者信息的连接以及指示呼叫者信息发送到的地址的消息。消息8-6可以是与消息8-4相同的消息。UA1通过消息8-7响应，消息8-7是接受针对呼叫者信息的连接的消息。此外，UA1在点8-8中开始捕获视频，UA1然后在视频流8-9中向S1转发该视频。通过在该点处开始捕获，确保存在可向UA2推或拉的呼叫者信息，但是，在示例中，仅在UA2请求呼叫者信息之后发送呼叫者信息。

S1检测到UA1接受呼叫者信息传送(消息8-7)并且通过发送消息8-10触发用于对UA2的呼叫者信息传送的连接建立。此外，S1向UA2转发视频流8-9。之后，过程如从图7中的点7-12那样继续，即，UA2产生铃声并且向Bob显示视频流，由此不在这里无用地重复描述。

在图4、图5、图6、图7和图8的示例中，用户装置UA1和UA2在没有来自Alice和Bob的任何特定用户输入的情形下传送呼叫者信息。由此，呼叫和呼叫的应答与没有呼叫者信息情形下的呼叫和应答一样平稳。

参照图9，Alice已经向她的用户装置UA1输入她想要呼叫Bob。因此，UA1向UA2发送消息9-1，消息9-1是包含呼叫方地址、被叫方地址以及对于音频呼叫和/或对于视频呼叫的媒体定义以及其它信息的SIP INVITE消息。

UA2在点9-2中检测到消息9-1不包含URI。Bob的用户设定要求在这种情况下提示Bob是否请求呼叫者信息，UA2因此在点9-2中提示Bob。可通过简单地显示“来自Alice的没有呼叫者信息的来电在待定中。请问你想请求该信息吗”而提示Bob，或者Bob可被提示还选择Bob想要有的呼叫者信息的类型，和/或，Bob还可被给予拒绝或软拒绝呼叫尝试的替代方案。利用以上的步骤301描述不同选择替代方案的示例。在例示出的示例中，Bob变得怀疑，因为一般Alice用呼叫者信息呼叫。因此，Bob选择“通过指纹验证用户”为呼叫者信息。响应于Bob的用户输入，UA2向UA1发送指示缺失URI的消息9-3。该特征的优点在于，被叫方可以在决定是否应答之前决定是否请求关于呼叫方的进一步的信息。可存在针对不同类型的呼叫者信息的不同的消息9-3，以及/或者，消息9-3可包含指示想要的一个或多个类型的呼叫方信息的域。

响应于接收到消息9-3，UA1在点9-4中提示Alice需要指纹以继续与Bob的呼叫建立。由于在例示出的示例中Alice想要继续，因此Alice在点9-4的UA1中输入她的指纹作为用户输入。例如，可通过拍摄快照输入指纹。在Alice的设定中，存在到具有Alice的预存的指纹的服务器S1的地址。UA1和S1通过消息9-5和9-6建立连接，然后UA1发送用于验证指纹的包含指纹的消息9-7。应当理解，如果用户装置UA1的使用需要指纹验证，那么不需要在点9-4中提示用户，但是，用来获取使用UA1的许可的指纹可在消息9-7中被转发，或者，当决定许可使用时获取的指纹和在许可期间在比较中使用的存储器中的指纹二者都可在消息9-7中被发送。在这种情况下，服务器不必储存指纹。

S1验证指纹是Alice的指纹并且在点9-8中将结果暂时储存于储存区域并且在消息9-9中发送指示存储区域的URI。

在接收到URI之后，UA1在点9-10中向消息9-1添加URI，并且在消息9-1′中向UA2发送具有URI的邀请。

UA2检测到消息9-1′是消息9-1的更新并且包含URI。因此，UA2向UA1发送消息9-11，消息9-11指示在消息9-1中发送的请求为待定的，并且向由URI指示的S1发送连接建立消息9-12。在另一示例中，在接收消息9-1之后立即发送消息9-11。

响应于消息9-12，S1通过发送消息9-13接受连接，并且从储存区域检索结果，释放存储区域用于其它用途，并且在消息9-7′中向UA2转发结果。

UA2在点9-14中产生铃声并且向Bob显示结果。在点9-14中，UA2检测到Bob对在例示出的示例中为音频呼叫的呼叫应答。UA2发送指示Bob的应答的消息9-15(SIP 200OK)。

响应于消息9-15，UA1通过消息9-16确认(SIP ACK)，并且，在Alice与Bob之间建立经由RTP的双向音频9-17。

图10例示出集中式系统中的信令，在该集中式系统中，呼叫方与被叫方之间的连接实际上是两个单独的连接，一个在呼叫方与集中式服务器之间，一个在集中式服务器与被叫方之间。在这种集中式系统中，至少当不参与通信时，用户装置中的呼叫客户端被配置为周期性地轮询服务器，以找出任何待定的呼叫建立请求，以及从呼叫客户端向服务器发起通信。在例示出的示例中，呼叫客户端被配置为通过使用HHTP GET请求和RTMP在REST(表述性状态传递样式)中通信，但不将示例限于这种方案。此外，在示例中，对于包含呼叫者信息的资源的引用是呼叫者标识符和被叫方标识符的组合。此外，在示例中，为了确保信息满足实时或近实时的标准，假定集中式服务器S1被配置为仅储存呼叫者信息非常短的时间，诸如若干毫秒，但不将示例限于这种方案。在图10的示例中，假定呼叫者信息是视频流，Alice的用户装置UA1包含到Bob或者到由Bob使用的用户装置UA2的地址，并且，Alice的用户装置中的设定指示总是在Alice选择呼叫某人时传送呼叫者信息。

参照图10，Alice已经向她的用户装置UA1输入她想呼叫Bob。为了建立连接并且传送根据Alice的设定要被传送的呼叫者信息，UA1向S1发送消息10-1，该消息10-1是请求连接Bob的用户装置UA2的消息，诸如“呼叫请求”(HTTP)，并且用于传送呼叫者信息，即视频流消息10-2，诸如“NetStream发布音频/视频”(RTMP)。

S1在点10-3中通过创建呼叫的记录、通过为呼叫者信息的暂时储存保留一些存储器资源以及通过对UA2创建事件，映射请求。记录包含由UA1和UA2用来指讨论中呼叫的呼叫者标识符和被叫方标识符二者，由此借助于它们找到记录，并因此找到呼叫者信息。

当UA2下一次通过诸如“周期性的事件轮询”(HTTP)的消息10-4轮询S1时，S1通过发送消息10-5以及在消息10-6中的呼叫者信息而通知呼叫建立请求。消息10-6与消息10-2对应。

响应于接收消息10-5和10-6，UA2在点10-7中通过产生铃声以及通过显示呼叫者信息即视频告知Bob呼叫建立请求。当UA2在点10-8中检测到呼叫被接受时，处理如现有技术那样继续。更确切地说，UA2向S1发送诸如“呼叫请求”(HTTP)的消息10-9，消息10-9然后通过发送诸如“呼叫响应”(HTTP)的消息10-10使UA1确认Bob应答。然后，通过交换消息10-11(从Alice到S1，从S1到Bob)和消息10-12(从Bob到S1，从S1到Alice)，视频或音频呼叫在进行中。消息10-11和10-12可与消息10-2对应。

图11所例示的示例与图10的示例不同在于，只有当被Bob特定请求时发送呼叫者信息。例如，Alice的设定可以是“不发送呼叫者信息，除非被请求”，Bob的设定可以是“如果未接收到呼叫者信息，则提醒并且提供请求呼叫者信息的机会”。换句话说，在图10中，在没有对于信息的任何特定请求的情形下连续地发送连接建立请求和信息，以及在图10中，或者响应于特定请求而发送信息。

参照图11，Alice已经向她的用户装置UA1输入她想呼叫Bob。为了建立连接，UA1向S1发送消息11-1，该消息11-1是请求连接Bob的用户装置UA2的消息。

S1在点11-2中通过对呼叫创建记录、通过临时保留一些用于暂时储存呼叫者信息的存储器资源，以及通过对UA2创建事件而映射请求。应当理解，在另一方案中，不保留用于暂时储存呼叫者信息的存储器资源。

当UA2下一次通过消息11-3轮询S1时，S1通过发送消息11-4而通知呼叫建立请求。

响应于接收消息11-4，UA2在点11-5中通过产生铃声并且通过显示用于请求呼叫者信息的选择工具而告知Bob呼叫建立请求。在例示出的示例中，Bob选择请求UA2在点11-5中检测的呼叫者信息。因此，UA2发送请求来自呼叫者的呼叫者信息的消息11-6，诸如“预览请求”(HTTP)。

由于S1可将请求映射到现有的记录，因此，S1通过发送诸如“预览响应”(HTTP)的消息11-7而通知UA1该请求。

在示例中，假定不需要来自Alice的反应。因此，响应于消息11-7，UA1开始在消息11-8中向S1传送呼叫者信息，将呼叫者信息映射到呼叫请求并且向UA2发送呼叫者信息(消息11-8)。

响应于接收被假定为视频的呼叫者信息，UA2在点11-9中向Bob显示呼叫者信息。然后，如果Bob接受呼叫，那么处理从点10-8如上面描述的那样继续。

从以上的示例清楚地看出，接受所请求的连接之前，呼叫方和/或呼叫方的用户装置可提供关于准确的实时时刻的信息，该信息常常会是接受者需要基于其作出他或者她的是否应答的决定的最关键的信息。

虽然在以上没有明确表述，但应理解，经由其向被叫方输出呼叫者信息的用户装置可以与被叫方在他或她接受呼叫(连接)时使用的用户装置不同。

在图4～9的以上的示例中，假定呼叫者信息被接收。应当理解，如果没有呼叫者信息被接收，那么处理可如以上的利用图2描述的那样继续。

虽然在以上没有明确表述，但应理解，即使当呼叫者信息被接收时，被叫方也可被提示或者以其它方式被提供机会以请求一些另外的呼叫者信息。

以上在图2～11中描述的步骤/点、消息和有关功能不是按照绝对的时间次序，可以同时或者按与给出的次序不同的次序执行步骤/点中的一些，以及发送消息。例如，当使用推原理时，呼叫方可询问被叫方是否被叫方愿意在应答呼叫建立请求之前接收UCI，以及，如果被叫方愿意接收UCI，那么在呼叫建立请求是待定的同时，呼叫方将向被叫方发送UCI。也可在步骤/点之间或者在步骤/点内实行其它功能，并且，可在例示出的消息之间发送其它消息。例如，在Bob应答呼叫之前，Bob可向Alice发送指示Alice移动她的网络照相机使得Bob更好地看到Alice的文本消息。步骤/点/消息中的一些或步骤/点/消息的部分也可被忽略或者被相应的步骤/点/消息或步骤/点/消息的部分替代。消息仅是示例性的，甚至可包含用于传输相同信息的几个单独的消息。

通过组合上述的功能，可以创建不同的服务或应用。例如，服务提供商可具有服务“安全”、“容易”和“高级”；服务“安全”确保呼叫方是已知方，其用户装置具有某些能力/特征并且按照被叫方已指示他/她想要具有的呼叫者信息的格式而向被叫者提供呼叫者信息；服务“容易”确保提供呼叫者信息，以及服务“高级”允许用户在不同的服务模式中选择，比如与安全对应的一个服务模式、与容易对应的一个服务模式。

图12是例示出对于装置1200的一些单元的简化框图，装置1200被配置为包含呼叫信息单元的用户装置，或者相应的功能，或者被配置为执行以上利用图10或11描述的功能的集中式服务器，或者相应的功能。在例示出的示例中，装置包括用于接收和发送信息的一个或多个接口(IF)1201、被配置为利用用户装置、利用相应的算法1203至少实现这里描述的一个或多个呼叫信息单元功能的处理器1202以及可用于储存呼叫信息单元和/或集中式服务器配置所要求的程序代码和算法的存储器1204。存储器1204也可用于储存其它可能的信息，比如不同的设定或规则或简档。

换句话说，被配置为提供用户装置的装置和/或集中式服务器和/或被配置为提供一个或多个相应功能的任何相应装置是可以为被配置为执行以上利用实施例/示例/实施方式描述的相应装置功能中的一个或多个的任何装置或设备或装备的计算设备，并且它可被配置为执行来自不同的实施例/示例/实施方式的功能。利用装置描述的诸如呼叫方信息单元的单元可以是甚至位于另一物理装置中的单独的单元，该物理装置形成提供功能的一个逻辑装置，或者在相同装置中与另一单元一体化。在其它实施例中，装置中的单元或者单元的功能的部分可位于另一物理装置内。

更确切地说，单元，诸如呼叫方信息单元，以及实体可以是软件和/或软件-硬件和/或固件组件(永久性地记录在诸如只读存储器的介质上或者包括于硬接线计算机电路中)。可通过各种部件实现这里描述的技术，使得实现用实施例/示例/实施方式描述的相应装置/实体的一个或多个功能的装置不仅包含现有技术部件，而且也包含用于实现用实施例/示例/实施方式描述的相应装置的一个或多个功能的部件，并且它可包含用于各单独的功能的单独的部件，或者部件可以被配置为执行两个或更多个功能。例如，可在硬件(一个或多个装置)、固件(一个或多个装置)、软件(一个或多个模块)或者它们的组合中实现这些技术。对于固件或软件，可通过执行这里描述的功能的模块(例如，过程和功能等)实现。软件代码可被储存于任何合适的处理器/计算机可读数据储存介质或存储器单元或制造物品中并且被一个或多个处理器/计算机实行。

被配置为提供用户装置和/或集中式服务器的装置，和/或被配置为提供一个或多个相应功能的任何相应装置可一般包含与存储器和装置的各种接口连接的处理器、控制器、控制单元或微控制器等。一般地，处理器是中央处理单元，但是处理器可以是附加的运算处理器。这里描述的诸如呼叫方信息单元的单元/实体中的每一个或一些或一个可被配置为计算机或处理器或诸如单芯片计算机元件的微处理器，或者被配置为芯片集，至少包含存储器以提供用于算术运算的储存区域以及运算处理器以实行算术运算。以上描述的单元/实体中的每一个或一些或一个可包含一个或多个计算机处理器、专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理器件(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)和/或以这种方式编程以实施一个或多个实施例的一个或多个功能的其它硬件组件。换句话说，以上描述的单元/实体中的每一个或一些或一个可以是包含一个或多个算术逻辑单元、若干特殊寄存器以及控制电路的元件。

此外，被配置为提供用户装置和/或集中式服务器的装置，和/或被配置为提供一个或多个相应功能的任何相应装置可一般包括易失性和/或非易失性存储器，例如，EEPROM、ROM、PROM、RAM、DRAM、SRAM、双浮动栅极场效应晶体管、固件、可编程逻辑等，并且通常储存内容或数据等。一个或多个存储器，特别是当提供媒体流内容的储存时，可以为任何类型(相互不同)，具有任何可能的存储结构，以及，如果要求的话，由任何数据库/高速缓存管理系统管理。存储器还可储存供处理器执行与根据实施例的装置的操作相关的步骤的诸如软件应用(例如，用于单元/实体中的一个或多个)或操作系统的计算机程序代码、信息、数据、内容等。存储器或它的部分可以是例如随机存取存储器、硬盘驱动器或在处理器/装置内或者处理器/装置外面实现的其它固定数据存储器或储存设备，在这种情况下，它可经由现有技术已知的各种部件与处理器/网络节点通信耦合。外部存储器的示例包括可拆卸地与装置连接的可去除存储器、分布式数据库和云服务器。

虽然在以上的示例中假定向被叫方显示关于呼叫方的信息，但是，对于本领域技术人员来说，很显然，可通过使用语音合成器或通过使用触觉输出或者输出不同类型的振动(例如包含每个部分具有不同长度的静音部分和振动部分)以及提供可感知输出的任何其它部件输出信息。

对于本领域技术人员来说，很显然，随着技术进步，可通过各种方式实现发明的概念。本发明及其实施例不限于以上描述的示例，而可在权利要求的范围内变化。

Claims (25)

1.一种用于第二用户装置的方法，所述方法包括：

通过从第一用户装置到第二用户装置的单向连接在第二用户装置中接收消息和实时视频流两者，所述消息指示来自第一用户装置的用于第一用户装置和第二用户装置之间的双向连接的连接建立请求，所述实时视频流包括从第一用户装置的用户实时捕获的实时视频，并且以连续方式将所述实时视频流从第一用户装置发送到第二用户装置，直到建立双向连接、或者确定双向连接不会被建立、或者建立的双向连接结束、或者接收到指示停止捕获和发送的用户输入；

输出所接收的连续视频流并且关于所述连接建立请求指示用户；以及

响应于接收到指示连接建立接受的用户输入，建立双向连接。

2.如权利要求1所述的方法，还包括：

响应于在第二用户装置中接收到指示连接建立请求的所述消息但没有接收到视频流，从第二用户装置发送对于所述实时视频流的请求，所述请求被定向到第一用户装置。

3.一种用于传输关于第一用户装置的用户的信息的方法，所述方法包括：

在第一用户装置中检测指示建立与第二用户装置的双向连接的请求的用户输入；

在检测之后由第一用户装置从第一用户装置的用户实时捕获要通过从第一用户装置到第二用户装置的单向连接在实时视频流中传输的实时视频；

在消息中发送被定向到第二用户装置的连接建立请求；

通过所述单向连接在一个或多个其他消息中从第一用户装置向第二用户装置以连续方式发送实时视频流，直到建立双向连接、或者确定双向连接不会被建立、或者建立的双向连接结束、或者接收到指示停止捕获和发送的用户输入。

4.如权利要求3所述的方法，还包括：

在没有对于所述实时视频流的任何特定请求的情形下连续地发送包含所述连接建立请求的消息和包含所述实时视频流的所述一个或多个其它消息，或者响应于特定请求而发送所述实时视频流。

5.一种用于第二用户装置的方法，所述方法包括：

通过从第一用户装置到第二用户装置的单向连接在第二用户装置中接收来自第一用户装置的包含对于资源的引用的连接建立请求，所述资源包含实时视频流，所述实时视频流包括从第一用户装置的用户实时捕获的实时视频，并且以连续方式将所述实时视频流从第一用户装置发送到第二用户装置，直到建立第一用户装置和第二用户装置之间的双向连接、或者确定双向连接不会被建立、或者建立的双向连接结束、或者接收到指示停止捕获和发送的用户输入；

使用所述引用以建立与所述资源的连接；

输出从所述资源检索的实时视频流；以及

响应于接收到指示连接建立接受的用户输入，建立与第一用户装置的双向连接。

6.如权利要求5所述的方法，还包括：

接收来自第一用户装置的没有对于资源的引用的连接建立请求；

请求更新的连接建立请求，所述更新的连接建立请求包含对于包含内容的资源的引用；

保持连接建立请求为待定的；以及

仅在接收到所述更新的连接建立请求之后，关于所述连接建立请求提醒第二用户装置的用户。

7.如权利要求5或6所述的方法，还包括：

响应于建立与第一用户装置的连接，解除与所述资源的连接。

8.如权利要求5或6所述的方法，还包括：

如果没有接收到对于资源的引用，或者如果使用第一用户装置的第一用户在使用第二用户装置的第二用户的被拦截呼叫者列表中并且对于资源的引用没有被接收到，或者如果第一用户不在第二用户的联系人列表中并且对于资源的引用没有被接收到，那么拒绝所述连接建立请求。

9.如权利要求8所述的方法，其中，拒绝所述连接建立请求是不向第一用户装置转发连接建立拒绝而是向第一用户装置指示所述连接建立请求为待定的软拒绝。

10.如权利要求1或5所述的方法，

响应于接收到指示拒绝所述连接建立请求的用户输入，执行不向第一用户装置转发对所述连接建立请求的拒绝而是向第一用户装置指示所述连接建立请求为待定的软拒绝。

11.一种用于传输关于第一用户装置的用户的信息的方法，所述方法包括：

在第一用户装置中检测指示建立与第二用户装置的双向连接的请求的用户输入；

在检测之后由第一用户装置从第一用户装置的用户实时捕获实时视频，并通过从第一用户装置经由资源到第二用户装置的单向连接以连续方式在实时视频流中将实时视频传输到资源，直到建立双向连接、或者确定双向连接不会被建立、或者建立的双向连接结束、或者接收到指示停止捕获和发送的用户输入；

向连接建立请求添加对于资源的引用；以及

通过从第一用户装置到第二用户装置的单向连接将所述连接建立请求发送到第二用户装置。

12.如权利要求11所述的方法，还包括：

发送没有对于所述资源的引用的连接建立请求；

接收对于资源的引用的请求；

响应于请求，执行所述添加；以及

发送具有对于所述资源的引用的连接建立请求。

13.如权利要求11或12所述的方法，还包括：

建立另外的与提供资源的网络节点的连接以中转所述实时视频；

接收对于所分配资源的引用；

向连接建立请求添加所接收的引用；以及

通过使用所述另外的连接在实时视频流中向所述资源发送从所述用户捕获的所述实时视频。

14.一种用户装置，包括：

用于通过从第一用户装置到所述用户装置的单向连接接收消息以及实时视频流两者的部件，所述消息指示来自第一用户装置的用于第一用户装置和所述用户装置之间的双向连接的连接建立请求，所述实时视频流包括从第一用户装置的用户捕获的实时视频，并且以连续方式将所述实时视频流从第一用户装置发送到所述用户装置，直到建立双向连接、或者确定双向连接不会被建立、或者建立的双向连接结束、或者接收到指示停止捕获和发送的用户输入；

用于输出所接收的连续实时视频流并且关于所述连接建立请求指示用户的部件；以及

用于响应于接收到指示连接建立接受的用户输入而建立双向连接的部件。

15.如权利要求14所述的用户装置，还包括：

用于响应于在用户装置中接收到指示连接建立请求的消息但没有接收到实时视频流而从用户装置发送对于所述实时视频流的请求的部件，所述请求被定向到第一用户装置。

16.一种用户装置，包括：

用于检测指示建立所述用户装置与第二用户装置之间的双向连接的请求的用户输入的部件；

用于从所述用户装置的用户捕获要通过从所述用户装置到第二用户装置的单向连接在实时视频流中传输的实时视频的部件，其中用于捕获的部件响应于用于检测的部件；

用于在消息中发送被定向到第二用户装置的连接建立请求的部件；以及

用于通过所述单向连接在一个或多个其他消息中从所述用户装置向第二用户装置以连续方式发送包括由所述用户装置实时捕获的实时视频的实时视频流，直到建立双向连接、或者确定双向连接不会被建立、或者建立的双向连接结束、或者接收到指示停止捕获和发送的用户输入的部件。

17.一种用户装置，包括：

用于接收来自第一用户装置的包含对于资源的引用的用于第一用户装置和所述用户装置之间的双向连接的连接建立请求的部件，所述资源包含实时视频流，所述实时视频流包含从第一用户装置的用户实时捕获的实时视频，并且以连续方式将所述实时视频流从第一用户装置经由所述资源发送到所述用户装置，直到建立双向连接、或者确定双向连接不会被建立、或者建立的双向连接结束、或者接收到指示停止捕获和发送的用户输入；

用于使用所述引用以建立与所述资源的连接的部件；

用于输出从所述资源检索的实时视频流的部件；以及

用于响应于接收到指示连接建立接受的用户输入而建立与第一用户装置的双向连接的部件。

18.如权利要求17所述的用户装置，还包括：

用于响应于接收到没有对于资源的引用的连接建立请求而请求更新的连接建立请求的部件，所述更新的连接建立请求包含对于包含内容的资源的引用；

用于保持连接建立请求为待定的部件；以及

用于仅在接收到所述更新的连接建立请求之后，关于所述连接建立请求提醒用户装置的用户的部件。

19.如权利要求17或18所述的用户装置，还包括：

用于响应于建立与第一用户装置的双向连接而解除与所述资源的单向连接的部件。

20.一种用户装置，包括：

用于在所述用户装置中检测指示建立所述用户装置与第二用户装置之间的双向连接的请求的用户输入的部件；

用于从所述用户装置的用户实时捕获实时视频的部件，其中用于捕获的部件响应于用于检测的部件；

用于把所捕获的实时视频在实时视频流中通过从所述用户装置经由资源到第二用户装置的单向连接以连续方式发送到资源，直到建立双向连接、或者确定双向连接不会被建立、或者建立的双向连接结束、或者接收到指示停止捕获和发送的用户输入的部件；

用于向连接建立请求添加对于资源的引用的部件；以及

用于通过从所述用户装置到第二用户装置的单向连接发送所述连接建立请求的部件。

21.如权利要求14、15、17或18所述的用户装置，还包括用于响应于接收到指示拒绝连接建立请求的用户输入而执行不是向第一用户装置转发对于所述连接建立请求的拒绝而是向第一用户装置指示所述连接建立请求为待定的软拒绝的部件。

22.一种电信系统，包括：

网络；

包含用于发起连接建立的部件和用于接收连接建立请求的部件的两个或更多个用户装置，

其中，用于发起的部件被配置为：

检测指示建立与第二用户装置的双向连接的请求的用户输入；

在检测之后从第一用户装置的用户实时捕获实时视频，其中，第一用户装置是发起连接建立的用户的用户装置；

把所捕获的实时视频在实时视频流中通过从第一用户装置经由资源到第二用户装置的单向连接以连续方式传输到资源，直到建立双向连接、或者确定双向连接不会被建立、或者建立的双向连接结束、或者接收到指示停止捕获和发送的用户输入；

向连接建立请求添加对于资源的引用；以及

发送所述连接建立请求；

其中，用于接收连接建立请求的部件被配置为：

在从第一用户装置接收包含对于资源的引用的连接建立请求时使用所述引用以建立与所述资源的单向连接；

输出从所述资源检索的实时视频流；

其中，所述引用指示所述系统中的资源，以及其中所述资源由第一用户装置和/或由所述网络中的资源提供。

23.如权利要求22所述的电信系统，其中，所述网络包含被配置为提供所述资源以及/或者转发所述实时视频流的服务器。

24.如权利要求23所述的电信系统，其中，

所述系统被配置为经由所述服务器在所述两个或更多个装置之间传递信令业务和用户业务；以及

所述服务器进一步被配置为响应于对用于待定的连接建立请求的资源的引用的请求，确定所述服务器是否已分配所述资源，以及，响应于所述资源被分配，通过发送对所述资源的引用而响应所述请求，以及，响应于资源没有被分配，转发所述请求。

25.如权利要求22、23或24所述的电信系统，其中，所述两个或更多个用户装置中的一个或多个还包括用于响应于接收到指示拒绝连接建立请求的用户输入而执行软拒绝的部件，在所述软拒绝中，不是向第一用户装置转发拒绝而是向第一用户装置指示所述连接建立请求为待定的。

Images