KR20150102891A

KR20150102891A - 통신 이력 제공 방법

Info

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

Abstract

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

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) 또한 향상시킬 수 있다.

도 1은 일반적인 SIP 기반의 CAB(Converged Address Book) 시스템 구조를 도시한 도면,
도 2는 다수 단말을 가진 수신자와 그룹 발신자간 통신이력(Communication History)을 저장하기 위한 신호 송수신을 나타낸 도면,
도 3a와 도3b는 본 발명에서 제안하는 SIP 기반의 프레즌스 정보를 포함하는 통신이력(Communication History) 공유하여 그룹 통화를 하기 위한 신호 송수신을 나타낸 도면,
도4는 본 발명의 다른 실시예에 따라 통신 이력을 관리하는 과정을 나타낸 도면,
도 5는 상기 도 3을 일반화한 흐름도.

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

본 발명은 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)로 갱신되는 통신 이력(communication 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) 되어 있는 그룹원들과 통화할 수 있을 뿐만 아니라, 통신 이력을 자기 본인의 다른 단말에 공유할 수 있는 장점이 있다.

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

100: CAB 클라이언트 120: CAB 서버
130: 콘택트 제어 서버 140:XDMS 서버

Claims

제1 단말이 통화를 진행하는 방법에 있어서,
통신 이력(communication history)을 수신하기 위한 등록 요청을 서버로 전송하는 과정과,
상기 제1 단말의 사용자의 통신 이력에 대한 구독 요청을 서버로 전송하는 과정과,
상기 제1 단말의 사용자와 관련된 모든 단말들의 통신 이력 정보를 서버로부터 수신하는 과정과,
상기 통신 이력 정보를 메모리에 저장하는 과정과,
상기 통신 이력 정보에 포함된 하나 이상의 제2 단말에 대한 프레즌스 정보의 요청을 상기 서버에 전송하는 과정과,
상기 서버로부터 상기 하나 이상의 제2 단말들에 대한 프레즌스 정보를 수신하는 과정과,
상기 프레즌스 정보에 기초하여 상기 하나 이상의 제2 단말들과 통화를 진행하는 과정을 포함하는 방법.
제1항에 있어서,
상기 제1 단말의 사용자와 관련된 모든 단말들의 통신 이력 정보는, 상기 제1 단말의 사용자와 관련된 모든 단말들에 대한 통신 이력을 포함하고,
상기 통신 이력은, 통화 타입, 통신 타입 및 메시징 서비스 타입 중 적어도 하나를 포함함을 특징으로 하는 방법.
제2항에 있어서,
상기 통화 타입은, 송신(outgoing call), 수신(incoming call), 부재중(absence) 및 수신 거부(rejected call) 중 적어도 하나를 포함하고,
통신 타입은, 음성 통화(voice call), 영상 통화(video call), 그룹 통화(group call) 및 메시징 서비스 중 적어도 하나를 포함하고,
상기 메시징 서비스는 SMS, MMS, SIMLPE IM, PoC, CPM 및 CAB 중 적어도 하나를 포함하고,
상기 통신 이력 정보는, 해당 단말의 주소, USIM 주소, 외장 메모리의 주소 중 적어도 하나를 더 포함함을 특징으로 하는 방법.
제1항에 있어서,
상기 통신 이력 정보에 포함된 하나 이상의 제2 단말에 대한 프레즌스 정보의 요청을 상기 서버에 전송하는 과정 이전에, 상기 하나 이상의 제2 단말들에 대한 필터링된 프레즌스 정보를 요청할 것인지 여부를 판단하는 과정을 더 포함하고,
상기 프레전스 정보에 대한 요청은, 상기 판단에 따른 결과를 포함함을 특징으로 하는 방법.
제1항에 있어서,
상기 사용자와 관련된 모든 단말들 중 하나 이상의 제3 단말들에 대한 프레즌스 정보를 상기 서버에 요청하는 과정을 더 포함함을 특징으로 하는 방법.
제1항에 있어서,
상기 사용자의 요청에 따라 상기 사용자와 관련된 모든 단말들의 통신 이력 정보 중 적어도 일부를 표시하는 과정을 더 포함함을 특징으로 하는 방법.
제1항에 있어서, 상기 프레즌스 정보에 기초하여 상기 하나 이상의 제2 단말들과 통화를 진행하는 과정은,
상기 사용자와 관련된 모든 단말들 중 상기 사용자에 의해 선택된 상기 하나 이상의 제2 단말들과 통신하는 과정을 포함함을 특징으로 하는 방법.
제1항에 있어서, 상기 구독 요청은,
업데이트된 XML 문서를 수신하기 위한 이벤트 패키지와, 상기 통신 이력으로서 업데이트된 XML 문서를 정의하기 위한 콘텐츠 타입(Content-Type)을 포함함을 특징으로 하는 방법.
제1항에 있어서, 상기 하나 이상의 제2 단말에 대한 프레즌스 정보를 요청하는 과정은,
상기 서버로 프레즌스 구독 요청 메시지를 전송하는 과정을 포함함을 특징으로 하는 방법.
제3항에 있어서,
상기 제1 단말이 하나 이상의 제3 단말들과 통신을 수행하여 새로운 통신 이력이 발생하면, 상기 서버로 상기 새로운 통신 이력을 전달하는 과정과,
상기 서버로부터, 상기 새로운 통신 이력을 포함하는 통신 이력 정보를 수신하는 과정과,
상기 새로운 통신 이력을 포함하는 통신 이력 정보를 저장하는 과정을 더 포함함을 특징으로 하는 방법.
서버에서 하나 이상의 단말들에 대한 통신 이력(Communication History)을 관리하는 방법에 있어서,
제1 단말로부터, 상기 제1 단말이 통신 이력을 수신하기 위한 등록 요청을 수신하는 과정과,
상기 제1 단말의 사용자와 관련된 모든 단말들에 대한 통신 이력 정보의 적어도 일부를 수신하는 수신 단말로서, 상기 제1 단말을 등록하는 과정과,
상기 제1 단말로부터 상기 사용자와 관련된 모든 단말들에 대한 통신 이력에 대한 구독 요청을 수신하는 과정과,
상기 제1 단말로 상기 사용자와 관련된 모든 단말들에 대한 통신 이력 정보를 전송하는 과정과,
상기 제1 단말과 통화할 하나 이상의 제2 단말들에 대한 프레즌스 정보를 상기 제1 단말로부터 요청받는 과정과,
상기 하나 이상의 제2 단말들에 대한 상기 프레즌스 정보를 상기 제1 단말로 전송하는 과정을 포함하고,
상기 제1 단말은, 상기 하나 이상의 제2 단말들에 대한 프레즌스 정보에 기초하여 상기 하나 이상의 제2 단말들과 통화를 진행함을 특징으로 하는 방법.
제11항에 있어서,
상기 제1 단말의 사용자와 관련된 모든 단말들의 통신 이력 정보는, 상기 제1 단말의 사용자와 관련된 모든 단말들에 대한 통신 이력을 포함하고,
상기 통신 이력은, 통화 타입, 통신 타입 및 메시징 서비스 타입 중 적어도 하나를 포함함을 특징으로 하는 방법.
제12항에 있어서,
상기 통화 타입은, 송신(outgoing call), 수신(incoming call), 부재중(absence) 및 수신 거부(rejected call) 중 적어도 하나를 포함하고,
통신 타입은, 음성 통화(voice call), 영상 통화(video call), 그룹 통화(group call) 및 메시징 서비스 중 적어도 하나를 포함하고,
상기 메시징 서비스는 SMS, MMS, SIMLPE IM, PoC, CPM 및 CAB 중 적어도 하나를 포함하고,
상기 통신 이력 정보는, 해당 단말의 주소, USIM 주소, 외장 메모리의 주소 중 적어도 하나를 더 포함함을 특징으로 하는 방법.
제11항에 있어서,
상기 프레즌스 정보에 대한 요청을 분석함으로써, 필터링된 프레즌스 정보를 요청하였는지 여부를 판단하는 과정을 더 포함함을 특징으로 하는 방법.
제14항에 있어서,
상기 제1 단말로부터 새롭게 발생한 통신 이력을 수신하는 과정과,
상기 새롭게 발생한 통신 이력이 포함된 통신 이력 정보를 상기 제1 단말로 전송하는 과정을 더 포함함을 특징으로 하는 방법.
제1 단말에 있어서,
통신 이력을 수신하기 위한 등록 요청을 서버로 전송하는 상기 제1 단말을 포함하고,
상기 제1 단말은, 상기 제1 단말의 사용자의 통신 이력에 대한 구독 요청을 서버로 전송하고, 상기 제1 단말의 사용자와 관련된 모든 단말들의 통신 이력 정보를 상기 서버로부터 수신하여 저장하고, 상기 통신 이력 정보에 포함된 하나 이상의 제2 단말들에 대한 프레즌스 정보를 요청하고, 상기 하나 이상의 제2 단말들에 대한 프레즌스 정보를 수신하고, 상기 프레즌스 정보에 기초하여 상기 하나 이상의 제2 단말들과 통화를 진행함을 특징으로 하는 제1 단말.
제16항에 있어서,
상기 제1 단말의 사용자와 관련된 모든 단말들의 통신 이력 정보는, 상기 제1 단말의 사용자와 관련된 모든 단말들에 대한 통신 이력을 포함하고,
상기 통신 이력은, 통화 타입, 통신 타입 및 메시징 서비스 타입 중 적어도 하나를 포함함을 특징으로 하는 방법.
제17항에 있어서,
상기 통화 타입은, 송신(outgoing call), 수신(incoming call), 부재중(absence) 및 수신 거부(rejected call) 중 적어도 하나를 포함하고,
통신 타입은, 음성 통화(voice call), 영상 통화(video call), 그룹 통화(group call) 및 메시징 서비스 중 적어도 하나를 포함하고,
상기 메시징 서비스는 SMS, MMS, SIMLPE IM, PoC, CPM 및 CAB 중 적어도 하나를 포함하고,
상기 통신 이력 정보는, 해당 단말의 주소, USIM 주소, 외장 메모리의 주소 중 적어도 하나를 더 포함함을 특징으로 하는 방법.
제16항에 있어서,
상기 제1 단말은, 상기 하나 이상의 제2 단말들에 대한 프레즌스 정보를 요청하기 이전에, 상기 하나 이상의 제2 단말들에 대한 필터링된 프레즌스 정보를 요청할 것인지 여부를 판단하고,
상기 프레전스 정보에 대한 요청은, 상기 하나 이상의 제2 단말들에 대한 필터링된 프레즌스 정보를 요청할 것인지 여부를 판단한 결과를 포함함을 특징으로 하는 제1 단말.
제18항에 있어서, 상기 제1 단말은,
제3 단말과 통신을 수행하여 새로운 통신 이력이 발생하면, 상기 서버로 상기 새로운 통신 이력을 전달하고, 상기 서버로부터, 상기 새로운 통신 이력을 포함하는 제2 통신 이력 정보를 수신하여 저장함을 특징으로 하는 제1 단말
제16항에 있어서, 상기 제1 단말은,
프레즌스 상태에서, 상기 통신 이력 정보에 포함된 모든 단말들 중 하나 이상의 제3 단말들에 대한 프레즌스 정보를 요청함을 특징으로 하는 제1 단말.
제16항에 있어서, 상기 제1 단말은,
상기 사용자의 요청에 따라 상기 통신 이력 정보를 표시함을 특징으로 하는 제1 단말.
제16항에 있어서, 상기 제1 단말은,
상기 통신 이력 정보에 포함된 모든 단말들 중 상기 사용자에 의해 선택된 상기 하나 이상의 제2 단말들과 통화를 진행함을 특징으로 하는 제1 단말.