法律状态公告日
法律状态信息
法律状态
2016-08-10
授权
授权
2013-11-06
实质审查的生效 IPC(主分类):H04L12/28 申请日:20120316
实质审查的生效
2013-10-09
公开
公开
优先权声明
本申请要求在2011年3月21日提交的、题目为“Apparatus and Method for Managing 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 cone NAT）”，一旦内部地址（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中，移动设备A 120给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和移动设备C 122。对于这些处理，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”），同时被处理器执行。处理器 可以是通用处理器（例如，CoreTM处理器）或专用处理器。 但是，方法可以使用硬件、软件和固件的任意组合来实现。另外，程 序代码可以存储于非易失性存储设备（如硬盘驱动器、光盘（例如， 数字视频盘或压缩盘）或者非易失性存储器（如闪存设备）内。
现在转至图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能够生 成被分配给邀请会话并被用来在所有进一步处理中识别会话的安全的 一次性“会话令牌”。然后，会话令牌的副本被发送回到移动设备A 120并且与邀请请求一起被发送给移动设备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中，移动设备B 121使用用于中继主机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
在一种实施例中，匹配度等于上述每个标准的（归一化权重*年 龄因素值）之和。年龄因素值可以从值1开始，并且在经过了预定的 时间段之后增加。然后，它可以随时间流逝而继续增加（例如，周期 性地增加指定量）。在一种实施例中，作为使用上文所述的年龄因素 值的代替，年龄阈值可以如同以下所描述的那样来建立。某些变量 （例如，连接类型和语言）的归一化值/加权值可以在某些年龄阈值 上应用（即使它们不匹配）。
在一种实施例中，在一对请求A和B之间的“匹配度”是A与B 的及B与A的匹配度的平均值。而且，每个因素的A与B的匹配度 可以基于A的年龄来调整（反之亦然）。在一种实施例中，对于兼 容的匹配可能需要1.0的匹配度。这意味着A和B将仅在NAT兼容 性、连接类型和语言匹配（导致1.0的归一化值）时或者在A和/或 B已经变老使得上述变量中的某些（例如，连接类型和语言）实际上 可忽略（使用在阈值之上或之下的变老因素值）时才匹配。
年龄——表B
年龄阈值可以如同上文的表B所阐明的那样来建立。随着每个 年龄阈值被超过（即，随着请求变为比指定的阈值更老时），变老因 素值可以相继增大至较大的值（例如，1.5、2.0等）。作为选择或者 除此以外，随着不同的年龄阈值被超过，某些变量的加权值可以被添 加至匹配判决（例如，以下所述的连接类型和语言）。
在一种实施例中，在表B中指定的请求年龄限制根据给定的 MSI的匹配流量来调整。在一种实施例中，流量被规定为每特定单 位时间（例如，每10秒、每分钟等）执行的匹配数。因而，流量提 供了关于特定MSI集的繁忙程度的指示。在一种实施例中，MSI集 越忙，在上文的表B中就可以将上述每个阈值设定得越低，以增大 早期成功匹配的可能性并降低匹配器的负载。而且，对给定的MSI 集的负载可以被提供给终端用户（例如，以估计的匹配时间值的形 式），使得中断用户能够选择是否尝试进入特别繁忙的多玩家游戏。 负载值可以用推送通知的形式提供给用户。
现在转至表A的每个变量，在一种实施例中，NAT兼容性根据 图14所示的NAT兼容表1400来确定。如果基于该表确定两个NAT 是兼容的，则可以施加NAT兼容权重。
连接类型——表C
连接类型可以使用如上文的表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可以被设计用于通过调用API 1910以经由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能够是 iPhone OS（由本申请的受让人设计的移动操作系统）。
游戏框架2000能够包括公共应用编程接口（API）2001b以及专 用的或“安全的”API2001a。在一种实施例中，设计用于提供本文所 描述的各种游戏相关的特征的游戏中心应用2031能够调用公共API 2001b和专用API2001a两者，然而其他应用2030（例如，由第三方 设计的应用）仅允许访问公共API2001b。例如，移动设备120的设 计者可能希望将可能涉及敏感信息的某些API函数保留于公共API 2001b之外，以避免被第三方开发人员滥用（例如，朋友请求、朋友 列表等）。但是，安全API2001a和公共API2001b两者可以合并成 可由移动设备上的所有应用访问的单个API（即，并不要求将API 分离成单独的公共及专用组件以符合本发明的基本原理）。标记 “API2001”在下文中有时被用来指代可以在公共API2001b和/或专 用API2001a中找到的操作。
在2010年4月7日提交的、发明人为Marcel Van Os和Mike Lampell、代理人案号为4860.P9127USP1（序列号为No.__）、题目 为“Systems and Methods for Providing a Game Center”的公共未决申 请（以下称为“游戏中心专利申请（Game Center Patent Application）”）中描述了游戏中心应用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和 Andrw H.Vyrros、代理人案号为4860.P9240（序列号为No.__）、 题目为“Apparatus and Method for 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实现 型软件构件（API implementing 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可以包括不通过API 2120指定且不可由API调用型软件构件2130使用的另外的函数、方 法、类、数据结构和/或其他特征。应当理解，API调用型软件构件 2130可以在与API实现型软件构件2110相同的系统上，或者可以被 定位于远处并且使用API2120经由网络来访问API实现型软件构件 2110。虽然图21示出了与API2120交互的单个API调用型软件构 件2130，但是应当理解，用与API调用型软件构件2130不同的语言 （或相同的语言）编写的其他API调用型软件构件也可以使用API 2120。
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和服务提供方D 2513。如同在先前的实施例中那样，每个服务提供方管理着含有由服 务提供方提供数据通信服务的一组用户的用户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或协议缓冲（Protocol Buffers）。在一种实施例中，不同的服务提供方可以使用任何协议 集或通信机制集来与个体用户设备通信。
在一种实施例中，提供方发现协议被采用以允许图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）[RFC 4347]被用来保护经由媒体信道的网络流量的通信。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.媒体信道拆卸
媒体会话可以被显式地或隐式地拆卸。媒体信道的显式拆卸通过 发送或接收SIP BYE消息来完成。隐式拆卸可以由于网络连接丢失 或不良的网络性能而发生。
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），但是本发明的基本原理并不限定于移动计算的实现方 式。事实上，在某些实施例中可以使用任何类型的客户端或对等点数 据处理设备，包括，例如，台式计算机或工作站计算机。因此，本发 明的范围和精神应当依据所附的权利要求书来判定。
机译： 用于管理不同服务提供商之间的点对点连接的设备和方法
机译： 用于管理不同服务提供商之间的点对点连接的设备和方法
机译： 用于管理不同服务提供商之间的点对点连接的设备和方法
