KR100994139B1

KR100994139B1 - 데이터가 여러 데이터 저장부들에 저장되는 방식을동기화하기 위한 방법 및 장치

Info

Publication number: KR100994139B1
Application number: KR1020047015714A
Authority: KR
Inventors: 피이스파넨주씨; 사히노자미코
Original assignee: 노키아 코포레이션
Priority date: 2002-04-02
Filing date: 2003-03-26
Publication date: 2010-11-15
Also published as: RU2337398C2; US9594821B2; US20030191827A1; US20040225731A1; JP2005521946A; US6721871B2; JP4405812B2; RU2004131856A; WO2003083684A1; KR20040099392A; CN1656468A; CN1656468B; AU2003212573A1; EP1490779A4; EP1490779A1

Abstract

두 장치들(11, 12)이 그 장치들(11, 12)에 의해 관리되는 각자의 데이터 저장부들(11c, 12c) 안에서 데이터 구성 방식을 동기화시키게 하는, SyncML이나 다른 유사한 마크업 랭귀지를 사용하는 방법이 제공되며, 그 방법을 구동시키는 장치들(11, 12) 및, 그 장치들(11, 12)이 그 방법에 따라 동작되도록 상응하는 컴퓨터 프로그램이 제공된다.

본 발명의 방법에 따르면, 두 장치들(11, 12) 그들 각자의 데이터 저장부들(11c, 12c)을 데이터 유닛들을 포함하는 폴더들 및 다른 가능한 폴더들에 대해 동기시키고, 그 동기 동작은, 폴더들에 대해 데이터 저장부들(11c, 12c)을 동기시킬 수 있도록 폴더들을 참조하는 데이터 식별 요소들(28, 29)을 포함하는 메시지들(21)을, 데이터 유닛들에 대한 어떤 참조와도 별개인 메시지에 제공되는 데이터 식별 요소들(28, 29)과 교환함으로써 이뤄진다.

Description

데이터가 여러 데이터 저장부들에 저장되는 방식을 동기화하기 위한 방법 및 장치{Method and apparatus for synchronizing how data is stored in different data stores}

본 발명은, 데스크탑 달력 및 이메일과 같은 하나 이상의 어플리케이션들의 데이터 아이템들(items)을 보유하는 서로 상이한 장치들 상의 데이터 저장부들(stores) 각각이 동기화되는 방법에 관한 것이다. 특히, 본 발명은 그러한 데이터 저장부들의 데이터 구조가 동기화되는 방법에 관한 것이다.

오늘날 실업가(businessperson)는 이메일 어플리케이션 및 달력 어플리케이션을(약속들을 계속 파악하기 위해) 이동 전화기 또는 팜(palm) (휴대용(handheld)) 컴퓨터(또는 어떤 다른 이동 단말기) 상에서 사용할 수 있다. 그리고 보조자(assistant)로 하여금 데스크탑 컴퓨터 상에서 동일한 어플리케이션들을 사용할 수 있게 하여, 실업가 대신에 보조자에 의해 보내지고 수신된 이메일을 계속 파악하게 하고, 실업가를 위해 약속들을 계속 파악하게 할 수 있다. 그와 같은 장치에 있어서, 이메일 어플리케이션을 위한 데이터 아이템들(여기에서 또한 데이터 유닛들이라고도 불리는) 및 달력을 위한 데이터 아이템들은 이동 전화기 상의 데이터 저장부 및 상기 데스크탑 상의 또 다른 데이터 저장부에 보존되는 경우가 흔하 다. 따라서, 이메일 및 달력 어플리케이션 양쪽 모두를 위한 데이터 아이템들을 포함하는 각각의 데이터 저장부들 중 어느 하나에 변화들이 발생되는 경우에는, 당해 데이터 저장부들은 동기화될 것이 요구된다.

서로 상이한 장치 상에서 구동하는 두 개의 어플리케이션들에 의해 사용되는 각각의 데이터 저장부들을 동기화하는(예를 들어, 상기 두 개의 저장부들의 데이터 구조 및 데이터 아이템들 양쪽 모두를 동기화하는) 것에 있어서, 상기 두 개의 데이터 저장부들의 내용들(contents)은, 최종 동기화 이후 발생하는 변화들이 전달되는 방식의 프로토콜에 기반하여, 서로에게 일치하도록 설정되어 있어서, 장치의 양쪽 부분들 상에서 발생되는 변화들 간의 불일치들이(소정의 정책에 따라서) 해결되고, 데이터 저장부들의 양쪽 모두에 존재하거나 그 중 하나에 존재하는 데이터 아이템들 또는 그것들의 구성 또는 양쪽 모두에서 변화들이 발생하게 된다.

설비들은 SyncML(동기화 마크업 언어(synchronization markup language))이라 불리는 것에 기반하여 그와 같은 데이터 저장부들을 동기화하기 위해 개발되고 있으며, 이른바 SyncML 이니셔티브(initiative) 하에 개발되고 있다. (SyncML을 위한 표준들 및 규격들, SyncML 이니셔티브를 포함하고, 특히 SyncML 표시 프로토콜 및 SyncML sync 프로토콜을 포함하는 SyncML에 관한 정보에 대하여는 http://www.syncml.org/ 참조) SyncML은, 원격 데이터(예를 들어, 서로 상이한 장치 및 서로 상이한 데이터 저장부에 저장된 데이터 아이템들)와 다중 네트워크들, 플랫폼들 및 장치들을 오가는 개인 정보의 일반적인 동기화를 위한 공통 언어에 대한 공개 산업 표준에 해당한다. SyncML을 사용하여, 상호 접속되는 하나 이상의 네 트워크들을 통하여 연결된 서로 다른 장치들 상에서 데이터 아이템들은 동기화될 수 있다. 그러나, 데이터 구조는 아직 그렇지 않다. 상기 네트워크들은 예를 들어, 범용 이동 통신 시스템(Universal Mobile Telecommunications System; UMTS), 무선 액세스 네트워크(Radio Acess Network; URTAN) 및 인터넷을 포함하는데, 여기에서 통신은 전체 또는 부분적으로 무선일 수 있고, 또는 유선일 수 있다. 따라서, 상기 장치들은 예를 들어, 고정된 네트워크들(무선 네트워크들을 포함하는), 적외선, 케이블 또는 블루투스를 통하여 통신할 수 있다.

데이터 저장부들을 동기화하는 것 외에, SyncML(예를 들어, 언어)는 장치 관리를 위해 사용될 수 있고, 특히 클라이언트 및 클라이언트를 위한 관리 서버 사이의 관리 작용들을 전달하기 위해 사용될 수 있다. 규격(specification)과, SyncML 장치 관리 프로토콜을 알기 위해서는 http://www.syncml.org를 참조하면 된다. SyncML 장치 관리 프로토콜은 관리 명령들이 관리 대상(object)들 상에서 실행될 수 있도록 하고, SyncML 동기화 프로토콜 및 SyncML 표시 프로토콜에 유사한 패키지 포맷(package format)을 사용한다. 관리 대상은 장치에 대한 일련의 구성 변수들을 반영할 수 있다. 이러한 대상에 반하여 행하여 질 수 있는 작용들로는 변수 키들 및 값들을 읽고 설정하는 것이 포함될 수 있다. 또 다른 관리 대상은 장치 상에서의 소프트웨어 어플리케이션들을 위한 실행 시간(run-time) 환경일 수 있다. 이러한 유형의 대상에 반하여 행해질 수 있는 작용들로는 소프트웨어 요소들을 설치하는 것, 업드레이드(upgrade)하는 것, 또는 프로그램을 삭제하는 것이 포함될 수 있다. 작용들은 SyncML 장치 관리 프로토콜 명령들에 의해 표시되고, 이는 SyncML 표시 프로토콜, 장치 관리 사용법에서 기술된다. 사용된 명령들과 메시지 구조는 SyncML 동기화 프로토콜의 그것과 동일하게 대응한다. (따라서, 이른바 관리 프로토콜을 위한 문서 유형 정의는 SyncML 동기화 프로토콜에 의거하는 문서 유형 정의이다.)

지금까지, 이동 데이터 동기화의 발전은 제한들에 의해 대부분 결정되었다. 데이터 저장부 동기화는 일련의 서로 다른 독점적인 프로토콜들에 기반하여 왔는데, 이들 각각은 매우 제한된 수의 장치들, 시스템들 및 데이터 유형들과만 기능을 수행하였다. 공통으로 이용가능하지 않는 이러한 기술들은 사용자들, 제조자들, 서비스 제공자들 및 개발자들의 업무를 복잡하게 만들어 왔다. 더욱이, 서로 상이하고 독점적인 데이터 저장부 동기화 프로토콜들의 확산은 이동 장치들의 사용의 확장에 장애가 되었고, 데이터 액세스 및 전달을 제한하고 사용자들의 이동성에 한계를 지웠다.

이동 컴퓨팅 및 통신 장치들의 수가 증가함에 따라, 사용자들은 그들이 어디에 있던지 간에 갱신된 정보 및 어플리케이션들에 액세스하기를 원하였고, 이용 가능한 장치라면 무엇이든지 사용하고, SyncML 표준과 같은 공개 표준에 대한 필요를 촉발하였다.

SyncML은 이른바 확장성 생성 언어(Extensible Markup Language; XML)의 구문(syntax)을 사용한다. 이는 웹사이트 http;//www.w3.org를 갖고 있는 월드 와이드 웹 협회(World Wide Web Consortium; W3C) XML 활동(activity)의 저작물인 확장성 생성 언어(XML) 1.0으로 시작되었다. XML에 관한 정보를 위해서는, http;//www.w3.org/XML을 참조하면 된다.

여기에서 사용되었듯이, 데이터 아이템 또는 데이터 유닛이라는 용어는 여기에서 폴더들이라고 불리는 것을 구성하는 데이터에 관한 장치를 나타내는데, 폴더들은 여기에서 디렉토리 구조라 불리는 것과, 또한 여기에서 데이터 구조라고 불리는 것을 차례로 구성한다. 도 4를 참조하여 보면, 디렉토리 구조가 다양한 폴더들을 포함하고 있는 것이 도시되고 있고, 그것들 각각은 하나 이상의 데이터 유닛들을 포함할 수 있다.

디렉토리 구조 또는 데이터 구조라는 용어 및 폴더라는 용어는 넓게 해석될 것이다. 첫째로, 폴더는 데이터 유닛들에 관한 어떠한 컨테이너(container)도 이에 해당할 수 있다고 해석되어야 한다. 따라서, 예를 들어 다양한 운영 체계(operating system)(이를 테면 마이크로소프트사에 의해 이용 가능한 윈도우즈와 같은)에서 폴더라고 불리는 것은 여기에서 사용되는 폴더라는 용어로 해석될 것이다. 그러나 관계 데이터베이스의 테이블에 있는 레코드 역시 그러한데, 왜냐하면 그와 같은 테이블에 있는 레코드는 데이터 유닛들에 해당하는 필드(field)들을 포함하기 때문이다. 필드는 문자들, 숫자들, 또는 데이터 유닛들이라고 간주될 수 있는 다른 요소들을 포함하고 있으므로, 그와 같은 필드조차도 폴더라고 간주될 수 있다. 따라서 각각의 필드는 폴더이다.

디렉토리 구조 또는 데이터 구조라는 용어는 데이터 저장부에 있는 폴더들의 배열을 나타내는데, 이를 테면 예를 들어 운영 체계에 의해 유지되는 디렉토리 내에 있는 폴더들의 트리 구조와 같은 것이 이에 해당하고, 그와 같은 경우에는 파일 들(files)이 데이터 유닛들에 해당할 것이다. 그러나 디렉토리 구조 또는 데이터 구조라는 용어는, 예를 들어 운영 체계에 의해 유지되는 것은 아니지만 대신에 운용 체계 하에서 구동하는 어플리케이션에 의해 유지되는 것과 같이, 어플리케이션들에 의해 내부적으로 유지되는 디렉토리 구조들을 포함하는 것으로도 해석되어야 한다. 대부분 이메일 어플리케이션들에 의해 유지되는 디렉토리 구조가 한 예인데, 이는 일반적으로 항상 적어도 두 개의 폴더들: 수신된 이메일(박스에 있는(in-box)) 폴더 및 송신된 이메일(보내진) 폴더를 포함한다. 게다가, 디렉토리 구조 또는 데이터 구조라는 용어는 내부 디렉토리 구조들을 포함하는 것으로도 해석되어야 하는데, 이러한 내부 디렉토리 구조들은 여러 가지 어플리케이션들에 의해(디렉토리 구조는 단지 하나의 어플리케이션에만이 아니라, 일반적으로 잘 인터페이스 접속된 여러 개의 어플리케이션들에 내부적으로 연결되어 있고, 그들 중 어느 것도 디렉토리 구조에 변화들을 만들 수 있도록) 공유된다. 나아가, 디렉토리 구조 또는 데이터 구조라는 용어는 시스템 디렉토리 구조들 및 내부 디렉토리 구조들 양자 모두를 포함하는 것으로도 해석되어야 할 것이다. 이메일 어플리케이션에 의해 유지되는 내부 디렉토리의 경우에는, 데이터 유닛이 이메일, 일종의 내부 파일일 것이다. 둘 중 어느 한 유형의 디렉토리 구조에 있어서, 일반적으로 폴더는 서로 상이한 어플리케이션들에 속하는 데이터 유닛들을 포함할 수 있고, 어플리케이션은 데이터 유닛이 그것에 속하는 것인지 또 다른 어플리케이션에 속하는 것인지를 구별하는데, 이는 데이터 유닛과 관련하여 유지되는 일정한 특성에 기반하여 구별하거나, 또는 그것에 속하는 모든 데이터 유닛들의 비공개 테이블을, 당해 모든 데이터 유닛들이 어디에 위치하고 있을지라도, 보호하는 어플리케이션에 기반하여 구별한다. 또한, 이미 설명한 바와 같이, 폴더는 예를 들어 데이터베이스의 테이블 내에 있는 레코드 또는 그러한 레코드 내에 있는 필드까지도 나타내는 것일 수 있기 때문에, 디렉토리 구조 또는 데이터 구조라는 용어는 데이터베이스 구조(폴더가 레코드인 경우) 또는 레코드 구조(폴더가 필드인 경우)까지도 포함하는 것으로도 해석되어야 한다. 따라서, 폴더라는 용어가 개방적으로(expansively) 사용되어 데이터 유닛들의 어떠한 컨테이너도 나타낸다는 것을 이해하는 것이 중요하다. 그리고 디렉토리 구조 또는 데이터 구조라는 용어는 서로 대응하여 개방적인 의미를 가진다.

어플리케이션의 사용자는 어플리케이션에 속하는 데이터 유닛들을(사용자는 어플리케이션을 사용하여 데이터 유닛의 컨텐츠들을 변경하기 때문에, 새로운 데이터 유닛을 부가하거나 갱신된 버전으로 데이터 유닛을 대체하는 것과 같이) 변경할 수 있고, 또한 어플리케이션의 사용자는 데이터 아이템들이 어떻게 저장되어 있는지에 대해서도(새로운 폴더를 부가하거나 이미 존재하는 폴더로부터 새로운 폴더로 일정한 데이터 유닛들을 이동하는 것과 같이) 변경할 수 있다. 이는 예를 들어 폴더들(예를 들어, 전체적인 디렉토리 구조)에 대해서 뿐만 아니라 데이터 유닛들에 대해서도 변경할 수 있는 것을 말한다. 그러나, SyncML에 대한 종래 기술에 따르면, 만일 사용자가 장치상의 폴더들을 변경한다면 SyncML는 상기 장치 상의 데이터 저장부를, 또 다른 장치 상에서 유지되며 대응하는 데이터 저장부와 동기화하는데 사용할 수 없다; SyncML에 관한 종래 기술은 데이터 유닛들에서의 변화들과 관련한 동기화만을 가능하게 할 뿐이다.

SyncML 메시지는 내포(nested) 구조이다. 그래서, 하나 이상의 SyncML 메시지들은 SyncML 패키지라고 불리는 것과 관련될 수 있다. 상기 SyncML 메시지는 개별적인 XML 문서이고 이러한 문서는 하나 이상의 요소 유형들을 갖는 하나 이상의 요소들 각각으로 구성된다. 당해 문서는 SyncHdr 요소 유형에 의해 특정된 헤더(header) 및 SyncBody 요소 유형에 의해 특정된 바디(body)로 구성된다. 상기 SyncML 헤더는 SyncML 메시지에 관한 루팅(routing) 및 버전 정보를 특정한다. 상기 SyncML 바디는 하나 이상의 SyncML 명령들을 위한 컨테이너이다. 상기 SyncML 명령들은 개별적인 요소 유형들에 의해 특정된다. 상기 SyncML 명령들은, 어떤 데이터 또는 메타 정보(meta-information)를 포함하고, 상기 SyncML 명령의 세부 내용들을 기술하는 다른 요소 유형들에 대한 컨테이너들로서 작용한다.

SyncML은 명령 요구(request commands)와 명령 응답(reponse commands)을 정의한다. 명령 요구는 예를 들어 다음과 같은 것들을 포함할 수 있다: 추가(발신자로 하여금 수신자에게 액세스 가능한 데이터에 하나 이상의 데이터 유닛들이 추가될 것을 요청할 수 있게 하는 명령); 경보(발신자가 수신자에게 상황을 알릴 수 있게 하는 명령); 복사(발신자로 하여금 수신자에게 액세스 가능한 하나 이상의 데이터 유닛들이 복사될 것을 요청할 수 있게 하는 명령); 삭제(발신자로 하여금 수신자에게 액세스 가능한 하나 이상의 데이터 유닛들이 삭제되거나 보존될(archived) 것을 요청할 수 있게 하는 명령); 읽기(get)(발신자가 수신자로부터 하나 이상의 데이터 유닛들을 요청할 수 있게 하는 명령); 및 탐색(발신자로 하여금 제공된 질문(supplied query)이 수신자에게 액세스 가능한 하나 이상의 데이터 유닛들에 반 하여 실행되도록 요청할 수 있게 하는 명령). 오직 응답 명령만이 현재적이다(currently): 상태(동작의 종료 상태를 나타내거나 또는 이전의 요구를 처리하는 과정 동안 에러가 발생했다는 것을 나타내는 명령); 결과들(SyncML 명령 탐색 또는 읽기의 데이터 결과들을 회신(return)하는데 사용되는 명령).

SyncML은 데이터 유닛들 또는 폴더들을 식별하기 위해 식별자들을 사용한다. 상기 식별자들은 소스(Source) 및 타겟(Target) 요소 유형들이라 불리는 것에 포함되고, 유니폼 리소스 식별자들(Uniform Resource identifiers; URIs) 유니폼 리소스 명칭들(Uniform Resource Names; URNs) 및 원문 명칭들의 조합일 수 있다.

(국제 이동 장비 식별자(International Mobile Equipment Identifier; IMEI)를 나타내기 위하여, SyncML은 IMEI URN 유형을 사용한다. 상기 IMEI URN은 유효한 15 숫자(digit) IMEI를 특정한다. 게다가, SyncML은 SyncML URN 유형을 사용하여 SyncML 특정 명칭 공간들(specific name spaces) 및 고유 명칭들(unique names)을 식별한다. 또한 다른 URN 유형들은 LocURI 요소 유형에서 사용될 것이다.)

이미 언급된 바와 같이, SyncML 표시 프로토콜(예를 들어 SyncML 메시지)은 XML 요소 유형들을 구성하는 문서 마크업이다. 상기 요소 유형들은 그들의 목적 또는 사용법, 뿌리(parent) 요소들, 컨텐츠 상의 어떤 제한들 또는 사용 및 컨텐츠 모델의 관점에서 정의된다. 상기 요소 유형들은 이른바 공통 사용(common use) 요소들, 메시지 컨테이너 요소들, 데이터 기술(description) 요소들, 프로토콜 관리 요소들, 및 프로토콜 명령 요소들을 포함한다.

공통 사용 요소 유형들은 다른 SyncML 요소 유형들에 의해 사용된 요소 유형 들이고, 예를 들어, 삭제 명령으로 특정된 데이터가 단순히 삭제하는 것이 아니라 삭제 명령의 수신자에 의해 보존되어야 하는 것을 나타내기 위한 보존(archive)을 포함한다. 따라서 상기 삭제 명령은 보존 공통 사용 요소를 사용할 수 있고, 본 문장의 문맥에 있어서 상기 보존 공통 사용 요소 유형의 뿌리 요소로서 참조된다. 또 다른 공통 사용 요소 유형은 Cmd 요소 유형인데, 이는 상태 요소 유형에 의해 참고된 SyncML 명령을 특정하는데 사용된다(그래서 상기 상태 요소 유형은 본 문장의 문맥에서 뿌리 요소이다). 또 다른 것은 CmdID 요소 유형인데, 이는 SyncML 메시지-고유 명령 식별자를 특정하는데 사용되고, 다양한 뿌리 요소들을 가질 수 있다. 이러한 뿌리 요소들로는 추가(Add), 경보(Alert), 원자(Atomic), 복사(Copy), 삭제(Delete), 실행(Exec), 읽기(Get), 맵(Map), 출력(Put), 교체(Replace), 결과들(Results), 탐색(Search), 시퀀스(Sequence), 상태(Status), 및 싱크(Sync)들이 포함된다.

공통 요소 유형들 LocName, LocURI, 소스, 및 타겟은 본 발명의 관점에서 특별히 주목된다. LocName은 타겟 또는 소스 주소를 위한 디스플레이 명칭을 특정하는데 사용되고, 그래서 뿌리 요소들로서 타겟 또는 소스를 가질 수 있다. LocURI는 상기 타겟 또는 소스 특정 주소를 특정하고, 또한 뿌리 요소들로서 타겟 또는 소스를 가질 수 있다. 공통 요소 유형 소스는 소스 루팅 또는 맵핑 정보를 특정하기 위해 사용되는데, 그것의 뿌리 요소들은 아이템, 맵, 맵아이템, 탐색, 싱크, 및 SyndHdr를 포함한다. 타겟은 타겟 루팅 또는 맵핑 정보를 특정하기 위해 사용되는데, 그것의 뿌리 요소들은 아이템, 맵, 맵아이템, 탐색, 싱크, 및 SyndHdr를 포함 한다.

메시지 컨테이너 요소 유형들은 SyncML 메시지들을 위한 기본적 컨테이너 지원(support)을 제공한다. 그와 같은 요소 유형들 셋은: SyncML, 이는 SyncML 메시지를 위한 컨테이너를 특정하기 위한 것이고, 뿌리 또는 문서 요소로 불리기 때문에 뿌리들이 없다; SyncHdr, 이는 SyncML 메시지에 있는 개정 정보 또는 루팅 정보(또는 양자 모두)를 위한 컨테이너를 특정하기 위한 것이고, SyncML 요소를 뿌리 요소로 가진다; SyncBody, 이는 SyncML 메시지의 바디 또는 컨텐츠들을 위한 컨테이너를 특정하기 위한 것이고, 또한 SyncML 요소를 뿌리 요소로서 가진다.

데이터 기술 요소들은 SyncML 메시지에서 교환된 데이터를 위한 컨테이너 요소들로서 사용된다; 데이터 기술 요소들은 다음의 요소 유형들을 포함한다: 데이터, 이는 불연속적인 SyncML 데이터를 특정하기 위한 것이고, (뿌리 요소들) 경보, 크레드(cred), 아이템, 상태, 및 탐색 요소 유형들에 의해 사용된다; 아이템, 이는 아이템 데이터를 위한 컨테이너를 특정하기 위한 것이고, (뿌리 요소들)추가, 경보, 복사, 삭제, 실행, 읽기, 출력, 교체, 결과들, 및 상태에 의해 사용된다; 및 메타, 이는 뿌리 요소 유형에 관한 메타 정보를 특정하기 위한 것이고, (뿌리 요소들) 추가, 원자, 칼(chal), 복사, 크레드, 삭제, 읽기, 아이템, 맵, 출력, 교체, 결과들, 탐색, 시퀀스, 및 싱크에 의해 사용된다.

요즘에, 프로토콜 관리 요소들은 단지 요소 유형 상태만을 포함하는데, 이는 지시된 SyncML 명령을 위한 요구 상태 코드를 특정하기 위한 것이고, (뿌리 요소) SyncBody에 의해 사용된다.

마지막으로, 프로토콜 명령 요소들이 있다. 이들은 이미 언급된 명령 요소들을 포함하는데, 예를 들어: 추가, 이는 데이터 모음(collection)에 데이터를 추가하는 것을 특정하기 위한 것이고, (뿌리 요소들) 원자, 시퀀스, 싱크, SyncBody에 의해 사용되고; 삭제; 교체; 등등이 있다.

상기의 요소 유형들 모두는 다음의 인터넷 주소; http://www.syncml.org/docs/syncml_represent_vll_200215.pdf에서 입수할 수 있는 표준, SyncML 표시 프로토콜에서 설명되었다.

만일 동기화된 프로토콜에 따라 데이터 및 통신을 조절하는 것을 동일한 어플리케이션이 처리한다면, 디렉토리 구조에서의 변화들을 통신하는 것은 문제가 되지 않는다. 그러나 보다 일반적인 문제점의 경우에 있어서, 각각의 장치 상에서 여러 어플리케이션들은 디렉토리 구조로서 구성된 데이터 저장부를 공유하고, 디렉토리 구조의 하나 이상의 폴더들에 그것들의 각각의 데이터 유닛들을 저장하고 있어서, 데이터 유닛들 뿐만 아니라 폴더들 역시 동기화 하기 위해서 어떻게 최선의 배열을 할 것인지, 예를 들어 그와 같은 것을 수행하기 위한 동기화 프로토콜을 어떻게 구성할 것인지 등이 명백하지 않다. SyncML 이니셔티브의 저작물로서 공개 표준인 SyncML 동기화 프로토콜에 따르면, 동기화될(어떤 관점에서도) 각각의 데이터 저장부들을 가지는 두 개의 원격 장치들 각각은 동기화(sync) 에이전트(장치 당 하나, 그래서 많은 여러 어플리케이션들에 서비스 제공이 가능한) 및 하나 이상의 어플리케이션 존재들을 포함한다. 그리고, 동기화 프로토콜에 따르는 것(예를 들어 표준에서 설명된 동기화 프로토콜에 따라 통신을 수행하는 것)은 어플리케이션들의 책임이 아니라, 동기화 에이전트들의 책임인 것이다. (오직 동기화 에이전트만이 SyncML을 해석할 수 있고, 어플리케이션들은 그렇지 않다.) 그러나 가장 최근에 이미 수행된 동기화 이후로 데이터 유닛이 변화했는지에 대해서는 오직 어플리케이션들만이 알 수 있다. 어떻게 SyncML 동기화 프로토콜을 확장할 수 있는지에 대해서는, 어플리케이션들 각각에, 동기화 에이전트에서 부호화되는 것과 같은, SyncML에 관한 지식이 포함되는 것을 요구하는 일정한 선택사항들이 존재하고, 동기화 에이전트가 여러 어플리케이션들이 행하는 방식으로 데이터 유닛들을 해석할 수 있을 것을 요구하는 일정한 선택사항들이 존재한다.

동기화 에이전트 및 어플리케이션 상에서의 요구들을 최소화하는 방식으로,디렉토리 구조에 있는 폴더들과 같은 데이터 조직의 측면들을 나타내기 위해서 SyncML(또는 어떤 유사한 동기화 언어)에 대한 일정한 방침이 필요하고, 그렇게 함으로써 코드 또는 폴더 정보를 복제해야 하는 것을 피할 수 있게 된다.

본 발명의 제1양상에 있어서, 제1데이터 저장부와 관련해 동작하는 제1동기 에이전트 및 제2데이터 저장부와 관련해 동작하는 제2동기 에이전트에 의해 이용되는 방법이 제공되며, 그 방법에 의해 제1데이터 저장부는 제2데이터 저장부와 동기되고, 상기 데이터 저장부들 각각이 제1 및 제2 동기 에이전트들과 별개인 각자의 제1 및 제2어플리케이션에 의해 폴더들 안에 데이터 유닛들로 데이터를 저장하는 것이고, 상기 폴더들은 합해져서 하나의 데이터 구조를 규정할 때, 상기 방법은, 제1 및 제2 동기 에이전트들이 제1 및 제2동기 에이전트들 사이에서 통신을 가능하 게 하는 전송 접속을 설정하는 단계; 및 제2동기 에이전트가 상기 통신 접속을 통해 제1동기 에이전트로, 마크업(markup) 랭귀지를 사용하고 적어도 하나의 데이터 식별 요소(여기서 데이터 식별 요소라는 용어는 SyncML에서 타겟 요소라고 불리는 것과 SyncML에서 소스 요소라 불리는 것을 나타내기 위해 사용되지만, SyncML과 유사한 어떤 마크업 랭귀지로 된 비슷한 요소들을 포함하는 것이라고 이해될 수 있을 것이며, 따라서 데이터 식별 요소라는 용어는, 데이터 유닛을 포함하는 SyncML 또는 유사 랭귀지로 쓰여진 한 요소를 의미하는 데이터 요소라는 용어와는 대조 구별된다)을 포함하여 표현된 메시지를 전송하는 단계를 포함하고, 상기 제1 또는 제2데이터 저장부의 데이터 구조의 변화에 대한 정보가 상기 메시지에 포함되어 전송되고, 상기 제1 또는 제2데이터 저장부의 데이터 구조의 변화에 대한 상기 정보는 적어도 한 데이터 식별 요소 안에 놓여진다.

본 발명의 제1양상에 따르면, 상기 적어도 하나의 데이터 식별 요소는 데이터 요소 (즉, SyncML 마크업 랭귀지의 특정 유형의 데이터 서술 요소 또는 유사한 마크업 랭귀지의 유사 요소)와는 별개인 것, 즉 그 데이터 요소에 포함되지 않을 수 있다. 또, 본 발명의 제1양상에 따르면, 제1 또는 제2데이터 저장부의 데이터 구조의 변화에 대한 상기 정보는 폴더 아이디(ID)를 포함할 수 있다. 또, 적어도 하나의 데이터 식별 요소는 타겟 요소 또는 소스 요소일 수 있다. 역시 또, 데이터 식별자 요소는 프로토콜 명령 요소에 포함될 수 있고, 프로토콜 명령 요소는 데이터 식별 성분와 결합되어 제1 또는 제2데이터 저장부의 데이터 구조의 변화에 대한 정보를 나타낼 수 있다. 또한, 데이터 식별 요소는 제2동기 에이전트에 의해 할당된 (마크업 랭귀지 SyncML로 된) LocURI라 불리는 요소 (또는 유사 마크업 랭귀지로 된 유사 요소)를 포함할 수 있고, 제1 또는 제2데이터 저장부의 데이터 구조의 변화에 대한 상기 정보는 그 LocURI 요소 안에 포함되어 제공될 수 있다.

역시 본 발명의 제1양상에 따르면, 제1장치가 제1동기 에이전트와 함께 제1데이터 저장부 및 제1어플리케이션을 호스트(host)하고, 제2장치가 제2동기 에이전트 및 제2데이터 저장부와 제2어플리케이션까지 호스트한다. 또, 제1장치는 클라이언트/서버 프로토콜의 클라이언트로서 기능하고, 제2장치는 그 클라이언트/서버 프로토콜의 서버로서 기능하며, 상기 클라이언트에 의해 상기 서버로 메시지가 제공된다. 또한, 제1장치가 클라이언트/서버 프로토콜의 서버로서 기능하고, 메시지는 상기 서버에 의해 상기 클라이언트로 제공될 것이며, 메시지를 전송하는 단계는 클라이언트 메시지에 응답하여 상기 서버가 호스트하는 데이터 저장부에 대해 클라이언트 메시지에 의해 야기된 어떤 충돌의 문제를 해결하는 단계를 포함할 수 있다.

또, 본 발명의 제1양상에 따르면, 제1어플리케이션은 메시지 안에 포함된 어느 데이터 요소에라도 응답하며, 제1동기 에이전트는 데이터 식별 요소에 응답하여, 제1어플리케이션이 메시지에 포함된 어떤 데이터 요소들에 의해 운반된 정보에 기반해 데이터 저장부의 데이터 유닛들에 대해 어떤 변화를 만들기 전에 데이터 식별 정보에 의해 운반된 정보에 기반해 제1데이터 저장부의 데이터 구조를 변화시킬 수 있다. 또한 제2싱크 에이전트는 데이터 식별 요소 안에 제1 또는 제2데이터 저장부의 데이터 구조의 변화에 대한 정보를 제공할 수 있고, 제2어플리케이션은 데 이터 요소 안에 제1 또는 제2데이터 저장부의 데이터 유닛들의 변화에 대한 정보 를 제공할 수 있다. 또, 상기 메시지에 반응하는 제1 동기 에이전트는 데이터 식별 요소로부터 데이터 구조 변화에 대한 정보를 추출하여 그 정보를 동기 엔진이나 어플리케이션 개체로 제공할 수 있다.

본 발명의 제2양상에 따르면, 상기 제1장치의 동작 및 제2장치의 동작에 대한 본 발명의 제1양상에 따라 동작되는 장치가 제공된다. 본 발명의 제2양상에 따르면, 상기 장치는 무선 통신 단말기일 수 있다. 또, 상기 장치는 유선 통신 단말기일 수도 있다. 또, 상기 장치는 클라이언트 서버 모델의 서버로서 기능할 수 있고, 상기 메시지에 의해 야기된 충돌을 해결하기 위한 싱크 엔진을 포함할 수 있다.

본 발명의 제3양상에 따르면, 본 발명의 제2양상에서와 같은 제1장치 및 제2장치를 구비하는 시스템이 제공되며, 상기 제1장치는 클라이언트 서버 모델에서 서버로서 기능하고 메시지에 의해 야기된 충돌을 해결하기 위한 동기 엔진을 포함하며, 상기 제2장치는 클라이언트 서버 모델에서 클라이언트로서 기능한다.

본 발명의 제4양상에 따르면, 통신장치(11, 12)를 위한 동작 명령어들을 나타내는 컴퓨터 프로그램이 제공되어, 통신 장치(11, 12)가 제1장치 및 제2장치에 대한 본 발명의 제1양상에 따라 동작되도록 한다.

본 발명의 제5양상에 따르면, 동기 에이전트에 대한 동작 명령어들을 나타내는 컴퓨터 프로그램이 제공되어, 상기 동기 에이전트가 제1동기 에이전트 및 제2동기 에이전트에 대한 본 발명의 제1양상에 따라 동작되도록 한다.

따라서, 본 발명은 사용자 데이터나 장치 관리와 관련해 어플리케이션들에 의해 사용될 수 있는 폴더들, 데이터 저장부들의 변화에 대해 데이터 저장부들을 동기시키는 방법을 제공하도록 SyncML을 확장하며; 폴더들에서의 변화와 데이터 저장부의 데이터 유닛들의 변화 모두 다른 데이터 저장부 안에서 반영될 수 있다.

본 발명은 장치 상의 각 어플리케이션이 SyncML을 이해하기 위해 부호화될 필요가 없이, 다만 그 장치의 동기 에이전트 및, 서버 상의 동기 에이전트와 인터페이스한다는 장점을 가진다. 또, 본 발명은 각 장치 상의 동기 에이전트에, 다른 장치의 상응하는 데이터 저장부와 동기되는 데이터 저장부를 공유하는 다른 어플리케이션들에 대해 데이터 유닛들을 해석하는 방법에 대한 어떤 지식도 포함할 필요를 없앤다.

본 발명의 상기 목적 및 다른 목적, 특징 및 이점은 이하의 도면에 나타난 상세한 설명으로부터 명백해질 것이다.

도 1은 본 발명에 따른 개별 데이터 저장부를 동기화하기 위한 SyncML 메시지를 교환하는 (이동 전화와 같은) 클라이언트와 (네트워크 서버 또는 PC와 같은) 서버의 블록도/흐름도이다.

도 2는 본 발명에 따른 SyncML 메시지의 개략도이다.

도 3은 본 발명에 따라 구성된 메시지를 사용하여 동기화 동안에 클라이언트와 서버의 구성요소간의 상호작용을 위한 장치를 도시하는 흐름도이다.

도 4는 종래 기술에 따른 디렉토리 구조의 개략도이다.

도 1을 참조하여, 클라이언트 데이터 저장부(11c)와 상응하는 서버(12)의 서버데이터 저장부(12c)를 동기화하는 클라이언트(11)가 도시된다. (데이터 저장부는 예를 들면, 이-메일과 같은 장치 관리 또는 사용자 데이터 보유를 위하여 사용될 수 있다.) 데이터 저장부는 도 4에 도시된 바와 같이 표현될 수 있는 임의의 디렉토리 구조를 사용하여, 하나의(또는 그 이상의) 시스템 디렉토리 구조 및 하나 이상의 내부 디렉토리 구조(즉, 운영 시스템과 대비되는 하나 이상의 어플리케이션에 의해서 유지되는 내부 디렉토리 구조)를 포함할 수 있으며, 그 결과 디렉토리 구조는 폴더의 트리 구조, (파일 즉, 시스템 디렉토리 구조 내에서 보존된 데이터의 유닛 또는 이-메일 어플리케이션에 의해서 보존된 이-메일과 같은 내부 디렉토리내의 어플리케이션에 의해서 보존된 유닛이나 데이터와 같은) 하나 이상의 데이터 유닛을 포함할 수 있는 각각의 폴더 및 트리 구조의 하나 이상의 다른 폴더가 된다. 임의의 유사하게 구조화된 또는 아날로그 언어에 따른 메시지가 사용될 수 있더라도, 동기화는 SyncML 메시지의 교환을 통하여 발생한다. 교환되는 일부 SyncML 메시지는 데이터 저장부(11c, 12c)를 데이터 유닛에 대하여 동기화하기 위한 명령 및 데이터 저장부의 데이터 구조에 대한 동기화를 위한 명령을 포함하며, 즉, 데이터 저장부가 폴더에 관하여 등가의 구조를 가지도록, 적어도 어플리케이션이 관계되는 한, 동기화가 수행된다. 클라이언트(11)는 클라이언트/서버 모델 내에서 클라이언트의 역할을 수행하는 임의의 장치이며, 그리고 SyncML 프로토콜에 따라, (통상적으로 랩탑 또는 휴대 전화 또는 다른 무선 단말기와 같은) 클라이언트는 그것의 데 이터 저장부(11c)내의 모든 변화를 클라이언트/서버 모델 내에서 서버의 역할을 갖는 (통상적으로 예를 들면, 데스크탑 컴퓨터와 같은) 장치인 서버(12)로 전송한다. (개별적인 데이터 저장부를 동기화하는 2개의 장치중, 더 큰 계산 용량을 갖는 장치가 통상적으로 서버의 역할을 할 것이다.)

클라이언트(11)와 서버(12)는 하나 이상의 개별적인 어플리케이션 개체(11a, 12a)를 포함하며, 그리고 클라이언트와 서버는 (일반적으로, 즉 특정 어플리케이션에 특정되지 않은 경우에는) 개별적인 동기 에이전트(11b, 12b)도 포함한다. 서버 어플리케이션 개체(12a)는 그것이 서버 동기 에이전트와 인터페이스로 접속하는 것뿐만 아니라 클라이언트(11)내에서 대응부(counterpart)를 갖지 않는 서버 동기 엔진(12f)과 인터페이스로 접속을 한다는 점에서 클라이언트 어플리케이션 개체(11a)와 상이하다. 유사하게, 서버 동기 에이전트(12c)는 서버 동기 엔진(12f)과도 인터페이스 접속을 한다는 점에서 클라이언트 동기 에이전트(12c)와 상이하다. 클라이언트/서버 어플리케이션 개체(11a, 12a)는 예를 들면, 판매자를 위한 약속을 지키기 위해 사용된 달력 어플리케이션이다. 만약, 예약이 클라이언트 장치(11)에 되어 있다면, 그러면 예약 정보는 새로운 파일로서 클라이언트 데이터 저장부(11c)내에 저장된다. 이후에, 클라이언트(11)의 요청 또는 서버(12)의 프롬프트에서, 데이터 저장부(12c)는 새로운 데이터(즉, 새로운 파일)에 대한 클라이언트 데이터 저장부(11c)와 동기화된다. 또한, 클라이언트 데이터 저장부(11c)상의 디렉토리 구조에 변화가 생긴다면, 클라이언트 데이터 저장부(11c)및 서버 데이터 저장부(12c)은 이러한 경우에, 디렉토리 구조에 대하여 즉, 어플리케이션을 위하여 데이터 유닛을 보존하기 위해 사용된 폴더에 대하여 동기화되어야 한다. 또한, 어플리케이션(11a, 12a)을 위한 폴더나 데이터 유닛에 대한 변화를 포함하여, 서버 데이터 저장부(12c)에 발생한 임의의 변화는 SyncML 메시지의 교환에 의해 클라이언트 데이터 저장부(11c)와 서버 데이터 저장부(12c)의 동기화를 요구할 것이다.

계속 도 1을 참조하여, SyncML 메시지는 예를 들면, 하이퍼텍스트 전송 프로토콜(HTTP), 유선 세션 프로토콜(WSP; Wireline Session Protocol) 및 객체 교환 프로토콜(OBEX; Object Exchange Protocol)을 포함하는 다양한 전송 접속(14)에 따라 통신될 수 있다. (전송 접속은 무선 접속 또는 유선 접속을 포함하는 임의의 종류의 물리적 계층 접속을 사용하여 제공될 수 있다.) 도시된 바와 같이, 서버(12)가 SyncML 메시지를 클라이언트(11)와 통신할 때(및 그 반대로 통신할 때), 서버 동기 에이전트(12b)는 메시지를 서버 동기 어댑터(12e)에 제공하고, SyncML 메시지를 전송 접속(14)을 통하여 클라이언트(11)로 제공하기 위하여, 동기 인터페이스(I/F)(12d)를 사용한다. 수신단에서, 클라이언트 동기 어댑터(11e)는 SyncML 메시지를 수신하고, 상기 SyncML 메시지를 클라이언트 동기 I/F(11d)로 통과시키며, 이어서 클라이언트 동기 에이전트(11b)로 제공한다.

이제, 폴더와 데이터 유닛 내에서의 변화에 대한 데이터 저장부(11c, 12c)의 동기화를 제공하기 위하여(그 결과, 동일한 데이터 유닛이 개별 장치 상의 동일한 또는 등가의 폴더내에 있으며, 그리고 각각의 상응하는 데이터 유닛의 내용이 동일하도록), 본 발명은 데이터 유닛을 변화시키기 위하여 사용되는 폴더를 변화시키기 위한 동일한 명령을 사용하는 SyncML를 가지며; 그러므로 폴더에 대한 변화는 동 기, 부가, 대체 및 삭제와 같은 운영 구성요소(프로토콜 명령 구성요소)를 전달하는 메시지를 송신(issue)함으로써 행해지며, 관계된 폴더는 데이터 요소 외부의 타겟 또는 소스 요소를 의미하는 이하에서 데이터 식별 요소라 불리는 것 내에서 참조된다. 데이터 유닛에 대한 변화를 생성하기 위하여, 종래 기술에 따른 SyncML는 운영 요소 내에서 내포된 데이터 요소내의 데이터 유닛을 참조하는 메시지를 호출한다. 데이터 요소(즉, 데이터 설명 요소) 외부의 관계된 폴더에 대한 참조를 사용하는 것은 관계된 폴더를 참조하기 위한 다른 가능한 장치들에 대하여 본 발명의 이점(즉, 개별적인 어플리케이션에 의해 SyncML 파싱(parsing)을 가능하게 하는 코드를 복사하지 않고, 각각의 상이한 어플리케이션의 데이터 유닛을 해석하기 위한 각각의 동기 에이전트 코드 내에서 포함하지 않는)을 제공한다.

이제 도 2를 참조하여, 본 발명에 따르면, 데이터 저장부(11c, 12c)를 동기화하는 과정에 관계된 폴더(및 디렉토리에 관한 데이터 구성)는 소스 요소(26)의 LocURI 요소(26a, 27a)와 데이터 요소(28, 29)(즉, 데이터 설명 요소의 특별한 유형) 외부의 (리플레이스와 같은) 프로토콜 명령 요소(25)의 타겟(Target) 요소(27)내에서 확인 또는 표시된다. 타겟과 소스 요소 양자는 데이터 유닛을 포함하는 데이터 요소(28, 29)와 대비하기 위하여 여기서는 데이터 식별 요소(Data Identification Elements)로 불려진다. 본 발명에 따른 데이터 식별 요소는 차례로 프로토콜 명령 요소(24)내에 내장되는 (아이템 요소와 같은) 비데이터(non-data) 요소 콘테이너내에 내장된다. 프로토콜 명령 요소(24)는 SyncML 콘테이너 요소 즉, SyncML 메시지(21)내에 포함된 SyncHdr 콘테이너와 SyncBody 콘테이너 요소(23)의 일부로서 전달된다.

데이터 유닛과 폴더 양자에 변화가 행해질 때, 폴더는 우선 동기화되어야 하며, 그리고 우선 폴더 변화가 행해지고, 그리고 나서 데이터 유닛이 변화하도록, 메시지는 공식화된다. (데이터 유닛 또는 폴더에 대한) 각각의 변화는 운영 요소를 통하여 달성된다. 폴더에 대한 변화는 데이터 유닛에 대한 임의의 변화 전에 올 수 있도록 조정되어야 한다.

그러므로, 본 발명에 따르면, 메시지 내의 폴더 변화가 전송될 때, 예를 들면, 새로운 폴더를 클라이언트에 부가할 때, 운영 요소 "부가(add)"의 데이터 요소(즉, 데이터 설명 요소의 특별한 유형)가 비어 있는(empty) 상태로 남겨지거나, 그러한 ("부가(add)") 요소는 메시지 내에 표시되지 않으며, 그리고 폴더 정보(폴더의 ID 및 전체 경로(full path)는 임의의 데이터 요소 외부의 데이터 식별 요소(소스 요소 또는 타겟 요소)내에서 전달된다.

이하의 SyncML 메시지 단편(fragment)은 리플레이스 명령 내에서, 식별자(7)를 갖지며 식별자(1)를 갖는 폴더내에 위치된 폴더를 어떻게 어드레스하는지를 보여준다.

</Replace>

(상기 폴더 자체와 대비되는) 폴더 내에 데이터 유닛을 어드레싱할 때, 폴더의 식별자 및 (트리 구조의 경우에) 디렉토리 구조의 루트(root)에 관한 폴더의 경로는 운영 요소 즉, (대체 또는 삭제와 같은) 프로토콜 명령 요소의 타겟 및 소스 공통 요소 유형의 LocURI 내에서 전송된다. 이하의 예는 폴더(7)가 식별자(1)를 갖는 폴더 내에 위치될 때, 식별자(7)를 갖는 폴더 내에 123의 국부 고유 식별자(LUID; locally unique identifier)를 갖는 아이템을 어떻게 어드레스할 것인지를 도시한다.

이하는 (클라이언트나 서버가 될 수 있는) 수신단 내에 폴더 정보를 생성하기 위해 사용된 운영 요소(명령)을 포함하는 본 발명에 따른 SyncML 메시지의 예시이다. 상기 예시에서, 클리어 텍스트 XML이 사용되었으며; 무선 환경에서, 클리어 텍스트는 일반적으로 사용되지 않으며, 대신에 WBXML(Wireless binary XML)이 사용될 것이다.

상기 SyncML 메시지 단편은 "My folder"의 이름을 갖도록 ./100/의 LocURI를 갖는 폴더를 이름 바꾼다.

동기화(SYNCHRONIZATION)

본 발명에 따르면, (양방향) 동기화는 이하에서 상술된 버전 1.1, SyncML 동기화 프로토콜 규격 내에서 상술된 바와 같이 행해진다.

이전의 동기 후에 클라이언트 폴더 구조에서 변형이 있다면, 동기 요소 내의 운영 요소(예를 들면, 리플레이스(대체), 부가 및 삭제)를 위한 이하의 필요 조건이 만족되어야 한다.

폴더 정보 전송은 임의의 메시지 객체 전송 전에 행해져야 한다 즉, 리플레이스 명령은 메시징 객체를 위한 임의의 변형을 정의하는 명령을 특정하기 전에 변형 패키지 내에서 지정되어야 한다.

데이터 요소는 아이템(Item) 요소를 위해 지정되어서는 안 된다.

연산(operation)이 삭제되지 않으면, 아이템 요소의 메타(Meta)요소 내의 마크(Mark) 요소는 폴더에 대한 정보(예를 들면, 폴더의 유형)를 전달하기 위해 활용되어야 한다.

연산(operation)이 삭제되지 않으면, 아이템 요소의 소스내의 LocName 요소는 폴더의 디스플레이 가능한 이름을 지정해야 한다.

아이템 요소의 소스 내의 LocURI 요소는 폴더 식별자 및 폴더의 전체 경로를 지정해야 한다 즉, 모든 가능한 서브폴더 식별자들도 LocURI 요소 내에서 특정되어야 한다. 폴더 식별자는 슬래시 문자('/')에 의해 범위가 정해져야 한다.

만약 이전 동기 후에 클라이언트 내의 메시징 객체 내에 변형이 있다면, 동기 요소내의 운영 요소를 위한 이하의 필요 조건이 만족되어야 한다.

만약 연산이 삭제되지 않으면, 아이템 요소의 소스 내의 LocName 요소는 메시지의 디스플레이 가능한 이름을 지정해야 한다.

만약 연산이 삭제되지 않으면, 아이템 요소의 메타 요소내의 마크 요소는 메시지의 상태에 대한 정보(예를 들면, 판독/미판독 정보)를 전달하기 위해 사용되어 야 한다.

아이템 요소의 소스 내의 LocURI 요소는 전체 경로를 포함한 아이템의 식별자를 지정해야 한다 즉, 모든 가능한 폴더 및 서브폴더 식별자도 LocURI 요소 내에서 지정되어야 한다. 아이템 식별자(즉, LUID)는 항상 LocURI 요소내의 최종 값으로 표현되어야 한다. 폴더 식별자들은 슬래시 문자('/')에 의해 범위가 정해져야 한다.

이하의 것은 변형을 서버에 전송하는 클라이언트의 예시이다.

만약, 이전의 동기 이후에, 서버의 폴더 구조 내에 변형이 있다면, 동기 요소 내의 운영 요소를 위한 이하의 필요 조건이 만족되어야 한다.

폴더 정보 전송은 임의의 메시지 객체 전송 전에 행해져야 한다 예를 들면, 리플레이스 명령은 메시징 객체를 위한 변형을 정의하는 임의의 명령을 지정하기 전에 변형 패키지 내에서 지정되어야 한다.

데이터 요소는 아이템을 위하여 지정되지 않아야 한다.

만약 연산이 삭제되지 않으면, 아이템 요소의 메타 요소내의 마크 요소는 폴더에 대한 정보(예를 들면, 폴더의 유형)를 전달하기 위해 사용되어야 한다.

만약 연산이 삭제되지 않으면, 아이템 요소의 타겟내의 LocName 요소는 폴더의 디스플레이 가능한 이름을 지정해야 한다.

연산이 추가(addition)라면, 소스 요소의 LocName은 폴더의 디스플레이 가능한 이름을 지정해야 한다.

아이템 요소의 타겟내의 LocURI 요소는 클라이언트측 폴더 식별자 및 폴더의 전체 경로를 지정해야 한다, 즉 모든 가능성 있는 서브폴더 식별자는 LocURI 요소 내에서 지정되어야 한다. 폴더 식별자는 슬래시 문자('/')에 의해 범위가 정해져야 한다.

만약 연산이 추가(addition)라면, 소스 요소의 LocURI는 서버측 폴더 식별자 및 경로를 지정해야 한다. 타켓 요소의 LocURI는 클라이언트의 폴더 경로를 지정해야 한다. 폴더 식별자는 타겟 LocURI내에서 지정되어서는 안 된다.

만약 이전 동기 이후에 서버내에서 메시징 객체 내의 임의의 변형이 있다면, 동기 요소내의 운영 요소를 위한 이하의 필요 조건이 만족되어야 한다.

연산이 추가인 경우에, 아이템 요소의 소스 내의 LocName 요소는 메시지의 디스플레이 가능한 이름을 지정해야 한다. 아이템 요소의 소스 내의 LocURI 요소는 전체 경로를 포함하는 아이템의 식별자를 지정해야 한다, 득 모든 가능성 있는 폴더 및 서브폴더 식별자들도 LocURI 요소 내에서 지정되어야 한다. 아이템 식별자(즉, GUID)는 항상 LocURI 요소 내에서 최종값으로 표현되어야 한다. 폴더 식별자는 슬래시 문자('/')에 의해 범위가 정해져야 한다. 타겟 요소의 LocURI는 클라이언트의 폴더 경로를 지정해야만 하지만, 아이템 식별자는 타겟 LocURI 내에서 지정되어서는 안 된다.

만약 연산이 변형(modification)이라면, 아이템 요소의 타겟 내의 LocName 요소는 메시지의 디스플레이 가능한 이름을 지정해야 한다. 아이템 요소의 타겟 내의 LocURI 요소는 전체 경로를 포함하는 아이템 식별자를 지정해야 한다, 즉 모든 가능성 있는 폴더와 서브폴더 식별자들도 LocURI 요소 내에서 지정되어야 한다. 아이템 식별자(즉, LUID)는 항상 LocURI 요소 내에서 최종값으로 표현되어야 한다. 폴더 식별자는 슬래시 문자('/')에 의해 범위가 정해져야 한다.

만약 연산이 삭제(deletion)라면, 아이템 요소의 소스 내의 LocURI 요소는 클라이언트의 전체 경로를 포함하는 클라이언트측 아이템 식별자를 지정해야 한다, 즉 모든 가능성 있는 폴더와 서브폴더 식별자들도 LocURI 요소 내에서 지정되어야만 한다. 폴더 식별자는 슬래시 문자('/')에 의해 범위가 정해져야 한다.

만약 연산이 삭제가 아니라면, 아이템 요소의 메타 요소내의 마크 요소는 메시지의 상태에 대한 정보(예를 들면, 판독/미판독 정보)에 대한 정보도 지정되어야 한다.

이하의 것은 변형을 클라이언트로 전송하는 서버의 예시이다.

명령 식별자(ID)(5)를 갖는 상기 명령에서, 서버는 "My Own Message" 이름을 갖는 폴더를 위한 ./4044/223/의 국부 단일 식별자(GUID)를 사용한다. SyncML 동기 프로토콜(표준), 버전 1.1, 섹션 5.3에서 설명된 바와 같이, 클라이언트 동기 에이전트는 폴더를 위한 LUID를 할당하며, 그리고 나서 (클라이언트의) LUID가 (서버의) GUID와 어떻게 관련되는지를 보여주는 맵을 서버에 리턴한다. (섹션 5.3.1에 주어진 예시 참조.)

몇몇의 폴더 조작 처리(SOME FOLDER MANIPULATIONS)

이미 설명된 바와 같이, 폴더는 동기화 세션내의 단지 다른 객체이다. 사용자가 클라이언트 장치(예를 들면, 랩탑 또는 이동 전화)내에서 새로운 폴더를 생성하는 경우의 예를 들면, 클라이언트는 다음 동기화 세션 내의 새로운 폴더에 대한 정보를 포함하는 리플레이스 명령을 전송해야 한다. 이것은 본 발명에 따른 이하의 SyncML 메시지 단편으로 행해질 것이다.

수신자가 데이터 요소를 포함하지 않는 연산(즉, 리플레이스나 추가)을 수신할 때, 연산이 폴더 조작 처리 연산이라는 것을 가정해야 한다.

폴더 생성(Creating Folders)

폴더 생성은 리플레이스나 추가 명령을 지정함으로써 행해진다. 이하는 (1011의 식별자를 갖는 클라이언트측 Inbox 폴더를 갖는) 클라이언트의 Inbox 폴더 내에서 폴더 식별자(7)를 갖는 새로운 폴더를 생성하기 위한 방법의 예시이다.

클라이언트는 서버 폴더의 식별자가 클라이언트 폴더의 식별자와 어떻게 관련시키는 지를 서버를 위하여 나타내는 정보를 서버로 매핑시키는 것으로 복귀해야 하며, 서버는 클라이언트의 폴더 식별자를 이용하여 폴더를 확인해야 한다. 그러므로, 서버에 의해 전송된 운영 요소의 아이템 내의 타겟 요소는 항상 클라이언트측 폴더 경로를 포함해야 한다.

새로운 폴더가 서버상에서 생성되며, 메시지가 폴더에 추가되는 경우에, 서버는 서버 변형 패키지의 제 1 메시지내의 폴더 연산(즉, 폴더 정보를 포함하는 추가 명령)를 전송해야 하며, 최종 플래그(flag)는 메시지 내에서 지정되어서는 안 된다. 클라이언트는 일련의 메시지 내에서 정보를 서버에 매핑시키는 폴더 식별자를 복귀시킬 수 있어야 하며, 그 결과 서버는 실제 메시지를 포함하는 추가 연산의 타겟 내에서 클라이언트의 폴더 식별자를 지정할 수 있게 된다.

폴더 이름 바꾸기(Renaming Folders)

폴더의 디스플레이 이름은 LocName 요소 내에서 전송되므로, 폴더의 이름을 바꾸기 위한 특별한 연상은 없다. 그러므로, 폴더의 디스플레이 가능한 이름이 변 경될 때, 리플레이스 명령이 전송되어야 하며, 그리고 LocName 요소는 폴더의 새로운 디스플레이 가능한 이름을 포함해야만 한다.

폴더 이동 (Moving Folder)

폴더의 전체 경로는 LocURI 요소 내에서 전송되므로, 폴더 이동을 위한 특별한 연산은 없다. 그러므로, 폴더가 다른 폴더 안으로 이동될 때, 리플레이스 명령이 전송되어야 하며, 그리고 새로운 폴더 경로는 LocURI 요소 내에 포함되어야 한다. 만약 새로운 폴더가 서버 내에서 생성되며, 존재하는 폴더가 새로운 폴더 안으로 이동된다면, 서버는 우선 새로운 폴더를 클라이언트에 추가시키며, 그리고 폴더 식별자를 위한 매핑 정보를 수신한 후에, 서버는 존재하는 폴더를 이동시켜야 한다 즉, 서버는 새로운 클라이언트측 폴더 경로를 포함하는 리플레이스 명령을 전송해야 한다.

어플리케이션 요소, 동기 요소 및 동기 엔진간의 상호작용

클라이언트와 서버 어플리케이션(11a, 11b) 및 동기 요소(11b, 12b) 및 서버 동기 엔진(12)이 데이터 구성(디렉토리 구조)에서의 변화를 다루기 위하여 상호작용하는 가능성 있는 한 가지 방식이 도 1에 개시되며, 도 3에도 개시되지만, 그러한 방식은 본 발명의 주제는 아니다. 이해하기 위하여 가장 중요한 것은 본 발명은 클라이언트와 서버 동기 요소(11b, 12b)가 데이터 구성에서의 변화를 행하기 위하여 갖는 정보를 추출하기 위하여 SyncML 메시지를 데이터 요소의 레벨로 하향 분석(parse)할 필요가 없다는 것이며, 그리고 클라이언트와 서버 어플리케이션(11a, 12a)은 데이터 추가, 리플레이스 또는 삭제를 할 수 있도록 개별적인 데이터 저장 부(11c, 12c)를 접속하기 위하여 디렉토리 구조에 대해서 전혀 이해할 필요가 없다는 것을 제공한다는 것이다.

그럼에도 불구하고, 다시 도 1 및 도 3을 참조하여, 2개의 데이터 저장부(11c, 12c)를 동기화하기 위한 한 장치에서, 제 1 단계(31a)에서, 서버 동기 에이전트(12b)는 클라이언트 동기 에이전트(11b)와의 전송 접속을 설정한다(클라이언트 동기 에이전트에 의해서 상호 동작이 수반되지만 도 3에서는 미도시). 다음 단계 31b에서, 클라이언트 어플리케이션(11a)은, 클라이언트 데이터 저장부(11c)에 있어서 최종 동기 이후의 클라이언트 데이터 저장부(11c)의 변경을 결정하고 (동일 데이터 저장부를 공유하는 어플리케이션은 1 개 이상이 있을 수 있지만, 1개의 어플리케이션 밖에 없다고 가정한다), 클라이언트 동기 에이전트는 데이터 저장부(11c)에 있어서 폴더들에 대하여, 동일한 처리를 실행한다. 또한, 다음 단계 31c에서, 동기 에이전트는 상기에서 설명한 바와 같이, 데이터 요소의 외부의 데이터 식별 요소에 의하여, 영향을 받는 폴더를 참조하기(reference) 위해, 데이터 식별 요소를 사용하여 명령(프로토콜 명령 요소)에 폴더의 변경을 설정한다. 그 다음에, 단계 31d에서, 어플리케이션은 데이터 설명(description) 요소(데이터, 아이템 또는 메타 요소)를 사용하여 명령에 데이터 유닛 변경을 설정한다. 다음에, 단계 31e에서, 동기 에이전트는 데이터 설명 요소와 (임의의 데이터 요소 외부의) 데이터 식별 요소와 함께 명령을 함유하는 메시지를 서버(12)에 전송한다.

그 다음에, 서버(12)에서, 다음 단계 31f에서, 동기 에이전트(12b)는 임의의 데이터 요소 외부의 클라이언트 데이터 식별 요소와 함께 임의의 명령으로부터 폴더 변경을 추출하며, 그리고 클라이언트 데이터 식별 요소에 포함된 명령에 기초하여 최종 동기화 이래로 클라이언트 데이터 저장 데이터 구조에 행해진 변화가 무엇인지를 동기 엔진(12f)에 나타낸다. 그 다음에, 단계 31g에서, 동기 엔진은 폴더 충돌을 해결하고, 실제 폴더 변화를 서버 동기 에이전트(12b)에 제공하며; 서버 동기 에이전트(12b)는 폴더 변화를 서버 데이터 저장부(12c)에 상응하게 만들며; 그리고 서버 동기 에이전트는 (클라이언트에 의해 임의의 데이터 유닛 변화를 전송하는) 메시지의 나머지를 (서버) 동기 엔진에 제공한다. 다음 단계 31h에서, 만약 클라이언트 데이터 저장부(11c)에 행해진 변화가 서버 데이터 저장부(12c)에도 모두 행해진다면 야기되는 서버 데이터 저장부와 임의의 데이터 유닛 충돌을 동기 엔진(12f)이 해결하며, 그리고 동기 엔진은 실제 데이터 유닛 변화를 서버 어플리케이션(12a)에 제공한다. 다음 단계 31i에서, 서버 어플리케이션은 표시된 데이터 유닛 변화를 서버 데이터 저장부(12c)에 행하며, 그리고 적절한 명령으로 클라이언트 데이터 저장부(11c)에 실제 데이터 유닛을 변화시킨다. 그리고 나서, 다음 단계 31j에서, 서버 동기 에이전트는 클라이언트 데이터 저장부(11c)내의 폴더에 행해질 실제 변화를 선택하고, 관계된 폴더를 나타내는 데이터 식별 요소를 포함하는 상응하는 명령을 추가하고, 상기 데이터 식별 요소는 메시지 내에서 임의의 데이터 요소 외부에 놓여진다. (그리고 나서, 메시지는 클라이언트에 전송된다.)

다음 단계 31k에서, 클라이언트(11)가 서버 메시지를 수신할 때, 클라이언트 동기 에이전트(11b)는 명령 내에 포함된 임의의 데이터 요소를 포함하지 않는 것을 제외하고 명령을 하향 분석(parse)함으로써 모든 폴더 변화를 추출하고, 따라서 클라이언트 데이터 저장부(11c)를 변화시키며, 그리고 어플리케이션(11a)에 데이터 유닛 변화를 위한 모든 명령을 제공한다. 마지막으로, 단계 31m에서, 어플리케이션(11a)는 클라이언트 동기 에이전트(11b)에 의해 제공된 명령에 따라 클라이언트 데이터 저장부(11c)를 변화시킨다.

상기 설명된 장치는 단지 본 발명의 원리를 적용하기 위한 예시임을 이해해야 한다. 많은 변형과 대안적인 장치가 본 발명의 범주로부터 벗어남이 없이 당업자에 의해서 고안될 수 있으며, 그리고 첨부되는 청구항은 그러한 변형 및 장치를 보호하기 위해 의도된다.

Claims

적어도 2개의 데이터 저장부를 동기화하기 위한 방법에 있어서, 상기 방법은:

제2 데이터 저장부에 관련된 제2 동기 에이전트와의 통신을 가능하게 하기 위해, 제1 데이터 저장부와 관련된 제1 동기 에이전트에 의해, 전송 연결을 설정하는 단계;

디렉토리 구조에 대하여 상기 제2 데이터 저장부와 동기화하기 위한 명령어를 포함한 메시지를 준비하는 단계 [상기 명령어는, 상기 제1 데이터 저장부에서의 적어도 하나의 변경과 관련된 폴더를 식별하는, 상기 명령어 내에 삽입된(embedded) 적어도 하나의 데이터 식별 요소를 포함]; 및

상기 메시지를 상기 제2 동기 에이전트로, 상기 설정된 전송 연결을 통해 전달하는 단계를 포함하며,

이때, 상기 명령어 내에 삽입된, 적어도 하나의 데이터 식별 요소는 상기 메시지의 적어도 하나의 비-데이터 요소 내에 담긴, 데이터 저장부 동기화 방법.
제1항에 있어서,

상기 명령어 및 상기 적어도 하나의 데이터 식별 요소는 상기 폴더와 관련된 상기 적어도 하나의 변경에 관한 정보를 포함하는, 데이터 저장부 동기화 방법.
제1항에 있어서,

상기 명령어, 즉 동작(operational) 요소에 포함된, 상기 적어도 하나의 데이터 식별 요소는 타겟 요소 및 소스 요소 중 적어도 하나를 포함하는, 데이터 저장부 동기화 방법.
제1항에 있어서,

메시지는 syncML 메시지이고, 그리고

상기 명령어는 syncML 프로토콜 명령 요소인, 데이터 저장부 동기화 방법.
제4항에 있어서,

상기 데이터 식별 요소는, LocURI 요소를 포함하는, 데이터 저장부 동기화 방법.
제1항에 있어서,

상기 명령어는, 폴더 재명명, 새로운 폴더 생성, 폴더 이동, 하나의 폴더로부터 다른 하나의 폴더로 데이터 아이템을 이동하는 것 중 하나 이상을 포함하는 폴더 조작 동작에 관한 것인, 데이터 저장부 동기화 방법.
제1항에 있어서,

상기 명령어 내에 삽입된, 상기 적어도 하나의 데이터 식별 요소는 상기 폴더의 경로(path) 및 ID(identification)를 포함하는, 데이터 저장부 동기화 방법.
적어도 2개의 데이터 저장부들을 동기화하기 위한 방법으로서, 상기 방법은:

제1 데이터 저장부와 관련된 제1 동기 에이전트와 제2 데이터 저장부와 관련된 제2 동기 에이전트 사이의 전송 연결을 설정하는 단계;

디렉토리 구조에 대하여 상기 제2 데이터 저장부를 동기화시키기 위한 명령어를 포함하는, 동기화 메시지를, 상기 제2 동기 에이전트에서, 상기 전송 연결을 통해, 수신하는 단계 [상기 명령어는, 상기 제1 데이터 저장부에서의 적어도 하나의 변경과 관련된 폴더를 식별하는, 상기 명령어 내에 삽입된(embedded) 적어도 하나의 데이터 식별 요소를 포함]; 및

상기 명령어 내에 삽입된 적어도 하나의 데이터 식별 요소 및 상기 메시지 내에 포함된 상기 명령어에 의해 운반된 정보에 기초하여 상기 제2 데이터 저장부의 디렉토리 구조를 변경시키는 단계를 포함하며,

상기 명령어 내에 삽입된, 적어도 하나의 데이터 식별 요소는 상기 메시지의 비-데이터 요소 내에 담긴, 데이터 저장부 동기화 방법.
제8항에 있어서,

상기 명령어 및 상기 적어도 하나의 데이터 식별 요소는 상기 폴더와 관련된 상기 적어도 하나의 변경에 관한 정보를 포함하며, 그리고

이때 상기 메시지는, 제1 데이터 저장부 내의 데이터 아이템들의 변경에 관한 정보를 담고 있는 적어도 하나의 데이터 요소를 더 포함하는, 데이터 저장부 동기화 방법.
제8항에 있어서, 상기 방법은,

상기 동기 에이전트에 의해, 적어도 하나의 데이터 식별 요소로부터 디렉토리 구조에서의 상기 변경에 관한 정보를 추출하는 단계, 및

상기 정보를 동기 엔진 또는 어플리케이션 개체 중 하나에 제공하는 단계를 더 포함하는, 데이터 저장부 동기화 방법.
제8항에 있어서,

상기 명령어 내에 삽입된, 적어도 하나의 데이터 식별 요소는, 타겟 요소 및 소스 요소 중 적어도 하나를 포함하는, 데이터 저장부 동기화 방법.
제8항에 있어서,

상기 메시지는 syncML 메시지이고, 그리고

상기 명령어는 syncML 프로토콜 명령 요소인, 데이터 저장부 동기화 방법.
제12항에 있어서,

상기 데이터 식별 요소는, LocURI 요소를 포함하는, 데이터 저장부 동기화 방법.
제8항에 있어서,

상기 명령어는, 폴더 재명명, 새로운 폴더 생성, 폴더 이동, 하나의 폴더로부터 다른 하나의 폴더로 데이터 아이템을 이동하는 것 중 하나 이상을 포함하는 폴더 조작 동작에 관한 것인, 데이터 저장부 동기화 방법.
제8항에 있어서,

상기 명령어 내에 삽입된, 상기 적어도 하나의 데이터 식별 요소는 상기 폴더의 경로(path) 및 ID(identification)를 포함하는, 데이터 저장부 동기화 방법.
적어도 2개의 데이터 저장부를 동기화하기 위한 기기에 있어서,

폴더들 내에 데이터 아이템들로서 데이터를 저장하도록 구성된 데이터 저장부 [폴더들은 디렉토리 구조를 특징 지음]; 및

상기 데이터 저장부를 다른 기기의 다른 데이터 저장부와 동기화시키도록 구성된 동기 에이전트를 포함하고, 상기 기기는:

상기 다른 데이터 저장부와 관련된, 상기 다른 기기의 다른 동기 에이전트와 상기 동기 에이전트 사이에 전송 연결을 설정하는 수단;

디렉토리 구조에 대하여 상기 데이터 저장부를 동기화시키기 위한 명령어를 포함하는, 동기화 메시지를 상기 동기 에이전트에서, 상기 전송 연결을 통해 수신하는 수단 [상기 명령어는 상기 다른 데이터 저장부에서의 적어도 하나의 변경과 관련된 폴더를 식별하는, 상기 명령어 내에 삽입된, 적어도 하나의 데이터 식별 요소를 포함]; 및

상기 명령어 내에 삽입된 적어도 하나의 데이터 식별 요소 및 메시지 내에 포함된 상기 명령어에 의해 운반된 정보에 적어도 부분적으로 기초하여, 상기 데이터 저장부의 디렉토리 구조를 변경시키는 수단을 포함하며,

상기 명령어 내에 삽입된 적어도 하나의 데이터 식별 요소는 메시지의 비-데이터 요소 내에 담긴, 데이터 저장부 동기화 기기.
제16항에 있어서,

명령어 및 적어도 하나의 데이터 식별 요소는, 상기 폴더와 관련된 상기 적어도 하나의 변경에 관한 정보를 포함하는, 데이터 저장부 동기화 기기.
제17항에 있어서,

상기 메시지는 상기 다른 데이터 저장부에서의 데이터 아이템들에서의 변경에 관한 정보를 포함하는 적어도 하나의 데이터 요소를 더 포함하는, 데이터 저장부 동기화 기기.
제16항에 있어서,

상기 기기는 무선 통신 단말 및 유선 통신 단말 중 하나를 포함하는, 데이터 저장부 동기화 기기.
제16항에 있어서,

상기 기기는 클라이언트 서버 모델에서 서버로서 동작하고, 그리고

상기 메시지에 의한 충돌을 해결하도록 구성된 동기(engine) 엔진을 포함하는, 데이터 저장부 동기화 기기.
제16항에 있어서, 상기 기기는,

적어도 하나의 데이터 식별 요소 및 명령어로부터 디렉토리 구조에서의 상기 변경에 관한 정보를 추출하고, 그리고 동기 엔진 또는 어플리케이션 개체 중 하나에 그 정보를 제공하는 수단을 더 포함하는, 데이터 저장부 동기화 기기.
제16항에 있어서,

상기 명령어 내에 삽입된 적어도 하나의 데이터 식별 요소는, 타겟 요소 및 소스 요소 중 적어도 하나를 포함하는, 데이터 저장부 동기화 기기.
제16항에 있어서,

상기 메시지는 syncML 메시지이고, 그리고

상기 명령어는 syncML 프로토콜 명령 요소인, 데이터 저장부 동기화 기기.
제16항에 있어서,

상기 데이터 식별 요소는, LocURI 요소를 포함하는, 데이터 저장부 동기화 기기.
제16항에 있어서,

상기 명령어는, 폴더 재명명, 새로운 폴더 생성, 폴더 이동, 하나의 폴더로부터 다른 하나의 폴더로 데이터 아이템을 이동하는 것 중 하나 이상을 포함하는 폴더 조작 동작에 관한 것인, 데이터 저장부 동기화 기기.
제16항에 있어서,

상기 명령어 내에 삽입된, 상기 적어도 하나의 데이터 식별 요소는 상기 폴더의 경로(path) 및 ID(identification)를 포함하는, 데이터 저장부 동기화 기기.
적어도 2개의 데이터 저장부를 동기화하기 위한 기기에 있어서,

폴더들 내에 데이터 아이템들로서 데이터를 저장하도록 구성된 데이터 저장부 [폴더들은 디렉토리 구조를 특징 지음]; 및

상기 데이터 저장부를 다른 기기의 다른 데이터 저장부와 동기화시키도록 구성된 동기 에이전트를 포함하고, 상기 기기는:

상기 다른 데이터 저장부와 관련된, 상기 다른 기기의, 다른 동기 에이전트와 상기 동기 에이전트 사이에 전송 연결을 설정하는 수단 ; 및

상기 디렉토리 구조에 대하여 상기 다른 데이터 저장부를 동기화시키기 위한 명령어를 포함하는 동기화 메시지를 준비하는 수단 [상기 명령어는, 상기 데이터 저장부 내의 적어도 하나의 변경과 관련된 폴더를 식별하는, 상기 명령어 내에 삽입된, 적어도 하나의 데이터 식별 요소를 포함]; 및

상기 다른 동기 에이전트로 상기 동기 메시지를 상기 전송 연결을 통해 전달하는 수단을 포함하며,

상기 명령어 내에 삽입된, 적어도 하나의 데이터 식별 요소는 상기 메시지의 비-데이터 요소 내에 담긴, 데이터 저장부 동기화 기기.
제27항에 있어서,

명령어 및 적어도 하나의 데이터 식별 요소는, 상기 폴더와 관련된 상기 적어도 하나의 변경에 관한 정보를 포함하는, 데이터 저장부 동기화 기기.
제28항에 있어서,

상기 메시지는 상기 다른 데이터 저장부에서의 데이터 아이템들에서의 변경에 관한 정보를 포함하는 적어도 하나의 데이터 요소를 더 포함하는, 데이터 저장부 동기화 기기.
제27항에 있어서,

상기 기기는 무선 통신 단말 및 유선 통신 단말 중 하나를 포함하는, 데이터 저장부 동기화 기기.
제27항에 있어서,

상기 기기는 클라이언트로서 동작하는, 데이터 저장부 동기화 기기.
제27항에 있어서,

상기 명령어 내에 삽입된, 적어도 하나의 데이터 식별 요소는 타겟 요소 및 소스 요소 중 적어도 하나를 포함하는, 데이터 저장부 동기화 기기.
제27항에 있어서,

상기 메시지는 syncML 메시지이고, 그리고

상기 명령어는 syncML 프로토콜 명령 요소인, 데이터 저장부 동기화 기기.
제27항에 있어서,

상기 데이터 식별 요소는, LocURI 요소를 포함하는, 데이터 저장부 동기화 기기.
제27항에 있어서,

상기 명령어는, 폴더 재명명, 새로운 폴더 생성, 폴더 이동, 하나의 폴더로부터 다른 하나의 폴더로 데이터 아이템을 이동하는 것 중 하나 이상을 포함하는 폴더 조작 동작에 관한 것인, 데이터 저장부 동기화 기기.
제27항에 있어서,

상기 명령어 내에 삽입된, 상기 적어도 하나의 데이터 식별 요소는 상기 폴더의 경로(path) 및 ID(identification)를 포함하는, 데이터 저장부 동기화 기기.