KR101597295B1 - 보안 인스턴트 메시징을 위한 시스템 및 방법 - Google Patents

보안 인스턴트 메시징을 위한 시스템 및 방법 Download PDF

Info

Publication number
KR101597295B1
KR101597295B1 KR1020137034859A KR20137034859A KR101597295B1 KR 101597295 B1 KR101597295 B1 KR 101597295B1 KR 1020137034859 A KR1020137034859 A KR 1020137034859A KR 20137034859 A KR20137034859 A KR 20137034859A KR 101597295 B1 KR101597295 B1 KR 101597295B1
Authority
KR
South Korea
Prior art keywords
user
service
mobile device
mobile devices
data
Prior art date
Application number
KR1020137034859A
Other languages
English (en)
Other versions
KR20140025553A (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 KR20140025553A publication Critical patent/KR20140025553A/ko
Application granted granted Critical
Publication of KR101597295B1 publication Critical patent/KR101597295B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/22—Arrangements for preventing the taking of data from a data transmission channel without authorisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/062—Pre-authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/58—Message adaptation for wireless communication

Abstract

보안 인스턴스 메시징을 위한 시스템 및 방법이 설명된다. 예를 들어, 한 실시예에서, 제1 사용자는 인스턴트 메시징 세션을 위한 제2 사용자를 제2 사용자의 ID 코드로 식별한다. 응답하여, 제1 사용자는 제2 사용자에 대한 네트워크 정보 및 제2 사용자와 연관된 공개 키(public key)를 제공받는다. 그러면 제1 사용자는 제2 사용자의 공개 키와 개인 키(private key)를 이용하여 인스턴트 메시지를 암호화한다. 한 실시예에서, 제1 사용자는 제2 사용자의 공개 키를 이용하여 인스턴트 메시지의 콘텐츠(예를 들어, 임의의 텍스트 및/또는 첨부물)를 암호화하고 제1 사용자의 개인 키를 이용하여 그 콘텐츠에 서명한다. 암호화된 메시지는 제1 사용자로부터 제2 사용자로 전송된다. 그러면 제2 사용자는 제2 사용자의 개인 키를 이용하여 인스턴트 메시지를 해독하고 제1 사용자의 공개 키로 서명을 검증한다.

Description

보안 인스턴트 메시징을 위한 시스템 및 방법{SYSTEM AND METHOD FOR SECURE INSTANT MESSAGING}
우선권 주장
본 출원은 2011년 6월 3일 출원된 미국 가출원 번호 제61/492,903호의, 35 U.S.C §119(e) 하의 출원일의 혜택을 주장한다.
발명의 분야
본 발명은 일반적으로 컴퓨터 네트워킹 분야에 관한 것이다. 더 구체적으로는, 본 발명은 보안 인스턴트 메시징을 위한 개선된 장치 및 방법에 관한 것이다.
피어-투-피어("P2P") 컴퓨팅이란, 컴퓨팅 노드들이 그들의 자원의 일부를 다른 네트워크 참여자들에게 직접 이용가능하게 하는 컴퓨팅 노드들로 구성된, 분산형 네트워크 아키텍쳐를 말한다. P2P 네트워크의 피어들은, 서버가 자원을 공급하고 클라이언트가 자원을 소비하는 종래의 클라이언트-서버 모델과는 대조적으로, 서로간에 직접적 통신 채널을 설정하고 클라이언트와 서버 양쪽 모두로서 행동한다.
인스턴트 메시징 및 화상 채팅과 같은 많은 현재의 P2P 애플리케이션들은 피어들간에 전송되는 기저 콘텐츠를 보호하기 위한 충분한 보안 수단을 제공하지 않는다. 따라서, 피어들을 식별하고 네트워크를 통해 보안된 P2P 트랜잭션을 제공하기 위한 개선된 기술이 요구된다.
첨부된 도면들과 연계한 이하의 상세한 설명으로부터 본 발명의 더 나은 이해를 얻을 수 있다.
도 1은 한 그룹의 모바일 장치 및 서비스가 네트워크를 통해 통신하는 네트워크 아키텍쳐를 나타낸다.
도 2a 내지 도 2c는 한 실시예의 접속 데이터 교환(CDX) 서비스, 중매자 서비스(matchmaker service) 및/또는 초대 서비스 사이의 트랜잭션을 나타낸다.
도 3은 티켓 데이터 구조의 한 실시예를 나타낸다.
도 4는 CDX 서비스에 의해 구현되는 방법의 한 실시예를 나타낸다.
도 5는 모바일 장치에 의해 구현되는 방법의 한 실시예를 나타낸다.
도 6은 1차 및 2차 통신 채널들을 통해 접속된 한 그룹의 모바일 장치를 나타낸다.
도 7은 모바일 장치가 1차 및 2차 통신 채널들 중에서 선택하기 위한 한 실시예를 나타낸다.
도 8a 및 도 8b는 1차 및 2차 통신 채널들을 통해 접속된 한 그룹의 모바일 장치와 그 결과의 네트워크 토폴로지를 나타낸다.
도 9는 1차 및 2차 통신 채널들 중에서 선택하기 위한 컴퓨터-구현된 방법의 한 실시예를 나타낸다.
도 10은 디렉토리 서비스 및 푸시 통보 서비스를 포함한, 한 그룹의 모바일 장치 및 서비스가 네트워크를 통해 통신하는 네트워크 아키텍쳐를 나타낸다.
도 11은 한 실시예의 초대 서비스, 푸쉬 통보 서비스, 및 접속 데이터 교환(CDX) 서비스 사이의 트랜잭션을 나타낸다.
도 12는 한 실시예의 초대 서비스, 푸쉬 통보 서비스, 및 중계 서비스 사이의 트랜잭션을 나타낸다.
도 13은 2개 이상의 모바일 장치들 사이에 중계 접속을 설정하기 위한 중계 서비스의 한 실시예를 나타낸다.
도 14는 NAT 호환성을 판정하기 위한 NAT 호환성 차트의 한 실시예를 나타낸다.
도 15는 온라인 애플리케이션에 대해 모바일 장치들을 매치하기 위한 중매자 서비스의 한 실시예를 나타낸다.
도 16은 사용자들/장치들을 매치하기 위한 방법의 한 실시예를 나타낸다.
도 17a 내지 도 17d는 사용자들/장치들을 매치하기 위해 수행되는 예시적인 일련의 테이블 업데이트를 나타낸다.
도 18은 상이한 매치 정합 변수(match fit variable)들을 이용하여 사용자들/장치들을 매치하기 위한 방법을 나타낸다.
도 19는, 애플리케이션에 대한 애플리케이션 프로그래밍 인터페이스(API)와, 한 세트의 서비스와 통신하기 위한 서비스 API를 나타내는 프레임워크를 도시한다.
도 20은 애플리케이션에 대한 API, 서비스들과 통신하기 위한 게임 데몬 및 게임 서비스 모듈을 갖는 게임 프레임워크의 한 실시예를 나타낸다.
도 21은 API 구현 소프트웨어 컴포넌트 및 API 호출 소프트웨어 컴포넌트의 한 실시예를 나타낸다.
도 22는 운영 체제들, 서비스들, 및 애플리케이션들 사이에서 API 호출이 이루어지는 한 실시예를 나타낸다.
도 23은 예시적 컴퓨터 시스템 아키텍쳐의 한 실시예를 나타낸다.
도 24는 예시적 컴퓨터 시스템 아키텍쳐의 또 다른 실시예를 나타낸다.
도 25는 복수의 상이한 서비스 제공자를 통해 접속되는 복수의 사용자를 나타낸다.
도 26은 사용자들의 위치를 식별하기 위한 블룸 필터(bloom filter)를 채용하는 본 발명의 실시예를 나타낸다.
도 27은 블룸 필터를 이용하기 위한 방법의 한 실시예를 나타낸다.
도 28은 블룸 필터를 이용하기 위한 방법의 또 다른 실시예를 나타낸다.
도 29는 본 발명의 한 실시예에 따른 포인트-투-포인트(P2P) 접속을 설정하는 2명의 사용자를 나타낸다.
도 30은 특정한 서비스 제공자에 의해 이용되는 중계 서비스를 통한 P2P 접속을 설정하는 2명의 사용자를 나타낸다.
도 31은 중계 서비스를 통해 P2P 접속을 설정하기 위한 본 발명의 또 다른 실시예를 나타낸다.
도 32는 본 발명의 한 실시예에서 채용되는 RFC 3894 헤더를 갖는 RTP 패킷을 나타낸다.
도 33은 푸시 통보 서비스 및 보안 인스턴트 메시징 서비스를 나타낸다.
도 34는 보안 인스턴트 메시징 세션을 설정하기 위한 방법의 한 실시예를 나타낸다.
도 35는 보안 인스턴트 메시징 세션을 설정하기 위한 방법의 또 다른 실시예를 나타낸다.
도 36은 신원 서비스 및 애플리케이션 인증 서비스를 포함하는 시스템 아키텍쳐를 나타낸다.
도 37은 사용자를 보안 인증하기 위한 방법의 한 실시예를 나타낸다.
도 38은 캐싱 및 지문(fingerprint)을 이용한 인증 효율을 개선하는 본 발명의 한 실시예를 나타낸다.
요약
보안 인스턴스 메시징을 위한 시스템 및 방법이 설명된다. 예를 들어, 한 실시예에서, 제1 사용자는 인스턴트 메시징 세션을 위한 제2 사용자를 제2 사용자의 ID 코드로 식별한다. 응답하여, 제1 사용자는 제2 사용자에 대한 네트워크 정보와 제2 사용자와 연관된 공개 키(public key)를 제공받는다. 그러면 제1 사용자는 제2 사용자의 공개 키와 개인 키(private key)를 이용하여 인스턴트 메시지를 암호화한다. 한 실시예에서, 제1 사용자는 제2 사용자의 공개 키를 이용하여 인스턴트 메시지의 콘텐츠(예를 들어, 임의의 텍스트 및/또는 첨부물)를 암호화하고 제1 사용자의 개인 키를 이용하여 그 콘텐츠에 서명한다. 암호화된 메시지는 제1 사용자로부터 제2 사용자로 전송된다. 그러면 제2 사용자는 제2 사용자의 개인 키를 이용하여 인스턴트 메시지를 암호해독하고 제1 사용자의 공개 키로 서명을 검증한다.
바람직한 실시예의 상세한 설명
네트워크 상에서 1차 및/또는 백업 피어-투-피어("P2P") 통신 채널을 설정하고, 유지하며, 이용하기 위한 장치, 방법, 및 머신-판독가능한 매체의 실시예들을 이하에서 설명한다. P2P 세션 동안 각각 사용자들을 초대하고 사용자들을 매치하기 위한 초대 서비스 및 중매자 서비스도 역시 설명된다. 추가적으로, 소정의 명시된 조건 하에서 사용자들이 중계 접속을 설정하는 것을 허용하는 중계 서비스가 설명된다. 마지막으로, 애플리케이션 개발자들이 본 명세서에서 설명되는 다양한 협력 온라인 특징들을 이용하는 애플리케이션을 설계할 수 있게 하는 애플리케이션 프레임워크 및 연관된 애플리케이션 프로그래밍 인터페이스(API; application programming interface)가 설명된다.
상세한 설명 전체를 통틀어, 설명의 목적을 위해, 많은 구체적인 세부사항이 본 발명의 철저한 이해를 제공하기 위하여 개시된다. 그러나, 본 발명은 일부의 이러한 구체적인 세부사항 없이도 실시될 수 있다는 것은 당업자에게 명백할 것이다. 다른 예들에서, 본 발명의 기저 원리를 모호하게 하는 것을 피하기 위하여 공지된 구조 및 장치들은 도시되지 않고 블록도 형태로 도시된다.
접속 데이터를 효율적으로 및 안전하게 교환하기 위한 장치 및 방법
도 1에 나타낸 바와 같이, 본 발명의 한 실시예에서 구현된 일반적 네트워크 토폴로지는, 네트워크(120)를 통해 서로간에 및 하나 이상의 서비스(110-112)와 각각 통신하는, 한 그룹의 "클라이언트" 또는 "피어" 모바일 컴퓨팅 장치(A-D)(120-123)를 포함할 수 있다. 도 1에서는 하나의 네트워크 클라우드(cloud)로서 나타내지만, "네트워크"(120)는, 인터넷과 같은 공중 네트워크와, 몇 가지 예를 들자면, 로컬 Wi-Fi 네트워크(예를 들어, 802.11n 홈 무선 네트워크 또는 무선 핫스팟), 근거리 이더넷 네트워크, 셀룰러 데이터 네트워크(예를 들어, 3G, Edge 등), 및 WiMAX 네트워크와 같은 사설 네트워크를 포함하는 다양한 상이한 컴포넌트들을 포함할 수 있다. 예를 들어, 모바일 장치 A(120)는 네트워크 링크(125)로 표시된 홈 Wi-Fi 네트워크에 접속될 수 있고, 모바일 장치 B(121)는 네트워크 링크(126)로 표시된 3G 네트워크(예를 들어, UMTS(Universal Mobile Telecommunications System), HSUPA(High-Speed Uplink Packet Access) 등)에 접속될 수 있고, 모바일 장치 C(122)는 네트워크 링크(127)로 표시된 WiMAX 네트워크에 접속될 수 있고, 모바일 장치(123)는 네트워크 링크(128)로 표시된 공중 Wi-Fi 네트워크에 접속될 수 있다. 모바일 장치들(120-123)을 접속시키는 로컬 네트워크 링크(125-128) 각각은, 게이트웨이 및/또는 NAT 장치(도 1에 도시되지 않음)를 통해 인터넷과 같은 공중 네트워크에 결합됨으로써, 공중 네트워크를 통해 다양한 모바일 장치(120-123)들 사이의 통신을 가능케할 수 있다. 그러나, 만일 2개의 모바일 장치들이 동일한 로컬 또는 사설 네트워크(예를 들어, 동일한 Wi-Fi 네트워크) 상에 있다면, 이 2개의 장치들은 그 로컬/사설 네트워크를 통해 직접 통신함으로써, 공중 네트워크를 바이패스할 수 있다. 물론, 본 발명의 기저 원리는 임의의 특정 세트의 네트워크 타입이나 네트워크 토폴로지로 제한되지 않는다는 점에 유의해야 한다.
도 1에 나타낸 모바일 장치(120-123) 각각은, 접속 데이터 교환(CDX) 서비스(110), 중매자 서비스(111), 및 초대 서비스(112)와 통신할 수 있다. 한 실시예에서, 서비스(110-112)는 서버와 같은 하나 이상의 물리적 컴퓨팅 장치를 통해 실행되는 소프트웨어로서 구현될 수 있다. 도 1에 도시된 바와 같이, 한 실시예에서, 서비스(110-112)는, 동일한 엔티티(예를 들어, 동일한 데이터 서비스 제공자)에 의해 관리되고 네트워크(120)를 통해 모바일 장치(120-123) 각각에 의해 액세스가능한 더 큰 데이터 서비스(100)의 콘텍스트 내에서 구현될 수 있다. 데이터 서비스(100)는 다양한 타입의 서버들과 데이터베이스를 접속하는 근거리 네트워크(예를 들어, Ethernet-기반의 LAN)를 포함할 수 있다. 데이터 서비스(100)는 또한, 데이터를 저장하기 위한 하나 이상의 스토리지 영역 네트워크(SAN; storage area network)를 포함할 수도 있다. 한 실시예에서, 데이터베이스는 모바일 장치(120-123) 각각과 이들 장치들의 사용자들에 관련된 데이터(예를 들어, 사용자 계정 데이터, 장치 계정 데이터, 사용자 애플리케이션 데이터 등)를 저장 및 관리한다.
한 실시예에서, 중매자 서비스(111)는 명시된 조건 세트에 기초하여 협력 P2P 세션에 대해 2개 이상의 모바일 장치를 매치시킬 수 있다. 예를 들어, 2개 이상의 모바일 장치들의 사용자들은 특정한 멀티플레이어 게임을 플레이하는데 관심을 가질 수도 있다. 이러한 경우, 중매자 서비스(111)는, 각 사용자의 숙련도, 각 사용자의 연령, 매치 요청의 시간, 매치 요청된 특정의 게임, 및 다양한 게임-특유의 변수들과 같은 변수들에 기초하여 게임에 참여할 한 그룹의 모바일 장치들을 식별할 수 있다. 제한이 아니라 예로서, 중매자 서비스(111)는 특정 게임의 플레이시에 비슷한 숙련도의 사용자들을 매치하려고 시도할 수 있다. 추가적으로, 성인은 다른 성인과 매치되고, 아이들은 다른 아이들과 매치될 수 있다. 게다가, 중매자 서비스(111)는, 이들 요청이 수신된 순서에 기초하여 사용자 요청을 우선순위화할 수도 있다. 본 발명의 기저 원리는, 임의의 특정한 세트의 매치 기준이나 임의의 특정한 타입의 P2P 애플리케이션으로 제한되지 않는다.
이하에서 상세히 기술되는 바와 같이, 매치 요청에 응답하여, 중매자 서비스(111)는, 효율적이고 안전한 방식으로 P2P 세션을 설정하기 위해 필요한 접속 데이터를 모든 매치된 참여자들이 수신하는 것을 보장하기 위해, CDX 서비스(110)와 조율할 수 있다.
한 실시예에서, 초대 서비스(112)는 또한, 협력적 P2P 세션에 참여하기 위한 모바일 장치들을 식별한다. 그러나, 초대 서비스(112)의 경우, 참여자들 중 적어도 한 명이 다른 참여자에 의해 특정적으로 식별된다. 예를 들어, 모바일 장치 A(120)의 사용자는 모바일 장치 B(121)의 사용자와의 협력적 세션을 특정적으로 요청할 수 있다(예를 들어, 사용자 ID 또는 전화 번호로 모바일 장치 B를 식별). 중매자 서비스(111)에서와 같이, 초대 요청에 응답하여, 초대 서비스(112)는, 효율적이고 안전한 방식으로 P2P 세션을 설정하기 위해 필요한 접속 데이터를 모든 참여자들이 수신하는 것을 보장하기 위해, 참여자 집합을 식별하고 CDX 서비스(110)와 조율할 수 있다.
전술된 바와 같이, 한 실시예에서, CDX 서비스(110)는 2개 이상의 모바일 장치들 사이에서 P2P 세션을 설정하는데 요구되는 접속 데이터에 대한 중앙 교환점으로서 동작한다. 구체적으로는, CDX 서비스의 한 실시예는 모바일 장치 요청에 응답하여 NAT 횡단 데이터(때때로 "홀 펀치" 데이터라고 함)를 생성하여 외부 서비스 및 클라이언트가 각각의 모바일 장치의 NAT를 통해 통신할 수 있게(즉, 장치에 도달하기 위해 NAT를 통한 "홀을 펀치"할 수 있게) 한다. 예를 들어, 한 실시예에서, CDX 서비스는 모바일 장치와 통신하는데 필요한 외부 IP 주소와 포트를 검출하여 이 정보를 모바일 장치에 제공한다. 한 실시예에서, CDX 서비스는 또한, 중매자 서비스(111) 및 초대 서비스(112)에 의해 발생된 모바일 장치의 목록을 수신 및 처리하고, (이하에서 상세히 기술되는) 그 목록에 포함된 모바일 장치들 각각에 접속 데이터를 효율이고도 안전하게 배포한다.
한 실시예에서, 모바일 장치들과 CDX 서비스(110) 사이의 통신은 사용자 데이터그램 프로토콜("UDP") 소켓과 같은 비교적 가벼운 네트워크 프로토콜을 이용하여 설정된다. 당업자라면 알 수 있는 바와 같이, UDP 소켓 접속은 패킷 신뢰성, 순서화, 또는 데이터 완전성을 보장하기 위한 핸드쉐이킹 대화를 요구하지 않으므로, TCP 소켓 접속과 같은 과도한 패킷 처리 오버헤드를 소비하지 않는다. 결과적으로, UDP의 가볍고 무상태 성향(stateless nature)은 방대한 수의 클라이언트로부터의 작은 질의들에 응답하는 서버들에 유용하다. 게다가, TCP와는 달리, UDP는 (패킷들이 로컬 네트워크 상의 모든 장치에 전송되는) 패킷 브로드캐스팅 및 (패킷들이 로컬 네트워크 상의 장치들의 서브셋에 전송되는) 멀티캐스팅과 호환된다. 후술되는 바와 같이, UDP가 이용될수 있더라도, 세션키를 이용하여 NAT 횡단 데이터를 암호화함으로써 CDX 서비스(110) 상에서 보안이 유지될 수 있다.
CDX 서비스(110)에 의해 이용되는 낮은 오버헤드의 가벼운 네트워크 프로토콜과는 대조적으로, 한 실시예에서, 모바일 장치(120-123)와 중매자 서비스(111) 및/또는 초대 서비스(112) 사이의 통신은, SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 접속에 의존하는 HTTPS(Hypertext Transfer Protocol Secure)와 같은 고유의 보안 네트워크 프로토콜을 이용하여 설정된다. 이들 프로토콜과 연관된 세부사항은 당업자에게 공지되어 있다.
도 2a는 CDX 서버에 의해 구현될 수 있는 예시적인 일련의 트랜잭션을 나타낸다. CDX 서비스의 한 실시예의 동작을 설명할 때, 이하의 용어들은 다음과 같은 의미를 가질 것이다.
접속 데이터(Connection Data) - 이것은 잠재적 피어들이 피어-투-피어 세션을 설정하기 위해 서로 교환할 필요가 있는 정보이다. 이하에서는 이 정보가 어떻게 교환될 수 있는지에 대한 메커니즘의 실시예들이 설명된다.
CDX 서버(CDX Server) - 한 실시예에서 CDX 서버는 인증된 엔티티들이 임의 데이터(arbitrary data)를 교환하는 것을 허용하는 인증된 멀티캐스터 리플렉 터(authenticated multicast reflector)이다. 이 데이터는 페이로드라 불린다.
CDX 세션(CDX Session) - CDX 세션이란 CDX 서버를 통해 서로 통신할 수 있는 한 그룹의 클라이언트 장치를 말한다. 세션의 일부인 각 클라이언트 장치에는 CDX 티켓(CDX Ticket)이 할당된다. 각 세션은, 개개의 세션을 식별하거나 참조하는데 이용될 수 있는 큰 정수인 고유 CDX 세션 ID(CDX　Session ID)를 가진다.
CDX 요청(CDX Request) - 클라이언트 장치로부터 CDX 서버로 전송되는 요청. 요청은 일반적으로 2개의 부분으로 구성된다: CDX 티켓 및 페이로드. 본 실시예에서는, 페이로드는 세션키로 암호화된 접속 데이터이다.
CDX 응답(CDX Response) - CDX 응답은, CDX 서버가 CDX 세션의 멤버로부터 CDX 요청을 수신할 때 CDX 세션 내의 다른 장치들에 되"반사"되는 것이다. 이것은 주어진 CDX 요청에서 이용되는 CDX 티켓의 CDX 티켓 서터브에 페이로드를 부가함으로써 구성된다.
CDX 티켓(CDX Ticket) - CDX 티켓은 CDX 세션의 멤버들에 페이로드를 전송하는 방법을 CDX 서버에게 말해준다. 한 실시예에서, 이것은 위조나 무단변경(tampering)을 방지하기 위해 CDX 티켓 키로 "서명"된다. 도 3에 나타낸 바와 같이, 한 실시예에서, CDX 티켓은 다음과 같은 정보를 포함한다:
한 실시예에서는 암호화 또는 모호화(obfuscate)되지 않은 세션 ID(301).
한 실시예에서는 암호화 또는 모호화되지 않은 세션의 참여자 수(302).
(한 실시예에서는 암호화 또는 모호화되지 않은) 이 티켓이 참조하는 세션의 참여자의 인덱스(303).
경과시에 티켓이 무효한 것으로 간주되는 (한 실시예에서는 암호화 또는 모호화되지 않은) 만료 시간/날짜(304).
한 실시예에서는 CDX 티켓 키를 이용하여 암호화되는, 세션의 각 참여자에 대한 CDX 홀-펀치 데이터(305-306).
티켓이 진본임을 보장하는 "디지털 서명"으로서 역할하는, CDX 티켓 키를 이용한 메시지 인증 코드(307).
CDX 티켓 스터브(CDX Ticket Stub) - CDX 티켓의 첫 번째 부분에서 CDX 홀-펀치 데이터 및 메시지 인증 코드를 제외한 부분.
페이로드(Payload) - 이것은 CDX 요청 및 CDX 응답의 두 번째 부분이다. 페이로드는 클라이언트 장치가 CDX 세션 내의 다른 장치들에 전달하기를 원하는 데이터이다. 본 실시예에서는, 페이로드는 세션키로 암호화된 접속 데이터이다. CDX 서버는 한 실시예에서는 페이로드를 암호화하지 않고, 미변경 상태로 단순 전달한다.
세션키(Session Key) - 이것은 접속 데이터를 암호화하기 위해 클라이언트에 의해 이용되는 키이다. 한 실시예에서, 이 키는 CDX 서버에게 알려지지 않는다. 본 실시예에서는, 세션 키는 중매 서비스에 의해 생성되어 클라이언트들에게 그들 개개의 CDX 티켓과 함께 전송된다.
CDX 티켓 키(CDX Ticket Key) - 이것은 CDX 티켓을 생성하고 "서명"하는데 이용되는 키이다. CDX 티켓 키는, CDX 서버와, 후술되는 바와 같이 중매 서비스 및/또는 초대 서비스일 수 있는 CDX 티켓을 생성하는 서비스에 의해서만 알려진다.
CDX 홀-펀치 요청(CDX Hole-Punch Request) - CDX 서버로부터 CDX 홀-펀치 데이터를 얻는데 이용되는 특별한 타입의 CDX 요청.
CDX 홀-펀치 데이터(CDX Hole - Punch Data) - 이것은 CDX 서버가 어떻게 정보를 본래 요청한 클라이언트에 전송하는지를 기술하는 불투명 데이터 블롭(opaque data blob)이다. 이것은 CDX 홀-펀치 요청을 CDX 서버에 전송함으로써 얻어진다. CDX 홀-펀치 데이터는 CDX 티켓이 생성될 수 있기 이전에 CDX 세션의 각 클라이언트로부터 수집되어야 한다. CDX 홀-펀치 데이터(때때로 "NAT 횡단 데이터"라고 함)는 요청측 장치의 공개 IP 주소 및 포트를 포함할 수 있다.
이제 도 2a를 참조하면, 한 실시예에서, 모바일 장치 A(120) 및 모바일 장치 B(121)는, 하나 이상의 다른 컴퓨팅 장치와의 P2P 접속을 요구하는 멀티플레이어 게임이나 협력 채팅 세션과 같은 협력 애플리케이션을 실행하고 있을 수 있다. 201a에서, 모바일 장치 A(120)는 CDX 서버(110)에 CDX 홀-펀치 요청을 전송한다. 그 다음, CDX 서버(110)는 202a에서 CDX 홀-펀치 데이터로 응답한다. 한 실시예에서, 홀 펀치 데이터는 모바일 장치 A의 공개 IP 주소 및 포트 및/또는 모바일 장치 A의 NAT를 통해 홀을 펀치하는데 요구되는 임의의 다른 데이터(예를 들어, 모바일 장치 A의 NAT 타입을 정의하는 NAT 타입 데이터)를 포함한다. 각각 201b 및 202b에서 모바일 장치 B에 대해 유사한 트랜잭션이 수행된다.
203a 및 203b에서, 모바일 장치 A 및 B는, 다음으로, CDX 홀-펀치 데이터를 포함하는 매치 요청을, 임의의 추가 매치 기준(후술)과 함께, 중매 서비스에 전송한다. 이 단계에서, 모바일 장치 A 및 B는 P2P 접속을 설정하는데 필요한 접속 데이터를 구성하기 시작할 수 있다. 이것은, (예를 들어, NAT 횡단 서비스에 의해), 예를 들어, 표준 인터넷 접속 확립("ICE": Internet Connectivity Establishment) 트랜잭션과 같은 트랜잭션을 이용하여 달성될 수 있다. 그러나, 본 발명의 기저 원리는 접속 데이터를 결정하기 위한 임의의 특정 메커니즘으로 제한되지 않는다.
한 실시예에서, 일단 중매 서비스(111)가 매치 기준을 이용하여 한 세트의 클라이언트 장치를 발견하고 나면, 고유 CDX 세션 ID, CDX 세션의 각 멤버에 대한 고유 CDX 티켓과, 고유 세션 키를 생성할 수 있다. 한 실시예에서, 중매 서비스(111)는 고유 CDX 티켓 키를 이용하여 CDX 티켓에 대한 CDX 홀-펀치 데이터를 암호화할 수 있다. 204a 및 204b에서, 중매 서비스는, 그 다음, 모바일 장치 A 및 B 각각에게 그들의 CDX 티켓 및 세션 키를 전송할 수 있다.
모바일 장치 A는 CDX 티켓과 세션 키를 수신하고, 세션 키를 이용하여 그 이전에 결정된 접속 데이터를 암호화하여, 페이로드를 형성한다. 한 실시예에서, 모바일 장치 A는 구성된 페이로드를 CDX 티켓에 첨부함으로써 CDX 요청을 구성한다. 205a에서, 모바일 장치 A는 CDX 서버(110)에 CDX 요청을 전송한다. 모바일 장치 B는 또한, 205b에서 동일한 동작을 수행하고 CDX 서버에 요청을 전송한다.
206a에서, CDX 서버(110)는 CDX 요청을 수신하고, (예를 들어, 메시지 인증 코드(307)에 기초하여) 티켓이 유효하고 진본임을 보장하기 위해 티켓을 검사한다. 만일 CDX 티켓이 무효라면, 그 요청이 누락된다. 한 실시예에서, CDX 서버는, 그 다음, CDX 티켓 키를 이용하여 CDX 티켓에 포함된 CDX 홀-펀치 데이터 세트를 암호해독한다. 한 실시예에서, CDX 티켓 키는 티켓들과 함께 전송될 수도 있는 만료 시간/날짜를 포함할 수 있다. CDX 서비스(110) 및 중매자 서비스(111)는 암호화/암호해독을 위해 2개의(또는 그 이상의) 상이한 CDX 티켓 키를 저장할 수 있으며, 그 첫 번째는 현재 활성인 CDX 티켓 키이고, 두 번째는 첫 번째의 만료 시간/날짜에 도달시 활성으로 될 CDX 티켓 키이다. 티켓의 수신시에, CDX 서비스(110)는 어떤 티켓 키를 사용할지를 결정하기 위해 만료 시간/날짜를 판독할 수 있다. CDX 티켓 키가 만료되면, CDX 서비스(110) 및 중매자 서비스(111)는 각각, (현재의 티켓 키가 만료한 후에 사용될 다음 키가 되는) 새로운 티켓 키를 생성할 수 있다. 한 실시예에서, CDX 서비스(110) 및 중매자 서비스(111)는 2개의 티켓 키들에서의 일관성을 보장하기 위해 동일한 키 생성 알고리즘을 실행한다. 예를 들어, 고정된 간격으로 새로운 인증 코드가 생성되는 공지된 RSA SecurID 인증 메커니즘에 이용되는 것과 같은 기술들이 이용될 수도 있다. 한 실시예에서, 새로운 CDX 티켓 키는 일별로(on daily basis) 생성된다. 그러나, 본 발명의 기저 원리는 CDX 티켓 키를 생성하기 위한 임의의 특정 메커니즘으로 제한되지 않는다.
동일한 동작들이 모바일 장치 B에 대해 206b에 도시된 바와 같이 수행될 수 있다. CDX 서버는 CDX 요청으로부터 CDX 응답을 구성한 다음, CDX 홀-펀치 데이터를 이용하여 CDX 응답을 CDX 세션의 참여자들에게 전송(207a에서는 모바일 장치 B에게 전송하고 207b에서는 모바일 장치 A에게 전송)한다.
모바일 장치 B는 CDX 서버로부터 CDX 응답(207a)을 수신한다. 클라이언트 장치 B는 세션 ID가 그 자신의 CDX 티켓의 세션 ID와 매치됨을 보장하기 위해 CDX 티켓 스터브를 검사한다. 모바일 장치 B는 그 다음, 세션 키를 이용하여 페이로드를 암호해독하여, 모바일 장치 A로부터의 접속 데이터를 산출한다. 그 다음, 모바일 장치 B는 모바일 장치 A로부터의 접속 데이터를 이용하여 P2P 세션을 설정하는 프로세스를 시작한다. 한 실시예에서, 이들은 표준 ICE 트랜잭션을 포함한다. 그러나, 본 발명의 기저 원리는 P2P 통신을 설정하기 위한 임의의 특정 메커니즘으로 제한되지 않는다.
전술된 바와 같이, 한 실시예에서, 모바일 장치 A와 B는 중매자 서비스(111)와 통신하기 위해 (예를 들어, HTTPS 요청/응답 트랜잭션을 이용하여) HTTPS(Hypertext Transfer Protocol Secure) 세션을 설정하고, CDX 서비스와 통신하기 위해 UDP 소켓을 설정한다. 매치 요청(204a, 204b)은, NAT 타입과, 각각의 모바일 장치에 대해 앞서 결정된 홀 펀치 데이터(예를 들어, 공개 IP 주소 및 포트)를 포함할 수 있다. 멀티플레이어 게임을 포함하는 한 실시예에서, 각각의 매치 요청은 (예를 들어, 고유 플레이어 ID 코드를 이용한) 각 모바일 장치 상의 플레이어, 각 사용자가 플레이하기를 원하는 게임, 게임에 참여할 플레이어의 수, 및/또는 원하는 게임과 연관된 다른 게임 구성 변수를 식별할 수 있다. 제한이 아닌 예로서, 게임과 연관된 게임 구성 변수는, 난이도(예를 들어, 쉬움, 보통, 어려움), 사용자의 나이(예를 들어, "13세 미만"), 게임의 소구역(sub-region)(예를 들어, "레벨 2"), 및/또는 플레이어의 숙련도(예를 들어, 전문가, 초보자, 중간)를 포함할 수 있다. 이하에서 상세히 설명되는 바와 같이, 이들 변수들은 때때로 게임 "버켓(bucket)"이라고 하며, 고유 "버켓 ID"를 이용하여 식별된다. 각각의 게임은 상이한 게임 구성 변수들을 식별하기 위한 상이한 세트의 버켓 ID들을 포함할 수 있다.
한 실시예에서, 모바일 장치 B는 208a 및 209a에서 접수확인(acknowledgement)을 전송한다. 마찬가지로, 모바일 장치 A의 접수확인은 208b 및 209b에서 전송된다. 만일 모바일 장치 A 또는 B의 접수확인이 지정된 기간 후에 수신되지 않는다면, 접속 데이터(207a)가 모바일 장치 B(212)에 재전송될 수 있다. CDX 서비스(110)가 재시도를 개시하거나 및/또는 모바일 장치 A(120)가 재시도를 개시할 수도 있다.
도 2b는 3개의 상이한 모바일 장치(120-122)가 CDX 서비스 및 중매자 서비스(111)를 이용하여 P2P 접속에 대해 협상하는 더 상세한 예를 나타낸다. 도 2b는 또한, 접속을 설정하기 위해 모바일 장치(120-122)에 의해 이용되는 2개의 추가 서비스를 나타낸다: NAT 타입을 결정하기 위한 NAT 횡단 서비스(291)와, (예를 들어, ICE 접속 데이터 트랜잭션을 이용하여) 각각의 모바일 장치에 대한 전체 접속 데이터를 결정하기 위한 NAT 횡단 서비스(290). 그러나, 본 발명의 기저 원리를 따르기 위해 별개의 서비스들이 요구되는 것은 아니라는 점에 유의해야 한다. 예를 들어, 대안적 실시예에서, 이들 서비스(290-291) 각각에 의해 수행되는 NAT 횡단 기능은 CDX 서비스(110) 및/또는 중매자 서비스(111) 내에 직접 통합될 수 있다. 마찬가지로, NAT 횡단 서비스(290-291) 양쪽 모두에 의해 수행되는 기능은 하나의 NAT 횡단 서비스 내에 통합될 수 있다. 요약하면, 본 발명의 기저 원리를 따르기 위해 도 2b에 도시된 구체적인 기능 분리가 요구되지는 않는다.
이제 도 2b의 구체적인 세부사항을 참조하면, 220에서, 모바일 장치 A는 NAT 타입 요청을 NAT 횡단 서비스(291)에 전송한다. 응답하여, NAT 횡단 서비스(291)는 모바일 장치 A에 의해 이용되는 NAT 타입을 결정하기 위해 일련의 트랜잭션을 구현하는 단계를 포함하는 다양한 공지된 기술을 이용할 수 있다. 예를 들어, NAT 횡단 서비스(291)는 모바일 장치 A의 NAT 상에서 상이한 IP 주소와 포트를 개방하고 상이한 IP/포트 조합을 이용하여 이들 포트를 통해 모바일 장치 A와 통신하려고 시도할 수 있다. 이런 방식으로, 모바일 장치 A에 의해 이용되는 NAT는 전술된 NAT 타입(예를 들어, 풀 콘(full cone), 제한된 콘(restricted cone), 포트 제한된 콘(port restricted cone), 대칭) 또는 대안적 NAT 타입 중 하나로서 분류될 수 있다. 그 다음, 이 정보는 예시된 바와 같이 모바일 장치 A(120)에 제공될 수 있다.
221에서, 모바일 장치 A(120)는 CDX 서비스(110)에 대한 NAT 횡단 요청을 개시한다. 응답하여, CDX 서비스(110)는 이 요청에 이용되는 공개 IP 주소와 공개 포트 번호를 판독하여 이 정보를 모바일 장치 A(120)에 되전송할 수 있다. 전술된 바와 같이, 장치가 NAT 뒤에 있다면, 그 공개 포트 및 IP 주소는 각각 그 사설 포트 및 IP 주소와 상이할 것이다. 따라서, 이용중인 NAT의 타입에 따라, 공개 IP 주소 및 포트는 모바일 장치에 도달하기 위해 NAT를 통해 "홀을 펀치"하기 위해 이용될 수도 있다.
222에서, 모바일 장치 A(120)는 중매자 서비스(111)에 매치 요청(222)을 전송한다. 전술된 바와 같이, 한 실시예에서, 모바일 장치 A는 HTTPS(Hypertext Transfer Protocol Secure) 세션(예를 들어, HTTPS 요청/응답 트랜잭션을 이용하여)을 이용하여 중매자 서비스(111)와 통신한다. 매치 요청은, 모바일 장치 A(120)에 대해 앞서 결정된 NAT 타입과 홀 펀치 데이터(예를 들어, 공개 IP 주소 및 포트)를 포함할 수 있다. 멀티플레이어 게임을 포함하는 실시예에서, 매치 요청은 (예를 들어, 고유 플레이어 ID 코드를 이용하여) 모바일 장치 A 상의 플레이어, 사용자가 플레이하기를 원하는 게임, 게임에 참여할 플레이어의 수, 및/또는 (도 2a에 관하여 전술된 바와 같은) 원하는 게임과 연관된 다른 게임 구성 변수를 식별할 수 있다.
223-225에서, 모바일 장치 B(121)에 대해 트랜잭션(220-222)에 대응하는 한 세트의 트랜잭션이 수행되고, 226-228에서, 모바일 장치 C(122)에 대해 트랜잭션(220-222)에 대응하는 한 세트의 트랜잭션이 수행된다. 따라서, 트랜잭션(228)에 후속하여, 중매자 서비스(111)는 모바일 장치(120-122) 3개 모두에 대해 매치 요청을 수신하였다. 이 특정 예에서, 매치 요청 결과, 멀티플레이어 게임과 같은 특정의 협력 세션에 대해 모바일 장치들(120-122)이 매치된다(예를 들어, 이들 모바일 장치들의 사용자들은 동일하거나 유사한 변수 세트에 의해 동일한 게임을 선택했을 수도 있음으로써, 결과적으로 중매자 서비스(111)에 의해 매치가 이루어진다).
중매자 서비스(111)는 각각의 매치 요청에 포함된 데이터를 이용하여 티켓 A를 생성하고, 229에서 모바일 장치 A에 전송한다; 티켓 B를 생성하고, 230에서 모바일 장치 B에 전송한다; 그리고, 티켓 C를 생성하고, 231에서 모바일 장치 C에 전송한다. 도 2b에 도시되지는 않았지만, 중매자 서비스(111)는 각각 모바일 장치 A, B, 및 C에 티켓 A, B, 및 C를 푸시하기 위해 (예를 들어, 도 11 및 도 12에 나타낸 푸시 통보 서비스(1050)와 같은) 푸시 통보 서비스를 이용할 수 있다. 티켓 A, B, 및 C에 대해 이용되는 티켓 데이터 구조의 한 실시예가 도 3을 참조하여 설명된다.
232에서, 모바일 장치 A(120)는 그 자신의 접속 데이터를 결정하기 위하여 NAT 횡단 서비스(290)와 통신한다. 한 실시예에서, 이것은 표준 ICE 접속 데이터 트랜잭션을 포함할 수 있다. 앞서 언급한 바와 같이, 접속 데이터는 모바일 장치 A(120)에 대한 공개/사설 IP 주소, 포트, 및 NAT 타입을 포함할 수 있다.
모바일 장치 A(120)는 그 접속 데이터를 티켓 A에 첨부하고, 233에서, 접속 데이터와 함께 티켓 A를 CDX 서비스(110)에 전송한다. 한 실시예에서, CDX 서비스(110)는 전술된 바와 같이 티켓 A를 처리하고, 234에서, 모바일 장치 B(121) 및 모바일 장치 C(122)에 (암호화될 수도 있는) 접속 데이터를 전송한다. 이들 트랜잭션에 대해, CDX 서비스(110)는 티켓 A에 포함된 모바일 장치 B 및 C에 대한 NAT 횡단 데이터를 이용할 수 있다.
236-238에서, 티켓 B를 이용하여 트랜잭션(232-234)에 대응하는 한 세트의 트랜잭션이 수행되고, 238-240에서, 티켓 C에 대해 트랜잭션(232-234)에 대응하는 한 세트의 트랜잭션이 수행된다. 따라서, 트랜잭션(240)에 후속하여, 각각의 모바일 장치들(120-122) 사이에서 접속 데이터가 공유되었다. 접속 데이터를 이용하여, 모바일 장치 A와 B 사이, 모바일 장치 A와 C 사이, 및 모바일 장치 A와 C 사이에 P2P 세션이 설정된다.
도 2c에 나타낸 바와 같이, 초대 서비스(112)는 (중매자 서비스(111) 대신에 또는 이에 추가하여) CDX 서비스(110)와 함께 이용될 수 있다. 한 실시예에서, 초대 서비스(112)는 특정의 모바일 장치 및/또는 사용자와의 P2P 접속을 위한 초대 서비스를 처리한다. 초대 서비스(112)는 무상태(stateless) 서비스(즉, 각 무선 장치들 사이의 트랜잭션의 현재 상태를 바꾸지(tack) 않는 서비스)로서 구현될 수 있다.
이 특정 예를 참조하면, 250에서, 모바일 장치 A(120)는 NAT 타입 요청을 NAT 횡단 서비스(291)에 전송한다. 응답하여, NAT 횡단 서비스(291)는, (몇 가지가 위에서 설명되었던) 모바일 장치 A에 의해 이용되는 NAT 타입을 결정하기 위한 다양한 공지된 기술을 이용할 수 있다. 251에서, 모바일 장치 A(120)는 CDX 서비스(110)에 대한 NAT 횡단 요청을 개시한다. 응답하여, CDX 서비스(110)는 이 요청에 이용되는 공개 IP 주소와 공개 포트 번호를 판독하여 이 정보를 모바일 장치 A(120)에 되전송할 수 있다. 전술된 바와 같이, 장치가 NAT 뒤에 있다면, 그 공개 포트 및 IP 주소는 각각 그 사설 포트 및 IP 주소와 상이할 것이다. 따라서, 이용중인 NAT의 타입에 따라, 공개 IP 주소 및 포트는 모바일 장치에 도달하기 위해 NAT 장치를 통해 "홀을 펀치"하기 위해 이용될 수 있다.
중매자 서비스에서와 같이, 한 실시예에서, 각 모바일 장치는 HTTPS(Hypertext Transfer Protocol Secure) 세션을 이용하여 (예를 들어, HTTPS 요청/응답 트랜잭션을 이용하여) 초대 서비스(112)와 통신한다.
252에서, 모바일 장치 A(120)는 모바일 장치 A의 NAT 횡단 데이터(예를 들어, NAT 타입, 공개 IP 주소/포트)를 포함하는 초대 요청을 초대 서비스(112)에 전송한다. (이하에서 더 상세히 설명되는) 푸시 통보 서비스를 이용하는 한 실시예에서, 초대 요청은 모바일 장치 A의 푸시 토큰(push token)도 포함할 수 있다. 초대 요청(252)은 또한, 한 명 이상의 다른 사용자들/장치들, 이 경우에는, 모바일 장치 B(121) 및 모바일 장치 C(122)의 사용자들을 식별하는 식별 코드를 포함할 수 있다. 다양한 상이한 식별 코드 타입들이 이용될 수도 있다. 예를 들어, 멀티플레이어 게임의 경우, 식별 코드들은 게임-특유의 플레이어 ID 코드를 포함할 수 있다. 음성/화상 채팅 세션의 경우, 식별 코드들은 모바일 장치 A 사용자의 "친구(buddy)" 목록으로부터 한 명 이상의 사용자들을 식별하는 전화 번호 또는 고유 ID 코드를 포함할 수 있다.
한 실시예에서, 초대 서비스(112)는 초대 요청으로부터 식별 코드를 판독하고, 모바일 장치들(B 및 C) 각각의 위치파악을 위해 등록 데이터베이스(도시되지 않음)에서 룩업(lookup)을 수행한다. 한 특정 실시예에서, 모바일 장치들(B 및 C) 각각은 초대 서비스(112)로부터 푸시 통보를 수신하는 푸시 서비스에 앞서 등록되었다. 이와 같이, 본 실시예에서, 초대 서비스(112)는, 각각 253 및 254에서 모바일 장치 B(121) 및 모바일 장치 C(122)에 초대 요청을 푸시하는 푸시 통보 서비스를 이용한다. 푸시 통보 서비스에 관련된 추가 상세사항이 이하에서, 그리고 앞서 참조한 푸시 통보 애플리케이션에서 설명된다(예를 들어, 도 11 및 도 12와 관련 본문 참조)
한 실시예에서, 초대 요청(253 및 254)은, 도 3에서 예시되고 도 2a 및 도 2b를 참조하여 전술된 티켓 데이터 구조를 포함한다. 구체적으로는, 모바일 장치 B에 전송된 티켓은 모바일 장치 A 및 B를 식별하는 암호화된 목록을 포함하고, 모바일 장치 C에 전송된 티켓은 모바일 장치 A 및 C를 식별하는 암호화된 목록을 포함한다. 한 실시예에서, 초대 서비스(112)는 아직 모바일 장치 B의 NAT 횡단 데이터를 갖지 않을 수 있기 때문에, 253에서의 "티켓"은 모바일 장치 B를 식별하는 다른 정보를 포함할 수 있다. 예를 들어, 중계 서비스 및 푸시 통보 서비스(예를 들어, 도 11 및 도 12 참조)를 이용하는 실시예들에 관하여 이하에서 개시되는 바와 같이, 253에서의 "티켓"은, 모바일 장치 A에 대한 NAT 횡단 데이터, 장치 A의 ID 코드, 장치 A의 푸시 토큰, 장치 B의 ID 코드, 및 모바일 장치 B에 대한 푸시 토큰을 포함할 수 있다. 모바일 장치(A 및 C)에 대하여 동일한 타입의 정보가 254에서 제공될 수 있다.
255에서, 모바일 장치 B는 NAT 횡단 서비스(291)와 통신하여 그 NAT 타입을 결정할 수 있고, 256에서, 모바일 장치 B는 CDX 서비스(110)와 통신하여 그 NAT 횡단 데이터(예를 들어, 공개 IP 주소/포트)를 결정할 수 있다. 257에서, 모바일 장치 B는, 모바일 장치 A 및 모바일 장치 B의 식별 코드, NAT 횡단 데이터, 및 푸시 통보 서비스가 이용되는 경우에는 모바일 장치 A 및 B에 대한 푸시 토큰을 포함하는 초대 서비스(112)에 초대 응답을 전송한다. 258에서, 모바일 장치 B는 NAT 횡단 서비스(290)와 통신함으로써 그 현재의 접속 데이터를 검색할 수 있다. 259에서, 모바일 장치 B는 그 현재의 접속 데이터와 함께 그 티켓(티켓 B)을 CDX 서비스(110)에 전송한다. 응답하여, CDX 서비스(110)는 전술된 바와 같이 티켓을 처리하고 접속 데이터를 모바일 장치 A(120)에 포워딩한다.
모바일 장치 B의 초대 응답의 수신시에, 초대 서비스(112)는 모바일 장치 A에 대한 암호화된 티켓을 생성하여 260에서 그 티켓을 모바일 장치 A에 전송할 수 있다. 한 실시예에서, 이 티켓은, 모바일 장치 A 및 B에 대해 NAT 횡단 데이터, NAT 타입 및 푸시 토큰(푸시 통보 서비스가 이용되는 경우)을 포함한다. 도 2c에 관하여 설명된 "티켓"은 중매자 서비스(111)에 관하여 설명된 "티켓"에 대한 데이터 구조와 동일하거나 상이할 수 있다. 예를 들어, 전술된 바와 같은 암호화된 "티켓"의 생성이 아니라, 초대 서비스(112)는 단순히 각 모바일 장치와의 초대 세션을 식별하기 위한 고유 세션 ID를 생성할 수 있다.
261에서, 모바일 장치 A는 NAT 횡단 서비스(290)와 통신함으로써 그 현재의 접속 데이터를 검색한다. 그 다음, 모바일 장치 A는 그 접속 데이터를 티켓에 첨부하고, 262에서, 그 접속 데이터와 함께 티켓을 CDX 서비스(110)에 전송할 수 있다. CDX 서비스(110)는 전술된 바와 같이 티켓을 처리하고 모바일 장치 A의 접속 데이터를 모바일 장치 B에 포워딩한다. 마지막으로, 263에서, 모바일 장치 A 및 B는 직접 P2P 접속을 개방하기 위해 교환된 접속 데이터를 이용한다. 후술되는 바와 같이, 모바일 장치 A 및 B의 NAT 타입들이 비호환인 경우, 모바일 장치 A와 B 사이의 통신을 가능케하기 위해 중계 서비스가 이용될 수 있다.
264-272에서, 모바일 장치 C(122)와 모바일 장치 A는 모바일 장치 B와 A에 대하여 255-263에서 설명된 바와 같은 P2P 접속을 설정하기 위하여 일련의 트랜잭션을 실행할 수 있다. 구체적으로는, 624에서, 모바일 장치 C(122)는 그 NAT 타입을 결정하기 위해 NAT 횡단 서비스(291)와 통신하며, 265에서, 그 NAT 횡단 데이터(예를 들어, 공개 IP 주소/포트)를 결정하기 위해 CDX 서비스(110)와 통신한다. 266에서, 모바일 장치 C는 모바일 장치 C와 모바일 장치 A의 NAT 타입, NAT 횡단 데이터 및 푸시 토큰(푸시 통보 서비스가 이용되는 경우)을 포함하는 초대 응답을 전송한다. 267에서, 모바일 장치 C는 NAT 횡단 P2P 서비스(290)를 통해 그 현재의 접속 데이터를 검색하고, 268에서, 모바일 장치 C는 그 접속 데이터를 티켓 C에 첨부하여 티켓 C를 CDX 서비스(110)에 전송한다. CDX 서비스(110)는 전술된 바와 같이 티켓을 처리하고 모바일 장치 C의 접속 데이터를 모바일 장치 A(120)에 포워딩한다.
269에서, 모바일 장치 A(120)는, 모바일 장치 A 및 C 양쪽 모두의 NAT 타입, NAT 횡단 데이터, 및 푸시 토큰(푸시 서비스가 이용되는 경우)을 포함하는 모바일 장치 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 또는 전화 번호를 푸시 토큰과 연관시킨다. 만일 디렉토리에서 푸시 토큰이 식별될 수 있다면, 푸시 통보 서비스는 푸시 통보를 모바일 장치에 전송하기 위해 그 푸시 토큰을 이용할 수 있다. 한 실시예에서, 푸시 통보 서비스는, 본 출원인의 양수인에 의해 설계되고, 예를 들어, 앞서 참조된 푸시 통보 애플리케이션에서 설명된 Apple Push Notification Service (“APNS”)이다. 그러나, 도 2a 내지 도 2c에 도시된 본 발명의 실시예들에서는 푸시 통보 서비스가 요구되지 않는다는 점에 유의해야 한다. 예를 들어, CDX 서비스(110)가 본 명세서에 설명된 그 동작을 수행하기 위해 푸시 통보는 요구되지 않는다.
도 4는 접속 데이터를 교환하기 위해 CDX 서비스(110)에 의해 구현될 수 있는 방법을 나타내고, 도 5는 접속 데이터를 교환하고 P2P 접속을 설정하기 위해 모바일 장치에 의해 구현될 수 있는 방법을 나타낸다. 이들 방법들의 소정 양태들이 도 1 내지 도 2c를 참조하여 이미 전술되었다. 특히, 이들 방법들은 도 1 내지 도 2c에 도시된 네트워크 아키텍쳐의 콘텍스트 내에서 구현될 수 있지만, 이들은 이러한 아키텍쳐로 제한되는 것은 아니다. 한 실시예에서, 방법들은, 프로세서에 의해 실행될 때 방법들의 동작들이 수행되게 하는 프로그램 코드로 구현된다. 이 프로그램 코드는 프로세서에 의해 실행되는 동안 랜덤 액세스 메모리("RAM")와 같은 머신-판독가능한 매체에 저장될 수도 있다. 프로세서는 범용 프로세서(예를 들어, Intel® CoreTM 프로세서) 또는 특별 목적 프로세서일 수 있다. 그러나, 방법들은 하드웨어, 소프트웨어, 및 펌웨어의 임의 조합을 이용하여 구현될 수 있다. 또한, 프로그램 코드는 하드 디스크 드라이브와 같은 비휘발성 저장 장치, 광 디스크(예를 들어, 디지털 비디오 디스크 또는 컴팩트 디스크), 또는 플래시 메모리 장치와 같은 비휘발성 메모리에 저장될 수 있다.
이제 도 4에 도시된 방법을 참조하면, 401에서, 특정 모바일 장치 ―이 예에서는 "모바일 장치 A"에 대한 NAT 횡단 요청(때때로 "홀 펀치" 요청이라고도 함)이 수신된다. 402에서, NAT 횡단 응답이 생성되어 모바일 장치 A에 전송된다. 한 실시예에서, NAT 횡단 응답을 생성하는 것은, 모바일 장치 A의 현재의 공개 IP 주소/포트 및/또는 NAT 타입을 결정하는 것을 포함할 수 있다.
후속해서 모바일 장치 A에 대한 티켓이, 전술된 중매자 서비스(111) 또는 초대 서비스(112)와 같은 티켓-생성 엔티티에 의해 생성되어 암호화될 수 있다. 403에서, (장치 A 및 하나 이상의 다른 장치에 대한) NAT 횡단 데이터 및 장치 A에 대한 접속 데이터를 포함하는 모바일 장치 A에 대해 생성된 티켓("티켓 A")이 수신된다. 404에서, 메시지 인증 코드를 이용하여 티켓이 인증되고, 티켓을 암호화하기 위해 티켓 생성 엔티티에 의해 이용되는 것과 동일한 CDX 티켓 키를 이용하여 홀 펀치 데이터가 암호해독된다. 앞서 언급한 바와 같이, 한 실시예에서, CDX 티켓 키와 연관된 만료 시간/날짜를 이용하여 올바른 CDX 티켓 키가 식별된다.
405에서, 모바일 장치에 대한 NAT 횡단 데이터가 추출된다. 406에서, 모바일 장치 A에 대한 접속 데이터가 NAT 횡단 데이터를 이용하여 피어들 각각에게 전송된다. 407에서, 피어들 각각으로부터 접수확인이 수신된다. 408에서 판정되는 바와 같이, 모든 피어들로부터 접수확인이 수신되지는 않았다면, 409에서, 응답하지 않은 피어들에게 모바일 장치 A의 접속 데이터가 재전송된다. 408에서 판정되는 바와 같이 모든 접속 데이터가 접수확인되면, 방법이 종료한다.
한 실시예에서, 도 4에 도시된 방법은, 각 피어가 P2P 접속을 설정하는데 요구되는 접속 데이터를 수신하는 것을 보장하기 위해 P2P 트랜잭션에 관여된 각 피어에 대해 수행될 수 있다.
도 5는 본 명세서에 설명된 본 발명의 실시예에 따라 모바일 장치에 의해 수행될 수 있는 방법을 나타낸다. 501에서, NAT 횡단 요청이 전송되고, 502에서, NAT 횡단 응답이 수신된다. 전술된 바와 같이, 응답에 포함된 NAT 횡단 데이터는 요청측 장치의 공개 포트/IP 주소를 포함할 수 있다. 503에서, NAT 횡단 데이터를 포함하는 매치 요청이 전송된다. 후속해서 모바일 장치에 대한 티켓이 전술된 중매자 서비스(111) 또는 초대 서비스(112)와 같은 티켓-생성 엔티티에 의해 생성되어 암호화될 수 있다. 전술된 티켓 데이터 구조에 대한 대안으로서, 중매자 서비스(111) 및/또는 초대 서비스(112)는 단순히 고유 세션 ID를 이용하여 각 참여자를 식별할 수 있다.
504에서, 티켓이 수신되고; 505에서, 모바일 장치에 대한 접속 데이터가 티켓에 첨부되고; 506에서, 접속 데이터를 갖는 티켓이 전송된다. 507에서, 하나 이상의 다른 피어들과의 P2P 접속을 확립하는데 필요한 접속 데이터가 수신된다. 508에서, 하나 이상의 다른 무선 장치가 506에서 전송된 접속 데이터를 수신했음을 나타내는 접수확인이 수신된다. 모든 접수확인이 수신되지는 않았다면, 510에서, 접수확인을 보내오지 않은 모바일 장치에 대해 접속 데이터가 재전송된다. 만일 509에서 판정되는 바와 같이 모든 접수확인이 수신되었다면, 다른 모바일 장치와의 P2P 세션을 설정하기 위해 507에서 수신된 접속 데이터가 이용된다.
백업 통신 채널을 설정하고 이용하기 위한 장치 및 방법
현재의 모바일 장치들은 다양한 상이한 통신 채널들을 통해 통신할 수 있다. 예를 들어, Apple iPhoneTM은 Wi-Fi 네트워크(예를 들어, 802.11b, g, n 네트워크); 3G 네트워크(예를 들어, UMTS(Universal Mobile Telecommunications System) 네트워크, HSUPA(High-Speed Uplink Packet Access) 네트워크 등); 및 (PAN(personal area network)이라고 알려진) Bluetooth 네트워크를 통해 통신할 수 있다. 향후의 모바일 장치들은, 몇 가지 예를 들자면, WiMAX, IMT(International Mobile Telecommunication) Advanced, 및 LTE(Long Term Evolution) Advanced와 같은 추가적인 통신 채널들을 통해 통신할 수 있을 것이다.
동작시에, 현재의 모바일 장치들은 한 세트의 가용 채널들로부터 하나의 1차 통신 채널을 선택한다. 예를 들어, 모바일 장치들은 종종, 이용가능하다면 Wi-Fi 접속을 선택하고 Wi-Fi 접속이 이용가능하지 않다면 셀룰러 데이터 접속(예를 들어, UMTS 접속)을 선택하도록 구성된다.
본 발명의 한 실시예에서, 한 그룹의 모바일 장치가 처음에, 표준 ICE 접속 데이터 교환을 이용하여 및/또는 전술된 접속 데이터 교환 기술을 이용하여 1차 피어-투-피어("P2P") 통신 채널을 설정한다. 그 다음 모바일 장치들은 임의의 1차 채널이 고장날 경우 백업 채널로서 이용되는 하나 이상의 2차 통신 채널을 설정하기 위해 1차 채널을 통해 접속 데이터를 교환할 수 있다. 한 실시예에서, 2차 통신 채널은 이들 채널들을 통해 "심박" 패킷(heartbeat packet)을 주기적으로 전송함으로써 NAT 방화벽을 통해 개방으로 유지된다.
본 명세서에서 사용될 때, 통신 "채널"이란, 2개의 모바일 장치 사이의 전체 네트워크 경로(full network path)를 말하고, 통신 "링크"란 통신 경로에서 이용되는 하나의 특정한 접속을 말한다. 예를 들어, 장치 A가 Wi-Fi 접속을 이용하여 인터넷에 접속되고 장치가 B가 3G 접속을 이용하여 인터넷에 접속되면, 장치 A와 장치 B 사이의 "채널"은 Wi-Fi 링크 및 3G 링크 양쪽 모두에 의해 정의된다; 장치 A는 Wi-Fi 통신 "링크"를 가지며; 장치 B는 3G 통신 "링크"를 가진다. 이와 같이, 장치 A가 Wi-Fi 링크로부터 3G 링크로 전환하면, 장치 B의 3G 링크가 동일하게 유지된다는 사실에도 불구하고 장치 A와 장치 B 사이의 "채널"이 변한다.
모바일 장치가 1차 및 2차 통신 채널을 설정하는 구체적인 예가 이제 도 6에 관하여 설명될 것이다. 그러나, 본 발명의 기저 원리는 도 6에 도시된 특정 세트의 통신 링크 및 통신 채널로 제한되지 않는다는 점에 유의해야 한다.
도 6에서, 모바일 장치 A(601)는 NAT 장치(611)를 갖는 통신 링크(605)를 통해, 및 NAT 장치(612)를 갖는 통신 링크(606)를 통해 네트워크(610)(예를 들어, 인터넷)에 접속할 수 있다. 마찬가지로, 모바일 장치 C(603)는 NAT 장치(613)를 갖는 통신 링크(609)를 통해, 및 NAT 장치(613)를 갖는 통신 링크(610)를 통해 네트워크(610)에 접속할 수 있다. 제한이 아닌 예로서, 통신 링크(605 및 609)는 3G 통신 링크이고, 통신 링크(606 및 610)는 Wi-Fi 통신 링크일 수 있다.
결과적으로, 이 예에서, 모바일 장치 A와 모바일 장치 B 사이에 설정될 수 있는 상이한 4개의 통신 채널이 존재한다: 링크(605 및 609)를 이용하는 제1 채널; 링크(605 및 610)을 이용하는 제2 채널; 링크(606 및 609)를 이용하는 제3 채널; 링크(606 및 610)을 이용하는 제4 채널. 한 실시예에서, 모바일 장치 A 및 B는 이들 채널들 중 하나를 우선순위화 방법에 기초하여 1차 통신 채널로서 선택할 것이며, 나머지 3개 채널을 백업 채널로서 선택할 것이다. 예를 들어, 한 우선순위화 방법은, 1차 채널로서 가장 높은 대역폭을 갖는 채널을 선택하고 2차 채널로서 나머지 채널들을 이용하는 것일 수 있다. 만일 2개 이상의 채널이 비슷한 대역폭을 가진다면, 우선순위화 방법은 (사용자가 하나 이상의 채널 이용에 대한 요금을 지불한다고 가정하면) 최소 비용의 채널을 선택하는 것을 포함할 수 있다. 대안으로서, 우선순위화 방법은 1차 채널로서 최소 비용의 채널을 선택하고, 각 채널의 비용이 동일하면, 가장 높은 대역폭의 채널을 선택할 수 있다. 본 발명의 기저 원리와 여전히 호환되면서 다양한 상이한 우선순위화 방법이 구현될 수 있다.
모바일 장치 A(601) 및 C(603)는 (예를 들어, CDX 서비스(110)를 통해 접속 데이터를 교환함으로써) 1차 통신 채널을 설정하기 위해 전술된 기술들을 이용할 수 있다. 대안으로서, 모바일 장치(601, 603)는 접속 데이터를 교환하기 위해 표준 인터넷 접속 설정("ICE") 트랜잭션을 구현할 수 있다. 1차 채널이 어떻게 설정되는지에 관계없이, 일단 설정되면, 모바일 장치 A(601) 및 C(603)는 1차 통신 채널을 통해 2차 통신 채널에 대한 접속 데이터를 교환할 수 있다. 예를 들어, 도 6의 1차 통신 채널이 통신 링크(606) 및 통신 링크(609)를 포함한다면, 이 접속은, 일단 설정되면, 통신 링크(605 및 609)를 포함하는 2차 통신 채널에 대한 접속 데이터를 교환하는데 이용될 수 있다. 이 예에서, 1차 통신 채널을 통해 교환된 접속 데이터는, 모바일 장치들 각각에 대한 공개 및 사설 IP 주소/포트를 포함한, NAT(611) 및 NAT(613)에 대한 NAT 횡단 데이터 및 NAT 타입 데이터를 포함할 수 있다.
일단 2차 통신 채널이 설정되고 나면, 이 채널들은 심박 패킷을 이용하여 개방된 상태로 유지된다. 예를 들어, 장치 A가 작은 "심박" 패킷을 장치 C에 주기적으로 전송하거나, 및/또는 장치 A가 작은 "심박" 패킷을 장치 C에 주기적으로 전송하여, 2차 채널들에 대해 이용되는 NAT 포트들이 개방 상태로 유지되는 것을 보장한다(NAT는 종종 비활성으로 인해 포트를 폐쇄할 것이다). 심박 패킷들은 페이로드가 없는 UDP 패킷일 수 있지만, 본 발명의 기저 원리는 이 특정 패킷 형태로 제한되는 것은 아니다. 심박 패킷들은 그들의 페이로드 헤더에 자체-식별 타입 필드를 갖춘 UDP 패킷일 수 있고, 채널 생존 시간값을 포함할 수 있지만 이것으로 제한되지는 않는, 선택적인 추가-포맷팅된 정보를 포함할 수 있다.
도 7에 나타낸 바와 같이, 각각의 모바일 장치(601)는 1차 및 2차 통신 채널의 목록을 포함하는 데이터 구조(710)(예를 들어, 테이블, 텍스트 파일, 데이터베이스 등)를 저장하고 유지한다. 별개의 엔트리가 각 통신 채널에 대해 제공되며, 그 채널을 이용하는데 필요한 접속 데이터(예를 들어, 사설/공개 IP 주소, NAT 타입 등)와 그 채널의 현재 상태(예를 들어, 1차, 제1 2차, 제2 2차 등)를 포함한다.
한 실시예에서, 각각 통신 링크(605) 및 통신 링크(606)를 통한 통신을 위해 통신 인터페이스(701 및 702)가 이용된다. 고장 검출 모듈(705)이 모바일 장치(601) 상에서 실행되어 특정한 통신 인터페이스/링크가 고장나거나 지정된 임계치 아래로 저하된 때를 검출한다. 응답하여, 링크 관리 모듈(706)은 1차/2차 접속 데이터(710)를 판독하여 다음으로 가장 높은 우선순위를 갖는 2차 채널을 1차 채널로 승급할 수 있다. 2차 채널들의 우선순위화는, (예를 들어, 대역폭, 비용, 신뢰성 등에 기초하여) 1차 채널에 대해 앞서 언급한 것과 동일한 원리를 이용하여 달성될 수 있다. 일단 2차 채널이 선택되고 나면, 링크 관리 모듈(706)은 다른 모바일 장치들 상의 링크 관리 모듈에 링크 고장 표시를 전송하여, 이들 장치들에게 2차 통신 채널을 1차 통신 채널로 승급할 것을 지시할 수 있다. 그러면 이들 장치들은 선택된 1차 채널과 연관된 접속 데이터의 이용을 개시할 것이다.
한 실시예에서, 2차 통신 채널들 중 하나로의 전환을 강제하기 위해 1차 통신 채널의 완전한 "고장"이 요구되는 것은 아니다. 예를 들어, 한 실시예에서, 1차 통신 채널이 충분히 저하된다면(예를 들어, 특정한 대역폭, 비트레이트, 또는 신뢰성 임계치 아래), 2차 채널로의 변경이 본 명세서에 설명된 바와 같이 구현될 수 있다. 한 실시예에서, 2차 채널로의 전환은, 2차 채널이 현재의 1차 채널보다 더 나은 성능(예를 들어, 대역폭, 비트레이트 또는 신뢰성)을 지원할 수 있는 경우에만 수행된다.
도 8a는, 네트워크(610)에 직접 접속되고 사설 네트워크 접속(620)을 통해 장치 C(603)에 접속된 모바일 장치 B(602)가 추가된, 도 6에 도시된 네트워크 구성과 동일한 네트워크 구성을 나타낸다. 사설 네트워크(620)는, 예를 들어, 장치 B(602)와 장치 C(603) 사이의 Bluetooth PAN 접속일 수 있다. 이 예로부터, 1차 채널로부터 2차 채널로의 전환은 네트워크 토폴로지를 극적으로 변경시킬 수 있다는 것을 알 수 있다. 예를 들어, 도 8b에 도시된 바와 같이, 모바일 장치에 대한 1차 채널(801)이 통신 링크(609)를 포함하고(그 결과, 장치들 A, B, 및 C 사이에 직접적인 접속이 형성됨) 2차 채널이 사설 네트워크(620)를 포함한다면, 장치 A 및 장치 C가 사설 네트워크를 이용하여 통신할 수 있는 유일한 길은 장치 B를 통하는 것이기 때문에 네트워크 토폴로지는 도 8c에 나타낸 바와 같이 변경될 수 있다. 이것은 단 3개의 장치만을 갖는 간략화된 예이지만, 상당히 많은 수의 장치들이 이용되어, 결과적으로, 1차 및 2차 통신 채널 사이의 전환시에 다양한 상이한 네트워크 토폴로지 구성들이 발생할 수 있다.
2차 채널을 설정하고 유지하기 위한 방법의 한 실시예가 도 8에 나타나 있다. 한 실시예에서, 이 방법은 각 모바일 장치 상의 링크 관리 모듈(706)에 의해 실행될 수 있다. 그러나, 이 방법은 임의의 특정한 장치 구성으로 제한되는 것은 아니다.
901에서, 1차 P2P 통신 채널이 선택된다. 앞서 언급한 바와 같이, 미리정의된 우선순위화 방법에 기초하여 1차 채널이 선택될 수 있다. 예를 들어, 다른 통신 채널 타입들에 앞서 소정의 통신 채널 타입이 우선순위화될 수 있다. 채널들은, 대역폭, 사용 비용, 및/또는 신뢰성과 같은 변수들에 기초하여 우선순위화될 수도 있다.
902에서, 백업 P2P 통신 채널들이 설정된다. 한 실시예에서, 이것은 1차 통신 채널을 통해 모든 모바일 장치들 간에 접속 데이터를 공유함으로써 달성된다. 903에서, 백업 채널들이 유지된다. 한 실시예에서, 이것은 2차 통신 채널을 통해 주기적으로 (예를 들어, 주기적 심박 패킷의 형태로) 데이터를 전송하는 것을 포함한다.
904에서, 1차 P2P 채널이 고장나면(예를 들어, 특정 모바일 장치의 통신 링크가 다운되거나 모바일 장치가 통신 링크의 범위 바깥으로 이동한 이유 때문에), 905에서, 모바일 장치들은 가장 높은 우선순위의 백업 채널을 1차 채널로 승급한다. 한 실시예에서, 이것은 고장난 링크를 갖는 모바일 장치가 2차 채널을 통해 그 링크 고장 통보를 다른 장치들에 전송하는 것을 포함한다. 마지막으로, 906에서, 백업 채널이 1차 채널로 되고, 프로세스는 902로 되돌아간다(여기서, 임의의 추가 백업 채널들이 발견되고 우선순위화 방법에 추가된다).
피어-투-피어(P2P) 통신 채널을 설정하는 초대 서비스를 위한 장치 및 방법
도 10에 나타낸 바와 같이, CDX 서비스(110), 중매자 서비스(111) 및 초대 서비스(112)(이들의 일부 실시예는 앞서 설명되었음)에 추가하여, 본 발명의 한 실시예는 등록/디렉토리 서비스(1052), 푸시 통보 서비스(1050), 및 중계 서비스(1051)를 포함할 수 있다. 앞서 언급한 바와 같이, 한 실시예에서, 초대 서비스(112) 및/또는 중매자 서비스(111)는 등록된 모바일 장치를 식별하기 위해 등록/디렉토리 서비스(1052)를 이용하고 모바일 장치에 데이터를 푸시하기 위해 푸시 통보 서비스(1050)를 이용할 수 있다. 한 실시예에서, 모바일 장치가 네트워크 상에서 동작할 때, 모바일 장치는 "푸시 토큰"(때때로 푸시 통보 애플리케이션에서는 "통보 서비스 계정 식별자"라고 함)을 패스워드 보호된 사용자 ID 또는 전화 번호와 연관시킴으로써, 그 푸시 토큰을 등록/디렉토리 서비스(1052)에 의해 유지되는 데이터베이스에 등록한다. 등록 디렉토리에서 푸시 토큰이 식별된다면(예를 들어, 사용자 ID를 이용한 질의를 수행함으로써), 푸시 통보 서비스(1050)는 모바일 장치에 푸시 통보를 전송하기 위해 푸시 토큰을 이용할 수 있다. 한 실시예에서, 푸시 통보 서비스는, 본 출원인의 양수인에 의해 설계되고, 예를 들어, 앞서 참조된 푸시 통보 애플리케이션에서 설명된 Apple Push Notification Service (“APNS”)이다.
도 11은 2개의 모바일 장치 사이에 직접적 P2P 접속을 설정하기 위해 푸시 통보 서비스(1051)가 이용되는 본 발명의 한 실시예를 나타내고, 도 12는 중계 서비스(1051)를 통해 P2P 접속을 설정하는데 이용되는 실시예를 나타낸다. 후술되는 바와 같이, P2P 접속을 설정하기 위해 중계 서비스(1051)를 이용할지의 여부에 관한 결정은 모바일 장치들 사이의 직접적 P2P 접속의 설정 가능성에 기초(예를 들어, NAT 호환성 문제에 기초)할 수 있다.
이제 도 11을 참조하면, 1101에서, 모바일 장치 A(120)는 모바일 장치 B(121)를 초대하는 초대를 전송하여 모바일 장치 B를 P2P 통신 세션(예를 들어, 협력적 비디오 게임, P2P 비디오 채팅 등)에 초대한다. 한 실시예에서, 초대는, 특정한 온라인 애플리케이션 콘텍스트 내에서 모바일 장치 B(121)를 식별하는 사용자 ID 코드(및/또는 모바일 장치 B의 사용자)를 포함한다. 예를 들어, 사용자 ID 코드는 특정한 멀티플레이어 P2P 게임에 대한 플레이어 ID이고, 예를 들어, UUID(Universally Unique Identifier)의 형태를 취할 수 있다. 대안으로서, 일부 실시예들에서, ID 코드는 모바일 장치 B(121)의 전화 번호일 수 있다. 게임 ID 코드는, 모바일 장치 A가 모바일 장치 B에게 참여할 것을 초대하고 있는 멀티플레이어 게임을 식별하는데 이용될 수 있다. 버켓 ID는 (중매자 서비스에 관하여 본 명세서에 기술된 바와 같은) 그 게임에 대한 구성을 식별하는데 이용될 수 있다.
초대(1101)는 또한, 모바일 장치 A(120)를 식별하는 ID 코드, 및 모바일 장치 A와 연관된 NAT 횡단/접속 데이터(예를 들어, 모바일 장치 A에 대한 공개/사설 IP 주소, 및 장치 A의 NAT 장치에 대한 NAT 타입)를 포함할 수 있다. NAT 횡단/접속 데이터 또는 NAT 타입 데이터는, (예를 들어, 도 2a 내지 도 2c에 관하여 전술된 것과 같은 NAT 횡단, NAT 타입 및 접속 데이터 트랜잭션을 통해) 초대 요청(1101)에 앞서 모바일 장치 A에 의해 이전에 결정되었을 수 있다. 앞서 언급한 바와 같이, 초대 요청(1101)은 HTTPS 요청의 형태를 취할 수 있다. 또한, 추가 보안을 위해, 초대 요청(1101)은 미리명시된 인증국(pre-specified certificate authority)에 의해 서명된 클라이언트 인증서를 포함할 수 있다.
모바일 장치 B를 식별하는데 이용되는 ID 코드의 특정한 타입에 관계없이, ID 코드가 초대 서비스(112)에 의해 수신되고, 1102에서, 초대 서비스(112)는, 모바일 장치 B에 통보를 푸시하는데 이용되는 푸시 토큰("푸시 토큰-B")과 같은 통보 서비스 계정 식별자를 식별하기 위해 (도 11에 도시되지 않음) 디렉토리 서비스(1052)에서 룩업을 수행할 수 있다. 한 실시예에서, 룩업 동작은 초대가 허용되어야 하는지를 결정하기 위해 수회의 검사를 수행할 수 있다. 우선, 모바일 장치 A에 대한 식별 코드("ID-A")와 장치 A의 푸시 토큰("푸시 토큰-A")가 디렉토리 서비스 데이터베이스 내의 등록된 연관임을 확인할 수 있다. 룩업 동작(1102)은 또한, 모바일 장치 A의 사용자가 모바일 장치 B의 사용자를 초대하는 것이 허용되어 있다는 것을 확인할 수 있다(예를 들어, 모바일 장치 B의 사용자는 B의 친구로서 등록된 다른 사용자들만이 사용자 B를 초대할 수 있다고 명시할 수 있다; 또는 어떠한 초대도 허용되지 않는다고 명시할 수 있다). 한 실시예에서, 이들 검사 중 임의의 것이 실패하면, 초대는 취소되고, 초대 서비스(112)는 모바일 장치 A에 에러(error)를 반환한다.
본 실시예에서는 "푸시 토큰"이 설명되고 있지만, 본 발명의 기저 원리는 "푸시 토큰"의 이용이나 모바일 장치들을 인증하고 모바일 장치들에 통보를 푸시하기 위한 기타 임의의 특정 데이터 구조의 이용으로 제한되지 않는다는 점에 유의해야 한다.
한 실시예에서, 푸시 토큰이 식별된 후에, 초대 서비스(112)는, 초대 세션에 할당되고 모든 추가의 트랜잭션들에서 세션을 식별하는데 이용되는, 보안된 1회용 "세션 토큰"을 생성할 수 있다. 그 다음, 세션 토큰의 사본이 모바일 장치 A(120)에 되전송되고, 초대 요청과 함께 모바일 장치 B에 전송된다. 한 실시예에서, 세션 토큰은 전술된 티켓 데이터 구조와 함께 이용되고, 또 다른 실시예에서는, 세션 토큰만이 이용된다.
1103에서, 초대 서비스(112)는 푸시 요청을 푸시 통보 서비스(1050)에 전송한다. 한 실시예에서, 푸시 요청은, 모바일 장치 A에 대한 NAT 횡단 데이터, 장치 A의 ID 코드, 푸시 토큰-A, 장치 B의 ID 코드, 및 푸시 토큰-B를 포함할 수 있다. 한 실시예에서, 이 정보는 "티켓" 데이터 구조 내에 팩키징되고 전술된 바와 같이 암호화될 수 있다. 또 다른 실시예에서, 데이터는 단순히 초대 세션 ID와 함께 전송된다.
이 예에서 모바일 장치 B(121)는 푸시 통보 서비스(1050)에 등록되었기 때문에, 푸시 통보 서비스(1050)는 1104에서 모바일 장치 B(121)의 위치를 파악하고 모바일 장치 B에 초대 요청을 푸시할 수 있다. 푸시된 초대(1104)는, 세션 토큰, 모바일 장치 A의 NAT 횡단 데이터/접속 데이터, 및 모바일 장치 B의 ID 코드를 포함할 수 있다. 초대 요청에 응답하여, 모바일 장치 B는, 전술된 바와 같이 NAT 횡단 서비스 또는 CDX 서비스(110)를 호출함으로써 그 네트워킹 정보(예를 들어, NAT 횡단/접속 데이터, NAT 타입 등)를 결정할 수 있다.
1105에서, 모바일 장치 B는 초대를 수락한다. 수락(1105)은 초대 서비스(112)에 대한 HTTPS 호출의 형태를 취할 수 있고 (초대 요청에 관하여 앞서 언급된) 미리명시된 인증국에 의해 서명된 클라이언트 인증서를 포함할 수 있다. 한 실시예에서, 수락(1105)은 모바일 장치 A 및 B에 대한 ID 코드와, 모바일 장치 A 및 B에 대한 NAT 횡단/접속 데이터 및/또는 NAT 타입을 포함할 수 있다. 수락(1105)은 또한, 모바일 장치 A 및 B에 대한 푸시 토큰 및/또는 세션 토큰을 포함할 수 있다. 한 실시예에서, 수락(1105)은 또한, 이것이 이전의 실패한 직접 접속 시도로부터의 재시도인지의 여부에 관한 표시를 포함할 수 있다. 그러나, 또 다른 실시예에서, 수락(1105)은 재시도 표시를 포함하지 않는다. 오히려, 실패한 P2P 접속 시도의 검출시에, 2개의 모바일 장치 중 하나는 특별한 "중계 초대"를 초대 서비스(112)에 전송할 수 있다. 응답하여, 서비스는 (1201에서 시작하는) 도 12에 관하여 이하에서 설명되는 일련의 중계 트랜잭션을 직접 개시할 수 있다.
1106에서, 초대 서비스(112)는 모바일 장치들 A와 B 사이의 직접적 P2P 접속이 가능성있는지를 판정하기 위해 호환성 검사를 수행할 수 있다. 예를 들어, 한 실시예에서, 모바일 장치 B로부터 수신된 수락(1105)이 이것이 이전의 실패한 직접 접속 시도로부터의 재시도(또는 이전의 실패한 직접적 접속 시도의 지정된 회수)라는 것을 표시한다면, 초대 서비스는 직접적 P2P 접속이 가능성없다고 결론을 내릴 수 있다. 초대 서비스(112)는, 모바일 장치들 A와 B의 NAT 장치들이 직접적 P2P 접속을 지원하는지를 판정하기 위해 모바일 장치들 A와 B에 대한 NAT 타입 데이터를 비교할 수 있다. NAT 타입들의 소정 조합은 P2P 접속의 설정에 비호환인 것으로 알려져 있다. 예를 들어, 직접적 P2P 접속을 설정하기 위해 폐쇄형/방화벽형 NAT를 제외한 기타 임의의 NAT와 함께 풀 콘 NAT가 이용될 수 있다. 대조적으로, 대칭 NAT는 직접적 P2P 접속을 설정하기 위해 풀 콘 NAT와만 함께 이용될 수 있다. 본 발명의 한 실시예에서 다양한 NAT 타입을 결합할 가능성은 도 14에 도시된 NAT 호환성 테이블(1400)에 개시되어 있으며, 여기서 열(column)은 한 모바일 장치(예를 들어, 모바일 장치 A)의 NAT 타입을 나타내고 행(row)은 다른 모바일 장치(예를 들어, 모바일 장치 B)의 NAT 타입을 나타낸다. 셀 내의 "1.0"은 연관된 행과 열의 NAT 타입들이 호환형이고 "0.0"은 NAT 타입들이 비호환형임을 나타낸다.
한 실시예에서, 호환성 검사(1106)가 직접적 P2P 접속이 가능성없다고 판정하면, 초대 서비스(112)는 도 12에 관하여 이하에서 설명되는 바와 같이 중계 룩업 요청(1201)을 전송할 수 있다. 그러나, 호환성 검사(1106)가 직접적 P2P 접속이 가능하다고 판정하면, 초대 서비스(112)는 모바일 장치 A의 초대에 대한 모바일 장치 B의 수락을 포함하는 푸시 요청(1107)을 푸시 통보 서비스(1050)에 전송할 수 있다. 푸시 요청(1107) 및 푸시 통보 서비스(1050)로부터 모바일 장치 A로의 후속된 푸시 전달(1108)은, 세션 토큰, 양쪽 모바일 장치 A와 B의 푸시 토큰, ID 코드, 및/또는 NAT 횡단/접속 데이터를 포함할 수 있다. 한 실시예에서, 이 정보는 전술된 "티켓" 데이터 구조(예를 들어, 도 2a 내지 도 2c 및 관련 본문 참조) 내에 팩키징될 수 있으며 고유 키를 이용하여 암호화될 수 있다. 대안으로서, 이 정보는 간단히 고유 초대 세션 ID와 함께 전송될 수 있다. 초대 서비스(1050)는 직접적 접속이 시도될 것이라는 것을 모바일 장치 B에게 통보할 수 있다.
이 단계에서, 모바일 장치 A와 B는 직접적 P2P 접속을 설정하기에 충분한 정보를 가진다. 한 실시예에서, 이것은 전술된 바와 같은 CDX 서비스(110)를 이용하여 달성된다. 예를 들어, 모바일 장치 B는 그 접속 데이터를 티켓 B에 첨부하고, 1109에서, (접속 데이터와 함께) 티켓 B를 CDX 서비스에 전송한다. 이 트랜잭션 직전에, 모바일 장치 B는, 그 접속 데이터가 현행임을 보장하기 위하여 도 2b에 도시된 트랜잭션(235)과 같은 트랜잭션을 구현할 수 있다. 그 다음 CDX 서비스(110)는 (예를 들어, 전술된 바와 같은 고유 세션 키를 이용하여) 티켓을 인증하고, 모바일 장치 B의 접속 데이터를 추출하며, 1110에서 그 접속 데이터를 모바일 장치 A에 포워딩한다. 마찬가지로, 모바일 장치 A는 그 접속 데이터를 티켓 A에 첨부하고, 1111에서, (접속 데이터와 함께) 티켓 A를 CDX 서비스(110)에 전송한다. 이 트랜잭션 직전에, 모바일 장치 A는, 그 접속 데이터가 현행임을 보장하기 위하여 도 2b에 도시된 트랜잭션(232)과 같은 트랜잭션을 구현할 수 있다. 그 다음 CDX 서비스(110)는 (예를 들어, 전술된 바와 같은 고유 세션 키를 이용하여) 티켓을 인증하고, 모바일 장치 A의 접속 데이터를 추출하며, 1112에서 그 접속 데이터를 모바일 장치 B에 포워딩한다. 마지막으로, 1113에서, 모바일 장치 A와 B는 교환된 접속 데이터를 이용하여 직접적 P2P 접속으로 진입한다.
이제 도 12를 참조하면, 호환성 검사(1106)가 직접적 P2P 접속이 가능성없다고 판정하면, 초대 서비스(112)는 각 모바일 장치에 의해 이용될 중계 호스트를 결정하기 위해 중계 서비스(1051)에 중계 룩업 요청(1201)을 전송할 수 있다. 요청(1201)은, 모바일 장치 A와 B 양자 모두에 대한 적절한 중계 호스트를 선택하기 위해 중계 서비스(1051)에 의해 이용되는 모바일 장치 A와 B에 대한 네트워킹 정보(예를 들어, NAT 횡단/접속 데이터 및/또는 NAT 타입 데이터)를 포함할 수 있다. 도 13에 나타낸 바와 같이, 중계 서비스(1051)의 한 실시예는, 복수의 중계 호스트(1302-1303) 및 각 중계 호스트에 관련된 네트워크 정보를 포함하는 중계 호스트 데이터베이스(1301)를 포함한다. 초대 서비스(112)는, 모바일 장치 A와 B에 대한 네트워크 정보를 이용하여 중계 호스트 데이터베이스(1301)에게 질의하는, 중계 룩업 서비스(1300)에 중계 룩업 요청(1201)을 전송한다. 데이터베이스 결과의 수신시에, 중계 룩업 서비스(1300)는 선택된 중계 호스트(1302-1303)를 식별하는 응답(1202)을 제공한다.
한 실시예에서, 중계 룩업 응답(1202)은, 중계 서비스에 의해 생성된 중계 토큰과 중계 접속을 위해 모바일 장치 A와 B에 의해 이용될 중계 호스트(1302-1303)의 네트워크 주소(IP 주소/포트)를 포함한다. 한 실시예에서, 중계 토큰은 중계 세션과 연관되고, 중계 서비스(1051)로의 접속시에 모바일 장치 A와 B를 인증하기 위해 중계 호스트(1302-1303)에 의해 이용된다. 토큰은, 예를 들어, 고유 ID, 중계 세션 ID 코드, 디지털 인증서 및/또는 중계 세션과 연관된 고유 암호화 키를 포함한 다양한 형태를 취할 수 있다.
1203에서, 초대 서비스는 중계 접속이 이루어질 것이라는 표시를 포함하는 중계 응답(1203)을 모바일 장치 B(121)에 전송한다. 한 실시예에서, 중계 응답(1203)은 중계 호스트 B(1303)에 대한 중계 토큰과 네트워크 정보를 포함할 수 있다. 한 실시예에서, 응답(1203)은, 모바일 장치 B의 수락(1105)에 응답하여 전송되고 있기 때문에 (푸시 통보 서비스(1050)를 바이패스함으로써) 모바일 장치 B에 직접 전송될 수 있다.
초대 서비스(112)는 중계 호스트 B(1303)에 대한 중계 토큰과 네트워크 정보를 포함할 수 있는 중계 응답(1204)을 모바일 장치 A에 전송한다. 이 사례에서, 응답(1204)은 트랜잭션(1205)에서 푸시 통보 서비스(1050)를 통해 모바일 장치 A에 푸시된다.
1206에서, 모바일 장치 A(120)는 중계 서비스(1051)와의 접속을 설정하기 위해 중계 호스트 A(1302)에 대한 네트워크 정보를 이용한다. 마찬가지로, 1207에서, 모바일 장치 B(121)는 중계 서비스(1051)와의 접속을 설정하기 위해 중계 호스트 B(1303)에 대한 네트워크 정보를 이용한다. 이들 트랜잭션들 각각에서, 모바일 장치 A와 B의 임의의 NAT 방화벽에 새로운 홀이 개방되고, 모바일 장치 A와 B에 대한 NAT 횡단/접속 데이터가 중계 서비스(1051)에 의해 결정되어 (예를 들어, 장치들에 대한 공개 IP/포트를 결정함으로써) 각각 모바일 장치 A와 B에 반환될 수 있다. 한 실시예에서, 중계 서비스(1051)와 모바일 장치 A 및 B는, 당업자라면 이해하는 바와 같이 NAT 또는 방화벽 뒤쪽의 요소가 TCP 또는 UDP 접속을 통해 인입 데이터를 수신하는 것을 허용하는 "TURN"(Traversal Using Relay NAT) 프로토콜을 구현한다.
1208에서, 모바일 장치 A는 1209에서 푸시 통보 서비스에 포워딩되고 1210에서 모바일 장치 B에 푸시되는 중계 업데이트를 초대 서비스(112)에 전송한다. 마찬가지로, 1211에서, 모바일 장치 B는, 1212에서 푸시 통보 서비스에 포워딩되고 1213에서 모바일 장치 A에 푸시되는 중계 업데이트를 초대 서비스(112)에 전송한다. 모바일 장치 A에 의해 전송된 중계 업데이트는, 세션 토큰, 각 장치의 ID 코드, 및 1206 및 1207에서 중계(즉, 모바일 장치 A가 그 NAT 횡단/접속 데이터를 모바일 장치 B에 전송하는 것 및 그 반대의 경우)에 의해 결정된 NAT 횡단/접속 데이터를 포함할 수 있다. 한 실시예에서, 중계 업데이트 동작은 각 모바일 장치의 NAT 정보가 변할 수 있기 때문에 수행된다.
마지막으로, 1214 및 1215에서, 모바일 장치 A와 B는 각각 중계 서비스(1051)를 통해 P2P 접속을 설정한다. 한 실시예에서, 중계 접속은 모바일 장치 A가 모바일 장치 B의 NAT 횡단/접속 데이터를 중계 서비스(1051)에 전송할 때 및 그 반대의 경우에 설정될 수 있음으로써, 중계 서비스가 각 피어의 중계 호스트(1302-1303)로의 올바른 경로를 결정하는 것을 허용한다.
전술된 기술을 이용하여, 초대 서비스(112)는, 방대한 수의 모바일 장치들을 갖는 대규모 시스템에서도, 고유하게 스케일가능하고 탄력있는 무상태 서비스(stateless service)로서 구현될 수 있다. 예를 들어, 푸시 통보 서비스(1050)는 본질적으로 콘텐츠의 위치를 파악하고 콘텐츠를 등록된 모바일 장치들에 푸시할 수 있기 때문에, 초대 서비스가 각 장치의 현재 위치를 추적할 것이 요구되지 않는다. 추가적으로, 장치들은 각 요청과 응답을 갖는 전체 세션 상태 데이터를 전송할 수 있기 때문에, 초대 서비스가 어떠한 접속당 상태 정보도 유지할 것이 결코 요구되지 않음으로써, 초대 서비스의 저장 및 처리 요건을 줄인다. 이러한 구현은 대규모 시스템에서 특히 유용하다.
온라인 세션에 대해 사용자들을 매치하기 위한 시스템 및 방법
도 15에 나타낸 바와 같이, 중매자 서비스(111)의 한 실시예는, 매치 요청을 수신하고 매치 응답을 모바일 장치(120-122)에 푸시하기 위한 중매자 관리기(matchmaker dispatcher, 1501); 매치 요청을 요청 테이블(1502)에 저장하고 매치가능한 세트 데이터를 매치가능한 세트 식별자("MSI") 테이블(1503)에 저장하기 위한 데이터베이스(1512); 및 데이터베이스(1512)로부터 매치 요청을 가져오고 매치 동작을 수행하며 매치 결과를 데이터베이스(1512)에 다시 저장하기 위한 하나 이상의 중매자(1510)를 포함할 수 있다. 그러나, 본 발명의 기저 원리는 도 15에 도시된 특정 아키텍쳐로 제한되지 않는다는 점에 유의해야 한다.
한 실시예에서, 중매자 관리기(1501)는 중매자 서비스(111)에 대한 인터페이스로서 작용하며, 모바일 장치(120-122)로부터 요청을 수신하고, 이들 요청을 데이터베이스(1512)에 요청을 저장하라는 명령으로 변환하고, 데이터베이스(1512)로부터의 매치 결과를 판독하며, 이들 결과를 변환하여 모바일 장치(120-122)에 전달한다.
동작시, 새로운 매치 요청이 도달하면, 중매자 관리기(1501)는 그 요청을 요청 테이블(1502)의 한 행 내에 저장할 수 있다. 한 실시예에서, 관리기(1501)는 (각각 모바일 장치 A, B, 및 C에 대응하는) 도 15에서 간단히 "A", "B", "C"라고 나타낸 요청 ID("RID") 코드를 각 매치 요청에 할당한다. 도 15에서는 간소화를 위해 문자 지정을 이용하여 도시되어 있지만, RID 코드는 데이터베이스 내의 매치 요청을 추적하는데 적합한 문자열, 정수, 또는 기타 임의의 변수 타입일 수 있다.
각 매치 요청에는 요청 테이블(1502)에 저장되는 매치가능한 세트 식별자("MSI") 값이 할당될 수 있다. 한 실시예에서, MSI는 매치가 요청되고 있는 특정한 애플리케이션 및/또는 그 애플리케이션에 대해 이용되는 구성 파라미터를 식별할 수 있다. 예를 들어, MSI 값 12:4는 식별자 "12"를 갖는 특정의 멀티플레이어 게임을 식별하고, 식별자 "4"를 갖는 게임에 대한 특정한 구성을 식별할 수 있다. 더 구체적으로는, ID 코드 12는 특정한 멀티플레이어 레이싱 게임을 식별하고, ID 코드 4는 그 레이싱 게임에 대한 특정한 레이싱 트랙, 속도, 또는 플레이어 숙련도를 식별할 수 있다. 한 실시예에서, 애플리케이션 개발자에게는 이런 방식으로 MSI 값을 이용하여 임의의 애플리케이션 구성 파라미터를 명시하는 옵션이 제공된다. 한 실시예에서, MSI를 직접 명시하는 것이 아니라, 애플리케이션 개발자들은 (특정한 게임을 식별하는) 게임 ID와 (특정한 게임 구성을 식별하는) 버켓 ID를 명시하고, 이들 값들은 중매자 관리기(1501)에 의해 MSI 값으로 맵핑된다.
추가적으로, 복수의 상이한 구성 파라미터를 명시하기 위해 단일의 MSI 내에서 수 개의 상이한 MSI 값들이 이용될 수 있다(예를 들어, 12:4:1은, 12=레이싱 게임; 4= 트랙; 및 1 = 숙련도를 나타낼 수 있다). 이하에서 상세히 설명되는 바와 같이, 한 실시예에서, 각각의 MSI는, 중매 동작이 수행될 수 있는 한 세트의 매치 요청을 식별하기 위해 중매자(1510)에 의해 이용된다(예를 들어, 요청은 MSI에 기초하여 그룹화되고 각 MSI 그룹 내에서 매치가 수행된다). 한 실시예에서, 각각의 MSI는, 상이한 머신 파티션들을 식별하는 파티션 ID를 포함하기 위해 관리기에 의해 동적으로 수정/선택될 수 있다. 예를 들어, 특정한 MSI가 과부하되면, 관리기는 (예를 들어, 4:3:1 및 4:3:2(여기서 마지막 자릿수는 각각 파티션 1과 2를 식별함)와 같은 지정을 이용하여) 2개 이상의 상이한 서버 및/또는 스토리지 파티션 사이에서 MSI를 분할할 수 있다. 그러면, 상이한 중매자가 상이한 서버들 각각으로부터의 상이한 MSI들 각각으로부터 요청들을 독립적으로 검색하고 처리할 수 있다.
도 15에 나타낸 바와 같이, 매치 요청 데이터는 또한, 각 요청에 대해 요청 테이블(1502) 내에 저장될 수 있다. 요청 데이터는, 중매 결정을 행하는데 이용가능한 임의의 데이터 및/또는 네트워크를 통해 요청을 개시하는 모바일 장치에 액세스하는데 필요한 임의의 데이터를 포함할 수 있다. 예를 들어, 한 실시예에서, 각 요청에 대한 매치 요청 데이터는, 그 요청을 개시하는 모바일 장치에 대한 NAT 타입 데이터 및/또는 NAT 횡단/접속 데이터를 포함한다. 장치 접속 속도(100kbps, 1Mbps 등), 접속 타입(예를 들어, 3G, EDGE, WiFi 등), 장치 위치(예를 들어, 위치 정보 기술에 의해 결정), 언어(영어, 스페인어 등), 및/또는 사용자 선호사항과 같은 요청 데이터의 다른 타입들도, 요청 테이블(1502) 내에 저장될 수 있다. 요청 데이터는 각각의 모바일 장치(120-122)에 의해 결정되어 각각의 매치 요청과 함께 중매자 관리기(1501)에 전송될 수 있다. 예를 들어, 각각의 모바일 장치는, 그 일부가 본 명세서에 설명된 다양한 기술(예를 들어, NAT 횡단/접속 데이터를 결정하기 위해 NAT 횡단 서버와 통신하는 것, GPS를 이용하여 장치 위치를 결정하는 것, 언어를 결정하기 위해 HTTP 정보를 판독하는 것 등)을 이용하여 그 접속 데이터, 접속 타입, 장치 위치 등을 결정할 수 있다.
도 15에 나타낸 바와 같이, 한 실시예에서, 각각의 활성 MSI가 MSI 테이블(1503)의 행에 할당될 수 있다. 한 실시예에서, 새로운 요청이 도달하면, 그 요청을 요청 테이블(1502)에 추가하는 것 외에도, 관리기(1501)는 또한 MSI 테이블(1503)을 검사하여 그 요청에 대해 MSI가 이미 존재하는지를(즉, 동일한 MSI를 갖는 다른 요청들이 이미 수신되었는지를) 판정한다. 어떠한 매치되는 MSI도 발견되지 않으면, 관리기(1501)는 새로운 요청에 대한 새로운 엔트리를 MSI 테이블(1503)에 생성할 수 있다. 매치되는 MSI가 발견되면, 관리기는 단순히, 전술된 바와 같이 그 새로운 요청을 요청 테이블(1502)에 추가할 수 있다.
일단 요청 테이블(1502) 및 MSI 테이블(1503)이 중매자 관리자(1501)에 의해 업데이트되고 나면, 중매자 모듈(1510)의 인스턴스(이하에서는, 간단히 "중매자(1510)"라고 함)가 중매 동작을 수행하기 위해 데이터를 가져온다. 복수의 중매자 인스턴스들이 동시에 실행되어 중매 요청을 수행할 수 있고 하나의 중매자(1510)가 복수의 상이한 MSI 그룹들에 관한 복수의 중매 동작을 동시에 처리할 수 있다.
한 실시예에서, 중매자(1510)가 이용가능하게 되면(예를 들어, MSI 그룹에 대한 중매 동작을 완료한 후에 또는 초기화된 후에), 중매자(1510)는 처리할 새로운 MSI를 식별하기 위해 MSI 테이블(1503)에 질의한다. 도 15에서, MSI 3:1에 대한 중매자 ID 필드에서의 "N/A" 값은, 이 MSI의 처리 책임이 중매자에게 아직 할당되지 않았다는 것을 나타낸다. 한 실시예에서, 각 MSI 엔트리는 타임-스탬프되고, 중매자(1510)는 가장 오래된 타임 스탬프를 갖는 MSI를 선택한다.
한 실시예에서, 중매자(1510)가 특정 MSI에 대한 책임을 떠맡을 때, 중매자(1510)는 MSI 테이블(1503) 내의 그 중매자 ID 코드를 업데이트하고 그 MSI에 대한 임대 지속기간(예를 들어, 5초)을 명시한다. 한 실시예에서, 중매자(1510)는 그 MSI에 대해 매치를 처리함에 따라 지속적으로 임대 값을 업데이트한다. 임대 값들은 실패한 중매자(1510)에 할당되었던 MSI들을 식별하는데 이용될 수 있다. 예를 들어, 임대 값이 만료되면, 그 MSI는, MSI 테이블(1503)이 그 MSI가 중매자에게 이미 할당되었음을 가리키는 사실에도 불구하고, 새로운 중매자에 의해 청구될 수 있다.
일단 중매자(1510)가 MSI에 대한 책임을 떠맡으면, 중매자(1510)는 요청 테이블(1502)에 질의하여 그 MSI와 연관된 요청을 메모리 내로 읽어들일 수 있다. 그 다음 중매자(1510)는, (예를 들어, 후술되는) 한 세트의 매치 기준에 따라 사용자들과 모바일 장치들을 매치하는 매치 동작을 수행할 수 있다. 중매자(1510)는 모바일 장치의 매치가 이루어진 때를 나타내기 위해 요청 테이블(1512)을 업데이트할 수 있다. 예를 들어, 중매자는, 매치가 완료되었다는 것을 나타내기 위해 요청 테이블(1512) 내의 MSI 열로부터 MSI 값들을 제거하고 미리정의된 값을 입력할 수 있다. 또한, 중매자(1510)는, 각각의 참여자에 대한 "요청 데이터"를, 그 참여자와 매치된 다른 참여자를 식별하기 위해 업데이트할 수 있다(예를 들어, 그 다른 참여자와 통신하는데 필요한 NAT 횡단/접속 데이터를 기입함으로써).
관리기(1501)는 완료된 매치를 식별하기 위해 요청 테이블(1502)에 주기적으로 질의할 수 있다. 완료된 매치의 검출에 응답하여, 관리기(1501)는 푸시 통보를 (예를 들어, 본 명세서 및 동시계류중인 출원에서 기술된 푸시 통보 기술을 이용하여) 그 매치에 관여된 모바일 장치들에 전송할 수 있다. 한 실시예에서, 푸시 통보는 전술된 "티켓" 데이터 구조를 포함한다. 그러면 모바일 장치들은 그들 티켓들 각각을 이용하여 전술된 CDX 서비스(110)를 통해 접속 데이터를 교환할 수 있다.
푸시 통보를 이용하는 것 외에도, 한 실시예에서, 모바일 장치(120-122)는 매치가 이루어졌는지를 판정하기 위해 관리기(1501)에 주기적으로 질의할 수 있다. 주기적 질의는, 모바일 장치에 푸시 통보가 이루어지지 않은 경우에 유용하다. 그러나, 푸시 아키텍쳐가 이용되기 때문에, 주기적 질의는 비교적 낮은 레이트로 설정되어, 중매자 서비스(111) 상의 부하를 저감할 수 있다.
도 16은 2개의 모바일 장치 A와 B가 중매자 서비스(111)에 의해 매치되는 방법의 한 실시예를 나타낸다. 도 17a 내지 도 17d는 방법이 진행됨에 따라 발생할 수 있는 요청 테이블(1502) 및 MSI 테이블(1503)에 대한 예시적인 업데이트를 나타낸다.
1601에서, 모바일 장치 A로부터 매치 요청이 수신된다. 1602에서, 도 17a에 나타낸 바와 같이, 모바일 장치 A의 요청이 요청 테이블에 입력되고, (이미 존재하지 않는 경우) 새로운 MSI 엔트리(MSI 1:1)가 MSI 테이블에 입력된다. 1603에서, 모바일 장치 B로부터 매치 요청이 수신되고, 1604에서, 모바일 장치 B의 매치 요청도 역시 도 17b에 나타낸 바와 같이 요청 테이블에 입력된다.
1605에서, 특정한 중매자 인스턴스(중매자 # N)는 MSI 테이블을 검사하고, 또 다른 중매자 인스턴스에 의해 MSI 1:1이 청구되지 않았음을 검출한다. 대안으로서, 중매자는 임대가 만료된 MSI 테이블 엔트리를 검출하여, 그 MSI에 관해 앞서 동작하던 중매자가 실패했음을 나타낸다. 한 실시예에서, 임대가 만료된 MSI 엔트리는 (아직 중매자가 할당되지 않은) 새로운 MSI 엔트리보다 높은 우선권이 주어진다. 또한, 한 실시예에서, 비교적 오래된 MSI 엔트리에는 비교적 새로운 MSI 엔트리보다 높은 우선권이 주어질 수 있다. 중매자가 MSI를 선택하는 방법에 관계없이, 중매자가 MSI를 선택하면, 그 식별자를 추가하고 도 17c에 나타낸 바와 같이 (예를 들어, 도시된 예에서는 5초의 임대 값을 이용하여) 그 MSI 엔트리에 대해 새로운 임대 값을 설정한다. 그 다음, 중매자는 요청 테이블에 질의하여 그 MSI를 갖는 요청 테이블 엔트리들을 메모리 내로 판독하여, 이들이 처리될 수 있게 할 수 있다.
1606에서, 중매자는 요청들 각각에 대해 적절한 매치를 선택하기 위해 일련의 매치 동작을 수행한다. 매치 동작들의 소정 실시예들이 도 18에 관하여 이하에서 기술된다. 간략하게 말하면, 한 실시예에서, "적절한" 매치를 결정하기 위해 평가되는 변수들로는, NAT 타입(예를 들어, 풀 콘(full cone), 포트 제한형, 대칭형 등), 접속 타입(예를 들어, WiFi, 3G, Edge 등), (HTTP 요청 수락-언어 헤더로부터 유도되는) 사용자와 연관된 언어, 및 매치 요청들 각각의 경과시간(age)이 포함된다. 일반적으로, 중매자(1510)는, (비록 후술되는 바와 같이 때때로 중계 서비스가 이용될 수 있지만) 호환형 NAT 타입, 동일한 접속 타입, 및 동일한 언어를 갖는 모바일 장치들을 매치하려고 시도할 수 있다. 한 실시예에서, 중매자(1510)는 매치 요청의 경과시간에 기초하여 매치 요건에서 더욱 관대할 수 있다(즉, 요청이 더 오래될수록, 매치 제약이 더욱 관대하게 적용될 것이다).
도 16을 참조하면, 1607에서, 매치 결정에 후속하여, 중매자(1510)는 요청 테이블을 업데이트하여 도 17d에 나타낸 바와 같이 그 매치가 완료되었음을 나타낸다. 업데이트의 일부로서, 중매자는 또한, 모바일 장치 A와 B에 대한 요청 데이터를 업데이트할 수 있다. 예를 들어, 한 실시예에서, 중매자(1510)는, 모바일 장치 B의 NAT 횡단/접속 데이터를 모바일 장치 A에 대한 요청 데이터 열에 기입하고, 모바일 장치 A의 NAT 횡단/접속 데이터를 모바일 장치 B에 대한 요청 열에 기입한다.
1608에서, 관리기(1501)는 매치된 요청 엔트리들을 식별하기 위해 요청 테이블을 통독(read through)할 수 있다. 한 실시예에서, 관리기가 모바일 장치 A와 B가 매치되었음을 검출하면, 관리기는 (전술된 바와 같이 중매자에 의해 업데이트된) 요청 데이터를 판독하고, 모바일 장치 A와 B에 대한 통보를 생성한다. 한 실시예에서, 이 통보는, 암호화되고 각 모바일 장치에 대한 NAT 횡단/접속 데이터를 포함하는 전술된 "티켓" 데이터 구조이다. 전술된 바와 같이, 한 실시예에서, 모바일 장치 A와 B에 통보를 푸시하기 위해 푸시 통보 서비스(1050)가 이용된다. 또한, 모바일 장치 A와 B는 매치가 이루어졌는지를 판정하기 위해 관리기(1501)를 주기적으로 폴링(poll)할 수 있다. 이 실시예에서, 폴링 기술은, 어떤 이유로, 모바일 장치들 중 하나에 성공적으로 푸시되지 않은 매치들을 식별하기 위해 비교적 느린 속도로 이루어질 수 있다. 폴링 요청 부하를 관리하기 위해 푸시 통보를 이용하는 것은, 이것을 이용하지 않을 경우 모바일 장치들로부터의 폴링 요청들로 부하를 받을, 중매자 서비스(111) 상의 부하를 상당히 경감시킨다.
1608에서 결정되는, 동일한 MSI에 대해 추가의 매치 요청이 계류중이라면, 중매자는 MSI 내의 모바일 장치들/사용자들을 계속 매치할 수 있다. 1610에서, 중매자는 MSI 테이블(1503) 내의 임대 값을 리셋할 수 있다. 1611에서, 추가의 매치들이 수행되고 요청 테이블이 (전술된 바와 같이) 업데이트된다. 1612에서, 요청 테이블로부터 추가의 매치들이 판독되고, 추가의 모바일 장치들이 (전술된 바와 같이) 업데이트된다. MSI에 대한 어떠한 추가 매치 요청도 계류중이 아니라면, 1609에서, (예를 들어, 관리기 및/또는 중매자 중 어느 하나로부터의 삭제 명령을 통해) MSI 테이블로부터 MSI 엔트리가 제거된다.
도 18은 모바일 장치들/사용자들 사이에 매치를 수행(도 16에서 동작 1606)하기 위한 방법의 한 실시예를 나타낸다. 1801에서, (예를 들어, 특정한 애플리케이션/버켓 조합에 대한) 모든 현재의 MSI 요청이 쌍으로 정렬된다. 1802에서, 각각의 쌍 사이의 매치 "정합(fit)"이 평가되고, 1803에서, 쌍들은 내림차순 정합별로 분류된다. "정합"은, NAT 타입(예를 들어, 풀 콘, 포트 제한형, 대칭형 등), 접속 타입(예를 들어, WiFi, 3G, Edge 등), (HTTP 요청 수락-언어 헤더로부터 유도되는) 사용자와 연관된 언어, 및 매치 요청들 각각의 경과시간(age)을 포함하지만, 이들만으로 제한되지 않는, 복수의 상이한 변수들에 기초하여 평가된다. 중매 결정 내에 인수화될 수 있는 다른 변수들로는, 각 모바일 장치의 위치(예를 들어, 특정 위치의 사용자들을 매치하려는 시도와 함께); 최소 및/또는 최대 플레이어 요건(예를 들어, 사용자 및/또는 애플리케이션에 의해 명시); MSI에 포함된 한 명 이상의 사용자들이 "친구들"인지 또는 이전에 P2P 접속에 들어갔던 적이 있는지의 여부(예를 들어, "친구"나 이전 면식인들과의 매치 선호도와 함께); 및 애플리케이션에 대한 사용자 경험(예를 들어, 멀티플레이어 게임의 경우, 유사한 숙련도의 사용자와 매치를 선호하는 경우 각 사용자의 점수판 순위가 인수화될 수 있다)이 포함된다.
이하의 표 A에 나타낸 바와 같이, 한 실시예에서, "정합도"의 평가는 0.0 내지 1.0 사이의 수치값이다. 부동 소수점값을 이용하는 것은 각 기준에 대한 정합도의 정규화(normalization)를 허용한다. 부동 소숫점 계산을 피하기 위해, 비-정규화된 정수 값이 적절한 평가와 함께 사용되어 정합도 값(fitness values)이 비교될 수 있다.
한 실시예에서, 모든 기준은 그들이 (정규값 1.0을 갖는) 호환형이거나 (정규값 1.0 미만을 갖는) 비호환형인 2진 정합도를 가진다. 이들은 (후술되는 바와 같이) 정합도가 경과시간에 따라 변할 수 있는 경우에 필요한 기준으로서 간주될 수 있다. 위치가 변수로서 추가된다면, 최상의 정합은 필요한 기준에 들어맞는 가장 가까운 플레이어의 것이 될 수 있다.
매치 정합도 - 표 A
Figure 112013119938728-pct00001
한 실시예에서, 정합도는 상기 기준 각각에 대한 (정규화된 가중치 * 경시(aged) 인자 값)의 합계와 같다. 경시 인자 값은 값 1에서 시작하여 미리결정된 기간이 지난 후에 증가할 수 있다. 그 다음, 이것은 더 많은 시간이 경과함에 따라 계속 증가할 수 있다(예를 들어, 지정된 양만큼 주기적으로 증가). 한 실시예에서, 전술된 경시 인자 값을 이용하는 것 대신에, 후술되는 바와 같이 경과시간 임계치가 설정될 수도 있다. 접속 타입 및 언어와 같은 소정 변수들의 정규화된/가중화된 값들은 (이들이 매치하지 않더라도) 소정의 경과시간 임계치 위에서 적용될 수 있다.
한 실시예에서, 한 쌍의 요청 A와 B 사이의 "정합도"는, B에 대한 A의 정합도와 A에 대한 B의 정합도의 평균이다. 게다가, 각 인자에 대한 B에 관한 A의 정합도는 A의 경과시간에 기초하여 조정될 수 있다(및 그 반대도 마찬가지). 한 실시예에서, 호환형 매치에 대해 정합도 1.0이 요구될 수 있다. 이것은, A와 B는 NAT 호환성, 접속 타입 및 언어가 매치(그 결과 정규화된 값 1.0)될 때에만 매치되거나, A 및/또는 B가 경시되어(aged) 상기 변수들 중 일부(예를 들어, 접속 타입 및 언어)가 (경시된 인자 값 위 또는 임계치 아래를 이용하여) 사실상 무시된다는 것을 의미한다.
경과시간 - 표 B
Figure 112013119938728-pct00002
경과시간 임계치는 상기 표 B에 개시된 바와 같이 설정될 수 있다. 각각의 경과시간 임계치를 지남에 따라(즉, 요청이 명시된 임계치보다 오래됨에 따라), 경시된 인자값은 계속적으로 더 큰 값(예를 들어, 1.5, 2.0 등)으로 증가될 수 있다. 대안으로서, 또는 추가로, 상이한 경과시간 임계치를 지남에 따라, (예를 들어, 후술되는 접속 타입 및 언어와 같은) 소정 변수에 대한 가중화된 값들이 매치 결정에 추가될 수 있다.
한 실시예에서, 표 B에 명시된 요청 경과시간 한계는 주어진 MSI에 대한 매치 진행률(match flow rate)에 따라 조정된다. 한 실시예에서, 진행률은 명시된 단위의 시간당(예를 들어, 매 10초, 매 분 등) 수행되는 매치의 갯수로서 정의된다. 따라서, 진행률은 특정한 MSI 세트가 얼마나 바쁜지에 대한 표시를 제공한다. 한 실시예에서, 세트가 바쁠수록, 상기 임계치 각각은 상기 표 B에서 더 낮게 설정되어 초기의 성공적 매치의 확률을 증가시키고 중매자에 주는 부담을 경감한다. 게다가, 주어진 MSI 세트에 대한 부하가 엔드 유저(end user)에 (예를 들어, 매치 값에 대한 추정된 시간의 형태로) 제공되어, 그 엔드 유저는 특별히 바쁜 멀티플레이어 게임에 들어가려고 시도할지를 선택할 수 있다. 부하 값은 푸시 통보의 형태로 사용자에게 제공될 수 있다.
이제 표 A로부터의 변수들 각각을 참조하면, 한 실시예에서, 도 14에 도시된 NAT 호환성 차트(1400)로부터 NAT 호환성이 판정된다. 2개의 NAT가 이 차트에 기초하여 호환된다고 판정되면, NAT 호환성 가중치가 적용될 수 있다.
접속 타입 - 표 C
Figure 112013119938728-pct00003
접속 타입은 상기에서 테이블 C로서 나타낸 것과 같은 차트를 이용하여 평가될 수 있다. 이 예에서, 장치 A와 B의 접속 타입이 동일하다면(동일한 접속 타입이 충족되는 경우 셀들에서 1.0으로 표시), 표 A로부터의 가중화된 접속 타입 값이 정합도 결정에 포함될 수 있다. 전술된 바와 같이, 각 요청의 경과시간이 이용되어 접속 타입 결정에 영향을 미칠 수 있다. 예를 들어, 한 실시예에서, 임계치 1, 2, 및 3에서의 경과시간에 대한 표 C의 매트릭스를 이용하여 접속 타입에 대한 정합도 값이 선택된다. 임계치 4 또는 그 이상에 대한 경과시간의 경우, 접속 타입은 (비정합 접속 타입에 대해서도) 1.0으로 설정될 수 있고, 대응하는 가중화된 접속 타입 값이 적용될 수 있다. 일부 실시예들에서는 접속 "타입"이 이용되지만, 접속 타입과 함께 또는 그 대신에, 접속 속도가 판정되어 이용될 수 있다. 예를 들어, 소정의 명시된 범위(예를 들어, 0-100kbps; 100-500kbps; 500-1000kbps, 1000-1500kbps 등) 내의 접속 속도는 "호환형"이라 간주될 수 있다. 본 명세서에 논의된 매치되는 변수들 중 임의의 것이 매치 정합도 계산에 대한 가중치로서 적용되고 전술된 바와 같이 경시(aged)될 수 있다.
한 실시예에서, 플레이어 언어는, 선호도 큐인자(qfactor)와 함께 하나 이상의 언어를 포함할 수 있는 HTTP 요청 수락-언어 헤더로부터 유도될 수 있다. 관리기는 가장 선호되는 언어를 추출하여 이 정보를 중매자에 전달할 수 있다. 한 실시예에서, 표 A로부터의 가중화된 언어 값은 언어들이 동일하다면 1.0으로 언어들이 동일하지 않다면 0.0으로 설정된다. 그러나, 한 실시예에서, 가중화된 언어 값은 언어들이 상이하더라도 경과시간이 명시된 임계치보다 높다면(예를 들어, 경과시간이 표 B에서 임계치 2 또는 그 이상이라면) 적용될 수 있다.
한 실시예에서, 비호환 NAT 타입들을 갖는 2명의 사용자들 사이에 매치가 이루어질 수 있다. 예를 들어, 중매자가 특정한 MSI에 대한 사용자들을 매치하는데에 어려움을 가진다면, 명시된 기간이 지난 후에, 전술된 기술들을 이용하여 중계 서비스(1051)를 통해 접속을 라우팅할 수 있다. 이런 방식으로, 중계 서비스(1051)는 압력 밸브처럼 역할하여, 비호환 NAT 타입들임에도 불구하고 경시 매치가 발생하는 것을 허용한다. 중계 서비스(1051)는 또한 하나 이상의 실패한 매치 시도의 검출에 응답하여 이용될 수 있다. 이 실시예에서, 모바일 장치에 의해 제출된 각 매치 요청은, 하나 이상의 성공하지 못한 매치가 이전에 시도되었는지에 관한 표시를 포함할 수 있다.
다양한 추가적인 매치 기준이 평가되어, 제한이 아닌 예로서, 매치를 요청하는 사용자들 중 임의의 사용자가 친구인지에 관한 표시를 포함한, 매치 정합도 판정의 일부로서 가중치를 제공받을 수 있다. 예를 들어, 중매자(1510)는, 매치 정합도 계산에 대해 "친구" 가중치를 적용함으로써, 임의의 요청들을 "친구"인 사용자들에 대해 매치하려고 시도할 수 있다. 마찬가지로, 친구들의 친구들 또한, (예를 들어, 2 이상의 분리도와 함께) 가중화될 수 있다. 추가적으로, 플레이어는 특정한 게임에 대해 다른 플레이어들의 순위를 매기고, 매치의 수행시에 중매자는 이들 순위를 평가할 수 있다(비교적 높은 순위를 갖는 플레이어들과 사용자를 매치시키고, 낮은 순위를 갖는 플레이어들과는 매치시키지 않는 경향). 게다가, 사용자의 접속의 레이턴시가 (예를 들어, 간단한 핑 동작을 이용하여) 평가되고 중매 결정의 일부로서 이용될 수 있다.
플레이어들을 매치시키는데 이용되는 또 다른 변수는 장치 타입일 수 있다. 예를 들어, 중매자(1510)는 유사한 장치 타입(예를 들어, iPad, iPod, iTouch, iPhone, RIM Blackberry 등)을 갖는 플레이어들을 매치시키려고 시도할 수 있다. 사용자의 점수판 랭킹, 현재 위치, 현재 거주지, 나이, 성별, 및 유사한 게임 콜렉션들을 포함한 추가의 변수들이, 매치 결정에 대해 유사하게 평가될 수 있다(즉, 많은 경우 유사한 기준을 갖는 사용자들 사이의 매치를 선호하는 경향). 마지막으로, 사용자들이 적절한 MSI들 및 동일한 나이의 다른 사용자들과만 매치되도록 보장하기 위해 중매자(1510)에 의해 부모 통제(parental control)가 평가될 수 있다.
중매자 서비스(111)는 데이터 서비스(100) 내에서 관리되는 하나 이상의 데이터베이스(예를 들어, 도 19에 관하여 후술되는 데이터베이스(1920)를 참조)로부터 상기 임의의 변수를 검색할 수 있다. 예를 들어, 친구 서비스 데이터베이스로부터의 사용자의 친구 데이터가 액세스되고, 각 사용자의 나이, 성별, 게임 콜렉션 등과 같은 기타의 정보는 하나 이상의 다른 데이터베이스(예를 들어, 사용자 프로파일, 게임 데이터베이스, 점수판 데이터베이스 등)로부터 액세스될 수 있다. 한 실시예에서, 본 명세서에 설명된 서비스들 모두에는, 중매 결정에 이용되는 다양한 상이한 타입들의 사용자/장치 데이터 모두를 저장하기 위한 동일한 중앙 데이터베이스(또는 데이터베이스 그룹)로의 액세스가 제공된다.
상기에서 몇 가지 구체적인 예가 제공되었지만, 본 발명의 기저 원리는, 매치에 대한 정합 수준을 결정하기 위한 임의의 특정한 변수 세트에 제한되지 않는다는 것을 이해할 것이다. 한 실시예에서, 시스템 상에서 실행될 애플리케이션과 본 명세서에서 설명된 방법을 설계하는 애플리케이션 프로그래머들은, 상이한 MSI 기준을 이용하여 요청을 매치시키고 및/또는 그룹화하기 위한 그들 자신의 기준 집합을 명시할 수 있다.
도 18의 방법을 다시 참조하면, 일단 각 쌍 사이의 매치 "정합도"가 결정되고 나면, 1803에서, 그 쌍들은 내림차순 정합도별로 분류된다(예를 들어, 가장 높은 정합도를 갖는 쌍이 목록의 최상위에 위치). 1804에서, "매치 세트"가, 명시된 임계치보다 위의 가장 높은 정합도 값을 갖는 쌍들로 작성(seed)된다. 전술된 바와 같이, "임계" 치는 상기 표 A에 도시된 정규화된 값 1.0으로 설정될 수 있다. 1805에서, 명시된 임계치 위의 매치 세트의 현재 멤버들 중 하나 또는 모두와의 정합도 값을 갖는 새로운 유망 파트너가 매치 세트에 추가된다. 예를 들어, 매치 세트가 처음에 A 및 B로 작성(seed)되었다면, A-C 및/또는 B-C의 정합도 값이 명시된 임계치 위라면 그 매치 세트에 C가 추가될 수 있다. 한 실시예에서, 단 하나의 매치 정합도가 유망 당사자에 대한 임계치 위라면, 그 당사자는 매치 세트에 추가될 수 있다(즉, 필요하다면, 그 당사자는 적절한 매치 정합도를 갖는 한 당사자를 통해 당사자들 모두와 통신할 수 있을 것이기 때문이다). 일단 하나 이상의 새로운 당사자가 매치 세트에 추가되고 나면, 1806에서 결정되는 그 매치에 대한 크기 요건이 충족되는 경우, 1807에서 매치 결과가 저장되고 보고된다(예를 들어, 전술된 바와 같이 요청 테이블(1502)을 업데이트하고 통보를 전송함으로써). 한 실시예에서, 하나의 매치 요청이 복수의 사용자를 나타낼 수 있다(예를 들어, 매치 요청이 후술되는 초대 시퀀스를 뒤따를 경우). 이 경우, 각 매치 요청이 나타내는 사용자 수에 기초하여 크기 요건이 평가된다. 크기 요건이 충족되지 않으면, 프로세스는 1805로 되돌아가고, 새로운 당사자(즉, 명시된 임계치 위의 상기 세트의 현재 멤버들 중 하나 이상과의 매치 정합도를 갖는 당사자)가 매치 세트에 추가된다.
1808에서, 매치된 요청들은, 중매자(1510)에 의해 처리 중인 현재 세트의 요청들로부터 제거된다. 1809에서, 다음 작성된 매치 세트가 선택되고 프로세스는 추가의 매치를 위해 1804로 되돌아간다. 도 18에서는 순차적 프로세스로서 나타내었지만, 본 발명의 기저 원리를 여전히 따르면서 복수의 작성된(seeded) 매치 세트들이 동시에 처리될 수 있다는 점에 유의해야 한다.
위에서는 별개의 서비스들로서 설명되었지만, 중매자 서비스(111) 및 초대 서비스(112)는 P2P 사용자들을 접속하기 위해 함께 동작할 수 있다. 예를 들어, 한 실시예에서, 제1 사용자는 한 명 이상의 친구를 온라인 세션에 초대하고 한 명 이상의 추가 사용자와의 매치를 요청할 수 있다(예를 들어, 멀티플레이어 비디오 게임에 대해 친구 "Bob"을 초대하고, 3명의 추가 플레이어를 매치). 이러한 경우, 초대 서비스(112)는 처음에 제1 사용자의 초대 요청을 처리하여 제1 사용자와 그 제1 사용자의 친구(들)을 접속할 수 있다. 그 다음, 초대 요청의 결과(예를 들어, 성공적 P2P 접속)가 사용자의 모바일 장치에 되보고될 수 있다. 그 다음, 중매 서비스(111)는 추가 플레이어를 요청하는 제1 사용자의 모바일 장치로부터(또는, 한 실시예에서는, 초대 서비스로부터 직접, 또는 제1 사용자의 친구로부터) 매치 요청을 수신할 수 있다. 응답하여, 중매자 서비스(111)는, (전술된 바와 같이) 제1 사용자를 그 제1 사용자의 요청과 동일한 MSI를 갖는 하나 이상의 다른 매치 요청과 매치시킬 수 있다. 매치 요청은 제1 사용자의 매치 기준만을 포함하거나, 제1 사용자 및 제1 사용자의 친구의 매치 기준(예를 들어, NAT 타입, 접속 타입, 언어, 위치 등)을 포함할 수 있다. 한 실시예에서, 한 명 이상의 제1 사용자의 친구들이 또 다른 매치된 사용자와의 직접적 P2P 접속을 설정할 수 없다면, (예를 들어, 제1 사용자의 모바일 장치를 접속에 대한 프록시로서 이용하여) 그 매치된 사용자의 제1 사용자의 친구와의 접속이 제1 사용자의 데이터 처리 장치를 통해 설정되거나, 및/또는 (전술된 바와 같이) 사용자들을 접속하기 위해 중계 서비스가 이용될 수 있다.
한 실시예에서, 제1 사용자는 처음에 (전술된 바와 같이) 중매자 서비스에 의해 한 명 이상의 사용자와 매치된 다음, 그 제1 사용자가 한 명 이상의 친구를 초대하여 제1 사용자 및 매치된 사용자들과의 온라인 세션에 참여시킬 수 있다. 이 실시예에서, 사용자의 정보 및 매치된 사용자들의 정보(예를 들어, NAT/접속 데이터, 사용자 ID, 푸시 토큰 등) 양쪽 모두를 (전술된 바와 같이) 초대 서비스를 통해 초대받은 사용자들과 교환할 수 있다. 본 발명의 기저 원리는, 매치가 먼저 발생하고 초대가 후속하든지, 또는 초대가 먼저 발생하고 매치가 후속하든지에 관계없이 동일하게 유지된다.
협력적 온라인 애플리케이션을 위한 애플리케이션 프로그래밍 인터페이스를 갖는 애플리케이션 프레임워크
도 19에 나타낸 바와 같이, 본 발명의 한 실시예는, 하나 이상의 애플리케이션(1911)과 인터페이싱하기 위한 애플리케이션 프로그래밍 인터페이스("API")(1910)와, 복수의 네트워크 서비스(1901-1903)와 통신하기 위한 서비스측 API(1910)를 갖는 미리정의된 소프트웨어 프레임워크(1912)를 갖는 모바일 장치(120)의 콘텍스트 내에서 구현된다. 도 19에 도시된 바와 같이, 네트워크 서비스(1901-1903)는 동일한 온라인 데이터 서비스(100)에 의해 설계 및/또는 관리될 수 있다(비록 이러한 구성이 요구되는 것은 아니지만). P2P 게이밍 애플리케이션과 같은 애플리케이션(1911)과 기타 타입의 협력적 온라인 애플리케이션들은, API(1910)를 호출함으로써 API(1910)를 통해 네트워크 서비스(1901-1903)에 액세스하도록 설계될 수 있다. 애플리케이션(1911)의 설계는, 프레임워크(1912)의 개발자에 의해 제공되는 소프트웨어 개발 킷("SDK")과 네트워크 서비스(1901-1903)를 이용함으로써 용이해질 수 있다. 프레임워크(1912)와 API(1910, 1913)의 더 구체적인 구현이 도 20을 참조하여 후술된다.
나타낸 바와 같이, 서비스들 각각에는 서비스들에 의해 이용되는 데이터를 저장하기 위한 데이터베이스(1920)로의 액세스가 제공될 수 있다. 한 특정의 예는, (전술된) 중매자 서비스(111)에 의해 이용되는 데이터베이스(1512)이다. 다른 예는, 점수판 데이터를 저장하기 위한 점수판 데이터베이스, 친구 상태 기록을 저장하기 위한 친구 서비스 데이터베이스, 사용자 프로파일 데이터를 저장하기 위한 프로파일 데이터베이스, 및 온라인 게임과 관련된 데이터를 저장하기 위한 게임 데이터베이스를 포함할 수 있다. 임의 타입의 데이터베이스(예를 들어, MySQL, Microsoft SQL 등)가 이용될 수도 있지만, 한 특정 실시예에서는, Berkley DB 및/또는 MZBasic DB와 같은 키/값 데이터베이스가 이용될 수 있다. 데이터베이스는, SAN(Storage Area Network) 또는 기타의 스토리지 구성 내의 많은 수의 대용량 스토리지 장치(예를 들어, 하드 드라이브)에 걸쳐 분산될 수 있다.
결과적으로, 특정 서비스가 전술된 바와 같이 데이터를 처리 및/또는 저장할 때, 그 데이터는 데이터베이스(1920) 내에 저장될 수 있다. 그러나, 일부 서비스들은 데이터베이스를 이용하지 않을 수 있다. 예를 들어, 전술된 바와 같이, 초대 서비스(112)는 무상태 서비스로서 구현될 수 있고, 따라서, 데이터베이스(1920) 내에 데이터를 저장할 것이 요구되지 않을 수 있다(비록 본 발명의 기저 원리에 따라 이러한 구현이 여전히 가능하지만).
API(1913)는, 예를 들어, 네트워크 계층의 TCP/IP 또는 UDP/IP와 애플리케이션 계층의 HTTPS를 포함한 임의의 적절한 네트워크 프로토롤 스택을 이용하여 네트워크 서비스(1901-1903)와 통신하고 정보를 교환하도록 설계될 수 있다. SOAP와 같은 HTTP 또는 HTTPS를 통한 원격 프로시져 호출(RPC)-기반의 프로토콜이 이용되거나 및/또는 REST(Representational State Transfer) 프로토콜이 이용될 수 있다. 게다가, 서비스들은, 예로서, Xserve 또는 Unix, Linux 또는 Apache 소프트웨어 플랫폼을 운영하는 유사한 서버들을 포함한, 임의의 컴퓨팅 플랫폼 상에서 구현될 수 있다. 한 특정 실시예에서, 플랫폼은 Linux 상에서 구현된 Web 객체를 포함한다. 전술된 예들은 단지 설명의 목적을 위해 제공된 것이다. 본 발명의 기저 원리는, 애플리케이션을 서비스에 링크하기 위한 임의의 특정한 메커니즘이나 임의의 특정한 네트워크 프로토콜 세트로 제한되는 것은 아니다.
도 20은 본 발명의 한 실시예의 무선 장치(120) 상에서 구현될 수 있는 애플리케이션 프로그래밍 인터페이스(API)(2001a-b)를 포함한 더 상세한 소프트웨어 아키텍쳐를 나타낸다. 이 실시예가 멀티플레이어 게임 프레임워크(2000)의 콘텍스트 내에서 설명되지만, 본 발명의 기저 원리는 게이밍 구현으로 제한되는 것은 아니다. 예를 들어, 게임이 아닌 다양한 협력적 애플리케이션들(예를 들어, 협력적 채팅, 멀티파티 협력적 오디오/비디오 등)을 지원하기 위해 도 20에 도시된 소프트웨어 아키텍쳐가 이용될 수 있다.
도 20에 도시된 아키텍쳐에서, 본 명세서에 설명된 다양한 멀티파티 특징과 P2P 특징을 지원하기 위해 게임 프레임워크(2000)가 제공된다. 한 실시예에서, 게임 프레임워크(2000)는 모바일 장치의 운영 체제(2005) 상에서 실행되도록 설계된다. 예를 들어, 모바일 장치(120)가 iPhone, iPad, 또는 iPod Touch이면, 운영 체제(2005)는 본 출원의 양수인에 의해 설계된 모바일 운영 체제인 iPhone OS일 수 있다.
게임 프레임워크(2000)는 공개 애플리케이션 프로그래밍 인터페이스(API)(2001b)와 사설 또는 "보안" API(2001a)를 포함할 수 있다. 한 실시예에서, 본 명세서에 설명되는 다양한 게임-관련 특징을 제공하도록 설계된 게임 센터 애플리케이션(2031)은, 공개 API(2001b)와 사설 API(2001a) 양쪽 모두를 호출할 수 있는 반면, 다른 애플리케이션(2030)(예를 들어, 제3자에 의해 설계된 애플리케이션들)에는 공개 API(2001b)로의 액세스만이 제공된다. 예를 들어, 모바일 장치(120)의 설계자는, 잠재적으로 민감한 정보를 포함하는 어떤 API 기능들을 공개 API(2001b)의 바깥에 유지하여 제3자 개발자에 의한 남용(예를 들어, 친구 요청, 친구 목록 등)을 피하기를 원할 수 있다. 그러나, 보안 API(2001a) 및 공개 API(2001b) 양쪽 모두는 모바일 장치 상의 모든 애플리케이션들에 의해 액세스가능한 단일 API로 병합될 수 있다(즉, 공개 컴포넌트와 사설 컴포넌트로의 API의 분리는 본 발명의 기저 원리를 따르는데 필요한 것은 아니다). 표기 "API 2001"은 때때로 이하에서, 공개 API(2001b) 및/또는 사설 API(2001a) 중 어느 하나에서 발견될 수 있는 동작을 지칭하기 위해 사용된다.
게임 센터 애플리케이션(2031)의 한 실시예는, 본 출원의 양수인에게 양도되고 참조에 의해 본 명세서에 포함되는, Attorney Docket 번호 제4860.P9127USP1이며, 발명자가 Marcel Van Os 및 Mike Lampell이고, 2010년 4월 7일 출원된 출원번호 ____이며, 발명의 명칭이 Systems and Methods for Providing a Game Center인, 동시계류중인 출원(이하에서는, “Game Center 특허 출원”이라 함)에 설명되어 있다. 요약하면, 게임 센서 애플리케이션(2031)은 멀티플레이어 게임들을 통해 네비게이팅하고; 새로운 게임을 구입하고; 게임에 관련된 정보(예를 들어, 점수판 정보, 업적, 친구 정보 등)를 검색하고; 게임을 플레이하기 위해 친구들에게 연락하고; 다른 사용자들과의 게임 매치를 요청하고; 특정 사용자들을 초대하기 위한 게임-중심의 그래픽 유저 인터페이스(GUI)를 포함한다. 게임 센터 애플리케이션(2031)에 의해 수행되는 다양한 다른 기능들은 앞서 참조한 Game Center 특허 출원에 설명되어 있다. 게임 센터 기능들의 일부는 게임 프레임워크(2000)에 의해 제공되어 공개 API(2001b)를 통해 다른 애플리케이션(2030)에 액세스가능하게 될 수 있다.
한 실시예에서, 게임 프레임워크(2000)에 의해 노출된 API(2001)는, 모바일 장치(120)에 대한 멀티플레이어, 협력적 게임을 설계하는 과정을 단순화시킨다. 특히, 한 실시예에서, API(2001)는, 개발자들이 간단한 API 호출을 행하여 멀티플레이어, P2P 게임 세션에 대해 사용자들을 접속하는 비교적 복잡한 프로세스를 기동시키는 것을 허용한다. 예를 들어, INVITE(플레이어 B ID, 버켓 ID)와 같은 간단한 API 호출이 API(2001)로부터 기동되어 전술된 세부적인 초대 시퀀스를 개시할 수 있다. 마찬가지로, MATCH(플레이어 A ID, 버켓 ID)와 같은 간단한 API 호출이 API(2001)로부터 기동되어 전술된 세부적인 중매 시퀀스를 개시할 수 있다. INVITE 및 MATCH 함수는 때때로 일반적으로 본 명세서에는 "P2P 접속 함수"라고 불린다. 한 실시예에서, 게임 프레임워크(2000)는 (이하에서 상세히 설명되는 바와 같은) 이들 API 호출에 응답하여 초대와 중매 동작을 관리하는데 요구되는 프로그램 코드를 포함한다. 실제의 API 함수들은 앞서 개시된 것들과는 다소 상이한 데이터 포맷을 가질 수 있다(비록 이들이 결과적으로 게임 프레임워크(2000)에 의해 수행되는 유사한 동작을 초래할 수도 있지만)는 점에 유의해야 한다. 본 발명의 기저 원리는 API 함수를 명시하기 위한 임의의 특정한 포맷으로 제한되지 않는다.
다양한 다른 타입의 게임-관련 트랜잭션과 정보도 역시, 게임 센터(2031) 및 기타의 애플리케이션(2030)을 대신해 게임 프레임워크(2000)에 의해 관리될 수 있다. 이 정보의 일부는 Game Center 특허 출원에 설명되어 있다. 제한이 아닌 예로서, 이 정보는 각 게임에 대해 최고 점수를 달성한 사용자들에 관련된 "점수판" 정보와, 어떤 게임-특정의 업적을 완료한 사용자들을 식별하는 "업적" 정보를 포함할 수 있다. 각 애플리케이션 개발자들은 각 게임 애플리케이션(2030)에 대한 그들 자신의 "업적" 세트(예를 들어, 레벨 1-3 완료; 5분 이하에서 레벨 1 완료; 레벨당 50 킬; 20 플래그 녹다운 등)를 명시할 수 있다.
게임 프레임워크(2000)는 또한, 사용자의 친구 데이터를 관리하고 게임 센터(2031) 및 기타의 게이밍 애플리케이션(2030)의 콘텍스트 내에서 친구 데이터를 통합하기 위한 프로그램 코드를 포함할 수 있다. 예를 들어, 사용자가 게임 센터(2031) 내의 특정 게임에 대한 링크를 선택하면, 그 게임에 대하여 그 사용자의 친구들 각각에 관련된 정보(예를 들어, 점수판에서의 친구들의 랭킹, 친구들의 업적, 그 사용자가 그/그녀의 각 친구와 게임을 플레이했을 때의 결과 등)가 디스플레이된다. 한 실시예에서, 게임 프레임워크(2000)의 API(2001)는, 본 출원의 양수인에게 양도되고 참조에 의해 본 명세서에 포함되는, Attorney Docket 번호 제4860.P9240이고, 발명자가 Amol Pattekar, Jeremy Werner, Patrick Gates, 및 Andrew H. Vyrros이며, 2010년 4월 7일 출원된 출원번호 ____이며, 발명의 명칭이 Apparatus and Method for Efficiently Managing Data in a Social Networking Service인(이하에서는 “Friend Service 출원”이라 함) 동시계류중인 출원에서 설명된 바와 같은 친구 서비스에 의해 관리되는 친구 데이터를 액세스하기 위한 함수를 포함한다.
도 20에 나타낸 바와 같이, 한 실시예에서, 게임 데몬(daemon)(2020)은 게임 프레임워크(2000)를 제1 세트의 서비스(2050)에 인터페이싱하고, 게임 서비스 컴포넌트(2010)는 게임 프레임워크(2000)를 제2 세트의 서비스(2051)에 인터페이싱할 수도 있다. 예로서, 제1 세트의 서비스(2050)는, 전술된 초대 서비스(112), 중매자 서비스(111), 중계 서비스(1051), 및 상기 언급된 Friend Service 출원에서 설명되는 친구 서비스를 포함할 수 있다. 게임 데몬(2020)을 통해 액세스될 수 있는 기타의 서비스들로는, (점수판 데이터를 제공하는) 점수판 서비스; (각 게임 및 게임 구입 능력에 관련된 통계와 기타의 데이터를 제공하는) 게임 서비스; (모바일 장치의 사용자를 인증하기 위한) 사용자 인증 서비스; 및/또는 (사용자 선호사항과 같은 사용자 프로파일 데이터를 저장하기 위한) 사용자 프로파일 서비스가 포함된다. 게임 서비스 컴포넌트(2010)를 통해 액세스되는 제2 세트의 서비스(2051)는, 전술된 접속 데이터 교환(CDX) 서비스(110) 및 NAT 횡단 서비스(290-291)를 포함할 수 있다. 설명의 목적을 위해 도 20에서는 별개의 컴포넌트로서 나타나 있지만, 게임 데몬(2020) 및 게임 서비스 모듈(2010)은 실제로 게임 프레임워크(2000)의 컴포넌트일 수 있다. 한 실시예에서, 게임 데몬(2020 및 2010)은, 한 실시예에서는 사설 (즉, 제3자 개발자들에게 공개되지 않은) API인 미리정의된 API를 통해 네트워크 서비스(2050-2051) 각각과 통신한다.
한 실시예에서, 게임 데몬(2020)은 HTTPS 프로토콜을 이용하여 중매자 서비스(111), 초대 서비스(112), 및 기타의 서비스(2050)와 통신할 수 있는 반면, 게임 서비스 모듈(2010)은 UDP 소켓과 같은 비교적 가벼운 프로토콜을 이용하여 CDX 서비스(110) 및 NAT 횡단 서비스(290-291)와 통신할 수 있다. 그러나, 전술된 바와 같이, 본 발명의 기저 원리를 여전히 따르면서 다양한 다른 네트워크 프로토콜이 이용될 수 있다.
또한, 도 20에 나타낸 바와 같이, 게임 데몬(2020)은 소정 서비스(2052)(예를 들어, 초대 서비스 및 중매자 서비스)에 의해 생성된 푸시 통보(2052)를 수신할 수 있는 반면, 다른 타입의 푸시 통보(2053)(예를 들어, 새로운 친구 요청과 같은 친구 서비스 통보)는 게임 센터에 의해 직접 수신될 수 있다. 한 실시예에서, 이들 푸시 통보(2053)는, 사용자의 민감한 데이터가 제3자 애플리케이션 개발자들에 의해 설계된 애플리케이션(2030)에게 액세스가능하지 않을 것을 보장하기 위해 게임 센터(2031)에 직접 제공된다.
상기 도 11에 개시된 게임 초대 예로 되돌아가면, 모바일 장치 A 상의 애플리케이션(2030)이 게임 프레임워크(2000)의 API(2001b)에 초대 호출을 행하여 모바일 장치 B의 사용자를 초대하면(예를 들어, INVITE (플레이어 B ID, 게임/버켓 ID)), 게임 프레임워크(2000)는 초대 요청을 모바일 장치 A의 게임 데몬(2020)에 전달할 수 있다. 그러면, 게임 데몬(2020)은 초대 요청을 제출하기 위해 초대 서비스(112)와 통신할 수 있다. 그러면, 초대 서비스(112)는 (전술된 바와 같은) 푸시 통보 서비스(1050)를 이용하여 모바일 장치 B의 게임 데몬(2020)에 초대를 푸시할 수 있다. 그러면, 모바일 장치 B의 게임 데몬(2020)은 모바일 장치 B의 게임 프레임워크(2000)와 통신하여 초대가 전송된 게임이 모바일 장치 B에 설치되어 있는지를 판정한다. 설치되어 있다면, 게임 프레임워크(2000)는 애플리케이션(2030)을 트리거하고 및/또는 초대의 시각적 통보를 생성할 수도 있다. 애플리케이션이 설치되어 있지 않다면, 게임 프레임워크(2000)는 (예를 들어, 게임 센터(2031) GUI를 통해) 게임의 구입 제안과 함께 모바일 장치 B의 사용자에게 초대의 시각적 통보를 트리거할 수 있다. 대안으로서, 시각적 통보는 (도시되지 않은) 모바일 장치(120) 상에서 실행중인 푸시 통보 데몬에 의해 생성될 수 있다. 모바일 장치 B의 사용자가 게임을 구입한다면, 구입에 후속하여 초대 시퀀스가 계속될 수 있다. 모바일 장치 B의 사용자가 초대 요청을 수락한다면, 모바일 장치 B의 게임 프레임워크(2000)는 초대 요청을 그 게임 데몬(2020)에 전달하고, 그 다음 게임 데몬(2020)이 초대 서비스(112)에 응답할 수 있다.
도 11에서, 호환성 검사(1106)는 모바일 장치 A와 B의 NAT 타입들이 호환되는지를 판정한다는 것을 상기한다. 따라서, 1108에서, 모바일 장치 A의 게임 데몬(2020)은 모바일 장치 B의 수락을 (예를 들어, 이 예에서는 푸시 통보를 통해) 수신할 수 있고, 한 실시예에서는, 그 수락을 게임 프레임워크(2000)에 전달한다. 이 단계에서, 모바일 장치 A의 게임 프레임워크(2000)는 (API(2001)를 통해) 모바일 장치 B가 수락했다는 것을 요청측 애플리케이션(2030)에 통보하거나, 장치들이 성공적으로 접속될 때까지 요청측 애플리케이션(2030)에 통보하는 것을 대기할 수 있다. 어느 경우든, 게임 프레임워크(2000)는, 한 실시예에서는, 모바일 장치 B와의 접속 데이터 교환을 개시할 수 있는 게임 서비스 모듈(2010)에 접속 요청을 전달할 수 있다. 특히, 게임 서비스 모듈은 CDX 서비스(110)를 이용하여 모바일 장치 B에 모바일 장치 A의 접속 데이터를 전송할 수 있다(예를 들어, 도 11의 트랜잭션(1111 및 1112)을 참조). 전술된 바와 같이, 이 통신은 보안 "티켓" 데이터 구조를 이용하여 UDP 접속으로서 구현될 수 있다.
도 12에서, 호환성 검사(1106)가 모바일 장치 A와 B의 NAT 타입들이 호환되지 않는다고 판정한다면, 장치들 사이의 접속을 제공하기 위해 중계 서비스(1051)가 이용될 수 있다는 점을 상기한다. 결과적으로, 모바일 장치 B의 게임 데몬(2020)은 (도 12에 도시된) 초대 서비스로부터 중계 응답(1203)을 수신할 수 있고, 모바일 장치 A의 게임 데몬(2020)은 (푸시 통보 서비스(1050)를 통해) 초대 서비스로부터 중계 응답(1205)을 수신할 수 있다. 모바일 장치 A와 B의 게임 데몬(2020)은 구성 데이터를 검색하기 위해 1206 및 1207에서 중계 서비스와 통신할 수 있다. 1210에서, 모바일 장치 B의 게임 데몬(2020)은 모바일 장치 A로부터 중계 업데이트 데이터를 수신하고, 1213에서, 모바일 장치 A의 게임 데몬(2020)은 모바일 장치 B로부터 중계 업데이트 데이터를 수신한다.
도 11 및 도 12에 도시된 프로세스의 최종 결과는, 모바일 장치 A와 B가 서로와의 접속(직접적 P2P 접속이거나 중계 접속)을 설정한다는 것이다. 한 실시예에서, 성공적 접속의 검출시에, 게임 프레임워크(2000)는 API 호출(예를 들어, CONNECTED (플레이어 A ID, 플레이어 B ID))을 이용하여 접속을 요청한 애플리케이션(2030)에게 통보할 수 있다. 모바일 장치 A와 B는 그 다음, 설정된 접속을 이용하여 명시된 게임이나 기타의 협력적 애플리케이션(2030)을 플레이할 수 있다.
따라서, API(2001)로부터의 비교적 간단한 호출 (예를 들어, INVITE 플레이어 B ID, 게임/버켓 ID)에 응답하여, 모바일 장치 A와 B 사이에 P2P 또는 중계 접속을 설정하기 위해 복잡한 일련의 트랜잭션이 게임 프레임워크(2000)에 의해 관리될 수 있다. 한 실시예에서, 게임 프레임워크(2000)는 모바일 장치 A와 B를 접속하는 동작들의 시퀀스를 수행한 다음, 요청측 애플리케이션(2030)에 그 결과를 제공함으로써, API 호출의 상세사항을 애플리케이션 설계자에게 투명하게 한다. 이와 같이, 애플리케이션 설계자는 네트워크 상에서 모바일 장치 A와 B를 접속하는 방법이나 장치들 사이의 통신을 가능케하기 위해 요구되는 기타의 다양한 함수들을 수행하는 방법에 관해 이해할 것이 요구되지 않음으로써, 애플리케이션 설계 과정을 단순화한다.
유사한 방식으로, 게임 프레임워크(2000)는 도 2a 및 도2b에 관하여 전술된 바와 같이 중매자 서비스(111)를 이용하여 모바일 장치 A와 다른 참여자들 사이의 매치를 설정할 수 있다. 이 예에서, 애플리케이션(2030)은 MATCH(플레이어 A ID, 게임/번들 ID)와 같은 단순한 호출을 API(2001)에 행할 수 있다. 응답하여, 게임 프레임워크(2000)는 매치와 접속 데이터 교환 동작을 관리할 수 있다. 매치 동작 및/또는 P2P 접속이 완료되면, 게임 프레임워크(2000)는 그 결과를 애플리케이션(2030)에게 다시 제공한다.
예를 들어, 도 2b에서, 게임 프레임워크(2000)는 접속 데이터 교환(CDX) 서비스(110) 및 NAT 횡단 서비스(290-291)와 통신하기 위해 게임 서비스 모듈(2010)을 이용하고, 중매자 서비스(111)와 통신하기 위해 게임 데몬을 이용할 수 있다. 일단 매치가 이루어지고 나면, 모바일 장치 A의 게임 데몬(2020)은 229에서 티켓 A를 수신하고, 게임 프레임워크(2000)는 이 정보를 이용하여 게임 서비스 모듈(2010)을 통한 접속 데이터 교환을 구현한다. 예를 들어, 232에서, 이것은 NAT 횡단 서비스(290)를 통해 그 자신의 접속 데이터를 요청한 다음, 그 접속 데이터를 CDX 서비스(110)를 통해 233-234에서 교환할 수 있다. 237 및 240에서, 모바일 장치 A의 게임 서비스 모듈(2010)은 각각 모바일 장치 B와 C에 대한 접속 데이터를 수신한다. 이들 교환에 후속하여, 게임 서비스 모듈(2010)은 241에서 P2P 접속을 설정하고 게임 프레임워크(2000)는 API 통보(예를 들어, MATCH COMPLETE (플레이어 B ID, 플레이어 C ID))를 이용하여 애플리케이션(2030)에게 접속 프로세스가 완료되었음을 통보한다. 그러면, 설정된 P2P 접속을 이용하여 애플리케이션이 실행될 수 있다.
일부 실시예들에서, 사용자에게는 현재 "온라인"으로 등록된 다른 친구들과 게임을 플레이할 옵션이 부여될 수 있다. 이 경우, 어떤 친구들이 온라인이라는 통보가 푸시 통보(2052) 또는 푸시 통보(2053)를 통해 제공(게임 센터(2031)에 의해 직접 수신)될 수 있다. 그러면 게임 센터(2031) 및/또는 애플리케이션(2030)은 그 통보를 사용자에게 제공하고 한 명 이상의 선택된 온라인 친구들과 플레이할 옵션을 사용자에게 제공할 수 있다. 그러나, 본 명세서에 설명된 초대 시퀀스는 온라인 통보가 제공되는지에 관계없이 작동할 것이라는 점에 유의해야 한다. 한 실시예에서, 사용자의 온라인 상태는 게임 데몬(2020)에 의해 액세스가능한 서비스에 의해(예를 들어, 상기 언급한 친구 서비스에 의해 또는 별개의 "존재(presence)" 서비스에 의해) 모니터링될 수 있다.
게임 프레임워크(2000)의 한 실시예는, 사용자가 한 명 이상의 친구를 초대하여 한 그룹의 미지의 매치된 참여자들과 플레이할 수 있는 초대/중매 서비스의 조합을 제공한다. 예를 들어, 게임이 4명의 플레이어를 요구하고, 제1 사용자가 제2 사용자를 초대하여 게임을 플레이한다면, 초대 서비스(112)는 처음에 제1 사용자와 제2 사용자를 접속하고, 그 다음, 중매 서비스(111)는 제1 사용자 및 제2 사용자를 2명(또는 그 이상의) 다른 플레이어와 매치시킬 수 있다. 이 실시예에서, 게임 프레임워크(2000)는 처음에, 제1 사용자와 제2 사용자를 접속하기 위해 전술된 초대 시퀀스를 수행할 수 있다. 한 실시예에서, 일단 제1 사용자와 제2 사용자가 성공적으로 접속되고 나면, 게임 프레임워크(2000)는 다른 사용자들을 식별하고 이들과 접속하기 위해 중매 시퀀스를 구현할 수 있다. 앞서 언급한 바와 같이, 한 실시예에서, 중매 서비스에 의해 적용되는 매치 기준은 제1 및 제2 사용자 양자 모두(예를 들어, 제1 및 제2 사용자 양자 모두의 NAT 타입, 접속 타입, 언어 등)를 포함할 수 있다. 대안으로서, 중매 결정을 내리기 위하여 2명의 사용자들 중 한 명의 기준이 평가될 수 있다.
일단 모든 사용자들이 접속되고 나면, 게임 프레임워크(2000)는 API(2001)를 통해 접속을 요청한 애플리케이션(2030)에 접속 결과를 제공할 수 있다. 다시 한번, 애플리케이션(2030)에 의한 비교적 단순한 API 호출에 응답하여, 게임 프레임워크(2000)는 장치들 각각을 접속하기 위하여 한 세트의 복잡한 트랜잭션 내에 진입한다. 일단 장치들이 성공적으로 접속되고 나면, 게임 프레임워크(2000)는 결과를 요청측 애플리케이션(2030)에 다시 제공한다.
도 20에 나타낸 바와 같이, 게임 프레임워크(2000)는 사용자와 다른 게임 참여자들 사이의 통신을 임시로 저장하는 통신 버퍼(2003)를 포함할 수 있다. 통신은 , 예를 들어, 텍스트, 오디오, 및/또는 비디오 통신을 포함할 수 있다. 게임 프레임워크(2000)는 각 애플리케이션(2030)의 요구에 기초하여 버퍼(2003)를 설정할 수 있다. 예를 들어, 느린 네트워크 접속에 의한 오디오/비디오 통신을 위해서는 상대적으로 더 큰 버퍼(2003)가 요구될 수 있다. 한 실시예에서, 각 애플리케이션(2030)은 API(2001)를 통해 소정 크기의 통신 버퍼를 설정하기 위해 (예를 들어, BUFFER (크기) 명령을 이용하여) 명시적 요청을 행할 수 있다. 대안으로서, 게임 프레임워크(2000)는 각 애플리케이션의 통신 요건에 기초하여 버퍼를 자동으로 생성할 수 있다. 예를 들어, 게임 프레임워크(2000)는 텍스트, 오디오, 및/또는 비디오가 지원될 필요가 있는지에 기초하여 특정한 버퍼 크기를 선택할 수 있다.
한 실시예에서, 통신 버퍼(2003)는 사용자들 사이에서 모든 P2P 접속들이 설정되기 이전에 통신 스트림을 임시로 저장할 수 있다. 예를 들어, 초대 서비스(112) 또는 중매자 서비스(111)가 각 사용자를 식별한 후이지만 CDX 서비스(110)가 접속 데이터 교환 동작을 완료하기 이전에, 각 사용자는 접속되고 있는 도중에 다른 게임 참여자들을 통보받을 수 있다. 이 단계에서, 모바일 장치(120)의 사용자는, 텍스트, 오디오, 및/또는 비디오 통신 스트림을 다른 참여자들에게 전송할 수 있다. 게임 프레임워크(2000)는 아직 접속되지 않은 참여자들에 대한 통신 스트림을 통신 버퍼(2003) 내에 저장할 것이다. 게임 프레임워크(2000)는 그 다음, 각 장치에 대한 접속이 완료됨에 따라 버퍼(2003)로부터 텍스트, 오디오, 및/또는 비디오를 전송할 수 있다.
한 실시예에서, 게임 데몬(2020)은, 네트워크 트래픽을 줄이기 위해 각 서비스(2050)들 상에서 지속되는 데이터를 캐싱하기 위한 캐시(2021)를 포함한다. 예를 들어, 사용자의 친구 목록, 점수판 데이터, 업적 데이터, 존재 데이터, 및 프로파일 데이터가 캐시 관리 정책에 의해 명시된 바와 같이 캐시(2021)에 저장될 수 있다. 한 실시예에서, 캐시 관리 정책은 데이터가 저장되는 각 개별 서비스에 의해 구동된다. 결과적으로, n개의 상이한 서비스에 대해, n개의 상이한 캐시 관리 정책이 캐시(2021)에 적용될 수 있다. 또한, 캐시 관리 정책은 서비스들에 의해 구동되기 때문에, 캐시 관리 정책은 현재의 네트워크 및/또는 서버 부하 상태에 기초하여 동적으로 수정될 수 있다. 예를 들어, 서비스에 부하가 많이 걸리는 기간 동안에(예를 들어, 크리스마스, 신제품 출시일 등), 서비스는 비교적 덜 빈번한 캐시 업데이트(예를 들어, 매 12시간마다 업데이트)를 갖는 캐시 관리 정책을 동적으로 명시할 수 있다. 대조적으로, 서비스에 부하가 많이 걸리지 않는 기간 동안에, 서비스는 더 빈번한 캐시 업데이트(예를 들어, 매 1/2시간, 1시간, 2시간 마다의 업데이트 등)를 갖는 캐싱 정책을 명시할 수 있다.
한 실시예에서, 캐시 관리 정책은, 캐시(2021)에 저장된 소정의 데이터 레코드에 대한 생존 시간(TTL; time-to-live) 값을 이용하여 명시된다. 데이터 레코드가 그 TTL 값을 지나서 캐시에 저장되고 있다면, 그 데이터는 "오래된(stale)" 것으로 간주되고, 그 데이터에 대한 국지적 요청은 그 데이터와 연관된 서비스에 직접 포워딩될 수 있다. 한 실시예에서, 이 요청은 데이터의 현재 버전을 식별하는 ID 코드를 포함한다. ID 코드가 서비스 상의 ID 코드와 일치하면, 그 데이터는 여전히 유효하고 업데이트될 필요가 없다. 그 다음, 캐시 내의 데이터가 현행(current)이라는 것을 나타내는 응답이 서비스로부터 되전송되고, 그 데이터 레코드에 대한 TTL 값이 리셋될 수 있다.
전술된 바와 같이 캐시 관리 정책을 이용하는 것 외에도, 한 실시예에서, 소정 타입의 데이터에 대한 캐시 업데이트가 푸시 통보 서비스(1050)를 이용하여 모바일 장치에 푸시될 수 있다. 예를 들어, 사용자 친구 목록에 대한 변경이나 사용자 친구의 현재 온라인 상태에 대한 변경이, 사용자의 모바일 장치(120)에 동적으로 푸시될 수도 있다. 푸시 통보는 게임 데몬(2020)에 의해 수신되고, 그 다음, 게임 데몬(2020)은 서비스에 의해 푸시된 데이터의 관련 부분을 포함하도록 캐시(2021)를 업데이트할 수 있다(즉, 그 서비스와 연관된 캐시 내의 데이터 모두의 업데이트가 요구되는 것은 아닐 수도 있다). 대조적으로, 일부 푸시 통보는 게임 데몬(2020)에게 캐시의 전체 내용을(또는 푸시를 수행하는 서비스와 연관된 캐시의 적어도 일부를) 오버라이트하도록 지시할 수 있다.
캐시(2021)를 업데이트하기 위해 푸시를 이용하는 이들 서비스들은, 캐시(2021)에 저장된 데이터를 업데이트하라는 통보를 푸시하는 능력을 갖기 때문에 비교적 높은 TTL 값을 선택할(및/또는 TTL 값을 설정하지 않을) 수 있다. 한 실시예에서, 각 서비스는 푸시 통보 캐시 업데이트를 트리거할 수 있는 한 세트의 이벤트를 명시한다. 예를 들어, 캐시 업데이트 이벤트는, 친구의 온라인 상태에 대한 변경, 새로운 친구 요청, 친구 요청의 수락, 친구해제 동작, 친구가 특정 게임을 플레이하고 있다는 표시, 친구가 도달한 게임 업적, 특정 점수판의 탑 10에 대한 업데이트, 또는 캐시 업데이트를 보장하기에 충분히 중요하다고 여겨지는 기타 임의의 이벤트를 포함할 수 있다. 이런 방식으로 캐시(2021)를 업데이트하기 위해 푸시 통보를 이용하는 것은 네트워크 및 서비스 부하를 감소시킬 수도 있는데, 이것은 푸시 업데이트에 의해, 모바일 장치와 서비스 사이의 주기적 폴링이 요구되지 않기 때문이다.
게임 프레임워크(2000)의 한 실시예는, 사용자의 국가 및/또는 지리적 위치에 기초하여 엔드 유저에 제시되는 데이터를 고유하게 포맷팅한다. 예를 들어, 현재 날짜, 시간, 및 금전 가치와 같은 값들은, 상이한 국가 및 장소의 사용자들에게 상이하게 제시될 수 있다. 예로서, 미국에서, 날짜 포맷은 [월 일, 연도](예를 들어, 4월 25일, 2010년)인 반면, 다른 나라에서는, 날짜 포맷은 [날 월, 연도](예를 들어, 25일 4월, 2010년)일 수 있다. 마찬가지로, 미국 및 일부 다른 나라들에서 시간을 표시할 때, AM/PM 표기가 이용될 수 있고, 시간과 분 사이에 콜론이 이용될 수 있다(예를 들어, 3:00 PM). 대조적으로, 많은 다른 나라들은 AM/PM 표기를 이용하지 않고, 및/또는 시간과 분 사이에 콤마를 이용한다(예를 들어, 15,00). 또 다른 예로서, 세계의 많은 지역들은 미터법(metric system)을 이용하는 반면, 세계의 일부 지역에서는 이용하지 않는다(예를 들어, 미국). 이들은 본 발명의 소정 실시예들에 의해 이용될 수 있는 단순한 예일 뿐이라는 점에 유의해야 한다. 본 발명의 기저 원리는 임의의 특정 세트의 데이터 포맷으로 제한되지 않는다.
한 실시예에서, 이들 상이한 데이터 포맷들은, 점수판 데이터, 업적 데이터, 친구 데이터, 및/또는 게임 프레임워크(2000)에 의해 처리되는 기타 임의의 데이터를 표시할 때 선택될 수 있다. 게임 프레임워크(2000)는 다양한 방식으로 사용자의 국가 및/또는 지리적 위치를 판정할 수 있다. 예를 들어, 한 실시예에서, 이 정보는 단순히 사용자의 프로파일 데이터에 제공되거나 및/또는 사용자의 셀룰러 서비스 제공자에 기초하여 결정될 수 있다. 사용자의 위치는 또한, 예를 들어, GPS(Global Positioning System) 추적을 이용하여 결정될 수 있다.
지리적 위치 및/또는 국가와 관련없는 다른 타입의 데이터 포맷팅도 게임 프레임워크(2000)에 의해 관리될 수 있다. 예를 들어, 점수판 데이터를 디스플레이할 ?, 가장 낮은 점수가 그 사용자를 점수판의 최상단 또는 최하단에 위치시켜야 할지를 아는 것이 중요하다. 일부 게임의 경우(예를 들어, 골프, 트랙, 레이싱, 스키 등), 낮은 점수일수록 더 나은 성과를 나타내는 반면, 다른 게임에서는(예를 들어, 풋볼, 야구 등), 높은 숫자일수록 더 나은 성과를 나타낸다. 따라서, 한 실시예에서, 애플리케이션(2030)은 API(2001)를 통해 이용될 점수의 타입(예를 들어, "오름차순" 또는 "내림차순")을 명시한다. 그 다음, 게임 프레임워크(2000)는, 점수를 디스플레이하기 위한 적절한 세트의 라벨과 포맷팅을 이용할 수 있다.
게임 프레임워크(2000)의 한 실시예는 또한, 사용자와 사용자의 친구 사이의 관계에 기초하여 사용자 데이터를 필터링한다. 예를 들어, 본 발명의 한 실시예는 "상세" 뷰, "친구" 뷰, 및 "공개" 뷰를 허용한다. 한 실시예에서, 상세 뷰는 그 데이터를 소유하는 사용자에게 이용가능하다(즉, 사용자의 개인 정보); 친구 뷰는 사용자의 친구에게 이용가능하다; 그리고, 공개 뷰는 다른 모든 사용자들에게 이용가능하다.
예로서, 공개 뷰(public view)는 단순히, 각 사용자와 연관된 "별명(alias)", 그 별명으로 플레이하는 게임들 및 연관된 점수, 및 게임이 플레이된 날짜/시간을 포함할 수 있다. 이 정보는, 공개 점수판을 채우기 위해 게임 프레임워크(2000)에 의해 이용된 다음, 게임 센터(2031)를 통해 표시될 수도 있다.
예를 들어, 친구 뷰는, 몇 가지 예를 들자면, 사용자가 소유한 게임들; 사용자가 플레이한 게임들; 사용자의 업적 및 점수; 사용자의 친구수; 이들 친구들의 신원; 사용자의 아바타를 식별하는 URL, 및/또는 사용자의 온라인 상태를 포함한, 사용자의 친구들 사이에서 공유되는 임의의 추가 정보 뿐만 아니라 일반적인 뷰로부터의 정보 모두를 포함할 수 있다. 한 실시예에서, "친구" 뷰는 친구들과 공유할 디폴트 세트의 정보를 제공하지만, 엔드 유저는 이 디폴트 구성을 조정하고 각 개별 친구 또는 친구 그룹(예를 들어, 동료, 가족 구성원, 대학/고등학교 친구 등)에 의해 공유될 정보의 타입을 구체적으로 명시할 수 있다.
"상세" 뷰는, "공개" 및 "친구" 뷰로부터의 모든 정보 뿐만 아니라 엔드 유저를 위하여 다양한 서비스(2050)에 의해 관리되는 기타 임의의 정보를 포함할 수 있다. 예로서, 이것은, 사용자의 모든 프로파일 데이터; 사용자의 UUID(Universally Unique Identifier)(때때로, 본 명세서에는 "플레이어 ID"라고 함); 플레이어 이름; 별명; 게임수 및 게임의 아이덴티티; 사용자의 친구; 사용자의 모든 업적 등을 포함할 수 있다.
일부 상황에서는, 애플리케이션(2030)은 각 사용자의 플레이어 ID와 같은 각 사용자에 관련된 소량의 정보만을 요구할 수 있다. 예를 들어, 한 실시예에서, 매치가 요청되면, 게임 프레임워크(2000)는 처음에 각 플레이어의 ID만을 요구할 수 있다. 중매자 서비스에 의해 매치들이 이루어짐에 따라(상기 참조), 게임 프레임워크(2000)는 매치된 사용자들 중 임의의 사용자가 친구인지를 판정할 수 있다(예를 들어, 친구 서비스와의 통신을 통해, 및/또는 사용자의 국지 친구 데이터에서 정보를 얻음으로써). 임의의 사용자가 친구라면, 게임 프레임워크(2000)는 추가의 사용자 데이터를 검색하고, 그 데이터를 임의의 매치된 친구들에게 제공할 수 있다. 이런 방식으로, 게임 프레임워크(2000)는 사용자의 신원과 사용자들 각자 간의 관계에 기초하여 정보를 필터링한다.
한 실시예에서, 게임 프레임워크(2000)는 처음에 제1 사용자와 제2 사용자가 친구 관계가 아니라면 이들 사이의 공개 뷰를 제공한다. 그러나, 한 실시예에서, 게임 프레임워크(2000)는 제1 사용자가 제2 사용자에게 친구 요청을 전송하는 것을 허용한다(예를 들어, 제2 사용자의 별명을 이용하여). 친구 요청이 수락되면, 게임 프레임워크(2000)는 사용자들 각자에게 추가 정보(예를 들어, 디폴트 "친구" 뷰)를 제공할 것이다.
상이한 API 실시예
한 실시예에서 구현된 API는 소프트웨어 컴포넌트(이하에서는 "API 구현 소프트웨어 컴포넌트)에 의해 구현된 인터페이스로서, 상이한 소프트웨어 컴포넌트(이하에서는 "API 호출 소프트웨어 컴포넌트")가 상기 API 구현 소프트웨어 컴포넌트에 의해 제공되는 하나 이상의 함수, 방법, 프로시져, 데이터 구조, 및/또는 기타의 서비스들을 액세스하여 이용하는 것을 허용한다. 예를 들어, API는 API 호출 소프트웨어 컴포넌트의 (제3자 개발자일 수 있는) 개발자가 API 구현 소프트웨어 컴포넌트에 의해 제공된 명시된 특징을 레버리지하는 것을 허용한다. 하나의 API 호출 소프트웨어 컴포넌트가 있거나, 둘 이상의 이러한 소프트웨어 컴포넌트가 있을 수 있다. API는, 소프트웨어 애플리케이션으로부터의 서비스들에 대한 요청을 지원하기 위해 컴퓨터 시스템이나 프로그램 라이브러리가 제공하는 소스 코드 인터페이스일 수 있다. API는, 메모리에서 데이터가 어떻게 레이아웃되는지에 관한 명시적 로우 레벨 설명이 아니라, 애플리케이션 구축시에 인터프리터되거나 컴파일될 수 있는 프로그래밍 언어에 의해 명시될 수 있다.
API는, API 구현 소프트웨어 컴포넌트의 명시된 특징을 액세스하여 이용할 때 API 호출 소프트웨어 컴포넌트가 이용하는 언어와 파라미터를 정의한다. 예를 들어, API 호출 소프트웨어 컴포넌트는, API에 의해 노출된 하나 이상의 API 호출(때때로, 함수 또는 메소드 호출이라고 함)을 통해 API 구현 소프트웨어 컴포넌트의 명시된 특징을 액세스한다. API 구현 소프트웨어 컴포넌트는, API 호출 소프트웨어 컴포넌트로부터의 API 호출에 응답하여 API를 통해 값을 반환할 수 있다. API가 API 호출의 구문론(syntax)과 결과(예를 들어, API 호출을 기동하는 방법과 API 호출이 무엇을 하는지)를 정의하지만, API는 통상, API 호출이 API 호출에 의해 명시된 함수를 어떻게 달성할 수 있는지를 드러내지 않는다. 호출측 소프트웨어(API 호출 소프트웨어 컴포넌트)와 API 구현 소프트웨어 컴포넌트 사이의 하나 이상의 애플리케이션 프로그래밍 인터페이스를 통해 다양한 함수 호출과 메시지들이 전송된다. 함수 호출이나 메시지를 전송하는 것은, 함수 호출이나 메시지의 발생, 개시, 기동, 호출, 수신, 반환, 또는 이에 대한 응답을 포함할 수 있다. 따라서, API 호출 소프트웨어 컴포넌트는 호출을 전송할 수 있고, API 구현 소프트웨어 컴포넌트는 호출을 전송할 수 있다.
예로서, API 구현 소프트웨어 컴포넌트(2010) 및 API 호출 소프트웨어 컴포넌트는, 운영 체제, 라이브러리, 장치 드라이버, API, 애플리케이션 프로그램, 또는 기타의 소프트웨어 모듈일 수 있다(API 구현 소프트웨어 컴포넌트 및 API 호출 소프트웨어 컴포넌트는 서로 동일하거나 상이한 타입의 소프트웨어 모듈일 수 있다는 점에 유의해야 한다). API 호출 소프트웨어 컴포넌트는, 국지적 소프트웨어 컴포넌트(즉, API 구현 소프트웨어 컴포넌트와 동일한 데이터 처리 시스템 상), 또는 네트워크를 통해 API 구현 소프트웨어 컴포넌트와 통신하는 원격 소프트웨어 컴포넌트(즉, API 구현 소프트웨어 컴포넌트와 상이한 데이터 처리 시스템 상)일 수 있다. API 구현 소프트웨어 컴포넌트는 API 호출 소프트웨어 컴포넌트로서 동작할 수 있고(즉, 상이한 API 구현 소프트웨어 컴포넌트에 의해 노출된 API에 대한 API 호출을 행할 수 있다), API 호출 소프트웨어 컴포넌트는 상이한 API 호출 소프트웨어 컴포넌트에 노출되는 API를 구현함으로써 API 구현 소프트웨어 컴포넌트로서 동작할 수 있다는 점에 유의해야 한다.
API는 상이한 프로그래밍 언어들로 씌어진 복수의 API 호출 소프트웨어 컴포넌트들이 API 구현 소프트웨어 컴포넌트와 통신하는 것을 허용할 수 있다(따라서, API는 호출을 변환하는 특징을 포함하고 API 호출 소프트웨어 컴포넌트와 API 구현 소프트웨어 컴포넌트 사이에서 복귀한다); 그러나 API는 특정의 프로그래밍 언어의 관점에서 구현될 수 있다.
도 21은, API(2120)를 구현하는 API 구현 소프트웨어 컴포넌트(2110)(예를 들어, 운영 체제, 라이브러리, 장치 드라이버, API, 애플리케이션 프로그램, 또는 기타의 소프트웨어 모듈)를 포함하는 API 아키텍쳐의 한 실시예를 나타낸다. API(2120)는, 하나 이상의 함수, 메소드, 클래스, 객체, 프로토콜, 데이터 구조, 포맷 및/또는 API 호출 소프트웨어 컴포넌트(2130)에 의해 이용될 수 있는 API 구현 소프트웨어 컴포넌트의 다른 특징들을 명시한다. API(2120)는, API 구현 소프트웨어 컴포넌트의 함수가 API 호출 소프트웨어 컴포넌트로부터 파라미터들을 어떻게 수신하는지, 및 이 함수가 API 호출 소프트웨어 컴포넌트에 결과를 어떻게 반환하는지를 명시하는 적어도 하나의 호출 규약을 명시할 수 있다. API 호출 소프트웨어 컴포넌트(2130)(예를 들어, 운영 체제, 라이브러리, 장치 드라이버, API, 애플리케이션 프로그램, 또는 기타의 소프트웨어 모듈)는 API(2120)에 의해 명시되는 API 구현 소프트웨어 컴포넌트(2110)의 특징들을 액세스하여 이용하기 위해 API(2120)를 통해 API 호출을 행한다. API 구현 소프트웨어 컴포넌트(2110)는, API 호출에 응답하여 API(2120)를 통해 API 호출 소프트웨어 컴포넌트(2130)에 값을 반환할 수 있다.
API 구현 소프트웨어 컴포넌트(2110)는, 추가의 함수, 메소드, 클래스, 데이터 구조, 및/또는 API(2120)를 통해 명시되지 않고 API 호출 소프트웨어 컴포넌트(2130)에 이용가능하지 않은 기타의 특징들을 포함할 수 있다는 것을 이해할 것이다. API 호출 소프트웨어 컴포넌트(2130)는 API 구현 소프트웨어 컴포넌트(2110)와 동일한 시스템 상에 있거나, 네트워크를 통해 API(2120)를 이용하여 API 구현 소프트웨어 컴포넌트(2110)에 원격으로 위치하여 액세스할 수 있다는 것을 이해해야 한다. 도 21은 API(2120)와 상호작용하는 하나의 API 호출 소프트웨어 컴포넌트(2130)를 나타내지만, API 호출 소프트웨어 컴포넌트(2130)와는 상이한 언어(또는 동일한 언어)로 씌어질 수 있는 다른 API 호출 소프트웨어 컴포넌트가 API(2120)를 이용할 수 있다는 점을 이해하여야 한다.
API 구현 소프트웨어 컴포넌트(2110), API(2120), 및 API 호출 소프트웨어 컴포넌트(2130)는, 머신(예를 들어, 컴퓨터 또는 기타의 데이터 처리 시스템)에 의해 판독가능한 형태로 정보를 저장하기 위한 임의의 메커니즘을 포함하는 머신-판독가능한 매체에 저장될 수 있다. 예를 들어, 머신-판독가능한 매체는, 자기 디스크, 광학 디스크, 랜덤 액세스 메모리; 판독 전용 메모리, 플래시 메모리 장치 등을 포함한다.
도 22("소프트웨어 스택")에서, 예시적 실시예, 애플리케이션은 수 개의 서비스 API를 이용하여 서비스 1 또는 2를 호출하거나 수 개의 OS API를 이용하여 운영 체제(OS)를 호출할 수 있다. 서비스 1 및 2는 수 개의 OS API를 이용하여 OS에 호출을 행할 수 있다.
서비스 2는 2개의 API를 가지며, 그 중 하나(서비스 2 API 1)는 애플리케이션 1로부터 호출을 수신하여 애플리케이션 1에 값들을 반환하고, 다른 하나(서비스 2 API 2)는 애플리케이션 2로부터 호출을 수신하여 애플리케이션 2에 값들을 반환한다는 점에 유의한다. (예를 들어, 소프트웨어 라이브러리일 수 있는) 서비스 1은 OS API 1에 호출을 행하고 이로부터 반환된 값들을 수신하며, (예를 들어, 소프트웨어 라이브러리일 수 있는) 서비스 2는 OS API 1 및 OS API 2 양쪽 모두에 호출을 행하고 이들로부터 반환된 값들을 수신한다. 애플리케이션 2는 OS API 2에 호출을 행하고 이로부터 반환된 값들을 수신한다.
예시적 데이터 처리 장치
도 23은 본 발명의 일부 실시예들에서 이용될 수 있는 예시적 컴퓨터 시스템을 나타내는 블록도이다. 도 23은 컴퓨터 시스템의 다양한 컴포넌트들을 나타내고 있지만, 컴포넌트들을 상호접속하는 임의의 특정한 아키텍쳐나 방식과 같은 세부사항은 본 발명과 관련없기 때문에 나타낼 의도가 없다는 점을 이해하여야 한다. 더 적거나 더 많은 컴포넌트를 갖는 다른 컴퓨터 시스템들도 본 발명에 이용될 수 있다는 점을 이해할 것이다.
도 23에 나타낸 바와 같이, 데이터 처리 시스템의 한 형태인 컴퓨터 시스템(2300)은, 처리 시스템(2320), 전원(2325), 메모리(2330), 및 비휘발성 메모리(2340)(예를 들어, 하드 드라이브, 플래시 메모리, 상변화 메모리(PCM) 등)과 결합되는 버스(들)(2350)을 포함한다. 버스(들)(2350)은, 본 분야에 공지된 다양한 브릿지, 제어기 및/또는 어댑터들을 통해 서로 접속될 수 있다. 처리 시스템(2320)은 메모리(2330) 및/또는 비휘발성 메모리(2340)로부터 명령어(들)을 검색하여, 전술된 바와 같은 동작들을 수행하기 위해 그 명령들을 실행할 수 있다. 버스(2350)는 상기 컴포넌트들을 함께 상호접속하고, 이들 컴포넌트들을, 선택사항적 도크(2360), 디스플레이 제어기 & 디스플레이 장치(2370), 입력/출력 장치(2380)(예를 들어, NIC(네트워크 인터페이스 카드), 커서 제어(예를 들어, 마우스, 터치스크린, 터치패드 등), 키보드 등), 및 선택사항적 무선 트랜시버(들)(2390)(예를 들어, Bluetooth, WiFi, 적외선 등)에 상호접속한다.
도 24은 본 발명의 일부 실시예들에서 이용될 수 있는 예시적 데이터 처리 시스템을 나타내는 블록도이다. 예를 들어, 데이터 처리 시스템(2400)은, 핸드헬드 컴퓨터, PDA(personal digital assistant), 모바일 전화, 휴대형 게이밍 시스템, 휴대형 미디어 재생기, 모바일 전화, 미디어 재생기, 및/또는 게이밍 시스템을 포함할 수 있는 태블릿 또는 핸드헬드 컴퓨팅 장치일 수 있다. 또 다른 예로서, 데이터 처리 시스템(2400)은 네트워크 컴퓨터이거나 또 다른 장치 내에 내장된 처리 장치일 수 있다.
본 발명의 한 실시예에 따르면, 전술된 모바일 장치에 대해 데이터 처리 시스템(2400)의 예시적 아키텍쳐가 이용될 수 있다. 데이터 처리 시스템(2400)은, 하나 이상의 마이크로프로세서 및/또는 집적 회로 상의 시스템을 포함할 수 있는 처리 시스템(2420)을 포함한다. 처리 시스템(2420)은, 메모리(2410), (하나 이상의 배터리를 포함하는) 전원(2425), 오디오 입력/출력(2440), 디스플레이 제어기 및 디스플레이 장치(2460), 선택사항적 입력/출력(2450), 입력 장치(들)(2470), 및 무선 트랜시버(들)(2430)과 결합된다. 도 24에 도시되지 않은 추가의 컴포넌트들도 본 발명의 소정 실시예들에서 데이터 처리 시스템(2400)의 일부가 될 수 있으며, 본 발명의 소정 실시예들에서는, 도 24에 도시된 것보다 적은 컴포넌트들이 이용될 수 있다는 것을 이해할 것이다. 또한, 본 분야에 공지된 바와 같이 다양한 컴포넌트를 상호접속하기 위해 도 24에 도시되지 않은 하나 이상의 버스가 이용될 수 있다는 것을 이해할 것이다.
메모리(2410)는 데이터 처리 시스템(2400)에 의해 실행되기 위한 데이터 및/또는 프로그램을 저장할 수 있다. 오디오 입력/출력(2440)은, 예를 들어, 음악을 재생하거나 및/또는 스피커 및 마이크로폰을 통해 전화 기능을 제공하기 위하여 마이크로폰 및/또는 스피커를 포함한다. 디스플레이 제어기 및 디스플레이 장치(2460)는 그래픽 유저 인터페이스(GUI)를 포함할 수 있다. 다른 데이터 처리 시스템과 통신하기 위해 무선(예를 들어, RF) 트랜시버(2430)(예를 들어, WiFi 트랜시버, 적외선 트랜시버, Bluetooth 트랜시버, 무선 셀룰러 전화 트랜시버 등)가 이용될 수 있다. 하나 이상의 입력 장치(2470)는 사용자가 시스템에 입력을 제공하는 것을 허용한다. 이들 입력 장치는 키패드, 키보드, 터치 패널, 멀티 터치 패널 등일 수 있다. 선택사항적인 다른 입력/출력(2450)은 도크에 대한 커넥터일 수 있다.
상이한 서비스 제공자들에 걸쳐 P2P 접속을 관리하기 위한 실시예
본 발명의 한 실시예에서, 전술된 아키텍쳐들이 확장되어 상이한 서비스 제공자들에서의 피어들이 실시간 오디오, 비디오, 및/또는 채팅 접속과 같은 피어-투-피어(P2P) 접속을 설정하는 것을 허용한다. 상이한 서비스 제공자들은 그들 자신의 프로토콜과 그들 자신의 클라이언트 ID 명칭공간을 이용할 수 있기 때문에, 본 발명의 이들 실시예들은 장치들이 이용되는 프로토콜에 관계없이 상호연동되는 것을 허용하고 명칭공간들을 단일의 전역 명칭공간으로 통합하는 기술을 제공한다.
전역 데이터베이스는 모든 시스템 상의 모든 사용자의 전역 명칭공간을 추적하도록 유지될 수 있다. 그러나, 서비스 제공자들에 걸쳐 분산된 방대한 수의 사용자를 고려하면, 전역 데이터베이스 접근법은 관리하기 어려울 수도 있다. 대안으로서, 사용자들 및/또는 데이터 처리 장치들을 식별하는데 이용되는 명칭들(예를 들어, 사용자 ID, 전화 번호)은 요청된 접속에 누가 응답할 수 있는지를 식별하기 위해 다른 모든 서비스 제공자들에게 브로드캐스트될 수 있다. 그러나, 다시 한번, 이러한 시스템은 확장성이 없을 것이다(즉, 각각의 시도된 접속에 대해 브로드캐스트 메시지를 전송하는 것은 상당한 양의 대역폭을 소비할 것이다).
상기 문제를 해결하기 위해, 본 발명의 한 실시예는 접속 시도 동안에 관련된 서비스 제공자들의 위치를 파악하기 위해 블룸 필터를 이용한다. 이 실시예는 도 25 및 도 26에 도시된 아키텍쳐에 관하여 기술될 것이다. 4개의 서비스 제공자가 도 25에 나타나 있다 ― 서비스 제공자 A(2510), 서비스 제공자 B(2511), 서비스 제공자 C(2512), 및 서비스 제공자 D(2513). 이전 실시예들에서와 같이, 각 서비스 제공자는 서비스 제공자로부터 데이터 통신 서비스를 제공받는 한 세트의 사용자의 사용자 ID 및/또는 전화 번호를 포함하는 등록 데이터베이스(2520-2523)를 관리한다. 예로서, 도 25에서, 사용자 A-C(2501-2503)는 서비스 제공자 A(2510)로부터 서비스를 제공받으며, 사용자 D-F는 서비스 제공자 D(2513)로부터 서비스를 제공받는다. 전술된 바와 같이, 한 실시예에서, 등록 데이터베이스(2520-2523)는 전화 번호 또는 사용자 ID를 각 사용자의 데이터 처리 장치의 푸시 토큰에 맵핑한다. 따라서, 서비스 제공자들에 의해 유지되는 서버들은 특정한 서비스 제공자의 사용자들이 전술된 기술(예를 들어, 도 10 내지 도 14 및 관련 본문을 참조)을 이용하여 서로 위치를 파악하고 피어-투-피어(P2P) 접속을 설정할 수 있게 한다. 한 예로서, 서비스 제공자들에 의해 유지되는 서버들은 사용자가 FaceTime™ Chat 세션(본 특허 출원의 양수인에 의해 설계된 기술)과 같은 오디오/비디오 채팅 세션을 서로 설정하는 것을 허용한다.
서비스 제공자 자신의 사용자들간에 P2P 접속을 가능케하는 것 외에도, 도 25 및 도 26에 나타내는 실시예들은 상이한 서비스 제공자들의 사용자들이 서로 P2P 접속을 설정하는 것을 가능케 한다. 특히, 도 26에 도시된 바와 같이, 각 서비스 제공자는, 처음에 서비스 제공자의 등록 데이터베이스(2520, 2523)에 질의하여 특정한 사용자가 그 서비스 제공자에 의해 관리되는지를 판정하기 위한 사용자 위치 서비스(2600, 2610)를 포함한다. (간소화를 위해 2개의 서비스 제공자(제공자 A 및 D)가 도 26에 도시되어 있다.) 사용자 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)를 포함한다. 당업자라면 알겠지만, 블룸 필터는 한 요소가 한 세트의 멤버인지를 테스트하는데 이용되는 공간-효율적인 확률적 데이터 구조(probabilistic data structure)이다. 긍정 오류(False positives)는 가능하지만, 부정 오류(false negatives)는 가능하지 않다. 본 명세서에 설명된 실시예에서, 각 블룸 필터를 생성하는데 이용되는 "요소들"은 각 사용자의 사용자 ID 및/또는 전화 번호이다. 도 26에서, 예를 들어, 서비스 제공자 A(2510)의 블룸 필터 생성기(2650)는 그 블룸 필터(2604)를 생성하기 위해 그 사용자 ID들 모두(예를 들어, Andy124, Tom4546 등)를 이용한다. 마찬가지로, 서비스 제공자 D(2513)의 블룸 필터 생성기(2651)는 그 블룸 필터(2603)를 생성하기 위해 그 등록 데이터베이스 내의 사용자 ID들 모두(Woody1234, Rick456 등)를 이용한다. 한 실시예에서, 각 서비스 제공자는 이런 방식으로 그 자신의 블룸 필터를 생성하고 블룸 필터를 다른 모든 서비스 제공자들에게 주기적으로 전송한다. 그러면 각 서비스 제공자는 다른 서비스 제공자들로부터 수신된 블룸 필터를 이용하여 특정한 사용자가 다른 서비스 제공자들에 의해 관리되는지를 테스트하고 판정할 수 있다.
예로서, 도 26에서, 사용자 ID가 Andy123인 사용자 A(2501)가 사용자 ID가 Woody123인 사용자 F(2506)와 P2P 세션(예를 들어, 개인 오디오/비디오 채팅)을 설정하려고 시도한다면, 서비스 제공자 A(2510)의 사용자 위치 서비스(2600)는 처음에 사용자 F의 사용자 이름 Woody123을 그 자신의 등록 데이터베이스(2520)에서 찾으려고 시도할 수 있다. 성공하지 못한다면, 한 실시예에서, 사용자 위치 서비스(2600)는, 사용자 ID "Woody123"을 관리하는 서비스 제공자를 찾기 위한 시도를, 다른 서비스 제공자의 블룸 필터(2601-2603)에게 질의할 것이다. 언급한 바와 같이, 블룸 필터들은 긍정 오류를 제공할 수 있지만 부정 오류는 제공하지 않을 것이다. 따라서, 블룸 필터가 서비스 제공자 B와 C는 Woody123을 관리하지 않는다는 것을 나타내면, 서비스 제공자 A는 Woody123이 이들 서비스 제공자들에 의해 관리되지 않는다고 명확하게 알 것이다. 예시된 예에서, 블룸 필터 질의는 Woody123이 서비스 제공자 D에 의해 관리될 수 있다고 표시하고, 또한, Woody123이 하나 이상의 다른 서비스 제공자에 의해 관리된다고 나타낼 수 있다. 이와 같이, 한 실시예에서, 서비스 제공자 A는 이 사용자 ID를 잠재적으로 관리하는 서비스 제공자들 각각에게 개시 메시지(예를 들어, 사용자 F를 P2P 세션에 초대하는 INVITE 명령)를 전송할 것이다. 사실상 이 사용자 ID를 관리하는 서비스 제공자들은 서비스 제공자 A에게 긍정적으로 응답할 것이다. 일단 올바른 서비스 제공자가 자신을 식별시키고 나면, - 이 예에서는 서비스 제공자 D -, 2개의 서비스 제공자들은 그들 각각의 사용자들(이 예에서는 사용자 A와 F)에 대한 프록시로서 역할할 수 있고 사용자들 사이에 통신 채널을 개방할 수 있다. 일단 사용자 A와 F가 접속 데이터를 교환하고 나면, 이들은 서로 직접적인 P2P 통신 채널을 개방할 것이다(예를 들어, 도 11에 관하여 전술된 기술들을 이용하여 교환하거나 및/또는 표준 인터넷 접속 확립("ICE") 트랜잭션을 구현함으로써). 대안으로서, 직접적인 P2P 접속이 가능하지 않다면(예를 들어, 비호환 NAT 타입으로 인해), 사용자 A와 F는 도 13에 나타낸 중계 서비스(1051)(또한 도 12 및 연관된 본문 참조)를 이용하여 중계 접속을 개방할 수 있다.
한 실시예에서, 각 서비스 제공자는 그 자신의 블룸 필터를 지속적으로 업데이트하고 참여중인 다른 서비스 제공자들 각각에게 블룸 필터를 전송하여 P2P 오디오/비디오 접속을 지원할 것으로 기대된다. 업데이트는, 규칙적인 간격(예를 들어, 매 시간마다 한번, 매일 한번 등)으로 및/또는 소정 개수의 새로운 사용자 ID가 등록 데이터베이스에 추가된 후에 일어날 수 있다. 본 발명의 기저 원리는 서비스 제공자들 사이에 블룸 필터를 교환하기 위한 임의의 특정한 메커니즘으로 제한되지 않는다.
블룸 필터를 생성하고 업데이트하기 위한 방법의 한 실시예가 도 27에 도시되어 있다. 이 방법은 도 25 및 도 26에 도시된 아키텍쳐 상에서 실행될 수 있지만, 임의의 특정한 시스템 아키텍쳐로 제한되지 않는다. 2701에서, 특정한 서비스 제공자의 사용자 등록 데이터베이스가 업데이트된다. 예를 들어, 새로운 사용자 ID/전화 번호가 추가되고 오래된 사용자 ID/전화 번호가 삭제될 수 있다. 2702에서, 전체 세트의 사용자 ID/전화 번호를 이용하여 새로운 블룸 필터가 생성된다. 2703에서, 새로운 블룸 필터가 참여중인 서비스 제공자들에게 전송된다.
클라이언트에 대한 서비스 제공자의 위치를 파악하기 위해 블룸 필터를 이용하기 위한 방법의 한 실시예가 도 27에 도시되어 있다. 이 방법은 도 26 및 도 26에 도시된 아키텍쳐 상에서 실행될 수 있지만, 임의의 특정한 시스템 아키텍쳐로 제한되지 않는다. 2801에서, 한 그룹의 참여중인 서비스 제공자들의 블룸 필터들이 수신된다. 블룸 필터들은 효율적인 액세스를 위해 휘발성 메모리에 저장되거나 및/또는 비휘발성 저장 장소에 영구저장될 수 있다. 2802에서, 사용자(이 예에서는 사용자 A)로부터 또 다른 사용자(사용자 F)와의 P2P 접속을 설정하기 위한 접속 요청이 수신된다. 2803에서, 블룸 필터 기능이 사용자 F의 사용자 ID(예를 들어, 상기 예로부터의 Woody123)에 관해 실행되어 소정의 서비스 제공자들을 배제한다. 블룸 필터 기능이 특정한 블룸 필터에 대해 부정 결과를 반환한다면, 사용자 F는 그 특정 블룸 필터에 의해 관리되지 않는다. 그러나, 블룸 필터에 대해 긍정 결과가 반환된다면, 그 블룸 필터와 연관된 서비스 제공자가 사용자 F를 관리할 타당한 가능성이 있다. 단 하나의 긍정 결과가 반환된다면, 2804에서, 접속 초대가 그 서비스 제공자에게 전송된다. 복수의 긍정 결과가 반환된다면, 2804에서, 별개의 접속 초대가 각각의 관련 서비스 제공자에게 전송될 수 있다.
그러면 사용자 F가 등록된 서비스 제공자는 긍정적으로 응답하고, 2개의 서비스 제공자는 2806에서 프록시로서 행동하여 사용자들이 전술된 바와 같이 접속 데이터(예를 들어, 푸시 토큰, 공개/사설 네트워크 주소/포트, NAT 타입 등)를 교환하는 것을 허용할 수 있다. 둘 이상의 서비스 제공자가 긍정적으로 응답한다면(2개의 서비스 제공자가 동일한 사용자 ID를 갖는 사용자들을 지원한다는 것을 의미), 추가의 단계들이 취해져(예를 들어, 접속하기를 원하는 사용자에 대해 알려진 전화 번호, 실명, 네트워크 주소 또는 기타의 정보를 비교함) 올바른 사용자를 식별한다.
일단 사용자 F에 대한 올바른 서비스 제공자가 식별되고 나면, 필요한 접속 데이터가 교환되고, 그 다음, 2807에서, 사용자 A와 사용자 F 사이에, 전술된 바와 같이, 직접적인 P2P 접속이나 중계 접속(필요한 경우)이 설정된다.
도 11 및 도 12에 관하여 전술된 바와 같이, 본 발명의 일부 실시예에서, 2명(또는 그 이상의) 사용자들 사이에 P2P 접속을 설정하는데 이용되는 다양한 서버들은 접속 프로세스 동안에 어떠한 접속 상태 정보도 유지할 필요가 없다. 이것은, 예를 들어, 초대 서비스(112)와 접속 데이터 교환 서비스(110)를 포함한다. 오히려, 이들 실시예들에서, 공개/사설 IP 및 포트(때때로 일반적으로 네트워크 정보라고 함), NAT 타입, 사용자 ID, 푸시 토큰 등을 포함하지만 이것으로 제한되지 않는 전체 접속 상태가 축적되고 각각의 연속된 사용자 트랜잭션과 함께 전송된다. 도 29에 나타낸 바와 같이, 각 트랜잭션과 함께 전송되는 다중-제공자 컨텍스트에서 한 추가적인 상태 정보는 제공자 ID 코드이다.
도 29의 구체적인 세부사항으로 돌아가면, 사용자 A는, 그 자신의 네트워크 ID(ID-A), 전술된 기술들을 이용하여 결정된 그 자신의 네트워크 정보(예를 들어, 공개/사설 IP/포트 데이터, NAT 타입 등), 그 자신의 푸시 토큰(토큰-A), 및 사용자 F의 ID 코드, 전화 번호 및/또는 기타 유형의 식별자를 포함하는 개시 요청(2901)(여기서는 때때로 "초대" 요청이라 함)을 전송한다. 개시 요청은 처음에, (예를 들어, 소정의 서비스 제공자들을 배제하기 위해 블룸 필터를 이용하여) 사용자 F의 서비스 제공자를 위치파악하기 위해 도 25 내지 도 28에 관하여 전술된 임의의 기술을 구현할 수 있는 사용자 A의 서비스 제공자에 의해 수신된다. (사용자 A와 사용자 F의 서비스 제공자들은 간소화를 위해 도 29에 도시되어 있지 않다.)
한 실시예에서, 일단 사용자 F의 서비스 제공자가 식별되고 나면, 사용자 A의 서비스 제공자 ― 이 예에서는 "제공자 A"에 대한 식별자를 포함하는 개시 푸시 동작(2902)이 사용자 F의 서비스 제공자로부터 사용자 F에 전송된다. 제공자 A에 대한 식별자는 N-비트(예를 들어, 16-비트, 32-비트, 64-비트 등) 식별 코드와 같이 단순할 수 있다. 대안으로서, 제공자 A에 대한 식별자는 제공자 A의 네트워크 게이트웨이를 식별하는 공개 IP 주소나 제공자 D에 접속하는데 필요한 기타의 네트워킹 데이터를 포함할 수 있다. 본 발명의 기저 원리는 P2P 접속 트랜잭션의 시퀀스에서 제공자 A를 식별하는데 이용되는 포맷에 관계없이 동일하게 유지된다.
한 실시예에서, 푸시 트랜잭션(2902)은 전술된 푸시 통보 서비스(1050)(예를 들어, 도 11 및 관련 본문 참조)와 같은 푸시 통보 서비스에 의해 생성된다. 언급한 바와 같이, 사용자 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에 대한 접속 상태 정보 모두는 사용자 F의 서비스 제공자(이 예에서는 "제공자 D")에 의해 수신되고, 사용자 F의 서비스 제공자는 그 자신의 제공자 ID 코드를 트랜잭션에 부착하고(제공자-D) 이것을 사용자 A의 서비스 제공자에게 포워딩한다. 제공자 A에 대해 전술된 바와 같이, 제공자 D에 대한 식별자는 N-비트 식별 코드와 같이 단순할 수 있다. 대안으로서, 제공자 D에 대한 식별자는 제공자 D의 네트워크 게이트웨이를 식별하는 공개 IP 주소나 제공자 D에 접속하는데 요구되는 기타의 네트워킹 데이터를 포함할 수 있다. 본 발명의 기저 원리는 P2P 접속 트랜잭션의 시퀀스 내에서 제공자 D를 식별하는데 이용되는 포맷에 관계없이 동일하게 유지된다.
일단 (제공자-D 데이터를 포함한) 접속 상태 데이터 모두가 사용자 A에 의해 수신되고 나면, 사용자 A와 사용자 F는, 트랜잭션(2905)로 표시된 바와 같이, 전술된 기술을 이용하여 P2P 접속을 설정할 수 있다.
전술된 바와 같이, 소정 조건 하에서, 사용자 A와 사용자 F는 직접적인 P2P 접속 대신에 중계 서비스(1051)(예를 들어, 도 10 참조)를 통해 접속을 설정할 필요가 있을 수 있다. 도 30에 나타낸 바와 같이, 한 실시예에서, 서비스 제공자 A와 F 양쪽 모두는 그들 자신의 중계 서비스(3001-3002)를 이용할(및/또는 제3자 중계 서비스와 관계를 가질) 수 있다. 한 실시예에서, 사용자 A와 사용자 F 사이에 시도된 P2P 접속이 실패한다면, 서비스 제공자 A의 중계 서비스(3001)(즉, P2P 접속을 개시하는 사용자의 제공자)가 접속을 지원하는데 이용된다. 대안적 실시예에서, 사용자 F의 중계 서비스(3002)(즉, 접속을 요청받은 사용자의 제공자)가 (도 31에서 사용자 A(2501), 중계 서비스(3002), 및 사용자 F(2506) 사이에 점선으로 표시된 바와 같이) 접속을 제공하는데 이용된다. 또 다른 실시예에서, 제공자들 모두가 하나의 중계 서비스에 동의하고 사용자들 사이에 P2P 접속을 설정하기 위해 그 중계 서비스를 이용한다.
본 발명의 한 실시예는 사용자 장치들 사이의 보안 오디오/비디오 P2P 통신을 지원하기 위해 다양한 상이한 통신 프로토콜을 결합한다. 이들 프로토콜들은, P2P 접속을 통해 보안 통신을 제공하는 DTLS(Datagram Transport Layer Security) 프로토콜; 암호화, 메시지 인증 및 무결성, 및 유니캐스트(장치 대 장치)와 멀티캐스트(장치 대 복수의 장치) 애플리케이션 모두에 대한 RTP 데이터에 대한 중계 보호를 제공하도록 의도된 RTP(Real-time Transport Protocol; 실시간 트랜스포트 프로토콜)의 프로파일을 정의하는 보안 실시간 트랜스포트 프로토콜(또는 SRTP); 및 사용자 장치들 사이에 음성/비디오 접속을 설정하는 세션 개시 프로토콜(Session Initiation Protocol; SIP)을 포함한다(그러나 이것으로 제한되지 않는다). 이들 프로토콜들은 본 명세서에 설명된 본 발명의 임의의 실시예의 콘텍스트에서 채용될 수 있다.
한 실시예에서, 도 25에 나타낸 개방된 제공자간 네트워크 상의 각 장치는 신원 확인과 STRP를 이용한 스트림의 단-대-단 암호화의 목적을 위해 다른 장치들에게 안전하게 식별가능할 것이다. 보안 통신을 가능케하기 위해 서비스 제공자들 각각에 의해 발행될 것이 요구되는 인증서 포맷이 이하에서 설명된다.
한 실시예에서, 각 제공자는 다른 피어 제공자들을 발견하는 방법을 알 필요가 있을 것이다. 한 실시예에서, 호출 라우팅(call routing) 및 피어 정보를 질의하기 위한 공급자들의 전역적 보안된 목록이 있다. 이것은 신뢰받는 서버들의 목록과 그들의 어드레싱 정보이다. 제공자들 중 하나는 이 서비스를 호스팅할 수 있다.
제공자들 사이의 접속을 유효성확인하고 신뢰하기 위해 제공자들 사이에 필요한 보안 및 인증 레벨이 이하에서 설명된다. 이것은 P2P 접속을 인증하는데 이용되는 것들 뿐만 아니라 제공자와 전역 룩업 데이터베이스 사이에서 이용되는 것들과는 상이한 자격증(credentials) 세트일 수 있다.
한 실시예에서, 호출 라우팅시에, 수신자의 제공자(즉, 호출되고 있는 사용자)는 종점들 사이의 P2P 접속 인증에 이용하기 위해 호출자에게 반환되는 피어 인증서를 제공한다. 이 인증서는 외부 엔티티에 의해 서명될 수도 있고 인증서 요건은 단지 전자메일 뿐만 아니라 임의 타입의 신원을 허용할 수 있다.
또한, 한 실시예에서, 오디오, 비디오 및 시그널링 데이터가 하나의 데이터 포트를 통해 각각의 데이터 처리 장치 상에서 함께 멀티플렉싱된다. 오디오, 비디오, 및 시그널링 데이터는 그 다음, 목적지 장치에서 디멀티플렉싱되고 디코딩된다.
도 25에 나타낸 제공자간 네트워크는 복수의 상호연동 층(interoperating layer)들로 구성된다. 이들 층들의 상호작용은 다양한 프로토콜에 의해 명시될 수 있다. 이 상호작용의 목적은 접속을 설정하기 위한 사용자 요청을 처리하는 것으로서, (도 25에서 사용자 A-F(2501-2506)로 식별되는) 사용자 종점들 사이에서 정보의 필요한 교환을 수행하여, 그들이 오디오/비디오 호출 세션을 설정할 수 있게 한다.
동작시에, 도 25에 나타낸 제공자간 네트워크는, 요청을 개시하고 응답하는, 서로 통신하는 한 세트의 서버로서 구현된다. 이들 요청은, 요청을 포워딩하여 사용자 종점들이 매체 채널 접속 데이터를 교환하고 오디오/비디오-호출 세션을 형성할 수 있게 하는데 필요한 프로토콜 동작이다. 한 실시예에서, 각 서비스 제공자는 그 사용자 종점들과의 모든 직접적인 통신을 관리한다.
한 실시예에서, 사용자 종점들은 종점을 제어하는 측을 식별하는 URI(Uniform Resource Identifier)를 통해 표현된다. 초기 지원된 URI 방식들은 (전화 번호의 경우) tel: 이고, (전자메일 주소의 경우) mailto: 이다. 다른 URI 방식들도 미래에 지원될 수 있다.
한 실시예에서, 각 사용자 종점으로의 URI의 맵핑은 신원 맵핑이 아니다; 이것은 다-대-다 관계이다. 단일 URI는 복수의 종점들에 맵핑될 수 있고, 단일 종점은 복수의 URI에 의해 맵핑될 수 있다. 또한, URI 대 종점 맵핑은 복수의 제공자들에 걸칠 수도 있다. 예를 들어, 제공자 A 상에 하나의 종점이 있고, 제공자 B 상에 상이한 종점이 있고, 이들 종점들 양쪽 모두는 동일한 URI에 의해 맵핑될 수 있다. (그러나, 한 실시예에서, 종점들은 한번에 하나의 제공자에 의해서만 호스팅될 수 있다.) 한 실시예에서, 종점 URI들은 전화 번호 및 전자메일 주소와 같은 일반적인 사용자-레벨 식별자들이다. 제공자들 및 종점들로의 이들의 맵핑은 시스템에 의해 수행되고, 엔드 유저에게는 투명하다.
한 실시예에서, 도 25에 나타낸 제공자간 통신에 이용되는 메타 프로토콜은 HTTP를 통한 사전이다. 이 실시예에서, 모든 동작들은 HTTP GET 또는 POST 중 어느 하나로서 수행된다. 동작이 HTTP GET으로서 명시된다면, 몸체부는 비어(empty) 있을 것이다. 동작이 HTTP POST로서 명시된다면, 몸체부는 사전으로서 인코딩된 요청 파라미터들을 포함할 것이다. 응답들은 사전으로서 인코딩된 응답 파라미터들을 포함하는 몸체부를 가질 것이다. 한 실시예에서, 사전의 초기 인코딩은 Apple XML Property Lists이다. JSON 또는 Protocol Buffer와 같은 다른 인코딩들도 이용될 수 있다. 한 실시예에서, 상이한 서비스 제공자들은 개개 사용자 장치와 통신하기 위해 임의 세트의 프로토콜 또는 통신 메커니즘을 이용할 수 있다.
한 실시예에서, 도 25에 도시된 서비스 제공자들이 서로를 발견하는 것을 허용하기 위해 제공자 발견 프로토콜(provider discovery protocol)이 채용된다. 한 실시예에서, 네트워크의 관리 엔티티(예를 들어, 1차 또는 관리 서비스 제공자)에 의해 부트스트랩 URI가 게시된다. 이 부트스트랩 URI는 이 네트워크의 수락된 멤버들인 제공자 세트를 포함하는 발견 사전(discovery dictionary)을 가리킨다. 각 서비스 제공자에 대해, 이 사전은 식별 정보 뿐만 아니라, 이 제공자와 통신하기 위한 방법을 명시하는 추가의 URI들을 포함한다. 한 실시예에서, 서비스 제공자들이 시작(start up)되면, 그 후 주기적으로, 이들은 발견 사전을 검색한다. 그 다음, 이들은 사전 내의 정보에 기초하여 다른 제공자들과 통신하도록 스스로를 구성한다.
사용자들 사이에 P2P 통신 세션을 설정하기 위한 한 특성 세트의 프로토콜에 대한 세부사항이 이제 설명될 것이다. 그러나, 이들 구체적인 세부사항은 단지 특정한 실시예를 나타내는 것일 뿐이지 본 발명의 기저 원리와 호환되는데 요구되는 것은 아니라는 점에 유의해야 한다.
1. 초대 프로토콜
한 실시예의 초대 프로토콜은 초기 호출 셋업에 이용된다. 이것은, 비디오-호출 세션을 위해 매체 채널을 확립하는데 이용되는 매체 채널 접속 데이터를 교환하기 위해 사용자 종점들(예를 들어, 도 25에서 사용자 종점(2501-2506))에 의해 이용되는 대역외 시그널링이다.
1.1. 동작
초대 프로토콜에서 4개의 주요 동작들이 있다.
1.1.1. 개시
호출을 시작하기 위해 개시측 종점에 의해 전송됨. 필드들: 세션-id, 자체-uri, 자체-토큰, 자체-블롭(self-blob), 피어-uri.
1.1.2. 수락
호출에 참여하고자 한다는 것을 나타내기 위해 수신측 종점에 의해 전송됨.
필드들: 세션-id, 자체-uri, 자체-토큰, 자체-블롭, 피어-uri, 피어-토큰, 피어-블롭.
1.1.3. 거부
호출에 참여하지 않고자 한다는 것을 나타내기 위해 수신측 종점에 의해 전송됨. 필드들: 세션-id, 자체-uri, 자체-토큰, 자체-블롭, 피어-uri, 피어-토큰, 피어-블롭.
1.1.4. 취소
호출이 종료되어야 한다는 것을 나타내기 위해 어느 하나의 종점에 의해 전송됨. 필드들: 세션-id, 자체-uri, 자체-토큰, 자체-블롭, 피어-uri, 피어-토큰, 피어-블롭.
1.2. 동작 변형들
동작을 서비스하는 측에 따라, 이들은 3가지 형태를 취할 수 있다:
* 요청(종점으로부터 제공자로)
* 포워드(제공자로부터 제공자로)
*푸시(제공자로부터 종점으로)
1.3. 호출 흐름
1.3.1. 사용자 엔트리
한 종점이 접속을 설정하기를 원할 때, 그 종점은 수신측 종점을 식별할 URI를 필요로 한다. 이 URI는 대개 사용자에 의해 제공된 일부 정보, 예를 들어, 다이얼링된 전화 번호, 또는 주소록에 저장된 전자메일 주소로부터 유도되기 쉽다. 그 다음, 종점은 그 호스팅 제공자에게 개시 요청을 요구한다.
1.3.2. 개시 요청(Initiate Request)
개시측 제공자는 URI를 검토하고 이 URI에 의해 맵핑되는 종점들을 호스팅하는 수신측 제공자 세트를 결정한다. (이 제공자 세트는 개시측 제공자 그 자체를 포함할 수 있다.) 그 다음, 모든 적용가능한 수신측 제공자들에게 개시 포워드를 요구한다.
1.3.3. 개시 포워드(Initiate Forward)
각각의 수신측 제공자는 수신측 종점을 결정하고, 수신측 종점에 개시 푸시(Initiate Push)를 전송한다.
1.3.4. 개시 푸시(Initiate Push)
수신측 종점은 개시 푸시를 얻고, 그 정보를 사용자에게 보여준다. (이것은 통상 "XXX가 호출중이다"라는 라인들을 따른 UI일 것이다.) 사용자가 그 호출을 받을 것이라고 결정하면, 종점은 수락 요청(Accept Request)을 요구할 것이다. (그렇지 않다면, 종점은 거부 요청(Reject Request)을 요구할 것이다.)
1.3.5. 수락 요청
수신측 종점은 그 호스팅 제공자에게 요청 수락을 요구한다.
1.3.6. 수락 포워드
수신측 제공자는 수락 푸시를 개시측 종점에 전송한다.
1.3.7. 수락 푸시
개시측 종점은 수락 푸시를 얻고, 접속 형성을 진행할 수 있다는 것을 사용자에게 표시한다. 이 시점에서, 양쪽 종점은 매체 채널 접속 데이터를 교환했기 때문에, 그들은 오디오/비디오-호출 세션을 위한 매체 채널을 설정할 준비가 되어 있다. 여기서부터, 플로우는, (이하의) 매체 세션 관리에서 기록된 바와 같이, 매체 채널 설정을 계속한다.
2. 송달 최적화 프로토콜
위에서 상세히 논의된 바와 같이, 한 실시예에서, 블룸 필터들은 개시 호출 요청에 응답할 수 있는 후보 서비스 제공자들을 선택하는데 이용된다. 한 실시예에서, 제공자들은 그들이 현재 호스팅하고 있는 종점들의 모든 URI들을 나타내는 최신 블룸 필터를 유지할 것이 요구된다. 모든 제공자들에 대한 블룸 필터들은 점증적 방식으로 다른 모든 제공자들에게 배포될 수 있다.
송달 최적화 프로토콜. 시작된 호출을 송달할 때, 제공자들은 먼저 다른 모든 제공자들의 블룸 필터를 조회한다. 이로부터, 이들은 그 호출을 실제로 서비스할 수 있는 제공자들의 후보 세트를 얻을 것이다. 그 다음 개시 동작이 이 후보 목록에만 전송된다.
3. 매체 세션 관리
매체 세션 관리란, 매체 채널과 매체 채널을 통해 운반되는 매체 스트림들의 셋업, 제어, 및 해체를 말한다. 매체 세션 관리를 이하의 섹션들에서 상세히 논한다.
4. 매체 채널 설정
매체 시그널링, 매체 흐름, 세션 해체를 위한 네트워크 패킷들은 매체 채널을 통해 전송된다. 매체 채널은 (상기에서 상세히 설명된 바와 같이) NAT 횡단이나 중계 구성을 통해 설정된다. NAT 횡단과 중계 구성 양쪽 모두는, 각 종점이 양쪽 종점들에 대한 매체 채널 접속 데이터를 소유할 것을 요구한다.
4.1. NAT 횡단 프로토콜
한 실시예에서, NAT 횡단 프로토콜은 직접적인 피어-투-피어 접속을 통해 매체 채널을 설정하는데 이용된다. 이것은 대화형 접속 확립(ICE; Interactive Connectivity Establishment) [RFC 5245]에서 다루는 기술들의 사용을 포함한다.
4.2. 중계 구성 프로토콜
한 실시예에서, 중계 프로토콜은 중계 네트워크를 통해 매체 채널을 설정하는데 이용된다. 한 실시예에서, 이것은 TURN [RFC 5761]의 사용을 포함한다.
5. 매체 채널 시그널링
매체 시그널링은 매체 협상 및 매체 암호화를 위한 보안의 셋업과, 오디오 및 비디오 파라미터들에 대한 매체 협상을 다룬다.
5.1. 보안 셋업
언급된 바와 같이, 한 실시예에서, DTLS(Datagram Transport Layer Security) [RFC 4347]는 매체 채널을 통한 네트워크 트래픽의 전달을 보안유지하는데 이용된다. DTLS 프로토콜은, 서비스 제공자가 사용자들 사이에 전송되는 음성/비디오 패킷들 내의 암호화된 콘텐츠에 액세스할 수 없도록 단-대-단 암호화를 제공하도록 구현될 수 있다.
5.2. 매체 협상
한 실시예에서, SIP [RFC 3261]는 비디오 호출 세션의 오디오 및 비디오 파라미터들을 협상하는데 이용된다.
5.3. 오디오 및 비디오 암호화
한 실시예에서, SRTP [RFC 3711]는 오디오 및 비디오 페이로드를 암호화하는데 이용된다.
6. 매체 흐름 제어
매체 흐름 제어는 활성 매체 스트림의 관리, 및 매체 채널을 통한 매체 상태 변경의 통보를 다룬다.
6.1. 네트워크 적합화
한 실시예에서, 통신 채널 등락(fluctuation)을 감안하기 위해 네트워크 적합화 기술들이 구현된다. 특히, 사용자 종점은, 처리량, 패킷 손실, 및 레이턴시에서의 변화와 같은 다양한 네트워크 상태에 적응하기 위하여 오디오 및/또는 비디오 비트레이트와 같은 스트림 파라미터들을 조절할 수 있다.
6.2 비디오 뮤팅(video muting)
비디오를 전송하는 종점은 비디오를 뮤트(mute)/언뮤트(unmute)할 수 있다. SIP MESSAGE를 이용하여 원격 종점에 통보가 전송된다.
6.3 비디오 방향(Video Orientation)
비디오를 전송하는 종점은 비디오의 방향(orientation of the video)을 변경할 수 있다. RTP 헤더 확장 정보를 이용하여 원격 종점에 통보가 전송된다.
6.4 비디오 스위칭
비디오를 전송하는 종점은 비디오의 소스를 스위칭할 수 있다. 예를 들어, 전향(front-facing) 및 배향(back-facing) 카메라 양쪽 모두를 포함하는 사용자 장치 상에서, 비디오는 전향으로부터 배향으로 스위칭할 수 있다. RTP 헤더 확장 정보를 이용하여 원격 종점에 통보가 전송될 수 있다.
6.5. 끊기(Hangup)
한 실시예에서, 종점은 SIP BYE 메시지를 전송함으로써 활성 세션을 명시적으로 종료할 수 있다.
7. 매체 채널 해체
매체 세션은 명시적으로 또는 묵시적으로 해체될 수 있다. 매체 채널의 명시적 해체는 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 Enhanced Low Delay AAC (AAC-ELD, ISO/IEC 14496-3)와 호환될 수 있다.
9.1.2. 오디오 품질
한 실시예에서, 오디오 신호 음향 특성은 광대역(Wideband) 전화 단말기에 대한 3GPP 명세, TS 26.131 및 TS 26.132에 의해 명시된다.
9.1.2.오디오 RTP 페이로드 포맷
9.2 비디오
한 실시예에서, 시퀀스 파라미터 세트(SPS) 및 화상 파라미터 세트(PPS) NALU들은 비트스트림에서 비디오 스트림 디스크립션을 운반하는데 이용된다.
9.2.1. 비디오 코덱
한 실시예에서, 도 25의 사용자들간 통신에 이용되는 비디오 코덱은 b-프레임 없는 H.264 High Profile, Level 1.2 (실질적으로, QVGA 15 fps, 최대 300kbps)이다. 그러나, 본 발명의 기저 원리는 임의의 특정한 오디오/비디오 포맷으로 제한되지 않는다는 점에 유의해야 한다.
9.2.2. 비디오 RTP 페이로드 포맷
언급된 바와 같이, RTP(Realtime Transport Protocol)는 사용자 종점들 사이에서 오디오/비디오 통신을 지원하는데 이용될 수 있다. 도 32에 나타낸 바와 같이, 한 실시예에서, RFC 3984 헤더(3202)(즉, H.264 비디오에 대한 RFC 3984 RTP 페이로드 포맷에 의해 정의됨)가 각각의 (RTP 데이터 패킷을 포함하는) 12 바이트 RTP 페이로드(3201)에 부가된다. 헤더는 H.264 영상 디스크립션 확장을 이용하여 RTP 데이터가 패킷화되는 방법을 명시한다.
보안 인스턴트 메시징을 위한 시스템 및 방법
본 발명의 한 실시예는, 인스턴트 메시징 및 화상 채팅과 같은 애플리케이션에 대해 모바일 장치들 사이의 보안 피어-투-피어 세션을 가능케하는 아키텍쳐를 제공한다. 도 33에 나타낸 바와 같이, 본 발명의 이 실시예는 사용자 인증을 위한 신원 서비스(3302), (전술된 바와 같은) 모바일 장치에 통보를 푸시하기 위한 푸시 통보 서비스(1050), 및 2명 이상의 모바일 사용자들(도 33에는 사용자 A(110) 및 B(111)가 도시되어 있다) 사이에서 보안 인스턴트 메시징 세션을 설정하기 위한 보안 인스턴트 메시징 서비스(3302)를 포함한다. 한 실시예에서, 신원 서비스(3301)는, 모바일 장치들에 푸시 통보를 전송하기 위해 본 명세서에 설명된 바와 같이 통보 서비스(1050)에 의해 이용될 수 있는, 활성 사용자 ID들, 인증 키들, 및 푸시 토큰들의 사용자 등록 디렉토리(3302)를 관리한다. 한 실시예에서, 사용자 ID는 전자메일 주소이지만, 본 발명의 기저 원리는 임의의 특정 타입의 사용자 ID로 제한되지 않는다. 게다가, 하나의 사용자는 상이한 애플리케이션들(예를 들어, 인스턴트 메시징, 화상 채팅, 파일 공유 등)에 대해 복수의 사용자 ID를 가질 수 있고, 상이한 모바일 장치들(예를 들어, iPhoneTM 및 별개의 iPadTM - 본 특허 출원의 양수인에 의해 설계된 장치들임)을 가질 수 있다.
보안 피어-투-피어 통신 채널을 설정하기 위한 컴퓨터-구현된 방법의 한 실시예가 도 34에 나타나 있다. 이 방법은 처음에 도 33에 도시된 아키텍쳐의 콘텍스트 내에서 설명될 것이지만, 본 발명의 기저 원리는 이 특정한 아키텍쳐로 제한되지 않는다는 점에 유의해야 한다.
3401에서, 사용자 A는 사용자 B의 식별자(예를 들어, 사용자 B의 전자메일 주소 및/또는 전화 번호)를 포함한 질의를 신원 서비스(3301)에 전송하여 사용자 B와의 보안 통신 채널을 개시한다. 응답하여, 신원 서비스(3301)는 3402에서 임의의 사용자 ID가 그 질의와 매치하는지를 판정한다(예를 들어, 사용자 B의 전자메일 주소 또는 전화 번호가 신원 서비스 내에 등록되어 있는지를 판정). 매치하지 않는다면, 3403에서, 신원 서비스는 실패 통보를 사용자 A에게 전송한다.
매치가 발견되면, 3404에서 사용자 A는 신원 서비스(3301)로부터 사용자 B의 네트워크 주소 정보 및 공개 키를 검색한다. 한 실시예에서, 주소 정보는 사용자 B의 컴퓨팅 장치에 대한 토큰을 포함함으로써, 사용자 A를 인증하여 이 특정 주소를 갖는 사용자 B에게 토킹(talk)할 수 있다(장치 A의 토큰은 B의 토큰에게 토킹할 수 있다). 사용자 B가 복수의 장치를 갖는다면, 신원 서비스(3301)로부터 복수의 토큰(각 장치당 하나)이 제공되어 사용자 A에게 별개로 라우팅될 수 있다.
한 실시예에서, 신원 서비스(3301)에 의해 제공되는 현재 시간의 타임스탬프, 사용자 A의 ID, 사용자 B의 ID, 사용자 A의 토큰, 및 사용자 B의 토큰에 관한 서명인 세션 키(때때로 본 명세서에서는 "질의 서명"이라고 함)도 생성된다. 이 세션 키는 후속해서 보안 IM 서비스(3302)에 의해 이용되어 (후술되는 바와 같이) 신원 서비스의 관여없이 2명의 사용자를 인증한다.
사용자 A는 이제 이들 주소 유닛들(타겟 ID/토큰) 각각에 대한 어드레싱 정보와 공개 키를 가진다. 3404에서, 장치 A는 사용자 B에 전송될 메시지와 첨부물을 사용자 A의 개인 키와 장치 B의 공개 키로 암호화한다. 한 실시예에서, 이것은 텍스트/첨부물의 내용을 사용자 B의 키로 암호화하고 그 내용을 사용자 A의 키로 서명하는 단계를 포함할 수 있다. 일단 암호화되고 나면, 메시지는 사용자 A와 사용자 B 사이에 위치한 임의의 서버에서 암호해독될 수 없지만, 서버들은 전송되는 메시지의 타입(예를 들어, 텍스트 메시지인지 수신 확인인지)을 알 수 있다. 사용자 B의 공개 키를 이용한 암호화의 결과, 사용자 B만이 메시지 내용을 읽을 수 있다. 사용자 B는 사용자 A의 서명을 이용하여 전송자(사용자 A)도 확인할 수 있다.
3406에서, 사용자 A는 DTLS(datagram transport layer security)를 이용하여 푸시 통보 서비스(1050)와의 보안 통신 채널을 개방하고, 암호화된 메시지를 사용자 B의 토큰, 사용자 ID, 및 사용자 A의 사용자 ID와 함께 푸시 통보 서비스(1050)에 전송한다. 당업자라면 아는 바와 같이, DTLS 프로토콜은 통신 프라이버시를 제공하여, 데이터그램-기반 애플리케이션들이, 도청, 무단변조 또는 메시지 위조를 방지하도록 설계되는 방식으로 통신하는 것을 허용한다. DTLS 프로토콜과 연관된 구체적인 세부사항은 공지되어 있으므로 여기서는 상세히 설명되지 않을 것이다.
일부 실시예에서, 사용자 A의 토큰은 이 단계에서 푸시 통보 서비스(1050)에 전송되지 않지만, 푸시 통보 서비스(1050)와의 사용자 A의 통신에 기초하여 유추된다. 3407에서, 푸시 통보 서비스(1050)는 보안 인스턴트 메시징 서비스(3302)와의 보안 통신 채널을 개방하고, 요청시에, 보안 인스턴트 메시징 서비스에 사용자 A의 푸시 토큰을 제공한다. 따라서, 이 단계에서, 보안 인스턴트 메시징 서비스(3302)는 사용자 B의 토큰 및 ID와 사용자 A의 토큰 및 ID를 가진다. 한 실시예에서, 이것은, 예를 들어, 사용자 B의 토큰 및 ID와 사용자 A의 토큰 및 ID와 타임스탬프로 세션 키를 재생성하고, 생성된 세션 키를 푸시 통보 서비스(1050)로부터 수신된 것과 비교함으로써, 앞서 언급된 세션 키를 이용하여 이 정보를 확인한다. 한 실시예에서, 현재의 타임스탬프가 원래의 타임스탬프보다 훨씬 앞에 있다면, 서명은 매치하지 않을 것이고, 확인 실패가 발생할 것이다. 서명이 매치된다면(즉, 메시지가 양호하게 서명되어 있다면), 3409에서, 보안 인스턴트 메시징 서비스(3302)는 푸시 통보 서비스(1050)와의 제2의 송출 보안 통신 채널을 개방하며, 사용자 A의 푸시 토큰을 (사용자 B의 푸시 토큰 및 ID와 함께) 메시지에 추가하고, 이 메시지를 사용자 B로의 전달을 위해 푸시 통보 서비스(1050)에 전송한다. 유의미하게, 이 단계에서, 보안 IM 서비스(3302)는 확인 목적을 위해 신원 서비스(3301)에 질의할 필요가 없어서, 네트워크 대역폭을 보존한다.
3410에서, 푸시 통보 서비스는 트랜스포트 층 보안(TLS; transport layer security)을 이용하여 사용자 B와의 보안 통신 채널을 개방하고, 사용자 B에 메시지를 푸시한다. 3411에서, 사용자 B는 메시지를 확인하고 암호해독하기 위해 사용자 A에 대해 전술된 것과 동일한 확인 동작을 수행한다. 특히, 사용자 B는 신원 서비스(3301)에 질의하여 사용자 A의 공개 키를 검색한 다음 그 공개 키를 이용하여 (사용자 A의 개인 키를 이용하여 이전에 서명되었고 사용자 B의 공개 키로 암호화된) 메시지를 확인할 수 있다. 이 단계에서, 사용자 A와 B는 3410에서 보안 IM 세션을 설정하는데 필요한 정보 모두(예를 들어, 공개 키 및 토큰)를 가진다.
도 35에 나타낸 한 실시예에서, 전술된 기술 대신에, 또는 이에 추가하여 OTR(Off-the-Record Messaging) 협상이 이용될 수 있다. 당업자라면 아는 바와 같이, OTR은, AES 대칭키 알고리즘, Diffie-Hellman 키 교환, 및 SHA-1 해쉬 함수의 조합을 이용하는 인스턴트 메시징 대화에 강력한 암호화를 제공하는 암호 프로토콜이다. 한 실시예에서, 전술된 보안 메시징 기술들이 시도되고, 성공적이지 않으면, 도 35에 나타낸 OTR 기술이 채용된다.
3501에서, 사용자 A는 사용자 B의 ID(예를 들어, 전자메일 주소, 전화 번호 등)를 이용하여 신원 서비스에 질의하고, 신원 서비스로부터 사용자 B의 공개 키를 검색한다. 3502에서, 사용자 A는 사용자 B의 공개 키를 이용하여 암호화함으로써 보안 OTR 세션 요청을 생성하고, 그 요청을 사용자 B에 전송한다. 3503에서, 사용자 B는 사용자 B의 개인 키를 이용하여 암호해독하고, 세션 요청에 응답하여, 사용자 B는 사용자 A의 공개 키를 검색한다.
3504에서, 사용자 B는 OTR 응답을 생성하고, 그 응답을 사용자 A의 공개 키로 암호화한다. 3505에서, 사용자 A와 B는 추가의 OTR 접속 메시지를 교환한다. 이 단계에서 교환되는 구체적인 메시지들은 현재의 OTR 명세에 의해 정의될 수 있으므로 여기서는 상세히 설명되지 않는다. 3506에서, 일단 모든 필요한 접속 데이터가 교환되고 나면, 사용자 A와 B는 서로와의 보안 인스턴트 메시징 통신 채널을 개방한다.
전술된 실시예들은 인스턴트 메시징 구현에 초점을 맞추고 있지만, 본 발명의 기저 원리는 피어-투-피어 오디오 및/또는 비디오 서비스와 같은 다른 타입의 피어-투-피어 통신 서비스에 구현될 수 있다.
모바일 사용자들을 접속하기 위한 신원 서비스의 실시예
앞서 언급한 바와 같이, 한 실시예에서, 신원 서비스(3301)는 활성 사용자 ID, 인증 키 및 푸시 토큰들의 사용자 등록 디렉토리(3302)를 관리한다. 신원 서비스(3301)는, 인간이-사용가능한 입력에 기초하여 모바일 장치와 사용자들에게 효율적인 식별 정보를 제공하기 위해 푸시 통보 서비스(1050) 및 인스턴트 메시징 서비스(3302)와 같은 다른 서비스들에 의해 이용된다. 특히, 한 실시예에서, 신원 서비스는 편리한 사용자-판독가능한 사용자 ID 코드들(예를 들어, 전화 번호, 전자메일 주소, 게임 센터 별명 등)을 상세한 사용자/장치 정보에 맵핑하는 테이블을 갖는 공유된 사용자 등록 데이터베이스(3302)를 포함한다.
한 실시예에서, 하나의 사용자 ID는 사용자 등록 디렉토리(3302) 내에서 복수의 물리적 장치에 맵핑될 수 있다. 예를 들어, ID tom@bstz.com을 갖는 사용자는, iPhoneTM 및 별개의 iPadTM(본 특허 출원의 양수인에 의해 설계된 장치들임) 및 별개의 노트북/데스크탑 개인용 컴퓨터와 같은 복수의 모바일 장치를 가질 수 있다. 필요한 인증 자격증(authentication credential)을 갖는 임의의 사용자 또는 서비스는 신원 서비스에 질의하여 다른 사용자들에 대한 정보를 검색할 수 있다. 전술된 특정한 장치들은 설명의 목적을 위해 이용되지만, 본 발명의 기저 원리는 임의의 특정한 장치 타입으로 제한되지 않는다.
한 실시예에서, 각 장치에 대해 유지되는 장치 정보는 (1) (전술된 바와 같이 장치에 대한 네트워크 어드레싱 정보를 포함하는) 장치에 대한 푸시 토큰과 (2) 한 세트의 장치 능력을 포함한다. 이 능력은, 장치에 대한 서비스 제공자의 신원(예를 들어, AT&T 대 Verizon), 장치 버전 정보(예를 들어, 소프트웨어 OS 버전 및/또는 애플리케이션 버전), 및 (예를 들어, 장치에 설치된 애플리케이션 프로그램 코드에 기초한) 장치에 의해 지원되는 하나 이상의 프로토콜을 포함함 수 있다. 예를 들어, 장치에 FacetimeTM 애플리케이션이 설치되었다면, 이 정보는 장치 정보와 함께 신원 서비스에 의해 저장될 것이다. 추가로, 장치 정보는, (예를 들어, 전술된 보안 인스턴트 메시징 서비스와 같은) 각 사용자 장치가 통신할 수 있는 서비스의 타입을 명시할 수 있다.
따라서, 사용자 B의 장치 정보를 검색하기 위한 질의에 응답하여, 사용자 A는 사용자 B의 장치들 각각에 대한 상기 장치 정보를 포함하는 응답을 신원 서비스(3301)로부터 수신할 수 있다. 이것은 사용자 A의 장치가 사용자 B와 통신할 수 있는 상이한 방식들을 사용자 A의 장치에게 효과적으로 통보할 것이다. 예를 들어, 사용자 A가 사용자 B와 동일한 통신 애플리케션들 중 일부(예를 들어, 동일한 인스턴트 메시징 클라이언트, Facetime 애플리케이션, 파일 공유 애플리케이션 등)를, 설치된 정확한 버전과 함께, 가진다면, 사용자 A의 장치는 사용자 B와의 통신 채널 개방을 시도하기 위해 이 정보를 이용할 수 있다.
한 실시예에서, 장치 정보는 또한 각 애플리케이션에 대한 구체적인 애플리케이션 능력을 식별하는 한 세트의 플래그(flag)를 포함한다. 상기 Facetime 예로 되돌아가면, 장치 정보는 사용자 B의 장치가 3G 네트워크를 통해 Facetime 채널을 지원한다는 것을 명시할 수 있다. 이러한 경우에, 사용자 A의 장치는 사용자 B의 장치에 의해 지원되는 특정한 프로토콜을 이용하여 3G 네트워크를 통해 사용자 B의 장치와의 통신 채널 개방을 시도할 수 있다. 물론, 상기 내용은 단순히 예시일 뿐이다. 본 발명의 기저 원리는 임의의 특정 세트의 애플리케이션 능력 또는 프로토콜로 제한되지 않는다.
도 36에 나타낸 본 발명의 한 실시예에서, 장치가 신원 서비스와 상호작용하기 위해 수행할 수 있는 4개의 동작이 있다: (1) 인증; (2) 등록; (3) 정규화(canonicalize); 및 (4) 질의.
(1) 인증
본 명세서에서 사용되는 "인증"이란 특정한 사용자 식별자(ID)의 신원을 증명하는 것을 말한다. 한 실시예에서, 수행되는 인증은 상이한 타입의 ID 코드들(예를 들어, 전자메일 주소, 서비스 별명, 사용자 ID 코드, 전화 번호 등)에 대해 상이할 수 있다. 예를 들어, 전자메일 주소의 인증은 전화 번호 또는 서비스 ID 코드들의 인증과는 상이할 수 있다.
이들 동작들이 도 36에 도시된 시스템 아키텍쳐와 도 37에 개시된 방법에 관하여 기술될 것이다. 그러나, 도 37에 나타낸 방법은 본 발명의 기저 원리와 여전히 일치하면서 상이한 시스템 아키텍쳐 상에서 구현될 수 있다는 점에 유의해야 한다.
3701에서, 사용자 A는 한 세트의 애플리케이션-특유의 자격증을 애플리케이션 인증 서비스(3601)에 전송한다. 전자메일 애플리케이션의 경우, 예를 들어, 자격증은 사용자 A의 전자메일 주소와 패스워드를 포함할 수 있다; 게임 애플리케이션의 경우, 이것은 게임 서비스에 대한 사용자 ID와 패스워드를 포함할 수 있다; 전화 번호의 경우, 이것은 단문 서비스(SMS; short message service) 서명을 포함할 수 있다. 게다가, 도 36에는 별개의 서비스로서 도시되어 있지만, 애플리케이션 인증 서비스(3601) 및 신원 서비스(3301)는 단일의 통합된 서비스를 형성할 수도 있다.
응답하여, 3702에서, 애플리케이션 인증 서비스(3601)는 제공된 인증 자격증을 취하여, 이들에 서명하고, 이들을 본 명세서에는 "권한설정 인증서(provisioning certificate)"라 불리는 인증 인증서 내에 삽입하여, 그 권한설정 인증서를 사용자 A에 전송한다. 한 실시예에서, 권한설정 인증서는 암호화 넌스(nonce)(예를 들어, 타임스탬프) 및 서명을 포함한다.
권한설정 인증서 외에도, 한 실시예에서, 사용자 A에게는 사용자 A의 푸시 토큰에 관한 서명, 넌스(예를 들어, 타임스탬프), 및 사용자 A의 능력(예를 들어, 사용자 A의 장치 상에 설치된 특정한 애플리케이션)의 목록을 포함하는 3703에서 푸시 통보 서비스로부터 수신된 "푸시 인증서"가 제공된다. 한 실시예에서, 푸시 인증서는 사용자 A의 장치가 네트워크 상에 처음에 공급될 때 사용자 A의 장치에 제공된다.
(2) 등록
3704에서, 사용자 A가 그 푸시 인증서와 그 권한설정 인증서를 신원 서비스에 등록하고, 3705에서, 신원 서비스는 푸시 인증서 및 권한설정 인증서로부터 소정의 미리결정된 정보를 추출하여, 본 명세서에는 사용자 A의 "신원 인증서"라고 불리는 이들 엔티티들에 대한 그 자신의 서명을 생성하고, 이 신원 인증서는 후속해서 네트워크 상의 임의의 서비스에서 사용자 A의 신원을 확인하는데 이용될 수 있다(즉, 서비스들이 확인을 위해 신원 서비스에 개별적으로 접촉할 필요가 없음).
(3) 정규화
소정 타입의 사용자 ID들은 "소란스러운데(noisy)", 이것은 이들이 종종 다양한 상이한 포맷들을 이용하여 표현된다는 것을 의미한다. 예를 들어, 동일한 전화 번호는 408-555-1212, 1-408-555-212 또는 4085551212로서 표현될 수 있다. 상이한 포맷들을 취하는 다양한 국제 액세스 코드들과 캐리어 액세스 코드들도 존재한다. 결과적으로, 제1 사용자는 제2 사용자의 전화 번호를 알 수 있지만, 등록 데이터베이스(3302)에서 제2 사용자의 전화 번호를 찾기 위해 사용자의 소정 현재 콘텍스트(예를 들어, 사용자가 현재 어디서 로밍중인지, 전화 번호가 어떻게 포맷되어 있는지)에 도달하는데 필요한 특정한 포맷을 알지 못할 수도 있다.
등록 데이터베이스 내에 특정 사용자 ID의 상이한 변형들 각각을 저장하는 것은 비효율적일 것이다(이것은 상당한 양의 공간을 소비할 것이고 상이한 가능한 포맷들 모두를 성공적으로 포착하지 못할 수 있다). 이와 같이, 이러한 문제를 해결하기 위해, 본 발명의 한 실시예는 (예를 들어, 협의된 정규화 포맷을 이용하여) 사용자 ID들을 등록 데이터베이스(3302)에 저장하기 전에 사용자 ID들을 정규화한다.
한 실시예에서, 신원 서비스(3301)는 사용자의 현재 콘텍스트와 요청측 장치 상의 설정에 기초하여 정규화를 수행하기 위한 로직을 포함한다. 예를 들어, 도 37에서, 사용자 B는, 신원 서비스(3301)에, 그 홈 캐리어의 신원(예를 들어, AT&T), 그 현재의 로밍 캐리어(예를 들어, TMobile), 사용자 설정(예를 들어, 국제 공조가 이용되고 있는지에 관한 표시), 및 로(raw) 타겟 ID 코드(예를 들어, 4085551212와 같은 비정규화된 형태의 사용자 A의 전화 번호)를 제공할 수 있다. 응답하여, 신원 서비스(3301)는 등록 데이터베이스(3302)에 질의를 수행하기 이전에 상기 변수들 모두에 기초하여 로 타겟 ID(raw target ID)를 정규화할 것이다. 따라서, 사용자 A의 정규 ID(로 ID가 아님)가 (이하에서 상세히 설명되는) 신원 서비스에 대한 사용자 B의 질의에 응답하여 사용자 B에 제공된다.
(4) 질의
앞서 설명된 바와 같이, 타겟 사용자와의 보안 채널을 설정하기 위하여, 사용자는 타겟 사용자에 대한 신원을 검색하기 위해 초기에 신원 서비스에 질의한다. 도 36에 나타낸 바와 같이, 사용자 B는 사용자 A의 신원에 대한 질의를 전송하고, 질의의 일부로서 그 자신의 신원 증명서를 전송한다. 응답하여, 신원 서비스는 다시 0개 이상의 신원 인증서를 전송하고, 이들 각각은 (앞서 언급된 바와 같이 정규화된 포맷의) 사용자 A의 ID 코드, 그 신원에 대한 푸시 토큰, 및 사용자의 A의 ID 및 푸시 토큰과 사용자 B의 ID 및 푸시 토큰에 관해 생성된 질의 서명을 포함한다.
인증이 요구될 때마다 각 서비스가 IDS를 질의하도록 강제하는 것은 비효율적일 것이다. 예를 들어, 사용자 A가 사용자 B에게 메시지를 전송하기를 원할 때, 전술된 인스턴트 메시징 서비스는 사용자 A의 토큰 및 서명과 사용자 B의 토큰 및 서명을 이용하여 신원 서비스에 질의할 필요가 있을 것이고, 이것은 네트워크 자원을 소비할 것이다.
이 문제를 해결하기 위해, 본 명세서에 설명된 본 발명의 실시예에서, 한 세트의 0개 이상의 서명이 사용자들 사이의 각 트랜잭션에 대해 신원 서비스에 의해 생성되고, 이 서명 세트는 각 요청과 함께 각 서비스에 전송된다. 서명은, 전술된 바와 같이, 소스 ID, 소스 토큰, 타겟 ID, 타겟 토큰, 및 타임스탬프의 튜플(tuple)에 관한 것이다. 따라서, 임의의 서비스는 이들 엔티티들에 관해 암호 서명을 동적으로 생성하여 신원 서비스와 연락하지 않고 확인함으로써 스스로 확인을 수행할 수 있다.
또한, 각 개개의 서비스는, 확인이 성공적으로 발생하기 위해 타임스탬프가 얼마나 신선한 것이 될 필요가 있는지에 관해 결정할 수 있다. 확인이 신원 서비스에 의해 생성된 원래의 타임스탬프로부터의 미리정의된 시간 윈도우 내에서 이루어지는 한, 트랜잭션은 성공적으로 확인될 것이다. 따라서, 신원 서비스는 애플리케이션 서비스가 사용자를 인증하는 것을 허용하기 위한 툴을 제공하지만, 인증이 어떻게 이루어져야 하는지(예를 들어, 타임스탬프가 얼마나 신선한 것이 될 필요가 있는지)에 관한 정책을 결정하지는 않는다. 따라서, 상이한 애플리케이션들은 인증에 대해 상이한 정책을 가질 수 있다.
신원 서비스의 한 실시예는 네트워크 트래픽의 양의 더욱 줄이기 위해 질의에 대한 캐싱 아키텍쳐를 구현한다. 도 38a 및 도 38b에 나타낸 바와 같이, 이 실시예에서, 사용자 ID들의 장치 캐시(3801)는 각 사용자 장치(111) 상에 유지되고 중간 시스템 캐시(3802)가 신원 서비스(3301)와 장치(3801) 사이의 네트워크 상에서 구현되어 신원 요청을 서비스함으로써 신원 서비스에 관한 부하를 줄인다. 한 실시예에서, 시스템 캐시(3802)는 Akamai 및 기타의 콘텐츠 배포 서비스로부터 이용가능한 것과 같은 콘텐츠 배포 네트워크에 의해 제공된다.
도 38a에 나타낸 바와 같이, 시스템 캐시가 사용자 A에 대한 유효한 엔트리를 현재 갖고 있지 않다면, 시스템 캐시는 요청을 신원 서비스에 포워딩할 것이고, 신원 서비스는 전술된 바와 같이 사용자 A에 대해 0개 이상의 신원으로 응답할 것이다. 또한, 도 38a에 나타낸 실시예에서, 신원 서비스는 사용자 A의 신원에 대한 지문(fingerprint)을 생성하고 그 지문을 시스템 캐시에 다시 전송한다. 한 실시예에서, 지문은 사용자 A의 신원(즉, A의 정규화된 ID, 푸시 토큰, 및 타임스탬프)을 포함하는 엔티티에 관한 해시(hash)이다. 한 실시예에서, 해시는 SHA-1 해시이지만, 발명의 기저 원리는 임의의 특정 타입의 해시 알고리즘으로 제한되지 않는다.
그 다음, 지문은 도 38b에 표시된 바와 같이, 시스템 캐시 상에 사용자 A의 신원과 함께 캐싱된다(예를 들어, 사용자 A의 정규화된 신원들을 이용하여 인덱싱된다). 또한, 지문 및 연관된 ID들은 사용자 B의 장치 상의 장치 캐시(3801) 내에 캐싱될 수 있다.
사용자 B가 후속해서 사용자 A의 신원을 질의할 필요가 있을 때, 사용자 B는 초기에 장치 캐시(3801) 내부를 찾아보고 사용자 A의 신원에 대해 유효한 캐시 엔트리가 존재하는지를 결정할 것이다. 한 실시예에서, 각 캐시 엔트리는 (도 38에 도시된 타임스탬프 열에 의해 결정되는) 그 연관된 생존 시간(TTL; time to live) 값을 가진다. 신원에 대한 요청이 이 타임스탬프로부터의 시간의 명시된 윈도우 내에서 발생하는 한, 장치 캐시(3801) 내의 엔트리는 유효하고 네트워크를 통한 질의는 요구되지 않는다(즉, 사용자 B는 장치 캐시(3801)로부터 사용자 A의 신원을 판독한다).
그러나, 장치 캐시(3801) 내의 캐시 엔트리가 만료되었다면(즉, TTL 값을 경과했다면), 사용자 B는 사용자 A의 신원들에 대한 질의를 시스템 캐시(3802)에 전송하고, 시스템 캐시(3802)는 사용자 A에 대한 지문을 조회하여 그 지문을 사용자 A에 대한 질의와 함께 신원 서비스(3301)에 전송한다. 신원 서비스(3301)에 의해 결정되는 바와 같이 지문이 여전히 유효하다면(예를 들어, 타임스탬프가 여전히 유효한 시간 윈도우 내에 있다면), 신원 서비스(3301)에 의해 요구되는 응답만이 지문의 유효성의 표시이다. 그러면 시스템 캐시(3802)는, 도 38b에 표시된 바와 같이, 사용자 A의 신원들의 캐싱된 사본을 사용자 B에 반환한다. 전술된 캐싱 기술들은 사용자 B와 사용자 A의 신원들에 관한 새로운 서명 세트를 생성하기 위해 요구될 상당한 양의 처리 자원을 절감한다.
한 실시예에서, 앞서 언급된 캐시 TTL 값은 애플리케이션별 기초로(즉, 애플리케이션 설계자의 보안 선호도에 기초하여) 구성가능할 수 있다. 따라서, 예를 들어, FacetimeTM과 같은 애플리케이션에는 iChatTM과는 상이한 TTL 값이 제공될 수 있다. 또한, TTL 값은 현재의 네트워크 상태에 기초하여 동적으로 설정될 수 있다. 예를 들어, 네트워크가 현재 트래픽으로 과부하되어 있다면, TTL 값은 더 높은 값으로 동적으로 설정(이로써, 캐싱된 신원이 더 긴 시간 동안 유효하다)될 수 있다. 또한, 한 실시예에서, 전술된 캐싱 기술들 모두는 애플리케이션 개발자들에 노출된 API 내에서 구현된다. 이와 같이, 신원들의 캐싱은 이들을 이용하는 애플리케이션들에게 투명하게 발생한다.
본 발명의 실시예들은 위에서 개시된 다양한 단계들을 포함할 수 있다. 이 단계들은 범용 컴퓨터 또는 특별 목적 컴퓨터가 소정의 단계들을 수행하게 하는 머신-실행가능한 명령어들로 구현될 수 있다. 대안으로서, 이들 단계들은, 단계들을 수행하기 위한 하드와이어드 로직을 포함하는 특정의 하드웨어 컴포넌트들에 의해 수행되거나, 프로그램된 컴퓨터 컴포넌트 및 맞춤형 하드웨어 컴포넌트들의 임의 조합에 의해 수행될 수 있다.
본 발명의 요소들은 또한, 머신-실행가능한 프로그램 코드를 저장하기 위한 머신-판독가능한 매체로서 제공될 수 있다. 머신-판독가능한 매체는, 플로피 디스켓, 광학 디스크, CD-ROM, 및 광자기 디스크, ROM, RAM, EPROM, EEPROM, 자기 또는 광학 카드, 또는 전자 프로그램 코드를 저장하기 위한 기타 유형의 매체/머신-판독가능한 매체를 포함할 수도 있지만, 이들로 제한되는 것은 아니다.
상기 상세한 설명 전체를 통해, 설명의 목적을 위해, 많은 구체적인 세부사항이 본 발명의 철저한 이해를 제공하기 위하여 개시되었다. 그러나, 본 발명은 이와 같은 구체적인 세부사항들 중 일부가 없이도 실시될 수 있다는 것은 당업자에게 명백할 것이다. 예를 들어, 본 명세서에 설명된 기능 모듈들 및 방법들은 소프트웨어, 하드웨어, 또는 이들의 임의 조합으로서 구현될 수도 있다는 것은 당업자에게 용이하게 명백할 것이다. 게다가, 본 발명의 실시예들이 모바일 컴퓨팅 환경의 콘텍스트에서(즉, 모바일 장치 120-123; 601-603을 이용하여) 본 명세서에 설명되었지만, 본 발명의 기저 원리는 모바일 컴퓨팅 구현으로 제한되는 것은 아니다. 예를 들어, 데스크탑이나 워크스테이션 컴퓨터를 포함하는 일부 실시예들에서, 사실상 임의 타입의 클라이언트 또는 피어 데이터 처리 장치들이 이용될 수 있다. 따라서, 본 발명의 범위와 사상은 이하의 청구항들에 관하여 판단되어야 한다.

Claims (33)

  1. 보안 인스턴트 메시징(secure instant messaging)을 구현하기 위한 방법으로서,
    신원 서비스에 의해 제1 사용자의 모바일 장치로부터 제2 사용자와의 인스턴트 메시징 세션을 확립하기 위한 요청을 수신하는 단계 ― 상기 요청은 상기 제2 사용자를 식별하는 식별 코드를 포함함 ―;
    상기 신원 서비스에 의해 상기 제2 사용자가 네트워크 서비스에 등록된 하나 이상의 모바일 장치를 갖는지를 결정하는 단계;
    상기 제2 사용자가 등록된 하나 이상의 모바일 장치를 가진다면, 상기 신원 서비스에 의해 상기 제1 사용자의 상기 모바일 장치로 상기 제2 사용자의 상기 하나 이상의 모바일 장치를 식별하는 어드레싱 정보 및 상기 제2 사용자와 연관된 공개 키를 제공하는 단계;
    상기 신원 서비스에 의해 푸시 통보 서비스로 세션 키를 제공하는 단계 - 상기 세션 키는 상기 제1 및 제2 사용자의 상기 모바일 장치들에 대한 네트워크 정보와 상기 제1 및 제2 사용자의 식별 코드들에 의해 생성된 서명을 포함함 - ;
    상기 푸시 통보 서비스에 의해 상기 제1 사용자의 상기 모바일 장치로부터 암호화된 인스턴트 메시지를 수신하는 단계 - 상기 암호화된 인스턴트 메시지는 상기 제2 사용자의 상기 공개 키와 상기 제1 사용자의 개인 키를 이용하여 상기 제1 사용자의 상기 모바일 장치에 의해 생성됨 - ;
    상기 푸시 통보 서비스에 의해 보안 인스턴트 메시지 서비스로 상기 세션 키 및 상기 암호화된 인스턴트 메시지를 송신하는 단계;
    상기 보안 인스턴트 메시지 서비스에 의해 상기 세션 키, 상기 제1 및 제2 사용자의 상기 모바일 장치들에 대한 상기 네트워크 정보 및 상기 제1 및 제2 사용자의 상기 식별 코드들을 사용해서 상기 암호화된 인스턴트 메시지를 확인(verify)하는 단계;
    상기 푸시 통보 서비스에 의해 상기 보안 인스턴트 메시지 서비스로부터 상기 확인된 암호화된 인스턴트 메시지를 수신하는 단계; 및
    상기 푸시 통보 서비스에 의해 상기 제2 사용자의 상기 하나 이상의 모바일 장치로 상기 확인된 암호화된 인스턴트 메시지를 송신하는 단계 - 상기 제2 사용자의 상기 하나 이상의 모바일 장치는 후속해서 상기 제2 사용자의 개인 키를 이용하여 상기 확인된 암호화된 인스턴트 메시지를 암호해독함 - 를 포함하는, 보안 인스턴트 메시징 구현 방법.
  2. 제1항에 있어서, 상기 식별 코드는 상기 제2 사용자의 전자메일 주소를 포함하는, 보안 인스턴트 메시징 구현 방법.
  3. 제1항에 있어서, 상기 어드레싱 정보는 상기 네트워크 서비스 상에서 상기 제2 사용자의 상기 하나 이상의 모바일 장치를 고유하게 식별하는 토큰(token)을 포함하는, 보안 인스턴트 메시징 구현 방법.
  4. 삭제
  5. 제1항에 있어서, 상기 결정하는 단계는,
    상기 제2 사용자가 상기 네트워크 서비스에 등록되어 있는지를 결정하기 위해 등록 데이터베이스로 질의하는 단계를 더 포함하고, 상기 등록 데이터베이스는 상기 제2 사용자를 하나 이상의 식별 코드와 연관시키는, 보안 인스턴트 메시징 구현 방법.
  6. 제1항에 있어서, 상기 인스턴트 메시지를 암호화하는 단계는, 상기 제2 사용자의 공개 키를 이용하여 임의의 텍스트 및 첨부물들 중 적어도 하나를 포함하는 상기 인스턴트 메시지의 콘텐츠를 암호화하고 상기 제1 사용자의 개인 키를 이용하여 상기 콘텐츠에 서명하는 단계를 더 포함하는, 보안 인스턴트 메시징 구현 방법.
  7. 제6항에 있어서, 상기 확인된 암호화된 인스턴트 메시지를 암호해독하는 것은 상기 제2 사용자의 개인 키를 이용하여 상기 콘텐츠를 암호해독하고 상기 제1 사용자의 공개 키를 이용하여 상기 콘텐츠에 대한 상기 서명을 확인하는 것을 더 포함하는, 보안 인스턴트 메시징 구현 방법.
  8. 제7항에 있어서, 상기 제2 사용자의 상기 하나 이상의 모바일 장치는 상기 신원 서비스에서 상기 제1 사용자의 공개 키를 검색하는(retrieve), 보안 인스턴트 메시징 구현 방법.
  9. 삭제
  10. 삭제
  11. 제1항에 있어서, 상기 확인하는 단계는 상기 보안 인스턴트 메시지 서비스에서 상기 세션 키를 재생성하는 단계를 포함하는, 보안 인스턴트 메시징 구현 방법.
  12. 보안 인스턴트 메시징을 구현하는 시스템으로서, 프로그램 코드를 저장하기 위한 메모리와 적어도 하나의 프로세서를 포함하며, 상기 적어도 하나의 프로세서는 상기 프로그램 코드를 처리하여
    신원 서비스에 의해 제1 사용자를 위한 모바일 장치로부터 제2 사용자와의 인스턴트 메시징 세션을 확립하기 위한 요청을 수신하는 동작 ― 상기 요청은 상기 제2 사용자를 식별하는 식별 코드를 포함함 ― ;
    상기 신원 서비스에 의해 상기 제2 사용자가 네트워크 서비스에 등록된 하나 이상의 모바일 장치를 갖는지를 결정하는 동작;
    상기 제2 사용자가 등록된 하나 이상의 모바일 장치를 가진다면, 상기 신원 서비스에 의해 상기 제1 사용자의 상기 모바일 장치로 상기 제2 사용자의 상기 하나 이상의 모바일 장치를 식별하는 어드레싱 정보 및 상기 제2 사용자와 연관된 공개 키를 제공하는 동작;
    상기 신원 서비스에 의해 푸시 통보 서비스로 세션 키를 제공하는 동작 - 상기 세션 키는 상기 제1 및 제2 사용자의 상기 모바일 장치들에 대한 네트워크 정보와 상기 제1 및 제2 사용자의 식별 코드들에 의해 생성된 서명을 포함함 - ;
    상기 푸시 통보 서비스에 의해 상기 제1 사용자의 상기 모바일 장치로부터 암호화된 인스턴트 메시지를 수신하는 동작 - 상기 암호화된 인스턴트 메시지는 상기 제2 사용자의 상기 공개 키와 상기 제1 사용자의 개인 키를 이용하여 상기 제1 사용자의 상기 모바일 장치에 의해 생성됨 - ;
    상기 푸시 통보 서비스에 의해 보안 인스턴트 메시지 서비스로 상기 세션 키 및 상기 암호화된 인스턴트 메시지를 송신하는 동작;
    상기 보안 인스턴트 메시지 서비스에 의해 상기 세션 키, 상기 제1 및 제2 사용자의 상기 모바일 장치들에 대한 상기 네트워크 정보 및 상기 제1 및 제2 사용자의 상기 식별 코드들을 사용해서 상기 암호화된 인스턴트 메시지를 확인하는 동작;
    상기 푸시 통보 서비스에 의해 상기 보안 인스턴트 메시지 서비스로부터 상기 확인된 암호화된 인스턴트 메시지를 수신하는 동작; 및
    상기 푸시 통보 서비스에 의해 상기 제2 사용자의 상기 하나 이상의 모바일 장치로 상기 확인된 암호화된 인스턴트 메시지를 송신하는 동작 - 상기 제2 사용자의 상기 하나 이상의 모바일 장치는 후속해서 상기 제2 사용자의 개인 키를 이용하여 상기 확인된 암호화된 인스턴트 메시지를 암호해독함 - 을 수행하는, 보안 인스턴트 메시징 구현 시스템.
  13. 제12항에 있어서, 상기 식별 코드는 상기 제2 사용자의 전자메일 주소를 포함하고,
    상기 어드레싱 정보는 상기 네트워크 서비스 상에서 상기 제2 사용자의 상기 하나 이상의 모바일 장치를 고유하게 식별하는 토큰을 포함하는, 보안 인스턴트 메시징 구현 시스템.
  14. 데이터 처리 시스템으로서,
    신원 서비스에 의해 제1 사용자를 위한 모바일 장치로부터 제2 사용자와의 인스턴트 메시징 세션을 확립하기 위한 요청을 수신하는 수단 ― 상기 요청은 상기 제2 사용자를 식별하는 식별 코드를 포함함 ― ;
    상기 신원 서비스에 의해 상기 제2 사용자가 네트워크 서비스에 등록된 하나 이상의 모바일 장치를 갖는지를 결정하는 수단;
    상기 제2 사용자가 등록된 하나 이상의 모바일 장치를 가진다면, 상기 신원 서비스에 의해 상기 제1 사용자의 상기 모바일 장치로 상기 제2 사용자의 상기 하나 이상의 모바일 장치를 식별하는 어드레싱 정보 및 상기 제2 사용자와 연관된 공개 키를 제공하는 수단;
    상기 신원 서비스에 의해 푸시 통보 서비스로 세션 키를 제공하는 수단 - 상기 세션 키는 상기 제1 및 제2 사용자의 상기 모바일 장치들에 대한 네트워크 정보와 상기 제1 및 제2 사용자의 식별 코드들에 의해 생성된 서명을 포함함 - ;
    상기 푸시 통보 서비스에 의해 상기 제1 사용자의 상기 모바일 장치로부터 암호화된 인스턴트 메시지를 수신하는 수단 - 상기 암호화된 인스턴트 메시지는 상기 제2 사용자의 상기 공개 키와 상기 제1 사용자의 개인 키를 이용하여 상기 제1 사용자의 상기 모바일 장치에 의해 생성됨 - ;
    상기 푸시 통보 서비스에 의해 보안 인스턴트 메시지 서비스로 상기 세션 키 및 상기 암호화된 인스턴트 메시지를 송신하는 수단;
    상기 보안 인스턴트 메시지 서비스에 의해 상기 세션 키, 상기 제1 및 제2 사용자의 상기 모바일 장치들에 대한 상기 네트워크 정보 및 상기 제1 및 제2 사용자의 상기 식별 코드들을 사용해서 상기 암호화된 인스턴트 메시지를 확인하는 수단;
    상기 푸시 통보 서비스에 의해 상기 보안 인스턴트 메시지 서비스로부터 상기 확인된 암호화된 인스턴트 메시지를 수신하는 수단; 및
    상기 푸시 통보 서비스에 의해 상기 제2 사용자의 상기 하나 이상의 모바일 장치로 상기 확인된 암호화된 인스턴트 메시지를 송신하는 수단 - 상기 제2 사용자의 상기 하나 이상의 모바일 장치는 후속해서 상기 제2 사용자의 개인 키를 이용하여 상기 확인된 암호화된 인스턴트 메시지를 암호해독함 - 을 포함하는 데이터 처리 시스템.
  15. 컴퓨터에 의해 실행될 때, 상기 컴퓨터로 하여금 제1항 내지 제3항, 제5항 내지 제8항 또는 제11항 중 어느 한 항의 방법을 수행하게 하는 컴퓨터 프로그램 코드가 저장된 컴퓨터 판독가능 매체.
  16. 삭제
  17. 삭제
  18. 삭제
  19. 삭제
  20. 삭제
  21. 삭제
  22. 삭제
  23. 삭제
  24. 삭제
  25. 삭제
  26. 삭제
  27. 삭제
  28. 삭제
  29. 삭제
  30. 삭제
  31. 삭제
  32. 삭제
  33. 삭제
KR1020137034859A 2011-06-03 2012-05-31 보안 인스턴트 메시징을 위한 시스템 및 방법 KR101597295B1 (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201161492903P 2011-06-03 2011-06-03
US61/492,903 2011-06-03
US13/224,599 2011-09-02
US13/224,599 US8958559B2 (en) 2011-06-03 2011-09-02 System and method for secure instant messaging
PCT/US2012/040314 WO2012166990A1 (en) 2011-06-03 2012-05-31 System and method for secure instant messaging

Publications (2)

Publication Number Publication Date
KR20140025553A KR20140025553A (ko) 2014-03-04
KR101597295B1 true KR101597295B1 (ko) 2016-02-24

Family

ID=46210465

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020137034859A KR101597295B1 (ko) 2011-06-03 2012-05-31 보안 인스턴트 메시징을 위한 시스템 및 방법

Country Status (10)

Country Link
US (1) US8958559B2 (ko)
EP (1) EP2702732B1 (ko)
JP (1) JP5904682B2 (ko)
KR (1) KR101597295B1 (ko)
CN (1) CN103597783B (ko)
AU (1) AU2012262053B2 (ko)
BR (1) BR112013030972B1 (ko)
DE (1) DE112012002343T5 (ko)
GB (1) GB2505590A (ko)
WO (1) WO2012166990A1 (ko)

Families Citing this family (99)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9622278B2 (en) 2010-10-26 2017-04-11 Kingston Digital Inc. Dual-mode wireless networked device interface and automatic configuration thereof
US9270453B2 (en) 2011-06-30 2016-02-23 Verizon Patent And Licensing Inc. Local security key generation
US8943318B2 (en) * 2012-05-11 2015-01-27 Verizon Patent And Licensing Inc. Secure messaging by key generation information transfer
US9154527B2 (en) 2011-06-30 2015-10-06 Verizon Patent And Licensing Inc. Security key creation
US8990554B2 (en) 2011-06-30 2015-03-24 Verizon Patent And Licensing Inc. Network optimization for secure connection establishment or secure messaging
US10237253B2 (en) * 2011-09-09 2019-03-19 Kingston Digital, Inc. Private cloud routing server, private network service and smart device client architecture without utilizing a public cloud based routing server
US9203807B2 (en) * 2011-09-09 2015-12-01 Kingston Digital, Inc. Private cloud server and client architecture without utilizing a routing server
US10601810B2 (en) 2011-09-09 2020-03-24 Kingston Digital, Inc. Private cloud routing server connection mechanism for use in a private communication architecture
US9935930B2 (en) * 2011-09-09 2018-04-03 Kingston Digital, Inc. Private and secure communication architecture without utilizing a public cloud based routing server
US9781087B2 (en) * 2011-09-09 2017-10-03 Kingston Digital, Inc. Private and secure communication architecture without utilizing a public cloud based routing server
US11863529B2 (en) 2011-09-09 2024-01-02 Kingston Digital, Inc. Private cloud routing server connection mechanism for use in a private communication architecture
US11683292B2 (en) 2011-09-09 2023-06-20 Kingston Digital, Inc. Private cloud routing server connection mechanism for use in a private communication architecture
US8825697B2 (en) * 2011-09-13 2014-09-02 Stefano Foresti Method and system to capture, share and find information and relationships
US9160780B2 (en) * 2011-12-30 2015-10-13 International Business Machines Corporation System and method for establishing a voice over IP session
US9680763B2 (en) 2012-02-14 2017-06-13 Airwatch, Llc Controlling distribution of resources in a network
US10404615B2 (en) 2012-02-14 2019-09-03 Airwatch, Llc Controlling distribution of resources on a network
GB2504461B (en) * 2012-06-14 2014-12-03 Microsoft Corp Notification of communication events
GB201210598D0 (en) 2012-06-14 2012-08-01 Microsoft Corp Notification of communication events
GB201210600D0 (en) 2012-06-14 2012-08-01 Microsoft Corp Call invites
GB201210596D0 (en) 2012-06-14 2012-08-01 Microsoft Corp Notification of communication events
US8707454B1 (en) 2012-07-16 2014-04-22 Wickr Inc. Multi party messaging
JP6224591B2 (ja) 2012-08-06 2017-11-01 グリー株式会社 表示システム、同システムにおける表示方法及び表示プログラム
US9772668B1 (en) 2012-09-27 2017-09-26 Cadence Design Systems, Inc. Power shutdown with isolation logic in I/O power domain
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
JP2014103614A (ja) * 2012-11-22 2014-06-05 Hitachi Ltd 通信システム
US9363165B2 (en) * 2013-03-11 2016-06-07 Qualcomm Incorporated Enhanced call control for directing a content path over multiple connections
US20140280955A1 (en) 2013-03-14 2014-09-18 Sky Socket, Llc Controlling Electronically Communicated Resources
FR3004047A1 (fr) * 2013-03-29 2014-10-03 France Telecom Technique de cooperation entre une pluralite d'entites clientes
KR101497630B1 (ko) * 2013-04-05 2015-03-03 삼성에스디에스 주식회사 모바일 환경에서의 p2p 접속 시스템 및 단말과 이를 이용한 p2p 접속 방법
US9219741B2 (en) 2013-05-02 2015-12-22 Airwatch, Llc Time-based configuration policy toggling
KR102142576B1 (ko) * 2013-05-16 2020-08-10 삼성전자주식회사 단말간 통신을 위한 탐색 방법 및 장치
US10021180B2 (en) 2013-06-04 2018-07-10 Kingston Digital, Inc. Universal environment extender
US10567349B2 (en) 2013-06-25 2020-02-18 Wickr Inc. Secure time-to-live
US10129260B1 (en) 2013-06-25 2018-11-13 Wickr Inc. Mutual privacy management
US9866591B1 (en) 2013-06-25 2018-01-09 Wickr Inc. Enterprise messaging platform
US9830089B1 (en) 2013-06-25 2017-11-28 Wickr Inc. Digital data sanitization
JP6056970B2 (ja) * 2013-06-28 2017-01-11 富士通株式会社 情報処理装置、端末機、情報処理システム及び情報処理方法
JP2015103031A (ja) * 2013-11-25 2015-06-04 株式会社セガ プッシュ通知管理装置、プッシュ通知管理方法およびプッシュ通知管理プログラム
US9698976B1 (en) 2014-02-24 2017-07-04 Wickr Inc. Key management and dynamic perfect forward secrecy
US20150350247A1 (en) * 2014-05-30 2015-12-03 Apple Inc. Efficient secure instant messaging
KR101585138B1 (ko) 2014-06-24 2016-01-13 주식회사 아이티엑스시큐리티 Ｐ２ｐ 중계 데몬을 이용한 보안 기기 연결 시스템 및 방법
US9584530B1 (en) 2014-06-27 2017-02-28 Wickr Inc. In-band identity verification and man-in-the-middle defense
US10348518B2 (en) 2014-09-22 2019-07-09 Left Technologies Inc. Method, apparatus, system and media for transmitting messages between networked devices in data communication with a local network access point
CN104270516B (zh) * 2014-09-23 2019-05-24 中兴通讯股份有限公司 解密方法和移动终端
KR102457809B1 (ko) 2014-09-24 2022-10-24 삼성전자주식회사 데이터 통신 보안을 위한 방법, 장치 및 시스템
US9654288B1 (en) 2014-12-11 2017-05-16 Wickr Inc. Securing group communications
US9584964B2 (en) 2014-12-22 2017-02-28 Airwatch Llc Enforcement of proximity based policies
CN105791234A (zh) * 2014-12-23 2016-07-20 宇龙计算机通信科技(深圳)有限公司 用于终端的数据共享方法、数据共享装置和终端
US9706394B2 (en) 2015-03-06 2017-07-11 Apple Inc. Communicating messages with intermittently available encryption credentials
US20160275301A1 (en) * 2015-03-17 2016-09-22 Dots Communication, Inc. Information sharing control
CN104660417B (zh) * 2015-03-17 2018-02-27 联想(北京)有限公司 验证方法、验证装置和电子设备
KR102395799B1 (ko) * 2015-07-09 2022-05-10 삼성전자주식회사 메신저 서비스를 제공하는 장치 및 방법
US9628992B2 (en) * 2015-07-31 2017-04-18 Wyfi, Inc. WiFi access management system and methods of operation thereof
KR101589111B1 (ko) * 2015-08-27 2016-01-28 주식회사 지앤톡 보안 채팅 서비스 제공 방법 및 이를 실행하는 시스템
CN105323243A (zh) * 2015-09-22 2016-02-10 阿里巴巴集团控股有限公司 基于即时通讯的安全语音通讯方法及装置
US9877197B2 (en) 2015-10-09 2018-01-23 Disney Enterprises, Inc. Secure network matchmaking
CN106612265A (zh) * 2015-10-27 2017-05-03 阿里巴巴集团控股有限公司 即时通信方法及服务器
KR102104094B1 (ko) * 2015-11-02 2020-04-23 에스케이텔레콤 주식회사 인증장치, 및 단말 간의 인증을 위한 프로그램 및 그 프로그램이 기록된 컴퓨터 판독 가능 기록매체
US9584493B1 (en) 2015-12-18 2017-02-28 Wickr Inc. Decentralized authoritative messaging
US10291607B1 (en) 2016-02-02 2019-05-14 Wickr Inc. Providing real-time events to applications
US9602477B1 (en) 2016-04-14 2017-03-21 Wickr Inc. Secure file transfer
US9596079B1 (en) 2016-04-14 2017-03-14 Wickr Inc. Secure telecommunications
US10333946B1 (en) * 2016-06-22 2019-06-25 Amazon Technologies, Inc. Distributing variable entropy ephemeral security credentials across channels of variable assurance
CN107548088B (zh) * 2016-06-25 2021-06-22 深圳壹账通智能科技有限公司 移动设备身份识别的方法及业务服务器
KR101795696B1 (ko) * 2016-07-14 2017-11-09 주식회사 코인플러그 메신저 서비스를 통하여 송수신되는 데이터에 대한 기록 및 검증 서비스를 제공하는 방법, 및 이를 이용한 서버
US10129229B1 (en) * 2016-08-15 2018-11-13 Wickr Inc. Peer validation
US10242206B2 (en) * 2016-09-01 2019-03-26 Onapsis, Inc. System and method for fast probabilistic querying role-based access control systems
CN106385318B (zh) * 2016-09-06 2019-06-14 北京叮叮关爱科技有限公司 基于椭圆方程的sdk验证方法
US20180123782A1 (en) * 2016-10-27 2018-05-03 Motorola Solutions, Inc. Method for secret origination service to distribute a shared secret
CN106549858B (zh) * 2016-12-08 2019-12-10 深圳奥联信息安全技术有限公司 一种基于标识密码的即时通信加密方法
CN106411963B (zh) * 2016-12-16 2019-06-25 北京元心科技有限公司 即时通讯消息的传输方法及装置
EP4207652A1 (en) * 2017-03-23 2023-07-05 Telefonaktiebolaget LM ERICSSON (PUBL) Configuring of transmission of data for a first service in a transmission of a second service
US10509921B2 (en) 2017-05-31 2019-12-17 Intuit Inc. System for managing transactional data
US10594661B1 (en) * 2017-06-13 2020-03-17 Parallels International Gmbh System and method for recovery of data packets transmitted over an unreliable network
JP7203297B2 (ja) * 2017-09-27 2023-01-13 有限会社シモウサ・システムズ エンドツーエンド暗号化通信システム
US20190116169A1 (en) * 2017-10-18 2019-04-18 Microsoft Technology Licensing, Llc. Real-time data for access control approval
CN108023873B (zh) * 2017-11-08 2020-12-11 深圳市文鼎创数据科技有限公司 信道建立方法及终端设备
TWI650990B (zh) * 2017-12-22 2019-02-11 中華電信股份有限公司 憑證透明度監督系統及其方法
CN110019682B (zh) * 2017-12-28 2022-12-27 北京京东尚科信息技术有限公司 用于处理信息的系统、方法和装置
IL258379A (en) * 2018-03-26 2018-05-31 Kazuar Advanced Tech Ltd Secure remote terminal
CN110557359A (zh) * 2018-06-01 2019-12-10 厦门本能管家科技有限公司 一种基于区块链的消息通信方法及其装置
US10944562B2 (en) 2018-06-03 2021-03-09 Apple Inc. Authenticating a messaging program session
CN108829539A (zh) * 2018-06-08 2018-11-16 中国联合网络通信集团有限公司 数据备份、数据恢复方法及设备
US11133932B2 (en) * 2018-12-20 2021-09-28 Sony Interactive Entertainment LLC Secure data channel in a networked gaming system
CN109639828B (zh) * 2019-01-15 2022-05-24 腾讯科技（深圳）有限公司 会话消息处理方法和装置
EP3923515A4 (en) * 2019-02-06 2022-12-14 Connectfree Corporation DATA TRANSMISSION METHOD, COMMUNICATIONS PROCESSING METHOD, DEVICE AND COMMUNICATIONS PROCESSING PROGRAM
EP3731480B1 (en) * 2019-04-25 2022-03-02 Mastercard International Incorporated Systems and methods for secure communication
CN112134826B (zh) * 2019-06-24 2022-05-13 华为技术有限公司 通信方法，计算机设备和计算机可读存储介质
EP4158857A1 (en) * 2020-05-27 2023-04-05 Step Software Inc. Systems and methods for data communications
TWI780461B (zh) * 2020-07-30 2022-10-11 莊連豪 資訊傳輸加密防護方法及其實施系統
KR102293610B1 (ko) * 2020-09-15 2021-08-25 주식회사 카카오엔터프라이즈 보안 인스턴트 메시징 방법 및 장치
CN112449345B (zh) * 2020-12-09 2024-02-09 中国联合网络通信集团有限公司 一种安全通信方法和设备
CN112671903A (zh) * 2020-12-23 2021-04-16 杭州安司源科技有限公司 一种通用内网在线服务系统
CN114765595A (zh) * 2021-01-04 2022-07-19 腾讯科技（深圳）有限公司 聊天消息的显示方法、发送方法、装置、电子设备及介质
KR102507864B1 (ko) * 2021-05-12 2023-03-08 주식회사 카카오엔터프라이즈 보안 인스턴트 메시징 방법 및 장치
US11546769B1 (en) * 2021-06-30 2023-01-03 Fortinet, Inc. NGFW (next generation firewall) security inspection over multiple sessions of message session relay protocol (MSRP) on a data communication network
US11941266B2 (en) 2021-10-20 2024-03-26 Samsung Electronics Co., Ltd. Resource isolation in computational storage devices
KR102544084B1 (ko) * 2021-12-10 2023-06-15 주식회사 카카오엔터프라이즈 보안 인스턴트 메시징 방법 및 장치
CN114968103A (zh) * 2022-05-27 2022-08-30 厦门大学 一种基于持久性内存的指纹存储方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070162554A1 (en) 2006-01-12 2007-07-12 International Business Machines Corporation Generating a public key and a private key in an instant messaging server
US20090215476A1 (en) 2008-02-27 2009-08-27 Research In Motion Limited System and method for enabling instant messages to be exchanged between mobile devices

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5748735A (en) * 1994-07-18 1998-05-05 Bell Atlantic Network Services, Inc. Securing E-mail communications and encrypted file storage using yaksha split private key asymmetric cryptography
US20030126213A1 (en) 2002-01-02 2003-07-03 International Business Machines Corporation Establishing direct instant messaging communication between wireless devices
KR20040080855A (ko) * 2003-03-14 2004-09-20 김형대 개인컴퓨터 간의 네트워크를 이용한 전자메일 송수신시스템 및 서비스 방법
CN1291610C (zh) * 2003-09-12 2006-12-20 腾讯科技（深圳）有限公司 一种基于即时通讯的信息反馈方法和系统
ATE429766T1 (de) 2005-11-16 2009-05-15 Totemo Ag Verfahren zur herstellung eines sicheren e-mail kommunikationskanals zwischen einem absender und einem empfänger
ATE547876T1 (de) 2009-10-28 2012-03-15 Research In Motion Ltd Automatische benutzerauthentifizierung und - identifizierung für mobile sofortnachrichtenanwendung

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070162554A1 (en) 2006-01-12 2007-07-12 International Business Machines Corporation Generating a public key and a private key in an instant messaging server
US20090215476A1 (en) 2008-02-27 2009-08-27 Research In Motion Limited System and method for enabling instant messages to be exchanged between mobile devices

Also Published As

Publication number Publication date
DE112012002343T5 (de) 2014-02-20
GB2505590A (en) 2014-03-05
JP5904682B2 (ja) 2016-04-20
BR112013030972A2 (pt) 2016-11-29
JP2014522014A (ja) 2014-08-28
US20120311329A1 (en) 2012-12-06
AU2012262053B2 (en) 2015-09-24
EP2702732B1 (en) 2018-11-07
BR112013030972B1 (pt) 2022-08-16
US8958559B2 (en) 2015-02-17
KR20140025553A (ko) 2014-03-04
CN103597783B (zh) 2017-04-26
EP2702732A1 (en) 2014-03-05
CN103597783A (zh) 2014-02-19
WO2012166990A1 (en) 2012-12-06
GB201321181D0 (en) 2014-01-15

Similar Documents

Publication Publication Date Title
KR101597295B1 (ko) 보안 인스턴트 메시징을 위한 시스템 및 방법
US9078128B2 (en) System and method for secure identity service
US9119067B2 (en) Embodiments of a system and method for securely managing multiple user handles across multiple data processing devices
JP5711849B2 (ja) 異なるサービスプロバイダー間のピア・ツー・ピア接続を管理する装置及び方法
KR101408490B1 (ko) 온라인 세션에 대해 사용자를 매치하기 위한 장치 및 방법
KR101408560B1 (ko) 사용자를 온라인 세션에 초대하기 위한 장치 및 방법
AU2012262053A1 (en) System and method for secure instant messaging
TWI458369B (zh) 用於建立及使用備用通信頻道之裝置及方法

Legal Events

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

Payment date: 20190116

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20200115

Year of fee payment: 5