KR20170010574A - 정보처리장치, 영상처리장치 및 그들의 제어방법 - Google Patents

Abstract

본 발명의 실시예에 따른 정보처리장치는, 어플리케이션 실행장치에서 설치될 어플리케이션의 주 프로그램과, 주 프로그램의 실행에 관한 복수의 속성의 데이터를 포함하는 제1리소스데이터가 저장되는 저장부와; 제1리소스데이터의 복수의 속성 중에서 주 프로그램의 실행 시 이용 정도가 상대적으로 낮은 적어도 하나의 속성의 데이터를 배제하여 제1리소스데이터보다 작은 데이터 크기를 가지는 제2리소스데이터를 생성하고, 주 프로그램 및 생성된 제2리소스 데이터를 포함하는 어플리케이션의 설치용 팩키지 프로그램을 생성하는 적어도 하나의 프로세서를 포함하는 것을 특징으로 한다.

Description

정보처리장치, 영상처리장치 및 그들의 제어방법 {INFORMATION PROCESSING APPARATUS, IMAGE PROCESSSING APPARATUS AND CONTROL METHODS THEREOF}

본 발명은 다양한 종류의 정보 또는 데이터를 사전에 지정된 프로세스에 따라서 처리하여 자체적으로 저장하거나 또는 외부장치에 전송할 수 있는 정보처리장치, 영상처리장치 및 그들의 제어방법에 관한 것으로서, 상세하게는 개발자에 의해 개발된 어플리케이션(application)이 팩키징(packaging)되어 사용자의 단말에 전달됨에 있어서, 이러한 어플리케이션 팩키지(application package) 내의 데이터를 최적화시키는 정보처리장치, 영상처리장치 및 그들의 제어방법에 관한 것이다.

정보처리장치는 소정의 정보를 특정 프로세스에 따라서 연산 및 처리하기 위한 목적으로 마련되며, 기본적으로 연산을 위한 CPU, 칩셋, 메모리 등의 전자부품들을 가지는 전자장치를 지칭한다. 정보처리장치는 처리 대상이 되는 정보가 무엇인지에 따라서 그 종류가 구분될 수 있는 바, 예를 들면 범용의 정보를 처리하는 PC나 서버 등의 컴퓨터가 있고, 영상 정보를 처리하는 영상처리장치가 있다.

정보처리장치 중에서 영상처리장치는 외부로부터 수신되는 영상신호/영상데이터를 다양한 영상처리 프로세스에 따라서 처리한다. 영상처리장치는 처리된 영상데이터를 자체 구비한 디스플레이 패널(display panel) 상에 영상으로 표시하거나, 또는 패널을 구비한 타 디스플레이장치에서 영상으로 표시되도록 이 처리된 영상신호를 해당 디스플레이장치에 출력할 수 있다. 즉, 영상처리장치는 영상데이터를 처리 가능한 장치라면 영상을 표시 가능한 패널을 포함하는 경우 및 패널을 포함하지 않는 경우 모두 포함할 수 있다. 전자의 경우를 특히 디스플레이장치라고 지칭하며 그 예시로는 TV, 휴대용 멀티미디어 재생기, 태블릿(tablet), 모바일 폰(mobile phone) 등이 있고, 후자의 경우의 예시로는 셋탑박스(set-top box) 등이 있다.

소프트웨어의 관점에서, 정보처리장치는 운영체제 상에서 다양한 어플리케이션이 실행됨으로써 각 어플리케이션 별로 요구되는 기능을 실행한다. 특히, 정보처리장치가 영상처리장치라면, 영상처리장치는 이러한 실행 결과를 영상으로 표시되게 처리한다.

어플리케이션이 사용자에게 전달되는 과정은 다음과 같다. 어플리케이션은 개발자에 의해 최초 개발되어 서버에 등록되며, 서버는 사용자의 단말에 대해 어플리케이션을 제공한다. 사용자의 단말은 서버로부터 다운로드 형태로 제공받은 어플리케이션을 자체 운영체제 상에 인스톨 및 실행시킨다. 이러한 어플리케이션은 여러 종류의 데이터들이 모여서 구현되므로, 용이한 배포를 위해 하나의 파일 단위로 팩키지화하여 배포되는 것이 일반적이다.

그런데, 어플리케이션 팩키지는 해당 어플리케이션이 실행됨에 있어서 필요한 데이터만 포함하는 것이 아닌, 불필요한 데이터를 포함할 수도 있다. 이러한 불필요한 데이터는 어플리케이션 팩키지의 전체 용량을 늘어나게 하고, 다운로드 및 설치 시간을 늘어나게 하며, 실행 시에 소요되는 메모리나 버퍼의 용량이 커지게 할 수 있으며, 불필요한 데이터를 처리하는 것 때문에 실행 시간도 지연시킬 수 있다. 따라서, 이러한 점을 최소화하도록 어플리케이션의 팩키지 형태를 개선하는 것이 요구된다.

본 발명의 실시예에 따른 정보처리장치는, 어플리케이션 실행장치에서 설치될 어플리케이션의 주 프로그램과, 상기 주 프로그램의 실행에 관한 복수의 속성의 데이터를 포함하는 제1리소스데이터가 저장되는 저장부와; 상기 제1리소스데이터의 복수의 속성 중에서 상기 주 프로그램의 실행 시 이용 정도가 상대적으로 낮은 적어도 하나의 속성의 데이터를 배제하여 상기 제1리소스데이터보다 작은 데이터 크기를 가지는 제2리소스데이터를 생성하고, 상기 주 프로그램 및 상기 생성된 제2리소스 데이터를 포함하는 상기 어플리케이션의 설치용 팩키지 프로그램을 생성하는 적어도 하나의 프로세서를 포함하는 것을 특징으로 한다. 이로써, 어플리케이션의 실행 시에 리소스데이터의 디코딩 소요시간을 줄일 수 있다.

여기서, 상기 저장부는, 복수의 리소스데이터의 타입에 각기 대응하는 상기 리소스데이터 내 상기 데이터의 속성 별 삭제 여부를 지정한 최적화 정보를 저장하며, 상기 적어도 하나의 프로세서는, 상기 제1리소스데이터의 타입을 판단하고, 상기 판단한 타입에 대응하는 삭제 대상 속성을 상기 최적화 정보에 따라서 판단할 수 있다. 이로써, 리소스데이터에서 삭제할 하위 데이터를 용이하게 판별할 수 있다.

여기서, 상기 리소스데이터는 이미지 파일, 음성 파일, 멀티미디어 파일 중 적어도 어느 하나로 마련되며, 상기 최적화 정보는 상기 리소스데이터 내 메타데이터 속성의 상기 데이터를 삭제하도록 지정할 수 있다. 이로써, 어플리케이션의 실행 시에 불필요한 데이터를 리소스데이터 내에서 판별할 수 있다.

또한, 상기 최적화 정보는 상기 리소스데이터에서 삭제되는 메타데이터 중 일부의 내용을 리소스 이력 정보로 저장하도록 지정하며, 상기 적어도 하나의 프로세서는, 상기 리소스 이력 정보를 상기 팩키지 프로그램에 포함시킬 수 있다. 이로써, 리소스데이터의 디코딩 소요시간을 줄이면서도 차후 메타데이터의 참조가 필요한 상황에 대비할 수 있다.

여기서, 상기 최적화 정보는 상기 리소스데이터의 제1포맷을 상기 제1포맷 대비 상대적으로 데이터 크기의 효율이 높은 기 설정된 제2포맷으로 변환하도록 지정하며, 상기 적어도 하나의 프로세서는, 제3리소스데이터의 포맷을 판단하고, 상기 제3리소스데이터를 상기 최적화 정보에 지정된 상기 제2포맷의 상기 제4리소스데이터로 변환하며, 기 설정된 플랫폼 상에서 상기 어플리케이션이 실행될 때에 상기 제3리소스데이터를 요청하는 동작에 응답하여 상기 제4리소스데이터가 반환되도록 상기 변환 이력을 상기 리소스 이력 정보에 기록할 수 있다. 이로써, 리소스데이터를 보다 효율성이 높은 포맷으로 변환하면서도, 리소스데이터의 파일명 변경으로 인해 어플리케이션의 실행에 에러가 발생하는 것을 방지할 수 있다.

또는, 상기 적어도 하나의 프로세서는 상기 어플리케이션의 모든 상기 리소스데이터 중에서 제5리소스데이터와 중복되는 하나 이상의 제6리소스데이터를 삭제하며, 기 설정된 플랫폼 상에서 상기 어플리케이션이 실행될 때에 상기 제5리소스데이터를 요청하는 동작에 응답하여 상기 제6리소스데이터가 반환되도록 상기 삭제 이력을 상기 리소스 이력 정보에 기록할 수 있다. 이로써, 중복되는 리소스데이터를 삭제하여 전체적인 용량을 줄이면서도, 리소스데이터의 삭제로 인해 어플리케이션의 실행에 에러가 발생하는 것을 방지할 수 있다.

또한, 상기 어플리케이션 실행장치와 통신하는 통신부를 더 포함하며, 상기 적어도 하나의 프로세서는, 상기 저장부에 상기 팩키지 프로그램을 저장하고, 상기 어플리케이션 실행장치의 요청에 응답하여 상기 팩키지 프로그램을 상기 어플리케이션 실행장치에 설치되도록 상기 통신부를 통해 전송할 수 있다. 이로써, 최적화된 팩키지 프로그램을 배포할 수 있다.

또한, 상기 어플리케이션은 웹 브라우저 프로그램 상에서 실행되는 웹 어플리케이션일 수 있다. 이로써, 리소스데이터를 직접 제어하는 네이티브 어플리케이션과 달리, 리소스데이터를 변경하더라도 어플리케이션 실행이 보장되도록 할 수 있다.

또한, 본 발명의 실시예에 따른 영상처리장치는, 주 프로그램과 상기 주 프로그램의 실행에 관한 복수의 속성의 데이터를 포함하는 제1리소스데이터를 포함하는 어플리케이션의 설치용 팩키지 프로그램을 수신하는 수신부와; 상기 팩키지 프로그램을 해제하여 상기 어플리케이션을 실행 가능하게 설치하는 적어도 하나의 프로세서를 포함하며, 상기 적어도 하나의 프로세서는, 상기 제1리소스데이터의 복수의 속성 중에서 상기 주 프로그램의 실행 시 이용 정도가 상대적으로 낮은 적어도 하나의 속성의 데이터를 배제하여 상기 제1리소스데이터보다 작은 데이터 크기를 가지는 제2리소스데이터를 생성하고, 상기 주 프로그램 및 상기 생성된 제2리소스 데이터를 포함하는 상기 어플리케이션을 설치하는 것을 특징으로 한다. 이로써, 리소스데이터가 최적화되어 있지 않은 어플리케이션 팩키지를 수신하였을 때, 해당 어플리케이션 팩키지의 리소스데이터를 최적화시켜 설치함으로써 어플리케이션의 실행 시에 리소스데이터의 디코딩 소요시간을 줄일 수 있다.

또한, 본 발명의 실시예에 따른 정보처리장치의 제어방법은, 어플리케이션 실행장치에서 설치될 어플리케이션의 주 프로그램과, 상기 주 프로그램의 실행에 관한 복수의 속성의 데이터를 포함하는 제1리소스데이터를 취득하는 단계와; 상기 제1리소스데이터의 복수의 속성 중에서 상기 주 프로그램의 실행 시 이용 정도가 상대적으로 낮은 적어도 하나의 속성의 데이터를 배제하여 상기 제1리소스데이터보다 작은 데이터 크기를 가지는 제2리소스데이터를 생성하는 단계와; 상기 주 프로그램 및 상기 생성된 제2리소스 데이터를 포함하는 상기 어플리케이션의 설치용 팩키지 프로그램을 생성하는 단계를 포함하는 것을 특징으로 한다. 이로써, 어플리케이션의 실행 시에 리소스데이터의 디코딩 소요시간을 줄일 수 있다.

여기서, 상기 제2리소스데이터를 생성하는 단계는, 상기 제1리소스데이터의 타입을 판단하고, 상기 판단한 타입에 대응하는 삭제 대상 속성을 기 설정된 최적화 정보에 따라서 판단하는 단계를 포함하며, 상기 최적화 정보는, 복수의 리소스데이터의 타입에 각기 대응하는 상기 리소스데이터 내 상기 데이터의 속성 별 삭제 여부를 지정할 수 있다. 이로써, 리소스데이터에서 삭제할 하위 데이터를 용이하게 판별할 수 있다.

여기서, 상기 리소스데이터는 이미지 파일, 음성 파일, 멀티미디어 파일 중 적어도 어느 하나로 마련되며, 상기 최적화 정보는 상기 리소스데이터 내 메타데이터 속성의 상기 데이터를 삭제하도록 지정할 수 있다. 이로써, 어플리케이션의 실행 시에 불필요한 데이터를 리소스데이터 내에서 판별할 수 있다.

또한, 상기 최적화 정보는 상기 리소스데이터에서 삭제되는 메타데이터 중 일부의 내용을 리소스 이력 정보로 저장하도록 지정하며, 상기 어플리케이션의 설치용 팩키지 프로그램을 생성하는 단계는, 상기 리소스 이력 정보를 상기 팩키지 프로그램에 포함시키는 단계를 포함할 수 있다. 이로써, 리소스데이터의 디코딩 소요시간을 줄이면서도 차후 메타데이터의 참조가 필요한 상황에 대비할 수 있다.

여기서, 상기 최적화 정보는 상기 리소스데이터의 제1포맷을 상기 제1포맷 대비 상대적으로 데이터 크기의 효율이 높은 기 설정된 제2포맷으로 변환하도록 지정하며, 상기 제2리소스데이터를 생성하는 단계는, 제3리소스데이터의 포맷을 판단하고, 상기 제3리소스데이터를 상기 최적화 정보에 지정된 상기 제2포맷의 상기 제4리소스데이터로 변환하는 단계와; 기 설정된 플랫폼 상에서 상기 어플리케이션이 실행될 때에 상기 제3리소스데이터를 요청하는 동작에 응답하여 상기 제4리소스데이터가 반환되도록 상기 변환 이력을 상기 리소스 이력 정보에 기록하는 단계를 포함할 수 있다. 이로써, 리소스데이터를 보다 효율성이 높은 포맷으로 변환하면서도, 리소스데이터의 파일명 변경으로 인해 어플리케이션의 실행에 에러가 발생하는 것을 방지할 수 있다.

또는, 상기 제2리소스데이터를 생성하는 단계는, 상기 어플리케이션의 모든 상기 리소스데이터 중에서 제5리소스데이터와 중복되는 하나 이상의 제6리소스데이터를 삭제하는 단계와; 기 설정된 플랫폼 상에서 상기 어플리케이션이 실행될 때에 상기 제5리소스데이터를 요청하는 동작에 응답하여 상기 제6리소스데이터가 반환되도록 상기 삭제 이력을 상기 리소스 이력 정보에 기록하는 단계를 포함할 수 있다. 이로써, 중복되는 리소스데이터를 삭제하여 전체적인 용량을 줄이면서도, 리소스데이터의 삭제로 인해 어플리케이션의 실행에 에러가 발생하는 것을 방지할 수 있다.

또한, 상기 팩키지 프로그램을 저장하고, 상기 어플리케이션 실행장치의 요청에 응답하여 상기 팩키지 프로그램을 상기 어플리케이션 실행장치에 설치되도록 전송하는 단계를 더 포함할 수 있다. 이로써, 최적화된 팩키지 프로그램을 배포할 수 있다.

또한, 상기 어플리케이션은 웹 브라우저 프로그램 상에서 실행되는 웹 어플리케이션일 수 있다. 이로써, 리소스데이터를 직접 제어하는 네이티브 어플리케이션과 달리, 리소스데이터를 변경하더라도 어플리케이션 실행이 보장되도록 할 수 있다.

또한, 본 발명의 실시예에 따른 영상처리장치의 제어방법은, 주 프로그램과 상기 주 프로그램의 실행에 관한 복수의 속성의 데이터를 포함하는 제1리소스데이터를 포함하는 어플리케이션의 설치용 팩키지 프로그램을 수신하는 단계와; 상기 팩키지 프로그램을 해제하여 상기 어플리케이션을 실행 가능하게 설치하는 단계를 포함하며, 상기 어플리케이션을 설치하는 단계는, 상기 제1리소스데이터의 복수의 속성 중에서 상기 주 프로그램의 실행 시 이용 정도가 상대적으로 낮은 적어도 하나의 속성의 데이터를 배제하여 상기 제1리소스데이터보다 작은 데이터 크기를 가지는 제2리소스데이터를 생성하는 단계와; 상기 주 프로그램 및 상기 생성된 제2리소스 데이터를 포함하는 상기 어플리케이션을 설치하는 단계를 포함하는 것을 특징으로 한다. 이로써, 리소스데이터가 최적화되어 있지 않은 어플리케이션 팩키지를 수신하였을 때, 해당 어플리케이션 팩키지의 리소스데이터를 최적화시켜 설치함으로써 어플리케이션의 실행 시에 리소스데이터의 디코딩 소요시간을 줄일 수 있다.

도 1은 본 발명의 제1실시예에 따른 시스템의 예시도,
도 2는 도 1의 시스템에서, 서버 및 클라이언트 컴퓨터의 구성 블록도,
도 3은 도 1의 시스템에서, 디스플레이장치의 구성 블록도,
도 4는 도 3의 디스플레이장치에서, 신호처리부의 구성 블록도,
도 5는 도 1의 디스플레이장치의 플랫폼의 계층 구조를 나타내는 구성 블록도,
도 6은 도 1의 디스플레이장치의 웹 플랫폼의 계층 구조를 나타내는 구성 블록도,
도 7은 도 1의 시스템에서 어플리케이션이 제작 및 배포되는 과정을 나타내는 플로우차트,
도 8은 도 1의 시스템에서 어플리케이션 팩키지가 생성되는 과정을 나타내는 예시도,
도 9는 본 발명의 제2실시예에 따른 어플리케이션 팩키지가 생성되는 과정을 나타내는 예시도,
도 10은 본 발명의 제2실시예에 따라서 구현되는 속성 DB의 예시도,
도 11은 본 발명의 제2실시예에 따라서, PNG 이미지인 어느 한 리소스를 분석한 청크 리스트의 예시도,
도 12는 본 발명의 제2실시예에 따른 시스템 내에서 어플리케이션이 제작 및 배포되는 과정을 나타내는 플로우차트,
도 13은 본 발명의 제2실시예에 따라서 클라이언트 컴퓨터가 어플리케이션 팩키지를 생성하는 과정을 나타내는 플로우차트,
도 14는 본 발명의 제3실시예에 따른 리소스의 최적화 방법의 원리를 나타내는 예시도,
도 15는 본 발명의 제3실시예에 따른 디스플레이장치에서 어플리케이션을 실행하는 원리를 나타내는 예시도,
도 16은 본 발명의 제3실시예에 따른 속성 DB의 예시도,
도 17은 본 발명의 제3실시예에 따른 클라이언트 컴퓨터가 리소스를 최적화하는 과정을 나타내는 플로우차트,
도 18은 본 발명의 제3실시예에 따른 디스플레이장치에서 플랫폼이 어플리케이션으로부터 요청받은 리소스를 검색하는 과정을 나타내는 플로우차트,
도 19는 본 발명의 제4실시예에 따른 리소스의 최적화 방법의 원리를 나타내는 예시도,
도 20은 본 발명의 제4실시예에 따른 디스플레이장치에서 어플리케이션을 실행하는 원리를 나타내는 예시도,
도 21은 본 발명의 제4실시예에 따른 클라이언트 컴퓨터가 리소스를 최적화하는 과정을 나타내는 플로우차트,
도 22는 본 발명의 제4실시예에 따른 디스플레이장치에서 플랫폼이 어플리케이션으로부터 요청받은 리소스를 검색하는 과정을 나타내는 플로우차트,
도 23은 어플리케이션 팩키지의 리소스의 최적화의 효과의 예시를 나타내는 그래프,
도 24는 본 발명의 제5실시예에 따른 어플리케이션 팩키지가 생성되는 과정을 나타내는 예시도,
도 25는 본 발명의 제5실시예에 따른 시스템 내에서 어플리케이션이 제작 및 배포되는 과정을 나타내는 플로우차트,
도 26은 본 발명의 제6실시예에 따른 어플리케이션 팩키지가 생성되고 인스톨되는 과정을 나타내는 예시도,
도 27은 본 발명의 제6실시예에 따른 시스템 내에서 어플리케이션이 제작 및 배포되는 과정을 나타내는 플로우차트,
도 28은 본 발명의 제7실시예에 따른 시스템 내에서 어플리케이션이 제작 및 배포되는 과정을 나타내는 플로우차트이다.

이하에서는 첨부도면을 참조하여 본 발명에 따른 실시예들에 관해 상세히 설명한다. 이하 실시예들의 설명에서는 첨부된 도면들에 기재된 사항들을 참조하는 바, 각 도면에서 제시된 동일한 참조번호 또는 부호는 실질적으로 동일한 기능을 수행하는 구성요소를 나타낸다.

만일, 실시예에서 제1구성요소, 제2구성요소 등과 같이 서수를 포함하는 용어가 있다면, 이러한 용어는 다양한 구성요소들을 설명하기 위해 사용되는 것이며, 용어는 하나의 구성요소를 다른 구성요소와 구별하기 위하여 사용되는 바, 이들 구성요소는 용어에 의해 그 의미가 한정되지 않는다. 실시예에서 사용하는 용어는 해당 실시예를 설명하기 위해 적용되는 것으로서, 본 발명의 사상을 한정하지 않는다.

또한, 실시예에서는 본 발명의 사상과 직접적인 관련이 있는 구성들에 관해서만 설명하며, 그 외의 구성에 관해서는 설명을 생략한다. 그러나, 본 발명의 사상이 적용된 장치 또는 시스템을 구현함에 있어서, 이와 같이 설명이 생략된 구성이 불필요함을 의미하는 것이 아님을 밝힌다. 실시예에서 "포함하다" 또는 "가지다"와 같은 용어는 명세서 상에 기재된 특징, 숫자, 단계, 동작, 구성요소 또는 이들의 조합이 존재함을 지정하기 위한 것이며, 하나 이상의 다른 특징, 숫자, 단계, 동작, 구성요소 또는 이들의 조합이 존재하거나 부가되는 가능성을 배제하는 것은 아니다.

도 1은 본 발명의 제1실시예에 따른 시스템(1)의 예시도이다.

도 1에 도시된 바와 같이, 제1실시예에 따른 시스템(1)은 상호간에 통신 가능하도록 네트워크에 접속된 복수의 정보처리장치(100, 200, 300)를 포함한다. 정보처리장치(100, 200, 300)는 다양한 종류 및 특성의 정보, 데이터, 신호를 처리하는 제반 전자장치로 구현될 수 있는 바, 어느 한 가지 종류로 구현 형태를 한정할 수 없다. 시스템(1)을 구성하는 한 가지 예시로서, 본 실시예에 따른 시스템(1)은 서버(100)와, 클라이언트 컴퓨터(200)와, 디스플레이장치(300)를 포함한다.

서버(100)는 다양한 웹 기반의 컨텐츠를 저장하고, 디스플레이장치(300)의 요청에 따라서 해당 디스플레이장치(300)에 요청받은 컨텐츠를 제공할 수 있다. 이를 위해, 기본적으로 시스템(1)을 구성하는 서버(100) 및 디스플레이장치(300)는 상호간에 양방향 통신이 구축된다.

클라이언트 컴퓨터(200)는 일반적인 PC를 의미한다. 클라이언트 컴퓨터(200)는 디스플레이장치(300)와 마찬가지로, 서버(100)를 기준으로 할 때 클라이언트 역할을 수행한다. 특히, 본 실시예에서의 클라이언트 컴퓨터(200)는 서버(100)에 저장된 컨텐츠를 제작하여 제공할 수 있다.

디스플레이장치(300)는 예를 들면 TV로 구현되며, 방송국의 송출장비(미도시)로부터 방송 컨텐츠를 수신하여 방송영상을 표시하는 것 뿐만 아니라, 로컬 접속된 영상재생장치(미도시)로부터 다양한 영상컨텐츠를 제공받아 영상으로 표시할 수 있다. 또한, 디스플레이장치(300)는 네트워크를 통해 서버(100)에 접속할 수 있는 바, 서버(100)로부터 스트리밍 방식 또는 VOD(video-on-demand) 방식 등에 따라서 영상컨텐츠를 제공받을 수 있다. 또한, 디스플레이장치(300)는 서버(100)로부터 웹 페이지 또는 웹 어플리케이션과 같은 웹 기반의 컨텐츠를 제공받아 실행할 수 있다. 본 실시예에서는 디스플레이장치(300)가 TV인 것으로 설명하지만, 태블릿이나 모바일 폰 등과 같이 영상을 표시 가능한 다양한 형태의 장치가 적용될 수 있다.

도 2는 서버(100) 및 클라이언트 컴퓨터(200)의 구성 블록도이다.

도 2에 도시된 바와 같이, 서버(100)는 네트워크를 통해 클라이언트 컴퓨터(200) 또는 디스플레이장치(300)와 통신하는 서버통신부(110)와, 데이터가 저장되는 서버저장부(120)와, 서버(100)의 제반 동작을 제어하는 서버처리부(130)를 포함한다.

또한, 클라이언트 컴퓨터(200)는 네트워크를 통해 서버(100)와 통신하는 클라이언트 통신부(210)와, 데이터가 저장되는 클라이언트 저장부(220)와, 클라이언트 컴퓨터(200)의 제반 동작을 제어하는 클라이언트 처리부(230)를 포함한다.

이하, 클라이언트 컴퓨터(200)의 각 구성에 관해 설명한다. 클라이언트 컴퓨터(200) 및 서버(100)는 시스템(1) 내에서의 각각 클라이언트 역할과 서버 역할을 수행할 뿐, 기본적인 구조는 통상적인 의미의 컴퓨터에 해당한다. 따라서, 서버(100)의 각 구성은 기본적으로 클라이언트 컴퓨터(200)의 경우를 응용할 수 있다.

클라이언트 통신부(210)는 클라이언트 컴퓨터(200)가 서버(100) 등과 같은 외부장치와 양방향 통신이 가능하도록 데이터의 송수신을 수행한다. 클라이언트 통신부(210)는 각 통신규격에 따른 접속 포트 또는 접속 모듈의 집합체에 의해 구현될 수 있으며, 지원 가능한 프로토콜 및 통신 접속 대상이 어느 하나의 종류 또는 형식으로 한정되지 않는다. 예를 들면, 클라이언트 통신부(210)는 AP(미도시)와의 무선통신을 위한 와이파이 통신모듈(미도시), 별도의 유선 접속을 위한 이더넷 모듈(미도시)을 포함할 수 있다.

클라이언트 저장부(220)는 클라이언트 처리부(230)의 처리 및 제어에 따라서 다양한 데이터가 저장된다. 클라이언트 저장부(220)는 클라이언트 처리부(230)에 의해 억세스됨으로써, 데이터의 독취(read), 기록(write), 수정(edit), 삭제(delete), 갱신(update) 등이 수행된다. 클라이언트 저장부(220)는 전원의 제공 유무와 무관하게 데이터를 보존할 수 있도록 플래시메모리(flash-memory), 하드디스크 드라이브(hard-disc drive)와 같은 비휘발성 메모리로 구현된다.

클라이언트 처리부(230)는 클라이언트 컴퓨터(200)의 동작을 제어하고 클라이언트 컴퓨터(200)에서 발생하는 연산 처리를 수행한다. 예를 들면, 클라이언트 처리부(230)는 클라이언트 저장부(220)에 저장되어 있는 데이터를 처리하고, 처리된 데이터를 클라이언트 통신부(210)를 통해 서버(100)로 전송할 수 있다.

만일 어플리케이션의 개발자가 클라이언트 컴퓨터(200)를 사용하여 어플리케이션을 제작하는 경우라면, 클라이언트 처리부(230)는 개발자의 입력에 따라서 어플리케이션을 제작 처리하고, 제작된 어플리케이션의 최종 결과물을 서버(100)에 전송한다. 서버처리부(130)는 클라이언트 컴퓨터(200)로부터 수신되는 어플리케이션을 서버저장부(120)에 저장하며, 이후 디스플레이장치(300)로부터 어플리케이션의 요청을 수신하면 서버저장부(120)에 저장된 어플리케이션을 디스플레이장치(300)에 제공한다.

도 3은 디스플레이장치(300)의 구성 블록도이다.

도 3에 도시된 바와 같이, 디스플레이장치(300)는 외부로부터 데이터를 수신하는 통신부(310)와, 통신부(310)에 수신되는 전송스트림의 영상데이터에 기초하여 영상을 표시하는 표시부(320)와, 통신부(310)에 수신되는 전송스트림의 음성데이터에 기초하여 음성을 출력하는 스피커(330)와, 사용자에 의한 입력 동작이 실행되는 사용자입력부(340)와, 데이터가 저장되는 저장부(350)와, 디스플레이장치(300)의 제반 동작의 제어 및 연산을 실행하는 신호처리부(360)를 포함한다.

통신부(310)는 네트워크를 통해 외부로부터 다양한 데이터를 수신하는 바, 이러한 데이터의 예로는 다양한 영상소스로부터 전송되는 전송스트림이 있다. 통신부(310)는 외부로부터 전송되는 신호를 수신하기만 할 수 있는 것은 아니며, 반대로 외부에 신호를 전송함으로써 양방향 통신을 수행할 수 있다. 통신부(310)는 복수의 통신규격에 각기 대응하는 통신포트 또는 통신모듈의 집합체에 의해 구현되는 바, 지원 가능한 프로토콜 및 통신접속대상이 어느 하나의 종류 또는 형식으로 한정되지 않는다. 예를 들면, 통신부(310)는 RF 신호를 수신하는 RFIC(미도시), 무선 네트워크 통신을 위한 와이파이 통신모듈(미도시), 유선 네트워크 통신을 위한 이더넷 모듈(미도시), USB 메모리(미도시) 등의 로컬 접속을 위한 USB 포트(미도시) 등을 포함할 수 있다.

표시부(320)는 신호처리부(360)에 의해 처리되는 영상신호를 영상으로 표시한다. 표시부(320)의 구현 방식은 한정되지 않으며, 예를 들면 액정 또는 OLED 디스플레이 패널을 포함한다. 또한, 표시부(320)는 디스플레이 패널 이외에, 패널의 구현 방식에 따라서 부가적인 구성을 추가적으로 포함할 수 있다. 예를 들면, 액정 방식인 경우에, 표시부(320)는 액정 디스플레이 패널(미도시)과, 액정 디스플레이 패널(미도시)에 광을 공급하는 백라이트유닛(미도시)과, 액정 디스플레이 패널(미도시)을 구동시키는 패널구동기판(미도시) 등을 포함한다.

스피커(330)는 신호처리부(360)에 의해 처리되는 음성신호를 음성으로 출력한다. 스피커(330)는 음성신호에 따라서 공기를 진동시킴으로써 기압을 변화시키는 원리로 음성을 전달한다. 스피커(330)는 어느 한 채널의 음성신호에 대응하게 마련된 단위 스피커를 포함하며, 복수 채널의 음성신호에 각기 대응하도록 복수의 단위 스피커를 포함할 수 있다.

스피커(330)는 출력하는 음성의 주파수 대역에 따라서 다양한 종류가 있다. 스피커(330)는 20Hz 내지 99Hz 대역에 대응하는 서브우퍼(sub-woofer), 100Hz 내지 299Hz 대역의 우퍼(woofer), 300Hz 내지 499Hz 대역의 미드우퍼(mid-woofer), 500Hz 내지 2.9KHz 대역의 미드레인지(mid-range) 스피커, 3KHz 내지 6.9KHz 대역의 트위터(tweeter) 스피커, 7KHz 내지 20KHz 대역의 수퍼트위터(super-tweeter) 스피커 등이 있으며, 이 중에서 하나 이상의 종류가 선택되어 디스플레이장치(300)에 적용된다.

사용자입력부(340)는 사용자의 조작 또는 입력에 따라서 기 설정된 다양한 제어 커맨드 또는 정보를 신호처리부(360)에 전달한다. 사용자입력부(340)는 사용자의 의도에 따라서 사용자의 조작에 의해 발생하는 다양한 이벤트를 신호처리부(360)에 전달한다. 사용자입력부(340)는 정보의 입력방식에 따라서 다양한 형태로 구현될 수 있는 바, 예를 들면 디스플레이장치(300)의 외측에 설치된 버튼, 디스플레이장치(300)의 본체와 이격된 리모트 컨트롤러(remote controller), 표시부(320)에 일체화된 터치스크린(touch-screen), 그 외에 디스플레이장치(300)와 통신하게 마련된 입력장치 등이 가능하다.

저장부(350)는 신호처리부(360)의 처리 및 제어에 따라서 다양한 데이터가 저장된다. 저장부(350)는 신호처리부(360)에 의해 억세스됨으로써, 데이터의 독취, 기록, 수정, 삭제, 갱신 등이 수행된다. 저장부(350)는 디스플레이장치(300)의 시스템 전원의 제공 유무와 무관하게 데이터를 보존할 수 있도록 비휘발성 메모리로 구현된다.

신호처리부(360)는 통신부(310)에 수신되는 전송스트림에 대해 다양한 프로세스를 수행한다. 통신부(310)에 전송스트림이 수신되면, 신호처리부(360)는 전송스트림으로부터 추출되는 영상신호에 대해 영상처리 프로세스를 수행하고, 이러한 프로세스가 수행된 영상신호를 표시부(320)에 출력함으로써 표시부(320)에 영상이 표시되게 한다.

신호처리부(360)가 수행하는 영상처리 프로세스의 종류는 한정되지 않으며, 예를 들면 입력되는 전송스트림을 영상신호, 음성신호, 부가데이터의 각 하위 스트림으로 구분하는 디멀티플렉싱(de-multiplexing), 영상신호의 영상 포맷에 대응하는 디코딩(decoding), 인터레이스(interlace) 방식의 영상신호를 프로그레시브(progressive) 방식으로 변환하는 디인터레이싱(de-interlacing), 영상신호를 기 설정된 해상도로 조정하는 스케일링(scaling), 영상 화질 개선을 위한 노이즈 감소(noise reduction), 디테일 강화(detail enhancement), 프레임 리프레시 레이트(frame refresh rate) 변환 등을 포함할 수 있다.

신호처리부(360)는 신호 또는 데이터의 종류, 특성에 따라서 다양한 프로세스를 수행할 수 있으므로 신호처리부(360)가 수행 가능한 프로세스를 영상처리 프로세스로 한정할 수 없으며, 또한 신호처리부(360)가 처리 가능한 데이터가 통신부(310)에 수신되는 것만으로 한정할 수 없다. 예를 들면, 신호처리부(360)는 전송스트림으로부터 추출되는 음성신호에 대해 음성처리 프로세스를 수행하고, 이러한 프로세스가 수행된 음성신호를 스피커(330)로 출력한다. 또는, 신호처리부(360)는 디스플레이장치(300)에 사용자의 발화가 입력되면 기 설정된 음성인식 프로세스에 따라서 해당 발화를 처리한다. 신호처리부(360)는 이러한 여러 기능을 통합시킨 SOC(system-on-chip)로 구현되거나, 또는 각 프로세스를 독자적으로 수행할 수 있는 개별적인 칩셋(chip-set)들이 인쇄회로기판 상에 장착된 영상처리보드(미도시)로 구현된다.

본 실시예에 따른 신호처리부(360)는 통신부(310)를 통해 서버(100)에 소정의 어플리케이션을 요청할 수 있다. 해당 요청에 응답하여 서버(100)가 어플리케이션의 데이터를 전송하면, 신호처리부(360)는 통신부(310)에 수신되는 어플리케이션을 운영체제에 인스톨 및 실행한다. 만일, 통신부(310)에 수신되는 어플리케이션이 팩키지 상태라면, 신호처리부(360)는 어플리케이션 팩키지를 세부 파일 단위로 풀어서 인스톨을 수행한다.

이와 같은 디스플레이장치(300)의 하드웨어적인 구성은, 디스플레이장치(300)가 구현되는 형태 및 디스플레이장치(300)가 지원하는 기능에 따라서 세부적으로 차이가 있을 수 있다. 예를 들면, 디스플레이장치(300)가 TV나 셋탑박스라면 방송신호를 특정 주파수로 튜닝하기 위한 구성을 필요로 하겠지만, 디스플레이장치(300)가 태블릿이라면 해당 구성이 제외될 수도 있다.

이하, 디스플레이장치(300)가 TV인 경우에 신호처리부(360)의 구체적인 구성에 관해 설명한다.

도 4는 신호처리부(360)의 구성 블록도이다. 본 도면의 신호처리부(360)는 제품에서 실제로 구현되는 구성 중에서 기본적인 것만을 나타낸 바, 디스플레이장치(300)가 실제 제품으로 구현될 때에는 본 실시예에서 설명하는 것 이외의 구성을 추가적으로 포함한다.

도 4에 도시된 바와 같이, 통신부(310)는 방송스트림을 특정 주파수로 튜닝하는 튜너(tuner)(311)와, 무선통신을 위한 무선통신모듈(312)과, 유선통신을 위한 이더넷 모듈(313)을 포함한다. 그리고, 신호처리부(360)는 통신부(310)로부터 전달되는 전송스트림을 복수의 서브신호들로 구분하여 출력하는 디먹스(deMUX)(361)와, 디먹스(361)로부터 출력되는 서브신호 중 영상신호를 영상처리 프로세스에 따라서 처리하여 표시부(320)로 출력하는 영상처리부(362)와, 디먹스(361)로부터 출력되는 서브신호 중 음성신호를 음성처리 프로세스에 따라서 처리하여 스피커(330)로 출력하는 음성처리부(363)와, 신호처리부(360)의 동작을 위한 연산 및 제어를 수행하는 CPU(central processing unit)(364)를 포함한다.

튜너(311)는 RF 안테나(미도시)에 방송스트림이 수신되면, 지정된 특정 채널의 주파수로 방송스트림을 튜닝하여 전송스트림으로 변환한다. 튜너(311)는 안테나(미도시)로부터 전달되는 고주파 반송파를 중간주파수 대역으로 변환하고, 이를 디지털 신호로 변환함으로써, 전송스트림을 생성한다. 이를 위해 튜너(311)는 A/D 컨버터(미도시)를 가질 수 있는데, 설계 방식에 따라서는 A/D 컨버터(미도시)는 튜너(311)가 아닌 디모듈레이터(demodulator)(미도시)에 포함될 수도 있다.

디먹스(361) 또는 디멀티플렉서(demultiplexer)(361)는 기본적으로 멀티플렉서(미도시)와 반대의 역할을 수행한다. 즉, 디먹스(361)는 하나의 입력단을 복수의 출력단과 연결하여, 입력단에 입력되는 스트림을 선택신호에 따라서 각 출력단에 출력하는 분배 역할을 수행한다. 예를 들면, 하나의 입력단에 대해 네 개의 출력단이 있다면, 디먹스(361)는 0 또는 1의 상태를 가지는 두 개의 선택신호의 상태를 조합함으로써 네 개의 출력단 각각을 선택할 수 있다.

디먹스(361)는 특히 디스플레이장치(300)에 적용되는 경우에, 튜너(311)로부터 전달되는 전송스트림을 영상신호 및 음성신호의 서브신호들로 구분하여 각 출력단으로 출력한다.

디먹스(361)가 전송스트림을 서브신호들로 구분하는 방법은 여러 가지가 적용될 수 있는데, 예를 들면 디먹스(361)는 전송스트림 내의 패킷(packet)들에 각기 부여된 식별자인 PID(packet identifier)에 따라서 전송스트림을 각 서브신호들로 구분한다. 전송스트림 내의 채널 별 서브신호를 독립적으로 압축되어 패킷화되어 있으며, 어느 한 채널에 해당하는 패킷에는 동일한 PID가 부여됨으로써 다른 채널의 패킷과 구별되도록 마련된다. 디먹스(361)는 전송스트림에서 PID 별로 패킷들을 분류하여, 동일한 PID를 가지는 서브신호들을 추출한다.

영상처리부(362)는 디먹스(361)로부터 출력되는 영상신호를 디코딩 및 스케일링하여 표시부(320)에 출력한다. 이를 위해, 영상처리부(362)는 특정 포맷에 의해 인코딩된 상태의 영상신호에 대해 해당 인코딩 과정을 역으로 수행함으로써 영상신호를 인코딩 이전 상태로 복원시키는 디코더(decoder)(미도시)와, 디코딩된 영상신호를 표시부(120)의 해상도 또는 별도로 지정된 해상도에 맞게 스케일링하는 스케일러(scaler)(미도시)를 포함한다. 만일 디먹스(361)로부터 출력되는 영상신호가 특정 포맷으로 인코딩되어 있지 않은 무압축 상태라면, 영상처리부(362)는 해당 영상신호에 대해서는 디코더(미도시)에 의한 처리를 수행하지 않는다.

음성처리부(363)는 디먹스(361)로부터 출력되는 음성신호를 증폭 처리하여 스피커(330)에 출력한다. 이를 위해, 음성처리부(363)는 음성신호인 디지털신호를 출력하는 디지털신호 공급부(미도시)와, 디지털신호 공급부(미도시)로부터 출력되는 디지털신호에 기초하여 펄스폭 변조(pulse width modulation, PWM) 신호를 출력하는 PWM 처리부(미도시)와, PWM 처리부(미도시)로부터 출력되는 PWM 신호를 증폭시키는 증폭부(미도시)와, 증폭부(미도시)에 의해 증폭된 PWM 신호를 특정 수파수 대역으로 필터링함으로써 PWM 신호를 복조하는 LC 필터(미도시)를 포함한다.

CPU(364)는 신호처리부(360) 내의 제반 구성들이 동작하기 위한 중심적인 연산을 수행하는 구성으로서, 기본적으로 데이터의 해석 및 연산의 중심 역할을 수행한다. CPU(364)는 내부적으로, 처리할 명령어들이 저장되는 프로세서 레지스터(미도시)와, 비교, 판단, 연산을 담당하는 산술논리 연산 유닛(arithmetic logic unit, ALU)(미도시)와, 명령어의 해석과 올바른 실행을 위하여 CPU(364)를 내부적으로 제어하는 컨트롤 유닛(control unit)(미도시)과, 내부 버스(BUS)(미도시)와, 캐시(cache)(미도시) 등을 포함한다.

CPU(364)는 디먹스(361), 영상처리부(362) 및 음성처리부(363)와 같은 신호처리부(360)의 각 구성의 동작에 필요한 연산을 수행한다. 다만, 신호처리부(360)의 설계 방식에 따라서, 신호처리부(360)의 구성 중에는 CPU(364)의 데이터 연산 없이 동작하거나 또는 별도의 마이크로 컨트롤러(micro-controller)(미도시)에 의해 동작하는 구성도 있을 수 있다.

이하, 디스플레이장치에서 어플리케이션이 실행되는 원리에 관해 설명한다.

도 5는 디스플레이장치의 플랫폼(400)의 계층 구조를 나타내는 구성 블록도이다.

도 5에 도시된 바와 같이, 디스플레이장치의 플랫폼(400)은 가장 하위에 있는 하드웨어(410) 상에, 하드웨어(410)를 제어하기 위한 운영체제 및 드라이버(420)가 있으며, 운영체제(420) 상에서 실행되는 어플리케이션(430)으로 구성된다.

하드웨어(410)는 예를 들면 앞선 도 3 관련 설명한 디스플레이장치(300, 도 3 참조)의 제반 구성, 특히 신호처리부(360, 도 3 참조)를 포함한다.

운영체제(420)는 디스플레이장치의 하드웨어(410)를 관리하며, 제반 어플리케이션(430)을 실행하기 위해 하드웨어 추상화 플랫폼 및 공통 시스템 서비스를 제공하는 시스템 소프트웨어이다. 운영체제(420)는 실행되는 어플리케이션(430)이 CPU 등을 비롯한 시스템 자원들을 사용할 수 있도록 제공하고, 이들을 추상화하여 파일 시스템 등의 서비스를 제공한다. 운영체제(420)는 기본적으로 사용자에게 어플리케이션을 쉽고 효율적으로 실행할 수 있는 환경을 제공하고, 디스플레이장치의 하드웨어(410) 및 소프트웨어 자원을 효율적으로 할당, 관리 및 보호하며, 잘못된 자원 사용의 감시와, 입출력 장치 등의 자원에 대한 연산과 제어를 관리한다.

드라이버(420)는 하드웨어(410)를 제어하기 위한 커널의 일부분으로 동작하는 프로그램이다. 드라이버(420)는 시스템 버스 또는 하드웨어(410)에 연결된 통신 하위 시스템을 통해 장치와 통신을 수행하며, 어플리케이션(430)이 드라이버(420)의 명령어를 호출하면 장치에 명령어를 전달한다. 장치가 드라이버(420)에 데이터를 리턴하면, 드라이버(420)는 어플리케이션(430)의 명령어로 데이터를 다시 전달한다. 드라이버(420)는 하드웨어(410)에 의존하며 특정한 운영체제(420)를 따른다. 일반적으로, 드라이버(420)는 장치 칩의 레지스터에 억세스하여 하드웨어(410)를 제어하며, 하드웨어(410)와 주변기기를 사용하는 어플리케이션(430)의 링크 역할을 수행한다. 드라이버(420)는 운영체제(420)의 하위 구성으로 포함될 수 있다.

어플리케이션(430), 또는 어플리케이션 소프트웨어는 넓은 의미로는 운영체제(420) 상에서 실행되는 모든 소프트웨어를 의미하며, 좁은 의미로는 운영체제(420) 상에서 사용자가 직접 핸들링하는 소프트웨어를 의미한다. 후자의 경우로 한정하면, 어플리케이션(430)은 부트로더(boot-loader), 운영체제 및 드라이버(420)와 같은 시스템 소프트웨어의 여집합으로 볼 수 있다.

어플리케이션(430)은 네이티브(Native) 어플리케이션(430)과 웹(Web) 어플리케이션(430)으로 구분된다.

네이티브 어플리케이션(431)은 디스플레이장치에 다운로드되어 로컬에 저장되는 바이너리 실행 파일이다. 네이티브 어플리케이션(431)은 운영체제(420)에서 제공하는 API(application programming interface)에 직접 액세스할 수 있으며, 운영체제(420)의 고유 기능을 활용한다.

네이티브 어플리케이션(431)은 다음과 같은 과정으로 제작된다. 개발자는 먼저 소스 코드를 작성하고, 이미지, 오디오, 동영상 등과 같은 리소스(resource)를 만든다. 개발자는 운영체제(420)가 지원하는 툴(tool)을 통해 소스 코드를 컴파일하고 리소스를 첨부하여, 배포를 위한 바이너리 형태의 실행파일을 만든다. 상기한 툴은 소프트웨어 개발 키트라고 하며 운영체제(420) 별로 고유한 툴을 제공한다. 운영체제(420) 별로 툴이 상이하다는 것은, 어느 한 플랫폼에 맞게 제작된 네이티브 어플리케이션(431)이 다른 플랫폼 상에서 사용될 수 없거나 또는 사용되기 곤란하다는 것을 의미한다. 리소스에 관련된 보다 자세한 내용은 후술한다.

웹 어플리케이션(433)은 네이티브 어플리케이션(431)처럼 디스플레이장치에 다운로드되어 로컬에 저장될 수 있다. 그러나, 웹 어플리케이션(433)은 계층 구조 측면에서 운영체제(420)의 바로 위에 위치한 네이티브 어플리케이션(431)과 달리, 웹 브라우저 프로그램(Web-browser program)(432) 또는 브라우저 프로그램(432) 상에 위치한다. 이는, 웹 어플리케이션(433)은 단독으로 운영체제(420) 상에서 실행될 수 없으며, 먼저 브라우저 프로그램(432)이 실행된 이후에 이 브라우저 프로그램(432) 상에서 실행되어야 한다는 것을 의미한다.

브라우저 프로그램(432)은 특성 상 네이티브 어플리케이션(431) 중의 하나이다. 브라우저 프로그램(432)은 인터넷의 웹 페이지나, 웹 어플리케이션(433)을 실행하기 위한 어플리케이션이다. 브라우저 프로그램(432)은 예를 들면 HTML 표준을 따라서 제작된 웹 페이지나 웹 어플리케이션(433)을 실행하여 표시하며, CSS3(cascading style sheets 3) 및 고급 자바스크립트(JavaScript)와 같은 HTML5의 최신 기능을 지원할 수 있다.

브라우저 프로그램(432)은 여러 가지의 운영체제(420)의 플랫폼에서 실행될 수 있도록 범용으로 제작되어 적용되므로, 웹 어플리케이션(433)은 네이티브 어플리케이션(431)과 달리 멀티 플랫폼을 지원한다. 즉, 네이티브 어플리케이션(431)이 멀티 플랫폼을 지원하기 위해서는 각 플랫폼 별로 소스 코드가 별도로 제작되어야 한다. 이에 비해, 웹 어플리케이션(433)은 어느 한 브라우저 프로그램(432) 상에서 실행되도록 제작되기만 하면, 해당 브라우저 프로그램(432)이 구동하는 모든 플랫폼 상에서 실행될 수 있다.

브라우저 프로그램(432)이 영상으로 표시될 때에, 브라우저 프로그램(432)은 웹 페이지 또는 웹 어플리케이션(433)의 영상이 표시되는 영역인 웹뷰(webview)와, 웹뷰를 둘러싼 형태로 표시되며 웹 페이지 또는 웹 어플리케이션(433)에 관련된 기능을 조정하는 옵션을 가진 브라우징 프레임(browsing frame)을 포함한다.

네이티브 어플리케이션(431)은 기계어로 번역된 상태에서 배포되는 것에 비해, 웹 어플리케이션(433)은 기계어로 번역되지 않은 상태에서 배포되며 브라우저 프로그램(432)에 의해 기계어로 번역되어 실행된다.

웹 어플리케이션(433)이 운영체제(420)와 직접 연동하여 독립적으로 실행되는 네이티브 어플리케이션(431)과 달리, 브라우저 프로그램(432) 내에서 실행된다는 것은 다음과 같은 사항을 의미한다. 브라우저 프로그램(432)은 네이티브 어플리케이션(431)의 일종이므로 그 자체가 운영체제(420)의 API에 직접 억세스할 수 있지만, 브라우저 프로그램(432) 내에서 실행되는 웹 어플리케이션(433)은 억세스할 수 있는 운영체제(420)의 API의 수에 제한이 있다. 즉, 네이티브 어플리케이션(431)은 운영체제(420) 및 하드웨어(410)에 대해 대폭적인 억세스 권한을 가지는 것에 비해, 웹 어플리케이션(433)은 운영체제(420) 및 하드웨어(410)에 대해 제한적인 억세스 권한만을 가진다.

이러한 네이티브 어플리케이션(431) 및 웹 어플리케이션(433)의 차이로 인해, 일 어플리케이션의 실행 시에 리소스 관리에서 서로 차이가 발생하는 바, 이에 관한 자세한 설명은 후술한다.

이하, 웹 어플리케이션에 포커스를 맞춘 웹 플랫폼의 구조에 관해 설명한다.

도 6은 디스플레이장치의 웹 플랫폼(500)의 계층 구조를 나타내는 구성 블록도이다. 웹 플랫폼(500)은 앞선 도 5의 플랫폼(400, 도 5 참조)으로부터, 웹 어플리케이션(540)의 실행에 관련된 구조를 보다 구체적으로 나타낸 것이다.

도 6에 도시된 바와 같이, 웹 플랫폼(500)은 가장 하위 계층에 운영체제(510)가 있으며, 운영체제(510) 상에 윈도우 관리자(520)가 있고, 윈도우 관리자(520) 상에 웹 엔진(530) 및 API(550)가 있다. 웹 어플리케이션(540)은 웹 엔진(530) 및 API(550) 상에서 실행된다. 또한, 웹 엔진(530)은 렌더링 엔진(531), JS 엔진(532)을 포함한다. 여기서, API(550)는 OpenGL(551) 및 WebGL(552)을 포함한다. 웹 엔진(530) 및 윈도우 관리자(520)는 브라우저 프로그램에 속한다.

윈도우 관리자(520)는 브라우징 프로그램에 의한 복수의 윈도우의 처리 및 표시를 관리한다. 여기서 지칭하는 윈도우는, 브라우징 프로그램의 영상이 포함하는 브라우징 프레임 및 웹뷰를 의미한다. 윈도우 관리자(520)는 웹 엔진(530)의 하위 계층에서, 웹 엔진(530)에 의해 표시되는 윈도우인 웹뷰를 브라우징 프레임과 조합시킴으로써 전체적인 브라우징 영상을 표시하도록 처리한다.

웹 엔진(530)은 웹뷰에 웹 어플리케이션(540) 또는 웹 페이지의 영상이 표시되도록 처리한다. 윈도우 관리자(520)와 비교할 때, 웹 엔진(530)은 웹 어플리케이션(540) 영상 처리를 수행하는 것에 비해, 윈도우 관리자(520)는 웹 엔진(530)에 의해 표시되는 웹 어플리케이션(540)의 윈도우를 별도의 타 윈도우와 함께 표시되도록 하는 차이가 있다. 즉, 웹 엔진(530)은 웹 어플리케이션(540)의 렌더링에만 관여한다.

렌더링 엔진(531)은 웹 코어(web core)라고도 지칭한다. 렌더링 엔진(531)은 웹 페이지의 HTML 및 CSS 구조 또는 웹 어플리케이션(540)을 분석하고, 분석 결과를 영상으로 표시되게 렌더링한다. 렌더링 엔진(531)의 예시로는 웹킷(Webkit) 엔진과 게코(Gecko) 엔진이 있는데, 웹킷 엔진은 최초 리눅스 플랫폼에서 동작하기 위해 제작된 오픈소스 엔진으로부터 출발하였다. 웹킷 엔진의 렌더링 클래스는 C++ 컴파일러 내에 포함되어 있는 기능인 RTTI(runtime type information) 기법을 사용한다. RTTI는 오브젝트의 유형을 실행 시에 결정할 수 있도록 허락하는 방식이다.

JS 엔진(532)은 JS 파서(parser)라고도 지칭한다. JS 엔진(532)은 웹 페이지의 자바 스크립트 코드를 분석하여, 실행되도록 처리한다.

API(550)는 어플리케이션이 사용할 수 있도록, 운영체제(510) 또는 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 의미한다. 즉, API(550)는 어플리케이션이 해당 어플리케이션을 지원하는 다른 프로그램에 대해 어떤 처리를 위해서 호출할 수 있는 서브루틴 또는 함수의 집합이다. API(550)는 어플리케이션 내에서 실행을 위해 특정 서브루틴에 연결을 제공하는 함수를 호출하는 것으로 구현된다. 그러므로 하나의 API(550)는 함수의 호출에 의해 요청되는 작업을 수행하기 위해 이미 존재하거나 또는 연결되어야 하는 몇 개의 프로그램 모듈이나 루틴을 가진다.

OpenGL(551)은 1992년 실리콘 그래픽스에서 만든 2차원 및 3차원 그래픽 표준 API 규격으로서, 프로그래밍 언어 사이 또는 플랫폼 사이의 교차 응용 프로그래밍을 지원한다. OpenGL(551)은 약 250여개 가량의 함수 호출을 이용하여 단순한 기하도형에서부터 복잡한 3차원 장면의 생성이 가능하게 한다.

그래픽 라이브러리(graphic library)는 구체성을 기준으로 하여 고수준과 저수준으로 분류되는데, OpenGL(551)은 저수준 라이브러리에 속한다. VRML(virtual reality modeling language)과 같은 고수준 라이브러리는 물체간의 관계를 정의함으로써 장면을 그려낸다. 이에 비해 저수준 라이브러리는 모델링보다는 렌더링 기능에 중점을 두며, 세부적인 명령을 일일이 전달함으로써 물체의 가장 기본적인 요소를 그린다. 저수준 라이브러리는 고수준 라이브러리에 비해 사용 방법이 더 어렵지만 보다 세밀한 부분까지 그릴 수 있다.

OpenGL(551)은 GL 및 GLU의 두 가지 라이브러리를 포함한다. GL은 기본적인 그리기 기능을 제공하는 핵심 라이브러리로서, OpenGL(551)의 본체에 해당한다. GL은 기초 도형을 렌더링하는 함수들을 포함한다. 한편, GLU는 GL을 보조하는 유틸리티 라이브러리이다. GLU는 분할, 투영 등의 고급 기능을 제공하며, 입체 도형을 생성하는 편의 기능도 제공한다.

WebGL(552)은 웹 기반의 그래픽 라이브러리이다. WebGL(552)은 자바 스크립트 언어를 통해서 사용할 수 있으며, 호환성을 가진 웹 브라우저에서 인터랙티브한 3차원 그래픽을 사용할 수 있도록 제공한다. WebGL(552)은 플러그인의 사용 없이 3차원 그래픽스 API를 제공하는 캔버스 HTML 요소의 일부분이다.

WebGL(552)은 OpenGL ES 2.0을 기반으로 하며, 3차원 그래픽을 사용하기 위한 프로그래밍 인터페이스를 제공한다. 여기서, OpenGL ES는 임베디드 단말을 위한 OpenGL이다. OpenGL ES는 3차원 컴퓨터 그래픽스 API인 OpenGL의 서브셋으로, 휴대전화, PDA 등과 같은 임베디드 단말을 위한 API이다.

웹 어플리케이션(540)의 그래픽 오브젝트의 표시를 위해서는, 해당 그래픽 오브젝트에 대해 OpenGL(551)이 호출됨으로써 텍스처에 로딩되어야 한다. 그러나, 웹 기반의 그래픽 오브젝트의 경우에, 바로 OpenGL(551)의 함수를 호출하는 것은 설계 구조상 용이하지 않을 수 있다. 이에, 그래픽 오브젝트에 대해 WebGL(552)의 함수가 호출되고, 호출된 WebGL(552)의 함수에 의해 다시 OpenGL(551)의 대응 함수가 호출되는 방식이 적용된다. 즉, 웹 기반의 그래픽 오브젝트는 WebGL(552)의 호출 과정을 거쳐서 OpenGL(551)을 호출한다.

이하, 어플리케이션이 제작 및 배포되는 과정에 관해 설명한다.

도 7은 시스템(1) 내에서 어플리케이션이 제작 및 배포되는 과정을 나타내는 플로우차트이다.

도 7에 도시된 바와 같이, S110 단계에서 클라이언트 컴퓨터(200)는 어플리케이션의 구동을 위해 필수적인 실행 프로그램과, 실행 프로그램에 의해 선택적으로 호출 및 사용되는 리소스를 제작한다.

S120 단계에서 클라이언트 컴퓨터(200)는 실행 프로그램 및 리소스에 인스톨 정보를 첨부하여 팩키징함으로써, 어플리케이션 팩키지를 생성한다. 인스톨 정보는 차후 어플리케이션이 디스플레이장치(300)에 인스톨될 때에 참조되는 정보로서, 예를 들면 어플리케이션 내의 실행 프로그램 및 리소스가 디스플레이장치(300)의 운영체제에 복사되는 데이터 위치 또는 데이터 주소를 지정한다.

팩키징 단계에서는 배포가 용이하도록 기 설정된 압축포맷으로 압축되어 단일 파일로 마련될 수 있다. 어플리케이션 팩키지의 예시로는, 안드로이드 플랫폼의 APK(android package) 파일이 있다.

S130 단계에서 클라이언트 컴퓨터(200)는 어플리케이션 팩키지를 서버(100)에 전송한다.

S140 단계에서 서버(100)는 클라이언트 컴퓨터(200)로부터 수신되는 어플리케이션 팩키지를 등록 및 저장한다.

S150 단계에서 서버(100)는 디스플레이장치(300)로부터 어플리케이션 팩키지의 요청을 수신한다. 이에, S160 단계에서 서버(100)는 해당 요청에 대응하는 어플리케이션 팩키지를 디스플레이장치(300)에 전송한다.

S170 단계에서 디스플레이장치(300)는 서버(100)로부터 수신되는 어플리케이션 팩키지의 압축을 풀어서 실행 프로그램, 리소스, 인스톨 정보 등의 내부 데이터를 추출하고, 인스톨 정보에 따라서 어플리케이션을 운영체제 상에 인스톨한다.

S180 단계에서 디스플레이장치(300)는 인스톨된 어플리케이션을 실행한다.

이와 같이, 본 실시예에서는 클라이언트 컴퓨터(200)에서 어플리케이션의 제작 및 팩키징이 수행되며, 그 결과물인 어플리케이션 팩키지가 서버(100)에 전달된다.

이하, 어플리케이션의 팩키지 과정에 관해 보다 자세히 설명한다.

도 8은 어플리케이션 팩키지(640)가 생성되는 과정을 나타내는 예시도이다.

도 8에 도시된 바와 같이, 개발자는 먼저 어플리케이션의 실행 프로그램(610)과, 하나 이상의 리소스(620)를 제작한다.

실행 프로그램(610)은 어플리케이션의 구동을 위해 실행되는 프로그램 코드이다. 실행 프로그램은 어플리케이션의 기능을 구현하기 위한 필수적인 데이터로서, 대표적으로 실행에 필요한 소스 코드 및 컴파일된 결과물을 포함한다. 실행 프로그램(610)의 예시로는, APK 파일에서 Classes.dex 파일이 있다.

리소스(620)는 실행 프로그램(610)가 어플리케이션을 실행하는 과정에서 선택적으로 사용되는 데이터로서, 예를 들면 이미지, 동영상, 음성, 텍스트, 폰트 등이 있다. 리소스(620)의 예시로는, APK 파일에서 Asset 폴더 및 Res 폴더 내의 파일, Resource.arsc 파일 등이 있다.

실행 프로그램(610) 및 리소스(620)가 마련되면, 개발자는 팩키징 과정을 실행시킨다. 팩키징 과정은 개발자의 클라이언트 컴퓨터에서 실행된다. 팩키징 시에는 실행 프로그램(610), 리소스(620), 인스톨 정보(630)가 통합하여 압축된다. 압축이 완료되면 배포 가능한 어플리케이션 팩키지(640)가 생성된다.

그런데, 이러한 리소스(620)는 개발자가 의도하지 않는 부가데이터를 포함할 수도 있다. 대표적인 부가데이터로는 메타데이터가 있는데, JPEG 규격의 이미지인 경우에는 JFIF나 Exif 데이터, PNG 규격의 이미지인 경우에는 tExt 청크(chunk), MP3 규격의 음성인 경우에는 ID3 태그(tag) 등이 있다. 즉, 개발 과정에서 개발자는 리소스(620)의 이미지, 동영상, 음성 등의 메인 데이터만을 필요로 하지만, 실제 리소스(620)는 메인 데이터 뿐만 아니라 추가적으로 메타데이터를 포함할 수도 있다. 이러한 경우에 메타데이터는 어플리케이션의 실행 및 동작에 관여하거나 참조되는 데이터가 아니므로, 어플리케이션의 입장에서는 불필요한 데이터이다.

리소스(620)에 포함되는 메타데이터는 팩키징 시에 어플리케이션 팩키지(640)에 포함되므로, 어플리케이션 팩키지(640)의 전체 용량을 증가시킨다. 이는, 어플리케이션 팩키지(640)의 배포 과정에서 통신 자원의 소요를 증가시키고, 또한 디스플레이장치에서 어플리케이션의 디코딩 시간을 지연시키며, 디스플레이장치에서의 인스톨 및 실행 시간을 지연시킨다.

이하, 상기한 문제점을 해소하기 위한 제2실시예에 관해 설명한다.

도 9는 본 발명의 제2실시예에 따른 어플리케이션 팩키지(760)가 생성되는 과정을 나타내는 예시도이다.

도 9에 도시된 바와 같이, 제2실시예에 따르면, 개발자는 어플리케이션의 실행 프로그램(710)과, 하나 이상의 리소스(720)를 제작한다.

실행 프로그램(710) 및 리소스(720)의 제작이 완료되면, 개발자의 클라이언트 컴퓨터는 팩키징 과정을 실행한다. 팩키징 과정에서, 클라이언트 컴퓨터는 속성 DB(730)를 참조하여 리소스(720)의 최적화 과정을 수행한다. 리소스(720)의 최적화 과정이 완료되면, 최적화된 리소스(720)와, 최적화에 따른 리소스(720)의 변경 상태에 대응하는 리소스 정보(740)가 도출된다.

클라이언트 컴퓨터는 실행 프로그램(710)과, 최적화 과정이 완료된 최적화된 리소스(720)와, 리소스 정보(740) 및 인스톨 정보(750)를, 기 설정된 압축포맷에 따라서 함께 압축한다. 이와 같은 팩키징 과정이 완료되면, 어플리케이션 팩키지(760)가 생성된다.

본 실시예가 앞선 도 8 관련 실시예와 상이한 점은, 속성 DB(730)에 기초하여 리소스(720)의 최적화 과정을 추가적으로 수행한다는 점이다. 이러한 최적화 과정을 통해, 메타데이터와 같이 어플리케이션의 실행 시에 불필요한 데이터를 리소스(720)에서 제거함으로써, 리소스(720)의 용량을 줄이고 최종적으로 어플리케이션 팩키지(760)의 용량을 줄일 수 있다. 또한, 리소스(720)의 용량을 줄임으로써, 어플리케이션의 디코딩 시간을 줄일 수 있다.

이와 같은 리소스(720)의 최적화 과정은 웹 어플리케이션의 제작 시에 적용되는 반면, 네이티브 어플리케이션의 제작 시에 적용되는 것은 곤란하다. 이는, 네이티브 어플리케이션이 직접 리소스(720)를 관리하기 때문인데, 네이티브 어플리케이션은 리소스(720)를 어떻게 디코딩할 것인지 또는 리소스(720)의 어떤 데이터를 사용할 것인지 직접 결정한다. 네이티브 어플리케이션을 구동시키는 플랫폼은 단지 네이티브 어플리케이션의 요청에 따라서 리소스(720)를 데이터 그대로 전달해주는 역할만 수행한다. 따라서, 어플리케이션의 팩키징 과정에서 리소스(720)를 변경하는 것은 어플리케이션의 오동작을 유발할 위험이 있다.

반면, 웹 어플리케이션은 직접 리소스(720)를 관리하는 것이 아닌, 웹 어플리케이션을 구동시키는 플랫폼이 리소스(720)의 관리를 대행한다. 즉, 웹 어플리케이션은 리소스(720)를 관리하는 별도의 관리자, 즉 브라우저 프로그램 상에서 실행된다. 따라서, 웹 어플리케이션의 경우에는 네이티브 어플리케이션의 경우와 달리 리소스(720)의 변경에 대응할 수 있다.

클라이언트 컴퓨터가 리소스(720) 최적화 과정을 실행함에 있어서, 리소스(720)의 어떤 데이터 블록(data block), 즉 어떤 청크를 삭제하고 어떤 청크를 남길 것인가에 관한 기준이 사전에 결정되어 있어야 한다. 이 기준이 기록된 것이 속성 DB(730)이다.

도 10은 속성 DB(730)의 구현 예시도이다.

도 10에 도시된 바와 같이, 속성 DB(730)는 리소스의 종류와, 각 리소스의 청크의 속성 중에서 유지해야 할 유지대상 속성, 리소스 정보로 이동해야 할 이동대상 속성, 리소스에서 삭제해야 할 삭제대상 속성을 지정한 정보를 포함한다.

여기서, 속성 DB(730)가 각 리소스 별로 유지대상 속성, 이동대상 속성, 삭제대상 속성을 모두 지정할 수도 있고 그렇지 않을 수도 있다. 예를 들면, 속성 DB(730)에 유지대상 속성 및 이동대상 속성만을 지정하고, 이들 속성에 해당하지 않는 속성은 삭제대상 속성으로 판단될 수 있다. 또는, 속성 DB(730)에 이동대상 속성 및 삭제대상 속성만을 지정하고, 이들 속성에 해당하지 않는 속성은 유지대상 속성으로 판단될 수 있다. 본 실시예에서는 세 가지 속성이 모두 지정된 것으로 표현하지만, 이는 하나의 예시일 뿐임을 밝힌다.

예를 들어 PNG 이미지 파일이 포함하는 청크의 속성으로는 IHDR, sBIT, pHYs, IDAT, IEND, tEXT, prVW, mkBF, mkTS, mkBS, mkBT, iTXt 등이 있다. 이러한 속성의 명칭은 PNG 규약에서 정해진 것이므로, 자세한 설명을 생략한다. 이 중에서, 이미지 헤더인 IHDR, 이미지 데이터인 IDAT, 이미지 트레일러인 IEND는 PNG 이미지에서 필수적인 청크이며, 텍스트에 관련된 tEXT, iTXt 등은 보조적인 청크이다. prVW, mkBF 등은 어플리케이션을 구현함에 있어서 불필요한 청크이다.

속성 DB(730)는 이와 같이 어플리케이션의 동작 시에 필요한지 사전에 결정되어, 청크의 속성 별로 적용 대상이 지정된다. PNG 이미지 리소스의 예를 들면, IHDR, sBIT, pHYs, IDAT, IEND 속성의 청크는 리소스에서 그대로 유지되고, tEXT 속성의 청크는 리소스에서 삭제하되 해당 청크의 내용을 리소스 정보에 추가하며, prVW, mkBF, mkTS, mkBS, mkBT, iTXt 속성의 청크는 리소스에서 삭제하고 해당 청크의 내용을 리소스 정보에 추가하지 않도록 지정될 수 있다.

여기서, 리소스에서 삭제하되 리소스 정보에 그 내용을 추가하는 속성은 다양한 요인에 따라서 결정될 수 있다. 리소스 정보에 추가되는 속성은, 어플리케이션의 실행 시에 필요하지는 않지만, 차후에 참조가 필요할 상황이 발생이 예상되는 경우에 지정될 수 있다. 이미지 리소스의 예를 들면 이미지 데이터의 관련 정보를 기록한 텍스트 청크가 이러한 속성에 해당할 수 있는데, 실제 어플리케이션의 실행 시에는 이미지 데이터만 필요하지만 어플리케이션 실행 이외의 상황에서 해당 이미지 데이터의 관련 정보가 필요할 수도 있다. 이를 위해, 해당 청크의 내용을 리소스 정보로 보존할 수 있다. 다만, 이는 하나의 가능한 예시일 뿐임을 밝힌다.

본 실시예에서는 PNG 이미지 리소스의 경우에 관해서만 설명하였으나, JPEG 이미지 리소스, MP3 음성 리소스 등등 다양한 리소스 별로 이러한 원리가 적용됨으로써 속성 DB(730)가 구현된다.

도 11은 PNG 이미지인 어느 한 리소스를 분석한 청크 리스트(770)의 예시도이다.

도 11에 도시된 바와 같이, 클라이언트 컴퓨터는 각 리소스에 대해 속성 DB의 지정 내용에 기초하여 리소스의 최적화 동작을 수행한다. 예를 들면, 클라이언트 컴퓨터는 PNG 이미지인 어느 한 리소스에 대해, 해당 리소스를 구성하는 각 청크의 속성을 분석하여, 도면 좌측과 같은 청크 리스트(770)를 생성한다. 청크 리스트(770)에는 청크 별로 속성과, 해당 속성의 간단한 설명, 길이, CRC 값 등의 나타나 있다.

클라이언트 컴퓨터는 청크 리스트(770) 상의 청크 중에서, 속성 DB에 정의된 대로, IHDR, sBIT, pHYs, IDAT, IEND 속성의 청크를 남기고, tEXT, prVW, mkBF, mkTS, mkBS, mkBT, iTXt 속성의 청크를 삭제한다. 그리고, 클라이언트 컴퓨터는 삭제된 청크 중에서, tEXT 속성의 청크에 대해서는 해당 청크의 내용을 리소스 정보에 추가한다.

이와 같이 PNG 리소스에서 일부 청크가 삭제되면, 도면 우측과 같은 청크 리스트(780)와 같은 결과가 나온다. 최적화 이전의 청크 리스트(770)와 최적화 이후의 청크 리스트(780)를 비교하면, 후자가 전자에 비해 리소스의 데이터 양이 대폭 감소된 것을 알 수 있다. 클라이언트 컴퓨터는 PNG 뿐만 아니라 모든 리소스에 대해 이러한 원리에 따라서 최적화를 수행하며, 최적화된 리소스로 어플리케이션 팩키지를 생성한다.

이하, 본 실시예에 따라서 어플리케이션이 제작 및 배포되는 과정에 관해 설명한다.

도 12는 본 발명의 제2실시예에 따른 시스템(1) 내에서 어플리케이션이 제작 및 배포되는 과정을 나타내는 플로우차트이다. 본 실시예에서의 서버(100), 클라이언트 컴퓨터(200), 디스플레이장치(300)의 기본적인 구조는 앞선 실시예와 동일하다.

도 12에 도시된 바와 같이, S210 단계에서 클라이언트 컴퓨터(200)는 어플리케이션의 구동을 위해 필수적인 실행 프로그램과, 실행 프로그램에 의해 선택적으로 호출 및 사용되는 리소스를 제작한다.

S220 단계에서, 클라이언트 컴퓨터(200)는 리소스의 최적화를 수행한다. 리소스의 최적화 과정은 앞서 설명한 바와 같으며, 그 결과 리소스가 최적화되고 리소스 정보가 생성된다. 리소스의 최적화 방식에 따라서는 리소스 정보는 생성되지 않을 수도 있다.

S230 단계에서, 클라이언트 컴퓨터(200)는 실행 프로그램 및 리소스에 인스톨 정보를 첨부하여 팩키징함으로써, 어플리케이션 팩키지를 생성한다. 만일 앞선 S220 단계에서 리소스 정보가 생성되었다면, 클라이언트 컴퓨터(200)는 어플리케이션 팩키지에 리소스 정보도 포함시킨다.

S240 단계에서 클라이언트 컴퓨터(200)는 어플리케이션 팩키지를 서버(100)에 전송한다.

S250 단계에서 서버(100)는 클라이언트 컴퓨터(200)로부터 수신되는 어플리케이션 팩키지를 등록 및 저장한다.

S260 단계에서 서버(100)는 디스플레이장치(300)로부터 어플리케이션 팩키지의 요청을 수신한다. 이에, S270 단계에서 서버(100)는 해당 요청에 대응하는 어플리케이션 팩키지를 디스플레이장치(300)에 전송한다.

S280 단계에서 디스플레이장치(300)는 서버(100)로부터 수신되는 어플리케이션 팩키지로부터 실행 프로그램, 리소스, 인스톨 정보를 복원하고, 어플리케이션을 인스톨 정보에 따라서 운영체제 상에 인스톨하여 실행한다.

다만, 리소스 정보는 어플리케이션의 실행에 필요하지 않으므로, 디스플레이장치(300)는 어플리케이션의 실행 시에는 리소스 정보를 디코딩하지 않고, 차후 리소스 정보가 필요하다고 판단되는 경우에 리소스 정보의 디코딩을 수행할 수 있다.

이와 같이, 최적화된 상태의 리소스를 대상으로 인스톨 및 디코딩을 수행하므로, 본 실시예에 따른 디스플레이장치에서 디코딩 및 인스톨에 소요되는 시간은 앞선 제1실시예의 경우에 비해 대폭 절감된다.

만일, S220 단계에서 리소스를 최적화할 때에 리소스에서 삭제한 메타데이터를 그대로 리소스 정보로 추가하는 상황을 가정할 수 있다. 이 경우에는 메타데이터가 리소스에서 리소스 정보로 이동한 것이 되므로, 어플리케이션 팩키지의 전체 용량은 변화하지 않는다. 디스플레이장치(300)에서의 어플리케이션의 실행 시에는 리소스에 대해 디코딩하며 리소스 정보에 대해 디코딩하지 않으므로, 이러한 경우에도 디코딩 소요 시간을 절감할 수 있다.

이하, 클라이언트 컴퓨터에 의해 어플리케이션 팩키지를 생성하는 과정에 관해 설명한다.

도 13은 본 발명의 제2실시예에 따라서 클라이언트 컴퓨터가 어플리케이션 팩키지를 생성하는 과정을 나타내는 플로우차트이다.

도 13에 도시된 바와 같이, S310 단계에서 클라이언트 컴퓨터는 어플리케이션의 제작을 위해 마련된 리소스를 호출한다. 본 리소스는 개별적으로 속성을 가진 하나 이상의 청크, 즉 데이터 블록을 포함한다.

S320 단계에서 클라이언트 컴퓨터는 리소스의 타입을 판단한다. 리소스 타입의 판단은, 리소스의 파일 확장자 또는 리소스의 헤더에 기록된 메타정보에 기초하여 수행될 수 있다.

S330 단계에서 클라이언트 컴퓨터는 판단한 타입에 대응하여 삭제할 속성을 결정한다. 이와 같은 결정은 사전에 구축된 속성 DB에 따른다.

S340 단계에서 클라이언트 컴퓨터는 결정된 속성의 데이터 블록을 리소스에서 삭제함으로써 리소스를 최적화한다. 필요한 경우에, 클라이언트 컴퓨터는 삭제된 데이터 블록의 내용을 리소스 정보로 신설할 수 있다.

S350 단계에서 클라이언트 컴퓨터는 최적화할 리소스가 남아있는지 판단한다. 클라이언트 컴퓨터는 최적화할 리소스가 남아있는 경우에는 S310 단계로 이행하며, 최적화할 리소스가 남아있지 않은 경우에는 S360 단계로 이행한다.

S360 단계에서 클라이언트 컴퓨터는 최적화된 리소스를 실행 프로그램 및 인스톨 정보와 함께 압축한다. 앞선 S340 단계에서 리소스 정보가 도출되었다면, 클라이언트 컴퓨터는 리소스 정보를 추가하여 압축을 수행한다.

S370 단계에서 클라이언트 컴퓨터는 압축을 완료하여 어플리케이션 팩키지를 생성한다.

본 실시예에서는 리소스에서 어플리케이션의 구현에 불필요한 부가데이터를 삭제하는 예시에 관해 설명하였으나, 리소스의 최적화 방법은 이러한 한 가지 예시에 한정되지 않는다. 이하, 리소스를 최적화하는 방법에 있어서, 앞선 실시예와 상이한 방법에 관해 설명한다.

도 14는 본 발명의 제3실시예에 따른 리소스의 최적화 방법의 원리를 나타내는 예시도이다.

도 14에 도시된 바와 같이, 제3실시예에 따른 클라이언트 컴퓨터는 리소스를 최적화하는 방법으로서 해당 리소스의 포맷을 변환하는 방법을 사용할 수 있다. 사용되는 포맷은 용량 저감 측면에서 보다 효율적인 것이 선택될 수 있다.

예를 들어 PNG 이미지 포맷의 A.PNG라는 파일명을 가진 리소스(810)가 있다고 한다. PNG 이미지 포맷은 용량과 디코딩 속도 측면에서 상대적으로 효율이 좋은 WEBP 이미지 포맷으로 대체할 수 있다.

WEBP 이미지 규격은 2010년에 구글에 의해 공개된 이미지 포맷 규격으로서, JPEG을 대체하기 위해 제시되었다. WEBP는 웹 사이트의 트래픽 감소 및 로딩 속도 단축을 위해 제안되었으며, 주로 사진 이미지 압축 효과가 높은 것으로 알려졌다. WEBP는 JPEG 등과 같은 손실 압축 포맷으로서, 화질 저하를 최소화 하면서 파일 크기를 축소하였고, 2012년에 무손실 압축 포맷도 제시되어 PNG 등과 같은 무손실 압축 포맷도 대체할 수 있게 되었다. WEBP는 영상 압축에 대해서는 멀티미디어 포맷인 WebM의 기반인 VP8 영상 코덱 기술을 이용하고, 컨테이너 형식으로 RIFF를 채용하고 있다.

클라이언트 컴퓨터는 PNG 포맷의 리소스(810)를 WEBP 포맷의 리소스(820)로 변환함으로써 리소스 최적화를 수행한다. 이 과정에서, 최적화된 리소스(820)의 파일명은 A.PNG에서 A.WEBP로 바뀐다. PNG를 WEBP로 바꾸는 최적화 방법은 하나의 예시일 뿐이며 본 발명의 사상을 한정하는 것이 아닌 바, 최적화에 적용되는 포맷은 용량과 디코딩 속도 측면에서 상대적으로 효율이 좋다고 판단되는 것이라면 제한없이 적용될 수 있다.

그런데 포맷변환 과정에서 리소스의 파일명이 바뀌었으므로, 클라이언트 컴퓨터는 리소스(810)의 최적화에 의해 파일명이 A.PNG에서 A.WEBP로 바뀌었다는 내용의 이력(831)을 리소스 정보(830)에 기록한다. 만일 이러한 이력(831)이 기록되지 않는다면, 차후에 어플리케이션이 디스플레이장치에서 실행될 때에 에러가 발생한다.

클라이언트 컴퓨터는 이와 같이 리소스의 최적화를 수행하여 어플리케이션 팩키지를 생성한다. 어플리케이션의 배포에 관하여 리소스의 최적화 이외의 방법은 앞선 실시예를 응용할 수 있는 바, 자세한 설명을 생략한다.

도 15는 본 발명의 제3실시예에 따른 디스플레이장치에서 어플리케이션을 실행하는 원리를 나타내는 예시도이다.

도 15에 도시된 바와 같이, 디스플레이장치는 어플리케이션(840)을 플랫폼(850)에 인스톨 및 실행한다. 디스플레이장치의 플랫폼(850) 상에서 어플리케이션(840)이 실행되는 동안, 어플리케이션(840)은 플랫폼(850)에 A.PNG라는 파일명의 리소스를 요청할 수 있다.

플랫폼(850)은 어플리케이션(840)의 요청에 대응하는 리소스를 검색한다. 그러나, 앞선 도 14와 같은 최적화 과정을 통해 어플리케이션 팩키지 내에 A.PNG라는 파일명의 리소스는 존재하지 않는다. 이에, 플랫폼(850)은 리소스 정보(830)에서 A.PNG라는 파일명의 리소스와 관련된 이력(831)이 있는지 검색한다. 만일 리소스 정보(830)가 디코딩되지 않은 상태라면, 플랫폼(850)은 리소스 정보(830)가 디코딩되도록 하여 검색을 수행할 수 있다.

플랫폼(850)은 리소스 정보(830)에서 A.PNG에서 A.WEBP로 바뀌었다는 내용의 이력(831)을 검색하면, 해당 이력(831)의 내용에 따라서 A.WEBP라는 파일명의 리소스를 검색한다. 플랫폼(850)은 검색된 리소스를 어플리케이션(840)에 반환한다.

만일, 리소스 정보(830)에 이러한 이력(831)이 없다면 플랫폼(850)은 A.WEBP라는 파일명의 리소스를 어플리케이션(840)에 반환할 수 없으며, 이에 따라서 어플리케이션(840)은 실행에 에러가 발생할 것이다. 따라서, 본 실시예와 같이 리소스의 최적화로 인해 리소스의 명칭이 변경된다면, 이러한 변경 사항을 기록한 리소스 정보가 필수적이다.

본 실시예에서는 이미지 포맷의 리소스에 관해 설명하였으나, 음성, 동영상 등 다양한 포맷의 리소스에도 본 발명의 사상이 적용될 수 있다.

도 16은 본 발명의 제3실시예에 따른 속성 DB(860)의 예시도이다.

도 16에 도시된 바와 같이, 클라이언트 컴퓨터는 속성 DB(860)에 기초하여 최적화할 리소스의 포맷을 변환한다. 속성 DB(860)는 리소스의 타입, 리소스의 현재 포맷, 리소스를 변환할 포맷을 지정한다.

클라이언트 컴퓨터는 예를 들어 리소스가 PNG 이미지 포맷인 것으로 판단되면, 속성 DB(860)를 검색함으로써 PNG 포맷을 WEBP 포맷으로 변환한다는 정보를 취득한다. 취득한 정보에 따라서, 클라이언트 컴퓨터는 리소스를 WEBP 포맷으로 변환시킨다.

또다른 예를 들면, 클라이언트 컴퓨터는 리소스가 FLAC 음성 포맷인 것으로 판단되면, 속성 DB(860)를 검색함으로써 FLAC 포맷을 OGG 포맷으로 변환한다는 정보를 취득한다. 취득한 정보에 따라서, 클라이언트 컴퓨터는 리소스를 OGG 포맷으로 변환시킨다.

이하, 본 실시예에 따른 리소스의 최적화 과정에 관해 설명한다.

도 17은 본 발명의 제3실시예에 따른 클라이언트 컴퓨터가 리소스를 최적화하는 과정을 나타내는 플로우차트이다.

도 17에 도시된 바와 같이, S410 단계에서 클라이언트 컴퓨터는 어플리케이션의 제작을 위해 마련된 일 리소스를 호출한다.

S420 단계에서 클라이언트 컴퓨터는 호출한 리소스의 포맷을 판단한다.

S430 단계에서 클라이언트 컴퓨터는 판단한 포맷에 대응하게 지정된 변환 포맷을 특정한다. 변환 포맷의 특정은 앞선 도 16과 관련하여 설명한 바와 같다.

S440 단계에서 클라이언트 컴퓨터는 리소스를 특정된 변환 포맷으로 변환함으로써 리소스를 최적화한다.

S450 단계에서 클라이언트 컴퓨터는 리소스의 포맷변환 이력을 리소스 정보에 기록한다.

S460 단계에서 클라이언트 컴퓨터는 최적화할 리소스가 남았는지 판단한다. 클라이언트 컴퓨터는 최적화할 리소스가 남았다고 판단하면 S410 단계로 이행하고, 최적화할 리소스가 남지 않았다고 판단하면 S470 단계로 이행한다.

S470 단계에서 클라이언트 컴퓨터는 실행 프로그램, 최적화한 리소스, 인스톨 정보 및 리소스 정보를 함께 압축시킨다.

S480 단계에서 클라이언트 컴퓨터는 압축을 완료하여 어플리케이션 팩키지를 생성한다.

도 18은 본 발명의 제3실시예에 따른 디스플레이장치에서 플랫폼이 어플리케이션으로부터 요청받은 리소스를 검색하는 과정을 나타내는 플로우차트이다.

도 18에 도시된 바와 같이, S510 단계에서 디스플레이장치의 플랫폼은 어플리케이션으로부터 일 리소스를 요청받는다.

S520 단계에서 플랫폼은 디스플레이장치에 인스톨된 리소스 중에서, 요청받은 리소스가 검색되는지 판단한다.

요청받은 리소스가 검색되면, S530 단계에서 플랫폼은 검색된 리소스를 어플리케이션에 반환한다.

반면, 요청받은 리소스가 검색되지 않으면, S540 단계에서 플랫폼은 해당 리소스에 링크되는 타 리소스, 즉 해당 리소스 대신 마련된 타 리소스가 무엇인지 리소스 정보에서 검색하여 특정한다.

S550 단계에서 플랫폼은 리소스 정보에 기초하여 특정된 타 리소스를 검색한다.

S560 단계에서 플랫폼은 검색된 타 리소스를 어플리케이션에 반환한다.

이하, 리소스를 최적화하는 방법에 있어서, 앞선 실시예와 상이한 방법에 관해 설명한다.

도 19는 본 발명의 제4실시예에 따른 리소스의 최적화 방법의 원리를 나타내는 예시도이다.

도 19에 도시된 바와 같이, 제4실시예에 따른 클라이언트 컴퓨터는 리소스 최적화 시에, 전체 리소스(910) 중에서 내용상 중복되는 리소스를 검색한다. 내용상 중복되는 리소스를 검색하는 방법은 다양한 실시예가 적용될 수 있는 사항이므로, 자세한 설명을 생략한다.

예를 들어 A.PNG라는 리소스와 B.PNG라는 리소스는 명칭만 다를 뿐 실질적으로 동일한 내용을 포함한다고 한다. 이에, 클라이언트 컴퓨터는 중복되는 두 리소스 중 어느 하나, 예를 들면 B.PNG라는 리소스를 삭제하고 A.PNG라는 리소스를 유지한다. 이로써, 클라이언트 컴퓨터는 B.PNG라는 중복되는 리소스가 제거된 최적화된 리소스(920)를 생성한다.

이 과정에서, 클라이언트 컴퓨터는 B.PNG를 삭제하는 대신, B.PNG가 A.PNG로 대체될 수 있다는 링크 정보(931)를 리소스 정보(930)에 기록한다. 만일, 이러한 링크 정보(931)이 리소스 정보(930)에 기록되지 않는다면, 차후 어플리케이션의 실행 시에 어플리케이션이 플랫폼에 B.PNG를 요청하게 되면 에러가 발생하게 된다.

본 실시예에서는 두 개의 리소스가 중복되는 경우에 어느 하나를 제거하는 예시에 관해 표현하였다. 만일 셋 이상의 리소스가 중복되는 경우라면, 클라이언트 컴퓨터는 이들 중에서 하나의 리소스만 남기고 나머지는 삭제한다.

도 20은 본 발명의 제4실시예에 따른 디스플레이장치에서 어플리케이션을 실행하는 원리를 나타내는 예시도이다.

도 20에 도시된 바와 같이, 디스플레이장치는 어플리케이션(940)을 플랫폼(950)에 인스톨 및 실행한다. 디스플레이장치의 플랫폼(950) 상에서 어플리케이션(940)이 실행되는 동안, 어플리케이션(940)은 플랫폼(950)에 B.PNG라는 파일명의 리소스를 요청할 수 있다.

플랫폼(950)은 어플리케이션(940)의 요청에 대응하는 리소스를 검색한다. 그러나, 앞선 도 19와 같은 최적화 과정을 통해 어플리케이션 팩키지 내에 B.PNG라는 파일명의 리소스는 존재하지 않는다. 이에, 플랫폼(950)은 리소스 정보(930)에서 B.PNG라는 파일명의 리소스에 링크되는 리소스의 정보(931)가 있는지 검색한다. 만일 리소스 정보(930)가 디코딩되지 않은 상태라면, 플랫폼(950)은 리소스 정보(930)가 디코딩되도록 하여 검색을 수행할 수 있다.

플랫폼(950)은 리소스 정보(930)에서 B.PNG에 링크되는 리소스가 A.PNG라는 내용의 정보(931)를 검색하면, 해당 정보(931)의 내용에 따라서 B.PNG 대신 A.PNG라는 파일명의 리소스를 검색한다. 플랫폼(950)은 검색된 리소스를 어플리케이션(940)에 반환한다.

만일, 리소스 정보(930)에 이러한 정보(931)가 없다면 플랫폼(950)은 A.PNG라는 파일명의 리소스를 어플리케이션(940)에 반환할 수 없으며, 이에 따라서 어플리케이션(940)은 실행에 에러가 발생할 것이다. 따라서, 본 실시예와 같이 리소스의 최적화로 인해 중복 리소스가 삭제된다면, 삭제된 리소스를 대체하기 위한 리소스를 특정한 리소스 정보가 필수적이다.

본 실시예에서는 이미지 포맷의 리소스에 관해 설명하였으나, 음성, 동영상 등 다양한 포맷의 리소스에도 본 발명의 사상이 적용될 수 있다.

이하, 본 실시예에 따른 리소스의 최적화 과정에 관해 설명한다.

도 21은 본 발명의 제4실시예에 따른 클라이언트 컴퓨터가 리소스를 최적화하는 과정을 나타내는 플로우차트이다.

도 21에 도시된 바와 같이, S610 단계에서 클라이언트 컴퓨터는 어플리케이션의 제작을 위해 마련된 모든 리소스를 호출한다.

S620 단계에서 클라이언트 컴퓨터는 모든 리소스 내에서 내용이 중복되는 리소스를 검색한다.

S630 단계에서 클라이언트 컴퓨터는 내용이 중복되는 리소스 중에서 어느 하나를 유지하고 나머지를 삭제함으로써, 리소스의 최적화를 수행한다.

S640 단계에서 클라이언트 컴퓨터는 삭제된 리소스를 유지된 리소스로 링크시키는 정보를 리소스 정보에 기록한다.

S650 단계에서 클라이언트 컴퓨터는 실행 프로그램, 최적화한 리소스, 인스톨 정보 및 리소스 정보를 함께 압축시킨다.

S660 단계에서 클라이언트 컴퓨터는 압축을 완료하여 어플리케이션 팩키지를 생성한다.

도 22는 본 발명의 제4실시예에 따른 디스플레이장치에서 플랫폼이 어플리케이션으로부터 요청받은 리소스를 검색하는 과정을 나타내는 플로우차트이다.

도 22에 도시된 바와 같이, S710 단계에서 디스플레이장치의 플랫폼은 어플리케이션으로부터 리소스를 요청받는다.

S720 단계에서 플랫폼은 디스플레이장치에 인스톨된 리소스 중에서, 요청받은 리소스가 검색되는지 판단한다.

요청받은 리소스가 검색되면, S730 단계에서 플랫폼은 검색된 리소스를 어플리케이션에 반환한다.

반면, 요청받은 리소스가 검색되지 않으면, S740 단계에서 플랫폼은 해당 리소스에 링크되는 리소스가 무엇인지 리소스 정보에서 검색하여 특정한다.

S750 단계에서 플랫폼은 리소스 정보에 기초하여 특정된 리소스를 검색한다.

S760 단계에서 플랫폼은 검색된 타 리소스를 어플리케이션에 반환한다.

도 23은 어플리케이션 팩키지의 리소스의 최적화의 효과의 예시를 나타내는 그래프이다.

도 23에 도시된 바와 같이, 예를 들어 180개의 PNG 이미지의 리소스 파일을 대상으로 리소스 최적화 효과를 실험한 바에 따르면, 리소스 파일의 크기의 저감에 비례하여 디코딩 소요시간이 줄어들었다. 그래프에서 PNG는 PNG 이미지 리소스 파일에서 최적화를 수행하지 않은 경우, PNG-Diet는 리소스 파일에서 불필요한 메타데이터를 삭제한 경우, WEBP는 리소스 파일을 PNG 포맷에서 WEBP 포맷으로 변환한 경우를 각각 나타낸다. 본 그래프에서는 각 케이스 별 상대비교를 위한 것이므로 실험 환경의 구체적인 조건 및 세로축의 단위는 명시하지 않았다.

최적화를 수행하지 않은 경우의 리소스의 크기가 1,096kB이고 디코딩 소요시간이 312ms일 때에, 메타데이터를 삭제한 경우에는 리소스의 크기가 792kB가 되고 디코딩 소요시간이 230ms로 줄어든다. 그리고, WEBP 포맷으로 변환한 경우에는 리소스의 크기가 568kB로 더욱 줄어들고 디코딩 소요시간이 83ms로 대폭 줄어든다. 즉, WEBP 포맷으로 변환한 경우가 메타데이터를 삭제한 경우에 비해 크기는 약 30%, 디코딩 속도는 약 60%의 개선 효과가 발생함을 알 수 있다.

다만, WEBP 포맷으로 변환한 경우의 실험 과정에서 전체 180개의 리소스 중에서 크기 및 디코딩 속도의 개선이 나오지 않고 오히려 악화되는 리소스가 5개 정도 발견되었다. 이는, 리소스의 컨텐츠에 따라서는 WEBP 포맷의 알고리즘이 오히려 PNG 포맷의 알고리즘에 비해 해당 컨텐츠에 적합하지 않는 경우가 있다는 것을 의미한다. 즉, 최적화의 의미가, 보다 효율적이라고 알려진 포맷으로의 일괄 변환을 꼭 의미하는 것은 아니라는 것을 나타낸다.

이상 실시예들에서는, 클라이언트 컴퓨터가 어플리케이션 팩키지를 생성하여 서버에 등록하고, 서버가 디스플레이장치에게 어플리케이션 팩키지를 배포하는 경우에 관해 설명하였다. 즉, 앞선 실시예들에서는 리소스의 최적화 및 어플리케이션의 팩키징 과정이 모두 개발자의 클라이언트 컴퓨터에서 수행되었다.

그러나, 어플리케이션의 팩키징은 서버에서 수행될 수도 있으며, 리소스의 최적화는 서버 또는 디스플레이장치에서 수행될 수도 있는 바, 앞선 실시예들의 내용이 본 발명의 사상을 한정하는 것은 아니다. 이하, 이와 같은 실시예들에 관해 설명한다.

도 24는 본 발명의 제5실시예에 따른 어플리케이션 팩키지(1150)가 생성되는 과정을 나타내는 예시도이다.

도 24에 도시된 바와 같이, 제5실시예에 따른 클라이언트 컴퓨터(200)는 어플리케이션의 제작을 위해 실행 프로그램(1110) 및 하나 이상의 리소스(1120)를 제작한다. 여기서, 클라이언트 컴퓨터(200)는 실행 프로그램(1110) 및 리소스(1120)를 그대로 서버(100)에 전송한다.

서버(100)는 클라이언트 컴퓨터(200)로부터 실행 프로그램(1110) 및 리소스(1120)를 수신하면, 리소스(1120)에 대해 리소스 최적화를 수행한다. 리소스 최적화의 방법에 관해서는 앞선 실시예들을 적용할 수 있는 바, 자세한 설명을 생략한다. 리소스 최적화가 완료되면, 최적화된 리소스(1120) 및 리소스 정보(1130)가 생성된다.

서버(100)는 실행 프로그램(1110), 최적화된 리소스(1120), 인스톨 정보(1140) 및 리소스 정보(1130)를 압축하여 어플리케이션 팩키지(1150)를 생성한다.

이하, 본 실시예에 따라서 어플리케이션이 제작 및 배포되는 과정에 관해 설명한다.

도 25는 본 발명의 제5실시예에 따른 시스템(1) 내에서 어플리케이션이 제작 및 배포되는 과정을 나타내는 플로우차트이다. 본 실시예에서의 서버(100), 클라이언트 컴퓨터(200), 디스플레이장치(300)의 기본적인 구조는 앞선 실시예와 동일하다.

도 25에 도시된 바와 같이, S810 단계에서 클라이언트 컴퓨터(200)는 어플리케이션의 구동을 위해 필수적인 실행 프로그램과, 실행 프로그램에 의해 선택적으로 호출 및 사용되는 리소스를 제작한다.

S820 단계에서 클라이언트 컴퓨터(200)는 서버(100)에 실행 프로그램 및 리소스를 전송한다.

S830 단계에서, 서버(100)는 클라이언트 컴퓨터(200)로부터 수신된 리소스의 최적화를 수행한다. 리소스의 최적화 과정은 앞서 설명한 바와 같으며, 그 결과 리소스가 최적화되고 리소스 정보가 생성된다. 리소스의 최적화 방식에 따라서는 리소스 정보는 생성되지 않을 수도 있다.

S840 단계에서, 서버(100)는 클라이언트 컴퓨터(200)로부터 수신된 실행 프로그램과, 최적화된 리소스, 인스톨 정보를 함께 팩키징하여 어플리케이션 팩키지를 생성한다. 만일 앞선 S830 단계에서 리소스 정보가 생성되었다면, 클라이언트 컴퓨터(200)는 어플리케이션 팩키지에 리소스 정보도 포함시킨다.

S850 단계에서 서버(100)는 생성된 어플리케이션 팩키지를 등록 및 저장한다.

S860 단계에서 서버(100)는 디스플레이장치(300)로부터 어플리케이션 팩키지의 요청을 수신한다. 이에, S870 단계에서 서버(100)는 해당 요청에 대응하는 어플리케이션 팩키지를 디스플레이장치(300)에 전송한다.

S880 단계에서 디스플레이장치(300)는 서버(100)로부터 수신되는 어플리케이션 팩키지의 압축을 풀어서 실행 프로그램, 리소스, 인스톨 정보를 복원하고, 어플리케이션을 인스톨 정보에 따라서 운영체제 상에 인스톨 및 실행한다.

이와 같이, 본 실시예에 따르면 서버(100)가 리소스의 최적화 동작 및 어플리케이션의 팩키징 동작을 수행할 수 있다.

도 26은 본 발명의 제6실시예에 따른 어플리케이션 팩키지(1240)가 생성되고 인스톨되는 과정을 나타내는 예시도이다.

도 26에 도시된 바와 같이, 제6실시예에 따른 클라이언트 컴퓨터(200)는 어플리케이션의 제작을 위해 실행 프로그램(1210) 및 하나 이상의 리소스(1220)를 제작한다. 여기서, 클라이언트 컴퓨터(200)는 실행 프로그램(1210) 및 리소스(1220)를 그대로 서버(100)에 전송한다.

서버(100)는 클라이언트 컴퓨터(200)로부터 실행 프로그램(1210) 및 리소스(1220)를 수신하면, 이에 인스톨 정보(1230)를 첨부하여 압축함으로써 어플리케이션 팩키지(1240)를 생성한다. 여기서, 인스톨 정보(1230)는 서버(100)가 생성할 수 있고, 클라이언트 컴퓨터(200)가 생성하여 서버(100)에 전송될 수도 있다. 서버(100)는 어플리케이션 팩키지(1240)를 디스플레이장치(300)에 전송한다.

디스플레이장치(300)는 서버(100)로부터 수신된 어플리케이션 팩키지(1240)의 압축을 해제하여, 실행 프로그램(1210), 리소스(1220), 인스톨 정보(1230)를 추출한다. 여기서, 디스플레이장치(300)는 리소스(1220)에 대해 리소스 최적화를 수행함으로써, 최적화된 리소스(1250) 및 리소스 정보(1260)를 도출한다. 리소스 최적화에 관한 방법은 앞선 실시예를 적용할 수 있으므로, 자세한 설명을 생략한다.

디스플레이장치(300)는 실행 프로그램(1210), 최적화된 리소스(1250), 인스톨 정보(1230) 및 리소스 정보(1260)를 운영체제 상에 인스톨한다.

이와 같이, 본 실시예에서는 서버(100)에서 어플리케이션의 팩키징 동작이 수행되며, 디스플레이장치(300)에서 리소스의 최적화 동작이 수행된다. 어플리케이션 팩키지(1240) 내의 리소스(1220)는 최적화되어 있지 않지만, 디스플레이장치(300)에서 인스톨 시에 리소스 최적화가 수행되므로, 어플리케이션의 실행 시에 디코딩 시간이 줄어드는 효과가 있다.

도 27은 본 발명의 제6실시예에 따른 시스템(1) 내에서 어플리케이션이 제작 및 배포되는 과정을 나타내는 플로우차트이다.

도 27에 도시된 바와 같이, S910 단계에서 클라이언트 컴퓨터(200)는 어플리케이션의 실행 프로그램 및 리소스를 제작한다.

S920 단계에서 클라이언트 컴퓨터(200)는 서버(100)에 실행 프로그램 및 리소스를 전송한다.

S930 단계에서, 서버(100)는 클라이언트 컴퓨터(200)로부터 수신된 실행 프로그램, 리소스, 인스톨 정보를 함께 팩키징하여 어플리케이션 팩키지를 생성한다.

S940 단계에서 서버(100)는 생성된 어플리케이션 팩키지를 등록 및 저장한다.

S950 단계에서 서버(100)는 디스플레이장치(300)로부터 어플리케이션 팩키지의 요청을 수신한다. 이에, S960 단계에서 서버(100)는 해당 요청에 대응하는 어플리케이션 팩키지를 디스플레이장치(300)에 전송한다.

S970 단계에서 디스플레이장치(300)는 서버(100)로부터 수신되는 어플리케이션 팩키지의 압축을 해제하여 실행 프로그램, 리소스, 인스톨 정보를 복원한다.

S980 단계에서, 디스플레이장치(300)는 리소스의 최적화를 수행한다. 리소스의 최적화 과정은 앞서 설명한 바와 같으며, 그 결과 리소스가 최적화되고 리소스 정보가 생성된다. 리소스의 최적화 방식에 따라서는 리소스 정보는 생성되지 않을 수도 있다.

S990 단계에서 디스플레이장치(300)는 실행 프로그램 및 최적화된 리소스를 인스톨 정보에 따라서 운영체제 상에 인스톨하고, 어플리케이션을 실행한다.

도 28은 본 발명의 제7실시예에 따른 시스템(1) 내에서 어플리케이션이 제작 및 배포되는 과정을 나타내는 플로우차트이다.

도 28에 도시된 바와 같이, S1110 단계에서 클라이언트 컴퓨터(200)는 어플리케이션의 실행 프로그램 및 리소스를 제작한다.

S1120 단계에서, 클라이언트 컴퓨터(200)는 실행 프로그램, 리소스, 인스톨 정보를 함께 팩키징하여 어플리케이션 팩키지를 생성한다.

S1130 단계에서 클라이언트 컴퓨터(200)는 서버(100)에 어플리케이션 팩키지를 전송한다.

S1140 단계에서 서버(100)는 클라이언트 컴퓨터(200)로부터 수신된 어플리케이션 팩키지를 등록 및 저장한다.

S1150 단계에서 서버(100)는 디스플레이장치(300)로부터 어플리케이션 팩키지의 요청을 수신한다. 이에, S1160 단계에서 서버(100)는 해당 요청에 대응하는 어플리케이션 팩키지를 디스플레이장치(300)에 전송한다.

S1170 단계에서 디스플레이장치(300)는 서버(100)로부터 수신되는 어플리케이션 팩키지의 압축을 해제하여 실행 프로그램, 리소스, 인스톨 정보를 복원한다.

S1180 단계에서, 디스플레이장치(300)는 리소스의 최적화를 수행한다. 리소스의 최적화 과정은 앞서 설명한 바와 같으며, 그 결과 리소스가 최적화되고 리소스 정보가 생성된다. 리소스의 최적화 방식에 따라서는 리소스 정보는 생성되지 않을 수도 있다.

S1190 단계에서 디스플레이장치(300)는 실행 프로그램 및 최적화된 리소스를 인스톨 정보에 따라서 운영체제 상에 인스톨하고, 어플리케이션을 실행한다.

이와 같이, 본 실시예에서는 클라이언트 컴퓨터(200)에서 팩키징 과정이 수행되고, 디스플레이장치(300)에서 어플리케이션을 인스톨할 때에 리소스 최적화 과정이 수행된다.

본 발명의 예시적 실시예에 따른 방법들은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 이러한 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 예를 들어, 컴퓨터 판독 가능 매체는 삭제 가능 또는 재기록 가능 여부와 상관없이, ROM 등의 저장 장치와 같은 휘발성 또는 비휘발성 저장 장치, 또는 예를 들어, RAM, 메모리 칩, 장치 또는 집적 회로와 같은 메모리, 또는 예를 들어 CD, DVD, 자기 디스크 또는 자기 테이프 등과 같은 광학 또는 자기적으로 기록 가능함과 동시에 기계(예를 들어, 컴퓨터)로 읽을 수 있는 저장 매체에 저장될 수 있다. 이동 단말 내에 포함될 수 있는 메모리는 본 발명의 실시 예들을 구현하는 지시들을 포함하는 프로그램 또는 프로그램들을 저장하기에 적합한 기계로 읽을 수 있는 저장 매체의 한 예임을 알 수 있을 것이다. 본 저장 매체에 기록되는 프로그램 명령은 본 발명을 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어의 기술 분야에서 숙련된 기술자에게 공지되어 사용 가능한 것일 수도 있다.

상기한 실시예는 예시적인 것에 불과한 것으로, 당해 기술 분야의 통상의 지식을 가진 자라면 다양한 변형 및 균등한 타 실시예가 가능하다. 따라서, 본 발명의 진정한 기술적 보호범위는 하기의 특허청구범위에 기재된 발명의 기술적 사상에 의해 정해져야 할 것이다.

1 : 시스템
100 : 서버
200 : 클라이언트 컴퓨터
300 : 디스플레이장치
710 : 실행 프로그램
720 : 리소스
730 : 속성 DB
740 : 리소스 정보
750 : 인스톨 정보
760 : 어플리케이션 팩키지

Claims (18)

1. 정보처리장치에 있어서,
   어플리케이션 실행장치에서 설치될 어플리케이션의 주 프로그램과, 상기 주 프로그램의 실행에 관한 복수의 속성의 데이터를 포함하는 제1리소스데이터가 저장되는 저장부와;
   상기 제1리소스데이터의 복수의 속성 중에서 상기 주 프로그램의 실행 시 이용 정도가 상대적으로 낮은 적어도 하나의 속성의 데이터를 배제하여 상기 제1리소스데이터보다 작은 데이터 크기를 가지는 제2리소스데이터를 생성하고, 상기 주 프로그램 및 상기 생성된 제2리소스 데이터를 포함하는 상기 어플리케이션의 설치용 팩키지 프로그램을 생성하는 적어도 하나의 프로세서를 포함하는 것을 특징으로 하는 정보처리장치.
2. 제1항에 있어서,
   상기 저장부는, 복수의 리소스데이터의 타입에 각기 대응하는 상기 리소스데이터 내 상기 데이터의 속성 별 삭제 여부를 지정한 최적화 정보를 저장하며,
   상기 적어도 하나의 프로세서는, 상기 제1리소스데이터의 타입을 판단하고, 상기 판단한 타입에 대응하는 삭제 대상 속성을 상기 최적화 정보에 따라서 판단하는 것을 특징으로 하는 정보처리장치.
3. 제2항에 있어서,
   상기 리소스데이터는 이미지 파일, 음성 파일, 멀티미디어 파일 중 적어도 어느 하나로 마련되며, 상기 최적화 정보는 상기 리소스데이터 내 메타데이터 속성의 상기 데이터를 삭제하도록 지정한 것을 특징으로 하는 정보처리장치.
4. 제2항에 있어서,
   상기 최적화 정보는 상기 리소스데이터에서 삭제되는 메타데이터 중 일부의 내용을 리소스 이력 정보로 저장하도록 지정하며,
   상기 적어도 하나의 프로세서는, 상기 리소스 이력 정보를 상기 팩키지 프로그램에 포함시키는 것을 특징으로 하는 정보처리장치.
5. 제4항에 있어서,
   상기 최적화 정보는 상기 리소스데이터의 제1포맷을 상기 제1포맷 대비 상대적으로 데이터 크기의 효율이 높은 기 설정된 제2포맷으로 변환하도록 지정하며,
   상기 적어도 하나의 프로세서는, 제3리소스데이터의 포맷을 판단하고, 상기 제3리소스데이터를 상기 최적화 정보에 지정된 상기 제2포맷의 제4리소스데이터로 변환하며, 기 설정된 플랫폼 상에서 상기 어플리케이션이 실행될 때에 상기 제3리소스데이터를 요청하는 동작에 응답하여 상기 제4리소스데이터가 반환되도록 상기 변환 이력을 상기 리소스 이력 정보에 기록하는 것을 특징으로 하는 정보처리장치.
6. 제4항에 있어서,
   상기 적어도 하나의 프로세서는 상기 어플리케이션의 모든 상기 리소스데이터 중에서 제5리소스데이터와 중복되는 하나 이상의 제6리소스데이터를 삭제하며, 기 설정된 플랫폼 상에서 상기 어플리케이션이 실행될 때에 상기 제5리소스데이터를 요청하는 동작에 응답하여 상기 제6리소스데이터가 반환되도록 상기 삭제 이력을 상기 리소스 이력 정보에 기록하는 것을 특징으로 하는 정보처리장치.
7. 제1항에 있어서,
   상기 어플리케이션 실행장치와 통신하는 통신부를 더 포함하며,
   상기 적어도 하나의 프로세서는, 상기 저장부에 상기 팩키지 프로그램을 저장하고, 상기 어플리케이션 실행장치의 요청에 응답하여 상기 팩키지 프로그램을 상기 어플리케이션 실행장치에 설치되도록 상기 통신부를 통해 전송하는 것을 특징으로 하는 정보처리장치.
8. 제1항에 있어서,
   상기 어플리케이션은 웹 브라우저 프로그램 상에서 실행되는 웹 어플리케이션인 것을 특징으로 하는 정보처리장치.
9. 영상처리장치에 있어서,
   주 프로그램과 상기 주 프로그램의 실행에 관한 복수의 속성의 데이터를 포함하는 제1리소스데이터를 포함하는 어플리케이션의 설치용 팩키지 프로그램을 수신하는 수신부와;
   상기 팩키지 프로그램을 해제하여 상기 어플리케이션을 실행 가능하게 설치하는 적어도 하나의 프로세서를 포함하며,
   상기 적어도 하나의 프로세서는,
   상기 제1리소스데이터의 복수의 속성 중에서 상기 주 프로그램의 실행 시 이용 정도가 상대적으로 낮은 적어도 하나의 속성의 데이터를 배제하여 상기 제1리소스데이터보다 작은 데이터 크기를 가지는 제2리소스데이터를 생성하고, 상기 주 프로그램 및 상기 생성된 제2리소스 데이터를 포함하는 상기 어플리케이션을 설치하는 것을 특징으로 하는 영상처리장치.
10. 정보처리장치의 제어방법에 있어서,
    어플리케이션 실행장치에서 설치될 어플리케이션의 주 프로그램과, 상기 주 프로그램의 실행에 관한 복수의 속성의 데이터를 포함하는 제1리소스데이터를 취득하는 단계와;
    상기 제1리소스데이터의 복수의 속성 중에서 상기 주 프로그램의 실행 시 이용 정도가 상대적으로 낮은 적어도 하나의 속성의 데이터를 배제하여 상기 제1리소스데이터보다 작은 데이터 크기를 가지는 제2리소스데이터를 생성하는 단계와;
    상기 주 프로그램 및 상기 생성된 제2리소스 데이터를 포함하는 상기 어플리케이션의 설치용 팩키지 프로그램을 생성하는 단계를 포함하는 것을 특징으로 하는 정보처리장치의 제어방법.
11. 제10항에 있어서,
    상기 제2리소스데이터를 생성하는 단계는,
    상기 제1리소스데이터의 타입을 판단하고, 상기 판단한 타입에 대응하는 삭제 대상 속성을 기 설정된 최적화 정보에 따라서 판단하는 단계를 포함하며,
    상기 최적화 정보는, 복수의 리소스데이터의 타입에 각기 대응하는 상기 리소스데이터 내 상기 데이터의 속성 별 삭제 여부를 지정한 것을 특징으로 하는 정보처리장치의 제어방법.
12. 제11항에 있어서,
    상기 리소스데이터는 이미지 파일, 음성 파일, 멀티미디어 파일 중 적어도 어느 하나로 마련되며, 상기 최적화 정보는 상기 리소스데이터 내 메타데이터 속성의 상기 데이터를 삭제하도록 지정한 것을 특징으로 하는 정보처리장치의 제어방법.
13. 제11항에 있어서,
    상기 최적화 정보는 상기 리소스데이터에서 삭제되는 메타데이터 중 일부의 내용을 리소스 이력 정보로 저장하도록 지정하며,
    상기 어플리케이션의 설치용 팩키지 프로그램을 생성하는 단계는, 상기 리소스 이력 정보를 상기 팩키지 프로그램에 포함시키는 단계를 포함하는 것을 특징으로 하는 정보처리장치의 제어방법.
14. 제13항에 있어서,
    상기 최적화 정보는 상기 리소스데이터의 제1포맷을 상기 제1포맷 대비 상대적으로 데이터 크기의 효율이 높은 기 설정된 제2포맷으로 변환하도록 지정하며,
    상기 제2리소스데이터를 생성하는 단계는,
    제3리소스데이터의 포맷을 판단하고, 상기 제3리소스데이터를 상기 최적화 정보에 지정된 상기 제2포맷의 제4리소스데이터로 변환하는 단계와;
    기 설정된 플랫폼 상에서 상기 어플리케이션이 실행될 때에 상기 제3리소스데이터를 요청하는 동작에 응답하여 상기 제4리소스데이터가 반환되도록 상기 변환 이력을 상기 리소스 이력 정보에 기록하는 단계를 포함하는 것을 특징으로 하는 정보처리장치의 제어방법.
15. 제13항에 있어서,
    상기 제2리소스데이터를 생성하는 단계는,
    상기 어플리케이션의 모든 상기 리소스데이터 중에서 제5리소스데이터와 중복되는 하나 이상의 제6리소스데이터를 삭제하는 단계와;
    기 설정된 플랫폼 상에서 상기 어플리케이션이 실행될 때에 상기 제5리소스데이터를 요청하는 동작에 응답하여 상기 제6리소스데이터가 반환되도록 상기 삭제 이력을 상기 리소스 이력 정보에 기록하는 단계를 포함하는 것을 특징으로 하는 정보처리장치의 제어방법.
16. 제10항에 있어서,
    상기 팩키지 프로그램을 저장하고, 상기 어플리케이션 실행장치의 요청에 응답하여 상기 팩키지 프로그램을 상기 어플리케이션 실행장치에 설치되도록 전송하는 단계를 더 포함하는 것을 특징으로 하는 정보처리장치의 제어방법.
17. 제10항에 있어서,
    상기 어플리케이션은 웹 브라우저 프로그램 상에서 실행되는 웹 어플리케이션인 것을 특징으로 하는 정보처리장치의 제어방법.
18. 영상처리장치의 제어방법에 있어서,
    주 프로그램과 상기 주 프로그램의 실행에 관한 복수의 속성의 데이터를 포함하는 제1리소스데이터를 포함하는 어플리케이션의 설치용 팩키지 프로그램을 수신하는 단계와;
    상기 팩키지 프로그램을 해제하여 상기 어플리케이션을 실행 가능하게 설치하는 단계를 포함하며,
    상기 어플리케이션을 설치하는 단계는,
    상기 제1리소스데이터의 복수의 속성 중에서 상기 주 프로그램의 실행 시 이용 정도가 상대적으로 낮은 적어도 하나의 속성의 데이터를 배제하여 상기 제1리소스데이터보다 작은 데이터 크기를 가지는 제2리소스데이터를 생성하는 단계와;
    상기 주 프로그램 및 상기 생성된 제2리소스 데이터를 포함하는 상기 어플리케이션을 설치하는 단계를 포함하는 것을 특징으로 하는 영상처리장치의 제어방법.

Images