ＸＤＭ 서버의 히스토리를 관리하기 위한 시스템 및 방법 document_id A220623035343

권한부여 정책(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 히스토리에서는, 사용자가 시간 기반 저장을 설정할 수 없으며, 이는 어느 날의 특정 시간에 문서에 관한 동작을 수행하는 문서 관리자가 없는 경우에 더 중요할 것이다. 따라서 그 시간 동안 그는 위 동작들의 추적을 원할 것이다. 이는 사용자에게 매우 유용할 것이다. 본 발명은 이러한 문제들을 해결하고 종래 기술에서 언급된 제약들을 극복하는 시스템 및 방법을 제공한다.