KR101712199B1

KR101712199B1 - 메시징 서비스와 소셜 네트워크 서비스 간의 상호 연동을 통한 연락처 제공 장치 및 방법

Info

Publication number: KR101712199B1
Application number: KR1020100018734A
Authority: KR
Inventors: 이경탁; 오규봉; 김욱; 이승용
Original assignee: 삼성전자주식회사
Priority date: 2010-03-02
Filing date: 2010-03-02
Publication date: 2017-03-03
Anticipated expiration: 2030-03-02
Also published as: CA2792147C; WO2011108844A2; CA2792147A1; KR20110099599A; WO2011108844A3; US9363106B2; US20120324009A1; EP2543201A2; EP2543201A4; JP2013521562A; JP5815569B2

Abstract

본 발명은 소셜 네트워크 서비스(Social Network Service: 이하, SNS)와의 상호 연동을 통한 연락처 제공 방법을 제안한다. 이를 위해 본 발명은 SNS와의 연동을 통해 타서비스를 이용하는 클라이언트에서 그 SNS에서 제공하는 연락처를 제공받는 과정과, 제공된 연락처에 그 클라이언트와 동일한 서비스에 가입된 상대방 클라이언트가 있는지를 판단하고, 판단 결과를 통지하는 과정으로 이루어진다. 이에 따라 타서비스를 이용하는 클라이언트는 판단 결과를 이용하여 원하는 상대방 클라이언트의 서비스 가입 여부를 알 수 있으며, 그 상대방 클라이언트가 자신과 동일한 서비스에 가입되어 있지 않을 경우 그 서비스 초청을 요청할 수 있다. 이렇게 함으로써 서비스 가입 여부를 알고자 하는 대상을 확장시킬 수 있게 된다.

Description

메시징 서비스와 소셜 네트워크 서비스 간의 상호 연동을 통한 연락처 제공 장치 및 방법{APPARATUS AND METHOD FOR PROVIDING NEW CONTACT VIA INTERACTION BETWEEN SOCIAL NETWORK SERVICE AND MESSAGING SERVICE}

본 발명은 메시징 서비스 장치 및 방법에 관한 것으로, 특히 메시징 서비스와 소셜 네트워크 서비스 간의 상호 연동을 통한 연락처 제공 장치 및 방법에 관한 것이다.

이동 통신 단말은 언제 어디서나 필요한 정보를 공급하고 교환할 수 있는 수단으로 기존에는 단순히 전화 등을 통한 통화가 대부분이었지만, 점차 이동 통신 단말의 보급이 보편화됨에 따라 텍스트 및 멀티미디어를 통해 대화나 정보 교환 측면의 중요성이 더욱 부각되고 있다. 이에 대응하여 SMS(Short Message Service), MMS(Multimedia Messaging Service), MSN(MicroSoft Network)과 같은 다양한 메시징 서비스와, 페이스북(Facebook), 트위터(Twitter)와 같은 다양한 소셜 네트워크(Social Network) 서비스가 제공되고 있다.

이런 다양한 서비스들은 서로 다른 기술 기반으로 제공되지만, 사용자 측면에서는 비록 서로 다른 서비스를 이용할지라도 중복되는 기능과 사용자 경험(user experience)을 제공받게 된다. 게다가 각 서비스마다 다른 서비스들과 구별되는 특징도 있기 때문에, 모든 특징들을 체험하기 위해서는 사용자가 각 서비스에 가입해야 하는 부담도 있다.

이러한 사용자 부담감을 최소화하기 위해, 이런 다양한 사용자 경험들을 통합하는 신규 서비스들이 도입되어 표준화되고 있다. 대표적인 경우로 OMA(Open Mobile Alliance)에서 표준한 OMA CPM(Converged IP Messaging)과 GSMA RCS(Global System for Mobile communication Association Rich Communication Suite)를 들 수 있다. 또한 이러한 메시징 서비스들의 경우 그 서비스들마다 서로 다른 주소록을 사용하므로, 이러한 주소록 관리에 대한 필요성이 대두되었다. 이러한 필요성에 따라 OMA에서는 OMA CAB(OMA Converged Address Book)를 제안하였다. 이 OMA CAB은 향상된 네트워크 주소록으로 다양한 정보를 네트워크 저장소를 활용해서 관리하고, 그룹 간의 정보 공유가 가능한 특징을 가지고 있다.

상기한 바와 같이 새롭게 도입된 신규 서비스들 중 기존 메시징 서비스의 경우 사용자가 그 서비스에 가입했더라도 그 서비스 또는 호환 가능한 다른 서비스에 상대방이 가입되어 있지 않으면, 그 서비스를 통한 대화 및 정보 교환이 어려운 실정이다. 이를 감안하여 RCS 서비스에서는 주소록 관리 기능을 제공하며, RCS 서비스의 가입 여부를 알려주는 기능을 제공할 수 있다. 하지만 RCS 서비스도 다른 서비스와 서로 주소록을 공유하여 사용하지 않으므로, RCS 서비스의 가입 여부가 그 RCS 서비스에서 사용하는 주소록에 한해 제공될 뿐이다. 따라서 메시징 서비스 입장에서는 소셜 네트워크 서비스와 연동한다면 확장된 주소록을 제공받을 수 있어 서비스 가입 여부를 알고자 하는 대상을 확장시킬 수 있을 것이다. 이에 따라 서비스 가입 여부를 알고자 하는 대상을 확장할 수 있는 방법이 요구되는 실정이다.

따라서 본 발명은 서비스 가입 여부를 알고자 하는 대상을 확장시킬 수 있는 메시징 서비스와 소셜 네트워크 서비스 간의 상호 연동을 통한 연락처 제공 장치 및 방법을 제공한다.

상기한 바를 달성하기 위한 본 발명은, 메시징 서비스와 소셜 네트워크 서비스(SNS) 간의 상호 연동을 통해 클라이언트 단말에서 연락처를 제공받는 방법에 있어서, 상기 소셜 네트워크 서비스에서 제공하는 연락처 프로필 리스트를 서버로 요청하는 과정과, 상기 요청에 대응하는 연락처 프로필 리스트 중에서 상기 서버에 의해 필터된 연락처 프로필 리스트를 상기 서버로부터 수신하는 과정과, 상기 수신된 연락처 프로필 리스트의 연락처마다 자신과 동일한 서비스에 가입했는지의 여부를 확인하는 과정을 포함함을 특징으로 한다.

또한 본 발명은, 메시징 서비스와 소셜 네트워크 서비스(SNS) 간의 상호 연동을 통해 연락처를 제공받는 클라이언트 단말에 있어서, 상기 소셜 네트워크 서비스에서 제공하는 연락처 프로필 리스트를 서버로 요청하고, 상기 요청에 대응하는 연락처 프로필 리스트 중에서 상기 서버에 의해 필터된 연락처 프로필 리스트를 상기 서버로부터 수신하고, 상기 수신된 연락처 프로필 리스트의 연락처마다 자신과 동일한 서비스에 가입했는지의 여부를 확인하는 제어부와, 상기 서버와의 요청 및 응답을 송수신하는 I/O 인터페이스와, 상기 수신된 연락처 프로필 리스트를 임시로 저장하는 메모리와, 상기 서버와 동기화된 주소록을 저장하는 주소록 관리부와, 사용자에게 상기 자신과 동일한 서비스의 가입 여부를 알려주는 사용자 인터페이스를 포함함을 특징으로 한다.

또한 본 발명은, 메시징 서비스와 소셜 네트워크 서비스(SNS) 간의 상호 연동을 통해 서버에서 클라이언트 단말로 연락처를 제공하는 방법에 있어서, 상기 소셜 네트워크 서비스에서 제공하는 연락처 프로필 리스트에 대한 클라이언트의 요청 사항을 수신하는 과정과, 상기 수신된 클라이언트의 요청 사항을 검토하는 과정과, 상기 소셜 네트워크 서비스로 연락처 리스트 요청을 전송하는 과정과, 상기 전송에 대응하여 연락처 리스트를 수신하는 과정과, 상기 수신된 연락처 리스트와 기존의 연락처와 비교함으로써 상기 검토한 요청 사항에 대응하는 연락처를 필터하는 과정과, 상기 필터된 연락처를 제공하는 과정을 포함함을 특징으로 한다.

또한 본 발명은, 메시징 서비스와 소셜 네트워크 서비스(SNS) 간의 상호 연동을 통해 클라이언트 단말로 연락처를 제공하는 서버에 있어서, 상기 소셜 네트워크 서비스에서 제공하는 연락처 프로필 리스트에 대한 클라이언트의 요청 사항을 수신하고, 상기 수신된 클라이언트의 요청 사항을 검토하고, 상기 소셜 네트워크 서비스로 연락처 리스트 요청을 전송하고, 상기 전송에 대응하여 연락처 리스트를 수신하고, 상기 수신된 연락처 리스트와 기존의 연락처와 비교함으로써 상기 검토한 요청 사항에 대응하는 연락처를 필터하고, 상기 필터된 연락처를 제공하는 제어부와, 상기 요청을 전송하고, 상기 요청에 대응한 응답을 수신하는 I/O 인터페이스를 포함함을 특징으로 한다.

본 발명에 따르면, 확장된 주소록을 제공받음으로써 서비스 가입 여부를 알고자 하는 대상을 확대시킬 수 있는 이점이 있다. 이에 따라 자신이 가지고 있는 주소록에는 없지만 자동으로 신규 연락처를 제공받을 수 있으므로, 사용자는 주소록에 있는 기존 친구 및 가족뿐만 아니라 본인 프로필과 연관 있지만 아직 모르는 연락처와도 쉽게 연결할 수 있게 된다. 또한 사용자 측면에서는 특정 서비스에 신규 가입했을 때 그 서비스를 바로 이용하는데 편의성을 제공해 준다. 게다가 예를 들어, 서비스 공급자가 가입 초대하면 관심이 없지만, 어느 학교 선배가 본 발명에 제안하는 시스템을 통해 어느 후배 주소를 알게 되어 가입 초대 메시지를 보내면, 후배가 가입할 가능성이 더 크다. 이러한 점을 고려한다면 서비스 공급자 측면에서는, 서비스에 아직 가입되지 않은 사용자들에게 서비스 가입을 더 쉽게 유도할 수 있어서, 서비스 가입자 수가 더 빨리 늘어날 수 있는 효과를 볼 수 있다.

도 1은 본 발명의 실시예에 따른 신규 연락처 제공을 위한 시스템 구성도,
도 2는 본 발명의 실시예에 따른 소셜 네트워크 서비스와의 연동을 통한 연락처 제공 과정을 보인 흐름도,
도 3은 상기 도 2의 응용 서버의 내부블록 구성도,
도 4는 상기 도 2의 응용 서버의 동작 흐름도,
도 5는 상기 도 2의 응용 클라이언트의 내부블록 구성도,
도 6은 상기 도 2의 응용 클라이언트의 동작 흐름도,
도 7은 본 발명에 이용되는 CAB 서비스를 위한 구성도,
도 8은 본 발명에 이용되는 프레전스 인에이블러에서의 동작 흐름도,
도 9a 및 도 9b는 본 발명의 제1실시예에 따른 연락처 제공 과정을 보인 흐름도,
도 10a 및 도 10b는 본 발명의 제2실시예에 따른 연락처 제공 과정을 보인 흐름도,
도 11a 및 도 11b는 본 발명의 제3실시예에 따른 연락처 제공 과정을 보인 흐름도,
도 12a 및 도 12b는 본 발명의 제4실시예에 따른 연락처 제공 과정을 보인 흐름도,
도 13a 및 도 13b는 본 발명의 제5실시예에 따른 연락처 제공 과정을 보인 흐름도,

이하 첨부된 도면을 참조하여 본 발명을 구성하는 장치 및 동작 방법을 본 발명의 실시 예를 참조하여 상세히 설명한다. 하기 설명에서는 구체적인 구성 소자 등과 같은 특정 사항들이 나타나고 있는데 이는 본 발명의 보다 전반적인 이해를 돕기 위해서 제공된 것일 뿐 이러한 특정 사항들이 본 발명의 범위 내에서 소정의 변형이나 혹은 변경이 이루어질 수 있음은 이 기술분야에서 통상의 지식을 가진 자에게는 자명하다 할 것이다. 또한, 본 발명을 설명함에 있어서 본 발명과 관련된 공지 기술에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에 그 상세한 설명을 생략하기로 한다.

후술될 상세한 설명에는 상술한 기술적 과제를 이루기 위한 본 발명에 있어서 대표적인 실시 예를 제시할 것이다. 또한 본 발명의 설명의 편의를 위하여 이동 단말의 어플리케이션의 표준 기구인 OMA(Open Mobile Alliance)의 CAB(Converged Address Book) 및 GSMA(Global System for Mobile communication Association)의 RCS(Rich Communication Suite)에서 정의하고 있는 개체들의 명칭들을 사용할 것이나, 이러한 표준 및 명칭들이 본 발명의 범위를 한정하는 것은 아니며, 유사한 기술적 배경을 가지는 시스템에 적용 가능함은 물론이다.

상기한 바와 같은 기능이 구현된 연락처 제공을 위한 시스템의 구성을 살펴보면, 도 1에 도시된 바와 같다.

도 1을 참조하면, 응용 클라이언트 A(10)는 사용자 단말기에서 동작하는 응용 메시징 서비스 프로그램이다. 응용 클라이언트 A(10)는 사용자 요구사항들을 네트워크에 있는 응용 서버(20)로 전달하고, 응용 서버(20) 또는 서비스 등록 서버(50)로부터 받은 이벤트나 메시지를 사용자에게 알려주는 역할을 한다. 여기서, 응용 메시징 서비스의 일례로, 본 발명의 실시예에서는 RCS 서비스를 예로 들어 설명한다. 이러한 응용 클라이언트 A(10)는 CAB 또는 Presence 클라이언트로서 동작 가능하다.

응용 서버(20)는 응용 클라이언트 A(10)로부터 받은 사용자 요구사항을 수행한다. 또한 SNS 인터워킹(Interworking) 서버(30)나 타네트워크로부터 받은 이벤트나 메시지를 응용 클라이언트 A(10)로 전달한다.

SNS 인터워킹 서버(30)는 응용 서버(20)와 담당하는 SNS 공급자(40)를 연결해 주는 게이트웨이 역할(Gateway)을 하고, 응용 서버(20)와 SNS 공급자(40) 사이간에 적합한 포맷으로 변환해 주는 등 주요한 중간 매체 역할을 한다. 본 발명에 따른 시스템이 실제로 구현될 경우, SNS 인터워킹 서버(30)는 응용 서버(20)와 같은 장소에 주로 배치되거나, 응용 서버(20)의 내부 요소로 포함될 수도 있다.

SNS 공급자(40, 41)는 페이스북(Facebook)이나 트위터(Twitter)와 같은 SNS를 제공해주는 기관들이다.

서비스 등록 서버(50)는 모든 서비스 등록을 처리하고 관리하는 서버다.

상기한 바와 같은 구성의 시스템에서 연락처 제공 과정을 설명하기 위해 도 2를 참조한다. 도 2에서는 사용자 A의 단말 즉, 응용 클라이언트 A(10)는 서비스 M에 가입되어 있으며, 동시에 SNS 서비스에 가입되어 있음을 전제로 한다. 이에 따라 SNS 서비스에 접속 가능한 사용자 A의 로그인과 암호가 존재하며, SNS 인터워킹 서버(30)는 사용자 A를 대신하여 SNS 공급자들(40, 41)에 로그인을 한 상태이고 접속이 가능하다. 만일 SNS 인터워킹 서버(30)가 직접 로그인이 가능하지 않을 경우, 사용자 A에게 우선 응용 클라이언트 A(10)를 통해 SNS 공급자들(40, 41)에 로그인 하도록 요청해서 로그인함을 전제로 한다.

도 2를 참조하면, 201단계에서 응용 클라이언트 A(10)는 응용 서버(20)로 신규 연락처 리스트를 요청한다. 이러한 신규 연락처 리스트의 요청은 사용자 A가 응용 클라이언트 A(10)를 실행하거나 서비스 M에 접속 시 이루어질 수 있다. 이러한 요청은 사용자 A와 특성이 맞는 예컨대, 다른 연락처가 있는 동일한 친구, 같은 학교 졸업 등에 해당하는 연락처가 있는지 알기 위해 해당 조건에 맞는 신규 연락처 프로필 리스트를 요청하기 위함이다. 여기서, 신규 연락처 프로필에는 이름, 메일 주소, 전화번호 등이 포함된다.

그러면 응용 서버(20)는 203단계에서 그 요청을 SNS 인터워킹 서버(30)에게 전달한다. 이에 대응하여 SNS 인터워킹 서버(30)는 205a 및 205b단계에서 응용 서버(20)로부터의 요청에 맞도록 필요한 적어도 하나의 요구 사항을 SNS 공급자(40, 41)들에게 요청을 한다. 그리고나서 207a, 207b단계에서 SNS 공급자들(40, 41)로부터 이러한 요청에 대한 응답을 수신하면, 209단계에서 SNS 인터워킹 서버(30)는 프로필 리스트가 수신되었는지를 판단한다.

구체적으로, 수신된 응답이 응용 서버(20)가 요구한 신규 연락처 프로필 리스트인지를 판단하여, 그 리스트가 아니면 205a 및 205b단계로 돌아가서 SNS 공급자들(40, 41)에게 필요한 그 다음 요청을 하고, 응답에 요구한 신규 연락처 프로필 리스트를 받은 경우, 211단계로 진행한다. 209단계에서 SNS 인터워킹 서버(30)는 예컨대, 연락처 ID 리스트만 받고, 이름, 메일 주소, 전화번호 등의 구체적인 프로필에 대해 제공받지 못한 경우에는 신규 연락처 프로필 리스트가 아니라고 판단하여, 다시 SNS 공급자들(40, 41)에게 요청하는 것이다.

이렇게 신규 연락처 프로필 리스트를 제공받으면, 211단계에서 SNS 인터워킹 서버(30)는 받은 신규 연락처 프로필 리스트를 응용 서버(20)로 전달한다. 그러면 응용 서버(20)는 수신한 각 연락처 프로필에 대해 사용자 A에게 유효한 연락처들만 필터한다. 여기서, 사용자 A의 주소록은 네트워크에도 저장되어 있으며, 응용 서버(20)는 그 주소록에 접속 가능하다. 이에 따라 연락처 필터를 수행할 수 있으며, 이에 대한 구체적인 설명은 도 4에서 후술하기로 한다.

그리고나서 응용 서버(20)는 215단계에서 필터된 연락처 리스트를 응용 클라이언트 A(10)로 보낸다. 그러면 217단계에서 응용 클라이언트 A(10)는, 수신된 연락처마다 서비스 M에 가입되었는지 확인하고 해당사항을 사용자에게 알린다. 이러한 연락처 서비스 등록 확인 및 사용자 알림 과정에 대한 구체적인 설명은 하기 도 6에서 후술하기로 한다.

이후, 어느 연락처가 서비스 M에 가입되었는지 확인하기 위해서는 응용 클라이언트 A(10)는 217a단계에서 서비스 등록 서버(50)에 연락처 등록 서비스 리스트를 요청하면, 217b 단계에서 서비스 등록 서버(50)가 연락처에 대응하여 등록된 서비스 리스트를 보낸다. 이에 따라 사용자 A는 이미 연결된 SNS 친구나, 그 사용자와 특성이 맞는 SNS 연락처를 제공받을 수 있으며, 그 연락처가 서비스 M에 가입되어 있다는 사실과 그 연락처와 서비스를 통해 연결할 수 있는 방법도 제공받을 수 있다. 게다가 제공받은 연락처가 서비스 M에 가입되어 있지 않거나 알 수가 없는 경우, 연락처에 대한 정보만 제공받더라도, 사용자 A는 필요에 따라 그 연락처를 이용하여 그 연락처에 해당하는 상대방 클라이언트로 서비스 M 가입 초청 메시지를 보낼 수도 있다.

이하, 연락처에 대한 필터를 수행하는 응용 서버의 동작을 살펴보기에 앞서 그 내부 구성은 도 3에 도시된 바와 같다.

도 3은 응용 서버(20)의 내부 블록 구성을 예시하고 있는데, 제어부(301)는 응용 서버(20)의 모든 동작을 제어하며, 다른 내부 구성 요소들과 연결해 어느 시점에 무엇을 수행해야 하는지 알려주는 역할을 한다. I/O 인터페이스(interface)(303)는 다른 시스템 요소들과 정보를 보내거나 받을 때 사용되며, 메모리(305)는 응용 서버(20)가 모든 동작을 수행할 때 처리 데이터가 임시로 저장되는 곳이다. 또한 주소록 관리부(307)은 사용자의 기존 연락처 정보를 저장하며, 응용 클라이언트(10)에 사용되는 주소록(507)과 동기화된 주소록을 저장하는 역할을 한다. 맵핑 테이블 관리부(309)는 메일 주소나 전화번호와 같은 기존 주소/번호를 서비스 M에 사용되는 특정 주소 예컨대, SIP URI로 변환해 준다. 이러한 주소록 관리부(307) 및 맵핑 테이블 관리부(309)는 본 발명에서 제안하는 실시예에 따라 응용 서버(20)로부터 분리되어 구현될 수 있다.

상기한 바와 같이 구성된 응용 서버(20)는 하기 도 4에서와 같은 연락처에 대한 필터를 수행한다. 이러한 필터의 수행은 응용 서버(20)의 제어부(301)의 제어하에 이루어진다.

도 4를 참조하면, 401단계에서 제어부(301)는 I/O 인터페이스(303)를 통해 수신한 연락처 프로필 리스트를 메모리(305)에 저장한다. 403단계에서 제어부(301)는 메모리(305)에 저장된 프로필에서 연락처 식별 가능한 데이터 예컨대, 이름, 메일 주소, 전화번호 등을 추출한다. 그리고나서 405단계에서 추출된 데이터와 주소록 관리부(307)에 있는 해당 데이터들과 비교해 이미 주소록에 존재하는 연락처인지 판단한다. 판단 결과 그 주소록에 존재하는 연락처로 판단되는 경우 407단계에서 서비스 M에 이미 가입되어 있는지를 판단한다. 구체적으로, 그 존재하는 연락처에 대해 서비스 M에 가입되어 있다는 표시가 주소록 관리부(307)에 있는지 판단한다. 만일 서비스 M에 이미 가입되어 있다고 판단되면, 제어부(301)는 409단계에서 프로필을 삭제한다. 이때, 서비스 M에 이미 가입되어 있다고 판단되면, 그 연락처가 서비스 M에 가입되어 있다는 사실을 사용자 A도 이미 알고 있다는 뜻이다. 따라서 이 연락처에 대해서는 더 이상 진행할 필요 없으므로, 연락처에 대한 프로필을 메모리(305)에서 삭제하는 것이다.

405단계에서 그 주소록에 존재하는 연락처가 아니거나 407단계에서 서비스에 이미 가입된 경우가 아니라면, 411단계에서 서비스 M에서 사용 가능한 주소가 있는지를 판단한다. 구체적으로, 주소록 관리부(307)에 그 연락처에 대응하여 서비스 M에서 사용 가능한 주소(이하, 서비스 M 주소)가 있는지 알아본다. 따라서, 주소록 관리부(307)에 존재하는 연락처가 아니거나 서비스 M 주소 예컨대, SIP URI가 없는 경우 맵핑 테이블 관리부(309)에 접속해 403단계에서 추출된 연락처의 메일 주소나 전화번호에 매칭되는 서비스 M 주소가 있는지 확인한다. 예를 들어, RCS 서비스 경우, SIP URI 주소가 사용 가능하지만 여러 서비스가 SIP URI 주소를 사용하기 때문에, SIP URI 주소가 있다고 해도 연락처가 반드시 RCS 서비스에 가입되었다는 것은 아니다.

따라서 하기와 같은 방법을 통해 알 수 있으며, 그 방법은 상황에 따라 선택적으로 이용된다. 그 방법을 설명하면 다음과 같다. 맵핑 테이블 관리부(309)에 매칭되는 연락처의 서비스 M 주소가 없지만, 연락처에 해당하는 상대방 클라이언트가 다른 네트워크 가입자여서 다른 네트워크에 있는 서버가 알 가능성 있는 경우, I/O 인터페이스(303)를 통해 타 네트워크 서버에 연락처의 프로필을 전달하고, 매칭되는 서비스 M 주소를 요구할 수 있다. 타 서버로부터 받는 응답을 I/O 인터페이스(303)를 통해 수신하고, 매칭되는 서비스 M 주소를 응답에 포함되어 있는 경우, 서비스 M 주소를 연락처 메일 주소 및 전화번호와 함께 맵핑 테이블 관리부(309)에 추가한다.

상기 방법들을 통해 연락처의 서비스 M 주소가 있는 경우, 연락처에 해당하는 상대방 클라이언트가 서비스 M에 가입할 가능성이 있으므로 413단계에서 연락처 프로필에 서비스 M 주소를 추가한다. 이와 달리 연락처의 서비스 M 주소가 없거나 알 수 없는 경우, 415단계로 진행하여 검토해야 할 연락처 프로필이 더 있는지를 판단하여, 검토할 연락처가 더 있는 경우 403단계로 되돌아가 전술한 과정을 반복 수행하고, 더 이상 검토할 프로필이 없는 경우, 내부 필터 동작을 종료한다

한편, 연락처 서비스 등록확인 및 사용자 알림 동작을 수행하는 응용 클라이언트 A의 동작을 살펴보기에 앞서 그 내부 구성을 살펴보면 도 5에 도시된 바와 같다.

도 5를 참조하면, 제어부(501)는 응용 클라이언트 A(10)의 모든 동작을 제어하는 요소로, 다른 내부 구성 요소들과 연결해 어느 시점에 무엇을 수행해야 하는지 알려주는 역할을 한다. I/O 인터페이스(503)는 다른 시스템 요소들과 정보를 보내거나 받을 때 사용되는 인터페이스이다. 메모리(505)는 응용 클라이언트 A(10)가 모든 동작을 수행할 때 처리 데이터가 임시로 저장되는 곳이다. 주소록 관리부(507)는 사용자의 기존 연락처 정보를 담은 저장소로서, 응용 서버(20)에 사용되는 주소록(307)과 동기화되어 있다. 사용자 인터페이스(509)는 사용자의 모든 정보를 보여줄 때나 사용자가 정보를 입력할 때 사용되는 인터페이스이다.

상기한 바와 같이 구성된 응용 클라이언트 A(10)는 하기 도 6에서와 같은 연락처 서비스 등록확인 및 사용자 알림 동작을 수행한다. 이러한 동작은 응용 클라이언트 A(10)의 제어부(501)의 제어하에 이루어진다.

도 6을 참조하면, 제어부(501)는 601단계에서 I/O 인터페이스(503)를 통해 수신한 필터된 연락처 프로필 리스트를 메모리(505)에 저장한다. 그리고나서 603단계에서 메모리(505)에 저장된 연락처 프로필에서 서비스 M 주소가 있는지 확인한다. 판단 결과 서비스 M 주소가 있는 경우 연락처가 서비스 M에 가입될 가능성이 있으므로, 제어부(501)는 605단계에서 연락처 프로필을 "가입 리스트"에 추가한 후, 메모리(505)에 저장한다. 이와 달리 서비스 M 주소가 없는 경우 그 연락처가 서비스 M에 가입될 가능성이 없거나 알 수가 없다. 이에 따라 제어부(501)는 연락처 프로필을 “미가입 리스트”에 추가하고 메모리(505)에 저장한다.

그리고나서 609단계에서 수신된 리스트에 검토할 프로필이 더 있는지를 판단하고, 검토할 프로필이 더 있는 경우 603단계로 되돌아가 전술한 과정을 반복 수행하며, 검토할 프로필이 더 이상 없는 경우 611단계로 진행한다. 611단계에서 제어부(501)는 메모리(505)에 저장된 “가입 리스트”에 있는 연락처들을 I/O 인터페이스(503)를 통해 서비스 등록 서버(50)에게 보내고, 각 연락처의 등록된 서비스 가입 리스트를 요청한다. 이러한 요청에 대응하여 613단계에서 I/O 인터페이스(503)를 통해 서비스 등록 서버(50)로부터 각 연락처에 대응하여 등록되어 있는 서비스 리스트를 수신한다. 즉, 연락처들에 해당하는 각 상대방 클라이언트가 등록한 서비스에 대한 리스트를 수신한다.

615단계에서 제어부(501)는 연락처 서비스 리스트에 서비스 M이 있는지 확인한다. 만일 서비스 M이 없는 경우 617단계에서 연락처가 서비스 M에 가입되어 있지 않으므로, 메모리(505)에 저장된 연락처를 “가입 리스트”에서 “미가입 리스트”로 이동시킨다. 그리고나서 619단계에서 수신된 연락처 프로필 리스트에 검토할 프로필이 더 있는지를 판단하고, 검토할 프로필이 더 있는 경우 615단계로 되돌아가 되돌아가 상기 과정을 반복 수행한다. 이와 달리 검토할 프로필이 더 이상 없는 경우 621단계에서 메모리(505)에 저장된 “가입 리스트”와 “미가입 리스트” 연락처들을 사용자 인터페이스(509)를 통해 사용자 A에게 알린다.

여기서, “가입 리스트” 연락처들의 경우, 응용 클라이언트 A(10)는 사용자 A에게 해당 연락처가 같은 서비스 M을 사용한다는 사실을 알리고, 주소록 관리부(507)에 연락처를 추가하는 방법과 그 연락처와 서비스 M을 통해 연결할 수 있는 방법을 제공해준다. “미가입 리스트” 연락처들의 경우, 응용 클라이언트 A(10)는 사용자 A에게 해당 연락처가 존재한다는 사실을 알리고, 주소록 관리부(507)에 연락처를 추가하는 방법과 그 연락처에게 서비스 M에 가입 초대 메시지를 보낼 수 있는 방법을 제공해준다.

이하, 응용 클라이언트 A(10)의 사용자가 가입한 서비스 M이 RCS라고 가정했을 경우 그 RCS는 다수의 인에이블러들(enablers)의 조합과 프로파일링(profiling)을 통해 서비스를 제공한다. 본 발명의 실시예에서는 이러한 RCS 서비스를 SNS 서비스와 연동함으로써 서비스 가입 여부를 알고자 하는 대상을 확장시킬 수 있도록 한다. 이러한 RCS는 주소록 통합 기능을 제공하는 인에이블러의 일례인 OMA(Open Mobile Alliance)의 CAB(Converged Address Book)과 OMA 프렌전스(Presence) 바탕으로 제공될 수 있다.

이에 따라 도 2에서의 응용 클라이언트 A(10)는 신규 연락처를 제공받기 위해 CAB 클라이언트로 동작할 수 있으며, 제공된 신규 연락처를 이용하여 그 신규 연락처에 해당하는 클라이언트의 서비스 가입 여부를 제공받기 위해 프레전스 클라이언트로도 동작할 수 있다. 따라서 본 발명에 따른 SNS 서비스와의 연동을 통한 연락처 제공 시스템은 CAB과 OMA 프레전스 인에이블러(Presence Enabler)를 기반으로 구현될 수 있다.

상기와 같은 본 발명을 설명하기에 앞서, 본 발명에서 이용되는 일반적인 CAB 시스템의 구성을 살펴보기 위해 도 7을 참조한다.

도 7을 참조하면, CAB Client(71)는 사용자 단말기에 있는 주소록을 관리 및 제어해주는 응용 프로그램이다. CAB Server(72)는 CAB Client(71)로부터 받은 사용자의 다양한 요구사항을 수행하는 네트워크 주요 요소이다. CAB AB((Address Book) XDMS(XML Document Management Server)(73)는 사용자의 주소록을 저장 및 관리해 주는 서버이다. CAB PCC(Personal Contact Card) XDMS(74)는 사용자의 프로필을 저장 및 관리해 주는 서버이다. CAB UP(User Preferences) XDMS(75)는 사용자의 선호도 및 특정 요구 사항들을 저장 및 관리해 주는 서버이다. Non-CAB Address Book Systems(76)는 CAB 서비스에서 사용하는 주소록 시스템과 다른 모든 주소록 시스템들을 포함하며, 예를 들어, vCard 등이 이에 해당한다. 본 발명에서는 도 2에 설명한 SNS 공급자(40, 41)들도 이 시스템에 포함된다고 가정할 수 있다.

본 발명에 사용되는 인터페이스들과 프로토콜/기술들은 다음과 같다:

CAB-1 인터페이스는 CAB Client(71)에 있는 주소록과 CAB AB XDMS (73)에 저장된 주소록 사이에 동기화 하고자 할 때 CAB Server(72)를 거쳐서 우선 동기화 되는데 사용된다. 또한 CAB Server(72)가 CAB Client(71)에게 두 주소록 사이에 변경이 있다고 알릴 때 사용된다. 프로토콜/기술로는 SyncML[3]이 사용된다.

SIC-1 인터페이스는 CAB PCC XDMS(74)와 CAB User Preferences XDMS(75)에 저장된 데이터들이 변경될 때마다 CAB Client(71)에게 변경 사항들을 알려줄 때 사용된다. 참고로, CAB AB XDMS(73) 변경 사항 알림은 상기 CAB-1 인터페이스가 사용된다. 프로토콜/기술로는 SIP(Session Initiation Protocol)-Specific Event Notification [4]가 사용된다.

SIC-2 인터페이스는 CAB AB XDMS(73), CAB PCC XDMS(74)와 CAB User Preferences XDMS(75)에 저장된 데이터들이 변경될 때마다 CAB Server(71)에게 변경 사항들을 알려줄 때 사용된다. 프로토콜/기술로는 SIP (Session Initiation Protocol)-Specific Event Notification [4]가 사용된다.

XDM-3i 인터페이스는 CAB Client(71)가 CAB PCC XDMS(74)와 CAB User Preferences XDMS(75)에 저장된 데이터를 관리할 때 사용된다. 프로토콜/기술로는 XCAP/HTTP(XML Configuration Access Protocol / Hyper Text Transfer Protocol)[5]가 사용된다.

XDM-4i 인터페이스는 CAB Server(72)가 CAB AB XDMS(73), CAB PCC XDMS(74)와 CAB User Preferences XDMS(75)에 저장된 데이터를 관리할 때 사용된다. 프로토콜/기술로는 XCAP/HTTP(XML Configuration Access Protocol / Hyper Text Transfer Protocol)[5]가 사용된다.

또한, 본 발명에 이용되는 일반적인 프레전스 인에이블러에서의 동작 흐름도는 도 8과 같다. OMA 프레전스 인에이블러에서 사용자가 다른 사용자가 사용하는 서비스에 대해 알고자 할 때 도 8과 같은 동작을 수행한다. 그 동작 흐름은 SIP -Specific Event Notification [4] 프로토콜을 통해 이루어진다.

도 8을 참조하면, Presence 클라이언트(81)는 페처(fetcher)로서, 타 사용자가 프레전스 서버(84)에 등록한 프레전스(Presence) 정보를 받기 위해 801단계에서 SIP SUBSCRIBE를 보낸다. 이때, 프레전스 정보를 한번만 받기 위해서 SIP SUBSCRIBE안에 “Expires” header를 0으로 설정한다. 이와 달리 주기적으로 변경 사항을 받기 위해서는 “Expires” header를 더 높은 값으로 설정한다. SIP SUBSCRIBE는 803단계 및 805단계에서 SIP 기반 하부 전송 네트워크에 해당하는 Fetcher SIP/IP Core(82)와 프레전스 서버(84) 쪽에 있는 Presentity SIP/IP Core(83)를 거쳐서 Presence 서버(84)로 전달된다.

807단계에서 Presence 서버(84)는 Presence 클라이언트(81)가 요청한 정보를 받을 수 있는지를 판단하기 위해 인증 체크(authorization check)를 수행한다. 만일 요청을 허락하는 경우 809단계 내지 813단계에서 Presence 서버(84)는 200 OK를 SIP/IP Cores(82, 83)를 거쳐 Presence 클라이언트로 전달한다. 그리고나서 815단계 내지 819단계에서 Presence 서버(84)는 요청한 정보를 SIP NOTIFY에 포함해 SIP/IP Cores(82, 83)를 거쳐 Presence 클라이언트(81)로 전달한다. 이에 대응하여 821단계 내지 825단계에서 Presence 클라이언트(81)는 200 OK를 통해 Presence 정보 수신 확인을 SIP/IP Cores(82, 83)를 거쳐 Presence 서버(84)로 전달한다.

이하, 본 발명의 실시예에 따른 도 2의 흐름을 상기한 바와 같은 도 7 및 도 8을 기반으로 재구성했을 경우를 구체적으로 설명하기로 한다. 본 발명의 실시예들에 따라 도 7 및 도 8 기반의 재구성된 RCS 서비스와 SNS 서비스와 연동하는 시스템의 구성은 도 9a 내지 도 13b에서와 같이 구현될 수 있다. 여기서, 도 9b, 도 10b, 도 11b, 도 12b, 도 13b는 각각 도 9a, 도 10b, 도 11b, 도 12b, 도 13b에 이어지는 흐름도이다.

먼저, 도 9a 및 도 9b는 본 발명의 제1실시예에 따른 연락처 제공 과정을 보인 흐름도이다. 도 9a 및 도 9b에서는 도 2의 응용 서버(20)와 SNS 인터워킹 서버(30)가 통합 구현된 경우를 예시하며, 설명의 편의를 위하여 라우팅 및 기타 목적을 위한 요소들 예컨대, SIP/IP Cores, IMS, Aggregation Proxy 등은 생략되어 있지만, 필요에 따라 그 요소들을 거쳐간다고 가정할 수 있다. 또한 이하의 도면에서는 도 2의 RCS 서비스를 CAB 서비스의 구성을 바탕으로 재구성된 것이므로, RCS는 CAB에서 사용되는 명칭으로 대체될 수 있으며 설명의 편의를 위해 RCS와 CAB를 병행하여 표기한다. 마찬가지로 도 2의 SNS도 Non-RCS와 병행하여 표기할 수 있다.

도 9a를 참조하면, 사용자 A가 RCS 서비스에 접속 시, RCS(CAB) 클라이언트 A(71)는 신규 연락처 제안 리스트를 받기 위해 요청에 대한 자세한 정보를 CAB XDMS(75)가 관리하는 “CAB Feature Handler”라는 문서에 저장하도록 요청한다. 이를 위해 901단계에서 "Get Contact suggestions" 요청이 XCAP/HTTP PUT 형태로 CAB XDMS들 중 CAB User Preferences XDMS(75)로 전달된다. “CAB Feature Handler”문서에 대한 상세 설명은 후술하기로 한다.

903단계에서 CAB User Preferences XDMS(75)는 관리하는 “CAB Feature Handler”문서에 요청 사항을 저장하고, 저장 완료 응답인 200 OK를 RCS(CAB) 클라이언트 A(71)로 보낸다. 그리고나서 905단계에서 CAB User Preferences XDMS(75)는 “CAB Feature Handler”문서에 저장된 RCS(CAB) 클라이언트 A(71)의 요청 사항과 정보를 RCS (CAB) 서버(72)에게 알린다. 이러한 알림을 위해 SIP NOTIFY 메시지가 이용된다. 그러면 907단계에서 RCS(CAB) 서버(72)는 알림을 수신하고 확인 메시지인 200 OK를 CAB User Preferences XDMS(75)로 보낸다. 이어, 909단계에서 RCS(CAB) 서버(72)는 요청 사항을 검토하고 Non-RCS(CAB) 주소록 시스템(Address Book Systems)(76)에게 적합한 포맷으로 변환해 Non-RCS(CAB) 연락처 리스트를 요청한다. 여기서, Non-RCS(CAB) 주소록 시스템은 SNS 공급자에 해당된다. 또한 도 9a 및 도 9b에서는 하나의 SNS 공급자에 해당하는 Non-RCS(CAB) 주소록 시스템을 예시하였으나, SNS 공급자가 복수일 경우 그 복수의 SNS 공급자로부터 연락처 리스트들을 받아 RCS(CAB) 서버(72)에서 취합할 수도 있음은 물론이다.

따라서 911단계에서 Non-RCS(CAB) 주소록 시스템(76)은 요청한 Non-RCS(CAB) 연락처 리스트를 RCS(CAB) 서버(72)로 보낸다. 이때, 필요한 리스트를 정확하게 받기 위해 상기 909단계와 911단계가 반복 수행될 수 있다. 913단계에서 RCS(CAB) 서버(72)는 받은 Non-CAB 연락처 리스트를 RCS(CAB) 포맷으로 변환한다. 915단계에서 RCS(CAB) 서버(72)는 네트워크에 저장된 사용자 A의 기존 주소록을 CAB AB XDMS (73)에게 요청한다. 이러한 요청을 위해 XCAP/HTTP GET가 사용될 수 있다. 이에 대응하여 917단계에서 CAB AB XDMS(73)은 요청한 사용자 A의 주소록을 포함하는 200 OK를 RCS(CAB) 서버(72)에게 보낸다. 여기서, RCS(CAB) 서버(72)는 도 2의 응용 서버(20)와 SNS 인터워킹 서버(30)의 기능을 수행한다.

이에 따라 RCS(CAB) 서버(72)는 919단계에서 사용자 A의 기존 연락처와 Non-RCS(CAB) 주소록 시스템(76)으로부터 받은 신규 연락처 프로필들을 비교함으로써 연락처들을 필터한다. 이러한 연락처 필터에 대한 동작은 전술한 도 4에 따라 이루어진다. 이렇게 필터된 연락처는 921단계에서 CAB User Preferences XDMS(75)에 저장되며, 이러한 저장 요청을 위해 XCAP/HTTP PUT이 이용된다. 923단계에서 CAB User Preferences XDMS(75)는 수신한 연락처 프로필들을 저장하고 확인 응답으로 200 OK를 RCS(CAB) 서버(72)로 보낸다.

또한 925단계에서 CAB User Preferences XDMS(75)는 신규 연락처 프로필들이 저장되어 있다는 사실을 RCS(CAB) 클라이언트 A(71)에게 알리고 프로필들을 보낸다. 이러한 프로필을 보내기 위해 SIP NOTIFY 메시지가 이용된다. 이러한 수신된 프로필은 RCS(CAB) 클라이언트 A(71)가 901단계에서 보낸 요청에 대한 응답이 된다. 그러면 927단계에서 RCS(CAB) 클라이언트 A(71)는 수신한 알림에 대해 확인 메시지를 CAB User Preferences XDMS(75)에게 보낸다.

이와 같이 RCS(CAB) 클라이언트 A(71) 입장에서는 Non-RCS 공급자 즉, SNS 공급자와의 연동을 통해 서비스 가입 여부를 알고자 하는 대상의 확장할 수 있게 된다. 이를 위해 929단계에서 수신한 프로필에서 SIP 주소가 있는 연락처를 추출한다. 구체적으로, 전술한 도 6에 따라 수신한 연락처 프로필들 중 RCS 서비스에 사용할 수 있는 주소 즉, SIP URI가 있는지 확인하고 그 연락처들을 추출한다. 그리고나서 931단계에서 RCS(CAB) 클라이언트 A(71)는 SIP 연락처 주소들을 바탕으로 RCS(Presence) 클라이언트 A(71)를 통해 사용 가능한 서비스 리스트를 나타내는 각 SIP 연락처의 “service capability information”를 RCS(Presence) 서버(84)에게 요청한다. 이러한 요청을 위해 SIP SUBSCRIBE 메시지가 이용된다. 여기서, RCS(CAB) 클라이언트 A(71)와 RCS(Presence) 클라이언트 A(71)는 도 2의 응용 클라이언트 A(10)에 해당하며 동일한 사용자 단말기에 설치된 응용 프로그램이다. 다만, 본 발명에서는 연락처를 요청하는 경우에는 RCS(CAB) 클라이언트로서 동작하므로, RCS(CAB) 클라이언트 A(71)라고 지칭하는 것이며, 서비스 가입 여부를 요청하는 경우에는 RCS(Presence) 클라이언트로서 동작하므로, RCS(Presence) 클라이언트 A(71)라고 지칭하는 것이다.

그러면 RCS(Presence) 서버(84)는 RCS(Presence) 클라이언트 A(71)가 요청한 정보를 받을 수 있는지 판단하기 위해 인증 체크(authorization check)을 검토하고, 요청을 수락하는 경우 933단계에서 수락 메시지인 200 OK를 RCS(Presence) 클라이언트에게 전달한다. 또한 935단계에서 RCS(Presence) 서버(84)는 요청한 연락처들의 “service capability information”를 RCS(Presence) 클라이언트 A(71)에게 SIP NOTIFY 메시지를 이용하여 전달한다. 이러한 메시지를 수신한 RCS(Presence) 클라이언트 A(71)는 937단계에서 “service capability information”의 수신 확인인 200 OK를 RCS(Presence) 서버(84)에게 전달한다.

그리고나서 939단계에서 RCS(CAB) 클라이언트 A(71)는 RCS(Presence) 클라이언트 A(71)를 통해 각 연락처들의 “service capability” 정보를 도 6의 615단계 내지 621단계에 따라 RCS 사용자인지의 여부를 검토하고 사용자에게 알린다.

상기한 바와 같이 본 발명의 제1실시예에서는 RCS(CAB) 서버가 필터링 기능 및 인터워킹 기능 모두를 수행하며, 필터된 연락처가 별도로 CAB User Preferences XDMS(75)에서 관리하는 “CAB Feature Handler”라는 문서에 저장되는 경우를 예로 들어 설명하였다. 하지만 다르게는 필터된 연락처는 “CAB Feature Handler” 문서가 아닌 RCS 클라이언트A(71)가 가지고 있는 주소록에 포함되어 저장될 수도 있으며, 이러한 본 발명의 제2실시예에 따른 구성은 도 10a 및 도 10b에 도시된 바와 같다.

본 발명의 제2실시예를 설명하기에 앞서, “CAB Feature Handler”라는 문서에 들어가는 내용을 살펴보면 다음과 같다.

본 발명에서는 <contact_suggestions>이라는 element를 정의한다. <contact_suggestions> element는 RCS(CAB) 클라이언트 A(71)가 신규 연락처 제안 리스트를 받고자 할 때 “CAB Feature Handler” 문서에 포함하는 element이다. 이러한 element의 하위 레벨은 <non-CAB source>, <credentials>, <criteria>, <scheduled-interval>, <max-suggestions>, <id>, <code>, <phrase>, <contact_suggestion_response> 등의 element들로 구성되어 있다.

먼저, <non-CAB source>는 어느 기관으로부터 신규 연락처 제안을 받고 싶은지 기재하기 위한 element로서, 예컨대, domain name이 기재된다. 이 element가 없는 경우, 서비스 공급자 정책에 따라서 정해진다.

<credentials>는 상기 기관에 접속할 때 인증을 위한 필요한 정보들을 의미한다. <credentials>의 하위 레벨에는 로그인 정보가 기재되는 <username>와 암호가 기재되는 <password> 등의 element가 속해있다.

<criteria>는 <preferences> 또는 <keywords>로 대체될 수 있으며, 신규 연락처 제안을 무슨 기준으로 선택할지 설정하는 데 이용된다. 이 element의 하위 레벨에는 <friend-of-friend>, <same-school>, <same-work>, <same-hobby> 등의 element로 구성될 수 있다.

먼저, <friend-of-friend> 는 <mutual-friend>이라고도 하며, 상기 기관에 있는 사용자 주소록의 등록된 연락처들의 연락처들을 받고 싶을 때 예컨대, 사용자 친구의 친구들의 연락처를 받고 싶을 때 “1”로 설정된다.

<same-school>에는 같은 학교에 다닌 연락처 제안을 받고 싶을 때 해당 학교 이름이 기재된다.

<same-work>에는 같은 직업을 다닌 연락처 제안을 받고 싶을 때 해당 회사나 직업 종류 이름을 기재한다.

<same-hobby>에는 같은 취미를 갖고 있는 연락처 제안을 싶을 때 해당 취미를 기재한다.

상기 하위 elements들은 예제일 뿐이고, <criteria> (또는 <preferences>, <keywords>)element 에 찾고자 하는 키워드들을 직접 입력할 수도 있다. 또한 <criteria>도 기재하지 않는 경우, RCS(CAB) 서버(72)가 사용자 프로필 (CAB PCC XDMS (74))에 접속해 사용자 프로필과 서비스 공급자 정책에 따라서 정해질 수 있다.

<scheduled-interval>에는 한번만 받는게 아니라 주기적으로 연락처 제안을 받고자 할 때, 여기에 제안 시간 간격을 기재한다.

<max-suggestions>에는 최대 몇 명의 연락처들을 제안 받고 싶은지 연락처 수를 설정한다.

<id>는 각 요청을 식별하는 ID이다.

상기에 설명한 <contact_suggestions> element는 <cab_feature>의 속하는 하위 레벨 element이다. <cab_feature> element의 하위 레벨에는 <response>이라는 element도 포함된다. <response> element는 전술한 921단계에서처럼 RCS(CAB) 서버(72)가 RCS(CAB) 클라이언트 A(71)가 요청에 응답할 때 채우는 element이다. <response> element의 하위 레벨은 다음 elements들이 포함된다:

<code>는 응답에 대한 상태 코드로, 응답이 성공적으로 실행됐는지 아니면 실패된 상황에 따라 해당 상태 코드(status code)가 기재된다.

<phrase>는 응답에 대한 high-level 문장이다

<contact_suggestions_response>에는 상기에 설명한 <contact_suggestions> 요청 관련 상세 응답을 기재한다. 여기서 신규 연락처 제안 정보들이 실려있으며, 각 연락처에 대한 자세한 정보 구조는 OMA CAB에서 정리한 구조를 따른다.

상기 본 발명의 제1실시예에서는 <contact_suggestions_response>가 신규 연락처 제안요청 정보와 같은 문서에 들어 있다고 가정하지만, 다른 문서에 따로 기재될 수도 있다.

한편, 본 발명의 제2실시예에서는 RCS 클라이언트A(71)가 가지고 있는 주소록에 필터된 연락처가 포함되어 저장되는 경우를 설명하며, 이를 위해 도 10a 및 도 10b를 참조한다.

도 10a의 1001단계 내지 1019단계는 도 9a의 901단계 내지 919단계에서의 동작과 동일하다. 다만, 본 발명의 제2실시예에서는 CAB Address Book XDMS(73)에 필터된 연락처들이 저장된다. 이에 따라 1021단계에서 RCS(CAB) 서버(72)는 필터된 연락처들을 CAB Address Book XDMS(73)에 저장하도록 요청한다. 이러한 요청을 위해 XCAP/HTTP PUT가 이용된다. 이때, 사용자 주소록에 바로 저장할 수도 있겠지만, 다른 별도 문서에 저장될 수도 있다.

그러면 1023단계에서 CAB Address Book XDMS(73)는 수신한 연락처 프로필들을 저장하고 확인 응답인 200 OK를 RCS(CAB) 서버(76)로 보낸다. 1025단계에서 RCS(CAB) 서버(72)는 주소록이 변경되었다는 사실을 RCS(CAB) 클라이언트 A(71)에게 알린다. 이러한 알림을 위해 OMA DS가 이용된다. 이어, 도 10b의 1027단계에서 RCS(CAB) 클라이언트 A(71)는 주소록 동기화를 RCS(CAB) 서버(72)와 실시하고, 동기화를 통해 신규 제안 연락처들을 함께 받는다. 이하, 도 10b의 1029단계 내지 1039단계는 도 9b의 929단계 내지 939단계에서의 동작과 동일하다. 단, 주소록에 직접 저장된 경우, 연락처가 RCS를 사용하지 않거나, 또한 사용자 성향 및 선택에 따라서 추가된 연락처 제안을 주소록에서 삭제할 수 있다.

한편, 본 발명의 제3실시예에서는 본 발명의 제2실시에서의 연락처 필터단계 및 필터된 연락처 리스트를 CAB User Preferences XDMS(75)에 저장하는 단계를 RCS(CAB) 서버(72)가 수행하지 않고, CAB AB XDMS(74)가 대신 수행하는 경우에 관한 것이다. 본 발명의 제3실시예를 설명하기 위해 도 11a 및 도 11b를 참조한다.

도 11a의 1101단계 내지 1113단계는 도 9a의 901단계 내지 913단계에서의 동작과 동일하다. 다만, CAB Address Book XDMS(73)에서 연락처를 필터하고 CAB User Preferences XDMS(75)에 저장하는 동작을 수행한다. 이에 따라 1115단계에서 RCS(CAB) 서버(72)는 변환된 연락처들을 CAB Address Book XDMS(73)에 저장하도록 요청하며, 이러한 요청을 위해 XCAP/HTTP PUT이 이용된다. 그러면, 1117단계에서 CAB Address Book XDMS(73)는 수신한 연락처 프로필들을 저장하고 확인 응답으로 200 OK를 RCS(CAB) 서버(72)로 보낸다. 1119단계에서 CAB Address Book XDMS(73)는 도 4에 설명한 동작을 따라서 사용자 A의 기존 연락처와 RCS(CAB) 서버(72)로부터 받은 (변환한) 신규 연락처 프로필들을 비교함으로써 연락처들을 필터한다.

그리고나서 1121단계에서 CAB Address Book XDMS(73)는 필터된 연락처들을 CAB User Preferences XDMS(75)에 저장한다. 이때, 필터된 연락처들의 저장 동작은 CAB XDMS 내부 요소들간에 이루어지는 동작이므로, 별도 프로토콜이나 수신 확인 메시지를 사용하지 않는다. 상기한 바 이외의 도 11a 및 도 11b에서의 1125단계 내지 1139단계는 도 9a 및 도 9b의 925단계 내지 939단계에서의 동작과 동일하다.

한편, 본 발명의 제4실시예에서는 본 발명의 제1실시예에서의 연락처 필터단계와 SIP 연락처 추출 및 “service capability information” 요청 단계를 RCS(CAB) 서버(72)가 미리 함께 다 수행하는 경우에 관한 것이다. 본 발명의 제4실시예를 설명하기 위해 도 12a 및 도 12b를 참조한다. 이에 따라 도 12a의 1201단계 내지 1219단계는 도 9a의 901단계 내지 919단계에서의 동작과 동일하다. 또한 도 12a의 1221단계 내지 도 12b의 1229단계는 도 9b의 929단계 내지 937단계에서의 동작과 동일하지만, 이 동작들을 RCS(Presence) 클라이언트(81) 가 수행하는 게 아니라 RCS(CAB) 서버(72)가 수행한다. 따라서 Presence 클라이언트 A(81) 역할을 하는 프레전스 기능이 RCS(CAB) 서버(72) 내부에 포함되었다고 가정한다.

또한, 도 12b의 1231단계 내지 1237단계는 도 9a의 921단계 내지 927 단계에서의 동작과 동일하다. 단, 1231단계에서 저장하는 제안 연락처 프로필에는 상기 1231단계 내지 1237단계의 결과에 따라 각 연락처가 RCS(CAB) 서비스 가입 여부에 대한 표시가 포함되어 있다. 그리고나서 1239단계에서 RCS(CAB) 클라이언트(71)는 수신한 연락처 정보를 따로 분석할 필요 없이 사용자에게 제안한다.

한편, 전술한 본 발명의 제4실시예에서는 모든 분석 및 필터 단계를 RCS(CAB) 서버(72)가 미리 다 수행하는 경우를 예로 들어 설명했지만, 본 발명의 제5실시예에서는 반대로 RCS(CAB) 서버(72)가 미리 수행하지 않고 나중에 RCS(CAB/Presence) 클라이언트(71)가 다 수행하도록 구현할 수도 있다. 이러한 본 발명의 제5실시예를 설명하기 위해 도 13a 및 도 13b를 참조하여 설명한다.

도 13a의 1301단계 내지 1313단계는 도 9a의 901단계 내지 913단계에서의 동작과 동일하다. 또한, 1315단계 내지 1321단계에도 도 9a의 921단계 내지 927단계에서의 동작과 동일하지만, 도 9a의 921단계에서 저장되는 연락처들은 RCS(CAB)포맷으로 변환되었지만 1315단계에서는 아직 추가 분석 및 필터 되지 않은 상태로 CAB User Preferences XDMS(75)에 저장된다. 또한 도 13b의 1323단계는 도 9a의 919단계에서의 동작과 동일하지만, 그 동작을 RCS(CAB) 서버(72)가 수행하는 게 아니라 RCS(CAB) 클라이언트(71)가 내부에 있는 주소록(507)에 있는 연락처들과 비교함으로써 필터를 수행한다. 이하, 도 13b의 1325단계 내지 1335단계는 도 9b의 929단계 내지 939단계에서의 동작과 동일하다.

Claims

메시징 서비스와 소셜 네트워크 서비스(SNS) 간의 상호 연동을 통해 클라이언트 단말에서 연락처를 제공받는 방법에 있어서,
상기 소셜 네트워크 서비스에서 제공하는 연락처 리스트에 대한 요청을 서버로 전송하는 과정과,
소셜 네트워크 서비스 제공 서버로부터 수신된 복수의 연락처 리스트 중에서 상기 클라이언트 단말에 대해 유효한 연락처를 포함하도록 상기 서버에 의해 필터된 연락처 리스트를 상기 서버로부터 수신하는 과정과,
상기 수신된 연락처 리스트를 기반으로 상기 서버와 주소록을 동기화하는 과정과,
상기 수신된 연락처 리스트에 상기 클라이언트 단말과 동일한 메시징 서비스의 주소가 있는 경우 상기 클라이언트 단말과 동일한 메시징 서비스의 주소를 가지는 적어도 하나의 연락처를 가입 리스트에 추가하는 과정을 포함함을 특징으로 하는 연락처를 제공받는 방법.
제1항에 있어서, 상기 연락처 리스트는,
이름, 메일 주소 및 전화번호 중 적어도 하나를 포함함을 특징으로 하는 연락처를 제공받는 방법.
제1항에 있어서,
상기 수신된 연락처 리스트에 상기 클라이언트 단말과 동일한 메시징 서비스의 주소가 있는지를 판단하는 과정을 더 포함함을 특징으로 하는 연락처를 제공받는 방법.
삭제
제 1항에 있어서,
상기 가입 리스트에 추가된 상기 적어도 하나의 연락처에 해당하는 상대방이 등록한 서비스 리스트를 메시징 서비스 등록 서버로 요청하는 과정과,
상기 메시징 서비스 등록 서버로부터 상기 메시징 서비스 리스트를 수신하는 과정을 더 포함함을 특징으로 하는 연락처를 제공받는 방법.
제5항에 있어서,
상기 메시징 서비스 리스트에 상기 클라이언트 단말과 동일한 메시징 서비스가 있는지를 판단하는 과정과,
상기 클라이언트 단말과 동일한 메시징 서비스가 있는 경우 상기 적어도 하나의 연락처에 해당하는 상대방이 상기 클라이언트 단말과 동일한 메시징 서비스를 사용함을 알리는 과정을 더 포함함을 특징으로 하는 연락처를 제공받는 방법.
제 1항에 있어서, 상기 연락처 리스트는,
상기 소셜 네트워크 서비스로부터 수신된 연락처 리스트와 CAB(Converged Address Book) XDMS(XML Document Management Server)로부터 수신된 주소록을 비교함으로써 필터된 것임을 특징으로 하는 연락처를 제공받는 방법.
메시징 서비스와 소셜 네트워크 서비스(SNS) 간의 상호 연동을 통해 연락처를 제공받는 클라이언트 단말에 있어서,
상기 소셜 네트워크 서비스에서 제공하는 연락처 리스트를 서버로 요청하고, 소셜 네트워크 서비스 제공 서버로부터 수신된 복수의 연락처 리스트 중에서 상기 클라이언트 단말에 대해 유효한 연락처를 포함하도록 상기 서버에 의해 필터된 연락처 리스트를 상기 서버로부터 수신하고, 상기 수신된 연락처 리스트를 기반으로 상기 서버와 주소록을 동기화하고, 상기 수신된 연락처 리스트에 상기 클라이언트 단말과 동일한 메시징 서비스의 주소가 있는 경우 상기 클라이언트 단말과 동일한 메시징 서비스의 주소를 가지는 적어도 하나의 연락처를 가입 리스트에 추가하는 제어부; 및
상기 서버와의 요청 및 응답을 송수신하는 입출력 인터페이스를 포함함을 특징으로 하는 클라이언트 단말.
제8항에 있어서, 상기 연락처 리스트는,
이름, 메일 주소 및 전화번호 중 적어도 하나를 포함함을 특징으로 하는 클라이언트 단말.
제8항에 있어서,
상기 수신된 연락처 리스트를 임시로 저장하는 저장부를 더 포함하고,
상기 제어부는 상기 수신된 연락처 리스트에 상기 클라이언트 단말과 동일한 메시징 서비스의 주소가 있는지를 판단함을 특징으로 하는 클라이언트 단말.
삭제
제8항에 있어서, 상기 제어부는,
상기 가입 리스트에 추가된 상기 적어도 하나의 연락처에 해당하는 상대방이 등록한 메시징 서비스 리스트를 메시징 서비스 등록 서버로 요청하고, 상기 메시징 서비스 등록 서버로부터 상기 메시징 서비스 리스트를 수신함을 특징으로 하는 클라이언트 단말.
제12항에 있어서, 상기 제어부는,
상기 메시징 서비스 리스트에 상기 클라이언트 단말과 동일한 메시징 서비스가 있는지를 판단하고, 상기 클라이언트 단말과 동일한 메시징 서비스가 있는 경우 상기 적어도 하나의 연락처에 해당하는 상대방이 상기 클라이언트 단말과 동일한 메시징 서비스를 사용함을 사용자 인터페이스를 통해 알림을 특징으로 하는 클라이언트 단말.
제8항에 있어서, 상기 연락처 리스트는,
소셜 네트워크 서비스로부터 수신된 연락처 리스트와 CAB(Converged Address Book) XDMS(XML Document Management Server)로부터 수신된 주소록을 비교함으로써 필터된 것임을 특징으로 하는 클라이언트 단말.
제 8항에 있어서, 상기 연락처 리스트 요청은,
상기 소셜 네트워크 서비스 포맷으로 변환되고, 상기 서버를 통해 상기 소셜 네트워크 서비스로 전송됨을 특징으로 하는 클라이언트 단말.
메시징 서비스와 소셜 네트워크 서비스(SNS) 간의 상호 연동을 통해 서버에서 클라이언트 단말로 연락처를 제공하는 방법에 있어서,
신규 연락처 리스트를 제공받기 위한 상기 클라이언트 단말로부터의 연락처 제안 요청을 수신하는 과정과,
외부의 주소록 서버로 연락처 리스트 요청을 전송하는 과정과,
상기 외부의 주소록 서버로부터 상기 연락처 리스트 요청에 대응한 연락처 리스트를 수신하는 과정과,
상기 수신된 연락처 리스트 및 기존의 주소록 연락처를 이용하여 상기 클라이언트 단말에 대해 유효한 연락처를 포함하도록 연락처 리스트를 필터링하는 과정과,
상기 필터된 연락처 리스트를 상기 클라이언트 단말로 전송하는 과정과,
상기 클라이언트 단말과 주소록 동기화를 수행하는 과정과,
상기 클라이언트 단말로 전송한 상기 필터된 연락처 리스트에 상기 클라이언트 단말과 동일한 메시징 서비스의 주소가 있는 경우 상기 클라이언트 단말과 동일한 메시징 서비스의 주소를 가지는 적어도 하나의 연락처를 가입 리스트에 추가하는 과정을 포함함을 특징으로 하는 클라이언트 단말로 연락처를 제공하는 방법.
제16항에 있어서, 상기 연락처 제안 요청을 수신하는 과정은,
상기 클라이언트 단말이 상기 연락처 제안 요청에 대한 정보를 저장한 CAB(Converged Address Book) XDMS(XML Document Management Server)으로부터 수신하는 과정임을 특징으로 하는 클라이언트 단말로 연락처를 제공하는 방법.
제16항에 있어서, 상기 연락처 리스트 요청을 전송하는 과정은,
상기 외부의 주소록 서버에 맞는 포맷으로 변환하여 전송하는 과정을 포함함을 특징으로 하는 클라이언트 단말로 연락처를 제공하는 방법.
제 18항에 있어서, 상기 외부의 주소록 서버는,
상기 소셜 네트워크 서비스를 제공하는 서버임을 특징으로 하는 클라이언트 단말로 연락처를 제공하는 방법.
제16항에 있어서, 상기 수신된 연락처 리스트는
CAB(Converged Address Book) 포맷으로 변환됨을 특징으로 하는 클라이언트 단말로 연락처를 제공하는 방법.
제16항에 있어서, 상기 연락처 리스트는,
상기 외부의 주소록 서버 또는 CAB(Converged Address Book) XDMS(XML Document Management Server)로부터 검색됨을 특징으로 하는 클라이언트 단말로 연락처를 제공하는 방법.
제 17항에 있어서, 상기 연락처 제안 요청에 대한 정보는,
HTTP(HyperText Transfer Protocol) PUT을 사용하여 저장됨을 특징으로 하는 클라이언트 단말로 연락처를 제공하는 방법.
제 16항에 있어서,
상기 기존의 주소록 연락처와 상기 수신된 연락처 리스트를 비교함으로써 필터된 연락처를 저장하는 과정을 더 포함함을 특징으로 하는 클라이언트 단말로 연락처를 제공하는 방법.
제 16항에 있어서, 상기 연락처 제안 요청은,
SIP(Session Initiation Protocol) NOTIFY를 이용하여 수신됨을 특징으로 하는 클라이언트 단말로 연락처를 제공하는 방법.
메시징 서비스와 소셜 네트워크 서비스(SNS) 간의 상호 연동을 통해 클라이언트 단말로 연락처를 제공하는 서버에 있어서,
상기 서버와의 요청 및 응답을 송수신하고, 상기 클라이언트 단말로부터 신규 연락처 리스트를 요청하는 연락처 제안 요청을 수신하고, 외부의 주소록 서버로 연락처 리스트 요청을 전송하며, 상기 연락처 리스트 요청에 대응한 연락처 리스트를 수신하는 입출력 인터페이스와,
상기 수신된 연락처 제안 요청을 저장하는 저장부, 및
상기 수신된 연락처 리스트 및 기존의 주소록 연락처를 이용하여 상기 클라이언트 단말에 대해 유효한 연락처를 포함하도록 연락처 리스트를 필터링하고, 상기 필터된 연락처 리스트를 상기 클라이언트 단말로 전송하고, 상기 클라이언트 단말과 주소록 동기화를 수행하며, 상기 클라이언트 단말로 전송한 상기 필터된 연락처 리스트에 상기 클라이언트 단말과 동일한 메시징 서비스의 주소가 있는 경우 상기 클라이언트 단말과 동일한 메시징 서비스의 주소를 가지는 적어도 하나의 연락처를 가입 리스트에 추가하는 제어부를 포함함을 특징으로 하는 클라이언트 단말로 연락처를 제공하는 서버.
제 25항에 있어서, 상기 연락처 제안 요청은,
상기 클라이언트 단말이 상기 연락처 제안 요청에 대한 정보를 저장한 CAB(Converged Address Book) XDMS(XML Document Management Server)로부터 수신함을 특징으로 하는 클라이언트 단말로 연락처를 제공하는 서버.
제 25항에 있어서, 상기 제어부는,
상기 연락처 리스트 요청을 전송하기 이전에, 상기 연락처 리스트 요청을 상기 외부의 주소록 서버에 맞는 포맷으로 변환함을 특징으로 하는 클라이언트 단말로 연락처를 제공하는 서버.
제 27항에 있어서, 상기 외부의 주소록 서버는,
상기 소셜 네트워크 서비스를 제공하는 서버임을 특징으로 하는 클라이언트 단말로 연락처를 제공하는 서버.
제 25항에 있어서, 상기 수신된 연락처 리스트는,
CAB(Converged Address Book) 포맷으로 변환됨을 특징으로 하는 클라이언트 단말로 연락처를 제공하는 서버.
제 25항에 있어서, 상기 제어부는,
상기 외부의 주소록 서버 또는 CAB(Converged Address Book) XDMS(XML Document Management Server)로부터 상기 연락처 제안 요청에 대한 정보에 대응하는 연락처를 검색함을 특징으로 하는 클라이언트 단말로 연락처를 제공하는 서버.
제 26항에 있어서, 상기 연락처 제안 요청에 대한 정보는,
HTTP(HyperText Transfer Protocol) PUT을 사용하여 저장됨을 특징으로 하는 클라이언트 단말로 연락처를 제공하는 서버.
제 25항에 있어서, 상기 저장부는,
상기 기존의 주소록 연락처와 상기 수신된 연락처 리스트와 비교함으로써 필터된 연락처를 저장함을 특징으로 하는 클라이언트 단말로 연락처를 제공하는 서버.
제 25항에 있어서, 상기 연락처 제안 요청은,
SIP(Session Initiation Protocol) NOTIFY를 이용하여 수신됨을 특징으로 하는 클라이언트 단말로 연락처를 제공하는 서버.