KR101397834B1 - 상이한 서비스 제공자들 사이의 피어-투-피어 접속들을 관리하기 위한 장치 및 방법 - Google Patents

상이한 서비스 제공자들 사이의 피어-투-피어 접속들을 관리하기 위한 장치 및 방법 Download PDF

Info

Publication number
KR101397834B1
KR101397834B1 KR1020120029039A KR20120029039A KR101397834B1 KR 101397834 B1 KR101397834 B1 KR 101397834B1 KR 1020120029039 A KR1020120029039 A KR 1020120029039A KR 20120029039 A KR20120029039 A KR 20120029039A KR 101397834 B1 KR101397834 B1 KR 101397834B1
Authority
KR
South Korea
Prior art keywords
service
user
data
mobile device
service provider
Prior art date
Application number
KR1020120029039A
Other languages
English (en)
Other versions
KR20120107880A (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 KR20120107880A publication Critical patent/KR20120107880A/ko
Application granted granted Critical
Publication of KR101397834B1 publication Critical patent/KR101397834B1/ko

Links

Images

Classifications

    • 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/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/335—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 Internet
    • 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/71—Game security or game management aspects using secure communication between game devices and game servers, e.g. by encrypting game data or authenticating players
    • 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
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • H04L45/7453—Address table lookup; Address filtering using hashing
    • H04L45/7459—Address table lookup; Address filtering using hashing using Bloom filters
    • 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
    • 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/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • 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/50—Network services
    • H04L67/55—Push-based network services
    • 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/20—Input arrangements for video game devices
    • A63F13/21—Input arrangements for video game devices characterised by their sensors, purposes or types
    • A63F13/216—Input arrangements for video game devices characterised by their sensors, purposes or types using geographical information, e.g. location of the game device or player using GPS
    • 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/407—Data transfer via internet
    • 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/53—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 details of basic data processing
    • A63F2300/532—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 details of basic data processing using secure communication, e.g. by encryption, authentication
    • 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
    • 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
    • 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/5573—Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history player location
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions

Abstract

블룸 필터를 이용하여 서비스 제공자들을 식별하기 위한 시스템 및 방법. 예를 들어, 본 발명의 일 실시예에서, 서비스 제공자들은 등록된 사용자의 사용자 ID 코드에 의해 블룸 필터들을 생성하고, 블룸 필터들을 상호간에 교환한다. 제1 사용자를 찾으라는 요청에 응답하여, 제1 서비스 제공자는 제1 사용자가 제1 서비스 제공자에 등록되어 있는지의 여부를 판정하기 위해 자신의 등록 데이터베이스를 쿼리할 것이다. 제1 사용자가 제1 서비스 제공자에 등록되어 있지 않은 경우, 제1 서비스 제공자는 제1 사용자가 등록될 수 있는 다른 서비스 제공자들을 식별하기 위해 블룸 필터들을 쿼리할 것이다. 블룸 필터로부터의 포지티브 응답은 제1 사용자가 블룸 필터와 연관된 서비스 제공자에 등록되어 있을 수도 있고, 또는 등록되어 있지 않을 수도 있다는 것을 나타내며, 네거티브 응답은 제1 사용자가 블룸 필터와 연관된 서비스 제공자에 등록되어 있지 않다는 것을 명확히 나타낸다. 제1 사용자를 찾으라는 요청은 포지티브 블룸 필터 응답이 수신된 서비스 제공자들에게만 전달된다.

Description

상이한 서비스 제공자들 사이의 피어-투-피어 접속들을 관리하기 위한 장치 및 방법{APPARATUS AND METHOD FOR MANAGING PEER-TO-PEER CONNECTIONS BETWEEN DIFFERENT SERVICE PROVIDERS}
이 출원은 "Apparatus and Method for Managing Peer-To-Peer Connections Between Different Service Providers"라는 표제가 붙은, 2011년 3월 21일에 출원된 미국 임시 출원 일련 번호 61/454,930의 우선권을 주장한다.
이 발명은 일반적으로 컴퓨터 네트워킹의 분야와 관련이 있다. 더 상세하게는, 이 발명은 모바일 디바이스들 사이의 피어-투-피어(P2P) 접속들을 관리하기 위한 개선된 장치 및 방법과 관련이 있다.
A. 네트워크 어드레스 변환( Network Address Translation )(" NAT ")
인터넷과 같은 큰 퍼블릭 네트워크(public network)는 법인, 인터넷 서비스 제공자, 또는 심지어 개별 가구들에 의해 유지되는 것들과 같은 보다 작은 프라이빗 네트워크(private network)들에 종종 접속한다. 매우 본질적으로, 퍼블릭 네트워크들은 일반적으로 합의된 네트워크 어드레스들, 즉, 퍼블릭 어드레스(public address)들의 할당을 가져야 한다. 여러 가지 이유로, 프라이빗 네트워크들의 유지자들은 종종 일반적으로 합의된 할당의 일부가 아닌 프라이빗 네트워크 어드레스들을 프라이빗 네트워크들을 위해 사용하기로 결정한다. 따라서, 프라이빗 네트워크로부터의 네트워크 트래픽이 퍼블릭 네트워크를 통과(traverse)할 수 있기 위해서는, 어떤 형태의 프라이빗/퍼블릭 네트워크 어드레스 변환("NAT")이 요구된다.
NAT 동작들을 수행하는 디바이스는 프라이빗 네트워크의 어드레싱 스킴(addressing scheme)에 따르도록 프라이빗 네트워크 밖으로 송신되는 데이터 패킷들을 변경한다. 특히, 네트워크 어드레스 변환기는 패킷의 발신하는(originating) 프라이빗 어드레스 및 포트 번호를 그 자신의 퍼블릭 어드레스 및 할당된 포트 번호로 대체한다. 네트워크 어드레스 변환기는 또한 수신처(destination) 퍼블릭 어드레스 및 포트 번호를 의도된 수신자의 정확한 프라이빗 어드레스 및 포트 번호로 대체하도록 프라이빗 네트워크 상의 컴퓨터들에 대하여 수신되고 있는 데이터 패킷들을 변경한다. 이 문서에서 사용된, 용어 어드레스는, 이 기술의 통상의 숙련자에 의해 이해되는 것과 같이, 컨텍스트에서 적절하다면 어드레스 및 포트 번호 둘 다를 포함하는 것으로 해석되어야 한다.
NAT는 현대의 네트워크 컴퓨팅에서 점점 일반화되었다. NAT의 하나의 이점은 그것이 퍼블릭 네트워크 어드레스 공간의 고갈을 보여준다는 것이다. 예를 들면, 인터넷에서 이용되는, TCP/IP 어드레싱은 각각 3개의 숫자의 4개의 스트링들을 포함하고, 따라서 한정된 어드레스 공간을 제공한다. 게다가, 이 어드레스 공간의 어떤 부분들은 특정한 사용들 또는 사용자들을 위해 예비되어, 이용 가능한 어드레스들의 실제 수를 더 고갈시킨다. 그러나, 만약 NAT가 이용된다면, 프라이빗 네트워크 또는 서브네트가 임의의 수의 어드레스들을 이용할 수 있고, 그럼에도 단 하나의 표준화된 퍼블릭 어드레스만을 외부 세계에 제공할 수 있다. 이것은 이용 가능한 어드레스들의 수를 무한하게 하는데, 그 이유는 각각의 프라이빗 네트워크가, 이론적으로는, 정확히 동일한 프라이빗 어드레스들을 사용할 수 있기 때문이다.
NAT에 의해 제공되는 하나의 이점은 퍼블릭 네트워크 상의 사람들이 프라이빗 네트워크 상의 컴퓨터의 실제(즉, 프라이빗) 네트워크 어드레스를 결정할 수 없다는 사실에서 비롯되는 증가된 보안이다. 이것은 네트워크 어드레스 변환기에 의해 프라이빗 네트워크 상에 퍼블릭 어드레스만이 제공되기 때문이다. 게다가, 이 퍼블릭 어드레스는 프라이빗 네트워크 상의 임의의 수의 컴퓨터들에 대응할 수 있다.
상이한 NAT 타입들은 상이한 보안 레벨들을 채용한다. 예를 들면, "풀 콘(full cone) NAT"에서는, 일단 내부 어드레스(iAddr:iPort)가 외부 어드레스(eAddr:ePort)에 매핑되면, 임의의 외부 호스트가 eAddr:ePort에 패킷들을 송신함으로써 iAddr:iPort에 패킷들을 송신할 수 있다. "제한된 콘(restricted cone) NAT"에서는, iAddr:iPort가 이전에 hAddr에 패킷을 송신한 경우에만 어드레스 hAddr을 갖는 외부 호스트가 eAddr:ePort에 패킷들을 송신함으로써 iAddr:iPort에 패킷들을 송신할 수 있다. 외부 호스트의 포트는 무관하다. "포트 제한된 콘(Port Restricted Cone) NAT"에서는, iAddr:iPort가 이전에 hAddr:hPort에 패킷을 송신한 경우에만 어드레스/포트 hAddr:hPort를 갖는 외부 호스트가 eAddr:ePort에 패킷들을 송신함으로써 iAddr:iPort에 패킷들을 송신할 수 있다. 마지막으로, 대칭(Symmetric) NAT에서는, 동일한 iAddr:iPort로부터 특정한 수신처 IP 어드레스로의 각각의 요청이 고유의 eAddr:ePort에 매핑된다. 만약 동일한 내부 호스트가 상이한 수신처에 패킷을 송신하면, 상이한 외부 어드레스 및 포트 매핑이 이용된다. 내부 호스트로부터 패킷을 수신하는 외부 호스트만이 내부 호스트에 다시 패킷을 송신할 수 있다.
B. 피어-투-피어 네트워킹에서의 NAT 문제들
피어-투-피어("P2P") 컴퓨팅은 그들의 리소스들의 일부를 다른 네트워크 참가자들에게 직접 이용 가능하게 하는 컴퓨팅 노드들로 이루어진 분산된 네트워크 아키텍처를 지시한다. 서버들이 리소스들을 공급하고 클라이언트들이 리소스들을 소비하는 전통적인 서버-클라이언트 모델과 대조적으로, P2P 네트워크 내의 피어들은 서로 직접 통신 채널들을 설정하고 클라이언트들 및 서버들 양쪽 모두로서 역할을 한다.
위에 설명된 NAT 동작들은 P2P 접속들에 대한 다수의 문제들을 제기한다. 예를 들면, 2개의 피어들 사이에 직접 접속을 설정하는 것은 만약 그 피어들 중 하나 또는 둘 다가 위에 설명된 NAT 타입들 중 하나 이상의 타입의 배후에 있다면 점점 어려워진다. 이 문제는 Apple iPod Touch®, Apple iPhone®, Apple iPad® 및 다양한 다른 디바이스들(예컨대, RIM Blackberry® 디바이스들, Palm Pre® 디바이스들, 등)과 같은 모바일 디바이스들이 상이한 NAT 구현들을 갖는 네트워크들 사이에 자주 움직인다는 사실에 의해 악화된다. 예를 들면, Apple iPhone TM은 Wi-Fi 네트워크들(예컨대, 802.11b,g,n 네트워크들); 3G 네트워크들(예컨대, UMTS(Universal Mobile Telecommunications System) 네트워크들, HSUPA(High-Speed Uplink Packet Access) 네트워크들, 등); 및 (PAN(personal area network)으로 알려진) 블루투스 네트워크들을 통하여 통신하는 것이 가능하다. 장래의 모바일 디바이스들이, 몇 가지 예를 들면, WiMAX, IMT(International Mobile Telecommunication) Advanced, 및 LTE(Long Term Evolution) Advanced와 같은 추가적인 통신 채널들을 통하여 통신하는 것이 가능할 것이다.
서비스 제공자들을 식별하기 위해 블룸 필터들(bloom filters)을 이용하기 위한 시스템 및 방법이 제공된다.
본 발명의 하나의 실시예에서, 서비스 제공자들은 등록된 사용자들의 사용자 ID 코드들을 갖는 블룸 필터들을 생성하고 그 블룸 필터들을 서로 교환한다. 제1 사용자를 찾기 위한(locate) 요청에 응답하여, 제1 서비스 제공자는 상기 제1 사용자가 상기 제1 서비스 제공자에 등록되어 있는지를 결정하기 위해 그 자신의 등록 데이터베이스에 쿼리(query)할 것이다. 만약 상기 제1 사용자가 상기 제1 서비스 제공자에 등록되어 있지 않다면, 상기 제1 서비스 제공자는 상기 제1 사용자가 등록되어 있을 수 있는 다른 서비스 제공자들을 식별하기 위해 그것의 블룸 필터들에 쿼리할 것이다. 블룸 필터로부터의 포지티브 응답(positive response)은 상기 제1 사용자가 그 블룸 필터와 연관된 서비스 제공자에 등록되어 있을 수 있거나 등록되어 있지 않을 수 있다는 것을 나타내고, 네거티브 응답(negative response)은 상기 제1 사용자가 그 블룸 필터와 연관된 서비스 제공자에 등록되어 있지 않다는 것을 확신을 가지고 나타낸다. 상기 제1 사용자를 찾기 위한 상기 요청은 포지티브 블룸 필터 응답이 수신된 서비스 제공자들에만 송신된다.
하기의 도면들과 관련하여 하기의 상세한 설명으로부터 본 발명의 더 나은 이해가 얻어질 수 있다.
도 1은 모바일 디바이스들의 그룹 및 서비스들이 네트워크를 통하여 통신하는 네트워크 아키텍처를 도시한다.
도 2a-c는 접속 데이터 교환(CDX) 서비스, 매치메이커(matchmaker) 서비스 및/또는 초대(invitation) 서비스의 하나의 실시예 사이의 트랜젝션들을 도시한다.
도 3은 티켓 데이터 구조의 하나의 실시예를 도시한다.
도 4는 CDX 서비스에 의해 구현되는 방법의 하나의 실시예를 도시한다.
도 5는 모바일 디바이스에 의해 구현되는 방법의 하나의 실시예를 도시한다.
도 6은 프라이머리 및 세컨더리 통신 채널들을 통하여 접속된 모바일 디바이스들의 그룹을 도시한다.
도 7은 프라이머리 및 세컨더리 통신 채널들 사이에 선택하기 위한 모바일 디바이스의 하나의 실시예를 도시한다.
도 8a-b는 프라이머리 및 세컨더리 통신 채널들을 통하여 접속된 모바일 디바이스들의 그룹 및 그 결과로서의 네트워크 토폴로지들을 도시한다.
도 9는 프라이머리 및 세컨더리 통신 채널들 사이에 선택하기 위한 컴퓨터 구현 방법의 하나의 실시예를 도시한다.
도 10은 모바일 디바이스들의 그룹, 및 디렉토리 서비스 및 푸시 통지(push notification) 서비스를 포함하는, 서비스들이 네트워크를 통하여 통신하는 네트워크 아키텍처를 도시한다.
도 11은 초대 서비스, 푸시 통지 서비스 및 접속 데이터 교환(CDX) 서비스의 하나의 실시예 사이의 트랜젝션들을 도시한다.
도 12는 초대 서비스, 푸시 통지 서비스, 및 릴레이(relay) 서비스의 하나의 실시예 사이의 트랜젝션들을 도시한다.
도 13은 2개 이상의 모바일 디바이스들 사이에 릴레이 접속을 설정하기 위한 릴레이 서비스의 하나의 실시예를 도시한다.
도 14는 NAT 호환성을 결정하기 위한 NAT 호환성 차트의 하나의 실시예를 도시한다.
도 15는 온라인 어플리케이션들을 위해 모바일 디바이스들을 매칭시키기 위한 매치메이커 서비스의 하나의 실시예를 도시한다.
도 16은 사용자들/디바이스들을 매칭시키기 위한 방법의 하나의 실시예를 도시한다.
도 17a-d는 사용자들/디바이스들을 매칭시키기 위해 수행되는 예시적인 일련의 표 업데이트들을 도시한다.
도 18은 상이한 매치 필터 변수들을 이용하여 사용자들/디바이스들을 매칭시키기 위한 방법을 도시한다.
도 19는 어플리케이션들을 위한 어플리케이션 프로그래밍 인터페이스(API) 및 서비스들의 세트와 통신하기 위한 서비스 API를 공개하는 프레임워크를 도시한다.
도 20은 어플리케이션들을 위한 API를 갖는 게임 프레임워크, 서비스들과 통신하기 위한 게임 데몬 및 게임 서비스 모듈의 하나의 실시예를 도시한다.
도 21은 소프트웨어 컴포넌트를 구현하는 API 및 소프트웨어 컴포넌트를 호출하는 API의 하나의 실시예를 도시한다.
도 22는 운영 체제들, 서비스들, 및 어플리케이션들 사이에 API 호출들이 행해지는 하나의 실시예를 도시한다.
도 23은 대표적인 컴퓨터 시스템 아키텍처의 하나의 실시예를 도시한다.
도 24는 대표적인 컴퓨터 시스템 아키텍처의 다른 실시예를 도시한다.
도 25는 복수의 상이한 서비스 제공자들을 통하여 접속된 복수의 사용자들을 도시한다.
도 26은 사용자들의 위치를 식별하기 위해 블룸 필터들을 채용하는 본 발명의 실시예를 도시한다.
도 27은 블룸 필터들을 이용하기 위한 방법의 하나의 실시예를 도시한다.
도 28은 블룸 필터들을 이용하기 위한 방법의 다른 실시예를 도시한다.
도 29는 본 발명의 하나의 실시예에 따른 포인트 투 포인트(P2P) 접속을 설정하는 2명의 사용자들을 도시한다.
도 30은 특정한 서비스 제공자에 의해 이용되는 릴레이 서비스를 통하여 P2P 접속을 설정하는 2명의 사용자들을 도시한다.
도 31은 릴레이 서비스를 통해 P2P 접속을 설정하기 위한 본 발명의 다른 실시예를 도시한다.
도 32는 본 발명의 하나의 실시예에서 이용되는 RFC 3984 헤더를 갖는 RTP 패킷을 도시한다.
도 33은 푸시 통지 서비스 및 안전한 인스턴트 메시징 서비스를 도시한다.
도 34는 안전한 인스턴트 메시징 세션을 설정하기 위한 방법의 하나의 실시예를 도시한다.
도 35는 안전한 인스턴트 메시징 세션을 설정하기 위한 방법의 다른 실시예를 도시한다.
도 36은 아이덴티티 서비스 및 어플리케이션 인증 서비스를 포함하는 시스템 아키텍처를 도시한다.
도 37은 사용자를 안전하게 인증하기 위한 방법의 하나의 실시예를 도시한다.
도 38은 캐싱 및 지문들을 이용하여 인증 효율을 개선하는 본 발명의 하나의 실시예를 도시한다.
네트워크 상에 프라이머리 및/또는 백업 피어-투-피어("P2P") 통신 채널들을 설정하고, 유지하고, 이용하기 위한 장치, 방법, 및 머신 판독 가능한 매체의 실시예들이 하기에 설명된다. P2P 세션들을 위해 각각 사용자들을 초대하고 사용자들을 매칭시키기 위한 초대 서비스 및 매치메이커 서비스가 또한 설명된다. 게다가, 사용자들이 어떤 지정된 조건에서 릴레이 접속들을 설정하는 것을 허용하는 릴레이 서비스가 설명된다. 마지막으로, 어플리케이션 개발자들이 이 문서에서 설명된 다양한 협력적인 온라인 특징들을 이용하는 어플리케이션들을 설계하는 것을 허용하는 어플리케이션 프레임워크 및 연관된 어플리케이션 프로그래밍 인터페이스(API)가 설명된다.
이 설명의 전체에 걸쳐서, 설명의 목적으로, 본 발명의 철저한 이해를 제공하기 위해 다수의 특정한 세부 사항들이 제시된다. 그러나, 이 기술분야의 숙련자에게 본 발명은 이러한 특정한 세부 사항들 없이 실시될 수 있다는 것이 명백할 것이다. 다른 사례들에서, 본 발명의 기초적인 원리들을 모호하게 하는 것을 피하기 위해 잘 알려진 구조들 및 디바이스들은 도시되지 않거나 블록도 형태로 도시된다.
접속 데이터를 효율적으로 안전하게 교환하기 위한 장치 및 방법
도 1에서 도시된 것과 같이, 본 발명의 하나의 실시예에서 구현된 일반적인 네트워크 토폴로지는 네트워크(120)를 통하여 서로 및 하나 이상의 서비스들(110-112)과 통신하는 "클라이언트" 또는 "피어" 이동 컴퓨팅 디바이스들 A-D(각각, 120-123)의 그룹을 포함할 수 있다. 비록 도 1에서는 단 하나의 네트워크 클라우드로서 도시되어 있지만, "네트워크"(120)는 몇 가지 예를 들면, 인터넷과 같은 퍼블릭 네트워크들 및 로컬 Wi-Fi 네트워크들(예컨대, 802.11n 홈 무선 네트워크 또는 무선 핫스팟), 로컬 에어리어 이더넷 네트워크, 셀룰러 데이터 네트워크(예컨대, 3G, Edge, 등), 및 WiMAX 네트워크와 같은 프라이빗 네트워크들을 포함하는 여러 가지 상이한 컴포넌트들을 포함할 수 있다. 예를 들면, 모바일 디바이스 A(120)는 네트워크 링크(125)로 나타내어진 홈 Wi-Fi 네트워크에 접속될 수 있고, 모바일 디바이스 B(121)는 네트워크 링크(126)로 나타내어진 3G 네트워크(예컨대, UMTS(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"들)을 포함할 수 있다. 하나의 실시예에서, 데이터베이스들은 모바일 디바이스들(120-123) 및 그 디바이스들의 사용자들에 관련된 데이터(예컨대, 사용자 계정 데이터, 디바이스 계정 데이터, 사용자 어플리케이션 데이터, ... 등)를 저장하고 관리한다.
하나의 실시예에서, 매치메이커 서버(111)는 지정된 조건들의 세트에 기초하여 협력적인 P2P 세션을 위해 2개 이상의 모바일 디바이스들을 매칭시킬 수 있다. 예를 들면, 모바일 디바이스들 중 2개 이상의 디바이스들의 사용자들은 특정한 멀티-플레이어 게임을 플레이하는 것에 관심이 있을 수 있다. 그러한 경우, 매치메이커 서비스(111)는 각각의 사용자의 전문적 기술 수준, 사용자들 각각의 나이, 매치 요청들의 타이밍, 매치가 요청되는 특정한 게임 및 다양한 게임 특유의 변수들에 기초하여 게임에 참가할 모바일 디바이스들의 그룹을 식별할 수 있다. 제한이 아닌 예로서, 매치메이커 서비스(111)는 특정한 게임을 플레이하는 데에 있어서 유사한 전문적 기술 수준들을 갖는 사용자들을 매칭시키려고 할 수 있다. 게다가, 어른들은 다른 어른들과 매칭될 수 있고 아이들은 다른 아이들과 매칭될 수 있다. 더욱이, 매치메이커 서비스(111)는 사용자 요청들이 수신되는 순서에 기초하여 그 요청들의 우선 순위를 매길 수 있다. 본 발명의 기초적인 원리들은 임의의 특정한 세트의 매칭 기준들 또는 임의의 특정한 타입의 P2P 어플리케이션에 제한되지 않는다.
하기에 상세히 설명된 것과 같이, 매치 요청에 응답하여, 매치메이커 서비스(111)는 CDX 서비스(110)와 협력하여, 모든 매핑된 참가자들이 효율적이고 안전한 방식으로 P2P 세션들을 설정하기 위한 필요한 접속 데이터를 수신하는 것을 보증할 수 있다.
하나의 실시예에서, 초대 서비스(112)는 또한 협력적인 P2P 세션들에 참가하기 위한 모바일 디바이스들을 식별한다. 그러나, 초대 서비스(112)의 경우에, 참가자들 중 적어도 하나가 다른 참가자에 의해 구체적으로 식별된다. 예를 들면, 모바일 디바이스 A(120)의 사용자는 모바일 디바이스 B(121)의 사용자와의 협력적인 세션을 구체적으로 요청할 수 있다(예컨대, 사용자 ID 또는 전화 번호로 모바일 디바이스 B를 식별한다). 매치메이커 서비스(111)와 마찬가지로, 초대 요청에 응답하여, 초대 서비스(112)는 참가자들의 세트를 식별하고 CDX 서비스(110)와 협력하여, 모든 참가자들이 효율적이고 안전한 방식으로 P2P 세션들을 설정하기 위한 필요한 접속 데이터를 수신하는 것을 보증할 수 있다.
위에 언급한 것과 같이, 하나의 실시예에서, CDX 서비스(110)는 2개 이상의 모바일 디바이스들 사이에 P2P 세션들을 설정하기 위해 필요한 접속 데이터에 대한 중앙 교환 포인트(central exchange point)로서 동작한다. 구체적으로, CDX 서비스의 하나의 실시예는 모바일 디바이스 요청들에 응답하여 (때때로 "홀 펀치"(Hole Punch) 데이터라고 불리는) NAT 통과 데이터(traversal data)를 생성하여 외부 서비스들 및 클라이언트들이 각각의 모바일 디바이스의 NAT를 통하여 통신하게(즉, NAT를 통하여 "구멍을 뚫어"(punch a hole) 그 디바이스에 도달하게) 할 수 있다. 예를 들면, 하나의 실시예에서, CDX 서비스는 모바일 디바이스와 통신하기 위해 필요한 외부 IP 어드레스 및 포트를 검출하고 이 정보를 모바일 디바이스에 제공한다. 하나의 실시예에서, CDX 서비스는 또한 매치메이커(111) 및 초대 서비스(112)에 의해 생성된 모바일 디바이스들의 리스트들을 수신하고 처리하여 그 리스트들에 포함된 모바일 디바이스들 각각에 효율적이고 안전하게 접속 데이터를 분배한다(하기에 상세히 설명된 것과 같이).
하나의 실시예에서, 모바일 디바이스들과 CDX 서비스(110) 사이의 통신은 UDP(User Datagram Protocol) 소켓들과 같은 비교적 경량의 네트워크 프로토콜을 이용하여 설정된다. 이 기술분야의 숙련자들이 아는 것과 같이, UDP 소켓 접속들은 패킷 신뢰도, 오더링(ordering), 또는 데이터 무결성(data integrity)을 보증하기 위해 대화들을 주고 받는 것(hand-shaking dialogues)을 요구하지 않고, 따라서 TCP 소켓 접속들만큼 많은 패킷 처리 오버헤드를 소비하지 않는다. 따라서, UDP의 경량의 무상태(stateless) 특징은 막대한 수의 클라이언트들로부터의 작은 쿼리들에 응답하는 서버들을 위해 유용하다. 더욱이, TCP와 다르게, UDP는 (패킷들이 로컬 네트워크 상의 모든 디바이스들에 송신되는) 패킷 브로드케스팅 및 (패킷들이 로컬 네트워크 상의 디바이스들의 서브세트에 송신되는) 멀티캐스팅과 호환가능하다. 하기에 설명된 것과 같이, 비록 UDP가 이용될 수 있을지라도, 세션 키들을 이용하여 NAT 통과 데이터를 암호화함으로써 CDX 서비스(110)에서 보안이 유지될 수 있다.
CDX 서비스(110)에 의해 이용되는 낮은 오버헤드, 경량의 네트워크 프로토콜과 현저히 다르게, 하나의 실시예에서, 모바일 디바이스들(120-130)와 매치메이커 서비스(111) 및/또는 초대 서비스(112) 사이의 통신은, SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 접속들에 의지하는, HTTPS(Hypertext Transfer Protocol Secure)와 같은 본질적으로 안전한 네트워크 프로토콜을 이용하여 설정된다. 이러한 프로토콜들에 대한 세부 사항들은 이 기술분야의 숙련자들이 잘 알고 있다.
도 2a는 CDX 서버에 의해 구현될 수 있는 예시적인 일련의 트랜젝션들을 도시한다. CDX 서비스의 하나의 실시예의 동작을 설명할 때, 하기의 용어들은 하기의 의미를 가질 것이다:
접속 데이터 - 이것은 잠재적인 피어들이 피어-투-피어 세션을 설정하기 위해 서로 교환할 필요가 있는 정보이다. 이 정보가 어떻게 교환될 수 있는지에 대한 메커니즘의 실시예들이 하기에 설명된다.
CDX 서버 - 하나의 실시예에서 CDX 서버는 공인된 엔티티들이 임의의 데이터를 교환하는 것을 허용하는 인증된 멀티캐스트 반사기( authenticated multicast reflector)이다. 이 데이터는 페이로드(Payload)로서 참조된다.
CDX 세션 - CDX 세션은 CDX 서버를 통해 서로 통신할 수 있는 클라이언트 디바이스들의 그룹을 지시한다. 세션의 일부인 각각의 클라이언트 디바이스는 CDX 티켓을 할당받는다. 각각의 세션은 고유의 CDX 세션 ID를 갖고, 이것은 개별 세션을 식별하거나 지시하기 위해 이용될 수 있는 큰 정수이다.
CDX 요청 - 클라이언트로부터 CDX 서버로 송신되는 요청. 요청은 일반적으로 2개의 부분: CDX 티켓 및 페이로드로 이루어진다. 이 실시예에서, 페이로드는 세션 키로 암호화된 접속 데이터이다.
CDX 응답 - CDX 서버가 CDX 세션의 멤버로부터 CDX 요청을 수신할 때 CDX 세션 내의 다른 디바이스들에 "반사되는" CDX 응답. 그것은 주어진 CDX 요청에서 이용되는 CDX 티켓의 CDX 티켓 스텁(CDX Ticket Stub)에 페이로드를 추가하는 것에 의해 구성된다.
CDX 티켓 - CDX 티켓은 CDX 세션의 멤버들에게 페이로드를 어떻게 송신하는지를 CDX 서버에 알린다. 하나의 실시예에서, 그것은 위조(forgery) 또는 부당 변경(tampering)을 막기 위해 CDX 티켓 키로 "서명된다". 도 3에서 도시된 것과 같이, 하나의 실시예에서, CDX 티켓은 하기의 정보를 포함한다:
하나의 실시예에서 암호화되거나 오퍼스케이트(obfuscate)되지 않는 세션 ID(301).
하나의 실시예에서 암호화되거나 오퍼스케이트되지 않는 세션 내의 참가자들의 수(302).
이 티켓이 지시하는 세션 내의 참가자의 인덱스(303)(하나의 실시예에서 암호화되거나 오퍼스케이트되지 않음).
그 후 티켓이 무효인 것으로 간주되는, 만료 시간/날짜(304)(하나의 실시예에서 암호화되거나 오퍼스케이트되지 않음).
하나의 실시예에서 CDX 티켓 키를 이용하여 암호화되는, 세션 내의 각각의 참가자에 대한 CDX 홀-펀치 데이터(305-306).
티켓이 진짜인 것을 보증하는 "디지털 서명"으로서 역할을 하는, CDX 티켓 키를 이용한 메시지 인증 코드(307).
CDX 티켓 스텁 - CDX 홀-펀치 데이터 및 메시지 인증 코드를 뺀, CDX 티켓의 제1 부분.
페이로드 - 이것은 CDX 요청의 제2 부분 및 CDX 응답이다. 페이로드는 클라이언트 디바이스가 CDX 세션 내의 다른 디바이스들에 전달하기를 원하는 데이터이다. 이 실시예에서, 페이로드는 세션 키로 암호화된 접속 데이터이다. CDX 서버는, 하나의 실시예서, 페이로드를 암호 해독하지 않고, 그것은 단순히 그것을 변하지 않은 채로 전달한다.
세션 키 - 이것은 접속 데이터를 암호화하기 위해 클라이언트들에 의해 이용되는 키이다. 하나의 실시예에서, 이 키는 CDX 서버에게 알려져 있지 않다. 이 실시예에서, 세션 키는 매치메이킹 서비스에 의해 생성되고 그것들의 개별 CDX 티켓들과 함께 클라이언트들에 송신된다.
CDX 티켓 키 - 이것은 CDX 티켓들을 생성하고 그것에 "서명"하기 위해 이용되는 키이다. CDX 티켓 키는 CDX 서버 및 CDX 티켓들을 생성하는 서비스(그것은, 하기에 설명된 것과 같이, 매치메이킹 서비스 및/또는 초대 서비스일 수 있다)만 알고 있다.
CDX 홀-펀치 요청 - CDX 서버로부터 CDX 홀-펀치 데이터를 획득하기 위해 이용되는 CDX 요청의 특별한 타입.
CDX 홀-펀치 데이터 - 이것은 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 접속을 설정하기 위해 필요한 접속 데이터를 구성하기 시작할 수 있다. 이것은, 예를 들면, 표준 ICE(Internet Connectivity Establishment) 트랜젝션을 이용하여(예컨대, NAT 통과 서비스에 의해) 달성될 수 있다. 그러나, 본 발명의 기초적인 원리들은 접속 데이터를 결정하기 위한 임의의 특정한 메커니즘에 제한되지 않는다.
하나의 실시예에서, 일단 매치메이킹 서비스(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 티켓이 무효라면, 요청은 드롭된다(dropped). 하나의 실시예에서, CDX 서버는 그 후 CDX 티켓 키를 이용하여 CDX 티켓에 포함된 CDX 홀-펀치 데이터를 암호 해독한다. 하나의 실시예에서, CDX 티켓 키는 티켓과 함께 또한 송신될 수 있는 만료 시간/날짜를 포함할 수 있다. CDX 서비스(110) 및 매치메이커 서비스(111)는 암호화/암호 해독을 위한 2개의(또는 그 이상의) CDX 티켓 키들을 저장할 수 있다(일반적으로 활성인 제1 CDX 티켓 키 및 제1 CDX 티켓 키의 만료 시간/날짜에 도달하면 활성이 될 제2 CDX 티켓 키). 티켓을 수신하면, CDX 서비스(110)는 만료 시간/날짜를 판독하여 어느 티켓 키를 사용할지를 결정할 수 있다. CDX 티켓 키가 만료되면, CDX 서비스(110) 및 매치메이커 서비스(111) 양쪽 모두는 각각 새로운 티켓 키를 생성할 수 있다(그것은 현재의 티켓 키가 만료된 후에 사용될 다음 키일 것이다). 하나의 실시예에서, CDX 서비스(110) 및 매치메이커 서비스(111)는 동일한 키 생성 알고리즘을 실행하여 2개의 티켓 키들과의 일관성을 보증한다. 예를 들면, 새로운 인증 코드가 일정한 간격으로 생성되는 잘 알려진 RSA SecurID 인증 메커니즘을 위해 이용되는 것들과 같은 기법들이 이용될 수 있다. 하나의 실시예에서, 새로운 CDX 티켓 키는 날마다 생성된다. 그러나, 본 발명의 기초적인 원리들은 CDX 티켓 키들을 생성하기 위한 임의의 특정한 메커니즘에 제한되지 않는다.
모바일 디바이스 B에 대하여 206b에서 도시된 것과 같이 동일한 동작들이 수행될 수 있다. CDX 서버는 CDX 요청으로부터 CDX 응답을 구성하고 그 후 CDX 홀-펀치 데이터를 이용하여 CDX 세션 내의 참가자들에게 CDX 응답을 송신한다(207a에서 모바일 디바이스 B에 및 207b에서 모바일 디바이스 A에 송신한다).
모바일 디바이스 B는 CDX 서버로부터 CDX 응답을 수신한다(207a). 클라이언트 디바이스 B는 CDX 티켓 스텁을 검사하여 세션 ID가 그 자신의 CDX 티켓의 세션 ID와 매칭하는 것을 보증한다. 모바일 디바이스 B는 그 후 세션 키를 이용하여 페이로드를 암호 해독하여, 모바일 디바이스 A로부터의 접속 데이터를 생성한다. 모바일 디바이스 B는 그 후 모바일 디바이스 A로부터의 접속 데이터를 이용하여 P2P 세션을 설정하는 프로세스를 시작한다. 하나의 실시예에서, 이것들을 표준 ICE 트랜젝션들을 수반한다. 그러나, 본 발명의 기초적인 원리들은 P2P 통신을 설정하기 위한 임의의 특정한 메커니즘에 제한되지 않는다.
위에 언급한 것과 같이, 하나의 실시예에서, 모바일 디바이스 A 및 B는 매치메이커 서비스(111)와 통신하기 위해 HTTPS(Hypertext Transfer Protocol Secure) 세션들을 설정하고(예컨대, HTTPS 요청/응답 트랜젝션들을 이용하여) CDX 서비스와 통신하기 위해 UDP 소켓들을 설정한다. 매치 요청들(204a, 204b)은 각각의 모바일 디바이스에 대하여 이전에 결정된 NAT 타입 및 홀 펀치 데이터(예컨대, 퍼블릭 IP 어드레스 및 포트)를 포함할 수 있다. 멀티-플레이어 게임을 수반하는 실시예에서, 각각의 매치 요청은 각각의 모바일 디바이스 상의 플레이어(예컨대, 고유의 플레이어 ID 코드를 이용하여), 각각의 사용자가 플레이하기를 원하는 게임, 게임에 참가할 플레이어들의 수, 및/또는 소망의 게임과 연관된 다른 게임 구성 변수들을 식별할 수 있다. 제한이 아닌 예로서, 게임과 연관된 게임 구성 변수들은 난이도(예컨대, 쉬운, 보통, 어려운), 사용자의 나이(예컨대, "13세 미만"), 게임의 서브-영역(예컨대, "레벨 2"), 및/또는 플레이어 전문적 기술 수준(예컨대, 전문가, 초보자, 중간)을 포함할 수 있다. 하기에 상세히 설명된 것과 같이, 이 변수들은 때때로 게임 "버킷"(bucket)이라고 불리고 고유의 "버킷 ID"를 이용하여 식별된다. 각각의 게임은 상이한 게임 구성 변수들을 식별하기 위해 상이한 버킷 ID들의 세트들을 포함할 수 있다.
하나의 실시예에서, 모바일 디바이스 B는 208a 및 209a에서 ACK(acknowledgement)를 송신한다. 유사하게, 모바일 디바이스 A의 ACK가 208b 및 209b에서 송신된다. 만약 모바일 디바이스 A의 또는 B의 ACK들이 지정된 시간 기간 후에 수신되지 않으면, 접속 데이터(207a)는 모바일 디바이스 B(212)에 재송신될 수 있다. CDX 서비스(110)가 재시도를 개시할 수 있고 및/또는 모바일 디바이스 A(120)가 재시도를 개시할 수 있다.
도 2b는 3개의 상이한 모바일 디바이스들(120-122)이 CDX 서비스 및 매치메이커 서비스(111)를 이용하여 P2P 접속들에 대하여 교섭하는 더 상세한 예를 도시한다. 도 2b는 또한 접속을 설정하기 위해 모바일 디바이스들(120-122)에 의해 이용되는 2개의 추가적인 서비스들을 도시한다: NAT 타입을 결정하기 위한 NAT 통과 서비스(291) 및 (예컨대, ICE 접속 데이터 트랜젝션을 이용하여) 각각의 모바일 디바이스에 대한 풀 접속 데이터를 결정하기 위한 NAT 서비스(290). 그러나, 본 발명의 기초적인 원리들에 따르기 위해 개별 서비스들이 요구되지는 않는다는 것에 주목해야 한다. 예를 들면, 대안적인 실시예에서, 이 서비스들(290-291) 각각에 의해 수행되는 NAT 통과 기능들은 CDX 서비스(110) 및/또는 매치메이커 서비스(111) 내에 직접 통합될 수 있다. 유사하게, 양쪽 NAT 통과 서비스들(290-291)에 의해 수행되는 기능들은 단 하나의 NAT 통과 서비스 내에 통합될 수 있다. 요약하면, 본 발명의 기초적인 원리들에 따르기 위해 도 2b에서 도시된 특정한 기능 분리가 요구되지는 않는다.
이제 도 2b의 특정한 세부 사항들을 보면, 220에서, 모바일 디바이스 A는 NAT 통과 서비스(291)에 NAT 타입 요청을 송신한다. 응답으로, NAT 통과 서비스(291)는 일련의 트랜젝션들을 구현하는 것을 포함하는 다양한 알려진 기법들을 이용하여 모바일 디바이스 A에 의해 이용되는 NAT 타입을 결정할 수 있다. 예를 들면, NAT 통과 서비스(291)는 모바일 디바이스 A의 NAT 상의 상이한 IP 어드레스들 및 포트들을 열고 상이한 IP/포트 조합들을 이용하여 그 포트들을 통하여 모바일 A와 통신하려고 할 수 있다. 이런 식으로, 모바일 디바이스 A에 의해 채용된 NAT는 위에 설명한 NAT 타입들(예컨대, 풀 콘, 제한된 콘, 포트 제한된 콘, 대칭) 중 하나 또는 대안적인 NAT 타입으로서 분류될 수 있다. 이 정보는 그 후 도시된 것과 같이 모바일 디바이스 A(120)에 제공될 수 있다.
221에서, 모바일 디바이스 A(120)는 CDX 서비스(110)를 이용하여 NAT 통과 요청을 개시한다. 응답으로, CDX 서비스(110)는 그 요청을 위해 이용되는 퍼블릭 IP 어드레스 및 퍼블릭 포트 번호를 판독할 수 있고 이 정보를 다시 모바일 디바이스 A(120)에 송신한다. 위에 설명한 것과 같이, 만약 디바이스가 NAT의 배후에 있다면, 그것의 퍼블릭 포트 및 IP 어드레스는 각각 그것의 프라이빗 포트 및 IP 어드레스와 다를 것이다. 따라서, 이용되고 있는 NAT의 타입에 따라서, 퍼블릭 IP 어드레스 및 포트는 모바일 디바이스에 도달하기 위해 NAT를 통하여 "구멍을 뚫기" 위해 이용될 수 있다.
222에서, 모바일 디바이스 A(120)는 매치메이커 서비스(111)에 매치 요청(222)을 송신한다. 위에 설명한 것과 같이, 하나의 실시예에서, 모바일 디바이스 A는 HTTPS(Hypertext Transfer Protocol Secure) 세션들을 이용하여 매치메이커 서비스(111)에 통신한다(예컨대, HTTPS 요청/응답 트랜젝션들을 이용하여). 매치 요청은 모바일 디바이스 A(120)에 대하여 이전에 결정된 NAT 타입 및 홀 펀치 데이터(예컨대, 퍼블릭 IP 어드레스 및 포트)를 포함할 수 있다. 멀티-플레이어 게임을 수반하는 실시예에서, 매치 요청은 모바일 디바이스 A 상의 플레이어(예컨대, 고유의 플레이어 ID 코드를 이용하여), 그 사용자가 플레이하기를 원하는 게임, 게임에 참가할 플레이어들의 수, 및/또는 소망의 게임과 연관된 다른 게임 구성 변수들을 식별할 수 있다(도 2a에 관하여 이전에 설명한 것과 같이).
223-225에서 모바일 디바이스 B(121)에 대하여 트랜젝션들(220-222)에 대응하는 트랜젝션들의 세트가 수행되고 226-228에서 모바일 디바이스 C(122)에 대하여 트랜젝션들(220-222)에 대응하는 트랜젝션들의 세트가 수행된다. 따라서, 트랜젝션(228) 후에, 매치메이커 서비스(111)는 모든 3개의 모바일 디바이스들(120-122)에 대하여 매치 요청들을 수신하였다. 이 특정한 예에서, 매치 요청들은 모바일 디바이스들(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에서, 트랜젝션들(232-234)에 대응하는 트랜젝션들의 세트가 티켓 B를 이용하여 수행되고 238-240에서 트랜젝션들(232-234)에 대응하는 트랜젝션들의 세트가 티켓 C를 이용하여 수행된다. 따라서, 트랜젝션(240) 후에, 모바일 디바이스들(120-122) 각각의 사이에 접속 데이터가 공유되었다. 접속 데이터를 이용하여, 모바일 디바이스들 A 및 B, 모바일 디바이스들 A 및 C, 및 모바일 디바이스들 B 및 C 사이에 P2P 세션들이 설정된다.
도 2c에서 도시된 것과 같이, CDX 서비스(110)와 함께 초대 서비스(112)가 또한 이용될 수 있다(매치메이커 서비스(111) 대신에 또는 그것에 더하여). 하나의 실시예에서, 초대 서비스(112)는 특정한 모바일 디바이스들 및/또는 사용자들과의 P2P 접속들에 대한 초대 요청들을 처리한다. 초대 서비스(112)는 무상태 서비스(즉, 무선 디바이스들 각각의 사이에 트랜젝션들의 현재의 상태를 결합(tack)하지 않는 서비스)로서 구현될 수 있다.
이 특정한 예를 보면, 250에서, 모바일 디바이스 A(120)는 NAT 통과 서비스(291)에 NAT 타입 요청을 송신한다. 응답으로, NAT 통과 서비스(291)는 모바일 디바이스 A에 의해 이용되는 NAT 타입을 결정하기 위해 다양한 알려진 기법들을 이용할 수 있다(그 중 일부가 위에 설명되어 있다). 251에서, 모바일 디바이스 A(120)는 CDX 서비스(110)를 이용하여 NAT 통과 요청을 개시한다. 응답으로, CDX 서비스(110)는 그 요청을 위해 이용되는 퍼블릭 IP 어드레스 및 퍼블릭 포트 번호를 판독할 수 있고 이 정보를 다시 모바일 디바이스 A(120)에 송신한다. 위에 설명한 것과 같이, 만약 디바이스가 NAT의 배후에 있다면, 그것의 퍼블릭 포트 및 IP 어드레스는 각각 그것의 프라이빗 포트 및 IP 어드레스와 다를 것이다. 따라서, 이용되고 있는 NAT의 타입에 따라서, 퍼블릭 IP 어드레스 및 포트는 모바일 디바이스에 도달하기 위해 NAT를 통하여 "구멍을 뚫기" 위해 이용될 수 있다.
매치메이커 서비스와 마찬가지로, 하나의 실시예에서, 모바일 디바이스들 각각은 HTTPS(Hypertext Transfer Protocol Secure) 세션들을 이용하여 초대 서비스(112)와 통신한다((예컨대, HTTPS 요청/응답 트랜젝션들을 이용하여).
252에서, 모바일 디바이스 A(120)는 모바일 디바이스 A의 NAT 통과 데이터(예컨대, NAT 타입, 퍼블릭 IP 어드레스/포트)를 포함하는 초대 요청을 초대 서비스(112)에 송신한다. (하기에 더 상세히 설명된) 푸시 통지 서비스를 이용하는 실시예에서, 초대 요청은 또한 모바일 디바이스 A의 푸시 토큰을 포함할 수 있다. 초대 요청(252)은 또한 하나 이상의 다른 사용자들/디바이스들(이 경우 모바일 디바이스들 B(121) 및 C(122)의 사용자들)을 식별하는 식별 코드를 포함할 수 있다. 다양한 상이한 식별 코드 타입들이 이용될 수 있다. 예를 들면, 멀티-플레이어 게임의 경우에, 식별 코드들은 게임 특유의 플레이어 ID 코드들을 포함할 수 있다. 오디오/비디오 채팅 세션의 경우에, 식별 코드들은 모바일 디바이스 A의 사용자의 "버디" 리스트로부터 하나 이상의 사용자들을 식별하는 전화 번호들 또는 고유의 ID 코드들을 포함할 수 있다.
하나의 실시예에서, 초대 서비스(112)는 초대 요청으로부터 식별 코드들을 판독하고 등록 데이터베이스(미도시)에서 룩업(lookup)을 수행하여 모바일 디바이스들 B 및 C 각각을 찾는다. 하나의 특정한 실시예에서, 모바일 디바이스들 B 및 C 각각은 초대 서비스(112)로부터 푸시 통지들을 수신하기 위해 이전에 푸시 서비스에 등록하였다. 따라서, 이 실시예에서, 초대 서비스(112)는 푸시 통지 서비스를 이용하여 253 및 254에서 각각 모바일 디바이스 B(121) 및 모바일 디바이스 C(122)에 초대 요청들을 푸시한다. 푸시 통지 서비스에 관련된 추가적인 세부 사항들은 하기에서(예컨대, 도 11-12 및 연관된 텍스트를 참조) 및 위에 언급된 푸시 통지 어플리케이션에서 설명된다.
하나의 실시예에서, 초대 요청들(253 및 254)은 도 3에 도시되고 도 2a-b에 관하여 위에 설명된 티켓 데이터 구조를 포함한다. 구체적으로, 모바일 디바이스 B에 송신된 티켓은 모바일 디바이스들 A 및 B를 식별하는 암호화된 리스트를 포함하고 모바일 디바이스 C에 송신된 티켓은 모바일 디바이스들 A 및 C를 식별하는 암호화된 리스트를 포함한다. 하나의 실시예에서, 초대 서비스(112)는 아직 모바일 디바이스 B의 NAT 통과 데이터를 갖고 있지 않을 수 있기 때문에, 253에서 "티켓"은 모바일 디바이스 B를 식별하는 다른 정보를 포함할 수 있다. 예를 들면, 릴레이 서비스 및 푸시 통지 서비스를 이용하는 실시예들에 관하여 하기에 설명된 것과 같이(예컨대, 도 11-12를 참조), 253에서 "티켓"은 모바일 디바이스 A에 대한 NAT 통과 데이터, 디바이스 A의 ID 코드, 디바이스 A의 푸시 토큰, 디바이스 B의 ID 코드, 및 모바일 디바이스 B에 대한 푸시 토큰을 포함할 수 있다. 동일한 타입의 정보가 254에서 모바일 디바이스들 A 및 C에 대하여 제공될 수 있다.
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 접속을 설정하기 위해 일련의 트랜젝션들을 실행할 수 있다. 구체적으로, 264에서, 모바일 디바이스 C(122)는 NAT 통과 서비스(291)와 통신하여 그것의 NAT 타입을 결정하고, 265에서, CDX 서비스(110)와 통신하여 그것의 NAT 통과 데이터(예컨대, 퍼블릭 IP 어드레스/포트)를 결정한다. 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 통과 데이터 및 푸시 토큰들(만약 푸시 서비스가 이용된다면)을 포함하는 모바일 디바이스 C의 초대 응답을 초대 서비스(112)로부터 수신한다. 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 또는 전화 번호를 푸시 토큰과 연관시킨다. 만약 푸시 토큰이 디렉토리에서 식별될 수 있다면, 푸시 통지 서비스는 그 푸시 토큰을 이용하여 모바일 디바이스에 푸시 통지들을 송신할 수 있다. 하나의 실시예에서, 푸시 통지 서비스는 본 출원의 양수인에 의해 설계되고, 예를 들면, 위에 언급된 푸시 통지 어플리케이션에서 설명된 APNS(Apple Push Notification Service)이다. 그러나, 도 2a-c에서 도시된 발명의 실시예들에 의해 푸시 통지 서비스가 요구되지 않는다는 것에 주목해야 한다. 예를 들면, CDX 서비스(110)가 이 문서에서 설명된 것과 같이 그것의 동작들을 수행하기 위해 푸시 통지들이 요구되지 않는다.
도 4는 접속 데이터를 교환하기 위해 CDX 서비스(110)에 의해 구현될 수 있는 방법을 도시하고 도 5는 접속 데이터를 교환하고 P2P 접속을 설정하기 위해 모바일 디바이스에 의해 구현될 수 있는 방법을 도시한다. 이 방법들의 어떤 양태들은 도 1-2c에 관하여 위에서 이미 설명되었다. 특히, 이 방법들은 도 1-2c에서 도시된 네트워크 아키텍처의 컨텍스트 내에서 구현될 수 있지만 그것들은 그러한 아키텍처에 제한되지 않는다. 하나의 실시예에서, 그 방법들은, 프로세서에 의해 실행될 때, 그 방법들의 동작들이 수행되게 하는 프로그램 코드로 구현된다. 프로그램 코드는 프로세서에 의해 실행되는 동안 RAM(random access memory)과 같은 머신 판독 가능한 매체에 저장될 수 있다. 프로세서는 범용 프로세서(예컨대, Intel® CoreTM 프로세서) 또는 특수 목적 프로세서일 수 있다. 그러나, 그 방법들은 하드웨어, 소프트웨어, 및 펌웨어의 임의의 조합을 이용하여 구현될 수 있다. 게다가, 프로그램 코드는 하드 디스크 드라이브, 광 디스크(예컨대, DVD 또는 CD)와 같은 비휘발성 저장 디바이스 또는 플래시 메모리 디바이스와 같은 비휘발성 메모리에 저장될 수 있다.
이제 도 4에서 도시된 방법을 보면, 401에서, 특정한 모바일 디바이스(이 예에서 "모바일 디바이스 A")에 대하여 NAT 통과 요청(때때로 "홀 펀치" 요청이라고도 불림)이 수신된다. 402에서, NAT 통과 응답이 생성되어 모바일 디바이스 A에 송신된다. 하나의 실시예에서, NAT 통과 응답을 생성하는 것은 모바일 디바이스 A의 현재의 퍼블릭 IP 어드레스/포트 및/또는 NAT 타입을 결정하는 것을 포함할 수 있다.
그 후 위에 설명한 매치메이커 서비스(111) 또는 초대 서비스(112)와 같은 티켓-생성 엔티티에 의해 모바일 디바이스 A에 대한 티켓이 생성되어 암호화될 수 있다. 403에서, (디바이스 A 및 하나 이상의 다른 디바이스들에 대한) NAT 통과 데이터 및 디바이스 A에 대한 접속 데이터를 포함하는 모바일 디바이스 A에 대하여 생성된 티켓("티켓 A")이 수신된다. 404에서, 메시지 인증 코드를 이용하여 티켓이 인증되고 티켓을 암호화하기 위해 티켓-생성 엔티티에 의해 이용된 것과 동일한 CDX 티켓 키를 이용하여 홀 펀치 데이터가 암호화된다. 위에 언급한 것과 같이, 하나의 실시예에서, 정확한 CDX 티켓 키는 CDX 티켓 키와 연관된 만료 시간/날짜를 이용하여 식별된다.
405에서, 모바일 디바이스에 대한 NAT 통과 데이터가 추출된다. 406에서, NAT 통과 데이터를 이용하여 모바일 디바이스 A에 대한 접속 데이터가 피어들 각각에 송신된다. 407에서 피어들 각각으로부터 수신확인들(acknowledgements)이 수신된다. 만약 모든 피어들로부터 수신확인들이 수신되지 않았다고 408에서 결정되면, 409에서 응답하지 않은 피어들에게 모바일 디바이스 A의 접속 데이터가 재송신된다. 모든 접속 데이터가 수신확인되었다고 408에서 결정되면, 방법은 종료한다.
하나의 실시예에서, 도 4에서 도시된 방법은 P2P 접속을 설정하기 위해 요구되는 접속 데이터를 각각의 피어가 수신하는 것을 보증하기 위해 P2P 트랜젝션에 수반된 피어들 각각에 대하여 수행될 수 있다.
도 5는 이 문서에서 설명된 방법의 실시예들에 따른 모바일 디바이스에 의해 수행될 수 있는 방법을 도시한다. 501에서, NAT 통과 요청이 송신되고, 502에서, NAT 통과 응답이 수신된다. 이전에 설명한 것과 같이, 응답에 포함된 NAT 통과 데이터는 요청하는 디바이스의 퍼블릭 포트/IP 어드레스를 포함할 수 있다. 503에서, NAT 통과 데이터를 포함하는 매치 요청이 송신된다. 그 후 위에 설명한 매치메이커 서비스(111) 또는 초대 서비스(112)와 같은 티켓-생성 엔티티에 의해 모바일 디바이스에 대한 티켓이 생성되고 암호화될 수 있다. 위에 설명한 티켓 데이터 구조의 대안으로서, 매치메이커 서비스(111) 및/또는 초대 서비스(112)는 단순히 고유의 세션 ID를 이용하여 참가자들 각각을 식별할 수 있다.
504에서, 티켓이 수신될 수 있고; 505에서, 모바일 디바이스에 대한 접속 데이터가 티켓에 추가되고; 506에서, 접속 데이터를 갖는 티켓이 송신된다. 507에서, 하나 이상의 피어들과의 P2P 접속을 설정하기 위해 필요한 접속 데이터가 수신된다. 508에서, 하나 이상의 다른 무선 디바이스들이 506에서 송신된 접속 데이터를 수신했다는 것을 나타내는 수신확인들이 수신된다. 만약 모든 수신확인들이 수신되지 않는다면, 510에서, 수신확인들이 수신되지 않은 모바일 디바이스들에 접속 데이터가 재송신된다. 만약 모든 수신확인들이 수신되었다고 509에서 결정되면, 507에서 수신된 접속 데이터는 다른 모바일 디바이스들과의 P2P 세션을 설정하기 위해 이용된다.
백업 통신 채널들을 설정하고 이용하기 위한 장치 및 방법
현재 모바일 디바이스들은 다양한 상이한 채널을 통해 통신할 수 있습니다. 예를 들어, Apple iPhoneTM은 Wi-Fi네트워크들(예를 들어, 802.11b,g,n 네트워크들), 3G 네트워크들(예를 들어, UMTS(Universal Mobile Telecommunications System) 네트워크들, HSUPA(Hihg-Speed Uplink Packet Access) 네트워크들 등) 및 (PAN(personal area network)들로 알려져 있는) 블루투스(bluetooth) 네트워크들을 통해 통신하는 것이 가능하다. 미래의 모바일 디바이스들은, 몇 가지 예를 들자면, WiMAX, IMT(International Mobile Telecommunication) Advanced, LTE(Long Term Evolution) Advanced 등의 추가적인 통신 채널을 통해 통신하는 것이 가능할 것이다.
동작시, 현재 모바일 디바이스들은 한 세트의 가용 채널들 중에서 하나의 프라이머리 통신 채널을 선택한다. 예를 들어, 모바일 디바이스들은 종종, 하나가 이용가능한 경우에는 Wi-Fi 접속을 선택하고 Wi-Fi가 이용가능하지 못한 경우에는 셀룰러 데이터 접속(예를 들어, UTMS 접속)을 선택하도록 구성될 수 있다.
본 발명의 일 실시예에서, 한 그룹의 모바일 디바이스들은 먼저 전술한 표준 ICE 접속 데이터 교환들을 이용하고/이용하거나 접속 데이터 교환 기술들을 이용하여, 프라이머리 P2P(peer-to-peer) 통신 채널들을 구축한다. 그런 다음, 모바일 디바이스들은 프라이머리 채널들을 통해 접속 데이터를 교환하여, 프라이머리 채널들이 모두 실패할 경우에 백업 채널들로서 사용되는 하나 이상의 세컨더리 통신 채널들을 구축할 수 있다. 일 실시예에서, 세컨더리 통신 채널들은, 이 채널들을 통해 "하트비트(heartbeat)" 패킷들을 주기적으로 송신함으로써 NAT 방화벽들을 통해 개방상태로 유지된다.
여기서 사용되는 바와 같이, 통신 "채널"은 2개의 모바일 디바이스들 간의 전체 네트워크 경로를 지칭하며, 통신 "링크"는 통신 경로에 사용되는 하나의 특정 접속을 지칭한다. 예를 들어, 디바이스 A가 Wi-Fi를 이용하여 인터넷에 접속되어 있고, 디바이스 B가 3G 접속을 이용하여 인터넷에 접속되어 있는 경우, 디바이스 A와 디바이스 B 사이의 "채널"은 Wi-Fi 링크와 3G 링크 양자 모두에 의해 정의되며, 디바이스 A는 Wi-Fi 통신 "링크"를 가지며, 디바이스 B는 3G 통신 "링크"를 갖는다. 이 경우, 만약 디바이스 A가 Wi-Fi 링크로부터 3G 링크로 전환하면, 디바이스 A와 디바이스 B 사이의 "채널"은 디바이스 B의 3G 링크가 동일하게 유지된다는 사실에도 불구하고 변경된다.
이제, 모바일 디바이스들이 프라이머리 및 세컨더리 통신 채널을 구축하는 특정 예들이 도 6에 관하여 기술될 것이다. 그러나, 본 발명의 기본 원리들은 도 6에 도시된 특정 세트의 통신 링크들 및 통신 채널들에 한정되는 것은 아니라는 점에 유의해야 한다.
도 6에서, 모바일 디바이스 A(601)는 NAT 디바이스(611)와의 통신 링크(605)를 통해, 그리고 NAT 디바이스(612)와의 통신 링크(606)와의 통신을 통해 네트워크(610)(예를 들어, 인터넷)에 접속할 수 있다. 유사하게, 디바이스 C(603)는 NAT 디바이스(613)와의 통신 링크(609)를 통해, 그리고 NAT 디바이스(613)와의 통신 링크(610)를 통해 네트워크(610)에 접속할 수 있다. 한정이 아닌 예를 들면, 통신 링크들(605, 609)은 3G 통신 링크들일 수 있고 통신 링크들(606, 610)은 Wi-Fi 통신 링크들일 수 있다.
결과적으로, 이 예에서는, 모바일 디바이스 A와 모바일 디바이스 B 사이에 구축될 수 있는 4가지의 상이한 통신 채널들, 즉 링크들(605, 609)을 이용하는 제1 채널, 링크들(605, 610)을 이용하는 제2 채널, 링크들(606, 609)을 이용하는 제3 채널, 링크들(606, 610)을 이용하는 제4 채널이 존재한다. 일 실시예에서, 모바일 디바이스 A 및 B는 우선순위결정 스킴(prioritization scheme)에 기초하여 이 채널들 중 하나를 프라이머리 통신 채널로서 선택할 것이며, 3개의 나머지 채널들을 백업 통신 채널들로서 선택할 것이다. 예를 들어, 하나의 우선순위결정 스킴은 최고의 대역폭을 갖는 채널을 프라이머리 채널로 선택하고 나머지 채널들을 세컨더리 채널들로 이용하는 것일 수 있다. 만약 2개 이상의 채널들이 필적할만한 대역폭을 갖는 경우, (사용자가 하나 이상의 채널들을 이용하기 위해 비용을 지불한다고 가정한다면) 우선순위결정 스킴은 가장 덜 비싼 채널을 선택하는 것을 포함할 수 있다. 대안적으로, 우선순위결정 스킴은 가장 덜 비싼 채널을 프라이머리 채널로서 선택하는 것일 수 있으며, 각 채널의 비용이 동일한 경우에는 최고의 대역폭 채널을 선택하는 것일 수 있다. 다양한 상이한 우선순위결정 스킴들은, 본 발명의 기본 원리들에 여전히 부합하는 상태에서 구현될 수 있다.
모바일 디바이스 A(601) 및 모바일 디바이스 C(603)는 (예를 들어, CDX 서비스(110)를 통해 접속 데이터를 교환함으로써) 프라이머리 통신 채널을 구축하기 위해 전술한 기술들을 이용할 수 있다. 대안적으로, 모바일 디바이스들(601, 603)은, 접속 데이터를 교환하기 위해, 표준 ICE(Internet Connectivity Establishment) 트랜젝션들을 실행할 수 있다. 프라이머리 채널들이 어떻게 구축되는지와 무관하게, 일단 구축되고 나면, 모바일 디바이스 A(601)와 모바일 디바이스 C(603)는 프라이머리 통신 채널을 통해 세컨더리 통신 채널들에 대한 접속 데이터를 교환할 수 있다. 예를 들어, 도 6의 프라이머리 통신 채널이 통신 링크(606)와 통신 링크(609)를 포함하는 경우, 이 접속은, 일단 구축되고 나면, 통신 링크(605, 609)를 포함하는 세컨더리 통신 채널들에 대한 접속 데이터를 교환하는데 사용될 수 있다. 이 예시에서, 프라이머리 통신 채널을 통해 교환된 접속 데이터는, 각각의 모바일 디바이스들에 대한 퍼블릭 및 프라이빗 IP 주소들/포트들을 포함하여, NAT(611) 및 NAT(613)에 대한 NAT 통과 데이터 및 NAT 타입 데이터를 포함할 수 있다.
세컨더리 통신 채널들이 설정되었으면, 그것들은 하트비트 패킷들(heartbeat packets)을 이용하여 열림(open)으로 유지된다. 예를 들어, 디바이스 A는 작은 "하트비트" 패킷을 디바이스 C로 주기적으로 전송할 수 있고/있거나, 디바이스 A는 작은 "하트비트" 패킷을 디바이스 C로 주기적으로 전송하여 세컨더리 채널들에 대해 사용된 NAT 포트들이 계속 열림이 되도록 할 수 있다(흔히 NAT들은 비활동으로 인해 포트들을 닫을 것임). 본 발명의 근본적인 원리들이 임의의 특정한 패킷 형식에 한정되지 않지만, 하트비트 패킷들은 어떠한 페이로드도 갖지 않는 UDP 패킷들일 수 있다. 하트비트 패킷들은 그것들의 페이로드 헤더에서 자기 식별 타입 필드를 갖는 UDP 패킷들일 수 있고, 채널 유지 시간 값(channel time-to-live value)을 포함하는(이에 한정되지 않음) 선택적인 추가 포맷의 정보를 포함할 수 있다.
도 7에서 도시된 것처럼, 각각의 모바일 디바이스(601)는 프라이머리 및 세컨더리 통신 채널들의 리스트를 포함하는 데이터 구조(710)(예를 들어, 테이블, 텍스트 파일, 데이터베이스 등)를 저장하고 유지한다. 개별적인 엔트리가 각각의 통신 채널에 제공되고, 그 채널을 이용하기 위해 요구되는 접속 데이터(예를 들어, 프라이빗/퍼블릭 IP 주소, NAT 타입, 등) 및 그 채널의 현재 상태(예를 들어, 프라이머리, 세컨더리 1, 세컨더리 2 등)를 포함한다.
일 실시예에서, 통신 인터페이스들(701 및 702)이 통신 링크(605) 및 통신 링크(606)를 통해 통신하기 위해 각각 사용된다. 고장(failure) 검출 모듈(705)은 모바일 디바이스(601) 상에서 실행되어, 언제 특정 통신 인터페이스/링크가 고장나거나 특정한 임계값 미만으로 저하되었는지를 검출할 수 있다. 응답에서, 링크 관리 모듈(706)은 프라이머리/세컨더리 접속 데이터(710)를 판독하여 두번째로 높은 우선순위를 갖는 세컨더리 채널을 프라이머리 채널로 승격시킬 수 있다. 세컨더리 채널들의 우선순위 결정(prioritization)은 프라이머리 채널들에 대해 상술한 것과 동일한 원리들을 사용하여(예를 들어, 대역폭, 비용, 신뢰도 등에 기초함) 달성될 수 있다. 세컨더리 채널이 선택되면, 링크 관리 모듈(706)은 링크 고장 인디케이션을 다른 모바일 디바이스들 상의 링크 관리 모듈들로 전송할 수 있고, 그 장치들에게 세컨더리 통신 채널을 프라이머리 통신 채널로 승격시킬 것을 명령할 수 있다. 그 후 그 장치들은 선택된 프라이머리 채널과 연관된 접속 데이터를 사용하여 시작할 것이다.
일 실시예에서, 세컨더리 통신 채널들 중 하나로 스위칭을 하기 위해 프라이머리 통신 채널의 완전한 "고장"이 요구되지는 않는다. 예를 들어, 일 실시예에서, 프라이머리 통신 채널이 충분히 저하되는 경우(예를 들어, 특정 대역폭, 비트레이트, 또는 신뢰도 임계값 미만인 경우), 세컨더리 채널로의 변경이 여기서 설명되는 것처럼 구현될 수 있다. 일 실시예에서, 세컨더리 채널로의 스위칭은, 세컨더리 채널이 현재 프라이머리 채널보다 더 좋은 성능(예를 들어, 대역폭, 비트레이트 또는 신뢰도)을 지원할 수 있는 경우에만 수행된다.
도 8a는, 네트워크(610)에 직접적으로 접속되고 프라이빗 네트워크 접속(620)을 통해 디바이스 C(603)에 접속되는 모바일 디바이스 B(602)가 추가된, 도 6에서 도시된 것과 동일한 네트워크 구성을 도시한다. 예를 들어, 프라이빗 네트워크(620)는 디바이스 B(602)와 디바이스 C(603) 사이의 블루투스 PAN 접속일 수 있다. 이러한 예시로부터 프라이머리 채널로부터 세컨더리 채널로의 스위칭이 네트워크 토폴로지를 극적으로 변화시킬 수 있다는 것을 알 수 있다. 예를 들어, 도 8b에 도시된 것처럼, 모바일 디바이스들에 대한 프라이머리 채널들(801)이 통신 링크(609)(디바이스들(A, B 및 C) 사이의 직접 접속들을 발생시킴)를 포함하고, 세컨더리 채널들이 프라이빗 네트워크(620)를 포함하는 경우, 디바이스 A 및 디바이스 C가 프라이빗 네트워크를 사용하여 통신하기 위한 유일한 방법이 디바이스 B를 통하는 것이기 때문에, 네트워크 토폴로지는 도 8c에 도시된 것처럼 변할 수 있다. 이것이 단지 세 개의 디바이스들을 구비한 간단한 예시인 반면에, 상당히 더 많은 수의 디바이스들이 사용될 수 있고, 프라이머리 및 세컨더리 통신 채널들 사이에 스위칭이 되는 경우 여러 가지의 상이한 네트워크 토폴로지 구성들이 생길 수 있다.
세컨더리 채널들을 설정하고 유지하는 방법의 일 실시예가 도 8에 도시된다. 일 실시예에서, 상기 방법은 각각의 모바일 디바이스 상에서 링크 관리 모듈(706)에 의해 실행될 수 있다. 그러나 상기 방법은 임의의 특정한 디바이스 구성에 한정되지 않는다.
단계(901)에서, 프라이머리 P2P 통신 채널이 선택된다. 상술한 것처럼, 프라이머리 채널은 미리 정의된 우선순위 결정 스킴에 기초하여 선택될 수 있다. 예를 들어, 특정 통신 채널 타입들이 다른 통신 채널 타입들보다 먼저 우선순위가 결정될 수 있다. 채널들은 또한 대역폭, 사용 비용, 및/또는 신뢰도 등의 변수들에 기초하여 우선순위가 결정될 수 있다.
단계(902)에서, 백업 P2P 통신 채널들이 설정된다. 일 실시예에서, 이것은 프라이머리 통신 채널을 통해 모든 모바일 디바이스들 사이에 접속 데이터를 공유함으로써 달성된다. 단계(903)에서, 백업 채널들이 유지된다. 일 실시예에서, 이것은 세컨더리 통신 채널들을 통해 (예를 들어, 주기적 하트비트 패킷들의 형태로) 주기적으로 데이터를 전송하는 것을 포함한다.
단계(904)에서, (예를 들어, 특정 모바일 디바이스의 통신 링크가 작동 중단되었거나 또는 모바일 디바이스가 통신 링크의 범위 밖으로 이동하였기 때문에) 프라이머리 P2P 채널이 고장나는 경우, 단계(905)에서 모바일 디바이스들은 최고 우선순위 백업 채널을 프라이머리 채널로 승격시킨다. 일 실시예에서, 이것은, 고장난 링크를 가지는 모바일 디바이스가 세컨더리 채널을 통해 그것의 링크 고장의 통지를 다른 디바이스들로 전송하는 것을 포함한다. 마지막으로, 단계(906)에서, 백업 채널이 프라이머리 채널로 되고, 프로세스는 (임의의 추가 백업 채널들이 발견되고 우선순위 결정 스킴에 추가되는) 단계(902)로 돌아간다.
피어-투-피어(P2P) 통신 채널들을 설정하기 위한 초대 서비스를 위한 장치 및 방법
도 10에 도시된 것처럼, CDX 서비스(110), 매치메이커 서비스(111) 및 초대 서비스(112)(소정의 실시예들이 상술됨)에 추가하여, 본 발명의 일 실시예는 등록/디렉토리 서비스(1052), 푸시 통지 서비스(1050), 및 릴레이 서비스(1051)를 포함한다. 상술한 것처럼, 일 실시예에서, 초대 서비스(112) 및/또는 매치메이커 서비스(111)는 등록/디렉토리 서비스(1052)를 사용하여 등록된 모바일 디바이스들을 식별하고, 푸시 통지 서비스(1050)를 사용하여 데이터를 모바일 디바이스들로 푸시할 수 있다. 일 실시예에서, 모바일 디바이스가 네트워크에서 활성화되는 경우, 그것은 "푸시 토큰(push token)"(때때로 푸시 통지 어플리케이션(Push Notification Application)에서 "통지 서비스 계정 식별자"로 칭해짐)을, 상기 푸시 토큰을 암호 보호되는 사용자 ID 또는 전화 번호와 연관시킴으로써, 등록/디렉토리 서비스(1052)에 의해 유지되는 데이터베이스에 등록한다. 푸시 토큰이 등록 디렉토리에서 (예를 들어, 사용자 ID를 이용하여 쿼리를 수행함으로써) 식별되는 경우, 푸시 통지 서비스(1050)는 푸시 토큰을 사용하여 푸시 통지들을 모바일 디바이스로 전송할 수 있다. 일 실시예에서, 푸시 통지 서비스는, 본 발명의 출원인에 의해 설계되고, 예를 들어, 위에서 참조된 푸시 통지 어플리케이션에서 설명된 애플 푸시 통지 서비스(Apple Push Notification Service; APNS)이다.
도 11은 두 개의 모바일 디바이스들 사이의 직접 P2P 접속을 설정하기 위해 푸시 통지 서비스(1051)가 사용되는 본 발명의 실시예를 도시하고, 도 12는 릴레이 서비스(1051)를 통해 P2P 접속을 설정하기 위해 사용되는 실시예를 도시한다. 아래에서 설명되는 것처럼, P2P 접속을 설정하기 위해 릴레이 서비스(1051)를 사용할 것인지에 관한 결정은 모바일 디바이스들 사이의 직접 P2P 접속을 설정하는 것의 실행 가능성에 기초할 수 있다(예를 들어 NAT 호환성 이슈들에 기초함).
도 11을 참조하면, 1101에서 모바일 디바이스 A(120)는 모바일 디바이스 B를 초대하기 위해, P2P 통신 세션(예컨대, 협동 비디오 게임, P2P 비디오 채팅, 등)으로 모바일 디바이스 B(121)를 초대하기 위한 초대를 송신한다. 일 실시예에서, 초대는, 특정 온라인 어플리케이션의 맥락 내에 모바일 디바이스 B(121) (및/또는 모바일 디바이스 B의 사용자)를 식별하는 사용자 ID 코드를 포함한다. 예를 들면, 사용자 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 타입 데이터는, 초대 요청(1101) 이전에 모바일 디바이스 A에 의해 사전에 결정되었을 수 있다(예컨대, 도 2a-c와 관련하여 앞서 기재된 것들과 같은 NAT 통과, NAT 타입 및 접속 데이터 트랜젝션들을 통해서). 앞서 기재된 바와 같이, 초대 요청(1101)은 HTTPS 요청의 형태를 취할 수 있다. 또한, 추가적인 보안을 위해 초대 요청(1101)은, 미리 지정된 인증서 권한자에 의해 서명된 클라이언트 인증서를 포함할 수 있다.
모바일 디바이스 B를 식별하는데 사용되는 ID 코드의 특정 타입에 관계없이, ID 코드는 초대 서비스(112)에 의해 수신되고, 1102에서 초대 서비스(112)는 디렉토리 서비스(1052)(도 11에는 도시되지 않음)에서 룩업을 실행하여, 통지들을 모바일 디바이스 B로 푸시하는데 사용되는 푸시 토큰("푸시-토큰-B")와 같은 통지 서비스 계정 식별자를 식별할 수 있다. 일 실시예에서, 룩업 동작들은, 초대가 허용되어야 하는지를 결정하기 위해 여러 번의 체크들을 수행할 수 있다. 첫째로, 모바일 디바이스 A에 대한 식별 코드("ID-A")와 디바이스 A의 푸시 토큰("푸시-토큰-A")이 디렉토리 서비스 데이터베이스 내에 등록된 연관성이라는 것이 확인될 수 있다. 룩업 동작(1102)은 또한, 모바일 디바이스 A의 사용자가 모바일 디바이스 B의 사용자를 초대하도록 허용되는지를 확인할 수 있다(예컨대, 모바일 디바이스 B의 사용자는, B의 친구들로 등록된 다른 사용자들만이 사용자 B를 초대할 수 있는 것으로 지정할 수 있거나, 또는 아무 초대도 허용되지 않는 것으로 지정할 수 있다). 일 실시예에서, 이러한 체크들 중 임의의 것을 하지 못하면, 초대는 취소되고, 초대 서비스(112)는 모바일 디바이스 A에 에러로 리턴된다.
이 실시예에서 "푸시 토큰"이 기재되었지만, 본 발명의 근본 원리들은 "푸시 토큰"의 사용, 또는 통지들을 인증하고 모바일 디바이스들에게 푸시하기 위한 임의의 다른 특정 데이터 구조로만 제한되는 것이 아니라는 것을 유의해야 한다.
일 실시예에서, 푸시 토큰이 식별된 후에, 초대 서비스(112)는, 모든 추가 트랜젝션들에의 세션을 식별하는 데 사용되고 초대 세션에 할당되는 1회용의 보안 "세션 토큰"(secure, one-time "session token")을 생성할 수 있다. 이후에, 세션 토큰의 사본은 모바일 디바이스 A(120)로 다시 전송되고, 초대 요청과 함께 모바일 디바이스 B로 전송된다. 일 실시예에서, 세션 토큰은 위에 기술된 티켓 데이터 구조와 함께 사용되고, 다른 실시예에서는 세션 토큰만이 사용된다.
1103에서, 초대 서비스(112)는 푸시 요청을 푸시 통지 서비스(1050)으로 전송한다. 일 실시예에서, 푸시 요청은, 모바일 디바이스 A에 대한 NAT 통과 데이터, 디바이스 A의 ID 코드, 푸시-토큰-A, 디바이스 B의 ID 코드, 및 푸시-토큰-B를 포함할 수 있다. 일 실시예에서, 이 정보는 위에 기술된 바와 같이 "티켓" 데이터 구조 내에 패키징될 수 있고, 암호화될 수 있다. 다른 실시예에서, 데이터는 단순히 초대 세션 ID와 함께 전송된다.
이러한 예에서의 모바일 디바이스 B(121)는 푸시 통지 서비스(1050)에 등록되므로, 1104에서 푸시 통지 서비스(1050)는 초대 요청을 모바일 디바이스 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)로 전송할 수 있다. 응답시에, 서비스는 도 12와 관련하여 이하 기술되는 일련의 릴레이 트랜젝션들을 직접 개시할 수 있다(1201에서 시작).
1106에서, 초대 서비스(112)는 모바일 디바이스 A와 B간의 직접 P2P 접속이 실현가능한지 여부를 판정하기 위한 호환성 체크를 수행할 수 있다. 예컨대, 일 실시예에서, 모바일 디바이스 B로부터 수신된 수락(1105)이 이전의 실패한 직접 접속 시도로부터의 재시도(또는 이전의 실패한 직접 접속 시도들의 특정 수)임을 나타내면, 다음에 초대 서비스는 직접 P2P 접속이 실현가능하지 않다고 결론내릴 수 있다. 초대 서비스(112)는, 모바일 디바이스 A 및 B의 NAT 디바이스들이 직접 P2P 접속을 지원하는지를 판정하기 위해 모바일 디바이스 A 및 B에 대한 NAT 타입 데이터를 비교할 수 있다. NAT 타입의 특정 조합들은 P2P 접속을 확립하는데 호환가능하지 않은 것으로 알려져 있다. 예컨대, 풀 콘 NAT는 직접 P2P 접속을 확립하기 위해 폐쇄/방화벽 NAT를 제외하고 임의의 다른 NAT 타입과 함께 이용될 수 있다. 이에 반해, 대칭 NAT는 직접 P2P 접속을 확립하기 위해 풀 콘 NAT와 함께만 이용될 수 있다. 본 발명의 일 실시예에서 다양한 NAT 타입의 조합의 실현가능성은 도 14에 도시된 NAT 호환성 테이블(1400)에 개시되어 있으며, 여기서 행은 하나의 모바일 디바이스(예컨대, 모바일 디바이스 A)의 NAT 타입을 나타내고, 열는 다른 모바일 디바이스(예컨대, 모바일 디바이스 B)의 NAT 타입을 나타낸다. 셀내의 "1.0"은 연관된 열 및 행내의 NAT 타입이 호환가능하다는 것을 나타내고, "0.0"은 NAT 타입이 호환가능하지 않다는 것을 나타낸다.
일 실시예에서, 호환성 체크(1106)가 직접 P2P 접속이 실현가능하지 않은 것으로 판정하면, 다음에 초대 서비스(112)는 이하 도 12와 관련하여 기술되는 바와 같이 릴레이 룩업 요청(1201)을 전송할 수 있다. 그러나, 호환성 체크(1106)가 직접 P2P 접속이 실현가능한 것으로 판정하면, 다음에 초대 서비스(112)는, 모바일 디바이스 B의 모바일 디바이스 A의 초대의 수락을 포함하는 푸시 통지 서비스(1050)에 푸시 요청(1107)을 전송할 수 있다. 푸시 요청(1107) 및 푸시 통지 서비스(1050)으로부터 모바일 디바이스 A에 대한 후속 푸시 통신(1108)은 세션 토큰, 및 모바일 디바이스 A 및 B의 푸시 토큰, ID 코드, 및/또는 NAT 통과/접속 데이터를 포함할 수 있다. 일 실시예에서, 이 정보는 전술한 바와 같은(예컨대, 도 2a-c 및 관련 텍스트 참조) "티켓" 데이터 구조내에 패킷될 수 있고, 고유 키를 이용하여 암호화될 수 있다. 대안적으로, 이 정보는 단순히 고유 초대 세션 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)는 릴레이 호스트가 각각의 모바일 디바이스에 의해 이용되는 것을 판정하기 위해 릴레이 룩업 요청(1201)을 릴레이 서비스(1051)로 전송할 수 있다. 요청(1201)은 모바일 디바이스 A 및 B에 대한 네트워킹 정보(예컨대, NAT 통과/ 접속 데이터 및/또는 NAT 타입 데이터)를 포함할 수 있고, 이 정보는 모바일 디바이스 양자 모두에 대한 적절한 릴레이 호스트를 선택하기 위해 릴레이 서비스(1051)에 의해 이용된다. 도 13에 도시되는 바와 같이, 릴레이 서비스(1051)의 일 실시예는 복수의 릴레이 호스트(1302-1303) 및 릴레이 호스트들 각각과 관련된 네트워크 정보를 포함하는 릴레이 호스트 데이터베이스(1301)를 포함한다. 초대 서비스(112)는 릴레이 룩업 요청(1201)을 릴레이 룩업 서비스(1300)로 전송하고, 모바일 디바이스 A 및 B에 대한 네트워크 정보를 이용하여 릴레이 호스트 데이터베이스(1301)에 쿼리한다. 데이터베이스 결과를 수신하면, 릴레이 룩업 서비스(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)은 (푸시 통지 서비스(1050)를 바이패싱하여) 모바일 디바이스 B로 직접 송신될 수 있는데, 그 이유는 모바일 디바이스 B의 수락(1105)에 응답하여 송신되기 때문이다.
초대 서비스(112)는 릴레이 토큰 및 릴레이 호스트 B (1303)에 대한 네트워크 정보를 포함할 수 있는 릴레이 응답(1204)을 모바일 디바이스 A로 전송한다. 이 경우에, 응답(1204)은 트렌잭션(1205)에서의 푸시 통지 서비스(1050)을 통해 모바일 디바이스 A로 푸시된다.
1206에서, 모바일 디바이스 A(120)는 릴레이 호스트 A(1302)에 대한 네트워크 정보를 이용하여 릴레이 서비스(1051)와의 접속을 확립한다. 마찬가지로, 1207에서, 모바일 디바이스 B(121)는 릴레이 호스트 B(1303)에 대한 네트워크 정보를 이용하여 릴레이 서비스(1051)와의 접속을 확립한다. 이러한 거래들 각각에서, 새로운 홀들은 모바일 디바이스들 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에 의해 전송되는 릴레이 업데이트는 1206 및 1207에서 릴레이에 의해 결정되는, 세션 토큰, 각각의 디바이스의 ID 코드 및 NAT 통과/접속 데이터를 포함할 수 있다(즉, 모바일 디바이스 A가 그 NAT 통과/접속 데이터를 모바일 디바이스 B에게 보내며 또한 역으로 모바일 디바이스 B가 그 NAT 통과/접속 데이터를 모바일 디바이스 A에게 보낸다). 일 실시예에서, 릴레이 업데이트 동작들이 수행되는데, 이는 각각의 모바일 디바이스의 NAT 정보가 변할 수 있기 때문이다.
마지막으로, 1214 및 1215에서, 모바일 디바이스들 A 및 B 각각은 릴레이 서비스(1051)를 통해 P2P 접속을 확립한다. 일 실시예에서, 릴레이 접속들은 모바일 디바이스 A가 모바일 디바이스 B의 NAT 통과/접속 데이터를 릴레이 서비스(1051)에게 보내며 또한 역으로 모바일 디바이스 B가 모바일 디바이스 A의 NAT 통과/접속 데이터를 릴레이 서비스(1051)에게 보낼 때 확립될 수 있으며, 이에 의해 릴레이 서비스가 각각의 피어의 릴레이 호스트(1302, 1303)로의 정확한 경로를 결정하도록 허용할 수 있다.
전술한 기법들을 이용하여, 초대 서비스(112)는, 대량의 모바일 디바이스들을 갖는 큰 스케일의 시스템에서도, 고유하게 스케일러블하고 또한 회복력이 있는 스테이트리스 서비스로서 구현될 수 있다. 예컨대, 푸시 통지 서비스(1050)가 등록된 모바일 디바이스들에게 콘텐츠를 고유하게 로케이팅하고 푸시할 수 있기 때문에, 초대 서비스는 각각의 디바이스의 현재의 위치를 추적할 필요가 없다. 또한, 디바이스들이 각각의 요청 및 응답을 갖는 전체 세션 상태 데이터를 전송할 수 있기 때문에, 초대 서비스는 임의의 완전한 접속 상태 정보를 유지할 필요가 없으므로, 초대 서비스의 저장 및 처리 요건들을 줄인다. 이러한 구현은 큰 스케일의 시스템에서 특히 유용하다.
온라인 세션들과 사용자들을 매칭하기 위한 시스템 및 방법
도 15에 도시된 바와 같이, 매치메이커 서비스(111)의 일 실시예는 매치 요청들을 수신하고 또한 매치 응답을 모바일 디바이스들(120-122)에게 푸시하는 매치메이커 디스패처(1501), 매치 요청들을 요청 테이블(1502)에 저장하고 또한 매치가능한 세트 데이터를 매치가능한 세트 식별자(MSI) 테이블(1503)에 저장하는 데이터베이스(1512), 및 데이터베이스(1512)로부터의 매치 요청들을 페칭하여 매칭 동작들을 수행하고 또한 매치 결과들을 데이터베이스(1512)에 되저장하는 하나 이상의 매치메이커(1510)를 포함할 수 있다. 그러나, 본 발명의 기본 원리들은 도 15에 도시된 특정한 아키텍처에 국한되지는 않는다.
일 실시예에서, 매치메이커 디스패처(1501)는 매치메이커 서비스(111)에 대한 인터페이스로서 동작하여, 모바일 디바이스들(120-122)로부터 요청들을 수신하고, 요청들을 데이터베이스(1512)에 저장하도록 하는 커맨드들로 이러한 요청들을 변환(translating)하고, 데이터베이스(1512)로부터의 매치 결과들을 판독하며, 이러한 결과들을 모바일 디바이스들(120-122)에게 변환 및 통신한다.
동작시, 새로운 매치 요청이 도달할 때, 매치메이커 디스패처(1501)는 요청 테이블(1502)의 행 내에 요청을 저장할 수 있다. 일 실시예에서, 디스패처(1501)는, 도 15에서 (모바일 디바이스들 A, B 및 C에 제각기 대응하는) "A", "B" 및 "C"로서 간결하게 도시되어 있는, 요청 ID(RID) 코드에 각각의 매치 요청을 할당한다. 도 15에서는 간결함을 위해 문자 지정을 이용하여 도시되어 있지만, RID 코드는 데이터베이스 내의 매치 요청들을 추적하는데 적합한 스트링, 정수 또는 임의의 다른 가변 타입일 수 있다.
각각의 매치 요청에는 요청 테이블(1502)에 저장되는 매치가능한 세트 식별자(MSI) 값이 할당될 수 있다. 일 실시예에서, MSI는 매치가 요청되는 특정한 어플리케이션 및/또는 그 어플리케이션에 이용될 구성 파라미터들을 식별할 수 있다. 예컨대, 12:4의 MSI 값은 특정한 멀티-플레이어 게임을 식별자 "12"로 식별할 수 있으며 또한 그 게임에 대한 특정한 구성을 식별자 "4"로 식별할 수 있다. 더 구체적으로는, 12의 ID 코드는 게임에 참여하는 특정한 멀티-플레이어를 식별할 수 있으며, 4의 ID 코드는 그 참여 게임에 대한 특정한 참여 트랙, 속도 또는 플레이어의 경험 레벨을 지정할 수 있다. 일 실시예에서, 어플리케이션 개별자들에게는 이러한 방식으로 MSI 값들을 이용하여 임의의 어플리케이션 구성 파라미터들을 지정하는 옵션이 제공된다. 일 실시예에서, MSI를 직접적으로 지정하기 보다는, 어플리케이션 개발자들은 (특정한 게임을 식별하기 위한) 게임 ID 및 (특정한 게임 구성을 식별하기 위한) 버킷 ID를 지정하고, 이러한 값들은 매치메이커 디스패처(1501)에 의해 MSI 값에 매핑된다.
또한, 여러 상이한 MSI 값들이 단일의 MSI 내에서 이용되어 다중의 상이한 구성 파라미터들을 지정할 수 있다(예컨대, 12:4:1은 12=참여 게임; 4=트랙; 및 1=경험 레벨을 나타낼 수 있다). 이하에서 상세히 설명하는 바와 같이, 일 실시예에서, 각각의 MSI는 매치메이킹 동작들이 수행될 수 있는 매치 요청들의 세트를 식별하기 위해 매치메이커(1510)에 의해 이용된다(예컨대, 요청들은 MSI에 기반하여 그룹화되고, 매치들은 각각의 MSI 그룹 내에서 수행된다). 일 실시예에서, 각각의 MSI는 디스패처에 의해 동적으로 수정/선택되어 상이한 머신 파티션들을 식별하는 파티션 ID를 포함할 수 있다. 예컨대, 만약 특정한 MSI가 과부하되면, 디스패처는 (예를 들면, 4:3:1 및 4:3:2와 같은 지정들(여기서, 최종 숫자들은 파티션들 1 및 2를 제각기 식별함)을 이용하여) 둘 이상의 상이한 서버들 및 저장 파티션들 간에 MSI를 나눌 수 있다. 그 후, 상이한 매치메이커는 상이한 서버들 각각으로부터의 상이한 MSI들 각각으로부터 요청들을 독립적으로 검색 및 처리할 수 있다.
도 15에 도해된 바와 같이, 매치 요청 데이터는 또한 각각의 요청에 대해 요청 테이블(1502) 내에 저장될 수 있다. 요청 데이터는, 네트워크를 거쳐 요청을 개시하는, 매치메이킹 결정을 내리는 데에 이용 가능한 임의의 데이터 및/또는 모바일 디바이스에 액세스할 필요가 있는 임의의 데이터를 포함할 수 있다. 예를 들어, 일 실시예에서, 각각의 요청에 대한 매치 요청 데이터는 요청을 개시하는, 모바일 디바이스에 대한 NAT 타입 데이터 및/또는 NAT 통과/접속 데이터를 포함한다. 요청 데이터의 다른 타입들은 또한 디바이스 접속 속도(100kbps, 1Mbps, 등), 접속 타입(예를 들어, 3G, EDGE, WiFi, 등), (예를 들어, 지리적 기술에 의해 결정되는)디바이스 위치, 언어(영어, 스페인어, 등) 및/또는 사용자 선호도와 같이 요청 테이블(1502) 내에 저장될 수 있다. 요청 데이터는 각각의 모바일 장치(120-122)에 의해 결정될 수 있고, 각 매치 요청으로 매치메이킹 디스패처(1501)에 송신될 수 있다. 예를 들어, 각각의 모바일 디바이스는, 몇몇은 여기서 기술되는 여러 기술(예를 들어, NAT 통과/접속 데이터를 결정하기 위한 NAT 통과 서버와의 통신, 디바이스 위치를 결정하기 위한 GPS 이용, 언어를 결정하기 위한 HTTP 정보 판독 등)을 이용하여 자신의 접속 데이터, 접속 타입, 디바이스 위치 등을 결정할 수 있다.
도 15에 도시된 바와 같이, 일 실시예에서, 각각의 활성 MSI는 MSI 테이블(1503)의 행에 할당될 수 있다. 일 실시예에서, 새로운 요청이 도착하는 경우에, 요청을 요청 테이블(1502)에 부가하며, 디스패처(1501)는 또한 MSI가 이미 그 요청에 대해 존재하는 지(즉, 동일한 MSI를 갖는 다른 요청들이 이미 수신되었는지)를 판정하기 위해 MSI 테이블(1503)을 확인한다. 만약 어떤 매칭 MSI도 발견되지 않으면, 디스패처(1501)는 새로운 요청을 위한 MSI 테이블(1503)내의 새로운 엔트리를 생성할 수 있다. 만약 매칭 MSI가 발견되면, 디스패처는 앞서 기술된 바와 같이 요청 테이블(1502)에 새로운 요청을 간단히 부가할 수 있다.
일단 요청 테이블(1502) 및 MSI 테이블(1503)이 매치메이커 디스패처(1501)에 의해 업데이트 되면, 매치메이커 모듈(1510)[이하 간단히 "매치메이커(1510)"라고 함]의 인스턴스가 매치메이킹 동작들을 수행하도록 데이터를 패치(fetch)한다. 다중 매치메이커 인스턴스는 매치메이킹 요청들을 수행하도록 동시에 실행될 수 있고, 단일 매치메이커(1510)는 다수의 상이한 MSI 그룹에서 다중 매치메이킹 동작을 동시에 프로세싱할 수 있다.
일 실시예에서, 매치메이커(1510)가 이용 가능하게 되는 경우에(예를 들어, MSI 그룹에 대한 매칭 동작들을 완료한 후에 또는 초기화된 후에), 매치메이커는 프로세싱할 새로운 MSI를 식별하기 위해 MSI 테이블(1503)에 쿼리한다. 도 15에서, MSI 3:1에 대한 매치메이커 ID 필드들 내의 "N/A" 값은 이 MSI 프로세싱에 대한 책임이 아직 매치메이커에서 할당되지 않았다는 것을 표시한다. 일 실시예에서, 각각의 MSI 엔트리는 타임 스탬핑되고, 매치메이커(1510)는 가장 오래된 타임 스탬프를 갖는 MSI를 선택한다.
일 실시예에서, 매치메이커(1510)가 특정 MSI에 대한 책임을 갖는다고 가정하는 경우에, 매치메이커는 MSI 테이블(1503)에서 자신의 매치메이커 ID 코드를 업데이트하고 그 MSI에 대한 리스(lease) 지속시간(예를 들어, 5초)을 구체화한다. 일 실시예에서, 매치메이커(1510)는 자신이 그 MSI에 대한 매치들을 프로세싱함에 따라 연속적으로 리스 값을 업데이트한다. 리스 값들은 장애 매치메이커들(1510)로 할당된 MSI들을 식별하는 데에 이용될 수 있다. 예를 들어, 만약 리스 값이 만료되면, MSI 테이블(1503)이, MSI가 이미 매치메이커에 할당되었다고 나타내는 사실에도 불구하고 그 MSI는 새로운 매치메이커에 의해 주장될 수 있다.
일단 매치메이커(1510)가 하나의 MSI에 대한 책임을 가졌다고 가정하면, 매치메이커는 메모리 내로 그 MSI와 연관된 요청들을 판독하도록 요청 테이블(1502)에 쿼리할 수 있다. 매치메이커(1510)는 그러면 (예를 들어, 아래에 기술된 바와 같은)매칭 기준의 세트에 따라 사용자들 및 모바일 디바이스들을 매칭하도록 매칭 동작들을 수행할 수 있다. 매치메이커(1510)는, 모바일 디바이스의 매치들이 이루어진 때를 표시하도록 요청 테이블(1512)을 업데이트할 수 있다. 예를 들어, 매체메이커는 요청 테이블(1512)의 MSI 열로부터 MSI 값들을 제거할 수 있고 매치가 완료되었다고 표시하는 사전에 정의된 값을 입력할 수 있다. 또한, 매치메이커(1510)는 각각의 참가자에 대한 "요청 데이터" 필드를 업데이트하여 (예를 들어, 다른 참가자들과 통신하기 위해 필요한 NAT 통과/접속 데이터를 기입함으로써)그 참가자가 매칭되는 다른 참가자들을 식별할 수 있다.
디스패처(1501)는 요청 테이블(1502)에 주기적으로 쿼리하여 완료된 매치들을 식별할 수 있다. 완료된 매치의 검출에 응답하여, 디스패처(1501)는 푸시 통지를 매치에 수반되는 모바일 디바이스들에게 (예를 들어, 여기서 및 함께 계류중인 출원들에서 기술된 푸시 통지 기술들을 이용하여) 송신할 수 있다. 일 실시예에서, 푸시 통지는 앞서 기술된 "티켓" 데이터 구조를 포함한다. 모바일 디바이스들은 그러면 앞서 기술된 바와 같이 CDX 서비스(110)를 통해 접속 데이터를 교환하는 데에 자신들의 티켓들의 각각을 이용할 수 있다.
푸시 통지들을 이용하는 것에 더하여, 일 실시예에서, 모바일 디바이스들(120-122)은 매치가 이루어졌는지를 판정하기 위해 디스패처(1501)에 주기적으로 쿼리할 수 있다. 주기적 쿼리들은 푸시 통지가 모바일 디바이스에 대해 이루어지지 못한 경우에 유용하다. 그러나, 푸시 아키텍처가 이용되지 때문에, 주기적 쿼리들은 비교적 낮은 레이트로 설정될 수 있고, 그에 의해 매치메이커 서비스(111) 상의 로드를 줄일 수 있다.
도 16은 2개의 모바일 디바이스 A 및 B가 매치메이커 서비스(111)에 의해 매치되는 방법의 예시적인 실시예를 도시한다. 도 17a-d는 이런 방법이 진행함에 따라 일어날 수 있는 요청 테이블(1502) 및 MSI 테이블(1503)에 대한 예시적인 업데이트를 도시한다.
단계 1601에서, 매치 요청은 모바일 디바이스 A로부터 수신된다. 도 17a에 도시된 바와 같이, 1602에서, 모바일 디바이스 A의 요청은 요청 테이블에 입력되고, 새로운 MSI 엔트리(MSI 1:1)는 (이미 존재하지 않는다면) MSI 테이블에 입력된다. 도 17b에 도시된 바와 같이, 1603에서, 매치 요청은 모바일 디바이스 B로부터 수신되며, 1604에서, 모바일 디바이스 B의 매치 요청은 요청 테이블에 또한 입력된다.
1605에서, 특정 매치메이커 인스턴스(매치메이커 #N)은 MSI 테이블을 체크하고, MSI 1:1이 다른 매치메이커 인스턴스에 의해 주장되는지를 검출한다. 선택적으로, 매치메이커는 MSI상에서 이전에 동작중인 매치메이커가 실패했다는 것을 나타내는 만료된 리스(expired lease)를 갖는 MSI 테이블 엔트리를 검출한다. 일 실시예에서, 만료된 리스를 갖는 MSI 엔트리는 (하나의 매치메이커에 이전에 할당되지 않은) 새로운 MSI 엔트리들보다 높은 우선순위가 주어진다. 또한, 일 실시예에서, 비교적 오래된 MSI 엔트리는 비교적 새로운 MSI 엔트리보다 높은 우선순위가 주어진다. 메치메이커가 어떻게 MSI를 선택하는지와, 선택할 때와는 무관하게, 도 17c에 도시된 바와 같이(예시된 예에서는 5초의 리스값을 이용하여), 자신의 식별자를 부가하고, MSI 엔트리에 대한 새로운 리스값을 설정한다. 매치메이커는 그 후 요청 테이블에 쿼리를 하고, 그 MSI를 갖는 요청 테이블 엔트리를, 이 엔트리가 처리될 수 있도록 메모리에서 판독한다.
1606에서, 매치메이커는 각각의 요청에 대한 적당한 매치를 선택하기 위한 일련의 매칭 동작을 수행한다. 매칭 동작의 특정 실시예가 도 18을 참고로 이하 예시된다. 간략하게, 일 실시예에서, "적당한"매치를 결정하기 위해 평가되는 변수들은 NAT 타입(예컨대, 풀 콘, 제한된 포트, 대칭 등), 접속 타입(WiFi,, 3G, 에지 등), (HTTP 요청 수용-언어 헤더로부터 도출된) 사용자와 연관된 언어, 및 매치 요청들 각각의 나이를 포함한다. 일반적으로, 매치메이커(1510)는 (릴레이 서비스가 후술되는 바와 같이 때때로 사용된다 할지라도) 호환가능한 NAT 타입, 동일 접속 타입, 및 동일 언어를 갖는 모바일 디바이스를 매칭하길 시도한다. 일 실시예에서, 매치메이커(1510)는 매칭 요청의 나이에 기초하여(즉, 요청이 오래될수록, 매칭 제약이 보다 자유롭게 적용된다) 매칭 요건에서 보다 자유로울 수 있다.
도 16을 참고하면, 1607에서, 매칭 결정에 후속하여, 도 17d에 도시된 바와 같이, 매치메이커(1510)는 매칭이 완료됨을 나타내기 위해 요청 테이블을 업데이트한다. 업데이트의 일부로서, 매치메이커는 모바일 디바이스 A 및 B에 대한 요청 데이터를 업데이트한다. 예컨대, 일 실시예에서, 매치메이커(1510)는 모바일 디바이스 A에 대한 요청 데이터 행에 모바일 디바이스 B의 NAT 통과/접속 데이트를 기입하고, 모바일 디바이스 B에 대한 요청 행에 모바일 디바이스 A의 NAT 통과/접속 데이트를 기입한다.
1608에서, 디스패처(1501)는 매칭되는 요청 엔트리를 식별하기 위해 요청 데이블을 통해 판독할 수 있다. 일 실시예에서, 모바일 디바이스 A 및 B가 매칭되는 것을 검출할 때, (상술한 매치메이커에 의해 업데이트되는) 요청 데이터를 판독하고, 모바일 디바이스 A 및 B에 대한 통지를 생성한다. 일 실시예에서, 통지는 상술한 암호화된 "티켓" 데이터 구조이며, 각 모바일 디바이스에 대한 NAT 통과/접속 데이터를 포함한다. 상술한 바와 같이, 일 실시예에서, 푸시 통지 서비스(1050)는 모바일 디바이스 A 및 B에 통지를 푸시하는데 이용된다. 또한, 모바일 디바이스 A 및 B는 매치가 이루어졌는지 여부를 판정하기 위해 디스패처(1501)를 주기적으로 폴링한다. 이 실시예에서, 폴링 기술은 어떤 이유로 모바일 디바이스들 중 하나에 성공적으로 푸시되지 않은 매치를 식별하기 위해 비교적 낮은 레이트에서 행해질 수 있다. 푸시 통지를 이용하여 폴링 요청 로드를 관리하게 되면, 푸시 통지를 이용하지 않을 때 생기는 모바일 디바이스로부터의 폴링 요청으로 로드되는 매치메이커 서비스(111)상의 로드를 크게 감소시킨다.
부가적인 매치 요청이 1608에서 결정된 바와 같이, 동일 MSI에 대해 진행중이라면, 매치메이커는 MSI내의 모바일 디바이스/사용자를 계속 매칭할 것이다. 1610에서, 매치메이커는 MSI 테이블(1503)내의 리스값을 리셋할 수 있다. 1611에서 (상술한 바와 같이) 부가적인 매치들이 수행되고, 요청 테이블이 업데이트된다. 1612에서, (상술한 바와 같이) 부가적인 매치는 요청 테이블로부터 판독되고, 부가적인 모바일 디바이스는 업데이트된다. 그 후 1609에서 어떤 부가적인 매치 요청이 MSI에 대해 진행중이지 않는다면, MSI 엔트리는 (예컨대, 디스패처 및/또는 매치메이커 중 어느 하나로부터의 삭제 명령을 통해) MSI 테이블로부터 제거된다.
도 18은 모바일 디바이스/사용자들 간의 매칭을 수행하는 방법(도 16에서의 동작 1606)의 일 실시예를 도시한다. 1801에서, 모든 현재의 MSI 요청(예컨대, 특정 어플리케이션/버킷 조합에 대한)은 쌍으로 배열된다. 1802에서, 각각의 쌍 사이의 매치 "피트(fit)"가 평가되고, 1803에서, 그 쌍은 감소 피트로 분류된다. "피트"는, 이하와 같은 것으로 제한되지 않는, NAT 타입(예컨대, 풀 콘, 제한된 포트, 대칭 등), 접속 타입(WiFi, 3G, 에지 등), (HTTP 요청 수용-언어 헤더로부터 도출된) 사용자와 연관된 언어, 및 매치 요청들 각각의 나이를 포함하는 복수의 상이한 변수들에 기초하여 평가된다. 매치메이킹 결정에 인자가 될 수 있는 다른 변수들은, (예컨대, 사용자들을 특정 위치에 매칭시킬려는 시도로) 모바일 디바이스들 각각의 위치, (예컨대, 사용자 및/또는 어플리케이션에 의해 특정되는) 최소 및/또는 최대 플레이어 요건들, MSI에 포함되는 하나 이상의 사용자들이 (예컨대, "친구" 또는 이전 친분에 매칭하는 선호도를 갖는) "친구"인지 또는 이전 P2P 접속에 입력되었는지 여부, 및 어플리케이션을 갖는 사용자 경험(예컨대, 멀티 플레이어 게임의 경우, 각 사용자들의 리더보드 랭크(leaderboard rank)가 그 구성인자가 되며, 유사 경험 사용자들에 매칭하는 선호도를 가진다)을 포함한다.
아래 표 A에 표시된 바와 같이, 일 실시예에서, "피트니스(fitness)"의 평가는 0.0과 1.0 사이의 수치값이다. 부동 소숫점 값을 이용하면, 각 기준에 대한 피트니스의 정규화가 허용된다. 부동 소숫점 산술을 피하기 위해, 비정규화 정수값이 적당한 평가에 사용될 수 있어, 피트니스 값들이 비교될 수 있다.
일 실시예에서, 모든 기준은 (1.0의 정규화된 값을 갖는) 호환가능한 또는 (1.0보다 작은 정규화된 값을 갖는) 비호환가능한 이진수의 피트를 가진다. 이들은 (후술되는 바와 같이) 피트가 나이에 따라 변할 수 있는 요구 기준으로 고려될 수 있다. 위치가 변수로서 부가된다면, 최상의 피트는 요구 기준을 매칭하는 가장 근접한 플레이어에서의 피트일 것이다.
[매치 피트니스 - 표 A]
Figure 112012023023085-pat00001
일 실시예에서, 피트는 (정규화된 가중치 * 에이즈드 인자(aged factor) 값)의 합과 동일하다. 에이즈드 인자값은 1의 값에서 시작하며, 미리결정된 기간이 경과한 후 증가한다. 그 후 시간이 보다 더 경과할 때 (예컨대, 특정량만큼 주기적으로 증가할 때) 계속 증가한다. 일 실시예에서, 상술한 에이즈드 인자값을 이용하지 않고, 나이 임계값(age threshold)이 후술하는 바와 같이 구축될 수 있다. 접속 타입 및 언어와 같은 특정 변수들의 정규화된/가중처리된 값은 특정 나이 임계값(이들이 매칭되지 않는다 할지라도)에 적용될 수 있다.
일 실시예에서, 한 쌍의 요청들, A와 B 간의 "피트"는 B에 대한 A의 피트와 A에 대한 B의 피트의 평균이다. 또한, 각각의 인자의 B에 대한 A의 피트는 A의 나이에 기초하여 조정될 수 있다(그 역 또한 같음). 일 실시예에서, 1.0의 피트가 호환가능 매치에 필요할 수 있다. 이는, NAT 호환성, 접속 타입 및 언어가 매치(그로 인한 1.0의 정규화된 값)하거나, A 및/또는 B가 오래되어, 상기 변수들 중 일부(예를 들어, 접속 타입과 언어)를 실제로 (상기 에이즈드 인자 값 또는 하기 임계값을 이용하여) 무시하게 되는 경우에만, A와 B가 매치할 것이라는 것을 의미한다.
[나이 - 표 B]
Figure 112012023023085-pat00002
나이 임계값은 상기 표 B에 개시된 것과 같이 설정될 수 있다. 각각의 나이 임계값을 지나면(즉, 지정된 임계값보다 요청이 오래됨에 따라), 에이즈드 인자 값을 계속하여 커지는 값들(예를 들어, 1.5나 2.0 등)로 증가시킬 수 있다. 다른 방법으로는, 또는 이에 추가하여, 상이한 나이 임계값을 지남에 따라, 일정 변수에 대한 가중된 값을 (예를 들어, 후술하는 접속 타입 및 언어와 같은) 매치 결정에 추가할 수 있다.
일 실시예에서, 표 B에 지정된 요청 나이 한계가 주어진 MSI에 대한 매치 플로우 레이트에 따라 조정된다. 일 실시예에서, 플로우 레이트는 지정된 시간 유닛(예를 들어, 10초 단위나 분 단위 등)당 수행되는 매치의 수로서 지정된다. 따라서, 플로우 레이트는 특정 MSI 세트가 얼마나 바쁜지에 대한 표시를 제공한다. 일 실시예에서, 세트가 바쁘면 바쁠수록, 상기 표 B에서 상기 임계값 각각을 낮게 설정하여 초기의 성공적인 매치 가능성을 증가시키고 매치메이커에 대한 로드를 줄일 수 있다. 또한, 주어진 MSI 세트에 대한 로드는 최종 사용자에게 (예를 들어, 값에 매치하는데 필요한 추정된 시간의 형태로) 제공될 수 있어, 최종 사용자가 특별히 바쁜 멀티 플레이어 게임에 입장해야 하는지를 선택할 수 있도록 해준다. 로드 값은 푸시 알림의 형태로 사용자에게 제공될 수 있다.
표 A의 변수들 각각을 참조하면, 일 실시예에서, NAT 호환가능성은 도 14에 도시된 NAT 호환가능성 차트(1400)로부터 결정된다. 이 차트에 기초하여 2개의 NAT가 호환가능한 것으로 결정되면, NAT 호환가능 가중치가 적용될 수 있다.
[접속 타입 - 표 C]
Figure 112012023023085-pat00003
접속 타입은 상기 표 C에 도시된 것과 같은 차트를 이용하여 평가될 수 있다. 본 예에서, (동일 접속 타입을 만족하는 셀에서 1.0으로 표시된 것과 같이) 디바이스 A와 B의 접속 타입이 동일하면, 표 A로부터의 가중된 접속 타입 값은 피트니스 결정에 포함될 수 있다. 상술한 바와 같이, 요청들 각각의 나이를 이용하여 접속 타입 결정에 영향을 줄 수 있다. 예를 들어, 일 실시예에서, 접속 타입에 대한 피트 값은 임계값 1, 2, 및 3에서의 나이에 대한 표 C의 행렬을 이용하여 선택된다. 임계값 4 또는 그 이상의 나이의 경우, 접속 타입은 (비매칭의 접속 타입인 경우에도) 1.0으로 설정될 수 있고, 대응하는 가중된 접속 타입 값이 적용될 수 있다. 일부 실시예에서는 접속 "타입"이 이용되지만, 접속 타입 대신에, 접속 속도가 결정될 수 있고, 접속 타입과 함께, 또는 그 대신에 이용될 수 있다. 예를 들어, 일정한 지정된 범위 내의 접속 속도는 "호환가능(예를 들어, 0-100kbps; 100-500kbps; 500-1000kbps, 1000-1500kbps 등)"한 것으로 고려될 수 있다. 또한, 본원에서 논의된 매칭 변수들 중 어느 매칭 변수도 매치 피트 계산에 대한 가중치로서 적용될 수 있고, 상술한 바와 같이 나이들 수 있다.
일 실시예에서, 플레이어 언어는 선호 qfactor를 갖는 하나 이상의 언어를 포함할 수 있는 HTTP 요청 허용-언어 헤더로부터 유도될 수 있다. 디스패처는 가장 선호되는 언어를 추출하고, 이 정보를 매치메이커에 전달할 수 있다. 일 실시예에서, 표 A로부터 가중된 언어 값은, 그 언어가 동일한 경우 1.0으로 설정되고, 그렇지 않은 경우 0.0으로 설정된다. 그러나, 일 실시예에서, 나이가 지정된 임계값보다 큰 경우(예를 들어, 나이가 표 B의 임계값 2 또는 그보다 큰 경우) 언어가 상이한 경우에도 가중된 언어 값이 적용될 수 있다.
일 실시예에서, 매치는 호환가능하지 않은 NAT 타입을 갖는 2개의 사용자 사이에서 이루어질 수 있다. 예를 들어, 매치메이커가 특정 MSI에 사용자를 매치하는데 어려움이 있는 경우, 지정된 시간 기간 후에, 상술한 기술을 이용하여 릴레이 서비스(1051)를 통해 접속을 라우팅할 수 있다. 이러한 방식으로, 릴레이 서비스(1051)는 압력 값으로서 기능을 하여, 에이징 매치가 호환가능하지 않은 NAT 타입에도 발생하는 것을 허용한다. 또한, 릴레이 서비스(1051)는 하나 이상의 실패한 매치 시도를 검출하는 것에 응답하여 이용될 수 있다. 본 실시예에서, 이동 디바이스에 의해 제출된 각각의 매치 요청 하나 이상의 성공적이지 않은 매치가 이전에 시도되었는지에 대한 표시를 포함할 수 있다.
여러 추가적인 매치 기준이 평가되고, 일 예로서, 매치를 요청하는 사용자 중 임의의 사용자가 친구인지에 대한 표시를 포함하는 매치 피트 결정의 일부로서 가중 값이 제공될 수 있지만, 이에 한정되는 것은 아니다. 예를 들어, 매치메이커(1510)는 매치 피트 계산에 "친구" 가중치를 적용함으로써 "친구"인 사용자에 대한 임의의 요청과 매치하려는 시도를 할 수 있다. 이와 유사하게, 친구의 친구도 (예를 들어, 2 이상의 분리도로) 가중될 수 있다. 또한, 플레이어는 특정 게임에 대한 다른 플레이어를 레이팅할 수 있고, 매치메이커는 (낮은 레이팅을 갖는 플레이어와 사용자를 매치하지 않고, 비교적 높은 레이팅을 갖는 플레이어와 사용자를 매치하려는 경향으로) 매치를 수행하는 경우 레이팅을 수행할 수 있다. 또한, 사용자의 접속 레이턴시가 (예를 들어, 단순한 핑 연산을 이용하여) 평가되고 매치메이킹 결정의 일부로서 이용될 수 있다.
플레이어를 매치하는데 이용되는 또 다른 변수는 디바이스 타입일 수 있다. 예를 들어, 매치메이커(1510)는 플레이어를 유사한 디바이스 타입(예를 들어, iPad들, iPod들, iTouch들, iPhone들, RIM Blackberry들 등)과 매치하려는 시도를 할 수 있다. 추가적인 변수는 사용자의 리더보드 랭킹, 현재 위치, 현재 거주, 나이, 성별을 포함할 수 있고, 유사한 게임 컬렉션이 매치 결정에 대하여 유사하게 평가될 수 있다(즉, 많은 경우에 있어서, 유사한 기준을 갖는 사용자 간의 매치를 선호하는 경향이 있음). 끝으로, 부모 콘트롤은 매치메이커(1510)에 의해 평가되어 사용자가 단지 적절한 MSI 및 같은 나이의 다른 사용자와 매치되는 것을 보장할 수 있다.
매치메이커 서비스(111)는 데이터 서비스(100) 내에서 관리되는 하나 이상의 데이터베이스들(예를 들어, 도 19와 관련하여 후술되는 데이터베이스(1920) 참조)로부터 전술한 변수들 중 임의의 변수를 검색할 수 있다. 예를 들어, 사용자의 친구 데이터는 친구 서비스 데이터베이스로부터 액세스될 수 있으며, 각각의 사용자의 나이, 성, 게임 컬렉션 등과 같은 다른 정보는 하나 이상의 다른 데이터베이스들(예를 들어, 사용자 프로파일, 게임 데이터베이스, 리더 보드 데이터베이스 등)로부터 액세스될 수 있다. 일 실시예에 있어서, 본 명세서에 기술된 모든 서비스들에는, 매치메이킹을 결정하는데 이용되는 각종 상이한 타입의 사용자/디바이스 데이터를 모두 저장하기 위한 동일한 중앙 데이터베이스(또는 데이터베이스들의 그룹)에 대한 액세스가 제공될 수 있다.
수개의 특정예들이 상기에 제공되지만, 본 발명의 기본 원리들은 매치에 대한 피트니스 레벨(fitness level)을 결정하기 위한 임의의 특정 변수들의 세트에 제한되지는 않는다는 것이 인식될 것이다. 일 실시예에 있어서, 본 명세서에 기술된 방법 및 시스템 상에서 실행되는 어플리케이션들을 설계하는 어플리케이션 프로그래머들은 상이한 MSI 기준들을 이용하여 요청들을 그룹화하고/하거나 매치하기 위한 고유의 기준 세트를 지정할 수 있다.
도 18의 방법을 다시 참조하면, 일단 각 쌍 사이의 매치 "피트"가 결정되었으면, 1803에서, 쌍들은 피트를 내림차순함으로써 분류된다(예를 들어, 쌍들은 리스트의 상부에 최고 피트를 가짐). 1804에서, 지정된 임계값보다 큰 최고 피트 값들을 갖는 쌍들이 "매치 세트들"에 시딩된다(seeded). 전술한 바와 같이, "임계" 값은 테이블 A에서 전술한 1.0의 정규화된 값으로 설정될 수 있다. 1805에서, 지정된 임계값보다 큰 매치 세트에서의 현재의 멤버들 중 하나 또는 이들 모두와의 피트 값들을 갖는 새로운 장래 파트너들이 매치 세트에 추가된다. 예를 들어, 매치 세트가 초기에 A 및 B에 대해 시딩된 경우, A-C 및/또는 B-C의 피트 값이 지정된 임계값보다 크다면 매치 세트에 C가 추가될 수 있다. 일 실시예에 있어서, 단일 매치 파티만이 장래 파티에 대한 임계값보다 큰 경우, 그 파티가 매치 세트에 추가될 수 있다(즉, 그 이유는 필요한 경우에 그 파티가 적합한 매치 피트를 갖는 하나의 파티를 통해 모든 파티와 통신가능할 것이기 때문이다). 일단 매치 세트에 하나 이상의 새로운 파티들이 추가되었으면, 1806에서 매치에 대한 사이즈 요구조건들이 충족되었다고 결정되는 경우, (예를 들어, 전술한 바와 같이 요청 테이블(1502)을 업데이트하며 통지를 송신함으로써) 1807에서 매치 결과들이 저장되며 보고된다. 일 실시예에 있어서, (예를 들어 매치 요청이 후술하는 바와 같이 초대 시퀀스를 뒤따르는 경우) 단일 매치 요청은 다수의 사용자들을 표현할 수 있다. 이 경우, 사이즈 요구조건들은 각각의 매치 요청에 의해 표현된 사용자들의 수에 기초하여 평가된다. 사이즈 요구조건들이 충족되지 않은 경우, 프로세스는 1805로 복귀하여, 새로운 파티(즉, 지정된 임계값보다 큰 세트의 현재의 멤버들 중 하나 이상과의 매치 피트를 갖는 파티)가 매치 세트에 추가된다.
1808에서, 매치된 요청들은 매치메이커(1510)에 의해 처리되는 현재의 요청들의 세트로부터 제거될 수 있다. 1809에서, 다음의 시딩된 매치 세트가 선택되며, 프로세스는 추가 매칭을 위해 1804로 복귀한다. 순차적인 프로세스로서 도 18에 도시되어 있지만, 다수의 시딩된 매치 세트들은 여전히 본 발명의 기본 원리들에 따르면서 동시에 처리될 수 있다는 것에 유의해야 한다.
개별적인 서비스들로 전술하였지만, 매치메이커 서비스(111) 및 초대 서비스(112)는 P2P 사용자들을 접속시키기 위해서 함께 동작할 수 있다. 예를 들어, 일 실시예에 있어서, 제1 사용자는 1명 이상의 친구들을 온라인 세션에 초대하고, 1명 이상의 추가 사용자들과의 매치를 요청할 수 있다(예를 들어, 친구 "Bob" INVITE 및 멀티레이어 비디오 게임에 대한 3명의 추가 플레이어들의 매치). 이러한 경우, 초대 서비스(112)는 초기에 제1 사용자의 초대 요청을 처리하여, 제1 사용자와 제1 사용자의 친구(들)를 접속시킬 수 있다. 그런 다음, 초대 요청의 결과(예를 들어, 성공적인 P2P 접속)가 사용자의 모바일 디바이스로 보고될 수 있다. 그런 다음, 매치메이킹 서비스(111)는 제1 사용자의 모바일 디바이스로부터(또는 일 실시예에 있어서 직접적으로 초대 서비스로부터 또는 제1 사용자의 친구들로부터) 추가 플레이어들을 요청하는 매치 요청을 수신할 수 있다. 이에 응답하여, 매치메이커 서비스(111)는 (전술한 바와 같이) 제1 사용자의 요청과 동일한 MSI를 갖는 하나 이상의 다른 매치 요청들과 제1 사용자를 매치할 수 있다. 매치 요청은 제1 사용자의 매칭 기준들만을 포함할 수 있거나, 또는 제1 사용자의 매칭 기준들 및 제1 사용자의 친구들의 매칭 기준들(예를 들어, NAT 타입, 접속 타입, 언어, 위치 등)을 포함할 수 있다. 일 실시예에 있어서, 제1 사용자의 친구들 중 1명 이상이 다른 매치된 사용자와 직접 P2P 접속을 확립할 수 없는 경우, 제1 사용자의 친구들과의 매치된 사용자의 접속은 제1 사용자의 데이터 처리 디바이스를 통해 (예를 들어, 접속을 위한 프록시로서 제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)의 설계는 네트워크 서비스들(1901-1903) 및 프레임워크(1912)의 개발자에 의해 제공된 소프트웨어 개발 키트("SDK")를 이용하여 용이해질 수 있다. 프레임워크(1912) 및 API들(1910, 1913)의 보다 상세한 구현은 도 20과 관련하여 후술된다.
도시된 바와 같이, 서비스들 각각은 서비스들에 의해 사용되는 데이터를 저장하기 위한 데이터베이스(1920)로의 액세스를 구비할 수 있다. 일 특정 실시예는 매치메이커 서비스(111)(상술됨)에 의해 사용된 데이터베이스(1512)이다. 다른 예들은 리더보드 데이터를 저장하기 위한 리더보드 데이터베이스, 친구 상태 레코드들을 저장하기 위한 친구 서비스 데이터베이스, 사용자 프로파일 데이터를 저장하기 위한 프로파일 데이터베이스, 및 온라인 게임들에 관한 데이터를 저장하기 위한 게임 데이터베이스를 포함할 수 있다. 데이터베이스의 임의의 타입(예를 들어, MySQL, 마이크로소프트 SQL 등)이 사용될 수 있으나, 일 특정 실시예에서 버클리 DB 및/또는 MZBasic DB와 같은 키/값 데이터베이스가 사용될 수 있다. 데이터베이스들은 SAN(Storage Area Network) 또는 다른 저장 구성에서 매우 많은 대용량 저장 디바이스들(예를 들어, 하드 드라이브)에 걸쳐 확산될 수 있다.
따라서, 특정 서비스가 상술한 바와 같이 데이터를 처리 및/또는 저장할 때, 데이터는 데이터베이스(1920) 내에 저장될 수 있다. 그러나, 몇몇 서비스는 데이터베이스를 활용하지 않을 수 있다. 예를 들어, 상술한 바와 같이, 초대 서비스(112)는 스테이트리스(stateless) 서비스로서 구현될 수 있고, 따라서, 데이터베이스(1920) 내에 데이터를 저장할 필요가 없을 수 있다(다만, 이러한 구현은 여전히 본 발명의 기본 원리에 따라서 가능함).
API(1913)는 예를 들어, 네트워크 층에서의 TCP/IP 또는 UDP/IP 및 응용 계층에서의 HTTPS를 포함하는 임의의 적합한 네트워크 프로토콜 스택을 이용하여 네트워크 서비스들(1901-1903)과 정보를 통신 및 교환하도록 설계될 수 있다. SOAP와 같은 HTTP 또는 HTTPS를 통한 원격 프로시저 호출(RPC)-기반 프로토콜이 사용될 수 있으며/있거나 REST(Representational State Transfer) 프로토콜이 사용될 수 있다. 또한, 서비스들은 예를 들어, Xserve, 또는 Unix, Linux를 실행하는 유사한 서버들을 포함하는 임의의 컴퓨팅 플랫폼, 또는 Apache 소프트웨어 플랫폼 상에서 구현될 수 있다. 일 특정 구현예에서, 플랫폼은 리눅스 상에서 구현된 웹 오브젝트들을 포함한다. 상술한 예들은 단지 설명을 위해 제공된다. 본 발명의 기본 원리는 어플리케이션들을 서비스들에 링크시키기 위한 임의의 특정 매커니즘이나 임의의 특정 네트워크 프로토콜 집합으로 제한되지 않는다.
도 20은 본 발명의 일 실시예에서 무선 디바이스(120) 상에서 구현될 수 있는 어플리케이션 프로그래밍 인터페이스(API)(2001a-b)를 포함하는 더 상세한 소프트웨어 아티텍처를 도시한다. 본 실시예는 멀티-플레이어 게임 프레임워크(2000)의 문맥 내에서 설명되지만, 본 발명의 기본 원리는 게이밍 구현으로 제한되지 않는다. 예를 들어, 도 20에 도시된 소프트웨어 아키텍처는 게임이 아닌 다양한 공동의 어플리케이션(예를 들어, 공동 채팅, 다자간(multi-party) 공동 오디오/비디오 등) 을 지원하기 위해 사용될 수 있다.
도 20에 도시된 아키텍처에서, 게임 프레임워크(2000)는 여기에 설명된 다양한 다자간 특징들 및 P2P 특징들을 지원하기 위해 제공된다. 일 실시예에서, 게임 프레임워크(2000)는 모바일 디바이스의 운영 체제(2005) 상에서 실행하도록 설계된다. 예를 들어, 모바일 디바이스(120)가 iPhone, iPad 또는 iPod Touch라면, 운영 체제(2005)는 본 출원의 양수인에 의해 고안된 모바일 운영 체제인 iPhone OS일 수 있다.
게임 프레임워크(2000)는 퍼블릭 어플리케이션 프로그래밍 인터페이스(API)(2001b) 및 프라이빗 또는 "보안" API(2001a)를 포함할 수 있다. 일 실시예에서, 여기에 설명된 다양한 게임-관련 특징들을 제공하기 위해 설계된 게임 센터 어플리케이션(2031)은 퍼블릭 API(2001b) 및 프라이빗 API(2001a) 둘 다에 대해 호출을 할 수 있지만, 다른 어플리케이션들(2030)(예를 들어, 제3자에 의해 설계된 어플리케이션들)은 퍼블릭 API(2001b)로의 액세스만을 제공받는다. 예를 들어, 모바일 디바이스(120)의 설계자는 제3자 개발자들에 의한 남용(예를 들어, 친구 요청, 친구 리스트 등)을 회피하기 위해 잠재적으로 민감한 정보를 포함하는 특정 API 기능들을 퍼블릭 API(2001b)로부터 보호하고 싶어할 수 있다. 그러나, 보안 API(2001a) 및 퍼블릭 API(2001b) 둘 다는 모바일 디바이스 상의 모든 어플리케이션들에 의해 액세스가능한 단일 API로 병합될 수 있다(즉, 본 발명의 기본 원리에 따르기 위해 API를 별도의 퍼블릭 및 프라이빗 컴포넌트로 구분할 필요는 없다). 설계 "API2001"는 때때로 이하에서, 퍼블릭 API(2001b) 및/또는 프라이빗 API(2001a)에서 발견할 수 있는 동작들을 지칭하는 데에 사용된다.
게임 센터 어플리케이션(2031)의 일 실시예는, 2010년 4월 7일에 출원하고 발명자가 마셀 반 오스 및 마이크 램펠이며, 발명의 명칭이 Systems and Methods for Providing a Game Center인 출원 번호 제________________호(대리인 사건 번호 4860.P9127USP1)(이하, "게임 센터 특허 어플리케이션")의 공동계류 출원에서 설명되며, 이 출원은 본 출원의 양수인에게 양도되고 여기에 참조로서 포함된다. 간략하게, 게임 센터 어플리케이션(2031)은 멀티-플레이어 게임들을 네비게이트하고; 새로운 게임들을 구매하고; 게임에 관한 정보(예를 들어, 리더보드 정보, 성과, 친구 정보 등)를 검색하고; 게임을 할 친구들에게 연락하고; 다른 사용자들과의 게임 매치를 요청하고; 특정 사용자들을 초대하기 위한 게임-중심의 그래픽 사용자 인터페이스(GUI)를 포함한다. 게임 센터 어플리케이션(2031)에 의해 수행되는 다양한 다른 기능들은 위에서 참조된 게임 센터 특허 출원에서 설명된다. 게임 센터 기능들 중 몇몇은 게임 프레임워크(2000)에 의해 제공될 수 있고 퍼블릭 API(2001b)를 통해 다른 어플리케이션들(2030)에 액세스가능해질 수 있다.
일 실시예에서, 게임 프레임워크(2000)에 의해 노출된 API(2001)는 모바일 디바이스(120)에 대한 멀티-플레이어의 공동 게임들을 설계하는 프로세스를 간단하게 한다. 특히, 일 실시예에서, API(2001)는 개발자들로 하여금, 멀티-플레이어의 P2P 게임 세션을 위해 사용자들을 접속시키는 비교적 복잡한 프로세스를 인보크하기 위해 간단한 API 호출을 하게 한다. 예를 들어, API(2001)로부터 INVITE (플레이어 B ID, 버킷 ID)와 같은 간단한 API 호출이 인보크되어, 상술된 상세한 초대 시퀀스를 개시할 수 있다. 마찬가지로, API(2001)로부터 MATCH(플레이어 A ID, 버킷 ID)와 같은 API 호출이 인보크되어, 상술된 상세한 매치메이킹 시퀀스를 개시할 수 있다. INVITE 및 MATCH 기능은 여기서, 때때로 일반적으로 "P2P 접속 기능"으로서 지칭된다. 일 실시예에서, 게임 프레임워크(2000)는 이들 API 호출에 응답하여 초대를 관리하고 동작들을 매치메이킹하는 데에 필요한 프로그램 코드를 포함한다(이하에 더 상세히 설명됨). 실제 API 기능은 상술한 것과는 다소 다른 데이터 포맷을 가질 수 있음을 유념한다(그러나, 이들은 게임 프레임워크(2000)에 의해 수행된 유사한 동작들로 귀결됨). 본 발명의 기본 원리는 API 기능을 특정하기 위한 임의의 특정 포맷으로 제한되지 않는다.
게임 관련 트랜젝션 및 정보의 다양한 다른 타입도 게임 센터(2031) 및 다른 어플리케이션(2030)을 대신하여 게임 프레임워크(2000)에 의해 관리될 수 있다. 이 정보 중 몇몇은 게임 센터 특허 출원에서 설명된다. 제한이 아닌 일례로서, 이 정보는 각각의 게임에 대해 최고 스코어를 획득한 사용자들에 관한 "리더보드" 정보, 및 특정 게임-지정 성과를 완수한 사용자들을 식별하는 "성과" 정보를 포함할 수 있다. 각각의 어플리케이션 개발자는 각각의 게임 어플리케이션(2030)에 대한 자신의 "성과" 세트(예를 들어, 레벨 1-3 완수; 5분 내에 레벨 1을 완수; 레벨 당 50 초과의 킬; 20개의 플래그를 쓰러뜨림)를 지정할 수 있다.
게임 프레임워크(2000)는 또한 사용자의 프랜드 데이터를 관리하고 게임 센터(2031) 및 다른 게이밍 어플리케이션(2030)의 컨텍스트 내로 프랜드 데이터를 통합하기 위한 프로그램 코드를 포함할 수 있다. 예를 들면, 사용자가 게임 센터(2031) 내의 특정 게임에 대한 링크를 선택한다면, 해당 게임에 대한 사용자의 프랜드들 각각에 관련된 정보(예를 들면, 리더보드(leaderboard) 상에서의 프랜드 순위, 프랜드의 성과, 사용자가 자신의 프랜드들과 각각 게임을 하였을때의 결과)가 디스플레이될 수 있다. 일 실시예에서, 게임 프레임워크(2000)의 API(2001)는 2010년 4월 7일에 출원되고, 발명자가 Amol Pattekar, Jeremy Werner, Patrick Gates, and Andrew H. Vyrros이며 , 발명의 명칭이 "Apparatus and Method for Efficiently Managing Data in a Social Networking Service"인 공동-계류중인 특허 출원 제___호 (대리인 정리 번호 4860.P9240) (이하, "프랜드 서비스 어플리케이션(Friend Service Application)") (본원 출원의 양수인에게 양도된 상기 출원은 본원에 참조로서 포함되는 것으로 한다)에 기술되어 있는 것과 같은 프랜드 서비스에 의해 관리되는 프랜드 데이터를 액세스하기 위한 기능을 포함한다.
도 20에 도시된 바와 같이, 일 실시예에서, 게임 데몬(2020)은 게임 프레임워크(2000)를 제1 서비스 세트(2050)에 인터페이싱할 수 있고 게임 서비스 컴포넌트(2010)는 게임 프레임워크(2000)를 제2 서비스 세트(2051)에 인터페이싱할 수 있다. 예로서, 제1 서비스 세트(2050)는 상술한 초대 서비스(112), 매치메이커 서비스(111) 및 릴레이 서비스(1051)와, 상기의 참조된 프랜드 서비스 어플리케이션에 기술된 프랜드 서비스를 포함할 수 있다. 데임 데몬(2020)을 통해 액세스될 수 있는 다른 서비스로는 (리더보드 데이터를 제공하는) 리더보드 서비스; (게임 구매 능력 및 게임 각각에 관련된 통계적 및 기타 데이터를 제공하는) 게임 서비스; (모바일 디바이스의 사용자를 인증하기 위한) 사용자 인증 서비스; 및/또는 (사용자 선호도 등의 사용자 프로파일 데이터를 저장하기 위한) 사용자 프로파일 서비스를 포함한다. 게임 서비스 컴포넌트(2010)를 통해 액세스되는 제2 서비스 세트(2051)는 상술한 접속 데이터 교환(connection data exchange; CDX) 서비스(110) 및 NAT 통과(traversal) 서비스(290-291)를 포함할 수 있다. 예시를 위하여 도 20에서는 개별적인 컴포넌트로서 도시되었지만, 실제로 게임 데몬(2020)과 게임 서비스 모듈(2010)은 게임 프레임워크(2000)의 컴포넌트일 수 있다. 일 실시예에서, 게임 데몬(2020 및 2010)은 미리정해진 API를 통하여 각각의 네트워크 서비스(2050-2051)와 통신하는데, 일 실시예에서, 이 미리정해진 API는 프리이빗(private; 제3자인 개발자에게 공개되지 않는) API이다.
일 실시예에서, 게임 데몬(2020)은 HTTPS 프로토콜을 이용하여 매치메이커 서비스(111), 초대 서비스(112) 및 기타 서비스(2050)와 통신할 수 있는 한편, 게임 서비스 모듈(2010)은 UDP 소켓들과 같은 비교적 경량의(lightweight) 프로토콜을 이용하여 CDX 서비스(110) 및 NAT 통과 서비스(290-291)와 통신할 수 있다. 그러나, 앞서 언급한 바와 같이, 본원 발명의 기본적인 원칙에 따르는 것이라면 각종 기타 네트워크 프로토콜도 채용될 수 있다.
그 외에도, 도 20에 도시된 바와 같이, 게임 데몬(2020)은 특정 서비스(2052)(예를 들어, 초대 서비스 및 매치메이커 서비스)에 의해 생성된 푸시 통지(2052)를 수신할 수 있지만, 그 외의 타입의 푸시 통지(2053)(예를 들어, 새로운 프랜드 요청과 같은 프랜드 서비스 통지)가 게임 센서에 의해 직접 수신될 수 있다. 일 실시예에서, 푸시 통지(2053)는 게임 센터(2031)에 의해 직접 제공되어 사용자의 민감한 데이터가 제3자인 어플리케이션 개발자에 의해 설계된 어플리케이션(2030)에 액세스될 수 없도록 함을 보장한다.
도 11에 관련하여 상술한 게임 초대 예시들을 다시 참조해보면, 모바일 디바이스 A 상의 어플리케이션(2030)이 모바일 디바이스 B의 사용자를 초대하기 위하여 게임 프레임워크(2000)의 API(2001b)에 대한 초대 호출(예를 들면, INVITE (Player B ID, Game/Bucket ID))을 생성하면, 게임 프레임워크(2000)는 모바일 디바이스 A의 게임 데몬(2020)에 이 초대 요청을 전달할 수 있다. 그러면 게임 데몬(2020)은 초대 서비스(112)와 통신하여 초대 요청을 전송할 수 있다. 그 다음 초대 서비스(112)는 (앞서 설명한) 푸시 통지 서비스(1050)를 이용하여 모바일 디바이스 B의 게임 데몬(2020)에 대한 초대를 푸시한다. 그 다음 모바일 디바이스 B의 게임 데몬(2020)은 모바일 디바이스 B의 게임 프레임워크(2000)와 통신하여 초대 송신의 대상이 되는 게임이 모바일 디바이스 B 상에 설치되었는지를 판정할 수 있다. 게임이 모바일 디바이스 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)는 요청 어플리케이션(2030)에 (API(2001)를 통해) 모바일 디바이스 B가 수락되었음을 통지하거나 디바이스가 성공적으로 접속될 때까지 요청 어플리케이션(2030)에 통지하기를 기다릴 수 있다. 어느 경우라도, 게임 프레임워크(2000)는 게임 서비스 모듈(2010)에 접속 요청을 전달하는데, 일 실시예에서, 이 게임 서비스 모듈(2010)은 모바일 디바이스 B와의 접속 데이터 교환을 개시할 수 있다. 구체적으로, 게임 서비스 모듈은 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)는 접속을 요청한 어플리케이션(2030)에게 API 호출을 이용하여 통지할 수 있다(예를 들면, CONNECTED (플레이어 A ID, 플레이어 B ID)). 모바일 디바이스 A 및 B는 그 후 구축된 접속을 이용하여 특화된 게임 또는 기타 협업적 어플리케이션(2030)을 플레이할 수 있다.
따라서, API(2001)로부터의 상대적으로 단순한 호출에 응답하여(예를 들면, INVITE 플레이어 B ID, 게임/버킷 ID), 게임 프레임워크(2000)에 의해 복잡한 시리즈의 트랜젝션이 관리되어 모바일 디바이스 A와 B 사이의 P2P 또는 릴레이 접속을 구축할 수 있다. 일 실시예에서, 게임 프레임워크(2000)는 모바일 디바이스 A와 B를 접속하는 동작의 시퀀스를 수행하고, 그 후 요청 에플리케이션(2030)에 결과를 제공함으로써, API 호출 트랜젝션의 디테일을 어플리케이션 설계자에게 맡긴다. 이와 같이, 어플리케이션 설계자는 네트워크 상에서 모바일 디바이스 A와 B를 접속하는 방법을 이해하거나, 디바이스들 간의 통신을 가능하게 하는 데 필요한 각종 다른 기능을 수행하도록 요구되지 않어서, 어플리케이션 설계 프로세스를 단순화한다.
유사한 방식으로, 게임 프레임워크(2000)는 도 2a-b에 관하여 상술한 바와 같이, 매치메이커 서비스(111)를 이용하여 모바일 디바이스 A와 다른 참가자(participants) 간에 매칭을 구축할 수 있다. 이 예시에서, 어플리케이션(2030)은 API(2001)에 MATCH(플레이어 A ID, 게임/번들 ID)와 같은 단순한 호출을 할 수 있다. 응답하여, 게임 프레임워크(2000)는 매칭 및 접속 데이터 교환 동작을 관리할 수 있다. 매칭 동작들 및/또는 P2P 접속들이 완료되면, 게임 프레임워크(2000)는 결과를 어플리케이션(2030)에 다시 제공한다.
예를 들면, 도 2b에서, 게임 프레임워크(2000)는 게임 서비스 모듈(2010)을 사용하여 접속 데이터 교환(CDX) 서비스(110) 및 NAT 통과 서비스(290-291)와 통신할 수 있고 게임 데몬을 사용하여 매치메이커 서비스(111)와 통신할 수 있다. 매치가 이루어지면, 모바일 디바이스 A의 게임 데몬(2020)은 229에서 티켓 A를 수신하고 게임 프레임워크(2000)는 이 정보를 사용하여 게임 서비스 모듈(2010)을 통해 접속 데이터 교환을 구현한다. 예를 들면, 232에서, NAT 통과 서비스(290)를 통해 자신 소유의 접속 데이터를 요청할 수 있고 233-234에서 CDX 서비스(110)를 통해 그것의 접속 데이터를 교환할 수 있다. 237 및 240에서, 모바일 디바이스 A의 게임 서비스 모듈(2010)은 모바일 디바이스 B와 C 각각에 대한 접속 데이터를 수신한다. 이들 교환에 이어서, 게임 서비스 모듈(2010)은 241에서 P2P 접속을 구축하고 게임 프레임워크(2000)는 어플리케이션(2030)에게 접속 프로세스가 완료되었다고 API 통지를 이용하여 보고한다(예를 들면, MATCH COMPLETE (플레이어 B ID, 플레이어 C ID)). 그 후 어플리케이션은 구축된 P2P 접속을 사용하여 실행될 수 있다.
몇몇 실시예에서, 현재 "온라인"으로 등록된 다른 친구들과 게임을 플레이하는 옵션이 사용자에게 주어질 수 있다. 이 경우에, 특정 친구들이 온라인이라는 통지는 푸시 통지(2052) 또는 (게임 센터(2031)에 의해 직접 수신된) 푸시 통지(2053)를 통해 제공될 수 있다. 게임 센터(2031) 및/또는 어플리케이션(2030)은 그 후 사용자에게 통지를 제공할 수 있고 사용자에게 한명 이상의 선택된 온라인 친구들와 플레이하는 옵션을 제공할 수 있다. 그러나, 온라인 통지가 제공되는지의 여부에 관계없이 본원에 설명된 초대 시퀀스가 작동할 것임이 이해되어야 한다. 일 실시예에서, 게임 데몬(2020)에 의해 액세스가능한 서비스에 의해(예를 들면, 상술한 친구 서비스에 의해 또는 별도의 "프레즌스(presence)" 서비스에 의해) 사용자의 온라인 상태가 모니터링될 수 있다.
게임 프레임워크(2000)의 일 실시예는 사용자가 미상의 매칭된 참가자들의 그룹과 함께 게임을 플레이하자고 한명 이상의 친구를 초대할 수 있는 조합 초대/매치메이킹 동작을 준비한다. 예를 들면, 게임이 4명의 플레이어를 요구하고 사용자가 게임을 플레이할 두번째 사용자를 초대한 경우, 초대 서비스(112)는 제1 사용자와 제2 사용자를 매치케이킹 서비스(111)와 초기에 접속하고 난 후 제1 사용자와 제2 사용자는 두명의(또는 둘보다 많은) 다른 플레이어와 매치할 수 있다. 이 실시예에서, 게임 프레임워크(2000)는 상술한 초대 시퀀스를 초기에 수행하여 제1 사용자와 제2 사용자를 접속할 수 있다. 일 실시예에서, 제1 사용자와 제2 사용자가 성공적으로 접속되면, 게임 프레임워크(2000)는 매치메이킹 시퀀스를 구현하여 다른 사용자들을 식별하고 그들과 접속할 수 있다. 일 실시예에서, 매치메이킹 서비스에 의해 적용되는 상술한 매칭 기준은 제1 사용자와 제2 사용자 양쪽을 포함할 수 있다(예를 들면, 제1 사용자와 제2 사용자 양쪽의 NAT 타입, 접속 타입, 언어 등). 대안적으로는, 매칭 결정을 내리는 데 두 사용자들 중 한쪽의 기준이 평가될 수 있다.
사용자들이 모두 접속되면, 게임 프레임워크(2000)는 API(2001)를 통해 접속을 요청한 어플리케이션(2030)에 접속 결과를 제공할 수 있다. 또한 어플리케이션(2030)에 의한 상대적으로 단순한 API 호출에 응답하여, 게임 프레임워크(2000)가 복잡한 트랜젝션의 세트에 진입하여 디바이스들 각각을 접속한다. 디바이스들이 성공적으로 접속되면, 게임 프레임워크(2000)는 요청 어플리케이션(2030)에 결과를 다시 제공한다.
도 20에 도시된 바와 같이, 게임 프레임워크(2000)는 사용자와 다른 게임 참가자들 사이의 통신을 일시적으로 저장하기 위해 통신 버퍼(2003)를 포함할 수 있다. 예를 들면, 통신은 텍스트, 오디오 및/또는 비디오 통신을 포함할 수 있다. 게임 프레임워크(2000)는 각 어플리케이션(2030)의 요건에 기초하여 버퍼(2003)를 구축할 수 있다. 예를 들면, 느린 네트워크 접속을 이용한 오디오/비디오 통신에 대해 상대적으로 더 큰 버퍼(2003)가 요구될 수 있다. 일 실시예에서, 각 어플리케이션(2030)은 API(2001)를 통해(예를 들면, 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 코드와 매칭되는 경우, 그 데이터는 여전히 유효하며, 업데이트될 필요가 없다. 그 후, 캐시 내이 데이터가 현재임을 나타내는 응답이 상기 서비스로부터 반송될 수 있고, 데이터 기록에 대한 TTL 값이 재설정될 수 있다.
전술한 바와 같은 캐시 관리 정책을 이용하는 것 외에, 일 실시예에서, 푸시 통지 서비스(1050)를 이용하여 특정 타입의 데이터에 대한 캐시 업데이트들이 모바일 디바이스에 푸싱될 수 있다. 예를 들어, 사용자의 친구 리스트 또는 사용자 친구의 현재 온라인 상태로의 변경들은 사용자의 모바일 디바이스(120)에 동적으로 푸싱될 수 있다. 푸시 통지는 게임 데몬(2020)에 의해 수신될 수 있으며, 그 후 서비스에 의해 푸싱된 데이터의 관련 부분을 포함하도록 캐시(2021)를 업데이트할 수 있다(즉, 그 서비스와 연관된 캐시 내의 데이터 모두에 대한 업데이트가 요구되지 않을 수 있다). 반면, 일부 푸시 통지는 게임 데몬(2020)으로 하여금 캐시의 콘텐츠 전체(또는 푸싱을 수행하는 서비스와 연관된 캐시의 적어도 일부분)를 오버라이트하도록 지시할 수 있다.
캐시(2021)를 업데이트하기 위해 푸시를 이용하는 이들 서비스들은, 캐시(2021) 내에 저장된 데이터를 업데이트 하라는 통지들을 푸싱하는 능력을 갖기 때문에 비교적 큰 TTL 값들을 선택할 수 있다(및/또는 TTL 값들을 설정하지 않을 수 있다). 일 실시예에서, 각각의 서비스는 푸시 통지 캐시 업데이트를 트리거할 수 있는 이벤트 세트를 지정한다. 예를 들어, 캐시 업데이트 이벤트들은 친구의 온라인 상태로의 변경, 새로운 친구의 요청, 친구 요청의 승낙, 친구 삭제 동작, 친구가 특정 게임을 하고 있다는 표시, 친구가 도달한 게임 성취도, 특정 리더보드의 상위 10위까지의 업데이트, 또는 캐시 업데이트를 보증하는 데 충분히 중요한 것으로 여겨지는 임의의 다른 이벤트들을 포함할 수 있다. 캐시(2021)를 이러한 방식으로 업데이트하라는 푸시 통지들을 이용하는 것은, 푸시 업데이트에 의해, 모바일 디바이스와 서비스 간의 주기적인 폴링이 요구되지 않기 때문에 네트워크 및 서비스의 로드를 감소시킬 수 있다.
게임 프레임워크(2000)의 일 실시예는 사용자의 지역 및/또는 지리적 위치에 기초하여 최종 사용자에게 제시되는 데이터를 고유하게 포맷한다. 예를 들어, 현재 날짜, 시각 등의 값들과 일시적인 값들은 사용자들에 대해 서로 다른 지역 및 위치에서 서로 다르게 제시될 수 있다. 예로서, 미국에서는 날짜 포맷이 [월일, 연도](예컨대, April 25, 2010)일 수 있는 반면, 다른 지역에서는, 날짜 포맷이 [일월, 연도](예컨대, 25 April, 2010)일 수 있다. 마찬가지로, US 및 일부 다른 지역에서 시각을 나타내는 경우, AM/PM 지정이 사용될 수 있으며, 시간과 분 사이에는 콜론이 사용될 수 있다(예컨대, 3:00 PM). 반면, 많은 다른 지역에서는 AM/PM 지정을 사용하지 않을 수 있으며, 그리고/또는 시간과 분 사이에 콤마를 사용할 수 있다(예컨대, 15,00). 다른 예로서, 세계의 수많은 지역에서는 메트릭 시스템을 사용하는 반면, 세계의 일부 지역에서는 이를 사용하지 않는다(예컨대, 미국). 이들은 단지 본 발명의 특정 실시예에 이용될 수 있는 설명을 위한 예시에 불과하다는 것을 유념해야 한다. 본 발명의 근본적인 이론은 임의의 특정 데이터 포맷 세트에 한정되지 않는다.
일 실시예에서, 리더보드 데이터, 성취 데이터, 친구 데이터 및/또는 게임 프레임워크(2000)에 의해 프로세싱되는 그외의 데이터를 디스플레이할 때, 이러한 상이한 데이터 포맷들이 선택될 수 있다. 게임 프레임워크(2000)는 사용자의 국가 및/또는 지리적 위치를 다양한 방식으로 판정할 수 있다. 예를 들어, 일 실시예에서, 이러한 정보는 단순하게 사용자의 프로파일에 제공되고/제공되거나 사용자의 무선 전화 서비스 제공자에 기초하여 판정될 수 있다. 사용자의 위치는 또한, 예를 들면, GPS(Global Positioning System) 추적을 이용하여 판정될 수 있다.
지리적 위치 및/또는 국가와 연관되지 않은 그외의 타입의 데이터 포맷팅은 또한 게임 프레임워크(2000)에 의해 관리될 수 있다. 예를 들어, 리더보드 데이터를 디스플레이하는 경우, 가장 낮은 점수가 사용자를 리더보드의 상단에 배치할지 또는 하단에 배치할지를 아는 것이 중요하다. 일부 게임들에 있어서(예를 들어, 골프, 트랙킹, 레이싱, 스키 등), 더 낮은 숫자가 더 나은 기록을 나타내는 한편, 다른 게임들에서(예를 들어, 풋볼, 베이스볼 등), 더 높은 숫자가 더 나은 기록을 나타낸다. 따라서, 일 실시예에서, 어플리케이션(2030)은 API(2001)를 통해 사용될 점수의 타입을 지정한다(예를 들면, 오름 차순(ascending), 내림 차순(descending)). 그리고 나서, 게임 프레임워크(2000)는 점수를 디스플레이하기 위한 적절한 세트의 레이블들 및 포맷팅을 사용할 수 있다.
게임 프레임워크(2000)의 일 실시예는 또한 사용자와 그 사용자의 "친구들" 사이의 관계에 기초하여 사용자 데이터를 필터링한다. 예를 들어, 본 발명의 일 실시예는 "상세" 보기("detailed" view), "친구들" 보기("friends" view), 및 "퍼블릭(public)" 보기를 허용한다. 일 실시예에서, 상세 보기는 데이터를 소유하는 사용자들에게 이용가능하고(즉, 사용자의 개인 정보), 친구들 보기는 사용자의 친구들에 대해 이용가능하고, 퍼블릭 보기는 그외의 모든 사용자에게 이용가능하다.
예로써, 퍼블릭 보기는 단순히 각각의 사용자와 연관된 "별명"("alias" name), 그 별명으로 플레이된 게임들 및 연관 점수들, 및 그 게임들이 플레이된 날짜/시간을 포함할 수 있다. 이러한 정보는 게임 프레임워크(2000)에 의해 사용되어 그 후에 게임 센터(2031)를 통해 디스플레이될 수 있는 퍼블릭 리더보드를 파퓰레이트할 수 있다.
친구들 보기는, 예를 들어, 사용자에게 소유된 게임들, 사용자에 의해 플레이된 게임들, 사용자의 성취 및 점수, 사용자가 얼마나 많은 친구를 갖고 있는지, 이러한 친구들에 대한 식별, 몇가지 예를 들면, 사용자의 온라인 상태 및/또는 사용자의 아바타들을 식별하는 URL을 포함하는, 사용자의 친구들 간에 공유되는 임의의 추가적인 정보뿐 아니라 일반적 보기로부터의 모든 정보를 포함할 수 있다. 일 실시예에서, "친구들" 보기는 친구들과 공유되는 디폴트 세트의 정보를 제공하지만, 종단 사용자는 이러한 디폴트 구성을 조정하고 각각의 개별 친구 또는 친구들의 그룹에 의해 공유되는 정보들의 타입을 특수성을 이용하여 지정할 수 있다(예를 들어, 동료들, 가족 멤버, 대학/고등학교 친구들 등).
"상세" 보기는 종단 사용자를 대신하여 다양한 서비스들(2050)에 의해 관리되는 임의의 그외의 정보들뿐 아니라 "퍼블릭" 및 "친구들" 보기들로부터의 모든 정보를 포함할 수 있다. 예로써, 이것은 사용자의 모든 프로파일 데이터, 사용자의 보편적으로 고유한 식별자(Universally Unique Identifier)("UUID")(본 명세서에서 때로는 "플레이어 아이디(Player ID)"로서 지칭됨), 플레이어 이름, 별명, 게임들의 수 및 게임들의 아이덴티티(identity), 사용자의 친구들, 사용자의 모든 성취 등을 포함할 수 있다.
일부 환경들에서, 어플리케이션(2030)은 각각의 사용자의 플레이어 아이디와 같이 각각의 사용자와 관련된 적은 양의 정보만을 요구할 수 있다. 예를 들어, 일 실시예에서, 매칭이 요구되는 경우, 게임 프레임워크(2000)는 초기에 각각의 플레이어의 아이디만을 요구할 수 있다. 매치메이커 서비스(상기 참조)에 의해 매칭이 이루어지면, 게임 프레임워크(2000)는 매칭된 임의의 사용자들이 친구들인지의 여부를 (예를 들어, 친구 서비스를 이용하는 통신을 통해 및/또는 사용자의 로컬 친구 데이터를 획득함으로써) 판정할 수 있다. 그렇다면, 그 후에, 게임 프레임워크(2000)는 추가적인 사용자 데이터를 검색하고 임의의 매칭된 친구들에 대한 그 데이터를 제공할 수 있다. 이런 방식으로, 게임 프레임워크(2000)는 각각의 사용자들 간의 관계 및 사용자들의 아이덴티티에 기초하여 정보를 필터링한다.
일 실시예에서, 게임 프레임워크(2000)는, 두명의 사용자가 친구 관계를 가지지 않을 경우, 제1 사용자와 제2 사용자 사이에 퍼블릭 보기를 초기에 제공한다. 그러나, 일 실시예에서, 게임 프레임워크(2000)는 제1 사용자가 제2 사용자에게 (예를 들어, 제2 사용자의 별명을 이용하여) 친구 요청을 송신하도록 허용한다. 친구 요청이 수락되면, 그 후에 게임 프레임워크(2000)는 사용자들 각각에게 추가적인 정보(예를 들어, 디폴트 "친구" 보기)를 제공할 것이다.
상이한 API 실시예들
일 실시예에서 구현된 API는, 상이한 소프트웨어 컴포넌트(이하, "API 호출 소프트웨어 컴포넌트")가 하나 이상의 기능들, 방법들, 프로시저들, 데이터 구조들, 및/또는 API 구현 소프트웨어 컴포넌트에 의해 제공되는 그외의 서비스들에 액세스하고 이용하게 하는 소프트웨어 컴포넌트(이하, "API 구현 소프트웨어 컴포넌트")에 의해 구현된 인터페이스이다. 예를 들어, API는 (서드 파티 개발자일 수 있는) API 호출 소프트웨어 컴포넌트의 개발자가 API 구현 소프트웨어 컴포넌트에 의해 제공된 지정된 특징들에 영향을 주는 것을 허용한다. 하나의 API 호출 소프트웨어 컴포넌트 또는 하나보다 많은 그러한 소프트웨어 컴포넌트가 존재할 수 있다. API는 컴퓨터 시스템 또는 프로그램 라이브러리가 소프트웨어 어플리케이션으로부터의 서비스 요청들을 지원하기 위해 제공하는 소스 코드 인터페이스일 수 있다. API는 메모리에 데이터가 놓이는(laid out) 방식에 대한 명확한 저 수준 기술(description)이라기보다는, 어플리케이션이 구축될 때 인터프리터형(interpretative)이거나 컴파일형(compiled)일 수 있다.
API는, API 호출 소프트웨어 컴포넌트들이 API 구현 소프트웨어 컴포넌트의 지정된 특징들을 액세스하고 이용하는 경우에 이용하는 언어 및 파라미터들을 정의한다. 예를 들어,API 호출 소프트웨어 컴포넌트는 API에 의해 노출된 하나 이상의 API 호출(때로는 기능 또는 메소드 호출이라고 지칭함)을 통해 API 구현 소프트웨어 컴포넌트의 지정된 특징들을 액세스한다. API 구현 소프트웨어 컴포넌트는 API 호출 소프트웨어 컴포넌트로부터의 API 호출에 응답하여 API를 통해 값을 반환할 수 있다. API가 API 호출의 신택스(syntax) 및 결과(예를 들어, API 호출을 인보크하는 방식 및 API 호출이 하는 일)를 정의하지만, API는 통상적으로 API 호출에 의해 지정된 기능을 API 호출이 어떻게 달성하는지 드러내지 않는다. 다양한 기능 호출 또는 메시지들이 호출 소프트웨어(API 호출 소프트웨어 컴포넌트)와 API 구현 소프트웨어 컴포넌트 간의 하나 이상의 어플리케이션 프로그래밍 인터페이스를 통해 전달된다. 기능 호출들 또는 메시지들을 전달하는 것은 발행(issuing), 개시(initiating), 인보크(invoking), 호출(calling), 수신(receiving), 반환(returning) 또는 기능 호출들 또는 메시지들에 대한 응답(responding)을 포함할 수 있다. 따라서, 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 호출 소프트웨어 컴포넌트 사이의 호출들 및 반환들을 변환하는(translating) 특징들을 포함할 수 있음)하게 할 수 있지만, API는 특정 프로그래밍 언어의 관점에서 구현될 수 있다.
도 21은 API(2120)를 구현하는 API 구현 소프트웨어 컴포넌트(2110)(예를 들어, 운영 체제, 라이브러리, 디바이스 드라이버, API, 어플리케이션 프로그램, 또는 다른 소프트웨어 모듈)를 포함하는 API 아키텍처의 일 실시예를 도시한다. API(2120)는 하나 이상의 기능, 방법, 클래스, 오브젝트, 프로토콜, 데이터 구조, 포맷 및/또는 API 호출 소프트웨어 컴포넌트(2130)에 의해 사용될 수 있는 API 구현 소프트웨어 컴포넌트의 다른 특징들을 특정한다. API(2120)는, API 구현 소프트웨어 컴포넌트의 함수가 API 호출 소프트웨어 컴포넌트로부터 어떻게 파라미터들을 수신하는지 및 함수가 API 호출 소프트웨어 컴포넌트로 결과를 어떻게 리턴하는지를 특정하는 적어도 하나의 호출 컨벤션을 특정할 수 있다. API 호출 소프트웨어 컴포넌트(2130)(예를 들어, 운영 체제, 라이브러리, 디바이스 드라이버, API, 어플리케이션 프로그램, 또는 다른 소프트웨어 모듈)는, API(2120)를 통한 API 호출들이 API(2120)에 의해 특정되는 API 구현 소프트웨어 컴포넌트(2110)의 특징들을 액세스하고 사용하게 한다. 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)는 머신 판독가능한 매체에 저장될 수 있고, 머신 판독가능한 매체는 정보를 머신(예를 들어, 컴퓨터 또는 다른 데이터 프로세싱 시스템)에 의해 판독가능한 형태로 저장하기 위한 임의의 메카니즘을 포함한다. 예를 들어, 머신 판독가능한 매체는 자기 디스크, 광 디스크, 랜덤 액세스 메모리(random access memory), 판독 전용 메모리(read only memory), 플래쉬 메모리 디바이스 등을 포함한다.
도 22("소프트웨어 스택")에서, 예시적인 실시예, 어플리케이션들은 몇몇의 서비스 API들을 사용하여 서비스 1 또는 서비스 2에 호출할 수 있고, 몇몇의 OS API들을 사용하여 운영 체제(OS)에 호출할 수 있다. 서비스 1 및 서비스 2는 몇몇의 OS API들을 사용하여 OS에 호출할 수 있다.
서비스 2는 2개의 API들을 갖고, 이중 하나(서비스 2 API 1)는 어플리케이션 1로부터 호출들을 접수하고 어플리케이션 1로 값들을 리턴하고, 다른 하나(서비스 2 API 2)는 어플리케이션 2로부터 호출들을 접수하고 어플리케이션 2로 값들을 리턴한다는 것에 유의한다. (예를 들어, 소프트웨어 라이브러리일 수 있는) 서비스 1은 OS API 1에 호출하여 OS API 1로부터 리턴 값들을 수신하고, (예를 들어, 소프트웨어 라이브러리일 수 있는) 서비스 2는 OS API 1 및 OS API 2 모두에 호출하여 이들 모두로부터 리턴 값들을 수신한다. 어플리케이션 2는 OS API 2에 호출하여 OS API 2로부터 리턴 값들을 수신한다.
예시적인 데이터 프로세싱 디바이스들
도 23은 본 발명의 일부의 실시예들에 사용될 수 있는 예시적인 컴퓨터 시스템을 도시하는 블록도이다. 도 23은 컴퓨터 시스템의 다양한 컴포넌트들을 도시하는 한편, 그 세부사항들이 본 발명과 밀접한 관계가 있지 않은 컴포넌트들을 상호접속하는 임의의 특정한 아키텍처 또는 방식을 나타내도록 의도되지 않는다는 것을 이해해야 한다. 더 적은 컴포넌트들 또는 더 많은 컴포넌트들을 갖는 다른 컴퓨터 시스템들이 또한 본 발명과 함께 사용될 수 있다는 것이 인식될 것이다.
도 23에 도시된 바와 같이, 데이터 프로세싱 시스템의 형태인 컴퓨터 시스템(2300)은, 프로세싱 시스템(2320)과 함께 결합되는 버스(들)(2350), 전원(2325), 메모리(2330) 및 비휘발성 메모리(2340)(예를 들어, 하드 드라이브, 플래쉬 메모리, PCM(Phase-Change Memory) 등)를 포함한다. 버스(들)(2350)는 본 기술 분야에 공지된 다양한 브리지, 콘트롤러 및/또는 어댑터를 통해 서로 접속될 수 있다. 프로세싱 시스템(2320)은 메모리(2330) 및/또는 비휘발성 메모리(2340)로부터 명령어(들)를 검색하고, 명령어들을 실행하여 전술된 동작들을 수행할 수 있다. 버스(2350)는 상기 컴포넌트들을 함께 상호접속하고, 또한 이 컴포넌트들을 선택적인 독(2360), 디스플레이 콘트롤러 및 디스플레이 디바이스(2370), 입출력 디바이스(2380)(예를 들어, NIC(Network Interface Card), 커서 콘트롤(예를 들어, 마우스, 터치스크린, 터치패드 등), 키보드 등) 및 선택적인 무선 송수신기(들)(2390)(예를 들어, 블루투스, WiFi, 적외선 등)에 상호접속한다.
도 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(graphical user interface)를 포함할 수 있다. 무선(예를 들어, RF) 송수신기들(2430)(예를 들어, WiFi 송수신기, 적외선 송수신기, 블루투스 송수신기, 무선 셀룰러 전화 송수신기 등)은 다른 데이터 프로세싱 시스템들과 통신하는데 사용될 수 있다. 하나 이상의 입력 디바이스들(2470)은 사용자가 시스템에 입력을 제공하는 것을 허용한다. 이 입력 디바이스들은 키패드, 키보드, 터치 패널, 멀티 터치 패널 등일 수 있다. 선택적인 다른 입출력(2450)은 독을 위한 커넥터일 수 있다.
상이한 서비스 제공자들에 걸친 P2P 접속들을 관리하기 위한 실시예들
본 발명의 다른 실시예에서, 전술된 아키텍처들은 상이한 서비스 제공자들에서의 피어(peer)가 실시간 오디오, 비디오 및/또는 채팅 접속들 등의 P2P(peer-to-peer) 접속들을 구축하는 것을 허용하도록 연장된다. 상이한 서비스 제공자들은 그들 자신의 프로토콜들 및 그들 자신의 클라이언트 ID 명칭공간(namespace)들을 이용할 수 있기 때문에, 본 발명의 이러한 실시예들은, 디바이스들이 사용되는 프로토콜들에 관계없이 상호동작하고, 명칭공간들을 단일의 글로벌 명칭공간으로 통합하는 것을 허용하는 기술들을 제공한다.
글로벌 데이터베이스는 모든 시스템들 상의 모든 사용자들의 글로벌 명칭공간을 트래킹하도록 유지될 수 있다. 그러나, 서비스 제공자들에 걸쳐 확산된 주어진 막대한 수의 사용자들은 관리하기 어려울 수 있다. 대안으로, 데이터 프로세싱 디바이스들 및/또는 사용자들을 식별하는데 사용되는 이름들(예를 들어, 사용자 ID들, 전화 번호들)은 요청된 접속에 대해 누가 응답할 수 있는지를 식별하기 위해 모든 다른 서비스 제공자들에게 방송될 수 있다. 그러나, 이러한 시스템은 다시 한번 잘 스케일되지 않는다(즉, 각각의 시도된 접속을 위한 방송 메시지를 전송하는 것은 상당한 양의 대역폭을 소모한다).
전술한 이슈들을 다루기 위해, 본 발명의 일 실시예는 접속 시도들 동안 관련되는 서비스 제공자들을 찾기 위해 블룸 필터를 사용한다. 이 실시예는 도 25-26에 도시된 아키텍처들에 관하여 설명될 것이다. 도 25에 4개의 서비스 제공자들이 예시된다 - 서비스 제공자 A(2510), 서비스 제공자 B(2511), 서비스 제공자 C(2512) 및 서비스 제공자 D(2513). 종래의 실시예들에서와 같이, 각각의 서비스 제공자는 서비스 제공자로부터 데이터 통신 서비스를 제공받는 사용자들의 세트의 사용자 ID들 및/또는 전화 번호들을 포함하는 등록 DB(2520-2523)를 관리한다. 예로서, 도 25에서, 사용자들 A-C(2501-2503)는 서비스 제공자 A(2510)로부터 서비스를 제공받으며, 사용자들 D-F는 서비스 제공자 D(2513)로부터 서비스를 제공받는다. 이전에 설명한 것과 같이, 일 실시예에서, 등록 DB들(2520-2523)은 전화 번호들 또는 사용자 ID들을 각각의 사용자의 데이터 프로세싱 디바이스의 푸시 토큰에 매핑한다. 그러므로, 서비스 제공자들에 의해 유지되는 서버들은 특정 서비스 제공자의 사용자들로 하여금 위에서 설명한 기법들을 사용하여 서로와의 P2P 접속들을 찾아내고 구축하도록 한다(예컨대, 도 10-14 및 연관된 본문을 참조하라). 한 예로서, 서비스 제공자들에 의해 유지되는 서버들은 사용자로 하여금 서로 FaceTimeTM Chat 세션들(본 특허 출원의 양수인에 의해 설계된 기술)과 같은 오디오/비디오 채팅 세션들을 구축하는 것을 허용한다.
서비스 제공자 자체의 사용자들 사이의 P2P 접속들을 가능하게 하는 것 외에, 도 25 및 26에 예시된 실시예들은 상이한 서비스 제공자들의 사용자들로 하여금 서로 P2P 접속들을 구축하는 것을 가능하게 한다. 특히, 도 26에 도시된 것과 같이, 각각의 서비스 제공자는 서비스 제공자의 등록 DB(2520, 2523)를 초기에 쿼리하여 특정 사용자가 그 서비스 제공자에 의해 관리되고 있는지를 결정하기 위한 사용자 위치 서비스(2600. 2610)를 포함한다. (단순함을 위해 도 26에는 단 두 개의 서비스 제공자들(제공자들 A 및 D)만이 도시된다. 사용자 A(2501)가 동일한 서비스 제공자에 의해 관리되는 다른 사용자 - 예컨대, 사용자 B(2502) - 와 P2P 접속을 요청한다면, 서비스 제공자 A의 사용자 위치 서비스(2600)는 등록 데이터베이스로부터 사용자 B를 식별할 것이고, (예컨대, 등록 데이터베이스(2520)로부터 검색된 사용자 B의 푸시 토큰을 사용하여) 사용자 B에 접속 요청을 전송할 것이다.
그러나, 사용자 A가 상이한 서비스 제공자에 의해 관리되는 사용자 - 예컨대, 사용자 F(2506)와 P2P 접속을 요청한다면, 서비스 제공자 A(2510)의 위치 서비스(2600)는 다른 서비스 제공자들 각각으로부터 수신한 블룸 필터들(2601-2603)을 사용하여 상이한 서비스 제공자에서 사용자 F를 찾아내려고 시도할 것이다. 특히, 도 26에 예시된 것과 같이, 각각의 서비스 제공자는 그것의 등록 데이터베이스(2520, 2523)의 현재 콘텐츠에 기초하여 블룸 필터를 생성하기 위한 블룸 필터 생성기(2650, 2651)를 포함한다. 본 기술분야의 당업자들에 의해 알려진 것과 같이, 블룸 필터는 요소가 세트의 구성원인지의 여부를 테스트하기 위해 사용되는 공간 효율적인 확률론적인 데이터 구조이다. 거짓 포지티브(false positive)는 가능하지만, 거짓 네거티브(false negative)는 불가능하다. 본원에 설명한 실시예들에서, 각각의 블룸 필터들을 생성하기 위해 사용되는 "요소들"은 각각의 사용자의 사용자 ID들 및/또는 전화 번호들이다. 도 26에서, 예컨대, 서비스 제공자 A(2510)의 블룸 필터 생성기(2650)는 그것의 블룸 필터(2604)를 생성하기 위해 그것의 사용자 ID들(앤디124, 톰4546 등) 모두를 사용한다. 유사하게, 서비스 제공자 D(2513)의 블룸 필터 생성기(2651)는 그것의 블룸 필터(2603)를 생성하기 위해 그것의 등록 데이터베이스 내에 있는 그것의 사용자 ID들(우디1234, 릭456 등) 모두를 사용한다. 일 실시예에서, 각각의 서비스 제공자는 이러한 방식으로 그것만의 블룸 필터를 생성하고 그 블룸 필터를 모든 다른 서비스 제공자들에게 주기적으로 송신한다. 그러면, 각각의 서비스 제공자는 특정 사용자가 다른 서비스 제공자들에 의해 관리되는지의 여부를 테스트 및 결정하기 위해 다른 서비스 제공자들로부터 수신한 블룸 필터들을 사용할 수 있다.
예로서, 도 26에서, 앤디123의 사용자 ID를 갖는 사용자 A(2501)가 우디123의 사용자 ID를 갖는 사용자 F(2506)와 P2P 세션(예컨대, 사적인 오디오/비디오 채팅)을 구축하기를 시도한다면, 서비스 제공자 A(2510)의 사용자 위치 서비스(2600)는 초기에 사용자 F의 사용자 이름, 우디123을 그것만의 등록 데이터베이스(2520) 내에서 찾으려고 시도할 수 있다. 만약 성공적이지 못하다면, 일 실시예에서, 그것은 다른 서비스 제공자들의 블룸 필터들(2601-2603)의 사용자 ID "우디123"을 관리하는 서비스 제공자를 찾으려는 시도를 쿼리할 것이다. 언급한 것과 같이, 블룸 필터들은 거짓 포지티브들을 제공할 수 있으나 거짓 네거티브들을 제공하지는 않을 것이다. 그러므로, 블룸 필터가 서비스 제공자들 B 및 C가 우디123을 관리하지 않는다고 나타내면, 서비스 제공자 A는 우디123이 그 서비스 제공자들에 의해 관리되지 않는다는 것을 확실하게 알 것이다. 예시된 예에서, 블룸 필터 쿼리는 우디123이 서비스 제공자 D에 의해 관리될 수 있다는 것을 나타내며, 우디123이 하나 이상의 다른 서비스 제공자들에 의해 관리된다는 것을 나타낼 수도 있다. 그로서, 일 실시예에서, 서비스 제공자 A는 이 사용자 ID를 관리할 가능성이 있는 서비스 제공자들 각각에 개시 메시지(예컨대, 사용자 F를 P2P 세션에 초대하는 INVITE 명령)를 전송할 것이다. 실제로 이 사용자 ID를 관리하는 서비스 제공자들은 서비스 제공자 A에 긍정적으로 응답할 것이다. 올바른 서비스 제공자가 그 자신을 식별하면 - 예컨대, 서비스 제공자 D - 2개의 서비스 제공자들은 그들 각각의 사용자들(이 예에서, 사용자들 A 및 F)에 대한 프록시들의 기능을 할 수 있으며, 사용자들 사이의 통신 채널을 오픈할 수 있다. 사용자들 A 및 F가 접속 데이터를 교환하면, 그들은 (예컨대, 도 11에 관해 상기 설명한 기법들을 사용하여 및/또는 표준 "ICE(Internet Connectivity Establishment)" 처리를 구현함으로써) 서로와 직접적인 P2P 통신 채널들을 오픈할 수 있다. 대안적으로, (예컨대, 호환 불가능한 NAT 종류들 때문에) 직접적인 P2P 접속이 불가능하다면, 사용자들 A 및 F는 도 13에 예시된 릴레이 서비스(1051)를 사용하여 릴레이 접속을 오픈할 수 있다(도 12 및 연관된 본문 또한 참조하라).
일 실시예에서, 각각의 서비스 제공자는 그것 자체의 블룸 필터를 계속적으로 업데이트하고, P2P 오디오/비디오 접속들을 지원하기 위해 참여하는 다른 서비스 제공자들 각각에 블룸 필터를 송신할 것으로 예상된다. 업데이트는 규칙적인 간격(예컨대, 매시간, 매일 한번 등)으로 발생할 수 있고 및/또는 등록 데이터베이스에 새로운 사용자 ID들의 특정 수가 추가된 후에 발생할 수 있다. 본 발명의 기본적인 원리들은 서비스 제공자들 사이에서 블룸 필터들을 교환하기 위한 임의의 특정 메커니즘에 제한되지 않는다.
블룸 필터들을 생성하고 업데이트하기 위한 방법의 일 실시예가 도 27에 예시된다. 방법은 도 25-26에 도시된 아키텍처 상에서 실행될 수 있지만, 임의의 특정 시스템 아키텍처에 제한되지 않는다. 2701에서, 특정 서비스 제공자에서의 사용자 등록 데이터베이스가 업데이트된다. 예컨대, 새로운 사용자 ID들/전화 번호들이 추가될 수 있으며 오래된 사용자 ID들/전화 번호들이 삭제될 수 있다. 2702에서, 사용자 ID들/전화 번호들의 완전한 세트를 사용하여 새로운 블룸 필터가 생성된다. 2703에서, 새로운 블룸 필터는 참여 중인 서비스 제공자들로 송신된다.
클라이언트를 위해 서비스 제공자를 찾기 위해 블룸 필터를 사용하기 위한 방법의 일 실시예가 도 27에 예시된다. 방법은 도 25-26에 도시된 아키텍처 상에서 실행될 수 있지만, 임의의 특정 시스템 아키텍처에 제한되지는 않는다. 2801에서, 참여 중인 서비스 제공자들의 그룹의 블룸 필터들이 수신된다. 블룸 필터들은 효율적인 액세스를 위해 휘발성 메모리 내에 저장될 수 있고 및/또는 비휘발성 저장 위치에 지속될 수 있다. 2802에서, 다른 사용자(사용자 F)와 P2P 접속을 구축하기 위한 접속 요청이 사용자(이 예에서, 사용자 A)로부터 수신된다. 2803에서, 특정 서비스 제공자들을 룰 아웃(rule out)하기 위해 사용자 F의 사용자 ID(예컨대, 위의 예로부터 우디123) 상에서 블룸 필터 기능이 실행된다. 특정 블룸 필터에 대해 블룸 필터 기능이 네거티브 결과를 반환한다면, 사용자 F는 그 특정 블룸 필터에 의해 관리되지 않는다. 그러나, 블룸 필터에 대해 포지티브 결과가 반환된다면, 그 블룸 필터와 연관되는 서비스 제공자가 사용자 F를 관리할 합당한 가능성이 있다. 단 하나의 포지티브 결과가 반환되었다면, 2804에서 접속 초대가 그 서비스 제공자에 송신된다. 복수의 포지티브 결과가 반환되었다면, 2804에서 각각의 연관되는 서비스 제공자에 개별적인 접속 초대가 송신될 수 있다.
그 후, 사용자 F가 등록된 서비스 제공자는 긍정적으로 응답하며, 2806에서 두 개의 서비스 제공자들은 위에서 설명한 것과 같이 사용자들이 접속 데이터를 교환하는 것을 허용하기 위해 프록시의 역할을 할 수 있다(예컨대, 푸시 토큰, 공공/사설 네트워크 주소들/포트들, NAT 종류들 등). 2 이상의 서비스 제공자가 긍정적으로 응답한다면(두 개의 서비스 제공자들이 동일한 사용자 ID를 갖는 사용자들을 지원한다는 것을 의미함), 올바른 사용자를 식별하기 위해 추가적인 스텝들이 행해질 수 있다(예컨대, 접속을 원하는 사용자에 대해 알려진 전화 번호들, 실제 이름들, 네트워크 주소들 또는 다른 정보를 비교하는 것).
사용자 F에 대한 올바른 서비스 제공자가 식별되고, 필요한 접속 데이터가 교환되면, 위에서 설명한 것과 같이 2807에서 사용자 A 및 사용자 F 사이에 직접적인 P2P 접속 또는 (필요하다면) 릴레이 접속이 구축된다.
도 11-12에 관해 위에서 언급한 것과 같이, 본 발명의 일부 실시예들에서, 두 명의(또는 그 이상의) 사용자들 사이에 P2P 접속을 구축하기 위해 사용된 다양한 서버들은 접속 프로세스 동안 어떠한 접속 상태 정보도 유지할 필요가 없다. 이는, 예컨대, 초대 서비스(112) 및 접속 데이터 교환 서비스(110)를 포함한다. 그보다는, 이 실시예들에서, 공공/사설 IP 및 포트(때로는 일반적으로 네트워크 정보로 명명됨), NAT 종류, 사용자 ID들, 푸시 토큰들 등을 포함하지만 이들에 제한되지 않는 완전한 접속 상태가 각각의 연속적인 사용자 처리마다 누적되고 송신된다. 도 29에 예시된 것과 같이, 각각의 처리마다 송신되는 다중-제공자 맥락의 상태 정보의 한 추가적인 조각은 제공자 ID 코드이다.
도 29의 특정한 세부사항들로 돌아오면, 사용자 A는 (본 명세서에서 때때로 "초대" 요청으로 지칭되는) 개시 요청(2901)을 송신하는데, 개시 요청은 그것의 고유한 네트워크 ID(ID-A), 상기 설명된 기술들을 사용하여 결정된 그것의 고유한 네트워크 정보(예를 들어, 공공/개인 IP/포트 데이터, NAT 타입 등), 그것의 고유한 푸시 토큰(토큰-A), 및 사용자 F에 대한 ID 코드, 전화 번호 및/또는 다른 타입의 식별자를 포함한다. 개시 요청은 먼저 사용자 A의 서비스 제공자에 의해서 수신되며, 서비스 제공자는 도 25-28과 관련하여 상기 설명된 사용자 F의 서비스 제공자를 찾기 위한 기술들(예를 들어, 블룸 필터를 사용하여 어떠한 서비스 제공자들을 배제하는 것) 중 하나를 구현할 수 있다(사용자 A의 서비스 제공자와 사용자 F의 서비스 제공자는 간결성을 위하여 도 29에 도시되지 않음).
일 실시예에서, 일단 사용자 F의 서비스 제공자가 식별되면, 사용자 A의 서비스 제공자에 대한 식별자 - 상기 예에서는 "제공자 A" - 를 포함하는 푸시 개시 동작(2902)이 사용자 F의 서비스 제공자로부터 사용자 F로 송신된다. 제공자 A에 대한 식별자는 N 비트 식별 코드(예를 들어, 16 비트, 32 비트, 64 비트 등)와 같이 간결할 수 있다. 대안적으로, 제공자 A에 대한 식별자는 제공자 A의 네트워크 게이트웨이를 식별하는 공공 IP 주소 또는 제공자 D에 접속하기 위해 필요한 다른 네트워킹 데이터를 포함할 수 있다. 본 발명의 근본적인 원리들은 P2P 접속 트랜젝션들의 시퀀스에 의해 제공자 A를 식별하기 위해 사용되는 포맷에 관계없이 동일하게 유지된다.
일 실시예에서, 푸시 트랜젝션(2902)은 상기 논의된(예를 들어, 도 11 및 관련된 텍스트를 참조) 푸시 통지 서비스(1050)과 같은 푸시 통지 서비스에 의해 생성된다. 언급된 바와 같이, 사용자 A에 의해 제공된 모든 원래의 상태 정보 및 서비스 제공자 A의 서버들에 의해 수집된 임의의 부가적인 상태 정보는 푸시 개시 트랜젝션(2902)에 포함된다.
도 29에 도시된 예에서, 사용자 F는, 예를 들어 사용자 F의 ID, (ID-F), 사용자 F의 네트워크 정보(NetInfo-F; 공공/개인 IP 주소/포트, NAT 타입 등을 포함할 수 있음), 및 사용자 F의 토큰(토큰-F)을 포함하지만 이에 한정되지는 않는 P2P 접속을 설정하기 위해 필요한 사용자 F의 정보와 함께, 모든 이전 상태 정보(ID-A, NetInfo-A, 제공자 A)를 포함하는 수락 트랜젝션(2903)으로 응답한다. 사용자 A 및 사용자 F에 대한 모든 접속 상태 정보는 그것의 고유한 제공자 ID 코드를 트랜젝션(제공자-D)에 부착하고 그것을 사용자 A의 서비스 제공자로 전달하는 사용자 F의 서비스 제공자(상기 예에서는 "제공자 D")에 의해 수신된다. 제공자 A에 대하여 상기 서술한 바와 같이, 제공자 D에 대한 식별자는 N 비트 식별 코드와 같이 간결할 수 있다. 대안적으로, 제공자 D에 대한 식별자는 제공자 D의 네트워크 게이트웨이를 식별하는 공공 IP 주소 또는 제공자 D에 접속하기 위해 필요한 다른 네트워킹 데이터를 포함할 수 있다. 본 발명의 근본적인 원리들은 P2P 접속 트랜젝션들의 시퀀스 내에서 제공자 D를 식별하기 위해 사용되는 포맷에 관계없이 동일하게 유지된다.
일단 사용자 A에 의해 (제공자-D 데이터를 포함한) 모든 접속 상태 데이터가 수신되면, 사용자 A와 사용자 F는 트랜젝션(2905)에 의해 표시되는 바와 같이, 상기 설명된 기술들을 사용하여 P2P 접속을 설정할 수 있다.
상기 논의된 바와 같이, 어떠한 조건들 아래에서, 사용자 A와 사용자 F는 직접적인 P2P 접속 대신에 릴레이 서비스(1051)(예를 들어, 도 10을 참조)를 통하여 접속을 설정할 필요가 있을 수 있다. 도 30에 도시된 바와 같이, 일 실시예에서, 서비스 제공자 A 및 F 양쪽이 그들의 고유한 릴레이 서비스들(3001-3002)을 사용할 (수 있고/있거나 제3자 릴레이 서비스들에 관계될) 수 있다. 일 실시예에서, 사용자 A와 사용자 F 사이에서 시도된 P2P 접속이 실패하면, 서비스 제공자 A의 릴레이 서비스(3001)(즉, P2P 접속을 개시하는 사용자의 제공자)가 접속을 지원하기 위해 사용된다. 대안적인 실시예에서, (도 31에서 사용자 A(2501), 릴레이 서비스(3002), 및 사용자 F(2506) 간의 점선들에 의해 표시된 바와 같이) 사용자 F의 릴레이 서비스(3002)(즉, 접속이 요청된 사용자의 제공자)가 접속을 지원하기 위해 사용된다. 또다른 실시예에서, 모든 제공자들은 단일의 릴레이 서비스에 동의하고 그 릴레이 서비스를 활용하여 사용자들 간의 P2P 접속들을 설정한다.
본 발명의 일 실시예는 사용자 디바이스들 간의 보안 오디오/비디오 P2P 통신을 지원하기 위한 다양한 서로 다른 통신 프로토콜들을 결합한다. 이러한 프로토콜들은, P2P 접속 상에서의 보안 통신을 제공하는 데이터그램 전송 계층 보안(DTLS) 프로토콜; 유니캐스트(디바이스에서 디바이스로) 및 멀티캐스트(디바이스에서 복수의 디바이스로) 양쪽을 위한 RTP 데이터에 암호화, 메시지 인증 및 통합, 및 리플레이 보호를 제공하는 것을 의도하는, RTP(실시간 전송 프로토콜)의 프로파일을 정의하는 보안 실시간 전송 프로토콜(또는 SRTP); 및 사용자 디바이스들 사이에 음성/비디오 접속들을 설정하는 세션 개시 프로토콜(SIP)을 포함한다(하지만, 이에 제한되는 것은 아니다). 이러한 프로토콜들은 본 명세서에 설명된 본 발명의 임의의 실시예들의 컨텍스트 내에서 채용될 수 있다.
일 실시예에서, 도 25에 도시된 개방된, 제공자-간 네트워크의 각 디바이스는 아이덴티티 검증 및 STRP를 사용하는 스트림의 단말 대 단말 암호화의 목적에서 다른 디바이스들과 안전하게 식별 가능할 것이다. 보안 통신을 가능하게 하기 위해 각각의 서비스 제공자들에 의해 발행될 것이 요구되는 인증서 포맷이 아래에 설명된다.
일 실시예에서, 각 제공자는 다른 피어 제공자들을 발견하는 방법을 알아야만 할 것이다. 일 실시예에서, 호출 라우팅 및 피어 정보를 쿼리하기 위한 제공자들의 광역적이고 보안된 리스트가 있다. 이는 신뢰할 수 있는 서버들과, 그들의 주소 정보의 리스트이다. 제공자들의 하나가 이 서비스를 호스팅할 수 있다.
아래에는 제공자들 사이에서 그들 사이의 접속을 유효화하고 신뢰하기 위해 필요한 보안과 인증의 레벨이 설명되어 있다. 이는 P2P 접속을 인증하기 위해 사용되는 것들뿐만 아니라 제공자와 광역 룩업 데이터베이스 사이에서 사용되는 것과는 다른 크리덴셜들의 집합일 수 있다.
일 실시예에서, 호출 라우팅 시간에, 수신자의 제공자(즉, 호출되는 사용자)는 호출자에게 반환되어 엔드포인트들 사이의 P2P 접속을 인증하기 위해 사용되는 피어 인증서를 제공한다. 이 인증서는 외부 엔티티에 의해 서명될 수 있으며 인증서의 요구 사항들은 이메일만이 아니라 임의의 타입의 엔티티를 허용할 수 있다.
또한, 일 실시예에서, 오디오, 비디오, 및 시그널링 데이터는 단일의 데이터 포트 상의 각각의 데이터 프로세싱 디바이스에서 함께 다중화된다. 다음으로, 오디오, 비디오, 및 시그널링 데이터는 목적지 장치에서 역다중화 및 디코딩된다.
도 25에 도시된 제공자-간 네트워크는 복수의 상호 동작하는 계층들로 이루어진다. 이들 계층들의 상호 작용은 다양한 프로토콜들에 의해 특정될 수 있다. 이러한 상호 작용의 목표는 사용자 엔드포인트들(도 25에서 사용자 A-F (2501-2506)로 식별됨) 사이에서 필요한 정보의 교환을 수행하여 그들이 오디오/비디오 호출 세션을 설정할 수 있도록, 접속을 설정하기 위한 사용자 요청을 처리하는 것이다.
동작에 있어서, 도 25에 도시된 제공자-간 네트워크는 요청들을 발생시키고 응답하며 서로 통신하는 서버들의 집합으로서 구현된다. 이들 요청들은 사용자 엔드포인트들이 매체 채널 접속 데이터를 교환하고 오디오/비디오-호출 세션을 형성할 수 있도록 요청들을 전달하기 위해 필요한 프로토콜 동작들이다. 일 실시예에서, 각각의 서비스 제공자는 그것의 사용자 엔드포인트들과의 모든 직접적인 통신을 관리한다.
일 실시예에서, 사용자 엔드포인트들은 엔드포인트를 콘트롤하는 측을 식별하는 인터넷 식별자(Uniform Resource Identifier)(URI)에 의해 표현된다. 초기에 지원되는 URI 방식은 (전화 번호들을 위한) tel: 및 (이메일 주소들을 위한) mailto:이다. 미래에는 다른 URI 방식들이 지원될 수 있다.
일 실시예에서, URI로부터 각각의 사용자 엔드포인트에의 매핑은 일대일 매핑(identity mapping)이 아니다; 그것은 다대다 관계(many-to-many relationship)이다. 단일의 URI가 복수의 엔드포인트들에 매핑될 수도 있으며, 단일의 엔드포인트가 복수의 URI들에 매핑될 수도 있다. 또한, URI에서 엔드포인트로의 매핑은 복수의 제공자들에 걸쳐 존재할 수 있다. 예를 들어, 제공자 A에 하나의 엔드포인트가 있고, 제공자 B에 다른 엔드포인트가 있고, 이 엔드포인트들 둘 다는 동일한 URI에 의해 매핑될 수 있다. (하지만, 일 실시예에서 엔드포인트들은 한번에 하나의 제공자에 의해서만 호스팅될 수 있다.) 일 실시예에서, 엔드포인트 URI들은 전화 번호들 또는 이메일 주소들과 같은 제네릭한 사용자 레벨 식별자들이다. 이들로부터 제공자들 및 엔드포인트들로의 매핑은 시스템에 의해 수행되며, 최종 사용자에게 투명하다.
일 실시예에서, 도 25에 도시된 제공자-간 통신을 위해 사용되는 메타 프로토콜은 HTTP 상의 사전들이다. 이 실시예에서, 모든 동작들은 HTTP GET 또는 POST 둘 중 하나로서 수행된다. 동작이 HTTP GET으로 특정된다면, 바디(body)는 빌(empty) 것이다. 동작이 HTTP POST로 특정된다면, 바디는 사전으로 인코딩된 요청 파라미터들을 포함할 것이다. 응답들은 사전으로 인코딩된 응답 파라미터들을 포함하는 바디를 가질 것이다. 일 실시예에서, 사전들의 초기 인코딩은 Apple XML Property Lists이다. JSON이나 Protocol Buffers와 같은 다른 인코딩들도 사용될 수 있다. 일 실시예에서, 서로 다른 서비스 제공자들은 개별 사용자 디바이스들과 통신하기 위해 프로토콜들 또는 통신 메커니즘들의 임의의 집합을 사용할 수 있다.
일 실시예에서, 도 25에 도시된 서비스 제공자들이 서로 탐색할 수 있도록 제공자 탐색 프로토콜이 이용된다. 일 실시예에서, 부트스트랩 URI는 네트워크의 관리 엔티티(예를 들어, 프라이머리 또는 관리 서비스 제공자)에 의해 발행된다. 이러한 부트스트랩 URI는 이 네트워크의 수락된 멤버들인 제공자들의 세트를 포함하는 탐색 사전을 가리킨다. 각각의 서비스 제공자에 대해, 이러한 사전은 식별 정보뿐만 아니라, 이러한 제공자와 통신하는 방법을 지정하는 추가 URI들을 포함한다. 일 실시예에서, 서비스 제공자들이 시작할 때, 그리고 주기적으로 그 이후에, 그들은 탐색 사전을 검색한다. 그 후, 그들은 사전 내의 정보에 기초하여 다른 제공자들과 통신하기 위해 그들 자신을 구성한다.
사용자들 사이의 P2P 통신 세션들을 확립하기 위한 하나의 특정 세트의 프로토콜들에 대한 상세가 이제 논의될 것이다. 그러나, 이들 특정 상세들이 특정 실시예를 나타낼 뿐이며, 본원의 기초를 이루는 원리들을 충족시키기 위해 요구되는 것은 아니라는 것에 유의해야 한다.
1. 초대( Invitation ) 프로토콜
일 실시예의 초대 프로토콜은 초기 호출 설정을 위해 이용된다. 이것은, 영상 통화(video-call) 세션을 위한 미디어 채널을 확립하는 데에 이용될 미디어 채널 접속 데이터를 교환하기 위해 사용자 엔드포인트들(예를 들면, 도 25의 사용자 엔드포인트들(2501-2506))에 의해 이용되는 대역 외(out-of-band) 시그널링이다.
1.1. 동작들
초대 프로토콜에는 4개의 메인 동작들이 존재한다.
1.1.1. 개시
호출을 시작하기 위해 개시 엔드포인트에 의해 보내진다. 필드들: session-id, self-uri, self-token, self-blob, peer-uri.
1.1.2. 수락
호출에 참여하고자 한다는 것을 나타내도록, 수신 엔드포인트에 의해 보내진다.
필드들: session-id, self-uri, self-token, self-blob, peer-uri, peer-token, peer-blob.
1.1.3. 거절
호출에 참여하지 않겠다는 것을 나타내도록, 수신 엔드포인트에 의해 보내진다. 필드들: session-id, self-uri, self-token, self-blob, peer-uri, peer-token, peer-blob.
1.1.4. 취소
호출이 종료되어야 한다는 것을 나타내도록, 어느 한 엔드포인트에 의해 보내진다. 필드들: session-id, self-uri, self-token, self-blob, peer-uri, peer-token, peer-blob.
1.2. 동작 변형들
동작을 서비스하는 당사자에 따라, 이들은 하기 세 가지 형태를 취할 수 있다:
* 요청(엔드포인트로부터 제공자로의)
* 전달(제공자로부터 제공자로의)
* 푸시(Push)(제공자로부터 엔드포인트로의)
1.3. 호출 흐름(Call Flow)
1.3.1. 사용자 엔트리
엔드포인트가 접속을 확립하기를 원할 때, 그것은 수신 엔드포인트들을 식별하기 위한 URI를 필요로 한다. 이러한 URI는 사용자에 의해 제공되는 일부 정보, 예를 들면, 전화를 건 전화 번호, 또는 주소 책(book)에 저장된 이메일 주소로부터 도출될 가능성이 크다. 그 후, 엔드포인트는 그의 호스팅 제공자에 대해 개시 요청(Initiate Request)을 보낸다.
1.3.2. 개시 요청
개시 제공자는 URI를 살펴보고, 이러한 URI에 의해 매핑된 엔드포인트들을 호스팅하는 수신 제공자의 세트를 결정한다(이러한 제공자들의 세트는 개시 제공자 자신을 포함한다). 그것은 이후 모든 적용가능한 수신 제공자들에 대해 개시 전달(Initiate Forward)을 보낸다.
1.3.3. 개시 전달
각각의 수신 제공자는 수신 엔드포인트를 결정하고, 그것에 개시 푸시(Initiate Push)를 보낸다.
1.3.4. 개시 푸시
수신 엔드포인트는 개시 푸시를 받고, 사용자에게 정보를 나타낸다(이것은 통상적으로 "XXX가 전화하고 있습니다."와 같은 UI일 것이다). 사용자가 전화를 받기로 결정하면, 엔드포인트는 수락 요청(Accept Request)를 보낼 것이다(그렇지 않으면, 그것은 거절 요청(Reject Request)을 보낼 것이다).
1.3.5. 수락 요청
수신 엔트포인트는 그것의 호스팅 제공자에 대해 수락 요청을 보낸다.
1.3.6. 수락 전달
수신 제공자는 수락 푸시(Accept Push)를 개시 엔드포인트에 보낸다.
1.3.7. 수락 푸시
개시 엔드포인트는 수락 푸시를 받고, 그것이 접속을 구성하는 것을 계속할 수 있다는 것을 사용자에게 나타낸다. 이 시점에서, 양쪽 엔드포인트들은 미디어 채널 접속 데이터를 교환하여, 그들이 음성/영상 통화 세션을 위한 미디어 채널을 확립할 준비가 되게 된다. 이로부터, (이하의) 미디어 세션 관리에 개시된 바와 같이, 흐름은 미디어 채널 확립으로 계속된다.
2. 최적화 프로토콜 디스패치( Dispatch Optimization Protocol )
상기에 상세히 논의된 바와 같이, 일 실시예에서, 블룸 필터들은 개시 호출 요청에 응답할 수 있을 후보 서비스 제공자들을 선택하는 데에 이용된다. 일 실시예에서, 제공자들은, 그들이 현재 호스팅하는 모든 엔드포인트들의 URI들을 나타내는 최신 블룸 필터를 유지하도록 요구된다. 모든 제공자들에 대한 블룸 필터들은 증가하는 방식으로 모든 다른 제공자들에 분배될 수 있다.
최적화 프로토콜 디스패치. 발신 호출(originated call)을 디스패치할 때, 제공자들은 우선 모든 다른 제공자들의 블룸 필터를 찾아 본다(consult). 이로부터, 그들은 호출을 실제로 서비스할 수 있는 제공자들의 후보 세트를 획득할 것이다. 개시 동작은 그 후 이러한 후보 리스트에만 보내진다.
3. 미디어 세션 관리
미디어 세션 관리는 미디어 채널 및 미디어 채널 상의 미디어 스트림들의 설정, 콘트롤, 및 테어다운(teardown)을 칭한다. 미디어 세션 관리는 이하의 섹션들에서 상세히 설명된다.
4. 미디어 채널 확립
미디어 시그널링, 미디어 흐름, 및 세션 테어다운을 위한 네트워크 패킷들은 미디어 채널을 통해 보내진다. 미디어 채널은 NAT 통과(traversal), 또는 (상기에 상세히 설명된 바와 같은) 릴레이 구성 중 어느 하나를 통해 확립된다. NAT 통과 및 릴레이 구성 양쪽 모두는 각각의 엔드포인트가 양쪽 엔드포인트들에 대한 미디어 채널 접속을 갖출 것을 요구한다.
4.1. NAT 통과 프로토콜
일 실시예에서, NAT 통과 프로토콜은 다이렉트 피어-투-피어 접속을 통한 미디어 채널을 확립하는 데에 이용된다. 그것은 ICE(Interactive Connectivity Establishment)[RFC 5245]에 포함되는 기법들의 사용을 포함한다.
4.2. 릴레이 구성 프로토콜
일 실시예에서, 릴레이 프로토콜이 릴레이 네트워크를 통해 미디어 채널을 설정하는 데에 사용된다. 일 실시예에서, 이는 TURN [RFC 5761]의 사용을 포함한다.
5. 미디어 채널 시그널링
미디어 시그널링은 미디어 협의 및 미디어 암호화에 대한 보안의 설정, 및 오디오 및 비디오 파라미터들을 위한 미디어 협의를 다룬다.
5.1. 보안 설정
기재한 바와 같이, 일 실시예에서, 데이터그램 전송 계층 보안(DTLS)[RFC 4347]은 미디어 채널을 통한 네트워크 트래픽의 통신을 보호하는 데에 사용된다. DTLS 프로토콜은 서비스 제공자가 사용자들 사이에서 전송되는 보이스/비디오 패킷들 내의 암호화된 콘텐츠에 액세스하지 못하도록 엔드-투-엔드 암호화를 제공하도록 구현될 수 있다.
5.2. 미디어 협의
일 실시예에서, SIP[RFC 3261]는 비디오 호출 세션의 오디오 및 비디오 파라미터들을 협의하기 위해 사용된다.
5.3. 오디오 및 비디오 암호화
일 실시예에서, SRTP [RFC 3711]는 오디오 및 비디오 페이로드들을 암호하하기 위해 사용된다.
6. 미디어 흐름 콘트롤
미디어 흐름 콘트롤은 액티브 미디어 스트림의 관리 및 미디어 채널을 통한 미디어 상태 변화의 통지를 다룬다.
6.1. 네트워크 적응
일 실시예에서, 네트워크 적응 기술은 통신 채널 변동을 고려하도록 구현된다. 특히, 사용자 엔드포인트는 쓰루풋, 패킷 손실, 및 레이턴시에서의 변화와 같은 네트워크 조건들이 변화하는 것에 적응하기 위해 오디오 및/또는 비디오 비트레이트와 같은 스트림 파라미터들을 조정할 수 있다.
6.2. 비디오 뮤트(mute)
비디오를 송신하는 엔드포인트는 비디오를 뮤트/언뮤트할 수 있다. 통지들이 SIP MESSAGE를 사용하여 원격 엔드포인트로 송신된다.
6.3. 비디오 오리엔테이션
비디오를 송신하는 엔드포인트는 비디오의 오리엔테이션을 변경할 수 있다. RTP 헤더 확장 정보를 사용하여 원격 엔드포인트로 통지들이 송신된다.
6.4. 비디오 전환
비디오를 송신하는 엔드포인트가 비디오의 소스를 전환할 수 있다. 예를 들면, 전방 및 후방 카메라 둘다를 포함하는 사용자 디바이스 상에서, 비디오는 전방으로부터 후방으로 전환될 수 있다. RTP 헤더 확장 정보를 사용하여 원격 엔드포인트로 통지들이 송신된다.
6.5. 행업(Hangup)
일 실시예에서, 엔드포인트는 SIP BYE 메시지를 송신함으로써 액티브 세션을 명료하게 종료할 수 있다.
7. 미디어 채널 테어다운( Teardown )
미디어 세션은 명시적으로 또는 암시적으로 테어다운될 수 있다. 미디어 채널의 명시적인 테어다운은 SIP BYE 메시지를 송신 또는 수신함으로써 행해진다. 암시적인 테어다운은 네트워크 접속 손실, 또는 열악한 네트워크 성능 때문에 발생할 수 있다.
8. 보안
8.1. 인증서
일 실시예에서, 도 25에 도시된 제공자간 시스템에서의 엔드포인트 사이의 통신은 공개 키 암호화를 사용하여 보호될 수 있다. 각각의 엔티티(제공자 및 엔드포인트)는 그것의 식별자를 서명하는 신뢰된 CA에 의해 발행된 인증서를 갖는다. 이 인증서는 엔티티에 속한 URI 뿐 아니라 정보를 식별하는 다른 것도 포함한다. 인증서는 통신할 때에 엔티티의 식별자를 검증하도록 카운터 파티들에 의해 사용될 수 있다.
8.2. 미디어 채널 시그널링
SIP 메시지들은 DTLS [RFC 4347]을 사용하여 보호될 수 있다.
8.3. 오디오 및 비디오
오디오 및 비디오 스트림들은 SRTP [RFC 3711]을 사용하여 보호될 수 있다.
9. 인코딩
9.1. 오디오
9.1.1. 오디오 코덱
오디오 코덱은 MPEG-4 인핸스드 로우 딜레이 AAC(AAC-ELD, ISO/IEC 14496-3)을 따를 수 있다.
9.1.2. 오디오 품질
일 실시예에서, 오디오 신호 청각 특징은 광대역 전화 단말을 위한 3GPP 사양, TS 26.131 및 TS 26.132에 의해 특정된다.
9.1.2. 오디오 RTP 페이로드 포맷
9.2. 비디오
일 실시예에서, 시퀀스 파라미터 세트(SPS) 및 화상 파라미터 세트(PPS) NALU들은 비트스트림에서 비디오 스트림 설명을 수행하는 데에 사용된다.
9.2.1. 비디오 코덱
일 실시예에서, 도 25의 사용자들 사이의 통신에 사용되는 비디오 코덱은 b-프레임 없는 H.264 하이 프로파일, 레벨 1.2(효율적으로는, QVGA 15 fps, 최대 300 kbps)이다. 그러나, 본 발명의 기본적인 원칙은 임의의 특정 오디오/비디오 포맷으로 제한하고자 하는 것이 아님을 알아야 한다.
9.2.2. 비디오 RTP 페이로드 포맷
언급한 바와 같이, 실시간 전송 프로토콜(RTP)은 사용자 엔드포인트들 사이에서 오디오/비디오 통신을 지원하는데에 사용될 수 있다. 도 32에서 도시된 바와 같이, 일 실시예에서, RFC 3984 헤더(3202) (즉, RFC 3984에 의해 정의된, H.264 비디오를 위한 RTP 페이로드 포맷)는 (RTP 데이터 패킷을 포함하는) 각각의 12 바이트 RTP 페이로드(3201)에 첨부된다. 헤더는 H.264 이미지 설명 확장을 사용하여 RTP 데이터가 어떻게 패킷화되는지를 특정한다.
본 발명의 실시예들은 상기한 바와 같이 다양한 단계들을 포함한다. 단계들은 범용 또는 특수목적 프로세서가 특정 단계들을 수행하게 하는 머신-실행가능한 명령어들로 구현될 수 있다. 다르게는, 이러한 단계들은 단계들을 수행하기 위한 유선 로직을 포함하는 특정 하드웨어 컴포넌트들에 의해, 또는 프로그래밍된 컴퓨터 컴포넌트들 및 커스텀 하드웨어 컴포넌트들의 임의의 조합에 의해 수행될 수 있다.
본 발명의 구성요소들은 머신-실행가능한 프로그램 코드를 저장하는 머신-판독가능한 매체로 제공될 수도 있다. 머신-판독가능한 매체는 플로피 디스켓, 광 디스크, CD-ROM, 및 자기-광 디스크, ROM, RAM, EPROM, EEPROM, 자기 또는 광 카드, 또는 전자 프로그램 코드를 저장하기에 적합한 미디어/머신-판독가능한 매체의 임의의 타입을 포함하지만 이에 제한되지는 않는다.
전술한 설명을 통해, 설명의 목적을 위해, 수치적인 특정 세부사항들이 본 발명의 철저한 이해를 돕기 위해 기재되었다. 그러나, 본 발명이 이러한 구체적 세부사항 없이도 시행될 수 있음이 당업자들에게는 명백할 것이다. 예를 들면, 본원에서 설명된 기능적인 모듈들 및 방법들이 소프트웨어, 하드웨어 또는 이들의 임의의 조합으로 구현될 수 있음이 당업자들에게 명백할 것이다. 또한, 본 발명의 실시예들이 모바일 컴퓨팅 환경의 컨텍스트 내에서(즉, 모바일 디바이스들 (120-123; 601-603)을 사용하여) 본원에서 기재되었지만, 본 발명의 본질적인 원칙은 모바일 컴퓨팅 구현으로 제한되는 것은 아니다. 가상적으로 클라이언트 또는 피어 데이터 프로세싱 디바이스들의 임의의 타입이 예를 들면, 데스크탑 또는 워크스테이션 컴퓨터들을 포함하는 일부 실시예들에서 사용될 수 있다. 따라서, 본 발명의 범위 및 사상은 첨부된 청구 범위의 기준으로 판단되어야 한다.

Claims (13)

  1. 컴퓨터 구현 방법으로서,
    제1 사용자를 찾으라는(locate) 요청을 제1 서비스 제공자에서 수신하는 단계 - 상기 요청은 상기 제1 사용자에 대한 ID(identification) 코드를 포함함 -;
    상기 제1 사용자가 상기 제1 서비스 제공자에 의해 등록되었는지를 결정하기 위하여 등록 데이터베이스에 쿼리하는 단계;
    상기 사용자가 상기 제1 서비스 제공자에 의해 등록되어 있지 않은 경우, 다른 서비스 제공자들로부터 주기적으로 수신된 복수의 블룸 필터(bloom filter)에 쿼리하는 단계 - 각각의 블룸 필터는 상이한 서비스 제공자와 연관됨 -;
    연관된 블룸 필터가 포지티브 응답을 반환한 서비스 제공자들을 수집하는 단계 - 상기 포지티브 응답은 상기 제1 사용자가 개개의 블룸 필터들과 연관된 서비스 제공자들에 의해 등록될 수도 있고 등록되지 않을 수도 있음을 나타내고, 네거티브 응답은 상기 제1 사용자가 개개의 블룸 필터들과 연관된 서비스 제공자들에 의해 등록되지 않음을 확신을 가지고 나타냄 -;
    상기 수집된 각각의 서비스 제공자에 대하여:
    상기 서비스 제공자에게 요청을 송신하는 단계;
    상기 서비스 제공자로부터 응답을 수신하는 단계; 및
    상기 응답이 상기 제1 사용자가 상기 서비스 제공자에 의해 등록되었음을 확신을 가지고 나타낼 경우, 상기 서비스 제공자를 선택하는 단계
    를 포함하고,
    상기 등록 데이터베이스에의 복수의 업데이트를 수신하는 경우 - 상기 업데이트들은 상기 제1 서비스 제공자에 의해 등록된 새로운 사용자들과 연관된 새로운 ID 코드들을 포함함 - 상기 제1 서비스 제공자는:
    상기 새로운 ID 코드들 및 상기 제1 서비스 제공자에 의해 이미 등록된 기존의 사용자들과 연관된 복수의 기존의 ID 코드들을 사용하여 블룸 필터를 생성하고,
    복수의 다른 서비스 제공자 각각에 새로운 블룸 필터를 송신 - 상기 블룸 필터는 상기 복수의 다른 서비스 제공자에 의해 사용가능하여, 특정 ID 코드들이 상기 제1 서비스 제공자에 의해 등록된 사용자들을 식별하지 않는 것을 확신을 가지고 결정함 -
    하는, 컴퓨터 구현 방법.
  2. 제1항에 있어서,
    상기 제1 사용자와의 P2P(peer-to-peer) 네트워크 접속을 설정하기 위하여 네트워크 접속 데이터를 제2 사용자에게 제공하는 단계 - 상기 네트워크 접속 데이터는 상기 선택된 서비스 제공자를 식별함 -
    를 더 포함하는 컴퓨터 구현 방법.
  3. 제1항에 있어서,
    상기 ID 코드는 영숫자 스트링(alphanumeric string)을 포함하는 컴퓨터 구현 방법.
  4. 제1항에 있어서,
    상기 ID 코드는 이메일 어드레스를 포함하는 컴퓨터 구현 방법.
  5. 제1항에 있어서,
    상기 ID 코드는 전화 번호를 포함하는 컴퓨터 구현 방법.
  6. 제1항에 있어서,
    상기 제1 사용자가 상기 제1 서비스 제공자에 의해 등록되는 경우, 상기 제1 사용자와의 P2P(peer-to-peer) 네트워크 접속을 설정하기 위하여 제2 사용자에게 네트워크 접속 데이터를 제공하고, 상기 네트워크 접속 데이터는 상기 제1 서비스 제공자에 의해 관리되는 네트워크 어드레스를 식별하는 컴퓨터 구현 방법.
  7. 제1항에 있어서,
    상기 제1 사용자가 상기 제1 서비스 제공자에 의해 등록되지 않고 블룸 필터에 의해 식별된 제2 서비스 제공자에 의해 등록되는 경우, 상기 제1 사용자에게 접속 데이터를 송신하기 위한 프록시로서 상기 제2 서비스 제공자를 사용하고, 상기 접속 데이터는 상기 제1 사용자로부터 상기 제1 서비스 제공자에 의해 등록되는 제2 사용자로의 P2P(peer-to-peer) 접속을 설정하는 데에 필요한 네트워킹 데이터를 포함하는 컴퓨터 구현 방법.
  8. 제7항에 있어서,
    상기 제2 사용자에게 상기 제1 사용자의 접속 데이터를 제공하기 위한 프록시로서 상기 제1 서비스 제공자를 사용하는 단계를 더 포함하고, 상기 접속 데이터는 상기 제2 사용자로부터 상기 제1 사용자로의 P2P 접속을 설정하는 데에 필요한 컴퓨터 구현 방법.
  9. 제6항에 있어서,
    상기 네트워크 어드레스는 TCP/IP 어드레스를 포함하는 컴퓨터 구현 방법.
  10. 삭제
  11. 삭제
  12. 삭제
  13. 하나 이상의 머신에 의해 실행될 때, 머신들로 하여금 제1항 내지 제9항 중 어느 한 항의 방법들의 동작들을 수행하게 하는 프로그램 코드가 저장된 머신 판독가능 매체.
KR1020120029039A 2011-03-21 2012-03-21 상이한 서비스 제공자들 사이의 피어-투-피어 접속들을 관리하기 위한 장치 및 방법 KR101397834B1 (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201161454930P 2011-03-21 2011-03-21
US61/454,930 2011-03-21
US13/410,232 US9667713B2 (en) 2011-03-21 2012-03-01 Apparatus and method for managing peer-to-peer connections between different service providers
US13/410,232 2012-03-01

Publications (2)

Publication Number Publication Date
KR20120107880A KR20120107880A (ko) 2012-10-04
KR101397834B1 true KR101397834B1 (ko) 2014-05-20

Family

ID=45841378

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020120029039A KR101397834B1 (ko) 2011-03-21 2012-03-21 상이한 서비스 제공자들 사이의 피어-투-피어 접속들을 관리하기 위한 장치 및 방법

Country Status (6)

Country Link
US (1) US9667713B2 (ko)
EP (1) EP2503804B1 (ko)
JP (1) JP5711849B2 (ko)
KR (1) KR101397834B1 (ko)
CN (1) CN103348633B (ko)
WO (1) WO2012129121A1 (ko)

Families Citing this family (84)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8073959B2 (en) * 2008-03-28 2011-12-06 Microsoft Corporation Automatically detecting whether a computer is connected to a public or private network
US9077676B2 (en) * 2010-11-10 2015-07-07 Rave Wireless, Inc. Intelligent messaging
US9083718B1 (en) * 2011-03-28 2015-07-14 Brian Bosak Global grid protocal, a system and method for establishing and simplifying peer-to-peer networking connections among a plurality of computers and divices by dynamically generating identifiers and performing routing and traversal processes
JP6243356B2 (ja) 2012-02-06 2017-12-06 ホットヘッド ゲームズ インコーポレイテッド カードのボックス及びパックの仮想的な開封
GB2500720A (en) * 2012-03-30 2013-10-02 Nec Corp Providing security information to establish secure communications over a device-to-device (D2D) communication link
US9170667B2 (en) 2012-06-01 2015-10-27 Microsoft Technology Licensing, Llc Contextual user interface
US9381427B2 (en) * 2012-06-01 2016-07-05 Microsoft Technology Licensing, Llc Generic companion-messaging between media platforms
US9356980B2 (en) 2012-07-31 2016-05-31 At&T Intellectual Property I, L.P. Distributing communication of a data stream among multiple devices
US9444726B2 (en) * 2012-07-31 2016-09-13 At&T Intellectual Property I, L.P. Distributing communication of a data stream among multiple devices
WO2014024888A1 (ja) * 2012-08-06 2014-02-13 グリー株式会社 表示システム、同システムにおける表示方法及び表示プログラム
US9148306B2 (en) * 2012-09-28 2015-09-29 Avaya Inc. System and method for classification of media in VoIP sessions with RTP source profiling/tagging
US9363165B2 (en) * 2013-03-11 2016-06-07 Qualcomm Incorporated Enhanced call control for directing a content path over multiple connections
US9120020B2 (en) 2013-03-13 2015-09-01 Microsoft Technology Licensing, Llc Matchmaking in multiplayer gaming
CN103152444B (zh) * 2013-03-25 2016-08-03 华为技术有限公司 中继方式的网络地址转换及报文传输方法及装置、系统
US9295915B2 (en) 2013-05-20 2016-03-29 Microsoft Technology Licensing, Llc Game availability in a remote gaming environment
CN103414756B (zh) * 2013-07-18 2016-08-24 华为技术有限公司 一种任务分发方法、分发节点及系统
EP3025540A4 (en) * 2013-07-26 2017-03-15 Intel IP Corporation Signaling interference information for user equipment assistance
CN103533039B (zh) * 2013-09-27 2017-04-19 深圳市瑞彩电子技术有限公司 P2p数据传输的方法、转发代理服务器与系统
KR101528563B1 (ko) * 2013-10-18 2015-06-12 주식회사 홍인터내셔날 오프라인 매치 메이킹 방법, 장치 및 컴퓨터-판독가능 매체
EP3063908A1 (en) * 2013-10-31 2016-09-07 Telefonaktiebolaget LM Ericsson (publ) Service chaining using in-packet bloom filters
JP6301464B2 (ja) * 2013-11-04 2018-03-28 エルジー エレクトロニクス インコーポレイティド 電子装置及び電子装置の制御方法
US9467842B2 (en) * 2013-12-12 2016-10-11 Alcatel Lucent Discovery of objects in wireless environments
CN104735106A (zh) * 2013-12-20 2015-06-24 乐视网信息技术（北京）股份有限公司 一种节点发送方法及装置
CN104753900B (zh) * 2013-12-31 2018-03-02 北京新媒传信科技有限公司 一种实现 ios 设备接入sip 网络的方法和网关
US10270819B2 (en) * 2014-05-14 2019-04-23 Microsoft Technology Licensing, Llc System and method providing collaborative interaction
TWI529638B (zh) * 2014-05-26 2016-04-11 國立成功大學 藉由近場通訊技術在行動裝置上安全移轉電子票證的系統及方法
KR101616085B1 (ko) * 2014-05-29 2016-04-29 계명대학교 산학협력단 대규모 다중사용자를 위한 네트워크 기반 부하 분산형 스크린 골프 시스템 및 그 방법
FR3023093A1 (fr) * 2014-06-30 2016-01-01 Orange Procede d'autorisation d'etablissement d'un flux pair a pair dans un reseau de telecommunications mobile
US10554709B2 (en) * 2014-07-08 2020-02-04 Microsoft Technology Licensing, Llc Stream processing utilizing virtual processing agents
US9825899B2 (en) * 2014-07-10 2017-11-21 Facebook, Inc. Systems and methods for directng messages based on social data
CN107111594A (zh) * 2014-09-24 2017-08-29 V5系统公司 动态数据管理
TWI612431B (zh) * 2014-10-03 2018-01-21 物聯智慧科技（深圳）有限公司 對等網路裝置社群之搜尋系統、搜尋方法及其對等網路裝置
KR102257474B1 (ko) * 2014-11-04 2021-05-31 삼성전자 주식회사 전자 장치의 데이터 송수신 방법 및 이를 사용하는 전자 장치
CN104519149A (zh) * 2014-12-24 2015-04-15 国家电网公司 一种通过缓存DHCPv6 rq options保护重要通信设备的方法
WO2016110785A1 (en) * 2015-01-06 2016-07-14 Umbra Technologies Ltd. System and method for neutral application programming interface
WO2016121881A1 (ja) * 2015-01-29 2016-08-04 エヌ・ティ・ティ・コミュニケーションズ株式会社 通信制御装置、通信制御方法及び通信制御プログラム
CN104735136B (zh) * 2015-03-02 2018-06-01 西安科技大学 一种新型的基于网络的数学学习系统
US10075447B2 (en) * 2015-03-04 2018-09-11 Neone, Inc. Secure distributed device-to-device network
CN104765990B (zh) * 2015-03-11 2018-09-04 小米科技有限责任公司 智能设备管理账户的设置方法及装置
EP3073702B1 (en) * 2015-03-27 2017-09-06 Axis AB Method and devices for negotiating bandwidth in a peer-to-peer network
US20160354696A1 (en) * 2015-06-05 2016-12-08 Apple Inc. Systems and methods for providing anonymous guest players in a multiplayer environment
US9298934B1 (en) 2015-06-30 2016-03-29 Linkedin Corporation Managing presentation of online content
US20170014718A1 (en) * 2015-07-14 2017-01-19 Hothead Games, Inc. Server daemon based gameplay management
US9628992B2 (en) * 2015-07-31 2017-04-18 Wyfi, Inc. WiFi access management system and methods of operation thereof
WO2017029108A1 (en) * 2015-08-18 2017-02-23 Nokia Solutions And Networks Oy Method and system for database queries
CN105262717A (zh) * 2015-08-31 2016-01-20 福建天晴数码有限公司 一种网络服务安全管理方法及装置
US9860157B2 (en) 2015-09-09 2018-01-02 Sling Media Pvt Ltd Zero configuration approach for port forwarding cascaded routers
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
US9901818B1 (en) * 2016-02-19 2018-02-27 Aftershock Services, Inc. Systems and methods for regulating access to game content of an online game
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
US9919213B2 (en) 2016-05-03 2018-03-20 Hothead Games Inc. Zoom controls for virtual environment user interfaces
US10010791B2 (en) 2016-06-28 2018-07-03 Hothead Games Inc. Systems and methods for customized camera views and customizable objects in virtualized environments
US10004991B2 (en) 2016-06-28 2018-06-26 Hothead Games Inc. Systems and methods for customized camera views in virtualized environments
US10019456B2 (en) 2016-06-29 2018-07-10 Microsoft Technology Licensing, Llc Recovering free space in nonvolatile storage with a computer storage system supporting shared objects
US10242206B2 (en) * 2016-09-01 2019-03-26 Onapsis, Inc. System and method for fast probabilistic querying role-based access control systems
US10225359B2 (en) 2016-09-22 2019-03-05 International Business Machines Corporation Push notifications from multiple tenant servers
EP3306896A1 (en) 2016-10-07 2018-04-11 Nokia Technologies OY Access to services provided by a distributed data storage system
TWI625979B (zh) * 2016-12-08 2018-06-01 財團法人工業技術研究院 換手方法、系統和用戶設備
CN108279983A (zh) * 2016-12-30 2018-07-13 北京国双科技有限公司 一种接口返回结果的处理方法及装置
US20180190028A1 (en) * 2017-01-03 2018-07-05 Bank Of America Corporation Facilitating Across-Network, Multi-User Sessions Using Augmented Reality Display Devices
JP6864477B2 (ja) * 2017-01-06 2021-04-28 任天堂株式会社 情報処理装置、情報処理システム、情報処理方法及びプログラム
CN108337156B (zh) 2017-01-20 2020-12-18 阿里巴巴集团控股有限公司 一种信息推送方法及装置
US10270851B2 (en) 2017-02-13 2019-04-23 Microsoft Technology Licensing, Llc Activating a peer-to-peer communication channel
EP3602879B1 (en) 2017-03-23 2022-12-07 Telefonaktiebolaget LM Ericsson (publ) Configuring puncture bundles of data for a first service in a transmission of a second service
EP3602878B1 (en) * 2017-03-23 2022-06-01 Telefonaktiebolaget LM Ericsson (PUBL) Puncture bundling of data for a first service in a transmission of a second service
US10594661B1 (en) * 2017-06-13 2020-03-17 Parallels International Gmbh System and method for recovery of data packets transmitted over an unreliable network
US10931534B2 (en) * 2017-10-31 2021-02-23 Cisco Technology, Inc. Auto discovery of network proxies
JP6392439B1 (ja) * 2017-12-15 2018-09-19 グリー株式会社 プログラム、端末装置、及び情報処理システム
US20190260826A1 (en) * 2018-02-21 2019-08-22 Artem Gurtovoy P2p video communication with a third-parties
CN110191141B (zh) * 2018-02-23 2022-03-29 阿里巴巴集团控股有限公司 服务调用信息处理方法、装置及计算机系统
CN108616845B (zh) * 2018-03-30 2021-10-26 佛山市顺德区中山大学研究院 基于社交内容的d2d分组多目标缓存方法及其系统、装置
US11132400B2 (en) * 2018-07-23 2021-09-28 Microsoft Technology Licensing, Llc Data classification using probabilistic data structures
CN109194740B (zh) * 2018-09-03 2021-08-24 高新兴科技集团股份有限公司 一种发电管理的方法和设备
KR102442919B1 (ko) * 2019-06-25 2022-09-14 이화여자대학교 산학협력단 블룸 필터를 이용한 물리적 복제 방지 기술 인증 시스템 및 그 방법
CN110380956B (zh) * 2019-08-22 2021-06-08 广州华多网络科技有限公司 一种传输即时通信消息的方法、装置及系统
JP2022549671A (ja) * 2019-09-25 2022-11-28 コモンウェルス サイエンティフィック アンド インダストリアル リサーチ オーガナイゼーション ブラウザアプリケーション用の暗号化サービス
CN111080370A (zh) * 2019-12-21 2020-04-28 济南东驰网络科技有限公司 一种基于flink进行LBS定位的互联网营销平台
JP7330113B2 (ja) * 2020-02-03 2023-08-21 株式会社バンダイナムコエンターテインメント コンピュータシステムおよびゲームシステム
KR102503028B1 (ko) * 2020-11-27 2023-02-23 (주)유미테크 블룸필터를 이용한 분산식별자 검색 방법
CN114598532B (zh) * 2022-03-11 2023-07-28 北京百度网讯科技有限公司 连接建立方法、装置、电子设备和存储介质
CN114827231B (zh) * 2022-04-11 2023-09-26 杭州指令集智能科技有限公司 基于浏览器本地存储实现多窗口点对点通信的方法及系统
CN115022281B (zh) * 2022-06-16 2023-07-14 杭州楷知科技有限公司 一种nat穿透的方法、客户端及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050044144A1 (en) * 2002-04-29 2005-02-24 Dale Malik Instant messaging architecture and system for interoperability and presence management
US20100082648A1 (en) * 2008-09-19 2010-04-01 Oracle International Corporation Hash join using collaborative parallel filtering in intelligent storage with offloaded bloom filters
KR20100037137A (ko) * 2007-07-10 2010-04-08 콸콤 인코포레이티드 피어-투-피어 네트워크에서 피어 발견 내에서 식별자들을 통신하는 코딩 방법들
US20100318795A1 (en) 2009-06-11 2010-12-16 Qualcomm Incorporated Bloom filter based device discovery

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6661799B1 (en) * 2000-09-13 2003-12-09 Alcatel Usa Sourcing, L.P. Method and apparatus for facilitating peer-to-peer application communication
US20020042875A1 (en) * 2000-10-11 2002-04-11 Jayant Shukla Method and apparatus for end-to-end secure data communication
US7003551B2 (en) * 2000-11-30 2006-02-21 Bellsouth Intellectual Property Corp. Method and apparatus for minimizing storage of common attachment files in an e-mail communications server
WO2003017659A1 (en) * 2001-08-21 2003-02-27 Sony Corporation Information processing system, information processing apparatus, and method
US7917581B2 (en) * 2002-04-02 2011-03-29 Verizon Business Global Llc Call completion via instant communications client
US7849140B2 (en) 2002-08-29 2010-12-07 Oracle America, Inc. Peer-to-peer email messaging
US7363244B2 (en) * 2002-11-08 2008-04-22 Palo Alto Research Center Incorporated Methods, apparatus, and program products for inferring service usage
US7565425B2 (en) * 2003-07-02 2009-07-21 Amazon Technologies, Inc. Server architecture and methods for persistently storing and serving event data
US7409406B2 (en) * 2003-09-08 2008-08-05 International Business Machines Corporation Uniform search system and method for selectively sharing distributed access-controlled documents
US20050108368A1 (en) * 2003-10-30 2005-05-19 Aditya Mohan Method and apparatus for representing data available in a peer-to-peer network using bloom-filters
US7730207B2 (en) * 2004-03-31 2010-06-01 Microsoft Corporation Routing in peer-to-peer networks
JP2006236178A (ja) * 2005-02-28 2006-09-07 Try Group:Kk 通信管理システム
US7522618B2 (en) * 2005-03-18 2009-04-21 Panasonic Corporation Communication apparatus, communication system and communication method
US8184641B2 (en) * 2005-07-20 2012-05-22 Verizon Business Global Llc Method and system for providing secure communications between proxy servers in support of interdomain traversal
US20080195597A1 (en) 2007-02-08 2008-08-14 Samsung Electronics Co., Ltd. Searching in peer-to-peer networks
US20090037529A1 (en) 2007-07-31 2009-02-05 Samsung Electronics Co., Ltd. Data sharing in a group of peers with limited resources
US20090049132A1 (en) 2007-08-15 2009-02-19 Moshe Livne Gutovski Device, system, and method of routing electronic mail
CN101398820B (zh) * 2007-09-24 2010-11-17 北京启明星辰信息技术股份有限公司 一种大规模关键词匹配方法
US8924505B2 (en) * 2008-12-31 2014-12-30 Opera Software Asa Method and device for configuring a user agent to operate as a web server
US20110082941A1 (en) * 2009-10-06 2011-04-07 Electronics And Telecommunications Research Institute Method of providing direct communication in internet protocol network
WO2012087188A1 (en) * 2010-12-20 2012-06-28 Telefonaktiebolaget L M Ericsson (Publ) Searching in peer to peer networks

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050044144A1 (en) * 2002-04-29 2005-02-24 Dale Malik Instant messaging architecture and system for interoperability and presence management
KR20100037137A (ko) * 2007-07-10 2010-04-08 콸콤 인코포레이티드 피어-투-피어 네트워크에서 피어 발견 내에서 식별자들을 통신하는 코딩 방법들
US20100082648A1 (en) * 2008-09-19 2010-04-01 Oracle International Corporation Hash join using collaborative parallel filtering in intelligent storage with offloaded bloom filters
US20100318795A1 (en) 2009-06-11 2010-12-16 Qualcomm Incorporated Bloom filter based device discovery

Also Published As

Publication number Publication date
EP2503804A1 (en) 2012-09-26
JP5711849B2 (ja) 2015-05-07
EP2503804B1 (en) 2017-05-03
US9667713B2 (en) 2017-05-30
CN103348633A (zh) 2013-10-09
WO2012129121A1 (en) 2012-09-27
CN103348633B (zh) 2016-08-10
US20120246301A1 (en) 2012-09-27
JP2014514815A (ja) 2014-06-19
KR20120107880A (ko) 2012-10-04

Similar Documents

Publication Publication Date Title
KR101397834B1 (ko) 상이한 서비스 제공자들 사이의 피어-투-피어 접속들을 관리하기 위한 장치 및 방법
KR101597295B1 (ko) 보안 인스턴트 메시징을 위한 시스템 및 방법
TWI458369B (zh) 用於建立及使用備用通信頻道之裝置及方法
US9319467B2 (en) Apparatus and method for efficiently and securely exchanging connection data
JP5628998B2 (ja) ユーザをオンラインセッションに招待するための装置及び方法
EP2540059B1 (en) Apparatus and method for matching users for online sessions
AU2012262053A1 (en) System and method for secure instant messaging

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
AMND Amendment
E601 Decision to refuse application
AMND Amendment
X701 Decision to grant (after re-examination)
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20170420

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20180417

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20190417

Year of fee payment: 6