KR20120002625A - 애플리케이션 프로그램 인증 및 실행 방법 - Google Patents

Abstract

종래 기술의 방송파를 통해 다운로드된 프로그램에 대한 기술과는 상이하게, 네트워크를 통해 프로그램을 다운로드하는 경우에, 이러한 프로그램은 프로그램이 부정 변경됨을 인지하지 못하고 동작될 가능성이 있다. 이러한 이유로, 프로그램이 네트워크를 통해 다운로드되는 경우, 서버에 위치한 프로그램에 대한 파일 계층이 단말의 로컬 영역내에 구성된다. 따라서, 로컬 영역내에 구성된 파일 계층에 대해 프로그램의 인증이 수행되고, 프로그램의 신뢰성이 보장된다.

Description

애플리케이션 프로그램 인증 및 실행 방법{METHOD FOR AUTHENTICATING AND EXECUTING AN APPLICATION PROGRAM}

본 발명은 프로그램을 인증하고 실행하며, 다운로드한 프로그램의 신뢰성을 확인하고, 신뢰성이 인증된 프로그램을 실행하는 방법과 관련되어 있다.

디지털 텔레비젼에 있어서의 프로그램을 다운로드하고 그러한 프로그램의 신뢰성 체크/보증하는 기능은 DVB-MHP 규격서 "ETSI TS 101 812 V1.2.1 DVB-MHP 규격서 1.0.2", PCT 국제출원의 일본번역문인 일본특허공표 2002-508624 등 에 기재되어 있다. 이것들은 수신중의 방송파에 중첩된 프로그램이 부정 변경된 것이 아닌지에 대한 검증과, 그러한 프로그램이 신뢰할 수 있는 기관에 의해 발송된 것인지에 대한 검증을 하는 기능을 갖는다. 이에 따라, 디지털 텔레비젼에 데미지를 주는, 원본과 다르게 작동하는 재기입 프로그램, 스푸핑(spoofing)하는 제3 부분에 속하는 프로그램 등이 기동되는 것을 미연에 방지할 수 있다.

이하에서는, 그와 동일한 프로그램의 신뢰성을 확인하는 것을 인증이라고 부르는 것으로 한다.

수신중의 방송파에 중첩된 프로그램과는 별도로, DVB-MHP 규격서 "ETSI TS 101 812 V1.2.1 DVB-MHP Standard 1.0.2"는 인터넷과 같은 네트워크를 통해 다운로드하여 서버내 배치된 프로그램을 검증하는 것도 고려하고 있다.

그러나, 종전의 방송파를 통해 다운로드된 프로그램의 경우와는 달리, 네트워크를 통해 다운로드하는 경우는 보안상의 문제가 발생할 수 있다. 여기서 말하는 보안상의 문제란 프로그램 인증에 사용되는 프로그램을 구성하는 파일(이하 구성파일(configuration file)이라 부른다) 및 프로그램이 단말장치상에서 기동되는 경우 사용되는 프로그램의 구성파일이 하나 또는 모든 파일에 있어서 다르게 되는 가능성이 있다는 것이다. 이것은 단말장치가 서버로부터 프로그램의 구성파일을 다운로드하여 인증한 후, 서버상에 배치된 프로그램의 상기 구성파일이 부정 변경되는 경우를 말한다. 상기 구성파일이 부정 변경되고 난 이후 상기 단말장치로부터 다시 다운로드 받게 되는 경우, 그러한 구성파일로부터 구성된 프로그램은 더 이상 일반적으로 사용될 수 없다.

또한, 잘 알려진 ZIP 파일 형식에 기반한 JAR(Java Archive)이라 불리우는 파일 형식으로 여러 파일을 하나의 파일로 묶는 기술이 존재한다. 그러한 기술을 사용하여, JAR이 사용되기 이전에 비해 파일 크기는 압축되고 다운로드하는 시간이 짧아지게 된다. 그러나, JAR이 서버내 배치된 데이터가 자주 업데이트 되는 경우 JAR이 사용되면, JAR 형식 파일은 데이터가 업데이트 되는 때마다 다시 만들어져야만 한다. 이것은 서버에 부담을 주게 되고, 이것은 바람직하지 않은 경우가 될 수 있다. 예를 들어, 증권 가격 정보를 사용하는 프로그램을 제공하는 서버의 경우 증권 가격에 대한 정보 및 기타 같은 종류의 실시간으로 끊임없는 변화의 범주에 들게 된다.

상기한 문제의 관점에서, 디지털 텔레비젼 등과 같은 인증 장치가 필요하게 되고, 이것이 파일 및 디렉토리가 JAR 형식으로 나타내지는 파일을 사용하지 않고 계층적(hierarchical) 구조로 배열된 서버로부터 네트워크를 통해 다운로드된 프로그램의 신뢰성을 보증한다.

본 발명에서는, 프로그램을 네트워크를 통해 다운로드 할 때, 단말장치의 로컬 영역에 서버상에 배치된 프로그램의 파일 계층(hierarchy)이 구축된다. 또한 본 발명은 로컬 영역내에 구축되는 파일 계층에 대해 프로그램 인증을 수행함으로써 프로그램의 신뢰성을 보증할 수 있는, 프로그램 인증 및 실행 방법을 제공하는 것을 목적으로 한다.

상기 종래의 문제를 해결하기 위해, 본 발명에 따른 프로그램 인증 및 실행 방법은 다음의 단계를 포함하는 프로그램 인증 및 실행 방법이다: i) 프로그램의 저장 위치를 식별하는 정보에 따라 부정 변경(tamper) 체크를 필요로 하는, 디렉토리 구조로 되어 있는, 적어도 하나의 데이터 파일로 구성된 프로그램을 소정의 서버로부터 다운로드하고, ii) 부정 변경 체크를 필요로 하는 상기 다운로드된 데이터 파일을 인증하고, iii) 상기 프로그램을 방송 수신기에 저장하는 인증 및 저장 단계 및 전송 스트림에 검증된 정보 및 네트워크에 연결된 서버 및 인증된 프로그램을 실행하는 실행 단계를 포함한다. 상기 인증 및 저장 단계는: 상기 디렉토리 구조를 구성하는 디렉토리내에 포함된 해시 파일내에 리스트된 디렉토리 및 데이터 파일에 기초하여, 상기 서버내에 저장된 프로그램의 디렉토리 구조와 동일한 디렉토리 구조를 가지도록, 해시 파일내에 리스트된 부정 변경 체크를 필요로 하는 전체 데이터 파일을 방송수신기에 다운로드하는 제1 단계, 2개의 해시 값이 일치하는지 여부를 검증하는 제2 단계 - 일 해시 값은 부정 변경 체크를 필요로 하는 각각의 데이터 파일로부터 연산되며, 다른 해시 값은 상기 데이터 파일을 리스트하는 해시 파일내에 저장됨 ; 상기 프로그램내에 포함된 인증서 파일의 유효성을 검증하는 제3 단계; 복호된 값과 해시 값이 일치하는지 여부를 검증하는 제4 단계 - 상기 복호된 값은 상기 프로그램의 인증서 파일내에 포함된 리프(leaf) 인증서의 공개 키를 이용하여 상기 프로그램내에 포함된 서명 파일의 서명값을 복호함에 의해 얻어지고, 상기 해시값은 상기 프로그램의 최상위 디렉토리내에 위치한 해시 파일로부터 연산됨 ; 및 이하의 모든 것 즉, 상기 제2 단계에서 상기 2개의 해시 값이 일치함이 검증되고; 상기 제3 단계에서 상기 인증서 파일이 유효함이 검증되고; 또한 상기 제4 단계에서 상기 복호된 값과 상기 해시 값이 일치함이 검증되는 것이 모두 만족되는 경우에, 상기 프로그램을 인증하고 상기 인증된 프로그램을 저장하는 제5 단계를 포함한다. 상기 실행 단계는 상기 저장된 프로그램내에 포함된 상기 인증서 파일이 유효한지 여부를 검증하는 검증 단계를 포함하며, 상기 실행 단계에서, 상기 저장된 프로그램은 상기 저장된 프로그램내에 포함된 상기 인증서 파일이 상기 검증 단계에서 유효한 것으로 검증된 경우에만 다시 인증되고 실행된다.

따라서, 로컬 저장 영역내 서버의 것과 동일한 파일 계층을 구조할 수 있고, 신뢰성이 보증될 수 있다. 또한, 성공적인 인증에도 불구하고 서버에서 부정 변경된 프로그램이 방송 수신기에 인스톨되는 것을 막을 수 있다. 또한, 서버에서 부정 변경이 생길지라도, 그러한 프로그램은 정상적으로 방송 수신기내 사용될 수 있다. 게다가 프로그램은 다시 다운로드될 필요는 없고, 그러한 다운로드에 대한 인증은 생략될 수 있다. 이것은 프로그램 활성화를 위해 인증이 완성때까지 기다려야만 하는 사용자에게 편리함을 제공한다. 또한, 본 발명에서는, JAR에서 보여지는 압축된 파일을 사용하지 않고 서버는 파일 계층화의 형식으로 파일을 제공한다. 따라서, 서버가 자주 업데이트되는 데이터를 가진 파일을 포함하는 경우까지도, 매번 업데이트할때 마다 압축된 파일을 다시 만들어야만 하는 서버내의 부담을 줄일 수 있다.

또한, 상기 제3 단계는 2개의 루트(root) 인증서가 일치하는지 여부를 검증하는 제6 단계 - 상기 루트 인증서 중 하나는 상기 프로그램내에 포함된 상기 인증서 파일내에 있으며, 다른 루트 인증서는 상기 방송 수신기내에 위치됨 - 을 포함하며, 상기 제3 단계에서, 상기 인증서 파일은 상기 2개의 루트 인증서가 일치하는 경우에 유효한 것으로 검증된다.

여기서, 상기 제3 단계는 상기 프로그램내에 포함된 상기 인증서 파일내의 각각의 인증서의 유효 기간을 검증하는 제7 단계를 포함하며, 상기 제3 단계에서, 상기 인증서 파일은 상기 2개의 루트 인증서가 일치하고; 또한 상기 인증이 수행된 시간이 상기 인증서 파일내의 각각의 인증서의 유효 기간내에 있는 것 모두가 만족되는 경우에 유효한 것으로 검증된다.

따라서, 일치하지 않는 루트 인증서 또는 유효기간이 이미 만료된 인증서를 가진 프로그램의 저장을 금지하는 것이 가능하다.

또한, 상기 검증 단계는 2개의 루트 인증서가 일치하는지 여부를 검증하는 제8 단계 - 상기 루트 인증서 중 하나는 상기 저장된 프로그램내에 포함된 상기 인증서 파일내에 있으며 다른 루트 인증서는 상기 방송 수신기내에 위치됨 - 를 포함하며, 상기 검증 단계에서, 상기 저장된 프로그램내에 포함된 상기 인증서 파일은 상기 2개의 루트 인증서가 일치하는 경우에 유효한 것으로 검증받을 수 있다.

여기서, 상기 검증 단계는 상기 저장된 프로그램내에 포함된 상기 인증서 파일내의 각각의 인증서의 유효 기간을 검증하는 제9 단계를 포함하며, 상기 검증 단계에서, 상기 저장된 프로그램내에 포함된 상기 인증서 파일은 상기 2개의 루트 인증서가 일치하고, 또한 상기 실행이 수행되는 시간이 상기 인증서 파일내의 각각의 인증서의 유효 주기내에 있는 것 모두가 만족되는 경우에 유효한 것으로 검증된다.

따라서, 일치하지 않는 루트 인증서 또는 유효기간이 이미 만료된 인증서를 가진 프로그램의 실행을 금지시킬 수 있다.

또한, 상기 제2 단계에서 상기 2개의 해시 값이 일치하는 것으로 검증되지 않는 것; 상기 제3 단계에서 상기 인증서 파일이 유효한 것으로 검증되지 않는 것; 및 상기 제4 단계에서 상기 복호된 값과 상기 해시 값이 일치하는 것으로 검증되지 않는 것 중 적어도 하나가 만족되는 경우에는 상기 프로그램은 저장되지 않는다.

따라서, 예를 들어, 서버에서 부정 변경된 프로그램의 저장을 금지할 수 있다.

또한, 상기 제1 단계는 상기 방송 수신기내의 최상위 디렉토리 아래에 해시 파일에 의해 지정된 디렉토리와 동일한 디렉토리를 구성하고, 디렉토리가 서버내에서 상기 프로그램을 구성하는 최상위 디렉토리내에 저장된 상기 해시 파일에 의해 지정되는 경우에, 상기 서버내의 상기 최상위 디렉토리내에 저장된 상기 해시 파일에 의해 지정된 상기 디렉토리내에 저장된 해시 파일에 의해 지정된 부정 변경 체크를 필요로 하는 데이터 파일을 상기 방송 수신기내에 구성된 대응 디렉토리에 다운로드하는 제10 단계를 포함한다.

따라서, 방송 수신기내, 서버와 동일한 파일 계층을 구성하고, 방송 수신기내 구성된 동일한 디렉토리에 부정 변경 확인을 요구하는 데이터 파일을 다운로드 할 수 있다.

또한, 본 발명은 상술한 바대로 프로그램을 인증하고 실행하는 방법으로서 뿐만 아니라, 그러한 방법에서 포함된 특징 단계를 구성 요소로서 갖는, 프로그램 인증 및 실행 장치 및 그러한 특징 단계를 컴퓨터가 실행하도록 하는 프로그램으로 구현될 수 있다. 또한, 그러한 프로그램이 CD-ROM과 같은 레코딩 매체 및 인터넷과 같은 전송 매체를 통해 분배될 수 있는 것은 말할 나위도 없다.

본 발명에서 프로그램을 인증하고 실행하는 방법에 따르면, 로컬 저장 영역내 서버의 것과 동일한 파일 계층을 구성하는 것이 가능하고, 프로그램의 신뢰성은 보증될 수 있다. 또한, 서버에서 부정 변경된 프로그램이 성공적인 인증에도 불구하고 방송 수신기로 설치되는 것을 막는 것이 가능하다. 따라서, 서버내 부정 변경이 있는 경우일지라도, 프로그램은 방송 수신기내에서 정상적으로 사용될 수 있다.

2004년 7월 14일에 출원된 명세서, 도면 및 청구항을 포함하는 미국 가출원(Provisional Application) 60/587511호의 공개는 여기서 전체를 참조하여 병합된다.

본 발명내 프로그램을 인증하고 실행하는 방법은, 로컬 저장영역에, 서버내 동일한 파일 계층을 구성하고 프로그램의 신뢰성을 보증할 수 있고 디지털 텔레비전 수신기에 기능의 향상, 기능의 부가에 유용하다. 또한, 본 발명의 프로그램을 인증하고 실행하는 방법은 디지털 텔레비전에 뿐만 아니라 퍼스날 컴퓨터 및 휴대 전화와 같은 소프트웨어에 의해 제어되는 정보 기기에 기능의 향상 및 기능의 부가와 같은 응용에 적용 가능하다.

본 발명의 이러한 및 다른 목적, 이점 및 형태는 본 발명의 상세한 실시예를 설명하는 첨부한 도면과 함께 제출되는 다음의 기술로부터 명백해질 것이다. 도면에서:
도 1은 본 발명의 제1 실시예에 따른 케이블 텔레비젼 시스템의 구성을 보여주는 도면이다.
도 2는 본 발명에 따른 케이블 텔레비젼 시스템에 있어서 헤드 엔드(head end)와 단말장치 사이의 통신에 사용되는 주파수 대역의 사용법의 일례이다;
도 3은 본 발명에 따른 케이블 텔레비젼 시스템에 있어서 헤드 엔드(head end)와 단말장치 사이의 통신에 사용되는 주파수 대역의 사용법의 일례이다;
도 4는 본 발명에 따른 케이블 텔레비젼 시스템에 있어서 헤드 엔드(head end)와 단말장치 사이의 통신에 사용되는 주파수 대역의 사용법의 일례이다;
도 5는 본 발명에 따른 케이블 텔레비젼 시스템에 있어서 단말장치의 구성을 보여주는 도면이다;
도 6은 본 발명에 따른 케이블 텔레비젼 시스템에 있어서 단말장치의 외관의 일례이다;
도 7은 본 발명에 따른 POD의 하드웨어 구성을 보여주는 도면이다;
도 8은 본 발명에 따른 POD에 저장된 프로그램의 구성을 보여주는 도면이다;
도 9는 MPEG 규격에서 정의된 패킷의 구조를 보여주는 도면이다;
도 10은 MPEG2 전송 스트림의 일례를 보여준다;
도 11은 입력부를 프론트 패널(front panel)의 형태로 구성했을 경우의 외관의 일례이다;
도 12는 본 발명에 따른 단말장치에 저장된 프로그램의 구성을 보여주는 도면이다;
도 13A 및 13B는 본 발명에 따른 디스플레이에 의해 표시되는 디스플레이 스크린의 일례를 보여준다;
도 14는 본 발명에 따른 2차 기억부에 저장된 정보의 일례를 보여준다;
도 15A 에서 15C는 본 발명에 따른 1차 기억부에 저장된 정보의 일례를 보여준다;
도 16은 본 발명에 따른 MPEG2에서 규정하는 PAT의 내용을 보여주는 개략도이다;
도 17은 본 발명에 따른 MPEG2 표준규격에서 규정하는 PMT의 내용을 보여주는 개략도이다;
도 18은 본 발명에 따른 DVB-MHP 표준규격에서 규정하는 AIT의 내용을 보여주는 개략도이다;
도 19는 본 발명에 따른 DSMCC 형식으로 송신되는 파일 시스템을 보여주는 개략도이다;
도 20은 본 발명에 따른 XAIT의 내용을 보여주는 개략도이다;
도 21은 본 발명에 따른 2차 기억부에 저장된 정보의 일례를 보여준다;
도 22A 에서 22C는 본 발명에 따른 파일명 또는 디렉토리명의 해시값을 저장하는 파일의 일례를 보여준다;
도 23은 본 발명에 따른 인증서 체인의 구조를 나타내는 도면이다;
도 24는 본 발명에 따른 X.509 인증서의 구조를 보여주는 도면이다;
도 25는 본 발명에 따른 서명 파일의 구조를 보여주는 도면이다;
도 26은 본 발명에 따른 보안 모듈(module)의 구성요소를 보여주는 도면이다;
도 27은 본 발명에 따른 파일 시스템이 인증받는 경우 수행되는 동작을 보여주는 플로차트이다;
도 28은 본 발명에 따른 인증 지시를 접수하였을 때 인증이 수행되지 않는 경우에 대한 플로차트이다;
도 29는 본 발명에 따른 파일 시스템에 부정 변경 확인을 할 때의 동작을 보여주는 플로차트이다;
도 30은 본 발명에 따른 서명 파일을 사용하여 부정 변경 확인을 할 때 수행되는 동작을 보여주는 플로차트이다;
도 31은 본 발명에 따른 리프(leaf) 인증서 및 중간(intermediate) 인증서 간의 체인 관계가 확인될 때의 동작을 보여주는 플로차트이다;
도 32는 본 발명에 따른 중간 인증서 및 루트 인증서 간의 체인 관계가 확인될 때의 동작을 보여주는 플로차트이다;
도 33은 본 발명에 따른 루트 인증서내 서명이 확인될 때의 동작을 보여주는 플로차트이다;
도 34는 본 발명에 따른 저장된 파일들을 상술하는데 사용되는 파일의 일례를 보여준다;
도 35는 본 발명에 따른 파일 시스템의 인증이 수행될 때의 동작을 보여주는 플로차트이다;
도 36은 본 발명에 따른 인증지시를 접수하였을 때 X.509 인증서의 유효성을 확인할 때의 동작을 보여주는 플로차트이다;
도 37은 본 발명에 따른 다운로드 모듈로부터 수취한 코드 파일의 간단한 구조를 보여주는 도면이다;
도 38A 에서 38C는 본 발명에 따른 단말장치가 소유하는 인증서가 교환되는 것을 보여주는 도면이다;
도 39는 본 발명에 따른 인증서 교환할 때의 동작을 나타내는 플로차트이다;
도 40은 본 발명에 따른 인증 지시를 접수할 때 루트 인증서를 비교할때의 동작을 나타내는 플로차트이다;
도 41은 본 발명에 따른 CRL의 구조를 나타내는 도면이다;
도 42는 본 발명에 따른 CRL중의 실효(revoked) 인증서 리스트를 보여주는 개략도이다;
도 43은 본 발명에 따른 CRL을 포함하는 파일 시스템의 일례이다;
도 44는 본 발명에 따른 CRL의 유효성이 해시값 및 서명값에 기초하여 확인되는 때에 작동을 보여주는 플로차트이다;
도 45는 본 발명에 따른 인증서들중 체인 관계 및 루트인증서간 비교에 기초하여 CRL의 유효성이 확인되는 때 동작을 보여주는 플로차트이다;
도 46은 본 발명에 따른 파일명 또는 디렉토리명의 해시값을 저장하는 파일의 일례를 보여준다;
도 47은 본 발명에 따른 프로그램 저장시에 CRL이 존재하는 경우의 인증을 수행하는 동작을 보여주는 플로차트이다;
도 48은 프로그램 활성화시에 CRL이 존재하는 경우에 인증을 수행하는 동작을 보여주는 플로차트이다;
도 49는 본 발명에 따른 실효 인증서의 데이터베이스를 보여주는 개략도이다;
도 50은 본 발명에 따른 XAIT의 세부사항을 보여주는 개략도이다;
도 51은 본 발명에 따른 네트워크의 연결 패턴을 보여주는 개략도이다;
도 52는 본 발명에 따른 AM의 구성요소 및 관련된 요소를 보여주는 도면이다;
도 53은 본 발명에 따른 파일 계층의 일례이다;
도 54A 및 54B는 본 발명에 따른 파일명 또는 디렉토리명의 해시값을 저장하는 파일의 일례를 보여준다;
도 55는 본 발명에 따른 파일 계층이 로컬 영역에서 구성되고 인증이 수행되는 때의 동작을 보여주는 플로차트이다;
도 56은 본 발명에 따른 XAIT의 세부사항을 보여주는 개략도이다;
도 57은 본 발명에 따른 파일 계층의 일례이다;
도 58A 에서 58C는 본 발명에 따른 파일명 또는 디렉토리명의 해시값을 저장하는 파일의 일례를 보여준다.

여기서부터, 본 발명의 실시예는 도면을 참조하여 설명될 것이다

(제 1 실시예)

본 발명의 케이블 텔레비젼 시스템의 실시예는 도면을 참조하여 설명될 것이다. 도 1은 케이블 시스템을 구성하는 헤드 엔드(101), 세개의 단말장치: 단말장치A(111), 단말장치B(112) 및 단말장치C(113)으로 구성된 장치들 사이의 관계를 나타내는 블록도이고, 본 실시예에서, 세개의 단말장치는 하나의 헤드 엔드와 연결되어 있으나, 임의의 수의 단말장치를 헤드 엔드에 연결하더라도 본 발명은 실시할 수 있다.

상기 헤드 엔드(101)는 복수의 단말장치에 대해 영상, 음성, 데이터 등의 방송신호를 송신하고, 단말 장치로부터 송신된 데이터를 수신한다. 이것을 실현하기 위해, 헤드 엔드(101)와 단말장치A(111), 단말장치B(112) 및 단말장치C(113)사이의 데이터전송에 이용하기 위하여 주파수 대역은 분할되어 사용된다. 도 2는 분할된 주파수 대역의 일례를 보여주는 표이다. 주파수대역은 Out of Band(약칭 OOB)와 In-Band로 나뉜다. 5~130MHz의 주파수 대역이 OOB에 할당되고, 주로 헤드엔드(101)와 단말장치A(111), 단말장치B(112) 및 단말장치C(113)간에 데이터를 교환하기 위해 주로 사용된다. 130MHz~864MHz의 주파수대역은 In-Band에 할당되고 주로 영상 및 음성을 포함하는 방송 채널에 주로 사용된다. QPSK는 OOB에 사용되고, 반면에 QAM64는 변조 기술로서 In-Band에 사용된다. 변조 기술의 상세한 설명은 본 발명과는 별로 관계가 없는 공지된 기술이기 때문에, 여기서는 생략한다. 도 3은 OOB 주파수 대역이 사용되는 방식의 더욱 상세한 예를 보여준다. 70MHz~74MHz의 주파수대역은 단말장치(101)로부터 데이터를 전송하는데 사용된다. 이러한 경우, 단말장치(All1), 단말장치B(112) 및 단말장치C(113)의 모두는 헤드 엔드(101)로부터 같은 데이터를 수취한다. 한편, 10.0MHz~10.1MHz의 주파수 대역은 단말장치A(111)로부터 헤드엔드(101)로 데이터를 전송하는데 사용된다. 10.1MHz~10.2MHz의 주파수 대역은 단말장치B(112)로부터 헤드엔드(101)로 데이터를 전송하는데 사용된다. 10.2MHz~10.3MHz의 주파수 대역은 단말장치C(113)로부터 헤드엔드(101)로 데이터를 전송하는데 사용된다. 따라서, 각각의 단말장치에 고유한 데이터가 단말장치A(111), 단말장치B(112) 및 단말장치C(113)로부터 헤드엔드(101)로 전송될 수 있다. 도 4는 In-Band 주파수 대역의 사용의 일례를 보여준다. 150~156MHz 및 156~162MHz의 주파수 대역은 각각 텔레비젼 채널 1 및 텔레비젼 채널 2에 각각에 할당되고, 이후 주파수는 6MHz의 간격으로 텔레비젼 채널에 할당된다. 310MHz 및 이후의 주파수는 1MHz의 간격으로 라디오 채널에 할당된다. 상기 채널의 각각은 아날로그 방송 또는 디지털 방송용으로 사용될 수 있다. 디지털 방송의 경우, 데이터는 MPEG2 규격에 기초를 둔 이송 패킷 형식으로 전송되고, 이 경우에는 음성 및 영상 데이터에 추가하여 다양한 데이터 방송 시스템을 위한 데이터도 송신할 수 있다.

헤드 엔드(101)는 각각의 주파수 대역에 대해 적절한 방송 신호를 송신하기 위해, QPSK 변조부, QAM 변조부를 갖는다. 또한 헤드엔드(101)는 단말장치로부터 데이터를 수신하게 위해 QPSK 복조부를 갖는다. 또한 헤드엔드(101)는 상기 변조부 및 복조부에 관계된 다양한 장치를 더 갖는다. 그러나 본 발명은 주로 단말장치와 관련되기 때문에, 이것에 대한 상세한 설명은 여기서 생략한다.

단말장치A(111), 단말장치B(112) 및 단말장치C(113)는 헤드엔드(101)로부터 방송신호를 수신하고 재생한다. 또한 단말장치A(111), 단말장치B(112) 및 단말장치C(113)는 헤드엔드(101)에 대하여 각각의 단말장치에 고유한 데이터를 송신한다. 본 실시예에서, 세가지의 단말장치는 동일한 구성을 갖는다.

도 5는 각각의 단말장치의 하드웨어 구성을 보여주는 블록도이다. 단말장치(500)는 QAM 복조부(501), QPSK 복조부(502), QPSK 변조부(503), TS 디코더(505), 음성 디코더(506), 스피커(507), 영상 디코더(508), 디스플레이(509), 2차 저장부(510), 1차 저장부(511), ROM(512), 입력부(513) 및 CPU(514)를 포함한다. 또한 POD(504)는 단말장치(500)으로부터 탈/부착할 수 있다.

도 6은 단말장치(500)의 외관의 일례인 박형 텔레비젼을 보여준다. 단말장치는 다양한 구성으로 실현될 수 있지만, 본 실시예에서, OpenCable(TM) 및 OCAP에 기초해 구성된 단말장치를 예로 들어 설명한다.

박형 텔레비젼의 하우징(601)은 단말장치(500)의 모든 구성요소를 포함하고 POD(504)는 제외한다.

디스플레이(602)는 도 5에 있어 디스플레이(509)에 해당한다.

프론트부(603)는 다수의 버튼으로 구성되고 도 5내 입력부(513)에 해당한다.

신호 입력부(604)는 헤드 엔드(101)과의 송/수신을 하기 위해서 케이블선에 접속해 있다. 또한, 신호입력부(604)는 도 5에서 보여지는 QAM 복조부(501), QPSK 복조부(502) 및 QPSK 변조부(503)에 접속해 있다.

POD카드(605)는 도 5에서 POD(504)에 해당한다. POD(504)는 단말장치(500)와 독립하여 구현되어 있고 도 6의 POD(605)의 경우와 같이, 단말장치(500)에서 탈/부착이 가능하다. POD(504)의 상세한 것은 후술한다.

삽입 슬롯(606)은 POD 카드(605)가 삽입되는 삽입 슬롯이다.

도 5를 참조하여, CPU(514)에 의해 규정된 주파수를 포함하는 튜닝 정보에 따라, QAM 복조부(501)는 헤드엔드(101)에서 QAM-변조되었고 헤드엔드(101)로부터 송신되어 온 신호를 복조하고, 그 결과를 POD(504)에 인도한다.

CPU(514)에 의해 규정된 주파수를 포함하는 튜닝 정보에 따라, QPSK 복조부(502)는 헤드엔드(101)에서 QPSK-변조되었고 헤드엔드(101)로부터 송신되어 온 신호를 복조하고, 그 결과를 POD(504)에 인도한다.

CPU(514)에 의해 규정된 주파수를 포함하는 복조 정보에 따라, QPSK 변조부(503)는 POD(504)로부터 인도된 신호를 QPSK-복조하여 그 결과를 헤드엔드(101)로 송신한다.

도 6에서 보여지는 바, POD(504)는 단말장치(500)의 본체로부터 착탈가능하다. 단말장치(500)의 본체와 POD(504)간의 접속면은 OpenCable(TM) CableCARD(TM) Interface Specification (OC-SP-CC-IF-I15-031121)및 명세서에 정의되어 있다. 그러한 명세서에서 CableCARD는 POD로 일컫는다. 여기서, 상세한 설명은 생략되고 단지 본 발명과 관련된 부분만 설명된다.

도 7은 POD(504)의 내부구성을 보여주는 블록도이다. POD(504)는 제1 디스크램블부(descrambler unit)(701), 제2 디스크램블부(702), 스크램블부(scrambler unit)(703), 1차 저장부(704), 2차 저장부(705) 및 CPU(706)로 만들어져있다.

제1 디스크램블부(701)는, CPU(706)으로부터 지시하에, 단말장치(500)의 QAM 복조부(501)로부터 스크램블된 신호를 수신하여 그러한 신호를 디스크램블한다. 그리고, 제1 디스크램블루(701)은 디스크램블된 신호를 단말장치(500)의 TS 디코더(505)로 송신한다. 키와 같은 디스크램블에 필요한 정보는 필요한 경우 CPU(706)에 의해 주어진다. 즉, 헤드엔드(101)는 몇개의 유료(pay)채널을 방송하고, 사용자가 이러한 유료 채널을 시청할 권리를 구매할때, 제1 디스크램블부(701)은 CPU(706)으로부터의 키와 같은 필요한 정보를 수신하여 디스크램블을 수행하고 사용자는 이러한 유료채널을 시청할 수 있다. 키와 같은 필요한 정보가 주어지지 않는 경우, 제1 디스크램블부(701)는 수신한 신호를 디스크램블하지 않고 바로 TS 디코더(505)로 인도한다.

제2 디스크램블부(702)는, CPU(706)으로부터의 지시하에, 단말장치(500)의 QPSL 복조부(502)로부터 스크램블된 신호를 수신하여, 그러한 신호를 디스크램블한다. 그리고 제2 디스크램블부(702)는 디스크램블된 데이터를 CPU(706)에 인도한다.

스크램블부(703)는, CPU(706)의 지시하에, CPU(706)으로부터 수신한 데이터를 스크램블하여 그 결과를 단말장치(500)의 QPSK 변조부(503)로 보낸다.

구체적으로 RAM과 같은 1차 메모리로 만들어진, 1차 저장부(704)는 CPU(706)가 프로세스를 수행하는 때에 임시적으로 데이터를 저장하는데 사용된다.

구체적으로 플래쉬 ROM과 같은 2차 저장 메모리로 만들어진, 2차 저장부(705)는 CPU(706)에 의해 수행되는 프로그램을 저장하는데 뿐만아니라 전원이 커졌을때조차도 지워지지 않을 데이터를 저장하는데도 사용된다.

CPU(706)는 2차 저장부(705)에 저장된 프로그램을 실행한다. 프로그램은 다수의 서브프로그램으로 만들어진다. 도 8은 2차 저장부(705)에 저장된 프로그램의 일례이다. 도 8에서, 프로그램(800)은 메인프로그램(801), 초기화 서브프로그램(802), 네트워크 서브프로그램(803), 재생 서브프로그램(804) 및 PPV 서브프로그램(805)을 포함하는 다수의 서브프로그램으로 만들어졌다.

여기서 PPV란 Pay PerPiew의 약자로, 영화와 같은 특정한 프로그램을 사용자가 유료로 시청할수 있게하는 서비스를 말한다. 시청자가 그의 개인 확인 번호를 입력하면, 프로그램 시청할 권리의 구매가 헤드엔드(101)에 통지되고 스크램블이 무효화되어, 그러한 프로그램은 사용가자 시청할 수 있게된다. 이러한 시청으로, 사용자는 후일에 구입 대금을 지불할 것이 요구된다.

전원이 켜졌을때 CPU(706)에 의해 최초로 활성화되는 서브프로그램인 메인 프로그램(801)은 다른 서브프로그램을 제어한다.

전원이 켜졌을때 메인프로그램(801)에 의해 활성화되는 초기화 서브프로그램(802)은 단말장치(500)와 정보교환을 하고 초기화를 수행한다. 이러한 초기화 처리는 OpenCable (TM) CableCARD (TM) Interface Specification (OC-SP-CC-IF-I15-031121) 및 명세서에 상세히 정의된다. 즉, 초기화 서브프로그램(802)는 또한 이 명세서에 정의되지 않은 초기화 처리를 수행한다. 여기서, 그러한 초기화 처리의 일부분을 소개한다. 전원이 켜지면, 초기화 서브프로그램(802)은 2차 저장부(705)에 저장된 제1 주파수를 단말장치(500)의 CPU(514)를 통해서 QPSK 복조부(502)에 통지한다. QPSK 복조부(502)는 제공된 제1 주파수를 사용하여 튜닝을 수행하고 그 결과 신호를 제2 스크램블부(702)에 송신한다. 또한, 초기화 서브프로그램(802)은 제2 스크램블부(702)에 2차 저장부(705)에 저장된 제1 키와 같은 디스크램블 정보를 제공한다. 그 결과, 제2 디스크램블부(702)는 디스크램블을 수행하고 그 결과를 초기화 서브프로그램(802)를 수행하는 CPU(706)에 인도한다. 따라서, 초기화 서브프로그램(802)은 정보를 받을 수 있다. 본 실시예에서, 초기화 서브프로그램(802)은 네트워크 서브프로그램(803)을 통해 정보를 수신한다. 상세한 설명은 후술한다.

또한, 초기화 서브프로그램(802)은 2차 저장부(705)가 저장하는 제2 주파수를 단말장치(500)의 CPU(514)를 통해 QPSK 변조부(503)에 통지한다. 초기화 서브프로그램(802)은 2차 저장부(705)내 저장된 스크램블 정보를 스크램블부(703)에 제공한다. 초기화 서브프로그램(802)가 전송이 필요한 정보를 네트워크 서브프로그램(803)을 통해, 스크램블부(703)에 제공할 때, 스크램블부(703)는 제공된 스크램블 정보를 사용하여 데이터를 스크램블하고, 스크램블된 데이터를 QPSK 변조부(503)에 제공한다. QPSK 변조부(503)는 수신한 스크램블된 정보를 변조하고, 그 변조된 정보를 헤드엔드(101)에 인도한다.

그 결과, 초기화 프로그램(802)은 단말장치(500), 제2 디스크램블부(702), 스크램블부(703) 및 네트워크 서브프로그램(803)을 통해 헤드엔드(101)와 쌍방향통신을 수행할 수 있다.

메인 프로그램(801) 및 초기화 서브프로그램(802)과 같은 다수의 서브프로그램에 의해 사용되는 네트워크 서브프로그램(803)은 헤드엔드(101)과 쌍방향통신을 수행하기 위한 서브프로그램이다. 즉, 네트워크 서브프로그램(803)은 네트워크 서브프로그램(803)을 사용하는 다른 서브프로그램이 마치 TCP/IP와 일치하여 헤드엔드(101)과 쌍방향통신을 하는 것처럼 행동한다. TCP/IP는 복수의 장치사이에 정보를 교환할 때 사용되는 프로토콜을 규정하는 공지의 기술이기 때문에, 그에 대한 상세한 설명은 여기서 생략한다. 전원이 켜질때, 초기화 서브프로그램(802)에 의해 활성화되는 경우, 네트워크 서브프로그램(803)은 미리 2차 저장부(705)에 저장되고 POD(504)를 식별하는 식별자인 MAC address(Media Access Control address의 약칭)을 단말장치(500)을 통해 헤드엔드(101)에 통지하여, IP address의 취득을 요구한다. 헤드엔드(101)는 IP address를 단말장치(500)를 통해 POD(504)에 통지하고, 네트워크 서브프로그램(803)은 IP address를 1차 저장부(704)에 저장한다. 이후, 헤드엔드(101) 및 POD(504)는 IP address를 POD(504)의 식별자로 사용하여 각각 통신을 한다.

재생 서브프로그램(804)은 2차 저장부(705)에 저장된 제2 키와 같은 디스크램블 정보 뿐만 아니라 단말장치(500)에 의해 제공되는 제3 키와 같은 디스크램블 정도를 제1 디스크램블부(701)에 제공하여, 디스크램블이 수행되는 것을 허용한다. 또한, 네트워크 서브프로그램(803)을 통해, 재생 서브프로그램(804)은 제1 디스크램블부(701)에 입력된 신호가 PPV 채널이라고 가리키는 정보를 수신한다. 신호가 PPV 채널이라는 것을 통지한 때, 재생 서브프로그램(804)은 PPV 서브프로그램(805)를 활성화한다.

활성화되면, PPV 서브프로그램(805)은 단말장치(500)상에 사용자에게 프로그램을 구입을 재촉하는 메세지를 표시하고 사용자로부터 입력을 받아들인다. 즉, 스크린상에 표시되고자하는 정보가 단말장치(500)의 CPU(514)에 보내질 때, 단말장치(500)의 CPU(514)상에서 동작하는 프로그램이 단말장치(500)의 디스플레이(509)상에 메세지를 표시한다. 그 후, 사용자는 개인 확인 숫자를 단말 장치(500)의 입력부(513)를 통해 입력할 때, 단말장치(500)의 CPU(514)는 그것을 수취하여 그것을 POD(504)의 CPU(706)상에 구동되는 PPV 서브프로그램(805)에 전달한다. PPV 서브프로그램(805)은 수취한 개인 확인 숫자를 네트워크 서브프로그램(803)을 통해 헤드엔드(101)에 전달한다. 그러한 개인 확인 숫자가 유효하면, 헤드엔드(101)는 네트워크 서브프로그램(803)을 통해, 제4 키와 같은 디스크램블에 필요한 디스크램블 정보를 PPV 서브프로그램(805)에 통지한다. PPV 서브프로그램(805)은 제4 키와 같은 수취한 디스크램블 정보를 제1 디스크램블부(701)에 제공하고, 제1 디스크램블부(701)는 입력된 신호를 디스크램블 한다.

도 5를 참고하여, TS 디코더(505)는 POD(504)로부터 수취한 신호에 필터링을 수행하여, 필요한 데이터를 음성 디코더(506), 영상 디코더(508) 및 CPU(514)에 인도한다. 여기서, POD(504)로부터 보내진 신호는 MPEG2 전송 스트림이다. MPEG2 전송 스트림에 대한 상세한 설명은 MPEG 규격서 ISO/IEC138181-1에 주어지고, 따라서 본 실시예에서는 상세한 설명은 생략한다. MPEG2 전송 스트림은 복수의 고정길이 패킷으로 구성되고, 패킷 ID는 각 패킷에 할당된다. 도 9는 패킷의 구조를 보여주는 도면이다. 900은 고정된 길이의 188 bytes에 의해 구성되는 패킷이다. 탑 4 bytes는 패킷을 확인하는 정보를 저장하는 헤더(901)이고, 나머지 184 bytes는 전송되는 정보를 포함하는 페이로드(902)이다. 903은 헤더(901)의 내역(breakdown)이다. 패킷 ID는 탑으로부터 12번째 ~ 24번째 bit의 13 bit에 포함되어 있다. 도 10은 전송되는 복수의 패킷 일렬(string)을 나타내는 개략도이다. 패킷(1001)은 그 헤더에 패킷 ID "1"를 가져, 그의 페이로드내 영상 A의 제1 정보를 포함한다. 패킷(1002)은 그 헤더에 패킷 ID "2"를 가져, 그의 페이로드내 음성 A의 제1 정보를 포함한다. 패킷(1003)은 그 헤더에 패킷 ID "3"을 가져, 그의 페이로드내 음성 B의 제1 정보를 포함한다.

패킷(1004)은 그 헤더에 패킷 ID "1"을 가져, 그의 페이로드내 영상 A의 제2 정보를 포함하고, 패킷(1001)의 연속이다. 유사하게, 패킷(1005, 1026 및 1027)은 다른 패킷의 후속 데이터를 가지고 있다. 위와 동일한 방법으로 같은 패킷 ID를 가진 패킷의 페이로드의 내용을 연결함으로써, 연속된 영상 및 음성을 재생할 수 있다.

도 10을 참고하여, CPU(514)가 출력 방향으로 패킷 ID "1" 뿐만아니라 "영상 디코더(508)"을 TS 디코더에 지시할 때, TS 디코더(505)는 POD(504)로부터 수취한 MPEG2 전송 스트림으로부터 패킷 ID "1"을 가진 패킷을 추출하여, 그들을 영상 디코더(508)에 전달한다. 따라서, 도 10에서 단지 영상 데이터만을 영상 디코터(508)에 인도하게 된다. 동시에, CPU(514)가 패킷 ID "2" 뿐만 아니라 "음성 디코더(506)"를 TS 디코더(505)에 통지할 때, TS 디코더(505)는 POD(504)로부터 수취한 MPEG2 전송 스트림으로부터 패킷 ID "2"를 가진 패킷을 추출하고, 그들을 음성 디코더(506)에 인도한다. 도 10에서는, 단지 음성 데이터만을 영상 디코더(508)에 인도한다.

패킷 ID에 따른 필요한 패킷만을 추출하는 이러한 처리는 TS 디코더(505)에 의해 수행되는 필터링에 해당한다. TS 디코더(505)는 CPU(514)의 지시에서, 하나이상의 필터링 처리를 동시에 실행할 수 있다.

도 5를 참조하여, 음성 디코더(506)는 TS 디코더(505)에 의해 주어진 MPEG2 전송 스트림내 패킷에 매립된 음성 데이터를 연결하여, 연속된 데이터에 디지털-아날로그 변환을 수행하여 스피커(507)에 그 결과를 출력한다.

스피커(507)는 음성 디코더(506)에 의해 제공되는 신호를 음성출력한다.

영상 디코더(508)는 TS 디코더(505)에 의해 제공되는 MPEG2 전송 스트림내 패킷에 매립된 영상 데이터를 연결하고, 연속된 데이터내 디지털-아날로그 변환을 수행하여, 디스플레이(509)에 그 결과를 출력한다.

구체적으로 CRT나 액정등으로 구성되는, 디스플레이(509)는 영상 디코더(508)에 의해 제공되는 영상 신호를 출력하고 CPU(514)에 의해 지시된 메세지를 디스플레이한다.

구체적으로 플래쉬 메모리나 하드 디스크 등으로 만들어진, 2차 기억부(510)는 CPU(514)로부터 지시된 데이터 및 프로그램을 저장하고 삭제한다. 저장된 데이터 및 프로그램은 CPU(514)에 의해 참조된다. 저장된 데이터 및 프로그램은 단말장치의 전원이 절단된 상태라도 저장하기를 계속한다.

구체적으로 RAM 등으로 구성된, 1차 기억부(511)는 CPU(514)로부터 지시된 데이터 및 프로그램을 일시적으로 저장하고 삭제한다. 저장된 데이터 및 프로그램은 CPU(514)에 의해 참조된다. 저장된 데이터 및 프로그램은 단말장치(500)의 전원이 꺼지면 삭제된다.

구체적으로 ROM, CD-ROM 또는 DVD 등으로 만들어진 상기 ROM(512)은 읽을 수만 있는 장치이다. ROM(512)은 CPU(514)에 의해 실행되는 프로그램을 저장한다.

구체적으로 프론트 패널 또는 원격제어(remote control)로 만들어진, 입력부(513)는 사용자로부터 입력을 수취한다. 도 11은 프론트 패널의 형태를 구성하는 경우에 입력부(513)의 일례를 보여준다. 1100은 도 6에서 보여지는 프론트 패널부(603)에 해당하는 프론트 패널이다. 그러한 프론트 패널(1100)은 7개의 버튼으로 만들어졌다: 위-커서 버튼(1101), 아래-커서 버튼(1102), 좌-커서 버튼(1103), 우-커서 버튼(1104), OK 버튼(1105), 무효화-버튼(1106) 및 EPG 버튼(1107). 사용자가 버튼을 누를 때, 그러한 눌려진 버튼의 식별자는 CPU(514)에게 통지된다.

CPU(514)는 ROM(512)에 저장된 프로그램을 실행한다. 실행되는 프로그램의 지시에 따라, CPU(514)는 QAM 복조부(501), QPSK 복조부(502), QPSK 변조부(503), POD(504), TS 디코더(505), 디스플레이(509), 2차 기억부(510), 1차 기억부(511) 및 ROM(512)를 제어한다.

도 12는 ROM(512)에 ROM(512)내 저장되고 CPU(514)에 의해 실행되는 프로그램 구조의 일례를 보여주는 도면이다.

프로그램(1200) 복수의 서브프로그램으로 이루어진다. 즉, 구체적으로 프로그램(1200)은 OS(1201), EPG(1202), JavaVM(1203), 서비스 매니저(1204) 및 Java 라이브러리(1205)로 만들어진다.

OS(1201)는 단말장치(500)에 전원이 켜질때 CPU(514)에 의해 활성화되는 서브프로그램이다. OS(1201)는 operating system을 나타내고, Linux 등의 그 일례이다. OS(1201)는 다른 서브프로그램과 같은 목적의 서브프로그램을 실행하는 커널(kernel)(1201a) 및 라이브러리(1201b)로 만들어진 공지기술의 일반명칭이고, 따라서 상세한 설명은 생략한다. 본 실시예에서, OS(1201)의 커널(1201a)은 서브프로그램으로서 EPG(1202) 및 JavaVM(1203)을 실행한다. 또한, 라이브러리(1201b)는 이러한 서브프로그램에 단말장치(500)의 구성요소를 제어하는데 필요한 복수의 기능을 제공한다.

여기서, 튜닝은 그러한 기능의 일례로 소개된다. 튜닝의 기능에서, 주파수를 포함하는 튜닝 정보는 다른 서브프로그램에서 수취되고 QAM 복호부(501)에 인도된다. 따라서 QAM 복호부(501)이 제공된 튜닝 정보에 기초한 복호를 수행하는 것이 가능하고, POD(504)에 복호된 데이터를 인도할 수 있다. 그 결과, 다른 서브프로그램은 라이브러리(1201b)를 통해 QAM 복호부를 제어할 수 있다.

EPG(1202)는 사용자에게 프로그램 리스트를 디스플레이하는 것 뿐 아니라 사용자로부터 입력을 수취하는 프로그램 디스플레이부(1202a) 및 채널을 선택하는 재생부(1102b)로 만들어졌다. 여기서, EPG는 Electronic Program Guide의 약자이다. EPG(1202)는 단말 장치(500)이 켜지면 활성화된다. 활성화된 EPG(1202)에서, 프로그램 라이브러리부(1202a)는 사용자로부터 단말장치(500)의 입력부(513)을 통해 입력을 기다린다. 여기서, 입력부(513)가 도 11의 프론트 패널의 형태를 취하는 경우, 사용자가 입력부(513)상에 EPG 버튼(1107)을 누를때, CPU(514)는 그러한 EPG 버튼의 식별자로 통지된다. CPU(514)에서 구동되는 서브프로그램이 있는 EPG(1202)의 프로그램 디스플레이부(1202a)는 이러한 식별자를 수취하고 디스플레이(509)상에 프로그램 정보를 보여준다. 도 13A 및 도 13B는 디스플레이(509)상에 표시되는 프로그램 표의 일례를 보여준다. 도 13A를 참고하여, 프로그램 정보는 격자 형태로 디스플레이(509)상에 표시된다. 하나의 열(column)(1301)은 시간 정보를 설명한다. 하나의 열(1302)은 열(1301)에 설명되는 각각의 시간에 따른 시간 주기동안 방송되는 채널명 "Channel 1" 및 프로그램을 설명한다. 프로그램 "News 9"은 9시부터 10시30분까지 방송되고, "영화 AAA"는 10시30분부터 12시까지 "Channel 1"에서 방송된다. 열(1303)은 열(1302)의 경우에서 처럼, 열(1301)에 설명되는 각각의 시간에 따른 시간 주기동안 방송되는 채널명 "Channel 2" 및 프로그램을 설명한다. 프로그램 "영화 BBB"는 9시부터 11시사이에 방송되고, "News 11"은 11시부터 12시까지 방송된다. 1330은 커서이다. 커서(1330)는 프론트 패널(1100)상에 있는 좌-커서(1103) 또는 우-커서(1104)를 누르면 이동한다. 우-커서(1104)가 도 13A에서 설명된 상태로 눌러지면, 커서(1330)는 도 13B에서 보여지는 대로 우측으로 움직인다. 또한, 좌-커서(1103)가 도 13B에서 설명한 상태에서 눌러지면, 커서(1330)는 도 13A에서 보여지는 바대로 왼쪽으로 움직인다.

프론트 패널(1100)상의 OK 버튼(1105)이 도 13A에서 보여지는 상태에서 눌러지면, 프로그램 디스플레이부(1202a)는 재생부(1102b)에 "Channel 1"의 식별자를 통지한다. 또한, 프론트 패널(1100)상에 OK 버튼(1105)이 도 13B에서 보여지는 상태로 눌러진다면, 프로그램 디스플레이부(1202a)는 재생부(1102b)에 "Channel 2"의 식별자를 통지한다.

또한, 프로그램 디스플레이부(1202a)는 헤드엔드(101)에서 1차 저장부(511)에 POD(504)를 통해 표시되는 프로그램 정보를 주기적으로 저장한다. 일반적으로 헤드 엔드로부터 프로그램 정보를 얻는데 시간이 걸린다. 그러나, 입력부(513)의 EPG 버튼(1107)을 누를 때, 1차 저장부(511)내 미리 저장된 프로그램 정보를 표시하는 프로그램을 표시함으로써 프로그램표를 빠르게 표시할 수 있다.

재생부(1102b)는 채널의 수취한 식별자를 사용하여 채널을 생산한다. 채널 식별자 및 채널간의 관계는 채널 정보로서 2차 저장부(510)에 의해 미리 저장된다. 도 14는 2차 저장부(510)내 저장된 채널 정보의 일례를 보여준다. 채널 정보는 표형태로 저장된다. 열(1401)은 채널의 식별자를 기술한다. 열 (1402)는 채널의 이름을 기술한다. 열(1403)은 튜닝 정보를 기술한다. 여기서, 튜닝 정보는 주파수, 전송율, 코딩율 등을 QAM 복조부(501)에 제공하는 값에 의해 표현된다. 열(1404)은 프로그램 수들을 설명한다. 프로그램 수들은 MPEG2 규격에 의해 정의되는 PMTs를 식별하기 위해 사용되는 수들이다. PMT에 관하여는 후술한다. 행(1411~1414)의 각각은 각 채널의 식별자, 채널명 및 튜닝 정보의 세트를 가리킨다. 행(1411)은 "1"은 식별자로, "Channel 1"은 채널명으로, "312MHz"의 주파수는 튜닝 정보로, "101"은 프로그램 수로 포함되는 한 세트를 설명한다. 재생부(1102b)는 채널의 재생을 위해 서비스 매니저로 직접 받아들여진 채널의 식별자를 인도한다.

또한, 재생이 일어나는 동안 사용자가 프론트 패널(1100)에 있는 위-커서(1101) 및 아래-커서(1102)를 누르는 경우, 재생부(1102b)는 입력부(513)으로부터 CPU(514)를 통해 사용자에 의한 그러한 누름에 대한 통지를 받고 재생중인 채널을 다른 것으로 부정 변경한다. 우선, 재생부(1102b)는 1차 저장부(511)에 현재 재생중인 채널의 식별자를 저장한다. 도 15A, 15B 및 15C는 1차 저장부(511)내 저장된 채널의 식별자의 일례를 보여준다. 도 15A는 식별자 "3"을 저장하고 있는 것을 보여주고, 도 14를 참고하여 채널명 "TV 3"이 재생되고 있다는 것이 보여진다. 사용자가 위-커서(1101)를 도 15A에서 도시된 상태로 누른 경우, 재생부(1102b)는 도 14에서 보여지는 채널 정보를 참조하여, 표(table)상의 이전의 채널인 채널명 "Channel 2"를 가진 채널을 새롭게 재생하기 위해 서비스 매니저에게 채널명 "Channel 2"의 채널명을 가진 채널의 식별자 "2"를 인도한다. 동시에, 재생부(1102b)는 식별자를 1차 저장부(511)내 저장된 채널 식별자 "2"로 재기입한다. 도 15B는 그러한 재기입된 채널 식별자를 보여준다. 또한, 사용자가 도 15A에서 도시된 상태에서 아래-커서를 누른 경우, 재생부(1102b)는 도 14에서 보여지는 채널 정보를 참조하여 표상의 다음 채널인 "TV Japan"의 채널명을 가진 채널을 새롭게 재생하기 위해 서비스 매니저에게 채널명 "TV Japan"을 포함하는 채널의 식별자 "4"를 인도한다. 동시에, 재생부(1102b)는 식별자를 1차 저장부(511)에 저장된 채널 식별자 "4"로 재기입한다. 도 15C는 그러한 재기입된 채널의 식별자를 보여준다.

JavaVM(1203)은 Java(TM)언어로 쓰여진 프로그램을 연속적으로 분석하고 실행하는 Java 가상 머신(virtual machine)이다. Java 언어로 쓰여진 프로그램은 하드웨어에 의존하지 않는 byte 코드라로 알려진 중간의(intermediate) 코드로 컴파일된다. Java 가상 머신은 그러한 byte 코드를 실행하는 해석기(interpreter)이다. Java 가상 머신은 byte 코드를 CPU(514)에 의해 해석가능한 실행가능한 형식으로 번역하고 그 결과를 CPU(514)에 인도하며, 그것을 실행한다. JavaVM(1203)은 커널(1201a)에 의해 규정되는 실행되는 Java 프로그램으로 활성화된다. 본 실시예에서, 커널(1201a)은 서비스 매니저(1204)를 실행되는 Java 프로그램으로 규정한다. Java 언어의 상세한 설명은 "Java Language Specification"(ISBN 0-201-63451-1)를 포함하는 많은 서적에 해설되어 있다. 따라서, 그에 대한 상세한 설명은 생략된다. 또한, JavaVM 자체의 동작에 대한 상세한 설명은 "Java Virtual Machine Specification"(ISBN 0-201-63451-X)을 포함하는 많은 책에 해설되어 있다. 따라서, 그에 대한 상세한 설명은 생략한다.

Java언어로 쓰여진 Java 프로그램인 서비스 매니저(1204)는 JavaVM(1203)에 의해 차차 실행된다. 서비스 매니저(1204)는 JNI(Java Native Interface)를 통해 Java 언어로 쓰여지지 않은 다른 서브프로그램을 호출하고 호출되는 것이 가능하다. JNI에 관한 해설은 "Java Native Interface"를 포함하는 많은 서적에 되어 있다. 따라서 여기서 그에 대한 상세한 설명은 생략한다.

서비스 매니저(1204)는 JNI를 통해 재생부(1102b)로부터 채널의 식별자를 받아들인다.

최초에, 서비스 매니저(1204)는 튜너를 요구하기 위해 채널의 식별자를 Java 라이브러리(1205)내 튜너(1205c)로 채널의 식별자를 인도한다. 튜너(1205c)는 튜닝 정보를 얻기 위해 2차 저장부(510)내 저장된 채널 정보를 말한다. 서비스 매니저(1204)는 채널의 식별자 "2"를 튜너(1205c)에 인도하고, 튜너(1205c)는 도 14에서 보여지는 열(1412)를 말하며, 채널에 따라 튜닝 정보 "156MHz"를 얻는다. 튜너(1205c)는 튜닝 정보를 OS(1201)의 라이브러리(1201b)를 통해 QAM 복조부(501)에 인도한다. QAM 복조부(501)는 QAM 복조부(501)에 주어진 튜닝 정보에 따른 헤드 엔드(101)으로부터 보내진 신호를 복조하고, 그 결과 신호를 POD(504)에 인도한다.

다음으로, 서비스 매니저(1204)는 Java 라이브러리(1205)내에 있는 CA(1205b)에 디스크램블을 수행할 것을 요구한다. CA(1205d)는 POD(504)에 OS(1201)내 라이브러리(1201b)를 통해 디스크램블에 필요한 정보를 제공한다. 그러한 제공된 정보에 기초하여, POD(504)는 QAM 복조부(501)에 의해 제공된 신호를 디스크램블하고, 그 결과신호를 TS 디코더(505)에 인도한다.

다음으로, 서비스 매니저(1204)는 Java 라이브러리(1205)내 JMF(1205a)에 채널의 식별자를 제공하여, 영상 및 음성 재생을 요구한다.

최초에, JMF(1205a)는, PAT 및 PMT로부터, 재생되는 영상 및 음성을 규정하기 위해 사용되는 패킷 ID을 취득한다. PAT 및 PMT는 MPEG2 전송 스트림내 포함되는 프로그램 라인업을 보여주는 MPEG-2 규격에 의해 정의되는 표이다. PAT 및 PMT는 MPEG2 전송 스트림내 포함되는 패킷내 페이로드로 음성 및 영상과 함께 송신된다. PAT 및 PMT의 상세한 설명을 위해 명세서를 언급한다. 여기, PAT 및 PMT의 개관만이 주어진다. Program Association Table의 약자인 PAT은 패킷 ID "0"로 패킷으로 송신된다. PAT를 얻기 위해, JMF(1205a)는, TS 디코더(505)에, OS(1201)의 라이브러리(1201b)를 통해 패킷 ID "0" 및 CPU(514)를 가리킨다. 그리고, TS 디코더(505)는 패킷 ID "0"에 기초한 필터링을 수행하고, 그 결과를 CPU(514)에 인도한다. 따라서, JMF(1205a)는 PAT 패킷을 수집할 수 있다. 도 16은 수집된 PAT 정보의 일례를 개략적으로 보여주는 표를 도시하고 있다. 열(1601)은 프로그램 수를 설명한다. 열(1602)은 패킷 ID를 설명한다. 열(1602)에서 보여주는 패킷 ID는 PAT를 얻는데 사용된다. 행(1611~1513)의 각각은 한쌍의 채널의 프로그램 수 및 그에 따른 패킷 ID이다. 여기서, 세 채널이 정의된다. 행(1611)은 한쌍의 프로그램 수 "101" 및 패킷 ID "501"을 정의한다. JMF에 제공되는 채널 식별자를 "2"라 하면, JMF(1205a)는 도 14내 열(1412)을 언급하게 되어, 그러한 채널 식별자에 따른 프로그램 수 "102"를 얻고, 도 16에서 보여지는 PAT내 열(1612)을 언급하게 되고, 프로그램 수 "102"에 따라 패킷 ID "502"을 얻는다. Program Map Table의 약어인 PMT는 PAT에서 규정된 패킷 ID의 패킷으로 송신된다. PMT를 얻기 위해, JMF(1205b)는, TS 디코더(505)에, OS(1201)의 라이브러리(1201b)를 통해 패킷 ID 및 CPU(514)를 지정한다. 여기서 지정되는 패킷 ID는 "502"이다. 또한, TS 디코더(505)는 패킷 ID "502"에 기반한 필터링을 수행하고, 그 결과를 CPU(514)에 인도한다. 따라서, JMF(1205a)는 PMT 패킷을 수집할 수 있다. 도 17은 수집된 PMT 정보의 일례를 개략적으로 보여주는 표를 도시한다. 열(1701)은 스트림 형태를 설명한다. 열(1702)은 패킷 ID들을 설명한다. 각각의 스트림 형태에서 지정한 정보는 열(1702)에서 지정된 패킷 ID를 가진 패킷의 페이로드에 송신된다. 열(1703)은 추가적인 정보를 설명한다. 열(1711~1714)의 각각은 기본적인 스트림이라고 알려진, 전송되는 한쌍의 패킷 ID 및 정보의 형태이다. 한쌍의 스트림 형태 "음성" 및 패킷 ID "5011"인 열(1711)은 음성 데이터가 패킷 ID "5011"을 가진 패킷의 페이로드내 저장된다는 것을 지정한다. JMF(1205a)는, PMT로부터, 재생되는 영상 및 음성의 패킷 ID를 얻는다. 도 17을 참고하여, JMF(1205a)는 열(1711)로부터 음성 패킷 ID "5011"을 얻고, 열(1712)로부터 영상 패킷 ID "5012"를 얻는다.

다음에, JMF(1205a)는 OS(1201)의 라이브러리(1201b)를 통해 TS 디코더(505)에 출력처로서 획득한 음성 패킷 ID 및 음성 디코더(506) 뿐만 아니라 영상 패킷 ID 및 영상 디코더(508)을 제공한다. TS 디코더(505)는 그러한 제공된 패킷 ID들 및 출력처에 기반하여 필터링을 수행한다. 여기서, 패킷 ID "5011"을 가진 패킷은 음성 디코더(506)에 인도되고 패킷 ID "5012"를 가진 패킷은 영상 디코더(508)에 인도된다. 음성 디코더(506)는 제공된 패킷에 디지털-아날로그 변환을 수행하여, 스피커를 통해 음성을 재생한다. 영상 디코더(508)는 제공된 패킷에 디지털-아날로그 변환을 수행하여, 디스플레이(509)에 영상을 표시한다.

마지막으로, 서비스 매니저(1204)는 Java 라이브러리(1205)내 AM(1205b)에 채널 식별자를 제공하여, 데이터 방송 재생을 요구한다. 여기서, 데이터 방송 재생은 MPEG2 전송 스트림내 포함된 Java 프로그램을 추출하고 JavaVM(1203)에 그것을 실행시키는 것을 의미한다. MPEG2 전송 스트림에 Java 프로그램을 매설하는 기술로서, MPEG 규격서 ISO/IEC138181-6에서 설명된 DSMCC로 알려진 방법이 사용된다. DSMCC에 대한 상세한 설명은 여기서 생략한다. DSMCC 방식은 컴퓨터에서 사용되는 디렉토리 및 파일로 구성된 파일 시스템을, MPEG2 전송 스트림내 패킷으로, 인코딩하는 방법을 정의한다. 실행되는 Java 프로그램에 대한 정보는 AIT 형식으로 MPEG2 전송 스트림내 패킷으로 송신된다. AIT는 DVB-MHP 규격(정식으로, ETSI TS 101 812 DVB-MHP 규격서 V1.0.2)의 10장에서 정의되어진 Application Information Table의 약어이다.

우선, AIT를 얻기 위해, AM(1205b)은 JMF(1205a)의 경우와 같이 PAT 및 PMT를 얻고, AIT를 저장한 패킷의 패킷 ID를 획득한다. "2"는 제공된 채널 식별자이고 도 16에서 보여지는 PAT 및 도 17에서 보여지는 PMT가 전송중이라고 한다면, JMF(1205a)와 동일한 절차에 따라, AM(1205b)는 도 17에서 보여지는 PMT를 획득한다. 이후, AM(1205b)은, PMT로부터, 스트림 형식이 "데이터"이고 "AIT"를 추가적 정보로 가지는 기초적인 스트림의 패킷 ID를 추출한다. 도 17에서 보여진 바대로, 열(1713)에서 기초적 스트림은 그러한 기초적 스트림에 해당하고, 따라서 AM(1205b)은 그로부터 패킷 ID "5013"을 얻는다.

AM(1205b)은 TS 디코더(505)에 OS(1201)의 라이브러리(1201b)를 통해 출력처로서 AIT 및 CPU(514)의 패킷 ID를 제공한다. 그리고, TS 디코더(505)는 그러한 제공된 패킷 ID에 기반한 필터링을 수행하고, 그 결과를 CPU(514)에 인도한다. 따라서, AM(1205b) AIT의 패킷을 수집할 수 있다. 도 18은 수집된 AIT 정보의 일례를 개략적으로 보여주는 표이다. 열(1801)은 Java 프로그램의 식별자를 설명한다. MHP 규격에 따라, 이러한 식별자는 Java 프로그램이 단말장치(500)의 보안 매니저(1205f)에 의해 인증되어야 하는 프로그램인지 아닌지 인식하는 출원 ID로서 정의된다. 식별자의 값이 OxO에서 OX3fff의 범위에 있는 경우 인증은 필요하지 않고, 반면에 식별자의 값이 Ox4000에서 Ox5fff의 범위에 있는 경우 인증은 필요하게 된다. 식별자값이 전자의 범위내인 Java 프로그램은 "서명없는 프로그램"이라고 하고, 식별자값이 후자의 범위내인 Java 프로그램은 "서명된 프로그램"이라고 한다. 열(1802)은 Java 프로그램을 제어하는 제어 정보를 설명한다. 제어 정보는 "자동개시", "현재" 및 "끝"을 포함한다. "자동개시"는 단말장치(500)가 자동적으로 프로그램을 신속히 실행하는 것을 의미한다. "현재"는 프로그램이 자동적으로 실행되는 것이 아닌 것을 의미한다. "끝"은 프로그램이 종료하는 것을 의미한다. 열(1803)은 DSMCC 형식으로 Java 프로그램을 포함하는 패킷 ID를 추출하는데 사용되는 DSMCC 식별자를 기술한다. 열(1804)은 Java 프로그램의 프로그램명을 기술한다. 열(1811 및 1812)의 각각은 한 세트의 Java 프로그램에 관한 정보이다. 열(1811)에서 정의되는 Java 프로그램은 한 세트의 식별자 "301", 제어 정보 "자동개시", DSMCC 식별자 "1" 및 프로그램명 "a/TopXlet"이다. 열(1812)에서 정의되는 Java 프로그램은 한 세트의 식별자 "302", 제어 정보 "현재", DSMCC 식별자 "1" 및 프로그램명 "b/GameXlet"이다. 여기서, 이러한 두개의 Java 프로그램은 동일한 DSMCC 식별자를 갖는다. 이것은 두개의 Java 프로그램이 동일한 DSMCC 방식에 따라 인코딩되는 파일 시스템내 포함된다는 것을 가리킨다. 여기서 단지 4개의 정보 아이템은 각각의 Java 프로그램에 기록되나, 다른 정보의 아이템은 있는 그대로 기록된다. 자세한 것은 DVB-MHP 규격서를 참고할 것.

AM(1205b)은 "자동 실행" Java 프로그램을 AIT로부터 찾아, 그에 상응하는 DSMCC 식별자 및 Java 프로그램명을 추출한다. 도 18을 참고하여, AM(1205b)은 열(1811)에서 Java 프로그램을 추출하고, DSMCC 식별자 "1" 및 Java 프로그램명 "a/TopXlet"를 얻는다.

다음으로, AM(1205b)은, PMT로부터, AIT로부터 얻은 DSMCC 식별자를 사용하여 DSMCC 형식으로 Java 프로그램을 저장하는 패킷의 패킷 ID를 얻는다. 즉, AM(1205b)은, PMT로부터, 스트림 형식이 "데이터"이고 추가적인 정보내 DSMCC 식별자가 일치하는 기초적인 스트림내 포함되는 패킷 ID를 얻는다.

여기서, 그러한 DSMCC 식별자가 "1"이고 PMT가 도 17에서 보여지는 것이라고 한다면, 행(1714)내 기초적인 스트림은 상기 조건을 만족시킨다. 따라서, 패킷 ID "5014"는 추출될 수 있다.

AM(1205b)은, TS 디코더(505)에, OS(1201)의 라이브러리(1201b)를 통해 출력처로서 데이터가 DSMCC 형식 뿐만 아니라 CPU(514)내 매립된 패킷의 패킷 ID를 가리킨다. 여기서, 패킷 ID "5014"가 제공된다. 그리고, TS 디코더(505)는 제공된 패킷 ID에 기초한 필터링을 수행하여, 그 결과를 CPU(514)에 인도한다. 따라서, AM(1205b)은 필요한 패킷을 수집할 수 있다. AM(1205b)은 DSMCC 방법에 따라 수집된 패킷으로부터 파일 시스템을 재구성하고, 재구성된 파일 시스템을 1차 저장부(511)에 저장한다. 파일시스템으로서 MPEG2 전송내 패킷으로부터 데이터를 추출하고 추출된 데이털를 1차 저장부와 같은 저장부에 저장하는 방법은 이후엔 다운로드라고 불리운다.

도 19는 다운로드한 파일 시스템의 일례를 보여준다. 도면중, 원은 디렉토리를 나타내고 사각은 파일을 나타내고, 1901은 루트 디렉토디, 1902는 디렉토리 "a", 1903은 디렉토리 "b", 1904는 파일 "TopXlet.class" 및 1905는 파일 "GameXlet.class"이다.

다음에, AM(1205b)은, JavaVM(1203)에, 1차 저장부(511)로 다운로드된 파일 시스템으로부터 추출된 Java 프로그램을 인도한다. 여기서, 실행되는 Java 프로그램명을 "a/TopWlet"이라고 하고, ".class"의 부속물로부터 상기 Java 프로그램명에 야기된 파일 "a/TopXlet.class"는 실행되는 파일이다. "/"는 디렉토리와 파일명 간의 구분문자이고 도 19에서 보여지는 바대로, 파일(1904)는 실행되는 Java 프로그램이다. 다음으로, 보안 매니저(1205f)에게 그러한 Java 프로그램의 인증 수행을 요구할 필요가 없다는 것을 의미하는 Java 프로그램의 식별자를 기술하는 열(1801)은 사인되지 않은 프로그램을 지칭하기 때문에, AM(1205b)은 파일(1904)을 실행되는 JavaVM(1203)에 인도한다.

JavaVM(1203)은 수신된 Java 프로그램을 실행한다.

다른 채널의 식별자를 수신하면서, 서비스 매니저(1204)는 동일한 Java 라이브러리(1205)내 포함되는 각각의 라이브러리를 통해 영상 및 음성의 재생 뿐만 아니라 Java 라이브러리(1205)내 포함되는 각각의 라이브러리를 통해 수행되는 Java 프로그램의 실행을 종결하고, 새롭게 수신된 채널 식별자에 기반한 Jav 프로그램의 실행 뿐만 아니라 영상 및 음성의 재생을 수행한다.

보안 매니저(1205f)는 단말 장치에서 수행되는 프로그램의 신뢰성을 보증하는데 필요하다. 그러한 프로그램이 부정 변경되고 그러한 프로그램이 단말장치내 작동할 수 있다면, 메모리와 같은 단말 장치의 수단은 폐기될 수 있고 단말 장차의 동작은 전체로서 안정적이지 않을 수 있다. 그러한 네트워크로서 수단을 사용하여, 단말 장치내 정보가 임의로 전송되는 것이 가능하다. 보안 매니저(1205f)는 그와 같은 일이 발생하지 않기 위해 프로그램의 신뢰성 및 신용성을 확인한다. 그러한 인증기능을 제공하는 보안 매니저(1205f)의 상세는 후술될 것이다.

Java 라이브러리(1205)는 ROM(512)내 저장된 복수의 Java 라이브러리의 집합이다. 본 실시예에서, Java 라이브러리(1205)는 JMF(1205a), AM(1205b), 튜너(1205c), CA(1205d), POD Lib(1205e), 보안 매니저(1205f), 다운로드 모듈(1206) 등을 포함한다.

보안 매니저(1204) 및 다운로드 모듈(1206)은 Java 라이브러리(1205)내 포함되는 POD Lib(1205e)를 통해 헤드엔드(101)과 쌍방향통신을 수행한다. 이러한 쌍방향통신은 OS(1201) 및 POD(504)의 라이브러리(1201b)를 통해 QPSK 복조부(502) 및 QPSK 변조부(503)를 사용하여 POD Lib(1205e)에 의해 실현된다.

다운로드 모듈(1206)은 이러한 통신을 통해 헤드엔드(101)로부터 코드 데이터를 수신할 수 있다. 코드 데이터는 단말장치(500)의 X.509 인증서 및 펌웨어를 포함하는 두성분의(binary) 데이터를 가리킨다. 도 37은 본 발명과 관련된 부분만을 설명하는 코드 데이터를 보여주는 개략도이다. 코드 데이터(37)을 수신할 경우, 다운로드 모듈(1206)은 포함되어 있는 경우 루트 인증서(371)를 추출하고, 그것을 보안 매니저(1205f)에 인도한다. 372는 그러한 펌웨어로서 다른 데이터를 가리킨다.

AM(1205b)은 헤드엔드(101)로부터, 단말장치(500)이 2차 저장부(510)내 저장하고 있는 Java 프로그램, Java 프로그램 활성 장치, 활성화되는 프로그램명 등에 대한 정보를 수신한다. 그러한 정보는 XAIT 정보라 불리운다. XAIT 정보는 헤드엔드(101) 및 POD(504) 사이에 임의의 형태로 전송된다. XAIT에 필요한 정보를 포함하고 있는한, 전송형식이 무엇이든 간에 본 발명은 실시 가능하다.

도 20은 헤드엔드(101)로부터 얻어지는 XAIT 정보의 일례를 개략적으로 보여주는 표이다. 열(2001)은 Java 프로그램의 식별자를 설명한다. 열(2002)은 Java 프로그램을 제어하는 제어 정보를 설명한다. 제어 정보는 "자동개시" 및 "현재"를 포함한다. "자동개시"는 단말장치(500)이 전원이 들어올 경우 자동적으로 실행되는 것을 의미하고, "현재"는 프로그램이 자동적으로 실행되는 것이 아닌 것을 의미한다. 열(2003)은 DSMCC 형식으로 Java 프로그램을 포함하는 패킷 ID를 추출하는데 사용되는 DSMCC 식별자를 기술한다. 열(2004)은 Java 프로그램의 프로그램명을 기술한다. 열(2005)은 Java 프로그램의 우선순위를 기술한다. 열(2011 및 2012)의 각각은 각각의 Java 프로그램에 대한 한 세트의 정보이다. 열(2011)내 정의된 Java 프로그램은 한 세트의 식별자 "Ox4001", 제어 정보 "자동개시", DSMCC 식별자 "1" 및 프로그램명 "a/PPV1Xlet"이다. Java 프로그램이 사인된 프로그램이라는 것은 Java 프로그램 출원 ID로부터 알 수 있다. 여기서, 단지 5개의 정보 아이템만이 각각의 Java 프로그램으로 규정되어 있으나, 더 많은 정보의 아이템이 정의될 지라도 본 발명은 실시가능하다.

XAIT 정보를 받아들이면, AM(1205b)은 AIT 정보로부터 Java 프로그램을 다운로드하는 것과 동일한 절차에 따라, 1차 저장부(511)내 MPEG2 전송 스트림으로부터 파일 시스템을 보유하고, Java 프로그램을 저장하는 지시가 XAIT 정보내 주어지는 경우, 2차 저장부(510)에 그것을 저장한다. 1차 저장부(511)에 보유하고 2차 저장부(510)에 저장하는 하는 동안, 다운로드 파일 저장 위치는 XAIT 정보와 관련된다.

도 21은 서로 관련된 1차 저장부(511) 및 2차 저장부(510)에 저장된 XAIT 정보 및 다운로드 파일 시스템의 일례를 보여준다. 여기서, OCAP 규격서 "OpenCable (TM) Application Platform Specification OCAP 1.0 Profile (OC-SP-OCAP1.0-I11-040604)"에 정의된 파일은 일례로서 설명된다. 도 20에서와 같은 도 21의 구성요소는 서로 같고, 따라서 그러한 구성요소의 설명은 생략된다. 열(2101)은 다운로드된 파일 시스템의 저장위치를 저장한다. 도 21에서, 그러한 저장위치는 화살표로 가리켜진다. 2110은 탑 디렉토리(2111), 디렉토리 "a"(2112), 디렉토리 "b"(2113), 파일 "PPV1Xlet.class"(2114), 파일 "PPV2Xlet.class"(2115), 파일 "ocap.hashfile"(2116~2118), 파일 "ocap.certificates.1"(2119) 및 파일 "ocap.signature.1"(2120)이 포함되어 있는 파일 시스템이다.

파일(2116~2118)은 파일명 또는 디렉토리명 및 해시값이 포함되어 있는 해시 파일이다. 도 22A 내 221, 도 22B 내 222, 및 도 22C 내 223은 각각 "ocap.hashfile"(2116), "ocap.hashfile"(2117), 및 "ocap.hashfile"(2118)의 상세를 나타내는 개략도이다. "/" 디렉토리(2111)내 존재하는 221의 "ocap.hashfile"은, 열(2211)내, 동일한 디렉토리(2111)에 존재하는 "ocap.certificates.1" 파일(2119), "ocap.signaturefile.1" 파일(2120), "a" 디렉토리(2112), 및 "b" 디렉토리(2113)를 포함한다. 열(2212)은 해시 알고리즘이 열(2213)에서 설명되는 각각의 값을 계산하는데 사용되는 것을 가리킨다. 열(2211)내 파일 또는 디렉토리와 관련된 열(2213)은 열(2212)에서 규정한 해시 알고리즘의 사용으로 계산되는 해시값을 포함한다. 현재, 주로 사용되는 해시 알고리즘은 SHA1(Secure Hash Algorithm 1) 및 MD5(Message Digest 5)이다. 이것은 임의적 길이를 가진 데이터를 고정길이 바이트값으로 전환하는 공개된 알고리즘이다. 이는 다음의 특징을 가지고 있다: 전환된 이후에 원래의 데이터를 예상하는 것은 불가능하다; 그리고 그들은 파일이 손상을 입거나 부정 변경되는지 체크하는데 사용된다. 한편, 해시값은 해시 알고리즘의 사용에 의해 발생된 유사 난수(pseudo random number)이다. 해시 알고리즘이 SHA1인 경우, 해시값의 길이가 20바이트이고 반면에, 해시 알고리즘이 MD5인 경우, 해시값의 길이는 16바이트로 전환된다. SHA1 및 MD5에 대한 상세를 위해, "FIPS-PUB 186-2 Secure Hash Standard" 및 "IETF RFC1321"를 참고한다. 여기서, 열(2211)에 설명되는 각각의 방향 "a" 및 "b"에 해당하는 해시값은 각각 "a"디렉토리에서 존재하는 "ocap.hashfile" 파일(2117) 및 "b" 디렉토리에서 존재하는 "ocap.hashfile" 파일(2118)에서 계산되는 SHA1 해시값이다.

211내 "ocap.hashfile"의 경우와 같이 222내 "ocap.hashfile"은 동일한 디렉토리(2112)내 존재하는 "PPV1Xlet.class" 파일(2114)의 파일명, 해시 알고리즘 및 해시값을 포함한다. 유사하게, 동일한 디렉토리(2113)내 존재하는 파일명, 해시 알고리즘 및 "PPV2Xlet.class" 파일(2115)의 해시값을 포함한다.

여기서, 본 발명과 관련된 유일한 특성이 설명되고, 그리하여 OCAP 규격서 "OpenCable (TM) Application Platform Specification OCAP 1.0 Profile (OC-SP-OCAP1.0-IF-I09-031121)"는 "ocap.hashfile"의 상세한 구조에 관해 참고될 것이다.

파일(2119)은 인증서 체인이다. 도 23은 "ocap.certificates.1" 파일(2119)의 상세한 구조를 보여주는 도면이다. "ocap.certificates.x"(x는 정수)의 전형적 구조를 도시하는 231은 루트 인증서(2311), 중간 인증서(2312) 및 리프 인증서(2313)를 포함한다. 예를 들어, 루트 인증서(2311)의 홀더는 중간 인증서(2312)를 발행하고 중간 인증서(2312)의 홀더는 리프 인증서(2313)를 발행하는 체인 관계이다. OCAP 규격서에 따르면, 서명파일 "ocap.signaturefile.x"와 관련된 인증서체인은 동일한 값 "x'를 가진 "ocap.certificates.x"이다. 도 21의 경우, "ocap.signaturefile.1"에 대응하는 인증서 체인은 "ocap.certificates.1"이다. 또한, 루트 인증서(2311), 중간 인증서(2312) 및 리프 인증서(2313)는 동일한 X.509 인증 형식내 구성된다. X.509 인증서는 ITU-T의 추천을 통해 인증서 표현형식에서 사실상 규격으로서 정보 및 통신 산업내 다양한 분야에서 광범위하게 사용된다. 도 23에서, 단지 3개의 인증서가 도시되어 있으나, 다수의 중간 인증서가 존재하는 경우가 있다. 그러나 이러한 경우, 이러한 중간 인증서는 서로 관련된 묶여진 상태에서 존재하여야 한다.

도 24는 X.509 인증서의 구조를 보여주는 도면이다. 여기서, 본 발명을 설명하기에 필요한 특성이 도시되어 있다. X.509 인증서에 대한 세부를 위해, IETF RFC3280 "Internet X.509 Public Key Infrastructure Certificate and CRL Profile"를 참조한다. 241은 X.509 인증서의 특성 영역을 지시하고 242는 X.509 인증서의 서명값을 지시한다. 인증번호(2411)는 인증서를 식별하는 번호를 가리키고, 서명 알고리즘(2412)은 서명값(242)을 결정하는데 사용되는 알고리즘을 가리키고, 금회 업데이트 일시(2413)는 이러한 X.509 인증서가 유효하게 되는 경우 일시를 가리키며, 다음회 업데이트 일시(2414)는 이러한 X.509 인증서가 만료하는 경우 일시를 가리키고, 발행자명(2415)은 이러한 X.509 인증서를 발행하는 권한을 가진자의 이름을 가리키고, 주제명(2416)은 이러한 X.509 인증서의 홀더를 가리키고, 공개키(2417)는 주제명(2416)의 공개키를 가리키고, 서명값(242)은 이러한 X.509 인증서의 발행자의 비밀 키로 사인된(복호된) 값을 가리킨다. 공개 키 및 비밀 키를 사용하는 시스템으로서, 비밀 키 암호체계는 전자 상거래 등에 사용된다. 공개 키 암호체예에서, 암호화된 텍스트는 평문(plaintext)을 암호화 하는데 사용되는 키와 다른 키로 복호된다. 암호화 키 및 복호 키는 다르기 때문에, 복호 키로부터 암호화 키를 예상하는 것은 불가능하다. 암호화 키는 비밀 키에 해당하고 복호 키는 공개 키에 해당한다. 공개 키 암호화 체계의 전형적인 예는 RSA(Rivest-Shamir-Adleman) 및 DSA(Digital Signature Standard)이다.

파일(2120)은 서명 파일이다. 도 25는 "ocap.signaturefile.1" 파일(2120)을 보여주는 개략도이다. 251은 X.509 인증서가 관련된 식별을 위한 인증서 식별서를 가리키고, 252는 해시 서명 알고리즘을 가리키고, 253은 252에 가리키는 해시 서명 알고리즘의 사용에 의한 "ocap.hashfile"(2116)으로 계산되는 서명값을 가리킨다.

Java 프로그램이 2차 저장부(510)에 저장되는 경우, 단말장치(500)에 전원의 종료와 같은 것을 야기하기 때문에 Java 프로그램이 1차 저장부(511)로부터 삭제되는 경우일지라도, AM(1205b) 도 20에서 보여지는 XAIT를 수신하는 한 다운로드를 기다릴 필요없이 Java 프로그램을 활성화할 수 있다.

도 20에서, 프로그램 "/a/PPV1Xlet"의 제어 정보(2002)는 "자동개시"이다. 그리하여, 도 21에 2011에서, "/a/PPV1Xlet"에 해당하는 파일 시스템의 위치(2101)에 탐색이 되고 그리하여 파일(2114)가 JavaVM(1203)에 인도되는 경우, 그러한 ㅍ파일 시스템에 저장된 va 프로그램 "PPV1Xlet"는 활성화된다. 또한, Java 프로그램의 활성화 이전에, AM(1205b)은 Java 프로그램 식별자(2001)의 값을 확인하고 그것이 사인된 프로그램인지 아닌지 판단한다. 그것이 사인된 프로그램이라면, 보안 매니저(1205f)는 인증을 수행하도록 지시된다.

다음으로, 인증을 수행하는 보안 매니저(1205f)의 설명이 행해진다.

파일을 인증하는 AM(1205B)에 의해 지시되는 경우, 보안 매니저(1205f)는 그것이 사인되었는지 아닌지를 판단하기 위해 Java 프로그램 식별자(2001)의 값을 확인한다. 여기서, Java 프로그램이 사인된 프로그램이기 때문에, 보안 매니저(1205f)는 "/" 디렉토리 미만의 파일 시스템의 인증을 행한다. 파일 시스템을 검정하기 위해, 도 21에서 도시되는 ocap.hashfiles(2116 ~ 2118), the ocap.certificates.1(2119), 및 the ocap.signaturefile.1(2120)을 사용함으로써 인증이 수행된다.

도 26은 파일 시스템의 인증을 수행하는 보안 매니저(1205f)의 구성요소를 보여준다.

통지수령부(261)는 AM(1205b)로부터 파일 인증 장치를 수령하는 것 뿐만 아니라 판단부(262)에 그러한 지시를 통지하는 것이 의도된다.

판단부(262)는 인증 결과를 판단한다. 해시 계산부(263)가 해시값을 수신하는 파일 시스템을 위해 해시 계산을 하는 것이 필요하다. 판단부(262)는 "ocap.hashfile" 파일내 존재하는 해시값(2213, 2223, 및 2233)으로부터 비교되는 값을 추출하고 그것이 수신한 해시값이 일치하는지 아닌지를 확인한다. 그들이 일치하지 않는다면, 판단부(262)는 부정변경이 있다는 판단을 하고 인증은 실패로 종결한다.

또한, 판단부(262)는 인증서 추출부(265)를 사용하여 X.509 인증서 각각을 추출하고, 현재 시간이 X.509 인증서의 각각의 이번 업데이트 일시(2413) 및 다음번 업데이트 일시(2414) 사이에 존재하는지를 판단한다. 현재 일시는 OS(1201)의 라이브러리(1201b)로부터 얻는다. 만약 유효기간이 "금회 업데이트 일시 < 현재 일시 < 다음회 업데이트 일시"를 만족하지 않는다면, 판단부(262)는 인증 실패라는 판단을 한다.

또한, 인증서 체인을 인증하기 위해, 판단부(262)는 해시 계산부(263)이 X.509 인증서 각각의 특성 영역(241)에 해시 계산을 수행할 것을 요구한다. 그리고, 서명값 복호부(264)가 X.509 인증서의 각각에 포함되는 서명값(242)을 복호하기 위해 계산을 할 것을 요구하고, 인증 체인의 상태를 확인하기 위해 결과의 복호된 값을 해시 계산부에 의해 얻어진 해시 값과 비교한다. 그들이 일치하지 않는다면, 인증서는 체인관계에 있지 않다는 것을 의미하고 그리하여 인증은 실패로 판단된다. 또한, 그러한 값이 일치되고 인증서가 체인관계에 있다고 검증되는 경우, 인증서 체인내 루트 인증서가 단말장치(500)의 2차 저장부(510)에 포함되는지 확인된다. 만약 포함되지 않는다면, 불가능이라는 판단과 비교하여, 판단부(262)는 인증이 실패라는 판단을 한다.

판단부(262)는 다음의 모든것을 만족하는 경우 인증 성공의 판단을 한다: (1) 부정 변경이 없다; (2) 유효 기간이 있다; (3) 인증서가 체인관계이다; (4) 루트 인증서가 일치된다.

판단부(262)에 의해 파일의 각각의 해시값을 계산하도록 요구되는 경우, 해시 계산부(263)는 그들을 위해 해시 계산을 수행하기 위해 파일의 각각을 OS(1201)의 라이브러리(1201b)로부터 추출하고, 판단부(262)에 결과값을 인도한다. 또한, 해시 계산부(263)는 인증서 추출부(265)로부터 인증서 체인(231)내 X.509 인증서의 각각을 얻고, 그들 각각의 특성 지역(241)을 위해 해시 계산을 수행한다.

서명값 복호부(264)는 판단부(262)에 의해 X.509 인증서 또는 "ocap.signaturefile.x"의 각각의 서명값을 복호하는 계산을 수행할 것을 요구된다. 각각의 X.509 인증서의 서명을 복호하는 계산을 수행하는 경우, 서명값 복호부(264)는 인증서 추출부(265)로부터 인증서 체인(231)내 X.509 인증서의 각각을 얻고, 그들 각각의 서명을 복호하기 위한 계산을 수행하여, 그 결과를 판단부(262)에 반환한다.

인증서 추출부(265)는 판단부(262), 해시 계산부(263) 및 서명값 복호부(264)에 의해 인증서 체인(231)내 X.509 인증서의 각각을 추출하도록 요구되고, X.509 인증서를 추출하여 반환한다.

도 27은 파일 시스템의 인증을 수행할 때, 보안 매니저 보안 매니저(1205f)에 의해 동작을 요약한 플로차트이다. 이 플로차트에 기반하여, 파일 시스템이 도 21에서 보여주는 구성을 가지는 경우 실행되는 동작에 대한 설명이 주어진다. AM(1205b)으로부터 파일시스템에 대한 인증 지시를 통지할 때(단계 S271), 보안 매니저(1205f)는 파일 시스템의 탑-레벨 "/" 디렉토리보다 하위의 파일 시스템에 대한 부정 변경 확인을 수행한다(단계 S272). 부정 변경 확인시, 해시값들을 비교하여, 파일 시스템의 각 디렉토리에 존재하는 파일에 손상이나 부정 변경이 없는 것이 검증된다.

도 29 및 도 30는 단계 S272의 상세한 플로차트이다. 우선, 단계 S291에 도시된 바와 같이, "/" 디렉토리에 존재하는 각각의 파일 "ocap.certificates.1" 및 "ocap.signaturefile.1" 및 각각의 디렉토리 "a" 및 "b"로 해시값이 계산된다. 디렉토리 "a" 및 "b"의 해시값은 각각 "/a/ocap.hashfile"file(222) 및 "/b/ocap.hashfile"file(223)로부터 계산된다. 단계 S293에서, 단계 S292에서 계산된 해시값들이 "/ocap.hashfile" 내의 2213에 기재된 해시값들의 각각과 비교된다. 단계 S294에서, 계산된 해시값들 중 어떠한 것이 2213내 해시값과 다른 경우, 부정 변경된 것으로 판단한다(단계 S297). 한편, 계산된 해시값 중 전부가 2213에서 해시값과 일치하는 경우, 단계 S295로 전이가 행해진다. 단계 S295에서, 부정 변경 확인이 완료되지 않은 서브디렉토리가 존재하는지의 여부가 확인된다. 현 단계에서, 디렉토리 "a" 및 "b"는 "/" 디렉토리의 서브디렉토리로서 존재하며, 이들에 대해서는 아직 부정 변경 확인가 실행되지 않았다. 따라서, 이들 디렉토리 "a" 및 "b"에 대해 부정변경 확인이 실행될 필요가 있다. 우선, 단계 S296내 "a" 디렉토리에 주목하고, 여기에서 "/" 디렉토리에 대해 실행된 것과 등가의 프로세스가 실행된다. "a" 디렉토리에 대한 부정 변경 확인이 완료된 후에, "b" 디렉토리에 대한 부정 변경 확인이 실행된다. 디렉토리 "a" 및 "b"에 대한 부정 변경 확인이 완료되었을 때, "/" 디렉토리에 주목하여 도 30의 단계 S301에 대한 프로세스가 실행된다. 단계 S301에서, 리프 인증서(2313)가 인증서 체인(231)인 "/ocap.certificate.1" 파일(2119)로부터 추출된다. 그 후, 단계(S302)에서, 공개키(2417)가 추출된 리프 인증서(2313)로부터 취해진다. 이어서, 단계(S303)에서, "/ocap.hashfile" 파일(221)의 해시값이 계산된다. 한편, 단계(S304)에서, "/ocap.certificate.1" 파일(2119) 내의 리프 인증서(2313) 내에 존재하는 공개키(2417)를 사용하여, "/ocap.signaturefile.1" 파일(2120) 내의 서명값(242)에 대해 복호가 실행된다. 단계 S305에서, 서명값을 복호함으로써, 단계(S303)에서 계산된 해시값이 단계(S304)에서 획득된 값과 동일한지의 여부가 확인된다. 이들 계산된 값이 일치하는 경우, "/" 디렉토리보다 하위의 파일 시스템이 부정 변경되지 않았다고 판단할 수 있다(단계 S306). 한편, 계산된 값들이 일치하지 않는 경우, 파일 시스템이 부정 변경된 것으로 판단할 수 있다(단계 S307). 탑-레벨 "/" 디렉토리에서 시작하여 내림차순으로 서브디렉토리를 향해 부정 변경 체크가 실행되는 일례에 대해 설명하였지만, 본 발명은 이것에 한정되는 것은 아니다. 따라서, 최하위 레벨 디렉토리에서 시작하여 오름차순으로 최상위 레벨 디렉토리를 향해 프로세스가 실행될 수도 있다. 상기 프로세스들을 통해, 도 27의 단계(S272)의 결과가 획득된다.

단계(S273)에서, 단계(S272)에서의 결과가 "부정 변경이 있음"일 때, 인증이 실패한 것으로 판단되고, 그러한 사실에 대한 통지가 이루어지며(단계 S279), 그 후 프로세스가 종료된다. 단계(S272)의 결과가 "부정 변경 없음"일 때, 단계(S274)에 대한 프로세스가 실행된다.

다음에, 도 31 내지 도 33을 참조하여, 인증서 체인 인증(단계 S274)에 대하여 상세히 설명한다. 중간 인증서(2313) 및 리프 인증서(2313)에 대한 확인이 먼저 실행된다고 하면, 그에 대한 플로차트는 도 31에 도시된다. 먼저, 중간 인증서(2312) 및 리프 인증서(2313)가 인증서 체인(231)로부터 추출된다(단계 S311). 그러한 추출된 리프 인증서(2313)로부터, 금회 업데이트 일시(2413), 다음회 업데이트 일시(2414) 및 발행자명(2415)이 추출된다(단계 S312). 그들 중에서, 현재 일시가, 그 동안 인증서가 유효한 상태로 유지될 수 있는 동안, 금회 업데이트 일시(2413) 및 다음회 업데이트 일시(2414) 사이에 있는지의 여부가 판단된다(단계 S313). 인증서가 유효한 상태로 유지될 수 있는 기간을 현재 일시가 초과하는 경우, 인증서 체인에 대한 인증이 실패로 종료한다(단계 S319). 한편, 현재 일시가 인증서의 유효 기간 내에 있는 것으로 판단될 때, 중간 인증서(2312) 내의 주제명(1416) 및 공개키(2417)가 추출되고(단계 S314), 중간 인증서(2312)의 주제명(2416)과 리프 인증서(2313)의 발행자명(2415) 사이의 비교가 행해져서, 중간 인증서(2312)와 리프 인증서(2313)가 체인 관계에 있는지의 여부를 판단한다(단계 S315). 이들 인증서가 체인 관계에 있지 않은 경우, 인증서 체인의 인증은 실패이다. 한편, 그들 사이에 체인 관계가 있을 때, 리프 인증서(2313)의 특성 영역(241)에 대한 해시값이 계산된다(단계 S316). 또한, 리프 인증서(2313) 내의 서명값(242)은 중간 인증서(2312)의 공개키(2417)로 복호된다(단계 S317). 단계(S316 및 S317)가 완료될 때, 각각의 단계에서 획득된 해시값과 복호된 서명값이 일치하는지 아닌지가 확인된다(단계 S318). 그들 값이 일치하지 않는 경우, 인증서 체인의 인증은 실패로 종료한다(단계 S319).

다음으로, 루트 인증서(2311)와 중간 인증서(2312) 사이의 확인이 실행된다. 도 32는 이 프로세스를 도시하는 플로차트이다. 루트 인증서(2311)와 중간 인증서(2312)는 인증서 체인(231)으로부터 추출되고(단계 S321), 중간 인증서(2312) 및 리프 인증서(2313)에 대해 실행된 확인과 등가인 프로세스가 루트 인증서(2311)와 중간 인증서(2312)에 대해 실행된다(단계 S322∼단계 S328).

단계 S328에서 상기 값들이 일치한다고 판단될 때, 루트 인증서(2311)에 대해서만 확인이 실행된다. 도 33은 루트 인증서(2311)에 대해서만 실행되는 확인을 도시하는 플로차트이다. 단계 S321에서 추출된 루트 인증서(2311)로부터, 금회 업데이트 일시(2413), 다음회 업데이트 일시(2414) 및 발행자명(2415)이 추출된다(단계 S331). 그들 중에서, 현재 일시가, 그 동안 인증서가 유효한 상태로 유지될 수 있는, 금회 업데이트 일시(2413)와 다음회 업데이트 일시(2414) 사이에 있는지의 여부가 판단된다(단계 S332). 현재 일시가 인증서가 유효한 상태로 유지될 수 있는 기간을 초과한 경우, 인증서 체인의 인증은 실패로 종료한다. 한편, 현재 일시가 인증서의 유효 기간 내에 있다고 판단될 때, 루트 인증서(2311)의 특성 영역(241)에 대한 해시값이 계산된다(단계 S334). 또한, 루트 인증서(2311) 내의 서명값(242)은 루트 인증서(2311)의 공개키(2417)로 복호된다(단계 S335). 단계 S334 및 단계 S335가 완료될 때, 각각의 단계에서 획득된 해시값과 복호된 서명값이 일치하는지 아닌지가 확인된다(단계 S336). 그들 값이 일치하는 경우, 인증서 체인의 인증은 성공이지만(S337), 그들 값이 일치하지 않는 경우, 인증서 체인의 인증은 실패로 종료한다(단계 S338). 이 점에서, 단계 S274의 프로세스가 종료한다.

프로세스는 S274의 결과에 따라 단계 S275에서 상이하게 실행된다. 단계 S274의 결과가 "인증서 체인의 인증 실패"일 때, 인증이 실패한 것으로 판단되고 그에 대한 통지가 행해지며(단계 S279), 그 후 파일 시스템에 대한 인증이 종료된다. 한편, "인증서 체인의 인증 성공"의 경우에, 단계 S276의 프로세스가 실행된다.

다음으로, 단말 장치(500)의 2차 저장부(510)는 "/ocap.certificate.1" 파일(2119)의 루트 인증서(2311)와 동일한 인증서를 탐색한다(단계 S276). 동일한 인증서가 2차 저장부(510) 내에 존재하지 않을 때, 단계 S277에서 인증서 체인(231)의 인증이 실패한 것으로 판단되고, 이러한 인증 실패에 관한 통지가 행해지며(단계 S279), 그 후 프로세스는 종료된다. 한편, 루트 인증서(2311)가 포함될 때, 파일 시스템의 인증이 성공한 것으로 판단되고, 이러한 인증 성공에 관한 통지가 AM(1205b)에 행해진다(단계 S278). 도 28을 참조하면, 그 후 Java 프로그램 인증 통지가 수신될지라도(단계 S281), 프로세스는 실행되지 않고 종료된다. 이것은 Java 프로그램의 인증이 이미 수행되었고, 이 시점에서 인증이 필요하지 않기 때문이다.

또한, "application description file"이 파일 시스템내 존재하는 경우, 저장 통지가 XAIT 정보내 신호되는 때, 그안에 기재된 파일은 저장될 것이다. OCAP 규격에 따르면, 예를 들어, "application description file"은 XML(eXtensible Markup Language) 포맷으로 기재된다. 도 34는 "application description file"의 일례를 도시한다.

(제2 실시예)

파일 시스템에 포함된 Java 프로그램(PPV1Xlet.class(2114) 또는 PPV2Xlet.class(2115))이 그러한 파일 시스템이 저장된 후 일정 기간 동안 활성화될 때, "/ocap.certificate.1" 파일(2119)에 포함된 X.509 인증서 중 하나의 유효기간이 만료될(즉, Java 프로그램의 활성화 일시＞다음회 업데이트 일시(2414)) 수 있다. 이미 만료된 X.509 인증서가 인증 체인(231)내 포함된다 할지라도, 이전 설명이 Java 프로그램이 활성화되는 것을 허용하기 때문에, Java 프로그램을 활성화하는 시기에, 인증서 체인(231)내 포함되는 인증서(2311, 2312 및 2313)의 각각의 유효기간이 만료되지 않는 것을 검증하는 기술이 또한 존재한다. 도 26은 구성성분을 도시한다. 그러한 기술에 필요한 구성성분(261-265)은 이미 제1 실시예에 기술되어 있고, 따라서 그의 설명은 여기서 하지 않는다.

플로차트로서, 도 27의 플로차트는 도 35의 플로차트로 대체되고, 도 36의 플로차트가 추가된다.

도 35를 참조하면, 파일 시스템이 저장되기 직전에 실행되는 프로세스들(단계 S351 내지 단계 S357)은 제1 실시예에서 설명된 프로세스들(단계 S271 내지 단계 S277)과 동일하므로, 그 설명을 생략한다. 만일 인증이 실패되지 않은 경우, 프로세스는 도 36에 도시된 플로차트로 진행한다. 일정 기간 후에 Java 프로그램인 PPV1Xlet.class(2114)가 활성화될 것이라는 통지의 수취 시에(단계 S361), 각각의 X.509 인증서, 즉, 루트 인증서(2311), 중간 인증서(2312) 및 리프 인증서(2313)가 "ocap.certificate.1" 파일(2119)로부터 추출된다(단계 S362). 그 후, 추출된 X.509 인증서는 리프 인증서에서 시작하여 루트 인증서까지의 순서로 하나씩 선택되고(단계 S363), 현재 일시가 각각의 X.509 인증서의 금회 업데이트 일시(2413)와 다음회 업데이트 일시(2414)의 사이에 있는지의 여부를 확인한다(단계 S364). 현재 일시가 금회 업데이트 일시(2413) 및 다음회 업데이트 일시(2414) 사이에 있지 않다면, 인증이 실패한 것으로 판단되고 그러한 사실에 관한 통지가 행해진다(단계 S367). 다른 경우에는, 모든 X.509 인증서에 대해 확인가 실행되었는지 아닌지가 확인된다(단계 S365). 모든 X.509 인증서에 대해 확인가 완료되지 않았다면, 프로세스는 S363으로 복귀되어, 후속 프로세스들이 반복된다. 한편, 모든 X.509 인증서가 단계 S365에서 미리 확인된 경우, 인증이 성공한 것으로 판단되고, 이 인증 성공에 관한 통지가 행해지며(단계 S366), 그 후 프로세스가 종료된다. 도 36의 플로차트에 도시된 프로세스들을 추가함으로써, 유효 기간이 만료된 Java 프로그램이 활성화되지 않도록 인증 실패를 AM(1205b)에 통지할 수 있게 된다. 보안 매니저(1205f)에 의해 인증 실패를 통지했을 때, AM(1205b)은 그러한 Java 프로그램을 JavaVM(1203)에 인도하지 않고 활성화를 중지한다.

(제3 실시예)

상기 설명한 바와 같이, 2차 저장부(510)는 인증서 체인(231) 내의 루트 인증서(2311)와 비교되는, 루트 인증서인 X.509 인증서를 포함한다. 2차 저장부(510)에 저장된 루트 인증서는 인증서의 신뢰성이 해킹 등으로 인해 저하되는 경우를 대비하여 새로운 X.509 인증서로 교환된다(이하 인증서 교환라고 한다). 새로운 X.509 인증서는 헤드 엔드(101)로부터 단말 장치(500)에 전송되어, 다운로드 모듈(106)을 통해 보안 매니저(1205f)에 송달된다.

도 38A 내지 38C는 보안 매니저(1205f)에 의해 교환(인증서 교환)된 2차 저장부(510) 내의 루트 인증서를 도시하는 도면이다. 이 경우에는, 인증서 A(381)가 교환될 오래된 인증서이고, 인증서 B(382)가 새로운 인증서이다. 도 38A의 38-1은 인증서 교환이 실행되기 전의 2차 저장부(510)에 저장된 인증서를 도시하고, 도 38B의 38-2는 교환되는 중의 인증서를 도시하며, 도 38C의 38-3은 인증서 교환이 실행된 후의 2차 저장부(510)에 저장된 인증서를 도시한다.

이전 설명에서는, Java 프로그램이 저장된 후에 인증서 교환이 실행될 때에도, Java 프로그램의 활성화 시에 새로운 인증서를 고려하지 않았다. 예를 들어, 인증서 체인(231) 내의 루트 인증서(2311)는, 보안 매니저(1205f)가 그 인증 통지에 응답하여 Java 프로그램을 인증 중일 때, 인증서 A(3811)와 일치하고, 보안 매니저(1205f)는 인증서 A(3811)가 인증서 B(3812)로 교환된 후에 Java 프로그램의 인증 통지를 수신한다고 한다. 이 시점에서, 2차 저장부(510)는 인증서 체인(231) 내의 루트 인증서(2311)와 일치하는 인증서를 포함하지 않으며, 이것은 그러한 인증서가 신뢰할 수 없다는 것을 의미한다. 그러나, 이전의 설명에서, Java 프로그램의 활성화 직전에 루트 인증서들간의 비교가 행해지지 않기 때문에(즉, 인증서 체인(231) 내의 루트 인증서(2311)가 인증서 B(3812)와 비교되지 않기 때문에), 인증 실패에 관한 통지가 AM(1205b)에 행해지지 않는다. 그 결과, AM(1205b)은 Java 프로그램이 활성화되게 한다.

그러므로, Java 프로그램 활성화 시에 인증서 교환을 고려하여 루트 인증서의 비교를 실행하는 기술이 존재한다.

도 26은 그러한 기술의 구성요소를 도시한다. 구성요소들(261∼265)은 이미 설명하였으므로 그 설명은 생략한다. 인증서 교환부(266), 인증서 교환 특정부(267) 및 인증서 수신부(268)가 추가된다.

인증서 교환 특정부(267)가, 수신된 인증서보다 더 오래된 인증서가 2차 저장부(510)에 저장되어 있다고 판단했을 때, 인증서 교환부(266)는 그러한 오래된 인증서를 새로운 인증서로 교환한다. 한편, 인증서 교환 특정부(267)가 오래된 인증서가 저장되지 않았다고 판단할 때, 인증서 교환부(266)는 새로운 인증서를 2차 저장부(510)에 저장한다.

인증서 교환 특정부(267)는 인증서 수신부(268)에 의해 수신된 인증서를 수신한다. 그 후, 인증서 교환 특정부(267)는 OS(1201)의 라이브러리(1201b)를 사용하여, 수신된 인증서보다 더 오래되고 발행자가 동일한 인증서가 있는지를 확인하기 위해 2차 저장부(510)에 저장된 인증서를 체크한다.

인증서 수신부(268)는 다운로드 모듈(1206)이 헤드 엔드(101)로부터 새로운 인증서를 수신할 때, 새로운 인증서를 수신한다. 인증서의 수신 시에, 인증서 수신부(268)는 인증서를 인증서 교환부(266) 및 인증서 교환 특정부(267)에 인도한다.

또한, 도 39 및 도 40이 도 35의 플로차트에 이어서 추가된다.

도 39는 인증서 교환을 실행할 때의 플로차트인 한편, 도 40은 인증서 교환이 실행된 후에 Java 프로그램을 활성화할 때의 플로차트이다. 도 39를 참조하면, 인증서 교환의 요구가 수신될 때(단계 S391), 그러한 수신된 인증서의 발행자명이 추출된다(단계 S392). 교환될 필요가 있는 오래된 인증서가 단말 장치(500)의 2차 저장부(510)에 존재하는지의 여부가 체크되고(단계 S393), 오래된 인증서가 존재할 때만, 그러한 인증서가 삭제된다. 그 후, 수신된 인증서가 2차 저장부(510)에 저장된다(단계 S395). Java 프로그램의 활성화 통지가 일정 기간 후에 수신될 때(단계 S401), 인증서 체인(231) 내의 루트 인증서(2311)와 일치하는 인증서를 2차 저장부(510)에서 탐색하며(단계 S402), 일치하는 인증서가 존재하면(단계 S403), 인증이 성공한 것으로 판단되고 그러한 사실에 관한 통지가 행해진다(단계 S404). 일치하는 인증서가 존재하지 않으면(단계 S403), 인증이 실패한 것으로 판단되고, 그러한 사실에 관한 통지가 행해진다(단계 S405). 단계 S404에서 인증이 성공한 것으로 판단하기 전에, 인증서 체인 내의 각각의 X.509 인증서가 "금회 업데이트 일시＜현재 일시＜다음회 업데이트 일시"를 충족시키는 것을 검증한 후에 인증이 성공한 것으로 결론지을 수도 있다.

또한, 루트 인증서들이 일치하는지를 체크하는 것에 부가하여, S402 이전에, 인증서 체인 내의 인증서들이 체인 관계에 있는지 아닌지를 확인하기 위해, 도 31∼도 33에 도시된 체크를 실행한 후에 인증이 성공인지 실패인지를 판단하는 것도 가능하다.

더욱이, 상기 설명은 교환되어야 하는 인증서가 발행자명에 기초하여 특정되는 경우에 대해 설명하였지만, 인증서는 주제명과 같은 다른 특성값에 기초하여 특정될 수도 있다.

(제4 실시예)

파일 시스템에 포함된 Java 프로그램(PPV1Xlet.class(2114) 또는 PPV2Xlet.class(2115))이 그러한 파일 시스템이 저장된 후 일정 기간 동안 활성화될 때, "/ocap.certificate.1" 파일(2119)에 포함되는 X.509 인증서 중 어느 하나의 유효 기간이 만료된 것 및 루트 인증서가 교환된 것과 다른 이유로 인증서가 무효화된 경우가 있다. 이러한 구성으로 인해 무효화된 인증서가 존재할 때에도 Java 프로그램이 활성화될 수 있다.

여기에서, CRL(Certificate Revocation List)은 인증서를 무효화하는 것으로 공지되어 있다. 도 41은 CRL의 구성을 도시하는 도면이다. 여기에서는, 본 발명을 설명하는데 필요한 속성만이 도시되어 있다. CRL의 상세한 설명을 위해, IETF RF C3280 "Internet X.509 Public Key Infrastructure Certificate and CRL Profile"을 참조하라. 411은 CRL의 특성 영역을 나타내고, 412는 서명값(413)의 서명 알고리즘을 나타내며, 413은 CRL의 서명값을 나타낸다. 발행자명(4111)은 이 CRL의 발행자를 나타내고, 금회 업데이트 일시(4112)는 CRL이 유효로 될 때의 일시를 나타내며, 다음회 업데이트 일시(4113)는 CRL의 유효 기간이 만료할 때의 일시를 나타내고, 무효화된 인증서 리스트(4114)는 무효화된 X.509 인증서에 관한 정보를 나타낸다. 도 42는 무효화된 인증서 리스트(4114)의 구성을 도시하는 도면이다. 본 발명을 설명하는데 필요한 속성만이 여기에도 도시되어 있다. 복수의 무효화된 X.509 인증서에 관한 정보가 무효화된 인증서 리스트(4114)에 저장된다. 도 42의 경우에는, 무효화된 "인증서 A"(421)에 관한 정보로서, 인증서를 고유하게 식별하는 일련 번호(4211) 및 "인증서 A"(421)가 무효화될 때의 일시(4212)가 포함된다. 다른 무효화된 리스트들은 421과 등가이다.

도 43은 CRL을 포함하는 파일 시스템의 구성의 일례이다. "/" 디렉토리(431), "a" 디렉토리(432), "SimpleXlet.class" 파일(433), "ocap.hashfile" 파일(434∼435), "ocap.certificate.1" 파일(436), "ocap.signaturefile.1" 파일(437), "ocap.crl.2" 파일(438) 및 "ocap.certificate.2" 파일(439)이 내부에 저장된다. CRL을 포함하지 않는 파일 시스템의 인증은 제1 실시예에서 설명한 바와 같다. 따라서, 본 실시예에서는 그러한 파일의 인증서 체인인 "ocap.certificate.2" 파일(439) 및 CRL 포맷으로 구성되어 있는 "ocap.crl.2" 파일(438)에 초점을 맞춘다. OCAP 규격에 따르면, "ocap.crl.x"의 인증서 체인은 "ocap.certificate.x"이다. 도 43의 경우에는, "ocap.crl.2"의 인증서 체인은 "ocap.certificate.2"이다.

도 46은 "ocap.hashfile" 파일(434)을 도시하는 개략도이다. 461은 ocap.hashfile(434)의 세부를 나타낸다. "/" 디렉토리(431) 내에 존재하는 461의 ocap.hashfile은 동일한 디렉토리(431) 내에 존재하는 "ocap.certificate.1" 파일(436), "ocap.signature.1" 파일(437), "a" 디렉토리(432), "ocap.crl.2" 파일(438) 및 "ocap.certificate.2" 파일(439)의 각각에 관련된 해시값들을 포함한다.

도 44는 CRL의 인증을 설명하기 위한 플로차트이다. 이하의 설명은 파일 시스템이 도 43에 도시된 구성을 갖는 일례에 대한 설명이다. 우선, 금회 업데이트 일시(4112) 및 다음회 업데이트 일시(4113)가 CRL로부터 추출되고(단계 S441), 현재 일시가 금회 업데이트 일시(4112) 및 다음회 업데이트 일시(4113) 사이에 있는지의 여부가 체크된다(단계 S442). 그렇지 않은 경우, 이 CRL은 무효라고 판단된다(단계 S447). 현재 일시가 그들 일시 사이에 있으면, "ocap.crl.2" 파일(438)의 서명값을 검증하기 위해 속성 영역(411)의 해시값이 계산된다(단계 S443). 동시에, 리프 인증서(2313)의 공개키(2417)가 인증서 체인인 "ocap.certificate.2" 파일(439)로부터 추출되고(단계 S444), "ocap.crl.2" 파일(438)의 서명값(413)이 추출된 공개키(2417)로 복호된다(단계 S445). 그 후, 단계 S443에서 획득된 해시값이 단계 S445에서 획득된 복호값과 동일한지의 여부가 확인된다(단계 S446). 그들 값이 동일하지 않으면, CRL이 무효라고 판단된다(단계 S447). 그들 값이 동일하면, 도 45를 참조하여, 인증서 체인인 "ocap.certificate.2" 파일(439)에 대한 인증이 실행된다(단계 S451). 인증서 체인을 인증하는 방법은 도 31 내지 도 33에 도시된 것과 동일하므로, 여기에서 설명하지 않는다. 이어서, 인증서 체인의 인증이 성공인지의 여부가 판단되고(단계 S452), 인증이 실패이면, 이 CRL은 무효인 것으로 판단된다(단계 S456). 한편, 인증이 성공이면, 2차 저장부(510)에서 루트 인증서와 동일한 인증서를 탐색한다(단계 S453). 여기에서, 일치하는 루트 인증서가 존재하지 않으면, 인증이 실패이고 이 CRL은 무효라고 판단되지만(단계 S456), 일치하는 루트 인증서가 포함되면, 인증이 성공이고 CRL은 유효하다고 판단된다(단계 S455).

이하 인증서가 CRL에 따라 무효화됨에도 불구하고 Java 프로그램이 활성화되는 문제점에 대한 해결법을 설명한다. 이를 뒷받침하기 위해, 본 실시예는, Java 프로그램의 활성화 통지가 행해질 때, Java 프로그램을 인증하는데 사용된 인증서가 CRL 내의 무효화된 인증서인지의 여부를 판단하는 기술이 존재한다.

도 26은 그러한 기술의 구성요소를 보여준다. 일부 추가가 행해진 262와 아직 설명하지 않은 269를 제외하고, 상술한 구성요소들에 대해서는 설명하지 않는다.

CRL을 인증할 수 있는 판단부(262)는 인증서 무효화 특정부(269)에 CRL에 의해 무효화될 인증서를 특정하도록 요구한다. 그 후, 통지 수신부(261)가 인증서 무효화 특정부(269)에 의해 특정된 무효화된 인증서에 관련된 Java 프로그램에 인증 통지를 수신할 때, 판단부(262)는 인증이 실패인 것으로 판단한다. 한편, 통지 수신부(261)가 판단부(262)가 CRL을 인증하는데 실패하였으므로 그러한 CRL이 무효라고 판단한 상태로 Java 프로그램에 인증 통지를 수신할 때, 판단부(262)는 인증이 성공이라고 판단한다.

판단부(262)가 CRL의 인증이 성공하였다고 인식할 때, 인증서 무효화 특정부(269)는 인증서 추출부(265)에 의해 추출된 X.509 인증서 중 하나가 무효화된 인증서라고 특정한다.

플로차트로서, 도 47 및 도 48이 추가된다. 이하 이들 플로차트에 따라 설명을 행한다. 도 21에 도시된 파일 시스템 인증 통지가 지금 행해지고, 도 35의 플로차트에 도시된 프로세스가 개시되며, 단계 S357의 프로세스가 적당한 때에 완료된다고 한다. 도 43에 도시된 다른 파일 시스템에 인증 통지가 그후 수취된다고 하면, 도 44의 플로차트에 도시된 프로세스의 완료 후에 단계 S471 내지 단계 S477이 실행된다. 단계 S471 내지 단계 S477의 프로세스들은 단계 S351 내지 단계 S357의 프로세스들과 동일하다. 단계 S478에 도달했을 때, "ocap.crl.2" 파일(438)의 인증(도 44 및 도 45의 플로차트)이 성공이면, 그러한 파일에 포함되는 무효화된 인증서에 관한 정보가 무효화된 인증서의 데이터베이스에 기입된다. 도 49는 무효화된 인증서의 데이터베이스를 도시하는 개략도이다. 발행자명이 열(491)에 저장되고, 인증서 일련 번호가 열(492)에 저장되며, 무효 일시가 열(493)에 저장된다. 여기에서, "PPV1Xlet.class"(2114)에 인증 통지가 수취될 때(단계 S481), "ocap.certificate.1" 파일(2119)의 인증서 체인(231)에 포함되는 X.509 인증서 중 어느 하나가 무효화된 인증서의 데이터베이스에 포함되는지의 여부가 체크된다(단계 S483). 해당하는 인증서가 있으면, 인증이 실패라고 판단하고 이에 관한 통지가 행해진다(단계 S486). 한편, 해당하는 인증서가 존재하지 않을 때, 전체 인증서 체인에 대해 체크가 실행되고(단계 S484), 인증이 성공인 것으로 판단하는 통지가 행해진다(단계 S485). 상기 프로세스를 통해, 검증 시에 파일의 인증서가 유효였으나 Java 프로그램이 활성화되었을 때까지 CRL에 의해 무효화되는 파일 시스템에 대해 파일의 인증이 실패라는 판단으로, 활성화되지 않아야할 Java 프로그램이 활성화되는 문제를 해결할 수 있다.

Java 프로그램에 인증 통지가 수신될 때, 각 디렉토리에 위치하는 "ocap.hashfile"을 사용하여, 파일 시스템의 트리 구조가 정확한지의 여부를 확인하기 위해 검증을 더 실행할 수도 있다.

또한, 간략하기 위한 목적으로 인증서 체인 내에는 하나의 중간 인증서만 존재하지만, 복수의 중간 인증서가 존재할 수도 있다. 그러나, 그 인증 체인의 인증이 실행될 때, 모든 중간 인증서들 간에 체인 관계이어야 한다.

또한, 이하의 프로세스는 언급한 순서로 설명하였지만, 본 발명은 그러한 순서: 부정 변경의 존부의 확인; 인증서 체인의 인증; 및 2차 저장부가 인증서 체인 내의 루트 인증서와 동일한 루트 인증서를 포함하는지를 확인하기 위한 체크의 순서에 한정되는 것은 아니다.

또한, 파일 시스템의 저장에 관하여, 보안 매니저(1205f)는 OS의 라이브러리(1201b)를 사용하여 파일 시스템을 저장할 수도 있다. 또한, 제1 내지 제4 실시예는, 파일 시스템의 최상위 디렉토리 "/"에 "application description file"이 제공되고 그 콘텐츠로서 파일 시스템의 일부만이 저장될 파일로 나타나는 경우에도 적용 가능하다. 따라서, 저장될 파일만이 취급되면 문제가 발생하지 않는다.

또한, 저장 대상으로서 프로그램들을 설명하였지만, 프로그램 이외의 데이터가 저장 대상이 될 수도 있고, 이것은 제1 내지 제4 실시예가 데이터에도 적용 가능한 것을 의미한다.

또한, 하나 이상의 "ocap.certificate.x"가 "ocap.signaturefile.x"에 대응할 가능성이 있으며, 이 경우에 적어도 하나의 "ocap.certificate.x" 파일의 인증이 성공되는 것이 필요하다.

또한, 인증서 체인의 일례로서 "ocap.certificate.x"가 제시되고, 해시값을 갖는 파일의 일례로서 "ocap.hashfile"이 제시되며, "/" 디렉토리 내의 "ocap.hashfile"가 부정 변경되었는지의 여부를 체크하는 파일의 일례로서 "ocap.signaturefile.x"가 제시되어 있지만, 본 발명은 이들 파일명에 한정되는 것은 아니다.

또한, 인증 실패의 경우에, 인증은 다시 다운로드한 후에 실행될 수도 있다.

(제 5 실시예)

이러한 관점에서, 방송파로부터 Java 프로그램을 다운로드 하는 경우가 설명되었다. 이후, 인터넷에 의한 네트워크를 통해 프로그램을 다운로드하는 경우 인증에 대해 설명될 것이다.

네트워크를 통해 Java 프로그램을 다운로드 하는 것은 DVB-MPH 규격서 "ETSI TS 101 812 V1.2.1 DVB-MHP standard 1.0.2" 및 OCAP 규격서 "OpenCable (TM) Application Platform Specification OCAP 1.0 Profile (OC-SP-OCAP1.0-I11-040604)"에서 고려된다. 동시에서, 공지된 ZIP 파일 포멧에 기초한 JAR(Java Archive)이라 불리는 파일 포멧으로 다수의 파일을 하나로서 함께 묶는 기술이 존재한다. 그러한 기술을 사용하여, JAR이 사용되지 않던 때에 비해, 파일 크기가 작아져 다운로드 하는 시간이 단축된다. 그러나, JAR이 서버에 위치하는 데이터가 자주 업데이트 되는 경우에 사용되는 경우, 데이터가 업데이트 되는 때마다 파일이 JAR 포멧으로 다시 만들어져야 할 필요가 있다. 이것은 서버에 부담을 주게되고 바람직하지 않은 경우이다. 예를 들어, 증권 가격 정보를 사용하는 프로그램을 제공하는 서버의 경우 증권 가격 정보 및 이와 유사한 실시간의 변화로서 이러한 범주내 포함된다. 여기서부터, JAR을 사용하지 않고, 파일 및 디렉토리가 서버내 계층적 구조를 가진 경우에 집중하겠다.

단말 장치가 네트워크를 통해 서버로부터 다운로드 하는 경우에도, 다운로드 될 프로그램이 사인된 프로그램이라면, 프로그램을 구성하는 파일이 보증되는 것을 검증할 필요가 있다. 또, 프로그램을 구성하는 파일은 프로그램이 실제 인스톨되고 활성화되는 경우에 필요로한다. 그러나 인증과 인스톨(또는 프로그램의 활성화)의 시간 사이에 서버로부터 다운로드하는 경우, 만약 단말이 인증을 완료한다 해도, 서버내 프로그램이 인스톨되는 동안 다운로드되는 시간까지 부정 변경될 수 있는 가능성이 있다. 그리하여, 그러한 문제를 극복하는 발명이 여기서 설명된다.

도 50은 AIT 또는 XAIT를 개략적으로 보여주는 표를 설명하고 있다. 도 20과 비교하여, 열(5003)은 상이하고 열(5006)은 추가된다. 그와 별도로, 열(5001 내지 5005)은 도 20에서 열(2001 내지 2005)와 각각 동일한 의미를 가진다. 그러나 열(5003)은 값이 "1"인 경우, 이전에 설명된 DSMCC 식별자이고, 값이 "2"인 경우 IP 네트워크를 통해 Java 프로그램의 다운로드를 지칭하는 IP 식별자이다. 열(5004)은 Java 프로그램의 프로그램명을 설명한다. 열(5005)은 Java 프로그램의 우선기간을 설명한다. 열(5006)은 다운로드 될 Java 프로그램이 위치하고 있는 서버 및 프로그램의 저장 위치를 지칭하는 URL을 설명한다. 행(5011)은 한 세트의 Java 프로그램 정보를 설명한다. 행(5011)에서 정의되는 Java 프로그램은 식별자 "0x5001", 제어 정보 "자동개시", 식별자 "2" 및 프로그램명 "a/PPV3Xlet"을 가지는 세트이다. Java 프로그램 식별자 적용 ID로부터 Java 프로그램이 사인된 프로그램이라는 것이 알려진다. URL이 "http://panasonic.com/app" 일 때, 단말장치는 HTTP를 사용하여 "app" 및 "panasonic.com"로 할당된 디렉토리 및 그 서브디렉토리로부터 Java 프로그램을 다운로드한다. 여기서, HTTP는 인터넷의 다른쪽에서 웹 서버로부터 홈페이지를 다운로드 할 때, 현재 가장 널리 사용되는 공개 기술이다. HTTP는 RFC2612에 상술되어 있다.

여기서, 정보의 여섯개의 아이템이 Java 프로그램에 특정된다 할지라도, 본 발명은 정보의 그 이상의 아이템이 정의된다 할지라도 충족될 수 있다.

도 51은 IP 네트워크를 통해 Java 프로그램을 다운로드 할 때 구성을 보여주는 개략도이다. 헤드엔드(5101) 및 단말장치(5102)는 CATV 네트워크(5104)를 통해 접속되어 있다. 또한, 헤드엔드(5101), 단말장치(5102) 및 Java 프로그램이 위치한 서버(5103)는 Internet과 같은 IP 네트워트(5105)를 통해 접속되어 있다.

도 52는 AM(1205b)의 구성요소를 도시한다. 신호 정보추출기(5201)는 이전에 설명된 방식으로, AIT 또는 XAIT의 신호정보를 추출하고, 그러한 신호 정보는 파일 계층 구성부(5202)에 인도된다. 파일 계층 구성부(5202)는 POD(504)를 통해 서버(5103)에 위치한 Java 프로그램 뿐만 아니라 Java 프로그램과 관련된 파일을 순차적으로 다운로드하고 1차 저장부(511a)의 영역에 서버(5103)와 동일한 파일 계층을 구성한다. 계층의 구성이 완료되는 경우, 보안 매니저(1205f)는 인증을 시작하도록 지시된다. 인증이 성공하는 경우, 파일 계층 구성부(5202)는 인스톨하기 위한 인스톨부(5203)를 요구하고 인스톨부(5203)은 인스톨을 시작한다.

IP 네트워크를 통해 다운로드된 Java 프로그램의 인증 도 51 및 도 52를 참조하여 설명될 것이다. Java 프로그램 식별자(5001)로서 "0x5001"를, Java 프로그램에 제어 정보로서 "자동개시"를, IP 식별자(5003)로서 "2"를, 프로그램명(5004)로서 "/a/PPV3Xlet"를, 우선기간(5005)로서 "200"을, URL(5006)로서 "http://panasonic.com/app"를 가리키는 XAIT가 도 51내 헤드엔드(5101)로부터 단말장치(5102)에 신호될 경우, 신호 정보 추출기(5201)는 우선 그러한 신호 정보를 해석한다. 이러한 경우, Java 프로그램 식별자의 값으로부터 Java 프로그램이 사인된 프로그램인지 판단하고, IP 식별자로부터 다운로드가 IP 네트워크를 통해 수행되는 것인지를 판단한다. 그리고 파일 계층 구조부(5202)에 URL "http://panasonic.com/app"에 존재하는 파일 계층과 동일한 파일계층을 1차 저장부(511)내 서버(5103)내 구성하라는 통지를 송신한다. 도 53은 URL "http://panasonic.com/app"의 파일 계층의 일례를 보여준다. 5301은 "http://panasonic.com/app"의 전체적인 파일 계층이고, 5302는 5301의 루트 디렉토리이고, 5303 및 5307, 5304 및 5305는 2116~2118, 2119 및 2120 각각과 같은 의미를 가지고, 따라서 그에 대한 설명은 생략한다. 5308은 Java 프로그램이며 5309는 Java 프로그램으로부터 읽힌 데이터를 보여준다. 도 54A내 5401 및 도 54B내 5402는 "ocap.hashfile"(5305 및 5307)의 상세를 각각 도시하고 있다. 5401 및 5402에 대한 의미가 도 22내 설명과 동일하기 때문에, 여기서 설명은 생략한다.

신호 정보 통지부(5201)로부터 통지를 수취하는 동안, 파일 계층 구성도(5202)는 우선 HTTP를 사용하여 "ocap.hashfile"(5303)을 다운로드한다. 여기서부터 HTTP의 사용이 IP 네트워크를 통해 다운로드를 가정한다 할지라도, 다른 프로토콜은 또한 다운로드가 가능한한 충분하다. "ocap.hashfile"(5303)으로부터 "/"는 "ocap.certificates.1", "ocap.signaturefile.1" 및 "a"를 포함하는 것이 알려지 있고, 이러한 것은 순차적으로 다운로드된다. 여기서 "a"의 다운로드가 시도되는 경우, "a"로서 다운로드 실패는 디렉토리이다. 그 때, "a/ocap.hashfile"의 다운로드가 시도된다. "a/ocap.hashfile"(5307)가 실제로 존재하는 동안, 다운로드는 성공하고, "ocap.hashfile", "ocap.certificates.1", 및 "ocap.signaturefile.1" 그리고 "a"는 1차 저장부(511)에 디렉토리로서 위치한다. 또한, "a" 디렉토리내 "PPV3Xlet.class" and "data.txt"의 존재는 "a/ocap.hashfile"로부터 읽혀지게 되는 경우, 다운로드가 되고 URL "http://panasonic.com/app"과 동일한 파일 계층이 1차 저장부(511)에 구성된다. 또한 Java 프로그램이 2차 저장부(510)에 저장되는 경우, 1차 저장부(511)대신에 파일 계층은 2차 저장부(510)내 구성될 수 있다. 추가적으로, "application description file"이 Java 프로그램이 2차 저장부(510)내 저장되는 경우에 포함된다면, "application description file"이 파일 계층에 대한 정보를 포함하는 경우, "ocap.hashfile" 대신에 파일 계층의 구성에 언급될 수 있다.

파일 계층 구성부(5202)는 파일 계층을 구성하는 경우, 보안 매니저(1205f)는 구성된 파일 계층을 인증하도록 통지된다. 보안 매니저(1205f)가 인증 지시를 수락할 때 파일 계층의 인증이 수행되고, 이미 전에 설명된 인증에 관한 설명은 여기서는 생략한다.

도 55는 네트워크을 통해 다운로드된 프로그램의 인증기간 동안의 플로차트를 보여준다. 5011에서 보여주는 XAIT가 수신되는 경우(단계 S5501), Java 프로그램 식별자(5001)로부터 Java 프로그램이 사인된 프로그램인지 그렇지 않은지 여부를 판단한다(단계 S5502). 만약 사인되지 않은 프로그램이면, 인스톨 및 활성화(단계 S5507)이 수행된다. 만약 사인된 프로그램이면, 프로그램이 DSMCC 식별자인지 IP 식별자인지에 대한 체크가 수행된다(단계 S5503). 만약 IP 식별자이면, URL(5006)에 의해 지시되는 파일 계층화는 로컬 영역인 1차 저장부(511) 또는 2차 저장부(510)에 구성된다(단계 S5504). 프로그램이 단계 S5503내 DSMCC 식별자 또는 단계 S5504가 완료된 경우, 보안 매니저(1205f)는 로컬 영역내 존재하는 파일 계층화를 인증하도록 지시된다(단계 S5505). 단계 5505는 도 27에 플로차트에 해당한다. 그리고, 인증(단계 S5506)의 경우 보안 매니저(1205f)가 성공적인지 아닌지에 달려있고, 성공적인 경우 수행되는 프로그램의 인스톨 및 활성화의 경우도 그러하다.

또한, 서버내 일부 또는 전체 파일이 인증이 실패할 수도 있다. 이것은 업그레이드가 되는 시간동안 다운로드가 수행되는 경우 있을 법한 일이기 때문이다. 그러한 경우에 대비하여, 다운로드 및 인증은 미리 결정된 시간의 수만큼 다시 시도될수 있고 경과된 미리 결정된 시간의 양동안 기다린 이후에 시도될 수도 있다. 또한, 사용자가 다시 시도할 것인지 즉각적으로 결정할 수도 있도록, 디스플레이(509)내 인증의 실패를 지시하는 메시지를 표시하는 것이 가능하다.

또한, 도 56의 XAIT의 Java 프로그램 다운로드 동안, 서버(5103)내 프로그램의 파일 계층이 도 57에서 보여지는 파일 계층을 소유하는 경우가 있고, 도 58A내 5710, 도 58B내 5720, 도 58C내 5730에 해당하는 "ocap.hashfile"(5611, 5621 및 5631)의 세부가 있고, 다른말로 하면, 디렉토리 "/b"(5630) 및 디렉토리 "/"(5610)에 다른 인증 파일(ocap.certificates.x and ocap.signaturefile.x)을 사용하여 인증이 수행되는 경우가 있다. 이러한 점에서, 디렉토리 "/b"의 해시 알고리즘이 도 58A의 5710에서 보여지는 대로, "Non-auth"로서 표현되는 경우, 디렉토리 "/b" 및 그 이하는 일시적으로 인증의 범위밖에 있게 된다. 이러한 조건하에, "/b" 디렉토리(5630) 대신 "/a" 디렉토리(5620)내 프로그램이 활성화되는 신호가 주어지는 경우, 파일 계층화 구조부(5202)는 로컬 영역에 비어있는 "/b" 디렉토리를 만들고, "/b" 디렉토리(5630) 또는 그 이하에 접근이 이루어지거나 인증이 필요한 경우, "/b" 디렉토리(5630) 아래 "PPV4Xlet.class"(5622)이 "PPVvideo.mpg"(5635)를 사용하려 하거나 "/b" 디렉토리(5630)아래 "PPV5Xlet.class"(5634)의 활성화가 사인되는 경우 "/b" 디렉토리(5630)는 로컬 영역내 구성된다. 또, "Non-auth"로 지정된 파일이 로컬영역의 파일 계층에 다운로드될 필요가 없게 하기 위해, 디렉토리 뿐만아니라 파일에도 동일한 것이 적용되고 크기가 "0"인 비어있는 파일이 로컬 영역에 대체적이로 만들어진다. 그러나 그러한 파일에 접근이 있는 경우, 빈 디렉토리 또는 빈 파일의 생성은 해시파일내 리스트된 파일명/디렉토리명 및 파일 계층내 존재하는 파일명/디렉토리명이 각각 일치해야하기 때문에 파일 계층에 다운로드가 수행된다.

또한, 로컬 영역내 구성된 인스톨되고 활성화된 사인된 Java 프로그램이 IP 네트워크를 통해 Java 프로그램과 같은 파일을 동일한 디렉토리로 다운로드할 수 있는 경우가 있다. 우연히 의도하지 않게 Java 프로그램이 단말장치에 손상을 입힐 수 있는 프로그램(class 파일)의 일부를 다운로드 하면, 그들중의 동작은 치명적인 문제를 야기할 수 있다. 따라서, Java 프로그램으로부터 발생된 class 파일에 인스톨이 요구되는 경우, 인스톨부(5203)는 파일 계층화 구성부(5202)에 그러한 class 파일을 인스톨하는 것이 옳은지에 대한 체크를 한다. 인스톨부(5203)에 의해 인스톨이 옳은지에 대한 체크를 요구하는 경우, 파일 계층 구성부(5202)는 그러한 class 파일이 파일 계층내 존재하는 ocap.hashfile내 리스트되어 있는지 여부를 확인한다. 파일이 리스트되어 있다면 그러한 class 파일의 인스톨이 허용되고, 그렇지 않다면 인스톨은 거부된다. 또한, ocap.hashfile이 재기입되어 class 파일이 리스트되었는지 아닌지 불확실한 경우를 준비할 필요가 있다. class 파일을 인스톨 하는 경우, 보안 매니저(1205f)에 인증을 지시할 수 있고 파일 계층 구성부(5202)에 인증 및 인스톨 인증이 성공적인 경우 class 파일을 인스톨하고 인스톨을 수행하는 것이 옳은지 여부를 체크를 요구할 수 있다.

본 발명의 일부 예시적인 실시예들만 상세히 설명하였지만, 당업자라면 본 발명의 신규 특징 및 이점으로부터 실질적으로 벗어남없이 예시적인 실시예에서 다양한 변형이 가능하다는 것을 쉽게 이해할 것이다. 따라서, 그러한 모든 변형은 본 발명의 범위 내에 포함되는 것으로 간주된다.

Claims (8)

1. 프로그램을 인증 및 실행하는 방법으로서,
   상기 프로그램의 저장 위치를 식별하는 정보에 따라, 부정 변경(tamper) 체크를 필요로 하는 적어도 하나의 데이터 파일로 디렉토리 구조로서 구성된 프로그램을 소정 서버로부터 다운로드하고, 부정 변경 체크를 필요로 하는 상기 다운로드된 적어도 하나의 데이터 파일을 인증하며, 그리고 상기 프로그램을 방송 수신기에 저장하는 단계 - 상기 정보는 전송 스트림에서 지정되고, 상기 서버는 네트워크에 접속됨 - ; 및
   상기 인증된 프로그램을 실행하는 단계를 포함하되,
   상기 인증 및 저장하는 단계는:
   상기 디렉토리 구조를 구성하는 디렉토리내에 포함된 해시 파일내에 리스트된 데이터 파일 및 디렉토리에 기초하여, 상기 서버내에 저장된 상기 프로그램의 디렉토리 구조와 동일한 디렉토리 구조를 가지도록, 상기 해시 파일내에 리스트된 부정 변경 체크를 필요로 하는 데이터 파일을 상기 방송 수신기에 다운로드하는 단계;
   2개의 해시 값이 일치하는지 여부를 검증하는 단계 - 상기 해시 값들 중 하나의 해시 값은 부정 변경 체크를 필요로 하는 각각의 데이터 파일로부터 연산되며, 다른 하나의 해시 값은 상기 데이터 파일을 리스트하는 상기 해시 파일내에 저장됨 - ;
   상기 프로그램내에 포함된 인증서 파일의 유효성을 검증하는 단계;
   복호된 값과 해시 값이 일치하는지를 검증하는 단계 - 상기 복호된 값은 상기 프로그램의 상기 인증서 파일내에 포함된 리프(leaf) 인증서의 공개 키를 이용하여 상기 프로그램내에 포함된 서명 파일의 서명값을 복호함에 의해 얻어지고, 상기 해시값은 상기 프로그램의 최상위 디렉토리내에 위치한 해시 파일로부터 연산됨 - ; 및
   다음의 조건 즉, 상기 2개의 해시 값이 일치함이 검증되는 것; 상기 인증서 파일이 유효함이 검증되는 것; 또한 상기 복호된 값과 상기 해시 값이 일치함이 검증되는 것이 모두 만족되는 경우에, 상기 프로그램을 인증하고 상기 인증된 프로그램을 저장하는 단계를 포함하며,
   상기 실행 단계는,
   상기 저장된 프로그램내에 포함된 상기 인증서 파일이 유효한지 여부를 검증하는 단계를 포함하며,
   상기 실행 단계 동안에, 상기 저장된 프로그램은, 상기 저장된 프로그램내에 포함된 상기 인증서 파일이 유효한지 여부를 검증하는 동안 상기 저장된 프로그램내에 포함된 상기 인증서 파일이 유효한 것으로 검증된 때에만 다시 인증되고 실행되고,
   상기 프로그램내에 포함된 인증서 파일의 유효성을 검증하는 단계는,
   2개의 루트(root) 인증서가 일치하는지 여부를 검증하는 단계 - 상기 루트 인증서들 중 하나는 상기 프로그램내에 포함된 상기 인증서 파일내에 있으며, 다른 하나의 루트 인증서는 상기 방송 수신기내에 위치됨 - 를 포함하며,
   여기서, 상기 인증서 파일은, 상기 2개의 루트 인증서가 일치할 때에 유효한 것으로 검증되는, 방법.
2. 청구항 1에 있어서,
   상기 프로그램내에 포함된 인증서 파일의 유효성을 검증하는 단계는,
   상기 프로그램내에 포함된 상기 인증서 파일내의 각각의 인증서의 유효 기간을 검증하는 단계를 더 포함하며,
   여기서, 상기 인증서 파일은, 다음의 조건 즉, 상기 2개의 루트 인증서가 일치하는 것; 또한 상기 인증이 수행된 시간이 상기 인증서 파일내의 각각의 인증서의 유효 기간내에 있는 것 모두가 만족되는 때에 유효한 것으로 검증되는, 방법.
3. 프로그램을 인증 및 실행하는 방법으로서,
   상기 프로그램의 저장 위치를 식별하는 정보에 따라, 부정 변경(tamper) 체크를 필요로 하는 적어도 하나의 데이터 파일로 디렉토리 구조로서 구성된 프로그램을 소정 서버로부터 다운로드하고, 부정 변경 체크를 필요로 하는 상기 다운로드된 적어도 하나의 데이터 파일을 인증하며, 그리고 상기 프로그램을 방송 수신기에 저장하는 단계 - 상기 정보는 전송 스트림에서 지정되고, 상기 서버는 네트워크에 접속됨 - ; 및
   상기 인증된 프로그램을 실행하는 단계를 포함하되,
   상기 인증 및 저장하는 단계는:
   상기 디렉토리 구조를 구성하는 디렉토리내에 포함된 해시 파일내에 리스트된 데이터 파일 및 디렉토리에 기초하여, 상기 서버내에 저장된 상기 프로그램의 디렉토리 구조와 동일한 디렉토리 구조를 가지도록, 상기 해시 파일내에 리스트된 부정 변경 체크를 필요로 하는 데이터 파일을 상기 방송 수신기에 다운로드하는 단계;
   2개의 해시 값이 일치하는지 여부를 검증하는 단계 - 상기 해시 값들 중 하나의 해시 값은 부정 변경 체크를 필요로 하는 각각의 데이터 파일로부터 연산되며, 다른 하나의 해시 값은 상기 데이터 파일을 리스트하는 상기 해시 파일내에 저장됨 - ;
   상기 프로그램내에 포함된 인증서 파일의 유효성을 검증하는 단계;
   복호된 값과 해시 값이 일치하는지를 검증하는 단계 - 상기 복호된 값은 상기 프로그램의 상기 인증서 파일내에 포함된 리프(leaf) 인증서의 공개 키를 이용하여 상기 프로그램내에 포함된 서명 파일의 서명값을 복호함에 의해 얻어지고, 상기 해시값은 상기 프로그램의 최상위 디렉토리내에 위치한 해시 파일로부터 연산됨 - ; 및
   다음의 조건 즉, 상기 2개의 해시 값이 일치함이 검증되는 것; 상기 인증서 파일이 유효함이 검증되는 것; 또한 상기 복호된 값과 상기 해시 값이 일치함이 검증되는 것이 모두 만족되는 경우에, 상기 프로그램을 인증하고 상기 인증된 프로그램을 저장하는 단계를 포함하며,
   상기 실행 단계는,
   상기 저장된 프로그램내에 포함된 상기 인증서 파일이 유효한지 여부를 검증하는 단계를 포함하며,
   상기 실행 단계 동안에, 상기 저장된 프로그램은, 상기 저장된 프로그램내에 포함된 상기 인증서 파일이 유효한지 여부를 검증하는 동안 상기 저장된 프로그램내에 포함된 상기 인증서 파일이 유효한 것으로 검증된 때에만 다시 인증되고 실행되고,
   상기 검증하는 단계는,
   2개의 루트 인증서가 일치하는지 여부를 검증하는 단계 - 상기 루트 인증서 중 하나는 상기 저장된 프로그램내에 포함된 상기 인증서 파일내에 있으며 다른 하나의 루트 인증서는 상기 방송 수신기내에 위치됨 - 를 포함하며,
   여기서, 상기 저장된 프로그램내에 포함된 상기 인증서 파일은 상기 2개의 루트 인증서가 일치하는 때에 유효한 것으로 검증되는, 방법.
4. 청구항 3에 있어서,
   상기 검증하는 단계는,
   상기 저장된 프로그램내에 포함된 상기 인증서 파일내의 각각의 인증서의 유효 기간을 검증하는 단계를 더 포함하며,
   여기서, 상기 저장된 프로그램내에 포함된 상기 인증서 파일은, 다음의 조건 즉, 상기 2개의 루트 인증서가 일치하는 것; 및 상기 실행이 수행되는 시간이 상기 인증서 파일내의 각각의 인증서의 상기 유효 기간내에 있는 것 모두가 만족되는 때에 유효한 것으로 검증되는, 방법.
5. 프로그램을 인증 및 실행하는 방법으로서,
   상기 프로그램의 저장 위치를 식별하는 정보에 따라, 부정 변경(tamper) 체크를 필요로 하는 적어도 하나의 데이터 파일로 디렉토리 구조로서 구성된 프로그램을 소정 서버로부터 다운로드하고, 부정 변경 체크를 필요로 하는 상기 다운로드된 적어도 하나의 데이터 파일을 인증하며, 그리고 상기 프로그램을 방송 수신기에 저장하는 단계 - 상기 정보는 전송 스트림에서 지정되고, 상기 서버는 네트워크에 접속됨 - ; 및
   상기 인증된 프로그램을 실행하는 단계를 포함하되,
   상기 인증 및 저장하는 단계는:
   상기 디렉토리 구조를 구성하는 디렉토리내에 포함된 해시 파일내에 리스트된 데이터 파일 및 디렉토리에 기초하여, 상기 서버내에 저장된 상기 프로그램의 디렉토리 구조와 동일한 디렉토리 구조를 가지도록, 상기 해시 파일내에 리스트된 부정 변경 체크를 필요로 하는 데이터 파일을 상기 방송 수신기에 다운로드하는 단계;
   2개의 해시 값이 일치하는지 여부를 검증하는 단계 - 상기 해시 값들 중 하나의 해시 값은 부정 변경 체크를 필요로 하는 각각의 데이터 파일로부터 연산되며, 다른 하나의 해시 값은 상기 데이터 파일을 리스트하는 상기 해시 파일내에 저장됨 - ;
   상기 프로그램내에 포함된 인증서 파일의 유효성을 검증하는 단계;
   복호된 값과 해시 값이 일치하는지를 검증하는 단계 - 상기 복호된 값은 상기 프로그램의 상기 인증서 파일내에 포함된 리프(leaf) 인증서의 공개 키를 이용하여 상기 프로그램내에 포함된 서명 파일의 서명값을 복호함에 의해 얻어지고, 상기 해시값은 상기 프로그램의 최상위 디렉토리내에 위치한 해시 파일로부터 연산됨 - ; 및
   다음의 조건 즉, 상기 2개의 해시 값이 일치함이 검증되는 것; 상기 인증서 파일이 유효함이 검증되는 것; 또한 상기 복호된 값과 상기 해시 값이 일치함이 검증되는 것이 모두 만족되는 경우에, 상기 프로그램을 인증하고 상기 인증된 프로그램을 저장하는 단계를 포함하며,
   상기 실행 단계는,
   상기 저장된 프로그램내에 포함된 상기 인증서 파일이 유효한지 여부를 검증하는 단계를 포함하며,
   상기 실행 단계 동안에, 상기 저장된 프로그램은, 상기 저장된 프로그램내에 포함된 상기 인증서 파일이 유효한지 여부를 검증하는 동안 상기 저장된 프로그램내에 포함된 상기 인증서 파일이 유효한 것으로 검증된 때에만 다시 인증되고 실행되고,
   상기 프로그램은, 다음의 조건 즉, 상기 2개의 해시 값이 일치하는 것으로 검증되지 않는 것; 상기 인증서 파일이 유효한 것으로 검증되지 않는 것; 및 상기 복호된 값과 상기 해시 값이 일치하는 것으로 검증되지 않는 것 중 적어도 하나가 만족되는 때에는 저장되지 않는, 방법.
6. 프로그램을 인증 및 실행하는 방법으로서,
   상기 프로그램의 저장 위치를 식별하는 정보에 따라, 부정 변경(tamper) 체크를 필요로 하는 적어도 하나의 데이터 파일로 디렉토리 구조로서 구성된 프로그램을 소정 서버로부터 다운로드하고, 부정 변경 체크를 필요로 하는 상기 다운로드된 적어도 하나의 데이터 파일을 인증하며, 그리고 상기 프로그램을 방송 수신기에 저장하는 단계 - 상기 정보는 전송 스트림에서 지정되고, 상기 서버는 네트워크에 접속됨 - ; 및
   상기 인증된 프로그램을 실행하는 단계를 포함하되,
   상기 인증 및 저장하는 단계는:
   상기 디렉토리 구조를 구성하는 디렉토리내에 포함된 해시 파일내에 리스트된 데이터 파일 및 디렉토리에 기초하여, 상기 서버내에 저장된 상기 프로그램의 디렉토리 구조와 동일한 디렉토리 구조를 가지도록, 상기 해시 파일내에 리스트된 부정 변경 체크를 필요로 하는 데이터 파일을 상기 방송 수신기에 다운로드하는 단계;
   2개의 해시 값이 일치하는지 여부를 검증하는 단계 - 상기 해시 값들 중 하나의 해시 값은 부정 변경 체크를 필요로 하는 각각의 데이터 파일로부터 연산되며, 다른 하나의 해시 값은 상기 데이터 파일을 리스트하는 상기 해시 파일내에 저장됨 - ;
   상기 프로그램내에 포함된 인증서 파일의 유효성을 검증하는 단계;
   복호된 값과 해시 값이 일치하는지를 검증하는 단계 - 상기 복호된 값은 상기 프로그램의 상기 인증서 파일내에 포함된 리프(leaf) 인증서의 공개 키를 이용하여 상기 프로그램내에 포함된 서명 파일의 서명값을 복호함에 의해 얻어지고, 상기 해시값은 상기 프로그램의 최상위 디렉토리내에 위치한 해시 파일로부터 연산됨 - ; 및
   다음의 조건 즉, 상기 2개의 해시 값이 일치함이 검증되는 것; 상기 인증서 파일이 유효함이 검증되는 것; 또한 상기 복호된 값과 상기 해시 값이 일치함이 검증되는 것이 모두 만족되는 경우에, 상기 프로그램을 인증하고 상기 인증된 프로그램을 저장하는 단계를 포함하며,
   상기 실행 단계는,
   상기 저장된 프로그램내에 포함된 상기 인증서 파일이 유효한지 여부를 검증하는 단계를 포함하며,
   상기 실행 단계 동안에, 상기 저장된 프로그램은, 상기 저장된 프로그램내에 포함된 상기 인증서 파일이 유효한지 여부를 검증하는 동안 상기 저장된 프로그램내에 포함된 상기 인증서 파일이 유효한 것으로 검증된 때에만 다시 인증되고 실행되고,
   상기 다운로드하는 단계는,
   상기 디렉토리가 상기 서버내에서 상기 프로그램을 구성하는 최상위 디렉토리내에 저장된 해시 파일에 의해 지정되는 때에, 상기 방송 수신기내의 최상위 디렉토리 아래에, 해시 파일에 의해 지정된 디렉토리와 동일한 디렉토리를 구성하고, 상기 서버내의 상기 최상위 디렉토리내에 저장된 상기 해시 파일에 의해 지정된 상기 디렉토리내에 저장된 상기 해시 파일에 의해 지정된 부정 변경 체크를 필요로 하는 데이터 파일을 상기 방송 수신기내에 구성된 대응 디렉토리에 다운로드하는 단계를 포함하는, 방법.
7. 프로그램을 인증 및 실행하기 위한 장치로서,
   프로그램의 저장 위치를 식별하는 정보에 따라, 부정 변경 체크를 필요로 하는 적어도 하나의 데이터 파일로 디렉토리 구조로서 구성된 프로그램을 소정 서버로부터 다운로드하고, 부정 변경 체크를 필요로 하는 상기 다운로드된 적어도 하나의 데이터 파일을 인증하고, 그리고 상기 프로그램을 방송 수신기에 저장하는 인증기 및 저장매체 - 상기 정보는 전송 스트림에서 지정되고, 상기 서버는 네트워크에 접속됨 - ; 및
   상기 인증된 프로그램을 실행하는 실행기를 포함하되,
   상기 인증기 및 저장매체는:
   상기 디렉토리 구조를 구성하는 디렉토리내에 포함된 해시 파일내에 리스트된 데이터 파일 및 디렉토리에 기초하여, 상기 서버내에 저장된 상기 프로그램의 디렉토리 구조와 동일한 디렉토리 구조를 가지도록, 상기 해시 파일내에 리스트된 부정 변경 체크를 필요로 하는 전체 데이터 파일을 상기 방송 수신기에 다운로드하는 파일 계층 구성기;
   2개의 해시 값이 일치하는지를 검증하는 제1 검증기 - 상기 해시 값들 중 하나의 해시 값은 부정 변경 체크를 필요로 하는 각각의 데이터 파일로부터 연산되며, 다른 하나의 해시 값은 상기 데이터 파일을 기술하는 상기 해시 파일내에 저장됨 - ;
   상기 프로그램내에 포함된 인증서 파일의 유효성을 검증하는 제2 검증기;
   복호된 값과 해시 값이 일치하는지를 검증하는 제3 검증기 - 상기 복호된 값은 상기 프로그램의 인증서 파일내에 포함된 리프(leaf) 인증서의 공개 키를 이용하여 상기 프로그램내에 포함된 서명 파일의 서명값을 복호함에 의해 얻어지고, 상기 해시 값은 상기 프로그램의 최상위 디렉토리내에 위치한 해시 파일로부터 연산됨 - ; 및
   다음의 조건 즉, 상기 제 1 검증기에 의해 상기 2개의 해시 값이 일치함이 검증되는 것; 상기 제2 검증기에 의해 상기 인증서 파일이 유효함이 검증되는 것; 또한 상기 제3 검증기에 의해 상기 복호된 값과 상기 해시 값이 일치함이 검증되는 것이 만족되는 때에, 상기 프로그램을 인증하고 상기 인증된 프로그램을 저장하는 저장매체를 포함하며,
   상기 실행기는,
   상기 저장된 프로그램내에 포함된 상기 인증서 파일이 유효한지 여부를 검증하는 제4 검증기를 포함하며,
   여기서, 상기 실행기는, 상기 저장된 프로그램내에 포함된 상기 인증서 파일이 상기 제4 검증기에 의해 유효한 것으로 검증된 경우에만 상기 저장된 프로그램을 다시 인증하고 실행하고,
   상기 제4 검증기는,
   2개의 루트(root) 인증서가 일치하는지 여부를 검증 - 상기 루트 인증서들 중 하나는 상기 프로그램내에 포함된 상기 인증서 파일내에 있으며, 다른 하나의 루트 인증서는 상기 방송 수신기내에 위치됨 - 하고, 상기 2개의 루트 인증서가 일치할 때에 상기 인증서 파일을 유효한 것으로 검증하는, 장치.
8. 컴퓨터가 실행하는 프로그램으로서,
   i) 소정 서버로부터, 실행가능 프로그램의 저장 위치를 식별하는 정보에 따라 부정 변경(tamper) 체크를 필요로 하는, 디렉토리 구조로 되어 있는, 적어도 하나의 데이터 파일로 구성된 실행 가능 프로그램을 다운로드하고, ii) 부정 변경 체크를 필요로 하는 상기 다운로드된 데이터 파일을 인증하고, iii) 상기 실행 가능 프로그램을 방송 수신기에 저장하는 인증 및 저장 단계 - 상기 정보는 전송 스트림으로 정해지고, 상기 서버는 네트워크에 접속됨 - ; 및
   상기 인증된 실행 가능 프로그램을 실행하는 단계
   를 포함하되, 상기 인증 및 저장 단계는:
   상기 디렉토리 구조를 구성하는 디렉토리내에 포함된 해시 파일내에 리스트된 디렉토리 및 데이터 파일에 기초하여, 상기 서버내에 저장된 상기 실행 가능 프로그램의 디렉토리 구조와 동일한 디렉토리 구조를 가지도록, 해시 파일내에 리스트된 부정 변경 체크를 필요로 하는 전체 데이터 파일을 상기 방송 수신기에 다운로드하는 제1 단계;
   2개의 해시 값이 일치하는지 여부를 검증하는 제2 단계 - 일 해시 값은 부정 변경 체크를 필요로 하는 각각의 데이터 파일로부터 연산되며, 다른 해시 값은 상기 데이터 파일을 기술하는 해시 파일내에 저장됨 - ;
   상기 실행 가능 프로그램내에 포함된 인증서 파일의 유효성을 검증하는 제3 단계;
   복호된 값과 해시 값이 일치하는지 여부를 검증하는 제4 단계 - 상기 복호된 값은 상기 실행 가능 프로그램의 인증서 파일내에 포함된 리프(leaf) 인증서의 공개 키를 이용하여 상기 실행 가능 프로그램내에 포함된 서명 파일의 서명값을 복호함에 의해 얻어지고, 상기 해시값은 상기 실행 가능 프로그램의 최상위 디렉토리내에 위치한 해시 파일로부터 연산됨 - ; 및
   이하의 모든 것 즉, 상기 제2 단계에서 상기 2개의 해시 값이 일치함이 검증되고; 상기 제3 단계에서 상기 인증서 파일이 유효함이 검증되고; 또한 상기 제4 단계에서 상기 복호된 값과 상기 해시 값이 일치함이 검증되는 것이 모두 만족되는 경우에, 상기 실행 가능 프로그램을 인증하고 상기 인증된 실행 가능 프로그램을 저장하는 제5 단계
   를 포함하며, 상기 실행 단계는
   상기 저장된 실행 가능 프로그램내에 포함된 상기 인증서 파일이 유효한지 여부를 검증하는 검증 단계를 포함하며,
   상기 실행 단계에서, 상기 저장된 실행 가능 프로그램은 상기 저장된 실행 가능 프로그램내에 포함된 상기 인증서 파일이 상기 검증 단계에서 유효한 것으로 검증된 경우에만 다시 인증되고 실행되고,
   상기 프로그램내에 포함된 인증서 파일의 유효성을 검증하는 단계는,
   2개의 루트(root) 인증서가 일치하는지 여부를 검증하는 단계 - 상기 루트 인증서들 중 하나는 상기 프로그램내에 포함된 상기 인증서 파일내에 있으며, 다른 하나의 루트 인증서는 상기 방송 수신기내에 위치됨 - 를 포함하며,
   여기서, 상기 인증서 파일은, 상기 2개의 루트 인증서가 일치할 때에 유효한 것으로 검증되는, 프로그램.

Images