KR100977502B1

KR100977502B1 - 푸시 콘텐츠 전달 시스템에 의한 클라이언트 애플리케이션및 콘텐츠 제공자의 조정된 플러그-인 등록

Info

Publication number: KR100977502B1
Application number: KR1020070091088A
Authority: KR
Inventors: 마이클 센필드
Original assignee: 리서치 인 모션 리미티드
Priority date: 2006-09-07
Filing date: 2007-09-07
Publication date: 2010-08-23
Also published as: SG140563A1; MX2007010864A; JP2011100490A; HK1110457A1; AU2007211960B2; JP5061249B2; TW200820703A; EP1898597B1; CA2600190C; CA2600190A1; DE602006004049D1; KR20080023195A; CN101141479A; JP2008065825A; JP4681588B2; BRPI0703509A; ATE416558T1; AU2007211960A1; TWI357248B; EP1898597A1

Abstract

푸시 콘텐츠 전달 시스템에서 범용 엘리먼트를 콘텐츠 전달 아키텍쳐에 접속하는 방법 및 장치를 제공하고, 상기 방법은 범용 엘리먼트와 콘텐츠 전달 아키텍쳐 사이에 메디에이터를 제공하는 단계와; 범용 엘리먼트에 대한 메디에이터 메타데이터를 추출하는 단계와; 콘텐츠 전달 아키텍쳐에 범용 엘리먼트를 등록하는 단계를 포함한다.

Description

푸시 콘텐츠 전달 시스템에 의한 클라이언트 애플리케이션 및 콘텐츠 제공자의 조정된 플러그-인 등록{MEDIATED PLUG-IN REGISTRATION OF CLIENT APPLICATIONS AND CONTENT PROVIDERS WITH PUSH CONTENT DELIVERY SYSTEM}

본 발명은 일반적으로 모바일 환경에서의 동적 콘텐츠 전달(dynamic content delivery)에 관한 것이고, 특히, 범용(generic) 애플리케이션 또는 범용 콘텐츠 제공자를 이용한 동적 콘텐츠 전달에 관한 것이다.

모바일 장치 또는 모바일 사용자 설비(UE)의 사용자는 그들이 자신의 모바일 장치로부터 요구하는 기능성 및 그들이 모바일 장치로부터 데이터를 액세스하는 방법면에서 점점 더 복잡해지고 있다.

동적 콘텐츠 전달은 사용자가 데이터에 접근하여 탐색하는 대신 그들에게 푸시(push)된 정보 또는 데이터를 가질 수 있게 한다. 데이터의 예로는 주식 시세, 날씨 정보, 교통 정보, 동적 배경 화면(dynamic wallpaper), 광고, 애플리케이션 또는 사용자에게 유용한 다른 데이터가 있다.

무선 응용 통신 규약(wireless application protocol; WAP)과 같은 모바일 장치의 현재 기술은 콘텐츠를 푸시하는 능력이 있다. 그러나, WAP은 무선 응용 통 신 규약을 만족시키기 위해 재기록할 웹사이트를 요구하고, 사이트를 보는 사용자 능력을 수용(accommodate)하도록 변경되지 않는 균일한 사이트를 사용자에게 제공한다.

다른 예로는 SMS 기반 푸시 및 방송 또는 셀 방송이 있다. 방송의 경우, 전달은 특정한 사용자의 요구 또는 특정한 장치의 능력에 맞춤화(customize)될 수 없다. 그러므로, 이 시스템들은 그들과 관련된 지능(intelligence)이 없다. 모바일 장치에 대하여 더 나은 솔루션이 요구된다.

동적 콘텐츠 전달에 있어서, 범용(generic) 푸시 클라이언트는 장치에서 다중 목표 애플리케이션(target application)으로서 작용한다. 유사하게, 푸시 프럭시(push proxy)는 다중 콘텐츠 제공자에게 서비스를 제공한다. 애플리케이션 및 콘텐츠 제공자가 다른 애플리케이션 또는 콘텐츠 제공자에 대한 서비스를 중단하지 않고 동적 콘텐츠 전달 프레임워크에 등록할 수 있는 효과적인 런타임 등록 메카니즘을 제공하는 것이 필수적이다. 가끔, 클라이언트 애플리케이션 또는 콘텐츠 제공자는 범용적인 것이고, 특정 콘텐츠 전달 시스템의 고유 지식(intrinsic knowledge)을 갖지 않는다.

본 발명의 시스템 및 방법은 아키텍쳐(architecture)를 수정할 필요없이 범용 애플리케이션 및 콘텐츠 제공자가 시스템에 부가될 수 있게 하는 동적 콘텐츠 전달 아키텍쳐 및 시스템을 제공한다. 더 구체적으로 말하면, 본 발명의 시스템 및 방법은 모바일 장치가 애플리케이션의 부가가 가능하고 콘텐츠를 모바일 장치에 제공할 수 있는 동적 애플리케이션 플랫폼으로 될 수 있게 한다. 여기에서 상기 동적 콘텐츠 전달 시스템의 아키텍쳐는 장치에 설치될 수 있는 애플리케이션의 유형 또는 장치가 수신하는 콘텐츠의 유형을 제한하지 않는다.

본 발명의 한 양태에서, 메타데이터가 제공되고, 이 메터데이터는 동적 콘텐츠 전달 아키텍쳐 내의 각종 처리 엘리먼트의 콘텐츠에 지능을 추가하기 위해 콘텐츠와 관련될 수 있다. 이 아키텍쳐는 콘텐츠 프로비져닝(provision), 푸시 프럭시를 포함한 서비스 프로비져닝, 무선 네트워크, 푸시 클라이언트 및 클라이언트 애플리케이션을 제공하는 논리 컴포넌트들을 포함할 수 있다.

본 발명의 다른 양태에서, 메타데이터는 푸시 콘텐츠 메타데이터에 대한 계층화형 "엔벨로프" 모델에 제공될 수 있다. 콘텐츠는 푸시 프레임워크 내의 각 엘리먼트에서 처리를 위해 사용될 수 있는 메타데이터로 랩핑(wrap)될 수 있다. 각각의 연속적인 엘리먼트에 대한 메타데이터는 계층화(layered)될 수 있고, 이것에 의해 처리 엘리먼트가 그 엘리먼트에 대한 메타데이터만을 추출할 수 있다. 예를 들면, 푸시 프럭시 및 클라이언트 애플리케이션에 보내진 메타데이터를 포함하는 콘텐츠 패키지는 클라이언트 애플리케이션에 대한 제1 레벨의 메타데이터와 푸시 프럭시에 대한 제2 레벨의 메타데이터를 가진 콘텐츠를 포함할 수 있다. 이것에 의해, 엔벨로프가 푸시 프럭시에 도달할 때, 푸시 프럭시용 메타데이터가 추출되어 콘텐츠에 적용될 수 있고, 클라이언트 애플리케이션에 대한 수정된 콘텐츠 및 메타데이터는 추가의 처리 엘리먼트로 전달된다.

본 발명의 다른 양태에서, 메타데이터는 정적 메타데이터(이 명세서에서 채널 메타데이터라고도 부름) 및 동적 메타데이터(이 명세서에서 콘텐츠 메타데이터라고도 부름)로 분리될 수 있다. 정적 메타데이터는 애플리케이션 및 콘텐츠 제공자 양쪽의 등록시에 바람직하게 확립될 수 있다. 그러나, 채널 메타데이터는 나중 시간에 확립될 수 있다. 채널 메타데이터는 전달되는 콘텐츠의 유형 및 콘텐츠 유형의 애플리케이션 필요조건에 특정되는 처리 규칙을 지정할 수 있다.

동적 메타데이터는 전달되는 특정 콘텐츠와 역으로 관련될 수 있다.

본 발명의 다른 양태에서, 플러그-인 등록 모델(plug-in registration model)은 푸시 프레임워크 내에 존재할 수 있다. 범용 푸시 클라이언트 및 푸시 프럭시가 식별(identify)되고, 각종 처리 블록 또는 모듈들을 각각 가지며, 각종 처리 블록 또는 모듈들은 이들 엘리먼트가 콘텐츠 및 메타데이터 양쪽을 처리할 수 있게 한다. 이 블록들은 전달되는 콘텐츠, 전달되는 메타데이터, 또는 전달되는 콘텐츠와 메타데이터 양쪽을 처리하도록 지시될 수 있다.

플러그-인 등록은 또한 콘텐츠 제공자와 애플리케이션 사이에서 채널 메타데이터의 확립을 가능하게 하는 서비스 매니페스트(manifest) 및 애플리케이션 매니 페스트의 전달을 제공한다. 구체적으로, 서비스 매니페스트는 푸시 프레임워크에 콘텐츠 제공자를 등록하기 위해 사용되고, 애플리케이션 매니페스트는 푸시 프레임워크에 애플리케이션을 등록하기 위해 사용될 수 있다.

본 발명의 다른 양태에서, 합성된 콘텐츠(syndicated content)를 푸시하는 방법이 제공되는데, 이 방법은 우선순위에 기초해서 및 데이터를 전송하는데 드는 비용, 접속된 네트워크의 유형 또는 사용자 선호도(preference)를 포함하는 네트워크 인자에 기초해서 데이터를 취급할 수 있게 한다. 합성된 콘텐츠의 선택적인 혼합 푸시/풀 모델은 네트워크 조건이 적합하게 될 때 푸시 프록시가 콘텐츠를 푸시하게 하는 것 또는 네트워크 조건이 적합하게 되거나 사용자가 콘텐츠를 요구할 때 클라이언트가 콘텐츠를 풀(pull)하게 하는 것을 가능하게 한다.

각종 모바일 장치를 수용하기 위해, 본 발명의 또다른 양태은 비선형 콘텐츠 프래그먼트화(fragmentation)를 비롯해서 콘텐츠에 대한 콘텐츠 프래그먼트화를 제공할 수 있다. 비선형 콘텐츠 프래그먼트화는 데이터가 클라이언트에게 전달되었을 때 데이터를 재구성할 수 있게 하는 메타데이터로 콘텐츠를 증가시킨다.

본 발명의 또다른 양태에서, 범용 애플리케이션 또는 콘텐츠 제공자는 조정된(mediated) 플러그-인 등록 모델을 이용하여 특정 콘텐츠 전달 인에이블러(CDE)에 접속될 수 있다. 조정된 플러그-인 등록에 의해 메디에이터(mediator)는 전용 애플리케이션, 무선(over-the-air) 애플리케이션 메타데이터 프로비져닝을 이용하는 범용 메디에이터 애플리케이션, 또는 전달 프레임워크 인식 런타임 환경 중의 어느 하나일 수 있다.

상기 및 기타 양태들은 도면을 참조한 상세한 설명으로부터 확인될 것이다.

그러므로, 본 출원은 푸시 콘텐츠 전달 시스템의 콘텐츠 전달 아키텍쳐에 범용 엘리먼트를 접속하는 방법을 제공하는데, 이 방법은 범용 엘리먼트와 콘텐츠 전달 아키텍쳐 사이에 메디에이터를 제공하는 단계와; 범용 엘리먼트의 메디에이터 메타데이터를 추출하는 단계와; 범용 엘리먼트를 콘텐츠 전달 아키텍쳐에 등록하는 단계를 포함한다.

푸시 콘텐츠 전달 시스템의 콘텐츠 전달 아키텍쳐에 범용 엘리먼트를 접속하는 메디에이터는 메타데이터를 추출하는 추출 수단과; 범용 엘리먼트의 등록 정보를 콘텐츠 전달 구조에 제공하는 등록 수단을 포함한다.

본 발명은 첨부 도면을 참조한 이하의 설명으로부터 더 잘 이해될 수 있을 것이다.

본 발명에 따르면, 푸시 콘텐츠 전달 시스템의 콘텐츠 전달 아키텍쳐에 범용 엘리먼트를 접속하는 것을 실현할 수 있다.

이제 도 1을 참조한다. 클라이언트 애플리케이션에 동적 콘텐츠를 전달하는 범용 푸시 시스템을 설명한다. 도 1의 시스템은 단순화시킨 시스템이고, 동적 콘텐츠 전달 아키텍쳐에 있어야 할 논리 컴포넌트들을 도시하지만, 다른 컴포넌트들이 있을 수 있고 각종 컴포넌트들이 함께 그룹지어질 수 있다는 것을 당업자라면 잘 알 것이다.

아키텍쳐(100)는 콘텐츠 제공자(110)를 포함한다. 콘텐츠 제공자(110)는 콘 텐츠 제공자(110)에게 가입된 사용자에게 동적 콘텐츠를 제공하도록 구성된다. 그 예를 들자면 책을 판매하는 웹사이트가 있을 수 있다. 사용자는 특정 장르(genre)에서 새로 출간된 책의 목록을 얻기 위해 콘텐츠 제공자(110)에게 등록할 수 있다. 다른 예로는 주기적인 방식으로 사용자에게 헤드라인을 제공하는 뉴스 사이트, 하루 중의 특정 기간동안 사용자에게 최신 교통 정보를 제공하는 교통 사이트, 업데이트된 주식 시세 또는 환율을 사용자에게 제공하는 주식시장 사이트 등이 있다.

뒤에서 더 자세히 설명하겠지만, 콘텐츠 제공자(110)는 서비스 제공자(120)에 등록하여 서비스 제공자의 클라이언트가 콘텐츠 제공자(110)로부터 콘텐츠를 수신할 수 있게 한다. 서비스 제공자(120)는 클라이언트 또는 클라이언트 애플리케이션에 대한 프럭시로서 작용하고 콘텐츠 제공자(110)가 콘텐츠를 전송할 목적지를 제공하는 푸시 프럭시(122)를 포함한다.

서비스 제공자(120)는 모바일 장치에 위치하고 있는 푸시 클라이언트(140)와 무선 네트워크(130)를 통해 통신한다. 푸시 클라이언트(140)에 대해서는 뒤에서 더 자세히 설명된다. 푸시 클라이언트(140)는 콘텐츠 제공자(110)로부터 전달된 콘텐츠를 수신하고 콘텐츠를 최종적으로 소비하는 클라이언트 애플리케이션(150)에 콘텐츠를 전송할 수 있다.

이 명세서에서, 콘텐츠 제공자(110), 서비스 제공자(120), 푸시 프럭시(122), 무선 네트워크(130), 푸시 클라이언트(140) 또는 클라이언트 애플리케이션(150)을 인용할 때는 도 1의 아키텍쳐를 다시 참조한다.

도 2를 참조하면, 도 1의 컴포넌트들은 단지 논리적 컴포넌트들이고 반드시 물리적 컴포넌트들로 분리하지는 않는다는 것을 쉽게 이해할 것이다. 도 1은 하나의 콘텐츠 제공자(110), 하나의 푸시 프럭시(122), 하나의 푸시 클라이언트(140) 및 하나의 클라이언트 애플리케이션(150)이 있는 범용 아키텍쳐를 나타낸 것이다. 대안적인 예는 도 2에 도시되어 있다.

구체적으로, 제1의 대안적 아키텍쳐(210)는 푸시 프럭시(122)와 통신하는 다수의 콘텐츠 제공자(110)를 포함한다. 푸시 프럭시(122)는, 도 1의 아키텍쳐에서와 마찬가지로, 무선 네트워크(130)를 통하여 푸시 클라이언트(140)와 통신한다. 또한, 이 아키텍쳐(210)에는 다수의 클라이언트 애플리케이션(150)이 존재한다. 그러므로, 이 아키텍쳐는 다수의 콘텐츠 제공자(110)와 다수의 클라이언트 애플리케이션(150)이 있는 N-1-1-N 시스템이다.

도 2의 아키텍쳐(220)는 푸시 프럭시(122)와 통신하고 푸시 프럭시(122)에 등록된 하나의 콘텐츠 제공자(110)를 포함한다. 또한, 푸시 프럭시(122)는 무선 네트워크(130)를 통하여 다수의 푸시 클라이언트(140)와 통신한다. 각각의 푸시 클라이언트(140)는 클라이언트 애플리케이션(150)과 통신한다. 그러므로, 이 아키텍쳐(220)는 클라이언트 애플리케이션(150)과 푸시 클라이언트(140)의 논리 컴포넌트들을 그룹짓는 N(1-1)-1-1 시스템이다.

도 2의 아키텍쳐(230)는 콘텐츠 제공자(110)와 각각 통신하는 다수의 푸시 프럭시(122)를 갖는다. 각각의 푸시 프럭시와 콘텐츠 제공자의 조합(232)은 무선 네트워크(130)를 통해 범용 푸시 클라이언트(140)와 통신하고, 푸시 클라이언트(140)는 그 다음에 클라이언트 애플리케이션(150)과 통신한다. 이것은 1-1-N(1-1) 시스템이다.

도 2의 아키텍쳐(240)에서, 콘텐츠 제공자(110)와 푸시 프럭시(122)의 그룹(232)은 무선 네트워크(130)를 통해 범용 푸시 클라이언트(140)와 클라이언트 애플리케이션(150)의 조합과 통신한다. 그러므로, 이것은 N(1-1)-N(1-1) 시스템이다.

당업자라면 잘 알 수 있는 바와 같이, 다른 대안적인 예도 가능하다. 상기 예는 별도의 물리 컴포넌트로 존재하거나 함께 그룹지어질 수 있는 각종 논리 컴포넌트들을 보여준다. 예를 들면, 푸시 클라이언트는 애플리케이션에 매립(embedded)될 수 있고, 공통 공유 클라이언트(common shared clients)는 다중 애플리케이션 또는 다른 대안적인 것에 의해 사용될 수 있다.

이제 도 3을 참조한다. 시스템에 지능(intelligence)을 추가하기 위해 콘텐츠는 메타데이터와 관련된다. 이 경우, 메타데이터는 콘텐츠를 관리하기 위해 처리 엘리먼트가 사용할 수 있는 데이터로서 정의된다. 잘 알려져 있는 바와 같이, 범용 푸시 시스템은 각종 콘텐츠 제공자 및 애플리케이션이 시스템 내에 존재할 수 있게 하기 위해 메타데이터를 요구한다. 메타데이터는 각종 형태의 것일 수 있고, 그 예를 들자면, 처리 파라미터 또는 규칙, 또는 직접 제공된 처리 핸들러, 코드 또는 기준 또는 다른 장소에 있는 처리 핸들러, 코드 또는 규칙에 대한 링크 등이 있다.

도 3에서 알 수 있는 바와 같이, 콘텐츠는 콘텐츠 제공자(110)로부터 클라이언트 애플리케이션(150)에게 전달되고, 이것은 화살표 310으로 표시되어 있다. 아키텍쳐(100) 내의 각종 컴포넌트들에게 명령을 제공하는 메타데이터는, 일반적으로 콘텐츠와 함께, 아키텍쳐(100) 내의 컴포넌트들 사이에서 또한 전달될 수 있다. 예를 들면, 화살표 320은 콘텐츠 제공자에서 시작해서, 메타데이터가 클라이언트 애플리케이션(150)에 도달할 때까지 전달 시스템에 투명한 메타데이터를 묘사하고 있다.

화살표 330은 콘텐츠 제공자(110)에 의해 생성되어 푸시 클라이언트(140)용으로 의도된 메타데이터를 보여주고 있으며, 따라서 이 메타데이터는 범용 푸시 클라이언트(140)에게만 흐른다.

화살표 340은 서비스 제공자(120)에 의해 발생되어 푸시 클라이언트(140)용으로 의도된 메타데이터를 보여주고 있으며, 따라서 이 메타데이터는 푸시 프럭시(122)에서 콘텐츠와 최초 관련되고 범용 푸시 클라이언트(140)에서는 콘텐츠로부터 제거된다. 이것이 발생할 수 있는 예로는 제공될 서비스의 레벨과 과금 계획(billing plan)에 관한 사용자와 서비스 제공자 간의 협약이 있고, 이때 서비스 제공자는 메타데이터를 이용하여 가용 서비스를 제한하거나 개선된 서비스를 제공할 수 있다.

메타데이터의 흐름과 메타데이터의 역할은 뒤에서 더 자세히 설명된다.

이제 도 4를 참조한다. 도 4는 본 발명의 시스템 및 방법과 관련하여 사용될 수 있는 예시적인 상세한 푸시 프럭시(410)를 도시한 것이다. 당업자라면 잘 알 수 있는 바와 같이, 푸시 프럭시(410)는 도 1 및 도 2의 푸시 프럭시(122)와 동일한 것일 수 있다.

도 4의 푸시 프럭시(410)는 푸시 프럭시(410)가 범용 푸시 환경에서 동작할 수 있게 하는 각종 엘리먼트들을 포함한다. 이것은 푸시 프럭시가 특정 콘텐츠 제공자 또는 푸시 클라이언트와의 상호작용으로 제한되지 않고 그 대신 동적 환경에 채택될 수 있기 때문에 유연성(flexibility)을 촉진한다. 푸시 프럭시(410)에 대하여 이하에서 설명하는 엘리먼트들은 푸시 프럭시(410) 내에 있는 것이 바람직하지만, 이 엘리먼트들이 전부는 아니고 다른 엘리먼트들도 가능하다. 또한, 특정 엘리먼트들을 푸시 프럭시(410)로부터 제거하고 나머지 엘리먼트들이 범용 푸시 서비스를 수행하게 하는 것도 가능하다.

푸시 프럭시(410)는 그 푸시 프럭시(410)에 등록된 콘텐츠 제공자(412)를 포함한다. 콘텐츠 제공자(412)는 콘텐츠 제공자 등록 서비스 제공자 인터페이스(SPI)(420)를 이용하여 등록한다. 뒤에서 더 자세히 설명하는 바와 같이, 이 등록에서는 콘텐츠 제공자(412)가 여기에서 채널 메타데이터로서 인용되는 확립될 채널에 대한 특정 정보를 포함하는 것이 바람직하다. 콘텐츠 제공자(412)는 도 1의 콘텐츠 제공자(110)와 동일한 것일 수 있다.

푸시 프럭시(410)는 또한 푸시 프럭시 서비스를 관리하기 위한 서비스 관리 블록(430)을 포함한다.

푸시 프럭시(410)는 콘텐츠 및 이 콘텐츠와 관련된 메타데이터를 취급하기 위한 각종 모듈을 포함한다. 제1 모듈은 메시지 브로커 및 전달 큐(delivery queue)(440)이고, 이것은 콘텐츠 제공자(412)로부터의 메시지를 소비함과 아울러 콘텐츠 전달 큐를 관리하는 서브시스템이다. 당업자라면 잘 알 수 있는 바와 같이, 모든 클라이언트 애플리케이션에 대한 모든 콘텐츠가 한번에 전달될 수 있는 것은 아니기 때문에, 전달 큐는 콘텐츠를 순조롭게 전달하기 위하여 확립될 필요가 있다. 예를 들면, 장치는 커버리지(coverage) 밖에 있을 수 있고, 콘텐츠는 저장될 필요가 있을 수 있다.

푸시 프럭시(410)는 흐름 제어 관리 블록(442)를 또한 포함한다. 흐름 제어 관리 블록(442)은 콘텐츠 흐름의 제어를 가능하게 한다. 예를 들면, 제한된 공간을 갖는 이동국(mobile station)은 특정량의 정보만을 수신하는 것이 가능할 수 있다. 이 경우, 모바일 장치는, 도 1에 도시된 푸시 클라이언트(140)를 통하여, 푸시 클라이언트(140)로의 데이터 흐름을 중단시키도록 푸시 프럭시(410)에게 요청할 수 있다. 흐름 제어 관리 블록(442)은 이것을 취급한다.

대안적으로, 모바일 장치는 오프라인에 있을 수 있다. 흐름 제어 관리 블록(442)은 콘텐츠가 푸시 프럭시(410)에 의해 수신된 대로 전달될 수 없을 때 푸시 클라이언트(140)에게로의 데이터 흐름을 중단 및 개시한다.

푸시 프럭시(410)의 추가 컴포넌트는 푸시 에이전트(444)이다. 푸시 에이전트(444)는 데이터를 클라이언트에게 보내는 책임을 갖는다.

당업자라면 잘 알 수 있는 바와 같이, 블록 440, 442 및 444는 메시징만을 취급하고 메타데이터와 관련되지 않는다. 다시 말해서, 상기 블록들은 메시지의 콘텐츠를 취급하지만 콘텐츠와 관련된 어떠한 메타데이터도 취급하지 않는다.

푸시 프럭시(410)의 추가 컴포넌트는 콘텐츠 메타데이터 추출기 및 캐시 블록(450)이다. 콘텐츠 메타데이터 추출기 및 캐시 블록(450)은 엔벨로프 콘텐츠 메타데이터에서 동작한다. 구체적으로, 뒤에서 더 자세히 설명하는 메타데이터 시스템의 엔벨로프 모델에서, 시스템 내의 각 논리 컴포넌트는 콘텐츠 처리와 관련된 메타데이터를 가질 수 있다. 이 메타데이터는 논리 컴포넌트가 콘텐츠에서 행동(action)들을 수행할 수 있게 한다. 따라서, 각 논리 컴포넌트는 그 컴포넌트와 관련된 메타데이터를 추출할 수 있어야 한다.

콘텐츠 메타데이터 추출기 및 캐시 블록(450)은 푸시 프럭시(410)와 관련된 메타데이터를 추출하고 이 메타데이터를 캐시하는 책임을 갖는다. 캐시 기능은 동일한 콘텐츠 제공자로부터 다음 콘텐츠 엔벨로프의 동일한 메타데이터를 전달할 필요성을 제거함으로써 최적화를 가능하게 한다. 메타데이터의 추출 및 캐시에 대해서는 뒤에서 설명한다.

지연 검색 메시지 저장 블록(452)은 콘텐츠 또는 그 일부를 클라이언트 애플리케이션에 전달하기에 효과적이지 않을 때 사용된다. 지연 검색 메시지 저장 블록(452)은 콘텐츠를 전송하는 것이 효과적일 때까지, 또는 콘텐츠가 클라이언트에 의해 풀링(pull) 될 때까지 클라이언트에 전달되지 않은 콘텐츠를 저장하기 위해 사용된다. 지연 검색 메시지 저장은 이미 전달된 콘텐츠를 통한 클라이언트 애플리케이션 내비게이션에 따라 클라이언트에게 선택적으로 전송되거나 클라이언트에 의해 풀링 수 있는 보조 콘텐츠를 캐시하기 위해 또한 사용된다.

지연 검색 메시지 저장 블록(452)의 목적은 도 19 및 도 21을 참조하여 뒤에서 자세히 설명된다. 예를 들면, 지연 검색 메시지 저장 블록(452)이 사용되는 경우는 사용자가 사용자의 위치에서 가까운 식당과 같은 위치 정보를 요구한 경우이다. 콘텐츠 제공자 또는 서비스 제공자는 제공하는 정보의 모델을 가질 수 있고, 이때 광고자는 그들의 정보를 탐색 요구에 추가하도록 비용을 지불할 수 있다. 따라서, 위치에 대해서 식당 정보를 요구하는 사용자는 그들의 요구에 수반된 그들의 위치에서 가까운 상점, 골프 코스, 체육관 또는 다른 서비스에 관한 정보를 가질 수 있다. 콘텐츠 제공자는 요구된 식당 정보를 추가적인 정보와 함께 묶어서 그 묶음을 푸시 프럭시(410)에게 전달한다.

푸시 프럭시(410)는, 제공된 메타데이터에 기초해서, 클라이언트에게 보낼 콘텐츠 패키지를 생성한다. 콘텐츠 패키지는 클라이언트가 요구한 정보뿐만 아니라 사용자가 관심을 가질만한 관련 정보의 요약(digest) 또는 개요(summary)를 포함할 수 있다. 개요는 사용자에게 보내지지만, 지연 검색 메시지 저장 블록(452)은 콘텐츠 제공자(110)로부터 수신한 실제 데이터를 저장한다. 따라서, 만일 장래에 사용자가 요약 내의 정보에 대한 더욱 상세한 정보를 얻기 원하면, 이 정보는 푸시 프럭시(410)에 이미 저장되어 있다.

지연 검색 메시지 저장 블록(452)의 대안적인 사용은 사용자가 전체 콘텐츠를 한번에 수용할 수 없는 경우이다. 예를 들어서, 만일 모든 콘텐츠를 장치에 보내는 것이 불가능하거나 경제적이지 못하면, 콘텐츠가 클라이언트에 의해 풀링되거나 또는 미리 규정된 규칙에 부합하여 푸시되는 나중 시간까지 콘텐츠의 일부가 저장될 수 있다. 이 규칙들은 특정 네트워크 또는 서비스 조건이 만족될 때 네트워크 또는 서비스 조건에 의해 지정될 수 있다. 이것에 대해서는 도 19를 참조하여 뒤에서 더 자세히 설명된다.

푸시 스케쥴러(454)는 클라이언트의 전달 슬롯을 계획한다. 전술한 바와 같이, 어떤 상황에서, 모든 콘텐츠를 한번에 푸시하는 것이 효율적이지 않을 수 있다. 푸시 스케쥴러(452)는 일부 정보는 즉시 푸시하고 나머지는 미리 규정된 스케 쥴에 따라 푸시하는 것을 결정할 수 있다. 또한, 푸시 스케쥴러(454)는 콘텐츠의 속성을 이용하여 콘텐츠가 언제 푸시되어야 하는지를 결정할 수 있다. 구체적으로, 메타데이터는 어떤 콘텐츠가 높은 우선순위에 있는지 또는 시간적으로 제한된 만료를 갖는지를 표시할 수 있고, 이 콘텐츠는 즉시 푸시되는 한편, 낮은 우선순위를 갖거나 만료가 없다고 표시된 콘텐츠는 데이터 전송 조건이 더 나은 때의 나중 시점에서 푸시될 수 있다.

당업자라면 잘 알 수 있는 바와 같이, 블록 450, 452 및 454는 메지지의 콘텐츠 및 그 메시지와 관련된 메타데이터를 취급한다.

가입 및 규칙 블록(460)은 서비스를 수신하기 위해서 및 전달되는 특정 콘텐츠를 취급하는 법에 대한 규칙들을 감시하기 위해서 등록되어 있는 애플리케이션들을 추적한다. 콘텐츠는 전형적으로 클라이언트에 의한 또는 클라이언트를 대신한 가입(subscription)에 기초하여 전달된다. 사용자는, 예컨대 그들이 특정한 서비스를 원한다면, 가입을 적극적으로 요구할 수 있다. 가입은 예를 들어서 만일 사용자가 서비스의 잇점(benefit)을 수신하기 위해 서비스 제공자(120)와의 협약에 서명하였다면 사용자를 대신하여 행하여질 수 있다. 이것은 사용자가 매일 특정 수의 광고를 수신하는 것에 동의하는 한 사용자가 선호 가격(preferred rate)을 수신하는 경우를 포함한다. 이 경우, 서비스 제공자(120)는 클라이언트를 대신하여 광고 제공자에 대한 가입을 할 수 있다.

애플리케이션이 모바일 장치에서 삭제되었을 때 또는 애플리케이션이 가입으로부터 미등록되었을 때, 가입 및 규칙 블록(460)은 그 사용자를 가입시키지 않을 수 있다.

콘텐츠 의존 블록(462)은 모바일 장치 사용자가 활용할 수 있는 서비스를 광고하기 위해 푸시 프럭시(410)에서 사용된다. 따라서, 만일 모바일 장치 사용자가 서비스에 대한 충분한 스크린 또는 대역폭 또는 메모리를 갖고 있지 않으면, 콘텐츠 의존 블록(462)은 사용자에 대한 서비스의 광고를 차단할 수 있다.

콘텐츠 프래그먼트화 블록(464)은 콘텐츠를 프래그먼트화시키기 위해 사용된다. 이것은 예를 들어서 만일 모바일 장치가 모든 콘텐츠를 한번에 수신할 수 없을 경우에 사용될 수 있다. 콘텐츠 프래그먼트화 블록(464)은 콘텐츠를 각종 컴포넌트로 나누기 위해 사용된다. 이 블록은 아직 전달되지 않은 프래그먼트화된 콘텐츠를 저장하기 위해 지연 검색 및 메시지 저장 블록(452)과 결합하여 사용될 수 있다.

콘텐츠 만료 및 교체 블록(466)은 2가지 목적으로 사용된다. 첫째, 이 블록은 가입을 감시하기 위해 사용될 수 있다. 각각의 가입은 만료 시간을 가지며, 이 만료 시간이 되었을 때 가입이 종료될 수 있다.

또한 콘텐츠 만료 및 교체 블록(466)은 정보를 감시하기 위해 사용될 수 있다. 특정 콘텐츠는 정보의 유효성에 대한 시간 제한을 가질 것이다. 예를 들면, 러시아워(rush hour)의 교통량을 감시하기 위해 사용되는 교통량 애플리케이션은 매우 시간 의존적이다. 만일, 몇가지 이유로 해서, 푸시 프럭시(410)가 콘텐츠를 모바일 장치로 즉시 전달할 수 없으면, 이 콘텐츠는 나중에 전달하기 위해 콘텐츠 기억장치(480)에 저장된다. 그러나, 만일 콘텐츠가 특수의 지정된 시간 내에 전달되지 않으면, 그 콘텐츠는 만료가 되어 전혀 전달되지 않을 수 있다.

유사하게, 콘텐츠 교체는 정보가 업데이트되는 상황을 취급한다. 예를 들면, 주식 시세를 수신하는 클라이언트 애플리케이션은 최근의 주식 시세만을 원할 수 있다. 따라서, 만일 푸시 프럭시(410)가 주식 시세를 푸시 클라이언트(140)에게 전달할 수 없고 후속하는 주식 시세가 콘텐츠 제공자(110)로부터 수신되면, 후속 주식 시세 내의 메타데이터는 후속 주식 시세가 이전 주식 시세 교체용으로 사용되어야 한다는 것을 표시할 수 있다. 전달 큐에 모든 정보를 추가하는 대신 저장된 정보를 교체하면 콘텐츠 기억장치(480) 내의 공간을 자유롭게 할 수 있다.

채널 메타데이터 저장소(repository)(470)는 채널 메타데이터를 저장하기 위해 사용되며, 이것에 대해서는 뒤에서 자세히 설명된다.

위에서는 본 발명의 방법 및 시스템과 함께 사용될 수 있는 예시적인 푸시 프럭시(410)를 설명하였다. 푸시 프럭시(410)의 블록들 및 엘리먼트들은 콘텐츠의 유형 및 애플리케이션에서 콘텐츠의 취급이 가변적이고 미리 정해지지 않은 범용 동적 콘텐츠 전달 시스템에서 푸시 프럭시(410)가 사용될 수 있게 한다.

이제 도 5를 참조한다. 도 5는 본 발명의 시스템 및 방법과 결합하여 사용될 수 있는 푸시 클라이언트(510)를 도시한 것이다. 푸시 클라이언트(510)는 도 1 및 도 2의 푸시 클라이언트(140)와 동일한 것일 수 있다.

당업자라면 잘 알 수 있는 바와 같이, 콘텐츠 및 콘텐츠의 처리가 미리 정해져 있지 않은 범용 시스템에서 사용되는 푸시 클라이언트(510)는 콘텐츠 및 이 콘텐츠와 관련된 메타데이터 양쪽을 수용하기 위해 사용될 수 있는 블록 또는 모듈을 포함하여야 한다. 도 5와 관련하여 정의된 블록들은 전부를 나타내는 것이 아니고, 다른 블록들이 푸시 클라이언트(510) 내에 또한 존재할 수 있다. 또한, 푸시 클라이언트(510) 내의 블록들은, 일부 예에서, 푸시 클라이언트(510) 내의 다른 블록들의 기능성에 지장을 주지 않고 삭제될 수 있다.

푸시 클라이언트(510)는 애플리케이션에 서비스를 제공하고 하나 이상의 애플리케이션(512)은 푸시 클라이언트(510)에 등록할 수 있다. 애플리케이션 등록은 후술될 바와 같이, 등록을 위한 인터페이스로서 애플리케이션 제공자 인터페이스(514)를 이용하고, 애플리케이션 제공자 인터페이스(514)를 추가로 이용하여 애플리케이션에 대한 채널 메타데이터를 추출할 수 있다.

푸시 클라이언트(510)는 푸시 클라이언트(510)를 관리하기 위해 사용되는 클라이언트 관리 블록(520)을 포함한다.

도 4의 푸시 서버(410)와 마찬가지로, 푸시 클라이언트(510)는 메시징을 취급하는 각종 블록, 메타데이터를 취급하는 각종 블록, 및 메시징과 메타데이터 양쪽을 취급하는 각종 블록들을 포함한다.

메시지 브로커 및 애플리케이션 큐(540)는 애플리케이션(512)으로의 전달을 위해 푸시 프럭시(410)로부터의 메시지를 취급한다. 애플리케이션 큐는 애플리케이션(512)에 대한 메시지의 큐이다.

흐름 제어 관리 블록(542)은 콘텐츠의 푸싱을 중단하거나 콘텐츠의 푸싱을 재개시하도록 도 4의 푸시 프럭시(410)에게 통지하기 위해 사용된다. 이것은 예를 들면 푸시 클라이언트(510)가 푸시된 콘텐츠를 수용할 수 있는 제한된 양의 메모리를 갖고 있을 때 사용될 수 있다. 이 경우, 푸시 클라이언트(510)는 푸시 콘텐츠를 소비하기 전에 푸시 프럭시(410)로부터 콘텐츠의 흐름을 중단시킬 필요가 있다. 일단 콘텐츠가 소비되었으면, 흐름 제어 관리 블록(542)은 데이터의 흐름을 다시 시작하기 위해 사용될 수 있다.

푸시 클라이언트(510) 내의 푸시 에이전트(544)는 도 4의 푸시 프럭시(410)로부터 정보를 수신하기 위해 사용된다.

당업자라면 잘 알 수 있는 바와 같이, 메시지 브로커 및 애플리케이션 큐(540), 흐름 제어 관리 블록(542) 및 푸시 에이전트(544)는 메시징을 배타적으로 취급하고 메타데이터는 취급하지 않는다.

콘텐츠 메타데이터 추출기 및 캐시 블록(550)은 푸시 클라이언트(510)에 예정되어진 동적 메타데이터를 추출하기 위해 사용된다. 도 4의 푸시 프럭시(410)와 관련하여 위에서 설명한 바와 같이, 동적 콘텐츠 전달 아키텍쳐의 임의의 처리 엘리먼트는 그들에게 예정되어진 메타데이터를 가질 수 있고, 이 메타데이터는 추출될 필요가 있다. 따라서, 푸시 클라이언트(510)에게 예정되어진 메타데이터는 콘텐츠 메타데이터 추출기 및 캐시 블록(550)에 의해 추출된다.

또한, 콘텐츠 메타데이터 추출기 및 캐시 블록(550)은 메타데이터를 캐시하기 위해 채택되는 것이 바람직하다. 제1 콘텐츠 패키지와 제2 콘텐츠 패키지 사이에서 변화되지 않은 푸시 클라이언트(510)에 대한 메타데이터는 전달될 필요가 없기 때문에 이 메타데이터의 추출을 요구하지 않음으로써 푸시 클라이언트(510)에서의 처리 시간을 절약할 수 있고, 또한 무선 네트워크(130)를 통해 전달되는 푸시 클라이언트(510)에 대한 메타데이터를 요구하지 않음으로써 네트워크 자원을 절약 할 수 있다.

지연 검색 관리자(552)는 수신된 콘텐츠의 파편(fragment)을 분석하고 올바른 방법으로 콘텐츠를 함께 두기 위해 사용된다. 뒤에서 더 자세히 설명하는 바와 같이, 데이터는 선형일 수도 있고 비선형일 수도 있다. 데이터가 비선형이면, 데이터를 재구성하기 위해 메타데이터가 요구되고, 이것은 지연 검색 관리자(552)에 의해 행하여진다. 지연 검색 관리자(552)는 또한 푸시 프럭시(510)의 지연 검색 기억부(452)에서 이용할 수 있는 정보의 요약을 분석하도록 구성되고, 콘텐츠 풀(pull) 브로커(554)(뒤에서 설명됨)를 구동시켜서 사용자가 요구한 때 상기 정보를 검색하게 한다. 이것은 콘텐츠 내비게이션이 콘텐츠 구조 그래프의 특정 브랜치(branch)에 들어갈 때 또는 대역폭 또는 가격 조건이 만족될 때의 예측 검색을 포함한다.

콘텐츠 풀 브로커(554)는 푸시 클라이언트(510)가 특정 상황에서 콘텐츠를 또한 풀링할 수 있는 푸시/풀 모델에서 사용된다. 그러한 상황은 도 19를 참조하여 뒤에서 설명된다.

당업자라면 잘 알 수 있는 바와 같이, 콘텐츠 메타데이터 추출기 및 캐시 블록(550), 지연 검색 관리자(552) 및 콘텐츠 풀 브로커(554)는 메시징 콘텐츠 및 메타데이터를 취급한다.

가입 관리 블록(560)은 도 4의 가입 및 규칙 블록(460)과 동일한 것일 수 있다. 구체적으로, 가입 관리 블록(560)은 가입을 관리하기 위해 사용된다. 만일 애플리케이션이 등록 해제(de-register)되거나 모바일 장치로부터 삭제되면, 가입 관리 블록(560)은 가입을 종료한다. 가입 관리 블록(560)은 또한 가입 채널이 만료가 되었을 때 클라이언트 애플리케이션을 대신하여 재가입할 수 있다.

업데이트 통지 블록(562)은 클라이언트 애플리케이션과 함께 동작하고 새로운 콘텐츠가 애플리케이션을 대기한다는 것을 애플리케이션에게 통지하기 위해 사용된다. 이것은 아래의 3가지 방법 중 한가지로 행하여질 수 있다.

a. 업데이트 통지 블록(562)이 애플리케이션(512)에게 통지할 수 있는 첫번째 방법은 푸시 클라이언트(510)가 콘텐츠를 애플리케이션(512)에 직접 전송하는 것이다.

b. 업데이트 통지 블록(562)이 애플리케이션(512)에게 새로운 콘텐츠를 통지할 수 있는 두번째 방법은 콘텐츠를 콘텐츠 기억 장치(580)에 저장하고 콘텐츠가 대기한다는 것을 애플리케이션(512)에게 선택적으로 통지하는 것이다. 이 경우의 통지는 선택적이다. 구체적으로, 만일 애플리케이션(512)이 자기에게 예정되어진 정보가 특정 메모리 블록에 저장되어 있음을 알고 있으면, 애플리케이션이 새로운 데이터를 갖고 있음을 발견하기 위한 한가지 옵션은 메모리 위치를 주기적으로 폴링하여 메모리 위치에 무엇인가가 기록되어 있는지를 알아보는 것이다. 대안적으로, 업데이트 통지 블록(562)은 데이터가 저장된 위치에 새로운 데이터가 있음을 표시하는 메시지를 애플리케이션(512)에게 전송할 수 있다.

c. 업데이트 통지 블록(562)이 애플리케이션(512)에게 새로운 콘텐츠를 통지할 수 있는 세번째 방법은 콘텐츠를 내부적으로 저장하고 애플리케이션에게 통지하는 것이다. 애플리케이션은 그 다음에 푸시 클라이언트에서 호출하여 콘텐츠를 검색할 수 있다.

콘텐츠 의존 블록(564)은 도 4의 콘텐츠 의존 블록(462)과 동일한 것일 수 있고, 서비스를 모바일 장치에 광고할 것인지 여부를 결정할 수 있다.

콘텐츠 만료 및 교체 블록(566)은 도 4의 콘텐츠 교체 및 만료 블록(466)과 동일한 것일 수 있다. 따라서, 콘텐츠의 만료 및 콘텐츠의 교체는 푸시 서버 또는 푸시 프럭시에 추가하여 푸시 클라이언트(510)에서 취급될 수 있다.

채널 메타데이터 저장소(570)는 애플리케이션(512)에 대한 채널 메타데이터를 저장하기 위해 사용된다.

배경 업데이트 처리 모듈(575)은 애플리케이션(512)이 이용불능일 때 업데이트를 수행하기 위해 사용된다. 배경 업데이트는, 예를 들면, 데이터를 애플리케이션 기억장치 내의 더 새로운 데이터로 교체할 수 있게 한다. 그 다음에, 사용자가 애플리케이션을 시작할 때, 애플리케이션에 의해 디스플레이되는 데이터가 보정되고 업데이트된다.

배경 업데이트 처리 모듈(575)은 처리 규칙을 이용하여 콘텐츠를 애플리케이션에게 허용가능한 포맷으로 변환한다. 이것은 콘텐츠 기억부(580) 내의 콘텐츠를 실행 및 처리할 수 있다.

예를 들자면, 오버나이트 계약자용으로 업데이트되는 작업 목록(task list)은 그 목록에 푸시된 태스크(task)를 가질 수 있다. 태스크 애플리케이션은 이 시간동안 시작되지 않고, 배경 업데이트 처리 모듈(575)이 태스크 애플리케이션에 대한 콘텐츠를 업데이트하기 위해 사용될 수 있다. 이것은 확장형 마크업 언어(XML) 파일을 취급하기 위한 코드로 행하여질 수 있고, "handler.exe"라고 부르는 파일로 장치에 존재할 수 있다. 푸시 클라이언트(510)에서의 배경 업데이트 처리 블록(575)은 XML 문서가 파라미터를 가짐을 전달하는 handler.exe를 실행시킬 수 있다. 그 다음에, 핸들러는 태스크를 애플리케이션의 내부 포맷으로 구성한다.

푸시 클라이언트(510)의 배경 업데이트 처리 블록(575)이 태스크를 애플리케이션 내부 포맷으로 구성하면, 그 다음에 콘텐츠 기억 장치(580)로부터 작업 목록으로 태스크를 읽어들여서 새로운 태스크를 목록에 첨부할 수 있다. 그 다음에, 수정된 태스크를 태스크 애플리케이션이 나중에 푸시 클라이언트(510)에 접속될 때를 위하여 콘텐츠 기억 장치(580)에 다시 저장할 수 있다.

그러므로, 도 5는 콘텐츠 및 콘텐츠의 처리가 동적이고 미리 정해지지 않은 범용 동적 콘텐츠 전달 시스템에서 사용될 수 있는 푸시 클라이언트(510)를 도시하고 있다. 도 5의 푸시 클라이언트(510)를 참조하여 위에서 설명한 블록들은 시스템의 동적 속성을 수용하기 위해 사용된다.

도 3을 참조하여 위에서 설명한 바와 같이, 콘텐츠는 콘텐츠의 처리에 지능을 제공하기 위해 메타데이터와 관련된다. 본 발명의 방법 및 시스템에 따르면, 메타데이터는 2가지 유형의 메타데이터로 나누어질 수 있다. 구체적으로 말하면, 정적(채널) 메타데이터와 동적(콘텐츠) 메타데이터로 나누어질 수 있다.

콘텐츠 제공자와 애플리케이션의 유형의 비제한적 가능성 때문에, 메타데이터는 범용 시스템을 구축하기 위해 절대적이다. 특정 유형의 콘텐츠를 취급하기 위한 유일한 방법은 메타데이터를 통하는 것이다.

정적 메타데이터는 특정 유형의 콘텐츠를 처리하는 방법에 관한 규칙들을 제 공하는 메타데이터이다. 정적 메타데이터는 각종 레벨의 추상화(abstraction)로 나누어질 수 있고, 예를 들면 콘텐츠 자체에 관한 구조 정보를 포함한다. 예를 들면, 실시간 단순 합성(RSS) 문서는 RSS 2.0.XSD 구조로 전달될 수 있고, 그 콘텐츠 제공자로부터의 모든 콘텐츠는 이 구조로 전달될 것이다.

정적 메타데이터의 추가적 레벨의 추상화는 콘텐츠 서브타입의 처리 규칙의 프로비져닝을 포함한다. 이것은 애플리케이션마다 특수할 수 있다. 따라서, 예를 들면, 재정 뉴스 애플리케이션은 데이터가 재정 뉴스 RSS 스트림으로부터 추출되어 미리 규정된 장소에 저장되어야 하는 것 및 애플리케이션이 정보의 도달을 통지받아야 하는 것을 표시한다. 애플리케이션은 자신에게 예정되어진 콘텐츠를 항상 이러한 방법으로 취급하도록 요구한다.

정적 메타데이터(이 명세서에서 채널 메타데이터라고도 부름)는 애플리케이션과 콘텐츠 제공자 사이에서 가입 내내 동일하게 유지되고, 따라서 정적 메타데이터는 아키텍쳐 내의 각 엘리먼트 마다 그리고 각 콘텐츠 전달 채널 마다 한번 확립될 수 있다. 일 실시예에서, 이것은 애플리케이션 또는 콘텐츠 제공자의 등록시에 행하여진다.

동적 메타데이터는 특정 피스(piece)의 콘텐츠와 관련된 메타데이터이다. 예를 들면, 특정 피스의 데이터와 관련된 만료 정보 또는 특정 피스의 데이터와 관련된 교체 규칙 및 정보가 있다.(즉, 문서 K는 문서 L을 교체한다)

도 4 및 도 5를 참조하여 위에서 설명한 바와 같이, 각각의 처리 엔티티는 그 처리 엔티티에서 보내진 정적 및 동적 메타데이터 양쪽을 수신할 수 있다. 따라 서, 푸시 프럭시(410)는 콘텐츠 메타데이터 추출기 및 캐시 블록(450)을 이용하여 동적 메타데이터를 추출하고, 콘텐츠 만료 및 교체 모듈(466)은 전달되지 않은 콘텐츠를 푸시 프럭시(410)에서 수신한 새로운 콘텐츠로 교체하기 위해 사용된다.

이제 도 6을 참조한다. 도 6은 콘텐츠 메타데이터에 대한 다층 엔벨로프 모델을 도시한 것이다.

푸시 프럭시(410)는 프럭시 서버에 대한 콘텐츠 처리 메타데이터(612) 및 푸시 클라이언트 엔벨로프(614)를 포함한 푸시 엔벨로프(610)를 수신한다. 푸시 프럭시(410)는 콘텐츠 처리 메타데이터(612)를 추출하고, 이 메타데이터를 이용하여 푸시 클라이언트 엔벨로프(614)를 처리한다. 메타데이터(612)는 푸시 클라이언트 엔벨로프(614)로 무엇을 할 것인지를 푸시 프럭시에게 지시한다.

푸시 클라이언트 엔벨로프(614)는 푸시 클라이언트(510)로 전달되어 여기에서 콘텐츠 엔벨로프(620)와 콘텐츠 처리 메타데이터(622)로 나누어진다. 콘텐츠 처리 메타데이터(622)는 콘텐츠 엔벨로프(620)를 처리하기 위해 푸시 클라이언트(510)에 의해 사용된다. 예를 들면, 이것은 만일 클라이언트 애플리케이션(150)이 최근 버젼의 콘텐츠에만 관심이 있다면 이전에 전달된 콘텐츠 엔벨로프(620)를 최근 엔벨로프로 교체하도록 푸시 클라이언트(510)에게 지시하기 위해 사용될 수 있다.

콘텐츠 엔벨로프(620)는 클라이언트 애플리케이션(150)으로 전달된다. 콘텐츠 엔벨로프(620)는 애플리케이션에 대한 콘텐츠 처리 메타데이터(630) 및 클라이언트 애플리케이션(150)에 의해 소비될 콘텐츠 페이로드(632)를 포함한다.

당업자라면 잘 알 수 있는 바와 같이, 도 6에 따른 엔벨로프의 내포(nesting)는 처리가 아키텍쳐의 임의의 처리 엘리먼트에서 발생할 수 있고 콘텐츠 제공자(110)가 특정 콘텐츠의 취급 방법을 지정할 수 있는 풍부한 동적 환경을 제공한다. 일 실시예에서, 특정 논리 엘리먼트로 보내진 메타데이터는 다른 처리 엘리먼트에는 불투명(opaque)한 것이다.

대안적으로, 서비스 제공자(120)는 푸시 클라이언트(510) 또는 클라이언트 애플리케이션(150)에서의 처리를 위해 푸시 프럭시(410)에서 메타데이터를 또한 추가할 수 있다.

도 7을 참조하면, 도 6의 엔벨로프 모델 및 각 처리 엘리먼트가 엔벨로프에서 취하는 단계들이 도시되어 있다. 도 7에 도시된 바와 같이, 푸시 프럭시(410)는 먼저 푸시 엔벨로프(610)로부터 메타데이터를 추출한다. 이것은 단계 710에서 행하여진다.

단계 712에서, 푸시 프럭시(410)는 메타데이터를 이용하여 푸시 클라이언트 엔벨로프(614)를 처리한다. 단계 714에서, 푸시 프럭시(410)는 푸시 클라이언트 엔벨로프(614)를 푸시 클라이언트(510)에 전달한다.

유사하게, 단계 720에서, 푸시 클라이언트(510)는 푸시 클라이언트 엔벨로프(614)로부터 콘텐츠 처리 메타데이터(622)를 추출한다. 단계 722에서, 푸시 클라이언트(510)는 콘텐츠 엔벨로프(620)에서 콘텐츠 처리 메타데이터(622)를 이용한다. 단계 724에서, 푸시 클라이언트(510)는 콘텐츠 엔벨로프(620)를 클라이언트 애플리케이션(150)에 전달한다.

단계 730에서, 클라이언트 애플리케이션(150)은 콘텐츠 처리 메타데이터(630)를 추출하고, 단계 732에서 콘텐츠 처리 메타데이터(630)를 콘텐츠 페이로드(632)에 이용한다.

도 8을 참조하면, 이 도면은 도 7에 도시된 방법을 정적 또는 채널 메타데이터를 이용하는 추가의 단계와 함께 도시하고 있다. 구체적으로, 단계 710에서 메타데이터가 푸시 엔벨로프(610)로부터 추출된 후, 푸시 프럭시(410)는 다음에 정적 채널 메타데이터를 이용하여 단계 810에서 푸시 클라이언트 엔벨로프를 처리한다. 단계 712에서, 푸시 프럭시(410)는 다음에 콘텐츠 처리 동적 메타데이터(612)를 처리한다. 푸시 프럭시(410)는 다음에 단계 714에서 푸시 클라이언트 엔벨로프(614)를 전달한다.

유사하게, 푸시 클라이언트(510)는 단계 720에서 콘텐츠 처리 메타데이터(622)를 추출한다. 그 다음에, 푸시 클라이언트(510)는 단계 820에서 콘텐츠 엔벨로프(620) 내의 콘텐츠에 채널 메타데이터를 이용한다. 그 다음에, 단계 722에서, 푸시 클라이언트(510)는 콘텐츠 엔벨로프(620)를 단계 724에서 클라이언트 애플리케이션(150)에 전달하기 전에 콘텐츠 처리 메타데이터(622) 내의 동적 콘텐츠 메타데이터를 이용한다.

단계 730에서, 클라이언트 애플리케이션(150)은 먼저 콘텐츠 처리 메타데이터(630)를 추출한다. 그 다음에, 단계 830에서 채널 메타데이터를 콘텐츠 페이로드(632)에 이용한다. 클라이언트 애플리케이션(150)은 그 다음에, 단계 732에서, 콘텐츠 처리 메타데이터(630)를 콘텐츠 페이로드(632)에 이용한다.

당업자라면 잘 알 수 있는 바와 같이, 상기 모델은 전송되는 특정 콘텐츠와 관련된 동적 메타데이터와 함께 정적 메타데이터가 채널에 적용될 수 있게 한다.

이제 도 9를 참조한다. 도 5에서 명백한 바와 같이, 푸시 클라이언트(510)는 모바일 장치의 다중 목표 애플리케이션(512)에 작용할 수 있다. 애플리케이션이 다른 애플리케이션에 대한 서비스를 방해하지 않고 동적 콘텐츠 전달 프레임워크에 등록할 수 있는 효과적인 런타임 등록 메카니즘이 필요하다.

도 9를 참조하면, 푸시 클라이언트(510)는 3개의 애플리케이션, 구체적으로 말하면, 푸시 클라이언트로 이미 등록된 애플리케이션(910, 912, 914)을 포함한다. 명백히 알 수 있는 바와 같이, 플러그-인 모델은 새로운 장치가 비제한 애플리케이션 유형을 장치에 설치시킬 수 있기 때문에 중요하다. 또한 애플리케이션은 동적으로 설치되어 모바일 장치가 애플리케이션 플랫폼이 되게 할 수 있다. 장치가 애플리케이션 플랫폼일 수 있기 때문에, 새로운 애플리케이션을 동적으로 통합할 수 있어야 한다.

푸시 프럭시(410)는 콘텐츠 및 이 콘텐츠와 관련된 메타데이터를 취급하기 위한 각종 모듈을 포함한다. 제1 모듈은 메시지 브로커 및 전달 큐(440)이고, 이것은 콘텐츠 제공자(412)로부터의 메시지를 소비함과 아울러 콘텐츠 전달 큐를 관리하는 서브시스템이다. 당업자라면 잘 알 수 있는 바와 같이, 모든 클라이언트 애플리케이션에 대한 모든 콘텐츠가 한번에 전달될 수 있는 것은 아니기 때문에, 전달 큐는 콘텐츠를 순조롭게 전달하기 위하여 확립될 필요가 있다. 예를 들면, 장치는 커버리지 밖에 있을 수 있고, 콘텐츠는 저장될 필요가 있을 수 있다.

지연 검색 메시지 저장 블록(452)은 콘텐츠 또는 그 일부를 클라이언트 애플리케이션에 전달하기에 효과적이지 않을 때 사용된다. 지연 검색 메시지 저장 블록(452)은 콘텐츠를 전송하는 것이 효과적일 때까지, 또는 콘텐츠가 클라이언트에 의해 풀링될 때까지 클라이언트에 전달되지 않은 콘텐츠를 저장하기 위해 사용된다. 지연 검색 메시지 저장은 이미 전달된 콘텐츠를 통한 클라이언트 애플리케이션 내비게이션에 따라 클라이언트에게 선택적으로 전송되거나 클라이언트에 의해 풀링될 수 있는 보조 콘텐츠를 캐시하기 위해 또한 사용된다.

지연 검색 메시지 저장 블록(452)의 목적은 도 19 및 도 21을 참조하여 뒤에서 자세히 설명된다. 예를 들면, 지연 검색 메시지 저장 블록(452)이 사용되는 경우는 사용자가 사용자의 위치에서 가까운 식당과 같은 위치 정보를 요구한 경우이다. 콘텐츠 제공자 또는 서비스 제공자는 제공하는 정보의 모델을 가질 수 있고, 이때 광고자는 그들의 정보를 탐색 요구에 추가하도록 비용을 지불할 수 있다. 따 라서, 위치에 대해서 식당 정보를 요구하는 사용자는 그들의 요구에 수반된 그들의 위치에서 가까운 상점, 골프 코스, 체육관 또는 다른 서비스에 관한 정보를 가질 수 있다. 콘텐츠 제공자는 요구된 식당 정보를 추가적인 정보와 함께 묶어서 그 묶음을 푸시 프럭시(410)에게 전달한다.

푸시 프럭시(410)는, 제공된 메타데이터에 기초해서, 클라이언트에게 보낼 콘텐츠 패키지를 생성한다. 콘텐츠 패키지는 클라이언트가 요구한 정보뿐만 아니라 사용자가 관심을 가질만한 관련 정보의 요약 또는 개요를 포함할 수 있다. 개요는 사용자에게 보내지지만, 지연 검색 메시지 저장 블록(452)은 콘텐츠 제공자(110)로부터 수신한 실제 데이터를 저장한다. 따라서, 만일 장래에 사용자가 요약 내의 정보에 대한 더욱 상세한 정보를 얻기 원하면, 이 정보는 푸시 프럭시(410)에 이미 저장되어 있다.

푸시 스케쥴러(454)는 클라이언트의 전달 슬롯을 계획한다. 전술한 바와 같이, 어떤 상황에서, 모든 콘텐츠를 한번에 푸시하는 것이 효율적이지 않을 수 있 다. 푸시 스케쥴러(452)는 일부 정보는 즉시 푸시하고 나머지는 미리 규정된 스케쥴에 따라 푸시하는 것을 결정할 수 있다. 또한, 푸시 스케쥴러(454)는 콘텐츠의 속성을 이용하여 콘텐츠가 언제 푸시되어야 하는지를 결정할 수 있다. 구체적으로, 메타데이터는 어떤 콘텐츠가 높은 우선순위에 있는지 또는 시간적으로 제한된 만료를 갖는지를 표시할 수 있고, 이 콘텐츠는 즉시 푸시되는 한편, 낮은 우선순위를 갖거나 만료가 없다고 표시된 콘텐츠는 데이터 전송 조건이 더 나은 때의 나중 시점에서 푸시될 수 있다.

가입 및 규칙 블록(460)은 서비스를 수신하기 위해서 및 전달되는 특정 콘텐츠를 취급하는 법에 대한 규칙들을 감시하기 위해서 등록되어 있는 애플리케이션들을 추적한다. 콘텐츠는 전형적으로 클라이언트에 의한 또는 클라이언트를 대신한 가입에 기초하여 전달된다. 사용자는, 예컨대 그들이 특정한 서비스를 원한다면, 가입을 적극적으로 요구할 수 있다. 가입은 예를 들어서 만일 사용자가 서비스의 잇점을 수신하기 위해 서비스 제공자(120)와의 협약에 서명하였다면 사용자를 대신하여 행하여질 수 있다. 이것은 사용자가 매일 특정 수의 광고를 수신하는 것에 동의하는 한 사용자가 선호 가격을 수신하는 경우를 포함한다. 이 경우, 서비스 제공자(120)는 클라이언트를 대신하여 광고 제공자에 대한 가입을 할 수 있다.

또한 콘텐츠 만료 및 교체 블록(466)은 정보를 감시하기 위해 사용될 수 있다. 특정 콘텐츠는 정보의 유효성에 대한 시간 제한을 가질 것이다. 예를 들면, 러시아워(rush hour)의 교통량을 감시하기 위해 사용되는 교통량 애플리케이션은 매우 시간 의존적이다. 만일, 몇가지 이유로 해서, 푸시 프럭시(410)가 콘텐츠를 모바일 장치로 즉시 전달할 수 없으면, 이 콘텐츠는 나중에 전달하기 위해 콘텐츠 기억장치(480)에 저장된다. 그러나, 만일 콘텐츠가 특정의 지정된 시간 내에 전달되지 않으면, 그 콘텐츠는 만료가 되어 전혀 전달되지 않을 수 있다.

푸시 클라이언트(510)는 애플리케이션에 서비스를 제공하고 하나 이상의 애플리케이션(512)은 푸시 클라이언트(510)에 등록할 수 있다. 애플리케이션 등록은 등록을 위한 인터페이스로서 애플리케이션 제공자 인터페이스(514)를 이용하고, 애플리케이션 제공자 인터페이스(514)는 또한 애플리케이션에 대한 채널 메타데이터를 추출하기 위해 사용될 수 있다. 이것에 대해서는 뒤에서 자세히 설명된다.

지연 검색 관리자(552)는 수신된 콘텐츠의 파편(fragment)을 분석하고 올바른 방법으로 콘텐츠를 함께 두기 위해 사용된다. 뒤에서 더 자세히 설명하는 바와 같이, 데이터는 선형일 수도 있고 비선형일 수도 있다. 데이터가 비선형이면, 데이터를 재구성하기 위해 메타데이터가 요구되고, 이것은 지연 검색 관리자(552)에 의해 행하여진다. 지연 검색 관리자(552)는 또한 푸시 프럭시(510)의 지연 검색 기억부(452)에서 이용할 수 있는 정보의 요약을 분석하도록 구성되고, 콘텐츠 풀(pull) 브로커(554)(뒤에서 설명됨)를 구동시켜서 사용자가 요구한 때 상기 정보를 검색하게 한다. 이것은 콘텐츠 내비게이션이 콘텐츠 구조 그래프의 특정 브랜치에 들어갈 때 또는 대역폭 또는 가격 조건이 만족될 때의 예측 검색을 포함한다.

가입 관리 블록(560)은 도 4의 가입 및 규칙 블록(460)과 동일한 것일 수 있다. 구체적으로, 가입 관리 블록(560)은 가입을 관리하기 위해 사용된다. 만일 애플리케이션이 등록 해제되거나 모바일 장치로부터 삭제되면, 가입 관리 블록(560)은 가입을 종료한다. 가입 관리 블록(560)은 또한 가입 채널이 만료가 되었을 때 클라이언트 애플리케이션을 대신하여 재가입할 수 있다.

예를 들자면, 오버나이트 계약자용으로 업데이트되는 작업 목록은 그 목록에 푸시된 태스크를 가질 수 있다. 태스크 애플리케이션은 이 시간동안 시작되지 않고, 배경 업데이트 처리 모듈(575)이 태스크 애플리케이션에 대한 콘텐츠를 업데이트하기 위해 사용될 수 있다. 이것은 확장형 마크업 언어(XML) 파일을 취급하기 위한 코드로 행하여질 수 있고, "handler.exe"라고 부르는 파일로 장치에 존재할 수 있다. 푸시 클라이언트(510)에서의 배경 업데이트 처리 블록(575)은 XML 문서가 파라미터를 갖는 것을 전달하는 handler.exe를 실행시킬 수 있다. 그 다음에, 핸들러는 태스크를 애플리케이션의 내부 포맷으로 구성한다.

도 3을 참조하여 위에서 설명한 바와 같이, 콘텐츠는 콘텐츠의 처리에 지능을 제공하기 위해 메타데이터와 관련된다. 본 발명의 방법 및 시스템에 따르면, 메타데이터는 2가지 유형의 메타데이터, 구체적으로 말하면, 정적(채널) 메타데이터와 동적(콘텐츠) 메타데이터로 나누어질 수 있다.

정적 메타데이터는 특정 유형의 콘텐츠를 처리하는 방법에 관한 규칙들을 제 공하는 메타데이터이다. 정적 메타데이터는 각종 레벨의 추상화로 나누어질 수 있고, 예를 들면 콘텐츠 자체에 관한 구조 정보를 포함한다. 예를 들면, 실시간 단순 합성(RSS) 문서는 RSS 2.0.XSD 구조로 전달될 수 있고, 그 콘텐츠 제공자로부터의 모든 콘텐츠는 이 구조로 전달될 것이다.

정적 메타데이터의 추가적 레벨의 추상화는 콘텐츠 서브타입의 처리 규칙의 공급을 포함한다. 이것은 애플리케이션마다 특수할 수 있다. 따라서, 예를 들면, 재정 뉴스 애플리케이션은 데이터가 재정 뉴스 RSS 스트림으로부터 추출되어 미리 규정된 장소에 저장되어야 하는 것 및 애플리케이션이 정보의 도달을 통지받아야 하는 것을 표시한다. 애플리케이션은 자신에게 예정되어진 콘텐츠를 항상 이러한 방법으로 취급하도록 요구한다.

정적 메타데이터(이 명세서에서 채널 메타데이터라고도 부름)는 애플리케이션과 콘텐츠 제공자 사이에서 가입 내내 동일하게 유지되고, 따라서 정적 메타데이터는 아키텍쳐 내의 각 엘리먼트에 대하여 및 각 콘텐츠 전달 채널에 대하여 한번 확립될 수 있다. 일 실시예에서, 이것은 애플리케이션 또는 콘텐츠 제공자의 등록시에 행하여진다.

동적 메타데이터는 특정 피스(piece)의 콘텐츠와 관련된 메타데이터이다. 예를 들면, 특정 피스의 데이터와 관련된 만료 정보 또는 특정 피스의 데이터와 관련된 교체 규칙 및 정보가 있다(즉, 문서 K는 문서 L을 교체한다).

당업자라면 잘 알 수 있는 바와 같이, 도 6에 따른 엔벨로프의 내포는 처리가 아키텍쳐의 임의의 처리 엘리먼트에서 발생할 수 있고 콘텐츠 제공자(110)가 특정 콘텐츠의 취급 방법을 지정할 수 있는 풍부한 동적 환경을 제공한다. 일 실시예에서, 특정 논리 엘리먼트로 보내진 메타데이터는 다른 처리 엘리먼트에는 불투명한 것이다.

단계 730에서, 클라이언트 애플리케이션(150)은 콘텐츠 처리 메타데이 터(630)를 추출하고, 단계 732에서 콘텐츠 처리 메타데이터(630)를 콘텐츠 페이로드(632)에 이용한다.

도 9에서 알 수 있는 바와 같이, 애플리케이션(916)은 푸시 클라이언트(510)로 등록하기를 원한다. 애플리케이션(916)은 양호한 실시예에서 그 애플리케이션에 대한 채널 메타데이터를 제공하는 애플리케이션 매니페스트(918)를 포함한다. 구체적으로, 애플리케이션 매니페스트(918)는 푸시 클라이언트(510)에 정보를 제공하고, 궁극적으로 푸시 프럭시(410) 및 도 1의 콘텐츠 제공자(110)에게 애플리케이션에 대한 정적 메타데이터를 제공한다. 이것은 어떤 유형의 콘텐츠를 애플리케이션이 기대하는지, 콘텐츠를 어떻게 전달할 것인지, 애플리케이션이 통지를 필요로 하는지, 또는 본 발명의 시스템 및 방법과 관련하여 당업자에게는 명백한 다른 채널 정보를 포함할 수 있지만, 이것들로 제한되는 것은 아니다.

그러므로, 애플리케이션(916)은 푸시 클라이언트(510)로 등록하여 애플리케이션(916)에 서비스하는 콘텐츠 제공자에 대한 채널을 확립하기 위해 애플리케이션 매니페스트(918)를 제공한다.

도 10을 참조하면, 대안적 모델은 도 2의 아키텍쳐(220)와 관련하여 설명한 모델일 수 있다. 구체적으로, 도 10의 모델에서, 클라이언트 애플리케이션(150)은 푸시 클라이언트(140)와 쌍을 이룬다. 각각의 클라이언트 애플리케이션(150)/푸시 클라이언트(140) 쌍은 푸시 콘테이너(1010)로 통합된다.

애플리케이션(1020)이 푸시 콘테이너(1010)로 등록하기 원할 때, 클라이언트(140)가 생성되고, 또는 만일 이미 존재한다면 푸시 콘테이너(1010)에 의해 사용된다. 또한, 등록시에, 애플리케이션(1020)은 푸시 콘테이너(1010)에 애플리케이션 매니페스트(1030)를 제공하고, 이것에 의해 애플리케이션(1020)에 대한 채널 메타데이터(정적 메타데이터)를 제공한다.

도 10의 대안적인 예는 도 11에 도시되어 있다. 구체적으로, 푸시 콘테이너(1110)는 푸시 클라이언트의 풀(pool)을 관리/유지한다. 애플리케이션이 콘테이너에 등록될 때, 애플리케이션은 단순한 경우에 소켓 리스너(listener)(1130) 및 콘텐츠 핸들러의 쌍으로 표시될 수 있는 전용 푸시 클라이언트(510)를 얻는다. 푸시 클라이언트는 애플리케이션이 콘테이너(및 콘텐츠 전달 서비스)로부터 미등록되거나 장치로부터 삭제될 때 풀(pool)로 복귀된다.

푸시 콘테이너(1110)는 통신에 대한 소켓(1120)을 포함한다. 또한, 푸시 콘 테이너(1110)는 특정 소켓에 할당된 소켓 리스너(1130) 및 콘텐츠 프로세서(1140)를 포함한다.

도 11에 도시된 바와 같이, 각종 콘텐츠 프로세서 및 소켓 리스너 쌍은 이전에 등록된 애플리케이션(150)에 의해 사용된다.

새로운 애플리케이션(1150)이 푸시 콘테이너(1110)에 등록하기 원할 때, 새로운 콘테이너 프로세서와 소켓 리스너(1120, 1130)는 서비스 애플리케이션(1050)에 할당된다.

그러므로, 상기 예는 새로운 클라이언트 애플리케이션(150)이 푸시 클라이언트(510) 또는 푸시 콘테이너(1010 또는 1110)와 함께 구현되고 등록될 수 있는 범용 푸시 프레임워크를 제공하고, 이것에 의해 장치가 새로운 애플리케이션을 동적으로 통합할 수 있는 애플리케이션 플랫폼이 될 수 있다. 도 9 및 도 10에서 애플리케이션 매니페스트(1030 또는 918)의 전달은 채널 메타데이터의 확립을 가능하게 하고, 이것에 의해 콘텐츠가 애플리케이션의 필요조건에 따라 처리되게 한다.

도 12를 참조하면, 콘텐츠 제공자(110)는 마찬가지로 푸시 프럭시(410)에 등록할 필요가 있다. 도 12에 도시된 바와 같이, 푸시 프럭시(410)는 푸시 프럭시(410)에 이미 등록된 3개의 콘텐츠 제공자(1210, 1212, 1214)를 포함한다. 콘텐츠 제공자(1216)는 푸시 프럭시(410)에 등록하기를 희망한다.

푸시 클라이언트(510)에 등록할 때 애플리케이션(916)에 의해 제공되는 도 9에 도시된 애플리케이션 매니페스트(918)와 마찬가지로, 콘텐츠 제공자(1216)는 콘텐츠 제공자(1216)가 등록할 때 푸시 프럭시(410)에 전달되는 서비스 매니페스 트(1218)을 포함한다. 서비스 매니페스트(1218)는 콘텐츠 제공자가 제공할 정보의 유형, 이 정보를 얼마나 자주 제공하는지, 정보의 포맷, 및 서비스 또는 서비스의 광고에 유용한 임의의 다른 정보에 관한 정보를 포함한다. 다른 정보도 가능하다.

따라서, 푸시 프럭시(410)는 서비스 매니페스트(1218)를 이용하여 콘텐츠 제공자(1216)에 대한 채널(정적) 메타데이터를 확립한다.

도 13을 참조하면, 도 2의 아키텍쳐에 의해 표시된 것의 대안적인 실시예는 다수의 푸시 프럭시(122)와 콘텐츠 제공자(110) 쌍과 함께 푸시 콘테이너를 갖는다. 도 12에서처럼, 각종 애플리케이션이 푸시 콘테이너(1310)로 이미 등록되어 있을 수 있고, 도 13의 예에서, 애플리케이션(1312, 1314, 1316)은 푸시 프럭시(1313, 1315, 1317)에 각각 이미 등록되어 있다.

새로운 애플리케이션(1320)은 푸시 콘테이너(1310)에 등록하기 원한다. 따라서, 푸시 콘테이너(1310)는 콘텐츠 제공자(1320)와 결합하는 새로운 프럭시(도시 생략됨)를 생성하거나 기존 프럭시(도시 생략됨)를 이용한다. 또한 콘텐츠 제공자(1320)는 콘텐츠 제공자(1320)가 제공하는 콘텐츠를 설명하는 서비스 매니페스트(1322)를 제공하고, 이것에 의해 채널 메타데이터의 확립을 가능하게 한다.

당업자라면 잘 알 수 있는 바와 같이, 도 9 및 도 10의 실시예는 푸시 클라이언트에 대한 2가지 옵션, 즉 공유 애플리케이션을 갖는 것과 애플리케이션마다 전용 푸시 클라이언트를 갖는 것을 보여준다. 당업자라면 다른 실시예도 가능하다는 것을 알 것이다. 마찬가지로, 도 12 및 도 13과 관련하여, 다중 콘텐츠 제공자가 등록된 푸시 프럭시가 도시되어 있고, 또는 각 콘텐츠 제공자마다의 전용 푸시 프럭시 및 푸시 콘테이너에 매립된 것이 도시되어 있다.

도 14에는 콘텐츠 제공자(110)와 클라이언트 애플리케이션(150) 간의 메시징이 도시되어 있다. 콘텐츠 제공자(110)는 푸시 프럭시(410)에게 등록 메시지를 제공한다. 이 메시지는 푸시 프럭시(410)에게 채널 메타데이터를 제공하기 위해 사용될 수 있는 서비스 매니페스트를 포함할 수 있다. 이것은 단계 1410에서 행하여진다.

콘텐츠 제공자(110)는 단계 1412에 표시된 바와 같이, 후속 메시지의 채널 메타데이터를 부가적으로 또는 대안적으로 제공할 수 있다.

그 다음에, 푸시 프럭시(410)는 단계 1414에서 서비스를 가용 서비스의 목록(서비스 카탈로그)에 추가한다.

도 14의 예에서 옵션 단계는 푸시 프럭시(410)가 새로운 가용 서비스를 푸시 클라이언트(510)에게 통지하는 것(단계 1416)이고, 이 통지는 클라이언트 애플리케이션(110)에게 전파될 수 있다.(단계 1418)

당업자라면 잘 알 수 있는 바와 같이, 단계 1416과 1418은 선택적인 것이고, 다른 대안적인 예는 새로운 서비스를 보기 위하여 서비스 카탈로그를 푸시 프럭시(410)로부터 주기적으로 풀링하는 클라이언트 애플리케이션(150)을 포함한다.

클라이언트 애플리케이션(150)이 서비스에 가입해야 한다는 것을 클라이언트 애플리케이션(150)에 대한 사용자 또는 서비스 제공자가 결정한 때, 클라이언트 애플리케이션(150)은 단계 1420에서 가입 메시지를 전송한다. 가입 메시지는 또한 단계 1422에서 푸시 프럭시(410)에게 전달된다.

단계 1422에서 일단 푸시 프럭시(410)가 가입 메시지를 수신하면, 2가지의 옵션이 가능하다. 첫번째 옵션은 가입을 위해 메시지를 콘텐츠 제공자(110)에게 보내고 그 다음에 메타데이터를 포함하는 메시지 엔벨로프를 다시 수신하는 것(단계 1426)이다. 메타데이터는 장치 또는 장치 유형마다 특정될 수 있다.

대안적으로, 푸시 프럭시(410)는 단계 1422에서 가입 메시지를 수신하고, 콘텐츠 제공자(110)에 의해 이미 제공되어 푸시 프럭시(410)에 저장되어 있는 정보에 기초하여 즉시 푸시 클라이언트(510)에게 응답할 수 있다.(단계 1430) 이 응답은 단계 1532에서 클라이언트 애플리케이션(150)에게 전파된다. 명백히 알 수 있는 바와 같이, 응답은 콘텐츠 제공자(110)마다 특정한 채널 메타데이터를 포함할 수 있다.

모델들 간의 차이는 누가 애플리케이션에 대한 데이터를 소비하는가에 의존할 수 있다. 명백히 알 수 있는 바와 같이, 콘텐츠 제공자(110)는 다른 처리 엘리먼트에 비하여 최상의 고객맞춤형 콘텐츠를 제공한다. 그러나, 서비스 제공자(120)는 푸시 프럭시(410)를 통하여 역시 고객맞춤형 콘텐츠를 제공할 수 있다.

또한, 명백히 알 수 있는 바와 같이, 콘텐츠의 구조는 애플리케이션이 요구하는 데이터에 의존할 수 있다. 예를 들면, 재정 애플리케이션에서, 애플리케이션은 주식 시세와 환율 양쪽을 원할 수 있다. 하기의 XML이 사용될 수 있다.

<FIN>

18.54

</quote>

123.45

</quote>

</quotes>

<rates>

1.15

</rate>

0.85

</rate>

</rates>

</FIN>

사용자가 만일 주식 시세만을 원하고 환율을 원하지 않으면, 구조는 다음과 같이 변화될 수 있다.

<FIN>

18.54

</quote>

123.45

</quote>

</FIN>

메타데이터는 데이터가 전달되는 구조에서 애플리케이션에 정보를 제공할 수 있다.

따라서, 2개의 모델이 존재한다. 정적 메타데이터는 등록 중에 또는 그 다음에 푸시 프럭시(410) 및 푸시 클라이언트(510)에게 제공될 수 있다. 대안적으로, 푸시 프럭시(410) 및 푸시 클라이언트(510)에 대한 메타데이터는 미리 프로비져닝될 수 있다. 즉, 정보는 애플리케이션이 클라이언트에 등록할 때까지 푸시 클라이언트 또는 푸시 프럭시에 저장된다.

이제 도 15를 참조한다. 도 15는 애플리케이션이 푸시 클라이언트(510)에 등록할 때 발생하는 논리적 단계들을 도시한 것이다.

일단 애플리케이션이 푸시 클라이언트(510)에 등록하면, 제1 단계(1510)는 등록된 애플리케이션을 애플리케이션이 요구하는 콘텐츠 유형과 일치시키는 것이다. 이것은 도 9에 도시된 바와 같은 애플리케이션 매니페스트(918)로부터 알 수 있다.

제2 단계(1520)는 애플리케이션에 대한 환경을 설정하는 것이다. 이것은 애플리케이션의 기억 및 전달 옵션을 포함하지만 이것으로 제한되는 것은 아니다. 예 를 들면, 애플리케이션은 미리 정해진 데이터량으로 전송을 제한할 수 있다. 애플리케이션 또는 클라이언트가 접촉하지 않으면, 흐름 제어 이벤트에서의 푸시 클라이언트(510)는 애플리케이션에 대한 데이터의 캐싱 및 선택적으로 데이터를 대기하고 있음을 애플리케이션에게 통지하도록 요구할 수 있다.

제3 단계(1530)는 애플리케이션 세팅을 푸시 프럭시(410)에게 통지하는 것이다. 이것은 예를 들면 애플리케이션 또는 푸시 클라이언트(510)에 대한 가용 기억장치를 포함한다. 명백히 알 수 있는 바와 같이, 푸시 프럭시(410)는 푸시 클라이언트(510)가 저장할 수 있는 것보다 더 많은 데이터를 푸시하여서는 안된다. 따라서, 애플리케이션 세팅은 전달되는 데이터의 상한을 포함할 수 있다. 도 4 및 도 5를 참조하면, 만일 애플리케이션이 처리할 수 있는 것보다 콘텐츠가 더 크면, 콘텐츠 프래그먼트화 블록(464)이 콘텐츠를 프래그먼트화시키도록 할 수 있다. 또한, 데이터가 비선형이면, 콘텐츠 의존 블록(462)은 콘텐츠 의존 블록(564)이 데이터를 재구성할 수 있게 하기 위해 도 5의 콘텐츠 의존 블록(564)에 대한 메타데이터를 생성하도록 요구될 수 있다.

도 15를 다시 참조하면, 단계 1530은 또한 데이터 전달시의 선호도를 표시할 수 있다. 예를 들면, 애플리케이션은 다른 데이터보다 특정 유형의 데이터를 더 선호할 수 있고, 이 유형의 데이터는 우선순위가 주어질 수 있다. 따라서, 단계 1530은 유형 "A"의 데이터가 즉시 전달되고 유형 "B"의 데이터가 나중 시간에 전달되는 전달 스케쥴을 확립하기 위해 사용될 수 있다.

이제 도 16을 참조한다. 콘텐츠 제공자(110)가 푸시 프럭시(410)에 등록할 때, 각종 단계가 수행된다. 제1 단계(1610)는 콘텐츠 저장 및 전달을 위한 요구된 클라이언트 세팅 분석을 포함한다. 이것은 예를 들면 콘텐츠 제공자(110)로부터의 콘텐츠를 소비할 수 있는 장치에서 푸시 클라이언트(510)를 식별하기 위해 서비스 광고용으로 사용될 수 있다.

제2 단계(1620)는 푸시 프럭시(410)가 프럭시 저장, 전달 옵션, 변환 옵션 등을 비롯한 환경을 설정할 수 있게 한다.

단계 1630에서, 푸시 프럭시(410)는 애플리케이션이 콘텐츠 제공자(110)로부터 콘텐츠를 획득하도록 이미 등록되었는지를 체크할 수 있다. 만일 등록되어 있으면, 애플리케이션은 콘텐츠를 수신할 준비가 되었고, 전달 채널이 확립되었고 애플리케이션이 콘텐츠 수신 준비가 되었다는 통지가 푸시 프럭시(410)로부터 콘텐츠 제공자(110)에게 보내질 수 있다.

단계 1630은 예컨대 만일 콘텐츠 제공자(110)가 온라인으로 오기 전에 애플리케이션이 장치에 미리 설치되었으면 실행될 수 있다. 따라서, 애플리케이션은 콘텐츠 제공자(110)가 이용가능하게 되는 것 또는 애플리케이션이 범용 유형(예를 들면, 브라우저 또는 RSS 뷰어)으로 되어 다중 콘텐츠 제공자로부터의 정보를 소비할 수 있는 것을 대기한다. 대안적인 세팅에서, 만일 애플리케이션이 설치되기 전에 콘텐츠 제공자(110)가 이미 이용가능이면, 도 15의 통지 단계(1530)를 사용하여 콘텐츠 제공자(110)로부터 클라이언트 애플리케이션(150)에게로의 흐름을 위한 콘텐츠 개시를 시작할 수 있다.

도 16에서 알 수 있는 바와 같이, 클라이언트 세팅은 콘텐츠 분 할(partitioning)을 위해 사용되는 가용 기억장치 사이즈, 흐름 제어를 위해 사용되는 큐 사이즈, 푸시 간격을 포함하는 전달 스케쥴링, 클라이언트가 프럭시로부터 정보를 검색하는지 여부, 의사 푸시(pseudo-push) 모드의 생성, 모바일 장치의 화면 크기와 같은 고객맞춤 옵션 등과 같은 특정 정보를 포함할 수 있다.

명백히 알 수 있는 바와 같이, 서비스 카탈로그는 클라이언트마다 다를 수 있다. 예를 들면, 특정 클라이언트는 더 많은 데이터를 이용할 수 있고 다른 화면 크기를 가질 수 있으며, 또는 클라이언트를 상기 정보량을 취급할 수 없는 장치보다 콘텐츠 제공자(110)에게 더 적합하게 만드는 다른 조건은 더 작은 화면 크기 등을 갖는다. 따라서, 푸시 프럭시(410)는 특정 클라이언트 애플리케이션에 대해서 그 클라이언트 애플리케이션의 지식에 기초하여 서비스 카탈로그를 생성할 수 있고, 클라이언트 애플리케이션(150)이 설치된 장치들만이 콘텐츠 제공자에 관한 정보를 수신할 수 있다.

명백히 알 수 있는 바와 같이, 일부 경우에, 애플리케이션은 사용자의 개입없이 서비스 제공자 및 콘텐츠 제공자에 기초하여 설치될 수 있다. 예를 들어서, 만일 콘텐츠 제공자(110)가 푸시 프럭시(410)로 등록하면, 모바일 장치 사용자는 특정 애플리케이션을 수락하는 계약 의무를 가질 수 있다. 따라서, 푸시 프럭시(410)는 애플리케이션의 설치 및 그 애플리케이션을 푸시 클라이언트(510)에게 푸시할 준비가 되었음을 푸시 클라이언트(510)에게 통지할 수 있다. 이것은 예를 들면 모바일 계획에 대한 선호 가격(preferred rate)을 취하기 위해 매월 특정 수의 광고를 수신하는 것에 동의하는 사용자를 포함할 수 있다. 콘텐츠 제공자(110) 는 광고 제공자가 될 수 있고, 그러므로, 푸시 프럭시(410)는 푸시 클라이언트(410)에 등록된 애플리케이션 설치자(installer)에 의해 서비스되는 광고 표시 애플리케이션을 푸시 클라이언트(510)에게 푸시할 수 있고, 이것에 의해 프로세스를 전체적으로 구동시키는 콘텐츠 제공자(110) 및 서비스 제공자(120)를 갖는다.

그러므로, 상기 예는 각 애플리케이션 또는 콘텐츠 제공자가 등록하고 애플리케이션 매니페스트 또는 서비스 매니페스트를 각각 제공하는 푸시 프레임워크에서 플러그-인 등록 모델을 제공한다. 애플리케이션 매니페스트 또는 서비스 매니페스트는 등록 중에 또는 후속적으로 푸시 프럭시(410) 및 푸시 클라이언트(510)에서 체널 메타데이터를 확립하기 위해 사용된다. 그 후, 애플리케이션(150)이 등록하고 콘텐츠 제공자(110)가 등록할 때, 콘텐츠는 애플리케이션(150)과 콘텐츠 제공자(110) 사이에서의 흐름을 시작할 수 있다.

도 4 및 도 5를 참조하면, 채널 메타데이터는 채널 메타데이터 저장소(470, 570)에 저장된다. 그러나, 동적 메타데이터가 반복되면 아키텍쳐(100) 내의 각종 처리 엘리먼트에 동적 메타데이터를 저장하는 것도 또한 유익하다. 명백히 알 수 있는 바와 같이, 현재 메타데이터 추출기(450)는 되풀이하여 동일한 메타데이터를 추출할 필요가 없기 때문에 이것은 푸시 프럭시(410)에서의 처리를 절약한다. 또한, 콘텐츠 만료 및 교체 모듈(466 또는 566)과 같은 각종 모듈에 의한 처리는 전달되는 각 콘텐츠 피스에 대하여 업데이트될 필요가 없다. 푸시 프럭시(410)는 다수의 푸시 클라이언트(510)와 함께 작업할 수 있기 때문에, 각 콘텐츠 메시지에 대한 처리 절약은 충분할 수 있다. 또한 콘텐츠 제공자(110)와 푸시 프럭시(410) 간의 고정 선로를 통하여 또는 푸시 프럭시(410)와 푸시 클라이언트(510) 간의 공기를 통하여 메타데이터를 전달할 필요가 없게 됨으로써 대역폭이 절약될 수 있다.

이제 도 17을 참조한다. 도 17은 최종 메타데이터 버젼이 처리 엘리먼트에 의해 저장되는 런타임 흐름의 예를 도시하고 있다.

도 17에서 알 수 있는 바와 같이, 콘텐츠 제공자(110)는 콘텐츠 [C₁+M(p,c,a)₁]을 포함하는 콘텐츠 엔벨로프를 제공한다. 이것은 제1 콘텐츠 페이로드가 프럭시 메타데이터, 클라이언트 메타데이터 및 애플리케이션 메타데이터를 포함하는 메타데이터와 함께 전송된다는 것을 의미한다. 이것은 단계 1710에서 전송된다.

단계 1712에서, 푸시 프럭시(410)는 구문(phrase) "M(p)₁ 이용"으로 표시된 바와 같이 프럭시 메타데이터를 이용한다. 또한 단계 1714에서 클라이언트 메타데이터와 애플리케이션 메타데이터를 포함하는 메타데이터 및 콘텐츠가 푸시 클라이언트(510)에게 전달된다.

단계 1716에서 푸시 클라이언트(510)는 클라이언트 메타데이터를 이용하고, 또한 단계 1718에서 콘텐츠 페이로드를 클라이언트 애플리케이션(150)에 전달한다. 클라이언트 애플리케이션(150)은 단계 1720에서 애플리케이션 메타데이터를 이용하고 또한 콘텐츠 페이로드를 소비한다.

단계 1722에서 알 수 있는 바와 같이, C₂로 표시된 제2 콘텐츠 페이로드는 제1 콘텐츠 페이로드와 동일한 메타데이터를 갖는다. 각각의 처리 엘리먼트, 즉, 푸시 프럭시(410), 푸시 클라이언트(510) 및 클라이언트 애플리케이션(150)은 콘텐츠 제공자(110)에 대한 메타데이터를 캐시하고 있기 때문에, 메타데이터는 다시 전달될 필요가 없고, 그 대신 이미 처리 엘리먼트에 존재한다.

그 후, 단계 1724에서 푸시 프럭시(410)는 푸시 프럭시(410)용으로 이전에 캐시된 메타데이터를 이용한다. 유사하게, 단계 1726 및 1728에서 푸시 클라이언트(510)는 클라이언트 메타데이터를 이용하고, 클라이언트 애플리케이션(150)은 애플리케이션 메타데이터를 각각 이용한다. 콘텐츠는 단계 1725 및 1727에서 메타데이터없이 전달된다.

단계 1740에 표시된 바와 같이, 콘텐츠는 푸시 클라이언트(510) 및 클라이언트 애플리케이션(150)에 대한 새로운 메타데이터를 가질 수 있지만, 푸시 프럭시(410)에 대한 구 메타데이터를 유지할 수 있다. 이 경우, 단계 1740에서 전달된 메타데이터는 클라이언트 메타데이터와 애플리케이션 메타데이터만을 포함한다. 단계 1742에서, 푸시 프럭시(410)는 캐시된 프럭시 메타데이터를 이용하고, 단계 1744에서 새로운 클라이언트 메타데이터와 애플리케이션 메타데이터와 함께 콘텐츠 페이로드를 전달한다.

단계 1746에서, 푸시 클라이언트(510)는 자신에게 전달된 새로운 클라이언트 메타데이터를 이용하고, 또한 단계 1748에서 콘텐츠 페이로드와 애플리케이션 메타데이터를 전달한다.

단계 1750에서 클라이언트 애플리케이션(150)은 새로운 애플리케이션 메타데이터를 이용하고, 콘텐츠 페이로드를 추가로 소비한다.

당업자라면 잘 알 수 있는 바와 같이, 어떤 메타데이터가 변경되고 어떤 메타데이터가 동일하게 유지되는지에 관한 각종 구성이 존재할 수 있고, 변경되는 메타데이터만이 그것을 요구하는 처리 엘리먼트에 전달된다. 당업자라면 잘 알 수 있는 바와 같이, 만일 새로운 메타데이터를 수신하지 못하면, 처리 엘리먼트는 그 처리 엘리먼트가 저장하고 있는 캐시된 메타데이터로 되돌아가고 캐시된 메타데이터를 콘텐츠 페이로드에서 이용한다.

또다른 대안적 실시예에서, 메타데이터에 대해서 증분적 변화가 또한 이루어질 수 있다. 예를 들면, 단계 1760에서 새로운 콘텐츠 페이로드는 델타 메타데이터와 함께 서비스 프럭시(410)에 전달될 수 있다. 프럭시 메타데이터의 델타는 이전에 전달된 프럭시 메타데이터와 콘텐츠를 처리할 현재 메타데이터 간의 차이를 포함할 수 있다. 푸시 프럭시(410)는 델타와 함께 이전 메타데이터를 추가하고 그 다음에 단계 1762에서 콘텐츠 페이로드를 처리하기 위해 이 데이터를 이용함으로써 메타데이터를 구성한다. 그 다음에, 변경이 없기 때문에, 단계 1764에서 콘텐츠 페이로드는 그 자신에 의해 보내지고, 단계 1766에서 푸시 클라이언트(510)는 이전에 캐시된 클라이언트 메타데이터를 이용한다.

그 다음에, 푸시 클라이언트는 단계 1768에서 콘텐츠 페이로드를 클라이언트 애플리케이션(150)에게 전달하고, 클라이언트 애플리케이션(150)은 단계 1770에서 콘텐츠 페이로드상의 이전에 캐시된 위치 메타데이터를 이용하며, 그 다음에 콘텐츠 페이로드를 소비한다.

증분 데이터를 사용할 수 있는 예는 콘텐츠 제공자가 콘텐츠 페이로드 내의 현존 필드의 프럭시를 말하는 상황이고, 30이 클라이언트 애플리케이션(150)에게 보내지기 위해 추출되어야 한다. 후속 처리에서, 그 콘텐츠 페이로드 피스에 중요한 2개의 추가적인 필드가 콘텐츠 제공자(110)에 의해 클라이언트 애플리케이션(150)에게 전달될 필요가 있는 것으로 간주될 수 있다. 그러므로, 증분 변화를 이용하는 콘텐츠 제공자는 2개의 추가적인 필드를 추출하여 이 필드를 이전에 추출된 30 필드에 추가하도록 푸시 프럭시에게 지시할 수 있다. 델타, 즉 2개의 추가적인 필드만을 전달할 필요가 있기 때문에, 푸시 프럭시(410)에서 메타데이터를 추출하는 처리 시간이 감소되고, 그에 따라 처리가 최적화된다.

명백히 알 수 있는 바와 같이, 메타데이터는 다양한 형태로 올 수 있다. 메타데이터는 원시 코드처럼 컴파일될 수도 있고, 자바 또는 C#처럼 해석된 코드일 수 있다. 메타데이터는 또한 특정 속성의 이용을 표시하는 데이터/속성 파일일 수 있다. 다른 대안적 실시예에서, 메타데이터는 이진 콘텐츠, 예를 들면 XML 문서에서 XSLT 변환과 같은 변환일 수 있다.

상기 예는 특정 클라이언트 애플리케이션에 전송되는 콘텐츠의 지능을 제공하기 위한 각종 애플리케이션용으로 사용될 수 있다. 또한 단지 그들의 데이터와 함께 제공하는 메타데이터에 기초해서 각종 애플리케이션에 대한 콘텐츠를 제공할 수 있는 콘텐츠 풍부 제공자를 제공할 수 있다. 이것은 도 18에 예로서 도시되어 있다.

콘텐츠 제공자(110)는 예를 들면 온라인 책 판매상(bookseller)일 수 있다. 애플리케이션은 특정 장르의 새로운 출간을 통보받기 원한다는 것을 온라인 책 판 매상에게 표시하기 위해 온라인 책 판매상에 등록할 수 있다. 이것은 매일 또는 주 단위 또는 월 단위로 행할 수 있다.

콘텐츠 제공자(110)는 예컨대 주 단위로 책 목록(1812)을 가진 콘텐츠 엔벨로프(1810)를 푸시 프럭시(410)에게 보낼 것이다. 콘텐츠 제공자(110)는 또한 예를 들면 특정 콘텐츠를 변환하기 위한 URL 링크인 변환 메타데이터(1814)를 그 메타데이터를 수신하는 애플리케이션에 기초해서 보낼 수 있다.

일 실시예에서, 책 목록(1812)은 다수의 책들 및 그 책의 저자와 줄거리를 비롯한 각 책의 설명을 포함할 수 있다. 파일은 예를 들면 100 KB의 크기일 수 있다.

푸시 프럭시(410)는 이 큰 파일을 수신하고, 서비스되는 클라이언트 애플리케이션에 기초해서, 예컨대 10 킬로바이트의 정보를 수신할 수만 있는 클라이언트를 더 잘 수용하기 위해 행하여질 필요가 있는 큰 콘텐츠 파일로의 변환을 실현할 수 있다. 프럭시 메타데이터로서 전달되는 변환은 책 목록에 적용되어 책 목록을 10 KB의 수정된 문서(1820)로 줄일 수 있다. 이것은 예를 들면 줄거리를 제거하고, 책을 등급정하고, 상위 50개만 포함시킴으로써 또는 당업자라면 잘 알 수 있는 다른 변환에 의해 행하여질 수 있다.

일단 변환이 완료되면, 수정된 문서(1820)는 푸시 클라이언트(510)에게 보내진다.

또한, 도 4에 도시된 것과 같은 지연 검색 메시지 기억부(452)는 변환 처리에서 제외된 여분의 콘텐츠를 저장하기 위해 사용될 수 있다.

상기 예의 장점은 책 판매상이 하나의 사이트를 갖고 하나의 목록을 그 클라이언트 모두에게 보낼 수 있다는 것이다. 각각의 클라이언트가 모바일 무선 클라이언트는 아닐 것이기 때문에, 100 KB 파일은 이들 클라이언트에게 적당할 것이다. 또한, 변환 메타데이터를 제공함으로써, 책 판매상은 모든 사람에게 보내는 하나의 목록을 가질 수 있다. 당업자라면 잘 알 수 있는 바와 같이, 최근의 웹 기술은 모바일 클라이언트에 대한 별도의 웹사이트를 요구하고, 이것은 상기 해법에 의해 극복된다.

상기 예는 합성 모델에도 또한 적용될 수 있고, 이제 도 19를 참조한다.

당업자라면 잘 알 수 있는 바와 같이, 모바일 장치는 네트워크 조건이 대량의 데이터를 수신하기에 적당하지 않을 때 대량 데이터의 수신을 원하지 않을 수 있다. 또한, 네트워크 운용자는 네트워크 교통량을 시간대별로 고르게 분산시키기 위해 대역폭 사용이 최고인 기간 동안에 대량의 데이터 전송을 피하고 싶어할 수 있다. 이것은 도 19에 도시된 푸시/풀 모델을 이용하여 달성될 수 있다.

도 4를 참조하여 위에서 설명한 바와 같이, 콘텐츠는 사용자가 현재 필요로 하는 것보다 더 많은 정보를 포함하는 것으로 제공될 수 있다. 예를 들어서 사용자가 그가 위치하고 있는 지역 내의 식당의 위치 정보를 요구하면, 서비스 제공자는 그 지역에서 이용가능한 다른 서비스의 광고를 추가하기 원할 수 있다. 그러나, 서비스 제공자는 이 추가적인 콘텐츠를 사용자에게 즉시 푸시하는 것을 원하지 않고, 그 대신 추가적인 콘텐츠를 나타내는 헤드라인 또는 목차(table of contents)와 같은 프리머(primer)를 제공할 수 있다.

다른 상황에서, 콘텐츠는 사용자에게 전송하기에 너무 클 수 있고, 사용자는 콘텐츠의 제1 부분만 수신하고 콘텐츠의 나머지는 지연 검색 메시지 기억부(510)에 저장될 수 있다.

그 다음에, 저장된 콘텐츠는 푸시 프럭시(410)에 의해 또는 푸시 클라이언트(510)의 요청이 있을 때 푸시 클라이언트(510)에게 전달될 수 있다.

푸시 클라이언트(510)는 네트워크의 상태를 감시할 수 있는 네트워크 상태 감시자(1910)를 포함한다. 푸시 클라이언트(510)는 특정 조건에서 여분의 데이터를 수신하는 것만 원할 수 있다. 예를 들면, WiFi 및 셀룰러 옵션을 가진 하이브리드 모바일 장치에서, WiFi 접속으로 데이터를 제공하는 것이 더 저렴하고, 따라서, 네트워크 상태 감시자(1910)는 푸시 클라이언트(510)가 지연 콘텐츠를 취하기 전에 WiFi 네트워크에 접속될 때까지 대기할 수 있다. 대안적으로, 네트워크 상태 감시자는 클라이언트가 외국 네트워크에 로밍하는지 또는 로밍 비용을 최소화하기 위해 홈 네트워크에 접속되는지를 체크할 수 있다. 네트워크 상태 감시자는 또한 장치에 대하여 전용 데이터 채널이 확립되었는지를 체크할 수 있다. 네트워크 상태 감시자(1910)는 또한 지연 데이터가 푸시 클라이언트(510)에게 전달될 것을 요구하기 전에 네트워크에서 다른 각종의 전제조건을 체크할 수 있다는 것을 당업자라면 이해할 것이다.

무선 네트워크(130)는 또한 데이터 전달 비용에 관한 정보를 푸시 클라이언트(510)와 푸시 프럭시(410) 중의 어느 하나 또는 양쪽에 제공할 수 있다. 당업자라면 잘 알 수 있는 바와 같이, 콘텐츠를 전달하는 데는 각종 피크 기간이 있다. 교통량 정보의 경우, 피크 기간은 사람들이 출퇴근하는 근무일의 출근 시간대와 퇴근 시간대일 수 있다. 주식 시세의 경우, 피크 기간은 시장이 열려있는 시간 동안일 수 있다. 다른 피크 기간이 있을 것이다. 데이터 교통량을 평균화하기 위해, 네트워크에서의 현재 데이터 사용량에 기초하여 네트워크가 상이한 비율을 부담하게 하는 것이 바람직하다. 따라서, 피크 기간 중에는 한밤중과 같은 비피크 기간보다 더 높은 비율을 부담할 수 있다. 그러므로, 무선 네트워크(130)는 푸시 클라이언트(510)의 지연 검색 관리자(552)에게 및 푸시 프럭시(410)의 푸시 스케쥴러(454)에게 전달 비용 통지를 제공한다.

일 실시예에서, 콘텐츠 제공자(110)로부터 푸시 프럭시(410)로 전달되는 데이터는 클라이언트에게의 중요도에 따라서 등급이 매겨질 수 있다. 특정 정보는 즉시 전달될 메타데이터를 통하여 지정될 수 있다. 다른 정보는 네트워크 비용이 제1 값(예를 들면 메가바이트당 10센트)보다 적을 때 전달되도록 지정될 수 있고, 다른 데이터는 네트워크 비용이 제2 값(예를 들면 메가바이트당 5센트) 아래로 떨어질 때 전달되도록 지정될 수 있다. 따라서, 푸시 스케쥴러(454)는 지연 검색 메시지 기억부(452)에 저장된 데이터를 생각하고 지연 데이터를 푸시 클라이언트(510)의 푸시 에이전트(544)에게 전달하도록 푸시 에이전트(444)에게 지시한다.

대안적으로, 지연 검색 관리자(552)는 무선 네트워크(130)로부터 보내진 네트워크 조건을 감시하고, 만일 데이터 속도가 특정 속도 이하이면 지연 검색 메시지 기억부(452)로부터 콘텐츠를 풀링하도록 콘텐츠 풀(pull) 브로커(554)에게 요청할 수 있다.

대안적으로, 지연 검색 관리자(552)는 모바일 장치가 WiFi 네트워크에 접속되는 경우와 같이 네트워크 상태가 대량의 데이터를 풀링할 수 있는지를 확인하고, 지연 검색 메시지 기억부(452)로부터 데이터를 풀링하도록 콘텐츠 풀 브로커(554)에게 요청할 수 있다.

명백히 알 수 있는 바와 같이, 사용자는 풀링한 콘텐츠를 갖기를 항상 요구할 수 있다. 따라서, 사용자 요구(1940)는 지연 검색 메시지 기억부(452)로부터 데이터를 풀링하도록 콘텐츠 풀 브로커(554)를 트리거하기 위해 사용될 수 있다.

푸시 스케쥴러(454) 및 지연 검색 관리자(552)에 저장된 규칙들은 콘텐츠의 분류에 기초한 정적 메타데이터일 수 있다. 규칙들은 전달되어진 특정 데이터에 대한 동적 메타데이터에 또한 기초할 수 있다. 이 경우, 콘텐츠 제공자(110)는 데이터를 분류한다.

이제 도 20을 참조한다. 당업자라면 잘 알 수 있는 바와 같이, 데이터는 선형 또는 비선형 형태를 가질 수 있다. 예를 들면, 선형 데이터는 배열(array) 또는 줄(string) 또는 선형으로 흐르는 콘텐츠일 수 있다. 반대로, 비선형 데이터는 서로에 대해 선형으로 관련되지 않은 데이터이고, 콘텐츠 맵 또는 링크와의 복합 의존성을 포함할 수 있다.

선형 콘텐츠에 대해서, 프래그먼트화(fragmentation)는 선형 진행에 기초하여 데이터를 각종 컴포넌트로 단순히 나누는 것을 수반한다. 데이터는 수 개의 세그멘트로 분할되고, 세그멘트들은 푸시 프럭시(410)에 전달된다. 도 20에 도시된 바와 같이, 프래그먼트화 처리기(2010)는 콘텐츠(2012)와 상호작용하여 콘텐츠가 선형 진행으로 분석될 수 있는지를 결정한다. 프래그먼트화 처리기(2010)는 그 다음에 데이터를 도 20의 예에서는 세그멘트 2014, 2016 및 2018로 분할하고, 도 20에 도시된 바와 같이, 제1 세그멘트(2014)를 전달하는 한편 제2 및 제3 세그멘트(2016, 2018)의 전달은 각각 지연시킨다.

커서 관리 모듈(2030)은 세그멘트가 전달되는 트랙을 유지하고 다음 세그멘트를 차례로 전달한다.

도 21을 참조하면, 비선형 콘텐츠는 보다 더 지능적인 방법으로 분할될 필요가 있다. 또한, 다른 한편으로, 세그멘트를 재구성하기 위해 메타데이터가 요구된다.

프래그먼트화 처리기(2110)는 메타데이터 기반 분석에 따라서 콘텐츠를 분석한다. 이것은 만일 논리적으로 필요하다면 특정 세그멘트 또는 데이터 엘리먼트를 함께 유지하는 것을 포함한다. 프래그먼트화 처리기(2110)는 콘텐츠(2112)를 분석하고, 콘텐츠를 논리 규칙에 따라서 다수의 세그멘트로 분할한다. 각 세그멘트는 예를 들면 의존성, 맵 및 각 세그멘트의 내비게이션 규칙을 포함하는 메타데이터와 콘텐츠를 포함한다.

일단 분할되면, 제1 세그멘트(2114)는 푸시 클라이언트(510)에게 보내지고, 나머지 세그멘트(2116, 2118)의 전달은 도 21에 도시된 바와 같이 지연된다. 세그멘트 내비게이션 블록(2130)은 어떤 세그멘트를 다음에 전송할 것인지를 결정한다. 당업자라면 잘 알 수 있는 바와 같이, 제1 세그멘트(2114)는 데이터부와 메타데이터부를 포함한다. 세그멘트(2114)의 메타데이터부는 콘텐츠 재구성 방법을 콘텐츠 의존 모듈(564)에 표시하기 위해 프래그먼트화 처리기(2110)에 의해 추가되는 메타데이터의 층이다. 제1 세그멘트(2114)의 데이터부는 콘텐츠, 및 채널 또는 콘텐츠와 관련된 메타데이터 양쪽을 포함할 수 있다.

세그멘트 내비게이션 블록(2130)은 사용자가 데이터를 통해 이동하는 법을 처리하기 위해 채택된다. 예를 들어서, 만일 데이터가 트리 형태이고 사용자가 트리의 제1 브랜치를 따라 아래로 내려가면, 세그멘트 내비게이션 블록(2130)은 사용자가 내비게이션하는 엘리먼트로부터 도달될 수 있는 트리의 다른 브랜치를 푸시 클라이언트(510)에게 전달할 수 있다.

예를 들면, 트리는 회사의 구조와 함께 고용인 이름을 가진 고용인 데이터베이스를 포함할 수 있다. 도 21에 기초해서, 만일 사용자가 조직의 특정 부서로 내비게이트하면, 세그멘트 내비게이션 블록(2130)은 그 부서 내의 그룹에 대한 그룹 파편(group fragment)을 회송할 것이다. 만일 사용자가 부서 내의 특정 그룹에 내비게이트하면, 세그멘트 내비게이션 블록(2130)은 그 그룹 내의 고용인에 관한 정보 파편을 전달할 것이다.

그러므로, 상기 예는 데이터가 논리 컴포넌트들로 분할될 것을 요구한다. 모든 유형의 콘텐츠에는 식별자가 할당되고, 프리머와 함께 정보를 전달하는 구조 정보가 생성된다.

그러므로, 상기 예는 애플리케이션 및 콘텐츠가 시스템의 구조를 변경하지 않고 추가될 수 있는 범용 시스템에서 사용할 수 있는 동적 콘텐츠 전달 구조를 제공한다. 콘텐츠는 콘텐츠를 수신하는 애플리케이션에 맞도록 고쳐질 수 있고 상기 예에 따라 프래그먼트화될 수 있다.

상기 예는 콘텐츠 제공자 및 애플리케이션이 콘텐츠 전달 환경을 인식하는 범용 시스템을 제공하지만, 본 발명의 방법 및 시스템의 일 실시예에서 콘텐츠 제공자와 애플리케이션의 어느 하나 또는 양쪽은 콘텐츠 전달 환경을 인식하지 않아도 된다. 이제 도 22를 참조한다. 도 22에서, 콘텐츠 전달 인에이블러(CDE)(2210)는 콘텐츠 제공자(2230)와 클라이언트 애플리케이션 간의 동적 콘텐츠 전달 및 콘텐츠 제공자(2230)와 애플리케이션을 묶는 능력을 촉진하도록 적응된다. 콘텐츠 전달 인에이블러(2210)는 도 1의 푸시 프레임워크(100)와 동일한 것이다.

콘텐츠 전달 인에이블러(2210)는 푸시 클라이언트(2212), 무선 네트워크(2214) 및 푸시 서버(2216)를 포함한다. 이것들은 도 1의 푸시 클라이언트(140), 무선 네트워크(130) 및 서비스 제공자(120)와 각각 등가의 것이고, 도 1과 관련한 컴포넌트들의 설명을 도 22의 실시예에 적용할 수 있다.

도 22의 실시예에서, 콘텐츠 제공자(2230)는 범용 콘텐츠 제공자이다. 다시 말해서, 콘텐츠 제공자(2230)는 다른 전달 수단을 사용하는 다른 단말에서 사용되고, 따라서 임의의 특정한 콘텐츠 전달 아키텍쳐에 불가지론적(agnostic)이다. 이러한 범용 콘텐츠 제공자(2230)는 당업자에게 잘 알려져 있고 다양한 클라이언트에게 서비스할 수 있다.

모바일 장치의 사용자는 어떤 상황에서 정규 브라우징을 통하여 콘텐츠 제공자(2230)에게 접근할 수 있다. 그러나, 만일 동적 콘텐츠 전달과 같은 더 복잡한 서비스가 범용 콘텐츠 제공자(2230)로부터 요구되면, 범용 콘텐츠 제공자(2230)를 전술한 바와 같은 콘텐츠 전달 아키텍쳐에 가져오기 위한 수단이 필요하다. 콘텐츠 제공자(2230)는 콘텐츠 제공자(2230)로부터 콘텐츠를 수신하고자 하는 임의의 애플리케이션이 콘텐츠 제공자(2230)에게 등록하는 옵션이 주어지는 것을 보장하기 위해 콘텐츠 전달 인에이블러(2210)에 등록되어야 한다. 또한, 콘텐츠 전달 인에이블러(2210)는 전달 개요 및 스케쥴을 확립하고 애플리케이션 또는 콘텐츠를 처리할 수 있는 애플리케이션 유형을 식별하기 위하여 범용 콘텐츠 제공자(2230)로부터 제공되는 콘텐츠에 대한 메타데이터 정보, 또는 콘텐츠 전달 인에이블러(2210) 및 애플리케이션 견지(perspective)로부터 소요되는 임의의 다른 정보를 가질 필요가 있다.

도 1 내지 도 21을 참조하여 위에서 설명한 바와 같이, 콘텐츠 제공자(2230)를 콘텐츠 전달 아키텍쳐에 가져오기 위해, 콘텐츠 제공자(2230)에 대한 메타데이터가 존재할 필요가 있다.

유사하게, 도 22에 도시된 클라이언트 애플리케이션(2240, 2245, 2250)과 같은 클라이언트 애플리케이션은 여기에서 범용 애플리케이션(2255)이라고 부르는 범용 클라이언트 애플리케이션일 수 있다. 다시 말해서, 범용 애플리케이션(2255)은 콘텐츠 전달 아키텍쳐에 대해 불가지론적일 수 있다.

범용 애플리케이션(2255)이 콘텐츠 전달 모델을 인식하지 못하고 콘텐츠 전달 모델을 통해 동적 콘텐츠를 수신하게끔 상호작용하도록 특별히 설계되어 있지 않으면, 그러한 애플리케이션(2255)은 그들 자신측에서 콘텐츠 전달 인에이블러(2210)에 등록할 수 없을 것이다. 이러한 애플리케이션(2255)은 전형적으로 콘텐츠 전달 인에이블러 및 등록 인터페이스에 관한 지식을 갖고 있지 않고, 따라서 도 1 내지 도 21을 참조하여 설명한 바와 같은 상기 모델에 적합하지 않다.

범용 콘텐츠 제공자(2230)와 마찬가지로, 범용 애플리케이션(2255)을 결합하는 것이 바람직하다. 이러한 애플리케이션은 모바일 장치 사용자에게 모바일 장치에 로드된 애플리케이션에 관한 더 많은 선택을 제공함과 아울러 로드된 애플리케이션의 기능성을 제공한다.

범용 애플리케이션(2255)과 같은 애플리케이션을 결합하기 위해, 본 발명은 메디에이터(mediator)(2260)를 제공한다. 메디에이터(2260)의 역할은 등록하는 애플리케이션의 메타데이터에 대한 지식 및 애플리케이션을 등록하기 위한 메타데이터 개요를 포함하는 등록 인터페이스에 대한 지식을 갖는 것이다.

메디에이터(2260)는 범용적인 것일 수도 있고 애플리케이션마다 특정한 것일 수도 있다. 예를 들면, 메디에이터(2260)는 애플리케이션과 함께 애플리케이션 개발자에 의해 제공될 수 있다. 그 다음에, 메디에이터(2260)는 예를 들면 애플리케이션이 특정 콘텐츠 전달 인에이블러로 특정 애플리케이션을 등록하기 위해 모바일 장치에 로드될 때 동작한다. 이 경우, 메디에이터(2260)는 애플리케이션에 대한 메타데이터 정보를 포함한다.

대안적으로, 범용 메디에이터(2260)는 모바일 장치에 존재할 수 있다. 그 경우, 다른 트리거 중에서도 특히, 예를 들면 모바일 장치에 로드된 애플리케이션을 가짐으로써, 콘텐츠 전달 인에이블러(2210)로 애플리케이션을 등록하는 사용자 요구를 가짐으로써, 애플리케이션에 예정되어진 메타데이터를 수신함으로써 일단 애플리케이션 등록이 요구되면, 범용 메디에이터(2260)는 저장소(2280)로 가서 애플리케이션에 대한 메타데이터를 획득할 수 있다.

명백히 알 수 있는 바와 같이, 일단 메타데이터가 애플리케이션(2255)에 대한 메디에이터(2260)에 의해 수신되면, 메디에이터는 그 다음에 애플리케이션을 콘텐츠 전달 인에이블러(2210)와 결합하도록 요구될 것이다.

이제 도 23을 참조한다. 메디에이터(2370)는 콘텐츠 전달 인에이블러(2345)에 의해 요구된 메타데이터 스키마(schema)(2340)에 대한 애플리케이션(2310)과 관련된 메타데이터(2320)를 분석(resolve)하려고 시도한다. 구체적으로, 애플리케이션(2310)은 자신과 관련된 메타데이터, 즉, 여기에서는 애플리케이션 메타데이터(2320)라고 부르는 메타데이터를 포함한다. 애플리케이션 메타데이터(2320)는 애플리케이션(2320)이 기대하는 각종 파라미터를 포함한다. 그 예를 들자면, 도달하는 콘텐츠가 저장되는 기억장치 파라미터, 애플리케이션이 기꺼이 수락하려고 하는 데이터의 프래그먼트화 또는 크기 제한 등이 있다. 다른 파라미터는 예를 들면 애플리케이션이 콘텐츠 도달을 통지받아야 하는지 또는 콘텐츠가 예컨대 캐시를 이용하여 애플리케이션에 직접 제공되어야 하는지, 또는 콘텐츠가 미리 규정된 위치에 저장되어야 하는지를 포함하는 통지 파라미터들을 포함한다. 애플리케이션에 특정한 다른 메타데이터도 또한 본 발명의 범위 내에서 예상할 수 있다.

도 23에 도시된 바와 같이, 콘텐츠 전달 인에이블러는 여기에서 콘텐츠 전달 인에이블러 메타데이터 스키마(2340)라고 부르는, 그들과 관련된 메타데이터 스키마를 포함한다. 명백히 알 수 있는 바와 같이, 콘텐츠 전달 인에이블러 메타데이터 스키마(2340)는 애플리케이션에 대한 콘텐츠를 취급 및 전달할 수 있도록 콘텐츠 전달 인에이블러(2345)에서 필요로 하는 애플리케이션 관련 파라미터를 취급한다.

메디에이터(2370)는 콘텐츠 전달 인에이블러 메타데이터 스키마(2340)로 애플리케이션 메타데이터(2320)를 분석한다. 그러한 분석은 애플리케이션 메타데이터(2320)를 판독하는 단계, 필요로 하는 파라미터 및 정보를 추출하는 단계, 전달 취급 관련 정보를 애플리케이션 메타데이터(2320)에 추가하는 단계, 데이터를 애플리케이션(2310)이 수락가능한 포맷으로 변환하는 단계, 및 콘텐츠 전달 인에이블러(2345)로 애플리케이션(2310)의 등록을 진행하는 단계를 포함한다. 전달 취급 관련 정보의 추가는 장치의 미리 특정된 파라미터에 기초할 수 있고, 또는 사용자가 그 정보를 수신하거나 취급하기 원하는 데이터에 대한 정보를 지정하도록 촉구되는 것과 같은 사용자 입력을 포함할 수 있다.

유사하게, 도 22의 메디에이터(2270)는 콘텐츠 제공자(2230)에 대한 메타데이터와 푸시 서버(2216)에 대한 메타데이터 사이에서 유사한 기능을 수행한다. 메디에이터(2270)는 콘텐츠 제공자 메타데이터와 콘텐츠 전달 인에이블러 메타데이터 사이에서 파라미터를 접속한다.

이것에 의해 메디에이터(2260, 2270)는 범용 애플리케이션용 및 범용 콘텐츠 제공자용으로 각각 허용된다. 메디에이터(2260)가 상기 기능을 수행할 수 있게 하기 위해, 각종 옵션들을 이용할 수 있다.

모바일 장치에서의 런타임 환경은 콘텐츠 전달 인식(aware)일 수도 있고 콘텐츠 전달 인식이 아닐 수도 있다. 만일 런타임 환경이 콘텐츠 전달 인식이면, 런타임 환경은 2가지 방법 중 하나의 방법으로 작용할 수 있다. 첫번째 방법에서, 런타임 환경은 새로운 애플리케이션이 설치되었는지, 사용자가 애플리케이션을 콘텐츠 전달 시스템에 접속하기 원하는지, 또는 범용 애플리케이션(2255)이 콘텐츠 전달 인에이블러(2210)에 접속되어야 함을 다른 트리거가 표시하는지를 확인할 수 있다.

일 실시예에서, 런타임 환경은 중앙 저장소로부터 다운로드되는 특정 용도 메디에이터(2260)를 개시(initiate)할 수 있다. 메디에이터(2260)는 애플리케이션이 최초로 모바일 장치에 로드될 때, 사용자가 애플리케이션으로부터 동적 콘텐츠 전달을 요구할 때, 모바일 장치에 의해 서비스될 수 있는 콘텐츠가 도달할 때 등을 비롯해서 각종 시간에 공중을 통해 프로비져닝될 수 있다. 특정 용도 메디에이터(2260)는 애플리케이션 메디에이터의 서비스 제공자 관리 저장소로부터 제공될 수 있고, 또는 애플리케이션 개발자 또는 리테일러에 의해 제공된 애플리케이션에 대한 저장소에서 애플리케이션 개발자 또는 리테일러에 의해 제공될 수 있다.

특정 용도 메디에이터(2260)가 다운로드되면, 런타임 환경은 다운로드된 메디에이터(2260)를 실행하고, 이것에 의해 애플리케이션을 콘텐츠 전달 인에이블러에 결합할 수 있다.

대안적으로, 런타임 환경 자체는 메디에이터 애플리케이션으로서 동작할 수 있다. 이 경우, 환경은 등록 처리를 실행하는 방법을 알고, 중앙 저장소로부터 애플리케이션에 대한 메타데이터를 다운로드할 수 있다. 이 점에서, 런타임 환경은 콘텐츠 전달 인에이블러(2210)로 애플리케이션을 등록하기 위해 메타데이터를 사용 할 수 있다.

다른 실시예에서, 만일 런타임 환경이 콘텐츠 전달 인식이 아니면, 사용자는 범용 애플리케이션 등록을 위해 특정 애플리케이션의 로딩을 개시할 필요가 있다. 특정 애플리케이션은 장치가 콘텐츠 전달을 인식하게 하고, 다운로드된 특정 애플리케이션은 그 다음에, 범용 애플리케이션 등록 트리거가 발생할 때마다, 범용 애플리케이션에 대한 메타데이터를 찾는 처리를 행하여 발견된 메타데이터를 이용하여 애플리케이션을 등록할 수 있다.

그러므로, 상기 예는 애플리케이션 및 이 애플리케이션과 관련된 메타데이터의 로딩, 실행 및 결합이 자동으로 또는 사용자의 구동에 의해 행하여질 수 있다는 것을 묘사한다. 다시 말해서, 사용자가 처리를 개시할 수도 있고, 또는 애플리케이션이 장치에 다운로드될 때마다 처리가 자동으로 행하여질 수도 있다. 3개의 모델, 즉 콘텐츠 전달 인식 런타임 환경에 의해 저장소로부터 특정 용도 메디에이터의 로딩; 범용 메디에이터로서 작용하는 콘텐츠 전달 인식 런타임 환경에 의해 저장소로부터 애플리케이션 메타데이터의 로딩; 또는 콘텐츠 전달 아키텍쳐를 인식하는 비콘텐츠 전달 인식 런타임 환경을 만들기 위해 모바일 장치에 대한 특정 애플리케이션의 로딩이 설명되었고, 그래서 새로운 콘텐츠 전달 인식 아키텍쳐가 메타데이터를 다운로드하고 범용 메디에이터로서 작용할 수 있다.

이용가능한 추가의 옵션은 특정 애플리케이션이 설치된 모바일 장치에 등록 메타데이터 또는 메디에이터를 푸시하는 것이다. 푸싱은 예컨대 저장소로부터 애플리케이션의 다운로딩시에 애플리케이션 저장소와 같은 제3자 엔티티로부터 또는 서 비스 제공자로부터 발생할 수 있다. 또한, 사용자가 푸시 클라이언트(2212)를 모바일 장치에 설치하여 콘텐츠 전달 프레임워크를 결합할 때, 서비스 제공자는 그 시간에 모바일 장치에 이미 설치된 애플리케이션에 대한 등록 메타데이터를 푸시할 수 있다. 애플리케이션의 목록은 이 경우 장치에 의해 제공될 수 있다. 다른 옵션은 본 발명에 대하여 통상의 지식을 갖는 사람에게는 명백할 것이다.

전술한 바와 같이, 메타데이터 또는 메타데이터 애플리케이션 자체를 획득하기 위한 중앙 저장소에 대한 대안적인 예는 저장소에 애플리케이션을 제공하는 것이다. 다시 말해서, 각각의 애플리케이션 개발자에게는 각종 저장소가 존재할 것이다. 그 다음에, 각 애플리케이션 개발자는 애플리케이션에 특정한 메디에이터 또는 메타데이터를 제공할 수 있다. 양호한 실시예에서, 메타데이터 또는 메디에이터는 또한 사용되는 콘텐츠 전달 아키텍쳐마다 특수할 수 있다. 이 방법에서, 도 22의 메디에이터(2260) 또는 도 23의 메디에이터(2370)는 콘텐츠 전달 인에이블러 메타데이터(2340)와 애플리케이션 메타데이터(2320) 간의 파라미터가 일치할 것이기 때문에 파라미터의 정합을 수행할 필요가 없다.

콘텐츠 제공자(2230)에 대해서, 조정은 푸시 서버(2216)에서 수행되고 상기 예에 대하여 불가지론적이다. 다시 말해서, 푸시 서버(2216)는 특정 콘텐츠 제공자에 대한 메디에이터를 얻을 수 있거나 콘텐츠 제공자에 대한 메타데이터를 획득할 수 있는 범용 메디에이터를 포함할 수 있다. 조정은 콘텐츠 전달 인에이블러 메타데이터(2340)와 콘텐츠 제공자 메타데이터(도시 생략됨) 사이에서 발생한다.

상기 예는 또한 암시적(implicit) 및 명시적 결합(explicit binding)을 고려함으로써 확장될 수 있다. 본 발명에 관한 당업자라면 잘 알 수 있는 바와 같이, 애플리케이션은 콘텐츠 제공자에게 결합된다. 다시 말해서, 콘텐츠 제공자는 콘텐츠 제공자가 제공하는 데이터를 취급할 것으로 기대되는 애플리케이션 또는 애플리케이션 유형을 표시할 수 있다.

일 예에서, 콘텐츠 제공자는 특정 애플리케이션만이 콘텐츠 제공자로부터의 콘텐츠를 취급할 수 있다는 것을 지정할 수 있다. 그 다음에, 콘텐츠 전달 인에이블러(2210)는 콘텐츠 제공자가 이용할 수 있는 특정 애플리케이션이 설치된 모바일 장치에만 통지를 행할 것이다. 애플리케이션에 대한 메타데이터 및 파라미터는 콘텐츠 제공자로부터 알려지고, 따라서 콘텐츠 제공자에 대한 애플리케이션의 결합은 명시적이다.

상기 콘텐츠 제공자 및 애플리케이션은 범용적인 것일 수 있다. 다시 말해서, 콘텐츠 제공자와 애플리케이션은 콘텐츠 전달 구조에 대하여 불가지론적일 수 있다. 그러므로, 상기 예는 콘텐츠 제공자와 콘텐츠 전달 인에이블러(2210) 사이에서, 및 콘텐츠 전달 인에이블러(2210)와 애플리케이션(2255) 사이에서 메디에이터를 요구할 수 있다.

애플리케이션(2255)은 또한 명시적 결합을 제공하도록 구성될 수 있다. 예를 들어서, 애플리케이션은 콘텐츠가 콘텐츠 제공자(2230)에 대한 특정 URI로부터 요구된다는 것을 지정할 수 있다. 만일 애플리케이션(2255)이 콘텐츠 제공자(2230) 이전에 등록되면, 모바일 장치는 애플리케이션(2255)이 요구한 콘텐츠 제공자(2230)가 등록되자마자 통지될 것이다.

명시적 결합에서의 관계는 서버측에서 관리된다. 콘텐츠 제공자 인에이블러(2210)는 콘텐츠 전달 인에이블러(2210)에 접속된 장치 및 애플리케이션(2255)에 대한 정보를 가지며, 애플리케이션(2255)이 존재하는 장치들에만 통지를 보낼 것이다.

대안적으로 암시적 결합이 발생할 수 있다. 예를 들면, 콘텐츠 제공자(2230)는 특정 유형의 콘텐츠를 제공하는 것을 지정할 수 있다. 만일 애플리케이션(2230)이 그 유형의 콘텐츠의 전부 또는 부분집합을 처리할 수 있다고 지정하면, 콘텐츠 제공자(2230)에게 수락가능한 것이라고 생각할 수 있다.

암시적 결합 상황에서, 콘텐츠 제공자(2230)와 애플리케이션(2255) 양쪽은 콘텐츠 전달 인에이블러(2210)에 콘텐츠 유형 토큰(token)을 제공하여야 한다. 그 다음에, 콘텐츠 전달 인에이블러(2210)는 콘텐츠 제공자의 토큰에 대한 스키마를 애플리케이션의 토큰과 연결하는 것을 정합시켜야 한다.

일 예에서, 콘텐츠 제공자(2230)는 RSS 피드(feed)를 제공한다는 것을 표시한다. 만일 애플리케이션이 RSS 피드를 처리할 수 있다고 표시하면, 정합이 존재하고 암시적 결합이 발생할 수 있다.

명백히 알 수 있는 바와 같이, 콘텐츠 제공자는 다수 유형의 데이터를 제공할 수 있고, 애플리케이션은 그러한 유형의 데이터를 모두 처리하지 못할 수 있다. 또한, 콘텐츠 제공자는 특수형, 즉 고객맞춤형 정보를 제공할 수 있고, 애플리케이션은 범용 처리만을 제공할 수 있다. 예를 들어서, 만일 주식 시세 RSS 콘텐츠 제공자가 주식 시세 정보를 위하여 특수화 RSS 피드를 제공하면, 범용 RSS 피드 뷰어 애플리케이션은 기대된 사용자 경험을 제공하지 않을 수 있다.

일 실시예에서, 강도 메트릭(strength metric)은 애플리케이션이 콘텐츠 제공자와 결속(tie)되어야 하는지를 결정하기 위해 사용될 수 있다. 따라서, 만일 애플리케이션이 콘텐츠 제공자에 의해 제공된 어떠한 스키마도 포함하지 않으면, 제로의 강도가 등록되고 애플리케이션은 콘텐츠 제공자와 결속되지 않을 것이다.

강도는 애플리케이션(2255)에 의해 해석될 수 있는 콘텐츠 제공자(2230)에 의해 제공된 정보 유형의 수에 관계될 수 있다. 따라서, 0 내지 X(여기에서 X는 임의의 정수임)의 정수가 강도 메트릭이 될 수 있다.

강도 메트릭은 애플리케이션을 콘텐츠 제공자에게 결합하는 것에 대한 결정을 하기 위해 사용될 수 있다. 예를 들어서, 만일 1의 강도가 있으면, 사용자는 애플리케이션을 콘텐츠 제공자에게 결합하기 원하고, 프롬프트가 사용자에게 제공될 수 있다. 만일 2의 강도가 있으면, 결합이 자동으로 이루어질 수 있다. 상기 예는 단지 설명을 위한 예에 불과하고, 각종의 결속 방식이 구현될 수 있다.

상기 예에서, 만일 콘텐츠 제공자에게 "RSS", "재정", 및 "주식 시세" 세그멘트를 포함한 콘텐츠 토큰이 제공되고 범용 RSS 피드 뷰어 애플리케이션에 콘텐츠 토큰 "RSS"가 제공되면, 강도는 1로서 정의될 것이다. 반면에, 만일 애플리케이션이 재정 정보에 대한 맞춤형 RSS 뷰어로서 설계되고 "RSS" 및 "재정" 세그멘트를 가진 콘텐츠 토큰이 제공되면, 강도는 2로 될 수 있다.

본 발명에 관한 당업자라면 잘 알 수 있는 바와 같이, 콘텐츠 제공자에 대한 애플리케이션의 결속은 콘텐츠 전달 인에이블러(2210) 아키텍쳐에서 중요하다. 모 바일 장치는 애플리케이션이 그들의 정보를 처리할 수 있는 새로운 콘텐츠 제공자가 추가되는 경우에 통지를 받는다. 또한, 애플리케이션이 콘텐츠 전달 인에이블러(2210)로 등록할 때 애플리케이션(2255)은 애플리케이션이 활용할 수 있는 콘텐츠 제공자(2230)의 목록을 제공받을 수 있다. 모든 애플리케이션(2255) 또는 콘텐츠 제공자(2230)가 그들이 사용하려고 의도하는 제공자(2230) 또는 애플리케이션(2255)을 각각 명시적으로 제공하는 것은 아니기 때문에, 콘텐츠 제공자에 대한 애플리케이션의 명시적인 결속은 콘텐츠 전달 인에이블러(2210)에 의해 수행되어야 한다.

전술한 강도 메트릭은 사용될 수 있는 강도 메트릭의 일 예에 불과하다. 또한 콘텐츠 유형 토큰의 스키마가 또한 범용적인 것이지만, 명백한 바와 같이, 애플리케이션 및 콘텐츠 제공자 양쪽에 대해서 공통으로 될 필요가 있다. 콘텐츠 전달 인에이블러(2210)는 암시적 결합을 위한 후보를 식별하기 위해 어떤 발견적 지도법(heuristics)을 적용하여야 한다. 또한, 토큰의 콘텐츠는 콘텐츠 전달 인에이블러(2210)에 대하여 불투명일 수 있고, 일부 경우 토큰의 스키마가 또한 불투명하게 될 수 있다. 이것은, 예를 들면, 결합이 콘텐츠 유형의 정확한 정합을 위하여 발생하는 경우에 존재한다.

강도 메트릭의 다른 예는 절대 정수(absolute integer) 대신에 사용될 수 있는 비율(ratio)이다. 따라서, 만일 콘텐츠 제공자(2230)가 콘텐츠 토큰에서 3개의 세그멘트(예를 들면, "RSS", "재정", "주식 시세")를 제공하면, 범용 RSS 뷰어 애플리케이션(예를 들면, "RSS")의 비율은 1/3이고 재정 정보용 특수화 RSS 뷰어(예를 들면, "RSS" 및 "재정" 세그멘트)의 비율은 2/3이다.

그러므로, 상기 예는 콘텐츠 전달 인에이블러 구조에 의한 범용 애플리케이션 및 범용 콘텐츠 제공자의 등록을 제공하고, 또한 애플리케이션 및 콘텐츠 제공자에 따라서 콘텐츠 제공자에 대한 애플리케이션의 명시적 또는 암시적 결속을 제공한다.

명백히 알 수 있는 바와 같이, 푸시 클라이언트 및 클라이언트 애플리케이션은 임의의 모바일 장치에 상주할 수 있다. 하나의 예시적인 모바일 장치는 도 24를 참조하여 뒤에서 설명된다. 이것은 설명 목적으로 제공되는 것이고 제한하고자 하는 것이 아니다.

도 24는 본 발명의 장치 및 방법의 양호한 실시예와 함께 사용될 수 있는 이동국(mobile station)을 나타내는 블록도이다. 이동국(2400)은 적어도 음성 및 데이터 통신 능력을 가진 양방향 무선 통신 장치가 바람직하다. 이동국(2400)은 인터넷상에서 다른 컴퓨터 시스템과 통신하는 능력을 갖는 것이 좋다. 제공된 정확한 기능성에 따라서, 무선 장치는 예를 들면 데이터 메시징 장치, 양방향 페이저, 무선 이메일 장치, 데이터 메시징 능력이 있는 셀룰러 전화기, 무선 인터넷 설비, 또는 데이터 통신 장치라고 부를 수 있다.

이동국(2400)이 양방향 통신용으로 인에이블될 때, 이 이동국은 수신기(2412) 및 송신기(2414) 뿐만 아니라 바람직하게는 매립형 또는 내장형인 하나 이상의 안테나 엘리먼트(2416, 2418)와 같은 관련 구성 엘리먼트, 국부 발진기(LO)(2413), 및 디지털 신호 처리기(DSP)(2420)와 같은 처리 모듈을 포함하는 통신 서브시스템(2411)을 구비한다. 통신 분야에 숙련된 사람이라면 명확히 알 수 있는 바와 같이, 통신 서브시스템(2411)의 특정한 설계는 장치가 동작하려고 의도하는 통신 네트워크에 따라서 달라질 수 있다.

네트워크 접근 필요조건은 또한 네트워크(2419)의 유형에 따라 달라질 것이다. 일부 CDMA 네트워크에서, 네트워크 접근은 가입자 또는 이동국(2400)의 사용자와 관련된다. CDMA 이동국은 CDMA 네트워크에서 동작하기 위해 제거가능 사용자 식별 모듈(RUIM) 또는 가입자 식별 모듈(SIM)카드를 요구할 수 있다. SIM/RUIM 인터페이스(2444)는 SIM/RUIM 카드를 디스켓 또는 PCMCIA 카드처럼 삽입하고 빼낼 수 있는 카드 슬롯과 일반적으로 유사하다. SIM/RUIM 카드는 약 64K의 메모리를 가질 수 있고, 많은 키 구성(2451), 신분 확인과 같은 기타 정보(2453), 및 가입자 관련 정보를 유지할 수 있다.

요구된 네트워크 등록 또는 기동 절차가 완료되었을 때, 이동국(2400)은 네트워크(2419)를 통해 통신 신호를 전송 및 수신할 수 있다. 도 24에 도시된 바와 같이, 네트워크(2419)는 모바일 장치와 통신하는 다수의 기지국으로 구성될 수 있다. 예를 들면, 하이브리드 CDMA 1×EVDO 시스템에서, CDMA 기지국과 EVDO 기지국은 이동국과 통신하고, 이동국은 상기 양측 기지국과 동시에 접속된다. EVDO 및 CDMA 1× 기지국은 상이한 페이징 슬롯을 이용하여 모바일 장치와 통신한다.

통신 네트워크(2419)를 통해 안테나(2416)에서 수신된 신호는 수신기(2412)에 입력되고, 상기 수신기는 신호 증폭, 주파수 다운 변환, 필터링, 채널 선택 등, 및 도 24에 도시된 예시적인 시스템에서는 아날로그-디지털(A/D) 변환과 같은 공통 수신기 기능을 수행할 수 있다. 수신된 신호의 A/D 변환은 DSP(2420)에서 수행되는 복조 및 디코딩과 같은 더 복잡한 통신 기능을 가능하게 한다. 유사한 방법으로, 송신하고자 하는 신호는 DSP(2420)에 의해 예컨대 변조 및 인코딩과 같은 처리를 받아서 디지털-아날로그 변환, 주파수 업 변환, 필터링, 증폭을 위해 송신기(2214)에 입력되고 안테나(2418)를 거쳐 통신 네트워크(2419)를 통해 송신된다. DSP(2420)는 통신 신호를 처리할 뿐만 아니라 수신기 및 송신기 제어를 제공한다. 예를 들면, 수신기(2412) 및 송신기(2414)에서 통신 신호에 적용되는 이득은 DSP(2420)에서 구현되는 자동 이득 제어 알고리즘을 통하여 적응적으로 제어된다.

이동국(2400)은 장치의 전체 동작을 제어하는 마이크로프로세서(2438)를 포함하는 것이 바람직하다. 적어도 데이터 및 음성 통신을 포함하는 통신 기능은 통신 서브시스템(2211)을 통하여 수행된다. 마이크로프로세서(2438)는 또한 디스플레이(2422), 플래시 메모리(2424), 랜덤 액세스 메모리(RAM)(2426), 보조 입/출력(I/O) 서브시스템(2428), 직렬 포트(2430), 2개 이상의 키보드 또는 키패드(2432), 스피커(2434), 마이크로폰(2436)과 같은 다른 장치 서브시스템, 예컨대 단거리 통신 서브시스템과 같은 기타 통신 서브시스템(2440) 및 개괄적으로 도면 부호 2442로 표시한 임의의 기타 장치 서브시스템과 상호작용한다. 직렬 포트(2430)는 USB 포트 또는 당업계에 잘 알려져 있는 기타의 포트를 포함할 수 있다.

도 24에 도시된 서브시스템들 중의 일부는 통신 관련 기능을 수행하고, 기타의 서브시스템은 "상주"(resident) 또는 온디바이스 기능을 제공할 수 있다. 예컨 대 키보드(2432) 및 디스플레이(2422)와 같은 일부 서브시스템은 통신 네트워크를 통해 송신하기 위한 텍스트 메시지를 입력하는 것과 같은 통신 관련 기능 및 계산기 또는 작업 목록과 같은 장치 상주 기능을 위해 사용될 수 있다.

마이크로프로세서(2438)에서 사용되는 운영체제 소프트웨어는 플래시 메모리(2424)와 같은 영구 기억장치에 저장되는 것이 바람직하다. 상기 플래시 메모리는 읽기 전용 메모리(ROM) 또는 유사한 기억장치 엘리먼트(도시 생략됨)를 대신할 수 있다. 당업자라면 운영체제, 특정 장치 애플리케이션 또는 그 일부가 RAM(2426) 등의 휘발성 메모리에 임시로 로드된다는 것을 알 것이다. 수신된 통신 신호도 또한 RAM(2426)에 저장될 수 있다.

도시된 바와 같이, 플래시 메모리(2424)는 컴퓨터 프로그램(2458)과 프로그램 데이터 기억(2450, 2452, 2454, 2456)을 위한 상이한 영역들로 분할될 수 있다. 이러한 상이한 기억 장치 유형은 각 프로그램이 그들 자신의 데이터 기억 필요조건을 위해 플래시 메모리(2424)의 일부를 할당할 수 있다는 것을 나타낸다. 마이크로프로세서(2438)는, 그 운영체제 기능 외에, 이동국에서 소프트웨어 애플리케이션을 실행할 수 있는 것이 바람직하다. 예컨대 적어도 데이터 및 음성 통신 애플리케이션을 포함한 기본 동작을 제어하는 미리 정해진 세트의 애플리케이션은 일반적으로 제조 과정 중에 이동국(2400)에 설치된다. 다른 애플리케이션은 후속적으로 또는 동적으로 설치될 수 있다.

양호한 소프트웨어 애플리케이션은 비제한적인 예로서 이메일, 칼렌더 이벤트, 음성 메일, 약속 및 작업 아이템과 같은 이동국의 사용자에 관한 데이터 아이 템을 조직 및 관리하는 능력을 가진 개인 정보 관리자(PIM) 애플리케이션일 수 있다. 본래, PIM 데이터 아이템의 저장을 용이하게 하기 위해 하나 이상의 메모리 기억부가 이동국에서 이용가능하다. 이러한 PIM 애플리케이션은 무선 네트워크(2419)를 통하여 데이터 아이템을 전송 및 수신하는 능력을 갖는 것이 바람직하다. 양호한 실시예에서, PIM 데이터 아이템은 저장된 또는 호스트 컴퓨터 시스템과 관련된 이동국 사용자의 대응하는 데이터 아이템에 의해 이음매없이 통합되고 동기화되고 업데이트된다. 다른 애플리케이션은 네트워크(2419), 보조 I/O 서브시스템(2428), 직렬 포트(2430), 단거리 통신 서브시스템(2440) 또는 임의의 다른 적당한 서브시스템(2442)을 통해 이동국에 로드될 수 있고, 마이크로프로세서(2438)에서 실행하기 위해 사용자에 의하여 RAM(2426)에 또는 바람직하게는 비휘발성 기억 장치(도시 생략됨)에 설치된다. 이러한 애플리케이션 설치의 유연성은 장치의 기능성을 증가시키고 장치 기능, 통신 관련 기능 또는 이들 양쪽을 개선할 수 있다. 예를 들면 보안성 통신 애플리케이션은 이동국(2400)을 이용하여 수행되는 전자 상거래 기능 및 기타의 재정 거래(financial transaction)를 가능하게 한다.

데이터 통신 모드에서, 텍스트 메시지 또는 웹페이지 다운로드와 같은 수신 신호는 통신 서브시스템(2411)에 의해 처리되고 마이크로프로세서(2438)에 입력되며, 마이크로프로세서(2438)는 바람직하게 수신 신호를 추가로 처리하여 디스플레이(2422) 또는 대안적으로 보조 I/O 장치(2428)에 출력한다. 푸시 클라이언트(140, 510 또는 2212)와 동일한 것일 수 있는 푸시 클라이언트(2460)는 입력을 또한 처리할 수 있다.

이동국(2400)의 사용자는 디스플레이(2422) 및 가능하다면 보조 I/O 장치(2428)와 함께, 예컨대 완전한 알파뉴메릭 키보드 또는 전화기형 키패드인 키보드(2432)를 이용하여 이메일 메시지 등의 데이터 아이템을 또한 구성할 수 있다. 이와 같이 구성된 아이템들은 통신 서브시스템(2411)을 통하여 통신 네트워크를 거쳐 송신될 수 있다.

음성 통신의 경우, 이동국(2400)의 전체 동작은 수신된 신호가 바람직하게 스프커(2434)로 출력되고 송신용 신호가 마이크로폰(2436)에 의해 생성된다는 점을 제외하고 유사하다. 음성 메시지 기록 서브시스템과 같은 다른 음성 또는 오디오 I/O 서브시스템이 또한 이동국(2400)에서 구현될 수 있다. 음성 또는 오디오 신호가 주로 스피커(2434)를 통하여 달성되는 것이 바람직하지만, 예를 들면 호출 상대방의 아이덴티티, 음성 호출의 기간, 또는 다른 음성 호출 관련 정보의 표시를 제공하기 위해 디스플레이(2422)가 사용될 수 있다.

도 24의 직렬 포트(2430)는 사용자 데스크톱 컴퓨터(도시 생략됨)와의 동기화가 요망되는 개인 휴대 정보 단말기(PDA)형 이동국에서 구현될 수 있지만, 이것은 선택적 장치 컴포넌트이다. 이러한 직렬 포트(2430)는 사용자가 외부 장치 또는 소프트웨어 애플리케이션을 통하여 선호도(preference)을 설정할 수 있게 하고, 무선 통신 네트워크를 통하지 않고 이동국(2400)에 대한 정보 또는 소프트웨어 다운로드를 제공함으로써 이동국(2400)의 능력을 확장한다. 다른 다운로드 경로는 예를 들면 안전한 장치 통신을 위하여 직접 및 그에 따라서 신뢰성있고 신용있는 접속을 통하여 장치에 암호화 키를 로드하기 위해 사용될 수 있다. 당업자라면 잘 알 수 있는 바와 같이, 직렬 포트(2430)는 또한 모바일 장치를 모뎀으로서 작용하도록 컴퓨터에 접속하기 위해 사용될 수 있다.

단거리 통신 서브시스템과 같은 다른 통신 서브시스템(2440)은 이동국(2400) 및 이것과 반드시 동일한 장치일 필요는 없는 다른 시스템 또는 장치 사이의 통신을 제공할 수 있는 추가의 선택적 엘리먼트이다. 예를 들면, 서브시스템(2440)은 유사하게 인에이블된 시스템 및 장치와의 통신을 제공하기 위해 적외선 장치 및 관련 회로와 컴포넌트들 또는 블루투스™ 통신 모듈을 포함할 수 있다.

여기에서 설명한 실시예들은 이 출원의 기술의 엘리먼트들에 대응하는 엘리먼트들을 가진 구조, 시스템 또는 방법의 예들이다. 이 명세서에서의 설명은 당업자가 이 출원의 기술의 엘리먼트들에 대응하는 다른 엘리먼트들을 가진 실시예를 구성하고 사용할 수 있게 할 것이다. 따라서, 이 출원의 기술의 의도된 범위는 여기에서 설명한 본 출원의 기술로부터 차이가 없는 다른 구조, 시스템 또는 방법을 포함하고, 또한 여기에서 설명한 본 출원의 기술로부터 본질적이지 않은 차이를 가진 다른 구조, 시스템 또는 방법을 포함하는 것으로 한다.

도 1은 동적 콘텐츠 전달 시스템의 기본 아키텍쳐를 나타낸 블록도.

도 2는 도 1의 동적 콘텐츠 전달 시스템의 다른 아키텍쳐를 나타낸 블록도.

도 3은 도 1의 블록도를 콘텐츠 및 메타데이터 흐름과 함께 나타낸 도면.

도 4는 본 발명의 시스템 및 방법과 관련하여 사용될 수 있는 푸시 프럭시를 나타낸 블록도.

도 5는 본 발명의 시스템 및 방법과 관련하여 사용될 수 있는 푸시 클라이언트를 나타낸 블록도.

도 6은 콘텐츠 및 메타데이터의 다층 엔벨로프 모델을 나타낸 블록도.

도 7은 도 6의 블록도를 각 엔벨로프의 동적 메타데이터 처리 단계와 함께 나타낸 도면.

도 8은 도 6의 블록도를 정적 및 동적 메타데이터를 이용한 처리와 함께 보여주는 도면.

도 9는 단일 공유 푸시 클라이언트에 대한 애플리케이션의 등록 처리를 보여주는 블록도.

도 10은 푸시 클라이언트의 풀(pool)을 관리하는 푸시 콘테이너에 대한 애플리케이션의 등록 처리를 보여주는 블록도.

도 11은 콘텐츠 프로세서 및 소켓 리스너에 대한 애플리케이션 등록을 보여주는 블록도.

도 12는 단일 공유 푸시 프럭시로 콘텐츠 제공자 등록 과정을 보여주는 블록 도.

도 13은 푸시 프럭시의 풀(pool)을 관리하는 푸시 콘테이너로 콘텐츠 제공자 등록 과정을 보여주는 블록도.

도 14는 콘텐츠 제공자와 클라이언트 애플리케이션 간의 등록 메시지를 보여주는 블록도.

도 15는 푸시 클라이언트와 푸시 프럭시 간의 등록 중의 상호 작용을 보여주는 블록도.

도 16은 푸시 프럭시와 콘텐츠 제공자 간의 등록 중의 상호 작용을 보여주는 블록도.

도 17은 콘텐츠 제공자와 처리 엘리먼트간의 콘텐츠 및 메타데이터의 흐름을 보여주는 흐름도.

도 18은 콘텐츠의 예시적인 변환 애플리케이션을 보여주는 블록도.

도 19는 콘텐츠 합성 모델의 블록도.

도 20은 선형 프래그먼트화 처리의 블록도.

도 21은 비선형 프래그먼트화 처리의 블록도.

도 22는 조정된 플러그-인 등록 모델의 블록도.

도 23은 도 22의 모델에서 동작하는 애플리케이션 메디에이터의 블록도.

도 24는 본 발명의 방법 및 시스템과 관련하여 사용될 수 있는 예시적인 모바일 장치의 블록도.

Claims

푸시 콘텐츠 전달 시스템에서 범용 엘리먼트(generic element) - 이 범용 엘리먼트는, 콘텐츠 제공 시스템과 사용자 장치(UE) 상의 클라이언트 애플리케이션 중 하나임 - 를 콘텐츠 전달 아키텍쳐에 접속시키는 방법에 있어서,

메디에이터(mediator)를 상기 범용 엘리먼트와 연관시키기 위해 상기 범용 엘리먼트가 상기 콘텐츠 전달 아키텍쳐의 클라이언트 또는 서버를 이용하는 단계로서, 상기 메디에이터는 상기 범용 엘리먼트 및 상기 콘텐츠 전달 아키텍쳐와 통신하도록 구성되는 것인, 상기 이용 단계와;

상기 메디에이터가 상기 범용 엘리먼트를 상기 콘텐츠 전달 아키텍쳐에 등록하는 단계

를 포함하는 콘텐츠 전달 아키텍쳐에의 접속 방법.
삭제
제1항에 있어서, 상기 이용 단계는 외부 저장소로부터 서비스 제공 시스템을 프로비져닝(provision)하는 단계를 포함하는 것인 콘텐츠 전달 아키텍쳐에의 접속 방법.
제1항에 있어서, 상기 이용 단계는,

범용 메디에이터를 서비스 제공 시스템에 위치시키는 단계와;

상기 콘텐츠 제공 시스템에 대한 메타데이터를 상기 메디에이터로부터 수신하는 단계를 포함하는 것인 콘텐츠 전달 아키텍쳐에의 접속 방법.
제4항에 있어서, 상기 수신하는 단계는 중앙 저장소 또는 콘텐츠 제공 시스템 전용 저장소로부터 메타데이터를 얻는 단계를 포함하는 것인 콘텐츠 전달 아키텍쳐에의 접속 방법.
삭제
제1항에 있어서, 상기 이용 단계는 외부 저장소로부터 상기 UE를 프로비져닝하는 단계를 포함하는 것인 콘텐츠 전달 아키텍쳐에의 접속 방법.
제3항에 있어서, 상기 외부 저장소는 범용 저장소 또는 콘텐츠 제공 시스템 전용 저장소인 것인 콘텐츠 전달 아키텍쳐에의 접속 방법.
제7항에 있어서, 상기 메디에이터는 상기 콘텐츠 전달 아키텍쳐에 고유(specific)한 것인 콘텐츠 전달 아키텍쳐에의 접속 방법.
제1항에 있어서, 상기 이용 단계는,

범용 메디에이터를 모바일 장치에 위치시키는 단계와;

상기 메디에이터를 이용하여 상기 콘텐츠 제공 시스템에 대한 메타데이터를 수신하는 단계를 포함하는 것인 콘텐츠 전달 아키텍쳐에의 접속 방법.
제1항에 있어서, 상기 이용 단계는 중앙 저장소 또는 애플리케이션 전용 저장소로부터 메타데이터를 얻는 단계를 포함하는 것인 콘텐츠 전달 아키텍쳐에의 접속 방법.
제1항, 제4항, 제5항, 제7항, 및 제9항 내지 제11항 중 어느 한 항에 있어서, 상기 등록하는 단계는 메타데이터를 이용하는 것인 콘텐츠 전달 아키텍쳐에의 접속 방법.
제1항, 제4항, 제5항, 제7항, 및 제9항 내지 제11항 중 어느 한 항에 있어서, 상기 이용 단계는 사용자 장치에 의해 구동되는 것인 콘텐츠 전달 아키텍쳐에의 접속 방법.
제1항, 제4항, 제5항, 제7항, 및 제9항 내지 제11항 중 어느 한 항에 있어서, 상기 이용 단계는 자동형인 것인 콘텐츠 전달 아키텍쳐에의 접속 방법.
제1항, 제4항, 제5항, 제7항, 및 제9항 내지 제11항 중 어느 한 항에 있어서, 상기 이용 단계 전에, 콘텐츠 전달 인식 환경을 제공하도록 애플리케이션을 로딩하는 단계를 더 포함하는 콘텐츠 전달 아키텍쳐에의 접속 방법.
삭제
제1항에 있어서, 상기 등록하는 단계는,

상기 콘텐츠 제공 시스템을 상기 클라이언트 애플리케이션에 명시적으로(explicitly) 결합 - 이 명시적 결합은, 상기 콘텐츠 제공 시스템이 상기 클라이언트 애플리케이션에 콘텐츠를 제공할 수 있거나 상기 클라이언트 애플리케이션이 상기 콘텐츠 제공 시스템으로부터 데이터를 수신할 수 있는 것으로 지정(specify)함으로써 이루어지는 것임 - 하는 단계를 포함하는 것인 콘텐츠 전달 아키텍쳐에의 접속 방법.
제1항에 있어서, 상기 등록하는 단계는,

상기 콘텐츠 제공 시스템을 상기 클라이언트 애플리케이션에 암시적으로(implicitly) 결합 - 이 암시적 결합은, 상기 콘텐츠 제공 시스템에 의해 제공되고 상기 클라이언트 애플리케이션에 의해 취급되는 데이터의 유형을 지정함으로써 이루어지는 것임- 하는 단계를 포함하는 것인 콘텐츠 전달 아키텍쳐에의 접속 방법.
제18항에 있어서, 상기 암시적으로 결합하는 단계는 상기 클라이언트 애플리케이션이 제공한 콘텐츠 유형 토큰과 상기 콘텐츠 제공 시스템이 제공한 콘텐츠 유형 토큰을 비교하는 단계를 포함하는 것인 콘텐츠 전달 아키텍쳐에의 접속 방법.
제19항에 있어서, 상기 비교하는 단계는 상기 클라이언트 애플리케이션이 제공한 콘텐츠 유형 토큰과 상기 콘텐츠 제공 시스템이 제공한 콘텐츠 유형 토큰 간에 중첩하는 세그멘트의 수를 카운트하는 단계를 포함하는 것인 콘텐츠 전달 아키텍쳐에의 접속 방법.
제20항에 있어서, 상기 등록하는 단계는 상기 비교로부터의 상기 카운트를 이용하여 애플리케이션을 콘텐츠 제공 시스템과 결합할 것인지 여부를 결정하는 단계를 포함하는 것인 콘텐츠 전달 아키텍쳐에의 접속 방법.
제1항, 제4항, 제5항, 제7항, 및 제9항 내지 제11항 중 어느 한 항에 있어서, 상기 등록하는 단계 전에,

상기 메디에이터가 상기 범용 엘리먼트에 대한 전달 취급 정보를 추가하는 단계와;

상기 메디에이터가 정보를 미리 정해진 포맷으로 변환하는 단계를 더 포함하는 콘텐츠 전달 아키텍쳐에의 접속 방법.
푸시 콘텐츠 전달 시스템에서 범용 엘리먼트 - 이 범용 엘리먼트는, 콘텐츠 제공 시스템과 사용자 장치(UE) 상의 클라이언트 애플리케이션 중 하나임 - 를 콘텐츠 전달 아키텍쳐에 접속시키는 메디에이터에 있어서,

메타데이터를 추출하는 추출 수단과;

상기 콘텐츠 전달 아키텍쳐에 상기 범용 엘리먼트에 대한 등록 정보를 제공하는 등록 수단을 포함하는 메디에이터.
삭제
제23항에 있어서, 상기 메디에이터는 외부 저장소로부터 서비스 제공 시스템 상으로 프로비져닝되는 것인 메디에이터.
삭제
제23항에 있어서, 상기 메디에이터는 외부 저장소로부터 모바일 장치 상에 프로비져닝되는 것인 메디에이터.
제23항에 있어서, 상기 콘텐츠 제공 시스템에 대한 메타데이터를 획득하도록 구성된 통신 수단을 더 포함하는 메디에이터.
제23항 또는 제27항에 있어서, 상기 등록 수단은 메타데이터를 이용하도록 구성된 것인 메디에이터.
삭제
제23항에 있어서, 상기 등록 수단은,

상기 콘텐츠 제공 시스템을 상기 클라이언트 애플리케이션에 명시적으로(explicitly) 결합 - 이 명시적 결합은, 상기 콘텐츠 제공 시스템이 상기 클라이언트 애플리케이션에 콘텐츠를 제공할 수 있거나 상기 클라이언트 애플리케이션이 상기 콘텐츠 제공 시스템으로부터 데이터를 수신할 수 있는 것으로 지정함으로써 이루어지는 것임 - 하도록 구성된 것인 메디에이터.
제23항에 있어서, 상기 등록하는 수단은,

상기 콘텐츠 제공 시스템을 상기 클라이언트 애플리케이션에 암시적으로(implicitly) 결합 - 이 암시적 결합은, 상기 콘텐츠 제공 시스템에 의해 제공되고 상기 클라이언트 애플리케이션에 의해 취급되는 데이터의 유형을 지정함으로써 이루어지는 것임 - 하도록 구성된 것인 메디에이터.
제32항에 있어서, 상기 암시적인 결합은, 상기 클라이언트 애플리케이션이 제공한 콘텐츠 유형 토큰의 스키마(schema)를 상기 콘텐츠 제공 시스템이 제공한 콘텐츠 유형 토큰의 스키마와 비교하는 것을 포함하는 것인 메디에이터.
제33항에 있어서, 상기 등록 수단은 또한 상기 클라이언트 애플리케이션이 제공한 콘텐츠 유형 토큰과 상기 콘텐츠 제공 시스템이 제공한 콘텐츠 유형 토큰 간에 중첩하는 스키마의 수를 카운트하도록 구성된 것인 메디에이터.
제34항에 있어서, 상기 등록 수단은 또한 상기 카운트를 이용하여, 애플리케이션을 콘텐츠 제공 시스템과 결합할 것인지 여부를 결정하도록 구성된 것인 메디에이터.
제23항 또는 제27항에 있어서, 상기 범용 엘리먼트에 대한 전달 취급 정보를 추가하도록 구성된 처리 수단과;

정보를 미리 정해진 포맷으로 변환하도록 구성된 변환 수단을 더 포함하는 메디에이터.