MX2008009873A - Provision rapida de buenos encuentros - Google Patents

Abstract

Pueden establecerse torneos de jugador múltiple, y después ejecutarse automáticamente por dispositivos de servidor de torneo para ayudar a proporcionar a los usuarios encuentros de calidad contra jugadores de habilidad similar. Los torneos pueden ser definidos por un administrador, y después iniciar automáticamente cualquier número de veces para acomodar demanda por jugadores. Algunos torneos pueden agrupar jugadores de clasificación similar en rondas del torneo, y también pueden emplear un factor de ventana para evitar que los jugadores jueguen juntos demasiado pronto después de jugar juntos en una ronda previa. Algunos torneos pueden utilizar un procedimiento de calificación de puntuación, que permite a los entrantes potenciales calificar para torneos al realizar logros especificados en parámetros de calificación.

Description

PROVISION RÁPIDA DE BUENOS ENCUENTROS ANTECEDENTES El juego de computadora en línea ha crecido rápidamente en un componente clave del mercado de video juegos de hoy en día, ya que existen hoy en día más y más oportunidades para jugar contra otros. Por ejemplo, en el servicio en línea de XBOX UVE™ (Microsoft Corporation, Redmond, Washington), es posible que los jugadores de videojuegos jueguen contra otros jugadores de todo el mundo. Con tal gran grupo de jugadores potenciales, existe una escala correspondientemente grande de capacidades de jugador, que varían del jugador por primera vez u ocasional al fanático diario, devoto, e incluso en las clasificaciones de jugadores de videojuegos profesionales. Esta amplia variedad de capacidades de jugador introdujo un nuevo problema. Muchos juegos en línea son competitivos, en cuanto a que los jugadores compiten uno contra otro para lograr objetivos de juego y ganar un nivel de ascendencia con sus competidores. Tales juegos competitivos frecuentemente sólo se disfrutan cuando los varios jugadores están cerca uno de otro en habilidades y capacidades. Si existe un gran número de discrepancia en el nivel de habilidad, el jugador con habilidad dominante no se retará, mientras el jugador con habilidad más débil experimentará frustración al ser vencido constantemente. Los juegos en línea típicos, sin embargo, recolectan jugadores mientras se unen a sesiones de juego, sin importar las capacidades de los jugadores o qué tan cerca están los jugadores al otro en términos de habilidad. Algunas competencias organizadas, tal como torneos, pueden intentar hacer coincidir jugadores de igual habilidad en una ronda final. Por ejemplo, los torneos de basquetbol de NCAA™ (Asociación de Atléticas de Universidad Nacional) toma 65 equipos y une a los equipos para que (al asumir que no hay alteraciones) existan dos grupos semifinales sobre los cuatro equipos uno contra otro (es decir, las cuatro semillas del número 1). Sin embargo, la ruta de cada número uno se siembra través de las rondas completas del torneo que se llena con coincidencias no balanceadas. Por ejemplo, la primera ronda del torneo de basquetbol de NCAA™ está en la semilla superior en una ménsula contra la semilla inferior en una ménsula (16ava semilla). Adicionalmente, la disposición de NCAA™ requiere una alineación fija, limitada de equipos (los 65 equipos en orden de semilla), y no se traducirá fácilmente en una comunidad de videojuego que tiene miles (o millones) de jugadores, y jugadores que pueden retirarse o llegar en cualquier momento.

BREVE DESCRIPCION DE LA INVENCION Esta breve descripción se proporciona para introducir una selección de conceptos en una forma simplificada que además se describe posteriormente en la Descripción detallada. Esta breve descripción no pretende identificar características clave o características esenciales del tema reclamado, ni pretende utilizarse para limitar el alcance del tema reclamado. Como se describirá en mayor detalle posteriormente, la presente solicitud incluye una estructura de competencia adaptable. Los parámetros de torneo pueden definirse por adelantado, y pueden iniciarse automáticamente por la red de comunicación de juego para que puedan crearse torneos como se necesite y existir indefinidamente, sin la necesidad de supervisión humana constante. Esta definición puede hacerse utilizando, por ejemplo, una interfase de página de Internet, o por una interfase de usuario de videojuego de usuario final. Un administrador de torneo puede registrarse con un servidor de torneo para definir el torneo, al ingresar a parámetros de torneo. El torneo puede iniciarse una o más veces, y los casos separados pueden comunicarse individual, y automáticamente, con los varios participantes, manejar resultados de sesión de juego, y determinar ganadores de torneo. En algunos aspectos, puede utilizarse el arbitraje de marcación para resolver anomalías en marcas reportadas por las varias consolas de juego en el torneo. Por ejemplo, un servidor de torneo puede comparar sus resultados recibidos con resultados recibidos por un procedimiento de marcación separado, en donde el procedimiento de marcación separado puede utilizar más transmisiones aseguradas con las consolas de juego para ayudar a verificar comunicaciones. En algunos aspectos, los torneos pueden correr de acuerdo con un programa, y pueden configurarse para correr uno después de otro (por ejemplo, substancialmente de forma continua). En algunos aspectos, un factor de ventana puede identificar una cantidad de tiempo que debe transcurrir antes de que los jugadores puedan reunirse en una sesión de juego, para minimizar el efecto de tener los mismos jugadores que juegan uno con otro a través de un torneo. También, un nuevo factor de jugador puede utilizarse para ajustar marcaciones de participantes recientemente ingresados. En algunos aspectos, los parámetros de torneo y las configuraciones de juego pueden descargarse a una consola de juego para configurar automáticamente la máquina del jugador para la siguiente ronda de un torneo. En algunos aspectos, un periodo de calificación puede preceder el torneo, durante el cual los jugadores pueden intentar calificar al colocar sus puntuaciones correspondientes. Los jugadores pueden notificarse de su estado de calificación, y puede notificarse de nuevo si el estado cambia debido a intentos de calificación de jugadores subsecuentes, y pueden dar una opción para hacer otro intento de calificación. Un torneo puede iniciarse múltiples veces para acomodar niveles diferentes de calificadores. En algunos aspectos, los torneos pueden ajustarse dinámicamente para acomodar números variables de entradas de torneos de calificación. Los parámetros de torneo, tal como el número de ganadores por contienda, número de jugadores por contienda, número de rondas, número de jugadores en la ronda final del torneo, y otros, pueden variar para que un número deseado de calificadores pueda participar en el torneo. Los entrantes pueden clasificarse al utilizar una relación de su puntuación total a la puntuación posible total para rondas que jugaron, y que puede utilizarse la clasificación en agrupaciones posteriores de jugadores.

Las interfases de usuario de torneo pueden presentarse para permitir navegación de usuario a través del procedimiento de torneo. El usuario puede jugar un videojuego interactivo, de jugador múltiple en línea y de ronda múltiple, y ver una lista de torneos para la cual calificó. Otras opciones también pueden ofrecerse, tal como buscar torneos que satisfacen criterios deseados por usuario, o presentar detalles de torneo y/o competidor. Estos y otros aspectos se describirán en mayor detalle posteriormente .

BREVE DESCRIPCIÓN DE LOS DIBUJOS La Figura 1 ilustra una consola de juego que puede utilizarse para implementar varias características aquí descritas. La Figura 2 ilustra componentes que pueden utilizarse en la consola mostrada en la Figura 1. La Figura 3 ilustra cómo varias consolas, y otros elementos, pueden ¡nterconectarse para implementar características aquí descritas. La Figura 4 ¡lustra una configuración de red ilustrativa que utiliza consolas de juego. La Figura 5a ilustra un dispositivo de cómputo ilustrativo que puede utilizarse para implementar características aquí descritas. Las Figuras 5b-m ilustran elementos de software y conceptos ilustrativos para implementar características aquí descritas. La Figura 6 ilustra un procedimiento ilustrativo para conducir torneos. La Figura 7 ilustra un ejemplo de una estructura de datos de torneo. Las Figuras 8a-b ilustran un procedimiento ilustrativo para un tipo de torneo, y la Figura 8c ilustra una progresión ilustrativa de clasificación y reclasificación. La Figura 9 ilustra otro procedimiento ilustrativo para un tipo alternativo de torneo. Las Figura 10a y 10b ilustran una ménsula de semilla ilustrativa y procedimiento para semilla. La Figura 11 ilustra otra ménsula de semilla ilustrativa. La Figura 12 ilustra un cuadro de relación ilustrativo que muestra como pueden utilizarse varias pantallas de interfase de usuario en una consola de jugador.

DESCRIPCIÓN DETALLADA En la siguiente descripción de los varios aspectos, se hace referencia a los dibujos anexos, que forman una parte aquí, y en donde se muestra a manera de ilustración varias características aquí descritas que pueden practicarse. Se debe entender que de otras modalidades pueden utilizarse y pueden hacerse modificaciones estructurales y funcionales. La Figura 1A ¡lustra un ejemplo de un ambiente de sistema de juego adecuado 100 en el cual los juegos de computadora, videojuegos, y otros juegos electrónicos (colectivamente denominados aquí como juegos de computadora) pueden jugarse. El ambiente de sistema de juego 100 solo es un ejemplo de un ambiente de cómputo adecuado y no pretende sugerir ninguna limitación al alcance de uso o funcionalidad de las características aquí descritas. El ambiente de sistema de juego 100 tampoco debe interpretarse como teniendo ninguna dependencia o requerimiento que se relaciona con cualquiera o combinación de componentes ilustrados en el ambiente de sistema de juego operativo ilustrativo 100. Los aspectos aquí descritos son operacionales con numerosos otros ambientes o configuraciones de sistema de cómputo de propósito general o propósito especial. Ejemplos de sistemas de cómputo bien conocidos, ambientes, y/o configuraciones que pueden ser adecuados para uso incluyen, pero no se limitan a, computadoras personales; computadoras de servidor; dispositivos portátiles y móviles tal como asistentes digitales personales (PDAs) PCs de tableta o PCs portátiles; sistemas de multiprocesador; sistemas a base de microprocesador; cajas de tv por cable; electrónica de consumidor programable; PCs de red; minicomputadoras; macrocomputadoras; consolas de juego electrónico, ambientes de cómputo distribuidos que incluyen cualquiera de los sistemas o dispositivos anteriores; y similares. Los aspectos aquí pueden describirse en el contexto general de instrucciones ejecutables por computadora tal como módulos de programa, que se ejecutan por una computadora, generalmente, módulos de programa incluyen rutinas, programas, objetos, componentes, estructuras de datos, etc. que realizan tareas particulares o implementan tipos de datos abstractos particulares. Las características aquí descritas también pueden practicarse en ambientes de cómputo distribuidos en donde las tareas se realizan por dispositivos de procesamiento remotos que se enlazan a través de una red de comunicaciones. En un ambiente de cómputo distribuido, los módulos de programa pueden localizarse tanto en medios de almacenamiento de computadora local y remota que incluye dispositivos de almacenamiento de memoria. La Figura 1 muestra un sistema de juego ilustrativo 100. El sistema de juego 100 puede incluir una consola de juegos 102 y uno o más controladores móviles, como se representa por controladores 104(1) y 104(2). La consola de juegos 102 puede equiparse con una unidad de disco duro interna o externa y una unidad de medios portátil 106 que soporta varias formas de medios de almacenamiento portátiles como se representó por disco de almacenamiento óptico 108. Ejemplos de medios de almacenamiento portátiles adecuados incluyen DVD, CD ROM, discos de juego, y así sucesivamente. La consola de juego 102 puede tener un número de ranuras 110 en su cara frontal para soportar hasta cuatro controladores, aunque el número de disposiciones de ranuras puede modificarse. Un botón de energía 112 y un botón de expulsión 114 también se colocan en la cara frontal de la consola de juegos 102. El botón de energía 112 cambia la energía para la consola de juego y el botón de expulsión 114 abre y cierra alternativamente una bandeja de la unidad de medios portátil 106 para permitir la inserción y extracción del disco de almacenamiento 108. En algunos aspectos, la consola de juegos 102 puede ser un dispositivo de cómputo dedicado para entretenimiento de hogar, y puede ser un sistema cerrado, seguro que solo ejecuta aplicaciones verificadas y autorizadas. La consola de juego 102 puede optimizarse para ejecutar programas de juego (por ejemplo, que tiene soporte de procesamiento aumentado para aplicaciones de juego, tal como co-procesadores físicos, co-procesadores de matemáticas, co-procesadores de gráficos, salida de video de resolución superior, salida de audio de fidelidad superior, etc.), y puede omitir ciertas características comúnmente encontradas en dispositivos de cómputo personales, tal como un teclado alfabético, ranuras de expansión de hardware internas, puerto de comunicación de impresora, etc.

La consola de juego 102 puede conectarse a una televisión u otra presentación (no mostrada) a través de cables de interfase a/v 120. Un cable de energía 122 proporciona energía a la consola de juego. La consola de juego 102 además puede configurarse con capacidades de red de banda ancha, como se representó por el cable o conector de módem 124 para facilitar acceso a una red, tal como Internet. El conector 124 también puede ajustarse con un adaptador inalámbrico para conectar una o más redes inalámbricas. Cada controlador 104 puede acoplarse a la consola de juego 102 a través de una interfase por cable o inalámbrica. En la implementación ilustrada, los controladores son compatibles de USB (Conductor común en serie universal) y se conectan a la consola 102 a través de cables USB 130. El controlador 102 puede equiparse con cualquiera de una gran variedad de mecanismos de interacción de usuario. Como se ilustró en la Figura 1, cada controlador 104 puede equiparse con dos palancas de pulgar 132(1) y 132(2), una almohadilla D 134, botones 136 (por ejemplo, ?', '?', 'X', ?'), y dos activadores 138. Las palancas de pulgar 132 pueden ser unidades de control direccional analógicas, y pueden incluir potenciómetros analógicos para detectar un grado de posición en las coordenadas X e Y La almohadilla D 134 puede ser una almohadilla direccional, con entradas para ingresar comandos direccionales tal como arriba, abajo, izquierda y derecha, o combinaciones de estas direcciones (por ejemplo, izquierda superior). La almohadilla D 134 puede también ser analógica, y proporcionar entrada como un grado de presión utilizado para presionar en una dirección particular. Estos mecanismos son simplemente representativos, y pueden sustituirse otros mecanismos de juego o agregarse a aquellos mostrados en la Figura 1. Una unidad de memoria (MU) 140 puede insertarse en el controlador 104 para proporcionar almacenamiento adicional y portátil. Las unidades de memoria portátiles permiten a los usuarios almacenar parámetros de juego y cuentas de usuario, y portarlos para jugar en otras consolas. En la implementación descrita, cada controlador se configura para acomodar dos unidades de memoria 140, aunque pueden emplearse más o menos de dos unidades en otras implementaciones. Un audífono 142 puede conectarse al controlador 104 ó consola de juego 102 para proporcionar capacidades de comunicación de audio. El audífono 142 puede incluir un micrófono para entrada de audio y una o más bocinas para salida de audio. El sistema de juego 100 es capaz de reproducir, por ejemplo, juegos, música, y videos. Con las diferentes ofertas de almacenamiento, los títulos pueden jugarse desde la unidad de disco duro o el medio portátil 108 en la unidad 106, de una fuente en linea, o de una unidad de memoria 140. Para seguridad, en algunas modalidades el código ejecutable solo puede correr desde el medio portátil 108. Una muestra de que sistema de juego 100 es capaz de jugar incluye títulos de juego jugados desde discos de CD y DVD, de la unidad de disco duro, y de una fuente en línea; música digital reproducida de un CD en la unidad de medios portátil 106, de un archivo en la unidad de disco duro (por ejemplo, "WINDOWS™" formato de Audio de medios (WMA)), o de fuentes de corriente en línea; y audio/video digital reproducido de un disco de DVD en la unidad de medios portátiles 106, de un archivo en la unidad de disco duro (por ejemplo, Formato de corriente activa), o de fuentes de corriente en línea. La Figura 2 muestra componentes funcionales del sistema de juego 100 en más detalle. La consola de juego 102 tiene una unidad de procesamiento central (CPU) 200 y un controlador de memoria 202 que facilita que el procesador acceda a varios tipos de memoria, que incluyen una ROM flash (Memoria de sólo lectura) 204, una RAM (memoria de acceso aleatorio) 206, una unidad de disco duro 208, y la unidad de medios portátil 106. La CPU 200 se equipa con una memoria caché 210 de nivel 1 y una memoria caché 212 de nivel 2 para almacenar temporalmente datos y a partir de aquí reducir el número de ciclos de acceso de memoria, con lo cual mejora la velocidad y resultado de procesamiento. La CPU 200, controlador de memoria 202, y varios dispositivos de memoria se interconectan a través de uno o más conductores comunes, que incluyen conductores comunes en serie y paralelos, un conductor común de memoria, un conductor común periférico, y un conductor común de procesador local que utiliza cualquiera de una variedad de arquitecturas de conductor común. A manera de ejemplo, tales arquitecturas pueden incluir un conductor común de Arquitectura estándar de industria (ISA), un conductor común de Arquitectura de microcanal (MCA), un conductor común de ISA mejorado (EISA), un conductor común local de Asociación de estándares de electrónica de video (VESA), y un conductor común de Interconexiones de componente periférico (PCI) también conocido como conductor común de Mezzanine. Como una implementación adecuada, la CPU 200, controlador de memoria 202, ROM 204, y RAM 206 se integran en un módulo común 214. En esta implementación, la ROM 204 se configura como una ROM flash que se conecta al controlador de memoria 202 y un conductor común de ROM (no mostrado). La RAM 206 se configura como DDR SDRAM (RAM Dinámica Sincrónica de Velocidad de Datos Dobles) que se controla independientemente por el controlador de memoria 202 a través de conductores comunes separados (no mostrado). La unidad de disco duro 208 y la unidad de medios portátil 106 se conecta al controlador de memoria a través del conductor común de PCI y un conductor común ATA (Unión AT) 216.

Una unidad de procesamiento de gráficos 3D 220 y un codificador de video 222 forman una tubería de procesamiento de video para procesamiento de gráficos de alta velocidad y alta resolución. Los datos se transportan desde la unidad de procesamiento de gráficos 220 al codificador de video 222 a través de un conductor común de video digital (no mostrado). Una unidad de procesamiento de audio 224 y un codificador/descodificador de audio (codee) 226 forman una tubería de procesamiento de audio correspondiente con procesamiento de alta fidelidad y de estéreo. Los datos de audio se transportan entre la unidad de procesamiento de audio 224 y el codificador/descodificador de audio 226 a través de un enlace de comunicación (no mostrado). Las tuberías de procesamiento de video y de audio sacan datos a un puerto a/v (audio/video) 228 para transmisión a la televisión u otra presentación. En la implementación ilustrada, los componentes de procesamiento de video y audio 220-228 se montan en el módulo 214. También implementados en el módulo 214 están un controlador de huésped de USB 230 y una interfase de red 232. El controlador de huésped de USB 230 se acopla a la CPU 200 y el controlador de memoria 202 a través de un conductor común (por ejemplo, conductor común de PCI) y sirve como huésped para los controladores periféricos 104(1 )- 104(4). La interfase de red 232 proporciona acceso a una red (por ejemplo, Internet, red de hogar, etc.) y puede ser cualquiera de una gran variedad de componentes de interfase por cable o inalámbricos que incluyen una tarjeta de Ethernet, un módem, un módulo de Bluetooth, un módem por cable, y similares. La consola de juego 102 tiene dos sub-ensambles de soporte de controlador doble 240(1 ) y 240(2) con cada sub-ensamble que soporta dos controladores de juego 104(1 )-104(4). Un sub-ensamble y/o de panel 242 soporta la funcionalidad del botón de energía 112 y el botón de expulsión 114. Asi como cualquiera de los LEDs (diodos de emisión de luz) u otros indicadores expuestos en la superficie exterior de la consola de juego. Los sub-ensambles 240(1 ), 240(2), y 242 se acoplan al módulo 214 a través de uno o más ensambles de cable 244. En algunas modalidades, la consola de juego 102 también puede incluir un sub-ensamble de entrada de teclado 240(3), al cual se conecta un teclado 254. El teclado 254 y su sub-ensamble pueden ofrecerse como parte de una versión de equipo de desarrollador de la consola 102, para permitir el uso de un teclado para ingresar comandos de texto y datos para propósitos de prueba. En algunas modalidades, el teclado 254 puede comunicarse directamente con un puerto de controlador (por ejemplo, como en sub-ensambles 240), y el uso de un sub-ensamble de entrada de teclado separado no es necesario. Además, para conservar recursos de consola de juego adicionales, un controlador de teclado y sub-ensamble pueden omitirse de la consola, y a su vez la consola puede acoplarse a un segundo dispositivo de cómputo (por ejemplo, otra PC, o una estación de trabajo de depuración) a través del cable USB, al cual el segundo dispositivo de cómputo puede enviar secuencias de comando a la consola de juego, que reducen la necesidad en la consola de juego de software y/o hardware separados para interpretar secuencias de comando de texto ingresadas a través del teclado. Las ocho unidades de memoria 140( 1 )- 140(8) se ilustran como conectables a los cuatro controladores 104(1 )-104(4), es decir, dos unidades de memoria para cada controlador. Cada unidad de memoria 140 ofrece almacenamiento adicional en el cual los juegos, parámetros de juego, y otros datos pueden almacenarse. Cuando se inserta en un controlador, la unidad de memoria 140 puede accederse por el controlador de memoria 202. Un módulo de suministro de energía de sistema 250 proporciona energía a los componentes del sistema de juego 100. Un ventilador 252 enfría el sistema de circuitos dentro de la consola de juegos 102. La consola de juegos 102 implementa un modelo de portal de medios uniformes que proporciona una interfase de usuario consistente y jerarquía de navegación para mover usuarios a través de varias áreas de entretenimiento. El modelo de portal ofrece una forma conveniente para acceder a contenido desde múltiples tipos de medios diferentes, datos de juego, datos de audio, y datos de video, sin importar el tipo de medios insertado en la unidad de medios portátil 106. Para implementar el modelo de portal de medios uniforme, una aplicación de interfase de usuario de consola (Ul) 260 se almacena en la unidad de disco duro 208. Cuando se enciende la consola de juego, se cargan varias porciones de la aplicación de consola 260 en RAM 206 y/o memorias caché 210, 212 y se ejecutan en la CPU 200. La aplicación de consola 260 presenta una interfase de usuario gráfica que proporciona una experiencia de usuario consistente cuando se navega a diferentes tipos de medios disponibles en la consola del juego.

El sistema de juego 100 puede operarse como un sistema aislado al conectar simplemente el sistema a una televisión u otra presentación. En este modo individual, el sistema de juego 100 permite a uno o más jugadores jugar juegos, ver películas, o escuchar música. Sin embargo, con la integración de conectividad de banda ancha hecha disponible a través de la interfase de red 232, el sistema de juego 100 además puede operar como un participante en una comunidad de juegos de red mayor. Este ambiente de juego de red se describe después. La Figura 3 muestra un ambiente de juegos de red ilustrativo 300 que conecta múltiples sistemas de juego 100(1),..., 100(g) a través de una red 302. La red 302 representa cualquiera de una gran variedad de redes de comunicaciones de datos. Puede incluir porciones públicas (por ejemplo, Internet) así como porciones privadas (por ejemplo, una Red de área local residencial (LAN)), así como combinaciones de porciones públicas y privadas. La red 302 puede im plementarse utilizando cualquiera de una o más de una gran variedad de medios de comunicaciones convencionales que incluyen tanto medios por cable como inalámbricos. Cualquiera de una gran variedad de protocolos de comunicaciones puede utilizarse para comunicar datos a través de la red 302, incluyendo tanto protocolos públicos como de propiedad. Ejemplos de tales protocolos incluyen TCP/IP, IPX/SPX, NetBEUI, etc. Además de los sistemas de juego 100, uno o más servicios en línea 304(1), 304(s) pueden ser accesibles a través de la red 302 para proporcionar varios servicios para los participantes, tal como alojar juegos en línea, servir archivos de música o video descartables, alojar competencias de juego, servir archivos de audio/video de corriente, y similares. El ambiente de juego de red 300 además puede involucrar un centro de distribución de clave 306 que juega un papel importante al verificar jugadores individuales y/o sistemas de juego 100 uno con otro así como servicios en línea 304. El centro de distribución 306 distribuye claves y boletos de servicio para validar participantes que entonces pueden utilizarse para formar jugadores contra múltiples jugadores o para comprar servicios de los servicios en línea 304. El ambiente de juego de red 300 introduce otra fuente de memoria disponible para sistemas de juego individuales 100, almacenamiento en línea. Además del medio de almacenamiento portátil 108, la unidad de disco duro 208, y la unidad(es) de memoria 140, el sistema de juego 100(1) también puede acceder a archivos de datos disponibles en localizaciones de almacenamiento remotas a través de la red 302, como se ejemplificó por el almacenamiento remoto 308 en servicio en línea 304(s). La Figura 4 es un diagrama de bloques de otro ambiente de juego en línea ilustrativo 400, por ejemplo "XBOX™ LIVE™" por Microsoft Corporation de Redmond, Washington. Múltiples consolas de juego 402(1), 402(2),..., 402(n) se acoplan a un acceso de seguridad 404 a través de una red 406. Cada consola de juego 402, por ejemplo, puede ser una consola de juego 102 de la Figura 1 o Figura 2. La red 406 representa cualquiera o más de una variedad de redes de comunicaciones de datos convencionales. La red 406 típicamente incluirá redes conmutadas de paquete, pero también puede incluir redes conmutadas de circuito. La red 406 puede incluir porciones por cable y/o inalámbricas. En una implementación ilustrativa, la red 406 incluye Internet y opcionalmente puede incluir una o más redes de área local (LANs) y/o redes de área ancha (WANs). Al menos una parte de la red 406 es una red pública, que se refiere una red que es públicamente accesible. Virtualmente cualquiera puede acceder a la red pública. En algunas situaciones, la red 406 incluye una LAN (por ejemplo, una red de hogar), con un dispositivo de enrutamiento situado entre la consola de juego 402 y el acceso de seguridad 404. Este dispositivo de enrutamiento puede realizar traducción de dirección de red (NAT), que permite a los múltiples dispositivos en la LAN compartir la misma dirección de IP en Internet, y también operar como un muro contra incendios para proteger el dispositivo(s) en la LAN de acceso por usuarios malignos o maliciosos a través de Internet. El acceso de seguridad 404 opera como un acceso entre la red pública 406 y una red privada 408. La red privada 408 puede ser cualquiera de una gran variedad de redes convencionales, tal como una red de área local. Las redes privadas 408, asi como otros dispositivos discutidos en mayor detalle posteriormente, está dentro de un centro de datos 410 que opera como una zona segura. El centro de datos 410 se forma de dispositivos confiados que se comunican a través de comunicaciones confiadas. De esa forma, la codificación críptica y la verificación dentro de la zona segura 410 no son necesarias. El origen privado de la red 408 se refiere a la accesibilidad restringida de la red 408, acceso a la red 408 se restringe sólo a ciertos individuos (por ejemplo, restringido por el propietario u operador de centro de datos 410). El acceso de seguridad 404 es un grupo de uno o más dispositivos de cómputo de acceso de seguridad. Estos dispositivos de cómputo de acceso de seguridad colectivamente implementan acceso de seguridad 404. El acceso de seguridad 404 opcionalmente puede incluir uno o más dispositivos de balance de carga convencionales que operan para dirigir solicitudes para controlarse por los dispositivos de cómputo de acceso de seguridad a los apropiados de aquellos dispositivos de cómputo. Esta dirección o balance de carga se realiza en una forma que intenta balancear la carga en los varios dispositivos de cómputo de acceso de seguridad aproximadamente de igual forma (o alternativamente de acuerdo con algún otro criterio). También dentro del centro de datos 410 están: uno o más servidores de verificación 412; uno o más puertas frontales de presencia y notificación 414, uno o más servidores de presencia 416, uno o más servidores de notificación 418, y un almacenamiento de perfil 428 (que implementa colectivamente un servicio o sistema de presencia y notificación 430); una o más puertas frontales de encuentro 420 y uno o más servidores de encuentro 422 (que implementa colectivamente un servicio de encuentro); una o más puertas frontales de estadística 424 y uno o más servidores de estadística 426 (que implementan colectivamente un servicio de estadística). Los servidores 416, 418, 422, y 426 proporcionan servicios a consolas de juego 402, y de esa forma pueden denominarse como dispositivos de servicio. Otros dispositivos de servicio también pueden incluirse además de, y/o en lugar de, uno o más de los servidores 416, 418, 422, y 426. Adicionalmente, aunque solo se muestra un centro de datos en la Figura 4, alternativamente pueden existir múltiples centros de datos con los cuales pueden comunicarse las consolas de juego 402. Estos centros de datos pueden operar independientemente, o pueden operar alternativamente de forma colectiva (por ejemplo, para hacer un gran centro de datos disponible para las consolas de juegos 102, 402). Las consolas de juego 402 se sitúan remotamente del centro de datos 410, y acceden al centro de datos 410 a través de la red 406. Una consola de juego 402 que desea comunicarse con uno o más dispositivos en los registros de centro de datos para el centro de datos y establece un canal de comunicación seguro entre la consola 402 y el acceso de seguridad 404. La consola de juego 402 y el acceso de seguridad 404 codifican crípticamente y verifican paquetes de datos que pasan de regreso y hacia delante, con lo cual permite que los paquetes de datos se transmitan de forma segura entre ellos sin entenderse por cualquier otro dispositivo que puede capturar o copiar los paquetes de datos sin romper la codificación críptica. Cada paquete de datos comunicado de la consola de juegos 402 al acceso de seguridad 404, o del acceso de seguridad 404 a ia consola de juegos 402 puede tener datos insertados aquí. Estos datos insertados se denominan como el contenido o contenido de datos del paquete. Información adicional también puede incluirse inherentemente en el paquete basándose en el tipo de paquete (por ejemplo un paquete de latidos). El canal de comunicación seguro entre una consola 402 y un acceso de seguridad 404 se basa en un boleto de seguridad. La consola 402 se verifica a sí misma y el usuario(s) actual de la consola 402 a un centro de distribución calve 429 y obtiene, del centro de distribución clave 429, un boleto de seguridad. La consola 402 entonces utiliza este boleto de seguridad para establecer el canal de comunicación seguro con el acceso de seguridad 404. Al establecer el canal de comunicación seguro con el acceso seguridad 404, la consola de juego 402 y el acceso de seguridad 404 se autentifican así mismos para establecer una clave de seguridad de sesión que se conoce solo por la consola de juego particular 402 y el acceso de seguridad 404. Esta clave de seguridad de sesión se utiliza para codificar crípticamente datos transferidos entre la consola de juego 402 y el grupo de acceso de seguridad 404, para que ningún otro de los dispositivos (incluyendo otras consolas de juego 404) puedan leer los datos. La clave de seguridad de sesión también se utiliza para comunicar un paquete de datos como desde el acceso de seguridad 404 ó consola de juego 402 que el paquete de datos alega ser de este. De esa forma, al utilizar tales claves de seguridad de sesión, los canales de comunicación segura pueden establecerse entre el acceso de seguridad 404 y las varias consolas de juego 402. Una vez que se establece el canal de comunicación seguro entre una consola de juego 402 y el acceso de seguridad 404, los paquetes de datos codificados crípticamente pueden transmitirse seguramente entre los dos. Cuando la consola de juego 402 desea enviar datos a un dispositivo de servicio particular en el centro de datos 410, la consola del juego 402 codifica crípticamente los datos y los envía a un acceso de seguridad 404 que solicita que se dirijan al dispositivo(s) de servicio particular objetivo por el paquete de datos. El acceso de seguridad 404 recibe el paquete de datos y, después de verificar y descodificar crípticamente paquetes de datos, encapsula el contenido de datos del paquete en otro mensaje para enviarse al servicio apropiado a través de la red privada 408. El acceso de seguridad 404 determina el servicio apropiado para el mensaje basándose en el servicio(s) solicitado objetivo por el paquete de datos. Similarmente, cuando un dispositivo de servicio en el centro de datos 410 desea comunicar datos a una consola de juego 402, el centro de datos envía un mensaje al acceso de seguridad 404, a través de la red privada 408, que incluye el contenido de datos para enviarse a la consola de juego 402 así como una indicación de la consola de juego particular 402 a la cual se va enviar el contenido de datos. El acceso de seguridad 404 inserta el contenido de datos en un paquete de datos, y entonces codifica crípticamente el paquete de datos para que solo pueda descodificarse crípticamente por la consola de juego particular 402 y también autentifica el paquete de datos como desde el acceso de seguridad 404. Aunque se discutió aquí como paquetes de datos codificados crípticamente que se comunican principalmente entre el acceso de seguridad 404 y una consola de juego 402, alternativamente algunos paquetes de datos pueden codificarse crípticamente de forma parcial (algunas porciones de los paquetes de datos se codifican crípticamente mientras otras porciones de datos no se codifican crípticamente). Qué porciones de los paquetes de datos se codifican críticamente y cuáles no pueden variar basándose en los deseos de los diseñadores del centro de datos 410 y/o consolas de juego 402. Por ejemplo, los diseñadores pueden elegir permitir que se comuniquen datos de voz entre consolas 402 para que los usuarios de las consolas 402 puedan hablar uno con otro, los diseñadores además pueden elegir permitir que los datos de voz se descodifiquen crípticamente mientras se codifica crípticamente cualquier otro dato en los paquetes. Adicionalmente, en otra alternativa, algunos paquetes de datos pueden no tener porciones que se codifican crípticamente (es decir, el paquete de datos completo no se codifica crípticamente). Se debe notar que, aunque sí un paquete de datos no se codifica crípticamente o sólo se codifica crípticamente de forma parcial, todo el paquete de datos aún puede verificarse. Cada dispositivo de acceso de seguridad en el acceso de seguridad 404 es responsable del canal de comunicación seguro que típicamente tiene una o más consolas de juego 402, y de esa forma cada dispositivo de acceso de seguridad puede observarse como siendo responsable de manejar o controlar una o más consolas de juego. Los varios dispositivos de acceso de seguridad pueden estar en comunicación uno con otro y comunicar mensajes uno a otro. Por ejemplo, un dispositivo de acceso de seguridad que necesita enviar un paquete de datos a una consola de juego que no es responsable de manejar puede enviar un mensaje a los otros dispositivos de acceso de seguridad con los datos para enviarse a esa consola de juego. Este mensaje se recibe por el dispositivo de acceso de seguridad que es responsable de manejar la consola de juego y envía los datos apropiados a esa consola de juego. Alternativamente, los dispositivos de acceso de seguridad pueden estar conscientes de que consolas de juego se controlan por cuales dispositivos de acceso de seguridad, esto puede ser explícito, para que cada dispositivo de acceso de seguridad mantenga una tabla de consolas de juego controladas por los otros dispositivos de acceso de seguridad, o alternativamente implícito, tal como al determinar que dispositivo de acceso de seguridad es responsable de una consola de juego particular basándose en un identif icador de la consola de juego. El servidor(es) de verificación 412 opera para informar dispositivos en el centro de datos 410 de una consola de juego no disponible 402 ó un dispositivo de acceso de seguridad no disponible de acceso de seguridad 404. Las consolas de juego 402 pueden volverse no disponibles para una variedad de diferentes razones, tal como una falla de hardware o software, la consola que se apaga sin salir del registro del centro de datos 410, el cable de conexión de red a la consola 402 que se desconecta de la consola 402, otros problemas de red (por ejemplo, la LAN que la consola 402 está en malfuncionamiento), etc. Sim ilarmente, un dispositivo de acceso de seguridad del acceso de seguridad 404 puede volverse no disponible por una variedad de diferentes razones, tal como falla de hardware o software, el dispositivo que se apaga, el cable de conexión de red al dispositivo que se desconecta del dispositivo, otros problemas de red, etc. Cada uno de los dispositivos de acceso de seguridad en el acceso de seguridad 404 se verifica por uno o más servidores de verificación 412, que detecta cuando uno de los dispositivos de acceso de seguridad se vuelve no disponible. En el caso que un dispositivo de acceso de seguridad se vuelva no disponible, el servidor de monitoreo 412 envía un mensaje a cada uno de los otros dispositivos en el centro de datos 410 (servidores, puertas frontales, etc.) que el dispositivo de acceso de seguridad ya no está disponible. Cada uno de los otros dispositivos puede operar basándose en esta información mientras se ajusta (por ejemplo, puede asumir que las consolas de juego particulares se manejan por el dispositivo de acceso de seguridad que ya no está en comunicación con el centro de datos 410 y realiza varias operaciones de limpieza por consiguiente). Alternativamente, solo ciertos dispositivos pueden recibir tal mensaje del servidor de verificación 412 (por ejemplo, solo aquellos dispositivos que se refieren así los dispositivos de acceso de seguridad están disponibles). El acceso de seguridad 404 verifica las consolas de juego individuales 402 y detecta cuando una de las consolas de juego 402 se vuelve no disponible. Cuando el acceso de seguridad 404 detecta que una consola de juego ya no está disponible, el acceso de seguridad 404 envía un mensaje al servidor de verificación 412 que identifica la consola de juego no disponible. En respuesta, el servidor de verificación 412 envía un mensaje a cada uno de los otros dispositivos en el centro de datos 410 (o alternativamente solo a dispositivos seleccionados) que la consola de juego ya no está disponible. Cada uno de los otros dispositivos entonces puede operar basándose en esta información mientras observa que se ajusta. El servidor(es) de presencia 416 soporta y procesa datos concernientes al estado o presencia de un usuario dado registrado en el centro de datos 410 para juego en línea. El servidor(es) de notificación 418 mantiene múltiples filas de notificación de mensajes salientes destinados para un jugador registrado en el centro de datos 410. La puerta frontal de presencia y notificación 414 es uno o más dispositivos de servidor que operan como un intermediario entre el acceso de seguridad 404 y servidores 416 y 418. Uno o más dispositivos de balance de carga (no mostrados) pueden incluirse en la puerta frontal de presencia y notificación 414 para balancear la carga entre los múltiples dispositivos de servidor que operan como puerta frontal 414. El acceso de seguridad 404 comunica mensajes para servidores 416 y 418 a la puerta frontal 414, y la puerta frontal 414 identifica que servidor particular 416 ó servidor particular 418 se va a comunicar el mensaje. Al utilizar la puerta frontal 414, la implementación real de servidores 416 y 418, tal como que servidores son responsables de manejar datos con respecto a que usuarios, se abstraen del acceso de seguridad 404. El acceso de seguridad 404 simplemente puede dirigir mensajes hacia adelante que son objetivo del servicio de presencia y notificación para la puerta frontal de presencia y notificación 414 y confían en la puerta frontal 414 para dirigir los mensajes al apropiado de servidor(es) 416 y servidor(es) 418. El servidor(es) de contienda o encuentro 422 soporta y procesa datos concernientes al encuentro de jugadores en línea uno con otro. Un usuario en línea es capaz de anunciar un juego disponible para jugar a lo largo de varias características del juego (por ejemplo, la localización en donde se jugará un juego de fútbol, si un juego se va a jugar durante el día o en la noche, el nivel de habilidad de usuario, etc.). Estas varias características entonces pueden utilizarse como una base para coincidir diferentes usuarios en línea para jugar juegos juntos. La puerta frontal de encuentro 420 incluye uno o más dispositivos de servidor (y opcionalmente un dispositivo(es) de balance de carga) y opera para abstraer servidor(es) de encuentro 422 del acceso de seguridad 404 en una forma analógica a la puerta frontal 414 que abstrae servidor(es) 416 y servidor(es) 418. El servidor(es) de estadística 426 mantiene y procesa datos concernientes a varias estadísticas para juegos en línea. Las estadísticas específicas utilizadas pueden variar basándose en los deseos del diseñador de juego (por ejemplo, las 10 puntuaciones de tiempos superiores, una clasificación mundial para todos los jugadores en línea del juego, una lista de usuarios que encontraron la mayoría de los artículos o gastaron la mayoría del juego de tiempo, etc.). La puerta frontal de estadística 426 incluye uno o más dispositivos de servidor (y opcionalmente un disposítivo(s) de balance de carga) y opera para abstraer servidor(es) de estadística 426 del acceso de seguridad 404 en una forma analógica a la puerta frontal 414 que abstrae servidor(es) 416 y servidor(es) 418. El servidor(es) de título 432 puede proporcionarse para cada título de juego individual o programa soportado por el servicio en línea. Cada servidor de título 432 puede actuar como un servidor y comunicarse con consolas de juego 402 para ejecutar programas y/o módulos para conducir una sesión de juego en linea. El servidor 432 puede otorgarse con mucho, o poco, control sobre acciones en un juego como se desee por el desarrollador de juego. Por ejemplo, algunos juegos pueden confiar en el servidor de título centralizado 432 para realizar cálculos y procesamiento que tiene que hacer interacciones entre múltiples jugadores en diferentes consolas de juego 402, tal como determinar que personaje de jugador fue primero para un punto particular en un mapa, o controlar la apariencia de un ambiente común en el cual aparecen varios personajes de jugadores, y pueden confiar en las consolas individuales 402 para controlar la mayoría de los aspectos más especializados, tal como la presentación real de imágenes y resultados, y procesamiento inicial de entrada de usuario. Por otro lado, los juegos pueden confiar más en las consolas 402 para procesamiento. Las responsabilidades de procesamiento para un juego dado pueden distribuirse entre una pluralidad de consolas 402 que se conectan a una sesión de juego. O, el juego puede seleccionar un subgrupo de las consolas 402 conectadas a la sesión, y causar que la consola actúe como el servidor para la sesión. En tal situación, el servidor de titulo 432 simplemente puede coordinar comunicaciones entre las consolas de juego 402, o simplemente puede realizar funciones de arranque iniciales (por ejemplo, tipo de juego, autorización de arranque, etc.), y entonces esperar resultados. Los servidores de torneo 434 también pueden estar presentes para manejar funcionalidad de torneo. Esta funcionalidad se describirá en mayor detalle posteriormente, y se relacionara generalmente con la creación, manejo y/o fin de torneos de jugador múltiple en linea. Los varios servidores descritos anteriormente no necesitan residir en máquinas separadas, ya que algunos o todos de ellos pueden combinarse en un procedimiento máquina común. De esa forma, se puede observar que el acceso de seguridad 404 opera para proteger dispositivos en la zona segura del centro de datos 410 de la red pública no confiada 406. Las comunicaciones dentro de la zona segura del centro de datos 410 no necesitan codificarse crípticamente, como todos los dispositivos dentro del centro de datos 410 son confiados. Sin embargo, cualquier información para comunicarse de un dispositivo dentro del centro de datos 410 a una consola de juego 402 pasa a través del grupo de acceso de seguridad 404, en donde se codifica crípticamente de tal forma que puede descalificarse crípticamente solo por la consola de juego 402 objetivo por la información. Como se ilustra en la Figura 4, el servidor de título 432 y el servidor de torneo 434 pueden recibir detrás de un segundo acceso de seguridad 405. El acceso de seguridad 405 puede ser el mismo que el acceso de seguridad 404, o puede ser uno simplificado para omitir características no necesarias por sus servidores y dispositivos. Una o más características aquí descritas pueden representarse en instrucciones ejecutables por computadora (es decir, software) almacenado en memoria RAM 206, memoria no volátil 108, 208, 308, o cualquier otra memoria residente en la consola de juegos 102. Generalmente, los módulos de software incluyen rutinas, programas, objetos, componentes, estructuras de datos, etc. que realizan tareas particulares o implementan tipos de datos abstractos particulares cuando se ejecutan por un procesador en la computadora u otro dispositivo. Las instrucciones ejecutables por computadora pueden almacenarse en un medio legible por computadora tal como uno o más discos duros 208, medios de almacenamiento removibles 108 (por ejemplo, CD-ROM, DVD, disco, etc.), memoria de estado sólido, RAM 206, etc. Como se apreciará por un experto en la técnica, la funcionalidad de los módulos de software puede combinarse o distribuirse como se desee en varias modalidades. Además, la funcionalidad puede representarse en todo o en parte en equivalentes de firmware o hardware tal como circuitos integrados específicos de aplicación (ASIC), órdenes de entrada programable de campo (SPGA), y similares. Los aspectos aquí no se limitan a ambientes de cómputo de consola. De hecho, estos aspectos también pueden implementarse en juegos de video que operan en computadoras personales (PCs). La Figura 5A ilustra un ejemplo de un ambiente de sistema de cómputo adecuado 500 en el cual pueden implementarse las características aquí descritas. El ambiente de sistema de cómputo 500 solo es un ejemplo de un ambiente de cómputo adecuado y no pretende sugerir ninguna limitación al alcance de uso o funcionalidad de las características aquí descritas. El ambiente de cómputo 500 tampoco debe interpretarse como teniendo ninguna dependencia o requerimiento que se relaciona con cualquiera o combinación de componentes ilustrados en el ambiente operativo ilustrativo 500. Las características aquí son operacionales con numerosos otros ambientes o configuraciones de sistema de cómputo de propósito general o propósito especial. Ejemplos de sistemas de cómputo bien conocidos, ambientes, y/o configuraciones que pueden ser adecuados para uso incluyen, pero no se limitan a, computadoras personales, computadoras de servidor, dispositivos móviles o portátiles, sistemas de multiprocesador, sistemas a base de microprocesador, cajas de tv por cable, electrónica de consumidor programable, PCs de red, minicomputadoras, m acrocom putadoras , ambientes de cómputo distribuidos que incluyen cualquiera de los sistemas o dispositivos anteriores, y similares. Las características aquí pueden describirse en el contexto general de instrucciones ejecutables por computadora, tal como módulos de programa, que se ejecutan por una computadora. Generalmente, los módulos de programa incluyen rutinas, programas, objetos, componentes, estructuras de datos, etc., que realizan tareas particulares o implementan tipos de datos abstractos particulares. Las características también pueden practicarse en ambientes de cómputo distribuidos en donde las tareas se realizan por dispositivos de procesamiento remotos que se enlazan a través de una red de comunicaciones. En un ambiente de cómputo distribuido, los módulos de programa pueden localizarse tanto en medios de almacenamiento de computadora locales como remotos que incluyen dispositivos de almacenamiento de memoria. Con referencia a la Figura 5A, un sistema ilustrativo puede implementar las características aquí descritas incluye un dispositivo de cómputo de propósito general en la forma de una computadora 510. Los componentes de computadora 510 pueden incluir, pero no se limitan a, una unidad de procesamiento 520, una memoria de sistema 530, y un conductor común de sistema 521 que acopla varios componentes de sistema que incluyen la memoria de sistema a la unidad de procesamiento 520. El conductor común de sistema 521 puede ser cualquiera de varios tipos de estructuras de conductor común que incluyen un conductor común de memoria o controlador de memoria, un conductor común periférico, y un conductor común local que utiliza cualquiera de una variedad de arquitecturas de conductor común. A manera de ejemplo, y no de limitación, tales arquitecturas incluyen conductor común de Arquitectura estándar de industria (ISA), conductor común de Arquitectura de microcanal (MCA), conductor común de ISA mejorado (EISA), conductor común local de Asociación de estándares de electrónica de video (VESA), y conductor común de interconexión de componente periférico (PCI) conocido como conductor común de mezzanine. La computadora 510 típicamente incluye una variedad de medios legibles por computadora. Los medios legi les por computadora puede ser cualquier medio disponible que puede accederse por la computadora 510 e incluye tanto medios volátiles como no volátiles y medios removibles y no removibles. A manera de ejemplo, y no de limitación, los medios legibles por computadora pueden comprender medios de almacenamiento por computadora y medios de comunicación. Los medios de almacenamiento por computadora incluyen tanto medios volátiles y no volátiles, removibles y no removibles implementados en cualquier método o tecnología para almacenamiento de información tal como instrucciones legibles por computadora, estructuras de datos, módulos de programa u otros datos. Los medios de almacenamiento por computadora incluyen, pero no se limitan a, RAM, ROM, EEPROM, memoria flash u otra tecnología de memoria, CD-ROM, discos versátiles digitales (DVD) u otro almacenamiento de disco óptico, casetes magnéticos, cinta magnética, almacenamiento de disco magnético u otros dispositivos de almacenamiento magnético (en singular o plural), o cualquier otro medio que puede utilizarse para almacenar la información deseada y que puede accederse por la computadora 510. Los medios de comunicación típicamente representan instrucciones legibles por computadora, estructuras de datos, módulos de programa u otros datos en una señal de datos modulada tal como una onda portadora u otro mecanismo de transporte e incluye cualquier medio de entrega de información. El término "señal de datos modulada" significa una señal que tiene una o más de sus características establecidas o cambiadas de tal forma para codificar información en la señal. A manera de ejemplo, y no de limitación, los medios de comunicación incluyen medios por cable tal como una red por cable o conexión por cable directa, y medios inalámbricos tal como acústicos, RF, infrarrojos y otros medios inalámbricos. Las combinaciones de cualquiera de los anteriores también deben incluirse dentro del alcance de medios legibles por computadora. La memoria de sistema 530 incluye medios de almacenamiento por computadora en la forma de memoria volátil y/o no volátil tal como memoria de solo lectura (ROM) 531 y memoria de acceso aleatorio (RAM) 532. El sistema de entrada/salida básico 533 (BIOS), que contiene las rutinas básicas que ayudan a transferir información entre elementos dentro de la computadora 510, tal como durante el arranque, típicamente se almacena en ROM 531. La RAM 532 típicamente contiene datos y/o módulos de programa que son inmediatamente accesibles a y/o actualmente están siendo operados por la unidad de procesamiento 520. A manera de ejemplo, y no de limitación, la Figura 5A ilustra el sistema operativo 534, programas de aplicación 535, otros módulos de programa 536, y datos de programa 537. La computadora 510 también puede incluir otros medios de almacenamiento por computadora removí bles/no removibles, volátiles/no volátiles. A manera de ejemplo solamente, la Figura 5 ilustra una unidad de disco duro 541 que lee de o escribe a medios magnéticos no removibles, no volátiles, una unidad de disco magnético 551 que lee de o escribe a un disco magnético removible, no volátil 552, y una unidad de disco óptico 555 que lee de o escribe a un disco óptico removible, no volátil 556 tal como un CD ROM u otro medio óptico. Otros medios de almacenamiento por computadora removibles/no removibles, volátíles/no volátiles que pueden utilizarse en el ambiente operativo ilustrativo incluyen, pero no se limitan a, casetes de cinta magnética, tarjetas de memoria flash, discos versátiles digitales, cinta de video digital, RAM de estado sólido, ROM de estado sólido, y similares. La unidad de disco duro 541 típicamente se conecta al conductor común de sistema 521 a través de una interfase de memoria no removible tal como interfase 540, y unidad de disco magnético 551 y unidad de disco óptico 555 típicamente se conectan al conductor común de sistema 521 por una interfase de memoria no removible, tal como la interfase 550. Las unidades y sus medios de almacenamiento por computadora asociados discutidos anteriormente e ilustrados en la Figura 5A, proporcionan almacenamiento de instrucciones legibles por computadora, estructuras de datos, módulos de programa y otros datos para la computadora 510. En la Figura 5, por ejemplo, la unidad de disco duro 541 se ilustra como almacenando el sistema operativo 544, programas de aplicación 545, otros módulos de programa 546, y datos de programa 547. Se debe notar que estos componentes pueden ser los mismos que o diferentes al sistema operativo 534, programas de aplicación 535, otros módulos de programa 536, y datos de programa 537. El sistema operativo 544, programas de aplicación 545, otros módulos de programa 546, y datos de programa 547 aquí se les proporcionan números diferentes para ilustrar que, a un mínimo, son copias diferentes un usuario puede ingresar comandos e información en la computadora a través de dispositivos de entrada tal como un teclado 562 y dispositivo de señalamiento 561, comúnmente denominado como un ratón, seguibola o almohadilla táctil. Otros dispositivos de entrada (no mostrados) pueden incluir un micrófono, palanca de mandos, almohadilla de juegos, antena parabólica, escáner, o similares. Estos dispositivos de entrada y otros frecuentemente se conectan a la unidad de procesamiento 520 a través de un interfase de entrada de usuario 560 que se acopla al conductor común de sistema, pero puede conectarse por otra interfase y estructuras de conductor común, tal como un puerto paralelo, puerto de juegos o un conductor común en serie universal (USB). Un monitor 591 u otro tipo de dispositivo de presentación también se conecta al conductor común de sistema 521 a través de una interfase, tal como una interfase de video 590. Además del monitor, las computadoras también pueden incluir otros dispositivos de salida periféricos tal como bocinas 597 e impresora 596, que pueden conectarse a través de una interfase periférica de salida 595. La computadora 510 puede operar en un ambiente en red que utiliza conexiones lógicas a una o más computadoras remotas, tal como computadora remota 580. La computadora remota 580 puede ser una computadora personal, un servidor, un enrutador, una PC de red, un dispositivo par u otro nodo de red común, y típicamente incluye muchos o todos los elementos descritos anteriormente relativos a la computadora 510, aunque solo se ilustra un dispositivo de almacenamiento de memoria 581 en la Figura 5. Las conexiones lógicas ilustradas en la Figura 5 incluyen una red de área local (LAN) 571 y una red de área ancha (WAN) 573, pero también pueden incluir otras redes. Tales ambientes en red comúnmente están ubicados en oficinas, redes de computadora extendidas en empresa, intranets e Internet. Cuando se utiliza en un ambiente de red LAN, la computadora 510 se conecta a la LAN 571 a través de una interfase de red o adaptador 570. Cuándo se utiliza en un ambiente en red WAN, la computadora 510 típicamente incluye un módem 572 u otros medios para establecer comunicaciones en la WAN 573, tal como Internet. El módem 572, que puede ser interno o externo, puede conectarse al conductor común de sistema 521 a través de la interfase de entrada de usuario 560, u otro mecanismo apropiado. En un ambiente en red, los módulos de programa ilustrados relativos a la computadora 510, o porciones de la misma, pueden almacenarse en el dispositivo de almacenamiento de memoria remoto. A manera de ejemplo, y no de limitación, la Figura 5 ilustra programas de aplicación remotos 585 como residentes en el dispositivo de memoria 581. Se apreciará que las conexiones en red mostradas son ilustrativas y pueden utilizarse otros medios para establecer un enlace de comunicaciones entre las computadoras. Una interfase de programación (o más simplemente, interfase) puede observarse como cualquier mecanismo, procedimiento, protocolo para permitir que uno o más segmento(s) de código se comuniquen o accedan a la funcionalidad proporcionada por uno o más de otro segmento(s) de código. Alternativamente, una interfase de programación puede observarse como uno o más mecanismo(s), método(s), llamada(s) de función, módulo(s), objeto(s), etc. de un componente de un sistema capaz de acoplar comunicativamente uno o más mecanismo(s), método(s), llamada(s) de función, módulo(s), etc. de otro componente(s). El término "segmento de código" en la oración precedente pretende incluir una o más instrucciones o lineas de código, e incluye, por ejemplo, módulos de código, objetos, subrutinas, funciones, y así sucesivamente, sin importar la terminología aplicada o si los segmentos de código se recopilan de forma separada, o sí los segmentos de código se proporcionan como fuente, intermedio, o código de objeto, si los segmentos de código se utilizan en un sistema o procedimiento de tiempo de funcionamiento, o si se localizan en la misma o diferentes máquinas o se distribuyen a través de múltiples máquinas, o si la funcionalidad representada por los segmentos de código se implementa completamente en software, completamente en hardware, o una combinación de hardware y software. De forma de noción, una interfase de programación puede observarse genéricamente, como se muestra en la Figura 5B o Figura 5C. La Figura 5B ilustra una interfase Interfase 1 como un conductor a través del cual se pueden comunicar los primeros y segundos segmentos de código. La Figura 5C ilustra una interfase que comprende objetos de interfase 11 e 12 (que pueden o no ser parte de los primeros y segundos segmentos de código), que permiten que los primeros y segundos segmentos de código de un sistema se comuniquen a través del medio M. En la vista de la Figura 5C, uno puede considerar objetos de interfase 11 e 12 como interfases separadas del mismo sistema y también puede considerar que los objetos 11 e 12 más medio M comprende la interfase. Aunque las Figuras 5B y 5C muestran flujo bidireccional e interfases en cada lado del flujo, ciertas implementaciones solo pueden tener flujo de información en una dirección (o sin flujo de información como se describe posteriormente) o solo pueden tener un objeto de interfase en un lado. A manera de ejemplo, y no de limitación, los términos tal como interfase de programación de aplicación (API), punto de entrada, método, función, subrutina, llamada de procedimiento remoto, interfase de modelo de objeto de componente (COM), se abarcan dentro de la definición de interfase de programación. Aspectos de tal interfase de programación pueden incluir el método con el cual el primer segmento de código transmite información (en donde "información" se utiliza en su sentido más amplio e incluye datos, comandos, solicitudes, etc.) al segundo segmento de código; el método con el cual el segundo segmento de código recibe la información; la estructura, secuencia, sintaxis, organización, esquema, registro de tiempo y contenido de la información. Con respecto a esto, el medio de transporte fundamental por si mismo puede no ser importante para la operación de la interfase, si el medio es por cable o inalámbrico, o una combinación de ambos, mientras la información se transporta en la forma definida por la interfase. En ciertas situaciones, la información puede no pasarse en una o ambas direcciones en el sentido convencional, mientras la transferencia de información puede ser a través de otro mecanismo (por ejemplo información colocada en un amortiguador, archivo, etc. separados de flujo de información entre los segmentos de código) o no existentes, como cuando un segmento de código simplemente accede a la funcionalidad realizada por un segundo segmento de código. Cualquier otro de los aspectos puede ser importante en una situación dada, por ejemplo, dependiendo si los segmentos de código son parte de un sistema en una configuración acoplada de forma floja o herméticamente acoplada, y así esta lista debe considerarse ilustrativa y no limitante. Esta noción de una interfase de programación se conoce por aquellos expertos en la técnica y está clara a partir de la descripción detallada anterior de la invención. Sin embargo, existen otras formas para implementar una interfase de programación, y, a menos que se excluya expresamente, se pretende abarcar por las reivindicaciones mencionadas al final de esta especificación. Tales otras formas pueden parecer más sofisticadas o complejas que la vista más simple de las Figuras 5B y 5C, pero sin embargo realizan una función similar para realizar el mismo resultado total. Ahora se describirán brevemente algunas implementaciones alternativas ilustrativas de una interfase de programación.

A. FACTORIZACÍÓN Una comunicación de un segmento de código a otro puede realizarse indirectamente al dividir la comunicación en múltiples comunicaciones separadas. Esto se ilustra esquemáticamente en las Figuras 5D y 5E. Como se muestra, algunas ¡nterfases pueden describirse en términos de grupos divisibles de funcionalidad de esa forma, la funcionalidad de interfase de las Figuras 5B y 5C puede factorizarse para lograr el mismo resultado, justo como uno puede proporcionar matemáticamente 24, o 2 veces 2 veces 3 veces 2. Por consiguiente, como se ilustra en la Figura 5D, la función proporcionada por la interfase Interfase 1 puede subdividirse para convertir las comunicaciones de la interfase en múltiples interfases Interfase 1A, Interfase 1B, Interfase 1C, etc. mientras logra el mismo resultado. Como se ilustró en la Figura 5E, la función proporcionada por la interfase 11 puede subdividirse en múltiples interfases 11a, 11b, 11c, etc. mientras logra el mismo resultado. Similarmente, la interfase 12 del segundo segmento de código que recibe información del primer segmento de código puede factorizarse en múltiples interfaces 12 a , 12 b , 12 c , etc. Cuando se actualiza, el número de interfases incluido con el primer segmento de código no necesita coincidir con el número de interfases incluidas con el segundo segmento de código. En cualquiera de los casos de las Figuras 5D y 5E, el espíritu funcional de la interfase Interfase 1 e 11 permanecerá igual con las Figuras 5B y 5C, respectivamente. La factorización de interfases también puede permitir propiedades asociativas, comunicativas, y otras matemáticas para que la factorización pueda ser difícil de reconocer. Por ejemplo, ordenar las operaciones puede no ser importante, y en consecuencia, una función llevada a cabo por una interfase puede llevarse a cabo bien en un avance de alcanzar la interfase, por otra pieza de código o interfase, o realizarse por un componente separado del sistema. Además, un experto en la técnica de programación puede apreciar que existe una variedad de formas para hacer diferentes llamadas de función que logran el mismo resultado .

B. REDEFINICIÓN En algunos casos, puede ser posible ignorar, agregar o redefinir ciertos aspectos (por ejemplo, parámetros) de una interfase de programación mientras aún se realiza el resultado pretendido. Esto se ilustra en las Figuras 5F y 5G. Por ejemplo, se asume que la interfase Interfase 1 de la Figura 5B incluye una llamada de función Cuadrada (entrada, precisión, salida), una llamada que incluye tres parámetros, entrada, precisión y salida, y que se emite del primer segmento de código al segundo segmento de código. En la precisión de parámetro medio si no hay problema en un escenario dado, como se muestra en la Figura 5F, solo se ignorará o incluso se remplazará con un parámetro no significativo (en esta situación). Uno también puede agregar un parámetro adicional sin problema. En cualquier caso, la funcionalidad de cuadrado puede lograrse, mientras la salida se regresa después de que la entrada se pone en cuadrado por el segundo segmento de código. La precisión puede ser un muy buen parámetro significativo para alguna porción en sentido descendente u otra del sistema de cómputo; sin embargo, una vez que se reconoce que la precisión no es necesaria para el propósito estrecho de calcular el cuadrado, puede reemplazarse o ignorarse. Por ejemplo, en lugar de pasar un valor de precisión válido, un valor sin significado como una fecha de nacimiento puede pasarse sin afectar adversamente el resultado. Sim ilarmente, como se muestra en la Figura 5G, la interfase 11 se reemplaza por la interfase 11', redefinida para ignorar o agregar parámetros a la interfase. La interfase 12 similarmente puede redefinirse como la interfase 12', redefinida para ignorar parámetros innecesarios, o parámetros que pueden procesarse en alguna otra parte. El punto aquí es que en algunos casos una interfase de programación puede incluir aspectos, tal como parámetros, que no se necesitan para algún propósito, y pueden ignorarse o redefinirse, o procesarse en alguna otra parte para otros propósitos.

C. CODIFICACIÓN EN LÍNEA También puede ser factible fusionar alguna toda la funcionalidad de dos módulos de código separados para que la "interfase" entre ellos cambie de forma. Por ejemplo, la funcionalidad de las Figura 5B y 5C puede convertirse a la funcionalidad de las Figuras 5H y 51, respectivamente. En la Figura 5H, los primeros y segundos segmentos de código de previos de la Figura 5B pueden fusionarse en un módulo que contiene ambos de ellos. En este caso, los segmentos de código aún se comunicarán uno con otro pero la interfase puede adaptarse a una forma que es más adecuada para el módulo individual. De esa forma, por ejemplo, las declaraciones de Llamada y Regreso formales pueden ya no ser necesarias, pero aún puede estar en efecto el procesamiento similar o respuesta(s) consecuente a la interfase Interfase 1. Similarmente , mostrada en la Figuras 51, parte (o toda) la interfase 12 de la Figura 1C puede escribirse en línea en la interfase 11 para formar la interfase 11". Como se ilustró, la interfase 12 se divide en 12 a e ! 2 b , y la porción de interfase 12 a se codificó en línea con la interfase 11 para formar la interfase 11". Para un ejemplo concreto, se considera que la interfase 11 de la Figura 5C realiza una función cuadrada de llamada (entrada, salida), que se recibe por la interfase 12, que después de procesar el valor pasado con la entrada (para cuadrarlos) por el segundo segmento de código, pasa de regreso el resultado cuadrado con la salida. En tal caso, el procesamiento realizado por el segundo segmento de código (entrada cuadrada) puede realizarse por el primer segmento de código sin una llamada a la interfase.

D. DIVORCIO Una comunicación de un segmento de código a otro puede realizarse indirectamente al separar la comunicación en múltiples comunicaciones separadas. Esto se ilustra esquemáticamente en las Figuras 5J y 5K. Como se muestra en la Figura 5J, una o más pieza(s) de software medio (Interfase(s) de divorcio, ya que divorcian funcionalidad y/o funciones de interfase de la interfase original) se proporcionan para convertir las comunicaciones en la primera interfase, Interfase 1, para conformarlos a una interfase diferente, en este caso interfases Interfase 2a, Interfase 2b e Interfase 2c. Esto puede hacerse, por ejemplo, en donde existe una base instalada de aplicaciones diseñadas para comunicarse con, digamos, un sistema operativo de acuerdo con un protocolo de Interfase 1, pero entonces el sistema operativo se cambia para utilizar una interfase diferente, en este caso interfases Interfase 2A, Interfase 2B e Interfase 2C. El punto es que la interfase original utilizada por el segundo segmento de código cambia para que ya no sea compatible con la interfase utilizada por el primer Segmento de código, y así se utiliza un intermediario para hacer las viejas y nuevas interfases compatibles. Similarmente, como se muestra en la Figura 5K, puede introducirse un tercer segmento de código con la interfase de divorcio DI1 para recibir las comunicaciones de la interfase 11 y con la interfase de divorcio DI2 para transmitir la funcionalidad de interfase, por ejemplo, la interfase 12 a e 12 b , rediseñada para trabajar con DI2, pero para proporcionar el mismo resultado funcional. Similarmente, DI1 y DI2 pueden trabajar juntos para traducir la funcionalidad de interfases 11 e 12 de la Figura 5C a un nuevo sistema operativo, mientras proporciona el mismo o similar resultado funcional.

E. REESCRITURA Incluso otra variante posible es reescribir dinámicamente el código para remplazar la funcionalidad de interfase con algo más pero que logra el mismo resultado total. Por ejemplo, puede existir un sistema en el cual se proporciona un segmento de código presentado en un lenguaje intermedio (por ejemplo, Microsoft IL, Java Código de byte, etc.) para un recopilador Justo a tiempo (JIT) o intérprete en un ambiente de ejecución (tal como el proporcionado por la estructura .Net, el ambiente de tiempo de funcionamiento de Java, u otros ambientes de tiempo de funcionamiento similares). El recopilador de JIT puede escribirse para convertir dinámicamente las comunicaciones del primer segmento de código al segundo segmento de código, es decir, para conformarlas a una interfase diferente como puede requerirse por el segundo segmento de código (ya sea el segundo segmento de código original o uno diferente). Esto se ilustra en las Figuras 5L y 5M. Como se puede observar en la Figura 5L, este acercamiento es similar al escenario de Divorcio descrito anteriormente. Esto puede hacerse, por ejemplo, en donde se diseña una base instalada de aplicaciones para comunicarse con un sistema operativo de acuerdo con un protocolo de Interfase 1, pero entonces el sistema operativo cambia para utilizar una interfase diferente. El Recopilador JIT puede utilizarse para conformar las comunicaciones en el momento de las aplicaciones de base instaladas a la nueva interfase del sistema operativo. Como se ilustra en la Figura 5 , este aspecto de reescribir dinámicamente la interfase(s) puede aplicarse por factorización dinámicamente, o de otra forma alterar la interfase(s) también. Se debe notar que los escenarios antes descritos para lograr el mismo o similar resultado como una interfase a través de modalidades alternativas también pueden combinarse de varias formas, en serie y/o en paralelo, o con otro código de intervención.

De esa forma, las modalidades alternativas presentadas anteriormente no son mutuamente exclusivas y pueden mezclarse, coincidirse y combinarse para producir los mismos o equivalentes escenarios para los escenarios genéricos presentados en las Figura 5B y 5C. También se debe notar que, como con la mayoría de las construcciones de programación, existen otras formas similares de lograr la misma o similar funcionalidad de una interfase que pueden no describirse aquí, pero sin embargo se representan por el espíritu y alcance de la invención, es decir se nota que es al menos en parte la funcionalidad representada por, y los resultados ventajosos habilitados por, una interfase que yace bajo el valor de una interfase. Los sistemas antes mencionados pueden utilizarse para implementar los métodos o sistemas de depuración aquí descritos. Varias características proporcionan la automatización de información de realimentación de depuración a un servidor al tirar porciones de memoria y automáticamente enviar la memoria desechada a un servidor cuando ocurren ciertos eventos de depuración. La Figura 6 ilustra un procedimiento total ilustrativo por el cual un torneo puede conducirse en un ambiente de juego de jugador múltiple linea. En el paso 601, un administrador de torneo puede tomar pasos para registrarse en un servidor seguro, tal como servidor de torneo 434, para comenzar la creación de un torneo en línea. El administrador puede ser un desarrollador de juego, jugador, o cualquiera que tenga el derecho de crear nuevos tipos de torneo en el sistema. El registro en proceso puede involucrar cualquier modo deseado de acceso, tal como acceder a un sitio de internet seguro que utiliza una contraseña y una terminal de computadora 510, o acceder a una localización en línea que utiliza una interfase de usuario de video juego de una consola 402. En el paso 602, el administrador de torneo puede definir los varios parámetros para el torneo que se crea. Esta entrada puede realizarse al utilizar una interfase presentada, tal con una página de Internet o una interfase de usuario de video juego, en donde el administrador puede impulsarse a ingresar (o seleccionar de una lista) los varios parámetros del torneo que se define. Los parámetros ilustrativos se discuten además posteriormente. Cuando los parámetros de torneo han sido definidos, el procedimiento entonces puede proceder al paso 603, en donde el sistema (por ejemplo, el servidor de torneo 434, o servidor de título 432, dependiendo que servidor se designa para la tarea) espera un activador para iniciar un torneo. El activador puede ser de cualquier tipo de evento predeterminado, tal como el pasaje de una cantidad de tiempo predeterminada (por ejemplo, 1 hora, 30 minutos, etc.), o el registro por un número predeterminado de jugadores (por ejemplo, 10, 50, 100 jugadores, etc.). Cuando se recibe o cuando ocurre el activador, el procedimiento puede proceder con inicio de un torneo en el paso 604. El inicio puede involucrar la ejecución de una o más secuencias de procesamiento que llevarán a cabo el torneo como se especificó en los parámetros. Estas secuencias pueden ejecutarse por el servidor de torneo 434, servidor de título 432, consolas individuales 402, o cualquier otro componente de cómputo en el sistema, y puede distribuirse a través de componentes (por ejemplo, a través de múltiples consolas 402) si se desea. Un caso de un torneo puede asignarse con su propia ID de torneo única para ayudar a coordinar comunicaciones con clientes que participan en el caso de torneo. Cuando se crea un caso de torneo, el torneo puede asignarse con una ID de puntuación. El servicio en línea fundamental (por ejemplo, XBOX LIVE™) puede proporcionar un grupo común de estructuras de datos de marcación que están disponibles para uso por los varios programas de juegos soportados por las consolas. Alternativamente, las estructuras de datos de puntuación pueden ser una estructura de costumbre creada para soportar cada caso de torneo, por ejemplo, al soportar las marcas de calificación para el caso de torneo dado. Estas estructuras pueden ser un objeto de base de datos definido que almacena identif icadores para varios jugadores, y uno o más valores de datos para un desempeño de jugador en un juego (por ejemplo, un tiempo de carrera del jugador, automóvil favorito, marcación, registro de ganado/perdido, marcaciones totales, oponentes con los que se jugó, etc.), y clientes de juego en consolas 402, servidores de torneo, y otros dispositivos pueden correr consultas SQL a la estructura de datos de puntuación para obtener una sesión de juego y resultados de torneo. La puntuación puede manejarse con un procedimiento de software por un servidor de título 432, un servidor de estadísticas 424, o cualquier otro dispositivo deseado en el sistema. En algunos casos, pueden utilizarse diferentes estructuras de puntuación para diferentes aspectos de un torneo. Por ejemplo, un servidor de título 432 puede manejar una puntuación de calificación, que acepta y procesa los datos de calificación para varias entradas de torneo (explicadas posteriormente), mientras un servidor de estadísticas 424 puede manejar una estructura de datos de puntuación de marcas totales para rastrear el progreso de jugador a través del torneo. Una vez que se inicia el torneo, el procedimiento conduce al torneo en el paso 605. La ejecución real del código de torneo para manejar el torneo puede ocurrir en cualquier servidor, tal como en el Servidor de torneo 434, Servidor de título 432, y/o consolas de juego 402, mientras diferentes torneos se conducen de forma diferente dependiendo de los parámetros elegidos por el administrador de torneo. Ejemplos de torneos se describen posteriormente con respecto a las Figuras 8-9. Cuando se condujo el torneo (o una porción del mismo, tal como una ronda), el procedimiento puede moverse al paso 606, en donde los varios clientes de juego reportan sus resultados al servidor que manejó el torneo. Los clientes pueden ser código de juego que corre en consolas individuales 402, y cada consola puede ser responsable de reportar resultados al servidor de torneo. Esos resultados pueden incluir información con respecto al desempeño del jugador de la consola particular 402, y también pueden incluir información con respecto al desempeño de algunos o todos los otros jugadores que participaron en la sesión de juego (por ejemplo, una consola de jugador puede reportar no sólo la marcación del jugador, si no las marcaciones de todos los otros jugadores en la sesión de juego también, esta información reportada múltiple puede compararse contra otra para confirmar que no ocurrió trampa, como se discutirá además posteriormente). Alternativamente, ya que múltiples consolas 402 pueden participar en la sesión de juego individual, este reporte puede coordinarse entre las consolas 402 para que una de las consolas que participan en la sesión pueda designarse para reportar los resultados de cualquiera que jugó en la sesión, y las otras consolas en la sesión pueden evitar duplicar ese reporte. Estos resultados también pueden reportarse al servidor que corre la puntuación, tal como Servidor de estadísticas 424, que utiliza las comunicaciones seguras requeridas por ese servidor. El reporte separado de los resultados a la puntuación puede ayudar a resolver anomalías en datos que se reportaron al servidor de torneo, como se dirigirá en mayor detalle posteriormente. Los resultados reales pueden estar en cualquier forma, dependiendo del tipo de juego que se juega, y generalmente pueden reportar logros hechos por los jugadores en la sesión de juego. Por ejemplo, un juego de tipo de tirador de primera persona puede reportar la relación de golpe de jugador, arma favorita, etc., mientras un juego de fútbol puede reportar el resultado de ganancia/pérdida del juego, la puntuación, y otras estadísticas de jugador y/o juego. Los juegos pueden utilizar su propio criterio al evaluar un desempeño de jugador y al obtener puntos, clasificación, u otras recompensas, y tales recompensas pueden reportarse como el resultado. Ya que el servidor de torneo recibirá resultados de torneo de una variedad de clientes, y puede recibir múltiples reportes de cada desempeño de jugador, pueden ocurrir inconsistencias y anomalías. Por ejemplo, dos consolas 402 pueden reportar resultados de juego inconsistentes para un juego individual, o para un jugador individual en el juego (por ejemplo, cada uno que reporta un ganador diferente, marcación, estadística, etc.). En juegos en los cuales ocurren migración de huésped (por ejemplo, juegos en donde una de las consolas participantes en la sesión se designa como un huésped de servidor local para el juego, pero en donde la consola experimenta una caída o falla durante la sesión y una consola participante diferente se toma como huésped), diferentes consolas pueden reportar resultados incompletos o de otra forma inconsistentes. En el paso 607, el servidor de torneo puede comparar resultados reportados de diferentes clientes, y observar inconsistencias en los resultados reportados. Adicionalmente, el servidor puede comparar los resultados con una estructura de datos predefinida que identifica resultados normales o aceptables para ver si cualquiera de los resultados reportados está más allá de los límites que se consideran normales o aceptables para la sesión de juego que se jugó. Por ejemplo, en un juego de fútbol típico, el diseñador de juego puede decidir que una puntuación que excede un total de punto predefinido (por ejemplo, más de 100 puntos) puede ser anormal. Si se detecta una anomalía, el procedimiento se mueve al paso 608, en donde un procedimiento de arbitraje analiza los resultados reportados para dirigir y/o corregir la anomalía. Este procedimiento de arbitraje puede involucrar consultar el servidor de puntuación para recuperar resultados de jugador individuales, y realizar la comparación. O, el arbitraje puede involucrar reportar el conflicto aparente al servidor que maneja la puntuación a la cual se asigna el torneo, y ese servidor (por ejemplo, el Servidor de estadísticas 424) puede hacer su propia comparación de los resultados que recibe, y puede correr seguridad adicional y/o revisiones de integridad para confirmar que grupo de resultados es el grupo genuino. El procedimiento de arbitraje puede acceder a datos almacenados que identifican la credibilidad relativa de los jugadores involucrados. Cuando el procedimiento de arbitraje identifica el error en los resultados reportados, el procedimiento en el paso 609 puede actualizar los datos de puntuación y corregir el error. Si no se detectan anomalías, o después que se corrigen las anomalías, el procedimiento puede proceder al paso 610 y verifica para ver sí el torneo debe concluirse. Diferentes torneos pueden tener diferentes parámetros que definen como terminar el torneo. Por ejemplo, el parámetro de Ganador de Torneo puede utilizarse como se describe posteriormente. En este paso, el procedimiento de torneo puede comparar los resultados reportados, o los resultados totales, con el parámetro(s) que define un ganador de torneo, y decidir si se encontró un ganador y debe concluir el torneo. Si el torneo no ha concluido, el procedimiento puede regresar al paso 605 para continuar la conducción del torneo. Por ejemplo, esto puede confeccionar el procesamiento de la siguiente ronda del torneo. Si va a concluir el torneo, el procedimiento puede moverse al paso 611 y concluir el torneo. Esta conclusión puede involucrar las cuentas finales de puntuaciones y resultados del objeto de datos de puntuación para determinar clasificaciones de jugador y un ganador de torneo. La conclusión de un torneo frecuentemente involucrará el otorgamiento de un premio al ganador y aquellos que terminan en lugares predefinidos (por ejemplo, segundo, tercero, los 10 primeros, etc.). Los premios pueden ser artículos físicos proporcionados por un patrocinador de torneo, o artículos virtuales en juego tal como un automóvil de carreras con diseño particular, equipo o arma especial, etc. La conclusión del torneo también puede incluir liberar la ID de puntuación para permitir que el objeto de datos de Puntuación de torneo se utilice para otro torneo u otro juego, registrar resultados en una base de datos de archivo para acceso futuro, registrar las marcaciones altas, etc. Con la conclusión de un torneo, el procedimiento entonces puede regresar al paso 603 para esperar el siguiente evento de activación. Si se desea, el parámetro de activador de torneo puede definirse para crear automáticamente el caso de torneo si uno no existe todavía, o inmediatamente después de que concluya el torneo, para que el torneo pueda ser continuamente disponible para jugadores. Como se notó anteriormente, múltiples casos de un torneo pueden existir simultáneamente, si se desea, para que el inicio de un segundo torneo no necesite depender de la conclusión de un caso previo. Por ejemplo, la conclusión de un caso de torneo simplemente puede terminar el procedimiento, con procedimientos separados que ocurren para cada caso independiente. La Figura 6 anterior denominada a un paso de parámetros de torneo de definición, y para elaborar en ese paso, la siguiente discusión dirige varios parámetros de torneo ilustrativos que pueden utilizarse: Nombre de Torneo, una secuencia de texto dada por el administrador para identificar el torneo para participantes (por ejemplo, un Festival de asesinato de Halo™ patrocinado por Microsoft"). Propietario de Torneo, una identificación de un administrador para el torneo. Por ejemplo, el propietario de un torneo puede ser el desarrollador de juego, o un patrocinador para el torneo. Tipo de Torneo, una identificación de un tipo predefinido de torneo. El Servidor de torneo 434 puede ofrecer un número de tipos predefinidos de torneos (por ejemplo, eliminación individual, eliminación doble, otros como se describió posteriormente, etc.) que pueden accederse y adaptarse por el administrador. Número de Entrantes de Torneo, uno o más valores que identifican un mínimo, máximo, escala, y/o número preferido de participantes de jugador totales soportado en el torneo. Algunos torneos pueden adecuarse mejor para escalas más pequeñas, mientras otros formatos pueden ser más ideales para gran número de jugadores. Número de Entrantes de Sesión de Juego, uno o más valores que identifican el mínimo, máximo, escala, y/o número preferido de jugadores que participan en cada sesión de juegos del torneo. Una sesión de juego puede definirse por cada juego de forma diferente, y puede referirse a una unidad básica de juego en el juego. Esto puede diferir dependiendo del tipo de juego. Por ejemplo, un juego de ajedrez involucrados entrantes por sesión (por ejemplo, un tablero), pero un juego de poker puede involucrar cinco entrantes por sesión (por ejemplo, una mesa). Número de Rondas, uno o más valores que identifican un mínimo, máximo, escala, y/o número preferido de rondas por el torneo una ronda de un torneo puede definirse para ocurrir cuando cada entrante de torneo juega en una sesión de juego. Factor de Ventana, en algunos torneos, los jugadores para una sesión de juego particular (por ejemplo, una "encuentro de muerte" individual que involucra un número de jugadores) se agrupan basándose, al menos en parte, en hace cuánto fue la última vez que los jugadores jugaron uno contra otro. El factor de ventana puede identificar un tiempo, que puede medirse en términos de sesiones de juego, rondas y/o torneos, así como segundos, minutos, horas, días, semanas, etc., que se requiere para pasar antes que los jugadores jueguen de nuevo en la misma sesión de juego del torneo. Por ejemplo, un torneo puede especificar un factor de ventana de dos sesiones de juego, que significa antes que dos jugadores se agrupen para un juego, no tienen que pelear uno contra otro por al menos dos juegos. El uso de un factor de ventana puede ser particularmente deseable para torneos que tienen duración limitada, o números muy grandes de contiendas y jugadores. Para soportar el uso de un factor de ventana, el caso de torneo puede almacenar una tabla de datos que identifica la última vez que cada par de jugadores en el torneo jugaron uno contra otro en el torneo. Espacio de clasificación, en algunos torneos, los jugadores pueden agruparse de acuerdo con su puntuación, clasificación, nivel de habilidad, etc., y un espacio de clasificación puede identificar una escala de clasificaciones dentro de la cual los jugadores se permite que se agrupen juntos. Por ejemplo, un torneo puede desear solo agrupa jugadores si están dentro de 20 puntos uno de otro, o si sus clasificaciones totales están dentro de número de clasificaciones (por ejemplo, jugadores de no más de 10 clasificaciones superior o inferior que otro) o porcentaje (por ejemplo, porcentaje del número total de entrantes en el torneo) de otro. Opciones de Programación, estas opciones identifican la programación en la cual se jugara el torneo. Un torneo puede ser continuo, en el cual se inicia una nueva ronda automáticamente con el término de una ronda previa, o de acuerdo con un programa. El programa puede indicar ciertos marcos de tiempo en los cuales pueden conducirse las rondas y sesiones de juego, tal como un torneo solo de fin de semana, un torneo diario, una fecha especifica y/o tiempo del día, cada 30 minutos, etc. Nuevo factor de jugador, uno o más valores que identifican como se utilizarán las nuevas marcaciones de jugadores en clasificaciones. Las clasificaciones de punto se dirigen en mayor detalle posteriormente, pero para algunos torneos, los jugadores se clasifican de acuerdo con valores de datos que pueden no tener gran sentido estadístico al inicio de la participación del jugador. Por ejemplo, un torneo que simplemente clasifica jugadores basándose en registro de ganancias/pérdidas puede clasificar un jugador no vencido 30-0 igual que un nuevo jugador con un registro 1-0 (ambos son 100% ganadores), incluso aunque el nuevo jugador pueden no merecer verdaderamente tal clasificación elevada. Para acomodar esto, el torneo puede utilizar un nuevo factor de jugador, en el cual se ajustan nuevas marcaciones de jugador antes de utilizarse en clasificación. Por ejemplo, así una nueva marcación de jugador puede reducirse al 75% cuando solo está disponible una marcación de sesión de juego, 50% cuando están disponibles dos marcaciones de sesiones de juego, 25% cuando las tres marcaciones de sesiones de juego están disponibles, y no descontarse del todo si cuatro o más marcaciones de sesión de juego están disponibles. El nuevo factor de jugador puede identificar una duración para el efecto (por ejemplo, número de rondas o sesión de juegos), y un valor de ajuste para el efecto (por ejemplo, descuento de marcación, adición/substracción de valor de punto, etc.). Evento de activador, una identificación de uno o más eventos que causará que se cree un caso de torneo. Esto puede relacionarse con el parámetro de programación descrito anteriormente, en cuyo caso un evento de activador simplemente será el tiempo del dia que coincide con el programa. También pueden utilizarse otros tipos de activadores. Por ejemplo, un torneo puede comenzar automáticamente cuando un número de jugadores predeterminados se registro para el torneo, o con la entrada de un comando por uno o más jugadores que ya están registrados para el torneo (por ejemplo, todos los jugadores registrados que presionan un botón de controlador para señalar su disponibilidad). Ganador de torneo, uno o más valores que identifican la forma en la cual se determina un ganador del torneo. Esto puede ser un total de punto predeterminado (por ejemplo, el primer jugador para alcanzar 1000 puntos; o la persona con el tiempo total inferior en una carrera), un evento de juego predeterminado (por ejemplo, el primer jugador para realizar un objetivo dado dentro del juego) o una clasificación que sigue un número de rondas (por ejemplo, el jugador con la clasificación superior después de la última ronda), etc. Opciones específicas de juego, un número de otras opciones que pueden ser específicas para juegos particulares. Estas pueden incluir la identificación de pistas de carrera, condiciones de clima, tipos de automóvil, y marcaciones de punto para un torneo de juego de carrera, o la identificación de un tipo de mapa, carga de arma, y marcación para un torneo de tirador de primera persona. Los varios parámetros de torneo pueden almacenarse en una estructura de datos de paquete de datos de torneo 701, como se muestra en la Figura 7. Esta estructura de datos puede incluir una o más listas de rondas 702, en donde cada lista de ronda incluye datos para un segmento/etapa/subgrupo de rondas en un torneo. Por ejemplo, el torneo ilustrativo 701 es un torneo que incluye 13 rondas, divididas en tres segmentos o etapas. La lista de ronda puede incluir una porción de encabezados 703 que contiene información para la lista particular, tal como una identificación del número de rondas en la lista, y configuraciones comunes, parámetros, o temas para la rondas en la lista (por ejemplo, todas las carreras de la lista 1 estarán en la pista de carreras de "Nueva York", o todas las carreras en la lista 1 ocurrirán con el clima establecido en "lluvioso"). Esta lista también puede incluir una pluralidad de configuraciones de ronda individuales 704, conteniendo parámetros que se utilizarán para cada sesión de juego correspondiente. Por ejemplo, una primera configuración de ronda puede indicar que solo pueden utilizarse carros de baja energía para la primera carrera, mientras la segunda configuración de ronda puede indicar que solo pueden utilizarse carros de motor de cuatro ruedas para la segunda carrera. El siguiente seudocódigo proporciona un ejemplo de un paquete de datos de torneo: «^CONFIGURACIONES DE JUEGO> <PAQUETE 1> <NOMBRE> Nombre de Secuencia de Texto de Paquete </NOMBRE> <LISTA 1> <NOMBRE> Control para Lista </NOMBRE> <NOMBRE VISIBLE> Nombre de Lista de Secuencia de Texto Presentada </NOM BRE VISIBLE> <RONDA> <CODIGO 1> 1011 </CODIGO 1> <CODIGO 2> 1000 </CODIGO 2> <CODIGO 3> 1190 </CODIGO 3> <CODIGO 4> 0 </CODIGO 4> </RONDA> <RONDA> <CODIGO 1> 1000 </CODIGO 1> <CODIGO 2> 1000 </CODIGO 2> <CODIGO 3> 1193 </CODIGO 3> <CODIGO 4> 0 </CODIGO 4> </RONDA> </LISTA 1> <LISTA 2> <NOMBRE> Control para Lista </NOMBRE> <NOMBRE VISIBLE> Nombre de Lista de Secuenci de Texto Presentada </NOMBRE VISIBLE> < RON DA> <CODIGO 1 > 1011 </CODIGO 1 > <CODIGO 2> 1000 </CODIGO 2> <CODIGO 3> 1190 </CODIGO 3> <CODIGO 4> 0 </CODIGO 4> </RONDA> < RON DA> <CODIGO 1> 1000 </CODIGO 1> <CODIGO 2> 1000 </CODIGO 2> <CODIGO 3> 1193 </CODIGO 3> <CODIGO 4> 0 </CODIGO 4> </RON DA </LISTA 2> </PAQ U ETE 1> </CONFIGURACIONES DE JUEGO> En el ejemplo precedente, un archivo de configuraciones de torneo puede incluir múltiples paquetes, cada paquete puede incluir múltiples listas, y cada lista puede incluir valores de datos para el control interno de lista, un valor de texto para presentarse, y uno o más códigos de juego para configuraciones en el juego. Los códigos de juego pueden ser valores numéricos que corresponden a entradas en una tabla utilizada por el programa de juego para configurar el juego. Por ejemplo, un juego de carrera puede proporcionarse con 16 pistas de carrera diferentes, y el código '1011' puede ser un índice binario en una tabla que enlista estas pistas, que identifican la onceava pista para uso. Otros códigos pueden ser similarmente índices en otras tablas de configuración, tal como tablas para el clima, la transmisión de automóvil, la dirección de la pista, tipo de automóvil, etc. El siguiente ejemplo ilustra cómo debe configurarse tal tabla: <TIPO DE TRANSMISION> O-Manual 1 -Automático <TIPO DE CLIMA> O-Normal 1 -Soleado y Caluroso 2- Lluvioso 3- N ieve 4- Hielo 5- Fuerte Viento Adicionalmente, los valores no necesitan ser todos códigos de índice en tablas. Por ejemplo, un valor parar los caballos de fuerza máximo simplemente puede incluir un valor numérico para esos caballos de fuerza máximos. También pueden incluirse otros datos, tal como los datos de programa para el caso de torneo (por ejemplo, que tan frecuentemente el torneo puede hacer caso, condiciones, etc.), y para rondas individuales dentro de un caso (por ejemplo, que tan frecuentemente ocurren las rondas). Como se notó anteriormente, puede existir una variedad de tipos de torneo. La eliminación individual, eliminación doble y torneos de tipo de todos contra todos pueden utilizarse. La Figura 8 ilustra un ejemplo de otro tipo de torneo que puede utilizarse. En el torneo de la Figura 8, los jugadores inician en el paso 801 al registrarse para participar en el torneo. El registro puede hacerse en varias formas. Por ejemplo, el jugador puede registrarse en un servidor, tal como un Servidor de título 432 ó Servidor de torneo 434, y consultar al servidor para tener una lista de torneos disponibles que se abre para registro. El servidor consultado puede regresar una lista de torneos disponibles, presentar los parámetros de torneos relevantes (por ejemplo, nombre de torneo, número de rondas, número de entrantes ya registrados, tiempo de inicio, premio, etc.), y el usuario puede registrarse para uno al presionar un botón en un controlador con un torneo particular resaltado. Alternativamente, los jugadores pueden unirse a un torneo como un resultado de recibir una invitación enviada por otro jugador que ya se registró para el torneo. El registro de jugador 801 puede continuar hasta un tiempo predeterminado (por ejemplo, tiempo transcurrido desde que se creó el caso de torneo, tiempo de día para torneo programado, tiempo transcurrido desde el primer registro, etc.), pasos, o hasta que se unieron un número de registrados predeterminados (por ejemplo, el parámetro de torneo que define un número máximo de entrantes). Cuando el registro termina, el torneo puede comenzar al colocar inicialmente los entrantes en un orden aleatorio, o seudoaleatorio, en el paso 802. Esta colocación inicial de clasificación puede hacerse de cualquier forma deseada, tal como alfabéticamente, o en orden de registro, debido a que el orden pronto se reordenará. Entonces, en el paso 803, el procedimiento puede determinar el número de jugadores para utilizarse en la sesión de juego para la siguiente ronda. Esto puede hacerse al consultar el parámetro de Número de Entrantes de sesión de juego descrito anteriormente, pero también puede involucrar cálculos y ajustes basándose en el número total de entrantes. Por ejemplo, el procedimiento puede realizar cálculos (por ejemplo, dividir el número total de entrantes por los varios valores en el parámetro de Número de Entrantes de sesión de juego) para encontrar un tamaño de sesión ideal un tamaño de sesión ideal puede ser un tamaño que permite que todas las sesiones tengan el mismo número de jugadores, o para todas las sesiones para diferir en tamaño por no más de un jugador (o cualquier otro valor predeterminado). La determinación de un tamaño de sesión también puede dar preferencia a utilizar mayores (o menores) números de jugadores por sesión de juego, o al tener un número que está más cerca de un número preferido especificado en el parámetro. Cuando el procedimiento ha determinado el número de jugadores para estar en una sesión que se completó, el procedimiento puede preceder al paso 804, y comenzar el llenado de un nuevo grupo para la siguiente sesión de juego. En el paso 805, el jugador de clasificación superior aún no se asignó con el grupo que se asigna en nuevo grupo. En el paso 806, los datos para el siguiente jugador no asignado superior (por ejemplo, un jugador potencial) se recuperan, y en el paso 807, se hace una revisión para ver si el jugador potencial recientemente jugó con cualquier otro de los jugadores ya asignados en el grupo actual. Esto puede hacerse, por ejemplo, al consultar una tabla almacenada que mantiene el rastro de la última vez que cada par de entrantes jugaron juntos en una sesión de juego. Si el jugador potencial no jugó demasiado recientemente con uno de los otros jugadores en el grupo, entonces el jugador potencial se agrega al grupo del paso 808. Por otro lado, el jugador potencial jugó muy recientemente, entonces el procedimiento salta el jugador potencial y se mueve en el paso 809, en donde se hace una revisión para ver si el grupo actual está lleno. Si el grupo no está lleno, el procedimiento regresa al paso 806 para recuperar información para el siguiente jugador no asignado. El grupo está completo, el procedimiento se mueve al paso 810 para ver si existen jugadores no asignados restantes. Si los hay, el procedimiento regresa al paso 804 para comenzar a llenar un nuevo grupo. Un paso opcional, no mostrado, puede tomarse si los últimos pocos jugadores no asignados todos jugaron demasiado recientemente uno con otro. En esta situación, el procedimiento simplemente puede abandonar el criterio de Factor de Ventana para estos jugadores, y agruparlos en uno o más grupos finales. Alternativamente, el sistema puede ajustar el factor de ventana por una cantidad predeterminada (por ejemplo, al reducirla por uno), y comenzar el procedimiento de nuevo.

Si todos los jugadores se asignaron a grupos, entonces el procedimiento se mueve al paso 811, en donde los jugadores entonces jugarán una sesión de juego. Cuando se completa la sesión de juego (por ejemplo, los jugadores terminan de correr una carrera, completan un juego de fútbol, terminan una encuentro de muerte, etc.), el procedimiento se mueve al paso 812 en el cual los jugadores se asignan con puntos basándose en su desempeño en la sesión de juego. Estos puntos pueden variar dependiendo del tipo de juego, con diferentes puntos que se obtienen por diferentes logros de juego. Varios tipos de mecanismos de puntuación pueden utilizarse. Por ejemplo, el servidor de torneo puede registrar marcaciones de juego para logros hechos por cada jugador durante la sesión de juego más reciente, marcaciones de juego acumulativas para contar los puntos acumulados por cada jugador de esa forma en el torneo, marcaciones de encuentro que toman en cuenta el número y/o clasificación de los jugadores contra los que se jugó (por ejemplo, un punto para cada jugador derrotado en una sesión dada), y una marcación acumulativa disponible que indica el número máximo de puntos que el jugador de esa forma pudo acumular en el torneo. El servidor o la consola que realizan la asignación de punto también pueden realizar cálculos para propósitos de clasificación. Por ejemplo, el procedimiento de torneo puede calcular un porcentaje de marcación que indica el porcentaje de la marcación máxima posible que el jugador obtuvo (por ejemplo, el dividir la marcación de juego acumulativa del jugador por la marcación acumulativa disponible). El procedimiento puede aplicar el parámetro de Factor de Nuevo jugador para ajustar una marcación de nuevo jugador antes de que se utilice para reclasificar el jugador (en el siguiente paso). Entonces, en el paso 813, el procedimiento puede reordenar, o reclasificar, los varios jugadores basándose en sus marcaciones totales y/o su porcentaje de marcación como se discutió anteriormente. Cuando los jugadores han sido reordenados, el procedimiento puede revisar en el paso 814 para ver si se jugaron más rondas. Esta determinación puede basarse en si los jugadores jugaron el número de rondas requisito, o si un jugador logró alguna otra condición para ganar, como se especificó en los parámetros de torneo. Si se jugaron más rondas, el procedimiento puede regresar al paso 804 para reagrupar los jugadores. Si no necesitan jugarse más rondas, el procedimiento puede moverse al paso 815 y terminar el torneo, como se describió anteriormente con respecto a la Figura 6.

La Figura 8c ilustra una progresión ilustrativa de clasificaciones de jugador, agrupaciones y reclasificación que pueden ocurrir en el procedimiento de torneo de las Figuras 8a y 8b. Los jugadores pueden clasificarse para la ronda 1 como se muestra a la izquierda, y agruparse en tres grupos (cuatro jugadores por grupo), y entonces reclasif icarse como se muestra a la derecha basándose en su desempeño en la ronda 1. Al agrupar jugadores para la segunda ronda, los cuatro jugadores reclasificados superiores son Jugadores A, E I y B, pero ya que B sólo jugó con el Jugador A en la ronda previa, el procedimiento puede saltar el Jugador B y agregar el siguiente jugador superior, Jugador F, a Grupo 1. El jugador B entonces se coloca en el Grupo 2 para la segunda ronda. El ejemplo ilustrado en la Figura 8c muestra el jugador final, Jugador L, que se relegó a un nuevo grupo debido a que el jugador jugó demasiado recientemente con el Jugador K del Grupo 3 de la segunda ronda. Si se desea, el procedimiento puede permitir que uno o más grupos al fondo de la lista jueguen uno con otro sin importar las restricciones de Factor de Ventana. Por ejemplo, el Jugador L simplemente puede coincidir en el Grupo 3, a pesar de que jugó recientemente con el Jugador K. Alternativamente, los jugadores al fondo que no pueden coincidir pueden caer del torneo. Como una alternativa, uno o más grupos que aparecen al fondo de las clasificaciones simplemente pueden caer del torneo, con lo cual hacen más estrecho el campo con rondas de paso. La caída puede ser después del paso de un número predeterminado de rondas (por ejemplo, dos rondas), para permitir al menos alguna clasificación preliminar para que los grupos caídos sean más probables a contener los jugadores más débiles de cualquier forma. El método de la Figura 8 solo es un ejemplo, y pueden hacerse modificaciones a este tipo de torneo. Por ejemplo, el parámetro de Espacio de Clasificación puede utilizarse como una segunda revisión en los pasos 807 y 808 para agregar un jugador a un grupo solamente si el nuevo jugador está lo suficientemente cerca en la clasificación a los otros jugadores en el grupo. El servidor de torneo también puede colocar diferentes prioridades en que tan estrictamente se van a utilizar los parámetros de Espacio de clasificación y Factor de ventana, al requerir el abandono de uno o ambos requerimientos y el número resultante de grupos requeridos excedió un umbral predeterminado, o si no existen suficientes jugadores para llenar grupos que satisfacen los requerimientos de parámetro. Las prioridades de servidor pueden abandonar una prioridad antes de abandonar otra. Como otra opción, el procedimiento puede permitir el registro adicional de nuevos jugadores después que inicia el torneo, y la caída (por ejemplo, renuncia) de jugadores que se registraron originalmente. Un jugador recientemente registrado simplemente puede agregarse al grupo de jugadores disponibles para la siguiente ronda, tal como antes del paso 803. Alternativamente, pueden existir limitaciones sobre cuando se permite que se unan nuevos jugadores (por ejemplo, solo después del primer número predeterminado de rondas, o prohibidos en el número predeterminado final de rondas, etc.). Cuando se agrega el nuevo jugador, el nuevo jugador puede tener una clasificación aleatoria del inicio (como con una colocación inicial en el paso 802), o alternativamente el jugador puede clasificarse automáticamente a la mitad, o al fondo, de la lista. El parámetro de Factor de Nuevo jugador puede ajustarse para ajustar una marcación de un nuevo jugador para asegurar que el nuevo jugador no supera rápidamente su cabeza en las clasificaciones después de jugar algunas rondas. Por ejemplo, si los porcentajes de marcación se utilizan y un nuevo jugador gana su primera ronda, el Factor de nuevo jugador puede multiplicar el porcentaje de marcación de jugador por 0.25 cuando el jugador solo jugó una ronda, para que un nuevo jugador no ascienda demasiado rápidamente después de ganar una ronda. Similarmente, el Factor de nuevo jugador puede variar dependiendo en cuantas rondas jugó el jugador (por ejemplo, al utilizar 0.5 después de dos rondas, y 0.75 después de tres, y 1.0 después de cuatro rondas), para que la marcación completa de jugador se acredite después de un número de rondas predeterminado. El procedimiento de torneo de la Figura 8 puede utilizarse para acomodar grandes números de jugadores, y puede utilizarse para correr un torneo continuo (por ejemplo, uno en el cual no hay un número de rondas definido). La Figura 9 ilustra otro procedimiento de torneo que puede utilizarse además de la Figura 8. El procedimiento de la Figura 9, un periodo de calificación de puntuación puede utilizarse para calificar y sembrar inicialmente los entrantes de torneo. El procedimiento comienza en el paso 901, en donde un creador de torneo o administrador (que puede ser un desarroMador de juego, jugador, etc., como se discutió anteriormente) define inicialmente los parámetros del torneo. Los parámetros pueden ser similares a aquellos discutidos anteriormente, pero también pueden utilizarse otros parámetros. Por ejemplo, el torneo puede utilizar una estructura de soporte de eliminación en la cual los ganadores avanzan y los perdedores caen, y tales torneos pueden incluir un parámetro separado que identifica el número de participantes para aparecer en la final, campeonato, juego y el número de ganadores para avanzar de juegos de ronda previos. Los parámetros de torneo también pueden identificar el número de niveles de torneo que se utilizará. Por ejemplo, un torneo puede definirse como teniendo tres niveles (por ejemplo, "Oro", "Plata" y "Bronce") para permitir que el superior, segundo superior, y tercero superior de los grupos de clasificación de jugadores compitan uno con otro. Cada uno de estos niveles puede operarse como casos individuales del torneo, que permiten que los jugadores de diferente calibre compitan en sus propios torneos. Pueden iniciarse casos separados, por ejemplo, después que se completa la calificación y los entrantes se dividen en grupos clasificados basándose en su calificación. El torneo también puede incluir información de programación para la ronda(s) de calificación, tal como el tiempo/fecha de apertura y duración. El torneo también puede incluir un parámetro de Definición de reto que menciona el tipo de reto que se utilizará para calificar a los participantes. Una estructura de datos de definición de reto generalmente puede indicar un tipo de logro que un jugador debe realizar con el fin de calificar para el torneo, y puede variar dependiendo del juego. La Definición de reto puede especificar una o más configuraciones de juego para el reto de calificación, tal como una configuración de localización (por ejemplo, pista de carreras para un juego de carreras, un mapa de campo de batalla para un juego de guerra, un nivel de juego o etapa, etc.), configuración de dificultad (por ejemplo, fácil, medio, difícil, etc.), condición de juego (por ejemplo, tipo de automóvil para una carrera, armas disponibles en un mapa, configuración de clima), etc. La Definición de reto no se limita sólo un evento. En lugar de eso, la definición puede especificar un número de eventos de calificación en una lista ordenada, tal como una secuencia de diferentes carreras o etapas, con diferentes condiciones. Para algunos juegos, la Definición de reto puede incluir un archivo de datos que puede descargarse a una consola de juegos 402 para configurar automáticamente un programa de título de juego en la consola para participar en el reto. Por ejemplo, si un parámetro de Definición de reto de juego requiere que se corra una carrera de cuatro vueltas en la pista de carreras de Laguna Seca en un día soleado, utilizar un automóvil de motor de ruedas traseras que no tiene más de 200 caballos de fuerza, y contra cinco oponentes controlados por computadora (Al) en una configuración de dificultad "media" del juego de carreras, el servidor de torneo puede incluir un archivo de descarga de reto de torneo que, cuando se descarga a la consola del jugador, automáticamente configurará el juego que corre en la consola para correr el tipo de carrera especificado en el archivo de descarga. El archivo de descarga también puede utilizarse por el juego, que corre en la consola 402, para restringir la elección del jugador de automóviles a aquellos permitidos por la Definición de reto. Cuando se definen los parámetros de torneo, el servidor de torneo entonces puede comenzar a ejecutar un procedimiento que controlará el torneo. El procedimiento puede distribuir (o de otra forma reservar) almacenamiento para una estructura de datos de puntuación que se utilizará para mantener los resultados de calificación de los jugadores, y la ID de puntuación puede ser uno de los parámetros definidos en el paso 901. La ID de puntuación puede incluir un nombre o control para la estructura de datos, y una localización de dirección de memoria que indica en donde se almacena y como puede recuperarse. Las IDs de puntuación pueden utilizarse para arbitraje de marcación. Cuando los parámetros de torneo se establecieron en el paso 901, un procedimiento de computadora entonces pueda anunciar el torneo a los jugadores en el paso 902. El anuncio puede ocurrir a través de comunicación electrónica, tal como correo electrónico, SMS, etc., y puede incluir enviar mensajes electrónicos a consolas de juego 402. Los anuncios también pueden hacerse al utilizar otras formas de comunicación, tal como anuncio por televisión, radio, teléfono, revistas, etc. El anuncio informa a los jugadores de los parámetros del torneo, el tipo de reto que debe realizarse para calificar para el torneo (por ejemplo, la Definición de reto), y el período de tiempo para el periodo de calificación (por ejemplo, tiempo de inicio y tiempo final). Después del anuncio en el paso 901, y si el tiempo programado se establece en los parámetros de torneo (o inmediatamente, si no se programa el tiempo), el procedimiento abre el periodo de calificación en el paso 903. Durante este periodo, los jugadores pueden descargar un archivo de configuración de Definición de reto, si está disponible, y puede jugar el reto requisito (por ejemplo, correr la carrera especificada). La consola de juego 402 puede registrar un progreso del jugador y logro (por ejemplo, tiempo de carrera), y puede reportar una marcación a través de transmisión segura de regreso al servidor de torneo, tal como Servidor de Torneo 434, para inclusión en la puntuación del torneo. Además de la revisión de transmisión segura discutida anteriormente, esta marcación reportada también puede someterse a un procedimiento de verificación para ayudar además a evitar tener marcaciones fraudulentas colocadas. El procedimiento de verificación puede incluir una comparación de una marcación reportada con un límite de marcación predeterminado o marcación esperada máxima (que puede ser parámetros de torneo adicionales definidos anteriormente), o con resultados reportados por una consola de juego diferente. Después de recibir una marcación del jugador, o en respuesta a una solicitud del jugador, el servidor puede consultar la puntuación para determinar una clasificación de torneo basándose en el resultado del jugador y otras marcaciones de calificación de los jugadores. El servidor puede enviar un mensaje al jugador que informa al jugador que también lo hizo (por ejemplo, "usted registró el 75avo tiempo más rápido para este reto"). El mensaje también puede informar al jugador sobre para lo que está calificado el jugador (por ejemplo, "su marcación califica para el torneo de nivel oro", o "su marcación califica para la décima semilla"). Si el jugador lo desea, el jugador puede intentar el evento de clasificación de nuevo y colocar otra marcación, al esperar mejorar su posición. Para evitar marcaciones de duplicado, el servidor puede obtener una identidad (por ejemplo, identidad de registro) del jugador que coloca una marcación (por ejemplo, transmitida con la marcación), y revisar si el jugador colocó previamente una marcación de calificación. Si el jugador lo hizo, el procedimiento de servidor puede reemplazar automáticamente la marcación previa con una más nueva, o puede hacerlo solo si la marcación más nueva resultará en una clasificación superior a la anterior, o si el usuario solicitó reemplazar una marcación antigua con una más nueva cuando envió la marcación. Alternativamente, los jugadores no necesitan tener oportunidad ilimitada para colocar marcaciones de calificación. Por ejemplo, el torneo puede restringir a cada usuario sólo a una entrada de calificación, o un número predeterminado limitado de entradas de calificación. El jugador puede tener una oportunidad para tener una marcación de sesión de juego ignorada (por ejemplo, que la trata con una ronda de práctica) en lugar de colocarse. Adicionalmente, el sistema puede presentar una opción a los usuarios para comprar intentos de calificación adicionales, y los usuarios pueden tener una cuenta predeterminada (por ejemplo, una cuenta de tarjeta de crédito, o una cuenta de suscripción) con un delito para el costo de tener otro intento al colocar una marcación de calificación superior. Mientras más y más jugadores califican durante el periodo de calificación, muchos jugadores pueden descender en las clasificaciones. El procedimiento de servidor de torneo puede notificar automáticamente a tales jugadores cuando cambia su clasificación, o si la clasificación cambia por una cantidad predeterminada (por ejemplo, un número de lugares, un porcentaje de participantes, etc.), o si su clasificación los saca de la calificación para un caso de torneo particular (por ejemplo, si su calificación previa utilizada para calificar para el torneo "Oro", pero ahora solo califica para el torneo "Plata"). La notificación puede estar en cualquier comunicación, similar al anuncio, y puede ser un mensaje electrónico enviado a la consola del jugador 402. El mensaje puede aparecer como una comunicación de juego en la consola del jugador, presentada al utilizar una interfase de usuario de programa de juego. Otras notificaciones, tal como correo electrónico a una computadora, también pueden utilizarse. El tipo real de notificación, y condiciones en las cuales se envían, puede especificarse como parámetros de torneo adicionales. Cuando se completa la calificación, el servidor de torneo entonces puede consultar la estructura de datos de puntuación en el paso 904, y determina cuantos jugadores realmente calificaron para el torneo al comparar los resultados colocados con los requerimientos para calificación. Los requerimientos para calificación pueden especificarse en, o derivarse de, los parámetros de torneo. Un ejemplo de tal derivación puede utilizar un cálculo basándose en parámetros de torneo ingresados, tal como el número deseado de jugadores por juego (P), el número de jugadores para estar en el juego final (PF), el número de ganadores debe avanzar de cada juego (W) (por ejemplo, 2, 3, 4, etc. jugadores avanzan de cada juego), y el de rondas deseado (R), para calcular el número total de jugadores (PT) que puede participar en un caso de un torneo: Para determinar que jugadores califican, el procedimiento de torneo puede realizar el cálculo anterior, y entonces calcular la puntuación para aceptar el número PT superior de jugadores como calificados para el torneo. Por supuesto, este cálculo pudo haberse realizado previamente, tal como el paso de definición de torneo 901 y/o periodo de calificación 903. Si se soportan múltiples casos de torneo (por ejemplo, como se indicó por los parámetros de torneo), entonces el procedimiento de torneo puede aceptar las siguientes entradas PT en la puntuación que califican para el siguiente torneo, y así sucesivamente hasta que se llena el número total de casos de torneo, o hasta que no hay más entradas no asignadas en la puntuación. De esta forma, el procedimiento de torneo divide los calificadores (o entrantes) en los varios niveles de torneo. El cálculo ilustrativo anterior no se limita a determinar un número total de jugadores por torneo. En lugar de eso, cualquiera de las variables puede calcularse basándose en otras variables proporcionadas. Así, por ejemplo, si un administrador de torneo decide dejar el número de rondas (R) abierto, la ecuación puede reordenarse para calcular el valor basándose en los otros valores (por ejemplo, conducir tantas rondas como toma tener un torneo para todos los jugadores y satisfacer los valores de jugador por juego y ganador por juego especificados). Adicionalmente, una relación de relleno de torneo puede definirse en los parámetros (por ejemplo, 20%) para requerir que cierto número de porcentaje de marcaciones colocadas califiqué para un torneo. Cuando el periodo de calificación termina, el procedimiento de torneo puede consultar la puntuación para determinar el número total de entrada recibidas, el procedimiento puede determinar cuántas (por ejemplo, 20%) entradas estarán en el torneo (por ejemplo, PT=20 si las relación es 20% y 100 entradas recibidas), y entonces puede ajustar los otros valores (por ejemplo, R, P, etc.) para acomodar la relación de relleno. En el paso 905, el procedimiento de torneo entonces puede programar los varios torneo(s) y ronda(s) de torneo, basándose en los valores calculados (y en algunos) y cualquiera de los parámetros de programa establecidos en los parámetros de torneo. El procedimiento también puede realizar siembra en el paso 906 para llenar soportes de torneo en torneos de eliminación. De esta siembra puede hacerse dinámicamente al utilizar el acercamiento de agrupación descrito anteriormente para mantener a los jugadores de habilidad cercana jugando uno contra otro en cada ronda (por ejemplo, los X jugadores superiores juegan en un juego, los siguientes X jugadores juegan en un segundo juego, etc., con la siembra que ocurre después de cada ronda y tan tarde como sea posible), o la siembra puede hacerse para intentar y asegurar que los jugadores sembrados superiores no dan con otros jugadores de semilla alta hasta que son las rondas últimas o finales. Esto puede hacerse generalmente al iniciar con el juego de campeonato, determinando el número de contiendas semifinales necesarias para llenar el encuentro final, y realizar de forma repetitiva el mismo análisis para las contiendas semifinales hasta que se definieron todas la rondas. Cuando las rondas de encuentro se definieron, el procedimiento de siembra entonces puede pasar del encuentro de abertura al encuentro de abertura, que coloca a los jugadores de semilla superior en números suficientes para llenar a los ganadores esperados, y entonces llenar el resto de las contiendas con los jugadores de semilla inferior. Esta clase de siembra puede hacerse estáticamente, en cuyo caso los jugadores llevan su semilla con ellos a través del torneo, y entonces no se vuelven a sembrar entre rondas. Como una alternativa adicional, esta siembra puede conducirse de nuevo después de cada ronda de juego, en donde solo aquellos jugadores que están presentes y listos para jugar (por ejemplo, que revisaron con el control de servidor el caso de torneo). Así, por ejemplo, si un número de jugadores se retira o desciende después de la primera ronda, el torneo puede volverse a sembrar para la segunda ronda para minimizar a los jugadores inactivos (por ejemplo, jugadores cuyos oponentes, de acuerdo con la siembra original, ya no juegan).

La Figura 10a ilustra un ejemplo de un soporte estáticamente sembrado que puede generarse cuando el servidor de torneo sigue el procedimiento mostrado en la Figura 10b. Aunque se muestran varios valores en las rindas intermedias del soporte de la Figura 10a, el resultado final del procedimiento de la Figura 10b es identificar las coincidencias de soporte de ronda de apertura, el número total de rondas, y la disposición de las contiendas (por ejemplo, cuyas contiendas previas suministran una encuentro posterior con sus competidores). Como se muestra en la Figura 10b, el procedimiento comienza en el paso 1001 al considerar la ronda final. El procedimiento puede consultar los parámetros de torneo para determinar cuántos competidores van a estar en la ronda final, y pueden llenar la ronda final. En el paso 1002, la ronda final puede llenarse con las semillas superiores. En el ejemplo de la Figura 10a, la ronda final puede definirse para tener ocho competidores, para que los ocho jugadores de semilla superior se presuma que aparezcan en la ronda final. De nuevo, sólo es una suposición para propósitos de siembra de las rondas de abertura, ya que los jugadores de semilla superior no se requiere que realmente sobrevivan a la ronda final. Entonces, en el paso 1003, el sistema puede revisar para ver cuántos encuentros de alimentador previas se necesitan en la ronda previa (por ejemplo, la ronda de semifinal) para llenar la ronda actual (por ejemplo, la ronda final). Por ejemplo, si la ronda final necesita ocho jugadores, y los parámetros de torneo indican que cuatro jugadores avanzan de cada encuentro, entonces la ronda previa (la ronda de semifinal) necesitará dos encuentros para proporcionar aquellos ocho jugadores. En el paso 1004, los jugadores de la ronda actual se distribuyen a través de las varias contiendas necesarias en la ronda previa. En el paso 1005, el resto de las contiendas en la ronda previa se llena con los siguientes jugadores sembrados disponibles superiores. El paso 1006, puede hacerse una revisión para determinar si todos los entrantes en el torneo se colocaron. Si no es así, entonces otra ronda previa se necesitará en el torneo. El procedimiento, en el paso 1007, entonces puede cambiar el enfoque a la siguiente ronda previa, y regresar al paso 1003 para realizar los mismos aspectos para llenar los encuentros de la ronda previa. Mientras tanto, por ejemplo, el sistema puede establecer la "ronda actual" en el paso 1007 para hacer la ronda de semifinal, y puede regresar al paso 1003 y comenzar a llenar los soportes para la siguiente ronda previa (por ejemplo, la ronda de cuartos de final). El procedimiento puede continuar hasta que se colocaron todos los entrantes, y la última ronda dirigida en el procedimiento proporciona las siembras de ronda de apertura. La Figura 11 ilustra otro ejemplo de un torneo en el cual seis jugadores aparecen en la ronda final, nueve jugadores juegan en los encuentros de rondas previas, y tres jugadores avanzan de cada encuentro previo. Las rondas previas indican el resultado final del procedimiento de siembra.

Los varios casos de torneo entonces pueden iniciarse, y el torneo(s) corre en el paso 907 para determinar sus resultados. El funcionamiento real de los torneos puede ocurrir como se describió anteriormente, con procedimientos de programa de computadora separados en los mismos o diferentes servidores que administran los varios casos de torneo, sesiones de juego que corren en consolas y se reportan al servidor, arbitraje de marcación, etc. La Figura 12 ilustra un mapa de ¡nterfase de usuario ilustrativo que puede utilizarse, por ejemplo, en un juego para acceder a torneos del tipo mostrado en las Figura 8a-8b y 9. El menú principal 1201 de la consola puede ofrecer un número de opciones de torneo, que incluyen una opción de página de torneos. La página de torneos de 1202, presentada en respuesta a seleccionar esa opción, puede incluir un menú de opciones de torneo. Por ejemplo, el menú de torneos 1202 puede presentar una lista de torneos para la cual el jugador ya está registrado, la clasificación de calificación del jugador, el número de entrantes, el estado actual del torneo (por ejemplo, registro, calificación, ronda X, etc.). El menú de torneos 1202 también puede incluir opciones seleccionares para ingresar a uno de los torneos enlistados, encontrar un torneo y para crear un torneo. Al elegir uno de los torneos enlistados, el usuario puede presentarse con una pantalla de estancia de torneo 1203 para el torneo seleccionado. La pantalla de estancia de torneo 1203 puede presentar información adicional para el torneo seleccionado, tal como estado actual, el siguiente oponente del jugador, estado de oponentes, etc. La pantalla de estancia de torneo 1203 puede incluir opciones de menú adicionales para jugar un juego en el torneo, ver un historial de juego para contiendas previas en el torneo, etc. Al seleccionar una opción de menú correspondiente, la consola de juego puede presentar una pantalla de juego 1204 para comenzar a jugar una ronda una encuentro en el torneo, o una pantalla de historial de juego 1205 para presentar información con respecto al desempeño previo del jugador en el torneo. Esta información puede incluir estadísticas para jugadores, oponentes, equipos, etc. La pantalla de historial 1205 también puede presentar desempeño en línea del jugador total a través de múltiples torneos y tipos de juego, tal como al consultar datos de una puntuación en el Servidor de estadística 426. La pantalla de estancia de torneo 1203 también puede incluir una opción de lista entrante, selección de la cual puede presentar una lista entrante 1206. La pantalla de lista entrante 1206 puede presentar identificación e información estadística con respecto a entrantes en el torneo, entrantes que se programan para jugar en la siguiente ronda, entrantes que juegan en la ronda previa, etc. Después de jugar un encuentro o ronda, el sistema puede presentar una pantalla de resultados de reporte 1207 para presentar el resultado del encuentro. Esto puede incluir estadísticas con respecto al desempeño de jugadores en el encuentro que acaba de jugar.

Del menú de torneos 1202, los jugadores también pueden tener la opción de buscar torneos. Al seleccionar esta opción, el jugador puede ver una pantalla de torneos para encontrar, que puede incluir impulsos para que el jugador ingrese, o seleccione, criterios de búsqueda que pueden utilizarse para localizar torneos en el sistema en línea, tal como aquellos que corren en uno o más Servidores de torneo 434, o aquellos que utilizan las puntuaciones. Los criterios pueden incluir título de juego, nombre de torneo, tipo de juego, tipo de torneo, huésped de torneo, o cualquier otro criterio de búsqueda deseado. Al correr la búsqueda, el sistema puede presentar una lista de torneos para este usuario, que indican los detalles de calificación (por ejemplo, si el usuario calificó, marcaciones de calificador entrantes, etc.) y un programa de cuando se establecen para ocurrir los torneos. El menú de torneo 1202 también puede incluir una opción para permitir que los jugadores creen nuevos torneos. Con la selección, el usuario puede mostrar una pantalla de torneo para crear 1209, que puede impulsar al usuario para criterios que definen un nuevo torneo. Los criterios pueden incluir cualquiera de las características descritas anteriormente, tal como parámetros de torneo, título de juego, etc. Una o más pantallas de configuraciones de juego adicionales 1210 también pueden utilizarse para este propósito. El menú de torneo 1202 también puede incluir una opción de torneo calificado de puntuación, y la selección de esta opción puede presentar una pantalla de puntuación 1211. La pantalla de puntuación 1211 puede enlistar torneos de puntuación, y contener datos adicionales con respecto a torneos calificados de puntuación, tal como el nombre, ID, estado actual, reto actual, periodo de reto/calificación, etc. La pantalla de puntuación 1211 puede incluir una opción para presentar explicación adicional y detalle sobre la calificación para un torneo presentado particular. La pantalla de detalles de calificación 1212 puede incluir descripción adicional para explicar cómo puede calificar el jugador (por ejemplo, "Carrera de la pista de carreras de Laguna Seca que utiliza carro cuatro WD con menos de 301 HP, y colocar una de las 150 veces superiores para calificar para el torneo de nivel Oro!"). El usuario puede elegir hacer un intento de calificación, que resulta en la pantalla de juego 1213, y después el intento del usuario puede observar una pantalla de resultados de reporte 1214 que presenta información con respecto al intento de calificación del jugador. La pantalla de resultados 1214 también puede presentar información recuperada de una puntuación que muestra como la marcación resultante del jugador clasifica entre otras, y la información que identifica si el jugador calificó para el torneo. Al seleccionar un torneo enlistado en la pantalla de puntuación 1211, la consola puede presentar una pantalla de detalles de eliminación 1215 para el torneo. La pantalla de detalles de eliminación 1215 puede enlistar el estado de torneo, la colocación/calificación del jugador, y si el jugador aún está en torneo, el siguiente juego programado para el torneo. Cuando el jugador ya va a comenzar la siguiente ronda, el jugador puede seleccionar una opción correspondiente en la pantalla de detalles 1215 e ingresar a la estancia de torneo 1216, en donde el jugador puede esperar la entrada de sus oponentes para la siguiente ronda. De la estancia 1216, el jugador puede elegir ver el soporte 1217 para el torneo, las configuraciones de juego y parámetros 1218, o estadísticas 1219 con respecto al jugador, con sus compañeros, amigos, otros competidores en el torneo, y oponentes que llegan. Cuando se ha registrado el oponente del jugador, y cuando ambos jugadores están listos, el jugador puede ver la pantalla de juego 1220 para jugar el encuentro, y una pantalla de resultados de pos-juego 1221 que muestran los resultados del encuentro (como se describió anteriormente). Las varias características descritas anteriormente son simples implementaciones ilustrativas de varios conceptos, y son posibles modificaciones como se desee. Por ejemplo, las referencias a un jugador anterior pueden referirse a una persona individual, o pueden referirse a un equipo de gente que juegan sus juegos juntos. Algunos torneos pueden soportar equipos, o clanes, al permitir que los varios jugadores participen juntos (por ejemplo, en una carrera individual) como un equipo. Las marcaciones para miembros de equipo pueden agregarse para comparación de clasificación. Otra modificación posible trata con salidas y no muestras para participantes de torneo. Si un jugador ingresa a un torneo al registrarse y/o calificar, pero falla al completar el torneo (por ejemplo, salirse después de iniciar, o nunca mostrarse en el tiempo programado, etc.), ese jugador puede tratarse como si el jugador hubiera acumulado una marcación de 0, o una pérdida. Como otra modificación posible, las varias pantallas mostradas en la Figura 12 y características descritas aquí pueden utilizarse para juego local, no en red también. Por ejemplo, un torneo de jugador múltiple puede alojarse por una consola individual, y las varias características implementarse por la consola. Las características descritas anteriormente preferiblemente se codifican en software de computadora como instrucciones ejecutables que pueden ejecutarse en un dispositivo de cómputo, tal como una computadora personal o consola de video juegos, para resultar en la presentación de pantallas mostradas en las figuras. Las instrucciones ejecutables pueden almacenarse en un medio legible por computadora, tal como uno o más discos de computadora, RAMs, CD-ROMs, DVDs, cartuchos de juego, etc. También, aunque se describen anteriormente varias características, no es necesario practicarlas todas en la misma modalidad. En lugar de eso, pueden implementarse varias combinaciones y sub-combinaciones como se desee, y el verdadero alcance de la presente invención sólo debe limitarse por las reivindicaciones que siguen. Aunque el tema se describió en lenguaje específico a características estructurales y/o actos metodológicos, se debe entender que el tema definido en las reivindicaciones anexas no necesariamente se limita a características o actos específicos descritos anteriormente. Más que eso, las características y actos específicos descritos anteriormente se describen como formas ilustrativas para implementar las reivindicaciones.

Claims (16)

REIVINDICACIONES

1. - Un método de torneo de consola de juego, que comprende los pasos de: recibir un registro en la solicitud 601 de un administrador de torneo; impulsar a dicho administrador de torneo para entrada de uno o más parámetros de torneo 602, dichos parámetros incluyendo criterios de programa para iniciar una pluralidad de casos 604 de dicho torneo, en donde cada caso: a) se comunica con una pluralidad de consolas de juego remotas 412 entrantes de torneo para establecer criterios de sesión de juego para una pluralidad de rondas en dicho torneo; b) recibe resultados de sesión de juego 606 de una pluralidad de consolas de juego que participan en una sesión de juego en línea de jugador múltiple común; y c) determina un ganador de torneo 611 basándose en resultados de una pluralidad de sesiones de juego.

2. - El método de torneo de consola de juego de acuerdo con la reivindicación 1, en donde dicho registro en la solicitud se recibe de una consola de juego 402.

3. - El método de torneo de consola de juego de acuerdo con la reivindicación 1, en donde dicho paso de determinar además comprende un paso 607 de comparar resultados de sesión de juego recibidos de una primera consola que participó en dicha sesión de fuego con resultados recibidos de una segunda consola que participó en dicha sesión de juego.

4. - El método de torneo de consola de juegos de acuerdo con la reivindicación 3, en donde si dicho paso de comparar identifica una inconsistencia entre dichos resultados comparados, dicho método además comprende el paso de conducir arbitraje 608 para resolver la inconsistencia.

5. - El método de torneo de consola de juego de acuerdo con la reivindicación 4, en donde dicho paso de arbitraje incluye consultar una estructura de datos de puntuación 608, dicha estructura de datos de puntuación recibiendo resultados de sesión del juego de dicha pluralidad de consolas de juego a través de transmisión segura.

6. - El método de torneo de consola de juego de acuerdo con la reivindicación 1, en donde dichos criterios de programa resulta en un inicio automático de un segundo caso de dicho torneo con el término de un primer caso de dicho torneo 603.

7. - El método de torneo de consola de juego de acuerdo con la reivindicación 1, en donde dichos parámetros de torneo además incluyen un factor de ventana que identifica un tiempo mínimo que debe transcurrir antes que los entrantes de torneo puedan agruparse para una segunda sesión de juego, después de estar juntos para la sesión de juego en línea de jugador múltiple común.

8. - El método de torneo de consola de juego de acuerdo con la reivindicación 1, en donde dichos parámetros de torneo además incluyen un espacio de clasificación que identifica una proximidad en clasificación entre jugadores para agruparse para una sesión de juego en dicho torneo.

9. - El método de torneo de consola de juego de acuerdo con la reivindicación 1, que además comprende el paso de aceptar un nuevo registro de jugador para un caso de dicho torneo después de que al menos una ronda de dicho torneo se haya completado, y que incluye dicho nuevo jugador en rondas subsecuentes de dicho torneo.

10. - El método de torneo de consola de juego de acuerdo con la reivindicación 9, en donde dichos parámetros incluyen un nuevo factor de jugador, y dicho método incluye el paso de utilizar dicho nuevo factor de jugador para ajustar una marcación de dicho nuevo jugador en una o más de dichas rondas subsecuentes de dicho torneo. 11.- El método de torneo de consola de juego de acuerdo con la reivindicación 10, en donde dicho nuevo factor de jugador varia mientras el nuevo jugador participa en más rondas de dicho torneo, y en donde dicho nuevo factor de jugador ya no se utiliza para dicho nuevo jugador después de que dicho nuevo jugador participó en un número de rondas más allá de un número especificado en dichos parámetros de torneo. 12.- El método de torneo de consola de juego de acuerdo con la reivindicación 1, que además comprende el paso de descargar datos de configuraciones de torneo a una consola de juego entrante, y configurar automáticamente dicha consola de juego para jugar una sesión de juego de acuerdo con los parámetros de torneo. 13. - El método de torneo de consola de juego de acuerdo con la reivindicación 1, en donde dichos parámetros de torneo definen un periodo de calificación 903 y uno o más criterios de calificación para dicho torneo, y dicho método además comprende el paso del recibir una pluralidad de reportes de marcación para consolas de juego durante dicho periodo de calificación, e identificar qué marcaciones califican para dicho torneo. 14. - El método de torneo de consola del juego de acuerdo con la reivindicación 13, que además comprende el paso de notificar automáticamente entrantes previamente calificados cuando su estado de calificación se altera debido a entrantes subsecuentemente calificados. 15. - El método de torneo de consola de juego de acuerdo con la reivindicación 14, que además comprende el paso de ofrecer dichos entrantes notificados una oportunidad de reintentar un intento de calificación en respuesta a dicho estado alterado. 16. - El método de torneo de consola de juego de acuerdo con la reivindicación 14, que además comprende el paso 904 de asignar una primera pluralidad de marcaciones de calificación a un caso de primer nivel de dicho torneo, y asignar una segunda pluralidad de marcaciones de calificación a un segundo caso de nivel de dicho torneo, dicha primera pluralidad de marcaciones teniendo una clasificación superior que dicha segunda pluralidad de marcaciones. 17.- El método de torneo de consola de juego de acuerdo con la reivindicación 1, que además comprende el paso de marcar dichos parámetros de torneo en un archivo de configuraciones de torneo, dicho archivo incluye diferentes parámetros de sesión de juego para una pluralidad de rondas en dicho torneo. 18.- Un método de torneo, que comprende los pasos de: recibir registros de torneo de una pluralidad de consolas de juego 402 para entrantes de torneo; clasificar 802 dicha pluralidad de entrantes registrados; agrupar secuencialmente un subgrupo de dichos entrantes clasificados para participación en una sesión de juego en una primera ronda de dicho torneo; reclasificar dichos entrantes basándose en desempeño en dicha primera ronda ; y agrupar secuencialmente un subgrupo de dichos entrantes reclasif icados en una sesión de juego en una segunda ronda de dicho torneo, en donde cuando se determina si se agrega un entrante a un grupo, se hace una revisión para determinar si un factor de ventana de tiempo transcurrió desde que el entrante jugó por último en una sesión de juego con cualquier miembro del grupo. 19.- El método de acuerdo con la reivindicación 18, en donde dicho factor de ventana identifica un número de sesiones de juego. 20.- Un método de torneo calificado de puntuación, que comprende los pasos de: colocar una definición de reto 902 para un programa de juego, dicha definición de reto incluye una pluralidad de criterios de sesión del juego para calificar para un torneo; recibir 903 resultados de sesión de juego de una pluralidad de consolas de juegos de jugadores que intentan calificar para dicho torneo; clasificar dichos resultados de sesión de juego recibidos e informar a los jugadores de su clasificación actual; enviar notificaciones en juego a jugadores cuando su marcación de calificación previa se vuelve una marcación de no calificación como un resultado de marcaciones de jugador subsecuentes, y que permiten a dichos jugadores notificados reintentar calificar; y cerrar el periodo de calificación y conducir dicho torneo al utilizar dichos entrantes calificados.