KR101378217B1

KR101378217B1 - 다중 프리젠티티용 ｒｌｓ 통보 기준을 제공하기 위한시스템 및 방법

Info

Publication number: KR101378217B1
Application number: KR1020070099860A
Authority: KR
Inventors: 오재권; 파통 바자바라 자야완트
Original assignee: 삼성전자주식회사
Priority date: 2006-10-03
Filing date: 2007-10-04
Publication date: 2014-03-27
Anticipated expiration: 2027-10-04
Also published as: WO2008041830A1; WO2008041830A8; KR20080031141A

Abstract

본 발명은 사용자로 하여금 RLS가 언제 어떻게 NOTIFY 요청을 발생시켜야 하는지에 대한 선택을 지정할 수 있도록 하는 시스템과 방법을 제안한다. 그 결과, 불필요하고 때로는 짜증나게 하는 통보를 피함으로써 프레전스 통보를 최적화한다. 이는 사용자가 초기 SIP SUBSCRIBE에서 RLS 통보 규칙기준을 지정하게 함으로써 가능하다. 이에 따라 본 발명은 와처가 SIP SUBSCRIBE에서 필터를 지정하도록 지원한다. 또한, 본 발명은 그러한 RLS 통보 기준규칙이 SIP SUBSCRIBE에 존재할 때 예상되는 RLS의 동작을 지시한다.

RLS, 통보, 규칙, 프레전스, 프리젠티티

Description

다중 프리젠티티용 ＲＬＳ 통보 기준을 제공하기 위한 시스템 및 방법{SYSTEM AND METHOD FOR PROVIDING RLS NOTIFICATION RULE FOR MULTIPLE PRESENTITIES}

본 발명은 일반적으로 이동 통신에 관한 것이다. 본 발명은 인스턴트 메시징, 푸시 투 토크 오버 셀룰러(Push to talk over Cellular), 컨버지드 IP 메시징(Converged IP Messaging) 및 프레전스(presence) 서비스를 이용하는 임의의 기타 향후 애플리케이션과 같이 SIP(Session Initiation Protocol)를 통한 다양한 OMA 개발 애플리케이션에 관한 것이다. 본 발명은 프레전스 정보에 관한 통보에 가입해서 이를 수신하는 애플리케이션에 관한 것이다. 더 구체적으로 본 발명은 다중 프리젠티티(presentity)를 위한 RLS(Resouce List Server) 통보 기준에 관한 것이다.

프레전스 시스템 아키텍처는 임의 사용자의 프레전스 정보를 다른 사용자들이 공유할 수 있도록 돕는다. 프레전스 정보는 기본적으로 사용자와 관계된 정보로서, 예를 들면 사용자의 현재 위치, 사용자의 연락처, 그리고 사용자의 인스턴트 메시징(IM: Instant Message) 이용 가능 여부 등과 같이 특정 애플리케이션과 관련 된 프레전스 정보가 있다. 현재의 기술 수준에서 어떤 사용자가 다른 사용자의 프레전스 정보를 수신하기 위해서는 그 사용자의 프레전스 정보에 가입해야 한다. 그러면, 요청받은 사용자는 요청한 사용자에게 자신의 프레전스 정보를 수신할 권한을 준다. 프레전스 서버 객체는 요청한 사용자의 프레전스 가입을 유지하고, 요청받은 사용자의 프레전스 정보를 저장한다. 요청받은 사용자의 프레전스 정보가 변경되면, 그 즉시 프레전스 서버는 가입이 유효한 기간 동안에 가입한/요청한 사용자에게 통보를 보낸다. 이때, 프레전스 정보가 관심 대상이 되는 다른 사용자/요청받은 사용자를 프리젠티티(Presentity)라고 부르며, 프레전스 정보에 가입해서 이를 수신하는 사용자/요청한 사용자는 와처(Watcher)라고 한다. 와처는 기본적으로 다른 사용자의 프레전스 정보를 열람할 권한이 있는 사용자이다. 가입 및 통보를 위해서 SIP SUBSCRIBE 및 SIP NOTIFY 방법을 이용한다.

와처가 가입할 수 있는 프레전스 속성은 많지만, 와처가 프리젠티티의 모든 프레전스 정보에 관심이 있지 않을 수도 있다. 이에 따라 필터를 지정함으로써 와처는 필요한 프레전스 정보만을 수신할 수 있다. 이러한 프레전스 정보 필터 기준들은 IEFT 드래프트 IETF RFC 4660 "이벤트 통보 필터링의 기능적 서술"에 정의되어 있다. 필터들은 프리젠티티의 프레전스 서버에서 실행된다.

또한, 프레전스 서비스에 등록한 사용자는 개인 또는 그룹의 프리젠티티의 프레전스 정보에 가입할 수 있다. 그룹의 프리젠티티의 프레전스 정보에 가입하는 경우에는 IETF RFC 4662 "리소스 목록을 위한 세션 초기화 프로토콜(SIP) 이벤트 통보 확장"에 규정되어 있는 바와 같이 SIP SUBSCRIBE가 프리젠티티의 집합을 열거 하는 리소스 목록의 URI를 규정하거나, IETF 드래프트 draft-ietf-sip-uri-list-subscribe "세션 초기화 프로토콜(SIP)에서의 요청 포함 리소스 목록 가입"에 규정되어 있는 바와 같은 URI 목록으로 이루어진다.

통보는 개별적인 와처에게 전달되거나, 리소스 목록 서버(RLS)를 통해 그룹의 프리젠티티로부터 취합된다. IEFT 드래트프 draft-ietf-sipping-uri-services "세션 초기화 프로토콜(SIP) 균일 리소스 식별자(URI)-목록 서비스를 위한 프레임워크 및 보안 고려 사항"에 규정되어 있는 바와 같이 URI-목록 서비스가 그러한 SIP SUBSCRIBE 및 SIP NOTIFY를 취급하게 된다. 필터가 존재하는 경우 이는 프리젠티티의 프레전스 서버에서 실행되어 RLS로의 통보를 발생시키기 위해 프레전스 서버의 동작을 규정한다.

uri-목록 서비스의 현재 기술 수준에서는 와처가 RLS로부터 그룹의 프리젠티티에 대한 복합적인 통보를 수신한다. RLS로부터의 이러한 복합적인 통보에는 그룹의 프리젠티티 각각으로부터의 통보들의 집합이 포함된다. 한 사용자로부터 수신된 통보와 다른 사용자로부터 수신된 통보 사이에는 아무런 연관이 없다.

이하, 도 1 및 도 2를 참조하여 상기의 경우에 대한 동작 순서를 설명하기로 한다.

예를 들어, 아담이 빌과 조 및 테드를 회의에 초대하려고 하고, 모두 회의에 참석해야 한다고 생각하는 경우를 고려해 보기로 한다. 아담은 빌과 조 및 테드의 프레전스 정보가 모두 "OPEN"일 때에만 통보를 보내는 방법을 포함한 가입 요청을 보낸다.

현재 빌과 테드의 프레전스 정보는 "CLOSED"이고, 조의 프레전스 정보는 "OPEN"이다. 도 1을 참조하면, 프레젠티티인 빌(50)은 홈 네트워크에 속하는 와처인 아담(10)과 동일한 운영자의 서비스에 가입해 있다. 반면, 프레젠티티인 조(60)와 테드(70)는 원격 네트워크에 속하는 다른 운영자의 서비스에 가입해 있다.

도 1 및 도 2를 참조하면, 와처인 아담의 클라이언트(10)는 100단계에서 단일 목록 프레전스 가입 요청(draft-ietf-sip-uri-list-subscribe에 따름)을 필터(IETF RFC 4660에 따름)를 포함하여 리소스목록서버(Resource List Server: 이하 RLS)(20)로 보낸다. 여기서, 가입 요청을 위해 SUBSCRIBE가 사용된다. 상기 목록은 빌과 조 및 테드에 대한 가입 요청을 포함하며, 필터 기준은 빌과 조 및 테드의 프레전스 정보가 "OPEN"일 때 통보를 보낼 것을 규정한다.

따라서, RLS(20)는 105단계 및 110단계에서 필터를 포함한 가입 요청을 프레전스 서버-A(PS-A: 이하 Presence-Server-A)(30) 및 프레전스 서버-B(PS-B: 이하 Presence-Server-B)(40)에 전달한다. 그러면 Presence-Server-A(30)는 115단계에서 빌(50)로부터 PUBLISH를 제공받아 빌(50)의 프레전스 정보를 감시한다. Presence-Server-A(30)는 120단계에서 필요시 프레전스 정보를 필터링한 후 125단계에서 빌(50)이 자신의 프레전스를 "OPEN"으로 바꿀 때에만 통보를 보낸다. 여기서, 통보를 위해 NOTIFY가 사용된다. 마찬가지로, Presence-Server-B(40)는 130단계에서 조(60)로부터 PUBLISH를 제공받은 후 조(60)의 프레전스 정보를 감시한다. Presence-Server-B(40)는 135단계에서 필요시 프레전스 정보를 필터링한 후 만일 조(60)의 프레전스 정보가 "OPEN"일 경우 140단계에서 RSL(20)로 통보를 즉시 송신 한다. 이에 따라 RLS(20)는 145단계에서 통보를 조합하여 150단계에서 통보를 아담(10)으로 전송함으로써 (통보 속도 등을 고려한 후) 아담(10)은 조(60)가 "OPEN"임을 알게 된다. 테드(70)의 경우에는 Presence-Server-B(40)가 155단계에서 테드(70)로부터 PUBLISH를 제공받아 테드(70)의 프레전스 정보를 감시하고, 160단계에서 필요시 프레전스 정보를 필터링한 후 테드(70)가 자신의 프레전스를 "OPEN"으로 바꿀 때에만 165단계에서 통보를 보낸다. 이에 따라 RLS(20)는 170단계에서 아담(10)으로 통보를 보낸다.

이와 같은 방식으로 아담은 빌과 조 및 테드의 "OPEN" 프레전스 정보를 다중 통보를 통해 수신할 것이다. 상기 이용 경우를 충족시키기 위해서 아담은 도착한 통보들이 빌과 조 및 테드 모두가 "OPEN"이어야 한다는 요건을 만족시키는지를 직접 감시해야 한다. 이에 따라 아담(10)은 175단계에서 다중 통보를 감시하게 된다. 그리고나서 빌과 조 및 테드 모두의 프레전스 정보가 "OPEN"이면 아담은 이들을 회의에 초대한다.

그러나, 한 사용자가 그룹의 프리젠티티의 프레전스 정보에 가입한 경우, 그 프리젠티티 집합으로부터 취합된 정보를 수신하기보다는 다른 사용자의 프레전스에 대한 통보만을 받고 싶어할 수 있다. 다시 말하면, 사용자는 RLS가 언제 어떻게 통보를 발생시킬 것인지를 선택해서 지정하기 원할 수 있다. 현재의 기술은 그러한 이용 경우를 감안하지 않는다.

또한, 그룹의 프리젠티티의 프레전스 정보에 가입한 경우 복수의 사용자들로부터 프레전스 정보가 변경될 때마다 통보를 받게 될 경우 많을 부하를 초래할 수도 있다. 게다가 매번 통보를 받을 경우에는 와처 입장에서는 불필요하고 때로는 짜증나게 하는 통보를 피함으로써 프레전스 통보를 최적화할 필요가 있다.

하지만 와처가 그룹의 프리젠티티로부터 프레전스 정보를 수신하고 나면, 클라이언트는 사용자에게 프레전스 정보를 제시하기 전에 사용자가 정한 통보 기준(클라이언트에 저장되어 있음)에 대해 평가해야 하는 그러한 이용 경우들을 현재의 기술로도 클라이언트 구현에 의해 구현할 수 있을 것이다. 그러나, 저자들은 그러한 클라이언트 구현을 알지 못한다.

따라서, 본 발명은 사용자로 하여금 RLS가 언제 어떻게 NOTIFY 요청을 발생시켜야 하는지에 대한 선택을 지정할 수 있도록 하는 시스템과 방법을 제공한다.

상술한 바를 달성하기 위한 본 발명은 다중 프리젠티티용 RLS(Resource List Server) 통보 기준을 제공하기 위한 방법에 있어서, RLS가 와처로부터 그룹의 프리젠티티들의 프레전스 정보를 요청하기 위한 가입 요청을 수신하는 과정과, 상기 RLS가 상기 그룹의 프리젠티티들로 상기 가입 요청을 전달한 후 상기 그룹의 프리젠티티들로부터 해당 프레전스 정보를 통보받는 과정과, 상기 RLS가 저장해놓은 RLS 통보 기준이 충족되는지를 판단하는 과정과, 상기 RLS가 상기 RLS 통보 기준이 충족될 경우에 상기 통보된 프레전스 정보들을 통합하여 상기 와처로 전송하는 과정을 포함함을 특징으로 한다.

또한 본 발명은 다중 프리젠티티용 RLS(Resource List Server) 통보 기준을 제공하기 위한 시스템에 있어서, 그룹의 프리젠티티들의 프레전스 정보를 요청하기 위한 가입 요청을 전송하는 와처와, 상기 그룹의 프리젠티티들로 상기 가입 요청을 전달한 후 상기 그룹의 프리젠티티들로부터 해당 프레전스 정보를 통보받으면, 저장해놓은 RLS 통보 기준이 충족되는지를 판단하고, RLS가 상기 RLS 통보 기준이 충족될 경우에 상기 통보된 프레전스 정보들을 통합하여 상기 와처로 전송하는 RLS를 포함함을 특징으로 한다.

본 발명은 사용자로 하여금 RLS가 언제 어떻게 통보를 발생시켜야 하는지를 지정할 수 있게 하여 통보를 최적화하는 이점이 있다. 또한, 본 발명은 좋은 사용자 경험을 제공할 수 있을 뿐만 아니라 서비스 비용을 감소시키는 이점을 제공한다.

본 발명은 사용자로 하여금 RLS가 언제 어떻게 NOTIFY 요청을 발생시켜야 하는지에 대한 선택을 지정할 수 있도록 하는 시스템과 방법을 제안한다. 그 결과, 불필요하고 때로는 짜증나게 하는 통보를 피함으로써 프레전스 통보를 최적화한다. 이는 사용자가 초기 SIP SUBSCRIBE에서 RLS 통보 기준을 지정하게 함으로써 가능하다. 이에 따라 본 발명은 와처가 SIP SUBSCRIBE에서 필터를 지정하도록 지원한다. 또한, 본 발명은 그러한 RLS 통보 기준이 SIP SUBSCRIBE에 존재할 때 예상되는 RLS의 동작을 지시한다.

RLS 통보 기준:

사용자가 초기 SIP SUBSCRIBE에서 RLS 통보 기준을 규정하도록 허용하는데, 이 기준은 "draft-ieft-sip-uri-list-subscribe"에 규정되어 있는 바와 같은 포맷으로 URI 목록을 포함하거나, RFC 4662에 규정되어 있는 바와 같은 URI 목록의 URI를 포함할 수 있다. RLS 통보 기준의 포맷(이하 rls-notification-rule이라고 칭함)은 컨텐츠 타입에 의해 정의할 수 있으며, 예컨대 "application/rls-notification-rule"일 수 있다. 기준은 "동작 타입"에 따라 다르다. 동작 타입은 “ALL”, “ATLEAST”, “ATMOST”, “EQUALS” 및 기타로 구분될 수 있다. 상기 동작 타입들의 예시적인 포맷을 설명하면 다음과 같다.

먼저, 동작 타입이 "ALL"인 경우의 예시적인 포맷은 하기 표 1과 같다.

상기 표 1의 예는 동작 타입에 따른 기준에서 정해진 목록의 사용자 모두로부터 통보가 수신되었을 때에만 와처가 통보에 관심이 있다는 것을 의미한다.

또한, 동작 타입이 "ATLEAST"인 경우의 예시적인 포맷은 하기 표 2와 같다.

상기 표 2의 예가 의미하는 것은 기준에서 정한 목록의 사용자로부터 "x"개 이상의 통보가 수신되었을 때에만 와처가 통보에 관심이 있다는 것이다.

또한, 동작 타입이 "ATMOST" 인 경우의 예시적인 포맷은 하기 표 3과 같다.

상기 표 3의 예가 의미하는 것은 기준에서 정한 목록의 사용자로부터 "x"개 이하의 통보가 수신되었을 때에만 와처가 통보에 관심이 있다는 것이다.

또한, 동작 타입이 "EQUALS" 인 경우의 예시적인 포맷은 하기 표 4와 같다.

상기 표 4의 예가 의미하는 것은 기준에서 정한 목록의 사용자로부터 x개의 통보가 수신되었을 때에만 와처가 통보에 관심이 있다는 것이다.

상기 표 1 내지 표 4의 예에서 <list> 요소는 전술한 모든 통보 기준에서 선택적이며, 이 요소가 존재하지 않는 경우에는, 리소스 목록에 언급된 모든 프리젠티티에 동작이 적용된다.

본 발명은 RLS 통보 기준을 전술한 동작 타입에 국한시키지 않으며, RLS 통보 기준은 RLS 통보를 제어하는 임의의 사용자 정의를 포함할 수 있다.

RLS 가 통보 기준을 저장:

URI-목록이 rls-notification-rule을 포함하는 SIP SUBSCRIBE 요청을 수신하면 URI 목록 서비스는 RFC 4662에 따라 가입을 생성하고, 생성된 다이얼로그 내 리소스의 변화를 수신한다. rls-notification-rule은 상기 다이얼로그와 연관되어 있으며, UIR 목록 서비스에 의해 저장된다.

RLS 가 기준에 의거하여 통보를 평가:

다중 리소스로부터 프레전스 통보를 수신하면 URI 목록 서비스는 rls-notification-rule에 의거하여 통보를 평가하며, 성공적인 평가의 경우에만 프레전스 통보를 와처에게 전달한다. 그렇지 않은 경우에는 통보를 와처에게 보내지 않는다.

이하, 도 3을 참조하여 본 발명에서 고려한 이용 경우와 관련하여 본 발명에 따른 동작 순서를 설명하기로 한다. 도 3에서는 빌과 테드의 프레전스 정보는 "CLOSED"이고, 조의 프레전스 정보는 "OPEN"이라고 가정한다. 또한, 빌은 아담과 동일한 서비스 운영자에 가입해 있으며, 조와 테드는 다른 서비스 운영자에 가입해 있음을 전제로 한다.

도 3을 참조하면, 아담(10)은 300단계에서 단일 목록 프레전스 가입 요청(draft-ietf-sip-uri-list-subscribe에 따름)을 필터(IETF RFC 4660에 따름)를 포함하여 RLS(20)로 보낸다.상기 목록은 빌(50)과 조 및 테드(60 & 70)에 대한 가입 요청을 포함한다.

필터 기준은 빌(50)과 조 및 테드(60 & 70)의 프레전스 정보가 "OPEN"일 때 통보를 보낼 것을 규정한다. 아담(10)은 또한 RLS(20)가 빌(50)과 조 및 테드(60 & 70) 모두로부터 프레전스 정보를 수신한 경우에만 아담(10)에게 통보를 보낼 것을 지시하는 rls-notification-rule을 규정한다.

RLS(20)는 305단계에서 rls-notification-rule이 있는지를 판단한 후 이를 저장하고, 310단계 및 315단계에서 필터를 포함한 가입 요청을 해당 서비스 운영자들 즉, Presence-Server-A(30) 및 Presence-Server-B(40)에 전달한다. 이때 상기 rls-notification-rule은 RLS(20)에 대해서만 유효하므로 Presence-Server-A(30) 및 Presence-Server-B(40)에 보내는 가입 요청에는 제외시킨다.

Presence-Server-A(30)는 320단계에서 빌(50)로부터 PUBLISH를 제공받아 빌(50)의 프레전스 정보를 감시하고, 325단계에서 필요시 프레전스 정보를 필터링한 후 빌이 자신의 프레전스를 "OPEN"으로 바꿀 때에만 330단계에서 통보를 보낸다. 이 통보를 위해 NOTIFY가 사용된다.

마찬가지로, Presence-Server-B(40)는 조와 테드(60 & 70)의 프레전스 정보를 감시한다. 이에 따라 Presence-Server-B(40)는 335단계에서 조(60)로부터 PUBLISH를 제공받은 후 340단계에서 필요시 프레전스 정보를 필터링한다. 조(60)의 프레전스 정보가 "OPEN"이므로 345단계에서 Presence-Server-B(40)로부터 조(60)의 프레전스 정보를 위한 통보가 RSL(20)로 즉시 송신된다. 그러면 RLS(20)는 350단계에서 RLS 통보 기준이 충족되는지를 검사한다. 그러나, 테드(70)의 프레전스 정보는 아직 "OPEN"이 아니므로 RLS 통보 기준이 충족되지 않아 통보가 이루어지지 않는다.

RLS(20)가 빌(50)과 조(60)로부터 통보를 수신했지만 테드(70)로부터는 아직 프레전스 정보를 수신하지 않았기 때문에 저장해놓은 rls-notification-rule이 충족되지 않은 상태이다. 따라서, RLS(20)는 테드(70)로부터 프레전스 정보를 수신할 때까지 아담(10)으로 통보를 전달하는 것을 유보한다.

테드(70)의 경우에는 Presence-Server-B(40)가 355단계에서 테드(70)로부터 PUBLISH를 제공받아 테드(70)의 프레전스 정보를 감시한다. 이에 따라 Presence-Server-B(40)가 360단계에서 필요시 프레전스 정보를 필터링한 후 테드(70)가 자신의 프레전스를 "OPEN"으로 바꾸면 365단계에서 통보를 RLS(20)로 보낸다.

이렇게 함으로써 RLS(20)가 테드(70)의 프레전스 정보를 수신하게 된다. 이에 따라 RLS(20)는 370단계에서 rls-notification-rule이 충족되는지를 판단한다. RLS(20)가 빌(50)과 조 및 테드(60 & 70) 모두로부터 프레전스 정보를 수신했으므로 그 rls-notification-rule이 충족되게 되므로, RLS(20)는 375단계에서 통합적인 통보를 아담(10)에게 보낸다.

이에 따라 아담(10)이 빌(50)과 조 및 테드(60 & 70) 의 "OPEN" 프레전스 정보에 대한 단일 통보를 RLS(20)로부터 수신한다. 빌(50)과 조 및 테드(60 & 70) 모두의 프레전스 정보가 "OPEN"이므로 아담(10)은 이들을 회의에 초대한다.

이를 달성하기 위해서 본 발명은 현재 기술에 다음과 같은 변화를 줄 것을 제안한다.

먼저, SIP SUBSCRIBE의 경우에는 SIP 중의 목록에 열거된 리소스에 대한 가입을 포함하는 SIP SUBSCRIBE 바디 에 사용자가 rls-notification-rule을 규정할 수 있게 하는데, 이는 RLS 또는 URI 목록 서비스로 송신된다. 또한, RLS 서버 또는 URI 목록 서비스의 경우에는 rls-notification-rule을 저장하는 추가 역할을 실행하고, 또한 그룹의 프리젠티티로부터 도착하는 프레전스 정보를 감시하여 rls-notification-rule을 평가하는 역할을 한다.

단계 1: SIP SUBSCRIBE 중의 변화

조건적인 기준을 포함시켰을 때 SIP SUBSCRIBE 요청이 어떻게 표현되는지에 대한 예는 하기 표 5와 같다.

SUBSCRIBE sip:rls@example.com SIP/2.0
Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL
Max-Forwards: 70
To: RLS <sip:rls@example.com>
From: <sip:adam@example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.example.com
CSeq: 1 SUBSCRIBE
Contact: <sip:terminal.example.com>
Event: presence
Expires: 7200
Require: recipient-list-subscribe
Supported: eventlist
Accept: application/cpim-pidf+xml
Accept: application/rlmi+xml
Accept: multipart/related
Accept: multipart/signed
Accept: multipart/encrypted
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: xxx

--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list>
<entry uri="sip:bill@example.com" />
<entry uri="sip:joe@example.org" />
<entry uri="sip:ted@example.org" />
</list>
</resource-lists>
--boundary1--

Content-Type: application/simple-filter+xml

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
</ns-bindings>
<filter id="123">
<trigger>
<changed from="CLOSED" to="OPEN">
/pidf:presence/pidf:tuple/pidf:status/pidf:basic
</changed>
</trigger>
</filter>
</filter-set>
--boundary1

Content-Type: application/ rls -notification-rule+xml

<?xml version="1.0" encoding=" UTF -8"?>
<rule-set xmlns ="urn:ietf: params :xml:ns: rls -notification-rule">
<rule id="123">
<trigger>
<operation type="AND">
<list>
<entry uri="sip:bill@example.com" />
<entry uri="sip:joe@example.org" />
<entry uri="sip:ted@example.org" />
</list>
</operation>
</trigger>
</rule>
</rule-set>
--boundary1
--

단계 2: RLS 서버 또는 URI 목록 서비스의 역할 변화

rls-notification-rule이 포함된 URI-목록을 가지는 SIP SUBSCRIBE 요청을 수신하면, URI 목록 서비스는 RFC 4662에 따라 가입을 생성하고, 생성된 다이얼로그 내 리소스의 변화를 수신한다. RLS 통보 기준은 상기 다이얼로그와 연관되어 있으며, UIR 목록 서비스에 의해 저장된다. 다중 리소스로부터 프레전스 통보를 수신하면, URI 목록 서비스는 rls-notification-rule에 의거하여 RLS 통보를 평가하며, 성공적인 평가의 경우에만 프레전스 통보를 와처에게 전달한다.

이하의 설명에 있어서, 본 발명을 응용하는 방법 중 하나를 예시 목적으로 설명할 것인데, 다른 방법들로도 본 발명을 적용할 수 있다.

먼저, 본 발명에 따른 RLS 통보 기준은 다음과 같다.

와처는 프레전스 목록에 가입할 때 통보의 촉발을 제어하기 위한 일부 조건을 정할 수 있다. RLS 통보 기준을 이용하면 와처는 RLS로부터 그룹의 프리젠티티의 프레전스 정보를 수신하고자하는 시점을 지정할 수 있다. 와처가 프레전스 목록에 가입하는 도중 일부 기준을 설정하기를 원할 때마다, 이하에서 상세히 설명하는 바와 같이 IETF RFC 3265 "세선 초기화 프로토콜(SIP)-특정 이벤트 통보"에 따라 SIP SUBSCRIBE 요청을 보낼 수 있다.

와처가 이벤트 통보 필터링 기준 IETF RFC 4660 "이벤트 통보 필터링의 기능적 서술" 및 RLS 통보 기준을 보내기를 원한다면 컨텐츠-타입 헤더에 "multipart/related" 값을 포함시킴으로써 "application/simple-filter+xml" 및 "application/vnd.oma/rls-notification-rules+xml" 컨텐츠 타입을 취합할 수 있다. RLS 통보 기준을 지정하기 위한 XML 포맷은 하기 표 6과 같은 구조를 가진다. 즉, 하기 표 6에서는 XML 스키마를 정의하고 있다.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="urn:oma:xml:prs:pidf:rls-notification-rule "
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:oma:xml:prs:pidf:rls-notification-rule"
elementFormDefault="qualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:annotation>
<xs:documentation xml:lang="en">Schema Definition for RLS Notification Condition.
</xs:documentation>
</xs:annotation>
<xs:element name="rule-set" type="RuleSetType"/>
<xs:complexType name="RuleSetType">
<xs:sequence>
<xs:element name="ns-bindings" type="NSBindings" minOccurs="0"/>
<xs:element name="rule" type="RuleType" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="NSBindings">
<xs:sequence>
<xs:element name="ns-binding" type="NSBinding" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="NSBinding">
<xs:attribute name="prefix" type="xs:string" use="required"/>
<xs:attribute name="urn" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="RuleType">
<xs:sequence>
<xs:element name="trigger" type="triggerType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="triggerType">
<xs:sequence>
<xs:element name="operation" type="operationType" minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="operationType">

<xs:attribute name="type" type="xs:string" use="required"/>
<xs:complexType>
<xs:schema>

또한, 본 발명에 따른 RLS 통보 기준은 하기에서 설명하는 구조 및 시맨틱스 에 따른다.

루트 요소 <rule-set>는, 확장성을 목적으로 임의의 기타 속성을 포함할 수 있으며, 네임스페이스 바인딩을 담고 있는 <ns-bindings>를 포함할 수 있으며, RLS 통보 전달을 위한 조건을 담고 있는 <rule-set> 요소를 하나 이상 포함한다.

또한, <ns-bindings> 요소는, 하나 이상의 <ns-binding> 요소를 포함하며, 이들 각각은 "prefix" 속성과 "namespace" 속성에 각각 프리픽스와 네임스페이스 사이의 바인딩을 담고 있다. 이 속성은 [RFC4826]에 기술된 바와 같이 리소스-목록의 포맷을 이용하여 조건을 적용해야 하는 URI의 목록을 표현하기 위해 사용된다.

또한, <rule> 요소는, 조건의 고유 ID를 담고 있는 "id" 속성을 포함하며, RLS 통보를 촉발하는 동작 타입을 담고 있는 <trigger> 요소를 포함하지 않거나 그 이상 포함하며, 확장성을 목적으로 다른 네임스페이스로부터 임의의 기타 요소를 포함할 수 있다.

또한, <trigger> 요소는, 적용할 동작 타입을 담고 있는 <operation> 요소를 포함하지 않거나 그 이상 포함하며, 확장성을 목적으로 다른 네임스페이스로부터 임의의 기타 요소를 포함할 수 있다.

또한, <operation> 요소는, 자식 요소로서 열거되어 있는 URI를 위한 촉발을 어떻게 적용할 것인가를 규정하는 "type" 속성을 포함하며, [RFC4826]에 기술되어 있는 바와 같이 자원의 URI를 담고 있는 <list> 요소를 포함하지 않거나 그 이상 포함할 수 있으며, 확장성을 목적으로 다른 네임스페이스로부터 임의의 기타 요소를 포함할 수 있다.

RLS 통보 기준에 따른 이벤트 통보 필터의 일례는 하기 표 7과 같다.

--boundary1--

Content-Type: application/simple-filter+xml

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
</ns-bindings>
<filter id="123">
<trigger>
<changed from="CLOSED" to="OPEN">
/pidf:presence/pidf:tuple/pidf:status/pidf:basic
</changed>
</trigger>
</filter>
</filter-set>

--boundary1

Content-Type: application/ vnd.oma.rls-notification-rule+xml

<?xml version="1.0" encoding="UTF-8"?>
<rule-set xmlns="urn:ietf:params:xml:ns:rls-notification-rule">
<ns-bindings>
<ns-binding prefix="rl" urn= "urn:ietf:params:xml:ns:resource-lists"/>
</ns-bindings>
<rule id="123">
<trigger>
<operation type="AND">
<rl:list>
<rl:entry uri="sip:bill@example.com" />
<rl:entry uri="sip:joe@example.org" />
<rl:entry uri="sip:ted@example.org" />
</rl:list>
</operation>
</trigger>
</rule>
</rule-set>
--boundary1--

한편, RLS에서의 RLS 통보 기준의 처리를 살펴보면 다음과 같다. RLS는 와처가 프레전스 리스트에 대해 SIP SUBSCRIBE 요청에서 정한 RLS 통보 기준을 지원할 수 있다.

RLS는 RLS 통보 기준과 함께 프레전스 목록에 대한 SUBSCRIBE 요청을 수신하면 다음 절차를 따른다.

먼저, RLS는 상기 표 6에서 설명한 바와 같이 컨텐츠-타입 "application/vnd.oma.rls-notification-rules+xml"을 지원한다. 또한, RLS는 RLS 통보 기준과 함께 SIP SUBSCRIBE 요청을 수신하면 포함된 조건을 평가하고 그 RLS 통보 기준을 저장한다. 그리고나서 RLS 통보 기준은 이 RLS에서만 유효하므로, RLS는 Presence-Server로 보내는 SIP SUBSCRIBE 요청에는 RLS 통보 기준을 포함하지 않는다. 이후, RLS는 프리젠티티의 목록으로부터 수신된 통보를 버퍼링하고, 규정된 조건이 충족되면 와처에게 전달한다.

도 1은 본 발명에서 고려하는 이용 경우와 관련된 객체들을 도시한 도면,

도 2는 본 발명에서 고려하는 이용 경우에 대한 종래 기술의 흐름도,

도 3은 본 발명에서 고려하는 이용 경우에 대한 본 발명의 흐름도.

Claims

다중 프리젠티티용 RLS(Resource List Server) 통보 기준을 제공하기 위한 방법에 있어서,

RLS가 와처에 의해 설정된 통보 기준을 포함하는 적어도 하나의 프리젠티티의 프레전스 정보를 요청하기 위한 가입 요청을 수신하는 과정과,

상기 RLS가 상기 적어도 하나의 프리젠티티로 상기 가입 요청을 전달한 후 상기 적어도 하나의 프리젠티티로부터 해당 프레전스 정보를 수신하는 과정과,

상기 프레전스 정보가 수신되면, 상기 RLS가 상기 와처에 의해 설정된 통보 기준이 충족되는지를 판단하는 과정과,

상기 RLS가 상기 통보 기준이 충족될 경우에 상기 프레전스 정보들을 통합하여 상기 와처로 전송하는 과정을 포함함을 특징으로 하는 다중 프리젠티티용 RLS 통보 기준을 제공하기 위한 방법.
제1항에 있어서,

상기 RLS가 상기 가입 요청에 상기 와처에 의해 설정된 통보 기준이 포함되어 있는지를 판단하는 과정과,

상기 통보 기준이 포함되어 있는 경우 상기 RLS가 상기 통보 기준을 저장하는 과정을 더 포함함을 특징으로 하는 다중 프리젠티티용 RLS 통보 기준을 제공하기 위한 방법.
제1항에 있어서,

상기 RLS가 상기 가입 요청을 상기 적어도 하나의 프리젠티티가 가입해있는 해당 서비스 운영자들에게로 전송하는 과정과,

상기 해당 서비스 운영자들이 상기 가입 요청을 상기 적어도 하나의 프리젠티티로 전송하는 과정과,

상기 해당 서비스 운영자들이 상기 적어도 하나의 프리젠티티로부터 프레전스 정보를 제공받는 과정과,

상기 적어도 하나의 프리젠티티 중 프레전스 정보가 변경되는 프리젠티티가 있을 경우, 상기 RLS가 상기 해당 서비스 운영자로부터 통보를 수신하는 과정을 더 포함함을 특징으로 하는 다중 프리젠티티용 RLS 통보 기준을 제공하기 위한 방법.
제1항에 있어서,

상기 가입 요청은 SUBSCRIBE를 사용하며, 상기 통보는 NOTIFY를 사용함을 특징으로 하는 다중 프리젠티티용 RLS 통보 기준을 제공하기 위한 방법.
제1항에 있어서, 상기 통보 기준의 동작 타입은,

상기 와처가 정한 목록의 프리젠티티들 전체로부터의 통보, 상기 와처가 정한 목록의 프리젠티티들로부터 일정 개수 이상의 통보, 상기 와처가 정한 목록의 프리젠티티들로부터 일정 개수 이하의 통보 및 상기 와처가 정한 목록의 프리젠티티들로부터 일정 개수의 통보를 수신한 경우에 따라 구분됨을 특징으로 하는 다중 프리젠티티용 RLS 통보 기준을 제공하기 위한 방법.
다중 프리젠티티용 RLS(Resource List Server) 통보 기준을 제공하기 위한 시스템에 있어서,

와처에 의해 설정된 통보 기준을 포함하는 적어도 하나의 프리젠티티의 프레전스 정보를 요청하기 위한 가입 요청을 전송하는 와처와,

상기 적어도 하나의 프리젠티티로 상기 가입 요청을 전달한 후 상기 적어도 하나의 프리젠티티로부터 해당 프레전스 정보를 통보받으면, 상기 와처에 의해 설정된 통보 기준이 충족되는지를 판단하고, 상기 통보 기준이 충족될 경우에 상기 프레전스 정보들을 통합하여 상기 와처로 전송하는 RLS를 포함함을 특징으로 하는 다중 프리젠티티용 RLS 통보 기준을 제공하기 위한 시스템.
제6항에 있어서, 상기 RLS는,

상기 가입 요청에 상기 와처에 의해 설정된 통보 기준이 포함되어 있는지를 판단하고, 상기 통보 기준이 포함되어 있는 경우 상기 통보 기준을 저장함을 특징으로 하는 다중 프리젠티티용 RLS 통보 기준을 제공하기 위한 시스템.
제6항에 있어서, 상기 적어도 하나의 프리젠티티가 가입해 있는 하나 이상의 해당 서비스 운영자들을 더 포함하고,

상기 해당 서비스 운영자들은 상기 RLS로부터 상기 가입 요청이 수신되면 상기 가입 요청을 자신들에 가입된 프리젠티티들로 전송하며, 상기 가입된 프리젠티티들로부터 프레전스 정보를 제공받으며, 상기 프리젠티티들 중 프레전스 정보가 변경되는 프리젠티티가 있을 경우 통보를 상기 RLS로 전송함을 특징으로 하는 다중 프리젠티티용 RLS 통보 기준을 제공하기 위한 시스템.
제6항에 있어서,

상기 가입 요청은 SUBSCRIBE를 사용하며, 상기 통보는 NOTIFY를 사용함을 특징으로 하는 다중 프리젠티티용 RLS 통보 기준을 제공하기 위한 시스템.
제6항에 있어서, 상기 통보 기준의 동작 타입은,

상기 와처가 정한 목록의 프리젠티티들 전체로부터의 통보, 상기 와처가 정한 목록의 프리젠티티들로부터 일정 개수 이상의 통보, 상기 와처가 정한 목록의 프리젠티티들로부터 일정 개수 이하의 통보 및 상기 와처가 정한 목록의 프리젠티티들로부터 일정 개수의 통보를 수신한 경우에 따라 구분됨을 특징으로 하는 다중 프리젠티티용 RLS 통보 기준을 제공하기 위한 시스템.