KR101187133B1

KR101187133B1 - 리치 미디어 서비스 내의 개별 콘텐츠의 점진적 전달과 동기화를 위한 방법 및 시스템

Info

Publication number: KR101187133B1
Application number: KR1020107022715A
Authority: KR
Inventors: 가엘 크리스틴 마틴-코처; 수레쉬 치투리
Original assignee: 리서치 인 모션 리미티드
Priority date: 2008-04-10
Filing date: 2009-04-08
Publication date: 2012-09-28
Also published as: EP2109283A1; CA2719539A1; CN101999136A; US8208006B2; US20090258594A1; EP2109283B1; KR20100123905A; WO2009126676A3; CN101999136B; US20120263398A1; WO2009126676A2; US8576275B2; CA2719539C

Abstract

네트워크 요소로부터 리치 미디어를 저작 및 전송하고 모바일 장치에서 수신하기 위한 방법이 개시된다. 이 방법은 리치 미디어가 개별 콘텐츠를 포함하는지의 여부를 검사하는 단계; 포함한다면, 리치 미디어의 개별 콘텐츠의 저해상도 버전을 전송하는 단계; 및 리치 미디어의 더 높은 해상도 버전을 후속해서 전송하는 단계를 포함한다. 수신하는 단계는 리치 미디어의 개별 콘텐츠의 저해상도 버전을 수신하고; 개별 콘텐츠의 더 높은 해상도 조각을 수신하며; 개별 콘텐츠의 저해상도 버전에 더 고해상도 조각을 점증적으로 적용하는 것을 포함한다.

Description

리치 미디어 서비스 내의 개별 콘텐츠의 점진적 전달과 동기화를 위한 방법 및 시스템{METHOD AND SYSTEM FOR PROGRESSIVE DELIVERY AND SYNCHRONIZATION OF DISCRETE CONTENT IN RICH MEDIA SERVICES}

본 출원은 리치 미디어 콘텐츠(rich media content)의 전달에 관한 것으로, 더 구체적으로 리치 미디어 서비스에서 개별 콘텐츠의 전달에 관한 것이다.

리치 미디어 콘텐츠란 일반적으로, 그래픽적으로 풍부하고 단일 인터페이스를 통해 전달되는 그래픽, 래스터 이미지, 텍스트, 비디오 및 오디오를 포함한 복수의 미디어를 포함하는 콘텐츠를 말한다. 리치 미디어 콘텐츠는 인터넷상에서 점점 인기가 많아져 가고 있고 최근에는 무선 공간에서도 마찬가지이다.

오늘날 리치 미디어 서비스에서 래스터 이미지와 같은 개별 콘텐츠의 전달은 점진적 성향으로 이루어지지 않는다. 이로 인해 사용자 경험이 나빠진다.

본 발명은 리치 미디어 콘텐츠를 전송하기 위한 방법을 제공한다. 이 방법은, 리치 미디어가 개별 콘텐츠를 포함하는지의 여부를 검사하고; 포함한다면, 리치 미디어의 개별 콘텐츠의 저해상도 버전을 전송하며; 후속하여 개별 콘텐츠의 고해상도 조각을 업데이트로서 전송하는 것을 포함한다.

본 발명은 또한, 리치 미디어를 전송하기 위한 네트워크 요소를 제공한다. 이 네트워크 요소는, 리치 미디어를 수신하도록 구성된 통신 서브시스템; 리치 미디어가 개별 콘텐츠를 포함하는지의 여부를 검사하고, 포함한다면, 리치 미디어의 개별 콘텐츠의 저해상도 버전을 통신 서브시스템을 통하여 전송하며; 후속하여 개별 콘텐츠의 더 높은 해상도 조각을 통신 서브시스템을 통하여 전송하도록 구성된 프로세서를 포함한다.

본 발명은 또한, 리치 미디어를 수신하기 위한 방법을 제공한다. 이 방법은, 리치 미디어의 개별 콘텐츠의 저해상도 버전을 수신하고; 개별 콘텐츠의 고해상도 조각을 수신하며; 개별 콘텐츠의 저해상도 버전에 더 높은 해상도 조각을 점증적으로 적용시키는 것을 포함한다.

본 발명은 또한, 리치 미디어를 수신하기 위한 모바일 디바이스를 제공한다. 이 디바이스는, 리치 미디어 내의 저해상도 개별 콘텐츠와 고해상도 개별 콘텐츠를 수신하도록 구성된 통신 서브시스템과; 리치 미디어를 렌더링하고 개별 콘텐츠의 더 높은 해상도 조각으로 개별 콘텐츠의 저해상도 버전을 증분시키도록 구성된 프로세서를 포함한다.

네트워크 요소로부터 리치 미디어를 저작 및 전송하고 모바일 장치에서 수신하기 위한 방법이 개시된다.

본 발명은 도면을 참조하면 더 잘 이해될 것이다.
도 1은 리미 미디어 출력의 예시적 스크린 표현이다.
도 2는 도 1로부터의 리치 미디어의 업데이트를 도시하는 예시적 스크린 표현이다.
도 3은 래스터 이미지에 대한 렌더링 시간을 나타내는 타임라인이다.
도 4는 래스터 이미지에 대한 렌더링 시간을 나타내는 타임라인이다.
도 5는 래스터 이미지의 점진적 해상도의 수신과 렌더링을 보여주는 타임라인이다.
도 6은 점진적 해상도를 갖는 리치 미디어를 전송하기 위한 네트워크측 프로세스를 도시하는 흐름도이다.
도 7은 점진적 해상도 업데이트를 수신하기 위한 모바일 디바이스측 프로세스를 보여주는 흐름도이다.
도 8은 저해상도 이미지에 대한 신뢰성 추가를 포함한 네트워크 요소로부터 점진적 해상도를 전송하기 위한 대안적 프로세스를 보여주는 흐름도이다.
도 9는 고해상도 차단을 포함한 네트워크 요소로부터 점진적 해상도를 전송하기 위한 대안적 프로세스를 보여주는 흐름도이다.
도 10은 간략화된 네트워크 요소를 보여주는 예시적 네트워크도이다.
도 11은 예시적 모바일 디바이스를 보여주는 블럭도이다.

무선 공간에서 리치 미디어 콘텐츠 요청에 응답하여, 이와 같은 콘텐츠를 렌더링하는 모바일 (무선) 디바이스의 능력을 증가시키는 것과 결합하여, 리치 미디어 콘텐츠 기술에 관한 수개의 표준이 개발되었다. 이들은 하기의 표준들을 포함한다.

3GPP DIMS

제3세대 파트너쉽 프로젝트(3GPP)에는 동적이고 대화성의 미디어 장면(DIMS; Dynamic and Interactive Media Scene)이 명시되어 있다. 이것은, 미디어 타입, 그 패키징, 전달, 및 로컬 단말기, 사용자, 및 기타의 로컬 및 원격 서브시스템들과의 상호작용을 포함한 동적 리치 미디어 시스템을 정의한다. 엔드-유저 상호작용과 결합하여 미디어 및 이벤트의 동기화와 조율된 관리에 의해 향상된 사용자 경험이 제공된다. DIMS 미디어 타입은 포괄적 미디어 타입으로 사용될 수 있어서, 동적, 대화성, 리치 미디어 서비스의 생성을 허용하며, 무엇보다도, 오디오 코덱, 비디오 코덱, 확장된 하이퍼텍스트 마크업 랭귀지와 같은 다른 미디어 타입으로부터 혜택을 받거나, 이들과 연계하여 사용될 수 있다.

리치 미디어 시스템은 3개의 주요 컴포넌트들을 포함하는, 클라이언트-서버 아키텍쳐로서 인식될 수 있다. 이들은 리치 미디어 서버, 트랜스포트 메커니즘, 및 리치 미디어 클라이언트이다. 서버는, 장면 설명, 이미지와 같은 개별 데이터 및, 오디오 및 비디오 미디어와 같은 연속 데이터를 포함하는 리치 미디어 콘텐츠를 입력으로서 취한다. 장면 설명은 장면 업데이트를 통해 동적으로 업데이트될 수 있다. 리치 미디어 콘텐츠는, 미디어 동기화, 메타데이터 및 패킷화에 대한 힌트 트랙과 같은 추가 정보를 포함하는 컨테이너 포멧으로 캡슐화될 수 있다. 시스템은 그 다음, 다운로드, 점진적 다운로드, 및 스트리밍 시나리오에 대한 1 대 1, 1 대 다 프로토콜을 위한 다양한 트랜스포트 메커니즘을 이용한다. 1 대 1 메커니즘의 예는, 하이퍼텍스트 트랜스포트 프로토콜(HTTP), 및 패킷 교환형 스트리밍 서비스(PSS; Packet Switched Streaming Service)를 포함한다. 1 대 1 프로토콜은, 예를 들어, 멀티미디어 브로드캐스트 멀티캐스트 서비스(MBMS)를 포함한다.

DMA RME

개방형 모바일 얼라이언스(OMA; Open Mobile Alliance) 리치 미디어 환경(RME; Rich Media Environment) 규격은, RME 콘텐츠가 모바일 장치 상에 배포되거나 디스플레이될 수 있도록 하는 프레임워크를 정의한다. RME 콘텐츠는, 비디오, 이미지, 애니메이션 및 텍스트와 같은 시각 객체, 및 사용자에게 더 풍성한 경험을 제공하기 위해 함께 구성되는 오디오 객체의 장면들로 구성된다. 이 시스템은 변화하는 부분만을 대체하는 새로운 정보로 장면을 지속적으로 업데이트하는 수단을 포함한다. 따라서, 장면의 한 부분을 유지하면서 장면의 다른 부분들을 업데이트하는 것이 가능하므로, 통신 대역폭과 장치 처리 능력 모두를 절감할 수 있다. 그러나, 원한다면 현재의 장면을 새로운 장면으로 대체하는 것도 가능하다. RME를 위한 전형적인 응용은 모바일 텔레비젼 클라이언트, 동적 애플리케이션 사용자 인터페이스, 멀티플레이어 게이밍, 온-디바이스 포탈(on-device portal)이다.

RME 시스템은 RME 클라이언트 및 RME 서버로 구성된다. RME 클라이언트는 전형적으로 RME 단말기 상에 주재하며, 로컬 및 원격 장면 객체와의 상호작용 뿐만 아니라, RME 데이터를 디스플레이하고 RME 장면에 대한 동적 업데이트를 처리하는 능력을 제공한다. 전형적으로, 서버는 데이터의 소스이며, RME 데이터를 클라이언트에 제공한다.

OMA BCAST

개방형 모바일 얼라이언스 모바일 브로드캐스트 서비스(B-CAST) 규격은, 모바일 브로드캐스트 서비스 인에이블러(B-CAST 1.0)를 포함하는 다른 규격과 함께, 기술적 프레임워크를 정의하고, 상이한 브로드캐스트 배포 시스템을 통해 모바일 브로드캐스트 서비스의 생성, 관리, 및 배포를 위한 전역적으로 상호교환가능한 기술을 명시한다. 이들은 제3세대 파트너쉽 프로젝트 MBMS, 제3세대 파트너쉽 프로젝트 2(3GPP2) 브로드캐스트 및 멀티캐스트 서비스(MCMCS) 및 인터넷 프로토콜(IP) 데이터캐스트 오버 디지털 비디오 브로드캐스트-핸드핼드(DVB-H)를 포함한다.

OMA B-CAST는 하기의 기능들을 위한 규격을 포함한다: 서비스 안내; 서비스 및 콘텐츠 보호; 파일 및 스트림 배포; 터미널 공급; 서비스 공급; 통보; 및 서비스 상호작용. 나아가, 모든 B-CAST 1.0 기술에 대한 공통 분모는, 이들은 인터넷 프로토콜(IP) 및 IP 관련 기술에 기초한다는 것이다.

W3C SVG Tiny 1.2

월드 와이드 웹 컨소시엄(W3C) 스케일러블 벡터 그래픽(SVG)은, 2차원 벡터 그래픽을 나타내기 위한 XML(eXtensible Markup Language; 확장된 마크업 랭귀지) 기반의 랭귀지이다. 확장성(scalability)에 추가하여, SVG는 또한, 상호작용성과, 애니메이션과, 래스터 이미지, 오디오 및 비디오 콘텐츠와 같은 미디어를 임베딩하는 능력을 제공한다.

SVG Tiny 1.2 규격은 3GPP DIMS 및 OMA RME 규격 모두에서 리치 미디오 콘텐츠를 배포하기 위한 베이스 콘텐츠 포멧이도록 선택될 수 있다. DIME와 RME간의 핵심적 차이는, DIMS는 주로 리치 미디어 콘텐츠의 트랜스포트와 전달에 중점을 두고 있는 반면, RME 규격은 단말기 및 사용자 인터페이스 상의 다른 모듈들과 리치 미디어의 통합 및 애플리케이션 레벨에서의 이벤트 처리와 같은 애플리케이션 층 문제를 다룬다는 점이다.

MPEG LASeR

동영상 전문가 그룹(MPEG; Moving Picture Experts Group) LASeR(Lightweight Application Scene Representation) 규격은 SVGT1.2 규격에 기초하여 LASeR 명령들을 정의한다.

LASeR 명령들은 DIMS 및 RME의 동적 업데이트 기능들 중 핵심이다. LASeR 명령과 유사한 기술은, 서버-전송된 DOM 이벤트와 같은 문서 객체 모델(DOM; Document Object Model) 이벤트를 이용하는 W3C에도 존재한다.

본 시스템의 방법에 대해 이용될 수 있는 추가적인 리치 미디어 포멧은 Adobe Flash™ 및 Microsoft Silverlight™를 포함한다.

전술된 내용으로부터, 리치 미디어 콘텐츠는 일반적으로, 초기 장면 설명 포멧과, 그 다음 후속하는, 시간에 경과에 따라 초기 장면에 가해지는 업데이트 시퀀스로 구성된다. 그 결과 콘텐츠에 동적 변경이 가해진다. 장면 설명은 또한 그래픽, 텍스트, 래스터 이미지, 비디오 및 오디오 콘텐츠를 포함한 상이한 미디어 타입을 포함할 수 있다. 래스터 이미지는 대개 장면 설명 내에, 예를 들어, base64 인코딩 스킴을 이용하여 SVG 콘텐츠 내에 임베딩되거나, 장치 내에 국부적으로 존재하거나 네트워크에 위치하는 파일에 대한 URL 스킴을 이용하여 참조된다.

래스터 이미지 또는 다른 개별 콘텐츠 또는 미디어는 RME 및 DIMS 하에서 점진적 성향으로 로딩되지 않기 때문에, 이로 인해, 사용자 경험이 좋지 않다. 래스터 이미지에서, 예를 들어, 전체 이미지는 렌더링 이전에 로딩될 필요가 있고, 이것은 이미지 렌더링을 지연시켜, 장면의 완전한 로딩의 지연 또는 동기화 소실로 이어진다.

래스터 이미지는, 이하의 설명에서 점진적 방식의 개별 콘텐츠의 로딩 예로서 이용된다. 그러나, 이것은 제한을 의미하는 것은 아니며, 점진적으로 로딩될 수 있는 다른 개별 콘텐츠가 당업자에게는 명백할 것이다.

이제 도 1 및 도 2를 참조하면, 초기 SVG 리치 미디어 콘텐츠 및 후속하는 동적 업데이트가 도시되어 있다. 도 1 및 도 2 내에서 변하지 않는 요소들에 대해서는 유사한 참조 번호가 사용된다.

시간 T초에서 초기 장면 설명은 다음과 같이 XML로 정의될 수 있다.

<?xml version="1.0"?>

<circle id="myCircle" cx="20" cy="20" r="10" fill="red"> <text id="myText" x="40" y="40">Hello rich media!</text>

</svg>

상기의 XML은 도 1처럼 디코딩되고 디스플레이될 것이다. 특히, 장면(100)은 전술된 XML과 대응한다.

상기의 XML을 라인별로 분석 해 보면, 첫 라인은 XML의 버전을 정의한다.

둘째 라인은 폭, 높이, 명칭 공간, 베이스 프로파일 및 버전을 포함한, SVG에 대한 파라미터들을 설정한다.

"<circle id...."으로 시작하는 네째 라인은 스크린(100) 상에 렌더링되는 형상(110)을 도시한다. XML에서 표시된 바와 같이, 원은, 20, 20의 x, y 좌표와, 반경 10, 및 빨간색의 채움 색상(fill color)을 가진다.

<text id...."으로 시작하는 다음 라인은 텍스트(120)를 정의한다. 이 경우, 텍스트는 "Hello rich media!"이고, x,y 쫘표 40, 40에 위치해 있다.

XML의 다음 라인은 "<image id...."으로 시작하고 이미지(130)에 대응한다. 이 경우, XML은 위치 10, 30, 폭 50, 높이 50, 및 이미지 소스로의 링크를 가진다. XML에서, 이미지 소스는 "Image1.png"로서 정의된다.

XML의 다음 라인은 "<video..."를 포함하고, "myvideo.mp4"로서 정의된 비디오로의 링크를 가진다. 이 비디오는 스크린(100) 상에서 140으로 도시되어 있으며 x,y 위치 50, 5, 폭 60, 높이 50을 가지며, 0초에서 시작한다.

따라서, 전술된 내용은 T초에서 정의되는 다양한 양태를 갖는 리치 미디어 콘텐츠를 도시한다.

도 2를 참조하면, 도 2는 시간 T+20초에서 업데이트되는 스크린(200)을 도시한다. 업데이트를 위한 XML 코드는 다음과 같이 정의된다:

<lsr:Replace ref="myImage" attributeName="xlink:href" value="image2.png"/>

<lsr:Replace ref="myCircle" attributeName="fill" value="blue"/>

<lsr:Replace ref="myText" attributeName="textContent" value="<- The image is updated!/>

상기 XML에서 정의된 바와 같이, 스크린(200)은 다양한 요소들을 대체시킨다. 첫 라인은 이미지(230)이 값 "Image2.png"로 대체된다는 것을 가리킨다.

XML의 둘째 라인은 텍스트 속성이 새로운 값으로 변경된다는 것을 가리키고, 이 경우, 텍스트(220)는 이제 "<- The image is updated!"로 읽힌다.

이해할 수 있는 바와 같이, 비디오(140)는 상기에서 변경되지 않았고 따라서 동일하게 유지되며 계속 플레이된다. 상기에서의 문제는 래스터 이미지들, 특히 이미지(130 및 230)는 점진적 방식으로 전달되지 않아서 잠재적으로 좋지 않은 사용자 경험을 초래한다는 것이다. 예를 들어, 리치 미디어 콘텐츠와 연관된 이미지는, 표시된 시간 T 및 T+20초에서 사용자에게 디스플레이되지 않을 수 있는데, 이것은 이미지들이 그들 전체 해상도로 다운로드되지 않고 디코딩 및 렌더링에 필요한 시간이 콘텐츠 저자에 의해 표시된 디스플레이 시간을 초과할 수 있기 때문이다. 이것은, 이하의 도 3 및 도 4에 예시된 바와 같이, 리치 미디어 콘텐츠 내의 다른 요소들과 래스터 이미지와의 동기화에 영향을 준다.

도 3을 참조하면, 도 3은 상기 도 1 및 도 2의 이미지(130 및 230)의 수신을 도시한다. 도 3에서, 타임라인(300)은 0초로서 도시된 시간 T에서 시작한다. 이 시점에서 전체 해상도의 래스터 이미지 1을 갖는 초기 장면(310)이 수신된다.

시간 20초에서, 박스(230)으로 도시된 바와 같이, 전체 해상도의 래스터 이미지 2로 장면이 업데이트된다.

도 4를 참조하면, 실제 렌더링 시간은, 전체 해상도/품질 래스터 이미지를 디코딩하고 디스플레이하는데 필요한 시간 때문에, 수신 시간과는 상이하다. 그 결과, 이것은 스크린 상에서 콘텐츠가 나타나는데 있어서 지연을 유발하여, 좋지 않은 사용자 경험을 초래한다.

구체적으로, 타임라인(400)은 도 3의 타임라인(300)에 대응한다. 박스(410)는 전체 해상도의 이미지 1의 실제 렌더링 시간을 예시한다. 박스(420)는 전체 해상도의 래스터 이미지 2의 렌더링 시간을 예시한다. 도시된 바와 같이, 박스(310)에 대한 수신 시간과 도 3 및 4로부터의 렌더링 시간 사이에는 5초의 차이가 있다. 이해하겠지만, 이것은 단지 예일 뿐이며, 렌더링 시간은, 무엇보다도, 이미지 크기, 모바일 디바이스, 에어 접속에 의존할 것이다.

박스(320)에서의 수신 시간과 렌더링 시간(420)간의 렌더링에서의 차이가 5초로서 도시되어 있다. 그러나, 이것은 다시 한번, 무엇보다도, 이미지 2, 모바일 디바이스, 네트워크 접속에 의존하며, 이미지 1의 수신과 이미지 1의 렌더링간의 차이는 이미지 2의 수신과 이미지 2의 렌더링간의 차이와는 상이할 수 있다.

상기 내용은 동기화 문제로 인해 좋지 못한 사용자 경험을 초래할 수 있다. 예를 들어, 리치 미디어에 대한 한 응용은 교육분야이다. 구체적으로, 강의가 비디오테잎화되고 강사가 참조하는 이미지는 비디오에 대응하여 디스플레이될 수 있다. 만일 강사가 이미지를 참조하고 있고, 강사가 그 이미지를 참조한 후 소정 기간 동안 사용자의 장치 상에 그 이미지가 디스플레이되지 않는다면, 좋지 않은 사용자 경험을 초래할 것이다.

래스터 이미지와의 동기화 문제를 해결하기 위해, 본 발명의 시스템 및 방법은, 점점 증가하는 품질로 개별 콘텐츠 부분 및 집합을 전송함으로써 래스터 이미지 및 다른 개별 콘텐츠를 점진적 방식으로 전달한다. 즉, 처음에 제1 저품질 이미지가 전송되고, 시간의 경과에 따라 이미지 품질을 개선시키는 추가적인 데이터 비트가 후속된다. 이러한 접근법은 리치 미디어 장면에서 래스터 이미지들의 점진적 전달을 가능케함으로써, 부드러운 엔드-유저 경험을 허용한다.

이제 도 5를 참조한다.

도 5는 래스터 이미지 1 및 2의 점진적 전달 및 동기화를 보여주는 타임라인(500)을 예시한다. 특히, 시간 0에서 초기 장면(510)은 초기 저해상도의 래스터 이미지 1을 포함한다. 이 이미지는 저해상도이기 때문에 렌더링하는데 매우 적은 시간이 소요되며 나머지 리치 미디어 콘텐츠와 동기화되어 렌더링된다.

시간 5초에서, 래스터 이미지 1은 추가 비트들을 수신하고 박스(512)는 이제 중간 해상도를 갖는 래스터 이미지 1을 도시한다.

시간 10초에서, 래스터 이미지 1은 모든 비트드들 수신하고 박스(514)로 표시한 바와 같이 전체 해상도로 디스플레이된다.

시간 20초 경에, 장면 업데이트가 발생하고 래스터 이미지 2는 박스(520)로 도시한 바와 같이 초기 저해상도로 렌더링된다.

그 다음, 이미지 2는 추가 비트들을 수신하고 시간 25초 경에, 래스터 이미지 2는 박스(522)로 도시한 바와 같이 중간 해상도이다.

시간 30초 경에, 장면 업데이트는 박스(524)로 도시된 바와 같이 전체 해상도의 래스터 이미지 2를 포함한다.

당업자라면 이해하는 바와 같이, 도 5의 도면은 단지 예를 의미하는 것이며, 특정 시간에서 해상도 개선을 위한 개별 박스들을 도시하고 있다. 그러나, 해상도에서의 증가는 지속적일 수 있으며, 저해상도에서 전체 해상도로의 천이 시간은 변동할 수 있다.

전술된 내용은 다양한 방식으로 구현될 수 있다. 제1 실시예는 대역내(in-band) 해결책을 포함한다. 특히, 래스터 이미지들 또는 개별 콘텐츠는 장면 콘텐츠 내에 라인별로 임베딩시킴으로써, RTP 또는 다른 프로토콜을 통한 스트리밍 동안에 대역내 전달될 수 있다. 이것은, 예를 들어, 이하의 XML에 예시된 바와 같이 base64 인코딩을 이용하여 이미지의 2진 표현을 임베딩함으로써 이루어진다.

<image width="135" height="262"

xlink:href="data:;base64,/9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8SEhEP......"/>

상기 기술은 다음과 같이 점진적 전달 동기화에서 이용될 수 있다. 시간 T에서 저해상도 버전의 이미지는 다음과 같이 장면내에 대역내 임베딩된다.

<?xml version="1.0"?>

<! - other scene elements can go here - >

data:;base64,/9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAUDB AQEAwUEBAQFBQUGBwwIBwcHBw[delta]LCwkMEQ[delta]SEhEP "/>

</svg>

상기에서 알 수 있는 바와 같이, 이미지가 정의되고, 그 위치 및 크기가 정의된 다음, base64 인코딩은 이미지를 대역내 제공한다.

시간 T+5초에서, 이하의 XML을 이용하여 이미지의 중간 해상도 조각이 전송된다:

<lsr:Add ref="mylmage" attributeName="xlink:href" value="data:;base64,RgABAQEASABI "/>

따라서 이미지의 해상도를 증가시키기 위해 이 시점에서 데이터 집합(chunk)이 추가된다.

저해상도 이미지 내에 데이터 집합을 가져오기 위한 다양한 방법들이 당업자에게 공지되어 있다. 예를 들어, 이미지의 저해상도 버전을 갖는 이전 코드는 이미지의 중간 해상도 조각에 대응하는 코드의 집합에 의해 향상될 수 있다. 이런식으로, 각각의 데이터 집합이 이전 이미지에 적용될 때, 그 결과의 이미지는 더 높은 해상도의 이미지가 된다.

T+10초에서 이미지의 전체 해상도 조각이 전송된다. 여기서 또 다른 Add 명령이 사용되어 장면을 나머지 점진적 데이터 집합으로 업데이트하여 이미지의 해상도 및 품질을 그 전체 해상도 및 품질로 향상시킨다. 이 XML은 하기와 같다:

<lsr:Add ref="mylmage" attributeName="xlink:href value="data:;base64, cHBw8LCwkMEQ8SEhEP "/>

추가의 실시예에서, 리치 미디어 장면에서 렌더링될 것이 요구되는 개별 콘텐츠는 점대점 전달을 위한 HTTP 프로토콜 또는 브로드캐스트 전달을 위한 FLUTE(File Delivery Over Unidirectional Transport)와 같은 또다른 프로토콜을 이용함으로써 대역밖에서 전달될 수 있다. 당업자라면 이해하겠지만, 리치 미디어 콘텍스트에서는 본질적으로 2가지 모드의 전달이 있다. 즉 유니캐스트와 브로드캐스트이다. 유니캐스트란 HTTP 및 PSS와 같은 점대점 접속을 말한다. 브로드캐스트란 MBMS 및 DVB-H와 같은 1-대-다 시나리오이다.

따라서, 대역외 해결책은 시간 T초에서 이미지의 초기의 낮은 해상도 버전을 포함한다. 이를 위한 XML의 예는 하기와 같다:

<?xml version="1.0"?>

<! - other scene elements can go here - >

</svg>

위에서 표시한 바와 같이, 이미지 하이퍼텍스트 참조 "image1_low.png"는 시간 T초에서 로딩된다.

만일 FLUTE가 전달을 위해 사용된다면, 참조된 하이퍼텍스트 이미지는 FLUTE 프로토콜에 의해 정의된 바와 같이 FDT(File Delivery Table)로부터 가져와져야 한다.

5초에서의 장면 업데이트 1에서, 이미지의 중간 해상도 조각은 대역외로 제공된다. 이를 위한 XLM은 다음과 같다:

<lsr:Add ref="mylmage" attributeName="xlink:href value="lmage1_medium.png>

상기에서 알 수 있는 바와 같이, 이미지는 이미지의 중간 해상도 조각을 참조하는, "Image1_medium.png"로서 정의된다.

마지막 시간 T+10초에서, 이미지의 전체 해상도가 로딩된다. 이를 위한 XML의 예는 하기와 같다:

<lsr:Add ref="mylmage" attributeName="xlink:href value="lmage1_full.png>

href값은 "Image1_full.png"로서, 이미지의 대역외 전체 해상도 조각이 로딩된다는 것을 나타낸다.

점진적 개별 콘텐츠의 시그널링은 헤더를 통해 이루어질 수 있다.

한 실시예에서, RTP 데이터 유닛이 초기 저해상도 이미지를 포함한다는 것을 표시하기 위해 1비트 필드가 RTP 데이터 헤더에 할당될 수 있다. 예를 들어, 현재의 3GPP DIMS 규격에서, RTP 데이터 유닛 헤더는 아래와 같이 기술된다. 제로 비트는 예약된다. 이 미사용 비트는, 임베딩된 래스터 이미지들의 점진적 전달의 이용과 동기화를 나타내기 위해 사용될 수 있다.

0	1	2	3	4	5	6	7
X		C	P	D	I	M	S

만일 X가 1로 세트되면, 이것은 현재의 패킷이 점진적 방식으로 전달될 래스터 이미지 콘텐츠를 포함한다는 것을 나타낸다. 만일 X가 0으로 세트되면, 이것은 어떠한 점진적 가능형 래스터 이미지도 존재하지 않는다는 것을 나타낸다.

만일 X가 1로 세트되면, 스트림에서 다가오는 패킷들은 현재 패킷에서 전달되는 래스터 이미지를 향상시키기 위한 데이터 집합을 운반할 수 있다는 것을 구현자는 알 필요가 있다.

추가 실시예는, 이미지의 점진적 렌더링에 대한 참고용으로 본 명세서에서 인용하는 미국특허 제20070294333호에 정의된 바와 같이 슬립스트림 기술을 이용할 수 있다. 이 문서는 이미지만에 대하여 단독 메커니즘으로 멀티미디어 객체의 점진적 전달을 보여준다.

슬립스트림 기술은 대역외 모드에서만 본 발명에 적용가능할 것이다. 여기서, 이미지 참조는 장면 내에 및 장면 업데이트에 포함되고, 참조되는 이미지들(또는 데이터 집합)은, 슬립스트림 특허에 의해 기술된 바와 같이, 별도의 대역외 채널로부터 가져와진다. 이해하겠지만, 미국특허 제20070294333호는 장면에 대하여 리치 미디어 콘텐츠 및 동기화를 제공하지 않는다.

리치 미디어에서 전술된 점진적 전달은 도 6을 참조하여 추가로 예시된다. 도 6은 개별 미디어를 전달하기 위한 네트워크 관점으로부터의 흐름도이다.

도 6을 참조하면, 프로세스는 단계(610)에서 시작하여 단계(612)로 진행하고, 여기서 리치 미디어 콘텐츠가 전달될 필요가 있는지의 여부가 검사된다. 필요가 없다면, 프로세스는 단계(620)로 진행하고 종료한다.

역으로, 단계(612)로부터 리치 미디어가 전달될 필요가 있다면, 프로세스는 단계(630)로 진행하고, 여기서, 리치 미디어가 개별 콘텐츠를 포함하는지의 여부를 알기 위해 검사가 이루어진다. 당업자라면 이해하겠지만, 개별 콘텐츠는 전술된 바와 같이 래스터 이미지와 같은 항목을 포함한다.

만일, 단계(630)에서, 리치 미디어 콘텐츠에 개별 콘텐츠가 없다면, 프로세스는 단계(620)로 진행하고 종료한다. 그렇지 않다면, 프로세스는 단계(632)로 진행한다.

단계(632)에서, 네트워크는 개별 콘텐츠를 복수의 해상도 조각들로 쪼갠다. 이해하겠지만, 단계(632)는 선택사항이고 개별 콘텐츠는 네트워크 요소에 의해 수신되기 이전에 복수의 해상도로 이미 쪼개될 것이다. 이 경우, 프로세스는 단계(634)로 직접 진행할 것이다.

만일 단계(632)가 필요하다면, 네트워크 요소 상의 프로세서는 콘텐츠를 쪼갤 최적의 해상도를 결정할 수 있다. 이 결정은, 무엇보다도, 미디어가 전송되고 있는 장치, 네트워크 접속에 기초하여 이루어질 수 있다.

추가적으로, 개별 콘텐츠의 전체 크기는 쪼개질 필요가 없을 정도로 충분히 작을 수 있다. X보다 작은 크기의 콘텐츠는 쪼개지지 않고 그대로 전송될 것을 가리키는 정책이 구현될 수 있다. 여기서, X는, 예를 들어 모바일 장치, 네트워크 오퍼레이터, 콘텐츠 제공자, 서비스 제공자, 또는 장면이나 장면 업데이트 가중치에 의해 결정된다.

전술된 예는 3개의 해상도 조각을 예시하였다. 즉, 낮은 해상도, 중간 해상도, 높은 해상도. 그러나, 본 발명은 3가지 해상도 조각으로 제한되는 것은 아니다. 어떤 경우, 2개의 해상도 조각, 즉 저해상도 및 전체 해상도이면 충분하다. 다른 솔루션에서는 더 많은 해상도가 요구될 수 있다. 단계(632)에서의 쪼개는 단계는 콘텐츠를 4개, 다섯개, 또는 그 이상의 해상도 조각들로 쪼갤 수 있다.

단계(632)로부터, 프로세스는 단계(634)로 진행하고, 여기서 저해상도 콘텐츠는 모바일 장치에 전송된다. 이해하겠지만, 단계(632)의 전송 단계는 일부 실시예에서는 유니캐스트이고, 다른 실시예에서는 브로드캐스트일 수 있다. 유니캐스트 또는 브로드캐스트에 대한 다양한 표준이 당업자에게 알려져 있다.

또한, 용어 "저해상도 콘텐츠"는 쪼개기 단계(632)가 콘텐츠를 쪼개는 이미지의 가장 낮은 해상도이다. 대안으로서, "저해상도 콘텐츠"는, 만일 개별 콘텐츠가 다양한 해상도 조각들로 이미 쪼개졌다면 네트워크 요소에 의해 수신된 개별 콘텐츠의 가장 낮은 해상도 버전이다.

그 다음, 프로세스는 단계(640)로 진행하고, 여기서, 더 높은 해상도 조각들이 이용가능한지의 여부를 알기 위해 검사가 이루어진다. 이용가능하다면, 프로세스는 단계(642)로 진행하고, 여기서, 프로세스는 미리결정된 시간량 동안 기다린다. 어떤 경우, 특정한 시간 인터벌 이후에 더 높은 해상도 조각을 전송하는 것이 바람직할 것이다. 다른 경우, 더 높은 해상도 조각은 즉시 전송될 수 있다. 따라서, 단계(642)에서의 시간은 네트워크 오퍼레이터 및 모바일 장치 요건에 기초하여 변동할 수 있다.

그 다음 프로세스는 단계(644)로 진행하고, 여기서, 다음의 더 높은 해상도 조각이 모바일 장치에 전송된다.

단계(644)로부터 프로세스는 다시 단계(640)로 진행하고, 여기서, 더 높은 해상도 조각들이 이용가능한지의 여부를 알기 위해 검사가 이루어진다. 만일 이용가능하다면, 프로세스는 단계(642) 및 단계(644)를 다시 진행한다. 그렇지 않다면, 프로세스는 단계(620)로 가서 종료한다.

전술된 내용에 대한 다양한 대안들이 구현될 수 있다. 예를 들어, 만일 가장 높은 해상도가 전송되기 이전에 업데이트가 수신되는 상황에서 경쟁 조건(race condition)이 회피될 것이라면, 업데이트가 대기중인지의 여부를 결정하기 위해 단계(640)와 단계(642) 사이에 검사가 삽입될 수 있다. 이 경우, 프로세스는 단계(630)로부터 시작하여 업데이트가 전달될 수 있도록, 단계(620)로 직접 진행하여 종료한다.

특히, 업데이트가 도달할 때, 프로세스는 전술된 바와 동일하게 진행할 수 있다. 단계(612)에서 전달될 리치 미디어 콘텐츠가 있는지의 여부에 관한 결정이 이루어질 수 있다. 그러나, 이것이 업데이트인 경우 YES를 따라 프로세스는 단계(630)로 간다. 여기서, 업데이트가 개별 콘텐츠를 포함하는지의 여부를 알기 위해 검사가 이루어진다. 만일 포함한다면, 프로세스는 단계(632)로 진행하고 필요하다면 개별 콘텐츠를 복수의 해상도 쪼개고, 프로세스는 단계(634)로 진행하고 가장 낮은 해상도의 콘텐츠 업데이트가 전송된다. 그 다음, 프로세스는 전술된 바와 같이 단계(640, 642, 및 644)로 진행한다.

무선 장치의 관점으로부터, 도 7을 참조하여 예시적 프로세스가 기술된다.

프로세스는 단계(710)에서 시작하고, 단계(712)에서, 리치 미디어의 수신 여부를 알기 위해 검사가 이루어진다. 만일 수신된 리치 미디어가 없다면, 프로세스는 단계(720)에서 종료한다. 역으로, 리치 미디어가 수신되었다면, 프로세스는 단계(730)로 진행하고 리치 미디어를 렌더링 및 디스플레이한다.

단계(730)로부터, 프로세스는 단계(740)으로 진행하고, 여기서 미디어 업데이트의 수신 여부를 알기 위해 검사가 이루어진다. 이해하겠지만, 업데이트는 브로드캐스트/푸시에 의해 수신되거나, 및/또는, 클라이언트 단말기에 의해 명시적으로 요청될 수 있다. 업데이트가 수신되면, 프로세스는 단계(750)로 진행하고 업데이트를 렌더링한다. 그렇지 않다면, 프로세스는 단계(740)으로 되돌아가고 미디어 업데이트의 수신 여부를 지속적으로 검사한다.

당업자라면 이해하겠지만, 단계(740)에서 수신된 업데이트는 래스터 이미지와 같은 개별 미디어의 더 높은 해상도 조각일 수 있다. 또한 전술된 바와 같이 장면 업데이트일 수도 있다.

추가 실시예에서, 전술된 내용은 이미지의 저해상도 버전에 신뢰성을 추가함으로써 수정될 수 있다. 특히, 스트리밍 동안에 데이터의 신뢰성을 개선시키고 재전송을 피하기 위해, 패킷들을 RAP(Random Access Point)로서 마킹함으로써 중요한 리치 미디어 콘텐츠의 부분들이 전달된다. RAP으로서 마킹된 패킷들은, 신뢰할수 없는 트랜스포트 채널에서 콘텐츠의 신뢰성을 높히기 위해, 전형적으로 높은 포워드 에러 정정(FEC; Forward Error Correction)으로 인코딩된다.

이와 같은 경우 신뢰성을 높히기 위해 이미지의 초기 저품질 버전은 EAP로 전달될 수 있다. 나머지 더 높은 품질의 집합들은 비-RAP 패킷으로서 전달될 수 있는데, 이것은 이들이 대단히 결정적으로 중요한 것이 아니라 단지 콘텐츠 호소력을 향상시키기 위해 사용되기 때문이다.

이제 도 8을 참조한다. 도 8은 추가된 단계(833)를 제외하고 도 6과 동일하다. 특히, 프로세스는 810에서 시작하고, 단계(812)에서 전달될 리치 미디어 콘텐츠가 있는지의 여부를 검사한다. 만일 없다면, 프로세스는 단계(820)에서 종료한다.

만일 전달될 리치 미디어 콘텐츠가 있다면, 프로세스는 단계(812)로부터 단계(830)로 진행하여, 리치 미디어 콘텐츠가 개별 콘텐츠를 포함하지의 여부를 검사한다.

단계(830)로부터, 개별 콘텐츠가 없다면, 프로세스는 단계(820)로 진행하여 종료한다. 그렇지 않다면, 프로세스는 단계(832)로 진행하고, 여기서, 프로세스는, 선택사항으로서, 개별 미디어를 복수의 해상도로 쪼갠다.

추가된 단계(833)는 개별 콘텐츠의 저해상도 버전을 RAP으로 마킹하고, 신뢰할 수 없는 트랜스포트 채널에서 콘텐츠의 신뢰성을 높히기 위해 패킷들은 높은 FEC로 인코딩된다.

그 다음, 프로세스는 단계(834)로 진행하고, 여기서, 개별 콘텐츠의 저해상도 버전이 전송된다.

단계(840)에서 더 높은 해상도가 이용가능한지의 여부를 결정하기 위해 검사가 이루어진다. 만일 이용가능하다면, 프로세스는 단계(842)로 진행하여, 더 높은 해상도 콘텐츠가 전송되는 단계(844)로 진행하기 이전에 미리결정된 시간 동안 기다린다. 이해하겠지만, 단계(844)의 더 높은 해상도 콘텐츠는 RAP으로서 마킹되지 않는다.

모바일 장치 관점으로부터, 도 7은, 단계(712) 및 단계(730)에서 패킷들이 신뢰성있게 수신되는 것을 보장하기 위해 FEC가 이용된다는 점을 제외하고는 여전히 적용가능하다.

추가의 실시예에서, 전송을 개별 콘텐츠의 저품질 서브셋으로 제한하고 개별 콘텐츠의 더 높은 해상도 조각들은 전송하지 않는 것이 바람직할 수 있다. 특히, 사용자가 로밍하고 있을 때, 데이터 전송은 종종 더욱 비싸다. 사용자는 전체 요금을 지불하지 않고 리치 미디어 콘텐츠를 참고하기를 원할 수 있다. 특히, 몇몇 래스터 이미지들은 중요하고 텍스트 메시지에 대한 단순한 개선을 위한 것이 아니다. 이 경우 초기 저해상도 버전은 전송될 수 있으나, 개선을 요청하는 것과 같은 특정한 사용자 액션이 제공되지 않는 한, 래스터 이미지들의 후속 조각들은 제공되지 않을 수 있다.

마찬가지로, 장치 자원이, 배터리 로우, 메모리 가득참과 같은 소정의 한계에 도달할 때, 래스터 이미지들의 후속 집합들의 전달이 유보될 수 있다.

일부 실시예들에서, 특정한 메시지에 의해 사용자에게 신호가 전송되거나, 사용자 선호사항의 일부로서 이와 같은 정책을 정의하고 선택하는 것이 사용자에게 달려있을 수도 있다.

추가의 실시예들에서, 소정 이미지들이 저품질로서 전송되어야 하는지의 여부를 결정하는 측이 서비스 제공자이거나 콘텐츠 제공자일 수 있다. 예를 들어, 특정한 이미지들은 렌더링을 위해 2개 해상도를 수신할 가치가 있는 반면, 다른 것들은 특정한 조건에서 가장 낮은 해상도만을 필요로 할 수 있다.

마찬가지로, 일부 래스터 이미지들은 특정한 콘텐츠 제공자 정책으로 인해 전체 이미지가 로딩될 것을 요구할 수 있다. 예를 들어, 로고 또는 광고 콘텐츠는 전체 해상도로 전송되는 것이 요구될 수 있다.

이제 도 9를 참조한다. 도 9는 전술된 내용이 구현되는 네트워크측 관점으로부터의 흐름도이다. 도 9는 단계(941)이 추가되었다는 점을 제외하고는 도 6과 동일하다. 특히, 프로세스는 910에서 시작하고 단계(912)로 진행하여, 여기서, 리치 미디어 콘텐츠가 전달될 필요가 있는지의 여부를 알기 위해 검사가 이루어진다. 필요가 없다면, 프로세스는 단계(920)에서 종료한다.

그렇지 않다면, 프로세스는 단계(930)로 진행하여, 리치 미디어가 래스터 이미지와 같은 개별 콘텐츠를 포함하는지의 여부를 알기 위해 검사가 이루어진다. 포함하지 않는다면, 프로세스는 단계(920)로 진행하고 종료한다. 그렇지 않다면, 프로세스는 단계(932)로 진행하고, 선택사항으로서 개별 콘텐츠를 복수의 해상도로 쪼갠다.

단계(934)에서 저해상도 콘텐츠가 모바일 장치로 전송되고, 그다음, 프로세스는 단계(940)로 진행한다.

단계(940)에서, 더 높은 해상도의 콘텐츠가 이용가능한지의 여부를 알기 위해 검사가 이루어진다. 이용가능하다면, 프로세스는 단계(941)로 진행하고, 블럭이 고해상도 이미지 상에 놓여야 하는지의 여부를 결정하기 위해 검사가 이루어진다. 전술한 바와 같이, 이것은, 사용자 선호사항, 장치 한계, 네트워크 또는 캐리어 선호사항에 기초할 수 있다. 또한, 이것은 사용자에 대한 촉구에 기초할 수 있으며, 사용자의 로밍 여부와 같은 다양한 네트워크 조건을 포함한다.

단계(941)에서 이미지의 고해상도 조각들 상에 블럭이 놓여야 한다고 결정된다면, 프로세스는 단계(942)로 진행하고, 잠재적으로, 단계(944)에서 다음 더 높은 해상도의 콘텐츠를 전송하기 이전 미리결정된 시간동안 기다린다.

단계(944)로부터 프로세스는 단계(940)로 다시 진행하고, 더 높은 해상도 조각들이 이용가능하지 않거나 다음 더높은 해상도 조각들이 차단되어야 할 때까지 계속 루핑한다.

추가의 실시예에서, 래스터 이미지 또는 개별 미디어의 추가 집합들의 점진적 전송은 시간 개념에 기초할 수 있다. 특히, 몇몇 이미지들은 사용자가 상호작용할 스크린 상의 몇몇 메뉴에서 나타날 수 있다. 상호작용시, 사용자는 이전 스크린으로 되돌아올 가능성없이 또다른 메뉴나 스크린을 볼 것이다. 따라서, 시간에 기초하여 이미지들의 연속된 집합을 전달하는 것이 이로울 것이다. 따라서, 만일 사용자가 소정 시간보다 많은 시간 동안 스크린에 머물러 있다면, 후속 집합이 전달된다. 그렇지 않다면, 첫번째 집합만이 전달된다.

만일 사용자가 상호작용하고 있지 않다면, 서버는, 사용자 장치가 로밍중인지의 여부, 자원 한계, 사용자로부터 입력 없음, 푸시 명령, 장치가 백그라운드 모드인지 등과 같은 다른 사용자 조건에 기초하여 집합을 발생 및 전달할 수 있다.

이들 인자들 중 하나 이상이 단계(914)에서 고려되어야 한다.

또한, 이미지 조각들은 장면 및 장면 업데이트 가중치에 기초하여 생성될 수 있다. 특히, 이미지의 초기 저해상도 버전은 양호한 동기화를 보장하기 위해 장면의 가중치보다 낮거나 같을 수 있다. 후속 세그먼트는 장면 가중치 또는 업데이트 가중치에 기초하여 이루어질 수 있다.

나아가, 다음 프레그먼트는 사용자의 더 나은 품질 요청에 후속하는 업데이트로서 전달될 수 있다. 이 업데이트는 이 프레그먼트만을 포함할 수 있다.

이해하겠지만, 전술된 내용은, LASeR, DIMS, 또는 RME 및 HTML이나 그 등가물과 같은 임의 종류의 콘텐츠에서 제공된 비동기화된 래스터 이미지들과 같은 리치 미디어 콘텐츠에 대한 래스터 이미지의 동기화에 적용된다.

추가 실시예에서, 제안된 방법은 HTML 5 서버-전송된 DOM 이벤트를 이용하여 구현될 수 있다. 당업자라면 이해하겠지만, 서버 전송된 DOM 이벤트 규격은 서버가 클라이언트 문서에 DOM 이벤트를 전송하는 것을 허용하기 위한 기술을 설명하고 있다.

이미지 품질을 향상시키는 이미지 데이터 집합을 운반하는 전술된 업데이트 명령은, 무엇보다도, DOMNodeInserted, DOMNodeRemoved, DOMAttrModified와 같은 W3V DOM 변종 이벤트에 맵핑될 수 있다. 즉, 리치 미디어 시스템은 명령과는 반대로 리치 미디어 장면을 업데이트하기 위해 원격 DOM 이벤트를 디스패치함으로써 구현될 수 있다.

이해하겠지만, DOM 이벤트를 이용한 전술된 구현은 DOM 이벤트를 이용하여 구현될 수 있는 단계(634) 및 단계(644)를 갖는 도 6 에 해당될 것이다. 마찬가지로, 장치측에서, 도 7을 참조하면, 단계(712) 및 단계(740)는 리치 미디어 장면 및 업데이트를 렌더링할 때 DOM 이벤트를 인식할 수 있다.

당업자라면 이해하겠지만, 전술된 프로세스들은 임의의 네트워크 요소에 의해 구현될 수 있다. 네트워크에 대한 간략화된 아키텍쳐가 도 10을 참조하여 기술된다.

도 10에서, 콘텐츠 제공자(1010)는 모바일 장치 사용자가 디스플레이하기를 원하는 리치 미디어 콘텐츠를 제공한다. 리치 미디어 콘텐츠는 네트워크(1020)를 통해 네트워크 요소(1040)에 전송된다.

도 10에 예시된 바와 같이, 간략화된 네트워크 요소(1040)는, 네트워크(1020)와 통신하도록 구성되고 이하에서 기술하는 바와 같이 모바일 네트워크(1050)와 통신하도록 구성된 적어도 통신 서브시스템(1042)을 포함한다.

통신 서브시스템(1042)에서 수신된 정보는 데이터 상에 전술된 처리를 수행하도록 구성된 프로세서(1044)에 포워딩된다. 예를 들어, 만일 데이터가 다양한 해상도로 쪼개질 필요가 있는 개별 콘텐츠를 갖는 리치 미디어 콘텐츠라면, 이것은 프로세서(1044)에서 이루어질 것이다.

프로세서(1044)는 또한, RAP 패킷으로서 저해상도 패킷을 지정하고, 점진적 업데이트가 수신될 예정인지의 여부를 나타내도록 RTP 헤더를 변경하도록 구성된다.

메모리(1046)는 다양한 요소들을 저장하고 프로세서(1044)와 통신하도록 구성된다. 메모리(1046)는 예를 들어, 프로세서(1044)에 의해 생성된 해상도 이미지들을 저장할 수 있다.

모바일 네트워크(1050)는, GSM(Global System for Mobile communication), GPRS(General Packet Radio Service), CDMA(Code Division Multiple Access), UMTS(Universal Mobile Telecommunication System), WCDMA(Wideband Code Divisional Multiple Access)등을 포함하지만 이들만으로 제한되는 것은 아니다. 이들 기술들은 동시에 음성 및 데이터의 사용을 허용한다.

이해하겠지만, 전술된 내용은 임의의 모바일 장치 상에서 구현될 수 있다. 한 예시적 모바일 장치가 도 11을 참조하여 기술된다. 이것은 제한적 의미가 아니라, 예시적 목적을 위해 제공되는 것이다.

도 11은 본 발명의 방법 및 장치의 양호한 실시예에서 사용되기에 적합한 모바일 장치를 예시하는 블럭도이다. 모바일 장치(1100)는 양호하게는 적어도 음성 통신 기능을 갖는 양방향 무선 통신 장치이다. 제공되는 정확한 기능에 따라, 무선 장치는 데이터 메시지 장치, 양방향 페이저, 무선 전자메일 장치, 데이터 메시징 기능을 갖는 셀룰러 전화, 무선 인터넷 도구, 또는 데이터 통신 장치라 불린다.

무선 통신 장치(1100)가 양방향 통신에 대해 인에이블된 경우, 무선 통신 장치(1100)는, 하나 이상의 양호하게는 임베딩되거나 내부의 안테나 요소(1116 및 1118), 국부 발진기(1113, LO), 및 DSP(1120)와 같은 처리 모듈등의 연관된 컴포넌트외에도, 수신기(1112) 및 송신기(1114) 모두를 포함하는 통신 서브시스템(1111)을 포함할 것이다. 당업자에게는 명백하겠지만, 통신 서브시스템(1111)의 특정한 설계는 장치가 동작하도록 의도된 통신 네트워크에 의존할 것이다.

네트워크 액세스 요건은 또한 네트워크(1119)의 타입에 따라 달라질 것이다. 일부 CDMA 네트워크에서, 네트워크 액세스는 모바일 장치(1100)의 사용자 또는 가입자와 연관된다. CDMA 모바일 장치는 CDMA 네트워크에서 동작하기 위해 SIM(Subscriber Identity Card) 카드 또는 RUIM(Removable User Identity Module)을 요구할 수 있다. SIM/RUIM 인터페이스(1144)는, SIM/RUIM 카드가 디스켓이나 PCMCIA 카드처럼 삽입되고 사출되는 카드-슬롯과 유사하다. SIM/RUIM 카드는 대략 64K 메모리를 가질수 있으며, 많은 키 구성(1151)과, 식별자 및 가입자 관련 정보와 같은 기타의 정보(1153)을 보유한다.

필요한 네트워크 등록 또는 활성화 프로시져가 완료되면, 모바일 장치(1100)는 네트워크(1119)를 통해 통신 신호를 송수신할 수 있다. 도 11에 예시된 바와 같이, 네트워크(1119)는 모바일 장치와 통신하는 복수의 기지국으로 구성될 수 있다. 예를 들어, 하이브리드 CDMA 1x EVDO 시스템에서, CDMA 기지국과 EVDO 기지국은 모바일 장치와 통신하며, 모바일 장치는 양자 모두에 동시에 접속된다. EVDO 및 CDMA 1x 기지국들은 모바일 장치와 통신하기 위해 상이한 페이징 슬롯들을 이용한다.

통신 네트워크(1119)를 통해 안테나(1116)에 의해 수신되는 신호들은, 신호 증폭, 주파수 다운 변환, 필터링, 채널 선택, 및 도 11에 도시된 예시적 시스템에서는 아날로그 대 디지털(A/D) 변환 등과 같은 일반적인 수신기 기능을 수행하는 수신기(1112)에 입력된다. 수신된 신호의 A/D 변환은 DSP(120)에서 수행되는 복조 및 디코딩과 같은 더 복잡한 통신 기능을 허용한다. 유사한 방식으로, 예를 들어 DSP(1120)에 의한 변조 및 인코딩, 디지털 대 아날로그 변환을 위한 전송기(1114)로의 입력, 주파수 업 변환, 필터링, 증폭 및 안테나(1118)를 이용하여 통신 네트워크(1110)를 통한 전송을 포함하여, 전송된 신호들이 처리된다. DSP(1120)는 통신 신호를 처리할 뿐만 아니라, 수신기 및 전송기 제어를 제공한다. 예를 들어, 수신기(1112) 및 전송기(1114)에서 통신 신호에 가해지는 이득은 DSP(1120)에 구현된 자동 이득 제어 알고리즘을 통해 적응적으로 제어될 수 있다.

모바일 장치(1100)는 양호하게는 장치의 전반적 동작을 제어하는 마이크로프로세서(1138)를 포함한다. 적어도 데이터 및 음성 통신을 포함한 통신 기능은 통신 서브시스템(1111)을 통해 수행된다. 마이크로프로세서(1138)는 또한, 디스플레이(1122), 플래시 메모리(1124), RAM(1126), 보조 입/출력 서브시스템(1128), 직렬 포트(1130), 하나 이상의 키보드 또는 키패드(1132), 스피커(1134), 마이크로폰(1136), 단거리 통신 서브시스템 및 1142로 표시된 기타 임의의 장치 서브시스템과 같은 기타의 통신 서브시스템(1140)과 같은, 추가의 장치 서브시스템들과 상호작용한다. 직렬 포트(1130)는 USB 포트 또는 강업계에 공지된 기타의 포트를 포함할 수 있다.

도 11에 도시된 서브시스템들 중 일부는 통신-관련 기능을 수행하는 반면, 기타의 서브시스템들은 "상주" 또는 온-디바이스 기능을 제공할 수 있다. 주목할 점은, 키보드(1132) 및 디스플레이(1122)와 같은 일부 시스템들은, 예를 들어, 통신 네트워크를 통한 전송용의 텍스트 메시지의 입력과 같은 통신-관련 기능, 및 계산기 또는 작업 리스트와 같은 장치-상주형 기능, 양자 모두를 위해 사용될 수 있다.

마이크로프로세서(1138)에 의해 사용되는 운영 체제 소프트웨어는 양호하게는 플래시 메모리(1124), 또는 대신에 ROM이나 유사한 저장 요소(미도시)와 같은 영구 저장장치에 저장된다. 당업자라면, 운영 체제, 주문형 장치 애플리케이션, 또는 그 일부가 RAM(1126)과 같은 휘발성 메모리에 임시로 로딩될 수 있다는 것을 이해할 것이다. 수신된 통신 신호는 또한 RAM(1126)에 저장될 수 있다.

도시된 바와 같이, 플래시 메모리(1124)는 컴퓨터 프로그램(1158) 및 프로그램 데이터 스토리지(1150, 1152, 1154 및 1156) 양자 모두에 대해 상이한 영역들로 분리될 수 있다. 이들 상이한 스토리지 타입은 각각의 프로그램이 그들 자신의 데이터 스토리지 요건을 위해 플래시 메모리(1124)의 일부를 할당할 수 있다는 것을 가리킨다. 마이크로프로세서(1138)는, 그 운영 체제 기능에 추가하여, 양호하게는 모바일 장치 상에서의 소프트웨어 애플리케이션의 실행을 인에이블한다. 예를 들어 적어도 데이터 및 음성 통신 애플리케이션을 포함한, 기본적인 동작을 제어하는 미리결정된 애플리케이션 세트는 통상 제조 동안에 모바일 장치(100) 상에 설치될 것이다. 다른 애플리케이션들은 후속하여 또는 동적으로 설치될 수 있다.

양호한 소프트웨어 애플리케이션으로는, 전자메일, 캘린더 이벤트, 음성 메일, 약속, 타스크 항목등을 포함하지만, 이것으로만 제한되지 않는, 모바일 장치 사용자에 관련된 데이터 항목들을 조직하고 관리하는 능력을 갖는 개인 정보 관리자(PIM) 애플리케이션이 해당된다. 자연적으로, PIM 데이터 항목들의 저장을 용이하게 하기 위해 하나 이상의 메모리 스토어가 이용가능할 것이다. 이와 같은 PIM 애플리케이션은 양호하게는 무선 네트워크(1119)를 통해 데이터 항목들을 송수신하는 능력을 가진다. 양호한 실시예에서, PIM 데이터 항목들은, 호스트 컴퓨터 시스템에 저장되거나 연관된 모바일 장치 사용자의 대응하는 데이터 항목들과, 무선 네트워크(1119)를 통해, 심리스 통합되고, 동기화되고, 업데이트된다. 추가의 애플리케이션들은 네트워크(1119), 보조 I/O 서브시스템(1128), 직렬 포트(1130), 단거리 통신 서브시스템(1140) 또는 기타 임의의 적절한 서브시스템(1142)을 통해 모바일 장치(1100) 상에 로딩되고, 사용자에 의해 RAM(1126)에 설치되거나 또는 마이크로프로세서(1138)에 의한 실행을 위해 비휘발성 저장소(미도시)에 저장된다. 애플리케이션 설치에서의 이와 같은 융통성은 장치의 기능을 증가시키고, 향상된 온-디바이스 기능, 통신 관련 기능, 또는 양자 모두를 제공할 수 있다. 예를 들어, 보안 통신 애플리케이션들은, 전자 상거래 기능 및 기타의 이와 같은 금융 거래가 모바일 장치(1100)를 이용하여 수행될 수 있도록 한다.

데이터 통신 모드에서, 텍스트 메시지 또는 다운로드된 웹 페이지와 같은 수신된 신호는 통신 서브시스템(1111)에 의해 처리되어 마이크로프로세서(1138)에 입력된다. 마이크로프로세서(1138)는 양호하게는, 디스플레이(1122) 또는 대안으로서 보조 I/O 장치(1128)로의 출력을 위한 요소 속성들에 대하여 수신된 신호를 추가로 처리한다.

모바일 장치(1100)의 사용자는 또한, 디스플레이(1122) 및 아마도 보조 I/O 장치(1128)과 연계하여, 예를 들어, 양호하게는 완전한 영숫자 키보드 또는 전화-타입 키패드일 수 있는 키보드(1132)를 이용하여 전자메일 메시지와 같은 데이터 항목을 작성할 수 있다. 그 다음, 이와 같이 작성된 항목들은 통신 서브시스템(1111)을 통해 통신 네트워크를 거쳐 전송될 수 있다.

음성 통신의 경우, 모바일 장치(1100)의 전체 동작은, 수신된 신호들이 양호하게는 스피커(1134)에 출력되고 전송용 신호들은 마이크로폰(1136)에 의해 발생된다는 점을 제외하고는 유사하다. 음성 메시지 기록 서브시스템과 같은 대안적인 음성 또는 오디오 I/O 서브시스템들도 또한 모바일 장치(1100) 상에 구현될 수 있다. 비록 음성 또는 오디오 신호 출력이 양호하게는 주로 스피커(1134)를 통해 달성되지만, 디스플레이(1122)도 또한, 발신측의 신원 식별, 음성 통화 기간, 또는 기타의 음성 통화 관련 정보를 제공하기 위해 사용될 수 있다.

도 11의 직렬 포트(1130)는 통상, 사용자 데스크탑 컴퓨터(미도시)와 동기화되는 것이 바람직한 PDA-타입의 모바일 장치에서 구현되지만, 선택사항적 장치 컴포넌트이다. 이와 같은 포트(1130)는 사용자가 외부 장치 또는 소프트웨어 애플리케이션을 통해 선호사항을 설정할 수 있도록 해주고, 무선 통신 네트워크가 아닌 다른 방법으로 모바일 장치(100)에 정보 또는 소프트웨어 다운로드를 제공함으로써 모바일 장치(1100)의 기능을 확장시킬 것이다. 대안적 다운로드 경로는 예를 들어 직접적이고 신뢰성 있으며 신뢰받는 접속을 통하여 장치 상에 암호화 키를 로딩하여 보안 장치 통신을 가능케하는데 사용될 수 있다. 당업자라면 이해하겠지만, 직렬 포트(1130)는 또한, 모뎀으로서 동작하는 컴퓨터에 모바일 장치를 접속하는데 사용될 수 있다.

단거리 통신 서브시스템과 같은 기타의 통신 서브시스템(1140)은, 모바일 장치(1100)와, 반드시 유사한 장치들일 필요는 없는 기타의 시스템들 또는 장치들간의 통신을 제공할 수 있는 추가의 컴포넌트이다. 예를 들어, 서브시스템(1140)은, 유사하게 인에이블된 시스템 및 장치들과의 통신을 제공하기 위해, 적외선 장치 및 연관된 회로들과 컴포넌트 또는 Bluetooth™ 통신 모듈을 포함할 수 있다. 서브시스템(1140)은 또한 WiFi 통신을 위해 사용될 수도 있다.

본 명세서에서 기술된 실시예들은 본 출원의 기술들의 요소들에 대응하는 요소들을 갖는 구조, 시스템, 또는 방법의 예이다. 지금까지 기술된 설명은 당업자로하여금 본 출원의 기술의 요소들에 유사하게 대응하는 대안적 요소들을 갖는 실시예를 만들고 사용할 수 있도록 해 줄수 있다. 따라서, 본 출원의 기술의 의도된 범위는 본 명세서에서 기술된 본 출원의 기술과 상이하지 않은 다른 구조, 시스템 또는 방법을 포함하며, 나아가, 본 명세서에서 기술된 본 출원의 기술과 큰 차이가 없는 다른 구조, 시스템 또는 방법도 포함한다.

1112: 수신기
1114: 전송기
1150: 장치 상태
1158: 프로그램
1152: 주소록
1154: 다른 PIM
1156: 기타
1151: 구성
1153: 기타
1124: 플래시 메모리
1144: SIM/RUIM 인터페이스
1142: 기타 장치 서브시스템
1138: 마이크로프로세서
1128: 보조 I/O
1130: 직렬 포트
1122: 디스플레이
1132: 키보드
1134: 스피커
1136: 마이크로폰
1140: 기타 통신서브시스템

Claims

리치 미디어(rich media)를 전송하기 위한 방법에 있어서,
상기 리치 미디어가 개별 콘텐츠(discrete content) - 상기 개별 콘텐츠는 이미지, 오디오 미디어 항목(item), 또는 비디오 미디어 항목 중 적어도 하나임 - 를 포함하는지의 여부를 검사하는 단계;
상기 검사에 응답하여 상기 리치 미디어의 상기 개별 콘텐츠의 저해상도 버전을 전송하는 단계; 및
상기 저해상도 버전의 해상도보다 더 높은 해상도를 갖는 상기 개별 콘텐츠의 조각을 업데이트로서 후속하여 전송하는 단계
를 포함하는 리치 미디어를 전송하기 위한 방법.
제1항에 있어서, 상기 후속하여 전송하는 단계는 미리결정된 대기 시간 다음에 수행되는 것인, 리치 미디어를 전송하기 위한 방법.
제1항에 있어서, 상기 저해상도 버전을 전송하기 이전에, 상기 개별 콘텐츠를 복수의 해상도로 쪼개는 단계를 더 포함하는, 리치 미디어를 전송하기 위한 방법.
제1항에 있어서, 상기 개별 콘텐츠의 저해상도 버전을 전송하는 단계는, 상기 개별 콘텐츠와 상기 리치 미디어 내의 다른 요소들을 동기화시키는 것인, 리치 미디어를 전송하기 위한 방법.
제1항에 있어서, 상기 개별 콘텐츠의 더 높은 해상도 조각은 상기 개별 콘텐츠의 저해상도 버전에 점증적으로(incrementally) 적용되는 것인, 리치 미디어를 전송하기 위한 방법.
제1항에 있어서, 상기 개별 콘텐츠의 저해상도 버전과 상기 개별 콘텐츠의 더 높은 해상도 조각은 대역내 또는 대역외로 전송되는 것인, 리치 미디어를 전송하기 위한 방법.
제1항에 있어서, 상기 개별 콘텐츠의 상기 저해상도 버전을 전송하는 단계와 상기 더 높은 해상도 조각을 전송하는 단계는 유니캐스트(unicast)를 통해 수행되는 것인, 리치 미디어를 전송하기 위한 방법.
제1항에 있어서, 상기 개별 콘텐츠의 상기 저해상도 버전을 전송하는 단계와 상기 더 높은 해상도 조각을 전송하는 단계는 브로드캐스트를 통해 수행되는 것인, 리치 미디어를 전송하기 위한 방법.
제1항에 있어서, 더 높은 해상도 조각이 전송되어야 하는지의 여부를 검사하고, 만일 전송되어야 하지 않는다면, 상기 더 높은 해상도 조각을 전송하는 단계를 차단하는 단계를 더 포함하는, 리치 미디어를 전송하기 위한 방법.
제9항에 있어서, 상기 검사하는 단계는 네트워크 요소에서 설정된 룰과 정책을 이용하는 것인, 리치 미디어를 전송하기 위한 방법.
제10항에 있어서, 상기 검사하는 단계는, 상기 리치 미디어를 수신하는 모바일 장치가 로밍중인지의 여부; 상기 모바일 장치로의 네트워크 접속이 이용가능한지의 여부; 사용자가 더 높은 해상도 조각을 요청했는지의 여부; 더 높은 해상도 조각을 허용할 시간이 충분한지의 여부; 장면 업데이트 가중치; 상기 모바일 장치 상의 가용 메모리; 상기 모바일 장치의 배터리 수명; 리치 미디어의 전달(delivery)에 관한 콘텐츠 제공자 선호사항; 및 리치 미디어의 전달에 관한 서비스 제공자 선호사항으로 구성된 그룹으로부터 선택된 하나 이상의 인자들을 이용하는 것인, 리치 미디어를 전송하기 위한 방법.
제1항에 있어서, 상기 저해상도 버전의 전송 단계는 증가된 신뢰성 포멧을 이용하여 이루어지는 것인, 리치 미디어를 전송하기 위한 방법.
제12항에 있어서, 상기 증가된 신뢰성 포멧은 더 높은 FEC(Forward Error Correction)가 지원되는 랜덤 액세스 포인트(Random Access Point)인 것인, 리치 미디어를 전송하기 위한 방법.
제1항에 있어서, 상기 더 높은 해상도 조각을 전송하는 단계는 풀 해상도(full resolution) 조각이 전송될 때까지 반복되는 것인, 리치 미디어를 전송하기 위한 방법.
제1항에 있어서, 상기 개별 콘텐츠의 저해상도 버전과 상기 개별 콘텐츠의 더 높은 해상도 조각은 문서 객체 모델 이벤트(Document Object Model event)를 이용하여 전송되는 것인, 리치 미디어를 전송하기 위한 방법.
제1항에 있어서, 상기 개별 콘텐츠의 저해상도 버전과 상기 개별 콘텐츠의 더 높은 해상도 조각은 LASeR 명령어들을 이용하여 전송되는 것인, 리치 미디어를 전송하기 위한 방법.
제1항에 있어서, 개별 콘텐츠의 점진적 전달을 나타내도록 실시간 트랜스포트 프로토콜 헤더가 수정되는 것인, 리치 미디어를 전송하기 위한 방법.
제1항에 있어서, 상기 개별 콘텐츠는 래스터 이미지인 것인, 리치 미디어를 전송하기 위한 방법.
리치 미디어를 전송하기 위한 네트워크 요소에 있어서,
통신 서브시스템; 및
프로세서를 포함하고,
상기 프로세서와 상기 통신 서브시스템은, 제1항 내지 제18항 중 어느 한 항에 따른 방법을 수행하도록 협동하는 것인, 네트워크 요소.
모바일 장치에 의해 수행되는, 리치 미디어를 수신하기 위한 방법에 있어서,
리치 미디어에서 개별 콘텐츠 - 상기 개별 콘텐츠는 이미지, 오디오 미디어 항목, 또는 비디오 미디어 항목 중 적어도 하나임 - 의 저해상도 버전을 수신하는 단계;
상기 리치 미디어를 렌더링하는 단계;
상기 개별 콘텐츠의 저해상도 버전보다 더 높은 해상도를 갖는 상기 개별 콘텐츠의 조각을 수신하는 단계; 및
상기 개별 콘텐츠의 저해상도 버전에 상기 더 높은 해상도를 갖는 조각을 점증적으로 적용시키는 단계
를 포함하는, 리치 미디어를 수신하기 위한 방법.
제20항에 있어서, 상기 개별 콘텐츠의 더 높은 해상도 조각은 수신되어 상기 개별 콘텐츠의 저해상도 버전에 점증적으로 적용되는 것인, 리치 미디어를 수신하기 위한 방법.
제20항에 있어서, 상기 개별 콘텐츠의 저해상도 버전과 상기 개별 콘텐츠의 더 높은 해상도 조각은 대역내 또는 대역외로 수신되는 것인, 리치 미디어를 수신하기 위한 방법.
제20항에 있어서, 상기 개별 콘텐츠의 저해상도 버전과 더 높은 해상도 조각의 수신은, 유니캐스트 또는 브로드캐스트를 통해 이루어지는 것인, 리치 미디어를 수신하기 위한 방법.
제20항에 있어서, 상기 개별 콘텐츠의 더 높은 해상도 조각이 네트워크 요소로부터 전송되어야 하는지의 여부를 나타내는 정보를 상기 네트워크 요소에 전송하는 단계를 더 포함하는, 리치 미디어를 수신하기 위한 방법.
제24항에 있어서, 상기 정보는, 상기 리치 미디어를 수신하는 모바일 장치가 로밍중인지의 여부; 상기 모바일 장치로의 네트워크 접속이 이용가능한지의 여부; 사용자가 더 높은 해상도의 개별 콘텐츠를 요청했는지의 여부; 더 높은 해상도의 개별 콘텐츠를 허용할 시간이 충분한지의 여부; 장면 업데이트 가중치; 상기 모바일 장치상의 가용 메모리; 및 상기 모바일 장치의 배터리 수명으로 구성된 그룹으로부터 선택된 하나 이상의 인자들을 포함하는 것인, 리치 미디어를 수신하기 위한 방법.
제20항에 있어서, 상기 개별 콘텐츠의 저해상도 버전은 증가된 신뢰성 포멧으로 수신되는 것인, 리치 미디어를 수신하기 위한 방법.
제20항에 있어서, 상기 개별 콘텐츠의 저해상도 버전과 더 높은 해상도 조각은 문서 객체 모델 이벤트(Document Object Model event)를 이용하여 수신되는 것인, 리치 미디어를 수신하기 위한 방법.
제20항에 있어서, 상기 개별 콘텐츠의 저해상도 버전과 더 높은 해상도 조각은 LASeR 명령어들을 이용하여 수신되는 것인, 리치 미디어를 수신하기 위한 방법.
제20항에 있어서, 상기 리치 미디어는 개별 콘텐츠의 점진적 전달을 나타내도록 수정된 실시간 트랜스포트 프로토콜 헤더를 포함하는 것인, 리치 미디어를 수신하기 위한 방법.
리치 미디어를 수신하기 위한 모바일 장치에 있어서,
통신 서브시스템; 및
프로세서를 포함하고,
상기 통신 서브시스템 및 상기 프로세서는 제20항 내지 제29항 중 어느 한 항에 따른 방법을 수행하도록 협동하는 것인, 모바일 장치.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제