CN101605050A - 用于基于邻近性来调整应用的方法、装置和系统 - Google Patents

Abstract

提供了用于基于邻近性来调整应用的方法、装置和系统。提供了一种对与第一通信设备和第二通信设备中的至少一个相关联的应用进行调整的方法、系统和装置。判定第一通信设备和第二通信设备之间的邻近性。基于邻近性来对与第一通信设备和第二通信设备中的至少一个相关联的应用进行调整。

Description

用于基于邻近性来调整应用的方法、装置和系统

技术领域

本说明书一般地涉及联网的设备，具体而言涉及用于基于邻近性(proximity)来调整(modulate)应用的方法、装置和系统。

背景技术

诸如IP电话、瘦型客户端(thin client)、PC/膝上型电脑之类的桌面设备经常需要繁重的配置以便与彼此相关联。例如，为了使得用户桌上的IP电话与在同一桌上的桌面PC/膝上型电脑上运行的通信应用相关联，用户或管理员经常需要利用电话的地址或DN、电话的呼叫控制器的地址以及其他细节来配置该应用。用户可能同样需要将PC的IP地址和其他细节手工输入到电话中。这对于一般用户来说是一个复杂的过程，并且既耗时又容易出错。

或者，同样的信息可以被配置到集中式数据库、应用文件等等之中。这导致需要庞大的持续管理工作(尤其是在大型系统中)来在数据随时间变化时保持数据最新。

此外，诸如IP地址之类的一些配置项目可能不时地变化，从而导致关联失败并且应用不正确工作。这导致了另一个持续数据维护问题，以及/或者不时的应用故障以及随此之后的重配置。

美国专利申请US2007/0171098公开了一种系统，利用该系统，关联可以经由以太网链路和IP地址自动地发生，但是该解决方案与使用IP地址的手工关联有着同样的缺陷：IP地址可能不时地发生变化，从而导致关联失败并且应用不正确工作。上述申请还描述了通过一种高级别协议来进行关联，该高级别协议是特定于其中描述的设备的类型的。这种协议所创建的关联缺乏本公开中描述的关联类型的一般性。本公开的技术可以被多种类型的设备用来创建任意类型的关联。

在涉及移动性的情况下，共位(co-located)的设备之间的关系不是长期的(例如，用户可能将膝上型电脑带到会议室或远程通信场所，并且希望或者单独或者与(一个或多个)基于膝上型电脑的应用相联系地临时使用诸如IP电话之类的桌面设施)。每次用户移动时就需要再次进行配置，并且在会话结束时需要取消配置，以便资源能够被回收并且将来的用户无法访问先前用户的信息。同样，这个过程对于终端用户来说是相当繁重的，并且容易出错。如果未能注销则可能会有安全性问题。

发明内容

本说明书的第一方面提供了一种对与第一通信设备和第二通信设备中的至少一个相关联的应用进行调整的方法。该方法包括判定第一通信设备和第二通信设备之间的邻近性。该方法还包括基于邻近性来对与第一通信设备和第二通信设备中的至少一个相关联的应用进行调整。

判定第一通信设备和第二通信设备之间的邻近性可以包括以下各项中的至少一个：判定第一通信设备和第二通信设备是否已建立个域网通信会话，判定第一通信设备和第二通信设备是否能够建立个域网通信会话。

判定第一通信设备和第二通信设备之间的邻近性可以包括：判定第一位置，该第一位置包括第一通信设备的位置；判定第二位置，该第二位置包括第二通信设备的位置；以及判定第一位置和第二位置是否与彼此邻近。

判定第一位置和第二位置是否彼此邻近可以包括：判定第一位置和第二位置之间的距离；将该距离与至少一个阈值距离进行比较，如果该距离小于该至少一个阈值距离或者等于该至少一个阈值距离，则第一位置和第二位置邻近。

该应用可以包括与经由远离第一通信设备和第二通信设备的通信网络在第一通信设备和第二通信设备之间建立通信会话相关联的应用。

判定第一通信设备和第二通信设备之间的邻近性可以包括判定第一通信设备和第二通信设备之间的邻近级别。

对应用进行调整可以包括选择应用的多个模式之一，该多个模式中的每一个与第一通信设备和第二通信设备之间的一个不同的邻近级别相关联。该多个模式还可以包括邻近模式和非邻近模式。多个模式可以包括共位模式、至少一个接近(nearby)模式和非邻近模式。

对应用进行调整可以包括以下各项中的至少一个：在第一通信设备和第二通信设备邻近时，启用第一组预定义的特征；在第一通信设备和第二通信设备邻近时，禁用第二组预定义的特征；去除先前配设(provision)的回呼设定；当在第一通信设备和第二通信设备之间建立通信会话时调整警告特征；以及当发生对建立第一通信设备和第二通信设备之间的通信会话的尝试时，自动建立该通信会话。

对应用进行调整可以包括：当尝试在第一通信设备和第二通信设备之间建立通信会话时，向第一通信设备和第二通信设备中的至少一个发送第一位置和第二位置中的至少一个的指示，从而使得该指示的表示在第一通信设备和第二通信设备中的至少一个处被输出。该指示可以包括与第一通信设备和第二通信设备中的至少一个相关联的用户的标识符。该指示还可以包括描绘第一位置和第二位置中的至少一个的地图。

对第一位置的判定和对第二位置的判定中的至少一个是基于以下各项中的至少一个的：链路层数据、GPS数据、RF三角测量数据、用户数据、无线接入点数据和存储在数据库中的位置数据。

判定第一位置和第二位置是否彼此邻近可以包括判定第一位置和第二位置是否共位。判定第一位置和第二位置是否共位可以包括判定第一位置和第二位置是否共同位于以下各项中的至少一个之中：同一物理域、同一房间、同一楼层、同一建筑物、同一城市地址。

本说明书的第二方面提供了一种用于对与第一通信设备和第二通信设备中的至少一个相关联的应用进行调整的计算设备。该计算设备包括能够用于与第一通信设备和第二通信设备通信的通信接口。该计算设备还包括与通信接口通信的处理单元，该处理单元能够用于：判定第一通信设备和第二通信设备之间的邻近性；以及基于邻近性来对与第一通信设备和第二通信设备中的至少一个相关联的应用进行调整。

该计算设备还可包括路由器和交换机中的至少一个，路由器和交换机中的每一个能够用于在第一通信设备和第二通信设备之间建立通信会话。

本说明书的第三方面提供了一种对与第一通信设备和第二通信设备中的至少一个相关联的应用进行调整的方法。该方法包括判定第一通信设备和第二通信设备之间的邻近级别。该方法还包括通过选择应用的多个模式之一，来基于邻近级别对与第一通信设备和第二通信设备中的至少一个相关联的应用进行调整，该多个模式中的每一个与第一通信设备和第二通信设备之间的一个不同的邻近级别相关联。

附图说明

参考以下附图来描述实施例，附图中：

图1示出了根据非限制性实施例的用于关联联网的通信设备的系统；

图2示出了根据非限制性实施例的用于关联联网的通信设备的消息图；

图3示出了根据非限制性实施例的用于关联联网的通信设备的消息图；

图4示出了根据非限制性实施例的用于关联联网的通信设备的消息图；

图5和图6示出了根据非限制性实施例的用于对与第一通信设备和第二通信设备中的至少一个相关联的应用进行调整的系统；以及

图7示出了根据非限制性实施例的对与第一通信设备和第二通信设备中的至少一个相关联的应用进行调整的方法。

具体实施方式

图1示出了根据非限制性实施例的用于关联联网的通信设备的系统100。如图1所示，可能存在若干个终端用户桌面，其中每一个上有多种共位的通信和/或计算设备可用，例如IP电话110、个人计算机(PC)或膝上型计算机115，或者“瘦型客户端”设备120。(本领域的技术人员将会理解，“瘦型客户端”指的是用户接口设备的集合，其由瘦型客户端处理器设备驱动，而实际的应用运行在系统中别处的“瘦型客户端服务器”125中。从用户的角度来看，瘦型客户端129等同于个人计算机，只不过应用实际上是越过数据网络130在远程运行的，只有应用的呈现是由瘦型客户端设备120及其外设(例如显示器、键盘、鼠标等等)在本地生成的)。

一些瘦型客户端实现方式还利用了在被插入到瘦型客户端设备120中时向瘦型客户端服务器125标识用户的个人身份卡135、存储密钥等等。这种身份卡135还可以结合PC/膝上型电脑115、其他计算设备或者诸如IP电话110之类的通信设备使用。

这些共位的桌面计算和/或通信设备(即，瘦型客户端设备120、IP电话110和/或PC/膝上型电脑115)一般通过诸如以太网或无线LAN之类的某种链路级连接而连接到诸如路由的IP网络之类的数据网络130。为了简单起见，该连接被示为到网络接入层2(L2)交换机140的有线以太网连接，该网络接入层2(L2)交换机140进而又将计算和/或通信设备连接到数据网络130。存在多种进行这些连接的方式，值得注意的是，每个通信设备可以单独连接到网络基础设施(桌面B和D)，或者诸如PC/膝上型电脑115或瘦型客户端120之类的一些通信设备可以通过诸如包括嵌入或附接的L2交换机/网桥145的IP电话(例如IP电话110)之类的其他设备来连接(桌面A和C)。此外，这些计算和/或通信设备可以在同一IP子网上也可以不在同一IP子网上：也就是说，它们可以在不同的第2层VLAN上，并因此无法通过广播来直接联络到彼此。应当理解，通过数据网络130通信的计算设备包括使能此通信的通信设备。另外，通信设备一般将包括用于对与数据网络130交换的信号进行处理的计算设备。因此，在以下说明书中，除非另有指明，否则术语“通信设备”和“计算设备”一般被认为是可互换的。例如，在以下描述的一些区域中，可能对主要充当通信设备的IP电话110和可能主要充当计算设备的PC/膝上型电脑115或者瘦型客户端120进行区分。另外，对设备的提及应当被理解为一般性地指通信和/或计算设备。

在许多情况下，在与通信设备关联过程有关的网络中还存在服务器。值得注意的是某种形式的关联数据库150，用于跟踪哪些通信设备被关联、其地址和唯一ID信息以及所需要的任何补充信息。在IP电话的情况下，在网络中经常有一个或多个呼叫控制器155(即，一个或多个服务器)。在这些实施例中，呼叫控制器155可以执行关联任务。在桌面上的瘦型客户端的情况下，在网络中还将有(一个或多个)瘦型客户端服务器125。此外，可能存在一个或多个执行关联任务以及可能执行其他应用的应用服务器160。注意，这些服务器是逻辑实体，因此它们在物理上可能彼此集成或者与网络中的其他服务器集成，也可能在物理上不彼此集成或者与网络中的其他服务器集成。还要注意，虽然所示出并在下文中描述的数据网络130包括路由的IP网络，但是这并非必要的-也可以使用其他协议，并且简单的LAN就足够了-只要通信设备和服务器能够通过联网基础设施联络到彼此即可。

为了使得应用以统一的方式利用共位的通信和/或计算设备，共位的设备需要与彼此相关联：也就是说，系统100需要知道这些设备中的哪些在物理上位于一处。希望在关联的通信设备上执行某种协同的动作的应用还必须知道(一般来说)每个设备的网络地址和唯一标识符。

此外，这些通信和/或计算设备中的一些或全部在性质上可以是移动性的(例如，膝上型电脑、PDA、移动电话等等可以很容易地移动位置)，并且通信设备可以与特定用户永久关联，也可以不与特定用户永久关联(例如，“桌面”比如在远程工作场所或者自动呼叫分配(ACD)代理轮班中可能在各个时间被许多用户所共享，或者可以是会议室或者其他共享的设施)。通信设备还可能因为其他原因而动态地来去，例如被断电或者断开连接，或者新的通信设备被插入(例如，插入视频相机以添加到会议)。因此，设备关联需要能够被动态地检测、建立、更新和取消。

诸如链路层发现协议(LLDP，IEEE 802.1AB-2005)或LLDP-媒体端点发现(LLDP-MED，ANSI/TIA-1057)之类的标准链路层(或第2层)协议向在网络链路的每一端处物理附接的“邻居”设备提供了相当多的信息。所提供的信息包括(但不限于)邻居设备的IP地址和MAC地址、设备能力(电话、网络元件等等)、设备名称和描述、清单(inventory)描述(厂商、牌子、型号、软件/固件/硬件修订，等等)。该信息对于使得在这些设备中运行的应用或者在系统中别处代表这些设备运行的应用能够与彼此相关联是非常有用的。

在IP电话的情况下，常常存在这样的情况，即计算/通信设备(即，PC/膝上型电脑115或瘦型客户端120)例如经由简单的L2交换机/网桥145被直接地物理插入到IP电话110中，所述L2交换机/网桥145可以嵌入在IP电话110中或者连接到IP电话110。这使得电话应用能够在第2层协议消息在附接的计算/通信设备与网络接入交换机基础设施(即，网络接入L2交换机140)之间的路途上经过IP电话110时“嗅探”(sniff)到这些第2层协议消息。在包含嵌入式L2交换机/网桥145(或者连接到L2交换机/网桥145)的计算/通信设备(或者任何其他设备)的情况下也可以想象类似的系统配置，从而允许它们也收集第2层协议中包含的信息，其他设备通过所述L2交换机/网桥145来连接。此外，这些连接配置中的设备的任何一个或者全部可以主动地通过链路向彼此发送第2层协议(而不是仅仅被动地将其从上游接入交换机传递)，从而允许该组共位的通信设备直接通信。

在IP电话110以及桌面PC/膝上型电脑115或瘦型客户端120两者处收集的该信息随后可以被发送到整个系统中的别处，例如发送到呼叫控制器155、共享数据库(例如关联数据库150)或者应用服务器160，在该处它可以被比对(collate)，因此在IP电话110(或者呼叫控制器155)中运行的有关应用可以被自动地配置以关于相应的计算/通信设备的所需信息，反之亦然。或者，该信息也可以在网络基础设施处(例如在网络接入第2层交换设备处)被搜集，并且从该处被收集，或者作为自动通知被发送到所涉及的其他元件。

此外，特定的物理位置信息也可以与通信设备相关联，例如城市地址(城市/街道地址/楼层/房间号)、基于坐标的地理位置(纬度/经度/高度)，或者诸如接线图(wiremap)墙壁插孔号之类的其他本地相关索引。该信息可以(例如)作为网络接入交换机配置的一部分(例如，作为LLDP-MED的一部分)获得、通过更高层的协议(例如动态主机配置协议(DHCP)、支持HTTP的位置递送(HELD))获得、通过设备中的定位技术(例如，GPS、“信标”等等)获得、通过例如经由预先填充的接线图数据库170之类的映射过程来间接获得，或者通过对设备中的一个或多个的间接配置来获得。在该信息还可以与通信设备相关联的情况下，位置还可以被应用用作找到特定位置处的那组共位的计算和/或通信设备的索引。

利用提供的这个信息和其他协议设施，可以实现允许自动发现设备关联的一组方法。利用LLDP-MED作为参考协议，在下文中单独描述每种方法。但是，这些方法并不被该参考协议过度限制，其他协议也在本说明书的范围之内。

作为此关联的示例性应用，描述了“单次登入登录(single sign-inlogon)”，其中用户可以登录到一个通信设备(例如PC/膝上型电脑115或IP电话110)，结果也被自动地登录到其他共位的通信设备中。其非限制性示例可以是将瘦型客户端ID卡135插入到瘦型客户端120中，结果也被关联的IP电话110所“共用(hotdesk)”，从而允许用户立即开始使用两个通信设备，而无需进一步的动作。但是，该应用不应当被认为是过度限制的，可以受益于设备关联的自动发现的其他应用(其中一些在下文中论述)也在本说明书的范围之内。

一般地，关于所使用的协议、特定的系统配置、系统组件在其他组件内的嵌入以及自动关联过程所使能的特定应用，有许多可能的变体。因此，以下示例并不想要过度限制，关于所描述的设备关联的自动发现的方法的变体处于本说明书的范围之内。

经由IP电话的链路层发现

现在参考图2论述关联耦合到数据网络的至少两个通信设备的方法，图2示出了根据非限制性实施例的用于关联联网的通信设备的消息图。在此方法中，假定计算/通信设备(PC/膝上型电脑115或瘦型客户端120)经由嵌入在IP电话110中的L2交换机/网桥145连接到数据网络130。在以下论述中进一步参考图1的桌面A场景。也描述了使用PC/膝上型电脑115的作为替换的桌面C场景。

在此实施例中，LLDP-MED在桌面计算设备(瘦型客户端120或PC/膝上型电脑115)上、在IP电话110上、以及在网络接入L2交换机140上都生效。

步骤201。利用此协议，计算设备和IP电话110都向网络接入L2交换机140通告其IP地址和MAC地址，并且网络接入L2交换机140向桌面设备通告回其地址和端口MAC(但是，后者对此场景来说是无关紧要的)。附加的补充信息也可以被发送，例如清单信息。

步骤201a。由于IP电话110的嵌入式L2交换机/网桥145被动地处于来自计算设备的消息传递的路径中，因此它能够“嗅探”该消息传递并且提取计算设备的IP地址和MAC地址以及协议中提供的任何补充信息。

步骤202。关于附接的计算设备的IP电话邻居信息与任何补充信息一起在“Neighbor_info”消息中被传递到IP电话110的注册呼叫控制器155。

步骤203。由于IP电话110的呼叫控制器155已经知晓IP电话的IP地址和MAC地址(或者其他唯一ID，参见下文)，因此它现在能够将其与计算设备的数据进行比对，并且向关联数据库150发送关联消息或等同物，该关联消息或等同物包含计算设备MAC地址到IP电话MAC地址(或者其他唯一标识符)的映射，并且还包含计算设备以及IP电话的IP地址(“Associate”)。该关联被存储在关联数据库150中，以便应用在以后使用。此时，设备关联阶段完成，物理设备关联被建立，并且可以被应用用来进行更高级别的动作。因此，呼叫控制器155通过发送关联消息而有效地触发了设备之间的关联。

步骤204。在之后的某个时刻，用户将其标识卡135插入到计算设备中，或者以某种其他方式登录到其上(例如，通过提供登录证书，比如用户名和口令)。

步骤205。在包括瘦型客户端120的实施例中，这可能导致用户登录消息或者等同物被发送到瘦型客户端服务器125，该用户登录消息或等同物包含用户的用户ID以及被访问的瘦型客户端120的MAC地址和/或IP地址(“Login”)。结果，用户被登录到瘦型客户端120中，并且可以开始使用它。

步骤206。作为登录到瘦型客户端120的结果，指示出发生登录的事件可以被从瘦型客户端服务器125发送到负责向同一桌面上的相关联IP电话110发起自动登录应用的应用服务器160(“Login_event”)。该消息可包含用户的用户ID、瘦型客户端MAC(或其他唯一ID)以及可能的其他数据(例如瘦型客户端IP地址)，等等。

步骤207。在应用服务器160上运行的自动登录应用随后查询关联数据库150，传递计算设备MAC(或其他唯一id)，并且可能传递用户的用户ID或其他有关数据，以作为关键字(“Association_Query”)。

步骤208。关联数据库150返回先前在以上步骤203中存储的计算设备MAC到IP电话MAC的映射(或者其他唯一ID对)以及计算设备用户ID到等同的IP电话用户ID(例如用户的个人DN(“UserDN”))的映射(“Association_Query_response”)。与一个或两个关联的设备有关的其他补充数据也可以被返回。

步骤209。自动登录应用随后向IP电话的呼叫控制器发送控制消息(或者，如果可行的话，直接向电话发送控制消息)，请求用户以共用桌(hotdesk)的方式被登录到关联的IP电话中，传递IP电话MAC地址(或者物理设备的其他唯一ID)、呼叫控制器所知晓的用户ID(例如，用户的共用桌DN，或者其他唯一用户ID)、以及完成用户到IP电话的登录所需的任何其他补充信息(“Phone_login”)。

步骤210。用户被自动登录到关联的IP电话110中，并且可以开始使用它。

变体1：桌面C场景

在计算设备包括PC/膝上型电脑115的实施例中(即，桌面C场景)，对图2的消息图的小修改可以如下进行：

·所有相应的消息将会由PC/膝上型电脑115直接发送和接收，而不是由瘦型客户端服务器125发送和接收。

·被描述为瘦型客户端110和瘦型客户端服务器125之间的消息将改为在PC/膝上型电脑115内部。

变体2：首先登录到IP电话110

在用户首先登录到IP电话110而不是计算设备的实施例中，对图2的消息图的小修改可以如下进行：

在步骤204和205：用户在IP电话110处登录(或者插入卡135，等等)。

在步骤206：在成功登录后，呼叫控制器155向应用服务器160发送包含IP电话设备ID(Phone MAC)和用户ID(UserDN)的Login_event。

在步骤207-208：应用服务器160利用IP电话设备ID(Phone MAC)和用户ID(UserDN)作为关键字查询关联数据库150，并且在响应中接收瘦型客户端设备ID(TC MAC)和用户ID(UserID)。

在步骤209-210：应用服务器160向瘦型客户端服务器125发送包含用户ID和瘦型客户端MAC的登录消息，从而将用户登录到瘦型客户端120中。

变体3：计算设备在IP电话110登录后被连接

在计算设备在IP电话110已被登录之后被连接(或者等同地，被通电、应用被启动等等)的实施例中，希望基于先前对IP电话110的有效登录来对计算设备发起设备关联和推迟的登录。在这些实施例中，可以使用对上述方法的以下修改。注意，为了发生设备关联，实际上并不需要IP电话110被登录(即，下面可以不需要或者可以推迟步骤207-210，而设备关联仍将发生)：

在步骤201-202：来自计算设备的LLDP-MED、随后对邻居的检测、以及向呼叫控制器155的Neighbor_Info的发送被推迟，直到计算设备连接为止。

在步骤203：被Neighbor_Info所触发，呼叫控制器155像以前那样向关联数据库150发送“Associate”消息，进而触发/建立设备关联。

在步骤206：呼叫控制器155可以向应用服务器160发送推迟的Login_event，如上所述。或者，Login_event可以更早(例如在用户登录到IP电话110时)被发送，并且Login_event被存储在应用服务器160处或者适当的数据库中，应用服务器160基于检测到作为步骤203处的上述Associate消息的结果在关联数据库150中进行设备之间的新关联而触发步骤207-210。在后一种替换实现方式中，存在若干种用于所述对新关联的检测的方法，包括但不限于应用服务器160轮询关联数据库150或者关联数据库150自发通知应用服务器160。

在步骤207-210：像用户首先登录到IP电话110的实施例中那样进行。

变体4-计算设备应用在IP电话登录后被启动：

作为关于同一方法的另一种变体，如果计算和/或通信设备被连接(或者等同地，被通电)，但最初没有要求设备关联的应用在运行，那么链路层协议可能尚未在所涉及的一个或多个设备上启动。一些链路层协议(例如LLDP)可以从应用层启动；因此应用可以在必要时直接或间接地启动设备关联过程。这可以在IP电话110(或者PC/膝上型电脑115或瘦型客户端120)被登录之前或之后进行。这可能是(作为非限制性示例)为了使应用能够将IP电话110用作其通信过程的一部分，或者作为某个其他目的(流音乐、文本到话音，等等)的附属。如果应用需要的话，也可以如前所述发起推迟的登录。以下修改后的方法在这些情况下是可能实现的。

变体4a-计算设备联络(或包括)关联数据库150。

在应用启动时，计算设备(即，PC/膝上型电脑115或瘦型客户端120)可以联络呼叫控制器155以获得对关联数据库150的访问，以请求它被告知以任何Neighbor_Info通知，或者可以开始为了相同的目的轮询关联数据库150(可能进行过滤，以仅限于包含其设备ID或IP地址作为info的一部分的那些)。应用随后在计算设备处启动链路层协议。在这些实施例中，可以采用以下变体：

在步骤201-203。像先前的变体(变体3)中那样进行，但是在一些实施例中，链路层协议可以被应用在计算设备(即，PC/膝上型电脑115或瘦型客户端120)处启动。

在步骤204-210。如果应用正在利用推迟的登录，则步骤204-210像先前的变体(变体3)中那样进行。否则，或者此外，与步骤207-208中相似的消息传递可以被应用用来查询关联数据库150以获得先前在上述步骤203中存储的IP电话MAC(或其他唯一ID对)，以及计算设备用户ID到等同的IP电话用户ID(例如用户的个人DN(“UserDN”))的映射。应用随后使用这些ID来与呼叫控制器155交互(或者直接与IP电话110交互)以控制设备。

变体4b-计算设备直接使用链路层协议。

或者，计算设备可以如上所述地发起链路层协议，并且直接使用从自IP电话110向计算设备发送的链路层消息中获得的IP电话MAC和/或IP地址(或者其他唯一标识符)。发起可能是计算设备启动或连接的结果，或者是应用启动的结果。此实施例假定IP电话110也在从链路的它的这一端向附接的计算设备(PC/膝上型电脑115或瘦型客户端120)发送链路层协议(此消息传递未在图2中示出)。应用随后可以使用这些获得的ID来与呼叫控制器交互(或者直接与电话交互)以控制设备、发起登录或者用于其他目的。

在变体4b的实施例中，计算设备可以是直接关注链路层协议的PC/膝上型电脑115，而在其他实施例中，PC/膝上型电脑115还可以包括应用服务器160和/或关联数据库150，因此在这些元件之间传送的消息在PC/膝上型电脑115内部发生。在变体4b的另一个实施例中，计算设备可以包括直接关注链路层协议的瘦型客户端120，并且将所获得的ID和/或其他信息传输给相关的瘦型客户端服务器125，而在其他实施例中，瘦型客户端服务器125还可包括应用服务器160和/或关联数据库150，因此在这些元件之间传送的消息在瘦型客户端服务器125内部发生。

虽然所描述的实施例在各处以MAC地址作为设备标识符，但其他类型的设备标识符也在这些实施例的范围之内，只要所使用的设备标识符唯一于特定的物理通信/计算设备并且是不变的即可。在一些实施例中，每个通信/计算设备可以使用不同的设备标识符类型。对此的进一步论述出现于下文中。

另外，虽然所描述的实施例假定用户ID在计算设备子系统(瘦型客户端110/瘦型客户端服务器125，或PC/膝上型电脑115)和通信子系统(呼叫控制器155/IP电话110)两者之中与同一用户相对应地存在，并且这些用户ID可以被互相比对，但用户ID的具体格式并不重要，只要它们唯一于特定用户并且是不变的即可。用户ID在每个子系统中可以是相同的，或者是不同的。存在许多实现对每个子系统中的用户ID的比对的方式，包括但不限于：

·用户ID使用相同的方法，例如，简单的、唯一的用户名字符串、统一的user_id/口令对、SIP URI，在这种情况下不需要比对。

·两个用户ID类型都可预先存在于单独的数据库中(例如，在公司的LDAP服务器中)，一个以另一个为关键字，或者两者以共同的关键字为关键字，例如利用用户名作为关键字来为该用户提取相应的计算子系统user_id/口令以及通信子系统目录号(DN)。

·可能存在算法关系，例如将用户名字符串变换成SIP URI和/或计算机系统user_id，或者从一个直接形成另一个。

·用户ID之间的比对可以被配置到关联数据库150中。

在步骤203、207和208：用户ID和设备ID的关联可以被分开存储在关联数据库150中，而不是如图所示被存储为一个记录。另外，可能存在用于每种关联类型的不同数据库和/或服务器。在这些实施例中，步骤203保持相同(关联设备ID)，而步骤207-208将为设备ID关联数据和用户ID关联数据中的每一个包括单独的查询/响应对。除了消息传递的增加以及数据存储的分布不同之外，这对于最终结果来说没有什么差别。

在许多情况下，所涉及的设备可能可获得物理位置数据，例如通过使用GPS或其他定位测量技术、通过链路层或更高层协议交互(例如，通过链路层发现协议-媒体端点发现(LLDP-MED)、DHCP或HELD协议)、或者通过直接配置来获得。该信息可以采取以下形式：城市地址(城市/街道地址/楼层/房间号)、基于坐标的地理位置(纬度/经度/高度)、或者其他本地相关索引(例如接线图墙壁插孔号)，等等。在可以获得这种信息的情况下，利用诸如这里描述的Neighbor_Info消息之类的消息传递，该信息也可以被添加到与处于同一物理位置处的一组设备相关联的关联数据库150中。在可以为至少一个关联的设备获得这种信息的情况下，该信息随后可被应用用作索引来判定和访问处于特定位置处的某组设备、判定某组设备处于(或者不处于)同一位置，或者判定处于特定位置处的一组全都关联的设备。

在链路层协议(例如LLDP-MED清单数据)中提供的或者被直接配置到通信设备中的补充数据可以被直接用作设备关联过程的一部分(例如，利用该补充数据中包含的唯一设备ID，例如设备DN或资产号)，或者可以被用于修改关联过程(例如，只允许特定牌子/型号的、或特定软件版本的、已知资产号(asset number)等等的设备的关联)。这在以上参考图2描述的消息传递中没有示出，但是通过在Neighbor_Info、Associate、Association Query/Association_Query_response或其他消息传递中传递此补充数据，它将是一种直观的扩展。

关于所描述的消息传递的其他变体可以包括但不限于：

·IP电话110可以直接地而不是经由呼叫控制器155与关联数据库150交互以建立设备关联(步骤202-203)；

·IP电话110可以直接地而不是经由呼叫控制器155与应用服务器160交互以建立设备关联(步骤202-203)和/或发起用户登录(步骤209-210)；

·通知消息(例如步骤202、205和206)可以按预订/通知(Subscribe/Notify)模式来实现，而不是实现为单向自发事件(例如实现为SIP预订/通知消息)。

与先前描述的一般系统描述中一样，由于所描述的每个实体只是逻辑上的，因此功能可以被任意组合。例如，应用服务器160和/或关联数据库150功能可以被集成在瘦型客户端服务器125中，呼叫控制器155可以(实质上)被集成在IP电话110(例如SIP电话设备)中，等等。

经由计算设备的链路层发现

现在描述链路层发现经由通信/计算设备(即PC/膝上型电脑115或瘦型客户端120)发生的实施例。在这些实施例中，假定IP电话110经由桌面通信/计算设备中的嵌入或者附接的L2交换机/网桥(类似于L2交换机/网桥145)连接到网络(即，交换机/网桥与PC/膝上型电脑115或瘦型客户端120相集成)。此场景基本上是先前描述的实施例的逆反，差别在于IP电话110的连通性是经由桌面通信/计算设备的，而不是相反。(注意此配置的连通性在图1中未具体示出，而是直观的扩展)。

在此方法中，经由IP电话110的链路层发现的步骤相对于图2来说大部分没有改变，但有以下例外：

在步骤201，LLDP-MED经由桌面通信/计算设备中的L2交换机/网桥(或者与桌面通信/计算设备相关联的L2交换机/网桥)被传递到网络。

在步骤201a。LLDP-MED在桌面通信/计算设备处被“嗅探”。

在步骤202。通信/计算设备的关于附接的IP电话110的邻居信息可以被传递到除呼叫控制器155之外的服务器(例如，直接传递到应用服务器160)。在瘦型客户端120的情况下，瘦型客户端服务器125将传递该信息。在PC/膝上型电脑115的情况下，PC/膝上型电脑115将直接传递该信息。在其他实施例中，例如在计算设备能够为了交互的目的而访问呼叫控制器中的设施的实施例中，将仍像先前描述的那样与呼叫控制器155发生交互。

在步骤203，关联的比对可以在除呼叫控制器155之外的服务器中进行，例如在应用服务器160中进行，导致Associate消息被从该服务器发送到关联数据库150，从而建立设备关联。

在步骤204，在IP电话登录的情况下，标识卡135被插入到IP电话110中。或者，在计算设备登录的情况下，标识卡135被插入到瘦型客户端120或PC/膝上型电脑115中。但是，如前所述，可以出现其他登录方法。

在步骤205，在IP电话登录的情况下，这可能导致用户Login消息或者等同物被发送到呼叫控制器155，结果，用户被登录到IP电话110中并且可以开始使用它。或者，在计算设备登录的情况下，这可能导致从瘦型客户端120发送到瘦型客户端服务器125的Login消息或者等同物，或者PC/膝上型电脑115内部的动作，使得用户被登录到计算设备中。

在步骤206，在IP电话登录的情况下，作为登录的结果，Login_event消息等等可以被从呼叫控制器155发送到应用服务器160。或者，在计算设备登录的情况下，作为登录的结果，Login_event消息等等可以被从瘦型客户端服务器125(在瘦型客户端实施例中)或者直接从PC/膝上型电脑115(在PC/膝上型电脑实施例中)发送到应用服务器160。

在步骤207，在IP电话登录的情况下，在应用服务器160上运行的自动登录应用随后可以查询关联数据库150，将IP电话MAC(或者其他唯一设备ID)以及登录用户的通信子系统用户ID作为关键字传递。或者，在计算设备登录的情况下，计算设备MAC(或其他唯一设备ID)以及登录用户的计算子系统用户ID可以作为关键字被传递。

在步骤208，关联数据库150返回IP电话MAC到计算设备MAC的映射(或者其他唯一ID对)以及IP电话用户ID到等同的计算设备用户ID的映射。

在步骤209，在IP电话登录的情况下，应用服务器160上的自动登录应用随后可以向瘦型客户端服务器125(在瘦型客户端实施例中)或者向PC/膝上型电脑115(在PC/膝上型电脑实施例中)发送控制消息，请求用户被登录到关联的计算设备中，传递计算设备MAC地址(或其他唯一设备ID)以及计算子系统已知的用户的用户ID(例如网络用户名/口令)。或者，在计算设备登录的情况下，控制消息可以被发送到呼叫控制器155，请求用户被登录到关联的IP电话中，传递IP电话MAC地址(或其他唯一设备ID)以及通信子系统已知的用户的用户ID(例如，用户的DN)。

在步骤210，在IP电话登录的情况下，用户被自动登录到关联的计算设备中，并且可以开始使用它。或者，在计算设备登录的情况下，用户被自动登录到关联的IP电话中，并且可以开始使用它。

经由网络通知的链路层发现

现在转到链路层发现经由网络通知而发生的实施例，假定通信/计算设备(PC/膝上型电脑115或瘦型客户端120)可以经由IP电话110的嵌入式L2交换机/网桥145连接到网络，也可以不经由IP电话110的嵌入式L2交换机/网桥145连接到网络，反之亦然。当不经由嵌入式L2交换机/网桥连接到网络时，通信/计算设备则各自连接到网络接入L2交换机140上的不同端口(图1的桌面B和D的场景)。当连接在不同的接入端口上时，假定有某种方法可用于例如利用网络接入L2交换机140可访问的接线图数据或位置数据来知晓到这些端口的连接实际上终止于同一物理位置处(例如，在同一墙壁插孔处，在同一会议室中，等等)。例如，在这些实施例中的一些中，接线图数据可被存储在网络接入L2交换机140处，而在其他实施例中，接线图数据可被存储在接线图数据库170处，并且接线图数据由网络接入L2交换机140通过数据网络130经由查询来检索。现在参考图3描述这些实施例，该图示出了根据非限制性实施例的用于关联联网的通信设备的消息图。另外使用桌面A场景来对图1进行参考，该场景中瘦型客户端120经由IP电话嵌入式L2交换机/网桥145连接到网络接入L2交换机140。使用不同的连通性和/或PC/膝上型电脑115的桌面B、C和D场景的实施例在下文中也有描述。

在此方法中，设备关联可以如下进行(参考图3的消息图)：

步骤301。与以上描述的步骤201类似。

步骤302。由通信/计算设备到网络的连接以及随后网络接入L2交换机140对链路上的LLDP-MED信息的检测(或者等同地，计算设备到IP电话嵌入式L2交换机/网桥145(其仅仅传递消息)的连接)所触发，状态事件的网络链路变化(“Notity_link_change”)消息被从网络接入L2交换机140生成到应用服务器160，其携带着网络接入L2交换机145端口ID和所连接的设备的IP地址和MAC地址。对于每个所连接的通信设备发生类似的消息传递，该消息传递携带着通信设备的个体IP地址和MAC地址，以及相同的网络接入L2交换机端口ID。在先前步骤中由LLDP-MED消息传递携带的任何补充数据也可以被携带于通知事件中。

步骤303。由于Notify_link_change消息来自同一端口ID(或者等同地，对于在该单个端口ID上的所有附接的设备，通知作为单个消息到达)，因此应用服务器160现在能够将IP电话数据与计算设备数据相比对，并且向关联数据库150发送关联消息(“Associate”)或等同物，该消息或等同物包含计算设备MAC地址到IP电话MAC地址(或其他唯一标识符)的映射，并且还包含计算设备的IP地址以及IP电话110的IP地址。从先前的步骤搜集的任何补充数据也可以被携带。此关联被存储在关联数据库150中，以便应用在以后使用。因此，应用服务器160通过发送关联消息而有效地触发了设备之间的关联。设备关联阶段完成。

步骤304-310基本上类似于上述的步骤204-210。

关于参考图3描述的消息传递的其他变体可以包括但不限于：

·步骤302可以使用多个消息(对于每个附接的设备有一个，如图所示)，或者单个消息(通知是针对所有附接的设备的)；

·步骤302中使用的通知协议可以是SNMP(在LLDP-MED中定义)，或者另一种适当的协议。

·步骤302可以在多个步骤中例如通过从网络接入L2交换机到应用服务器160的更原始的通知来实现，例如使用SNMP网桥MIB(管理信息库)等等的简单端口LinkUp/LinkDown通知(例子)，该通知随后被应用服务器160用来触发对关于所通知的(一个或多个)端口的更具体数据的一个或多个查询。更具体的查询例如可以使用LLDP-MED定义的SNMPMIB或其他类似的查询格式。

在不同端口上连接的设备的变体

在关于以上方法的其他变体中，计算设备(瘦型客户端120或PC/膝上型电脑115)和IP电话110可以连接到不同的网络接入L2交换机端口(即，不经由任何一者之上的嵌入式L2交换机/网桥连接，如图1的桌面B或D中所示)。在此情况下，于是以上步骤303的比对可以使用若干种方法中的任何一种来比对信息。例如：

·步骤303a。应用服务器160可以包含或者能够访问接线图数据库170，该接线图数据库170包含接入交换机端口ID到与端口的终止有关的物理位置数据(例如到房间号、墙壁插孔标识符等等)的映射。于是比对可以基于匹配的终止位置。注意，在许多应用中，能够判定端口ID对应于同一物理位置就足够了，不一定要判定该特定位置是什么。另外，在使用非特定索引(例如墙壁插孔标识符)并且标识符不同的情况下，可以通过对接线图数据库170执行进一步的查询，例如通过查询每个墙壁插孔标识符到每个的物理位置的映射，然后匹配所返回的物理位置信息，来判定这些标识符确实实际上映射到了同一的物理位置。一旦进行了这种比对，就可以形成并发送从应用服务器160到关联数据库150的Associate消息。

步骤303b。网络接入L2交换机140可以被配置为包含与每个端口相关联的物理位置信息(例如由LLDP-MED定义)，例如给出地理位置坐标、城市地址坐标、房间号、墙壁插孔标识符，等等。该位置信息随后可被应用服务器160在接收到通知后查询(例如利用LLDP-MED所使能的SNMP)，或者等同地，作为(一个或多个)通知的一部分被直接提供。于是比对可以基于匹配的网络接入L2交换机位置数据。

与以上参考图2描述的实施例相类似的、关于这些实施例的其他变体处于本说明书的范围之内。这些变体包括但不限于：

·诸如呼叫控制器155、瘦型客户端服务器125或PC/膝上型电脑115之类的任何网络元件都可充当(或者包括)应用服务器160和/或关联数据库150。

·被示为自发事件的消息(例如消息301、302)中的任何一个或全部都可以实现为预订/通知交互。

·诸如用户ID之类的补充信息也可以被直接携带于链路层协议消息传递(消息301)中，以及携带于链路变化通知(消息302)和Associate消息(303)中，从而利用在设备关联时有效的关联用户数据来更新关联数据库150。

经由网络查询的链路层发现

现在描述链路层发现经由网络查询而发生的实施例。在这些实施例中的一些中，像图1中的桌面场景A和C中那样，通信/计算设备(例如PC/膝上型电脑115或瘦型客户端120)经由IP电话110的嵌入式L2交换机/网桥145连接到网络(或者反之)。在其他实施例中，像桌面场景B和D中那样，每个设备连接到网络接入L2交换机140上的不同端口。当连接在不同的接入端口上时，假定有一种方法可用于例如利用网络接入L2交换机140可访问的接线图数据或位置数据来知晓到这些端口的连接实际上终止于同一物理位置处(例如，在同一墙壁插孔处)。例如，在这些实施例中的一些中，接线图数据可被存储在网络接入L2交换机140处，而在其他实施例中，接线图数据被存储在接线图数据库170处，并且接线图数据由网络接入L2交换机140通过数据网络130经由查询来检索。现在参考图4描述这些实施例，该图示出了根据非限制性实施例的用于关联联网的通信设备的消息图。另外使用桌面A场景来对图1进行参考，该场景中瘦型客户端120经由IP电话嵌入式L2交换机/网桥145连接到网络接入L2交换机140。使用不同的连通性和/或PC/膝上型电脑115的桌面B、C和D场景的实施例在下文中也有描述。

在此方法中，设备关联可以如下进行(参考图4的消息图)：

步骤401。与以上描述的步骤201类似。

步骤402。应用服务器160持续地周期性轮询网络接入L2交换机140(“Query_port”)，以检测在网络接入L2端口处连接的设备的变化。注意，虽然为了清晰起见在图4中只示出了一个轮询，但是一般将存在多个Query_port轮询，它们周期性地发生，或者被应用服务器160触发。或者，在认为所有设备都非移动的实施例中，如图所示的单个查询就足够了。

步骤402a。网络接入L2交换机140作出响应(“Query_port_response”)，携带网络接入L2交换机端口ID以及每个端口连接的设备的IP地址和MAC地址。在不止一个设备附接到端口的情况下，所返回的响应可包含与每个设备有关的数据，或者可以使用多个响应消息。

步骤403。由于Query_port_response消息是来自同一端口ID的(或者等同地，对于在该端口上的所有附接的设备，响应作为单个消息到达)，因此应用服务器160现在能够将通信/计算设备数据与IP电话数据相比对，并且向关联数据库150发送关联消息或等同物，该消息或等同物包含计算设备MAC地址到IP电话MAC地址(或其他唯一标识符)的映射，并且还包含计算设备的IP地址以及IP电话的IP地址。此关联被存储在关联数据库150中，以便应用在以后使用。因此，应用服务器160通过发送关联消息而有效地触发了设备之间的关联。设备关联阶段完成。

步骤404-410基本上类似于上述的步骤204-210。

关于参考图4描述的消息传递的变体可以包括但不限于：

·为了搜集关于附接到网络接入L2交换机140上的特定端口的每个设备的信息，步骤402-402a可以使用多个消息对(对于端口上的每个设备使用一个查询/响应)，或者使用单个消息对(提供关于该端口上的所有附接的设备的大批信息)；

·为了搜集关于网络接入L2交换机140上的每个端口的信息，步骤402-402a可以使用多个消息对(对于每个端口使用一个查询/响应，或者像上述那样对于每个端口的每个设备使用一个查询/响应)，或者使用单个消息对(提供关于所有附接的端口上的所有设备的大批信息)；

·步骤402-402a中的查询/响应协议可以是SNMP(例如，在LLDP-MED中定义的)，或者可以是任何其他适当的协议。

·步骤402-402a也可以例如由从网络接入L2交换机140到应用服务器160的更原始的通知来触发而不是轮询，例如由使用SNMP网桥MIB等等的简单端口LinkUp/LinkDown通知(例子)来触发，所述通知随后可被应用服务器160用来触发对关于所通知的(一个或多个)端口的更具体数据的一个或多个查询。更具体的查询可以(例如)使用LLDP-MED定义的SNMP MIB等等。

·发生在步骤402处的从应用服务器160到网络接入L2交换机140的查询的开始可以由从呼叫控制器155(或者直接从IP电话110)或者从计算设备(PC/膝上型电脑115或瘦型客户端服务器125)到应用服务器160的消息传递来触发。任何数目的方法都可以用于此消息传递，例如SNMP通知事件，具体方法在这里是无关紧要的。触发消息可能(但并不一定)还提供了要查询的特定交换机端口ID。为了提高轮询效率，该触发消息可以如下所示在适当的时间发送：

·IP电话110和/或计算设备(115、125)可以在初始网络连接时通知应用服务器160开始轮询；

·呼叫控制器155(或者直接为IP电话110)可以在成功向呼叫控制器155注册IP电话110后通知应用服务器160开始轮询；

·呼叫控制器155(或者IP电话110或PC/膝上型电脑115或瘦型客户端120，或者瘦型客户端服务器125)可以在成功将用户登录到IP电话110(或者PC/膝上型电脑115或瘦型客户端120)后开始轮询。

在不同端口上连接的设备的变体

在关于以上方法的其他变体中，计算设备(瘦型客户端120或PC/膝上型电脑115)和IP电话110可以连接到不同的网络接入L2交换机端口(即，不经由任何一者之上的嵌入式L2交换机/网桥145连接，如图1的桌面场景B或D中所示)。关于以上刚刚描述的基于经由网络查询的链路层发现的方法的变体与先前在对基于经由网络通知的链路层发现的方法的描述下的标题“在不同端口上连接的设备的变体”下描述的那些类似，如前所述。

与以上参考图2和3描述的实施例相类似的、关于这些实施例的其他变体处于本说明书的范围之内。

设备和用户关联解除

现在关注先前建立的关联被取消的实施例。例如，至少一个关联的设备可能由于其被断电或断开连接而不再与数据网络130通信。在另一示例中，用户可能从设备中的一个或多个登出，并且先前建立的与其他设备的关联不再有效。解除关联的过程因此可以解决隐私问题和其他安全性考虑、资源消耗和/或滥用问题。

以下的实现设备的关联解除的实施例是参考先前描述的那些来描述的。其实，以下针对关联解除而描述的每个实施例对应于以上描述的关联方法。

利用经由设备的链路层发现的设备关联解除

现在描述设备关联解除利用经由IP电话110的链路层发现来发生的实施例，并扩展到利用经由计算设备(例如PC/膝上型电脑115或瘦型客户端120)的发现的等同方法。这些实施例实质上是以上参考图2描述的那些用于相应的设备关联的实施例的逆反。虽然以下是参考图2进行描述的，但是应当理解，解除关联的方法是利用与图2所示的类似的消息传递来描述的。当附接的计算设备(例如PC/膝上型电脑115或瘦型客户端120和/或IP电话110)被断开连接或断电时，或者有关应用被关闭时，存在与图2的消息201-203相对应的两种情况。

情况A-被动

步骤201。作为断开连接、断电或应用关闭的结果，从计算设备到网络接入L2交换机140的LLDP-MED(或等同物)消息传递停止，因此从计算设备到IP电话110及其嵌入式L2交换机/网桥145的LLDP-MED(或等同物)消息传递也终止。

步骤201a。因此，作为消息传递终止的结果，IP电话110(其嗅探消息传递)中的相应邻居信息被淘汰并且变得无效。

情况B-主动

步骤201。在断电或应用关闭时，从计算设备到网络接入L2交换机140的显式链路层消息可以被发送以指示出设备不再被使用。

步骤201a。指示设备不再被使用的显式链路层消息被IP电话110所嗅探。在这些实施例中，IP电话110能够使相应的邻居信息无效。

因此，设备的关联解除可以经由情况A或B来检测到。此后，可以发生以下步骤：

步骤202。当上游设备信息通过情况A或情况B被无效时，新的Neighbor_Info消息被发送到呼叫控制器155，以指示出上游设备不再是活动的。

步骤203。结果，新的Associate消息被从呼叫控制器155发送到关联数据库150，该新的Associate消息能够触发在关联数据库150处对相应设备关联的去除或无效(实质上是关联解除消息)。

设备关联解除也可以发生在使用经由桌面计算设备的链路层发现的实施例中。关联解除的这些实施例与上述那些相类似，只不过从IP电话110到网络和计算设备的LLDP-MED消息传递(或等同物)停止(步骤201，情况A)，或者显式的消息被发送(步骤201，情况B)，并且指示设备连通性变化的Neighbor_Info消息被从计算设备(即，从PC/膝上型电脑115、从瘦型客户端120，或从瘦型客户端服务器125)而不是从呼叫控制器155或IP电话110发送到应用服务器160(步骤202)。指示出关联的去除的Associate消息随后将被从应用服务器160发送到关联数据库150(步骤203)。

使用经由网络通知的链路层发现的设备关联解除

现在描述设备关联解除利用经由网络通知的链路层发现来发生的实施例。这些实施例实质上是以上参考图3描述的那些用于相应的设备关联的实施例的逆反。虽然以下是参考图3进行描述的，但是应当理解，解除关联的方法是利用与图3所示的类似的消息传递来描述的。当附接的设备(例如PC/膝上型电脑115、瘦型客户端120和/或IP电话110)被断开连接或断电时，或者有关应用被关闭时，存在与图3的消息301-303相对应的两种情况。

情况A-被动

步骤301。作为断开连接、断电或应用关闭的结果，从计算设备(或者作为替代，从IP电话110)到网络接L2交换机140的LLDP-MED(或等同物)消息传递停止。由于没有来自计算设备或IP电话110的通告，因此在网络接入L2交换机140处包含的相应信息被淘汰并无效。

情况B-主动

步骤301。在断电或应用关闭时，显式的链路层消息可以被从计算设备(或者作为替代，从IP电话110)发送到网络接入L2交换机140，指示出设备不再被使用。该消息触发网络接入L2交换机140处对相应上游设备信息的无效。

因此，设备的关联解除可以经由情况A或B来检测到。此后，可以发生以下步骤：

步骤302。当网络接入L2交换机140处的设备信息被无效时，作为该变化的结果，新的Notify_link_change消息可以被发送到应用服务器160，指示出上游设备不再是活动的。

步骤303。结果，新的Associate消息被从应用服务器160发送到关联数据库150，该新的Associate消息能够触发在关联数据库150处对相应设备关联的去除或无效(实质上是关联解除消息)。

使用经由网络查询的链路层发现的设备关联解除

现在描述设备关联解除利用经由网络查询的链路层发现来发生的实施例。这些实施例实质上是以上参考图4描述的那些用于相应的设备关联的实施例的逆反。虽然以下是参考图4进行描述的，但是应当理解，解除关联的方法是利用与图4所示的类似的消息传递来描述的。当附接的设备(例如PC/膝上型电脑115、瘦型客户端120和/或IP电话110)被断开连接或断电时，或者有关应用被关闭时，存在与图4的消息401-403相对应的两种情况。

情况A-被动

步骤401。作为断开连接、断电或应用关闭的结果，从计算设备(或者等同地，从IP电话110)到网络接入L2交换机140的LLDP-MED(或等同物)消息传递停止。由于没有来自计算设备或IP电话110的通告，因此在L2交换机140处包含的相应信息被淘汰并无效。

情况B-主动

步骤401。在断电或应用关闭时，显式的链路层消息被从计算设备(或者等同地，从IP电话110)发送到网络接入L2交换机140，指示出设备不再被使用。该消息触发网络接入L2交换机140处对相应上游设备信息的无效。

因此，设备的关联解除可以经由情况A或B来检测到。此后，可以发生以下步骤：

步骤402-402a。在下一轮询时间间隔中，当Query_port被从应用服务器发送到网络接入L2交换机时，所返回的Query_port_response指示出(一个或多个)被无效的设备不再活动。在一些实施例，这可以包括关于该设备的信息的缺乏，而在其他实施例中，这可以包括关于设备现在不活动的显式指示。

步骤403。结果，新的Associate消息被从应用服务器160发送到关联数据库150，该新的Associate消息能够触发在关联数据库150处对相应设备关联的去除或无效(实质上是关联解除消息)。

用户级关联解除

在以上描述的设备关联实施例中的一些中，一旦设备级关联解除完成，用户也被解除关联，以例如自动将用户从先前关联的设备中的一些或全部中登出。在这些实施例中的一些中，作为在关联的设备之一上采取的用户动作的结果，所有这些设备上的相应用户级动作发生，例如作为从任何一个中登出的结果而从一些或全部中登出。因此，在共用桌环境中，如果在一个设备处发生登出，则在共用桌关联中的其他设备处可能发生登出。

现在描述对用户进行关联解除的两个实施例，情况A和情况B，但是其他实施例也在本说明书的范围之内。虽然以下是参考图2来描述的，但是应当理解，对用户进行关联解除的实施例使用与图2所示的类似的消息传递。

情况A-设备关联解除驱动

如果关联解除是物理的(设备被断开连接、断电或应用被关闭，就像先前描述的场景中那样)，那么设备关联解除在应用服务器160处被检测(参见先前关于关联解除方法的章节，具体而言是步骤203、303和403)。

被物理设备关联解除所触发，在计算设备断开连接的情况下，应用服务器160随后可以向呼叫控制器155发送登出消息(未示出)，以将相应的用户从相应的IP电话中登出。参考图2中的步骤204-210(以及类似地，图3中的步骤304-310和图4中的步骤404-410)，此过程可以按以下步骤来进行：

步骤207-208。应用服务器160利用计算设备相关用户ID作为关键字，检索与新断开连接的设备的用户相对应的关联数据。在呼叫控制器155中使用的相应用户ID(UserDN)被从响应中提取出。

但是，在一些实施例中，登出可能还需要设备ID。在这些实施例中，关联数据库150可以临时维护设备之间的关联，直到用户登出发生为止。例如，关联数据库150可以维护被解除关联的设备的记录，即使同一用户仍被登录到这些设备中也是如此。

步骤209。Phone_logout消息(等同于消息图中的Phone_login)被从应用服务器160发送到呼叫控制器155，该消息包含所提取的用户ID(UserDN)。(注意，在一些实施例中，在此消息中可能不需要电话MAC，因为呼叫控制器155已经知晓用户被登录到了哪个物理IP电话中)。

步骤210。呼叫控制器155随后使用户从IP电话110中登出。

关于情况A的其他变体如下：

·或者，如果初始的断开连接/断电/应用关闭是从IP电话110发起的，则用户关联查询可以是关于计算设备用户ID的，并且相应的登出消息可被从应用服务器160发送到瘦型客户端服务器125(或者直接发送到PC/膝上型电脑115)，从而改为使计算设备将用户在该设备处登出。

·物理设备关联数据可以被从关联数据库150完全去除，或者可以被标记为不活动的并保持被缓存在关联数据库中以便以后在被去除的设备被重新连接时使用。如果以后新的连接或通电被检测到，则设备关联必须再次如前所述地被重新建立，但可以利用任何先前缓存的数据来辅助该过程。

·在先前针对设备关联解除所描述的步骤303(或403，或503)中，在发送Associate消息以从关联数据库150中去除设备关联之前，应用服务器160可以在与步骤307/308类似的步骤之后从关联数据库150预先查询现有的关联数据，并且保留该数据以便以后在如上所述的用户级关联解除过程中使用。

·与以上变体相等同地，在步骤303(或403，或503)，Association消息可以具有从关联数据库150返回到应用服务器160的相应响应消息，其指示出设备关联数据被去除，包括所有先前关联的设备ID或者执行如上所述的用户级关联解除过程所需的其他数据。

情况B-用户动作驱动

如果用户在关联的设备之一处登出(但该设备未被断开连接或断电)或者采取某个其他动作以在该设备处终止用户级会话(例如，应用被关闭)，则在其他关联的设备处可能需要采取等同的用户登出或其他动作。在此情况下，物理关联可以保留在关联数据库中以便以后使用，因为设备本身仍处于相同的关系中。

被一个设备上的用户动作所触发，在计算设备登出的情况下，应用服务器160随后可以向呼叫控制器发送登出消息，以将相应的用户从相应的IP电话中登出。参考图2中的步骤204-210(以及类似地，图3中的步骤304-310和图4中的步骤404-410)，此过程可以按以下步骤来进行：

步骤204。用户从瘦型客户端120中去除其标识卡135，或者以某种其他的方式登出。在PC/膝上型电脑的情况下，可以在PC/膝上型电脑115处去除该卡或者采取其他登出动作。

步骤205。结果，瘦型客户端120随后可以向瘦型客户端服务器125发送登出消息或等同物。这可以类似于在先前描述的设备关联和自动登录期间的此步骤中发送的Login消息。

步骤206。瘦型客户端服务器125随后可以向应用服务器160发送指示出用户登出的事件消息。在PC/膝上型电脑的情况下，类似的消息可以被直接从PC/膝上型电脑115发送到应用服务器160。这可以类似于在先前描述的设备关联和自动登录期间的此步骤中发送的Login_event消息。

步骤207-208。应用服务器160利用计算设备相关用户ID作为关键字，检索与新登出的设备的用户相对应的关联数据。在呼叫控制器155中使用的相应用户ID(UserDN)被从响应中提取出。

步骤209。Phone_logout消息(等同于消息图中的Phone_login)被从应用服务器160发送到呼叫控制器155，该消息包含所提取的用户ID(例如UserDN)。(注意，在此消息中可能需要也可能不需要电话MAC，因为呼叫控制器155已经知晓用户被登录到了哪个物理电话中)。

步骤210。呼叫控制器155随后使用户从IP电话110登出。

关于情况B的其他变体如下：

·作为替代，如果初始的登出是从IP电话110发起的，那么登出事件将是经由呼叫控制器155(或者直接从IP电话110)到应用服务器160的，用户关联查询将会是关于计算设备用户ID的，并且相应的登出消息被从应用服务器160发送到瘦型客户端服务器125(或者发送到PC/膝上型电脑115)，从而改为使计算设备将用户在该设备处登出。

·物理设备关联数据可以保留在关联数据库150中以便以后在新的(可能是同一个)用户再次登录到关联的设备之一中时使用。在一些实施例中，物理关联可以仅在物理断开连接或断电被检测到时才仅被销毁或标记为不活动。如果以后新的连接或通电被检测到，则设备关联必须再次如前所述地被重新建立。

适用于情况A和情况B两者的其他变体如下：

·以上的两个情况都同样适用于PC/膝上型电脑场景，在这种情况下相应的消息将被PC/膝上型电脑115直接发送和接收，而不是被瘦型客户端服务器125发送和接收。先前被描述为瘦型客户端120和瘦型客户端服务器125之间的消息将改为在PC/膝上型电脑115内部。

替换实施例

存在对参考图1至4描述的先前实施例的其他替换，包括但不限于：

·实施例不限于LLDP-MED被用作链路层协议，在为关联提供充分的信息的情况下可以使用任何其他协议。这种协议的非限制性示例包括生成树协议(STP)或诸如Cisco发现协议(CDP)之类的专有协议。

·虽然非限制性示例已经就瘦型客户端场景进行了描述，但是所描述的所有方法都同样适用于PC/膝上型电脑场景。在这些情况下，所有相应消息将被PC/膝上型电脑115直接发送和接收，而不是被瘦型客户端服务器125发送和接收。先前被描述为瘦型客户端120和瘦型客户端服务器125之间的消息将改为在PC/膝上型电脑115内部。

·虽然非限制性示例已经描述了跨多个设备的自动登录/登出的应用，但是描述这些主要是为了证明设备关联步骤在促进这种应用方面的可使用性。许多其他应用都处于本说明书的范围之内，包括但不限于：电话小键盘(“TKB”)到基于PC的接线员控制台(PC-based Attendant Console)应用的关联；PC附属电话设备(例如，来自Mitel Networks，350 LeggetDrive P.O.Box 13089，Kanata，Ontario，Canada K2K 2W7的MitelNavigator)到所附接的运行控制应用的PC的关联。实际上，对于许多应用，可能不需要登录/登出动作。例如，仅仅插入设备就可以自动使其可用，即使在任何设备上都没有发生用户登录也是如此。

·虽然上述实施例只包括两个要被关联(或解除关联)的设备，但是任意数目的设备都可被关联，只要它们之间的连通性通过设备之一(例如，经由与桌面A和桌面C场景中的L2交换机/网桥145相类似的多端口嵌入式L2交换机)被建立即可，或者只要有充分的映射或位置数据可用来将多个网络接入L2交换机端口(与桌面B和桌面D场景中描述的网络接入L2交换机端口相类似)与彼此关联起来即可。

·参考图1至4描述的关联方法的多个方面可以在关联多个设备时被同时使用。

·虽然所描述的实施例提及将MAC地址作为有关消息传递中的物理设备标识符，但是其他标识符也在本说明书的范围之内。实际上，物理设备的任何唯一的、不变的标识符都足以用于此目的。标识符的非限制性示例包括：UUID(通用唯一标识符)、资产号、序列号、以及物理设备DN(目录号)。同样，关联的设备也不限于使用相同类型的标识符，每个设备可以使用不同的标识符类型，只要标识符对于该特定设备来说保持唯一即可。

·虽然所描述的实施例提及有线网络环境，但是，利用LLDP-MED或其他等同的协议，无线(例如WiFi、蓝牙)网络也可支持等同的方法。

·虽然所描述的实施例提及IP电话与桌面计算设备的关联，但是设备关联也可应用到任何以下述方式共位的设备：从用户或管理的角度来看，它们应当与彼此相关联。其他示例包括但不限于：

·IP电话和连接到IP电话或者与IP电话紧邻的附属单元，例如会议单元、视频相机、占线指示灯区域(busy lamp field)，等等；

·将要联合使用的多个计算和/或娱乐设备，例如PC/膝上型电脑、音频/视频装置、游戏控制器；

·共位的计算设备，比如在共同的应用中合作以例如实现数据中心中的多服务器集群的多个服务器；

·协作性应用；

·集群计算/数据中心；以及

·以上的任何组合。

如上所述，经由共位检测的设备关联是邻近性检测的一种形式，因为关联判定了设备处于同一位置。也如上所述，这使得能够共享位置信息。但是，在基于邻近性的应用中，位置的特性和身份一般是无关紧要的，但即使缺乏具体的位置信息，关于邻近性的知识也可以用于调整与通信设备相关联的应用，现在将对此进行描述。

现在关注图5，该图示出了根据非限制性实施例的用于对与第一通信设备510a和第二通信设备510b(一般称为通信设备510，并且统称为通信设备510)中的至少一个相关联的应用进行调整的系统500。在一些实施例中，系统100和系统500具有共同的元件，其中相似的元件用相似的标号来表示。另外，在一些实施例中，第一通信设备510a和/或第二通信设备510b可以包括上述的IP电话110、个人计算机(PC)或膝上型计算机115、以及/或者“瘦型客户端”设备120，而在其他实施例中，第一通信设备510a和/或第二通信设备510b可以包括诸如蜂窝电话和/或PDA之类的能够经由任何适当的无线协议并经由任何适当的无线通信网络通信的移动电子设备。

另外，与第一通信设备510a和/或第二通信设备510b相关联的应用，例如应用A，可以驻留在第一通信设备510a和/或第二通信设备510b和/或应用服务器160和/或呼叫控制器155处。在一些实施例中，应用A包括与经由远离第一通信设备510a和第二通信设备510b的通信网络(例如数据网络130或任何其他适当的通信网络)在第一通信设备510a和第二通信设备510b之间建立通信会话相关联的应用。应当理解，远程通信网络是任何包括与通信设备510相分离并且/或者远离通信设备510的交换和/或路由元件的通信网络。另外，远程通信网络不同于存在于通信设备510之间的个域网(PAN)，例如基于诸如Bluetooth^TM之类的PAN协议的PAN(例如，参见下述的图6)。

在一些实施例中，应用A包括协作应用A，它使得通信设备510能够协作。在这些实施例中的一些中，应用A使得通信设备510能够经由远程通信网络来协作，如上所述。

另外，在系统500中，呼叫控制器155可以包括能够经由数据网络130(或任何其他适当的通信网络)与通信设备通信的通信接口550、用于处理应用A的处理单元560、以及用于连接通信设备510之间的呼叫的交换机570。在一些实施例中，例如在通信会话是基于分组的通信会话的实施例中，呼叫控制器155还可包括用于在通信设备510之间路由分组的路由器580。在这些实施例中的一些中，交换机570可能不存在于呼叫控制器155中。在一些实施例中，呼叫控制器155包括PBX。另外，一般应当理解，经由呼叫控制器155在通信设备510之间建立的通信会话是经由远程通信网络建立的。在一些实施例中，呼叫控制器155还包括存储器590，用于存储应用A的拷贝，以及/或者辅助建立通信设备510之间的通信会话的交换/路由数据。

在任何情况下，第一通信设备510a都位于第一位置520a处并且与用户530a相关联，而第二通信设备510b位于第二位置520b(一般称为位置520并且统称为位置520)处并且与用户530b(一般称为用户530并且统称为用户530)相关联。

在一些实施例中，通信设备510中的一个或多个经由网络接入L2交换机140(例如，如图1所示)连接到数据网络130，并且一个或多个通信设备的位置被存储在经由链路层数据来编制的接线图数据库170中，如上所述。因此，在这些实施例中，可以基于链路层数据来判定通信设备510的位置，例如通过参考接线图数据库170来判定。

但是，在其他实施例中，正如本领域的技术人员已知的，如果通信设备510包括GPS模块，则可以基于GPS(全球定位系统)数据来判定通信设备510的位置。因此，可以通过例如经由数据网络130或另一通信网络查询GPS模块来判定通信设备510的位置。

在这些实施例中的一些中，通信设备510包括无线电子设备(即，无线地连接到数据网络130或能够进行无线通信的另一种适当的通信网络，而不是经由网络接入L2交换机140连接到数据网络130)。

另外，在通信设备510是无线移动电子设备的其他实施例中，正如本领域的技术人员已知的，可以通过其经由给定的无线接入点(例如，WiFi接入点、蜂窝电话接入点等等(未示出))的网络接入来判定通信设备510的位置，并且/或者经由从与通信设备510通信的多个无线接入点(未示出)收集的RF三角测量数据来判定通信设备510的位置。

在其他实施例中，可以基于用户数据来判定通信设备510的位置：例如，用户530在改变位置时可以将标识当前位置的用户数据输入到通信设备510中(例如经由诸如键盘、指针设备等等之类的输入设备)。

在一些实施例中，位置数据可被存储在通信设备510处，而在其他实施例中，位置数据可被发送到远程数据库(例如，关联数据库150和/或邻近性/位置数据库595)和/或呼叫控制器155(例如，并被存储在存储器590中)。因此，可以通过向通信设备510和/或远程数据库(例如，关联数据库150和/或邻近性/位置数据库595)和/或呼叫控制器155和/或其组合请求位置数据来判定通信设备510的位置。但是，对于在何处存储位置数据并无具体限制。

另外，对于位置数据的格式没有具体限制，它可以是任何适当的格式，包括但不限于地理定位(纬度/经度/高度)、建筑物/房间标识符、城市地址、和/或接线图标识符，等等。此外，应当理解，对于不同的通信设备510，位置数据的格式可以是不同的，并且来自不同通信设备510的位置数据可以被关联起来，所述关联独立于特定通信设备510的位置数据的格式。

在其他实施例中，个域网(PAN)技术可用来在不判定(一个或多个)通信设备510的位置的情况下判定通信设备510是否邻近。例如，关注图6，该图示出了根据非限制性实施例的用于对与第一通信设备510a和第二通信设备510b中的至少一个相关联的应用进行调整的系统600。系统600基本类似于图5，其中相似的元件具有相似的标号。但是，在系统600中，不一定知晓和/或可判定通信设备510的绝对位置。另外，通信设备510已经基于PAN协议在其间建立了PAN通信会话610。在一些实施例中，PAN协议包括Bluetooth^TM协议，但其他PAN协议和技术将被本领域的技术人员想到并且处于这些实施例的范围之内。正如本领域的技术人员也已知的，PAN协议一般能够在有限的距离上工作，因此如果具备Bluetooth^TM能力的通信设备510正与另一个具备Bluetooth^TM能力的通信设备510通信，则关于这些通信设备510邻近的判定可以由于通信会话610的建立而发生。还应当理解，在这些实施例中，邻近被理解为共位。随后，可以自动地或者在接收到来自中央设备的请求后将通信设备510的邻近性报告给中央设备，例如呼叫控制器155或远程数据库(例如关联数据库150和/或邻近性/位置数据库595)。

在一些实施例中，可在基于通信设备是邻近还是不邻近来调整基于邻近性的应用，其中每种条件触发一种不同的调整模式。另外，在一些实施例中，邻近可以被理解为共位，而在其他实施例中，邻近性还可以进一步由以下判定所约束：判定通信设备510在同一房间、建筑物、公共区域或其他受约束的空间中，即，设备可能在物理上接近，但如果通信设备510不在同一物理空间中，则它们可能不被判定为邻近和/或共位。

例如，移动设备可能彼此只相距较短的物理距离，但却位于不同的房间中，因此能够被认为是“接近”，但并不严格地共位。邻近性应用可被相应地调整。因此，在这些实施例中，邻近性应用可以包括基于通信设备510“接近”但并不严格共位的至少一种邻近性模式。在一些实施例中，可以通过处理与通信设备510相关联的位置数据来判定这种有条件邻近。在这些实施例中的一些中，可以通过对描述通信设备510所在的物理空间的进一步数据进行处理来判定这种有条件邻近。这种处理可以包括但不限于：将包含房间标识符的接线图数据与地理定位数据(例如地理定位数据指示出通信设备510仅相隔较短距离，但接线图数据指示出通信设备510位于不同的房间中)关联起来；将与通信设备510相关联的地理定位数据映射到描述通信设备510所在的物理空间的几何形状的形状数据；以及/或者将位置数据映射到城市位置数据，并且比较每个通信设备510的城市位置数据。判定邻近级别(例如、共位、邻近、“接近”和接近到什么程度、以及非邻近)的其他方法处于这些实施例的范围之内。

另外，在一些实施例中，共位和/或邻近和/或接近和/或不邻近的定义可以由用户530以及/或者系统500和/或系统600的管理员来设定。这种管理员可以定义与给定的邻近性模式相关联的基于邻近性的应用的调整，包括但不限于触发给定的邻近性模式的邻近性条件。例如，可以根据通信设备位于给定的房间和/或同一房间中、建筑物的给定楼层和/或同一楼层中、以及/或者位于任何适当的给定物理域内，来调整基于邻近性的应用。在这些实施例中的一些中，通信设备510可以被定义为共位，而在其他实施例中，按照管理员所判定的，通信设备510可以被定义为邻近，并被相应地调整。

但是，应当理解，一些基于邻近性的应用只包括邻近模式和非邻近模式，其中邻近和/或非邻近的条件由管理员来定义。在这些实施例中的一些中，邻近被理解为共位，但共位并不一条是邻近的条件。

另外，在一些实施例中，判定通信设备510处于同一给定物理域(例如，给定的物理空间)中可能并不足以判定邻近；在这些实施例中，物理距离可以是判定共位和/或邻近程度的条件。例如，在一些实施例中，可以判定两个通信设备510处于同一给定物理域中，但该给定的物理域可能是曲棍球场。在这种实施例中，通信设备510可能还相隔一段距离，而该段距离阻碍了对邻近和/或共位的肯定判定(例如，处于曲棍球场的两端和/或曲棍球场的不同区间)。因此，在这些实施例中，如果通信设备510相隔小于阈值距离，则可以发生对邻近和/或共位的肯定判定。

在一些实施例中，通信设备510可能能够支持与可能基于用户530彼此远离这一假设的特征相关联的协作应用，例如应用A。但是，这些特征的某些方面可能不适合于用户530彼此邻近的实例。如上所述，在一些实施例中，邻近被理解为共位，而在其他实施例中，邻近被理解为接近。例如，关于正在处理协作应用(例如应用A)的通信设备510的邻近性的知识可用于调整与该邻近性相称的协作应用活动和/或行为。在一些实施例中，可以向用户530提供与邻近性相称的选项。在一些实施例中，应用的调整可以经由驻留在协作应用处的邻近性客户端P而发生，该邻近性客户端能够根据需要与协作应用相接口。或者，基于邻近性的调整特征可以被内置到协作应用本身之中。

在一些实施例中，对应用的调整包括选择应用的多个模式之一，该多个模式中的每一个与通信设备510之间的一个不同的邻近级别相关联。如上文中所述以及下文中进一步描述的，这种邻近级别可以基于通信设备510之间的距离。如前所述，邻近级别或共位可以进一步以判定设备处于同一物理域/空间中为条件。例如，在一些实施例中，可能存在针对通信设备510邻近时的一种模式和针对通信设备510不邻近时的第二模式。在其他实施例中，可能存在针对通信设备510共位时的一种模式、针对通信设备510接近时的第二模式、以及针对通信设备510不邻近时的第三模式。这些实施例中的一些可以包括多个接近模式，这多个接近模式中的每一个基于通信设备510之间的不同距离。

在非限制性示例中，如果通信设备510a尝试与通信设备510b建立通信会话(例如，经由数据网络130，或者任何其他适当的通信网络)，那么如果用户530彼此邻近，则与建立通信会话相关联的应用可以被调整以避免向用户530提供语音或视频会话的选项，其中邻近被理解为指共位。共位可被定义为通信设备510相隔的距离小于给定的阈值距离，以及/或者通信设备510位于同一物理域/空间内。在此场景中进行下述假设，即用户530a希望与邻近的用户530b共享数据，而不需要被由于用户530的邻近而变得不必要的无用选项所扰。在一些实施例中，默认的调整行为可由用户530中的一个或多个来设定。

在另一个非限制性示例中，如果在通信设备510不共位的情形下通信设备510a尝试与通信设备510b建立通信会话，那么可以使通信设备510b播放可听警告(即，电话铃声、远程桌面应用指示播放等等)，以及/或者显示给定的可视指示，以指示出对打开通信会话的尝试。但是，如果通信设备510共位/邻近，则这种可听警告是令人分心并且/或者不合需要的。因此，如果通信设备510被判定为共位/邻近，则这种可听警告可以被调整。这种调整的范围从而可以是从播放较安静的警告、完全禁用警告到呈现不同的可视指示不等。在其他实施例中，这种调整还可以基于邻近级别：例如，基于通信设备510之间的距离，以及/或者对它们处于同一物理域/空间中的判定，可以改变可听警告的声音级别，以及/或者可以呈现可视距离指示(或者任何其他适当的指示(振动等等))。

在其他实施例中，对邻近的判定可以进一步指示出用户530本来就希望建立通信会话。因此，无需来自用户530b的进一步输入，在通信设备510b即可接受/建立通信会话(例如，通信应用被调整为处于“自动应答”模式中)。在一些实施例中，一旦建立了通信会话，就可播放警告(例如“您已与用户530b建立了通信会话”)。

在另一个非限制性示例中，如果已知未经授权的用户的通信设备存在，那么在通信设备510的一个或多个处对机密信息的本地显示(和/或播放)可以被驻留在通信设备510上的邻近性调整客户端P所抑制。在此实施例中，邻近性客户端P可以参考授权的和/或未授权的通信设备/用户的数据库来判定是否允许显示机密信息(这种数据库可以对通信设备510而言是本地的，或者是远程的并且可经由数据网络130访问)。在一些实施例中，在显示机密信息之前可以请求用户530的明确许可。

在在通信设备之间进行关联的实施例中(例如以上参考系统100所述)，系统100和/或系统500(和/或系统600)的监视和/或触发关联的元件或者元件的组合(例如呼叫控制器155和/或应用服务器160)可以还能够对与通信设备510中的至少一个相关联的应用进行基于邻近性的调整。例如，一旦通信设备510被判定为共位/邻近，基于与共位/邻近的通信设备510相关联的数据，适当的元件就可以触发对在通信设备510处可用的应用的调整。例如，一旦通信设备510被判定为共位/邻近，适当的元件就可以判定与第一通信设备510a相关联的许可(例如，基于存储在数据库处的许可，等等)，并且基于这些许可使得某些应用在共位/邻近的第二通信设备510b处可用。在另一示例中，可以使得诸如与第一通信设备510a相关联地存储的个人信息管理(PIM)数据之类的数据对共位/邻近的第二通信设备510b可用。

在一些实施例中，对与通信设备510中的至少一个相关联的应用进行基于邻近性的调整的功能可以在诸如路由器之类的元件或者任何其他适当的网络基础设施组件内实现。

但是，在其他实施例中，对与通信设备510中的至少一个相关联的应用进行调整可以针对邻近的通信设备发生，其中邻近被理解为接近但不一定共位或者相关联。例如，一旦判定了通信设备510中的每一个的位置，就可以判定它们之间的距离。可以将该距离与阈值距离进行比较。如果该距离小于(或等于)阈值距离，则通信设备510可被判定为彼此邻近，并且作为响应，对与通信设备510中的至少一个相关联的应用的调整可以被触发。

在一些实施例中，阈值距离还可以考虑通信设备510是否在建筑物的同一楼层上。如果是，则较大的阈值距离是可接受的，因为用户530在给定楼层内行走较长的距离与用户530必须走楼梯或搭电梯相比，花费的行进时间将是相同的。

在一些实施例中，可以计算从位置520a到位置520b的大致行进时间(例如，计算行进时间的应用被预先配设以用户530的行走速度、在楼层之间行进的时间，等等)，并且将大致行进时间与阈值行进时间进行比较。

其他实施例可以包括多个阈值距离，每个距离阈值与不同的邻近级别相关联，从而应用A可以经不同的邻近级别(即，不同的“接近”级别)被调整。

或者，可以不知晓绝对位置，但如果知晓位置的相对方位，则仍然可以判定邻近性。例如，位置的相对方位可以被存储在数据库中，并且位置520处的通信设备510之间的邻近性可以通过查询数据库来判定。在特定的非限制性示例中，如果通信设备510a的位置520a被判定为“201办公室”，而通信设备510b的位置520b被判定为“202办公室”，并且“201办公室”和“202办公室”之间的相对方位在数据库中被存储为“邻近”或“毗邻”，则通信设备510被判定为邻近。在这些实施例中的一些中，如上所述，邻近被理解为指接近，但不是正好共位(例如，在同一房间中)。

在其他实施例中，可以经由上述方法中的任何一种来知晓通信设备510之间的邻近性，但是通信设备510可能本来并不与用户530相关联。但是，如果用户530随后登录到通信设备510中，则用户530可以与所登录到的通信设备510相关联，并且用户530之间的邻近性可以基于登录来判定。

可以基于邻近性来调整的一些应用/特征在通信设备510接近但不共位(例如在隔壁办公室中)时更合需要。例如，在一个实施例中，可以提供一种应用，其中当用户530b接近时，用户530a将被通知。用户530a可以经由应用A和/或邻近性客户端P或任何其他适当的应用来指定用户530b。例如，当用户530b正在拜访毗邻的办公室中的某人时用户530a可以被通知，因此用户530a可以走一小段距离去会见用户530b。

但是，在一些情况下(例如在与某个企业相关联的一套办公室中)，用户530b可能经常在与用户530a毗邻的办公室中，用户530a因此可能会发现，如果每次发生这种情况都接收到通知，那将会是很恼人的。因此，在一些实施例中，可以调整一应用，使得仅当用户530a尝试与用户530b建立通信会话时(即，经由通信设备510)，用户530a才会被通知以用户530b的邻近。例如，用户530a可尝试利用通信设备510a(例如，输入通信设备510b的标识符，例如蜂窝电话号码)以及远程通信网络(例如，数据网络130和/或呼叫控制器155)发起与用户530b的通信会话。当这种尝试被进行时，呼叫控制器155可以发起邻近性应用(例如应用A)，该邻近性应用如上所述判定通信设备510的邻近性并且将用户530b的邻近通知给用户530a。用户530a可以通过以下方式被通知：向通信设备510a发送位置520a和位置520b中的至少一个的指示，使得该指示的表示例如经由输出设备处显示的消息(例如，“您正在呼叫Joe。如果您愿意，您可以直接跟他交谈，因为他正在隔壁办公室中)在通信设备510a处被输出。这可以被称为“接近特征”。在一些实施例中，该表示可以包括去往位置520b的地图。在其他实施例中，所尝试的通信会话被终止。在其他实施例中，可以向用户530a提供终止所尝试的通信会话的选项。

以上已经描述了使用接线图数据库170来将通信设备510与其所在的位置相关联，就像接线图数据库170如何能被用于关联处于其所共同位于的位置内的设备一样。因此，可以定位通信设备510所在的房间。为了“接近特征”的目的，可以扩展房间的标识来判定位置是否接近/邻近。这或者可以通过赋予每个房间一个绝对位置并因此能够在接近特征运行时判定其间的距离来完成(其中有一“接近”的标准，该标准指示出什么距离和其他因素(例如楼层)是合适的)，或者可以在提供表格/数据库的情况下离线完成它，该表格/数据库将每个房间或其他位置与可被认为接近/邻近的其他房间或其他位置的身份相链接，如上所述。

因此，如果用户530b在计算机上登录或者被判定为处于接近设定了“接近特征”应用的用户530a的房间中，则“接近特征”应用可以被调整到“开启状态”(并且相反地，如果邻近级别变为非邻近，则被调整到“关闭状态”)。

基于邻近性来调整应用的另一个非限制性示例是调整回呼应用。用户530a可能尝试了经由通信设备510与用户530b建立通信会话。如果用户530b非空闲(即，通信设备510b已经参与一通信会话并且不可被打断)，那么用户530a可能被赋予了一旦用户530b变得空闲就接收自动回呼的选项。这种回呼应用是本领域的技术人员已知的，并且在系统500或系统600中可以通过呼叫控制器155提醒通信设备510a通信设备510b有空并随后尝试在它们之间建立通信会话来发起。但是，如果通信设备510b变得邻近通信设备510a(例如，用户530b可能在用蜂窝电话(即通信设备510b)讲话的同时正朝着位置520b行进)，则这种回呼将会是冗余的。因此，如果判定了通信设备510之间的邻近，则可以调整回呼应用以取消回呼。在一些实施例中，可以仅在判定通信设备510共位和/或邻近时才调整回呼应用。在其他实施例中，如果判定通信设备510邻近但不共位，则可以将回呼应用调整到“接近”模式(见上文)。例如，回呼应用可以被调整为显示一消息，该消息告知用户530a：用户530b在附近，并且在一些实施例中，该消息还将用户530b的位置告知给用户530a。因此，用户530a可能更宁愿去见用户530b，而不是发起回呼。

但是，不应当假定通信设备510永久地与单个用户相关联；虽然这种情况可能存在。例如，通信设备510可以是共享的设备，并且用户530可以经由任何适当的方法(例如用户名/口令/身份卡135，等等)登录到该共享设备中。在其他实施例中，每个通信设备510可以特别与多个用户530相关联(例如，多个用户530中的每一个可以在给定的时间使用通信设备510)。在任何情况下，对邻近性的判定都提供了可用来调整应用的信息，并且进一步的调整可以基于一个或多个用户530而发生。例如，如上所述，通信设备510之间的位置信息的共享是其行为可由对邻近性的判定来调整的应用。与之不同的是，通过对邻近性(具体在此实例下是共位)的判定来调整的应用是在判定一个或多个特定用户的邻近性时提供的通知。诸如以上描述的会话发起应用之类的其他特征可以由用户触发，但是行为可以利用关于被叫用户与发端用户邻近(即，共位)的知识来调整。

另外，在其他实施例中，编码在关联数据库150中的共位和/或邻近性信息可以被进一步发布给存在性服务器和/或专用邻近性服务器，在该处它可以用来触发和/或调整特征操作。在一些实施例中，这种服务器的发布-预订模型可以用于此目的。

在一些实施例中，关联数据库150可以包括邻近性数据库，例如邻近性/位置数据库595。需要关于与另一通信设备510(及其用户530)邻近或接近的通信设备510(以及暗含地，它们的用户530)的信息的特征可以查询关联数据库150和/或邻近性数据库来判定此信息。此信息也可以作为用户530及其(一个或多个)通信设备510的邻近性信息被发布给存在性服务器。

另外，虽然所描述的实施例涉及单个应用的操作，但关联信息也可用作判定在协作情况下的多个应用和/或多个通信设备的适当行为的上下文。

此外，在一些实施例中，设备可能不与任何特定用户相关联，或者可能根本不与任何用户相关联，例如所述设备可以是：处于机架上的计算装备，实现合作应用或服务器集群；用户感兴趣的自动售货机、存储位置等等；机器人；实现用户跟踪应用的设备；和/或实现资产跟踪应用的设备，等等。

现在关注图7，该图示出了对与第一通信设备和第二通信设备中的至少一个相关联的应用进行调整的方法700。为了帮助说明方法700，将假定方法700是利用系统500(或者作为替代，系统600)来执行的。另外，以下对方法700的论述将带来对系统500及其各种组件的进一步理解。但是，应当理解，系统500和/或方法700可以被改变，而不是需要完全像这里论述的那样彼此联合地工作，并且这种变体处于这些实施例的范围之内。

在步骤710，判定通信设备510之间的邻近性。在一些实施例中，步骤710可以在通信设备510中的至少一个尝试与至少一个其他通信设备510例如经由远程通信网络建立通信会话时被触发。在一些实施例中，这种触发可以发生在协作应用被启动时，并且在建立通信会话的任何尝试之前，可以有对邻近性的判定。在其他实施例中，对邻近性的判定可以与建立通信会话的尝试并行发生。在其他实施例中，对邻近性的判定可以发生在通信会话已被建立之后以及可以基于邻近性来调整的应用(和/或应用中的特征)被启动之时。在其他实施例中，例如可以通过独立于可以基于邻近性来调整的任何(一个或多个)应用的活动的邻近性代理P来持续地判定邻近性。

另外，对通信设备510之间的邻近性的邻近性判定可以在通信设备510中的一个或多个的本地发生，或者远离通信设备510发生(例如，在呼叫控制器155和/或应用服务器180处发生)。

在一些实施例中，步骤710之前可以有步骤705，对每个通信设备510的位置的判定可以基于GPS数据、无线接入点连接数据、RF三角测量数据、用户数据、基于有线连接端口的接线图数据和/或存储在数据库中的位置数据。在一些实施例中，可以判定每个通信设备510的绝对位置，而在其他实施例中可以判定每个通信设备510的相对位置。在任何情况下，在这些实施例中，在步骤710处基于在步骤705处判定的每个通信设备510的位置，例如如上所述通过判定这些位置是否彼此邻近，来判定通信设备510的邻近性。

在其他实施例中，步骤710之前可以有步骤706，或者步骤710可以与步骤706并行发生，该步骤706判定在通信设备510之间是否已经建立了PAN通信会话，如上所述。在实施例中，对是否已建立PAN通信会话的判定可以包括接收来自通信设备510中的至少一个的关于PAN通信已被建立的通知，该通知在能够对与通信设备510中的至少一个相关联的应用进行调整的远程实体(例如呼叫控制器155)处被接收。在其他实施例中，对通信设备510之间是否已建立PAN通信会话的判定包括远程实体就是否已建立PAN通信会话而查询通信设备510中的至少一个并且作为回复接收通知。在其他实施例中，PAN通信会话的可用性(即，如果需要可以建立PAN)可以触发对邻近性的通知，或者可以用于在被本地或远程实体查询时确认邻近性。这种通知和/或查询可以作为步骤710的一部分发生。

在一些实施例中，在步骤720，例如当要调整的应用具有基于邻近性和/或共位的不同模式时，可以确立邻近级别，如上所述。在一些实施例中，步骤720还可包括基于共同位于同一物理空间中来判定邻近级别，如前所述。例如，根据通过对在步骤705处判定的位置数据的处理所判定的，在步骤720可以判定通信设备510共同位于同一物理域/空间(房间、公共空间等等)中。在一些实施例中，这种处理还可包括位置数据的相关和/或对描述通信设备510所在的物理空间的另外的数据(例如接线图数据、形状数据(例如物理空间和/或地理域的形状)等等)的处理，如上所述。步骤720可以与步骤710并行发生，或者在步骤710之后发生。

在步骤730，基于邻近性来调整与通信设备510中的至少一个相关联的应用，如上所述。一些被调整的应用可以被基于邻近性调整一次，以后邻近性的变化对于该应用来说是无关紧要的(例如，如果预先配设的回呼被禁用，则以后邻近性的变化对于回呼应用来说是无关紧要的)。但是，在一些实施例中，一旦在步骤710处最初判定了邻近性，就可以监视邻近性的变化，并且在步骤740，判定通信设备510之间的邻近性是否已改变(例如通信设备510变得更近或更远)。如果是，则在步骤710可以再次判定邻近性(或者作为替代，作为对邻近性变化的监视的一部分再次判定邻近性)，从而在步骤730可以再次调整应用。否则方法700在步骤750结束。

本领域的技术人员将会明白，在一些实施例中，PC/膝上型电脑115、IP电话110、瘦型客户端120、瘦型客户端服务器125、网络接入L2交换机140、L2交换机145、关联数据库150、呼叫控制器155、应用服务器160和/或通信设备510的功能可以利用预先编程的硬件或固件元件(例如，专用集成电路(ASIC)、电可擦除可编程只读存储器(EEPROM)，等等)或者其他有关组件来实现。在其他实施例中，PC/膝上型电脑115、IP电话110、瘦型客户端120、瘦型客户端服务器125、网络接入L2交换机140、L2交换机145、关联数据库150、呼叫控制器、应用服务器160和/或通信设备510的功能可以利用一计算装置来实现，该计算装置能够访问存储着计算机可读程序代码以供计算装置操作的代码存储器(未示出)或任何其他适当的计算机可读存储介质。例如，计算机可读程序代码可以被存储在固定的、有形的并且能被这些组件直接读取的介质(例如，可移动磁盘、CD-ROM、ROM、固定盘、USB驱动器)上。或者，计算机可读程序代码可以被远程存储，但是可以通过传输介质经由调制解调器或连接到网络(包括但不限于因特网)的其他接口设备被传输到这些组件。传输介质可以是非无线介质(例如，光通信线路或模拟通信线路)或无线介质(例如，微波、红外、自由空间光或其他传输方案)或其组合。

本领域的技术人员将会明白，还有其他可能用来实现实施例的替换实现方式和修改，并且以上实现方式和示例只是对一个或多个实施例的例示。因此，范围仅由所附权利要求所限。

本申请是2008年1月4日提交并通过引用并入在此的申请No.12/006,651的部分继续案。

Claims (10)

1.一种对与第一通信设备和第二通信设备中的至少一个相关联的应用进行调整的方法，包括：

判定所述第一通信设备和所述第二通信设备之间的邻近性；以及

基于所述邻近性来对与所述第一通信设备和所述第二通信设备中的至少一个相关联的所述应用进行调整。

2.如权利要求1所述的方法，其中，所述判定所述第一通信设备和所述第二通信设备之间的邻近性包括以下各项中的至少一个：判定所述第一通信设备和所述第二通信设备是否已建立个域网通信会话，判定所述第一通信设备和所述第二通信设备是否能够建立个域网通信会话。

3.如权利要求1所述的方法，其中，所述判定所述第一通信设备和所述第二通信设备之间的邻近性包括，

判定第一位置，所述第一位置包括所述第一通信设备的位置；

判定第二位置，所述第二位置包括所述第二通信设备的位置；以及

判定所述第一位置和所述第二位置是否与彼此邻近。

4.如权利要求1所述的方法，其中所述应用包括与经由远离所述第一通信设备和所述第二通信设备的通信网络在所述第一通信设备和所述第二通信设备之间建立通信会话相关联的应用。

5.如权利要求1所述的方法，其中，所述判定所述第一通信设备和所述第二通信设备之间的邻近性包括判定所述第一通信设备和所述第二通信设备之间的邻近级别。

6.如权利要求1所述的方法，其中，对所述应用进行调整包括选择所述应用的多个模式之一，所述多个模式中的每一个与所述第一通信设备和所述第二通信设备之间的一个不同的邻近级别相关联。

7.如权利要求1所述的方法，其中，所述对所述应用进行调整包括以下各项中的至少一个：

在所述第一通信设备和所述第二通信设备邻近时，启用第一组预定义的特征；

在所述第一通信设备和所述第二通信设备邻近时，禁用第二组预定义的特征；

去除先前配设的回呼设定；

当在所述第一通信设备和所述第二通信设备之间建立通信会话时调整警告特征；以及

当发生对建立所述第一通信设备和所述第二通信设备之间的通信会话的尝试时，自动建立所述通信会话。

8.如权利要求3所述的方法，其中对所述第一位置的判定和对所述第二位置的判定中的至少一个是基于以下各项中的至少一个的：链路层数据、GPS数据、RF三角测量数据、用户数据、无线接入点数据和存储在数据库中的位置数据。

9.一种用于对与第一通信设备和第二通信设备中的至少一个相关联的应用进行调整的计算设备，包括：

通信接口，能够用于与所述第一通信设备和所述第二通信设备通信；

与所述通信接口通信的处理单元，能够用于：判定所述第一通信设备和所述第二通信设备之间的邻近性；以及基于所述邻近性来对与所述第一通信设备和所述第二通信设备中的至少一个相关联的所述应用进行调整。

10.一种对与第一通信设备和第二通信设备中的至少一个相关联的应用进行调整的方法，包括：

判定所述第一通信设备和所述第二通信设备之间的邻近级别；以及

通过选择所述应用的多个模式之一，来基于所述邻近级别对与所述第一通信设备和所述第二通信设备中的至少一个相关联的所述应用进行调整，所述多个模式中的每一个与所述第一通信设备和所述第二通信设备之间的一个不同的邻近级别相关联。

Images