CN103348633B - 用于管理不同的服务提供方之间的点对点连接的装置和方法 - Google Patents

Abstract

本发明公开了一种用于使用布隆过滤器来识别服务提供方的系统和方法。服务提供方以注册用户的用户ID码来生成布隆过滤器，并且相互交换布隆过滤器。第一服务提供方将查询其自身的数据库，以确定第一用户是否向第一服务提供方注册。如果第一用户没有向第一服务提供方注册，则第一服务提供方将查询其过滤器以识别第一用户可能注册的其他服务提供方。来自过滤器的肯定应答表明第一用户可能或者可能没有向与该过滤器相关的服务提供方注册，而否定应答确定地表明第一用户没向该提供方注册。定位第一用户的请求只被传输给对其已经接收到肯定的过滤器应答的那些服务提供方。

Description

用于管理不同的服务提供方之间的点对点连接的装置和方法

优先权声明

本申请要求在2011年3月21日提交的、题目为“Apparatus and Method forManaging Peer-To-Peer Connections Between Different Service Providers”的、序列号为61/454,930的美国临时申请的优先权。

技术领域

本发明总体涉及计算机网络领域。更特别地，本发明涉及用于管理移动设备之间的点对点（P2P）连接的改进装置和方法。

背景技术

A．网络地址转换（“NAT”）

大型公共网络（例如，因特网）频繁地连接到较小的专用网络（例如由企业、因特网服务提供方或者甚至是个体家庭维护的网络）。由于其本身性质，公共网络必须具有公认的网络地址分配，即，公共地址。由于各种原因，专用网络的维护者通常选择为专用网络使用不是公认分配的一部分的专用网络地址。因而，为了使来自专用网络的网络流量能够穿过公共网络，需要某种形式的专网/公网地址转换（“NAT”）。

进行NAT操作的设备修改从专用网络发送来的数据包，以符合公共网络的寻址方案。特别地，网络地址转换器用其自身的公共地址和分配的端口号来替代数据包始发的专用地址和端口号。网络地址转换器还修改为专用网络上的计算机而接收到的数据包，以用期望的接收者的正确专用地址和端口号来替代目标公共地址和端口号。如同本文所使用的，术语地址在适当的情况下在上下文中应当被解释为包含地址和端口号两者，这是本领域技术人员所应当理解的。

NAT在现代的网络计算中已越来越常见。NAT的一个优点是：它减缓了公共网络地址空间的消耗。例如，在因特网上使用的TCP/IP编址包括四个各自为三位数的字符串，因而提供了有限的地址空间。另外，该地址空间的某些部分被保留用于特定的用途或用户，进一步消耗了可用地址的实际数量。但是，如果使用NAT，则专用网络或子网可以使用任意数量的地址，并且对外部世界仍然仅呈现单个的、标准的公共地址。这使得可用地址的数量实际上是无限的，因为每个专用网络在理论上都能够使用完全相同的专用地址。

由NAT赋予的一个优点是安全性提高，这是因为：在公共网络上的装置无法确定在专用网络上的计算机的实际（即，专用）网络地址。这是因为网络地址转换器在公共网络上仅提供公共地址。另外，该公共地址可以对应于专用网络上的任意数量的计算机。

不同的NAT类型采用不同的安全级别。例如，对于“完全锥型NAT（full coneNAT）”，一旦内部地址（iAddr:iPort）被映射到外部地址（eAddr:ePort），则任何外部主机都能够通过给eAddr:ePort发送数据包来给iAddr:iPort发送数据包。对于“受限锥型NAT（Restricted cone NAT）”，只有在iAddr:iPort先前已经给hAddr发送过数据包时，具有地址hAddr的外部主机才能够通过给eAddr:ePort发送数据包来给iAddr:iPort发送数据包。外部主机的端口是不相关的。对于“端口受限锥型NAT（Port Restricted Cone NAT）”，只有在iAddr:iPort先前给hAddr:hPort发送过数据包时，具有地址/端口hAddr:hPort的外部主机才能够通过给eAddr:ePort发送数据包来给iAddr:iPort发送数据包。最后，对于对称型NAT，从同一iAddr:iPort到具体的目标IP地址和端口的每个请求都被映射到唯一的eAddr:ePort。如果同一内部主机给不同的目标发送数据包，则使用不同的外部地址和端口映射。只有从内部主机接收数据包的外部主机能够将数据包发回到内部主机。

B．点对点网络的NAT问题

点对点（“P2P”）计算指的是分布式网络体系结构，包括使其资源的一部分可被其他网络参与者直接使用的计算节点。在P2P网络中的对等点彼此间建立直接的通信信道，并且充当客户端和服务器两者，与其中服务器供应资源而客户端消费资源的传统的客户端-服务器模型不同。

以上所描述的NAT操作给P2P连接造成了众多的问题。例如，如果一个或两个对等点位于上述类型的一个或多个NAT之后，则在两个对等点之间建立直接的连接变得越来越困难。这个问题因以下事实而加剧：诸如Apple iPod、Apple、Apple和各种其他设备（例如，RIM设备、Palm设备等）之类的移动设备被频繁地在具有不同NAT实现方式的网络之间移动。例如，Apple iPhoneTM能够通过Wi-Fi网络（例如，802.11b,g,n网络）、3G网络（例如，通用移动通信系统（“UMTS”）网络、高速上行链路分组接入（“HSUPA”）网络等）以及蓝牙网络（称为个人局域网（“PAN”））来通信。未来的移动设备将能够通过另外的通信信道来通信，例如，WiMAX、高级国际移动通信（“IMT”）和高级长期演进（“LTE”），仅列举几个。

发明内容

本发明公开了一种用于使用布隆过滤器（bloom filter）来识别服务提供方的系统和方法。在本发明的一种实施例中，服务提供方利用注册用户的用户ID码来生成布隆过滤器，并且相互交换布隆过滤器。响应于定位第一用户的请求，第一服务提供方将查询其自身的注册数据库，以确定第一用户是否已向第一服务提供方注册。如果第一用户没有向第一服务提供方注册，则第一服务提供方将查询其布隆过滤器，以识别第一用户可能已向其注册的其他服务提供方。来自布隆过滤器的肯定应答表明第一用户可能已向或者可能没向与该布隆过滤器相关的服务提供方注册，而否定应答确定地表明第一用户没向与该布隆过滤器相关的服务提供方注册。定位第一用户的请求只被传输给已经接收到肯定的布隆过滤器应答的那些服务提供方。

附图说明

结合附图根据下面的详细描述能够获得对本发明的更好理解，在附图中：

图1示出了其中一组移动设备和服务通过网络进行通信的网络体系结构。

图2a-c示出了在连接数据交换（CDX）服务、匹配器服务和/或邀请服务的一种实施例之间的处理。

图3示出了权证（ticket）数据结构的一种实施例。

图4示出了由CDX服务实现的方法的一种实施例。

图5示出了由移动设备实现的方法的一种实施例。

图6示出了通过主通信信道和次通信信道连接的一组移动设备。

图7示出了用于在主通信信道和次通信信道当中进行选择的移动设备的一种实施例。

图8a-b示出了通过主通信信道和次通信信道连接的一组移动设备以及所产生的网络拓扑。

图9示出了用于在主通信信道和次通信信道之间进行选择的计算机实现的方法的一种实施例。

图10示出了其中一组移动设备和服务（包括目录服务和推送通知服务）通过网络进行通信的网络体系结构。

图11示出了在邀请服务、推送通知服务和连接数据交换（CDX）服务的一种实施例之间的处理。

图12示出了在邀请服务、推送通知服务和中继服务的一种实施例之间的处理。

图13示出了用于在两个或多个移动设备之间建立中继连接的中继服务的一种实施例。

图14示出了用于确定NAT兼容性的NAT兼容性图表的一种实施例。

图15示出了用于为在线应用匹配移动设备的匹配器服务的一种实施例。

图16示出了用于匹配用户/设备的方法的一种实施例。

图17a-d示出了为匹配用户/设备而进行的一系列示例性的表格更新。

图18示出了用于使用不同的匹配变量（match fit variable）来匹配用户/设备的一种方法。

图19示出了使用于应用的应用编程接口（API）与跟一组服务进行通信的服务API露出的框架。

图20示出了具有用于应用的API、游戏守护程序以及用于与服务进行通信的游戏服务模块的游戏框架的一种实施例。

图21示出了API实现的软件构件和API调用的软件构件的一种实施例。

图22示出了其中在操作系统、服务和应用之间进行API调用的一种实施例。

图23示出了示例性计算机系统体系结构的一种实施例。

图24示出了示例性计算机系统体系结构的另一种实施例。

图25示出了通过多个不同的服务提供方连接的多个用户。

图26示出了采用布隆过滤器来识别用户的位置的本发明的一种实施例。

图27示出了用于使用布隆过滤器的方法的一种实施例。

图28示出了用于使用布隆过滤器的方法的另一种实施例。

图29示出了根据本发明的一种实施例建立点对点（P2P）连接的两个用户。

图30示出了通过由特定的服务提供方使用的中继服务建立P2P连接的两个用户。

图31示出了用于通过中继服务建立P2P连接的本发明的一种实施例。

图32示出了具有在本发明的一种实施例中采用的RFC3984报头的RTP包。

图33示出了推送通知服务和安全的即时通信服务。

图34示出了用于建立安全的即时通信会话的方法的一种实施例。

图35示出了用于建立安全的即时通信会话的方法的另一种实施例。

图36示出了包括识别服务和应用认证服务的系统体系结构。

图37示出了用于安全地认证用户的方法的一种实施例。

图38示出了使用高速缓存和指纹来提高认证效率的本发明的一种实施例。

具体实施方式

下面描述用于在网络上建立、保持和利用主要的和/或备用的点对点（“P2P”）通信信道的装置、方法和机器可读介质的实施例。同样描述分别用于为P2P会话邀请用户和匹配用户的邀请服务和匹配器服务。另外，描述允许用户在某些指定的条件下建立中继连接的中继服务。最后，描述允许应用开发人员设计利用本文所描述的各种协同的在线特征的应用的应用框架以及关联的应用程序接口（API）。

在整个描述中，出于解释的目的，众多具体细节被阐明以便提供对本发明的全面理解。但是，本领域技术人员应当清楚，本发明可以在没有这些具体细节中的某些细节的情况下实行。在其他情况下，众所周知的结构和设备将不会示出或者以框图的形式示出，以避免使本发明的基本原理模糊。

用于高效地且安全地交换连接数据的装置和方法

如图1所示，在本发明的一种实施例中实现的通用网络拓扑能够包括一组分别通过网络120相互间通信以及与一个或多个服务110-112通信的“客户端”或“对等点”的移动计算设备A-D120-123。虽然在图1中被示为单个网络云，但是“网络”120能够包括各种不同的构件，包括公共网络（例如，因特网）和专用网络（例如，Wi-Fi局域网（例如，802.11n家用无线网或无线热点）、局域以太网、蜂窝数据网络（例如，3G、Edge等）以及WiMAX网络，仅列举数例）。例如，移动设备A120可以连接至家用Wi-Fi网络，由网络链路125表示；移动设备B121可以连接至3G网络（例如，通用移动通信系统（“UMTS”）、高速上行链路分组接入（“HSUPA”）等），由网络链路126表示；移动设备C122可以连接至WiMAX网络，由网络链路127表示；以及移动设备123可以连接至公共Wi-Fi网络，由网络链路128表示。通过其来连接移动设备120-123的局域网络链路125-128每个都可以通过网关和/或NAT设备（在图1中未示出）耦接至公共网络（例如，因特网），由此使得不同的移动设备120-123之间能够通过公共网络进行通信。但是，如果两个移动设备在同一局域网或专用网络（例如，同一Wi-Fi网络）上，则两个设备可以通过该局域网/专用网络直接通信，绕开公共网络。当然，应当注意，本发明的基本原理并不限定于任何特定的一组网络类型或网络拓扑。

在图1中示出的移动设备120-123中的每个都能够与连接数据交换（CDX）服务110、匹配器服务111及邀请服务112通信。在一种实施例中，服务110-112能够被实现为在一个或多个实体计算设备（例如，服务器）上执行的软件。如图1所示，在一种实施例中，服务110-112可以被实现于较大的数据服务100的环境中，该较大的数据服务100由同一实体（例如，同一数据服务提供方）管理并且可由每个移动设备120-123通过网络120来访问。数据服务100能够包括连接各种类型的服务器和数据库的局域网（例如，基于以太网的LAN）。数据服务100还可以包括用于存储数据的一个或多个存储区域网络（“SAN”）。在一种实施例中，数据库存储并管理与每个移动设备120-123以及这些设备的用户相关的数据（例如，用户账号数据、设备账号数据、用户应用数据等）。

在一种实施例中，匹配器服务111能够基于一组指定的条件来匹配用于协同的P2P会话的两个或更多个移动设备。例如，两个或更多个移动设备的用户可能对玩特定的多玩家游戏感兴趣。在这种情况下，匹配器服务111可以基于诸如每个用户的专门技能水平、每个用户的年龄、匹配请求的定时、请求匹配的特定游戏以及各种游戏特定变量之类的变量来识别参与该游戏的一组移动设备。举例来说（但不作为限定），匹配器服务111可以试图匹配在玩某种游戏方面具有类似的专门技能水平的用户。另外，成人可以与其他成人匹配，而儿童可以与其他儿童匹配。而且，匹配器服务111可以基于收到那些请求的顺序来按优先排序用户的请求。本发明的基本原理并不限定于任何一组特定的匹配标准或者任何特定类型的P2P应用。

如同下文将详细描述的，响应于匹配请求，匹配器服务111能够与CDX服务110协调，以确保所有被匹配的参与者都以高效且安全的方式接收用于建立P2P会话的必要连接数据。

在一种实施例中，邀请服务112还识别出参与到协同的P2P会话的移动设备。但是，在邀请服务112的情况下，至少一个参与者由另一个参与者特别地识别。例如，移动设备A120的用户可以特别地请求与移动设备B121的用户的协同会话（例如，以用户ID或电话号码来识别移动设备B）。如同匹配器服务111一样，响应于邀请请求，邀请服务112能够识别该组参与者并且与CDX服务110协调，以确保所有参与者都以高效且安全的方式接收用于建立P2P会话的必要连接数据。

如上所述，在一种实施例中，CDX服务110作为用于连接数据的中央交换点来操作，所述连接数据是在两个或更多个移动设备之间建立P2P会话所需要的。特别地，CDX服务的一种实施例响应于移动设备请求而生成NAT穿越数据（有时称为“打孔（Hole Punch）”数据），以使外部服务和客户端能够通过每个移动设备的NAT来通信（即，“打孔”通过NAT以达到设备）。例如，在一种实施例中，CDX服务检测与移动设备通信所需的外部IP地址和端口，并且将该信息提供给移动设备。在一种实施例中，CDX服务还接收并处理由匹配器服务111和邀请服务112生成的移动设备列表，并且高效且安全地将连接数据分发给包含于列表内的每个移动设备（这将在下文详细描述）。

在一种实施例中，在移动设备与CDX服务110之间的通信使用相对较简便的网络协议（例如，用户数据报协议（“UDP”）套接字）来建立。如同本领域技术人员所已知的，UDP套接字连接不需要握手对话来确保数据包的可靠性、顺序或数据完整性，并且因此不会消耗TCP套接字连接那样多的数据包处理开销。因此，UDP的简便的、无状态性质对于回答大量客户端的小查询的服务器是有用的。而且，与TCP不同，UDP兼容数据包广播（其中数据包被发送给局域网上的所有设备）和多播（其中数据被发送给局域网上的设备的一个子集）。如下所述，即便可以使用UDP，也能够通过使用会话密钥加密NAT穿越数据来在CDX服务110上保持安全性。

与CDX服务110所使用的低开销的简便型网络协议相比，在一种实施例中，在移动设备120-123与匹配器服务111和/或邀请服务112之间的通信以固有的安全的网络协议（例如，安全超文本传送协议（“HTTPS”））来建立，该网络协议依靠安全套接字层（“SSL”）或者传输层安全（“TLS”）连接。有关这些协议的细节是本领域技术人员所熟知的。

图2a示出了能够由CDX服务器实现的一系列示例性处理。在描述CDX服务的一种实施例的操作时，下列术语应当具有以下意思。

连接数据——这是潜在的对等点需要相互交换以建立点对点会话的信息。以下将描述如何交换该信息的机制的实施例。

CDX服务器——CDX服务器在一种实施例中是允许已授权的实体交换任意数据的认证的多播反射器。该数据被称为有效载荷（Payload）。

CDX会话——CDX会话指的是能够经由CDX服务器彼此通信的一组客户端设备。作为会话的一部分的每个客户端设备都被分配一个CDX权证。每个会话都具有唯一的CDX会话ID，该CDX会话ID是能够用来识别或指代单独会话的大整数。

CDX请求——从客户端设备发送给CDX服务器的请求。请求一般地包括两个部分：CDX权证和有效载荷。在本实施例中，有效载荷是以会话密钥加密的连接数据。

CDX应答——CDX应答是在CDX服务器接收到来自CDX会话的成员的CDX请求时“反射”回到CDX会话内的其他设备的内容。它通过将有效载荷附加于在给定的CDX请求中使用的CDX权证的CDX权证存根（stub）来构造。

CDX权证——CDX权证告知CDX服务器如何将有效载荷发送给CDX会话的成员。在一种实施例中，它以CDX权证密钥来签名以防止伪造或篡改。如图3所示，在一种实施例中，CDX权证含有下列信息：

在一种实施例中不被加密或混淆的会话ID301。

在一种实施例中不被加密或混淆的会话的参与者数量302。

在该权证指代的会话中的参与者的索引303（在一种实施例中不被加密或混淆）。

在其之后权证将被视为无效的过期时间/日期304（在一种实施例中不被加密或混淆）。

在一种实施例中使用CDX权证密钥加密的、会话中的每个参与者的CDX打孔数据305-306。

充当确保权证认证的“数字签名”的、使用CDX权证密钥的消息认证码307。

CDX权证存根——CDX权证的第一部分，减去CDX打孔数据和消息认证码。

有效载荷——这是CDX请求和CDX应答的第二部分。有效载荷是客户端设备希望传输到CDX会话中的其他设备的数据。在本实施例中，有效载荷是以会话密钥加密的连接数据。在一种实施例中，CDX服务器不解密有效载荷，它只是简单地将其传递下去，不做改变。

会话密钥——这是由客户端用来加密连接数据的密钥。在一种实施例中，该密钥不为CDX服务器所知。在本实施例中，会话密钥由匹配服务生成并且连同它们的个体CDX权证一起被传输到客户端。

CDX权证密钥——这是用来创建并“签名”CDX权证的密钥。CDX权证密钥仅为CDX服务器以及生成CDX权证的服务所知，所述服务可以是匹配服务和/或邀请服务，如下所述。

CDX打孔请求——被用来从CDX服务器获得CDX打孔数据的特殊类型的CDX请求。

CDX打孔数据——这是描述CDX服务器如何能够将信息发送给初始请求它的客户端的不透明数据块（data blob）。它通过将CDX打孔请求发送给CDX服务器来获得。CDX打孔数据必须在能够生成CDX权证之前从CDX会话中的每个客户端设备收集。CDX打孔数据（有时称为“NAT穿越数据”）可以包括请求设备的公共IP地址和端口。

现在转至图2a，在一种实施例中，移动设备A120和移动设备B121能够执行协同应用，例如，需要与一个或多个其他计算设备进行P2P连接的多玩家游戏或协同聊天会话。在201a中，移动设备A120给CDX服务器110发送CDX打孔请求。然后，CDX服务器110在202a以CDX打孔数据作为应答。在一种实施例中，打孔数据包括移动设备A的公共IP地址和端口，和/或打孔通过移动设备A的NAT所需的任何其他数据（例如，定义移动设备A的NAT类型的NAT类型数据）。对于移动设备B分别在201b和202b中进行类似的处理。

在203a和203b中，移动设备A和B然后将包含CDX打孔数据的匹配请求连同任何附加的匹配标准（在下文描述）一起发送给匹配服务。在该阶段，移动设备A和B可以开始构造建立P2P连接所需的连接数据。例如，这可以使用诸如标准的因特网连接建立（“ICE”）处理之类的处理（例如，通过NAT穿越服务）来完成。但是，本发明的基本原理并不限定于用于确定连接数据的任何特定机制。

在一种实施例中，一旦匹配服务111以匹配标准找到了一组客户端设备，它就可以生成唯一的CDX会话ID、用于CDX会话的每个成员的唯一的CDX权证以及唯一的会话密钥。在一种实施例中，匹配服务111可以使用唯一的CDX权证密钥来加密CDX权证的CDX打孔数据。在204a和204b，匹配服务然后可以给移动设备A和B中的每一个发送它们的CDX权证和会话密钥。

移动设备A接收CDX权证和会话密钥，并且使用会话密钥来加密其先前确定的连接数据，形成有效载荷。在一种实施例中，移动设备A通过将所构造的有效载荷附加于CDX权证来构造CDX请求。在205a，移动设备A将CDX请求发送给CDX服务器110。移动设备B同样能够进行相同的操作并且在205b向CDX服务器发送请求。

在206a，CDX服务器110接收CDX请求，检查权证以确保它是有效且已认证的（例如，基于消息认证码307）。如果CDX权证无效，则请求被丢弃。在一种实施例中，CDX服务器然后使用CDX权证密钥来解密包含于CDX权证内的CDX打孔数据集。在一种实施例中，CDX权证密钥能够包含同样可以与权证一起发送的过期时间/日期。CDX服务110和匹配器服务111能够存储两个（或更多个）不同的CDX权证密钥用于加密/解密——当前活动的第一个CDX权证密钥以及在第一个达到过期时间/日期时将变为活动的第二个CDX权证密钥。在接收到权证时，CDX服务110能够读取过期时间/日期以确定要使用哪个权证密钥。当CDX权证密钥过期时，CDX服务110和匹配器服务111两者都能够各自生成新的权证密钥（该新的权证密钥将为在当前权证密钥过期之后使用的下一密钥）。在一种实施例中，CDX服务110和匹配器服务111执行相同的密钥生成算法以确保与两个权证密钥的一致性。例如，可以将诸如众所周知的RSA SecurID认证机制所使用的那些技术之类的技术，使用于以固定的间隔生成新的认证码。在一种实施例中，每天生成新的CDX权证密钥。但是，本发明的基本原理并不限定于用于生成CDX权证密钥的任何特定机制。

对移动设备B能够进行相同的操作，如206b所示。CDX服务器根据CDX请求来构造CDX应答，并且然后使用CDX打孔数据将CDX应答发送给CDX会话中的参与者（在207a发送给移动设备B以及在207b发送给移动设备A）。

移动设备B接收来自CDX服务器的CDX应答207a。客户端设备B检查CDX权证存根以确保会话ID匹配其自身的CDX权证的会话ID。移动设备B然后可以使用会话密钥来解密有效载荷，得到来自移动设备A的连接数据。移动设备B然后使用来自移动设备A的连接数据来开始建立P2P会话的处理。在一种实施例中，这些涉及标准的ICE处理。但是，本发明的基本原理并不限定于用于建立P2P通信的任何特定机制。

如上所述，在一种实施例中，移动设备A和B建立安全超文本传送协议（“HTTPS”）会话以与匹配器服务111通信（例如，使用HTTPS请求/应答处理），并且建立UPD套接字以与CDX服务通信。匹配请求204a、204b能够包含先前为每一个移动设备确定的NAT类型和打孔数据（例如，公共IP地址和端口）。在涉及多玩家游戏的实施例中，每个匹配请求都能够识别在每个移动设备上的玩家（例如，使用唯一的玩家ID码）、每个用户都希望玩的游戏、参与游戏的玩家数，和/或与所期望的游戏相关的其他游戏配置变量。举例来说（但不作为限定），与游戏相关的游戏配置变量可以包括难度等级（例如，容易、普通、困难）、用户年龄（例如，“13岁以下”）、游戏子区（例如，“等级2”），和/或玩家专门技能等级（例如，专家、新手、中级玩家）。如同下文将详细描述的，这些变量有时被称为游戏“桶（bucket）”，并且使用唯一的“桶ID”来识别。每个游戏都可以包括不同的桶ID组，以识别不同的游戏配置变量。

在一种实施例中，在208a和209a，移动设备B发送确认。类似地，移动设备A的确认在208b和209b被发送。如果在指定的时间段后没有接收到移动设备A的或B的确认，则可以给移动设备B212重新发送连接数据207a。CDX服务110可以发起重试，和/或移动设备A120可以发起重试。

图2b示出了其中三个不同的移动设备120-122使用CDX服务和匹配器服务111来针对P2P连接进行协商的更详细的实例。图2b还示出了由移动设备120-122用来建立连接的两个附加服务：用于确定NAT类型的NAT穿越服务291以及用于确定每个移动设备的完全连接数据（例如，利用ICE连接数据处理）的NAT穿越服务290。但是，应当注意，单独的服务不需要符合本发明的基本原理。例如，在一种另选的实施例中，由这些服务290-291中的每个服务执行的NAT穿越功能可以直接集成于CDX服务110和/或匹配器服务111之内。类似地，由NAT穿越服务290-291两者执行的功能可以集成于单个NAT穿越服务之内。总之，在图2b中示出的具体功能分离不需要符合本发明的基本原理。

现在转至图2b的具体细节，在220中，移动设备A将NAT类型请求发送给NAT穿越服务291。作为响应，NAT穿越服务291可以使用包括实现一系列处理在内的各种已知技术来确定移动设备A所使用的NAT类型。例如，NAT穿越服务291可以尝试在移动设备A的NAT上打开不同的IP地址和端口，并且使用不同的IP/端口组合通过这些端口与移动设备A通信。以此方式，移动设备A所采用的NAT可以被归类为以上所述的NAT类型（例如，完全锥型、受限锥型、端口受限锥型、对称型）或者另选的NAT类型之一。然后，该信息可以被提供给移动设备A120，如图所示。

在221，移动设备A120对CDX服务110发起NAT穿越请求。作为响应，CDX服务110能够读出用于该请求的公共IP地址和公共端口号，并且将该信息发送回到移动设备A120。如上所述，如果设备位于NAT之后，则其公共端口和IP地址将分别不同于其专用端口和IP地址。因而，取决于所使用的NAT的类型，公共IP地址和端口可以被用来“打孔”通过NAT设备以达到移动设备。

在222，移动设备A120对匹配器服务111发送匹配请求222。如上所述，在一种实施例中，移动设备A使用安全超文本传送协议（“HTTPS”）会话（例如，使用HTTPS请求/应答处理）来与匹配器服务111通信。匹配请求能够包括先前为移动设备A120确定的NAT类型和打孔数据（例如，公共IP地址和端口）。在涉及多玩家游戏的实施例中，匹配请求能够识别出移动设备A上的玩家（例如，使用唯一的玩家ID码）、用户希望玩的游戏、参与游戏的玩家数，和/或与所期望的游戏相关的其他游戏配置变量（如同先前关于图2a所描述的）。

在223-225，对移动设备B121进行与处理220-222对应的一组处理，并且在226-228中，对移动设备C122进行与处理220-222对应的一组处理。因而，在处理228之后，匹配器服务111接收到了所有三个移动设备120-122的匹配请求。在该具体实例中，匹配请求导致移动设备120-122被匹配用于特定的协同会话，诸如多玩家游戏（例如，这些移动设备的用户可能选择了具有相同的或类似的变量集的相同游戏，由此通过匹配器服务111产生匹配）。

匹配器服务111使用包含于每个匹配请求内的数据来生成：由它在229发送给移动设备A的权证A；由它在230发送给移动设备B的权证B；以及由它在231发送给移动设备C的权证C。虽然在图2b中未示出，但是匹配器服务111可以利用推送通知服务（例如，图11-12所示的推送通知服务1050）来将权证A、B和C分别推送给移动设备A、B和C。用于权证A、B和C的权证数据结构的一种实施例已在上文关于图3进行了描述。

在232中，移动设备A120与NAT穿越服务290进行通信以确定其自身的连接数据。在一种实施例中，这能够包括标准的ICE连接数据处理。如先前提到的，连接数据可以包括用于移动设备A120的公共/专用IP地址、端口及NAT类型。

移动设备A120将其连接数据附加于权证A，并且在233中将具有连接数据的权证A发送给CDX服务110。在一种实施例中，CDX服务110如同以上所描述的那样处理权证A，并且在234中将连接数据（该连接数据可以是加密的）发送给移动设备B121和移动设备C122。对于这些处理，CDX服务110能够利用权证A包含的用于移动设备B和C的NAT穿越数据。

在236-238中，使用权证B来进行与处理232-234对应的一组处理，并且在238-240中，对权证C进行与处理232-234对应的一组处理。因而，在处理240之后，连接数据已经在每个移动设备120-122之间被共享。使用连接数据，P2P会话被建立于移动设备A和B之间、移动设备A和C之间以及移动设备A和C之间。

如图2c所示，邀请服务112同样能够与CDX服务110一起使用（或者代替匹配器服务111或者除匹配器服务111之外还使用它）。在一种实施例中，邀请服务112处理用于与具体移动设备和/或用户的P2P连接的邀请请求。邀请服务112能够被实现为无状态服务（即，不附加在每个无线设备之间的处理的当前状态的服务）。

转至该特定实例，在250中，移动设备A120将NAT类型请求发送给NAT穿越服务291。作为响应，NAT穿越服务291可以使用用于确定移动设备A所使用的NAT类型的各种已知技术（这些技术中的某些已在上文描述）。在251中，移动设备A120对CDX服务110发起NAT穿越请求。作为响应，CDX服务110能够读取用于该请求的公共IP地址和公共端口号，并且将该信息发送回到移动设备A120。如上所述，如果设备位于NAT之后，其公共端口和IP地址将分别不同于其专用端口和IP地址。因而，取决于所使用的NAT的类型，公共IP地址和端口可以被用来“打孔”穿过NAT设备以达到移动设备。

如同匹配器服务一样，在一种实施例中，每个移动设备都使用安全超文本传送协议（“HTTPS”）会话（例如，使用HTTPS请求/应答处理）来与邀请服务112进行通信。

在252中，移动设备A120将包括移动设备A的NAT穿越数据（例如，NAT类型、公共IP地址/端口）的邀请请求发送给邀请服务112。在利用推送通知服务（将在下文更详细地描述）的实施例中，邀请请求同样可以包括移动设备A的推送令牌。邀请请求252同样能够包括用于识别一个或多个其他用户/设备（在本例中为移动设备B121和C122的用户）的识别码。各种不同的识别码类型都可以使用。例如，在多玩家游戏的情况下，识别码可以包括游戏专用的玩家ID码。在音频/视频聊天会话的情况下，识别码可以包括从移动设备A的“好友”列表中识别出一个或多个用户的电话号码或者唯一的ID码。

在一种实施例中，邀请服务112从邀请请求中读出识别码，并且在注册数据库（未示出）中进行查找以定位每个移动设备B和C。在一种特定的实施例中，移动设备B和C中的每一个先前已向推送服务注册，以接收来自邀请服务112的推送通知。照此，在本实施例中，邀请服务112使用推送通知服务，分别在253和254中将邀请请求推送给移动设备B121和移动设备C122。有关推送通知服务的附加的细节在下文（例如，参见图11-12及相关的文字）以及在上文所引用的推送通知应用中描述。

在一种实施例中，邀请请求253和254包括图3所示的并在上文关于图2a-b所描述的权证数据结构。特别地，发送给移动设备B的权证包括用于识别移动设备A和B的加密列表，并且发送给移动设备C的权证包括用于识别移动设备A和C的加密列表。在一种实施例中，因为邀请服务112可能尚未具有移动设备B的NAT穿越数据，所以在253中“权证”可以包括用于识别移动设备B的其他信息。例如，如同下文关于利用中继服务和推送通知服务的实施例（例如，参见图11-12）所阐明的那样，在253中“权证”可以包括用于移动设备A的NAT穿越数据、设备A的ID码、设备A的推送令牌、设备B的ID码以及用于移动设备B的推送令牌。对于移动设备A和C，可以在254中提供相同类型的信息。

在255中，移动设备B可以与NAT穿越服务291进行通信以确定其NAT类型，并且在256中，移动设备B可以与CDX服务110进行通信以确定其NAT穿越数据（例如，公共IP地址/端口）。在257中，移动设备B将含有移动设备A的和移动设备B的识别码、NAT穿越数据以及用于移动设备A和B的推送令牌（如果使用推送通知服务的话）的邀请应答发送给邀请服务112。在258中，移动设备B能够通过与NAT穿越服务290进行通信来检索其当前的连接数据。在259中，移动设备将它的具有它的当前连接数据的权证（权证B）发送给CDX服务110。作为响应，CDX服务110如同上文所描述的那样处理该权证，并且将连接数据转发给移动设备A120。

在接收到移动设备B的邀请应答时，邀请服务112能够生成用于移动设备A的加密权证并且在260中将该权证发送给移动设备A。在一种实施例中，权证包含用于移动设备A和B的NAT穿越数据、NAT类型和推送令牌（如果使用推送通知服务的话）。关于图2c所描述的“权证”可以是与关于匹配器服务111所描述的权证相同的或不同的数据结构。例如，邀请服务112可以简单地生成唯一的会话ID来识别出与每个移动设备的邀请会话，而不是如同以上所描述的那样生成加密的“权证”。

在261中，移动设备A通过与NAT穿越服务290进行通信来检索其当前的连接数据。然后，移动设备A可以将其连接数据附加于权证，并且在262中，将权证连同其连接数据发送给CDX服务110。CDX服务110如同以上所描述的那样处理该权证，并且将移动设备A的连接数据转发给移动设备B。最后，在263中，移动设备A和B使用所交换的连接数据来打开直接的P2P连接。如同下文将描述的，在移动设备A和B的NAT类型不兼容的情形中，可以使用中继服务来使在移动设备A和B之间能够进行通信。

在264-272中，移动设备C122和移动设备A能够如同在255-263中针对移动设备B和A所描述的那样执行一系列处理以建立P2P连接。特别地，在624中，移动设备C122与NAT穿越服务291进行通信以确定其NAT类型，并且在265中与CDX服务110进行通信以确定其NAT穿越数据（例如，公共IP地址/端口）。在266中，移动设备C发送含有移动设备C和移动设备A的NAT类型、NAT穿越数据和推送令牌（如果使用推送通知服务的话）的邀请应答。在267中，移动设备C通过NAT穿越P2P服务290来检索其当前的连接数据，并且在268中，移动设备C将其连接数据附加于权证C并将权证C发送给CDX服务110。CDX服务110如同上文所描述的那样处理权证，并且将移动设备C的连接数据转发给移动设备A120。

在269中，移动设备A120接收来自邀请服务112的移动设备C的邀请应答，该邀请应答包含移动设备A和C两者的NAT类型、NAT穿越数据和推送令牌（如果使用推送服务的话）。在270中，移动设备A检索来自NAT穿越服务290的其当前连接数据，将其当前的连接数据附加于权证A，并且在271中将权证A发送给CDX服务110。作为选择，可以不需要处理270，因为移动设备在处理261中确定其连接数据。CDX服务110如同上文所描述的那样处理权证A，并且将移动设备A的连接数据转发给移动设备C。最后，在272，移动设备A和C使用所交换的连接数据来建立直接的P2P连接272。

在一种实施例中，邀请服务112和匹配器服务111能够依赖于用于将数据推送给移动设备的推送通知服务（未示出）。例如，在图2c中，邀请请求253和254可以经由推送通知服务被推送到移动设备B121和C122。类似地，在图2a中，权证A和B可以被推送到移动设备A120和B121。在一种实施例中，当移动设备在网络上被激活时，它在可由推送通知服务访问的中央注册目录中注册其推送令牌。在一种实施例中，注册目录将受密码保护的用户ID或电话号码与推送令牌相关联。如果在目录中能够识别出推送令牌，则推送通知服务能够使用推送令牌来将推送通知发送给移动设备。在一种实施例中，推送通知服务是由本申请的受让人设计的且在例如上文所提及的推送通知服务中描述的苹果推送通知服务（“APNS”）。但是，应当注意，推送通知服务并非是图2a-c所示的本发明的实施例所必需的。例如，推送通知并非是CDX服务110如同本文所描述的那样执行其操作所必需的。

图4示出了能够由CDX服务110实现、用以交换连接数据的一种方法，并且图5示出了可以由移动设备实现、用以交换连接数据并建立P2P连接的一种方法。这些方法的某些方面已经在上文关于图1-2c进行了描述。特别地，这些方法可以在图1-2c所示的网络体系结构的背景下实现，但是它们并不受限于这样的体系结构。在一种实施例中，这些方法以程序代码来体现，该程序代码在由处理器执行时会促使这些方法的操作被执行。程序代码可以存储于机器可读介质内，诸如随机存取存储器（“RAM”），同时被处理器执行。处理器可以是通用处理器（例如，Core^TM处理器）或专用处理器。但是，方法可以使用硬件、软件和固件的任意组合来实现。另外，程序代码可以存储于非易失性存储设备（如硬盘驱动器、光盘（例如，数字视频盘或压缩盘）或者非易失性存储器（如闪存设备）内。

现在转至图4所示的方法，在401中，接收用于特定移动设备（在本例中为“移动设备A”）的NAT穿越请求（有时也称为“打孔”请求）。在402中，NAT穿越应答被生成并被发送给移动设备A。在一种实施例中，生成NAT穿越应答能够包括确定移动设备A的当前公共IP地址/端口和/或NAT类型。

用于移动设备A的权证随后可以由权证生成实体（诸如，上文所述的匹配器服务111或邀请服务112）生成并加密。在403中，接收为移动设备A所生成的权证（“权证A”），该权证A包含NAT穿越数据（用于设备A以及一个或多个其他设备）以及用于设备A的连接数据。在404中，权证使用消息认证码来认证，并且打孔数据使用与权证生成实体用来加密权证相同的CDX权证密钥来被解密。如上所述，在一种实施例中，正确的CDX权证密钥使用与CDX权证密钥关联的过期时间/日期来识别。

在405中，提取用于移动设备的NAT穿越数据。在406中，使用NAT穿越数据将用于移动设备A的连接数据发送给每个对等点。在407，接收来自每个对等点的确认。如果在408中确定还没有接收到来自全部对等点的确认，则在409中，移动设备A的连接数据被重新发送给尚未应答的那些对等点。当在408中确定所有的连接数据都已被确认时，则方法结束。

在一种实施例中，图4所示的方法能够针对P2P处理所涉及的每个对等点执行，以确保每个对等点都接收到建立P2P连接所需的连接数据。

图5示出了根据本文所描述的本发明的实施例的能够由移动设备执行的一种方法。在501中，发送NAT穿越请求，并且在502中，接收NAT穿越应答。如上所述，包含于应答内的NAT穿越数据可以包括请求设备的公共端口/IP地址。在503中，发送含有NAT穿越数据的匹配请求。用于移动设备的权证随后可以由诸如上文所描述的匹配器服务111或邀请服务112之类的权证生成实体来生成并加密。作为上文所描述的权证数据结构的替代选择，匹配器服务111和/或邀请服务112可以使用唯一的会话ID简单地识别出每个参与者。

在504中，可以接收权证；在505中，用于移动设备的连接数据被附加于权证；并且，在506中，发送具有连接数据的权证。在507中，接收与一个或多个其他对等点建立P2P连接所需的连接数据。在508中，接收指示一个或多个其他无线设备已经接收到在506中所发送的连接数据的确认。如果并非所有确认都已接收到，则在510中，将连接数据重新发送给尚未从其处接收到确认的那些移动设备。如果在590中确定所有确认都已接收到，则使用在507中接收到的连接数据来建立与其他移动设备的P2P会话。

用于建立并利用备用通信信道的装置和方法

当前的移动设备能够通过各种不同的通信信道来进行通信。例如，苹果的iPhoneTM能够通过如下网络进行通信：Wi-Fi网络（例如，802.11b、g、n网络）；3G网络（例如，通用移动通信系统（“UMTS”）网络、高速上行链路分组接入（“HSUPA”）网络等）；以及蓝牙网络（被称为个人局域网（“PAN”））。未来的移动设备将能够通过另外的通信信道来进行通信，诸如WiMAX、高级国际移动通信（“IMT”）和高级长期演进（“LTE”），仅列举几个。

在操作中，当前的移动设备从一组可用信道当中选出一个主要的通信信道。例如，移动设备通常被配置为：若Wi-Fi可用则选择Wi-Fi连接，若Wi-Fi不可用则选择蜂窝数据连接（例如，UTMS连接）。

在本发明的一种实施例中，一组移动设备最初使用标准的ICE连接数据交换和/或使用上文所描述的连接数据交换技术来建立主要的点对点（“P2P”）通信信道。移动设备然后可以通过主信道来交换连接数据以建立一个或多个次通信信道，若任何主信道失效，该一个或多个次通信信道用作备用信道。在一种实施例中，通过周期性地通过这些次通信信道发送“心跳”数据包来使次通信信道保持开放地通过NAT防火墙。

如同本文所使用的，通信“信道”指的是在两个移动设备之间的完全网络通路，并且通信“链路”指的是在通信通路内使用的一个特定连接。例如，如果设备A使用Wi-Fi连接来连接至因特网，并且设备B使用3G连接来连接至因特网，则在设备A和设备B之间的“信道”由Wi-Fi链路和3G链路两者来界定，设备A具有Wi-Fi通信“链路”；而设备具有3G通信“链路”。照此，如果设备A从Wi-Fi链路切换至3G链路，则在设备A与设备B之间的“信道”被改变，然而设备B的3G链路仍保持不变。

现在将参照图6来描述其中移动设备建立主通信信道和次通信信道的具体实例。但是，应当注意，本发明的基本原理并不限定于图6所示的那组特定的通信链路和通信信道。

在图6中，移动设备A601能够通过与NAT设备611的通信链路605以及通过与NAT设备612的通信链路606连接至网络610（例如，因特网）。类似地，设备C603能够通过与NAT设备613的通信链路609以及通过与NAT设备613的网络链路610连接至网络610。举例来说（但不作为限定），通信链路605和609可以是3G通信链路，并且通信链路606和610可以是Wi-Fi通信链路。

因此，在本实例中，存在可以在移动设备A与移动设备B之间建立的四个不同的通信信道：使用链路605和609的第一信道；使用链路605和610的第二信道；使用链路606和609的第三信道；以及使用链路606和610的第四信道。在一种实施例中，移动设备A和B将基于优先排序方案来选择这些信道之一作为主通信信道，并且将选择三个剩余信道作为备用通信信道。例如，一种优先排序方案可以是选择具有最高宽带的信道作为主信道，并使用剩余信道作为次信道。如果两个或更多个信道具有相当的带宽，则优先排序方案可以包括选择最小花费的信道（假定用户付费使用一个或多个信道）。作为选择，优先排序方案可以是选择最小花费的信道作为主信道，并且如果每个信道的费用是相同的，则选择最高带宽的信道。可以实现各种不同优先排序方案，同时这些方案仍然符合本发明的基本原理。

移动设备A601和C603可以利用上文所述的技术来建立主通信信道（例如，通过经由CDX服务110来交换连接数据）。作为选择，移动设备601、603可以实现标准的因特网连接建立（“ICE”）处理以交换连接数据。不管主信道是如何建立的，一旦它建立了，移动设备A601和C603就可以通过主通信信道来交换用于次通信信道的连接数据。例如，如果主通信信道在图6中包括通信链路606和通信链路609，则该连接一旦建立就可以被用来交换用于包含通信链路605和609的次通信信道的连接数据。在本实例中，通过主通信信道交换的连接数据可以包括用于NAT611和NAT613的NAT穿越数据和NAT类型数据（包括每个移动设备的公共及专用IP地址/端口）。

一旦次通信信道建立了，它们就使用心跳数据包来保持打开。例如，设备A可以周期性地给设备C发送小的“心跳”数据包，和/或设备A可以周期性地给设备C发送小的“心跳”数据包以确保用于次信道的NAT端口保持打开（NAT通常会由于不活动而关闭端口）。心跳数据包可以是没有有效载荷的UDP数据包，但是本发明的基本原理并不限定于任何特定的数据包格式。心跳数据包可以是在其有效载荷报头中具有自识别型字段的UDP数据包，并且可以含有可选的另外格式化的信息，该信息包括（但不限于）信道的存活时间值（time-to-live value）。

如图7所示，每个移动设备601都存储并保持含有主通信信道以及次通信信道列表的数据结构710（例如，表格、文本文件、数据库等）。单独的条目被提供给每个通信信道，并且包含利用该信道所需的连接数据（例如，专用/公共IP地址、NAT类型等）以及该信道的当前状态（例如，主要、次要1、次要2等）。

在一种实施例中，通信接口701和702被用来分别通过通信链路605和通信链路606来进行通信。失效检测模块705能够在移动设备601上被执行，以检测出特定的通信接口/链路在何时失效或者降级到指定阈值以下。作为响应，链路管理模块706能够读出主/次连接数据710以将具有下一最高优先级的次信道提升为主信道。次信道的优先排序可以使用上文针对主信道所讨论的原理相同的原理来实现（例如，基于带宽、费用、可靠性等）。一旦次信道被选择，则链路管理模块706就能够将链路失效指示发送给其他移动设备上的链路管理模块，指示那些设备将次通信信道提升为主通信信道。那些设备然后将开始使用与被选择的主信道相关的连接数据。

在一种实施例中，并不需要主通信信道完全“失效”来迫使其切换至一个次通信信道。例如，在一种实施例中，如果主通信信道已充分降级（例如，在特定的带宽、比特率或可靠性阈值以下），则可以如同本文所描述的那样实现到次信道的改变。在一种实施例中，切换至次信道仅在相比当前主信道，次信道能够支持更好的性能（例如，带宽、比特流或可靠性）时才执行。

图8a示出了与如图6所示的相同的网络配置，添加了与网络610直接连接且通过专用网络连接620连接至设备C603的移动设备B602。专用网络620可以是例如在设备B602与设备C603之间的蓝牙PAN连接。从该实例可看出，从主信道到次信道的切换可以显著地改变网络拓扑。例如，如图8b所示，如果用于移动设备的主信道801包括通信链路609（导致设备A、B和C之间直接连接）并且次信道包括专用网络620，则网络拓扑可以改变为图8c所示的那样，因为设备A和设备C使用专用网络进行通信的唯一途径是通过设备B。虽然这是仅有三个设备的简化实例，但是可以使用数量显著较大的设备，从而当在主通信信道及次通信信道之间切换时产生各种不同的网络拓扑配置。

图8示出了用于建立并保持次信道的方法的一种实施例。在一种实施例中，该方法可以由在每个移动设备上的链路管理模块706执行。但是，该方法并不限定于任何特定的设备配置。

在901中，选择主P2P通信信道。如上所述，主通信信道可以基于预定义的优先排序方案来选择。例如，某些通信信道类型可以列于其他通信信道类型之前。信道同样可以基于诸如带宽、使用费用和/或可靠性之类的变量来按优先排序。

在902中，建立备用的P2P通信信道。在一种实施例中，这通过在所有移动设备之间通过主通信信道共享连接数据来实现。在903中，保持备用信道。在一种实施例中，这涉及通过次通信信道周期性地发送数据（例如，采用周期性心跳数据包的形式）。

在904中，如果主P2P信道失效（例如，因为特定移动设备的通信链路故障或者移动设备移出了通信链路的范围），则在905中，移动设备将最高优先级的备用信道提升为主信道。在一种实施例中，这涉及具有失效链路的移动设备通过次信道将其链路失效的通知发送给其他设备。最后，在906中，备用信道成为主信道，并且处理返回至902（在902中，任何另外的备用信道被发现并被添加至优先排序方案）。

用于为邀请服务建立点对点（P2P）通信信道的装置和方法

如图10所示，除了CDX服务110、匹配器服务111和邀请服务112（它们的某些实施例已在上文描述）之外，本发明的一种实施例还能够包括注册/目录服务1052、推送通知服务1050和中继服务1051。如上所述，在一种实施例中，邀请服务112和/或匹配器服务111能够使用注册/目录服务1052来识别已注册的移动设备，并且使用推送通知服务1050将数据推送给移动设备。在一种实施例中，当移动设备在网络上被激活时，它通过将推送令牌与受密码保护的用户ID或电话号码关联，来向由注册/目录服务1052保持的数据库注册“推送令牌”（在推送通知应用中有时称为“通知服务账号标识符”）。如果在注册目录中识别出推送令牌（例如，通过执行对用户ID的查询），推送通知服务1050能够使用推送令牌来给移动设备发送推送通知。在一种实施例中，推送通知服务是由本申请的受让人设计并且在例如上文提及的推送通知应用中描述的苹果推送通知服务（“APNS”）。

图11示出了其中推送通知服务1051被用来在两个移动设备之间建立直接的P2P连接的本发明的实施例，并且图12示出了用来通过中继服务1051建立P2P连接的实施例。如下所述，关于是否使用中继服务1051来建立P2P连接的判断可以基于在移动设备之间建立直接的P2P连接的可行性（例如，基于NAT兼容问题）。

现在转至图11，在1101中，移动设备A120发送邀请移动设备B121的邀请，以邀请移动设备B到P2P通信会话（例如，协同视频游戏、P2P视频聊天等）。在一种实施例中，邀请包括用于在特定的在线应用的环境中识别移动设备B121（和/或移动设备B的用户）的用户ID码。例如，用户ID码可以是用于特定的多玩家P2P游戏的玩家ID，并且可以采用例如通用唯一标识符（UUID）的形式。作为选择，在一些实施例中，ID码可以是移动设备B121的电话号码。游戏ID码可以被用来识别移动设备A正邀请移动设备B加入的多玩家游戏。桶ID可以被用来识别用于该游戏的配置（如在本文中关于匹配器服务所描述的）。

邀请1101同样可以包含用于识别移动设备A120的ID码以及与移动设备A关联的NAT穿越/连接数据（例如用于移动设备A的公共/专用IP地址和端口以及用于设备A的NAT设备的NAT类型）。NAT穿越/连接数据或NAT类型数据可以预先由移动设备A在邀请请求1101之前确定（例如，经由NAT穿越、NAT类型及连接数据处理，诸如上文关于图2a-c所讨论的那些）。如上所述，邀请请求1101能够采用HTTPS请求的形式。另外，为了额外的安全性，邀请请求1101能够包括由预先指定的证书授权机构签名的客户端证书。

与用来识别移动设备B的ID码的特定类型无关，ID码由邀请服务112接收，并且在1102中，邀请服务112能够进行在目录服务1052（在图11中未示出）内的查找，以识别通知服务帐号标识符（诸如用来给移动设备B推送通知的推送令牌（“推送令牌B”））。在一种实施例中，查找操作能够进行几种检查以确定是否允许该邀请。首先，它能够证实用于移动设备A的识别码（“ID-A”）和设备A的推送令牌（“推送令牌A”）是在目录服务数据库内的注册关联。查找操作1102同样能够证实移动设备A的用户被许可邀请移动设备B的用户（例如，移动设备B的用户能够指定只有注册为B的朋友的那些其他用户能够邀请用户B；或者能够指定不许可被邀请）。在一种实施例中，如果这些检查中的任一项失效，则取消邀请，并且邀请服务112给移动设备A返回错误。

虽然在本实施例中描述了“推送令牌”，但是应当注意，本发明的基本原理并不限定于使用“推送令牌”或者用于认证并给移动设备推送通知的任何其他特定数据结构。

在一种实施例中，在识别了推送令牌之后，邀请服务112能够生成被分配给邀请会话并被用来在所有进一步处理中识别会话的安全的一次性“会话令牌”。然后，会话令牌的副本被发送回到移动设备A120并且与邀请请求一起被发送给移动设备B。在一种实施例中，会话令牌与上文所述的权证数据结构一起使用，而在另一种实施例中，仅使用会话令牌。

在1103中，邀请服务112给推送通知服务1050发送推送请求。在一种实施例中，推送请求能够包括用于移动设备A的NAT穿越数据、移动设备A的ID码、推送令牌A、设备B的ID码以及推送令牌B。在一种实施例中，该信息能够被打包到“权证”数据结构中并且如同上文所描述的那样加密。在另一种实施例中，数据只是简单地与邀请会话ID一起发送。

因为移动设备B121在本例中已向推送通知服务1050注册，所以推送通知服务1050能够在1104中定位移动设备B121并给其推送邀请请求。所推送的邀请1104可以包括会话令牌、移动设备A的NAT穿越数据/连接数据以及移动设备B的ID码。响应于邀请请求，移动设备B可以通过如同上文所描述的那样调用NAT穿越服务或CDX服务110来确定其网络信息（例如，NAT穿越/连接数据、NAT类型等）。

在1105中，移动设备B接受邀请。接受1105可以采取对邀请服务112进行HTTPS调用的形式，并且可以包括由预先指定的证书授权机构（上文关于邀请请求所提及的）签名的客户端证书。在一种实施例中，接受1105能够包括用于移动设备A和B的ID码以及用于移动设备的A和B的NAT穿越/连接数据和/或NAT类型。接受1105同样可以包括用于移动设备A和B的推送令牌和/或会话令牌。在一种实施例中，接受1105同样可以含有关于它是否是来自先前失效的直接连接尝试的重试的指示。但是，在另一种实施例中，接受1105不含有重试指示。相反，在检测到失效的P2P连接尝试时，这两个移动设备之一可以给邀请服务112发送特殊的“重试邀请”。作为响应，服务可以直接发起以下关于图12所描述的一系列重试处理（从1201开始）。

在1106中，邀请服务112能够进行兼容性检查以确定在移动设备A和B之间的直接的P2P连接是否可行。例如，在一种实施例中，如果从移动设备B接收到的接受1105指示它是来自先前失效的直接连接尝试的重试（或者指定数量的先前失效的直接连接尝试），则邀请服务可以断定直接的P2P连接是不可行的。邀请服务112可以比较用于移动设备A和B的NAT类型数据，以确定移动设备A和B的NAT设备是否会支持直接的P2P连接。已经知道NAT类型的某些组合不可兼容用于建立P2P连接。例如，除了关闭的/带防火墙的NAT之外，完全锥型NAT可以与任何其他NAT类型一起被用来建立直接的P2P连接。相比之下，对称的NAT只能够与完全锥型NAT一起被用来建立直接的P2P连接。将各种NAT类型结合于本发明的一种实施例中的可行性在图14所示的NAT兼容表1400中进行了阐明，在该NAT兼容表1400中，列代表一个移动设备（例如，移动设备A）的NAT类型，而行代表另一移动设备（例如，移动设备B）的NAT类型。单元格内的“1.0”表明在关联的行和列内的NAT类型是兼容的，而“0.0”表明NAT类型是不兼容的。

在一种实施例中，如果兼容性检查1106确定直接的P2P连接是不可行的，则如同下文关于图12所描述，邀请服务112能够发送中继查找请求1201。但是，如果兼容性检查1106确定直接的P2P连接是可行的，则邀请服务112能够给推送通知服务1050发送含有移动设备B接受移动设备A的邀请的推送请求1107。推送请求1107以及随后从推送通知服务1050到移动设备A的推送通信1108能够包括会话令牌以及移动设备A和B两者的推送令牌、ID码和/或NAT穿越/连接数据。在一种实施例中，该信息可以被打包到上文所述的“权证”数据结构内（例如，参见图2a-c及相关的文字）并且可以使用唯一的密钥来加密。作为选择，该信息可以与唯一的邀请会话ID一起简单地发送。邀请服务1050还可以通知移动设备B：直接连接将被尝试。

在该阶段，移动设备A和B具有足够的信息来建立直接的P2P连接。在一种实施例中，这如同上文所描述的那样使用CDX服务110来完成。例如，移动设备B将其连接数据附加于权证B，并且在1109中将权证B（具有连接数据）发送给CDX服务。正好在该处理之前，移动设备B可以实现诸如图2b所示的处理235之类的处理以便确保其连接数据是当前的。CDX服务110然后对权证进行认证（例如，如同上文所描述的那样使用唯一的会话密钥），提取移动设备B的连接数据，并且在1110中将连接数据转发给移动设备A。类似地，移动设备A将其连接数据附加于权证A，并且在1111中将权证A（具有连接数据）发送给CDX服务110。正好在该处理之前，移动设备A可以实现诸如图2b所示的处理235之类的处理以便确保其连接数据是当前的。CDX服务110然后对权证进行认证（例如，如同上文所描述的那样使用唯一的会话密钥），提取移动设备A的连接数据，并且在1112中将连接数据转发给移动设备B。最后，在1113中，移动设备A和B使用所交换的连接数据进入直接的P2P连接。

现在转至图12，如果兼容性检查1106确定直接的P2P连接是不可行的，则邀请服务112能够给中继服务1051发送中继查找请求1201，以确定被每个移动设备使用的中继主机。请求1201可以含有用于移动设备A和B的网络信息（例如，NAT穿越/连接数据和/或NAT类型数据），该网络信息被中继服务1051用来选择用于两个移动设备的适当的中继主机。如图13所示，中继服务1051的一种实施例包括多个中继主机1302-1303以及含有与每个中继主机相关的网络信息的中继主机数据库1301。邀请服务112给中继查找服务1300发送中继查找请求1201，该中继查找服务1300使用用于移动设备A和B的网络信息来查询中继主机数据库1301。在接收到数据库结果时，中继查找服务1300提供用于识别所选的中继主机1302-1303的应答1202。

在一种实施例中，中继查询应答1202含有由中继服务生成的中继令牌以及将被移动设备A和B用于中继连接的中继主机1302-1303的网络地址（IP地址/端口）。在一种实施例中，中继令牌与中继会话关联，并且被中继主机1302-1303用来在连接至中继服务1051时认证移动设备A和B。权证可以采取各种形式，包括，例如唯一的ID的中继会话ID码、数字证书和/或与中继会话相关的唯一的加密密钥。

在1203中，邀请服务给移动设备B121发送含有将要进行中继连接的指示的中继应答1203。在一种实施例中，中继应答1203能够包括中继令牌以及用于中继主机B1303的网络信息。在一种实施例中，应答1203能够直接发送给移动设备B（绕过推送通知服务1050），因为它响应于移动设备B的接受1105而发送。

邀请服务112给移动设备A发送中继应答1204，该中继应答1204能够包括中继令牌以及用于中继主机B1303的网络信息。在该实例中，应答1204在处理1205中经由推送通知服务1050被推送给移动设备A。

在1206中，移动设备A120使用用于中继主机A1302的网络信息来建立与中继服务1051的连接。类似地，在1207中，移动设备B121使用用于中继主机B1303的网络信息来建立与中继服务1051的连接。在每个这些处理中，在移动设备A和B的任意NAT防火墙中打开新的孔，并且用于移动设备A和B的NAT穿越/连接数据可以由中继服务1051确定并分别返回到移动设备A和B（例如，通过确定用于设备的公共IP/端口）。在一种实施例中，中继服务1051以及移动设备A和B实现使用中继穿越NAT（“TURN”）协议，该TURN协议允许在NAT或防火墙之后的元件接收通过TCP或UDP连接进来的数据，这是本领域技术人员所理解的。

在1208中，移动设备A给邀请服务112发送中继更新，该中继更新在1209中被转发给推送通知服务并且在1210中被推送给移动设备B。类似地，在1211中，移动设备B给邀请服务112发送中继更新，该中继更新在1212中被转发给推送通知服务并且在1213中被推送给移动设备A。由移动设备A发送的中继更新能够包括会话令牌、每个设备的ID码以及由中继在1206和1207中确定的NAT穿越/连接数据（即，移动设备A将其NAT穿越/连接数据发送到移动设备B，反之亦然）。在一种实施例中，进行中继更新操作，因为每个移动设备的NAT信息都可以改变。

最后，在1214和1215中，移动设备A和B分别通过中继服务1051建立P2P连接。在一种实施例中，中继连接能够在移动设备给中继服务1051发送移动设备B的NAT穿越/连接数据时建立，反之亦然，因此允许中继服务确定至每个对等点的中继主机1302-1303的正确通路。

使用上文所描述的技术，邀请服务112可以被实现为无状态服务，该无状态服务即使是在具有大量移动设备的大规模系统中也是固有可伸缩的且有弹性的。例如，因为推送通知服务1050固有地能够定位已注册的移动设备并给其推送内容，所以邀请服务不必跟踪每个设备的当前位置。另外，因为设备可以发送具有每个请求和应答的整个会话状态数据，所以邀请服务从不需要保持任何每个连接的状态信息，由此降低邀请服务的存储及处理要求。这样的实现方式在大规模系统中特别有用。

用于为在线会话匹配用户的系统和方法

如图15所示，匹配器服务111的一种实施例能够包括匹配器调度器1501，用于接收匹配请求并给移动设备120-122推送匹配应答；数据库1512，用于将匹配请求存储于请求表1502内并且用于将可匹配集数据存储于可匹配集标识符（“MSI”）表1503内；以及一个或多个匹配器1510，用于从数据库1512中获取匹配请求，进行匹配操作并将匹配结果存储回到数据库1512内。但是，应当注意，本发明的基本原理并不限定于图15所示的具体体系结构。

在一种实施例中，匹配器调度器1501充当到匹配器服务111的接口，接收来自移动设备120-122的请求，将这些请求转译成命令以将请求存储于数据库1512内，从数据库1512中读出匹配结果，并且转译这些结果并将其发送给移动设备120-122。

在操作中，当新的匹配请求到达时，匹配器调度器1501能够将请求存储于请求表1502的行内。在一种实施例中，匹配器调度器1501给每个匹配请求分配请求ID（“RID”）码，在图15中被简单地示为“A”、“B”和“C”（分别对应于移动设备A、B和C）。虽然为了简便在图15中使用字母标记来示出，但是RID码可以是字符串、整数或者适用于跟踪数据库内的匹配请求的任何其他变量类型。

对每个匹配请求都可以分配存储于请求表1502内的可匹配集标识符（“MSI”）值。在一种实施例中，MSI能够识别出正对其请求匹配的具体应用和/或将用于该应用的配置参数。例如，12:4的MSI值可以识别出具有标识符“12”的特定的多玩家游戏，并且可以识别出用于具有标识符“4”的游戏的特定配置。更特别地，ID码12可以识别出特定的多玩家竞速游戏，而ID码4可以为竞速游戏指定特定的赛道、速度或玩家经验等级。在一种实施例中，以此方式给应用开发人员提供了使用MSI值来指定任何应用配置参数的选项。在一种实施例中，应用开发人员不是直接指定MSI，而是指定游戏ID（用于识别特定的游戏）和桶ID（用于识别特定的游戏配置），并且这些值由匹配器调度器1501映射到MSI值。

另外，在单个MSI内可以使用几个不同的MSI值来指定多个不同的配置参数（例如，12:4:1可以表示：12=竞速游戏；4=赛道；以及1=经验等级）。如同下文将详细描述的，在一种实施例中，每个MSI被匹配器1510用来识别一组匹配请求，在该组匹配请求中能够进行匹配操作（例如，请求基于MSI来分组并且在每个MSI分组内进行匹配）。在一种实施例中，每个MSI都可以由调度器动态地修改/选择以包含用于识别不同的机器分区的分区ID。例如，如果特定的MSI过载，调度器则可以将MSI分割于两个或更多个不同的服务器和/或存储分区之间（例如，使用诸如4:3:1和4:3:2之类的标记，其中最后的数字分别识别分区1和2）。然后，不同的匹配器可以单独检索并处理来自每个不同的服务器的每个不同的MSI的请求。

如图15所示，针对每个请求，匹配请求数据同样可以存储于请求表1502内。请求数据可以包括可用来给出匹配判决的任何数据和/或为访问通过网络发起请求的移动设备所需的任何数据。例如，在一种实施例中，用于每个请求的匹配请求数据包括NAT类型数据和/或发起请求的移动设备的NAT穿越/连接数据。其他类型的请求数据同样可以存储于请求表1502内，该请求数据诸如设备连接速度（100kbps、1Mbps等），连接类型（例如，3G、EDGE、WiFi等），设备位置（例如，由地理定位技术确定的），语言（英语、西班牙语等），和/或用户偏好。请求数据可以由每个移动设备120-122确定并且与每个匹配请求一起被发送给匹配调度器1501。例如，每个移动设备都可以使用各种技术来确定其连接数据、连接类型、设备位置等，这些技术中的某些将在下文描述（例如，与NAT穿越服务器通信以确定NAT穿越/连接数据，使用GPS来确定设备的位置，读出HTTP信息以确定语言等）。

如图15所示，在一种实施例中，每个活动的MSI都能够在MSI表1503内分配一行。在一种实施例中，当新的请求到达时，除了将请求添加到请求表1502之外，调度器1501还检查MSI表1503以确定针对该请求MSI是否已经存在（即，是否已经接收到具有相同MSI的其他请求）。如果没有找到匹配的MSI，则调度器1501可以在MSI表1503内为新请求创建新的条目。如果找到匹配的MSI，则调度器能够如同上文所描述的那样将新请求简单地添加至请求表1502。

一旦请求表1502和MSI表1503由匹配器调度器1501更新了，匹配器模块1510的实例（以下简称为“匹配器1510”）取回数据以执行匹配操作。多个匹配器实例可以同时执行以执行匹配请求，而单个匹配器1510可以同时处理在多个不同的MSI分组上的多个匹配操作。

在一种实施例中，当匹配器1510变为可用时（例如，在完成了MSI分组的匹配操作之后或者在初始化之后），它查询MSI表1503以识别新的MSI来处理。在图15中，在MSI3:1的匹配器ID字段内的“N/A”值指示用于处理该MSI的责任尚未被指派给匹配器。在一种实施例中，每个MSI条目都带时间戳，并且匹配器1510选择具有最老时间戳的MSI。

在一种实施例中，当匹配器1510假定特定MSI的责任时，它更新其在MSI表1503内的匹配器ID码，并且为该MSI指定租赁期限（例如，5秒）。在一种实施例中，匹配器1510在其处理该MSI的匹配时连续地更新租期值。租期值可以被用来识别分配给失效的匹配器1510的MSI。例如，如果租期值已到期，则该MSI可以由新的匹配器要求，但是MSI表1503指出该MSI已被分配给匹配器。

一旦匹配器1510假定了MSI的责任，它就能够查询请求表1502以将与该MSI关联的请求读入存储器内。然后，匹配器1510能够执行匹配操作以根据一组匹配标准来匹配用户和移动设备（例如，如同下文所描述的）。匹配器1510能够更新请求表1512以指示移动设备何时已进行了匹配。例如，匹配器能够从请求表1512的MSI列中去除MSI值，并且输入预定值以指示该匹配已经完成。另外，匹配器1510可以更新每个参与者的“请求数据”字段，以识别该参与者所匹配的其他参与者（例如，通过写入与其他参与者通信所需的NAT穿越/连接数据）。

调度器1501能够周期性地查询请求表1502以识别完成的匹配。响应于检测到完成的匹配，调度器1501可以将推送通知发送给该匹配所涉及的移动设备（例如，使用本文及共同未决申请所描述的推送通知技术）。在一种实施例中，推送通知包括上文所述的“权证”数据结构。然后，移动设备可以使用它们的每个权证以如同上文所描述的那样经由CDX服务110来交换连接数据。

除了使用推送通知外，在一种实施例中，移动设备120-122可以周期性地查询调度器1501以确定是否已经获得匹配。周期性查询在推送通知尚未将其传送给移动设备的情况下是有用的。但是，因为使用了推送体系结构，所以可以将周期性查询设定于相对较低的速率，由此降低匹配器服务111的负载。

图16示出了其中两个设备A和B通过匹配器服务111匹配的方法的一种示例性实施例。图17a-d示出了请求表1502和MSI表1503的示例性更新，这些更新可以作为方法进程而发生。

在1601，接收到来自移动设备A的匹配请求。在1602，移动设备A的请求被输入请求表，并且新的MSI条目（MSI1:1）被输入MSI表（如果该MSI条目尚未存在），如图17a所示。在1603，接收到来自移动设备B的匹配请求，并且在1604，移动设备B的匹配请求同样被输入请求表，如图17b所示。

在1605，特定的匹配器实例（匹配器#N）检查MSI表，并且检测到MSI1:1尚未由别的匹配器实例声明。作为选择，匹配器可以检测出租期已过的MSI表条目，表明先前在MSI上工作的匹配器已经失效。在一种实施例中，租期已过的MSI条目被赋以比新的MSI条目更高的优先级（这些新的MSI条目尚未被分配给匹配器）。另外，在一种实施例中，可以给相对较老的MSI条目赋以比相对较新的MSI条目更高的优先级。不管匹配器如何选择MSI，一旦它选择了，它就添加其标识符并且为MSI条目设定新的租期值，如图17c所示（例如，在所示出的实例中使用5秒的租期值）。匹配器然后可以查询请求表并且将具有该MSI的请求表条目读入存储器，以便它们能够被处理。

在1606，匹配器执行一系列匹配操作以为每个请求选择适当的匹配。匹配操作的某些实施例将在下面针对图18来描述。简要地，在一种实施例中，被评价用于确定“适当的”匹配的变量包括NAT类型（例如，完全锥型、端口受限型、对称型等），连接类型（例如，WiFi、3G、Edge等），与用户相关的语言（从HTTP请求的接受语言报头中得出），以及匹配请求各自的年龄（age）。一般地，匹配器1510可以尝试匹配具有兼容的NAT类型的（尽管有时可以如同下文所描述的那样使用中继服务）、相同连接类型及相同语言的移动设备。在一种实施例中，基于匹配请求的年龄，匹配器1510在匹配要求方面可以更自由（即，请求越老，应当施加的匹配约束就越自由）。

返回到图16，在1607，在匹配判决之后，匹配器1510可以更新请求表以指出匹配已完成，如图17d所示。作为更新的一部分，匹配器还可以更新移动设备A和B的请求数据。例如，在一种实施例中，匹配器1510将移动设备B的NAT穿越/连接数据写入移动设备A的请求数据列内，并且将移动设备A的NAT穿越/连接数据写入移动设备B的请求列内。

在1608，调度器1501能够通读请求表以识别已经匹配的请求条目。在一种实施例中，当它检测到移动设备A和B已经匹配时，它读出请求数据（由匹配器如同上文所描述的那样更新），并且生成用于移动设备A和B的通知。在一种实施例中，通知是上文所述的“权证”数据结构，该权证数据结构被加密并且包含每个移动设备的NAT穿越/连接数据。如上所述，在一种实施例中，推送通知服务1050被用来给移动设备A和B推送通知。另外，移动设备A和B可以周期性地轮询调度器1501以确定是否已经获得了匹配。在本实施例中，轮询技术可以按相对低的速率进行，以识别出由于某种原因没有被成功地推送给移动设备之一的匹配。使用推送通知来管理轮询请求负载显著地降低了匹配器服务111的负载，否则该匹配器服务111将加载来自移动设备的轮询请求。

如果对同一MSI的附加匹配请求正悬而未决（在1608确定），则匹配器可以继续匹配在MSI内的移动设备/用户。在1610，匹配器可以重置在MSI表1503内的租期值。在1611，执行附加的匹配并且更新请求表（如上所述）。在1612，从请求表中读出附加的匹配并且更新附加的移动设备（如上所述）。如果对于MSI已无附加的匹配请求悬而未决，则在1609将MSI条目从MSI表中移除（例如，经由调度器和/或匹配器的删除命令）。

图18示出了用于执行在移动设备/用户之间的匹配（在图16中为操作1606）的方法的一种实施例。在1801，所有当前的MSI请求（例如，对于特定的应用/桶组合）被排列成对。在1802，评价每个对之间的“匹配度”，并且在1803，这些对按下降的匹配度（fit）来排序。“匹配度”基于多种不同的变量来评价，包括（但不限于）：NAT类型（例如，完全锥型、端口受限型、对称型等），连接类型（例如，WiFi、3G、Edge等），与用户相关的语言（从HTTP请求的接受语言报头中得出），以及匹配请求各自的年龄。可以计算于匹配判决内的其他变量包括每个移动设备的位置（例如，对于匹配特定位置的用户的尝试）；最少和/或最多玩家要求（例如，由用户和/或应用指定）；包含于MSI内的一个或多个用户是否是“朋友”或者是否先前已经进入P2P连接（例如，偏好匹配“朋友”或先前的熟人）；以及用户在该应用上的经验（例如，对于多玩家游戏，可以将每个用户的排行榜排名计算在内，偏好匹配经验相似的用户）。

如同以下在表A中指出的，在一种实施例中，“匹配度”的评价是0.0-1.0的数字值。使用浮点值允许匹配度对每个标准进行归一化。为了避免浮点运算，非归一化的整数值能够与适合的评价一起使用，以便匹配度值能够被比较。

在一种实施例中，所有标准都具有二元匹配，其中它们或者为兼容（具有1.0的归一化值）或者为不兼容（具有小于1.0的归一化值）。这些能够被认为是必要的标准，其中匹配度可以随年龄而改变（如下文所描述的）。如果位置被添加为变量，则最佳的匹配可以是与匹配必要标准的最近玩家的匹配。

匹配度——表A

因素	权重	归一化
			NAT兼容性	2.0	0.4
连接类型	2.0	0.4
			语言	1.0	0.2
合计	5.0	1.0

在一种实施例中，匹配度等于上述每个标准的（归一化权重*年龄因素值）之和。年龄因素值可以从值1开始，并且在经过了预定的时间段之后增加。然后，它可以随时间流逝而继续增加（例如，周期性地增加指定量）。在一种实施例中，作为使用上文所述的年龄因素值的代替，年龄阈值可以如同以下所描述的那样来建立。某些变量（例如，连接类型和语言）的归一化值/加权值可以在某些年龄阈值上应用（即使它们不匹配）。

在一种实施例中，在一对请求A和B之间的“匹配度”是A与B的及B与A的匹配度的平均值。而且，每个因素的A与B的匹配度可以基于A的年龄来调整（反之亦然）。在一种实施例中，对于兼容的匹配可能需要1.0的匹配度。这意味着A和B将仅在NAT兼容性、连接类型和语言匹配（导致1.0的归一化值）时或者在A和/或B已经变老使得上述变量中的某些（例如，连接类型和语言）实际上可忽略（使用在阈值之上或之下的变老因素值）时才匹配。

年龄——表B

年龄	阈值1	阈值2	阈值3	阈值4	阈值5
						老于	0秒	1秒	5秒	10秒	30秒

年龄阈值可以如同上文的表B所阐明的那样来建立。随着每个年龄阈值被超过（即，随着请求变为比指定的阈值更老时），变老因素值可以相继增大至较大的值（例如，1.5、2.0等）。作为选择或者除此以外，随着不同的年龄阈值被超过，某些变量的加权值可以被添加至匹配判决（例如，以下所述的连接类型和语言）。

在一种实施例中，在表B中指定的请求年龄限制根据给定的MSI的匹配流量来调整。在一种实施例中，流量被规定为每特定单位时间（例如，每10秒、每分钟等）执行的匹配数。因而，流量提供了关于特定MSI集的繁忙程度的指示。在一种实施例中，MSI集越忙，在上文的表B中就可以将上述每个阈值设定得越低，以增大早期成功匹配的可能性并降低匹配器的负载。而且，对给定的MSI集的负载可以被提供给终端用户（例如，以估计的匹配时间值的形式），使得中断用户能够选择是否尝试进入特别繁忙的多玩家游戏。负载值可以用推送通知的形式提供给用户。

现在转至表A的每个变量，在一种实施例中，NAT兼容性根据图14所示的NAT兼容表1400来确定。如果基于该表确定两个NAT是兼容的，则可以施加NAT兼容权重。

连接类型——表C

A/B	WiFi	Edge	3G
				WiFi	1.0	0.0	0.0
Edge	0.0	1.0	0.0
				3G	0.0	0.0	1.0

连接类型可以使用如上文的表C所示的图表来评价。在本实例中，如果设备A和B的连接类型是相同的（如在相同的连接类型相遇的单元格内的1.0所示），则表A的加权的连接类型值可以包含于匹配度确定中。如上所述，每个请求的年龄都可以被用来影响连接类型的确定。例如，在一种实施例中，对于在阈值1、2和3处的年龄，连接类型的匹配度值使用在表C内的矩阵来选择。对于在阈值4处或以上的年龄，连接类型可以被设定为1.0（即使是不匹配的连接类型），并且可以应用相应的加权连接类型值。虽然在某些实施例中使用了连接“类型”，但是连接速度可以被确定并且与连接类型一起或者代替连接类型来使用。例如，在某些指定范围内的连接速度可以被认为是“兼容的”（例如，0-100kbps、100-500kbps、500-1000kbps、1000-1500kbps等）。本文所讨论的任何匹配变量同样可以被应用为匹配度计算的权重，并且可以如同上文所描述的那样变老。

在一种实施例中，玩家语言能够从HTTP请求的接受语言报头中得出，该HTTP请求的接受语言报头可以含有具有偏好品质因子（preference qfactor）的一种或多种语言。调度器能够提取最优选的语言并且将该信息传递到匹配器。在一种实施例中，如果语言是相同的，则将来自表A的加权语言值设定为1.0，或者如果它们不同，则为0.0。但是，在一种实施例中，即使语言不同，也可以应用加权语言值，只要年龄在指定的阈值之上（例如，在表B中，只要年龄处于阈值2或之上）。

在一种实施例中，匹配可以在具有不兼容的NAT类型的两个用户之间进行。例如，如果匹配器对于特定的MSI匹配用户有困难，则在指定的时间段之后，它可以使用上文所述的技术通过中继服务1051来路由连接。以此方式，中继服务1051充当压力阀，从而尽管NAT类型不兼容也允许变老匹配（aging match）发生。中继服务1051同样可以响应于检测到一个或多个失效的匹配尝试而使用。在本实施例中，由移动设备提交的每个匹配请求都可以包括关于先前是否已经尝试了一个或多个不成功的匹配的指示。

可以评价各种另外的匹配标准并给其提供作为匹配度确定的一部分的权重值，包括，例如（但不作为限定），关于请求匹配的任一用户是否是朋友的指示。例如，匹配器1510可以尝试通过将“朋友”权重应用于匹配度计算来匹配作为“朋友”的用户的任何请求。类似地，同样可以对朋友的朋友加权（例如，以2或更大的分离度）。另外，玩家可以评定（rate）特定游戏的其他玩家，并且匹配器可以在执行匹配时评价那些评定（倾向于将用户与具有相对较高的评定的那些玩家进行匹配，而不是将用户与具有低评定的玩家进行匹配）。而且，可以评价用户连接的等待时间（例如，使用简单的ping操作）并将其用作匹配判决的一部分。

用来匹配玩家的又一变量可以是设备类型。例如，匹配器1510可以尝试匹配具有类似设备类型（例如，iPad、iPod、iTouch、iPhone、RIM Blackberry等）的玩家。另外的变量可以包括：用户的排行榜排名、当前位置、当前住所、年龄、性别，并且对于匹配确定可以类似地评价相似的游戏集（即，在许多情况下倾向于偏爱在具有类似标准的那些用户之间匹配）。最后，家长控制可以由匹配器1510来评价以确保仅匹配具有适当的MSI的用户并且该用户仅与相同年龄的其他用户匹配。

匹配器服务111可以从在数据服务100内管理的一个或多个数据库（例如，参见以下将关于图19进行描述的数据库1920）中检索出任意上述变量。例如，用户的朋友数据可以从朋友服务数据库中获得，而诸如每个用户的年龄、性别、游戏收等其他信息可以从一个或多个其他数据库（例如，用户简档、游戏数据库、排行榜数据库等）中获得。在一种实施例中，本文所描述的所有服务都允许访问同一中央数据库（或者一组数据库），以便存储用于作出匹配判决的所有各种不同类型的用户/设备数据。

虽然上文提供了几个具体的实例，但是应当意识到，本发明的基本原理并不限定于用于确定匹配的匹配度水平的任意一组特定的变量。在一种实施例中，设计将在本文所描述的系统及方法上运行的应用的应用程序员可以指定他们自己的标准集，以便使用不同的MSI标准来匹配请求和/或对其分组。

返回到图18的方法，一旦在每个对之间确定了“匹配度”，则在1803按下降的匹配度来排序这些对（例如，具有最高匹配度的对在列表的顶部）。在1804，以具有在指定的阈值之上的最高匹配度值的那些对来构造（seed）“匹配集”。如上所述，“阈值”可以设定为上文在表A中示出的归一化值1.0。在1805，将与匹配集的一个或全部当前成员间的匹配值在指定阈值之上的新的潜在伙伴添加至匹配集。例如，如果匹配集最初以A和B来构造，则如果A-C和/或B-C的匹配值在指定阈值之上就可以将C添加至匹配集。在一种实施例中，如果潜在伙伴只有单个匹配度在阈值之上，则可以将该伙伴添加至匹配集（即，因为（如果必要）该伙伴将能够通过它与其具有适合的匹配度的那个伙伴与所有伙伴通信）。一旦一个或多个新伙伴被添加至匹配集，则在达到了匹配的大小要求时（在1806确定），就在1807存储并报告匹配结果（例如，通过如上文所描述的那样更新请求表1502并发送通知）。在一种实施例中，单个匹配请求可以代表多个用户（例如，当匹配请求跟随在邀请序列之后时，这将在下文描述）。在这种情况下，大小要求基于每个匹配请求所代表的用户的数量来评价。如果尚未达到大小要求，则过程返回至1805并且新的伙伴被添加至匹配集（即，具有在指定阈值之上的与匹配集的一个或多个当前成员间的匹配度的伙伴）。

在1808，从正由匹配器1510处理的当前请求集中去除匹配的请求。在1809，选择下一构造的匹配集，并且过程返回至1804以进行另外的匹配。虽然在图18中被示为顺序过程，但是应当注意，多个构造的匹配集可以被同时处理，同时仍然遵从本发明的基本原理。

虽然在上文被描述为单独的服务，但是匹配器服务111和邀请服务112可以共同操作用于连接P2P用户。例如，在一种实施例中，第一用户可以邀请一个或多个朋友进入在线会话，并且请求与一个或多个另外的用户匹配（例如，邀请朋友“Bob”并且匹配3个另外的玩家来进行多玩家视频游戏）。在这种情况下，邀请服务112最初可以处理第一用户的邀请请求，以连接第一用户和第一用户的朋友。然后，可以将邀请请求的结果（例如，成功的P2P连接）往回报告给用户的移动设备。匹配器服务111然后可以接收来自第一用户的移动设备的（或者，在一种实施例中，直接来自邀请服务的或者来自第一用户的朋友的）请求另外玩家的匹配请求。作为响应，匹配器服务111可以将第一用户与具有与第一用户的请求相同的MSI的一个或多个其他匹配请求进行匹配（如上所述）。匹配请求可以仅包括第一用户的匹配标准，或者可以包括第一用户的和第一用户的朋友的匹配标准（例如，NAT类型、连接类型、语言、位置等）。在一种实施例中，如果第一用户的一个或多个朋友无法与另一匹配用户建立直接的P2P连接，则该匹配用户与第一用户的朋友的连接可以通过第一用户的数据处理设备来建立（例如，将第一用户的移动设备用作连接的代理），和/或中继服务可以被用来连接用户（如上所述）。

在一种实施例中，第一用户最初可以通过匹配器服务与一个或多个用户匹配（如上所述），并且然后第一用户可以邀请一个或多个朋友加入与第一用户及匹配用户间的在线会话。在本实施例中，用户的信息和匹配用户的信息（例如，NAT/连接数据、用户ID、推送令牌等）两者可以通过邀请服务与所邀请的用户进行交换（如上所述）。本发明的基本原理保持不变，不管是匹配在邀请先前先发生还是邀请在匹配先前先发生。

用于协同在线应用的具有应用编程接口的应用框架

如图19所示，本发明的一种实施例在具有预定义的软件框架1912的移动设备120的环境中实现，该预定义的软件框架1912具有用于与一个或多个应用1911接口的应用编程接口（“API”）1910以及用于与多个网络服务1901-1903通信的服务侧API1910。如图19所示，网络服务1901-1903可以由同一在线数据服务100设计和/或管理（但这样的配置并非是必要的）。诸如P2P游戏应用和其他类型的协同在线应用之类的应用1911可以被设计用于通过调用API1910以经由API1910来访问网络服务1901-1903。应用1911的设计可以使用由框架1912及网络服务1901-1903的开发人员提供的软件开发工具包（“SDK”）来促进。框架1912和API1910、1913的更具体的实现方式将在下文参照图20来描述。

如图所示，每个服务都允许访问数据库1920，以便存储由服务使用的数据。一个特定的实例是由匹配器服务111使用的数据库1512（如上文描述）。其他实例可以包括用于存储排行榜数据的排行榜数据库、用于存储朋友状态记录的朋友服务数据库、用于存储用户简档数据的简档数据库以及用于存储与在线游戏相关的数据的游戏数据库。任何类型的数据库都可以使用（例如，MySQL、Microsoft SQL等），但是在一种特定的实施例中，能够使用键/值数据库，例如，BerkleyDB和/或MZBasic DB。数据库可以跨存储区域网络（SAN）或其他存储配置内的许多大容量存储设备（例如，硬盘）分布。

因此，当特定的服务如同上文所描述的那样处理和/或存储数据时，该数据可以存储于数据库1920内。但是，某些服务可以不使用数据库。例如，如上所述，邀请服务112可以被实现为无状态服务，并且因此可以不需要将数据存储于数据库1920内（但是按照本发明的基本原理，这样的实现方式仍然是可能的）。

API1913可以被设计用于使用任何合适的网络协议栈（包括，例如，在网络层的TCP/IP或UDP/IP以及在应用层的HTTPS）来与网络服务1901-1903通信并交换信息。可以使用经由HTTP或HTTPS的基于远程过程调用（RPC）的协议（例如，SOAP），和/或可以使用表述性状态转译（REST）协议。而且，服务可以被实现于任何计算平台上，包括，例如，Xserve或者运行Unix、Linux或Apache软件平台的类似服务器。在一种特定的实施例中，平台包含在Linux上实现的Web对象。上述实例仅为了说明而提供。本发明的基本原理并不限定于用于将应用链接到服务的任何特定机制或者任何特定的网络协议集。

图20示出了一种更详细的软件体系结构，包括在发明的一种实施例中能够实现于无线设备120上的应用编程接口（API）2001a-b。尽管该实施例在多玩家游戏框架2000的背景下描述，但是本发明的基本原理并不限定于游戏实现方式。例如，图20所示的软件体系结构可以被用来支持不是游戏的各种协同应用（例如，协同聊天、多方协同音频/视频等）。

在图20所示的体系结构中，游戏框架2000被提供用于支持本文所描述的各种多方特征和P2P特征。在一种实施例中，游戏框架2000被设计用于在移动设备的操作系统2005上运行。例如，如果移动设备120是iPhone、iPad或iPod Touch，则操作系统2005能够是iPhoneOS（由本申请的受让人设计的移动操作系统）。

游戏框架2000能够包括公共应用编程接口（API）2001b以及专用的或“安全的”API2001a。在一种实施例中，设计用于提供本文所描述的各种游戏相关的特征的游戏中心应用2031能够调用公共API2001b和专用API2001a两者，然而其他应用2030（例如，由第三方设计的应用）仅允许访问公共API2001b。例如，移动设备120的设计者可能希望将可能涉及敏感信息的某些API函数保留于公共API2001b之外，以避免被第三方开发人员滥用（例如，朋友请求、朋友列表等）。但是，安全API2001a和公共API2001b两者可以合并成可由移动设备上的所有应用访问的单个API（即，并不要求将API分离成单独的公共及专用组件以符合本发明的基本原理）。标记“API2001”在下文中有时被用来指代可以在公共API2001b和/或专用API2001a中找到的操作。

在2010年4月7日提交的、发明人为Marcel Van Os和Mike Lampell、代理人案号为4860.P9127USP1（序列号为No.__）、题目为“Systems and Methods for Providing a GameCenter”的公共未决申请（以下称为“游戏中心专利申请（Game Center PatentApplication）”）中描述了游戏中心应用2031的一种实施例，该专利申请被转让给本申请的受让人并且以引用方式并入本文。简要地说，游戏中心应用2031包括以游戏为中心的图形用户界面（GUI），用于在多玩家游戏中导航，购买新游戏，检索与游戏相关的信息（例如，排行榜信息、成就、朋友信息等），联系朋友来玩游戏，请求与其他用户的游戏匹配，以及邀请具体的用户。由游戏中心应用2031执行的各种其他功能已在上文所引用的游戏中心专利申请中进行了描述。某些游戏中心功能可以由游戏框架2000来提供，并且被允许通过公共API2001b来访问其他应用2030。

在一种实施例中，由游戏框架2000给出的API2001简化了为移动设备120设计多玩家协同游戏的过程。特别地，在一种实施例中，API2001允许开发人员进行简单的API调用，以便调用为多玩家的P2P游戏会话连接用户的相对较复杂的过程。例如，诸如INVITE（Player B ID,Bucket ID）之类的简单的API调用可以从API2001中调用，以发起上文所述的详细的邀请序列。类似地，诸如MATCH（Player A ID,Bucket ID）之类的API调用可以从API2001中调用，以发起上文所述的详细的匹配序列。INVITE和MATCH函数在此有时一般地称为“P2P连接函数”。在一种实施例中，游戏框架2000包括响应于这些API调用而管理邀请和匹配操作所需的程序代码（这将在下文更详细地描述）。应当指出，实际的API函数可以具有与上文所阐明的数据格式稍有不同的数据格式（但是它们可以引起由游戏框架2000执行的类似操作）。本发明的基本原理并不限定于用于指定API函数的任何特定格式。

各种其他类型的游戏相关处理及信息同样可以由代表游戏中心2031及其他应用2030的游戏框架2000来管理。该信息的一部分在游戏中心专利申请中进行了描述。举例来说（但并不作为限定），该信息可以包括：与已经获得每个游戏的最高分数的那些用户相关的“排行榜”信息以及用于识别已经完成某些游戏特定的成就的用户的“成就”信息。每个应用开发人员都可以为每个游戏应用2030指定它们自己的“成就”集（例如，完成等级1-3；5分钟内完成第1级；每级杀敌50个以上；击倒20个标记等）。

游戏框架2000同样可以包括用于管理用户的朋友数据以及用于将朋友数据集成于游戏中心2031及其他游戏应用2030的环境中的程序代码。例如，当用户选择到游戏中心2031内的特定游戏的链接时，可以为该游戏显示与用户的每个朋友相关的信息（例如，朋友在排行榜上的排名、朋友的成就、用户与他/她的每个朋友玩游戏时的结果等）。在一种实施例中，游戏框架2000的API2001包括用于访问由朋友服务管理的朋友数据的函数，例如，在2010年4月7日提交的、发明人为Amol Pattekar、Jeremy Werner、Patrick Gates和AndrwH.Vyrros、代理人案号为4860.P9240（序列号为No.__）、题目为“Apparatus and Methodfor Efficiently Managing Data in a Social Networking Service”的公共未决申请（以下称为“朋友服务申请（Friend Service Application）”）中描述的函数，该申请被转让给本申请的受让人并且通过引用的方式并入本文。

如图20所示，在一种实施例中，游戏守护进程2020可以使游戏框架2000与第一组服务2050接口，而游戏服务构件2010可以使游戏框架2000与第二组服务2051接口。举例来说，第一组服务2050可以包括上文所述的邀请服务112、匹配器服务111和中继服务1051，以及在上文所引用的朋友服务申请中描述的朋友服务。可以经由游戏守护进程2020访问的其他服务包括：排行榜服务（提供排行榜数据）；游戏服务（提供与每个游戏相关的统计和其他数据以及购买游戏的能力）；用户认证服务（用于认证移动设备的用户）；和/或用户简档服务（用于存储诸如用户偏好之类的用户简档数据）。经由游戏服务构件2010来访问的第二组服务2051可以包括上文所述的连接数据交换（CDX）服务110和NAT穿越服务290-291。虽然为了说明在图20中被示为单独的构件，但是游戏守护进程2020和游戏服务模块2010实际上可以是游戏框架2000的构件。在一种实施例中，游戏守护进程2020和2010通过预定义的API与每个网络服务2050-2051通信，预定义的API在一种实施例中为专用API（即，不对第三方开发人员公开）。

在一种实施例中，游戏守护进程2020能够使用HTTPS协议与匹配器服务111、邀请服务112及其他服务2050通信，同时游戏服务模块2010能够使用相对较简便的协议（例如，UDP套接字）与CDX服务110和NAT穿越服务290-291通信。但是，如上所述，能够采用各种其他网络协议，同时仍然遵守本发明的基本原理。

另外，如图20所示，游戏守护进程2020可以接收由某些服务2052（例如，邀请服务和匹配器服务）生成的推送通知2052，然而其他类型的推送通知2053可以由游戏中心直接接收（例如，朋友服务通知，例如，新朋友请求）。在一种实施例，这些推送通知2053被直接提供给游戏中心2031，以确保用户的敏感数据不可被第三方应用开发人员所设计的应用2030访问。

返回上文在图11中阐明的游戏邀请实例，当在移动设备A上的应用2030对游戏框架2000的API2001b作出邀请调用以邀请移动设备B的用户（例如，INVITE（Player B ID,Game/Bucket ID））时，游戏框架2000可以将邀请请求传递给移动设备A的游戏守护进程2020。然后，游戏守护进程2020可以与邀请服务112通信以提交邀请请求。然后，邀请服务112能够使用推送通知服务1050（如上所述）来将邀请推送给移动设备B的游戏守护进程2020。然后，移动设备B的游戏守护进程2020可以与移动设备B的游戏框架2000通信以确定在移动设备B上是否安装有对其发送邀请的游戏。如果是，则游戏框架2000可以触发应用2030和/或生成邀请的可视化通知。如果应用尚未安装，则游戏框架2000可以给移动设备B的用户触发邀请的可视化通知，提议购买该游戏（例如，经由游戏中心2031GUI）。作为选择，可视化通知可以由在移动设备120上运行的推送通知守护进程（未示出）生成。如果移动设备B的用户购买该游戏，邀请序列可以继续跟进该购买。如果移动设备B的用户接受邀请请求，则移动设备B的游戏框架2000可以将邀请请求传递给其游戏守护进程2020，该游戏守护进程2020然后能够对邀请服务112作出应答。

回想一下，在图11中，兼容性检查1106确定移动设备A和B的NAT类型是兼容的。因而，在1108，移动设备A的游戏守护进程2020可以接收移动设备B的接受（例如，在本例中为经由推送通知），并且在一种实施例中，将接受传递给游戏框架2000。在该阶段，移动设备A的游戏框架2000或者可以通知请求应用2030移动设备B已经接受（经由API2001），或者可以等到设备已经成功连接后才通知请求应用2030。在任何一种情况下，游戏框架2000都可以将连接请求传递给游戏服务模块，该游戏服务模块2010在一种实施例中可以发起与移动设备B的连接数据交换。特别地，游戏服务模块可以使用CDX服务110将移动设备A的连接数据发送给移动设备B（例如，参见图11中的处理1111和1112）。如上所述，可以使用安全的“权证”数据结构来将该通信实现为UDP连接。

回想一下，在图12中，如果兼容性检查1106确定移动设备A和B的NAT类型是不兼容的，则可以使用中继服务1051来提供设备之间的连接。因此，移动设备B的游戏守护进程2020可以接收来自邀请服务的中继应答1203（示于图12中），并且移动设备A的游戏守护进程2020可以接收来自邀请服务的中继应答1205（经由推送通知服务1050）。在1206和1207，移动设备A和B的游戏守护进程2020可以与中继服务通信以检索配置数据。在1210，移动设备B的游戏守护进程2020接收来自移动设备A的中继更新数据，并且在1213，移动设备A的游戏守护进程2020接收来自移动设备B的中继更新数据。

在图11和12中示出的处理的最终结果是：移动设备A和B彼此间建立了连接（或者是直接的P2P连接，或者是中继连接）。在一种实施例中，在检测到成功的连接时，游戏框架2000可以通知使用API调用（例如，CONNECTED（Player A ID,Player B ID））来请求连接的应用2030。然后，移动设备A和B可以使用所建立的连接来玩指定的游戏或其他协同应用2030。

因而，响应于来自API2001的相对简单的调用（例如，INVITE（Player B ID,Game/Bucket ID）），用于在移动设备A和B之间建立P2P或中继连接的一系列复杂的处理可以由游戏框架2000来管理。在一种实施例中，游戏框架2000执行连接移动设备A和B的操作序列，并且然后将结果提供给请求应用2030，由此将API调用的细节保留为对应用设计者透明的。照此，应用设计者不需要了解如何在网络上连接移动设备A和B，或者如何执行为使设备间能够通信所需的各种其他功能，由此简化应用设计过程。

以类似的方式，游戏框架2020能够使用匹配器服务111来建立在移动设备A和其他参与者之间的匹配，如同上文参照图2a-b所描述的。在本实例中，应用2030可以对API2001作出简单的调用，例如，MATCH（Player A ID,Game/Bundle ID）。作为响应，游戏框架2000能够管理匹配和连接数据交换操作。当匹配操作和/或P2P连接完成时，游戏框架2000将结果向回提供给应用2030。

例如，在图2b中，游戏框架2000可以使用游戏服务模块2010来与连接数据交换（CDX）服务110及NAT穿越服务290-291通信，并且可以使用游戏守护进程来与匹配器服务111通信。一旦作出了匹配，移动设备A的游戏守护进程2020就在229接收权证A，并且游戏框架2000使用该信息来通过游戏服务模块2010实现连接数据交换。例如，在232，它可以通过NAT穿越服务290来请求它自己的连接数，并且然后可以在233-234通过CDX服务110交换其连接数据。在237和240，移动设备A的游戏服务模块2010分别接收移动设备B和C的连接数据。在这些交换之后，游戏服务模块2010在241建立P2P连接，并且游戏框架2000使用API通知来通知应用2030连接过程完成（例如，MATCH COMPLETE（Player B ID,Player C ID））。然后，该应用可以使用所建立的P2P连接来执行。

在某些实施例中，可以给用户被赋以与当前登记为“在线”的其他朋友玩游戏的选项。在这种情况下，关于某些朋友在线的通知可以经由推送通知2052或推送通知2053来提供（由游戏中心2031直接接收）。然后，游戏中心2031和/或应用2030可以给用户提供通知并且给用户提供与一个或多个选定的在线朋友游戏的选项。但是，应当注意，不管是否提供在线通知，本文所描述的邀请序列都将工作。在一种实施例中，用户的在线状态可以通过可由游戏守护进程2020访问的服务（例如，由上文所述的朋友服务或者由单独的“在场”服务）来监测。

游戏框架2000的一种实施例提供了用户可以用以邀请一个或多个朋友与一组未知的匹配参与者玩游戏的组合邀请/匹配操作。例如，如果游戏要求4个玩家并且第一用户邀请第二用户来玩该游戏，则邀请服务112最初可以连接第一用户和第二用户，并且匹配服务111然后可以将第一用户和第二用户与两个（或更多个）其他玩家匹配。在本实施例中，游戏框架2000最初可以执行上文所述的邀请序列，以连接第一用户和第二用户。在一种实施例中，一旦第一用户和第二用户已经成功连接，则游戏框架2000可以实现匹配序列以识别并连接其他用户。如上所述，在一种实施例中，由匹配服务应用的匹配标准可以包括第一及第二用户两者（例如，第一及第二用户两者的NAT类型、连接类型、语言等）。作为选择，可以评价这两个用户之一的标准，以作出匹配判决。

一旦所有用户被连接，游戏框架2000可以给经由API2001请求连接的应用2030提供连接结果。再一次，响应于应用2030作出的相对简单的API调用，游戏框架2000进入用于连接每个设备的一组复杂处理。一旦设备已经成功连接，游戏框架2000就将结果往回提供给请求应用2030。

如图20所示，游戏框架2000可以包括用于临时存储用户与其他游戏参与者之间的通信的通信缓冲区2003。通信可以包括例如文本、音频和/或视频通信。游戏框架2000能够基于每个应用2030的要求来建立缓冲区2003。例如，对于缓慢网络连接下的音频/视频通信，相对较大的缓冲区2003可能是必要的。在一种实施例中，每个应用2030可以作出经由API2001建立某一大小的通信缓冲区（例如，使用BUFFER（size）命令）的明确请求。作为选择，游戏框架2000可以基于每个应用的通信要求而自动地创建缓冲区。例如，游戏框架2000可以基于是否需要支持文本、音频和/或视频而选择特定的缓冲区大小。

在一种实施例中，通信缓冲区2003可以在用户间建立起全部P2P连接先前暂时存储通信流。例如，在邀请服务112或匹配器服务111识别了每个用户之后，但是在CDX服务110完成了连接数据交换操作先前，可以通知每个用户其他游戏参与者正处于被连接的过程中。在该阶段，移动设备120的用户可以将文本、音频和/或视频通信流发送给其他参与者。游戏框架2000将会为了尚未连接的那些参与者而将通信流存储于通信缓冲区2003内。然后，游戏框架2000可以在每个设备的连接完成时发送缓冲区2003内的文本、音频和/或视频。

在一种实施例中，游戏守护进程2020包括用于为了降低网络流量而高速缓存每个服务2050所保持的数据的高速缓存2021。例如，可以将用户的朋友列表、排行榜数据、成就数据、在场数据及简档数据存储于高速缓存2021内，这由高速缓存管理策略指定。在一种实施例中，高速缓存管理策略由数据存储于其上的每个个体服务驱动。因此，对于n个不同的服务，可以对高速缓存2021应用n个不同的高速缓存管理策略。另外，因为，高速缓存管理策略由服务驱动，所以它可以基于当前的网络和/或服务器负载状况而动态地修改。例如，在服务负载重的时段内（例如，圣诞节、新产品发布日等），服务可以动态地指定高速缓存更新相对不频繁的高速缓存管理策略（例如，每12小时更新一次）。相比之下，在服务负载不重的时段内，服务可以指定高速缓存更新更频繁的高速缓存策略（例如，每半小时、1小时、2小时等更新一次）。

在一种实施例中，高速缓存管理策略使用高速缓存2021所存储的某些数据记录的存活时间（TTL）值来指定。当超过其TTL值的数据记录已被存储于高速缓存内时，则该数据被认为是“陈旧的”，并且对该数据的本地请求可以被直接转发给与该数据相关的服务。在一种实施例中，请求包括用于识别数据的当前版本的ID码。如果ID码匹配在服务上的ID码，则该数据仍然是有效的，并且不需要更新。然后可以将服务的应答发送回去，其指示在高速缓存内的数据是当前的，并且可以重置数据记录的TTL值。

除了如同上文所描述的那样使用高速缓存管理策略之外，在一种实施例中，可以使用推送通知服务1050给移动设备推送某些类型的数据的高速缓存更新。例如，可以给用户的移动设备120动态地推送用户的朋友列表或者用户的朋友的当前在线状态的变更。推送通知可以由游戏守护进程2020接收，该游戏守护进程2020然后可以更新高速缓存2021以包含由服务推送的数据的相关部分（即，可能并不需要更新在与该服务相关的高速缓存内的所有数据）。相比之下，某些推送通知可以指示游戏守护进程2020重写高速缓存的全部内容（或者至少是高速缓存中与执行推送的服务相关的那部分）。

使用推送来更新高速缓存2021的那些服务可以选择相对较高的TTL值（和/或可以不设定TTL值），因为它们具有推送通知来更新存储于高速缓存2021内的数据的能力。在一种实施例中，每个服务指定一组可以触发推送通知高速缓存更新的事件。例如，高速缓存更新事件可以包括：朋友的在线状态的变更、新的朋友请求、朋友请求的接受、删除朋友的操作、朋友正在玩特定游戏的指示、朋友达到的游戏成就、特定排行榜的前十名的更新，或者被认为足以重要到许可高速缓存更新的任何其他事件。以此方式来使用推送通知来更新高速缓存2021可以降低网络和服务的负载，因为对于推送更新，不需要在移动设备与服务之间的周期性轮询。

游戏框架2000的一种实施例基于用户的国家和/或地理位置来唯一地格式化呈现给终端用户的数据。例如，可以将诸如当前日期、时间及币值之类的值不同地呈现给不同国家及位置的用户。举例来说，在美国，日期格式可以是[月日,年]（例如，April25,2010），然而在其他国家，日期格式可以是[日月,年]（例如，25April,2010）。类似地，当在美国及某些其他国家表示时间时，可以使用AM/PM标记，并且在小时和分钟之间可以使用冒号（例如，3:00PM）。作为比较，许多其他国家不使用AM/PM标记，和/或在小时和分钟之间使用逗号（例如，15,00）。作为另一实例，世界上的许多地区使用公制（metric system），然而世界上的某些地区不使用（例如，美国）。应当注意，这些仅为说明性的实例，这些实例可以由本发明的某些实施例使用。本发明的基本原理并不限定于任何特定的数据格式集。

在一种实施例中，在显示排行榜数据、成就数据、朋友数据和/或由游戏框架2000处理的任何其他数据时，可以选择这些不同的数据格式。游戏框架2000可以用各种方式来确定用户的国家和/或地理位置。例如，在一种实施例中，该信息被简单地提供于用户的简档数据中，和/或可以基于用户的蜂窝通讯服务提供方（cellular service provider）来确定。用户的位置也可以使用例如全球定位系统（GPS）跟踪来确定。

与地理位置和/或国家无关的其他类型的数据格式同样可以由游戏框架2000来管理。例如，在显示排行榜数据时，重要的是了解最低分数是应当将用户置于排行榜的顶部还是底部。对于某些游戏（例如，高尔夫、径赛、竞速、滑雪等），较小的数字指示较好的成绩，然而在其他游戏（例如，足球、棒球等）中，较高的数字指示较好的成绩。因而，在一种实施例中，应用2030经由API2001来指定将被使用的分数的类型（例如，“升序”或“降序”）。然后，游戏框架2000可以使用适当的一组标签和格式来显示分数。

游戏框架2000的一种实施例还基于用户与用户的朋友之间的关系来过滤用户数据。例如，本发明的一种实施例考虑到了“详细”视图、“朋友”视图和“公共”视图。在一种实施例中，详细视图可由拥有数据（即，用户的个人信息）的用户使用；朋友视图可由用户的朋友使用；而公共视图可由所有其他用户使用。

举例来说，公共视图可以简单地包括与每个用户相关的“别名”，该别名玩的游戏及相关分数，以及玩游戏的日期/时间。该信息可以被游戏框架2000用来填充公共排行榜，该公共排行榜然后可以经由游戏中心2031来显示。

朋友视图可以包括一般视图的所有信息，以及将在用户的朋友当中共享的任何附加信息，包括，例如，用户所拥有的游戏、用户所玩的游戏、用户的成就及分数、用户拥有多少朋友、那些朋友的标识、识别用户头像的URL和/或用户的在线状态，仅例举数例。在一种实施例中，“朋友”视图提供将与朋友共享的一组默认信息，但是终端用户可以调整该默认配置并且具体地指定将由每个个体朋友或朋友群共享的信息的类型（例如，同事、家庭成员、大学/高中朋友等）。

“详细”视图可以包括“公共”及“朋友”视图的所有信息，以及由代表终端用户的各种服务2050管理的任何其他信息。举例来说，这可以包括：用户的全部简档数据、用户的通用唯一标识符（“UUID”）（在本文中有时称为“玩家ID”）、玩家名称、别名、游戏数及游戏的标识、用户的朋友、用户的全部成就等。

在某些情况下，应用2030可以只要求与每个用户相关的少量信息，例如，每个用户的玩家ID。例如，在一种实施例中，当匹配被请求时，游戏框架2000最初可以只要求每个玩家的ID。在匹配由匹配器服务执行时（参见上文），游戏框架2000可以确定任一匹配用户是否是朋友（例如，经由与朋友服务的通信和/或通过询问用户的本地朋友数据）。如果是，则游戏框架2000可以检索另外的用户数据并将该数据提供给任何匹配的朋友。以此方式，游戏框架2000基于用户的标识以及每个用户之间的关系来过滤信息。

在一种实施例中，如果第一用户和第二用户没有朋友关系，则游戏框架2000最初在这两个用户之间提供公共视图。但是，在一种实施例中，游戏框架2000允许第一用户给第二用户发送朋友请求（例如，使用第二用户的别名）。如果朋友请求被接受，则游戏框架2000将给每个用户提供另外的信息（例如，默认的“朋友”视图）。

不同的API实施例

在一种实施例中实现的API是由软件构件（以下称为“API实现型软件构件（APIimplementing software component）”）实现的接口，该接口允许不同的软件构件（以下称为“API调用型软件构件（API calling software component）”）访问并使用一个或多个函数、方法、过程、数据结构和/或由API实现型软件构件提供的其他服务。例如，API允许API调用型软件构件的开发人员（该开发人员可以是第三方开发人员）利用（leverage）由API实现型软件构件提供的指定特征。可以存在一个API调用型软件构件，或者可以存在多个这样的软件构件。API能够是计算机系统或程序库提供的源代码接口，以便支持软件应用对服务的请求。API能够依据编程语言来指定，该编程语言可以是解释性的并且在构建（build）应用时被编译，而不是关于数据在存储器内如何布置的显式的低层描述。

API定义了API调用型软件构件在访问并使用API实现型软件构件的指定特征时使用的语言和参数。例如，API调用型软件构件通过由API给出的一个或多个API调用（有时称为函数或方法调用）来访问API实现型软件构件的指定特征。API实现型软件构件可以响应于API调用型软件构件的API调用而通过API来返回值。虽然API定义了API调用的语法和结果（例如，调用API调用的方式以及API调用进行的操作），但是API通常不展示API调用如何完成由API调用指定的函数。各种函数调用或消息经由一个或多个应用编程接口在调用软件（API调用型软件构件）与API实现型软件构件之间传送。函数调用或消息的传输可以包括发布、启动、调用、调入、接收、返回或者响应于函数调用或消息。因此，API调用型软件构件能够传输调用，并且API实现型软件构件能够传输调用。

举例来说，API实现型软件构件2010和API调用型软件构件可以是操作系统、库、设备驱动器、API、应用程序或者其他软件模块（应当理解，API实现型软件构件和API调用型软件构件可以是相同类型的软件模块或者是彼此类型不同的软件模块）。API调用型软件构件可以是本地软件构件（即，在与API实现型软件构件相同的数据处理系统上）或者是通过网络经由API与API实现型软件构件通信的远程软件构件（即，在与API实现型软件构件不同的数据处理系统上）。应当理解，API实现型软件构件也可以充当API调用型软件构件（即，它可以对由不同的API实现型软件构件给出的API进行API调用），并且API调用型软件构件也可以通过实现不同的API调用型软件构件可见的API而充当API实现型软件构件。

API可以允许以不同的编程语言编写的多个API调用型软件构件与API实现型软件构件通信（从而API可以包括用于转译在API实现型软件构件与调用API的软件之间之间的调用及返回的特征）；但是，API可以依据具体的编程语言来实现。

图21实现了API体系结构的一种实施例，该实施例包括用于实现API2120的API实现型软件构件2110（例如，操作系统、库、设备驱动器、API、应用程序或其他软件模块）。API2120指定可以由API调用型软件构件2130使用的一个或多个函数、方法、类、对象、协议、数据结构、格式和/或API实现型软件构件的其他特征。API2120能够指定用于指定在API实现型软件构件中的函数如何接收来自API调用型软件构件的参数以及函数如何将结果返回给API调用型软件调用的至少一个调用约定。API调用型软件构件2130（例如，操作系统、库、设备驱动器、API、应用程序或其他软件模块）通过API2120来作出API调用，以访问并使用由API2120指定的API实现型软件构件2110的特征。API实现型软件构件2110可以响应于API调用而通过API2120将值返回给API调用型软件构件2130。

应当意识到，API实现型软件构件2110可以包括不通过API2120指定且不可由API调用型软件构件2130使用的另外的函数、方法、类、数据结构和/或其他特征。应当理解，API调用型软件构件2130可以在与API实现型软件构件2110相同的系统上，或者可以被定位于远处并且使用API2120经由网络来访问API实现型软件构件2110。虽然图21示出了与API2120交互的单个API调用型软件构件2130，但是应当理解，用与API调用型软件构件2130不同的语言（或相同的语言）编写的其他API调用型软件构件也可以使用API2120。

API实现型软件构件2110、API2120和API调用型软件构件2130可以存储于机器可读介质内，该机器可读介质包括用于以可由机器（例如，计算机或其他数据处理系统）读取的形式存储信息的任何机制。例如，机器可读介质包括磁盘、光盘、随机存取存储器、只读存储器、闪存设备等。

在图22（“软件栈”）中，一种示例性实施例，应用能够使用几种服务API来来调用服务1或2，以及使用几种OS API来调用操作系统（OS）。服务1和2能够使用几种OS API来调用OS。

注意，服务2具有两个API，其中之一（服务2的API1）接收应用1的调用并将值返回给应用1，而另一个（服务2的API2）接收应用2的调用并将值返回给应用2。服务1（该服务1能够是例如软件库）调用OS的API1并接收其返回值，而服务2（该服务2能够是例如软件库）调用OS的API1和OS的API2并接收它们的返回值。应用2调用OS的API2并接收其返回值。

示例性数据处理设备

图23是示出可以在本发明的某些实施例中使用的一种示例性计算机系统的框图。应当理解，虽然图23示出了计算机系统的各种构件，但是它并非旨在表示任何特定的体系结构或者构件的互连方式，因为此类细节并不与本发明密切相关。应当意识到，具有更少构件或更多构件的其他计算机系统同样可以用于本发明。

如图23所示，形式为数据处理系统的计算机系统2300包括与处理系统2320、电源2325、存储器2330及非易失性存储器2340（例如，硬盘驱动器、闪存、相变存储器等）耦接的总线2350。总线2350可以通过本技术领域所熟知的各种桥、控制器和/或适配器来相互连接。处理系统2320可以从存储器2330和/或非易失性存储器2340中检索出指令，并且执行指令以执行上文所述的操作。总线2350使上述构件互连在一起，并且还使那些构件与可选的对接部（dock）2360、显示控制器和显示设备2370、输入/输出设备2380（例如，NIC（网络接口卡）、光标控制器（例如，鼠标、触摸屏、触摸板等）、键盘等）以及可选的无线收发器2390（例如，蓝牙、WiFi、红外等）互连。

图24是示出可以在本发明的某些实施例中使用的一种示例性数据处理系统的框图。例如，数据处理系统2400可以是手持式计算机、个人数字助理（PDA）、移动电话、便携式游戏系统、便携式媒体播放器、平板电脑或手持式计算设备，该手持式计算设备可以包括移动电话、媒体播放器和/或游戏系统。作为另一实例，数据处理系统2400可以是网络计算机或者在另一设备内的嵌入式处理设备。

根据本发明的一种实施例，数据处理系统2400的示例性体系结构可以用于上文所述的移动设备。数据处理系统2400包括处理系统2420，该处理系统2420可以包括一个或多个微处理器和/或在集成电路上的系统。处理系统2420与存储器2410、电源2425（该电源2425包括一个或多个电池）、音频输入/输出2440、显示控制器和显示设备2460、可选的输入/输出2450、输入设备2470及无线收发器2430耦接。应当意识到，在本发明的某些实施例中，没有在图24中示出的另外的构件同样可以是数据处理系统2400的一部分，并且在本发明的某些实施例中可以使用比图24所示的构件少的构件。另外，应当意识到，没有在图24中示出的一个或多个总线可以被用来互连本技术领域所熟知的各种构件。

存储器2410可以存储数据和/或由数据处理系统2400执行的程序。音频输入/输出2440可以包括传声器和/或扬声器，用于例如播放音乐和/或通过扬声器和传声器来提供电话功能。显示控制器和显示设备2460可以包括图形用户接口（GUI）。无线（例如，RF）收发器2430（例如，WiFi收发器、红外收发器、蓝牙收发器、无线蜂窝电话收发器等）可以被用来与其他数据处理系统通信。该一个或多个输入设备2470允许用户给系统提供输入。这些输入设备可以是键板（keypad）、键盘、触摸板、多点触摸板等。可选的其他输入/输出2450可以是对接部的连接器。

用于管理在不同的服务提供方间的P2P连接的实施例

在本发明的一种实施例中，上文所述的体系结构被扩展为允许在不同的服务提供方处的对等点建立点对点（P2P）连接，例如，实时的音频、视频和/或聊天连接。因为不同的服务提供方可以使用它们自己的协议以及它们自己的客户ID命名空间，所以本发明的这些实施例提供允许设备交互操作（不管所使用的协议是什么）以及将命名空间集成为单个全局的命名空间的技术。

全局数据库可以被保持用于跟踪所有系统上的所有用户的全局命名空间。但是，假定大量的用户跨多个服务提供方分布，全局数据库法可能难以管理。作为选择，用来识别用户和/或数据处理设备的名称（例如，用户ID、电话号码）可以被广播给所有其他服务提供方，以识别谁能够应答所请求的连接。但是，再一次，这样的系统无法灵活伸缩（即，为每个尝试的连接发送广播消息会消耗相当大量的带宽）。

为了解决上述问题，本发明的一种实施例使用布隆过滤器来在连接尝试期间定位相关的服务提供方。该实施例将针对图25-26所示的体系结构来描述。在图25中示出了四个服务提供方——服务提供方A2510、服务提供方B2511、服务提供方C2512和服务提供方D2513。如同在先前的实施例中那样，每个服务提供方管理着含有由服务提供方提供数据通信服务的一组用户的用户ID和/或电话号码的注册数据库2520-2530。举例来说，在图25中，用户A-C2501-2503由服务提供方A2510提供服务，而用户D-F由服务提供方D2513提供服务。如上所述，在一种实施例中，注册数据库2520-2523将电话号码或用户ID映射到每个用户的数据处理设备的推送令牌。因而，由服务提供方维护的服务器使特定服务提供方的用户能够使用上文所述的技术来定位并建立相互间的点对点（P2P）连接（例如，参见图10-14及相关文字）。作为一个实例，由服务提供方维护的服务器允许用户相互间建立音频/视频聊天会话，例如，FaceTimeTM聊天会话（由本专利申请的受让人设计的技术）。

除了实现在服务提供方自己的用户之间的P2P连接之外，图25和26所示的实施例使不同服务提供方的用户能够相互间建立P2P连接。特别地，如图26所示，每个服务提供方包括用于在开始时查询服务提供方的注册数据库2520、2523以确定特定的用户是否由该服务提供方管理的用户定位服务2600、2610。（为了简便起见，在图26中仅示出两个服务提供方（提供方A和D））。如果用户A2501请求与由同一服务提供方管理的另一用户（例如，用户B2502）的P2P连接，则服务提供方A的用户定位服务2600将识别注册数据库的用户B，并且给用户B发送连接请求（例如，利用从注册数据库2520中检索出用户B的推送令牌）。

但是，如果用户A请求与由不同服务提供方管理的用户（例如，用户F2506）的P2P连接，则服务提供方A2510的定位服务2600将尝试使用从每个其他服务提供方处接收的布隆过滤器2601-2603来定位在不同服务提供方处的用户F。特别地，如图26所示，每个服务提供方包括用于基于其注册数据库2520、2523的当前内容来生成布隆过滤器的布隆过滤器发生器2650、2651。如同本领域技术人员所已知的，布隆过滤器是用来测试元素是否为集合成员的空间有效的概率型数据结构。假阳性是可能的，但是假阴性是不可能的。在本文所述的实施例中，用来生成每个布隆过滤器的“元素”是每个用户的用户ID和/或电话号码。例如，在图26中，服务提供方A2510的布隆过滤器发生器2650使用其全部用户ID（Andy124、Tom4546等）来生成其布隆过滤器2604。类似地，服务提供方D2513的布隆过滤器发生器2651使用在其注册数据库内的全部用户ID（Woody1234、Rick456等）来生成其布隆过滤器2603。在一种实施例中，每个服务提供方都以此方式来生成它自己的布隆过滤器，并且周期性地将该布隆过滤器发送给所有其他服务提供方。然后，每个服务提供方可以使用从其他服务提供方接收到的布隆过滤器来测试并确定特定的用户是否由其他服务提供方管理。

举例来说，在图26中，如果用户ID为Andy123的用户A2501尝试与用户ID为Woody123的用户F2506建立P2P会话（例如，个人音频/视频聊天），则服务提供方A2510的用户定位服务2600在开始时可以尝试在它自己的注册数据库2520内定位用户F的用户名称——Woody123。如果不成功，在一种实施例中，它将查询其他服务提供方的布隆过滤器2601-2603以尝试定位管理用户ID“Woody123”的服务提供方。如上所述，布隆过滤器会提供假阳性，但不会提供假阴性。因而，如果布隆过滤器指出服务提供方B和C不管理Woody123，则服务提供方A将会确定地知道Woody123不由这些服务提供方管理。在所示出的实例中，布隆过滤器查询指出Woody123可能由服务提供方D管理，并且还可以指出Woody123由一个或多个其他服务提供方管理。照此，在一种实施例中，服务提供方A将给可能管理该用户ID的每个服务提供方发送启动消息（例如，用于邀请用户F进入P2P会话的INVITE命令）。实际上确实管理该用户ID的服务提供方将肯定地应答服务提供方A。一旦正确的服务提供方自行识别了（在本例中为服务提供方D），则两个服务提供方就可以充当它们各自用户（在本例中为用户A和F）的代理，并且打开这两个用户之间的通信信道。一旦用户A和F交换了连接数据，他们就可以打开彼此间直接的P2P通信信道（例如，通过使用上文关于图11所描述的技术来交换和/或实现标准的因特网连接建立（“ICE”）处理）。作为选择，如果直接的P2P通信是不可行的（例如，由于不兼容的NAT类型），则用户A和F可以使用图13所示的中继服务1051来打开中继连接（同样参照图12及相关文字）。

在一种实施例中，每个服务提供方都被预料会持续地更新它自己的布隆过滤器，并且将布隆过滤器发送给参与支持P2P音频/视频连接的其他每个服务提供方。更新可以每隔一定时间（例如，每小时一次、每天一次等）就发生，和/或在一定数量的新用户ID被添加到注册数据库之后发生。本发明的基本原理并不限定于用于在服务提供方之间交换布隆过滤器的任何特定机制。

图27示出了用于生成并更新布隆过滤器的方法的一种实施例。该方法可以在图25-26所示的体系结构上执行，但并不限定于任何特定的系统体系结构。在2701，在特定的服务提供方处的用户注册数据库被更新。例如，可以添加新的用户ID/电话号码，并且可以删除旧的用户ID/电话号码。在2702，新的布隆过滤器使用完整的用户ID/电话号码集来生成。在2703，新的布隆过滤器被发送给参与的服务提供方。

图27示出了用于使用布隆过滤器来为客户端定位服务提供方的方法的一种实施例。该方法可以在图25-26所示的体系结构上执行，但并不限定于任何特定的系统体系结构。在2801，一组参与的服务提供方的布隆过滤器被接收。布隆过滤器为了高效访问可以存储于易失性存储器内，和/或可以保持于非易失性存储位置。在2802，接收来自用户（在本例中为用户A）的用于与另一用户（用户F）建立P2P连接的连接请求。在2803，对用户F的用户ID（例如，来自上文实例的Woody123）执行布隆过滤器函数，以排除某些服务提供方。如果布隆过滤器函数对于特定的布隆过滤器返回否定结果，则用户F不由该特定的布隆过滤器管理。但是，如果对于布隆过滤器返回肯定的结果，则完全有可能是与该布隆过滤器关联的服务提供方管理着用户F。如果只返回一个肯定的结果，则在2804，连接邀请被发送给该服务提供方。如果返回多个肯定的结果，则在2804，可以给每个相关的服务提供方发送单独的连接邀请。

然后，用户F已向其注册的服务提供方肯定地应答，并且在2806，两个服务提供方可以充当允许用户交换连接数据的代理，如上所述（例如，推送令牌、公共/专用网络地址/端口、NAT类型等）。如果多个服务提供方肯定地应答（意味着两个服务提供方支持具有相同用户ID的用户），则可以采取另外的步骤来识别正确的用户（例如，比较电话号码、真实名称、网络地址或者有关希望与其进行连接的用户的其他已知信息）。

一旦识别出了用户F的正确的服务提供方，并且必要的连接数据已经交换，则在2807建立在用户A和用户F之间的直接的P2P连接或中继连接（若必要），如上所述。

如同上文关于图11-12所提到的，在本发明的某些实施例中，用来在两个（或更多个）用户之间建立P2P连接的各种服务器在连接过程期间不需要保持任何连接状态信息。这包括例如邀请服务112和连接数据交换服务110。相反，在这些实施例中，针对每个成功的用户处理都积累并发送完整的连接状态，包括（但不限于）：公共/专用IP和端口（有时一般地称为网络信息）、NAT类型、用户ID、推送令牌等。如图29所示，在多提供方的环境中的每个处理都发送的另外一条状态信息是提供方ID码。

转至图29的具体细节，用户A发送启动请求2901（在本文中有时称为“邀请”请求），该启动请求2901包括：它自己的网络ID（ID-A）、使用上文所述的技术确定的它自己的网络信息（例如，公共/专用IP/端口数据、NAT类型等），它自己的推送令牌（Token-A）以及用户F的ID码、电话号码和/或其他类型的标识符。启动请求最初由用户A的服务提供方接收，该服务提供方可以实现上文关于图25-28描述的任何技术以定位用户F的服务提供方（例如，使用布隆过滤器来排除某些服务提供方）。（为了简便起见，在图29中没有示出用户A的和用户F的服务提供方）。

在一种实施例中，一旦用户F的服务提供方被识别出，启动推送操作2902就由用户F的服务提供方发送给用户F，该启动推送操作2902包括用户A的服务提供方的标识符（在本例中为“提供方A”）。提供方A的标识符可以如同N位标识码（例如，16位、32位、64位等）一样简单。作为选择，提供方A的标识符可以包括用于识别提供方A的网关的公共IP地址或者连接至提供方D所需的其他网络数据。不管用来以P2P连接处理的序列识别提供方A的格式如何，本发明的基本原理都保持不变。

在一种实施例中，推送处理2902由推送通知服务（例如，上文所讨论的推送通知服务1050）生成（例如，参见图11及相关文字）。如上所述，由用户A提供的全部原始状态信息以及由服务提供方A的服务器收集的任何附加状态信息都包含于启动推送处理2902内。

在图29所示的实例中，用户F以含有全部先前的状态信息（ID-A、NetInfo-A、Provider A）接受处理2903连同建立P2P连接所需的用户F的信息作出应答，所述用户F的消息包括例如（但不作为限定）用户F的ID（ID-F）、用户F的网络信息（NetInfo-F，可以包括公共/专用IP地址/端口、网络类型等），以及用户F的令牌（Token-F）。用户A和用户F的全部连接状态信息都由用户F的服务提供方接收（在本例中为“提供方D”），用户F的服务提供方将它自己的提供方ID码加入处理（Provider-D）并且将其转发给用户A的服务提供方。如同上文对提供方A所描述的，提供方D的标识符可以如同N位标识码一样简单。作为选择，提供方D的标识符可以包括用于识别提供方D的网关的公共IP地址或者连接至提供方D所需的其他网络数据。不管用来在P2P连接处理的序列中识别提供方D的格式如何，本发明的基本原理都保持不变。

一旦用户A接收到了全部连接状态数据（包括Provider-D数据），用户A和用户F就可以使用上文所述的技术来建立P2P连接，如同处理2905所指出的。

如同上文所讨论的，在某些条件下，用户A和用户F可能需要通过中继服务1051来建立连接（例如，参见图10），而不是直接的P2P连接。如图30所示，在一种实施例中，服务提供方A和F两者都可以使用它们自己的中继服务3001-3002（和/或与第三方中继服务有关系）。在一种实施例中，如果在用户A和用户F之间所尝试的P2P连接失败，则服务提供方A的中继服务3001（即，发起P2P连接的用户的提供方）被用来支持该连接。在一种另选的实施例中，用户F的中继服务3002（即，正被请求与其连接的用户的提供方）被用来支持该连接（如在图31中的用户A2501、中继服务3002和用户F2506之间的虚线所指出的）。在又一种实施例中，全部提供方都同意单个中继服务，并且使用该中继服务来建立用户间的P2P连接。

本发明的一种实施例结合了多种不同的通信协议，用于支持用户设备之间的安全的音频/视频P2P通信。这些协议包括（但不限于）：用于提供经由P2P连接的安全通信的数据报传输层安全（DTLS）协议；安全实时传输协议（或SRTP），用于定义RTP（实时传输协议）的简档，旨在提供加密、消息认证及完整性，以及对单播（设备到设备）及多播（设备到多个设备）应用的RTP数据的重放保护；以及用于在用户设备之间建立音频/视频连接的会话发起协议（SIP）。这些协议可以在本文所描述的本发明的任何实施例的背景下使用。

在一种实施例中，为了身份认证以及使用STRP的流的端到端加密，在图25所示的开放的提供方间网络（inter-provider network）上的每个设备将可由其他设备安全地识别。以下将描述由每个服务提供方发布以允许安全通信的必要的证书格式。

在一种实施例中，每个提供方将需要了解如何发现其他对等点提供方。在一种实施例中，存在查询呼叫路由和对等点信息的一系列全球性的且安全的提供方。这是一系列已认证的服务器，以及它们的寻址信息。这些提供方之一可以作为该服务的主机。

以下描述的是安全级别以及在提供方之间所需的认证，用以认证并信任它们之间的连接。这可以是与在提供方和全球查找数据库之间使用的以及用来认证P2P连接的凭证不同的凭证集。

在一种实施例中，在呼叫路由时间，接受者的提供方（即，正被呼叫的用户）提供返回给呼叫者的对等点证书，以被用来认证端点之间的P2P连接。该证书可以能够由外部实体签名，并且证书要求可以允许任何类型的标识，而不仅仅是电子邮件。

另外，在一种实施例中，音频、视频及信令数据经由单个数据端口在每个数据处理设备上被多路复用于一起。音频、视频及信令数据然后被去多路复用，并且在目标设备处解码。

图25所示的提供方间网络包括多个交互操作层。这些层的交互可以由各种协议指定。该交互的目标是处理用户请求以建立连接，执行在用户端点（在图25中标识为用户A-F2501-2506）之间必要的信息交换，以便他们能够建立音频/视频呼叫会话。

在操作中，图25所示的提供方间网络被实现为彼此通信的一组服务器，用于发起并应答请求。这些请求是协议行为，这些协议行为是转发请求所必需的，使得用户端点能够交换媒体信道连接数据并形成音频/视频呼叫会话。在一种实施例中，每个服务提供方管理与其用户端点间的所有直接通信。

在一种实施例中，用户端点通过用于识别控制端点的参与方（party）的统一资源标识符（URI）来表示。最初支持的URI方案是tel：（用于电话号码）以及mailto：（用于电子邮件地址）。未来可以支持其他URI方案。

在一种实施例中，URI到每个用户端点的映射不是身份映射；它是多对多的关系。单个URI可以映射到多个端点，并且单个端点可以通过多个URI来映射。另外，URI到端点的映射可以跨越多个提供方。例如，可以有在提供方A上的一个端点，以及在提供方B上的不同端点，并且这两个端点都可以通过相同的URI来映射。（但是，在一种实施例中，端点可以每次仅以单个提供方为宿主）。在一种实施例中，端点URI是一般的用户层标识符，如电话号码和电子邮件地址。这些到提供方及端点的映射由系统执行，并且对终端用户是透明的。

在一种实施例中，用于图25所示的提供方间通信的元协议是在HTTP上的字典（dictionary）。在本实施例中，所有动作都作为HTTP GET或POST来执行。如果动作被指定为HTTP GET，则主体将是空的。如果动作被指定为HTTP POST，则主体将含有被编码为字典的请求参数。应答将具有含有被编码为字典的应答参数的主体。在一种实施例中，字典的最初编码是Apple XML属性列表。同样可以使用其他编码，例如，JSON或协议缓冲（ProtocolBuffers）。在一种实施例中，不同的服务提供方可以使用任何协议集或通信机制集来与个体用户设备通信。

在一种实施例中，提供方发现协议被采用以允许图25所示的服务提供方发现彼此。在一种实施例中，引导程序URI由网络的管理实体（例如，主要的或管理服务提供方）发布。该引导程序URI指向含有作为该网络的被接受成员的那组提供方的发现字典。对于每个服务提供方，该字典含有识别信息，以及用于指定如何与该提供方通信的更多的URI。在一种实施例中，当服务提供方启动时，并且之后周期性地，它们检索发现字典。然后，它们对自身进行配置以基于字典内的信息与其他提供方通信。

现在将描述用于在用户间建立P2P通信会话的一组特定协议的细节。但是，应当注意，这些具体的细节仅代表特定的实施例，并且对于遵守本发明的基本原理而言不是必要的。

1.邀请协议

一种实施例的邀请协议被用于初始呼叫设置。这是由用户端点（例如，在图25中的用户端点2501-2506）使用以交换媒体信道连接数据的带外信令，该媒体信道连接数据将被用来建立视频呼叫会话的媒体信道。

1.1.行为

在邀请协议中有四个主要行为。

1.1.1.发起

由发起端点发送，用于启动呼叫。字段：session-id、self-uri、self-token、self-blob、peer-uri。

1.1.2.接受

由接收端点发送，用于指示它愿意参与该呼叫。

字段：session-id、self-uri、self-token、self-blob、peer-uri、peer-token、peer-blob。

1.1.3.拒绝

由接收端点发送，用于指示它不愿意参与该呼叫。字段：session-id、self-uri、self-token、self-blob、peer-uri、peer-token、peerblob。

1.1.4.取消

由任一端点发送，用于指示呼叫将被终止。字段：session-id、self-uri、self-token、self-blob、peer-uri、peer-token、peer-blob。

1.2.行为变化

取决于服务该行为的参与方，这些可以采取三种形式：

*请求（从端点到提供方）

*转发（从提供方到提供方）

*推送（从提供方到端点）

1.3.呼叫流程

1.3.1.用户条目

当端点希望建立连接时，它需要URI来识别接收端点。该URI很可能从由用户提供的某些信息中得出，例如，详细的电话号码，或者存储于地址簿内的电子邮件地址。然后，端点调用在其宿主提供方上的发起请求（Initiate Request）。

1.3.2.发起请求

发起提供方查看URI，并且确定作为由该URI映射的端点的宿主的那组接收提供方。（该组提供方可以包括发起提供方自身）。然后，它调用在所有可应用的接收提供方上的发起转发（Initiate Forward）。

1.3.3.发起转发

每个接收提供方确定接收端点，并且将其发送给发起推送（Initiate Push）。

1.3.4.发起推送

接收端点获得发起推送，并且给用户呈现信息。（这通常是连同“XXX正在呼叫”等行一起的UI）。如果用户决定接收该呼叫，端点将调用接受请求（Accept Request）。（否则，它将调用拒绝请求（Reject Request））。

1.3.5.接受请求

接收端点调用在其宿主提供方上的接收请求。

1.3.6.接受转发（Accept Forward）

接收提供方给发起端点发送接受推送（Accept Push）。

1.3.7.接受推送

发起端点获得接受推送，并且向用户指示它能够进行形成连接。在这点上，两个端点都交换了媒体信道连接数据，所以它们已准备好建立用于音频/视频呼叫会话的媒体信道。从此处起，流程继续媒体信道建立，这将在媒体会话管理（在下文中）中论述。

2.调度优化协议

如同上文所详细讨论的，在一种实施例中，布隆过滤器被用来选择将能够对发起呼叫请求作出应答的候选服务提供方。在一种实施例中，提供方被要求保持代表当前以它们为承载的所有端点的URI的最新的布隆过滤器。所有提供方的布隆过滤器可以用增量的方式分发给其他全部提供方。

调度优化协议。在调度所发起的呼叫时，提供方首先咨询所有其他提供方的布隆过滤器。由此，它们将获得能够实际服务该呼叫的一组候选的提供方。然后，仅对该候选列表发送发起行为。

3.媒体会话管理

媒体会话管理指的是媒体信道以及通过媒体信道输送的媒体流的建立、控制和拆卸。在下列部分中将详述媒体会话管理。

4.媒体信道建立

用于媒体信令的网络数据包、媒体流及会话移除通过媒体信道来发送。媒体信道通过NAT穿越或者中继配置（如上文所详细描述的）来建立。NAT穿越和中继配置要求每个端点都持有两个端点的媒体信道连接数据。

4.1.NAT穿越协议

在一种实施例中，NAT穿越协议被用来通过直接的点对点连接来建立媒体信道。它包括交互式连接建立（ICE）[RFC 5245]所包含的技术的使用。

4.2.中继配置协议

在一种实施例中，中继协议被用来通过中继网络来建立媒体信道。在一种实施例中，它包括TURN[RFC 5761]的使用。

5.媒体信道信令

媒体信令覆盖构建媒体协商和媒体加密的安全性，以及音频和视频参数的媒体协商。

5.1.安全性构建

如上所述，在一种实施例中，数据报传输层安全（DTLS）[RFC4347]被用来保护经由媒体信道的网络流量的通信。DTLS协议可以被实现为提供端到端加密，使得服务提供方将无法访问在用户间传输的音频/视频数据包内的加密内容。

5.2.媒体协商

在一种实施例中，SIP[RFC 3261]被用来协商视频呼叫会话的音频和视频参数。

5.3.音频和视频加密

在一种实施例中，SRTP[RFC 3711]被用来加密音频和视频有效载荷。

6.媒体流向控制

媒体流向控制包括活动的媒体流的管理，以及经由媒体信道来通知媒体状态变化。

6.1.网络适配

在一种实施例中，网络适配技术被实现用于解决通信信道波动。特别地，用户端点可以调节流参数，例如，音频和/或视频比特率，以便适应变动的网络条件，例如，吞吐量的变化、数据包丢失和等待时间。

6.2.视频静音

发送视频的端点可以使视频静音/取消静音。使用SIP MESSAGE来给远程端点发送通知。

6.3.视频方向

发送视频的端点可以改变视频的方向。使用RTP报头扩展信息来给远程端点发送通知。

6.4.视频切换

发送视频的端点可以切换视频源。例如，在包括前向及背向摄像头的用户设备上，视频可以从前向切换至背向。使用RTP报头扩展信息来给远程端点发送通知。

6.5.挂起

在一种实施例中，端点能够通过发送SIP BYE消息来显式地终止活动的会话。

7.媒体信道拆卸

媒体会话可以被显式地或隐式地拆卸。媒体信道的显式拆卸通过发送或接收SIPBYE消息来完成。隐式拆卸可以由于网络连接丢失或不良的网络性能而发生。

8.安全

8.1.证书

在一种实施例中，在图25所示的提供方间系统内的端点之间的通信使用公共密钥加密技术来保护。每个实体（提供方和端点）具有由对其身份进行签名的已认证的CA发布的证书。该证书含有属于该实体的URI，以及其他识别信息。证书能够由相对方用来在通信时验证实体的身份。

8.2.媒体信道信令

SIP消息可以使用DTLS[RFC 4347]来保护。

8.3.音频和视频

音频和视频流可以使用SRTP[RFC 3711]来保护。

9.编码

9.1.音频

9.1.1.音频编解码

音频编解码符合MPEG-4增强型低延迟AAC（AAC-ELD、ISO/IEC14496-3）。

9.1.2.音频质量

在一种实施例中，音频信号的声学特性由3GPP规范为宽带电话终端TS26.131和TS26.132而指定。

9.1.2.音频RTP有效载荷格式

9.2.视频

在一种实施例中，序列参数集（SPS）和图像参数集（PPS）NALU被用来在比特流中携带视频流描述。

9.2.1.视频编解码

在一种实施例中，用来在图25中的用户之间通信的视频编解码是没有B帧的1.2级的H.264高规格（H.264High Profile）（实际上，QVGA 15 fps，max 300kbps）。但是，应当注意，本发明的基本原理并不限定于任何特定的音频/视频格式。

9.2.2.视频RTP有效载荷格式

如上所述，实时传输协议（RTP）可以被用来支持在用户端点之间的音频/视频通信。如图32所示，在一种实施例中，RFC 3984报头3202（即，由RFC 3984定义的，H.264视频的RTP有效载荷格式）被附加于每个12字节的RTP有效载荷3201（含有RTP数据包）。报头规定RTP数据如何使用H.264图像描述扩展来分组。

本发明的实施例可以包括上文所阐明的各种步骤。这些步骤可以用机器可执行的指令来实现，这些指令会促使通用或专用处理器执行某些步骤。作为选择，这些步骤可以由含有用于执行步骤的硬连线的逻辑的特定硬件构件，或者由编程的计算机构件与定制的硬件构件的任意组合来执行。

本发明的要素同样可以被提供为用于存储机器可执行的程序代码的机器可读介质。机器可读介质可以包括（但不限于）：软盘、光盘、CD-ROM，以及磁光盘、ROM、RAM、EPROM、EEPROM、磁卡或光卡，或者适用于存储电子程序代码的其他类型的介质/机器可读介质。

在以上的描述中，为了说明的目的，阐明了众多具体的细节，以便使本发明被彻底理解。但是，本领域技术人员应当清楚，本发明可以在没有这些具体细节中的某些细节的情况下实现。例如，本领域技术人员应当很容易清楚，本文所描述的功能模块及方法可以被实现为软件、硬件或者它们的任意组合。而且，虽然本发明的实施例在这里是在移动计算环境的背景下描述的（即，使用移动设备120-123、601-603），但是本发明的基本原理并不限定于移动计算的实现方式。事实上，在某些实施例中可以使用任何类型的客户端或对等点数据处理设备，包括，例如，台式计算机或工作站计算机。因此，本发明的范围和精神应当依据所附的权利要求书来判定。

Claims (21)

1.一种计算机实现的数据处理方法，所述方法由物理设备执行，所述方法包括：

由服务提供方接收连接到第一用户的请求，所述请求包括对应于所述第一用户的识别码；以及

响应于所接收到的连接请求：

查询由第一服务提供方维护的注册数据库以确定所述第一用户是否向所述第一服务提供方注册；

响应于确定所述第一用户没有向所述第一服务提供方注册，对于从第二服务提供方接收的布隆过滤器：

利用所述布隆过滤器和所述识别码执行布隆过滤器功能；以及

响应于从执行所述布隆过滤器功能接收到肯定的应答，向所述第二服务提供方发送连接邀请；以及

从所述第二服务提供方接收对所述连接邀请的接受，所述接受表明所述第一用户向所述第二服务提供方注册。

2.根据权利要求1所述的数据处理方法，还包括：

向第二用户提供网络连接数据以便与所述第一用户建立点对点(P2P)网络连接，所述网络连接数据标识所述第二服务提供方。

3.根据权利要求1所述的数据处理方法，其中所述识别码包括字母数字串。

4.根据权利要求1所述的数据处理方法，其中所述识别码包括电子邮件地址。

5.根据权利要求1所述的数据处理方法，其中所述识别码包括电话号码。

6.根据权利要求1所述的数据处理方法，其中如果所述第一用户已经向所述第一服务提供方注册，则向第二用户提供网络连接数据以便建立与所述第一用户的点对点(P2P)网络连接，所述网络连接数据标识由所述第一服务提供方管理的网络地址。

7.根据权利要求1所述的数据处理方法，其中如果所述第一用户没有向所述第一服务提供方注册，而是向所述第二服务提供方注册，则将所述第二服务提供方用作给所述第一用户发送连接数据的代理，所述连接数据包括建立从所述第一用户到向所述第一服务提供方注册的第二用户的点对点(P2P)连接所需的网络数据。

8.根据权利要求7所述的数据处理方法，还包括：

将所述第一服务提供方用作给所述第二用户提供所述第一用户的连接数据的代理，所述连接数据是建立从所述第二用户到所述第一用户的P2P连接所需的。

9.根据权利要求6所述的数据处理方法，其中所述网络地址包括TCP/IP地址。

10.一种数据处理系统，包括：

用于由服务提供方接收连接到第一用户的请求的装置，所述请求包括对应于所述第一用户的识别码；以及

响应于所接收到的连接请求：

用于查询由第一服务提供方维护的注册数据库以确定所述第一用户是否向所述第一服务提供方注册的装置；

用于响应于确定所述第一用户没有向所述第一服务提供方注册，对于从第二服务提供方接收的布隆过滤器：

利用所述布隆过滤器和所述识别码执行布隆过滤器功能的装置；以及

响应于从执行所述布隆过滤器功能接收到肯定的应答向所述第二服务提供方发送连接邀请的装置；以及

用于从所述第二服务提供方接收对所述连接邀请的接受的装置，所述接受表明所述第一用户向所述第二服务提供方注册。

11.根据权利要求10所述的数据处理系统，包括：

向第二用户提供网络连接数据以便与所述第一用户建立点对点(P2P)网络连接的装置，所述网络连接数据标识所述第二服务提供方。

12.根据权利要求10所述的数据处理系统，其中所述识别码包括字母数字串。

13.根据权利要求10所述的数据处理系统，其中所述识别码包括电子邮件地址。

14.根据权利要求10所述的数据处理系统，其中所述识别码包括电话号码。

15.根据权利要求10所述的数据处理系统，其中如果所述第一用户已经向所述第一服务提供方注册，则向第二用户提供网络连接数据以便建立与所述第一用户的点对点(P2P)网络连接，所述网络连接数据标识由所述第一服务提供方管理的网络地址。

16.根据权利要求10所述的数据处理系统，其中如果所述第一用户没有向所述第一服务提供方注册，而是向所述第二服务提供方注册，则将所述第二服务提供方用作给所述第一用户发送连接数据的代理，所述连接数据包括建立从所述第一用户到向所述第一服务提供方注册的第二用户的点对点(P2P)连接所需的网络数据。

17.根据权利要求16所述的数据处理系统，还包括：

将所述第一服务提供方用作给所述第二用户提供所述第一用户的连接数据的代理，所述连接数据是建立从所述第二用户到所述第一用户的P2P连接所需的。

18.根据权利要求15所述的数据处理系统，其中所述网络地址包括TCP/IP地址。

19.一种计算机实现的数据处理方法，所述方法由物理设备执行，所述方法包括：

经某一时间段，在第一服务提供方处，接收和存储来自多个服务提供方的多个布隆过滤器，其中所述多个布隆过滤器中的每一个：

是从向所述多个服务提供方中的一个服务提供方注册的所有用户的识别码生成的；

是能够由所述第一服务提供方使用以确定地确定某些识别码没有识别向所述多个服务提供方中的所述一个服务提供方注册的用户；

在所述时间段之后，接收连接到第一用户的请求，所述请求包括第一用户的识别码；以及

响应于所接收到的连接请求：

确定所述第一用户没有向所述第一服务提供方注册；

利用所述多个布隆过滤器中的每一个和所述识别码执行布隆过滤器功能；

响应于至少两个布隆过滤器返回肯定的结果，向由所述至少两个布隆过滤器识别的至少两个服务提供方中的每一个服务提供方发送连接邀请；

接收来自所述至少两个服务提供方中的第一服务提供方的第一接受和来自所述至少两个服务提供方中的第二服务提供方的第二接受，所述多个接受确定地表明所述第一用户和另一用户共享相同的识别码；

执行附加的检查以确定所述第一用户是向所述至少两个服务提供方中的第一个服务提供方还是向第二服务提供方注册。

20.根据权利要求19所述的数据处理方法，其中所述附加的检查包括比较所述第一用户的电话号码与其它用户的电话号码。

21.根据权利要求19所述的数据处理方法，其中所述附加的检查包括比较所述第一用户的真实姓名与其它用户的真实姓名。