KR20110025012A

KR20110025012A - 근거리 네트워크에서 사용자 인터페이스 매칭장치 및 방법

Info

Publication number: KR20110025012A
Application number: KR1020090096927A
Authority: KR
Inventors: 박호연; 황승오; 정보선; 김준형; 금지은
Original assignee: 삼성전자주식회사
Priority date: 2009-09-01
Filing date: 2009-10-12
Publication date: 2011-03-09
Also published as: US20110050449A1; JP5937005B2; CN102484895B; CN104683451B; WO2011028022A3; CN102484895A; CN104683451A; WO2011028022A2; EP2474198A2; EP2474198A4; US9607504B2; EP2474198B1; AU2010290258B2; AU2010290258A1; JP2013502146A

Abstract

원격 UI 디바이스에서 표현되고 있는 원격 UI 화면을 제어할 수 있는 제3의 원격 UI 디바이스에서, 원격 UI 서버로부터 제3의 원격 UI 디바이스에 적합한 제어 UI를 받기 위해 원격 UI 서버와 제3의 원격 UI 디바이스 간에 Capability Exchange하는 과정으로 이루어진다.

Control UI, CUI, RUI, Remote Control, RC

Description

근거리 네트워크에서 사용자 인터페이스 매칭장치 및 방법{APPARATUS AND METHOD FOR MACHING USER INTERFACE IN A LOCAL NETWORK}

본 발명은 근거리 네트워크에서 사용자 인터페이스 (User Interface, 이하 UI라 칭함)를 매칭하기 위한 장치 및 방법에 관한 것으로, 특히 근거리 네트워크 내에서 장치의 성능에 매칭되는 UI가 운용될 수 있도록 하는 장치 및 방법에 관한 것이다.

오늘날 근거리 네트워크를 기반으로 하는 홈 네트워크 기술은 많은 산업 표준 단체들에 의해 그 성능 향상을 위한 연구가 활발히 진행되고 있다. 상기 홈 네트워크 기술의 성능 향상을 위한 연구를 진행하고 있는 대표적인 산업 표준 단체들로는 DLNA(Digital Living Network Alliance), HAVi(Home Audio-Video Interoperability), UPnP(Universal Plug and Play) 등이 존재한다.

한편, 홈 네트워크에서 하나의 장치가 다른 장치의 기능을 제어하기 위해서는 원격 사용자 인터페이스 (RUI: Remote User Interface) 기술이 사용될 수 있다. 상기 RUI 기술에 관해 간단하게 설명하면, 상기 RUI 기술은 클라이언트-서버 아키텍쳐 (client-server architecture)를 기반으로 하고 있다. 이는 RUI 클라이언트가 RUI 서버로부터 UI를 가져와서, 사용자가 RUI 클라이언트에서 UI를 통해 RUI 서버를 제어할 수 있도록 하는 기술이다.

따라서 RUI 클라이언트에서 RUI 서버를 제어하기 위해서는 상기 RUI 서버로부터 UI를 제공받을 수 있는 방안이 마련되어야 한다.

본 발명은 원격지 장치에서 RUI 서버를 제어하기 위한 RUI를 제공하기 위한 장치 및 방법을 제안한다.

또한, 본 발명은 원격지 장치의 성능에 매칭된 RUI를 RUI 서버에서 제공할 수 있도록 하는 장치 및 방법을 제안한다.

또한, 본 발명은 원격지에 있는 제3의 장치에서 원격 UI 장치를 제어할 수 있는 제어 UI를 RUI 서버로부터 제공받을 때 제3의 장치의 성능 (Capability)에 맞는 제어 UI를 제공받도록 하는 장치 및 방법을 제안한다.

본 발명의 실시 예에 따른 근거리 네트워크 시스템에서의 사용자 인터페이스 매칭 방법은, 원격지에 위치하는 장치로부터 자신의 성능에 관한 정보를 전달받 는 과정과, 상기 전달받은 성능에 관한 정보를 원격 사용자 인터페이스 서버로 전달 가능한 형태의 데이터로 가공한 후 상기 사용자 인터페이스 서버로 전달하는 과정 및 상기 사용자 인터페이스 서버로부터 상기 성능에 관한 정보에 매칭되는 원격 사용자 인터페이스에 관한 정보를 수신하는 과정을 포함한다.

본 발명의 실시 예에 따른 근거리 네트워크 시스템에서의 사용자 인터페이스 매칭 장치는, 자신의 성능에 관한 정보를 요청에 의해 전달하는 원격 장치와, 상기 원격지 장치로부터 성능에 관한 정보를 전달받고, 상기 전달받은 성능에 관한 정보를 원격 사용자 인터페이스 서버로 전달 가능한 형태의 데이터로 가공한 후 전달하며, 상기 사용자 인터페이스 서버로부터 상기 성능에 관한 정보에 매칭되는 원격 사용자 인터페이스에 관한 정보를 수신하는 원격 사용자 인터페이스 제어기 및 상기 원격 사용자 인터페이스 제어기로부터 제공되는 성능에 관한 정보에 매칭되는 사용자 인터페이스에 관한 정보를 상기 원격 사용자 인터페이스 제어기로 제공하는 상기 사용자 인터페이스 서버를 포함한다.

상술한 바와 같이 본 발명을 통해서 원격지에 있는 제3의 장치에서 자신의 성능에 매칭된 제어 UI를 RUI 서버로부터 제공받도록 함으로써, 근거리 네트워크의 성능을 최대화할 수 있다. 한편, 그 외의 다양한 효과는 후술 될 본 발명의 실시 예에 따른 상세한 설명에서 직접적 또는 암시적으로 개시될 것이다.

하기에서 본 발명을 설명함에 있어 관련된 공지 기능 또는 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략할 것이다. 그리고 후술 되는 용어들은 본 발명에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.

이하 본 발명의 실시 예에서, 원격 UI 클라이언트 (Remote User Interface Client: 이하 "RUIC"라 칭함)는 클라이언트-서버 아키텍쳐 시스템에서 클라이언트에 원격 UI (Remote User Interface: 이하 "RUI"라 칭함) 및 제어정보 (control information)를 전송하는 장치(device)를 의미한다.

상기 RUIC는 원격 UI 서버 (Remote User Interface Server: 이하 "RUIS"라 칭함)로부터 RUIC에서 표현되는 UI와 상기 RUIC에서 표현되는 UI를 제어할 수 있는 제어 UI (CUI: Control User Interface)들을 수신한다. 상기 제어 UI들에 의해 RUIC 및/또는 상기 RUIC에서 랜더링되는 RUI가 제어된다.

한편, 본 발명의 실시 예에서 제3의 장치는 원격 제어 UI 장치(remote control RUIC device)로써 제어 UI를 통해 RUIC를 제어한다. 이때 상기 제어 UI는 RUIC 또는 RUIS로부터 제공받을 수 있다. 여기서 상기 제3의 장치는 모바일 기기 (예를 들면 휴대전화기 등), 휴대장치 (예를 들면 통신 기능을 가지는 소형 표시장치들) 등이 될 수 있다. 이하의 설명에서 상기 원격 제어 UI 장치는 제3의 장치 또 는 제3의 RUIC 또는 제3의 RUIC 장치로 혼용되어 사용될 수 있음에 유념하여야 한다.

도 1은 본 발명의 실시 예를 적용하기 위한 일반적인 근거리 네트워크 시스템의 구성을 보이고 있다. 즉 도 1에서는 제3의 RUIC를 통해서 RUIC(100)를 제어하기 위한 아키텍처를 보이고 있다.

도 1을 참조하면,RUIC(100)는 RUIS(101)와의 프로토콜을 위해 인터페이스 (Interface 1)(103)을 사용한다. 상기 RUIC(100)는 인터페이스 (Interface 1)(103) 상에서 사용하는 프로토콜을 통하여 RUIS(101)로부터 RUI와 컨트롤 정보를 수신한다. 여기서 컨트롤 정보는 RUIC(100)에서 표현되는 RUI를 제어할 수 있는 컨트롤 정보 이외에 제어 UI까지도 포함될 수 있다.

상기 RUIS(101)로부터 수신된 컨트롤 정보는 상기 RUIC(100) 내의 제어 UI 관리기(105)에 의해 제어 UI가 분리된다. 그리고 상기 제어 UI 관리기(105)는 상기 분리된 제어 UI를 상기 RUIC(100)의 제어를 위해 제3의 RUIC(102)에게 전달된다. 상기 전달된 제어 UI는 제3의 RUIC(102)에 표현되며, 사용자는 전달된 제어 UI를 사용하여 상기 RUIC(100)를 제어할 수 있다.

상기 제어 UI 관리기(105)는 논리적인 존재로서 상기 RUIC(100) 내부 혹은 외부에 존재할 수 있다.

도 2와 도 3은 제어 UI 관리기(105)가 RUIC(201) 외부에 존재할 수 있는 경우를 보이고 있다. 특히 DLNA RUIS(303)나 CEA-2014의 RUIS(202) 그리고 Open IPTV Forum의 OITF(300) 내에 존재하는 Mobile / Portable Device과 통신을 위한 Embedded Server Functional Entity 등이 될 수 있다. 덧붙여 RUIC(203) 내의 Remote Control Plug-in(203)의 역할까지 할 수 있다.

도 1의 RUIC(100)와 제3의 RUIC(102) 사이에 있는 인터페이스(Interface 2)(104)를 통해 UPnP 혹은 HTTP 프로토콜을 이용하여 제3의 RUIC(102)에서 표현되고 있는 제어 UI로부터 RUIC 장치 혹은 RUIC에 표현되고 있는 RUI를 제어할 수 있다.

도 4는 도 1을 통해 살펴본 아키텍처 상에서의 인터페이스를 보이고 있다. 즉 도 4에서는 제3의 장치(102)에서 RUIS(101)로 제3의 장치(102)의 성능 (Capability)을 전달하기 위한 프로토콜의 정의가 필요함을 보이고 있다.

도 4를 참조하면, 제3의 장치(102)는 RUIC(100) 내의 Embedded Server(105)와 성능 교환 (Capability Exchange)을 통해 제3의 장치(102)에 맞는 제어 UI를 RUIC(100)로부터 가져올 수 있다. 그 이유는 제3의 장치(102)와 RUIC(100) 간의 I/F2(104)에 대한 프로토콜에 대해서는 정의하고 있기 때문이다.

하지만, 제3의 장치(102)는 RUIS(101)에게 제3의 장치(102)의 성능 (Capability)에 관한 정보를 제공할 수 있는 방법이 마련되어 있지 않다. 따라서 RUIS(101)로부터 자신의 성능에 상응하는 제어 UI를 가져올 수가 없었다.

따라서 후술 될 본 발명의 실시 예에서는 RUIS(101)로부터 제3의 장치(102)의 성능 (Capability)에 맞는 제어 UI가 제공될 수 있도록 하기 위한 I/F 3(108)과 I/F 1(103)에 대한 프로토콜을 정의하고자 한다.

후술 될 본 발명의 실시 예는 RUIC에서 렌더링되고 있는 하나의 RUI를 제어 하는 제어 UI를 RUIS로부터 제3의 장치가 받아올 때, 제3의 장치의 성능 (Capability)에 맞는 제어 UI를 받아올 수 있도록 하는 방법 및 장치에 관해 구체적으로 설명할 것이다.

도 5는 본 발명의 실시 예에 따른 근거리 네트워크 시스템의 구조를 보이고 있다. 즉 도 5에서는 제3의 장치(502)에서 RUIC(500)를 거쳐 RUIS(509)에게 제3의 장치(502)에 관한 성능 (Capability)을 전달하기 위한 인터페이스를 보이고 있다.

도 5를 참조하면, 제3의 장치(502)는 인터페이스 2 (I/F 2)(104)를 통해 자신의 성능 (Capability)에 관한 정보를 RUIC(500) 내의 Embedded Server(506)에게 전달한다. 상기 Embedded Server(506)는 상기 제3의 장치(502)로부터 전달받은 성능(Capability)에 관한 정보를 인터페이스 4 (I/F 4)(510)를 통해서 Remote Control Plug-in(508)에게 전달한다.

상기 Embedded Server(506)에 의해 전달된 성능 (Capability)에 관한 정보는 상기 Remote Control Plug-in(508)에 저장된다. 그리고 Browser 1(505)은 인터페이스 5 (I/F 5)(511)를 통해 자신에 의해 표현되는 RUI와의 통신을 이용하여 제어 UI를 다운로드 받으라는 명령을 상기 Remote Control Plug-in(508)에게 전송한다.

상기 Remote Control Plug-in(508)는 상기 Browser 1(505)로부터 제어 UI를 다운로드 받으라는 명령을 전달받으면, 앞서 저장된 성능 (Capability)에 관한 정보를 인터페이스 6 (I/F 6)(512)를 통해 전달할 수 있는 형태로 변환한다. 하지만, 필요에 따라 상기 저장된 성능 (Capability)에 관한 정보의 형태를 변환하지 않을 수도 있다. 상기 인터페이스 6(512)은 상기 RUIC(500)와 RUIS(509) 간의 인터페이스를 의미한다.

그리고 상기 Remote Control Plug-in(508)는 상기 인터페이스 6(512)을 통해 상기 RUIS(509)에게 제어 UI를 다운로드 받으라는 HTTP 메시지를 전송한다. 상기 HTTP 메시지의 헤더에는 앞서 변환된 성능에 관한 정보가 포함된다. 상기 HTTP 메시지의 헤더에 포함되는 성능에 관한 정보는 User-Agent 값으로 변환된 정보이다. 하지만, 앞에서도 밝힌 바와 같이 필요에 따라 상기 성능에 관한 정보는 변환되지 않은 정보일 수 있다.

도 6은 본 발명의 실시 예에 따라 근거리 네트워크 시스템에서 성능에 관한 정보를 전달하기 위한 동작을 개략적으로 보이고 있다. 즉 도 6에서는 제3의 RUIC(502)의 성능 (Capability)에 관한 정보가 RUIC(500)를 거쳐 RUIS(509)에게 전달되는 형태를 보이고 있다.

도 6을 참조하면, 제3의 RUIC(502)는 RUIC(500)에게 자신의 성능 (Capability)에 관한 정보를 전송한다.

하기 <표 1>은 HTTP Header 내에 성능에 관한 정보가 포함된 구조의 일 예를 보이고 있다.

User-Agent: CE-HTML/1.0 (<capabilities>)

상기 RUIC(500)는 상기 <표 1>에서 표현된 User-Agent 값의 성능에 관한 정보를 전달받고, 상기 전달받은 성능에 관한 정보를 내부에 구비된 Remote Control Plug-in (508)에게 제공한다. 상기 Remote Control Plug-in(508)은 상기 전달된 성능 (Capability)에 관한 정보, 즉 성능 값을 RUIS(509)에 전달할 수 있는 형태로 변환(601)한다. 그리고 상기 변환된 형태의 성능에 관한 정보 (User+-Agent A-)를 상기 RUIS(509)에게 전달한다.

일 예로 상기 성능에 관한 정보를 OIPF에서 정의된 방식에 의해 전달한다고 할 때, 상기 OIPF에서 정의된 헤더의 구조는 HTTP Header 내에 상기 변환된 성능에 관한 정보가 포함될 수 있도록 하기 <표 2>와 같이 변경될 수 있다.

User-Agent: OIPF/1.1.0 (<capabilities>; [<vendorName>]; [<modelName>]; [<softwareVersion>];<hardwareVersion>];<reserved>) [<appName>[/<appVersion>]]

이때 상기 <표 1>에서 보이고 있는 성능에 관한 정보는 상기 <표 2>의 성능에 관한 정보 안에 포함된다. 혹은 상기 변형된 성능에 관한 정보는 상기 <표 2>의 필드 중, <reserved> 필드 안에 포함되어 보내어질 수도 있다.

만일, 제3의 RUIC(502)에서 RUIC(500)로 전달되는 User-Agent A (600) 형태와 상기 RUIC(500)에서 RUIS(509)로 전달되는 User-Agent A- (601) 형태가 같은 경우에는, User-Agent A(600) 형태 및 내용이 그대로 상기 RUIC(500)에서 상기 RUIS(509)로 전달될 수 있다.

도 7a와 도 7b는 본 발명의 실시 예에 따른 근거리 네트워크 시스템에서 성능에 매칭된 제어 UI를 제공하기 위한 제어 흐름을 보이고 있다. 즉 도 7a와 도 7b에서는 제3의 장치의 성능 (Capability)에 맞는 제어 UI를 RUIS로부터 RUIC를 거처 제3의 장치로 전달하기 위한 동작을 보이고 있다.

이때 도 7a는 제3의 RUIC가 현재 RUIC에 연결되어 있을 경우에 수행될 수 있는 제어 흐름이며, 도 7b는 도 7a에서 현재 연결된 제3의 RUIC가 없을 때, 나중에 제3의 RUIC가 RUIC에 연결되어 제어 UI를 요청할 경우에 수행될 수 있는 제어 흐름이다.

먼저 도 7a를 참조하면, RUIC는 700단계에서 RUIS에게 RUI를 요청한다. 상기 RUIS는 상기 요청에 대응하여 상기 RUIC로 요청된 RUI를 제공한다. 상기 RUIC는 701단계에서 상기 RUIS로부터 제공된 RUI를 실행한다.

그리고 702단계에서 상기 실행된 RUI는 현재 RUIC에 연결된 제3의 RUIC가 존재하는지 체크한다. 만약, 연결된 제3의 RUIC가 존재하지 않으면 703단계로 진행하여 RUI에 연관된 제어 UI에 대한 요청 관련 프로세스를 더 이상 진행하지 않는다. 이 후 제3의 RUIC가 RUIC에 접속하여 제어 UI를 요청할 경우, 도 7b의 제어 흐름에 따른 동작이 진행된다.

상기 702단계에서 현재 연결된 제3의 RUIC가 존재한다면, 704단계에서 상기 RUIC는 연결된 제3의 RUIC에게 성능 (Capability)에 대한 정보를 요청하며, 상기 요청에 대응하여 상기 제3의 RUIC로부터 성능에 대한 정보를 제공받는다.

상기 RUIC는 상기 제3의 RUIC로부터 성능 (Capability)에 대한 정보를 받으면, 705단계에서 RUIS에게 제3의 RUIC의 성능 (Capability)에 맞는 제어 UI를 요청한다. 상기 RUIC로부터 요청을 받은 RUIS는 해당 제어 UI를 상기 RUIC에게 전송한다.

상기 RUIC는 706단계에서 상기 RUIS로부터 전송된 제어 UI를 제3의 RUIC에게 전송한다.

다음으로, 도 7b를 참조하면, 도 7a에서 RUI가 실행될 때 현재 연결되어 있는 제3의 RUIC가 존재하지 않은 경우에 있어서, 이후에 제3의 RUIC가 RUIC에 접속을 하고 제어 UI에 대한 요청을 RUIC에게 하면, RUIC는 710단계에서 RUI가 실행되고 있는 도중에 제3의 RUIC로부터 제어 UI에 대한 요청을 수신한다. 이때 상기 제3의 RUIC는 711단계에서 요청 메시지에 제3의 RUIC에 대한 성능 (Capability)에 관한 정보를 함께 담아서 상기 RUIC에게 전송한다.

상기 RUIC는 제어 UI 요청을 위해 712단계에서 앞에서 전송받은 성능 (Capability)에 관한 정보를 제어 UI 요청 메시지와 함께 묶어서 상기 RUIS에게 전송한다. 그러면, 상기 RUIS는 전송받은 성능 (Capability)에 맞는 제어 UI를 추출하고, 상기 추출된 제어 UI를 상기 RUIC에게 전송한다. 상기 RUIC는 713단계에서 상기 RUIS로부터 전송받은 제어 UI를 상기 제3의 RUIC에게 전송한다.

도 8은 본 발명의 실시 예에 따라 RUI가 RUIC에서 실행될 때, 제3의 RUIC의 성능 (Capability)에 맞는 제어 UI를 전달하기 위한 시그널링을 보이고 있다.

도 8을 참조하면, 제3의 단말 혹은 전통적인 리모컨에 의해 RUIC(901)로 RUI가 실행되도록 명령이 내려지면, RUIC(901)는 RUIS(902)에게 RUI를 요청한다.

그 후 상기 RUIC(901)는 상기 RUIS(902)로부터 RUI를 전송받아 RUIC(901) 내의 Browser(905)에서 상기 전송받은 RUI를 실행한다. 상기 RUI는 실행되면서 Remote Control Plug-in(904)에게 현재 RUIC(901)에 연결된 제3의 RUIC가 존재하는지 여부를 isRCExist() method를 통해서 묻는다.

상기 Remote Control Plug-in(904)는 Embedded Server(903)에게 제3의 RUIC가 존재하는지 여부를 묻고, 상기 Embedded Server(903)는 제3의 RUIC가 현재 RUIC(901) 내의 Embedded Server(903)에 연결되어 있는지 여부를 체크한다.

이때 상기 제3의 RUIC가 연결되어 있다면 상기 제3의 RUIC(900)에게 성능 (Capability)에 관한 정보를 제공하여 줄 것을 요청하는 메시지를 보낸다. 그러면, 상기 제3의 RUIC(900)는 Embedded Server(903)에게 제어 UI에 대한 요청 메시지와 함께 자신의 성능 (Capability)에 관한 정보를 함께 제공한다.

만약에 이전에 제3의 RUIC가 상기 Embedded Server(903)에 접속하여 HTTP 메시지를 전송한 이력이 있다면, 상기 Embedded Server(903)는 그때, HTTP 메시지 안의 HTTP 헤더 중, User-Agent 값을 내부적으로 저장한다. 그리고 상기 제3의 RUIC(900)와 상기 RUIC(901) 내에 존재하는 Embedded Server(903) 간의 연결이 끊어지면, 저장된 User-Agent 값은 삭제된다.

상기 제3의 RUIC(900)는 상기 Embedded Server(903)와의 연결이 끊기기 전까지는 상기 Embedded Server(903)로부터 Notification을 받을 수 있는 연결은 지속적으로 유지하고 있다.

이후, 상기 Remote Control Plug-in(904)으로부터, 연결된 제3의 RUIC(900)에 대한 존재 여부를 체크하는 명령이 상기 Embedded Server(903)로 전달되면, 상기 Embedded Server(903)에 User-Agent 저장 여부를 체크한다. 그리고 존재하면 상기 Remote Control Plug-in(904)에게 User-Agent 값을 전달한다.

상기 Remote Control Plug-in(904)은 전달된 User-Agent 값을 내부에 저장하고, 상기 RUI(906)에게 현재 연결된 제3의 RUIC(900)가 존재한다는 'true' 값을 전달한다. 상기 'true' 값에 대한 전달과 제3의 RUIC(900)의 성능 (Capability) 값을 저장하는 순서를 뒤바뀔 수 있다.

상기 RUI(906)는 상기 Remote Control Plug-in(904)로부터 'true' 값을 받으면, 상기 Remote Control Plug-in(904)에게 현재 RUI를 제어할 수 있는 연관된 제어 UI를 전달하라는 getCUI 명령어를 전송한다.

상기 Remote Control Plug-in(904)는 이전에 저장한 제3의 RUIC의 성능 (Capability) 값을 RUIS(902)에 맞게 변형시킨 뒤, 상기 변형된 정보와 함께 제어 UI에 대한 요청을 상기 RUIS(902)에게 한다. 그리고 제3의 RUIC로 전송될 수 있도록 상기 Embedded Server(903) 내의 적절한 위치에 다운로드 받는다.

한편, 본 발명의 실시 예의 구현을 좀 더 간단히 하기 위해서, isRCExist method를 호출하는 동작에서부터, RUI에게 true 값을 리턴하는 동작까지의 과정은 생략될 수 있다. 이에 대신하여 대체할 수 있는 흐름도로, 이전에 제3의 RUIC(900)가 RUIC(901)에 접속하여 HTTP 메시지를 한번이라도 전송한 이력이 있으면, 해당 HTTP 메시지의 User-Agent 값을 RUIC(901) 내에 저장한다. 그리고 RUI(906)에서 Remote Control Plug-in(904)으로 getCUI method를 호출할 때, Remote Control Plug-in(904)은 RUIC(901) 내에 저장된 User-Agent 값을 그대로 사용하거나 혹은 변형하여 RUIS(902)에게 RUI(906)에 대한 제어 UI를 요청한다.

상술한 바에 의해 제어 UI에 대한 다운로드가 완성되면 상기 Remote Control Plug-in(904)는 RUI(906)에게 제어 UI에 대한 다운로드가 완성되었다는 onCompleteReceivingCUI 이벤트를 전송한다. 그러면, 상기 RUI(906)는 상기 Remote Control Plug-in(904)에게 실제로 제어 UI를 제3의 RUIC(900)에게 전송하라는 sendCUI 명령어를 전달한다.

상기 명령어를 전달받은 상기 Remote Control Plug-in(904)은 Embedded Server(903)에게 제3의 RUIC(900)로 제어 UI를 전달하라는 명령어를 전송한다. 상기 제어 UI를 전달하라는 명령어를 수신한 상기 Embedded Server(903)는 상기 제3의 RUIC(900)에게 제어 UI 정보 혹은 제어 UI에 대한 URL을 전송한다.

상기 제3의 RUIC(900)는 전송받은 URL 정보를 이용하여 자신에게 맞는 제어 UI를 전송받아서 실행시킨다.

도 9는 본 발명의 실시 예로 RUI가 RUIC에서 실행될 때, 제3의 RUIC에서 자신의 성능 (Capability)에 맞는 제어 UI 요청을 처리하기 위한 시그널링을 보이고 있다.

도 9를 참조하면, RUIC(901) 내의 Browser(905)에서 RUI가 실행되면서, 현재연결된 제3의 RUIC(900)가 있는지 여부를 체크한다. 상기 체크를 통해 연결된 제3의 RUIC(900)가 존재하지 않으면, 제어 UI에 관한 프로세스를 더 이상 진행하지 않는다.

그 후 제3의 RUIC(900)에 의해 제3의 RUIC(900)의 성능 (Capability)에 관한 정보가 담긴 제어 UI 요청 메시지가 Embedded Server(903)로 전송되면, 상기 Embedded Server(903)는 Remote Control Plug-in(904)에게 해당 성능 (Capability)에 관한 정보를 전송한다.

상기 Remote Control Plug-in(904)은 전송받은 성능 (Capability)에 관한 정보를 저장한 뒤, 현재 Browser(905)에서 실행되고 있는 RUI(906)에게 제어 UI에 대한 요청이 들어왔다는 onCUIRequest 이벤트를 전송한다. 그러면, 상기 RUI(906)는 상기 Remote Control Plug-in(904)에게 RUI(906)를 제어할 수 있는 제어 UI를 요청하는 getCUI 명령어를 상기 Remote Control Plug-in(904)에게 전송한다.

상기 Remote Control Plug-in(904)는 저장된 제3의 RUIC(900)의 성능 (Capability)에 관한 정보를 상기 RUIS(902)에 전송할 수 있는 형태로 변형시킨다. 상기 Remote Control Plug-in(904)는 제어 UI 다운로드 요청 메시지와 함께 상기 변형된 성능 (Capability)에 관한 정보를 상기 RUIS(902)로 전송한다. 그 후 상기 Remote Control Plug-in(904)는 상기 RUIS(902)로부터 제어 UI를 다운로드 받아서 내부의 적절한 장소에 저장한다. 그 뒤의 프로세스는 도 8과 동일하게 진행된다.

도 10은 본 발명의 실시 예에 따라 RUI가 RUIC에서 실행될 때, 제3의 RUIC의 성능 (Capability)에 맞는 제어 UI를 전달하기 위한 시그널링의 다른 예를 보이고 있다.

도 10에서는 RUI가 제어 UI를 RUIS에게 요청할 때, 제어 UI의 다운로드 방식이 아닌 제어 UI를 전달 (CUI Forwarding) 하는 역할을 하여 제어 UI를 제3의 RUIC에게 전달하는 방식이다.

도 10을 참조하면, RUI(906)가 getCUI 메소드를 통해서 Remote Control Plug-in(904)에게 제어 UI를 RUIS(902)로부터 전달받을 것을 요청한다. 상기 Remote Control Plug-in(904)은 상기 RUIS(902)에게 제어 UI를 요청한다. 상기 RUIS(902)는 상기 Remote Control Plug-in(904)에 의해 요청된 제어 UI에 대한 내용을 HTTP 메시지의 본체(BODY) 안에 넣어서, 상기 Remote Control Plug-in(904)에게 전달한다.

상기 Remote Control Plug-in(904)은 상기 RUIS(902)로부터 전달받은 HTTP 메시지로부터 제어 UI에 대한 내용을 추출하고, 상기 추출된 제어 UI에 대한 내용을 RUI(906)에게 전달한다. 상기 RUI(906)는 다시 상기 Remote Control Plug-in(904)에게 해당 HTTP 메시지로부터 추출한 제어 UI에 대한 내용을 Embedded web Server(903)를 통해, 제3 RUIC(900)에게 전달할 것을 명령한다. 상기 HTTP 메시지로부터 추출된 제어 UI에 대한 내용은 필요에 따라 RUI(906), Remote Control Plug-in(904) 혹은 Embedded web server(903)에 의해 수정될 수 있다.

한편, 참조번호 1000에 상응하는 시그널링인 onCompleteReceivingCUI와 sendCUI은 상황에 따라 수행될 필요가 없다. 예컨대 Remote Control Plug-in(904)에서 RUIS(902)로 제어 UI를 요청하고, 이에 대응한 응답을 받을 때, 응답 내용을 RUI(906)에게 알릴 필요가 없으면, 상기 참조번호 1000에 상응하는 시그널링은 사용되지 않는다. 이 경우 상기 Remote Control Plug-in(904)은 상기 RUIS(902)로부터 전달받은 HTTP 메시지로부터 추출한 제어 UI에 대한 내용을 Embedded web server(903)로 전달한다. 그리고 상기 Embedded web server(903)는 상기 Remote Control Plug-in(904)으로부터 전달받은 제어 UI에 대한 내용을 제3의 RUIC(900)에게 전달한다.

도 11은 본 발명의 실시 예로 RUI가 RUIC에서 실행될 때, 제3의 RUIC에서 자신의 성능 (Capability)에 맞는 제어 UI 요청을 처리하기 위한 시그널링의 다른 예를 보이고 있다.

도 11에서는 제어 UI의 다운로드 방식이 아닌 제어 UI를 전달 (Forwarding) 하는 역할을 하여 제어 UI를 제3의 RUIC에게 전달하는 방식이다.

도 11을 참조하면, RUIC(901) 내의 Browser(905)에서 RUI가 실행되면서, 현재연결된 제3의 RUIC(900)가 있는지 여부를 체크한다. 상기 체크를 통해 연결된 제3의 RUIC(900)가 존재하지 않으면, 제어 UI에 관한 프로세스를 더 이상 진행하지 않는다.

상기 getCUI 명령어를 수신한 Remote Control Plug-in(904)은 상기 RUIS(902)에게 제어 UI를 요청한다. 상기 RUIS(902)는 상기 Remote Control Plug-in(904)에 의해 요청된 제어 UI에 대한 내용을 HTTP 메시지의 본체(BODY) 안에 넣어서, 상기 Remote Control Plug-in(904)에게 전달한다.

도 12는 본 발명의 다른 실시 예에 따라 DLNA 장치에서 요청된 서비스에 맞는 제어 UI를 전달하기 위한 시그널링을 보이고 있다. 여기서 요청된 서비스는 IP TV 서비스이며, 상기 IP TV 서비스는 Open IPTV Forum 표준에 적용할 수 있는, DLNA Device(+RUIPL+)를 통해서 OITF로 요청할 수 있다.

도 12를 참조하면, DLNA Device(+RUIPL+)(1200)에서 미리 정의된 URI를 통해 OITF(1201)로 IPTV 서비스를 요청한다. 이때 상기 요청 시에 상기 DLNA Device(+RUIPL+)(1200)는 서비스 요청 메시지와 함께 자신의 성능 (Capability)에 관한 정보를 전송된다.

상기 DLNA Device(+RUIPL+)(1200)에 의해 전송된 성능 (Capability)은 상기 DLNA Functions(+RUISRC+)(1203) 안에 저장된다. 그리고 상기 DLNA Functions(+RUISRC+)(1203)는 DAE 브라우저(1205)에게 해당 IPTV 서비스에 맞는 DAE 어플리케이션 (Application)을 IPTV Applications server(1202)로부터 받아서 실행할 것을 명령한다.

상기 명령에 의해 해당 IPTV 서비스에 맞는 DAE Application(1206)이 DAE 브라우저(1205)에서 실행되면, 상기 DAE Application(1206)은 Remote Control Plug-in(1204)에게 제어 UI에 대한 URI와 함께 getCUI 메소드를 제공한다. 그 뒤, 상기 Remote Control Plug-in(1204)은 상기 DLNA Functions(+RUISRC+)(1203)에 저장된 성능 (capability)을 가져와서 IPTV Applications server(1202)에 전달할 수 있는 형태로 가공한다. 상기 가져온 성능을 IPTV Applications server(1202)에 전달할 수 있는 형태로 가공하는 것은 필요에 따라 이루어지지 않을 수도 있다.

한편, 상기 Remote Control Plug-in(1204)은 앞에서 가공 (또는 필요에 따라 가공되지 않은) 된 성능에 관한 정보를 상기 getCUI 메소드에 의해 전달받은 URI 파라미터를 이용하여 IPTV Applications(1202)으로 제공한다. 그리고 상기 Remote Control Plug-in(1204)은 상기 IPTV Applications(1202)으로부터 제어 UI를 전달받는다. 상기 제어 UI를 전달받는 형식은 2 가지가 존재할 수 있다.

먼저, 다운로드 형태로 전달받는다면, Remote Control Function Plug-in(1204)은 IPTV Applications server(1202)로부터 DLNA Functions(1203)으로 제어 UI들을 포함하는 압축 파일을 다운로드 받은 후 상기 다운로드 받은 압축 파일에 대한 압축을 해제한다. 그리고 DLNA Device(1200)에서 상기 압축을 해제한 디렉토리에 상응하는 URL 형태로 접근 가능한 장소를 onCompleteReceivingCUI 이벤트 함수를 이용하여 상기 DAE Application(1206)으로 전달한다.

상기 DAE Application(1206)은 전달받은 prefix URI를 가지고서 내부에 저장된 제어 UI 리스트 중 하나를 붙여서 새로운 URI를 생성한다. 이때 생성되는 새로운 URI는 DLNA Device(1200)가 OITF 내의 제어 UI에 접근 가능한 URI이다.

상술한 바에 의해 생성된 새로운 URI는 send CUI 메소드를 통해서 상기 DLNA Device(1200)에게 전달된다. 상기 DLNA Device(1200)는 해당 URI를 호출하여, OITF 단말 내의 DLNA Functions(1203)로부터 제어 UI를 전달받는다.

다른 예로써 제어 UI를 IPTV Applications server(1202)로부터 전달받을 때, 다운로드 방식이 아닌 Forwarding 방식으로 전달받는 경우를 설명하면, DAE Application(1206)은 제어 UI의 HTML 내용을 getCUI 메소드를 통해서 IPTV Applications server(1202)로부터 받아온다. 그리고 상기 DAE Application(1206)은 받아온 HTML 내용을 필요에 따라 수정한 후 sendCUI 메소드를 통해서 DLNA Device(1200)에게 전달한다. 하지만, 앞서 받아온 HTML 내용에 대한 수정이 필요 없으면, 상기 받아온 HTML 내용을 바로 sendCUI 메소드를 통해서 상기 DLNA Device(1200)에게 전달할 수도 있다.

상기 DLNA Device(1200)는 상기 DAE Application(1206)로부터 전달받은 HTML 내용을 자신의 화면에 렌더링한다.

상술한 두 가지의 예시에서 설명된 바와 같이 상기 sendCUI를 사용할 때, Forwarding 방식에서는 파라미터로 HTML 내용을 넣고, Download 방식일 때는 URI 값이 들어간다.

도 13은 본 발명의 다른 실시 예로 Open IPTV Forum 표준에 적용할 수 있는, DLAN Device(+RUIPL+)를 통해서 OITF에서 현재 실행되는 IPTV 서비스에 맞는 제어 UI를 제공받기 위한 시그널링을 보이고 있다.

도 13을 참조하면, 이미 OITF 단말(1201) 내에는 DAE Application(1206)에 의해 IPTV 서비스가 실행되고 있음을 가정한다. 이때 사용자는 DLNA Device(1200)의 IRCF 기능을 통해 상기 OITF(1201)에게 현재 실행되는 IPTV 서비스를 제어할 수 있는 제어 UI를 사전에 미리 정의된 URI를 통해 요청한다. 이때 상기 DLNA Device(1200)는 요청 메시지와 함께 DLNA Device(1200)의 성능 (Capability)에 관한 정보를 함께 DLNA Functions(1203)으로 전달한다. 그리고 상기 전달된 성능 (Capability)에 관한 정보는 상기 DLNA Functions(1203)에 저장된다.

상기 DLNA Functions(1203)는 상기 DLNA Device(1200)로부터 제어 UI에 대한 요청이 접수되었음을 Remote Control Function Plug-in(1204)에게 알린다. 이에 대응하여 상기 Remote Control Function Plug-in(1204)은 onCUIRequest 이벤트 함수를 통해 제어 UI 요청이 접수되었다는 사실을 DAE Application(1206)에게 알려준다. 상기 제어 UI 요청이 접수되었음을 인지한 상기 DAE Application(1206)은 getCUI 메소드를 통해 Remote Control Function Plug-in(1204)에게 해당 제어 UI를 IPTV Applications server(1202)로부터 전달받을 것을 명령한다. 상기 제어 UI를 IPTV Applications server(1202)로부터 전달받기 위해서는 상기 DLNA Functions(1203)에 저장된 capability를 이용한다. 이후 과정은 도 12에서 진행되는 과정과 동일함에 따라 구체적인 설명은 생략한다.

도 14는 본 발명의 실시 예로 Open IPTV Forum 표준의 DAE SPEC에 적용할 수 있는 API 및 인터페이스를 보이고 있다.

먼저, Property (Event) 관련해서 제 3의 장치에서 현재 OITF에서 실행되는 DAE Application에 대한 제어 UI를 요청할 경우, Remote Control Plug-in에서 DAE Application으로 onCUIRequest 콜백 이벤트 함수가 발생한다. 이때, 현재 연결된 제 3의 RUIC 장치에 대한 Device Handle 값이 파라미터로 함께 DAE Application으로 전달된다. 상기 onCUIRequest 콜백 이벤트 함수가 상기 DAE Application에 발생하기 이전에 OITF 단말은 상기 제 3의 RUIC 장치로부터 제어 UI에 대한 요청과 함께 전달된 제 3의 RUIC 장치의 성능 (capability)에 관한 정보를 저장한다. 상기 성능 (capability)에 관한 정보는 향후 IPTV Applications 서버로부터 상기 제 3의 RUIC 장치에 표현되기에 적절한 제어 UI를 가져오기 위한 getCUI 메소드가 호출될 때 사용된다.

두 번째 onCompleteReceivingCUI 콜백 이벤트 함수는 DAE Application에서 Remote Control Plug-in에게 발생한다. 상기 발생한 onCompleteReceivingCUI 콜백 이벤트 함수는 getCUI 메소드에 의해 제어 UI에 대한 다운로드를 요청하는 것이다. 상기 Remote Control Plug-in은 IPTV Applications로부터 OITF 단말로 제어 UI에 대한 다운로드가 완료되고, 제3의 RUIC 장치로 제어 UI에 대한 전송 준비가 완료되면, 상기 다운 로드된 제어 UI들에 접근할 수 있는 URI의 prefix 값을 상기 DAE Application으로 전달한다.

한편, 상기 onCompleteReceivingCUI 콜백 이벤트 함수를 발생하면서 함께 전달되는 파라미터 cuiPrefixURI는 다운 로드된 제어 UI들이 위치하는 디렉토리의 위치를 제3의 RUIC 장치가 OITF 단말에 접속할 수 있는 URL 형태로 표현된다 (Ex: /cui/playercontroller/001/).

만약, DAE Application이 가지고 있는 제어 UI에 대한 이름이 friends_cod_controller.html이라면, cuiPrefixURI와 제어 UI 이름을 붙여서, 제 3의 RUIC 장치에게 전달할 수 있다 (Ex: /cui/playercontroller/001/friends_cod_controller.html).

메소드를 보면, 제 3의 RUIC 장치 존재 여부에 대한 확인과 동시에 존재할 경우, 제3의 RUIC 장치의 성능 (Capability)에 관한 정보를 Remote Control Plug-in에 전송하여 저장할 수 있는 boolean isRCExist() 메소드가 있다. 이때 리턴 (Return)되는 값이 성공 (true)인 경우는 제3의 RUIC 장치가 현재 OITF 단말에 연결되어 있으며, 제3의 RUIC 장치의 성능 (Capability)에 관한 정보가 성공적으로 OITF 단말 내의 Remote Control Plug-in에 저장될 경우에 해당된다.

그 이외의 경우에는 실패 (false) 값이 DAE Application(RUI)로 리턴 (return) 된다.

상기 isRCExist() 메소드와 비슷한 기능을 하는 getConnectedRemoteDeivceHandle() 메소드의 경우는, DAE Application에 의해서 호출될 경우, 연결된 제3의 RUIC 장치를 조정할 수 있는 장치 조정 (device handle) 값을 정수 (Integer) 값으로 전달한다. 만약, 연결된 제3의 RUIC 장치가 없을 경우에는 불확정 (undefined) 값 혹은 널 (null) 값이 리턴된다.

다음으로, getCUI 메소드는 DAE Application이 Remote Control Plug-in에게 제어 UI를 IPTV Applications으로부터 다운로드 받도록 명령을 내린다. 이때, 다운로드 받을 수 있는 다운로드 URL 주소가 파라미터로써 전달되며, getCUI 메소드에 의해 Remote Control Plug-in이 IPTV Applications 서버에 다운로드 요청 메시지를 전송할 때, OITF 단말에 저장된 제3의 RUIC 장치의 성능 (capability)에 관한 값이 같이 전송된다.

상기 getCUI 메소드는 비동기 방식으로 진행되며, DAE Application에 의해 해당 메소드가 호출되면, 메소드에 대한 실행 여부의 성공 (true)/실패 (false) 값이 바로 DAE Application으로 넘어온다. 즉, 실질적으로 다운로드는 Remote Control Plug-in과 IPTV Applications 사이에서 진행 중이지만, DAE Application은 getCUI 메소드가 호출된 다음 프로세스를 바로 진행할 수가 있다. 한편, 상기 Remote Control Plug-in과 상기 IPTV Applications 사이의 다운로드가 완료되면, 앞서 설명한 onCompleteReceivingCUI 이벤트가 DAE Application으로 전달된다.

sendCUI 메소드가 실제로 현재 OITF에 연결된 제 3의 RUIC 장치에 대한 고유한 장치 조정 (Device Handle) 값과 제어 UI에 접근할 수 있는 URI 정보가 파라미터로 함께 전달되어 DAE Application에서 호출되면, Remote Control Plug-in은 첫 번째 파라미터로 전달된 장치 조정 (Device Handle) 값을 이용하여 해당 장치 조정 (Device Handle) 값에 연결된 제3의 RUIC 장치로 두 번째 파라미터 값인 제어 UI에 접근할 수 있는 URI 정보를 전송한다. 상기 제3의 RUIC 장치는 상기 Remote Control Plug-in로부터 전송된 URI 정보를 통해서 OITF 단말로부터 제어 UI를 가져올 수 있다.

Remote Control Plug-in과 RUIS 사이의 인터페이스 경우에 있어서, HTTP 프로토콜은 OIPF DAE SPEC에 정의된 형태를 그대로 사용하며, 대신 성능 (Capability)에 관한 정보를 기록하는 장소에 제3의 RUIC 장치의 성능 (Capability) 값을 기록한다. 이때 상기 제3의 RUIC에 관한 vendorName, modelName, SoftwareVersion, hardwareVersion, application Name, application version에 대한 정보를 함께 기록하는 것을 기본으로 한다.

만약, 이와 같은 정보(제3의 RUIC에 관한 vendorName, modelName, SoftwareVersion, hardwareVersion, application Name, application version에 대한 정보)가 제3의 RUIC 장치의 성능 (Capability)에 관한 정보와 함께 전송될 수 없는 상황이면(Ex: 제3의 RUIC 장치로부터 제 3의 RUIC 장치에 관한 vendorName, modelName, SoftwareVersion, hardwareVersion, application Name, application version에 대한 정보가 전달되지 않은 경우), 제 3의 RUIC 장치의 성능 (Capability)에 대한 정보 이외의 정보는 OITF 단말에 대한 정보로 채워져서 함께 전송될 수 있다. 물론, 상기 정보들은 optional 정보이기 때문에, 해당 필드는 값없이 제3의 RUIC 장치의 성능 (Capability)에 관한 정보만 전달될 수 있다. 한편, 도 10의 Remote Control Plug-in과 IPTV Applications 사이의 인터페이스의 예시를 보면, 상기 정보는 []로 표시되어 있다. []로 표시된 필드는 Optional 정보를 의미한다.

도 15a와 도 15b는 본 발명의 실시 예로 도 14에서 제시한 API들에 대한 Open IPTV Forum 표준의 스펙에 적용될 내용을 보이고 있다.

도 16은 본 발명의 실시 예로 Open IPTV Forum 표준의 PROTOCOL 스펙에 적용할 수 있는 제3의 단말이 OITF 단말에 IPTV 서비스 (service)를 실행시킬 수 있는 인터페이스 및 메시지를 보이고 있다.

도 8, 9, 10, 11의 흐름도에서 맨 처음에 제3의 RUIC 장치를 통해 IPTV Applications 서버에서 OITF 단말로 RUI(IPTV Service)를 보내서 실행시키기 위해서는 상기 프로토콜이 필요하다.

도 16은 크게 3가지 순서로 나뉜다. 첫 번째는 현재, 제3의 RUIC 장치에서 표현되는 제어 UI를 통해서 HTTP 메시지를 OITF 단말에 전송한다. 이때, 도 16의 첫 번째 스텝 (step 1)에 표시된 것처럼 GET 혹은 POST 방식으로 정해진 URI를 통해서, HTTP 요청 메시지를 전송할 수 있다. 두 번째 스텝 (step 2)은 제어 UI가 첫 번째 스텝에서 HTTP 메시지를 전송한 뒤, 응답을 받을 때까지 대기한다. 마지막으로 세 번째 스텝 (step 3)은 제3의 RUIC 장치에서 요청된 IPTV 서비스를 제어할 수 있는 새로운 제어 UI에 대한 URI 정보를 OITF 단말이 제3의 RUIC 장치에게 전송한다. 이때 상기 HTTP 메시지의 형식은 도 16의 세 번째 스텝과 같다. HTTP Response Body 안에 상기 제어 UI에 대한 URI 정보가 담겨 있다.

도 17은 본 발명의 실시 예로 Open IPTV Forum 표준의 PROTOCOL 스펙에 적용할 수 있는, 제3의 단말이 OITF 단말에서 현재 실행되는 DAE Application을 제어할 수 있는 제어 UI에 대한 요청을 할 수 있는 인터페이스 및 메시지를 보이고 있다.

도 17은 3가지 순서로 나뉜다. 첫 번째는 현재, 제3의 RUIC 장치에서 표현되는 제어 UI를 통해서 현재 OITF 단말에 실행되는 DAE Application을 제어할 수 있는 제어 UI에 대한 HTTP 요청 메시지를 OITF 단말에 전송한다. 이때, 도 17의 첫 번째 스텝 (step 1)에 표시된 것처럼 GET 방식으로 정해진 URI를 통해서, HTTP 요청 메시지를 전송할 수 있다. 두 번째 스텝 (step 2)은 제어 UI가 첫 번째 스텝에서 HTTP 메시지를 전송한 뒤, 응답을 받을 때까지 대기한다. 마지막으로 세 번째 스텝(step 3)은 제3의 RUIC 장치에서 요청한 제어 UI에 대한 URI 정보를 OITF 단말이 제3의 RUIC 장치에게 전송한다. 이때 HTTP 메시지의 형식은 도 17의 세 번째 스텝과 같다. HTTP Response Body 안에 상기 제어 UI에 대한 URI 정보가 담겨 있다.

한편, 이상에서는 본 발명의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 본 발명은 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형 실시할 수 있는 것은 물론이고, 이러한 변형 실시들은 본 발명의 기술적 사상이나 전망으로부터 개별적으로 이해되어 져서는 안 될 것이다.

도 1은 본 발명의 실시 예를 적용하기 위한 일반적인 근거리 네트워크 시스템의 구성을 보이고 있는 도면;

도 2와 도 3은 제어 UI 관리기가 RUIC 외부에 존재할 수 있는 경우를 보이고 있는 도면;

도 4는 도 1을 통해 살펴본 아키텍처 상에서의 인터페이스를 보이고 있는 도면;

도 5는 본 발명의 실시 예에 따른 근거리 네트워크 시스템의 구조를 보이고 있는 도면;

도 6은 본 발명의 실시 예에 따라 근거리 네트워크 시스템에서 성능에 관한 정보를 전달하기 위한 동작을 개략적으로 보이고 있는 도면;

도 7a와 도 7b는 본 발명의 실시 예에 따른 근거리 네트워크 시스템에서 성능에 매칭된 제어 UI를 제공하기 위한 제어 흐름을 보이고 있는 도면;

도 8은 본 발명의 실시 예에 따라 RUI가 RUIC에서 실행될 때, 제3의 RUIC의 성능 (Capability)에 맞는 제어 UI를 전달하기 위한 시그널링을 보이고 있는 도면;

도 9는 본 발명의 실시 예로 RUI가 RUIC에서 실행될 때, 제3의 RUIC에서 자신의 성능 (Capability)에 맞는 제어 UI 요청을 처리하기 위한 시그널링을 보이고 있는 도면;

도 10은 본 발명의 실시 예에 따라 RUI가 RUIC에서 실행될 때, 제3의 RUIC의 성능 (Capability)에 맞는 제어 UI를 전달하기 위한 시그널링의 다른 예를 보이 고 있는 도면;

도 11은 본 발명의 실시 예로 RUI가 RUIC에서 실행될 때, 제3의 RUIC에서 자신의 성능 (Capability)에 맞는 제어 UI 요청을 처리하기 위한 시그널링의 다른 예를 보이고 있는 도면;

도 12는 본 발명의 다른 실시 예에 따라 DLNA 장치에서 요청된 서비스에 맞는 제어 UI를 전달하기 위한 시그널링을 보이고 있는 도면;

도 13은 본 발명의 다른 실시 예로 Open IPTV Forum 표준에 적용할 수 있는, DLAN Device(+RUIPL+)를 통해서 OITF에서 현재 실행되는 IPTV 서비스에 맞는 제어 UI를 제공받기 위한 시그널링을 보이고 있는 도면;

도 14는 본 발명의 일 실시 예로 Open IPTV Forum 표준의 DAE SPEC에 적용할 수 있는 API 및 인터페이스를 보이고 있는 도면;

도 15a와 도 15b는 본 발명의 실시 예로 도 14에서 제시한 API들에 대해 Open IPTV Forum 표준의 DAE 스펙에 실제로 적용될 내용을 도시한 도면;

도 16은 본 발명의 실시 예로 Open IPTV Forum 표준의 PROTOCOL 스펙에 적용할 수 있는 제3의 단말이 OITF 단말에 IPTV 서비스를 실행시킬 수 있는 인터페이스 및 메시지를 보이고 있는 도면;

도 17은 본 발명의 실시 예로 Open IPTV Forum 표준의 PROTOCOL 스펙에 적용할 수 있는, 제3의 단말이 OITF 단말에서 현재 실행되는 DAE Application을 제어할 수 있는 제어 UI에 대한 요청을 할 수 있는 인터페이스 및 메시지를 보이고 있는 도면.

Claims

근거리 네트워크 시스템에서 사용자 인터페이스를 매칭하는 방법에 있어서,

원격지에 위치하는 장치로부터 자신의 성능에 관한 정보를 전달받는 과정;

상기 전달받은 성능에 관한 정보를 원격 사용자 인터페이스 서버로 전달 가능한 형태의 데이터로 가공한 후 상기 사용자 인터페이스 서버로 전달하는 과정; 및

상기 사용자 인터페이스 서버로부터 상기 성능에 관한 정보에 매칭되는 원격 사용자 인터페이스에 관한 정보를 수신하는 과정을 포함하는 사용자 인터페이스 매칭방법.
근거리 네트워크 시스템에서 사용자 인터페이스를 매칭하는 장치에 있어서,

자신의 성능에 관한 정보를 요청에 의해 전달하는 원격 장치;

상기 원격지 장치로부터 성능에 관한 정보를 전달받고, 상기 전달받은 성능에 관한 정보를 원격 사용자 인터페이스 서버로 전달 가능한 형태의 데이터로 가공한 후 전달하며, 상기 사용자 인터페이스 서버로부터 상기 성능에 관한 정보에 매칭되는 원격 사용자 인터페이스에 관한 정보를 수신하는 원격 사용자 인터페이스 제어기; 및

상기 원격 사용자 인터페이스 제어기로부터 제공되는 성능에 관한 정보에 매칭되는 사용자 인터페이스에 관한 정보를 상기 원격 사용자 인터페이스 제어기로 제공하는 상기 사용자 인터페이스 서버를 포함하는 사용자 인터페이스 매칭장치.