ES2463099T3 - Aparato y procedimiento para emparejar usuarios para sesiones en línea - Google Patents

Abstract

Procedimiento implementado por ordenador para establecer una comunicación punto a punto “P2P”, entre dispositivos móviles que comprende: recepción (1601, 1603) de una serie de solicitudes de emparejamiento de una serie de dispositivos móviles (120-122), incluyendo cada una de las solicitudes de emparejamiento los datos de aplicación que indican una solicitud particular para la que se está solicitando un emparejamiento y que incluye, además, los datos de configuración de red para cada uno de la serie de dispositivos móviles (1502, 1503); determinación (1802) de ajustes de emparejamiento para grupos de la serie de los dispositivos móviles, los ajustes de emparejamiento basados, al menos en parte, en los datos de configuración de red de los dispositivos móviles; y generación (1807) de emparejamientos para dos o más dispositivos móviles en base tanto a los datos de la 15 aplicación como a los ajustes de emparejamiento determinados para los dispositivos móviles.

Description

Aparato y procedimiento para emparejar usuarios para sesiones en línea

ANTECEDENTES

Reivindicación de prioridad

Esta solicitud reivindica la prioridad de la solicitud provisional U.S. número 12/321.842, presentada el 7 de abril de 2010 con el título “aparato y procedimiento para emparejar usuarios para sesiones en línea”.

La invención dada a conocer y reivindicada en esta solicitud fue dada a conocer al público prematuramente y sin la autorización de Apple cuando un prototipo del iPhone 4 de Apple fue aparentemente robado a un ingeniero de Apple el 25 de marzo de 2010. La solicitud de prioridad U.S., en la que se basa esta solicitud, no se presentó antes del aparente robo.

Campo de la invención

Esta invención se refiere, en general, al campo de las redes informáticas. Más particularmente, la invención se refiere a un aparato y procedimiento mejorados para emparejar usuarios de dispositivos informáticos tal como dispositivos móviles para sesiones de comunicación en línea (por ejemplo, sesiones punto a punto (“peer to peer”).

Descripción de la técnica relacionada

A. Traducción de dirección de red (“NAT”)

Las grandes redes públicas, tales como Internet, tienen conexiones frecuentemente a redes privadas menores, tales como las mantenidas por una corporación, el proveedor de servicios de internet, o incluso los domicilios particulares. Por su propia naturaleza, las redes públicas deben tener un acuerdo común sobre la asignación de las direcciones de red, es decir, las direcciones públicas. Por una variedad de razones, el personal de mantenimiento de las redes privadas a menudo eligen utilizar direcciones de red privadas para las redes privadas que no son parte del acuerdo común de asignación. De esta manera, para que el tráfico de red de la red privada pueda atravesar a la red pública, se requiere alguna forma de traducción de las direcciones de red privada/pública (“NAT”).

Un dispositivo que lleva a cabo las operaciones de NAT altera los paquetes de datos que se están enviando desde la red privada para cumplir con el esquema de dirección de la red pública. Particularmente, el traductor de direcciones de red sustituye la dirección y el número de puerto privados originales de un paquete con su propia dirección pública y un número de puerto asignado. Un traductor de dirección de red también altera los paquetes de datos que se están recibiendo de los ordenadores de la red privada para sustituir la dirección pública y el número de puerto de destino con la dirección y el número de puerto privados correcto del receptor destinatario. Tal como se utiliza en este documento, el término dirección se debe interpretar de manera que incluya tanto una dirección como un número de puerto si es apropiado en el contexto, tal como lo entendería un experto en la técnica.

El NAT se ha convertido cada vez en algo común en la informática de redes modernas. Una ventaja del NAT es que retarda la reducción del espacio de las direcciones de red públicas. Por ejemplo, el direccionamiento TCP/IP, que se utiliza en Internet, comprende cuatro cadenas de tres dígitos cada una, proporcionando, de esta manera, un espacio de direcciones finito. Adicionalmente, ciertas partes de este espacio de direcciones están reservadas para un usuario o usuarios particulares, disminuyendo adicionalmente el número actual de las direcciones disponibles. No obstante, si se utiliza el NAT, una red o subred privada puede utilizar un número arbitrario de direcciones y aún presentar una única dirección, pública estandarizada al mundo exterior. Esto hace el número de direcciones disponibles prácticamente ilimitadas, debido a que cada red privada podría, teóricamente, utilizar exactamente las mismas direcciones privadas.

Una ventaja proporcionada por el NAT es una seguridad mejorada que surge del hecho de que aquellos en la red pública no pueden determinar la dirección de red actual (es decir, privada) de un ordenador en una red privada. Esto se debe a que únicamente se proporciona la dirección pública en la red pública mediante el traductor de direcciones de red. Adicionalmente, esta dirección pública puede corresponder a cualquier número de ordenadores en la red privada.

Los diferentes tipos de NAT emplean diferentes niveles de seguridad. Por ejemplo, con un ”NAT de cono completo” (“full cone NAT”), una vez una dirección interna (iAddr:iPort) se mapea con una dirección externa (eAddr:ePort), cualquier ordenador externo puede enviar paquetes a iAddr:iPort enviando los paquetes a eAddr:ePort. Con un “NAT de cono restringido”, un ordenador externo con una dirección hAddr puede enviar paquetes a iAddr:iPort enviando

los paquetes a eAddr:ePort únicamente si iAddr:iPort habían enviado previamente un paquete a hAddr. El puerto del ordenador externo es irrelevante. Con un “NAT de cono de puerto restringido”, un ordenador externo que tiene una dirección/puerto hAddr:hPort puede enviar paquetes a iAddr:iPort enviando los paquetes a eAddr:ePort únicamente si iAddr:iPort ha enviado anteriormente un paquete a hAddr:hPort. Finalmente, con un NAT simétrico, cada solicitud de la misma dirección iAddr:iPort a una dirección IP y puerto de destino específicos se mapea a una única eAddr:ePort. Si el mismo ordenador interno envía un paquete a un destino diferente, se utiliza un mapeado dedirección y puerto externos diferentes. Únicamente un ordenador externo que recibe un paquete de un ordenador interno puede enviar un paquete de vuelta al ordenador interno.

B. Problemas del NAT con las redes punto a punto

La informática de redes punto a punto (“P2P”) se refiere a una arquitectura de red distribuida compuesta por nodos informáticos que hacen que una parte de sus recursos esté directamente disponible a otros participantes de la red. Los puntos (“peers”) en una red P2P establecen canales de comunicación directa entre sí y actúan tanto como clientes como servidores, en contraste con el modelo tradicional cliente-servidor en el que los servidores suministran los recursos y los clientes consumen los recursos. La solicitud de patente US 2009/0086745 A1 describe una red P2P en el que los puntos se emparejan en base a solicitudes de emparejamiento e indicaciones de emparejamiento almacenadas.

Las operaciones de NAT descritas anteriormente plantean numerosos problemas para las conexiones P2P. Por ejemplo, establecer una conexión directa entre dos puntos se vuelve cada vez más difícil si uno o ambos puntos están ubicados detrás de uno o más de los tipos de NAT descritos anteriormente. Este problema se agrava por el hecho de que los dispositivos móviles tales como el Apple iPod Touch®, Apple iPhone®, Apple iPad® y otros diversos dispositivos (por ejemplo, los dispositivos RIM Blackberry®, dispositivos Palm Pre®, etc.) se desplazan frecuentemente entre redes que tiene diferentes implementaciones de NAT. Por ejemplo, el Apple iPhoneTM es capaz de comunicarse en redes Wi-Fi (por ejemplo, redes 802.11b, g, n); redes 3G (por ejemplo, redes de sistema universal de telecomunicaciones móviles (“UMTS”) ,redes de acceso ascendente de paquetes a alta velocidad (“HSUPA”), etc.); y las redes de Bluetooth (conocidas como redes de área personal (“PANs”)). Los futuros dispositivos móviles podrán comunicarse sobre canales de comunicación adicionales tales como WiMAX, telecomunicaciones móviles internacionales (“IMT”) avanzadas y evolución a largo plazo (“LTE”) avanzada, para nombrar algunos.

CARACTERÍSTICAS

Un procedimiento implementado por ordenador, medios legibles por máquina y dispositivos informáticos para establecer una comunicación punto a punto (“P2P”) se describen en las reivindicaciones 1, 17 y 18. En particular, en una realización, un servicio de emparejamiento lleva a cabo una serie de operaciones para atender solicitudes de emparejamiento recibidas de un grupo de dispositivos móviles. En una realización, el servicio de emparejamiento agrupa las solicitudes de emparejamiento en conjuntos emparejables en base a la aplicación para las que se reciben las solicitudes y una o más variables asociadas con la aplicación. Las solicitudes de emparejamiento dentro de cada conjunto de emparejamientos se pueden emparejar en base a variables tales como el tipo de NAT, el tipo de conexión y el idioma asociado con cada uno de los dispositivos móviles. Otras variables tales como la ubicación geográfica, el nivel de habilidad, y la edad de las solicitudes de emparejamiento también se pueden utilizar para realizar decisiones de emparejamiento.

BREVE DESCRIPCIÓN DE LOS DIBUJOS

Un mejor entendimiento de la presente invención se puede obtener de la siguiente descripción detallada conjuntamente con los siguientes dibujos, en los que:

la figura 1 muestra una arquitectura de red en la que un grupo de dispositivos móviles y servicios se comunican sobre una red.

Las figuras 2a-c muestran las transacciones entre una realización de un servicio de intercambio de los datos de conexión (CDX), un servicio de emparejamiento y/o un servicio de invitaciones.

La figura 3 muestra una realización de una estructura de los datos de la credencial.

La figura 4 muestra una realización de un procedimiento implementado por un servicio de CDX.

La figura 5 muestra una realización de un procedimiento implementado por un dispositivo móvil.

La figura 6 muestra un grupo de dispositivos móviles conectados a través de los canales de comunicación primario y secundario.

La figura 7 muestra una realización de un dispositivo móvil para seleccionar entre los canales de comunicación primario y secundario.

5 Las figuras 8a-b muestran un grupo de dispositivos móviles conectados a través de los canales de comunicación primario y secundario y las topologías de red resultantes.

La figura 9 muestra una realización de un procedimiento implementado por ordenador para seleccionar entre los 10 canales de comunicación primario y secundario.

La figura 10 muestra una arquitectura de red en la que un grupo de dispositivos y servicios móviles, que incluye un servicio de directorio y un servicio de notificaciones automáticas, se comunican sobre una red.

15 La figura 11 muestra las transacciones entre una realización de un servicio de invitaciones, un servicio de notificaciones automáticas y un servicio de intercambio de los datos de conexión (CDX).

La figura 12 muestra las transacciones entre una realización de un servicio de invitaciones, un servicio de notificación automáticas y un servicio de retransmisión.

20 La figura 13 muestra una realización de un servicio de retransmisión para establecer una conexión de retransmisión de dos o más dispositivos móviles.

La figura 14 muestra una realización de un cuadro de compatibilidad de NAT para determinar la compatibilidad de 25 NAT.

La figura 15 muestra una realización de un servicio de emparejamiento para emparejar dispositivos móviles para aplicaciones en línea.

30 La figura 16 muestra una realización de un procedimiento para emparejar usuarios o dispositivos.

La figura 17a-d muestra una serie actualizaciones de tablas de ejemplo llevados a cabo para emparejar usuarios o dispositivos.

35 La figura 18 muestra un procedimiento para emparejar usuarios/dispositivos que utilizan diferentes variables de ajuste de emparejamiento.

La figura 19 muestra una estructura que expone una interfaz de programación de aplicaciones (API) para aplicaciones y un servicio de API para comunicarse con un conjunto de servicios.

40 La figura 20 muestra una realización de una estructura de juegos con una API para aplicaciones, un “daemon” de juegos y un módulo de servicios de juego para comunicarse con los servicios.

La figura 21 muestra una realización de una componente de software que implementa una API y una componente 45 de software que llama a la API.

La figura 22 muestra una realización en la que las llamadas a la API se realizan entre sistemas operativos, servicios y las aplicaciones.

50 La figura 23 muestra una realización de una arquitectura de sistema informático de ejemplo.

La figura 24 muestra otra realización de una arquitectura de sistema informático de ejemplo.

DESCRIPCIÓN DETALLADA DE LAS REALIZACIONES PREFERENTES

55 A continuación se describen las realizaciones de un aparato, procedimiento y medio legible por ordenador para establecer, mantener y utilizar los canales de comunicación punto a punto (“P2P”) primario y/o de apoyo en una red. También se describen un servicio de invitaciones y un servicio de emparejamiento para invitar usuarios y emparejar usuarios, respectivamente, para sesiones P2P. Adicionalmente, se describe un servicio de retransmisión para

60 permitir que los usuarios establezcan conexiones de retransmisión bajo ciertas condiciones específicas. Finalmente, se describen una estructura de la aplicación y una interfaz (API) de programación de aplicaciones asociada para permitir que los desarrolladores de aplicaciones diseñen aplicaciones que aprovechan diversas características de colaboración en línea descritas en este documento.

Durante la descripción, para los propósitos de la explicación, se exponen numerosos detalles específicos a efectos de proporcionar un entendimiento exhaustivo de la presente invención. No obstante, será evidente para un experto en la técnica que la presente invención se puede llevar a la practica sin algunos de estos detalles específicos. En otras circunstancias, las estructuras y dispositivos bien conocidos no se muestran o se muestran en forma de un diagrama de bloques para evitar confundir los principios básicos de la presente invención.

APARATO Y PROCEDIMIENTO PARA INTERCAMBIAR LOS DATOS DE CONEXIÓN DE MANERA SEGURA Y EFICIENTE

Tal como se muestra en la figura 1, una topología de red general implementada en una realización de la invención puede incluir un grupo de dispositivos informáticos móviles de “cliente” o “punto” A-D, -120-123-, respectivamente, que se comunican entre sí y con uno o más servicios -110-112- sobre una red -120-. Aunque se muestra como una única nube de red en la figura 1, la “red” -120- puede incluir una variedad de componentes diferentes que incluyen redes públicas como Internet y redes privadas tales como redes Wi-Fi locales (por ejemplo, hotspots inalámbricos o redes inalámbricas domésticas 802.11n), redes de Ethernet de área local, redes de datos móviles (por ejemplo, 3G, Edge, etc.) y redes WiMAX, por nombrar algunas. Por ejemplo, el dispositivo móvil A -120- puede estar conectado a una red Wi-Fi doméstica representada por el enlace de red -125-, el dispositivo móvil B -121- puede estar conectado a una red 3G (por ejemplo, un sistema universal de telecomunicaciones móviles (“UMTS”), un acceso ascendente de paquetes a alta velocidad (“HSUPA”), etc.) representada por el enlace de red -126-, el dispositivo móvil C -122puede estar conectado a una red WiMAX representada por un enlace de red -127- y un dispositivo móvil -123- puede estar conectado a una red Wi-Fi pública representada por el enlace de red -128-. Cada uno de los enlaces de red local -125-128- sobre las que los dispositivos móviles -120-123- están conectados puede acoplarse a una red pública tal como Internet a través de una pasarela y/o un dispositivo de NAT (no mostrado en la figura 1), permitiendo de esta manera la comunicación entre los diversos dispositivos móviles -120-123- sobre la red pública. No obstante, si dos dispositivos móviles se encuentran en la misma red privada o local (por ejemplo, la misma red Wi-Fi), entonces los dos dispositivos pueden comunicarse directamente sobre dicha red local o privada, evitando la red pública. Se debe observar que, por supuesto, los principios subyacentes de la invención de la invención no están limitados a ningún conjunto particular de tipos de red o topologías de red.

Cada uno de los dispositivos móviles -120-123- mostrados en la figura 1 puede comunicarse con un servicio de intercambio de los datos de conexión (CDX) -110-, un servicio de emparejamiento -111- y un servicio de invitaciones -112-. En una realización, los servicios -110-112- se pueden implementar como un software que se ejecuta a través de uno o más dispositivos informáticos físicos tal como servidores. Tal como se muestra en la figura 1, en una realización, los servicios -110-112- se pueden implementar dentro del contexto de un servicio de datos mayor -100gestionado por la misma entidad (por ejemplo, el mismo proveedor de servicios de datos) y accesibles por cada uno de los dispositivos móviles -120-123- sobre la red -120-. El servicio -100- de datos puede incluir una red de área local (por ejemplo, una red de área local basada en Ethernet) que conecta varios tipos de servidores y bases de datos. El servicio de datos -100- también puede incluir una o más redes de área de almacenamiento (“SAN”) para almacenar datos. En una realización, las bases de datos almacenan y gestionan los datos relacionados con cada uno de los dispositivos móviles -120-123- y los usuarios de esos dispositivos (por ejemplo, los datos de cuenta del usuario, los datos de la cuenta del dispositivo, los datos de la aplicación del usuario, etc.)

En una realización, el servicio de emparejamiento -111- puede emparejar dos o más dispositivos móviles para una sesión P2P de colaboración en base a un conjunto específico de condiciones. Por ejemplo, los usuarios de dos o más dispositivos móviles pueden estar interesados en jugar a un juego multijugador específico. En tal caso, el servicio de emparejamiento -111- puede identificar un grupo de dispositivos móviles a participar en el juego en base a variables tales como el nivel de habilidad de cada usuario, la edad de cada uno de los usuarios, el momento en que se solicitó el emparejamiento, el juego específico para el que se solicita el emparejamiento y diversas variables específicas del juego. A modo de ejemplo, y no como limitación, el servicio de emparejamiento -111- puede intentar emparejar usuarios con niveles de habilidad similares para jugar un juego específico. Adicionalmente, los adultos pueden ser emparejados con otros adultos y los niños pueden ser emparejados con otros niños. Además, el servicio de emparejamiento -111- puede dar prioridad a las solicitudes de los usuarios en base al orden en que se recibieron dichas solicitudes. Los principios básicos de la invención no están limitados a ningún conjunto particular de criterios de emparejamiento o ningún tipo particular de aplicación de P2P.

Tal como se describe en detalle a continuación, en respuesta a una solicitud de emparejamiento, el servicio de emparejamiento -111- puede coordinarse con el servicio de CDX -110- para asegurar que todos los participantes emparejados reciban los datos de conexión necesarios para establecer sesiones P2P de una manera segura y eficiente.

En una realización, el servicio de invitaciones -112- también identifica los dispositivos móviles a participar en las sesiones P2P de colaboración. No obstante, en el caso del servicio de invitaciones -112-, al menos uno de los

participantes es identificado específicamente por otro participante. Por ejemplo, el usuario del dispositivo móvil A -120- puede solicitar específicamente una sesión de colaboración con el usuario del dispositivo móvil B -121- (por ejemplo, identificando el dispositivo móvil B con un identificador de usuario o un número de teléfono). Como con el servicio de emparejamiento -111-, en respuesta a una solicitud de invitación, el servicio de invitaciones -112- puede identificar el conjunto de participantes y coordinarse con el servicio de CDX -110- para asegurar que todos los participantes reciban los datos de conexión necesarios para establecer las sesiones P2P en una manera eficiente y segura.

Tal como se ha mencionado anteriormente, en una realización, el servicio de CDX -110- funciona como un punto de intercambio central para los datos de conexión requeridos para establecer las sesiones P2P entre dos o más dispositivos móviles. Específicamente, una realización del servicio de CDX genera los datos de NAT trasversal (a veces denominados como datos de “perforación”) en respuesta a las solicitudes de los dispositivos móviles para permitir que los servicios y clientes externos se comuniquen a través del NAT de cada dispositivo móvil (es decir, para “perforar” a través del NAT para alcanzar el dispositivo). Por ejemplo, en una realización, el servicio de CDX detecta el puerto y dirección IP externos necesarios para comunicarse con el dispositivo móvil y proporciona esta información al dispositivo móvil. En una realización, el servicio de CDX también recibe y procesa las listas de los dispositivos móviles generados por el servicio de emparejamiento -111- y el servicio de invitaciones -112- y distribuye eficiente y seguramente los datos de conexión a cada uno de los dispositivos móviles incluidos en las listas (tal como se describe en detalle a continuación).

En una realización, la comunicación entre los dispositivos móviles y el servicio de CDX -110- se establece utilizando un protocolo de red relativamente ligero tal como sockets de protocolo de datagrama de usuarios (“UDP”). Tal como es conocido por los expertos en la técnica, las conexiones de socket de UDP no requieren diálogos de saludo para garantizar la fiabilidad, el orden de los paquetes o la integridad de los datos y, por tanto, no consume tanto gasto de procesamiento de paquetes como conexiones de socket de TCP. En consecuencia, la naturaleza ligera y sin estado de los UDP es útil para los servidores que respondan consultas menores de un gran número de clientes. Además, a diferencia de los TCP, los UDP son compatibles con la difusión de paquetes (en la que los paquetes se envían a todos los dispositivos en una red local) y una multidifusión (en la que los paquetes se envían a un subconjunto de dispositivos en la red local). Tal como se describe a continuación, aunque se pueden utilizar los UDP, se puede mantener la seguridad en el servicio de CDX -110- cifrando los datos de NAT trasversal utilizando claves de sesión.

En contraste con la baja sobrecarga, el protocolo de red ligero utilizado por el servicio de CDX -110-, en una realización, la comunicación entre los dispositivos móviles -120-123- y el servicio de emparejamiento -111- y/o el servicio de invitaciones -112- se establecen con un protocolo de red inherentemente seguro tal como un protocolo seguro de transferencia de hipertexto (“HTTPS”), que depende de las conexiones de la capa de conexión segura (“SSL”) o de la seguridad de la capa de transporte (“TLS”). Los detalles asociados con estos protocolos son bien conocidos por los expertos en la técnica.

La figura 2a muestra una serie de transacciones de ejemplo que pueden ser implementadas por un servidor de CDX. Cuando se describe el funcionamiento de una realización del servicio de CDX, los términos siguientes tendrán los siguientes significados:

Datos de conexión - Esta es la información que los puntos potenciales necesitan intercambiar entre sí para establecer una sesión punto a punto. Descritas a continuación se encuentran las realizaciones de un mecanismo de cómo se puede intercambiar esta información.

Servidor de CDX - Un servidor de CDX en una realización es un reflector de multidifusión autenticado que permite que las entidades autorizadas intercambien datos arbitrarios. Estos datos se denominan carga útil.

Sesión de CDX - Una sesión de CDX se refiere a un grupo de dispositivos clientes que pueden comunicarse entre sí a través del servidor de CDX. Cada dispositivo cliente que es parte de la sesión es asignado una credencial de CDX. Cada sesión tiene un identificador de sesión de CDX único, que es un entero grande que se puede utilizar para identificar o referirse a una sesión individual.

Solicitud de CDX - Una solicitud que se envía desde un dispositivo cliente al Servidor de CDX. Una solicitud consiste generalmente en dos partes: una credencial de CDX y la carga útil. En esta realización, la carga útil son los datos de conexión encriptados con la clave de sesión.

Respuesta de CDX - Una respuesta de CDX es lo que se “refleja” de vuelta a los otros dispositivos en una sesión de CDX cuando el servidor de CDX recibe una solicitud de CDX de un miembro de la sesión de CDX. Se construye ajuntando la carga útil al Stub de la credencial de CDX de la credencial de CDX utilizado en la solicitud de CDX dada.

Credencial de CDX - Una credencial de CDX le dice al servidor de CDX cómo enviar una carga útil a los miembros de la sesión de CDX. En una realización, se “firma” con la clave de la credencial de CDX para evitar falsificación o la manipulación. Tal como se muestra en la figura 3, en una realización, una credencial de CDX contiene la siguiente información:

El identificador de sesión -301- que no se encripta o se ofusca en una realización.

El número de participantes -302- en la sesión que no se encripta u ofusca en una realización.

El índice -303- del participante en la sesión al que se refiere la credencial (no encriptado u ofuscado en una realización).

Una hora y fecha de caducidad -304-, tras los que la credencial se considera inválida (no encriptados u ofuscados en una realización).

Los datos de perforación de CDX -305-306- para cada participante en la sesión, encriptados utilizando la clave de la credencial de CDX en una realización.

Un código de autenticación de mensajes -307- que utiliza la clave de la credencial de CDX, que actúa como una “firma digital” para asegurarse que la credencial es auténtica.

Stub de la credencial de CDX - La primera parte de una credencial de CDX, menos los datos de perforación de CDX y el código de autenticación del mensaje.

Carga útil - Esta es la segunda parte de una solicitud de CDX y una respuesta de CDX. La carga útil son los datos que un dispositivo cliente desea comunicar a otros dispositivos en la sesión de CDX. En esta realización, la carga útil son los datos de la conexión encriptados con la clave de sesión. El servidor de CDX no decripta la carga útil, en una realización, simplemente la pasa sin modificar.

Clave de sesión - Esta es la clave utilizada por los clientes para encriptar los datos de conexión. En una realización, esta clave no es conocida por el servidor de CDX. En esta realización, la clave de sesión es generada por el servicio de emparejamiento y transmitida a los clientes conjuntamente con sus credenciales de CDX individuales.

Clave de la credencial de CDX - Esta es la clave utilizada para crear y “firmar” las credenciales de CDX. La clave de la credencial de CDX es conocida únicamente por el servidor de CDX y el servicio que genera las credenciales de CDX que, tal como se describe más adelante, podría ser el servicio de emparejamiento y/o el servicio de invitaciones.

Solicitud de perforación de CDX - Un tipo especial de solicitud de CDX que se utiliza para obtener los datos de perforación de CDX del servidor de CDX.

Datos de perforación de CDX - Este es un blob de datos opacos que describe cómo el servidor de CDX puede enviar información al cliente que lo solicitó originalmente. Se obtiene enviando una solicitud de perforación de CDX al servidor de CDX. Se deben reunir los datos de perforación de CDX de cada dispositivo de cliente en la sesión de CDX antes de que se generen las credenciales de CDX. Los datos de perforación de CDX (a veces denominados como “datos de NAT trasversal”) pueden incluir la dirección IP y puerto públicos de un dispositivo solicitante.

Haciendo referencia a la figura 2a, en una realización, el dispositivo móvil A -120- y el dispositivo móvil B -121pueden ejecutar una aplicación de colaboración tal como un juego multijugador o una sesión de conversación de colaboración que requieren una conexión P2P con uno u más dispositivos informáticos. En -201a-, el dispositivo móvil A -120- transmite una solicitud de perforación de CDX al servidor de CDX -110-. El servidor de CDX -110responde entonces con los datos de perforación de CDX en -202a-. En una realización, los datos de perforación incluyen la dirección IP y puerto públicos del dispositivo A y/o cualquier otros datos necesarios para perforar un orificio a través del NAT del dispositivo móvil A (por ejemplo, los datos del tipo de NAT que definen el tipo de NAT del dispositivo móvil A). Transacciones similares se llevan a cabo para el dispositivo móvil B en -201b- y -202b-, respectivamente.

En -203a- y -203b-, los dispositivos móviles A y B envían entonces las solicitudes de emparejamiento que incluyen los datos de perforación de CDX al servicio de emparejamiento, conjuntamente con cualesquiera criterios de emparejamiento adicionales (descritos más adelante). En esta etapa, los dispositivos móviles A y B pueden empezar a construir los datos de conexión necesarios para establecer una conexión P2P. Esto se puede conseguir, por ejemplo, utilizando una transacción tal como una transacción de establecimiento de conexión de internet (“ICE”) (por ejemplo, mediante un servicio de NAT trasversal). No obstante, los principios subyacentes de la invención no están

limitados a ningún mecanismo particular para determinar los datos de la conexión.

En una realización, una vez el servicio de emparejamiento -111- ha encontrado un conjunto de dispositivos cliente con criterios que se corresponden, puede generar un identificador de sesión de CDX único, una credencial de CDX única para cada miembro de la sesión de CDX, y una clave de sesión única. En una realización, el servicio -111- de emparejamiento puede encriptar los datos de perforación de CDX para la credencial de CDX que utiliza una clave de la credencial de CDX única. En -204a- y -204b-, el servicio de emparejamiento entonces puede enviar a cada uno de los dispositivos móviles A y B su credencial de CDX y la clave de sesión.

El dispositivo móvil A recibe la credencial de CDX y la clave de sesión y encripta sus datos de conexión previamente determinados utilizando la clave de sesión, haciendo una carga útil. En una realización, el dispositivo móvil A construye una solicitud de CDX adjuntando la carga útil construida a la credencial de CDX. En -205a-, el dispositivo móvil A envía la solicitud de CDX al servidor de CDX -110-. El dispositivo móvil B también podría llevar a cabo las mismas operaciones y transmitir una solicitud al servidor de CDX en -205b-.

En -206a-, el servidor de CDX -110- recibe la solicitud de CDX, examina la credencial para asegurarse que es válida y auténtica (por ejemplo, en base al código de autenticación de mensajes -307-). Si la credencial de CDX no es válida, se abandona la solicitud. En una realización, el servidor de CDX decripta entonces el conjunto de datos de perforación de CDX que están contenidos en la credencial de CDX que utiliza la clave de la credencial de CDX. En una realización, la clave de la credencial de CDX puede incluir una hora y fecha de caducidad que también se pueden transmitir con las credenciales. El servicio de CDX -110- y el servicio de emparejamiento -111- puede almacenar dos (o más) claves de la credencial de CDX diferentes para encriptar y desencriptar - una primera que está activa actualmente y una segunda que se puede activar al alcanzar la hora o fecha de caducidad de la primera. Al recibir una credencial, el servicio de CDX -110- puede leer la hora y la fecha de caducidad para determinar qué clave de credencial utilizar. Cuando la clave de la credencial de CDX ha caducado, tanto el servicio de CDX -110como el servicio de emparejamiento -111- pueden generar cada uno una clave de la credencial nueva (que será la siguiente clave a utilizar una vez caduque la clave de la credencial actual). En una realización, el servicio de CDX -110- y el servicio de emparejamiento -111- ejecuta el mismo algoritmo de generación de claves para asegurar la consistencia con las dos claves de la credencial. Por ejemplo, se pueden utilizar técnicas tales como las utilizadas por el bien conocido mecanismo de autenticación SecurID RSA en las que se genera un nuevo código de autenticación a intervalos fijos. En una realización, se genera una nueva clave de la credencial de CDX diariamente. No obstante, los principios subyacentes de la invención no están limitados a un mecanismo particular para generar claves de la credencial de CDX.

Las mismas operaciones se pueden lleva a cabo tal como se muestra en -206b- para el dispositivo móvil B. El servidor de CDX construye una respuesta de CDX a la solicitud de CDX y posteriormente utiliza los datos de perforación de CDX para enviar la respuesta de CDX a los participantes de la sesión de CDX (enviando al dispositivo móvil B en -207a- y al dispositivo móvil A en -207b-).

El dispositivo móvil B recibe la respuesta de CDX -207a- del servidor de CDX. El dispositivo cliente B examina el stub de la credencial de CDX para asegurarse que el identificador de sesión concuerda con el identificador de sesión de su propia credencial de CDX. El dispositivo móvil B puede entonces descifrar la carga útil utilizando la clave de sesión, entregando los datos de la conexión del dispositivo móvil A. El dispositivo móvil B utiliza entonces los datos de la conexión del dispositivo móvil A para iniciar el proceso de establecer la sesión P2P. En una realización, éstos implican las transacciones ICE estándar. No obstante, los principios subyacentes de la invención no están limitados a ningún mecanismo particular para establecer la comunicación P2P.

Tal como se ha mencionado anteriormente, en una realización, los dispositivos móviles A y B establecen las sesiones de protocolo seguro de transferencia de hipertexto (“HTTPS”) para comunicarse con el servicio de emparejamiento -111- (por ejemplo, utilizando las transacciones de solicitud/respuesta de HTTPS) y establecer conexiones UDP para comunicarse con el servicio de CDX. Las solicitudes de emparejamiento -204a-, -204bpueden incluir el tipo de NAT y los datos de perforación (por ejemplo, el puerto y dirección IP públicos) determinados previamente para cada dispositivo móvil respectivo. En una realización que implica un juego multijugador, cada solicitud de emparejamiento puede identificar el jugador de cada dispositivo móvil (por ejemplo, utilizando un código de identificador de jugador único), el juego que cada jugador desea jugar, el número de jugadores a participar en el juego, y/o las otras variables de configuración de juego asociadas con el juego deseado. A modo de ejemplo, y no como limitación, las variable de configuración del juego asociadas con un juego pueden incluir un nivel de dificultad (por ejemplo, fácil, normal, difícil), la edad del usuario (por ejemplo, “menores de 13”), una subzona del juego (por ejemplo, “nivel 2”), y/o un nivel de habilidad del jugador (por ejemplo, experto, principiante, intermedio). Tal como se describe en detalle a continuación, estas variables a veces se denominan como una “cubeta” (“bucket”) de juego y se identifican utilizando un “identificador de cubeta” único. Cada juego puede incluir conjuntos de identificadores de cubeta diferentes para identificar las diferentes variables de configuración de juego.

En una realización, el dispositivo móvil B envía una confirmación en -208a- y -209a-. De manera similar, la confirmación del dispositivo móvil A se transmite en -208b- y -209b-. Si las confirmaciones de los dispositivos móviles A o B no se reciben tras un periodo de tiempo especificado, entonces los datos de la conexión -207apueden volverse a enviar al dispositivo móvil B -212-. El servicio de CDX -110- puede iniciar el reintento y/o el dispositivo móvil A 120- puede iniciar el reintento.

La figura 2b muestra un ejemplo más detallado en el que tres dispositivos móviles -120-122- diferentes negocian las conexiones P2P utilizando el servicio de CDX y el servicio de emparejamiento -111-. La figura 2b también muestra dos servicios adicionales utilizados por los dispositivos móviles -120-122- para establecer una conexión: un servicio de NAT trasversal -291- para determinar el tipo de NAT y un servicio de NAT trasversal -290- para determinar los datos de conexión completos para cada dispositivo móvil (por ejemplo, utilizando una transacción de los datos de conexión ICE). Se debe observar, no obstante, que los servicios independientes no se requieren para cumplir con los principios subyacentes de la invención. Por ejemplo, en una realización alternativa, las funciones de NAT trasversal llevadas a cabo mediante cada uno de estos servicios -290-291- pueden ser integradas directamente dentro del servicio de CDX -110- y/o el servicio de emparejamiento -111-. De manera similar, las funciones llevadas a cabo tanto por los servicios de NAT trasversal -290-291- pueden estar integradas dentro de un servicio de NAT trasversal único. En resumen, la separación funcional específica mostrada en la figura 2b no se requiere para cumplir con los principios subyacentes de la invención.

Haciendo referencia ahora a los detalles específicos de la figura 2b, en -220- el dispositivo móvil A transmite una solicitud de tipo de NAT al servicio de NAT trasversal -291-. En respuesta, el servicio de NAT trasversal -291- puede utilizar varias técnicas conocidas que incluyen la implementación de una serie de transacciones para determinar el tipo de NAT utilizado por el dispositivo móvil A. Por ejemplo, el servicio de NAT trasversal -291- puede intentar abrir diferentes puertos y direcciones IP en el NAT del dispositivo móvil A y comunicarse con el dispositivo móvil A a través de dichos puertos utilizando diferentes combinaciones IP/puerto. De esta manera, el NAT utilizado por el dispositivo móvil A puede clasificarse como uno de los tipos de NAT descritos anteriormente (por ejemplo, de cono completo, de cono restringido, de cono de puerto restringido, simétrico) o un tipo de NAT alternativo. Esta información puede proporcionarse entonces al dispositivo móvil A -120- tal como se muestra.

En -221-, el dispositivo móvil A -120- inicia una solicitud de NAT trasversal con el servicio de CDX -110-. En respuesta, el servicio de CDX -110- puede leer la dirección IP pública y el número de puerto público utilizados para la solicitud y transmite esta información de vuelta al dispositivo móvil A -120-. Tal como se ha descrito anteriormente, si un dispositivo está detrás del NAT, su puerto y dirección IP públicos serán diferente de su puerto y dirección IP privados, respectivamente. De esta manera, dependiendo del tipo de NAT utilizado, la dirección IP y puerto públicos se pueden utilizar para “perforar” a través del dispositivo de NAT para alcanzar el dispositivo móvil.

En -222-, el dispositivo móvil A -120- transmite una solicitud de emparejamiento -222- al servicio de emparejamiento -111-. Tal como se ha descrito anteriormente, en una realización, el dispositivo móvil A se comunica con el servicio de emparejamiento -111- utilizando las sesiones de protocolo seguro de transferencia de hipertexto (“HTTPS”) (por ejemplo, utilizando transacciones de solicitud/respuesta HTTPS). La solicitud de emparejamiento puede incluir el tipo de NAT y los datos de perforación (por ejemplo, el puerto y la dirección IP públicos) determinados anteriormente para el dispositivo móvil A -120-. En una realización que implica un juego multijugador, la solicitud de emparejamiento puede identificar el jugador del dispositivo móvil A (por ejemplo, utilizando un código de identificador de jugador único), el juego que el usuario desea jugar, el número de jugadores a participar en el juego y/o otras variables de configuración del juego asociadas al juego deseado (tal como se ha descrito anteriormente con respecto a la figura 2a).

En -223-225- un conjunto de transacciones correspondientes a las transacciones -220-222- se llevan a cabo para el dispositivo móvil B -121- y en -226-228- un conjunto de transacciones correspondientes a las transacciones -220-222- se llevan a cabo para el dispositivo móvil C -122-. De esta manera, siguiendo a la transacción -228-, el servicio de emparejamiento -111- ha recibido las solicitudes de emparejamiento para los tres dispositivos móviles -120-122-. En este ejemplo específico, las solicitudes de emparejamiento dan como resultado que los dispositivos móviles -120-122- se emparejen para una sesión de colaboración particular tal como un juego multijugador (por ejemplo, los usuarios de estos dispositivos móviles pueden haber seleccionado el mismo juego con el mismo conjunto de variables o conjunto de variable similares, dando como resultado, por tanto, en un emparejamiento por parte del servicio de emparejamiento -111-).

El servicio de emparejamiento -111- utiliza los datos contenidos en cada una de las solicitudes de emparejamiento para generar la credencial A, que se transmite al dispositivo móvil A en -229-; la credencial B, que se transmite al dispositivo móvil B en -230- y la credencial C, que se transmite al dispositivo móvil C en -231-. Aunque no se muestra en la figura 2b, el servicio de emparejamiento -111- puede utilizar un servicio de notificaciones automáticas para transmitir las credenciales A, B y C a los dispositivo móviles A, B y C, respectivamente (por ejemplo, tal que el servicio de notificaciones automáticas -1050- mostrado en las figuras 11-12). Una realización de la estructura de los

datos de la credencial utilizada por las credenciales A, B y C se ha descrito anteriormente con respecto a la figura 3.

En -232-, el dispositivo móvil A -120- se comunica con el servicio de NAT trasversal -290- para determinar sus propios datos de conexión. En una realización, esto puede incluir una transacción de los datos de conexión ICE estándar. Tal como se ha mencionado anteriormente, los datos de conexión pueden incluir las direcciones IP, puertos públicos/privados y el tipo de NAT para el dispositivo móvil A -120-.

El dispositivo móvil A -120- adjunta sus datos de conexión a una credencial A y, en -233-, transmite la credencial A con los datos de conexión al servicio de CDX -110-. En una realización, el servicio de CDX -110- procesa la credencial A tal como se ha descrito anteriormente y, en -234- transmite los datos de conexión (que puede estar encriptados) al dispositivo móvil B -121- y al dispositivo móvil C -122-. Para estas transacciones, el servicio de CDX -110- puede utilizar los datos de NAT trasversal para los dispositivos móviles B y C incluidos en la credencial A.

En -236-238-, se llevan a cabo un conjunto de transacciones correspondientes a las transacciones -232-234utilizando la credencial B y en -238-240- se llevan a cabo un conjunto de transacciones correspondiente a las transacciones -232-234- para la credencial C. De esta manera, siguiendo a la transacción -240-, los datos de conexión se han compartido entre cada uno de los dispositivos móviles -120-122-. Utilizando los datos de conexión, las sesiones P2P se establecen entre los dispositivos móviles A y B, los dispositivos móviles A y C, y los dispositivos móviles A y C.

Tal como se muestra en la figura 2c, un servicio de invitaciones -112- también se puede utilizar con el servicio de CDX -110- (bien en lugar del servicio de emparejamiento -111- o además de éste). En otra realización, el servicio de invitaciones -112- procesa las solicitudes de invitación para las conexiones P2P con los dispositivos móviles específicos y/o los usuarios. El servicio de invitaciones -112- puede implementarse como un servicio sin estado (es decir, un servicio que no cambia el estado actual de las transacciones entre cada uno de los dispositivos inalámbricos).

Haciendo referencia a este ejemplo particular, en -250-, el dispositivo móvil A -120- transmite una solicitud de tipo de NAT al servicio de NAT trasversal -291-. En respuesta, el servicio de NAT trasversal -291- puede utilizar diversas técnicas conocidas para determinar el tipo de NAT utilizado por el dispositivo móvil A (algunos de los cuales se han descrito anteriormente). En -251-, el dispositivo móvil A -120- inicia la solicitud de NAT trasversal con el servicio de CDX -110-. En respuesta, el servicio de CDX -110- puede leer la dirección IP pública y el número de puerto público utilizados para la solicitud y transmite esta información de vuelta al dispositivo móvil A -120-. Tal como se ha descrito anteriormente, si un dispositivo se encuentra detrás de un NAT, su puerto y dirección IP públicos serán diferentes a su puerto y dirección IP privados, respectivamente. De esta manera, dependiendo del tipo de NAT que se está utilizando, la dirección IP y el puerto público se pueden utilizar para “perforar” a través del dispositivo de NAT para alcanzar el dispositivo móvil.

Al igual que con el servicio de emparejamiento, en una realización, cada uno de los dispositivos móviles se comunica con el servicio de invitaciones -112- utilizando las sesiones de protocolo seguro de transferencia de hipertexto (“HTTPS”) (por ejemplo, utilizando las transacciones de solicitud/respuesta HTTPS).

En -252-, el dispositivo móvil A -120- transmite una solicitud de invitación al servicio de invitaciones -112- que incluye los datos del NAT trasversal del dispositivo móvil A (por ejemplo, el tipo de NAT, el puerto/dirección IP públicos). En una realización que utiliza un servicio de notificaciones automáticas (descrito en mayor detalle a continuación), la solicitud de invitación puede incluir el token automático del dispositivo móvil A. La solicitud de invitación -252también puede incluir un código de identificación que identifica otro o más dispositivos o usuarios - en este caso los usuarios de los dispositivos móviles B -121- y C -122-. Se pueden utilizar varios códigos de identificación diferentes. Por ejemplo, en el caso de un juego multijugador, los códigos de identificación pueden comprender los códigos de identificador de jugador específicos del juego. En el caso de una sesión de conversación de audio/vídeo, los códigos de identificación pueden comprender los números de teléfono o los códigos de identificación únicos que identifican uno o más usuarios de la lista de amigos del dispositivo móvil A.

En una realización, el servicio de invitaciones -112- lee los códigos de identificación de la solicitud de invitación y lleva a cabo una búsqueda en una base de datos de registro (no mostrada) para ubicar a cada uno de los dispositivos móviles B y C. En una realización particular, cada uno de los dispositivos móviles B y C se ha registrado anteriormente con un servicio automático para recibir notificaciones automáticas desde el servicio de invitaciones -112-. Como tal, en esta realización, el servicio de invitaciones -112- utiliza el servicio de notificaciones automáticas para transmitir las solicitudes de invitación al dispositivo móvil B -121- y al dispositivo móvil C -122- en -253- y -254-, respectivamente. Los detalles adicionales referidos a un servicio de notificaciones automáticas se describen a continuación (véase, por ejemplo, las figuras 11-12 y el texto asociado) y en la aplicación de notificaciones automáticas referenciadas anteriormente.

En una realización, las solicitudes de invitación -253- y -254- incluyen la estructura de los datos de la credencial mostrados en la figura 3 y descritos anteriormente con respecto a las figuras 2a-b. Específicamente, la credencial enviada al dispositivo móvil B incluye una lista encriptada que identifica los dispositivos móviles A y B y la credencial enviada al dispositivo móvil C incluye una lista encriptada que identifica los dispositivos móviles A y C. En una realización, debido a que el servicio de invitaciones -112- puede no tener todavía los datos del NAT trasversal del dispositivo móvil B, la “credencial” en -253- puede incluir otra información que identifica el dispositivo móvil B. Por ejemplo, tal como se expone a continuación con respecto a las realizaciones que utilizan el servicio de transmisión y el servicio de notificaciones automáticas (véase, por ejemplo, las figuras 11-12), la “credencial” en -253- puede incluir los datos del NAT trasversal para el dispositivo móvil A, el código de identificación del dispositivo A, el token automático del dispositivo A, el código de identificación del dispositivo B y el token automático para el dispositivo móvil B. Los mismos tipos de información se pueden proporcionar en -254- para los dispositivos móviles A y C.

En -255-, el dispositivo móvil B puede comunicarse con el servicio de NAT trasversal -291- para determinar su tipo de NAT y, en -256- el dispositivo móvil B puede comunicarse con el servicio de CDX -110- para determinar sus datos de NAT trasversal (por ejemplo, el puerto/dirección IP públicos). En -257-, el dispositivo móvil B transmite una respuesta de invitación al servicio de invitaciones -112- que contiene el código de identificación del dispositivo móvil A y del dispositivo móvil B, datos trasversales NAT y si se utiliza el servicio de notificación “push”, tokens push para los dispositivos móviles A y B. En -258-, el dispositivo móvil B puede recuperar sus datos de conexión actuales comunicándose con el servicio de NAT trasversal -290-. En -259-, el dispositivo móvil B transmite su credencial (credencial B) con sus datos de conexión actuales al servicio de CDX -110-. En respuesta, el servicio de CDX -110procesa la credencial tal como se ha descrito anteriormente y reenvía los datos de conexión al dispositivo móvil A -120-.

Al recibir la respuesta de invitación del dispositivo móvil B, el servicio de invitaciones -112- puede generar una credencial encriptada para el dispositivo móvil A y transmitir la credencial al dispositivo móvil A en -260-. En una realización, la credencial incluye los datos de NAT trasversal, el tipo de NAT y el token automático (si se utiliza el servicio de notificaciones automáticas) para los dispositivos móviles A y B. Las “credenciales” descritas con respecto a la figura 2c pueden ser las mismas que las estructuras de datos o diferentes de la misma para las “credenciales” descritas con respecto al servicio de emparejamiento -111-. Por ejemplo, en lugar de generar una “credencial” encriptada tal como se ha descrito anteriormente, el servicio de invitaciones -112- puede generar simplemente un identificador de sesión único para identificar la sesión de invitación con cada uno de los dispositivos móviles.

En -261-, el dispositivo móvil A recupera sus datos de conexión actuales comunicándose con el servicio de NAT trasversal -290-. El dispositivo móvil A puede adjuntar entonces sus datos de conexión a la credencial y, en -262-, transmitir la credencial con sus datos de conexión al servicio de CDX -110-. El servicio de CDX -110- procesa la credencial tal como se ha descrito anteriormente y reenvía los datos de conexión del dispositivo móvil A al dispositivo móvil B. Finalmente, en -263-, los dispositivos móviles A y B utilizan los datos de conexión intercambiados para abrir una conexión P2P directa. Tal como se describe a continuación, en los casos en los que los tipos de NAT de los dispositivos móviles A y B son incompatibles, se puede utilizar un servicio de retransmisión para permitir la comunicación entre los dispositivos móviles A y B.

En -264-272-, el dispositivo móvil C -122- y el dispositivo móvil A pueden ejecutar una serie de transacciones para establecer una conexión P2P tal como se describe en -255-263- para los dispositivos móviles B y A. Específicamente, en -624-, el dispositivo móvil C -122- se comunica con el servicio de NAT trasversal -291- para determinar su tipo de NAT y, en -265- se comunica con el servicio de CDX -110- para determinar sus datos de NAT trasversal (por ejemplo, el puerto/dirección IP públicos). En -266-, el dispositivo móvil C transmite una respuesta de invitación que contiene el tipo de NAT, los datos de NAT trasversal y el token automático del dispositivo móvil C y del dispositivo móvil A (si se utiliza el servicio de notificaciones automáticas). En -267-, el dispositivo móvil C recupera sus datos de conexión actuales a través del servicio P2P de NAT trasversal -290- y, en -268-, el dispositivo móvil C adjunta sus datos de conexión a la credencial C y transmite la credencial C al servicio de CDX -110-. El servicio de CDX -110- procesa la credencial tal como se ha descrito anteriormente y reenvía los datos de conexión el dispositivo móvil C al dispositivo móvil A -120-.

En -269-, el dispositivo móvil A -120- recibe la respuesta de invitación del dispositivo móvil C del servicio de invitaciones -112- que incluye tanto el tipo de NAT, los datos de NAT trasversal y los tokens automáticos (si se utiliza el servicio automático) del dispositivo móvil A y del C. En -270-, el dispositivo móvil A recupera sus datos de conexión actuales del servicio de NAT trasversal -290-, adjunta sus datos de conexión actuales a la credencial A y, en -271- transmite la credencial A al servicio de CDX -110-. De manera alternativa, puede no requerirse la transacción -270- debido a que el dispositivo móvil determinó sus datos de conexión en la transacción -261-. El servicio de CDX -110- procesa la credencial A tal como se ha descrito anteriormente y reenvía los datos de conexión del dispositivo móvil A al dispositivo móvil C. Finalmente, en -272- el dispositivo móvil A y C utilizan los datos de conexión intercambiados para establecer una conexión P2P directa -272-.

En una realización, el servicio de invitaciones -112- y el servicio de emparejamiento -111- pueden depender de un servicio de notificaciones automáticas (no mostrado) para transmitir los datos a los dispositivos móviles. Por ejemplo, en la figura 2c, las solicitudes de invitación -253- y -254- pueden transmitirse a los dispositivos móviles B -121- y C -122- a través del servicio de notificaciones automáticas. De manera similar, en la figura 2a, las credenciales A y B se pueden transmitir a los dispositivos móviles A -120- y B -121-. En una realización, cuando se activa un dispositivo móvil en la red, registra su token automático en un directorio de registro central accesible por el servicio de notificaciones automáticas. En una realización, el directorio de registro asocia un identificador de usuario o un número de teléfono protegidos por contraseña con un token automático. Si se puede identificar el token automático en el directorio, el servicio de notificaciones automáticas puede utilizar el token automático para transmitir las notificaciones automáticas al dispositivo móvil. En una realización, el servicio de notificaciones automáticas es el servicio de notificaciones automáticas Apple (“APNS”) diseñado por el solicitante de la presente solicitud y descrito, por ejemplo, en la aplicación de notificaciones automáticas referenciada anteriormente. No obstante, se debe observar que un servicio de notificaciones automáticas no es requerido por las realizaciones de la invención mostradas en las figuras 2a-c. Por ejemplo, no se requieren las notificaciones automáticas para el servicio de CDX -110- para llevar a cabo sus funciones tal como se ha descrito en este documento.

La figura 4 muestra un procedimiento que puede implementarse mediante un servidor de CDX -110- para intercambiar los datos de conexión y la figura 5 muestra un procedimiento que puede implementarse mediante un dispositivo móvil para intercambiar los datos de conexión y establecer una conexión P2P. Ciertos aspectos de estos procedimientos ya se han descrito anteriormente con respecto a las figuras 1-2c. En particular, estos procedimientos se pueden implementar dentro del contexto de la arquitectura de red mostrada en las figuras 1-2c pero no están limitados a dicha arquitectura. En una realización, los procedimientos se representan en un código de programa que, cuando se ejecutan mediante un procesador, hacen que se lleven a cabo las operaciones de los procedimientos. El código de programa se puede almacenar en un medio legible por ordenador tal como una memoria de acceso aleatorio (“RAM”) mientras es ejecutado por el procesador. El procesador puede ser un procesador de propósito general (por ejemplo, un procesador CoreTM Intel®) o un procesador de propósito especial. No obstante, los procedimientos se pueden implementar utilizando cualquier combinación de hardware, software y firmware. Además, el código de programa se puede almacenar en un dispositivo de almacenamiento no volátil tal como una unidad de disco duro, un disco óptico (por ejemplo, un disco de video digital o un disco compacto) o una memoria no volátil tal como un dispositivo de memoria flash.

Haciendo referencia ahora al procedimiento mostrado en la figura 4, en -401-, una solicitud de NAT trasversal (también denominada a veces como una solicitud de “perforación”) se recibe para un dispositivo móvil particular - el “dispositivo móvil A” en el ejemplo. En -402-, se genera y se transmite una respuesta de NAT trasversal al dispositivo móvil A. En una realización, generar la respuesta de NAT trasversal puede incluir la determinación del puerto/dirección IP públicos y/o el tipo de NAT del dispositivo móvil A.

Una credencial para el dispositivo móvil A puede ser generada y encriptado posteriormente mediante una entidad de generación de credenciales tal como el servicio de emparejamiento -111- o el servicio de invitaciones -112- descrito anteriormente. En -403-, se recibe la credencial generada para el dispositivo móvil A (“credencial A”) que incluye los datos del NAT trasversal (para el dispositivo A y otro o más dispositivos) y los datos de conexión para el dispositivo

A. En -404-, se autentica la credencial utilizando el código de autenticación del mensaje y se descifran los datos de perforación utilizando la misma clave de la credencial de CDX que la utilizada por la entidad de generación de credenciales para encriptar la credencial. Tal como se ha mencionado anteriormente, en una realización, se identifica la clave de la credencial de CDX correcta utilizando una hora/fecha de caducidad asociada con la clave de la credencial de CDX.

En -405-, se extraen los datos del NAT trasversal para los dispositivos móviles. En -406-, se transmiten los datos de conexión para el dispositivo móvil A a cada uno de los puntos utilizando los datos del NAT trasversal. En -407-, se reciben las confirmaciones de cada uno de los puntos. Si no se han recibido las confirmaciones de todos los puntos, determinados en -408-, entonces se retransmiten los datos de conexión del dispositivo móvil a aquellos puntos que no respondieron en -409-. Cuando se han confirmado todos los datos de conexión, determinados en -408-, termina el procedimiento.

En una realización, el procedimiento mostrado en la figura 4 se puede llevar a cabo para cada uno de los puntos implicados en la transacción P2P para asegurar que cada punto recibe los datos de conexión requeridos para establecer una conexión P2P.

La figura 5 muestra un procedimiento que puede ser llevado a cabo por un dispositivo móvil según las realizaciones de la invención descritas en este documento. En -501-, se transmite una solicitud de NAT trasversal y, en -502-, se recibe una respuesta del NAT trasversal. Tal como se ha descrito anteriormente, los datos del NAT trasversal contenidos en la respuesta pueden incluir la dirección IP/puerto públicos del dispositivo solicitante. En -503-, se transmite una solicitud de emparejamiento que contiene los datos del NAT trasversal. Posteriormente se puede

generar y encriptar una credencial para el dispositivo móvil mediante una entidad de generación de credenciales tal como el servicio de emparejamiento -111- o el servicio de invitaciones -112- descrito anteriormente. Como alternativa a la estructura de datos de la credencial descrita anteriormente, el servicio de emparejamiento -111- y/o el servicio de invitaciones -112- puede identificar simplemente a cada uno de los participantes utilizando un identificador de sesión único.

En -504-, se puede recibir la credencial, en -505-, se adjuntan los datos de conexión para el dispositivo móvil a la credencial; y, en -506- se transmite la credencial con los datos de conexión. En -507-, se reciben los datos de conexión necesarios para establecer conexiones P2P con uno o más puntos. En -508-, se reciben las confirmaciones que indican que uno o más dispositivos inalámbricos han recibido los datos de conexión transmitidos en -506-. Si entonces no se han recibido todas las confirmaciones, en -510-, se retransmiten los datos de conexión a aquellos dispositivos móviles de los que no se han recibido las confirmaciones. Si se han recibido todas las confirmaciones, determinadas en -509-, entonces se utilizan los datos de conexión recibidos en -507- para establecer las sesiones P2P con los otros dispositivos móviles.

APARATO Y PROCEDIMIENTO PARA ESTABLECER Y UTILIZAR LOS CANALES DE COMUNICACIÓN DE APOYO

Los dispositivos móviles actuales son capaces de comunicarse sobre una serie de canales de comunicación diferentes. Por ejemplo, el iPhoneTM Apple es capaz de comunicarse sobre redes Wi-Fi (por ejemplo, redes 802.11b, g, n); redes 3G (por ejemplo, redes de sistema universal de telecomunicaciones móviles (“UMTS”), redes de acceso ascendente de paquetes a alta velocidad (“HSUPA”), etc.) y redes Bluetooth (conocidas como redes de área personal (“PAN”)). Los dispositivos móviles futuros serán capaz de comunicarse sobre canales de comunicación adicionales tales como WiMAX, telecomunicaciones móviles internacionales (“IMT”) avanzadas y evolución a largo plazo (“LTE”) avanzado, para nombrar algunos.

En funcionamiento, los dispositivo móviles actuales seleccionan un canal de comunicación primario de entre un conjunto de canales disponibles. Por ejemplo, los dispositivos móviles se configuran a menudo para elegir una conexión Wi-Fi si se encuentra disponible y para elegir una conexión de datos móviles (por ejemplo, una conexión UMTS) si una conexión Wi-Fi no se encuentra disponible.

En una realización de la invención, un grupo de dispositivos móviles establecen inicialmente los canales de comunicación primarios punto a punto (“P2P”) utilizando los intercambios de datos de conexión ICE y/o utilizando las técnicas de intercambio de datos de conexión descritas anteriormente. Los dispositivos móviles pueden entonces intercambiar los datos de conexión sobre los canales primarios para establecer uno o más canales de comunicación secundarios que se utilizan como canales de apoyo si falla cualquiera de los canales primarios. En una realización, se mantienen abiertos los canales de comunicación secundarios a través del cortafuegos del NAT transmitiendo periódicamente los paquetes de “la señal de funcionamiento” (“heartbeat”) por estos canales.

Tal como se utiliza en esta documento, un “canal” de comunicación se refiere a una ruta de red completa entre dos dispositivos móviles y un “enlace” de comunicación se refiere a una conexión particular utilizada en la ruta de comunicación. Por ejemplo, si el dispositivo A está conectado a internet utilizando una conexión Wi-Fi y el dispositivo B está conectado a internet utilizando una conexión 3G, entonces el “canal” entre el dispositivo A y el dispositivo B está definido tanto por el enlace Wi-Fi y el enlace 3G; el dispositivo A tiene un “enlace” de comunicación Wi-Fi y el dispositivo B tiene un “enlace” de comunicación 3G. Como tal, si el dispositivo A cambia de un enlace Wi-Fi a un enlace 3G, entonces el “canal” entre el dispositivo A y el dispositivo B cambia a pesar del hecho de que el enlace 3G del dispositivo B permanece igual.

A continuación se describirán ejemplos específicos en los que los dispositivos móviles establecen canales de comunicación primarios y secundarios con respecto a la figura 6. No obstante, se debe observar, que los principios subyacentes de la invención no están limitados al conjunto particular de enlaces de comunicación y a los canales de comunicación mostrados en la figura 6.

En la figura 6, el dispositivo móvil A -601- es capaz de conectarse a una red -610- (por ejemplo, Internet) sobre un enlace de comunicación -605- con el dispositivo de NAT -611- y sobre un enlace de comunicación -606- con el dispositivo de NAT -612-. De manera similar, el dispositivo C -603- puede conectarse a la red -610- sobre el enlace de comunicación -609- con el dispositivo de NAT -613- y sobre el enlace de comunicación -610- con el dispositivo de NAT -613-. A modo de ejemplo, y no como limitación, los enlaces de comunicación -605- y -609- pueden ser enlaces de comunicación 3G y los enlaces de comunicación -606- y 610- pueden ser enlaces de comunicación Wi-Fi.

En consecuencia, en este ejemplo, existen cuatro canales de comunicación diferentes que se pueden establecer entre el dispositivo móvil A y el dispositivo móvil B: un primer canal que utiliza los enlaces -605- y -609-; un segundo canal que utiliza los enlaces -605- y -610-; un tercer canal que utiliza los enlaces -606- y -609- y un tercer canal que

utiliza los enlaces -606- y -610-. En una realización, los dispositivos móviles A y B seleccionarán uno de estos canales como el canal de comunicación primario en base a un esquema de prioridades y seleccionará los tres canales restantes como canales de comunicación de apoyo. Por ejemplo, se puede seleccionar un esquema de prioridades para seleccionar el canal con el mayor ancho de banda como el canal primario y utilizar los canales restantes como los canales secundarios. Si dos o más canales tienen un ancho de banda comparable, el esquema de prioridades puede incluir la selección del canal menos caro (suponiendo que el usuario paga una tasa para utilizar uno o más de los canales). De manera alternativa, el esquema de prioridades puede seleccionar el canal menos caro como el canal primario y, si el coste de cada canal es el mismo, seleccionar el canal con mayor ancho de banda. Los diversos esquemas de prioridad diferentes se pueden implementar mientras aún se cumple con los principios subyacentes de la invención.

Los dispositivos móviles A -601- y C -603- pueden utilizar las técnicas descritas anteriormente para establecer el canal de comunicación primario (por ejemplo, intercambiando los datos de conexión a través del servicio de CDX -110-). De manera alternativa, los dispositivos móviles -601-, -603- pueden implementar las transacciones de establecimiento de conexión de internet (“ICE”) estándar para intercambiar los datos de conexión. Independientemente de cómo se establece el canal primario, una vez está establecido, los dispositivos móviles A -601- y C -603- pueden intercambiar los datos de conexión para los canales de comunicación secundarios sobre el canal de comunicación primario. Por ejemplo, si el canal de comunicación primario de la figura 6 incluye el enlace de comunicación -606- y el enlace de comunicación -609-, entonces esta conexión, una vez está establecida se puede utilizar para intercambiar los datos de conexión para los canales de comunicación secundarios que incluyen los enlaces de comunicación -605- y -609-. En este ejemplo, los datos de conexión intercambiados sobre el canal de comunicación primario pueden incluir los datos del NAT trasversal y los datos de tipo de NAT para el NAT -611- y NAT -613-, incluyendo los puertos/direcciones IP públicos y privados para cada uno de los dispositivos móviles.

Una vez se han establecido los canales de comunicación secundarios, se mantienen abiertos utilizando los paquetes de la señal de funcionamiento (“heartbeat”). Por ejemplo, un dispositivo A puede transmitir periódicamente un pequeño paquete de la “señal de funcionamiento” al dispositivo C y/o el dispositivo A puede transmitir periódicamente un pequeño paquete de “señal de funcionamiento” al dispositivo C para asegurar que los puertos NAT utilizados para los canales secundarios permanecen abiertos (los NAT a menudo cierran los puertos debido a la inactividad). Los paquetes de señal de funcionamiento pueden ser paquetes de UDP sin carga útil, aunque los principios subyacentes de la invención no están limitados a ningún formato particular de paquete. Los paquetes de señal de funcionamiento pueden ser paquetes de UDP con un campo de tipo autoidentificación en su cabecera de la carga útil y pueden contener información opcional formateada adicionalmente que incluye, pero no está limitada, a un valor de tiempo de vida del canal.

Tal como se muestra en la figura 7, cada dispositivo móvil -601- almacena y mantiene una estructura de datos -710(por ejemplo, una tabla, un archivo de texto, una base de datos, etc.) que contiene una lista de canales de comunicación primarios y secundarios. Se proporciona una entrada independiente para cada canal de comunicación e incluye los datos de conexión necesarios para utilizar dicho canal (por ejemplo, la dirección IP pública/privada, el tipo de NAT, etc.) y el estado actual de dicho canal (por ejemplo, primario, secundario 1, secundario 2, etc.)

En una realización, las interfaces de comunicación -701- y -702- se utilizan para comunicarse sobre el enlace de comunicación -605- y el enlace de comunicación -606-, respectivamente. Se puede ejecutar un módulo de detección de fallos -705- sobre el dispositivo móvil -601- para detectar cuando ha fallado una interfaz o enlace de comunicación particular o se ha degradado por debajo de un umbral específico. En respuesta, un módulo de gestión del enlace -706- puede leer los datos de conexión primarios/secundarios -710- para promocionar un canal secundario que tiene la siguiente mayor prioridad que el canal primario. La priorización de los canales secundario puede conseguirse utilizando los mismos principios que los tratados anteriormente para los canales primarios (por ejemplo, en base al ancho de banda, coste, fiabilidad, etc.). Una vez se ha seleccionado un canal secundario, el módulo de gestión del enlace -706- puede transmitir una indicación de fallo de enlace a los módulos de gestión de enlaces en los otros dispositivos móviles, que ordenan a esos dispositivos que asciendan el canal de comunicación secundario a un canal de comunicación primario. Entonces estos dispositivos comenzarán a utilizar los datos de conexión asociados con el canal primario seleccionado.

En una realización, no se requiere un “fallo” completo del canal de comunicación primario para forzar un cambio de uno de los canales de comunicación secundarios. Por ejemplo, en una realización, si el canal de comunicación primario se degrada suficientemente (por ejemplo, por debajo de un ancho de banda, tasa de bits o un umbral de fiabilidad particulares), entonces se puede implementar un cambio a un canal secundario tal como se ha descrito en este documento. En una realización, el cambio al canal secundario se lleva a cabo únicamente si el canal secundario es capaz de soportar un mejor rendimiento (por ejemplo, ancho de banda, tasa de bits o fiabilidad) que el canal primario actual.

La figura 8a muestra la misma configuración de red tal como se muestra en la figura 6 con la adición del dispositivo

móvil B -602- conectado directamente a la red -610- y conectado al dispositivo C -603- a través de una conexión de red -620- privada. La red privada -620- puede ser, por ejemplo, una conexión PAN Bluetooth entre el dispositivo B -602- y el dispositivo C -603-. Se puede observar de este ejemplo que el cambio de un canal primario a un canal secundario puede alterar dramáticamente la topología de red. Por ejemplo, tal como se muestra en la figura 8b, si los canales primarios -801- para los dispositivos móviles incluyen el enlace de comunicación -609- (que resulta en conexiones directas entre los dispositivos A, B y C) y los canales secundarios incluyen la red privada -620-, entonces la topología de red puede cambiar tal como se muestra en la figura 8c debido a que la única manera de que el dispositivo A y el dispositivo C se comuniquen utilizando la red privada es a través del dispositivo B. Aunque esto es un ejemplo simplificado con únicamente tres dispositivos, se puede utilizar un número de dispositivos significativamente grande, que resulta en una variedad de diferentes configuraciones de topología de red cuando se cambia entre los canales de comunicación primarios y secundarios.

Una realización de un procedimiento para establecer y mantener los canales secundarios se muestra en la figura 8. En una realización, el procedimiento se puede ejecutar mediante el módulo de gestión de enlaces -706- en cada dispositivo móvil. No obstante, el procedimiento no está limitado a ninguna configuración de dispositivo específica.

En -901-, se selecciona un canal de comunicación P2P primario. Tal como se ha mencionado anteriormente, se puede seleccionar el canal primario en base a un esquema de priorización predefinido. Por ejemplo, se pueden priorizar ciertos tipos de canales de comunicación sobre otros tipos de canales de comunicación. También se pueden priorizar los canales en base a variables tal como el ancho de banda, el coste de uso y/o la fiabilidad.

En -902-, se establecen los canales de comunicación P2P de apoyo. En una realización, se consigue compartiendo los datos de conexión entre todos los dispositivos móviles sobre el canal de comunicación primario. En -903-, se mantienen los canales de apoyo. En una realización, esto implica la transmisión de datos periódicamente sobre los canales de comunicación secundarios (por ejemplo, en la forma de paquetes de señal de funcionamiento periódicos).

En -904-, si el canal P2P primario falla (por ejemplo, debido al enlace de comunicación de un dispositivo móvil específico se cayó o el dispositivo móvil salió del rango del enlace de comunicación), entonces, en -905-, los dispositivos móviles ascienden el canal de apoyo con mayor prioridad al canal primario. En una realización, esto implica que el dispositivo móvil cuyo enlace falló transmite una notificación del fallo de su enlace a los otros dispositivos sobre el canal secundario. Finalmente, en -906-, el canal de apoyo se convierte en canal primario y el proceso vuelve a -902- (en el que se descubren y añaden canales de apoyo adicionales al esquema de priorización).

APARATO Y PROCEDIMIENTO PARA UN SERVICIO DE INVITACIONES PARA ESTABLECER CANALES DE COMUNICACIÓN DE IGUAL A IGUAL (P2P)

Tal como se muestra en la figura 10, además del servicio de CDX -110-, el servicio de emparejamiento -111- y el servicio de invitaciones -112- (algunas realizaciones de los mismos se han descrito anteriormente), una realización de la invención puede incluir un servicio de registro/directorio -1052-, un servicio de notificaciones automáticas -1050- y un servicio de retransmisión -1051-. Tal como se ha mencionado anteriormente, en una realización, el servicio de invitaciones -112- y/o el servicio de emparejamiento -111- pueden utilizar el servicio de registro/directorio -1052- para identificar los dispositivos móviles registrados y el servicio de notificaciones automáticas -1050- para transmitir datos a los dispositivos móviles. En una realización, cuando se activa un dispositivo móvil en la red, registra un “token automático” (a veces referido como un “identificador de cuenta del servicio de notificación” en la aplicación de notificación automática) con una base de datos mantenida por el servicio de registro/directorio -1052asociando el token automático con una contraseña protegida por el identificador de usuario o un número de teléfono. Si el token automático se identifica en el directorio de registro (por ejemplo, llevando a cabo una consulta con el identificador de usuario), el servicio de notificaciones automáticas -1050- puede utilizar el token automático para transmitir las notificaciones automáticas a un dispositivo móvil. En una realización, el servicio de notificaciones automáticas es el servicio de notificaciones automáticas de Apple (“APNS”) diseñado por el solicitante de la presente aplicación y descrito, por ejemplo, en la aplicación de notificaciones automáticas referida anteriormente.

La figura 11 muestra una realización de la invención en la que el servicio de notificaciones automáticas -1051- se utiliza para establecer una conexión P2P directa ente dos dispositivos móviles y la figura 12 muestra una realización que se utiliza para establecer una conexión P2P a través del servicio de retransmisiones -1051-. Tal como se describe a continuación, la decisión de si utilizar el servicio de retransmisión -1051- para establecer una conexión P2P se puede basar en la viabilidad de establecer un conexión P2P directa entre los dispositivos móviles (por ejemplo, en base a los problemas de compatibilidad de NAT).

Haciendo referencia ahora a la figura 11, en -1101-, un dispositivo móvil A -120- transmite una invitación para invitar al dispositivo móvil B -121- a una sesión de comunicación P2P (por ejemplo, un juego de video de colaboración, una conversación de vídeo P2P, etc.). En una realización, la invitación incluye un código de identificador de usuario que

identifica el dispositivo móvil B -121- (y/o el usuario del dispositivo móvil B) dentro del contexto de una aplicación en línea específica. Por ejemplo, el código de identificador de usuario puede ser un identificador de jugador para un juego P2P multijugador específico y puede tomar la forma de un identificador universalmente único (UUID), por ejemplo. De manera alternativa, en algunas realizaciones, el código de identificador puede ser un número de teléfono de un dispositivo móvil B -121-. Se puede utilizar un código de identificador de juego para identificar el juego multijugador que el dispositivo móvil A está invitando al dispositivo móvil B a unirse. Se puede utilizar un identificador de cubeta para identificar una configuración para dicho juego (tal como se describe en este documento con respecto al servicio de emparejamiento).

La invitación -1101- también puede incluir un código de identificador que identifica el dispositivo móvil A -120- y los datos de conexión/de NAT trasversal asociados con el dispositivo móvil A (por ejemplo, los puertos y direcciones IP públicos/privados para el dispositivo móvil A y el tipo de NAT para el dispositivo de NAT del dispositivo A). Los datos de conexión/de NAT trasversal o los datos de tipo de NAT se han determinado anteriormente para el dispositivo móvil A antes de la solicitud de invitación -1101- (por ejemplo, a través del NAT trasversal, el tipo de NAT y las transacciones de datos de conexión tal como las tratadas anteriormente con respecto a las figura 2a-c). Tal como se ha mencionado anteriormente, la solicitud de invitación -1101- puede tomar la forma de una solicitud HTTPS. Además, para mayor seguridad, la solicitud de invitación -1101- puede incluir un certificado de cliente firmado por una autoridad de certificación especificada previamente.

Independientemente del tipo particular del código de identificación utilizado para identificar el dispositivo móvil B, el código de identificador es recibido por el servicio de invitaciones -112- y, en -1102-, el servicio de invitaciones -112puede llevar a cabo una búsqueda en el servicio de directorio -1052- (no mostrado en la figura 11) para identificar un identificador de cuenta del servicio de notificaciones tal como un token automático utilizado para notificaciones automáticas al dispositivo B (“token automático B”). En una realización, las operaciones de búsqueda pueden llevar a cabo diversas comprobaciones para determinar si se debe permitir la invitación. En primer lugar, se puede confirmar que el código de identificación para el dispositivo móvil A (“ID-A”) y el token automático del dispositivo A (“token automático A”) han registrado su asociación dentro de la base de datos del servicio de directorio. La operación de búsqueda -1102- también puede confirmar que se permite que el usuario del dispositivo móvil A invite al usuario del dispositivo móvil B (por ejemplo, el usuario del dispositivo móvil B puede especificar que únicamente los otros usuarios registrados como amigos de B pueden invitar al usuario B; o puede especificar que no se permite ninguna invitación). En una realización, si falla alguna de estas comprobaciones, se cancela la invitación y el servicio de invitaciones -112- puede devolver un error al dispositivo móvil A.

Aunque se describe un “token automático” en esta realización, se debe observar que los principios subyacentes de la invención no están limitados al uso de un “token automático” o ninguna otra estructura de datos particular para autenticar y transmitir notificaciones a dispositivos móviles.

En una realización, una vez se ha identificado el token automático, el servicio de invitaciones -112- puede generar un “token de sesión” seguro, de un solo uso, asignado a la sesión de invitación y utilizado para identificar la sesión en todas las demás transacciones. Entonces se transmite una copia del token de sesión de vuelta al dispositivo móvil A -120- y se envía al dispositivo móvil B con la solicitud de invitación. En una realización, el token de sesión se utiliza conjuntamente con la estructura de datos de la credencial descrita anteriormente y, en otra realización, se utiliza únicamente el token de sesión.

En -1103-, el servicio de invitaciones -112- transmite una solicitud automática al servicio de notificaciones automáticas -1050-. En una realización, la solicitud automática puede incluir los datos del NAT trasversal para el dispositivo móvil A, el código de identificador del dispositivo A, el token automático A, el código de identificador del dispositivo B y el token automático B. En una realización, esta información puede estar empaquetada y encriptada con una estructura de datos de la “credencial” tal como se ha descrito anteriormente. En otra realización, los datos se transmiten simplemente con el identificador de sesión de invitación.

Debido al dispositivo móvil B -121- en este ejemplo se ha registrado con el servicio de notificaciones automáticas -1050-, el servicio de notificaciones automáticas -1050- puede ubicar y transmitir la solicitud de invitación al dispositivo móvil B -121- en -1104-. La invitación transmitida -1104- puede incluir el token de la sesión, los datos del NAT trasversal o los datos de conexión del dispositivo móvil A y el código de identificación del dispositivo móvil B. En respuesta a la solicitud de invitación, el dispositivo móvil B puede determinar su información de red (por ejemplo, los datos del NAT trasversal/conexión, el tipo de NAT, etc.) llamando a un servicio de NAT trasversal o el servicio de CDX -110- tal como se ha descrito anteriormente.

En -1105-, el dispositivo móvil B acepta la invitación. La aceptación -1105- puede tomar la forma de una llamada HTTPS al servicio de invitaciones -112- y puede incluir un certificado de cliente firmado por la autoridad certificada especificada previamente (mencionada anteriormente con respecto a la solicitud de invitación). En una realización, la aceptación -1105- puede incluir el código de identificación para dispositivos móviles A y B y los datos del NAT

trasversal/conexión y/o el tipo de NAT para los dispositivos móviles A y B. La aceptación -1105- puede incluir también los tokens automáticos para los dispositivos móviles A y B y/o el token de sesión. En una realización, la aceptación -1105- también puede contener una indicación en cuanto a si es un reintento de un intento de una conexión directa fallida anterior. No obstante, en otra realización, la aceptación -1105- no contiene la indicación de reintento. En su lugar, al detectar un intento de conexión P2P fallido, uno de los dos dispositivos móviles puede transmitir una “invitación de retransmisión” especial al servicio de invitaciones -112-. En respuesta, el servicio puede iniciar directamente la serie de transacciones de retransmisiones descrita a continuación con respecto a la figura 12 (iniciándose en -1201-).

En -1106-, el servicio de invitaciones -112- puede llevar a cabo una comprobación de compatibilidad para determinar si es viable una conexión P2P directa entre los dispositivos móviles A y B. Por ejemplo, en una realización, si la aceptación -1105- recibida del dispositivo móvil B indica que es un reintento de un intento de una conexión directa anterior fallida (o un número especificado de intentos de conexión directa anteriores fallidos), entonces el servicio de invitaciones puede concluir que no es viable una conexión P2P directa. El servicio de invitaciones -112- puede comparar los datos de tipo de NAT para los dispositivos móviles A y B para determinar si los dispositivos NAT de los dispositivos móviles A y B soportarán una conexión P2P directa. Ciertas combinaciones de tipos de NAT son conocidos por ser incompatibles para establecer las conexiones P2P. Por ejemplo, se puede utilizar un NAT de cono completo con cualquier otro tipo de NAT excepto un NAT cerrado/protegido por cortafuegos para establecer una conexión P2P directa. En cambio, un NAT simétrico sólo puede ser utilizado con un NAT de cono completo para establecer una conexión P2P directa. La fiabilidad de combinar diversos tipos de NAT en una realización de la invención se expone en la tabla de compatibilidad de NAT -1400- mostrada en la figura 14, en el que las columnas representan los tipos de NAT de un dispositivo móvil (por ejemplo, el dispositivo móvil A) y las filas representan los tipos de NAT de otro dispositivo móvil (por ejemplo, el dispositivo móvil B). Un “1.0” en una célula indica que los tipos de NAT en las filas y columnas asociadas son compatibles y un “0.0” indican que los tipos de NAT son incompatibles.

En una realización, si la comprobación de compatibilidad -1106- determina que no es viable una conexión P2P directa, entonces el servicio de invitaciones -112- puede transmitir una solicitud de búsqueda de retransmisión -1201- tal como se describe a continuación con respecto a la figura 12. No obstante, si la comprobación de compatibilidad -1106- determina que una conexión P2P directa es viable, entonces el servicio de invitaciones -112puede transmitir una solicitud automática -1107- al servicio de notificaciones automáticas -1050- que contiene la aceptación del dispositivo móvil B de la invitación del dispositivo móvil A. La solicitud automática -1107- y la posterior comunicación automática -1108- al dispositivo móvil A desde el servicio de notificaciones automáticas -1050- puede incluir el token de sesión y ambos token automático del dispositivo móvil A y B, el código de identificador y/o los datos del NAT trasversal o de conexión. En una realización, esta información se puede empaquetar dentro de la estructura de datos de la “credencial” descrita anteriormente (véase, por ejemplo, las figuras 2a-c y el texto asociado) y puede ser encriptado utilizando una clave única. De manera alternativa, esta información puede ser transmitido simplemente con un identificador de sesión de invitación único. El servicio de invitaciones -1050- también puede notificar el dispositivo móvil B que se intentará una conexión directa.

En esta etapa, los dispositivos móviles A y B tiene suficiente información para establecer una conexión P2P directa. En una realización, esto se consigue utilizando el servicio de CDX -110- tal como se ha descrito anteriormente. Por ejemplo, el dispositivo móvil B adjunta sus datos de conexión a la credencial B y, en -1109-, transmite la credencial B (con los datos de conexión) al servicio de CDX. Justo antes de esta transacción, el dispositivo móvil B puede implementar una transacción tal como una transacción -235- mostrada en la figura 2b a efectos de asegurar que sus datos de conexión son actuales. El servicio de CDX -110- autentifica entonces la credencial (por ejemplo, utilizando la clave de sesión única tal como se ha descrito anteriormente), extraen los datos de conexión del dispositivo móvil B y reenvía los datos de conexión al dispositivo móvil A en -1110-. De manera similar, el dispositivo móvil A adjunta sus datos de conexión a la credencial A y, en -1111-, transmite la credencial A (con los datos de conexión) al servicio de CDX -110-. Justo antes de esta transacción, el dispositivo móvil A puede implementar una transacción tal como una transacción -232- mostrada en la figura 2b a efectos de asegurar que sus datos de conexión son actuales. El servicio de CDX -110- autentica entonces la credencial (por ejemplo, utilizando la clave de sesión única tal como se ha descrito anteriormente), extrae los datos de conexión del dispositivo móvil A y reenvía los datos de conexión al dispositivo móvil B en -1112-. Finalmente, en -1113-, los dispositivos móviles A y B entras en una conexión P2P directa utilizando los datos de conexión intercambiados.

Haciendo referencia ahora a la figura 12, si la comprobación de compatibilidad -1106- determina que la conexión P2P directa no es viable, entonces el servicio de invitaciones -112- puede transmitir una solicitud de búsqueda de retransmisión -1201- al servicio de retransmisión -1051- para determinar un ordenador de retransmisión a utilizar por cada uno de los dispositivos móviles. La solicitud -1201- puede contener la información de red para los dispositivos móviles A y B (por ejemplo, los datos del NAT trasversal/conexión y/o los datos de tipo de NAT) que son utilizados por el servicio de retransmisión -1051- para seleccionar ordenadores de retransmisión adecuados para ambos dispositivos móviles. Tal como se muestra en la figura 13, una realización del servicio de retransmisión -1051

incluye una serie de ordenadores de retransmisión -1302-1303- y una base de datos de ordenadores de retransmisión que contienen una información de red relacionada con cada uno de los ordenadores de retransmisión. El servicio de invitaciones -112- transmite una solicitud de búsqueda de retransmisión -1201- a un servicio de búsqueda de retransmisión -1300-, que consulta la base de datos de ordenadores de retransmisión -1301- utilizando la información de red para los dispositivos móviles A y B. Al recibir los resultados de las bases de datos, el servicio de búsqueda de retransmisión -1300- proporciona una respuesta -1202- que identifica los ordenadores de retransmisión seleccionados -1302-1303-.

En una realización, la respuesta de búsqueda de retransmisión -1202- contiene un token de retransmisión generado por el servicio de retransmisión y las direcciones de red (puertos/direcciones IP) de los ordenadores de retransmisión -1302-1303- a utilizar por los dispositivos A y B para la conexión de retransmisión. En una realización, el token de retransmisión está asociado con la sesión de retransmisión y es utilizado por los ordenadores de retransmisión -1302-1303- para autenticar los dispositivos móviles A y B al conectar al servicio de retransmisión -1051-. El token puede tomar varias formas que incluyen, por ejemplo, el código de identificador único de sesión de retransmisión del identificador, un certificado digital y/o una clave de encriptado única asociada con la sesión de retransmisión.

En -1203-, el servicio de invitaciones transmite una respuesta de retransmisión -1203- al dispositivo móvil B -121que contiene una indicación de que se realizará una conexión de retransmisión. En una realización, la respuesta de retransmisión -1203- puede incluir el token de retransmisión y la información de red para el ordenador de retransmisión B -1303-. En una realización, la respuesta -1203- puede ser enviada directamente al dispositivo móvil B (evitando el servicio de notificaciones automáticas -1050-) debido a que es enviado en respuesta a la aceptación -1105- del dispositivo móvil B.

El servicio de invitaciones -112- transmite la respuesta de retransmisión -1204- al dispositivo móvil A que puede incluir el token de retransmisión y la información de red para el ordenador de retransmisión B -1303-. En este caso, la respuesta -1204- se transmite al dispositivo móvil A a través del servicio de notificaciones automáticas -1050- en la transacción -1205-.

En -1206-, el dispositivo móvil A -120- utiliza la información de red para el ordenador de retransmisión A -1302- para establecer una conexión con el servicio de retransmisión -1051-. De manera similar, en -1207-, el dispositivo móvil B -121- utiliza la información de red para el ordenador de retransmisión B -1303- para establecer una conexión con el servicio de retransmisión -1051-. En cada una de estas transacciones, se abren nuevos huecos en cualquiera de los cortafuegos del NAT de los dispositivos móviles A y B y los datos del NAT trasversal/de conexión para los dispositivos móviles A y B se pueden determinar mediante el servicio de retransmisión -1051- y se devuelven a los dispositivos móviles A y B, respectivamente (por ejemplo, determinando el puerto/IP públicos para los dispositivos). En una realización, el servicio de retransmisión -1051- y los dispositivos móviles A y B implementan el protocolo de NAT de retransmisión que utiliza el trasversal (“TURN”) que, tal como es entendido por los expertos en la técnica, permite que un elemento tras el NAT o el cortafuegos reciba datos entrantes sobre conexiones TCP o UDP.

En -1208-, el dispositivo móvil A transmite una actualización de la retransmisión al servicio de invitaciones -112- que se reenvía al servicio de notificaciones automáticas en -1209- y se transmite al dispositivo móvil B en -1210-. De manera similar, en -1211- el dispositivo móvil B transmite una actualización de la retransmisión al servicio de invitaciones -112- que se reenvía al servicio de notificaciones automáticas en -1212- y se transmite al dispositivo móvil A en -1213-. La actualización de la retransmisión transmitida por el dispositivo móvil A puede incluir el token de sesión, el código de identificador de cada dispositivo y los datos de conexión/del NAT trasversal determinado por la retransmisión en -1206- y -1207- (es decir, con el dispositivo móvil A enviando sus datos de conexión/del NAT trasversal al dispositivo móvil B y viceversa). En una realización, las operaciones de actualización de la retransmisión se llevan a cabo debido a que la información NAT de cada dispositivo móvil puede cambiar.

Finalmente, en -1214- y -1215- los dispositivos móviles A y B, respectivamente, establecen una conexión P2P a través del servicio de retransmisiones -1051-. En una realización, las conexiones de retransmisión se pueden establecer cuando el dispositivo móvil A envía los datos de conexión/de NAT trasversal del dispositivo móvil B al servicio de retransmisión -1051-, y viceversa, permitiendo, de esta manera, el servicio de retransmisión para determinar la ruta correcta de cada ordenador de retransmisión de cada punto -1302-1303-.

Utilizando las técnicas descritas anteriormente, el servicio de invitaciones -112- puede implementarse como un servicio sin estado que es inherentemente escalable y flexible, incluso en un sistema a gran escala con un gran número de dispositivos móviles. Por ejemplo, debido a que el servicio de notificaciones automáticas -1050- es inherentemente capaz de ubicar y transmitir contenido a los dispositivos móviles registrados, no se requiere que el servicio de invitaciones rastree la ubicación actual de cada dispositivo. Adicionalmente, debido a que los dispositivos pueden transmitir los datos de estado de toda la sesión con cada solicitud y respuesta, nunca se requiere que el servicio de invitaciones mantenga ninguna información de estado previa a la conexión, reduciendo, de esta manera,

los requerimientos de almacenamiento y procesamiento del servicio de invitaciones. Dicha implementación es particularmente útil en un sistema a gran escala.

SISTEMA Y PROCEDIMIENTO PARA EMPAREJAR USUARIOS PARA SESIONES EN LÍNEA

Tal como se muestra en la figura 15, una realización de un servicio de emparejamiento -111- puede incluir un emisor del emparejador -1501- para recibir las solicitudes de emparejamiento y transmitir las respuestas de emparejamiento a los dispositivos móviles -120-122-; una base de datos -1512- para almacenar las solicitudes de emparejamiento en una tabla de solicitudes -1502- y para almacenar los datos del conjunto emparejable en una tabla del identificador del conjunto emparejable (“MSI”) -1503- y uno o más emparejadores -1510- para recuperar las solicitudes de emparejamiento de la base de datos -1512-, llevando a cabo las operaciones de emparejamiento, y almacenando los resultados de emparejamiento en la base de datos -1512-. No obstante, se debe observar que los principios subyacentes de la invención no están limitados a la arquitectura específica mostrada en la figura 15.

En una realización, el emisor del emparejador (“matchmaker”) actúa como interfaz con respecto al servicio de emparejamiento -111-, recibiendo peticiones de los dispositivos móviles -120-122-, traduciendo estas peticiones en órdenes de almacenamiento de las peticiones en la base de datos -1512- y traduciendo y comunicando estos resultados a los dispositivos móviles -120-122-.

En funcionamiento, cuando llega una nueva solicitud de emparejamiento, el emisor del emparejador -1501- puede almacenar la solicitud dentro de una fila de la tabla de solicitudes -1502-. En una realización, el emisor -1501- asigna a cada solicitud de emparejamiento un código de identificador de solicitud (“RID”), mostrado simplemente como “A”, “B” y “C” en la figura 15 (correspondiente a los dispositivos móviles A, B y C, respectivamente). Mientras se muestra utilizando una designación de letra en la figura 15 por simplicidad, el código RID puede ser una cadena, un entero o cualquier otro tipo de variable para rastrear las solicitudes de emparejamiento dentro de la base de datos.

A cada solicitud de emparejamiento se le puede asignar un valor de identificador de conjunto emparejable (“MSI”) que se almacena en la tabla de solicitudes -1502-. En una realización, el MSI puede identificar la aplicación específica por la que se solicita un emparejamiento y/o los parámetros de configuración a utilizar para esta aplicación. Por ejemplo, un valor MSI de 12:4 puede identificar un juego multijugador particular con el identificador “12” y puede identificar una configuración particular para el juego con el identificador “4”. Más específicamente, el identificador de código de 12 puede identificar un juego de carreras multijugador particular y el identificador de código de 4 puede especificar una pista de carreras, velocidad, o nivel de habilidad de jugador específicas para el juego de carreras. En una realización, a los desarrolladores de la aplicación se les proporciona la opción de especificar cualesquiera parámetros de configuración de la aplicación utilizando los valores MSI de esta manera. En una realización, en lugar de especificar un MSI directamente, los desarrolladores de la aplicación especifican un identificador de juego (para identificar un juego específico) y un identificador de cubeta (para identificar una configuración de juego específica) y estos valores se mapean a un valor MSI por parte del emisor de emparejador -1501-.

Adicionalmente, se pueden utilizar diversos valores MSI diferentes dentro de un MSI único para especificar múltiples parámetros de configuración diferentes (por ejemplo, 12:4:1 podría representar: 12 = juego de carreras; 4 = pista y 1 = nivel de habilidad). Tal como se describe en detalle a continuación, en una realización, se utiliza cada MSI por parte de un emparejador -1510- para identificar un conjunto de solicitudes de emparejamiento en las que se pueden llevar a cabo las operaciones de emparejamiento (por ejemplo, las solicitudes se agrupan en base a los MSI y los emparejamientos se llevan a cabo dentro de cada grupo de MSI). En una realización cada MSI puede ser modificado/seleccionado dinámicamente por el emisor para incluir un ID de partición que identifica diferentes particiones de máquina. Por ejemplo, si un MSI específico se sobrecarga, el emisor puede dividir el MSI entre dos o más servidores diferente y/o almacenar particiones (por ejemplo, utilizando designaciones tales como 4:3:1 y 4:3:2 donde los últimos dígitos identifican particiones 1 y 2, respectivamente). Un emparejador diferente puede entonces recuperar y procesar independientemente solicitudes de cada uno de los MSI diferentes de cada uno de los diferentes servidores.

Tal como se muestra en la figura 15, también se pueden almacenar los datos de solicitud de emparejamiento dentro de la tabla de solicitudes -1502- para cada solicitud. Los datos de la solicitud pueden incluir cualquier dato utilizable para realizar una decisión de emparejamiento y/o cualquier dato necesario para acceder a los dispositivos móviles que inician la solicitud sobre la red. Por ejemplo, en una realización los datos de la solicitud de emparejamiento para cada solicitud incluyen los datos de tipo de NAT y/o los datos de NAT trasversal/de conexión para el dispositivo móvil que inicia la solicitud. También se pueden almacenar otros tipos de datos de solicitud dentro de la tabla de solicitudes -1502- tal como una velocidad de conexión del dispositivo (100 bkps, 1 Mbps, etc.), el tipo de conexión (por ejemplo, 3G, EDGE, WiFi, etc.), la ubicación del dispositivo (por ejemplo, determinado por las técnicas de ubicación geográfica), idioma (inglés, castellano, etc.) y/o las preferencias del usuario. Los datos de solicitud se pueden determinar para cada dispositivo móvil -120-122- y se pueden transmitir al emisor de emparejamiento -1501

con cada solicitud de emparejamiento. Por ejemplo, cada dispositivo móvil puede determinar sus datos de conexión, el tipo de conexión, la ubicación del dispositivo, etc., utilizando varias técnicas, algunas de las cuales se describen en este documento (por ejemplo, comunicando con un servidor de NAT trasversal para determinar los datos del NAT trasversal/de conexión, utilizando el GPS para determinar la ubicación del dispositivo, leyendo la información HTTP para determinar el idioma, etc.).

Tal como se muestra en la figura 15, en una realización, a cada MSI activo se puede asignar una fila en la tabla de MSI -1503-. En una realización, cuando llega una nueva solicitud, además de añadir la solicitud a la tabla de solicitudes -1502-, el emisor -1501- también comprueba la tabla de MSI -1503- para determinar si un MSI ya existe para dicha solicitud (es decir, si se han recibido otras solicitudes que tienen el mismo MSI). Si no se encuentra un MSI correspondiente, entonces el emisor -1501- puede crear una nueva entrada en la tabla de MSI -1503- para la nueva solicitud. Si se encuentra un MSI correspondiente, entonces el emisor puede añadir simplemente la nueva solicitud a la tabla de solicitudes -1502- tal como se ha descrito anteriormente.

Una vez el emisor de emparejamiento -1501- actualiza la tabla de solicitudes -1502- y la tabla de MSI -1503-, un caso de un módulo de emparejamiento -1510- (en adelante simplemente referido como “emparejador 1510”) recupera los datos para llevar a cabo las operaciones de emparejamiento. Los casos de múltiples emparejadores se pueden ejecutar concurrentemente para llevar a cabo las solicitudes de emparejamiento y un emparejador -1510único puede procesar concurrentemente múltiples operaciones de emparejamiento en múltiples grupos de MSI diferentes.

En una realización, cuando el emparejador -1510- se encuentra disponible (por ejemplo, tras finalizar las operaciones de emparejamiento para un grupo de MSI o tras ser inicializado), consulta la tabla de MSI -1503- para identificar un MSI nuevo a procesar. En la figura 15, el valor “N/A” en los campos de identificador de emparejador para el MSI 3:1 indican que la responsabilidad para procesar este MSI no se ha asignado todavía a un emparejador. En una realización, cada entrada de MSI se sella con la hora y el emparejador -1510- selecciona un MSI que tiene el sello de hora más antiguo.

En una realización, cuando un emparejador -1510- asume la responsabilidad de un MSI específico, actualiza su código de identificador de emparejador en la tabla de MSI -1503- y especifica una duración de alquiler de ese MSI (por ejemplo, 5 segundos). En una realización, el emparejador -1510- actualiza continuamente el valor del alquiler (“lease”) a medida que procesa emparejamientos para ese MSI. Los valores de alquiler pueden ser utilizados para identificar los MSI que se asignaron a emparejadores -1510- fallidos. Por ejemplo, si ha caducado este valor de alquiler, ese MSI puede ser reivindicado por un nuevo emparejador independientemente del hecho de que la tabla de MSI -1503- indica que el MSI ya se ha asignado a un emparejador.

Una vez el emparejador -1510- ha asumido la responsabilidad de un MSI, puede consultar la tabla de solicitudes -1502- para leer las solicitudes asociadas con ese MSI en la memoria. El emparejador -1510- puede llevar a cabo las operaciones de emparejamiento para emparejar usuarios y dispositivos móviles según un conjunto de criterios de emparejamiento (por ejemplo, tal como se describe a continuación). El emparejador -1510- puede actualizar la tabla de solicitudes -1512- para indicar cuando se han realizado emparejamientos del dispositivo móvil. Por ejemplo, el emparejador puede eliminar los valores de MSI de la columna de MSI en la tabla de solicitudes -1512- e introduce un valor predefinido para indicar que ha finalizado el emparejamiento. Además, el emparejador -1510- puede actualizar el campo de los “datos de la solicitud” para cada participante para identificar los otros participantes con los que se ha emparejado ese participante (por ejemplo, escribiendo los datos del NAT trasversal/de conexión necesarios para comunicarse con los otros participantes).

El emparejador -1501- puede consultar periódicamente la tabla de solicitudes -1502- para identificar los emparejamientos finalizados. En respuesta a la detección de un emparejamiento completo, el emparejador -1501puede transmitir una notificación automática a los dispositivos móviles implicados en el emparejamiento (por ejemplo, utilizando las técnicas de notificación automática descritas en este documento y en las solicitudes dependientes). En una realización, la notificación automática incluye la estructura de datos de la “credencial” descritas anteriormente. Los dispositivos móviles pueden utilizar entonces cada una de sus credenciales para intercambiar los datos de conexión a través del servicio de CDX -110- tal como se ha descrito anteriormente.

Además de utilizar notificaciones automáticas, en una realización, los dispositivos móviles -120-122- pueden consultar periódicamente al emparejador -1501- para determinar si se ha realizado un emparejamiento. Las consultas periódicas son útiles en el caso en que las notificaciones automáticas no han llegado al dispositivo móvil. No obstante, debido a que se utiliza una arquitectura automática, las consultas periódicas pueden fijarse a una tasa relativamente baja, reduciendo, de esta manera, la carga del servicio de emparejador -111-.

La figura 16 muestra una realización de ejemplo de un procedimiento en el que dos dispositivos móviles, A y B, se emparejan mediante el servicio de emparejador -111-. Las figuras 17a-d muestran las actualizaciones de ejemplo

en la tabla -1502- de solicitudes y la tabla de MSI -1503- que pueden tener lugar a medida que progresa el procedimiento.

En -1601-, una solicitud de emparejamiento se recibe del dispositivo móvil A. En -1602-, la solicitud del dispositivo móvil A se introduce en la tabla de solicitudes y se introduce una nueva entrada de MSI (MSI 1:1) en la tabla de MSI (si todavía no existe), tal como se muestra en la figura 17a. En -1603-, se recibe una solicitud de emparejamiento de un dispositivo móvil B y, en -1604- la solicitud de emparejamiento del dispositivo móvil B también se introduce en la tabla de solicitudes mostrada en la figura 17b.

En -1605-, un caso de emparejamiento específico (emparejamiento número N) comprueba la tabla de MSI y detecta que el MSI 1:1 no ha sido reivindicado por otro caso de emparejamiento. De manera alternativa, el emparejador puede detectar una entrada en la tabla de MSI con un alquiler caducado, que indica que el emparejador que trabajaba anteriormente en el MSI ha fallado. En una realización, a las entradas de MSI con alquileres caducados se les da una mayor prioridad que las entradas MSI nuevas (a las que no se las han asignado un emparejador). Además, en una realización, a las entradas MSI relativamente más antiguas se les puede dar una mayor prioridad que entradas de MSI relativamente nuevas. Independientemente de cómo el emparejador selecciona el MSI, cuando lo hace, añade su identificador y fija un nuevo valor de alquiler para la entrada de MSI, tal como se muestra en la figura 17c (por ejemplo, utilizando un valor de alquiler de 5 segundos en el ejemplo mostrado). El emparejador puede consultar entonces la tabla de solicitudes y leer las entradas de la tabla de solicitudes con ese MSI en la memoria de manera que pueden ser procesados.

En -1606-, el emparejador lleva a cabo una serie de operaciones de emparejamiento para seleccionar un emparejamiento adecuado para cada una de las solicitudes. Ciertas realizaciones de las operaciones de emparejamiento se describen a continuación con respecto a la figura 18. Brevemente, en una realización, las variables que se evalúan para determinar los emparejamientos “adecuados” incluyen el tipo de NAT (por ejemplo, de cono completo, de puerto restringido, simétrico, etc.), el tipo de conexión (por ejemplo, WiFi, 3G, Edge, etc.), el idioma asociado al usuario (derivado de la cabecera de idioma de aceptación de la solicitud HTTP) y la edad de cada una de las solicitudes de emparejamiento. En general, el emparejador -1510 puede intentar emparejar los dispositivos móviles que tienen tipos de NAT compatibles (aunque el servicio de retransmisión se puede utilizar a veces como se describe a continuación), los mismos tipos de conexión, y los mismos idiomas. En una realización, el emparejador -1510- puede ser más liberal con los requerimientos de emparejamiento en base a la edad de las solicitudes de emparejamiento (es decir, cuanto más antigua es la solicitud, más liberalmente se aplicarán las restricciones del emparejamiento).

Haciendo referencia a la figura 16, en -1607-, siguiendo a la decisión de emparejamiento, el emparejador -1510puede actualizar la tabla de solicitudes para indicar que ha finalizado el emparejamiento, tal como se indica en la figura 17. Como parte de la actualización, el emparejador puede actualizar también los datos de la solicitud para los dispositivos móviles A y B. Por ejemplo, en una realización, el emparejador -1510- escribe los datos del NAT trasversal/de conexión del dispositivo móvil A en la columna de la solicitud para el dispositivo móvil B.

En -1608-, el emisor -1501- puede leer a través de la tabla de solicitudes para identificar las entradas de las solicitudes que se han emparejado. En una realización, cuando detecta que los dispositivos móviles A y B han sido emparejados, lee los datos de actualización (actualizados por el emparejador tal como se ha descrito anteriormente) y genera una notificación para los dispositivos móviles A y B. En una realización, la notificación es la estructura de datos de una “credencial” descrita anteriormente que se encripta e incluye los datos de NAT trasversal/de conexión para cada dispositivo móvil. Tal como se ha descrito anteriormente, en una realización, el servicio de notificaciones automáticas -1050- se utiliza para transmitir las notificaciones a los dispositivos móviles A y B. Además, los dispositivos móviles A y B pueden consultar al emisor -1501- para determinar si se ha realizado un emparejamiento. En esta realización, la técnica de consulta puede ser realizada a una tasa relativamente menor para identificar los emparejamientos que, por alguna razón, no fueron transmitidos a uno de los dispositivos móviles. Utilizar las notificaciones automáticas gestiona la carga de solicitud de consulta reduce la carga del servicio emparejador -111-, que de otra manera se cargaría con las solicitudes de consulta de los dispositivos móviles.

Si las solicitudes de emparejamiento adicionales están pendientes para el mismo MSI, determinado en -1608-, el emparejador puede continuar emparejando dispositivos móviles y usuarios dentro del MSI. En -1610-, el emparejador puede resetear el valor de alquiler dentro de la tabla de MSI -1503-. En -1611-, los emparejamientos adicionales se llevan a cabo y se actualiza la tabla de solicitudes (tal como se ha descrito anteriormente). En -1612-, los emparejamientos adicionales se leen de la tabla de solicitudes y se actualizan los dispositivos móviles adicionales (tal como se ha descrito anteriormente). Si no hay solicitudes de emparejamiento adicionales pendientes para el MSI entonces, en -1609-, se elimina la entrada de MSI de la tabla de MSI (por ejemplo, a través de una instrucción de borrado bien del emisor y/o del emparejador).

La figura 18 muestra una realización de un procedimiento para llevar a cabo los emparejamientos entre los

dispositivos móviles y usuarios (operación -1606- en la figura 16). En -1801-, todas las solicitudes de MSI (por ejemplo, para una combinación cubeta/aplicación específica) se disponen en puntos. En -1802-, se evalúa el ajuste (“fit”) de emparejamiento entre cada punto y, en -1803-, los puntos se clasifican mediante un ajuste descendente. El “ajuste” se evalúa en base a una serie de variables diferentes que incluye, pero no está limitado al tipo de NAT (por ejemplo, cono completo, de puerto restringido, simétrico, etc.), el tipo de conexión (por ejemplo, WiFi,3G, Edge, etc.), el idioma asociado al usuario (derivado de la cabecera de idioma de aceptación de la solicitud HTTP) y la edad de cada una de las solicitudes de emparejamiento. Otras variables que se pueden tener en cuenta en la decisión del emparejamiento incluyen la ubicación de cada uno de los dispositivos móviles (por ejemplo, con un intento de emparejar usuarios en una ubicación particular); los requisitos de jugador mínimos y/o máximos (por ejemplo, especificado por el usuario y/o la aplicación); tanto si uno o más usuarios incluidos en el MSI son “amigos” o han entrado en una conexión P2P anteriormente (por ejemplo, con una preferencia para emparejar “amigos” o conocidos anteriores); y la experiencia del usuario con la aplicación (por ejemplo, para un juego multijugador, los rangos de la tabla de clasificados de cada uno de los usuarios puede tenerse en cuenta, con una preferencia para emparejar a los usuarios con experiencia similar).

Tal como se indica en la Tabla A mostrada a continuación, en una realización, la evaluación de “adecuación” es un valor número entre 0.0 y 1.0. Utilizando un valor de punto flotante permite la normalización de la adecuación para cada criterio. Para evitar valores enteros no normalizados, aritméticos de punto flotante se puede utilizar con una evaluación adecuada de manera que se pueden comparar los valores de adecuación.

En una realización, todos los criterios tienen una adecuación binaria en el que son bien compatibles (que tienen un valor normalizado de 1,0) o no compatibles (que tiene un valor normalizado menor que 1,0). Estos pueden ser los criterios requeridos en el que el ajuste puede cambiar con la edad (tal como se describe a continuación). Si se añade la ubicación como una variable, entonces el mejor ajuste puede ser con el jugador más cercano que reúne los criterios requeridos.

Adecuación de emparejamiento - Tabla A

Factor

Peso Normalizado

Compatibilidad de NAT

2,0 0,4

Tipo de conexión

2,0 0,4

Idioma

1,0 0,2

TOTAL

5,0 1,0

En una realización, el ajuste es igual a la suma de (peso normalizado * valor de factor de edad) para cada uno de los criterios anteriores. El valor del factor de edad puede iniciarse con un valor 1 y aumenta una vez ha transcurrido un periodo de tiempo predeterminado. Entonces puede continuar aumentando a medida que pasa el tiempo (por ejemplo, aumentando periódicamente una cantidad especificada). En una realización, en lugar de utilizar el valor de factor de edad descrito anteriormente, se pueden establecer umbrales de edad tal como se describe a continuación. Los valores ponderados/normalizados de ciertas variables tal como el tipo de conexión y el idioma pueden aplicarse sobre ciertos umbrales de edad (incluso si no concuerdan).

En una realización, el “ajuste” entre un par de solicitudes, A y B, es el valor medio del ajuste de A con B y B con A. Además, el ajuste de A con B para cada factor se puede ajustar en base a la edad de A (y viceversa). En una realización, se puede requerir un ajuste de 1.0 para un emparejamiento compatible. Esto significa que A y B únicamente emparejarán si concuerdan la compatibilidad de NAT, el tipo de conexión y el idioma (dando como resultado en un valor normalizado de 1.0) o si A y/o B han envejecido de manera que algunas de las variables anteriores (por ejemplo, el tipo de conexión y el idioma) se ignoran de manera efectiva (bien utilizando el valor del factor de edad anterior o los umbrales mostrados a continuación).

Edades - Tabla B

Edad

Umbral 1 Umbral 2 Umbral 3 Umbral 4 Umbral 5

Mayor que

0 segundos 1 segundo 5 segundos 10 segundos 30 segundos

Se pueden establecer los umbrales de edad tal como se exponen en la Tabla B anterior. A medida que pasa cada tiempo (es decir, a medida que el tiempo de la solicitud es mayor que el umbral especificado), el valor del factor de tiempo puede aumentarse a valores sucesivamente mayores (por ejemplo, 1,5, 2,0, etc.). De manera alternativa, o además de esto, a medida que pasan los diferentes umbrales de tiempo, se pueden añadir los valores ponderados para ciertas variables a la decisión de emparejamiento (por ejemplo, tal como el tipo de conexión y el idioma tal como se describe más adelante).

En una realización, los límites de tiempo de la solicitud especificados en la tabla B se ajustan según la tasa del flujo de emparejamiento para un MSI dado. En una realización, la tasa de flujo se especifica como un número de emparejamientos que se están llevando a cabo por unidad de tiempo específica (por ejemplo, cada 10 segundos,

cada minuto, etc.). De esta manera, la tasa de flujo proporciona una indicación de lo ocupado que está un MSI específico. En una realización, cuanto más ocupado esté el conjunto, más bajo se puede fijar cada uno de los umbrales anteriores de la Tabla B para aumentar la probabilidad de un emparejamiento con éxito y reducir la carga del emparejador. Además, la carga para un conjunto de MSI dado se puede proporcionar a un usuario final (por ejemplo, en la forma de un tiempo estimado para el valor de emparejamiento), de manera que el usuario final puede elegir si intentar entrar en un juego multijugador que es especialmente concurrido. El valor de carga se puede proporcionar al usuario en la forma de una notificación automática.

Haciendo referencia ahora a cada una de las variables de la Tabla A, en una realización, la compatibilidad del NAT se determina a partir del cuadro de compatibilidad de NAT -1400- mostrado en la figura 14. Si se determina que dos NAT son compatibles en base a este cuadro, entonces se puede aplicar la ponderación de la compatibilidad de NAT.

Tipo de conexión - Tabla 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

El tipo de conexión se puede evaluar utilizando un cuadro tal como el que se muestra anteriormente en la Tabla C. En este ejemplo, si el tipo de conexión de los dispositivos A y B es el mismo (tal como se indica mediante 1,0 en las celdas en el que se reúnen los mismos tipos de conexión), entonces el valor ponderado de tipo conexión de la Tabla A se puede incluir en la determinación de la adecuación. Tal como se ha mencionado anteriormente, el tiempo de cada una de las solicitudes se puede utilizar para afectar la determinación del tipo de conexión. Por ejemplo, en una realización, el valor de ajuste para el tipo de conexión se selecciona utilizando la matriz de la Tabla C para los tiempos en el umbral 1, 2 y 3. Para los tiempos del umbral 4 o superiores, el tipo de conexión puede fijarse a 1,0 (incluso para tipos de conexión sin concordar) y se puede aplicar el correspondiente valor ponderado del tipo de conexión. Mientras se utiliza el “tipo” de conexión en algunas realizaciones, se puede determinar la velocidad de la conexión y utilizarla con el tipo de conexión o en lugar del mismo. Por ejemplo, las velocidades de conexión dentro de ciertos rangos específicos se puede considerar “compatible” (por ejemplo, 0-100 kbps; 100-500 kbps; 500-1000 kbps, 1000-5000 kbps, etc.). Cualquiera de las variables de emparejamiento tratadas en este documento también se pueden aplicar como ponderaciones al cálculo del ajuste de emparejamiento y de tiempo tal como se ha descrito anteriormente.

En una realización, se puede deducir el idioma del jugador a partir de la cabecera de aceptación de idioma de la solicitud HTTP que pueden contener uno o más idiomas con un factor de preferencia. El emisor puede extraer el idioma más preferido y pasar esta información al emparejador. En una realización, el valor ponderado del idioma de la Tabla A se fija a 1,0 si los idiomas son los mismos o a 0,0 si no lo son. No obstante, en una realización, el valor ponderado del idioma puede ser aplicado incluso si los idiomas son diferentes si el tiempo es superior al umbral especificado (por ejemplo, si el tiempo está en el umbral 2 o superior en la Tabla B).

En una realización, se puede realizar un emparejamiento entre dos usuarios con tipos de NAT incompatibles. Por ejemplo, si el emparejador está teniendo dificultades para emparejar a los usuarios para un MSI específico, tras un periodo específico de tiempo puede enrutar las conexiones a través del servicio de retransmisión -1051- utilizando las técnicas descritas anteriormente. De esta manera, el servicio de retransmisión -1051- actúa como una válvula de presión, permitiendo que los emparejamientos de tiempo tengan lugar a pesar de los tipos de NAT incompatibles. El servicio de retransmisión -1051- también se puede utilizar en respuesta a la detección de uno o más intentos de emparejamiento fallido. En esta realización, cada solicitud de emparejamiento enviada mediante un dispositivo móvil puede incluir una indicación en cuanto a si uno o más emparejamientos sin éxito se intentó anteriormente.

Se pueden evaluar diversos criterios de emparejamiento adicionales y proporcionar un valor ponderado como parte de la determinación del ajuste de emparejamiento que incluye, a modo de ejemplo y no como limitación, una indicación en cuanto a si cualquiera de los usuarios que solicitan emparejamientos son amigos. Por ejemplo, el emparejador -1510- puede intentar emparejar cualesquiera solicitudes para los usuarios que son “amigos” aplicando una ponderación de “amigos” al cálculo de ajuste de emparejamiento. De manera similar, los amigos de amigos también puede ser ponderados (por ejemplo, con dos o más grados de separación). Adicionalmente, un jugador puede valorar otros jugadores para un juego específico y el emparejador puede evaluar aquellas clasificaciones cuando se realiza un emparejamiento (con una tendencia a emparejar un usuario con esos jugadores que tienen clasificaciones relativamente más altas y no para emparejar un usuario con los jugadores que tienen unas clasificaciones bajas). Además, la latencia de una conexión de usuario se puede evaluar (por ejemplo, utilizando una simple operación de ping) y ser utilizados como parte de la decisión de emparejamiento.

Otra variable adicional utilizada para emparejar jugadores puede ser el tipo de dispositivo. Por ejemplo, el emparejador -1510- puede intentar emparejar jugadores con tipos de dispositivos similares (por ejemplo, iPads,

iPods, iTouches, iPhones, Blackberries RIM, etc.). Variables adicionales pueden incluir una clasificación de posiciones de los usuarios, la ubicación actual, la residencia actual, edad, género y colecciones de juegos similares pueden ser evaluados de manera similar para la determinación del emparejamiento (es decir, en muchos casos tiende a favorecer los emparejamientos entre esos usuarios con los criterios similares). Finalmente, los controles parentales se pueden evaluar mediante el emparejador -1510-para asegurar que los usuarios se emparejen únicamente con los MSI adecuados y con otros usuarios de la misma edad.

El servicio de emparejador -111- puede recuperar cualquiera de las variables anteriores a partir de una o más bases de datos gestionados dentro de los servicios de datos -100- (véase, por ejemplo, la base de datos -1920- descrita anteriormente con respecto a la figura 19). Por ejemplo, los datos de un usuario amigo se pueden acceder desde una base de datos de servicio de amigos y se puede acceder a otra información tal como la edad, sexo, colección de juegos, etc. del usuario desde una o más bases de datos adicionales (por ejemplo, un perfil de usuario, una base de datos de juegos, una base de datos de tablas de clasificaciones, etc.). En otra realización, todos los servicios descritos en este documento se proporcionan con acceso a la misma base de datos central ( o grupos de base de datos) para almacenar todos los diversos tipos de diferentes de los datos de usuario/dispositivo utilizado para realizar las decisiones de emparejamiento.

Aunque se han proporcionando diversos ejemplos específicos anteriormente, se apreciará que los principios subyacentes de la invención no están limitados a cualquier conjunto de variables para determinar un nivel de adecuación para un emparejamiento. En una realización, los programadores de la aplicación que diseñan aplicaciones para ejecutarse en el sistema y el procedimiento descrito en este documento pueden especificar su propio conjunto de criterios para emparejar y/o para agrupar las solicitudes utilizando diferentes criterios de MSI.

Haciendo referencia al procedimiento de la figura 18, una vez se ha determinado el “ajuste” de emparejamiento entre cada punto, en -1803-, los puntos se clasifican mediante un ajuste descendente (por ejemplo, con los puntos que tiene el mayor ajuste en la parte superior de la lista). En -1804-, los “conjuntos de emparejamiento” se preseleccionan con esos puntos que tienen los valores de ajuste más altos superiores al umbral especificado. Tal como se ha descrito anteriormente, el valor “umbral” puede fijarse al valor normalizado de 1,0 mostrado anteriormente en la Tabla A. En -1805-, los posibles nuevos socios se añaden al conjunto de emparejamientos que tienen valores de ajuste con uno o todos los miembros actuales en el ajuste emparejamiento superior a un umbral especifico. Por ejemplo, si un conjunto de emparejamiento ha preseleccionado inicialmente con A y B, entonces C puede añadirse al conjunto de emparejamientos si el valor de ajuste de A-C y/o B-C es superior al umbral especificado. En una realización, si solo un único ajuste de emparejamiento es superior a un umbral para una posible parte, entonces se puede añadir esa parte al conjunto de emparejamiento (es decir, debido a que, si es necesario, esa parte será capaz de comunicarse con todos las partes a través de una parte con la que tiene un ajuste de emparejamiento adecuado). Una vez se han añadido una o más partes nuevas al conjunto de emparejamientos, si se han reunido los requerimientos de tamaño para el emparejamiento, determinado en -1806-, entonces los resultados del emparejamiento se almacenan y se informan en -1807- (por ejemplo, actualizando la tabla de solicitudes -1502- y transmitiendo las notificaciones tal como se ha descrito anteriormente). En una realización, una única solicitud de emparejamiento puede representar múltiples usuarios (por ejemplo, cuando una solicitud de emparejamiento sigue una secuencia de invitaciones tal como se describe a continuación). En este caso, se evalúan los requerimientos de tamaño en base al número de usuarios representados por cada solicitud de emparejamiento. Si no se reúnen los requerimientos de tamaño, entonces el proceso vuelve a -1805- y se añade una nueva parte al conjunto de emparejamientos (es decir, una parte que tiene un ajuste de emparejamiento con uno o más de los miembros actuales del conjunto superior a un umbral especificado).

En -1808-, se eliminan las solicitudes de emparejamiento del conjunto actual de solicitudes que se están procesando por parte del emparejador -1510-. En -1809- el siguiente conjunto de emparejamiento preseleccionado es seleccionado y el proceso vuelve a -1804- para un emparejamiento adicional. Aunque se muestra en la figura 18 como un proceso secuencial, se debe observar que los conjuntos de emparejamiento preseleccionados de manera múltiple se pueden procesar de manera concurrente mientras aún se cumple con los principios subyacentes de la invención.

Aunque se ha descrito anteriormente como servicios separados, el servicio de emparejador -111- y el servicio de invitaciones -112- pueden operar conjuntamente para conectar usuarios P2P. Por ejemplo, en una realización, un primer usuario puede invitar uno o más amigos a una sesión en línea y solicitar un emparejamiento con uno o más usuarios adicionales (por ejemplo, invitar al amigo “Bob” y emparejar 3 jugadores adicionales para un jugador de vídeo multijugador). En tal caso, el servicio de invitaciones -112- puede procesar inicialmente la primera solicitud de invitación del usuario para conectar al primer usuario y el primer amigo o primeros amigos del usuario. Los resultados de la solicitud de invitaciones (por ejemplo, una conexión P2P exitosa) puede entonces ser informada al dispositivo móvil del usuario. El servicio de emparejador -111- puede recibir entonces una solicitud de emparejamiento del dispositivo móvil del primer usuario (o, en una realización, directamente del servicio de invitaciones o de los amigos del primer usuario) que solicitan jugadores adicionales. En respuesta, el servicio de

emparejador -111- puede emparejar el primer usuario con una o más solicitudes de emparejamiento adicionales que tienen el mismo MSI que la solicitud del primer usuario (tal como se ha descrito anteriormente). La solicitud de emparejamiento puede incluir únicamente los criterios de emparejamiento del primer usuario o puede incluir los criterios de emparejamiento del primer usuario y de los amigos del primer usuario (por ejemplo, tipo de NAT, tipo de conexión, idioma, ubicación, etc.). En una realización, si uno o más amigos del primer usuario no pueden establecer una conexión P2P directa con otro usuario emparejado, la conexión del usuario emparejado con los amigos del primer usuario se pueden establecer a través del dispositivo de procesamiento de datos del primer usuario (por ejemplo, utilizando el dispositivo móvil del primer usuario como una proxy para la conexión) y/o el servicio de retransmisión se puede utilizar para conectar a los usuarios (tal como se ha descrito anteriormente).

En una realización, el primer usuario puede ser emparejado inicialmente con uno o más usuarios mediante el servicio de emparejamiento (tal como se ha descrito anteriormente) y entonces el primer usuario puede invitar a uno

o más amigos a unirse a la sesión en línea con el primer usuarios y los usuarios emparejados. En esta realización, tanto la información del usuario como la información de los usuarios emparejados (por ejemplo, los datos NAT/de conexión, los identificadores de usuario, tokens automáticos, etc.) se pueden intercambiar con los usuarios invitados a través del servicio de invitaciones (tal como se ha descrito anteriormente). Los principios subyacentes de la invención permanecen los mismos independientemente de si el emparejamiento tiene lugar primero, seguido por la invitación o si la invitación tiene lugar primero, seguida por el emparejamiento.

ESTRUCTURA DE LA APLICACIÓN CON UNA INTERFAZ DE PROGRAMACIÓN DE LA APLICACIÓN PARA APLICACIONES DE COLABORACIÓN EN LÍNEA

Tal como se muestra en la figura 19, se implementa una realización de la invención dentro del contexto de un dispositivo móvil -120- que tiene una estructura de software -1912- predefinida con una interfaz de programación de la aplicación (“API”) -1910- para ser una interfaz con una o más aplicaciones -1911- y una API del lado del servicio -1910- para comunicarse con una serie de servicios de red -1901-1903-. Tal como se muestra en la figura 19, los servicios de red -1901-1903- se pueden diseñar y/o gestionar mediante los mismos servicios de datos en línea -100(aunque no se requiere dicha configuración). Las aplicaciones -1911- tal como aplicaciones de juegos P2P y otros tipos de aplicaciones de colaboración en línea se pueden diseñar para acceder los servicios de red -1901-1903- a través de la API -1910- realizando llamadas a la API -1910-. El diseño de las aplicaciones -1911- se puede facilitar utilizando un kit de desarrollo de software (“SDK”) proporcionado por el desarrollador de la estructura -1912- y los servicios de red -1901-1903-. Una implementación más específica de la estructura -1912- y las API -1910-, -1913- se describe a continuación con respecto a la figura 20.

Tal como se muestra, cada uno de los servicios se puede proporcionar con acceso a una base de datos -1920- para almacenar los datos utilizados por otros servicios. Un ejemplo particular es la base de datos -1512- utilizada por el servicio de emparejamiento -111- (descrito anteriormente). Otros ejemplos pueden incluir una base de datos para la tabla de clasificaciones para almacenar los datos de la tabla de clasificaciones, una base de datos de servicio de amigos para almacenar los registros de estado de amigos, una base de datos de perfiles para almacenar los datos del perfil del usuario y una base de datos de juegos para almacenar los datos relacionados con los juegos en línea. Se puede utilizar cualquier tipo de base de datos (por ejemplo, MySQL, Microsoft SQL, etc.) pero en una realización específica, se puede utilizar una base de datos clave/valor tal como una base de datos Berkley y/o una base de datos MZBasic. Las bases de datos se pueden extender a través de un gran número de dispositivos de almacenamiento (por ejemplo, discos duros) en una red de área de almacenamiento (SAN) u otra configuración de almacenamiento.

En consecuencia, cuando un servicio particular procesa y/o almacena los datos tal como se ha descrito anteriormente, los datos pueden ser almacenados en la base de datos -1920-. No obstante, algunos servicios pueden no utilizar una base de datos. Por ejemplo, tal como se ha descrito anteriormente, el servicio de invitaciones -112- puede ser implementado como un servicio sin estados y, por tanto, puede no requerir almacenar datos dentro de una base de datos -1920- (aunque dicha implementación aún es posible según los principios subyacentes de la invención).

La API -1913- puede estar diseñada para comunicarse e intercambiar la información con el servicio de red -1901-1903- utilizando cualquier pila de protocolos de red que incluye, por ejemplo, el TCP/IP o el UDP/IP en la capa de red y el HTTPS en la capa de aplicación. Un protocolo basado en llamadas a procedimientos remotos (RPC) sobre HTTP o HTTPS, tal como una SOAP, se puede utilizar y/o se puede utilizar un protocolo de transferencia de estado representacional (REST). Además, los servicios se pueden implementar sobre cualquier plataforma informática que incluye, a modo de ejemplo, Xserve o servidores similares que se ejecuten en Unix, Linux o una plataforma de software Apache. En una realización particular, la plataforma incluye objetos Web implementados en Linux. Los ejemplos anteriores se proporcionan únicamente para propósito de ejemplo. Los principios subyacentes de la invención no están limitados a ningún mecanismo particular para enlazar aplicaciones a los servicios o cualquier conjunto particular de los protocolos de red.

La figura 20 muestra una arquitectura de software más detallada que incluye las interfaces de programación de aplicaciones (API) -2001a-b- que pueden ser implementadas sobre el dispositivo inalámbrico -120- en una realización de la invención. Aunque esta realización se describe dentro del contexto de una estructura -2000- de juego multijugador, los principios subyacentes de la invención no están limitados a una implementación del juego. Por ejemplo, la arquitectura de software mostrada en la figura 20 puede ser utilizada para soportar diversas aplicaciones de colaboración que no son juegos (por ejemplo, una conversación de colaboración, audio/vídeo multipartidario de colaboración, etc.).

En la arquitectura mostrada en la figura 20, una estructura de juego -2000- está provista para soportar las diversas características multipartidarias y las características P2P descritas en este documento. En una realización, la estructura de juego -2000- está diseñada para ejecutarse en el sistema operativo -2005- del dispositivo móvil. Por ejemplo, si el dispositivo móvil -120- es un iPhone, iPad o iPod Touch, el sistema operativo -2005- puede ser el sistema operativo del iPhone, un sistema operativo móvil diseñado por el solicitante de la presente solicitud.

La estructura de juegos -2000- puede incluir una interfaz de programación de aplicaciones pública (API) -2001b- y una API privada o “segura” -2001a-. En una realización, una aplicación central de juegos -2031- diseñada para proporcionar diversas características relacionadas con los juegos descritas en este documento puede realizar llamadas tanto a la API pública -2001b- como a la API privada -2001a-, mientras que otras aplicaciones -2030- (por ejemplo, las aplicaciones diseñadas por terceras partes) se proporcionan con acceso únicamente a la API pública -2001b-. Por ejemplo, el diseñador del dispositivo móvil -120- puede desear mantener ciertas funciones API que implican información potencialmente confidencial fuera de la API pública -2001b- para evitar que terceros desarrolladores hagan mal uso de ella (por ejemplo, solicitudes de amigos, listas de amigos, etc.). No obstante, tanto la API segura -2001a- como la API pública -2001b- pueden unirse en una única API accesible por todas las aplicaciones en los dispositivos móviles (es decir, la separación de la API en componentes públicos y privados independientes no se requiere para cumplir los principios subyacentes de la invención). La designación “API 2001” a veces se utiliza más adelante para referirse a las operaciones que se pueden encontrar en la API pública -2001b- y/o en la API privada -2001a-.

Una realización de la aplicación del centro de juegos -2031- se describe en la solicitud pendiente de resolución titulada Sistemas y procedimientos para proporcionar un centro de juegos, número de expediente del agente 4860.P9127USP1, número de serie 61/321.861, presentada el 7 de abril de 2010, que tiene los inventores Marcel Van Os y Mike Lampell (en adelante “solicitud de patente del centro de juegos”), que está asignada al solicitante de la presente invención y que se incorpora en este documento por referencia. Brevemente, la aplicación de centro de juegos -2031- incluye una interfaz de usuario gráfica del centro de juegos (GUI) para navegar a través de juegos multijugador, adquirir nuevos juegos, recuperar información relacionada con los juegos (por ejemplo, información del tablón de clasificaciones, logros, información de amigos, etc.), contactar con amigos para jugar juegos, solicitar partidas de juegos con otros usuarios e invitar a usuarios específicos. Otras diversas funciones relacionadas con la aplicación del centro de juegos -2031- se describen en la solicitud de patente del centro de juegos referida anteriormente. Algunas funciones del centro de juegos se pueden proporcionar mediante la estructura de juegos -2000- y pueden hacerse accesibles a otras aplicaciones -2030- mediante la API pública -2001b-.

En una realización, la API -2001- expuesta por la estructura de juegos -2000- simplifica el proceso de diseño de juegos de colaboración, multijugador, para el dispositivo móvil -120-. En particular, en una realización, la API -2001permite que los desarrolladores realicen una simple llamada a la API para invocar el relativamente complejo proceso de conectar usuarios para una sesión de juegos P2P multijugador. Por ejemplo, una simple llamada a la API tal como Invitar (identificador del jugador B, identificador de cubeta), puede ser invocado desde la API -2001- para iniciar la secuencia de invitaciones detallada descrita anteriormente. De manera similar, una llamada a la API tal como Emparejar (identificador de jugador A, identificador de cubeta) puede ser invocada desde la API -2001- para iniciar la secuencia de emparejamiento detallada descrita anteriormente. Las funciones Invitar y Emparejar a menudo referidas generalmente en este documento como “funciones de conexión P2P”. En una realización, la estructura de juegos -2000- incluye el código de programa requerido para gestionar las operaciones de invitación y de emparejamiento en respuesta a estas llamadas a la API (tal como se describe en mayor detalle más adelante). Se debe observar que las funciones de la API actuales pueden tener formatos de datos algo diferentes que los expuestos anteriormente, (aunque pueden resultar en operaciones similares llevadas a cabo por la estructura de juegos -2000-). Los principios subyacentes de la invención no están limitados a ningún formato particular para especificar las funciones API.

También se pueden gestionar otros diversos tipos de transacciones relacionados con los juegos mediante la estructura de juegos -2000- en nombre del centro de juegos -2031- y otras aplicaciones -2030-. Parte de esta información se describe en la solicitud de patente del centro de juegos. A modo de ejemplo y no como limitación, esta información puede incluir información del “tabla de clasificaciones” relacionada con aquellos usuarios que han conseguido las puntuaciones más altas para cada juego e información de “logros” que identifica a los usuarios que

han completado ciertos logros específicos del juego. Cada desarrollador de la aplicación puede especificar su propio conjunto de “logros” para cada aplicación del juego -2030- (por ejemplo, los niveles 1-3 completados, nivel 1 completado en menos de 5 minutos, más de 50 muertes por nivel, 20 banderas derribadas, etc.).

La estructura de juegos -2000- también puede incluir el código de programa para gestionar los datos de los amigos del usuario y para integrar los datos de los amigos dentro del contexto del centro de juegos -2031- y otras aplicaciones de juegos -2030-. Por ejemplo, cuando el usuario selecciona un enlace a un juego particular dentro del centro de juegos -2031-, se puede mostrar la información relacionada con cada uno de los amigos del usuario para ese juego (por ejemplo, la clasificación de los amigos en la tabla de clasificaciones, los logros de los amigos, los resultados cuando el usuario que jugó al juego con cada uno de sus amigos, etc.). En una realización, la API -2001de la estructura de juegos -2000- incluye funciones para acceder a los datos de los amigos gestionados por un servicio de amigos tal como el descrito en la solicitud pendiente de resolución titulada Aparato y procedimiento para gestionar datos en un servicio de redes sociales, número de expediente de abogado 4860.P9240Z, número de serie 61/321.848, presentado el 7 de abril de 2010, que tiene los inventores Amol Pattekar, Jeremy Wemer, Partick Gates y Andrew H. Vyrros (en adelante “solicitud de servicio de amigos”), que está asignado al solicitante de la presente solicitud y que se incorpora en este documento por referencia.

Tal como se muestra en la figura 20, en una realización, un “daemon” de juegos -2020- puede interconectarse con la estructura de juegos -2000- a un primer conjunto de servicios -2050- y un componente de servicios de juegos -2010- puede interconectarse con la estructura de juegos -2000- a un segundo conjunto de servicios -2051-. A modo de ejemplo, el primer conjunto de servicios -2050- puede incluir el servicio de invitaciones -112-, un servicio de emparejamiento -111- y un servicio de retransmisión -1051- descrito anteriormente y el servicio de amigos descrito en la solicitud de servicio de amigos referida anteriormente. Otros servicios a los que se puede acceder a través del “daemon” de juegos -2020- incluyen un servicio de tabla de clasificaciones (que proporciona datos de la tabla de clasificación); un servicio de juegos (que proporciona estadísticas y otros datos relacionados con cada uno de los juegos y la capacidad de adquirir un juego); un servicio de autenticación de usuario (para autenticar el usuario del dispositivo móvil); y/o un servicio de perfiles de usuario (para almacenar los datos de perfil tal como preferencias de usuario). El segundo conjunto de servicios -2051- accedido a través del componente de servicios de juego -2010puede incluir el servicio de intercambio de los datos de conexión (CDX) -110- y los servicios de NAT trasversal -290-291- descritos anteriormente. Aunque se muestran como componentes independientes en la figura 20 para el propósito de la ilustración, el “daemon” de juegos -2020- y el módulo de servicios de juegos -2010- puede ser en realidad los componentes de la estructura de juegos -2000-. En una realización, el “daemon” de juegos -2020- y -2010- se comunica con cada uno de los servicios de red -2050-2051- a través de una API predefinida que, en una realización, es una API privada (es decir, no pública para otros desarrolladores).

En una realización, el “daemon” de juegos -2020- puede comunicarse con el servicio de emparejamiento -111-, el servicio de invitaciones -112- y otros servicios -2050- utilizando el protocolo HTTPS mientras que el módulo de servicio de juegos -2010- puede comunicarse con el servicio de CDX -110- y los servicios de NAT trasversal -290-291- utilizando un protocolo relativamente ligero tal como conexiones UDP. No obstante, tal como se ha mencionado anteriormente, se pueden emplear otros diversos protocolos aun cumpliendo con los principios subyacentes de la invención.

Además, tal como se muestra en la figura 20, el “daemon” de juegos -2020- puede recibir notificaciones automáticas -2052- generadas por ciertos servicios -2052- (por ejemplo, el servicio de invitaciones y el servicio de emparejamiento) mientras que se pueden recibir otros tipos de notificaciones automáticas -2053- directamente por el centro de juegos (por ejemplo, notificaciones de servicio de amigos tal como solicitudes de nuevos amigos). En una realización, estas notificaciones automáticas -2053-se proporcionan directamente al centro de juegos -2031- para asegurar que los datos de usuario confidenciales no son accesibles para las aplicaciones -2030- diseñadas por otros desarrolladores de la aplicación.

Haciendo referencia a los ejemplos de invitación expuestos anteriormente en la figura 11, cuando una aplicación -2030- en un dispositivo móvil A realiza una llamada de invitación a la API -2001b- de la estructura de juegos -2000para invitar a un usuario del dispositivo móvil B (por ejemplo, Invitar (identificador del jugador B, identificador de cubeta/juego)), la estructura de juegos -2000- puede pasar la solicitud de invitación al “daemon” de juegos -2020- del dispositivo móvil A. El “daemon” de juegos -2020- puede comunicarse entonces con el servicio de invitaciones -112- para enviar la solicitud de invitación. El servicio de invitaciones -112- puede utilizar entonces el servicio de notificaciones automáticas -1050- (tal como se ha descrito anteriormente) para entregar la invitación al “daemon” de juegos -2020- del dispositivo móvil B. El “daemon” de juegos -2020- del dispositivo móvil B puede comunicarse entonces con la estructura de juegos -2000- del dispositivo móvil para determinar si el juego para el se que envió la solicitud está instalado en el dispositivo móvil B. En dicho caso, entonces la estructura de juegos -2000- puede iniciar la aplicación -2030- y/o generar una notificación visual de la invitación. Si la aplicación no está instalada, entonces la estructura de juegos -2000- puede iniciar una notificación visual de la invitación al usuario del dispositivo móvil B con una oferta para adquirir el juego (por ejemplo, a través del centro de juegos -2031- GUI). De manera

alternativa, la notificación visual puede ser generada por un “daemon” de notificaciones automáticas que se ejecuta en el dispositivo móvil -120- (no mostrado). Si el usuario del dispositivo móvil B adquiere el juego, la secuencia de invitaciones puede continuar siguiendo a la adquisición. Si el usuario del dispositivo móvil B acepta la solicitud de invitaciones, entonces la estructura de juegos -2000- del dispositivo móvil B puede pasar la solicitud de invitaciones a su “daemon” de juegos -2020- que puede responder entonces al servicio de invitaciones -112-.

Recuérdese que en la figura 11, la comprobación de compatibilidad -1106- determina que los tipos de NAT de los dispositivos móviles A y B son compatibles. De esta manera, en -1108- el “daemon” de juegos -2020- del dispositivo móvil A puede recibir la aceptación del dispositivo móvil B (por ejemplo, a través de notificaciones automáticas en el ejemplo) y, en una realización, pasa la aceptación a la estructura de juegos -2000-. En esta etapa, la estructura de juegos -2000- del dispositivo móvil A puede bien notificar a la aplicación solicitante -2030- que el dispositivo móvil B ha aceptado (a través de la API -2001-) o puede esperar para notificar a la aplicación solicitante -2030- hasta que los dispositivos han sido conectados con éxito. En cualquier caso, la estructura de juegos -2000- puede pasar una solicitud de conexión al módulo de servicios de juego -2010- que, en una realización, puede iniciar un intercambio de datos de conexión con el dispositivo móvil B. En particular, el módulo de servicios de juego puede transmitir los datos de conexión del dispositivo móvil A al dispositivo móvil B utilizando el servicio de CDX -110- (véase, por ejemplo, las transacciones -1111- y -1112- en la figura 11). Tal como se ha descrito anteriormente, esta comunicación puede ser implementada como una conexión UDP utilizando una estructura de datos de “credencial”.

Recuérdese que en la figura 12, si la comprobación de compatibilidad -1106- determina que los tipos de NAT de los dispositivos móviles A y B no son compatibles entonces el servicio de retransmisión -1051- puede utilizarse para proporcionar una conexión entre los dispositivos. En consecuencia, el “daemon” de juegos -2020- del dispositivo móvil B puede recibir una respuesta de retransmisión -1203- desde el servicio de invitaciones (mostrado en la figura 12) y el “daemon” de juegos -2020- del dispositivo móvil A puede recibir una respuesta de retransmisión -1205desde el servicio de invitaciones (a través del servicio de notificaciones automáticas -1050-). Los “daemons” de juego -2020- de los dispositivos móviles A y B pueden comunicarse con el servicio de retransmisión en -1206- y -1207- para recuperar los datos de configuración. En -1210-, el “daemon” de juegos -2020- del dispositivo móvil B recibe los datos de actualización de la retransmisión del dispositivo móvil A y, en -1213-, el “daemon” de juegos -2020- de dispositivo móvil A recibe los datos de actualización de la retransmisión del dispositivo móvil B.

El resultado final de los procesos mostrados en las figuras 11 y 12 es que los dispositivos móviles A y B han establecido una conexión entre si (bien una conexión directa, una conexión P2P o una conexión de retransmisión). En una realización, al detectar una conexión con éxito, la estructura de juegos -2000- puede notificar a la aplicación -2030- que solicitó la conexión utilizando una llamada a la API (por ejemplo, Conectado (identificador del jugador A, identificador del jugador B)). Los dispositivos móviles A y B pueden jugar entonces el juego especificado u otra aplicación de colaboración -2030- utilizando la conexión establecida.

De esta manera, en respuesta a una llamada relativamente simple de la API -2001- (por ejemplo, Invitar identificador del jugador B, identificador de cubeta/juego), una serie compleja de transacciones se puede gestionar mediante la estructura de juegos -2000- para establecer una conexión P2P o una conexión de retransmisión entre los dispositivos móviles A y B. En una realización, la estructura de juegos -2000- lleva a cabo la secuencia de las operaciones para conectar los dispositivos móviles A y B y entonces proporciona los resultados a la aplicación solicitante -2030-, dejando, de esta manera, los detalles de la llamada a la API transparente al diseñador de la aplicación. Como tal, no se requiere que el diseñador de la aplicación entienda cómo conectar los dispositivos móviles A y B en la red o para llevar a cabo varias otras funciones requeridas para permitir la comunicación entre los dispositivos, simplificando, de esta manera, el proceso de diseño de la aplicación.

De manera similar, la estructura de juegos -2000- puede establecer un emparejamiento entre el dispositivo móvil A y otros participantes que utilizan el servicio de emparejamiento -111- tal como se ha descrito anteriormente con respecto a la figura 2a-b. En este ejemplo, la aplicación -2030- puede realizar una simple llamada a la API -2001- tal como Emparejar (identificador del jugador A, identificador de la cubeta/juego). En respuesta, la estructura de juegos -2000- puede gestionar el emparejamiento y las operaciones de intercambio de los datos de conexión. Cuando las operaciones de emparejamiento y/o las conexiones P2P finalizan, la estructura de juegos -2000- envía los resultados de vuelta a la aplicación -2030-.

Por ejemplo, en la figura 2b, la estructura de juegos -2000- puede utilizar el módulo de servicios de juegos -2010puede comunicarse con el servicio de intercambio de los datos de comunicación (CDX) -110- y los servicios de NAT trasversal -290-291- y puede utilizar el “daemon” de juegos para comunicarse con el servicio de emparejamiento -111-. Una vez se ha realizado el emparejamiento, el “daemon” de juegos -2020- del dispositivo móvil A recibe la credencial A en -229- y la estructura de juegos -2000- utiliza esta información para implementar un intercambio de los datos de la conexión a través del módulo de servicios de juegos -2010-. Por ejemplo, en -232-, puede solicitar sus propios datos de conexión a través del servicio de NAT trasversal -290- y puede intercambiar entonces sus datos de conexión en -233-234- a través del servicio de CDX -110-. En -237- y -240-, el módulo de servicios de

juegos -2010- del dispositivo móvil A recibe los datos de conexión para los dispositivos móviles B y C, respectivamente. Siguiendo estos intercambios, el módulo de servicios de juegos -2010- establecen las conexiones P2P en -241- y la estructura de juegos -2000- notifica la aplicación -2030- que el proceso de conexión se finaliza utilizando una notificación de la API (por ejemplo, Emparejamiento completo (identificador del jugador B, identificador del jugador C)). La aplicación puede ejecutarse entonces utilizando la conexión P2P establecida.

En algunas realizaciones, se le puede ofrecer al usuario la opción de jugar un juego con otros amigos que están registrados actualmente como “en línea”. En este caso, la notificación de que ciertos amigos están en línea se puede proporcionar a través de las notificaciones automáticas -2052- o notificaciones automáticas -2053- (recibida directamente mediante el centro de juegos -2031-). El centro de juegos -2031- y/o las aplicaciones -2030- pueden proporcionar entonces las notificaciones al usuario y proporcionar al usuario la opción de jugar con uno o más amigos en línea seleccionados. No obstante, se debe observar, que la secuencia de invitación descrita en este documento funcionará independientemente de si se proporcionan notificaciones en línea. En una realización, el estado en línea del usuario se puede controlar mediante un servicio accesible por el “daemon” de juegos -2020- (por ejemplo, mediante el servicio de amigos mencionado anteriormente o mediante un servicio de “presencia” independiente).

Una realización de la estructura de juegos -2000- proporciona una operación de combinación de invitación/emparejamiento en la que un usuario puede invitar a uno o más amigos a jugar un juego con un grupo de participantes emparejados desconocidos. Por ejemplo, si un juego requiere 4 jugadores y un primer usuario invita a un segundo usuario a jugar el juego, entonces el servicio de invitaciones -112- puede conectar inicialmente el primer usuario y el segundo usuario y el servicio de emparejamiento -111- puede emparejar entonces el primer usuario y el segundo usuario con dos (o más) jugadores. En esta realización, la estructura de juegos -2000- puede llevar a cabo inicialmente las secuencias de invitación descritas anteriormente para conectar el primer usuario y el segundo usuario. En una realización, una vez el primer usuario y el segundo usuario se han conectado con éxito, la estructura de juegos -2000- puede implementar las secuencias de emparejamiento para identificarse y conectarse con los demás usuarios. Tal como se ha mencionado anteriormente, en una realización, los criterios de emparejamiento aplicados por el servicio de emparejamiento puede incluir tanto el primer como el segundo usuario (por ejemplo, los tipos de NAT, los tipos de conexión, idioma, etc., tanto del primer como del segundo usuario). De manera alternativa, los criterios de uno de los dos usuarios se pueden evaluar para llevar a cabo la decisión de emparejamiento.

Una vez se han conectado los usuarios, la estructura de juegos -2000- puede proporcionar los resultados de la conexión a la aplicación -2030- que solicitó la conexión a través de la API -2001-. Una vez más, en respuesta a una llamada a la API relativamente simple mediante una aplicación -2030-, la estructura de juegos -2000- entra en un conjunto de transacciones complejas para conectar cada uno de los dispositivos. Una vez los dispositivos se han conectado con éxito, la estructura de juegos -2000- envía los resultados de vuelta a la aplicación solicitante -2030-.

Tal como se muestra en la figura 20, la estructura de juegos -2000- puede incluir un búfer de comunicación -2003para almacenar temporalmente la comunicación entre el usuario y los otros participantes del juego. La comunicación puede incluir, por ejemplo, la comunicación de texto, audio y/o vídeo. La estructura de juego -2000- puede establecer el búfer -2003- en base a los requerimientos de cada aplicación -2030-. Por ejemplo, un búfer -2003relativamente grande puede requerirse para la comunicación de audio y vídeo con una conexión de red lenta. En una realización, cada aplicación -2030- puede realizar una solicitud explícita para establecer un búfer de comunicación de un cierto tamaño a través de la API -2001- (por ejemplo, utilizando una instrucción BÚFER (tamaño)). De manera alternativa, la estructura de juegos -2000- puede crear un búfer automáticamente en base a los requerimientos de comunicación de cada aplicación. Por ejemplo, la estructura de juegos -2000- puede seleccionar un tamaño de búfer particular en base a si se necesita soportar texto, audio y/o vídeo.

En una realización, el búfer de comunicación -2003- puede almacenar un flujo de comunicación temporalmente antes de que se hayan establecido las conexiones P2P entre los usuarios. Por ejemplo, una vez que el servicio de invitaciones -112- o el servicio de emparejamiento -111- haya identificado a cada uno de los usuarios pero antes de que el servicio de CDX -110- haya completado las operaciones de intercambio de los datos de conexión, se puede notificar a cada usuario de que los otros participantes del juego se encuentran en el proceso de ser conectados. En esta etapa el usuario del dispositivo móvil -120- puede transmitir flujos de comunicación de texto, audio y/o vídeo a los demás participantes. La estructura de juegos -2000- almacenará los flujos de comunicación dentro del búfer de comunicación -2003- para aquellos participantes que todavía no se han conectado. Entonces la estructura de juegos -2000- puede transmitir texto, audio y/o vídeo desde el búfer -2003- cuando finaliza la conexión de cada dispositivo.

En una realización, el “daemon” de juegos -2020- incluye una memoria caché -2021- para guardar los datos en memoria cache que permanecen en cada uno de los servicios -2050- para reducir el tráfico de la red. Por ejemplo, la lisad de los amigos del usuario, los datos de la tabla de clasificación, los datos de los logros, los datos de presencia y los datos de perfil se pueden almacenar en la memoria caché -2021- tal como se especifica mediante una política de gestión de la memoria caché. En una realización, la política de gestión de la memoria caché es impulsada por

cada servicio individual en el que se almacenan datos. En consecuencia, para n servicios diferentes, se pueden aplicar n políticas de gestión diferentes a la memoria caché -2021-. Además, debido a que la política de gestión de la memoria caché es impulsada por los servicios, se puede modificar de manera dinámica en base a una red actual y/o las condiciones de carga del servidor. Por ejemplo, durante periodos de tiempo en los que el servicio tiene una gran carga (por ejemplo, navidad, el día en que se lanza un nuevo producto, etc.), el servicio puede especificar de manera dinámica una política de gestión de la memoria caché con actualizaciones de la memoria caché relativamente poco frecuentes (por ejemplo, actualizaciones cada 12 horas). En cambio, durante periodos de tiempo en los que un servicio no tienen mucha carga, el servicio puede especificar una política de memoria caché con actualizaciones de la memoria caché más frecuentes (por ejemplo, actualizaciones cada media hora, cada hora, cada dos horas, etc.).

En una realización, se especifica la política de gestión de la memoria caché utilizando un valor de tiempo de vida (TTL) para ciertos registros de datos almacenados en la memoria caché -2021-. Cuando un registro de datos se ha almacenado en la memoria caché una vez ha transcurrido su valor de TTL, entonces esos datos se consideran “obsoletos” y se puede enviar una solicitud local para dichos datos al servicio asociado con dichos datos. En una realización, la solicitud incluye un código de identificador que identifica una versión actual de los datos. Si el código de identificación concuerda con el código de identificador del servicio, entonces los datos aún son válidos y no se necesita actualizarlos. Entonces se puede enviar una respuesta desde el servicio que indica que los datos en la memoria caché son actuales y el valor TTL para el registro de datos puede ser reiniciado.

Además de utilizar una política de gestión de la memoria caché tal como se ha descrito anteriormente, en una realización, las actualizaciones de la memoria caché para ciertos tipos de datos se pueden enviar al dispositivo móvil utilizando el servicio de notificaciones automáticas -1050-. Por ejemplo, los cambios en la lista de amigos del usuario

o del estado en línea actual de los amigos del usuario se pueden enviar de manera dinámica al dispositivo móvil del usuario -120-. La notificación automática puede ser recibida por el “daemon” de juegos -2020- que pueden actualizar entonces la memoria caché -2021- para incluir la parte relevante de los datos enviados por el servicio (es decir, puede no necesitarse una actualización de todos los datos en la memoria caché asociada con ese servicio). En cambio, algunas notificaciones automáticas pueden ordenar al “daemon” de juegos -2020- para sobreescribir todos los contenidos de la memoria caché (o al menos la parte de la memoria caché asociada al servicio que está llevando a cabo la notificación).

Esos servicios que utilizan las notificaciones para actualizar la memoria caché -2021- puede elegir valores TTL relativamente elevados (y/o puede no fijar los valores TTL) debido a que tienen la capacidad de enviar notificaciones para actualizar los datos almacenados en la memoria caché -2021-. En una realización, cada servicio especifica un conjunto de eventos que pueden iniciar una actualización de la memoria caché mediante notificación automática. Por ejemplo, los eventos de actualización de la memoria caché puede incluir un cambio de un estado en línea de amigos, una nueva solicitud de amigos, una aceptación de una solicitud de amigo, una operación para dejar de ser amigos, una indicación de que un amigo está jugando un juego particular, un logro de juego alcanzado por un amigo, una actualización de los 10 primeros clasificados de una tabla de clasificación particular o cualesquiera otros eventos considerados de suficiente importancia para garantizar una actualización de la memoria caché. Utilizando las notificaciones automáticas para actualizar la memoria caché -2021- de esta manera puede disminuir la carga de red y del servicio debido a que, con las actualizaciones mediante notificación, no se requiere realizar consultas periódicamente entre el dispositivo móvil y el servicio.

Una realización de la estructura de juegos -2000- únicamente formatea los datos presentados al usuario final en base al país y/o a la ubicación geográfica del usuario. Por ejemplo, valores tal como la fecha y hora actuales y los valores monetarios se pueden presentar de manera diferente para usuarios en países y ubicaciones diferentes. A modo de ejemplo, en los Estados Unidos el formato de la fecha puede ser [mes día, año] (por ejemplo, Abril 25, 2010) mientras que en otros países, el formato de la fecha puede ser [día mes, año] (por ejemplo, 25 Abril, 2010). De manera similar, cuando se representa el tiempo en E.E.U.U. y en algunos otros países se puede utilizar la designación AM/PM y se puede utilizar dos puntos entre las horas y minutos (por ejemplo, 3:00 PM). En cambio, muchos otros países no utilizan la designación AM/PM y/o utilizan una coma entre las horas y los minutos (por ejemplo, 15,00). Como en otro ejemplo, muchas partes del mundo utilizarían el sistema simétrico mientras que algunas partes del mundo no la utilizan (por ejemplo, E.E.U.U.). Se debe observar que estos son ejemplos simplemente ilustrativos que pueden ser utilizados por ciertas realizaciones de la invención. Los principios subyacentes de la invención no están limitados a ningún conjunto particular de formatos de datos.

En una realización, estos formatos de datos diferentes se pueden seleccionar cuando se muestra los datos de la tabla de clasificación, los datos de logros, los datos de amigos y/o cualquier otro dato procesado por la estructura de juegos -2000-. La estructura de juegos -2000- puede determinar el país y/o la ubicación geográfica del usuario de diversas maneras. Por ejemplo, en una realización, esta información es simplemente proporcionada por los datos de perfil del usuario y/o puede estar determinado en base al proveedor de servicios de teléfono móvil del usuario. La ubicación del usuario se puede determinar también utilizando, por ejemplo, el rastreo del sistema de posicionamiento

global (GPS).

Otros tipos de formateado de datos que no están relacionados con la ubicación geográfica y/o con el país también se pueden gestionar mediante la estructura de juegos -2000-. Por ejemplo, cuando se muestra los datos de la tabla de clasificación, es importante conocer si la menor puntuación debería situar al usuario en la parte superior o la parte inferior de la tabla de clasificación. Para algunos juegos (por ejemplo, golf, carreras, esquí, etc.), un número menor indica un mejor rendimiento mientras que otros juegos (por ejemplo, fútbol, béisbol, etc.), un mayor número indica un mejor rendimiento. De esta manera, en una realización, la aplicación -2030- especifica el tipo de puntuación que se utilizará a través de la API -2001- (por ejemplo, “ascendente” o “descendente”). Entonces la estructura de juegos -2000- puede utilizar el conjunto adecuado de etiquetas y formatear cómo se muestra la puntuación.

Una realización de la estructura de juegos -2000- también filtra los datos de usuario en base a la relación entre el usuario y los amigos del usuario. Por ejemplo, una realización de la invención permite una vista “detallada”, una vista de “amigos” y una vista “pública”. En una realización, la vista detallada se encuentra disponible para el usuario que es dueño de los datos (es decir, la información personal del usuario); la vista de amigos se encuentra disponible para los amigos del usuario y la vista pública se encuentra disponible para todos los usuarios.

A modo de ejemplo, la vista pública puede incluir simplemente un nombre de “alias” asociada con cada usuario, los juegos jugados por el alias y las puntuaciones asociadas y las fechas/hora en las que se jugaron los juegos. Esta información puede ser utilizada por la estructura de juegos -2000- para rellenar una tabla de clasificaciones pública que se puede mostrar entonces a través del centro de juegos -2031-.

La vista de amigos puede incluir toda la información de la vista general así como cualquier información adicional a compartir entre los amigos del usuario que incluye, por ejemplo, los juegos que posee el usuario, los juegos jugados por el usuario, los logros y puntuaciones del usuario, cuántos amigos tiene el usuario, la identificación de dichos amigos, la URL que identifica los avatares de los usuarios y/o el estado en línea del usuario, para nombrar unos pocos. En una realización, la vista de “amigos” proporciona un conjunto de informaciones por defecto a compartir con amigos pero el usuario final puede ajustar esta configuración por defecto y especificar con particularidad los tipos de información a compartir por cada amigo individual o grupos de amigos (por ejemplo, compañeros de trabajo, miembros de la familia, amigos de la universidad o del instituto, etc.).

La vista “detallada” puede incluir toda la información de las vistas “públicas” y “amigos” así como cualquier otra información gestionada por los diversos servicios -2050- en nombre del usuario final. A modo de ejemplo, esto puede incluir todos los datos de perfil del usuario, el identificador universalmente único (“UUID”) del usuario (a veces referido en adelante como el “identificador del jugador”), el nombre del jugador, los nombres del alias, el número de juegos y la identidad de los juegos, los amigos del usuario, todos los logros del usuario, etc.

En algunas circunstancias, una aplicación -2030- únicamente puede requerir una pequeña cantidad de información relacionada con cada usuario tal como el identificador de jugador de cada usuario. Por ejemplo, en una realización, cuando se solicita un emparejamiento, la estructura de juegos -2000- inicialmente puede requerir únicamente en cada identificador de jugador. A medida que se realizan emparejamientos mediante el servicio de emparejamiento (véase lo anterior), la estructura de juegos -2000- puede determinar si cualquiera de los usuarios emparejados son amigos (por ejemplo, a través de una comunicación con el servicio de amigos y/o interrogando los datos de amigos locales del usuario). Si es así, entonces la estructura de juegos -2000- puede recuperar los datos de usuario adicionales y proporcionan esos datos a cualquiera de los amigos emparejados. De esta manera, la estructura de juegos -2000- filtra la información en base a la identidad de los usuarios y la relación entre cada uno de los usuarios.

En una realización, la estructura de juegos -2000- proporciona inicialmente una vista pública entre un primer usuario y un segundo usuario si los dos usuarios no tienen una relación de amigos. No obstante, en una realización, la estructura de juegos -2000- permite al primer usuario enviar una solicitud de amigos al segundo usuario (por ejemplo, utilizando el segundo nombre del usuario). Si la solicitud del amigo es aceptada, entonces la estructura de juegos -2000- proporcionará información adicional a cada uno de los usuarios (por ejemplo, la vista de “amigos” por defecto).

REALIZACIONES DIFERENTES DE LA API

La API implementada en una realización, es una interfaz implementada mediante una componente de software (en adelante “una componente de software que implementa una API”) que permite una componente de software diferente (en adelante “componente de software que llama a una API”) para acceder y utilizar una o más funciones, procedimientos, procedimientos, estructuras de datos y/o otros servicios provistos por la componente de software que implementa una API. Por ejemplo, una API permite que un desarrollador de una componente de software que llama a una API (que puede ser un tercer desarrollador) para hacer uso de características específicas proporcionadas por una componente de software que implementa una API. Puede haber una componente de

software que llama a una API o puede haber más de una componente de software. Una API puede ser una interfaz de código fuente que un sistema informático o una biblioteca de programas proporciona a efectos de soportar solicitudes de servicios de una aplicación de software. Se puede especificar una API en términos de un lenguaje de programación que puede ser interpretativo o compilado cuando se construye una aplicación, en lugar de una descripción de bajo nivel explícita de cómo los datos se disponen en la memoria.

La API define el idioma y los parámetros que la componente de software que llama a la API utilizan cuando acceden y utilizan características específicas de la componente de software que implementa la API. Por ejemplo, una componente de software que llama a una API accede a las características específicas de la componente de software que implementa la API a través de una o más llamadas a la API (a veces referida como llamadas a función o a procedimiento) expuestas por las API. La componente de software que implementa la API puede devolver un valor a través de la API en respuesta a una llamada de la API desde una componente de software que llama a la API. Mientras la API define la sintaxis y resultado de una llamada a la API (por ejemplo, cómo invocar la llamada a la API y qué hace la llamada a la API), la API típicamente no revela cómo la llamada a la API cumple la función especificada por la llamada a la API. Diversas llamadas de función o mensajes se transfieren a través de una o más interfaces de programación de la aplicación entre el software que llama (componente de software que llama a la API) y una componente de software que implementa la API. Las transferencias de las llamadas de función o mensajes puede incluir emitir, iniciar, invocar, llamar, recibir, devolver o responder a las llamadas de función o mensajes. Por tanto, una componente de software que llama a la API puede transferir una llamada y una componente de software que implementa una API puede transferir una llamada.

A modo de ejemplo, la componente de software que implementa la API -2010- y la componente de software que llama a la API puede ser un sistema operativo, una biblioteca, un controlador de dispositivo, una API, un programa de aplicación u otro módulo de software (se debe entender que la componente de software que implementa la API puede ser la misma o un tipo diferente de módulo de software). La componente de software que llama a la API puede ser una componente de software local (es decir, en el mismo sistema de procesamiento de datos tal como la componente de software que implementa la API) o una componente de software remota (es decir, en un sistema de procesamiento de datos diferente como la componente de software que implementa la API) que se comunica con la componente de software que implementa la API a través de la API sobre una red. Se debe entender que una componente de software que implementa la API también puede actuar como una componente de software que llama a la API (es decir, puede realizar llamadas a la API expuestas por una componente de software que implementa la API) y una componente de software que llama a la API también puede actuar como una componente de software que implementa la API mediante la implementación de una API que está expuesta a una componente de software que llama a la API diferente.

La API puede permitir múltiples componentes de software que llaman a API escritas en diferentes lenguajes de programación para comunicarse con la componente de software que implementa la API (así, la API puede incluir características para traducir las llamadas y devolverlas entre la componente de software que implementa la API y la componente de software que llama a la API); no obstante la API puede implementarse en términos de lenguaje de programación específico.

La figura 21 muestra una realización de una arquitectura de API que incluye una componente de software que implementa la API -2110- (por ejemplo, un sistema operativo, una biblioteca, un controlador del dispositivo, una API, un programa de aplicación u otro módulo de software) que implementa la API -2110-. La API -2120- especifica una o más funciones, procedimientos, clases, objetos, protocolos, estructuras de datos y /o otras características de la componente de software que implementa la API pueden ser utilizadas por la componente de software que llama a la API -2130-. La API -2120- puede especificar al menos una convención de llamada que especifica cómo una función en la componente de software que implemente la API recibe los parámetros de la componente de software que llama a la API y cómo la función devuelve un resultado a la componente de software que llama a la API. La componente de software que llama a la API -2130- (por ejemplo, un sistema operativo, una biblioteca, un controlador del dispositivo, una API, un programa de la aplicación u otro módulo de software), realiza llamadas a la API a través de la API -2120- para acceder y utilizar las características de la componente de software que implementa la API -2110que se especifican mediante la API -2120-. La componente de software que implementa la API -2110- puede devolver un valor a través de la API -2120- a la componente de software que llama a la API -2130- en respuesta a una llamada a la API.

Se apreciará que la componente de software que implementa la API -2110- puede incluir funciones adicionales, procedimientos, clases, estructuras de datos y/o otras características que no se especifican a través de la API -2120y no se encuentran disponibles para la componente de software que llama a la API -2130-. Se debe entender que la componente de software que llama a la API -2130- puede encontrarse en el mismo sistema que la componente de software que implementa la API -2110- o se puede ubicar remotamente y acceder a la componente de software que implementa la API -2110- que utiliza la API -2120- sobre una red. Mientras la figura 21 muestra una única componente de software que llama a la API -2130- que interactúa con la API -2120-, se debe entender que otras

componentes de software que llaman a la API, que pueden estar escritas en idiomas diferentes (o el mismo idioma) que la componente de software que llama a la API -2130-, puede utilizar la API -2120-.

La componente de software que implementa la API -2110-, la API -2120- y la componente de software que llama a la API -2130- puede almacenarse en un medio legible por máquina, que incluye cualquier mecanismo para almacenar información en una forma legible por una máquina (por ejemplo, un ordenador u otro sistema de procesamiento). Por ejemplo, un medio legible por máquina incluye discos magnéticos, discos ópticos, memoria de acceso aleatorio, memoria de sólo lectura, dispositivos de memoria flash, etc.

En la figura 22 (“pila de software”), una realización de ejemplo, las aplicaciones pueden realizar llamadas a los servicios -1- o -2- utilizando diversos servicios API y al sistema operativo (OS) que utiliza diversas API de SO. Los servicios -1- y -2- pueden realizar llamadas al OS utilizando diversas API de OS.

Se debe observar que el servicio -2- tiene dos API, una de las cuales (API -1- del servicio -2-) recibe llamadas y devuelve valores a la aplicación -1- y la otra (API -2- del servicio -2-) recibe llamadas desde la aplicación -2- y devuelve valores a la misma. El servicio -1- (que puede ser una biblioteca de software, por ejemplo) realiza llamadas al API -1- del OS y recibe los valores devueltos de la misma, y el servicio -2- (que puede ser una biblioteca de software, por ejemplo) realiza llamadas tanto a la API -1- del OS y a la API -2- del OS y recibe los valores devueltos de las mismas. La aplicación -2- realiza llamadas a la API -2- del OS y recibe los valores devueltos de la misma.

DISPOSITIVOS EJEMPLO DE PROCESAMIENTO DE DATOS

La figura 23 es un diagrama de bloques que muestra un sistema informática de ejemplo que se puede utilizar en algunas realizaciones de la invención. Se debe entender que mientras que la figura 23 muestra diversos componentes de un sistema informático, no se pretende representar ninguna arquitectura particular ni manera de interconectar las componentes dado que dichos detalles no están relacionados con la presente invención. Se apreciará que otros sistemas informáticos que tienen menos componentes o más componentes también se pueden utilizar en la presente invención.

Tal como se muestra en la figura 23, el sistema informático -2300-, que es una forma de un sistema de procesamiento de datos, incluye el bus o buses -2350- que se acopla con el sistema de procesamiento -2320-, la fuente de alimentación -2325-, la memoria -2330- y la memoria no volátil -2340 (por ejemplo, un disco duro, una memoria flash, una memoria de cambio de fase (PCM), etc.). El bus o buses -2350- pueden estar conectados entre sí a través de varios puentes, controladores y/o adaptadores tal como es bien conocido en la técnica. El sistema de procesamiento -2320- puede recuperar la instrucción o instrucciones de la memoria -2330- y/o la memoria no volátil -2340- y ejecutar las instrucciones para realizar operaciones tal como se ha descrito anteriormente. El bus -2350interconecta los componentes anteriores entre sí y también interconecta aquellos componentes al muelle opcional -2360-, el controlador de la pantalla y el dispositivo de pantalla -2370-, los dispositivos de entrada y salida -2380(por ejemplo, el NIC (tarjeta de interfaz de red), un control del cursor (por ejemplo, ratón, pantalla táctil, panel táctil, etc.), un teclado, etc.) y el transceptor o los transceptores inalámbricos opcionales -2390- (por ejemplo, Bluetooth, WiFi, infrarrojos, etc.).

La figura 24 es un diagrama de bloques que muestra un sistema de procesamiento de datos de ejemplo que se puede utilizar en algunas realizaciones de la invención. Por ejemplo, el sistema de procesamiento de datos -2400puede ser un ordenador portátil, un asistente personal digital (PDA), un teléfono móvil, un sistema de juegos portátil, un reproductor multimedia portátil, una tableta o un dispositivo informático portátil que puede incluir un teléfono móvil, un reproductor multimedia y/o un sistema de juegos. Como otro ejemplo, el sistema de procesamiento de datos -2400- puede ser un ordenador de red o un dispositivo de procesamiento integrado dentro de otro dispositivo.

Según una realización de la invención, la arquitectura de ejemplo del sistema de procesamiento de datos -2400- se puede utilizar para los dispositivos móviles descritos anteriormente. El sistema de procesamiento de datos -2400incluye el sistema de procesamiento -2420- que puede incluir uno o más microprocesadores y/o sistemas en un circuito integrado. El sistema de procesamiento -2420- está acoplado con una memoria -2410-, una fuente de alimentación -2425- (que incluye una o más baterías), una unidad de entrada y salida de audio -2440-, un controlador de pantalla y un dispositivo de pantalla -2460-, una unidad de entrada y salida opcional -2450-, un dispositivo o dispositivos de entrada -2470- y un transceptor o transceptores inalámbricos -2430-. Se apreciará que componentes adicionales, no mostrados en la figura 24, también pueden ser parte del sistema de procesamiento de datos -2400- en ciertas realizaciones de la invención, y en ciertas realizaciones de la invención se pueden utilizar menos componentes que los mostrados en la figura 24. Además, se apreciará que se pueden utilizar uno o más buses, no mostrados en la figura 24, para interconectar los diversos componentes tal como bien se conoce en la técnica.

La memoria -2410- puede almacenar datos y/o programas para ejecutar mediante el sistema de procesamiento de

datos -2400-. La unidad de entrada y salida de audio -2440- puede incluir un micrófono y/o un altavoz para reproducir música y/o proporcionar una funcionalidad telefónica, por ejemplo, a través del altavoz y del micrófono. El controlador de la pantalla y el dispositivo de pantalla -2460- puede incluir una interfaz gráfica de usuario (GUI). Los transceptores -2430- inalámbricos (por ejemplo, RF) (por ejemplo, un transceptor WiFi, un transceptor de infrarrojos, un transceptor de Bluetooth, un transceptor de telefonía celular inalámbrica, etc.) se puede utilizar para comunicarse con otros sistemas de procesamiento de datos. Uno o más dispositivos de entrada -2470- permiten que un usuario proporcione una entrada al sistema. Estos dispositivos de entrada pueden ser un teclado numérico, un teclado, un panel táctil, un panel multitáctil, etc. La otra unidad de entrada y salida -2450- opcional puede ser un conector para una instalación (“dock”).

Las realizaciones de la invención pueden incluir diversas etapas tal como se ha expuesto anteriormente. Las etapas se pueden representar en instrucciones ejecutables por máquina que pueden hacer que un procesador de propósito general o e propósito especial realicen ciertas etapas. De manera alternativa, estas etapas se pueden llevar a cabo mediante unos componentes de hardware específicos que contienen lógica cableada para realizar las etapas o mediante alguna combinación de componentes de ordenador programados y componentes de hardware personalizados.

Los elementos de la presente invención también pueden estar provistos tal como medios legibles por máquina, medios para almacenar el código de programa ejecutable por máquina. Los medios legibles por máquina pueden incluir disquetes, discos ópticos, CD-ROM y discos magnetoópticos, memoria ROM, memoria RAM, memorias EPROM, memorias EEPROM, tarjetas magnéticas u ópticas u otro tipo de medios legibles por máquina para almacenar el programa electrónico, pero no están limitados a éstas.

Mediante la descripción anterior, para el propósito de explicación, se expusieron numerosos detalles específicos a efectos de proporcionar un mejor entendimiento de la invención. No obstante, será evidente para un experto en la técnica que la invención se puede practicar sin algunos de estos detalles específicos. Por ejemplo, será fácilmente aparente para los expertos en la técnica que los módulos funcionales y los procedimientos descritos en este documento se pueden implementar como software, hardware o alguna combinación de los mismos. Además, aunque las realizaciones de la invención se describen en este documento dentro del contexto de un entorno informático móvil (es decir, utilizando dispositivos móviles -120-123-, -601-603-), los principios subyacentes de la invención no están limitados a una implementación informática móvil. Se puede utilizar virtualmente cualquier tipo dispositivos de procesamiento de datos de iguales o clientes en algunas realizaciones que incluyen, por ejemplo, ordenadores de sobremesa o de trabajo.

Claims (15)

1. REIVINDICACIONES

   1. Procedimiento implementado por ordenador para establecer una comunicación punto a punto “P2P”, entre dispositivos móviles que comprende:

   5 recepción (1601, 1603) de una serie de solicitudes de emparejamiento de una serie de dispositivos móviles (120-122), incluyendo cada una de las solicitudes de emparejamiento los datos de aplicación que indican una solicitud particular para la que se está solicitando un emparejamiento y que incluye, además, los datos de configuración de red para cada uno de la serie de dispositivos móviles (1502, 1503);

   10 determinación (1802) de ajustes de emparejamiento para grupos de la serie de los dispositivos móviles, los ajustes de emparejamiento basados, al menos en parte, en los datos de configuración de red de los dispositivos móviles; y

   generación (1807) de emparejamientos para dos o más dispositivos móviles en base tanto a los datos de la 15 aplicación como a los ajustes de emparejamiento determinados para los dispositivos móviles.
2. 2. Procedimiento, según la reivindicación 1, en el que la determinación del ajuste de emparejamiento incluye la determinación de la compatibilidad entre las configuraciones de red de dos o más dispositivos móviles que envían las solicitudes de emparejamiento.
3. 3. Procedimiento, según la reivindicación 2, en el que la determinación de la compatibilidad de la configuración de red comprende la determinación de la traducción de la dirección de red, “NAT”, los tipos de dispositivos utilizados por los dos o más dispositivos móviles, el procedimiento comprende además el intento de generar emparejamientos entre los dispositivos móviles que tienen los tipos de dispositivos NAT que son capaces de establecer canales de

   25 comunicación directa P2P.
4. 4. Procedimiento, según la reivindicación 1, en el que el ajuste de emparejamiento se basa en los tipos de conexión de cada uno de los dispositivos móviles, el procedimiento comprende, además, el intento de generar emparejamientos entre los dispositivos móviles que tienen tipos de conexión similares.

5. 5.

   Procedimiento, según la reivindicación 1, en el que los tipos de conexión incluyen conexiones WiFi, de tercera generación, “3G”, conexiones móviles y conexiones móviles Edge.

6. 6.

   Procedimiento, según la reivindicación 1, en el que el ajuste de emparejamiento se basa, además, en los idiomas

   35 para los que los dispositivos móviles están configurados, el procedimiento comprende, además, el intento de generar emparejamientos entre dispositivos móviles que tienen idiomas similares.
7. 7. Procedimiento, según la reivindicación 1, en el que las solicitudes de emparejamiento comprenden, además,

   variables de configuración para cada aplicación, comprendiendo el procedimiento, además, la generación de 40 emparejamientos para los dispositivos móviles en base, en parte, en las variables de configuración.
8. 8. Procedimiento, según la reivindicación 7, en el que las variables de configuración incluyen un nivel de habilidad para la aplicación y/o una subaplicación de la aplicación.

   45 9. Procedimiento, según la reivindicación 1, que comprende además:

   la determinación de la edad de cada una de las solicitudes de emparejamiento; y

   el ajuste del ajuste de emparejamiento para emparejamientos potenciales entre dos o más dispositivos móviles en 50 base a la edad de cada una de las solicitudes de emparejamiento.
9. 10. Procedimiento, según la reivindicación 9, en el que el ajuste comprende un aumento del ajuste de emparejamiento para los emparejamientos potenciales con una edad superior a un umbral especificado.

   55 11. Procedimiento, según la reivindicación 10, en el que el ajuste comprende continuar aumentando el ajuste de emparejamiento a medida que la edad aumenta por encima de uno o más umbrales adicionales.
10. 12. Procedimiento, según la reivindicación 1, en el que la generación de emparejamiento comprende además:

    60 el agrupamiento (1605) de las solicitudes de emparejamiento en grupos de emparejamientos en base a los datos de la aplicación;

    la determinación (1606) del ajuste de emparejamiento para las solicitudes de emparejamiento dentro de cada grupo

    de emparejamiento; y

    la generación de los emparejamientos para los dispositivos móviles con cada grupo de emparejamiento en base al ajuste de emparejamiento determinado. 5
11. 13. Procedimiento, según la reivindicación 1, en el que la generación de emparejamientos comprende, además:

    el agrupamiento (1605) de las solicitudes de emparejamiento en grupos de emparejamiento en base a los datos de la aplicación;

    10 la determinación (1606) del ajuste de emparejamiento para puntos de las solicitudes de emparejamiento dentro de cada conjunto de emparejamientos;

    la generación (1804) de cada uno de la serie de conjuntos de emparejamiento con puntos de solicitudes de 15 emparejamiento que tienen un ajuste de emparejamiento superior especificado;

    la adición (1805) de las solicitudes de emparejamiento para cada conjunto de emparejamiento;

    la retención de las solicitudes de emparejamiento adicionales en cada conjunto de emparejamiento si los ajustes de 20 emparejamiento combinados en el conjunto de emparejamiento se encuentran por debajo del umbral especificado.
12. 14. Procedimiento, según la reivindicación 13, que comprende, además:

    continuar añadiendo los conjuntos de emparejamiento hasta que se han reunido los requerimientos de tamaño del 25 emparejamiento.
13. 15. Procedimiento, según la reivindicación 1, en el que las solicitudes de emparejamiento incluyen los datos del NAT trasversal/de conexión asociados con cada uno de los dispositivos móviles, comprendiendo el procedimiento, además:

    30 la transmisión (1608) de una notificación a un conjunto de dispositivos móviles emparejados que ha realizado un emparejamiento, el envío de la notificación a cada dispositivo móvil que incluye los datos del NAT trasversal/de conexión necesarios para conectar a uno o más de los demás dispositivos móviles incluidos en el emparejamiento.

    35 16. Procedimiento, según la reivindicación 15, en el que los datos del NAT trasversal/de conexión incluyen un puerto y dirección IP pública para cada uno de los dispositivos móviles.
14. 17. Medio legible por máquina que tiene el código de programa almacenado en el mismo que, cuando es ejecutado

    por un dispositivo informático, hace que el dispositivo informático lleve a cabo el procedimiento como en cualquiera 40 de las reivindicaciones 1 a 16.
15. 18. Dispositivo informático que comprende una memoria para almacenar un código de programa y un procesador para procesar el código de programa para llevar a cabo un procedimiento según cualquiera de las reivindicaciones 1 a 16.