KR20080031140A

KR20080031140A - Ｘｄｍ 서버의 히스토리를 관리하기 위한 시스템 및 방법

Info

Publication number: KR20080031140A
Application number: KR1020070099859A
Authority: KR
Inventors: 오재권; 마유레시 마두카르 포틸
Original assignee: 삼성전자주식회사
Priority date: 2006-10-03
Filing date: 2007-10-04
Publication date: 2008-04-08
Also published as: KR101490520B1; WO2008041831A8; WO2008041831A1

Abstract

본 발명은 XDM(XML Document Management) 서버 히스토리(History) 저장의 관리 및 개선을 위한 시스템 및 방법에 관한 것으로서, XML(Extensible Markup Language) 문서 및 XML 문서의 히스토리 정보에 대한 필터링 규칙을 전송하는 제1 XDM 클라이언트 디바이스(The First XDM Client Device)와, XML 문서(XML Document) 및 XML 문서의 필터링 규칙을 수신하여 저장하는 XDM 서버와, XDM 서버에 저장된 XML 문서를 액세스(Access)하는 제2 XDM 클라이언트 디바이스(The Second XDM Client Device)를 포함하고, XDM 서버가 제2 클라이언트 디바이스가 XML문서를 액세스하는 경우, 필터링 규칙에 따른 히스토리 정보를 저장함을 특징으로 하는, XDM 서버의 히스토리를 관리하기 위한 시스템을 제공한다.

이러한 구성에 의하여, 본 발명은 히스토리의 저장 및 관리를 개선하는 효과가 있다. 좀 더 구체적으로는 사용자가 어떤 정보가 히스토리에 저장되고, 언제 저장되는지를 선택할 수 있으므로, 불필요한 정보의 저장을 피할 수 있으며 히스토리의 관리가 용이해진다. 아울러 사용자는 히스토리 정보의 검색(Search)과 독출(Retrieve) 역시 용이하게 할 수 있다.

XDM 서버, 히스토리

Description

ＸＤＭ 서버의 히스토리를 관리하기 위한 시스템 및 방법{SYSTEM AND METHOD FOR MANAGING XML DOCUMENT MANAGEMENT SERVER HISTORY}

본 발명은 일반적인 모바일 애플리케이션(Mobile Application)에 관한 것이다. 본 발명은 애플리케이션-특정(Application Specific) XML 문서(Extensible Makrup Language Document)들이 저장되는 XDM 서버에 적용될 수 있다. 본 발명은 또한 서버에서 XML 문서의 관리에 이용되는 XCAP 프로토콜(Protocol)에 관한 것이다. 특히 본 발명은 XDM 서버 히스토리(History) 저장 개선을 위한 시스템 및 방법에 관한 것이다.

권한부여 정책(Authorization Policy), 콘택 리스트(Contact List), 그룹 리스트(Group List)에 대한 다양한 문서의 저장을 위한 PoC(Push to talk Over Cellular) 및 IM XDM 서버(Instant Messagning XDM 서버)와 같은 다양한 SIP(Session Initiation Protocol) 기반 통신 애플리케이션이 있다. 이러한 종류의 정보는 애플리케이션-특정 XDM 서버로 저장된다. 공유 정보는 공유 XDM 서버에 저장될 것이다. OMA 포럼(Open Mobile Alliance Forum)은 다양한 모바일 애플리케이션, 예를 들어 인증 규칙 및 콘택 및 그룹 콘택 정보를 저장하는 IM XDM 서버, 프레즌스(Presence) XDM 서버에 대한 효율적인 XML 문서 관리를 위한 XDM 프로토콜을 표준화하고 있는 중이다. XMD 서버 프로토콜은 XML 문서들에 대한 추가, 생성, 삭제 및 수정 동작을 할 수 있도록 한다.

SIP 기반 통신 애플리케이션에 대한 기본 구성이 도 1에 도시되어 있다. 위 구성을 살펴보면, XDM 클라이언트 디바이스(XDM Client Device)(110) 및 애플리케이션 서버(120), 예컨대 IM 서버, 프레즌스 서버가 있다. SIP 코어(130)는 애플리케이션 서버와 XDM 클라이언트 디바이스(110) 사이에 위치한다. 애플리케이션-특정 XDM 서버가 애플리케이션 특정 정보(고정:static)를 XML 포맷(Format)으로 저장하는데 이용된다. XCAP 프로토콜이 그러한 XML 포맷 정보를 관리하는데 이용된다. XDM 클라이언트 디바이스(110)는 XCAP 프로토콜을 이용하여 통합 프락시(Aggregation Proxy)(150)를 통해 XML 문서들에 액세스(Access)하기 위한 XDM 클라이언트 디바이스(110)를 가진다. 이는 OMA 포럼에서 정의된 바와 같이 SIP 기반 애플리케이션에 대한 기본 구성이다.

도 2는 XDM 서버(140)에 저장된 XML 문서에 XCAP 동작들을 수행하는 기존의 다양한 XCAP 과정들을 보여준다. 도 2에 도시한 바와 같이, 만약 클라이언트가 XDM 서버(140)로부터 XML 리소스(XML Resource)를 획득하기 원할 경우, XDM 클라이언트 디바이스(110)는 통합 프락시9150)를 통해 XDM 서버(140)로 XCAP GET 요청(Request)을 전송한다. 통합 프락시(140)는 XDM 클라이언트 디바이스(110)를 인증할 것이다.(S210)

만일 사용자가 기존의 문서를 생성하거나 업데이트(Update)하기를 원할 경우 에는 사용자는 XCAP PUT 동작을 전송하고 XML 콘텐트(Content)를 XDM 서버(140)에 대한 요청의 바디(Body)에 포함시킨다.(S220)

만일 사용자가 위 문서나 문서의 일부분을 삭제하기 원할 경우 사용자는 XML Detele 요청을 XDM 서버(140)로 전송한다.(S230)

XCAP은 또한 검색(Search) 관련 동작들을 위한 XCAP POST 방법을 지원한다. 검색을 원할 때마다 사용자는 XCAP POST 방법을 통합 프락시(150)로 전송하고, 통합 프락시(150)는 동일한 요청을 검색 프락시(Search Proxy)(200)로 전송한다. 그러면 인턴(Intern) 검색 프락시는 POST 요청을 XMD 서버(140)로 전송하고 XDM 서버로부터 위 정보를 독출(Retrieve)한다. 검색 프락시(200)는 결과를 모으고, 그 검색 결과를 XDM 클라이언트 디바이스(110)로 전송한다.(S240)

OMA 포럼은 사용자에 의해 XML 문서 또는 리소스에 수행된 동작에 대한 히스토리 정보의 저장을 위한 요건을 제시하였다. 히스토리 저장의 주요 사용 케이스(Case)는 위임 동작(XML 문서에 엔트리 추가, 업데이트 및 삭제와 같은 XCAP 동작들)으로부터 유래한다. 사용자는 다른 사용자들에게 특정 XML 문서에 대한 수정이나 액세스를 위임할 수 있다. 따라서 히스토리 정보인 다른 사용자에 의해 수행된 동작의 저장은 중요하다. 사용자는 히스토리의 사용이 가능해야 한다. 종래의 요구사항은 히스토리 정보의 저장이다. 종래에는 사용자는 "히스토리에 무엇을 저장하는지"와 "히스토리 정보를 언제 저장하는지"를 선택할 수 없다. 사용자가 히스토리 정보를 선택적으로 저장하는 것이 바람직할 것이다. 종래 기술의 다양한 제약들이 다음에서 논의되며, 그에 따라 새로운 개선을 위한 동기가 논의된다.

종래 기술에서 동작들의 히스토리 저장에 대한 요구에 관한 기술이 있다. 히스토리 정보가 XDM 서버로 저장된다. 히스토리 정보는 사용자에 의해 요구될 때 검색될 수 있다. 종래 기술의 경우에서는 단지 히스토리 정보 동작의 사용가능(Enable) 또는 사용해제(Disable)만이 허용된다. 그러나 본 발명은 히스토리 저장을 위한 필터링 규칙(Filtering Rule)을 구비한다. 이는 사용자가 히스토리에 무엇을 저장하는지와, 히스토리 정보를 언제 저장하는지를 정의하는 것을 지원한다. 이러한 종류의 정보는 사용자 관점에서 매우 유익하다. 다음은 종래 기술의 몇 가지 단점이다.

1. 사용자에 의해 수행된 동작들이 많을 가능성이 있고, 따라서 모든 정보를 저장하는 것이 서버에 문제가 될 수 있으며, 나중에 사용자는 히스토리 정보를 얻기 위해 엄청난 양의 정보 전체를 가져올(Fetch) 필요가 있게 된다.

2. 모든 히스토리 정보의 저장이 필요치 않을 수 있다. 따라서 종래 기술은 불필요한 정보를 히스토리 정보에 저장하고 있다.

3. 이벤트(Event) 기반 히스토리 저장은 종래 기술에서 가능하지 않으며, 여기서 이벤트 기반이라는 것은 특정 이벤트들이 발생할 경우에만 히스토리 문서에 저장하는 것을 의미한다. 이는 사용자가, 이벤트의 전체 세트가 아닌, 특정 이벤트를 추적하기 원하는, 그러한 많은 경우에서 도움이 될 것이다. 추적 이후에 특정 이벤트 히스토리를 검색하는 것이 용이하기 때문에 사용자에게 유연성을 제공할 것이다.

4. 종래의 XDM 히스토리에서는, 사용자가 시간 기반 저장을 설정할 수 없으 며, 이는 어느 날의 특정 시간에 문서에 관한 동작을 수행하는 문서 관리자가 없는 경우에 더 중요할 것이다. 따라서 그 시간 동안 그는 위 동작들의 추적을 원할 것이다. 이는 사용자에게 매우 유용할 것이다.

본 발명은 이러한 문제들을 해결하고 종래 기술에서 언급된 제약들을 극복하는 시스템 및 방법을 제공한다.

본 발명은 사용자로 하여금 어느 문서에라도 히스토리를 설정할 수 있게 하는, 히스토리 저장 관리를 위한 방법을 제공한다.

본 발명은 XDM 서버에서 히스토리 저장 요건을 강화시키는 것을 목표로 한다. 본 발명은 히스토리에 저장되는 정보와, 상기 히스토리 정보를 언제 저장하는지를 선택하는 필터를 정의한다(이벤트 기반 히스토리 저장). 본 발명은 또한 이를 달성하는 필터 규칙을 이용하는 방법을 더 제안한다.

본 발명은 XDM 동작들을 위한 히스토리 작동 시스템 및 방법을 제공한다.

구체적으로는, 본 발명은 히스토리 필터 규칙들을 설정하는 시스템 및 방법을 더 제공한다.

아울러 본 발명은 시간 기반 히스토리 저장을 위한 시스템 및 방법을 더 제공한다.

상기 해결하고자 하는 과제를 해결하기 위하여, 본 발명은 XML 문서(XML Document) 및 상기 XML 문서의 히스토리(History) 정보에 대한 필터링 규칙(Filtering Rule)을 전송하는 제1 XDM 클라이언트 디바이스(The First XDM Client Device)와, 상기 XML 문서 및 상기 XML 문서의 필터링 규칙을 수신하여 저장하는 XDM 서버와, 상기 XDM 서버에 저장된 XML 문서를 액세스(Access)하는 제2 XDM 클라이언트 디바이스(The Second XDM Client Device)를 포함하고, 상기 XDM 서 버가, 상기 제2 클라이언트 디바이스가 상기 XML문서를 액세스하는 경우, 상기 필터링 규칙에 따른 히스토리 정보를 저장함을 특징으로 하는, XDM 서버의 히스토리를 관리하기 위한 시스템을 제공한다.

본 발명의 구성에 의하여, 히스토리의 저장 및 관리를 개선할 수 있다. 좀 더 구체적으로는 사용자가 이벤트를 기반으로 히스토리의 저장에 관해 설정할 수 있으며, 이로 인해 히스토리의 관리가 용이해진다. 특히 사용자가 어떤 정보가 히스토리에 저장되고, 언제 저장되는지를 선택할 수 있으므로, 불필요한 정보의 저장을 필요할 수 있으며 히스토리의 관리가 용이해진다. 아울러 사용자는 히스토리 정보의 검색과 독출 역시 용이하게 할 수 있다.

한편, 사용자는 시간을 기반으로 히스토리의 저장에 관해 설정할 수 있으며, 이 역시 사용자의 히스토리 관리를 용이하게 해주는 효과가 있다.

종래 기술에서 설명한 현재의 XDM 히스토리 메커니즘(Mechanism)에서의 제약을 해결하기 위하여, 본 발명은 다음의 새로운 요건들을 제시한다:

1. 사용자는 히스토리 정보 기능을 동작시키거나 해제시킬 수 있다.

2. 사용자는 어느 정보/동작이 히스토리 정보로서 저장되는지를 선택할 수 있다. 하나의 예는: 오직 XCAP PUT 동작만이 히스토리 정보로서 저장되는 것이며, 사용자 관점에서 XCAP PUT이 XCAP GET 보다 훨씬 중요한 동작이다. 따라서 동작의 전체 리스트를 저장하는 대신에 특정 동작에 대해서만 히스토리 정보를 저장할 수 있다.

3. 사용자는 어느 이벤트 때에 동작이 히스토리 정보로서 저장되는지를 선택할 수 있다. 하나의 예로서: 오직 위임된 동작만 히스토리 정보로서 저장된다.

4. 사용자는 위 동작에서의 어떤 정보가 히스토리 정보로서 저장되는지를 선택할 수 있다. 하나의 예로서: XCAP 방법, 동작 요청자(Operation Requestor) 및 동작에서의 시간만이 히스토리 정보로서 저장되는 것이다.

5. 그룹 문서의 경우에, 그룹은 어느 사용자에 의해 생성될 수 있으며, 이러한 사용자를 그 그룹의 관리자라고 한다. 어느 관리자가 몇 가지 동작들을 그 사용자에게 위임할 수 있지만, 그는 특정 사용자의 추가와 같은 중요한 동작을 로그(Log)하기 원할 수 있으며, 그럼으로써 그 관리자는 이후 시점에 상기 그룹에 추가된 사람을 알 수 있다.

6. 사용자는 또한 특정 문서에 행해진 동작에 대한 인스턴트 정보를 얻기 위하여 히스토리의 히스토리 문서 변경들을 구독(Subscribe)할 수 있다. 여기서는 누군가에 의해 XCAP PUT 동작이 수행된 때 통지하는 것과 같은 선택된 동작의 통지를 사용자가 받을 수 없다. 그러나 만약 사용자가 히스토리 저장에 필터를 적용한다면 선택적인 통지를 받을 수 있다. 이는 사용자에게 더 유연성을 제공하고, 또한 사용자가 히스토리의 문서 변경을 구독하였을 경우에 불필요한 히스토리 정보를 피할 수 있다.

본 발명은 히스토리 관리를 위한 시스템 및 방법을 제공한다. 본 발명은 또한 상술한 개선을 제시한다. 본 발명은 또한 이러한 개선을 위한 시스템 및 방법을 제공한다. 본 발명은 XDM 서버 및 XDM 클라이언트 디바이스에 대한 추가적인 동작을 더 제안한다. 본 발명은 히스토리 저장을 위한 새로운 필터를 정의한다. 이러한 필터는 시간 기반 히스토리 저장을 정의하는데 도움을 준다. 그것은 또한 무엇이 히스토리 정보에 저장되는지를 정의한다.

본 발명은 또한 히스토리 저장 기능을 작동 및 해제하는 방법을 제공한다.

A. 상세한 방법

본 발명에 있어서 아래에서는 사용자로 하여금 히스토리 선호도를 설정할 수 있게 하는 상세한 방법을 제공한다. 기본적인 제안은 사용자에 의해 설정되어 히스토리 저장을 필터링하는 새로운 필터링 규칙들을 정의하는 것이다. 본 발명은 사용자가 히스토리 저장에 몇 가지 선호도를 설정할 수 있도록, XCAP 요청에 새로운 필터 바디를 정의한다. 이 새로운 구조는 하기에서 설명한다. 여기서는 히스토리 및 그와 관련된 대응 필터들을 설정하는 기본 방법을 설명한다. 본 발명에서는, XCAP PUT 방법이, 히스토리 기능을 설정하고 그와 관련된 필터들을 설정하는데 이용된다. XDM 클라이언트 디바이스는 XCAP PUT 요청을 이용하고 XCAP PUT의 바디에 히스토리 설정을 언급할 것이다. 따라서 XDM 서버는 이러한 요청을 수신하고 나서, 필터에 따라, 히스토리 문서에 상기 히스토리 선호도를 저장하고, 상기 히스토리 설정을 적용하고, 다른 사용자에 의해 수행된 동작들을 저장한다.

도 3은 이러한 기능을 위한 기본적인 논리 흐름을 보여준다. 하기에서는 XDM 클라이언트 디바이스(111, 112)및 XDM 서버(140) 동작을 설명한다.

XDM 클라이언트 디바이스(111, 112) 측의 동작을 살펴보면 다음과 같다.

도 3에 도시한 바와 같이, 특정 리소스(즉, XDMS의 XML 문서)에서 수행된 동작들의 히스토리 정보에 대한 저장 요청을 전송할 것이다. 사용자는 또한 어떤 종류의 정보가 상기 히스토리에 저장될 필요가 있는지 그리고 언제 상기 히스토리 정보를 저장하는지에 대한 필터 정보를 추가할 수 있다. XDM 클라이언트 디바이스A(111)가 일단 히스토리 정보를 사용가능하게 하고 또한 그것에 대한 필터 정보를 설정하고 나면, XDM 서버(140)는 요청에 의해 확인된 그 특정 리소스에서 수행된 동작에 관한 히스토리 정보를 저장할 것이다. 위 필터는 사용자로 하여금 어떤 동작 및 상기 동작의 어느 부분들이 히스토리 정보로서 저장되는지를 설정할 수 있게 하고, 또한 히스토리 저장에 대한 시간 주기(Time Period)를 설정할 수 있게 한다. 사용자는 또한 선택된 동작들에 대한 히스토리 저장을 설정할 수 있다. 이러한 동작에 이용되는 상기 방법은 XCAP PUT이다. 본 발명은 또한 XCAP PUT 요청 바디에 있는 히스토리 제어 정보를 위한 새로운 콘텐트 타입(Content-Type)을 정의한다. 그럼으로써 XDM 클라이언트 디바이스A(111)는 적합한 바디를 갖는 XCAP PUT 요청을 전송할 것이다. 이 바디는 히스토리 기능이 사용가능하게 되는 리소스들을 확인한다. 이 필터 바디는 또한 본 발명에서 제안된 다양한 개선을 지원하기 위한 다양한 필터링 규칙을 정의하도록 한다. XDM 클라이언트 디바이스A(111)는 위 요청을 적절하게 발생시키고 히스토리 규칙을 XDM 서버(140)로 설정한다. 그러한 규칙에 따라, XDM 서버(140)가 위 히스토리 정보를 저장할 것이다.

한편, XDM 서버(140) 측의 동작을 살펴보면 다음과 같다.(S320)

XDM 서버(140)가 XDM 클라이언트 디바이스A(111)로부터 히스토리 요청과 함 께 그 바디에 있는 히스토리 필터 규칙들을 수신한다. XDM 서버(140)는 위 히스토리 필터 규칙을 저장하고 위 요청에 명시된 목표 리소스에 대하여 히스토리 기능을 작동시킨다. 이어 XDM 서버(140)는 필터 설정에 따라 리소스에 수행된 동작들의 히스토리 정보를 저장하기 시작한다.

XDM 서버(140)의 상세한 동작은 다음과 같다.

- XCAP PUT 요청을 수신하면, XDM 서버(140)는 바디의 타당성을 체크한다. 그러한 타당성 체크는 특정된 목표 리소스 또는 XML 문서가 XDM 서버(140)에 존재하는지 여부를 체크하는 것을 포함한다.

- 타당성 체크가 성공적으로 수행되고 나면, XDM 서버(140)가 XCAP PUT 요청의 바디에 있는 히스토리 규칙들을 요청 라인(Line)의 특정된 URI 위치에 저장한다.

- 성공적으로 처리하고 나면, XDM 서버(140)가 XDM 클라이언트 디바이스A(111)에게 응답을 전송하고, 히스토리 규칙들에 따라 히스토리 기능을 작동시킨다.

아래의 표 1은 히스토리 필터 바디에 관하여 예시하고 있다.

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns="urn:oma:params:xml:ns:XDMHistory" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:oma:params:xml:ns:XDMHistory">  <xs:attribute name="State"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="ON"/> <xs:enumeration value="OFF"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="CondID" type="xs:string"/> <xs:attribute name="Resource" type="xs:anyURI"/> <xs:element name="OppType"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="ADD"/> <xs:enumeration value="REMOVE"/> <xs:enumeration value="REPLACE"/> <xs:enumeration value="NEW"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Include"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="Opptype"/> <xs:enumeration value="timestamp"/> <xs:enumeration value="User"/> <xs:enumeration value="change"/> <xs:enumeration value="OriginalValue"/> <xs:enumeration value="FreeText"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="User" type="xs:anyURI"/> <xs:complexType name="timeAttrib"> <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="FilterCond"> <xs:complexType> <xs:sequence> <xs:element ref="OppType" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="User" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="timeAttrib" type="xs:time" minOccurs="0"/> </xs:sequence> <xs:attribute ref="CondID"/>" use="Required"/> <xs:attribute ref="Resource"/> <xs:attribute ref="State"/> </xs:complexType> </xs:element> <xs:element name="WhatStore"> <xs:complexType> <xs:sequence> <xs:element ref="Include"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="History">  <xs:complexType> <xs:sequence> <xs:element ref="FilterCond" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="WhatStore" minOccurs="0" maxOccurs="1"/> </xs:sequence> <xs:attribute ref="State" use="required"/> <xs:attribute ref="Resource" use="required"/> </xs:complexType> </xs:element> </xs:schema>

도 4는 스키마(Schema) 구조 블록을 나타내고, 표 1은 상세한 히스토리 필터 스키마를 나타낸다. 위 스키마는 XCAP PUT 바디에 사용된다. 이 스키마는 사용자들로 하여금 히스토리 저장을 작동/해제시킬 수 있게 하고, 히스토리 저장과 관련된 필터 규칙들을 설정할 수 있게 한다. 스키마는 "History"(400)라고 불리는 하나의 루트(Root) 요소를 정의한다. "History"(400) 요소는 히스토리가 작동되는지 해제되는지를 나타내는, "State"(410)라고 불리는 2개의 속성(Attribute) 및 히스토리 기능이 작동/해제되는 목표 XML 문서를 확인하는 URI를 포함하는 "Resource"(420)를 가진다. 예를 들어, 만약 사용자가 그/그녀의 콘택 리스트(Contact List)에 수행된 동작들의 히스토리를 갖기 원한다면, "Resource"(420)는 상기 콘택 리스트의 URI일 것이다. 루트 요소 내부에서 정의된 2개의 요소가 있으며, 하나는 히스토리를 위한 필터 규칙들을 정의하는 "FilterCond"(430)이고, 다른 하나는 동작(정보)의 어느 부분들이 히스토리 정보로서 저장되는지를 나타내는 "WhatSrore"(440)이다.

"FilterCond"(430) 요소는 히스토리 정보를 저장하기 위한 조건을 정의한다. 그것은 "OppType"(434), "User"(435) 및 "TimeAttrib"(436)인 3개의 자(子) 요소를 가진다. "OppType"(434) 요소는 어느 동작이 히스토리 요소로서 저장되어야 하는지를 정의하는데 이용된다. 그것은 ADD, REMOVE, REPLACE 및 NEW와 같은 다양한 값들을 취할 수 있다. 만일 "OppType"(434)이 ADD로 설정된 경우에는 모든 추가적인 동작들이 히스토리 정보로서 저장된다. "User"(435)요소는 특정된 사용자가 위 동작을 요청할 때 그것을 특정하는데 이용되며, 그러면 위 동작이 히스토리 정보로서 저장되는 것이다. "TimeAttrib"(436)는 그 동안 위 동작들이 히스토리 정보로서 저장되어야 하는 시간 주기(Time Period)를 특정하는데 이용된다. "FilterCond"(430)는 3개의 속성을 가지는데, "CondID"(431)는 필터 규칙을 확인하는데 이용되고, "Resource"(420)는 어느 리소스에 관하여 이러한 필터 규칙이 적용되는지를 나타내며, "State"(410)는 특정 필터 규칙에 대한 활성 상태를 나타낸다.

"WhatStore"(440)는 히스토리 문서로 캡쳐(Capture)될 필요가 있는 다양한 값을 정의하는데 이용된다. 그것은 "Include"(441)라는 하나의 요소를 갖는다. 사용자는 이 "Include"(441) 요소를 이용하여 히스토리 스토리지(History Storage)로 저장되어야 하는 정보를 표시한다.

이하에서는 XDM 클라이언트 디바이스 측의 프로세싱 규칙을 설명한다.

XDM 클라이언트 디바이스(110)는 히스토리 저장을 작동시키고 해제시키기 위해 XCAP PUT 방법을 이용한다. 여기서는 XDM 클라이언트 디바이스(110)는 본 발명에서 정의된 스키마를 이용하여 다양한 필터링 규칙을 정의하는 바디를 포함할 것이다. XDM 클라이언트 디바이스(110)는 "FilterCond"(430)를 이용하여 다양한 유형의 조건을 정의할 수 있다. XDM 클라이언트 디바이스(110)는 또한 하나 이상의 "FilterCond"(430) 요소를 포함할 수 있다. 다른 "FilterCond"(430) 하에서 정의된 규칙들은 논리적으로 OR일 것이다.

XDM 클라이언트 디바이스(110)는 또한 하나 이상의 "Include"(441) 요소를 포함시킴으로써 "WhatStore"(440) 요소를 이용하여 어떤 정보가 히스토리 문서로 포함되어야 하는지를 나타낼 수 있다. 예를 들어, 만약 사용자가 히스토리 문서에 사용자의 이름만을 추가하기 원할 경우에, 사용자는 "Include"(441) 요소를 "WhatStore"(440) 요소에 추가하고 값을 "User"(435)로 설정할 것이다.

다음의 표 2는 히스토리 작동에 관한 예시이다.

PUT http://xcap.example.com/address??book/users/ adbook1_filter.xml HTTP/1.1 Host: xcap.example.com User??Agent: XDM??client/OMA1.0 Date: Tue, 01 Aug 2006 17:00:01 GMT+9 X??XCAP??Asserted??Identity: "sip:history_function_요청or@example.com" Content??Type: application/vnd.oma.history+xml Content??Length: (...) <?xml version="1.0" encoding="UTF??8"?> <!???? Enable History ????> <History xmlns=="urn:ietf:params:xml:ns:XDMHistory" State="ON" Resource="http://xcap.example.com/address??book/users/ adbook1"> </History>

표 2는 XDM 클라이언트 디바이스(110)가 그룹 어드레스 리스트(Group Address List)에 대한 XDM 히스토리를 작동시키기를 원할 경우의 바디를 보여준다. 여기서 XDM 클라이언트 디바이스(110)는 루트 요소를 포함하고, "State"(410) 속성은 "ON"으로 설정된다. XDM 클라이언트 디바이스(110)는 또한 "Resource"(432) 속성 값을 어드레스 북의 URI로서 설정한다. 이와 같이 XDM 클라이언트 디바이스(110)는 특정 "Resource"(432)에 대하여 위 히스토리를 작동시킬 수 있다.

다음의 표 3은 히스토리 정보의 작동 및 필터 규칙들의 설정에 관하여 예시하고 있다.

PUT http://xcap.example.com/address??book/users/ adbook1_filter.xml HTTP/1.1 Host: xcap.example.com User??Agent: XDM??client/OMA1.0 Date: Tue, 01 Aug 2006 17:00:01 GMT+9 X??XCAP??Asserted??Identity: "sip:history_function_요청or@example.com" Content??Type: application/vnd.oma.history+xml Content??Length: (...) <?xml version="1.0" encoding="UTF??8"?> <!???? Enable History ????> <History xmlns=="urn:ietf:params:xml:ns:XDMHistory" State="ON" Resource="http://xcap.example.com/address??book/users/ adbook1"> <FilterCond ConID="132" State="ON"> <OppType>ADD</OppType> </FilterCond> </History>

표 3에서, XDM 클라이언트 디바이스(110)는 XDM 서버(140)에게 히스토리 정보로서 '추가' 동작만을 저장하라고 지시하는 필터 규칙을 설정한다.

이하에서는 XDM 서버(140) 측의 프로세싱 처리 규칙에 대하여 설명한다.

XDM 클라이언트 디바이스(110)가 XCAP PUT 요청을 전송하는 경우에, XDM 서버(140)는 콘텐트 타입을 체크할 것이고, 만일 콘텐츠 유형이 "application/vnd.oma.history+xml"이라면, XDM 서버(140)는 그것이 히스토리 요청라는 것을 알 수 있을 것이다. 따라서 XDM 서버(140)는 필터 규칙의 존재를 체크하고, 만일 필터 규칙이 이미 거기에 있다면, 그것은 상기 필터 규칙을 변경하라는 요청이다. 만일 필터 규칙이 존재하지 않는다면, XDM 서버(140)는 위에서처럼 요청된 필터 규칙들을, XCAP PUT 요청의 요청 라인에 특정된 바와 같이, URI에 저장한다. 이어서 XDM 서버(140)는 응답으로서의 그 결과를 저장할 것이다.

XMD 서버(140)는 필터 바디를 저장하고 위 요청에 따라 히스토리 저장을 작동/해제시킬 것이다. XDM 서버(140)는 히스토리 바디를 추출하고, 필터 바디의 타당성을 체크할 것이다. XDM 서버(140)는 루트 요소 히스토리의 "State"(410) 속성을 체크할 것이며, 만일 상태 요소가 'ON'이라면 그것은 히스토리의 턴온(Turn On)된 것을, 그 반대는 턴오프(Turn Off)된 것을 각각 의미한다. 따라서 상기 "State"(410) 속성이 히스토리 정보를 작동 또는 해제시키는데 이용된다. XDM 클라이언트 디바이스(110)는 언제 히스토리 정보를 저장하는지에 대한 조건들을 설정하기 위한, 하나 이상의 필터 조건을 포함할 수 있다. 만일 "OppType"(434)가 '추가(ADD)'로 설정된다면, 오직 추가 요청만이 XDM 히스토리로 기록될 것이다. 마찬가지로 "User"(435) 요소가 특정 이름으로 설정될 경우에, 그 사용자에 의해 수행된 동작들이 히스토리 정보에 저장될 것이다. 마찬가지로 "TimeAttrib"(436)이 사용자에 의해 설정된다면, XDM 서버(140)는 히스토리 정보를 기록하기 위해서 이러한 시간 주기를 이용할 것이다. XDM 클라이언트 디바이스(110)는 다중 필터 조건들을 포함할 수 있으며, XDM 서버(140)는 이들 조건의 논리적인 OR을 행할 것이다. XDM 서버(140)는 또한 무엇이 히스토리 문서에 저장되는지를 지시하는 "WhatStore"(440) 요소를 추출한다.

다음에서는 XCAP POST 요청에 기반을 둔 히스토리 제어를 위한 대안적 솔류션(Solution)에 대하여 설명한다.

본 발명에서는 히스토리 및 필터 규칙들을 설정하기 위한 XCAP POST 요청을 제안한다. 여기서 XDM 클라이언트 디바이스(110)는 이미 언급한 제안과 동일한 바디를 갖는 XCAP POST 요청을 사용한다. 도 5는 히스토리 저장을 설정하기 위한 기본적인 흐름을 보여준다.

다음의 표 4는 목표 리소스(Target Resource)에 대하여 히스토리 기능을 작동시키는 XDM 클라이언트 디바이스(110)로부터의 예시적인 요청 메시지를 예시하고 있다.(다음의 예는 PoC XDMS의 PoC 그룹 문서에 대하여 히스토리 기능을 작동시킨다.)

POST http://xcap.example.com/org.openmobilealliance.poc/history HTTP/1.1 Host: xcap.example.com User-Agent: XDM-client/OMA1.0 Date: Tue, 01 Aug 2006 17:00:01 GMT+9 X-XCAP-Asserted-Identity: "sip:history_function_요청or@example.com" Content-Type: application/vnd.oma.history+xml Content-Length: (...) <History xmlns="urn:ietf:params:xml:ns:XDMHistory" Resource="http://xcap.example.com/org.openmobilealliance.poc/users/sip:history_function_요청or@example.com/poc-groups.xml" State="ON" />

위 요청 라인은 XDM 서버(140)에 대한 라우팅(Routing) 가능한 URI(이는 "http://xcap.example.com/org.openmobilealliance.poc"이다) 및 히스토리 기능 제어를 위한 서비스 디렉토리(이는 "/history"이다)를 포함한다.

위 바디는 목표 리소스 및 히스토리 기능 제어(즉, ON/OFF)를 포함한다. 바디는 본 IDF에 의해 제안된 바와 같이 필터와 같은 히스토리 기능 제어를 더 포함할 수 있다.

히스토리 기능이 작동되고 나면, 목표 리소스에 대한 예정된 히스토리 문서, 예를 들어 "poc-groups.history.xml"가 히스토리 정보를 저장하는데 이용될 것이다. 이는 히스토리 저장을 위한 시스템-발생 사용자 문서(System-Generated user Document)이다.

다음에서는 SIP SUBSCIBE를 이용한 대안적인 방법에 대하여 설명한다.

이 방법에서는, 히스토리를 설정하고 다른 사용자들에 의해 수행된 동작들에 대한 통지를 얻는 SIP SUBSCRIBE 방법을 제안한다. 이 메커니즘에서는 사용자가 XDM-히스토리와 같은 이벤트 패키지를 갖는 SUBSCRIBE 바디를 전송할 것이다. 이 방법은 상기 히스토리를 작동시킬 수 있거나 상기 히스토리 기능을 해제시킬 수 있는, XDM-히스토리라고 불리는 새로운 이벤트 패키지를 제안한다.

이 방법에서, 만약 사용자가 히스토리 기능을 작동시키기를 원한다면 사용자는 XDM-히스토리와 같은 이벤트 패키지를 갖는 SIP SUBSCRIBE 방법을 XDM 서버(140)로 전송할 것이다. XDM 서버(140)가 XDM-히스토리 기능과 같은 이벤트를 갖는 위 SIP SUBSCRIBE를 수신하면, XDM 서버(140)는 그것을 사용자가 위 히스토리 기능을 요청하고 있는 것으로 간주한다.

동일한 요청으로서 사용자는 수행된 동작에 대한 통지를 요청할 수 있다는 것을 유념한다. 이는 논제로(Nonzero) 값인 만료 필드(Expires Field)를 갖는 SUBSCRIBE 요청을 전송함으로써 수행될 수 있다. 따라서 XDM 서버(140)가 사용자에 의해 몇 가지 동작이 수행된 때에 통지도 또한 전송할 수 있고, XDM 서버(140)는 또한 히스토리 기능의 해당 동작을 저장한다.

만일 사용자가 앞서 정의된 히스토리 필터 스키마에 기반을 둔 히스토리 기능을 저장하기 위한 필터링 규칙들을 설정하기 원한다면, 사용자는 이 필터링 바디를 SIP SUBSCRIBE BODY에 포함시킨다. 동일한 바디 포맷이 앞서 정의된 바와 같이 이용될 수 있다. 도 6은 본 발명에 대한 기본 논리 흐름을 보여준다.

만약 사용자가 히스토리 기능을 작동시키기를 원하면, SIP SUBSCRIBE 요청을 발생시키고, 히스토리 선호도에 대한 필터 바디를 포함시키고 나서, 요청-URI를 "Rsource"(432)에 설정한다. 만약 사용자가 키 동작들에 대한 통지를 수신하기를 원한다면, 만료 필드(Expires Field) 값을 논제로(Nonzero)로 입력한다. 만약 사용자가 단지 히스토리 기능을 작동이나 해제시키기를 원한다면, 사용자는 제로인 만료 필드를 입력할 것이다.

다음의 표 5는 히스토리 설정을 위한 SUBSCRIBE를 예시하고 있다.

SUBSCRIBE sip:my??buddy??list@example.com SIP/2.0 Via: SIP/2.0/TCP terminal.example.com; branch=z9hG4bKwYb6QREiCL Max??Forwards: 70 To: <sip:my??buddy??list@example.com> From: <sip:brian@example.com>;tag=ie4hbb8t Call??ID: cdB34qLToC@terminal.example.com CSeq: 322723822 SUBSCRIBE Contact: <sip:terminal.example.com> Event: XDM??History Expires: 0 Accept: application/vnd.oma.history+xml Content??Type: application/ vnd.oma.history+xml Content??Length: ... <History xmlns=="urn:ietf:params:xml:ns:XDMHistory" State="ON" Resource="http://xcap.example.com/address??book/users/ adbook1"> <FilterCond ConID="132" State="ON"> <OppType>ADD</OppType> </FilterCond> </History>

표 5는 히스토리 기능을 설정하기 위한 SIP SUBSCRIBE 요청 포맷을 보여준다. 히스토리 기능을 작동시키기 원하는 사용자는 XDM-히스토리와 같은 이벤트를 갖는 SUBSCRIBE 요청을 전송하고, 히스토리 선호도를 설정하기 위한 application/vnd.oma.history+xml을 포함시킨다. 이와 같이 사용자는, SIP SUBSCRIBE 요청을, 히스토리를 설정하는데 그리고 특정 리소스에서 수행된 동작들에 대한 인스턴트 통지를 획득하기 위하여 히스토리 통지를 설정하는데 이용할 수 있다.

이하에서는 XCAP-Diff를 이용하여 SIP SUBSCRIBE를 이용하는 대안적인 방법에 대하여 설명한다.

본 발명에서 이 부분은 특정 동작들에 대한 인스턴트 통지를 구독할 수 있는 접근을 설명한다. 이 방법은 히스토리 문서 변경을 구독하기 위해 XCAP-Diff 이벤트 패키지를 이용한다. 본 발명은 또한 SUBSCRIBE 요청과 더불어 히스토리 필터링 규칙들을 설정하기 위한 몇 가지 히스토리 필터를 포함하는 것을 제안한다.

아래 표 6은 히스토리 문서 변경을 구독하기 위한 그리고 히스토리 필터링 규칙들을 설정하기 위한 SUBSCRIBE 요청의 예들을 보여준다.

SUBSCRIBE http://xcap.example.com/org.openmobilealliance.poc/historySIP/2.0 Via: SIP/2.0/UDP Max-Forwards: 70 Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>, <sip:orig@scscf1.home1.net;lr> From: <sip:joe.bloggs@example.com>;tag=31415 To: <sip:joe.bloggs@example.com> Event: xcap-diff;path="org.openmobilealliance.groups/users/sip:joe.bloggs@example.com/joebloggs_friends" Call-ID: b89rjhnedlrfjflslj40a222 CSeq: 85 SUBSCRIBE P-Preferred-Identity: "Joe Bloggs" <sip:joe.bloggs@example.com> Privacy: none Expires: 600000 Accept: application/xcap-diff+xml, application/vnd.oma.history+xml Contact: <sip:Joe.bloggs@example.com> Content-type: application/vnd.oma.history+xml Content-Length: … <History xmlns=="urn:ietf:params:xml:ns:XDMHistory" State="ON" Resource="http://xcap.example.com/address-book/users/ adbook1"> <FilterCond ConID="132" State="ON"> <OppType>ADD</OppType> </FilterCond> </History>

위 표 6에 나타난 바와 같이, 이는 특정 리소스에 대한 설정을 위해 XCAP-diff 동작을 이용한다. 그것은 XCAP-diff인 이벤트 패키지를 갖는 SUSBCRIBE 요청을 전송하고, 또한 "application/vnd.oma.history+xml"인 콘텐트-타입의 히스토리 설정을 갖는 바디를 포함한다.

XDM 클라이언트 디바이스(110)가 그의 콘택 리스트에 대한 히스토리를 설정하기 원할 경우에는, 그는 XCAP-diff인 패키지 이름을 갖는 SUBSCRIBE 요청을 전송하고 히스토리 관련 설정을 포함시킨다. 표 6에 나타난 바와 같이, 이 설정에서, 사용자는 히스토리가 활성화될 필요가 있는 리소스를 특정할 것이다.

히스토리 정보를 작동/해제하기 위한 메커니즘에 대한 대안적인 다른 메커지즘들은 SIP MESSAGE를 이용하는 것일 수 있으며, 예를 들어, 상기 히스토리 정보는 시간 주기 및 필터들을 갖는 SIP MESSAGE 요청를 이용하여 작동이나 제어될 수 있다.

도 1은 SIP 기반 통신 애플리케이션을 기본 구성도

도 2는 종래 기술에서의 XCAP 동작의 흐름도

도 3은 XCAP PUT 방법을 이용하는 히스토리 관리에 대한 논리 흐름도

도 4는 논리 스키마 구조(Logical Schema Structure)의 개념도

도 5는 XCAP POST 기반 솔루션에 대한 논리 흐름도

도 6은 SIP SUBSCIRBE 방법을 이용한 논리 흐름도

Claims

XDM(XML Document Management) 서버의 히스토리(History)를 관리하기 위한 시스템에 있어서,

XML(Extensible Markup Language) 문서 및 상기 XML 문서의 히스토리 정보에 대한 필터링 규칙을 전송하는 제1 XDM 클라이언트 디바이스(The First XDM Client Device)와,

상기 XML 문서 및 상기 XML 문서의 필터링 규칙을 수신하여 저장하는 XDM 서버와,

상기 XDM 서버에 저장된 XML 문서를 액세스하는 제2 XDM 클라이언트 디바이스(The Second XDM Client Device)를 포함하고,

상기 XDM 서버가, 상기 제2 클라이언트 디바이스가 상기 XML문서를 액세스하는 경우, 상기 필터링 규칙에 따른 히스토리 정보를 저장함을 특징으로 하는, XDM 서버의 히스토리를 관리하기 위한 시스템.
제1항에 있어서, 상기 필터링 규칙이,

사용 가능 또는 사용 해제가 되도록 설정될 수 있음을 특징으로 하는, XDM 서버를 포함하는 XDM 서버의 히스토리를 관리하기 위한 시스템.
제1항에 있어서, 상기 제2 XDM 클라이언트 디바이스가,

상기 XDM 서버에 저장된 XML 문서를 생성, 업데이트, 변경, 삭제, 검색, 독출 중 어느 하나의 동작에 의해 액세스함을 특징으로 하는, XDM 서버의 히스토리를 관리하기 위한 시스템.
제1항에 있어서, 상기 필터링 규칙이,

XCAP 프로토콜에 따른 이벤트 또는 시간을 기반으로 하는 히스토리 선호도임을 특징으로 하는, XDM 서버의 히스토리를 관리하기 위한 시스템.
제4항에 있어서, 상기 필터링 규칙이,

상기 XDM 서버에 저장되는 히스토리 정보의 저장 기간에 따른 시간 주기(Time Period)를 포함함을 특징으로 하는, XDM 서버의 히스토리를 관리하기 위한 시스템.
제1항에 있어서, 상기 XDM 서버가,

상기 히스토리 정보를 XML 형태의 XML 리소스(XML Resource)로 저장함을 특징으로 하는, XDM 서버의 히스토리를 관리하기 위한 시스템.
제1항에 있어서,

상기 제1 XDM 클라이언트 디바이스 및 상기 제2 XDM 클라이언트 디바이스와, 상기 XDM 서버를 연결하는 통합 프락시(Aggregation Proxy)를 더 포함하는, XDM 서 버의 히스토리를 관리하기 위한 시스템.
제1항에 있어서,

상기 XDM 서버에 저장된 히스토리 정보를 검색 및 독출하기 위한 검색 프락시(Search Proxy)를 더 포함함을 특징으로 하는, XDM 서버의 히스토리를 관리하기 위한 시스템.
XDM(XML Document Management) 서버의 히스토리(History)를 관리하기 위한 방법에 있어서,

제1 XDM 클라이언트 디바이스(The First XDM Client Device)가 XML 문서(XML Document) 및 상기 XML 문서의 히스토리 정보에 대한 필터링 규칙을 전송하는 과정과,

XDM 서버가 상기 XML 문서 및 상기 XML 문서의 필터링 규칙을 수신하여 저장하는 과정과,

제2 XDM 클라이언트 디바이스(The Second XDM Client Device)가 상기 XDM 서버에 저장된 XML 문서를 액세스하는 과정과,

상기 XDM 서버가 상기 XML 문서의 상기 필터링 규칙에 따른 히스토리 정보를 저장하는 과정을 포함하는, XDM 서버의 히스토리를 관리하기 위한 방법.
제9항에 있어서, 상기 필터링 규칙이,

사용 가능 또는 사용 해제가 되도록 설정될 수 있음을 특징으로 하는, XDM 서버를 포함하는 XDM 서버의 히스토리를 관리하기 위한 방법.
제9항에 있어서, 상기 XDM 서버에 저장된 XML 문서를 액세스하는 과정이,

상기 제2 클라이언트 디바이스가 상기 XDM 서버에 저장된 XML 문서를 생성, 업데이트, 변경, 삭제, 검색, 독출 중 어느 하나의 동작에 의해 액세스하는 과정임을 특징으로 하는, XDM 서버의 히스토리를 관리하기 위한 방법.
제9항에 있어서, 상기 필터링 규칙이,

XCAP 프로토콜에 따른 이벤트 또는 시간을 기반으로 하는 히스토리 선호도임을 특징으로 하는, XDM 서버의 히스토리를 관리하기 위한 방법.
제9항에 있어서, 상기 필터링 규칙이,

상기 XDM 서버에 저장되는 히스토리 정보의 저장 기간에 따른 시간 주기(Time Period)를 포함함을 특징으로 하는, XDM 서버의 히스토리를 관리하기 위한 방법.
제9항에 있어서, 상기 필터링 규칙에 따른 히스토리 정보를 저장하는 과정이,

상기 히스토리 정보를 XML 형태의 XML 리소스(XML Resource)로 저장하는 과 정임을 특징으로 하는, XDM 서버의 히스토리를 관리하기 위한 방법.