KR101511469B1

KR101511469B1 - 프레즌스 속성 기반의 프레즌스 통지 시스템 및 방법

Info

Publication number: KR101511469B1
Application number: KR20140019344A
Authority: KR
Inventors: 마유레시 마두카 패틸; 오재권
Original assignee: 삼성전자주식회사
Priority date: 2006-08-14
Filing date: 2014-02-19
Publication date: 2015-04-10
Also published as: WO2008020705A1; KR20080016467A; CN101507187A; US8849986B2; EP2052493A4; JP2010500840A; CN102307243A; CN102307243B; EP2858307A3; EP2506537B1; EP2052493B1; EP2506537A3; KR20150018860A; EP2506537A2; EP2052493A1; CN101507187B; KR20140033191A; EP2858307B1; EP2858307A2; US20140372608A1

Abstract

본 발명은 프레즌스 통지(Presence Notification)를 최적화하는 시스템 및 방법을 제공한다. 그러한 시스템은 프레즌스 구독(Presence Subscription) 및 프레즌스 정보(Presence Information)를 저장하는 프레즌스 서버(Presence Server); 및 인증 관련 정보를 저장하는 프레즌스 XDM 서버(XML Document Management Server)를 포함하는데, 프레즌스 서버는 프레즌스 속성 기반의 통지 전달에 관한 필터링 규칙(Filtering Rules)을 저장한다. 또한, 본 발명은 프레즌스 서버가 프레즌스 구독 및 프레즌스 정보를 저장하는 단계; 및 프레즌스 XDM 서버가 인증 관련 정보를 저장하는 단계를 포함하되, 프레즌스 속성 기반의 통지 전달에 관한 필터링 규칙을 프레즌스 서버와 함께 사용하는 프레즌스 속성 기반의 프레즌스 통지 방법을 개시한다.

Description

프레즌스 속성 기반의 프레즌스 통지 시스템 및 방법{SYSTEM AND METHOD FOR PRESENCE NOTIFICATION BASED ON PRESENCE ATTRIBUTE}

본 발명은 전반적으로 네트워크를 통한 네트워킹 및 통신에 관한 것이다. 본 발명은 OMA 프레즌스(Open Mobile Alliance Presence) 및 어베일러빌리티 워킹 그룹(OMA Presence and Availability Working Group)에 의해 정의된 사용자의 프레즌스 정보를 통지하는 절차에 적용될 수 있다. 다시 말해서, 본 발명은 SIP(Session Initiation Protocol) 기술에 관한 것으로, 프레즌스 통지를 최적화하는 것을 그 목표로 하고 있다. 더욱 구체적으로, 본 발명은 프레즌스 통지를 최적화하기 위한 프레즌스 속성 기반의 프레즌스 통지 시스템 및 방법에 관한 것이다.

프레즌스 시스템 구조는 임의의 사용자의 프레즌스 정보를 다른 사용자와 공유하는 것을 지원한다. 프레즌스 정보는 기본적으로 사용자의 현재의 위치, 사용자에 대한 가용 접속 정보, 또는 인스턴트 메시지 관련 정보, 사용자가 IM(Instant Messaging)에서 온라인인지 오프라인인지의 여부, POC (Push to Talk over Cellular) 특정 속성과 같은 애플리케이션 특정 정보 등의 사용자 관련 정보이다. 현재, 사용자는 요구되는 사용자의 프레즌스 정보를 구독할 필요가 있고, 아울러 다른 사용자는 그 사용자가 자신의 프레즌스 정보를 보는 것을 인증한다. 프레즌스 서버 엔티티(Presence Server Entity)는 프레즌스 구독을 유지하고, 사용자의 프레즌스 정보를 저장한다. 사용자의 프레즌스 정보가 변경되는 즉시, 프레즌스 서버는 와처(Watcher)들에게 통지를 보낸다. 와처들은 기본적으로 사용자의 프레즌스 속성을 보는 것을 인증받은 사용자들이다. 현재, 일단 사용자가 프레즌스 정보를 구독하고 나면, 그 사용자는 계속해서 프레즌스 정보 변경의 통지를 받게 된다. 그러한 구독 및 통지에는 SIP SUBSCRIBE 방법 및 SIP NOTIFY 방법이 사용된다. 그러한 방법들에서는, 네트워크 운영자의 주된 관심사인 방대한 통지 및 게시 트래픽(Traffic)이 있게 된다. 사용자의 수가 증가함에 따라, 부하는 그 이상으로 증가하고 있다. 선행 기술에 따르면, 불필요한 통지 트래픽이 네트워크 엔티티 및 액세스 네트워크를 통해 흐르는 경우가 있다.

선행 기술은 통지 바디(Body)에 프레즌스 정보에 대한 필터들을 정의하는 것을 지원하고 있다. 통지 바디는 프레즌티티(Presentity)의 각종의 프레즌스 정보로 이뤄진다. 사용자에 대한 프레즌스 속성들이 다수 존재하므로, 가입자는 프레즌스 속성들 모두에 대해 관심을 갖지 않을 수 있다. 그러한 프레즌스 속성을 거르는 것은 SUBSCRIBE 바디에 필터들을 정의함으로써 구현된다. 사용자는 요구되는 프레즌스 속성들을 구독함에 있어서 필터링을 지원하는 필터 규칙을 구독 바디에 규정하게 된다. 그러한 필터 규칙은 IETF 드래프트 "이벤트 통지 필터링 draft-ietf-simple-event-filter-funct-05의 기능 설명(Functional Description of Event Notification Filtering draft - ietf - simple - event - filter - funct -05)"에 정의되어 있다. 그러한 필터링 규칙은 일부 프레즌스 속성들에 대한 특정의 조건을 설정함으로써 통지를 보낼 시기에 대한 규칙도 또한 정의하고 있다. 예컨대, 가용 프레즌스 속성에 대한 상태가 오프라인으로부터 온라인으로 변경되면, 통지를 보낸다. 그러한 부류의 필터링 규칙이 구독 요청의 바디에 지정될 수 있으므로, 그 필터링 규칙은 콘텐츠 레벨을 설정하는데 사용된다.

전술된 선행 기술은 다음과 같은 한계점을 갖는다:

1. 현재, 프레즌스 속성의 변경 후마다 통지가 발송되어 통지 트래픽이 매우 높다.

2. 현재의 시나리오에서는 불필요한 통지들을 차단하기가 불가능하다.

3. 현재, 사용자는 자신의 선호도를 기반으로 하여 통지를 제어하지 못한다.

4. 사용자는 종종 다수의 클라이언트를 사용하는데, 사용자가 일부 클라이언트 장치에서 통지를 수신하는 것을 원치 않을 경우에, 그것을 선행 기술을 사용하여서는 구현할 수 없다.

IETF에 의해 정의된 현재의 필터 메커니즘은 기본적으로 콘텐츠 및 통지율을 제어하는 규칙에 대한 것이지만, 본 발명은 기본적으로 와처의 프레즌스 속성을 기반으로 하여 통지를 차단하는 것을 지향하고 있다. 그러한 규칙은 사용자가 통화 중이거나 사용자가 통지를 수신하고자 하지 않을 경우에 불필요한 프레즌스 통지들을 차단할 수 있게 한다. 그것은 통지 트래픽을 제어하는데 도움이 되고, 사용자가 통지 차단 필터링 규칙을 설정하는 것을 지원한다.

본 발명은 프레즌스 통지를 최적화하는 시스템 및 방법을 다루고 있다. 본 발명의 목적은 불필요한 통지를 회피하여 네트워크 부하 및 사용자에 대한 성가신 통지를 줄이는 것이다. 본 발명은 와처의 프레즌스 정보를 기반으로 하여 통지를 설정하는 것을 제안하고 있다. 본 발명은 와처의 프레즌스를 기반으로 하여 프레즌스 정보의 통지를 필터링하는 규칙을 설정하는 시스템 및 방법을 제공한다.

따라서 본 발명은 프레즌스 속성 기반의 프레즌스 통지 시스템으로서,

프레즌스 구독 및 프레즌스 정보를 저장하는 프레즌스 서버; 및

인증 관련 정보를 저장하는 프레즌스 XDM 서버를 포함하되, 프레즌스 서버가 프레즌스 속성 기반의 통지 전달에 관한 필터링 규칙을 저장하는 것을 특징으로 하는 프레즌스 통지 시스템을 개시한다.

따라서, 본 발명은 프레즌스 속성 기반의 프레즌스 통지 방법으로서,

프레즌스 서버가 프레즌스 구독 및 프레즌스 정보를 저장하는 단계; 및

프레즌스 XDM 서버가 인증 관련 정보를 저장하는 단계를 포함하되, 프레즌스 속성 기반의 통지 전달에 관한 필터링 규칙을 프레즌스 서버와 함께 사용하는 것을 특징으로 하는 프레즌스 통지 방법을 개시한다.

본 발명은 사용자가 자신의 프레즌스 속성을 기반으로 하여 통지 차단 필터를 설정할 수 있게 하는 시스템 및 방법을 제공한다.

본 발명의 이점은 다음과 같다:

i) 원치 않는 통지가 차단될 수 있기 때문에, 통지 트래픽을 줄일 수 있다.

ii) 사용자의 프레즌스 정보와 같은 사용자 선호도를 사용하여 통지를 설정할 수 있다.

iii) 사용자가 통지에 대해 기간을 설정할 수 있다.

iv) 사용자가 자신의 장치 타입을 기반으로 하여 통지를 제어할 수 있다.

또한, 본 명세서 및 첨부 도면에 의해 교시되는 바와 같은 본 발명의 여러 방법 및 장치의 조합으로부터 다른 제어 방법 및 장치를 도출할 수 있고, 그들 또한 본 발명의 범위 내에 있는 것임이 당업자에게 자명할 것이다. 또한, 그 때문에, 그러한 조합 및 변형들이 전술된 설명에서는 생략되어 있다. 아울러, 애플리케이션을 저장하기 위한 호스트는 비록 그에 한정되는 것은 아니지만 마이크로칩, 마이크로프로세서, 포켓용 통신 장치, 컴퓨터, 렌더링 장치, 또는 다기능 장치를 포함하는 것임을 알아야 할 것이다.

본 발명을 첨부 도면들을 참조하여 바람직한 실시예들과 관련지어 충분히 설명하였지만, 다양한 변경 및 수정이 가능하고, 그것이 당업자에게는 자명한 것임을 알아야 할 것이다. 그러한 변경 및 수정은 그것이 첨부된 청구 범위에 의해 한정되는 본 발명의 범위를 벗어나지 않는 그 범위 내에 속하는 것으로 이해되어야 할 것이다.

도 1은 시스템 구조를 나타낸 도면.
도 2는 논리 흐름을 나타낸 도면.
도 3은 단일 도메인 와처 및 동일 도메인에서의 프레즌스를 나타낸 도면.
도 4는 다중 도메인 구독 시나리오를 나타낸 도면.
도 5는 프레즌스 서버가 와처의 프레즌스 정보를 구독하고 나서 통지 블록 필터 규칙을 프레즌스 서버에 저장하는 대안을 나타낸 도면.
도 6 및 도 7은 프레즌스 통지 시나리오를 각각 나타낸 도면.

이후로 첨부 도면들과 결부지어 이뤄지는 본 발명의 상세한 설명으로부터 본 발명의 전술된 및 기타의 목적, 특징, 및 이점이 명확히 드러날 것이다.

이하, 본 발명의 바람직한 실시예들을 첨부 도면들을 참조하여 설명하기로 한다. 하지만, 개시되는 실시예들은 다양한 형태로 실시될 수 있는 본 발명을 예시하는 것에 불과하다는 것을 알아야 할 것이다. 이후의 설명 및 도면들은 본 발명을 한정하는 것으로 해석되어서는 안 되고, 특허 청구 범위에 대한 기초로서, 그리고 본 발명을 어떻게 구현 및/또는 사용할지를 당업자에게 교시하기 위한 기초로서 본 발명에 대한 완벽한 이해를 도모하고자 여러 특정 세부 사항들을 설명하기로 한다. 하지만, 특정의 경우에는, 본 발명을 쓸데없이 모호하게 하지 않기 위해 주지의 또는 종래의 세부 사항들에 관해서는 구체적으로 설명하지 않기로 한다.

현재의 프레즌스 시스템은 사용자가 다른 사용자들의 프레즌스 정보를 구독할 수 있게 한다. 프레즌스 서버는 구독 정보 및 프레즌스 정보를 유지한다. OMA 프레즌스 및 어베일러빌리티 그룹에서 정의하고 있는 현재의 프레즌스 시스템은 사용자가 통지에서 전송되는 정보의 양을 제어하기 위한 필터를 규정지을 수 있게 한다. 현재, 시간 속성에 의해 통지율도 제어될 수 있다. 하지만, 원치 않는 통지들이 프레즌스 서버에 의해 발생하는 경우가 여전히 많이 있다. 그리하여, 네트워크 트래픽에 과중한 부하가 걸리게 된다. 본 발명은 그러한 통지들을 제어하는 것을 그 목표로 하고 있다.

본 발명이 지향하고 있는 바는 와처의 프레즌스 정보를 기반으로 하여 통지를 줄이는 것이다. 본 발명은 와처의 프레즌스 정보를 기반으로 하여 통지를 보내는 것을 제안한다. 본 발명은 사용자가 통지를 보내거나 차단할지를 결정하는 기반이 되는 규칙을 설정할 수 있게 한다. 그에 대한 간단한 예는 와처가 통화 중일 경우에는 통지를 보내지 말게 하는 것이다. 사용자가 통화 중이어서 통지를 받기를 원치 않지만 구독을 계속하고자 하는 시기들이 많이 있다. 원치 않는 통지들이 전송되어 그러한 원치 않는 통지들을 전달하기 위해 네트워크 부하를 증가시켜야 하는 상황도 있다. 본 발명은 그러한 원치 않는 통지들을 차단하는 필터 규칙을 제안한다.

도 1은 제안된 본 발명의 시스템 구조를 나타내고 있다. 본 시스템 구조에는, 프레즌스 구독 및 프레즌스 정보를 저장할 프레즌스 서버(120) 및 인증 관련 정보를 저장할 프레즌스 XDM 서버(XML 문서 관리 서버; XML Document Mangement Server)(140)가 포함된다. 본 발명에서 제안하는 바는 프레즌스 서버(120)가 통지 전달에 관한 필터링 규칙도 또한 저장하는 것이다. 도 2에 도시된 바와 같이, 프레즌스 서버(120)에는 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터가 저장되고, 그 후에 와처에 대한 통지가 발생할 경우, 그 통지가 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터를 통과하게 되고, 이어서 그 필터가 허용하는 경우에만 그 통지가 와처에 보내진다. 본 발명은 그러한 와처의 프레즌스 속성을 기반으로 한 차단 필터링 규칙을 설정하고 적용하는 방법을 제안한다.

본 발명에서는 제안하는 바는 SUBSCRIBE 요청을 하면서 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터링 바디를 SUBSCRIBE 요청에 포함시키는 것이다. 본 발명은 와처의 프레즌스 속성을 기반으로 한 차단 필터와 그 동작 흐름 및 처리를 제안한다.

이하에서는, 단일 도메인 사례 및 다중 도메인 사례에 있어서의 흐름 및 동작 신호 흐름을 설명하기로 한다.

도 2는 단일 도메인에 관한 실시예의 하나로서, 전술된 필터 규칙을 설정하기 위해 본 발명에서 잇따라 수행되는 단계들을 나타내고 있다. 먼저, 클라이언트(110)는 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터 바디를 포함하는 SUBSCRIBE 요청을 구성한다. 그러한 필터 바디는 통지를 보내기 전에 확인해야 할 구체적인 조건, 예컨대 나의 프레즌스 상태가 통화 중이면 통지를 보내지 말 것과 같은 조건을 갖게 된다. 그러한 필터 바디는 XML(Extended Markup Language) 포맷으로 되어 있다. 프레즌스 서버(120)는 클라이언트(110)로부터 SUBSCRIBE 요청을 수신하고, 이어서 조건을 평가한다. 프레즌스 서버(120)가 그러한 조건을 해석할 수 있고, 또한 처리할 수 있으면, 프레즌스 서버는 200 OK 응답을 전송하고, 뒤이어 "CondOK"로서의 구독 상태 헤더 값과 프레즌스 속성을 갖는 바디를 포함하는 통지를 전송한다. 따라서, 요청된 통지 차단 필터링 규칙이 프레즌스 서버(120)에 저장되고, 통지의 발생 시마다 그 조건을 확인하게 된다.

도 3은 와처와 프레즌티티가 동일 도메인에 있는 단일 도메인에 대한 흐름도를 나타내고 있다.

1. 와처(310)는 그 바디에 통지 차단을 위한 필터를 갖는 SUBSCRIBE 요청을 전송한다.

2. SIP 코어(320)는 그 요청을 프레즌스 서버(330)에 전달한다.

3. 프레즌스 서버(330)는 그 요청을 수신하고, 인증 여부를 확인하며, 필터 바디 구조를 확인한다. 찾아낸 필터 바디가 유효하면, 프레즌스 서버(330)는 그 필터를 저장하고, 긍정의 응답을 전송한다. 인증이 허용되지 않으면, 프레즌스 서버(330)는 SIP SUBSCRIBE/NOTIFY 동작에 따라 부정의 응답을 전송한다. 또한, 프레즌스 서버(330)는 통지 차단 필터가 허용될 경우에 "CondOK"를 응답에 포함시키거나, 통지 차단 필터가 허용되지 않을 경우에 "CondReject"를 전송하고 요청된 구독을 종료시킨다. 대안적으로, 프레즌스 서버(330)는 요청된 구독을 허용하면서도 요청된 통지 차단 필터링 규칙만을 무효화시킬 수도 있다.

4. 프레즌스 서버(330)는 SIP 코어(320)를 통해 200 OK 응답을 전송한다.

5. SIP 코어(330)는 그 응답을 와처(310)에 전달한다.

6. 프레즌스 서버(330)는 요청된 통지 차단 필터가 수락되었는지 거부되었는지의 여부를 가리키는 "CondOK" 또는 "CondReject"로서의 적절한 상태를 갖는 초기 통지 응답을 전송한다.

7. SIP 코어(320)는 그 통지 응답을 와처(310)에 전송한다.

8. 프레즌티티를 나타내는 프레즌스 소스(340)는 프레즌티티의 프레즌스 정보에 관한 변경을 알아내어 갱신된 프레즌스 정보를 프레즌스 서버(330)에 게시(PUBLISH)한다.

9. 프레즌스 서버(330)는 통지를 발하고, 이어서 통지 차단 필터 규칙을 확인한다.

10. 통지 차단 필터 규칙이 통지의 전송을 허용하면, 프레즌스 서버(330)는 그 통지를 와처(310)에 전송한다.

11. SIP 코어(320)는 그 통지 요청을 와처(310)에 전달한다.

그와 같이 프레즌스 통지 차단 필터를 정의하고 그것을 프레즌스 서버(330)에 저장함으로써, 네트워크를 통한 불필요한 통지 흐름을 회피할 수 있게 된다. 그것은 또한 그러한 프레즌스 통지가 액세스 네트워크를 통해 흐르는 것을 회피하는데 도움이 되어 무선 환경에 매우 유용하게 된다.

도 4는 다중 도메인 사례를 나타내고 있다. 여기서, 클라이언트는 구독 요청을 전송하면서 라우트 헤더 필드(route header field)를 그에 포함시키고, 홈 프레즌스 서버(430)로서 그 값을 지정한다.

1. 와처(410)는 프레즌스 속성 기반 필터링을 위한 필터 바디를 갖는 SUBSCRIBE 요청을 전송하고, 또한 자신의 홈 프레즌스 서버 주소를 갖는 라우트 헤더 필드를 그에 첨부한다.

2. SIP 코어(450)는 그 요청을 와처의 홈 프레즌스 서버(430)에 전달한다.

3. 와처의 홈 프레즌스 서버(430)는 프레즌스와 관련된 필터를 추출하여 그 필터를 설정하고, 기록 라우트 헤더 및 그것의 주소를 첨부하여 그 요청을 프레즌티티 네트워크의 SIP 코어(450)에 전달한다.

4. SIP 코어(420)는 그 구독 요청을 프레즌티티의 프레즌스 서버(440)에 전달한다.

5. 프레즌티티의 프레즌스 서버(440)는 인증 정책 및 와처의 인증 여부를 확인한다. 프레즌스 서버(440)는 프레즌스 문서의 콘텐츠와 관련된 필터를 저장하고, 200 OK 응답을 전송한다.

6. 프레즌티티의 SIP 코어(450)는 200 OK 응답을 와처의 프레즌스 서버(430)에 전달한다.

7-8. 프레즌스 서버(430)는 200 OK 응답을 SIP 코어(450)를 경유하여 전달한다.

9-10. 프레즌스 서버(440)는 제1 초기 통지를 SIP 코어(420)를 통해 와처(410)에 전송한다. 그것은 전술된 200 OK 응답과 똑같이 와처의 프레즌스 서버(430)를 통해 라우팅된다.

11-12. 와처의 프레즌스 서버(430)는 제1 통지 및 적절한 상태 정보를 수신하고, 이어서 그것을 SIP 코어(420)를 경유하여 와처(410)에 전달한다.

13. 프레즌티티의 프레즌스 소스(460)는 PUBLISH 요청을 SIP 코어(450)를 통해 프레즌티티의 프레즌스 서버(440)에 전송하여 자신의 프레즌스 정보를 갱신한다.

14. SIP 코어(450)는 그 요청을 프레즌티티의 프레즌스 서버(440)에 전달한다.

15. 프레즌티티의 프레즌스 서버(440)는 프레즌티티의 프레즌스 문서를 갱신하고, 프레즌스 문서의 콘텐츠와 관련된 필터를 확인하며, 확인된 필터를 라우트 헤더에 첨부하여 그 통지를 와처의 프레즌스 서버(430)에 전송한다.

16. SIP 코어(450)는 그 통지를 와처의 프레즌스 서버(430)에 전달한다.

17-18. 와처의 프레즌스 서버(430)는 그 통지를 확인하고, 와처의 프레즌스와 관련된 필터를 확인하여 필터가 허용하면 그 통지를 SIP 코어(420)를 통해 와처(410)에 전달한다.

그와 같이 프레즌스 필터를 정의하고 그것을 프레즌스 서버에 저장함으로써, 불필요한 통지기 네트워크를 통해 흐르는 것을 회피할 수 있게 된다. 그것은 또한 그러한 프레즌스 통지가 액세스 네트워크를 통해 흐르는 것을 회피하는데 도움이 되어 무선 환경에 매우 유용하게 된다.

도 5는 프레즌티티의 프레즌스 서버가 와처의 프레즌스 정보를 구독하고 나서 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터링 규칙을 프레즌티티의 프레즌스 서버에 저장하는 대안을 나타내고 있다. 따라서, 프레즌티티의 프레즌스 서버는 와처의 프레즌스 정보를 기반으로 하여 통지를 차단하게 된다.

1-3. 와처(410)는 그 바디에 필터 규칙을 갖는 SUBSCRIBE 요청을 전송하는데, 그 요청은 프레즌티티의 프레즌스 서버(440)에 라우팅된다.

4. 프레즌티티의 프레즌스 서버(440)는 인증 여부를 확인하고, 이어서 그 필터 규칙을 설정하여 저장한다.

5-7. 프레즌티티의 프레즌스 서버(440)는 200 OK 응답을 SIP 코어(450, 420)를 통해 와처(410)에 전송한다.

8-10. 프레즌티티의 프레즌스 서버(440)는 프레즌티티의 프레즌스 정보의 초기 통지를 SIP 코어(450, 420)를 통해 와처(410)에 전송한다.

11-13. 프레즌티티의 프레즌스 서버(440)는 와처의 프레즌스 서버(430)로 요구되는 와처의 프레즌스 정보를 구독한다.

14-20. 와처의 프레즌스 서버(430)는 주도적으로 프레즌스 서버를 인증하고, 이어서 200 OK 응답 및 그에 뒤이은 와처의 프레즌스 속성의 통지를 프레즌티티의 프레즌스 서버(440)에 전송한다.

21-22. 프레즌티티의 프레즌스 정보가 변경될 경우, 프레즌티티에 대한 프레즌스 소스(440)는 PUBLISH 요청을 전송하여 프레즌티티의 프레즌스 서버(440)에 있는 프레즌스 정보를 갱신한다.

23. 프레즌스 서버(440)는 통지 차단 규칙 및 콘텐츠 필터링 규칙을 확인하여 통지를 전송할지의 여부를 결정한다.

24-26. 프레즌티티의 프레즌스 서버(440)는 필터 규칙을 확인한 후에 프레즌티티의 프레즌스 정보의 통지를 전송한다.

이하에서는, 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터 바디 구조를 설명한다.

본 발명은 필터링 규칙을 설정하기 위한 다음의 XML 스키마(XML Schema)를 가질 것을 제안한다. 그러한 스키마는 "Notifiaction-Block-Set"이라고 하는 하나의 루트 요소를 가질 것을 제안하고 있다. 그러한 루트 요소는 그 하나가 "PresAttrib"이고 다른 하나가 "TimeAttrib"인 2개의 요소를 갖는데, PresAttrib는 프레즌스 관련 조건을 설정하는데 사용되고, TimeAttrib는 통지에 대한 시간 기반 제어를 설정하는데 사용된다. PresAttrib는 다음의 속성들로 이뤄진다.

i. Equals: 과연 차단 조건이 무엇인지에 해당하는 프레즌스 속성

ii. Type: XPATH 또는 URI 등과 같은 값의 타입

iii. FID: 다른 필터와 구별 짓는 필터 ID

iv. ValidTime: 조건의 유효 기간

v. OperationType: 더 많은 필터의 추가, 필터링 규칙의 삭제와 같은 필터링

규칙에 관해 수행되는 동작

PresAttrib는 XPATH 또는 URI 포맷으로 된 프레즌스 속성으로서의 값을 갖게 되고, 그에 따라 프레즌스 서버는 프레즌스 속성이 Equals 속성치(필수적인 값임)와 같은지를 확인하고, 그에 해당하면 통지를 차단하게 된다. ValidTime 속성은 그 조건에 대한 유효 기간을 부여하는데 사용된다. TimeAttrib는 FROM 값으로부터 TO 값까지 통지를 차단하는 것과 같은 시간 기반의 통지 차단을 설정하는데 사용된다. 다수의 PresAttrib 수단을 가질 수 있는 PresFilter에서는 하나 이상의 조건이 설정될 수 있음을 유의해야 할 것이다. 1개 또는 2개의 PresAttrib가 존재하면, 논리 OR 동작으로 처리되고, 그것은 TimeAttrib에 대해서도 동일하다.

다음의 표 1은 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터의 전술된 구조에 대한 스키마 정의를 보이고 있다.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="urn:Notification-Filter-rules" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:Notification-Filter-rules" elementFormDefault="qualified" attributeFormDefault="unqualified">
<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">
XML Schema Definition for Filter Criteria.
</xs:documentation>
</xs:annotation>


<xs:attribute name="Equals" type="xs:string"/>
<xs:attribute name="ValidTime" type="xs:time"/>
<xs:attribute name="FID" type="xs:string"/>
<xs:attribute name="Type">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="XPATH"/>
<xs:enumeration value="URI"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="OperationType">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="ADD"/>
<xs:enumeration value="REMOVE"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>

<xs:attribute name="From" type="xs:time"/>
<xs:attribute name="To" type="xs:time"/>
<xs:attribute name="FiltID" type="xs:string"/>

<xs:complexType name="PresenceCond">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="Equals" use="required"/>
<xs:attribute ref="ValidTime" use="optional"/>
<xs:attribute ref="FID" use="required"/>
<xs:attribute ref="Type" use="optional" default="XPATH"/>
<xs:attribute ref="OperationType" use="optional" default="ADD"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="TimeAttribType">
<xs:simpleContent>

<xs:extension base="xs:boolean">
<xs:attribute name="From" type="xs:time" use="required"/>
<xs:attribute name="TO" type="xs:time" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>

<xs:element name="Notification-Block-Set">
<xs:complexType>
<xs:sequence>
<xs:element name="PresAttrib" type="PresenceCond" maxOccurs="unbounded"/>
<xs:element name="TimeAttrib" type="TimeAttribType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

다음의 표 2는 상기 표 1의 스키마 정의에 따른 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터의 예를 보이고 있다.

<?xml version="1.0" encoding="UTF-8"?>

<Notification-Block-Set xmlns=="urn:ietf:params:xml:ns:Notification-Filter-rules">

　 

　 <PresAttrib FID="123" Equals="away">
　　　//dm:person/rpid:activities/rpid:away
　 </PresAttrib>


　 <PresAttrib FID="567" Equals="closed">
　　　　　　　//dm:person/op:overriding-willingness/op:basic　　　
　 </PresAttrib>


　 <TimeAttrib FROM="6:00:00" TO="7:00:00">TRUE</TimeAttrib>

위에서는, 통지 차단 규칙 스키마에 대한 각종의 요소 및 속성의 정의에 관해 논하였다. 이하에서는, 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터의 스키마 처리에 관해 설명하며, 좀 더 상세하게는 XML 문서 포맷에 대한 처리 규칙을 설명하기로 한다.

먼저, 클라이언트측의 스키마 처리에 관해 살펴보면 다음과 같다.

클라이언트는 본 스키마를 SUBSCRIBE 바디에 프레즌스 속성 기반의 통지 차단 필터링 규칙을 정의하는데 사용하게 된다. 스카마의 정의에 따라, 클라이언트는 "PresAttrib" 요소를 사용하여 프레즌스 필터 규칙을 "Notification-Block-Set" 루트 요소에 포함시킨다. 클라이언트는 XPATH 표기법을 사용하여 또는 사용되는 포맷을 언급하는 "type" 속성을 갖는 다른 타입을 사용하여 프레즌스 속성 명칭으로서의 값을 PresAttrib에 지정하고, Equals 속성에서 프레즌스 속성의 값을 지정한다. "type" 속성이 누락되면, XPATH를 디폴트값으로 본다. 클라이언트는 FID 속성을 사용하여 고유 필터 ID를 규칙에 지정한다. 클라이언트는 다수의 조건을 포함하는 문서에 하나 이상의 PresAttrib를 포함시킬 수 있고, 그러한 조건들은 상이한 FID를 갖게 됨을 유의해야 할 것이다. PresAttrib는 "추가(ADD)" 또는 "삭제(REMOVE)"와 같은 동작의 타입을 나타내는 OperationType 속성도 갖는다. 삭제 OperationType 값을 갖는 PresAttrib는 필터 규칙을 삭제하는데 사용된다. 삭제가 PresAttrib 요소의 값에 언급된 특정의 값과 함께 사용된다면, 서버에 의해 교체(REPLACE) 동작이 수행될 필요가 있다. OperationType이 문서에 포함되지 않으면, ADD 값을 디폴트로 본다. 사용자가 특정의 조건에 대해 논리 AND 동작을 정의하고자 한다고 하면, 클라이언트는 2개의 "PresAttrib"를 추가하고, 2개의 PresAttrib에 동일한 FID 속성치를 지정한다.

클라이언트는 "TimeAttrib" 속성을 사용하여 시간 기반 필터 규칙을 정의할 수도 있다. 클라이언트는 TimeAttrib를 사용하여 요구되는 존속 시간에 따라 그에 상응하게 FROM 시간 속성치 및 TO 시간 속성치를 지정한다.

다음으로 서버측 스키마 처리에 관해 살펴보면 다음과 같다.

프레즌스 속성 기반의 통지 차단 필터 바디가 SUBSCRIBE 요청에서 수신되면, 서버는 스키마 정의를 사용하여 문서의 유효성을 확인한다. 필터가 유효하지 않을 경우, 서버는 오류를 생성한다. 그러한 확인 후에, 서버는 "PresAttrib" 요소 내의 프레즌스 속성과 "TimeAttrib" 요소 내의 시간 속성으로 이뤄진 통지 차단 필터 규칙을 바디로부터 판독하여 판독된 필터 규칙을 저장한다. 서버는 또한 언급되어 있는 경우에 그 규칙에 대한 유효 기간을 확인하고, 클라이언트에 의해 지정된 FID를 규칙에 지정한다.

다수의 "PresAttrib" 요소 및 "TimeAttrib" 요소가 존재하면, 서버는 그 모든 조건을 논리 OR 동작으로 처리한다. 서버가 동일한 FID를 갖는 2개의 조건을 식별해낸 경우에는, 그 2개의 조건에 대해 논리 AND 동작이 수행된다. 서버가 FID 및 "삭제"로서의 OperationType을 갖는 비어 있는 "PresAttrib" 요소 또는 "TimeAttrib" 요소를 수신하면, 동일한 FID를 갖는 특정의 기존 필터 규칙이 서버로부터 삭제된다. 서버가 FID 및 "교체"로서의 OperationType을 갖는 비어 있지 않은 "PresAttrib" 요소를 수신하면, 동일한 FID를 갖는 특정의 기존 필터 규칙이 그 요소에 언급된 규칙으로 교체된다.

이하에서는 와처의 동작에 관해 설명한다.

명시된 와처의 프레즌스 조건 동안에만 프레즌티티의 프레즌스 정보에 관한 통지를 수신하고자 하는 와처는 그러한 와처의 프레즌스 조건을 명시하는 프레즌스 통지 차단 필터를 갖는 SUBSCRIBE 요청을 생성한다. 와처는 상기 3절에서 설명된 바와 같이 통지를 수신할 자신의 선호 프레즌스 조건을 필터 바디에 명시하여 그 필터 바디를 프레즌티티의 프레즌스 정보에 대한 SUBSCRIBE 요청에 포함시킬 수 있다. SUBSCRIBE 요청에 포함될 경우, 그 필터에 대한 콘텐츠 타입은 "simple-filter-presfilter+xml"로서 명시될 수 있다.

이하에서는 프레즌스 서버의 동작에 관해 설명한다.

먼저 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터의 추출에 관해 살펴보면 다음과 같다.

본 발명에 의해 제안되는 바와 같은 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터에 대한 신규의 콘텐츠 타입은 simple-filter-presfilter+xml일 수 있다. SUBSCRIBE 요청의 바디에 포함될 경우, 그 콘텐츠 타입은 프레즌스 서버가 와처의 프레즌스와 관련된 통지 차단 필터의 존재를 식별하는데 사용된다. 그와 같이 식별된 경우, 프레즌스 서버는 SUBSCRIBE 바디로부터 통지 차단 필터를 추출하여 그것을 추후의 처리를 위해 저장한다.

다음으로, 추출된 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터의 처리에 관해 살펴보면 다음과 같다.

프레즌스 서버는 위에서 설명된 바와 같이 추출된 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터를 다음에 설명되는 바와 같이 처리한다:

프레즌스 서버가 와처의 프레즌스와 관련된 통지 차단 필터에 명시된 조건을 해석하거나 다룰 수 있으면, 프레즌스 서버는 200 OK 응답을 전송하고, 이어서 "active" 및"CondOK"로서의 구독 상태 헤더 값과 타깃 프레즌티티의 요청된 프레즌스 속성이 담긴 바디를 갖는 NOTIFY를 전송한다.

그와 같이 와처의 프레즌스와 관련된 통지 차단 필터로 성공적인 구독을 하고 나면, 프레즌스 서버는 그 필터링 규칙을 저장하여 향후의 NOTIFY 요청의 발생 시에 와처에 적용한다. 와처에 의해 요청된 바와 같은 프레즌티티의 프레즌스 속성을 포함한 NOTIFY 요청을 발생시킬 경우, 프레즌스 서버는 와처의 프레즌스 속성을 기반으로 한 통지 차단 규칙 내의 조건을 확인한다. 그 조건이 프레즌스 서버가 알고 있는 현재의 와처의 프레즌스 속성과 일치하면, 프레즌스 서버는 NOTIFY 요청을 와처에 전송하지 않고, 그렇지 않으면 NOTIFY 요청을 와처에 전송한다. 도 3은 그러한 절차에 의한 흐름을 나타내고 있다.

프레즌스 서버가 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터를 식별해냈지만 그 필터에 명시되어 있는 조건을 평가할 수 없으면, 프레즌스 서버는 200 OK 또는 202 Accepted 응답을 전송하고, 이어서 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터 내의 요청된 조건이 평가될 수 없음을 나타내는 "terminated" 또는 "CondReject"로서의 구독 상태 헤더 값을 갖는 NOTIFY 요청을 전송한 후에 구독을 종료시킨다.

대안적으로, 프레즌스 서버가 통지 차단 필터링 규칙을 해석하지 못함에도 구독을 유지하고자 한다면, 프레즌스 서버는 200 OK 또는 202 Accepted 응답을 전송하고, 이어서 구독을 계속하면서 후속 NOTIFY 요청에서 구독 상태 헤더를 "active" 또는 "CondReject"로 설정함으로써 구독을 유지한다. 따라서, 와처가 "active" 또는 "CondReject"로서의 구독 상태를 갖는 NOTIFY 요청을 수신할 경우, 클라이언트는 요청된 통지 차단 필터링 규칙이 프레즌스 서버에 의해 거부되거나 해석되지 못하였지만, 요청된 구독이 여전히 유효하여 타깃 프레즌티티의 요청된 프레즌스 속성에 관한 향후의 통지를 수신할 수 있음을 인식할 수 있게 된다.

프레즌스 서버가 통지 차단 필터링 규칙을 지원하지 않으면, 프레즌스 서버는 SUBSCRIBE 요청에 대해 403 Forbidden 응답 또는 다른 적절한 오류 응답을 전송한다. 그것은 프레즌스 서버의 로컬 정책에 따라 달라질 수 있다.

다음으로, 다중 도메인에 관해 살펴보면 다음과 같다.

와처가 타깃 프레즌티티의 도메인과는 다른 도메인에 있는 경우, 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터링 규칙을 갖는 SUBSCRIBE 요청은 도 4 및 상기 1b절의 단계들에서 예시된 바와 같이 와처의 프레즌스 서버로 라우팅된 후에 프레즌티티의 프레즌스 서버로 전달되어야 한다. 그 경우, 와처의 프레즌스 서버는 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터링 규칙을 전술된 바와 같이 다루고, 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터링 규칙을 성공적으로 처리하고 나면 향후에 프레즌티티의 프레즌스 정보에 대한 구독을 처리하기 위해 SUBSCRIBE 요청을 프레즌티티의 프레즌스 서버에 전달하고, 혹시 존재한다면 RFC 460 "통지 필터링의 기능 설명(Functional Description of Notification Filtering)"에 따른 와처의 이벤트 통지를 전달한다. 프레즌티티의 프레즌스 정보에 관한 NOTIFY 요청을 프레즌티티의 프레즌스 서버로부터 수신한 와처의 프레즌스 서버는 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터링 규칙이 현재의 와처의 프레즌스 속성과 일치하는지의 여부를 확인한다. 일치한다면, 와처의 프레즌스 서버는 수신된 NOTIFY 요청을 와처에 전달하는 것을 차단하고, 그렇지 않다면 바로 위에서 명시된 바와 같이 NOTIFY 요청을 전달한다.

전술된 다중 도메인에서는, NOTIFY 요청이 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터링 규칙의 처리 및 저장을 위해 와처의 프레즌스 서버로 라우팅되어야 한다. 하지만, SUBSCRIBE 요청은 현재 SIP 코어를 통해 프레즌티티의 프레즌스 서버로 직접 라우팅되기만 할 수 있다. 그런고로, 와처의 프레즌스 서버를 SUBSCRIBE SIP 세션 경로에 있도록 강제할 필요가 있다. 그것은 와처의 프레즌스 서버 또는 그 홈 프레즌스 서버의 SIP 주소를 갖는 SIP 라우트 헤더를 사용하여 구현될 수 있다. 따라서, 다중 도메인의 경우에는, 와처에 대한 홈 프레즌스 서버 또는 프레즌스 서버가 프레즌티티의 프레즌스 서버로부터의 통지를 전달하는 중계 서버로서의 역할을 하고, 와처로의 통지가 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터링 규칙에 의해 제어되어야 할 지점으로서 동작한다.

다음으로 다중 도메인에 관한 다른 실시예를 살펴보면 다음과 같다.

와처가 타깃 프레즌티티의 도메인과는 다른 도메인에 있는 경우, 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터링 규칙을 갖는 SUBSCRIBE 요청은 프레즌티티의 프레즌스 서버로 직접 라우팅되어야 한다. 그러면, 프레즌티티의 프레즌스 서버가 구독 요청을 다루고, 혹시 존재한다면 RFC 460 "통지 필터링의 기능 설명"에 따른 와처의 이벤트 통지를 다루게 된다. 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터링 규칙의 존재를 식별해낸 프레즌티티의 프레즌스 서버는 그 규칙을 전술된 바와 같이 다루고, 이어서 와처의 프레즌스 정보를 구독하여 와처의 최신 프레즌스 정보를 갖기 위해 SUBSCRIBE 요청을 와처의 프레즌스 서버에 전송한다. 프레즌티티의 프레즌스 정보에 대한 NOTIFY 요청이 발생하면, 프레즌티티의 프레즌스 서버는 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터링 규칙이 현재의 와처의 프레즌스 속성과 일치하는지의 여부를 확인한다. 일치한다면, 프레즌티티의 프레즌스 서버는 NOTIFY 요청을 와처에 전송하지 않고, rfjg지않으면 NOTIFY 요청을 와처에 전송한다. 도 5는 그러한 절차에 의한 흐름의 예를 나타내고 있다.

이하에서는, 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터의 대안적 구조 및 처리에 관해 설명한다.

위에서 설명된 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터 바디에 추가하여, 본 발명은 다음의 대안적 구조를 제안한다. 아래의 표 3은 그러한 대안적 구조에 대한 스키마 정의를 보이고 있다.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="urn:Notification-Filter-rules" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:Notification-Filter-rules" 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 Notification Block Filter Criteria.

</xs:documentation>
</xs:annotation>
<xs:element name="notblock-filter-set" type="NOTblockFilterSetType"/>
<xs:complexType name="NOTblockFilterSetType">
<xs:sequence>
<xs:element name="ns-bindings" type="NSBindings" minOccurs="0"/>
<xs:element name="notblock-filter" type="NOTblockFilterType" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="watcher-uri" type="xs:anyURI" use="optional"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</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="NOTblockFilterType">
<xs:sequence>
<xs:element name="presattrib" type="presattribType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="timeattrib" type="timeattribType" minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="remove" type="xs:boolean" use="optional" default="false"/>
<xs:attribute name="enabled" type="xs:boolean" use="optional" default="true"/>
<xs:attribute name="valid-till" type="xs:dateTime" use="optional"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="presattribType">
<xs:sequence>
<xs:element name="include" type="InclType" minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>
</xs:complexType>
<xs:complexType name="InclType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="type" type="TypeType" use="optional" default="xpath"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="TypeType">
<xs:restriction base="xs:string">
<xs:enumeration value="xpath"/>
<xs:enumeration value="namespace"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="timeattribType">
<xs:sequence>
<xs:element name="duration-date" type="duration-dateType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="duration-time" type="duration-timeType" minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="duration-dateType">
<xs:attribute name="from" type="xs:dateTime" use="optional"/>
<xs:attribute name="till" type="xs:dateTime" use="optional"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="duration-timeType">
<xs:attribute name="from" type="xs:time" use="optional"/>
<xs:attribute name="till" type="xs:time" use="optional"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
</xs:schema>

표 3은 본 발명에 의해 제안된 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터링 규칙에 대한 대안적 스키마를 보인 것으로, 그것은 기본적으로 RFC 4661 "이벤트 통지 필터링에 대한 XML 기반 포맷(XML Based Format for Event Notification Filtering)" 및 와처의 프레즌스를 기반으로 한 통지 차단 필터링 규칙을 지원하는 적절한 개선책에 그 기반을 두고 있다. 본 절에서는, 그러한 스키마 구조를 간략히 설명하기로 한다.

그 스키마는 "notblock-filter-set"이라 하는 루트 요소를 정의한다. 루트 요소는 다음의 요소들을 갖는다:

ns-bindings: 명칭 공간과 프리픽스 사이의 바인딩을 명시한다.

notblock-filter: 필터 규칙을 명시한다.

"notblock-filter-set" 루트 요소는 "watcher-uri"라 하는 하나의 속성도 또한 갖게 되는데, 그 속성은 그것의 프레즌스 속성을 기반으로 하여 통지 차단 필터링 규칙을 적용할 타깃 와처 URI를 명시한다.

"notblock-filter" 요소는 필터링 규칙을 명시하는데 사용된다. 그 요소는 다음의 속성들을 갖는다.

i) id: 본 속성은 필터 규칙을 식별하는데 사용된다.

ii) remove: 본 속성은 필터 규칙을 삭제하는데 사용된다. 그 값은 피연산자(참/거짓)이다.

iii) enable: 본 속성은 필터링 규칙을 이네이블/디스에이블하는데 사용된다. 그 값은 피연산자(참/거짓)이다.

iv) valid-till: 본 속성은 xmrwjdd의 필터에 대한 시간 및 일자의 효력을 명시한다. 그 값은 일시이다.

"notblock-filter" 요소는 2개의 자요소(child element)를 갖는데, 그 하나는 그에 관한 통지가 차단되는 특정의 프레즌스 정보에 대해 필터링 규칙을 정의하는 것을 지원하는 presattrib이고, 다른 하나는 통지를 차단하는 기간을 식별하는 것을 지원하는 timeattrib이다. "presattrib"는 "include" 요소를 갖고, "include" 요소는 그 "include" 요소의 값의 타입을 명시하는 하나의 "type" 속성을 갖는다. "type" 속성의 값은 "xpath" 또는 다른 어떤 것일 수 있는데, 여기서 "xapth"는 "type" 속성이 없는 경우에 디폴트값이 된다. 프레즌스 속성에 관한 특정의 조건을 명시하는데 XPATH 피연산자를 사용할 수 있다(표 5의 예를 참조). 하나보다 더 많은 include 요소를 포함시켜 다중 조건을 명시하기도 한다. 다중 조건은 논리 AND 동작으로 처리된다. 상이한 notblock-filter 요소에 명시된 프레즌스 조건들은 논리 OR 동작으로 처리된다.

"notblock-filter" 요소의 "timeattrib" 자요소는 통지를 차단하는 기간을 명시하는데 사용된다. 그러한 요소는 그 하나가 duration-time이고 다른 하나가 duration-date인 2개의 요소를 갖는다. "duration-time" 요소 및 "duration-date" 요소는 그 하나가 "from"이고 다른 하나가 "till"인 2개의 속성을 갖는데, 그 속성들은 존속 시간 및 존속 일자를 각각 명시하는데 사용된다(표 4의 예를 참조). 그러한 기간 동안에는, 모든 통지가 차단된다.

다음의 표 4는 상기 표 3에서와 같은 대안적 스키마 정의에 따른 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터의 예를 보이고 있다.

<?xml version="1.0" encoding="UTF-8"?>
<notblock-filter-set xmlns="urn:Notification-Filter-rules"
watcher-uri="target_watcher@example.com">
<ns-bindings>

<ns-binding prefix="dm" urn="urn:ietf:params:xml:ns:pidf:data-model"/>
<ns-binding prefix="rpid" urn="urn:ietf:params:xml:ns:pidf:rpid"/>
</ns-bindings>




<notblock-filter id="123">
<presattrib>
<include>//dm:person/rpid:activities/rpid:away</include>
<include>//dm:person/rpid:activities/rpid:meeting</include>
</presattrib>
</notblock-filter>


<notblock-filter id="567">
<presattrib>
<include>//dm:person/op:overriding-willingness[op:basic="closed"]</include>
</presattrib>
</notblock-filter>


<notblock-filter id="abc">
<timeattrib>
<duration-time from="18:00:00" till="00:00:00"/>
<duration-time from="00:00:00" till="08:00:00"/>
</timeattrib>
</notblock-filter>

</notblock-filter-set>

표 3에서의 스키마 정의에 따른 와처의 프레즌스 속성을 기반으로 한 통지 차단 필터 바디는 위의 언급에 추가하여 다음과 같이 처리된다:

먼저 클라이언트측 처리는 다음과 같다.

클라이언트는 전술된 스키마를 사용하여 SUBSCRIBE 바디에 프레즌스 속성 기반의 통지 차단 필터링 규칙을 정의한다. 스크마의 정의에 따라, 클라이언트는 통지를 수신하고 싶지 않을 경우에 각각의 "notblock-filter" 요소 항목에 통지 차단 규칙을 명시할 수 있다. 다중 통지 차단 규칙이 명시된 경우, 통지는 "notblock-filter" 요소 내에 명시된 통지 차단 규칙 중의 하나에 부합될 경우에 차단되게 된다. 즉, "notblock-filter-set" 루트 요소 하의 각각의 "notblock-filter" 요소 내에 들어있는 통지 차단 필터링 규칙의 평가는 논리 OR 동작으로 처리된다.

클라이언트는 "presattrib" 자요소 또는 "timeattrib" 자요소를 사용하여 "notblock-filter" 요소 내의 통지 차단 규칙에 다수의 조건들을 명시할 수 있다. 그 다수의 조건들의 평가는 논리 AND 동작으로 처리된다. 즉, 규칙 내의 모든 조건이 참(TRUE)으로 평가된 경우에만 "notblock-filter"의 통지 차단 규칙에 부합하는 것이다. 클라이언트는 하나의 통지 차단 필터링 규칙을 이루는 각각의 "notblock-filter" 요소에서 "presattrib" 요소를 사용하여 통지 차단을 위한 프레즌스 속성을 명시할 수 있다. 그러한 프레즌스 속성들은 XPATH의 포맷으로 표현될 수 있다. 클라이언트는 또한 "timeattrib" 요소를 사용하여 통지가 차단될 존속 시간을 명시할 수 있다. "timeattrib" 요소는 2가지 타입의 자요소를 갖는다. 그중에서, "duration-time" 자요소는 통지가 차단되는 매일의 존속 시간을 명시하는데 사용되는 한편, "duration-date" 자요소는 통지가 차단되는 정확한 일자 및 존속 시간을 명시하는데 사용된다.

클라이언트는 "notblock-filter" 요소의 "id" 속성의 값을 사용하여 "notblock-filter" 요소에 들어있는 통지 차단 필터링 규칙을 식별해낼 수 있다. 클라이언트는 "notblock-filter" 요소의 "enable" 속성의 값을 사용하여 통지 차단 필터링 규칙을 이네이블/디스에이블할 수 있다. 클라이언트는 "notblock-filter"의 "remove" 속성의 값을 사용하여 통지 차단 필터링 규칙을 삭제할 수 있다. 클라이언트는 "notblock-filter" 요소의 "valid-till" 속성을 설정함으로써 통지 차단 필터링 규칙의 유효 존속 시간을 설정할 수 있다.

다음으로 서버측 처리는 다음과 같다.

SUBSCRIBE 요청에서 프레즌스 속성 기반의 통지 차단 필터 바디에 관한 클라이언트의 요청을 수신할 경우, 서버는 전술된 스키마 정의를 사용하여 문서의 유효성을 확인한다. 필터가 유효하지 않은 경우, 서버는 오류를 생성한다. 그러한 확인 후에, 서버는 SUBSCRIBE 바디로부터 통지 차단 필터 규칙을 추출하여 그것을 저장한다.

"notblock-filter" 요소에 명시된 통지 차단 필터링 규칙을 평가할 경우, 서버는 "notblock-filter-ser" 루트 요소의 "watcher-uri" 속성에 의해 명시된 타깃의 프레즌스 속성이 "presattrib" 요소들 내의 프레즌스 조건들과 일치하는지의 여부를 확인한다. 또한, 서버는 현재의 시간이 "timeattrib" 요소들에 명시된 존속 시간 조건들과 일치하는지의 여부를 확인한다. 모든 프레즌스 조건 및 시간 조건이 일치하면, 통지 차단 필터링 규칙은 참으로 평가된다.

"notblock-filter-set" 내의 하나 이상의 통지 차단 규칙이 참으로 평가될 경우, 서버는 통지를 차단한다. 서버는 다음의 조건들 중의 하나에 부합되면 "notblock-filter" 요소 내의 통지 차단 규칙을 무시하고 평가하지 않는다:

"notblock-filter" 요소의 "enable" 속성의 값이 거짓(FALSE)으로 설정된경우, 또는

"notblock-filter" 요소의 "valid-till" 속성에 명시된 시간이 만료된 경우.

서버가 "id" 속성 및 참으로 설정된 "remove" 속성을 갖는 "notblock-filter" 요소 내의 통지 차단 규칙을 수신할 경우, 서버는 동일한 "id" 속성치를 갖는, 서버에 저장된 통지 차단 규칙을 삭제한다.

이하에서는, 본 발명에 의한 프레즌스 속성을 기반으로 한 프레즌스 통지 방법에 관해 설명한다.

본 절은 도 6 및 도 7에 도시된 예들을 제시한다.

먼저, 사용자가 부재시에 필터를 설정하는 경우는 다음과 같다.

도 6에 도시된 바와 같은 본 예에서는, 사용자 A(610)가 필터 규칙을 "자신의 부재 시에는 통지를 보내지 말 것"으로 설정한다. 그를 위해, 사용자 A(610)는 SUBSCRIBE 요청을 구성하고, 본 발명에서 정의된 스키마에 따라 통지 차단 필터 규칙을 바디로서 그에 포함시킨다. 본 예에서는, 사용자 A(610)가 RFC 4480 "프레즌스 정보 데이터 포맷(PIDF)으로의 리치 프레즌스 확장(Rich Presence Extensions to the Presence Information Data Format (PDIF))"에 따른 PIDF 문서의 "away" RPID 요소로 PresAttrib를 설정하고, 그에 따라 프레즌스 서버(610)는 사용자 A의 RPID 프레즌스 속성이 "away"이면 통지를 보내지 않는다.(640) 프레즌스 서버(620)는 상기 요청을 수신한 후에 그 요청을 분석하고, 이어서 구독 상태 헤더 요소에 CondOK를 포함하는 통지를 보낸다. 그와 같이, 본 방법을 사용하여 통지 차단 필터링 규칙을 설정한다.(650)

다음으로 클라이언트가 통신을 사양할 경우에는 다음과 같다.

도 7에 도시된 바와 같은 본 예에서는, 사용자 A(610)가 필터 규칙을 "자신이 통신을 사양할 경우 통지를 보내지 말 것"으로 설정한다. 그를 위해, 사용자 A(610)는 SUBSCRIBE 요청을 구성하고, 본 발명에서 정의된 스키마에 따라 통지 차단 필터 규칙을 바디로서 그에 포함시킨다. 본 예에서는, 사용자 A(610)가 PIDF 문서의 "overriding-willingness" 요소로 PresAttrib를 설정하고, "closed"로 "Equals" 속성을 설정하며, 그에 따라 프레즌스 서버(620)는 사용자 A(610)의 "overrriding-willingness" 프레즌스 속성이 "closed"이면 통지를 보내지 않는다.(740) 프레즌스 서버(610)는 상기 요청을 수신한 후에 그 요청을 분석하고, 이어서 구독 상태 헤더 요소에 CondOK를 포함하는 통지를 보낸다. 그와 같이, 본 방법을 사용하여 필터링 규칙을 설정한다.(750)

110: 프레즌스 클라이언트 A, 120: 프레즌스 서버, 130: 프레즌스 소스, 140: XDM 서버

Claims

프레즌스 통지를 제공하기 위한 프레즌스 서버에 있어서,
와처 클라이언트로부터 프레즌스 통지 전달에 관한 필터링 규칙(filtering rule)을 포함하는 구독 요청(subscription request)을 수신하는 통신부; 및
인증 정보(authorization information)를 이용하여 상기 구독 요청의 인증 여부를 판단하고,
상기 필터링 규칙의 허용 여부를 결정하고,
상기 구독 요청이 인증되고 상기 필터링 규칙이 허용된 경우에 상기 프레즌스 통지 전달의 차단에 적용하기 위해 상기 필터링 규칙을 저장하고,
상기 구독 요청의 인증이 실패한 경우에 상기 구독 요청의 인증 실패를 상기 와처 클라이언트에게 통지하고,
상기 구독 요청이 인증되고 상기 필터링 규칙이 허용되지 않는 경우에 상기 필터링 규칙이 허용되지 않음을 상기 와처 클라이언트에게 통지하도록 제어하는 제어부를 포함하는, 프레즌스 서버.
제1항에 있어서,
상기 통신부는 프레즌스 XDM 서버(Presence XML Document Server)에 저장된 상기 인증 정보를 수신하는, 프레즌스 서버.
제1항에 있어서,
상기 통신부는 다른 클라이언트로부터의 프레즌스 통지를 수신하고,
상기 제어부는 상기 필터링 규칙에 기반하여 상기 와처 클라이언트로의 상기 프레즌스 통지 전송 여부를 결정하는, 프레즌스 서버.
제3항에 있어서,
상기 제어부는 상기 와처 클라이언트의 프레즌스 속성이 상기 필터링 규칙에 대응하는 통지 차단 필터를 통과하면 상기 프레즌스 통지를 전송하는, 프레즌스 서버.
프레즌스 통지를 제공하기 위한 방법에 있어서,
와처 클라이언트로부터 프레즌스 통지 전달에 관한 필터링 규칙(filtering rule)을 포함하는 구독 요청(subscription request)을 수신하는 단계;
인증 정보(authorization information)를 이용하여 상기 구독 요청의 인증 여부를 판단하는 단계;
상기 필터링 규칙의 허용 여부를 결정하는 단계;
상기 구독 요청이 인증되고 상기 필터링 규칙이 허용된 경우에 상기 프레즌스 통지 전달의 차단에 적용하기 위해 상기 필터링 규칙을 저장하는 단계;
상기 구독 요청의 인증이 실패한 경우에 상기 구독 요청의 인증 실패를 상기 와처 클라이언트에게 통지하는 단계; 및
상기 구독 요청이 인증되고 상기 필터링 규칙이 허용되지 않는 경우에 상기 필터링 규칙이 허용되지 않음을 상기 와처 클라이언트에게 통지하는 단계를 포함하는, 프레즌스 통지 제공 방법.
제5항에 있어서,
프레즌스 XDM 서버(Presence XML Document Server)에 저장된 상기 인증 정보를 수신하는 단계를 더 포함하는, 프레즌스 통지 제공 방법.
제5항에 있어서,
다른 클라이언트로부터의 프레즌스 통지를 수신하는 단계; 및
상기 필터링 규칙에 기반하여 상기 와처 클라이언트로의 상기 프레즌스 통지 전송 여부를 결정하는 단계를 더 포함하는, 프레즌스 통지 제공 방법.
제7항에 있어서,
상기 전송 여부 결정 단계는,
상기 와처 클라이언트의 프레즌스 속성이 상기 필터링 규칙에 대응하는 통지 차단 필터를 통과하면 상기 프레즌스 통지를 전송하는, 프레즌스 통지 제공 방법.
프레즌스 통지를 수신하는 단말에 있어서,
프레즌스 통지 전달에 관한 필터링 규칙(filtering rule)을 생성하는 제어부; 및
상기 필터링 규칙을 포함하는 구독 요청(subscription request)을 프레즌스 서버로 전송하고,
상기 구독 요청이 인증 정보(authorization information)에 의해 인증되고, 상기 필터링 규칙이 허용되고, 다른 클라이언트부터의 프레즌스 통지가 상기 필터링 규칙을 만족하는 경우에 상기 프레즌스 서버로부터 상기 프레즌스 통지를 수신하고,
상기 구독 요청의 인증이 실패한 경우에 상기 구독 요청의 인증 실패를 나타내는 통지를 상기 프레즌스 서버로부터 수신하고,
상기 구독 요청이 인증되고 상기 필터링 규칙이 허용되지 않는 경우에 상기 필터링 규칙이 허용되지 않음을 나타내는 통지를 상기 프레즌스 서버로부터 수신하는 통신부를 포함하는, 단말.
삭제
제9항에 있어서,
상기 통신부는 상기 다른 클라이언트로부터의 프레즌스 정보가 변경되고, 상기 프레즌스 통지가 상기 필터링 규칙을 만족하는 경우에 상기 변경된 프레즌스 정보를 수신하는, 단말.
프레즌스 통지를 수신하는 방법에 있어서,
프레즌스 통지 전달에 관한 필터링 규칙(filtering rule)을 생성하는 단계;
상기 필터링 규칙을 포함하는 구독 요청(subscription request)을 프레즌스 서버로 전송하는 단계;
상기 구독 요청이 인증 정보(authorization information)에 의해 인증되고, 상기 필터링 규칙이 허용되고, 다른 클라이언트부터의 프레즌스 통지가 상기 필터링 규칙을 만족하는 경우에 상기 프레즌스 서버로부터 상기 프레즌스 통지를 수신하는 단계;
상기 구독 요청의 인증이 실패한 경우에 상기 구독 요청의 인증 실패를 나타내는 통지를 상기 프레즌스 서버로부터 수신하는 단계; 및
상기 구독 요청이 인증되고 상기 필터링 규칙이 허용되지 않는 경우에 상기 필터링 규칙이 허용되지 않음을 나타내는 통지를 상기 프레즌스 서버로부터 수신하는 단계를 포함하는, 프레즌스 통지 수신 방법.
삭제
제12항에 있어서,
상기 다른 클라이언트로부터의 프레즌스 정보가 변경되고, 상기 프레즌스 통지가 상기 필터링 규칙을 만족하는 경우에 상기 변경된 프레즌스 정보를 수신하는 단계를 더 포함하는, 프레즌스 통지 수신 방법.