KR100649946B1 - Method for constructing library based on open cable application platform and recoding medium storing the smae - Google Patents
Method for constructing library based on open cable application platform and recoding medium storing the smae Download PDFInfo
- Publication number
- KR100649946B1 KR100649946B1 KR1020050045739A KR20050045739A KR100649946B1 KR 100649946 B1 KR100649946 B1 KR 100649946B1 KR 1020050045739 A KR1020050045739 A KR 1020050045739A KR 20050045739 A KR20050045739 A KR 20050045739A KR 100649946 B1 KR100649946 B1 KR 100649946B1
- Authority
- KR
- South Korea
- Prior art keywords
- middleware
- package
- class
- classes
- ocap
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/38—Creation or generation of source code for implementing user interfaces
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Human Computer Interaction (AREA)
- Stored Programmes (AREA)
Abstract
Description
도 1은 본 발명에 따른 OCAP 기반의 라이브러리가 위치하는 OCAP 프로토콜 스택의 구조를 도시한 도면,1 is a diagram illustrating a structure of an OCAP protocol stack in which an OCAP-based library is located according to the present invention;
도 2는 본 발명에 따른 OCAP 기반의 라이브러리 구축 방법에 대한 바람직한 실시예의 수행과정을 도시한 흐름도,2 is a flowchart illustrating a process of performing a preferred embodiment of the OCAP-based library construction method according to the present invention;
도 3은 본 발명에 다라 구현된 클래스와 자바 플랫폼과의 관계를 도시한 도면, 3 is a diagram illustrating a relationship between a class implemented according to the present invention and a Java platform;
도 4는 공통으로 사용하는 패키지를 참조하여 구현된 클래스의 일예를 도시한 도면, 4 is a diagram illustrating an example of a class implemented by referring to a commonly used package;
도 5는 본 발명에 따라 구현된 SI 변환모듈의 일예를 도시한 도면, 그리고, 5 is a diagram illustrating an example of an SI conversion module implemented according to the present invention;
도 6은 본 발명에 따라 구현된 바이패스모듈의 일예를 도시한 도면이다.6 is a diagram illustrating an example of a bypass module implemented according to the present invention.
본 발명은 OCAP 기반의 라이브러리 구축방법 및 그 기록매체에 관한 것으로, 보다 상세하게는, 쌍방향 디지털 데이터 방송용 컨텐츠를 제작함에 있어 사용되는 OCAP 기반의 라이브러리를 구축하는 방법 및 라이브러리가 기록된 기록매체에 관한 것이다.The present invention relates to a method for constructing an OCAP-based library and a recording medium thereof, and more particularly, to a method for constructing an OCAP-based library used for producing interactive digital data broadcasting content and a recording medium on which a library is recorded. will be.
현재 쌍방향 디지털 데이터방송을 위한 개발 표준은 유럽 지역을 중심으로 OpenTV, Canal+, Liberate 등과 같은 특정 업체의 특정 제품이 산업 표준의 형태로만 먼저 자리를 잡고 있는 상황이다. 그러나 이들 업체를 중심으로 최근 불필요한 중복 투자의 방지를 위해 다방면에 걸쳐 표준화된 개발 스펙을 지속적으로 연구 중인 상황이며, 그 결과 위성 디지털 방송에서는 DVB-MHP 개발 표준안이, 케이블 디지털 방송에서는 OpenCable-OCAP 개발 표준안이, 지상파 케이블 방송에서는 ATSC-DASE 개발 표준안이 속속 정의되고, 이것들이 협회나 학회를 통해 계속 업데이트 되면서 발표되는 추세이다. 나아가 OCAP과 DASE 방식의 경우는 상호 호환성이 지나치게 떨어진다는 지적에 의거, 이를 상호 통합하는 ACAP(Advanced OCAP)방식의 개발 표준안도 적극 논의되고 있다. Currently, the development standard for interactive digital data broadcasting is a situation in which specific products of certain companies such as OpenTV, Canal +, and Liberate are first placed in the form of industry standards, mainly in Europe. However, these companies are continuously researching standardized development specifications in various fields in order to prevent unnecessary overlapping investments. As a result, DVB-MHP development standard is proposed for satellite digital broadcasting and OpenCable-OCAP development for cable digital broadcasting. In the terrestrial cable broadcasting standard, the ATSC-DASE development standard is continuously defined, and these are published as they are continuously updated through associations and conferences. In addition, in the case of OCAP and DASE method, the interoperability is too low, and the proposal for development standard of ACAP (Advanced OCAP) method that integrates each other is actively discussed.
국내의 경우도 세계적 추세에 맞춰 MHP, OCAP, DASE 등을 쌍방향 데이터 방송의 개발 표준 스펙으로 정의하고 이에 맞는 다양한 서비스 기술 및 컨텐츠를 연구하려고 노력중이다. 특히, OCAP의 경우 국내 시장에서 가장 규모가 큰, 다시 말해 시장성이 가장 높은, 디지털 케이블 방송에서의 개발 표준인 관계로 관련 기반 기술을 하루라도 먼저 확보하는 업체가 가장 높은 쌍방향 데이터 방송용 컨텐츠 제작 능력과 시장 점유율을 가진다라고 해도 과언이 아니다. 한편 MHP 방식의 개발 표준은 이미 한국디지털위성방송(주)에서 채택하여 상업적 목적의 쌍방향 서비스를 개시하였으며, 케이블 방송 업체의 경우는 OCAP 표준 개발 스펙을 따르자는 기본적 방침만 확인한 상황으로, 금년 상반기 중 개발자를 위한 OCAP 기반 STB(셋탑박스)가 시험 출시될 상황으로 예견된다. 그러나 아직까지 이러한 표준 개발안 중에서 어느 것도 세계 시장에서 상용화되어 완벽하게 제품화된 사례가 없다.In Korea, MHP, OCAP, and DASE are defined as the development standard specification for interactive data broadcasting in accordance with the global trend, and various service technologies and contents are being researched accordingly. In particular, in the case of OCAP, which is the largest development standard in the domestic market, that is, the marketable, digital cable broadcasting company, the company that secures the relevant base technology first and foremost has the highest ability to produce contents for interactive data broadcasting. It is no exaggeration to have a market share. Meanwhile, the development standard of the MHP method has already been adopted by Korea Digital Satellite Broadcasting Co., Ltd. to launch a commercial interactive service, and cable companies only confirmed the basic policy to follow the OCAP standard development specification. OCAP-based STBs (set-top boxes) for developers are expected to be put to market. However, none of these standards developments are commercially available and fully commercialized in the global market.
본 발명이 이루고자 하는 기술적 과제는, 데이터 방송용 컨텐츠의 개발시 환경설정에 해당하는 부분을 매번 다시 작성해야 하는 불편함을 제거하여 개발자가 컨텐츠 내용의 작성에 치중할 수 있는 OCAP 기반의 라이브러리를 구축하는 방법 및 구축된 OCAP 기반의 라이브러리가 저장된 기록매체를 제공하는 데 있다.The technical problem to be solved by the present invention is to eliminate the inconvenience of having to rewrite the part corresponding to the environment setting at the time of the development of data broadcasting contents, and to build an OCAP-based library in which the developer can focus on the contents contents. The method and the OCAP-based library is built to provide a storage medium.
상기의 기술적 과제를 달성하기 위한, 본 발명에 따른 OCAP 기반의 라이브러리 구축 방법은, OCAP 표준 라이브러리를 구성하는 복수개의 패키지를 설정하는 단계; 상기 설정된 각각의 패키지를 구성하는 적어도 하나의 미들웨어 독립적인 클래스를 설정하는 단계; 데이터 방송용 컨텐츠 제작을 위한 표준 미들웨어 패키지를 구성하는 클래스들을 상기 미들웨어 독립적인 클래스에 대응시켜 상기 미들웨어 클래스의 기능을 확정하는 단계; 상기 표준 미들웨어 패키지를 구성하는 클래스 중에서 공통으로 사용되는 클래스를 참조하여 상기 미들웨어 독립적인 패키지를 구성하는 제1패키지를 생성하는 단계; 및 상기 표준 미들웨어 패키지를 구성하는 클래스 중에서 미들웨어 종속정인 클래스를 참조하여 상기 미들웨어 독립적인 패키지를 구성하는 제2패키지를 생성하는 단계;를 갖는다. In order to achieve the above technical problem, an OCAP-based library construction method according to the present invention comprises: setting a plurality of packages constituting an OCAP standard library; Setting at least one middleware independent class constituting each set package; Determining functions of the middleware class by mapping classes constituting a standard middleware package for data broadcasting content production to the middleware independent class; Generating a first package constituting the middleware independent package by referring to a class commonly used among classes constituting the standard middleware package; And generating a second package constituting the middleware-independent package by referring to a middleware dependent class among classes constituting the standard middleware package.
이에 의해, 데이터 방송용 컨텐츠의 개발시에 환경설정에 해당하는 부분에 대한 고려없이 컨텐츠 내용의 작성에 치중할 수 있다.As a result, it is possible to focus on the creation of content contents without considering the part corresponding to the environment setting at the time of development of the data broadcasting content.
이하에서 첨부된 도면들을 참조하여 본 발명에 따른 OCAP 기반의 라이브러리 구축 방법의 바람직한 실시예에 대해 상세하게 설명한다.Hereinafter, with reference to the accompanying drawings will be described in detail a preferred embodiment of the OCAP-based library construction method according to the present invention.
도 1은 본 발명에 따른 OCAP 기반의 라이브러리가 위치하는 OCAP 프로토콜 스택의 구조를 도시한 도면이다.1 is a diagram illustrating a structure of an OCAP protocol stack in which an OCAP-based library is located according to the present invention.
도 1을 참조하면, OCAP 프로토콜 스택(100)은 OCAP 기반의 미들웨어(110), OCAP 표준 라이브러리(120), 운영엔진(130), 애플리케이션모듈(140), 게임모듈(150), 설정모듈(160) 및 전자프로그램가이드모듈(170)로 구성된다.Referring to FIG. 1, the OCAP
OCAP 기반의 미들웨어(110)는 물리계층과 애플리케이션 계층의 사이에 위치하여 양자간의 데이터, 제어명령 및 이벤트의 전달을 중계한다. OCAP 표준 라이브러리(120)는 OCAP 기반의 미들웨어(110)와 애플리케이션모듈(140)/게임모듈(150) 사이에 위치하며, 개발자가 데이터 컨텐츠 개발시 참조할 수 있는 API를 제공한다. 운영엔진(130)은 OCAP 기반의 미들웨어(110)와 설정모듈(160)/전자프로그램가이드모듈(170) 사이에 위치하며, OCAP 기반의 미들웨어(110)를 통해 물리계층으로부터 입력되는 제어명령에 따라 설정모듈(160)/전자프로그램가이드모듈(170)의 동작을 제어한다. 애플리케이션모듈(140)은 방송용 서비스 컨텐츠를 제공하며, 게임모듈(150)은 방송용 게임서비스를 제공한다. 설정모듈(160)은 운영자로부터 입력되는 명령 또는 OCAP 기반의 미들웨어(110)를 통해 물리계층으로부터 입력되는 제어명령에 따라 장치의 동작환경을 설정한다. 전자프로그램가이드모듈(170)은 방송 프로그 램에 대한 정보를 제공한다. OCAP-based
도 2는 본 발명에 따른 OCAP 기반의 라이브러리 구축 방법에 대한 바람직한 실시예의 수행과정을 도시한 흐름도이다.2 is a flowchart illustrating a process of performing a preferred embodiment of the OCAP-based library construction method according to the present invention.
도 2를 참조하면, 먼저, OCAP 표준 라이브러리를 구성하는 복수개의 패키지를 설정한다(S200). 이 때, 각각의 패키지는 디지털 컨텐츠의 개발자의 요청사항에 따라 설정되며, 개발자의 요청사항은 개발환경과 관련된 요청사항, 화면 디자인과 관련된 요청사항, 리소스 처리 및 관리와 관련된 요청사항, 그리고, 인터랙션 구현과 관련된 요청사항으로 구분된다. 각각의 요청사항과 관련된 구체적인 내용은 다음과 같다.2, first, a plurality of packages constituting the OCAP standard library is set (S200). At this time, each package is set according to the developer's request of the digital content, the developer's request is the request related to the development environment, the request related to the screen design, the request related to resource processing and management, and the interaction It is divided into requests related to implementation. Specific contents related to each request are as follows.
개발환경과 관련된 요청사항은 클래스의 단일화, 환경설정부분의 프리셋팅, 및 워크플로우로 구분된다. Requests related to the development environment are divided into class unification, configuration presetting, and workflow.
먼저, 클래스의 단일화와 관련하여, 데이터 방송용 컨텐츠는 PC용 컨텐츠에 비해 훨씬 많은 API의 상속 및 구현을 필요로 한다. 자바 API는 대부분 PC 환경을 위해 개발된 것으로 데이터 방송 환경에 맞는 여러 API들의 개발이 필요하다. 한편, PC용 팝업창 구현에 비해 데이터 방송용 팝업창 구현은 훨씬 많은 수의 클래스들의 상속을 필요로 하게 되며 수백여 개의 클래스 중에서 필요한 클래스들을 구성하는 것은 각 개발자의 판단에 의지할 수 밖에 없다. 따라서, 팝업창 구현에 필요한 모든 클래스들을 미리 그룹지어 놓아 하나의 클래스를 통해 팝업창 구현이 가능하게 된다면 훨씬 효율적인 컨텐츠 개발이 이루어질 수 있다. 이 경우, 개발자는 팝업창 구현에 필요한 모든 클래스들에 대해 고려할 필요없이 하나의 팝업창 생성 기능을 담당하는 클래스에 접근하여 팝업창 구현시 필요로 하는 모든 메쏘드에의 접근이 가능하기 때문이다. First, with regard to the unification of classes, data broadcasting contents require much more inheritance and implementation of APIs than PC contents. Most Java APIs are developed for the PC environment and require development of various APIs for the data broadcasting environment. On the other hand, the pop-up window implementation for data broadcasting requires much more inheritance than the pop-up window implementation for PC, and the composition of the necessary classes among hundreds of classes is inevitably dependent on each developer's judgment. Therefore, if all the classes required for pop-up window implementation are grouped in advance and the pop-up window can be implemented through one class, much more efficient content development can be achieved. In this case, the developer can access all the methods needed to implement the pop-up window by accessing the class responsible for creating a pop-up window without having to consider all the classes necessary for the pop-up window.
다음으로, 환경설정부분의 프리셋팅과 관련하여, 디지털 방송에서는 PC 환경과는 다른 여러 디바이스 셋팅이 필요하다. 예를 들어 디지털 방송의 화면은 백그라운드 레이어, 비디오 레이어, 그래픽스 레이어 등 3개의 디스플레이 레이어로 구성된다. 이러한 디스플레이 레이어나 디지털 방송 정보를 나타내주는 EPG(Electronic Program Guide) 접근을 비롯한 기타 여러 장치를 위한 환경 설정이 필요하며, 컨텐츠 개발시에 이와 같은 환경설정에 해당하는 부분을 매번 다시 작성해야 하는 불편함이 있다. 따라서 환경 설정에 관한 부분을 캡슐화를 통해 은닉함으로써 개발자가 컨텐츠 외부적인 요소는 신경 쓰지 않고 컨텐츠 내용에 치중하여 개발할 수 있도록 하는 기능이 필요하다. Next, with regard to the presetting of the configuration part, digital broadcasting requires various device settings different from those of the PC environment. For example, a screen of a digital broadcast is composed of three display layers, a background layer, a video layer, and a graphics layer. It is necessary to set up the environment for such a display layer or EPG (Electronic Program Guide) access that shows digital broadcasting information, and to rewrite the corresponding part of the environment every time the content is developed. have. Therefore, there is a need for a function that enables developers to concentrate on the contents of contents without being concerned about external elements of contents by encapsulating the environment setting through encapsulation.
다음으로, 워크플로우(workflow)와 관련하여, 데이터 방송용 컨텐츠 제작에 많은 경험이 없는 개발자는 API나 튜토리얼을 분석한다 하더라도 프로그램 코딩을 어디서부터 어떠한 순서대로 진행시켜야 할지 쉽게 파악하기 어렵다. 따라서 여러 컨텐츠를 개발해 본 경험을 바탕으로 작성된 워크플로우 제공이 필요하며 워크플로우는 서비스 도메인에 따라 차이가 있다. Next, in terms of workflow, developers who do not have much experience in producing content for data broadcasting, it is difficult to figure out where and in what order the program coding should proceed even if the API or tutorial is analyzed. Therefore, it is necessary to provide a workflow created based on the experience of developing various contents, and the workflows vary depending on the service domain.
또한, 화면디자인과 관련된 요청사항은 그래픽, 버퍼드 이미지(BufferedImage) 생성, 애니메이션, 및 이미지 조작으로 구분된다. In addition, requests related to screen design are divided into graphics, buffered image generation, animation, and image manipulation.
먼저, 그래픽과 관련하여, 데이터 컨텐츠 구현시 화면 레이아웃에 빈번하게 사용되는 버튼, 풀다운 메뉴 , 팝업창, 라디오 버튼, 체크박스 등의 컴포넌트를 손 쉽게 사용할 수 있는 인터페이스가 필요하다. First, with regard to graphics, an interface for easily using components such as buttons, pull-down menus, pop-up windows, radio buttons, and checkboxes that are frequently used for screen layout in data content implementation is needed.
다음으로, 버퍼드 이미지의 생성과 관련하여, 데이터 방송용 컨텐츠는 많은 이미지들로 구성이 되며 개발자는 이미지 처리를 위해 이미지 개수 및 크기 등을 고려해야 한다. 그러나 데이터 방송용 컨텐츠는 셋탑박스에서 디코딩되어 표현되므로 PC 환경의 컨텐츠보다 메모리나 전송 대여폭등의 제약 조건이 많다. 특히 같은 이미지를 매번 반복해서 화면에 디스플레이를 해줘야하는 경우 애플리케이션과 이벤트 발생 사이에 시간적 지연이 발생할 수 있으므로, 이를 방지할 수 있는 버퍼드 이미지의 사용이 필수적이다. Next, in relation to the generation of the buffered image, the content for data broadcasting is composed of many images, and the developer should consider the number and size of the image for image processing. However, data broadcasting contents are decoded in the set-top box, so there are more constraints such as memory or transmission rental width than contents in a PC environment. In particular, if the same image needs to be repeatedly displayed on the screen each time, there may be a time delay between the application and the occurrence of an event. Therefore, it is necessary to use a buffered image to prevent this.
다음으로, 애니메이션과 관련하여, 데이터 방송용 컨텐츠에서 애니메이션 기능은 다른 어떤 기능보다 매우 빈번하게 사용되나 애니메이션 효과를 나타내기 위하여 개발자가 고려해야할 사항이 많아 애니메이션 효과를 위한 프레임 설정, 삽입될 이미지 설정, 반복 시간 등을 쉽게 컨트롤할 수 있는 인터페이스가 필요하다. Next, in relation to animation, animation functions are used more frequently than any other functions in data broadcasting contents, but there are many things that developers need to consider in order to show animation effects. Frame setting for animation effects, image setting to be inserted, and repetition You need an interface that allows easy control of time, etc.
다음으로, 이미지 조작과 관련하여, 제작자가 이미지 크기 조절, 이미지 조각내기, 이미지의 투명색 설정 등을 용이하게 제어할 수 있는 기능이 필요하다. Next, in relation to image manipulation, a function that allows a producer to easily control image resizing, image fragmentation, and transparent color setting of an image is needed.
또한, 리소스 처리 및 관리와 관련된 요청사항은 자원관리 및 풀링기능을 포함한다.In addition, requests related to resource processing and management include resource management and pooling functions.
먼저, 자원관리와 관련하여, 전송되는 애플리케이션 및 모든 멀티미디어 데이터 등에 대한 접근과 애플리케이션 실행 후 반환되는 리소스들을 손쉽게 관리할 수 있는 기능이 요구된다. 다음으로, 풀링(Pooling) 기능(이미지 풀링, 쓰레드 풀링, 소켓 풀링)과 관련하여, 풀링은 필요한 것들을 미리 할당시켜 놓는 기법을 말 하며 데이터 방송 환경에서는 이미지 풀링, 쓰레드 풀링, 소켓 풀링 등이 사용될 수 있다. PC 환경에 비해 프로그램 수행에 따른 제약조건이 많은 디지털 방송 환경에서 풀링 개념을 이용하게 되면 프로그램 수행 시간이 빨라져 작업 처리가 효율적으로 이뤄질 수 있다. 또한 반복적으로 사용되는 컨텐츠 리소스의 생성/소멸 처리에 대한 비효율적인 작업도 줄일 수 있다. First, with regard to resource management, a function for accessing the transmitted application and all multimedia data and the like and easily managing resources returned after the application is required is required. Next, with regard to the pooling functions (image pooling, thread pooling, socket pooling), pooling is a technique of pre-assigning necessary things.In data broadcasting environment, image pooling, thread pooling, socket pooling, etc. can be used. have. When the concept of pooling is used in a digital broadcasting environment that has more constraints on program execution than in a PC environment, the execution time of a program can be increased, and work processing can be efficiently performed. In addition, it is possible to reduce inefficient work of creating / destroying content resources that are repeatedly used.
또한, 인터랙션 구현과 관련된 요청사항은 키입력 및 리턴채널을 포함한다.In addition, requests related to the interaction implementation include key input and return channels.
먼저, 연속키/복합키와 같은 키입력과 관련하여, 디지털 방송에서 사용자와의 상호작용은 PC에서 사용되는 키보드나 마우스가 아닌 TV 리모컨을 통하여 이루어진다. 리모컨에 구현된 특수키의 갯수는 매우 한정적이어서 제공되는 특수키만을 이용하여 애플리케이션과 상호작용을 표현하기는 힘들다. 따라서 컨텐츠 개발시 빈번하게 사용되는 복합키와 연속키의 구현이 필요하다. 복합키는 동시에 두개의 키 입력을 인식하는 기능을 뜻하며, 연속키는 키를 계속 누르고 있는 상태를 계속적인 이벤트로 인식하는 기능을 뜻한다. 다음으로, 리턴채널과 관련하여, 사용자와의 인터렉티브한 상호작용이 강조되고 있는 시점에서 단방향 방송에서 벗어나 사용자가 정보를 서버로 보낼 수 있도록 메시지 은닉, 네트워크 환경 설정 등을 쉽게 구현할 수 있는 클래스들이 필요하다. First, in relation to key input such as a continuous key / composite key, interaction with a user in digital broadcasting is performed through a TV remote control, not a keyboard or a mouse used in a PC. The number of special keys implemented in the remote control is very limited, so it is difficult to express the interaction with the application using only the provided special keys. Therefore, it is necessary to implement a compound key and a continuous key which are frequently used in content development. A compound key is a function that recognizes two key inputs at the same time, and a continuous key is a function that recognizes a state of continuously pressing a key as a continuous event. Next, with respect to the return channel, when the interactive interaction with the user is emphasized, a class is needed to easily implement message concealment, network configuration, etc. so that the user can send information to the server away from unidirectional broadcasting. Do.
또한, 사운드와 관련된 요청사항은 사운드 처리기능이 포함되며, 사운드 처리기능과 관련하여, 데이터 방송용 컨텐츠에는 디스플레이되는 내용 더불어 사운드 효과가 컨텐츠의 내용전달에 매우 중요한 역할을 담당한다. 스트림 형태의 사운드는 JMF 등을 통해 처리하지만 애플리케이션에서 파일 형태로 접근하는 사운드 파일 에 대한 작업은 개발자가 매번 손수 구현을 해야 한다. 따라서 이러한 파일 형태로 파일 접근하게 되는 음원을 개발자가 손쉽게 컨트롤할 수 있는 인터페이스 구현이 요구된다. In addition, the request related to sound includes a sound processing function, and in relation to the sound processing function, the sound effect plays a very important role in the content delivery in addition to the content displayed in the data broadcasting content. Although stream-type sounds are handled through JMF, etc., developers must manually implement the sound files that are accessed as files in the application each time. Therefore, there is a need for an interface implementation that allows developers to easily control sound sources that access files in the form of files.
다음으로, 설정된 각각의 패키지를 구성하는 적어도 하나의 미들웨어 독립적인 클래스를 설정한다(S210). 데이터 컨텐츠 제작 업체에서 필요로 하는 기능 조사를 바탕으로 47개의 클래스들을 설정할 수 있으며, 각각의 클래스들은 기능에 따라 크게 9개의 패키지로 분류될 수 있다. 각각의 패키지의 명칭은 GEM, MHP, OCAP, ACAP에서 API 분류 시 사용하는 카테고리 이름을 참고하여 부여된다. OCAP 표준 라이브러리를 구성하는 패키지는 그래픽 환경설정 초기화와 그래픽생성을 위한 클래스들을 포함하는 GUI API, 스트림 미디어를 실시간으로 제어하고 이벤트를 관리하기 위한 클래스들을 포함하는 스트림미디어 API, 사운드의 환경설정과 제어를 위한 클래스들을 포함하는 사운드 API, 멀티미디어 데이터에 대한 접근과 리소스 반환을 위한 클래스들을 포함하는 컨텐츠 자원관리 API, 애플리케이션의 라이프 사이클의 제어와 컨텐츠 서비스 제어를 위한 클래스들을 포함하는 프로세스 제어 API, 키입력과 디스플레이의 동기화의 제어를 위한 클래스들을 포함하는 키이벤트 관리 API, 파일 입출력과 시스템간의 데이터 송수신의 제어를 위한 클래스들을 포함하는 데이터 접근 관리 API, 다중화된 전송 스트림에서 특정한 서비스를 선택하고 서비스정보 테이블에 대한 접근기능을 제공하기 위한 클래스들을 포함하는 서비스정보 및 선택 제어 API 및 사용자와의 상호작용이 가능한 컨텐츠 구현을 위한 클래스들을 포함하는 리턴 채널 제어 API를 포함한다.Next, at least one middleware independent class constituting each set package is set (S210). 47 classes can be set based on the function research required by the data content producer, and each class can be classified into 9 packages according to functions. Each package is named after referring to the category name used for classifying APIs in GEM, MHP, OCAP, and ACAP. The packages that make up the OCAP standard library include a GUI API that includes classes for initializing graphics preferences and creating graphics, a stream media API that includes classes for managing stream media and managing events in real time, and configuring and controlling sounds. A sound API including classes for content management, a content resource management API including classes for accessing and returning multimedia data, a process control API including classes for controlling an application's life cycle and content services, and key input Key event management API including classes for controlling the synchronization of display and display, data access management API including classes for controlling data input / output and data transmission and reception between systems, selecting a specific service from a multiplexed transport stream It includes service information and selection control API including classes for providing access to the table and a return channel control API including classes for implementing content that can interact with a user.
각각의 API에 포함되는 세부 클래스들은 다음과 같다.Detailed classes included in each API are as follows.
1. GUI API(Graphic User Interface API)1.Graphic User Interface API
배경계층(Background Layer), 영상계층(Video Layer), 그래픽계층(Graphics Layer)을 위한 그래픽 환경 설정 초기화와 이미지 및 그래픽스를 위한 클래스들을 정의하며 다음과 같은 클래스들을 포함한다. Initializes graphic environment setup for background layer, video layer, and graphics layer, and defines classes for images and graphics. It includes the following classes.
● GraphicEnvironment: 그래픽 환경 초기화 설정 및 백그라운드 디바이스와 그래픽 디바이스 설정을 위해 캡슐화된 클래스이다. • GraphicEnvironment: Encapsulated class for graphic environment initialization and background device and graphic device configuration.
● GraphicEnvironmentListner: 캡슐화되어 은닉된 GraphicEnvironment class에 접근을 위한 인터페이스이다. • GraphicEnvironmentListner: An interface for accessing encapsulated and hidden GraphicEnvironment classes.
● PopupWindow: Graphics Layer 위에 웹 브라우저의 팝업창과 같은 기능을 간단히 구현할 수 있는 인터페이스 제공한다. • PopupWindow: Provides an interface to easily implement a popup window of a web browser on the Graphics Layer.
● Animation: 프레임 설정, 삽입될 이미지 설정, 반복 시간 설정 등의 기능을 제공해주는 클래스이다. • Animation: This class provides functions such as frame setting, image to be inserted, and repetition time.
● Button: HGraphic Button과 HTextButton의 기능을 모두 갖고 있는 단일 클래스이다. • Button: A single class that has both the HGraphic Button and HTextButton functions.
● RadioButton: 라디오 버튼 기능 구현을 위한 클래스이다. • RadioButton: This class implements radio button function.
● CheckBox: 체크 박스 기능 구현을 위한 클래스이다. • CheckBox: This class implements the check box function.
● GUIFactory: 팝업창, 애니메이션, 버튼, 라디오 버튼, 체크박스 등 GUI를 위한 컴포넌트들을 생성하여 사용하기 위한 클래스이다. ● GUIFactory: This class is used to create and use components for GUI such as popup window, animation, button, radio button, and check box.
● ImageTransformation: 이미지 크기조정, 이미지 이동, 이미지 회전, 이미 지 fragmentation 등의 조작을 위한 클래스이다. • ImageTransformation: This class is for image resizing, image movement, image rotation, and image fragmentation.
● ImageFragment: 프로그램 수행 속도를 높이기 위하여 이미지를 여러 조각 낸 후 사용하기 위한 클래스이다. • ImageFragment: This class is used to slice out several pieces of image to speed up program execution.
● PullDown: 풀다운 메뉴를 통하여 컨텐츠 UI를 구성하기 위한 클래스이다. ● PullDown: This class is used to compose content UI through pulldown menu.
● XYLayout: 그래픽 컴포넌트를 패널과 같은 그래픽 컨테이너 상에서 위치를 정할 때 상대적인 위치 설정이 가능한 클래스로 컨테이너의 크기 변형에 따라 위치를 재정의 해야 하는 불편함을 없앨 수 있다. • XYLayout: A class that allows relative positioning when positioning graphic components on graphic containers such as panels, and eliminates the inconvenience of having to redefine the position according to the size change of the container.
2. 스트림미디어 API(Streamed Media API)2. Streamed Media API
스트림 미디어를 실시간으로 제어 및 이벤트 관리를 위한 클래스들을 포함한다. Contains classes for controlling and managing stream media in real time.
● MediaController: 스트림 미디어의 재생, 정지, 반복, 부분 재생 등의 기능을 제공하는 클래스이다. • MediaController: This class provides functions for playing, stopping, repeating, and playing partial stream media.
● MediaManager: 스트림 미디어를 사용하는 모든 클래스의 생성 및 관리를 담당한다. MediaManager is responsible for creating and managing all classes that use stream media.
3. 사운드 API(Sound API)3. Sound API
스트림 미디어 형태가 아닌 애플리케이션에서 파일 형태로 접근하는 사운드의 환경 설정, 재생, 정지 등 사운드 컨트롤을 위한 클래스들을 포함한다. Contains classes for sound control, such as setting, playing, and stopping sounds that are accessed in the form of files from applications that are not in the form of stream media.
● Sound: Hsound를 내부적으로 생성하여 소리의 재생, 정지, 자원 해지 등을 쉽게 제어할 수 있는 기능을 제공한다. ● Sound: By creating Hsound internally, it provides a function to easily control the playback, stop, and resource release of sound.
4. 컨텐츠 리소스 API(Contents Resource API)4. Contents Resource API
사운드, 이미지 등 멀티미디어 데이터에 대한 접근과 애플리케이션 실행 후 리소스 반환을 위한 클래스들을 포함한다. Contains classes for accessing multimedia data such as sound and image and returning resources after application execution.
● ResourceManager: 모든 클래스에서 사용하는 자원을 생성하고 자원 해지를 위한 클래스이다. ResourceManager: A class used to create and release resources used by all classes.
● ImagePool: HashTable의 이미지 ID 값과 이미지보관을 위한 클래스로 계속 사용되는 이미지와 한번 사용 후 자원 해지 되는 이미지에 대한 정보를 제공한다. • ImagePool: Provides information about the image ID value of the HashTable and the image that is continuously used as a class for image storage and the image that is released after being used.
● SoketPool: 1:N의 수월한 통신을 위해 미리 소켓 설정을 하는 클래스이다. • SoketPool: This is a class that configures socket in advance for easy 1: N communication.
● ThreadPool: 여러 가지 작업을 동시에 수행할 수 있도록 멀티 태스크 구현을 위한 클래스 이다. • ThreadPool: A class for implementing multiple tasks so that various tasks can be performed at the same time.
● ImagePoolListener: ImagePool 클래스에 접근하기 위한 인터페이스이다. • ImagePoolListener: The interface to access the ImagePool class.
● SoketPoolListener: SoketPool 클래스에 접근하기 위한 인터페이스이다. SoketPoolListener: An interface for accessing the SoketPool class.
● ThreadPoolListener: ThreadPool 클래스에 접근하기 위한 인터페이스이다. • ThreadPoolListener: The interface to access the ThreadPool class.
● TimeTask: 비디오 컨텐츠와 데이터 컨텐츠의 시간 동기화 및 데이터 컨텐츠 자체의 실행 시간 제어를 위한 클래스이다. • TimeTask: This class is for time synchronization of video content and data content and execution time control of data content itself.
5. 프로세스제어 API(Process Control API)5. Process Control API
애플리케이션의 라이프 사이클 구현과 컨텐츠 서비스 분야에 따른 핵심 알고리즘을 위한 클래스들을 포함한다. Contains classes for core algorithms in the life cycle implementation of the application and in the context of content services.
● ProcessXlet: Xlet 인터페이스를 구현한 클래스로 실제 하나의 애플리케이션 라이프 사이클을 갖는 클래스로 메인 쓰레드를 포함하고 있다. • ProcessXlet: A class that implements the Xlet interface, which actually has a single application life cycle. It contains the main thread.
● Core: 컨텐츠의 특성에 맞는 애플리케이션의 핵심 알고리즘이 구현되는 클래스이다. ● Core: This class implements the core algorithm of the application that matches the characteristics of the content.
6. 키이벤트 API(Key Event API)6. Key Event API
연속키, 키 초기화, 특수키 맵핑, 키 입력과 디스플레이의 동기화를 위한 클래스들을 정의하여 상수의 삽입과 삭제가 용이하도록 하였으며 연속키를 통한 화면 디스플레이의 동기화를 구현하였다. By defining classes for serial key, key initialization, special key mapping, key input and display synchronization, constant insertion and deletion are made easy and synchronization of screen display through serial key is implemented.
● ChainKeyEvent: 리모컨의 버튼을 계속 누르고 있을 때 이를 연속적인 이벤트로 받아들여 처리하는 기능 제공하며 키가 계속 눌러질 때 Key Buffer에 연속적으로 값을 넣어 줌으로써 계속적으로 값을 반환하는 모듈을 포함한다. ● ChainKeyEvent: Provides a function that accepts and processes a continuous event when a button on the remote control is held down, and includes a module that continuously returns a value by continuously inserting a value into the key buffer when a key is pressed.
● WaitBreak: 애플리케이션이 종료, 무한 반복, 일시 정지 상태일 때 버튼 이벤트를 통해 현재 상태를 빠져 나오는 기능을 제공한다. • WaitBreak: Provides the ability to get out of the current state through a button event when the application is in a shutdown, infinite loop, or pause state.
● EventManager: 애플리케이션 수행 중 발생하는 모든 Event를 관리하기 위해서 만든 클래스로 HKeyListener를 상속 받은 abstract 클래스를 반환하며 Singleton Pattern을 적용하여 오직 하나만 Instance를 생성하여 사용을 원할 경우 참조를 통하여 접근가능하다. ● EventManager: This class is created to manage all events that occur during application execution. It returns an abstract class that inherits HKeyListener. It can be accessed by reference when only one instance is created by applying Singleton Pattern.
● CompositeKeyEvent: 두개의 키를 동시에 눌렀을 때 발생하는 이벤트를 저장 하고 두개의 키를 연속적으로 계속 반환 해주는 기능을 제공한다. CompositeKeyEvent: Provides a function to save an event that occurs when two keys are pressed at the same time, and to continuously return two keys.
● DefaultKeyEvent: 기본적인 KeyEvent를 구현한 클래스로 getKey() 메소드 를 통해 현재 Pressed된 키 값을 가져온다. • DefaultKeyEvent: A class that implements basic KeyEvent. Gets the key value currently pressed through getKey () method.
● KeyConstants: 키 상수 값 설정 기능을 담당하는 클래스이다. • KeyConstants: This class is responsible for setting key constant values.
● KeyEvent: 키 값을 키 버퍼에 담아 두기, 작업 흐름을 잠시 정지 시키고 확인키에만 반응하여 재시작 하기, 작업 흐름을 잠시 정지 시키고 어떤 키 입력이라도 반응 하여 재시작 하기 기능 구현한다. • KeyEvent: Implements the function of storing the key value in the key buffer, stopping the workflow temporarily and restarting in response to the confirmation key only, stopping the workflow temporarily and restarting in response to any key input.
7. 데이터 접근제어 API(Data Access API)7. Data Access API
모든 파일의 입출력과 시스템간의 커뮤니케이션을 위한 클래스들을 포함한다. Contains classes for input and output of all files and communication between systems.
● DataInputStream: 데이터 통신을 위해 전달되는 메시지를 각각의 프로토콜 정의에 맞게 패킷 단위로 분리 저장하여 다른 시스템이 보낸 메시지를 읽어 들이는 기능 제공한다. ● DataInputStream: It saves the message transmitted for data communication in packet unit according to each protocol definition and provides the function to read the message sent from other system.
● DataManager: 데이터 처리와 관련된 기능을 수행하는 모든 클래스들의 생성 및 제어와 메시지 반환에 대한 관리 기능을 제공하며 데이터와 관련된 기능을 가진 클래스는 이 클래스의 제어를 받고 데이터를 반환을 하는 관리 기능이 집중된 클래스이다. ● DataManager: Provides management functions for creating and controlling all classes that perform data processing related functions and returning messages. Classes with data related functions have control of this class and centralized management functions for returning data. Class.
● Client: Socket 클래스를 상속받은 클래스로 Server 클래스와의 통신을 담당하는 클래스로 주로 Message 클래스 안에 모든 내용을 캡슐화 하여 서버로 보낸다. DataInputStream과 DataOutputStream 클래스를 사용하게 되며 이 두개의 클래스를 반환하여 서버와의 교신에 사용한다. ● Client: A class that inherits Socket class and is in charge of communication with Server class. It mainly encapsulates all contents in Message class and sends it to server. You will use the DataInputStream and DataOutputStream classes and return these two classes to communicate with the server.
● DataOutputStream: 데이터 통신을 위해 전달되는 메시지를 각각의 프로토 콜 정의에 맞게 패킷 단위로 분리 저장하여 다른 시스템 보내기 위한 기능을 제공한다. ● DataOutputStream: Provides the function to send the message to other system by storing the message transmitted for data communication in packet unit according to each protocol definition.
● Message: 리턴채널을 통해 전달되는 메시지가 외부에 노출되지 않도록 캡슐화 하는 인터페이스Message 클래스는 Message를 표준화 하여 각각의 기능으로 분리한 메소드를 선언을 해 놓은 인터페이스이다. Message 인터페이스를 통해 여러 가지 Message클래스를 확장 할 수 있고 생성된 Message는 DataManager를 통해 관리 된다. Message: An interface that encapsulates a message delivered through a return channel so that it is not exposed to the outside. The Message class is an interface that standardizes Message and declares methods separated into their respective functions. Various Message classes can be extended through the Message interface, and the generated Message is managed through the DataManager.
● MessageImpl: Message 인터페이스를 확장한 클래스이다. MessageImpl: A class that extends the Message interface.
● Protocol: XML로 정의한 프로토콜을 가져와 이름과 값으로 프로토콜을 재정의 하는 클래스로 프로토콜 정의를 XML문서로 만들어 손쉽게 재정의 할 수 있다. ● Protocol: A class that imports a protocol defined by XML and overrides the protocol by name and value. You can easily redefine the protocol definition by creating an XML document.
● Server: 서버 소켓을 쉽게 구현하기 위해서 만든 클래스이다. 주로 서버 소켓을 생성하여 구동시킬 수 있으며 서버 여러 개 구현하면 여러 개의 서버를 만들 수 있다. 또한 클라이언트 접속에 관한 부분을 처리를 하게 된다. Server: This class is designed to easily implement server sockets. You can create and run server sockets mainly. If you implement multiple servers, you can create multiple servers. It also takes care of the client connection.
● SessionManager: 서버에 클라이언트가 접속 시 새로운 소캣을 만들어 반환하고 소캣을 구동을 시키는 역할을 하는 클래스로 현재 접속된 클라이언트 수를 쉽게 파악할 수 있으며 클라이언트의 제어가 가능한 클래스이다. ● SessionManager: A class that creates and returns a new socket when the client connects to the server, and runs the socket. It can easily determine the number of clients currently connected and can be controlled by the client.
● UIListener: 소캣 클라이언트 접속 시 UI와의 느슨한 연결을 위하여 UIListener를 상속 받아야 하며 Client와의 확장성을 고려한 Interface이다. ● UIListener: When connecting Socat client, UIListener should be inherited for loose connection with UI. This interface considers extensibility with Client.
8. 서비스정보 및 선텍제어 API(Service information and selection API)8. Service information and selection API
다중화된 전송 스트림에서 특정 서비스를 선택하고 서비스정보(Service Information : SI) 테이블에 대한 접근 등의 기능을 제공하는 클래스들이다. Classes that select specific services from multiplexed transport streams and provide access to service information (SI) tables.
● SIManager: 로케이터 값을 통한 SI 테이블 정보 반환과 서비스 이동을 위한 메소드 등을 제공한다. ● SIManager: Provides methods to return SI table information and move service through locator value.
● SITable: SI Data를 애플리케이션에 비동기적으로 제공하고 SI Data가 변경될 경우 애플리케이션에게 통보하는 매커니즘을 제공한다. • SITable: Provides SI data asynchronously to the application and provides a mechanism to notify the application when SI data changes.
9. 리턴 채널 제어 API(Return Channel API) 9. Return Channel API
사용자와의 인터랙티브한 컨텐츠 구현을 위해 필요한 클래스들이다. These are the classes needed to implement interactive content with the user.
● Message: 리턴채널을 통해 전달되는 메시지가 외부에 노출되지 않도록 캡슐화하는 인터페이스이다. Message: An interface that encapsulates a message delivered through a return channel so that it is not exposed to the outside.
● Network: 메시지를 서버에 전송하기 위한 여러 통신 환경 설정을 위한 클래스이다. ● Network: Class for setting various communication environment for sending message to server.
● ReturnChannelFactory: 내부적으로 RCInterfaceManager를 생성하여 RCInteface를 반환하며 각각의 메소드가 null을 반환 할 경우 접속 오류 Exception을 발생시킨다. 또한 모든 메소드는 static로 되어 있으며 connection target에 접속 또는 접속해지의 기능을 포함하고 있다. ● ReturnChannelFactory: Creates RCInterfaceManager internally and returns RCInteface. When each method returns null, a connection error exception is thrown. In addition, all methods are static and include the ability to connect to or disconnect from a connection target.
다음으로, 데이터 방송용 컨텐츠 제작을 위한 표준 미들웨어 패키지를 구성하는 클래스들을 미들웨어 독립적인 클래스에 대응시켜 미들웨어 클래스의 기능을 확정한다(S220). 본 발명에 따른 OCAP 표준 라이브러리를 실질적인 클래스로 구현함에 있어서 각각의 API는 패키지로 표현된다. 따라서, OCAP 표준 라이브러리는 itv.gui, itv.streamedmedia, itv.sound, itv.resource, itv.process, itv.event, itv.dataaccess, itv.si, itv.returnchannel 이렇게 총 9개의 패키지로 구성된다. 이러한 9개의 패키지와 기존의 미들웨어(예를 들면, MHP, OCAP, ACAP)에서 사용되는 패키지의 관련성은 다음의 표에 기재되어 있다. Next, the functions of the middleware class are determined by mapping the classes constituting the standard middleware package for data broadcasting content production to the middleware independent class (S220). In implementing the OCAP standard library according to the present invention as a practical class, each API is represented as a package. Thus, the OCAP standard library consists of nine packages: itv.gui, itv.streamedmedia, itv.sound, itv.resource, itv.process, itv.event, itv.dataaccess, itv.si, and itv.returnchannel. The relevance of these nine packages to those used in existing middleware (eg MHP, OCAP, ACAP) is shown in the following table.
표 1을 참조하면, 표준 미들웨어 패키지는 JMF, DAVIC, JavaTV, HAVi, MHP, OCAP 및 ACAP에 대응하는 미들웨어 패키지 중에서 적어도 하나를 포함하며, 각각의 표준 미들웨어 패키지의 기능이 9개의 패키지에 구현된다.Referring to Table 1, the standard middleware package includes at least one of the middleware packages corresponding to JMF, DAVIC, JavaTV, HAVi, MHP, OCAP, and ACAP, and the functions of each standard middleware package are implemented in nine packages.
다음으로, 표준 미들웨어 패키지를 구성하는 클래스 중에서 공통으로 사용되는 클래스를 참조하여 미들웨어 독립적인 패키지를 구성하는 제1패키지를 생성한다(S230). 또한, 표준 미들웨어 패키지를 구성하는 클래스 중에서 미들웨어 종속적인 클래스를 참조하여 상기 미들웨어 독립적인 패키지를 구성하는 제2패키지를 생성한다(S240). 이 때, 제2패키지는 표준 미들웨어 패키지의 종류에 따라 상이한 메쏘드를 호출하거나 상이한 값을 전달하는 변환모듈 및 표준 미들웨어 패키지 각각에만 고유하게 존재하는 API를 지원하기 위해 하위에 존재하는 클래스들과 바이패스 형태의 연결을 설정하는 바이패스 모듈 중에서 적어도 하나를 포함한다.Next, a first package constituting the middleware independent package is generated by referring to a class commonly used among classes constituting the standard middleware package (S230). In addition, the second package constituting the middleware independent package is generated by referring to the middleware dependent class among the classes constituting the standard middleware package (S240). At this time, the second package is bypassed with classes existing below to support APIs unique to each of the conversion module and the standard middleware package that call or transmit different methods according to the type of the standard middleware package. It includes at least one of the bypass module for establishing the connection of the type.
각각의 미들웨어에서 사용하는 패키지는 공통으로 사용되는 집합 및 상이한 패키지 집합이 존재한다. 따라서, 구현될 클래스 역시 상술한 바와 같이 공통으로 사용하는 패키지를 참조하여 구현가능한 클래스와 미들웨어 종속적인 패키지를 참조하여 구현되는 클래스로 구분할 수 있다. 또한, 구현될 클래스들은 공통으로 사용하는 패키지나 미들웨어에 종속적인 패키지 외에도 자바 플랫폼 패키지(Java Platform Package)를 직접 상속받아 필요한 모듈을 구현할 수 있는 데 그 대표적인 예로 이미지풀(ImagePool) 클래스 구현에 사용되는 해쉬테이블(HashTable)이나 벡터(Vector)등으로 이들은 java.util 패키지를 상속 받아 구현가능하다. The packages used in each middleware have a set of commonly used packages and a different set of packages. Therefore, the class to be implemented may also be classified into a class that can be implemented by referring to a package commonly used as described above and a class that is implemented by referring to a middleware dependent package. Also, the classes to be implemented can implement the necessary module by directly inheriting Java Platform Package in addition to the package or middleware dependent package. For example, the ImagePool class is used. As a hashtable or vector, they can be implemented by inheriting the java.util package.
도 3에는 상기와 같은 방법에 의해 구현된 클래스와 자바 플랫폼과의 관계가 도시되어 있다.3 illustrates a relationship between a class implemented by the above method and the Java platform.
도 3을 참조하면, 본 발명에 따른 OCAP 기반의 라이브러리(300)는 공통정의모듈(310), 자체정의모듈(320), 변환모듈(330) 및 바이패스모듈(340)을 포함한다. 공통정의모듈(310)은 도 2를 참조하여 설명한 제1패키지에 해당하며, JMF, DAVIC, JavaTN, HAVi, 및 MHP의 일부 등의 표준 미들웨어에서 공통으로 사용하는 클래스가 포함된 모듈이다. 공통으로 사용하는 패키지를 참조하여 구현되는 클래스인 공통정의모듈(310)은 MA나 OA에 속하는 클래스들을 상속 확장하여 구현되는 클래스로 컨텐츠 개발시 요구사항 중 하나인 클래스 단일화 기능을 제공한다. 도 4에는 공통으로 사용하는 패키지를 참조하여 구현된 클래스의 일예가 도시되어 있다. 자체정의모듈(320)은 다른 표준 미들웨어에는 포함되어 있지 않은 기능을 제공하는 클래스를 포함한다.Referring to FIG. 3, the OCAP-based
한편, 미들웨어 패키지의 기능을 비교·분석하여 기능이 유사한 패키지로 분류되는 경우와 기능이 상이한 패키지로 분류되는 경우에 따라 클래스 구현 방법에 차이가 있다. 먼저, 기능이 유사한 경우는 MA나 OA를 참조하는 경우이며, 미들웨어에 따라 다른 메쏘드를 호출하거나 다른 변환값을 전달해주는 변환모듈(330)로 구현된다. 예를 들어, MHP의 SI 패키지와 OCAP의 SI 패키지는 서로 다르지만 양자 모두 서비스정보를 제공해주기 위한 패키지라는 공통점이 있으므로 기능이 유사한 패키지로 분류된다. 도 5에는 작성된 SI 변환모듈의 일예가 도시되어 있다.On the other hand, there is a difference in class implementation method depending on the case where a function is classified into a similar package by comparing and analyzing the functions of a middleware package and when the function is classified into a different package. First, a similar function is a case of referring to a MA or an OA, and is implemented by a
다음으로, OCAP에는 셋탑박스로부터 보안기능 및 수신제한기능을 분리한 POD(Point of Deployment) 장치를 지원하기 위한 API가 정의되어 있다. POD는 OpenCable 방식을 따르는 모든 미들웨어에 필수적인 하드웨어이며, 다른 미들웨어에는 존재하지 않는 특별한 장치이다. 따라서, 이와 같이 각각의 미들웨어으 특수한 기능을 위해 존재하는 API를 지원하기 위해서는 하부단의 클래스들과의 바이패스 형태의 연결이 필요하며, 바이패스모듈(340)이 이러한 기능을 담당한다. 도 6에는 작성된 바이패스모듈의 일예가 도시되어 있다.Next, OCAP defines APIs to support POD (Point of Deployment) devices that separate security and reception restrictions from set-top boxes. POD is an essential piece of hardware for all middleware that follows the OpenCable approach and is a special device that does not exist in other middleware. Therefore, in order to support the API existing for each specific function of the middleware as described above, a bypass type connection with the lower classes is required, and the
본 발명에 따른 OCAP 기반의 라이브러리 구축방법에 의해 생성된 클래스 라이브러리의 검증을 위해 현재 MHP 환경에서 데이터 컨텐츠 제작시 사용되고 있는 API를 이용하여 구현한 오목 게임 컨텐츠와 본 발명에 따라 구축된 클래스 라이브러리를 이용하여 구현한 오목 게임 컨텐츠를 비교하였다. 본 발명에 따라 구축된 클래스 라이브러리를 이용하여 구현한 오목 게임 컨텐츠는 총 7개의 클래스 파일로 작성되었으며 각 클래스 파일의 상세 내용은 다음과 같다. In order to verify the class library generated by the OCAP-based library construction method according to the present invention, the concave game content implemented using the API currently used in the production of data content in an MHP environment and the class library constructed according to the present invention are used. We compared the concave game contents. The concave game content implemented using the class library constructed in accordance with the present invention was created with a total of seven class files, and the details of each class file are as follows.
● GameAlgorithm: 오목 Engine 부분 GameAlgorithm: Concave Engine
● GameContainer: 오목 게임의 디스플레이, 키 인터렉션, 프로세스 처리 등을 담당하는 클래스 • GameContainer: The class responsible for displaying concave games, key interactions, and process
● GameXlet: Xlet을 구현한 실행 클래스 GameXlet: An execution class that implements Xlet
● Constant: GameContainer에서 쓰이는 모든 상수 값 정의 • Constant: Defines all the constant values used in GameContainer.
● OmokInfo: 오목의 정보를 저장하기 위한 클래스 • OmokInfo: class for storing the information of the concave
● OmokLastStatus: 오목의 마지막 상태를 저장하기 위한 클래스 OmokLastStatus: A class for storing the last state of the concave.
● OmokPosition: 오목의 위치를 저장하기 위한 클래스 • OmokPosition: class for storing the position of the concave
상기와 같은 클래스들 중 오목 게임 컨텐츠의 디스플레이 되는 요소와 관련된 기능을 제공하는 GameAlgorithm, GameContainer, GameXlet 클래스에는 본 발명에 따라 구축된 클래스 라이브러리의 적용이 가능하다. 그 이외의 클래스들은 게임 컨텐츠라는 도메인적인 특성을 반영하기 위한 기능을 담당하는 클래스들로 게임 상태 저장이나 위치 저장등과 같은 역할을 수행한다. 따라서 개발자의 판단 하에 구현하고자 하는 컨텐츠의 특성에 맞도록 프로그래밍 되어야 하는 부분이므로 본 발명에 따라 구축된 클래스 라이브러리의 적용 범위에 속하지 않는다. Of the above classes, a class library constructed according to the present invention can be applied to the GameAlgorithm, GameContainer, and GameXlet classes that provide functions related to the displayed elements of the concave game content. Other classes are responsible for reflecting domain characteristics such as game contents, and play a role of saving game state or saving location. Therefore, it should be programmed according to the characteristics of the content to be implemented at the developer's discretion and does not belong to the scope of application of the class library constructed in accordance with the present invention.
구현된 두개의 컨텐츠를 테스트하기 위하여 스트림스테이션(StreamStation)을 이용하였다. 스트림스테이션은 자바 애플리케이션을 셋탑박스에서 해석 가능한 RF(Radio Frequency) 신호로 변환하여 출력해주는 애뮬레이션 장비이다. PC에서 작성한 애플리케이션을 스트림스테이션을 이용하여 MHP 미들웨어가 탑재된 셋탑박스로 송출함으로서 skylife를 통해 방송되는 내용과 같은 결과를 나타낼 수 있다. 한편, 현재 상용화 되어있는 OCAP 셋탑박스가 존재하기 않고 ACAP은 아직 표준화가 정립되지 않은 관계로 MHP 셋탑박스에서만 설계한 클래스 라이브러리의 검증이 이루어졌다. 그러나 향후 다른 미들웨어에서의 테스트를 위하여 OCAP API를 분석하여 필요한 OCAP 종속적인 API를 직접 구현하였고, 이를 이용하여 컨텐츠 구현 시 PC용 애플리케이션 상태에서 컴파일 에러가 발생하지 않도록 테스트하였다. 따라서 추후에 OCAP 셋탑박스가 상용화되고 ACAP 표준이 정립된 후에, 본 발명에 따라 구축된 클래스 라이브러리를 MHP 이외의 다른 미들웨어 표준에서의 적용이 어렵지 않을 것이다. StreamStation was used to test the implemented two contents. StreamStation is an emulation device that converts Java applications into RF (Radio Frequency) signals that can be interpreted in set-top boxes. By sending an application written on a PC to a set-top box equipped with MHP middleware using a stream station, the same result as that broadcasted through skylife can be produced. On the other hand, there is no commercial OCAP set-top box and ACAP has not been standardized yet. Therefore, the class library designed only in MHP set-top box has been verified. However, for future testing in other middleware, OCAP API was analyzed and the required OCAP-dependent API was directly implemented. By using this, test was performed to prevent compilation errors in the application state for PC. Therefore, after the OCAP set-top box is commercialized and the ACAP standard is established in the future, it will not be difficult to apply the class library constructed in accordance with the present invention to other middleware standards other than MHP.
이와 같이 구성된 테스트를 통해, 기존의 컨텐츠 개발방법과 본 발명에 따라 구축된 클래스 라이브러리를 통한 컨텐츠 개발방법에 있어서 개발의 효율성에 중점을 두어 양자간의 그래픽 디스플레이 및 인터랙션 기능, 클래스 개수, 애플리케이션 크기 및 코딩 라인 및 로딩 시간 및 응답시간을 비교하였다. 테스트 결과를 살펴보면 다음과 같다. Through the test configured as described above, the graphic display and interaction function, the number of classes, the application size and the coding between the existing content development method and the content development method through the class library built in accordance with the present invention are focused on the efficiency of development. Line and loading time and response time were compared. The test results are as follows.
먼저, 그래픽 디스플레이 및 제공하는 기능에 있어서, 두 컨텐츠간의 차이가 없었다. 일반적으로 게임 컨텐츠는 다른 컨텐츠들에 비해 다양한 인터랙션과 화려한 그래픽을 제공한다. 따라서 뉴스, 증권 등 다른 서비스 도메인에서 방송될 컨텐츠 제작 시에도 본 발명에 따라 구축된 클래스 라이브러리를 사용하여 원하는 그래픽과 인터랙션 기능 등을 무리없이 표현할 수 있을 것이라 예상된다. First, there was no difference between the two contents in the graphic display and providing function. In general, game content provides a variety of interactions and colorful graphics compared to other content. Therefore, even when producing content to be broadcast in other service domains such as news and securities, it is expected that a desired graphic and interaction function can be expressed without difficulty using the class library constructed in accordance with the present invention.
다음으로, 클래스 개수에 있어서, 개발의 편의성을 비교해보기 위하여 개발자가 고려해야 할 클래스 개수와 실제 개발 시 임포트(import)된 클래스 개수를 비교하였다. 국내 데이터 방송 환경에서 서로 다른 미들웨어의 상이한 API에 대한 이해가 필요하므로 개발자는 총 587개의 클래스를 고려하여 컨텐츠 개발을 해야 한다. 표 2에는 각각의 미들웨어에 따라 고려해야할 클래스의 갯수가 기재되어 있다.Next, in terms of the number of classes, in order to compare the convenience of development, the number of classes to be considered by the developer and the number of classes imported during actual development were compared. As it is necessary to understand the different API of different middleware in domestic data broadcasting environment, the developer should develop contents considering 587 classes in total. Table 2 lists the number of classes to consider for each middleware.
한편, 오목게임 컨텐츠의 구현시 임포트되는 클래스는 기존의 MHP 사용시에는 42개의 클래스를 임포트하여야 한다. MHP 사용시 임포트되는 클래스들은 표 3에 기재되어 있다. On the other hand, the classes to be imported when implementing the game contents should import 42 classes when using the existing MHP. The classes that are imported when using the MHP are listed in Table 3.
그러나 본 발명에 따라 구축된 클래스 라이브러리는 총 47개의 클래스로 구성되어 있다. 표 4에는 본 발명에 따라 구축된 클래스 라이브러리를 참조하여 오목 게임을 구현할 때에 임포트되는 클래스가 기재되어 있다.However, the class library built according to the present invention is composed of a total of 47 classes. Table 4 lists the classes that are imported when implementing the caro game with reference to the class library built in accordance with the present invention.
이처럼 많은 수의 클래스를 줄일 수 있었던 이유는 먼저 변환처리 모듈을 통해 개발자가 상이한 미들웨어 환경에서 알아야 했던 API들에 대한 이해가 필요 없었기 때문이며, 다음으로 디지털 방송 환경 설정에 관해 임포트 해야 했던 많은 클래스들을 캡슐화하여 은닉했기 때문이다. 또한 각 미들웨어에서 정의된 API는 컨텐츠 개발에 필요한 내용 이외에도 셋탑박스 개발에 필요한 API와 방송을 송출하기 위한 API등을 포함하고 있기 때문에 전체 API가 실제 데이터 컨텐츠 개발에 이용되는 것은 아니기 때문이다. 따라서 다양한 데이터 컨텐츠를 개발해온 경험을 바탕으로 데이터 컨텐츠 개발에 실제 자주 사용되는 클래스들과 그렇지 않은 클래스들을 파악하고 개발 필드에서 필요로 하는 기능을 위주로 클래스를 단일화함으로써 하나의 클래스 접근으로 원하는 기능을 구현할 수 있다. The reason for this reduction in the number of classes was because the conversion module did not require an understanding of the APIs that developers needed to know in different middleware environments, and then encapsulated many classes that had to be imported into the digital broadcast environment setup. Because it was concealed. In addition, since the API defined in each middleware includes APIs required for set-top box development and APIs for broadcasting, in addition to the contents required for content development, the entire API is not used for actual data content development. Therefore, based on the experience of developing various data contents, we can grasp the classes that are frequently used for data contents development and the classes that are not, and unify the classes based on the functions needed in the development field to implement the desired functions with one class access. Can be.
다음으로, 애플리케이션 크기 및 코딩 라인에 있어서, 현재 스카이라이프는 디지털 방송 서비스를 위해 총 12기의 위성 중계기를 임대해주고 있고, 이 가운데 데이터 방송은 1개의 중계기를 할당 받아 사용 중이다. 1기의 중계기는 대략 38 Mbps의 대여폭을 가지고 있으며 많은 업체가 중계기를 함께 사용하는 이유로 컨텐츠는 보통 400~500KB로 구성되는 것이 일반적이다. 전체 애플리케이션의 크기를 측정하는 이유는 위에서 언급한 것처럼 데이터 방송 서비스를 제공하기 위해 컨텐츠 제작 업체가 사용할 수 있는 대여폭이 제한적이기 때문에 클래스 라이브러리를 포함하여 전송하였을 때 무리가 없는지를 테스트하기 위함이다. 전체 애플리케이션의 크기는 오목 컨텐츠가 셋탑박스 상에서 구동되기 위해 필요한 모든 데이터를 합한 크기를 말하는 것으로 자바 클래스 파일 외에도 클래스 라이브러리 패키지, 이미지, 사운드 등 리소스 파일이 포함된다. 표 5에는 기존의 방법에 의해 구현된 컨텐츠와 본 발명에 따른 라이브러리를 참조하여 구현된 컨텐츠의 크기 및 코딩라인의 수가 기재되어 있다.Next, in terms of application size and coding line, Skylife currently leases a total of 12 satellite repeaters for digital broadcasting service, and one of these data broadcasts is allocated and used. One repeater has a rental bandwidth of approximately 38 Mbps, and the content is generally composed of 400 ~ 500KB because many companies use repeaters together. The reason for measuring the size of the entire application is to test whether there is no problem when transmitting the class library because the rental width available to the content producer is limited to provide the data broadcasting service as mentioned above. The size of the entire application is the sum of all the data needed for the concave content to run on the set-top box. In addition to the Java class files, it includes resource files such as class library packages, images, and sounds. Table 5 describes the content implemented by the existing method and the size of the content implemented by reference to the library according to the present invention and the number of coding lines.
표 5를 참조하면, 본 발명에 따라 구축된 클래스 라이브러리를 통해 구현된 오목 컨텐츠는 전체 애플리케이션의 크기가 기존의 MHP 기반 오목 컨텐츠보다 32KB 컸다. 이는 본 발명에 따라 구축된 클래스 라이브러리를 통해 구현된 오목 컨텐츠는 올바른 동작을 위해서는 설계한 클래스 라이브러리를 jar 파일 형태로 함께 전송해야 했기 때문이다. 그러나 클래스 라이브러리, 이미지, 사운드 등을 제외하고 실제 개발자가 작성한 순수 자바 코드만을 포함하는 클래스 파일의 크기와 코딩 라인수를 비교한 결과 제안한 클래스 라이브러리를 통해 구현된 컨텐츠가 기존의 컨텐츠에 비해 약 30%정도 줄었음을 알 수 있다. 사실상 데이터 컨텐츠 표현에 관한 기능을 제공하는 GameAlgorithm, GameContainer, GameXlet 클래스를 제외한 나머지 클래스들은 클래스 라이브러리의 영향을 거의 받지않기 때문에 기존의 컨텐츠와 새로 구현된 컨텐츠에 공통으로 포함된다. 또한 GameAlgorithm 클래스에서 다음 돌을 놓는 위치를 결정하는 오목 알고리즘 구현 관련 부분이 중복될 수밖에 없음을 가만했을 때, 본 발명에 따라 구축된 클래스 라이브러리의 효율성을 판단하기 위해서는 컨텐츠의 디스플레이적인 내용과 인터랙션 부분을 표현하는 GameContainer 클래스의 변화를 살펴보아야 한다. 그 결과 GameContainer 클래스의 코딩 라인이 기존의 컨텐츠에 비해 약 50% 정도 줄어들어 코딩이 훨씬 간단해졌음을 알 수 있으며, 전체 코딩 라인의 변화에 GameContainer 클래스의 변화가 가장 큰 영향을 미침을 알 수 있다. Referring to Table 5, the concave content implemented through the class library built in accordance with the present invention was 32KB larger than the overall MHP-based concave content of the size of the entire application. This is because the concave content implemented through the class library constructed according to the present invention had to transfer the designed class library together in a jar file form for proper operation. However, after comparing the size of the class file and the number of lines of coding that contain only pure Java code written by developers, excluding the class library, images, and sound, the content implemented through the proposed class library is about 30% compared to the existing content. It can be seen that the decrease. In fact, except the GameAlgorithm, GameContainer, and GameXlet classes, which provide functions for data content representation, they are included in both existing and newly implemented content because they are hardly affected by the class library. In addition, when the part related to the implementation of the concave algorithm for deciding where to place the next stone in the GameAlgorithm class is inevitably duplicated, in order to determine the efficiency of the class library constructed in accordance with the present invention, the display content and the interaction part of the content are determined. Notice the change in the GameContainer class that it represents. As a result, the coding line of the GameContainer class is reduced by about 50% compared to the existing content, which makes coding much simpler. It can be seen that the change of the GameContainer class has the greatest influence on the change of the entire coding line.
다음으로, 로딩 시간 및 응답시간에 있어서, 두 컨텐츠를 셋탑박스에서 구동하였을 때 애플리케이션 로딩 시간 및 게임진행에 따른 컴퓨터의 응답시간을 비교하였다. 로딩 시간 및 응답 시간은 스트림스테이션에 표기되는 진행시간을 토대로 하여 총 10번의 테스트 후 평균을 산출하였다. 먼저 로딩시간을 비교해본 결과 기존 오목 컨텐츠는 로딩시간이 평균 15.6초, 새로 구현된 오목 컨텐츠는 평균 16.8초로 새로 구현한 오목 컨텐츠가 약 1.2초 정도 로딩 시간이 더 필요함을 알 수 있었다. 이는 실제로 컨텐츠를 접하게 되는 사용자는 거의 차이를 느끼지 못하는 정도의 시간 차이이며, 이처럼 로딩시간이 더 필요한 이유는 새로 구현한 컨텐츠가 클래스 라이브러리 패키지를 포함하고 있기 때문이다. 다음으로 응답시간을 측정하였다. 본 테스트에서 의미하는 응답시간이란 리모콘 입력에 따라 화면 디스플레이의 변화가 나타나는 시간을 의미하는 것으로 데이터 방송에서는 셋탑박스의 제한된 메모리 영역으로 인하여 디스플레이 타임 딜레이(time delay)가 발생하기 쉽다. 측정 결과 두 컨텐츠 모두 1초 이내의 반응을 보여 두 컨텐츠 간의 차이를 전혀 느낄 수 없었으므로 애플리케이션의 전체 용량이나 컨텐츠를 구성하고 있는 디렉토리의 뎁스(depth)가 응답시간에 미치는 영향은 미미함을 알 수 있다. Next, in loading time and response time, when the two contents were driven in the set-top box, the application loading time and the response time of the computer according to game progress were compared. The loading time and response time were averaged after a total of 10 tests based on the running time indicated on the stream station. As a result of comparing the loading time, the loading time of the existing concave content is 15.6 seconds on average and the newly implemented concave content is 16.8 seconds on average. This is a time difference in which the user who encounters the content is almost indistinguishable, and the reason why the loading time is more necessary is that the newly implemented content includes the class library package. Next, the response time was measured. In this test, the response time refers to the time when the screen display changes according to the input of the remote controller. In data broadcasting, a display time delay is likely to occur due to the limited memory area of the set-top box. As a result of the measurement, both contents responded within one second, so we could not feel the difference between the two contents. Therefore, the effect of the total capacity of the application or the depth of the directory constituting the contents on the response time was minimal. have.
본 발명은 또한 컴퓨터로 읽을 수 있는 기록매체에 컴퓨터가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 기록매체는 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 컴퓨터가 읽을 수 있는 기록매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광데이터 저장장치 등이 있으며, 또한 캐리어 웨이브(예를 들어 인터넷을 통한 전송)의 형태로 구현되는 것도 포함한다. 또한 컴퓨터가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어 분산방식으로 컴퓨터가 읽을 수 있는 코드가 저장되고 실행될 수 있다.The invention can also be embodied as computer readable code on a computer readable recording medium. The computer-readable recording medium includes all kinds of recording devices in which data that can be read by a computer system is stored. Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage, and the like, and may also be implemented in the form of a carrier wave (for example, transmission over the Internet). Include. The computer readable recording medium can also be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.
이상에서 본 발명의 바람직한 실시예에 대해 도시하고 설명하였으나, 본 발명은 상술한 특정의 바람직한 실시예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자라면 누구든지 다양한 변형 실시가 가능한 것은 물론이고, 그와 같은 변경은 청구범위 기재의 범위 내에 있게 된다.Although the preferred embodiments of the present invention have been shown and described above, the present invention is not limited to the specific preferred embodiments described above, and the present invention belongs to the present invention without departing from the gist of the present invention as claimed in the claims. Various modifications can be made by those skilled in the art, and such changes are within the scope of the claims.
본 발명에 따른 OCAP 기반의 라이브러리 구축 방법에 의해 구축된 클래스 라이브러리에 의하면, 하나의 컨텐츠를 미들웨어에 독립적으로 구현하여 공유할 수 있으며 더불어 데이터 컨텐츠 개발자가 각 미들웨어마다 상이한 규격을 숙지할 필요가 없어 효율적인 컨텐츠 개발이 가능하다. 또한, 컨텐츠의 재사용성이 증가하고 개발자가 보다 양질의 컨텐츠를 개발할 수 있는 환경이 조성됨에 따라 국내 데이터 방송 컨텐츠 개발이 활성화될 수 있으며, 향후에는 간단한 컨텐츠 제작을 위한 선언적 애플리케이션 활용의 증대가 가능하다. According to the class library built by the OCAP-based library construction method according to the present invention, one content can be independently implemented and shared in middleware, and data content developers do not need to know different specifications for each middleware. Content development is possible. In addition, as data reusability increases and an environment for developers to develop higher quality content is created, domestic data broadcasting content development can be activated, and in the future, the use of declarative applications for simple content production can be increased. .
Claims (6)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020050045739A KR100649946B1 (en) | 2005-05-30 | 2005-05-30 | Method for constructing library based on open cable application platform and recoding medium storing the smae |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020050045739A KR100649946B1 (en) | 2005-05-30 | 2005-05-30 | Method for constructing library based on open cable application platform and recoding medium storing the smae |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| KR100649946B1 true KR100649946B1 (en) | 2006-12-26 |
Family
ID=37814679
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020050045739A KR100649946B1 (en) | 2005-05-30 | 2005-05-30 | Method for constructing library based on open cable application platform and recoding medium storing the smae |
Country Status (1)
| Country | Link |
|---|---|
| KR (1) | KR100649946B1 (en) |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001075944A (en) | 1999-06-30 | 2001-03-23 | Sony Corp | Method and device for producing contents and program providing medium |
| KR20010112066A (en) * | 2000-06-08 | 2001-12-20 | 김문영 | Authoring system for contents of digital television and its method |
| KR20020069102A (en) * | 2001-02-23 | 2002-08-29 | 주식회사 에어코드 | A contents authoring system and a contents authoring method for data broadcasting |
| KR20030091106A (en) * | 2002-05-22 | 2003-12-03 | 주식회사 에어코드 | A system for creating and operating real-time data contents for data broadcasting and a controlling method thereof |
| US20030229900A1 (en) * | 2002-05-10 | 2003-12-11 | Richard Reisman | Method and apparatus for browsing using multiple coordinated device sets |
| KR20040048246A (en) * | 2002-12-02 | 2004-06-07 | 삼성전자주식회사 | A java execution device and a java execution method |
| US7055169B2 (en) * | 2002-04-19 | 2006-05-30 | Opentv, Inc. | Supporting common interactive television functionality through presentation engine syntax |
-
2005
- 2005-05-30 KR KR1020050045739A patent/KR100649946B1/en not_active IP Right Cessation
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001075944A (en) | 1999-06-30 | 2001-03-23 | Sony Corp | Method and device for producing contents and program providing medium |
| KR20010112066A (en) * | 2000-06-08 | 2001-12-20 | 김문영 | Authoring system for contents of digital television and its method |
| KR20020069102A (en) * | 2001-02-23 | 2002-08-29 | 주식회사 에어코드 | A contents authoring system and a contents authoring method for data broadcasting |
| US7055169B2 (en) * | 2002-04-19 | 2006-05-30 | Opentv, Inc. | Supporting common interactive television functionality through presentation engine syntax |
| US20030229900A1 (en) * | 2002-05-10 | 2003-12-11 | Richard Reisman | Method and apparatus for browsing using multiple coordinated device sets |
| KR20030091106A (en) * | 2002-05-22 | 2003-12-03 | 주식회사 에어코드 | A system for creating and operating real-time data contents for data broadcasting and a controlling method thereof |
| KR20040048246A (en) * | 2002-12-02 | 2004-06-07 | 삼성전자주식회사 | A java execution device and a java execution method |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5919301B2 (en) | Smart set-top box providing smart service and digital TV service on a single operating system and driving method thereof | |
| CN103430564B (en) | The Intelligent set top box and operating method of intelligent Service and digital TV service are provided using the default media player included in single operating | |
| US20080244682A1 (en) | Method for enhancing features offered by a software application residing on a set top terminal | |
| US20040207723A1 (en) | UI remoting with synchronized out-of-band media | |
| US20070261090A1 (en) | Interactive television application distribution, control, and communication system and methods | |
| CN104427388A (en) | Operating system of intelligent television | |
| KR20010080210A (en) | Television set-top box with configurable functionality | |
| WO2006042300A2 (en) | System and method for creating, distributing, and executing rich multimedia applications | |
| US9621370B2 (en) | Apparatus and method for providing interactive service to device using different digital broadcast middleware standards | |
| WO2006122024A2 (en) | Open architecture for internet protocol television | |
| CN112099795A (en) | Interface notification message construction method, device, equipment and storage medium | |
| Vidakovic et al. | A java API interface for the integration of DTV services in embedded multimedia devices | |
| US20030033612A1 (en) | Software appliance method and system | |
| Jones | DVB-MHP/Java TV data transport mechanisms | |
| KR100649946B1 (en) | Method for constructing library based on open cable application platform and recoding medium storing the smae | |
| US8776164B2 (en) | Distributed presentation software for multiple instantiations in home network | |
| CN115119022B (en) | Control method for skipping video advertisements and display equipment | |
| TW200400765A (en) | DVD virtual machine | |
| JP2009129170A (en) | Device control apparatus and broadcast receiver equipped with the apparatus | |
| CA2301935A1 (en) | Streaming media control and synchronization application program interface (api) for a digital television receiver | |
| Fotschl et al. | Interactive applications for the multimedia home platform | |
| CN117812379A (en) | Display equipment and media asset playing method | |
| CN103348692B (en) | Single operating is used to be used for Intelligent Service and the Intelligent set top box of digital TV service and operational approach | |
| Maia et al. | Using the iDTV as the Center of an Ubiquitous Environment | |
| Song et al. | Mobile rich media technologies: current status and future directions |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A201 | Request for examination | ||
| N231 | Notification of change of applicant | ||
| E701 | Decision to grant or registration of patent right | ||
| GRNT | Written decision to grant | ||
| FPAY | Annual fee payment |
Payment date: 20091117 Year of fee payment: 6 |
|
| LAPS | Lapse due to unpaid annual fee |