KR20080033407A - 사용자 디바이스를 프로비저닝하기 위한 시스템 및 방법 - Google Patents

Abstract

통신 네트워크에서 하나 이상의 사용자 디바이스를 접속시키기 위해 다수 진입점을 제공하기 위한 시스템 및 방법이 개시된다. 본 방법은 하나 이상의 사용자 디바이스와 통신하기 위한 서버를 제공하는 단계로서, 서버는 접속-데이터-세트를 포함하고 하나 이상의 사용자 디바이스는 접속-데이터-세트의 일부를 공유하는, 단계, 다수 진입점 중 하나로부터의 접속-데이터-세트에 액세스하기 위한 요청을 사용자 디바이스로부터 수신하는 단계, 사용자 디바이스의 속성을 자동적으로 판정하는 단계, 사용자 디바이스의 속성을 사용해, 소정 클라이언트 디바이스의 데이터베이스로부터 통신 방법을 선택하는 단계, 및 통신 방법에 따라 사용자 디바이스를 준비하는 단계를 포함한다.

통신 네트워크, 사용자 디바이스, 진입점, 서버, 접속-데이터-세트, 통신 방법

Description

사용자 디바이스를 프로비저닝하기 위한 시스템 및 방법 {SYSTEM AND METHOD FOR PROVISIONING A USER DEVICE}

본 발명은 일반적으로, 통신 네트워크의 하나 이상의 사용자 디바이스로 서비스를 제공하는 분야에 관한 것이다. 특히, 본 발명은 사용자 디바이스를 프로비저닝하기 위한 시스템 및 방법에 관한 것이다.

관련 출원에 대한 상호 참조

이 출원은, 이것과 함께 동시에 출원되고 전체가 참고 문헌으로써 여기에 포함되어 있는 다음의 특허 출원: Matthias Breuer 등의 "System and Method for Servicing a User Device"라는 명칭의 미국특허출원 제11/182,348호(attorney docket number 32421-2001700); Torsten Schulz 등의 "System and Method for Synchronizing between a User Device and a Server in a Communication Network"라는 명칭의 미국특허출원 제11/182,203호(attorney docket number 32421-2001800); Venkatachary Srinivasan 등의 "An Alert Mechanism for Notifying Multiple User Devices Sharing a Connected-Data-Set"라는 명칭의 미국특허출원 제11/183,137호(attorney docket number 32421-2002200); Marco Boerris 등의 "Methods and Systems for Data Transer and Notification Mechanisms"라는 명칭의 미국특허출원 제11/182,614호(attorney docket number 32421-20021.00); 및 Torsten Schulz 등의 "Content Router"라는 명칭의 미국특허출원 제11/182,287호(attorney docket number 32421-2000900)와 관련이 있다.

통신, 정보 관리 및 레크레이션을 위한 전자 디바이스의 최근의 급증으로 인해 일상적인 컴퓨팅 능력은 데스크바운드(deskbound) 퍼스널 컴퓨터로부터 멀어지게 되었다. 사용자는 셀폰, 카메라폰, PDA(personal digital assistants) 및 네비게이션 시스템과 같은 디바이스를, 사무실과 집에서 뿐만 아니라 현장과 거리에서도 사용하고 있다. 통신, 비지니스, 네비게이션, 엔터테인먼트 및 심지어 기본적인 일상 활동 관리를 포함하는, 그러한 디바이스를 위한 다양한 범위의 애플리케이션이 존재할 수 있다. 예를 들어, 전화를 걸고 받는데 셀폰을 사용하는 것처럼, 많은 사용자가 현재로서는 단일 태스크를 위해 단일 디바이스만을 사용한다. 그러나, 이 디바이스들은 더 이상은 단일-기능 디바이스(single-function devices)가 아니다. 이 디바이스는, 다양한 데이터 유형, 예를 들어, 전자 메일, 음성 메시지, 사진, 비디오 등을 생성할 수 있다. 디바이스의 기능 수의 증가는 사용자에 대한 개인화(personalization) 수준을 증가시킨다. 사용자가 어디에 있든, 무슨 디바이스를 사용하든, 무슨 서비스에 접속하든, 사용자에게 사용자의 데이터에 접속하고 액세스하기 위한 접속-서비스(connected-service)를 제공하는 것이 바람직하다.

사용자에게 그러한 접속-서비스를 제공하는 것의 어려움 중 하나는, 사용자가 제품을 구입한 후, 이동 디바이스를 프로비저닝해야 할 필요가 있다는 점이다. 전통적으로, 사용자는 퍼스널 컴퓨터에 접속된 크래들(cradle)을 통해 디바이스를 프로비저닝해야 할 것이다. 이 작업은 통상적으로 집 또는 사무실에서 이루어진다. 프로비저닝 단계가 완료될 때까지, 사용자는 이동 디바이스를 사용할 수 없다. 따라서, 언제 어디서든 이동 디바이스를 프로비저닝해야 할 필요가 있다.

사용자에게 그러한 접속-서비스를 제공하는 것의 다른 어려움은, 하나 이상의 사용자 디바이스가, 사용자가 사용자의 PC, PDA, 셀폰, 또는 다른 디바이스에 이미 설정되어 있는 설정 및 데이터의 세트에 접속되어야 할 필요가 있다는 점이다. 예를 들어, 새로운 디바이스를 갖게 된 경우, 사용자는 설정 및 데이터의 세트를 기존 디바이스로부터 새로운 디바이스로 복제해야 할 필요가 있다. 사용자는 설정 및 데이터의 세트로 기존 디바이스를 보수 또는 교체해야 할 필요가 있다. 사용자 디바이스가 유실되거나, 도난되거나, 잠시 두고 온 경우, 사용자는 사용자 디바이스의 서비스를 종료해야 할 필요가 있다.

사용자에게 그러한 접속-서비스를 제공하는 것의 또 다른 어려움은, 사용자의 통신 상태를, 설정 및 데이터의 공통 세트를 공유하는 하나 이상의 사용자 디바이스에게 통지해야 할 필요가 있다는 점이다. 예를 들어, 하나 이상의 사용자 디바이스에서 이메일, 태스크, 캘린더 이벤트, 또는 주소록 엔트리의 저장에 있어 오버플로우 조건이 존재하는 경우, 사용자에게 통지해야 할 필요가 있다.

사용자에게 그러한 접속-서비스를 제공하는 것의 또 다른 어려움은 설정 및 데이터의 공통 세트를 공유하는 서버 및 하나 이상의 사용자 디바이스 사이에서 데이터 일관성(consistency)을 유지해야 할 필요가 있다는 점이다. 예를 들어, 서비 스가 일정 시간 동안 서버에서 중단되었을 때, 서버 및 하나 이상의 사용자 디바이스 사이에서 데이터 변화를 동기화해야 할 필요가 있다.

일 실시예에서, 통신 네트워크에서 하나 이상의 사용자 디바이스를 접속시키기 위해 다수 진입점을 제공하기 위한 시스템은 하나 이상의 사용자 디바이스와 통신하기 위한 서버를 포함하는데, 서버는 접속-데이터-세트(connected-data-set)를 포함하고, 하나 이상의 사용자 디바이스는 접속-데이터-세트의 일부를 공유한다. 시스템은 다수 진입점 중 하나로부터의 접속-데이터-세트에 액세스하기 위한 요청을 사용자 디바이스로부터 수신하기 위한 로직, 사용자 디바이스의 속성을 자동적으로 판정하기 위한 로직, 사용자 디바이스의 속성을 사용해, 소정 클라이언트 디바이스의 데이터베이스로부터 통신 방법을 선택하기 위한 로직, 및 통신 방법에 따라, 사용자 디바이스를 프로비저닝하기 위한 로직을 더 포함한다.

다른 실시예에서, 통신 네트워크에서 하나 이상의 사용자 디바이스를 접속시키기 위해 다수 진입점을 제공하기 위한 방법은 하나 이상의 사용자 디바이스와 통신하기 위한 서버를 제공하는 단계로서, 서버는 접속-데이터-세트를 포함하고 하나 이상의 사용자 디바이스는 접속-데이터-세트의 일부를 공유하는, 단계, 다수 진입점중 하나로부터의 접속-데이터-세트에 액세스하기 위한 요청을 사용자 디바이스로부터 수신하는 단계, 사용자 디바이스의 속성을 자동적으로 판정하는 단계, 사용자 디바이스의 속성을 사용해, 소정 클라이언트 디바이스의 데이터베이스로부터 통신 방법을 선택하는 단계, 및 통신 방법에 따라 사용자 디바이스를 프로비저닝하는 단계를 포함한다.

본 발명의 상기 특징 및 이점 뿐만 아니라 그것에 관한 추가적인 특징 및 이점은, 다음의 도면과 함께 본 발명의 실시예에 대한 상세한 설명을 읽은 이후에 좀더 명백하게 이해 가능할 것이다.

도 1a는 본 발명의 일 실시예에 따른 접속-라이프 서비스(connected-life service)를 도시한다.

도 1b는, 본 발명의 일 실시예에 따른, 도 1a의 접속-라이프 서비스를 지원하는 접속-라이프 서버(connected-life server)를 도시한다.

도 2는, 본 발명의 일 실시예에 따른, 접속-라이프 서버의 디바이스 관리자 구현을 도시한다.

도 3은, 본 발명의 일 실시예에 따른, 미-구성 어카운트 그룹(un-configured account group)을 프로비저닝하기 위한 작업 흐름을 도시한다.

도 4는, 본 발명의 일 실시예에 따른, 사전-구성 어카운트 그룹(pre-configured account group)을 프로비저닝하기 위한 작업 흐름을 도시한다.

도 5는, 본 발명의 일 실시예에 따른, Microsoft Outlook을 프로비저닝하기 위한 작업 흐름을 도시한다.

도 6은, 본 발명의 일 실시예에 따른, 사전-설치 로더(pre-installed Loader)를 통해 디바이스를 프로비저닝하기 위한 작업 흐름을 도시한다.

도 7은, 본 발명의 일 실시예에 따른, 웹사이트를 통해 디바이스를 프로비저 닝하기 위한 작업 흐름을 도시한다.

도 8은, 본 발명의 일 실시예에 따른, 확인된 폰 번호에 의해 웹사이트를 통해 디바이스를 프로비저닝하는 작업 흐름을 도시한다.

도 9는, 본 발명의 일 실시예에 따른, 확인된 폰 번호없이 웹사이트를 통해 디바이스를 프로비저닝하는 작업 흐름을 도시한다.

도 10은, 본 발명의 일 실시예에 따른, ActiveX 디바이스를 위한 웹사이트를 통해 디바이스를 프로비저닝하는 작업 흐름을 도시한다.

도 11은, 본 발명의 일 실시예에 따른, 클라이언트 소프트웨어를 사용하는 웹사이트를 통해 디바이스를 프로비저닝하는 작업 흐름을 도시한다.

도 12는, 본 발명의 일 실시예에 따른, 디바이스의 기존 동기화 스택(existing sync stack)을 사용하는 웹 사이트를 통해 디바이스를 프로비저닝하는 작업 흐름을 도시한다.

도 13은, 본 발명의 일 실시예에 따른, SMS를 통해 디바이스를 프로비저닝하는 작업 흐름을 도시한다.

도 14는, 본 발명의 일 실시예에 따른, 온라인 샵(online shop)을 통해 디바이스를 프로비저닝하는 작업 흐름을 도시한다.

도 15는 REx 프로토콜 흐름의 개요를 도시한다.

도 16은 상이한 REx 방법을 사용하는 사용자 디바이스와 서버 사이의 상호 작용 흐름도를 도시한다.

도 17은, 본 발명의 일 실시예에 따른, 쿼리 프로세스(query process)를 위 한 순서도를 도시한다.

도 18은, 본 발명의 일 실시예에 따른, 클라이언트 디바이스와 서버 사이를 동기화하기 위한 동기화 앵커 프로토콜(sync anchor protocol)을 도시한다.

도 19는, 본 발명의 일 실시예에 따른, 디바이스가 디바이스 유형 ID(identification) 설정을 교환할 때의 프로세스 흐름도를 도시한다.

도 20은, 본 발명의 일 실시예에 따른, 디바이스가 좀비 상태(zombie state)에서 디바이스 유형 ID 이외의 설정을 교환하려 할 때의 프로세스 흐름도를 도시한다.

도 21은, 본 발명의 일 실시예에 따른, 표준 설정 교환(normal settings exchange)을 위한 순서도를 도시한다.

도 22는, 본 발명의 일 실시예에 따른, 덤프 설정(dump settings)을 위한 순서도를 도시한다.

도 23은, 본 발명의 일 실시예에 따른, 디바이스와 서버 사이의 애플리케이션 교환 프로세스 흐름의 순서도를 도시한다.

도 24는, 본 발명의 일 실시예에 따른, 애플리케이션 교환 상태 전이도를 도시한다.

사용자 디바이스를 프로비저닝하기 위한 방법 및 시스템이 제공된다. 다음 설명은, 당업자라면 누구나 본 발명을 실시하고 사용할 수 있도록 하기 위해 제시된다. 특정 실시예 및 애플리케이션의 설명은 단지 일례로서 제공된다. 여기에서 설명되는 일례의 다양한 변경 및 조합은 당업자에게 이미 명백할 것이고, 여기에서 정의되는 일반적인 원리는, 본 발명의 사상 및 범위를 벗어나지 않는 범위 내에서, 다른 일례 및 애플리케이션에 적용될 수 있다. 따라서, 본 발명은 설명되고 도시된 예로 제한되지 않으며, 여기에서 설명되는 원리 및 특징에 부합하는 최대 범위를 따를 것이다.

다음의 상세한 설명 중 소정 부분은 절차, 단계, 논리 블록, 프로세싱, 및 컴퓨터 메모리 상에서 수행될 수 있는 데이터 비트에 대한 동작의 다른 기호 표현에 의해 제시된다. 절차, 컴퓨터-실행 단계, 논리 블록, 프로세스 등은 여기에서, 원하는 결과에 이르는 단계 또는 명령어의 자체 모순없는 시퀀스(self-consistent sequence)인 것으로 생각된다. 단계는 물리량의 물리적 조작을 이용하는 것이다. 이 양은, 저장, 전송, 조합, 비교, 및 그렇지 않으면 컴퓨터 시스템에서 조작될 수 있는 전기, 자기, 또는 무선 신호의 형태를 취할 수 있다. 이 신호를 때로는 비트, 값, 요소, 심볼, 캐릭터, 항목, 숫자 등으로 언급할 수도 있다. 각 단계는 하드웨어, 소프트웨어, 또는 그것에 관한 조합에 의해 수행될 수도 있다.

도 1a는 본 발명의 일 실시예에 따른 접속-라이프 서비스를 도시한다. 접속-라이프 서비스는 사용자가 그들의 접속-데이터-세트를 언제 어디서든 임의의 디바이스로 공유하고 액세스할 수 있게 한다. (디바이스 또는 클라이언트라고도 지칭되는) 사용자 디바이스는 셀룰러폰, 무선 PDA, 네비게이션 디바이스, 퍼스널 컴퓨터, 게임 콘솔, 인터넷 터미널, 및 키오스크(Kiosks)를 포함할 수도 있다. 접속-데이터-세트는 이메일, 연락처(contacts), 캘린더, 태스크, 메모(notes), 사진, 문서, 음악, 비디오, 북마크, 및 링크를 포함할 수 있다.

다른 실시예에서, 접속-라이프 서비스는 다음의 기능성: 1) 사용자 디바이스를 보수, 2) 제1 사용자 디바이스를 제2 사용자 디바이스로 복제, 3) 제1 사용자 디바이스를 제2 사용자 디바이스로 교체, 및 4) 사용자 디바이스의 서비스를 종료하는 기능성을 제공한다. 사용자 디바이스를 보수하는 서비스는 하나 이상의 사용자 디바이스의 상태를 재설정하는 단계, 하나 이상의 사용자 디바이스의 구성 및 설정을 복구하는 단계, 및 접속-데이터-세트를 하나 이상의 사용자 디바이스상으로 복구하는 단계를 포함한다.

제1 사용자 디바이스를 제2 사용자 디바이스로 복제하는 서비스는 제1 사용자 디바이스의 구성 및 설정을 제2 사용자 디바이스로 전달하는 단계, 및 제1 사용자 디바이스의 설정에 따라, 접속-데이터-세트의 일부를 제2 사용자 디바이스로 전달하는 단계를 포함한다.

제1 사용자 디바이스를 제2 사용자 디바이스로 교체하는 서비스는, 소정 구성 및 설정의 세트를 구성 데이터베이스(configuration database)로부터 제1 디바이스와 동일한 모델, 만듦새(make), 및 유형(type)을 가진 제2 사용자 디바이스에게로 전달하는 단계 및, 제2 사용자 디바이스의 설정에 따라 접속-데이터-세트 중 일부를 제2 사용자 디바이스로 전달하는 단계를 포함한다. 제1 사용자 디바이스를 제2 사용자 디바이스로 교체하는 서비스는 소정 구성 및 설정의 세트를 구성 데이터베이스로부터, 제1 디바이스와는 상이한 모델, 만듦새, 또는 유형을 가진 제2 사용자 디바이스로 전달하는 단계 및, 제2 사용자 디바이스의 설정에 따라, 접속-데 이터-세트 중 일부를 제2 사용자 디바이스로 전달하는 단계를 더 포함한다.

사용자 디바이스의 서비스를 종료하는 서비스는 사용자 디바이스의 구성 및 설정을 삭제하는 단계, 사용자 디바이스로의 통신을 종료하는 단계, 및 사용자의 다른 디바이스에게로 종료 상태를 송신하는 단계를 포함한다. 디바이스의 서비스를 종료하는 것은 디바이스로부터 서비스를 제거하는데 적용될 뿐만 아니라, "디바이스 유실" 또는 "디바이스 도난" 시나리오에도 이용될 수 있다는 것에 주의해야 한다. 그러한 시나리오에서는, 소프트웨어 및 설정 뿐만 아니라, (메일, 첨부물, PIM, 포토 등과 같은) 사용자 데이터도 제거될 수 있다.

또한, 디바이스 종료 서비스의 다른 특징은 디바이스 블로킹(device blocking)이다. 이 시나리오에서, 사용자는 디바이스를 찾을 수 없을 뿐만 아니라, 디바이스가 유실되었는지 아니면 단지 어딘가에 두고 왔는지 확실히 알지 못하지만 여전히 디바이스가 발견될 가능성이 높다고 가정하고 있다. 이 경우, 서비스는, 사용자로부터 추가 명령이 있을 때까지, 디바이스를 블로킹하거나 적어도 디바이스로의 데이터 서비스를 일시적으로 블로킹하기 위한 기능을 사용자에게 제공한다.

도 1b는, 본 발명의 일 실시예에 따른, 도 1a의 접속-라이프 서비스를 지원하는 접속-라이프 서버를 도시한다. 접속-라이프 서버(100)는 상이한 지리적 위치의 하나 이상의 컴퓨터/서버에 의해 구현될 수 있다. 접속-라이프 서버는, 퍼스널 컴퓨터(102 및 104), 이동 디바이스(106), 서버(108), 및 웹 포털(110 및 120)을 포함하는, 사용자가 데이터를 생성하거나 저장할 수 있는 상이한 컴퓨팅 디바이스 사이에서 접속-데이터-세트를 관리한다.

도 2는 본 발명의 일 실시예에 따른 접속-라이프 서버의 디바이스 관리자 구현을 도시한다. 디바이스 관리자(200)는 웹 전단(web front-end;202), 디바이스 제어기(204), 디바이스 디스크립션 저장소(206) 및 한 세트의 프로토콜 어댑터(208)를 포함한다. 디바이스 관리자는 프로토콜 어댑터(208)를 통해 사용자 디바이스(210)와 통신하고 사용자 디바이스(210)를 관리한다. 또한, 디바이스 관리자는 사용자 관리 유닛(212) 및 스마트 컨텐츠 라우팅 유닛(214;smart content routing unit)을 통해 접속-라이프 서버 중 다른 일부와 통신한다. 사용자 관리 유닛은 상이한 서비스로부터 사용자 디바이스를 관리하는데 사용된다는 것에 주의해야 한다. 모든 사용자가 SBC-Yahoo DSL 서비스와 같은 동일한 인터넷 서비스 제공자로부터 왔다면, 이 유닛은 선택적이다.

디바이스 제어기(204)는 소프트웨어 관리 유닛(216), 서비스 관리자(218), 설정 변경 디스패처(220;settings change dispatcher) 및 디바이스 상태 저장소(222)을 더 포함한다. 소프트웨어 관리 유닛(216)은 사용자 디바이스를 위한 기록, 설정, 및 애플리케이션을 설치, 업데이트 및 설치 해제(de-install)한다. 서비스 관리자(218)는 사용자 디바이스를 위해 지원되는 서비스의 유형을 관리한다. 서비스 관리자는 사용자 디바이스 및 접속-라이프 서버 사이에서 접속-데이터-세트를 전달하기 위해 스마트 컨텐츠 라우팅 유닛(214)에게 정보를 제공한다. 설정 변경 디스패처(220)는 디바이스 설정 변경을 디바이스 관리자로부터 사용자 디바이스로 제공한다. 디바이스 상태 저장소(222)는 사용자 디바이스의 동작 상태에 관한 정보를 저장한다.

디바이스 디스크립션 저장 공간(206)은 접속-라이프 서비스에 의해 지원되는 사용자 디바이스(210)의 유형 디스크립션(224), 트랜스코딩(226;transcodings), 어카운트 템플릿(228;account templates) 및 서비스 디스크립션(230)을 저장한다. 디바이스 관리자는 그러한 디바이스 정보를 디바이스 디스크립션 저장소(206)와 파일 서버(230) 사이에서 전달한다. 디바이스 관리자는, 사용자 디바이스를 유형 디스크립션, 트랜스코딩, 어카운트 템플릿 및 서비스 디스크립션의 상이한 조합들과 연관지음으로써 조합 각각이 사용자 디바이스의 사전 정의된 그룹에 대해 테스트되고 확인될 수 있도록 한다. 결과적으로, 상이한 서비스 라인들은 대응되는 디바이스 특징을 포함하고, 서비스들은 상이한 그룹의 사용자들에게 제공될 수 있다.

프로토콜 어댑터(208)는 프로비저닝 유닛(232), 기록 교환 유닛(234), 설정 교환 유닛(236), 애플리케이션 교환 유닛(238), SyncML 유닛(240) 및 다른 어댑터 유닛(242)을 포함할 수 있다. 상술된 기능 유닛(즉, 논리 블록(200 - 244))은 소프트웨어, 하드웨어 또는 소프트웨어와 하드웨어의 조합으로 구현될 수 있다는 것에 주의해야 한다. 기능 유닛 사이의 상호 작용은 다음 섹션에서 부연설명된다.

사용자 디바이스 프로비저닝하기

일반적으로, 고객이 접속-라이프 서비스에 가입할 수 있는 2가지 방법으로는, 1) 디바이스 프로비저닝이 이후, 어카운트 등록하기; 및 2) 디바이스를 등록하고, 그로써 접속-라이프 서비스 어카운트의 등록이 (이미 활성화되어 있지 않다면) 절차에 포함되도록 하는 것이 있다.

사용자가 접속-라이프 서비스에 가입할 때의 상기 2가지 선택 중에서, 첫번째 선택은 어카운트를 등록하는 것이다. 접속-라이프 서비스는, 그들의 고객을 위해 어카운트를 유지 보수하는 서비스 제공자를 통해 제공될 것이다. 이것은 이메일 어카운트, PIM 저장소 및 관리 설비, 그리고 "서류 가방(briefcase)" 기능성( 사진, 음악, 문서, 및 다른 데이터와 같은, 사용자의 다른 파일을 위한 저장소)을 포함할 수도 있지만, 그것으로 제한되는 것은 아니다.

사용자가 접속-라이프 서비스에 의해 제공되는 서비스에 등록할 때, 사용자는 서비스를 제공중인 서비스 제공자의 이미 등록된 고객으로서 이를 수행할 것이다. 이처럼, 사용자는 접속-라이프 서비스 용도를 위해 인에이블된 어카운트를 이미 가지고 있다. 어카운트 프로비저닝의 구현은 후술된다. 그것은 다음의 섹션을 포함한다.

● 어카운트 그룹

이 섹션은 상이한 어카운트 그룹 또는 어카운트 유형을 설명한다. 상이한 어카운트 프로비저닝 사용 경우를 이해하기 위해서는 이 그룹을 알아야 한다.

● 사용 경우(Use Cases)

3가지 어카운트 프로비저닝 사용 경우가 존재한다. 다음 섹션에서 각각 설명된다.

사용자는 먼저 그들의 디바이스를 등록하는 것에 의해 어카운트를 등록하는 옵션도 가진다. 여기에서는, 디바이스 프로비저닝 프로세스의 일부로서, 어카운트가 자동적으로 생성된다.

어카운트 그룹

사용자 어카운트는 그룹으로 정렬될 수 있다. 각각의 어카운트 그룹은 한가지 이상의 방법을 사용해 프로비저닝될 수도 있다. 표 1은 접속-라이프 서비스에 의해 지원되는 샘플 어카운트 그룹을 나타낸다.

어카운트 그룹	액세스 프로토콜	설명
Exchange WebDAV	WebDAV(RFC 2518)	서버가 WebDAV를 노출시키는 임의의 Microsoft Exchange 어카운트.
IMAP	IMAP	임의의 IMAP 서버에 위치하는 메일 어카운트.
POP3	POP3	임의의 POP3 서버에 위치하는 메일 어카운트.
Outlook Redirector	REx	Microsoft Outlook에서 이메일 및 PIM 데이터에 액세스하는데 사용되는 일반적 어카운트 그룹.

사용 경우

어카운트 그룹은 3가지 상이한 방법으로 접속-라이프 서비스를 위해 프로비저닝될 수 있다. 이러한 사용 경우들은 다음 섹션에서 설명된다.

1) 미-구성 어카운트 그룹 프로비저닝하기

여기에서, 사용자가 등록할 어카운트의 세부 사항은 대부분의 경우 접속-라이프 서버(CLS)에 알려져 있지 않다. 따라서, 사용자는 이러한 세부 사항을 수동으로 입력하고, 이와 같이, 이것은 경험있는 사용자를 위한 것일 뿐이다.

2) 사전-구성 어카운트 그룹 프로비저닝하기

어카운트 그룹을 위한 기술 명세(technical specifications)가 이미 CLS에게 알려진 경우, 어카운트의 프로비저닝은, 최소량의 사용자 노력을 필요로 하면서도, 용이한 방식으로 발생할 수 있다.

3) Microsoft Outlook 프로비저닝하기

어카운트를 자신만의 PC에 배치하고 그들의 Microsoft Outlook 애플리케이션을 사용하고자 하는 사용자를 위한 것이다.

미-구성 어카운트 그룹을 프로비저닝하기 위한 전제 조건은, 사용자가 Outlook Redirector 이외의 임의의 어카운트 그룹으로부터의 어카운트를 이미 가지고 있다는 것이다. 적용 가능 어카운트 그룹은 Exchange, WebDAV, IMAP 및 POP3이다. 이러한 사용 경우에서, 사용자는 CLS에 의해 요구되는 모든 정보를, CLS가 어카운트/데이터 소스를 등록할 수 있는 순서로 특정한다. 이것은 어카운트 사용자 이름 및 패스워드 뿐만 아니라 서버의 이름 및 서버의 개개 포트 번호로서 그러한 정규 파라미터(regular parameters)를 포함한다.

이것은 3가지 모든 사용 경우 중에서 가장 복잡하므로, 경험있는 사용자에 대해서만 추천된다. 서비스 제공자가 이러한 데이터 소스 파라미터를 알지 못하는 경우, 예를 들어, 사용자가 서비스 제공자의 데이터 소스가 아닌 데이터 소스에 접속하도록 제안되는 경우에만 구현될 수도 있다.

도 3은, 본 발명의 일 실시예에 따른, 미-구성 어카운트 그룹을 프로비저닝하기 위한 작업 흐름을 도시한다. 사용자는 1) 서비스 제공자의 웹사이트에 로그인하고; 2) 적합한 어카운트 그룹을 선택하며; 3) 어카운트를 위해 필요한 모든 파라미터를 입력한다. 일단 이 단계가 완료되고 나면, CLS는 어카운트를 생성한다.

도 4는, 본 발명의 일 실시예에 따른, 사전-구성 어카운트 그룹을 프로비저닝하기 위한 작업 흐름을 도시한다. 사전-구성 어카운트 그룹을 프로비저닝하기 위한 전제 조건은, 사용자가 Outlook Redirector 이외의 임의의 어카운트 그룹으로부터의 어카운트를 이미 가지고 있다는 것이다. 적용 가능 어카운트 그룹은 서비스 제공자에 의해 제공되는 어카운트 그룹이다. 이러한 사용 경우는, 사용자가 등록을 선택하기 전에 어카운트의 명세 대부분을 알고 있다는 것에 기초한다. 첫번째 사용 경우와 달리, 이것은 사전-구성 어카운트 그룹의 프로비저닝을 포함한다. 다시 말해, 어카운트의 명세 대부분이 이미 접속-라이프 서버에게 알려져 있고, 사용자는 어카운트를 등록하기 위해 서비스 제공자에 대해 크리덴셜(credentials)을 입력할 뿐이다. 서버 이름, 포트 번호 등과 같은 명세는 타이핑될 필요가 없다.

이것은 어카운트를 프로비저닝하기 용이한 방법이다. 사용자에게는 "네, 나는 이 서비스에 가입하기를 원합니다(Yes, I want to subscribe to this service)"라는 간단한 응답을 제공할 것이 요구될 뿐이고, 나머지는 접속-라이프 서비스에 의해 핸들링된다. 사용자가 사용자의 서비스 제공자에 로그인한 후, 사용자는 그들이 접속-라이프 서비스에 등록하고자 하는 어카운트를 선택한다.

도 5는, 본 발명의 일 실시예에 따른, Microsoft Outlook을 프로비저닝하기 위한 작업 흐름을 도시한다. Microsoft Outlook을 프로비저닝하기 위한 전제 조건은, 사용자가 사용자의 PC에 Microsoft Outlook을 설치했어야 한다는 것이다. 적용 가능 어카운트 그룹은 Outlook Redirector이다.

이 옵션에 의해, 사용자는 그들의 퍼스널 컴퓨터상의 Microsoft Outlook 애플리케이션을 데이터 소스로서 가질 것을 선택할 수 있다. 어카운트가 서비스 제공자의 서버에 위치하는 사용 경우(I 및 II)와 달리, Microsoft Outlook 어카운트의 프로비저닝은 그것이 사용자 자신의 PC에 국지적으로(locally) 위치한다는 것을 의미한다.

이 방법을 사용하면, 사용자는 그들의 Exchange, IMAP, 또는 POP 어카운트를 여전히 접속-라이프 서비스 어카운트로서 가질 수 있지만, CLS는 제공자의 서버(들)가 아니라 Microsoft Outlook에 접속할 수 있다. 그것은, Outlook의 . pst 파일에 국지적으로 저장된 데이터에 접속하거나, Exchange 어카운트에 접속하기 위해 Outlook이 사용되는 경우라면, Exchange 어카운트 접속하여 이를 통해 Exchange 서버에 접속gkf 수 있다. 후자의 시나리오는 CLS와 Exchange 서버 사이의 방화벽 문제를 극복하는데 사용될 수 있다.

Microsoft Outlook을 프로비저닝하는 것은 사용자의 PC에 Outlook Redirector를 설치한다는 것을 의미한다. Redirector는 Outlook의 . pst 파일/Exchange 프로파일의 데이터와 접속-라이프 서버 사이의 매개자로서 행동한다. Outlook은, 디바이스의 데이터가 어카운트로부터 공급될 수 있는 디바이스로서 프로비저닝될 수 있다는 것에 주의해야 한다. 디바이스가 프로비저닝되는 방법에 대한 세부 사항은 다음 섹션에서 설명된다.

도 5는, 본 발명의 일 실시예에 따른, Outlook을 데이터 소스로서 등록하기 위한 작업 흐름을 도시한다. Outlook을 데이터 소스로서 등록하기 위한 작업 흐름은 다음과 같다:

1. 사용자가 서비스 제공자의 웹 사이트에 로그인한다.

2. 사용자가 Outlook Redirector 어카운트 그룹을 선택한다.

3. PC에 로더(Loader)가 설치된다.

4. 사용자가 해당 PC에 대한 사용자 이름 및 패스워드를 입력한다.

5. 어카운트가 활성화되고, 클라이언트 소프트웨어가 설치된다.

사용자는, 사용자가 그들의 어카운트 등록을 완료한 후에, 디바이스를 프로비저닝할 수 있다. 다른 방법으로, 접속-라이프 서비스는 사용자에게 그들의 디바이스 및 어카운트를 동시에 (즉, 사용자의 관점에서) 등록하기 위한 가능성을 부여한다. 그 목적은 프로비저닝 프로세스를 최대한 용이하고 간단하게 하는 것이다. 프로비저닝의 종결시에, 사용자는 그 데이터가 사용자의 디바이스(들)에 접속되는 어카운트를 갖게 된다. 디바이스 프로비저닝 프로세스에는 적어도 4개의 진입점(entry points)이 존재한다:

1. 사용자가 로더 소프트웨어를 수신한다.

2. 사용자가 웹사이트를 통해 입력한다. 사용자가 서비스 제공자의 웹사이트에 로그인할 수 있거나, 사용자를 대신해, 판매원 또는 CSR(customer service representative)이 (전화를 통해, 샵에서) 사용자를 등록시킨다.

3. 사용자가 그들의 서비스 제공자에 의해 특정된 번호로 SMS를 송신한다.

4. 사용자가 그들의 제공자의 온라인 샵에 로그인한다.

또한, 사용자는, 디바이스가 그것의 데이터 전부 또는 일부를 유실하거나 사용자가 디바이스를 유실하여 그것을 동일한 유형의 다른 디바이스로 교체하는 경우, 그들의 디바이스를 복구하는 쪽을 선택할 수 있다. 이러한 시나리오 모두는, 고객이 이미 접속-라이프 서비스를 제공하는 서비스 제공자에 등록된 사용자라고 가정한다. 또한, 이러한 시나리오 모두는, 사용자가 아직까지 접속-라이프 서비스에 가입하지 않았다면, 사용자는 사전-구성 어카운트 그룹을 프로비저닝하기 위한 사용 경우(II)에 따라 등록될 것으로 가정한다.

도 6은, 본 발명의 일 실시예에 따른, 사전-설치 로더를 통해 디바이스를 프로비저닝하기 위한 작업 흐름을 도시한다. 사용자가 그들의 디바이스를 접속-라이프 서비스에 대해 등록할 수 있는 한가지 방법은 그들의 디바이스에 로더 애플리케이션(Loader application)을 설치하는 것을 통해서이다. 로더는, 디바이스 프로비저닝 및 클라이언트 소프트웨어 설치를 용이하게 하는 애플리케이션이다.

로더는, 다운로드, CD-ROM, SD 또는 다른 메모리 카드에 의하거나 로더를 디바이스로 송신하는 다른 임의의 방법에 의한 것을 포함하는, 다양한 방법으로 사용자에게 이용 가능해질 수 있다. 로더는 특정 디바이스 유형에 대해 (버전 번호(version numbers)로) 레이블링된다. 따라서, 디바이스가 등록을 위해 CLS에 접속할 때, 서버는 디바이스 유형 및 클라이언트 소프트웨어가 설치되어야 하는지의 여부를 자동적으로 알게 될 것이다. 사전-설치 로더를 통해 디바이스를 프로비저닝하기 위한 단계는 다음과 같다:

1. 디바이스에서 로더가 시작된다.

2. 로더가 서비스 제공자 로그인 스크린을 표시한다.

3. 사용자가 그들의 어카운트 사용자 이름, 패스워드, 및 그들의 디바이스에 대한 이름(예를 들어, My Phone)을 입력한다.

4. 사용자가 아직까지 서비스 제공자의 고객이 아니라면, 사용자에게 제공자를 접촉할 것을 요청하는 메시지가 표시된다.

5. 사용자가 아직까지 접속-라이프 서비스의 가입자가 아니라면, 그들의 어카운트는 자동적으로 활성화될 것이다.

6. 일단 사용자가 그들의 어카운트 크리덴셜을 제공하고 나면, 로더는, (교환될 데이터 유형과 같은) 사전-결정된 서비스 뿐만 아니라 디폴트 필터로 구성된 클라이언트 소프트웨어를 다운로드할 것이다. 다운로드는 전파를 통하거나(over-the-air) PC 접속을 통한 것일 수 있거나, 단순히 로컬 메모리 카드로부터 전송될 수도 있다.

7. CLS는 디바이스에 대한 서비스를 활성화한다. CLS는 디바이스로부터 기존 데이터를 들여오기하고(디폴트 동작) 디바이스를 어카운트에 접속시킨다. CLS는, 기록을 CLS로부터 디바이스에게로 송신하기 전에, 어카운트에서의 기록에 필요한 임의의 복제 핸들링(duplicate handling)을 수행한다.

이제 디바이스가 프로비저닝되고 데이터를 교환하기 위한 준비를 갖추게 된다.

도 7은, 본 발명의 일 실시예에 따른, 웹사이트를 통해 디바이스를 프로비저닝하기 위한 작업 흐름을 예시한다. 이 시나리오에서, 사용자는 그들의 디바이스를 웹 브라우저를 사용해 접속-라이프 서비스에 등록한다. 이것은 다음과 같을 수 있다:

● 고객이 이용 가능한 서비스 제공자의 웹 사이트를 통해 직접적으로 사용자가 로그인한다.

● CSR을 통해. 통상적인 시나리오는 사용자가 서비스/판매 직통 전화(hotline)을 호출하는 것 또는 사용자가 서비스 제공자의 샵 중 하나를 방문하는 것을 포함하는데, 이 경우, 판매원이 고객을 대신해 고객을 등록시키는 것을 진행할 수 있다.

웹 브라우저를 사용해 디바이스를 프로비저닝하는 것에는 2가지 단계: 1) 디바이스를 사전-프로비저닝하는 단계, 및 2) 디바이스를 프로비저닝하는 단계가 존재한다. 프로비저닝 프로세스를 시작하기 전에, CLS는 어떤 종류의 디바이스가 프로비저닝될 것인지 그리고 그것이 현재 접속되어 있는 방법(PC에 의해, 무선을 통해)을 판정한다. CLS는 프로비저닝이 새로운 것인지의 여부 또는 사용자가 디바이스를 복구하기를 원하는지의 여부도 알고 있다. 디바이스 복구는, 디바이스가 유실되어 새로운 디바이스로 교체되었거나, 하드 리셋(hard reset)되어 그것의 프로그램 및 데이터를 유실하였거나, 데이터를 다른 어떤 방법으로 유실하였을 때 필요하다.

디바이스가 CLS와 교환하는 유형의 데이터를 디바이스가 유실하였거나 디바이스가 이전 구성으로 백업하지 않았다면, 디바이스 복구는 불필요하다. 전자의 경우, 정규 데이터 교환이 발생할 것이고 유실 데이터가 어카운트로부터 검색될 것이다. 후자의 경우, 느린 동기화(slow sync)가 개시되어 디바이스를 어카운트의 현재 상태로 되돌릴 것이다. 다시 말해, 클라이언트 소프트웨어가 삭제되면, 복구가 요구된다. 서버는 문제가 되는 디바이스로부터 모든 데이터를 요청하고, 모든 기록을 목록(inventory)과 비교하여 부정합(mismatches)을 식별하며, 디바이스를 목록으로부터의 기록으로 업데이트한다. 디바이스 복구가 푸시 디바이스(push devices)에 적용되는 것은 아니라는 것에 주의해야 한다.

서버가 사용자 디바이스와의 동기화를 벗어나고 서버측 목록의 백업이 복구되는 경우, 느린 동기화 프로세스는, 서버측 목록의 백업이 이루어질 때마다, 디바이스에 점검점 마커(checkpoint marker;예를 들어, 타임 스탬프)를 보유하는 것에 의해 최적화될 수 있다. 이로 인해, 서버는 점검점 마커 이후에 변경된 기록만을 비교할 수 있게 된다. 이 방법은 사용자 디바이스에게로 전송되어야 하는 데이터량을 감소시킨다. 이와 같이, 느린 동기화 프로세스의 기간을 단축시키고 느린 동기화 프로세스의 전송 대역 사용을 경감시킨다.

프로비저닝 프로세스 자체는 등록되는 디바이스 유형에 의존한다. 이 관점에서, 그것은 5개 카테고리로 분류된다:

1. 확인된 폰 번호를 갖는 푸시 디바이스.

2. 확인된 폰 번호가 없는 푸시 디바이스.

3. ActiveX-가능(ActiveX-enabled) 디바이스.

4. 클라이언트 소프트웨어를 사용하는 디바이스.

5. 고유한 동기화 스택을 사용하는 디바이스.

이 프로세스들은 다음 섹션에서 상세하게 설명된다.

웹사이트를 통해 디바이스를 사전-프로비저닝하기 위한 단계는 다음과 같다:

1. 사용자가 웹사이트를 통해 그들의 디바이스 프로비저닝을 시작할 수 있는 다수 방법이 존재한다. 사용자는 서비스 제공자의 콜센터를 호출하거나, 그들의 샵 중 하나를 방문하거나, 그들의 웹사이트를 직접적으로 브라우징할 수 있다. 모든 경우에서, 프로비저닝은 웹을 통해 수행된다.

2. 사용자가 로더를 설치하는 첫번째 사용 경우에서와 같이, 사용자가 아직까지 접속-라이프 서비스 어카운트를 가지고 있지 않다면, 자동적으로 이것이 생성된다.

3. 디바이스가 (예를 들어, 하드 리셋으로 인해) 복구되고 있다면, 디바이스는 디바이스 카테고리에 따라 프로비저닝된다.

4. 나머지 사전-프로비저닝 프로세스는, 디바이스가 현재적으로 접속되는 방법과 관련된 다수 방법인, 디바이스가 CLS에 의해 검출되는 방법에 의존한다. 도 7은 3가지 가능성을 나타낸다:

a. 디바이스를 사용하는 사용자 브라우징.

이 경우, CLS는 디바이스 유형을 검출할 것이고 사용자를 로더 다운로드 페이지로 인도할 수 있다. 다음으로, 사용자에 의해 로더가 시작되고, 프로비저닝 프로세스는 도 4에 도시된 바와 같이 계속된다.

b. PC 접속을 통해 검출되는 디바이스 유형(또는 디바이스가 PC).

여기에서는, 디바이스가 PC에 접속되거나, 프로비저닝되는 디바이스가 PC 자체이다. 관리 애플리케이션은, ActiveX 제어를 사용해, 이 접속을 통해 디바이스 유형을 검출할 수 있다. PC를 통해 접속된 디바이스들에 대해 프로비저닝이 발생할 것이다.

i. 어카운트, 서비스, 및 필터가 구성된다(사용자에 의해 부분적으로 수행되거나 완전 자동으로 수행된다).

ii. 서비스 제공자가 캐리어(carrier)가 아니라면, 디바이스에 대한 폰 번호가 입력된다. 제공자 및 캐리어가 동일하면, 번호는 이미 알려져 있다.

c. 사용자가 메뉴로부터 디바이스 유형을 수동으로 선택한다.

여기에서는, 디바이스가 무선으로 접속되거나, PC에 접속되는 경우, 어떤 원인으로 인해 디바이스가 검출될 수 없다고 가정된다. 프로비저닝 프로세스는 전파를 통하거나, 디바이스의 메모리 카드를 통해, 또는 소정의 다른 방법을 통해 발생할 수 있다.

디바이스가 자동적으로 검출될 수 없으므로, 사용자는 리스트로부터 디바이스 유형을 수동 선택한다. 일단 선택되고 나면, 어카운트, 서비스 및 필터의 사전-구성이 발생하고(상기 4.b.i. 참조), 프로세스는 거기로부터 계속된다.

5. 이제 사전-프로비저닝 프로세스는 마무리된다. 이제는, 디바이스 유형에 기초해, 프로비저닝 자체가 시작되며, 다음 섹션에서 설명된다.

다른 일례에서, 사전-프로비저닝은 디바이스를 복구하는데 사용된다. 접속-라이프 서비스는 다음과 같은 사건에서 디바이스를 복구하는 가능성을 제공한다:

● 디바이스가(도난, 유실 등으로 인해) 동일한 유형의 다른 디바이스로 교체된다.

● 디바이스가 리셋되었거나, 다른 소정의 방식으로 그것의 접속-라이프 서비스 구성을 유실하였다.

이러한 경우, 디바이스(또는 교체 디바이스)는 복구될 수 있다. 사전-프로비저닝 프로세스는 단계를 통해 진행하는데 - 사용자, 디바이스 및 그것의 선행 구성은 서버에 이미 공지되어 있다. 프로비저닝 프로세스는 디바이스 카테고리에 기초해 시작될 수 있다.

도 8은, 본 발명의 일 실시예에 따른, 확인된 폰 번호로서 웹사이트를 통해 디바이스를 프로비저닝하는 작업 흐름을 도시한다. 여기와 다음 섹션에서 설명되는 작업 흐름, 즉 "작업 흐름 - 확인된 폰 번호없는 푸시 디바이스"는 소위 "푸시" 디바이스 또는, 즉, MMS 디바이스에 적용된다. 그것은 가장 기본적인 수준의 데이터 교환을 제공하고 일방향(one-way)이다. 본질적으로, 데이터는 CLS에 의해 디바이스에게로 푸시된다. 이 데이터는 사용자에 의해 디바이스에서 변경되도록 의도된 것이 아니며, 이루어진 변경 그것이 무엇이든 CLS에게로 역송신되지 않는다. 이메일이 디바이스에게로 푸시될 수 있는 데이터 유형의 일례이다.

이러한 디바이스는, 접속-라이프 서비스와의 사용을 위해 어떤 소프트웨어도 설치될 것을 요구하지 않는다. 도 DP6에 도시된 프로비저닝 프로세스에서, 일단 사전-프로비저닝 프로세스가 마무리되고 나면, 디바이스를 위해 서비스를 활성화하고 디바이스에게로 데이터를 송신하는 것이 문제일 뿐이다. 이러한 사용 경우에서, 디바이스의 폰 번호는 CLS에 의해 이미 확인되었다. 폰 번호의 확인은, 데이터가 올바른 디바이스에게로 송신된다는 것을 보장하기 위한 보안 이유에서 수행된다.

도 9는, 본 발명의 일 실시예에 따른, 확인된 폰 번호없이 웹사이트를 통해 디바이스를 프로비저닝하는 작업 흐름을 예시한다. 이러한 사용 경우에서, 디바이스는 (앞서와 같은) 푸시 디바이스이지만, 그 폰 번호는 여전히 확인될 수 있다. 이 프로세스가 디바이스 프로비저닝의 주요 부분을 형성하고, 일단 이것이 완료되고 그것의 서비스가 활성화되고 나면, 디바이스는 실행 준비를 갖춘다. 폰 번호 확인 프로세스는 다음과 같다:

1. 사용자가 폰 번호를 입력하고 OK를 클릭하여 SMS를 송신한다.

2. SMS가 디바이스에게로 송신된다. 디바이스는 4개 숫자의 확인 번호(4-digit verification number)를 표시한다.

3. 동시에, 브라우저는 사용자가 이 확인 번호를 입력하기 위한 페이지를 연다.

4. 사용자가 확인 번호를 입력한다.

5. 일단 확인되고 나면, CLS는 다음으로 진행하여 디바이스를 위한 서비스를 활성화하고, 프로비저닝 프로세스는 마무리된다.

도 10은, 본 발명의 일 실시예에 따른, ActiveX 디바이스에 대하여, 웹사이트를 통해 디바이스를 프로비저닝하는 작업 흐름을 예시한다. 이러한 프로비저닝 작업 흐름은 다음의 디바이스에 적용된다:

● ActiveX-가능(ActiveX-enabled) 웹 브라우저를 갖춘 PC.

● 그러한 PC에 접속된 핸드헬드 디바이스.

로더는, CLS가 디바이스 유형을 검출할 수 있게 하고 클라이언트 소프트웨어를 설치할 수 있게 하는 ActiveX 제어를 포함한다. 그것은 또한, 클라이언트 소프트웨어 다운로드를 허용하면서, CLS로 디바이스를 인증한다.

도 11은, 본 발명의 실시예에 따른, 클라이언트 소프트웨어를 사용하여 웹사이트를 통해 디바이스를 프로비저닝하는 작업 흐름을 도시한다. 이 작업 흐름은, 클라이언트 소프트웨어 설치를 요구하는 디바이스에 적용된다. 절차는 다음과 같다:

1. 브라우저는 로더의 URL 뿐만 아니라 사용자를 위한 고유 PIN도 표시한다. 또한:

a. CSR에 대해, 브라우저는 임의의 다른 이용 가능 바이너리(binaries)의 URL도 표시할 것이다.

b. 개발자들에 대해, 브라우저는 CLS 설치 및 로더의 URL 뿐만 아니라 설치되어야 할 다른 바이너리의 URL을 입력하는 선택권을 개발자에게 부여한다.

2. 정규 사용자는 바로 로더 설치로 건너뛸 것이다:

a. 그것이 전파를 통해서 설치되어야 한다면, CLS는 로더에 대한 URL을 포함하는 구성 SMS를 디바이스에게로 송신할 것이다. 그것을 여는 것이 다운로드를 시작하는 것이다.

b. 디바이스가 PC에 접속되면, 로더는 자동적으로 다운로드되고 시작될 것이다.

이 단계 모두는, 인증 목적을 위해, 앞서 표시된 PIN을 입력할 것을 사용자에게 요구한다.

3. 로더가 시작된 후, 그것은 클라이언트 소프트웨어를 다운로드, 설치, 및 시작할 것이다.

4. 디바이스 서비스가 활성화될 것이고, 데이터가 (선택된다면) 디바이스로부터 들여오기될 것이며, 복제 기록이 CLS에 의해 핸들링될 것이고, 어카운트로부터의 기록이 디바이스에게로 송신될 것이다. 프로비저닝 프로세스는 마무리된다.

도 12는, 본 발명의 일 실시예에 따른, 디바이스에서의 기존 동기화 스택을 사용하여 웹사이트를 통해 디바이스를 프로비저닝하는 작업 흐름을 도시한다. 이 작업 흐름은, 자신만의 동기화 스택을 가진 디바이스, 예를 들어, SyncML 디바이스에 적용된다. 이 경우, 클라이언트 소프트웨어는 설치될 필요가 없다. 대다수 디바이스를 위한 작업 흐름은 상당히 단순하다. 서버 이름, 포트 번호 등을 특정하는 구성 SMS만이 디바이스에게로 송신되면 된다. 일단 송신되고 나면, 프로비저닝은 서비스를 활성화하고 데이터 교환을 시작하는 것에 의해 일반적 방법으로 계속된다.

디바이스가 추가 소프트웨어 설치를 필요로 하는 경우, 수반되는 절차는 기본적으로 도 9에 도시된 로더의 설치를 위한 것과 동일하다. 다시 말해:

1. 브라우저는 바이너리의 URL 뿐만 아니라 사용자에 대한 고유 PIN도 표시한다. 또한:

a. CSR의 경우, 브라우저는 임의의 다른 이용 가능 바이너리의 URL도 표시할 것이다.

b. 개발자에 대해, 브라우저는 CLS 설치 및 로더의 URL 뿐만 아니라 설치되어야 할 다른 바이너리의 URL을 입력하는 선택권을 개발자에게 부여한다.

2. 정규 사용자는 바로 바이너리 설치로 건너뛸 것이다:

a. 그것이 전파를 통해 설치되어야 한다면, CLS는 바이너리에 대한 URL을 포함하는 구성 SMS를 디바이스에게로 송신할 것이다. 그것을 여는 것이 다운로드를 시작하는 것이다.

b. 디바이스가 PC에 접속되면, 바이너리는 자동적으로 다운로드되어 시작될 것이다.

이 단계 모두는, 인증 목적을 위해, 앞서 표시된 PIN을 입력할 것을 사용자에게 요구한다.

3. 디바이스 서비스가 활성화될 것이고, 데이터가 (선택된다면) 디바이스로부터 들여오기될 것이며, 복제 기록이 CLS에 의해 핸들링될 것이고, 어카운트로부터의 기록이 디바이스에게로 송신될 것이다. 프로비저닝 프로세스는 마무리된다.

도 13은, 본 발명의 일 실시예에 따른, SMS를 통해 디바이스를 프로비저닝하는 작업 흐름을 도시한다. 이 사용 경우는, 사용자 경험의 관점에서, 간단한 프로비저닝 프로세스를 제공한다. 여기에서, 서비스 제공자는 특정 디바이스 유형을 위한 접속-라이프 서비스를 준비할 수도 있고 사용자가 SMS를 지정된 번호로 단순 송신하게 할 수도 있는데, 그 뒤, 그 어카운트는, 그것이 이미 활성화되어 있지 않다면, 접속-라이프 사용을 위해 활성화되고, 디바이스는, 최소량의 사용자 상호 작용을 요구하면서, 자동적으로 프로비저닝된다. 도 13에 표현된 (특정 분기의) 작업 흐름은 서비스 제공자의 요구 사항 및 프로비저닝될 수 있는 디바이스 유형(들)을 충족시키도록 조정될 수도 있다. 다른 방법으로는, 일반적 분기하에 도시된 바와 같이, SMS 송신시에, CLS는, 웹사이트 사용 경우를 통해 설명된 바와 같이 사용자가 디바이스를 브라우징하고 프로비저닝하기 위한 URL을 리턴할 수도 있다.

도 14는, 본 발명의 일 실시예에 따른, 온라인 샵을 통해 디바이스를 프로비저닝하는 작업 흐름을 도시한다. 이러한 프로비저닝 시나리오에서, 디바이스는 이미, 접속-라이프 서비스와의 사용을 위한 기술적 요구 사항을 충족시킨다. 사용자는 서비스 제공자에 대해 (반드시 접속-라이프 서비스인 것은 아님) 어카운트를 가지고 있다. 사용자가 수행하는 전부는 제공자의 웹사이트에 로그인하여 접속-라이프 서비스를 활성화하는 것이다. 프로비저닝은 자동으로 이루어진다.

REx ( Record Exchange ;기록 교환) 애플리케이션 프로그램 인터페이스

기록 교환 API는 SyncML(세션-기반) 프로토콜에서 사용되는 기능성을 제공하도록 설계된다. 이를 실현하기 위해, 요구되는 단계 및 그 단계를 실현하는데 사용되는 명령 수는 감소된다. SyncML 모델에서, 프로세스 흐름은 다음과 같이 설명된다:

- 인증하기

- 세션 시작하기

- 동기화 세션 초기화하기(매 데이터베이스 유형마다 동기화 유형 협상하기)

- 클라이언트가 (다수 메시지를 요구할 수 있는) 서버에게로 기록 송신하기

- 서버가 클라이언트의 데이터와 서버 사이의 동기화 수행하기

- 서버가 클라이언트의 기록에 대해 수신확인(acknowledge) (다수 메시지를 요구할 수도 있는) 클라이언트에게로 기록 송신하기

- 클라이언트가 서버의 기록을 수신확인하기

- 세션 끝

앞서 언급된 바와 같이, 전체 세션은 동기화 동작이 성공적인 것으로 생각되도록 순서에 따라 성공적으로 마무리된다. 이로 인해, 전반적인 프로세스 오류-경향은 주로 네트워크 접속성 및 디바이스 안정성 쟁점에 기인하게 된다.

기록 교환 API(Record Exchange API)는, 프로세스를, 대부분, 서로 독립적으로 수행될 수 있는 개별 동작(discrete operations)으로 분해하는 것에 의해, SyncML(세션-기반) 동기화의 무결성 문제(integrity problem)를 해결한다. 동기화의 개념은 그것의 2가지 구성 부분: 클라이언트의 관점으로부터 항목(item)을 배치하는 것과 항목을 취하는 것으로 분할되고, 초기화의 개념은 이러한 동작 중 어느 하나와 조합될 수 있다. 따라서, 프로세스의 실행(actions)을 단계적 종속 상태로 사용하는 대신에, 기록 교환 API를 사용하는 통상적 동기화는 다음과 같이 설명된다:

- 클라이언트는, 그것이 사용하고자 하는 데이터 유형을 초기화하고 항목을 송신한다. 서버는 이 요청을 위한 중간 응답을 송신한다. 서버는 그것의 응답으로, 클라이언트를 위해 보류중인 항목이 존재하는지의 여부를 나타낼 수 있다. 이 단계는, 클라이언트가 필요하다고 생각하는 횟수만큼 반복될 수 있다.

- 클라이언트는 그것이 사용하고자 하는 데이터 유형을 초기화하고 서버로부터 항목을 요청한다. 서버는 보류중인 항목을 클라이언트에게로 리턴하고, 여전히 좀더 많은 보류가 존재하는지를 지시한다. 클라이언트는 이 단계를 반복할 수 있고 수신확인 정보를 포함할 수 있다.

단 2개의 단계만이 앞서 도시되었지만, 기록 교환 API는 그러한 단계들의 상이한 부분을 수행하기 위해 상이한 펑션을 제공한다. 클라이언트 디바이스는 풋/겟(put/get) 프로세스 또는 원한다면 별도의 초기화 및 수신확인 단계를 포함하는 보다 상세한 프로세스를 사용할 수 있다. 이들 단계 각각은 다음에서 좀더 상세하게 논의된다.

도 15는 REx 프로토콜 흐름의 개요를 도시한다. 프로토콜 변경을 지원하고 좀더 오래된 디바이스와의 역방향 호환성(backward compatibility)을 제공하기 위해, 디바이스는 현재의 프로토콜 버전을 각각의 요청과 함께 URL 파라미터로서 송신한다.

기록 교환하기

REx API를 통해 교환되는 모든 항목이 어드레싱된다(addressed). 이를 실현하기 위해, REx API는 항목에 대한 고유 참조를 구비하는 수개 컴포넌트를 정의한다. 컴포넌트 모두가 모든 상황에서 사용되는 것은 아니지만, 임의의 소정 항목에 대해, 공급된 어드레싱 정보는 그 항목을 고유하게 식별하기에 충분해야 한다. REx API에서 정의되는 어드레싱 컴포넌트는 데이터 소스, 데이터 유형, 및 기록 ID이다.

이 컴포넌트 중에서, 기록 ID만이 필수적(mandatory)이다. 나머지 2개의 경우, 수행중인 동작에 그 값이 내포될 수도 있는데, 이 경우 그것은 생략될 수 있다. 데이터 소스 컴포넌트는, 클라이언트가 유효한 데이터 소스를 판정할 수 있는 능력을 가지는 경우, 클라이언트가 상이한 데이터 소스에 새로운 항목을 생성하게 하는데 사용되고, 사용자가 어떤 것을 사용할지 선택하게 하는 것을 가능하게 할 수도 있다.

이 컴포넌트의 이름은 REx API의 원래 도메인으로부터 기인하지만, 그것이 임의의 어드레싱 요구 사항에 사용될 수 있다. 예를 들어 기록 ID는, 설정 경로 펑션(setting path function)일 수 있다. 소정 데이터 유형의 경우, 기록 ID는 선택적이라는 것에 주의해야 한다. 이 경우, 기록 ID는 생략될 수도 있다. 서버로부터의 각 응답내에는, 각각의 기록 ID를 위해 하나의 항목이 존재한다.

클라이언트는 putItems 호출을 사용해 서버에게로 기록을 송신한다. 이 펑션은 ExchangeItems의 어레이를 파라미터로서 취한다. 서버는, 각각의 putItems 호출에, 보류중인 변경을 가진 데이터 유형의 어레이 및 수신 항목에 대한 수신확인을 포함하고 있는 ExchangeResult 구조로써 응답한다. 한가지 요구 사항은, putItems를 호출하기 전에 클라이언트가 서버로부터 수신된 모든 항목에 수신확인해야 한다는 것이다.

언제든 클라이언트는 getItems 요청을 송신하는 것에 의해, 보류중인 항목을 위해 서버를 쿼리(query)할 수 있다. 이 호출은 항목 캐시의 내용을 점검하고 클라이언트를 위해 보류중인 임의 기록을 리턴한다. 항목 및 상태의 최적 교환을 용이하게 하기 위해, 클라이언트는, ackAndGetItems 호출을 사용하는 것에 의해 새로운 항목을 취할 때, 수신확인 정보를 포함할 수 있다. 수신확인 정보의 포맷은 후술된다.

각각의 getItems 호출에 대한 응답으로, 서버는, 다른 것들 중에서도 보류중인 항목의 내용을 포함하고 있는 ExchangeItems의 어레이 및 어떤 데이터 유형이 검색되어야 할 항목을 더 많이 가지고 있는지를 나타내는 DataTypes의 어레이를 포함하고 있는 ExchangeResult를 리턴한다.

서버로부터 클라이언트로의 항목 흐름을 최적화하기 위해, 서버는 항상, 항목 추가 및 교체 이전에 항목 삭제를 송신할 것이다. getItems 요청의 요구 사항은 다음을 포함한다:

- 클라이언트는, getItems를 호출하기 전에, putItems를 통해 보류중인 모든 변경을 서버로 송신하고;

- 클라이언트는, 서버가 각각의 getItems 호출에 대한 응답으로 얼마나 많은 정보를 리턴할 것인지를 판정하는데 사용될 제한값(limit value)을 포함하며;

- 클라이언트는 getItems 호출 직후에 ackItems를 호출한다.

항목은 양방향으로 수신확인되어, 클라이언트 및 서버는, 항목이 언제 성공적으로 프로세싱되는지 알게 된다. ack 및 수신확인(acknowledge)이라는 용어는 본 명세서 전체에 걸쳐 상호 교환 가능하게 사용된다는 것에 주의해야 한다. getItems을 통해 항목의 수신을 수신확인하기 위한 2가지 방법이 존재하는데, 개별 ack에 의하거나 모든 ExchangeItems의 ack에 의한 것이다. 장애(failure) ack는 항상 개별 ExchangeItem의 ack를 요구하고, 그에 따라, 정확한 항목 및 장애 원인이 식별될 수 있다. 모든 ExchangeItems의 ack는, 항목이 수신확인되기 전에 수신되는 모든 항목이 성공적으로 프로세싱되는 것으로 해석되도록 핸들링된다. Ack-all-items 방법은 유효한 데이터 유형 이름을 포함한다. 이는, 교환에 관련된 데이터 유형 각각을 위해 별도의 ack-all-items가 요구된다는 것을 함축한다.

서버는 putItems 호출에 대한 응답으로 어떠한 ack 항목도 리턴하지 않는다. 대신에, 서버는 전체 putItems 호출에 대한 전반적인 결과 응답을 리턴한다. 다시 말해, putItems 호출에서의 항목의 프로세싱은 전부 또는 전무(all-or-nothing) 동작이다. 이로 인해, 클라이언트로부터 송신된 항목을 수신확인할 경우 항목 기준값(item ref value)이 사용되지 않는다. 클라이언트는, 클라이언트가 서버에게로 송신하는 ExchangeItems에서 이 값을 생략한다. 클라이언트가 가능한 빨리 ack-all-items를 송신함으로써, 서버가 클라이언트의 가장 정확한 상태 표현을 가지도록 하는 것이 장려된다.

제안된 기록 ID를 저장할 수 없거나 저장할 것을 선택하지 않은 클라이언트는 서버에 의해 제안된(일시적) LUID(Locate Unit ID)를 포함하는 맵 명령(map commands)을 역송신할 수 있고, LUID는 클라이언트에서의 기록을 표현한다. 클라이언트는, ackItems 호출에서 ExchangeItems를 전달하는 것에 의해, 맵 명령을 서버에게로 송신한다. 맵 명령은 언제든 송신될 수 있고, (통신 장애의 경우) 몇번이든 송신될 수 있으며, 항목의 암묵적 수신확인(implicit receipt acknowledgement)으로 해석되지 않는다. 클라이언트는, ID 매핑되는 항목을 위해서도 여전히 ack 항목을 명시적으로 전달할 수 있다는 것에 주의해야 한다. 클라이언트는, 클라이언트가 서버에게로 맵 명령을 송신할 때까지, 서버의 기록 ID를 사용할 수 있다.

ID를 매핑하기 위해, 클라이언트는, 항목 유형을 변경하고 데이터 멤버를 클라이언트의 LUID로 교체한 후, 서버로부터 수신된 ExchangeItems를 에코백(echo back)한다. 일 실시예에서, 서버로부터 송신된 ExchangeItem의 일례는 다음과 같이 도시된다:

클라이언트는 이와 같이 맵 명령을 리턴할 수도 있다:

기록 교환 데이터 구조

일 실시예에서, REx의 데이터 구조 일례는 다음과 같이 도시된다.

itemRef는, 서버가 그것이 클라이언트에게로 송신하는 항목을 참조하는데 사용하는 고유 식별자(unique identifier)이다. 클라이언트는 이 값을 사용해, 그것이 서버로부터 수신한 항목을 수신확인한다. itemRefs는 단조적으로 증가하는 정수값의 시퀀스이다. 서버는 데이터 유형 각각을 위한 시퀀스를 보유한다.

디바이스 또한, itemRef 값의 단조적으로 증가하는 시퀀스로써 그것이 서버에게로 송신하는 명령을 마크할(mark) 수 있다. 서버와 디바이스 사이의 접속이 중단될 때, 서버는 itemRef 값을 점검하는 것에 의해 재송신 명령을 검출하고, 이미 수신된 명령은 무시한다. 디바이스는, 그것이 itemRef 값으로써 지원하는 명령을 위한 데이터 유형 각각을 위해 itemRef 시퀀스를 유지한다. 디바이스는, 그것이 모든 또는 비명령(non-commands)을 위한 데이터 유형에 따라 itemRef 값을 송신한다는 것을 보장한다.

일 접근 방법에서, 유효한 항목 유형은 다음과 같이 열거된다:

- Add 1

- Replace 2

- Delete 3

- AddOrReplace 4 디바이스에서 서버로만 유효함

- Map 5 영구적으로 저장되지 않음

- Get 6

- Ack 7 영구적으로 저장되지 않음

- Ack All 8 영구적으로 저장되지 않음

- Query 9

- Query Result 10

- Query End 11

- Clear 12

- GetResult 15

데이터 내용:

- 추가 및 교체를 위한 데이터의 기록 내용

- (일부 선호 관리 경우에서와 같이) 삭제 동작을 수행하는데 추가 정보가 요구되지 않으면, 삭제를 위해 NULL

- 맵을 위한 기록 LUID

- Query 명령을 위한 선택적 필터

REx API는 기록 또는 데이터를 교환하기 위한 유연한 프로토콜(flexible protocol)이다. 그러나, REx API에 구축된 유연성에도 불구하고, 코어 유형 정의가, 요구되는 정보 모두를 제공하지 않는 상황이 존재할 것이다. 이러한 문제를 해결하기 위한 한가지 방법은 API가 제공하는 코어 유형 정의에 기초해 맞춤 유형(custom types)을 정의하는 것이다. REx가 XML-RPC에 기초하므로, 이것이 핸들링된다. REx API로 정의된 구조 모두는 XML-RPC 포맷의 구조로서 전송된다. XML-RPC 구조는 이름/값 쌍의 집합(collection of name/value pairs)으로 볼 수 있다. 구조를 확장하기 위해, 새로운 이름/값 쌍이 추가된다.

REx API 파서(parser)는 일반적인 XML-RPC 오브젝트를 구축하고 그것을, 프로토콜 핸들러 클래스에 상주하는 마샬러(marshaller) 펑션에게로 전달한다. 코어 REx API 펑션은 단일 프로토콜 핸들러에 상주하지만, 그것만의 목적을 위해 특수화된 펑션을 제공하면서, 전체적인 코어 REx API 펑션을 승계하는 맞춤 프로토콜 핸들러를 정의할 수도 있다. 특수화된 이 펑션은 그것이 수신하는 파라미터를 마샬링할 수 있고, 확장된 유형을 적절하게 핸들링할 수 있다. 확장된 유형의 일례는 다음과 같이 도시된다:

상기 구조는, ExchangeItem이 예상되는 어디로든 전달될 수 있지만, DMExchangeItem 유형을 이해하는 펑션 또한 dataTypeID 정보를 검색하고 사용할 수 있다.

기록 교환 상태 및 결과 코드

표 2는 유효한 교환 상태 및 결과 코드를 정의한다. 열거된 모든 값이 모든 경우에 적용 가능한 것은 아니라는 것에 주의해야 한다. 각각의 펑션에 적용되는 정확한 값을 위해서는 개별 펑션 정의를 참조한다.

		디바이스 대 서버의 수신확인 항목 결과	디바이스 대 서버의 InitRefresh 데이터 유형 교환 상태	서버 대 디바이스의 데이터 유형 교환 상태	전반적인 결과
200	OK(일반적인 성공 결과)	x		x	x
201	OK(보류중인 기록); 서버는, 그것이 변경을 가지고 있는 경우라 하더라도, 201을 송신할 것이 강제되지 않음			x
250	교환 리프레시(클라이언트는 데이터 소스 기록으로부터 복구될 것임)		x
300	디바이스는 좀비 모드에 있음				x
400	불량 요청(일반적인 요청 오류)	x		x	x
401	미지의 외부 사용자 ID(이러한 전반적 오류 코드는 요청을 서버에게로 송신하는데 보안 서블릿(security servlet)을 사용하지 않는 디바이스를 위해서만 유효함)				x
404	미지 데이터 유형	x		x
410	서버는 클라이언트 프로토콜 버전을 지원하지 않음				x
417	요구되는 리프레시(예를 들어, 동기화 앵커 부정합)			x
420	디바이스 풀(full)(디바이스가 메모리/"디스크" 공간/...을 다 써버렸음)	x
421	일시적 오류, 이후의 재시도	x
422	수신된 비-기존 항목을 위한 명령	x
423	서버는 디바이스에서 서버로의 명령 및 itemRef 값없이 디바이스-송신된 명령을 위한 itemRef 값을 요구함			x
500	일반적인 일시적 서버 오류				x

일 접근 방법으로, CLS에게 오류 상황에 관해 통지하는데 사용되는 요청과 그것의 대응되는 구조 및 응답이 후술된다. 구조는, 오류 상황이 더 이상 존재하지 않을 때, 오류를 소거하는데도 사용된다.

ErrorMessage 구조가 raiseError 및 closeError 요청에 대한 파라미터로서 송신된다. 모든 멤버가 모든 오류 및 모든 요청 방법을 위해 설정되는 것은 아니다. 각각의 오류 및 요청 방법을 위해, 멤버는 미사용(unused), 선택적(optional), 및 필수적(mandatory)으로 정의된다. 멤버 이후의 괄호 수는 멤버의 최대 길이를 정의한다는 것에 주의해야 한다.

모든 요청에 대한 응답으로서, ErrorResponse 구조가 호출 디바이스에게로 리턴된다.

각각의 요청에 대한 응답으로서, CLS는 응답 구조에서의 상태 멤버(status member)를 설정하는 것에 의해 요청의 결과를 리턴한다. 상태 멤버를 위한 값은 다음의 표 3과 같다:

이름	값	설명
OK	200	CLS는 문제없이 요청을 실행하였다.
BAD_REQUEST	400	CLS는 요청을 전혀 이해할 수 없었다. 이것은 일어나지 않을 수도 있으며 클라이언트 버그(client bug)에 대한 힌트이다.
INVALID_ARGUMENT	402	ErrorMessage 구조의 필수적 멤버가 누락중이거나 ErrorMessage 구조의 한 멤버가 무효 값, 예를 들어, 지나치게 긴 스트링으로써 설정되었다. 메시지 필드는 무효 필드의 이름을 보유할 것이다.
TEMPORORY_SERVER_ERROR	500	CLS가 일시적 문제를 가지고 있다. 디바이스는 증가하는 지연으로써 요청을 재시도할 수도 있다.

raiseError 호출은 CLS에게, 디바이스에서 오류가 발생했다는 것을 통지하는데 사용된다. ErrorResponse 요청은, 상이한 멤버가 오류 유형에 따라 설정되는 인수(argument)로서 ErrorMessage 구조를 취한다. 결과적으로, ErrorResponse 구조가 리턴된다.

ErrorResponse raiseError(ErrorMessage)

closeError 요청은, 선행 raiseError 요청에 의해 보고되는 오류를 소거한다. ErrorMessage 구조의 messageID 멤버만이 closeError 요청에 사용된다. CLS가 요청을 수신할 때, 그것은 동일한 messageID로써 앞서 보고된 오류를 소거한다.

ErrorResponse closeError(ErrorMessage)

기록 교환 펑션

이 섹션은 기록 교환 API에서의 펑션을 설명한다. 전달된 파라미터를 변경하는 펑션을 위해, 다음 규약이 사용된다:

-> 오른쪽-포인팅 화살표(right-pointing arrow)는, 값이 클라이언트에 의해 설정되고 서버에 의해서는 변경되지 않는다는 것을 지시함

<- 왼쪽-포인팅 화살표는, 서버가 클라이언트에 의해 송신된 값을 판독하지는 않지만 값을 리턴할 것을 지시함

<-> 양방향 화살표는, 서버가 클라이언트의 값을 판독할 뿐만 아니라 가능하다면 업데이트된 값을 리턴한다는 것을 지시함

기록 교환 API의 사전-교환 펑션은 checkSyncAnchors , initRefresh, 및 queryChanges를 포함한다. 사전-교환 펑션, 그것의 대응되는 포맷 및 파라미터의 설명이 다음에서 제공된다.

checkSyncAnchors: 클라이언트는 dataType 구조 내부의 데이터 유형을 위한 양자의 앵커로써 이 펑션을 호출하여, 2개의 동기화 앵커 중 하나가 서버 앵커와 정합하는지를 확인한다. 동기화 앵커 점검이 소정 데이터 유형을 위해 실패하면, 서버는 리프레시가 요구되는 결과(refresh-required result)를 리턴할 것이다. 서버에 저장된 동기화 앵커 값은 변경되지 않을 것이다.

ExchangeResult checkSyncAnchors( dataType [] DataTypes )

파라미터:

DataTypes - 어떤 데이터 유형이 점검에 사용될 것인지를 지시하는 어레이:

-> dataTypeName

-> SyncAnchor - 이 데이터 유형을 위한 현재의 디바이스 동기화 앵커.

-> pendingSyncAnchor - 이 데이터 유형을 위해 보류중인 앵커.

리턴: 각각의 dataType을 위해 특정된 적합한 exchangeStatus의 dataType 어레이를 포함하고 있는 ExchangeResult.

<- result - 서버가 요청을 성공적으로 프로세싱했을 때의 200(OK) 또는 정의된 오류 코드.

<- DataTypes는 데이터 유형을 위한 exchangeStatus - 200(OK), 201, 또는 정의된 오류 코드를 보유한다.

initRefresh: 리프레시가 요구된다고 클라이언트가 판정하거나 서버에 의해 클라이언트에게 언급되었다면, 클라이언트는 initRefresh를 호출하여 리프레시 프로세스를 시작한다.

ExchangeResult initRefresh( dataType [] DataTypes )

파라미터:

DataTypes - 어떤 DataTypes이 초기화에 사용될 것인지를 지시하는 어레이:

→ dataTypeName,

→ exchangeStatus - 250(교환 리프레시),

→ SyncAnchor - 이 데이터 유형을 위한 새로운 앵커.

리턴: 다음과 같이 채워진 ExchangeResult:

<- result - 서버가 요청을 성공적으로 프로세싱했을 때의 200(OK) 또는 정의된 오류 코드.

<- DataTypes는 원래 호출에서 특정된 데이터 유형 각각을 위한 초기 상태: 200(OK), 201, 또는 정의된 오류 코드를 지시한다.

queryChanges: 이 펑션은, 클라이언트가, 교환을 수행하기 이전에, 보류중인 임의 변경을 위해 서버를 폴링(polling)하여, 어쩌면 사용자 피드백을 제공하고자 하는 경우에 사용된다.

ExchangeResult queryChanges( dataType [] DataTypes )

파라미터:

DataTypes - 변경 쿼리에 어떤 DataTypes를 사용할 것인지를 정의하는 어레이. 공백 데이터 유형 어레이를 송신하는 것은 모든 데이터 유형을 위한 쿼리 변경일 것이다.

-> dataTypeName

리턴: 다음과 같이 채워진 ExchangeResult:

<- result - 서버가 요청을 성공적으로 프로세싱했을 때의 200(OK) 또는 정의된 오류 코드.

<- DataTypes는 어떤 DataTypes가 서버에 보류중인 변경을 가지고 있는지를 지시한다. 호출자가 공백 DataTypes 파라미터를 전달하면, 데이터 유형의 어레이 결과는 서버에 변경이 존재하는 데이터 유형만을 포함할 것이다. 호출자가 비공백 DataTypes 파라미터를 전달하면, 동일한 어레이는 각각의 데이터 유형을 위해 특정된 200(비변경), 201(보류중인 기록), 또는 417 교환 상태로써 리턴될 것이다.

기록 교환 API의 후행-교환 펑션(post-exchange functions)은 ackItems , putItems, 및 ackAndPutItems를 포함한다. 후행-교환 펑션, 그것의 대응되는 포맷 및 파라미터의 설명이 다음에서 제공된다.

ackItems: 서버로부터 항목을 수신한 후에, 클라이언트는 서버에게로 수신확인을 리턴한다. 이것은 서버에게 각 기록의 도달 상태를 통지함으로써, 서버가 클라이언트의 데이터에 대한 그것의 캐시를 효율적으로 관리할 수 있게 한다. 일 구현에서, 이 펑션은 ExchangeItems의 어레이를 사용하는데, 이는 서버가 다양한 getItems 호출로 클라이언트에게 리턴하는 것이다. 클라이언트는 itemRef 및 ExchangeItem 각각의 결과 멤버만을 특정하면 된다. 이 펑션을 사용하는 다른 방법은 Ack All로 설정된 itemType, 수신확인되는 항목의 그룹에 따라 설정된 dataType, 및 그 dataType을 위해 성공적으로 프로세싱된 마지막 항목으로 설정된 itemRef와 함께 ExchangeItem을 송신하는 것이다. 서버는 이것을, dataType의 itemRef가, 특정된 itemRef 값 이하인 그러한 dataType의 모든 항목을 위한 성공적인 수신확인으로서 해석한다. 이런 식으로 다수 ExchangeItems을 송신할 수 있다는 것에 주의해야 한다. 모든 개개 ack 항목은, itemAcks 파라미터의 ack-all-items 이전에 포함된다.

ExchangeResult ackItems( ExchangeItem [] itemAcks )

파라미터:

itemAcks - 수신확인되는 항목에 관한 정보를 포함하고 있는 ExchangeItems의 어레이. itemAcks를 위한 요구 사항은 다음과 같다:

ExchangeItem 멤버	Ack를 위한 요구 사항	Ack All을 위한 요구 사항
itemRef	예	예
itemType	예	예
result	예	선택적(200)
dataTypeName	예	예
다른 모든 것	아마도	아마도

리턴: 다음과 같이 채워진 ExchangeResult:

<- result - 서버가 요청을 성공적으로 프로세싱했을 때의 200(OK) 또는 정의된 오류 코드.

<- DataTypes - dataType 구조 어레이; 요소 각각은 exchangeStatus: 200) 또는 정의된 오류 코드를 보유중이다.

putItems: 이 펑션은 클라이언트가 서버에게로 다수 유형을 송신할 수 있게 한다.

ExchangeResult putItems ( DataType [] dataTypes , ExchangeItem [] items ):

파라미터:

DataType - 디바이스는 이 요청으로부터의 항목 어레이에 사용되는 모든 dataTypes를 위해 새로운 동기화 앵커를 송신한다.

→ dataTypeName

→ SyncAnchor - 이 데이터 유형을 위한 새로운 앵커.

items - 서버에게로 송신될 기록을 포함하고 있는 ExchangeItems의 어레이.

리턴: 다음과 같이 채워진 ExchangeResult:

<- result - 서버가 요청을 성공적으로 프로세싱하였을 때의 200(OK) 또는 정의된 오류 코드.

<- dataTypes - 요청의 데이터 유형을 위한 DataType 구조 어레이; 요소 각각은 exchangeStatus: 200, 201, 또는 정의된 오류 코드를 보유중이다.

ackAndPutItems: 이 펑션은, 클라이언트가, 새로운 항목을 배치하기 전에, 수신 유형을 수신확인할 수 있게 하는 파라미터가 추가된 putItems와 유사하다.

ExchangeResult ackAndPutItems( ExchangeItem [] acks , DataType [] dataTypes, ExchangeItem [] items )

파라미터 - 다음과 같은 것이 추가된, putItems와 유사하다:

acks - 특정 ExchangeItems를 위한 수신확인 정보를 포함한다. 서버는, 클라이언트로부터 기록을 수용하기 전에, 이 acks를 프로세싱할 것이다. 좀더 많은 정보를 위해서는 ackItems 펑션 설명을 참고한다.

리턴: putItems와 동일하다.

getItems: 클라이언트는 하나 이상의 데이터 유형을 위해 보류중인 기록을 검색하기 위해 이 펑션을 호출한다. 이것은 서버로부터 기록을 검색하는 일반적인 방법이다. 데이터 유형 각각을 위한 itemRef 값으로 인해, 서버는, 항목에서의 어떤 기록이 이미 수신된 클라이언트를 캐시하고 어떤 기록이 여전히 송신되어야 하는지를 판정할 수 있다. 클라이언트는 프로세싱된 마지막 itemRef를 이 필드로 송신할 수도 있다.

ExchangeResult getItems( DataType [] dataTypes , int limit )

파라미터:

dataTypes - 서버에게 어떤 데이터 유형을 동기화할 것인지 그리고 항목의 어떤 시점에서 기록을 송신하기 시작할 것인지를 통지하는 DataType 구조의 어레이. DataType 항목은 다음과 같이 전달된다:

-> dataTypeName - 데이터 유형의 이름.

→ syncAnchor - 이 데이터 유형을 위한 새로운 앵커.

서버는, DataType 어레이가 요소를 포함하고 있지 않을 때, getItems를 위한 요청을 무시할 것이다.

limit - 이것은 미압축 응답 XML-RPC 메시지의 최대 사이즈를 특정하는 선택적 파라미터이다. 이 값이 생략되면, 서버는 합리적이라고 생각되는 제한값을 사용할 것이다.

리턴: 다음과 같이 채워진 ExchangeResult:

<- result - 서버가 요청을 성공적으로 프로세싱했을 때의 200(OK) 또는 정의된 오류 코드.

<- dataTypes - 검색될 것으로 프로비저닝된 항목을 가진 요청으로부터의 데이터 유형 각각을 위한 DataType 구조를 포함한다. 그것은 다음과 같이 채워진다:

<- dataTypeName

<- exchangeStatus - 200(OK), 201 , 또는 정의된 오류 코드.

<- items - 다음과 같이 채워진 보류중인 기록을 포함한다:

<- itemRef

<- itemType

<- recordID - 추가 항목을 위한 임시 LUID, 다른 모든 항목 유형을 위한 클라이언트 LUID이다.

<- dataTypeName

<- data - 삭제 항목을 위해서는 생략된다.

ackAndGetItems: 이 펑션은, 클라이언트가, 새로운 항목을 취하면서, 수신 항목을 수신확인할 수 있게 하는 파라미터 추가된 getItems와 유사하다.

ExchangeResult ackAndGetItems( ExchangeItem [] acks , DataType [] dataTypes, int limit )

파라미터:

acks - 특정 ExchangeItems를 위한 수신확인을 포함하고 있다. 서버는 항목 캐시로부터 기록을 검색하기 전에, 이 acks를 프로세싱할 것이다. 좀더 많은 정보를 위해서는 ackItems 펑션 설명을 참고한다.

도 16은 상이한 REx 방법을 사용하는 사용자 디바이스와 서버 사이의 상호 작용 흐름도를 예시한다.

기록 교환 항목 유형

getItems 또는 ackAndGetItems 요청에 대한 응답으로서, 서버는 Clear 명령을 리턴할 수도 있다. 이 명령은 데이터 내용을 갖지 않으며 소정 데이터 유형 이름을 위한 모든 유형을 제거할 것을 디바이스에게 강제한다.

클라이언트 디바이스 PIM 데이터를, 초기 동기화(initial sync) 또는 dataSource로부터 쉐도우 데이터(shadow data)를 인출하는 것의 일부로서, 들여오기하는 것과 같은, 일부 상황에서, 서버는 Query 명령을 디바이스에게로 리턴하여 소정 데이터 유형을 위한 데이터를 서버에게로 업로드할 것을 디바이스에게 강제할 수 있다.

도 17은, 본 발명의 실시예에 따른, 쿼리 프로세스를 위한 순서도를 예시한다. 단계 1에서, 디바이스는 서버로부터 정보를 요청하기 위해 getItems 방법을 호출한다. getItems 또는 ackAndGetItems 요청에 대한 응답으로, 서버는 Query 명령을 리턴한다. 명령의 ExchangeItem에서, jobID 필드가 설정되어 이 쿼리를 마킹한다. 선택적인 데이터 필드는 쿼리를 한정하기 위한 필터를 포함할 수도 있다. 필터가 부여되지 않을 때, 디바이스는 소정 데이터 유형을 위한 모든 항목을 리턴할 것이다. Query 명령을 위한 ExchangeItem의 일례가 다음과 같이 도시된다:

단계 2에서, 디바이스는, 그것이 Query 명령을 수신하였다는 것을 수신확인하기 위해 ackItems를 호출한다. 단계 3에서, 디바이스는 쿼리된 데이터를 수집한다. 단계 4에서, 디바이스는 putItems를 사용해 데이터를 서버에게로 송신한다. 쿼리된 항목 각각이 하나의 QueryResult로서 송신된다. 모든 QueryResult 항목이 송신된 후, 쿼리를 위한 데이터 업로드가 수행된다는 것을 마킹하는 하나의 QueryEnd 항목이 송신된다. 모든 QueryResult 및 QueryEnd 항목은 쿼리로부터의 작업 ID(job ID)로 설정된 jobID 필드를 가짐으로써, 이 항목이 이러한 jobID를 가진 쿼리와 관련된다는 것을 지시한다. QueryResult 및 마지막 QueryEnd ExchangeItem의 일례가 다음에 도시된다:

쿼리를 위한 결과가 하나의 putItems 호출을 위해 지나치게 클 경우, 디바이스는, 다수 putItems를 사용해, 항목을 서버에게로 업로드할 수도 있다. 마지막 QueryEnd 명령은 마지막 putItems 호출로만 송신된다.

디바이스가 단계 2 이후에, 예를 들어, 디바이스 충돌 이후에, 사용자가 디바이스를 턴오프한 이후에, 또는 죽은 배터리의 교체 이후에 재시작할 때, 디바이스는 쿼리를 계속한다. 디바이스가 이미 Query 명령을 수신확인하였으므로, 서버는 이 명령을 재송신하지 않을 것이다. 따라서, 디바이스는 이 명령이 재시작에도 지속적으로 생존하게 한다. 이러한 상황을 방지하기 위해, 디바이스는 단계 4에서 ackAndPutItems를 호출하는 것에 의해 Query 명령을 수신확인할 수도 있다.

서버는 데이터 필드를 사용해 Query 명령의 일부로서 필터를 설정할 수도 있다는 것에 주의해야 한다. 일 구현에서, 서버는 dataSources를 위한 필터로서 스트링 {partial}만을 사용한다. 이 필터는 dataSource에게, 쿼리된 항목을 위한 쉐도우 정보만을 리턴할 것을 통지한다. 이것은 업로드되는 데이터량을 감소시킬 것이다. 서버가 완성 항목을 필요로 할 때, 서버는 Get 명령을 송신하여 그것을 인출할 것이다.

서버가 (부분 필터(partial filter)를 통해) 쉐도우 정보를 요청할 때, dataSource는, 메일, 연락처, 태스크, 및 이벤트 유형과 같은, 데이터의 상이한 유형을 위한 이 정보를 리턴한다.

Get 명령은, LUID를 특정하는 것에 의해, 디바이스에게, 특정 항목을 putItems를 사용해 서버에게로 업로드할 것을 요청한다. 다음은 Get 명령을 위한 ExchangeItem의 일례이다:

디바이스는 GetResult를 사용해 항목을 역송신한다. 작업 ID는 Get 및 GetResult를 접속시키는데 사용된다:

쿼리 경우처럼, 디바이스는 ackAndPutItems를 사용해 Get 명령을 수신확인하고 요청 항목을 한번의 호출로 서버에게로 송신하거나, 디바이스가 Get 명령의 결과를 영속적이게 한다는 것에 주의해야 한다. 디바이스가 비기존 항목을 위한 Get을 수신할 때, 디바이스는 422 상태 코드로써 항목을 수신확인한다.

QueryResult 명령은 디바이스에 의해 쿼리의 결과에 그리고 Get 명령에 대한 응답으로서 사용된다. dataSource가 새로운 항목을 검출할 때, dataSource는 Add 명령을 서버에게로 송신한다. dataSource가 상당량의 새로운 항목(예를 들어, dataSource쪽으로 복사된 수천통 이메일의 새로운 이메일 폴더)을 검출했을 때, dataSource는 새로운 항목 각각을 위해 쉐도우 정보만을 포함하는 QueryResult 명령을 송신한다. QueryResult 명령의 마지막 정보 부분 송신시에, QueryEnd 명령이 송신되어, 서버에게 업로드가 종료되었음을 통지한다. 서버는, 그것이 1개 항목의 완성된 정보를 필요로 할 때, Get 명령을 송신할 것이다. 이것은, 그러한 경우를 위한 데이터 송신량을 감소시킨다.

서버 및 디바이스의 동기화

접속-라이프 서버(CLS)는 서버와 하나 이상의 사용자 디바이스 사이의 데이터 동기화를 최적화한다. 구체적으로, CLS는 소정 백업 간격에 따라 서버에서 접속-데이터-세트의 백업을 생성한다. 그 다음, CLS는, 접속-데이터 세트의 백업이 생성되는 시구간을 추적하기 위한 점검점 마커를 발생시키고 점검점 마커를 접속-데이터-세트에 대한 변경의 제1 기록을 유지 보수하기 위한 하나 이상의 사용자 디바이스에게로 송신한다.

서버 및 하나 이상의 사용자 디바이스가 비동기화 상태인지의 여부를 판정하기 위해, CLS는 서버의 교체 또는 서버의 충돌을 검출한다. 다른 방법으로, CLS는 세션-기반 syncML 프로토콜 또는 (후술되는) 동기화 앵커 프로토콜을 실행하여, 서버 및 사용자 디바이스가 비동기화 상태인지의 여부를 판정할 수도 있다. 서버 및 하나 이상의 사용자 디바이스가 비동기화 상태라는 판정시에, CLS는 서버에서 접속-데이터-세트의 백업 데이터를 복구한다. 다음으로, CLS는 점검점 마커를 사용해 하나 이상의 사용자 디바이스로부터 접속-데이터-세트의 변경의 제1 기록을 요청한다. CLS는, 하나 이상의 사용자 디바이스로부터의 접속-데이터-세트의 변경의 제1 기록에 따라, 점검점 마커 이후에 변경을 가진 접속-데이터-세트의 제1 부분을 판정한다. 이것은, 하나 이상의 사용자 디바이스와 서버 사이에서 점검점 마커 이후에 좀더 새로운 타임스탬프를 가진 접속-데이터-세트의 부분을 비교하는 것에 의해 이루어진다. 그 다음, CLS는, 서버에서 변경의 제1 기록의 트랜잭션을 실행하는 것에 의해, 변경을 가진 접속-데이터-세트의 제1 부분을 업데이트한다.

마찬가지로, 서버 및 후위 데이터베이스가 비동기화 상태라는 판정시에, CLS는 서버에서 접속-데이터-세트의 백업 데이터를 복구한다. 다음으로, CLS는 점검점 마커를 사용해 후위 데이터베이스로부터 접속-데이터-세트의 변경의 제2 기록을 요청한다. CLS는, 후위 데이터베이스로부터의 접속-데이터-세트의 변경의 제2 기록에 따라, 점검점 마커 이후에 변경을 가진 접속-데이터-세트의 제2 부분을 판정한다. 이것은, 후위 데이터베이스와 서버 사이에서 점검점 마커 이후에 좀더 새로운 타임스탬프를 가진 접속-데이터-세트의 부분을 비교하는 것에 의해 이루어진다. 그 다음, CLS는, 서버에서 변경의 제2 기록의 트랜잭션을 실행하는 것에 의해, 접속-데이터-세트의 제2 부분을 업데이트한다.

동기화 앵커 프로토콜의 일차 목적은, 디바이스 및 서버가 교환 항목을 위한 동기화를 벗어났다는 것을 검출하는 것이다. 클라이언트 디바이스는 서버와 동기화할 책임을 가진다. 그러나, 클라이언트 단독으로는 검출될 수 없는 한가지 이상의 시나리오가 존재한다. 다음에서 일련의 이벤트를 고려한다:

- 클라이언트 및 서버가 포인트 A에서는 동기화 상태이다.

- 클라이언트 및 서버가 이후에 포인트 B에서도 동기화 상태지만, 실제 dataset는 포인트 A에서와 상이하다.

- 사용자는, 모든 데이터, 구성 파일 등을 포함하는, 전체 디바이스 이미지의 시스템 복구를 수행한다.

- 클라이언트가 시작될 수도 있지만, 클라이언트가 그것의 로컬 데이터를 점검할 때, 클라이언트는 그것이 포인트 B에 위치하기 때문에 모순되지 않는다고 생각한다. 그러나, 클라이언트는, 디바이스가 포인트 B에 위치한다고 가정하는 서버와 일관되지 않는다(비동기화 상태이다).

이 쟁점은 REx 동기화 앵커 프로토콜에 의해 다루어진다. 동기화 앵커에 기초해, 서버는, 서버가 더 이상 동기화 상태가 아니라는 것을 확인할 수 있고 클라이언트에게 통지할 수 있다. 이것은, 리프레시되어야 하는 데이터를 전달하기 위한 트래픽을 최소화하기 위해, 데이터베이스 각각을 위해 수행된다. 교환 항목의 유형 각각을 위해, 디바이스는 2개 앵커를 유지 보수한다. 하나는 교환 항목의 유형을 위한 현재 앵커이다. 디바이스가 서버로부터 또는 서버에게로 데이터를 요청 또는 송신할 때, 디바이스는 새로운 앵커를 발생시키고 이 데이터를 요청으로 송신한다. 요청이 오류없이 끝날 때, 디바이스는, 서버가 새로운 앵커를 성공적으로 수신하였다는 것을 인지한다. 이 경우, 디바이스는 새로운 앵커를 현재 앵커로서 저장한다.

클라이언트가 서버와의 통신을 개시할 때, 클라이언트는 checkSyncAnchors 방법을 호출하여, 디바이스 및 서버 앵커가 정합하는지의 여부를 점검한다. 그렇지 않다면, 디바이스 및 서버는 교환 항목의 이 유형을 위한 동기화를 벗어난다.

도 18은, 본 발명에 따른, 클라이언트 디바이스와 서버 사이의 동기화를 위한 동기화 앵커 프로토콜을 예시한다. 도 18에 도시된 바와 같이, 디바이스는 각각의 데이터 유형 이름을 위해 2개의 동기화 앵커를 유지 보수한다. 하나는 현재 앵커이고, 디바이스가 데이터를 송신하거나 요청하는 방법을 호출할 때, 디바이스는 요청의 데이터 유형 각각을 위해 새로운 동기화 앵커(보류중 앵커)를 발생시켜 서버에게로 송신한다. 전반적으로 성공적인 응답은, 서버가 (특정 데이터 유형을 위한 교환 상태가 성공적이지 않은 경우라 하더라도) 이 데이터 유형 이름을 위해 새로운 앵커를 취하고 저장했다는 것을 함축한다. 이 경우, 디바이스는 데이터 유형 각각을 위한 새로운 앵커를 현재 앵커로서 저장한다. 디바이스가 응답을 취하지 않거나 전반적으로 성공적이지 못한 결과 코드의 응답을 취하면, 디바이스는 보류중 앵커를 저장하고 그것을 새로운 후속 앵커로서 재송신한다.

디바이스는 현재 앵커로써 그리고, 보류중 앵커가 존재한다면, 선택적으로 보류중 앵커로써 checkSyncAnchors를 호출한다. 하나의 앵커가 서버 앵커와 정합할 때, 디바이스 및 서버는 동기화 상태이다. 이 경우 그리고 보류중 앵커가 존재할 때, 디바이스는, 서버가 보류중 앵커를 수신하였는지의 여부를 디바이스는 알지 못하므로, 앞서 송신된 현재 앵커를 현재 앵커로서 사용하고 보류중 앵커를 새로운 후속 앵커로서 송신한다.

앵커 점검이 실패할 때, 서버는 오류 상태 코드(417)를 리턴한다. 디바이스는 앵커를 초기 앵커로 역설정하고, (초기 앵커가 아닌) 새로운 앵커로써 initRefresh를 호출한다. 그 다음, 디바이스는 getItems를 호출하여, 서버가 디바이스를 위한 Clear 명령 또는 Query 명령을 가지고 있는지의 여부를 판정한다. 다음으로, 디바이스는 putItems를 통해 선택적으로 디바이스-관리 항목을 서버에게로 송신한다. 마지막으로, 디바이스는 getItems를 호출하여 서버로부터 업데이트 항목을 검색한다.

디바이스(또는 하나의 데이터 유형 이름을 담당하는 디바이스의 한 부분)가 시작될 때, 디바이스는 먼저 checkSyncAnchors를 호출하여, 디바이스 및 서버가 여전히 동기화 상태인지의 여부를 점검한다. getItems 또는 ackAndPutItems같은 방법도 요청으로부터의 데이터 유형을 위해 417 교환 코드를 리턴할 수 있다는 것에 주의해야 한다. 이 경우, 디바이스는, checkSyncAnchors를 위한 호출이 실패한 것처럼 행동한다.

디바이스가 설치 이후에 또는 미지 데이터 유형(404)의 상황 이후에 데이터 유형을 위한 초기 동기화를 시작할 때, 디바이스는 초기 동기화 앵커로서의 0로써 checkSyncAnchors를 호출한다. 디바이스가 0를 보류중 앵커로서도 송신하는지의 여부는 선택적이다. 서버 및 디바이스가 초기 동기화를 위해 동기화 상태일 것이 요구된다.

디바이스는 초기의 checkSyncAnchors 호출 이후에 getItems를 호출하고, getItems 호출의 결과로서, Clear 또는 Query 명령이 리턴된다. 디바이스는, 이러한 초기 명령이 프로세싱될 때, 변경 검출을 활성화한다.

통신의 사용자 디바이스 상태 통지

CLS는 서버와 사용자 사이의 통신에 대한 사용자 상태를 통지한다. 사용자는, CLS에 의해 유지되는 접속-데이터-세트의 부분을 공유하는 하나 이상의 사용자 디바이스를 가진다. 일 구현에서, CLS는 소정 세트의 통지 조건을 위해 서버와 하나 이상의 사용자 디바이스 사이의 통신을 모니터링한다. 소정 통지 조건의 세트가 제조자에 의해 제공되는 정보에 따라 그리고 하나 이상의 사용자 디바이스의 실제 사용을 통해 수집된 정보에 따라 형성된다. 또한, 소정 통지 조건의 세트는 접속-데이터 세트의 요소에 대한 전송 실패를 포함한다.

예를 들어, 통지 메시지는, 통지 조건이 검출되는 통신의 타이틀을 포함할 수도 있다. 통지 메시지는, 통지 조건이 검출되는 통신의 요약을 포함할 수도 있다. 더 나아가, 서버에 의해 디바이스에게로 송신되는 통지 메시지는 하이퍼링크를 포함할 수도 있다. 이 하이퍼링크는, 통지의 특징에 대해 상술하는 웹 페이지를 포인팅할 수 있거나, 사용자가 쟁점을 해결할 수 있는 (예를 들어, 후위(backend)에 액세스하기 위해 새로운 패스워드를 입력하는) 웹 페이지로 사용자를 인도할 수도 있다. 통상적으로 정보의 수개 항목만이 클라이언트 디바이스에게로 이송될 수 있기 때문에 그리고 이 방법은 대체로 통지의 특징을 설명하기 위한 다수 워드(many words)를 요구하기 때문에, 이 방법은 유용하다. 또한, 하이퍼링크는 확장 가능성을 위한 수단을 제공한다. 통지 메시지(또는 통지 스크린 또는 애플리케이션의 메뉴)에는, 브라우저를 시작하여, 이 하이퍼링크에 이어서 웹 페이지를 로드하기 위한 옵션이 존재할 수도 있다.

통지 조건이 검출될 대, CLS는 통지 메시지를 하나 이상의 사용자 디바이스에게로 송신한다. 일 구현에서, 통지 메시지는, 소정 세트의 통지 조건이 검출되는 사용자 디바이스에게로 송신될 수도 있다는 것에 주의해야 한다. 다른 구현에서는, 통지 메시지가, 소정 세트의 통지 조건이 검출되지 않는 사용자 디바이스에게로 송신될 수도 있다.

또 다른 구현에서, 소정 통지 조건의 세트는 하나 이상의 사용자 디바이스를 위한 이메일, 태스크, 캘린더, 및 주소록 오버플로우 조건을 포함할 수도 있다. 디바이스 오버플로우를 방지하기 위해, 서버는 각각의 디바이스 애플리케이션이 보유할 수 있는 데이터량을 모니터링하고 기록한다. 디바이스 제조자에 의해 제공되는 정보를 통해; 사용자 디바이스의 테스팅을 통해; 또는 실제 사용을 통해 데이터가 수집되는데, 예를 들어, 사용자 매뉴얼은 디바이스의 주소록이 최대 500개 연락처를 보유할 수 있다는 것을 특정할 수도 있고, 디바이스는 서버에 의해 송신되는 기록의 소정 갯수 이상을 저장하는 것을 거부하며, 어떤 캘린더 애플리케이션은, 이벤트의 수가 사용자 매뉴얼에서의 소정 최대 갯수를 초과하는 경우라 하더라도 여전히 동작할 수도 있다.

수집된 데이터에 기초해, 서버는 서버 인프라구조로 매 디바이스 유형 또는 애플리케이션당 상한 세트(a set of upper limits)를 정의할 수 있다. 서버는 각 디바이스에서의 실제 기록 수를 모니터링하므로, 서버는, 디바이스에서의 기록 수가 소정 상한에 접근할 때, 디바이스에게로 더 이상의 기록을 송신하는 것을 중단할 수 있다. 예를 들어, 서버는 디바이스를 90% 채워지도록 유지하여, 사용자가 여전히 일부 유용한 작업을 수행하게 할 수도 있다. 또한, 서버는 사용자에게, 디바이스에서의 (이메일 또는 캘린더와 같은) 특정 애플리케이션이 소정 상한에 도달하였다는 것을 경보할 수도 있고, 사용자에게, 특정 애플리케이션에 상이한 필터를 적용하여 기록 수를 감소시키는 것과 같은, 예방 조치를 취할 것을 요청할 수도 있다. 다른 접근 방법으로, 상이한 규칙이 상이한 데이터 유형에 적용되어, 디바이스에서의 기록량을 관리할 수도 있다. 예를 들어,

- 메일: 디바이스에게로 항상 송신될 새로운 메일에 좀더 높은 우선 순위가 할당된다. 디바이스가 새로운 메일을 위해 공간을 형성해야 한다면, 오래된 메일이 가장 오래된 것으로부터 가장 새로운 것으로의 순서로 삭제될 것이다.

- 태스크: 개방 태스크(open tasks)에 좀더 높은 우선 순위가 할당되고, 만기(due date)가 가까울수록, 좀더 중요한 태스크이다. 디바이스가 새로운 태스크를 위해 공간을 형성해야 한다면, 완료된 태스크는 가장 오래된 것으로부터 가장 새로운 것으로의 순서로 삭제될 것이다.

- 캘린더: 가까운 미래에 발생할 이벤트에 좀더 높은 우선 순위가 할당된다. 일반적으로, 미래의 이벤트가 과거의 이벤트보다 좀더 중요하다. 디바이스가 새로운 이벤트를 위해 공간을 형성해야 한다면, 과거 이벤트가 가장 오래된 것으로부터 가장 새로운 것으로의 순서로 삭제될 것이다.

- 주소록: 이미 디바이스에 위치하는 주소에 좀더 높은 우선 순위가 부여된다. 주소록이 가득차면, 서버는 새로운 어드레스를 다른 디바이스로부터 또는 후위로부터 디바이스에게로 전달하지 않을 것이다.

설정 교환( SetEx ; Settings Exchange ) 프로토콜

설정 교환(SetEx) 프로토콜은 디바이스와 서버 사이에서 설정 정보를 교환하는데 사용된다. SetEx는 데이터 구조에 대한 변경과 함께 DPREx 프로토콜에 의해 지원된다. DPREx 프로토콜과 유사하게, 데이터 내용은 설정 변경을 보유중인 XML 문서이다. XML 데이터 내용 문서의 인코딩은 항상 XML-RPC 엔빌로프(envelope)의 인코딩과 동일하다. 인코딩은 모든 유니코드 캐릭터를 표현할 수 있다. SetEx 프로토콜은 설정을 기본 URL 확장자로서 사용하는데; 예를 들어, http://server:port/dp/settings가 SetEx URL의 일례이다.

설정 교환 상태 코드

SetEx는 DPREx와 동일한 상태 코드를 사용한다. 상태 코드(300)는, 디바이스가 좀비 상태이고 서버에게로 또는 서버로부터 설정을 배치하거나 취하고자 할 때 리턴된다. 이 경우, 디바이스는 먼저 디바이스 유형 ID를 송신한다. SetEx는 새로운 상태 코드(405)를 사용한다. 이 코드는, 서버가 디바이스로부터 설정을 취할 것을 요청하는 때를 판정하기 위해, SetEx 호출에 대한 응답으로서 리턴된다.

설정 교환 프로세스 흐름

일 실시예에서, 설정 교환을 위한 프로세스 흐름은 3가지 사용 경우: 1) 초기 설정 교환; 2) 표준 설정 교환; 및 3) 덤프 설정 교환으로 설명된다.

초기 설정 교환 동안, 디바이스는 서버에 대한 그것의 디바이스 유형을 식별한다. 이 상황은, 디바이스가 처음으로 서버에 접속할 때 발생한다. 이것은, 사용자가 새로운 디바이스를 구입했을 때, 디바이스가 완전하게 리셋되었을 때, 또는 디바이스 상태가 서버측에서 좀비로 리셋되면 발생할 수 있다는 것에 주의해야 한다. 이 모든 상황에서, 디바이스는 디바이스 유형 ID 설정을 교환하는 것에 의해 시작된다. 이것은, 서버가 디바이스의 진정한 고유성(정확한 디바이스 유형 ID 정보)을 판정할 수 있게 한다. 2가지의 가능한 프로세스 흐름 시나리오가 존재한다. 제1 경우에서, 디바이스는, 그것이 처음으로 서버에 접속중이라고 생각하고, 디바이스는 디바이스 유형 ID 설정을 교환한다. 제2 경우에서, 디바이스는, 그것이 초기화되었다(동기화된 디바이스 유형 ID 설정을 가진다)고 생각하는 한편, 서버는 다르게 생각한다. 양자의 이 경우가, 다음 섹션에서 설명되는 순서도와 관련하여 논의된다.

도 19는, 본 발명의 실시예에 따른, 디바이스가 디바이스 유형 ID 설정을 교환할 때의 프로세스 흐름도를 예시한다. 도 19에 도시된 바와 같이, 단계 1에서, 디바이스는 putItems를 호출하여 디바이스 유형 ID 설정을 교환한다. 단계 1.1에서, 서버는, 디바이스를 적당하게 식별한 후, 디바이스 좀비 상태를 종료한다. 단계 1.2에서, 서버는 buildExchangeResult 방법을 호출하는 것에 의해 응답을 구축한다. 응답은 디바이스에게로 송신될 서버 상태를 포함한다. 디바이스가 디바이스 유형 ID 설정을 수신할 때 디바이스가 이미 좀비 상태를 벗어났다면, 이 동작은 영향을 미치지 않을 것이다.

도 20은, 본 발명의 실시예에 따른, 디바이스가 좀비 상태에서 디바이스 유형 ID 이외의 설정을 교환하고자 할 때의 프로세스 흐름도를 예시한다. 이 상황은, 서버에서의 디바이스 공지 상태가 좀비 상태이고 디바이스가 표준 애플리케이션 설정을 교환하고자 할 때 발생한다. 도 20에 도시된 바와 같이, 단계 1에서, 디바이스는 putItems를 호출하여 표준 설정을 교환한다. 이 경우, 서버는 오류 코드(300)로써 디바이스 요청을 거부하는데, 이는, 디바이스가 좀비 상태임을 지시한다. 단계 2에서, 디바이스는 다음으로 putItems를 호출하여, 서버가 디바이스의 고유성을 확인하여 좀비 상태를 끝낼 수 있게 하는 디바이스 유형 ID 설정을 교환한다.

표준 설정 교환의 경우에서, 디바이스는 디바이스에서 실행중인 애플리케이션을 위한 설정을 교환한다. 이 시나리오에서, 디바이스는 더 이상 좀비 상태가 아니고 디바이스와 서버 사이에서 표준 설정 교환을 수행할 수 있다.

도 21은, 본 발명의 실시예에 따른, 표준 설정 교환을 위한 순서도를 예시한다. 도 21에 도시된 바와 같이, 단계 1에서, 디바이스가 설정을 변경했다면, 디바이스는 putItems 방법 호출을 사용해 그것을 서버에게로 송신한다. 디바이스는, 디바이스가 송신할 좀더 많은 설정을 가지고 있는 한, 이 단계를 반복한다.

디바이스가 서버로부터 서버에서 이용 가능한 보류중인 설정 변경을 위한 통지를 수신하면, 그것은 getItems 호출을 발행하여 설정 변경을 검색한다. 디바이스를 위해 이용 가능한 보류중인 설정이 서버에 존재하지 않으면, 이 단계는 생략될 수도 있다는 것에 주의해야 한다.

서버가 좀더 많은 설정 변경이 존재한다는 201 데이터 유형 상태 코드를 통해 플래그되었다면, 디바이스는 ackAndGetItems 방법 호출을 발행한다. 이 경우 디바이스는 서버로부터의 마지막 응답에서 수신된 설정을 수신확인하고 서버에서의 보류중인 설정 변경을 요청한다.

마지막으로, 모든 설정 변경이 디바이스에 의해 서버로부터 인출된 후, 디바이스는 ackItems 호출을 발행한다. ackItems 방법은, 서버가, 서버로부터 송신되는 변경된 설정과 연관되는 임의 리소스를 소거할 수 있게 한다.

상술된 프로세스 흐름에서는, 업데이트중인 설정 사이에 차이점이 존재하지 않는다. 주된 차이점은, 동작이 상이함에도 불구하고, 데이터 내용이다. 다음에 주의해야 한다:

1. 공백 설정 문서에 의한 삭제는 전체 데이터베이스를 삭제한다.

2. 모든 설정 및 삭제 데이터 내용 문서에 남겨지는 그러한 설정의 서브-트리(sub-trees)가 삭제된다.

3. 삭제 데이터 내용에서 노드로서 마킹된 설정은 서브-트리를 삭제하지 않는다.

예를 들어, 기존 트리는 다음과 같다:

a/b/m

a/b/n

a/c/

m 및 n을 삭제하기 위해, 서브-노드를 특정할 수도 있다. m 및 n을 삭제하기 위한 SetEx 데이터 내용은 다음과 같다:

<Node name= "a">

<Leaf name= "b"></Leaf>

</Node>

서브-노드 b는 삭제된 데이터 내용에서 리프(leaf)로서 특정된다. 결과적 트리는 다음과 같다:

a/c

리프를 삭제하는 것은 흔치 않다. 내부 노드(interior nodes)는 시맨틱(semantic)을 갖지 않는다는 것에도 주의해야 한다. 상기 스키마 일례로부터, 트리(a/c)는 (a/b, a/c)와 동일한데, b는 내부 노드이고 시맨틱을 갖지 않기 때문이다. 따라서, 리프(a/b/m 및 a/b/n)를 삭제하는 것은 상기 일례에서 a/b를 삭제하는 것과 시맨틱하게(semantically) 동일하다. 리프 노드 삭제 일례는 다음과 같다:

<Node name="a">

<Node name="b">

<Leaf name="m"></Leaf>

<Leaf name="n"></Leaf>

</Node>

</Node>

결과적 트리는 다음과 같다:

a/c

구현을 간략화하기 위해, 데이터 내용 명세(data content specs)는, 삭제가 특정 서브-노드에 대해서만 허용된다고 정의할 수도 있다. 상기 일례를 위한 데이터 내용 한정은, 리프에 대한 삭제는 허용되지 않으면서, a/b에 대한 삭제만이 허용된다는 것일 수도 있다.

덤프 설정 교환

덤프 설정 교환의 경우, 디바이스는 SetEx 방법 호출을 발행한다. 서버는, 그것이 디바이스로부터 모든 설정을 취하는 것과 유사한지를 판정한다. 이 방법은 주로, 디바이스로부터 모든 데이터를 취하는 것에 의해, 디바이스가 서버가 예상하는 상태에 있는지를 테스트하거나 점검하는데 사용된다. 이것이 발생할 때, 서버는 특수한 오류 코드(405)로써 응답한다. 오류 코드에 대한 응답으로, 디바이스는 이것을 발생시킨 데이터 유형에 관한 설정 정보를 덤핑하기 시작한다.

도 22는, 본 발명의 실시예에 따른, 덤프 설정을 위한 순서도를 예시한다. 디바이스는 putItems 호출을 호출하여 표준 설정을 교환한다. 서버가, 디바이스에게, 소정 데이터 유형을 위한 모든 공지 설정을 덤핑할 것을 요구하는 상태에 있다면, 서버는 소정 데이터 유형을 위해 405 코드를 리턴한다. 이것은, 디바이스가 getItems 호출을 개시할 때에도 발생할 수 있다는 것에 주의해야 한다.

디바이스는 initRefresh(코드 251)를 호출하여, 서버에게 그것이 덤프 설정 교환을 시작했다는 것을 통지한다. 디바이스는, 서버에 의해 송신되는 것에 주의할 것이 요구되는 덤프에 대한 응답으로 putItems 요청을 발행한다. 이 상태에서, 디바이스는 그것이 포함하고 있는 모든 설정을 서버에게로 덤핑한다. 이 단계는, 디바이스가, 덤핑되어야 할 좀더 많은 설정을 가지고 있는 한, 반복된다.

설정 교환 데이터 구조

이 섹션은 코어 디바이스 프럭시 기록 교환(DPREx;device proxy records exchange) 데이터 구조에 대한 향상을 설명한다. ExchangeItem 구조는 설정 교환을 지원하도록 변경될 수도 있다. 특히, 어떤 값이 ExchangeItem에서의 itemType 및 recordID 필드를 위한 SetEx 프로토콜에서 허용되는지에 대한 제한이 존재한다.

일 구현에서, itemType 데이터 구조는 Delete 및 Replace 동작을 지원한다. 설정 교환의 경우, 설정이 존재하지 않고 다른 방법으로 업데이트하면, Replace는 Add를 의미하도록 재정의된다. recordID 필드는 설정 교환을 위해 생략된다.

디바이스가 설정을 요청하지만 메시지 사이즈를 소정 사이즈 미만이도록 제한할 때, SetEx 내용은 소정 사이즈 미만이도록 분할된다. 분할은 리프 노드에 기초한다. 예를 들어, 메시지 사이즈가 0으로 설정되면, 매 요청당 하나의 리프 노드만이 전송된다. 본 구현이 이 정의에 의해서는 어떤 이점도 없이 지나치게 복잡하다는 것이 대체적이다. 구현을 간략화하기 위해, 설정을 노드 레벨에 대해 그룹화할 수 있다. 데이터 내용의 일례는 a/b/c, a/b/d, a/b/e, 및 a/m/c로서 도시된다.

그룹화가 a/b/를 위해 가능해지면, a/b/c, a/b/d, 및 a/b/e가, 메시지 사이즈에 상관없이, 하나의 메시지로서 전송된다는 것이 보장된다. 이 메시지가 다른 설정도 포함할 수 있다는 것에 주의해야 한다. 설정을 정의하는 것은 데이터 내용 스펙에 달려 있다.

다음 섹션은, 샘플 설정 데이터 내용을 포함하고 있는 XML-RPC 프레그먼트를 나타낸다. 일 구현에서, ExchangeItem의 데이터 필드에서의 설정 트리 데이터 내용은 디바이스 유형 ID 설정을 교환하는데 사용된다. 6개의 상이한 디바이스 유형 ID 설정이 사용되고, 그것은 Mod, Hint1, Hint2, Hint3, Hint4, 및 Hint5이다. 여기에서, Mod는 디바이스 모델을 표현하고, 대부분의 경우, 디바이스를 고유하게 식별하는데 사용될 수 있다. Hint1 내지 Hint5는, Mod 스트링에 포함되어 있는 정보 이외에, 디바이스 유형을 식별하기 위한 정보를 포함한다.

다음의 devTypeIdent XML 스키마는, 어떤 데이터가 허용되는지를 정의한다. 이 경우를 위한 데이터 유형 이름은 s- devTypeIdent라는 것에 주의해야 한다.

다음은 이메일 폴더 설정을 교환하기 위해 설정 트리 데이터 내용을 호출하는 getItems를 위한 서버 응답의 일례를 나타낸다.

SetEx에서, Clear 명령이, 선행 설치 또는 데이터베이스 활성화의 흔적을 소거하기 위한 제일 첫 명령으로 사용되지는 않는다. 따라서, 디바이스가 SetEx 데이터 유형을 위한 제1 동기화(앵커 0에 의한 checkSyncAnchors 호출)를 수행할 때, 디바이스는 자체적으로 소거 프로세스(cleanup process)를 개시한다. 서버가 디바이스에게, SetEx 요청에 대해 교환 상태(417)를 리턴하는 것에 의해, initRefresh 호출을 수행할 것을 강제할 때에도, 동일한 초기-동기화 규칙이 적용된다.

설정 교환 펑션

이 섹션은, getItems , putItems , ackItems, 및 initRefresh를 포함하는, DPREx 펑션에 대한 변경된 정의의 리스트를 포함하고 있다. getItems 및 putItems의 경우, 다음의 제한이 적용되는데: recordID 필드는 사용되지 않고, Replace 및 Delete만이, 리턴된 ExchangeItem 인스턴스에서의 itemType 필드를 위해 지원된다. ExchangeItem의 데이터 필드는 설정 데이터 내용을 포함하고 있다.

ackItems의 경우, 다음의 제한이 적용되는데: recordID 필드는 사용되지 않고, Ack 및 AckAll만이, 리턴된 ExchangeItem 인스턴스에서의 itemType 필드를 위해 지원된다. 이 경우, 데이터 필드는 사용되지 않는다.

initRefresh 방법은 2가지 경우로 디바이스에 의해 호출될 수 있다. 첫번째, 그것은 서버에게, 서버 경보에 대한 응답으로, 디바이스가 디바이스에게 공지되어 있는 모든 설정의 덤프를 시작할 것이라는 것을 통지하는데 사용된다. 이것은 디바이스에게 공지되어 있는 데이터 유형 각각을 위한 상태 코드(251)로써 표현되는 ExchangeAll을 특수한 교환 상태로 송신하는 것에 의해 수행된다. 두번째, 디바이스는 getItems 호출 이후에 서버에서의 모든 공지 설정을 검색하고 싶어 한다. 디바이스는, 데이터 유형 각각을 위해 상태 코드(251)로써 표현되는 상태 INIT_REFRESH를 송신하는 것에 의해 이를 실현한다.

애플리케이션 교환 프로토콜

애플리케이션 교환 프로토콜은 디바이스와 서버 사이에서 소프트웨어 변경을 교환하는 프로세스를 정의하는데 사용된다. 애플리케이션 교환 기능성은, XML_RPC의 상단에 새로운 프로토콜을 정의하는데 필요한 기록 및 설정 교환과는 상당히 상이하다. 애플리케이션 교환(AppEx) 소프트웨어를 위한 프로토콜 흐름, 데이터 구조, 및 펑션이 다음 섹션에서 설명된다. AppEx 프로토콜은 apps를 기본 URL 확장자로서 사용하고 버전 번호 및 외부 사용자 ID를 URL 파라미터로 사용한다. AppEx URL의 일례는 다음으로서 도시된다.

http://www.verdisoft.com/dp/apps?extID=2347dhji34&version=1.0.1

애플리케이션 교환 프로세스 흐름

도 23은, 본 발명의 실시예에 따른, 디바이스와 서버 사이의 애플리케이션 교환 프로세스 흐름의 순서도를 예시한다. 도 23의 소프트웨어 교환 프로세스 흐름에서의 일련의 단계가 다음에서 설명된다:

1) 디바이스는 서버에게, 이용 가능 애플리케이션 변경을 요청한다. 서버는 이용 가능 변경을 가진 모든 애플리케이션을 위한 설정 정보의 리스트를 리턴한다. 서버가 소프트웨어 변경을 가지고 있지 않을 때, AppEx 프로세스는 종료한다.

2) 디바이스는 설정 정보를 프로세싱하고 소프트웨어 변경을 실행하는 것을 시작할 때를 판정한다.

3) 디바이스는 애플리케이션 설정을 개시한다. 서버는 디바이스가 실행하기 위한 설정 명령의 리스트로써 응답한다.

4) 디바이스는 설정 명령을 프로세싱하고 애플리케이션 설정을 위해 요구되는 파일을 다운로드한다. 파일 다운로드에 실패하면, 디바이스는 나머지 파일을 다운로드하는 것을 중단한다. 그것은 성공적으로 다운로드된 소프트웨어를 설치한 다음, 순차적 deviceSetupStarts 및 적합한 오류 코드의 deviceSetupEnds를 사용해, 서버에게 다운로드에 실패했다는 것을 통지한다.

5) 디바이스는 서버에게, 애플리케이션 설정 프로세스가 디바이스에서 시작될 것을 통지한다. 이 정보는 서버에 의해, 디바이스에서 변경된 소프트웨어와 연관된 모든 예전 서비스를 무효화하는데 사용된다. 서버는, 디바이스에게 getApplicationUpdates를 호출하는 것을 시작으로 전체 프로세스를 시작할 것을 강제하기 위한 특수한 상태 코드(301)로써 응답할 수도 있다. 하나의 설정 명령이 실패할 때, 디바이스는 나머지 명령의 실행을 중단한다.

6) 디바이스가 애플리케이션을 시작한다.

7) 애플리케이션은 서버에게, 그것이 설치된다는 것을 통지한다. 서버는 이 호출을 사용해 디바이스를 위한 설정을 스케줄링한다.

8) 디바이스는 서버로부터 필요한 설정을 인출한다.

9) 애플리케이션은 선택적 요청을 통해 서버에게, 그것이 자체-테스트를 위한 프로비저닝을 갖추었다는 것을 통지한다. 서버는 일부의 소정 테스트 데이터를 이 애플리케이션을 위해 활성화한다.

10) 디바이스는 서버에게, 디바이스에서의 설정 프로세스가 특정 애플리케이션을 위해 완료되었다는 것을 통지한다. 요청의 일부로서, 디바이스는 새로운 소프트웨어 동기화 앵커를 송신한다.

11) 애플리케이션은 선택적 요청을 통해 서버에게, 그것이 사용될 준비를 갖추었다는 것을 통지한다.

애플리케이션 교환 데이터 구조

이 섹션은, 디바이스와 서버 사이의 소프트웨어 애플리케이션 교환에 사용되는 XML_RPC 데이터 구조를 설명한다. 애플리케이션 교환 데이터 구조는 SetupInfo, SetupInfoItem, SetupCommand, NameValuePair, 및 AppExResult를 포함한다.

SetupInfo 구조는, 디바이스가 서버에게 이용 가능 소프트웨어 변경을 요청할 때 사용된다. 서버는, 디바이스를 위해 이용 가능한 소프트웨어 업데이트를 표현하는 SetupInfo 인스턴스를 리턴한다.

데이터 멤버:

description: 이것은 필수적 필드이고 인간-판독 가능(human-readable)하다. 그것은 전체 소프트웨어 업데이트를 설명하고, 사용자에게 업데이트를 수용할 것이 요청된다면, 디바이스에 의해 사용자를 위한 대화 상자에 메시지를 표시하는데 사용된다.

setupSize: 이것은, 애플리케이션 업데이트를 위한 공간 요구 사항을 특정하는 필수적 필드이다.

sunshineDate; 이것은, 소프트웨어가 업데이트될 수 있는 시점을 특정하는 선택적 필드이다. 포맷은 UTC이다. 디바이스가 소프트웨어를 제시간에 설치하지 않았을 때, 서버로의 액세스는 거부될 수 있다. 이 필드가 누락될 때, 디바이스는 소프트웨어 변경을 즉각적으로 프로세싱하고; 그렇지 않으면, 사용자에게, 사용자가 지금 아니면 나중에 업데이트하고 싶어하는지가 질문될 것이다.

setupInfoItems: 이것은 선택적 필드로서, 소프트웨어 변경이 존재할 때의 SetupInfoItem 구조의 어레이이다.

SetupInfoItem 구조는 SetupInfo 구조 내부에 사용된다. SetupInfoItem 각각은 디바이스를 위해 이용 가능한 소프트웨어 변경을 표현한다.

데이터 멤버:

setupType: 이것은 필수적 필드이고, 상수(INSTALL=1, UPDATE=2, 및 UNINSTALL=3) 중 하나를 포함할 수 있다.

additionalDescription: 이것은, 이 설정 항목을 위한 디스크립션이 SetupInfo에서의 전체적인 디스크립션과는 독립적이고 그것에 추가적이며, 사용자에게 추가적으로 제시된다는 것을 특정하는 선택적 필드이다. 이 플래그가 존재하지 않거나 거짓이면, 사용자에게 디스크립션은 제시되지 않는다.

setupInfoId: 이것은, 디바이스를 위한 애플리케이션 설정 변경을 고유하게 식별하는 필수적 필드이다.

description: 이것은, 소프트웨어 변경을 설명하는 선택적 필드이다.

SetupCommand 구조는 설정 명령을 소프트웨어 변경의 일부로서 디바이스에게로 송신하는데 사용된다. SetupCommand 구조 및 그것의 대응되는 데이터 멤버의 일례가 다음에서 설명된다.

데이터 멤버:

setupType: 이것은 필수적 필드이고, 상수(INSTALL=1, UPDATE=2, 및 UNINSTALL=3) 중 하나를 포함한다.

itemRef: 이것은 필수적 필드이다. SetupCommand 어레이의 SetupCommand 요소는 증가하는 항목 참조 번호로써 마킹된다. 이 항목 참조는 일부 펑션에서 어레이로부터 SetupCommand 요소를 식별하는데 사용된다.

URL: 이것은, 다운로드할 설정 명령 또는 파일을 위한 URL을 특정하는 선택적 필드이다. 이 필드는 일반적으로 디폴트로 설정된다. 그러나, 일부 플랫폼에서, 소프트웨어가 설치 해제를 위해 다운로드될 필요는 없다.

CRCStr: 이것은 선택적 필드이고 CRC-32 체크섬 정보(check sum information)를 포함한다. CRC는 디바이스에 의해 CRC에 기초한 소프트웨어 다운로드를 캐시(cache)하는데 사용될 수 있거나, 다운로드 파일의 유실 여부를 점검하는데 사용될 수도 있다.

programId: 이것은 필수적 필드이고, 설정되는 애플리케이션 프로그램을 고유하게 식별하는 ID를 포함한다.

NameValuePairs: 이것은 선택적 필드이고 NameValuePair 데이터 구조를 특정한다.

NameValuePair 구조는 SetupCommand 구조의 일부로서 사용된다. NameValuePair 구조는 이름/값 쌍의 파라미터를 특정하는데 사용된다. 이 파라미터는 이 설치에 대해 특정적이고 특정 소프트웨어 및/또는 디바이스 유형을 위해 필요한 정보, 예를 들어, 명령 라인 파라미터를 전달하는데 사용된다.

AppExResult 구조는 방법 요청의 결과를 리턴하는데 사용된다. 이것은 애플리케이션 교환에 관한 정보를 포함한다.

데이터 멤버:

SetupInfo: 이것은 선택적 필드이고 애플리케이션 설정 정보를 디바이스에게로 리턴하는데 사용된다. 이 필드는, 디바이스가 getApplicationUpdates를 호출할 경우에만 리턴된다.

setupCommands: 이것은 선택적 필드이고, 애플리케이션 변경(설치, 업데이트, 또는 설치 해제)과 연관된 설정 명령을 리턴하는데 사용된다. 이 필드는, 디바이스가 initiateApplicationUpdates를 호출할 때 리턴된다.

result: 이것은 필수적 필드이고, 애플리케이션 교환 방법 요청의 결과를 포함한다.

애플리케이션 교환 펑션

이 섹션은 디바이스와 서버 사이에서 애플리케이션 교환을 수행하는데 사용되는 펑션을 설명한다. AppEx 펑션은 checkSyncAnchors , getApplicationUpdates , initiateApplicationUpdates, deviceSetupStarts , deviceSetupEnds , applicationInstalled, applicationReadyToTest , applicationReadyToGo, 및 initRefresh를 포함한다. 일부 펑션은 서버에게로 오류 코드를 송신할 수 있다. 일 구현에서, 오류 코드는 다음의 표 5에서 정의된다.

코드	이름	설명
0	OK	오류가 발생하지 않았다.
1	ERR_CANT_GET_RESPONSE	서버가 호출에 응답하지 않았다.
2	ERR_CANT_DOWNLOAD_FILE	컴포넌트가 파일 서버로부터 파일을 다운로드할 수 없었다.
3	ERR_CANT_WRITE_FILE	다운로드된 파일을 컴포넌트가 저장할 수 없다.
4	ERR_RAN_OUT_OF_DISKSPACE	(현재 플랫폼 수단을 위한 어떤 디스크이든) 디스크 공간이 바닥났다.
5	ERR_RAN_OUT_OF_MEMORY	메모리가 바닥났다.
200	ERR_SETUP_FAILED	설정 프로그램에 장애가 발생하였다.

ERR_CANT_DOWNLOAD_FILE 또는 ERR_RAN_OUT_OF_DISKSPACE같은 디바이스 로컬 오류(divice local errors)의 경우, 디바이스는, 서버에게로 오류를 보고하기 전에, 오류를 수정하기 위한 가능한 모든 단계를 시도한다(예를 들어, 사용자에게 인터넷 접속을 점검하거나 하드 드라이브를 청소할 것을 요청한다). 디바이스가 오류 코드를 송신하여 현재 소프트웨어 변경의 문제점을 보고할 때, 서버는 디바이스를 디스에이블(disable)한다.

checkSyncAnchors는 디바이스가 시동할 때마다 사용되는데; 이것은 디바이스에게 공지되어 있는 현재의 소프트웨어 앵커를 송신한다. 디바이스가 보류중인 앵커를 가질 경우, 이것은 보류중인 앵커 또한 서버에게로 송신한다. 다른 방법으로, 디바이스가 보류중인 앵커를 가지고 있지 않을 때, 서버에게로 송신되는 보류중인 앵커는 존재하지 않는다. 서버는 수신된 앵커를 서버에 저장된 앵커와 비교하여, 디바이스와 서버가 비동기화 상태인지의 여부를 판정한다.

AppExResult checkSyncAnchors( String anchor , String pendingAnchor )

리턴: 앵커가 정합할 때의 결과는 200이고 앵커 부정합이 존재할 때의 결과는 417인 AppExResult의 인스턴스.

getApplicationUpdates 방법은 디바이스를 위해 이용 가능한 모든 애플리케이션 업데이트의 리스트에 관한 정보를 리턴한다.

AppExResult getApplicationUpdates( String anchor )

리턴: 소프트웨어 변경이 이용 가능할 때 SetupInfo 구조를 포함하는 AppExResult의 인스턴스. 그렇지 않으면, SetupInfo 멤버는 설정되지 않는다.

파라미터:

● anchor - 디바이스는 새로운 앵커를 송신한다.

initiateApplicationUpdates 방법은 서버로부터 명령어의 리스트를 취하기 위한 디바이스에 의해 호출되어, 애플리케이션 변경(설치, 업데이트, 또는 설치 해제) 프로세스를 시작한다. 서버에 의해 리턴되는 정보는 디바이스로 다운로드될 파일 및 디바이스에서 실행될 명령을 포함한다. 디바이스는 리턴된 설정 명령에서 열거된 순서로 애플리케이션 변경 명령을 실행한다.

AppExResult initiateApplication Updates( String [] setupInfoIds )

리턴: SetupCommand 어레이를 포함하는 AppExResult의 인스턴스.

파라미터:

● setupInfoIds - 디바이스가 getApplicationUpdates 응답으로부터의 setupInfoIds를 송신하는 파라미터.

deviceSetupStarts 방법은 서버에게, 디바이스에서 애플리케이션 설정이 시작되었다는 것을 통지한다. 이것은, 서버가 변경되고 있는 소프트웨어와 연관된 오래된 모든 서비스를 무효화하는 것을 가능하게 한다. 한편, 디바이스가 애플리케이션 업데이트 프로세스를 개시한 이후에 그리고 이 펑션 호출 이전에, 새로운 애플리케이션 업데이트가 서버에 추가되었다면, 서버는 새로운 애플리케이션 업데이트가 존재한다는 것을 지시하는 오류 코드(301)를 리턴한다. 이것이 발생했을 때, 디바이스는 애플리케이션 업데이트 프로세스를 재시작한다.

AppExResult deviceSetupStarts ()

리턴: 결과 코드(301)를 발행하여 디바이스가 AppEx 프로세스를 재시작한다는 것을 지시할 수도 있는 AppExResult의 인스턴스.

디바이스가 이 방법을 요청하고 서버로부터 응답을 다시 취하지 않을 때, 디바이스는 요청이 서버에 의해 수신되었는지의 여부 또는 서버로부터의 응답이 유실되었는지의 여부를 알지 못한다. 이 경우, 디바이스는 이 방법을 위한 새로운 요청으로써 재시도한다. 응답이 유실되었다면, 이것이 420 오류 코드를 초래할 수 있다는 것에 주의해야 한다.

deviceSetupEnds 방법은 서버에게, 디바이스에서의 애플리케이션 설정이 완료되었음을 통지한다. 서버는 그 사이에 서버에서 좀더 많은 소프트웨어 변경이 스케줄링되었는지의 여부를 점검하고 필요하다면 새로운 통지를 송신한다.

AppExResult deviceSetupEnds( String anchor , int itemRef , int errorCode , String errorMsg )

파라미터:

● anchor - 디바이스는 현재적으로 설치된 소프트웨어를 표현하는 새로운 앵커를 송신한다.

● itemRef: 이 파라미터는 2가지 방법으로 사용될 수 있다:

첫번째, itemRef는, 설정 명령 어레이의 위치 "N"에서의 명령 및 그 위치 "N" 미만의 다른 모든 명령이 성공적이고 다른 모든 명령은 실행되지 않는다는 것을 특정한다.

두번째, itemRef는, itemRef에 의해 특정된 위치, 예를 들어 "M"에서의 명령을 위한 설정이 실패하였고, "M" 미만의 오프셋을 가진 다른 모든 명령은 성공적이며, "M"보다 큰 오프셋의 모든 명령은 실행되지 않는다는 것을 지시한다.

● errorCode - 오류의 경우, 여기에서 오류의 원인이 열거된다. 그렇지 않으면, "OK" 코드가 리턴된다.

● errorMsg - 이 파라미터는 상세한 오류 메시지를 특정한다. 성공의 경우, 이 필드는 널(null)이다.

리턴: AppExResult의 인스턴스.

이 방법은 표준 동작에 따라 호출된다. 현재의 AppEx 프로세스가 AppEx 코드를 포함하는 프로그램을 설치 해제하면, 디바이스는, 디바이스가 설치 해제를 시작하기 직전에 이 방법을 호출한다.

applicationInstalled 방법은 서버에게, 애플리케이션이 설치 또는 업데이트되었음을 통지한다. REx API 또는 SetEx API를 사용하는 모든 애플리케이션은 필수적으로 디바이스와 서버 사이에서 데이터를 동기화해야 한다. 이 방법의 일차 용도는 프로그램 업데이트를 위한 것이다. 서버는 이 방법을 호출하여, 업데이트된 소프트웨어에 의해 사용되는 설정을 활성화한다.

AppExResult applicationInstalled( String programId , int errorCode , String errorMsg )

파라미터:

● programld - 서버측에서의 애플리케이션 서비스를 고유하게 식별한다.

● errorCode - 오류의 경우, 여기에서 오류의 원인이 열거된다. 그렇지 않으면, OK 코드가 리턴된다.

● errorMsg - 상세한 오류 메시지를 특정한다. 성공적인 애플리케이션 설치의 경우, 이 필드는 널이다.

리턴: AppExResult의 인스턴스.

applicationReadyToTest 방법은 서버에게, 일부 테스트를 수행하여 서버가 정확하게 동작하는지의 여부를 점검하고자 한다는 것을 통지한다. 서버는 이 방법을 사용해 일부 테스트 데이터를 활성화한다.

AppExResult applicationReadyToTest( String programld , int errorCode , String errorMsg )

파라미터:

● programId - 서버측에서의 애플리케이션 서비스를 고유하게 식별한다.

● errorCode - 오류의 경우, 여기에서 오류의 원인이 열거된다. 그렇지 않으면, "OK" 코드가 리턴된다.

● errorMsg - 상세한 오류 메시지를 특정한다. 성공의 경우, 이 필드는 널이다.

리턴: AppExResult의 인스턴스.

applicationReadyToGo 방법은 서버에게, 사용할 준비를 갖추었다는 것을 통지한다. applicationInstalled 또는 applicationReadyToTest를 호출하는 프로그램 각각은 applicationReadyToGo 방법을 호출할 것이 요구된다.

AppExResult applicationReadyToGo( String programId , int errorCode , String errorMsg )

파라미터:

● programId - 서버측의 애플리케이션 서비스를 고유하게 식별한다.

● errorCode - 오류의 경우, 여기에서 오류의 원인이 열거된다. 그렇지 않으면, "OK" 코드가 리턴된다.

● errorMsg - 상세한 오류 메시지를 특정한다. 성공의 경우, 이 필드는 널이다.

리턴: AppExResult의 인스턴스.

initRefresh 방법은, 디바이스가 서버에게, 디바이스가 디바이스의 모든 소프트웨어를 재설치하고자 한다는 것을 통지할 때 사용된다. 서버가 이 요청을 수신할 때, 서버는 설치를 위해 디바이스에 위치할 수 있는 모든 소프트웨어를 마킹한다. 디바이스가 이 호출로부터 성공적인 응답을 수신할 때, 디바이스는 완전한 AppEx 프로세스를 수행하여 명령을 검색한다.

AppExResult initRefresh ()

리턴: AppExResult의 인스턴스.

서버는, 그것이 디바이스를 위한 소프트웨어 변경을 가지고 있을 때, 통지를 송신한다. 디바이스가 getApplicationUpdates를 호출할 때, 서버는, 디바이스가 통지를 수신했다고 가정하고 서버측에서 통지를 소거한다. 이것은, 디바이스가, 사용자가 소프트웨어 변경을 연기하는 경우 및 디바이스가 재시작된 경우 모두에 모순되지 않는 getApplicationUpdates의 결과를 형성한다는 것을 의미한다. 디바이스가 AppEx 프로세스의 중간에 통지를 수신하면, 디바이스는 통지를 무시할 수도 있다. 디바이스가 deviceSetupEnds를 호출하여 AppEx 프로세스를 종료하면, 서버는 좀더 많은 소프트웨어 변경이 존재하는지의 여부를 점검하고 필요하다면 새로운 통지를 송신한다.

애플리케이션 교환 상태 코드

설정 교환에서, 디바이스가 좀비 모드일 때, 상태 코드(300)가 리턴된다. 이 경우, 디바이스는 먼저 디바이스 프로비저닝 프로토콜을 사용해 디바이스 유형 ID를 송신함으로써 좀비 모드를 벗어난다.

deviceSetupStarts 방법을 위한 호출은, getApplicationUpdates를 호출하는 것에 의한 시작으로부터 전체 AppEx 프로세스를 시작할 것을 디바이스에게 강제하는 301 결과 코드를 리턴할 수 있다. getApplicationUpdates를 위한 호출은, 서버가 현재적으로, 소프트웨어 변경이 존재하는지의 여부를 판정할 수 없을 때 302 결과 코드를 리턴할 수 있다. 이것은, 서버가 새롭게 설치 또는 업데이트된 소프트웨어 프로그램이 applicationInstalled 및/또는 applicationReadyToGo를 호출할 것을 대기할 때 발생할 수 있다. 이 경우, 디바이스는 증가된 지연으로써 이후에 수차례 요청을 재시도한다. 수차례 재시도 이후에, 서버가 여전히 302 상태 코드로써 응답하면, 디바이스는 전체 AppEx 프로세스를 종료하고 그저 후속 통지를 대기한다.

checkSyncAnchors 방법을 위한 호출은, 서버가 디바이스에 존재할 수 있다고 생각하는 소프트웨어와 디바이스의 소프트웨어가 상이하다는 것을 지시하는 417 결과 코드를 리턴할 수 있다. 서버로의 각 호출은 오류 코드(500)를 초래할 수도 있다. 이것은, 서버가 이 순간 어떤 원인에서든 디바이스 호출에 응답할 수 없다는 것을 지시하는 일시적 서버 오류이다. 데이터 내용은 서버에 의해 조사되지 않았으므로, 데이터 내용이 잘못되었다고 생각되지는 않는다. 클라이언트는 이전과 동일한 간격을 사용해 동일한 요청을 재시도한다. 소정 횟수의 재시도 이후에, 클라이언트는 재시도를 종결하고, 통지 또는 폴링 타임아웃(polling timeout)과 같은, 후속의 표준 동기화 이벤트를 대기할 수도 있다.

소프트웨어 동기화 앵커

소프트웨어 동기화 앵커는, 서버가 디바이스에 존재할 수 있다고 생각하는 소프트웨어와 디바이스의 소프트웨어가 상이한 때를 검출하는데 사용된다. 이것은, 사용자가 전체 디바이스를 백업하고자 할 때 발생할 수 있다. 이 상황에서, 디바이스의 소프트웨어는, 디바이스가 백업으로부터 복구되기 이전에 서버를 통해 디바이스에 설치된 소프트웨어와 호환이 불가능할 수도 있다.

디바이스와 서버 모두가 동일한 소프트웨어 동기화 앵커 값으로 초기화되어, 시작시에 디바이스와 서버가 동기화 상태라는 것을 보장한다. 디바이스는 동기화 앵커를 구동한다. 디바이스가 getApplicationUpdates 또는 deviceSetupEnds를 호출할 때마다, 디바이스는 앵커를 저장하는 서버에게로 새로운 앵커를 송신한다. 디바이스가 서버로부터 호출에 대한 성공적인 응답을 수신할 때, 디바이스는 현재 앵커를 서버에게로 송신된 새로운 앵커로 교체한다. getApplicationUpdates 또는 deviceSetupEnds를 위한 호출이 실패할 때, 디바이스는, 서버가 요청을 수신하였는지 그리고 새로운 앵커를 저장하였는지의 여부를 알지 못한다. 따라서, 디바이스는, 디바이스가 요청을 다시 호출하고자 시도할 때, 보류중인 새로운 앵커를 재송신한다.

시작할 때마다, 디바이스는 checkSyncAnchors를 사용해 현재 앵커를 서버에게로 송신한다. 디바이스가 deviceSetupEnds 호출을 위해 성공적 응답을 취하지 못한 보류중인 새로운 앵커를 가지고 있을 때, 디바이스는 이 앵커를 checkSyncAnchors 호출에 대한 파라미터로서 송신한다. 서버는 송신된 앵커(또는 송신된 앵커들)를 서버가 디바이스로부터 수신한 마지막 앵커와 비교한다. 앵커가 정합하지 않을 때, 디바이스는 문제점을 사용자에게 보고하고 initRefresh를 호출하여 스크래치(scratch)로부터 완전한 소프트웨어 설치를 시작한다.

애플리케이션 교환 상태

서버는 소프트웨어 설치, 설치 해제, 또는 업데이트 프로세스 동안 2가지 상태 중 하나일 수 있다. 도 24는, 본 발명의 실시예에 따른, 애플리케이션 교환 상태 전이도를 예시한다. 디바이스가 불법적인 방법(illegal method)을 호출할 때, 오류 상태는, 서버가 이 호출에 대한 응답으로서 420 상태 코드를 리턴하게 한다. 그후, 상태 머신은, 그것이 오류 상태로 전이된 이전 상태로 복귀한다.

오류 상태를 벗어나기 위해, 디바이스는 getApplicationUpdates를 호출하여 전체 애플리케이션 교환 프로세스를 재시작할 수도 있다. 그것을 위해, 디바이스는 오류 코드(예를 들어, 200) 및 itemRef로서의 -1로써 deviceSetupEnds를 호출한다. 그 다음, 그것은 앞서 중단된 프로세스에 관한 소거 상태(clean state)로부터 새로운 AppEx 프로세스를 시작한다.

애플리케이션 교환 설치 및 업데이트

디바이스가 AppEx를 통해 소프트웨어를 설치 또는 업데이트할 때, 설치 또는 업데이트 실패가 발생할 수도 있다. (디바이스가 충돌되었으므로) 변경이 설정 프로그램에 의해 완전하게 원래 수준으로 회복되지 않았을 때, 소프트웨어는 더 이상 사용 불가능할 수도 있다. 디바이스가 디바이스에서 AppEx를 수행하는 소프트웨어를 업데이트하고자 시도한다면, 이것이 결정적이다.

디바이스가 여전히 서버에 의해 AppEx를 실행할 수 있다면, 디바이스는 AppEx 프로세스가 수반되는 initRefresh 방법을 호출하여 모든(그리고 그렇게 파괴된) 소프트웨어 프로그램을 디바이스에 재설치하는 것을 시도할 수도 있다. 디바이스가 더 이상 AppEx 프로그램을 실행할 수 없다면, 디바이스는, 디바이스 유형 ID 정보와 같은, 디바이스 역량을 송신하기 위한 로더를 사용해 URL을 다시 원격 설치자에게로 전달한다. 이 호출은, 서버측의 모든 소프트웨어 프로그램이 재설치를 위해 마킹된다는 것을 함축한다. 디바이스는 원격 설치자를 설치한 다음 AppEx를 사용해 소프트웨어 프로그램을 재설치한다.

명료화를 위한 상기 설명은 상이한 기능 유닛 및 프로세서를 참조하여 본 발명의 실시예를 설명하였다는 것을 알 수 있을 것이다. 그러나, 본 발명에서 벗어나지 않으면서, 상이한 기능 유닛과 프로세서 사이의 기능성의 적당한 임의 분배가 사용될 수도 있다는 것이 명백할 것이다. 예를 들어, 별도 프로세서 또는 제어기에 의해 수행될 것으로 예시된 기능성이 동일한 프로세서 또는 제어기에 의해 수행될 수도 있다. 따라서, 특정 기능 유닛에 대한 참조는, 엄격한 논리적 또는 물리적 구조 또는 편성을 지시하는 것이 아니라, 단지 설명된 기능성을 제공하기 위한 적당한 수단에 대한 참조로서 생각되어야 한다.

본 발명은, 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 임의 조합을 포함하는, 적당한 임의 형태로 구현될 수 있다. 본 발명은 선택적으로, 하나 이상의 데이터 프로세서 및/또는 디지털 신호 프로세서에서 실행중인 컴퓨터 소프트웨어로서 부분적으로 구현될 수도 있다. 본 발명의 실시예의 요소 및 컴포넌트는 임의의 적당한 방법으로 물리적, 기능적, 및 논리적으로 구현될 수도 있다. 실제로, 기능성은 단일 유닛으로, 복수개 유닛으로, 또는 다른 기능 유닛의 일부로서 구현될 수도 있다. 그에 따라, 본 발명은 단일 유닛으로 구현될 수 있거나 상이한 유닛과 프로세서 사이에 물리적으로 그리고 기능적으로 분배될 수도 있다.

당업자라면, 여전히 동일한 기본적 기초 메커니즘 및 방법을 이용하면서, 개시된 실시예의 가능한 다수 변경 및 조합이 사용될 수도 있다는 것을 알 수 있을 것이다. 상기 설명은, 설명의 목적을 위해, 특정 실시예를 참조하여 기재되었다. 그러나, 상기한 예시적 논의는 개시된 정확한 형태로 본 발명을 총망라하거나 제한하기 위한 것이 아니다. 상기 교수의 관점에서 다수 변경 및 변형이 가능하다. 실시예는, 본 발명의 원리 및 그것의 실질적인 적용을 설명하고 당업자라면 본 발명을 그리고 다양한 실시예를 예상되는 특정 사용에 적합한 다양한 변경으로써 가장 잘 이용할 수 있도록 하기 위해, 선택되고 설명되었다.

Claims (36)

1. 통신 네트워크에서 하나 이상의 사용자 디바이스를 접속시키기 위해 다수의 진입점(entry points)을 제공하기 위한 시스템으로서,

   상기 하나 이상의 사용자 디바이스와 통신하기 위한 서버 - 상기 서버는 접속-데이터-세트를 포함하고, 상기 하나 이상의 사용자 디바이스는 상기 접속-데이터-세트의 일부를 공유함 - ;

   상기 다수의 진입점 중 하나로부터의 상기 접속-데이터-세트에 액세스하기 위한 요청을 사용자 디바이스로부터 수신하기 위한 로직;

   상기 사용자 디바이스의 속성(attributes)을 자동으로 판정하기 위한 로직;

   상기 사용자 디바이스의 상기 속성을 사용하여, 소정 클라이언트 디바이스의 데이터베이스로부터 통신 방법을 선택하기 위한 로직; 및

   상기 통신 방법에 따라 상기 사용자 디바이스를 프로비저닝하기(provisioning) 위한 로직

   을 포함하는 시스템.
2. 제1항에 있어서,

   상기 하나 이상의 사용자 디바이스는,

   적어도 하나 이상의 셀룰러폰, 무선 PDA(personal digital assistants), 네비게이션 디바이스, 퍼스널 컴퓨터, 게임 콘솔, 인터넷 터미널 및 키오스 크(Kiosks)를 포함하는 시스템.
3. 제1항에 있어서,

   상기 접속-데이터-세트는,

   적어도 하나 이상의 이메일, 연락처(contacts), 캘린더, 태스크, 메모, 사진, 음악, 문서, 비디오, 북마크 및 링크를 포함하는 시스템.
4. 제1항에 있어서,

   상기 서버는,

   다수의 지리적 위치에 분산된 하나 이상의 컴퓨터 및 데이터 저장 시스템을 포함하는 시스템.
5. 제1항에 있어서,

   상기 속성은,

   디바이스 유형 디스크립션(description);

   서비스 디스크립션;

   트랜스코딩; 및

   어카운트 템플릿(account templates)을 포함하는 시스템.
6. 제1항에 있어서,

   상기 사용자 디바이스를 프로비저닝하기 위한 로직은,

   SMS 기반 프로비저닝을 수행하기 위한 로직;

   디바이스 브라우저 기반 프로비저닝을 수행하기 위한 로직;

   실행 가능 프로그램 기반 프로비저닝을 수행하기 위한 로직; 및

   ActiveX 기반 프로비저닝을 수행하기 위한 로직을 포함하는 시스템.
7. 제6항에 있어서,

   상기 SMS 기반 프로비저닝을 수행하기 위한 로직은,

   크리덴셜(credential)을 요청하는 상기 사용자 디바이스로 URL을 송신하기 위한 로직 - 상기 크리덴셜은 이메일 어드레스 및 패스워드를 포함함 - ;

   상기 사용자 디바이스로부터 상기 크리덴셜을 수신하기 위한 로직; 및

   상기 사용자 디바이스로부터의 상기 크리덴셜의 확인시, 상기 사용자 디바이스로 프로비전 SMS(provision SMS)를 송신하기 위한 로직을 구비하는 시스템.
8. 제6항에 있어서,

   상기 디바이스 브라우저 기반 프로비저닝을 수행하기 위한 로직은,

   크리덴셜을 요청하는 상기 사용자 디바이스로 새로운 디바이스 지시자를 송신하기 위한 로직 - 상기 크리덴셜은 폰 번호를 포함함 - ;

   상기 사용자 디바이스로부터 상기 크리덴셜을 수신하기 위한 로직; 및

   상기 사용자 디바이스로부터의 상기 크리덴셜의 확인시, 상기 사용자 디바이 스로 프로비전 SMS를 송신하기 위한 로직을 포함하는 시스템.
9. 제6항에 있어서,

   상기 실행 가능 프로그램 기반 프로비저닝을 수행하기 위한 로직은,

   상기 사용자 디바이스가 SDK 디바이스인지의 여부를 판정하기 위한 로직;

   상기 사용자 디바이스를 구성하고 크리덴셜을 요청하기 위해 실행 가능 프로그램을 상기 사용자 디바이스로 송신하기 위한 로직 - 상기 크리덴셜은 폰 번호를 포함함 - ;

   상기 사용자 디바이스로부터 상기 크리덴셜을 수신하기 위한 로직; 및

   상기 사용자 디바이스로부터의 상기 크리덴셜의 확인시, 상기 사용자 디바이스로 구성을 다운로드하기 위한 로직을 포함하는 시스템.
10. 제9항에 있어서,

    상기 구성을 다운로드하기 위한 로직은,

    컴퓨터 프로그램을 설치하기 위한 로직;

    필터를 적용하기 위한 로직; 및

    상기 접속-데이터-세트로의 접속을 적용하기 위한 로직을 포함하는 시스템.
11. 제6항에 있어서,

    상기 ActiveX 기반 프로비저닝을 수행하기 위한 로직은,

    상기 사용자 디바이스가 ActiveX 가능(ActiveX enabled)인지의 여부를 판정하기 위한 로직;

    상기 사용자 디바이스가 ActiveX 가능이면, 상기 사용자 디바이스에 ActiveX 로더를 설치하기 위한 로직; 및

    상기 사용자 디바이스에서 상기 ActiveX 로더를 실행하기 위한 로직을 포함하는 시스템.
12. 제6항에 있어서,

    상기 사용자 디바이스를 프로비저닝하기 위한 로직은,

    상기 사용자 디바이스에 대한 서비스를 활성화하기 위한 로직;

    상기 사용자 디바이스로부터 데이터를 들여오기 위한 로직;

    상기 사용자 디바이스를 소정 어카운트에 접속시키기 위한 로직;

    복제 기록(duplicate records)을 핸들링하기 위한 로직; 및

    기록을 상기 사용자 디바이스로 송신하기 위한 로직을 더 포함하는 시스템.
13. 통신 네트워크에서 하나 이상의 사용자 디바이스를 접속시키기 위해 다수의 진입점을 제공하기 위한 방법으로서,

    상기 하나 이상의 사용자 디바이스와 통신하기 위한 서버를 제공하는 단계 - 상기 서버는 접속-데이터-세트를 포함하고, 상기 하나 이상의 사용자 디바이스는 상기 접속-데이터-세트의 일부를 공유함 - ;

    상기 다수의 진입점 중 하나로부터의 상기 접속-데이터-세트에 액세스하기 위한 요청을 사용자 디바이스로부터 수신하는 단계;

    상기 사용자 디바이스의 속성을 자동으로 판정하는 단계;

    상기 사용자 디바이스의 속성을 사용하여, 소정 클라이언트 디바이스의 데이터베이스로부터 통신 방법을 선택하는 단계; 및

    상기 통신 방법에 따라 상기 사용자 디바이스를 프로비저닝하는 단계를 포함하는 방법.
14. 제13항에 있어서,

    상기 하나 이상의 사용자 디바이스는,

    적어도 하나 이상의 셀룰러폰, 무선 PDA, 네비게이션 디바이스, 퍼스널 컴퓨터, 게임 콘솔, 인터넷 터미널 및 키오스크를 포함하는 방법.
15. 제13항에 있어서,

    상기 접속-데이터-세트는,

    적어도 하나 이상의 이메일, 연락처, 캘린더, 태스크, 메모, 사진, 음악, 문서, 비디오, 북마크 및 링크를 포함하는 방법.
16. 제13항에 있어서,

    상기 서버는,

    다수의 지리적 위치에 분산된 하나 이상의 컴퓨터 및 데이터 저장 시스템을 포함하는 방법.
17. 제13항에 있어서,

    상기 속성은,

    디바이스 유형 디스크립션;

    서비스 디스크립션;

    트랜스코딩; 및

    어카운트 템플릿을 포함하는 방법.
18. 제13항에 있어서,

    상기 사용자 디바이스를 프로비저닝하는 단계는,

    SMS 기반 프로비저닝을 수행하는 단계;

    디바이스 브라우저 기반 프로비저닝을 수행하는 단계;

    실행 가능 프로그램 기반 프로비저닝을 수행하는 단계; 및

    ActiveX 기반 프로비저닝을 수행하는 단계를 포함하는 방법.
19. 제18항에 있어서,

    상기 SMS 기반 준비를 수행하는 단계는,

    크리덴셜을 요청하는 상기 사용자 디바이스로 URL을 송신하는 단계 - 상기 크리덴셜은 이메일 어드레스 및 패스워드를 포함함 - ;

    상기 사용자 디바이스로부터 상기 크리덴셜을 수신하는 단계; 및

    상기 사용자 디바이스로부터의 크리덴셜의 확인시, 상기 사용자 디바이스로 프로비전 SMS를 송신하는 단계를 구비하는 방법.
20. 제18항에 있어서,

    상기 디바이스 브라우저 기반 프로비저닝을 수행하는 단계는,

    크리덴셜을 요청하는 상기 사용자 디바이스로 새로운 디바이스 지시자를 송신하는 단계 - 상기 크리덴셜은 폰 번호를 포함함 - ;

    상기 사용자 디바이스로부터 상기 크리덴셜을 수신하는 단계; 및

    상기 사용자 디바이스로부터의 크리덴셜의 확인시, 상기 사용자 디바이스로 프로비전 SMS를 송신하는 단계를 포함하는 방법.
21. 제18항에 있어서,

    상기 실행 가능 프로그램 기반 프로비저닝을 수행하는 단계는,

    상기 사용자 디바이스가 SDK 디바이스인지의 여부를 판정하는 단계;

    상기 사용자 디바이스를 구성하고 크리덴셜을 요청하기 위해, 실행 가능 프로그램을 상기 사용자 디바이스로 송신하는 단계 - 상기 크리덴셜은 폰 번호를 포함함 - ;

    상기 사용자 디바이스로부터 상기 크리덴셜을 수신하는 단계; 및

    상기 사용자 디바이스로부터의 상기 크리덴셜의 확인시, 상기 사용자 디바이스로 구성을 다운로드하는 단계를 포함하는 방법.
22. 제21항에 있어서,

    상기 구성을 다운로드하는 단계는,

    컴퓨터 프로그램을 설치하는 단계;

    필터를 적용하는 단계; 및

    상기 접속-데이터-세트로의 접속을 적용하는 단계를 포함하는 방법.
23. 제18항에 있어서,

    상기 ActiveX 기반 프로비저닝을 수행하는 단계는,

    상기 사용자 디바이스가 ActiveX 가능인지의 여부의 판정하는 단계;

    상기 사용자 디바이스가 ActiveX 가능이면, 상기 사용자 디바이스에 ActiveX 로더를 설치하는 단계; 및

    상기 사용자 디바이스에서 상기 ActiveX 로더를 실행하는 단계를 포함하는 방법.
24. 제18 항에 있어서,

    상기 사용자 디바이스를 프로비저닝하는 단계는,

    상기 사용자 디바이스에 대한 서비스를 활성화하는 단계;

    상기 사용자 디바이스로부터 데이터를 들여오는 단계;

    상기 사용자 디바이스를 소정 어카운트에 접속시키는 단계;

    복제 기록을 핸들링하는 단계; 및

    상기 사용자 디바이스로 기록을 송신하는 단계를 더 포함하는 방법.
25. 적어도 프로세싱 유닛, 사용자 인터페이스 및 메모리를 갖춘 하나 이상의 컴퓨터 시스템에 의해 실행되기 위한 컴퓨터 프로그램을 저장하는 매체를 포함하는 통신 네트워크에서 하나 이상의 사용자 디바이스를 접속시키기 위해 다수의 진입점을 제공하기 위한 컴퓨터 프로그램 제품으로서,

    서버 및 상기 하나 이상의 사용자 디바이스 사이에서 통신하기 위한 코드 - 상기 서버는 접속-데이터-세트를 포함하고, 상기 하나 이상의 사용자 디바이스는 상기 접속-데이터-세트의 일부를 공유함 - ;

    상기 다수 진입점 중 하나로부터의 상기 접속-데이터-세트에 액세스하기 위한 요청을 사용자 디바이스로부터 수신하기 위한 코드;

    상기 사용자 디바이스의 속성을 자동으로 판정하기 위한 코드;

    상기 사용자 디바이스의 속성을 사용하여, 소정 클라이언트 디바이스의 데이터베이스로부터 통신 방법을 선택하기 위한 코드; 및

    상기 통신 방법에 따라 상기 사용자 디바이스를 프로비저닝하기 위한 코드를 포함하는 컴퓨터 프로그램 제품.
26. 제25항에 있어서,

    상기 하나 이상의 사용자 디바이스는,

    적어도 하나 이상의 셀룰러폰, 무선 PDA, 네비게이션 디바이스, 퍼스널 컴퓨터, 게임 콘솔, 인터넷 터미널 및 키오스크를 포함하는 컴퓨터 프로그램 제품.
27. 제25항에 있어서,

    상기 접속-데이터-세트는,

    적어도 하나 이상의 이메일, 연락처, 캘린더, 태스크, 메모, 사진, 음악, 문서, 비디오, 북마크 및 링크를 포함하는 컴퓨터 프로그램 제품.
28. 제25항에 있어서,

    상기 서버는,

    다수의 지리적 위치에 분산된 하나 이상의 컴퓨터 및 데이터 저장 시스템을 포함하는 컴퓨터 프로그램 제품.
29. 제25항에 있어서,

    상기 속성은,

    디바이스 유형 디스크립션;

    서비스 디스크립션;

    트랜스코딩; 및

    어카운트 템플릿을 포함하는 컴퓨터 프로그램 제품.
30. 제25항에 있어서,

    상기 사용자 디바이스를 프로비저닝하기 위한 코드는,

    SMS 기반 프로비저닝을 수행하기 위한 코드;

    디바이스 브라우저 기반 프로비저닝을 수행하기 위한 코드;

    실행 가능 프로그램 기반 프로비저닝을 수행하기 위한 코드; 및

    ActiveX 기반 프로비저닝을 수행하기 위한 코드를 포함하는 컴퓨터 프로그램 제품.
31. 제30항에 있어서,

    상기 SMS 기반 프로비저닝을 수행하기 위한 코드는,

    크리덴셜을 요청하는 상기 사용자 디바이스에게로 URL을 송신하기 위한 코드 - 상기 크리덴셜은 이메일 어드레스 및 패스워드를 포함함 - ;

    상기 사용자 디바이스로부터 상기 크리덴셜을 수신하기 위한 코드; 및

    상기 사용자 디바이스로부터의 크리덴셜의 확인시, 상기 사용자 디바이스로 프로비전 SMS를 송신하기 위한 코드를 포함하는 컴퓨터 프로그램 제품.
32. 제30항에 있어서,

    상기 디바이스 브라우저 기반 프로비저닝을 수행하기 위한 코드는,

    크리덴셜을 요청하는 상기 사용자 디바이스로 새로운 디바이스 지시자를 송신하기 위한 코드 - 상기 크리덴셜은 폰 번호를 포함함 - ;

    상기 사용자 디바이스로부터 상기 크리덴셜을 수신하기 위한 코드; 및

    상기 사용자 디바이스로부터의 상기 크리덴셜의 확인시, 상기 사용자 디바이스로 프로비전 SMS를 송신하기 위한 코드를 포함하는 컴퓨터 프로그램 제품.
33. 제30항에 있어서,

    상기 실행 가능 프로그램 기반 프로비저닝을 수행하기 위한 코드는,

    상기 사용자 디바이스가 SDK 디바이스인지의 여부를 판정하기 위한 코드;

    상기 사용자 디바이스를 구성하고 크리덴셜을 요청하기 위해, 실행 가능 프로그램을 상기 사용자 디바이스로 송신하기 위한 코드 - 상기 크리덴셜은 폰 번호를 포함함 - ;

    상기 사용자 디바이스로부터 상기 크리덴셜을 수신하기 위한 코드; 및

    상기 사용자 디바이스로부터의 크리덴셜의 확인시, 상기 사용자 디바이스로 구성을 다운로드하기 위한 코드를 포함하는 컴퓨터 프로그램 제품.
34. 제33항에 있어서,

    상기 구성을 다운로드하기 위한 코드는,

    컴퓨터 프로그램을 설치하기 위한 코드;

    필터를 적용하기 위한 코드; 및

    상기 접속-데이터-세트로의 접속을 적용하기 위한 코드를 포함하는 컴퓨터 프로그램 제품.
35. 제30항에 있어서,

    상기 ActiveX 기반 프로비저닝을 수행하기 위한 코드는,

    상기 사용자 디바이스가 ActiveX 가능인지의 여부의 판정하기 위한 코드;

    상기 사용자 디바이스가 ActiveX 가능이면, 상기 사용자 디바이스에 ActiveX 로더를 설치하기 위한 코드; 및

    상기 사용자 디바이스에서 상기 ActiveX 로더를 실행하기 위한 코드를 포함하는 컴퓨터 프로그램 제품.
36. 제30항에 있어서,

    상기 사용자 디바이스를 프로비저닝하기 위한 코드는,

    상기 사용자 디바이스에 대한 서비스를 활성화하기 위한 코드;

    상기 사용자 디바이스로부터 데이터를 들여오기 위한 코드;

    상기 사용자 디바이스를 소정 어카운트에 접속시키기 위한 코드;

    복제 기록을 핸들링하기 위한 코드; 및

    상기 사용자 디바이스로 기록을 송신하기 위한 코드를 더 포함하는 컴퓨터 프로그램 제품.

Images