KR20080094031A - 게임 콘솔 토너먼트 방법, 토너먼트 방법, 및 리더보드예선 토너먼트 방법 - Google Patents

Abstract

멀티플레이어 토너먼트가 설정될 수 있고 이어서 유사한 기량의 플레이어들에 대한 훌륭한 대진을 사용자에게 제공하는 데 도움을 주도록 토너먼트 서버 장치에 의해 자동적으로 실행될 수 있다. 토너먼트는 운영자에 의해 정의될 수 있고, 이어서 플레이어들에 의한 요구에 대응하기 위해 여러번 자동적으로 인스턴스화될 수 있다. 어떤 토너먼트는 토너먼트 라운드(tournament round)에서 유사한 등급의 플레이어들을 그룹화할 수 있으며, 또한 플레이어들이 이전 라운드에서 함께 플레이한 후에 얼마 되지도 않아 함께 플레이하는 것을 방지하기 위해 윈도우 인자(window factor)를 이용할 수 있다. 어떤 토너먼트는 잠재적인 참가자가 예선 파라미터(qualification parameter)에 규정된 업적을 달성하는 것에 의해 토너먼트 예선을 통과할 수 있게 해주는 리더보드 예선 프로세스(leaderboard qualification process)를 사용할 수 있다.

게임, 토너먼트, 리더보드, XBOX, 씨드 배정

Description

게임 콘솔 토너먼트 방법, 토너먼트 방법, 및 리더보드 예선 토너먼트 방법{QUICKLY PROVIDING GOOD MATCHUPS}

온라인 컴퓨터 게임은 오늘날의 비디오 게임 시장의 주된 요소로 빠르게 성장하였는데, 그 이유는 현재 다른 사람들과 플레이할 기회가 점점 더 많기 때문이다. 예를 들어, XBOX LIVE™(미국 워싱턴주 레드몬드 소재의 마이크로소프트사) 온라인 서비스를 통해, 비디오 게임 플레이어가 전세계의 다른 플레이어들과 플레이하는 것이 가능하다. 이러한 거대한 잠재적 플레이어들의 풀(pool)에서, 처음으로 하는 또는 가끔씩 하는 플레이어로부터 매일같이 빠져 있는 팬, 심지어 프로 비디오 게임 플레이어의 등급에 이르기까지 대응하는 광범위한 플레이어 자질이 있다.

이러한 광범위한 플레이어 자질은 새로운 문제를 야기하였다. 많은 온라인 게임들은 플레이어들이 게임 목적을 달성하기 위해 또 그의 경쟁자보다 한 수준 우위를 차지하기 위해 서로 경쟁한다는 점에서 경쟁적이다. 이러한 경쟁적인 게임들은 종종 다양한 플레이어들의 기량 및 자질이 서로 비슷할 때에만 재미가 있다. 기량의 수준차가 너무 큰 경우, 기량이 우세한 플레이어는 도전받지 않을 것인 반면, 기량이 떨어지는 플레이어는 항상 져서 좌절감을 느낄 것이다. 그렇지만, 통상적인 온라인 게임은 플레이어의 자질에 상관없이 또는 플레이어들이 기량면에서 서로 얼마나 비슷한지에 상관없이 플레이어들이 게임 세션에 참가할 때 플레이어들을 모집한다.

토너먼트 등의 어떤 조직적인 시합은 결승 라운드(final round)에서 동일한 기량의 플레이어들끼리 대전시키려고 할 수 있다. 예를 들어, NCAA™(National College Athletics Association) 농구 토너먼트는 65개 팀을 참가시키며, (의외의 결과가 없는 것으로 가정할 때) 그의 2번의 준결승 게임이 상위 4개의 팀(즉, 4개의 1번 씨드)을 서로 대항시키도록 팀들에 씨드를 부여한다. 그렇지만, 각각의 1번 씨드가 토너먼트의 이전 라운드들을 지나온 경로는 균형이 맞지 않는 대전 투성이다. 예를 들어, NCAA™ 농구 토너먼트의 제1 라운드는 대진표(bracket)에서의 최상위 씨드(top seed)를 대진표에서의 최하위 씨드(16번째 씨드)와 대전시킨다. 그에 부가하여, NCAA™ 배치는 정해진 제한된 팀들의 진영(씨드 순서로 된 65개 팀)을 필요로 하고, 수천(또는 수백만)의 플레이어들 및 언제든지 탈락(drop out) 또는 진출(come in)할 수 있는 플레이어들을 갖는 비디오 게임 커뮤니티로 용이하게 변환되지 않는다.

이 요약은 이하의 상세한 설명에 더 기술되는 개념들 중 선택된 것을 간단화된 형태로 소개하기 위해 제공된 것이다. 이 요약은 청구된 발명 대상의 주요 특징들 또는 필수적인 특징들을 확인하기 위한 것이 아니며 청구된 발명 대상의 범위를 제한하는 데 사용되기 위한 것도 아니다.

이하에서 더 상세히 기술되는 바와 같이, 본 출원은 커스터마이즈가능한 시합 구조(customizable competition structure)를 포함한다. 토너먼트 파라미터(tournament parameter)가 사전에 정의될 수 있으며, 계속적인 사람의 감독을 필요로 함이 없이, 필요에 따라 토너먼트가 생성되어 무한정 존재할 수 있도록 게임의 통신 네트워크에 의해 자동적으로 인스턴스화될 수 있다. 이 정의는, 예를 들어, 인터넷 페이지 인터페이스를 사용하여, 또는 최종 사용자의 비디오 게임 사용자 인터페이스에 의해 행해질 수 있다.

토너먼트 운영자는 토너먼트를 정의하기 위해 토너먼트 서버에 로그인하여 토너먼트 파라미터를 입력할 수 있다. 토너먼트는 한번 이상 인스턴스화될 수 있고, 서로 다른 인스턴스가 개별적으로 또한 자동적으로 다양한 참가자들과 통신을 하고 게임-세션 결과를 관리하며 토너먼트 우승자를 결정할 수 있다.

어떤 측면에서, 토너먼트에서 여러가지 게임 콘솔들에 의해 보고된 점수들에서의 변칙들을 해결하기 위해 득점 중재(scoring arbitration)가 사용될 수 있다. 예를 들어, 토너먼트 서버가 그의 수신된 결과를 별개의 리더보드 프로세스에 의해 수신된 결과와 비교할 수 있으며, 여기서 별개의 리더보드 프로세스는 통신을 검증하는 데 도움이 되도록 게임 콘솔과 더 안전한 전송을 사용할 수 있다.

어떤 측면에서, 토너먼트는 스케쥴에 따라 진행될 수 있으며, 차례로(예를 들어, 거의 연속적으로) 진행되도록 구성될 수 있다.

어떤 측면에서, 윈도우 인자(window factor)는, 토너먼트 전체에 걸쳐 동일 플레이어들이 서로 플레이하게 만드는 효과를 최소화하기 위해, 플레이어들이 게임 세션에서 재회할 수 있기 전에 경과되어야만 하는 시간의 양을 식별해줄 수 있다. 또한, 새로 들어온 참가자의 점수를 조정하기 위해 새로운 플레이어 인자가 사용될 수 있다.

어떤 측면에서, 토너먼트의 그 다음 라운드를 위해 플레이어의 기계를 자동적으로 구성하기 위해 토너먼트 파라미터 및 게임 설정이 게임 콘솔로 다운로드될 수 있다.

어떤 측면에서, 예선 기간(qualification period)이 토너먼트에 선행할 수 있으며, 그 기간 동안 플레이어들은 그들의 해당 점수를 게시함으로써 예선을 통과하고자 시도할 수 있다. 플레이어들은 그들의 예선 통과 상태를 통지받을 수 있으며, 후속 플레이어들의 예선 통과 시도(qualification attempt)로 인해 그 상태가 변하는 경우 또다시 통지받을 수 있고 또한 다른 예선 통과 시도를 할 옵션을 제공받을 수 있다. 토너먼트는 여러 레벨의 예선 통과자(qualifier)에 대응하기 위해 여러번 인스턴스화될 수 있다.

어떤 측면에서, 토너먼트는 가변적인 예선 토너먼트 엔트리 수에 대응하기 위해 동적으로 조정될 수 있다. 원하는 수의 예선 통과자가 토너먼트에 참가할 수 있도록 시합별 우승자의 수, 시합별 플레이어의 수, 라운드 수, 토너먼트의 결승 라운드에서의 플레이어의 수, 기타 등등의 토너먼트 파라미터가 변경될 수 있다. 참가자들은 그들이 플레이한 라운드에 대한 총 가능 점수 대 그들의 총 점수의 비를 사용하여 순위가 매겨질 수 있으며, 그 순위는 나중에 플레이어들을 그룹화하는 데 사용될 수 있다.

사용자가 토너먼트 프로세스를 순회할 수 있도록 토너먼트 사용자 인터페이스가 디스플레이될 수 있다. 사용자는 대화식의 온라인 멀티플레이어(multiplayer) 및 멀티-라운드(multi-round) 비디오 게임을 플레이할 수 있고 플레이어가 예선을 통과한 토너먼트들의 리스트를 볼 수 있다. 사용자가 원하는 기준을 만족시키는 토너먼트를 검색하는 것 또는 토너먼트 및/또는 시합 상대에 대한 상세를 디스플레이하는 것 등의 다른 옵션들도 제공될 수 있다.

이들 및 기타 측면들에 대해 이하에서 더 상세히 기술한다.

도 1은 본 명세서에 기술된 다양한 특징들을 구현하는 데 사용될 수 있는 게임 콘솔을 나타낸 도면.

도 2는 도 1에 도시된 콘솔에서 사용될 수 있는 컴포넌트들을 나타낸 도면.

도 3은 본 명세서에 기술된 특징들을 구현하기 위해 다양한 콘솔 및 기타 구성요소들이 어떻게 상호 연결될 수 있는지를 나타낸 도면.

도 4는 게임 콘솔을 사용한 예시적인 네트워크 구성을 나타낸 도면.

도 5a는 본 명세서에 기술된 특징들을 구현하는 데 사용될 수 있는 예시적인 컴퓨팅 장치를 나타낸 도면.

도 5b 내지 도 5m은 본 명세서에 기술된 특징들을 구현하는 예시적인 소프트웨어 요소 및 개념들을 나타낸 도면.

도 6은 토너먼트를 수행하는 예시적인 프로세스를 나타낸 도면.

도 7은 토너먼트 데이터 구조의 일례를 나타낸 도면.

도 8a 및 도 8b는 한 유형의 토너먼트의 예시적인 프로세스를 나타낸 도면.

도 8c는 예시적인 순위 지정(ranking) 및 순위 재지정(reranking) 배열을 나타낸 도면.

도 9는 대안의 유형의 토너먼트에 대한 다른 예시적인 프로세스를 나타낸 도면.

도 10a 및 도 10b는 예시적인 씨드 부여 대진표(seeding bracket) 및 씨드 부여 프로세스를 나타낸 도면.

도 11은 다른 예시적인 씨드 부여 대진표를 나타낸 도면.

도 12는 플레이어의 콘솔에서 다양한 사용자 인터페이스 화면이 어떻게 사용될 수 있는지를 보여주는 예시적인 관계도.

여러가지 측면들에 대한 이하의 설명에서, 본 명세서에 기술된 여러가지 특징들이 예시로서 도시되어 있는, 본 명세서의 일부를 이루는 첨부 도면이 참조된다. 다른 실시예들이 사용될 수 있으며 구조상 및 기능상의 수정이 행해질 수 있다는 것을 잘 알 것이다.

도 1은 컴퓨터 게임, 비디오 게임 및/또는 기타 전자 게임(통틀어 본 명세서에서 컴퓨터 게임이라고 함)이 플레이될 수 있는 적당한 게임 시스템 환경(100)의 일례를 나타낸 것이다. 이 게임 시스템 환경(100)은 적당한 컴퓨팅 환경의 일례에 불과하며, 본 명세서에 기술된 특징들의 용도 또는 기능의 범위에 관해 어떤 제한을 암시하려는 것이 아니다. 게임 시스템 환경(100)이 예시적인 운영 중인 게임 시스템 환경(100)에 예시된 컴포넌트들 중 임의의 컴포넌트 또는 그 컴포넌트들의 임의의 조합과 관련하여 어떤 의존성 또는 요구조건을 갖는 것으로 해석되어서도 안된다.

본 명세서에 기술된 측면들은 수많은 다른 범용 또는 특수 목적의 컴퓨팅 시스템 환경 또는 구성에서 동작한다. 사용하기에 적합할 수 있는 공지의 컴퓨팅 시스템, 환경, 및/또는 구성의 예로는 퍼스널 컴퓨터, 서버 컴퓨터, PDA(personal digital assistant)·태블릿 PC 또는 랩톱 PC 등의 휴대용 및 핸드헬드 장치, 멀티프로세서 시스템, 마이크로프로세서-기반 시스템, 셋톱 박스, 프로그램가능 가전 제품, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 전자 게임 콘솔, 상기한 시스템들 또는 장치들 중 임의의 것을 포함하는 분산 컴퓨팅 환경, 기타 등등이 있지만, 이에 한정되는 것은 아니다.

본 명세서에서의 측면들은 일반적으로 컴퓨터에 의해 실행 중인, 프로그램 모듈 등의 컴퓨터 실행가능 명령어와 관련하여 기술될 수 있다. 일반적으로, 프로그램 모듈은 특정의 태스크를 수행하거나 특정의 추상 데이터 유형을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조, 기타 등등을 포함한다. 본 명세서에 기술된 특징들은 통신 네트워크를 통해 연결되어 있는 원격 처리 장치들에 의해 태스크가 수행되는 분산 컴퓨팅 환경에서도 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 저장 장치를 비롯한 로컬 및 원격 컴퓨터 저장 매체 둘다에 위치할 수 있다.

도 1은 예시적인 게임 시스템(100)을 나타낸 것이다. 게임 시스템(100)은 게임 콘솔(102) 및 하나 이상의 핸드헬드 컨트롤러[컨트롤러(104(1) 및 104(2))로 나타냄]를 포함할 수 있다. 게임 콘솔(102)은 내장형 또는 외장형 하드 디스크 드라이브 및 광 저장 디스크(108)로 나타내어져 있는 다양한 형태의 휴대용 저장 매체를 지원하는 휴대용 매체 드라이브(106)를 구비하고 있을 수 있다. 적당한 휴대용 저장 매체의 예로는 DVD, CD-ROM, 게임 디스크, 기타 등등이 있다.

게임 콘솔(102)은 최대 4개의 컨트롤러를 지원하기 위해 그의 전면에 다수의 슬롯(110)을 가지고 있을 수 있지만, 슬롯의 수 및 배열이 수정될 수 있다. 전원 버튼(112) 및 꺼내기 버튼(eject button)(114)도 게임 콘솔(102)의 전면에 배치되어 있다. 전원 버튼(112)은 게임 콘솔에의 전원을 스위칭하며, 꺼내기 버튼(114)은 저장 디스크(108)의 삽입 및 배출을 가능하게 해주기 위해 휴대용 매체 드라이브(106)의 트레이(tray)를 교대로 열고 닫는다. 어떤 측면에서, 게임 콘솔(102)은 홈 엔터테인먼트(home entertainment)를 위한 전용의 컴퓨팅 장치일 수 있으며, 인증되고 허가된 애플리케이션만을 실행하는 닫힌 보안 시스템(closed, secure system)일 수 있다. 게임 콘솔(102)은 (예를 들어, 물리 코프로세서, 수학 코프로세서, 그래픽 코프로세서, 고해상도 비디오 출력, 고충실도 오디오 출력(higher fidelity audio output), 기타 등등의 게임 애플리케이션에 대한 향상된 처리 지원을 갖는) 게임 프로그램을 실행하기 위해 최적화될 수 있고, 알파벳 키보드, 내장 하드웨어 확장 슬롯, 프린터 통신 포트, 기타 등등의 퍼스널 컴퓨팅 장치에 통상적으로 있는 어떤 특징들을 생략할 수 있다.

게임 콘솔(102)은 A/V 인터페이싱 케이블(120)을 통해 텔레비전 또는 기타 디스플레이(도시 생략)에 연결될 수 있다. 전원 케이블(122)은 게임 콘솔에 전원 을 제공한다. 게임 콘솔(102)은 또한 인터넷 등의 네트워크에의 액세스를 용이하게 해주기 위해, 케이블 또는 모뎀 커넥터(124)로 나타내어져 있는 바와 같이, 광대역 네트워크 기능을 갖도록 구성될 수 있다. 커넥터(124)는 또한 하나 이상의 무선 네트워크에 접속하기 위해 무선 어댑터를 구비할 수 있다.

각각의 컨트롤러(104)는 유선 또는 무선 인터페이스를 통해 게임 콘솔(102)에 연결될 수 있다. 예시된 구현에서, 컨트롤러는 USB(Universal Serial Bus) 호환이며 USB 케이블(130)을 통해 콘솔(102)에 연결된다. 컨트롤러(104)는 광범위한 사용자 상호작용 메카니즘 중 임의의 것을 구비할 수 있다. 도 1에 예시된 바와 같이, 각각의 컨트롤러(104)는 2개의 썸스틱(thumbstick)(132(1), 132(2)), D-패드(D-pad)(134), 버튼(136)(예를 들어, 'A', 'B', 'X', 'Y') 및 2개의 트리거(trigger)(138)를 구비할 수 있다. 썸스틱(132)은 아날로그 방향 제어 유닛일 수 있으며, X-좌표 및 Y-좌표로 된 위치의 정도(degree of position)를 검출하는 아날로그 전위차계를 포함할 수 있다. D-패드(134)는 상, 하, 좌 및 우, 또는 이들 방향의 조합(예를 들어, 좌상) 등의 방향 명령을 입력하기 위한 입력을 갖는 방향 패드일 수 있다. D-패드(134)는 아날로그일 수도 있으며, 특정의 방향으로 누르는 데 사용되는 압력의 정도(degree of pressure)에 관한 입력을 제공할 수 있다. 이들 메카니즘은 단지 대표적인 것에 불과하며, 다른 공지의 게임 메카니즘이 도 1에 도시된 것에 대용될 수 있거나 그에 추가될 수 있다.

부가적인 휴대용 저장 장치를 제공하기 위해 메모리 장치(memory unit, MU)(140)가 컨트롤러(104)에 삽입될 수 있다. 휴대용 메모리 장치에 의해 사용자 는 게임 파라미터 및 사용자 계정을 저장할 수 있고, 다른 콘솔에서 플레이하기 위해 이들을 포팅할 수 있다. 기술된 구현에서, 각각의 컨트롤러는 2개의 메모리 장치(140)를 수용하도록 구성되어 있지만, 다른 구현에서는 2개보다 많은 또는 그보다 적은 장치가 이용될 수 있다. 오디오 통신 기능을 제공하기 위해 헤드셋(142)이 컨트롤러(104) 또는 게임 콘솔(102)에 연결될 수 있다. 헤드셋(142)은 오디오 입력을 위한 마이크 및 오디오 출력을 위한 하나 이상의 스피커를 포함할 수 있다.

게임 시스템(100)은, 예를 들어, 게임, 음악, 및 비디오를 플레이할 수 있다. 여러 저장 형태 제품이 있는 경우, 타이틀(title)이 하드 디스크 드라이브 또는 드라이브(106) 내의 휴대용 매체(108)로부터, 온라인 소스로부터, 또는 메모리 장치(140)로부터 플레이될 수 있다. 보안을 위해, 어떤 실시예에서는, 실행가능 코드(executable code)가 휴대용 매체(108)로부터만 실행될 수 있다. 게임 시스템(100)이 무엇을 플레이할 수 있는지의 일례로는 CD 및 DVD 디스크로부터, 하드 디스크 드라이브로부터, 또는 온라인 소스로부터 플레이되는 게임 타이틀, 휴대용 매체 드라이브(106) 내의 CD로부터, 하드 디스크 드라이브 상의 파일[예를 들어, WMA(WINDOWS™ Media Audio) 형식]로부터, 또는 온라인 스트리밍 소스로부터 플레이되는 디지털 음악, 및 휴대용 매체 드라이브(106) 내의 DVD 디스크로부터, 하드 디스크 드라이브 상의 파일[예를 들어, ASF(Active Streaming Format)]로부터, 또는 온라인 스트리밍 소스로부터 플레이되는 디지털 오디오/비디오가 있다.

도 2는 게임 시스템(100)의 기능 컴포넌트들을 더 상세히 나타낸 것이다. 게임 콘솔(102)은 중앙 처리 장치(CPU)(200)와, 플래쉬 ROM(Read Only Memory)(204), RAM(Random Access Memory)(206), 하드 디스크 드라이브(208), 및 휴대용 매체 드라이브(106)를 비롯한 다양한 유형의 메모리에의 프로세서 액세스를 용이하게 해주는 메모리 컨트롤러(202)를 갖는다. CPU(200)는 데이터를 일시적으로 저장하고 따라서 메모리 액세스 사이클의 수를 감소시킴으로써 처리 속도 및 처리량(throughput)을 향상시키기 위해 1차 캐쉬(level 1 cache)(210) 및 2차 캐쉬(level 2 cache)(212)를 구비하고 있다.

CPU(200), 메모리 컨트롤러(202) 및 다양한 메모리 장치는, 직렬 및 병렬 버스, 메모리 버스, 주변 장치 버스, 및 다양한 버스 아키텍처 중 임의의 것을 사용하는 프로세서 또는 로컬 버스를 비롯한, 하나 이상의 버스를 통해 상호 접속된다. 예로서, 이러한 아키텍처로는 ISA(Industry Standard Architecture) 버스, MCA(Micro Channel Architecture) 버스, EISA(Enhanced ISA) 버스, VESA(Video Electronics Standards Association) 로컬 버스, 및 메자닌(Mezzanine) 버스라고도 하는 PCI(Peripheral Component Interconnects) 버스가 있을 수 있다.

한 적당한 구현으로서, CPU(200), 메모리 컨트롤러(202), ROM(204), 및 RAM(206)은 공통 모듈(214) 상에 통합되어 있다. 이 구현에서, ROM(204)은 메모리 컨트롤러(202) 및 ROM 버스(도시 생략)에 연결된 플래쉬 ROM으로서 구성되어 있다. RAM(206)은 개별적인 버스(도시 생략)를 통해 메모리 컨트롤러(202)에 의해 독립적으로 제어되는 다수의 DDR SDRAM(Double Data Rate Synchronous Dynamic RAM)으로서 구성되어 있다. 하드 디스크 드라이브(208) 및 휴대용 매체 드라이브(106)는 PCI 버스 및 ATA(AT Attachment) 버스(216)를 통해 메모리 컨트롤러에 연결되어 있 다.

3D 그래픽 처리 장치(220) 및 비디오 인코더(202)는 고속 및 고해상도 그래픽 처리를 위한 비디오 처리 파이프라인을 형성한다. 데이터가 디지털 비디오 버스(도시 생략)를 통해 그래픽 처리 장치(220)로부터 비디오 인코더(222)로 전달된다. 오디오 처리 장치(224) 및 오디오 코덱(코더/디코더)(226)은 고충실도(high fidelity) 및 스테레오 처리를 갖는 대응하는 오디오 처리 파이프라인을 형성한다. 오디오 데이터는 통신 링크(도시 생략)를 통해 오디오 처리 장치(224)와 오디오 코덱(226) 사이에서 전달된다. 비디오 및 오디오 처리 파이프라인은 텔레비전 또는 기타 디스플레이로 전송하기 위해 A/V(오디오/비디오) 포트(228)로 데이터를 출력한다. 예시된 구현에서, 비디오 및 오디오 처리 컴포넌트(220-228)는 모듈(214) 상에 탑재되어 있다.

또한, 모듈(214) 상에는 USB 호스트 컨트롤러(230) 및 네트워크 인터페이스(232)가 구현되어 있다. USB 호스트 컨트롤러(230)는 버스(예를 들어, PCI 버스)를 통해 CPU(200) 및 메모리 컨트롤러(202)에 연결되어 있으며, 주변 장치 컨트롤러(104(1)-104(4))에 대한 호스트로서 역할한다. 네트워크 인터페이스(232)는 네트워크(예를 들어, 인터넷, 홈 네트워크, 기타)에의 액세스를 제공하며, 이더넷 카드, 모뎀, 블루투스 모듈, 케이블 모뎀, 기타 등등을 비롯한 광범위한 다양한 유선 또는 무선 인터페이스 컴포넌트 중 어느 것이라도 될 수 있다.

게임 콘솔(102)은 2개의 듀얼 프로세서 지원 서브어셈블리(240(1), 240(2))를 가지며, 각각의 서브어셈블리는 2개의 게임 컨트롤러(104(1)-104(4))를 지원한 다. 전면 패널 I/O 서브어셈블리(242)는 전원 버튼(112) 및 꺼내기 버튼(114)은 물론 게임 콘솔의 외부 표면 상에 노출되어 있는 임의의 LED(발광 다이오드) 또는 기타 표시기의 기능을 지원한다. 이 서브어셈블리(240(1), 240(2), 242)는 하나 이상의 케이블 어셈블리(244)를 통해 모듈(214)에 연결되어 있다. 어떤 실시예에서, 게임 콘솔(102)은 또한 키보드(254)가 연결되어 있는 키보드 입력 서브어셈블리(240(3))를 포함할 수 있다. 키보드(254) 및 그의 서브어셈블리는, 테스트를 위해 텍스트 명령 및 데이터를 입력하는 데 키보드를 사용할 수 있게 해주기 위해, 콘솔(102)의 개발자 키트 버전의 일부로서 제공될 수 있다. 어떤 실시예에서, 키보드(254)는 컨트롤러 포트(controller port)(예를 들어, 서브어셈블리(240)에 있음)와 직접 통신을 할 수 있으며, 별도의 키보드 입력 서브어셈블리의 사용이 필요하지 않다. 게다가, 추가의 게임 콘솔 자원을 절감하기 위해, 키보드 드라이버 및 서브어셈블리가 콘솔로부터 생략될 수 있으며, 그 대신에 콘솔이 USB 케이블을 통해 제2 컴퓨팅 장치(예를 들어, 다른 PC, 또는 디버깅 워크스테이션)에 연결될 수 있으며, 그에 의해 제2 컴퓨팅 장치가 명령 시퀀스를 게임 콘솔로 전송할 수 있어, 게임 콘솔에서 키보드를 통해 입력된 텍스트 명령 시퀀스를 해석하기 위한 별도의 소프트웨어 및/또는 하드웨어의 필요성을 줄여준다.

8개의 메모리 장치(140(1)-140(8))가 4개의 컨트롤러(104(1)-104(4))에 연결가능한 것으로, 즉 각각의 컨트롤러마다 2개의 메모리 장치가 연결가능한 것으로 도시되어 있다. 각각의 메모리 장치(140)는 게임, 게임 파라미터, 및 기타 데이터가 저장될 수 있는 부가의 저장 장치를 제공한다. 컨트롤러에 삽입될 때, 메모리 장치(140)는 메모리 컨트롤러(202)에 의해 액세스될 수 있다.

시스템 전원 공급 장치 모듈(250)은 게임 시스템(100)의 컴포넌트들에 전력을 제공한다. 팬(252)은 게임 콘솔(102) 내의 회로를 냉각시킨다.

게임 콘솔(102)은 다양한 엔터테인먼트 영역을 통해 사용자를 이동시키기 위해 일관된 사용자 인터페이스 및 내비게이션 계층(navigation hierarchy)을 제공하는 균일 매체 포털 모델(uniform media portal model)을 구현한다. 포털 모델은, 휴대용 매체 드라이브(106)에 삽입된 매체 유형에 상관없이, 게임 데이터, 오디오 데이터, 및 비디오 데이터 등의 복수의 서로 다른 매체 유형으로부터 컨텐츠에 액세스하는 편리한 방법을 제공한다.

균일 매체 포털 모델을 구현하기 위해, 콘솔 사용자 인터페이스(UI) 애플리케이션(260)이 하드 디스크 드라이브(208) 상에 저장되어 있다. 게임 콘솔의 전원을 켜면, 콘솔 애플리케이션(260)의 다양한 부분들이 RAM(206) 및/또는 캐쉬(210, 212)에 로드되고 CPU(200) 상에서 실행된다. 콘솔 애플리케이션(260)은 게임 콘솔 상에서 이용가능한 서로 다른 매체 유형을 내비게이션할 때 일관된 사용자 경험을 제공하는 그래픽 사용자 인터페이스를 제공한다.

게임 시스템(100)은 단순히 이 시스템을 텔레비전 또는 기타 디스플레이에 연결함으로써 독립형 시스템으로서 동작될 수 있다. 이 독립형 모드에서, 게임 시스템(100)은 하나 이상의 플레이어가 게임을 플레이하거나, 영화를 보거나, 또는 음악을 들을 수 있게 해준다. 그렇지만, 네트워크 인터페이스(232)를 통해 광대역 접속의 통합이 가능하게 되는 경우, 게임 시스템(100)은 또한 대규모 네트워크 게 임 커뮤니티의 참여자로서 동작할 수 있다. 이어서, 이 네트워크 게임 환경에 대해서 기술한다.

도 3은 네트워크(302)를 통해 복수의 게임 시스템(100(1),..., 100(g))을 상호 연결시키는 예시적인 네트워크 게임 환경(300)을 나타낸 것이다. 네트워크(302)는 아주 다양한 데이터 통신 네트워크 중 임의의 것을 나타낸다. 이는 공적 부분(예를 들어, 인터넷), 사적 부분[예를 들어, 가정용 LAN(Local Area Network)]은 물론 공적 부분과 사적 부분의 조합도 포함할 수 있다. 네트워크(302)는 유선 및 무선 매체 둘다를 비롯한 아주 다양한 종래의 통신 매체 중 임의의 하나 이상을 사용하여 구현될 수 있다. 공개 및 독점 프로토콜 둘다를 비롯한 아주 다양한 통신 프로토콜 중 임의의 것이 네트워크(302)를 통해 데이터를 통신하는 데 사용될 수 있다. 이러한 프로토콜의 예로는 TCP/IP, IPX/SPX, NetBEUI, 기타 등등이 있다.

게임 시스템(100)에 부가하여, 온라인 게임을 호스팅하는 것, 다운로드가능한 음악 또는 비디오 파일을 서비스하는 것, 게임 시합을 호스팅하는 것, 스트리밍 오디오/비디오 파일을 서비스하는 것, 기타 등등의 다양한 서비스를 참가자에게 제공하기 위해 네트워크(302)를 통해 하나 이상의 온라인 서비스(304(1),..., 304(s))에 액세스할 수 있다. 네트워크 게임 환경(300)은 또한 개개의 플레이어들 및/또는 게임 시스템(100)을 서로에게 인증하는 역할을 하는 키 배포 센터(key distribution center)(306)는 물론 온라인 서비스(304)를 포함할 수 있다. 배포 센터(306)는 다수의 플레이어들 간의 게임을 형성하기 위해 또는 온라인 서비 스(304)로부터 서비스를 구입하기 위해 나중에 사용될 수 있는 키 및 서비스 티켓을 유효한 참가자에게 배포한다.

네트워크 게임 환경(300)은 개개의 게임 시스템(100)이 이용할 수 있는 다른 메모리 소스, 즉 온라인 저장 장치를 도입한다. 휴대용 저장 매체(108), 하드 디스크 드라이브(208) 및 메모리 장치(들)(140)에 부가하여, 게임 시스템(100(1))은 또한 네트워크(302)를 통해 원격 저장 장소[온라인 서비스(304(s))에 있는 원격 저장 장치(308)로 예시되어 있음]에 있는 데이터 파일에 액세스할 수 있다.

도 4는 다른 예시적인 온라인 게임 환경(400), 예를 들어, 미국 워싱턴주 레드몬드 소재의 마이크로소프트사의 "XBOX™ LIVE™"의 블록도이다. 다수의 게임 콘솔(402(1), 402(2),..., 402(n))이 네트워크(406)를 통해 보안 게이트웨이(404)에 연결되어 있다. 각각의 게임 콘솔(402)은, 예를 들어, 도 1 또는 도 2의 게임 콘솔(102)일 수 있다. 네트워크(406)는 다양한 종래의 데이터 통신 네트워크 중 임의의 하나 이상을 나타낸다. 네트워크(406)는 통상적으로 패킷 교환 네트워크를 포함하지만, 회선 교환 네트워크도 포함할 수 있다. 네트워크(406)는 유선 및/또는 무선 부분을 포함할 수 있다. 한 예시적인 구현에서, 네트워크(406)는 인터넷을 포함하며, 선택적으로 하나 이상의 근거리 통신망(LAN) 및/또는 원거리 통신망(WAN)을 포함할 수 있다. 네트워크(406)의 적어도 일부는 공개적으로 액세스가능한 네트워크를 말하는 것인 공개 네트워크(public network)이다. 실질적으로 누구라도 공개 네트워크에 액세스할 수 있다.

어떤 상황에서, 네트워크(406)는 게임 콘솔(402)과 보안 게이트웨이(404) 사 이에 위치한 라우팅 장치를 갖는 LAN(예를 들어, 홈 네트워크)을 포함한다. 이 라우팅 장치는 네트워크 주소 변환(network address translation, NAT)을 수행하여, LAN 상의 다수의 장치가 인터넷 상의 동일한 IP 주소를 공유할 수 있게 해주고 또한 인터넷을 통한 악의적인 또는 짖궂은 사용자에 의한 액세스로부터 LAN 상의 장치(들)을 보호하는 방화벽으로서 동작할 수 있다.

보안 게이트웨이(404)는 공개 네트워크(406)와 사설 네트워크(408) 사이의 게이트웨이로서 동작한다. 사설 네트워크(408)는 근거리 통신망 등의 아주 다양한 종래의 네트워크 중 어느 것이라도 될 수 있다. 사설 네트워크(408)는 물론 이하에서 더 상세히 기술되는 기타 장치들은 보안 구역(secure zone)으로서 동작하는 데이터 센터(410) 내에 있다. 데이터 센터(410)는 신뢰 통신(trusted communications)을 통해 통신을 하는 신뢰 장치들(trusted devices)로 이루어져 있다. 따라서, 보안 구역(410) 내에서의 암호화 및 인증이 필요하지 않다. 네트워크(408)의 사적 속성은 네트워크(408)에의 액세스가 제한되어 있음을 말한다, 즉 네트워크(408)에의 액세스가 어떤 개인으로만 제한되어 있다(예를 들어, 데이터 센터(410)의 소유자 또는 운영자에 의해 제한됨).

보안 게이트웨이(404)는 하나 이상의 보안 게이트웨이 컴퓨팅 장치의 클러스터이다. 이들 보안 게이트웨이 컴퓨팅 장치들이 모여서 보안 게이트웨이(404)를 구현한다. 보안 게이트웨이(404)는 선택적으로 보안 게이트웨이 컴퓨팅 장치들에 의해 처리될 요청들을 이들 컴퓨팅 장치들 중 해당 장치들로 보내는 동작을 하는 하나 이상의 종래의 부하 분산 장치들(load balancing devices)을 포함할 수 있다. 이러한 보내는 동작 또는 부하 분산 동작은 다양한 보안 게이트웨이 컴퓨팅 장치들에 대한 부하가 거의 똑같게(또는 다른 대안으로서 어떤 다른 기준에 따라) 균형을 이루도록 수행된다.

또한, 데이터 센터(410) 내에는, 하나 이상의 모니터링 서버(412), 하나 이상의 프레즌스 및 통지 프런트 도어(presence and notification front door)(414)·하나 이상의 프레즌스 서버(416)·하나 이상의 통지 서버(418) 및 프로파일 저장소(428)[이들이 모여서 프레즌스 및 통지 서비스 또는 시스템(430)을 구현함], 하나 이상의 대전 프런트 도어(match front door)(420) 및 하나 이상의 대전 서버(match server)(422)[이들이 모여서 대전 서비스(match service)를 구현함], 및 하나 이상의 통계 프런트 도어(statistics front door)(424) 및 하나 이상의 통계 서버(statistics server)(426)(이들이 모여서 통계 서비스를 구현함)이 있다. 서버(416, 418, 422, 426)는 게임 콘솔(402)에 서비스를 제공하며, 따라서 서비스 장치라고 할 수 있다. 서버(416, 418, 422, 426) 중 하나 이상에 부가하여 및/또는 그 대신에 다른 서비스 장치들도 포함될 수 있다. 그에 부가하여, 도 4에 단지 하나의 데이터 센터가 도시되어 있지만, 다른 대안으로서, 게임 콘솔(402)과 통신을 할 수 있는 다수의 데이터 센터가 존재할 수 있다. 이들 데이터 센터는 독립적으로 동작할 수 있거나, 다른 대안으로서 [예를 들어, 게임 콘솔(102, 402)이 하나의 대규모 데이터 센터를 이용할 수 있도록] 집단으로 동작할 수 있다.

게임 콘솔(402)은 데이터 센터(410)로부터 원격지에 위치하며, 네트워크(406)를 통해 데이터 센터(410)에 액세스한다. 데이터 센터 내의 하나 이상의 장치들과 통신하고자 하는 게임 콘솔(402)은 데이터 센터에 로그인하고 콘솔(402)과 보안 게이트웨이(404) 사이에 보안 통신 채널을 설정한다. 게임 콘솔(402) 및 보안 게이트웨이(404)는 상호간에 전달되는 데이터 패킷을 암호화 및 인증함으로써, 이들 사이에서 데이터 패킷이 안전하게 전송될 수 있으며, 데이터 패킷을 포착 또는 복사할 수 있는 어떤 다른 장치도 암호를 깨지 않고는 이들을 이해하지 못한다. 게임 콘솔(402)로부터 보안 게이트웨이(404)로 또는 보안 게이트웨이(404)로부터 게임 콘솔(402)로 전달되는 각각의 데이터 패킷은 그 안에 데이터가 내장되어 있을 수 있다. 이 내장된 데이터를 패킷의 내용(content) 또는 데이터 내용(data content)라고 한다. 패킷 유형[예를 들어, 하트비트 패킷(heartbeat packet)]에 기초하여 부가의 정보도 역시 본질적으로 패킷에 포함될 수 있다.

콘솔(402)과 보안 게이트웨이(404) 사이의 보안 통신 채널은 보안 티켓(security ticket)에 기초하고 있다. 콘솔(402)은 키 배포 센터(429)에 그 자신 및 콘솔(402)의 현재 사용자(들)를 인증받고, 키 배포 센터(429)로부터 보안 키를 획득한다. 콘솔(402)은 이어서 이 보안 티켓을 사용하여 보안 게이트웨이(404)와 보안 통신 채널을 설정한다. 보안 게이트웨이(404)와 보안 통신 채널을 설정함에 있어서, 게임 콘솔(402) 및 보안 게이트웨이(404)는 서로에 대해 그 자신을 인증받고, 그 특정의 게임 콘솔(402) 및 보안 게이트웨이(404)만이 알고 있는 세션 보안 키(session security key)를 설정한다. 이 세션 보안 키는 게임 콘솔(402)과 보안 게이트웨이 클러스터(404) 사이에서 전송되는 데이터를 암호화하는 데 사용되며, 따라서 다른 어떤 장치[다른 게임 콘솔(402)을 포함함]도 그 데이터를 판독할 수 없다. 세션 보안 키는 또한 데이터 패킷을, 그 데이터 패킷의 주장된 출처인 보안 게이트웨이(404) 또는 게임 콘솔(402)로부터 온 것으로 인증하는 데도 사용된다. 따라서, 이러한 세션 보안 키를 사용하여, 보안 게이트웨이(404)와 다양한 게임 콘솔(402) 사이에 보안 통신 채널이 설정될 수 있다.

게임 콘솔(402)과 보안 게이트웨이(404) 사이에 보안 통신 채널이 설정되면, 암호화된 데이터 패킷이 이들 둘 사이에서 안전하게 전송될 수 있다. 게임 콘솔(402)이 데이터 센터(410) 내의 특정의 서비스 장치로 데이터를 전송하고자 할 때, 게임 콘솔(402)은 그 데이터를 암호화하여 보안 게이트웨이(404)로 전송하여, 데이터 패킷이 목표로 하는 특정의 서비스 장치(들)로 그 데이터를 포워드하도록 요청한다. 보안 게이트웨이(404)는 데이터 패킷을 수신하고, 데이터 패킷을 인증 및 복호화한 후에, 패킷의 데이터 내용을 사설 네트워크(408)를 통해 해당 서비스로 전송될 다른 메시지 내에 캡슐화한다. 보안 게이트웨이(404)는 데이터 패킷이 목표로 하는 요청된 서비스(들)에 기초하여 메시지에 대한 해당 서비스를 결정한다.

이와 유사하게, 데이터 센터(410) 내의 서비스 장치가 게임 콘솔(402)로 데이터를 전달하고자 할 때, 데이터 센터는 사설 네트워크(408)를 통해, 게임 콘솔(402)로 전송될 데이터 내용은 물론 데이터 내용이 전송될 특정의 게임 콘솔(402)의 표시를 포함한 메시지를 보안 게이트웨이(404)로 전송한다. 보안 게이트웨이(404)는 데이터 내용을 데이터 패킷 내에 내장시키고, 이어서 그 데이터 패킷을 암호화하며, 따라서 이는 특정의 게임 콘솔(402)에 의해 복호화될 수 있고 또 한 그 데이터 패킷을 보안 게이트웨이(404)로부터 온 것으로 인증한다.

본 명세서에서 보안 게이트웨이(404)와 게임 콘솔(402) 간에 주로 암호화된 데이터 패킷을 전달하는 것으로 기술되어 있지만, 다른 대안으로서, 어떤 데이터 패킷은 부분적으로 암호화될 수 있다(데이터 패킷의 어떤 부분들은 암호화되는 반면, 다른 부분들은 암호화되지 않는다). 데이터 패킷의 어느 부분들이 암호화되는지와 어느 부분들이 암호화되지 않는지는 데이터 센터(410) 및/또는 게임 콘솔(402)의 설계자가 원하는 바에 기초하여 변할 수 있다. 예를 들어, 설계자는 음성 데이터가 콘솔들(402) 간에 전달될 수 있도록 하려고 할 수 있으며 따라서 콘솔(402)의 사용자는 서로 말을 할 수 있다. 설계자는 또한 그 음성 데이터가 암호화되지 않도록 할 수 있는 반면, 패킷 내의 임의의 다른 데이터는 암호화된다. 그에 부가하여, 다른 대안에서, 어떤 데이터 패킷들은 암호화된 부분이 하나도 없을 수 있다(즉, 전체 데이터 패킷이 암호화되지 않는다). 유의할 점은, 데이터 패킷이 암호화되지 않거나 부분적으로만 암호화되더라도, 데이터 패킷 전부가 여전히 인증될 수 있다는 것이다.

보안 게이트웨이(404) 내의 각각의 보안 게이트웨이 장치는 통상적으로 하나 이상인 게임 콘솔(402)과의 보안 통신 채널을 책임지고 있으며, 따라서 각각의 보안 게이트웨어 장치가 하나 이상의 게임 콘솔을 관리 또는 담당할 책임이 있는 것으로 볼 수 있다. 다양한 보안 게이트웨이 장치들은 서로 통신을 하여 서로에게 메시지를 전달할 수 있다. 예를 들어, 관리할 책임이 없는 게임 콘솔로 데이터 패킷을 전송할 필요가 있는 보안 게이트웨이 장치는 그 게임 콘솔로 전송될 데이터를 갖는 메시지를 나머지 보안 게이트 장치들 전부에게 전송할 수 있다. 이 메시지는 그 게임 콘솔을 관리할 책임이 있고 또 해당 데이터를 그 게임 콘솔로 전송하는 보안 게이트웨이 장치에 의해 수신된다. 다른 대안으로서, 보안 게이트웨이 장치는 어느 보안 게이트웨이 장치가 어느 게임 콘솔을 담당하고 있는지를 알 수 있다. 이것은 각각의 보안 게이트웨이 장치가 나머지 보안 게이트웨이 장치들이 담당하고 있는 게임 콘솔들의 테이블을 유지하는 것과 같이 명시적일 수 있거나, 다른 대안으로서, 게임 콘솔의 식별자에 기초하여 어느 보안 게이트웨이 장치가 특정의 게임 콘솔을 책임지고 있는지를 판정하는 것과 같이 암시적일 수 있다.

모니터링 서버(들)(412)는 이용가능하지 않은 게임 콘솔(402) 또는 보안 게이트웨이(404)의 이용가능하지 않은 보안 게이트웨이 장치를 데이터 센터(410) 내의 장치들에 알려주는 동작을 한다. 게임 콘솔(402)은 하드웨어 또는 소프트웨어 고장, 콘솔이 데이터 센터(410)에서 로그아웃하지 않고 전원이 꺼짐, 콘솔(402)에의 네트워크 접속 케이블이 콘솔(402)로부터 분리됨, 기타 네트워크 문제(예를 들어, 콘솔(402)이 있는 LAN이 오작동함) 등의 다양한 서로 다른 이유로 이용가능하지 않게 될 수 있다. 이와 유사하게, 보안 게이트웨이(404)의 보안 게이트웨이 장치도 하드웨어 또는 소프트웨어 고장, 장치의 전원이 꺼짐, 장치에의 네트워크 접속 케이블이 장치로부터 분리됨, 기타 네트워크 문제 등의 다양한 서로 다른 이유로 이용가능하지 않게 될 수 있다.

보안 게이트웨이(404) 내의 보안 게이트웨이 장치들 각각은, 보안 게이트웨이 장치들 중 하나가 이용가능하지 않게 될 때를 검출하는 하나 이상의 모니터링 서버(412)에 의해 모니터링된다. 보안 게이트웨이 장치가 이용가능하지 않게 되는 경우, 모니터링 서버(412)는 보안 게이트웨이 장치가 더 이상 이용가능하지 않다는 메시지를 데이터 센터(410) 내의 나머지 장치들(서버들, 프런트 도어들, 기타) 각각에 전송한다. 나머지 장치들 각각은, 적절하다고 생각될 때, 이 정보에 기초하여 동작할 수 있다(예를 들어, 각각의 장치는 보안 게이트웨이 장치에 의해 관리되는 특정의 게임 콘솔들이 더 이상 데이터 센터(410)와 통신을 하지 않는 것으로 가정하고 그에 따라 다양한 소거 동작(clean-up operation)을 수행할 수 있다). 다른 대안으로서, 어떤 장치들만(예를 들어, 보안 게이트웨이 장치가 이용가능한지 여부에 관심이 있는 장치들만)이 모니터링 서버(412)로부터 이러한 메시지를 수신할 수 있다.

보안 게이트웨이(404)는 개개의 게임 콘솔(402)을 모니터링하고 게임 콘솔(402) 중 하나가 이용가능하지 않게 될 때를 검출한다. 보안 게이트웨이(404)가 게임 콘솔이 더 이상 이용가능하지 않음을 검출할 때, 보안 게이트웨이(404)는 이용가능하지 않은 게임 콘솔을 식별해주는 메시지를 모니터링 서버(412)로 전송한다. 이에 응답하여, 모니터링 서버(412)는 게임 콘솔이 더 이상 이용가능하지 않다는 메시지를 데이터 센터(410) 내의 나머지 장치들 각각으로(또는 다른 대안으로서 선택된 장치들에만) 전송한다. 나머지 장치들 각각은 이어서, 적절하다고 생각될 때, 이 정보에 기초하여 동작할 수 있다.

프레즌스 서버(들)(416)는 온라인 게임을 위해 데이터 센터(410)에 로그인한 주어진 사용자의 상태 또는 존재에 관한 데이터를 보유 및 처리한다. 통지 서버 (들)(418)는 데이터 센터(410)에 로그인한 플레이어로 보내지는 발신 메시지의 다수의 통지 큐(notification queue)를 유지한다. 프레즌스 및 통지 프런트 도어(414)는 보안 게이트웨이(404)와 서버들(416, 418) 간의 매개물로서 역할하는 하나 이상의 서버 장치이다. 프런트 도어(414)로서 동작하는 다수의 서버 장치들 간에 부하를 분산시키기 위해, 하나 이상의 부하 분산 장치(도시 생략)가 프레즌스 및 통지 프런트 도어(414)에 포함될 수 있다. 보안 게이트웨이(404)는 서버(416, 418)에 대한 메시지를 프런트 도어(414)로 전달하고, 프런트 도어(414)는 그 메시지가 어느 특정 서버(416) 또는 특정 서버(418)로 전달되어야 하는지를 식별한다. 프런트 도어(414)를 사용함으로써, 어느 서버가 어느 사용자에 관한 데이터의 관리를 책임지고 있는지와 같이 서버(416, 418)의 실제 구현은 보안 게이트웨이(404)로부터 추상화된다. 보안 게이트웨이(404)는 프레즌스 및 통지 서비스를 목표로 하는 메시지를 프레즌스 및 통지 프런트 도어(414)로 포워드할 수 있으며 프런트 도어(414)에 의존하여 서버(들)(416) 및 서버(들)(418) 중 해당 서버로 그 메시지를 라우팅한다.

대전 서버(들)(422)는 온라인 플레이어들을 서로 대전시키는 것에 관한 데이터를 보유 및 처리한다. 온라인 사용자는 플레이할 수 있는 게임을 그 게임의 다양한 특성(예를 들어, 축구 게임이 플레이되는 장소, 게임이 주간에 또는 야간에 플레이되는지 여부, 사용자의 기량 수준, 기타)과 함께 광고할 수 있다. 이들 다양한 특성은 이어서 함께 게임을 할 서로 다른 온라인 사용자들을 대전시키기 위한 기초로서 사용될 수 있다. 대전 프런트 도어(420)는 하나 이상의 서버 장치(및 선 택적으로 부하 분산 장치(들))를 포함하며, 프런트 도어(414)가 서버(들)(416) 및 서버(들)(418)를 추상화하는 것과 유사한 방식으로 보안 게이트웨이(404)로부터 대전 서버(들)(422)를 추상화하는 동작을 한다.

통계 서버(들)(426)는 온라인 게임에 대한 다양한 통계에 관한 데이터를 보유 및 처리한다. 사용되는 특정의 통계는 게임 설계자가 원하는 바(예를 들어, 상위 10개 점수 또는 시간, 게임의 모든 온라인 플레이어의 세계 순위, 가장 많은 아이템을 찾았거나 플레이하는 데 가장 많은 시간이 걸린 사용자들의 리스트, 기타)에 기초하여 변할 수 있다. 통계 프런트 도어(426)는 하나 이상의 서버 장치(및 선택적으로 부하 분산 장치(들))를 포함하며, 프런트 도어(414)가 서버(들)(416) 및 서버(들)(418)를 추상화하는 것과 유사한 방식으로 보안 게이트웨이(404)로부터 통계 서버(들)(426)를 추상화하는 동작을 한다.

온라인 서비스에 의해 지원되는 각각의 개별적인 게임 타이틀 또는 프로그램에 대해 타이틀 서버(들)(432)가 제공될 수 있다. 각각의 타이틀 서버(432)는 서버로서 동작할 수 있으며 온라인 게임 세션을 수행하는 프로그램들 및/또는 모듈들을 실행하기 위해 게임 콘솔(402)과 통신을 할 수 있다. 서버(432)는 게임에서의 동작들에 대해 많든 또는 적든 게임 개발자가 원하는 만큼의 제어를 할 수 있다. 예를 들어, 어떤 게임들은, 어느 플레이어 캐릭터가 지도 상의 특정 지점에 제일 먼저 왔는지를 판정하는 것, 또는 다양한 플레이어의 캐릭터가 등장하는 공통의 환경의 모습을 제어하는 것과 같은, 서로 다른 게임 콘솔(402)에 있는 다수의 플레이어들 간의 상호작용과 관련이 있는 계산 및 처리를 수행하기 위해 중앙집중식 타이 틀 서버(centralized title server)(432)에 의존할 수 있으며, 또한 이미지 및 결과의 실제 렌더링 및 사용자 입력의 초기 처리와 같은 더 로컬화된 측면들을 처리하기 위해 개개의 콘솔(402)에 의존할 수 있다.

반면에, 게임은 처리를 위해서는 콘솔(402)에 더 의존할 수 있다. 주어진 게임에 대한 처리 책임이 게임 세션에 연결되어 있는 복수의 콘솔(402) 간에 분산될 수 있다. 또는, 게임이 세션에 연결된 콘솔들(402)의 서브셋을 선택하고, 그 콘솔로 하여금 그 세션에 대한 서버로서 역할하게 할 수 있다. 이러한 상황에서, 타이틀 서버(432)는 단순히 게임 콘솔들(402) 간의 통신을 조정할 수 있거나, 단순히 초기 시작 함수(initial startup function)[예를 들어, 게임 유형, 시작 허가(startup authorization), 기타]를 수행하고 이어서 결과를 기다릴 수 있다.

토너먼트 기능을 관리하기 위해 토너먼트 서버(434)도 존재할 수 있다. 이 기능은 이하에서 더 상세히 기술될 것이며, 일반적으로 온라인 멀티플레이어 토너먼트의 생성, 관리 및/또는 완료에 관한 것일 수 있다. 상기한 다양한 서버는 개별적인 기계에 존재할 필요는 없는데, 그 이유는 이들 중 일부 또는 그 전부가 공통의 프로세스 또는 기계 내에 결합될 수 있기 때문이다.

따라서, 보안 게이트웨이(404)가 데이터 센터(410)의 보안 구역 내의 장치들을 비신뢰 공개 네트워크(untrusted, public network)(406)로부터 보호하는 동작을 한다는 것을 잘 알 것이다. 데이터 센터(410)의 보안 구역 내에서의 통신은 암호화될 필요가 없는데, 그 이유는 데이터 센터(410) 내의 모든 장치들이 신뢰되고 있기 때문이다. 그렇지만, 데이터 센터(410) 내의 장치로부터 게임 콘솔(402)로 전 달되어야 하는 모든 정보는 보안 게이트웨이 클러스터(404)를 통과하며, 여기에서 그 정보는 정보가 목표로 하는 게임 콘솔(402)에 의해서만 복호화될 수 있는 방식으로 암호화된다.

도 4에 나타낸 바와 같이, 타이틀 서버(432) 및 토너먼트 서버(434)는 제2 보안 게이트웨이(405) 배후에 존재할 수 있다. 보안 게이트웨이(405)는 보안 게이트웨이(404)와 동일한 것일 수 있거나 그의 서버 및 장치들이 필요로 하지 않는 특징들을 생략하기 위해 단순화된 것일 수 있다.

본 명세서에 기술된 하나 이상의 특징들은 RAM 메모리(206), 비휘발성 메모리(108, 208, 308) 또는 게임 콘솔(102) 상에 존재하는 임의의 다른 메모리에 저장된 컴퓨터 실행가능 명령어(즉, 소프트웨어)로 구현될 수 있다. 일반적으로, 소프트웨어 모듈은 컴퓨터 또는 기타 장치 내의 프로세서에 의해 실행될 때 특정의 태스크를 수행하거나 특정의 추상 데이터 유형을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조, 기타 등등을 포함한다. 컴퓨터 실행가능 명령어들은 하나 이상의 하드 디스크(208), 이동식 저장 매체(108)(예를 들어, CD-ROM, DVD, 디스크, 기타), 고상 메모리(solid state memory), RAM(206), 기타 등등의 컴퓨터 판독가능 매체 상에 저장될 수 있다. 당업자라면 잘 알 것인 바와 같이, 소프트웨어 모듈의 기능은 여러가지 실시예에서 원하는 바에 따라 결합되거나 분산되어 있을 수 있다. 그에 부가하여, 기능은 전체적으로 또는 부분적으로 ASIC(application specific integrated circuit), FPGA(field programmable gate array), 기타 등등의 펌웨어 또는 하드웨어 등가물로 구현될 수 있다.

본 명세서의 측면들은 콘솔 컴퓨팅 환경으로 제한되지 않는다. 실제로, 이들 측면은 퍼스널 컴퓨터(PC)에서 동작하는 비디오 게임에서도 구현될 수 있다. 도 5a는 본 명세서에 기술된 특징들이 구현될 수 있는 적당한 컴퓨팅 시스템 환경(500)의 일례를 나타낸 것이다. 컴퓨팅 시스템 환경(500)은 적당한 컴퓨팅 환경의 일례에 불과하며, 본 명세서에 기술된 특징들의 용도 또는 기능의 범위에 관한 어떤 제한을 암시하려는 것이 아니다. 컴퓨팅 환경(500)은 예시적인 운영 환경(500)에 예시된 컴포넌트들 중 임의의 하나 또는 그 컴포넌트들의 임의의 조합과 관련하여 어떤 의존성 또는 요구사항을 갖는 것으로 해석되어서도 안된다.

본 명세서에서의 특징들은 수많은 다른 범용 또는 특수 목적의 컴퓨팅 시스템 환경 또는 구성에서 동작한다. 사용하는 데 적합할 수 있는 공지의 컴퓨팅 시스템, 환경 및/또는 구성의 예로는 퍼스널 컴퓨터, 서버 컴퓨터, 핸드-헬드 또는 랩톱 장치, 멀티프로세서 시스템, 마이크로프로세서 기반 시스템, 셋톱 박스, 프로그램가능한 가전제품, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 상기 시스템들이나 장치들 중 임의의 것을 포함하는 분산 컴퓨팅 환경, 기타 등등이 있지만 이에 제한되는 것은 아니다.

본 명세서에서의 특징들은 일반적으로 컴퓨터에 의해 실행되는 프로그램 모듈과 같은 컴퓨터 실행가능 명령어와 관련하여 기술될 수 있다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상 데이터 유형을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등을 포함한다. 이 특징들은 또한 통신 네트워크를 통해 연결되어 있는 원격 처리 장치들에 의해 태스크가 수행되는 분산 컴퓨팅 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 저장 장치를 비롯한 로컬 및 원격 컴퓨터 저장 매체 둘다에 위치할 수 있다.

도 5a를 참조하면, 본 명세서에 기술된 특징들을 구현하는 예시적인 시스템은 컴퓨터(510) 형태의 범용 컴퓨팅 장치를 포함한다. 컴퓨터(510)의 컴포넌트들은 처리 장치(520), 시스템 메모리(530), 및 시스템 메모리를 비롯한 각종 시스템 컴포넌트들을 처리 장치(520)에 연결시키는 시스템 버스(521)를 포함할 수 있지만 이에 제한되는 것은 아니다. 시스템 버스(521)는 메모리 버스 또는 메모리 컨트롤러, 주변 장치 버스 및 각종 버스 아키텍처 중 임의의 것을 이용하는 로컬 버스를 비롯한 몇몇 유형의 버스 구조 중 어느 것이라도 될 수 있다. 예로서, 이러한 아키텍처로는 ISA(industry standard architecture) 버스, MCA(micro channel architecture) 버스, EISA(Enhanced ISA) 버스, VESA(video electronics standard association) 로컬 버스, 그리고 메자닌 버스(mezzanine bus)로도 알려진 PCI(peripheral component interconnect) 버스 등이 있지만 이에 제한되는 것은 아니다.

컴퓨터(510)는 통상적으로 각종 컴퓨터 판독가능 매체를 포함한다. 컴퓨터(510)에 의해 액세스 가능한 매체는 그 어떤 것이든지 컴퓨터 판독가능 매체가 될 수 있고, 이러한 컴퓨터 판독가능 매체는 휘발성 및 비휘발성 매체, 이동식 및 비이동식 매체 둘다를 포함한다. 예로서, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있지만 이에 제한되는 것은 아니다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터와 같 은 정보를 저장하는 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식 및 비이동식 매체 둘다를 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 기타 메모리 기술, CD-ROM, DVD(digital versatile disk) 또는 기타 광 디스크 저장 장치, 자기 카세트, 자기 테이프, 자기 디스크 저장 장치 또는 기타 자기 저장 장치(단수형 또는 복수형), 또는 컴퓨터(510)에 의해 액세스될 수 있고 원하는 정보를 저장하는 데 사용될 수 있는 임의의 기타 매체를 포함하지만 이에 제한되는 것은 아니다. 통신 매체는 통상적으로 반송파(carrier wave) 또는 기타 전송 메커니즘(transport mechanism)과 같은 피변조 데이터 신호(modulated data signal)에 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터를 구현하고 모든 정보 전달 매체를 포함한다. "피변조 데이터 신호"라는 용어가, 신호 내에 정보를 인코딩하도록 그 신호의 특성들 중 하나 이상을 설정 또는 변경시킨 신호를 의미한다. 예로서, 통신 매체는 유선 네트워크 또는 직접 배선 접속(direct-wired connection)과 같은 유선 매체, 그리고 음향, RF, 적외선 및 기타 무선 매체와 같은 무선 매체를 포함하지만, 이에 한정되는 것은 아니다. 상술된 매체들 중 임의의 것의 조합도 컴퓨터 판독가능 매체의 영역 안에 포함되는 것으로 한다.

시스템 메모리(530)는 판독 전용 메모리(ROM)(531) 및 랜덤 액세스 메모리(RAM)(532)와 같은 휘발성 및/또는 비휘발성 메모리 형태의 컴퓨터 저장 매체를 포함한다. 시동 중과 같은 때에, 컴퓨터(510) 내의 구성요소들 사이의 정보 전송을 돕는 기본 루틴을 포함하는 기본 입/출력 시스템(BIOS)(533)은 통상적으로 ROM(531)에 저장되어 있다. RAM(532)은 통상적으로 처리 장치(520)가 즉시 액세스 할 수 있고 및/또는 현재 동작시키고 있는 데이터 및/또는 프로그램 모듈을 포함한다. 예로서, 도 5a는 운영 체제(534), 애플리케이션 프로그램(535), 기타 프로그램 모듈(536) 및 프로그램 데이터(537)를 도시하고 있지만 이에 제한되는 것은 아니다.

컴퓨터(510)는 또한 기타 이동식/비이동식, 휘발성/비휘발성 컴퓨터 저장 매체를 포함할 수 있다. 단지 예로서, 도 5a는 비이동식·비휘발성 자기 매체에 기록을 하거나 그로부터 판독을 하는 하드 디스크 드라이브(541), 이동식·비휘발성 자기 디스크(552)에 기록을 하거나 그로부터 판독을 하는 자기 디스크 드라이브(551), 및 CD-ROM 또는 기타 광 매체 등의 이동식·비휘발성 광 디스크(556)에 기록을 하거나 그로부터 판독을 하는 광 디스크 드라이브(555)를 포함한다. 예시적인 운영 환경에서 사용될 수 있는 기타 이동식/비이동식, 휘발성/비휘발성 컴퓨터 저장 매체로는 자기 테이프 카세트, 플래시 메모리 카드, DVD, 디지털 비디오 테이프, 고상(solid state) RAM, 고상 ROM 등이 있지만 이에 제한되는 것은 아니다. 하드 디스크 드라이브(541)는 통상적으로 인터페이스(540)와 같은 비이동식 메모리 인터페이스를 통해 시스템 버스(521)에 접속되고, 자기 디스크 드라이브(551) 및 광 디스크 드라이브(555)는 통상적으로 인터페이스(550)와 같은 이동식 메모리 인터페이스에 의해 시스템 버스(521)에 접속된다.

위에서 설명되고 도 5a에 도시된 드라이브들 및 이들과 관련된 컴퓨터 저장 매체는, 컴퓨터(510)에 대한 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 및 기타 데이터를 저장한다. 도 5a에서, 예를 들어, 하드 디스크 드라이브(541)는 운영 체제(544), 애플리케이션 프로그램(545), 기타 프로그램 모듈(546), 및 프로그램 데이터(547)를 저장하는 것으로 도시되어 있다. 여기서 주의할 점은 이들 컴포넌트가 운영 체제(534), 애플리케이션 프로그램(535), 기타 프로그램 모듈(536), 및 프로그램 데이터(537)와 동일하거나 그와 다를 수 있다는 것이다. 이에 관해, 운영 체제(544), 애플리케이션 프로그램(545), 기타 프로그램 모듈(546) 및 프로그램 데이터(547)에 다른 번호가 부여되어 있다는 것은 적어도 이들이 다른 사본(copy)이라는 것을 나타내기 위한 것이다. 사용자는 키보드(562) 및 통상 마우스, 트랙볼(trackball) 또는 터치 패드라고 하는 포인팅 장치(561) 등의 입력 장치를 통해 명령 및 정보를 컴퓨터에 입력할 수 있다. 다른 입력 장치(도시 생략)로는 마이크, 조이스틱, 게임 패드, 위성 안테나, 스캐너, 기타 등등을 포함할 수 있다. 이들 및 기타 입력 장치는 종종 시스템 버스에 결합된 사용자 입력 인터페이스(560)를 통해 처리 장치(520)에 접속되지만, 병렬 포트, 게임 포트 또는 USB(universal serial bus) 등의 다른 인터페이스 및 버스 구조에 의해 접속될 수도 있다. 모니터(591) 또는 다른 유형의 디스플레이 장치도 비디오 인터페이스(590) 등의 인터페이스를 통해 시스템 버스(521)에 접속된다. 모니터 외에, 컴퓨터는 스피커(597) 및 프린터(596) 등의 기타 주변 출력 장치를 포함할 수 있고, 이들은 출력 주변장치 인터페이스(595)를 통해 접속될 수 있다.

컴퓨터(510)는 원격 컴퓨터(580)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 사용하여 네트워크화된 환경에서 동작할 수 있다. 원격 컴퓨터(580)는 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치 또는 기타 통상의 네트워크 노드일 수 있고, 통상적으로 컴퓨터(510)와 관련하여 상술된 구성요소들 중 다수 또는 그 전부를 포함하지만, 도 5a에는 메모리 저장 장치(581)만이 도시되어 있다. 도 5a에 도시된 논리적 접속으로는 근거리 통신망(LAN)(571) 및 원거리 통신망(WAN)(573)이 있지만, 기타 네트워크를 포함할 수도 있다. 이러한 네트워킹 환경은 사무실, 전사적 컴퓨터 네트워크(enterprise-wide computer network), 인트라넷, 및 인터넷에서 일반적인 것이다.

LAN 네트워킹 환경에서 사용될 때, 컴퓨터(510)는 네트워크 인터페이스 또는 어댑터(570)를 통해 LAN(571)에 접속된다. WAN 네트워킹 환경에서 사용될 때, 컴퓨터(510)는 통상적으로 인터넷과 같은 WAN(573)을 통해 통신을 설정하기 위한 모뎀(572) 또는 기타 수단을 포함한다. 내장형 또는 외장형일 수 있는 모뎀(572)은 사용자 입력 인터페이스(560) 또는 기타 적절한 메커니즘을 통해 시스템 버스(521)에 접속될 수 있다. 네트워크화된 환경에서, 컴퓨터(510)와 관련하여 기술된 프로그램 모듈 또는 그의 일부가 원격 메모리 저장 장치에 저장될 수 있다. 예로서, 도 5a는 원격 애플리케이션 프로그램(585)이 메모리 장치(581)에 있는 것으로 도시하고 있지만 이에 제한되는 것은 아니다. 도시된 네트워크 접속은 예시적인 것이며 이 컴퓨터들 사이에 통신 링크를 설정하는 기타 수단이 사용될 수 있다는 것을 이해할 것이다.

프로그래밍 인터페이스(또는 보다 간단히 "인터페이스")는 하나 이상의 코드 세그먼트(들)가 하나 이상의 다른 코드 세그먼트(들)와 통신을 하거나 그에 의해 제공되는 기능에 액세스할 수 있게 해주는 임의의 메카니즘, 프로세스, 프로토콜로 볼 수 있다. 다른 대안으로서, 프로그래밍 인터페이스는 다른 컴포넌트(들)의 하나 이상의 메카니즘(들), 메서드(method)(들), 함수 호출(들), 모듈(들), 기타 등등과 통신 연결될 수 있는 시스템의 컴포넌트의 하나 이상의 메카니즘(들), 메서드(들), 함수 호출(들), 모듈(들), 객체(들), 기타 등등으로 볼 수 있다. 이전의 문장에서의 용어 "코드 세그먼트(segment of code)"는 하나 이상의 명령어 또는 코드 라인(line of code)을 포함시키고자 의도된 것이며, 적용되는 전문 용어 또는 코드 세그먼트가 개별적으로 컴파일되는지 여부 또는 코드 세그먼트가 소스 코드(source code), 중간 코드(intermediate code) 또는 오브젝트 코드(object code)로서 제공되는지, 코드 세그먼트가 런타임 시스템 또는 프로세스에서 이용되는지, 또는 이들이 동일한 또는 서로 다른 기계 상에 위치하는지 또는 다수의 기계에 걸쳐 분산되어 있는지, 또는 코드 세그먼트로 표현된 기능이 전적으로 소프트웨어로, 전적으로 하드웨어로, 또는 하드웨어와 소프트웨어의 조합으로 구현되는지에 상관없이, 예를 들어, 코드 모듈, 객체, 서브루틴, 함수, 기타 등등을 포함한다.

개념상, 프로그래밍 인터페이스는 일반적으로 도 5b 또는 도 5c에 도시된 바와 같이 생각될 수 있다. 도 5b에서는 인터페이스(Interface1)를 도관(conduit)으로 나타내고 있는데, 이 도관을 통해 제1 및 제2 코드 세그먼트가 통신을 한다. 도 5c는 인터페이스를 인터페이스 객체(I1, I2)(제1 및 제2 코드 세그먼트의 일부일 수 있거나 그 일부가 아닐 수 있음)를 포함하는 것으로 나타내고 있으며, 이들 인터페이스 객체에 의해 시스템의 제1 및 제2 코드 세그먼트가 매체(M)를 통해 통 신을 할 수 있게 된다. 도 5c를 보면, 인터페이스 객체(I1, I2)를 동일한 시스템의 개별적인 인터페이스로 볼 수 있으며, 또한 객체(I1, I2)와 매체(M)가 인터페이스를 구성하는 것으로도 볼 수 있다. 도 5b 및 도 5c가 양방향 흐름을 나타내고 이 흐름의 양쪽에 인터페이스를 나타내고 있지만, 어떤 구현은 단지 한쪽 방향으로의 정보 흐름만을 가질 수 있거나(또는 이하에 기술되는 바와 같이 정보 흐름이 없거나) 단지 한쪽에만 인터페이스 객체를 가질 수 있다. 제한이 아닌 예로서, 애플리케이션 프로그래밍 인터페이스(API), 진입점(entry point), 메서드, 함수, 서브루틴, 원격 프로시저 호출(remote procedure call), 및 컴포넌트 객체 모델(component object model, COM) 인터페이스 등의 용어는 프로그래밍 인터페이스의 정의 내에 포함된다.

이러한 프로그래밍 인터페이스의 측면들은 제1 코드 세그먼트가 정보를 제2 코드 세그먼트로 전송하는 데 사용되는 메서드(여기서, "정보"는 그의 최광의로 사용되며, 데이터, 명령, 요청, 기타 등등을 포함함), 제2 코드 세그먼트가 그 정보를 수신하는 데 사용되는 메서드, 및 그 정보의 구조, 시퀀스, 구문(syntax), 구성(organization), 스키마(schema), 타이밍(timing) 및 내용(content)을 포함할 수 있다. 이 점에서, 그 정보가 인터페이스에 의해 정의된 방식으로 전송되는 한, 기본적인 전송 매체 자체가 인터페이스의 동작에 중요하지 않을 수 있으며, 그 매체가 유선이나 무선이든 또는 이 둘의 조합이든 상관없다. 어떤 상황에서, 정보가 종래의 의미에서 한쪽 방향 또는 양쪽 방향으로 전달되지 않을 수 있는데, 그 이유는 정보 전송이 또다른 메카니즘을 통하거나(예를 들어, 코드 세그먼트 간의 정보 흐름과 별도로 정보가 버퍼, 파일, 기타 등등에 배치됨), 한 코드 세그먼트가 단지 다른 코드 세그먼트에 의해 수행되는 기능에 액세스하는 때와 같이, 정보 전송이 존재하지 않을 수 있기 때문이다. 이들 측면 중 임의의 것 또는 그 모두가, 예를 들어, 코드 세그먼트가 소결합된 구성(loosely coupled configuration)에서 또는 밀결합된 구성(tightly coupled configuration)에서 시스템의 일부인지에 따라, 주어진 상황에서 중요할 수 있으며, 따라서 이 리스트는 예시적인 것이지 제한하는 것이 아닌 것으로 보아야 한다.

프로그래밍 인터페이스의 이러한 개념은 당업자에게는 잘 알려져 있으며, 본 발명의 이상의 상세한 설명으로부터 분명하다. 그렇지만, 프로그래밍 인터페이스를 구현하는 다른 방식들이 있으며, 명시적으로 배제되지 않는 한, 이들도 역시 본 명세서의 끝부분에 서술되어 있는 청구 범위에 포함되는 것으로 보아야 한다. 이러한 기타 방식들이 도 5b 및 도 5c에 극도로 단순화하여 나타낸 것보다 더 정교하거나 복잡할 수 있지만, 이들은 그럼에도 불구하고 동일한 전체적인 결과를 달성하기 위해 유사한 기능을 수행한다. 이제부터 프로그래밍 인터페이스의 몇몇 예시적인 대안 구현들에 대해 간략하게 기술한다.

A. 인수 분해(factoring)

한 코드 세그먼트로부터 다른 코드 세그먼트로의 통신은 그 통신을 다수의 개별적인 통신으로 분해함으로써 간접적으로 달성될 수 있다. 이것은 도 5d 및 도 도 5e에 개략적으로 도시되어 있다. 도시된 바와 같이, 몇몇 인터페이스는 분할가능한 기능 세트의 관점에서 설명될 수 있다. 따라서, 마치 수학적으로 24 또는 2 x 2 x 3 x 2를 제공할 수 있는 것과 같이, 도 5b 및 도 5c의 인터페이스 기능이 동일한 결과를 달성하도록 인수분해될 수 있다. 따라서, 도 5d에 나타낸 바와 같이, 동일한 결과를 달성하면서 인터페이스의 통신을 다수의 인터페이스(Interface1A, Interface1B, Interface1C, 기타)로 변환하기 위해, 인터페이스(Interface1)에 의해 제공되는 기능이 세분될 수 있다. 도 5e에 나타낸 바와 같이, 인터페이스(I1)에 의해 제공되는 기능은 동일한 결과를 달성하면서 다수의 인터페이스(I1a, I1b, I1c, 기타)로 세분될 수 있다. 이와 유사하게, 제1 코드 세그먼트로부터 정보를 수신하는 제2 코드 세그먼트의 인터페이스(I2)는 다수의 인터페이스(I2a, I2b, I2c, 기타)로 인수분해될 수 있다. 인수분해를 할 때, 제1 코드 세그먼트에 포함된 인터페이스의 수가 제2 코드 세그먼트에 포함된 인터페이스의 수와 일치할 필요는 없다. 도 5d 및 도 5e의 경우 중 어느 하나에서, 인터페이스(Interface1, I1)의 기능상 핵심(functional spirit)은 여전히 각각 도 5b 및 도 5c와 동일하다. 인터페이스의 인수분해는 또한 결합(associative), 교환(commutative) 및 기타 수학적 성질을 따를 수 있으며, 따라서 인수분해를 알아내기가 어려울 수도 있다. 예를 들어, 동작의 순서는 중요하지 않을 수 있으며, 그 결과 인터페이스에 의해 수행되는 기능이 인터페이스에 도달하기 훨씬 이전에 다른 코드 또는 인터페이스에 의해 수행되거나, 시스템의 별도의 컴포넌트에 의해 수행될 수 있다. 게다가, 프로그래밍 분야의 당업자라면 동일한 결과를 달성하는 서로 다른 함수 호출을 행하는 다양한 방식이 있다는 것을 잘 알 수 있다.

B. 재정의

어떤 경우에, 의도한 결과를 여전히 달성하면서 프로그래밍 인터페이스의 어떤 측면들(예를 들어, 매개변수)을 무시, 추가 또는 재정의하는 것이 가능할 수 있다. 이것이 도 5f 및 도 5g에 도시되어 있다. 예를 들어, 도 5b의 인터페이스(Interface1)가 함수 호출 Square(input, precision, output)(이 호출은 3개의 매개변수, input(입력), precision(정도(程度)) 및 output(출력)을 포함하고 제1 코드 세그먼트로부터 제2 코드 세그먼트로 발행됨)을 포함하는 것으로 가정하자. 중간 매개변수 precision이 주어진 시나리오에서 중요하지 않은 경우, 도 5f에 도시된 바와 같이, 이것도 역시 무시되거나 심지어 의미없는(이 상황에서) 매개변수로 대체될 수 있다. 또한, 중요하지 않은 부가의 매개변수를 추가할 수도 있다. 여하튼간에, 제2 코드 세그먼트에 의해 입력이 제곱된 후에 출력이 반환되는 한, 제곱의 기능이 달성될 수 있다. precision(정도)는 확실히 컴퓨터 시스템의 어떤 뒤에 오는 부분 또는 다른 부분에 의미있는 매개변수일 수 있다. 그렇지만, 정도(precision)가 제곱을 계산하는 좁은 목적에 필요하지 않은 것으로 인식되는 경우, 이는 대체되거나 무시될 수 있다. 예를 들어, 유효한 정도(precision) 값을 전달하는 대신에, 결과에 악영향을 주지 않고 생일 등의 의미없는 값이 전달될 수 있다. 이와 유사하게, 도 5g에 도시된 바와 같이, 인터페이스(I1)가 인터페이스(I1')로 대체되고, 매개변수를 무시하거나 인터페이스에 매개변수를 추가하도록 재정의된다. 인터페이스(I2)도 이와 유사하게 인터페이스(I2')로 재정의될 수 있으며, 불필요한 매개변수 또는 다른 곳에서 처리될 수 있는 매개변수를 무시하도록 재정의될 수 있다. 여기서의 요점은 어떤 경우에 프로그래밍 인터페이스가 어떤 목적에 필요하지 않는 매개변수 등의 측면들을 포함할 수 있으며 따라서 이들이 무시 또는 재정의되거나 다른 목적으로 다른 곳에서 처리될 수 있다는 것이다.

C. 인라인 코딩(inline coding)

또한, 2개의 개별적인 코드 모듈의 기능의 일부 또는 그 전부를 병합하여 이들 간의 "인터페이스"의 형태가 변하도록 하는 것도 가능할 수 있다. 예를 들어, 도 5b 및 도 5c의 기능이 각각 도 5h 및 도 5i의 기능으로 변환될 수 있다. 도 5h에서, 도 5b의 이전의 제1 및 제2 코드 세그먼트가 이들 둘다를 포함하는 모듈로 병합된다. 이 경우에, 이들 코드 세그먼트는 여전히 서로 통신을 할 수 있지만 그 인터페이스는 단일의 모듈에 더 적합한 형태로 개조될 수 있다. 따라서, 예를 들어, 정식의 Call문 및 Return문이 더 이상 필요하지 않을 수 있지만, 인터페이스(Interface1)에 따른 유사한 처리 또는 응답(들)은 여전히 유효할 수 있다. 이와 유사하게, 도 5i에 도시된 바와 같이, 도 5c로부터의 인터페이스(I2)의 일부(또는 그 전부)는 인터페이스(I1) 내에 인라인으로 작성되어 인터페이스(I1")를 형성할 수 있다. 도시된 바와 같이, 인터페이스(I2)는 I2a 및 I2b로 나누어지고, 인터페이스 부분(I2a)은 인터페이스(I1)에 인라인 코딩되어 인터페이스(I1")를 형성한다. 구체적인 예에 있어서, 도 5c로부터의 인터페이스(I1)가 함수 호출 square(input, output)를 수행하고, 이것이 인터페이스(I2)에 의해 수신되며, 인터페이스(I2)가, 제2 코드 세그먼트에 의해 (input(입력)을 제곱하기 위해) input(입력)으로 전달된 값을 처리한 후에, 제곱된 결과를 output(출력)으로 다시 전달하는 것을 생각해보자. 이러한 경우에, 제2 코드 세그먼트에 의해 수행되는 처리(input 을 제곱하는 것)는 인터페이스에 대한 호출 없이 제1 코드 세그먼트에 의해 수행될 수 있다.

D. 분리(divorce)

한 코드 세그먼트로부터 다른 코드 세그먼트로의 통신은 그 통신을 다수의 개별적인 통신으로 분해함으로써 간접적으로 달성될 수 있다. 이것은 도 5j 및 도 5k에 개략적으로 도시되어 있다. 도 5j에 도시된 바와 같이, 제1 인터페이스(Interface1)를 통한 통신을 다른 인터페이스(이 경우에, 인터페이스(Interface2A, Interface2B, Interface2C))에 부합하도록 그 통신을 변환하기 위해, 하나 이상의 미들웨어(들)(분리 인터페이스(divorce interface)(들). 왜냐하면 이들이 기능 및/또는 인터페이스 함수를 원래의 인터페이스로부터 분리시키기 때문임)가 제공된다. 이것은 예를 들어 Interface1 프로토콜에 따라, 이를테면, 운영 체제와 통신을 하도록 설계되어 있는 베이스 애플리케이션(base of application)이 설치되어 있지만 그 운영 체제가 다른 인터페이스(이 경우에, 인터페이스(Interface2A, Interface2B, Interface2C))를 사용하도록 변경되어 있는 경우에 행해질 수 있다. 여기서의 요점은 제2 코드 세그먼트에 의해 사용되는 원래의 인터페이스가 변경되어 더 이상 제1 코드 세그먼트에 의해 사용되는 인터페이스와 호환되지 않게 되고 따라서 이전의 인터페이스와 새로운 인터페이스가 호환되도록 하기 위해 매개물이 사용된다는 것이다. 이와 유사하게, 도 5k에 도시된 바와 같이, 제3 코드 세그먼트가 인터페이스(I1)로부터 통신을 수신하기 위해 분리 인터페이스(DI1)에 도입될 수 있고 또 인터페이스 기능을 예를 들어 인터페이스(I2a, I2b)(DI2와 함께 동작하지만 동일한 기능상 결과를 제공하도록 재설계되어 있음)로 전송하기 위해 분리 인터페이스(DI2)에 도입될 수 있다. 이와 유사하게, DI1 및 DI2는 협력하여 도 5c의 인터페이스(I1, I2)의 기능을 동일 또는 유사한 기능상 결과를 제공하면서 새로운 운영 체제에 맞게 변환시킬 수 있다.

E. 재작성(rewriting)

또다른 가능한 변형예는 인터페이스 기능을 다른 무언가로 대체시키지만 동일한 전체적인 결과를 달성하는 코드를 동적으로 재작성하는 것이다. 예를 들어, 실행 환경(.Net 프레임워크, Java 런타임 환경 또는 다른 유사한 런타임 유형 환경에 의해 제공되는 것 등)에서 중간 언어(intermediate language)(예를 들어, Microsoft IL, Java ByteCode, 기타)로 제공되는 코드 세그먼트가 JIT(Just-in-Time) 컴파일러 또는 인터프리터(interpreter)에 제공되는 시스템이 있을 수 있다. JIT 컴파일러는 제1 코드 세그먼트로부터의 통신을 제2 코드 세그먼트로 동적으로 변환하도록, 즉 그 통신을 제2 코드 세그먼트(원래의 또는 다른 제2 코드 세그먼트 중 어느 하나)에 의해 필요로 될 수 있는 다른 인터페이스에 부합시키도록 작성될 수 있다. 이것은 도 5l 및 도 5m에 도시되어 있다. 도 5l에서 알 수 있는 바와 같이, 이 방식은 상기한 분리(Divorce) 시나리오와 유사하다. 이는, 예를 들어, 설치된 베이스 애플리케이션이 Interface1 프로토콜에 따라 운영 체제와 통신을 하도록 설계되어 있지만 운영 체제가 다른 인터페이스를 사용하도록 변경되는 경우에 행해질 수 있다. 설치된 베이스 애플리케이션으로부터의 통신을 동작 중에 운영 체제의 새로운 인터페이스에 부합시키기 위해 JIT 컴파일러가 사용될 수 있다. 도 5m에 도시된 바와 같이, 인터페이스(들)를 동적으로 재작성하는 이 방식은 또한 인터페이스(들)를 동적으로 인수분해하거나 다른 방식으로 변경하는 데도 적용될 수 있다.

또한 유의할 점은 대안적인 실시예를 통해 인터페이스와 동일한 또는 유사한 결과를 달성하기 위한 상기한 시나리오들이 또한 여러가지 방식으로, 직렬로 및/또는 병렬로, 또는 다른 중재 코드(intervening code)로 조합될 수 있다는 것이다. 따라서, 이상에 제공된 대안적인 실시예는 상호 배타적이지 않으며, 도 5b 및 도 5c에 제공된 일반적인 시나리오들과 동일한 또는 동등한 시나리오를 생성하기 위해 혼합(mix), 정합(match) 및 결합(combine)될 수 있다. 또한, 유의할 점은, 대부분의 프로그래밍 구조(programming construct)에서와 같이, 본 명세서에 기술되어 있지 않을 수 있지만 그럼에도 불구하고 본 발명의 정신 및 범위에 의해 표현되는 인터페이스의 동일 또는 유사한 기능을 달성하는 다른 유사한 방식들이 있다는 것이다. 즉, 유의할 점은 적어도 부분적으로 인터페이스에 의해 표현되는 기능 및 그에 의해 가능하게 되는 유익한 결과들이 인터페이스의 가치의 근간을 이룬다는 것이다. 상기한 시스템들은 본 명세서에 기술된 디버깅 방법 또는 시스템을 구현하는 데 사용될 수 있다. 다양한 특징들은 어떤 디버깅 이벤트가 발생할 때 메모리의 일부분을 덤프하고 덤프된 메모리를 서버로 자동적으로 전송함으로써 디버깅 피드백 정보를 서버에 제공하는 자동화에 대한 것이다.

도 6은 온라인 멀티플레이어 게임 환경에서 토너먼트가 수행될 수 있는 예시적인 프로세스 전체를 나타낸 것이다. 단계(601)에서, 토너먼트 운영 자(tournament administrator)는 온라인 토너먼트의 생성을 시작하기 위해 토너먼트 서버(434) 등의 보안 서버에 로그인하는 단계를 밟을 수 있다. 운영자는 게임 개발자, 플레이어 또는 시스템에 새로운 토너먼트 유형을 생성할 권한을 갖는 누구라도 될 수 있다. 로그인 프로세스는 패스워드 및 컴퓨터 단말기(510)를 사용하여 보안 인터넷 사이트에 액세스하는 것, 또는 콘솔(402)로부터 비디오 게임 사용자 인터페이스를 사용하여 온라인 장소에 액세스하는 것과 같은 임의의 원하는 액세스 모드를 포함할 수 있다. 단계(602)에서, 토너먼트 운영자는 생성되는 토너먼트에 대한 다양한 파라미터를 정의할 수 있다. 이 입력은 인터넷 페이지 또는 비디오 게임 사용자 인터페이스 등의 디스플레이된 인터페이스를 사용하여 달성될 수 있으며, 여기서 운영자는 정의되는 토너먼트에 대한 다양한 파라미터를 입력(또는 리스트로부터 선택)하도록 요청받을 수 있다. 예시적인 파라미터에 대해 이하에서 더 설명한다.

토너먼트 파라미터가 정의되었으면, 이 프로세스는 이어서 단계(603)로 진행하여, 시스템[예를 들어, 그 태스크에 대해 어느 서버가 지정되어 있는지에 따라, 토너먼트 서버(434), 또는 타이틀 서버(432)]은 토너먼트를 인스턴스화하기 위해 트리거를 기다린다. 이 트리거는 미리 정해진 시간량(예를 들어, 1시간, 30분, 기타)의 경과 또는 미리 정해진 수의 플레이어(예를 들어, 10명, 50명, 100명의 플레이어, 기타)에 의한 등록 등의 임의의 유형의 미리 정해진 이벤트일 수 있다.

트리거가 수신되거나 발생될 때, 이 프로세스는 계속하여 단계(604)에서 토너먼트를 인스턴스화할 수 있다. 인스턴스화는 파라미터에 지정된 대로 토너먼트 를 수행하는 하나 이상의 처리 쓰레드의 실행을 수반할 수 있다. 이들 쓰레드는 토너먼트 서버(434), 타이틀 서버(432), 개개의 콘솔(402), 또는 시스템 내의 임의의 다른 컴퓨팅 컴포넌트에 의해 실행될 수 있으며, 원하는 경우 컴포넌트들에 걸쳐[예를 들어, 다수의 콘솔(402)에 걸쳐] 분산되어 있을 수 있다. 토너먼트의 인스턴스는 토너먼트 인스턴스에 참여하고 있는 클라이언트들과의 통신을 조정하는 데 도움이 되는 그 자신의 고유 토너먼트 ID를 할당받을 수 있다.

토너먼트 인스턴스가 생성되면, 토너먼트는 리더보드(leaderboard) ID를 할당받을 수 있다. 기본적인 온라인 서비스(예를 들어, XBOX LIVE™)는 콘솔에 의해 지원되는 다양한 게임 프로그램이 사용할 수 있는 일련의 공통의 리더보드 데이터 구조(leaderboard data structure)를 제공할 수 있다. 다른 대안으로서, 리더보드 데이터 구조는, 예를 들어, 주어진 토너먼트 인스턴스에 대한 예선 득점(qualification score)을 보유함으로써 각각의 토너먼트 인스턴스를 지원하도록 생성된 커스텀 구조일 수 있다. 이들 구조는 다양한 플레이어들에 대한 ID(identification) 및 게임에서의 플레이어의 성적에 대한 하나 이상의 데이터값(예를 들어, 플레이어의 레이스 시간(race time), 좋아하는 자동차, 득점, 우승/패배 기록, 총 득점, 플레이 상대, 기타)을 저장하는 정의된 데이터베이스 객체일 수 있으며, 콘솔(402) 상의 게임 클라이언트, 토너먼트 서버, 및 기타 장치들은 게임 세션 및 토너먼트 결과를 획득하기 위해 리더보드 데이터 구조에 SQL 질의를 실행할 수 있다. 리더보드는 타이틀 서버(432), 통계 서버(424) 또는 시스템 내의 임의의 다른 원하는 장치에 의해 소프트웨어 프로세스로서 관리될 수 있다. 어떤 경 우에, 토너먼트의 서로 다른 측면에 대해 서로 다른 리더보드 구조가 사용될 수 있다. 예를 들어, 타이틀 서버(432)는 다양한 토너먼트 참가자에 대한 예선 데이터(qualification data)를 받아서 처리하는 예선 리더보드(qualification leaderboard)를 관리할 수 있는 반면(이하에서 설명함), 통계 서버(424)는 플레이어의 토너먼트 과정을 추적하기 위해 전체적인 점수 리더보드 데이터 구조를 관리할 수 있다.

토너먼트가 인스턴스화되면, 이 프로세스는 단계(605)에서 토너먼트를 수행한다. 토너먼트를 관리하는 토너먼트 코드의 실제 실행은 토너먼트 서버(434), 타이틀 서버(432) 및/또는 게임 콘솔(402) 등 어느 서버에서라도 행해질 수 있는데, 그 이유는 서로 다른 토너먼트가 토너먼트 운영자에 의해 선택된 파라미터에 따라 서로 다르게 수행되기 때문이다. 예시적인 토너먼트에 대해 도 8 및 도 9를 참조하여 이하에서 더 설명한다.

토너먼트(또는 라운드(round) 등의 그의 일부분)가 수행되었으면, 프로세스는 단계(606)로 이동하여, 다양한 게임 클라이언트가 토너먼트를 관리하는 서버에게 그의 결과를 보고한다. 클라이언트는 개개의 콘솔(402) 상에서 실행 중인 게임 코드일 수 있고, 각각의 콘솔은 토너먼트의 서버에 결과를 보고할 책임이 있을 수 있다. 이들 결과는 그 특정의 콘솔(402)의 플레이어의 성적에 관한 정보를 포함할 수 있고, 또한 게임 세션에 참여한 다른 플레이어들 중 일부 또는 그 전부의 성적에 관한 정보도 포함할 수 있다(예를 들어, 플레이어의 콘솔은 그 플레이어의 점수 뿐만 아니라 게임 세션 내의 나머지 플레이어들 전부의 점수도 보고할 수 있고, 이 다수의 보고된 정보는 속임수가 행해지지 않았는지를 확인하기 위해 서로 대조하여 비교될 수 있으며, 이에 대해서는 이하에서 더 기술한다). 다른 대안으로서, 다수의 콘솔(402)이 단일의 게임 세션에 참여할 수 있기 때문에, 세션에 참여하고 있는 콘솔들 중 하나가 그 세션에서 플레이한 모든 사람에 대한 결과를 보고하도록 지정될 수 있고 그 세션에서의 나머지 콘솔들이 중복하여 그 보고를 하는 것을 피할 수 있도록 이러한 보고가 콘솔들(402) 간에 조정될 수 있다. 이들 결과는 또한 통계 서버(424) 등의 리더보드를 실행하는 서버에, 그 서버가 요구하는 보안 통신을 사용하여, 보고될 수 있다. 리더보드에 결과를 별도로 보고하는 것은 토너먼트 서버에 보고되는 데이터에서의 변칙들을 해결하는 데 도움을 줄 수 있으며, 이에 대해서는 이하에서 더 상세히 기술할 것이다.

실제의 결과는 플레이되는 게임의 유형에 따라 임의의 형태로 되어 있을 수 있으며, 일반적으로 게임 세션에서 플레이어가 거둔 성과에 관해 보고할 수 있다. 예를 들어, 1인칭 슈터형 게임(first-person shooter type game)은 플레이어의 적중율, 좋아하는 무기, 기타 등등을 보고할 수 있는 반면, 축구 게임은 게임의 승패 결과, 점수, 그리고 기타 플레이어 및/또는 게임 통계를 보고할 수 있다. 게임은 플레이어의 성적을 평가하여 점수, 순위 또는 기타 보상을 지급하는 데 그 자신의 기준을 사용할 수 있으며, 이러한 보상이 결과로서 보고될 수 있다.

토너먼트의 서버가 각종의 클라이언트로부터 토너먼트 결과를 수신하게 되고 또 각각의 플레이어의 성적에 대한 다수의 보고서를 받을 수 있기 때문에, 모순 및 변칙이 일어날 수 있다. 예를 들어, 2개의 콘솔(402)이 단일의 게임에 대한 또는 게임에서의 단일의 플레이어에 대한 모순되는 게임 결과를 보고할 수 있다(예를 들어, 각각이 서로 다른 우승자, 점수, 통계, 기타 등등을 보고함). 호스트 마이그레이션(host migration)이 행해지는 게임에서(예를 들어, 세션에 참여하고 있는 콘솔들 중 하나가 게임에 대한 로컬 서버 호스트로서 지정되지만 그 콘솔이 세션 동안에 탈락 또는 패배를 겪어 참여 중인 다른 콘솔이 호스트로서 인계를 받는 게임에서), 여러 콘솔들이 불완전한 또는 다른 방식으로 모순되는 결과들을 보고할 수 있다. 단계(607)에서, 토너먼트의 서버는 여러 클라이언트들로부터 보고된 결과를 비교하고 보고된 결과들에서 모순을 찾는다. 그에 부가하여, 이 서버는 어떤 보고된 결과가 플레이된 게임 세션에 대해 정상이라고 또는 타당하다고 생각되는 것의 한계를 넘는지 알아보기 위해 그 결과를 정상적인 또는 타당한 결과를 식별해주는 사전 정의된 데이터 구조와 비교할 수 있다. 예를 들어, 통상적인 축구 게임에서, 게임 설계자는 사전 정의된 총점을 초과하는 점수(예를 들어, 100점 이상)가 비정상일 수 있다고 결정할 수 있다.

변칙이 검출되면, 프로세스는 단계(608)로 이동하여, 중재 프로세스가 변칙을 해결 및/또는 정정하기 위해 보고된 결과를 분석한다. 이 중재 프로세스는 개개의 플레이어 결과를 검색하기 위해 리더보드 서버에 질의하는 것 및 비교를 수행하는 것을 수반할 수 있다. 또는, 이 중재는 토너먼트에 배정된 리더보드를 관리하는 서버에 명백한 상충을 보고하는 것을 수반할 수 있으며, 그 서버[예를 들어, 통계 서버(424)]는 그가 수신한 결과를 자체적으로 비교할 수 있고 어느 결과 세트가 진짜 세트인지를 확인하기 위해 부가의 보안 및/또는 무결성 검사를 실행할 수 있다. 중재 프로세스는 관여된 플레이어들의 상대적 신용성(relative credibility)을 식별해주는 저장된 데이터에 액세스할 수 있다. 중재 프로세스가 보고된 결과에서 오류를 식별하는 경우, 프로세스는 단계(609)에서 리더보드 데이터를 갱신하고 오류를 정정할 수 있다.

어떤 변칙도 검출되지 않은 경우, 또는 변칙이 정정된 후에, 프로세스는 단계(610)로 진행하여 토너먼트가 완료되어야만 하는지를 알아보기 위해 검사를 할 수 있다. 서로 다른 토너먼트는 토너먼트가 어떻게 완료되는지를 정의하는 서로 다른 파라미터를 가질 수 있다. 예를 들어, Tournament Winner(토너먼트 우승자) 파라미터는 이하에서 더 기술되는 바와 같이 사용될 수 있다. 이 단계에서, 토너먼트 프로세스는 보고된 결과 또는 전체 결과를 토너먼트 우승자를 정의하는 파라미터(들)와 비교하고 우승자가 있는지와 토너먼트가 완료되어야만 하는지를 결정할 수 있다.

토너먼트가 완료되어서는 안되는 경우, 프로세스는 단계(605)로 돌아가서 토너먼트를 계속 수행할 수 있다. 예를 들어, 이것은 토너먼트의 그 다음 라운드를 처리하는 일을 수반할 수 있다.

토너먼트가 완료되어야 하는 경우, 프로세스는 단계(611)로 이동하여 토너먼트를 완료할 수 있다. 이 완료는 플레이어 순위 및 토너먼트 우승자를 결정하기 위해 리더보드 데이터 객체로부터의 점수 및 결과를 최종 집계(final tallying)하는 것을 수반할 수 있다. 토너먼트를 완료시키는 일은 종종 우승자 및 사전 정의된 순위에 드는 자(예를 들어, 2위, 3위, 상위 10명, 기타)에게 상을 수여하는 것 을 수반한다. 이 상은 토너먼트 후원자에 의해 제공되는 물리적 아이템이거나, 특정의 디자인을 갖는 레이스카, 특수 장비 또는 무기, 기타 등등의 게임내 가상 아이템(in-game virtual item)일 수 있다. 토너먼트를 완료시키는 것은 또한 토너먼트의 리더보드 데이터 객체가 다른 토너먼트 또는 다른 게임에 사용될 수 있게 해주기 위해 리더보드 ID를 해제하는 것, 장래의 액세스를 위해 결과를 보존 데이터베이스(archival database)에 기록하는 것, 상위 점수들을 기록하는 것, 기타 등등을 포함할 수 있다. 토너먼트의 완료 시에, 프로세스는 단계(603)로 돌아가서 그 다음 트리거링 이벤트(triggering event)를 기다릴 수 있다. 원한다면, 플레이어들이 토너먼트를 계속하여 이용할 수 있도록, 토너먼트 인스턴스가 아직 존재하지 않는 경우 또는 토너먼트가 완료된 직후, 토너먼트 인스턴스를 자동적으로 생성하기 위해 토너먼트 트리거 파라미터가 정의될 수 있다. 상기한 바와 같이, 원하는 경우 다수의 토너먼트 인스턴스가 동시에 존재할 수 있으며, 따라서 제2 토너먼트의 인스턴스화가 이전의 인스턴스의 완료에 의존할 필요가 없다. 예를 들어, 토너먼트 인스턴스의 완료가 단순히 프로세스를 종료시키고, 각각의 독립적인 인스턴스에 대해 별개의 프로세스가 행해질 수 있다.

상기 도 6과 관련하여 토너먼트 파라미터를 정의하는 단계에 대해 언급하였으며, 그 단계에 대해 상세히 기술하기 위해, 이하에서는 사용될 수 있는 몇가지 예시적인 토너먼트 파라미터에 대해 설명한다.

Tournament Name(토너먼트 이름) - 참가자들에게 토너먼트를 식별시키기 위해 운영자에 의해 부여되는 텍스트 문자열(예를 들어, "Halo2™ Slayfest Sponsored by Microsoft").

Tournament Owner(토너먼트 소유자) - 토너먼트의 운영자의 ID. 예를 들어, 토너먼트의 소유자는 게임 개발자 또는 토너먼트의 후원자일 수 있다.

Tournament Type(토너먼트 유형) - 사전 정의된 토너먼트 유형의 ID. 토너먼트 서버(434)는 운영자가 액세스하여 커스터마이즈할 수 있는 다수의 사전 정의된 토너먼트 유형[예를 들어, 1패 탈락(single elimination), 2패 탈락(double elimination), 이하에 기술되는 기타 등등]을 제공할 수 있다.

Number of Tournament Entrants(토너먼트 참가자의 수) - 토너먼트에서 지원되는 총 플레이어 참가자의 최소 인원수, 최대 인원수, 범위, 및/또는 선호 인원수를 식별해주는 하나 이상의 값. 어떤 토너먼트는 적은 규모에 더 적합할 수 있는 반면, 다른 형식들은 더 많은 수의 플레이어들에 더 이상적일 수 있다.

Number of Game Session Entrants(게임 세션 참가자의 수) - 토너먼트의 각각의 게임 세션에 참가하는 플레이어의 최소 인원수, 최대 인원수, 범위 및/또는 선호 인원수를 식별해주는 하나 이상의 값. 게임 세션은 각각의 게임에 의해 서로 다르게 정의될 수 있으며, 게임에서의 기본 플레이 단위를 참조할 수 있다. 이것은 게임 유형에 따라 다를 수 있다. 예를 들어, 체스 게임은 세션(예를 들어, 보드)마다 2명의 참가자를 필요로 하지만, 포커 게임은 세션(예를 들어, 테이블)마다 5명의 참가자를 필요로 할 수 있다.

Number of Rounds(라운드 수) - 토너먼트의 라운드의 최소 횟수, 최대 횟수, 범위 및/또는 선호 횟수를 식별해주는 하나 이상의 값. 토너먼트의 라운드는 각각 의 토너먼트 참가자가 한 게임 세션에서 플레이할 때 행해지도록 정의될 수 있다.

Window Factor(윈도우 인자) - 어떤 토너먼트에서, 플레이어들이 서로를 상대로 하여 마지막으로 플레이한 이후로 얼마나 지났는지에 적어도 부분적으로 기초하여, 특정의 게임 세션(예를 들어, 일군의 플레이어들을 필요로 하는 단일의 "데스 매치(death match)")에 대한 플레이어들이 함께 그룹화될 수 있다. 윈도우 인자는 플레이어들이 토너먼트의 동일한 게임 세션에서 서로 다시 플레이할 수 있기 이전에 경과해야 하는 시간을 식별해줄 수 있으며, 이 시간은 게임 세션, 라운드 및/또는 토너먼트의 관점에서는 물론 초, 분, 시간, 일, 주, 기타 등등의 관점에서 측정될 수 있다. 예를 들어, 토너먼트는 2 게임 세션의 윈도우 인자를 지정할 수 있으며, 이는 2명의 플레이어가 어떤 게임에 대해 함께 그룹화되기 이전에 적어도 2 게임 동안 서로를 상대로 플레이해서는 안된다는 것을 의미한다. 윈도우 인자의 사용은 무한의 지속기간 또는 아주 많은 수의 대전 및 플레이어를 갖는 토너먼트에 대해 특히 바람직할 수 있다. 윈도우 인자의 사용을 지원하기 위해, 토너먼트 인스턴스는 토너먼트 내의 각각의 플레이어 쌍이 토너먼트에서 서로를 상대로 마지막으로 플레이한 때를 식별해주는 데이터 테이블을 저장할 수 있다.

Rank Gap(순위차) - 어떤 토너먼트에서, 플레이어들은 그의 점수, 순위, 기량 레벨, 기타 등등에 따라 함께 그룹화될 수 있으며, 순위차는 플레이어들이 함께 그룹화될 수 있는 순위 범위를 식별해줄 수 있다. 예를 들어, 토너먼트는, 플레이어들이 상대편으로부터 20점 이내에 있는 경우 또는 플레이어들의 전체적인 순위가 상대편으로부터 몇 순위(예를 들어, 상대편보다 10 순위 미만 높거나 낮은 플레이 어) 또는 퍼센트(토너먼트의 총 참가자 수에 대한 퍼센트) 이내에 있는 경우에만, 그 플레이어들을 함께 그룹화하고자 할 수 있다.

Scheduling Options(스케쥴링 옵션) - 이들 옵션은 토너먼트가 플레이되는 스케쥴을 식별해준다. 토너먼트는 연속적일 수 있으며, 이 경우 새로운 라운드가 이전 라운드의 완료 시에 또는 스케쥴에 따라 자동적으로 시작된다. 스케쥴은 라운드 및 게임 세션이 수행될 수 있는 어떤 시간 프레임(time frame)[주말에만 있는 토너먼트, 매일 있는 토너먼트(daily tournament), 특정의 날짜 및/또는 시각, 매 30분마다, 기타 등등]을 나타낼 수 있다.

New player factor(새로운 플레이어 인자) - 새 플레이어의 점수가 순위에서 어떻게 사용되는지를 식별해주는 하나 이상의 값. 점수 순위(point ranking)에 대해 이하에서 더 상세히 기술하지만, 어떤 토너먼트의 경우, 플레이어들은 플레이어의 참가 초기에 그다지 통계적 의미가 없을 수 있는 데이터값에 따라 순위가 매겨질 수 있다. 예를 들어, 단순히 승패 기록에 기초하여 플레이어의 순위를 매기는 토너먼트는 무패인 30-0 플레이어를 1-0 기록을 갖는 새 플레이어와 동일하게 순위를 매길 수 있지만(둘다 100% 우승자임), 사실은 새 플레이어가 이러한 높은 순위를 받을 자격이 없을지도 모른다. 이것에 대응하기 위해, 토너먼트는 새로운 플레이어 인자를 사용할 수 있으며, 이 경우 새 플레이어의 점수는 순위 지정에서 사용되기 이전에 조정된다. 따라서, 예를 들어, 새 플레이어의 점수는, 단지 한 게임 세션의 점수만이 이용가능한 경우 75%, 2개의 게임 세션의 점수가 이용가능한 경우 50%, 3개의 게임 세션의 점수가 이용가능한 경우 25%만큼 감소될 수 있으며, 4개 이상의 게임 세션의 점수가 이용가능한 경우 전혀 공제(discount)되지 않을 수 있다. 새로운 플레이어 인자는 효과의 기간(예를 들어, 라운드 또는 게임 세션의 수) 및 효과의 조정값(예를 들어, 득점 공제, 점수값 가산/감산, 기타)을 식별해줄 수 있다.

Trigger event(트리거 이벤트) - 토너먼트의 인스턴스가 생성되게 하는 하나 이상의 이벤트의 ID. 이것은 상기한 스케쥴링 파라미터와 관련되어 있을 수 있으며, 이 경우 트리거 이벤트는 단순히 스케쥴과 일치하는 시각일 수 있다. 다른 유형의 트리거도 역시 사용될 수 있다. 예를 들어, 미리 정해진 수의 플레이어가 토너먼트에 등록을 하였을 때 또는 토너먼트에 이미 등록을 한 하나 이상의 플레이어가 명령을 입력할 시에(예를 들어, 모든 등록된 플레이어가 준비되었음을 신호하기 위해 컨트롤러 버튼을 누를 시에), 토너먼트가 자동적으로 시작될 수 있다.

Tournament winner(토너먼트 우승자) - 토너먼트 우승자가 결정되는 방식을 식별해주는 하나 이상의 값. 이것은 미리 정해진 총 점수(예를 들어, 1000점에 최초로 도달한 플레이어 또는 총 레이스 시간이 최저인 사람), 미리 정해진 게임 이벤트(예를 들어, 게임 내에서 주어진 목적을 최초로 달성한 플레이어), 또는 다수의 라운드 이후의 순위(예를 들어, 마지막 라운드 이후에 최상위 순위를 갖는 플레이어), 기타 등등일 수 있다.

Game-specific Options(게임 관련 옵션들) - 특정의 게임과 관련이 있을 수 있는 다수의 다른 옵션들. 이들은 레이싱 게임 토너먼트에 대한 레이스 트랙의 ID, 기상 조건, 자동차 유형, 및 채점(point scoring), 또는 1인칭 슈터 토너먼 트(first-person shooter tournament)에 대한 지도 유형의 ID, 무기 로드아웃(weapon loadout), 및 채점(scoring)을 포함할 수 있다.

다양한 토너먼트 파라미터가 도 7에 도시된 바와 같은 토너먼트 데이터 패키지의 데이터 구조(701)에 저장될 수 있다. 이 데이터 구조는 하나 이상의 라운드 리스트(702)를 포함할 수 있으며, 여기서 각각의 라운드 리스트는 토너먼트에서의 라운드들의 세그먼트/스테이지/서브셋(segment/stage/subset)에 대한 데이터를 포함한다. 예를 들어, 예시적인 토너먼트(701)는 13개 라운드를 포함하는 토너먼트(3개의 세그먼트 또는 스테이지로 나누어져 있음)이다. 라운드 리스트는, 리스트 내의 다수의 라운드의 ID 및 리스트 내의 라운드들에 대한 공통의 설정, 파라미터 또는 주제(예를 들어, 리스트 1 내의 모든 레이스가 "뉴욕" 레이스 트랙에서 있게 될 것임 또는 리스트 1 내의 모든 레이스가 "비가 오는(rainy)" 날씨로 설정된 상황에서 행해질 것임) 등의, 특정 리스트에 대한 정보를 포함하는 헤더 부분(703)을 포함할 수 있다. 이 리스트는 또한, 각각의 대응하는 게임 세션에 대해 사용될 파라미터들을 포함하는, 복수의 개개의 라운드 설정(704)을 포함할 수 있다. 예를 들어, 제1 라운드 설정은 단지 저성능 자동차만이 제1 레이스에 사용될 수 있음을 나타낼 수 있는 반면, 제2 라운드 설정은 4륜 구동 자동차만이 제2 레이스에 사용될 수 있음을 나타낼 수 있다. 이하의 의사코드는 토너먼트 데이터 패키지의 일례를 제공한다.

상기 예에서, 토너먼트 설정 파일은 다수의 패키지를 포함할 수 있으며, 각각의 패키지는 다수의 리스트를 포함할 수 있고, 각각의 리스트는 리스트의 내부 핸들(internal handle)에 대한 데이터 값, 디스플레이될 텍스트값, 및 게임에서의 설정에 대한 하나 이상의 게임 코드를 포함할 수 있다. 게임 코드는 게임을 구성하기 위해 게임 프로그램에 의해 사용되는 테이블 내의 엔트리에 대응하는 숫자값일 수 있다. 예를 들어, 레이싱 게임은 16개의 서로 다른 레이스 트랙을 구비하고 있을 수 있으며, 코드 '1011'는 사용하기 위한 제11 트랙을 식별해주는, 이들 트랙을 열거하는 테이블에 대한 이진 인덱스일 수 있다. 기타 코드들도 이와 유사하게 날씨, 자동차 변속기, 트랙에서의 방향, 자동차의 유형, 기타 등등에 대한 테이블 등의, 기타 설정 테이블에 대한 인덱스일 수 있다. 이하의 예는 이러한 테이블이 어떻게 구성될 수 있는지를 나타낸 것이다.

<변속기 유형>

0 - 수동

1 - 자동

<날씨 유형>

0 - 정상

1 - 맑고 더움

2 - 비

3 - 눈

4 - 결빙

5 - 강한 바람

그에 부가하여, 이들 값이 모두 테이블에 대한 인덱스 코드일 필요는 없다. 예를 들어, 최대 마력에 대한 값은 단지 그 최대 마력에 대한 숫자값을 포함할 수 있다. 토너먼트 인스턴스에 대한 스케쥴 데이터(예를 들어, 토너먼트가 얼마나 빈번히 인스턴스화되는지, 조건, 기타) 및 개개의 라운드에 대한 스케쥴 데이터(예를 들어, 라운드가 얼마나 자주 행해지는지) 등의, 기타 데이터도 포함될 수 있다.

상기한 바와 같이, 다양한 토너먼트 유형이 있을 수 있다. 1패 탈락(single elimination), 2패 탈락(double elimination) 및 라운드-로빈(round-robin) 유형 토너먼트가 사용될 수 있다. 도 8은 사용될 수 있는 다른 유형의 토너먼트의 일례를 나타낸 것이다. 도 8의 토너먼트에서, 플레이어들은 단계(801)에서 토너먼트에 참가하기 위해 등록하는 것으로 시작을 한다. 등록은 다양한 방식으로 행해질 수 있다. 예를 들어, 플레이어는 타이틀 서버(432) 또는 토너먼트 서버(434) 등의 서버에 로그온할 수 있고 등록하기 위한 빈자리가 있는 이용가능한 토너먼트의 리스트를 획득하기 위해 서버에 질의를 할 수 있다. 질의를 받은 서버는 이용가능한 토너먼트의 리스트를 반환하여 관련 토너먼트 파라미터(예를 들어, 토너먼트 이름, 라운드 수, 이미 등록한 참가자의 수, 시작 시간, 상금, 기타)를 디스플레이할 수 있고, 사용자는 컨트롤러 상의 버튼을 누름으로써 하이라이트된 특정 토너먼트에 등록할 수 있다. 다른 대안으로서, 플레이어는 토너먼트에 이미 등록을 한 다른 플레이어가 보낸 초대를 받은 결과로서 토너먼트에 참가할 수 있다.

플레이어 등록(801)은 미리 정해진 시간(예를 들어, 토너먼트 인스턴스가 생성된 이후의 경과 시간, 스케쥴링된 토너먼트의 시각, 첫번째 등록자 이후의 경과 시간, 기타)이 경과할 때까지 또는 미리 정해진 수의 등록자(예를 들어, 토너먼트 파라미터가 최대 참가자 수를 정의함)가 참가할 때까지 계속될 수 있다. 등록이 종료될 때, 토너먼트는 먼저 단계(802)에서 참가자를 랜덤한, 또는 의사-랜덤한 순서로 배치하는 것으로 시작을 할 수 있다. 이러한 초기 순위 배치는 임의의 원하는 방식으로, 예를 들어, 알파벳순으로 또는 등록순으로 행해질 수 있는데, 그 이유는 그 순서가 곧 재정렬되기 때문이다.

이어서, 단계(803)에서, 프로세스는 그 다음 라운드에 대한 게임 세션에서 사용할 플레이어의 수를 결정할 수 있다. 이것은 상기한 Number of Game Session Entrants 파라미터를 조회함으로써 행해질 수 있지만, 총 참가자 수에 기초한 계산 및 조정을 수반할 수도 있다. 예를 들어, 프로세스는 이상적인 세션 크기를 구하기 위해 계산(예를 들어, 총 참가자 수를 Number of Game Session Entrants 파라미터에서의 여러가지 값으로 나누는 것)을 수행할 수 있다. 이상적인 세션 크기는 모든 세션이 동일한 수의 플레이어를 가질 수 있게 해주는 크기이거나, 또는 모든 세션의 크기가 1명의 플레이어 미만(또는 임의의 다른 미리 정해진 값)만큼 다른 크기일 수 있다. 세션 크기의 결정은 또한 게임 세션마다 더 많은(또는 더 적은) 수의 플레이어를 사용하는 쪽을 선택하거나, 파라미터에 지정된 선호된 수에 가장 가까운 수를 갖는 쪽을 선택할 수 있다.

프로세스가 세션에 있어야 하는 플레이어의 수가 완료되었을 때, 프로세스는 단계(804)로 진행하여, 그 다음 게임 세션에 대한 새로운 그룹을 채우기 시작할 수 있다. 단계(805)에서, 아직 그룹에 배정되지 않은 최고 순위 플레이어가 새로운 그룹에 배정된다. 단계(806)에서, 그 다음 최고의 미배정된 플레이어(예를 들어, 잠재적인 플레이어)에 대한 데이터가 검색되고, 단계(807)에서, 그 잠재적인 플레이어가 현재 그룹에 이미 배정된 나머지 플레이어들 중 임의의 플레이어와 최근에 플레이한 적이 있는지를 알아보기 위해 검사가 행해진다. 이것은, 예를 들어, 각각의 참가자 쌍이 게임 세션에서 마지막으로 함께 플레이한 때를 추적하는 저장된 테이블을 조회함으로써 행해질 수 있다.

잠재적인 플레이어가 그룹 내의 나머지 플레이어들 중 하나와 지나치게 최근에 플레이한 적이 없는 경우, 단계(808)에서 잠재적인 플레이어는 그룹에 추가된다. 반면에, 잠재적인 플레이어가 지나치게 최근에 플레이한 적이 있는 경우, 프로세스는 그 잠재적인 플레이어를 건너뛰고 계속하여 단계(809)로 가서, 현재 그룹이 차있는지를 알아보기 위해 검사가 행해진다. 그룹이 채워져 있지 않은 경우, 프로세스는 단계(806)로 되돌아가서 그 다음의 미배정된 플레이어에 대한 정보를 검색한다. 그룹이 채워져 있는 경우, 프로세스는 단계(810)로 가서 미배정된 플레이어가 남아 있는지를 알아본다. 남아 있는 경우, 프로세스는 단계(804)로 되돌아가서, 새로운 그룹을 채우기 시작한다. 마지막 몇명의 미배정된 플레이어 모두가 지나치게 최근에 서로 플레이한 적이 있는 경우, 도시되지 않은 한가지 선택적인 단계가 행해질 수 있다. 이 상황에서, 프로세스는 단순히 이들 플레이어에 대해 Window Factor 기준을 무시하고 이들을 하나 이상의 최종 그룹으로 그룹화할 수 있다. 다른 대안으로서, 본 시스템은 미리 정해진 양만큼 윈도우 인자를 조정할 수 있고(예를 들어, 1만큼 감소시킴), 프로세스를 새로 시작한다.

모든 플레이어가 그룹에 배정된 경우, 프로세스는 단계(811)로 진행하여, 그 플레이어들이 게임 세션을 플레이한다. 게임 세션이 완료될 때(예를 들어, 플레이어가 레이스 경주를 종료할 때, 축구 게임을 완료할 때, 데스 매치를 종료할 때, 기타 등등일 때), 프로세스는 단계(812)로 진행하여, 플레이어들은 게임 세션에서의 그들의 성적에 기초하여 점수를 할당받는다. 이들 점수는 게임 유형에 따라 다를 수 있으며, 서로 다른 게임 성적에 대해 서로 다른 점수가 부여된다. 다양한 유형의 채점 메카니즘이 사용될 수 있다. 예를 들어, 토너먼트 서버는 가장 최근의 게임 세션 동안에 각각의 플레이어가 거둔 성적에 대한 게임 점수, 토너먼트에서 지금까지 각각의 플레이어가 누적한 점수를 계산하는 누적 게임 득점, 함께 플레이한 다른 플레이어의 수 및/또는 순위를 고려하는 대전 점수(match score)(예를 들어, 주어진 세션에서 패배한 각각의 플레이어에 대한 점수), 및 플레이어가 토너먼트에서 지금까지 누적할 수 있었을 최대 점수를 나타내는 가용 누적 점수(available cumulative score)를 기록할 수 있다.

점수 할당을 수행하는 서버 또는 콘솔은 또한 순위 지정을 위한 계산도 수행할 수 있다. 예를 들어, 토너먼트 프로세스는 플레이어가 획득할 수 있는 최대 가능 점수의 퍼센트를 나타내는 득점 퍼센트(scoring percentage)를 계산할 수 있다(예를 들어, 플레이어의 누적 게임 점수를 가용 누적 점수로 나눔). 프로세스는 새로운 플레이어의 점수가 (다음 단계에서) 그 플레이어의 순위를 재지정하는 데 사용되기 이전에 그 점수를 조정하기 위해 New Player Factor 파라미터를 적용할 수 있다.

이어서, 단계(813)에서, 프로세스는 플레이어의 총 점수 및/또는 상기한 득 점 퍼센트에 기초하여 다양한 플레이어를 순서 재지정(reorder) 또는 순위 재지정(re-rank)할 수 있다. 플레이어의 순서가 재지정된 경우, 프로세스는 단계(814)에서 플레이할 라운드가 더 있는지를 알아보기 위해 검사를 할 수 있다. 이 판정은, 토너먼트 파라미터에 지정된 바와 같이, 플레이어가 필요한 수의 라운드를 플레이했는지 또는 우승을 위한 어떤 다른 조건을 성취했는지에 기초할 수 있다. 플레이어할 라운드가 더 있는 경우, 프로세스는 단계(804)로 되돌아가서 플레이어들을 재그룹화할 수 있다. 더 이상 라운드를 플레이할 필요가 없는 경우, 도 6과 관련하여 상기한 바와 같이, 프로세스는 단계(815)로 가서 토너먼트를 종료할 수 있다.

도 8c는 도 8a 및 도 8b의 토너먼트 프로세스에서 행해질 수 있는 플레이어 순위 지정, 그룹화 및 순위 재지정의 예시적인 배열을 나타낸 것이다. 플레이어들은 좌측에 나타낸 바와 같이 라운드 1에 대해 순위 지정될 수 있고, 3개의 그룹으로 그룹화될 수 있으며(그룹마다 4명의 플레이어), 이어서 라운드 1에서의 그들의 성적에 기초하여 우측에 나타낸 바와 같이 순위 재지정될 수 있다. 제2 라운드에 대해 플레이어들을 그룹화함에 있어서, 4명의 최고 순위로 재지정된 플레이어들은 플레이어 A, E, I 및 B이지만, B가 이전 라운드에서 플레이어 A와 방금 플레이했기 때문에, 프로세스는 플레이어 B를 건너뛰고 그 다음으로 최고인 플레이어, 즉 플레이어 F를 그룹 1에 추가할 수 있다. 플레이어 B는 이어서 제2 라운드에서는 그룹 2에 배치될 수 있다. 도 8c에 예시된 예는 최종 플레이어, 즉 플레이어 L이 새로운 그룹으로 격하됨을 나타내고 있는데, 그 이유는 그 플레이어가 제2 라운드의 그 룹 3의 플레이어 K와 너무 최근에 플레이했기 때문이다. 원하는 경우, 프로세스는 리스트의 하단에 있는 하나 이상의 그룹이 Window Factor 제한에 상관없이 서로 플레이할 수 있게 해줄 수 있다. 예를 들어, 플레이어 L은 플레이어 K와 최근에 플레이했음에도 불구하고 단순히 그룹 3 내에서 대전될 수 있다. 다른 대안으로서, 대전될 수 없는 하단에 있는 플레이어들은 토너먼트로부터 누락될 수 있다.

다른 대안으로서, 순위의 하단에 나타나는 하나 이상의 그룹이 단순히 토너먼트로부터 누락될 수 있으며, 그에 의해 경과 라운드(passing round)를 갖는 필드가 좁혀진다. 어쨋든 누락된 그룹이 가장 약한 플레이어를 포함할 가능성이 더 많도록 적어도 어떤 예선 순위를 참작하기 위해, 누락이 미리 정해진 수의 라운드(예를 들어, 2개의 라운드)의 경과 후에 시작될 수 있다.

도 8의 방법은 단지 한 예에 불과하며, 이러한 유형의 토너먼트에 대한 수정이 행해질 수 있다. 예를 들어, Rank Gap 파라미터는 새로운 플레이어가 순위에 있어서 그룹 내의 나머지 플레이어들에 충분히 가까운 경우에만 플레이어를 그룹에 추가하기 위해 단계(807) 및 단계(808)에서 제2 검사로서 사용될 수 있다. 토너먼트 서버는 또한 Rank Gap 및 Window Factor 파라미터가 얼마나 엄격하게 사용되어야 하는지에 따라 우선순위를 다르게 할 수 있다, 예를 들어, 그 결과 얻어지는 필요한 그룹의 수가 미리 정해진 문턱값을 초과하는 경우 또는 파라미터의 요건을 만족시키는 그룹을 채울 플레이어가 충분하지 않은 경우에, 한 요건 또는 양 요건 둘다를 무시해야만 할지도 모른다. 이 서버 우선순위는 다른 우선순위를 무시하기 전에 한 우선순위를 무시할 수 있다.

다른 옵션으로서, 프로세스는 토너먼트가 시작된 후에 새로운 플레이어의 추가적인 등록 및 원래 등록된 플레이어의 탈락(예를 들어, 단념)을 고려할 수 있다. 새로 등록한 플레이어가, 예를 들어, 단계(803) 이전에, 단순히 그 다음 라운드에 대한 가용 플레이어의 풀에 추가될 수 있다. 다른 대안으로서, 새로운 플레이어가 참가할 수 있는 때에 제한이 있을 수 있다(예를 들어, 제1 미리 정해진 수의 라운드 후에만, 또는 마지막 미리 정해진 수의 라운드에서 금지됨, 기타 등등). 새로운 플레이어를 추가할 때, 새로운 플레이어는 처음에 랜덤한 순위를 부여받을 수 있거나[단계(802)에서의 초기 배치에서와 같음], 다른 대안으로서, 플레이어는 자동적으로 리스트의 중간에 또는 하단에 순위 지정될 수 있다. 새로운 플레이어가 몇 라운드를 플레이한 후에 그의 선두를 넘어 빠르게 순위가 올라가지 않도록 하기 위해, New Player Factor 파라미터가 새로운 플레이어의 점수를 조정하는 데 사용될 수 있다. 예를 들어, 득점 퍼센트가 사용되고 새로운 플레이어가 그의 제1 라운드를 승리한 경우, New Player Factor는, 새로운 플레이어가 1 라운드를 승리한 후에 너무 빨리 올라가지 않도록, 플레이어가 단지 1 라운드만 플레이한 경우 플레이어의 득점 퍼센트에 0.25를 곱할 수 있다. 이와 유사하게, 미리 정해진 수의 라운드 후에 플레이어의 전체 점수(full score)가 반영되도록, New Player Factor는 플레이어가 몇 라운드를 플레이했는지에 따라 다를 수 있다(예를 들어, 2 라운드 후에는 0.5를 사용하겨, 3 라운드 후에는 0.75, 4 라운드 후에는 1.0을 사용함).

도 8의 토너먼트 프로세스는 많은 수의 플레이어를 수용하기 위해 사용될 수 있으며, 연속적인 토너먼트(예를 들어, 한정되지 않은 수의 라운드가 있는 토너 먼트)를 실행하기 위해 사용될 수 있다. 도 9는 도 8의 프로세스에 부가하여 사용될 수 있는 다른 토너먼트 프로세스를 나타낸 것이다. 도 9의 프로세스에서, 토너먼트 참가자들을 먼저 예선을 거치게 하여 씨드를 주기 위해 리더보드 예선 기간(leaderboard qualification period)이 사용될 수 있다. 프로세스는 단계(901)에서 토너먼트 생성자 또는 운영자(상기한 바와 같이, 게임 개발자, 플레이어, 기타 등등이 될 수 있음)가 먼저 토너먼트의 파라미터를 정의하는 것으로 시작한다. 이 파라미터는 상기한 것들과 유사할 수 있지만, 기타 파라미터들도 사용될 수 있다. 예를 들어, 토너먼트는 우승자가 진출하고 패배자는 탈락하는 탈락 대진표 구조(elimination bracket structure)를 사용할 수 있으며, 이러한 토너먼트는 최종의 챔피언쉽 게임에 등장하는 등장할 참가자의 수 및 이전-라운드 게임으로부터 진출하는 우승자의 수를 식별해주는 별도의 파라미터를 포함할 수 있다. 토너먼트 파라미터는 또한 사용될 토너먼트 레벨의 수를 식별해줄 수 있다. 예를 들어, 토너먼트는 가장 높은, 두번째로 높은, 및 세번째로 높은 순위 그룹의 플레이어들이 서로 경쟁할 수 있게 해주기 위해 3개의 레벨(예를 들어, "골드(Gold)", "실버(Silver)", 및 "브론즈(Bronze)")을 갖는 것으로 정의될 수 있다. 이들 레벨 각각은 토너먼트의 개개의 인스턴스로서 역할 수 있으며, 서로 다른 역량의 플레이어들이 그 자신의 토너먼트에서 경쟁할 수 있게 해준다. 예를 들어, 예선이 완료되고 참가자들이 그들의 예선에 기초하여 순위 지정된 그룹들로 분할된 후에 개별적인 인스턴스가 시작될 수 있다.

토너먼트는 또한 개막 시간/날짜 및 기간 등의 예선 라운드(들)에 대한 스케 쥴링 정보를 포함할 수 있다. 토너먼트는 또한 참가자들을 예선을 거치게 하는 데 사용될 도전의 유형을 기술하는 Challenge Definition(도전 정의) 파라미터를 포함할 수 있다. Challenge Definition 데이터 구조는 일반적으로 플레이어가 토너먼트의 예선을 통과하기 위해 달성해야만 하는 위업의 유형을 나타낼 수 있으며, 게임에 따라 다를 수 있다. Challenge Definition은 장소 설정(예를 들어, 레이싱 게임에 대한 레이스 트랙, 전쟁 게임에 대한 전쟁터 지도, 게임 레벨 또는 스테이지, 기타), 난이도 설정(예를 들어, 쉬움, 중간, 어려움, 기타), 게임 조건(레이스를 위한 자동차의 유형, 지도 상에서 이용가능한 무기, 날씨 설정), 기타 등등의 예선에서 치르는 도전에 대한 하나 이상의 게임 설정을 지정할 수 있다. Challenge Definition는 단지 하나의 이벤트로 제한되지 않는다. 그 대신에, 이 정의는 서로 다른 조건을 갖는 서로 다른 레이스 또는 스테이지의 시퀀스 등의 순서 리스트(ordered list)에 다수의 예선 이벤트를 지정할 수 있다.

어떤 게임의 경우, Challenge Definition는 도전에 참가하기 위해 콘솔 상에 게임 타이틀 프로그램을 자동적으로 구성하기 위해 게임 콘솔(402)로 다운로드될 수 있는 데이터 파일을 포함할 수 있다. 예를 들어, 레이스 게임의 Challenge Definition 파라미터가 맑은 날에 Laguna Seca 레이스 트랙에서 200마력을 넘지 않는 후륜 구동 자동차를 사용하여 레이스 게임의 "중간" 난이도 설정에 설정된 5대의 컴퓨터-제어(AI) 상대자와 4-바퀴 레이스(4-lap race)가 실행되어야만 함을 요구하는 경우, 토너먼트의 서버는, 플레이어의 콘솔에 다운로드될 때, 다운로드 파일에 지정된 유형의 레이스를 실행하도록 콘솔 상에서 실행 중인 게임을 자동적으 로 구성하는 토너먼트 도전 다운로드 파일(tournament challenge download file)을 포함할 수 있다. 다운로드 파일은 또한 플레이어의 자동차 선택을 Challenge Definition에 의해 허용된 것으로 제한하기 위해, 콘솔(402) 상에서 실행 중인 게임에 의해 사용될 수 있다.

토너먼트 파라미터가 정의되면, 토너먼트의 서버는 토너먼트를 처리할 프로세스를 실행하기 시작할 수 있다. 프로세스는 플레이어의 예선 결과를 보유하기 위해 사용될 리더보드 데이터 구조에 대한 저장 장치를 할당할 수 있고(또는 다른 방식으로 예비할 수 있고), 리더보드의 ID는 단계(901)에서 정의된 파라미터들 중 하나일 수 있다. 리더보드 ID는 데이터 구조에 대한 이름 또는 핸들, 및 그 데이터 구조가 어디에 저장되어 있는지 또한 어떻게 검색될 수 있는지를 나타내는 메모리 주소 장소(memory address location)를 포함할 수 있다. 리더보드 ID는 득점 중재(scoring arbitration)를 위해 사용될 수 있다.

단계(901)에서 토너먼트 파라미터가 설정되었으면, 컴퓨터 프로세스는 이어서 단계(902)에서 플레이어들에게 토너먼트를 발표할 수 있다. 이 발표는 e-메일, SMS, 기타 등등의 전자 통신을 통해 행해질 수 있고, 전자 메시지를 게임 콘솔(402)로 전송하는 것을 포함할 수 있다. 발표는 또한 텔레비전 광고, 라디오, 전화, 잡지, 기타 등등의 다른 형태의 통신을 사용하여 행해질 수도 있다. 발표는 플레이어들에게 토너먼트의 파라미터, 토너먼트 예선을 통과하기 위해 달성되어야만 하는 도전의 유형(예를 들어, Challenge Definition), 및 예선 기간에 대한 시간(예를 들어, 시작 시간 및 종료 시간)을 알려준다.

단계(901)에서의 발표 후에, 토너먼트 파라미터에 예정된 시간이 설정되어 있다면 그 시간에(또는 시간이 예정되어 있지 않은 경우, 즉각), 프로세스는 단계(903)에서 예선 기간을 시작한다. 이 기간 동안, 플레이어들은, 이용가능하다면, Challenge Definition 구성 파일을 다운로드할 수 있고, 필수 도전(requisite challenge)을 플레이어할 수 있다(예를 들어, 지정된 레이스를 할 수 있다). 게임 콘솔(402)은 플레이어의 진척 및 성과(예를 들어, 레이스 시간)를 기록할 수 있고, 토너먼트의 리더보드에 포함시키기 위해 보안 전송을 통해 점수를 다시 토너먼트의 서버[토너먼트 서버(434) 등]로 보고할 수 있다. 상기한 보안 전송 검사에 부가하여, 이 보고된 점수는 또한 부정한 점수가 게시되는 것을 방지하는 데 도움을 주기 위해 검증 프로세스도 거칠 수 있다. 이 검증 프로세스는 보고된 점수를 미리 정해진 점수 한계 또는 최대 예상 점수(상기 정의된 부가의 토너먼트 파라미터일 수 있음) 또는 다른 게임 콘솔에 의해 보고된 결과와 비교하는 것을 포함할 수 있다.

플레이어의 점수를 수신한 후에, 또는 플레이어의 요청에 응답하여, 서버는 플레이어의 결과 및 다른 플레이어들의 예선 점수에 기초하여 토너먼트 순위를 결정하기 위해 리더보드에 질의를 할 수 있다. 서버는 플레이어에게 그의 성적이 얼마나 좋은지를 알려주는 메시지(예를 들어, "이 도전에 대해 75번째로 빠른 시간을 로그하였습니다")를 플레이어에게 전송할 수 있다. 이 메시지는 또한 플레이어가 어떤 자격이 있는지에 관하여 플레이어에게 알려줄 수 있다(예를 들어, "당신의 점수는 골드 레벨 토너먼트에 대한 자격이 있습니다" 또는 "당신의 점수는 10번째 씨드를 받을 자격이 있습니다"). 플레이어가 원하는 경우, 플레이어는, 그의 위치를 향상시키고자 희망하여, 예선 이벤트를 다시 시도할 수 있으며 다른 점수를 게시할 수 있다. 중복적인 점수를 피하기 위해, 서버는 점수를 게시하는 플레이어의 ID(예를 들어, 로그인 ID)(예를 들어, 점수와 함께 전송됨)를 획득할 수 있고 그 플레이어가 이전에 예선 점수를 게시하였는지를 알아보기 위해 검사를 할 수 있다. 그 플레이어가 이전에 점수를 게시한 경우, 서버 프로세스는 자동적으로 이전의 점수를 새 점수로 교체할 수 있거나, 새 점수가 이전의 점수보다 더 높은 순위로 되는 경우에 또는 사용자가 새 점수를 전송할 때 이전의 점수를 새 점수로 교체하도록 요청한 경우에만 그렇게 할 수도 있다. 다른 대안으로서, 플레이어는 예선 점수를 게시할 무한의 기회를 제공받을 필요가 없다. 예를 들어, 토너먼트는 각각의 사용자를 단지 하나의 예선 엔트리로 또는 제한된 미리 정해진 수의 예선 엔트리로 제한할 수 있다. 플레이어는 게임 세션 점수를 게시하는 대신에 이를 무시(예를 들어, 이를 연습 라운드로 취급)할 기회를 제공받을 수 있다. 그에 부가하여, 시스템은 부가적인 예선 시기(試技)(qualification attempt)를 구입할 옵션을 사용자에게 디스플레이할 수 있고, 사용자는 더 높은 예선 점수를 게시하려고 또한번 시도하는 비용을 미리 정해진 계정(예를 들어, 신용 카드 계정, 또는 가입 계정)으로 결제할 수 있다.

예선 기간 동안에 점점 더 많은 플레이어가 예선을 통과함에 따라, 많은 플레이어들은 순위가 아래로 내려갈 수 있다. 토너먼트 서버 프로세스는, 플레이어의 순위가 변할 때 또는 플레이어의 순위가 미리 정해진 양(예를 들어, 순위수, 참가자들의 퍼센트, 기타)만큼 변하는 경우 또는 플레이어의 순위가 특정의 토너먼트 인스턴스의 예선을 통과하지 못하고 탈락하는 경우(예를 들어, 이전의 자격이 "골드" 토너먼트 예선을 통과하는 데 사용되었지만 이제는 단지 "실버" 토너먼트 예선을 통과하는 경우), 이러한 플레이어에게 자동적으로 통지를 할 수 있다. 이 통지는 발표와 유사한 임의의 통신일 수 있으며, 플레이어의 콘솔(402)로 전송되는 전자 메시지일 수 있다. 이 메시지는 게임 프로그램의 사용자 인터페이스를 사용하여 디스플레이되는, 플레이어의 콘솔 상에 게임내 통신으로서 나타날 수 있다. 컴퓨터에의 이메일 등의 기타 통지들도 사용될 수 있다. 통지의 실제 유형 및 통지가 전송되는 조건은 부가의 토너먼트 파라미터로서 지정될 수 있다.

예선이 완료된 경우, 토너먼트 서버는 단계(904)에서 리더보드 데이터 구조를 조회할 수 있고, 게시된 결과를 예선 통과 요건과 비교함으로써 몇명의 플레이어가 실제로 토너먼트 예선을 통과했는지를 판정할 수 있다. 예선 통과 요건은 토너먼트 파라미터에 지정되어 있거나 그로부터 도출될 수 있다. 이러한 도출의 예는, 토너먼트의 한 인스턴스에 참가할 수 있는 총 플레이어 수(P_T)를 계산하기 위해, 게임당 원하는 플레이어 수(P), 결승 게임에 있을 플레이어 수(P_F), 각각의 게임으로부터 진출해야만 하는 우승자 수(W)(예를 들어, 2명, 3명, 4명, 기타 등등의 플레이어가 각각의 게임으로부터 진출함), 및 원하는 라운드 수(R) 등의, 입력된 토너먼트 파라미터에 기초한 계산을 사용할 수 있다.

어느 플레이어가 예선을 통과하는지를 판정하기 위해, 토너먼트 프로세스는 상기 계산을 수행할 수 있고, 이어서 상위 P_T명의 플레이어를 토너먼트 예선을 통과한 것으로 받아들이기 위해 리더보드를 조회할 수 있다. 물론, 이 계산은, 토너먼트 정의 단계(901) 및/또는 예선 기간(903)에서와 같이, 더 일찍 수행될 수도 있다. (예를 들어, 토너먼트 파라미터로 나타낸 바와 같이) 다수의 토너먼트 인스턴스가 지원되는 경우, 토너먼트 프로세스는 리더보드에서의 그 다음 P_T명의 엔트리를 그 다음 토너먼트의 예선을 통과한 것으로서 받아들일 수 있으며, 전체 토너먼트 인스턴스가 채워질 때까지 또는 리더보드에 미배정된 엔트리가 더 이상 없을 때까지 이하 마찬가지로 행해진다. 이와 같이, 토너먼트 프로세스는 예선 통과자(또는 엔트리)를 다양한 토너먼트 레벨로 나눈다.

상기 예시적인 계산은 토너먼트마다의 총 플레이어 수를 결정하는 것에 한정되지 않는다. 그 대신에, 다른 제공된 변수들에 기초하여 변수들 중 임의의 하나가 계산될 수 있다. 따라서, 예를 들어, 토너먼트 운영자가 라운드 수(R)를 미정인 채로 두기로 결정한 경우, 나머지 값들에 기초하여 그 값을 계산하기 위해 상기 식이 재배열될 수 있다(예를 들어, 모든 플레이어에 대해 토너먼트를 하고 지정된 게임당 플레이어 및 게임당 우승자 값을 만족시키는 데 필요한 수만큼의 라운드를 수행함). 그에 부가하여, 어떤 수 또는 퍼센트의 게시된 점수들이 토너먼트 예산을 통과해야만 하도록 하기 위해 토너먼트 채움 비율(tournament fill ratio)이 파라미터(예를 들어, 20%)에 정의될 수 있다. 예선 기간이 종료되고 토너먼트 프로 세스가 수신된 전체 엔트리 수를 결정하기 위해 리더보드를 조회할 수 있을 때, 프로세스는 엔트리 중 몇개(예를 들어, 20%)가 토너먼트에 있게 될지를 결정할 수 있고(예를 들어, 비율이 20%이고 100개 엔트리가 수신된 경우 P_T = 20임) 이어서 채움 비율에 대응하기 위해 나머지 값들(예를 들어, R, P, 기타)을 조정할 수 있다.

단계(905)에서, 토너먼트 프로세스는 이어서 (있는 경우) 계산된 값들 및 토너먼트 파라미터에 설정된 임의의 스케쥴 파라미터에 기초하여, 다양한 토너먼트(들) 및 토너먼트 라운드(들)를 스케쥴링할 수 있다. 이 프로세스는 또한 단계(906)에서 탈락 토너먼트(elimination tournament)에서 토너먼트 대진표를 채우기 위해 씨드 배정(seeding)을 수행할 수 있다. 이러한 씨드 배정은 매라운드마다 비슷한 기량의 플레이어들이 서로 플레이하게 하기 위해 상기한 그룹화 방법을 사용하여 동적으로 행해질 수 있거나(예를 들어, 상위 X명의 플레이어가 한 게임에서 플레이하고, 그 다음 X명의 플레이어가 다른 게임에서 플레이하며, 이하 마찬가지로 행해지고, 씨드 배정은 각각의 라운드 후에 가능한 늦게 행해짐), 상위-씨드를 배정받은 플레이어가 나중의 또는 결승 라운드때까지 다른 상위-씨드 플레이어와 대전하지 않도록 씨드 배정이 행해질 수 있다. 이것은 일반적으로 챔피언쉽 게임을 시작하고, 결승 대전(final match)을 채우는 데 필요한 준결승 대전(semifinal match)의 수를 결정하며, 모든 라운드가 정의될 때까지 준결승 대전에 대해 동일한 분석을 반복하여 수행함으로써 행해질 수 있다. 대전의 라운드가 정의되면, 씨드 배정 프로세스는 개막 대전에서 개막 대전으로 진행하여, 숫자상 예상된 우승자를 채우기에 충분한 상위 씨드의 플레이어를 배치하고, 이어서 나머지 대전을 하위 씨드 플레이어로 채운다. 이러한 종류의 씨드 배정은 정적으로 행해질 수 있으며, 이 경우에 플레이어들은 토너먼트 전체에 걸쳐 그의 씨드를 가지고 있으며 라운드 간에 씨드를 재배정받지 않는다. 부가의 대안으로서, 이러한 씨드 배정은 각각의 플레이 라운드 후에 새로 수행될 수 있으며, 이 경우 그 플레이어들만이 존재하고 플레이할 준비가 되어 있다(예를 들어, 토너먼트 인스턴스를 처리하는 서버에 체크인 했음). 따라서, 예를 들어, 다수의 플레이어가 제1 라운드 후에 그만두거나 탈락한 경우, 토너먼트는 놀고 있는 플레이어(예를 들어, 원래의 씨드 배정에 따른 그의 상대가 더 이상 플레이하고 있지 않는 플레이어)를 최소화하기 위해 제2 라운드에 대한 씨드를 재배정받을 수 있다.

도 10a는 토너먼트 서버가 도 10b에 도시된 프로세스를 따를 때 발생될 수 있는 정적으로 씨드 배정된 대진표의 일례를 나타낸 것이다. 도 10a의 대진표의 중간 라운드에 다양한 값들이 나타내어져 있지만, 도 10b의 최종 결과는 개막 라운드 대진표 대전(opening round bracket matchup), 전체적인 라운드 수, 및 대전의 배열(예를 들어, 어느 이전의 대전이 그의 경쟁자와의 나중의 대전을 제공하는가)을 식별하는 것이다. 도 10b에 도시된 바와 같이, 이 프로세스는 단계(1001)에서 결승 라운드를 고려하는 것으로 시작한다. 프로세스는 몇명의 경쟁자가 결승 라운드에 있게 될지를 결정하기 위해 토너먼트 파라미터를 조회할 수 있고, 결승 라운드를 채울 수 있다. 단계(1002)에서, 결승 라운드는 톱 씨드(top seed)로 채워질 수 있다. 도 10a의 예에서, 결승 라운드에 8명의 경쟁자가 있도록 정의되었으며, 따라서 8명의 톱 씨드 배정된 플레이어가 결승 라운드에 나타날 것으로 추정된다. 다시 말하면, 이것은 개막 라운드의 씨드를 배정하기 위한 가정에 불과한데, 그 이유는 톱 씨드를 받은 플레이어들이 결승 라운드까지 실제로 살아남아야만 하는 것은 아니기 때문이다.

이어서, 단계(1003)에서, 본 시스템은 현재 라운드(예를 들어, 결승 라운드)를 채우기 위해 이전 라운드(예를 들어, 준결승 라운드)에서 몇개의 이전의 피더 대전(feeder match)이 필요한지를 알아보기 위해 검사를 할 수 있다. 예를 들어, 결승 라운드가 8명의 플레이어를 필요로 하고 토너먼트 파라미터가 4명의 플레이어가 각각의 대전으로부터 진출하는 것으로 나타내는 경우, 이전 라운드(준결승 라운드)는 그 8명의 플레이어를 제공하기 위해 2번의 대전을 필요로 한다. 단계(1004)에서, 현재 라운드의 플레이어들은 이전 라운드에 필요한 다양한 대전에 걸쳐 분산되어 있다. 단계(1005)에서, 이전 라운드에서의 나머지 대전들은 그 다음으로 높은 이용가능한 씨드 배정된 플레이어로 채워진다.

단계(1006)에서, 토너먼트의 모든 참가자가 배치되었는지를 판정하기 위해 검사가 행해질 수 있다. 배치되지 않은 경우, 토너먼트에 또하나의 이전 라운드가 필요하게 된다. 그러면, 프로세스는, 단계(1007)에서, 그 다음으로 이전인 라운드로 관심을 옮기고, 단계(1003)로 되돌아가서 이전 라운드의 대전을 채우기 위해 동일한 단계들을 수행할 수 있다. 따라서, 예를 들어, 시스템은 단계(1007)에서 "현재 라운드"를 준결승 라운드로 설정할 수 있고, 단계(1003)으로 되돌아가서 그 다음으로 이전인 라운드(예를 들어, 준준결승 라운드)에 대한 대진표를 채우기 시작 할 수 있다. 이 프로세스는 모든 참가자가 배치될 때까지 계속될 수 있으며, 프로세스에 검토되는 마지막 라운드가 개막 라운드 씨드(opening round seeding)를 제공한다.

도 11은 결승 라운드에 6명의 플레이어가 나타나고 이전 라운드의 대전에서 9명의 플레이어가 플레이하며 각각의 이전 대전으로부터 3명의 플레이어가 진출하는 토너먼트의 다른 예를 나타낸 것이다. 가장 빠른 라운드들이 씨드 배정 프로세스의 최종 결과를 나타낸다.

다양한 토너먼트 인스턴스가 이어서 인스턴스화되고, 그들의 결과를 판정하기 위해 단계(907)에서 토너먼트(들)가 수행된다. 토너먼트의 실제 수행은 상기한 바와 같이 행해질 수 있으며, 동일한 또는 서로 다른 서버 상의 개별적인 컴퓨터 프로그램 프로세스들이 다양한 토너먼트 인스턴스를 운영하고, 게임 세션들이 콘솔에서 실행되어 서버로 보고되며, 득점 중재, 기타 등등이 있게 된다.

도 12는, 예를 들어, 도 8a 및 도 8b, 그리고 도 9에 도시된 유형의 토너먼트에 액세스하는 게임에서 사용될 수 있는 예시적인 사용자 인터페이스 지도(user interface map)를 나타낸 것이다. 콘솔의 메인 메뉴(1201)는, 토너먼트 페이지(tournaments page) 옵션을 비롯한 다수의 토너먼트 옵션들을 제공할 수 있다. 그 옵션을 선택한 것에 응답하여 디스플레이되는 토너먼트 페이지(1202)는 토너먼트 옵션들의 메뉴를 포함할 수 있다. 예를 들어, 토너먼트 메뉴(1202)는 플레이어가 이미 등록을 한 토너먼트의 리스트, 플레이어의 예선 순위, 참가자의 수, 토너먼트의 현재 상태(예를 들어, 등록자수, 예선, 라운드 X, 기타)를 디스플레이할 수 있다. 토너먼트 메뉴(1202)는 또한 열거된 토너먼트 중 하나를 입력하고 토너먼트를 찾아내며 토너먼트를 생성하기 위한 선택가능한 옵션들도 포함할 수 있다. 열거된 토너먼트 중 하나를 선택할 시에, 사용자는 선택된 토너먼트에 대한 토너먼트 로비 화면(tournament lobby screen)(1203)을 제공받을 수 있다.

토너먼트 로비 화면(1203)은, 현재 상태, 플레이어의 다음 상대, 상대의 상태, 기타 등등의, 선택된 토너먼트에 대한 부가 정보를 디스플레이할 수 있다. 토너먼트 로비 화면(1203)은 토너먼트에서 게임을 플레이하는 것, 토너먼트에서의 이전 대전에 대한 게임 이력을 보는 것, 기타 등등을 위한 부가의 메뉴 옵션들을 포함할 수 있다. 대응하는 메뉴 옵션을 선택할 시에, 게임 콘솔은 토너먼트에서의 라운드 또는 대전을 플레이하기 시작하기 위해 게임 플레이 화면(1204)을 디스플레이하거나 토너먼트에서의 플레이어의 이전 성적에 관한 정보를 디스플레이하기 위해 게임 이력 화면(game history screen)(1206)을 디스플레이할 수 있다. 이 정보는 플레이어, 상대(opponent), 팀, 기타 등등에 대한 통계를 포함할 수 있다. 이력 화면(1205)은 또한, 통계 서버(426) 상의 리더보드로부터의 데이터를 조사하는 등에 의해, 다수의 토너먼트 및 게임 유형에 걸쳐 플레이어 온라인 성적 전체를 디스플레이할 수 있다.

토너먼트 로비 화면(1203)은 또한 참가자 리스트 옵션도 포함할 수 있으며, 이를 선택하면 참가자 리스트(1206)를 디스플레이할 수 있다. 참가자 리스트 화면(1206)은 토너먼트의 참자가, 그 다음 라운드에서 플레이하기로 예정된 참가자, 이전 라운드에서 플레이한 참가자, 기타 등등에 관한 ID 및 통계적 정보를 디스플 레이할 수 있다.

대전 또는 라운드를 플레이한 후에, 시스템은 대전의 결과를 디스플레이하는 결과 보고 화면(report results screen)(1207)을 디스플레이할 수 있다. 이것은 이제 막 플레이된 대전에서의 플레이어들의 성적에 관한 통계를 포함할 수 있다.

토너먼트 메뉴(1202)로부터, 플레이어들은 토너먼트를 검색하는 옵션도 제공받을 수 있다. 이 옵션을 선택할 시에, 플레이어는, 하나 이상의 토너먼트 서버(434)에서 실행되는 것 또는 리더보드를 사용하는 것 등의, 사용자에게 온라인 시스템에서 토너먼트를 찾아내는 데 사용될 수 있는 기준을 입력 또는 선택하도록 하는 프롬프트를 포함할 수 있는 토너먼트 찾기 화면(find tournaments screen)을 볼 수 있다. 이 기준은 게임 타이틀, 토너먼트 이름, 게임 유형, 토너먼트 유형, 토너먼트 호스트, 또는 임의의 다른 원하는 검색 기준을 포함할 수 있다. 검색을 실행할 시에, 시스템은 이 사용자를 위해, 예선 상세(예를 들어, 사용자가 예선을 통과했는지, 참가자 예선 통과 점수, 기타 등등) 및 토너먼트가 언제 행해지기로 설정되었는지의 스케쥴을 나타내는 토너먼트의 리스트를 디스플레이할 수 있다.

토너먼트 메뉴(1202)는 또한 플레이어들이 새로운 토너먼트를 생성할 수 있게 해주는 옵션도 포함할 수 있다. 선택 시에, 사용자는 사용자에게 새로운 토너먼트를 정의하기 위한 기준을 요청할 수 있는 토너먼트 생성 화면(1209)를 볼 수 있다. 이 기준은 토너먼트 파라미터, 게임 타이틀, 기타 등등의 상기한 특징들 중 어느 것이라도 포함할 수 있다. 하나 이상의 부가의 게임 설정 화면(1210)도 역시 이를 위해 사용될 수 있다.

토너먼트 메뉴(1202)는 또한 리더보드 예선 토너먼트(leaderboard qualified tournament) 옵션을 포함할 수 있으며, 이 옵션을 선택하면 리더보드 화면(1211)를 디스플레이할 수 있다. 리더보드 화면(1211)은 리더보드 토너먼트를 열거할 수 있으며, 이름, ID, 현재 상태, 현재의 도전, 도전/예선 기간, 기타 등등의 리더보드 예선 토너먼트에 관한 부가의 데이터를 포함할 수 있다. 리더보드 화면(1211)은 특정의 디스플레이된 토너먼트에 대한 예선에 관한 부가의 설명 및 상세를 디스플레이하는 옵션을 포함할 수 있다. 예선 상세 화면(1212)은 플레이어가 어떻게 예선을 통과할 수 있는지를 설명하는 부가의 설명(예를 들어, "301마력 미만의 4WD 자동차를 사용하여 Laguna Seca 레이스 트랙을 질주하고 골드 레벨 토너먼트의 예선을 통과하기 위해 상위 150 횟수 중 하나를 게시하시오")을 포함할 수 있다. 사용자는 예선 시기(試技)(qualifying attempt)를 하기로 선택할 수 있으며, 그 결과 게임 화면(1213)이 나타나고, 그 시기(試技) 이후에, 사용자는 플레이어의 예선 시기에 관한 정보를 디스플레이하는 결과 보고 화면(1214)를 볼 수 있다. 결과 화면(1214)은 또한 플레이어의 결과 점수의 순위가 플레이어들 중에서 몇번째인지를 보여주는 리더보드로부터 검색된 정보, 및 플레이어가 토너먼트의 예선을 통과했는지를 알려주는 정보를 디스플레이할 수 있다.

리더보드 화면(1211)에서 열거된 토너먼트를 선택할 시에, 콘솔은 토너먼트에 대한 탈락 상세 화면(1215)을 디스플레이할 수 있다. 탈락 상세 화면(1215)은 토너먼트 상태, 플레이어의 순위/랭킹, 및 플레이어가 여전히 토너먼트 중인 경우, 토너먼트에 대한 그 다음 예정된 게임을 열거할 수 있다. 플레이어가 그 다음 라 운드를 시작할 준비가 되어 있을 때, 플레이어는 상세 화면(1215)으로부터 대응하는 옵션을 선택하고 토너먼트 로비(1216)에 들어가서 플레이어는 그 다음 라운드에 대한 상대의 입장을 기다릴 수 있다. 로비(1216)로부터, 플레이어는 토너먼트에 대한 대진표(1217), 게임 설정 및 파라미터(1218), 또는 플레이어, 그의 팀원, 친구, 토너먼트에서의 기타 경쟁자, 및 만나게 될 상대에 관한 통계(1219)를 보기로 할 수 있다.

플레이어의 상대가 체크인 한 경우 및 양 플레이어 모두가 준비된 경우, 플레이어는 대전을 플레이하기 위해 게임 화면(1220)을 볼 수 있고, 대전의 결과를 보여주는 게임후 결과 화면(post-game results screen)(1221)을 볼 수 있다(이에 대해서는 상기하였음).

상기한 여러가지 특징들은 여러가지 개념들의 예시적인 구현에 불과하며, 원하는 바에 따라 수정이 가능하다. 예를 들어, 이상에서 플레이어에 대한 언급은 한명의 사람을 말할 수 있거나, 그들의 게임을 함께 플레이하는 한 팀의 사람들을 말할 수 있다. 어떤 토너먼트는 다양한 플레이어가 팀으로서 (예를 들어, 단일의 레이스에) 함께 참가할 수 있게 해주는 것에 의해 팀 또는 단체(clan)를 지원할 수 있다. 팀원들에 대한 점수는 순위 비교를 위해 취합될 수 있다.

다른 가능한 수정은 토너먼트 참가자들에 대한 탈락(dropout) 및 출전하지 않음(no-show)을 처리한다. 플레이어가 등록 및/또는 예선 통과에 의해 토너먼트에 참가하지만 토너먼트를 완료하지 못하는 경우(예를 들어, 시작한 후에 탈락하거나 예정된 시간에 출전하지 않는 것), 그 플레이어는 0점을 누적하거나 패배한 것 처럼 처리될 수 있다.

다른 가능한 수정으로서, 도 12에 도시된 다양한 화면 및 본 명세서에 기술된 특징들이 로컬의 비네트워크화된 플레이에 대해서도 사용될 수 있다. 예를 들어, 멀티플레이어 토너먼트가 단일의 콘솔에 의해 호스팅될 수 있으며, 다양한 특징들이 그 콘솔에 의해 구현될 수 있다.

상기한 특징들은 양호하게는 퍼스널 컴퓨터 또는 비디오 게임 콘솔 등의 컴퓨팅 장치 상에서 실행되어, 도면에 도시된 화면들을 디스플레이할 수 있는 실행가능 명령어로서 컴퓨터 소프트웨어에 인코딩된다. 이 실행가능 명령어는 하나 이상의 컴퓨터 디스크, RAM, CD-ROM, DVD, 게임 카트리지, 기타 등등의 컴퓨터 판독가능 매체 상에 저장될 수 있다. 또한, 다양한 특징들이 전술되어 있지만, 이들 모두가 동일한 실시예에서 실시될 필요가 없다. 그 대신에, 원하는 바에 따라 다양한 컴비네이션 및 서브컴비네이션이 구현될 수 있으며, 본 발명의 진정한 범위는 이하의 청구 범위에 의해서만 제한되어야 한다.

비록 본 발명이 구조적 특징 및/또는 방법적 동작과 관련하여 기술되어 있지만, 첨부된 청구항들에 정의된 본 발명이 꼭 상기한 특정의 특징 또는 동작으로 제한될 필요가 없다는 것을 잘 알 것이다. 오히려, 상기한 특정의 특징 및 동작은 청구항들을 구현하는 예시적인 형태로서 개시된 것이다.

Claims (20)

1. 게임 콘솔 토너먼트 방법으로서,

   토너먼트 운영자로부터 로그인 요청을 수신하는 단계(601), 및

   상기 토너먼트 운영자에게 하나 이상의 토너먼트 파라미터를 입력(602)하도록 프롬프트하는 단계 - 상기 파라미터는 상기 토너먼트의 복수의 인스턴스를 인스턴스화(604)하기 위한 스케쥴 기준을 포함함 - 를 포함하며,

   각각의 인스턴스는,

   a) 상기 토너먼트에서의 복수의 라운드에 대한 게임 세션 기준을 설정하기 위해 토너먼트 참가자들의 복수의 원격 게임 콘솔(402)과 통신을 하고,

   b) 공통의 멀티플레이어 온라인 게임 세션에 참가하는 복수의 게임 콘솔로부터 게임 세션 결과를 수신하며(606),

   c) 복수의 게임 세션의 결과에 기초하여 토너먼트 우승자를 결정(611)하는 것인, 게임 콘솔 토너먼트 방법.
2. 제1항에 있어서, 상기 로그인 요청은 게임 콘솔(402)로부터 수신되는 것인, 게임 콘솔 토너먼트 방법.
3. 제1항에 있어서, 상기 결정하는 단계는 상기 게임 세션에 참가한 제1 콘솔로부터 수신된 게임 세션 결과를 상기 게임 세션에 참가한 제2 콘솔로부터 수신된 결 과와 비교하는 단계(607)를 더 포함하는 것인, 게임 콘솔 토너먼트 방법.
4. 제3항에 있어서, 상기 비교하는 단계가 상기 비교된 결과들 간의 모순을 확인하는 경우, 상기 방법은 이 모순을 해결하기 위해 중재를 수행하는 단계(608)를 더 포함하는 것인, 게임 콘솔 토너먼트 방법.
5. 제4항에 있어서, 상기 중재 단계는 리더보드 데이터 구조에 질의를 하는 단계(608)를 포함하고,

   상기 리더보드 데이터 구조는 보안 전송을 통해 상기 복수의 게임 콘솔로부터 게임 세션 결과를 수신하는 것인, 게임 콘솔 토너먼트 방법.
6. 제1항에 있어서, 상기 토너먼트의 제1 인스턴스의 완료 시에 상기 스케쥴 기준에 의해 상기 토너먼트의 제2 인스턴스의 자동 인스턴스화(automatic instantiation)(603)가 일어나는 것인, 게임 콘솔 토너먼트 방법.
7. 제1항에 있어서, 상기 토너먼트 파라미터는 2명의 토너먼트 참가자가 상기 공통의 멀티플레이어 온라인 게임 세션을 함께 한 후에 제2 게임 세션을 위해 함께 그룹화될 수 있기 이전에 경과해야만 하는 최소 시간을 식별해주는 윈도우 인자(window factor)를 더 포함하는 것인, 게임 콘솔 토너먼트 방법.
8. 제1항에 있어서, 상기 토너먼트 파라미터는 상기 토너먼트에서의 게임 세션을 위해 그룹화될 플레이어들 간의 순위 근접성(proximity in rank)을 식별해주는 순위차(rank gap)를 더 포함하는 것인, 게임 콘솔 토너먼트 방법.
9. 제1항에 있어서, 상기 토너먼트의 적어도 하나의 라운드가 완료된 후에 상기 토너먼트의 인스턴스에 대한 새로운 플레이어 등록을 받고 상기 새로운 플레이어를 상기 토너먼트의 후속하는 라운드들에 포함시키는 단계를 더 포함하는 것인, 게임 콘솔 토너먼트 방법.
10. 제9항에 있어서, 상기 파라미터는 새로운 플레이어 인자(new player factor)를 포함하고,

    상기 방법은 상기 새로운 플레이어 인자를 사용하여 상기 토너먼트의 상기 후속하는 라운드들 중 하나 이상에서 상기 새로운 플레이어의 점수를 조정하는 단계를 포함하는 것인, 게임 콘솔 토너먼트 방법.
11. 제10항에 있어서, 상기 새로운 플레이어 인자는 상기 새로운 플레이어가 상기 토너먼트의 더 많은 라운드에 참여함에 따라 변하며,

    상기 새로운 플레이어 인자는 상기 새로운 플레이어가 상기 토너먼트 파라미터에 지정된 최소값을 넘는 수의 라운드에 참가한 후에는 상기 새로운 플레이어에 대해 더 이상 사용되지 않는 것인, 게임 콘솔 토너먼트 방법.
12. 제1항에 있어서, 토너먼트 설정 데이터를 참가자의 게임 콘솔로 다운로드하고 상기 토너먼트의 파라미터에 따라 게임 세션을 플레이하도록 상기 게임 콘솔을 자동적으로 구성하는 단계를 더 포함하는, 게임 콘솔 토너먼트 방법.
13. 제1항에 있어서, 상기 토너먼트 파라미터는 상기 토너먼트에 대한 예선 기간(903) 및 하나 이상의 예선 기준을 정의하고,

    상기 방법은 상기 예선 기간 동안에 게임 콘솔들로부터 복수의 점수 보고를 받고 어느 점수가 상기 토너먼트의 예선을 통과하는지를 식별하는 단계를 더 포함하는 것인, 게임 콘솔 토너먼트 방법.
14. 제13항에 있어서, 이미 예선을 통과한 참가자들의 예선 상태가 차후에 예선을 통과한 참가자들로 인해 변경될 때 이미 예선을 통과한 참가자들에게 자동적으로 통지를 하는 단계를 더 포함하는, 게임 콘솔 토너먼트 방법.
15. 제14항에 있어서, 상기 통지를 받은 참가자들에게 상기 변경된 상태에 응답하여 예선 시기(試技)(qualification attempt)를 재시도할 기회를 제공하는 단계를 더 포함하는, 게임 콘솔 토너먼트 방법.
16. 제14항에 있어서, 상기 토너먼트의 제1 레벨 인스턴스에 제1 복수의 예선 통 과 점수를 할당하고 상기 토너먼트의 제2 레벨 인스턴스에 제2 복수의 예선 통과 점수를 할당하는 단계(904)를 더 포함하며,

    상기 제1 복수의 점수는 상기 제2 복수의 점수보다 상위 순위를 갖는 것인, 게임 콘솔 토너먼트 방법.
17. 제1항에 있어서, 상기 토너먼트 파라미터들을 토너먼트 설정 파일에 저장하는 단계를 더 포함하며,

    상기 파일은 상기 토너먼트에서의 복수의 라운드에 대한 서로 다른 게임 세션 파라미터들을 포함하는 것인, 게임 콘솔 토너먼트 방법.
18. 토너먼트 방법으로서,

    토너먼트 참가자들의 복수의 게임 콘솔(402)로부터 토너먼트 등록을 수신하는 단계,

    상기 복수의 등록된 참가자들의 순위를 지정하는 단계(802),

    상기 토너먼트의 제1 라운드에서의 게임 세션에 참가하기 위해 상기 순위 지정된 참가자들의 서브셋을 순차적으로 그룹화하는 단계,

    상기 제1 라운드에서의 성적에 기초하여 상기 참가자들의 순위를 재지정하는 단계, 및

    상기 토너먼트의 제2 라운드에서의 게임 세션에서 상기 순위 재지정된 참가자들의 서브셋을 순차적으로 그룹화하는 단계를 포함하며,

    참가자를 그룹에 추가할지 여부를 결정할 때, 상기 참가자가 게임 세션에서 상기 그룹의 임의의 구성원과 마지막으로 플레이한 이후 윈도우 인자의 시간이 경과했는지를 판정하기 위해 검사가 행해지는 것인, 토너먼트 방법.
19. 제18항에 있어서, 상기 윈도우 인자는 게임 세션의 수를 식별해주는 것인, 토너먼트 방법.
20. 리더보드 예선 토너먼트 방법(leaderboard qualified tournament method)으로서,

    게임 프로그램에 대한 도전 정의(challenge definition)를 게시하는 단계(902) - 상기 도전 정의는 토너먼트의 예선을 통과하기 위한 복수의 게임 세션 기준을 포함함 -,

    상기 토너먼트의 예선을 통과하려고 하는 플레이어들의 복수의 게임 콘솔로부터 게임 세션 결과를 수신하는 단계(903),

    상기 수신된 게임 세션 결과의 순위를 지정하고 플레이어들에게 그들의 현재 순위를 알려주는 단계,

    후속하는 플레이어 점수들의 결과로서 플레이어들의 이미 예선 통과한 점수가 예선 미통과 점수(non-qualifying score)가 될 때 플레이어들에게 게임내 통지를 전송하고 상기 통지를 받은 플레이어들이 예선 통과의 재시도를 할 수 있게 해주는 단계, 및

    상기 예선 기간을 종료시키고 상기 예선을 통과한 참가자들을 사용하여 상기 토너먼트를 수행하는 단계를 포함하는, 리더보드 예선 토너먼트 방법.

Images