KR20130009827A - 백업 통신 채널들을 설정 및 이용하기 위한 장치 및 방법 - Google Patents

Abstract

피어-투-피어("P2P") 네트워크에서 백업 채널들을 설정, 유지 및 이용하기 위한 장치, 방법 및 머신-판독가능한 매체가 기술된다. 예를 들어, 일 실시예에서, 각각의 모바일 디바이스는 하나 이상의 다른 모바일 디바이스들과의 프라이머리 P2P 통신 채널을 설정할 수 있다. 프라이머리 채널이 설정되면, 각각의 모바일 디바이스는 세컨더리 채널 통신 데이터를 교환하기 위해 프라이머리 채널을 사용할 수 있고, 후속적으로 다른 모바일 디바이스들과의 하나 이상의 세컨더리 P2P 통신 채널들을 개방할 수 있다. 프라이머리 P2P 통신 채널이 실패했거나 특정 임계(예를 들어, 대역폭 또는 비트레이트 임계) 미만으로 저하되었음을 검출하면, 세컨더리 P2P 채널들 중 하나는 프라이머리 P2P 통신 채널로 자동으로 승격될 수 있다.

Description

백업 통신 채널들을 설정 및 이용하기 위한 장치 및 방법{APPARATUS AND METHOD FOR ESTABLISHING AND UTILIZING BACKUP COMMUNICATION CHANNELS}

우선권 청구

이 출원은 "Apparatus and Method For Establishing and Utilizing Backup Communication Channels"라는 명칭으로 2010년 4월 7일에 출원된 미국 가출원 제61/321,841호의 우선권을 청구한다.

이 출원에서 개시되고 청구될 발명은 Apple의 iPhone 4의 프로토타입이 2010년 3월 25일에 Apple 엔지니어로부터 명백하게 도용당했을 때 Apple의 허가 없이 미리 공중에 공개되었다. 이 출원에 기초한 미국 우선 출원은 명백한 도용 이전에 출원되지 않았다.

본 발명은 일반적으로 컴퓨터 네트워킹의 분야에 관한 것이다. 더 구체적으로, 발명은 모바일 디바이스들에 대한 백업 통신 채널들을 설정 및 이용하기 위한 개선된 장치 및 방법에 관한 것이다.

A. 네트워크 어드레스 변환(" NAT ")

인터넷과 같은 큰 공중 네트워크들은 회사, 인터넷 서비스 제공자, 또는 심지어 개별 가구들에 의해 유지되는 것과 같은 더 작은 개인 네트워크들에 대한 접속들을 빈번하게 가진다. 이들의 바로 그러한 속성에 의해, 공중 네트워크들은 네트워크 어드레스들, 즉, 공중 어드레스들의 공통으로 합의된 할당을 가져야 한다. 다양한 이유들로 인해, 개인 네트워크들의 유지자들은 종종 공통으로 합의된 할당의 일부분이 아닌 개인 네트워크들에 대한 개인 네트워크 어드레스들을 사용하도록 선택한다. 따라서, 공중 네트워크를 횡단할 수 있는 개인 네트워크로부터의 네트워크 트래픽에 대해, 일부 형태의 개인/공중 네트워크 어드레스 변환("NAT")이 요구된다.

NAT 동작들을 수행하는 디바이스는 공중 네트워크의 어드레스지정 방식에 따르도록 개인 네트워크 밖으로 송신되는 데이터 패킷들을 변경한다. 특히, 네트워크 어드레스 변환기는 패킷의 발신 개인 어드레스 및 포트 번호를 자신의 고유한 공중 어드레스 및 할당된 포트 번호로 대체한다. 네트워크 어드레스 변환기는 또한 목적지 공중 어드레스 및 포트 번호를 의도된 수신자의 정확한 개인 어드레스 및 포트 번호로 대체하기 위해 개인 네트워크 상에서 컴퓨터들에 대해 수신된 데이터 패킷들을 변경한다. 여기서 사용된 바와 같이, 용어 어드레스는 당업자에 의해 이해될 바와 같이, 상황상 적절한 경우 어드레스 및 포트 번호 모두를 포함하도록 해석되어야 한다.

NAT는 현대 네트워크 컴퓨팅에서 점점 일반화되어 가고 있다. NAT의 일 장점은 그것이 공중 네트워크 어드레스 공간의 고갈을 늦춘다는 점이다. 예를 들어, 인터넷 상에서 사용되는 TCP/IP 어드레싱은 각각 3개 디지트들의 4개 스트링들을 포함하며, 따라서, 유한 어드레스 공간을 제공한다. 추가로, 이러한 어드레스 공간의 특정 부분들은 특정 사용들 또는 사용자들에 대해 예약되어, 사용가능한 실제 개수의 어드레스들을 추가로 고갈시킨다. 그러나, NAT가 사용되는 경우, 개인 네트워크 또는 서브넷은 임의의 개수의 어드레스들을 사용할 수 있고, 외부 세계에 대해 여전히 단일의 표준화된 공중 어드레스만을 제시할 수 있다. 이는 각각의 개인 네트워크가 이론적으로 정확히 동일한 개수의 개인 어드레스들을 사용할 수 있으므로, 사용가능한 어드레스들의 개수가 실제로 무제한이 되게 한다.

NAT에 의해 제공되는 일 장점은 공중 네트워크 상의 항목들이 개인 네트워크 상의 컴퓨터의 실제(즉, 개인) 네트워크 어드레스를 결정할 수 없다는 사실로 인해 발생하는 증가된 보안이다. 이는 오직 공중 어드레스만이 네트워크 어드레스 변환기에 의해 공중 네트워크 상에 제공되기 때문이다. 추가로, 이러한 공중 어드레스는 개인 네트워크 상의 임의의 개수의 컴퓨터들에 대응할 수 있다.

상이한 NAT 타입들은 상이한 보안 레벨들을 사용한다. 예를 들어, "풀 콘 NAT"를 이용하여, 내부 어드레스(iAddr:iPort)가 외부 어드레스(eAddr:ePort)에 매핑되면, 임의의 외부 호스트는 eAddr:ePort에 패킷들을 송신함으로써 iAddr:iPort에 패킷들을 송신할 수 있다. "제한된 콘 NAT"를 이용하여, 어드레스 hAddr를 가지는 외부 호스트는 iAddr:iPort가 이전에 hAddr에 패킷을 송신한 경우에만 eAddr:ePort에 패킷들을 송신함으로써 iAddr:iPort에 패킷들을 송신할 수 있다. 외부 호스트의 포트는 무관하다. "포트 제한된 콘 NAT"를 이용하여, 어드레스/포트 hAddr:hPort를 가지는 외부 호스트는 iAddr:iPort가 이전에 hAddr:hPort에 패킷을 송신한 경우에만 eAddr:ePort에 패킷들을 송신함으로써 iAddr:iPort에 패킷들을 송신할 수 있다. 마지막으로, 대칭 NAT를 이용하여, 동일한 iAddr:iPort로부터 특정 목적지 IP 어드레스 및 포트로의 각각의 요청은 고유 eAddr:ePort로 매핑된다. 동일한 내부 호스트가 상이한 목적지로 패킷을 송신하는 경우, 상이한 외부 어드레스 및 포트 매핑이 사용된다. 내부 호스트로부터 패킷을 수신하는 외부 호스트만이 내부 호스트로 다시 패킷을 송신할 수 있다.

B. 피어-투-피어 네트워킹을 이용한 NAT 발행들

피어-투-피어("P2P") 컴퓨팅은 자신의 자원들의 일부분을 직접 다른 네트워크 참여자들에 대해 사용가능하도록 만드는 컴퓨팅 노드들로 구성되는 분산 네트워크 아키텍처를 참조한다. P2P 네트워크에서의 피어들은, 서버들이 자원들을 공급하고 클라이언트들이 자원들을 소모하는 종래의 클라이언트-서버 모델에 비해, 서로 간에 직접 통신 채널들을 설정하고 클라이언트들 및 서버들 모두로서 동작한다.

전술된 NAT 동작들은 P2P 접속들에 대한 다수의 문제점들을 제기한다. 예를 들어, 2개 피어들 사이의 직접 통신의 설정은, 피어들 중 하나 또는 둘 모두가 전술된 NAT 타입들 중 하나 이상의 뒤에 위치되는 경우 더욱 더 어려워진다. 이러한 문제점은 Apple iPod Touch?, Apple iPhone?, Apple iPad?와 같은 모바일 디바이스들 및 다양한 다른 디바이스들(예를 들어, RIM Blackberry? 디바이스들, Palm Pre? 디바이스들 등)이 상이한 NAT 구현들을 가지는 네트워크들 사이에서 빈번하게 이동된다는 사실에 의해 악화된다. 예를 들어, Apple iPhone™은 Wi-Fi 네트워크들(예를 들어, 802.11b, g, n 네트워크들); 3G 네트워크들(예를 들어, 유니버셜 모바일 통신 시스템("UMTS") 네트워크들, 고속 업링크 패킷 액세스("HSUPA") 네트워크들 등); 및 블루투스 네트워크들(개인 영역 네트워크("PAN")들로서 공지됨) 상에서 통신할 수 있다. 향후 모바일 디바이스들은, 몇몇을 언급하자면, WiMAX, 국제 이동 통신("IMT") 어드밴스드, 및 롱 텀 에볼루션("LTE") 어드밴스드와 같은 추가적인 통신 채널들 상에서 통신할 수 있을 것이다.

피어-투-피어("P2P") 네트워크에서 백업 채널들을 설정, 유지 및 이용하기 위한 장치, 방법, 및 머신-판독가능한 매체가 기술된다. 예를 들어, 일 실시예에서, 각각의 모바일 디바이스는 하나 이상의 다른 모바일 디바이스들과의 프라이머리 P2P 통신 채널을 설정할 수 있다. 프라이머리 채널이 설정되면, 각각의 모바일 디바이스는 세컨더리 채널 통신 데이터를 교환하기 위해 프라이머리 채널을 사용할 수 있고, 후속적으로 다른 모바일 디바이스들과의 하나 이상의 세컨더리 P2P 통신 채널들을 개방할 수 있다. 프라이머리 P2P 통신 채널이 실패했거나 특정 임계(예를 들어, 대역폭 또는 비트레이트 임계) 미만으로 저하되었음을 검출하면, 세컨더리 P2P 채널들 중 하나는 프라이머리 P2P 통신 채널로 자동으로 승격될 수 있다.

본 발명의 더 양호한 이해는 후속하는 도면들과 함께 후속하는 상세한 설명으로부터 획득될 수 있다.

도 1은 네트워크 상에서 모바일 디바이스들 및 서비스들의 그룹이 통신하는 네트워크 아키텍처를 예시하는 도면이다.
도 2a-c는 접속 데이터 교환(CDX) 서비스, 매치메이커 서비스 및/또는 초대 서비스의 일 실시예 사이의 트랜잭션들을 예시하는 도면이다.
도 3은 티켓 데이터 구조의 일 실시예를 예시하는 도면이다.
도 4는 CDX 서비스에 의해 구현되는 방법의 일 실시예를 예시하는 도면이다.
도 5는 모바일 디바이스에 의해 구현되는 방법의 일 실시예를 예시하는 도면이다.
도 6은 프라이머리 및 세컨더리 통신 채널들을 통해 접속되는 모바일 디바이스들의 그룹을 예시하는 도면이다.
도 7은 프라이머리 및 세컨더리 통신 채널들 중에서 선택하기 위한 모바일 디바이스의 일 실시예를 예시하는 도면이다.
도 8a-b는 프라이머리 및 세컨더리 통신 채널들을 통해 접속되는 모바일 디바이스들의 그룹 및 결과적인 네트워크 토폴로지들을 예시하는 도면이다.
도 9는 프라이머리 및 세컨더리 통신 채널들 사이에서 선택하기 위한 컴퓨터-구현 방법의 일 실시예를 예시하는 도면이다.
도 10은 디렉토리 서비스 및 푸시 통지 서비스를 포함한, 모바일 디바이스들 및 서비스들의 그룹이 네트워크 상에서 통신하는 네트워크 아키텍처를 예시하는 도면이다.
도 11은 초대 서비스, 푸시 통지 서비스 및 접속 데이터 교환(CDX) 서비스의 일 실시예 사이에서의 트랜잭션들을 예시하는 도면이다.
도 12는 초대 서비스, 푸시 통지 서비스, 및 릴레이 서비스의 일 실시예 사이의 트랜잭션들을 예시하는 도면이다.
도 13은 2개 이상의 모바일 디바이스들 사이에 릴레이 접속을 설정하기 위한 릴레이 서비스의 일 실시예를 예시하는 도면이다.
도 14는 NAT 호환성을 결정하기 위한 NAT 호환성 차트의 일 실시예를 예시하는 도면이다.
도 15는 온라인 애플리케이션들에 대해 모바일 디바이스들을 매치시키기 위한 매치메이커 서비스의 일 실시예를 예시하는 도면이다.
도 16은 사용자들/디바이스들을 매치시키기 위한 방법의 일 실시예를 예시하는 도면이다.
도 17a-d는 사용자들/디바이스들을 매치시키기 위해 수행되는 예시적인 일련의 표 업데이트들을 예시하는 도면이다.
도 18은 상이한 매치 피트 변수들을 사용하여 사용자들/디바이스들을 매치시키기 위한 방법을 예시하는 도면이다.
도 19는 애플리케이션들에 대한 애플리케이션 프로그래밍 인터페이스(API)를 노출하는 프레임워크 및 서비스들의 세트와 통신하기 위한 서비스 API를 예시하는 도면이다.
도 20은 서비스들과 통신하기 위한 애플리케이션들, 게임 데몬 및 게임 서비스 모듈에 대한 API를 가지는 게임 프레임워크의 일 실시예를 예시하는 도면이다.
도 21은 API 구현 소프트웨어 컴포넌트 및 API 호출 소프트웨어 컴포넌트의 일 실시예를 예시하는 도면이다.
도 22는 API 호출들이 운영 체제들, 서비스들 및 애플리케이션들 사이에서 이루어지는 일 실시예를 예시하는 도면이다.
도 23은 예시적인 컴퓨터 시스템 아키텍처의 일 실시예를 예시하는 도면이다.
도 24는 예시적인 컴퓨터 시스템 아키텍처의 또다른 실시예를 예시하는 도면이다.

네트워크 상에서 프라이머리 및/또는 백업 피어-투-피어("P2P") 통신 채널들을 설정, 유지 및 이용하기 위한 장치, 방법 및 머신-판독가능한 매체의 실시예들이 하기에 기술된다. 또한 P2P 세션들 동안 각각 사용자들의 초대 및 사용자들의 매치를 위한 초대 서비스 및 매치메이커 서비스가 기술된다. 추가로, 사용자들로 하여금 어떤 특정 조건들 하에서 릴레이 접속들을 설정하게 하기 위한 릴레이 서비스가 기술된다. 마지막으로, 애플리케이션 개발자들로 하여금 여기서 기술된 다양한 공동 온라인 특징들을 사용하는 애플리케이션들을 설계하게 하기 위한 애플리케이션 프레임워크 및 연관된 애플리케이션 프로그래밍 인터페이스(API)가 기술된다.

기재 전반을 통해, 설명의 목적으로, 다수의 특정 상세항목들이 본 발명의 완전한 이해를 제공하기 위해 설명된다. 그러나, 본 발명이 이들 특정 상세항목들 중 일부 없이도 구현될 수 있다는 점이 당업자에게 명백할 것이다. 다른 경우들에서, 본 발명의 기본 원리들을 모호하게 하는 것을 피하기 위해 공지된 구조들 및 디바이스들이 도시되지 않거나, 블록도 형태로 도시된다.

접속 데이터를 효율적으로 그리고 안전하게 교환하기 위한 장치 및 방법

도 1에 예시된 바와 같이, 발명의 일 실시예에서 구현되는 일반적인 네트워크 토폴로지는 각각 네트워크(120)를 통해 서로 그리고 하나 이상의 서비스들(110-112)과 통신하는, "클라이언트" 또는 "피어" 모바일 컴퓨팅 디바이스들 A-D(120-123)의 그룹을 포함할 수 있다. 도 1에서 단일 네트워크 클라우드로서 예시되지만, "네트워크"(120)는, 몇몇을 들자면, 인터넷과 같은 공중 네트워크들 및 로컬 Wi-Fi 네트워크들(예를 들어, 802.11n 홈 무선 네트워크들 또는 무선 핫스폿들), 로컬 영역 이더넷 네트워크들, 셀룰러 데이터 네트워크들(예를 들어, 3G, Edge 등), 및 WiMAX 네트워크들과 같은 개인 네트워크들을 포함하는 다양한 상이한 컴포넌트들을 포함할 수 있다. 예를 들어, 모바일 디바이스 A(120)는 네트워크 링크(125)에 의해 표현되는 홈 Wi-Fi 네트워크에 접속될 수 있고, 모바일 디바이스 B(121)는 네트워크 링크(126)에 의해 표현되는 3G 네트워크(예를 들어, 유니버설 모바일 통신 시스템("UMTS"), 고속 업링크 패킷 액세스("HSUPA") 등)에 접속될 수 있고, 모바일 디바이스 C(122)는 네트워크 링크(127)에 의해 표현되는 WiMAX 네트워크에 접속될 수 있고, 모바일 디바이스(123)는 네트워크 링크(128)에 의해 표현되는 공중 Wi-Fi 네트워크에 접속될 수 있다. 모바일 디바이스들(120-123)이 접속되는 로컬 네트워크 링크들 각각(125-128)은 게이트웨이 및/또는 NAT 디바이스(도 1에 미도시됨)를 통해 인터넷과 같은 공중 네트워크에 커플링될 수 있고, 이에 의해 공중 네트워크를 통해 다양한 모바일 디바이스들(120-123) 사이의 통신을 가능하게 할 수 있다. 그러나, 2개의 모바일 디바이스들이 동일한 로컬 또는 개인 네트워크(예를 들어, 동일한 Wi-Fi 네트워크) 상에 있는 경우, 2개의 디바이스들은 로컬/개인 네트워크를 통해 직접 통신하고, 공중 네트워크를 바이패스할 수 있다. 물론, 본 발명의 기본 원리들이 네트워크 타입들 또는 네트워크 토폴로지들의 임의의 특정 세트에 제한되지 않는다는 점에 유의해야 한다.

도 1에 예시된 모바일 디바이스들(120-123) 각각은 접속 데이터 교환(CDX) 서비스(110), 매치메이커 서비스(111), 및 초대 서비스(112)와 통신할 수 있다. 일 실시예에서, 서비스들(110-112)은 서버들과 같은 하나 이상의 물리적 컴퓨팅 디바이스들을 통해 실행되는 소프트웨어로서 구현될 수 있다. 도 1에 도시된 바와 같이, 일 실시예에서, 서비스들(110-112)은 동일한 엔티티(예를 들어, 동일한 데이터 서비스 제공자)에 의해 관리되고 네트워크(120)를 통해 모바일 디바이스들(120-123) 각각에 의해 액세스가능한 더 큰 데이터 서비스(100)의 상황 내에서 구현될 수 있다. 데이터 서비스(100)는 다양한 타입들의 서버들 및 데이터베이스들을 접속시키는 로컬 영역 네트워크(예를 들어, 이더넷-기반 LAN)를 포함할 수 있다. 데이터 서비스(100)는 또한 데이터를 저장하기 위한 하나 이상의 저장 영역 네트워크("SAN")들을 포함할 수 있다. 일 실시예에서, 데이터베이스들은 데이터를 모바일 디바이스들(120-123) 각각 및 해당 디바이스들의 사용자들에 관련된 데이터(예를 들어, 사용자 계정 데이터, 디바이스 계정 데이터, 사용자 애플리케이션 데이터,...등)를 저장 및 관리한다.

일 실시예에서, 매치메이커 서비스(111)는 조건들의 특정 세트에 기초하여 공동 P2P 세션 동안 둘 이상의 모바일 디바이스들을 매치시킬 수 있다. 예를 들어, 모바일 디바이스들 중 둘 이상의 사용자들은 특정 멀티-플레이어 게임을 하는 것에 관심이 있을 수 있다. 이러한 경우, 매치메이커 서비스(111)는 각각의 사용자의 숙련도 레벨, 사용자들 각각의 연령, 매치 요청들의 타이밍, 매치가 요청되는 특정 게임 및 다양한 게임-특정 변수들과 같은 변수들에 기초하여 게임에 참여하기 위한 모바일 디바이스들의 그룹을 식별할 수 있다. 제한이 아닌 예시로서, 매치메이커 서비스(111)는 특정 게임을 할 때 유사한 숙련도 레벨들을 가지는 사용자들을 매치시키려고 시도할 수 있다. 추가로, 성인들은 다른 성인들과 매치될 수 있고, 어린이들은 다른 어린이들과 매치될 수 있다. 추가로, 매치메이커 서비스(111)는 해당 요청들이 수신되는 순서에 기초하여 사용자 요청들을 우선순위화할 수 있다. 본 발명의 기본 원리들은 매치 기준의 임의의 특정 세트 또는 P2P 애플리케이션의 임의의 특정 타입에 제한되지 않는다.

하기에 상세하게 기술되는 바와 같이, 매치 요청에 응답하여, 매치메이커 서비스(111)는 모든 매치되는 참여자들이 효율적이고 안전한 방식으로 P2P 세션들을 설정하기 위해 필요한 접속 데이터를 수신함을 보장하기 위해 CDX 서비스(110)와 조화될 수 있다.

일 실시예에서, 초대 서비스(112)는 또한 공동 P2P 세션들에 참여하기 위한 모바일 디바이스들을 식별한다. 그러나, 초대 서비스(112)의 경우, 참여자들 중 적어도 하나는 또다른 참여자에 의해 구체적으로 식별된다. 예를 들어, 모바일 디바이스 A(120)의 사용자는 (예를 들어, 사용자 ID 또는 전화 번호를 이용하여 모바일 디바이스 B를 식별하는) 모바일 디바이스 B(121)의 사용자와의 공동 세션을 구체적으로 요청할 수 있다. 매치메이커 서비스(111)를 이용하여, 초대 요청에 응답하여, 초대 서비스(112)는 참여자들의 세트를 식별하고, 모든 참여자들이 효율적이고 안전한 방식으로 P2P 세션들을 설정하기 위한 필요한 접속 데이터를 수신함을 보장하기 위해 CDX 서비스(110)와 조화될 수 있다.

전술된 바와 같이, 일 실시예에서, CDX 서비스(110)는 둘 이상의 모바일 디바이스들 사이에 P2P 세션들을 설정하기 위해 요구되는 접속 데이터에 대한 중심 교환점으로서 동작한다. 구체적으로, CDX 서비스의 일 실시예는 외부 서비스들 및 클라이언트들로 하여금 각각의 모바일 디바이스의 NAT를 통해 통신하게(즉, 디바이스에 도달하기 위해 NAT를 통해 "홀을 펀치"하게) 하기 위한 모바일 디바이스 요청들에 응답하여 NAT 이동 데이터(때때로, "홀 펀치" 데이터로서 참조됨)를 생성한다. 예를 들어, 일 실시예에서, CDX 서비스는 모바일 디바이스와 통신하기 위해 요구되는 외부 IP 어드레스 및 포트를 검출하고, 이 정보를 모바일 디바이스에 제공한다. 일 실시예에서, CDX 서비스는 또한 매치메이커 서비스(111) 및 초대 서비스(112)에 의해 생성되는 모바일 디바이스들의 리스트들을 수신 및 프로세싱하고 (하기에 상세히 설명되는 바와 같이) 리스트들 상에 포함되는 모바일 디바이스들 각각에 접속 데이터를 효율적이고 안전하게 분배한다.

일 실시예에서, 모바일 디바이스들 및 CDX 서비스(110) 사이의 통신은 사용자 데이터그램 프로토콜("UDP") 소켓들과 같은 상대적으로 경량의 네트워크 프로토콜을 사용하여 설정된다. 당업자에 의해 공지된 바와 같이, UDP 소켓 접속들은 패킷 신뢰도, 순서 또는 데이터 무결성을 보장하기 위해 핸드-쉐이킹 다이얼로그들을 요구하지 않고, 따라서, TCP 소켓 접속들만큼 많은 패킷 프로세싱 오버헤드를 소모하지 않는다. 결과적으로, UDP의 경량의 무상태 속성은 매우 많은 수의 클라이언트들로부터의 작은 질의들에 대답하는 서버들에 대해 사용가능하다. 또한, TCP와는 달리, UDP는 패킷 브로드캐스팅(여기서, 패킷들은 로컬 네트워크 상의 모든 디바이스들에 송신됨) 및 멀티캐스팅(여기서, 패킷들은 로컬 네트워크 상의 디바이스들의 서브세트에 송신됨)과 호환가능하다. 하기에 설명되는 바와 같이, UDP가 사용될 수 있다 하더라도, 세션 키들을 사용하여 NAT 이동 데이터를 암호화함으로써 CDX 서비스(110)에 대한 보안이 유지될 수 있다.

CDX 서비스(110)에 의해 사용되는 저-오버헤드, 경량의 네트워크 프로토콜에 비해, 일 실시예에서, 모바일 디바이스들(120-123) 및 매치메이커 서비스(111) 및/또는 초대 서비스(112) 사이의 통신은 보안 소켓층("SSL") 또는 전송층 보안("TLS") 접속들에 의존하는 하이퍼텍스트 전송 프로토콜 보안("HTTPS")과 같은 내재적으로 안전한 네트워크 프로토콜을 이용하여 설정된다. 이들 프로토콜들과 연관된 상세항목들은 당업자에 의해 공지되어 있다.

도 2a는 CDX 서버에 의해 구현될 수 있는 트랜잭션들의 예시적인 시리즈를 예시한다. CDX 서비스의 일 구현예의 동작을 기술하는 경우, 후속하는 용어들은 다음 의미를 가질 것이다:

접속 데이터 - 이는 잠재적 피어들이 피어-투-피어 세션을 설정하기 위해 서로 교환하는 정보이다. 이러한 정보가 교환될 수 있는 방법에 대한 메커니즘의 실시예들이 하기에 기술된다.

CDX 서버 - 일 실시예에서의 CDX 서버는 허가된 엔티티들로 하여금 임의의 데이터를 교환하게 하는 인증된 멀티캐스트 리플렉터(reflector)이다. 이러한 데이터는 페이로드로서 참조된다.

CDX 세션 - CDX 세션은 CDX 서버를 통해 서로 통신할 수 있는 클라이언트 디바이스들의 그룹을 참조한다. 세션의 일부분인 각각의 클라이언트 디바이스에는 CDX 티켓이 할당된다. 각각의 세션은 고유한 CDX 세션 ID를 가지는데, 이는 개별 세션을 식별하거나 참조하기 위해 사용될 수 있는 큰 정수이다.

CDX 요청 - 클라이언트 디바이스로부터 CDX 서버로 송신되는 요청. 요청은 일반적으로 2개 부분들, 즉 CDX 티켓 및 페이로드로 구성된다. 이러한 실시예에서, 페이로드는 세션 키를 가지고 암호화되는 접속 데이터이다.

CDX 응답 - CDX 응답은 CDX 서버가 CDX 세션의 멤버로부터 CDX 요청을 수신하는 경우 CDX 세션에서 다른 디바이스들에 다시 "반사"되는 것이다. 이는 주어진 CDX 요청에서 사용되는 CDX 티켓의 CDX 티켓 스터브(stub)에 페이로드를 첨부함으로써 구성된다.

CDX 티켓 - CDX 티켓은 CDX 세션의 멤버들에 페이로드를 송신하는 방법을 CDX 서버에 통지한다. 일 실시예에서, 이는 위조 또는 조작을 방지하기 위해 CDX 티켓 키를 이용하여 "서명"된다. 도 3에 예시된 바와 같이, 일 실시예에서, CDX 티켓은 후속하는 정보를 포함한다:

일 실시예에서 암호화되거나 흐려지지(obfuscated) 않은 세션 ID(301).

일 실시예에서 암호화되거나 흐려지지 않은 세션 내의 참여자들의 수(302).

이러한 티켓이 참조하는(일 실시예에서 암호화되거나 흐려지지 않은) 세션 내의 참여자의 인덱스(303).

이후 티켓이 무효한(일 실시예에서 암호화되거나 흐려지지 않음) 것으로 간주되는 만료 시간/날짜(304).

일 실시예에서 CDX 티켓 키를 사용하여 암호화된, 세션 내에 각각의 참여자들에 대한 CDX 홀-펀치 데이터(305-306).

티켓이 진본임을 보장하기 위해 "디지털 서명"으로서 작용하는 CDX 티켓 키를 사용하는 메시지 인증 코드(307).

CDX 티켓 스터브 - CDX 티켓의 제1 부분, 마이너스 CDX 홀-펀치 데이터 및 메시지 인증 코드.

페이로드 - 이는 CDX 요청 및 CDX 응답의 제2 부분이다. 페이로드는 클라이언트가 CDX 세션에서 다른 디바이스들에 전달하기를 원하는 데이터이다. 이 실시예에서, 페이로드는 세션 키를 가지고 암호화되는 접속 데이터이다. CDX 서버는 페이로드를 암호해독하지 않으며, 일 실시예에서, CDX 서버는 페이로드를 단순히 변경되지 않은 채 전달한다.

세션 키 - 이는 접속 데이터를 암호화하기 위해 클라이언트들에 의해 사용되는 키이다. 일 실시예에서, 이러한 키는 CDX 서버에 공지되지 않는다. 이 실시예에서, 세션 키는 매치메이킹 서비스에 의해 생성되고 클라이언트들에게 이들의 개별 CDX 티켓들과 함께 전송된다.

CDX 티켓 키 - 이는 CDX 티켓들을 생성하고 "서명" 하기 위해 사용되는 키이다. CDX 티켓 키는 오직 CDX 서버 및 CDX 티켓들을 생성하는 서비스 - 하기에 기술되는 바와 같이 매치메이킹 서비스 및/또는 초대 서비스일 수 있음 - 에 의해서만 공지된다.

CDX 홀-펀치 요청 - CDX 서버로부터 CDX 홀-펀치 데이터를 획득하기 위해 사용되는 CDX 요청의 특정 타입.

CDX 홀-펀치 데이터 - 이는 CDX 서버가 정보를 원래 이를 요청한 클라이언트에게 송신할 수 있는 방법을 기술하는 불투명한 데이터 블로브(blob)이다. 이는 CDX 서버에 CDX 홀-펀치 요청을 송신함으로써 획득된다. CDX 홀-펀치 데이터는 CDX 티켓들이 생성될 수 있기 전에 CDX 세션 내에서 각각의 클라이언트 디바이스로부터 수집되어야 한다. CDX 홀-펀치 데이터(때때로,"NAT 이동 데이터"로서 참조됨)는 요청 디바이스의 공중 IP 어드레스 및 포트를 포함할 수 있다.

이제 도 2a를 참조하면, 일 실시예에서, 모바일 디바이스 A(120) 및 모바일 디바이스 B(121)는 하나 이상의 다른 컴퓨팅 디바이스들과의 P2P 접속을 요청하는 공동 대화 세션 또는 멀티-플레이어 게임과 같은 공동 애플리케이션을 실행할 수 있다. 201a에서, 모바일 디바이스 A(120)는 CDX 서버(110)에 CDX 홀-펀치 요청을 전송한다. 202a에서, CDX 서버(110)는 이후 CDX 홀-펀치 데이터를 이용하여 응답한다. 일 실시예에서, 홀 펀치 데이터는 모바일 디바이스 A의 공중 IP 어드레스 및 포트 및/또는 모바일 디바이스 A의 NAT(예를 들어, 모바일 디바이스 A의 NAT 타입을 정의하는 NAT 타입 데이터)를 통해 홀을 펀칭하기 위해 필요한 임의의 다른 데이터를 포함한다. 유사한 트랜잭션들이 각각 201b 및 202b에서 모바일 디바이스 B에 대해 수행된다.

203a 및 203b에서, 모바일 디바이스들(A 및 B)은 이후 임의의 추가적인 매칭 기준(하기에 기술됨)과 함께, 매치메이킹 서비스에 대한 CDX 홀-펀치 데이터를 포함하는 매치 요청들을 송신한다. 이러한 스테이지에서, 모바일 디바이스들(A 및 B)은 P2P 접속을 설정하기 위해 필요한 접속 데이터를 구성하기 시작할 수 있다. 이는, 예를 들어, (예를 들어, NAT 이동 서비스에 의한) 표준 인터넷 접속 설정("ICE") 트랜잭션과 같은 트랜잭션을 사용하여 달성될 수 있다. 그러나, 본 발명의 기본 원리들은 접속 데이터를 결정하기 위한 임의의 특정 메커니즘에 제한되지 않는다.

일 실시예에서, 매치메이킹 서비스(111)가 매칭 기준을 이용하여 클라이언트 디바이스들의 세트를 발견하면, 이는 고유 CDX 세션 ID, CDX 세션의 각각의 멤버에 대한 고유 CDX 티켓, 및 고유 세션 키를 생성할 수 있다. 일 실시예에서, 매치메이킹 서비스(111)는 고유 CDX 티켓 키를 사용하여 CDX 티켓에 대한 CDX 홀-펀치 데이터를 암호화할 수 있다. 204a 및 204b에서, 매치메이킹 서비스는 이후 모바일 디바이스들(A 및 B) 각각에 이들의 CDX 티켓 및 세션 키를 송신할 수 있다.

모바일 디바이스 A는 CDX 티켓 및 세션 키를 수신하고, 세션 키를 사용하여 그것의 이전에 결정된 접속 데이터를 암호화하여, 페이로드를 만든다. 일 실시예에서, 모바일 디바이스 A는 CDX 티켓에 구성된 페이로드를 첨부함으로써 CDX 요청을 구성한다. 205a에서, 모바일 디바이스 A는 CDX 서버(110)에 CDX 요청을 송신한다. 205b에서, 모바일 디바이스 B는 또한 동일한 동작들을 수행하고, CDX 서버에 요청을 전송한다.

206a에서, CDX 서버(110)는 CDX 요청을 수신하고, (예를 들어, 메시지 인증 코드(307)에 기초하여) 티켓이 유효하며 진본임을 보장하기 위해 티켓을 검사한다. CDX 티켓이 무효한 경우, 요청이 드롭된다. 일 실시예에서, CDX 서버는 이후 CDX 티켓 키를 사용하여 CDX 티켓에 포함되는 CDX 홀-펀치 데이터 세트를 암호해독한다. 일 실시예에서, CDX 티켓 키는 또한 티켓들과 함께 전송될 수 있는 만료 시간/날짜를 포함할 수 있다. CDX 서비스(110) 및 매치메이커 서비스(111)는 암호화/암호해독을 위한 둘(이상)의 상이한 CDX 티켓 키들을 저장할 수 있다 - 제1 CDX 티켓 키는 현재 활성이고, 제2 CDX 티켓 키는 제1 CDX 티켓 키가 만료 시간/날짜에 도달할 시에 활성화될 것이다. 티켓을 수신할 시에 CDX 서비스(110)는 어느 티켓 키를 사용할지를 결정하기 위해 만료 시간/날짜를 판독할 수 있다. CDX 티켓 키가 만료되는 경우, CDX 서비스(110) 및 매치메이커 서비스(111) 모두는 각각 (현재 티켓 키가 만료된 이후 사용될 다음 키일) 새로운 티켓 키를 생성할 수 있다. 일 실시예에서, CDX 서비스(110) 및 매치메이커 서비스(111)는 2개의 티켓 키들과의 일치성을 보장하기 위해 동일한 키 생성 알고리즘을 실행한다. 예를 들어, 공지된 RSA SecurID 인증 메커니즘에 대해 사용되는 것과 같은 기법들이 사용될 수 있으며, 여기서 새로운 인증 코드가 고정된 구간들에서 생성된다. 일 실시예에서, 새로운 CDX 티켓 키는 매일 기반으로 생성된다. 그러나, 본 발명의 기본 원리들은 CDX 티켓 키들을 생성하기 위한 임의의 특정 메커니즘에 제한되지 않는다.

동일한 동작들이 모바일 디바이스 B에 대해 206b에 도시된 바와 같이 수행될 수 있다. CDX 서버는 CDX 요청으로부터 CDX 응답을 구성하고, (207a에서 모바일 디바이스 B에 그리고 207b에서 모바일 디바이스 A에 송신하는) CDX 세션에서 참여자들에게 CDX 응답을 송신하기 위해 CDX 홀-펀치 데이터를 사용한다.

모바일 디바이스 B는 CDX 서버로부터 CDX 응답(207a)을 수신한다. 클라이언트 디바이스 B는 세션 ID가 자신의 고유한 CDX 티켓의 세션 ID에 매치함을 보장하기 위해 CDX 티켓 스터브를 검사한다. 모바일 디바이스 B는 이후 세션 키를 사용하여 페이로드를 암호해독하여, 모바일 디바이스 A로부터 접속 데이터를 획득한다. 모바일 디바이스 B는 이후 P2P 세션을 설정하는 프로세스를 시작하기 위해 모바일 디바이스 A로부터의 접속 데이터를 사용한다. 일 실시예에서, 이들은 표준 ICE 트랜잭션들을 수반한다. 그러나, 본 발명의 기본 원리들은 P2P 통신을 설정하기 위한 어떠한 특정 메커니즘에도 제한되지 않는다.

전술된 바와 같이, 일 실시예에서, 모바일 디바이스 A 및 B는 (예를 들어, HTTPS 요청/응답 트랜잭션들을 사용하여) 매치메이커 서비스(111)와 통신하기 위해 하이퍼텍스트 전송 프로토콜 보안("HTTPS") 세션들을 설정하고, CDX 서비스와 통신하기 위해 UDP 소켓들을 설정한다. 매치 요청들(204a, 204b)은 각각의 개별 모바일 디바이스에 대해 이전에 결정된 홀 펀치 데이터(예를 들어, 공중 IP 어드레스 및 포트) 및 NAT 타입을 포함할 수 있다. 멀티-플레이어 게임을 수반하는 실시예에서, 각각의 매치 요청은 (예를 들어, 고유한 플레이어 ID 코드를 사용하는) 각각의 모바일 디바이스 상의 플레이어, 각각의 사용자가 플레이하기를 원하는 게임, 게임에 참여할 플레이어들의 수, 및/또는 원하는 게임과 연관된 다른 게임 구성 변수들을 식별할 수 있다. 제한이 아닌 예시로서, 게임과 연관된 게임 구성 변수들은 난이도 레벨(예를 들어, 쉬움, 중간, 어려움), 사용자의 연령(예를 들어, "13세 이하"), 게임의 서브-영역(예를 들어, "레벨 2"), 및/또는 사용자 숙련도 레벨(예를 들어, 전문가, 초보자, 중간)을 포함할 수 있다. 하기에서 상세하게 기술되는 바와 같이, 이들 변수들은 때때로, 게임 "버킷"으로서 참조되며, 고유한 "버킷 ID"를 사용하여 식별된다. 각각의 게임은 상이한 게임 구성 변수들을 식별하기 위한 버킷 ID들의 상이한 세트들을 포함할 수 있다.

일 실시예에서, 208a 및 209a에서 모바일 디바이스 B는 확인응답을 송신한다. 유사하게, 모바일 디바이스 A의 확인응답은 208b 및 209b에서 전송된다. 모바일 디바이스 A의 또는 B의 확인응답들이 특정 시간 기간 이후에 수신되지 않는 경우, 접속 데이터(207a)는 모바일 디바이스 B(212)에 재송신될 수 있다. CDX 서비스(110)가 재시도를 개시할 수 있고 그리고/또는 모바일 디바이스 A(120)가 재시도를 개시할 수 있다.

도 2b는 CDX 서비스 및 매치메이커 서비스(111)를 사용하여 3개의 상이한 모바일 디바이스들(120-122)이 P2P 접속들에 대해 협상하는 더욱 상세한 예를 예시한다. 도 2b는 또한 접속을 설정하기 위해 모바일 디바이스들(120-122)에 의해 사용되는 2개의 추가적인 서비스들, 즉 (예를 들어, ICE 접속 데이터 트랜잭션을 이용하여) 각각의 모바일 디바이스에 대한 전체 접속 데이터를 결정하기 위한 NAT 이동 서비스(290) 및 NAT 타입을 결정하기 위한 NAT 이동 서비스(291)를 예시한다. 그러나, 본 발명의 기본 원리들에 따르기 위해 별도의 서비스들이 요구되는 것이 아니라는 점에 유의해야 한다. 예를 들어, 대안적인 실시예에서, 이들 서비스들(290-291) 각각에 의해 수행되는 NAT 이동 기능들은 CDX 서비스(110) 및/또는 매치메이커 서비스(111) 내에 직접 통합될 수 있다. 유사하게, NAT 이동 서비스들(290-291) 모두에 의해 수행되는 기능들이 단일 NAT 이동 서비스 내에 통합될 수 있다. 요약하면, 도 2b에 도시된 특정 기능적 분리가 본 발명의 기본 원리들에 따르기 위해 요구되지 않는다.

이제 도 2b의 특정 상세항목들을 참조하면, 220에서, 모바일 디바이스 A는 NAT 이동 서비스(291)에 NAT 타입 요청을 전송한다. 그 응답으로, NAT 이동 서비스(291)는 모바일 디바이스 A에 의해 사용되는 NAT 타입을 결정하기 위해 일련의 트랜잭션들을 구현하는 것을 포함하는 다양한 공지된 기법들을 사용할 수 있다. 예를 들어, NAT 이동 서비스(291)는 모바일 디바이스 A의 NAT에 대한 상이한 IP 어드레스들 및 포트들을 개방하고 상이한 IP/포트 조합들을 사용하여 해당 포트들을 통해 모바일 디바이스 A와 통신하려 시도할 수 있다. 이러한 방식으로, 모바일 디바이스 A에 의해 사용되는 NAT는 전술된 NAT 타입들(예를 들어, 풀 콘, 제한된 콘, 포트 제한된 콘, 대칭) 중 하나 또는 대안적인 NAT 타입으로서 분류될 수 있다. 이러한 정보는 이후 예시된 바와 같이 모바일 디바이스 A(120)에 제공될 수 있다.

221에서, 모바일 디바이스 A(120)는 CDX 서비스(110)를 이용하여 NAT 이동 요청을 개시한다. 그 응답으로, CDX 서비스(110)는 요청을 위해 사용되는 공중 IP 어드레스 및 공중 포트 번호를 판독할 수 있고, 이 정보를 다시 모바일 디바이스 A(120)에 전송한다. 전술된 바와 같이, 디바이스가 NAT 뒤에 있는 경우, 이것의 공중 포트 및 IP 어드레스는 각각 디바이스의 개인 포트 및 IP 어드레스와 상이할 것이다. 따라서, 사용되는 NAT의 타입에 따라, 공중 IP 어드레스 및 포트는 모바일 디바이스에 도달하기 위해 NAT 디바이스를 통해 "홀을 펀치"하기 위해 사용될 수 있다.

222에서, 모바일 디바이스 A(120)는 매치메이커 서비스(111)에 매치 요청(222)을 전송한다. 전술된 바와 같이, 일 실시예에서, 모바일 디바이스 A는 하이퍼텍스트 전송 프로토콜 보안("HTTPS") 세션들을 사용하여(예를 들어, HTTPS 요청/응답 트랜잭션들을 사용하여) 매치메이커 서비스(111)에 전달한다. 매치 요청은 모바일 디바이스 A(120)에 대해 이전에 결정된 NAT 타입 및 홀 펀치 데이터(예를 들어, 공중 IP 어드레스 및 포트)를 포함할 수 있다. 멀티-플레이어 게임을 수반하는 실시예에서, 매치 요청은 (예를 들어, 고유한 플레이어 ID 코드를 사용하여) 모바일 디바이스 A 상의 플레이어, 사용자가 플레이하기를 원하는 게임, 게임에 참여할 플레이어들의 수, 및/또는 (도 2a에 대해 전술된 바와 같은) 원하는 게임과 연관된 다른 게임 구성 변수들을 식별할 수 있다.

223-225에서, 트랜잭션들(220-222)에 대응하는 트랜잭션들의 세트가 모바일 디바이스 B(121)에 대해 수행되고, 226-228에서, 트랜잭션들(220-222)에 대응하는 트랜잭션들의 세트는 모바일 디바이스 C(122)에 대해 수행된다. 따라서, 트랜잭션(228)에 후속하여, 매치메이커 서비스(111)는 모바일 디바이스들(120-122) 3개 모두에 대한 매치 요청들을 수신한다. 이러한 특정 예에서, 매치 요청들은 모바일 디바이스들(120-122)이 멀티-플레이어 게임과 같은 특정 공동 세션 동안 매치되는 것을 초래한다(예를 들어, 이들 모바일 디바이스들의 사용자들은 동일한 또는 유사한 변수들의 세트들을 이용하여 동일한 게임을 선택했을 수 있고, 이에 의해 매치메이커 서비스(111)에 의한 매치를 초래할 수 있다).

매치메이커 서비스(111)는 229에서 그것이 모바일 디바이스 A에 전송하는 티켓 A; 230에서 그것이 모바일 디바이스 B에 전송하는 티켓 B; 및 231에서 그것이 모바일 디바이스 C에 전송하는 티켓 C를 생성하기 위한 매치 요청들 각각에 포함되는 데이터를 사용한다. 도 2b에 도시되지 않았지만, 매치메이커 서비스(111)는 각각 모바일 디바이스들 A, B 및 C에 티켓들 A, B 및 C를 푸시하기 위한 푸시 통지 서비스(예를 들어, 도 11-12에 예시된 푸시 통지 서비스(1050)와 같은)를 이용할 수 있다. 티켓들 A, B 및 C에 대해 사용되는 티켓 데이터 구조의 일 실시예가 도 3에 대해 전술되었다.

232에서, 모바일 디바이스 A(120)는 자신만의 접속 데이터를 결정하기 위해 NAT 이동 서비스(290)와 통신한다. 일 실시예에서, 이는 표준 ICE 접속 데이터 트랜잭션을 포함할 수 있다. 이전에 언급된 바와 같이, 접속 데이터는 모바일 디바이스 A(120)에 대한 공중/개인 IP 어드레스, 포트 및 NAT 타입을 포함할 수 있다.

모바일 디바이스 A(120)는 티켓 A에 자신의 접속 데이터를 첨부하고, 233에서 CDX 서비스(110)에 접속 데이터를 가지는 티켓 A를 전송한다. 일 실시예에서, CDX 서비스(110)는 전술된 바와 같이 티켓 A를 프로세싱하고, 234에서, 모바일 디바이스 B(121) 및 모바일 디바이스 C(122)에 (암호화될 수 있는) 접속 데이터를 전송한다. 이들 트랜잭션들에 대해, CDX 서비스(110)는 티켓 A와 함께 포함된 모바일 디바이스들 B 및 C에 대한 NAT 이동 데이터를 이용할 수 있다.

236-238에서, 트랜잭션들(232-234)에 대응하는 트랜잭션들의 세트는 티켓 B를 사용하여 수행되고, 238-240에서, 트랜잭션들(232-234)에 대응하는 트랜잭션들의 세트가 티켓 C에 대해 수행된다. 따라서, 트랜잭션(240)에 후속하여, 접속 데이터가 모바일 디바이스들(120-122) 각각 사이에서 공유된다. 접속 데이터를 사용하여, P2P 세션들이 모바일 디바이스들 A 및 B, 모바일 디바이스들 A 및 C, 및 모바일 디바이스들 A 및 C 사이에 설정된다.

도 2c에 예시된 바와 같이, 초대 서비스(112)가 또한 CDX 서비스(110)와 함께(매치메이커 서비스(111) 대신 또는 추가하여) 사용될 수 있다. 일 실시예에서, 초대 서비스(112)는 특정 모바일 디바이스들 및/또는 사용자들과의 P2P 접속들을 위한 초대 요청들을 프로세싱한다. 초대 서비스(112)는 무상태 서비스(즉, 무선 디바이스들 각각 사이의 트랜잭션의 현재 상태를 고정하지 않는 서비스)로서 구현될 수 있다.

이 특정 예를 참조하면, 250에서, 모바일 디바이스 A(120)는 NAT 이동 서비스(291)에 NAT 타입 요청을 전송한다. 그 응답으로, NAT 이동 서비스(291)는 모바일 디바이스 A에 의해 사용되는 NAT 타입을 결정하기 위한 다양한 공지된 기법들을 사용할 수 있다(이 중 일부가 전술됨). 251에서, 모바일 디바이스 A(120)는 CDX 서비스(110)를 이용하여 NAT 이동 요청을 개시한다. 그 응답으로, CDX 서비스(110)는 요청을 위해 사용되는 공중 IP 어드레스 및 공중 포트 번호를 판독할 수 있고, 이 정보를 다시 모바일 디바이스 A(120)에 전송한다. 전술된 바와 같이, 디바이스가 NAT 뒤에 있는 경우, 그것의 공중 포트 및 IP 어드레스는 각각 그것의 개인 포트 및 IP 어드레스와 상이할 것이다. 따라서, 사용되는 NAT의 타입에 따라, 공중 IP 어드레스 및 포트는 모바일 디바이스에 도달하기 위해 NAT 디바이스를 통해 "홀을 펀치"하기 위해 사용될 수 있다.

매치메이커 서비스를 이용함으로써, 일 실시예에서, 모바일 디바이스들 각각은 하이퍼텍스트 전송 프로토콜 보안("HTTPS") 세션들을 사용하여(예를 들어, HTTPS 요청/응답 트랜잭션들을 사용하여) 초대 서비스(112)와 통신한다.

252에서, 모바일 디바이스 A(120)는 모바일 디바이스 A의 NAT 이동 데이터(예를 들어, NAT 타입, 공중 IP 어드레스/포트)를 포함하는 초대 서비스(112)에 초대 요청을 전송한다. (하기에 더욱 상세히 기술되는) 푸시 통지 서비스를 이용하는 실시예에서, 초대 요청은 또한 모바일 디바이스 A의 푸시 토큰을 포함할 수 있다. 초대 요청(252)은 또한 하나 이상의 다른 사용자들/디바이스들 - 이 경우, 모바일 디바이스들 B(121) 및 C(122)의 사용자들 - 을 식별하는 식별 코드를 포함할 수 있다. 다양한 상이한 식별 코드 타입들이 사용될 수 있다. 예를 들어, 멀티-플레이어 게임의 경우, 식별 코드들은 게임-특정 플레이어 ID 코드들을 포함할 수 있다. 오디오/비디오 대화 세션의 경우, 식별 코드들은 모바일 디바이스 A의 사용자의 "친구" 리스트로부터 하나 이상의 사용자들을 식별하는 전화 번호들 또는 고유한 ID 코드들을 포함할 수 있다.

일 실시예에서, 초대 서비스(112)는 초대 요청으로부터 식별 코드들을 판독하고, 모바일 디바이스들 B 및 C 각각을 위치시키기 위해 등록 데이터베이스(미도시)에서 검색을 수행한다. 일 특정 실시예에서, 모바일 디바이스들 B 및 C 각각은 초대 서비스(112)로부터 푸시 통지들을 수신하기 위해 푸시 서비스에 이전에 등록했다. 따라서, 이 실시예에서, 초대 서비스(112)는 253 및 254에서 각각, 모바일 디바이스 B(121) 및 모바일 디바이스 C(122)에 초대 요청들을 푸시하기 위해 푸시 통지 서비스를 사용한다. 푸시 통지 서비스에 관련된 추가적인 상세항목들이 하기에(예를 들어, 도 11-12 및 연관된 텍스트를 참조하라) 그리고 위에서 참조된 푸시 통지 애플리케이션에서 기술된다.

일 실시예에서, 초대 요청들(253 및 254)은 도 3에 예시되는, 그리고 도 2a-b에 대해 전술된 티켓 데이터 구조를 포함한다. 구체적으로, 모바일 디바이스 B에송신된 티켓은 모바일 디바이스들 A 및 B를 식별하는 암호화된 리스트를 포함하고, 모바일 디바이스 C에 송신된 티켓은 모바일 디바이스들 A 및 C를 식별하는 암호화된 리스트를 포함한다. 일 실시예에서, 초대 서비스(112)가 아직 모바일 디바이스 B의 NAT 이동 데이터를 가지지 않을 수 있으므로, 253에서 "티켓"은 모바일 디바이스 B를 식별하는 다른 정보를 포함할 수 있다. 예를 들어, 릴레이 서비스 및 다른 푸시 통지 서비스들을 이용하는 실시예들에 대해 하기에 설명되는 바와 같이(예를 들어, 도 11-12를 참조하라), 253에서, "티켓"은 모바일 디바이스 A에 대한 NAT 이동 데이터, 디바이스 A의 ID 코드, 디바이스 A의 푸시 토큰, 디바이스 B의 ID 코드, 및 모바일 디바이스 B에 대한 푸시 토큰을 포함할 수 있다. 동일한 정보 타입들이 모바일 디바이스 A 및 C에 대해 254에서 제공될 수 있다.

255에서, 모바일 디바이스 B는 자신의 NAT 타입을 결정하기 위해 NAT 이동 서비스(291)와 통신할 수 있고, 256에서, 모바일 디바이스 B는 자신의 NAT 이동 데이터(예를 들어, 공중 IP 어드레스/포트)를 결정하기 위해 CDX 서비스(110)와 통신할 수 있다. 257에서, 모바일 디바이스 B는 모바일 디바이스 A 및 모바일 디바이스 B의 식별 코드, NAT 이동 데이터, 및 푸시 통지 서비스가 사용되는 경우 모바일 디바이스들 A 및 B에 대한 푸시 토큰들을 포함하는 초대 서비스(112)에 대한 초대 응답을 전송한다. 258에서, 모바일 디바이스 B는 NAT 이동 서비스(290)와 통신함으로써 자신의 현재 접속 데이터를 검색할 수 있다. 259에서, 모바일 디바이스 B는 CDX 서비스(110)에 자신의 현재 접속 데이터를 가지는 자신의 티켓(티켓 B)을 전송한다. 그 응답으로, CDX 서비스(110)는 전술된 바와 같이 티켓을 프로세싱하고, 모바일 디바이스 A(120)에 접속 데이터를 포워딩한다.

모바일 디바이스 B의 초대 응답의 수신 시에, 초대 서비스(112)는 모바일 디바이스 A에 대한 암호화된 티켓을 생성하고 260에서 모바일 디바이스 A에 티켓을 전송할 수 있다. 일 실시예에서, 티켓은 모바일 디바이스들 A 및 B에 대한 NAT 이동 데이터, NAT 타입 및 푸시 토큰(푸시 통지 서비스가 사용되는 경우)을 포함한다. 도 2c에 대해 기술된 "티켓들"은 매치메이커 서비스(111)에 대해 기술된 "티켓들"에 대한 데이터 구조들과 동일하거나 상이할 수 있다. 예를 들어, 전술된 바와 같이 암호화된 "티켓"을 생성한다기보다는, 초대 서비스(112)는 단순히 모바일 디바이스들 각각을 이용하여 초대 세션을 식별하기 위해 고유한 세션 ID를 생성할 수 있다.

261에서, 모바일 디바이스 A는 NAT 이동 서비스(290)와 통신함으로써 자신의 현재 접속 데이터를 검색한다. 모바일 디바이스 A는 이후 티켓에 자신의 접속 데이터를 첨부할 수 있고, 262에서, CDX 서비스(110)에 자신의 접속 데이터를 가지는 티켓을 전송할 수 있다. CDX 서비스(110)는 전술된 바와 같이 티켓을 프로세싱하고 모바일 디바이스 B에 모바일 디바이스 A의 접속 데이터를 포워딩한다. 마지막으로, 263에서, 모바일 디바이스들 A 및 B는 직접 P2P 접속을 개방하기 위해 교환된 접속 데이터를 사용한다. 하기에 기술되는 바와 같이, 모바일 디바이스 A 및 B의 NAT 타입들이 호환가능하지 않은 경우들에서, 릴레이 서비스는 모바일 디바이스들 A 및 B 사이의 통신을 가능하게 하기 위해 사용될 수 있다.

264-272에서, 모바일 디바이스 C(122) 및 모바일 디바이스 A는 모바일 디바이스들 B 및 A에 대해 255-263에서 기술된 바와 같이 P2P 접속을 설정하기 위해 일련의 트랜잭션들을 실행할 수 있다. 구체적으로, 264에서, 모바일 디바이스 C(122)는 자신의 NAT 타입을 결정하기 위해 NAT 이동 서비스(291)와 통신하고, 265에서, 자신의 NAT 이동 데이터(예를 들어, 공중 IP 어드레스/포트)를 결정하기 위해 CDX 서비스(110)와 통신한다. 266에서, 모바일 디바이스 C는 모바일 디바이스 C 및 모바일 디바이스 A의 NAT 타입, NAT 이동 데이터 및 푸시 토큰(푸시 통지 서비스가 사용되는 경우)을 포함하는 초대 응답을 전송한다. 267에서, 모바일 디바이스 C는 NAT 이동 P2P 서비스(290)를 통해 자신의 현재 접속 데이터를 검색하고, 268에서, 모바일 디바이스 C는 티켓 C에 자신의 접속 데이터를 첨부하고, CDX 서비스(110)에 티켓 C를 전송한다. CDX 서비스(110)는 전술된 바와 같이 티켓을 프로세싱하고, 모바일 디바이스 A(120)에 모바일 디바이스 C의 접속 데이터를 포워딩한다.

269에서, 모바일 디바이스 A(120)는 모바일 디바이스 A 및 C의 NAT 타입, NAT 이동 데이터 및 푸시 토큰들(푸시 서비스가 사용되는 경우) 모두를 포함하는 초대 서비스(112)로부터의 모바일 디바이스 C의 초대 응답을 수신한다. 270에서, 모바일 디바이스 A는 NAT 이동 서비스(290)로부터 자신의 현재 접속 데이터를 검색하고, 티켓 A에 자신의 현재 접속 데이터를 첨부하고, 271에서, CDX 서비스(110)에 티켓 A를 전송한다. 대안적으로, 모바일 디바이스가 트랜잭션(261)에서 자신의 접속 데이터를 결정했으므로 트랜잭션(270)이 요구되지 않을 수 있다. CDX 서비스(110)는 전술된 바와 같이 티켓 A를 프로세싱하고, 모바일 디바이스 C에 모바일 디바이스 A의 접속 데이터를 포워딩한다. 마지막으로, 272에서, 모바일 디바이스 A 및 C는 직접 P2P 통신(272)을 설정하기 위해 교환된 접속 데이터를 사용한다.

일 실시예에서, 초대 서비스(112) 및 매치메이커 서비스(111)는 모바일 디바이스들에 데이터를 푸시하기 위해 푸시 통지 서비스(미도시)에 의존할 수 있다. 예를 들어, 도 2c에서, 초대 요청들(253 및 254)은 푸시 통지 서비스를 통해 모바일 디바이스들 B(121) 및 C(122)에 푸시될 수 있다. 유사하게, 도 2a에서, 티켓들(A 및 B)은 모바일 디바이스들 A(120) 및 B(121)에 푸시될 수 있다. 일 실시예에서, 모바일 디바이스가 네트워크 상에서 활성화되는 경우, 모바일 디바이스는 푸시 통지 서비스에 의해 액세스가능한 중심 등록 디렉토리 내에 자신의 푸시 토큰을 등록한다. 일 실시예에서, 등록 디렉토리는 패스워드 보호된 사용자 ID 또는 전화 번호를 푸시 토큰과 연관시킨다. 푸시 토큰이 디렉토리에서 식별될 수 있는 경우, 푸시 통지 서비스는 모바일 디바이스에 푸시 통지들을 전송하기 위해 푸시 토큰을 사용할 수 있다. 일 실시예에서, 푸시 통지 서비스가 본 출원의 양수인에 의해 설계되는 Apple 푸시 통지 서비스("APNS")이며, 예를 들어, 위에서 참조된 푸시 통지 애플리케이션에서 기술된다. 그러나, 푸시 통지 서비스가 도 2a-c에 도시된 발명의 실시예들에 의해 요구되지 않는다는 점에 유의해야 한다. 예를 들어, 푸시 통지들은 CDX 서비스(110)가 여기서 기술된 바와 같은 자신의 동작들을 수행하기 위해 요구되지는 않는다.

도 4는 접속 데이터를 교환하기 위해 CDX 서비스(110)에 의해 구현될 수 있는 방법을 예시하고, 도 5는 접속 데이터를 교환하고 P2P 접속을 설정하기 위해 모바일 디바이스에 의해 구현될 수 있는 방법을 예시한다. 이들 방법들의 특정 양상들이 도 1-2c에 대해 이미 전술되었다. 특히, 이들 방법들은 도 1-2c에 도시된 네트워크 아키텍처의 상황 내에서 구현될 수 있지만, 이들은 이러한 아키텍처에 제한되지 않는다. 일 실시예에서, 방법들은, 프로세서에 의해 실행되는 경우, 방법들의 동작들이 수행되게 하는 프로그램 코드에서 구현된다. 프로그램 코드는 랜덤 액세스 메모리("RAM")와 같은 머신-판독가능한 매체에 저장되면서, 프로세서에 의해 실행될 수 있다. 프로세서는 범용 프로세서(예를 들어, Intel? Core™ 프로세서) 또는 특수 목적 프로세서일 수 있다. 그러나, 방법들은 하드웨어, 소프트웨어 및 펌웨어의 임의의 조합을 사용하여 구현될 수 있다. 추가로, 프로그램 코드는 하드 디스크 드라이브, 광학 디스크(예를 들어, 디지털 비디오 디스크 또는 컴팩트 디스크)와 같은 비휘발성 저장 디바이스 또는 플래시 메모리 디바이스와 같은 비휘발성 메모리 상에 저장될 수 있다.

이제 도 4에 도시된 방법을 참조하면, 401에서, NAT 이동 요청(또한, 때때로 "홀 펀치" 요청으로서 참조됨)은 특정 모바일 디바이스 - 예에서 "모바일 디바이스 A" - 에 대해 수신된다. 402에서, NAT 이동 응답이 생성되어 모바일 디바이스 A에 전송된다. 일 실시예에서, NAT 이동 응답의 생성은 모바일 디바이스 A의 현재 공중 IP 어드레스/포트 및/또는 NAT 타입을 결정하는 것을 포함할 수 있다.

후속적으로 모바일 디바이스 A에 대한 티켓이 전술된 매치메이커 서비스(111) 또는 초대 서비스(112)와 같은 티켓-생성 엔티티에 의해 생성되고 암호화될 수 있다. 403에서, (디바이스 A 및 하나 이상의 다른 디바이스들에 대한) NAT 이동 데이터 및 디바이스 A에 대한 접속 데이터를 포함하는, 모바일 디바이스 A에 대해 생성된 티켓("티켓 A")이 수신된다. 404에서, 티켓은 메시지 인증 코드를 사용하여 인증되고, 홀 펀치 데이터는 티켓을 암호화하기 위해 티켓-생성 엔티티에 의해 사용된 것과 동일한 CDX 티켓 키를 사용하여 암호해독된다. 전술된 바와 같이, 일 실시예에서, 정확한 CDX 티켓 키는 CDX 티켓 키와 연관된 만료 시간/날짜를 사용하여 식별된다.

405에서, 모바일 디바이스들에 대한 NAT 이동 데이터가 추출된다. 406에서, 모바일 디바이스 A에 대한 접속 데이터는 NAT 이동 데이터를 사용하여 피어들 각각에 전송된다. 407에서, 확인응답들은 피어들 각각으로부터 수신된다. 408에서 확인응답들이 피어들 모두로부터 수신되지 않았다고 결정되는 경우, 409에서 모바일 디바이스 A의 접속 데이터는 응답하지 않은 해당 피어들에 재전송된다. 408에서 접속 데이터 모두가 확인응답된 것으로 결정되는 경우, 방법은 종료한다.

일 실시예에서, 도 4에 도시된 방법은 각각의 피어가 P2P 접속을 설정하기 위해 요구되는 접속 데이터를 수신함을 보장하기 위해 P2P 트랜잭션에 수반되는 피어들 각각에 대해 수행될 수 있다.

도 5는 여기서 기술되는 본 발명의 실시예들에 따라 모바일 디바이스에 의해 수행될 수 있는 방법을 예시한다. 501에서, NAT 이동 요청이 전송되고, 502에서, NAT 이동 응답이 수신된다. 이전에 기술된 바와 같이, 응답에 포함되는 NAT 이동 데이터는 요청 디바이스의 공중 포트/IP 어드레스를 포함할 수 있다. 503에서, NAT 이동 데이터를 포함하는 매치 요청이 전송된다. 모바일 디바이스에 대한 티켓이 후속적으로, 전술된 매치메이커 서비스(111) 또는 초대 서비스(112)와 같은 티켓-생성 엔티티에 의해 생성 및 암호화될 수 있다. 전술된 티켓 데이터에 대한 대안으로서, 매치메이커 서비스(111) 및/또는 초대 서비스(112)는 단순히 고유 세션 ID를 사용하여 참여자 각각을 식별할 수 있다.

504에서, 티켓이 수신될 수 있고; 505에서, 모바일 디바이스에 대한 접속 데이터가 티켓에 첨부되고; 506에서, 접속 데이터를 가지는 티켓이 전송된다. 507에서, 하나 이상의 다른 피어들과의 P2P 접속들을 설정하기 위해 요구되는 접속 데이터가 수신된다. 508에서, 하나 이상의 다른 무선 디바이스들이 506에서 전송된 접속 데이터를 수신했음을 표시하는 확인응답들이 수신된다. 모든 확인응답들이 수신되지 않는 경우, 510에서 접속 데이터는 확인응답들을 아직 송신하지 않은 해당 모바일 디바이스들에 재전송된다. 509에서, 모든 확인응답들이 수신되었다고 결정되면, 507에서 수신된 접속 데이터는 다른 모바일 디바이스들과의 P2P 세션들을 설정하기 위해 사용된다.

백업 통신 채널들을 설정 및 이용하기 위한 장치 및 방법

현재 모바일 디바이스들은 다양한 상이한 통신 채널들을 통해 통신할 수 있다. 예를 들어, Apple iPhone™은 Wi-Fi 네트워크들(예를 들어, 802.11b, g, n 네트워크들); 3G 네트워크들(예를 들어, 유니버설 모바일 통신 시스템("UMTS") 네트워크들, 고속 업링크 패킷 액세스("HSUPA") 네트워크들 등); 및 블루투스 네트워크들(개인 영역 네트워크("PAN")들로서 공지됨)을 통해 통신할 수 있다. 향후 모바일 디바이스들은, 몇몇을 들자면, WiMAX, 국제 이동 통신("IMT") 어드밴스드, 및 롱 텀 에볼루션("LTE") 어드밴스드와 같은 추가적인 통신 채널들을 통해 통신할 수 있을 것이다. 동작 시, 현재 모바일 디바이스들은 가용 채널들의 세트 중에서 하나의 프라이머리 통신 채널을 선택한다. 예를 들어, 모바일 디바이스들은 종종, Wi-Fi 접속이 사용가능한 경우 Wi-Fi 접속을 선택하고, Wi-Fi가 사용가능하지 않은 경우 셀룰러 데이터 접속(예를 들어, UMTS 접속)을 선택하도록 구성된다.

본 발명의 일 실시예에서, 모바일 디바이스들의 그룹은 표준 ICE 접속 데이터 교환들을 사용하여 그리고/또는 전술된 접속 데이터 교환 기법들을 사용하여 프라이머리 피어-투-피어("P2P") 통신 채널들을 초기에 설정한다. 모바일 디바이스들은 이후 프라이머리 채널들 중 임의의 것이 실패하는 경우 백업 채널들로서 사용되는 하나 이상의 세컨더리 통신 채널들을 설정하기 위해 프라이머리 채널들을 통해 접속 데이터를 교환할 수 있다. 일 실시예에서, 세컨더리 통신 채널들은 이들 채널들을 통해 "심박" 패킷들을 주기적으로 전송함으로써 NAT 방화벽들을 통해 개방한 채 유지된다.

여기서 사용된 바와 같이, 통신 "채널"은 2개의 모바일 디바이스들 사이의 풀 네트워크 경로를 참조하고, 통신 "링크"는 통신 경로에서 사용되는 하나의 특정 접속을 참조한다. 예를 들어, 디바이스 A가 Wi-Fi 접속을 사용하여 인터넷에 접속되고 디바이스 B가 3G 접속을 사용하여 인터넷에 접속되는 경우, 디바이스 A 및 디바이스 B 사이의 "채널"은 Wi-Fi 링크 및 3G 링크 모두에 의해 정의되고; 디바이스 A는 Wi-Fi 통신 "링크"를 가지고; 디바이스 B는 3G 통신 "링크"를 가진다. 따라서, 디바이스 A가 Wi-Fi 링크로부터 3G 링크로 스위칭되는 경우, 디바이스 A 및 디바이스 B 사이의 "채널"은 디바이스 B의 3G 링크가 동일하게 유지된다는 사실에도 불구하고 변경된다.

모바일 디바이스들이 프라이머리 및 세컨더리 통신 채널들을 설정하는 특정 예들이 이제 도 6에 대해 기술될 것이다. 그러나, 본 발명의 기본 원리들이 도 6에 도시된 통신 채널들 및 통신 링크들의 특정 세트에 제한되지 않는다는 점에 유의해야 한다.

도 6에서, 모바일 디바이스 A(601)는 NAT 디바이스(611)와 통신 링크(605)를 통해 그리고 NAT 디바이스(612)와 통신 링크(606)를 통해 네트워크(610)(예를 들어, 인터넷)에 접속할 수 있다. 유사하게, 디바이스 C(603)는 NAT 디바이스(613)와 통신 링크(609)를 통해 그리고 NAT 디바이스(613)와 통신 링크(610)를 통해 네트워크(610)에 접속할 수 있다. 제한이 아닌 예를 들어, 통신 링크들(605 및 609)은 3G 통신 링크들일 수 있고, 통신 링크들(606 및 610)은 Wi-Fi 통신 링크들일 수 있다.

결과적으로, 이 예에서, 모바일 디바이스 A 및 모바일 디바이스 B 사이에 설정될 수 있는 4개의 상이한 통신 채널들, 즉, 링크들(605 및 609)을 사용하는 제1 채널; 링크들(605 및 610)을 사용하는 제2 채널; 링크들(606 및 609)을 사용하는 제3 채널; 및 링크들(606 및 610)을 사용하는 제4 채널이 존재한다. 일 실시예에서, 모바일 디바이스들 A 및 B는 우선순위화 방식에 기초하여 프라이머리 통신 채널로서 이들 채널들 중 하나를 선택할 것이며, 백업 통신 채널들로서 3개의 나머지 채널들을 선택할 것이다. 예를 들어, 하나의 우선순위화 방식은 가장 높은 대역폭을 가지는 채널을 프라이머리 채널로서 선택하고 나머지 3개 채널들을 세컨더리 채널들로서 선택할 수 있다. 둘 이상의 채널들이 비교가능한 대역폭을 가지는 경우, 우선순위화 방식은 (사용자가 채널들 중 하나 이상을 사용하기 위해 비용을 지불한다고 가정하면) 가장 덜 비싼 채널을 선택하는 것을 포함할 수 있다. 대안적으로, 우선순위화 방식은 가장 덜 비싼 채널을 프라이머리 채널로서 선택할 수 있고, 각각의 채널의 비용이 동일한 경우, 가장 높은 대역폭 채널을 선택할 수 있다. 다양한 상이한 우선순위화 방식들이 구현될 수 있는 동시에 본 발명의 기본 원리들에 따를 수 있다.

모바일 디바이스들 A(601) 및 C(603)는 (예를 들어, CDX 서비스(110)를 통해 접속 데이터를 교환함으로써) 프라이머리 통신 채널을 설정하기 위해 전술된 기법들을 이용할 수 있다. 대안적으로, 모바일 디바이스들(601, 603)은 접속 데이터를 교환하기 위해 표준 인터넷 접속성 설정("ICE") 트랜잭션들을 구현할 수 있다. 프라이머리 채널이 설정되는 방법과는 무관하게, 일단 설정되면, 모바일 디바이스들 A(601) 및 C(603)는 프라이머리 통신 채널을 통해 세컨더리 통신 채널들에 대한 접속 데이터를 교환할 수 있다. 예를 들어, 도 6에서의 프라이머리 통신 채널이 통신 링크(606) 및 통신 링크(609)를 포함하는 경우, 이러한 접속은, 설정되면, 통신 링크들(605 및 609)을 포함하는 세컨더리 통신 채널들에 대한 접속 데이터를 교환하기 위해 사용될 수 있다. 이러한 예에서, 프라이머리 통신 채널을 통해 교환되는 접속 데이터는, 모바일 디바이스들 각각에 대한 공중 및 개인 IP 어드레스들/포트들을 포함하는, NAT(611) 및 NAT(613)에 대한 NAT 이동 데이터 및 NAT 타입 데이터를 포함할 수 있다.

세컨더리 통신 채널들이 설정되면, 이들은 심박 패킷들을 사용하여 개방된 채 유지된다. 예를 들어, 디바이스 A는 디바이스 C에 작은 "심박" 패킷을 주기적으로 전송할 수 있고 그리고/또는 디바이스 A는 세컨더리 채널들에 대해 사용되는 NAT 포트들이 개방된 채 유지됨을 보장하기 위해 디바이스 C에 작은 "심박" 패킷을 주기적으로 전송할 수 있다(NAT들은 비활성으로 인해 포트들을 종종 폐쇄할 것이다). 심박 패킷들이 페이로드 없는 UDP 패킷들일 수 있지만, 본 발명의 기본 원리들은 어떠한 특정 패킷 포맷에도 제한되지 않는다. 심박 패킷들이 이들의 페이로드 헤더 내의 자가 식별 타입 필드를 가지는 UDP 패킷들일 수 있고, 채널 TTL(time-to-live) 값을 포함하지만 이에 제한되지 않는 선택적인 추가적으로 포맷된 정보를 포함할 수 있다.

도 7에 예시된 바와 같이, 각각의 모바일 디바이스(601)는 프라이머리 및 세컨더리 통신 채널들의 리스트를 포함하는 데이터 구조(710)(예를 들어, 표, 텍스트 파일, 데이터베이스 등)를 저장 및 유지한다. 별도의 엔트리가 각각의 통신 채널에 대해 제공되고, 해당 채널을 이용하기 위해 요구되는 접속 데이터(예를 들어, 개인/공중 IP 어드레스, NAT 타입 등), 및 해당 채널의 현재 상태(예를 들어, 프라이머리, 세컨더리 1, 세컨더리 2 등)를 포함한다.

일 실시예에서, 통신 인터페이스들(701 및 702)은 각각 통신 링크(605) 및 통신 링크(606)를 통해 통신하기 위해 사용된다. 실패 검출 모듈(705)은 언제 특정 통신 인터페이스/링크가 실패하거나 특정 임계 미만으로 저하되는지를 검출하기 위해 모바일 디바이스(601) 상에서 실행된다. 그 응답으로, 링크 관리 모듈(706)은 다음으로 가장 높은 우선권을 가지는 세컨더리 채널을 프라이머리 채널로 승격시키기 위해 프라이머리/세컨더리 접속 데이터(710)를 판독할 수 있다. 세컨더리 채널들의 우선순위화는 (예를 들어, 대역폭, 비용, 신뢰성 등에 기초하여) 프라이머리 채널들에 대해 전술된 것들과 동일한 원리들을 사용하여 달성될 수 있다. 세컨더리 채널이 선택되면, 링크 관리 모듈(706)은 다른 모바일 디바이스들 상에서 링크 관리 모듈들에 링크 실패 표시를 전송하여, 해당 디바이스들에게 세컨더리 통신 채널을 프라이머리 통신 채널로 승격시키도록 명령할 수 있다. 해당 디바이스들은 선택된 프라이머리 채널과 연관된 접속 데이터를 사용하여 시작할 것이다.

일 실시예에서, 프라이머리 통신 채널의 완전한 "실패"는 세컨더리 통신 채널들 중 하나에 대한 스위칭을 강제하도록 요구되지 않는다. 예를 들어, 일 실시예에서, 프라이머리 통신 채널이 충분히 저하되는 경우(예를 들어, 특정 대역폭, 비트레이트, 또는 신뢰성 임계 미만), 세컨더리 채널에 대한 변경은 여기서 기술된 바와 같이 구현될 수 있다. 일 실시예에서, 세컨더리 채널에 대한 스위칭은 오직 세컨더리 채널이 현재 프라이머리 채널보다 더 양호한 성능(예를 들어, 대역폭, 비트레이트 또는 신뢰성)을 지원할 수 있는 경우에만 수행된다.

도 8a는 네트워크(610)에 직접 접속되고 개인 네트워크 접속(620)을 통해 디바이스 C(603)에 접속되는 모바일 디바이스 B(602)가 추가된, 도 6에 도시된 바와 동일한 네트워크 구성을 예시한다. 개인 네트워크(620)는, 예를 들어, 디바이스 B(602) 및 디바이스 C(603) 사이의 블루투스 PAN 접속일 수 있다. 이 예로부터, 프라이머리 채널로부터 세컨더리 채널로의 스위칭이 네트워크 토폴로지를 현저하게 변경할 수 있다는 점을 알 수 있다. 예를 들어, 도 8b에 도시된 바와 같이, 모바일 디바이스들에 대한 프라이머리 채널들(801)이 통신 링크(609)(디바이스들 A, B 및 C 사이의 직접 통신들을 초래함)를 포함하고, 세컨더리 채널들이 개인 네트워크(620)를 포함하는 경우, 네트워크 토폴로지는, 디바이스 A 및 디바이스 C가 개인 네트워크를 사용하여 통신하기 위한 유일한 길이 디바이스 B를 통과하는 것이므로, 도 8c에 예시된 바와 같이 변경될 수 있다. 이것이 오직 3개의 디바이스들을 가지는 간략화된 예이지만, 현저하게 더 많은 수의 디바이스들이 사용되어, 프라이머리 및 세컨더리 통신 채널들 사이에서 스위칭하는 경우 다양한 상이한 네트워크 토폴로지 구성들을 초래할 수 있다.

세컨더리 채널들을 설정 및 유지하기 위한 방법의 일 실시예가 도 8에 예시된다. 일 실시예에서, 방법은 각각의 모바일 디바이스 상에서 링크 관리 모듈(706)에 의해 실행될 수 있다. 그러나, 방법은 어떠한 특정 디바이스 구성에도 제한되지 않는다.

901에서, 프라이머리 P2P 통신 채널이 선택된다. 전술된 바와 같이, 프라이머리 채널은 미리 정의된 우선순위화 방식에 기초하여 선택될 수 있다. 예를 들어, 특정 통신 채널 타입들은 다른 통신 채널 타입들에 앞서 우선순위화될 수 있다. 채널들은 또한 대역폭, 사용 비용 및/또는 신뢰성과 같은 변수들에 기초하여 우선순위화될 수 있다.

902에서, 백업 P2P 통신 채널들이 설정된다. 일 실시예에서, 이는 프라이머리 통신 채널을 통해 모든 모바일 디바이스들 사이에서 접속 데이터를 공유함으로써 달성된다. 903에서, 백업 채널들이 유지된다. 이 실시예에서, 이는 (예를 들어, 주기적 심박 패킷들의 형태로) 세컨더리 통신 채널들을 통해 주기적으로 데이터를 전송하는 것을 수반한다.

904에서, (예를 들어, 특정 모바일 디바이스의 통신 링크가 다운되었거나 모바일 디바이스가 통신 링크의 범위 밖으로 이동했기 때문에) 프라이머리 P2P 채널이 실패하는 경우, 905에서, 모바일 디바이스들은 가장 높은 우선순위의 백업 채널을 프라이머리 채널로 승격시킨다. 일 실시예에서, 이는 실패한 링크를 가지는 모바일 디바이스가 세컨더리 채널을 통해 다른 디바이스들에 자신의 링크 실패의 통지를 전송하는 것을 수반한다. 마지막으로, 906에서, 백업 채널은 프라이머리 채널이 되고 프로세스는 902로 되돌아간다(여기서, 임의의 추가적인 백업 채널들이 발견되고 우선순위화 방식에 추가됨).

피어-투-피어(P2P) 통신 채널들을 설정하기 위한 초대 서비스를 위한 장치 및 방법

도 10에 예시된 바와 같이, CDX 서비스(110), 매치메이커 서비스(111) 및 초대 서비스(112)(전술된 일부 실시예들)에 추가하여, 본 발명의 일 실시예는 등록/디렉토리 서비스(1052), 푸시 통지 서비스(1050) 및 릴레이 서비스(1051)를 포함할 수 있다. 전술된 바와 같이, 일 실시예에서, 초대 서비스(112) 및/또는 매치메이커 서비스(111)는 등록된 모바일 서비스들을 식별하기 위한 등록/디렉토리 서비스(1052) 및 모바일 디바이스들에 데이터를 푸시하기 위한 푸시 통지 서비스(1050)를 사용할 수 있다. 일 실시예에서, 모바일 디바이스가 네트워크 상에서 활성화되는 경우, 이는 푸시 토큰을 패스워드 보호된 사용자 ID 또는 전화 번호와 연관시킴으로써 등록/디렉토리 서비스(1052)에 의해 유지되는 데이터 베이스에 "푸시 토큰"(때때로, 푸시 통지 애플리케이션에서 "통지 서비스 계정 식별자"로서 참조됨)을 등록한다. 푸시 토큰이 (예를 들어, 사용자 ID를 가지고 질의를 수행함으로써) 등록 디렉토리에서 식별되는 경우, 푸시 통지 서비스(1050)는 모바일 디바이스에 푸시 통지들을 전송하기 위해 푸시 토큰을 사용할 수 있다. 일 실시예에서, 푸시 통지 서비스는 본 출원의 양수인에 의해 설계되고, 예를 들어, 위에서 참조된 푸시 통지 애플리케이션에 기술된 Apple 푸시 통지 서비스("APNS")이다.

도 11은 푸시 통지 서비스(1051)가 두 개의 모바일 디바이스들 사이에 직접 P2P 접속을 설정하기 위해 사용되는 본 발명의 실시예를 예시하고, 도 12는 릴레이 서비스(1051)를 통해 P2P 접속을 설정하기 위해 사용되는 실시예를 예시한다. 하기에 기술된 바와 같이, P2P 접속을 설정하기 위해 릴레이 서비스(1051)를 사용할지의 여부에 대한 결정은 모바일 디바이스들 사이의 직접 P2P 접속을 설정하는 실현가능성에 기초할 수 있다(예를 들어, NAT 호환성 이슈들에 기초할 수 있다).

이제 도 11을 참조하면, 1101에서, 모바일 디바이스 A(120)는 모바일 디바이스 B를 초대하기 위해 모바일 디바이스 B(121)에 대해 P2P 통신 세션(예를 들어, 공동 비디오 게임, P2P 비디오 대화 등)에 대한 초대를 전송한다. 일 실시예에서, 초대는 특정 온라인 애플리케이션의 상황 내에서 모바일 디바이스 B(121)(및/또는 모바일 디바이스 B의 사용자)를 식별하는 사용자 ID를 포함한다. 예를 들어, 사용자 ID 코드는 특정 멀티-플레이어 P2P 게임에 대한 플레이어 ID일 수 있고, 예를 들어, 유니버설 고유 식별자(UUID)의 형태를 취할 수 있다. 대안적으로, 일부 실시예들에서, ID 코드는 모바일 디바이스 B(121)의 전화 번호일 수 있다. 게임 ID 코드는 모바일 디바이스 A가 참여할 모바일 디바이스 B를 초대하는 멀티-플레이어 게임을 식별하기 위해 사용될 수 있다. 버킷 ID는 (매치메이커 서비스에 대해 여기서 기술된 바와 같은) 해당 게임에 대한 구성을 식별하기 위해 사용될 수 있다.

초대(1101)는 또한 모바일 디바이스 A(120)를 식별하는 ID 코드 및 모바일 디바이스 A와 연관된 NAT 이동/접속 데이터를 포함할 수 있다(예를 들어, 모바일 디바이스 A에 대한 공중/개인 IP 어드레스들 및 포트들 및 디바이스 A의 NAT 디바이스에 대한 NAT 타입). NAT 이동/접속 데이터 또는 NAT 타입 데이터는 (예를 들어, 도 2a-c에 대해 전술된 것과 같은 NAT 이동, NAT 타입 및 접속 데이터 트랜잭션을 통해) 초대 요청(1101) 이전에 모바일 디바이스 A에 의해 이전에 결정될 수 있다. 이전에 언급된 바와 같이, 초대 요청(1101)은 HTTPS 요청의 형태를 취할 수 있다. 추가로, 추가적인 보안을 위해, 초대 요청(1101)은 미리-특정된 인증서 허가에 의해 서명된 클라이언트 인증서를 포함할 수 있다.

모바일 디바이스 B를 식별하기 위해 사용되는 ID 코드의 특정 타입과는 무관하게, ID 코드는 초대 서비스(112)에 의해 수신되고, 1102에서, 초대 서비스(112)는 모바일 디바이스 B("푸시-토큰-B")에 통지들을 푸시하기 위해 사용되는 푸시 토큰과 같은 통지 서비스 계정 식별자를 식별하기 위해 디렉토리 서비스(1052)(도 11에 미도시됨)에서 검색을 수행할 수 있다. 일 실시예에서, 검색 동작들은 초대가 허용되어야 하는지의 여부를 결정하기 위해 몇몇 검사들을 수행할 수 있다. 먼저, 이는 모바일 디바이스 A에 대한 식별 코드("ID-A") 및 디바이스 A의 푸시 토큰("푸시-토큰-A")이 디렉토리 서비스 데이터베이스 내에 등록된 연관임을 확인할 수 있다. 검색 동작(1102)은 또한 모바일 디바이스 A의 사용자가 모바일 디바이스 B의 사용자를 초대하도록 허가됨을 확인할 수 있다(예를 들어, 모바일 디바이스 B의 사용자는 B의 친구들로서 등록된 다른 사용자들만이 사용자 B를 초대할 수 있다고 특정할 수 있거나, 또는 어떠한 초대들도 허가되지 않는다고 특정할 수 있다). 일 실시예에서, 이들 검사들 중 임의의 것이 실패하는 경우, 초대가 취소되고, 초대 서비스(112)는 모바일 디바이스 A에 에러를 리턴시킨다.

"푸시 토큰"이 이 실시예에서 기술되지만, 본 발명의 기본 원리들이 "푸시 토큰"의 사용 또는 통지들을 인증하고 모바일 디바이스들에 푸시하기 위한 임의의 다른 특정 데이터 구조에 제한되지 않는다는 점에 유의해야 한다.

일 실시예에서, 푸시 토큰이 식별된 이후, 초대 서비스(112)가 식별된 이후, 초대 서비스(112)는 초대 세션에 할당되고 모든 추가적인 트랜잭션들에서 세션을 식별하기 위해 사용되는, 보안 일회성 "세션 토큰"을 생성할 수 있다. 세션 토큰의 카피는 모바일 디바이스 A(120)에 다시 전송되고 초대 요청을 이용하여 모바일 디바이스 B에 송신된다. 일 실시예에서, 세션 토큰은 전술된 티켓 데이터 구조와 함께 사용되고, 또다른 실시예에서, 오직 세션 토큰만이 사용된다.

1103에서, 초대 서비스(112)는 푸시 통지 서비스(1050)에 푸시 요청을 전송한다. 일 실시예에서, 푸시 요청은 모바일 디바이스 A에 대한 NAT 이동 데이터, 디바이스 A의 ID 코드, 푸시-토큰-A, 디바이스 B의 ID 코드, 및 푸시-토큰-B를 포함할 수 있다. 일 실시예에서, 이러한 정보는 "티켓" 데이터 구조 내에 패키지화되고 전술된 바와 같이 암호화될 수 있다. 또다른 실시예에서, 데이터는 단순히 초대 세션 ID를 이용하여 전송된다.

이러한 예에서 모바일 디바이스 B(121)가 푸시 통지 서비스(1050)에 등록했으므로, 푸시 통지 서비스(1050)는 1104에서 모바일 디바이스 B(121)에 초대 요청을 위치시키고 푸시할 수 있다. 푸시된 초대(1104)는 세션 토큰, 모바일 디바이스 A의 NAT 이동 데이터/접속 데이터, 및 모바일 디바이스 B의 ID 코드를 포함할 수 있다. 초대 요청에 응답하여, 모바일 디바이스 B는 전술된 바와 같이 NAT 이동 서비스 또는 CDX 서비스(110)에 호출을 수행함으로써 자신의 네트워킹 정보(예를 들어, NAT 이동/접속 데이터, NAT 타입 등)를 결정할 수 있다.

1105에서, 모바일 디바이스 B는 초대를 수락한다. 수락(1105)은 초대 서비스(112)에 대한 HTTPS 호출의 형태를 취할 수 있고, (초대 요청에 대해 전술된) 미리-특정된 인증서 허가에 의해 서명된 클라이언트 인증서를 포함할 수 있다. 일 실시예에서, 수락(1105)은 모바일 디바이스들 A 및 B에 대한 ID 코드 및 모바일 디바이스들 A 및 B에 대한 NAT 이동/접속 데이터 및/또는 NAT 타입을 포함할 수 있다. 수락(1105)은 또한 모바일 디바이스들 A 및 B에 대한 푸시 토큰들 및/또는 세션 토큰을 포함할 수 있다. 일 실시예에서, 수락(1105)은 또한 이것이 이전에 실패한 직접 접속 시도로부터의 재시도인지에 대한 표시를 포함할 수 있다. 그러나, 또다른 실시예에서, 수락(1105)은 재시도 표시를 포함하지 않는다. 오히려, 실패한 P2P 접속 시도를 검출할 시에, 두 개의 모바일 디바이스들 중 하나는 초대 서비스(112)에 특수 "릴레이 초대"를 전송할 수 있다. 그 응답으로, 서비스는 도 12에 대해 하기에 기술되는 릴레이 트랜잭션들의 시리즈를 직접 개시할 수 있다(1201에서 시작함).

1106에서, 초대 서비스(112)는 모바일 디바이스들 A 및 B 사이의 직접 P2P 접속이 구현가능한지의 여부를 결정하기 위해 호환성 검사를 수행할 수 있다. 예를 들어, 일 실시예에서, 모바일 디바이스 B로부터 수신된 수락(1105)이 이것이 이전의 실패한 직접 접속 시도로부터의 재시도(또는 이전에 실패한 직접 접속 시도들의 특정 수)임을 표시하는 경우, 초대 서비스는 직접 P2P 접속이 구현불가능하다고 결론지을 수 있다. 초대 서비스(112)는, 모바일 디바이스들 A 및 B의 NAT 디바이스들이 직접 P2P 접속을 지원할 것인지의 여부를 결정하기 위해 모바일 디바이스들 A 및 B에 대한 NAT 타입 데이터를 비교할 수 있다. NAT 타입들의 특정 조합들은 직접 P2P 접속들을 설정하기에 호환불가능한 것으로 공지되어 있다. 예를 들어, 풀 콘 NAT는 직접 P2P 접속을 설정하기 위해 폐쇄된/방화벽에 막힌 NAT를 제외한 임의의 다른 NAT 타입과 함께 사용될 수 있다. 반면, 대칭적 NAT는 직접 P2P 접속을 설정하기 위해 오직 풀 콘 NAT와 함께 사용될 수 있다. 본 발명의 일 실시예에서 다양한 NAT 타입들을 결합시키는 구현가능성이 도 14에 도시된 NAT 호환성 표(1400)에 설명되며, 여기서 열들은 하나의 모바일 디바이스(예를 들어, 모바일 디바이스 A)의 NAT 타입들을 나타내고, 행들은 다른 모바일 디바이스(예를 들어, 모바일 디바이스 B)의 NAT 타입들을 나타낸다. 셀 내의 "1.0"은 연관된 행 및 열 내의 NAT 타입들이 호환가능함을 표시하고, "0.0"은 NAT 타입들이 호환불가능함을 표시한다.

일 실시예에서, 호환성 검사(1106)가 직접 P2P 접속이 구현불가능하다고 결정하는 경우, 초대 서비스(112)는 도 12에 대해 하기에 기술되는 바와 같이 릴레이 검색 요청(1201)을 전송할 수 있다. 그러나, 호환성 검사(1106)가 직접 P2P 접속이 구현가능하다고 결정하는 경우, 초대 서비스(112)는 모바일 디바이스 A의 초대의 모바일 디바이스 B의 수락을 포함하는 통지 서비스(1050)를 푸시하기 위해 푸시 요청(1107)을 전송할 수 있다. 푸시 통지 서비스(1050)로부터 모바일 디바이스 A로의 푸시 요청(1107) 및 후속하는 푸시 통신(1108)은 세션 토큰 및 모바일 디바이스 A 및 B의 푸시 토큰 모두, ID 코드, 및/또는 NAT 이동/접속 데이터를 포함할 수 있다. 일 실시예에서, 이러한 정보는 전술된 "티켓" 데이터 구조 내에 패킹될 수 있고(예를 들어, 도 2a-c 및 연관된 텍스트를 참조하라) 고유 키를 사용하여 암호화될 수 있다. 대안적으로, 이러한 정보는 단순히 고유 초대 세션 ID와 함께 전송될 수 있다. 초대 서비스(1050)는 또한 직접 접속이 시도될 것임을 모바일 디바이스 B에 통지할 수 있다.

이 스테이지에서, 모바일 디바이스들 A 및 B는 직접 P2P 접속을 설정하기에 충분한 정보를 가진다. 일 실시예에서, 이는 전술된 바와 같은 CDX 서비스(110)를 사용하여 달성된다. 예를 들어, 모바일 디바이스 B는 티켓 B에 자신의 접속 데이터를 첨부하고, 1109에서, CDX 서비스에 (접속 데이터를 가지는) 티켓 B를 전송한다. 이러한 트랜잭션 바로 이전에, 모바일 디바이스 B는 자신의 접속 데이터가 현재 것임을 보장하기 위해 도 2b에 도시된 트랜잭션(235)과 같은 트랜잭션을 구현할 수 있다. CDX 서비스(110)는 이후 (예를 들어, 전술된 바와 같은 고유 세션 키를 사용하여) 티켓을 인증하고, 모바일 디바이스 B의 접속 데이터를 추출하고, 1110에서 모바일 디바이스 A에 접속 데이터를 포워딩한다. 유사하게, 모바일 디바이스 A는 티켓 A에 자신의 접속 데이터를 첨부하고, 1111에서, CDX 서비스(110)에 (접속 데이터를 가지는) 티켓 A를 전송한다. 이러한 트랜잭션 바로 이전에, 모바일 디바이스 A는 자신의 접속 데이터가 현재 것임을 보장하기 위해 도 2b에 도시된 트랜잭션(232)과 같은 트랜잭션을 구현할 수 있다. CDX 서비스(110)는 이후 (예를 들어, 전술된 바와 같은 고유 세션 키를 사용하여) 티켓을 인증하고, 모바일 디바이스 A의 접속 데이터를 추출하고, 1112에서 모바일 디바이스 B에 접속 데이터를 포워딩한다. 마지막으로, 1113에서, 모바일 디바이스들 A 및 B는 교환된 접속 데이터를 사용하여 직접 P2P 접속에 진입한다.

이제 도 12를 참조하면, 호환성 검사(1106)가 직접 P2P 접속이 구현불가능함을 결정하는 경우, 초대 서비스(112)는 각각의 모바일 디바이스에 의해 사용될 릴레이 호스트를 결정하기 위해 릴레이 서비스(1051)에 릴레이 검색 요청(1201)을 전송할 수 있다. 요청(1201)은 모바일 디바이스들 모두에 대해 적절한 릴레이 호스트들을 선택하기 위해 릴레이 서비스(1051)에 의해 사용되는 모바일 디바이스들 A 및 B에 대한 네트워킹 정보(예를 들어, NAT 이동/접속 데이터 및/또는 NAT 타입 데이터)를 포함할 수 있다. 도 13에 예시된 바와 같이, 릴레이 서비스의 일 실시예(1051)는 복수의 릴레이 호스트들(1302-1303) 및 릴레이 호스트들 각각에 관련된 네트워크 정보를 포함하는 릴레이 호스트 데이터베이스(1301)를 포함한다. 초대 서비스(112)는 모바일 디바이스들(A 및 B)에 대한 네트워크 정보를 사용하여 릴레이 호스트 데이터베이스(1301)에 질의하는 릴레이 검색 서비스(1300)에 릴레이 검색 요청(1201)을 전송한다. 데이터베이스 결과들의 수신 시에, 릴레이 검색 서비스(1300)는 선택된 릴레이 호스트들(1302-1303)을 식별하는 응답(1202)을 제공한다.

일 실시예에서, 릴레이 검색 응답(1202)은 릴레이 서비스에 의해 생성되는 릴레이 토큰 및 릴레이 접속을 위해 모바일 디바이스들 A 및 B에 의해 사용될 릴레이 호스트들(1302-1303)의 네트워크 어드레스들(IP 어드레스들/포트들)을 포함한다. 일 실시예에서, 릴레이 토큰은 릴레이 세션과 연관되며, 릴레이 서비스(1051)에 접속할 시에 모바일 디바이스들 A 및 B를 인증하기 위해 릴레이 호스트들(1302-1303)에 의해 사용된다. 토큰은 예를 들어, 고유 ID 릴레이 세션 ID 코드, 디지털 인증서 및/또는 릴레이 세션과 연관된 고유 암호화 키를 포함하는 다양한 형태들을 취할 수 있다.

1203에서, 초대 서비스는 릴레이 접속이 이루어질 것이라는 표시를 포함하는 모바일 디바이스 B(121)에 릴레이 응답(1203)을 전송한다. 일 실시예에서, 릴레이 응답(1203)은 릴레이 토큰 및 릴레이 호스트 B(1303)에 대한 네트워크 정보를 포함할 수 있다. 일 실시예에서, 응답(1203)은, 그것이 모바일 디바이스 B의 수락(1105)에 응답하여 송신되므로, (푸시 통지 서비스(1050)를 바이패스하는) 모바일 디바이스 B에 직접 송신될 수 있다.

초대 서비스(112)는 릴레이 토큰 및 릴레이 호스트 B(1303)에 대한 네트워크 정보를 포함할 수 있는 릴레이 응답(1204)을 모바일 디바이스 A에 전송한다. 이러한 경우, 응답(1204)은 트랜잭션(1205)에서 푸시 통지 서비스(1050)를 통해 모바일 디바이스 A에 푸시된다.

1206에서, 모바일 디바이스 A(120)는 릴레이 서비스(1051)와의 접속을 설정하기 위해 릴레이 호스트 A(1302)에 대한 네트워크 정보를 사용한다. 유사하게, 1207에서, 모바일 디바이스 B(121)는 릴레이 서비스(1051)와의 접속을 설정하기 위해 릴레이 호스트 B(1303)에 대한 네트워크 정보를 사용한다. 이들 트랜잭션들 각각에서, 새로운 홀들이 모바일 디바이스들 A 및 B의 임의의 NAT 방화벽들에서 개방되고, 모바일 디바이스들 A 및 B에 대한 NAT 이동/접속 데이터가 (예를 들어, 디바이스들에 대한 공중 IP/포트를 결정함으로써) 릴레이 서비스(1051)에 의해 결정되고 각각 모바일 디바이스들 A 및 B에 리턴될 수 있다. 일 실시예에서, 릴레이 서비스(1051) 및 모바일 디바이스들 A 및 B는, 당업자에 의해 이해되는 바와 같이, NAT 또는 방화벽 뒤의 엘리먼트로 하여금 TCP 또는 UDP 접속들을 통해 인입 데이터를 수신하게 하는 TURN(Traversal Using Relay NAT) 프로토콜을 구현한다.

1208에서, 모바일 디바이스 A는 초대 서비스(112)에 릴레이 업데이트를 전송하며, 이는 1209에서 푸시 통지 서비스에 포워딩되고 1210에서 모바일 디바이스 B에 푸시된다. 유사하게, 1211에서, 모바일 디바이스 B는 초대 서비스(112)에 릴레이 업데이트를 전송하고, 이는 1212에서 푸시 통지 서비스로 포워딩되고 1213에서 모바일 디바이스 A에 푸시된다. 모바일 디바이스 A에 의해 전송되는 릴레이 업데이트는 세션 토큰, 각각의 디바이스의 ID 코드, 및 1206 및 1207에서 릴레이에 의해 결정되는(즉, 모바일 디바이스 B에 자신의 NAT 이동/접속 데이터를 송신하는 모바일 디바이스 A를 가지는, 그리고 그 역이 성립하는) NAT 이동/접속 데이터를 포함할 수 있다. 일 실시예에서, 각각의 모바일 디바이스의 NAT 정보가 변경될 수 있으므로 릴레이 업데이트 동작들이 수행된다.

마지막으로, 1214 및 1215에서 모바일 디바이스들 A 및 B는 각각 릴레이 서비스(1051)를 통한 P2P 접속을 설정한다. 일 실시예에서, 모바일 디바이스 A가 릴레이 서비스(1051)에 모바일 디바이스 B의 NAT 이동/접속 데이터를 송신하고 그 역도 성립하는 경우 릴레이 접속들이 설정될 수 있고, 릴레이 접속들이 설정될 수 있고, 이에 의해 릴레이 서비스로 하여금 각각의 피어의 릴레이 호스트(1302-1303)에 정확한 경로를 결정하게 한다.

전술된 기법들을 사용하여, 초대 서비스(112)는, 심지어 매우 많은 수의 모바일 디바이스들을 가지는 대형 스케일의 시스템에서, 내재적으로 스케일링가능하고 복원가능한 무상태 서비스로서 구현될 수 있다. 예를 들어, 푸시 통지 서비스(1050)가 내재적으로 컨텐츠를 위치시키고 등록된 모바일 디바이스들에 푸시할 수 있으므로, 초대 서비스는 각각의 디바이스의 현재 위치를 추적하도록 요구되지 않는다. 추가로, 디바이스들이 각각의 요청 및 응답을 가지고 전체 세션 상태 데이터를 전송할 수 있으므로, 초대 서비스는 임의의 접속-당 상태 정보를 유지하기 위해 요구되지 않으며, 이에 의해 저장소를 감소시키고 초대 서비스의 요건들을 프로세싱한다. 이러한 구현예는 대형 스케일의 시스템에서 특히 사용가능하다.

온라인 세션들 동안 사용자들을 매치시키기 위한 시스템 및 방법

도 15에 예시된 바와 같이, 매치메이커 서비스(111)의 일 실시예는 매치 요청들을 수신하고 모바일 디바이스들(120-122)에 매치 응답들을 푸시하기 위한 매치메이커 디스패처(1501); 요청 표(1502)에 매치 요청들을 저장하고 매치가능한 세트 식별자("MSI") 표(1503)에서 매치가능한 세트 데이터를 저장하기 위한 데이터베이스(1512); 및 데이터베이스(1512)로부터 매치 요청들을 패치하고, 매치 동작들을 수행하고, 데이터베이스(1512)에 다시 매치 결과들을 저장하기 위한 하나 이상의 매치메이커들(1510)을 포함할 수 있다. 그러나, 본 발명의 기본 원리들이 도 15에 도시된 특정 아키텍처에 제한되지 않는다는 점에 유의해야 한다.

일 실시예에서, 매치메이커 디스패처(1501)는 모바일 디바이스들(120-122)로부터의 요청들을 수신하고, 해당 요청들을 데이터베이스(1512) 내에 요청들을 저장하기 위한 커맨드들로 변환하고, 데이터베이스(1512)로부터 매치 결과들을 판독하고, 해당 결과들을 변환하고 모바일 디바이스들(120-122)에 전달하는 매치메이커 서비스(111)에 대한 인터페이스로서 작용한다.

동작 시에, 새로운 매치 요청이 도달하는 경우, 매치메이커 디스패처(1501)는 요청 표(1502)의 행 내에 요청을 저장할 수 있다. 일 실시예에서, 디스패처(1501)는 (각각 모바일 디바이스들 A, B 및 C에 대응하는) 도 15에서 단순히 "A", "B" 및 "C"로서 예시되는 각각의 매치 요청을 요청 ID("RID") 코드에 할당한다. 간략함을 위해 도 15에서 문자 표기를 사용하여 도시되지만, RID 코드는 스트링, 정수, 또는 데이터베이스 내에 매치 요청들을 추적하기에 적절한 임의의 다른 변수 타입일 수 있다.

각각의 매치 요청에는 요청 표(1502)에 저장되는 매치가능한 세트 식별자("MSI") 값이 할당될 수 있다. 일 실시예에서, MSI는 매치가 요청되는 특정 애플리케이션 및/또는 해당 애플리케이션에 대해 사용될 구성 파라미터들을 식별할 수 있다. 예를 들어, 12:4의 MSI 값은 식별자 "12"를 가지는 특정 멀티-플레이어 게임을 식별할 수 있고, 식별자 "4"를 가지는 게임에 대한 특정 구성을 식별할 수 있다. 더 구체적으로, 12의 ID 코드는 특정 멀티-플레이어 레이싱 게임을 식별할 수 있고, 4의 ID 코드는 레이싱 게임에 대한 특정 레이싱 트랙, 스피드 또는 플레이어 경험 레벨을 특정할 수 있다. 일 실시예에서, 애플리케이션 개발자들은 이러한 방식으로 MSI 값들을 사용하여 임의의 애플리케이션 구성 파라미터들을 특정하기 위한 옵션을 제공받는다. 일 실시예에서, MSI를 직접 특정한다기보다는, 애플리케이션 개발자들은 (특정 게임을 식별하기 위한) 게임 ID 및 (특정 게임 구성을 식별하기 위한) 버킷 ID를 특정하고, 이들 값들은 매치메이커 디스패처(1501)에 의해 MSI 값에 매핑된다.

추가로, 몇몇 상이한 MSI 값들은 다수의 상이한 구성 파라미터들을 특정하기 위해 단일 MSI 내에서 사용될 수 있다(예를 들어, 12:4:1은 12= 레이싱 게임; 4=트랙; 및 1= 경험 레벨을 나타낼 수 있다). 하기에 기술된 바와 같이, 일 실시예에서, 각각의 MSI는 매치메이킹 동작들이 수행될 수 있는 매치 요청들의 세트를 식별하기 위해 매치메이커(1510)에 의해 사용된다(예를 들어, 요청들은 MSI에 기초하여 그룹화되고, 매치들은 각각의 MSI 그룹 내에서 수행된다). 일 실시예에서, 각각의 MSI는 상이한 머신 파티션들을 식별하는 파티션 ID를 포함하도록 디스패처에 의해 동적으로 수정/선택될 수 있다. 예를 들어, 특정 MSI가 오버로드되는 경우, 디스패처는 (예를 들어, 4:3:1 및 4:3:2와 같은 표기들을 사용하여 - 여기서 마지막 디지트들은 각각 파티션들 1 및 2를 식별함 -) 둘 이상의 상이한 서버들 및/또는 저장소 파티션들 사이에서 MSI를 분할할 수 있다. 상이한 매치메이커는 이후 상이한 서버들 각각으로부터의 상이한 MSI들 각각으로부터 요청들을 독립적으로 검색 및 프로세싱할 수 있다.

도 15에 예시된 바와 같이, 매치 요청 데이터는 또한 각각의 요청에 대한 요청 표(1502) 내에 저장될 수 있다. 요청 데이터는 매치메이킹 결정을 렌더링하기 위해 사용가능한 임의의 데이터 및/또는 네트워크를 통해 요청을 개시하는 모바일 디바이스를 액세스하기 위해 필요한 임의의 데이터를 포함할 수 있다. 예를 들어, 일 실시예에서, 각각의 요청에 대한 매치 요청 데이터는 요청을 개시하는 모바일 디바이스에 대한 NAT 타입 데이터 및/또는 NAT 이동/접속 데이터를 포함한다. 디바이스 접속 속도(100kbps, 1Mbps 등), 접속 타입(예를 들어, 3G, EDGE, WiFi 등), (예를 들어, 지오-로케이션(geo-location) 기법들에 의해 결정되는) 디바이스 위치, 언어(영어, 스페인어 등), 및/또는 사용자 선호도들과 같은 다른 타입들의 요청 데이터가 또한 요청 표(1502) 내에 저장될 수 있다. 요청 데이터는 각각의 모바일 디바이스(120-122)에 의해 결정되고, 각각의 매치 요청을 이용하여 매치메이킹 디스패처(1501)에 전송될 수 있다. 예를 들어, 각각의 모바일 디바이스는 자신의 접속 데이터, 접속 타입, 디바이스 위치 등을 다양한 기법들을 사용하여 결정할 수 있으며, 이들 중 일부는 여기에 기술된다(예를 들어, NAT 이동/접속 데이터를 결정하기 위해 NAT 이동 서버와 통신함, 디바이스 위치를 결정하기 위해 GPS를 이용함, 언어를 결정하기 위해 HTTP 정보를 판독함 등).

도 15에 예시된 바와 같이, 일 실시예에서, 각각의 활성 MSI에는 MSI 표(1503) 내의 행이 할당될 수 있다. 일 실시예에서, 요청 표(1502)에 요청을 추가하는 것에 더하여, 새로운 요청이 도달하는 경우, 디스패처(1501)는 또한 MSI가 이미 해당 요청에 대해 존재하는지의 여부(즉, 동일한 MSI를 가지는 다른 요청들이 이미 수신되었는지의 여부)를 결정하기 위해 MSI 표(1503)를 검사한다. 매칭하는 MSI가 발견되지 않는 경우, 디스패처(1501)는 새로운 요청에 대해 MSI 표(1503) 내에 새로운 엔트리를 생성할 수 있다. 매칭하는 MSI가 발견되는 경우, 디스패처는 전술된 바와 같이 단순히 요청 표(1502)에 새로운 요청을 추가할 수 있다.

요청 표(1502) 및 MSI 표(1503)가 매치메이커 디스패처(1501)에 의해 업데이트되면, 매치메이커 모듈(1510)의 인스턴스(이하 단순히 "매치메이커(1510)"로서 참조됨)는 매치메이킹 동작들을 수행하기 위해 데이터를 패치한다. 다수의 매치메이커 인스턴스들은 매치메이킹 요청들을 수행하기 위해 동시에 실행될 수 있고, 단일 매치메이커(1510)는 다수의 상이한 MSI 그룹들에 대해 다수의 매치메이킹 동작들을 동시에 프로세싱할 수 있다.

일 실시예에서, 매치메이커(1510)가 (예를 들어, MSI 그룹에 대한 매치 동작들을 완료한 이후, 또는 초기화된 이후) 사용가능해지는 경우, 이는 프로세싱할 새로운 MSI를 식별하기 위해 MSI 표(1503)에 질의한다. 도 15에서, MSI 3:1에 대한 매치메이커 ID 필드들 내의 "N/A" 값은 이러한 MSI를 프로세싱하기 위한 책임이 매치메이커에게 아직 할당되지 않았음을 표시한다. 일 실시예에서, 각각의 MSI 엔트리는 타임-스탬핑되고, 매치메이커(1510)는 가장 오래된 타임-스탬프를 가지는 MSI를 선택한다.

일 실시예에서, 매치메이커(1510)가 특정 MSI에 대한 책임을 가정하는 경우, 이는 MSI 표(1503)에서 자신의 매치메이커 ID 코드를 업데이트하고, 해당 MSI에 대한 대여 듀레이션(예를 들어, 5초)을 특정한다. 일 실시예에서, 매치메이커(1510)는 그것이 해당 MSI에 대한 매치들을 프로세싱함에 따라 대여 값을 계속 업데이트한다. 대여 값들은 실패한 매치메이커들(1510)에 할당된 MSI들을 식별하기 위해 사용될 수 있다. 예를 들어, 대여 값이 만료되는 경우, MSI는 MSI가 매치메이커에게 이미 할당되었음을 MSI 표(1503)가 표시한다는 사실에도 불구하고 새로운 매치메이커에 의해 청구될 수 있다.

매치메이커(1510)가 MSI에 대한 책임을 가정하면, 이는 메모리로 해당 MSI와 연관된 요청들을 판독하기 위해 요청 표(1502)에 질의할 수 있다. 매치메이커(1510)는 이후 (예를 들어, 하기에 기술되는 바와 같은) 매칭 기준들의 세트에 따라 사용자들 및 모바일 디바이스들을 매치하기 위한 매칭 동작들을 수행할 수 있다. 매치메이커(1510)는 모바일 디바이스의 매치들이 언제 이루어졌는지를 표시하기 위해 요청 표(1512)를 업데이트할 수 있다. 예를 들어, 매치메이커는 요청표(1512) 내의 MSI 열으로부터 MSI 값들을 제거하고, 매치가 완료되었음을 표시하기 위해 미리 정의된 값을 입력할 수 있다. 추가로, 매치메이커(1510)는 (예를 들어, 다른 참여자들과 통신하기 위해 요구되는 NAT 이동/접속 데이터를 기록함으로써) 해당 참여자와 매치했던 다른 참여자들을 식별하기 위해 각각의 참여자에 대한 "요청 데이터" 필드를 업데이트할 수 있다.

디스패처(1501)는 완료된 매치들을 식별하기 위해 요청 표(1502)를 주기적으로 질의할 수 있다. 완료된 매치를 검출하는 것에 응답하여, 디스패처(1501)는 (예를 들어, 여기서 그리고 공동 계류중인 출원에서 기술되는 푸시 통지 기법들을 사용하여) 매치에 수반되는 모바일 디바이스들에 푸시 통지를 전송할 수 있다. 일 실시예에서, 푸시 통지는 전술된 "티켓" 데이터 구조를 포함한다. 모바일 디바이스들은 이후 전술된 바와 같이 CDX 서비스(110)를 통해 접속 데이터를 교환하기 위해 이들의 티켓들 각각을 사용할 수 있다.

푸시 통지들을 사용하는 것에 추가하여, 일 실시예에서, 모바일 디바이스들(120-122)은 매치가 이루어졌는지의 여부를 결정하기 위해 디스패처(1501)에 주기적으로 질의할 수 있다. 주기적 질의들은 푸시 통지가 모바일 디바이스에 대해 이루어지지 않은 경우 사용가능하다. 그러나, 푸시 아키텍처가 사용되므로, 주기적 질의들은 상대적으로 낮은 레이트로 세팅되고, 이에 의해 매치메이커 서비스(111)에 대한 로드를 감소시킬 수 있다.

도 16은 2개의 모바일 디바이스들 A 및 B가 매치메이커 서비스(111)에 의해 매치되는 방법의 예시적인 실시예를 예시한다. 도 17a-d는 방법이 진행함에 따라 발생할 수 있는 요청 표(1502) 및 MSI 표(1503)에 대한 예시적인 업데이트들을 예시한다.

1601에서, 매치 요청이 모바일 디바이스 A로부터 수신된다. 1602에서, 모바일 디바이스 A의 요청이 요청 표에 입력되고, 도 17a에 예시된 바와 같이, 새로운 MSI 엔트리(MSI 1:1)가 (만약 아직 존재하지 않는 경우) MSI 표에 입력된다. 1603에서, 매치 요청이 모바일 디바이스 B로부터 수신되고, 1604에서, 모바일 B의 매치 요청은 도 17b에 예시된 바와 같이 또한 요청 표에 입력된다.

1605에서, 특정 매치메이커 인스턴스(매치메이커 #N)는 MSI 표를 검사하고, MSI 1:1이 또다른 매치메이커 인스턴스에 의해 청구되지 않음을 검출한다. 대안적으로, 매치메이커는 대여가 만료된 MSI 표 엔트리를 검출할 수 있고, 이는 이전에 MSI에서 작동한 매치메이커가 실패했음을 나타낸다. 일 실시예에서, 대여가 만료된 MSI 엔트리들은 (매치메이커에게 아직 할당되지 않은) 새로운 MSI 엔트리들보다 더 높은 우선순위가 주어진다. 추가로, 일 실시예에서, 상대적으로 더 오래된 MSI 엔트리들은 상대적으로 더 새로운 MSI 엔트리들보다 더 높은 우선순위가 주어질 수 있다. 매치메이커가 MSI를 선택하는 방법과는 무관하게, 매치메이커가 MSI를 선택하는 경우, 도 17c에 예시된 바와 같이(예를 들어, 예시된 예에서 5초의 대여 값을 사용하여), 매치메이커는 자신의 식별자를 추가하고 MSI 엔트리에 대한 새로운 대여 값을 설정한다. 매치메이커는 이후 요청 표에 질의할 수 있고, 해당 MSI를 가지는 요청 표 엔트리들을 메모리로 판독하며 따라서 이들이 프로세싱될 수 있다.

1606에서, 매치메이커는 요청들 각각에 대한 적절한 매치를 선택하기 위해 일련의 매치 동작들을 수행한다. 매치 동작들의 특정 실시예들은 도 18에 대해 하기에 기술된다. 간략하게, 일 실시예에서, "적절한" 매치들을 결정하기 위해 평가되는 변수들은 NAT 타입(예를 들어, 풀 콘, 포트 제한, 대칭 등), 접속 타입(예를 들어, WiFi, 3G, Edge 등), 사용자와 연관된 언어(HTTP 요청 수락-언어 헤더로부터 유도됨), 및 매치 요청들 각각의 에이지를 포함한다. 일반적으로, 매치메이커(1510)는 호환가능한 NAT 타입들(그러나 릴레이 서비스는 때때로 하기에 기술된 바와 같이 사용될 수 있음), 동일한 접속 타입, 및 동일한 언어를 가지는 모바일 디바이스들을 매치시키려고 시도할 수 있다. 일 실시예에서, 매치메이커(1510)는 매치 요청들의 에이지에 기초하여 매칭 요건들에 더욱 자유로울 수 있다(즉, 요청이 더 오래될수록, 매칭 제약들이 더 자유롭게 적용될 것이다).

도 16으로 돌아가면, 1607에서, 매칭 결정에 후속하여, 도 17d에 표시된 바와 같이, 매치메이커(1510)는 매칭이 완료되었음을 표시하도록 요청 표를 업데이트할 수 있다. 업데이트의 일부분으로서, 매치메이커는 또한 모바일 디바이스들 A 및 B에 대한 요청 데이터를 업데이트할 수 있다. 예를 들어, 일 실시예에서, 매치메이커(1510)는 모바일 디바이스 A에 대한 요청 데이터 열에 모바일 디바이스 B의 NAT 이동/접속 데이터를 기록하고 모바일 디바이스 B에 대한 요청 열에 모바일 디바이스 A의 NAT 이동/접속 데이터를 기록한다.

1608에서, 디스패처(1501)는 매치된 요청 엔트리들을 식별하기 위해 요청 표를 통해 판독할 수 있다. 일 실시예에서, 디스패처(1501)가 모바일 디바이스들 A 및 B가 매치됨을 검출하는 경우, 그것은 (전술된 바와 같이 매치메이커에 의해 업데이트된) 요청 데이터를 판독하고, 모바일 디바이스들 A 및 B에 대한 통지를 생성한다. 일 실시예에서, 통지는 암호화된 전술된 "티켓" 데이터 구조이며, 각각의 모바일 디바이스에 대한 NAT 이동/접속 데이터를 포함한다. 이전에 설명된 바와 같이, 일 실시예에서, 푸시 통지 서비스(1050)는 모바일 디바이스들 A 및 B에 통지들을 푸시하도록 사용된다. 추가로, 모바일 디바이스들 A 및 B는 매치가 이루어졌는지의 여부를 결정하기 위해 디스패처(1501)를 주기적으로 폴링(poll)할 수 있다. 이 실시예에서, 폴링 기법은, 일부 이유로 모바일 디바이스들 중 하나에 성공적으로 푸시되지 않은 매치들을 식별하기 위해 상대적으로 느린 레이트로 수행될 수 있다. 폴링 요청 로드를 관리하기 위해 푸시 통지들을 사용하는 것은 매치메이커 서비스(111)에 대한 로드를 현저하게 감소시키며, 이는 그렇지 않은 경우 모바일 디바이스들로부터의 폴링 요청들로 로딩된다.

1608에서 추가적인 매치 요청들이 동일한 MSI에 대해 계류중이라고 결정되는 경우, 매치메이커는 MSI 내의 모바일 디바이스들/사용자들을 계속 매치시킬 수 있다. 1610에서, 매치메이커는 MSI 표(1503) 내의 대여 값을 리셋할 수 있다. 1611에서, 추가적인 매치들이 수행되고, 요청 표는 (전술된 바와 같이) 업데이트된다. 1612에서, 추가 매치들이 요청 표로부터 판독되고, 추가적인 모바일 디바이스들이 (전술된 바와 같이) 업데이트된다. 어떠한 추가적인 매치 요청들도 MSI에 대해 계류 중이지 않은 경우, 1609에서, MSI 엔트리는 (예를 들어, 디스패처 및/또는 매치메이커로부터의 삭제 커맨드를 통해) MSI 표로부터 제거된다.

도 18은 모바일 디바이스들/사용자들 사이에서 매치들을 수행하기 위한 방법의 일 실시예를 예시한다(도 16에서 동작 1606). 1801에서, (예를 들어, 특정 애플리케이션/버킷 조합에 대한) 모든 현재 MSI 요청들은 쌍들로 배열된다. 1802에서, 각각의 쌍 사이의 매치 "피트(fit)"가 평가되고, 1803에서, 쌍들은 내림차순 피트에 의해 분류된다. "피트"는 NAT 타입(예를 들어, 풀 콘, 포트 제한, 대칭 등), 접속 타입(예를 들어, WiFi, 3G, Edge 등), 사용자와 연관된 언어(HTTP 요청 수락-언어 헤더로부터 유도됨), 및 매치 요청들 각각의 에이지를 포함하지만 이에 제한되지 않는 복수의 다양한 변수들에 기초하여 평가된다. 매치메이킹에 고려될 수 있는 다른 변수들은 (예를 들어, 특정 위치 내의 사용자들을 매칭하기 위한 시도를 가지는) 모바일 디바이스들 각각의 위치; (예를 들어, 사용자 및/또는 애플리케이션에 의해 특정되는) 최소 및/또는 최대 플레이어 요건들; MSI 내에 포함되는 사용자들 중 하나 이상이 "친구들"인지 또는 (예를 들어, 매칭하는 "친구들" 또는 이전 지인들에 대한 선호도를 가지고) 이전에 P2P 접속으로 진입했는지의 여부; 및 애플리케이션에 대한 사용자 경험을 포함한다(예를 들어, 멀티-플레이어 게임에 대해, 사용자들 각각의 점수판(leaderboard) 순위들은 매칭하는 유사한-경험을 가진 사용자들에 대한 선호도를 가지고 고려될 수 있다).

아래 표 A에서 표시되는 바와 같이, 일 실시예에서, "적합도(fitness")의 평가는 0.0 및 1.0 사이의 수치이다. 부동 소수점 값을 사용하는 것은 각각의 기준에 대한 적합도의 정규화를 허용한다. 부동 소수점 연산을 회피하기 위해, 비정규화된 정수값들이 적절한 평가에 사용될 수 있으며, 따라서 적합도 값들이 비교될 수 있다.

일 실시예에서, 모든 기준들은 이들이 호환가능하거나(1.0의 정규화 값을 가짐) 호환가능하지 않은(1.0 미만의 정규화된 값을 가짐) 바이너리 피트를 가진다. 이들은 (하기에 기술되는 바와 같이) 피트가 에이지에 따라 변경될 수 있는 요구되는 기준들로 간주될 수 있다. 위치가 변수로서 추가되면, 최상의 피트는 요구되는 기준을 매치하는 가장 가까운 플레이어를 가지는 것일 수 있다.

일 실시예에서, 피트는 위의 기준들 각각에 대해 (정규화된 가중 * 에이지 인자 값)의 합계와 동일하다. 에이지 인자 값은 1의 값으로 시작하여, 미리 결정된 시간 기간이 경과한 이후 증가할 수 있다. 이는 이후 더 많은 시간이 경과함에 따라 계속 증가할 수 있다(예를 들어, 특정 양만큼 주기적으로 증가함). 일 실시예에서, 전술된 바와 같은 에이지 인자 값의 사용 대신, 에이지 임계들이 하기에 기술되는 바와 같이 설정될 수 있다. 접속 타입 및 언어와 같은 특정 변수들의 정규화된/가중된 값들은 (심지어 이들이 매치하지 않는 경우라도) 특정 에이지 임계들 위에 적용될 수 있다.

일 실시예에서, 한 쌍의 요청들 A 및 B 사이의 "피트"는 B를 가진 A 및 A를 가진 B의 피트의 평균이다. 또한, 각각의 인자에 대해 B를 가진 A의 피트는 A의 에이지에 기초하여 조정될 수 있다(그 역도 성립한다). 일 실시예에서, 1.0의 피트는 호환가능한 매치에 대해 요구될 수 있다. 이는 A 및 B가 NAT 호환성, 접속 타입 및 언어가 매치하는 경우(1.0의 정규화된 값을 초래함) 또는 A 및/또는 B가 에이징되어 위의 변수들(예를 들어, 접속 타입 및 언어) 중 일부가 (에이징된 인자 값 초과 또는 임계들 미만을 사용하여) 효과적으로 무시되는 경우에만 매치할 것임을 의미한다.

에이지 임계들은 위의 표 B에서 설명되는 바와 같이 설정될 수 있다. 각각의 에이지 임계가 경과됨에 따라(즉, 요청이 특정 임계보다 더 오래됨에 따라), 에이지 인자 값은 연속적으로 더 큰 값들(예를 들어, 1.5, 2.0 등)로 증가될 수 있다. 대안적으로, 또는 추가적으로, 상이한 에이지 임계들이 경과함에 따라, 특정 변수들에 대한 가중된 값들(예를 들어, 하기에 설명되는 바와 같은 접속 타입 및 언어와 같은)이 매치 결정에 추가될 수 있다.

일 실시예에서, 표 B에 특정된 요청 에이지 제한들은 주어진 MSI에 대한 매치 플로우 레이트에 따라 조정된다. 일 실시예에서, 플로우 레이트는 특정 시간 단위마다(예를 들어, 매 10초마다, 매분마다 등) 수행되는 매치들의 수로서 특정된다. 따라서, 플로우 레이트는 특정 MSI 세트가 얼마나 붐비는지(busy)에 대한 표시를 제공한다. 일 실시예에서, 세트가 더 붐빌수록, 조기의 성공적 매치의 확률을 증가시키고 매치메이커에 대한 로드를 감소시키기 위해, 위의 임계들 각각이 위의 표 B에서 더 낮게 설정될 수 있다. 또한, 주어진 MSI 세트에 대한 로드가 (예를 들어, 매치 값에 대해 추정된 시간의 형태로) 최종 사용자에게 제공될 수 있고, 따라서, 최종 사용자는 특히 붐비는 멀티-플레이어 게임에 입장하도록 시도할지의 여부를 선택할 수 있다. 로드 값은 푸시 통지의 형태로 사용자에게 제공될 수 있다.

이제 표 A로부터의 변수들 각각을 참조하면, 일 실시예에서, NAT 호환성은 도 14에 도시된 NAT 호환성 차트(1400)로부터 결정된다. 2개의 NAT들이 이 차트에 기초하여 호환가능한 것으로 결정되는 경우, NAT 호환성 가중이 적용될 수 있다.

접속 타입은 표 C로서 위에서 도시된 것과 같은 차트를 사용하여 평가될 수 있다. 이 예에서, 디바이스들 A 및 B의 접속 타입이 (동일한 접속 타입들이 만족되는 셀들 내에서 1.0에 의해 표시되는 바와 같이) 동일한 경우, 표 A로부터의 가중된 접속 타입 값은 적합도 결정에 포함될 수 있다. 위에서 언급된 바와 같이, 요청들 각각에 대한 에이지가 접속 타입 결정에 영향을 주기 위해 사용될 수 있다. 예를 들어, 일 실시예에서, 접속 타입에 대한 피트 값은 임계 1, 2 및 3에서의 에이지들에 대해 표 C에서 행렬을 사용하여 선택된다. 임계 4 또는 그 이상에서의 에이지들에 대해, 접속 타입은 (심지어, 비-매칭 접속 타입들에 대해서) 1.0으로 설정될 수 있고, 대응하는 가중된 접속 타입 값이 적용될 수 있다. 일부 실시예들에서 접속 "타입"이 사용되지만, 접속 속도가 결정되고 접속 타입과 함께 또는 접속 타입 대신 사용될 수 있다. 예를 들어, 어떤 특정된 범위들 내의 접속 속도들은 "호환가능한" 것으로 간주될 수 있다(예를 들어, 0-100kbps; 100-500kbps; 500-1000kbps, 1000-1500kbps 등). 여기서 논의된 매칭 변수들 중 임의의 것이 또한 매치 피트 계산에 대한 가중들로서 적용되고 전술된 바와 같이 에이지를 가질 수 있다.

일 실시예에서, 플레이어 언어는 선호도 q 팩터를 가지는 하나 이상의 언어들을 포함할 수 있는 HTTP 요청 수락-언어 헤더로부터 유도될 수 있다. 디스패처는 가장 선호되는 언어를 추출하고, 이 정보를 매치메이커에게 전달할 수 있다. 일 실시예에서, 표 A로부터의 가중된 언어 값은, 언어들이 동일한 경우 1.0으로 설정되거나, 이들이 동일하지 않은 경우 0.0으로 설정된다. 그러나, 일 실시예에서, 가중된 언어 값은, 에이지가 특정 임계를 초과하는 경우(예를 들어, 에이지가 표 B에서 임계 2 또는 그 위에 있는 경우), 언어들이 상이하더라도 적용될 수 있다.

일 실시예에서, 매치는 호환불가능한 NAT 타입들을 가지는 두 사용자들 사이에 이루어질 수 있다. 예를 들어, 매치메이커가 특정 MSI에 대해 사용자들을 매칭하는 것에 어려움을 가지는 경우, 특정 시간 기간 이후, 전술된 기법들을 사용하여 릴레이 서비스(1051)를 통해 접속들을 라우팅할 수 있다. 이러한 방식으로, 릴레이 서비스(1051)는 압력 밸브로서 작용하여, 호환불가능한 NAT 타입들에도 불구하고 에이지 매치들이 발생하게 한다. 릴레이 서비스(1051)는 또한 하나 이상의 실패한 매치 시도들을 검출하는 것에 응답하여 사용될 수 있다. 이러한 실시예에서, 모바일 디바이스에 의해 제출되는 각각의 매치 요청은 하나 이상의 비성공적 매치들이 이전에 시도되었는지의 여부에 대한 표시를 포함할 수 있다.

다양한 추가적인 매치 기준들이 평가될 수 있고, 제한이 아닌 예시로서, 매치들을 요청하는 사용자들 중 임의의 사용자가 친구들인지의 여부에 대한 표시를 포함하는 매치 피트 결정의 일부분으로서 가중 값이 제공될 수 있다. 예를 들어, 매치메이커(1510)는 매치 피트 계산에 대해 "친구들" 가중을 적용함으로써 "친구들"인 사용자들에 대한 임의의 요청들을 매치하려고 시도할 수 있다. 유사하게, 친구들의 친구들이 또한 (예를 들어, 2 또는 그 이상의 분리 정도를 가지고) 가중될 수 있다. 추가로, 플레이어는 특정 게임에 대해 다른 플레이어들을 등급화(rate)할 수 있고, 매치메이커는 (상대적으로 더 높은 등급들을 가지는 해당 플레이어들과 사용자를 매치시키고 낮은 등급들을 가지는 플레이어들과 사용자를 매치하지 않으려는 경향을 가지고) 매치를 수행할 시에 해당 등급들을 평가할 수 있다. 또한, 사용자의 접속의 레이턴시가 (예를 들어, 단일 핑(ping) 동작을 사용하여) 평가되고 매치메이킹 결정의 일부분으로서 사용될 수 있다.

플레이어들을 매치시키기 위해 사용되는 또다른 변수는 디바이스 타입일 수 있다. 예를 들어, 매치메이커(1510)는 유사한 디바이스 타입들(예를 들어, iPad, iPod, iTouch, iPhone, RIM Blackberry 등)을 가지는 플레이어들을 매치하려고 시도할 수 있다. 추가적인 변수들은 사용자의 점수판 순위, 현재 위치, 현재 주거, 연령, 성별을 포함할 수 있고, 유사한 게임 컬렉션들이 유사하게 매치 결정을 위해(즉, 유사한 기준들을 가지는 해당 사용자들 사이의 매치들을 선호하려는 경향이 있는 많은 경우들에서) 평가될 수 있다. 마지막으로, 사용자들이 오직 적절한 MSI들을 가지고, 그리고 동일한 연령의 다른 사용자들을 가지고 매치됨을 보장하기 위해 부모 제어들이 매치메이커(1510)에 의해 평가될 수 있다.

매치메이커 서비스(111)는 데이터 서비스(100) 내에서 관리되는 하나 이상의 데이터베이스들(예를 들어, 도 19에 대해 하기에 기술되는 데이터 베이스(1920)를 참조하라)로부터 위의 변수들 중 임의의 것을 검색할 수 있다. 예를 들어, 사용자의 친구 데이터는 친구 서비스 데이터베이스로부터 액세스될 수 있고, 각각의 사용자의 연령, 성별, 게임 컬렉션 등과 같은 다른 정보는 하나 이상의 다른 데이터베이스들(예를 들어, 사용자 프로파일, 게임 데이터베이스, 점수판 데이터베이스 등)로부터 액세스될 수 있다. 일 실시예에서, 여기서 기술된 서비스들 모두에는 매치메이커 결정들을 수행하기 위해 사용되는 다양한 상이한 타입들의 사용자/디바이스 데이터 모두를 저장하기 위한 동일한 중앙 데이터베이스(또는 데이터베이스들의 그룹)에 대한 액세스가 제공된다.

몇몇 특정 예들이 위에 제공되지만, 본 발명의 기본 원리들은 매치에 대한 적합도 레벨을 결정하기 위한 변수들의 임의의 특정 세트에 제한되지 않는다는 점이 이해될 것이다. 일 실시예에서, 여기서 기술되는 시스템 및 방법에 대해 실행될 애플리케이션들을 설계하는 애플리케이션 프로그래머들은 상이한 MSI 기준을 사용하여 요청들을 매치시키기 위한 그리고/또는 그룹화하기 위한 자신의 고유한 기준 세트를 특정할 수 있다.

도 18의 방법을 다시 참조하면, 각각의 쌍 사이의 매치 "피트"가 결정되면, 1803에서, 쌍들은 내림차순 피트에 의해(예를 들어, 리스트의 최상부에서 가장 높은 피트를 가지는 쌍들을 가지고) 분류된다. 1804에서, "매치 세트들"은 특정된 임계 위의 가장 높은 피트 값들을 가지는 해당 쌍들을 시드(seed)로 한다. 전술된 바와 같이, "임계" 값은 표 A에서 위에 도시되 1.0의 정규화된 값으로 설정될 수 있다. 1805에서, 새로운 예상 파트너들이 특정 임계를 초과하는 매치 세트 내의 현재 멤버들 중 하나 또는 모두와의 피트 값들을 가지는 매치 세트에 추가된다. 예를 들어, 매치 세트가 초기에 A 및 B를 시드로 한 경우, A-C 및/또는 B-C의 피트 값이 특정 임계를 초과한다면, C가 매치 세트에 추가될 수 있다. 일 실시예에서, 오직 단일 매치 피트가 예상 당사자에 대한 임계를 초과하는 경우, 해당 당사자는 매치 세트에 추가될 수 있다(즉, 필요한 경우, 적절한 매치 피트를 가지는 하나의 당사자를 통해 해당 당사자가 모든 당사자들과 통신할 수 있을 것이기 때문이다). 하나 이상의 새로운 당사자들이 매치 세트에 추가되면, 1806에서 매치에 대한 사이즈 요건들이 만족되었다고 결정되는 경우, 1807에서 매치 결과들이 (예를 들어, 전술된 바와 같이 요청 표(1502)를 업데이트하고 통지들을 전송함으로써) 저장되고 보고된다. 일 실시예에서, 단일 매치 요청은 (예를 들어, 하기에 설명된 바와 같이, 매치 요청이 초대 시퀀스에 후속하는 경우) 다수의 사용자들을 나타낼 수 있다. 이러한 경우, 사이즈 요건들은 각각의 매치 요청에 의해 표현되는 사용자들의 수에 기초하여 평가된다. 사이즈 요건들이 만족되지 않는 경우, 프로세스는 1805로 리턴하고, 새로운 당사자(즉, 특정 임계를 초과하는 세트의 현재 멤버들 중 하나 이상과의 매치 피트를 가지는 당사자)가 매치 세트에 추가된다.

1808에서, 매치된 요청들은 매치메이커(1510)에 의해 프로세싱되는 요청들의 현재 세트로부터 제거된다. 1809에서, 다음의 시드되는 매치 세트가 선택되고 프로세스는 추가적인 매칭을 위해 1804로 리턴한다. 순차적 프로세스로서 도 18에 예시되었지만, 다수의 시드되는 매치 세트들이 동시에 프로세싱될 수 있는 동시에 여전히 본 발명의 기본 원리들에 따른다는 점에 유의해야 한다.

별도의 서비스들로서 전술되었지만, 매치메이커 서비스(111) 및 초대 서비스(112)는 P2P 사용자들을 접속시키도록 함께 동작할 수 있다. 예를 들어, 일 실시예에서, 제1 사용자는 온라인 세션에 하나 이상의 친구들을 초대하고, 하나 이상의 추가적인 사용자들과의 매치를 요청할 수 있다(예를 들어, 멀티플레이어 비디오 게임에 대해 친구 "Bob"을 초대하고 3명의 추가적인 플레이어들을 매치한다). 이러한 경우, 초대 서비스(112)는 제1 사용자 및 제1 사용자의 친구(들)를 접속시키기 위해 제1 사용자의 초대 요청을 초기에 프로세싱할 수 있다. 초대 요청의 결과들(예를 들어, 성공적인 P2P 접속)은 이후 사용자의 모바일 디바이스에 다시 보고될 수 있다. 매치메이커 서비스(111)는 이후 추가적인 플레이어들을 요청하는 제1 사용자의 모바일 디바이스로부터(또는 일 실시예에서, 직접 초대 서비스로부터 또는 제1 사용자의 친구들로부터) 매치 요청을 수신할 수 있다. 그 응답으로, 매치메이커 서비스(111)는 (전술된 바와 같이) 제1 사용자의 요청과 동일한 MSI를 가지는 하나 이상의 다른 매치 요청들과 제1 사용자를 매치할 수 있다. 매치 요청은 오직 제1 사용자의 매치 기준을 포함할 수 있거나, 제1 사용자의 그리고 제1 사용자의 친구의 매칭 기준(예를 들어, NAT 타입, 접속 타입, 언어, 위치 등)을 포함할 수 있다. 일 실시예에서, 제1 사용자의 친구들 중 하나 이상이 또다른 매치된 사용자와의 직접 P2P 접속을 설정할 수 없는 경우, 제1 사용자의 친구들과의 매치된 사용자의 접속은 (예를 들어, 접속을 위한 프록시로서 제1 사용자의 모바일 디바이스를 사용하여) 제1 사용자의 데이터 프로세싱 디바이스를 통해 설정될 수 있고, 그리고/또는 (전술된 바와 같이) 릴레이 서비스가 사용자들을 접속시키기 위해 사용될 수 있다.

일 실시예에서, 제1 사용자는 (전술된 바와 같이) 매치메이킹 서비스에 의해 하나 이상의 사용자들과 초기에 매치될 수 있고, 이후, 제1 사용자는 제1 사용자 및 매치된 사용자들과의 온라인 세션에 참여할 하나 이상의 친구들을 초대할 수 있다. 이 실시예에서, 사용자의 정보 및 매치된 사용자의 정보(예를 들어, NAT/접속 데이터, 사용자 ID들, 푸시 토큰들 등) 모두가 (전술된 바와 같이) 초대 서비스를 통해 초대된 사용자들과 교환될 수 있다. 본 발명의 기본 원리들은 매칭이 초대에 선행하여 발생하는지의 여부, 또는 초대가 매칭에 선행하여 먼저 발생하는지의 여부와는 무관하게 동일하게 유지된다.

공동 온라인 애플리케이션들에 대한 애플리케이션 프로그래밍 인터페이스를 가지는 애플리케이션 프레임워크

도 19에 예시된 바와 같이, 본 발명의 일 실시예는 하나 이상의 애플리케이션들(1911)과 인터페이싱하기 위한 애플리케이션 프로그래밍 인터페이스("API")(1910) 및 복수의 네트워크 서비스들(1901-1903)과 통신하기 위한 서비스-측 API(1910)를 가지는 미리 정의된 프레임워크(1912)를 가지는 모바일 디바이스(120)의 상황 내에 구현된다. 도 19에 도시된 바와 같이, 네트워크 서비스들(1901-1903)은 동일한 온라인 데이터 서비스(100)에 의해 설계되고 그리고/또는 관리될 수 있다(그러나, 이러한 구성이 요구되지 않는다). P2P 게임 애플리케이션들과 같은 애플리케이션들(1911) 및 다른 타입들의 공동 온라인 애플리케이션들은 API(1910)에 대한 호출들을 수행함으로써 API(1910)를 통해 네트워크 서비스들(1901-1903)에 액세스하도록 설계될 수 있다. 애플리케이션들(1911)의 설계는 프레임워크(1912) 및 네트워크 서비스들(1901-1903)의 개발자에 의해 제공되는 소프트웨어 개발 키드("SDK")를 사용하여 용이해질 수 있다. 프레임워크(1912) 및 API들(1910, 1913)의 더욱 특정한 구현예가 도 20에 대해 하기에 설명된다.

예시된 바와 같이, 서비스들 각각에는 서비스들에 의해 사용되는 데이터를 저장하기 위한 데이터베이스(1920)에 대한 액세스가 제공될 수 있다. 일 특정한 예는 (전술된) 매치메이커 서비스(111)에 의해 사용되는 데이터베이스(1512)이다. 다른 예들은 점수판 데이터를 저장하기 위한 점수판 데이터베이스, 친구 상태 기록들을 저장하기 위한 친구 서비스 데이터베이스, 사용자 프로파일 데이터를 저장하기 위한 프로파일 데이터베이스 및 온라인 게임들에 관련된 데이터를 저장하기 위한 게임 데이터베이스를 포함할 수 있다. 임의의 타입의 데이터베이스(예를 들어, MySQL, Microsoft SQL 등)가 사용될 수 있지만, 일 특정 실시예에서, Berkley DB 및/또는 MZBasic DB와 같은 키/값 데이터베이스가 사용될 수 있다. 데이터베이스들은 저장 영역 네트워크(SAN) 또는 다른 저장소 구성 내의 많은 수의 대용량 저장 디바이스들(예를 들어, 하드 드라이브들)에 걸쳐 확산될 수 있다.

결과적으로, 특정 서비스가 전술된 바와 같이 데이터를 프로세싱 및/또는 저장하는 경우, 데이터는 데이터베이스(1920) 내에 저장될 수 있다. 그러나, 일부 서비스들은 데이터베이스를 이용하지 않을 수 있다. 예를 들어, 전술된 바와 같이, 초대 서비스(112)는 무상태 서비스로서 구현될 수 있고, 따라서, 데이터베이스(1920) 내에 데이터를 저장하도록 요구되지 않을 수 있다(그러나, 이러한 구현예는 본 발명의 기본 원리들에 따라 여전히 가능하다).

API(1913)는 예를 들어, 애플리케이션층에서의 HTTPS 및 네트워크층에서의 TCP/IP 또는 UDP/IP를 포함하는 임의의 적절한 네트워크 프로토콜 스택을 사용하여 네트워크 서비스들(1901-1903)과 통신하고 정보를 교환하도록 설계될 수 있다. SOAP과 같은 HTTP 또는 HTTPS를 통한 원격 프로시져 호출(RPC)-기반 프로토콜이 사용될 수 있고 그리고/또는 대표 상태 전송(REST) 프로토콜이 사용될 수 있다. 또한, 서비스들은 예를 들어, Xserve 또는 Unix, Linux 또는 Apache 소프트웨어 플랫폼을 실행하는 유사한 서버들을 포함하는 임의의 컴퓨팅 플랫폼 상에서 구현될 수 있다. 일 특정 실시예에서, 플랫폼은 Linux 상에서 구현되는 Web 오브젝트들을 포함한다. 이전의 예들은 단순히 예시의 목적으로 제공된다. 본 발명의 기본 원리들은 서비스들에 애플리케이션들을 링크시키기 위한 임의의 특정 메커니즘 또는 네트워크 프로토콜들의 어떠한 세트에도 제한되지 않는다.

도 20은 본 발명의 일 실시예에서 무선 디바이스(120) 상에서 구현될 수 있는 애플리케이션 프로그래밍 인터페이스(API)들(2001a-b)을 포함하는 더욱 상세화된 소프트웨어 아키텍처를 예시한다. 이러한 실시예가 멀티플레이어 게임 프레임워크(2000)의 상황 내에 기술되지만, 본 발명의 기본 원리들은 게임 구현예에 제한되지 않는다. 예를 들어, 도 20에 도시된 소프트웨어 아키텍처는 게임들이 아닌 다양한 공동 애플리케이션들(예를 들어, 공동 대화, 다중-당사자 공동 오디오/비디오 등)을 지원하기 위해 사용될 수 있다.

도 20에 도시된 아키텍처에서, 게임 프레임워크(2000)가 여기서 기술된 다양한 다중-당사자 특징들 및 P2P 특징들을 지원하기 위해 제공된다. 일 실시예에서, 게임 프레임워크(2000)는 모바일 디바이스의 운영 체제(2005) 상에서 실행하도록 설계된다. 예를 들어, 모바일 디바이스(120)가 iPhone, iPad, 또는 iPod Touch인 경우, 운영 체제(2005)는 본 출원의 양수인에 의해 설계되는 모바일 운영 체제인 iPhone OS일 수 있다.

게임 프레임워크(2000)는 공개 애플리케이션 프로그래밍 인터페이스(API)(2001b) 및 개인 또는 "보안" API(2001a)를 포함할 수 있다. 일 실시예에서, 여기서 설계된 다양한 게임-관련 특징들을 제공하기 위해 설계되는 게임 센터 애플리케이션(2031)은 공개 API(2001b) 및 개인 API(2001a) 모두에 호출을 수행할 수 있는 반면, 다른 애플리케이션들(2030)(예를 들어, 제3자들에 의해 설계된 애플리케이션들)에는 오직 공개 API(2001b)에 대한 액세스가 제공된다. 예를 들어, 모바일 디바이스(120)의 설계자는 제3자 개발자에 의한 침해를 회피하기 위해 공개 API(2001b) 밖의 잠재적으로 민감한 정보(예를 들어, 친구 요청들, 친구 리스트들 등)를 포함하는 특정 API 기능들을 유지하기를 원할 수 있다. 그러나, 보안 API(2001a) 및 공개 API(2001b) 모두는 모바일 디바이스 상의 모든 애플리케이션들에 의해 액세스가능한 단일 API로 병합될 수 있다(즉, 별도의 공중 및 개인 컴포넌트들로의 API의 분리는 본 발명의 기본 원리들에 따르기 위해 요구되지 않는다). 표기 "API 2001"는 공개 API(2001b) 및/또는 개인 API(2001a)에서 발견될 수 있는 동작들을 참조하기 위해 하기에 때때로 사용된다.

게임 센터 애플리케이션(2031)의 일 실시예는 발명자들이 Marcel Van Os and Mike Lampell인, 2010년 4월 7일에 출원된, 출원인 관리번호 4860.P9127USP1, 일련 번호 61/321,861의, Systems and Methods for Providing a Game Center라는 명칭의 공동 계류중인 출원(이하, "게임 센터 특허 출원")에 기술되며, 이는 본 출원의 양수인에게 할당되고 여기에 참조로 포함된다. 간략하게, 게임 센터 애플리케이션(2031)은 멀티-플레이어 게임들을 통해 탐색하고; 새로운 게임들을 구매하고; 게임들에 관련된 정보(예를 들어, 점수판 정보, 달성, 친구 정보 등)을 검색하고; 게임을 하기 위해 친구에게 연락하고; 다른 사용자들과의 게임 매치들을 요청하고; 그리고 특정 사용자들을 초대하기 위한 게임-중심 그래픽 사용자 인터페이스(GUI)를 포함한다. 게임 센터 애플리케이션(2031)에 의해 수행되는 다양한 다른 기능들이 위에서 참조된 게임 센터 특허 출원에 기술된다. 게임 센터 기능들 중 일부는 게임 프레임워크(2000)에 의해 제공되고, 공개 API(2001b)를 통해 다른 애플리케이션들(2030)에 대해 액세스 가능해질 수 있다.

일 실시예에서, 게임 프레임워크(2000)에 의해 노출되는 API(2001)는 모바일 디바이스(120)에 대한 멀티 플레이어 공동 게임들을 설계하는 프로세스를 간략화한다. 특히, 일 실시예에서, API(2001)는 개발자들로 하여금 멀티-플레이어 P2P 게임 세션에 대한 사용자들을 접속시키는 상대적으로 복잡한 프로세스를 인보킹하기 위해 단순한 API 호출을 수행하게 한다. 예를 들어, 초대와 같은 단순한 API 호출(플레이어 B ID, 버킷 ID)은 전술된 상세화된 초대 시퀀스를 개시하기 위해 API(2001)로부터 인보킹될 수 있다. 유사하게, 매치와 같은 API 호출(플레이어 A ID, 버킷 ID)은 전술된 상세화된 매치메이커 시퀀스를 개시하기 위해 API(2001)로부터 인보킹될 수 있다. 초대 및 매치 기능들은 때때로 일반적으로 "P2P 접속 기능들"로서 여기에 참조된다. 일 실시예에서, 게임 프레임워크(2000)는 (하기에 더욱 상세하게 기술되는 바와 같이) 이들 API 호출들에 응답하여 초대 및 매치메이킹 동작들을 관리하기 위해 요구되는 프로그램 코드를 포함한다. 실제 API 동작들이 위에서 설명된 것들과는 다소 상이한 데이터 포맷들을 가질 수 있다는 점에 유의해야 한다(그러나, 이들은 게임 프레임워크(2000)에 의해 수행되는 유사한 동작들을 초래할 수 있다). 본 발명의 기본 원리들은 API 기능들을 특정하기 위한 어떠한 특정한 포맷에도 제한되지 않는다.

다양한 다른 타입들의 게임-관련 트랜잭션들 및 정보가 또한 게임 센터(2031) 및 다른 애플리케이션들(2030) 대신 게임 프레임워크(2000)에 의해 관리될 수 있다. 이러한 정보 중 일부는 게임 센터 특허 출원에 기술된다. 제한이 아닌 예를 들어, 이러한 정보는 각각의 게임에 대해 최상 스코어들을 달성한 해당 사용자들에 관련된 "점수판" 정보 및 특정 게임-특정적 성과들을 완료한 사용자들을 식별하는 "성과" 정보를 포함할 수 있다. 각각의 애플리케이션 개발자는 각각의 게임 애플리케이션(2030)에 대한 자신의 고유한 "성과들"의 세트를 특정할 수 있다(예를 들어, 완료된 레벨들 1-3; 5분 내에 완료된 레벨 1; 레벨 당 50 이상 처치; 20 플래그 녹 다운 등).

게임 프레임워크(2000)는 또한 게임 센터(2031)의 상황 내에서 사용자의 친구 데이터를 관리하기 위한 그리고 친구 데이터를 통합하기 위한 프로그램 코드 및 다른 게임 애플리케이션들(2030)을 포함할 수 있다. 예를 들어, 사용자가 게임 센터(2031) 내의 특정 게임에 대한 링크를 선택하는 경우, 각각의 사용자의 친구들에 관련된 정보(예를 들어, 점수판 상의 친구들의 순위, 친구들의 성과, 사용자가 자신의 친구들 각각과 게임을 한 결과 등)가 해당 게임에 대해 디스플레이될 수 있다. 일 실시예에서, 게임 프레임워크(2000)의 API(2001)는, 발명자들이 Amol Pattekar, Jeremy Werner, Patrick Gates, 및 Andrew H. Vyrros인, 2010년 4월 7일에 출원된, 출원인 관리 번호 4860.P9240, 일련 번호 61/321,848인 Apparatus and Method for Efficiently Managing Data in a Social Networking Service라는 명칭의 공동 계류 중인 출원(이하, "친구 서비스 출원")에 기술된 것과 같은 친구 서비스에 의해 관리되는 친구 데이터에 액세스하기 위한 기능들을 포함하며, 이는 본 출원의 양수인에게 양도되며, 여기에 참조로 포함된다.

도 20에 예시된 바와 같이, 일 실시예에서, 게임 데몬(2020)은 서비스들의 제1 세트(2050)에 대해 게임 프레임워크(2000)를 인터페이싱할 수 있고, 게임 서비스 컴포넌트(2010)는 서비스들의 제2 세트(2051)에 대해 게임 프레임워크(2000)를 인터페이싱할 수 있다. 예를 들어, 서비스들의 제1 세트(2050)는 초대 서비스(112), 매치메이커 서비스(111), 및 전술된 릴레이 서비스(1051) 및 위에서 참조된 친구 서비스 출원에 기술된 친구 서비스를 포함할 수 있다. 게임 데몬(2020)을 통해 액세스될 수 있는 다른 서비스들은 (점수판 데이터를 제공하는) 점수판 서비스; (게임들 각각에 관련된 통계들 및 다른 데이터 및 게임을 구매할 능력을 제공하는) 게임 서비스; (모바일 디바이스의 사용자를 인증하기 위한) 사용자 인증 서비스; 및/또는 (사용자 선호도와 같은 사용자 프로파일 데이터를 저장하기 위한) 사용자 프로파일 서비스를 포함한다. 게임 서비스 컴포넌트(2010)를 통해 액세스되는 서비스들의 제2 세트(2051)는 전술된 접속 데이터 교환(CDX) 서비스(110) 및 NAT 이동 서비스들(290-291)을 포함할 수 있다. 예시의 목적으로 도 20에 별도의 컴포넌트들로서 예시되었지만, 게임 데몬(2020) 및 게임 서비스 모듈(2010)은 실제로 게임 프레임워크(2000)의 컴포넌트들일 수 있다. 일 실시예에서, 게임 데몬(2020 및 2010)은, 일 실시예에서 개인 API인(즉, 제3자 개발자들에게 공개되지 않는) 미리 정의된 API를 통해 네트워크 서비스들(2050-2051) 각각과 통신한다.

일 실시예에서, 게임 데몬(2020)은 매치메이커 서비스(111), 초대 서비스(112), 및 HTTPS 프로토콜을 사용하는 다른 서비스들(2050)과 통신할 수 있는 반면, 게임 서비스 모듈(2010)은 UDP 소켓들과 같은 상대적으로 경량 프로토콜을 사용하여 CDX 서비스(110) 및 NAT 이동 서비스들(290-291)과 통신할 수 있다. 그러나, 이전에 언급된 바와 같이, 다양한 다른 네트워크 프로토콜들이 사용될 수 있는 동시에 본 발명의 기본 원리에 여전히 따를 수 있다.

또한, 도 20에 예시된 바와 같이, 게임 데몬(2020)은 특정 서비스들(2052)(예를 들어, 초대 서비스 및 매치메이커 서비스)에 의해 생성된 푸시 통지들(2052)을 수신할 수 있는 반면, 다른 타입들의 푸시 통지들(2053)(예를 들어, 새로운 친구 요청들과 같은 친구 서비스 통지들)은 게임 센터에 의해 직접 수신될 수 있다. 일 실시예에서, 이들 푸시 통지들(2053)은 사용자의 민감한 데이터가 제3 자 애플리케이션 개발자들에 의해 설계되는 애플리케이션들(2030)에 대해 액세스가능하지 않음을 보장하기 위해 게임 센터(2031)에 직접 제공된다.

도 11에서 위에서 설명된 게임 초대 예들로 돌아가면, 모바일 디바이스 A 상의 애플리케이션(2030)이 모바일 디바이스 B의 사용자를 초대하기 위해 게임 프레임워크(2000)의 API(2001b)에 대한 초대 호출을 수행하는 경우(예를 들어, 초대(플레이어 B ID/ 버킷 ID)), 게임 프레임워크(2000)는 모바일 디바이스 A의 게임 데몬(2020)에 초대 요청을 전달할 수 있다. 게임 데몬(2020)은 이후 초대 요청을 제출하기 위해 초대 서비스(112)와 통신할 수 있다. 초대 서비스(112)는 이후 모바일 디바이스 B의 게임 데몬(2020)에 초대를 푸시하기 위해 (전술된 바와 같은) 푸시 통지 서비스(1050)를 사용할 수 있다. 모바일 디바이스 B의 게임 데몬(2020)은 이후 초대가 송신된 게임이 모바일 디바이스 B 상에 설치되어 있는지의 여부를 결정하기 위해 모바일 디바이스 B의 게임 프레임워크(2000)와 통신할 수 있다. 설치되어 있는 경우, 게임 프레임워크(2000)는 애플리케이션(2030)을 트리거링하고 그리고/또는 초대의 시각적 통지를 생성할 수 있다. 애플리케이션이 설치되지 않은 경우, 게임 프레임워크(2000)는 (예를 들어, 게임 센터(2031) GUI를 통해) 게임을 구매하기 위한 공급을 가지고 모바일 디바이스 B의 사용자에 대한 초대의 시각적 통지를 트리거링할 수 있다. 대안적으로, 시각적 통지는 모바일 디바이스(120) 상에서 실행하는 푸시 통지 데몬(미도시됨)에 의해 생성될 수 있다. 모바일 디바이스 B의 사용자가 게임을 구매하는 경우, 초대 시퀀스가 구매에 후속하여 계속될 수 있다. 모바일 디바이스 B의 사용자가 초대 요청을 수락하는 경우, 모바일 디바이스 B의 게임 프레임워크(2000)는 이후 초대 요청을, 초대 서비스(112)에 응답할 수 있는 자신의 게임 데몬(2020)에 전달할 수 있다.

도 11을 상기하면, 호환성 검사(1106)는 모바일 디바이스들 A 및 B의 NAT 타입이 호환가능함을 결정한다. 따라서, 1108에서, 모바일 디바이스 A의 게임 데몬(2020)은 모바일 디바이스 B의 수락을 (예를 들어, 예에서 푸시 통지를 통해) 수신할 수 있고, 일 실시예에서 게임 프레임워크(2000)에 수락을 전달한다. 이러한 스테이지에서, 모바일 디바이스 A의 게임 프레임워크(2000)는 모바일 디바이스 B가 (API(2001)를 통해) 수락한 요청 애플리케이션(2030)을 통지할 수 있거나, 또는 디바이스들이 성공적으로 접속될 때까지 요청 애플리케이션(2030)을 통지할 것을 대기할 수 있다. 어느 경우든, 게임 프레임워크(2000)는, 일 실시예에서 모바일 디바이스 B와의 접속 데이터 교환을 개시할 수 있는 게임 서비스 모듈(2010)에 접속 요청을 전달할 수 있다. 특히, 게임 서비스 모듈이 CDX 서비스(110)를 사용하여 모바일 디바이스 B에 모바일 디바이스 A의 접속 데이터를 전달할 수 있다(예를 들어, 도 11 내의 트랜잭션들(1111 및 1112)을 참조하라). 전술된 바와 같이, 이러한 통신은 보안 "티켓" 데이터 구조를 사용하여 UDP 접속으로서 구현될 수 있다.

도 12를 상기하면, 호환성 검사(1106)가 모바일 디바이스들 A 및 B의 NAT 타입들이 호환가능하지 않다고 결정하는 경우, 릴레이 서비스(1051)는 디바이스들 사이의 접속을 제공하기 위해 사용될 수 있다. 결과적으로, 모바일 디바이스 B의 게임 데몬(2020)은 초대 서비스로부터 릴레이 응답(1203)을 수신할 수 있고(도 12에 도시됨), 모바일 디바이스 A의 게임 데몬(2020)은 (푸시 통지 서비스(1050)를 통해) 초대 서비스로부터 릴레이 응답(1205)을 수신할 수 있다. 모바일 디바이스들 A 및 B의 게임 데몬들(2020)은 구성 데이터를 검색하기 위해 1206 및 1207에서 릴레이 서비스와 통신할 수 있다. 1210에서, 모바일 디바이스 B의 게임 데몬(2020)은 모바일 디바이스 A로부터 릴레이 업데이트 데이터를 수신하고, 1213에서, 모바일 디바이스 A의 게임 데몬(2020)은 모바일 디바이스 B로부터 릴레이 업데이트 데이터를 수신한다.

도 11 및 12에 도시된 프로세스들의 최종 결과는 모바일 디바이스들 A 및 B가 서로의 접속(직접, P2P 접속 또는 릴레이 접속)을 설정한다는 것이다. 일 실시예에서, 성공적인 접속을 검출할 시에, 게임 프레임워크(2000)는 API 호출을 사용하여 접속을 요청한 애플리케이션(2030)을 통지할 수 있다(예를 들어, 접속됨(플레이어 A ID, 플레이어 B ID)). 모바일 디바이스들 A 및 B는 이후 설정된 접속을 사용하여 특정 게임 또는 다른 공동 애플리케이션(2030)을 플레이할 수 있다.

따라서, API(2001)로부터 상대적으로 단순한 호출에 응답하여, 트랜잭션의 복잡한 시리즈는 모바일 디바이스들 A 및 B 사이의 P2P 또는 릴레이 접속을 설정하기 위해 게임 프레임워크(2000)에 의해 관리될 수 있다. 일 실시예에서, 게임 프레임워크(2000)는 모바일 디바이스들 A 및 B를 접속시키기 위한 동작들의 시퀀스를 수행하고, 이후 결과들을 요청 애플리케이션(2030)에 제공하고, 이에 의해 API 호출의 상세항목들을 애플리케이션 설계자에게 투명하게 둔다. 따라서, 애플리케이션 설계자는 네트워크 상에서 모바일 디바이스들 A 및 B를 접속시키는 방법, 또는 디바이스들 사이의 통신을 가능하게 하기 위해 요구되는 다양한 다른 기능들을 수행하는 방법을 이해하도록 요구되지 않으며, 이에 의해 애플리케이션 설계 프로세스를 간략화한다.

유사한 방식으로, 게임 프레임워크(2000)는 도 2a-b에 대해 전술된 바와 같이 매치메이커 서비스(111)를 사용하여 모바일 디바이스 A 및 다른 참여자들 사이의 매치를 설정할 수 있다. 이 예에서, 애플리케이션(2030)은 매치(플레이어 A ID, 게임/번들 ID)와 같은 API(2001)에 대한 단순한 호출을 수행할 수 있다. 그 응답으로, 게임 프레임워크(2000)는 매칭 및 접속 데이터 교환 동작들을 관리할 수 있다. 매칭 동작들 및/또는 P2P 접속들이 완료된 경우, 게임 프레임워크(2000)는 결과들을 다시 애플리케이션(2030)에 제공한다.

예를 들어, 도 2b에서, 게임 프레임워크(2000)는 접속 데이터 교환(CDX) 서비스(110) 및 NAT 이동 서비스들(290-291)과 통신하기 위해 게임 서비스 모듈(2010)을 사용할 수 있고, 매치메이커 서비스(111)와 통신하기 위해 게임 데몬을 사용할 수 있다. 매치가 이루어지면, 모바일 디바이스 A의 게임 데몬(2020)은 229에서 티켓 A를 수신하고, 게임 프레임워크(2000)는 게임 서비스 모듈(2010)을 통해 접속 데이터 교환을 수행하기 위해 이러한 정보를 사용한다. 예를 들어, 232에서, 이는 NAT 이동 서비스(290)를 통해 자신의 고유한 접속 데이터를 요청할 수 있고, 이후 CDX 서비스(110)를 통해 233-234에서 자신의 접속 데이터를 교환할 수 있다. 237 및 240에서, 모바일 디바이스 A의 게임 서비스 모듈(2010)은 각각 모바일 디바이스들 B 및 C에 대한 접속 데이터를 수신한다. 이들 교환들에 후속하여, 게임 서비스 모듈(2010)은 241에서 P2P 접속들을 설정하고, 게임 프레임워크(2000)는 접속 프로세스가 API 통지를 사용하여 완료되었음을 애플리케이션(2030)에 통지한다(예를 들어, 매치 완료(플레이어 B ID, 플레이어 C ID)). 애플리케이션은 이후 설정된 P2P 접속을 사용하여 실행할 수 있다.

일부 실시예들에서, 사용자에게는 현재 "온라인"으로서 등록된 다른 친구들과 게임을 하기 위한 옵션이 주어질 수 있다. 이러한 경우, 특정 친구들이 온라인이라는 통지는 (게임 센터(2031)에 의해 직접 수신되는) 푸시 통지들(2052) 또는 푸시 통지들(2053)을 통해 제공될 수 있다. 게임 센터(2031) 및/또는 애플리케이션들(2030)은 이후 사용자에게 통지들을 제공하고, 사용자에게 하나 이상의 선택된 온라인 친구들과 플레이하기 위한 옵션을 제공할 수 있다. 그러나, 여기서 기술된 초대 시퀀스가 온라인 통지들이 제공되는지의 여부와는 무관하게 작용할 것이라는 점에 유의해야 한다. 일 실시예에서, 사용자의 온라인 상태는 게임 데몬(2020)에 의해(예를 들어, 위에서 언급된 친구 서비스에 의해 또는 별도의 "존재" 서비스에 의해) 액세스가능한 서비스에 의해 모니터링될 수 있다.

게임 프레임워크(2000)의 일 실시예는 사용자가 알려지지 않은 매치된 참여자들의 그룹과 게임을 할 하나 이상의 친구들을 초대할 수 있는 조합 초대/매치메이킹 동작을 제공한다. 예를 들어, 게임이 4명의 플레이어들을 요구하고, 제1 사용자가 게임을 할 제2 사용자를 초대하는 경우, 초대 서비스(112)는 초기에 제1 사용자 및 제2 사용자를 접속시킬 수 있고, 매치메이커 서비스(111)는 이후 제1 사용자 및 제2 사용자를 2명(또는 그 이상의) 다른 플레이어들과 매치시킬 수 있다. 이러한 실시예에서, 게임 프레임워크(2000)는 제1 사용자 및 제2 사용자를 접속시키기 위해 전술된 초대 시퀀스들을 초기에 수행할 수 있다. 일 실시예에서, 제1 사용자 및 제2 사용자가 성공적으로 접속되면, 게임 프레임워크(2000)는 다른 사용자들을 식별하고 접속시키기 위해 매치메이킹 시퀀스들을 구현할 수 있다. 위에서 언급된 바와 같이, 일 실시예에서, 매치메이킹 서비스에 의해 적용되는 매치 기준은 제1 및 제2 사용자 모두를 포함할 수 있다(예를 들어, 제1 및 제2 사용자 모두의 NAT 타입들, 접속 타입들, 언어 등). 대안적으로, 두 사용자들 중 한 명의 기준은 매칭 결정을 수행하기 위해 평가될 수 있다.

사용자들 모두가 접속되면, 게임 프레임워크(2000)는 API(2001)를 통해 접속을 요청한 애플리케이션(2030)에 접속 결과들을 제공할 수 있다. 다시 한번, 애플리케이션(2030)에 의한 상대적으로 단순한 API 호출에 응답하여, 게임 프레임워크(2000)는 디바이스들 각각을 접속시키기 위해 복잡한 트랜잭션들의 세트에 진입한다. 디바이스들이 성공적으로 접속되면, 게임 프레임워크(2000)는 요청 애플리케이션(2030)에 다시 결과들을 제공한다.

도 20에 예시된 바와 같이, 게임 프레임워크(2000)는 사용자와 다른 게임 참여자들 사이의 통신을 임시로 저장하기 위한 통신 버퍼(2003)를 포함할 수 있다. 통신은 예를 들어, 텍스트, 오디오 및/또는 비디오 통신을 포함할 수 있다. 게임 프레임워크(2000)는 각각의 애플리케이션(2030)의 요건들에 기초하여 버퍼(2003)를 설정할 수 있다. 예를 들어, 상대적으로 더 큰 버퍼(2003)는 느린 네트워크 접속을 가지고 오디오/비디오 통신을 위해 요구될 수 있다. 일 실시예에서, 각각의 애플리케이션(2030)은 (예를 들어, 버퍼(사이즈) 커맨드를 사용하여) API(2001)를 통해 특정 사이즈의 통신 버퍼를 설정하기 위한 명시적인 요청을 수행할 수 있다. 대안적으로, 게임 프레임워크(2000)는 각각의 애플리케이션의 통신 요건들에 기초하여 버퍼를 자동으로 생성할 수 있다. 예를 들어, 게임 프레임워크(2000)는 텍스트, 오디오 및/또는 비디오가 지원될 필요가 있는지의 여부에 기초하여 특정 버퍼 사이즈를 선택할 수 있다.

일 실시예에서, 통신 버퍼(2003)는 모든 P2P 접속들이 사용자들 사이에 설정되기 전에 통신 스트림을 임시로 저장할 수 있다. 예를 들어, 초대 서비스(112) 또는 매치메이커 서비스(111)가 사용자들 각각을 식별한 이후, 그러나 CDX 서비스(110)가 접속 데이터 교환 동작들을 완료하기 전에, 각각의 사용자는 접속된 프로세스에서 다른 게임 참여자들을 통지받을 수 있다. 이 스테이지에서, 모바일 디바이스(120)의 사용자는 다른 참여자들에게 텍스트, 오디오 및/또는 비디오 통신 스트림들을 전송할 수 있다. 게임 프레임워크(2000)는 아직 접속되지 않은 해당 참여자들을 위해 통신 버퍼(2003) 내에 통신 스트림들을 저장할 것이다. 게임 프레임워크(2000)는 이후, 각각의 디바이스에 대한 접속이 완료됨에 따라, 버퍼(2003)로부터 텍스트, 오디오 및/또는 비디오를 전송할 수 있다.

일 실시예에서, 게임 데몬(2020)은 네트워크 트래픽을 감소시키기 위해, 서비스들(2050) 각각에 대해 지속되는 데이터를 캐싱하기 위한 캐시(2021)를 포함한다. 예를 들어, 사용자의 친구 리스트, 점수판 데이터, 달성 데이터, 존재 데이터, 및 프로파일 데이터는 캐시 관리 정책에 의해 특정되는 바와 같이 캐시(2021)에 저장될 수 있다. 일 실시예에서, 캐시 관리 정책은 데이터가 저장되는 각각의개별 서비스에 의해 구동된다. 결과적으로, n개의 상이한 서비스들에 대해, n개의 상이한 캐시 관리 정책들이 캐시(2021)에 적용될 수 있다. 추가로, 캐시 관리 정책이 서비스들에 의해 구동되므로, 이는 현재 네트워크 및/또는 서버 로드 조건들에 기초하여 동적으로 수정될 수 있다. 예를 들어, 서비스가 심하게 로딩되는 시간 기간들 동안(예를 들어, 크리스마스, 신제품 출시일 등), 서비스는 상대적으로 덜 빈번한 캐시 업데이트들(예를 들어, 매 12시간마다의 업데이트들)을 가지고 캐시 관리 정책을 동적으로 특정할 수 있다. 반면, 서비스가 심하게 로딩되지 않는 시간 기간들 동안, 서비스는 더 빈번한 캐시 업데이트들(예를 들어, 매 ½ 시간, 매 1시간, 매 2시간마다의 업데이트들 등)을 이용하여 캐시 정책을 특정할 수 있다.

일 실시예에서, 캐시 관리 정책은 캐시(2021)에 저장된 특정 데이터 기록들에 대한 TTL(time-to-live) 값을 사용하여 특정된다. 데이터 기록이 자신의 TTL 값을 경과하여 캐시에 저장되면, 이후 해당 데이터는 "오래된(stale)" 것으로 간주되고, 해당 데이터에 대한 로컬 요청은 해당 데이터와 연관된 서비스에 직접 포워딩될 수 있다. 일 실시예에서, 요청은 데이터의 현재 버전을 식별하는 ID 코드를 포함한다. ID 코드가 서비스에 대한 ID 코드를 매치하는 경우, 데이터는 여전히 유효하며, 업데이트될 필요가 없다. 응답은 이후 캐시 내의 데이터가 현재 것임을 표시하는 서비스로부터 다시 송신될 수 있고, 데이터 레코드에 대한 TTL 값이 리셋될 수 있다.

전술된 바와 같은 캐시 관리 정책의 사용에 추가하여, 일 실시예에서, 특정 타입들의 데이터에 대한 캐시 업데이트들은 푸시 통지 서비스(1050)를 사용하여 모바일 디바이스에 푸시될 수 있다. 예를 들어, 사용자의 친구 리스트에 대한 또는 사용자의 친구들의 현재 온라인 상태에 대한 변경들은 사용자의 모바일 디바이스(120)에 동적으로 푸시될 수 있다. 푸시 통지는 이후 서비스에 의해 푸시되는 데이터의 관련 부분을 포함하도록 캐시(2021)를 업데이트할 수 있는 게임 데몬(2020)에 의해 수신될 수 있다(즉, 해당 서비스와 연관된 캐시 내의 모든 데이터의 업데이트가 요구되지 않을 수 있다). 반면, 일부 통지들은 캐시의 전체 컨텐츠(또는 푸시를 수행하는 서비스와 연관된 캐시의 적어도 일부분)를 덮어쓰도록 게임 데몬(2020)에 명령할 수 있다.

캐시(2021)를 업데이트하기 위해 푸시를 이용하는 해당 서비스들은 상대적으로 높은 TTL 값들을 선택할 수 있는데(그리고/또는 TTL 값들을 설정하지 않을 수 있는데) 왜냐하면 이들이 캐시(2021) 내에 저장된 데이터를 업데이트하기 위해 통지들을 푸시할 능력을 가지기 때문이다. 일 실시예에서, 각각의 서비스는 푸시 통지 캐시 업데이트를 트리거링할 수 있는 이벤트들의 세트를 특정한다. 예를 들어, 캐시 업데이트 이벤트들은 친구의 온라인 상태, 새로운 친구 요청, 친구 요청 수락, 친구끊기(de-friend) 동작, 친구가 특정 게임을 하고 있다는 표시, 친구에 의해 도달된 게임 성과, 특정 점수판의 톱 10에 대한 업데이트, 또는 캐시 업데이트를 보장하기 위해 충분히 중요한 것으로 간주되는 임의의 다른 이벤트들을 포함할 수 있다. 이러한 방식으로 캐시(2021)를 업데이트하기 위한 푸시 통지들의 사용은 네트워크 및 서비스 로드를 감소시킬 수 있는데, 왜냐하면, 푸시 업데이트들을 통해, 모바일 디바이스 및 서비스 사이의 주기적 폴링이 요구되지 않기 때문이다.

게임 프레임워크(2000)의 일 실시예는 사용자의 국가 및/또는 지리적 위치에 기초하여 최종 사용자에게 제시되는 데이터를 고유하게 포맷한다. 예를 들어, 현재 날짜, 시간 및 통화 값들과 같은 값들은 상이한 국가들 및 위치들에서의 사용자들에 대해 상이하게 제시될 수 있다. 예를 들어, 미국에서, 데이터 포맷은 [달 일, 연도](예를 들어, 4월 25일, 2010년)일 수 있는 반면, 다른 국가들에서, 날짜 포맷은 [일 달, 연도](예를 들어, 25일 4월, 2010년)일 수 있다. 유사하게, 미국 및 일부 다른 국가들에서 시간을 표현할 시에, AM/PM 표기가 사용될 수 있고, 콜론(:)이 시와 분 사이에 사용될 수 있다(예를 들어, 3:00 PM). 반면, 많은 다른 국가들은 AM/PM 표기를 사용하지 않고 그리고/또는 시와 분 사이에 콤마를 사용한다(예를 들어, 15,00). 또다른 예로서, 세계의 많은 지역들은 미터 시스템을 사용하는 반면, 세계의 일부 지역들은 사용하지 않는다(예를 들어, 미국). 이들이 단순히 본 발명의 특정 실시예들에 의해 사용될 수 있는 예시적인 예들이라는 점에 유의해야 한다. 본 발명의 기본 원리들은 어떠한 특정 데이터 포맷들의 세트에도 제한되지 않는다.

일 실시예에서, 이들 상이한 데이터 포맷들은 점수판 데이터, 성과 데이터, 친구 데이터, 및/또는 게임 프레임워크(2000)에 의해 프로세싱되는 임의의 다른 데이터를 디스플레이하는 동안 선택될 수 있다. 게임 프레임워크(2000)는 다양한 방식들로 사용자의 국가 및/또는 지리적 위치를 결정할 수 있다. 예를 들어, 일 실시예에서, 이러한 정보는 단순히 사용자의 프로파일 데이터에 제공되며 그리고/또는 사용자의 셀룰러 서비스 제공자에 의해 결정될 수 있다. 사용자의 위치는 또한, 예를 들어, 글로벌 위치탐색 시스템(GPS) 추적을 사용하여 결정될 수 있다.

지리적 위치 및/또는 국가와 관련되지 않은 다른 타입들의 데이터 포맷이 또한 게임 프레임워크(2000)에 의해 관리될 수 있다. 예를 들어, 점수판 데이터를 디스플레이하는 경우, 최저 스코어가 점수판의 최상부 또는 최하부에 사용자를 위치시켜야 하는지의 여부를 아는 것이 중요하다. 일부 게임들(예를 들어, 골프, 추적, 레이싱, 스키 등)에 대해, 더 낮은 수가 더 양호한 성능을 표시하는 반면, 다른 게임들(예를 들어, 미식축구, 야구 등)에서, 더 높은 수가 더 양호한 성능을 표시한다. 따라서, 일 실시예에서, 애플리케이션(2030)은 API(2001)를 통해 사용될 스코어의 타입을 특정한다(예를 들어, "오름차순" 또는 "내림차순"). 게임 프레임워크(2000)는 이후 스코어를 디스플레이하기 위해 적절한 라벨들 및 포맷의 세트를 사용할 수 있다.

게임 프레임워크(2000)의 일 실시예는 또한 사용자와 사용자의 친구들 사이의 관계에 기초하여 사용자 데이터를 필터링한다. 예를 들어, 본 발명의 일 실시예는 "상세화된" 뷰, "친구들" 뷰, 및 "공개" 뷰를 허용한다. 일 실시예에서, 상세화된 뷰는 데이터(즉, 사용자의 개인 정보)를 소유하는 사용자에게 사용가능하고; 친구들 뷰는 사용자의 친구들에게 사용가능하고; 공개 뷰는 모든 다른 사용자들에게 사용가능하다.

예를 들어, 공개 뷰는 단순히 각각의 사용자 연관된 "가명", 가명에 의해 플레이되는 게임 및 연관 스코어들, 및 게임들이 플레이된 날짜/시간을 포함할 수 있다. 이러한 정보는 이후 게임 센터(2031)를 통해 디스플레이될 수 있는 공개 점수판을 채우기 위해 게임 프레임워크(2000)에 의해 사용될 수 있다.

친구들 뷰는 일반적 뷰로부터의 모든 정보 뿐만 아니라, 몇몇을 들자면, 예를 들어, 사용자에 의해 소유된 게임들; 사용자에 의해 플레이되는 게임들; 사용자의 성과 및 스코어; 사용자가 가지는 친구들의 수; 해당 친구들의 신원; 사용자의 아바타를 식별하는 URL 및/또는 사용자의 온라인 상태를 포함한 사용자의 친구들 사이에서 공유될 임의의 추가 정보를 포함할 수 있다. 일 실시예에서, "친구들" 뷰는 친구들과 공유될 정보의 디폴트 세트를 제공하지만, 최종 사용자는 이러한 디폴트 구성을 조정하고, 각각의 개별 친구 또는 친구들의 그룹들(예를 들어, 동료들, 가족 구성원들, 대학교/고등학교 친구들 등)에 의해 공유될 정보의 타입들을 특수성을 가지고 특정할 수 있다.

"상세화된" 뷰는 "공개" 및 "친구들" 뷰들로부터의 모든 정보 뿐만 아니라 최종 사용자를 대신하여 다양한 서비스들(2050)에 의해 관리되는 임의의 다른 정보를 포함할 수 있다. 예를 들어, 이는 사용자의 모든 프로파일 데이터; 사용자의 유니버설 고유 식별자("UUID")(때때로 여기서 "플레이어 ID"로서 참조됨); 플레이어 이름; 가명들; 게임의 수 및 게임의 신원; 사용자의 친구들; 사용자의 모든 성과들 등을 포함할 수 있다.

일부 환경들에서, 애플리케이션(2030)은 오직 각각의 사용자의 플레이어 ID와 같은 각각의 사용자에 관련된 소량의 정보만을 요구할 수 있다. 예를 들어, 일 실시예에서, 매치가 요청되는 경우, 게임 프레임워크(2000)는 초기에 오직 각각의 플레이어 ID만을 요구할 수 있다. 매치들이 매치메이커 서비스에 의해 이루어짐에 따라(위 내용 참조), 게임 프레임워크(2000)는 (예를 들어, 친구 서비스와의 통신을 통해 그리고/또는 사용자의 로컬 친구 데이터를 조사(interrogate)함으로써) 매치된 사용자들 중 임의의 사용자가 친구들인지의 여부를 결정할 수 있다. 만약 그러하다면, 게임 프레임워크(2000)는 추가적인 사용자 데이터를 검색하고, 해당 데이터를 임의의 매치된 친구들에게 제공할 수 있다. 이러한 방식으로, 게임 프레임워크(2000)는 사용자들의 신원 및 사용자들 각각 사이의 관계에 기초하여 정보를 필터링한다.

일 실시예에서, 게임 프레임워크(2000)는, 제1 사용자 및 제2 사용자가 친구 관계를 가지지 않는 경우, 초기에 두 사용자들 사이에 공개 뷰를 제공한다. 그러나, 일 실시예에서, 게임 프레임워크(2000)는 제1 사용자로 하여금 (예를 들어, 제2 사용자의 가명을 사용하여) 제2 사용자에게 친구 요청을 송신하게 한다. 친구 요청이 수락되는 경우, 게임 프레임워크(2000)는 사용자들 각각에 추가적인 정보(예를 들어, 디폴트 "친구" 뷰)를 제공할 것이다.

상이한 API 실시예들

일 실시예에서 구현되는 API는 상이한 소프트웨어 컴포넌트(이하, API 호출 소프트웨어 컴포넌트")로 하여금 하나 이상의 기능들, 방법들, 프로시져들, 데이터 구조들, 및/또는 API 구현 소프트웨어 컴포넌트에 의해 제공되는 다른 서비스들을 액세스 및 사용하게 하는 소프트웨어 컴포넌트(이하 "API 구현 소프트웨어 컴포넌트")에 의해 구현되는 인터페이스이다. 예를 들어, API는 (제3자 개발자일 수 있는) API 호출 소프트웨어 컴포넌트의 개발자로 하여금 API 구현 소프트웨어 컴포넌트에 의해 제공되는 특정된 특징들을 조정(leverage)하게 한다. 하나의 API 호출 소프트웨어 컴포넌트가 존재할 수 있거나, 또는 하나 초과의 이러한 소프트웨어 컴포넌트가 존재할 수 있다. API는 컴퓨터 시스템 또는 프로그램 라이브러리가 소프트웨어 애플리케이션으로부터 서비스들에 대한 요청들을 지원하기 위해 제공하는 소스 코드 인터페이스일 수 있다. API는 데이터가 메모리 내에 어떻게 레이아웃되는지에 대한 명시적인 저 레벨 기술이라기 보다는 애플리케이션이 구축되는 경우 해석되거나 컴파일링될 수 있는 프로그래밍 언어의 견지에서 특정될 수 있다.

API는 API 구현 소프트웨어 컴포넌트의 특정된 특징들을 액세스 및 사용하는 경우 API 호출 소프트웨어 컴포넌트들이 사용하는 언어 및 파라미터들을 정의한다. 예를 들어, API 호출 소프트웨어 컴포넌트는 API에 의해 노출되는 하나 이상의 API 호출들(때때로 함수 또는 방법 호출들로서 참조됨)을 통해 API 구현 소프트웨어 컴포넌트의 특정된 특징들을 액세스한다. API 구현 소프트웨어 컴포넌트는 API 호출 소프트웨어 컴포넌트로부터의 API 호출에 응답하여 API를 통해 값을 리턴할 수 있다. API가 API 호출의 신택스 및 결과(예를 들어, API 호출을 인보킹하는 방법 및 API 호출이 수행하는 것)를 정의하는 반면, API는 통상적으로 API 호출이 API 호출에 의해 특정되는 기능을 달성하는 방법을 노출하지 않는다. 다양한 함수 호출들 또는 메시지들은 호출 소프트웨어(API 호출 소프트웨어 컴포넌트) 및 API 구현 소프트웨어 컴포넌트 사이의 하나 이상의 애플리케이션 프로그래밍 인터페이스들을 통해 전송된다. 함수 호출들 또는 메시지들을 전달하는 것은 함수 호출들 또는 메시지들을 발행하고, 개시하고, 인보킹하고, 호출하고, 수신하고, 리턴하고, 응답하는 것을 포함할 수 있다. 따라서, API 호출 소프트웨어 컴포넌트가 호출을 전송할 수 있고, API 구현 소프트웨어 컴포넌트가 호출을 전송할 수 있다.

예를 들어, API 구현 소프트웨어 컴포넌트(2010) 및 API 호출 소프트웨어 컴포넌트는 운영 체제, 라이브러리, 디바이스 드라이버, API, 애플리케이션 프로그램, 또는 다른 소프트웨어 모듈일 수 있다(API 구현 소프트웨어 컴포넌트 및 API 호출 소프트웨어 컴포넌트는 서로 동일하거나 상이한 타입의 소프트웨어 모듈일 수 있다는 점이 이해되어야 한다). API 호출 소프트웨어 컴포넌트는 네트워크 상에서 API를 통해 API 구현 소프트웨어 컴포넌트와 통신하는 원격 소프트웨어 컴포넌트(즉, API 구현 소프트웨어 컴포넌트와 상이한 데이터 프로세싱 시스템 상의) 또는 로컬 소프트웨어 컴포넌트(즉, API 구현 소프트웨어 컴포넌트와 동일한 데이터 프로세싱 상의)일 수 있다. API 구현 소프트웨어 컴포넌트가 또한 API 호출 소프트웨어 컴포넌트로서 동작할 수 있으며(즉, 이는 상이한 API 구현 소프트웨어 컴포넌트에 의해 노출되는 API에 대해 API 호출들을 수행할 수 있음), API 호출 소프트웨어 컴포넌트가 또한 상이한 API 호출 소프트웨어 컴포넌트에 노출되는 API를 구현함으로써 API 구현 소프트웨어 컴포넌트로서 동작할 수 있다는 점이 이해되어야 한다.

API는 상이한 프로그래밍 언어들로 기록된 다수의 API 호출 소프트웨어 컴포넌트들로 하여금 API 구현 소프트웨어 컴포넌트와 통신하게 할 수 있지만(따라서, API가 API 구현 소프트웨어 컴포넌트 및 API 호출 소프트웨어 컴포넌트 사이에 호출들 및 리턴들을 변환(translate)하기 위한 특징들을 포함할 수 있지만), API는 특정 프로그래밍 언어의 견지에서 구현될 수 있다.

도 21은 API(2120)를 구현하는 API 구현 소프트웨어 컴포넌트(2110)(예를 들어, 운영 체제, 라이브러리, 디바이스 드라이버, API, 애플리케이션 프로그램, 또는 다른 소프트웨어 모듈)를 포함하는 API 아키텍처의 일 실시예를 예시한다. API(2120)는 API 호출 소프트웨어 컴포넌트(2130)에 의해 사용될 수 있는 API 구현 소프트웨어 컴포넌트의 하나 이상의 함수들, 방법들, 클래스들, 오브젝트들, 프로토콜들, 데이터 구조들, 포맷들 및/또는 다른 특징들을 특정한다. API(2120)는 API 구현 소프트웨어 컴포넌트 내의 함수가 API 호출 소프트웨어 컴포넌트로부터 파라미터들을 수신하는 방법 및 함수가 API 호출 소프트웨어 컴포넌트에 결과를 리턴하는 방법을 특정하는 적어도 하나의 호출 컨벤션을 특정할 수 있다. API 호출 소프트웨어 컴포넌트(2130)(예를 들어, 운영 체제, 라이브러리, 디바이스 드라이버, API, 애플리케이션 프로그램, 또는 다른 소프트웨어 모듈)는 API(2120)에 의해 특정되는 API 구현 소프트웨어 컴포넌트(2110)의 특징들을 액세스 및 사용하기 위해 API(2120)를 통해 API 호출들을 수행한다. API 구현 소프트웨어 컴포넌트(2110)는 API 호출에 응답하여 API 호출 소프트웨어 컴포넌트(2130)에 API(2120)를 통해 값을 리턴할 수 있다.

API 구현 소프트웨어 컴포넌트(2110)가 추가적인 함수들, 방법들, 클래스들, 데이터 구조들, 및/또는 API(2120)를 통해 특정되지 않으며 API 호출 소프트웨어 컴포넌트(2130)에 사용가능하지 않은 다른 특징들을 포함할 수 있다는 점이 이해될 것이다. API 호출 소프트웨어 컴포넌트(2130)가 API 구현 소프트웨어 컴포넌트(2110) 와 동일한 시스템 상에 존재할 수 있거나, 원격으로 위치될 수 있으며, 네트워크 상에서 API(2120)를 사용하여 API 구현 소프트웨어 컴포넌트(2110)를 액세스한다는 점이 이해되어야 한다. 도 21은 API(2120)와 상호작용하는 단일 API 호출 소프트웨어 컴포넌트(2130)를 예시하지만, API 호출 소프트웨어 컴포넌트(2130)와 상이한 언어들(또는 동일한 언어)로 기록될 수 있는 다른 API 호출 소프트웨어 컴포넌트들이 API(2120)를 사용할 수 있다는 점이 이해되어야 한다.

API 구현 소프트웨어 컴포넌트(2110), API(2120), 및 API 호출 소프트웨어 컴포넌트(2130)는, 머신(예를 들어, 컴퓨터 또는 다른 데이터 프로세싱 시스템)에 의해 판독가능한 형태로 정보를 저장하기 위한 임의의 메커니즘을 포함하는 머신-판독가능한 매체에 저장될 수 있다. 예를 들어, 머신-판독가능한 매체는 자기 디스크들, 광학 디스크들, 랜덤 액세스 메모리, 판독 전용 메모리, 플래시 메모리 디바이스들 등을 포함한다.

도 22("소프트웨어 스택")의, 예시적인 실시예에서, 애플리케이션들은 몇몇 서비스 API들을 사용하여 서비스들 1 또는 2에, 그리고 몇몇 운영 체제(OS) API들을 사용하여 OS에 호출들을 수행할 수 있다. 서비스들 1 및 2는 몇몇 OS API들을 사용하여 OS에 수행할 수 있다.

서비스 2가 2개의 API들을 가지며, 이들 중 하나(서비스 2 API 1)가 애플리케이션 1로부터 호출들을 수신하고 애플리케이션 1에 값들을 리턴시키며, 다른 하나(서비스 2 API 2)는 애플리케이션 2로부터 호출들을 수신하고 애플리케이션 2에 값들을 리턴시킨다는 점에 유의한다. 서비스 1(예를 들어, 소프트웨어 라이브러리일 수 있음)은 OS API 1에 대한 호출들을 수행하고 OS API 1로부터 리턴된 값들을 수신하고, 서비스 2(예를 들어, 소프트웨어 라이브러리일 수 있음)는 OS API 1 및 OS API 2 모두에 대한 호출들을 수행하고 OS API 1 및 OS API 2 모두로부터 리턴된 값들을 수신한다. 애플리케이션 2는 OS API 2에 대한 호출들을 수행하고 OS API 2로부터 리턴된 값들을 수신한다.

예시적인 데이터 프로세싱 디바이스들

도 23은 본 발명의 일부 실시예들에서 사용될 수 있는 예시적인 컴퓨터 시스템을 예시하는 블록도이다. 도 23이 컴퓨터 시스템의 다양한 컴포넌트들을 예시하지만, 컴포넌트들을 상호접속시키는 임의의 특정 아키텍처 또는 방식이 본 발명과 밀접한 관련을 가지지 않음에 따라 이것이 이러한 상세항목들을 나타내도록 의도되지 않는다는 점이 이해되어야 한다. 더 적은 컴포넌트들 또는 더 많은 컴포넌트들을 가지는 다른 컴퓨터 시스템들이 또한 본 발명과 함께 사용될 수 있다는 점이 이해될 것이다.

도 23에 예시된 바와 같이, 데이터 프로세싱 시스템의 형태인 컴퓨터 시스템(2300)은 프로세싱 시스템(2320), 전원(2325), 메모리(2330) 및 비휘발성 메모리(2340)(예를 들어, 하드 드라이브, 플래시 메모리, 상변화 메모리(PCM) 등)와 커플링되는 버스(들)(2350)를 포함한다. 버스(들)(2350)는 당해 기술분야에 공지된 바와 같이 다양한 브리지들, 제어기들 및/또는 어댑터들을 통해 서로 접속될 수 있다. 프로세싱 시스템(2320)은 메모리(2330) 및/또는 비휘발성 메모리(2340)로부터 명령(들)을 검색하고, 전술된 바와 같은 동작들을 수행하도록 명령들을 실행할 수 있다. 버스(2350)는 위의 컴포넌트들을 함께 상호접속시키며, 또한 해당 컴포넌트들을 선택적 도크(2360), 디스플레이 제어기 & 디스플레이 디바이스(2370), 입력/출력 디바이스들(2380)(예를 들어, NIC(네트워크 인터페이스 카드), 커서 제어(예를 들어, 마우스, 터치스크린, 터치 패드 등), 키보드 등), 및 선택적 무선 트랜시버(들)(2390)(예를 들어, 블루투스, WiFi, 적외선 등)에 상호접속시킨다.

도 24는 본 발명의 일부 실시예들에서 사용될 수 있는 예시적인 데이터 프로세싱 시스템을 예시하는 블록도이다. 예를 들어, 데이터 프로세싱 시스템(2400)은 핸드헬드 컴퓨터, 개인 디지털 정보 단말(PDA), 모바일 전화, 휴대용 게임 시스템, 휴대용 미디어 플레이어, 모바일 전화를 포함할 수 있는 태블릿 또는 핸드헬드 컴퓨팅 디바이스, 미디어 플레이어, 및/또는 게임 시스템일 수 있다. 또다른 예로서, 데이터 프로세싱 시스템(2400)은 네트워크 컴퓨터 또는 또다른 디바이스 내의 임베디드 프로세싱 디바이스일 수 있다.

본 발명의 일 실시예에 따라, 데이터 프로세싱 시스템(2400)의 예시적인 아키텍처가 전술된 모바일 디바이스들에 대해 사용될 수 있다. 데이터 프로세싱 시스템(2400)은 하나 이상의 마이크로프로세서들 및/또는 집적 회로 상의 시스템을 포함할 수 있는 프로세싱 시스템(2420)을 포함한다. 프로세싱 시스템(2420)은 메모리(2410), 전원(2425)(하나 이상의 배터리들을 포함함), 오디오 입력/출력(2440), 디스플레이 제어기 및 디스플레이 디바이스(2460), 선택적 입력/출력(2450), 입력 디바이스(들)(2470), 및 무선 트랜시버(들)(2430)와 커플링된다. 도 24에 도시되지 않은 추가적인 컴포넌트들이 또한 본 발명의 특정 실시예들에서 데이터 프로세싱 시스템(2400)의 일부분일 수 있으며, 본 발명의 특정 실시예들에서, 도 24에 도시된 것보다 더 적은 컴포넌트들이 사용될 수 있다는 점이 이해될 것이다. 추가로, 도 24에 도시되지 않은 하나 이상의 버스들이 당해 기술분야에 공지된 바와 같은 다양한 컴포넌트들을 상호접속하기 위해 사용될 수 있다는 점이 이해될 것이다.

메모리(2410)는 데이터 프로세싱 시스템(2400)에 의한 실행을 위해 데이터 및/또는 프로그램들을 저장할 수 있다. 오디오 입력/출력(2440)은, 예를 들어, 음악을 재생하기 위한 마이크로폰 및/또는 스피커를 포함하고 그리고/또는 스피커 및 마이크로폰을 통해 텔레포니 기능성을 제공할 수 있다. 디스플레이 제어기 및 디스플레이 디바이스(2460)는 그래픽 사용자 인터페이스(GUI)를 포함할 수 있다. 무선(예를 들어, RF) 트랜시버들(2340)(예를 들어, WiFi 트랜시버, 적외선 트랜시버, 블루투스 트랜시버, 무선 셀룰러 텔레포니 트랜시버 등)은 다른 데이터 프로세싱 시스템들과 통신하기 위해 사용될 수 있다. 하나 이상의 입력 디바이스들(2470)은 사용자로 하여금 시스템에 입력을 제공하게 한다. 이들 입력 디바이스들은 키패드, 키보드, 터치 패널, 멀티 터치 패널 등일 수 있다. 선택적인 다른 입력/출력(2450)은 도크에 대한 커넥터일 수 있다.

본 발명의 실시예들은 위에서 설명된 바와 같은 다양한 단계들을 포함할 수 있다. 단계들은 범용 또는 특수 목적 프로세서로 하여금 특정 단계들을 수행하게 하는 머신-실행가능한 명령들에서 구현될 수 있다. 대안적으로, 이들 단계들은 단계들을 수행하기 위한 하드와이어 로직을 포함하는 특정 하드웨어 컴포넌트들에 의해, 또는 프로그래밍된 컴퓨터 컴포넌트들 및 커스텀 하드웨어 컴포넌트들의 임의의 조합에 의해 수행될 수 있다.

본 발명의 엘리먼트들은 또한 머신-실행가능한 프로그램 코드를 저장하기 위한 머신-판독가능한 매체로서 제공될 수 있다. 머신-판독가능한 매체는 플로피 디스켓들, 광학 디스크들, CD-ROM들, 및 자기-광학 디스크들, ROM들, RAM들, EPROM들, EEPROM들, 자기 또는 광학 카드들, 또는 전자 프로그램 코드를 저장하기에 적합한 다른 타입의 미디어/머신-판독가능한 매체를 포함할 수 있지만 이에 제한되지 않는다.

이전 기재 전반에 걸쳐, 설명의 목적으로, 다수의 특정 상세항목들이 본 발명의 완전한 이해를 제공하기 위해 설명되었다. 그러나, 본 발명이 이들 상세항목들 중 일부 없이 구현될 수 있다는 점이 당업자에게 명백할 것이다. 예를 들어, 여기서 기술된 기능 모듈들 및 방법들이 소프트웨어, 하드웨어 또는 이들의 임의의 조합으로서 구현될 수 있다는 점이 자명할 것이다. 또한, 본 발명의 실시예들이 모바일 컴퓨팅 환경의 상황 내에서(즉, 모바일 디바이스들(120-123; 601-603)을 사용하여) 여기서 기술되지만, 본 발명의 기본 원리들이 모바일 컴퓨팅 구현예들에 제한되지 않는다. 가상으로, 임의의 타입의 클라이언트 또는 피어 데이터 프로세싱 디바이스들이 예를 들어, 데스크톱 또는 워크스테이션 컴퓨터들을 포함하는 일부 실시예들에서 사용될 수 있다. 따라서, 본 발명의 범위 및 사상은 후속하는 청구항들의 견지에서 판단되어야 한다.

Claims (24)

1. 피어-투-피어("P2P") 통신을 위한 백업 채널들을 설정 및 유지하기 위한 컴퓨터-구현 방법으로서,
   하나 이상의 모바일 컴퓨팅 디바이스들과의 프라이머리 P2P 통신 채널을 개방하는 단계 - 상기 프라이머리 P2P 통신 채널은 상기 하나 이상의 모바일 컴퓨팅 디바이스들과의 P2P 세션들을 개방하기 위해 사용가능함 -;
   상기 프라이머리 P2P 통신 채널을 통해 상기 하나 이상의 모바일 컴퓨팅 디바이스들과 세컨더리 채널 접속 데이터를 교환하는 단계;
   상기 하나 이상의 모바일 컴퓨팅 디바이스들과 하나 이상의 세컨더리 P2P 통신 채널들을 개방하기 위해 상기 세컨더리 채널 접속 데이터를 사용하는 단계;
   상기 프라이머리 P2P 통신 채널이 특정 임계 미만으로 저하되었음을 검출하는 단계; 및
   응답하여(responsively) 상기 세컨더리 P2P 통신 채널들 중 하나를 프라이머리 P2P 통신 채널로 승격시키는 단계를 포함하는 컴퓨터-구현 방법.
2. 제1항에 있어서,
   상기 세컨더리 통신 채널들을 통해 심박 패킷을 주기적으로 전송함으로써 상기 세컨더리 통신 채널들을 유지하는 단계를 더 포함하는 컴퓨터-구현 방법.
3. 제1항에 있어서,
   상기 프라이머리 통신 채널을 개방하는 단계는 상기 하나 이상의 모바일 컴퓨팅 디바이스들과 접속 데이터를 교환하는 단계를 포함하는 컴퓨터-구현 방법.
4. 제3항에 있어서,
   상기 접속 데이터를 교환하는 단계는 일련의 인터넷 접속성 설정(ICE; Internet Connectivity Establishment) 트랜잭션들을 실행하는 단계를 더 포함하는 컴퓨터-구현 방법.
5. 제1항에 있어서,
   상기 특정 임계는 상기 프라이머리 통신 채널의 실패를 포함하는 컴퓨터-구현 방법.
6. 제1항에 있어서,
   상기 통신 채널들 각각의 현재 상태를 가지고 저장 디바이스 상에 상기 하나 이상의 세컨더리 통신 채널들 및 상기 프라이머리 통신 채널과 관련된 접속 데이터를 저장하는 단계를 더 포함하는 컴퓨터-구현 방법.
7. 제1항에 있어서,
   각각의 통신 채널은 제3 세대("3G") 무선 셀룰러 링크들, 제4 세대("4G") 무선 셀룰러 링크들, Wi-Fi 링크들, 및 블루투스 링크들 중 하나 이상을 포함하는 통신 링크들의 세트로 구성되는 컴퓨터-구현 방법.
8. 제1항에 있어서,
   적어도 하나의 프라이머리 또는 세컨더리 P2P 통신 채널은 제1 모바일 컴퓨팅 디바이스와 제2 모바일 컴퓨팅 디바이스 사이의 개인 네트워크 링크를 포함하고, 상기 제2 모바일 디바이스와의 P2P 접속은 상기 제1 모바일 컴퓨팅 디바이스를 통해 설정되는 컴퓨터-구현 방법.
9. 프로그램 코드를 저장하기 위한 메모리 및 상기 프로그램 코드를 프로세싱하기 위한 프로세서를 포함하는 모바일 컴퓨팅 디바이스로서,
   상기 프로그램 코드는,
   하나 이상의 다른 모바일 컴퓨팅 디바이스들과의 프라이머리 P2P 통신 채널을 개방하는 동작 - 상기 프라이머리 P2P 통신 채널은 상기 하나 이상의 모바일 컴퓨팅 디바이스들과의 P2P 세션들을 개방하기 위해 사용가능함 -;
   상기 프라이머리 P2P 통신 채널을 통해 상기 하나 이상의 다른 모바일 컴퓨팅 디바이스들과 세컨더리 채널 접속 데이터를 교환하는 동작;
   상기 하나 이상의 다른 모바일 컴퓨팅 디바이스들과 하나 이상의 세컨더리 P2P 통신 채널들을 개방하기 위해 상기 세컨더리 채널 접속 데이터를 사용하는 동작;
   상기 프라이머리 P2P 통신 채널이 특정 임계 미만으로 저하되었음을 검출하는 동작; 및
   응답하여, 상기 세컨더리 P2P 통신 채널들 중 하나를 프라이머리 P2P 통신 채널로 승격시키는 동작을 수행하기 위한 것인 모바일 컴퓨팅 디바이스.
10. 제9항에 있어서,
    상기 프로세서로 하여금 상기 세컨더리 통신 채널들을 통해 심박 패킷을 주기적으로 전송함으로써 상기 세컨더리 통신 채널들을 유지하는 동작들을 수행하게 하는 추가적인 프로그램 코드를 포함하는 모바일 컴퓨팅 디바이스.
11. 제9항에 있어서,
    프라이머리 통신 채널을 개방하는 것은 상기 하나 이상의 모바일 컴퓨팅 디바이스들과 접속 데이터를 교환하는 것을 포함하는 모바일 컴퓨팅 디바이스.
12. 제11항에 있어서,
    접속 데이터를 교환하는 것은 일련의 인터넷 접속성 설정("ICE") 트랜잭션들을 실행하는 것을 더 포함하는 모바일 컴퓨팅 디바이스.
13. 제9항에 있어서,
    상기 특정 임계는 상기 프라이머리 통신 채널의 실패를 포함하는 모바일 컴퓨팅 디바이스.
14. 제9항에 있어서,
    상기 프로세서로 하여금 상기 통신 채널들 각각의 현재 상태를 가지고 저장 디바이스 상에 상기 하나 이상의 세컨더리 통신 채널들 및 상기 프라이머리 통신 채널과 관련된 접속 데이터를 저장하는 동작들을 수행하게 하는 추가적인 프로그램 코드를 포함하는 모바일 컴퓨팅 디바이스.
15. 제9항에 있어서,
    각각의 통신 채널은 제3 세대("3G") 무선 셀룰러 링크들, 제4 세대("4G") 무선 셀룰러 링크들, Wi-Fi 링크들, 및 블루투스 링크들 중 하나 이상을 포함하는 통신 링크들의 세트로 구성되는 모바일 컴퓨팅 디바이스.
16. 제9항에 있어서,
    적어도 하나의 프라이머리 또는 세컨더리 P2P 통신 채널은 제1 모바일 컴퓨팅 디바이스와 제2 모바일 컴퓨팅 디바이스 사이의 개인 네트워크 링크를 포함하고, 상기 제2 모바일 디바이스와의 P2P 접속은 상기 제1 모바일 컴퓨팅 디바이스를 통해 설정되는 모바일 컴퓨팅 디바이스.
17. 컴퓨팅 디바이스에 의해 실행되는 경우, 상기 컴퓨팅 디바이스로 하여금,
    하나 이상의 다른 모바일 컴퓨팅 디바이스들과의 프라이머리 P2P 통신 채널을 개방하는 동작 - 상기 프라이머리 P2P 통신 채널은 상기 하나 이상의 모바일 컴퓨팅 디바이스들과의 P2P 세션들을 개방하기 위해 사용가능함 -;
    상기 프라이머리 P2P 통신 채널을 통해 상기 하나 이상의 다른 모바일 컴퓨팅 디바이스들과 세컨더리 채널 접속 데이터를 교환하는 동작;
    상기 하나 이상의 다른 모바일 컴퓨팅 디바이스들과 하나 이상의 세컨더리 P2P 통신 채널들을 개방하기 위해 상기 세컨더리 채널 접속 데이터를 사용하는 동작;
    상기 프라이머리 P2P 통신 채널이 특정 임계 미만으로 저하되었음을 검출하는 동작; 및
    응답하여 상기 세컨더리 P2P 통신 채널들 중 하나를 프라이머리 P2P 통신 채널로 승격시키는 동작
    을 수행하게 하는 프로그램 코드가 저장되어 있는 머신-판독가능한 매체.
18. 제17항에 있어서,
    상기 프로세서로 하여금 상기 세컨더리 통신 채널들을 통해 심박 패킷을 주기적으로 전송함으로써 상기 세컨더리 통신 채널들을 유지하는 동작들을 수행하게 하는 추가적인 프로그램 코드를 포함하는 머신-판독가능한 매체.
19. 제17항에 있어서,
    상기 프라이머리 통신 채널을 개방하는 것은 상기 하나 이상의 모바일 컴퓨팅 디바이스들과 접속 데이터를 교환하는 것을 포함하는 머신-판독가능한 매체.
20. 제19항에 있어서,
    상기 접속 데이터를 교환하는 것은 일련의 인터넷 접속성 설정("ICE") 트랜잭션들을 실행하는 것을 더 포함하는 머신-판독가능한 매체.
21. 제17항에 있어서,
    상기 특정 임계는 상기 프라이머리 통신 채널의 실패를 포함하는 머신-판독가능한 매체.
22. 제17항에 있어서,
    상기 프로세서로 하여금 상기 통신 채널들 각각의 현재 상태를 가지고 저장 디바이스 상에 상기 하나 이상의 세컨더리 통신 채널들 및 상기 프라이머리 통신 채널과 관련된 접속 데이터를 저장하는 동작들을 수행하게 하는 추가적인 프로그램 코드를 포함하는 머신-판독가능한 매체.
23. 제17항에 있어서,
    각각의 통신 채널은 제3 세대("3G") 무선 셀룰러 링크들, 제4 세대("4G") 무선 셀룰러 링크들, Wi-Fi 링크들, 및 블루투스 링크들 중 하나 이상을 포함하는 통신 링크들의 세트로 구성되는 머신-판독가능한 매체.
24. 제17항에 있어서,
    적어도 하나의 프라이머리 또는 세컨더리 P2P 통신 채널은 제1 모바일 컴퓨팅 디바이스와 제2 모바일 컴퓨팅 디바이스 사이의 개인 네트워크 링크를 포함하고, 상기 제2 모바일 디바이스와의 P2P 접속은 상기 제1 모바일 컴퓨팅 디바이스를 통해 설정되는 머신-판독가능한 매체.

Images