KR101408560B1 - 사용자를 온라인 세션에 초대하기 위한 장치 및 방법 - Google Patents

사용자를 온라인 세션에 초대하기 위한 장치 및 방법 Download PDF

Info

Publication number
KR101408560B1
KR101408560B1 KR1020127028631A KR20127028631A KR101408560B1 KR 101408560 B1 KR101408560 B1 KR 101408560B1 KR 1020127028631 A KR1020127028631 A KR 1020127028631A KR 20127028631 A KR20127028631 A KR 20127028631A KR 101408560 B1 KR101408560 B1 KR 101408560B1
Authority
KR
South Korea
Prior art keywords
mobile device
service
data
connection
relay
Prior art date
Application number
KR1020127028631A
Other languages
English (en)
Other versions
KR20130006496A (ko
Inventor
앤드류 에이치. 비로스
제레미 매튜 워너
패트릭 게이츠
Original Assignee
애플 인크.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 애플 인크. filed Critical 애플 인크.
Publication of KR20130006496A publication Critical patent/KR20130006496A/ko
Application granted granted Critical
Publication of KR101408560B1 publication Critical patent/KR101408560B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/34—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using peer-to-peer connections
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/79—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
    • A63F13/795—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories for finding other players; for building a team; for providing a buddy list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2564—NAT traversal for a higher-layer protocol, e.g. for session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2567—NAT traversal for reachability, e.g. inquiring the address of a correspondent behind a NAT server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/33—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections
    • A63F13/332—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections using wireless networks, e.g. cellular phone networks
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/90—Constructional details or arrangements of video game devices not provided for in groups A63F13/20 or A63F13/25, e.g. housing, wiring, connections or cabinets
    • A63F13/92—Video game devices specially adapted to be hand-held while playing
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/20—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterised by details of the game platform
    • A63F2300/209—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterised by details of the game platform characterized by low level software layer, relating to hardware management, e.g. Operating System, Application Programming Interface
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/40—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterised by details of platform network
    • A63F2300/406—Transmission via wireless network, e.g. pager or GSM
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/40—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterised by details of platform network
    • A63F2300/408—Peer to peer connection
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/55—Details of game data or player data management
    • A63F2300/5546—Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history
    • A63F2300/5566—Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history by matching opponents or finding partners to build a team, e.g. by skill level, geographical area, background, play style

Abstract

피어-투-피어("P2P) 통신 채널을 확립하기 위한 장치, 방법, 및 머신-판독가능한 매체가 설명된다. 특히, 한 실시예에서, 초대 서비스(invitation service)는 2개 이상의 모바일 데이터 처리 장치들 사이에서 P2P 통신 채널을 가능케하기 위해 일련의 트랜잭션(transaction)을 수행한다. P2P 네트워크 통신 채널을 확립하려는 시도 이전에, 초대 서비스는 먼저 모바일 장치들 각각에 대한 네트워크 정보를 수집하고, 직접적 P2P 네트워크 통신 채널이 가능한지를 판정하기 위해 이 네트워크 정보를 이용한다. 직접적 접속이 가능하다면, 초대 서비스는 직접적 P2P 통신을 제공하고, 필요한 네트워크 정보를 각 모바일 장치에 푸시한다. 그러나, 직접적 접속이 가능하지 않거나 직접적 접속을 시도하여 실패한다면, 초대 서비스는 중계 서비스(relay service)와 연관된 네트워크 정보를 확인할 수도 있다. 그러면, 네트워크 정보는 임의 쌍의 모바일 장치들에 의해 중계 서비스를 통해 접속을 확립하기 위해 이용될 수도 있다. 또한, 한 실시예에서, 초대 서비스는 모바일 장치들 중 임의의 장치에 대한 어떠한 접속별 상태 정보(per-connection state information)를 유지하지 않고도 그 기능을 수행할 수 있다.

Description

사용자를 온라인 세션에 초대하기 위한 장치 및 방법{APPARATUS AND METHOD FOR INVITING USERS TO ONLINE SESSIONS}
우선권 주장
본 출원은 "Apparatus and Method for Inviting Users to Online Sessions"이라는 명칭의 2010년 4월 7일 출원된 미국 가출원 번호 제61/321,832호의 우선권을 주장한다.
본 출원에서 개시되고 청구되는 발명은, 2010년 3월 25일 Apple 엔지니어가 Apple의 iPhone 4의 프로토타입을 무단취득하여 Apple의 승인없이 너무 이르게 공개되었다.　 본 출원이 기초하고 있는 U.S 우선권 출원은 이 명백한 무단취득 이전에 출원되지 않았다.
발명의 분야
본 출원에서 개시되고 청구되는 발명은, 2010년 3월 5일 Apple 엔니지어가 Apple의 iPhone 4의 프로토타입을 무단취득하여 Apple의 승인없이 너무 이르게 공개되었다.　 본 출원이 기초하고 있는 U.S. 우선권 출원은 이 명백한 무단취득 이전에 출원되지 않았다.
본 발명은 대체로 컴퓨터 네트워킹 분야에 관한 것이다. 더 구체적으로는, 본 발명은 모바일 장치와 같은 컴퓨팅 장치의 사용자를 온라인 통신 세션(예를 들어, 피어-투-피어 세션)에 초대하기 위한 개선된 장치 및 방법에 관한 것이다.
관련 기술의 설명
A. 네트워크 주소 변환("NAT")
인터넷과 같은 대규모 공중 네트워크는, 회사, 인터넷 서비스 제공자, 또는 심지어 개별 가정에 의해 유지되는 네트워크와 같은 더 작은 사설 네트워크로의 접속을 빈번하게 가진다. 바로 이러한 그들의 성격상, 공중 네트워크는 널리 합의된(commonly agreed upon) 네트워크 주소 할당, 즉, 공개 주소(public address)를 가져야 한다. 다양한 이유로 인해, 사설 네트워크의 유지보수인은 종종 널리 합의된 할당의 일부가 아닌 사설 네트워크에 대한 사설 네트워크 주소를 이용할 것을 선택한다. 따라서, 사설 네트워크로부터의 네트워크 트래픽이 공중 네트워크를 횡단할 수 있기 위해, 소정 형태의 사설/공중 네트워크 주소 변환("NAT")이 요구된다.
NAT 연산을 행하는 장치는 사설 네트워크 외부로 전송되는 데이터 패킷들을 변경하여 공중 네트워크의 주소지정 체계에 따르도록 한다. 특히, 네트워크 주소 변환기는 패킷의 발신 사설 주소와 포트 번호를 그 자신의 공개 주소 및 할당된 포트 번호로 대체한다. 네트워크 주소 변환기는 또한, 사설 네트워크 상의 컴퓨터용으로 수신되고 있는 데이터 패킷들을 변경하여, 목적지 공개 주소 및 포트 번호를 의도된 수신자의 올바른 사설 주소 및 포트 번호로 대체한다. 본 명세서에서 사용될 때, 용어, 주소는, 당업자라면 이해하는 바와 같이, 문맥상 적절하다면 주소와 포트 번호 양쪽 모두를 포함하는 것으로 해석되어야 한다.
NAT는 현대의 네트워크 컴퓨팅에서 점점 더 흔해지고 있다. NAT의 한 이점은 공중 네트워크 주소 공간의 고갈을 늦춘다는 것이다. 예를 들어, TCP/IP 주소지정은, 인터넷 상에서 이용될 때, 각각이 3 자릿수를 갖는 4개 문자열을 포함하므로, 유한한 주소 공간을 제공한다. 추가적으로, 이 주소 공간의 소정 부분들은 특정한 사용자 또는 사용자들을 위해 예약되어 있어서, 가용 주소의 실제 갯수를 더욱 고갈시킨다. 그러나, 만일 NAT가 이용된다면, 사설 네트워크 또는 서브넷은 임의 숫자의 주소를 이용할 수도 있지만, 여전히 외부 세계에 대해서는 단 하나의 표준화된 공개 주소를 내보인다. 이것은, 각 사설 네트워크는 이론적으로 정확히 동일한 사설 주소들을 이용할 수 있기 때문에, 가용 주소의 갯수를 사실상 무제한으로 만든다.
NAT에 의해 제공되는 한 이점은, 공중 네트워크 상의 컴퓨터들이 사설 네트워크 상의 컴퓨터의 실제 (즉, 사설) 네트워크 주소를 판정할 수 없다는 사실로 인해 보안성이 증가된다는 것이다. 이것은 공중 네트워크 상에는 네트워크 주소 변환기에 의해 공개 주소만이 제공되기 때문이다. 추가적으로, 이 공개 주소는 사설 네트워크 상의 임의 갯수의 컴퓨터에 대응할 수도 있다.
NAT 타입마다 상이한 보안 레벨을 이용하고 있다. 예를 들어, "full cone NAT"에서는, 일단 내부 주소(iAddr:iPort)가 외부 주소(eAddr:ePort)로 맵핑되고 나면, 임의의 외부 호스트는 eAddr:ePort에 패킷을 전송함으로써 iAddr:iPort에 패킷을 전송할 수 있다. "restricted cone NAT"에서는, 주소 hAddr을 갖는 외부 호스트는, iAddr:iPort가 앞서 hAddr에 패킷을 전송한 경우에만 eAddr:ePort에 패킷을 전송함으로써 iAddr:iPort에 패킷을 전송할 수 있다. 외부 호스트의 포트는 무관하다. "Port Restricted Cone 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 iPhoneTM은 Wi-Fi 네트워크(예를 들어, 802.11b, g, n 네트워크); 3G 네트워크(예를 들어, UMTS(Universal Mobile Telecommunications System) 네트워크, HSUPA(High-Speed Uplink Packet Access) 네트워크 등); 및 (PAN(personal area network)이라고 알려진) Bluetooth 네트워크를 통해 통신할 수 있다. 향후의 모바일 장치들은, 몇 가지 예를 들자면, WiMAX, IMT(International Mobile Telecommunication) Advanced, 및 LTE(Long Term Evolution) Advanced와 같은 추가적인 통신 채널들을 통해 통신할 수 있을 것이다.
피어-투-피어("P2P) 통신 채널을 확립하기 위한 장치, 방법, 및 머신-판독가능한 매체를 설명한다. 특히, 한 실시예에서, 초대 서비스(invitation service)는 2개 이상의 모바일 데이터 처리 장치들 사이에서 P2P 통신을 가능케하기 위해 일련의 트랜잭션(transaction)을 수행한다. P2P 네트워크 통신 채널을 확립하려는 시도 이전에, 초대 서비스는 먼저 모바일 장치들 각각에 대한 네트워크 정보를 수집하고, 직접적 P2P 네트워크 통신 채널이 가능한지를 판정하기 위해 이 네트워크 정보를 이용한다. 만일 직접적 접속이 가능하다면, 초대 서비스는 직접적 P2P 통신을 제공하고, 필요한 네트워크 정보를 각 모바일 장치에 푸시한다. 그러나, 만일 직접적 접속이 가능하지 않거나 직접 접속을 시도하여 실패한다면, 초대 서비스는 중계 서비스(relay service)와 연관된 네트워크 정보를 확인할 수도 있다. 그러면, 네트워크 정보는 중계 서비스를 통해 접속을 확립하기 위해 임의 쌍의 모바일 장치들에 의해 이용될 수도 있다. 또한, 한 실시예에서, 초대 서비스는 모바일 장치들 중 임의의 장치에 대한 접속별 상태 정보(per-connection state information)를 유지하지 않고도 그 기능을 수행할 수 있다.
첨부된 도면들과 연계한 이하의 상세한 설명으로부터 본 발명의 더 나은 이해를 얻을 수 있다.
도 1은 한 그룹의 모바일 장치 및 서비스가 네트워크를 통해 통신하는 네트워크 아키텍쳐를 나타낸다.
도 2a 내지 도 2c는 한 실시예의 접속 데이터 교환(CDX) 서비스, 중매자 서비스(matchmaker service) 및/또는 초대 서비스 사이의 트랜잭션을 나타낸다.
도 3은 티켓 데이터 구조의 한 실시예를 나타낸다.
도 4는 CDX 서비스에 의해 구현되는 방법의 한 실시예를 나타낸다.
도 5는 모바일 장치에 의해 구현되는 방법의 한 실시예를 나타낸다.
도 6은 1차 및 2차 통신 채널들을 통해 접속된 한 그룹의 모바일 장치를 나타낸다.
도 7은 모바일 장치가 1차 및 2차 통신 채널들 중에서 선택하는 한 실시예를 나타낸다.
도 8a 및 도 8b는 1차 및 2차 통신 채널들을 통해 접속된 한 그룹의 모바일 장치와 그 결과의 네트워크 토폴로지를 나타낸다.
도 9는 1차 및 2차 통신 채널들 중에서 선택하기 위한 컴퓨터-구현된 방법의 한 실시예를 나타낸다.
도 10은 디렉토리 서비스 및 푸시 통보 서비스를 포함한, 한 그룹의 모바일 장치 및 서비스가 네트워크를 통해 통신하는 네트워크 아키텍쳐를 나타낸다.
도 11은 한 실시예의 초대 서비스, 푸쉬 통보 서비스, 및 접속 데이터 교환(CDX) 서비스 사이의 트랜잭션을 나타낸다.
도 12는 한 실시예의 초대 서비스, 푸쉬 통보 서비스, 및 중계 서비스 사이의 트랜잭션을 나타낸다.
도 13은 2개 이상의 모바일 장치들 사이에 중계 접속을 확립하기 위한 중계 서비스의 한 실시예를 나타낸다.
도 14는 NAT 호환성을 판정하기 위한 NAT 호환성 차트의 한 실시예를 나타낸다.
도 15는 온라인 애플리케이션에 대해 모바일 장치들을 매치하기 위한 중매자 서비스의 한 실시예를 나타낸다.
도 16은 사용자들/장치들을 매치하기 위한 방법의 한 실시예를 나타낸다.
도 17a 내지 도 17d는 사용자들/장치들을 매치하기 위해 수행되는 예시적인 일련의 테이블 업데이트를 나타낸다.
도 18은 상이한 매치 정합 변수(match fit variable)들을 이용하여 사용자들/장치들을 매치하기 위한 방법을 나타낸다.
도 19는 애플리케이션에 대한 애플리케이션 프로그래밍 인터페이스(API)와, 한 세트의 서비스와 통신하기 위한 서비스 API를 나타내는 프레임워크를 도시한다.
도 20은 애플리케이션에 대한 API, 게임 데몬, 및 서비스들과 통신하기 위한 게임 서비스 모듈을 갖는 게임 프레임워크의 한 실시예를 나타낸다.
도 21은 API 구현 소프트웨어 컴포넌트 및 API 호출 소프트웨어 컴포넌트의 한 실시예를 나타낸다.
도 22는 운영 체제들, 서비스들, 및 애플리케이션들 사이에서 API 호출이 이루어지는 한 실시예를 나타낸다.
도 23은 예시적 컴퓨터 시스템 아키텍쳐의 한 실시예를 나타낸다.
도 24는 예시적 컴퓨터 시스템 아키텍쳐의 또 다른 실시예를 나타낸다.
네트워크 상에서 1차 및/또는 백업 피어-투-피어("P2P") 통신 채널을 확립하고, 유지하며, 이용하기 위한 장치, 방법, 및 머신-판독가능한 매체의 실시예들을 이하에서 설명한다. P2P 세션 동안 각각 사용자들을 초대하고 사용자들을 매치하기 위한 초대 서비스 및 중매자 서비스도 역시 설명된다. 추가적으로, 소정의 명시된 조건 하에서 사용자들이 중계 접속을 확립하는 것을 허용하는 중계 서비스가 설명된다. 마지막으로, 애플리케이션 개발자들이 본 명세서에서 설명되는 다양한 협력 온라인 특징들을 이용하는 애플리케이션을 설계할 수 있게 하는 애플리케이션 프레임워크 및 연관된 애플리케이션 프로그래밍 인터페이스(API)가 설명된다.
상세한 설명 전체를 통틀어, 설명의 목적을 위해, 많은 구체적인 세부사항이 본 발명의 철저한 이해를 제공하기 위하여 개시된다. 그러나, 본 발명은 이와 같은 구체적인 세부사항 없이도 실시될 수 있다는 것은 당업자에게 명백할 것이다. 다른 예들에서, 본 발명의 기저 원리를 모호하게 하는 것을 피하기 위하여 공지된 구조 및 장치들은 도시되지 않고 블록도 형태로 도시된다.
접속 데이터를 효율적으로 및 안전하게 교환하기 위한 장치 및 방법
도 1에 나타낸 바와 같이, 본 발명의 한 실시예에서 구현된 일반적 네트워크 토폴로지는, 네트워크(120)를 통해 서로간에 및 하나 이상의 서비스(110-112)와 각각 통신하는, 한 그룹의 "클라이언트" 또는 "피어" 모바일 컴퓨팅 장치(A-D)(120-123)를 포함할 수 있다. 도 1에서는 하나의 네트워크 클라우드(cloud)로서 나타내지만, "네트워크"(120)는, 인터넷과 같은 공중 네트워크와, 몇 가지 예를 들자면, 로컬 Wi-Fi 네트워크(예를 들어, 802.11n 홈 무선 네트워크 또는 무선 핫스팟), 근거리 이더넷 네트워크, 셀룰러 데이터 네트워크(예를 들어, 3G, Edge 등), 및 WiMAX 네트워크와 같은 사설 네트워크를 포함하는 여러가지 상이한 컴포넌트들을 포함할 수 있다. 예를 들어, 모바일 장치 A(120)는 네트워크 링크(125)로 표시된 홈 Wi-Fi 네트워크에 접속될 수도 있고, 모바일 장치 B(121)는 네트워크 링크(126)로 표시된 3G 네트워크(예를 들어, UMTS(Universal Mobile Telecommunications System), HSUPA(High-Speed Uplink Packet Access) 등)에 접속될 수도 있고, 모바일 장치 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; storage area network)를 포함할 수도 있다. 한 실시예에서, 데이터베이스는 모바일 장치(120-123) 각각과 이들 장치들의 사용자들에 관련된 데이터(예를 들어, 사용자 계정 데이터, 장치 계정 데이터, 사용자 애플리케이션 데이터 등)를 저장 및 관리한다.
한 실시예에서, 중매자 서비스(111)는 명시된 조건 세트에 기초하여 협력 P2P 세션을 위해 2개 이상의 모바일 장치를 매치시킬 수 있다. 예를 들어, 2개 이상의 모바일 장치들의 사용자들은 특정한 멀티플레이어 게임을 플레이하는데 관심을 가질 수도 있다. 이러한 경우, 중매자 서비스(111)는, 각 사용자의 숙련도, 각 사용자의 연령, 매치 요청의 시간, 매치 요청된 특정의 게임, 및 다양한 게임-특유의 변수들과 같은 변수들에 기초하여 게임에 참여할 모바일 장치들의 그룹을 식별할 수 있다. 제한이 아니라 예로서, 중매자 서비스(111)는 특정 게임의 플레이시에 비슷한 숙련도의 사용자들을 매치하려고 시도할 수도 있다. 추가적으로, 성인은 다른 성인과 매치되고, 아이들은 다른 아이들과 매치될 수도 있다. 게다가, 중매자 서비스(111)는 이들 요청이 수신된 순서에 기초하여 사용자 요청을 우선순위화할 수도 있다. 본 발명의 기저 원리는, 임의의 특정한 세트의 매치 기준이나 임의의 특정한 타입의 P2P 애플리케이션으로 한정되지 않는다.
이하에서 상세히 기술되는 바와 같이, 매치 요청에 응답하여, 중매자 서비스(111)는, 효율적이고 안전한 방식으로 P2P 세션을 확립하기 위해 필요한 접속 데이터를 모든 매치된 참여자들이 수신하는 것을 보장하기 위해, CDX 서비스(110)와 조율할 수 있다.
한 실시예에서, 초대 서비스(112)는 또한, 협력적 P2P 세션에 참여하기 위한 모바일 장치들을 식별한다. 그러나, 초대 서비스(112)의 경우, 참여자들 중 적어도 한 명이 다른 참여자에 의해 특정적으로 식별된다. 예를 들어, 모바일 장치 A(120)의 사용자는 모바일 장치 B(121)의 사용자와의 협력적 세션을 특정적으로 요청할 수도 있다(예를 들어, 사용자 ID 또는 전화 번호로 모바일 장치 B를 식별). 중매자 서비스(111)에서와 같이, 초대 요청에 응답하여, 초대 서비스(112)는, 효율적이고 안전한 방식으로 P2P 세션을 확립하기 위해 필요한 접속 데이터를 모든 참여자들이 수신하는 것을 보장하기 위해, 참여자 집합을 식별하고 CDX 서비스(110)와 조율할 수 있다.
전술된 바와 같이, 한 실시예에서, CDX 서비스(110)는 2개 이상의 모바일 장치들 사이에 P2P 세션을 확립하는데 요구되는 접속 데이터에 대한 중앙 교환점으로서 동작한다. 구체적으로는, CDX 서비스의 한 실시예는 모바일 장치 요청에 응답하여 NAT 횡단 데이터(때때로 "홀 펀치" 데이터라고 함)를 생성하여 외부 서비스 및 클라이언트가 각각의 모바일 장치의 NAT를 통해 통신할 수 있게(즉, 장치에 도달하기 위해 NAT를 통한 홀을 펀치할 수 있게) 한다. 예를 들어, 한 실시예에서, CDX 서비스는 모바일 장치와 통신하는데 필요한 외부 IP 주소와 포트를 검출하여 이 정보를 모바일 장치에 제공한다. 한 실시예에서, CDX 서비스는 또한, 중매자 서비스(111) 및 초대 서비스(112)에 의해 발생된 모바일 장치의 목록을 수신 및 처리하고, (이하에서 상세히 기술되는) 그 목록에 포함된 모바일 장치들 각각에 접속 데이터를 효율적이고도 안전하게 배포한다.
한 실시예에서, 모바일 장치와 CDX 서비스(110) 사이의 통신은 사용자 데이터그램 프로토콜("UDP") 소켓과 같은 비교적 가벼운 네트워크 프로토콜을 이용하여 확립된다. 당업자라면 알 수 있는 바와 같이, UDP 소켓 접속은 패킷 신뢰성, 순서화, 또는 데이터 무결성을 보장하기 위한 핸드쉐이킹 대화를 요구하지 않으므로, TCP 소켓 접속과 같은 과도한 패킷 처리 오버헤드를 소비하지 않는다. 결과적으로, UDP의 가볍고 무상태 성향(stateless nature)은 방대한 수의 클라이언트로부터의 작은 질의들에 응답하는 서버들에 유용하다. 게다가, TCP와는 달리, UDP는 (패킷들이 로컬 네트워크 상의 모든 장치에 전송되는) 패킷 브로드캐스팅 및 (패킷들이 로컬 네트워크 상의 장치들의 서브셋에 전송되는) 멀티캐스팅과 호환된다. 후술되는 바와 같이, UDP가 이용될수 있더라도, 세션키를 이용하여 NAT 횡단 데이터를 암호화함으로써 CDX 서비스(110) 상에서 보안이 유지될 수 있다.
CDX 서비스(110)에 의해 이용되는 낮은 오버헤드의 가벼운 네트워크 프로토콜과는 대조적으로, 한 실시예에서, 모바일 장치(120-123)와 중매자 서비스(111) 및/또는 초대 서비스(112) 사이의 통신은, SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 접속에 의존하는 HTTPS(Hypertext Transfer Protocol Secure)와 같은 고유의 보안된 네트워크 프로토콜을 이용하여 확립된다. 이들 프로토콜과 연관된 세부사항은 당업자에게 공지되어 있다.
도 2a는 CDX 서버에 의해 구현될 수 있는 예시적인 일련의 트랜잭션을 나타낸다. CDX 서비스의 한 실시예의 동작을 설명할 때, 이하의 용어들은 다음과 같은 의미를 가질 것이다.
접속 데이터(Connection Data) - 이것은 잠재적 피어들이 피어-투-피어 세션을 확립하기 위해 서로 교환할 필요가 있는 정보이다. 이하에서는 이 정보가 어떻게 교환될 수 있는지에 대한 메커니즘의 실시예가 설명된다.
CDX 서버(CDX Server) - 한 실시예에서 CDX 서버는 인증된 엔티티들이 임의 데이터(arbitrary data)를 교환하는 것을 허용하는 인증된 멀티캐스터 리플렉 터(authenticated multicast reflector)이다. 이 데이터는 페이로드라 불린다.
CDX 세션(CDX Session) - CDX 세션이란 CDX 서버를 통해 서로 통신할 수 있는 한 그룹의 클라이언트 장치를 말한다. 세션의 일부인 각 클라이언트 장치에는 CDX 티켓(CDX Ticket)이 할당된다. 　각 세션은 개개의 세션을 식별하거나 참조하는데 이용될 수 있는 큰 정수인 고유 CDX 세션 ID(CDX 　 Session ID)를 가진다.
CDX 요청(CDX Request) - 클라이언트 장치로부터 CDX 서버로 전송되는 요청. 요청은 일반적으로 2개의 부분으로 구성된다: CDX 티켓 및 페이로드. 본 실시예에서는, 페이로드는 세션키로 암호화된 접속 데이터이다.
CDX 응답(CDX Response) - CDX 응답은 CDX 서버가 CDX 세션의 멤버로부터 CDX 요청을 수신할 때 CDX 세션 내의 다른 장치들에 되"반사"되는 것이다. 이것은 주어진 CDX 요청에서 이용되는 CDX 티켓의 CDX 티켓 스터브에 페이로드를 부가함으로써 구성된다.
CDX 티켓(CDX Ticket) - CDX 티켓은 CDX 세션의 멤버들에 페이로드를 전송하는 방법을 CDX 서버에게 말해준다. 한 실시예에서, 이것은 위조나 무단변경(tampering)을 방지하기 위해 CDX 티켓 키로 "서명"된다. 도 3에 나타낸 바와 같이, 한 실시예에서, CDX 티켓은 다음과 같은 정보를 포함한다:
한 실시예에서는 암호화 또는 난독화(obfuscate)되지 않은 세션 ID(301).
한 실시예에서는 암호화 또는 난독화되지 않은 세션의 참여자 수(302).
(한 실시예에서는 암호화 또는 난독화되지 않은) 이 티켓이 참조하는 세션의 참여자의 인덱스(303).
경과시에 티켓이 무효한 것으로 간주되는 (한 실시예에서는 암호화 또는 난독화되지 않은) 만료 시간/날짜(304).
한 실시예에서는 CDX 티켓 키를 이용하여 암호화되는, 세션의 각 참여자에 대한 CDX 홀-펀치 데이터(305-306).
티켓이 진본임을 보장하는 "디지털 서명"으로서 역할하는, CDX 티켓 키를 이용한 메시지 인증 코드(307)
CDX 티켓 스터브(CDX Ticket Stub) - CDX 티켓의 첫 번째 부분에서 CDX 홀-펀치 데이터 및 메시지 인증 코드를 제외한 부분.
페이로드(Payload) - 이것은 CDX 요청 및 CDX 응답의 두 번째 부분. 페이로드는 클라이언트 장치가 CDX 세션 내의 다른 장치들에 전달하기를 원하는 데이터이다. 본 실시예에서는, 페이로드는 세션키로 암호화된 접속 데이터이다. CDX 서버는 한 실시예에서는 페이로드를 암호해독하지 않고, 미변경 상태로 단순 전달한다.
세션키(Session Key) - 이것은 접속 데이터를 암호화하기 위해 클라이언트에 의해 이용되는 키. 한 실시예에서, 이 키는 CDX 서버에게 알려지지 않는다. 본 실시예에서는, 세션 키는 중매 서비스에 의해 생성되어 클라이언트들에게 그들 개개의 CDX 티켓과 함께 전송된다.
CDX 티켓 키(CDX Ticket Key) - 이것은 CDX 티켓을 생성하고 "서명"하는데 이용되는 키이다. CDX 티켓 키는, CDX 서버와, 후술되는 바와 같이 중매 서비스 및/또는 초대 서비스일 수 있는 CDX 티켓을 생성하는 서비스에 의해서만 알려진다.
CDX 홀-펀치 요청(CDX Hole - Punch Request) - CDX 서버로부터 CDX 홀-펀치 데이터를 얻는데 이용되는 특별한 타입의 CDX 요청.
CDX 홀-펀치 데이터(CDX Hole - Punch Data) - 이것은 CDX 서버가 어떻게 정보를 본래 그것을 요청한 클라이언트에 전송할 수 있는지를 기술하는 불투명 데이터 블롭(opaque data blob)이다. 이것은 CDX 홀-펀치 요청을 CDX 서버에 전송함으로써 얻어진다. CDX 홀-펀치 데이터는 CDX 티켓이 생성될 수 있기 이전에 CDX 세션의 각 클라이언트 장치로부터 수집되어야 한다. CDX 홀-펀치 데이터(때때로 "NAT 횡단 데이터"라고 함)는 요청측 장치의 공개 IP 주소 및 포트를 포함할 수도 있다.
이제 도 2a를 참조하면, 한 실시예에서, 모바일 장치 A(120) 및 모바일 장치 B(121)는, 하나 이상의 다른 컴퓨팅 장치와의 P2P 접속을 요구하는 멀티플레이어 게임이나 협력 채팅 세션과 같은 협력 애플리케이션을 실행하고 있을 수 있다. 201a에서, 모바일 장치 A(120)는 CDX 서버(110)에 CDX 홀-펀치 요청을 전송한다. 그 다음, CDX 서버(110)는 202a에서 CDX 홀-펀치 데이터로 응답한다. 한 실시예에서, 홀 펀치 데이터는 모바일 장치 A의 공개 IP 주소 및 포트 및/또는 모바일 장치 A의 NAT를 통해 홀을 펀치하는데 요구되는 임의의 다른 데이터(예를 들어, 모바일 장치 A의 NAT 타입을 정의하는 NAT 타입 데이터)를 포함한다. 각각 201b 및 202b에서 모바일 장치 B에 대해 유사한 트랜잭션이 수행된다.
203a 및 203b에서, 모바일 장치 A 및 B는, 다음으로, CDX 홀-펀치 데이터를 포함하는 매치 요청을, 임의의 추가 매치 기준(후술)과 함께, 중매 서비스에 전송한다. 이 단계에서, 모바일 장치 A 및 B는 P2P 접속을 확립하는데 필요한 접속 데이터를 구성하기 시작할 수도 있다. 이것은, (예를 들어, NAT 횡단 서비스에 의해), 예를 들어, 표준 인터넷 접속 확립("ICE"; Internet Connectivity Establishment) 트랜잭션과 같은 트랜잭션을 이용하여 달성될 수도 있다. 그러나, 본 발명의 기저 원리는 접속 데이터를 결정하기 위한 임의의 특정 메커니즘으로 한정되지 않는다.
한 실시예에서, 일단 중매 서비스(111)가 매치 기준을 이용하여 한 세트의 클라이언트 장치를 발견하고 나면, 고유 CDX 세션 ID, CDX 세션의 각 멤버에 대한 고유 CDX 티켓과, 고유 세션 키를 생성할 수도 있다. 한 실시예에서, 중매 서비스(111)는 고유 CDX 티켓 키를 이용하여 CDX 티켓에 대한 CDX 홀-펀치 데이터를 암호화할 수도 있다. 204a 및 204b에서, 중매 서비스는, 그 다음, 모바일 장치 A 및 B 각각에게 그들의 CDX 티켓 및 세션 키를 전송할 수도 있다.
모바일 장치 A는 CDX 티켓과 세션 키를 수신하고, 세션 키를 이용하여 그 이전에 결정된 접속 데이터를 암호화하여, 페이로드를 만든다. 한 실시예에서, 모바일 장치 A는 구성된 페이로드를 CDX 티켓에 첨부함으로써 CDX 요청을 구성한다. 205a에서, 모바일 장치 A는 CDX 서버(110)에 CDX 요청을 전송한다. 모바일 장치 B는 또한, 205b에서 동일한 동작을 수행하고 CDX 서버에 요청을 전송할 수 있다.
206a에서, CDX 서버(110)는 CDX 요청을 수신하고, (예를 들어, 메시지 인증 코드(307)에 기초하여) 티켓이 유효하고 진본임을 보장하기 위해 티켓을 검사한다. 만일 CDX 티켓이 무효라면, 그 요청이 누락된다. 한 실시예에서, CDX 서버는, 그 다음, CDX 티켓 키를 이용하여 CDX 티켓에 포함된 CDX 홀-펀치 데이터 세트를 암호해독한다. 한 실시예에서, CDX 티켓 키는 티켓들과 함께 전송될 수도 있는 만료 시간/날짜를 포함할 수 있다. CDX 서비스(110) 및 중매자 서비스(111)는 암호화/암호해독을 위해 2개의(또는 그 이상의) 상이한 CDX 티켓 키를 저장할 수 있으며, 그 첫 번째는 현재 활성인 CDX 티켓 키이고, 두 번째는 첫 번째의 만료 시간/날짜에 도달시 활성으로 될 CDX 티켓 키이다. 티켓의 수신시에, CDX 서비스(110)는 어떤 티켓 키를 사용할지를 결정하기 위해 만료 시간/날짜를 판독할 수 있다. CDX 티켓 키가 만료되면, CDX 서비스(110) 및 중매자 서비스(111) 둘 다는 각각, (현재의 티켓 키가 만료한 후에 사용될 다음 키가 되는) 새로운 티켓 키를 생성할 수 있다. 한 실시예에서, CDX 서비스(110) 및 중매자 서비스(111)는 2개의 티켓 키들에서의 일관성을 보장하기 위해 동일한 키 생성 알고리즘을 실행한다. 예를 들어, 고정된 인터벌로 새로운 인증 코드가 생성되는 공지된 RSA SecurID 인증 메커니즘에 이용되는 기술과 같은 기술들이 이용될 수도 있다. 한 실시예에서, 새로운 CDX 티켓 키는 일별로(on a daily basis) 생성된다. 그러나, 본 발명의 기저 원리는 CDX 티켓 키를 생성하기 위한 임의의 특정 메커니즘으로 한정되지 않는다.
동일한 동작들이 모바일 장치 B에 대해 206b에 도시된 바와 같이 수행될 수 있다. CDX 서버는 CDX 요청으로부터 CDX 응답을 구성한 다음, CDX 홀-펀치 데이터를 이용하여 CDX 응답을 CDX 세션의 참여자들에게 전송(207a에서는 모바일 장치 B에게 전송하고 207b에서는 모바일 장치 A에게 전송)한다.
모바일 장치 B는 CDX 서버로부터 CDX 응답(207a)을 수신한다. 클라이언트 장치 B는 세션 ID가 그 자신의 CDX 티켓의 세션 ID와 매치됨을 보장하기 위해 CDX 티켓 스터브를 검사한다. 모바일 장치 B는 그 다음, 세션 키를 이용하여 페이로드를 암호해독하여, 모바일 장치 A로부터의 접속 데이터를 산출할 수 있다.　 그 다음, 모바일 장치 B는 모바일 장치 A로부터의 접속 데이터를 이용하여 P2P 세션을 확립하는 프로세스를 시작한다. 한 실시예에서, 이들은 표준 ICE 트랜잭션을 포함한다. 그러나, 본 발명의 기저 원리는 P2P 통신을 확립하기 위한 임의의 특정 메커니즘으로 한정되지 않는다.
전술된 바와 같이, 한 실시예에서, 모바일 장치 A와 B는 중매자 서비스(111)와 통신하기 위해 (예를 들어, HTTPS 요청/응답 트랜잭션을 이용하여) HTTPS(Hypertext Transfer Protocol Secure)를 확립하고, CDX 서비스와 통신하기 위해 UDP 소켓을 확립한다. 매치 요청(204a, 204b)은, NAT 타입과, 각각의 개별 모바일 장치에 대해 앞서 결정된 홀 펀치 데이터(예를 들어, 공개 IP 주소 및 포트)를 포함할 수 있다. 멀티플레이어 게임을 포함하는 한 실시예에서, 각각의 매치 요청은 (예를 들어, 고유 플레이어 ID 코드를 이용한) 각 모바일 장치 상의 플레이어, 각 사용자가 플레이하기를 원하는 게임, 게임에 참여할 플레이어의 수, 및/또는 원하는 게임과 연관된 다른 게임 구성 변수를 식별할 수 있다. 제한이 아니라 예로서, 게임과 연관된 게임 구성 변수는, 난이도(예를 들어, 쉬움, 보통, 어려움), 사용자의 나이(예를 들어, "13세 미만"), 게임의 소구역(sub-region)(예를 들어, "레벨 2"), 및/또는 플레이어의 숙련도(예를 들어, 전문가, 초보자, 중간)를 포함할 수도 있다. 이하에서 상세히 설명되는 바와 같이, 이들 변수들은 때때로 게임 "버켓(bucket)"이라고 하며, 고유 "버켓 ID"를 이용하여 식별된다. 각각의 게임은 상이한 게임 구성 변수들을 식별하기 위한 상이한 세트의 버켓 ID들을 포함할 수도 있다.
한 실시예에서, 모바일 장치 B는 208a 및 209a에서 접수확인(acknowledgement)을 전송한다. 마찬가지로, 모바일 장치 A의 접수확인은 208b 및 209b에서 전송된다. 만일 모바일 장치 A 또는 B의 접수확인이 지정된 기간 후에 수신되지 않는다면, 접속 데이터(207a)가 모바일 장치 B(212)에 재전송될 수도 있다. CDX 서비스(110)가 재시도를 개시하거나 및/또는 모바일 장치 A(120)가 재시도를 개시할 수도 있다.
도 2b는 3개의 상이한 모바일 장치(120-122)가 CDX 서비스 및 중매자 서비스(111)를 이용하여 P2P 접속에 대해 협상하는 더 상세한 예를 나타낸다. 도 2b는 또한, 접속을 확립하기 위해 모바일 장치(120-122)에 의해 이용되는 2개의 추가 서비스를 나타낸다: NAT 타입을 결정하기 위한 NAT 횡단 서비스(291)와, (예를 들어, ICE 접속 데이터 트랜잭션을 이용하여) 각각의 모바일 장치에 대한 풀(full) 데이터 접속을 결정하기 위한 NAT 횡단 서비스(290). 그러나, 본 발명의 기저 원리를 따르기 위해 별개의 서비스들이 요구되는 것은 아니라는 점에 유의한다. 예를 들어, 대안적 실시예에서, 이들 서비스(290-291) 각각에 의해 수행되는 NAT 횡단 기능은 CDX 서비스(110) 및/또는 중매자 서비스(111) 내에 직접 통합될 수도 있다. 마찬가지로, NAT 횡단 서비스(290-291) 양쪽 모두에 의해 수행되는 기능은 하나의 NAT 횡단 서비스 내에 통합될 수도 있다. 요약하면, 본 발명의 기저 원리를 따르기 위해 도 2b에 도시된 구체적인 기능 분리가 요구되지는 않는다.
이제 도 2b의 구체적인 세부사항을 참조하면, 220에서, 모바일 장치 A는 NAT 타입 요청을 NAT 횡단 서비스(291)에 전송한다. 응답하여, NAT 횡단 서비스(291)는 모바일 장치 A에 의해 이용되는 NAT 타입을 결정하기 위해 일련의 트랜잭션을 구현하는 단계를 포함하는 다양한 공지된 기술을 이용할 수도 있다. 예를 들어, NAT 횡단 서비스(291)는 모바일 장치 A의 NAT 상에서 상이한 IP 주소들과 포트들을 개방하고 상이한 IP/포트 조합을 이용하여 이들 포트를 통해 모바일 장치 A와 통신하려고 시도할 수도 있다. 이런 방식으로, 모바일 장치 A에 의해 이용되는 NAT는 전술된 NAT 타입(예를 들어, 풀 콘(full cone), 제한된 콘(restricted cone), 포트 제한된 콘(port restricted cone), 대칭) 또는 대안적 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(Hypertext Transfer Protocol Secure) 세션(예를 들어, HTTPS 요청/응답 트랜잭션을 이용하여)을 이용하여 중매자 서비스(111)와 통신한다. 매치 요청은, 모바일 장치 A(120)에 대해 앞서 결정된 NAT 타입과 홀 펀치 데이터(예를 들어, 공개 IP 주소 및 포트)를 포함할 수 있다. 멀티플레이어 게임을 포함하는 한 실시예에서, 매치 요청은 (예를 들어, 고유 플레이어 ID 코드를 이용한) 모바일 장치 A 상의 플레이어, 각 사용자가 플레이하기를 원하는 게임, 게임에 참여할 플레이어의 수, 및/또는 (도 2a에 관하여 전술된 바와 같은) 원하는 게임과 연관된 다른 게임 구성 변수를 식별할 수 있다.
223-225에서, 모바일 장치 B(121)에 대해 트랜잭션(220-222)에 대응하는 한 세트의 트랜잭션이 수행되고, 226-228에서, 모바일 장치 C(122)에 대해 트랜잭션(220-222)에 대응하는 한 세트의 트랜잭션이 수행된다. 따라서, 트랜잭션(228)에 후속하여, 중매자 서비스(111)는 모바일 장치(120-122) 3개 모두에 대해 매치 요청을 수신하였다. 이 특정 예에서, 매치 요청 결과, 멀티플레이어 게임과 같은 특정의 협력 세션에 대해 모바일 장치들(120-122)이 매치된다(예를 들어, 이들 모바일 장치들의 사용자들은 동일하거나 유사한 변수 세트에 의해 동일한 게임을 선택했을 수도 있음으로써, 결과적으로 중매자 서비스(111)에 의해 매치가 이루어진다).
중매자 서비스(111)는 각각의 매치 요청에 포함된 데이터를 이용하여 티켓 A를 생성하고, 229에서 모바일 장치 A에 전송한다; 티켓 B를 생성하고, 230에서 모바일 장치 B에 전송한다; 그리고, 티켓 C를 생성하여, 231에서 모바일 장치 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에서, 접속 데이터와 함께 티켓 A를 CDX 서비스(110)에 전송한다. 한 실시예에서, CDX 서비스(110)는 전술된 바와 같이 티켓 A를 처리하고, 234에서, 모바일 장치 B(121) 및 모바일 장치 C(122)에 (암호화될 수도 있는) 접속 데이터를 전송한다. 이들 트랜잭션에 대해, CDX 서비스(110)는 티켓 A에 포함된 모바일 장치 B 및 C에 대한 NAT 횡단 데이터를 이용할 수 있다.
236-238에서, 티켓 B를 이용하여 트랜잭션(232-234)에 대응하는 한 세트의 트랜잭션이 수행되고, 238-240에서, 티켓 C에 대해 트랜잭션(232-234)에 대응하는 한 세트의 트랜잭션이 수행된다. 따라서, 트랜잭션(240)에 후속하여, 각각의 모바일 장치들(120-122) 사이에서 접속 데이터가 공유되었다. 접속 데이터를 이용하여, 모바일 장치 A와 B 사이, 모바일 장치 A와 C 사이, 및 모바일 장치 A와 C 사이에 P2P 세션이 확립된다.
도 2c에 나타낸 바와 같이, 초대 서비스(112)는 (중매자 서비스(111) 대신에 또는 이에 추가하여) CDX 서비스(110)와 함께 이용될 수 있다. 한 실시예에서, 초대 서비스(112)는 특정의 모바일 장치 및/또는 사용자와의 P2P 접속을 위한 초대 요청을 처리한다. 초대 서비스(112)는 무상태(stateless) 서비스(즉, 각 무선 장치들 사이의 트랜잭션의 현재 상태를 바꾸지(tack) 않는 서비스)로서 구현될 수 있다.
이 특정 예를 참조하면, 250에서, 모바일 장치 A(120)는 NAT 타입 요청을 NAT 횡단 서비스(291)에 전송한다. 응답하여, NAT 횡단 서비스(291)는, (몇 가지가 위에서 설명되었던) 모바일 장치 A에 의해 이용되는 NAT 타입을 결정하기 위한 다양한 공지된 기술을 이용할 수도 있다. 251에서, 모바일 장치 A(120)는 CDX 서비스(110)에 대한 NAT 횡단 요청을 개시한다. 응답하여, CDX 서비스(110)는 이 요청에 이용되는 공개 IP 주소와 공개 포트 번호를 판독하여 이 정보를 모바일 장치 A(120)에 되전송할 수 있다. 전술된 바와 같이, 만일 장치가 NAT 뒤에 있다면, 그 공개 포트 및 IP 주소는 각각 그 사설 포트 및 IP 주소와 상이할 것이다. 따라서, 이용중인 NAT의 타입에 따라, 공개 IP 주소 및 포트는 모바일 장치에 도달하기 위해 NAT 장치를 통해 "홀을 펀치"하기 위해 이용될 수도 있다.
중매자 서비스에서와 같이, 한 실시예에서, 각 모바일 장치는 HTTPS(Hypertext Transfer Protocol Secure) 세션(예를 들어, HTTPS 요청/응답 트랜잭션을 이용하여)을 이용하여 초대 서비스(112)와 통신한다.
252에서, 모바일 장치 A(120)는 모바일 장치 A의 NAT 횡단 데이터(예를 들어, NAT 타입, 공개 IP 주소/포트)를 포함하는 초대 요청을 초대 서비스(112)에 전송한다. (이하에서 더 상세히 설명되는) 푸시 통보 서비스를 이용하는 실시예에서, 초대 요청은 모바일 장치 A의 푸시 토큰(push token)을 역시 포함할 수도 있다. 초대 요청(252)은 또한, 한 명 이상의 다른 사용자들/장치들 -이 경우에는, 모바일 장치 B(121) 및 모바일 장치 C(122)의 사용자들 -을 식별하는 식별 코드를 포함할 수 있다. 다양한 상이한 식별 코드 타입들이 이용될 수도 있다. 예를 들어, 멀티플레이어 게임의 경우, 식별 코드들은 게임-특유의 플레이어 ID 코드를 포함할 수도 있다. 음성/화상 채팅 세션의 경우, 식별 코드들은 모바일 장치 A의 "친구(buddy)" 목록의 사용자로부터 한 명 이상의 사용자들을 식별하는 전화 번호 또는 고유 ID 코드를 포함할 수도 있다.
한 실시예에서, 초대 서비스(112)는 초대 요청으로부터 식별 코드를 판독하고, 모바일 장치들(B 및 C) 각각의 위치파악을 위해 등록 데이터베이스(미도시)에서 룩업(lookup)을 수행한다. 한 특정 실시예에서, 모바일 장치들(B 및 C) 각각은 초대 서비스(112)로부터 푸시 통보를 수신하는 푸시 서비스에 앞서 등록되었다. 이와 같이, 본 실시예에서, 초대 서비스(112)는, 각각 253 및 254에서 모바일 장치 B(121) 및 모바일 장치 C(122)에 초대 요청을 푸시하는 푸시 통보 서비스를 이용한다. 푸시 통보 서비스에 관련된 추가 상세사항이 이하에서, 그리고 앞서 참조한 푸시 통보 애플리케이션에서 설명된다(예를 들어, 도 11 및 도 12와 관련 본문 참조).
한 실시예에서, 초대 요청(253 및 254)은, 도 3에서 예시되고 도 2a 및 도 2b를 참조하여 전술된 티켓 데이터 구조를 포함한다. 구체적으로는, 모바일 장치 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 횡단 서비스(291)와 통신하여 그 NAT 타입을 결정할 수도 있고, 256에서, 모바일 장치 B는 CDX 서비스(110)와 통신하여 그 NAT 횡단 데이터를 결정할 수도 있다(예를 들어, 공개 IP 주소/포트). 257에서, 모바일 장치 B는, 모바일 장치 A 및 모바일 장치 B의 식별 코드, NAT 횡단 데이터, 및 푸시 통보 서비스가 이용되는 경우에는 모바일 장치 A 및 B에 대한 푸시 토큰을 포함하는 초대 서비스(112)에 초대 응답을 전송한다. 258에서, 모바일 장치 B는 NAT 횡단 서비스(290)와 통신함으로써 그 현재의 접속 데이터를 회수할 수 있다. 259에서, 모바일 장치 B는 그 현재의 접속 데이터와 함께 그 티켓(티켓 B)을 CDX 서비스(110)에 전송한다. 응답하여, 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)는 전술된 바와 같이 티켓을 처리하고 모바일 장치 A의 접속 데이터를 모바일 장치 B에 포워딩한다. 마지막으로, 263에서, 모바일 장치 A 및 B는 직접 P2P 접속을 개방하기 위해 교환된 접속 데이터를 이용한다. 후술되는 바와 같이, 모바일 장치 A 및 B의 NAT 타입들이 비호환인 경우, 모바일 장치 A와 B 사이의 통신을 가능케하기 위해 중계 서비스가 이용될 수도 있다.
264-272에서, 모바일 장치 C(122)와 모바일 장치 A는 모바일 장치 B와 A에 대하여 255-263에서 설명된 P2P 접속을 확립하기 위하여 일련의 트랜잭션을 실행할 수 있다. 구체적으로는, 624에서, 모바일 장치 C(122)는 그 NAT 타입을 결정하기 위해 NAT 횡단 서비스(291)와 통신하며, 265에서, 그 NAT 횡단 데이터(예를 들어, 공개 IP 주소/포트)를 결정하기 위해 CDX 서비스(110)와 통신한다. 266에서, 모바일 장치 C는 모바일 장치 C와 모바일 장치 A의 NAT 타입, NAT 횡단 데이터 및 푸시 토큰(푸시 통보 서비스가 이용되는 경우)을 포함하는 초대 응답을 전송한다. 267에서, 모바일 장치 C는 NAT 횡단 P2P 서비스(290)를 통해 그 현재의 접속 데이터를 회수하고, 268에서, 모바일 장치 C는 그 접속 데이터를 티켓 C에 첨부하여 티켓 C를 CDX 서비스(110)에 전송한다. CDX 서비스(110)는 전술된 바와 같이 티켓을 처리하고 모바일 장치 C의 접속 데이터를 모바일 장치 A(120)에 포워딩한다.
269에서, 모바일 장치 A(120)는, 모바일 장치 A 및 C 양쪽 모두의 NAT 타입, NAT 횡단 데이터, 및 푸시 토큰(푸시 서비스가 이용되는 경우)을 포함하는 초대 서비스(112)로부터의 모바일 장치 C의 초대 응답을 수신한다. 270에서, 모바일 장치 A는 NAT 횡단 서비스(290)로부터 그 현재의 접속 데이터를 회수하고, 그 현재의 접속 데이터를 티켓 A에 첨부하며, 271에서 티켓 A를 CDX 서비스(110)에 전송한다. 대안으로서, 모바일 장치가 트랜잭션(261)에서 그 접속 데이터를 결정했기 때문에 트랜잭션(270)은 요구되지 않을 수도 있다. CDX 서비스(110)는 전술된 바와 같이 티켓 A를 처리하고 모바일 장치 A의 접속 데이터를 모바일 장치 C에 포워딩한다. 마지막으로, 272에서, 모바일 장치 A 및 C는 직접 P2P 접속(272)을 확립하기 위해 교환된 접속 데이터를 이용한다.
한 실시예에서, 초대 서비스(112) 및 중매자 서비스(111)는 모바일 장치에 데이터를 푸시하기 위해 푸시 통보 서비스(미도시)에 의존할 수 있다. 예를 들어, 도 2c에서, 초대 요청(253 및 254)이 푸시 통보 서비스를 이용하여 모바일 장치 B(121) 및 C(122)에 푸시될 수도 있다. 마찬가지로, 도 2a에서, 티켓 A 및 B가 모바일 장치 A(120) 및 B(121)에 푸시될 수도 있다. 한 실시예에서, 모바일 장치가 네트워크 상에서 작동되면, 모바일 장치는 푸시 통보 서비스에 의해 액세스가능한 중앙 등록 디렉토리에서 그 푸시 토큰을 등록한다. 한 실시예에서, 등록 디렉토리는 패스워드 보호된 사용자 ID 또는 전화 번호를 푸시 토큰과 연관시킨다. 만일 디렉토리에서 푸시 토큰이 식별될 수 있다면, 푸시 통보 서비스는 푸시 통보를 모바일 장치에 전송하기 위해 그 푸시 토큰을 이용할 수 있다. 한 실시예에서, 푸시 통보 서비스는, 본 출원의 양수인에 의해 설계되고, 예를 들어, 앞서 참조된 푸시 통보 애플리케이션에서 설명된 Apple Push Notification Service (“APNS”)이다. 그러나, 도 2a 내지 도 2c에 도시된 본 발명의 실시예에서는 푸시 통보 서비스가 요구되지 않는다는 점에 유의해야 한다. 예를 들어, CDX 서비스(110)가 여기서 설명된 그 동작을 수행하기 위해 푸시 통보는 요구되지 않는다.
도 4는 접속 데이터를 교환하기 위해 CDX 서비스(110)에 의해 구현될 수 있는 방법을 나타내고, 도 5는 접속 데이터를 교환하고 P2P 접속을 확립하기 위해 모바일 장치에 의해 구현될 수도 있는 방법을 나타낸다. 이들 방법들의 다양한 양태들이 도 1 내지 도 2c를 참조하여 이미 전술되었다. 특히, 이들 방법들은 도 1 내 지 도 2c에 도시된 네트워크 아키텍쳐의 정황 내에서 구현될 수도 있지만, 이들은 이러한 아키텍쳐로 한정되는 것은 아니다. 한 실시예에서, 방법들은, 프로세서에 의해 실행될 때 방법들의 동작들이 수행되게끔 하는 프로그램 코드로 구현된다. 이 프로그램 코드는 프로세서에 의해 실행되는 동안 랜덤 액세스 메모리("RAM")와 같은 머신-판독가능한 매체에 저장될 수도 있다. 프로세서는 범용 프로세서(예를 들어, Intel® CoreTM 프로세서) 또는 특별 목적 프로세서일 수도 있다. 그러나, 방법들은 하드웨어, 소프트웨어, 및 펌웨어의 임의 조합을 이용하여 구현될 수도 있다. 또한, 프로그램 코드는 하드 디스크 드라이브와 같은 비휘발성 저장 장치, 광 디스크(예를 들어, 디지털 비디오 디스크 또는 컴팩트 디스크), 또는 플래시 메모리 장치와 같은 비휘발성 메모리에 저장될 수도 있다.
이제 도 4에 도시된 방법을 참조하면, 401에서, 특정 모바일 장치 -이 예에서는 "모바일 장치 A"-에 대한 NAT 횡단 요청(때때로 "홀 펀치" 요청이라고도 함)이 수신된다. 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에서 판정되는 바와 같이 모든 접수확인이 수신되었다면, 다른 모바일 장치와의 P2P 세션을 확립하기 위해 507에서 수신된 접속 데이터가 이용된다.
백업 통신 채널을 확립하고 이용하기 위한 장치 및 방법
현재의 모바일 장치들은 다양한 상이한 통신 채널을 통해 통신할 수 있다. 예를 들어, Apple iPhoneTM은 Wi-Fi 네트워크(예를 들어, 802.11b, g, n 네트워크); 3G 네트워크(예를 들어, UMTS(Universal Mobile Telecommunications System) 네트워크, HSUPA(High-Speed Uplink Packet Access) 네트워크 등); 및 (PAN(personal area network)이라고 알려진) Bluetooth 네트워크를 통해 통신할 수 있다. 향후의 모바일 장치들은, 몇 가지 예를 들자면, WiMAX, IMT(International Mobile Telecommunication) Advanced, 및 LTE(Long Term Evolution) Advanced와 같은 추가적인 통신 채널들을 통해 통신할 수 있을 것이다.
동작시에, 현재의 모바일 장치들은 한 세트의 가용 채널들로부터 하나의 1차 통신 채널을 선택한다. 예를 들어, 모바일 장치들은 종종, 이용가능한 경우에는 Wi-Fi 접속을 선택하고 Wi-Fi 접속이 이용가능하지 않다면 셀룰러 데이터 접속(예를 들어, UTMS 접속)을 선택하도록 구성된다.
본 발명의 한 실시예에서, 한 그룹의 모바일 장치가 처음에, 표준 ICE 접속 데이터 교환을 이용하여 및/또는 전술된 접속 데이터 교환 기술을 이용하여 1차 피어-투-피어("P2P") 통신 채널을 확립한다. 그 다음 모바일 장치들은 임의의 1차 채널이 고장날 경우 백업 채널로서 이용되는 하나 이상의 2차 통신 채널을 확립하기 위해 1차 채널을 통해 접속 데이터를 교환할 수도 있다. 한 실시예에서, 2차 통신 채널은 이들 채널들을 통해 "심박 패킷(heartbeat packet)"을 주기적으로 전송함으로써 NAT 방화벽을 통해 개방으로 유지된다.
본 명세서에서 사용될 때, 통신 "채널"이란, 2개의 모바일 장치 사이의 전체 네트워크 경로(full network path)를 말하고, 통신 "링크"란 통신 경로에서 이용되는 하나의 특정한 접속을 말한다. 예를 들어, 만일 장치 A가 Wi-Fi 접속을 이용하여 인터넷에 접속되고 장치가 B가 3G 접속을 이용하여 인터넷에 접속되면, 장치 A와 장치 B 사이의 "채널"은 Wi-Fi 링크 및 3G 링크 양쪽 모두에 의해 정의된다; 장치 A는 Wi-Fi 통신 "링크"를 가지며; 장치 B는 3G 통신 "링크"를 가진다. 이와 같이, 만일 장치 A가 Wi-Fi 링크로부터 3G 링크로 전환하면, 장치 B의 3G 링크가 동일하게 유지된다는 사실에도 불구하고 장치 A와 장치 B 사이의 "채널"이 변한다.
모바일 장치가 1차 및 2차 통신 채널을 확립하는 구체적인 예가 이제 도 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을 이용하는 제3 채널. 한 실시예에서, 모바일 장치 A 및 B는 우선순위화 방법에 기초하여 1차 통신 채널로서 이들 채널들 중 하나를 선택할 것이며, 백업 통신 채널로서 나머지 3개 채널을 선택할 것이다. 예를 들어, 한 우선순위화 방법은, 1차 채널로서 가장 높은 대역폭을 갖는 채널을 선택하고 2차 채널로서 나머지 채널들을 선택하는 것일 수도 있다. 만일 2개 이상의 채널이 비슷한 대역폭을 가진다면, 우선순위화 방법은 (사용자가 하나 이상의 채널 이용에 대한 요금을 지불한다고 가정하면) 최소 비용의 채널을 선택하는 것을 포함할 수도 있다. 대안으로서, 우선순위화 방법은 1차 채널로서 최소 비용의 채널을 선택하고, 각 채널의 비용이 동일하면, 가장 높은 대역폭의 채널을 선택할 수도 있다. 본 발명의 기저 원리와 여전히 호환되면서 다양한 상이한 우선순위화 방법이 구현될 수도 있다.
모바일 장치 A(601) 및 C(603)는 (예를 들어, CDX 서비스(110)를 이용하여 접속 데이터를 교환함으로써) 1차 통신 채널을 확립하기 위해 전술된 기술들을 이용할 수도 있다. 대안으로서, 모바일 장치(601, 603)는 접속 데이터를 교환하기 위해 표준 인터넷 접속 확립("ICE") 트랜잭션을 구현할 수도 있다. 1차 채널이 어떻게 확립되는지에 관계없이, 일단 확립되면, 모바일 장치 A(601) 및 C(603)는 1차 통신 채널을 통해 2차 통신 채널에 대한 접속 데이터를 교환할 수 있다. 예를 들어, 만일 도 6의 1차 통신 채널이 통신 링크(606) 및 통신 링크(609)를 포함한다면, 이 접속은, 일단, 확립되면, 통신 링크(605 및 609)를 포함하는 2차 통신 채널에 대한 접속 데이터를 교환하는데 이용될 수도 있다. 이 예에서, 1차 통신 채널을 통해 교환된 접속 데이터는, 모바일 장치들 각각에 대한 공개 및 사설 IP 주소/포트를 포함한, NAT(611 및 613)에 대한 NAT 횡단 데이터 및 NAT 타입 데이터를 포함할 수도 있다.
일단 2차 통신 채널이 확립되고 나면, 이 채널들은 심박 패킷을 이용하여 개방된 상태로 유지된다. 예를 들어, 장치 A가 작은 "심박" 패킷을 장치 C에 주기적으로 전송하거나, 및/또는 장치 A가 작은 "심박" 패킷을 장치 C에 주기적으로 전송하여, 2차 채널들에 대해 이용되는 NAT 포트들이 개방 상태로 유지되는 것을 보장한다(NAT는 종종 비활성으로 인해 포트를 폐쇄한다). 심박 패킷은 페이로드가 없는 UDP 패킷일 수도 있지만, 본 발명의 기저 원리는 임의의 특정 패킷 포맷으로 한정되는 것은 아니다. 심박 패킷은 그 페이로드 헤더에 자체-식별 타입 필드를 갖춘 UDP 패킷일 수도 있고, 채널 생존 시간값을 포함하지만 이것으로만 한정되지는 않는 선택사항적인 추가의 포멧팅된 정보를 포함할 수도 있다.
도 7에 나타낸 바와 같이, 각각의 모바일 장치(601)는 1차 및 2차 통신 채널의 목록을 포함하는 데이터 구조(710)(예를 들어, 표, 텍스트 파일, 데이터베이스 등)를 저장하고 유지한다. 별개의 엔트리가 각 통신 채널에 대해 제공되며, 그 채널을 이용하는데 필요한 접속 데이터(예를 들어, 사설/공개 IP 주소, NAT 타입 등)와 그 채널의 현재 상태(예를 들어, 1차, 제1의 2차, 제2의 2차 등)를 포함한다.
한 실시예에서, 각각 통신 링크(605) 및 통신 링크(606)를 통한 통신에 대해 통신 인터페이스(701 및 702)가 이용된다. 고장 검출 모듈(705)이 모바일 장치(601) 상에서 실행되어 특정한 통신 인터페이스/링크가 고장나거나 지정된 임계치 아래로 열화된 때를 검출할 수 있다. 응답하여, 링크 관리 모듈(706)은 1차/2차 접속 데이터(710)를 판독하여 가장 높은 우선순위를 갖는 2차 채널을 1차 채널로 승급할 수 있다. 2차 채널의 우선순위화는, (예를 들어, 대역폭, 비용, 신뢰성 등에 기초하여) 1차 채널에 대해 앞서 언급한 것과 동일한 원리를 이용하여 달성될 수도 있다. 일단 2차 채널이 선택되고 나면, 링크 관리 모듈(706)은 다른 모바일 장치들 상의 링크 관리 모듈에 링크 고장 표시를 전송하여, 이들 장치들에게 2차 통신 채널을 1차 통신 채널로 승급할 것을 지시할 수 있다. 그러면 이들 장치들은 선택된 1차 채널과 연관된 접속 데이터의 이용을 개시할 것이다.
한 실시예에서, 2차 통신 채널들 중 하나로의 전환을 강제하기 위해 1차 통신 채널의 완전한 "고장"은 요구되지 않는다. 예를 들어, 한 실시예에서, 만일 1차 통신 채널이 충분히 열화된다면(예를 들어, 특정한 대역폭, 비트레이트, 또는 신뢰성 임계치 아래로), 2차 채널로의 변경이 여기서 설명된 바와 같이 구현될 수도 있다. 한 실시예에서, 2차 채널로의 전환은, 2차 채널이 현재의 1차 채널보다 더 나은 성능(예를 들어, 대역폭, 비트레이트 또는 신뢰성)을 지원할 수 있는 경우에만 수행된다.
도 8a는, 네트워크(610)에 직접 접속되고 사설 네트워크 접속(620)을 통해 장치 C(603)에 접속된 모바일 장치 B(602)가 추가된 도 6에 도시된 네트워크 구성과 동일한 네트워크 구성을 나타낸다. 사설 네트워크(620)는, 예를 들어, 장치 B(602)와 장치 C(603) 사이의 Bluetooth PAN 접속일 수도 있다. 이 예로부터, 1차 채널로부터 2차 채널로의 전환은 네트워크 토폴로지를 극적으로 변경시킬 수도 있다는 것을 알 수 있다. 예를 들어, 도 8b에 도시된 바와 같이, 만일 모바일 장치에 대한 1차 채널(801)이 통신 링크(609)를 포함하고(그 결과, 장치 장치들 A, B, C 사이에 직접적인 접속이 형성됨) 2차 채널이 사설 네트워크(620)를 포함한다면, 장치 A 및 장치 C가 사설 네트워크를 이용하여 통신할 수 있는 유일한 길은 장치 B를 통하는 것이기 때문에 네트워크 토폴로지는 도 8c에 도시된 바와 같이 변경될 수도 있다. 이것은 단 3개의 장치만을 갖는 간략화된 예이지만, 상당히 많은 수의 장치들이 이용되어, 결과적으로, 1차 및 2차 통신 채널 사이의 전환시에 많은 상이한 네트워크 토폴로지 구성이 발생할 수 있다.
2차 채널을 확립하고 유지하기 위한 방법의 한 실시예가 도 8에 나타나 있다. 한 실시예에서, 이 방법은 각 모바일 장치 상의 링크 관리 모듈(706)에 의해 실행될 수도 있다. 그러나, 이 방법은 임의의 특정한 장치 구성으로 한정되는 것은 아니다.
901에서, 1차 P2P 통신 채널이 선택된다. 앞서 언급한 바와 같이, 미리정의된 우선순위화 방법에 기초하여 1차 채널이 선택될 수도 있다. 예를 들어, 다른 통신 채널 타입들에 앞서 소정의 통신 채널 타입이 우선순위화될 수도 있다. 채널들은, 대역폭, 사용 비용, 및/또는 신뢰성과 같은 변수들에 기초하여 우선순위화될 수도 있다.
902에서, 백업 P2P 통신 채널들이 확립된다. 한 실시예에서, 이것은 1차 통신 채널을 통해 모든 모바일 장치들 간에 접속 데이터를 공유함으로써 달성된다. 903에서, 백업 채널들이 유지된다. 한 실시예에서, 이것은 2차 통신 채널을 통해 주기적으로 (예를 들어, 주기적 심박 패킷의 형태로) 데이터를 전송하는 것을 포함한다.
904에서, 만일 1차 P2P 채널이 고장나면(예를 들어, 특정 모바일 장치의 통신 링크가 다운되거나 모바일 장치가 통신 링크의 범위 바깥으로 이동하는 이유 때문에), 905에서, 모바일 장치들은 가장 높은 우선순위의 백업 채널을 1차 채널로 승급한다. 한 실시예에서, 이것은 고장난 링크를 갖는 모바일 장치가 2차 채널을 통해 그 링크의 고장 통보를 다른 장치들에 전송하는 것을 포함한다. 마지막으로, 906에서, 백업 채널이 1차 채널로 되고, 프로세스는 902로 되돌아간다(여기서, 임의의 추가 백업 채널들이 발견되고 우선순위화 방법에 추가된다).
피어-투-피어(P2P) 통신 채널을 확립하는 초대 서비스를 위한 장치 및 방법
도 10에 나타낸 바와 같이, CDX 서비스(110), 중매자 서비스(111) 및 초대 서비스(112)(이들의 일부 실시예는 앞서 설명되었음)에 추가하여, 본 발명의 한 실시예는 등록/디렉토리 서비스(1052), 푸시 통보 서비스(1050), 및 중계 서비스(1051)를 포함할 수 있다. 앞서 언급한 바와 같이, 일 실시예에서 초대 서비스(112) 및/또는 중매자 서비스(111)는 등록된 모바일 장치를 식별하기 위해 등록/디렉토리 서비스(1052)를 이용하고 모바일 장치에 데이터를 푸시하기 위해 푸시 통보 서비스(1050)를 이용할 수 있다. 한 실시예에서, 모바일 장치가 네트워크 상에서 동작할 때, 모바일 장치는 "푸시 토큰"(때때로 푸시 통보 애플리케이션에서는 "통보 서비스 계정 식별자"라고 함)을 패스워드 보호된 사용자 ID 또는 전화 번호와 연관시킴으로써, 그 푸시 토큰을 등록/디렉토리 서비스(1052)에 의해 유지되는 데이터베이스에 등록한다. 만일 등록 디렉토리에서 푸시 토큰이 식별된다면(예를 들어, 사용자 ID를 이용한 질의를 수행함으로써), 푸시 통보 서비스(1050)는 모바일 장치에 푸시 통보를 전송하기 위해 푸시 토큰을 이용할 수 있다. 한 실시예에서, 푸시 통보 서비스는, 본 출원인의 양수인에 의해 설계되고, 예를 들어, 앞서 참조된 푸시 통보 애플리케이션에서 설명된 Apple Push Notification Service (“APNS”)이다.
도 11은 2개의 모바일 장치들 사이의 직접적 P2P 접속을 확립하기 위해 푸시 통보 서비스(1051)가 이용되는 본 발명의 실시예를 나타내고, 도 12는 중계 서비스(1051)를 통해 P2P 접속을 확립하는데 이용되는 실시예를 나타낸다. 후술되는 바와 같이, P2P 접속을 확립하기 위해 중계 서비스(1051)를 이용할지의 여부에 관한 결정은 모바일 장치들 사이의 직접적 P2P 접속의 확립 가능성에 기초(예를 들어, NAT 호환성 문제에 기초)할 수도 있다.
이제 도 11을 참조하면, 1101에서, 모바일 장치 A(120)는 모바일 장치 B(121)를 초대하는 초대를 전송하여 모바일 장치 B를 P2P 통신 세션(예를 들어, 협력적 비디오 게임, P2P 비디오 채팅 등)에 초대한다. 한 실시예에서, 초대는, 특정한 온라인 애플리케이션 정황 내에서 모바일 장치 B(121)를 식별하는 사용자 ID 코드(및/또는 모바일 장치 B의 사용자)를 포함한다. 예를 들어, 사용자 ID 코드는 특정한 멀티플레이어 P2P 게임에 대한 플레이어 ID일 수 있고, 예를 들어, UUID(Universally Unique Identifier)의 형태를 취할 수도 있다. 대안으로서, 일부 실시예에서, ID 코드는 모바일 장치 B(121)의 전화 번호일 수도 있다. 게임 ID 코드는, 모바일 장치 A가 모바일 장치 B에게 참여할 것을 초대하고 있는 멀티플레이어 게임을 식별하는데 이용될 수도 있다. 버켓 ID는 (중매자 서비스에 관하여 여기서 기술된 바와 같은) 그 게임에 대한 구성을 식별하는데 이용될 수도 있다.
초대(1101)는 또한, 모바일 장치 A(120)를 식별하는 ID 코드, 및 모바일 장치 A와 연관된 NAT 횡단/접속 데이터(예를 들어, 모바일 장치 A의 공개/사설 IP 주소 및 포트, 및 장치 A의 NAT 장치의 NAT 타입)를 포함할 수도 있다. NAT 횡단/접속 데이터 또는 NAT 타입 데이터는, (예를 들어, 도 2a 내지 도 2c에 관하여 전술된 것과 같은 NAT 횡단, NAT 타입 및 접속 데이터 트랜잭션을 통해) 초대 요청(1101)에 앞서 모바일 장치 A에 의해 앞서 결정되었을 수도 있다. 앞서 언급한 바와 같이, 초대 요청(1101)은 HTTPS 요청의 형태를 취할 수 있다. 또한, 추가 보안을 위해, 초대 요청(1101)은 미리명시된 인증국(pre-specified certificate authority)에 의해 서명된 클라이언트 인증서를 포함할 수 있다.
모바일 장치 B를 식별하는데 이용되는 ID 코드의 특정한 타입에 관계없이, ID 코드가 초대 서비스(112)에 의해 수신되고, 1102에서, 초대 서비스(112)는, 모바일 장치 B에 통보를 푸시하는데 이용되는 푸시 토큰("푸시 토큰 B")과 같은 통보 서비스 계정 식별자를 식별하기 위해 (도 11에는 도시되지 않은) 디렉토리 서비스(1052)에서 룩업을 수행할 수 있다. 한 실시예에서, 룩업 동작은 초대가 허용되어야 하는지를 결정하기 위해 수회의 검사를 수행할 수 있다. 우선, 모바일 장치 A에 대한 식별 코드("ID-A")와 장치 A의 푸시 토큰("푸시 토큰 A")이 디렉토리 서비스 데이터베이스 내의 등록된 연관임을 확인할 수 있다. 룩업 동작(1102)은 또한, 모바일 장치 A의 사용자가 모바일 장치 B의 사용자를 초대하는 것이 허용되어 있다는 것을 확인할 수 있다(예를 들어, 모바일 장치 B의 사용자는 B의 친구로서 등록된 다른 사용자들만이 사용자 B를 초대할 수 있다고 명시할 수 있다; 또는 어떠한 초대도 허용되지 않는다고 명시할 수 있다). 한 실시예에서, 이들 검사 중 임의의 것이 실패하면, 초대는 취소되고, 초대 서비스(112)는 모바일 장치 A에 에러(error)를 반환한다.
본 실시예에서는 "푸시 토큰"이 설명되고 있지만, 본 발명의 기저 원리는 "푸시 토큰"의 이용이나 모바일 장치들을 인증하고 모바일 장치들에 통보를 푸시하기 위한 기타 임의의 특정 데이터 구조의 이용으로 한정되지 않는다는 점에 유의해야 한다.
한 실시예에서, 푸시 토큰이 식별된 후에, 초대 서비스(112)는, 초대 세션에 할당되고 모든 추가의 트랜잭션들에서 세션을 식별하는데 이용되는, 보안된 1회용 "세션 토큰"을 생성할 수 있다. 그 다음, 세션 토큰의 사본이 모바일 장치 A(120)에 되전송되고, 초대 요청과 함께 모바일 장치 B에 전송된다. 한 실시예에서, 세션 토큰은 전술된 티켓 데이터 구조와 함께 이용되고, 또 다른 실시예에서는, 세션 토큰만이 이용된다.
1103에서, 초대 서비스(112)는 푸시 요청을 푸시 통보 서비스(1050)에 전송한다. 한 실시예에서, 푸시 요청은, 모바일 장치 A에 대한 NAT 횡단 데이터, 장치 A의 ID 코드, 푸시 토큰 A, 장치 B의 ID 코드, 및 푸시 토큰 B를 포함할 수 있다. 한 실시예에서, 이 정보는 "티켓" 데이터 구조 내에 패키징되고 전술된 바와 같이 암호화될 수도 있다. 또 다른 실시예에서, 데이터는 단순히 초대 세션 ID와 함께 전송된다.
이 예에서 모바일 장치 B(121)는 푸시 통보 서비스(1050)에 등록되었기 때문에, 푸시 통보 서비스(1050)는 1104에서 모바일 장치 B(121)의 위치를 파악하고 모바일 장치 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 접속 시도의 검출시에, 2개의 모바일 장치들 중 하나는 특별한 "중계 초대"를 초대 서비스(112)에 전송할 수도 있다. 응답하여, 서비스는 (1201에서 시작하는) 도 12에 관하여 이하에서 설명되는 일련의 중계 트랜잭션을 직접 개시할 수도 있다.
1106에서, 초대 서비스(112)는 모바일 장치들 A와 B 사이의 직접적 P2P 접속이 가능성있는지를 판정하기 위해 호환성 검사를 수행할 수 있다. 예를 들어, 한 실시예에서, 만일 모바일 장치 B로부터 수신된 수락(1105)이 이것이 이전의 실패한 직접 접속 시도로부터의 재시도(또는 이전의 실패한 직접적 접속 시도의 지정된 회수)라는 것을 표시한다면, 초대 서비스는 직접적 P2P 접속이 가능성없다고 결론을 내릴 수도 있다. 초대 서비스(112)는, 모바일 장치들 A와 B의 NAT 장치들이 직접적 P2P 접속을 지원하는지를 판정하기 위해 모바일 장치들 A와 B에 대한 NAT 타입 데이터를 비교할 수도 있다. NAT 타입들의 소정 조합은 P2P 접속의 확립에 비호환인 것으로 알려져 있다. 예를 들어, 직접적 P2P 접속을 확립하기 위해 폐쇄형/방화벽형 NAT를 제외한 기타 임의의 다른 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의 수락을 포함하는 푸시 요청(1107)을 푸시 통보 서비스(1050)에 전송할 수 있다. 푸시 요청(1107) 및 푸시 통보 서비스(1050)로부터 모바일 장치 A로의 후속된 푸시 전달(1108)은, 세션 토큰, 양쪽 모바일 장치 A와 B의 푸시 토큰, ID 코드, 및/또는 NAT 횡단/접속 데이터를 포함할 수 있다. 한 실시예에서, 이 정보는 전술된 "티켓" 데이터 구조(예를 들어, 도 2a 내지 도 2c 및 관련 본문 참조) 내에 패키징될 수도 있으며 고유 키를 이용하여 암호화될 수도 있다. 대안으로서, 이 정보는 간단히 고유 초대 세션 ID와 함께 전송될 수도 있다. 초대 서비스(1050)는 직접적 접속이 시도될 것이라는 것을 모바일 장치 B에게 통보할 수도 있다.
이 단계에서, 모바일 장치 A와 B는 직접적 P2P 접속을 확립하기에 충분한 정보를 가진다. 한 실시예에서, 이것은 전술된 바와 같은 CDX 서비스(110)를 이용하여 달성된다. 예를 들어, 모바일 장치 B는 그 접속 데이터를 티켓 B에 첨부하고, 1109에서, (접속 데이터와 함께) 티켓 B를 CDX 서비스에 전송한다. 이 트랜잭션 직전에, 모바일 장치 B는, 그 접속 데이터가 현행임을 보장하기 위하여 도 2b에 도시된 트랜잭션(235)과 같은 트랜잭션을 구현할 수도 있다. 그 다음 CDX 서비스(110)는 (예를 들어, 전술된 바와 같은 고유 세션 키를 이용하여) 티켓을 인증하고, 모바일 장치 B의 접속 데이터를 추출하며, 1110에서 그 접속 데이터를 모바일 장치 A에 포워딩한다. 마찬가지로, 모바일 장치 A는 그 접속 데이터를 티켓 A에 첨부하고, 1111에서, (접속 데이터와 함께) 티켓 A를 CDX 서비스(110)에 전송한다. 이 트랜잭션 직전에, 모바일 장치 A는, 그 접속 데이터가 현행임을 보장하기 위하여 도 2b에 도시된 트랜잭션(232)과 같은 트랜잭션을 구현할 수도 있다. 그 다음 CDX 서비스(110)는 (예를 들어, 전술된 바와 같은 고유 세션 키를 이용하여) 티켓을 인증하고, 모바일 장치 A의 접속 데이터를 추출하며, 1112에서 그 접속 데이터를 모바일 장치 B에 포워딩한다. 마지막으로, 1113에서, 모바일 장치 A와 B는 교환된 접속 데이터를 이용하여 직접적 P2P 접속으로 진입한다.
이제 도 12를 참조하면, 만일 호환성 검사(1106)가 직접적 P2P 접속이 가능성없다고 판정하면, 초대 서비스(112)는 각 모바일 장치에 의해 이용될 중계 호스트를 결정하기 위해 중계 서비스(1051)에 중계 룩업 요청(1201)을 전송할 수 있다. 요청(1201)은, 모바일 장치 A와 B 양자 모두에 대한 적절한 중계 호스트를 선택하기 위해 중계 서비스(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에서, 초대 서비스는 중계 접속이 이루어질 것이라는 표시를 포함하는 중계 응답(1203)을 모바일 장치 B(121)에 전송한다. 한 실시예에서, 중계 응답(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 횡단/접속 데이터가 중계 서비스(1051)에 의해 결정되어 (예를 들어, 장치들에 대한 공개 IP/포트를 결정함으로써) 각각 모바일 장치 A와 B에 반환될 수도 있다. 한 실시예에서, 중계 서비스(1051) 및 모바일 장치 A와 B는, 당업자라면 이해하는 바와 같이 NAT 또는 방화벽 뒤쪽의 요소가 TCP 또는 UDP 접속을 통해 인입 데이터를 수신하는 것을 허용하는 "TURN"(Traversal Using Relay NAT) 프로토콜을 구현한다.
1208에서, 모바일 장치 A는 1209에서 푸시 통보 서비스에 포워딩되고 1210에서 모바일 장치 B에 푸시되는 중계 업데이트를 초대 서비스(112)에 전송한다. 마찬가지로, 1211에서, 모바일 장치 B는, 1212에서 푸시 통보 서비스에 포워딩되고 1213에서 모바일 장치 A에 푸시되는 중계 업데이트를 초대 서비스(112)에 전송한다. 모바일 장치 A에 의해 전송된 중계 업데이트는 세션 토큰, 각 장치의 ID 코드, 및 1206 및 1207에서 중계(즉, 모바일 장치 A가 그 NAT 횡단/접속 데이터를 모바일 장치 B에 전송하는 것 및 그 반대의 경우)에 의해 결정된 NAT 횡단/접속 데이터를 포함할 수 있다. 한 실시예에서, 중계 업데이트 동작은 각 모바일 장치의 NAT 정보가 변할 수도 있기 때문에 수행된다.
마지막으로, 1214 및 1215에서, 모바일 장치 A와 B는 각각 중계 서비스(1051)를 통해 P2P 접속을 확립한다. 한 실시예에서, 중계 접속은 모바일 장치 A가 모바일 장치 B의 NAT 횡단/접속 데이터를 중계 서비스(1051)에 전송할 때 및 그 반대의 경우에 확립될 수 있음으로써, 중계 서비스가 각 피어의 중계 호스트(1302-1303)로의 올바른 경로를 결정하는 것을 허용한다.
전술된 기술을 이용하여, 초대 서비스(112)는, 방대한 수의 모바일 장치들을 갖는 대규모 시스템에서도, 고유하게 스케일가능하고 탄력있는 무상태 서비스(stateless service)로서 구현될 수도 있다. 예를 들어, 푸시 통보 서비스(1050)는 본질적으로 콘텐츠의 위치를 파악하고 콘텐츠를 등록된 모바일 장치들에 푸시할 수 있기 때문에, 초대 서비스가 각 장치의 현재 위치를 추적할 것이 요구되지 않는다. 추가적으로, 장치들은 각 요청과 응답을 갖는 전체 세션 상태 데이터를 전송할 수도 있기 때문에, 초대 서비스가 어떠한 접속당 상태 정보도 유지할 것이 결코 요구되지 않음으로써, 초대 서비스의 저장 및 처리 요건을 저감한다. 이러한 구현은 대규모 시스템에서 특히 유용하다.
온라인 세션에 대해 사용자들을 매치하기 위한 시스템 및 방법
도 15에 나타낸 바와 같이, 중매자 서비스(111)의 한 실시예는, 매치 요청을 수신하고 매치 응답을 모바일 장치(120-122)에 푸시하기 위한 중매자 디스패처(dispatcher, 1501); 매치 요청을 요청 테이블(1502)에 저장하고 매치가능한 세트 데이터를 매치가능한 세트 식별자("MSI") 표(1503)에 저장하기 위한 데이터베이스(1512); 및 데이터베이스(1512)로부터 매치 요청을 가져오고 매치 동작을 수행하며, 매치 결과를 데이터베이스(1512)에 되저장하기 위한 하나 이상의 중매자(1510)를 포함할 수 있다. 그러나, 본 발명의 기저 원리는 도 15에 도시된 특정 아키텍쳐로 한정되지 않는다는 점에 유의해야 한다.
한 실시예에서, 중매자 디스패처(1501)는 중매자 서비스(111)에 대한 인터페이스로서 작용하며, 모바일 장치(120-122)로부터 요청을 수신하고, 이들 요청을 데이터베이스(1512)에 요청을 저장하라는 명령으로 변환하고, 데이터베이스(1512)로부터의 매치 결과를 판독하며, 이들 결과를 변환하여 모바일 장치(120-122)에 저장한다.
동작시, 새로운 매치 요청이 도달하면, 중매자 디스패처(1501)는 그 요청을 요청 테이블(1502)의 한 행 내에 저장할 수 있다. 한 실시예에서, 디스패처(1501)는 (각각 모바일 장치 A, B, 및 C에 대응하는) 도 15에서 간단히 "A", "B", "C"라고 나타낸 요청 ID("RID") 코드를 각 매치 요청에 할당한다. 도 15에서는 간소화를 위해 문자 지정을 이용하여 도시되어 있지만, RID 코드는 데이터베이스 내의 매치 요청을 추적하는데 적합한 문자열, 정수, 또는 기타 임의의 변수 타입일 수도 있다.
각 매체 요청에는 요청 테이블(1502)에 저장된 매치가능한 세트 식별자("MSI")가 할당될 수도 있다. 한 실시예에서, MSI는 매치가 요청되고 있는 특정한 애플리케이션 및/또는 그 애플리케이션에 대해 이용되는 구성 파라미터를 식별할 수 있다. 예를 들어, MSI 값 12:4는 식별자 "12"를 갖는 특정의 멀티플레이어 게임을 식별하고, 식별자 "4"를 갖는 게임에 대한 특정한 구성을 식별할 수도 있다. 더 구체적으로는, ID 코드 12는 특정한 멀티플레이어 레이싱 게임을 식별하고, ID 코드 4는 그 레이싱 게임에 대한 특정한 레이싱 트랙, 속도, 또는 플레이어 숙련도를 지정할 수도 있다. 한 실시예에서, 애플리케이션 개발자에게는 이런 방식으로 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를 식별하는 것임)와 같은 지정을 이용하여) 2개 이상의 상이한 서버 및/또는 스토리지 파티션 사이에서 MSI를 분할할 수도 있다. 그러면, 상이한 중매자가 상이한 서버들 각각으로부터의 상이한 MSI들 각각으로부터 요청들을 독립적으로 회수하고 처리할 수도 있다.
도 15에 나타낸 바와 같이, 매치 요청 데이터는 또한, 각 요청에 대한 요청 테이블(1502) 내에 저장될 수 있다. 요청 데이터는, 중매 결정을 행하는데 이용가능한 임의의 데이터 및/또는 네트워크를 통해 요청을 개시하는 모바일 장치에 액세스하는데 필요한 임의의 데이터를 포함할 수도 있다. 예를 들어, 한 실시예에서, 각 요청에 대한 매치 요청 데이터는, 그 요청을 개시하는 모바일 장치에 대한 NAT 타입 데이터 및/또는 NAT 횡단/접속 데이터를 포함한다. 장치 접속 속도(100kbps, 1Mbps 등), 접속 타입(예를 들어, 3G, EDGE, WiFi 등), 장치 위치(예를 들어, 위치 정보 기술에 의해 결정), 언어(영어, 스페인어 등), 및/또는 사용자 선호사항과 같은 요청 데이터의 다른 타입들도 또한, 요청 테이블(1502) 내에 저장될 수 있다. 요청 데이터는 각각의 모바일 장치(120-122)에 의해 결정되어 각각의 매치 요청과 함께 중매자 디스패처(1501)에 전송될 수도 있다. 예를 들어, 각각의 모바일 장치는, 그 일부가 여기서 설명된 다양한 기술(예를 들어, NAT 횡단/접속 데이터를 결정하기 위해 NAT 횡단 서버와 통신하는 것, GPS를 이용하여 장치 위치를 결정하는 것, 언어를 결정하기 위해 HTTP 정보를 판독하는 것 등)을 이용하여 그 접속 데이터, 접속 타입, 장치 위치 등을 결정할 수도 있다.
도 15에 나타낸 바와 같이, 한 실시예에서, 각각의 활성 MSI가 MSI 테이블(1503)의 행에 할당될 수 있다. 한 실시예에서, 새로운 요청이 도달하면, 그 요청을 요청 테이블(1502)에 추가하는 것 외에도, 디스패처(1501)는 또한 MSI 테이블(1503)을 검사하여 그 요청에 대해 MSI가 이미 존재하는지를(즉, 동일한 MSI를 갖는 다른 요청들이 이미 수신되었는지를) 판정한다. 만일 어떠한 매치되는 MSI도 발견되지 않으면, 디스패처(1501)는 새로운 요청에 대한 새로운 엔트리를 MSI 테이블(1503)에 생성할 수도 있다. 만일 매치되는 MSI가 발견되면, 디스패처는 단순히, 전술된 바와 같이 그 새로운 요청을 요청 테이블(1502)에 추가할 수 있다.
일단 요청 테이블(1502) 및 MSI 테이블(1503)이 중매자 관리자(1501)에 의해 업데이트되고 나면, 중매자 모듈(1510)의 인스턴스(이하에서는, 간단히 "중매자(1510)"이라고 함)가 중매 동작을 수행하기 위해 데이터를 가져온다. 복수의 중매자 인스턴스들이 동시에 실행되어 중매 요청을 수행할 수도 있고 하나의 중매자(1510)가 복수의 상이한 MSI 그룹들 상에서 복수의 중매 동작을 동시에 처리할 수도 있다.
한 실시예에서, 중매자(1510)가 이용가능하게 되면(예를 들어, MSI 그룹에 대한 중매 동작을 완료한 후에 또는 초기화된 후에), 중매자(1510)는 처리할 새로운 MSI를 식별하기 위해 MSI 테이블(1503)에 질의한다. 도 15에서, MSI 3:1에 대한 중매자 ID 필드에서의 "N/A" 값은, 이 MSI의 처리 책임이 중매자에게 아직 할당되지 않았다는 것을 나타낸다. 한 실시예에서, 각 MSI 엔트리는 타임-스탬프되고, 중매자(1510)는 가장 오래된 타임 스탬프를 갖는 MSI를 선택한다.
한 실시예에서, 중매자(1510)가 특정 MSI에 대한 책임을 떠맡을 때, 중매자(1510)는 MSI 테이블(1503) 내의 그 중매자 ID 코드를 업데이트하고 그 MSI에 대한 임대 지속기간(예를 들어, 5초)을 명시한다. 한 실시예에서, 중매자(1510)는 그 MSI에 대해 매치를 처리함에 따라 지속적으로 임대 값을 업데이트한다. 임대 값들은 실패한 중매자(1510)에 할당되었던 MSI들을 식별하는데 이용될 수도 있다. 예를 들어, 만일 임대 값이 만료되면, 그 MSI는, MSI 테이블(1503)이 그 MSI가 중매자에게 이미 할당되었다는 것을 가리키는 사실에도 불구하고, 새로운 중매자에 의해 청구될 수 있다.
일단 중매자(1510)가 MSI에 대한 책임을 떠맡으면, 중매자(1510)는 요청 테이블(1502)에 질의하여 그 MSI와 연관된 요청을 메모리 내로 판독할 수 있다. 그 다음 중매자(1510)는, (예를 들어, 후술되는) 한 세트의 매치 기준에 따라 사용자들과 모바일 장치들을 매치하는 매치 동작을 수행할 수 있다. 중매자(1510)는 모바일 장치의 매치가 이루어진 때를 나타내기 위해 요청 테이블(1512)을 업데이트할 수 있다. 예를 들어, 중매자는, 매치가 완료되었다는 것을 나타내기 위해 요청 테이블(1512) 내의 MSI 열로부터 MSI 값들을 제거하고 미리정의된 값을 입력할 수 있다. 또한, 중매자(1510)는, 각각의 참여자에 대한 "요청 데이터"를, 그 참여자와 매치된 다른 참여자를 식별하기 위해 업데이트할 수도 있다(예를 들어, 그 다른 참여자와 통신하는데 필요한 NAT 횡단/접속 데이터를 기입함으로써).
디스패처(1501)는 완료된 매치를 식별하기 위해 요청 테이블(1502)에 주기적으로 질의할 수 있다. 완료된 매치의 검출에 응답하여, 디스패처(1501)는 푸시 통보를 (예를 들어, 본 명세서 및 동시계류중인 출원에서 기술된 푸시 통보 기술을 이용하여) 그 매치에 연루된 모바일 장치들에 전송할 수도 있다. 한 실시예에서, 푸시 통보는 전술된 "티켓" 데이터 구조를 포함한다. 그러면 모바일 장치들은 그들 티켓들 각각을 이용하여 전술된 CDX 서비스(110)를 통해 접속 데이터를 교환할 수도 있다.
푸시 통보를 이용하는 것 외에도, 한 실시예에서, 모바일 장치(120-122)는 매치가 이루어졌는지를 판정하기 위해 디스패처(1501)에 주기적으로 질의할 수도 있다. 주기적 질의는, 모바일 장치에 푸시 통보가 이루어지지 않은 경우에 유용하다. 그러나, 푸시 아키텍쳐가 이용되기 때문에, 주기적 질의는 비교적 낮은 레이트로 설정되어, 중매자 서비스(111) 상의 부하를 저감할 수도 있다.
도 16은 2개의 모바일 장치 A와 B가 중매자 서비스(111)에 의해 매치되는 방법의 실시예를 나타낸다. 도 17a 내지 도 17d는 방법이 진행됨에 따라 발생할 수도 있는 요청 테이블(1502) 및 MSI 테이블(1503)에 대한 예시적인 업데이트를 나타낸다.
1601에서, 모바일 장치 A로부터 매치 요청이 수신된다. 1602에서, 도 17a에 나타낸 바와 같이, 모바일 장치 A의 요청이 요청 테이블에 입력되고, (이미 존재하지 않는 경우) 새로운 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 요청 수락-언어 헤더로부터 유도되는) 사용자와 연관된 언어, 및 매치 요청들 각각의 경과시간(age)이 포함된다. 일반적으로, 중매자(1510)는, (비록 후술되는 바와 같이 때때로 중계 서비스가 이용될 수도 있지만) 호환형 NAT 타입, 동일한 접속 타입, 및 동일한 언어를 갖는 모바일 장치들을 매치하려고 시도할 것이다. 한 실시예에서, 중매자(1510)는 매치 요구의 경과시간에 기초한 매치 요건에 더욱 자유로울 수도 있다(즉, 요청이 더 오래될수록, 적용되는 매치 제약이 더욱 자유로울 것이다).
도 16으로 되돌아가면, 1607에서, 매치 결정에 후속하여, 중매자(1510)는 요청 테이블을 업데이트하여 도 17d에 나타낸 바와 같이 그 매치가 완료되었음을 나타낸다. 업데이트의 일부로서, 중매자는 또한, 모바일 장치 A와 B에 대한 요청 데이터를 업데이트할 수도 있다. 예를 들어, 한 실시예에서, 중매자(1510)는, 모바일 장치 B의 NAT 횡단/접속 데이터를 모바일 장치 A에 대한 요청 데이터 열에 기입하고, 모바일 장치 A의 NAT 횡단/접속 데이터를 모바일 장치 B에 대한 요청 열에 기입한다.
1608에서, 디스패처(1501)는 매치된 요청 엔트리들을 식별하기 위해 요청 테이블을 통독(read through)할 수 있다. 한 실시예에서, 디스패처가 모바일 장치 A와 B가 매치되었음을 검출하면, 디스패처는 (전술된 바와 같이 중매자에 의해 업데이트된) 요청 데이터를 판독하고, 모바일 장치 A와 B에 대한 통보를 생성한다. 한 실시예에서, 이 통보는, 암호화되고 각 모바일 장치에 대한 NAT 횡단 데이터/접속 데이터를 포함하는 전술된 "티켓" 데이터 구조이다. 전술된 바와 같이, 한 실시예에서, 모바일 장치 A와 B에 통보를 푸시하기 위해 푸시 통보 서비스(1050)가 이용된다. 또한, 모바일 장치 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 요청 수락-언어 헤더로부터 유도되는) 사용자와 연관된 언어, 및 매치 요청들 각각의 경과시간(age)을 포함하지만, 이들만으로 한정되지 않는, 복수의 상이한 변수들에 기초하여 평가된다. 중매 결정 내에 인수화되어 들어갈 수 있는 다른 변수들로는, 각 모바일 장치의 위치(예를 들어, 특정 위치의 사용자들을 매치하려는 시도와 함께); 최소 및/또는 최대 플레이어 요건(예를 들어, 사용자 및/또는 애플리케이션에 의해 명시); MSI에 포함된 한 명 이상의 사용자들이 "친구들"인지 또는 이전에 P2P 접속에 들어갔던 적이 있는지의 여부(예를 들어, "친구"나 이전 면식인들과의 매치 선호도와 함께); 및 애플리케이션에 대한 사용자 경험(예를 들어, 멀티플레이어 게임의 경우, 유사한 숙련도의 사용자와 매치를 선호하는 경우 각 사용자의 점수판 순위가 인수화될 수도 있다)이 포함된다.
이하의 표 A에 나타낸 바와 같이, 한 실시예에서, "정합도"의 평가는 0.0과 1.0 사이의 수치값이다. 부동 소수점값을 이용하는 것은 각 기준에 대한 정합도의 정규화(normalization)를 허용한다. 부동 소숫점 계산을 피하기 위해, 비-정규화된 정수 값이 적절한 평가와 함께 사용되어 정합도 값(fitness values)이 비교될 수 있다.
한 실시예에서, 모든 기준은 그들이 (정규값 1.0을 갖는) 호환형이거나 (정규값 1.0 미만을 갖는) 비호환형인 경우의 2진 정합성을 가진다. 이들은 (후술되는 바와 같이) 정합도가 경과시간에 따라 변할 수도 있는 경우에 필요한 기준으로서 간주될 수 있다. 만일 위치가 변수로서 추가된다면, 최상의 정합은 필요한 기준에 들어맞는 가장 가까운 플레이어의 위치가 될 수도 있다.
Figure 112012089359731-pct00001
한 실시예에서, 정합도는 상기 기준 각각에 대한 (정규화된 가중치 * 경시(aged) 인자 값)의 합계와 같다. 경시 인자 값은 값 1에서 시작하여 미리결정된 기간이 지난 후에 증가할 수도 있다. 그 다음, 이것은 더 많은 시간이 경과함에 따라 계속 증가할 수도 있다(예를 들어, 지정된 양만큼 주기적으로 증가). 한 실시예에서, 전술된 경시 인자 값을 이용하는 것 대신에, 후술되는 바와 같이 경과시간 임계치가 설정될 수도 있다. 접속 타입 및 언어와 같은 소정 변수들의 정규화된/가중화된 값들은 (이들이 매치하지 않더라도) 소정의 경과시간 임계치 위에서 적용될 수도 있다.
한 실시예에서, 한 쌍의 요청 A와 B 사이의 "정합도"는, B에 대한 A의 정합도와 A에 대한 B의 정합도의 평균이다. 게다가, 각 인자에 대한 B에 관한 A의 정합도는 A의 경과시간(및 그 반대의 경우)에 기초하여 조정될 수도 있다. 한 실시예에서, 호환형 매치에 대해 정합도 1.0이 요구될 수도 있다. 이것은 A와 B는 NAT 호환성, 접속 타입 및 언어가 매치(그 결과 정규화된 값 1.0)될 때 또는 A 및/또는 B가 경시될(aged) 때에만 매치되어 상기 변수들 중 일부(예를 들어, 접속 타입 및 언어)가 (상기 경시된 인자 값 또는 하기 임계치를 이용하여) 사실상 무시된다는 것을 의미한다.
Figure 112012089359731-pct00002
경과시간 임계치는 상기 표 B에 개시된 바와 같이 설정될 수도 있다. 각각의 경과시간 임계치를 지남에 따라(즉, 요청이 명시된 임계치보다 오래됨에 따라), 경시된 인자값은 계속적으로 더 큰 값(예를 들어, 1.5, 2.0 등)으로 증가될 수도 있다. 대안으로서, 또는 추가로, 상이한 경과시간 임계치를 지남에 따라, 소정 변수에 대한 가중화된 값들이 (예를 들어, 후술되는 접속 타입 및 언어와 같은) 매치 결정에 추가될 수도 있다.
한 실시예에서, 표 B에 명시된 요청 경과시간 한계는 주어진 MSI에 대한 매치 진행률(match flow rate)에 따라 조정된다. 한 실시예에서, 진행률은 명시된 단위의 시간당(예를 들어, 매 10초, 매 분 등) 수행되는 매치의 갯수로서 정의된다. 따라서, 진행률은 특정한 MSI 세트가 얼마나 바쁜지에 대한 표시를 제공한다. 한 실시예에서, 세트가 바쁠수록, 상기 임계치 각각은 상기 표 B에서 더 낮게 설정되어 초기의 성공적 매치의 확률을 증가시키고 중매자에 주는 부담을 경감한다. 게다가, 주어진 MSI 세트에 대한 부하가 엔드 유저(end user)에 (예를 들어, 매치 값에 대한 추정된 시간의 형태로) 제공되어, 그 엔드 유저는 특별히 바쁜 멀티플레이어 게임에 들어가려고 할지를 선택할 수 있다. 부하 값은 푸시 통보의 형태로 사용자에게 제공될 수도 있다.
이제 표 A로부터의 변수들 각각을 참조하면, 한 실시예에서, 도 14에 도시된 NAT 호환성 차트(1400)로부터 NAT 호환성이 판정된다. 만일 2개의 NAT가 이 차트에 기초하여 호환된다고 판정되면, NAT 호환성 가중치가 적용될 수도 있다.
Figure 112012089359731-pct00003
접속 타입은 상기에서 표 C로서 나타낸 것과 같은 차트를 이용하여 평가될 수도 있다. 이 예에서, 만일 장치 A와 B의 접속 타입이 동일하다면(동일한 접속 타입이 충족되는 셀들에서 1.0으로 표시), 표 A로부터의 가중화된 접속 타입 값이 정합도 결정에 포함될 수도 있다. 전술된 바와 같이, 각 요청의 경과시간이 이용되어 접속 타입 결정에 영향을 미칠 수도 있다. 예를 들어, 한 실시예에서, 임계치 1, 2, 및 3에서의 경과시간에 대한 표 C의 매트릭스를 이용하여 접속 타입에 대한 정합도 값이 선택된다. 임계치 4 또는 그 이상에 대한 경과시간의 경우, 접속 타입은 (비정합 접속 타입에 대해서도) 1.0으로 설정될 수도 있고, 대응하는 가중화된 접속 타입 값이 적용될 수도 있다. 몇몇 실시예에서는 접속 "타입"이 이용되지만, 접속 타입과 함께 또는 그 대신에, 접속 속도가 판정되어 이용될 수도 있다. 예를 들어, 소정의 명시된 범위(예를 들어, 0-100kbps; 100-500kbps; 500-1000kbps, 1000-1500kbps 등) 내의 접속 속도는 "호환형"이라 간주될 수도 있다. 여기서 논의된 매치되는 변수들 중 임의의 것이 매치 정합도 계산에 대한 가중치로서 적용되고 전술된 바와 같이 경시(aged)될 수도 있다.
한 실시예에서, 플레이어 언어는, 선호도 큐인자(qfactor)와 함께 하나 이상의 언어를 포함할 수도 있는 HTTP 요청 수락-언어 헤더로부터 유도될 수 있다. 디스패처는 가장 선호되는 언어를 추출하여 이 정보를 중매자에 전달할 수 있다. 한 실시예에서, 표 A로부터의 가중화된 언어 값은 언어들이 동일하다면 1.0으로, 언어들이 동일하지 않다면 0.0으로 설정된다. 그러나, 한 실시예에서, 가중화된 언어 값은 언어들이 상이하더라도 경과시간이 명시된 임계치보다 높다면(예를 들어, 경과시간이 표 B에서 임계치 2 또는 그 이상이라면) 적용될 수 있다.
한 실시예에서, 비호환 NAT 타입들을 갖는 2명 사용자들 사이에 매치가 이루어질 수도 있다. 예를 들어, 만일 중매자가 특정한 MSI에 대한 사용자들을 매치하는데에 어려움을 가진다면, 명시된 기간이 지난 후에, 전술된 기술들을 이용하여 접속을 중계 서비스(1051)를 통해 라우팅할 수도 있다. 이런 방식으로, 중계 서비스(1051)는 압력 밸브처럼 역할하여, 비호환 NAT 타입들임에도 불구하고 경시 매치가 발생하는 것을 허용한다. 중계 서비스(1051)는 또한 하나 이상의 실패한 매치 시도의 검출에 응답하여 이용될 수도 있다. 이 실시예에서, 모바일 장치에 의해 제출된 각 매치 요청은, 하나 이상의 성공하지 못한 매치가 이전에 시도되었는지에 관한 표시를 포함할 수도 있다.
다양한 추가적인 매치 기준이 평가되어, 제한이 아닌 예로서, 매치를 요청하는 사용자들 중 임의의 사용자가 친구인지에 관한 표시를 포함한, 매치 정합도 판정의 일부로서 가중치를 제공받을 수 있다. 예를 들어, 중매자(1510)는, 매치 정합도 계산에 대해 "친구" 가중치를 적용함으로써, 임의의 요청들을 "친구"인 사용자들에 대해 매치하려고 시도할 수도 있다. 마찬가지로, 친구의 친구들이 또한, (예를 들어, 2이상의 분리도와 함께) 가중화될 수도 있다. 추가적으로, 플레이어는 특정한 게임에 대해 다른 플레이어들의 순위를 매기고, 매치의 수행시에 중매자는 이들 순위를 평가할 수도 있다(비교적 높은 순위를 갖는 플레이어들과 사용자를 매치시키고, 낮은 순위를 갖는 플레이어들과는 매치시키지 않는 경향). 게다가, 사용자의 접속의 레이턴시가 (예를 들어, 간단한 핑 동작을 이용하여) 평가되고 중매 결정의 일부로서 이용될 수도 있다.
플레이어들을 매치시키는데 이용되는 역시 또 다른 변수가 장치 타입일 수도 있다. 예를 들어, 중매자(1510)는 유사한 장치 타입(예를 들어, iPads, iPods, iTouches, iPhones, RIM Blackberry 등)을 갖는 플레이어들을 매치시키려고 시도할 수도 있다. 사용자의 점수판 랭킹, 현재 위치, 현재 거주지, 나이, 성별, 및 유사한 게임 콜렉션들을 포함한 추가의 변수들이, 매치 결정에 대해 유사하게 평가될 수도 있다(즉, 많은 경우 유사한 기준을 갖는 사용자들 사이의 매치를 선호하는 경향). 마지막으로, 사용자들이 적절한 MSI들 및 동일한 나이의 다른 사용자들과만 매치되도록 보장하기 위해 중매자(1510)에 의해 부모 통제(parental control)가 평가될 수도 있다.
중매자 서비스(111)는 데이터 서비스(100) 내에서 관리되는 하나 이상의 데이터베이스(예를 들어, 도 19에 관하여 후술되는 데이터베이스(1920)를 참조)로부터 상기 임의의 변수를 검색할 수도 있다. 예를 들어, 친구 서비스 데이터베이스로부터의 사용자의 친구 데이터가 액세스되고, 각 사용자의 나이, 성별, 게임 콜렉션 등과 같은 기타의 정보는 하나 이상의 다른 데이터베이스(예를 들어, 사용자 프로파일, 게임 데이터베이스, 점수판 데이터베이스 등)로부터 액세스될 수도 있다. 한 실시예에서, 여기서 설명된 서비스들 모두에는, 중매 결정에 이용되는 다양한 상이한 타입들의 사용자/장치 데이터 모두를 저장하기 위한 동일한 중앙 데이터베이스(또는 데이터베이스 그룹)로의 액세스가 제공된다.
상기에서 수 개의 구체적인 예가 제공되었지만, 본 발명의 기저 원리는, 매치에 대한 정합 수준을 결정하기 위한 임의의 특정한 변수 세트에 한정되지 않는다는 것을 이해할 것이다. 한 실시예에서, 시스템 상에서 실행될 애플리케이션과 여기서 설명된 방법을 설계하는 애플리케이션 프로그래머들은, 상이한 MSI 기준을 이용하여 요청을 매치시키고 및/또는 그룹화하기 위한 그들 자신의 기준 집합을 명시할 수도 있다.
도 18의 방법을 참조하면, 일단 각 쌍 사이의 매치 "정합도"가 결정되고 나면, 1803에서, 쌍들이 내림차순 정합도별로 분류된다(예를 들어, 가장 높은 정합도를 갖는 쌍이 목록의 최상위에 위치). 1804에서, "매치 세트"가, 명시된 임계치보다 위의 가장 높은 정합도 값을 갖는 쌍들로 작성(seed)된다. 전술된 바와 같이, "임계" 치는 상기 표 A에 도시된 정규화된 값 1.0으로 설정될 수도 있다. 1805에서, 명시된 임계치 위의 매치 세트의 현재 멤버들 중 하나 또는 모두와의 정합도 값을 갖는 새로운 유망 파트너가 매치 세트에 추가된다. 예를 들어, 매치 세트가 처음에 A 및 B로 작성(seed)되었다면, A-C 및/또는 B-C의 정합도 값이 명시된 임계치 위이라면 그 매치 세트에 C가 추가될 수도 있다. 한 실시예에서, 만일 단 하나의 매치 정합도가 유망 당사자에 대한 임계치 위이라면, 그 당사자는 매치 세트에 추가될 수도 있다(즉, 필요하다면, 그 당사자는 적절한 매치 정합도를 갖는 한 당사자를 통해 당사자들 모두와 통신할 수 있을 것이다). 일단 하나 이상의 새로운 당사자가 매치 세트에 추가되고 나면, 만일 1806에서 결정되는 그 매치에 대한 크기 요건이 충족되는 경우, 1807에서 매치 결과가 저장되고 보고된다(예를 들어, 전술된 바와 같이 요청 테이블(1502)을 업데이트하고 통보를 전송함으로써). 한 실시예에서, 하나의 매치 요청이 복수의 사용자를 나타낼 수도 있다(예를 들어, 매치 요청이 후술되는 초대 시퀀스를 뒤따를 경우). 이 경우, 각 매치 요청이 나타내는 사용자 수에 기초하여 크기 요건이 평가된다. 만일 크기 요건이 충족되지 않으면, 프로세스는 1805로 되돌아가고, 새로운 당사자(즉, 명시된 임계치 위의 상기 세트의 현재 멤버들 중 하나 이상과의 매치 정합도를 갖는 당사자)가 매치 세트에 추가된다.
1808에서, 매치된 요청들은, 중매자(1510)에 의해 처리중인 현재 세트의 요청들로부터 제거된다. 1809에서, 다음 작성된 매치 세트가 선택되고 프로세스는 추가의 매치를 위해 1804로 되돌아간다. 도 18에서는 순차적 프로세스로서 나타내었지만, 본 발명의 기저 원리를 여전히 따르면서 복수의 작성된(seeded) 매치 세트들이 동시에 처리될 수도 있다는 점에 유의해야 한다.
위에서는 별개의 서비스들로서 설명되었지만, 중매자 서비스(111) 및 초대 서비스(112)는 P2P 사용자들을 접속하기 위해 함께 동작할 수도 있다. 예를 들어, 한 실시예에서, 제1 사용자는 한 명 이상의 친구를 온라인 세션에 초대하고 한 명 이상의 추가 사용자와의 매치를 요청할 수도 있다(예를 들어, 친구 "Bob"을 초대하고, 멀티플레이어 비디오 게임에 대해 3명의 추가 플레이어를 매치). 이러한 경우, 초대 서비스(112)는 처음에 제1 사용자의 초대 요청을 처리하여 제1 사용자와 그 제1 사용자의 친구(들)을 접속할 수 있다. 그 다음, 초대 요청의 결과(예를 들어, 성공적 P2P 접속)가 사용자의 모바일 장치에 되보고될 수도 있다. 그 다음, 중매자 서비스(111)는 추가 플레이어를 요청하는 제1 사용자의 모바일 장치로부터(또는, 한 실시예에서는, 초대 서비스로부터 직접, 또는 제1 사용자의 친구로부터) 매치 요청을 수신할 수도 있다. 응답하여, 중매자 서비스(111)는, (전술된 바와 같이) 제1 사용자를 그 제1 사용자의 요청과 동일한 MSI를 갖는 하나 이상의 다른 매치 요청과 매치시킬 수 있다. 매치 요청은 제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)의 개발자에 의해 제공되는 소프트웨어 개발 킷("SDK")와 네트워크 서비스(1901-1903)를 이용함으로써 용이해질 수도 있다. 프레임워크(1912)와 API(1910, 1913)의 더 구체적인 구현이 도 20을 참조하여 후술된다.
나타낸 바와 같이, 서비스들 각각에는 서비스들에 의해 이용되는 데이터를 저장하기 위한 데이터베이스(1920)로의 액세스가 제공될 수도 있다. 한 특정의 예는, (전술된) 중매자 서비스(111)에 의해 이용되는 데이터베이스(1512)이다. 다른 예는, 점수판 데이터를 저장하기 위한 점수판 데이터베이스, 친구 상태 기록을 저장하기 위한 친구 서비스 데이터베이스, 사용자 프로파일 데이터를 저장하기 위한 프로파일 데이터베이스, 및 온라인 게임과 관련된 데이터를 저장하기 위한 게임 데이터베이스를 포함할 수도 있다. 임의 타입의 데이터베이스(예를 들어, MySQL, Microsoft SQL 등)가 이용될 수도 있지만, 한 특정 실시예에서는, Berkley DB 및/또는 MZBasic DB와 같은 키/값 데이터베이스가 이용될 수 있다. 데이터베이스는, SAN(Storage Area Network) 또는 기타의 스토리지 구성 내의 많은 수의 대용량 스토리지 장치(예를 들어, 하드 드라이브)에 걸쳐 분산될 수도 있다.
결과적으로, 특정 서비스가 전술된 바와 같이 데이터를 처리 및/또는 저장할 때, 데이터는 데이터베이스(1920) 내에 저장될 수도 있다. 그러나, 일부 서비스들은 데이터베이스를 이용하지 않을 수도 있다. 예를 들어, 전술된 바와 같이, 초대 서비스(112)는 무상태 서비스로서 구현될 수도 있고, 따라서, 데이터베이스(1920) 내에 데이터를 저장할 것이 요구되지 않을 수도 있다(비록 본 발명의 기저 원리에 따라 이러한 구현이 여전히 가능하지만).
API(1913)는, 예를 들어, 네트워크 계층의 TCP/IP 또는 UDP/IP와 애플리케이션 계층의 HTTPS를 포함한 임의의 적절한 네트워크 프로토롤 스택을 이용하여 네트워크 서비스(1901-1903)와 통신하고 정보를 교환하도록 설계될 수도 있다. SOAP와 같은 HTTP 또는 HTTPS를 통한 원격 프로시져 호출(RPC)-기반의 프로토콜이 이용되거나 및/또는 REST(Representational State Transfer) 프로토콜이 이용될 수도 있다. 게다가, 서비스들은, 예로서, Xserve 또는 Unix, Linux 또는 Apache 소프트웨어 플랫폼을 운영하는 유사한 서버들을 포함한, 임의의 컴퓨팅 플랫폼 상에서 구현될 수도 있다. 한 특정 실시예에서, 플랫폼은 Linux 상에서 구현된 Web 객체를 포함한다. 전술된 예들은 단지 설명의 목적을 위해 제공된 것이다. 본 발명의 기저 원리는, 애플리케이션을 서비스에 링크하기 위한 임의의 특정한 메커니즘이나 임의의 특정한 네트워크 프로토콜 세트로 한정되는 것은 아니다.
도 20은 본 발명의 한 실시예의 무선 장치(120) 상에서 구현될 수 있는 애플리케이션 프로그래밍 인터페이스(API)(2001a-b)를 포함한 더 상세한 소프트웨어 아키텍쳐를 나타낸다. 이 실시예가 멀티플레이어 게임 프레임워크(2000)의 정황 내에서 설명되지만, 본 발명의 기저 원리는 게이밍 구현으로 한정되는 것은 아니다. 예를 들어, 게임이 아닌 다양한 협력적 애플리케이션들(예를 들어, 협력적 채팅, 멀티파티 협력적 오디오/비디오 등)을 지원하기 위해 도 20에 도시된 소프트웨어 아키텍쳐가 이용될 수도 있다.
도 20에 도시된 아키텍쳐에서, 여기서 설명된 다양한 멀티파티 특징과 P2P 특징을 지원하기 위해 게임 프레임워크(2000)가 제공된다. 한 실시예에서, 게임 프레임워크(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)의 설계자는, 잠재적으로 민감한 정보를 포함하는 어떤 API 기능들을 공개 API(2001b)의 바깥에 유지하여 제3자 개발자에 의해 남용(예를 들어, 친구 요청, 친구 목록 등)을 피하기를 원할 수도 있다. 그러나, 보안 API(2001a) 및 공개 API(2001b) 양쪽 모두는 모바일 장치 상의 모든 애플리케이션들에 의해 액세스가능한 단일 API로 병합될 수도 있다(즉, 공개 컴포넌트와 사설 컴포넌트로의 API의 분리는 본 발명의 기저 원리를 따르는데 필요한 것은 아니다). 표기 "API 2001"은 때때로 이하에서, 공개 API(2001b) 및/또는 사설 API(2001a) 중 어느 하나에서 발견될 수도 있는 동작을 지칭하기 위해 사용된다.
게임 센터 애플리케이션(2031)의 한 실시예는, 본 출원의 양수인에게 양도되고 본 명세서에서 참조용으로 인용되는, Attorney Docket 번호 제4860.P9127USP1이며, 발명자가 Marcel Van Os 및 Mike Lampell이고, 2010년 4월 7일 출원된 출원번호 61/321,861호이며, 발명의 명칭이 Systems and Methods for Providing a Game Center인, 동시계류중인 출원(이하에서는, “Game Center Patent Application”이라 함)에 설명되어 있다. 요약하면, 게임 센서 애플리케이션(2031)은 멀티플레이어 게임을 네비게이팅하고; 새로운 게임을 구입하고; 게임에 관련된 정보(예를 들어, 점수판 정보, 업적, 친구 정보 등)를 검색하고; 게임을 플레이하기 위해 친구들에게 연락하고; 다른 사용자들과의 게임 매치를 요청하고; 특정 사용자들을 초대하기 위한 게임-중심의 그래픽 유저 인터페이스(GUI)를 포함한다. 게임 센터 애플리케이션(2031)에 의해 수행되는 다양한 다른 기능들은 앞서 참조한 Game Center Patent Application에 설명되어 있다. 게임 센터 기능들의 일부는 게임 프레임워크(2000)에 의해 제공되어 공개 API(2001b)를 통해 다른 애플리케이션(2030)에 액세스가능하게 될 수도 있다.
한 실시예에서, 게임 프레임워크(2000)에 의해 노출된 API(2001)는, 모바일 장치(120)에 대한 멀티플레이어, 협력적 게임을 설계하는 과정을 단순화시킨다. 특히, 한 실시예에서, API(2001)는, 개발자들이 간단한 API 호출을 행하여 멀티플레이어 P2P 게임 세션에 대해 사용자들을 접속하는 비교적 복잡한 프로세스를 기동시키는 것을 허용한다. 예를 들어, INVITE(플레이어 B ID, 버켓 ID)와 같은 간단한 API 호출이 API(2001)로부터 기동되어 전술된 세부적인 초대 시퀀스를 개시할 수도 있다. 마찬가지로, MATCH(플레이어 A ID, 버켓 ID)와 같은 간단한 API 호출이 API(2001)로부터 기동되어 전술된 세부적인 중매 시퀀스를 개시할 수도 있다. INVITE 및 MATCH 함수는 때때로 일반적으로 여기서는 "P2P 접속 함수"라고 불린다. 한 실시예에서, 게임 프레임워크(2000)는 (이하에서 상세히 설명되는 바와 같은) 이들 API 호출에 응답하여 초대와 중매 동작을 관리하는데 요구되는 프로그램을 포함한다. 실제의 API 함수들은 앞서 개시된 것들과는 다소 상이한 데이터 포멧을 가질 수도 있다(비록 이들이 결과적으로 게임 프레임워크(2000)에 의해 수행되는 유사한 동작을 초래할 수도 있지만). 본 발명의 기저 원리는 API 함수를 명시하기 위한 임의의 특정한 포멧으로 한정되지 않는다.
다양한 다른 타입의 게임-관련 트랜잭션과 정보도 역시, 게임 센터(2031) 및 기타의 애플리케이션(2030)을 위해 게임 프레임워크(2000)에 의해 관리될 수 있다. 이 정보의 일부는 Game Center Patent Application에 설명되어 있다. 제한이 아닌 예로서, 이 정보는 각 게임에 대해 최고 점수를 달성한 사용자들에 관련된 "점수판" 정보와, 어떤 게임-특정의 업적을 완료한 사용자들을 식별하는 "업적" 정보를 포함할 수도 있다. 각 애플리케이션 개발자들은 각 게임 애플리케이션(2030)에 대한 그들 자신의 "업적" 세트(예를 들어, 레벨 1-3 완료; 5분 이하에서 레벨 1 완료; 레벨당 50 킬; 20 플래그 녹다운 등)를 명시할 수도 있다.
게임 프레임워크(2000)는 또한, 사용자의 친구 데이터를 관리하고 게임 센터(2031) 및 기타의 게이밍 애플리케이션(2030)의 정황 내에서 친구 데이터를 통합하기 위한 프로그램 코드를 포함할 수도 있다. 예를 들어, 사용자가 게임 센터(2031) 내의 특정 게임에 대한 링크를 선택하면, 그 게임에 대하여 그 사용자의 친구들 각각에 관련된 정보(예를 들어, 점수판에서의 친구들의 랭킹, 친구들의 업적, 그 사용자가 각 친구와 게임을 플레이했을 때의 결과 등)가 디스플레이된다. 한 실시예에서, 게임 프레임워크(2000)의 API(2001)는, 본 출원의 양수인에게 양도되고 본 명세서에서 참조용으로 인용되는, Attorney Docket 번호 제4860.P9240이고, 발명자가 Amol Pattekar, Jeremy Werner, Patrick Gates, 및 Andrew H. Vyrros이며, 2010년 4월 7일 출원된 출원번호 61/321,848이며, 발명의 명칭이 Apparatus and Method for Efficiently Managing Data in a Social Networking Service인(이하에서는 “Friend Service Application”이라 함) 동시계류중인 출원에서 설명된 바와 같은 친구 서비스에 의해 관리되는 친구 데이터를 액세스하기 위한 함수를 포함한다.
도 20에 나타낸 바와 같이, 한 실시예에서, 게임 데몬(daemon)(2020)은 게임 프레임워크(2000)를 제1 세트의 서비스(2050)에 인터페이싱하고, 게임 서비스 컴포넌트(2010)는 게임 프레임워크(2000)를 제2 세트의 서비스(2051)에 인터페이싱할 수도 있다. 예로서, 제1 세트의 서비스(2050)는, 전술된 초대 서비스(112), 중매자 서비스(111), 중계 서비스(1051), 및 상기 Friend Service Application에서 설명되는 친구 서비스를 포함할 수도 있다. 게임 데몬(2020)을 통해 액세스될 수도 있는 기타의 서비스들로는, (점수판 데이터를 제공하는) 점수판 서비스; (각 게임 및 게임 구입 능력에 관련된 통계와 기타의 데이터를 제공하는) 게임 서비스; (모바일 장치의 사용자를 인증하기 위한) 사용자 인증 서비스; 및/또는 (사용자 선호사항과 같은 사용자 프로파일 데이터를 저장하기 위한) 사용자 프로파일 서비스가 포함된다. 게임 서비스 컴포넌트(2010)를 통해 액세스되는 제2 세트의 서비스(2051)는, 전술된 접속 데이터 교환(CDX) 서비스(110) 및 NAT 횡단 서비스(290-291)를 포함할 수도 있다. 설명의 목적을 위해 도 20에서는 별개의 컴포넌트로서 나타나 있지만, 게임 데몬(2020) 및 게임 서비스 모듈(2010)은 실제로 게임 프레임워크(2000)의 컴포넌트일 수도 있다. 한 실시예에서, 게임 데몬(2020 및 2010)은, 한 실시예에서는 사설 (즉, 제3자 개발자들에게 공개되지 않은) API인 미리정의된 API를 통해 네트워크 서비스(2050-2051) 각각과 통신한다.
한 실시예에서, 게임 데몬(2020)은 HTTPS 프로토콜을 이용하여 중매자 서비스(111), 초대 서비스(112), 및 기타의 서비스(2050)와 통신할 수 있는 반면, 게임 서비스 모듈(2010)은 UDP 소켓과 같은 비교적 가벼운 프로토콜을 이용하여 CDX 서비스(110) 및 NAT 횡단 서비스(290-291)와 통신할 수 있다. 그러나, 전술된 바와 같이, 본 발명의 기저 원리를 여전히 따르면서 다양한 다른 네트워크 프로토콜이 이용될 수도 있다.
또한, 도 20에 나타낸 바와 같이, 게임 데몬(2020)은 소정 서비스(2052)(예를 들어, 초대 서비스 및 중매자 서비스)에 의해 생성된 푸시 통보(2052)를 수신할 수도 있는 반면, 다른 타입의 푸시 통보(2053)(예를 들어, 새로운 친구 요청과 같은 친구 서비스 통보)는 게임 센터에 의해 직접 수신될 수도 있다. 한 실시예에서, 이들 푸시 통보(2053)는, 사용자의 민감한 데이터가 제3자 애플리케이션 개발자들에 의해 설계된 애플리케이션(2030)에게 액세스가능하지 않을 것을 보장하기 위해 게임 센터(2031)에 직접 제공된다.
상기 도 11에 개시된 게임 초대 예로 되돌아가면, 모바일 장치 A 상의 애플리케이션(2030)이 게임 프레임워크(2000)의 API(2001b)에 초대 호출을 행하여 모바일 장치 B의 사용자를 초대하면(예를 들어, INVITE (플레이어 B ID, 게임/버켓 ID)), 게임 프레임워크(2000)는 초대 요청을 모바일 장치 A의 게임 데몬(2020)에 전달할 수도 있다. 그러면, 게임 데몬(2020)은 초대 요청을 제출하기 위해 초대 서비스(112)와 통신할 수도 있다. 그러면, 초대 서비스(112)는 (전술된 바와 같은) 푸시 통보 서비스(1050)를 이용하여 모바일 장치 B의 게임 데몬(2020)에 초대를 푸시할 수 있다. 그러면, 모바일 장치 B의 게임 데몬(2020)은 모바일 장치 B의 게임 프레임워크(2000)와 통신하여 초대가 전송된 게임이 모바일 장치 B에 설치되어 있는지를 판정한다. 만일 그렇다면, 게임 프레임워크(2000)는 애플리케이션(2030)을 트리거하고 및/또는 초대의 시각적 통보를 생성할 수도 있다. 만일 애플리케이션 설치되어 있지 않다면, 게임 프레임워크(2000)는 (예를 들어, 게임 센터(2031) GUI를 통해) 게임의 구입 제안과 함께 모바일 장치 B의 사용자에게 초대의 시각적 통보를 트리거할 수도 있다. 대안으로서, 시각적 통보는 (도시되지 않은) 모바일 장치(120) 상에서 실행중인 푸시 통보 데몬에 의해 생성될 수도 있다. 만일 모바일 장치 B의 사용자가 게임을 구입한다면, 구입에 후속하여 초대 시퀀스가 계속될 수도 있다. 만일 모바일 장치 B의 사용자가 초대 요청을 수락한다면, 모바일 장치 B의 게임 프레임워크(2000)는 초대 요청을 그 게임 데몬(2020)에 전달하고, 그 다음 게임 데몬(2020)이 초대 서비스(112)에 응답할 수도 있다.
도 11에서, 호환성 검사(1106)는 모바일 장치 A와 B의 NAT 타입들이 호환되는지를 판정한다는 것을 상기한다. 따라서, 1108에서, 모바일 장치 A의 게임 데몬(2020)은 모바일 장치 B의 수락을 (예를 들어, 이 예에서는 푸시 통보를 통해) 수신하고, 한 실시예에서는, 그 수락을 게임 프레임워크(2000)에 전달한다. 이 단계에서, 모바일 장치 A의 게임 프레임워크(2000)은 (API(2001)를 통해) 모바일 장치 B가 수락했다는 것을 요청측 애플리케이션(2030)에 통보하거나, 장치들이 성공적으로 접속될 때까지 요청측 애플리케이션(2030)에 통보하는 것을 대기할 수도 있다. 어느 경우든, 게임 프레임워크(2000)는, 한 실시예에서는, 모바일 장치 B와의 접속 데이터 교환을 개시할 수도 있는 게임 서비스 모듈(2010)에 접속 요청을 전달할 수도 있다. 특히, 게임 서비스 모듈은 CDX 서비스(110)를 이용하여 모바일 장치 B에 모바일 장치 A의 접속 데이터를 전송할 수도 있다(예를 들어, 도 11의 트랜잭션 1111 및 1112를 참조). 전술된 바와 같이, 이 통신은 보안 "티켓" 데이터 구조를 이용하여 UDP 접속으로서 구현될 수도 있다.
도 12에서, 만일 호환성 검사(1106)가 모바일 장치 A와 B의 NAT 타입들이 호환되지 않는다고 판정한다면, 장치들 사이의 접속을 제공하기 위해 중계 서비스(1051)가 이용될 수도 있다는 점을 상기한다. 결과적으로, 모바일 장치 B의 게임 데몬(2020)은 (도 12에 도시된) 초대 서비스로부터 중계 응답(1203)을 수신하고, 모바일 장치 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)에게 통보할 수도 있다(예를 들어, CONNECTED (플레이어 A ID, 플레이어 B ID)). 모바일 장치 A와 B는 그 다음, 확립된 접속을 이용하여 명시된 게임이나 기타의 협력적 애플리케이션(2030)을 플레이할 수도 있다.
따라서, API(2001)로부터의 비교적 간단한 호출 (예를 들어, INVITE 플레이어 B ID, 게임/버켓 ID)에 응답하여, 모바일 장치 A와 B 사이에 P2P 또는 중계 접속을 확립하기 위해 복잡한 일련의 트랜잭션이 게임 프레임워크(2000)에 의해 관리될 수도 있다. 한 실시예에서, 게임 프레임워크(2000)는 모바일 장치 A와 B를 접속하는 동작 시퀀스를 수행한 다음, 요청측 애플리케이션(2030)에 그 결과를 제공함으로써, API 호출의 상세사항을 애플리케이션 설계자에게 투명하게 한다. 이와 같이, 애플리케이션 설계자는 네트워크 상에서 모바일 장치 A와 B를 접속하는 방법이나 장치들 사이의 통신을 가능케하기 위해 요구되는 기타의 다양한 함수들을 수행하는 방법에 관해 이해할 것이 요구되지 않음으로써, 애플리케이션 설계 과정을 단순화한다.
유사한 방식으로, 게임 프레임워크(2000)는 도 2a 및 도2 b에 관하여 전술된 바와 같이 중매자 서비스(111)를 이용하여 모바일 장치 A와 다른 참여자들 사이의 매치를 확립할 수 있다. 이 예에서, 애플리케이션(2030)은 MATCH(플레이어 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 통보(예를 들어, MATCH COMPLETE (플레이어 B ID, 플레이어 C ID))를 이용하여 애플리케이션(2030)에게 접속 프로세스가 완료되었음을 통보한다. 그러면, 확립된 P2P 접속을 이용하여 애플리케이션이 실행될 수 있다.
일부 실시예에서, 사용자에게는 현재 "온라인"으로 등록된 다른 친구들과 게임을 플레이할 옵션이 주어질 수도 있다. 이 경우, 어떤 친구들이 온라인이라는 통보가 푸시 통보(2052) 또는 푸시 통보(2053)를 통해 제공(게임 센터(2031)에 의해 직접 수신)될 수도 있다. 그러면 게임 센터(2031) 및/또는 애플리케이션(2030)은 그 통보를 사용자에게 제공하고 한 명 이상의 선택된 온라인 친구들과 플레이할 옵션을 사용자에게 제공할 수도 있다. 그러나, 여기서 설명된 초대 시퀀스는 온라인 통보가 제공되는지에 관계없이 작동할 것이라는 점에 유의해야 한다. 한 실시예에서, 사용자의 온라인 상태는 게임 데몬(2020)에 의해 액세스가능한 서비스에 의해(예를 들어, 상기 언급한 친구 서비스에 의해 또는 별개의 "존재(presence)" 서비스에 의해) 모니터링될 수도 있다.
게임 프레임워크(2000)의 한 실시예는, 사용자가 한 명 이상의 친구를 초대하여 한 그룹의 미지의 매치된 참여자들과 플레이할 수도 있는 초대/중매 서비스의 조합을 제공한다. 예를 들어, 만일 게임이 4명의 플레이어를 요구하고, 제1 사용자가 제2 사용자를 초대하여 게임을 플레이한다면, 초대 서비스(112)는 처음에 제1 사용자와 제2 사용자를 접속하고, 그 다음, 중매 서비스(111)는 제1 사용자 및 제2 사용자를 2명(또는 그 이상의) 다른 플레이어와 매치시킬 수도 있다. 이 실시예에서, 게임 프레임워크(2000)는 처음에, 제1 사용자와 제2 사용자를 접속하기 위해 전술된 초대 시퀀스를 수행할 수도 있다. 한 실시예에서, 일단 제1 사용자와 제2 사용자가 성공적으로 접속되고 나면, 게임 프레임워크(2000)는 다른 사용자들을 식별하고 이들과 접속하기 위해 중매 시퀀스를 구현할 수도 있다. 앞서 언급한 바와 같이, 한 실시예에서, 중매 서비스에 의해 적용되는 매치 기준은 제1 및 제2 사용자 양자 모두(예를 들어, 제1 및 제2 사용자 양자 모두의 NAT 타입, 접속 타입, 언어 등)를 포함할 수도 있다. 대안으로서, 중매 결정을 내리기 위하여 2명의 사용자들 중 한 명의 기준이 평가될 수도 있다.
일단 모든 사용자들이 접속되고 나면, 게임 프레임워크(2000)는 API(2001)를 통해 접속을 요청한 애플리케이션(2030)에 접속 결과를 제공할 수도 있다. 다시 한번, 애플리케이션(2030)에 의한 비교적 단순한 API 호출에 응답하여, 게임 프레임워크(2000)는 장치들 각각을 접속하기 위하여 한 세트의 복잡한 트랜잭션 내에 진입한다. 일단 장치들이 성공적으로 접속되고 나면, 게임 프레임워크(2000)는 결과를 요청측 애플리케이션(2030)에 다시 제공한다.
도 20에 나타낸 바와 같이, 게임 프레임워크(2000)는 사용자와 다른 게임 참여자들 사이의 통신 정보를 임시로 저장하는 통신 버퍼(2003)를 포함할 수도 있다. 통신 정보는, 예를 들어, 텍스트, 오디오, 및/또는 비디오 통신 정보를 포함할 수도 있다. 게임 프레임워크(2000)는 각 애플리케이션(2030)의 요구에 기초하여 버퍼(2003)를 설정할 수 있다. 예를 들어, 느린 네트워크 접속에 의한 오디오/비디오 통신을 위해서는 상대적으로 더 큰 버퍼(2003)가 요구될 수도 있다. 한 실시예에서, 각 애플리케이션(2030)은 API(2001)를 통해 소정 크기의 통신 버퍼를 설정하기 위해 (예를 들어, BUFFER (크기) 명령을 이용하여) 명시적 요청을 행할 수도 있다. 대안으로서, 게임 프레임워크(2000)는 각 애플리케이션의 통신 요건에 기초하여 버퍼를 자동으로 생성할 수도 있다. 예를 들어, 게임 프레임워크(2000)는 텍스트, 오디오, 및/또는 비디오가 지원될 필요가 있는지에 기초하여 특정한 버퍼 크기를 선택할 수도 있다.
한 실시예에서, 통신 버퍼(2003)는 사용자들 사이에서 모든 P2P 접속들이 확립되기 이전에 통신 스트림을 임시로 저장할 수도 있다. 예를 들어, 초대 서비스(112) 또는 중매자 서비스(111)가 각 사용자를 식별한 후로서 CDX 서비스(110)가 접속 데이터 교환 동작을 완료하기 이전에, 각 사용자는 접속되고 있는 도중에 다른 게임 참여자들을 통보받을 수도 있다. 이 단계에서, 모바일 장치(120)의 사용자는, 텍스트, 오디오, 및/또는 비디오 통신 스트림을 다른 참여자들에게 전송할 수도 있다. 게임 프레임워크(2000)는 아직 접속되지 않은 참여자들에 대한 통신 스트림을 통신 버퍼(2003) 내에 저장할 것이다. 게임 프레임워크(2000)는 그 다음, 각 장치에 대한 접속이 완료됨에 따라 버퍼(2003)로부터 텍스트, 오디오, 및/또는 비디오를 전송할 수도 있다.
한 실시예에서, 게임 데몬(2020)은, 네트워크 트래픽을 줄이기 위해 서비스(2050)들 각각 상에서 지속되는 데이터를 캐싱하기 위한 캐시(2021)를 포함한다. 예를 들어, 사용자의 친구 목록, 점수판 데이터, 업적 데이터, 존재 데이터, 및 프로파일 데이터가 캐시 관리 정책에 의해 명시된 바와 같이 캐시(2021)에 저장될 수도 있다. 한 실시예에서, 캐시 관리 정책은 데이터가 저장되는 각 개별 서비스에 의해 구동된다. 결과적으로, n개의 상이한 서비스에 대해, n개의 상이한 캐시 관리 정책이 캐시(2021)에 적용될 수도 있다. 또한, 캐시 관리 정책은 서비스들에 의해 구동되기 때문에, 캐시 관리 정책은 현재의 네트워크 및/또는 서버 부하 상태에 기초하여 동적으로 수정될 수도 있다. 예를 들어, 서비스에 부하가 많이 걸리는 기간 동안에(예를 들어, 크리스마스, 신제품 출시일 등), 서비스는 비교적 덜 빈번한 캐시 업데이트(예를 들어, 매 12시간마다 업데이트)를 갖는 캐시 관리 정책을 동적으로 명시할 수도 있다. 대조적으로, 서비스에 부하가 많이 걸리지 않는 기간 동안에, 서비스는 더 빈번한 캐시 업데이트(예를 들어, 매 1/2시간, 1시간, 2시간 마다의 업데이트 등)를 갖는 캐싱 정책을 명시할 수도 있다.
한 실시예에서, 캐시 관리 정책은, 캐시(2021)에 저장된 소정의 데이터 레코드에 대한 생존(TTL; time-to-live) 값을 이용하여 명시된다. 데이터 레코드가 그 TTL 값을 지나서 캐시에 저장되고 있다면, 그 데이터는 "오래된(stale)" 것으로 간주되고, 그 데이터에 대한 국지적 요청은 그 데이터와 연관된 서비스에 직접 포워딩될 수도 있다. 한 실시예에서, 이 요청은 데이터의 현재 버전을 식별하는 ID 코드를 포함한다. 만일 ID 코드가 서비스 상의 ID 코드와 일치하면, 그 데이터는 여전히 유효하고 업데이트될 필요가 없다. 그 다음, 캐시 내의 데이터가 현행(current)이라는 것을 나타내는 응답이 서비스로부터 되전송되고, 그 데이터 레코드에 대한 TTL 값이 리셋될 수도 있다.
전술된 바와 같이 캐시 관리 정책을 이용하는 것 외에도, 한 실시예에서, 소정 타입의 데이터에 대한 캐시 업데이트가 푸시 통보 서비스(1050)를 이용하여 모바일 장치에 푸시될 수도 있다. 예를 들어, 사용자 친구 목록에 대한 변경이나 사용자 친구의 현재 온라인 상태에 대한 변경이, 사용자의 모바일 장치(120)에 동적으로 푸시될 수도 있다. 푸시 통보는 게임 데몬(2020)에 의해 수신되고, 그 다음, 게임 데몬(2020)은 서비스에 의해 푸시된 데이터의 관련 부분을 포함하도록 캐시(2021)를 업데이트할 수도 있다(즉, 그 서비스와 연관된 캐시 내의 데이터 모두의 업데이트가 요구되는 것은 아닐 수도 있다). 대조적으로, 일부 푸시 통보는 게임 데몬(2020)에게 캐시의 전체 내용을(또는 푸시를 수행하는 서비스와 연관된 캐시의 적어도 일부를) 오버라이트하도록 지시할 수도 있다.
캐시(2021)를 업데이트하기 위해 푸시를 이용하는 이들 서비스들은, 캐시(2021)에 저장된 데이터를 업데이트하라는 통보를 푸시하는 능력을 갖기 때문에 비교적 높은 TTL 값을 선택할(및/또는 TTL 값을 설정하지 않을) 수도 있다. 한 실시예에서, 각 서비스는 푸시 통보 캐시 업데이트를 트리거할 수도 있는 한 세트의 이벤트를 명시한다. 예를 들어, 캐시 업데이트 이벤트는, 친구의 온라인 상태에 대한 변경, 새로운 친구 요청, 친구 요청의 수락, 친구해제 동작, 친구가 특정 게임을 플레이하고 있다는 표시, 친구가 도달한 게임 업적, 특정 점수판의 탑 10에 대한 업데이트, 또는 캐시 업데이트를 보장하기에 충분히 중요하다고 여겨지는 기타 임의의 이벤트를 포함할 수도 있다. 이런 방식으로 캐시(2021)를 업데이트하기 위해 푸시 통보를 이용하는 것은 네트워크 및 서비스 부하를 감소시킬 수도 있는데, 이것은 푸시 업데이트에 의해, 모바일 장치와 서비스 사이의 주기적 폴링이 요구되지 않기 때문이다.
게임 프레임워크(2000)의 한 실시예는, 사용자의 국가 및/또는 지리적 위치에 기초하여 엔드 유저에 제시되는 데이터를 고유하게 포멧팅한다. 예를 들어, 현재 날짜, 시간, 및 금전 가치와 같은 값들은, 상이한 국가 및 장소의 사용자들에게 상이하게 제시될 수도 있다. 예로서, 미국에서, 날짜 포멧은 [월 일, 연도](예를 들어, 4월 25일, 2010)인 반면, 다른 나라에서는, 날짜 포멧은 [날 월, 연도](예를 들어, 25일 4월, 2010)일 수도 있다. 마찬가지로, 미국 및 일부 다른 나라들에서 시간을 표시할 때, AM/PM 표기가 이용될 수도 있고, 시간과 분 사이에 콜론이 이용될 수도 있다(예를 들어, 3:00 PM). 대조적으로, 많은 다른 나라들은 AM/PM 표기를 이용하지 않고, 및/또는 시간과 분 사이에 콤마를 이용한다(예를 들어, 15,00). 또 다른 예로서, 세계의 많은 지역들은 미터법(metric system)을 이용하는 반면, 세계의 일부 지역에서는 이용하지 않는다(예를 들어, 미국). 이들은 본 발명의 어떤 실시예들에 의해 이용될 수도 있는 단순한 예일 뿐이라는 점에 유의해야 한다. 본 발명의 기저 원리는 임의의 특정 세트의 데이터 포멧으로 한정되지 않는다.
한 실시예에서, 이들 상이한 데이터 포멧들은, 점수판 데이터, 업적 데이터, 친구 데이터, 및/또는 게임 프레임워크(2000)에 의해 처리되는 기타 임의의 데이터를 표시할 때 선택될 수도 있다. 게임 프레임워크(2000)는 다양한 방식으로 사용자의 국가 및/또는 지리적 위치를 판정할 수도 있다. 예를 들어, 한 실시예에서, 이 정보는 간단히 사용자의 프로파일 데이터에 제공되거나 및/또는 사용자의 셀룰러 서비스 제공자에 기초하여 결정될 수도 있다. 사용자의 위치는 또한, 예를 들어, GPS(Global Positioning System) 추적을 이용하여 결정될 수도 있다.
지리적 위치 및/또는 국가와 관련없는 다른 타입의 데이터 포멧팅은 또한 게임 프레임워크(2000)에 의해 관리될 수도 있다. 예를 들어, 점수판 데이터를 디스플레이할 때, 가장 낮은 점수가 그 사용자를 점수판의 최상위 또는 최하위에 위치시켜야 할지를 아는 것이 중요하다. 일부 게임의 경우(예를 들어, 골프, 트랙, 레이싱, 스키 등), 낮은 점수일수록 더 나은 성과를 나타내는 반면, 다른 게임에서는(예를 들어, 풋볼, 야구 등), 더 높은 숫자일수록 더 나은 성과를 나타낸다. 따라서, 한 실시예에서, 애플리케이션(2030)은 API(2001)를 통해 이용될 점수의 타입(예를 들어, "오름차순" 또는 "내림차순")을 명시한다. 그 다음, 게임 프레임워크(2000)는, 점수를 디스플레이하기 위한 적절한 세트의 라벨과 포멧팅을 이용할 것이다.
게임 프레임워크(2000)의 한 실시예는 또한, 사용자와 사용자의 친구 사이의 관계에 기초하여 사용자 데이터를 필터링한다. 예를 들어, 본 발명의 한 실시예는 "상세" 뷰, "친구" 뷰, 및 "공개" 뷰를 허용한다. 한 실시예에서, 상세 뷰는 그 데이터를 소유하는 사용자에게 이용가능하다(즉, 사용자의 개인 정보); 친구 뷰는 사용자의 친구에게 이용가능하다; 그리고, 공개 뷰는 다른 모든 사용자들에게 이용가능하다.
예로서, 공개 뷰는 단순히, 각 사용자와 연관된 "별명(alias)", 그 별명으로 플레이하는 게임들과 점수, 및 게임이 플레이된 날짜/시간을 포함할 수도 있다. 이 정보는, 공개 점수판을 채우기 위해 게임 프레임워크(2000)에 의해 이용된 다음, 게임 센터(2031)를 통해 표시될 수도 있다.
친구 뷰는, 예를 들어, 몇 가지 예를 들자면, 사용자가 소유한 게임들; 사용자가 플레이한 게임들; 사용자의 업적 및 점수; 사용자의 친구수; 이들 친구들의 신분; 사용자의 아바타, 및/또는 사용자의 온라인 상태를 식별하는 URL을 포함한, 사용자의 친구들 사이에서 공유되는 임의의 추가 정보 뿐만 아니라 일반적인 뷰로부터의 정보 모두를 포함할 수도 있다. 한 실시예에서, "친구" 뷰는 친구들과 공유할 디폴트 세트의 정보를 제공하지만, 엔드 유저는 이 디폴트 구성을 조정하고 각 개별 친구 또는 친구 그룹(예를 들어, 동료, 가족 구성원, 대학/고등학교 친구 등)에 의해 공유될 정보의 타입을 구체적으로 명시할 수도 있다.
"상세" 뷰는, "공개" 및 "친구" 뷰로부터의 모든 정보 뿐만 아니라 엔드 유저를 위하여 다양한 서비스(2050)에 의해 관리되는 기타 임의의 정보를 포함할 수도 있다. 예로서, 이것은, 사용자의 모든 프로파일 데이터; 사용자의 UUID(Universally Unique Identifier)(때때로, 여기서는 "플레이어 ID"라고 함); 플레이어 이름; 별명; 게임수 및 게임의 아이덴티티; 사용자의 친구; 사용자의 모든 업적 등을 포함할 수도 있다.
일부 상황에서는, 애플리케이션(2030)은 각 사용자의 플레이어 ID와 같은 각 사용자에 관련된 소량의 정보만을 요구할 수도 있다. 예를 들어, 한 실시예에서, 매치가 요청되면, 게임 프레임워크(2000)는 처음에 각 플레이어의 ID만을 요구할 수도 있다. 중매자 서비스에 의해 매치들이 이루어짐에 따라(상기 참조), 게임 프레임워크(2000)는 매치된 사용자들 중 임의의 사용자가 친구인지를 판정할 수도 있다(예를 들어, 친구 서비스와의 통신을 통해, 및/또는 사용자의 국지 친구 데이터에서 정보를 얻음으로써). 만일 그렇다면, 게임 프레임워크(2000)는 추가의 사용자 데이터를 회수하고, 그 데이터를 임의의 매치된 친구들에게 제공할 수도 있다. 이런 방식으로, 게임 프레임워크(2000)는 사용자의 신분과 사용자들 각자간의 관계에 기초하여 정보를 필터링한다.
한 실시예에서, 게임 프레임워크(2000)는 처음에 제1 사용자와 제2 사용자가 친구 관계가 아니라면 이들 사이의 공개 뷰를 제공한다. 그러나, 한 실시예에서, 게임 프레임워크(2000)는 제1 사용자가 제2 사용자에게 친구 요청을 전송하는 것을 허용한다(예를 들어, 제2 사용자의 별명을 이용하여). 만일 친구 요청이 수락되면, 게임 프레임워크(2000)는 사용자들 각자에게 추가 정보(예를 들어, 디폴트 "친구" 뷰)를 제공할 것이다.
상이한 API 구현예
한 실시예에서 구현된 API는, 상이한 소프트웨어 컴포넌트(이하에서는 "API 호출 소프트웨어 컴포넌트")가 소프트웨어 컴포넌트를 구현하는 API에 의해 제공되는 하나 이상의 함수, 방법, 프로시져, 데이터 구조, 및/또는 기타의 서비스들을 액세스하여 이용하는 것을 허용하는 소프트웨어 컴포넌트(이하에서는 "API 구현 소프트웨어 컴포넌트)에 의해 구현된 인터페이스이다. 예를 들어, API는 API 호출 소프트웨어 컴포넌트의 (제3자 개발자일 수도 있는) 개발자가 API 구현 소프트웨어 컴포넌트에 의해 제공된 명시된 특징을 레버리지하는 것을 허용한다. 하나의 API 호출 소프트웨어 컴포넌트가 있거나, 하나보다 많은 이러한 소프트웨어 컴포넌트가 있을 수도 있다. API는, 소프트웨어 애플리케이션으로부터의 서비스들에 대한 요청을 지원하기 위해 컴퓨터 시스템이나 프로그램 라이브러리가 제공하는 소스 코드 인터페이스일 수 있다. API는, 메모리에서 데이터가 어떻게 레이아웃되는지에 관한 명시적 로우 레벨 설명이 아니라, 애플리케이션 구축시에 애플리케이션이 인터프리터되거나 컴파일될 수 있는 프로그래밍 언어에 의해 명시될 수 있다.
API는, API 구현 소프트웨어 컴포넌트의 명시된 특징을 액세스하여 이용할 때 API 호출 소프트웨어 컴포넌트가 이용하는 언어와 파라미터를 정의한다. 예를 들어, API 호출 소프트웨어 컴포넌트는, API에 의해 노출된 하나 이상의 API 호출(때때로, 함수 또는 메소드 호출이라고 함)을 통해 API 구현 소프트웨어 컴포넌트의 명시된 특징을 액세스한다. API 구현 소프트웨어 컴포넌트는, API 호출 소프트웨어 컴포넌트로부터의 API 호출에 응답하여 API를 통해 값을 반환할 수도 있다. API가 API 호출의 구문론(syntax)과 결과(예를 들어, 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는 특정의 프로그래밍 언어의 관점에서 구현될 수 도 있다.
도 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(2120)를 통해 API 호출 소프트웨어 컴포넌트(2130)에 값을 반환할 수도 있다.
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에 호출을 행하고 이로부터 반환된 값들을 수신하며, (예를 들어, 소프트웨어 라이브러리일 수 있는) 서비스 2는 OS API 1 및 OS API 2 양쪽 모두에 호출을 행하고 이들로부터 반환된 값들을 수신한다. 애플리케이션 2는 OS API 2에 호출을 행하고 이로부터 반환된 값들을 수신한다.
예시적 데이터 처리 장치
도 23은 본 발명의 일부 실시예들에서 이용될 수도 있는 예시적 컴퓨터 시스템을 나타내는 블록도이다. 도 23은 컴퓨터 시스템의 다양한 컴포넌트들을 나타내고 있지만, 컴포넌트들을 상호접속하는 임의의 특정한 아키텍쳐나 방식과 같은 세부사항은 본 발명과 관련없기 때문에 나타낼 의도가 없다는 점을 이해하여야 한다. 더 적거나 더 많은 컴포넌트를 갖는 다른 컴퓨터 시스템들도 역시 본 발명에 이용될 수도 있다는 점을 이해할 것이다.
도 23에 나타낸 바와 같이, 데이터 처리 시스템의 한 형태인 컴퓨터 시스템(2300)은, 처리 시스템(2320), 전원(2325), 메모리(2330), 및 비휘발성 메모리(2340)(예를 들어, 하드 드라이브, 플래시 메모리, 상변화 메모리(PCM) 등)과 결합되는 버스(들)(2350)을 포함한다. 버스(들)(2350)은, 본 분야에 공지된 다양한 브릿지, 제어기 및/또는 어댑터들을 통해 서로 접속될 수도 있다. 처리 시스템(2320)은 메모리(2330) 및/또는 비휘발성 메모리(2340)로부터 명령어(들)을 회수하여, 전술된 바와 같은 동작들을 수행하기 위해 그 명령들을 실행할 수도 있다. 버스(2350)는 상기 컴포넌트들을 함께 상호접속하고, 이들 컴포넌트들을, 선택사항적 도크(2360), 디스플레이 제어기 & 디스플레이 장치(2370), 입력/출력 장치(2380)(예를 들어, NIC(네트워크 인터페이스 카드), 커서 제어(예를 들어, 마우스, 터치스크린, 터치패드 등), 키보드 등), 및 선택사항적 무선 트랜시버(들)(2390)(예를 들어, Bluetooth, WiFi, Infrared 등)에 상호접속한다.
도 24은 본 발명의 일부 실시예들에서 이용될 수도 있는 예시적 데이터 처리 시스템을 나타내는 블록도이다. 예를 들어, 데이터 처리 시스템(2400)은, 핸드헬드 컴퓨터, PDA(personal digital assistant), 모바일 전화, 휴대형 게이밍 시스템, 휴대형 미디어 재생기, 모바일 전화, 미디어 재생기, 및/또는 게이밍 시스템을 포함할 수도 있는 태블릿 또는 핸드헬드 컴퓨팅 장치일 수도 있다. 또 다른 예로서, 데이터 처리 시스템(2400)은 네트워크 컴퓨터이거나 또 다른 장치 내에 내장된 처리 장치일 수도 있다.
본 발명의 한 실시예에 따르면, 전술된 모바일 장치에 대해 데이터 처리 시스템(2400)의 예시적 아키텍쳐가 이용될 수도 있다. 데이터 처리 시스템(2400)은, 하나 이상의 마이크로프로세서 및/또는 집적 회로 상의 시스템을 포함할 수도 있는 처리 시스템(2420)을 포함한다. 처리 시스템(2420)은, 메모리(2410), (하나 이상의 배터리를 포함하는) 전원(2425), 오디오 입력/출력(2440), 디스플레이 제어기 및 디스플레이 장치(2460), 선택사항적 입력/출력(2450), 입력 장치(들)(2470), 및 무선 트랜시버(들)(2430)과 결합된다. 도 24에 도시되지 않은 추가의 컴포넌트들은, 본 발명의 소정 실시예들에서 데이터 처리 시스템(2400)의 일부가 될 수도 있으며, 본 발명의 소정 실시예들에서는, 도 24에 도시된 것보다 적은 컴포넌트들이 이용될 수도 있다는 것을 이해할 것이다. 또한, 본 분야에 공지된 바와 같이 다양한 컴포넌트를 상호접속하기 위해 도 24에 도시되지 않은 하나 이상의 버스가 이용될 수도 있다는 것을 이해할 것이다.
메모리(2410)는 데이터 처리 시스템(2400)에 의해 실행되기 위한 데이터 및/또는 프로그램을 저장할 수도 있다. 오디오 입력/출력(2440)은, 예를 들어, 음악을 재생하거나 및/또는 스피커 및 마이크로폰을 통해 전화 기능을 제공하기 위하여 마이크로폰 및/또는 스피커를 포함한다. 디스플레이 제어기 및 디스플레이 장치(2460)는 그래픽 유저 인터페이스(GUI)를 포함할 수도 있다. 다른 데이터 처리 시스템과 통신하기 위해 무선(예를 들어, RF) 트랜시버(2430)(예를 들어, WiFi 트랜시버, 적외선 트랜시버, Bluetooth 트랜시버, 무선 셀룰러 전화 트랜시버 등)가 이용될 수도 있다. 하나 이상의 입력 장치(2470)는 사용자가 시스템을 입력을 제공하는 것을 허용한다. 이들 입력 장치는 키패드, 키보드, 터치 패널, 멀티 터치 패널 등일 수도 있다. 선택사항적인 다른 입력/출력(2450)은 도크에 대한 커넥터일 수도 있다.
본 발명의 실시예들은 전술된 다양한 단계들을 포함할 수도 있다. 이 단계들은 범용 컴퓨터 또는 특별 목적 컴퓨터가 소정의 단계들을 수행하게끔 하는 머신-실행가능한 명령어들로 구현될 수도 있다. 대안으로서, 이들 단계들은, 단계들을 수행하기 위한 하드와이어드 로직을 포함하는 특정의 하드웨어 컴포넌트들에 의해 수행되거나, 프로그램된 컴퓨터 컴포넌트 및 맞춤형 하드웨어 컴포넌트들의 임의 조합에 의해 수행될 수도 있다.
본 발명의 요소들은 또한, 머신-실행가능한 프로그램 코드를 저장하기 위한 머신-판독가능한 매체로서 제공될 수도 있다. 머신-판독가능한 매체는, 플로피 디스켓, 광학 디스크, CD-ROM, 및 광자기 디스크, ROM, RAM, EPROM, EEPROM, 자기 또는 광학 카드, 또는 전자 프로그램 코드를 저장하기 위한 기타 유형의 미디어-머신-판독가능한 매체를 포함할 수도 있지만, 이들로 한정되는 것은 아니다.
상기 상세한 설명 전체를 통해, 설명의 목적을 위해, 많은 구체적인 세부사항이 본 발명의 철저한 이해를 제공하기 위하여 개시되었다. 그러나, 본 발명은 이와 같은 구체적인 세부사항들 중 일부가 없이도 실시될 수 있다는 것은 당업자에게 명백할 것이다. 예를 들어, 여기서 설명된 기능 모듈들 및 방법들은 소프트웨어, 하드웨어, 또는 이들의 임의 조합으로서 구현될 수도 있다는 것은 당업자에게 용이하게 명백할 것이다. 게다가, 본 발명의 실시예들이 모바일 컴퓨팅 환경의 정황에서(즉, 모바일 장치 120-123; 601-603을 이용하여) 여기서 설명되었지만, 본 발명의 기저 원리는 모바일 컴퓨팅 구현으로 한정되는 것은 아니다. 예를 들어, 데스크탑이나 워크스테이션 컴퓨터를 포함하는 일부 실시예들에서, 사실상 임의 타입의 클라이언트 또는 피어 데이터 처리 장치들이 이용될 수도 있다. 따라서, 본 발명의 범위와 사상은 이하의 청구항들에 관하여 판단되어야 한다.

Claims (30)

  1. 모바일 장치들 사이에 피어-투-피어("P2P") 통신을 확립하기 위한 컴퓨터-구현된 방법으로서,
    제1 모바일 장치로부터 P2P 통신 채널을 개방하라는 초대 요청을 상기 모바일 장치들 외부의 초대 서비스에서 수신하는 단계 - 상기 초대 요청은 제2 모바일 장치의 식별자 및 상기 제1 모바일 장치의 네트워크 구성에 관련된 네트워크 정보를 포함함 -;
    상기 제2 모바일 장치에 대한 푸시 통보 서비스 식별자를 식별하기 위해 상기 제2 모바일 장치의 상기 식별자를 이용하는 단계;
    상기 모바일 장치들 외부의 푸시 통보 서비스에서 상기 푸시 통보 서비스 식별자를 이용하여 상기 제2 모바일 장치를 식별하고 상기 초대 요청을 상기 푸시 통보 서비스로부터 상기 제2 모바일 장치에 푸시하는 단계;
    상기 초대 서비스에서 상기 제2 모바일 장치로부터 응답을 수신하는 단계 - 상기 응답은 초대의 수락 및 상기 제2 모바일 장치의 네트워크 구성에 관련된 네트워크 정보를 포함함 -;
    상기 제1 모바일 장치와 상기 제2 모바일 장치 사이의 직접적 P2P 접속이 가능한지를 판정하기 위해 상기 제1 모바일 장치와 상기 제2 모바일 장치의 네트워크 정보를 상기 초대 서비스가 평가하는 단계 - 상기 제1 모바일 장치와 상기 제2 모바일 장치 사이에 P2P 직접적 접속이 가능하다고 판단하면, 상기 초대 서비스는 상기 제2 모바일 장치와의 피어-투-피어 접속을 확립하기 위해 상기 제1 모바일 장치에 의해 사용가능한 상기 제2 모바일 장치에 대한 접속 데이터와 함께 상기 초대의 수락을 상기 제1 모바일 장치로 송신함 - ;
    상기 제1 모바일 장치와 상기 제2 모바일 장치 사이의 중계 접속을 확립하기 위한 요청을 상기 모바일 장치들 외부의 중계 서비스에서 상기 초대 서비스로부터 수신하는 단계 - 상기 초대 서비스가 상기 제1 모바일 장치와 상기 제2 모바일 장치 사이의 P2P 직접적 접속이 가능하지 않다고 판단한 경우, 상기 초대 서비스는 상기 중계 서비스와 연관된 중계 서비스 네트워크 정보를 식별하고, 상기 제1 모바일 장치 및 상기 제2 모바일 장치로 상기 중계 서비스 네트워크 정보를 전달함 - ;
    상기 제1 모바일 장치 및 상기 제2 모바일 장치가 상기 중계 서비스에 접속하기 위해 상기 중계 서비스 네트워크 정보를 이용하는 단계; 및
    이에 응답하여 상기 중계 서비스를 통해 상기 제1 모바일 장치와 상기 제2 모바일 장치 간의 접속을 확립하는 단계
    를 포함하는, 컴퓨터-구현된 방법.
  2. 제1항에 있어서,
    상기 제2 모바일 장치로부터 푸시 통보 등록(push notification registration)을 수신하는 단계; 및
    이에 응답하여 디렉토리 데이터베이스 내에 상기 푸시 통보 서비스 식별자를 포함하는 상기 푸시 통보 등록을 등록하는 단계
    를 더 포함하고,
    상기 푸시 통보 서비스 식별자를 이용하여 상기 제2 모바일 장치를 식별하고 상기 초대 요청을 상기 제2 모바일 장치에 푸시하는 단계는, 상기 제2 모바일 장치의 식별자를 이용하여 상기 디렉토리 데이터베이스에서 상기 푸시 통보 서비스 식별자를 식별하고, 이에 응답하여 상기 푸시 통보 서비스 식별자를 이용하여 상기 초대 요청을 상기 제2 모바일 장치에 푸시하는 단계를 포함하는, 컴퓨터-구현된 방법.
  3. 제1항에 있어서,
    상기 네트워크 정보는 상기 제1 모바일 장치 및 상기 제2 모바일 장치와 연관된 네트워크 주소 변환(network address translation: "NAT") 타입 데이터를 포함하는, 컴퓨터-구현된 방법.
  4. 제3항에 있어서,
    상기 제1 모바일 장치와 상기 제2 모바일 장치 사이의 직접적 P2P 접속이 가능한지를 판정하기 위해 상기 제1 모바일 장치와 상기 제2 모바일 장치의 네트워크 정보를 평가하는 단계는, 상기 제1 모바일 장치 및 상기 제2 모바일 장치의 NAT 타입들이 호환되는지를 판정하는 단계를 포함하는, 컴퓨터-구현된 방법.
  5. 제1항에 있어서,
    상기 제1 모바일 장치와 상기 제2 모바일 장치 사이의 하나 이상의 이전의 P2P 접속 시도가 성공적이지 못하였는지를 판정하는 단계; 및
    하나 이상의 이전의 P2P 접속 시도가 성공적이지 못했는지의 여부에 적어도 부분적으로 기초하여, 상기 제1 모바일 장치와 상기 제2 모바일 장치 사이의 직접적 P2P 접속이 가능한지를 판정하는 단계
    를 더 포함하는, 컴퓨터-구현된 방법.
  6. 제5항에 있어서,
    상기 제1 모바일 장치와 상기 제2 모바일 장치 사이의 하나 이상의 이전의 P2P 접속 시도가 성공적이지 못하였는지를 판정하는 단계는, 하나 이상의 이전의 P2P 접속 시도가 성공적이지 못했다는 표시를 상기 제2 모바일 장치로부터 수신하는 단계를 포함하는, 컴퓨터-구현된 방법.
  7. 제1항에 있어서,
    상기 중계 서비스와 연관된 네트워크 정보는, 상기 제1 모바일 장치에 의해 이용될 제1 중계 호스트 주소와 상기 제2 모바일 장치에 의해 이용될 제2 중계 호스트 주소를 포함하는, 컴퓨터-구현된 방법.
  8. 제7항에 있어서,
    상기 제1 모바일 장치로부터 제1 중계 업데이트 트랜잭션을 수신하는 단계 - 상기 제1 중계 업데이트 트랜잭션은 상기 제1 모바일 장치에 대한 NAT 횡단/접속(traversal/connection) 데이터를 포함함 -;
    상기 제2 모바일 장치에 상기 제1 중계 업데이트 트랜잭션을 송신하는 단계;
    상기 제2 모바일 장치로부터 제2 중계 업데이트 트랜잭션을 수신하는 단계 - 상기 제2 중계 업데이트 트랜잭션은 상기 제2 모바일 장치에 대한 NAT 횡단/접속 데이터를 포함함 -; 및
    상기 제1 모바일 장치에 상기 제2 중계 업데이트 트랜잭션을 송신하는 단계
    를 더 포함하는, 컴퓨터-구현된 방법.
  9. 제8항에 있어서,
    상기 제1 모바일 장치 및 상기 제2 모바일 장치는 푸시 통보를 수신하기 위해 디렉토리 데이터베이스 내에 앞서 등록되었고, 상기 제1 중계 업데이트 트랜잭션을 송신하는 단계는 상기 디렉토리 데이터베이스 내에서 상기 제2 모바일 장치를 식별하고, 이에 응답하여 상기 제1 중계 업데이트를 상기 제2 모바일 장치에 푸시하는 단계를 포함하고, 상기 제2 중계 업데이트 트랜잭션을 송신하는 단계는 상기 디렉토리 데이터베이스 내에서 상기 제1 모바일 장치를 식별하고, 이에 응답하여 상기 제1 중계 업데이트를 상기 제2 모바일 장치에 푸시하는 단계를 포함하는, 컴퓨터-구현된 방법.
  10. 제8항에 있어서,
    상기 제1 모바일 장치 및 상기 제2 모바일 장치에 대한 NAT 횡단/접속 데이터는, 상기 NAT 횡단/접속 데이터가 현행임을 보장하도록 상기 제1 모바일 장치 및 상기 제2 모바일 장치 각각과 상기 중계 서비스 사이의 트랜잭션에 의해 결정되는, 컴퓨터-구현된 방법.
  11. 컴퓨팅 장치에 의해 실행될 때, 상기 컴퓨팅 장치로 하여금 제1항 내지 제10항 중 어느 한 항의 방법을 수행하도록 하는 프로그램 코드가 저장된 머신-판독가능한 매체.
  12. 프로그램 코드를 저장하기 위한 메모리, 및 상기 프로그램 코드를 처리하여 제1항 내지 제10항 중 어느 한 항의 방법을 수행하기 위한 프로세서를 포함하는 컴퓨팅 장치.
  13. 삭제
  14. 삭제
  15. 삭제
  16. 삭제
  17. 삭제
  18. 삭제
  19. 삭제
  20. 삭제
  21. 삭제
  22. 삭제
  23. 삭제
  24. 삭제
  25. 삭제
  26. 삭제
  27. 삭제
  28. 삭제
  29. 삭제
  30. 삭제
KR1020127028631A 2010-04-07 2010-09-23 사용자를 온라인 세션에 초대하기 위한 장치 및 방법 KR101408560B1 (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US32183210P 2010-04-07 2010-04-07
US61/321,832 2010-04-07
US12/832,003 2010-07-07
US12/832,003 US8412833B2 (en) 2010-04-07 2010-07-07 Apparatus and method for inviting users to online sessions
PCT/US2010/050065 WO2011126504A1 (en) 2010-04-07 2010-09-23 Apparatus and method for inviting users to online sessions

Publications (2)

Publication Number Publication Date
KR20130006496A KR20130006496A (ko) 2013-01-16
KR101408560B1 true KR101408560B1 (ko) 2014-06-17

Family

ID=44761701

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020127028631A KR101408560B1 (ko) 2010-04-07 2010-09-23 사용자를 온라인 세션에 초대하기 위한 장치 및 방법

Country Status (7)

Country Link
US (2) US8412833B2 (ko)
EP (1) EP2556649B1 (ko)
JP (1) JP5628998B2 (ko)
KR (1) KR101408560B1 (ko)
AU (1) AU2010350742B2 (ko)
MX (1) MX2012011618A (ko)
WO (1) WO2011126504A1 (ko)

Families Citing this family (64)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8038535B2 (en) 2005-05-17 2011-10-18 Electronic Arts Inc. Collaborative online gaming system and method
US8521809B2 (en) * 2009-07-31 2013-08-27 Z2Live, Inc. Mobile device notification controls system and method
US20110250971A1 (en) 2010-04-07 2011-10-13 Van Os Marcel Methods and systems for providing a game center having customized notifications
US8825962B1 (en) * 2010-04-20 2014-09-02 Facebook, Inc. Push-based cache invalidation notification
US8924304B2 (en) 2010-06-04 2014-12-30 Apple Inc. Methods for using unique identifiers to identify systems in collaborative interaction in a mesh network
KR20120081368A (ko) * 2011-01-11 2012-07-19 주식회사 엔씨소프트 모바일 플랫폼에서의 채팅을 통한 게임 초대 방법
US20120311504A1 (en) * 2011-06-03 2012-12-06 Van Os Marcel Extensible architecture for navigating a hierarchy
JP5433639B2 (ja) * 2011-06-30 2014-03-05 株式会社コナミデジタルエンタテインメント ゲーム装置およびプログラム
US8784214B2 (en) * 2011-07-05 2014-07-22 Sony Computer Entertainment Inc. Method and system for establishing location-based leaderboard
US9576434B2 (en) 2011-07-25 2017-02-21 Sony Interactive Entertainment Inc. Implementing computer activity-based challenges
CN102624534A (zh) * 2011-10-18 2012-08-01 北京小米科技有限责任公司 一种建立群组的方法
KR101341490B1 (ko) * 2011-10-31 2014-01-14 주식회사 유비벨록스모바일 복합 방식을 이용한 푸시 발송 시스템 및 방법
CN103327039A (zh) * 2012-03-20 2013-09-25 腾讯科技（深圳）有限公司 一种消息推送方法及装置、系统
GB201210600D0 (en) 2012-06-14 2012-08-01 Microsoft Corp Call invites
GB201210596D0 (en) 2012-06-14 2012-08-01 Microsoft Corp Notification of communication events
GB2504461B (en) 2012-06-14 2014-12-03 Microsoft Corp Notification of communication events
GB201210598D0 (en) 2012-06-14 2012-08-01 Microsoft Corp Notification of communication events
JP6224591B2 (ja) 2012-08-06 2017-11-01 グリー株式会社 表示システム、同システムにおける表示方法及び表示プログラム
JP2016503536A (ja) 2012-11-12 2016-02-04 カルガリー サイエンティフィック インコーポレイテッド 共同セッションに加えるユーザに通知および勧誘を行うためのフレームワーク
JP6171409B2 (ja) * 2013-03-05 2017-08-02 株式会社バッファロー 通信システム、通信管理方法
US9363165B2 (en) * 2013-03-11 2016-06-07 Qualcomm Incorporated Enhanced call control for directing a content path over multiple connections
US9141682B1 (en) 2013-03-25 2015-09-22 Amazon Technologies, Inc. Resolving conflicts within saved state data
TWI493924B (zh) * 2013-04-10 2015-07-21 D Link Corp Through the two network devices to help complete the STUN technology network system and its methods
US20140364237A1 (en) * 2013-06-07 2014-12-11 Matthew Robert Read Multiplayer network game notifications
US9244994B1 (en) * 2013-06-19 2016-01-26 Amazon Technologies, Inc. Idempotency of application state data
US20160295597A1 (en) * 2013-07-26 2016-10-06 Intel IP Corporation Signaling interference information for user equipment assistance
JP6281223B2 (ja) * 2013-09-30 2018-02-21 ブラザー工業株式会社 通信機器
CN103618747B (zh) * 2013-12-11 2016-09-21 中国联合网络通信集团有限公司 一种实现sip信息服务的方法及系统
US9609056B2 (en) * 2014-03-29 2017-03-28 Google Technology Holdings LLC Methods for obtaining content from a peer device
US9776091B1 (en) 2014-05-16 2017-10-03 Electronic Arts Inc. Systems and methods for hardware-based matchmaking
US9712623B2 (en) * 2014-05-30 2017-07-18 Apple Inc. Answering a call with client through a host
CN104320498B (zh) * 2014-07-04 2018-02-13 物联智慧科技（深圳）有限公司 有效保持nat通道服务方法
TWI555357B (zh) * 2014-07-04 2016-10-21 Throughtek Technology Shenzhen Co Ltd Effectively maintain the NAT channel service method
US9923907B2 (en) 2014-07-08 2018-03-20 International Business Machines Corporation Push notifications of system events in a restricted network
US9825899B2 (en) * 2014-07-10 2017-11-21 Facebook, Inc. Systems and methods for directng messages based on social data
US9154736B1 (en) * 2014-07-16 2015-10-06 Omnivision Technologies, Inc. Video conferencing with a mobile platform
JP6173268B2 (ja) * 2014-07-24 2017-08-02 日本電信電話株式会社 マッチングシステム、マッチング方法及びＷｅｂサーバ
US9614915B2 (en) * 2014-08-18 2017-04-04 Google Inc. Seamless peer to peer internet connectivity
US10298547B2 (en) * 2014-11-14 2019-05-21 William J. Ziebell Systems, methods, and media for a cloud based social media network
JP2016162068A (ja) * 2015-02-27 2016-09-05 株式会社ソニー・インタラクティブエンタテインメント 情報処理装置、メッセージ表示方法および情報システム
US10075447B2 (en) * 2015-03-04 2018-09-11 Neone, Inc. Secure distributed device-to-device network
US10123229B2 (en) 2015-03-10 2018-11-06 Hewlett Packard Enterprise Development Lp Sensing conditions of a wireless network
US9720760B2 (en) * 2015-03-10 2017-08-01 Aruba Networks, Inc. Mitigating wireless networking problems of a wireless network
US10219174B2 (en) 2015-03-10 2019-02-26 Hewlett Packard Enterprise Development Lp Capacity estimation of a wireless link
US9894536B2 (en) 2015-03-10 2018-02-13 Aruba Networks, Inc. Motion-controlled device for supporting planning, deployment or operation of a wireless network
US10786732B2 (en) * 2015-06-15 2020-09-29 Square Enix Co., Ltd. Video game processing program and video game processing system
US9860157B2 (en) 2015-09-09 2018-01-02 Sling Media Pvt Ltd Zero configuration approach for port forwarding cascaded routers
TWI595765B (zh) 2015-10-22 2017-08-11 財團法人工業技術研究院 穿透網路位置轉換器之方法及通訊裝置
CN105577762B (zh) * 2015-11-09 2018-11-13 广州多益网络股份有限公司 一种本地离线推送的实现方法、装置及系统
US9901818B1 (en) * 2016-02-19 2018-02-27 Aftershock Services, Inc. Systems and methods for regulating access to game content of an online game
US10035068B1 (en) 2016-02-19 2018-07-31 Electronic Arts Inc. Systems and methods for making progress of a user character obtained in an online game via a non-virtual reality interface available in a virtual reality interface
US10576379B1 (en) 2016-02-19 2020-03-03 Electronic Arts Inc. Systems and methods for adjusting online game content and access for multiple platforms
US9919218B1 (en) * 2016-02-19 2018-03-20 Aftershock Services, Inc. Systems and methods for providing virtual reality content in an online game
US10134227B1 (en) 2016-02-19 2018-11-20 Electronic Arts Inc. Systems and methods for making game content from a single online game accessible to users via multiple platforms
US20170239563A1 (en) * 2016-02-23 2017-08-24 Sony Interactive Entertainment America Llc Game selection and invitation process
US9993735B2 (en) 2016-03-08 2018-06-12 Electronic Arts Inc. Multiplayer video game matchmaking optimization
US10729975B1 (en) 2016-03-30 2020-08-04 Electronic Arts Inc. Network connection selection processing system
AU2017274088A1 (en) * 2016-06-02 2019-01-24 BQ Media Lab Pty Ltd A system and method of providing a game
US10286327B2 (en) 2016-10-21 2019-05-14 Electronic Arts Inc. Multiplayer video game matchmaking system and methods
US10091281B1 (en) 2016-12-01 2018-10-02 Electronics Arts Inc. Multi-user application host-system selection system
US10771547B2 (en) * 2017-06-14 2020-09-08 Sony Interactive Entertainment LLC Online matchmaking for P2P topologies
US10610779B2 (en) * 2017-06-19 2020-04-07 Sony Interactive Entertainment LLC Methods and systems for scheduling game play of a video game
US10986169B2 (en) 2018-04-19 2021-04-20 Pinx, Inc. Systems, methods and media for a distributed social media network and system of record
KR102126828B1 (ko) * 2019-04-23 2020-06-25 권준 무선 인터컴 시스템

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080232362A1 (en) 2007-03-20 2008-09-25 Matsushita Electric Industrial Co., Ltd. Ip communication apparatus and ip communication method of such apparatus
US20080285554A1 (en) 2007-05-14 2008-11-20 Matsushita Electric Industrial Co., Ltd. Communication apparatus and data transmission method thereof
EP2071809A1 (en) * 2007-12-13 2009-06-17 Alcatel Lucent Method of establishing a connection in a peer-to-peer network with network address translation (NAT)
US7649491B2 (en) * 2005-03-09 2010-01-19 Omron Corporation Distance measuring apparatus, distance measuring method, reflector and communication system

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7227864B2 (en) 2001-12-17 2007-06-05 Microsoft Corporation Methods and systems for establishing communications through firewalls and network address translators
WO2004063843A2 (en) * 2003-01-15 2004-07-29 Matsushita Electric Industrial Co., Ltd. PEER-TO-PEER (P2P) CONNECTION DESPITE NETWORK ADDRESS TRANSLATOR (NATs) AT BOTH ENDS
DE10347617A1 (de) * 2003-10-09 2005-05-19 T-Mobile Deutschland Gmbh Steuerung der Rufzustellung und Rufumleitung von Telekommunikationsverbindungen, insbesondere bei Mehrgerätekonfigurationen
JP4339184B2 (ja) * 2004-06-07 2009-10-07 パナソニック株式会社 サーバ装置、通信機器、通信システム、通信方法、プログラム及び記録媒体
US7912046B2 (en) * 2005-02-11 2011-03-22 Microsoft Corporation Automated NAT traversal for peer-to-peer networks
JP4084365B2 (ja) 2005-03-08 2008-04-30 株式会社東芝 通信装置、通信方法および通信プログラム
WO2007062018A2 (en) * 2005-11-18 2007-05-31 Bertorello, Inc. Information synchronization
US7643491B2 (en) * 2005-12-16 2010-01-05 Microsoft Corporation Scheduling connections between peers in a peer-to-peer file sharing environment
TWI301025B (en) 2005-12-28 2008-09-11 Ind Tech Res Inst Method for transmitting real-time streaming data and apparatus using the same
KR100810759B1 (ko) * 2006-02-17 2008-03-07 엔에이치엔(주) Ｐ2ｐ 파일 전송 시스템 및 방법
US9137027B2 (en) * 2007-02-21 2015-09-15 Avaya Canada Corp. Bootstrapping in peer-to-peer networks with network address translators
US7933273B2 (en) * 2007-07-27 2011-04-26 Sony Computer Entertainment Inc. Cooperative NAT behavior discovery
US8266284B2 (en) * 2008-05-16 2012-09-11 Microsoft Corporation System from reputation shaping a peer-to-peer network
US7962627B2 (en) * 2008-12-04 2011-06-14 Microsoft Corporation Peer-to-peer network address translator (NAT) traversal techniques
TWI408936B (zh) * 2009-09-02 2013-09-11 Ind Tech Res Inst 網路穿透方法及網路通訊系統

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7649491B2 (en) * 2005-03-09 2010-01-19 Omron Corporation Distance measuring apparatus, distance measuring method, reflector and communication system
US20080232362A1 (en) 2007-03-20 2008-09-25 Matsushita Electric Industrial Co., Ltd. Ip communication apparatus and ip communication method of such apparatus
US20080285554A1 (en) 2007-05-14 2008-11-20 Matsushita Electric Industrial Co., Ltd. Communication apparatus and data transmission method thereof
EP2071809A1 (en) * 2007-12-13 2009-06-17 Alcatel Lucent Method of establishing a connection in a peer-to-peer network with network address translation (NAT)

Also Published As

Publication number Publication date
AU2010350742B2 (en) 2014-09-25
US8412833B2 (en) 2013-04-02
EP2556649A1 (en) 2013-02-13
WO2011126504A1 (en) 2011-10-13
JP2013524363A (ja) 2013-06-17
BR112012025350A2 (pt) 2016-06-28
US20110252079A1 (en) 2011-10-13
AU2010350742A1 (en) 2012-10-25
JP5628998B2 (ja) 2014-11-19
US9654551B2 (en) 2017-05-16
MX2012011618A (es) 2012-11-30
EP2556649B1 (en) 2016-01-06
US20130227019A1 (en) 2013-08-29
KR20130006496A (ko) 2013-01-16

Similar Documents

Publication Publication Date Title
KR101408560B1 (ko) 사용자를 온라인 세션에 초대하기 위한 장치 및 방법
KR101408490B1 (ko) 온라인 세션에 대해 사용자를 매치하기 위한 장치 및 방법
US9319467B2 (en) Apparatus and method for efficiently and securely exchanging connection data
CA2794032C (en) Apparatus and method for establishing and utilizing backup communication channels
US9130820B2 (en) Application programming interface, system, and method for collaborative online applications
KR101397834B1 (ko) 상이한 서비스 제공자들 사이의 피어-투-피어 접속들을 관리하기 위한 장치 및 방법

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20170522

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20180516

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20190515

Year of fee payment: 6