KR101922985B1

KR101922985B1 - 연락처 정보의 구독을 초대하는 장치 및 방법

Info

Publication number: KR101922985B1
Application number: KR1020110131358A
Authority: KR
Inventors: 오규봉; 김욱; 이경탁
Original assignee: 삼성전자주식회사
Priority date: 2011-12-08
Filing date: 2011-12-08
Publication date: 2018-11-29
Also published as: CN103988468A; JP2015502613A; EP2789122A4; EP2789122B1; US10795963B2; JP6254530B2; KR20130082561A; US20140344215A1; CN103988468B; EP2789122A1; WO2013085342A1

Abstract

다양한 실시예에 따르면, 통합 주소록 문서 관리 서버(converged address book XML Document Management Server, CAB XDMS)에서 연락처 정보의 구독을 초대하는 방법에 있어서, 제1 클라이언트로부터 제1 클라이언트의 연락처 뷰의 일부에 대해 구독하도록 제2 클라이언트를 초대하기 위한 연락처 공유 요청을 수신하는 과정과, 상기 연락처 공유 요청을 상기 제1 클라이언트와 연관된 CAB 서버에 통지하는 과정과, 상기 연락처 공유 요청의 통지에 응답하여, 상기 CAB 서버에 의해 업데이트되는 상기 제2 클라이언트에 대한 액세스 권한 문서(access permission document)를 저장하는 과정과, 상기 CAB 서버로부터 연락처 공유를 위한 포워드 요청을 수신하는 과정과, 상기 제2 클라이언트와 연관된 CAB XDMS에 연락처 공유를 위한 원격 요청을 전송하는 과정을 포함하고, 상기 포워드 요청은, 상기 연락처 뷰의 일부에 대한 구독을 허용하는 조건 및 상기 제2 클라이언트를 초대하는 초대 메시지를 포함하고, 상기 원격 요청은, 상기 연락처 뷰의 일부를 수신할 수 있는 주소 정보를 포함하는 것을 특징으로 한다.

Description

연락처 정보의 구독을 초대하는 장치 및 방법{APPARATUS AND METHOD FOR INVITING SUBSCRIPTION OF CONTACT INFORMATION}

본 발명은 통합주소록 서비스(Converged Address Book: CAB)에 관한 것으로, 특히 통합주소록 서비스를 기반으로 한 연락처 정보의 구독을 초대하는 장치 및 방법에 관한 것이다.

통합주소록(Converged Address Book: CAB) 서비스는 사용자가 가진 다양한 단말에서 이용 가능한 주소 정보를 저장하고 이 정보를 언제, 어디서, 어떤 장치로도 접근 가능하게 하며, 주소 정보를 동기화하는 단일 네트워크 기반의 주소록 서비스이다. 이러한 통합주소록 서비스는 네트워크에 단일 네트워크 주소록을 저장함으로써 주소록에 대한 사용자의 경험과 기능을 향상시키는 목적으로 제공되는 서비스이다. 이러한 통합주소록 서비스의 주요 기능으로는 주소록 동기화, 연락처 구독(Contact Subscription), 연락처 공유(Contact Share), 연락처 검색(Contact Search), 비통합주소록(non-CAB) 시스템으로부터 외부 주소록 가져오기 등의 기능이 있다.

그 중에서도 연락처 구독 기능의 경우 발신측에서 수신측으로 하여금 자신의 연락처를 구독하도록 초대하는 방법이 있다. 이를 위해 종래에는 도 1에 도시된 바와 같이 구독 요청 대상의 정보를 직접 수신측으로 전달하여 저장한 후, 연락처 상태 정보를 전달하는 형태로 구현된다.

도 1을 참조하면, CAB 클라이언트A(10)는 1단계에서 구독 초대 요청(subscription invitation request))을 CAB 서버(20)에 저장하면, CAB 서버(20)에서는 CAB 클라이언트A(10)의 연락처 정보를 CAB 클라이언트B(60)의 사용자B가 구독하도록 초대하기 위해 일련의 동작을 수행하게 된다. 하지만, 종래에는 CAB 클라이언트B(60)의 구독 허락 여부와 상관없이 4단계에서 CAB 클라이언트A(10)의 모든 연락처 정보가 일단 CAB 클라이언트B(60)가 속한 CAB 서버(50)로 전달되게 된다. 5단계에서는 구독을 허락한 경우 6단계에서 구독 요청 대상 정보 즉, 수신받은 모든 연락처 정보와 구독 초대가 저장되어, 7단계에서 CAB 클라이언트B(60)의 사용자B는 사용자A가 사용자A의 연락처 정보 구독에 대해 초대했음을 알게 된다. 또한 5단계에서 구독을 허락하지 않은 경우 수신받은 모든 연락처 정보를 저장하지 않는다.

상기한 바와 같이, CAB 클라이언트A(10)는 CAB 클라이언트B(60)로 하여금 사용자A의 연락처 정보를 구독하도록 초대하나, 4단계에서는 사용자A의 모든 연락처 정보가 전달되므로, 사용자 A의 입장에서는 자신의 연락처 정보 중 일부만을 사용자B와 공유하고자 하더라도 이를 지원할 방법이 없는 실정이다. 게다가 CAB 클라이언트B(60)가 구독 초대의 허락 또는 거절 여부에 상관없이 무조건 실제 연락처 정보가 사용자A측의 CAB 서버(20)로부터 사용자B측의 CAB 서버(50)로 전달되므로, 프로세싱 용량의 비효율성 및 CAB 서버 및 CAB XDMS 내 불필요한 저장공간을 소모해야 하는 관계로 효율성 측면에서도 바람직하지 않게 된다.

또한, CAB 클라이언트B(60)의 사용자B의 입장에서는 5단계에서 이러한 구독에 대해 거절을 설정한 경우, CAB 클라이언트A(10)의 연락처 정보의 구독 요청뿐만 아니라 다른 모든 클라이언트로부터의 요청도 일괄적으로 거절되게 된다. 즉, 클라이언트별로 수락 또는 거절을 설정할 수 없는 실정이다. 따라서, 효율적으로 연락처 정보의 구독 초대를 할 수 있는 방법이 요구되는 실정이다.

따라서 본 발명은 효율적으로 연락처 정보의 구독 초대를 할 수 있는 장치 및 방법을 제공한다.

또한 본 발명은 연락처 정보 중 일분만을 선택적으로 구독할 것을 초대하는 장치 및 방법을 제공한다.

상기한 바를 달성하기 위한 본 발명은, 통합주소록 서버에서 연락처 정보의 구독을 초대하는 방법에 있어서,

제1클라이언트로부터 제1클라이언트의 특정 연락처 정보의 구독 초대 요청을 수신하는 과정과, 상기 구독 초대 요청에 상기 특정 연락처 정보에 대해 구독을 허용하는 조건이 포함되어 있는지를 판단하고, 상기 조건이 포함된 경우 상기 조건 및 상기 특정 연락처 정보를 제공받을 수 있는 주소 정보를 포함하는 구독 요청을 제2클라이언트로 보내는 과정을 포함함을 특징으로 한다.

본 발명에 따르면, 본 발명에서 제안된 시스템 및 방법을 통해, 사용자에게 보다 효율적인 연락처 정보 관리 방법을 제공할 수 있게 된다. 또한 본 발명은 발신측 입장에서는 전체 연락처 정보 중 원하는 부분만을 구독할 것을 요청할 수 있으며, 수신측 입장에서는 원하는 클라이언트의 연락처 정보만을 선택적으로 제공받을 수 있게 된다. 게다가 실제 연락처 정보 대신 연락처 정보에 대한 주소 정보를 전달함으로써 전송 효율이 증대되는 이점이 있을 뿐만 아니라 CAB 서버 및 CAB XDMS의 저장 효율을 증대시킬 수 있게 된다.

도 1은 종래의 연락처 정보의 구독 초대 방식을 설명하기 위한 도면,
도 2는 본 발명의 실시예에 따른 연락처 정보의 구독 초대를 위한 시스템 구성도,
도 3은 본 발명의 실시예에 따른 연락처 정보의 구독 초대 과정을 나타낸 도면,
도 4는 상기 도 3의 상세 과정을 나타낸 도면,
도 5는 상기 도 3의 연락처 공유 요청 메시지의 예시도,
도 6는 상기 도 3의 수신자의 구독 허용을 위한 접속 권한 문서의 예시도,
도 7은 상기 도 4의 XDCP 포워드 요청 메시지의 예시도,
도 8은 상기 도 4의 XDCP 포워드 원격 요청 메시지의 예시도,
도 9는 본 발명의 실시예에 따라 수락 상태인 경우의 연락처 정보 구독 초대 과정을 나타낸 도면,
도 10은 상기 도 9의 연락처 상태의 예시도,
도 11은 상기 도 9의 요청 통지 리스트의 예시도.

이하 본 발명의 바람직한 실시예들을 첨부한 도면을 참조하여 상세히 설명한다. 도면들 중 동일한 구성 요소들은 가능한 한 어느 곳에서든지 동일한 부호들로 나타내고 있음에 유의해야 한다. 또한 본 발명의 요지를 불필요하게 흐릴 수 있는 공지 기능 및 구성에 대한 상세한 설명은 생략한다.

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

본 발명은 효율적으로 연락처(contact) 정보의 구독 초대를 하기 위한 방법을 제안한다. 이를 위해 본 발명은 제1클라이언트에서 제1클라이언트의 특정 연락처 정보의 구독 초대를 요청하면, CAB 서버가 특정 연락처 정보에 대해 구독을 허용하는 조건이 포함되어 있는지를 판단하고, 상기 조건이 포함된 경우 상기 조건 및 상기 특정 연락처 정보의 주소 정보를 포함하는 구독 요청을 제2클라이언트로 보내는 과정으로 이루어진다. 이렇게 함으로써 다양한 형태의 통신 서비스를 지원하는 통신 시스템에서 자원과 전력 및 메모리의 낭비 없이 고속으로 통신 서비스를 제공할 수 있게 된다. 또한, 사용자의 의사 선택에 따라 손쉽고 빠르게 CAB 서비스가 가능한 데이터 송수신 방법을 제공할 수 있게 된다.

도 2를 통해 OMA CAB의 개념적인 구조를 살펴보면, CAB 서비스 시스템은 통합주소록(이하, CAB) 클라이언트(100), CAB 서버(110), CAB 문서 관리 서버(XML Document Management Server: XDMS)(이하, CAB XDMS)(120), 비통합주소록(이하, non-CAB) 시스템(130) 등으로 구성된다.

먼저, CAB 클라이언트(100)는 단말 상에서 CAB 서버(110)와 통신을 하며 CAB 사용자 인증, 개인연락카드 정보(Personal Contact Card: 이하, 'PCC'이라함.)와 네트워크 저장소에 저장된 통합 주소록의 동기화 그리고 CAB 사용자의 요구사항, 예를 들면 주소 구독(subscription), 주소 찾기, 주소 공유, 기존 주소록과의 상호작용 또는 사용자 선호도의 관리 등을 CAB 서버(110)에게 전송하는 역할을 담당한다.

특히 본 발명의 실시예에 따른 CAB 클라이언트(100)는 사용자A의 단말을 의미하며, 사용자A의 요청에 따라 사용자A 보유의 연락처 정보에 대한 구독을 사용자B에게 권유하기 위한 연락처 공유 요청을 전송하는 역할을 한다. 이러한 연락처 공유 요청에는 개인 정보(PCC) 중 연락처 뷰(contact view)의 일부분을 허용하기 위한 조건으로써 필터값이 포함된다. 이러한 연락처 공유 요청은 사용자B에게 사용자A의 일부 연락처 정보를 구독하라는 요청을 의미하며, 특히 구독 요청하는 일부 연락처 정보가 무엇인지 알리기 위해 필터값이 포함될 수 있다.

여기서, 본 발명의 실시예에 따른 연락처 정보는 주소록, 명함 정보, 개인정보(PCC) 중 적어도 하나를 포함하며, 이러한 연락처 뷰는 개인 정보 중 사용자가 필요에 따라 예컨대, 이름, 전화번호, 이메일 등의 일부 정보를 하나의 그룹으로 묶은 것을 지칭한다. 즉, 전체 연락처 정보 중 공유를 위해 일부를 선택적으로 추출하여 서브셋(subset)으로 만든 것을 의미한다.

CAB 서버(110)는 CAB 구조에서 주요한 네트워크 구성요소로써, CAB 클라이언트(100)로부터 CAB 사용자의 요청사항을 받아 처리하는 역할을 담당한다. CAB 서버(110)의 주요 기능으로는 CAB 클라이언트 상호인증, CAB 주소의 저장, 주소 정보 동기화, 주소 구독 기능으로부터의 주소 정보 갱신을 받아 주소록에 반영하는 역할을 한다.

CAB 서버(110)는 주소 구독/공유/변환 및 사용자의 선호도/정책 등을 반영하는 네트워크 운영에 대한 동작을 수행한다. 또한, 기존 주소록 시스템과 연계 또는 외부 인에이블러에 인터페이스를 노출하는 인터워킹 기능(IWF) 등이 있다.

이러한 CAB 서버(110)는 CAB 클라이언트(100)로부터 연락처 정보의 선택적인 구독 허용을 위한 필터값을 포함하는 연락처 공유 요청을 수신한다. 그러면, CAB 서버(110)는 이러한 필터값에 따라 선택된 CAB 클라이언트(100)의 특정 연락처 정보를 제공받을 수 있는 주소 정보를 생성한다. 이렇게 새롭게 생성된 주소 정보를 포함하는 요청은 사용자A가 속한 CAB 서버(예로, XDMS(120))을 통해 사용자B가 속한 CAB 서버(예로, XDMS(140))로 전달되게 된다. 이와 같이 CAB 서버(110)에서는 전송 부하량을 줄일 수 있도록 실제 연락처 정보 대신 연락처 정보를 제공받을 수 있는 주소 정보 예컨대, URL 정보를 새롭게 만들어 제공하는 역할을 한다.

사용자의 데이터를 관리하는 CAB XDMS(120)에는 통합 주소록 및 기존 사용자와 CAB 사용자를 구분하기 위한 연락처 상태를 저장하는 통합주소록 주소록 어플리케이션 사용부(CAB AB App(Address Book Application) Usage), 사용자의 선호도를 저장하는 통합주소록 사용자선호도 어플리케이션 사용부(CAB UP App((User Preference Application) Usage), 개인연락카드 정보를 저장하는 통합주소록 개인연락카드 어플리케이션 사용부(CAB PCC App(Personal Contact Card Application) Usage) 및 CAB 서비스 요청 및 응답을 관리하는 통합주소록 기능 구동 어플리케이션 사용부(CAB FH App(Feature Handler Application) Usage) 등이 있다. 이외에 다양한 어플리케이션 사용부(App Usage) 기능에 접속하기 위한 XDMC, 외부 도메인의 엔티티들과의 메시지 라우팅을 위한 SIP/IP 코어 네트워크, non-SIP 단말들의 통보 메시지 전달을 위한 PUSH 인에이블러 등이 있다.

본 발명의 실시예에서는 도 2의 통합 주소록 시스템 내 연락처 정보 예컨대, 개인 프로파일 정보(PCC information)에 대해 다른 사용자에게 개인 프로파일 정보를 구독하라고 초대하고자 하는 경우, 정형화된 초청 메시지(예로, “연락처 구독 초대”(contact subscription invitation))를 포함하는 연락처 공유를 요청하는 신규 스키마(schema)를 CAB Feature Handler App. Usage내에 정의한다. 반면, CAB 서버(110)에서는 해당 연락처 공유 요청에 대해 수신자의 개인 프로파일 정보 구독을 위한 권한을 허용하고, 해당 연락처 공유 요청을 수신측으로 전송하고, 수신자가 설정해 놓은 타인의 구독 요청에 관한 사용자 선호도 즉 수락, 거부 및 확인에 따라 해당 개인 프로파일 정보 구독 초청을 포함하는 연락처 공유 요청을 처리함으로써, 최종적으로 연락처 상태 정보의 형태로 수신자로 하여금 연락처 정보 구독을 초대하는 방법을 제안하는 것이다. 여기서, 사용자 선호도 확인이란, 타인의 구독 요청에 대해 수신자에게 구독 요청 사실을 통보하여 수락여부를 묻도록 설정하였다는 것을 말한다.

이를 구체적으로 살펴보기 위해 본 발명의 실시예에 따른 연락처 정보의 구독 초대 과정을 나타낸 도 3을 참조하여 설명하기로 한다. 도 3에서는 XML 문서 전송을 통한 연락처 정보 구독 초대 방법을 예시하고 있다.

도 3을 참조하면, 300단계에서 CAB 클라이언트A(100)는 연락처 공유 요청을 CAB XDMS(120) 내 CAB Feature Handler App. Usage로 보낸다. 이때, 연락처 공유 요청을 위해 XCAP(XML Configuration Access Protocol) request가 사용된다. 이러한 연락처 공유 요청에는 개인 정보(PCC) 중 특정 연락처 뷰에 대해 수신자 예컨대,(XUI: sip:[email protected])에게 연락처 정보 구독 초대를 위한 정형화된 초청 메시지와, 연락처 뷰의 일부분만 구독을 허용하기 위한 선택적인 필터값을 포함한다. 또한 정형화된 초청 메시지는 수신자의 상기 연락처 정보 구독 초대 메시지를 수신한 서버에서 자동으로 생성할 수 있음은 자명하다.

이에 대응하여 305단계에서 CAB XDMS(120)는 연락처 공유 요청을 통지한다. 이를 위해 CAB XDMS(120)내의 CAB Feature Handler App. Usage는 CAB Feature Handler의 문서 변경(document change) 즉, 연락처 공유 요청에 대한 문서 갱신 정보를 CAB 서버(110) 내 연락처 공유 기능부(Contact Share function)(105)에게 알려준다.

310단계에서 CAB 서버(110)는 수신자에 대한 접속 권한 문서를 업데이트한다. 구체적으로, CAB XDMS(120) 내 PCC App. Usage에 발신자의 연락처 정보 구독 초대에 따른 수신자의 구독 허용을 위해 305단계에서 획득한 연락처 공유 요청에 대한 문서 갱신 정보를 바탕으로 접속 권한(Access Permission) 문서를 갱신한다. 이때 연락처 정보 구독 제한을 위해 포함된 필터 정보 또한 접속 권한 문서에 반영된다. 이는 미리 수신자 예컨대, 사용자B가 발신자 예컨대, 사용자A의 연락처 정보를 구독할 수 있도록 인증하는 과정에 해당한다. CAB 서버(110)는 사용자A의 다수 수신자에 대해 연락처 정보로부터 각각 서로 다른 복수개의 구독 허여 요청을 받을 수 있고, 이를 관리하는 역할 즉, 사용자A에 대하여 복수개의 구독 허여 요청에 대하여 생성, 갱신, 삭제 등을 수행할 수 있다.

이어, CAB 서버(110)는 315단계에서 요청을 포워드한다. 이러한 요청의 전달을 위해 CAB 서버(110)는 XDCP Forward request을 생성하여 이를 이용한다. 이러한 XDCP Forward request는 연락처 정보 구독 초대를 위한 정형화된 메시지와 연락처 뷰의 일부분만을 구독 허용하기 위한 필터값을 포함한다. 특히 CAB 서버(110)는 이러한 특정 연락처 정보를 실제 제공받을 수 있는 URL 정보를 생성하여 이를 상기 Forward request에 포함시켜 전송한다. 이와 같이 본 발명에서는 종래의 'SIP MESSAGE' 대신 'HTTP POST'를 이용하므로 실제 연락처 정보가 가는 대신 연락처 정보를 제공받을 수 있는 정보만을 보낼 수 있을 뿐만 아니라 필터값을 통해 부분적인 연락처 정보를 제공하는 것도 가능하다.

이러한 XDCP Forward request은 CAB XDMS(120) 내 PCC App. Usage로 전달되며, 발신자 즉, 사용자A가 구독 초대를 위해 지정한 특정 연락처 뷰에 대해 일부분만을 구독 허용하기 위한 상기 필터를 적용하여 새로운 연락처 뷰를 생성한 후 이를 임시저장공간 또는 PCC App. Usage내 별도의 문서 저장공간에 저장한다. 이어, CAB XDMS(120)는 320단계에서 상기 문서에 대한 URI값과 연락처 정보 구독 초대를 위한 정형화된 메시지를 포함하는 원격 요청을 포워드한다. 또한 전체 연락처 정보로부터 상기 필터를 적용하여 특정 연락처 뷰만 특정 수신자에게 보일 수 있도록 URI값을 생성할 수도 있다. 이러한 원격 요청을 위해 XDCP Forward Remote request가 사용된다.

이러한 XDCP Forward Remote request은 수신측 즉, 사용자B가 속한 CAB XDMS(120)으로 전달된다. 그러면 325단계에서 CAB XDMS(120)의 PCC App. Usage는 수신한 XDCP Forward Remote request를 바탕으로 원격 요청을 처리한다. 즉, CAB XDMS(120)은 사용자 B의 주소록 문서 전송에 관한 선호도 확인을 수행한다. 주소록 문서 전송에 관한 선호도에는 수락, 거부 및 확인 등의 설정이 있을 수 있다. 수락은 사용자 B가 타인의 구독 요청이 있을시 사용자 B에 문의없이 바로 전달받은 문서를 저장하도록 한다는 것이고, 거부는 타인의 구독 요청을 받아들이지 않는다는 의미이며, 확인인 경우에는 타인의 구독 요청에 대하여 사용자 B에게 타인의 구독 요청을 알리고 사용자 B로부터 구독 요청에 대한 응답(예로, 수락 혹은 거부)을 받아 처리하는 것을 의미한다. 따라서, 선호도가 수락인 경우에 사용자A측으로부터 전달받은 문서의 URI 값을 이용하여 연락처 정보 구독 초대에 사용될 문서가 저장되어 있는 서버로부터 가져와서(Fetch) 임시문서 예컨대,ContactInvitationPCC.xml 형태로 저장한다.

330단계에서 수신측 CAB 서버(140)는 CAB XDMS(120)의 PCC App. Usage로부터 임시 문서를 통보받는다. 구체적으로, 임시문서인 ‘ContactSharePCC.xml’ 및 상기 ‘note’ 엘리먼트를 포함하는 연락처 초대 문서(Contact Invitation document)를 문서 변경으로 통보받거나 ‘ContactInvitationPCC.xml’ 및 상기 ‘note’ 엘리먼트를 포함하는 연락처 초대 문서(Contact Invitation document)를 문서 변경으로 통보받을 수 있다.

335단계에서 CAB 서버(140)는 연락처 엔트리를 저장한다. 이를 위해 이러한 연락처 엔트리의 예로는, 주소가 있으며 이러한 주소 공유 데이터를 주소록 포맷에 맞게 변환한 후, 이를 CAB XDMS(120)의 AB App. Usage내 주소록 문서(AB document)내에 추가한다. 또한, 330단계에서의 연락처 초대 문서(Contact Invitation document)를 참조하여 그에 대한 연락처 상태(contact status)로서 주소 타입과 엔트리 상태로서 갱신 형태(<updated>)와 발신자로부터 전달된 연락처 정보 구독 초대를 위한 정형화된 메시지(또는 표현)인 <note> 엘리먼트 등을 표시한다.

이후, CAB 서버(140)는 340단계에서 CAB 클라이언트B(150)의 주소록 동기화를 위해 AB App. Usage에 발생한 문서 변경을 포함하는 서버 알림 메시지를 보낸다. 이렇게 함으로써 CAB 클라이언트B(150)의 사용자B는 주소록 동기화를 통해 사용자A에서 구독을 허용한 연락처 정보를 볼 수 있게 된다.

이하, 상기 도 3의 보다 구체적으로 살펴보기 위해 도 4를 참조한다. 도 4는 발신측에서의 연락처 정보 공유를 위한 상세 내용을 예시하고 있다.

도 4를 참조하면, 400단계는 상기 도 3의 300단계와 동일하며, 보다 상세히 설명하면 연락처 공유 요청에는 이러한 공유 요청에 대한 결과 보고 및 그 공유 요청 내 'note' 엘리먼트에 ‘contact subscription invitation’ 이라는 연락처 정보 구독 초대를 위한 정형화된 메시지가 포함된다. 이러한 연락처 공유 요청을 위한 메시지를 예시하면 도 5에 도시된 바와 같다.

도 5를 참조하면, 상기 ‘note’ 엘리먼트에 ‘contact subscription invitation’ 이라는 정형화된 메시지는 이후 발신측 및 수신측에서 연락처 공유 요청이 발신자의 연락처 정보 구독 초대를 위한 연락처 공유 요청임을 나타내는 지시(indication) 역할을 한다. 또한 도 5에서는 ‘invite-include’라는 filter id를 통해 발신자의 연락처 정보 중 중 이름(name), 연락처(comm-addr), 경력(career-history)만 최종적으로 수신자(XUI: sip:[email protected])가 연락처 정보 구독 초대에 응해 발신자의 연락처 정보 구독을 시도하는 경우 구독하거나 읽을 수 있도록 해당 문서의 일부값만 구독 허용하기 위한 필터값을 설정한 경우를 예시하고 있다.

405단계에서 CAB XDMS(120)의 CAB Feature Handler App. Usage는 전달받은 XCAP request를 저장하고 응답 메시지(200 OK)를 CAB 클라이언트A(100)에게 보낸다.

410단계에서 CAB Feature Handler App. Usage는 CAB Feature Handler의 document change 즉, 해당 연락처 공유 요청에 대한 문서 갱신 정보를 CAB 서버(110) 내 연락처 공유 기능부(Contact Share function)(105)에게 알려준다. 여기서는 CAB Feature Handler App. Usage가 변경정보를 통보하는 것과 별도로 연락처 공유 기능부(105)가 능동적으로 연락처 공유 요청 메시지의 저장 여부를 확인해 CAB Feature Handler내 변경 정보를 획득할 수도 있다.

이에 대응하여 415단계에서 연락처 공유 기능부(105)는 응답 메시지(200 OK)를 CAB Feature Handler App. Usage에 보낸다. 이어, 420단계는 도 3의 310단계에서와 동일하다. 보다 상세히 설명하면, 연락처 공유 기능부(105)는 XDM Agent로 하여금 해당 PCC App. Usage내 발신자의 연락처 정보 구독 초대에 따른 수신자의 구독 허용을 위해 410단계에서 획득한 연락처 공유 요청에 대한 문서 갱신 정보내 수신자 정보 및 연락처 정보 구독 제한을 위해 포함된 필터 정보를 바탕으로 접속 권한(Access Permission) 문서를 갱신한다.

도 6에서는 PCC App. Usage내 연락처 정보 구독 초대에 따른 수신자의 구독 허용을 위한 접속 권한 문서의 예시를 보이고 있다.

도 6을 참조하면, 발신자(XUI: sip:[email protected])의 연락처 정보 중 개인 정보(PCC)에 대한 문서룰(document-rule)인 ‘allow-retrieve’의 경우 발신자의 연락처 정보 전체를 수신자가 구독하거나 읽을 수 있다는 의미이다. 또한, 410단계에서 획득한 연락처 공유 요청에 대한 문서 갱신 정보내 수신자(XUI: sip:[email protected]) 정보 및 연락처 정보 구독 제한을 위해 포함된 필터 정보(‘invite-include’)를 바탕으로 접속 권한(Access Permission) 문서를 갱신함으로써 발신자의 개인 정보 중 이름(name), 연락처(comm-addr), 경력(career-history)만 최종적으로 수신자가 연락처 정보 구독 초대에 응해 발신자의 연락처 정보 구독을 시도하는 경우 구독하거나 읽을 수 있도록 허용한 것이다.

425단계에서 연락처 공유 기능부(105)는 응답 메시지(200 OK)를 PCC App. Usage로부터 수신한 후, 430단계에서 XDM Agent로 하여금 해당 PCC App. Usage에 연락처 정보를 공유하도록 하기 위해 XDCP Forward request를 생성하여 전송한다. 이때, 410단계에서 획득한 연락처 뷰의 일부값만 구독 허용하기 위한 필터 정보를 포함시킨다. 또한, XDCP Forward request내 ‘note’ 엘리먼트에 ‘contact subscription invitation’ 이라는 연락처 정보 구독 초대를 위한 정형화된 메시지(또는 표현)도 포함시킨다. 이러한 연락처 공유 기능부(105)에서 생성한 XDCP Forward request를 예시하면 도 7에서와 같다.

이어, 435에서 PCC App. Usage는 우선적으로 발신자의 연락처 공유에 대한 전송 보고(Contact Share Delivery Report) 요청 여부를 확인한다. 이어, 전송 결과의 발신자 통보를 위해 List XDMS의 Forward Notification List(이하 ‘FNL) App. Usage내 전달 통보 리스트(<forward-notification-list>) 엘리먼트의 전송 통보 리스트(<delivery-notification-list>) 엘리먼트에 상기 ‘note’ 엘리먼트를 포함하고 해당 수신자의 전송 상태값을 ‘전송중(pending)’으로 하여 관련 정보를 갱신한다. 이에 대응하여 440단계에서 PCC App. Usage는 응답 메시지(200 OK)를 List XDMS(125)로부터 수신한다.

그러면 PCC App. Usage는 상기 XDCP Forward request를 바탕으로, 수신자가 다른 도메인의 사용자임을 확인하고, 발신자가 구독 초대를 위해 지정한 특정 연락처 뷰에 대해 일부 값만 구독 허용하기 위한 상기 필터를 적용한 후 이를 임시저장공간 또는 PCC App. Usage내 별도의 문서 저장공간에 저장한다.

그리고나서 445단계에서 그 문서에 대한 URI값과 개인 정보 구독 초대를 위한 정형화된 메시지를 포함한 XDCP Forward Remote request를 수신측으로 보낸다. 이러한 발신측 PCC App. Usage가 생성하는 XDCP Forward Remote request의 예시하면 도 8에 도시된 바와 같다. 이후, 450단계에서 PCC App. Usage는 수신측 네트워크(127&129)부터 전송 결과에 대한 응답 메시지(200 OK)를 수신한다. 그러면 455단계에서 PCC App. Usage는 전송 결과에 대한 응답 메시지(200 OK)로부터 XDCP Forward request에 대한 응답 메시지(200 OK)를 생성한다.

이후, 연락처 공유 기능부(105)는 460단계에서 포워딩 결과를 저장한다. 즉, CAB Feature Handler App. Usage에 전송 결과를 저장하고, 465단계에서 CAB Feature Handler App. Usage는 응답 메시지(200 OK)를 연락처 공유 기능부(105)에 보낸다.

470단계에서 PCC App. Usage는 수신측 네트워크(127&129)로부터 연락처 공유 전송 보고(Contact Share Delivery Report)를 수신한다. 이에 대한 응답으로 475단계에서 PCC App. Usage는 수신측 네트워크(127&129)로 응답 메시지(200 OK)를 전송한다.

그러면 PCC App. Usage는 480단계에서 포워드 통지 리스트를 업데이트한다. 구체적으로 전송 결과의 발신자 통보를 위해 List XDMS의 Forward Notification List(이하 ‘FNL) App. Usage내 전달 통보 리스트(<forward-notification-list>) 엘리먼트의 전송 통보 리스트(<delivery-notification-list>) 엘리먼트에 해당 수신자의 전송 상태값을 ‘전송완료(delivered)’으로 하여 관련 정보를 갱신한다. 이러한 갱신이 완료되면, 485단계에서 PCC App. Usage는 응답 메시지(200 OK)를 List XDMS(125)로부터 수신한다.

이후 490단계에서 CAB 서버(120) 내 XDM Agent는 전송 보고에 대한 결과를 통보받아 CAB FH App. Usage내 해당 연락처 공유 요청의 전송 상태를 갱신한다.

한편, 도 9에서는 수신자의 XML 문서 전송에 대한 사용자 선호도를 수락(accept)으로 설정한 경우에 대해 개인 정보 구독을 초대하는 방법의 상세 내용을 예시하고 있다.

도 9를 참조하면, 900단계에서 CAB 클라이언트B(150)가 속한 PCC App. Usage는 발신측 네트워크(127&129)로부터 XDCP Forward Remote request를 수신한다. 그러면 905단계에서 PCC App. Usage는 XDCP Forward Remote request 내 수신자가 해당 도메인 내에 있는지 확인 후 응답 메시지(200 OK)를 CAB 클라이언트A(100)가 속한 PCC App. Usage로 보낸다.

이어, 910단계에서 CAB XDMS(120)의 PCC App. Usage는 AB App. Usage내 AB forward 선호도로부터 XDCP Forward Remote request에 대한 CAB 클라이언트B(150)의 선호도를 확인한다. AB forward 선호도에는 다음 세 가지의 경우가 있는데 여기에서는 CAB 클라이언트B(150가 CAB 클라이언트A(100)로부터 수신한 XDM Resource를 수신하는(accept) 경우이다.

만일 선호도가 수락((accept)일 경우 915단계에서 발신측으로부터 전송된 XDM Resource를 해당 XDM 서버에 자동으로 저장한다. 반면, 선호도가 확인(confirm)일 경우 발신측으로부터 전송된 XDM Resource를 수신자에게 알려준 후 그에 대한 결정을 기다린다. 그러나 선호도가 거절(reject)인 경우에는 발신측으로부터 전송된 XDM Resource를 해당 XDM 서버가 저장하지 않고 거절한다. 게다가 선호가 거절인 경우에는 920단계 이하의 단계들은 수행되지 않는다.

구체적으로, 수신측 PCC App. Usage는 XDCP Forward Remote request에 포함된 문서 URI 즉, 구독 초대를 위해 발신자가 지정한 특정 연락처 뷰에 대해 일부값만 구독 허용하기 위해 발신자가 설정한 필터값이 적용되어 발신측 PCC App. Usage내 일시저장공간 또는 별도 저장공간에 저장된 문서의 URI를 이용하여 XDM Resource를 발신측 PCC App. Usage로부터 가져온다. 그리고 나서 기존 주소 공유 요청의 방법에서 보인 ‘ContactSharePCC.xml’ 형태의 문서로 저장하거나 XDCP Forward Remote request에 포함된 ‘note’ 엘리먼트에 ‘contact subscription invitation’ 이라는 개인 정보 구독 초대를 위한 정형화된 메시지(또는 표현)를 확인하고 ‘ContactInvitationPCC.xml’ 과 같은 신규 형태의 문서로 저장한다. 예컨대, ‘ContactSharePCC.xml’의 형태로 저장할 수 있다.

이어, 920단계에서 CAB 서버(140)는 수신측 PCC App. Usage로부터 임시 문서를 통보받는다. 구체적으로, ‘ContactSharePCC.xml’ 및 상기 ‘note’ 엘리먼트를 포함하는 Contact Invitation document를 document change로 통보 받거나 ‘ContactInvitationPCC.xml’ 및 상기 ‘note’ 엘리먼트를 포함하는 Contact Invitation document를 document change로 통보받는다. 아울러 시스템 구현에 따라서는 앞서 언급한 ‘note’ 엘리먼트를 포함하는 Contact Invitation document를 별도로 생성하여 포함하지 않고 통보 요청 메시지(SIP NOTIFY)내 신규 헤더 형태로 포함시킬 수 있다. 예를 들어, ‘ContactSharePCC.xml’ 및 Contact Invitation document 형태로 document change를 통보 받는 것으로 한다. CAB 서버(140)가 수신측 PCC App. Usage로부터 상기 정보를 통보 받는 것과 별도로 능동적으로 수신측 PCC App. Usage내 해당 문서의 변경 정보를 획득할 수도 있다.

이에 대응하여 CAB 서버(140)는 925단계에서 응답 메시지(200 OK)를 PCC App. Usage에 보낸 후, 930단계에서 주소록을 업데이트한다. 구체적으로, CAB 서버(140)는 연락처 정보 공유 데이터를 AB format으로 변환 후, 이를 AB App. Usage내 AB document내에 추가한다. 그리고나서 연락처 초대 문서(Contact Invitation document) 또는 통보 요청 메시지내 포함된 ‘note’ 관련 헤더를 참조하여 그에 대한 연락처 상태(contact status)로서 아래와 같이 주소 타입과 엔트리 상태로서 갱신 형태(<updated>)와 발신자로부터 전달된 개인 정보 구독 초대를 위한 정형화된 메시지(또는 표현)인 <note> 엘리먼트 등을 표시한다.

이러한 연락처 상태를 예시하면 도 10과 같다. 도 10에서는 AB document내 연락처 공유 데이터와 더불어 연락처 정보 구독 초대를 위해 추가되는 연락처 상태를 예시하고 있다.

이후, 935단계에서 AB App. Usage는 응답 메시지(200 OK)를 CAB 서버(140)에 보낸다.

940단계에서 PCC App. Usage는 수신한 XDCP Forward remote request의 상세 사항을 수신자에게 통보하기 위해 위해 List XDMS(132)의 Forward Notification List내 <request-notification-list> 엘리먼트를 추가한다. 이때, 연락처 정보 공유 요청내 연락처 정보 구독 초대를 위한 정형화된 메시지(또는 표현)인 'note' 엘리먼트를 함께 저장한다. 이러한 List XDMS(132)의 Forward Notification List내 'note' 엘리먼트를 포함하는 <request-notification-list> 엘리먼트를 예시하면 도 11에 도시된 바와 같다.

도 11의 Request Notification List 예시에서 볼 수 있는 바와 같이 수신자는 해당 Request Notification List를 통해 발신자(XUI: sip:[email protected]) 의 정보 및 연락처 정보 구독 초대를 위한 정형화된 메시지(또는 표현) 등을 확인할 수 있다. 여기서는, List XDMS(132)의 해당 Request Notification List 변경정보를 수신자에게 통보하는 것과 수신자가 능동적으로 List XDMS(132)의 해당 Request Notification List를 확인해 List XDMS(132)의 해당 Request Notification List 변경 정보를 획득할 수도 있다.

945단계에서 List XDMS(132)는 응답 메시지(200 OK)를 PCC App. Usage에 보낸다. 이어, 950단계에서 CAB XDMS(120)는 연락처 공유 전송 보고(Contact Share Delivery Report)를 생성하여 발신측 네트워크(127&129)로 전송한다. 이에 대응하여 CAB XDMS(120)는 955단계에서 발신측 네트워크(127&129)로부터 응답 메시지(200 OK)를 수신한다.

이후, 960단계에서 CAB 서버(140)는 CAB 클라이언트B(150)의 주소록 동기화를 위해 AB App. Usage에 발생한 document change의 포함하는 서버 알림 메시지를 CAB 클라이언트B(150)로 보낸다.

추가적으로 수신측이 발신측의 구독 초대를 확인 후 이를 수락하여 구독하는 경우 이후의 연락처 정보 구독 과정은 일반적인 절차에 따라 진행되게 된다. 다만, 이러한 경우 발신자의 PCC App. Usage내 이미 설정된 접속 권한 즉, 상기 도 4의 420단계에서 ‘invite-include’라는 필터 ID를 통해 발신자의 연락처 정보 중 중 이름(name), 연락처(comm-addr), 경력(career-history)만 최종적으로 수신자(XUI: sip:[email protected])가 연락처 정보 구독 초대에 응해 발신자의 연락처 정보 구독을 시도하는 경우 구독하거나 읽을 수 있도록 설정한 것에 따라 연락처 정보 구독 결과를 통보받게 되고 사용자 선호도에 따라 연락처 정보를 갱신하게 될 것이다.

그리고 수신측 XML 문서 전송에 대한 사용자 선호도가 수락(accept)가 아닌 확인(confirm)인 경우 경우에는 AB App. Usage에 수신한 AB document를 추가하고 연락처 상태를 “temporary”로 하여 CAB 클라이언트B(150)의 주소와 동기화한 후 수신자가 직접 이에 대한 확인의사를 표시하고 “temporary”를 제거함으로써 연락처 공유가 완료된다.

또한 본 발명에서는 연락처 공유 요청을 CAB FH App. Usage를 통해 CAB 서버로 전달하여 개인 정보 구독 초대 방법을 구현하였는데, 시스템 구현에 따라 그렇지 않은 경우 즉, CAB Client와 CAB XDMS간 XDM 문서 전송 요청/응답을 위한 직접 interface가 있어 이를 통해 연락처 공유 요청이 XDM 문서 전송의 형태로 CAB XDMS로 전달되는 통합 주소록 시스템하에서는 상기 열거한 예제들이 일반적인 XDM 문서 관리 기능 구현의 허용 범위내에서 수정되어 이뤄질 수 있으나 전체적인 동작 및 방법은 본 발명의 범주내에서 동일하다고 볼 수 있다.

마지막으로 본 발명에서는 서로 다른 도메인 사용자간 연락처 정보 구독 초대 방법을 구현하였는데, 동일 도메인 사용자간 연락처 정보 구독 초대 방법에 있어서도 동일 도메인내 CAB 서버 및 CAB XMDS에서 일반적인 XDM 문서 관리 기능 구현의 허용 범위내에서 상기에서 보인 서로 다른 도메인 사용자간 연락처 정보 구독 초대 방법이 일부 수정되어 이뤄질 수 있으나 전체적인 동작 및 방법은 본 발명의 범주내에서 동일하다고 볼 수 있다.

Claims

통합 주소록 문서 관리 서버(converged address book XML Document Management Server, CAB XDMS)에서 연락처 정보의 구독을 초대하는 방법에 있어서,
제1 클라이언트로부터 제1 클라이언트의 연락처 뷰의 일부에 대해 구독하도록 제2 클라이언트를 초대하기 위한 연락처 공유 요청을 수신하는 과정과,
상기 연락처 공유 요청을 상기 제1 클라이언트와 연관된 CAB 서버에 통지하는 과정과,
상기 연락처 공유 요청의 통지에 응답하여, 상기 CAB 서버에 의해 업데이트되는 상기 제2 클라이언트에 대한 액세스 권한 문서(access permission document)를 저장하는 과정과,
상기 CAB 서버로부터 연락처 공유를 위한 포워드 요청을 수신하는 과정과,
상기 제2 클라이언트와 연관된 CAB XDMS에 연락처 공유를 위한 원격 요청을 전송하는 과정을 포함하고,
상기 포워드 요청은, 상기 연락처 뷰의 일부에 대한 구독을 허용하는 조건 및 상기 제2 클라이언트를 초대하는 초대 메시지를 포함하고,
상기 원격 요청은, 상기 연락처 뷰의 일부를 수신할 수 있는 주소 정보를 포함하는 것을 특징으로 하는 방법.
제1항에 있어서, 상기 액세스 권한 문서는,
상기 제1 클라이언트의 연락처 뷰를 필터링하기 위한 정보를 포함하는 것을 특징으로 하는 방법.
제1항에 있어서, 상기 제1 클라이언트의 전체 연락처 뷰 중 상기 구독을 허용하는 조건을 적용하여 필터링된 연락처 뷰를 생성하는 과정을 더 포함하는 것을 특징으로 하는 방법.
제1항에 있어서,
상기 연락처 뷰의 일부를 수신할 수 있는 주소 정보를 생성하는 과정을 더 포함하는 것을 특징으로 하는 방법.
제1항에 있어서, 상기 포워드 요청은,
HTTP POST를 이용하여 상기 CAB 서버에 의해 생성되어 전송되는 것을 특징으로 하는 방법.
제1항에 있어서,
상기 제2 클라이언트와 통신하는 네트워크로부터 상기 원격 요청에 대한 포워딩 결과에 대한 제1 응답 메시지를 수신하는 과정과,
상기 포워드 요청에 대한 제2 응답 메시지를 생성하여 상기 포워드 요청에 대한 결과를 저장하는 과정을 더 포함하는 것을 특징으로 하는 방법.
제6항에 있어서,
상기 제2 응답 메시지를 전송하는 과정과,
상기 제2 응답 메시지의 전송 이후에 상기 제2 클라이언트와 통신하는 네트워크로부터 상기 연락처 공유 요청에 대한 전송 보고를 수신하는 과정을 더 포함하는 것을 특징으로 하는 방법.
제7항에 있어서,
상기 연락처 공유 요청에 대한 전송 보고에 기반하여 상기 연락처 공유 요청의 전송 상태는 상기 CAB 서버에서 업데이트되는 것을 특징으로 하는 방법.
연락처 정보의 구독을 초대하는 통합 주소록 문서 관리 서버(converged address book XML Document Management Server, CAB XDMS)에 있어서,
제1 클라이언트로부터 상기 제1클라이언트의 연락처 뷰의 일부에 대해 구독하도록 제2 클라이언트를 초대하기 위한 연락처 공유 요청을 수신하고, 상기 연락처 공유 요청을 상기 제1 클라이언트와 연관된 CAB 서버로 통지하는 통합 주소록 기능 구동 어플리케이션 사용부와,
상기 연락처 공유 요청의 통지에 응답하여, 상기 CAB 서버에 의해 업데이트되는 상기 제2 클라이언트에 대한 액세스 권한 문서(access permission document)를 저장하고, 상기 CAB 서버로부터 연락처 공유를 위한 포워드 요청을 수신하고, 상기 제2 클라이언트와 연관된 CAB XDMS로 연락처 공유를 위한 원격 요청을 전송하는 통합 주소록 개인연락카드 어플리케이션 사용부를 포함하고,
상기 포워드 요청은, 상기 연락처 뷰의 일부에 대한 구독을 허용하는 조건 및 상기 제2 클라이언트를 초대하는 초대 메시지를 포함하고,
상기 원격 요청은, 상기 연락처 뷰의 일부를 수신할 수 있는 주소 정보를 포함하는 것을 특징으로 하는 통합 주소록 문서 관리 서버.
제9항에 있어서, 상기 액세스 권한 문서는,
상기 제1 클라이언트의 연락처 뷰를 필터링하기 위한 정보를 포함하는 것을 특징으로 하는 통합 주소록 문서 관리 서버.
제9항에 있어서, 상기 통합 주소록 개인연락카드 어플리케이션 사용부는,
상기 연락처 뷰의 일부를 수신할 수 있는 주소 정보를 생성하는 것을 특징으로 하는 통합 주소록 문서 관리 서버.
제9항에 있어서, 상기 포워드 요청은,
HTTP POST를 이용하여 상기 CAB 서버에 의해 생성되어 전송되는 것을 특징으로 하는 통합 주소록 문서 관리 서버.
제9항에 있어서, 상기 통합 주소록 개인연락카드 어플리케이션 사용부는,
상기 제2 클라이언트와 통신하는 네트워크로부터 상기 원격 요청에 대한 전송 결과에 대한 제1 응답 메시지를 수신하고, 상기 포워드 요청에 대한 제2 응답 메시지를 생성하여 상기 포워드 요청의 결과를 상기 CAB 서버의 연락처 공유 기능부에 저장하는 것을 특징으로 하는 통합 주소록 문서 관리 서버.
제13항에 있어서, 상기 통합 주소록 기능 구동 어플리케이션 사용부는,
상기 제2 응답 메시지를 상기 연락처 공유 기능부로 전송하고,
상기 통합 주소록 개인연락카드 어플리케이션 사용부는 상기 연락처 공유 요청의 전송 보고를 상기 제2 클라이언트와 통신하는 네트워크로부터 수신하는 것을 특징으로 하는 통합 주소록 문서 관리 서버.
제14항에 있어서,
상기 연락처 공유 요청에 대한 전송 보고에 기반하여 상기 연락처 공유 요청의 전송 상태는 상기 CAB 서버에서 업데이트되는 것을 특징으로 하는 통합 주소록 문서 관리 서버.