KR20090051718A - 컨텐츠 전달 시스템에 대한 애플리케이션 선호도 등록을 위한 방법 및 시스템 - Google Patents

Abstract

컨텐츠 전달 시스템에 애플리케이션 선호도를 제공하는 방법 및 시스템이 제공되며, 이 방법은 애플리케이션과 모바일 서비스들 간의 관계들과 관련된 확장성 생성 언어(XML) 문서 관리(XDM) 리포지토리 선호도에 대해 공개하는 단계와; XDM 서버 상에 애플리케이션과 모바일 서비스들 간의 관계들과 관련된 선호도를 저장하는 단계를 갖는다.

Description

컨텐츠 전달 시스템에 대한 애플리케이션 선호도 등록을 위한 방법 및 시스템{METHOD AND SYSTEM FOR APPLICATION PREFERENCE REGISTRATION TO A CONTENT DELIVERY SYSTEM}

본 발명은 일반적으로 확장성 생성 언어(XML) 문서 관리(XDM)에 관한 것으로, 보다 자세하게는 XDM에서의 선호도를 저장하는 것에 관한 것이다.

오픈 모바일 아키텍쳐(open mobile architecture; OMA) 다이내믹 컨텐츠 전달(dynamic content delivery; DCD) 사양은 애플리케이션이 컨텐츠를 수신하도록 등록할 수 있는 일반 전달 인에이블러(generic delivery enabler)를 정의한다. 일부 실시예에서, DCD 인에이블러는 DCD 인에이블러에 대해 불투명한 임의 컨텐츠를 전달할 수 있다. 컨텐츠는 채널 메타데이터에 의해 기술되는 채널들로 분류된다. 또한, DCD 인에이블러를 통하여 컨텐츠를 수신하기를 원하는 애플리케이션은 애플리케이션 메타데이터의 세트를 사용하여 자신의 선호도를 제공할 수 있다. 이러한 메타데이터를 제공하기 위하여, 장치 상에 상주하는 애플리케이션을 DCD 클라이언트에 등록하는 것이 필요하다.

OMA XDM 사양은 하나 이상의 유저들 및/또는 애플리케이션 대신에 정보의 저 장을 위한 플랫폼을 정의한다. 정보는 확장가능한 방식으로 그리고 플랫폼 중립 방식으로 저장된다. 일례는 정보를 XML 문서들에 저장하는 것이다. 이에 의해 인가받은 주재자(authorized principal)가 필요에 따라 이러한 데이터를 저장 및/또는 공유할 수 있게 한다.

XDM은 모바일 환경에 대해 최적화되며, 여기서 장치 특성들 및 네트워크 대역폭이 구속받을 수 있다. XDM 인에이블러의 의무는 OMA-RD-XDM-V1_0-20060612-A의 4장에서 개시되어 있는 바와 같이, 다른 OMA 인에이블러를 지원하는 것이다.

DCD에 의해 정의되는 바와 같은 일반 전달 메카니즘은 애플리케이션에 컨텐츠를 최상으로 전달하기 위하여 애플리케이션에 대해 정의된 선호도를 아는데 필요하다. 예를 들어, 일반 애플리케이션 선호도들은 다른 무엇보다도 컨텐츠가 어디에 저장될 것인지, 컨텐츠 테마, MIME 유형, 컨텐츠 유형, 전달 주파수 또는 스케쥴, 컨텐츠 크기 제약조건들을 포함할 수 있다.

컨텐츠 특정 애플리케이션 선호도는 DCD 인에이블러에 의해 처리되지 않고 단지, 불투명 컨텐츠로서 처리된 다음 처리를 위해 컨텐츠 제공자에게 전달된다. 컨텐츠 특정 애플리케이션 선호도들은 컨텐츠의 특정 서브세트에 대한 서브스크립션 필터(subscription filter)들을 포함하며, 무엇보다도, 서브스크립션 필터와 같은 것은 예를 들어, 주식 시세 서비스(stock quotation service)로부터의 주식들의 서브세트를 포함할 수 있어, 유저로 하여금 유저가 관심이 있는 주식에 대한 주식 시세만을 수신하도록 하게 한다.

본 발명은 일반 애플리케이션 선호도들을 바람직하게 다루며, 특히 XDM 인에이블러를 사용하여 DCD 인에이블러에 선호도들을 제공함으로써 이에 의해 DCD 클라 이언트에의 애플리케이션 직접 등록을 우회하는 간접 방법을 다룬다.

본 발명은 OMA DCD 인에이블러에 대한 일반 전달 애플리케이션에 애플리케이션 선호도들을 제공하는 유저 선호도 모델을 제공할 수 있다. 특히 본 방법들 및 시스템들은 일 실시예에서 다른 OMA 애플리케이션 사용 식별자와 양립하는 XDM에 대한 OMA DCD 애플리케이션 사용을 설정하는 것으로 이루어진다.

추가의 실시예에서, 본 방법 및 시스템은 모든 애플리케이션 관련 선호도들의 저장을 위한 XML 문서 스키마의 정의를 제공할 수 있다. 일 실시예에서, 이 스키마에는, DCD 인에이블러 구성요소들에 대해 관심이 있는 DCD 애플리케이션 선호도들이 포함된다.

본 방법 및 시스템은 XDM 서버를 사용하여, DCD 관심의 컨텐츠 특정 애플리케이션 선호도들 및 DCD 선호도(여기에서는 DCD-prefs이라 함)들의 양쪽 모두의 애플리케이션 선호도들의 저장 및 검색에 대한 메카니즘을 제공할 수 있다.

주어진 유저 장치 실행 환경 내에서 설치된 애플리케이션으로부터 XDM 서버로의 DCD 선호도들의 저장 또는 업데이트는 서로 다른 해명들(apology)을 사용할 수 있고 애플리케이션이 DCD-prefs를 DCD 클라이언트에 제출하고 DCD 클라이언트가 이들 DCD-prefs를 DCD 서버에 전달하는 것을 포함한다. DCD 서버는 DCD-prefs를 XDM 서버에 관철시키기 위해 XDM 클라이언트 기능성을 제공하도록 강화될 수 있다. 추가적인 실시예는 애플리케이션이 DCD 선호도들을 DCD 클라이언트에 제출하는 것을 포함할 수 있다. 이 실시예에서, DCD 클라이언트는 XDM 서버 내에 DCD-prefs를 관철시키기 위해 XDM 클라이언트 기능성을 제공하도록 강화될 수 있다. 추가의 실 시예에서, 전용 XDM 클라이언트 프로세스에 DCD-prefs를 제공하는 애플리케이션이 장치 상에 공동 위치(co-locate)되고 XDM 서버에 대한 접속성을 갖는다. 추가의 실시예에서, XDM 클라이언트 기능성이 내부에 내장되어 있는 애플리케이션이 제공될 수 있으며, 여기서, 이 애플리케이션은 DCD-prefs를 공개하는 XDM 서버에 대한 접속성을 갖는다.

추가의 실시예에서, 주어진 애플리케이션에 대한 DCD-prefs의 XDM 서버로부터 DCD 인에이블러 구성요소로의 업데이트의 검색 또는 통지가 기술된다. XDM 서버로부터 DCD-prefs를 직접적으로 또는 간접적으로 검색하기 위하여 서로 다른 시나리오들이 존재할 수 있다. 이들은 이 실시예에서는 XDM 서버로부터의 DCD-prefs에 대한 업데이트들을 패치(fetch)하거나 또는 통지받기 위하여 DCD 서버가 XDM 클라이언트 기능성을 제공하도록 강화되는 것을 포함하며 DCD 클라이언트는 DCD 서버로부터의 업데이트를 수신한다.

추가의 실시예에서, DCD 클라이언트는 XDM 서버로부터의 DCD-prefs에 대한 업데이트들을 패치하거나 또는 통지받기 위하여 XDM 클라이언트 기능성을 제공하도록 강화될 수 있다. DCD 클라이언트는 업데이트들에 대해 DCD 서버에 통지한다.

본 발명은 XDM 클라이언트와 XDM 서버 사이의 경로에 HTTP 프록시로서 구성되는 DCD 클라이언트의 삽입을 더 제공할 수 있다.

당해 기술 분야의 당업자에 잘 알려진 바와 같이, 이에 의해, DCD가 장치와 서버 양쪽 모두 상에서 이미 사용가능할 수 있는 XDM 프레임워크들을 재사용할 수 있게 하고, DCD의 실시를 위한 배치(deployment) 시나리오의 면에서 보다 더 유연 성을 제공한다.

따라서, 본 발명은 모바일 서비스들에 애플리케이션 선호도들을 제공하기 위한 방법을 제공할 수 있으며, 본 방법은 애플리케이션과 모바일 서비스들 간의 관계들과 관련된 확장성 생성 언어(XML) 문서 관리(XDM) 리포지토리 선호도에 대해 공개하는 단계와; XDM 서버 상에 애플리케이션과 모바일 서비스들 간의 관계들과 관련된 선호도를 저장하는 단계를 포함한다.

본 발명은 컨텐츠 전달 시스템에 대한 애플리케이션 선호도 등록을 위한 시스템을 추가로 제공할 수 있으며, 본 시스템은, 모바일 서비스들 간의 관계들과 관련된 선호도들을 저장하도록 구성된 XDM 서버 상의 XDM 리포지토리와; 컨텐츠 전달 시스템을 포함한, 모바일 서비스들 간의 관계들과 관련된 선호도들을 공개하도록 구성된 XDM 클라이언트를 포함한다.

본 발명의 구성에 따르면, XDM 인에이블러를 사용하여 DCD 인에이블러에 선호도들을 제공함으로써 이에 의해 DCD 클라이언트에의 애플리케이션 직접 등록을 우회하는 간접 방법을 제공할 수 있다.

본 방법 및 시스템은 도면들을 참조로 하여 보다 잘 이해될 것이다.

이하 도 1을 참조하여 본다. 도 1은 DCD 클라이언트(120)와 DCD 서버(130)를 갖는 일반 DCD 아키텍쳐(110)를 나타낸다.

하나 또는 복수의 장치 상주형 애플리케이션(140)은 DCD 클라이언트(120)를 통하여 컨텐츠를 수신할 수 있다. 각각의 애플리케이션(140)은 DCD 인에이블 클라이언트 애플리케이션(DECA)으로 불린다. DECA는 DCD 클라이언트(120)에 컨텐츠 선택 및 전달 개인화 및 구성에 관련된 선호도들을 제공한다. 개인화는 유저 특정형이고, 구성은 장치/애플리케이션 특정형이다. 이 데이터는 DCD 클라이언트(120)와, DCD 서버(130)에 의해 사용되며, DCD 서버(130)는 DCD 클라이언트(120)에 의해 중계되는 애플리케이션 등록 메시지의 부분으로서 애플리케이션 선호도들의 관련 서브세트를 수신한다.

복수의 컨텐츠 제공자들(150)은 DCD 서버(130)에 연결되거나 또는 등록되며 애플리케이션(140)에 의해 요청된 동적 컨텐츠를 제공한다.

선호도들은 채널 등록시 컨텐츠 제공자(150)에 의해 제공되는 채널 메타데이터와 애플리케이션 선호도들을 매칭시키고 적절한 컨텐츠를 애플리케이션(140)에 제공하도록 DCD 인에이블러에 의해 사용된다. 여기에 사용된 바와 같이, DCD 인에이블러는 DCD 서버(130)와 DCD 클라이언트(120)를 포함한다. 선호도들은 또한 다른 무엇보다도, 전달 스케쥴 또는 선호도들, 컨텐츠 스토리지, 컨텐츠 만료(expiry), 풀 또는 푸시 서비스들의 선택과 같은 전달 채널 속성들을 설정하기 위해 사용된다. 컨텐츠 선택 및 채널 설정시, DCD 인에이블러는 컨텐츠 제공자(150)로부터 애플리케이션으로 컨텐츠를 전달한다.

이 선호도들은 애플리케이션(140)에 의해 애플리케이션 선호도들(142)로서 저장될 수 있다. 또한, 이 선호도들은 DCD 클라이언트에 의해 선호도 데이터(122)로서 저장 또는 캐싱될 수 있고 DCD 서버(130)에 의해 선호도 데이터(132)로서 저 장 또는 캐싱될 수 있다.

이하, 도 2를 참조하여 본다. 도 2는 애플리케이션 데이터를 저장하기 위한 현재 XDM 모델(210)을 나타낸다. 도 2에서, 애플리케이션(220)은 XDM 클라이언트(230)에 선호도 데이터(222)를 제공하도록 구성되며, 여기서, XDM 클라이언트는 선호도 데이터(222)를 XDM 서버(240)에 공개한다. XDM 서버(240)는 이 데이터를 선호도 데이터(242)로서 저장한다.

이하, 도 3을 참조하여 본다. 도 3은 브랜치가 서비스의 특정 클래스(class)를 정의할 때 애플리케이션 고유 식별자(AUID) 하에서, XDM 리포지토리 내에 그리고 XDM 계층 구조 내에서 저장된 어떤 임의 데이터의 저장을 가능하게 하는 일반 XDM 아키텍쳐 모델(310)을 나타낸다. 이것을 애플리케이션 사용이라 한다.

보다 구체적으로, 루트 균일 자원 식별자(uniform resource identifier; URI)(312) 하에서, 여러 브랜치가 존재한다. 도면의 예에 도시된 브랜치들은 "프리젠스" 브랜치(320), AUID X 브랜치(330) 및 AUID Y 브랜치(340)를 포함한다.

프리젠스 브랜치(320) 하에서, 유저에 대한 카테고리(322)가 존재한다. 여러 유저들은 이 카테고리 하에서 저장될 수 있고 도면에 도시된 예에서는, 유저 A로서 도시된 제1 유저(324)만이 제공된다. 당해 기술 분야의 당업자에 알려진 바와 같이, 복수의 유저들이 유저 카테고리(322) 하에서 저장될 것이다. 그러나, 설명을 목적으로 하기 위해 한 유저만이 도시되어 있다.

제1 유저(324)는 유저 A에 대한 특별한 정보를 저장하기 위해 인덱스(326)를 포함한다.

AUID X(330) 브랜치 하에서, 유저용 카테고리(332)와 글로벌용 카테고리(334)가 제공된다. 이해될 바와 같이, 글로벌 카테고리(334)는 브랜치 AUID X(330)에 대한 모든 유저들에 적합한 정보를 저장한다.

도 3의 예에서, 단일의 유저 A(336)가 유저 카테고리(332) 내에서 발견된다.

유사하게, AUID Y(340) 브랜치 내에서, 유저들 카테고리(342)와 글로벌 카테고리(344)가 존재한다. 유저(342)는 유저 A로서 도시된 제1 유저(346)를 포함한다.

AUID X 브랜치(330)와 AUID Y 브랜치(340)의 것과 같이 애플리케이션 고유 식별자로 저장된 애플리케이션들의 예들은 다른 무엇보다도 푸시 투 토크(push-to-talk), DCD, 모바일 광고를 포함할 수 있다. XDM 구조는 XDM 클라이언트가 루트 URI에 의해 표기된 XDM 서버로부터 또는 XDM 서버로 데이터를 저장, 검색, 업데이트 또는 삭제할 수 있게 한다.

XDM는 또한 주어진 애플리케이션 또는 유저가 판독 권한(privilege)을 가질 수 있는 하부의 문서/데이터로 이루어지는 변경들을 관심이 있는 클라이언트들 또는 관찰자에 비동기 통지하는 것도 지원한다.

잘 알려진 바와 같이, XDM 구조체는 비교적 균일하며, 미리 정해진 브랜치들을 갖는다. 도 3은 XDM 서버에서 리포지토리 구조체를 나타낸다. 주어진 애플리케이션 사용에 관련된 데이터는 루트 URI에 의해 나타내어지는 XDM 서버 상의 리포지토리 내에 저장된다. 이 정보를 필요로 하고 이 데이터를 얻기 위해 적절한 인가를 갖는 다른 애플리케이션 또는 서비스는 XDM 서버로부터 정보를 후속하여 검색할 수 있거나 또는 임의의 또는 모든 정보가 변경되었는지를 통지받을 수 있다. 이 통지 는 무엇이 변경되었는지에 대한 특정 정보를 더 포함할 수 있다.

당해 기술 분야의 당업자에 잘 알려진 바와 같이, 상기 구성은 특정 모바일 서비스 및 다른 서비스들의 관계들과 관련된 선호도들의 저장을 고려하도록 구성될 수 있다. 이 양태는 동적 컨텐츠 전달 아키텍쳐를 참조로 아래 설명될 것이다. 그러나, 본 발명은 특정 모바일 서비스 또는 서비스들의 관계들과 관련된 임의의 선호도들 및 DCD로 한정되는 것임을 의미하지 않으며, 다른 것들이 이용될 수 있다.

이하, 도 4를 참조하여 본다. 도 4는 XDM의 브랜치가 DCD 선호도들의 저장을 위하여 이용되고 있는 일례를 나타낸다.

구체적으로, 도 4는 프리젠스 정보의 기존 AUID와 함께 DCD에 대한 서비스의 클래스 또는 별도의 AUID를 가진 일 실시예를 나타낸다. 도 4의 예에서, DCD 선호도들의 유저 영역 내의 각각의 애플리케이션은 DCD 인이에블 애플리케이션에 대응하는 0 이상의 애플리케이션 성분들을 갖는다. 주어진 유저에 대한 각각의 고유 애플리케이션에 대해, DCD 인에이블러 구성요소들에 의한 특별한 이용을 위한 애플리케이션 선호도들과 함께 관련 애플리케이션 선호도들을 포함하는 성분들이 존재한다. 또한, 프리젠스 정보 스토어 내에 대응하는 유저 DCD 서비스 양태들에 대한 연결(linkage) 또는 레퍼런스를 제공하는 문서 소스가 존재할 수 있다. 이는 그 서비스에 관련된 관련 장치 정보에 대한 간접 액세스를 포함한다. 이 연결은 DCD 서비스 자체에 특별히 관련된 DCD 선호도들에 포함되는데 필요한 중복 정보의 양을 감소시킨다.

도 4에서, XDM 서버는 XDM 루트(412)에 의해 레퍼런스된다. 도 4의 이 예는 3개의 브랜치, 즉, 프리젠스 브랜치(420), 푸시 투 토크 브랜치(430) 및 DCD 선호도 브랜치(440)를 포함한다.

프리젠스 브랜치(420) 하에서, 유저들은 카테고리(422)에 의해 정의되며, 유저 A로서 도시된 제1 유저(424)가 포함된다. 다른 유저들도 유사하게 유저 카테고리(422) 내에 들어올 것이다.

제1 유저(424)는 DCD 서비스 튜플(427)을 더 포함하는 인덱스(426)를 포함한다.

DCD 서비스(427)를 위한 장치들은 DCD 서비스(427) 하에서 브랜치되며 도 4의 예에서는, 랩톱(428) 및 폰(429)과 같은 DCD 서비스 튜플 내의 XML 부성분들을 포함한다. 당해 기술 분야의 당업자에 알려진 바와 같이, 브랜치(420)의 브랜치 구조는 단지 일례임을 의미하며 한정적인 것이 아니다.

푸시 투 토크 브랜치(430) 하에서, 유저 카테고리(432)와 글로벌 카테고리(434)가 제공된다. 예시의 목적으로 유저(432) 아래에 단일의 유저(436)가 도시되어 있다.

XDM 변환을 뒤따르는 DCD 브랜치(440)는 다른 무엇보다도 XML 문서들이 저장, 검색, 업데이트될 수 있는 유저 또는 글로벌 영역을 포함한다. 이들은 유저 카테고리(442)와 글로벌 카테고리(444)로서 여기에서 언급된다. 도 4의 실시예는 어느 한쪽의 카테고리에서의 DCD 선호도들에 관련된 데이터를 저장하도록 선택될 수 있다. 그러나, 도 4의 예들을 위하여, 그리고 기록의 각각의 고유 유저 또는 어드레스에 의해 차별화하기 위하여, DCD 선호도들이 유저 카테고리에 저장된다.

예시의 목적으로, 유저(442) 하에서 단일의 유저(446)가 도시되어 있다.

유저(446)는 유저 하에서 여러 브랜치들을 포함하는 인덱스(448)를 포함한다. 구체적으로, 인덱스(448) 하에서, 여러 애플리케이션들이 나열될 수 있다. 도 4의 예들은 제1 애플리케이션(450)과 제2 애플리케이션(452)을 포함한다. 제1 애플리케이션(450)은 박스(456)에 도시된 DCD 인에이블러에 의한 이용을 위한 애플리케이션 선호도들과 박스(454)에 도시된 다른 애플리케이션 및 컨텐츠 제공자들에 의한 액세스를 위한 선호도들로서 나열되는 정보를 더 포함한다. 유사한 정보가 박스(458 및 460)를 이용하여 애플리케이션(452)에 대하여 도시되어 있다.

인덱스(448) 하에서 유저(446)에 대한 DCD 인에이블러 선호도들이 제공된다. 이러한 선호도들은 모든 애플리케이션에 대하여 포괄적이며, 박스(462)에 도시된다. 선호도들의 예는 이들이 유저 A와 관련되어 있을 때, 다른 무엇보다도 푸시 서비스들을 대신하여 풀 서비스를 이용하여, 또는 풀 서비스들을 대신하여 푸시 서비스를 이용하여 전달을 위한 스케쥴을 포함할 수 있다.

도 4의 예에서, 브랜치들 간의 관계는 여러 브랜치들에서의 중복성의 감소를 가능하게 하기 위해 제공된다. 보다 자세하게는, 박스(462)와 DCD 서비스(427) 간의 라인(470)에 의해 도시된 관계는 별도의 브랜치에서 또는 박스(462) 하에서 선호도들을 저장해야 할 필요없이 박스(462)가 DCD 서비스에 대한 유저의 선호도들에의 액세스를 가질 수 있도록 한다.

유저에 대응하는 XML 문서들의 포맷은 특정 AUID와 포맷의 요건들까지 이른다. 도 4에 도시된 예들은 제한을 위한 것으로 의미하지 않는다.

상기의 것에 기초하여, DCD 사양 애플리케이션 사용은 애플리케이션 선호도들의 저장/검색을 허용하도록 선언되어야 한다. IETF에 상세화되고 OMA에 의해 인용된 협약(rfc 4825)에 따라, 선택된 AUID는 벤더/OMA 특정형이다. 표준 접근 방식은 AUID에 대한 프리픽스를 위해 예비할당된 도메인 이름을 이용하는 것이다. 오픈 모바일 얼라이언스에 대한 일례는 "org.openmobilealliance"일 것이다. 그 후, 특정 AUID가 이에 추가된다. 예를 들어, 도 4에는, "dcd-prefs"가 추가된다.

브랜치(440)에 대한 스키마는 다음과 같이 볼 수 있다.

다음은, 서비스와, bob@example.com의 AOR(Address-of Record)을 가진 유저 Bob에 관한 메타데이터에 대한 양쪽 모두의 상술한 스키마의 사례의 일례이다.

당해 기술분야의 당업자에 알려진 바와 같이, 상기의 것은 도 4의 DCD 서비스 튜플(427)에 대한 라인(470)을 정의하는 DCD 인에이블러 선호도들(462)의 일부분을 나타낸다.

추가의 예는 유저 밥(Bob)에 대한 DCD-pref XDM 자원을 나타낸다.

유사한 코드 세그먼트가 아래의 도 5 및 도 6의 예들에 이용될 수 있다.

이하, 도 5에 대하여 참조하여 본다. 도 5는 애플리케이션 선호도들의 저장/검색을 제공하기 위해 하부의 프리젠스 정보 데이터 모델을 이용하는 다른 XDM 기반 변동을 나타낸다. 도 4의 예와 달리, 도 5의 예는 프리젠스 정보 스토어에서의 포함을 위하여 추가되어진 DCD 특정 서비스 파라미터들에 대한 직접 액세스를 이용 한다. 또한, 이 모델은 유저 대신에 DCD를 지원하는 하부 장치들에 대한 직접 액세스를 제공한다.

도 5를 참조하여 보면, XDM 루트(512)는 2개의 브랜치들을 포함한다. 당해 기술 분야의 당업자에게 알려진 바와 같이, 도 5는 단지 일례임을 의미하며, 복수의 브랜치들이 XDM 루트 하에서 존재할 수 있다. 제1 브랜치(520)는 OMA 프리젠스 브랜치이며, 제2 브랜치(560)는 AUID X 브랜치이다. 도 5의 이 예에서, AUID X 브랜치는 푸시 투 토크 서비스이다.

프리젠스 브랜치(520)는 유저 카테고리(522)를 포함하며, 제1 유저(524)는 이 카테고리 하에 존재한다.

유저 인덱스(526)는 유저(524) 하에 들어오며, 서비스 튜플(528)은 인덱스(526) 하에서 정의된다.

도 5의 경우에, 이 서비스는 DCD 서비스이며, 박스(530)에서의 유저(524), 제1 애플리케이션(532), 제2 애플리케이션(534) 및 관련 장치 박스(536)의 디스크립션에 관련된 DCD 인에이블러 선호도들을 포함한다.

제1 애플리케이션(532)은 다른 애플리케이션들과 박스(540)에 도시된 컨텐츠 제공자들에 의한 액세스를 위한 제1 애플리케이션 선호도들과 DCD 인에이블러 박스(542)에 의한 이용을 위한 애플리케이션 선호도들을 포함한다. 유사하게, 제2 애플리케이션(534)은 컨텐츠 제공자들 박스(544)에서의 다른 애플리케이션에 의한 액세스를 위한 제2 애플리케이션 선호도들과 DCD 인에이블러 박스(546)에 의한 이용을 위한 애플리케이션 선호도들을 포함한다.

AUID X 브랜치(560)는 도 4를 참조로 하여 위에서 설명된 카테고리(432 및 434)에 유사한 유저 카테고리(562) 및 글로벌 카테고리(564)를 포함한다.

예시의 목적으로, 제1 유저(566)는 유저 카테고리(562) 아래에서 찾아진다. 이해될 바와 같이, 복수의 유저들은 도 5의 모델에 존재할 수 있고 존재할 것이다. 그러나, 예시의 목적으로, 제1 유저만이 도시되었다.

이하, 도 6을 참조하여 본다. 본질적으로, 도 6은 한 인에이블러가 다른 인에이블러를 이용하는 경우를 나타낸다. 도 6의 예에서, 제1 인에이블러는 모바일 광고 인에이블러이고 제2 인에이블러는 동적 컨텐츠 전달 인에이블러이다. 모바일 광고의 구성요소인 ad 엔진은 DCD 인에이블러에 대한 클라이언트 애플리케이션으로서, DCD 인에이블러를 통하여 ad들을 수신한다. 도 6은 XDM의 모바일 광고 브랜치에서 정의된 ad 엔진이 프리젠스 브랜치에 기술된 일반 모바일 광고 서버 선호도들을 조회하고, 이어서, XDM의 DCD 선호도 브랜치에서의 ad 엔진의 DCD 관련 선호도들이 XDM의 모바일 광고 브랜치에서의 ad 엔진 일반 선호도들을 조회하는 경우의 일례를 나타낸다.

도 6의 예에서, XDM 루트(610)는 3개의 브랜치들을 포함한다.

제1 브랜치(620)는 OMA 프리젠스 브랜치이다. 제2 브랜치(640)는 모바일 광고 브랜치이다. 제3 브랜치(660)는 DCD 선호도 브랜치이다.

제1 브랜치(620) 하에서, 유저 카테고리(622)가 정의되고 제1 유저(624)가 유저 카테고리(622) 하에 나타내어진다.

제1 유저(624)는 유저 하에서 정의되어 있는 광고 서비스 튜플(628)을 갖는 인덱스(626)를 포함한다.

모바일 광고 서비스들은 도 6의 예에서의 서비스 하에서 제1 장치(630)와 제2 장치(632)에 대한 선호도들을 가질 수 있다. 도 6은 단지 일례에 불과하며, 모바일 광고 서비스들은 유저 A에 대응하는 모바일 광고를 조작하는 장치들에 따른 복수의 장치들에 대한 선호도들을 가질 수 있음을 이해해야 한다.

모바일 광고에 대한 제2 브랜치(640) 하에서, 유저 카테고리(642)와 글로벌 카테고리(644)가 존재한다.

유저 카테고리(642) 하에서, 인덱스(648)를 포함하는 제1 유저(646)가 정의된다.

광고 엔진(650)은 인덱스(648) 하에 들어오며, 광고 엔진(650)은 엔진 하에서 다른 애플리케이션 및 컨텐츠 제공자 박스(652)에 의한 액세스에 대한 광고 엔진 선호도들을 포함한다.

DCD 선호도들의 제3 브랜치(660)는 유저 카테고리(662)와 글로벌 카테고리(664)를 포함한다.

유저 카테고리(662) 하에, 제1 유저(666)가 포함되고 인덱스(668)를 갖는다.

도 6의 예에서, 인덱스(668)는 광고 엔진(670), 제2 애플리케이션(672), 및 제1 유저 박스(674)에 관련된 DCD 인에이블러 선호도들을 포함한다.

광고 엔진(670)은 DCD 애플리케이션의 일례이다. 당해 기술 분야의 당업자에 알려진 바와 같이, 일부 실시예에서, 모바일 장치의 유저는 모바일 장치의 동작 비용을 감소시키기 위해 소모하거나 또는 생성하는 컨텐츠와 광고가 관련될 수 있도 록 선택할 수 있다. 이러한 광고들은 일부의 경우에, 컨텐츠와 관련되거나 또는 유저 프로파일과 관련될 수 있다.

도 6의 예에서, 광고 엔진(670)은 라인(678)에서 DCD 인에이블러에 의한 이용을 위한 광고 엔진 선호도들을 포함한다.

또한, 애플리케이션(672)은 다른 애플리케이션 및 컨텐츠 제공자 박스(680)에 의한 액세스를 위한 애플리케이션 선호도들 및 DCD 인에이블러 박스(682)에 의한 이용을 위한 애플리케이션 선호도들을 포함한다.

도 6의 예에서, ad 에이전트(670)는 엔진 선호도들을 획득하기 위하여 모바일 광고 브랜치 하에서 ad 엔진(650)을 조회한다. 또한, ad 엔진(650)은 특정 장치들에 대한 특정 모바일 광고 서비스 선호도들을 획득하기 위하여 라인(690)에서 모바일 광고 서비스들(628)을 조회한다.

따라서, 상기의 것은 애플리케이션 선호도들을 저장하기 위한 XDM의 확장을 나타낸다. 그러나 상기의 것은 광고 또는 DCD로 제한되는 것을 의미하지 않으며 단지 애플리케이션 선호도들을 삽입할 수 있는 서비스들의 양태를 갖는 애플리케이션 선호도들의 연결성을 보여주기 위한 것일 뿐이다.

도 4 내지 도 6에 기초하여, 위에서의 배치 모델들은 임의의 애플리케이션 또는 서비스들을 포함하도록 추가로 일반화될 수 있고 이 기술은 애플리케이션들의 클래스 또는 다양한 다른 서비스들에 적용될 수 있으며 연결성은 XDM 서버 내의 어느곳에서라도 저장된 기존 정보를 최적화하는 방식으로 적응될 수 있다. 또한, 당해 기술 분야의 당업자는 모든 브랜치들이 국부적 XDM 서버 또는 원격 XDM 서버를 조회할 수 있음을 주지해야 한다. 국부적 XDM 서버는 동일한 위치 내의 계층 구조이거나 동일한 루트 URI 내에서 조회된다. 원격 XDM 서버는 전체적으로 또는 부분적으로 루트 URI로부터 이격되어 있다. 조회는 원격 루트 URI 레퍼런스를 통하여 행해진다.

애플리케이션 프로파일 사용을 위하여 변형된 XDM 구조를 채용하기 위해 여러 아키텍쳐가 이용될 수 있다. 도 7 내지 도 11의 예들은 DCD 아키텍쳐에 관하여 제공된다. 그러나, 상술한 바와 같이, 다른 애플리케이션 프로파일 또는 선호도들이 이용될 수 있다.

이하 도 7을 참조하여 본다. 도 7은 XDM 클라이언트가 장치 상에 있는 예시적인 아키텍쳐의 블록도를 나타낸다.

도 7의 일 실시예에서, 애플리케이션(710)은 선호도들(712)을 포함한다. 선호도들(712)은 당해 기술 분야의 당업자에 잘 알려진 바와 같이, 다른 무엇보다도 유저, 서비스, 장치 또는 애플리케이션 선호도들을 포함할 수 있다.

애플리케이션(710)은 XDM 클라이언트(720)와 통신하고 그 후 XDM 클라이언트(720)는 선호도들을 XDM 서버(730)에 공개한다. XDM 서버는 DCD 서버(740)를 포함한 여러 애플리케이션들에 의한 이용을 위한 선호도들(732)을 저장한다. 화살표(736)로 표시된 바와 같이, DCD 서버(740)는 선호도들을 요청하거나 또는 XDM 서버(730)로부터 선호도들을 수신함으로써 XDM 서버로부터 애플리케이션(742)에 대한 선호도들을 획득할 수 있다.

그 후, DCD 서버(740)는 DCD 클라이언트(750)에 선호도들을 푸싱하며 이들 선호도는 선호도들(752)로서 저장된다.

대안의 실시예에서, XDM 클라이언트(720)가 DCD 클라이언트(750)에 선호도들(752)을 직접 제공하도록 구성될 수 있다. 이것은 화살표(725)로 나타내어진다.

추가의 실시예에서, XDM 서버(730)가 DCD 클라이언트(750)에 선호도들(752)을 직접 제공하도록 구성될 수 있다. 이것은 화살표(735)로 나타내어진다.

상기의 것에 기초하여, 아키텍쳐는 설치 시간에, 또는 유저에 의한 애플리케이션의 이용 전에, 애플리케이션이 장치 실행 환경 뿐만 아니라 전달 클라이언트의 존재를 알고 있지 않음을 제공한다. 애플리케이션은 애플리케이션 선호도들을 XDM 클라이언트(720)에 전송한다.

추가로 이해될 바와 같이, XDM 서버(730)에 의한 선호도들의 공개는 도 4 내지 도 6을 참조로 하여 위에서 설명된 모델들 중 어느 하나를 이용할 수 있다. XDM 서버(730)가 선호도들을 수신하는 경우, 그 후, XDM 소스는 유저의 AOR에 대응하는 문서 내에 위치된다.

애플리케이션이 푸시되거나 풀링될 컨텐츠를 요청하는 경우, DCD 서버(740)는 DCD 클라이언트(750)를 통하여 애플리케이션에 전달되기 위해 관련 채널들을 매칭시키도록 XDM 서버(703)에 대해 요청을 개시한다. DCD 클라이언트(750)는 DCD 서버(740)로부터 자신에게 푸싱되는 관련 애플리케이션 선호도들을 갖는다. 이것은 DCD 서버 및 가능하다면 DCD 클라이언트가 장치 실행 환경 내에서 국부적으로 저장을 실시해야 하는 것을 경감시킨다. 상기의 것에 대한 대안은 도 7을 참조로 설명된 바와 같이, DCD 클라이언트(750)가 애플리케이션 선호도들을 XDM 클라이언 트(720)로부터 직접 검색하도록 하거나 또는 DCD 클라이언트가 애플리케이션 선호도들을 XDM 서버(730)로부터 수신하도록 하는 것이다.

DCD 클라이언트(750)는 국부적으로 이들 선호도를 저장하거나 또는 캐싱할 수 있다. 이러한 배치 모델의 이점은 하부의 메타데이터가 다른 무엇보다도 컨텐츠 제공자, 데스크 톱 PC로부터의 인가받은 유저와 같은 외부 소스에 의해 업데이트되는 경우, DCD 클라이언트가 재패치를 수행하거나 또는 XDM 서버(730)에 의해 통지되어지는 유연성을 갖는다는 것이다.

대안의 아키텍쳐는 도 8을 참조로 설명된다. 도 8은 초기 처리 단계들이 도 7을 참조로 설명된 것과 유사한 다른 방법을 나타낸다. 프로세스는 XDM 클라이언트(820)가 관련 선호도들을 공개할 때까지 애플리케이션(810)이 XDM 클라이언트(820)와 통신하는 선호도들(812)을 갖는 점에서 일치한다. 선호도들(832)로서 XDM 서버(830)에 직접 전달하는 것보다는, HTTP 공개 트래픽이 DCD 클라이언트(840) 내에 내장되어 있는 HTTP 프록시를 통하여 재라우팅되고 DCD 클라이언트는 842에 나타낸 바와 같이, 또한 HTTP/POST 요청으로부터 애플리케이션 선호도들을 선택할 수 있고 이 선호도들을 국부적으로 저장할 수 있다. 이점들은 네트워크 상에서 XDM 서버에의 접속을 회피하기 때문에 즉각적으로 나타난다. 추가로, DCD 클라이언트(840)는 화살표(835)에 의해 나타낸 바와 같이, XDM 서버(830)에 선호도들을 전달할 수 있다.

DCD 서버(850)는 DCD 클라이언트(840)를 통하여 애플리케이션에 의해 제공된 선호도들의 세트로부터 애플리케이션 선호도들(852) 만을 저장하여, DCD 클라이언 트(840)에 대하여 유사하게 처리할 수 있다. 마지막으로, 애플리케이션 선호도들은 저장을 위하여 XDM 서버(830)에 전달된다. 이러한 모델의 이점은 선호도들의 업데이트가 즉시 인식하여 DCD 클라이언트에 이용될 수 있다는 점이다. 이 모델의 다른 이점은 선호도들이 변경되는 경우, DCD 클라이언트(840)가, XDM 클라이언트(820)가 행하는 것만큼 즉시는 아니지만 적절한 때에 이들 변경 또는 완전히 새로운 세트 또는 선호도들을 전송할 수 있다는 점이다.

도 8의 실시예에서, XDM 클라이언트(820)로부터 XDM 서버(830)로의 통신이 하이퍼텍스트 트랜스퍼 프로토콜(Hypertext Transfer Protocol; HTTP) 프록시로서 DCD 클라이언트(840)를 통하여 재라우팅된다.

추가적인 대안의 모델이 도 9를 참조로 설명된다. 도 9는 이 모델에 의해 애플리케이션 선호도들이 DCD 클라이언트에 전송되는 것을 나타낸다. 이 모델에서, XDM 클라이언트는 DCD 클라이언트 내에서 직접 호스트된다. 이 모델은 XDM DCD 클라이언트로 하여금 XDM 서버에 선호도들을 전송하기 전에 선호도들을 국부적으로 저장할 수 있게 한다. 이 모델은 또한 XDM 일반 프레임워크 내에서 DCD 저장 및 전달 능력들의 이점을 결합한다. DCD 클라이언트 및 서버는 상술한 모델들 및 특히 도 8을 참조로 한 모델과 동일한 방식으로 진행한다. 당해 기술 분야의 당업자에 알려진 바와 같이, DCD 서버는 XDM 서버로부터 애플리케이션 선호도들을 직접 검색가능하다.

도 9를 참조하여 보면, 애플리케이션(910)은 결합형 DCD-XDM 클라이언트(920)에 전파되는 선호도들(912)을 포함한다.

결합형 DCD-XDM 클라이언트(920)는 이들 선호도를 XDM 서버(930)에 공개한 다음, XDM 서버(930)는 도 4 내지 도 6의 모델과 유사한 모델을 이용하여 이들 선호도(932)를 저장한다.

DCD 서버(940)는 선호도들(942)로서 XDM 서버(930)로부터 애플리케이션 선호도들(932)을 검색한다.

도 9에 도시된 바와 같이, DCD-XDM 클라이언트는 922로서 선호도들을 저장할 수 있고, 추가로 이들 선호도는 선호도들(924)로서 DCD 클라이언트 측에 의해 저장될 수 있다.

도 10을 참조하여 보면, 도 10은 현재의 DCD 모델에 따라 DCD 클라이언트를 통하여 자신의 선호도들을 전송하는 다른 모델의 블록도를 나타낸다. 그 후, DCD 클라이언트는 선호도들을 국부적으로 저장하고 DCD 서버에 선호도들을 전송 또는 송신하도록 선택할 수 있다. 도 10의 경우에, DCD 서버는 내장형 XDM 클라이언트 기능을 포함한다. 따라서, DCD 서버는 XDM 서버를 접촉하고, 선호도들을 공개한다. 잘 알려진 바와 같이, 도 10의 모델은 선호도들의 완벽한 동기화를 가능하게 한다. DCD 서버는 필요에 따라 어느 때이든지 XDM 서버에 접속할 수 있다. DCD 클라이언트는 심지어 접속되지 않거나 또는 XDM 서버가 기능하지 않는 경우에도, 애플리케이션 선호도들에 따라 자신의 현재 메타데이터 스냅샷을 이용하여 처리 및 기능을 할 수 있다.

따라서, 도 10에서, 애플리케이션(1010)은 선호도들(1012)을 포함하며, 이들 선호도를, DCD 클라이언트(1020)에 전파하고, 위에 나타낸 바와 같이, DCD 클라이 언트(1020)는 1022로서 이들 선호도를 국부적으로 저장할 수 있다.

DCD 클라이언트는 선호도들(1022)을 DCD 서버(1030)에 전송하고, DCD 서버(1030)는 선호도들을 1032로서 저장할 수 있다. 도 10의 경우에, DCD 서버(1030)는 XDM 클라이언트(1034) 기능성을 포함하며, 이것에 기초하여, 선호도들은 XDM 서버(1040)에 공개된 다음, XDM 서버(1040)가 위의 도 4 내지 도 6의 모델들에 따라 선호도들의 전체 세트를 1042로서 저장한다.

이하, 도 11을 참조하여 본다. 도 11은 초기화 또는 설치 시에 애플리케이션이 XDM 서버를 직접 접촉하도록 인가받은 경우의 모델을 나타낸다. 도 11의 모델에서, XDM 클라이언트는 애플리케이션 자체 내에 내장되어 있다. 이것은 복잡성을 추가하지만, 이는 애플리케이션이 DCD 클라이언트, 프록시 또는 다른 매개물에 의한 관여 없이도 자신의 애플리케이션 선호도들을 가능성있게 검색할 수 있게 한다.

도 11의 DCD 서버 및 도 11의 DCD 클라이언트가 도시된 바와 같이 진행할 수 있다.

구체적으로, 애플리케이션(1110)은 선호도들(1112)을 포함한다. 또한, 애플리케이션(1110)은 내장형 XDM 클라이언트(1114)를 포함하며, 이것에 기초하여, 자신의 선호도들을 XDM 서버(1120)에 직접 공개할 수 있고 그 후, XDM 서버(1120)는 선호도들을 위의 도 4 내지 도 6의 모델에 따라 1122로서 저장한다.

DCD 서버(1130)는 XDM 서버(1120)로부터 선호도들을 검색할 수 있고 이들 선호도를 스토리지(1132)로서 캐싱할 수 있다.

또한, DCD 서버(1130)는 선호도들을 DCD 클라이언트(1140)에 푸시할 수 있고 그 후, DCD 클라이언트(1140)는 이 선호도들을 1142로서 캐싱할 수 있다.

따라서, 본 발명은 일반 애플리케이션 선호도들, 특히, XDM 인에이블러를 이용하여 DCD 인에이블러에 선호도들을 제공하며, 이에 의해 애플리케이션의 DCD 클라이언트에의 직접 등록을 우회할 수 있는 간접 방법을 다룬다.

본 발명은 일반 전달 애플리케이션에 대한 애플리케이션 선호도들을 OMA DCD 인에이블러에 제공하기 위해 유저 선호도 모델을 추가로 제공한다. 특히, 본 방법 및 시스템은 일 실시예에서, 다른 OMA 애플리케이션 사용 식별자들에 양립하는 XDM에 대한 OMA DCD 애플리케이션 사용을 설정하는 것으로 이루어진다.

당업자라면 잘 알고 있는 바와 같이, 애플리케이션, DCD 클라이언트 및 어떤 경우에 XDM 클라이언트는 임의의 모바일 장치 상에 존재할 수 있다. 한 예시적인 모바일 장치에 대해 도 12를 참조하여 이하에서 기술한다. 이것은 제한하려는 것이 아니며 예시의 목적을 위한 것이다.

도 12는 본 발명의 장치 및 방법의 양호한 실시예에서 사용하기에 적합한 이동국을 나타낸 블록도이다. 이동국(1200)은 양호하게는 적어도 음성 및 데이터 통신 능력을 갖는 양방향 무선 통신 장치이다. 이동국(1200)은 양호하게는 인터넷을 통해 다른 컴퓨터 시스템과 통신할 수 있는 능력을 갖는다. 제공된 정확한 기능에 따라, 무선 장치는, 예로서, 데이터 메시징 장치, 양방향 페이저, 무선 이메일 장치, 데이터 메시징 능력을 갖는 셀룰러 전화, 무선 인터넷 기기, 또는 데이터 통신 장치라고 할 수 있다.

이동국(1200)이 양방향 통신이 가능한 경우, 이동국(1200)은 수신기(1212) 및 송신기(1214) 둘다를 포함하는 통신 서브시스템(1211)은 물론, 하나 이상의, 양호하게는 내장된 또는 내장형의, 안테나 요소(1216, 1218), 국부 발진기(LO)(1213), 및 디지털 신호 처리기(DSP)(1220) 등의 처리 모듈을 포함할 것이다. 통신 분야의 당업자에게는 명백한 바와 같이, 통신 서브시스템(1211)의 특정의 설계는 장치가 사용되도록 되어 있는 통신 네트워크에 의존한다.

네트워크 액세스 요건도 네트워크(1219)의 유형에 따라 변하게 된다. 어떤 CDMA 네트워크에서, 네트워크 액세스는 가입자 또는 이동국(1200)의 유저와 연관되어 있다. CDMA 이동국은 CDMA 네트워크 상에서 동작하기 위해서 분리가능 유저 식별 모듈(removable user identity module, RUIM) 또는 가입자 식별 모듈(subscriber identity module, SIM)을 필요로 할 수 있다. SIM/RUIM 인터페이스(1244)는 통상적으로 디스켓 또는 PCMCIA 카드처럼 SIM/RUIM 카드가 삽입되고 배출될 수 있는 카드-슬롯과 유사하다. SIM/RUIM 카드는 대략 64 K의 메모리를 가질 수 있고 또 많은 키 구성(1251)과, 식별자 및 가입자 관련 정보 등의 다른 정보(1253)를 가질 수 있다.

요구되는 네트워크 등록 또는 활성화 절차가 완료되었을 때, 이동국(1200)은 네트워크(1219)를 거쳐 통신 신호를 전송 및 수신할 수 있다. 도 12에 나타낸 바와 같이, 네트워크(1219)는 이동국과 통신하는 다수의 기지국으로 이루어질 수 있다. 예를 들어, 하이브리드 CDMA 1x EVDO 시스템에서, CDMA 기지국 및 EVDO 기지국은 이동국과 통신하고, 이동국은 둘다에 동시에 연결되어 있다. EVDO 및 CDMA 1x 기지국은 이동국과 통신하기 위해 서로 다른 페이징 슬롯을 사용한다.

통신 네트워크(1219)를 통해 안테나(1216)에 의해 수신되는 신호는 수신기(1212)에 입력되고, 이 수신기(1212)는 신호 증폭, 주파수 다운 컨버전, 필터링, 채널 선택, 및 도 12에 나타낸 예시적인 시스템에서의 아날로그-디지털(A/D) 변환 등과 같은 통상의 수신기 기능을 수행할 수 있다. 수신된 신호의 A/D 변환은 복조 및 디코딩 등의 보다 복잡한 통신 기능이 DSP(1220)에서 수행될 수 있게 해준다. 유사한 방식으로, 전송될 신호는, 예를 들어, 변조 및 인코딩을 비롯하여, DSP(1220)에 의해 처리되고, 디지털-아날로그 변환, 주파수 업 컨버전, 필터링, 증폭, 및 안테나(1218)를 거쳐 통신 네트워크(1219)를 통한 전송을 위해 송신기(1214)에 입력된다. DSP(1220)는 통신 신호를 처리할 뿐만 아니라, 수신기 및 송신기 제어도 제공한다. 예를 들어, 수신기(1212) 및 송신기(1214)에서 통신 신호에 적용되는 이득은 DSP(1220)에 구현되는 자동 이득 제어 알고리즘을 통해 적응적으로 제어될 수 있다.

이동국(1200)은 양호하게는 장치의 전체적인 동작을 제어하는 마이크로프로세서(1238)를 포함한다. 적어도 데이터 및 음성 통신을 포함하는 통신 기능은 통신 서브시스템(1211)을 통해 수행된다. 마이크로프로세서(1238)는 또한 디스플레이(1222), 플래쉬 메모리(1224), 랜덤 액세스 메모리(RAM)(1226), 보조 입/출력(I/O) 서브시스템(1228), 직렬 포트(1230), 2개 이상의 키보드 또는 키패드(1232), 스피커(1234), 마이크로폰(1236), 단거리 통신 서브시스템 등의 다른 통신 서브시스템(1240), 및 일반적으로 1242로 표시된 임의의 다른 장치 서브시스템 등의 다른 장치 서브시스템들과 상호작용한다. 직렬 포트(1230)는 USB 포트 또는 당업자에게 알려져 있는 다른 포트를 포함할 수 있다.

도 12에 나타낸 서브시스템들 중 어떤 것들은 통신 관련 기능을 수행하는 반면, 다른 서브시스템들은 "상주형(resident)" 또는 온-디바이스(on-device) 기능을 제공할 수 있다. 주목할 만한 것은, 예를 들어, 키보드(1232) 및 디스플레이(1222) 등의 어떤 서브시스템들은 통신 네트워크를 통해 전송하기 위한 텍스트 메시지를 입력하는 것 등의 통신 관련 기능, 및 계산기 또는 작업 목록 등의 장치-상주형 기능(device-resident function) 둘다에 대해 사용될 수 있다.

마이크로프로세서(1238)에 의해 사용되는 운영 체제 소프트웨어는 양호하게는 플래쉬 메모리(1224) 등의 영속적 저장 장치에 저장되어 있으며, 이 저장 장치는 그 대신에 판독 전용 메모리(ROM) 또는 유사한 저장 요소(도시 생략)일 수 있다. 당업자라면 운영 체제, 특정의 장치 애플리케이션, 또는 그의 일부분이 일시적으로 RAM(1226) 등의 휘발성 메모리에 로드될 수 있다는 것을 잘 알 것이다. 수신된 통신 신호도 RAM(1226)에 저장될 수 있다.

도시된 바와 같이, 플래쉬 메모리(1224)는 컴퓨터 프로그램(1258) 및 프로그램 데이터(1250, 1252, 1254, 1256) 저장 둘다를 위해 서로 다른 영역으로 분할될 수 있다. 이들 서로 다른 저장 유형은 각각의 프로그램이 플래쉬 메모리(1224)의 일부분을 그 자신의 데이터 저장 요건을 위해 할당할 수 있음을 나타낸다. 마이크로프로세서(1238)는, 그의 운영 체제 기능 이외에, 양호하게는 이동국 상에서의 소프트웨어 애플리케이션의 실행을 가능하게 해준다. 예를 들어, 적어도 데이터 및 음성 통신 애플리케이션을 포함하는 기본적인 동작을 제어하는 미리 정해진 일련의 애플리케이션이 통상적으로 제조 동안에 이동국(1200) 상에 설치된다. 다른 애플리케이션은 차후에 또는 동적으로 설치될 수 있다.

양호한 소프트웨어 애플리케이션은 이메일, 일정 관리(calendar event), 음성 메일, 약속, 및 작업 항목(이에 한정되지 않음) 등의 이동국의 유저에 관련한 데이터 항목을 구성 및 관리할 수 있는 기능을 갖는 개인 정보 관리자(PIM) 애플리케이션일 수 있다. 당연히, PIM 데이터 항목의 저장을 용이하게 해주기 위해 하나 이상의 메모리 저장 장치가 이동국 상에서 이용가능하게 된다. 이러한 PIM 애플리케이션은 양호하게는 무선 네트워크(1219)를 통해 데이터 항목을 전송 및 수신할 수 있는 기능을 가지게 된다. 양호한 실시예에서, PIM 데이터 항목은, 무선 네트워크(1219)를 통해, 호스트 컴퓨터 시스템에 저장되거나 그와 연관된 이동국 유저의 대응하는 데이터 항목과 매끄럽게 통합, 동기화 및 갱신될 수 있다. 추가의 애플리케이션도 네트워크(1219), 보조 I/O 서브시스템(1228), 직렬 포트(1230), 단거리 통신 서브시스템(1240) 또는 임의의 다른 적당한 서브시스템(1242)을 통해 이동국(1200)에 로드되고, 마이크로프로세서(1238)에 의해 실행하기 위해 유저에 의해 RAM(1226) 또는 양호하게는 비휘발성 저장 장치(도시 생략)에 설치될 수 있다. 애플리케이션 설치에서의 이러한 유연성은 장치의 기능을 향상시키고 또 향상된 온-디바이스 기능, 통신-관련 기능, 또는 둘다를 제공할 수 있다. 예를 들어, 보안 통신 애플리케이션은 전자 상거래 기능 및 다른 이러한 금융 거래가 이동국(1200)을 사용하여 수행될 수 있게 해줄 수 있다.

데이터 통신 모드에서, 텍스트 메시지 또는 웹 페이지 다운로드 등의 수신된 신호는 통신 서브시스템(1211)에 의해 처리되고 마이크로프로세서(1238)에 입력되며, 이 마이크로프로세서(1238)는 양호하게는 수신된 신호를 디스플레이(1222)로 또는 다른 대안으로서 보조 I/O 장치(1228)로 출력하기 위해 추가적으로 처리한다. DCD 클라이언트(120, 750, 840, 920, 1020 및 1140) 또는 XDM 클라이언트(230, 820 및 1114)와 동등할 수 있는 클라이언트(1260)도 일부 실시예에서, 모바일 장치 상에 있을 수 있다.

이동국(1200)의 유저는 또한 디스플레이(1222) 및 아마도 보조 I/O 장치(1228)와 함께, 양호하게는 완전한 영숫자 키보드 또는 전화형 키패드인 키보드(1232)를 사용하여, 예를 들어, 이메일 메시지 등의 데이터 항목을 작성할 수 있다. 이러한 작성된 항목은 이어서 통신 서브시스템(1211)을 통해 통신 네트워크를 거쳐 전송될 수 있다.

음성 통신의 경우, 이동국(1200)의 전체적인 동작은, 수신된 신호가 양호하게는 스피커(1234)로 출력되고 전송을 위한 신호가 마이크로폰(1236)에 의해 생성되는 것을 제외하고는 유사하다. 음성 메시지 녹음 서브시스템 등의 대안의 음성 또는 오디오 I/O 서브시스템도 이동국(1200) 상에 구현될 수 있다. 음성 또는 오디오 신호 출력이 양호하게는 주로 스피커(1234)를 통해 달성되지만, 예를 들어, 호출측 당사자의 신원의 표시, 음성 통화의 기간, 또는 다른 음성 통화 관련 정보를 제공하기 위해 디스플레이(1222)도 사용될 수 있다.

도 12의 직렬 포트(1230)는 통상적으로 유저의 데스크톱 컴퓨터(도시 생략)과의 동기화가 바람직할 수 있는 개인 휴대 단말기(PDA)형 이동국에서 구현되지만, 이는 선택적인 장치 요소이다. 이러한 포트(1230)는 유저가 외부 장치 또는 소프트웨어 애플리케이션을 통해 유저 선호도들을 설정할 수 있게 해주고 또 무선 통신 네트워크 이외의 것을 통해 이동국(1200)으로의 정보 또는 소프트웨어 다운로드를 제공함으로써 이동국(1200)의 기능을 확장시킨다. 대안의 다운로드 경로는 예를 들어 직접 연결(direct connection), 따라서 믿을만한 신뢰된 연결을 통해 장치 상으로 암호화 키를 로드하고 그에 의해 안전한 장치 통신을 가능하게 해주는데 사용될 수 있다. 당업자라면 잘 알고 있는 바와 같이, 직렬 포트(1230)는 또한 모뎀으로서 동작하도록 모바일 장치를 컴퓨터에 연결하는데 사용될 수 있다.

단거리 통신 서브시스템 등의 다른 통신 서브시스템(1240)은 이동국(1200)과 다른 시스템 또는 장치(꼭 유사한 장치일 필요는 없음) 간의 통신을 제공할 수 있는 또다른 선택적인 구성요소이다. 예를 들어, 서브시스템(1240)은 유사한 기능의 시스템 및 장치와의 통신을 제공하기 위해 적외선 장치와 관련 회로 및 구성요소 또는 블루투스™ 통신 모듈을 포함할 수 있다.

본 명세서에 기술된 실시예는 본 발명의 기술의 구성요소에 대응하는 구성요소를 갖는 구조, 시스템 또는 방법의 예이다. 이 기술된 설명은 당업자로 하여금 마찬가지로 본 발명의 기술의 구성요소에 대응하는 대안의 구성요소를 갖는 실시예를 제조 및 사용할 수 있게 해줄 수 있다. 본 발명의 기술의 의도된 범위는 따라서 본 명세서에 기술된 본 발명의 기술과 다르지 않은 기타의 구조, 시스템 또는 방법을 포함하며, 또한 본 명세서에 기술된 본 발명의 기술과 실질적으로 다르지 않은 기타의 구조, 시스템 또는 방법도 포함한다.

도 1은 동적 컨텐츠 전달 아키텍쳐를 나타내는 블록도이다.

도 2는 일반 XDM 아키텍쳐 모델을 나타내는 블록도이다.

도 3은 XDM 리포지토리 구조를 나타낸다.

도 4는 동적 컨텐츠 전달 브랜치가 추가되었던 XDM 리포지토리 구조를 나타내며, 동적 컨텐츠 전달 브랜치는 DCD 서비스 튜플을 가진 프리젠스 브랜치를 조회한다.

도 5는 DCD 서비스 튜플을 가진 프리젠스 브랜치 하에서 동적 컨텐츠 전달 서비스가 추가되었던 XDM 리포지토리 구조를 나타낸다.

도 6은 여러 서비스들이 크로스 서비스 의존성(cross-service dependency)을 갖는 XDM 리포지토리 구조를 나타낸다.

도 7은 애플리케이션 선호도들이 XDM 클라이언트, XDM 서버, DCD 서버를 통하여 DCD 클라이언트에 전파되는 제1 아키텍쳐 모델을 나타낸다.

도 8은 XDM 클라이언트로부터의 트래픽이 DCD 클라이언트를 통하여 HTTP 프록시로서 재라우팅되는 아키텍쳐 모델의 블록도를 나타낸다.

도 9는 DCD 클라이언트가 XDM 클라이언트 인식형인 아키텍쳐 모델을 나타내는 블록도이다.

도 10은 DCD 서버가 XDM 클라이언트 인식형인 아키텍쳐 모델의 블록도이다.

도 11은 애플리케이션이 XDM 클라이언트 인식형인 아키텍쳐 모델이다.

도 12는 본 발명에 이용되기 쉬운 예시적인 이동 장치의 블록도를 나타낸다.

Claims (25)

1. 모바일 서비스들에 애플리케이션 선호도들을 제공하는 방법으로서,

   애플리케이션과 모바일 서비스들 간의 관계들과 관련된 확장성 생성 언어(XML) 문서 관리(XDM) 리포지토리 선호도들에 대해 공개하는 단계와;

   XDM 서버 상에 애플리케이션과 모바일 서비스들 간의 관계들과 관련된 선호도들을 저장하는 단계를 포함하는 애플리케이션 선호도들의 제공 방법.
2. 제1항에 있어서, 상기 선호도들은 동적 컨텐츠 전달 'DCD' 인에이블러에 대한 애플리케이션 선호도들인 것인 애플리케이션 선호도들의 제공 방법.
3. 제2항에 있어서, 상기 애플리케이션 선호도들은 일반 또는 컨텐츠 특정 애플리케이션 선호도들인 것인 애플리케이션 선호도들의 제공 방법.
4. 제2항 또는 제3항에 있어서, 상기 DCD 인에이블러에 대한 애플리케이션 선호도들은 XDM 리포지토리의 애플리케이션 고유 식별자 브랜치에 저장되는 것인 애플리케이션 선호도들의 제공 방법.
5. 제2항 또는 제3항에 있어서, 상기 DCD 인에이블러에 대한 애플리케이션 선호도들은 DCD가 아닌 서비스에 대한 브랜치 하에 저장되는 것인 애플리케이션 선호도 들의 제공 방법.
6. 제5항에 있어서, 상기 DCD가 아닌 서비스는 프리젠스 서비스인 것인 애플리케이션 선호도들의 제공 방법.
7. 제2항 또는 제3항에 있어서, 상기 공개하는 단계는,

   애플리케이션으로부터 XDM 클라이언트에 선호도들을 제공하는 단계와;

   상기 선호도들을 XDM 서버에 전송하는 단계와;

   XDM 서버로부터 DCD 서버에 선호도들을 검색하는 단계와;

   XDM 서버 또는 DCD 서버로부터 DCD 클라이언트에 선호도들을 푸시하는 단계

   를 포함하는 것인 애플리케이션 선호도들의 제공 방법.
8. 제2항 또는 제3항에 있어서, 상기 공개하는 단계는,

   애플리케이션으로부터 XDM 클라이언트에 선호도들을 제공하는 단계와;

   선호도들을 XDM 서버에 전송하는 단계와;

   XDM 서버와 XDM 클라이언트 사이에서 DCD 클라이언트를 하이퍼텍스트 전송 프로토콜 프록시로서 이용하는 단계 - 이 단계에 의해 DCD 클라이언트에서부터 선호도들을 검색함 - 와;

   DCD 클라이언트로부터 DCD 서버에, 또는 XDM 서버로부터 DCD 서버에 선호도들을 전송하는 단계

   를 포함하는 것인 애플리케이션 선호도들의 제공 방법.
9. 제8항에 있어서, 상기 전송하는 단계는 DCD 클라이언트에 재라우팅(rerouting)하는 단계를 포함하는 것인 애플리케이션 선호도들의 제공 방법.
10. 제2항 또는 제3항에 있어서, 상기 공개하는 단계는,

    애플리케이션으로부터 결합형 XDM-DCD 클라이언트에 선호도들을 제공하는 단계와;

    선호도들을 XDM 서버에 전송하는 단계와;

    XDM 서버로부터 DCD 서버에 선호도들을 검색하는 단계

    를 포함하는 것인 애플리케이션 선호도들의 제공 방법.
11. 제2항 또는 제3항에 있어서, 상기 공개하는 단계는,

    애플리케이션으로부터 DCD 클라이언트에 선호도들을 제공하는 단계와;

    XDM 인식 DCD(XDM aware DCD) 서버에 선호도들을 전송하는 단계와;

    XDM 인식 DCD(XDM aware DCD) 서버로부터 XDM 서버에 선호도들을 전달하는 단계

    를 포함하는 것인 애플리케이션 선호도들의 제공 방법.
12. 제2항 또는 제3항에 있어서, 상기 공개하는 단계는,

    XDM 인식 애플리케이션으로부터 XDM 서버에 선호도들을 제공하는 단계와;

    XDM 서버로부터 DCD 서버에 선호도들을 검색하는 단계와;

    DCD 서버로부터 DCD 클라이언트에 선호도들을 푸시하는 단계

    를 포함하는 것인 애플리케이션 선호도들의 제공 방법.
13. 제1항 내지 제3항 중 어느 한 항에 있어서,

    상기 공개는 제1 인에이블러로 하여금 제2 인에이블러를 이용할 수 있게 하고, 상기 제1 인에이블러는 XDM 리포지토리에서의 제1 브랜치를 이용하고 상기 제2 인에이블러는 제2 브랜치를 이용하는 것인 애플리케이션 선호도들의 제공 방법.
14. 제13항에 있어서, 상기 제1 브랜치 및 제2 브랜치는 별도의 XDM 리포지토리들에 위치되어 있는 것인 애플리케이션 선호도들의 제공 방법.
15. 컨텐츠 전달 시스템에의 애플리케이션 선호도 등록을 위한 시스템으로서,

    XDM 서버 상에 있고, 모바일 서비스들 간의 관계들과 관련된 선호도들을 저장하도록 구성된 XDM 리포지토리와;

    모바일 서비스들 간의 관계들과 관련된 선호도들을 공개하도록 구성된 XDM 클라이언트

    를 포함하는 애플리케이션 선호도 등록을 위한 시스템.
16. 제15항에 있어서, 상기 선호도들은 동적 컨텐츠 전달 'DCD' 인에이블러에 대한 애플리케이션 선호도들이고,

    DCD 서버 및 DCD 클라이언트를 더 포함하는 애플리케이션 선호도 등록을 위한 시스템.
17. 제16항에 있어서, 상기 애플리케이션 선호도들은 일반 또는 컨텐츠 특정 애플리케이션 선호도들인 것인 애플리케이션 선호도 등록을 위한 시스템.
18. 제16항 또는 제17항에 있어서, 상기 DCD 서버 및 DCD 클라이언트에 대한 선호도들은 XDM 리포지토리의 애플리케이션 사용 유저 브랜치에 저장되는 것인 애플리케이션 선호도 등록을 위한 시스템.
19. 제16항 또는 제17항에 있어서,

    상기 XDM 클라이언트는 애플리케이션으로부터 선호도들을 수신하고 XDM 서버에 선호도들을 전송하도록 구성되고,

    상기 DCD 서버는 XDM 서버로부터 선호도들을 검색하고 DCD 클라이언트에 선호도들을 푸시하도록 구성되는 것인 애플리케이션 선호도 등록을 위한 시스템.
20. 제16항 또는 제17항에 있어서,

    상기 XDM 클라이언트는 애플리케이션으로부터 선호도들을 수신하고 XDM 서버 에 선호도들을 전송하도록 구성되며,

    상기 DCD 클라이언트는 XDM 서버와 XDM 클라이언트 사이에서 하이퍼텍스트 전송 프로토콜 프록시로서 이용되도록 구성되며 이 이용에 의해 DCD 클라이언트에서부터 선호도들을 검색하고,

    DCD 클라이언트 또는 XDM 서버는 DCD 서버에 선호도들을 전송하도록 추가로 구성되는 것인 애플리케이션 선호도 등록을 위한 시스템.
21. 제16항 또는 제17항에 있어서, 상기 XDM 클라이언트는 DCD 클라이언트 또는 DCD 서버와 결합되는 것인 애플리케이션 선호도 등록을 위한 시스템.
22. 제16항 또는 제17항에 있어서, 상기 XDM 클라이언트는 애플리케이션과 결합되는 것인 애플리케이션 선호도 등록을 위한 시스템.
23. 제15항 내지 제17항 중 어느 한 항에 있어서,

    제2 인에이블러의 선호도들을 이용하도록 구성되는 제1 인에이블러를 더 포함하며,

    상기 제1 인에이블러는 XDM 리포지토리에서의 제1 브랜치를 이용하고 상기 제2 인에이블러는 제2 브랜치를 이용하는 것인 애플리케이션 선호도 등록을 위한 시스템.
24. 제23항에 있어서, 상기 제1 브랜치 및 제2 브랜치는 별도의 XDM 리포지토리들에 위치되어 있는 것인 애플리케이션 선호도 등록을 위한 시스템.
25. 서버의 프로세서에 의해 수행될 때 상기 서버가 제1항 내지 제3항 중 어느 한 항에 기재된 방법을 수행할 수 있도록 하는 컴퓨터 판독가능 명령들을 베어링하는 컴퓨터 판독가능 기록 매체.

Images