KR20070063571A

KR20070063571A - Ｍｈｐ 애플리케이션들의 시동 시간을 감소시키기 위한시스템 및 방법

Info

Publication number: KR20070063571A
Application number: KR1020077009834A
Authority: KR
Inventors: 페트루스 엔. 우터스
Original assignee: 코닌클리케 필립스 일렉트로닉스 엔.브이.
Priority date: 2004-09-30
Filing date: 2005-09-28
Publication date: 2007-06-19
Also published as: JP2008515322A; EP1805605A2; US20080209453A1; WO2006035405A3; WO2006035405A2

Abstract

시스템 및 방법에는 MHP 1.0.x의 지속성 저장 용량들 및 사용자 클래스로더를 사용함으로써 MHP 1.0.x 표준에 기초한 MHP 애플리케이션들의 시동 시간을 감소시키는 것이 제공된다. 일반 래퍼 클래스는 임의의 MHP 1.0.x가 그것 자체를 복사하고, 지속성 저장 장치로부터 그것 자체를 실행하고, 그로 인해 시동 시간을 줄일 수 있도록 생성된다. 일반 래퍼 클래서는 MHP 프로토콜, DVB 클래스로더 API 및 지속성 저장장치 API에 두 개의 이미 존재하는 API들을 활용한다.

MHP, 시동 시간, API

Description

ＭＨＰ 애플리케이션들의 시동 시간을 감소시키기 위한 시스템 및 방법{System and method for reducing the start-up time of ＭＨＰ applications}

본 발명은 MHP 1.0.x에 기반한 MHP 애플리케이션들의 시동 시간을 줄이는 시스템 및 방법에 관한 것이다.

텔레비전 방송 소비자들의 많은 복잡한 시장-주도적 요구들을 충족시키기 위해 콘텐트 데이터를 가입자 셋톱 박스들에 전달하는 것과 같은 미들웨어 플랫폼 제공자들은 다수의 이종(heterogeneous) 방송 및 웹 가능한 네트워크들을 가로질러 배치되는 콘텐트(즉, 애플리케이션들/데이터)를 액세스할 필요가 있다. 이들 네트워크들은 일반적으로 예로써, 디지털 비디오 방송(Digital Video Broadcasting: DVB)(DVB-C(케이블), DVB-T(지상파), 및 DVB-S(위성)을 포함), OpenCable.TM. 애플리케이션 플랫폼(OpenCable.TM. Applications Platform: OCAP), 차세대 텔레비전 시스템 위원회(ATSC), 국가 텔레비전 시스템 위원회(NTSC), GI 모토롤라 네트워크, 멀티미디어 홈 플랫폼(MHP) 표준 등을 포함한 각각의 미국 또는 유럽 산업 디지털 방송 표준에 기초한다. MHP 표준은 위성, 케이블, 지상파 및 마이크로파를 포함한 모든 전송 네트워크들에서의 방송 및 대화식 서비스들에 대한 현존하는 DVB 표준을 확장한다. DVB/MHP 표준은 일반적인, 즉, 그 애플리케이션들이 실행하는 대화식 디지털 애플리케이션들 및 터미널들 사이의 하드웨어 독립적인, 인터페이스를 정의한다. 이것은 디지털 콘텐트 제공자들이 저기능으로부터 고기능 셋톱 박스들, 집적된 디지털 TV 세트들 및 멀티미디어 PC들에 이르는 모든 유형들의 터미널들을 다룰 수 있게 한다.

DVB/MHP 표준에 따르면, MHP 애플리케이션들은 DSM-CC와 같이 알려진 프로토콜에 의해 순환하는 형태로 방송된다. 애플리케이션을 시작하기 위해, 수신기는 애플리케이션을 시작하도록 요구되는 적어도 일부가 올 때까지 기다려야 한다. 이러한 시간은 종종 비효율적이고 시간 소모적인 완전한 애플리케이션의 순환 시간과 동일하다. 또한, 대역폭 제한들 및 증가하는 애플리케이션 크기는 더 많은 애플리케이션 시동 시간을 상당히 제한한다. 집적된 수신기 장치의 상주 파일 시스템에 MHP 애플리케이션들을 저장하는 것은 API들이 필요할 때 저장된 MHP 애플리케이션들의 검색을 용이하게 하도록 구성되는 MHP 1.1.x 표준에 따라 동작하는 시스템들에 대한 완전한 솔루션을 제공한다. 그러나, 많은 사용자들은 아직 MHP 1.0.x로부터 MHP 1.1.x로 바꾸지 않고 있으며, 그러한 설비는 저장된 MHP 애플리케이션들을 검색하기 위한 MHP 1.0.x에 존재하지 않는다.

그러므로, MHP 1.0.x 표준에 기반한 MHP 애플리케이션들의 시동 시간을 감소시키는 장치 및 방법들을 제공하는 것이 바람직하다.

본 발명에 따르면, MHP 1.0.x 표준에 기초한 MHP 애플리케이션들의 시동 시 간을 감소시키는 시스템 및 방법이 있다. 일반적으로 말하면, 본 발명의 시스템 및 방법은 MHP 1.0.x 애플리케이션들이 사용자 클래스로더(custom Classloader) 및 설명될 MHP 1.0.x의 지속성 저장 용량을 사용함으로써 그 시동 시간을 감소시키도록 한다.

일 실시예에서, 일반 래퍼(GW) 클래스는 임의의 MHP 1.0.x 애플리케이션이 지속성 파일 시스템에 그 자체를 복사하고 그로부터 그 자체를 실행하도록 허용하는 MHP 1.0.x 애플리케이션들을 위해 생성되며, 이것은 예를 들면, MHP 1.0.x 애플리케이션의 시동 시간을 감소시키기 위해 일반적인 방송 파일 시스템 대신에, 대화식 디지털 텔레비전(IDT) 시스템 또는 셋톱 박스(STB)에 연관될 수 있다.

시동 시간은 MHP 프로토콜, DVBClassloader API 및 지속성 저장장치 API에서의 두 개의 이미 존재하는 API들을 이용함으로써 일반 래퍼(GW) 클래스를 통해 감소된다. DVBClassloader API는 상수 파일 시스템에서의 디렉토리들로부터 클래스들 및 리소스들을 로딩할 수 있는 DVBClassloader 객체를 인스턴스화하기 위한 일반 래퍼(GW) 클래스로 불리운다. DVBClassloader 객체는 지속성 파일 시스템에서의 클래스 파일들의 위치 및 방송 파일 시스템에서의 클래스 파일들의 위치를 포함한 URL들의 리스트를 수신한다. DVBClassloader 객체는 지속성 파일 시스템에서의 MHP 1.0.x 애플리케이션의 클래스 파일들 및 리소스들을 검색하기 위해 리스트에서의 제 1 URL을 사용한다. 지속성 파일 시스템에서 발견되지 않은 클래스들 및 리소스들에 대해, DVBClassloader 객체는 방송 파일 시스템에서의 지속성 파일 시스템에 발견되지 않은 클래스들 및 리소스들을 검색하기 위해 리스트에서의 제 2 URL을 사용한다.

또 다른 양상에 따르면, 일반 래퍼(GW) 클래스가 호출되는 시간마다, 방송 시스템으로부터 지속성 파일 시스템으로 파일들을 복사하기 시작하는 카피스레드(copythread) 프로세스(Java 작업)가 생성된다. 보다 상세하게는, 지속성 저장장치 API는 일반 래퍼(GW) 클래스로 불리운다. 카피스레드 프로세스는 일반 래퍼(GW) 클래스가 호출될 때마다 방송 스트림으로부터 지속성 파일 시스템으로 MHP 애플리케이션의 클래스 파일들만큼을 복사하기 위해 지속성 저장장치 API를 이용한다. 일반 래퍼(GW) 클래스가 호출될 때마다, 카피스레드 프로세스는 지속성 저장장치로 클래스들을 계속해서 복사함으로써 이전의 호출에서 중단된 지점에서 계속한다. 그러한 것으로서, 일반 래퍼(GW) 클래스에 대한 각각의 호출은 이전의 호출들의 각각에서 지속성 저장장치로 부가적인 클래스 파일들을 저장함에 의해 MHP 애플리케이션의 시동 시간을 점차 향상시키도록 한다. 일 실시예에서, 이러한 프로세스는 상술된 바와 같이 DVBClassloader API와 병행하여 수행되기 위해 낮은 우선순위를 가지고 수행될 것이다.

일 양상에 따르면, 애플리케이션에 관련된 지속성 파일 시스템 디렉토리가 단지 보안 제한들 없이 액세스할 수 있는 디렉토리임을 인식함으로써, MHP 애플리케이션이 상주 시스템으로부터 Xlet 콘텍스트를 수신하기 전에 MHP 애플리케이션의 구성 ID 및 애플리케이션 ID를 유도하는 것이 가능하다.

본 발명의 이전 특징들은 첨부된 도면들과 함께 취해진 본 발명의 예시적인 실시예의 다음의 상세한 설명을 참조함으로써 보다 쉽게 명백해지고 이해될 수 있을 것이다.

도 1은 멀티미디어 애플리케이션들의 통신 시스템의 백본을 도시한 도면.

도 2a는 종래 기술에 따른 XLET 클래스 로딩을 도시한 타임라인 다이어그램들을 도시한 도면.

도 2b은 본 발명에 따른 XLET 클래스 로딩을 도시한 시퀀스 다이어그램들을 도시한 도면.

본 발명은 DVB/MHP 환경에서 적용된 바와 같은 DSM-CC 방송 프로토콜에 따른 사용을 위한 실시예를 참조하여 설명될 것이다.

배경에 설명된 바와 같이, 종래 기술에 따라서, 도 1의 IRD 수신기(12)와 같은, DSM-CC를 사용하는 디지털 TV 플랫폼들이 방송되기 위해 요청된 모듈들의 차례를 기다려야 함으로써 야기되는 텔레텍스트(teletext)와 같은 시스템들과 부닥치는 모듈들에 접근할 때의 긴 지연들을 회피하기 위해 적어도 몇몇의 DSM-CC 모듈들을 일반적으로 캐싱한다. 그러나 캐싱은 제한된 메모리 및 비지속성으로 인하여 불완전한 솔루션이다. 그러한 것으로서, 저장 장치는 바람직한 옵션이다. 이후의 리콜 에 대해 지속성 파일 시스템에 MHP 애플리케이션들을 저장하는 것은 "저장된 애플리케이션들로서 칭하여지는 MHP 1.1의 고유의 메커니즘이며, 그러나 MHP 1.0.x는 지속성 파일 시스템으로부터 그러한 저장 및 리콜에 대한 분명한 지원을 제공하지 않는다.

본 발명의 시스템 및 방법은 MHP 1.0.x 사양에 따라 동작하는, 임의의 존재하는 MHP 애플리케이션이 그것이 시작되는 다음번에 지속성 파일 시스템으로 그것 자체를 복사하고 지속성 파일 시스템으로부터 그것 자체를 로딩할 수 있도록 일반 래퍼 클래스를 제공함으로써 이들 결점들을 극복한다. 프로세스를 복사하는 것은 제 1 또는 이후의 호출에 전체적으로 수행되지 않으며, 그 경우, 애플리케이션이 시작되는 다음번에 지속성 파일 시스템으로부터 단지 부분적으로 로딩될 것이다.

멀티미디어 애플리케이션들에 대한 통신 시스템의 백본(backbone)은 도 1을 참조하여 이제 설명될 것이다. 백본은 다수의 통신 경로들을 포함한다. 전송 매체는 오디오(A), 비디오(V), 및 데이터(D)와 같은, 디지털 정보의 고속 정보를 지원한다. 다수의 사용자들은 백본에 연결되며, 그것의 제 1 사용자(10)는 도 1에 도시된다. 이 사용자(10)은 도 1에 지정된 다수의 서비스 제공자들(40)에 의헤 제공된, 텔레비전 프로그램들의 가입자와 같은 멀티미디어 정보의 수신자로서 기능한다. 각각의 사용자는 인입 정보를 처리하고 때때로 정보의 전송자로서 또한 기능하도록 배열된 셋톱 박스(미도시) 또는 집적된 수신기/디코더(IRD)(12)가 될 수 있는 수신 또는 상주 플랫폼(resident platform)을 가진다.

본 발명의 대표적인 실시예에서, 상주 플랫폼은 집적된 수신기/디코 더(IRD)(12)로서 구체화되며 DVB/MHP 순응적임을 가정한다. 멀티미디어 홈 플랫폼(MHP) 명세는 디지털 텔레비전에 대한 강화된 대화식 애플리케이션의 전송을 위한 DVB 표준에 의해 정의된다. 이러한 명세의 가장 큰 특징은 자바 미들 웨어를 사용한다는 것이다. 자바는 플랫폼들 간의 호환성을 향상시키기 위한 방법으로서 선 마이크로시스템즈에 의해 진행된 미들웨어이다. 모든 자바 애플리케이션들은 자바가 설치된 컴퓨터 또는 장치상에서 실행될 것이며, 자바 애플리케이션의 가장 큰 특징은 그것들이 특정 플랫폼에 제한되지 않고 광범위한 운영 환경들에서 사용될 수 있다는 것이다. 그러한 것으로서, 멀티미디어 홈 플랫폼(MHP)은 그 애플리케이션들이 실행되는 대화식 디지털 애플리케이션들 및 터미널들 간의 일반적인 인터페이스를 정의한다. 이러한 인터페이스는 상이한 MHP 터미널 구현들의 특정 하드웨어 및 소프트웨어 상세사항들로부터의 상이한 제공자 애플리케이션들을 분리한다. 그것은 디지털 콘텐트 제공자들이 저기능에서 고기능 셋톱 박스들에 이르는 모든 유형의 터미널들, 집적된 디지털 TV 세트들 및 멀티미디어 PC들을 다룰 수 있게 한다. 여기에서 사용된 바와 같이, "애플리케이션"은 방송 수신 장치에서의 다양한 목적들을 달성하도록 실행되는 프로그램으로서 정의된다.

MHP 애플리케이션들은 적절하게 설치된 IRD 수신기(12)로 디지털 텔레비전 프로그램들과 함께 방송 스트림으로 방송된다. 배경에 설명된 바와 같이, MHP 애플리케이션들은 ISO/IEC1381-6 하에 특정된 DSM-CC 프로토콜과 같은 프로토콜에 따라 캐로셀(carousel) 포맷으로 방송되고, 여기서 MHP 애플리케이션들은 주기적으로 방송된다. 적절하게 설치된 IRD 수신기(12)는 이들 MHP 애플리케이션들을 수신하고 그것들을 국부적으로 실행한다. 예시적인 애플리케이션들에는 전자 프로그램 가이드들, 따라하는(play-along) 게임들, 텔레뱅킹, 메뉴 네비게이션 옵션들, 텔레쇼핑, 전자 신문들 및 유사한 정보 서비스들이 있다.

상술된 바와 같이, 본 발명은 임의의 MHP 1.0.x 애플리케이션이 지속성 파일 시스템으로 그 자체를 복사하고 그로부터 그 자체를 실행하도록 하는 PersistentCopyWrapper Xlet으로서 달리 칭하여지는, 일반 래퍼(GW) 클래스를 이용한다. 그러므로 그것은 Xlet들을 간단히 리뷰하는 이러한 지점에서 유익하다.

선 마이크로시스템즈는 Xlet의 또 다른 이름으로, 자바 TVTM API를 공개하였다. 자바 TV 애플리케이션들은 프로그래밍 정보 및 알림들과 같은 특징들, 게임 쇼와 협조하는 능력과 같은 선택 가능한 애플리케이션들, 스크린을 가로질러 움직이는 주식 시세 표시기 배너와 같은 방송 데이터, 또는 대화식 프로그램-관련된 조사와 같은 미디어 제어를 제공함으로써 방송 및 시청 경험을 증가시킨다. 애플릿의 경우에, 기본적인 소프트웨어는 브라우저 또는 애플릿뷰어 툴(appletviewer tool)이다. Xlet의 경우에, 기본적인 소프트웨어는 자바 TV 플랫폼(예로써, 도 1의 IRD(12))을 지원하는 셋톱 박스 또는 디지털 텔레비전 수신기이다. Xlet들은 "주된(main)" 방법을 가지지 않으며 Xlet들은 항상 인터페이스 Xlet을 실행한다. 애플릿과 같이, Xlet들은 수명 주기를 가지며, 수명 주기 메소드 서명(life cycle method signature)은 인터페이스 Xlet에 의해 정의된다. 인터페이스 Xlet은 생성, 초기화, 시작 및 파괴와 같은 Xlet 상태 변화들을 알리기 위해 수명 주기 메소드들을 제공한다. 그러나, 인터페이스 Xlet은 그 수명 주기 메소드들에 대한 실행을 제공하지 않는다.

모든 자바 TV 실행들은 인터페이스 Xlet을 경유하여 다양한 애플리케이션 상태들을 통해 하나 이상의 Xlet들을 이동시키기 위해 수명 주기 메소드들을 호출하는 애플리케이션 매니저를 가진다. 상술된 바와 같이, 인터페이스 Xlet은 그 수명 주기 메소드들에 대한 실행을 제공하지 않는다. 개발자는 Xlet 수명 주기에서의 각각의 지점에서 일어나는 것을 정의함으로써 그 메소드들에 대한 애플리케이션-지정 실행들을 제공한다. 예를 들면, 게임 Xlet에 대한 iniXlet 메소드는 사용자 인터페이스 구성 요소들을 생성할 것이다. Xlet은 몇몇 상태 변화들 자체를 개시하고 XletContext 인터페이스에서 메소드들을 야기함으로써 그 상태 변화들을 애플리케이션 매니저에 알리는 것을 주의한다.

인터페이스 Xlet은 자바 TVTM API에 정의된 패키지들 중 하나인 javax.tv.xlet 패키지에 의해 정의된다. 자바 TVTV API는 패키지들로 그룹핑된 인터페이스들 및 클래스들로 이루어진다. 이들 패키지들은 텔레비전 네트워크들에 의해 전송된 방송 스트림을 통해 디지털 수신기로 전송된 비디오, 오디오, 및 데이터를 처리하기 위한 인터페이스들 및 클래스들을 포함한다.

javax.tv.xlet에 정의된, 인터페이스 Xlet은 애플리케이션 매니저가 Xlet을 생성, 초기화, 시작, 정지 및 파괴할 수 있도록 허용한다. 애플리케이션 매니저는 Xlet의 상태를 유지하고 다양한 수명주기 메소드들을 통해 Xlet상에 메소드들을 야기한다. Xlet은 애플리케이션 매니저에 의해 지시되는 바와 같이 그것의 내부 동작들 및 리소스 사용들을 업데이트하기 위해 이들 메소드들을 실행한다.

javax.tv.xlet에 의해 정의된 바와 같이, 인터페이스 Xlet의 메소드 요약은 다음과 같다. destroylet은 종료하고 파괴된 상태(destroyed state)로 진입하기 위해 Xlet에 신호를 보낸다. initXlet은 그 자체를 초기화하고 중지 상태(paused state)로 진입하기 위해 Xlet에 신호를 보낸다. startXlet은 서비스를 제공학 ㅣ시작하고 활성 상태(active state)로 진입하기 위해 Xlet에 신호를 보낸다. 이들 메소드들의 어떤 것은 이하에서 설명될 본 발명의 일반 래퍼 클래스에 통합된다.

잘 알려진 바와 같이, MHP 1.0.x는 기본적이고, 벤더 특정의 하드웨어 및 소프트웨어에 상관없이 디지털 대화식 TV에 대한 광범위한 애플리케이션 실행 환경을 특정한다. 이러한 실행 환경은 Java™가상 머신의 사용 및 대화식 디지털 TV 터미널의 일반적인 리소스들 및 시설들로의 액세스를 제공하는 일반 API들의 정의에 기초한다. 이들 일반 API들을 사용하는 Java™애플리케이션은 DVB-J 애플리케이션이라 불리운다. 반대로, MHP 1.1은 새로운 선택적인 애플리케이션 유형, DVB-HTML을 정의하는 것을 포함하는 다수의 방식으로 MHP 1.0.x 플랫폼에 대한 부가적인 기능성을 제공한다. MHP 1.0.x에 대해서, 단지 DVB-J만이 지원될 것을 요구한다. 그러므로, MHP 1.0.x 하에 실행되는 DVB-J 애플리케이션에 대해서, "javax.tv.xlet.Xlet"은 정의된 인터페이스이고 MHP 1.0.x하에서 실행될 수 있는 단지 인식할 수 있는 엔티티이다.

본 발명은 임의의 MHP 1.0.x 애플리케이션이 지속성 파일 시스템으로 MHP 애플리케이션의 코드(클래스 파일들)를 저장하도록 허용하는 MHP 애플리케이션들의 일반 Xlet 패러 클래스를 생성하고, 그것이 실행되는 다음번에 지속성 파일 시스템 으로부터 완전한 MHP 애플리케이션을 로딩하기 위해 저장된 클래스 파일들을 사용한다. 이러한 방식으로, 일반적으로 저장되지 않는 MHP 애플리케이션들은 향상된 시동 시간을 실현한다.

본 발명은 바람직하게는 임의의 MHP 1.0.x 애플리케이션이 지속성 파일 시스템으로 그 자체를 복사하고 그로부터 그 자체를 실행하도록 하는 MHP 애플리케이션들에 대해, 본 명세서에서 "PersistentXletCopyWrapperXlet"으로서 달리 칭하여지는, 설명될 일반 래퍼(GW) Xlet 클래스를 생성함으로써 일반적인 방법으로 구현된다.

일반 래퍼(GW) 클래스는 GW 래퍼 클래스에서 호출된 각각의 메소드, 생성자, 정적 초기화기가 원래의 MHP 1.0.x 애플리케이션에서의 대응하는 메소드, 생성자, 정적 초기화기에 전파되는 방식으로 설계된다. 사실, 인터페이스는 그것이 감기는 MHP 1.0.x 애플리케이션 인터페이스와 정확하게 같다.

원래의 MHP 1.0.x 애플리케이션의 기능성을 미러링하는 것에 더하여, 일반 래퍼 클래스는 두 개의 API들을 포함한다. 제 1 API는 자바 클래스로더의 확장이고 MHP API의 일부인 DVBClassloader API이다. 그것은 MHP 애플리케이션들에 의한 사용을 위해 단지 이용 가능한 클래스로더라는 점에서 특별한 확장이다. DVBClassloader API는 자바 클래스들이 저장될 수 있는 위치들을 참조하는 URL들의 검색 경로로부터 클래스들 및 리소스들을 로딩하기 위해 사용된다. 본 발명에 사용된 바와 같이, DVBClassloader API에는 MHP의 클래스들을 찾을 수 있는 방송 파일 시스템에서의 위치들의 리스트에 대응하는 URL들의 검색 경로 및 지속성 파일 시스 템에서의 위치들의 리스트에 대응하는 URL들의 검색 경로가 제공된다.

제 2 API는 "PersistentXletCopyWrapperXlet" 클래스가 호출될 때마다 DVBClassloader API에 실질적으로 병행하여 동작할 수 있는 지속성 저장장치 API이다. 카피스레드 프로세스는 방송 스트림으로부터 지속성 파일 시스템으로 MHP 1.0.x 애플리케이션의 클래스 파일들을 복사한다. "PersistentXletCopyWrapperXlet" 클래스가 호출될 때마다, 카피스레드 프로세스는 지속성 파일 시스템으로 클래스들을 계속해서 복사함으로써 이전 호출에서의 중지된 지점에서 계속한다. 이러한 방식으로, 카피스레드 프로세스는 오히려 배경 프로세스에 가깝다. 그러한 것으로서, "PersistentXletCopyWrapperXlet" 클래스에 대한 각각의 호출은 단지 이전의 호출들의 각각에서 지속성 파일 시스템으로 부가적인 클래스 파일들을 저장함으로써 MHP 1.0.x 애플리케이션의 시동 시간을 향상시키는 역할을 수행한다.

도 2a 및 도 2b는 종래 기술에 따른 MHP 애플리케이션(도 2a) 및 본 발명에 따른 "PersistentXletCopyWrapperXlet" 클래스에 대한 호출의 머캐닉들(mechanics)을 나타낸 시퀀스 다이어그램을 도시한다. 연대순으로, 시퀀스 다이어그램들은 사용자가 채널을 바꾼 후의 지점에서 시작하고, MHP 시스템은 (1) 그 채널과 관련된 MHP 애플리케이션이 있는지, (2) 어떤 Xlet 클래스 파일들이 각각의 MHP 애플리케이션에 속하는지 및 (3) 스트림 및 클래스의 위치를 응답적으로 결정한다. 이 모두는 MHP 프로토콜로 캡슐화된다. 몇몇 지점에서 시스템은 도 2a 및 2b에 시작하는, 클래스 파일들을 로딩하기 시작할 것이다.

도 2a는 종래 기술의 시퀀스 다이어그램이다. 그것은 MHP 애플리케이션이 시작될 때 MHP 시스템이 다음의 단계를 실행할 것임을 설명한다. (1) Xlet 클래스를 로딩하는 단계, 라벨(51) 참조(즉, Xlet 인터페이스, AnXlet을 실행하는 자바 클래스), (2) Xlet 클래스의 정적 초기화기들을 실행하는 단계, 라벨(53) 참조, (3) Xlet 클래스의 인스턴스를 생성하고, 그것의 디폴스 생성자를 실행하는 단계, 라벨(55) 참조, (4) iniXlet 호출, 라벨(57) 참조, (5) start Xlet 호출, 라벨(59) 참조. 이들 단계들은 MHP 애플리케이션의 수명주기를 제어한다. MHP 애플리케이션이 시작될 때마다, 동일한 단계들이 수행됨을 주의한다. 보다 큰 애플리케이션들은 보다 작은 애플리케이션을 로딩하는데 보다 긴 시간이 필수적으로 걸린다. 몇몇 인스턴스들에서, 도시된 클래스들은 부가적인 시간을 요구하는 그들 자신의 생성자 및 초기화기들을 갖는 다른 클래스들을 반복적으로 로딩할 것이다.

도 2b는 GW 클래스(90)으로서 본 명세서에 칭하여지는, 일반 래퍼 클래스, "PersistentXletCopyWrapperXlet"에 의해 수행되는 단계들을 도시한 본 발명의 실시예에 따른 시퀀스 다이어그램이다. MHP 애플리케이션을 시작하기 위한 종래 기술(도 2a에 도시된 바와 같이)의 동작들을 수행하는 것에 더하여 GW 클래스(90)는 두 개의 API들을 호출한다. DVBClassloader API 및 지속성 파일 시스템 API.

MHP 시스템(70)은 xlet 클래스들을 로딩하기 위해 클래스로더(75)를 잠재적으로 인스턴스화한다(이러한 클래스로더는 시스템-지정이고 따라서 애플리케이션에 의해 사용되지 않는다).

MHP 시스템(70)은 그 후 GW 클래스(90)를 로딩하기 위해 "loadClass"(201)을 호출한다.

MHP 시스템(70)은 그 후 GW 클래스(90)의 "정적 초기화기"(301)를 호출한다. 이러한 호출은 DVB클래스 로더 객체(80)를 차례로 인스턴스화한다. 상술된 바와 같이, DVBClassloader는 MHP 애플리케이션이 지속성 파일 저장 시스템으로부터 MHP 애플리케이션을 로딩하기 위해 MHP 1.0.x 시스템에서 이용할 수 있는 단지 한 종류의 클래스로더이다. DVBClassloader는 시스템 리소스이고 URL 파라미터들의 리스트(미도시)를 수신한다. 바람직한 실시예에서, DVBClassloader 객체(80)는 클래스들의 위치(들) 및 지속성 파일 시스템 및 방송 파일 시스템의 리소스를 가리키거나 정의하는 두 개의 URL들을 수신한다.

DVBClassloader 객체(80)는 지속성 파일 시스템에서 MHP 애플리케이션의 리소스들 및 클래스 파일들을 검색하기 위해 제 1 제공된 URL을 사용한다. 지속성 파일 시스템에서 모든 클래스들 및 리소스들이 발견될 수 있는 것은 아니다. 지속성 파일 시스템에서 발견되지 않은 그 클래스들 및 리소스들에 대해서, DVBClassloader 객체(80)는 그 후 방송 파일 시스템에서 클래스들 및 리소스들을 검색하기 위해 제 2 제공된 URL을 사용한다. 그것은 본 발명의 주요 특징을 나타내는 것과 같이, 순서가 매우 중요한데, 이는 클래스 파일들이 존재하는 경우(즉, 그것들이 이전의 호출로부터 이미 복사되었다고 가정하면) 지속성 파일 시스템으로부터 항상 로딩되고 지속성 파일 시스템에서 그것을 발견하지 않는 대신에 방송 시스템으로부터 단지 로딩되어야 하기 때문이다.

상술된 정확한 순서로 클래스 파일들을 검색하는 것(즉, 방송 시스템을 검색 하는 것에 앞서 지속성 파일 시스템을 검색)은 MHP 애플리케이션의 시동 시에 MHP 애플리케이션에 대한 연속적인 호출들에 걸쳐 증가하는 향상을 허용한다. 이것은 각각의 호출에서 배경 스레드 프로세스가 방송 파일 시스템으로부터 지속성 파일 시스템으로 부가적인 클래스들 및 리소스들을 복사하기 때문에 발생한다. 이것은 모든 클래스들이 복사되고 그 후, 단지 그 지속성 파일 시스템으로부터 그것들을 로딩하는 첫번째 호출에서 복사 동작을 수행하는 것과 대조를 이룬다.

일반적으로, DVBClassloader 객체(80)는 다음과 같이 DVBClassloader에 의해 생성될 것이다.

라인 4에서, 상술된 URL들을 검색하는 바람직한 순서가 정의된다. 즉, 제 1 또는 초기 검색은 지속성 파일 시스템, 즉 persistentUrl에서 이루어지고, 그 후 초기 검색 동안 지속성 파일 저장 시스템에 클래스 파일들 및 리소드들이 발견되지 않는 경우, 필요하다면, 제 2 검색이 방송 파일 시스템, broadcastUrl에서 이루어진다.

GW 클래스(90)는 이어서 원래의 Xlet 클래스를 로딩하기 위해 DVBClassloader 객체(80)의 loadClass를 호출한다. 이 지점에서, 바람직한 검색 순서가 야기되며, 즉 하나 또는 다른 위치로부터 Xlet 클래스들 및 리소스들을 검 색하기 위해 지속성 파일 시스템에 이어서 방송 파일 시스템이 야기된다.

DVBClassloader 객체(80)에 대한 호출은 AnXlet(402)이 호출된 클래스로 리턴하고, 이것은 실행될 MHP 애플리케이션으로부터의 Xlet 클래스이다.

GW 클래스(90)는, 이어서 원래의 Xlet 클래스의 정적 초기화기(403)를 호출한다.

Xlet 클래스의 정적 초기화가 완료되고 MHP 시스템(70)은 MHP 애플리케이션을 차례로 인스턴스화(404)하는 일반 래퍼(GW) 클래스(90)를 인스턴스화할 수 있다(302).

GW 클래스(90)는 그 후 복사 프로세스를 실행할 스레드(405)를 생성한다.

그 후, GW 클래스(90)는 방송 스트림으로부터 지속성 파일 시스템으로 파일들 및 디렉토리들을 반복하여 복사할 스레드(406)를 시작한다.

MHP 시스템(70)은 그 후 GW 클래스(90)의 initXlet(303), MHP 1.0.x 애플리케이션의 initXlet(407)을 차례로 호출할 initXlet(801)을 호출한다.

MHP 시스템(70)은 그 후 GW 클래스(90)의 startXlet(304)를 호출하고, 이것은 MHP 1.0.x 애플리케이션의 startXlet(408)을 차례로 호출할 것이다.

또 다른 양상에 따르면, MHP 애플리케이션이 시스템으로부터 Xlet 콘텍스트를 수신하기 전에 MHP 애플리케이션의 애플리케이션 ID 및 구성 ID를 유도하는 것이 가능하다. 즉, initXlet(도 2b의 303 참조)을 호출하기 이전의 시간 지점에서. 이하에 보다 상세하게 설명될 바와 같이, 구성 ID 및 애플리케이션 ID의 유도는 애플리케이션이 관련된 지속성 파일 시스템 디렉토리가 보단 제한들 없이 액세스할 수 있는 디렉토리인 것을 인식함으로써 이루어진다. 방송하는 각각의 MHP 애플리케이션은 고유의 식별자가 주어지고, 그것은 또한 애플리케이션 정보 테이블(AIT)로서 불리우는 여분의 서비스 정보(SI) 테이블에 저장된다. AIT는 MHP 애플리케이션을 포함하는 모든 서비스에 대해 방송되고, 그것은 그 서비스에 대해 유효한 모든 MHP 애플리케이션에 대한 엔트리를 포함한다. 그러므로, 서비스가 그것과 관련된 두 개의 애플리케이션을 갖는다면, 이 테이블은 두 개의 엔트리들을 포함할 수 있다. 각각의 MHP 애플리케이션에 주어진 고유의 식별자는 시스템의 다른 부분들이 애플리케이션을 고유하게 참조할 수 있도록 하는데, 이는 이름 또는 다른 속성들이 고유하지 않을 수 있기 때문이다. 각각의 식별자는 두 개의 부분들, 즉 MHP 애플리케이션들을 생성하는 모든 구성에 고유한, 32비트 구성 ID, 및 16비트 애플리케이션 ID로 이루어진다. 이러한 애플리케이션 ID는 고유할 필요는 없지만, 동일한 AIT에 신호를 보내는 두 개의 애플리케이션들이 동일한 구성 ID 및 애플리케이션 ID를 가질 수 없다.

MHP 애플리케이션이 시스템으로부터 Xlet 콘텍스트를 수신하기 전에 MHP 애플리케이션의 구성 ID 및 애플리케이션 ID를 유도할 수 있는 키는 Xlet이 그 자신의 애플리케이션 디렉토리에만 액세스한다는 것이 알려져 있다. 이러한 정보는 다음의 방식에 사용된다.

애플리케이션 수명주기 API에 의해서, 일반 래퍼(GW) 클래스(즉 "PersistentXletCopyWrapperXlet")는 모든 현재 알려진 애플리케이션들을 포함한 리스트를 수신한다. 일단 이러한 리스트가 획득되면, GW 클래스는 리스트상의 각각 의 애플리케이션과 관련된 애플리케이션 디렉토리를 액세스하려고 한다. 모든 경우들에 있어서, 하나를 제외하고 "보안 예외(Security Exception)"가 발생할 것이다. 단지 애플리케이션 그 자신의 디렉토리는 "보안 예외"를 던지지 않을 것인데, 이는 상술된 바와 같이 Xlet 만이 그 자신의 애플리케이션 디렉토리에 액세스하기 때문이다. 애플리케이션 수명주기 API는 모든 알려진 애플리케이션들의 구성 ID 및 애플리케이션 ID를 노출하기 때문에, 그 대응이 유도될 수 있다.

결국, 본 발명의 시스템 및 방법은 MHP 1.0.x에서 지속적으로 저장된 애플리케이션들에 대한 명백한 지원의 부족을 극복한다. MHP 실행에서 지속적으로 저장되고 방송 스트림으로부터 그것들을 다시 다운로드하지 않고 이후의 실행을 가능하게 하도록 방송될 수 있는 그 애플리케이션들로서 정의되는 지속적인 저장장치. 보다 상세하게는, 본 발명의 시스템 및 방법은 유리하게는 임의의 MHP 1.0.x 애플리케이션이 지속성 저장 장치로 그 자신을 복사하고 그로부터 그 자신을 실행하도록 허용하는 일반 래퍼 클래스를 생성함으로써 MHP 1.0.x 애플리케이션이 지속성 저장 장치로부터 그 자신을 복사 및 실행하도록 허용한다.

또한, 본 발명의 시스템 및 방법은 또한 MHP 애플리케이션이 시스템으로부터 Xlet 콘텍스트를 수신하기 전에 MHP 애플리케이션의 구성 ID 및 애플리케이션 ID를 유도하기 위한 방법을 제공한다.

비록 본 발명은 특정 실시예들을 참조하여 설명되었지만, 많은 변경들이 첨부된 청구항들에 설명된 바와 같이 이러한 발명의 사상 및 범위에 벗어나지 않고 재분류될 수 있음을 이해해야 한다. 따라서 명세 및 도면들은 예시적인 방법으로 간주되며 첨부된 청구항들의 범위를 제한하기 위해 의도되지 않는다.

Claims

MHP 1.0.x 애플리케이션의 시동 시간을 감소시키는 방법에 있어서,

일반 래퍼(generic wrapper; GW) 클래스를 생성하는 단계;

상기 GW 클래스의 각각의 호출에 응답하여,

(a) 클래스들 및 리소스들의 부분이 저장된 지속성 파일 시스템으로부터 상기 MHP 1.0.x 애플리케이션의 상기 클래스들 및 리소스들의 부분을 로딩하는 동작,

(b) 방송 파일 시스템으로부터 상기 MHP 1.0.x 애플리케이션의 상기 클래스들 및 리소스들의 나머지 부분을 로딩하는 동작을 수행하는 단계를 포함하는, 시동 시간 감소 방법.
제 1 항에 있어서,

상기 방송 파일 시스템에서 상기 지속성 파일 시스템으로 상기 MHP 1.0.x 애플리케이션의 클래스들 및 리소스들의 상기 나머지 부분들의 적어도 일부를 복사하는 동작을 더 포함하는, 시동 시간 감소 방법.
제 2 항에 있어서,

상기 복사 동작은 카피스레드(Copythread) 프로세스의 제어 하에 수행되는, 시동 시간 감소 방법.
제 3 항에 있어서,

상기 카피스레드 프로세스는 MHP 프로토콜에 정의된 바와 같은 지속성 저장장치 API를 이용하는, 시동 시간 감소 방법.
제 1 항에 있어서,

상기 단계들 (a) 및 (b)에서의 로딩 동작은 상기 MHP 프로토콜에 정의된 바와 같은 DVBClassloader API를 이용하는, 시동 시간 감소 방법.
제 5 항에 있어서,

상기 DVBClassloader API는 적어도 제 1 URL 파라미터와 제 2 URL 파라미터를 포함하며, 상기 제 1 URL 파라미터는 상기 MHP 1.0.x 애플리케이션의 클래스들 및 리소스들의 상기 부분이 저장되는 상기 지속성 저장 장치에서의 위치에 대한 클래스 경로를 정의하고, 상기 제 2 URL 파라미터는 상기 MHP 1.0.x 애플리케이션의 상기 클래스들 및 리소스들의 상기 나머지 부분이 저장되는 상기 MHP 1.0.x 애플리케이션의 상기 방송 파일 시스템에서의 위치에 대한 클래스 경로를 정의하는, 시동 시간 감소 방법.
MHP 1.0.x 표준에 기초하여 MHP 애플리케이션들의 시동 시간을 감소시키는 방법에 있어서,

(a) MHP 애플리케이션에 대한 일반 래퍼(GW) 클래스를 생성하는 단계;

(b) 상기 일반 래퍼(GW) 클래스로부터 호출하는 단계로서, 제 1 API는 상기 MHP 애플리케이션의 클래스들 및 리소스들이 저장된 수신기 장치의 지속성 파일 시스템에서의 위치에 대응하는 제 1 URL 검색 경로를 식별하는 제 1 파라미터를 가지며, 상기 제 1 API는 상기 MHP 애플리케이션의 클래스들 및 리소스들이 저장되는 방송 파일 시스템에서의 위치에 대응하는 제 2 URL 검색 경로를 식별하는 제 2 파라미터를 갖는, 상기 호출 단계;

(c) 상기 제 1 API의 제어 하에서, 상기 지속성 파일 시스템에 현재 저장된 상기 MHP 애플리케이션과 관련된 클래스들 및 리소스들을 로딩하는 단계;

(d) 상기 제 1 API의 제어 하에서, 상기 제 2 파라미터를 이용하여 상기 지속성 파일 시스템에 현재 저장되지 않는 상기 방송 파일 시스템으로부터 상기 MHP 애플리케이션과 관련된 임의의 나머지 클래스들 및 리소스들을 로딩하는 단계를 포함하는, 시동 시간 감소 방법.
제 7 항에 있어서,

상기 제 1 API는 DVBClassloader API인, 시동 시간 감소 방법.
제 7 항에 있어서,

(a) 상기 일반 래퍼(GW) 클래스로부터 제 2 API를 호출하는 단계; 및

(b) 상기 방송 스트림에서 상기 지속성 파일 시스템으로 상기 MHP 애플리케 이션과 관련된 파일들 및 디렉토리들을 반복하여 복사하는 상기 호출된 제 2 API로부터 스레드를 시작하는 단계를 더 포함하는, 시동 시간 감소 방법.
제 3 항에 있어서,

상기 제 1 및 제 2 API들은 실질적으로 병렬로 동작하는, 시동 시간 감소 방법.
제 4 항에 있어서,

상기 제 2 API는 지속성 저장장치 API인, 시동 시간 감소 방법.
MHP 1.0.x 표준에 따라 동작하는 집적 수신기 장치에 있어서,

MHP 애플리케이션에 대한 일반 래퍼 클래스를 생성하는 수단;

지속성 파일 시스템에 현재 존재하는 상기 MHP 1.0.x 애플리케이션의 부분을 로딩하는 수단; 및

지속성 파일 시스템에 현재 존재하지 않는 상기 MHP 1.0.X 애플리케이션의 적어도 일부분을 복사하는 수단을 포함하는, 집적 수신기 장치.
제 12 항에 있어서,

상기 복사 수단은 상기 MHP 1.0.x 애플리케이션을 방송하는 방송 스트림에서 상기 지속성 파일 시스템으로 상기 MHP 1.0.x 애플리케이션의 클래스 파일들 및 리 소스들을 복사하는 단계를 더 포함하는, 집적 수신기 장치.
제 12 항에 있어서,

상기 복사 수단은 카피스레드 프로세스의 제어 하에 수행되는, 집적 수신기 장치.
제 14 항에 있어서,

상기 카피스레드 프로세스는 상기 MHP 프로토콜에 정의된 지속성 저장장치 API를 이용하는, 집적 수신기 장치.
제 12 항에 있어서,

상기 로딩 수단은 상기 MHP 프로토콜에 정의된 DVBClassloader API를 이용하는, 집적 수신기 장치.
제 16 항에 있어서,

상기 DVBClassloader API는 상기 MHP 애플리케이션의 클래스 파일들이 저장되는 상기 지속성 파일 시스템에서의 위치에 대한 클래스 경로를 정의하는 적어도 제 1 및 제 2 URL 파라미터를 포함하며, 상기 제 2 URL 파라미터는 상기 MHP 1.0.x 애플리케이션을 방송하는 방송 스트림의 방송 파일 시스템의 파일 시스템에서의 위치에 대한 클래스 경로를 정의하는, 집적 수신기 장치.
MHP 애플리케이션이 MHP 시스템으로부터 Xlet 콘텍스트를 수신하기 전에 상기 MHP 애플리케이션의 구성 ID 및 애플리케이션 ID를 유도하는 방식을 제공하는 방법에 있어서,

일반 래퍼(GW) 클래스에 의해, 상기 MHP 시스템으로부터 모든 현재 알려진 애플리케이션들의 리스트를 수신하는 단계로서, 상기 리스트에서의 각각의 애플리케이션은 관련된 구성 ID 및 애플리케이션 ID를 포함하는, 상기 리스트 수신 단계;

상기 구성 ID 및 애플리케이션 ID를 이용하여 상기 리스트에서의 각각의 애플리케이션을 지속성 파일 시스템에서의 애플리케이션을 식별하는 디렉토리 리스팅으로 변환하는 단계;

상기 GW 클래스에 의해 디렉토리 리스팅들의 각각에 액세스하는 단계;

상기 리스트들로부터의 애플리케이션이 보안 예외를 리턴하지 않는지 결정하는 단계;

상기 보안 예외를 리턴하지 않는 애플리케이션과 같이 상기 결정 단계로부터 상기 구성 ID 및 애플리케이션 ID를 유도하는 단계를 포함하는, 유도 방식 제공 방법.
제 18 항에 있어서,

상기 변환 동작은 지속성 루트/구성 ID/애플리케이션 ID의 형태로 상기 구성 ID 및 상기 애플리케이션 ID를 이용하여 상기 디렉토리 리스팅을 구성하는 단계를 더 포함하는, 유도 방식 제공 방법.