KR20100061254A

KR20100061254A - 통신 이력 제공 방법

Info

Publication number: KR20100061254A
Application number: KR1020080123631A
Authority: KR
Inventors: 오규봉
Original assignee: 삼성전자주식회사
Priority date: 2008-11-28
Filing date: 2008-12-05
Publication date: 2010-06-07
Also published as: US8671156B2; JP5436571B2; US20100138516A1; CN102227927A; EP2351394A2; JP2012510231A; CN102227927B; EP2351394B1; KR20150102891A; WO2010062135A3; KR101635906B1; WO2010062135A2; EP2351394A4

Abstract

본 발명은 SIP/IP 코어망에서 단말의 통신이력(Communication History)을 제공하는 것에 관한 것으로, 복수의 단말을 사용하는 사용자가 단말의 통신이력 구독을 서버로 요청하면, 서버가 복수의 단말과 관련된 통신이력이 새롭게 등록될 때 마다 복수의 단말 중 어느 하나의 단말로 상기 복수의 단말과 관련된 통신이력 정보를 전송하고, 상기 통신 이력 정보를 수신한 단말은 필요에 따라 상기 통신 이력 정보에 포함된 통화 상대 단말의 프레즌스 정보를 요청, 수신할 수 있다.

CAB(Converged Address Book), 통신이력(Communication History), Presence 정보,

Description

통신 이력 제공 방법{METHOD FOR PROVIDING THE COMMUNICATION HISTORY}

본 발명은 SIP/IP(Session Initiation Protocol/ Internet Protocol)코어망의 통합 주소록 서비스에 관한 것으로, 특히, 통합 주소록 서비스를 이용해 이동 단말의 통신 이력을 관리하는 방법 및 장치에 관한 것이다.

SIP/IP 코어망에서 통합 주소록 서비스(Converged Address Book, 이하 CAB)는, 사용자가 가진 다양한 단말에서 이용 가능한 주소 정보를 저장하고 이 정보를 언제, 어디서, 어떤 장치로도 접근 가능하게 하며, 주소 정보를 동기화하는 단일 네트워크 기반의 주소록 서비스이다.

도 1을 통해 OMA CAB 그룹에 제안된 CAB 의 개념적인 구조를 살펴보면, CAB 클라이언트(100), CAB 서버(120), 콘택트 제어 서버(130), XDMS(XML Document Management Server)(140) 등으로 구성된다.

CAB 클라이언트(100)는 단말상에서 CAB 서버(120)와 통신을 하며 CAB 사용자 인증, 개인 콘택트 정보(Personal Contact Card이하, 'PCC'이라함.)와 네트워크 저장소에 저장된 통합 주소록의 동기화 그리고 CAB 사용자의 요구사항, 예를 들면 주소 구독(subscription), 주소 찾기, 주소 공유, 기존 주소록과의 상호작용 또는 사 용자 선호도의 관리 등을CAB 서버(120)에게 전송하는 역할을 담당한다. CAB 서버(130)는 CAB 구조에서 주요한 네트워크 구성요소로써, CAB 클라이언트(100)로부터 CAB 사용자의 요청사항을 받아 처리하는 역할을 담당한다. CAB 서버(120)의 주요 기능으로는 CAB 클라이언트 상호인증, CAB 주소의 저장, 주소 정보 동기화, 주소 구독 기능으로부터의 주소 정보 갱신을 받아 주소록에 반영하는 역할을 한다. 콘택트 제어 서버(130)는 주소 구독/공유/변환 및 사용자의 선호도/정책 등을 반영하는 네트워크 구성요소로써, 주요 기능으로는 CAB 사용자 선호도 및 정책 XDMS로부터 CAB 사용자 선호도 XML 문서 회수, CAB 사용자의 구독 요청을 받는 주소 구독 기능, 주소 구독을 통해 받은 데이터의 개인 선호도 적용 및 주소록으로의 반영, 구독 상태 정보 유지, PCC나 통합주소록을 공유하는 주소 공유 기능 그리고 기존 주소록 시스템과 연계 또는 외부 인에이블러에 인터페이스를 노출하는 인터워킹 기능 등이 있다. 사용자의 데이터를 관리하는 XDMS(140)에는 통합 주소록을 저장하는 CAB XDMS, 사용자의 선호도 및 정책을 저장하는 CAB 사용자 선호도/정책 XDMS, 기존 사용자와 CAB 사용자를 구분하는 콘택트 상태(Contact Status) XDMS, 타인과 공유하는 주소록을 저장하는 콘택트 공유 XDMS (Contact Share XDMS) 그리고 PCC 정보를 저장하는 PCC XDMS, 등이 있다. 이외에 다양한 XDMS 기능에 접속하기 위한 XDMS, 외부 도메인의 엔티티들과의 메시지 라우팅을 위한 SIP/IP 코어 네트워크 등이 있다.

다수의 단말을 보유중인 수신자와 발신자간 통신에 관한 예제를 도2를 참조하여 살펴보고자 한다. 도2는 CAB 서비스에서 여러 대의 단말을 가진 수신자와 발신자가 통신하는 것을 나타낸 예시이다. 도2에서 다수의 단말을 보유하고 있는 수신측 사용자 A는 자신의 첫 번째 단말 #1(200)로 들어온 발신측 사용자 B(240)의 통신 요청을 받아들여 오디오 세션을 개설한다(201단계, 203단계, 205단계). 여기서 사용자 B(240)는 그룹으로 구성될 수 있다. 발신자와 수신자간의 소기의 목적(통화, 문자, 메신저 등)을 달성한 후 사용자 A는 사용자 B(240)와의 세션을 종료한다(207단계, 209단계). 세션이 종료됨에 따라 사용자 A의 첫 번째 단말 #1(200)과 사용자 B(240)의 단말에는 금번 통신에 대한 통신이력(Communication history)이 각각 남게 된다(215-a단계, 215-b단계). 그런데 현재의 CAB 서비스에서는 사용자 A의 두 번째 단말 #2(220)에서 사용자 B(240)에게로 세션 개설을 요청하는 경우 사용자 A의 첫 번째 단말 #1(200)에 남아 있는 통신이력을 사용자 A의 두 번째 단말 #2(220)에서 알 수 없는 관계로 사용자 A가 통신 이력을 활용한 사용자 B(240)와의 통신이 원활하지 않게 된다(217단계). 더욱이 사용자 B(240)의 연락처가 CAB 주소록에 저장되어 있지 않다면 사용자 A는 첫 번째 단말 #1(200)의 통신이력을 확인하지 않는 이상 사용자 B(240)와의 통신이 불가능하게 된다.

이와 같이 다수의 단말을 가진 수신자가 특정 단말을 사용하여 발신자와의 통신 후 다른 단말로 발신자와 통신을 시도하는 경우 수신자는 기존 발신자와의 통 신이력을 최초 통신한 특정 단말을 통해 확인하지 않는 이상 그에 대한 정보를 취득할 수 없으며 현재의 CAB 서비스 또한 이에 대한 정보를 제공하고 있지 않아 다수의 단말을 가진 사용자들의 원활한 통신에 커다란 장애가 있다. 따라서 CAB 서비스에서 다수의 단말에 존재하는 통신이력을 통합적으로 관리하는 방안이 절실하다.

본 발명에서는, 상기 기술된 문제점을 해결하기 위하여, 다수의 단말의 가진 사용자가 통합된 통신이력을 통해 원하는 수신자와의 원활한 통신을 할 수 있는 방법을 제공한다.

그리고 통합 주소록 시스템에서의 통합 통신이력 제공을 통해 다수 단말을 가진 사용자에게 개개의 단말내 통신이력에 대한 산발적 이용에 대한 불편을 제거함으로써 다수 단말 사용자의 의사선택에 따라 손쉽고 빠르게 CAB 서비스가 가능한 데이터 송수신 방법 및 장치를 제공한다.

한편, 본 발명은 통신 시스템에서 단말이 통신이력(Communication History)을 제공 받는 방법에 있어서, 통신이력구독을 서버로 요청하는 단계와, 상기 단말의 사용자에 대응하여 등록된 모든 단말의 통신이력정보를 상기 서버로부터 수신하여 저장하는 단계를 포함한다.

그리고 상기 통신이력정보에 포함된 적어도 하나의 통신 상대 단말에 대한 프레즌스 정보를 요청하는 단계와, 상기 적어도 하나의 통신 상대 단말에 대한 프레즌스 정보를 수신하는 단계를 더 포함한다.

그리고 상기 단말이 임의의 단말과 통신을 수행하여 새로운 통신 이력이 발 생하면 상기 서버로 상기 새로운 통신 이력을 전달하는 단계와, 상기 서버로부터 상기 새로운 통신 이력이 포함된 상기 통신 이력 정보를 수신하여 저장하는 단계를 포함한다.

본 발명에서 제안된 시스템 및 방법을 통해, 발신자의 등록된 단말들이 통신이력(Communication history) 구독요청을 하면 단말마다 통신이력(Communication history)이 생성될 때마다 통보를 받게 되며 사용자는 기존 사용 단말이 아닌 다른 단말에서 프레즌스 정보를 포함하는 통신이력(Communication history)을 제공함으로써, 활동중인(active) 그룹원들과 연속성 있는 통신을 할 수 있으며 이에 따라 사용자 경험(experience) 또한 향상시킬 수 있다.

이하 첨부된 도면을 참조하여 본 발명의 따른 바람직한 실시 예를 상세히 설명한다. 또한, 본 발명을 설명함에 있어서, 관련된 공지기능 혹은 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단된 경우 그 상세한 설명은 생략한다.

본 발명은 SIP/IP 코어망에서 단일 사용자가 가진 다수의 단말에서 이용 가능하도록 주소 정보 및 통신 이력(Communication History)를 저장하고 이 정보를 언제, 어디서, 어떤 장치로도 접근 가능하며 이 정보를 동기화하는 단일 네트웍 기반 주소록 서비스인 통합 주소록 (Converged Address Book, 이하 CAB) 서비스에 관한 것으로, 다수의 단말을 사용하는 사용자가 각각의 단말에 존재하는 주소 정보 및 통신이력(Communication history)를 통합하여 관리하고 이를 프레즌스(Presence) 정보를 제공함으로써 사용자에게 통신이력(Communication history)를 이용하여 그룹 콜 시 통화 연속성의 편의를 제공하고자 하는 방법에 관한 것이다.

그리고 본 발명에서 CAB 인에이블러의 기능으로 포함된 통신 이력(Communication History)은 단말에서 발생한 모든 통신에 관한 기록을 말하는 것으로써 기존 송수신 통화목록을 포함하여 통화타입별(송신,수신,부재중,수신거부 등), 통신 종류 예를 들어, 음성 통화(Voice Call), 영상 통화(Video Call), 그룹 통화(Group Call), 각종 메시징 서비스(SMS/MMS/SIMPLE IM/PoC/CPM/CAB 등)등을 포함하며, 단말 주소, USIM 주소, 외장 메모리 주소와 같이 주소 저장위치에 따른 통신 기록 등을 포함한다.

본 발명에서는, 통신 당사자간에 프레즌스 정보를 포함하는 통신이력(Communication history) 제공을 통한 단말간 이력(history)의 연속성을 위해 다음을 제안한다. 더 구체적으로 통신 당사자간에 등록된 단말들이 통합 통신 이력 구독요청을 하면 단말마다 통신이력이 생성될 때마다 통보를 받게 되며, 사용자는 기존 사용 단말이 아닌 다른 단말에서 프레즌스 정보를 포함하는 통신이력을 통보 받음으로써, 활동중인(active) 그룹원들과 연속성 있는 통신을 할 수 있으며 이에 따라 사용자 경험(experience) 또한 향상시킬 수 있다.

현재의 통합 메시징 서비스(CPM)와 PoC 서비스에서는 각각 메시지/미디어 저장 장치(Message & Media Storage)와 PoC Box라는 저장소에 세션 이력(session history) 정보와 미디어를 저장할 수 있다. 하지만 각각은 사용자의 선호도와 사업 자의 정책에 의존하는 관계로 기록이 저장되지 않을 수 있는 문제점이 있다. 또한 세션 이력에 관한 내용이 SIP헤더 정보에 국한되는 관계로 현재의 단말에서 제공하고 있는 통신 이력 정보에 비해 다양성 및 유용성 측면에서 상대적으로 가치가 부족하다 할 수 있다.

이런 세션 이력의 정보의 한계를 극복하고 아울러 단말마다 따로 존재하는 통신이력 정보의 일목요연한 관리가 필요하다. 이를 위해 본 발명은 등록된 단말의 통신이력 구독을 요청하도록 하고 그에 대한 변화되는 정보를 받게 함으로써 단말간 통신이력을 관리할 수 있게 하고, 통신이력에 프레즌스 정보를 포함시켜 전달함으로써, 다수단말을 가지는 사용자에게 통신이력을 통해 연속성 있는 통신이 가능토록 하고자 한다. 이에 대해서는 아래에서 보다 자세하게 설명하도록 하겠다.

본 발명에 따라 CAB 클라이언트(100)는 통신 이력의 구독/관리/동기화하는 역할을 수행할 수 있다. 그리고 CAB 서버(120)는 본 발명과 관련하여 통신 이력의 의 저장/동기화/갱신하는 역할을 할 것이다. 또한 XDMS(140)는 사용자의 통신 이력을 저장하는 통신 이력 XDMS(Communication History XDMS)를 추가적으로 포함할 수 있다.

도3a와 도3b에서 두 개 이상의 단말을 가진 사용자 A는 첫 번째 단말 #1(200)로 사용자 B(240)가 보낸 그룹콜(Group Call) 초청을 통해 그룹원(사용자 B, 사용자C, 사용자D)과 그룹콜을 진행한 다음 사용자 A의 두 번째 단말 #2(220) 단말로 업데이트된 통신이력으로 프레즌스 정보를 통해 활동중인(active)한 그룹원들과 그룹콜을 시도한다.

도3a와 도3b는 본 발명에서 제안하는 프레즌스 정보를 포함하는 통신이력 제공 방법을 나타낸 것이다. 다수의 단말을 사용하는 발신자는 추후 그룹콜을 원활히 할 수 있도록 하기 위하여 발신자가 사용중인 두 단말 중 사용자 A두 번째 #2 단말(220)로 갱신 되는 통신이력(comm. history)의 구독을 요청하게 된다.(3210단계, 3211단계, 3213단계, 3215단계, 3217단계,) 이를 수신한 CAB XDMS(280)는 지금까지 사용자 A와 관련하여 저장하고 있었던 기존의 통신이력을 사용자 A의 두 번째 #2 단말(220)로 통보한다.(3219단계, 3221단계, 3223단계, 3225단계, 3225단계)이후에 구독요청기한이 만료될 때까지 변경된 통신 이력이 없다면 통보 또한 없을 것이다.

이후, 사용자 A 와 사용자 B 사이에 그룹콜이 있고 이 후 그룹콜이 종료될 경우 통신이력이 생성될 것이고(3230-a단계, 3230-b단계 ), 사용자 A의 첫 번째 단말(200)과 CAB서버(260)간 데이터 동기화(Data Synchronization)(3231 단계)를 통해 생성된 통신이력이 CAB XDMS(280)에 저장(3233단계, 3233단계, 3235단계, 3237단계, 3239단계)될 것이다. 따라서 CAB XDMS(280)는 변경된 통신이력에 대한 구독을 신청 권한(Authorization)을 확인한 다음 사용자 A 두 번째 단말#2(220)에게 이를 통보해 준다.(3241단계, 3243단계, 3245단계, 3247단계) 사용자 A는 통보 받은 첫 번째 단말 #1(200)에서의 그룹콜에 대한 통신이력 정보를 토대로 사용자 A두 번째 단말 #2(220)에서 기존 그룹콜을 재개설 요청을 하려 한다(3250단계). 이때 그룹원들의 프레즌스가 제공된다면 그룹콜 연결에 대한 연결/개최가능성을 확보할 수 있게 됨으로써 사용자의 경험 향상에 상당한 도움이 될 것이다. 발신자(사용자 A)는 통신이력으로부터 리소스 리스트를 획득한 후 활동중인 리소스에 대한 프레즌스 구독요청을 하는 필터 (filter)를 가진 프레즌스 구독 요청 메시지를 프레즌스 서버(350)로 보내게 된다.(3251단계, 3253단계, 3255단계, 3257단계) 리소스 리스트란 통신이력에 포함된 통신 상대에 대한 리스트이다.

프레즌스(Presence) 서버(350)는 발신자의 권한을 확인한 후 리소스 리스트에 대한 중 활동중인 리소스(사용자 B/사용자 C)에 대해서만 프레즌스 정보를 통보하게 된다.(3259단계, 3261단계, 3263단계, 3265단계) 따라서 기존 그룹콜에 참여한 그룹원 중 활동중인 그룹원(사용자 A/ 사용자 B/사용자 C)의 프레즌스 정보를 획득한 발신자는 사용자 A의 두 번째 단말 #2(220)로 사용자 B 및 사용자 C와 그룹콜을 진행하게 되며(3267단계, 3269단계), 그룹콜 종료 후에는 이에 대한 통신이력 정보가 이전과 동일하게 CAB XDMS(280)에 저장되게 된다.(3271단계, 3273단계, 3275단계, 3277단계)

본 발명에 따라 단말과 서버간 통신 이력 데이터 동기화의 방법은 도3에서 나타낸 동기화 과정 이외에 도4와 같은 동기화 과정으로 구성될 수도 있다. 도4는 비 SIP 기반 구독 바인딩(non SIP based subscription binding)을 통한 XCAP patch operations(RFC 5261)를 이용한 통신 이력 데이터 동기화 과정을 나타낸 것이다.

도4에서는 XCAP PUT을 이용해 CAB XDMS(280)에 비 SIP 기반 구독 바인딩을 설정한 후 기존 설정된 사용자 선호도를 확인하여 해당 단말로 업데이트된 통신 이력을 통보하고 있다.

먼저 사용자 A의 두번째 단말 #2(220)에 대해 사용자는 등록된 단말의 통신 이력의 업데이트되는 정보를 받기 위해 사용자 선호도에 구독요청을 설정한 다.(3301단계) 이후 사용자 A가 자신의 첫번째 단말 #1(200)로 그룹콜을 진행하면(3303단계), XCAP PUT 을 이용해 발생한 통신 이력을 CAB XDMS(280)로 저장한다.(3305-a단계, 3305-b단계, 3307단계, 3309단계) 이때 비 SIP 기반 구독 바인딩을 통해 다른 단말로의 동기화가 필요성과 통신 이력이 변경되었음을 같이 전송함으로써 통신 이력 데이터 동기화를 위한 비 SIP 통보(non SIP notification)를 꾀할 수 있다. XCAP PUT을 받은 CAB XDMS(280)는 통신 이력의 상태가 변경되었음을 구독 기능부(370)에 알려주며(3311단계,3313단계), 이를 통보 받은 구독 기능부(370)는 사용자 선호도를 확인하여 통신 이력 동기화를 위해 통보가 필요한 사용자의 등록된 단말을 확인한다.(3315 단계) 구독 기능부(370)는 기존에 사용자 A의 두번째 단말 #2(220)이 통신 이력 구독기능을 설정해 놓은 것을 확인하고 XCAP patch operations을 활용하여 갱신된 통신 이력만 사용자의 두 번째 단말#2(220)로 전송한다.(3317단계, 3319단계,3321단계, 3323단계) 이로써 사용자 A의 두번째 단말#2(220)은 기존 그룹콜의 재개설 요청이 가능해지며 도3에서와 마찬가지로 기존 참가자들의 프레즌스 정보를 바탕으로 다시 그룹콜을 진행할 수 있을 것이다.(3325단계)

도3, 도4의 신호흐름도에서 볼 수 있는 바와 같이 발신측 입장에서 단말에 대한 통합된 통신 이력 정보를 받게 됨으로써 한 단말에서의 수신된 전화에 대한 통신 이력을 다른 단말에서 취득하지 못하는 문제점을 해소할 수 있으며 또한 그에 대한 프레즌스 정보를 포함한 통신 이력 정보를 받게 됨으로써 통신의 연속성을 크게 향상시킬 수 있다.

상기의 도3의 신호 흐름도에 대해 표1 내지 표5는 각각의 단계에 대한 메시지 포맷을 보이고 있다.

표 1은 사용자 A의 두 번째 단말#2(220)가 갱신되는 통신이력을 구독요청하기 위해 CAB XDMS(280)로 보내는 메시지의 일례를 표시하였다(3211단계). 갱신되는 XML문서를 받기 위해 이벤트 패키지로 "xcap-diff"를 사용하였으며 콘텐츠 타입(content-type)으로는 본 발명에서 제안하는 통신이력을 정의하는 새로운 포맷을 요청한다. 아래 XML문서는 통신이력 저장부에 저장된 사용자 A의 통신이력을 구독하기 위한 URI를 보이고 있다.

SUBSCRIBEsip:alice.cafe@example.com;auid=org.openmobilealliance.comm_histories SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 70
Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>, <sip:orig@scscf1.home1.net;lr>
From: <sip:alice2.cafe@example.com>;tag=31415
To: <sip:alice.cafe@example.com>
Event: xcap-diff
Call-ID: b89rjhnedlrfjflslj40a222
CSeq: 85 SUBSCRIBE
P-Preferred-Identity: "Alice2 Cafe" <sip:Alice2.cafe@example.com>
Privacy: none
Expires: 600000
Accept: application/xcap-diff+xml
Contact: <sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp>
Content-Type: application/communication-histories+xml
Content-Length: ..

<?xml version="1.0" encoding="UTF-8"?>
<communication-history xmlns="urn:ietf:params:xml:ns:communication-histories">
<list>
<entry uri="org.openmobilealliance.comm_histories/user
s/sip:alice. /communication_histories"/>
</list>
</communication-history >

표 2에서는 사용자 B와의 그룹콜을 진행한 사용자 A의 첫 번째 단말 #1(200)에 의해 새로 생성된 통신이력을 CAB XDMS(280)에 저장하는 메시지를 일례로 보이고 있다.(3233단계) 생성된 통신이력이 속하는 리스트는 수신그룹통화이며 통신 이력 의 참조 주소는 "SIP:112233@comm_historyserver.example.com"이다. 송신자는 사용자 B(240)이며 그 아래로 접속타입(contact type_"home", "office", "abroad"등), 접속번호(contact number), 일정(date time), 통화시간(call time), 그룹콜 참가자 정보(participants)가 나와 있다. 표2의 예시는 기본적인 통신이력의 형태를 나타낸 것이고 단말에 따라 보다 풍부한 통신이력 정보가 제공될 수도 있다.

PUT/org.openmobilealliance.communication-histories/users/sip:alice.cafe@example.com/communication_histories.xml HTTP/1.1
Host: xcap.example.com
…
Content-Type: application/communication-histories+xml
Content-Length: (…)

<?xml version="1.0" encoding="UTF-8"?>
<communication-histories xmlns="urn:ietf:params:xml:ns:communication-histories">
<communication_histories>
<history list="incoming_group_call" history_reference="sip:112233@comm_ historyserver.example.com">
<entry name="Bob">
<contact type="home">031-111-2222</contact>
<datetime>2008-01-10T19:20:49+09:00</datetime>
<calltime>00:04:30</calltime>
<participants>
<entry name="Jane" uri="sip:jane@example.com"/>
<entry name="Tom" uri="sip:tom@example.com"/>
</entry>
</history>
</communication_histories>

표 3은 새로 저장된 통신이력을 사용자 A의 두 번째 단말 #2(220)의 구독요청에 따라 통보하는 메시지를 보이고 있다.(3241단계) CAB XDMS(280)는 단말로 "sip:112233@comm_historyserver.example.com"라는 새로운 엔트리를 보낸다.

NOTIFY sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp SIP/2.0
Via: SIP/2.0/UDP cabxdms1.home1.net;branch=z9hG4bK332b23.1
Max-Forwards: 70
Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>
From: <sip:alice.cafe@example.com>;tag=31415
To: <sip:alice2.cafe@example.com>;tag=151170
Call-ID: b89rjhnedlrfjflslj40a222
CSeq: 112 NOTIFY
Subscription-State: active;expires=600000
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Contact: <sip:cabxdms1.home1.net>
Content-Length: (...)

<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff" xmlns:och=" urn:ietf:params:xml:ns:communication-histories"xcap-root="http://xcap.example.com">
<document previous-etag="7ahggs"sel="org.openmobilealliance.comm_histories/user
s/sip:alice.cafe@example.com/communication_histories"
new-etag="ffds66a">
<change-log>
<add sel="och:group/och:communication_histories/l:list">
<och:entry och:uri="sip:112233@comm_historyserver.example.com">
</add>
</change-log>
</document>
</xcap-diff>

표 4는 사용자 A가 두 번째 단말 #2(220)로 기존의 그룹콜을 재개하기 위해 통신이력으로부터의 리소스 리스트를필터로 활용하여 프레즌스를 구독 요청하는 메시지의 일례를 보인 것이다.(3251단계) 사용자 A의 두 번째 단말 #2(220)은 각각 사용자 A의 첫 번째 단말 #1(200), 사용자 B/사용자 C/사용자 D(240)에게 프레즌스 정보를 요청한다.

SUBSCRIBE sip:alice.cafe@example.com;auid=org.openmobilealliance.presence SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 70
Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>, <sip:orig@scscf1.home1.net;lr>
From: <sip:alice2.cafe@example.com>;tag=31415
To: <sip:alice.cafe@example.com>
Call-ID: 32432udfidfjmk342
Cseq: 1 SUBSCRIBE
P-Preferred-Identity: "Alice2 Cafe" <sip:Alice2.cafe@example.com>
Expires: 3600
Accept: multipart/related
Accept: application/rlmi+xml
Event: Presence
Contact: sip: alice2.cafe@example.com
Content-Type: application/simple-filter+xml
Content-Length: (...)
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
<filter id="123" uri="sip:alice1.cafe@example.com">
<what>
<include type="xpath">
//pidf:tuple/pidf:status[pidf:basic="open"]/pidf:basic
</include>
</what>
</filter>
<filter id="124" uri="sip:bob@example.com">
<what>
<include type="xpath">
//pidf:tuple/pidf:status[pidf:basic="open"]/pidf:basic
</include>
</what>
</filter>
<filter id="125" uri="sip:jane@example.com">
<what>
<include type="xpath">
//pidf:tuple/pidf:status[pidf:basic="open"]/pidf:basic
</include>
</what>
</filter>
<filter id="126" uri=" sip:tom@example.com">
<what>
<include type="xpath">
//pidf:tuple/pidf:status[pidf:basic="open"]/pidf:basic
</include>
</what>
</filter>
</filter-set>

표 5는 표 4의 요청에 따른 결과 정보인 리소스 리스트의상태에 대한 필터가 적용된 프레즌스 정보를 통보하는 메시지이다.(3259단계) 메시지에서 보는 바와 같이 사용자 B와 사용자 C가 "online"상태임을 알 수 있다. 이 정보를 바탕으로 사용자 A는 두 번째 단말 #2(220)로 해당 수신자들에게 그룹콜을 시도할 수 있을 것이다.

NOTIFY sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp SIP/2.0
Via: SIP/2.0/UDP cabxdms1.home1.net;branch=z9hG4bK332b23.1
Max-Forwards: 70
Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>
From: <sip:alice.cafe@example.com>;tag=31415
To: <sip:alice2.cafe@example.com>;tag=151170
Call-ID: b89rjhnedlrfjflslj40a222
CSeq: 112 NOTIFY
Subscription-State: active;expires=600000
Event: Presence
Contact: sip: alice.cafe@example.com
Content-Type: application/pidf+xml
Content-Length: (...)
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:alice@example.com">
<tuple id="123">
<status>
<basic>closed</basic>
</status>
</tuple>
<tuple id="124">
<status>
<basic>open</basic>
</status>
</tuple>
<tuple id="125">
<status>
<basic>closed</basic>
</status>
</tuple>
<tuple id="126">
<status>
<basic>open</basic>
</status>
</tuple>
</presence>

그리고 도4의 XCAP patch operations를 통해 업데이트된 통신 이력을 통보하는 예에 대해 표6과 표7에서 주요 단계에 대한 메시지 포맷을 나타내었다.(3307단계)

표 6의 메시지에서는 생성된 통신 이력이 동기화가 필요하며(sync=active) CAB XDMS(280)에 저장됨으로써 다른 등록된 단말로의 동기화가 필요하다는(status=update) 의미를 CAB XDMS(280)에 전송한다.

PUT /org.openmobilealliance.communication-histories/users/sip:alice.cafe@example.com/communication_histories.xml HTTP/1.1
Host: xcap.example.com

Content-Type: application/communication-histories+xml
Content-Length: ()

<?xml version="1.0" encoding="UTF-8"?>
<communication-histories xmlns="urn:ietf:params:xml:ns:communication-histories">
<communication_histories status="update" sync="active">
<history id=a111 list="incoming_group_call" history_reference=sip:112233@comm_historyserver.example.com>
<entry name="Bob">
<contact type="home">031-111-2222</contact>
<datetime>2008-01-10T19:20:49+09:00</datetime>
<calltime>00:04:30</calltime>
<participants>
<entry name=Jane uri=sip:jane@example.com/>
<entry name=Tom uri=sip:tom@example.com/>
</entry>
</history>
</communication_histories>

표 7은 사용자 A의 사용자 선호도 XDMS로부터 사용자 A의 두번째 단말#2(220)이 통신 이력 구독 요청된 것을 확인한 구독 기능부(350)가 XCAP patch operations를 통해 업데이트된 통신 이력을 사용자 A의 두번째 단말#2(220)로 전송하는 메시지 예를 나타낸 것이다.(3319단계)

PUT /org.openmobilealliance.communication-histories/users/sip:alice2.cafe@example.com/communication_histories.xml HTTP/1.1
Host: xcap.example.com

Content-Type: application/communication-histories+xml
Content-Length: ()

<?xml version="1.0" encoding="UTF-8"?>
<p:communication-histories xmlns="urn:ietf:params:xml:ns:communication-histories">
<p:add sel="communication-histories/history[@id='a111'] type=@list>incoming_group_call</p:add>
<p:add sel="communication-histories/history[@id='a111'] type=@history_reference> sip:112233@comm_historyserver.example.com</p:add>
<p:add sel="communication-histories/history[@id='a111']>
<entry name="Bob">
<contact type="home">031-111-2222</contact>
<datetime>2008-01-10T19:20:49+09:00</datetime>
<calltime>00:04:30</calltime>
<participants>
<entry name=Jane uri=sip:jane@example.com/>
<entry name=Tom uri=sip:tom@example.com/>
</entry>
</p:add>
</p:communication_histories>

이상에서 보인 바와 같이 다수의 단말을 사용하는 사용자가 각각의 단말에 존재하는 통화 이력을 통합하여 관리하고 이에 프레즌스 정보를 제공하는 동작을 일반화 시킨 과정을 정리하면 도5와 같다.

사용자 A는 두 번째 단말 #2(220)로 통신이력에 대한 구독요청하고 이에 대한 통보를 받는다.(403단계) 사용자 A는 첫 번째 단말 #1(200)로 사용자 B의 그룹콜 수신하여 사용자 C와 사용자 D와 함께 그룹콜 통신을 수행한다(405단계). 그룹콜이 종료됨에 따라 사용자 A의 첫 번째 단말 #1(200)은 자신의 통신이력 XDMS에 생성된 통신이력을 OMA SyncML과 XCAP PUT을 이용하여 저장한다(407단계). 기존 구독요청(subscribe)에 따라 사용자 A의 두 번째 단말 #2(220)는 업데이트된 통신이력 정보를 CAB XDMS(280)로부터 통보 받는다(409단계). 사용자 A는 필요에 따라 두 번째 단말 #2(220)로 통신이력을 이용하여 그룹콜을 재시도한다(411단계). 이 경우 기존 그룹콜을 진행한 그룹원에 대한 프레즌스 정보의 요청여부를 결정한다(413단계). 프레즌스 정보를 요청하지 않는다면 사용자 A는 통신이력 정보를 이용하여 단순 그룹콜을 요청한다(423단계). 프레즌스 정보를 요청하는 경우 사용자 A는 필터링된 프레즌스 정보를 요청할 것인지 결정한다(415단계). 그룹원에 대한 필터링된 프레즌스 정보를 요청하는 경우 사용자 A는 그룹원의 프레즌스에 대한 필터링된 정보를 요청한다(SUBSCRIBE (Event: presence, with filter)(417단계). 그룹원에 대한 필터링된 프레즌스 정보를 요청하지 않는 경우 사용자 A는 그룹원 전체에 대한 프레즌스 정보 요청한다(SUBSCRIBE)(419단계). 사용자 A는 그룹원의 프레즌스에 대한 요청한 정보를 통보 받는다(421단계). 사용자 A는 통보된 그룹원의 프레즌스 정보를 바탕으로 활동중인(active) 그룹원들과 그룹콜 시도한다(INVITE)(423단계).

이렇듯 통신이력을 이용하여 그룹콜을 재 시도할 시 다수 단말을 사용하는 사용자는 활성화(Active)되어 있는 그룹원들과 통화 할 수 있을 뿐만 아니라, 통신이력을 자기 본인의 다른 단말에 공유할 수 있는 장점이 있다.

상술한 본 발명의 설명에서는 구체적인 실시예에 관해 설명하였으나, 여러 가지 변형이 본 발명의 범위에서 벗어나지 않고 실시할 수 있다. 따라서 본 발명의 범위는 설명된 실시예에 의하여 정할 것이 아니고 특허청구범위와 특허청구범위의 균등한 것에 의해 정해 져야 한다.

도 1은 일반적인 SIP 기반의 CAB(Converged Address Book) 시스템 구조를 도시한 도면,

도 2는 다수 단말을 가진 수신자와 그룹 발신자간 통신이력(Communication History)을 저장하기 위한 신호 송수신을 나타낸 도면,

도 3a와 도3b는 본 발명에서 제안하는 SIP 기반의 프레즌스 정보를 포함하는 통신이력(Communication History) 공유하여 그룹콜을 하기 위한 신호 송수신을 나타낸 도면,

도4는 본 발명의 다른 실시예에 따라 통신 이력을 관리하는 과정을 나타낸 도면,

도 5는 상기 도 3을 일반화한 흐름도.

Claims

통신 시스템에서 단말이 통신이력(Communication History)을 제공 받는 방법에 있어서,

통신이력구독을 서버로 요청하는 단계와,

상기 단말의 사용자에 대응하여 등록된 모든 단말의 통신이력정보를 상기 서버로부터 수신하여 저장하는 단계를 포함함을 특징으로 하는 통신 이력 제공 방법.
제1항에 있어서, 상기 통신이력정보에 포함된 적어도 하나의 통신 상대 단말에 대한 프레즌스 정보를 요청하는 단계와,

상기 적어도 하나의 통신 상대 단말에 대한 프레즌스 정보를 수신하는 단계를 더 포함함을 특징으로 하는 통신 이력 제공 방법.
제2항에 있어서, 상기 단말이 임의의 단말과 통신을 수행하여 새로운 통신 이력이 발생하면 상기 서버로 상기 새로운 통신 이력을 전달하는 단계와,

상기 서버로부터 상기 새로운 통신 이력이 포함된 상기 통신 이력 정보를 수신하여 저장하는 단계를 포함함을 특징으로 하는 통신 이력 제공 방법.
통신 시스템에서 단말로 통신이력(Communication History)을 제공하는 방법에 있어서,

단말로부터 통신이력을 요청을 수신하는 단계와,

상기 단말의 사용자에 대응하여 등록된 모든 단말의 통신이력 정보를 상기 모든 단말 중 하나의 단말로 전송하는 단계를 포함함을 특징으로 하는 통신 이력 제공 방법.
제4항에 있어서,

상기 하나의 단말로부터 상기 통신이력정보에 포함된 적어도 하나의 통신 상대 단말에 대한 프레즌스 정보 요청을 수신하는 단계와,

상기 적어도 하나의 통신 상대 단말에 대한 프레즌스 정보를 상기 하나의 단말로 전달하는 단계를 더 포함함을 특징으로 하는 통신 이력 제공 방법.
제5항에 있어서,

상기 단말로부터 새롭게 발생한 통신 이력을 수신하는 단계와,

새롭게 발생한 통신 이력이 포함된 상기 통신 이력 정보를 상기 하나의 단말로 전송하는 단계를 포함함을 특징으로 하는 통신 이력 제공 방법.