KR20130012199A - 메시징 서비스와 타 서비스 간의 상호 연동을 통한 연락처 제공 방법 및 장치 - Google Patents

Abstract

본 발명은 메시징 서비스와 타 서비스 간의 상호 연동을 통한 연락처 제공 방법에 있어서, 응용 서버가 응용 클라이언트로부터 사용자 선호도를 수신하는 과정과, 응용 클라이언트로부터 신규 연락처 리스트 요청을 수신하는 과정과, 신규 연락처 리스트 요청을 인터워킹 서버로 전달하는 과정과, 상기 인터워킹 서버를 통해 서비스 공급자로부터 연락처 프로필을 수신하는 과정과, 상기 수신한 연락처 프로필을 필터링하는 과정과, 상기 필터링된 연락처 리스트를 상기 응용 클라이언트로 전달하는 과정을 포함함을 특징으로 한다.

Description

메시징 서비스와 타 서비스 간의 상호 연동을 통한 연락처 제공 방법 및 장치{METHOD AND APPARATUS FOR PROVIDING OF CONTACT BY INTEROPERABLILITY BETWEEN MESSAGING SEVICE AND OTHER SERVICES}

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

이동 통신 단말은 언제 어디서나 필요한 정보를 공급하고 교환할 수 있는 수단으로 기존에는 단순히 통화 서비스를 이용하는 것이 대부분이었지만, 점차 텍스트 및 멀티미디어를 통해 대화나 정보 교환 측면의 중요성이 더욱 부각되고 있다. 이에 대응하여 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은 향상된 네트워크 주소록으로 다양한 정보를 네트워크 저장소를 활용해서 관리하고, 그룹 간의 정보 공유가 가능한 특징이 있다.

상기한 바와 같이 새롭게 도입된 신규 서비스들 중 기존 메시징 서비스의 경우 사용자가 그 서비스에 가입했더라도 그 서비스 또는 호환 가능한 다른 서비스에 상대방이 가입되어 있지 않으면, 그 서비스를 통한 대화 및 정보 교환이 어려운 상황이 발생한다. 따라서 메시징 서비스 입장에서는 소셜 네트워크와 같은 다른 서비스와 연동한다면 확장된 주소록을 제공받을 수 있어 연락 대상을 확장시킬 수 있다.

한편, 사용자는 일반적으로 친구 혹은 선배나 후배같이 주로 개인적으로 관계가 있는 연락처들을 주로 제공 받을 수 있지만, 상황에 따라서 아무 관계가 없는 연락처도 제공받기를 원하는 경우가 발생할 수 있다. 예를 들어, 해외를 방문할 때 사용자가 한국 음식을 선호한다면, 해외에서 사용자가 직접 한국 식당을 알아서 찾아야 하는 경우가 있다. 이런 상황에서 사용자 주변에 있는 한국 식당 연락처와 메뉴와 같은 부가 정보를 미리 받을 수 있다면 사용자 간편함을 증가할 수 있게 될 것이다. 하지만 이와 같은 정보들은 특정 장소나 기간 동안만 주로 유효한 정보이기 때문에, 이와 같은 제공받은 정보를 주소록에 추가하게 되면, 사용자가 수동으로 삭제나 이동과 같은 관리를 해야하는 부담감이 있다. 따라서 주소록에 제공받은 정보를 상황에 따라서 자동으로 관리할 수 있는 방법이 필요하다.

본 발명은 연락 대상을 확장시킬 수 있는 메시징 서비스와 타 서비스 간의 상호 연동을 통한 연락처 제공 방법 및 장치를 제공하고자 하며, 제공받은 임시 연락처를 관리하기 위한 방법 및 장치를 제공하고자 한다.

이를 달성하기 위한 본 발명의 일 형태에 따르면, 본 발명은 메시징 서비스와 타 서비스 간의 상호 연동을 통한 연락처 제공 방법에 있어서, 응용 서버가 응용 클라이언트로부터 사용자 선호도를 수신하는 과정과, 응용 클라이언트로부터 신규 연락처 리스트 요청을 수신하는 과정과, 신규 연락처 리스트 요청을 인터워킹 서버로 전달하는 과정과, 상기 인터워킹 서버를 통해 서비스 공급자로부터 연락처 프로필을 수신하는 과정과, 상기 수신한 연락처 프로필을 필터링하는 과정과, 상기 필터링된 연락처 리스트를 상기 응용 클라이언트로 전달하는 과정을 포함함을 특징으로 하며,

상기 필터링하는 과정은, 수신한 연락처 프로필에서 연락처 식별이 가능한 데이터를 추출하는 과정과, 상기 추출한 연락처 식별이 가능한 데이터를 상기 응용 서버의 주소록 관리부에 저장된 주소록의 데이터와 비교하여, 상기 수신한 연락처 프로필이 상기 주소록에 저장된 데이터인지 판단하는 과정과, 상기 수신한 연락처 프로필이 상기 주소록에 저장되지 않은 데이터인 경우, 상기 사용자 선호도에 해당하는 데이터를 상기 수신한 연락처 프로필로부터 추출하는 과정과, 상기 추출한 상기 사용자 선호도에 해당하는 데이터가 상기 응용 서버의 선호도 관리부에 저장된 사용자 선호도와 일치하는지 판단하는 과정과, 상기 추출한 상기 사용자 선호도에 해당하는 데이터가 상기 응용 서버의 선호도 관리부에 저장된 사용자 선호도와 일치하는 경우, 상기 수신한 연락처 프로필에 임시 연락처 표시를 추가하는 과정을 포함함을 특징으로 하며,

상기 연락처 식별이 가능한 데이터는 이름, 메일 주소, 전화번호, 제공받은 서비스 중 적어도 하나임을 특징으로 한다.

본 발명의 제 2형태에 따르면, 본 발명은 메시징 서비스와 타 서비스 간의 상호 연동을 통한 연락처 제공을 위한 응용 서버에 있어서, 상기 응용 서버가 동작하기 위해 필요한 데이터를 저장하며, 서비스 공급자로부터 수신한 연락처 프로필 리스트를 저장하기 위한 메모리와, 다른 시스템 요소들과 정보를 송수신하기 위한 I/O 인터페이스(interface)와, 상기 응용 클라이언트의 주소록과 동기화된 주소록 정보를 저장하기 위한 주소록 관리부와, 응용 서버가 응용 클라이언트로부터 사용자 선호도를 수신하며, 응용 클라이언트로부터 신규 연락처 리스트 요청을 수신하며, 신규 연락처 리스트 요청을 인터워킹 서버로 전달하며, 상기 인터워킹 서버를 통해 서비스 공급자로부터 연락처 프로필을 수신하며, 상기 수신한 연락처 프로필을 필터링하며, 상기 필터링된 연락처 리스트를 상기 응용 클라이언트로 전달하는 제어부를 포함함을 특징으로 하며,

사용자로부터 수신한 사용자 선호도를 저장하기 위한 선호도 관리부를 더 포함함을 특징으로 한다.

본 발명의 제 3형태에 따르면, 본 발명은 메시징 서비스와 타 서비스 간의 상호 연동을 통해 연락처를 제공받는 방법에 있어서, 응용 클라이언트가 응용 서버로 신규 연락처 리스트 요청을 전송하는 과정과, 응용 클라이언트가 응용 서버로부터 필터링된 연락처 리스트를 수신하는 과정과, 상기 수신한 필터링된 연락처 리스트를 표시하는 과정과, 상기 수신한 필터링된 연락처 리스트를 주소록에 추가하는 과정과, 상기 추가한 연락처 리스트를 미리 설정된 기준에 따라 삭제하는 과정을 포함함을 특징으로 하며,

상기 추가한 연락처 리스트를 미리 설정된 기준에 따라 삭제하는 과정은, 상기 추가한 연락처 프로필에 임시 표시가 있는지 확인하는 과정과, 상기 추가한 연락처 프로필에 임시 표시가 있는 경우, 상기 임시 표시가 있는 연락처 프로필의 보관 기준을 확인하는 과정과, 상기 보관 기준에 일치하는 경우, 주기적으로 보관 기준을 확인하는 과정과, 상기 보관 기준이 일치하지 않는 경우, 상기 임시 표시가 있는 연락처 프로필을 삭제하는 과정을 포함함을 특징으로 하며,

상기 보관 기준은, 응용 클라이언트의 위치, 미리 설정된 기간 중 적어도 하나를 포함함을 특징으로 한다.

본 발명의 제 4형태에 따르면, 본 발명은 메시징 서비스와 타 서비스 간의 상호 연동을 통해 연락처를 제공 받기 위한 응용 클라이언트에 있어서, 상기 응용 클라이언트가 동작하기 위해 필요한 데이터를 저장하는 메모리와, 다른 시스템 요소들과 정보를 송수신하기 위한 I/O 인터페이스(interface)와, 주소록 정보를 저장하기 위한 주소록 관리부와, 데이터 입출력을 위한 사용자 인터페이스와, 응용 서버로 신규 연락처 리스트 요청을 전송하며, 상기 응용 서버로부터 필터링된 연락처 리스트를 수신하며, 상기 수신한 필터링된 연락처 리스트를 표시하며, 상기 수신한 필터링된 연락처 리스트를 주소록에 추가하며, 상기 추가한 연락처 리스트를 미리 설정된 기준에 따라 삭제하는 제어부를 포함함을 특징으로 한다.

본 발명은 메시징 서비스 시, 다른 서비스로부터 확장된 주소록을 제공받음으로써 연락 대상을 확대시킬 수 있는 이점이 있다. 이에 따라 자신이 가지고 있는 주소록에는 없지만 자동으로 신규 연락처를 제공받을 수 있으며, 이에 따라, 사용자는 주소록에 있는 기존 친구 및 가족뿐만 아니라 본인 프로필과 선호도와 연관 있지만 아직 알지 못하는 식당과 같은 다른 연락처와 임시로 쉽게 연결할 수 있는 효과가 있다. 또한 사용자 측면에서 특정 서비스에 신규 가입했을 때 그 서비스를 바로 이용하는데 편의성을 제공한다.

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

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

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

본 발명은 타 서비스와의 상호 연동을 통한 연락처 제공 방법 및 장치와, 제공된 임시 연락처 관리 방법을 제안한다. 이를 위해 본 발명은 타 서비스와의 연동을 통해 메시징 서비스를 이용하는 클라이언트에서 그 타 서비스에서 제공하는 연락처를 제공받는 과정과, 특정 기준, 예를 들어 사용자와 연락처의 실시간 위치거리와 같은 기준에 따라 더 이상 필요없는 연락처로 판단될 경우, 클라이언트가 그 연락처를 자동으로 처리(예: 삭제)하는 과정으로 이루어진다. 이에 따라 메시징 서비스를 이용하는 클라이언트는 주소록에 임시로 필요한 연락처들도 쉽게 확장할 수 있고, 더 이상 필요 없는 경우 사용자의 조치가 따로 필요 없이 직접 관리(예: 삭제)해 준다.

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

도 1은 본 발명의 실시예에 따른 신규 연락처 제공 및 임시 연락처 관리를 위한 시스템 구성도이다.

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

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

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

타 서비스 공급자(40, 41)는 상기 메시징 서비스와 구별되는 다른 서비스를 제공해주는 기관들이다. 예를 들어, Social Network Services경우 페이스북(Facebook)이나 트위터(Twitter)와 같은 기관들이다.

도 1에 도시된 시스템을 참조하여, 본 발명의 연락처 제공 동작을 설명하면, 최초 응용 클라이언트(10)는 응용 서버(20)로 신규 연락처를 요청(101)하고, 응용 서버는 인터워킹 서버로 신규 연락처를 요청(103)하며, 인터워킹 서버(30)는 타서비스 공급자(40, 41)들에게 신규 연락처 프로필을 요청하고, 그에 대한 정보를 수신(104)한다. 다음 인터워킹 서버(30)는 타 서비스 공급자들(40, 41)로부터 수신한 신규 연락처 프로필을 변환하여 응용 서버로 전달(107)하고, 응용 서버(20)는 신규 연락처를 응용 클라이언트(10)로 전달(109)한다. 응용 클라이언트(10)는 신슈 연락처를 사용자에게 제안(111)하고, 이후, 응용 클라이언트(10)는 신규 연락처 삭제 기준을 비교하여, 기준에 만족하지 않으면 주소록에서 삭제(113)한다.

도 1에 도시된 바와 같은 시스템에서의, 연락처 제공 동작 과정을 도 2를 참조하여 보다 상세히 설명하기로 한다. 도 2는 본 발명의 실시예에 따른 타 서비스와의 연동을 통한 연락처 제공 동작의 흐름도이다.

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

도 2를 참조하면, 201단계에서 응용 클라이언트(10)는 응용 서버(20)로 신규 연락처 리스트를 요청한다. 이러한 신규 연락처 리스트의 요청은 사용자가 응용 클라이언트(10)를 실행하거나 서비스에 접속 시 이루어질 수 있다. 이러한 요청은 사용자 선호도가 맞는 예컨대, 사용자가 선호하는 음식 종류 식당이나 음악 종류 이벤트 등, 해당 조건에 맞는 신규 연락처 프로필 리스트를 요청하기 위함이다. 여기서, 신규 연락처 프로필에는 이름, 메일 주소, 전화번호 등이 포함된다.

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

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

다음, 응용 서버(20)는 215단계에서 필터된 연락처 리스트를 응용 클라이언트(10)로 보낸다. 그러면 217단계에서 응용 클라이언트(10)는, 해당 사항을 사용자에게 알리고, 사용자가 연락처를 주소록에 추가 요청할 경우, 주소록을 추가 및 관리한다. 사용자 알림, 연락처 추가 및 관리 과정에 대한 구체적인 설명은 하기 도 6에서 후술하기로 한다.

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

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

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

본 발명의 일 실시 예에서 상기 응용 서버(20)는 상기 응용 서버가 동작하기 위해 필요한 데이터를 저장하며, 서비스 공급자로부터 수신한 연락처 프로필 리스트를 저장하기 위한 메모리(305)와, 다른 시스템 요소들과 정보를 송수신하기 위한 I/O 인터페이스(interface)(303)와, 상기 응용 클라이언트의 주소록과 동기화된 주소록 정보를 저장하기 위한 주소록 관리부(307)와, 응용 서버가 응용 클라이언트로부터 사용자 선호도를 수신하며, 응용 클라이언트로부터 신규 연락처 리스트 요청을 수신하며, 신규 연락처 리스트 요청을 인터워킹 서버로 전달하며, 상기 인터워킹 서버를 통해 서비스 공급자로부터 연락처 프로필을 수신하며, 상기 수신한 연락처 프로필을 필터링하며, 상기 필터링된 연락처 리스트를 상기 응용 클라이언트로 전달하는 제어부(301)를 포함한다.

도 4는 상기 도 2의 응용 서버의 동작 흐름도이다. 도 4를 참조하면, 401단계에서 제어부(301)는 I/O 인터페이스(303)를 통해 수신한 연락처 프로필 리스트를 메모리(305)에 저장한다. 403단계에서 제어부(301)는 메모리(305)에 저장된 프로필에서 연락처 식별 가능한 데이터 예컨대, 이름, 메일 주소, 전화번호, 제공받은 서비스 (예: Facebook) 등을 추출한다. 그리고 나서 405단계에서 추출된 데이터와 주소록 관리부(307)에 있는 해당 데이터들과 비교해 이미 주소록에 존재하는 연락처인지 판단한다. 판단 결과 그 주소록에 존재하는 연락처로 판단되는 경우, 407단계에서 프로필을 삭제한다.

405단계에서 이미 주소록에 존재하는 연락처가 아니라면, 409단계에서 사용자 선호도에 해당하는 데이터를 연락처 프로필로부터 추출한다. 이 때, 임시 연락처에 해당되는 선호도 데이터(예: 위치거리, 기간)도 같이 추출한다. 411단계에서 추출된 데이터가 선호도 관리부(309)에 저장된 사용자 선호도(예: 위치거리 200m 이내)와 일치하는지 확인하고, 일치하지 않는 경우에는, 407단계로 진행하여 프로필을 삭제한다. 411단계에서 사용자 선호도와 일치하는 경우, 413단계로 진행하여 연락처에 임시 연락처로 식별할 수 있는 사용자 선호도나 연락처 데이터가 있는지 확인한다. 예를 들어, 사용자 선호도가 “위치거리 200m 이내”이고, 연락처(예: 식당)의 위치거리는 100m에 있는 경우, 사용자 선호도와 일치되지만, 위치거리는 사용자 이동에 따라 일치 여부는 변경되기 쉽기 때문에 임시 연락처로 판단한다. 또 다른 예를 들면, 현 날짜가 1월 5일이고, 연락처(예: 재즈 페스티벌)에 해당 기간은 1월 1일 ~ 1월 10일인 경우, 현 날짜 기준으로 봐서는 유효하지만, 그 기간이 지나면 더 이상 유효하지 않은 연락처로 볼 수 있기 때문에, 임시 연락처로 판단할 수 있다. 이와 같은 선호도나 데이터가 있는 경우 415 단계에서 임시 연락처임을 연락처 프로필에 표시한다.

이후, 417단계로 진행하여 검토해야 할 연락처 프로필이 더 있는지를 판단하여, 검토할 연락처가 더 있는 경우 403단계로 되돌아가 전술한 과정을 반복 수행하고, 더 이상 검토할 프로필이 없는 경우, 내부 필터 동작을 종료한다

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

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

본 발명의 실시 예에 따른 응용 클라이언트는, 상기 응용 클라이언트가 동작하기 위해 필요한 데이터를 저장하는 메모리와(505), 다른 시스템 요소들과 정보를 송수신하기 위한 I/O 인터페이스(interface)(503)와, 주소록 정보를 저장하기 위한 주소록 관리부(507)와, 데이터 입출력을 위한 사용자 인터페이스(509)와, 응용 서버로 신규 연락처 리스트 요청을 전송하며, 상기 응용 서버로부터 필터링된 연락처 리스트를 수신하며, 상기 수신한 필터링된 연락처 리스트를 표시하며, 상기 수신한 필터링된 연락처 리스트를 주소록에 추가하며, 상기 추가한 연락처 리스트를 미리 설정된 기준에 따라 삭제하는 제어부(501)를 포함한다.

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

도 6을 참조하면, 제어부(501)는 601단계에서 I/O 인터페이스(503)를 통해 수신한 필터된 연락처를 사용자 인터페이스(509)를 통해 사용자에게 알린다. 603단계에서는 사용자가 신규 연락처를 주소록에 추가에 대한 결정을 대기하고, 연락처를 주소록에 추가 요청 시 605단계로 진행하여 추가하고, 603단계에서 추가 요청이 아닌 경우에는 611단계로 진행하여 연락처를 삭제하고 응용 클라이언트(10)의 동작을 종료한다. 연락처를 주소록에 추가한 경우에는, 607단계에서 연락처 프로필에 임시 표시가 있는지 확인한다. 임시 표시가 없는 경우, 본 연락처는 계속 보관해야 하기 때문에 응용 클라이언트(10) 동작을 종료한다. 임시 표시가 있는 경우, 본 연락처는 특정 기준(예: 사용자 현 위치와 연락처 위치거리가 200m내인지)이 일치하는 동안 까지만 보관할 필요가 있다. 따라서 609단계에서 임시 연락처가 보관 기준에 일치하는지 주기적으로 확인하도록 설정할 수 있다. 일치하면 609단계로 돌아가서 보관 기준을 정기적으로 확인한다. 임시 연락처가 보관 기준에 일치하지 않는 경우에는, 611단계에서 연락처를 주소록에서 삭제한다. 대안 동작으로, 611단계에서 사용자에게 삭제 확인을 우선 요청하고 확인을 받으면 삭제하도록 할 수 있다. 또 다른 동작으로, 611단계에서 영구로 삭제하지 않고, “지운 연락처 함”과 같은 다른 저장소에 이동할 수도 있다. 611단계를 수행 후 응용 클라이언트(10)의 동작은 종료된다.

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

이에 따라 도 2에서의 응용 클라이언트(10)는 신규 연락처를 제공받기 위해 CAB 클라이언트로 동작할 수 있다. 따라서 본 발명에 따른 SNS 서비스와의 연동을 통한 연락처 제공 시스템은 CAB 인에이블러를 기반으로 구현될 수 있다.

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

도 7은 본 발명에 이용되는 CAB 서비스를 위한 구성도이다. 도 7을 참조하면, CAB Client(71)는 사용자 단말기에 있는 주소록을 관리 및 제어해주는 응용 프로그램이다. CAB Server(72)는 CAB Client(71)로부터 받은 사용자의 다양한 요구사항을 수행하는 네트워크 주요 요소이다. 특히 CAB 시스템과 타 주소록 시스템 (예: vCard)과 연동을 가능하게 해주는 Interworking Function도 CAB Server(72)에 포함되어 있다. CAB AB(Address Book) Application Usage(73)는 사용자의 주소록을 저장 및 관리해 주는 서버이다. CAB PCC(Personal Contact Card) Application Usage(74)는 사용자의 프로필을 저장 및 관리해 주는 서버이다.

CAB User Preferences Application Usage(75)는 사용자의 선호도를 저장 및 관리해 주는 서버이다.

CAB FH(Feature Handler) Application Usage(76)는 사용자의 특정 요구 사항들을 저장 및 관리해 주는 서버이다. Non-CAB Address Book Systems(77)는 CAB 서비스에서 사용하지 않는 모든 주소록 시스템들을 포함하며, 예를 들어, vCard 등이 이에 해당한다. 본 발명에서는 도 2에 설명한 타 서비스 공급자(40, 41)들도 이 시스템에 포함된다고 가정할 수 있다.

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

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

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

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

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

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

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

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

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

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

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

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

825단계에서 RCS(CAB) 서버(72)는 주소록이 변경되었다는 사실을 RCS(CAB) 클라이언트(71)에게 알린다. 이러한 알림을 위해 OMA DS가 이용된다. 이어, 827단계에서 RCS(CAB) 클라이언트(71)는 주소록 동기화를 RCS(CAB) 서버(72)와 실시하고, 동기화를 통해 신규 제안 연락처들을 함께 받는다. 그리고 나서 829단계에서 RCS(CAB) 클라이언트(71)는 수신한 연락처들을 도6 동작에 따라 사용자에게 알리고 관리한다.이와 같이 RCS(CAB) 클라이언트(71) 입장에서는 Non-RCS 공급자 즉, 타 서비스 공급자와의 연동을 통해 서비스 가입 여부를 알고자 하는 대상의 확장할 수 있게 된다.

상기한 바와 같이 본 발명의 제1실시 예에서는 RCS(CAB) 서버가 필터링 기능 및 인터워킹 기능 모두를 수행하며, 필터된 연락처는 CAB AB Application Usage(73)에서 관리하고, 사용자의 요청과 연락처 제안에 대한 선호도는 CAB FH Application Usage(76)에서 관리하는 “CAB Feature Handler”라는 문서에 저장되는 경우를 예로 들어 설명하였다.

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

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

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

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

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

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

<same-school>에는 같은 학교에 다닌 연락처 제안을 받고 싶을 때 해당 학교 이름을 직접 기재하거나, 나중에 RCS(CAB) 서버(72)가 사용자 프로필(CAB PCC Application Usage(74)에 접속해 이미 기재된 학교 이름을 활용한다.

<same-work>에는 같은 직업을 갖는 연락처 혹은 같은 직장에 관련된 연락처 제안을 받고 싶을 때 해당 회사나 직업 종류 이름을 직접 기재하거나, 나중에 RCS(CAB) 서버(72)가 사용자 프로필 (CAB PCC Application Usage(74))에 접속해 이미 기재된 회사나 직업 종류 이름을 활용한다.

<same-hobby>에는 같은 취미를 갖고 있는 연락처를 제안 받고 싶을 때 해당 취미를 직접 기재하거나, 나중에 RCS(CAB) 서버(72)가 사용자 프로필(CAB PCC Application Usage(74))에 접속해 이미 기재된 취미를 활용한다.

<max-distance>에는 사용자의 현 위치와 연락처 위치간 최대 허용거리를 기재한다. 예를 들어 “200m”를 기재하면, 사용자 현 위치의 200미터 이하 거리인 연락처들만 받고 싶다는 뜻이다. 예를 들어 사용자 주변에 있는 식당 같은 기업용 연락처를 제공받고자 할 때 효율적이다.

<period>에는 제공 받고자 하는 연락처의 유효기간을 설정한다. 예를 들어 기간이 “01.01 ~ 01.10”이면, 연락처의 유효 기간이 이 기간과 겹치는 연락처들을 제공 받게 된다. 사용자가 관심이 있는 콘서트나, 전시 같은 제안된 기간 동안만 유효한 연락처를 제공받고자 할 때 효율적이다.

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

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

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

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

다음은 도 8의 821단계에서 RCS(CAB) 서버(72)가 CAB AB Application Usage(73)에 저장하는 필터 된 연락처들의 내용을 정리한다. 정리하기 위해 우선 OMA CAB에서 기술된 주소록 포맷(structure)을 설명한다. 사용자의 주소록은 다음을 포함한다.

<address-book>은 주소록을 대표하는 요소이다. 이 요소의 하위 레벨에는 하나 이상의 <contact> 요소로 구성될 수 있다.

<contact>는 주소록에 한 연락처를 대표하는 요소이다. 이 요소의 하위 레벨에는 하나 이상의 <pcc>와 <contact-status> 요소들로 구성될 수 있다.

<pcc> (Personal Contact Card)에는 연락처의 이름, 주소 등 같은 연락처에 대한 자세한 정보가 들어 있다. 이 요소의 하위 레벨에는 <person-details>, <org-details>, <group-details>로 구성 되어 있고, 각 구성 요소마다 또한 다양한 하위레벨 구성 요소들로 계속 이어진다. 그 중 연락처의 위치정보를 표시하는 요소(<location>)도 포함되어 있다.

<contact-status>에는 연락처에 대한 상태 정보가 들어있다. 하위 레벨에는 <contact-type>, <entry_status>, <contact-source>등 같은 요소들 중 한 요소 이상으로 구성되어 있다.

<contact-type>에는 연락처가 CAB 사용자인지 아닌지 표시한다. CAB 사용자가 아닌 경우 이 요소는 생략된다.

<entry_status>에는 이 연락처에 대한 상태 정보를 제공한다. 하위 레벨에는 <updated>나 <temporary>중 한 요소로 구성되어 있다.

<updated>는 사용자가 아직 모르는 신규 연락처나 기존 연락처에 대한 갱신된 정보이지만, 사용자의 별도의 동의 없이(예: 자동동의) 주소록에 반영해도 되는 경우 사용된다. 하기 표 1은 <updated>에 가능한 값을 정리한다:

Value	Definition
incoming subscription request	value indicates that an incoming subscription request is received from the associated contact (that is a CAB User)
contact subscription	value indicates that the contact was updated as a result of outgoing Contact Subscription updates
contact imported	value indicates that the contact was updated as a result of importing non-CAB data
contact-share	value indicates that accepted contact share data received has resulted in an updated Contact Entry

종래기술의 CAB 클라이언트는 사용자가 신규 정보를 읽은 후 <updated>값을 삭제 한다.

<temporary> 는 사용자가 아직 모르는 신규 연락처나 기존 연락처에 대한 갱신된 정보이고, 주소록에 반영하기 전에 우선 사용자의 동의가 필요한 경우 사용된다. 하기 표 2는 <temporary>에 가능한 값을 정리한다:

Value	Definition
contact subscription	value indicates that the contact was created as a result of outgoing Contact Subscription updates
contact imported	value indicates that the contact was created as a result of importing non-CAB data
incoming subscription request	value indicates that the contact was created as result of incoming subscription request from other CAB User
contact-share	value indicates that contact share data that was received needs to be confirmed and has resulted in a temporary Contact Entry

종래기술의 CAB 클라이언트는 사용자가 신규 정보에 대해 동의하면 <updated>값을 삭제 한고, 동의하지 않으면 연락처를 삭제한다.

<contact-source>에는 신규 연락처나 연락처에 대한 갱신정보가 제공된 기관을 표시한다.

상기 종래기술에 따라, 도 8의 821단계에서 RCS(CAB) 서버(72)가 CAB AB Application Usage(73)에 저장하는 내용은 <address-book>요소 아래 한 개 이상의 <contact>요소를 제공하는 것이다. 본 발명의 목적과 환경에 따라 다음 설정이 적용이 되고, 종래기술에 없는 정보가 다음과 같이 추가하게 된다.

<pcc>: 제공하고자 하는 연락처에 대한 정보이다. 도 6에 설명한 바와 같이 임시 연락처 관리에 필요한 정보(예: 위치정보 - <location>)가 있는 경우 같이 포함된다.

<contact-type>는 타 서비스 즉 CAB 서비스가 아닌 기관으로부터 제공 받았으니 생략된다.

<entry-status>아래, <updated>나 <temporary>중 상기 종래기술 설명에 맞춰 사용되지만, 선택된 <updated>나 <temporary>는 다음 표 3에 도시된 신규 값이 적용된다.

Value	Definition
contact_suggeted	value indicates that the contact was created as a result of suggesting non-CAB contacts by the CAB service

도 6에 설명한 임시 연락처 관리가 지속적으로 되기 위해, <updated>및 <temporary>와 같은 레벨에 다음 <auto-remove> 요소를 정의한다. 본 발병의 415단계와 607단계에 설명한 임시 연락처 표시의 실시 예이다.

<auto-remove>는 제공한 연락처가 어느 기준에 따라 자동으로 삭제될 수 있는지 표시하는 요소이다. 하위 레벨에는 <max_dist>와 <validity_period> 한 개 이상 요소로 구성되어 있다.

<max-distance>는 사용자의 현 위치와 연락처 위치간 최대 허용 거리를 기재한다. 이 거리를 넘으면 연락처는 사용자 선호도에 따라 자동으로 삭제될 수 있다.

<validity-period>는 연락처의 유효기간이다. 이 유효기간을 지나면 연락처는 사용자 선호도에 따라 자동으로 삭제될 수 있다.

다른 실시 예로, <max-distance>와 <validity-period> 요소들은 기존에 있는 <updated>와 <temporary>요소들의 하위 레벨에 대신 적용될 수도 있다. 하지만 종래 기술에 따르면 CAB 클라이언트는 사용자가 신규 정보를 읽거나 동의한 후 <updated>와 <temporary>요소들을 삭제하기로 되어 있다. <max-distance>나 <validity-period>요소가 그 하위 레벨에 존재한다면, 본 발명 실시 예에 따라 (CAB) 클라이언트 (71)는 <updated>와 <temporary>요소들을 계속 보관하거나, <max-distance>와 <validity-period>정보를 따로 보관해야 한다.

본 발명의 제 1실시 예에서는 사용자가 RCS 서비스에 접속 시, RCS(CAB) 클라이언트(71)는 신규 연락처 제안 리스트를 받기 위해 사용자의 선호도를 포함한 모든 자세한 정보를 CAB FH Application Usage(76)가 관리하는 “CAB Feature Handler”라는 문서에 저장하도록 했다. 한편, 본 발명의 제2실시 예에서 RCS(CAB) 클라이언트(71)는 제안 리스트를 받기 위한 기본 정보는 CAB FH Application Usage(76)가 관리하는 “CAB Feature Handler”라는 문서에 계속 저장하되, 제안 리스트에 대한 사용자 선호도는 CAB User Preferences Application Usage(75)가 관리하는 “CAB User Preferences document” 라는 문서에 별도로 저장하는 경우를 설명하며, 이를 위해 도 9를 참조한다.

도 9는 본 발명의 제2실시예에 따른 연락처 제공 과정을 보인 흐름도이다.

도 9의 901단계에서 RCS(CAB) 클라이언트(71)는 사용자가 제안 리스트를 받기 위해 선호도를 신규를 설정하거나 갱신하면, 901단계에서 RCS(CAB) 클라이언트(71)는 사용자 선호도를 CAB UP(User Preferences) Application Usage(75)가 관리하는 “CAB User Preferences”라는 문서에 저장하도록 요청한다. “CAB User Preferences document”문서에 대한 상세 설명은 후술하기로 한다. 903단계에서 CAB UP Application Usage(75)는 관리하는 “CAB User Preferences”문서에 요청 사항을 저장하고, 저장 완료 응답인 200 OK를 RCS(CAB) 클라이언트(71)로 보낸다.

이후 사용자가 RCS 서비스에 접속 시, 상기 설명한 제1실시 예와 비슷하게 905 단계에서 RCS(CAB) 클라이언트(71)는 신규 연락처 제안 리스트를 받기 위해 요청에 대한 정보를 CAB FH Application Usage(76)가 관리하는 “CAB Feature Handler”라는 문서에 저장하도록 요청한다. 단, “CAB Feature Handler”문서에는 요청 자체에 대한 필요한 기본 정보만 기재하고, 제안 리스트에 대한 사용자 선호도는 포함하지 않는다. 907단계에서 CAB FH Application Usage(76)는 관리하는 “CAB Feature Handler”문서에 요청 사항을 저장하고, 저장 완료 응답인 200 OK를 RCS(CAB) 클라이언트(71)로 보낸다. 그리고 나서 제1실시 예와 동일하게 909단계에서 CAB FH Application Usage(76)는 “CAB Feature Handler”문서에 저장된 RCS(CAB) 클라이언트(71)의 요청 사항과 정보를 RCS(CAB) 서버(72)에게 알린다. 이러한 알림을 위해 SIP NOTIFY 메시지가 이용된다. 그러면 911단계에서 RCS(CAB) 서버(72)는 알림을 수신하고 확인 메시지인 200 OK를 CAB FH Application Usage(76)로 보낸다.

이어, 913단계에서 RCS(CAB) 서버(72)는 본 요청에 해당하는 제안 리스트에 대한 사용자의 선호도 (Contact suggestions preferences)룰 XCAP/HTTP GET를 통해 CAB UP Application Usage(75)에게 요청한다. 915단계에서 CAB UP Application Usage(75)는 관리하는 “CAB User Preferences”문서에 저장된 사용자 선호도를 200 OK를 통해 RCS(CAB) 서버(72)로 보낸다.

도 9의 나머지 917단계 내지 937단계는 도 8의 809단계 내지 829단계에서의 동작과 동일하다.

종래기술에 “CAB User Preferences”라는 문서에 들어가는 내용을 살펴보면 다음과 같다:

<cab-upp>는 제일 상단 레벨에 있는 “root” 요소이다. 이 요소의 하위 레벨에는 요소들 중 본 발명과 연관된 <cab-upp-set>요소로 구성되어 있다.

<cab-upp-set>는 모든 사용자 선호도들을 표시하는 요소이다. 이 요소의 하위 레벨에는 한 개 이상의 <profile>요소로 구성 되어 있다.

<profile>은 사용자의 특정 프로필이나 환경(예: 집, 사무실)에 적용되는 사용자 선호도들을 모은 요소이다. 이 요소의 하위 레벨에는 <update-ab>같은 다양한 선호도들을 표시하는 요소들로 구성되어 있다.

<update-ab>는 어느 이벤트를 통해 사용자 주소록이 갱신될 경우 바로 자동으로 갱신될지 사용자 동의를 받은 후 갱신될지 정하는 선호도 요소이다. 이 요소의 하위 레벨에는 각 이벤트 별 해당 선호도를 표시하는 요소로 구성되어 있다.

상기와 같이 설명한“CAB User Preferences”라는 문서에 본 발명 제2실시 예에 따르면 다음과 같은 요소들을 추가하게 된다.

<profile>요소 하위 레벨에 <auto-remove>요소를 정의한다. 이 요소는, 본 발명 도 6에서 설명한 주소록에 추가된 연락처 관리 과정에서 어느 기준(사용자와 위치거리, 유효기간)과 충족하지 않는 경우, 사용자의 선호도에 따라 연락처를 처리하게 된다. 즉 상기 (<address-book>요소의 하위 레벨에서 정의한) <max-distance>요소에 명시된 기준에 비교해 현 위치거리가 그 기준을 넘었거나, <validity-period>요소에 명시된 기준에 비교해 현 날짜가 그 유효기간을 지난 경우, 본 선호도 <auto-remove>값을 확인하게 된다. 값이 “true”인 경우 해당 연락처를 자동으로 삭제하고, 값이 “false”인 경우 연락처 삭제에 대한 사용자 동의를 우선 구한다. 다른 구현에 따라 값이 “true”인 경우 연락처를 영구로 삭제 하지 않고, 어느 “지운 연락처 함”같은 다른 저장소에 이동할 수도 있다.

<profile>요소 하위 레벨에 <contact-suggestions>요소를 정의한다. 이 요소는, 제1실시 예에서 RCS(CAB) FH Application Usage(76)가 관리하고 “CAB feature handler”문서에 저장했던, <contact-suggestions>요소에 해당된다. 즉 제안 리스트를 받기 위해 RCS(CAB) 클라이언트(10)가 전송하는 정보들이다. 하지만 제2실시 예에는 제1실시 예와 달리 사용자 선호도와 연관된 정보들만 RCS(CAB) UP Application Usage(75)에서 따로 관리한다고 했다. 따라서 다음 선호도 요소들을 상기 <contact-suggestions>요소의 하위 레벨에 추가한다: <friend-of-friend>, <same-school>, <same-work>, <same-hobby>, <max-distance>, <period>, <max-suggestions>. 각 요소의 설명과 사용 방법은 제1실시 예에서 설명한 것과 동일하다.

<update-ab>요소 하위 레벨에 <suggestions-update>요소를 정의한다. 이 요소는, 신규 연락처 리스트를 사용자에게 제안하고자 할 때 주소록에 자동으로 추가될지 (<suggestions-update> = “true”) 사용자 동의를 받은 후 추가될지 (<suggestions-update> = “false”) 정하는 선호도 요소이다. 이 요소는 제1실시 예에도 적용이 가능하고, 이 요소의 값이 “true”인 경우 도 6의 603단계(신규 연락처를 주소록에 추가에 대한 사용자의 결정 대기 과정)는 생략한다.

제 1실시 예와(819단계) 제2실시 예에서(927단계)는 도4에서 설명한 바와 같이 사용자의 기존 연락처 및 선호도와 Non-RCS(CAB) 주소록 시스템(77)으로부터 받은 신규 연락처 프로필들을 비교하고 필터 하는 과정을 RCS(CAB) 서버(72)가 수행한다고 가정했다. 하지만, 그 비교 및 필터 작업(즉 도4의 동작)을 다른 요소가 수행할 수도 있다. 제3실시 예에는 그 필터 과정을 RCS(CAB) AB Application Usage(73)하는 것으로 가정한다. 따라서 도 10을 살펴보면, 1001단계 내지 1011단계는 도 9의 901단계 내지 911단계에서의 동작과 동일하다. 하지만 제3실시 예에서는 RCS(CAB) 서버(72)는 필터 동작을 수행하지 않기 때문에 필터 하기 위한 사용자 선호도를 제2실시 예와 같이 요청할 필요가 없다. 따라서 1013단계 내지 1019단계 에서 RCS(CAB) 서버(72)는 Non-RCS(CAB) 주소록 시스템 (77)에게 신규 연락처들을 바로 요청하고(1013 단계), 해당 연락처 리스트를 받고(1015 단계), 연락처 리스트를 RCS(CAB) 포맷으로 변환한 다음(1017 단계), 필터 하지 않고 바로 CAB AB Application Usage(73)에게 저장하도록 요청한다(1019 단계). 1021단계에서, CAB AB Application Usage(73)는 받은 요청이 신규 연락처 리스트를 사용자에게 제안하기 위한 저장 요청임을 알게 되고, 1021내지 1027단계에서 연락처 리스트 제안관련 사용자 선호도를 CAB UP Application Usage(75)에게 요청을 하고(1021단계), 사용자 선호도를 받고(1023 단계), 신규 연락처들을 사용자 선호도와 사용자 주소록에 있는 연락처들과 비교 및 필터 한 다음(1025 단계), 필터를 통해 남은 연락처들을 저장하고 저장 응답 메시지를 RCS(CAB) 서버(72)에게 보낸다(1027단계). 1029단계 내지 1033단계는 도 9의 933단계 내지 937단계에서의 동작과 동일하다.

또 다른 4실시 예로, 상기 설명한 비교 및 필터 작업을 RCS(CAB) 클라이언트(10)가 직접 수행할 수 있다. 그런 경우, RCS(CAB) 클라이언트(10)는 이미 사용자의 선호도를 사용자 입력을 통해 이미 알고 있고 주소록을 기기에 따로 보관하기 때문에 필터가 수행 가능하며, 사용자의 선호도를 RCS(CAB) 서버(72)나 RCS(CAB) AB Application Usage(73)에게 전달할 필요가 없다.

도 11은 본 발명의 제4실시예에 따른 연락처 제공 과정을 보인 흐름도이다. 도 11을 참조하면, 도 9에 설명했던 901단계 및 903단계, 즉 사용자 선호도를 CAB UP Application Usage에 저장 요청과 해당 응답은 생략한다. 1101단계 내지 1107단계는 도 9의 905단계 내지 911단계에서의 동작과 동일하다. 1109단계 내지 1113단계는 RCS(CAB) 서버(72)가 사용자 선호도를 요청할 필요 없이 도 9의 917단계 내지 921단계에서의 동작과 동일하다. 또한, 1115단계 내지 1121단계는 RCS(CAB) 서버(72)가 주소록 요청, 비교 및 필터 동작이 필요 없이 도 9의 929단계 내지 935단계에서의 동작과 동일하다. 1123단계에서 RCS(CAB) 클라이언트(10)는 도 4에 설명한 동작을 RCS(CAB) 서버(72) 대신 수행하고, 1125단계에서 필터 된 연락처들을 사용자에게 알리고 도 6 설명에 따라 관리한다.

상기와 같이 본 발명의 일 실시예에 따른 메시징 서비스와 타 서비스 간의 상호 연동을 통한 연락처 제공 방법 및 장치의 동작 및 구성이 이루어질 수 있으며, 한편 상기한 본 발명의 설명에서는 구체적인 실시예에 관해 설명하였으나 여러 가지 변형이 본 발명의 범위를 벗어나지 않고 실시될 수 있다.

[참조문헌]

[1] “SyncML Representation Protocol, Data Synchronization Usage”, Version 1.2, Open Mobile Alliance™, OMA-TS-DS_DataSyncRep-V1_2, URL: http://www.openmobilealliance.org/

[2] Session Initiation Protocol (SIP)-Specific Event Notification, RFC 3265, URL: http://www.ietf.org/rfc/rfc3265.txt

[3] XML Configuration Access Protocol, RFC 4825, RFC 4826, RFC 4827

Claims (17)

1. 메시징 서비스와 타 서비스 간의 상호 연동을 통한 연락처 제공 방법에 있어서,
   응용 서버가 응용 클라이언트로부터 사용자 선호도를 수신하는 과정과,
   응용 클라이언트로부터 신규 연락처 리스트 요청을 수신하는 과정과,
   신규 연락처 리스트 요청을 인터워킹 서버로 전달하는 과정과,
   상기 인터워킹 서버를 통해 서비스 공급자로부터 연락처 프로필을 수신하는 과정과,
   상기 수신한 연락처 프로필을 필터링하는 과정과,
   상기 필터링된 연락처 리스트를 상기 응용 클라이언트로 전달하는 과정을 포함함을 특징으로 하는 연락처 제공 방법.
2. 제 1항에 있어서, 상기 필터링하는 과정은,
   수신한 연락처 프로필에서 연락처 식별이 가능한 데이터를 추출하는 과정과,
   상기 추출한 연락처 식별이 가능한 데이터를 상기 응용 서버의 주소록 관리부에 저장된 주소록의 데이터와 비교하여, 상기 수신한 연락처 프로필이 상기 주소록에 저장된 데이터인지 판단하는 과정과,
   상기 수신한 연락처 프로필이 상기 주소록에 저장되지 않은 데이터인 경우, 상기 사용자 선호도에 해당하는 데이터를 상기 수신한 연락처 프로필로부터 추출하는 과정과,
   상기 추출한 상기 사용자 선호도에 해당하는 데이터가 상기 응용 서버의 선호도 관리부에 저장된 사용자 선호도와 일치하는지 판단하는 과정과,
   상기 추출한 상기 사용자 선호도에 해당하는 데이터가 상기 응용 서버의 선호도 관리부에 저장된 사용자 선호도와 일치하는 경우, 상기 수신한 연락처 프로필에 임시 연락처 표시를 추가하는 과정을 포함함을 특징으로 하는 연락처 제공 방법.
3. 제 2항에 있어서, 상기 수신한 연락처 프로필이 상기 주소록에 저장된 데이터인지 판단 결과, 상기 수신한 연락처 프로필이 상기 주소록에 저장된 데이터인 경우, 상기 수신한 연락처 프로필을 삭제하는 과정을 더 포함함을 특징으로 하는 연락처 제공 방법.
4. 제 2항에 있어서, 상기 추출한 상기 사용자 선호도에 해당하는 데이터가 상기 응용 서버의 선호도 관리부에 저장된 사용자 선호도와 일치하지 않는 경우, 상기 수신한 연락처 프로필을 삭제하는 과정을 더 포함함을 특징으로 하는 연락처 제공 방법.
5. 제 2항에 있어서, 상기 연락처 식별이 가능한 데이터는
   이름, 메일 주소, 전화번호, 제공받은 서비스 중 적어도 하나임을 특징으로 하는 연락처 제공 방법.
6. 메시징 서비스와 타 서비스 간의 상호 연동을 통한 연락처 제공을 위한 응용 서버에 있어서,
   상기 응용 서버가 동작하기 위해 필요한 데이터를 저장하며, 서비스 공급자로부터 수신한 연락처 프로필 리스트를 저장하기 위한 메모리와,
   다른 시스템 요소들과 정보를 송수신하기 위한 I/O 인터페이스(interface)와,
   상기 응용 클라이언트의 주소록과 동기화된 주소록 정보를 저장하기 위한 주소록 관리부와,
   응용 서버가 응용 클라이언트로부터 사용자 선호도를 수신하며, 응용 클라이언트로부터 신규 연락처 리스트 요청을 수신하며, 신규 연락처 리스트 요청을 인터워킹 서버로 전달하며, 상기 인터워킹 서버를 통해 서비스 공급자로부터 연락처 프로필을 수신하며, 상기 수신한 연락처 프로필을 필터링하며, 상기 필터링된 연락처 리스트를 상기 응용 클라이언트로 전달하는 제어부를 포함함을 특징으로 하는 응용 서버.
7. 제 6항에 있어서, 사용자로부터 수신한 사용자 선호도를 저장하기 위한 선호도 관리부를 더 포함함을 특징으로 하는 응용 서버.
8. 제 6항에 있어서, 상기 제어부는
   상기 수신한 연락처 프로필을 필터링 시, 수신한 연락처 프로필에서 연락처 식별이 가능한 데이터를 추출하며, 상기 추출한 연락처 식별이 가능한 데이터를 상기 응용 서버의 주소록 관리부에 저장된 주소록의 데이터와 비교하여, 상기 수신한 연락처 프로필이 상기 주소록에 저장된 데이터인지 판단하며, 상기 수신한 연락처 프로필이 상기 주소록에 저장되지 않은 데이터인 경우, 상기 사용자 선호도에 해당하는 데이터를 상기 수신한 연락처 프로필로부터 추출하며, 상기 추출한 상기 사용자 선호도에 해당하는 데이터가 상기 응용 서버의 선호도 관리부에 저장된 사용자 선호도와 일치하는지 판단하며, 상기 추출한 상기 사용자 선호도에 해당하는 데이터가 상기 응용 서버의 선호도 관리부에 저장된 사용자 선호도와 일치하는 경우, 상기 수신한 연락처 프로필에 임시 연락처 표시를 추가하는 것을 특징으로 하는 응용 서버.
9. 제 8항에 있어서, 상기 제어부는
   상기 수신한 연락처 프로필이 상기 주소록에 저장된 데이터인지 판단 결과, 상기 수신한 연락처 프로필이 상기 주소록에 저장된 데이터인 경우, 상기 수신한 연락처 프로필을 삭제하는 것을 특징으로 하는 응용 서버.
10. 제 8항에 있어서, 상기 제어부는
    상기 추출한 상기 사용자 선호도에 해당하는 데이터가 상기 응용 서버의 선호도 관리부에 저장된 사용자 선호도와 일치하지 않는 경우, 상기 수신한 연락처 프로필을 삭제하는 것을 특징으로 하는 응용 서버.
11. 제 8항에 있어서, 상기 연락처 식별이 가능한 데이터는
    이름, 메일 주소, 전화번호, 제공받은 서비스 중 적어도 하나임을 특징으로 하는 응용 서버.
12. 메시징 서비스와 타 서비스 간의 상호 연동을 통해 연락처를 제공받는 방법에 있어서,
    응용 클라이언트가 응용 서버로 신규 연락처 리스트 요청을 전송하는 과정과,
    응용 클라이언트가 응용 서버로부터 필터링된 연락처 리스트를 수신하는 과정과,
    상기 수신한 필터링된 연락처 리스트를 표시하는 과정과,
    상기 수신한 필터링된 연락처 리스트를 주소록에 추가하는 과정과,
    상기 추가한 연락처 리스트를 미리 설정된 기준에 따라 삭제하는 과정을 포함함을 특징으로 하는 연락처를 제공받는 방법.
13. 제 12항에 있어서, 상기 추가한 연락처 리스트를 미리 설정된 기준에 따라 삭제하는 과정은,
    상기 추가한 연락처 프로필에 임시 표시가 있는지 확인하는 과정과,
    상기 추가한 연락처 프로필에 임시 표시가 있는 경우, 상기 임시 표시가 있는 연락처 프로필의 보관 기준을 확인하는 과정과,
    상기 보관 기준에 일치하는 경우, 주기적으로 보관 기준을 확인하는 과정과,
    상기 보관 기준이 일치하지 않는 경우, 상기 임시 표시가 있는 연락처 프로필을 삭제하는 과정을 포함함을 특징으로 하는 연락처를 제공받는 방법.
14. 제 13항에 있어서, 상기 보관 기준은, 응용 클라이언트의 위치, 미리 설정된 기간 중 적어도 하나를 포함함을 특징으로 하는 연락처를 제공받는 방법.
15. 메시징 서비스와 타 서비스 간의 상호 연동을 통해 연락처를 제공 받기 위한 응용 클라이언트에 있어서,
    상기 응용 클라이언트가 동작하기 위해 필요한 데이터를 저장하는 메모리와,
    다른 시스템 요소들과 정보를 송수신하기 위한 I/O 인터페이스(interface)와,
    주소록 정보를 저장하기 위한 주소록 관리부와,
    데이터 입출력을 위한 사용자 인터페이스와,
    응용 서버로 신규 연락처 리스트 요청을 전송하며, 상기 응용 서버로부터 필터링된 연락처 리스트를 수신하며, 상기 수신한 필터링된 연락처 리스트를 표시하며, 상기 수신한 필터링된 연락처 리스트를 주소록에 추가하며, 상기 추가한 연락처 리스트를 미리 설정된 기준에 따라 삭제하는 제어부를 포함함을 특징으로 하는 응용 클라이언트.
16. 제 15항에 있어서, 상기 제어부가 상기 추가한 연락처 리스트를 미리 설정된 기준에 따라 삭제 시,
    상기 추가한 연락처 프로필에 임시 표시가 있는지 확인하며, 상기 추가한 연락처 프로필에 임시 표시가 있는 경우, 상기 임시 표시가 있는 연락처 프로필의 보관 기준을 확인하며, 상기 보관 기준에 일치하는 경우, 주기적으로 보관 기준을 확인하며, 상기 보관 기준이 일치하지 않는 경우, 상기 임시 표시가 있는 연락처 프로필을 삭제하는 것을 포함함을 특징으로 하는 응용 클라이언트.
17. 제 16항에 있어서, 상기 보관 기준은, 응용 클라이언트의 위치, 미리 설정된 기간 중 적어도 하나를 포함함을 특징으로 하는 응용 클라이언트.

Images