MX2012011617A - Aparato y metodo para corresponder usuarios para sesiones en linea. - Google Patents

Abstract

Se describen un aparato, un método y un medio legible por máquina para establecer canales de comunicación punto a punto ("P2P"). En particular, en una modalidad, un servicio intermediario realiza una serie de operaciones para servir solicitudes de correspondencia recibidas de un grupo de dispositivos móviles. En una modalidad, el servicio intermediario agrupa las solicitudes de correspondencia en juegos correspondientes con base en la aplicación para la cual las solicitudes se recibieron y una o más variables asociadas con la aplicación. Las solicitudes de correspondencia dentro de cada grupo de correspondencia entonces pueden corresponderse con base en variables tales como el tipo NAT, el tipo de conexión y el lenguaje asociado con cada uno de los dispositivos móviles. Otras variables tales como ubicación geográfica, nivel de experiencia y edad de las solicitudes de correspondencia también pueden usarse para generar las decisiones de correspondencia.

Description

APARATO Y MÉTODO PARA CORRESPONDER USUARIOS PARA SESIONES EN LÍNEA CAMPO DE LA INVENCIÓN Esta invención se refiere generalmente al campo de las redes de computadora. Más particularmente, la invención se refiere a un aparato y método mejorados para corresponder usuarios de los dispositivos de computación tales como dispositivos móviles para sesiones de comunicación en línea (por ejemplo, sesiones punto a punto (peer to peer).

ANTECEDENTES DE LA INVENCIÓN A. Traducción de Direcciones de Red ("NAT") Las grandes redes públicas, tales como Internet, frecuentemente tienen conexiones a redes privadas más pequeñas, tales como aquellas mantenidas por una corporación, un proveedor de servicios de Internet o incluso grupos familiares individuales. Por su propia naturaleza, las redes públicas deben tener un acuerdo común sobre la asignación de direcciones de red, es decir, direcciones públicas. Por una variedad de razones los agentes de conservación de las redes privadas a menudo deciden usar las direcciones de las redes privadas para las redes privadas que no son parte de los convenios sobre asignación. Además, para el tráfico de la red de la red privada para poder atravesar la red pública, alguna forma de traslación de las direcciones de red privadas/públicas ("NAT", por sus siglas en Inglés) se requiere.

Un dispositivo realizando las operaciones NAT altera los paquetes de datos siendo enviados fuera de la red privada para cumplir con el esquema de dirección de la red pública. Particularmente, el traductor de dirección de red remplaza la dirección privada originaria y el número de puerto 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 siendo recibidos por computadoras en la red privada para remplazar la dirección pública de destino y el número de puerto con la dirección privada correcta y el número de puerto del recipiente intentado. Como se usa en este documento, el término dirección debe construirse para incluir ambos una dirección y un número de puerto si es apropiado en el contexto como se entendería por un experto en la técnica.

NAT ha llegado a ser incrementadamente más común en la red informática moderan. Una ventaja de NAT es que retarda el agotamiento del espacio de direcciones de red pública. Por ejemplo, el direccionamiento TCP/IP, que se usa en la Internet, comprende cuatro hilos de tres dígitos cada uno, además proporcionando un espacio finito de direcciones. Adicionalmente, ciertas porciones de este espacio de direcciones están reservadas para el usuario o usuarios particulares, además agotando el número actual de direcciones disponibles. Sin embargo, sí NAT se usa, una red o subred privada puede usar un número arbitrario de direcciones, y aún presentar solamente una sola dirección pública estandarizada al mundo exterior. Esto hace al número de direcciones disponibles prácticamente ¡limitado, porque cada red privada podría usar teóricamente exactamente las mismas direcciones privadas.

Una ventaja proporcionada por NAT es la seguridad incrementada surgiendo del hecho de que aquellas en la red pública no pueden determinar la dirección de red actual (es decir, la privada) de una computadora en una red privada. Esto es porque solamente la dirección pública se proporciona en la red pública por el traductor de dirección de red. Adicionalmente, esta dirección pública puede corresponder a cualquier número de computadoras en la red privada.

Los diferentes tipos de NAT emplean diferentes niveles de seguridad. Por ejemplo, con un "NAT de cono completo", una vez que una dirección interna (iAdd:¡Port) se mapea a una dirección externa (eAdd:ePort), cualquier huésped externo puede enviar paquetes a iAddr iPort mediante enviar los paquetes a eAddrePort. Con un "NAT de cono restringido", un host externo con una dirección hAddr puede enviar paquetes a iAddriPort mediante enviar paquetes a eAddr.ePort solamente si ÍAddr:iPort ha enviado previamente un paquete a hAddr. El puerto del host externo es irrelevante. Con un "NAT de Cono de Puerto Restringido", un host externo teniendo una dirección/puerto hAddr:hPort puede enviar paquetes a iAddr:Port solamente si AddrPort envía previamente un paquete a hAddnhPort. Finalmente, con un NAT Simétrico, cada solicitud del mismo Addr:Port a una dirección IP de destino específico y puerto se mapea a un eAddnPort único. Si el mismo ost interno envía un paquete a un destino diferente, una dirección externa diferente y mapeo del puerto se usa. Solamente un host externo que recibe un paquete de un host interno puede enviar un paquete de nuevo al host interno.

B. Temas de NAT con Redes Punto a Punto (Peer to Peer) La computación Punto a Punto ("P2P") se refiere a una arquitectura de red distribuida comprendida de nodos de computación que hacen una porción de sus fuentes directamente disponible para otros participantes de la red. Los puntos en una red P2P establecen canales de comunicación directa unos con otros y actúan como ambos clientes y servidores, en contraste al modelo de servidor-cliente tradicional en el cual los servidores suministran las fuentes y los clientes consumen los recursos.

Las operaciones NAT anteriormente descritas poseen problemas numerosos para las conexiones P2P. Por ejemplo, estableciendo una conexión directa entre dos puntos llega a ser incrementadamente difícil si uno o ambos de los puntos se localiza detrás de uno o más de los tipos de- NAT anteriormente descritos. Este problema es exacerbado por el hecho de que los dispositivos móviles tales como Apple iPod Touch®, Apple iPhone®, Apple iPad® y varios otros dispositivos (por ejemplo, dispositivos RIM de Blackberry®, dispositivos Palm Pre®, etc.) se mueven frecuentemente entre las redes qué tienen diferentes implementaciones NAT. Por ejemplo, el Apple iPhoneTM es capaz de comunicarse en una red Wi-Fi (por ejemplo redes 802.1 1 b, g, n); redes 3G (por ejemplo, redes de Sistema de Telecomunicaciones Móviles Universales ("UMTS", por sus siglas en inglés), redes de Acceso Ascendente de Paquetes a Alta Velocidad ("HSUPA", por sus siglas en Inglés), etc. y la redes Bluetooth (conocidas como redes de área personal ("PANs" por sus siglas en Inglés)). Los dispositivos móviles futuros serán capaces de comunicarse sobre canales de comunicación adicionales tales como WiMAX, Telecomunicación Móvil Internacional Avanzada ("IMT" por sus siglas en Inglés) y Evolución a Largo Plazo Avanzada ("LTE" por sus siglas en Inglés) por nombrar a algunas.

SUMARIO DE LA INVENCIÓN Se describen un aparato, método y medio legible por máquina para establecer canales de comunicación punto a punto ("P2P"). En particular, en una modalidad, un servicio intermediario realiza una serie de operaciones para servir las solicitudes de correspondencia recibidas de un grupo de dispositivos móviles. En una modalidad, el servicio intermediario agrupa las solicitudes de correspondencia dentro de juegos correspondientes basados en la aplicación para la cual las solicitudes se reciben y una o más variables asociadas con la aplicación. Las solicitudes de correspondencia dentro de cada juego de correspondencia entonces pueden corresponderse con base en las variables tales como tipo de NAT, tipo de conexión y el lenguaje asociado con cada uno de los dispositivos móviles. Otras variables tales como ubicación geográfica, nivel de experiencia y antigüedad de las solicitudes de correspondencia también pueden usarse para tomar las decisiones de correspondencia.

BREVE DESCRIPCIÓN DE LOS DIBUJOS Un mejor entendimiento de la presente invención puede obtenerse de la siguiente descripción detallada junto con los dibujos siguientes, en los cuales: La Figura 1 ilustra una arquitectura de red en la cual un grupo de dispositivos y servicios móviles se comunican en una red.

Las Figuras 2a-c ilustran las transacciones entre una modalidad de una conexión de servicio de intercambio de datos (CDX), un servicio intermediario y/o un servicio de invitación.

La Figura 3 ilustra una modalidad de una estructura de datos de entrada.

La Figura 4 ilustra una modalidad de un método implementado por un servicio CDX.

La Figura 5 ilustra una modalidad de un método implementado por un dispositivo móvil.

La Figura 6 ilustra un grupo de dispositivos móviles conectados a través de canales de comunicación primaria y secundaria.

La Figura 7 ilustra una modalidad de un dispositivo móvil para seleccionar entre canales de comunicación secundaria y primaria.

Las Figuras 8a-b ilustran un grupo de dispositivos móviles conectados a través de canales de comunicación primarios y secundarios y las topologías de redes resultantes.

La Figura 9 ilustra una modalidad de un método implementado por computadora para seleccionar entre canales de comunicación secundaria y primaria.

La Figura 10 ilustra una arquitectura de red en la cual un grupo de dispositivos y servicios móviles incluyendo un servicio de directorio y un servicio de notificación push se comunican en una red .

La Figura 1 ilustra transacciones entre una modalidad de un servicio de invitación, un servicio de notificación push y una conexión de intercambio de datos (CDX).

La Figura 12 ilustra transacciones entre una modalidad de un servicio de invitación, un servicio de notificación push y un servicio de retransmisión.

La Figura 13 ilustra una modalidad de un servicio de retransmisión para establecer una conexión de retransmisión entre dos o más dispositivos móviles.

La Figura 14 ilustra una modalidad de un servicio intermediario para concordar los dispositivos móviles para aplicaciones en línea.

La Figura 15 ilustra una modalidad de un método para concordar los dispositivos/usuarios.

La Figura 16 ilustra un método para concordar los usuarios/dispositivos usando diferentes variables de ajuste de correspondencia.

La Figura 17 ilustra un recuadro exponiendo una interfase de programación de aplicación (API) para aplicaciones y servicio API para comunicarse con un juego de servicios.

La Figura 18 ilustra una modalidad de un recuadro de juego con una API para aplicaciones, un módulo de servicios de juego y un demonio de juego para la comunicación con los servicios.

La Figura 19 ilustra una modalidad de un componente del programa de implementación API y un componente del programa de llamada API.

La Figura 20 ilustra una modalidad en la cual las llamadas API se realizan entre los sistemas, servicios y aplicaciones de operación.

. La Figura 21 ilustra una modalidad de una arquitectura del sistema de computación ejemplarizador.

La Figura 22 ilustra otra modalidad de una arquitectura del sistema de computación ejemplarizador.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN Se describen modalidades de un aparato, método y medio legible por computadora para establecer, mantener y usar canales de comunicación punto o punto ("P2P") de respaldo y/o primarios en una red. Un servicio de invitación y un servicio intermediario también se describen para invitar y concordar a los usuarios, respectivamente, para las sesiones P2P. Adicionalmente, un servicio de retransmisión se describe para permitir a los usuarios establecer conexiones de retransmisión bajo ciertas condiciones específicas. Finalmente, un recuadro de la aplicación e interfase de programación de la aplicación asociada (API) se describen para permitir a los desarrolladores de la aplicación diseñar las aplicaciones que toman ventaja de varias características de colaboración en línea descritas en este documento.

En toda la descripción para propósitos de explicación, se establecen numerosos detalles específicos para proporcionar un entendimiento completo de la presente invención. Será aparente para un experto en la técnica que la presente invención puede practicarse con algunos de estos detalles específicos. En otros ejemplos, las estructuras y dispositivos bien conocidos no se muestran o se muestran en una forma de diagrama de bloque para evitar el oscurecimiento de los principios subyacentes de la presente invención.

APARATO Y MÉTODO PARA LA CONEXIÓN DE INTERCAMBIO DE DATOS EN FORMA EFICIENTE Y SEGURA Como se ilustra en la Figura 1 , una topología de red general implementada en una modalidad de la .invención puede incluir un grupo de dispositivos de computación móviles de "clientes" o "punto" A-D, 120-123, respectivamente, la comunicación con uno u otro y con uno o más servicios 1 10-1 12 en una red 120. Aunque ilustrado como una nube de red simple en la Figura 1 , la "red" 120 puede incluir una variedad de diferentes componentes incluyendo redes públicas tales como la Internet y las redes privadas tales como redes Wi-F¡ (por ejemplo redes inalámbricas caseras 802.1 1 n o puntos de acceso a internet inalámbricos), redes Ethernet de área local, redes de datos para celular (por ejemplo, 3G, Edge, etc.) y redes WiMAX por nombrar a algunos. Por ejemplo, el dispositivo móvil A 120 puede conectarse a una red Wi-Fi local representada por el enlace de red 125, el dispositivo móvil B 121 puede conectarse a una red 3G (por ejemplo, Sistema de Telecomunicaciones Móviles Universales ("UMTS"), Acceso Ascendente de Paquetes a Alta Velocidad ("HSUPA"), etc.) representado por el enlace de red 126, el dispositivo móvil C 122 puede conectarse a una red WiMAX representada por el enlace de red 127 y el dispositivo móvil 123 puede conectase a una red Wi-Fi pública representada por el enlace de red 128. Cada uno de los enlaces de red local 125-128 en la red tal como la Internet a través de una puerta y/o dispositivo NAT (no mostrado en la Figura 1 ), por lo tanto habilitando la información entre los varios dispositivos móviles 120-123 en la red pública. Sin embargo, si dos dispositivos móviles están en la misma red local o privada (por ejemplo, la misma red Wi-Fi), entonces los dos dispositivos pueden comunicarse directamente sobre esa red local/privada, derivando la red pública. Debe notarse, por supuesto que los principios subyacentes de la invención no se limitan a cualquier juego particular de tipos de redes o topologías de redes.

Cada uno de los dispositivos móviles 120-123 ilustrados en la Figura 1 pueden comunicarse con un servicio intercambiador de datos (CDX) 1 10, un servicio intermediador 1 1 1 y un servicio de invitación 1 12. En una modalidad, los servicios 1 10-1 12 pueden implementarse como programas ejecutados a través de uno o más dispositivos de computación físicos tales como servidores. Como se muestra en la Figura 1 , en una modalidad, los servicios 1 10-1 12 pueden implementarse dentro del contexto de un servicio de datos más grande 100 manejado por la misma entidad (por ejemplo, el mismo proveedor de servicio de datos) y accesible por cada uno de los dispositivos móviles 120-123 en la red 120. El servicio de datos 100 puede incluir una red de área local (por ejemplo, una LAN basad en Ethernet) conectando varios tipos de servidores y bases de datos. ?G servicio de datos 100 también puede incluir una o más redes de almacenamiento ("SANs" por sus siglas en Inglés) para almacenar los datos. En una modalidad, las bases de datos almacenan y manejan los datos para cada uno de los dispositivos móviles 120-123 y los usuarios de aquellos dispositivos (por ejemplo, datos de cuenta del usuario, datos de cuenta del dispositivo, datos de aplicación del usuario, etc.).

En una modalidad, el servicio de intermediario 1 1 1 puede concordar dos o más dispositivos móviles para una sesión P2P de colaboración en un juego especifico de condiciones. Por ejemplo, los usuarios de dos o más de los dispositivos móviles pueden interesarse en jugar un juego de jugadores múltiples particular. En dicho caso, el servicio intermediario 1 1 1 puede identificar un grupo de dispositivos móviles para participar en el juego con base en variable tal como cada nivel de experiencia del usuario, la edad de cada uno de los jugadores, el tiempo de las solicitudes de correspondencia, el juego particular para el cual una correspondencia se solicitó y varias variables de juego específicas. Por medio de ejemplo y no limitante, el servicio de intermediario 1 1 1 puede intentar concordar a los usuarios con niveles similares de experiencia en el juego de un juego particular. Adicionalmente, los adultos puede concordarse con otros adultos y los niños pueden concordarse con otros niños. Además, el servicio intermediario 1 1 1 puede priorizar las solicitudes del usuario con base en el orden en el cual aquellas solicitudes fueron recibidas. Los principios subyacentes de la invención no se limitan a cualquier juego particular de criterio de correspondencia o cualquier tipo particular de aplicación P2P.

Como se describió anteriormente, en respuesta a una solicitud de correspondencia, el servicio intermediario 1 1 1 puede coordinarse con el servicio CDX 10 para asegurar que todos los participantes concordados reciben los datos de conexión necesarios para establecer las sesiones P2P en una manera segura y eficiente.

En una modalidad, el servicio de invitación 1 12 también identifica dispositivos móviles para participación en sesiones P2P de colaboración. Sin embargo, en el caso del servicio de invitación 1 12, al menos uno de los participantes se identifica específicamente por el 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 ID del usuario o número telefónico). Como con el servicio intermediario 1 1 1 , en respuesta a una solicitud de invitación, el servicio de invitación 1 12 puede identificar el juego de participantes y coordinarlos con el servicio CDX 1 10 para asegurar que todos los participantes reciben los datos de conexión necesarios para establecer las sesiones P2P en una manera segura y eficiente.

Como se mencionó anteriormente, en una modalidad, el servicio CDX 110 opera 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. Especialmente, una modalidad del servicio CDX genera los datos transversales NAT (algunas veces referidos como puntos de dato ("Hole Punch") en respuesta a las solicitudes del dispositivo móvil para habilitar los servicios y clientes externos para comunicarse a través de NAT de cada dispositivo móvil (es decir para "marcar un punto" a través de NAT para alcanzar el dispositivo). Por ejemplo, en una modalidad , el servicio CDX detecta la dirección IP externa y el puerto necesario para comunicarse con el dispositivo móvil y proporciona esta información al dispositivo móvil. En una modalidad, el servicio CDX también recibe y procesa listas de dispositivos móviles generadas por el servicio intermediario 1 1 1 y el servicio de invitación 1 12 y distribuye eficientemente y con seguridad los datos de conexión para cada uno de los dispositivos móviles incluidos en las listas (como se describe en detalle posteriormente).

En una modalidad, la comunicación entre los dispositivos móviles y el servicio CDX 1 10 se establece usando un protocolo de red relativamente ligero y el servicio CDX 1 10 se establece usando un protocolo de red relativamente ligero tal como las conexiones de Protocolo de Datagramas de Usuario ("UDP", por sus siglas en Inglés). Como se conoce por los expertos en la técnica, las conexiones UDP no requieren diálogos de movimiento de manos para garantizar la confiabilidad del paquete, ordenamiento o integridad de los datos y por lo tanto no consume tanto procesamiento de paquetes como las conexiones TCP. Consecuentemente, la naturaleza apátrida ligera del UDP es útil para los servidores que contestan pequeñas preguntas de un vasto número de clientes. Además, a pesar del TCP, el UCP es compatible con la transmisión de paquetes (en los cuales los paquetes se envían a todos los dispositivos en una red local) y la multi-distribución (en la cual los paquetes se envían a un subconjunto de dispositivos en la red local). Como se describió anteriormente, incluso cuando el UDP puede usarse, la seguridad puede mantenerse en el servicio CDX mediante la encriptación de los datos transversales a NAT usando claves de sesión.

En contraste al protocolo de red ligero bajo usado por el servicio CDX 1 10, en una modalidad , la comunicación entre los dispositivos móviles 1 20-123 y el servicio intermediario 1 1 1 y/o el servicio de invitación 1 12 se establece con un protocolo de red inherentemente seguro tal como Seguridad de Protocolo de Transferencia de Hipertexto ("HTTPS", por sus siglas en Inglés), que confía en las conexiones de Capa de Conexión Segura ("SSL", por sus siglas en Inglés) o la Seguridad en la Capa de Transporte ("TLS", por sus siglas en Inglés). Los detalles asociados con estos protocolos son bien conocidos por aquellos expertos en la técnica.

La Figura 2a ilustra una serie ejemplarizadora de transacciones que pueden implementarse por un servidor CDX. Cuando se describe la operación de una modalidad del servicio CDX, los siguientes términos tendrán los siguientes significados: Datos de Conexión - Esta es la información cuyos compañeros potenciales necesitan intercambiar uno con el otro para establecer una Sesión de Punto a Punto. Se describen modalidades de un mecanismo de cómo esta información puede intercambiarse.

Servidor CDX - Un servidor CDX en una modalidad es un reflector de multidifusión autentificado que permite a las entidades autorizadas intercambiar datos arbitrarios. Estos datos se refieren como Carga útil.

Sesión CDX - Una sesión CDX se refiere a un grupo de dispositivos del cliente que pueden comunicarse uno con otro via el Servidor CDX. Cada dispositivo del cliente que es una parte de la sesión se asigna a una Entrada CDX. Cada sesión tiene una ID de Sesión CDX única, que es un número entero mayor que puede usarse para identificar o ser referencia para una sesión individual .

Solicitud CDX - Una solicitud que se envía desde un dispositivo del cliente al Servidor CDX, Una solicitud generalmente consiste de dos partes: Una solicitud generalmente consiste de dos partes: una Entrada CDX y la Carga Útil. En esta modalidad, la carga útil son los Datos de Conexión encriptados con la Clave de Sesión.

Respuesta CDX - Una respuesta CDX es la que se "refleja" de nuevo a los otros dispositivos en una Sesión CDX cuando el Servidor CDX recibe una Solicitud CDX de un miembro de la Sesión CDX Se construye mediante adicionar la Carga Útil al Módulo Ficticio de la Entrada CDX de la Entrada CDX usada en la Solicitud CDX dada.

Entrada CDX - Una Entrada CDX le dice al Servidor CDX como enviar una Carga Útil a los miembros de la Sesión CDX. En una modalidad, está se "firma" con la clave de la Entrada CDX para prevenir la falsificación o alteración. Como se ilustra en la Figura 3, en una modalidad, una Entrada CDX contiene la siguiente información: El ID de Sesión 301 que no se encripta u ofusca en una modalidad.

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

El Índice 303 de cual participante en la sesión al cual esta entrada se refiere (no encriptado u ofuscado en una modalidad).

Una fecha/tiempo de expiración 304, después de la cual la entrada se considera inválida (no encriptada u ofuscada en una modalidad).

Los Datos de Punto de Dato CDX 305-306 para cada participante en la sesión, encriptados usando la Clave de Entrada CDX en una modalidad.

Un código de autentificación de mensaje 307 usando la Clave de Entrada CDX, que actúa como una "Firma digital" para asegurar que la entrada es auténtica.

Módulo Ficticio de la Entrada CDX - la primera parte de una Entrada CDX, menos los Datos de Punto de Dato CDX y el código de autentificación de mensaje.

Carga Útil - Esta es la segunda parte de una Solicitud CDX y una Respuesta CDX. La Carga Útil son los datos que un dispositivo del cliente desea comunicar a otros dispositivos en la Sesión CDX. En esta modalidad, la Carga Útil son los Datos de Conexión encriptados con la Clave de Sesión. El Servidor CDX no encripta la Carga Útil, en una modalidad, simplemente la pasa a lo largo sin cambios: Clave de Sesión - Esta es la clave usada por los clientes para encriptar los Datos de Conexión. En una modalidad, esta clave no se conoce para el Servidor CDX. En esta modalidad, la Clave de Sesión se genera mediante emparejar el servicio y transmitirlo a los clientes junto con sus Entradas CDXs individuales.

Clave de Entrada CDX - Esta es la clave usada para crear y "firmar" las Entradas CDXs. La clave de Entrada CDX se conoce solamente por el Servidor CDX y el servicio que genera la Entrada CDXs— el cual, como se describe posteriormente, podría ser el servicio intermediario y/o el servicio de invitación.

Solicitud de Punto de Dato CDX - Un tipo especial de Solicitud CDX que se usa para obtener los Datos de Punto de Dato CDX del Servidor CDX.

Datos del Punto de Dato CDX - Esto es un objeto binario grande de datos opacos que describe como el Servidor CDX puede enviar información al cliente que originalmente lo solicita. Se obtiene mediante enviar una Solicitud de Punto de Dato CDX al Servidor CDX. Los Datos de Punto de Dato CDX deben colectarse de cada dispositivo del cliente en la Sesión CDX antes de que las Entradas CDXs puedan generarse. Los Datos de Punto de Dato CDX (algunas veces referidos como "Datos transversales NAT') pueden incluir lá dirección IP pública y el puerto de un dispositivo de solicitud.

Regresando ahora a la Figura 2a, en una modalidad, el dispositivo móvil A 120 y el dispositivo móvil B 121 pueden ejecutar una aplicación de colaboración tal como un juego de múltiples jugadores o una sesión de chat de colaboración que requiere una conexión P2P con uno o más dispositivos de computación. En 201 a, el dispositivo móvil A 120 transmite una Solicitud de Punto de Dato CDX al Servidor CDX 110. El Servidor CDX 1 10 entonces responde con los Datos de Punto de Dato CDX en 202a. En una modalidad, los datos de punto de dato incluyen la dirección IP pública y el puerto del dispositivo móvil A y/o cualquier otro dato necesario para señalar datos a través del NAT del dispositivo móvil A (por ejemplo, los datos tipo NAT definiendo el tipo NAT del dispositivo móvil A). Transacciones Similares se realizan por el dispositivo móvil B en 201 b y 202b, respectivamente.

¦ En 203a y 203b, los dispositivos móviles A y B entonces envían las solicitudes de correspondencia incluyendo los Datos de Punto de Dato CDX al Servicio Intermediario, junto con cualquier criterio de correspondencia adicional (posteriormente descrito). En esta etapa, dispositivos móviles A y B pueden iniciar la construcción de los Datos de Conexión necesarios para establecer una conexión P2P. Esto puede llevarse a cabo, por ejemplo, usando una transacción tal como una transacción de Establecimiento de Conectividad al Internet estándar ("ICE" por sus siglas en Inglés) (por ejemplo, mediante un Servicio transversal NAT). Sin embargo, los principios subyacentes de la invención no se limitan a cualquier mecanismo particular para la determinación de los Datos de Conexión.

En una modalidad, una vez que el Servicio Intermediario 1 1 1 ha encontrado un juego de los dispositivos del cliente con criterio correspondiente, puede generarse un ID de Sesión CDX única, una Entrada CDX única para cada miembro de la Sesión CDX, y una Clave de Sesión única.

En una modalidad, el Servicio Intermediario 1 1 1 puede encriptar los Datos de Punto de Dato CDX para la Entrada CDX usando un clave de Entrada CDX única. En 204a y 204b, el Servicio Intermediario entonces puede enviar a cada uno de los dispositivos móviles A y B su Entrada CDX y la Clave de Sesión.

El Dispositivo móvil A recibe la Entrada CDX y la Clave de Sesión y encripta sus Datos de Conexión previamente determinados usando la Clave de Sesión, haciendo una Carga Útil. En una modalidad, el dispositivo móvil A construye una Solicitud CDX mediante agregar la Carga Útil construida a la Entrada CDX. En 205a, el dispositivo móvil A envía la Solicitud CDX al Servidor CDX 1 10. El Dispositivo móvil B también podría realizar las mismas operaciones y transmitir una solicitud al Servidor CDX en 205b.

En 206a, el Servidor CDX 1 10 recibe la Solicitud CDX, examina la entrada para asegurar que es válida y auténtica (por ejemplo, con base en el código de autentificación de mensaje 307). Si la Entrada CDX es inválida, la solicitud se deja caer. En una modalidad, el Servidor CDX entonces encripta el juego de Datos de Punto de Dato CDX que está contenido en la Entrada CDX usando la clave de Entrada CDX. En una modalidad, la clave de Entrada CDX puede incluir un tiempo/fecha de expiración que también puede transmitirse con las entradas. El Servicio CDX 1 10 y el servicio intermediario 1 1 1 pueden almacenar dos (o más) diferentes claves de Entrada CDX para encriptación - decriptación - una primera que se activa realmente y una segunda que llegará a ser activada al alcanzar el tiempo/fecha de expiración de la primera. Al recibir una entrada, el Servicio CDX 1 10 puede leer el tiempo/fecha de expiración para determinar la clave de entrada a usarse. Cuando una clave de Entrada CDX ha expirado, ambos, el Servicio CDX 1 10 y el servicio intermediario 1 1 1 - pueden cada uno generar una nueva clave de entrada (que será la siguiente clave para usarse después de que la clave de entrada actual expira). En una modalidad, el Servicio CDX 1 10 y el servicio intermediario 1 1 1 ejecutan el mismo algoritmo de generación de clave para asegurar la consistencia con las dos claves de entrada. Por ejemplo, las técnicas tales como aquellas usadas para el mecanismo de autentificación RSA SecurID bien conocido puede usarse en el cual un nuevo código de autentificación se genera en intervalos fijos. En una modalidad, una nueva clave de entrada CDX se genera en una base diaria. Sin embargo, los principios subyacentes de la invención no se limitan a cualquier mecanismo particular para la generación de claves de Entrada CDX.

Las mismas operaciones podrían realizarse como se muestra en 206b para el dispositivo móvil B. El Servidor CDX construye una Respuesta CDX de la Solicitud CDX y posteriormente usad los Datos de Punto de Dato CDX para enviar la Respuesta CDX a los participantes en la Sesión 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 CDX 207a del Servidor CDX. El Dispositivo del cliente B examina el modelo ficticio de la Entrada CDX para asegurar que el ID de la Sesión corresponde al ID de Sesión de su propia Entrada CDX. El Dispositivo móvil B puede entonces decriptar la Carga Útil usando la Clave de Sesión, produciendo los Datos de Conexión del Dispositivo móvil A. El Dispositivo móvil B entonces usa los Datos de Conexión del Dispositivo móvil A para iniciar el proceso de establecer una sesión P2P. En una modalidad, estas involucran transacciones estándares ICE. Sin embargo, los principios subyacentes de la invención no se limitan a ningún mecanismo particular para establecer la comunicación P2P.

Como se mencionó anteriormente, en una modalidad, los dispositivos móviles A y B establecen sesiones de Seguridad de Protocolos de Transferencia de Hipertextos ("HTTPS") para comunicarse con el servicio intermediario 1 1 1 (por ejemplo, usando las solicitudes HTTPS / transacciones de respuesta) y establecen las conexiones UDP para comunicarse con el Servicio CDX. Las solicitudes de correspondencia 204a, 204b pueden incluir el tipo NAT y los datos de punto de dato (por ejemplo, la dirección IP pública y el puerto) previamente determinados para cada dispositivo móvil respectivo. En una modalidad que involucra un juego de múltiples jugadores, cada solicitud de correspondencia puede identificar al jugador en cada dispositivo móvil (por ejemplo, usando un código de ID de jugador único), el juego que cada usuario desea jugar, el número de jugadores que participan en el juego y/u otras variables de configuración asociadas con el juego deseado. Por medio de ejemplo y sin limitación, las variables de configuración del juego asociadas con un juego pueden incluir un nivel de dificultad (por ejemplo, fácil, normal, difícil), la edad de un usuario (por ejemplo, "debajo de los 13"), una subregión del juego (por ejemplo, "nivel 2) y/o el nivel de la experiencia del jugador (por ejemplo, experto, novato, intermedio). Como se describe en detalle posteriormente, estas variables algunas veces se refieren como una "celda" del juego y son identificadas usando un "ID de Celda" único. Cada juego puede incluir juegos diferentes de ID de celdas para identificar las diferentes variables de configuración del juego.

En una modalidad, el dispositivo móvil B envía y reconoce en 208a y 209a. Similarmente, el reconocimiento del dispositivo móvil A se transmite en 208b y 209b. Si los reconocimiento del dispositivo móvil A o B no se reciben después de un periodo de tiempo específico, entonces los Datos de Conexión 207a pueden volverse a enviar al dispositivo móvil B 212. Ya sea el Servicio CDX 1 10 puede iniciar el reintento y/o el dispositivo móvil A 120 puede reiniciar el reintento.

La Figura 2b ilustra un ejemplo más detallado en el cual tres diferentes dispositivos móviles 120-122 negocian para las conexiones P2P usando el Servicio CDX y el servicio intermediario 1 1 1 . La Figura 2b también ilustra dos servicios adicionales usados por los dispositivos móviles 120-122 para establecer una conexión: un servicio NAT transversal 291 para determinar el tipo NAT y un Servicio NAT transversal 290 para determinar los datos de conexión completos para cada uno de los dispositivos móviles (por ejemplo, usando una transacción de datos de conexión ICE). Debe notarse, sin embargo, que los servicios separados no se requieren para cumplir con los principios subyacentes de la invención. Por ejemplo en una modalidad alterna, las funciones NAT transversales realizadas por cada uno de estos servicios 290-291 pueden integrarse directamente dentro del servicio CDX 1 10 y/o el servicio intermediario 1 1 1 . Similarmente, las funciones realizadas por ambos servicios NAT transversales pueden integrarse dentro de un solo servicio NAT transversal. 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.

Regresando ahora a los detalles específicos de la Figura 2b, en 220, el dispositivo móvil A transmite una solicitud tipo NAT al Servicio transversal NAT 291 . En respuesta, el Servicio transversal NAT 291 puede usar varias técnicas conocidas incluyendo la implementación de una serie de transacciones para determinar el tipo NAT usado por el dispositivo móvil A. Por ejemplo, el Servicio transversal NAT 291 puede intentar abrir las diferentes direcciones IP y los puertos en el NAT del dispositivo móvil A y comunicarse con el dispositivo móvil A, a través de aquellos puertos usando diferentes combinaciones de IP/puerto. De esta manera, el NAT empleado por el dispositivo móvil A puede clasificarse como uno de los tipos NAT anteriormente descrito (por ejemplo, cono completo, cono restringido, cono restringido del puerto, simétrico) o un tipo NAT alterno. Esta información entonces puede proporcionarse al dispositivo móvil A 120 como se ilustra.

En 221 , el dispositivo móvil A 120 inicia una solicitud transversal NAT con el Servicio CDX 1 10. En respuesta, el Servicio CDX 1 10 puede leer la dirección IP pública y el número de puerto público usado para la solicitud y transmite esta información de regreso al dispositivo móvil A 20. Como se describió anteriormente, si un dispositivo está detrás de un NAT, su puerto público y la Dirección IP serán diferentes de su puerto privado y Dirección IP, respectivamente. Además, dependiendo del tipo de NAT siendo usadó, la dirección IP pública y el puerto pueden usarse para "señalar un dato" a través del dispositivo NAT para alcanzar al dispositivo móvil.

En 222, el dispositivo móvil A 120 transmite una solicitud de correspondencia 222 al servicio intermediario 1 1 1 . Como se describió anteriormente, en una modalidad, el dispositivo móvil A comunica al servicio intermediario 1 1 1 usando las sesiones de Seguridad de Protocolos de Transferencia de Hipertextos ("HTTPS") (por ejemplo, usando solicitudes HTTPS/transacciones de respuesta). La solicitud de correspondencia puede incluir el tipo NAT y los datos de punto de datos (por ejemplo, la dirección IP pública y el puerto) previamente determinados por el dispositivo móvil A 120. En una modalidad que involucra un juego de múltiples jugadores, la solicitud de correspondencia puede identificar al jugar en el dispositivo móvil A (por ejemplo, usando un código de ID de jugador único), el juego que el usuario desea jugar, el número de jugadores que participan en el juego y/u otras variables de configuración del juego asociadas con el juego deseado (como se describió previamente con respecto a la Figura 2a).

En 223-225 un juego de transacciones correspondiente a las transacciones 220-222 se realizan por dispositivo móvil B 121 y en 226-228 un juego de transacciones correspondiente a las transacciones 220-222 se realizan por el dispositivo móvil C 122. Además, siguiendo la transacción 228, el servicio intermediario 1 1 1 ha recibido solicitudes de correspondencia para los tres de los dispositivos móviles 120-122. En este ejemplo especifico, las solicitudes de correspondencia resultan en los dispositivos móviles 120-122 siendo correspondientes para una sesión de colaboración particular tal como un juego de múltiples jugadores (es decir, los usuarios de estos dispositivos móviles pueden tener seleccionado el mismo juego con los mismos o similares juegos de variables, por lo tanto resultando en una correspondencia por el servicio intermediario 1 1 1 ).

El servicio intermediario 1 1 1 usa los datos contenidos en cada una dé las solicitudes de correspondencia para generar la Entrada A, que se transmite al dispositivo móvil A en 229; la Entrada B, que se transmite al dispositivo móvil B en 230 y la Entrada C, que se transmite al dispositivo móvil C en 231 . Aunque no se muestra en la Figura 2b, el servicio intermediario 111 puede usar un servicio de notificación push para enviar las Entradas A, B y C en los dispositivos móviles A, B, y C, respectivamente (por ejemplo, tal como el servicio de notificación push 1050 ilustrado en las Figuras 1 1 -12). Una modalidad de la estructura de datos de entrada usada para las entradas A, B, y C se describió anteriormente con respecto a la Figura 3.

En 232, el dispositivo móvil A 120 se comunica con el Servicio transversal NAT 290 para determinar sus propios Datos de Conexión. En una modalidad, este puede incluir una transacción de datos de conexión ICE estándares. Como se mencionó previamente, los datos de conexión incluyen la dirección IP pública/privada, el puerto y el tipo NAT para el dispositivo móvil A 120.

El dispositivo móvil A 120 adjunta sus Datos de Conexión a la Entrada A y en 233, transmite la Entrada A con los datos de conexión al servicio CDX 1 10. En una modalidad, el servicio CDX 1 10 procesa la Entrada A como se describió anteriormente y en 234, transmite los datos de conexión (que pueden encriptarse) al dispositivo móvil B 121 y el dispositivo móvil C 122. Para estas transacciones, el servicio CDX 1 10 puede usar los datos transversales NAT para los dispositivos móviles B y C incluidos con la Entrada A.

En 236-238, un juego de transacciones correspondientes a las transacciones 232-234 se realizan usando la Entrada B y en 238-240 un juego de transacciones correspondientes a las transacciones 232-234 se realiza por la Entrada C. Además, siguiendo la transacción 240, los Datos de Conexión han sido compartidos entre cada uno de los dispositivos móviles 120-122. Usando 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.

Como se ilustra en la Figura 2c, un servicio de invitación 1 12 también puede usarse con el Servicio CDX 1 10 (ya sea en lugar. de o en adición al servicio intermediario 1 1 1 ). En una modalidad, el servicio de invitación 1 12 procesa las solicitudes de invitación para las conexiones P2P con dispositivos móviles y/o usuarios específicos. El servicio de invitación 1 12 puede implementarse como un servicio apátrido (es decir, un servicio que no cambia el estado actual de las transacciones entre cada uno de los dispositivos inhalámbricos.).

Regresando a este ejemplo particular, en 250, el dispositivo móvil A 120 transmite una solicitud tipo NAT al Servicio transversal NAT 291 . En respuesta, el Servicio transversal NAT 291 puede usar varias técnicas conocidas para determinar el tipo NAT usado por el dispositivo móvil A (algunos de los cuales se describieron anteriormente). En 251 , el dispositivo móvil A 120 inicia una solicitud NAT con el Servicio CDX 1 10. En respuesta, el Servicio CDX 110 puede leer la dirección IP pública y el número del puerto público usado para la solicitud y retrasmisión de esta información de regreso al dispositivo móvil A 120. Como se describió anteriormente, si un dispositivo está detrás de un NAT, su puerto público y la Dirección IP serán diferentes de su puerto privado y la Dirección IP, respectivamente. Además, dependiendo del tipo de NAT siendo usado, la dirección IP pública y el puerto pueden usarse para "señalar un dato" a través del dispositivo NAT para alcanzar el dispositivo móvil.

Como con el servicio intermediario, en una modalidad, cada uno de los dispositivos móviles se comunica con el servicio de invitación 12 usando las sesiones de Seguridad de Protocolos de Transferencia de Hipertextos ("HTTPS") (por ejemplo, usando solicitudes HTTPS / transacciones de respuesta).

En 252, el dispositivo móvil A 120 transmite una solicitud de invitación al servicio de invitación 2 que incluye los datos transversales NAT del dispositivo móvil A (por ejemplo, tipo NAT, puerto/dirección IP pública). En una modalidad que usa un servicio de notificación push (descrito en mayor detalle posteriormente), la solicitud de invitación también puede incluir el componente léxico push del dispositivo móvil A. La solicitud de invitación 252 también puede incluir un código de identificación identificando uno o más de los otros usuarios/dispositivos - en este caso, los usuarios de los dispositivos móviles B 121 y C 122. Varios tipos diferentes de código de identificación pueden usarse. Por ejemplo, en el caso de un juego de jugadores múltiples, el código de identificación puede comprender los códigos de ID de jugador específico - del juego. En el caso de una sesión de chat de audio/video, el código de identificación puede comprender los números de teléfono o los códigos de ID únicos identificando cada uno o más de los usuarios del usuario de la lista de "amigos" del dispositivo móvil A.

En una modalidad, el servicio de invitación 1 12 lee el código de identificación de la solicitud de invitación y realiza una búsqueda en una base de datos de registro (no mostrada) para localizar cada uno de los dispositivos móviles B y C. En una modalidad particular, cada uno de los dispositivos móviles B y C han sigo previamente registrados con un servicio push para recibir las notificaciones push del servicio de invitación 112. Como tal, en esta modalidad, el servicio de invitación 112 usa el servicio de notificación push para enviar las solicitudes de invitación en el dispositivo móvil B 121 y el dispositivo móvil C 122 en 253 y 254, respectivamente. Los detalles adicionales relacionados a un servicio de notificación push se describen posteriormente (ver, por ejemplo, las Figuras 1 1 -12 y el texto asociado) y en la Solicitud de Notificación push anteriormente referenciados.

En una modalidad, las solicitudes de invitación 253 y 254 incluyen la estructura de datos de entrada ilustrados en la Figura 3 y anteriormente descrita con respecto a las Figuras 2a-b. Específicamente, la entrada que se envía al dispositivo móvil B incluye una lista encriptada identificando los dispositivos móviles A y B y la entrada enviada al dispositivo móvil C incluye una lista encriptada identificando los dispositivos móviles A y C. En una modalidad, porque el servicio de invitación 12 no puede aún tener los datos transversales NAT del dispositivo móvil B, la "entrada" en 253 puede incluir otra información identificando el dispositivo móvil B. Por ejemplo, como se establece posteriormente con respecto a las modalidades que usan el servicio de retransmisión y el servicio de notificación push (ver, por ejemplo, las Figuras 1 1 -12), la "entrada" en 253 puede incluir los Datos transversales NAT para el dispositivo móvil A, el código de ID del dispositivo A, el componente léxico push del dispositivo A, el código de identificación del dispositivo B y el componente léxico push para el dispositivo móvil B. Los mismos tipos de información pueden proporcionarse en 254 para los dispositivos móviles A y C.

En 255, el dispositivo móvil B puede comunicarse con el Servicio transversal NAT 291 para determinar su tipo de NAT y, en 256, el dispositivo móvil B puede comunicarse con el Servicio CDX 1 10 para determinar sus Datos transversales NAT (por ejemplo, puerto/dirección IP pública). En 257, el dispositivo móvil B transmite una respuesta a la invitación al servicio de invitación 1 12 conteniendo el código de identificación del dispositivo móvil A y el dispositivo móvil B, los datos transversales NAT y si se usa el servicio de notificación push, los componentes léxicos push para los dispositivos móviles A y B. En 258, el dispositivo móvil B puede recuperar sus Datos de Conexión actuales mediante comunicarse con el Servicio transversal NAT 290. En 259, el dispositivo móvil B transmite su entrada (Entrada B) con sus Datos de Conexión actuales al Servicio CDX 1 10. En respuesta, el Servicio CDX 1 10 procesa la entrada como se describió anteriormente y envía los Datos de Conexión al dispositivo móvil A 120.

En la recepción de la respuesta a la invitación del dispositivo móvil B, el servicio de invitación 1 12 puede generar una entrada encriptada para el dispositivo móvil A y transmite la entrada al dispositivo móvil A en 260. En una modalidad, la entrada incluye datos transversales NAT, el tipo de NAT y el componente léxico push (si el servicio de notificación push se usa) para los dispositivos móviles A y B. Las "entradas" descritas con respecto a la Figura 2c pueden ser las mismas o diferentes de las estructuras de datos para las "entradas" descritas con respecto al servicio intermediario 1 1 1 . Por ejemplo, más que generar una "entrada" encriptada" como se describió anteriormente, el servicio de invitación 1 12 puede simplemente generar una ID de sesión única 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 mediante comunicarse con el Servicio transversal NAT 290. El dispositivo móvil A posteriormente puede adjuntar sus Datos de Conexión a la entrada y en 262, transmite la entrada con sus datos de conexión para el Servicio CDX 1 10. El Servicio CDX 1 10 procesa la entrada como se describió anteriormente y la renvia 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 usan los datos de conexión intercambiados para abrir una conexión P2P directa. Como se describe posteriormente, en los casos en donde los tipos de NAT del dispositivo móvil A y el dispositivo móvil B son incompatibles, un servicio de retransmisión puede usarse para habilitar 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 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 transversal NAT 291 para determinar su Tipo NAT y, en 265, se comunica con el Servicio CDX 1 10 para determinar sus Datos transversales NAT (por ejemplo, puerto/dirección IP pública). En 266, el dispositivo móvil C transmite una respuesta de invitación conteniendo el tipo NAT del dispositivo móvil C y el dispositivo móvil A, los Datos transversales NAT y el componente léxico push (si el servicio de notificación push se usa). En 267, el dispositivo móvil C recupera sus Datos de Conexión actuales a través del NAT transversal del servicio P2P 290 y, en 268, el dispositivo móvil C agrega sus Datos de Conexión a la Entrada C y transmite la Entrada C al servicio CDX 1 10. El Servicio CDX 1 0 procesa la entrada como se describió anteriormente y renvía los datos de conexión del dispositivo móvil C al dispositivo móvil A 120.

En 269, dispositivo móvil A 120 recibe la respuesta de invitación del dispositivo móvil C del servicio de invitación 1 12 que incluye ambos tipo NAT de los dispositivos móviles A y C, los datos transversales NAT y los componentes léxicos push (si el servicio push se usa). En 270, el dispositivo móvil A recupera sus Datos de Conexión actuales del Servicio transversal NAT 290, agrega sus Datos de Conexión actuales a la Entrada A y en 271 , transmite la Entrada A al Servicio CDX 1 10. Alternativamente, la transacción 270 no puede requerirse porque el dispositivo móvil determina sus datos de conexión en la transacción 261 . El Servicio CDX 1 10 procesa la Entrada A como se describió anteriormente y renvía los datos de conexión del dispositivo móvil A al dispositivo móvil C. Finalmente, en 272, los dispositivos móviles A y C usan los datos de conexión intercambiados para establecer una conexión P2P directa 272.

En una modalidad, el servicio de invitación 1 12 y el servicio intermediario 1 1 1 pueden confiar en un servicio de notificación push (no mostrado) para depositar los datos en los dispositivos móviles. Por ejemplo, en la Figura 2c, las solicitudes de invitación 253 y 254 pueden enviarse' a los dispositivos móviles B 121 y C 122 vía el servicio de notificación push. Similarmente, en las Figura 2a, las entradas A y B pueden enviarse a los dispositivos móviles A 120 y B 121. En una modalidad, cuando un dispositivo móvil se activa en la red, registra su componente léxico push en un directorio de registro central accesible por el servicio de notificación push. En una modalidad, el directorio de registro asocia un ID de usuario protegido con contraseña o un número telefónico con un componente léxico push. Si el componente léxico push puede identificarse en el directorio, el servicio de notificación push puede usar el componente léxico push para transmitir las notificaciones push al dispositivo móvil. En una modalidad, el servicio de notificación push es el Servicio de notificación push de Apple ("APNS") diseñado por el cesionario de la presente solicitud y se describe por ejemplo en la Solicitud de Notificación push anteriormente referenciada. Debe notarse sin embargo, que un servicio de notificación push no se requiere por las modalidades de la invención mostradas en las Figuras 2a-c. Por ejemplo, las notificaciones push no se requieren para el Servicio CDX 1 10 para realizar sus operaciones como se describe en este documento.

La Figura 4 ilustra un método que puede implementarse por un Servicio CDX 1 10 para intercambiar los Datos de Conexión y la Figura 5 ilustra un método que puede implementarse por un dispositivo móvil para intercambiar los Datos de Conexión y establecer una conexión P2P. Ciertos aspectos de estos métodos ya se han descrito anteriormente con respecto a las Figuras 1 -2c. En particular, estos métodos pueden implementarse dentro del contexto de la arquitectura de red mostrada en las Figuras 1 -2c pero no se limitan a dicha arquitectura. En una modalidad, los métodos se incorporan en el código de programa que cuando se ejecuta por un procesador, causa las operaciones de los métodos a realizarse. El código del programa puede almacenarse en un medio legible por máquina tal como una memoria de acceso aleatorio ("RAM") mientras se ejecuta por el procesador. El procesador puede ser un procesador de propósito general (por ejemplo, un procesador Intel® CoreTM) o un procesador de propósito especial. Sin embargo, los métodos pueden implementarse usando cualquier combinación de equipo, programas y microprogramas. Además, el código de programa puede almacenarse en un dispositivo de almacenaje no volátil tal como un disco duro, disco óptico (por ejemplo, un Disco de Video Digital o Disco Compacto) o una memoria no volátil tal como un dispositivo de memoria Flash.

Regresando ahora al método mostrado en la Figura 4, en 401 , una solicitud NAT transversal (también referenciada algunas veces como una solicitud de "punto de dato") se recibe para un dispositivo móvil particular - "dispositivo móvil A" en el ejemplo. En 402, una respuesta NAT transversal se genera y transmite al dispositivo móvil A. En una modalidad, la generación de la respuesta NAT transversal puede incluir determinar el puerto/dirección IP pública actual y/o el Tipo NAT de dispositivo móvil A.

Una entrada para el dispositivo móvil A puede generarse subsecuentemente y encriptarse por una .entidad de generación de entradas tal como el servicio intermediario 1 1 1 o el servicio de invitación 1 12 anteriormente descrito. En 403, la entrada generada para el dispositivo móvil A ("Entrada A") se recibe, el cual incluye los Datos transversales NAT (para el dispositivo A y uno o más de los otros dispositivos) y los Datos de Conexión para el dispositivo A. En 404, la entrada se autentifica usando el código de autentificación de mensaje y los datos de punto de dato se decriptan usando la misma clave de Entrada CDX como esa usada por la entidad de generación de entrada para encriptar la entrada. Como se mencionó anteriormente, en una modalidad, la clave de Entrada CDX correcta se identifica usando una fecha/tiempo de expiración asociado con la clave de Entrada CDX.

En 405, los Datos transversales NAT para los dispositivos móviles se extraen. En 406, los Datos de Conexión para el dispositivo móvil A se transmiten a cada uno de los puntos usando los Datos transversales NAT. En 407 los reconocimientos se reciben de cada uno de los puntos. Si los reconocimientos no han sido recibidos de todos los puntos, determinados en 408, entonces los datos de conexión del dispositivo móvil A se retransmiten a aquellos puntos que no han respondido en 409. Cuando todos los datos de conexión se han reconocido, determinados' en 408, el método termina.

En una modalidad, el método mostrado en la Figura 4 puede realizarse para cada uno de los puntos involucrado 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 ilustra un método que puede realizarse mediante un dispositivo móvil de conformidad con las modalidades de la invención descritas en este documento. En 501 , una solicitud NAT transversal se transmite y, en 502, una respuesta NAT transversal se recibe. Como se describió previamente, los Datos transversales NAT contenidos en la respuesta pueden incluir el puerto público/Dirección IP del dispositivo de solicitud. En 503, una solicitud de correspondencia se transmite la cual contiene los Datos transversales NAT. Una entrada para el dispositivo móvil puede generarse subsecuentemente y encriptarse por una entidad de generación de entrada tal como el servicio intermediario 11 1 o el servicio de invitación 1 12 anteriormente descrito. Como una alternativa a la estructura de datos de entrada anteriormente descrita, el servicio intermediario 1 1 1 y/o el servicio de invitación 1 12 puede simplemente identificar cada uno de los participantes usando un ID de sesión única .

En 504, la entrada puede recibirse; en 505, los Datos de Conexión para el dispositivo móvil se adjuntan a la entrada; y en 506, la entrada con los Datos de Conexión se transmiten. En 507, los Datos de Conexión necesarios para establecer las conexiones P2P con uno o más puntos ser reciben. En 508, los reconocimientos indicando que uno o más de los dispositivos inalámbricos han recibido los Datos de Conexión transmitidos en 506 se reciben. Si todos los reconocimientos no se reciben, entonces en 510, los Datos de Conexión se retransmiten a aquellos dispositivos móviles de los cuales los reconocimientos no se han recibido. Si todos los reconocimientos se reciben, determinados en 509, entonces los Datos de Conexión recibidos en 507 se usan para establecer las Sesiones P2P con los otros dispositivos móviles.

APARATO Y MÉTODO PARA ESTABLECER Y USAR CANALES DE COMUNICACIÓN DE RESPALDO Los dispositivos móviles actuales son capaces de comunicarse en una variedad de canales de comunicación diferentes. Por ejemplo, el Apple ¡PhoneTM es capaz de comunicarse en redes Wi-Fi (por ejemplo, 802.1 1 b, g, redes n); redes 3G (por ejemplo, redes del Sistema de Telecomunicaciones Móviles Universales ("UMTS"), redes de Acceso Ascendente de Paquetes a Alta Velocidad ("HSUPA"), etc.); y redes Bluetooth (conocidas como redes de área personal ("PANs")). Los dispositivos móviles futuros serán capaces de comunicarsé con canales de comunicación adicionales tales como WiMAX, Telecomunicación Móvil Internacional Avanzada ("IMT"), y Evolución a Largo Plazo Avanzada ("LTE"), por nombrar a algunas.

' En operación, los dispositivos móviles actuales seleccionan un canal de comunicación primario de entre un juego de canales disponibles. Por ejemplo, los dispositivos móviles comúnmente se configuran para seleccionar una conexión Wi-Fi si una está disponible y para seleccionar una conexión de datos celulares (por ejemplo, una conexión UTMS) si Wi-F¡ no está disponible.

En una modalidad de la invención, un grupo de dispositivos móviles inicialmente establece los canales de comunicación punto a punto ("P2P") usando intercambios de los Datos de Conexión ICE estándares y/o usando las técnicas de intercambio de los Datos de Conexión anteriormente descritas. Los dispositivos móviles entonces pueden intercambiar los Datos de Conexión en los canales primarios para establecer uno o más canales de comunicación secundarios que se usan como canales de respaldo si cualquiera de los canales primarios falla. En una modalidad, los canales de comunicación secundarios se mantienen abiertos a través de los cortafuegos NAT mediante periódicamente transmitir los paquetes "heartbeat" en estos canales.

Como se usa en este documento, un "canal" de comunicación se refiere a la ruta de red entre dos dispositivos móviles y un "enlace" de comunicación se refiere a una conexión particular usada en la ruta de comunicación. Por ejemplo, si el dispositivo A se conecta a la Internet usando una conexión Wi-Fi y el dispositivo B se conecta a la Internet usando una conexión 3G, entonces el "canal" entre el dispositivo A y el dispositivo B se define por ambos 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, el dispositivo A intercambia de un enlace Wi-Fi a un enlace 3G, entonces el "canal" entre el dispositivo A y el dispositivo B se cambia no importando el hecho de que el enlace 3G del dispositivo B sigue siendo el mismo.

Los ejemplos específicos en los cuales los dispositivos móviles establecen canales de comunicación primarios y secundarios ahora se describirán con respecto a la Figura 6. Debe notarse, sin embargo, que los principios subyacentes de la invención no se limitan al juego particular de enlaces de comunicación y 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, la Internet) en un enlace de comunicación 605 con el dispositivo NAT 61 1 y en el enlace de comunicación 606 con el dispositivo NAT 612. Similarmente, el dispositivo C 603 es capaz de conectarse a la red 610 en el enlace de comunicación 609 con el dispositivo NAT 613 y en el enlace de comunicación 610 con el dispositivo NAT 613. Por medio de ejemplo, y sin 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.

Consecuentemente, en este ejemplo, existen cuatro diferentes canales de comunicación que pueden establecerse entre el dispositivo móvil A y el dispositivo móvil B: un primer canal que usa los enlaces 605 y 609; un segundo canal que usa los enlaces 605 y 610; un tercer canal que usa los enlaces 606 y 609; y un tercer canal que usa los enlaces 606 y 610. En una modalidad, los dispositivos móviles A y B seleccionarán uno de estos canales como el canal de comunicación primario basado en un esquema de priorización y seleccionarán los tres canales restantes como canales de respaldo. Por ejemplo, un esquema de priorización puede seleccionar el canal con el ancho de banda más alto como el canal primario y usar los canales restantes como los canales secundarios. Si dos o más canales tienen ancho de banda comparable, el esquema de priorización puede incluir seleccionar el canal menos caro (asumiendo que el usuario paga una tasa por usar uno o más de los canales). Alternativamente, el esquema de priorización puede ser para seleccionar el canal menos caro como el canal primario y, si el costo de cada canal es el mismo, se selecciona el canal con ancho de banda más alto. Varios esquemas de priorización diferentes pueden ¡mplementarse mientras aún se cumple con los principios subyacentes de la invención.

Los dispositivos móviles A 601 y C 603 pueden usar las técnicas anteriormente descritas para establecer el canal de comunicación primaria (por ejemplo, mediante intercambiar los Datos de Conexión vía el Servicio CDX 1 10). Alternativamente, los dispositivos móviles 601 , 603 pueden implementar las transacciones del Establecimiento de Conectividad a la Internet estándares ("ICE") para intercambiar los datos de conexión. Sin considerar como el canal primario se establece, una vez, 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 en la Figura 6 incluye el enlace de comunicación 606 y el enlace de comunicación 609, entonces esta conexión, una vez establecida puede usarse 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 en el canal de comunicación primario pueden incluir los Datos transversales NAT y los datos Tipo NAT para NAT 61 1 y NAT 613, incluyendo los puertos/direcciones IP públicas y privadas para cada uno de los dispositivos móviles.

Una vez que los canales de comunicación secundarios se han establecido, se mantienen abiertos usando los paquetes heartbeat. Por ejemplo, el dispositivo A puede transmitir periódicamente un paquete "heartbeat" pequeño al dispositivo C y/o al dispositivo A puede transmitir periódicamente un paquete "heartbeat" pequeño al dispositivo C para asegurar que los puertos NAT usados para los canales secundarios permanecen abiertos (los NATs comúnmente cierran los puertos debido a la inactividad). Los paquetes heartbeat pueden ser los paquetes UDP sin Carga Útil, aunque los principios subyacentes de la invención no se limitan a cualquier formato de paquete particular. Los paquetes heartbeat pueden ser los paquetes UDP con un campo de tipo de auto-identificación en su encabezado de carga útil y puede contener información formateada adicionalmente opcional incluyendo pero no limitada a un canal de valor de tiempo en vivo.

Como se ilustra en la Figura 7, cada dispositivo móvil 601 almacena y mantiene una estructura de datos 710 (por ejemplo, una tabla, archivo de texto, base de datos, etc.) conteniendo una lista de canales de comunicación primarios y secundarios. Una entrada separada se proporciona para cada canal de comunicación e incluye los datos de conexión necesarios para usar ese canal (por ejemplo, dirección IP pública/privada, tipo NAT, etc.) y el estado actual de ese canal (por ejemplo, primario, secundario 1 , secundario 2, etc.).

En una modalidad, las interfases de comunicación 701 y 702 se usan para comunicarse en el enlace de comunicación 605 y el enlace de comunicación 606 respectivamente. Un módulo de detección de falla 705 puede ejecutarse en el dispositivo móvil 601 para detectar cuando una interfase/enlace de comunicación particular ha fallado o se ha degradado debajo de un inicio especificado. En respuesta, un módulo de manejo de enlace 706 puede leer los datos de conexión primarios/secundarios 710 para promover un canal secundario que tiene la siguiente prioridad más alta para el canal primario. La p orización de los canales secundarios puede llevarse a cabo usando los mismos principios como aquellos divulgados anteriormente para los canales primarios (es decir, basados en el ancho de banda, costo, confiabilidad, etc.). Una vez que un canal secundario se ha seleccionado, el módulo de manejo de enlace 706 puede transmitir una indicación de falla del enlace a los módulos de manejo de enlace en los otros dispositivos móviles, instruyendo a aquellos dispositivos para promover el canal de comunicación secundario a un canal de comunicación primario. Aquellos dispositivos posteriormente iniciaran los datos de conexión asociados con el canal primario seleccionado.

En una modalidad, una "falla" completa del canal de comunicación primario no se requiere para forzar un intercambio a uno de los canales de comunicación secundarios. Por ejemplo,- en una modalidad, si el canal de comunicación primario es suficientemente degradado (por ejemplo, debajo de un ancho de banda particular, tasa de bits, o inicio personalizado), posteriormente un cambio a un canal secundario puede implementarse como se describe en este documento. En una modalidad, el intercambio al canal secundario solamente se realiza si el canal secundario es capaz de soportar mejor el funcionamiento (es decir, ancho de banda, tasa de bits o contabilidad) que el canal primario actual.

La Figura 8a ilustra la misma configuración de red 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 privada 620. La red privada 620 puede ser, por ejemplo, una conexión Bluetooth PAN entre el dispositivo B 602 y el dispositivo C 603. Puede observarse de este ejemplo que el intercambio de un canal primario a un canal secundario puede alterar dramáticamente la topología de la red. Por ejemplo, como se muestra en la Figura 8b, si los canales primarios 801 para los dispositivos móviles incluyen el enlace de comunicación 609 (resultando en conexiones directas entre los dispositivos A, B y C) y los canales secundarios incluyen la red privada 620, entonces la topología de la red puede cambiar como se ilustra en la Figura 8c porque solamente el solo camino para el dispositivo A y el dispositivo C para comunicarse usando la red privada es a través del dispositivo B. Mientras que esto es un ejemplo simplificado con solo tres dispositivos, un número significantemente mayor de dispositivos puede usarse, resultando en una variedad de configuraciones de topología de red diferentes cuando se intercambia entre canales de comunicación primarios y secundarios.

La invitación 1 101 también puede incluir un código ID identificando el dispositivo móvil A 120 y el NAT transversal/datos de conexión asociados con el dispositivo móvil A (por ejemplo, las Direcciones IP públicas/privadas y los puertos para el dispositivo móvil A y el Tipo NAT para el dispositivo NAT del dispositivo A). El NAT transversal/datos de conexión o los datos tipo NAT pueden haber sido previamente determinados por el dispositivo móvil A antes de la solicitud de invitación 1 101 (por ejemplo, vía el NAT transversal, el tipo NAT y las transacciones de los datos de conexión tales como aquellas anteriormente divulgadas con respecto a las Figuras 2a-c). Como se mencionó previamente, la solicitud de invitación 1 101 puede tomar la forma de una solicitud HTTPS. En adición, para seguridad adicional, la solicitud de invitación 1 101 puede incluir un certificado de cliente firmado por una autoridad certificada pre-específica.

" Sin importar el tipo particular del código ID usado para identificar el dispositivo móvil B, el Código ID se recibe por el servicio de invitación 1 12 y, en 1 102, el servicio de invitación 1 12 puede realizar una búsqueda en el servicio de directorio 1052 (no mostrado en la Figura 1 1 ) para identificar un identificador de la cuenta del servicio de notificación tal como un componente léxico push usado para enviar las notificaciones al dispositivo móvil B ("envio-componente-B"). En una modalidad, las operaciones de búsqueda pueden realizar varias verificaciones para determinar si la invitación debe permitirse. Primero, puede confirmar que el código de identificación para el dispositivo móvil A ("ID-A") y el componente léxico push del dispositivo A ("envío-componente-A") son una asociación registrada dentro de la base de datos del servicio de directorio. La operación de búsqueda 1 102 también puede confirmar que el usuario del dispositivo móvil A está permitido para invitar la usuario del dispositivo móvil B (por ejemplo, el usuario del dispositivo móvil B puede especificar que solamente aquellos usuarios registrados como amigos de B pueden invitar al usuario B o puede especificar que no se permiten invitaciones). En una modalidad, si cualquiera de estas verificaciones falla, la invitación se cancela, y el servicio de invitación 1 12 regresa un error al dispositivo móvil A.

Mientras un "componente léxico push" se describe en esta modalidad, debe notarse que los principios subyacentes de la invención no están limitados al uso de un "componente léxico push" o cualquier otra estructura de datos particular para autentificar y enviar las notificaciones a los dispositivos móviles.

En una modalidad, después de que el componente léxico push se ha identificado, el servicio de invitación 1 12 puede generar un "componente léxico de sesión" seguro de un solo uso, asignado a la sesión de invitación y usada para identificar la sesión en todas las transacciones adicionales. Una copia del componente léxico de sesión posteriormente se transmite de nuevo al dispositivo móvil A 120 y envía al dispositivo móvil B con la solicitud de invitación. En una modalidad, el componente léxico de sesión se usa junto con la estructura de datos de entrada anteriormente descrita y en otra modalidad solo el componente léxico de sesión se usa.

En 1 103, el servicio de invitación 1 12 transmite una solicitud püsh al servicio de notificación push 1050. En una modalidad, la solicitud push puede incluir los datos transversales NAT para el dispositivo móvil A, el código ID del dispositivo A, el envío-componente-A, el código ID del dispositivo B, y envio-componente-B. En una modalidad, esta información puede empacarse dentro de una estructura de datos de "entrada" y encriptarse como se describió anteriormente. En otra modalidad, los datos simplemente se transmiten con el ID de la sesión de invitación.

Porque el dispositivo móvil B 121 en este ejemplo se ha registrado con el servicio de notificación push 1050, el servicio de notificación push 1050 es capaz de localizar y enviar la solicitud de invitación al dispositivo móvil B 121 en 1 104. La invitación enviada 1 104 puede incluir el componente léxico de sesión, los datos transversales NAT /datos de conexión del dispositivo móvil A y el código ID 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, NAT transversal/datos de conexión, tipo NAT, etc.) mediante hacer una llamada a un servicio transversal NAT o el servicio CDX 1 10 como se describió anteriormente.

En 1 05, el dispositivo móvil B acepta la invitación. La aceptación 1 105 puede tomar la forma de una llamada HTTPS al servicio de invitación 1 12 y puede incluir un certificado de cliente firmado por la autoridad certificada pre-especificada (anteriormente mencionada con respecto a la solicitud de invitación). En una modalidad, la aceptación 1 05 puede incluir el código ID para los dispositivos móviles A y B y el NAT transversal/datos de conexión y/o tipo NAT para los dispositivos móviles A y B. La aceptación 1105 también puede incluir componentes léxicos push para los dispositivos móviles A y B y/o el componente léxico de sesión. En una modalidad, la aceptación 1 105 también puede contener una indicación como si fuera una recuperación de un intento de conexión directa previamente fallado. Sin embargo, en otra modalidad, la aceptación 1 105 no contiene la indicación de recuperación. Más bien, en la detección de un intento de conexión P2P fallado, uno de los dos dispositivos móviles puede transmitir una "invitación de retransmisión" especial al servicio de invitación 1 12. En respuesta, el servicio puede iniciar directamente las series de transacciones de retransmisión posteriormente descritas con respecto a la Figura 12 (iniciando en 1201 ).

Una modalidad de un método para establecer y mantener los canales secundarios se ilustra en la Figura 8. En una modalidad, el método puede ejecutarse por el módulo de manejo de enlace 706 en cada dispositivo móvil. Sin embargo, el método no se limita a ninguna configuración de dispositivo particular.

En 901 , un canal de comunicación P2P primario se selecciona. Como se mencionó anteriormente, el canal primario puede seleccionarse con base en un esquema de priorización predefinido. Por ejemplo, ciertos tipos de canales de comunicación pueden priorizarse arriba de otros tipos de canales de comunicación. Los canales también pueden priorizarse con base en las variables tales como ancho de banda, costo de uso y/o confiabilidad.

En 902, los canales de comunicación P2P de respaldo se establecen. En una modalidad, esto se lleva a cabo mediante compartir los datos de conexión entre todos los dispositivos móviles en el canal de comunicación primario. En 903, los canales de respaldo se mantienen. En una modalidad, esto involucra la transmisión de datos periódicamente en los canales de comunicación secundarios (por ejemplo, en la forma de paquetes heartbeat periódicos.

En 904, si el canal P2P primario falla (por ejemplo, porque el enlace de comunicación de un dispositivo móvil particular se vino abajo o el dispositivo móvil se movió fuera del rango del enlace de comunicación), entonces en 905, los dispositivos móviles promueven el canal de respaldo de más alta prioridad al canal primario. En una modalidad, esto involucra el dispositivo móvil con el enlace con falla transmitiendo una notificación de su falla de enlace a los otros dispositivos en el canal secundario. Finalmente, en 906, el canal de respaldo se hace el canal primario y el proceso se revierte en 902 (en el cual cualquier canal de respaldo adicional se descubre y agrega al esquema de priorización.

APARATO Y MÉTODO PARA UN SERVICIO DE INVITACIÓN PARA ESTABLECER CANALES DE COMUNICACIÓN PUNTO A PUNTO (P2P) Como se ilustra en La Figura 10, además del Servicio CDX 1 10, el servicio intermediario 1 1 1 y el servicio de invitación 1 12 (algunas modalidades de los cuales se describió anteriormente), una modalidad de la invención puede incluir un servicio de registro/directorio 1052, un servicio de notificación push 1050, y un servicio de retransmisión 1051 . Como se mencionó anteriormente, en una modalidad, el servicio de invitación 1 12 y/o el servicio intermediario 1 1 1 puede usar el servicio de registro/directorio 1052 para identificar los dispositivos móviles registrados y el servicio de notificación push 1050 para enviar los datos a los dispositivos móviles. En una modalidad, cuando un dispositivo móvil se activa en la red, registra un "componente léxico push" (algunas veces referido como un "identificador de cuenta de servicio de notificación" en la Aplicación de Notificación Push) con una base de datos mantenida por el servicio de registro/directorio 1052 mediante asociar el componente léxico push con un ID de usuario protegido por contraseña o un número telefónico. Si el componente léxico push se identifica en el directorio de registro (por ejemplo, mediante realizar una consulta con el ID del usuario), el servicio de notificación push 1050 puede usar el componente léxico push para transmitir las notificaciones push a un dispositivo móvil. En una modalidad, el servicio de notificación push es el Servicio de notificación push de Apple ("APNS") designado por el cesionario de la presente solicitud y se describe, por ejemplo, en la Solicitud de Notificación Push anteriormente referenciada.

La Figura 1 1 ilustra una modalidad de la invención en la cual el servicio de notificación push 1051 se usa para establecer una conexión P2P directa entre dos dispositivos móviles y la Figura 12 ilustra una modalidad que se usa para establecer una conexión P2P a través del servicio de retransmisión 1051. Como se describirá posteriormente, la decisión de si se usa el servicio de retransmisión 1051 para establecer una conexión P2P puede basarse en la factibilidad de establecer una conexión P2P directa entre los dispositivos móviles (por ejemplo, con base en los asuntos de compatibilidad NAT), Regresando ahora a la Figura 1 1 , en 1 101 , el 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 video juego de colaboración, un video chat P2P, etc.)- En una modalidad, la invitación incluye un código ID de usuario identificando 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 particular. Por ejemplo, el código ID de usuario puede ser el ID del jugador para un jugador múltiple particular, el juego P2P y puede tomar la forma, por ejemplo, de un Identificador Universalmente Único (UUID). Alternativamente, en algunas modalidades, el código ID puede ser un número telefónico del dispositivo móvil B 121 . Un código ID del juego puede usarse para identificar el juego de múltiples jugadores que ese dispositivo móvil A está invitando al dispositivo móvil B a unirse. Un ID de celda puede usarse para identificar una configuración para ese juego (como se describe en este documento con respecto al servicio intermediario).

En 1 106, el servicio de invitación 1 12 puede realizar una verificación de compatibilidad para determinar si una conexión P2P directa entre los dispositivos móviles A y B es factible. Por ejemplo, en una modalidad, si la aceptación 1 105 recibida del dispositivo móvil B indica que es una recuperación de un intento de conexión directa fallado previo (o un número especifico de intentos de conexión directa previos fallados), entonces el servicio de invitación puede concluir que una conexión P2P directa no es factible El servicio de invitación 1 12 puede comparar los datos tipo 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 modalidades de los tipos NAT se conocen por ser incompatibles para establecer conexiones P2P. Por ejemplo, un cono completo NAT puede usarse con cualquier otro tipo NAT excepto un NAT con corta fuegos/cerrada para establecer una conexión P2P directa. En contraste, un NAT simétrico solamente puede usarse con un cono NAT completo para establecer una conexión P2P directa. La factibilidad de combinar varios tipos NAT en una modalidad de la invención se establece en la Tabla de compatibilidad NAT 1400 mostrada posteriormente, en la cual las columnas representan los tipos NAT de un dispositivo móvil (por ejemplo, el dispositivo móvil A) y las filas representan los tipos NAT del otro dispositivo móvil (por ejemplo, el dispositivo móvil B). Un "1.0" en una celda indica que los tipos NAT en la fila asociada y la columna son compatibles y un "0.0" indica que los tipos NAT son incompatibles.

TABLA DE COMPATIBILIDAD 1400 En una modalidad, si la verificación de compatibilidad 1 106 determina que una conexión P2P directa no es factible, entonces el servicio de invitación 12 puede transmitir una solicitud de búsqueda de retransmisión 1201 como se' describirá posteriormente con respecto a la Figura 12. Si, sin embargo, la verificación de compatibilidad 1 106 determina que una conexión P2P directa es factible, entonces el servicio de invitación 1 12 puede transmitir una solicitud push 1 107 al servicio de notificación push 1050 conteniendo la aceptación del dispositivo móvil B a la invitación del dispositivo móvil A. La solicitud push 07 y la comunicación push subsecuente 1 08 para el dispositivo móvil A del servicio de notificación push 1050 puede incluir el componente léxico de sesión y ambos componentes léxicos push del dispositivo móvil A y B, el código ID, y/o el NAT transversal/datos de conexión. En una modalidad, esta información puede empacarse dentro de la estructura de datos de "entrada" anteriormente descrita (ver, por ejemplo, las Figuras 2a-c y el texto asociado) y puede encriptarse usando una clave única. Alternativamente, esta información puede simplemente transmitirse con un ID de sesión de invitación única. El servicio de invitación 1050 también puede notificar al dispositivo móvil B que una conexión directa se intentará.

En esta etapa, los dispositivos móviles A y B tienen suficiente información para establecer una conexión P2P directa. En una modalidad, esto se lleva a cabo usando el Servicio CDX 1 10 como se describió anteriormente. Por ejemplo, el dispositivo móvil B agrega sus datos de conexión a la Entrada B y en 1 109, transmite la Entrada B (con los datos de conexión) al Servicio CDX. Justo antes de esta transacción, el dispositivo móvil B puede implementar una transacción tal como la transacción 235 mostrada en la Figura 2b para asegurar que sus datos de conexión son actuales. El Servicio CDX 1 10 entonces autentifica la entrada (por ejemplo, usando la Clave de Sesión única como se describió anteriormente), extrae los datos de conexión del dispositivo móvil B y renvla los datos de conexión al dispositivo móvil A en 1 1 10. Similarmente, el dispositivo móvil A agrega sus datos de conexión a Entrada A y en 1 11 , transmite la Entrada A (con los datos de conexión) al servicio CDX 10. Justo antes de esta transacción, el dispositivo móvil A puede implementar una transacción tal como la transacción 232 mostrada en la Figura 2b para asegurar que sus datos de conexión están actuales. El Servicio CDX 1 10 entonces autentifica la entrada (por ejemplo, usando la clave de sesión única como se describió anteriormente), extrae los datos de conexión del dispositivo móvil A y renvía los datos de conexión al dispositivo móvil B en 1 1 12. Finalmente, en 1 1 13, los dispositivos móviles A y B ingresan en una conexión P2P directa usando los datos de conexión intercambiados.

Regresando ahora a la Figura 12, si la verificación de compatibilidad 1 106 determina que una conexión P2P directa no es factible, entonces el servicio de invitación 1 12 puede transmitir una solicitud de búsqueda de retransmisión 1201 al servicio de retransmisión 1051 para determinar un host de retransmisión para usarse para cada dispositivo móvil. La solicitud 201 puede contener la información de red para los dispositivos móviles A y B (por ejemplo, NAT transversal/datos de conexión y/o datos Tipo NAT) que se usa por el servicio de retransmisión 1051 para seleccionar los host de retransmisión apropiados para ambos de los dispositivos móviles. Como se ilustra en la Figura 13, una modalidad del servicio de retransmisión 1051 incluye una pluralidad de hosts de retransmisión 1302-1303 y una base de datos del host de retransmisión 1301 conteniendo la información de red relacionada a cada uno de los hosts de retransmisión. El servicio de invitación 1 12 transmite una solicitud de búsqueda de retransmisión 1201 a un servicio de búsqueda de retransmisión 1300, que solicita la base de datos del host de retransmisión 1301 usando la información de red para los dispositivos móviles A y B. Al recibir los resultados de la base de datos, el servicio de búsqueda de retransmisión 1300 proporciona una respuesta 1202 identificando los host de retransmisión seleccionados 1302-1303.

En una modalidad, la respuesta de búsqueda de retransmisión 1202 contiene un componente léxico de retransmisión generado por el servicio de retransmisión y las direcciones de red (Direcciones IP/puertos) de los hosts de retransmisión 1302-1303 para usarse por los dispositivos móviles A y B para la conexión de retransmisión. En una modalidad, el componente léxico de retransmisión se asocia con la sesión de retransmisión y se usa por los hosts de retransmisión 1302-1303 para autentificar los dispositivos móviles A y B en la conexión al servicio de retransmisión 1051 . El componente léxico puede tomarse en varias formas, incluyendo por ejemplo,' el código de ID de sesión de retransmisión de ID único, un certificado digital y/o una clave de encriptación única asociada con la sesión de retransmisión.

En 1203, el servicio de invitación transmite una respuesta de retransmisión 1203 al dispositivo móvil B 121 conteniendo una indicación de que una conexión de retransmisión se hará. En una modalidad, la respuesta de retransmisión 1203 puede incluir el componente léxico de retransmisión y la información de red para el host de retransmisión B 1303. En una modalidad, la respuesta 1203 puede enviarse directamente al dispositivo móvil B (derivando el servicio de notificación push 1050) porque está siendo enviado en respuesta a la aceptación del dispositivo móvil B 1 105.

El servicio de invitación 1 12 transmite la respuesta de retransmisión 1204 al dispositivo móvil A el cual puede incluir el componente léxico de retransmisión y la información de red para el host de retransmisión B 1303. En este ejemplo, la respuesta 1204 se envía al dispositivo móvil A vía el servicio de notificación push 1050 en la transacción 1205.

En 1206, el dispositivo móvil A 120 usa la información de red para el host de retransmisión A 1302 para establecer una conexión con el servicio de retransmisión 1051 . Similarmente, en 1207, el dispositivo móvil B 121 usa la información de red para el host de retransmisión B 1303 para establecer una conexión con el servicio de retransmisión 1051 . En cada una de estas transacciones, nuevos accesos se abren en cualquier corta fuegos de NAT de los dispositivos móviles A y B y el NAT transversal/datos de conexión para los dispositivos móviles A y B pueden determinarse por el servicio de retransmisión 1051 y regresarse a los dispositivos móviles A y B, respectivamente (por ejemplo, mediante determinar la IP pública/puerto para los dispositivos). En una modalidad, el servicio de retransmisión 1051 y los dispositivos móviles A y B implementan el protocolo de NAT de Retransmisión Usando el Transversal ("TURN") que se entiende por aquellos expertos en la técnica, permite un elemento detrás de un NAT ó corta fuegos para recibir los datos entrantes en las conexiones TCP o UDP.

En 1208, el dispositivo móvil A transmite una actualización de retransmisión al servicio de invitación 2 que se renvía al servicio de notificación push en 1209 y se envía al dispositivo móvil B en 1210. Similarmente, en 121 1 el dispositivo móvil B transmite una actualización de retransmisión al servicio de invitación 1 12 que se renvía al servicio de notificación push en 1212 y se envía al dispositivo móvil A en 1213. La actualización de retransmisión transmitida por el dispositivo móvil A puede incluir el componente léxico de sesión, cada código ID del dispositivo y el NAT transversal/datos de conexión determinados por la retransmisión en 1206 y 1207 (es decir, con el dispositivo móvil A enviando su NAT transversal/datos de conexión al dispositivo móvil B y viceversa). En una modalidad, las operaciones de actualización de retransmisión se realizan porque la información de cada NAT del 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 retransmisión 1051 . En una modalidad, las conexiones de retransmisión pueden establecerse cuando el dispositivo móvil A envía el NAT transversal/datos de conexión del dispositivo móvil B al servicio de retransmisión 1051 , y viceversa, por lo tanto permitiendo al servicio de retransmisión determinar la ruta correcta para cada host de retransmisión del punto 1302-1303.

Usando las técnicas anteriormente descritas, el servicio de invitación 1 12 puede ser implementado como un servicio apatrida que es inherentemente escalable y flexible, incluso en un sistema a gran escala con un vasto número de dispositivos móviles. Por ejemplo, porque el servicio de notificación push 1050 es inherentemente capaz de localizar y enviar el contenido a los dispositivos móviles registrados, el servicio de invitación no se requiere que rastree la ubicación actual de cada dispositivo. Adicionalmente, porque los dispositivos pueden transmitir los datos completos del estado de la sesión con cada solicitud y respuesta, el servicio de invitación nunca se requiere para mantener cualquier información de estado por conexión, por lo tanto reduciendo los requerimientos de procesamiento y almacenaje del servicio de invitación. Dicha implementación es particularmente útil en un sistema a gran escala.

SISTEMA Y MÉTODO PARA CONCORDAR USUARIOS PARA SESIONES EN LÍNEA.

Como se ilustra en la Figura 14, una modalidad de un servicio intermediario 1 1 1 puede incluir un despachador intermediario 1501 para recibir las solicitudes de correspondencia y enviar las respuestas de correspondencia a los dispositivos móviles 120-122; una base de datos 1512 para almacenar las solicitudes de correspondencia en una tabla de solicitudes 1502 y para almacenar los datos establecidos como correspondientes en una tabla del identificador del juego correspondiente ("MSI") 1503 y uno o más intermediarios 1510 para retomar las solicitudes de correspondencia de la base de datos 1512, realizando operaciones de correspondencia y almacenando los resultados de correspondencia de nuevo en la base de datos 1512. Debe notarse, sin embargo, que los principios subyacentes de la invención no están limitados a la arquitectura específica mostrada en la Figura 14.

En una modalidad, el despachador intermediario 1501 actúa como una interfase para el servicio ¦ intermediario 1 1 1 , recibiendo las solicitudes de los dispositivos móviles 120-122, traduciendo aquellas solicitudes en comandos para almacenar las solicitudes en la base de datos 1512, leyendo los resultados de correspondencia de la base de datos 1512, y traduciendo y comunicando aquellos resultados a los dispositivos móviles 120-122.

En operación, cuando llega una nueva solicitud de correspondencia, el despachador intermediario 1501 puede almacenar la solicitud dentro de la tabla de solicitudes 1502. En una modalidad, el expendedor 1501 asigna a cada solicitud de correspondencia un código ID de solicitud ("RID") ilustrado simplemente como "A," "B" y "C" en la Figura 14 (correspondiente a los dispositivos móviles A, B y C, respectivamente). Mientras se muestra usando una designación de letras en la Figura 14 por simplicidad, el código RID puede ser un número entero o cualquier otra variable para seguir las solicitudes de correspondencia dentro de la base de datos.

Cada solicitud de correspondencia puede asignarse a un valor de identificador de juego correspondiente ("MSI") que se almacena en la tabla de solicitudes 1502. En una modalidad, el MSI puede identificar la aplicación particular para la cual una correspondencia está siendo solicitada y/o los parámetros de configuración a usarse para esa aplicación. Por ejemplo, un valor MSI de 12:4 puede identificar un juego de múltiples jugadores particulares con el identificador "12" y puede identificar una configuración particular para el juego con el identificador "4". Más específicamente, el código ID del 12 puede identificar un juego de carreras de jugadores múltiples y el código ID de 4 puede especificar una pista de carreras particular, la velocidad, o el nivel de experiencia del jugador para el juego de carreras. En una modalidad, los desabolladores de la aplicación proporcionan la opción de especificar cualquier parámetro de configuración de la aplicación usando los valores MSI de esta manera. En una modalidad, más bien especificar un MSI directamente, los desarrolladores de la aplicación especifican un ID de juego (para identificar un juego particular) y un ID de celda (para identificar una configuración de juego particular) y estos valores se mapean a un valor MSI mediante el despachador intermediario 1501 .

Adicionalmente, varios valores MSI diferentes pueden usarse dentro de un solo MSI para especificar múltiples parámetros de configuración (por ejemplo, 12:4: 1 puede- representar: 12 = juego de carreras; 4 = camino; y 1 = nivel de experiencia). Como se describe posteriormente en detalle, en una modalidad, cada MSI se usa por un intermediario 1510 para identificar un juego de solicitudes en las cuales las operaciones de correspondencia pueden realizarse (es decir, las solicitudes se agrupan con base en el MSI y las correspondencias se realizan dentro de cada grupo MSI). En una modalidad, cada MSI puede modificarse/seleccionarse dinámicamente por el despachador para incluir un ID de partición identificando las diferentes particiones de la máquina. Por ejemplo, si un MSI llega a sobrecargarse, el despachador puede dividir el MSI entre dos o más diferentes servidores y/o particiones de almacenaje (por ejemplo, usando las designaciones tales como 4:3:1 y 4:3:2 en donde los últimos dígitos identifican las particiones 1 y 2, respectivamente). Un intermediario diferente posteriormente independientemente recupera y procesa las solicitudes de cada uno de los diferentes MSIs de cada uno de los servidores diferentes.

Como se ¡lustra en la Figura 14, los datos de la solicitud de correspondencia también se almacenan dentro de la tabla de solicitudes 1502 para cada solicitud. Los datos de solicitud pueden incluir cualquier dato usable para obtener una decisión de correspondencia y/o cualquier dato necesario para accesar al dispositivo móvil iniciando la solicitud en la red. Por ejemplo, en una modalidad, los datos de solicitud de correspondencia para cada solicitud incluyen los datos del tipo de NAT y/o los datos de conexión/NAT transversal para el dispositivo móvil iniciando la solicitud. Otros tipos de datos de solicitud también pueden almacenarse dentro de la tabla de solicitudes 1502 tal como la velocidad de conexión del dispositivo (100kbps, 1 Mbps, etc), tipo de conexión (por ejemplo, 3G, EDGE, WiFi, etc), ubicación del dispositivo (por ejemplo, determinada por las técnicas de geo-localización), idioma (Inglés, Español, etc.) y/o las preferencias del usuario. Los datos de la solicitud pueden determinarse por cada dispositivo móvil 120-122 y transmitirse al despachador de correspondencia 1501 con cada solicitud de correspondencia. Por ejemplo, cada dispositivo móvil puede determinar sus datos de conexión, el tipo de conexión, la ubicación del dispositivo, etc. usando varias técnicas, algunas de las cuales se describen en este documento (por ejemplo, comunicándose con un servidor transversal NAT para determinar los datos de conexión/NAT transversal usando GPS para determinar la ubicación del dispositivo, información de lectura HTTP para determinar el idioma, etc).

Como se ilustra en la Figura 14, en una modalidad cada MSI activo puede asignarse a una fila en la tabla MSI 1503. En una modalidad, cuando una nueva solicitud llega, además de agregar la solicitud a la tabla de solicitudes 1502, el despachador 1501 también verifica la tabla MSI 1503 para determinar si un MSI ya existe para esa solicitud (es decir, si otras solicitudes que tienen el mismo MSI ya han sido recibidas). Si no se encuentra una correspondencia MSI, entonces el despachador 1501 puede crear una nueva entrada en la tabla MSI 1503 para la nueva solicitud.. Si una correspondencia MSI se encuentra, entonces el despachador puede simplemente agregar la nueva solicitud a la tabla de solicitudes 1502 como se describió anteriormente.

Una vez que la tabla de solicitudes 1502 y la tabla MSI 1503 se actualizan por el despachador intermediario 1501 , un ejemplo de un módulo intermediario 1510 (de aquí en adelante referido simplemente como "intermediario 1510") recupera los datos para realizar las operaciones de correspondencia. Los ejemplos de intermediario múltiple pueden ejecutarse concurrentemente para realizar las solicitudes de correspondencia y un solo intermediario 1510 puede procesar concurrentemente las operaciones de correspondencia múltiples en grupos múltiples MSI diferentes.

En una modalidad, cuando el intermediario 1510 llega a estar disponible (es decir, después de completar las operaciones de correspondencia para un grupo MSI o después de ser iniciado), solicita la tabla MSI 1503 para identificar un nuevo MSI para procesar. En la Figura 14, el valor "N/A" en los campos de ID del intermediario para MSI 3:1 indican que la responsabilidad para el procesamiento de este MSI no ha sido asignado a un intermediario. En una modalidad, cada entrada MSI se estampa en tiempo y el intermediario 1510 selecciona un MSI teniendo la estampa de tiempo más antigua.

En una modalidad, cuando un intermediario 1510 asume la responsabilidad para un MSI particular, actualiza su código de ID de intermediario en la Tabla de MSI 1503 y especifica una duración de la concesión para ese MSI (por ejemplo, 5 segundos). En una modalidad, el intermediario 1510 continuamente actualiza el valor de concesión como proceden las correspondencias para ese MSI. El valor de concesión puede usarse para identificar los MSIs que fueron asignados a intermediarios con fallas 1510. Por ejemplo, si el valor de concesión ha expirado, ese MSI puede reclamarse por un nuevo intermediario no importando el hécho de que la tabla MSI 1503 indica que el MSI ya se asignó a un intermediario.

Una vez que el intermediario 1510 ha asumido la responsabilidad para un MSI, puede consultar la tabla de solicitudes 1502 para leer las solicitudes asociadas con ese MSI en la memoria. El intermediario 1510 puede entonces realizar las operaciones de correspondencia para corresponder a los usuarios y los dispositivos móviles de acuerdo con un juego de criterios de correspondencia (por ejemplo, como se describe posteriormente). El intermediario 1510 puede actualizar la tabla de solicitudes 1512 para indicar cuando las correspondencias del dispositivo móvil se han hecho. Por ejemplo, el intermediario puede remover los valores MSI de la columna MSI en la tabla de solicitudes 1512 e ingresar un valor predefinido para indicar que la correspondencia se ha completado. Además, el intermediario 1510 puede actualizar el campo de "datos de solicitud" para cada participante para identificar los otros participantes con los cuales ese participante fue correspondiente (por ejemplo, mediante escribir el NAT transversal/datos de conexión necesarios para comunicarse con los otros participantes).

El despachador 1501 puede consultar periódicamente la tabla de solicitudes 1502 para identificar las correspondencias completadas. En respuesta a detectar una correspondencia completada, el despachador 1501 puede transmitir una notificación push al dispositivo móvil involucrado en la correspondencia, (por ejemplo, usando las técnicas de notificación push descritas en este documento y en las solicitudes co-pendientes), En una modalidad, la notificación push incluye la estructura de datos de "entrada" anteriormente descrita. Los dispositivos móviles pueden entonces usar cada una de sus entradas para intercambiar los datos de conexión .vía el servicio CDX 1 10 como se describió anteriormente.

Además de usar las notificaciones push, en una modalidad, los dispositivos móviles 120- 122 pueden consultar periódicamente el despachador 1501 para determinar si una correspondencia se ha hecho. Las consultas periódicas son útiles en el caso de que la notificación push no se haya hecho al dispositivo móvil. Sin embargo, porque una arquitectura push se usa, las consultas periódicas pueden establecer una proporción relativamente baja, por lo tanto reduciendo la carga en el servicio intermediario 1 1 1 .

La Figura 15 ilustra una modalidad ejemplarizadora de un método en el cual dos dispositivos móviles A y 8, son correspondientes por el servicio intermediario 1 1 1 . Las Tablas 17 a-d ilustran las actualizaciones ejemplarizadoras para la tabla de solicitudes 1502 y la tabla MSI 1503 que puede ocurrir a medida que el método progresa.

TABLA 17a Solicitud Tabla 1502 MSI Tabla 1503 Datos de la RID MSI MSI Concesión JD MM Solicitud Datos de la 1 :1 1 :1 N/A N/A Solicitud A TABLA 17b Solicitud Tabla 1502 MSI Tabla 1503 TABLA 17c Solicitud Tabla 1502 MSI Tabla 503 TABLA 17d Solicitud Tabla 1502 MSI Tabla 1503 En 1601 , una solicitud de correspondencia se recibe del dispositivo móvil A. En 1602, la solicitud del dispositivo móvil A se ingresa en la tabla de solicitudes y una nueva entrada MSI (MSI 1 :1 ) se ingresa en la tabla MSI (si ya no existe), como se ¡lustra en la Tabla 17a. En 1603, una solicitud de correspondencia se recibe del dispositivo móvil B y en 1604, la solicitud de correspondencia del dispositivo móvil B también se ingresa en la tabla de solicitudes como se ¡lustra en la Tabla 17b.

En 1605, una instancia del intermediario particular (intermediario #N) verifica la tabla MSI y detecta que MSI 1 :1 no se ha reclamado por otra instancia del intermediario. Alternativamente, el intermediario puede detectar una entrada de la tabla MSI con una concesión expirada indicando que el intermediario previamente trabajando en la MSI ha fallado. En una modalidad, las entradas MSI con concesiones expiradas proporcionan mayor prioridad que las nuevas entradas MSI (que no han sido aún asignadas a un intermediario). Además, en una modalidad, las entradas MSI relativamente antiguas pueden proporcionar mayor prioridad que las entradas MSI relativamente más nuevas. Sin importar como el intermediario selecciona el MSI, cuando lo hace, agrega su identificador y establece un nuevo valor de concesión para la entrada MSI, como se ilustra en la Tabla 17c (por ejemplo usando un valor de concesión de 5 segundos en el ejemplo ilustrado). El intermediario puede entonces consultar la tabla de solicitudes y leer las entradas de la tabla de solicitudes con ese MSI en la memoria de manera que puedan procesarse.

En 1606, el intermediario realiza una serie de operaciones de correspondencia para seleccionar una correspondencia apropiada para cada una de las solicitudes. Ciertas modalidades de las operaciones de correspondencia se describen posteriormente con respecto a la Figura 16. Brevemente, en una modalidad, las variables que se evalúan para determinar las correspondencias "apropiadas" incluyen el tipo de NAT (por ejemplo, cono completo, puerto restringido, simétrico, etc.), el tipo de conexión (por ejemplo, WiFi, 3G, Edge, etc), el idioma asociado con el usuario (derivado del encabezado de aceptación del idioma de la solicitud HTTP) y la edad de cada una de las solicitudes de correspondencia. En general, el intermediario 1510 puede intentar corresponder los dispositivos móviles que tienen tipos de NAT compatibles (aunque el servicio de retransmisión, algunas veces puede usarse como se describe posteriormente), los mismos tipos de conexión y el mismo idioma. En una modalidad, el intermediario 1510 puede ser más liberal con los requerimiento de correspondencia con base en la antigüedad de las solicitudes de correspondencia (es decir, entre más antigua la solicitud, se aplicará la restricción de correspondencia más liberalmente).

Con referencia a la Figura 15 en 1607, siguiendo la decisión de correspondencia, el intermediario 1510 puede actualizar la tabla de solicitudes para indicar que la correspondencia se completó, como se indica en Tabla 17d. Como parte de la actualización, el intermediario también puede actualizar los datos de solicitud para los dispositivos A y B. Por ejemplo, en una modalidad, el intermediario 1510 escribe los datos de conexión/NAT transversal del dispositivo móvil B en la columna de datos de solicitudes para el dispositivo móvil A y escribe los datos de conexión/NAT transversal del dispositivo móvil A en la columna de solicitudes para el dispositivo móvil B.

En 1608, el despachador 1501 puede leer a través de la tabla de solicitudes para identificar las entradas de solicitudes que son correspondientes. En una modalidad, cuando detecta que los dispositivos móviles A y B son correspondientes, lee los datos de solicitud (actualizados por el intermediario como se describió anteriormente) y genera una notificación para los dispositivos móviles A y B. En una modalidad, la notificación es la estructura de datos' de "entrada" anteriormente descrita que se encripta e incluye los datos de conexión/NAT transversal para cada dispositivo móvil. Como se describió previamente, en una modalidad, el servicio de notificaciones push 1050 se usa para enviar las notificaciones a los dispositivos móviles A y B. Además, los dispositivos móviles A y B pueden encuestar periódicamente al despachador 1501 para determinar si una correspondencia se ha hecho. En esta modalidad, la técnica de encuesta puede hacerse en una proporción relativamente lenta para identificar las correspondencias que, por alguna razón, no fueron enviadas exitosamente a uno de los dispositivos móviles. Usando las notificaciones push para manejar la carga de solicitud de encuesta reduce significantemente la carga en el servicio intermediario 1 1 1 , que de otra manera se cargaría con las solicitudes de encuesta de los dispositivos móviles.

Si solicitudes de correspondencia adicionales están pendientes para el mismo MSI, determinado en 1608, el intermediario puede continuar para corresponder los dispositivos móviles/usuarios dentro del MSI. En 1610, el intermediario puede volver a establecer el valor de concesión dentro de la tabla MSI 1503. En 161 1 , las correspondencias adicionales se realizan y la tabla de solicitudes se actualiza (como se describió anteriormente). En 1612, las correspondencias adicionales se leen de la tabla de solicitudes y los dispositivos móviles adicionales se actualizan (como se describió anteriormente). Si no están pendientes solicitudes de correspondencia para el MSI, entonces en 1609, la entrada MSI se elimina de la tabla MSI (por ejemplo, vía un comando de eliminación del despachador y/o el intermediario).

La Figura 16 ilustra una modalidad de un método para realizar las correspondencias entre los dispositivos móviles/usuarios (operación 1606 en la Figura 15). En 1801 , todas las solicitudes MSI actuales (por ejemplo, para una combinación de celda/aplicación particular) se colocan en pares. En 1802, el "ajuste" de correspondencia entre cada par se evalúa y en 1803, los pares se clasifican por el ajuste descendente. El "ajuste" se evalúa con base en una pluralidad de diferentes variables incluyendo pero no limitados al tipo de NAT (por ejemplo, cono completo, puerto restringido, simétrico, etc.), el tipo de conexión (por ejemplo, , WiFi, 3G, Edge, etc), el idioma asociado con el usuario (derivado del encabezado del idioma-aceptación a la solicitud HTTP) y la antigüedad de cada una de las solicitudes de correspondencia. Otras variables que pueden fabricarse en la decisión de correspondencia incluyen la ubicación de cada uno de los dispositivos móviles (por ejemplo, con un Intento de corresponder a los usuarios en una ubicación particular); requerimientos de jugador máximos y/o mínimos (por ejemplo, especificados por el usuario y/o la solicitud); si uno p más de los usuarios incluidos en el MSI son "amigos" o han ingresado en una conexión P2P previamente (por ejemplo, con una preferencia para corresponder a los "amigos" o los conocidos anteriormente), y la experiencia del usuario con la aplicación (es decir, para un juego de múltiples jugadores, los rangos de las tablas de posiciones de cada uno de los usuarios que se pueden fabricar en ella, con una preferencia para corresponder los usuarios con experiencia similar).

Como se indica en la Tabla A posterior, en una modalidad, la evaluación de la "adaptabilidad" es un valor numérico entre 0.0 y 1 .0. Usando un valor de punto flotante permite la normalización de la adaptabilidad para cada criterio. Para evitar el punto de flotación aritmético, los valores de número entero no normalizados pueden usarse con evaluación apropiada así los valores de la adaptabilidad pueden compararse.

En una modalidad, todos los criterios tienen un ajuste binario en donde ellos son compatibles (teniendo un valor normalizado de 1 .0) o no compatible (teniendo un valor normalizado de menos de 1.0). Estos pueden pensarse como criterios requeridos en donde el ajuste puede cambiar con la edad (como se describe posteriormente). Si la ubicación se agrega como una variable, entonces el mejor ajuste puede ser uno con el jugador más cercano que corresponde al criterio requerido.

Corres ondencia de Ada tabilidad - Tabla A En una modalidad, el Ajuste es correspondiente a la Suma de (Peso Normalizado * Valor de Factor Antiguo) para cada uno de los criterios anteriores. El Valor de Factor Antiguo puede iniciar con un valor de 1 e incrementar después de que ha pasado un periodo predeterminado de tiempo. Posteriormente puede continuar para incrementar como más tiempo pasa (por ejemplo, incrementando periódicamente por una cantidad específica). En una modalidad, en lugar de usar el Valor de Factor Antiguo anteriormente descrito, los inicios de la antigüedad pueden establecerse como se describe posteriormente. Los valores pesados/normalizados de ciertas variables tal como Tipo de Conexión e Idioma pueden aplicarse a ciertos inicios de antigüedad anteriores (incluso si no son correspondientes).

En una modalidad, el "ajuste" entre un par de solicitudes, A y B, es el promedio del ajuste de A con B y B con A. Además, el ajuste de A con B para cada factor puede ajustarse con base en la antigüedad de A (y viceversa). En una modalidad, un ajuste de 1.0 puede requerirse para una correspondencia compatible. Esto significa que A y B solamente se corresponderán si la compatibilidad NAT, el Tipo de Conexión y el Idioma son correspondientes (resultando en un valor normalizado de 1 .0) o si A y/o B son antiguos de manera que algunas de las variables anteriores (por ejemplo, el Tipo de Conexión y el Idioma) se ignoran efectivamente (usando el valor de factor antiguo anterior o los inicios posteriores).

Antigüedad - Tabla B Los inicios de antigüedad pueden establecerse como se establece en la Tabla B anterior. Como cada inicio de antigüedad se pasa (es decir, como la solicitud llega a ser más antigua que el inicio especificado), el valor del factor antiguo puede incrementarse a valores sucesivamente más grandes (es decir, 1 .5, 2.0, etc.). Alternativamente, o en adición, como se pasan los inicios de antigüedad diferentes, los valores pesados para ciertas variables pueden agregarse a la decisión e correspondencia (es decir, tal como el tipo de conexión y el idioma como se describe posteriormente).

En una modalidad, los límites de antigüedad de la solicitud especificados en la Tabla B se ajustan de acuerdo con la proporción del flujo de correspondencia para un MSI dado. En una modalidad, la proporción del flujo se especifica como un número de correspondencias siendo realizadas por una unidad de tiempo específica (por ejemplo, cada 10 segundos, cada minuto, etc.). Además, la proporción del flujo proporciona una indicación de que tan ocupado está un juego de MSI particular. En una modalidad, entre más ocupado el juego, menor cada uno de los inicios anteriores que pueden establecerse en la Tabla B anterior para incrementar la probabilidad de una correspondencia anticipada exitosa y reduce la carga en el intermediario. Además, la carga para un juego MSI dado puede proporcionarse al usuario terminal (es decir, en la forma de un tiempo estimado para el valor de correspondencia), de manera que el usuario terminal pueda seleccionar si intenta ingresar a un juego de jugadores múltiples que está particularmente ocupado. El valor de carga puede proporcionarse al usuario en la forma de una notificación push.

Regresando ahora a cada una de las variables de la Tabla A, en una modalidad, la compatibilidad NAT se determina de la tabla de compatibilidad NAT 1400 anteriormente mostrada. Si dos NATs se determinan para ser compatibles con base en esta tabla, entonces el peso de compatibilidad NAT puede aplicarse.

Tipo de Conexión - Tabla C El tipo de conexión puede evaluarse usando la tabla tal como se muestra anteriormente como la Tabla C. En este ejemplo, si el tipo de conexión de los dispositivos A y B es el mismo (como se indica por un 1 .0 en las celdas en donde los mismos tipos de conexión se juntan), entonces el valor del tipo de conexión pesado de la Tabla A puede incluirse en la determinación de la adaptabilidad. Como se mencionó anteriormente, la antigüedad de cada una de las solicitudes puede usarse para afectar la determinación del tipo de conexión. Por ejemplo, en una modalidad, el valor de ajuste para el tipo de conexión se selecciona usando la matriz en la Tabla C para las antigüedades en el inicio 1 , 2 y 3. Para las antigüedades en el inicio 4 o anteriores, el tipo de conexión puede establecerse en 1 .0 (incluso para los tipos de conexión sin correspondencia) y puede aplicarse el valor del tipo de conexión pesado correspondiente. Mientras el "tipo" de conexión se usa en algunas modalidades, la velocidad de conexión puede determinarse y usarse con, o en lugar del tipo de conexión. Por ejemplo, las velocidades de conexión dentro de ciertos rangos específicos puede considerarse "compatible" (por ejemplo, 0-100kbps; 100-500kbps; 500- 1000kbps, 1000-1500kbps, etc). Cualquiera de las variables de correspondencia divulgadas en este documento, también puede aplicarse como pesos para el cálculo del ajuste de correspondencia y la antigüedad como se describió anteriormente.

En una modalidad, el idioma del jugador puede derivarse del encabezado de idioma-aceptación de la solicitud HTTP que puede contener uno o más idiomas con un factor q de preferencia. El despachador puede extraer el idioma más preferido y pasar esta información al intermediario. En una modalidad, el valor de idioma pesado de la Tabla A se establece a 1 .0 si los idiomas son los mismos o 0.0 si no lo son. Sin embargo, en una modalidad, el valor de idioma pesado puede aplicarse si los idiomas son diferentes si la antigüedad está arriba de un inicio específico (por ejemplo, si la antigüedad está en el inicio 2 o arriba en la Tabla B).

En una modalidad, una correspondencia puede hacerse entre dos usuarios con tipos de NAT no compatibles. Por ejemplo, si el intermediario está teniendo dificultad para corresponder usuarios para un MSI particular, después de un periodo de tiempo específico puede enrutar las conexiones a través del servicio de retransmisión 1051 usando las técnicas anteriormente descritas. En esta forma, el servicio de retransmisión 1051 actúa como una válvula de presión, permitiendo las correspondencias de antigüedad para ocurrir sin importar los tipos NAT no compatibles. El servicio de retransmisión 1051 también puede usarse en respuesta para detectar uno o más intentos de correspondencia fallidos. En esta modalidad, cada solicitud de correspondencia enviada por un dispositivo móvil incluye una indicación como si una o más correspondencias no exitosas se intentaron previamente.

Varios criterios de correspondencia adicionales pueden evaluarse y proporcionar un valor de peso como parte de la determinación de ajuste de correspondencia incluyendo, por medio de ejemplo, y sin limitación, una indicación de si cualquiera de usuarios solicitando las correspondencias son amigos. Por ejemplo, el intermediario 1510 puede intentar corresponder cualquier solicitud para los usuarios quienes son "amigos" mediante aplicar un peso de "amigos" al cálculo de ajuste de correspondencia. Similarmente, los amigos de amigos también pueden pesarse (es decir, con 2 o más grados de separación). Adicionalmente, un jugador puede calificar a otros jugadores para un juego particular y el intermediario puede evaluar aquellas calificaciones cuando se realiza una correspondencia (con una tendencia para corresponder a un usuario con aquellos jugadores quiénes tienen calificaciones relativamente más altas y no corresponder al usuario con jugadores quiénes tienen calificaciones más bajas). Además, la latencia de una conexión de usuario puede evaluarse (es decir, usando una simple operación de ping) y usada como parte de la decisión de correspondencia.

Aún otra variable usada para corresponder a los jugadores puede ser el tipo de dispositivo. Por ejemplo, el intermediario 1510 puede intentar corresponder a los jugadores con tipos de dispositivo similares (por ejemplo, iPads, iPods, ¡Touches, iP ones, RIM Blackberries, etc). Las variables adicionales pueden incluir una clasificación de tablas de posiciones del usuario, ubicación actual, residencia actual, edad, género, y las colecciones similares de juegos pueden ser similarmente evaluadas para la determinación de la correspondencia (es decir, en muchos casos tendiendo a correspondencias a favor entre aquellos usuarios con criterios similares). Finalmente, los controles parenterales pueden evaluarse por el intermediario 1510 para asegurar que los usuarios solamente son correspondientes con MSIs apropiados y con otros usuarios de la misma edad.

El servicio intermediario 1 11 puede recuperar cualquiera de las variables anteriores de una o más bases de datos manejados dentro del servicio de datos 00 (ver, por ejemplo, la base de datos 1920 descrita posteriormente con respecto a la Figura 17). Por ejemplo, los datos de un amigo del usuario puede accesarse de una base de datos del servicio del amigo y otra información tal como la edad de cada usuario, el género, la colección de juegos, etc. puede accesarse desde una o más de otras bases de datos (por ejemplo, un perfil de usuario, una base de datos de juegos, una base de datos de tabla de posiciones, etc.). En una modalidad, todos los servicios descritos en este documento se proporcionan con el acceso a la misma base de datos central (o grupo de bases de datos) para almacenar todo de los varios tipos diferentes de datos del dispositivo/usuario usados para hacer las decisiones de correspondencia.

Mientras varios ejemplos específicos se proporcionaron anteriormente, se apreciará que los principios subyacentes de la invención no se limitan a ningún juego particular de variables para determinar el nivel de adaptabilidad para una correspondencia. En una modalidad, los programadores de la aplicación designando las aplicaciones para correr en el sistema y método descritos en este documento pueden especificar su propio juego de criterios para la correspondencia y/o las solicitudes de agrupamiento usando el diferente criterio MSI.

Regresando ahora al método de la Figura 16, una vez que el "ajuste" de correspondencia entre cada par se ha determinado, en 1803, los pares se clasifican por el ajuste descendente (es decir, con los pares teniendo el ajusta más alto en la cima de la lista). Eri 1804 los "juegos correspondientes" se siembran con aquellos pares que tienen los valores de ajuste más altos arriba del inicio específico. Como se describió anteriormente, el valor de "inicio" puede establecerse al valor normalizado de 1.0 anteriormente mostrado en la Tabla A. En 1805, nuevos compañeros prospectivos se agregan al juego de correspondencia que tienen los valores de ajuste con uno o todos de los miembros actuales en el juego de correspondencia arriba de un inicio específico. Por ejemplo, si un juego de correspondencia ha sido sembrado inicialmente con A y B, entonces C puede agregarse al juego de correspondencia si el valor de correspondencia de A-C y/o B-C está arriba del inicio específico. En una modalidad, si solamente un solo ajuste de correspondencia está arriba de un inicio para una parte prospectiva, entonces esa parte puede agregarse al juego de correspondencia (es decir, porque, si es necesario, que esa parte sea capaz de comunicarse con todas las partes a través de una parte con la cual tiene un ajuste de correspondencia apropiado). Una vez que una o más nuevas partes han sido agregadas al juego de correspondencia, si los requerimientos de tamaño para la correspondencia se han cumplido, determinados en 1806, entonces los resultados de correspondencia se almacenan y reportan en 1807 (por ejemplo, mediante actualizar la tabla de solicitudes 1502 y transmitiendo las notificaciones como se describió anteriormente). En una modalidad, una sola solicitud de correspondencia puede representar múltiples usuarios (por ejemplo, cuando una solicitud de correspondencia sigue una secuencia de invitación como se describe posteriormente). En este caso, los requerimientos de tamaño se evalúan con base en el número de usuarios representados por cada solicitud de correspondencia. Si los requerimientos de tamaño no se han cumplido, entonces el proceso regresa a 1805 y una nueva parte se agrega al juego de correspondencia (es decir, una parte teniendo un ajuste de correspondencia con uno o más de los miembros actuales del juego arriba de un inicio especifico).

En 1808, las solicitudes de correspondencia se remueven del juego actual de las solicitudes siendo procesadas por el intermediario 1510. En 1809 el siguiente juego de correspondencia sembrado se selecciona y el proceso regresa a 1804 para correspondencia adicional. Aunque ilustrado en la Figura 16 como un proceso secuencial debe notarse que los juegos de correspondencia sembrados múltiples pueden procesarse concurrentemente mientras aún se cumple con los principios subyacentes de la invención.

Aunque descrito anteriormente como servicios separados, el servicio intercambiador 1 1 1 y el servicio de invitación 1 12 pueden operar juntos para conectar a los usuarios P2P. Por ejemplo, en una modalidad, un primer usuario puede invitar a uno o más amigos a una sesión en línea y solicitar una correspondencia con uno o más usuarios adicionales (por ejemplo, amigo INVITA a "Bob" y corresponde a 3 jugadores adicionales para un video juego de varias etapas). En dicho caso, el servicio de invitación 1 12 puede procesar inicialmente la solicitud de invitación del primer usuario para conectarse con el primer usuario y los amigos del primer usuario. Los resultados de la solicitud de invitación (por ejemplo, una conexión P2P exitosa) entonces pueden reportarse de nuevo al dispositivo móvil del usuario. El servicio de correspondencia 1 1 1 puede entonces recibir una solicitud de correspondencia del dispositivo móvil del primer usuario (o en una modalidad, directamente del servicio de invitación o del primer amigo del usuario) solicitando jugadores adicionales. En respuesta, el servicio intermediario 1 1 1 puede corresponder el primer usuario con una o más de otras solicitudes de correspondencia teniendo el mismo MSI como la solicitud del primer usuario (como se describió anteriormente). La solicitud de correspondencia puede incluir solamente el criterio de correspondencia del primer usuario o puede incluir el criterio de correspondencia del amigo del primer usuario y del primer usuario (es decir, el tipo de NAT, el tipo de conexión, el idioma, la ubicación, etc.). En una modalidad, si uno o más de los amigos del primer usuario no pueden establecer una conexión P2P directa con otro usuario correspondiente, la conexión del usuario correspondiente con los amigos del primer usuario puede establecerse a través del dispositivo de procesamiento de datos del primer usuario (por ejemplo, usando el dispositivo móvil del primer usuario como un proxy para la conexión) y/o el servicio de retransmisión puede usarse para conectar a los usuarios (como se describió anteriormente).

En una modalidad, el primer usuario inicialmente puede corresponderse con uno o más usuarios mediante el servicio de correspondencia (como se describió anteriormente) y posteriormente el primer usuario puede invitar a uno o más amigos a unirse a la sesión en línea con el primer usuario y los usuarios correspondientes. En esta modalidad, ambas la información del usuario y la información de los usuarios correspondientes (por ejemplo NAT/datos de conexión, IDs de usuario, componente léxico push, etc.) pueden intercambiarse con los usuarios invitados a través del servicio de invitación (como se describió anteriormente). Los principios subyacentes de la invención permanecen siendo los mismos sin importar si la correspondencia ocurre primero, seguida por la invitación o si la invitación ocurre primero seguida por la correspondencia.

RECUADRO DE LA APLICACIÓN CON UNA INTERFASE DE PROGRAMACIÓN DE LA APLICACIÓN PARA LAS APLICACIÓN DE COLABORACIÓN EN LÍNEA Como se ilustra en la Figura 17, una modalidad de la invención se implementa dentro del contexto de un dispositivo móvil 120 teniendo un recuadro de programa predefinido 19 2 con una ¡nterfase de programación de aplicación ("API") 1910 para hacer inferíase con una o más aplicaciones 191 1 y un API de servicio lateral 1910 para comunicarse con una pluralidad de servicios de red 1901 -1903. Como se muestra en la Figura 17, los servicios de red 1901 -1903 pueden diseñarse y/o manejarse por el mismo servicio de datos en linea 100 (aunque dicha configuración no se requiere). Las aplicaciones 191 1 tal como las aplicaciones de juegos P2P y otros tipos de aplicaciones de colaboración en línea pueden diseñarse para accesar a los servicios de red 1901 1903 a través de API 1910 mediante hacer llamadas al API 1910. El diseño de las aplicaciones 19 1 puede facilitarse usando un equipo de desarrollo de equipo ("SDK") proporcionado por el desabollador del recuadro 1912 y los servicios de red 1901 -1903. Una implementación más especifica del recuadro 1910 y APIs 1910, 1913 se describe posteriormente con respecto a la Figura 18.

Como se ilustra, cada uno de los servicios puede proporcionarse con acceso a una base de datos 1920 para almacenar los datos usados por los servicios. Un ejemplo particular es la base de datos 1512 usada por el servicio intermediario 1 1 1 (anteriormente descrito). Otros ejemplos pueden incluir una base de datos de tablas de posiciones para almacenar los datos de la tabla de posiciones, una base de datos del servicio del amigo para almacenar los registros del estado del amigo, una base de datos del perfil para almacenar los datos del perfil del usuario y una base de datos de los juegos para almacenar los datos relacionados a los juegos en línea. Cualquier tipo de bases de datos puede usarse (por ejemplo, MySQL, Microsoft SQL, etc) pero en una modalidad particular, una base de datos de valor/clave tal como Berkley DB y/o MZBasic DB puede usarse. Las bases de datos pueden difundirse a través de un gran número de dispositivos de almacenaje en masa (por ejemplo, discos duros) en una Red de Área de Almacenaje (SAN) u otra configuración de almacenaje.

Consecuentemente, cuando un servicio particular procesa y/o almacena los datos como se describió anteriormente, los datos pueden almacenarse dentro de la base de datos 1920. Algunos servicios, sin embargo, pueden no usar una base de datos. Por ejemplo, como se describió anteriormente, el servicio de invitación 1 12 puede implementarse como un servicio apatrida y por lo tanto, puede no requerir almacenar los datos dentro de una base de datos 1920 (aunque dicha implementación aún es posible de acuerdo con los principios subyacentes de la invención).

El API 1913 puede diseñarse para comunicar e intercambiar la información con los servicios de red 1901 -1903 usando cualquier pila de protocolo de red apropiada incluyendo por ejemplo, TCP/IP o UDP/IP en la capa de red y HTTPS en la capa de la aplicación. Un protocolo basado en (RPC) llamada de procedimiento remoto en HTTP o HTTPS tal como SOAP puede usarse y/o un protocolo de Transferencia de Estado Representacional (REST) puede usarse. Además, los servicios pueden implementarse en cualquier plataforma de computadora incluyendo, por medio de ejemplo, un servidor Xserve o servidores similares corriendo Unix-, Linux o una plataforma de programa Apache. En una modalidad particular, la plataforma incluye objetos Web implementados en Linux. Los ejemplos precedentes se proporcionan solamente para el propósito de ilustración. Los principios subyacentes de la invención no se limitan a ningún mecanismo particular para las aplicaciones de enlace a los servicios o cualquier juego de protocolos de red.

La Figura 18 ¡lustra una arquitectura de programa más detallada incluyendo las interfases de programación de aplicaciones (APIs) 2001 a-b que pueden implementarse en el dispositivo inalámbrico 120 en una modalidad de la invención. Aunque esta modalidad se describe dentro del contexto de un recuadro de juego de jugadores múltiples 2000, los principios subyacentes de la invención no se limitan a una implementación del juego. Por ejemplo, la arquitectura de programa mostrada en la Figura 18 puede usarse para soportar varias aplicaciones de colaboración que no son juegos (por ejemplo, chat de colaboración, audio/video de colaboración de múltiples partes, etc.).

En la arquitectura mostrada en la Figura 18, un recuadro de juego 2000 se proporciona para soportar las varias características de múltiples partes y las características P2P descritas en este documento. En una modalidad, el recuadro de juego 2000 se diseña para correr en el sistema de operación del dispositivo móvil 2005. Por ejemplo, si el dispositivo móvil 120 es un iPhone, ¡Pad, o iPod Touch, el sistema de operación 2005 puede ser el ¡Phone OS, un sistema operativo móvil diseñado por el cesionario de la presente solicitud.

• El recuadro de juego 2000 puede incluir una ¡nterfase de programación de aplicación pública (API) 2001 b y una "segura" o privada API2001a. En una modalidad, una. aplicación de centro de juegos 2031 designada para proporcionar varias características relacionadas con el juego descritas en este documento pueden hacer llamadas para ambas API2001 b y el API2001 a privada, mientras que otras aplicaciones 2030 (por ejemplo, las aplicaciones designadas por terceras partes) se proporcionan con acceso para solamente la API2001 b pública. Por ejemplo, el diseñador del dispositivo móvil 120 puede desear conservar ciertas funciones API que involucra la información potencialmente sensible fuera del API2001 b pública para evitar el abuso por los desarrolladores de la tercera parte (por ejemplo solicitudes de amigos, listas de amigos, etc.). Sin embargo, ambos la API2001 segura y la API2001 b pública pueden emerger dentro de una sola API accesible por todas las aplicaciones en el dispositivo móvil (es decir, la separación de API dentro de los componentes públicos y privados separados no se requiere para cumplir con los principios subyacentes de la invención). La designación "API 2001 " algunas veces se usa debajo para referirse a las operaciones que pueden encontrarse en la API 2001 b pública y/o la API 2001 a privada.

Una modalidad de la aplicación del centro de juegos 2031 se describe en la aplicación co-pendiente titulada Sistemas y Métodos para Proporcionar un Centro de Juegos, No. de Documento del Apoderado 4860.P9127USPI, No. de Serie 61/321 ,861 . Presentada el 7 de Abril, 2010 teniendo los inventores Marcel Van Os y Mike Lampell (de aquí en adelante "Aplicación de Patente de Centro de Juegos"), que se asigna al cesionario de la presente aplicación y que se incorpora en este documento como referencia. Brevemente, la aplicación de centro de juegos 2031 incluye una interfase de usuario gráfico céntrica-de juego (GUI) para navegar a través de los juegos de jugadores múltiples, comprando nuevos juegos, recuperando la información relacionada a los juegos (es decir información de tabla de posiciones, logros, información de amigos, etc.), contactando amigos para jugar los juegos; solicitar las correspondencias de juego con los otros usuarios e invitar a usuarios específicos. Varias otras funciones realizadas por la aplicación de centro de juego 2031 se describen en la Solicitud de Patente de Centro de Juegos anteriormente referenciada. Algunas de las funciones del centro de juegos pueden proporcionarse por el recuadro de juegos 2000 y hacerse accesible a las otras aplicaciones 2030 a través del API pública 2001 b.

En una modalidad, la API2001 expuesta por el recuadro de juegos 2000 simplifica el proceso para designar jugadores múltiples, juegos de colaboración para el dispositivo móvil 120. En particular, en una modalidad, la API 2001 permite a los desabolladores hacer una simple llamada API para invocar el proceso relativamente complejo para conectar a los usuarios para una sesión de juego P2P de jugadores múltiples. Por ejemplo, una simple llamada API tal como INVITAR (Invite) (ID del jugador B, ID de la celda) puede invocarse del API 2001 para iniciar la secuencia de correspondencia detallada anteriormente descrita. Similarmente, una llamada API tal como CORRESPONDER (Match) (ID del jugador A, ID de la celda) puede invocarse de API2001 para iniciar la secuencia de correspondencia detallada anteriormente descrita. Las funciones INVITAR (Invite) e CORRESPONDER (Match) algunas veces generalmente se refieren en este documento como "Funciones de Conexión P2P". En una modalidad, el recuadro de juegos 2000 incluye el código del programa requerido para manejar la invitación y las operaciones de correspondencia en respuesta a estas llamadas API (como se describe en mayor detalle posteriormente). Debe notarse que las funciones API actuales pueden tener un poco de los formatos de datos diferentes que aquellos establecidos anteriormente (aunque pueden resultar en las operaciones similares realizadas por el recuadro de juegos 2000). Los principios subyacentes de la invención no se limitan a cualquier formato particular para especificar las funciones API .

Varios otros tipos de transacciones relacionadas con los juegos y la información también pueden manejarse por el recuadro de juegos 2000 en representación del centro de juegos 2031 y otras aplicaciones 2030. Algo de esta información se describe en la Solicitud de Patente de Centro de Juegos. Por medio de ejemplo y no como limitación, esta información puede incluir información de las "tablas de posiciones" relacionadas a aquellos usuarios quienes han logrado los marcadores más altos para cada juego y la información de "logros" identificando a los usuarios quiénes han completado ciertos logros de juegos específicos. Cada desabollador de la aplicación puede especificar su propio juego de "logros" para cada aplicación del juego 2030 (por ejemplo, niveles completados 1 -3, nivel 1 completado debajo de 5 minutos, con 50 habilidades por nivel; haciendo 20 banderas, etc.).

El recuadro de juegos 2000 también puede incluir el código de programa para manejar los datos de los amigos de un usuario y para la integración de los datos de los amigos dentro del contexto del centro de juegos 2031 y otras aplicaciones de juego 2030. Por ejemplo, cuando el usuario selecciona un enlace para un juego particular dentro del centro de juegos 2031 , la información relacionada para cada uno de los amigos del usuario puede desplegarse para ese juego (por ejemplo, los amigos que están en la tabla de posiciones, los logros de los amigos, los resultados cuando el usuario juega el juego con otro de sus amigos, etc.). En una modalidad, el API 200 del recuadro de juegos 2000 incluye las funciones para accesar a los datos.de los amigos manejados por un servicio de amigos tal como se describe en la solicitud co-pendiente titulada Aparato y Método para Manejar Eficientemente los Datos en un Servicio de Red Social, No. de Documento del Apoderado 4860.P9240, No. de Serie. 61/321 ,848, Presentada el 7 de Abril, 2010, teniendo los inventores Amol Pattekar, Jeremy Werner, Patrick Gates, y Andrew H. Vyrros (de aquí en adelante "Aplicación para Servicio de Amigos"), que se asigna al cesionario de la presente solicitud y que se incorpora en este documento como referencia.

Como se ilustra en la Figura 18, en una modalidad, un demonio de juego 2020 puede hacer interfase con el recuadro de juegos 2000 para un primer juego de servicios 2050 y un componente de servicios de juego 2010 puede interferir el recuadro de juegos 2000 para un segundo juego de servicios 2051. Por medio de ejemplo, el primer juego de servicios 2050 puede incluir el servicio de invitación 1 12, el servicio intermediario 1 1 1 y el servicio de retransmisión 1051 anteriormente descritos y el servicio de amigos descrito en la Aplicación de Servicio de Amigos antes referenciado. Otros servicios que pueden accesarse vía el demonio de juegos 2020 incluye un servicio de tabla de posiciones (proporcionando los datos de la tabla de posiciones); un servicio de juegos (proporcionando estadísticas y otros datos relacionados para cada uno de los juegos y la habilidad para comprar el juego); un servicio de autentificación del usuario (para la autentificación del usuario del dispositivo móvil) y/o un servicio de perfil de usuario (para almacenar los datos del perfil de usuario tal como las preferencias del usuario). El segundo juego de servicios 2051 accesado vía el componente de servicios de juego 2010 puede incluir el servicio de intercambio de datos de conexión (CDX) 1 10 y los servicios de NAT transversal 290-291 , anteriormente descritos. Aunque se ilustran como componentes separados en la Figura 18 para el propósito de ilustración, el demonio de juego 2020 y el módulo de servicios de juego 2010 pueden actualizar los componentes del recuadro de juegos 2000. En una modalidad, el demonio de juegos 2020 y 2010 se comunica con cada servicio de red 2050-2051 a través de un API predefinido que en una modalidad es un API privado (es decir, no publicado para los desabolladores de terceras partes).

En una modalidad, el demonio de juego 2020 puede comunicarse con el servicio intermediario 1 1 1 , el servicio de invitación 1 12 y los otros servicios 2050 usando el protocolo HTPPS mientras el módulo de servicios de juego 2010 puede comunicarse con el servicio CDX y los servicios transversales NAT 290-291 usando un protocolo relativamente ligero tal como las conexiones UDP. Sin embargo, como se mencionó previamente, varios otros protocolos de red pueden emplearse mientras aún se cumple con los principios subyacentes de la invención.

Además, como se ¡lustra en la Figura 18, el demonio de juego 2020 puede recibir las notificaciones push 2052 generadas por ciertos servicios 2052 (es decir, el servicio de invitación y el servicio intermediario) mientras otros tipos de notificaciones push 2053 puede recibirse directamente por el centro de juegos (es decir, las notificaciones de servicio de amigos tales como nuevas solicitudes de amigos). En una modalidad, estas notificaciones push 2053 se proporcionan directamente al centro de juegos 2031 para asegurar que los datos sensibles de un usuario no son accesibles para las aplicaciones 2030 diseñadas por los desarrolladores de aplicaciones de terceras partes.

Regresando a los ejemplos de invitación de juegos establecidos posteriormente en la Figura 1 1 , cuando una aplicación 2030 en un dispositivo móvil A hace una llamada de invitación al API2001 b del recuadro de juegos 2000 para invitar a un usuario del dispositivo móvil B (por ejemplo INVITAR (Invite) (ID del Jugador B, ID de Celda/Juego)), el recuadro de juego 2000 puede pasar la solicitud de invitación al demonio -de juegos 2020 del dispositivo móvil A. El demonio de juegos 2020 posteriormente puede comunicarse con el servicio de invitación 1 12 para enviar la solicitud de invitación. El servicio de invitación 1 12 entonces puede usar el servicio de notificación push 1050 (como se describió anteriormente) para enviar la invitación al demonio de juegos 2020 del dispositivo móvil B. El demonio de juegos 2020 del dispositivo móvil B posteriormente puede comunicarse con el recuadro de juegos 2000 del dispositivo móvil B para determinar si el juego para el cual la invitación se envío se instaló en el dispositivo móvil B. Si es asi, entonces el recuadro de juegos 2000 puede activar la aplicación 2030 y/o generar una notificación visual de la invitación. Si la aplicación no se instaló, entonces el recuadro de juegos 2000 puede activar una notificación visual de la invitación para el usuario del dispositivo móvil B con una oferta para comprar el juego (por ejemplo, vía el centro de juegos 2031 GUI). Alternativamente, la notificación visual puede generarse por un demonio de notificación push corriendo en el dispositivo móvil 120 (no mostrado). Si el usuario del dispositivo móvil B compra el juego, la secuencia de invitación puede continuar siguiendo la compra. Si el usuario del dispositivo móvil B acepta la solicitud de invitación, entonces el recuadro de juego 2000 del dispositivo móvil B pasa la solicitud de invitación a su demonio de juegos 2020 que posteriormente puede responder al servicio de invitación 1 12.

Recordar que en la Figura 1 1 , la verificación de compatibilidad 1 106 determina que los tipos NAT de los dispositivos móviles A y B son compatibles. Además, en 1 108, el demonio de juegos del dispositivo móvil A 2020 puede recibir la aceptación del dispositivo móvil B (por ejemplo, vía la notificación push en el ejemplo) y en una modalidad, pasa la aceptación al recuadro de juegos 2000. En este estado, el recuadro de juegos 2000 del dispositivo móvil A puede notificar a la aplicación de solicitud 2030 que el dispositivo móvil B ha aceptado (vía el API 2001 ) o puede esperar a notificar la aplicación de solicitud 2030 hasta que los dispositivos se han conectado exitosamente. En cuyo caso, el recuadro de juegos 2000 puede pasar una solicitud de conexión al módulo de servicios del juego 2010 que, en una modalidad, puede iniciar un intercambio de los datos de conexión con el dispositivo móvil B. En particular, el módulo de los servicios de juego puede transmitir los datos de conexión del dispositivo móvil A al dispositivo móvil B usando el servicio CDX 1 10 (ver por ejemplo, las transacciones 1 1 1 1 y 1 1 12 en la Figura 1 1 ). Como se describió anteriormente, esta comunicación puede ¡mplementarse como una conexión UDP usando una estructura de datos de "entrada" segura.

Recordar que en la Figura 12, si la verificación de compatibilidad 1 106 determina que los tipos NAT de los dispositivos móviles A y B no son compatibles, entonces el servicio de retransmisión 1051 puede usarse para proporcionar una conexión entre los dispositivos. Consecuentemente, el demonio de juegos 2020 del dispositivo móvil B puede recibir una respuesta de retransmisión 1203 del servicio de invitación (mostrado en la Figura 12) y el demonio de juegos 2020 del dispositivo A puede recibir una respuesta de retransmisión 1205 del servicio de invitación (vía el servicio de notificación push 1050). Los demonios de juegos 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 demonio de juegos 2020 del dispositivo móvil B recibe los datos de la actualización de retransmisión del dispositivo móvil A en 1213, el demonio de juegos 2020 del dispositivo móvil A recibe los datos de actualización de retransmisión del dispositivo móvil B.

Los resultados terminales de los procesos mostrados en las Figuras 1 1 y 12 es que los dispositivos móviles A y B han establecido una conexión uno con el otro (ya sea una directa, una conexión P2P o una conexión de retransmisión). En una modalidad, en la detección de una conexión exitosa, el recuadro de juegos 2000 puede notificar la aplicación 2030 que solicitó la conexión usando una llamada API (por ejemplo CONECTADO (ID de Jugador A, ID de Jugador B)). Los dispositivos móviles A y B posteriormente pueden jugar el juego especificado u otra aplicación de colaboración 2030 usando la conexión establecida.

Además, en respuesta a una llamada relativamente simple del API 2001 (por ejemplo INVITAR ID del Jugador B, ID de la Celda/Juego), una serie compleja de transacciones puede manejarse por el recuadro de juegos 2000 para establecer un P2P o una conexión de retransmisión entre los dispositivos móviles A y B. En una modalidad, el recuadro de juegos 2000 realiza la secuencia de operaciones para conectar los dispositivos móviles A y B, y entonces proporciona los resultados de la aplicación de solicitud 2030, por lo tanto dejando los detalles de la llamada API transparentes para el diseñador de la aplicación. Como tal, el diseñador de la aplicación no se requiere que entienda como conectar los dispositivos móviles A y B en la red, o como realizar otras varias funciones requeridas para habilitar la comunicación entre los dispositivos, por lo tanto simplifica el proceso de diseño de la aplicación.

En una manera similar, el recuadro de juegos 2000 puede establecer una correspondencia entre el dispositivo móvil A y los otros participantes usando el servicio intermediario 1 1 1. como se describió anteriormente con respecto a las Figuras 2a-b. En este ejemplo, la aplicación 2030 puede hacer una simple llamada al API 2001 tal como CORRESPONDER (ID del Jugador A/ID de la Celda/Juego). En respuesta, el recuadro de juegos 2000 puede manejar las operaciones de intercambio de datos e correspondencia. Cuando las operaciones de correspondencia y/o conexiones P2P se completan, el recuadro de juegos 2000 proporciona los resultados de nuevo a la aplicación 2030.

Por ejemplo, en la Figura 2b, el recuadro de juegos 2000 puede usar el módulo de servicios de juego 2010 para comunicarse con el servicio de intercambio de datos de conexión (CDX) 1 10 y los servicios transversales NAT 290-291 y puede usar el demonio de juegos para comunicarse con el servicio intermediario 1 1 1 . Una vez que una correspondencia se ha hecho, el demonio de juegos 2020 del dispositivo móvil A recibe la Entrada A en 229 y el recuadro de juegos 2000 usa esta información para implementar un intercambio de datos de conexión a través del módulo de servicios de juego 2010. Por ejemplo, en 232, puede solicitar sus propios datos de conexión a través del servicio transversal' NAT 290 y posteriormente intercambiar sus datos de conexión en 233-234 a través del servicio CDX 1 10. En 237 y 240, el módulo de servicios de juego 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 juego 2010 establece las conexiones P2P en 241 y el recuadro de juegos 2000 notifica la aplicación 2030 que el proceso de conexión está completo usando una notificación API (por ejemplo CORRESPONDENCIA COMPLETA (ID de Jugador B, ID de Jugador C)), la aplicación posteriormente se ejecuta usando la conexión P2P establecida.

En algunas modalidades, el usuario puede dar la opción de jugar un juego con otros amigos que están actualmente registrados como "en línea". En este caso, la notificación que ciertos amigos están en línea puede proporcionarse vía la notificación push 2052 o las notificaciones push 2053 (recibidas directamente por el centro de juegos 2031 ). Él centro de juegos 2031 y/o las aplicaciones 2030 posteriormente pueden proporcionar las notificaciones al usuario y proporcionar al usuario la opción de jugar con uno o más amigos seleccionados en línea. Debe notarse, sin embargo, que la secuencia de invitación descrita en este documento trabajará a pesar de si las' notificaciones en línea se proporcionan. En una modalidad, el estado en línea del usuario puede monitorearse por un servicio accesible por el demonio de juegos 2020 (por ejemplo, por el servicio de^amigos anteriormente mencionado o por un servicio de "presencia" separado).

Una modalidad del recuadro de juegos 2000 proporciona una combinación de la operación de correspondencia/invitación en la cual un usuario puede invitar uno o más amigos a jugar un juego con un grupo de participantes correspondientes desconocidos. Por ejemplo, si un jugador requiere 4 jugadores y un primer usuario invita a un segundo usuario para jugar el juego, entonces el servicio de invitación 112 puede inicialmente conectar al primer usuario y al segundo usuario y el servicio intermediario 1 1 1 entonces puede corresponder al primer usuario y al segundo usuario con dos (o más) de los otros jugadores. En esta modalidad, el recuadro del juego 2000 puede realizar inicialmente las secuencias de invitación anteriormente descritas para conectar al primer usuario y al segundo usuario. En una modalidad, una vez que el primer usuario y el segundo usuario se han conectado exitosamente, el recuadro de juegos 2000 puede implementar las secuencias de correspondencia para identificarse y conectarse con los otros usuarios. Como se mencionó anteriormente, en una modalidad, el criterio de correspondencia aplicado por el servicio de correspondencia puede incluir ambos, el primero y segundo usuarios (por ejemplo, tipos NAT, tipos de conexión, idioma, etc. de ambos primero y segundo usuarios). Alternativamente, el criterio de uno de los dos usuarios puede evaluarse para hacer la decisión de correspondencia.

Una vez que todos los usuarios están conectados, el recuadro de juegos 2000 puede proporcionar los resultados de conexión a la aplicación 2030 que solicitaron la conexión vía el API 2001 . Una vez de nuevo, en respuesta a una llamada API relativamente simple por una aplicación 2030, el recuadro de juegos 2000 ingresa en un juego de transacciones complejas para conectar a cada uno de los dispositivos. Una vez que los dispositivos han sido conectados exitosamente, el recuadro de juegos 2000 proporciona los resultados de nuevo a la aplicación de solicitud 2030.

Como sé ilustra en la Figura 18, el recuadro de juegos 2000 puede incluir un buffer de comunicación 2030 para almacenar temporalmente la comunicación entre el usuario y los otros participantes del juego. La comunicación puede incluir, por ejemplo, texto, audio y/o comunicación en video. El recuadro de juegos 2000 puede establecer el buffer 2003 con base en los requerimientos de cada aplicación 2030. Por ejemplo, un buffer relativamente grande 2003 puede requerirse para la comunicación de audio/video con una conexión de red lenta. En una modalidad, cada aplicación 2030 puede hace runa solicitud explícita para establecer un buffer de comunicación de un cierto tamaño vía el API 2001 (por ejemplo, usando un comando BUFFER (tamaño). Alternativamente, el recuadro de juegos 2000 puede crear automáticamente un buffer con base en los requerimientos de comunicación de cada aplicación. Por ejemplo, el recuadro de juegos 2000 puede seleccionar un tamaño de buffer particular con base en si se necesita soportar texto, audio, y/o video.

En una modalidad, el buffer de comunicación 2003 puede almacenar temporalmente flujos de comunicación antes de que todas las conexiones P2P hayan sido establecidas entre los usuarios. Por ejemplo, después de que el servicio de invitación 1 12 o el servicio intermediario 1 1 1 ha identificado a cada uno de los usuarios pero antes el servicio CDX 1 10 ha completado las operaciones de intercambio de datos de conexión, cada usuario puede notificarse de los otros participantes del juego 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 video a los otros participantes. El recuadro de juegos 2000 almacenará los flujos de comunicación dentro del buffer de comunicación 2003 para aquellos participantes quiénes aún no están conectados. El recuadro de juegos 2000 puede entonces transmitir el texto, audio y/o video desde el buffer 2003 cuando la conexión para cada dispositivo esté completa.

En una modalidad, el demonio de juego 2020 incluye un caché 2021 para capturar los datos persistentes en cada uno de los servicios 2050 para reducir el tráfico de red. Por ejemplo, la lista de amigos del usuario, los datos de la tabla de posiciones, los datos de los logros, los datos de presencia y los datos de perfil pueden almacenarse en el caché 2021 como se especifica por una política de manejo del caché. En una modalidad, la política de manejo del caché se lleva a cabo por cada servicio individual en el cual los datos se almacenan. Consecuentemente, para los servicios diferentes n, las políticas de manejo del caché diferente n pueden aplicarse al caché 2021 . Además, porque la política de manejo del caché se conduce por los servicios, puede modificarse dinámicamente con base en la red actual y/o las condiciones de carga del servidor. Por ejemplo, durante los periodos de tiempo cuando un servicio es pesadamente cargado (por ejemplo, Navidad, el día de venta de un nuevo producto, etc.), el servicio puede especificar dinámicamente una política de manejo de caché con actualizaciones de caché relativamente infrecuentes (es decir, actualizaciones cada 12 horas). En contraste, durante los periodos de tiempo cuando un servicio no está cargado pesadamente, el servicio puede especificar una política de captura con actualizaciones de caché más frecuentes (por ejemplo, actualizaciones cada V. hora, hora, 2 horas, etc.).

En una modalidad, la política de manejo del caché se especifica usando un valor de tiempo en vivo (TTL) para ciertos registros de datos almacenados en el caché 2021. Cuando un registro de datos se ha almacenado en el caché pasando su valor TTL, entonces los datos se consideran "pasados" y una solicitud local para esos datos puede renviarse directamente al servicio asociado con esos datos. En una modalidad, la solicitud incluye un código ID identificando una versión actual de los datos. Si el código de ID corresponde al código ID en el servicio, entonces los datos aún son válidos y no necesitan actualizarse Una respuesta entonces puede enviarse de nuevo desde el servicio indicando que los datos en el caché son actuales y el valor TTL para el registro de datos puede restablecerse.

Además de usar una política de manejo del caché como se describió anteriormente, en una modalidad, las actualizaciones del caché para ciertos tipos de datos pueden enviarse al dispositivo móvil usando el servicio de notificación push 1050. Por ejemplo, los cambios para una lista de amigos del usuario o el estado en línea actual de los amigos del usuario pueden enviarse dinámicamente al dispositivo móvil del usuario 120. La notificación push puede recibirse por el demonio de juego 2020 que posteriormente puede actualizar el caché 2021 para incluir la porción relevante de los datos enviados por el servicio (es decir, una actualización de todos los datos en el caché asociado con ese servicio puede no requerirse). En contraste, algunas notificaciones push pueden instruir al demonio de juego 2020 para sobrescribir los contenidos completos del caché (o al menos una porción del caché asociado con el servicio realizando el push).

Aquellos servicios que usan el push para actualizar el caché 2021 puede seleccionar valores TTL relativamente altos (y/o pueden no establecer los valores TTL) porque tienen la habilidad de enviar las notificaciones para actualizar los datos almacenados en el caché 2021 . En una modalidad, cada servicio especifica un juego de eventos que pueden activar una actualización del caché de la notificación push. Por ejemplo, los eventos de actualización del caché pueden incluir un cambio a un estado en línea del amigo, una solicitud de un nuevo amigo, una aceptación de una solicitud de amigo, una operación de no amigo, una indicación de que un amigo está jugando un juega particular, un logro del juego alcanzado por un amigo, una actualización en la parte alta 10 de una tabla de posiciones particular o cualquier evento considerado para ser de una importancia suficiente para garantizar la actualización del caché. Usando las notificaciones push para actualizar el caché 2021 de esta manera puede disminuir la carga de servicio y red porque con las actualizaciones push, no se requiere el sondeo periódico entre el dispositivo móvil y el servicio.

Una modalidad del recuadro de juegos 2000 es únicamente formatos de los datos presentados al usuario final con base en el país y/o la ubicación geográfica del usuario. Por ejemplo, los valores tales como la fecha actual, el tiempo y los valores monetarios pueden presentarse diferentemente por los usuarios en diferentes países y ubicaciones. Por medio de ejemplo, en los Estados Unidos el formato de fecha puede ser [mes, día, año] (por ejemplo, Abril 25, 2010) mientras en otros países, el formato de fecha puede ser [dia, mes, año] (por ejemplo, 25 de Abril, 2010). Similarmente, cuando se representa el tiempo en los Estados Unidos y algunos otros países la designación AM/PM puede usarse y dos puntos pueden usarse entre las horas y los minutos (por ejemplo, 3:00 PM). En contraste, muchos otros países no usan la designación AM/PM y/o usan una coma entre las horas y los minutos (por ejemplo, 15,00). Como otro ejemplo, muchas partes del mundo usan el sistema métrico mientras en algunas partes del mundo nó lo usan, (por ejemplo, los Estados Unidos). Debe notarse que estos son simplemente ejemplos ilustrativos que pueden usarse para ciertas modalidades de la invención. Los principios subyacentes de la invención no se limitan a cualquier juego particular de los formatos de datos.

En una modalidad, estos diferentes formatos de datos pueden seleccionarse cuando se despliegan los datos de la tabla de posiciones, los datos de los logros, los datos de los amigos y/o cualquier otro dato procesado por el recuadro de juegos 2000. El recuadro de juegos 2000 puede • determinar la ubicación geográfica y/o país del usuario en varias formas. Por ejemplo, en una modalidad, esta información se proporciona simplemente en los datos del perfil del usuario y/o puede determinarse con base en el proveedor de servicios celulares del usuario. La ubicación del usuario también puede determinarse usando, por ejemplo, el ajuste del Sistema de Posicionamiento Global (GPS).

Otros tipos de formateo de datos que son irrelevantes para la ubicación geográfica y/o país también pueden manejarse por el recuadro de juegos 2000. Por ejemplo, cuando se despliegan los datos de la tabla de posiciones, es importante conocer si el puntaje mas bajo debería colocar al usuario a la cabeza o al final de la tabla de posiciones. Para algunos juegos (por ejemplo, golf, carreras, pistas, esquí, etc.), un número menor indica un mejor funcionamiento mientras que en otros juegos (por ejemplo, fútbol, béisbol, etc.) un número mayor indica un mejor funcionamiento. Además, en una modalidad, la aplicación 2030 específica el tipo de puntuación que se usará vía el API 2001 (por ejemplo, "ascendente" o "descendente"). El recuadro de juegos 2000 posteriormente puede usar el juego apropiado de etiquetas y formatear el despliegue de la puntuación.

Una modalidad del recuadro de juegos 2000 también filtra los datos del usuario con base en la relación entre el usuario y los amigos del usuario. Por ejemplo, una modalidad de la invención permite una vista "detallada", una vista de "amigos" y una vista "pública". En una modalidad, la vista detallada está disponible para el usuario a quién pertenecen los datos (es decir, información personal del usuario); la vista de amigos está disponible para los amigos del usuario y la vista pública está disponible para todos los otros usuarios.

Por medio de ejemplo, la vista pública puede incluir simplemente un nombre "alias" asociado con cada usuario, los juegos jugados por el alias y los puntajes asociados, y las fechas/tiempos en los cuales los juegos se juegan. Esta información puede usarse por el recuadro de juegos 2000 para rellenar una tabla de posiciones pública que posteriormente puede desplegarse vía el 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 compartirse entre los amigos del usuario, por ejemplo, los juegos pertenecientes al usuario, los juegos jugados por el usuario; los logros del usuario y los resultados.; como muchos amigos del usuario tienen la identidad de aquellos amigos, la URL identificando los avatares de los amigos y/o el estado en linea del usuario, por nombrar algunos. En una modalidad, la vista "amigos" proporciona un juego por defecto de la información a compartirse con los amigos pero el usuario final puede ajustar esta configuración por defecto y especificar particularmente los tipos de información a compartirse por cada amigo individual o grupos de amigos (por ejemplo, co-trabajadores, miembros de la familia, amigos de la escuela/la universidad, etc.).

La vista "detallada" puede incluir todo de la información de las vistas "pública" y "amigos" así como cualquier otra información manejada por los varios servicios 2050 en representación del usuario final. Por medio de ejemplo, esto puede incluir todo de los datos de perfil del usuario, el Identificador Universalmente Único ("UUID") (algunas veces referido en este documento como "ID del Jugador"); el nombre del jugador, los nombres alias, el número de juegos y la identidad de los juegos; los amigos del usuario; todo de los logros del usuario, etc.

En algunas circunstancias, una aplicación 2030 puede solamente requerir un poco cantidad de información relacionada con cada usuario tal como la ID de Jugador de cada usuario. Por ejemplo, en una modalidad, cuando una correspondencia se solicita, el recuadro de juegos 2000 puede inicialmente solamente requerir el ID de cada jugador. Como se hacen las correspondencias por el servicio intermediario (ver lo anterior), el recuadro de juegos 2000 puede determinar si cualquiera de los usuarios correspondientes son amigos (por ejemplo, vía la comunicación con el servicio del amigo y/o mediante interrogar los datos del amigo local del usuario). Si es así, entonces el recuadro de juegos 2000 puede recuperar los datos adicionales del usuario y proporcionar esos datos a cualquier amigo correspondiente. De esta forma, el recuadro de juegos 2000 filtra la información con base en la identidad de los usuarios y la relación entre cada uno de los usuarios.

En una modalidad, el recuadro de juegos 2000 inicialmente proporciona una vista pública entre un primer usuario y un segundo usuario si los dos usuarios no tienen una relación de amigos. Sin embargo, en una modalidad, el recuadro de juegos 2000 permite al primer usuario enviar una solicitud de amigo al segundo usuario (por ejemplo, usando el alias del segundo usuario). Si la solicitud de amigo se acepta, entonces el recuadro de juegos 2000 proporcionará información adicional a cada uno de los usuarios (por ejemplo, la vista de "amigos" por defecto).

MODALIDADES DE API DIFERENTES La API implementada en una modalidad, es una ¡nterfase implementada por un componente de programa (de aquí en adelante "componente de programa implementando API") que permite un componente de programa diferente (de aquí en adelante "componente de programa de llamada API") para accesar y usar una o más funciones, métodos, procedimientos, estructuras de datos' y/o servicios proporcionados por el componente de programa de implementación API. Por ejemplo, una API permite a un desarrollador de un componente de programa de llamada API (que puede ser un desarrollador de tercera parte) influenciar las características específicas proporcionadas por el componente de programa de implementación API. Puede existir un componente de programa de llamada API o puede existir más de un componente de dicho programa. Una API puede ser una interfase de código fuente que un sistema de computadora o biblioteca de programa proporciona para soportar las solicitudes para los servicios de una aplicación de programa. Una API puede especificarse en términos de un lenguaje de programación que puede ser interpretativo o compilado cuando una aplicación se construye, más que una descripción de nivel bajo explícito de cómo los datos se extienden en la memoria.

La API define el lenguaje y los parámetros que los componentes del programa llamado API usan cuando accesan y usan las características específicas del componente del programa implementando API. Por ejemplo, un componente de programa de llamada API accesa las características específicas del componente de programa implementando API a través de una o más llamadas API (algunas veces referidas como función o llamadas de método) expuestas por la API. El componente de programa de ¡mplementación API puede regresar un valor a través de la API en respuesta a una llamada API de un componente de programa de llamada API. Mientras la API define la sintaxis y el resultado de una llamada API (por ejemplo, como invoca la llamada API y que la llamada API no), la API típicamente no revela como la llamada API lleva a cabo la función específica por la llamada API. Varias llamadas o mensajes de función se transfieren vía una o más interfases de programación de la aplicación entre el programa de llamada (componente de programa de llamada API) y un componente de programa de ¡mplementación API. Transfiriendo la función de llamadas o mensajes puede incluir enviar, iniciar, invocar, llamar, recibir, regresar o responder a la función de llamadas o mensajes. Aquí, un componente de programa de llamada API puede transferir una llamada y un componente de programa de implementación API puede transferir una llamada.

Por medio de ejemplo, el componente de programa de implementación API 2010 y el componente de programa de llamada API pueden ser un sistema operativo, una biblioteca, un driver del dispositivo, una API, un programa de aplicación u otro módulo de programa (debe entenderse que el componente de programa de ¡mplementación API y el componente de programa de llamada API pueden ser el mismo o de diferente tipo de módulos de programa uno del otro). El componente de programa de llamada API puede ser un componente de programa focal (es decir, en el mismo sistema de procesamiento de datos como el componente de programa de implementación API) o un componente de programa remoto (es decir, en un sistema de procesamiento de datos diferente como el componente de programa de ¡mplementación API) que se comunica con el componente de programa de ¡mplementación API a través del API en una red. Debe entenderse que un componente de programa de implementación API también puede actuar como un componente de programa de llamada API (es decir, puede hacer llamadas API a un API expuesto por un componente de programa de implementación API) y un componente de programa de llamada API también puede actuar como un componente de programa de implementación API mediante implementar un API que se expone a un componente de programa de llamada API diferente.

La API puede permitir que los componentes de programa de llamada API escriban en diferentes lenguajes de programación para comunicarse con el componente de programa de implementación API (además, la API puede incluir características para traducir las llamadas y regresarlas entre el componente de programa de implementación API y el componente de programa de llamada API), sin embargo la API puede implementarse en términos de un lenguaje de programación específico.

La Figura 19 ilustra una modalidad de una arquitectura API que incluye un componente de programa de implementación API 21 10 (por ejemplo, un sistema operativo, una biblioteca, un driver del dispositivo, una API, un programa de aplicación u otro módulo de programa) que implementa el API 2120. El API 2120 específica una o más funciones, métodos, clases, objetos, protocolos, estructuras de datos, formatos y/u otras características del componente de programa de implementación API que puede usarse por el componente de programa de llamada API 2130. El API 2120 puede especificar al menos una convención de llamada que especifica como una función en el componente de programa de implementación API recibe parámetros del componente de programa de llamada API y como la función regresa un resultado para el componente de programa de llamada API . El componente de programa de llamada API 2130 (por ejemplo, un sistema operativo, una biblioteca, un driver del dispositivo, una API, un programa de aplicación u otro módulo del programa), hace las llamadas API a través del API 2120 para accesar y usar las características del componente de programa de implementación API 2120 que se especifican por el API 2120. El componente de programa de implementación API 21 10 puede regresar un valor a través del API 2120 al componente de programa de llamada API 21 30 en respuesta a una llamada API .

Se aprecia que el componente de programa de implementación API 21 10 puede incluir funciones, métodos, clases, estructuras de datos y/u otras características adicionales que no se especifican a través de API 2120 y no están disponibles para el componente de programa de llamada API 2130. Debe entenderse que el componente de programa de llamada API 2130 puede ser el mismo sistema como el componente de programa de implementación API 21 10 o puede localizarse remotamente y accesar el componente de programa de implementación API 21 10 usando API 2120 en una red. Mientras la Figura 19 ilustra un solo componente de programa de llamada API 2130 interactuando con la API 2120, debe entenderse que otros componentes de programa de llamada API, que pueden escribirse en diferentes lenguajes (o el mismo lenguaje) que el componente de programa de llamada API 2130 pueden usar la API 2120.

El componente de programa de implementación API 21 10, el API 2120, y el componente de programa de llamada API 2130 puede almacenarse en un medio legible por computadora, que incluye cualquier mecanismo para almacenar la información en una forma legible por una máquina (por ejemplo, una computadora u otro sistema de procesamiento de datos). Por ejemplo, un medio legible por computadora incluye discos magnéticos, discos ópticos, memoria de acceso aleatorio, memoria solamente de lectura, dispositivos de memoria flash, etc.

En la Figura 20 ("Pila de Programa"), una modalidad ejemplarizadora, las aplicaciones pueden hacer las llamadas a los Servicios 1 ó 2 usando varias APIs de Servicio y para el Sistema Operativo (OS) usando varias APIs OS. Los Servicios 1 y 2 pueden hacer llamadas a OS usando varias APIs OS.

Notar que el Servicio 2 tiene dos APIs, uno de los cuales (Servicio 2 API 1 ) recibe las llamadas de y regresa los valores a la Aplicación 1 y el otro (Servicio 2 API 2) recibe las llamadas de y regresa los valores a la Aplicación 2. El Servicio 1 (que puede ser, por ejemplo, una biblioteca de programa) hace las llamadas a y recibe los valores de regreso de OS API I y el Servicio 2 (que puede ser, por ejemplo, una biblioteca de programa) hace llamadas para y recibe los valores regresados de ambos API I OS y API 2 OS. La Aplicación 2 hace llamadas a y recibe los valores regresados desde OS API 2.

DISPOSITIVOS DE PROCESAMIENTO DE DATOS EJEMPLARIZADORES La Figura 21 es un diagrama de bloque que ilustra un sistema de computadora ejemplarizador que puede usarse en algunas modalidades de la invención. Debe entenderse que mientras la Figura 21 ilustra varios componentes de un sistema de computación, no se intenta que represente cualquier arquitectura particular o forma de interconexión de los componentes como esos detalles que no son pertinentes para la presente invención. Se apreciará que otros sistemas de computación también pueden usarse con la presente invención.

Como se ¡lustra en la Figura 21 , el sistema de computación 2300, que es una forma de un sistema de procesamiento de datos, incluye el bus (es) 2350 que se acopla con el sistema de procesamiento 2320, el suministro de energía 2325, la memoria 2330 y la memoria o volátil 2340 (por ejemplo, un disco duro, memoria flash, Memoria de Cambio de Fase (PCM), etc.). Los buses 2350 pueden conectarse uno con el otro a través de varios puentes, controladores y/o adaptadores como es bien conocido en la técnica. El sistema de procesamiento 2320 puede recuperar las instrucciones de la memoria 2330 y/o la memoria no volátil 2340 y ejecutar las instrucciones para realizar las operaciones como se describió anteriormente. El bus 2350 interconecta los componentes anteriores juntos y también interconecta aquellos componentes al dock opcional 2360, el dispositivo de despliegue & el controlador de despliegue 2370, los dispositivos de Entrada/Salida 2380 (por ejemplo NIC (Tarjeta de Interfase de Red), un controlador de cursor (por ejemplo, ratón, pantalla táctil, touchpad, etc.), un teclado, etc.) y los transmisores inhalámbricos opcionales 2390 (por ejemplo, Bluetooth, WiFi, Infrarrojo etc.).

La Figura 22 es un diagrama de bloque ilustrando un sistema de procesamiento de datos ejemplarizador que puede usarse en algunas modalidades de la invención. Por ejemplo, el sistema de procesamiento de datos 2400 puede ser una computadora portátil, un asistente digital personal (PDA), un teléfono móvil, un sistema de juegos portátil, un reproductor de medios portátil, una tableta o un dispositivo de computación portátil que puede incluir un teléfono móvil, un reproductor de medios y/o un sistema de juegos. Como otro ejemplo, el sistema de procesamiento de datos 2400 puede ser una computadora de red o un dispositivo de procesamiento incrustado dentro de otro dispositivo.

De acuerdo con una modalidad de la invención, la arquitectura ejemplarizadora del sistema de procesamiento de datos 2400 puede usarse para los dispositivos móviles anteriormente descritos. El sistema de procesamiento de datos 2400 incluye el sistema de procesamiento 2420 que puede incluir uno o más microprocesadores y/o un sistema en un circuito integrado. El sistema de procesamiento 2420 se acopla con una memoria 2410, un suministro de energía 2425 (que incluye una o más baterías), una entrada/salida de audio 2440, un controlador de pantalla, y dispositivo de pantalla 2460, entrada/salida opcional 2450, dispositivo de entrada 2470 y transmisores receptores inhalámbricos 2430. Se apreciará que los componentes adicionales, no mostrados en la Figura 22 también puede ser una parte del sistema de procesamiento de datos 2400 en ciertas modalidades de la invención y en ciertas modalidades de la invención menos componentes de ios mostrados en la Figura 22 pueden usarse. Además, se apreciará que uno o más buses, no mostrados en la Figura 22 pueden usarse para ¡nterconectar los varios componentes como es bien conocido en la técnica.

La memoria 2410 puede almacenar los datos y/o los programas para la ejecución por el sistema de procesamiento de datos 2400. La entrada/salida de audio 2440 puede incluir un micrófono y/o un altavoz para por ejemplo, reproducir música y/o proporcionar funcionalidad telefónica a través del micrófono y el altavoz. El controlador de pantalla y el dispositivo de pantalla 2460 pueden incluir una interfase de usuario gráfico (GUI). Los transmisores-receptores inhalámbricos (por ejemplo, RF) 2430 (por ejemplo, un transmisor-receptor WiFi, un transmisor-receptor infrarrojo, un transmisor-receptor Bluetooth, un transmisor-receptor de telefonía celular inalámbrico, etc.) puede usarse para comunicarse con los otros sistemas de procesamiento de datos. El uno o más dispositivos de entrada 2470 permiten al usuario proporcionar la entrada al sistema. Estos dispositivos de entrada pueden ser un teclado, un teclado numérico, un panel táctil, un panel táctil múltiple, etc. La otra entrada/salida opcional 2450 puede ser un conector para un dock.

Las modalidades de la invención pueden incluir varias etapas como se establece posteriormente. Las etapas pueden encontrarse en las instrucciones ejecutables por la máquina que causan un procesador de propósito especial o de propósito general para realizar ciertas etapas. Alternativamente, estas etapas pueden realizarse por los componentes de equipo específicos que contienen lógica cableada para realizar las etapas o mediante cualquier combinación de componentes de computación programados y los compontes de equipo de costumbre.

Los elementos de la presente invención también pueden proporcionase como un medio legible por computadora para almacenar el código de programa ejecutable por la máquina. El medio legible por la máquina puede incluir, pero no limitarse a discos flexibles, discos ópticos, CD-ROMs, y discos magneto-ópticos, ROMs, RAMs, EPROMs, EEPROMs, tarjetas ópticas o magnéticas u otro tipo de medios legibles por máquina/medios apropiados para almacenar el código de programa electrónico.

A través de toda la descripción precedente, para los propósitos de explicación, numerosos detalles específicos se establecerán para proporcionar un entendimiento completo de la invención. Será aparente, sin embargo, para un experto en la técnica que la invención puede practicarse sin alguno de estos detalles específicos. Por ejemplo, será rápidamente aparente para aquellos expertos en la técnica que los módulos funcionales y los métodos descritos en este documento pueden implementarse como programas, equipo o cualquier combinación de los mismos. Además, aunque las modalidades de la invención se describen en este documento dentro del contexto de un ambiente de computación móvil (es decir, usando dispositivos móviles 120-123; 601 -603), los principios subyacentes de la invención no se limitan a una implementación de computación móvil. Virtualmente cualquier tipo de cliente o dispositivos de procesamiento de datos de cliente o punto puede usarse en algunas modalidades incluyendo, por ejemplo, computadoras de escritorio o de estaciones de trabajo. Por consiguiente, el alcance y espíritu de la invención debe juzgarse en los términos de las siguientes reivindicaciones.

Claims (18)

REIVINDICACIONES

1 . Un método ¡mplementado por computadora para establecer comunicación punto a punto ("P2P") entre dispositivos móviles comprendiendo: recibir una pluralidad de solicitudes de correspondencia de una pluralidad de dispositivos móviles, cada una de las solicitudes de correspondencia incluyendo los datos de la aplicación indicando una aplicación particular para la cual una correspondencia está siendo solicitada y además incluyendo datos de configuración de red indicando una configuración de red para cada una de la pluralidad de dispositivos móviles, determinar los ajustes de correspondencia para los grupos de la pluralidad de dispositivos móviles, los ajustes de correspondencia basados al menos en parte en los datos de configuración de red de los dispositivos móviles y generando correspondencias para dos o más dispositivos móviles con base en ambos los datos de la aplicación y los ajustes de correspondencia determinados para los dispositivos móviles.

2. El método de conformidad con la reivindicación 1 , en donde determinar el ajuste de correspondencia incluye determinar la compatibilidad entre las configuraciones de red de dos o más dispositivos móviles enviando las solicitudes de correspondencia.

3. El método de conformidad con la reivindicación 2, en donde 'determinar la compatibilidad de la configuración de red comprende determinar los tipos de dispositivo de traducción de dirección de red ("NAT") usados por dos o más dispositivos móviles, el método además comprendiendo intentar generar correspondencias entre los dispositivos teniendo tipos de dispositivo NAT que son capaces de establecer canales de comunicación P2P directa.

4. El método de conformidad con la reivindicación 1 , en donde el ajuste de correspondencia se basa en los tipos de conexión de cada uno de los dispositivos móviles, el método además comprendiendo intentar generar las correspondencias entre los dispositivos móviles teniendo similares tipos de conexión.

5. El método de conformidad con la reivindicación 1 , en donde los tipos de conexión incluyen conexiones WiFi, conexiones de celular de tercera generación ("3G"), y conexiones de celular Edge.

6. El método de conformidad con la reivindicación 1 , en donde el ajuste de correspondencia se basa en los lenguajes para los cuales los dispositivos móviles se configuran, el método además comprendiendo intentar generar correspondencias entre los dispositivos móviles teniendo lenguajes similares.

7. El método de conformidad con la reivindicación 1 , en donde las solicitudes de correspondencia además incluyen las variables de configuración para cada aplicación, el método además comprendiendo generar correspondencias para los dispositivos móviles basados, en parte en las variables de configuración.

8. El método de conformidad con la reivindicación 7, en donde las variables de configuración incluyen un nivel de experiencia para la aplicación y/o una sub-aplicación de la aplicación.

9. El método de conformidad con la reivindicación 1 , que además comprende: determinar una antigüedad de cada una de las solicitudes de correspondencia y ' ajustar el ajuste de correspondencia para las correspondencias potenciales entre dos o más dispositivos móviles con base en la antigüedad de cada una de las solicitudes de correspondencia.

10. El método de conformidad con la reivindicación 9, en donde el ajuste comprende incrementar el ajuste de correspondencia para las correspondencias potenciales con una antigüedad arriba de un inicio especifico.

1 1 . El método de conformidad con la reivindicación 10, en donde el ajuste comprende continuar el incremento del ajuste de correspondencia como la antigüedad incrementa arriba de uno o más inicios adicionales.

12. El método de conformidad con la reivindicación 1 , en donde la generación de correspondencias además comprende: agrupar las solicitudes de correspondencia en grupos de correspondencia con base en los datos de la solicitud; determinar el ajuste de correspondencia para las solicitudes de correspondencia dentro de cada grupo de correspondencia y generar correspondencias para los dispositivos móviles con cada grupo de correspondencia con base en el ajuste de correspondencia determinado.

13. El método de conformidad con la reivindicación 1 , en donde la generación de correspondencias además comprende: agrupar las solicitudes de correspondencia en grupos de correspondencia con base en los datos de la solicitud, determinar el ajuste de correspondencia para pares de solicitudes de correspondencia dentro de cada grupo de correspondencia, enviar cada una de una pluralidad de grupos de correspondencia con pares de solicitudes de correspondencia teniendo un ajuste de correspondencia arriba de un inicio especifico, agregar las solicitudes de correspondencia a cada grupo de correspondencia, retener las solicitudes de correspondencia adicionales en cada grupo de correspondencia si los ajustes de correspondencia combinados en el grupo de correspondencia están debajo del inicio específico.

14. El método de conformidad con la reivindicación 13, que además comprende: continuar agregando grupos de correspondencia hasta que los requerimientos del tamaño de correspondencia se han cumplido.

15. El método de conformidad con la reivindicación 1 , en donde las solicitudes de correspondencia incluyen datos de conexión /NAT transversal asociados con cada uno de los dispositivos móviles, el método además comprendiendo: transmitir una notificación a un grupo de dispositivos móviles correspondientes que una correspondencia se ha hecho, la notificación enviada a cada dispositivo móvil incluyendo datos de conexión/NAT transversal necesarios para conectar uno o más de los dispositivos móviles incluidos en la correspondencia.

16. El método de conformidad con la reivindicación 15, en donde los datos de conexión/NAT transversal incluyen una dirección IP pública y un puerto para cada uno de los dispositivos móviles.

17. Un medio legible por computadora que tiene el código de programa almacenado en el mismo, el cual cuando se ejecuta por un dispositivo de computación, causa que el dispositivo de computación realice un método como en cualquiera de las reivindicaciones 1 -16.

18. Un dispositivo de computación comprendiendo una memoria para almacenar el código de programa y un procesador para procesar el código de programa para realizar un método como en cualquiera de las reivindicaciones 1 -16.